CPOF, Computer-Aided-Dispatch, and Open Source
699 views
Skip to first unread message
Arnie Shore
Aug 10, 2012, 9:41:06 AM8/10/12
to mil...@googlegroups.com
Guys , a retired mil ex-mil here, who lurks enjoying discussions re
OSS applications suitable to the civ world.
My own contribution to OSS is in the Tickets CAD project, a free OS
Computer-Aided-Dispatch application, oriented to use by teams who lack
the budget that the larger municipalities, etc., have for commercial
CAD's, as well as by teams of vollies of course. (The term CAD here
is widely used in the civilian emergency response world, so I use it
here despite its ambiguity.)
Now it struck me that - scale aside for the moment - CPOF battle
management concepts might apply to dispatch management. Like,
incidents === bad guys, response teams === good guys, facilities ===
depots, and so many issues are common between battle management and
dispatch/response management.
The few CPOF screen shots I saw were remarkably consistent with our
CAD application. Which, on reflection, is hardly a surprise, since
the situation information being presented requires maps and tabular
data for use in an almost real-time 24x7 operation with important
hierarchical considerations. Situational awareness, essentially.
I wd dearly love to be able to introduce the benefits of CPOF work
being done into the world of CAD. But - per Wikipedia - much of CPOF
is proprietary, and classification issues are involved, I expect. So,
I'll appreciate any suggestions re available open information sources,
including any open source work being done in this fascinating niche
application area.
Worth a mention here is my observation that military retirees often
find second careers in local emergency response. A familiar UI could
be a significant boon in so many ways. Thanks, all!
OSS applications suitable to the civ world.
My own contribution to OSS is in the Tickets CAD project, a free OS
Computer-Aided-Dispatch application, oriented to use by teams who lack
the budget that the larger municipalities, etc., have for commercial
CAD's, as well as by teams of vollies of course. (The term CAD here
is widely used in the civilian emergency response world, so I use it
here despite its ambiguity.)
Now it struck me that - scale aside for the moment - CPOF battle
management concepts might apply to dispatch management. Like,
incidents === bad guys, response teams === good guys, facilities ===
depots, and so many issues are common between battle management and
dispatch/response management.
The few CPOF screen shots I saw were remarkably consistent with our
CAD application. Which, on reflection, is hardly a surprise, since
the situation information being presented requires maps and tabular
data for use in an almost real-time 24x7 operation with important
hierarchical considerations. Situational awareness, essentially.
I wd dearly love to be able to introduce the benefits of CPOF work
being done into the world of CAD. But - per Wikipedia - much of CPOF
is proprietary, and classification issues are involved, I expect. So,
I'll appreciate any suggestions re available open information sources,
including any open source work being done in this fascinating niche
application area.
Worth a mention here is my observation that military retirees often
find second careers in local emergency response. A familiar UI could
be a significant boon in so many ways. Thanks, all!
James Neushul
Aug 10, 2012, 2:26:03 PM8/10/12
to mil...@googlegroups.com
Arnie,
Would love to see what you have, CPOF is in fact absolute unmitigated drek - ad not worth a moment of your time. It is in fact known as "Command Post of the Foolish" because it was fielded with capabilities that were obsolete - let alone not "of the future." I was in Iraq in 2007 with 2003 maps because of CPOF.
We all know that Google Earth delivers geodesy data over remarkably small pipes to everyone in the world. CPOF - invented after Google Earth - requires manually loaded maps, Because there aren't enough contractors (and we have paid for enough to build CPOF 50 times over) to fly all over any theater and update the maps manually - all maps are (uniformly) dated. This idiocy remains in effect in Afghanistan.
This is just the beginning .. there are the incompatibilities with message formats which has operators hand jamming data from one system to the other - and of course the ridonculous footprint of the servers, These shortfalls haven't been fixed and won't be - becuase of the nature of closed source software and because of the "Ron White Principle" which is that "You can't fix stupid."
CPOF was invented by DARPA in an effort that can be considered neither "Advanced" nor "Research" - and in fact belongs to the DOD in accordance with the FAR. It is supported and delivered by the Vendor (General Dynamics) on CDs (remember those) - usually by a contractor who has to be paid - and it continues to cost us millions. Another small point of issue on the "foolish" moniker.
CPOF is a big reason why we started MIL-OSS. Please - don't try to fix it - just REPLACE it with relevant open source code. The bar is not that stinkin' high.
Cheers!
Neutron
Would love to see what you have, CPOF is in fact absolute unmitigated drek - ad not worth a moment of your time. It is in fact known as "Command Post of the Foolish" because it was fielded with capabilities that were obsolete - let alone not "of the future." I was in Iraq in 2007 with 2003 maps because of CPOF.
We all know that Google Earth delivers geodesy data over remarkably small pipes to everyone in the world. CPOF - invented after Google Earth - requires manually loaded maps, Because there aren't enough contractors (and we have paid for enough to build CPOF 50 times over) to fly all over any theater and update the maps manually - all maps are (uniformly) dated. This idiocy remains in effect in Afghanistan.
This is just the beginning .. there are the incompatibilities with message formats which has operators hand jamming data from one system to the other - and of course the ridonculous footprint of the servers, These shortfalls haven't been fixed and won't be - becuase of the nature of closed source software and because of the "Ron White Principle" which is that "You can't fix stupid."
CPOF was invented by DARPA in an effort that can be considered neither "Advanced" nor "Research" - and in fact belongs to the DOD in accordance with the FAR. It is supported and delivered by the Vendor (General Dynamics) on CDs (remember those) - usually by a contractor who has to be paid - and it continues to cost us millions. Another small point of issue on the "foolish" moniker.
CPOF is a big reason why we started MIL-OSS. Please - don't try to fix it - just REPLACE it with relevant open source code. The bar is not that stinkin' high.
Cheers!
Neutron
--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com
To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
www.mil-oss.org
Scott Clark
Aug 13, 2012, 8:48:57 AM8/13/12
to mil...@googlegroups.com
Arnie,
I'd like to see what you have as well. I've worked on projects that have dealt with both C2 and with CAD. CPOF isn't where you'd want to start. While the front-end has layers that are familiar, the rest of the system is a far cry from what you'd want. Some reasons are already stated. Others include the fact that it's also built on its own data model, and that it's used for much different functionality than you'd want in a CAD. Something far better could be designed with current technology and with some of the advances we're making in projects now with spatial technology, it would be a huge leap beyond the current systems without getting too complicated.
Scott
Arnie Shore
Aug 13, 2012, 10:31:15 AM8/13/12
to mil...@googlegroups.com
Scott/all, sent previously via private channel:
WRT seeing what we have, I don't wanna even hint that what we have
might be useful on the battlefield - and believe me that there's no
false modesty involved. CAD-wise, I'm satisfied that our data model
is mebbe 75% of where it shd go. It's the UI that deserves some
attention, however, and that's where I thought a peek at CPOF might
help me with ideas. As a minimum Tickets needs sortable tables,
draggable windows, multi-monitor operation, etc., etc. (We have a
move in progress to open map imagery from the current Google maps.)
(Nonetheless, there's a guest login at
http://www.kolshalomannapolis.org/ticketscad)
FYI, my mil/tech background started with the SAGE air defense system
of the 50's (I kid you not!), the Pentagon Telecomm's Center
consolidation in the 70's - I can parse a JANAP 128 message
blindfolded - the Washington-Moscow hotline also of that era, etc.,
etc. So I'm responsive to the special needs/requirements of the
military.
Which is why I'd love to play some kind of role in any effort underway.
I'll be hanging out below the radar on this topic, but with audio
sensors crazy active. I'd love to hear about any real OSS work re
battle management applications, but I expect there's no real room for
a vollie on such an effort. Still, ... .
AS
WRT seeing what we have, I don't wanna even hint that what we have
might be useful on the battlefield - and believe me that there's no
false modesty involved. CAD-wise, I'm satisfied that our data model
is mebbe 75% of where it shd go. It's the UI that deserves some
attention, however, and that's where I thought a peek at CPOF might
help me with ideas. As a minimum Tickets needs sortable tables,
draggable windows, multi-monitor operation, etc., etc. (We have a
move in progress to open map imagery from the current Google maps.)
(Nonetheless, there's a guest login at
http://www.kolshalomannapolis.org/ticketscad)
FYI, my mil/tech background started with the SAGE air defense system
of the 50's (I kid you not!), the Pentagon Telecomm's Center
consolidation in the 70's - I can parse a JANAP 128 message
blindfolded - the Washington-Moscow hotline also of that era, etc.,
etc. So I'm responsive to the special needs/requirements of the
military.
Which is why I'd love to play some kind of role in any effort underway.
I'll be hanging out below the radar on this topic, but with audio
sensors crazy active. I'd love to hear about any real OSS work re
battle management applications, but I expect there's no real room for
a vollie on such an effort. Still, ... .
AS
T Slick
Aug 13, 2012, 2:01:30 PM8/13/12
to mil...@googlegroups.com
A.Shore a few things for you.
1) While CoMotion (the engine that runs CPOF is propertierty) the application is Govt rights and Tactical Mission Command has developed a CPOF third party development kit when anyone can write and/or read from a CPOF repository using web services. Command Web is a product that takes advantage of 3PDK. Recommend contacting PM-BC and the Army could provide you with the tools you would like to expeiment with CPOF.
This a good brief on the Concepts behind CoMotion
Here are a few examples of other orgnizations using the CoMotion Engine to visualize other products.
IRT to Neutron - CPOF is now FOC and is soley supported by Govt orgnizations if requests for CPOF support is needed by the Army the user can Contact Tactical Mission Command and if it is requested by the USMC then Marine Corps Tactical Systems Support Activity, Communication Training Centers or MAGTF Integrated System Training Center provides support. GDC4S is no longer involved with USMC support of CPOF or the Combat Operations Center.
"there are the incompatibilities with message formats which has operators hand jamming data from one system to the other"
This is no longer the case CPOF is interoperable with all systems within the ABCS architecture as well as C2PC the issue was with PASS/DDS configuration.
" - and of course the ridonculous footprint of the servers - "
The CPOF server stack is virtulized and can be hosted on one 64bit server with 32 Gigs of RAM. Every system that interfaces with the PASS/DDS has a mediation server or service it is just that most training doesn't include instructions on use. (CPOF = Databridge, C2PC=JDH, JADOCS=PCI, AFATDS=RAAS/EMT).
TSlick
Kit Plummer
Aug 13, 2012, 2:08:07 PM8/13/12
to mil...@googlegroups.com
There's your problem. 32G of RAM? Holy mother of Java Batman! Any idea what that'd cost you in EC2 to run? :)
T Slick
Aug 13, 2012, 2:14:12 PM8/13/12
to mil...@googlegroups.com
That's 32Gigs for the entire architecture. Which is multiple services separated into different VMs
James Neushul
Aug 14, 2012, 5:23:50 PM8/14/12
to mil...@googlegroups.com
TSlick,
Thanks for the update ..
Closed source software relies on the "SDK" approach to get people to increase the value - and degree of lock in - of a proprietary product but expending resources on something that they can never own.
In this case the "owners" of CPOF are civilians in the DOD who are not required to provide source code or access to other parts of the DOD because the code is not open source. This is the "rice bowl" behavior that closed source software creates within the DOD - and is what I believe represents waste and abuse.
The code is bought and paid for by DOD. Why isn't it Open Source? Because we are own own worst enemy.
Free software - as in freedom - allows full ownership. USG clearly doesn't have it in this case. I am fairly certain that GD owns CoMotion and gets paid for every copy fielded
As for CPOF message interoperability - It cannot be achieved with a "bridge" because the systems have different data and perform different functions. Marines are still hand jamming because they use one system operationally - but are required to report at higher levels using another.
The problem could be solved with a CPOF plugin in C2PC - or a C2PC plugin in CPOF (or better yet a web service that just does the super simple thing that they use it for) to provide the different functionality in either but this can't be done because both products are closed source and jealously guarded by their rice bowl stakeholders..
For perspective - the majority of people in the fight just need decent maps and only make a few very basic reports on a consistent basis. This can be provided with a decent web service - but instead we field bloatware that is jury rigged with "bridges" that most often nobody can figure out wthout extensive "training" - which is a whole new discussion about good money after bad.
I don't mean to shoot the messenger - or even continue an argument about a system that is not OSS and thus not relevant for this forum - or in my opinion for anything except government waste. As you might guess - my experiences with CPOF and C2PC have been so bad as to make me irreparably jaded.
Most people in the trenches on these projects - perhaps including you TSlick - mean well and are hardworking and dedicated to supporting the war fighter. In most cases they have no control over licensing or support decisions and are just trying to work in the system that they are in.
One of the goals of MIL-OSS is to free our programmers from these bad decisions and allow them to leverage the collaborative resources that exist.
Semper Fidelis,
Neutron
Thanks for the update ..
Closed source software relies on the "SDK" approach to get people to increase the value - and degree of lock in - of a proprietary product but expending resources on something that they can never own.
In this case the "owners" of CPOF are civilians in the DOD who are not required to provide source code or access to other parts of the DOD because the code is not open source. This is the "rice bowl" behavior that closed source software creates within the DOD - and is what I believe represents waste and abuse.
The code is bought and paid for by DOD. Why isn't it Open Source? Because we are own own worst enemy.
Free software - as in freedom - allows full ownership. USG clearly doesn't have it in this case. I am fairly certain that GD owns CoMotion and gets paid for every copy fielded
As for CPOF message interoperability - It cannot be achieved with a "bridge" because the systems have different data and perform different functions. Marines are still hand jamming because they use one system operationally - but are required to report at higher levels using another.
The problem could be solved with a CPOF plugin in C2PC - or a C2PC plugin in CPOF (or better yet a web service that just does the super simple thing that they use it for) to provide the different functionality in either but this can't be done because both products are closed source and jealously guarded by their rice bowl stakeholders..
For perspective - the majority of people in the fight just need decent maps and only make a few very basic reports on a consistent basis. This can be provided with a decent web service - but instead we field bloatware that is jury rigged with "bridges" that most often nobody can figure out wthout extensive "training" - which is a whole new discussion about good money after bad.
I don't mean to shoot the messenger - or even continue an argument about a system that is not OSS and thus not relevant for this forum - or in my opinion for anything except government waste. As you might guess - my experiences with CPOF and C2PC have been so bad as to make me irreparably jaded.
Most people in the trenches on these projects - perhaps including you TSlick - mean well and are hardworking and dedicated to supporting the war fighter. In most cases they have no control over licensing or support decisions and are just trying to work in the system that they are in.
One of the goals of MIL-OSS is to free our programmers from these bad decisions and allow them to leverage the collaborative resources that exist.
Semper Fidelis,
Neutron
Reply all
Reply to author
Forward
0 new messages