This started out as a brief essay that I (MKSheppard) wrote up based on a discussion I had with Stuart at HPCAthon 2007 in Dayton, Ohio, which was then greatly expanded by Stuart to clarify some points.
------------------------------------------------
The original question from Ace Pace on SDN which started this Essay was:
By the way, ask Stuart about how the usage of consumer electronics with enough processing power to do military tasks influences things, now that a simple home computer has enough processing power to run map boards with advanced displays, is that utilized.
COTS
Over the years there have been a number of military acronyms that seemed like good ideas at the time and turned out to be anything but. One is TPP (Total Package Procurement – meaning that a single contractor was given a contract to design and build all the equipment in a given program), another is COTS (Commercial-Off-The-Shelf – the procurement of civilian standard equipment to perform military functions in place of dedicated military systems). COTS came about because it was becoming apparent that many items of equipment, especially computers, were cheaper and more advanced in the civilian market than the ones available via military sources. So, why not buy the civilian ones? Sounded like it made a lot of sense – and for some applications it does. There is no reason for a computer that sits in an office and never sees a battlefield to be built to military standards. Or is there?
Anyway, during the 1990s, there was a major effort to move to COTS equipment where applicable. This had some immediate and very marked advantages. Tactical plots that used advanced displays all benefited greatly from the move to COTS. So did some forms of administrative functions. However, the problem that first emerged on the scene was a psychological one; because COTS seemed like a good idea a great deal of pressure started to be generated to apply COTS in areas where it was not appropriate. A parallel can be drawn with Stealth technology here; another good idea for some applications that became a buzz-word and started to be used for areas where it was not appropriate. It quickly became a requirement to claim extensive use of COTS even though the concept might not be appropriate to the application. This equally quickly resulted in a situation where a project proposal was at a disadvantage if it didn’t employ COTS.
It was about at that point that the problems with COTS became apparent. The first to emerge was the matter of obsolescence. Commercial computer equipment had a front-line marketing life of a few months; after a few years it became unsupportable and had to be replaced. The situation with COTS based equipment was that it was in a continuous state of flux. A system that had been designed around the use of, say US$5 million worth of advanced civilian-standard gear, would, in five years, see that gear becoming completely obsolete as civilian standards moved on. Worse, the manufacturers ceased to support that equipment (try getting Microsoft to support Windows 3.11 now and you’ll see what I mean) so it had to be replaced. Thus, while COTS saved money in the short term, it flunked badly in the long term. The cost savings proved to be largely illusory.
You can see this by how the F-22 has had to have it's electronics systems pretty much completely replaced during the development cycle as the "top state of the art" electronics became obsolete during it's development, and had to be replaced with newer stuff, since the old stuff wasn't made anymore.
Of course, we’re working for the military here, cost doesn’t actually mean that much, its performance that counts. Here, COTS gear seemed to have a marvelous edge – when the civilian world was playing with 512GHz Pentium IIIs, the military were still using the equivalent of 386s and 486s. Surely it was worth paying the extra for all that added performance?
That’s where the real problem with COTS started. Firstly, that sparkling performance in the civilian sector didn’t carry over to the military sphere. It sound trite but the military and civilian environments are different. One of the problems was that the computer networks used in civilian life are pretty simple compared with their military equivalents. Once civilian-standard computers were placed in military networks, they slowed down a lot. This was absolutely critical because what those networks were being used for was maintaining a tactical plot. That plot has to be accurate and real-time. If you have a nuclear-tipped anti-ship missile coming straight at you, a tactical plot that shows the situation five seconds ago is remarkably useless.
This problem hit all the great electronic systems in the 1990s. None of them worked; they all had terrible systems integration problems. The most publicized was that of the Collins Class submarines in Australia (its best-known not because the situation was worse with them but because the Australian Government made a very honest report on it). All those systems took a lot of time to get working properly.
Another problem was software bloat. The commercial computers ran commercial software – they had to, their cost advantage was based on exactly that. Unfortunately, this software included lots of things that weren’t needed and a plethora of add-ons that got in the way. For example, do we really want our ops room crew playing Solitaire or Minesweeper? More importantly, this mass of software had to be integrated with the systems on the ship – for example the engine room controls and weapons systems.
A tale from the crypt for you. There was a program called Smartship that essentially was based around the large-scale integration of COTS into an AEGIS cruiser to bring about great increases in efficiency and combat power. The test ship was USS Yorktown. Now, she was out one day and everything was just peachy until the ship stopped working. I mean she went completely dead and nothing anybody could do could get her started again. There was much playing with the system and much pounding of keyboards yet nothing happened. Eventually Yorktown was towed back into port, tied up alongside and the arrival of a Tiger Team expected.
Fast forward a few hours – to midnight to be precise. Very precise. An Ensign is on the bridge alone, on Cold Iron watch, probably reading a good book. Then, at the stroke of midnight, the ship comes to life. The bridge lights up, the systems activate, the engines start up. To our panic-stricken Ensign, the whole ship is starting to come alive. Then, the ship starts to back up. She rips her mooring lines out and sets off across the bay. Our Ensign is on a 10,000 ton cruiser that is veering backwards and out of control, across the harbor, straight towards a VLCC. “Oh dear, this does not look good” quothe the Ensign who, by a miracle, manages to avert disaster.
What had happened was that some of the coding in the Windows program clashed with coding elsewhere and locked the whole system. All the orders that were being put in when the efforts to get the system running went into the buffer and stayed there. At midnight, the system reset, the blockage was cleared and all those orders flooded through. The experience was very valuable, it became apparent that we couldn’t produce a Frankenstein system that used some commercial, some military software. We had to have everything more or less done from scratch. Which is why all those systems were years late and way over budget.
Datalinks
Other problems became apparent. One is that the density of electronic systems in military use. This particularly applies to datalinks where a ship may have dozens of the things operating in close proximity. The commercial systems interfered with each other, they interacted in ways that lost a lot of data and their capacity was limited. In civilian use, they were quite adequate but it military use, their bandwidth was hopelessly wanting. The problem was that civilian systems gained capacity by extensive use of data compression algorithms and this approach didn’t work so well in the military environment.
The problem is that gains in compression algorithms et al do not equate to massive leaps in the amount of bandwidth available; since you still have to buffer and heavily repeat data; so that you are assured that what you're sending will get to your intended destination. Having to heavily error correct the data slows down the overall system; while the entire system is feasible on a small scale; it does not scale up very well to large scale situations, since you will rapidly overload the system with data, and a backlog of transmitted data forms up.
Once again, the effect was that the system then progressively becomes further and further behind real time, since the data link is only able to transmit x amount of data *reliably* each second, and more and more data will be coming in every second, forming a data backlog and jamming the data pipe solid. However, it’s even worse than just the system slowing down drastically. As the flow of data through the system becomes congested, it becomes turbulent and the data packages start to eliminate each other. So data is irretrievably lost and nobody knows that its lost. That’s why we get tales now and then of an aircraft flying around over an air defense site and the command system insists it isn’t there.
It gets worse as you add more and more layers of C3I or data hops into the system, as your error correction requirements go dramatically up. Instead of only having to error correct a single hop between say, a platoon commander and the company commander, you now have to error correct multiple hops; which will require even more data throughput to be taken up for error correction, choking the system.
And even with all the error correction, with each hop added to the net, the chance of an error sneaking into the system goes up; and in a military operation, such things can be bad. Like for example, you told your UAV to turn right, but instead somewhere along the way the signal got garbled into "turn left", and the UAV went left. You're now behind the curve, and as more time passes, your data becomes more and more behind the curve, until the whole thing just ends up having no relationship to reality at all.
Traditionally, with the employment of widespread communications links in the military, they have generally occurred at the higher headquarters level; where all the data flowing in from the component units is looked at and some sense is made of it before it is reported back to higher HQs. With a highly integrated system, you open yourselves to a lot of false positives and stuff that has no relationship to reality whatsoever, now that the average grunt can now relay every single movement he *thinks* he saw. Remember, people see what they want to see; I suggest you look up the "Battle of the Blips" in the Aleutians Campaign of WW2; a US Navy taskforce detected some blips on radar, assumed it was a Japanese task force, and engaged it. Multiple lookouts on multiple ships reported all kinds of things, from cruisers burning to torpedo wakes incoming; when none of it existed at all; except as a glitch in the radar.
Another problem with this whole area is one of security. Typewriters and computers are almost by definition not secure. They emit electronic signals that can be read a considerable distance away from the source. Military systems are carefully shielded against such emissions (the standard is called Tempest), civilian systems are not. Modifying equipment to meet with Tempest standards essentially means a new system. In this context, security doesn’t just mean the enemy can listen in (or, even worse gain access), it also means that the stray electronic signals are so dense that they can adversely affect the systems in question.
Summary
One of the signature characteristics of COTS systems is that they work very well when the environment is small and simple; however, adding extra layers means it folds up very fast. This has been experienced with some of the “digitalized battlefield” systems. They work well when (say) using a platoon of tanks, but take that up to battalion level and the system falls apart. This appears to be an insoluble problem; none of these “system of systems” concepts works worth a damn.
What is happening now is the military system makers are getting much better at incorporating technology developed for the civilian sector into military systems. One amusing side effect of that is that more and more civilian systems have military characteristics built into them from the start (for example surge protection that can handle EMP from nuclear initiations, anti-emission standards that comply with Tempest). So, its not so much that civilian consumer electronics are finding their way to the military sector so much as the two sectors are converging to produce equipment that’s suitable for both.