One of the most shameless myths created and perpetuated by the entertainment industry is the notion that military computers are somehow much more powerful and "hi-tech" than those employed by the industry at large.

Nothing could be further from the truth, and with the exception of a handful of highly specialised digital signal processing systems, most computers employed in military systems are one, two, three or even four generations behind in technology, in comparison with their commercial cousins.

In this month's feature we will explore the specialised and in many respects very different world of military computers.

A Different World?

To attempt to attach a simple label to a military computer, and generalise its attributes, is about as futile as attempting to do the same for commercial computers.

Computers used by the military can however be broadly divided by the type of operating environment they must accommodate, and it is the environmental constraints which indeed turn out to be the most important differences between military and commercial computers.

The first category of computers used in the military are basic fixed base support machines, used for admin and bean counting purposes, in essentially standard office environments. Such machines are no different from their commercial cousins, although often they must meet electromagnetic emission requirements such as the US NACSIM 5100 TEMPEST standard. While the machine might be a very ordinary PC, server or workstation, it cannot be allowed to leak Van Eck radiation from the monitor, or eavesdroppable emissions from is LAN and serial interfaces. So the quartermaster's PC will probably be identical to the machine on your desk, but the spook's machine, or HQ wordprocessor, is likely to be the more expensive TEMPEST model.

The next step up the hierarchy of environmental resilience is the "ruggedised" military computer. A ruggedised machine is a hybrid of commercial grade electronic hardware, packaged in a Milspec or Military Standard (Mil-Std- in the US, STANAG in Europe) casing or chassis. The chassis will be made to comply with one or more military environmental standards. Such machines are deployed in the field, or used in "undemanding" airborne, land-mobile or naval environments.

Finally, we have military embedded computers, designed form the ground up to survive in harsh environments, and fully compliant with the full gamut of military reliability standards. These are the processors which are installed in satellites, fighter planes, missiles, torpedoes, smart bombs and other military equipment. Such machines may implement commercial, or specialised military instruction sets.

Reliability and Milspecs

The military reliability standards were developed by the US DoD during the fifties and sixties, in an attempt to produce standard engineering guidelines for the construction of equipment, electronic and mechanical, which could provide known and predictable reliability performance in harsh temperature, humidity, shock, vibration and radiation environments, and would employ standard interfaces and component packaging.

The genesis of the US DoD MilSpec system lies in the WW II experience, when the US ramped up its even then massive industrial base for the construction of war material. One of the immediate difficulties experienced was standardisation, since specific pieces of equipment were essentially proprietary products and thus components were not frequently interchangeable between different maker's equipment, a major issue if you are stranded in Woop Woop, with two remaining radios within the perimeter, and bloodthirsty enemy soldiers trying to overrun you. The other difficulty experienced was with achieving predictable reliability in what were becoming increasing complex pieces of equipment. Could you afford to sortie a dozen fighters on a mission, and have half of then turn back enroute since various bits and pieces stop working along the way ? A final and no less important issue was providing a common benchmark for the enormous subcontractor base to work to, so if prime contractor X wants to build a tank, bomber or battleship, he can easily specify to a subcontractor the design and test specifications for the nut and bolts, or other components to be purchased.

Many standards now regarded as common in the computer hardware industry, such as the JEDEC chip packaging scheme, are essentially US military standards.

The US MilSpec standards are enormous, by any measure, and rival or exceed in complexity many if not most industrial specification and standardisation schemes. Any standard you can contemplate, a MilSpec probably exists for it, produced at some stage during the last forty years. Whether it is gasoline, hose fittings, paint composition, chip packaging, or machine instruction set, there is a Milspec for it.

The MilSpecs which are most important from a general computer industry perspective are those which cover the areas of component packaging, and reliability vs operating environment.

Reliability in the most fundamental of terms is defined as the equipment's probability of survival, i.e. ability to continue working, as a function of time spent in a given operating environment. Reliability is measured in terms of Mean Time Between Failure (MTBF), or simply the statistical average of time between hardware faults accumulated over a very large population of equipment items.

The central mathematical premise behind most reliability theory, and the US MilSpec system, is a little known theorem called Lusser's Product Law, which states that in a serial system, where the failure of any component results in the failure of the equipment item, the probability of survival P[survival] of the equipment is the product of the probabilities of survival of each component.

Robert Lusser was one of Werner von Braun's rocket scientists on the V2 project, which in its early days was plagued by incessant failures, on the launch pad or in flight. Perplexed with their inability to get the missile working properly, Lusser consulted Erich Pieruschka, one of the mathematicians on the project, about why they could not get it to work. Once they applied some basic probability theory to the problem, it all became very obvious, and thus Lusser's Product Law was born. Needless to say, everything else is now history, and the deluge of Scud like V2 rockets which landed on the UK in late 1944 was the proof of the pudding.

If we know the reliability numbers, ie probability of survival, for each and every component in a complex system, we can then calculate the reliability of the system. Or conversely, if we need a system to have a certain reliability, we can calculate in turn the required reliabilities for all of the bits and pieces which make up the system.

Determining the reliability of an electronic component can be an expensive and time consuming chore, and indeed this is one of the underlying reasons why modern military equipment is often worth its weight in gold, or more !

To understand why, it is helpful to digress a little into failure mechanisms in electronic components, an area which like basic reliability theory, is most sadly not taught in most Australian university engineering and computer science courses. Since we invest most of our engineering and comp sci talent into supporting equipment rather than designing it, this is all the more an incongruity in the scheme of things.

Electrical failures in components result typically from dielectric breakdowns in insulators, mechanical open and short circuits, migration effects in semiconductor PN junctions, and migration effects in metal. To this we can also add the insidious effects of corrosion in materials.

Without delving too deeply into the materials science behind these effects, we can state that all of these phenomena are accelerated in effect either by shock, vibration, temperature, temperature changes, humidity, and the presence of corrosive agents such as salt or chemicals left over from production processes.

Temperature alone can be destructive since it accelerates the diffusion of dopants in semiconductors, and this over a period of time will result in semiconductor junction dopant gradients, the reason why transistors work in the first place, flattening out to the point where the junction ceases to be a junction and the component fails. High temperatures also accelerate the migration of metal between connections or chips, causing eventual short circuits.

Temperature changes cause mechanical expansion and contraction which causes all manner of turmoil, from printed circuit board delamination, through hole and via connections shearing off, to pins on packages or connectors developing metal fatigue.

Vibration and shock cause straight mechanical failures, or metal fatigue. A particularly nasty manifestation of vibration is the excitation of flexural modes in printed circuit boards, not unlike those on your stereo system woofer.

Humidity is insidious in its effects, since it reduces the effectiveness of cooling systems, and also precipitates on components during rapid temperature changes, thereby producing an electrolyte for dissimilar metals and production residues on components, thus facilitating corrosion.

Clearly all three of these basic environmental factors, temperature/changing temperature, vibration/shock, and humidity are damaging within themselves, and also mutually supportive in impairing the reliability of any piece of equipment. This needless to say is true of commercial and military equipment. The big difference between the two contexts, is that one simply increases costs and cuts profit margins, whereas the other costs lives and loses battles. Recent examples of the latter are the failed US attempt to extract hostages from Teheran in 1979, when the use of support category rated minesweeping helicopters instead of highly reliable combat search and rescue helicopters caused a mission failure and loss of lives, or the sinking of at least one RN destroyer in the Falklands, due to a intermittently failing missile launcher.

For electronics which we wish to loft into orbit on a satellite, we can also add the wondrous effects of radiation, which increases defect density in semiconductors to the point where they eventually break down.

The simple consequence of these factors is that the harsher the environment, the less reliable any given type of component is. If we wish a component to exhibit a certain level of reliability in a very harsh temperature/vibration/humidity environment, we have no choice other than to alter its design and/or packaging to accomodate these conditions.

The harshest military environments require chips in metal can or ceramic rather than molded epoxy packages, gold plated pins on packages and connectors, no or few socketed chips, surface mounted passive components, chemically sterile manufacturing environments, and extremely tight quality control and testing.

To be really certain, once the device is made and passes its basic electrical tests, it is then stress tested at an elevated temperature to weed out the devices with incipient failures. At the end of this arduous process, we have the MilSpec rated version of whatever chip we started out with, including a hefty bundle of test reports to attest to the fact that the chip indeed meets the MilSpec in question. This is also why a MilSpec rated version of a commercially used chip costs several times more.

What the US MilSpec and NATO STANAG systems provide is a standards framework for manufacturing, testing, verifying and measuring the reliability of electronic components, and tabulated reliability data for standardised devices.

Essentially the MilSpec system divides operating environments by their degree of harshness, and provides cross reference tables which specify the failure rates of chips and passive components, depending on their environmental rating, type and operating temperature.

In this manner, a designer can calculate apriori the failure rate of a board full of chips, or a box full of boards, or a system full of boxes, knowing the MilSpec rating of the components used and the operating environment. The design engineer's bible is called Mil-Hdbk-217E, and is essentially a compilation of such tables, periodically revised to include new devices.

Because 217E is based on Lusser's product law, and a huge statistical base, it provides a very high confidence level that the end product will indeed meet specs. Reading through it can be most revealing, since it shows not only the tremendous reliability improvement of MilSpec rated devices over their commercial cousins, but also the huge statistical variance in commercial devices. An interesting side effect is that a commercially rated chip in MilSpec packaging may well be just as statistically reliable, but since it hasn't been tested as thoroughly, it must be tabulated with a much lower reliability to account for the greater variance.

The MilSpec system has been much maligned in recent years, the common accusation being that it results in "gold plated" equipment which is often several times as reliable statistically, once in service, than it was originally calculated to be. The upside however is that in service support costs are often well below calculated expectations.

Another criticism of the MilSpec system is that the accumulation of a sufficient statistical reliability database for any new component is time consuming and very expensive, since a large batch of components must be tortured to death in a cyclic test environment emulating the MilSpec environment rating. It can take months or years until sufficient data is accumulated to satisfy the statistical confidence criteria, as a result of which the MilSpec version of the commercial chip may not ship to customers until several years after commercial clients get it.

An example would be the stores management computer on the RAAF's Hornet fighters, delivered during the mid eighties. That was the period of the 386/387 combo in commercial desktop computing. The Hornet used a MilSpec rated Intel 8080 and AMD 2900 bitslice processor in this box.

The emergence of ruggedised military computing equipment is a direct reaction to this effect, since a ruggedised chassis is designed to provide a box which isolates the "soft" commercially rated components from the "harsh" military operating environment, yet still provides the user with a system which is competitive in performance and price with commercial equipment.

The drawback of ruggedised machines is size and weight, since armour plating a Pentium, SPARC, Alpha or SGI system requires a solid package of metalwork, vibration dampeners, excess cooling and a MilSpec power supply. Therefore, ruggedised is only a partial solution to the problem, but one which is often more than adequate. Systems on ships, surveillance aircraft, mobile command posts and surveillance systems, can often be implemented as ruggedised equipment, since the volumetric requirements and environment permit it.

The computers which are packaged into tanks, missiles, torpedoes, combat aircraft, guided bombs and satellites alas still have to be built from the ground up to a MilSpec rating, since the weight, volume, cooling and radiation shielding needs of commercial components are not compatible with the tight packaging and cooling environments of the system.

Interfaces, Architectures and Software

While the reliability and environmental aspects of the military environment are by far the most unique and demanding aspect of military computing, they are not the only one.

The military have developed over the last two decades a unique and somewhat idiosyncratic package of standard interfaces, architectures and software tools, especially to support embedded systems.

The origins of unique interfaces go back to the late sixties and seventies, when the US military fielded the first generation of fully digital weapon systems on ships and aircraft. At this time, the commercial computing world was firmly wedded to the proprietary interfaces which often plague us today as legacy systems. To integrate a large number of embedded digital systems into a single interoperable package, often common across several types of aircraft, missile, ship or tank, common interfaces are pretty much a requirement from the outset. So a number of standard busses were defined. The most important of these is the 1 Mbit/s Mil-Std-1553B bus, analogous in many respects to the commercial Ethernet precursors of that period.

The big difference was that the 1553B bus uses much higher signalling levels to withstand much nastier noise and interference levels, and it uses a centralised protocol model rather than a decentralised collision detection model. In real time embedded systems, response times have to be highly predictable and a collision detection bus isn't the best strategy for achieving this. The 1553B bus is today the dominant connectivity standard for military embedded systems, and is used to interconnect computers, sensors and weapons. Its drawback is poor throughput, which is often worked around by dedicating multiple busses in the equipment. Instead of a common shared bus, the main computer has multiple bus interfaces and a bus to an individual black box.

The success of the 1553B standard is attested to by the fact that it was adopted by ARINC, with modifications, for commercial avionics, and also copied by the Soviets.

Machine architectures are another area of uniqueness in military equipment, and one which has created much debate in recent years.

During the early days of digital military equipment, each black box or system was built around a Milspec implementation of what were essentially proprietary machine architectures. That meant that a commercial mini was built up to MilSpec stands, using MilSpec rated chips in Milspec ceramic or metal can packages, and tortured to MilSpec standards. The hardware therefore did what was asked of it and everybody was happy.

This blissful union of commercial machine architectures and military hardware standards did not persist for very long. Realtime embedded performance needs typically resulted in code which was initially written in Fortran, or a proprietary language, then compiled down to assembler, and the assembly code then hand tuned for maximum execution speed, resulting in huge reams of assembly code specific to the processor and system.

Very soon the military found itself embedded in a software maintenance problem of gargantuan proportions, since every tweak to the code, and every tweak to the hardware, both essential aspects of evolving military systems to match an opponent's technological moves, produced massive cost overheads. The defence contractor who produced the system had a licence to print money, in the simplest of terms.

Falling back on the true and tried methods of standardisation, the US Air Force created the PDP-11 like Mil-Std-1750A 16-bit machine instruction set for embedded computers, and the US Navy standardised on its CDC UYK-14 architecture, for ships and aircraft. Almost all US embedded systems since the late seventies have been built with these machine architectures, with the exception of specialised signal and data processors, built around DSP chips like the TMS320 series, or exotica like the i860 vector engine, or UK Transputers.

Concurrently, the USAF also standardised on the Fortran / C like JOVIAL high level language, so that across the board high level and assembly code was now standardised. In the UK, CORAL became the high level language of choice, while assembly code commonly continued to be produced in proprietary instruction sets.

This standardisation effort was a major improvement in many respects over the earlier hodgepodge of adapted commercial equipment, but many in the US DoD system considered it to be inadequate, since it still left a big split between the Air Force and Navy embedded systems, and the large number of software systems developed and run on commercial support machines. It also did not address issues such as code documentation, the lack thereof being an important piece of leverage to a contractor wishing to retain software maintenance contracts on a previously developed product.

Thus was born ADA, the favourite hate object of many in the Comp Sci community. The idea behind ADA was to produce a high level language standard to encompass all military applications, from the high speed realtime embedded systems, down to the massive equivalents to commercial systems, used for logistics and specialised databases.

Needless to say, the objectives of the ADA program were ambitious and far reaching, since the language was to combine the attributes of low level systems languages such as C and JOVIAL, number crunching languages such as Fortran, beancounting languages such as COBOL, and the then flavour of the month object oriented languages, while adding in a pedantic documentation mechanism to force the undisciplined code commenting averse programmers to do the proper thing and describe what they were actually trying to do, all of this while reducing bugginess in code through language features.

Like any racehorse designed by committee, ADA proved to be a bit of camel. The most difficult problems arose in meeting the needs of fast, tightly coded embedded systems, always running short of CPU cycles and memory. While features like object orientation and task (process) rendezvous provided wonderful means of simplifying embedded code design, the first generation of compilers usually managed to be language standard compliant, but too slow and memory hungry, or fast and tight enough, but not compliant. Chaos ensued, and the often very heated techno-religious debate between proponents and opponents of ADA ran for many years. Even today we can occasionally see manifestations of this. Interestingly, the latest -9(X) flavour of ADA is considered by many to meet the needs of its consumers. However, the basic objective of blanket standardisation was never met.

The evolutionary trends in hardware which solidified during the eighties and early nineties revolved about replacing existing board sets in -1750A and "Yuk 14" systems with much faster, but architecturally identical boards, retaining often the existing code. Much of the in service equipment we see today, designed during the seventies and eighties, and incrementally upgraded in between, still runs JOVIAL, CORAL, Fortran, assembler, C, C++ and whatever language of convenience managed to slip past the ADA "regulators", through waivers approved to meet th pressures of then time schedules.

So today we have a tower of Babel in military computing, revolving about a mix of commercial and military standard machine instruction sets, board layouts, busses, new and old military language standards, and flavour of the month commercial standards.

The Future ?

The existing 16-bit military machine standards which have been pretty much mandatory in embedded systems are now three to four generations behind the current state of the art in commercial machines. In many instances this has proven to be irrelevant, since a flight control system or missile guidance package at most requires doubling, tripling or quadrupling of its compute performance over the life of the host system, to accommodate growth in the code it hosts. Thus the result has been the emergence of specialised manufacturers such as Performance Semiconductor or CPU Technology, who produce MilSpec rated -1750A chips, ROMed microcode and all, with improved clock speeds, year by year. These devices are built first and foremost for extreme reliability, and the internal architecture is generally stable. An interesting deviation from this trend has been the development effort by CPU Technology to produce a superscalar instruction set compliant -1750A processor, with something close to ten times the performance of the currently standard 3-10 MIPS engines. So ships, aircraft and missiles designed in the sixties, and built during the sixties, seventies and eighties, and refitted in the meantime with -1750A based systems, will live on with new build -1750A processors.

The push to force ADA standardisation has faltered and appears to have been abandoned, with the realisation that maintaining cadres of specialised ADA cutters itself imposes a cost burden, over the use of commercially common languages. So current systems are mostly coded either in ADA, or JOVIAL, CORAL, or C and C++. Unix and Unix-like realtime operating systems are becoming increasingly common.

The biggest pressures today in military computing are cost vs performance. The cost of specialised, low production volume military chips, lagging in performance due to stringent testing needs, provides a glaring contrast against the rapid and unhindered evolution of commercial hardware, which has in the last decade transitioned from CISC to RISC, RISC to superscalar RISC, and now superscalar RISC to VLIW. The first cracks in the standardisation armour developed when the i960 and MIPS architectures were accepted as alternatives to -1750A, for embedded systems, about a decade ago. Some demanding applications even then were hosted on high performance, fully MilSpec rated VAX machines, and later Alphas.

The failure of the military to define a board level parallel bus, for backplanes and motherboards, compounded the difficulties in hardware standardisation. So in service equipment today employs a mix of proprietary backplanes, variants of industry standards like VME and Multibus, and range of proprietary board sizes, as well as the sole MilSpec SEM standard for board form factors.

Internal system bandwidth requirements for equipment such as radars, electronic warfare equipment, optical equipment and weapons management systems have outstripped the capacity of the ubiquitous -1553B bus, no differently than has occurred with its commercial cousin, the 10 Base X Ethernet.

Wherein lies the future for military computing ? Several interesting trends are evident at this time.

The first trend in high density embedded systems is a away from the seventies "federated system architecture" model in which a central CPU controlled a package of variously intelligent black boxes in various parts of the system. The current trend, typified by the US F-22 fighter and its Central Integrated Processor (CIP), is to go for a large, dual redundant, multiprocessing machine with a very fast, fault tolerant backplane. Instead of doing the compute intensive chores in specialised black boxes, like radar and electronic warfare signal and data processors, all compute intensive work is concentrated in the redundant central computers. Like this, several processor boards can fail, and the compute load is simply shifted to other, working boards, in the main processor.

The mix of -1750A general purpose processors, specialised vector processors, and digital signal processing chips, all on various board shapes and sizes, and using various busses, is replaced by a model where all processing is done by a battery of identical, general purpose superscalar RISC engines, in a standard form factor on a common high speed backplane. The black boxes are "dumbed down" to their analogue components, and high speed digital to analogue, and analogue to digital converters, which interface to the central processors through high speed busses. The software maintenance effort is concentrated in the central processors, which perform all computing on the system. Compute performance upgrades are addressed by adding or replacing identical central processor boards.

The next trend is typified by the Joint Strike Fighter (JSF) development program, in which specialised internal busses are to be replaced with a MilSpec variant of the IEEE Scalable Coherent Interface (SCI). This is essentially a case of taking the fastest commercial bus standard in existence, and producing a variant robust enough to survive a MilSpec environment. In this fashion, MilSpec environmentally rated versions of bus interface chips can be used directly, or MilSpec versions of commercial SCI processor boards are used. The linear segmented bus topology of the -1553B model is replaced with a mix of rings and switches, designed to handle Gigabits/sec of data throughput.

These two trends will dominate the design of new equipment.

Equipment built around existing standards, and semi/non-standards, will remain in many instances in service for decades (the US are planning to keep their B-52s, built in the early sixties, until 2030 !). Such systems will need to be incrementally upgraded through their remaining life, to remain competitive. One approach will be newer -1750A based boards in existing semi-proprietary formats. The other is the rapidly proliferating MilSpec VME standard, essentially commercial/industrial embedded VMEbus hardware manufactured to MilSpec environmental standards. A number of manufacturers now supply MilSpec rated VME chassis, designed to fit in aircraft, armoured vehicles and ships. Depending on the environmental harshness, either fully MilSpec or industrial grade VME processor and I/O boards can be fitted. Processor architectures now available cover the Motorola/IBM PowerPC/RS-6000, Pentium, Alpha, SPARC and MIPS engines, as well as the trusty -1750A. This will allow the use of almost current commercial Silicon, as well as much reducing development time and prototyping costs. Systems can be developed, and code cut, on commercial variants of boards, while the MilSpec variant is being certified "everything-proof".

A 10 Mbit/s optical fibre variant of the -1553B bus, the -1773 bus, has been adopted and will reduce some pressure insofar as box-to-box bandwidth goes. Optical 10-Base-F and 100-Base-F Ethernet has been adopted for some systems, such as command and control aircraft and naval weapon systems.

The clear trend in supporting established military systems will be to replace specialised hardware with MilSpec variants of commercial hardware, or ruggedised commercial hardware, where ever possible.

The differences between military computing and commercial computing are profound, and as much a reflection of different functional and support needs, as much as a deeply differing history. The lessons to be learned from the last two decades of evolution in this area is that standards must be defined in a manner which can be evolved smoothly and continuously, and that excessive reliance upon specialised and closed standards is guaranteed to cost dearly. In a period where "bang-per-buck" is the driving criterion, military computing has travelled a full circle, back to it roots in MilSpec rated variants of commercial computers. History repeating itself ?