[erlang-questions] Erlang based C2ISR system
Mon Feb 23 06:44:44 CET 2015
Thanks for the input Miles.
Do we have any implementation for fuselets or Jopes DIS/HLA etc in Erlang
On Sun, Feb 22, 2015 at 1:45 AM, Miles Fidelman <mfidelman@REDACTED>
> 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
>> against a different combination of language/platform/environment
>> 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
>> 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
>> 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
>> 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
>> single system is completely different from every other system (and
>> that itself
>> is a product of the nature of acquisitions within large
>> 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
>> random memoranda about authorized holster models, etc.), so the
>> 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.
> Miles Fidelman
> In theory, there is no difference between theory and practice.
> In practice, there is. .... Yogi Berra
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions