Slashdot Mirror
Linux And Innovative Simulations
cameronhunt writes "This article (shameless plug alert - I'm quoted in it) presents a growing trend of integrating simulated and live training in the military - often using Linux and Open Source methods, standards, and protocols. This trend isn't just in the military, but increasingly found everywhere from games to everyday life. I'll be talking more about this at LinuxWorld."
4 comments in one:
1. Why Linux?
True, the eetimes article is discombobulated and provides little explanation of why Linux should matter at all for wargaming simulations. And the explanation it implies (that Linux helps data compatibility) is nonsensical.
However, I've seen several military simulation projects that run on Linux. The obvious reasons: The Pentagon isn't a fast or flexible software developer. These games may take decades of to produce and shape into something workable, and we can't throw them out just because new OSes (Windows XP, etc) come along.
So many projects that were first written for big iron SGI or Solaris machines are now running on Linux desktops. I've heard several ancedotes of software getting a 5x speed boost alongside a 10x drop in platform cost when changing hardware vendors from SGI to Dell.
One major simulation project is OneSAF ("One Semi-Automated Force"). You can go read the PowerPoint they gave at a Linux conference years ago. (The "CCTT" project mentioned in the article is an ancient fork of OneSAF)
2. 100 entities is small
The article says they will be reaching the point of simulating 100 entities in their exercise, up from 20 in the previous test. And it'll take place at 3 different locations.
That is tiny compared to the number already used in a military simulation last year. Millenium Challenge 2002 took place on ~15 sites around the US, and involved 13500 human participants, many of them controlling more than one "entity" in the game.
3. The Pentagon is trending back towards DIS
The article mentions this project is using the IEEE 1278 standard DIS (Distributed Interactive Simulation). That is a fairly old specification- finalized at least 10 years ago. It worked well back then, and still does. However, it fell out of popular use in the late 90s because a vantity project from Defense Modeling & Simulation Office mandated that all simulations be switched to use their new improved HLA infrastructure, which is IEEE 1516.
The HLA was a traditional example of Fred Brook's Second-System effect. That is, when a person first makes a project of a certain type, he will be conservative and careful to make something that works and he can understand. (In this case, the DIS protocol). But once the first system works well, programmers tend to get overconfident and decide to fill the second system will all manner of elaborate stuff that distracts from the real purpose. That is what happened with the HLA protocol.
HLA is a real kitchen-sink system, addressing all uses but satsifying none. Only in the past year has DMSO's political power been reduced so that wargame developers can stop using the bad, unpredictable HLA and get back to the clean, efficient, and comprehensible DIS.
4. HLA does have one advantage over DIS
The DIS protocol is a global publication system. Each computer controlling simulated entities broadcasts their position to ever other computer. (Originally this used ethernet broadcast, now it might change to internet multicast UDP). That meant that in a large exercise, people out-of-range from each other would still recieve positional updates clogging their network card. HLA included specifications to describe, geographically, who should recieve which packets. This allowed for world-spanning scenarios to be played with thousands of vehicles spread around.
The article suggests that new projects (DFIRST? I haven't heard of that before) will bring some of this capability to DIS.