[erlang-questions] Erlang based C2ISR system

zxq9 zxq9@REDACTED
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
> 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.

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 mailing list