[erlang-questions] Erlang based C2ISR system

[Rizwan Khan]

Thanks for the input Miles.

Do we have any implementation for fuselets or Jopes DIS/HLA etc in Erlang
already?



Rizwan Khan



On Sun, Feb 22, 2015 at 1:45 AM, Miles Fidelman <mfidelman@REDACTED>
wrote:

> 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
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150223/efb2feb1/attachment.htm>