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
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
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
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
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
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
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
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
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
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
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
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
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
These two trends will dominate the design of new
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
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
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