[erlang-questions] Erlang based C2ISR system

[Miles Fidelman]

I think I'm going to respond with exactly the opposite conclusion. I see 
lots of use cases for Erlang in C2ISR, and am working on some of them.  
More below, in-line and at the end.....

> On Tue, Feb 17, 2015 at 9:05 AM, zxq9 <zxq9@REDACTED 
> <mailto:zxq9@REDACTED>> wrote:
>
>     On 2015年2月17日 火曜日 11:47:32 Rizwan Khan wrote:
>     > Any one knows if Erlang is being used anywhere for Command and
>     Control or
>     > ISR systems which are normally for the armed forces.
>     >
>     > I am not too sure if that would be a good fit either. May be in
>     terms for
>     > distributed computing and surely not for image processing related
>     > applications.
>
>     A somewhat long-winded response follows, much of it anecdotal. I'm
>     trying to
>     give enough background for the OP to understand the situation that
>     exists at
>     the C2 level, the tactical level, and what I have seen in a C2&T
>     project I've
>     worked on, and what I have externally observed about another very
>     similar one.
>
>     ~~~~~~
>
>     I doubt it is. In any case, of the bajillion or so supposedly
>     interoperable C2
>     systems I ever took the time to peek into, every one seemed to be
>     written
>     against a different combination of language/platform/environment
>     assumptions.
>     Whether or not Erlang is a good fit for C2 (and in many cases it
>     certainly may
>     be), it seems to have about zero mindshare within the military.
>
>     At a larger TOC there was usually a guy or section whose task it
>     was to
>     aggregate data so various folks could access it or use it -- more
>     often than
>     not, though, a TOC (whether a FOB, JSOTF, JSOTF-forward, or an
>     *actual* TOC)
>     is a blackhole for information.
>
>     In SF our 18E/F/Cs (or whoever on the team had significant
>     computer knowledge
>     and could work with the 18E) would deal with receiving, say, UAV
>     imagery
>     directly from the pilot's direct feed or (usually better) from
>     whatever laptop
>     software could talk to it, convert it to something he could send
>     over the air,
>     and relay it that way. Data from outside the team might be handled
>     the same
>     way (if there was time), but usually a one-off system existed for
>     each type of
>     asset we might be working with (like an application that handles
>     one specific
>     type of video from one particular source, an entire
>     hardware-kit-in-a-suitcase
>     for receiving P3 imagery live, a special video box with no digital
>     output so
>     we could (maybe) watch a particular feed, etc.) and very often
>     there just
>     isn't time to mess with aggregation in a useful way until long
>     after the fun
>     is over.
>
>     Of course, at the TOC, where all the folks who don't actually do
>     anything
>     operational hang out, all sorts of data is supposedly aggregated
>     -- but I've
>     seen exactly zero evidence of that in practice. I suspect that
>     roughly half
>     the blame for the blackholiness of TOCs (and other echelons beyond
>     reality in
>     general) belongs to the bureaucratic sloth that manifests in any
>     large, rigid
>     organization, and the other half probably belongs to the fact that
>     every
>     single system is completely different from every other system (and
>     that itself
>     is a product of the nature of acquisitions within large
>     bureaucracies).
>     Sorting through all the miles of piles of data that pour in to a
>     TOC after-
>     the-fact is a much lower priority than ongoing operations (or than
>     printing
>     random memoranda about authorized holster models, etc.), so the
>     monumental
>     task of untangling the digital/analog Gordian Knot appears to
>     rarely be
>     undertaken in a serious way -- at least from what I witnessed. I
>     don't think
>     there is really any way around this, though the situation could
>     certainly be a
>     bit less ridiculous.
>

Just to be clear...  here, you're really talking the ISR and data fusion 
aspects of C2ISR, not C2.  In this domain,  about the best example of 
interoperability I've seen is cursor-on-target, which is basically a 
protocol for moving information around.  Erlang is a great environment 
for writing protocol engines.

On the fusion side, AFRL used to have a neat little concept called 
"fuselets" - essentially distributed agents linked into data flow 
networks that aggregated information from multiple sources.  Like most 
distributed agent work, it was all done in Java - a horrible environment 
for this kind of thing.  We're really talking an actor formalism, which 
is what Erlang is perfect for.

On the C2 side, it's worth noting that an awful lot of stuff flows over 
Jopes - in the form of classic nntp newsgroups; and most of what passes 
for C2 is really message traffic.  Again, we're talking protocol 
activities, for which erlang ideal.

And, on a different note, I've periodically though that the distributed 
training model - synchronized copies of the same "world model,"  using 
protocols like DIS and HLA - would be a great model for a distributed 
common operating picture.  Again... protocols and protocol engines.

Cheers,

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra