[erlang-questions] Erlang based C2ISR system
Tue Feb 17 10:05:55 CET 2015
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
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
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.
So with that anecdotal picture in mind, the search for use cases of Erlang in
C2 systems (of any kind) is either going to be extremely difficult (sifting
through thousands of one-off systems by vendors reluctant to expose their
tools), or purely academic.
Colt is doing some interesting work on an integrated C2 system for the
tactical level, but I don't think any Erlang is involved there (mostly C and
Java, from the looks of it -- I've never looked inside, though). I was leading
a project last year at a company developing a conceptually related system
which had very different origins and a different focus (The company imploded
midway through! Very frustrating!). While I was actually going to use Erlang
for the (somewhat limited) tasks that existed server-side, much of the rest of
the project code was C and Scala. A lot of what was required was either
directly dependent on unique hardware or had to run on Android, everything
required careful power usage, most of the system was peer-oriented up to a
certain layer, and Erlang just did not fit most of the roles.
More information about the erlang-questions