The humble VMEbus is considered a little
passe in the mainstream computing market, so much so that it is
becoming a little difficult to find. Perhaps surprisingly for those in
commercial computing, the VMEbus not only continues to dominate the
industrial embedded market, but has now found a new and very lucrative
niche - avionics, space and military computing.
In this month's issue we pick up where we left off in
the November, 1998, feature and explore the technological issues and
current trends in this area.
The most appropriate starting point for any such
discussion is the environment and its unique attributes.
Avionics and
Military Computing - Why a Niche Market?
The common attribute shared by both the commercial
avionic and military computing markets is an implicit need for
ruggedness. In both of these environments, a computer can be expected
to sustain often high levels of vibration, operation over a widely
varying temperature, pressure and humidity range, and often also very
rapid changes in operating temperatures.
For a space environment, typified by a communications
satellite, we can add very nasty doses of high energy radiation, which
has a propensity to wreak havoc with semiconductors, especially high
density devices.
All three of these environments put a very high premium
on reliability. Airliners falling out of the sky, fighter planes, tanks
or submarines being destroyed in combat, or satellites failing in orbit
are all situations to be best avoided. With the increasing dependency of
such systems upon their onboard computing assets, the cost of a serious
central computer failure can be prohibitive to a user, yet by the same
token the application frequently allows enough play in cost structures
to accommodate more expensive computing hardware.
The biggest market in recent decades for hardened,
rugged or military specification computers has been military aviation.
A typical off-the-shelf USD 50M fighter plane has dozens of
microprocessors embedded in various subsystems, and typically one, two
or three "central computer" or "mission computer" boxes, which run the
main embedded system which controls and manages the aircraft and its
navigation and weapons systems, and more recently, cockpit displays.
This is now beginning to change, with the world's armies
also acquiring a taste for "digitisation". A top of the line tank,
armoured personnel carrier, or any other combat vehicle is likely to
have a digital fire control system, night vision equipment, a
sophisticated package of digital communications equipment, and more
recently networking facilities for onboard computers.
What is important for the computing industry is that air
forces typically have inventories of dozens to hundreds of aircraft, but
an army of similar relative "size" will typically have many more tanks
and armoured vehicles. Therefore we are seeing a potential tripling or
quadrupling (or more) of the established market for this category of
computing equipment. Navies with dozens or at most hundreds of ships
are a relatively modest volume consumer, compared to armies and air
forces.
Commercial airliners are also becoming increasingly
"digitised", but represent a modest market volume, compared to military
users, since a typical widebody airliner requires a small fraction of
the computing capability of a military aircraft, and such airliners are
operated in much smaller fleet sizes. The aggregate demand is in theory
more modest. However, commercial airliners often remain in service for
many decades, and an increasing trend is to retrofit them every so many
years with the latest and greatest in cockpit equipment. So this too is
a potentially large market, especially if the cost of the equipment
allows back-fits into smaller, short haul, commuter and feeder service
aircraft.
Traditionally the approach followed in the military
market was to employ standardised "military" machine instruction sets.
The two most widely used are the Mil-Std-1750A architecture, a US Air
Force standard, and the former Control Data (CDC) UYK-14/AYK-14
architecture, a US Navy standard. A typical machine of this generation
has a PDP-11-like instruction set, 16-bit datapaths, and clock speeds
of MegaHertz to tens of MegaHertz. Implementation is mostly using
either a microprocessor design, or a chipset.
Historically most such designs originated during the
latter portion of the Cold War, when defence budgets were "fat" and
custom built equipment fully compliant with the very rigorous and
somewhat gargantuan US Milspec standards suite was considered to be
fiscally acceptable. The code was usually a mix of Fortran, Jovial,
Coral, plenty of assembly code, and in the last decade increasingly
variants of ADA. Therefore equipment of this generation was expensive
to build, expensive to code for, but usually superbly reliable even in
the most harsh environments.
Such computing machinery was clearly up to the task of
running seventies and eighties technology systems, but is not keeping
up with user expectations in the late nineties. One of the attributes
of the shrunken defence budget environment of the post Cold War period
(doubters should consider that the US military is today about 1/3 the
size it was at the end of the Cold War, a pale shadow of its former
self) is that equipment is usually asked to perform many more roles than
it was originally designed for, and usually this is accommodated by
tacking more line of codes on to the original system.
With the big push toward networking up systems using
data modems and datalinks, the demand for computing cycles has grown.
With the proliferation of Milspec, high quality colour AMLCDs,
everybody wants a colour display in his cockpit or turret. As we all
know graphics guzzle compute cycles.
While this has transpired, we have seen the total size
of the military embedded software market shrink, in many instances
below a decent critical mass. As a result, we are seeing fewer and
fewer code cutters prepared to take the risk of investing in developing
"single market" skills such as coding in Jovial, assembler, ADA or
other defacto "military specials". With better bucks to be made in the
commercial commodity software market, why bother ?
So we are seeing several strongly convergent trends:
flat defence budgets, standing inventories of software intensive
equipment and systems requiring not only code maintenance, but
frequently also growth in system capabilities, a very tight and modest
market for new equipment, and the expectation that the cost of code
maintenance, code improvements and hardware support should decline. The
reliability of the hardware must not be diminished.
The trends in the coming generation of US fighter
aircraft are to go well beyond the established technology base, the
Europeans are still clinging to the computing architecture which the US
pioneered in the mid seventies and given their demonstrated reluctance
to invest in R&D this is unlikely to change in the coming decade.
The centre-piece of the US military modernisation effort
is the much maligned (and unjustifiably so, in my opinion) F-22 Raptor
fighter, a technological masterpiece of engineering which combines
stealth, supersonic cruise engines and an exceptionally powerful and new
computing architecture. While most people in the defence community are
taken by the F-22's aerodynamics, stealth and engines, the truth is
that its computing architecture is the most innovative portion of the
design.
The F-22 avionic package is completely software centred,
with signal and data processing for virtually every sensor and system
on the aircraft implemented in software. The intent was to produce a
technological chameleon, where the capabilities of many of the
aircraft's systems could be incrementally upgraded through the life of
the aircraft by writing more code and replacing existing CPU boards with
much faster boards. This is a radical departure from the seventies
technology model, in which a gaggle of hardware boxes for the various
systems and sensors were all hooked up to a small number of central CPU
boxes using 1 Mbit/s serial data busses. Each box in such a system used
its own CPU or CPUs and custom code to perform its task, resulting in a
nightmare to maintain code for.
The new approach is quite different, insofar as
equipment such as radar, radar warning receivers, and communications
are pared down to the equivalent of a dumb modem, with fast
analogue-digital and digital-analogue converters, and whatever
radio-frequency hardware is required. All signal and data processing is
performed in a pair of large Common Integrated Processor (CIP) boxes,
and high speed busses are employed to carry digital signals between the
CIPs and the aircraft's sensors.
The CIP is very interesting because it brings us back to
the VME technology base. The processing in the two CIPs is performed
either by Intel i960 CPUs, as data processors, or by high speed signal
and vector processing chipsets developed in a US DoD program. All CPUs
employ liquid cooling, the intent being to produce the highest possible
power density in the CIP boxes, and are packaged in a DoD standard SEM-E
board format. Liquid cooling is an expensive technique which in the
commercial world has been confined to IBM mainframes and Crays.
The internal bussing architecture is based upon the
JIAWG (Joint Integrated Avionics Working Group) PI-bus (Parallel
Interconnect). The PI-bus started out as an improvement on the
established 32-bit VME bus standard, but very soon evolved into a
synchronous message passing bus, thereby becoming a lot closer to newer
busses in design philosophy. The bus transceiver design is based on the
Futurebus+. The basic PI-bus clock rate is 12.5 MHz, yielding a 50
Mbyte/s burst rate, but faster versions are planned for. It is
supplemented by a serial JIAWG TM-bus (Test & Maintenance bus),
clocked at 6.25 MHz, which is used for diagnostic test functions. The
intent is for a central maintenance processor to be able to externally
test every board in the system to isolate faulty modules.
The shared main memory in the CIP is accessed via a high
speed switch, details of which are rather scarce at this time,
switching allowing for a potentially huge bandwidth in a multi-port
memory.
The drawback of the CIP/JIAWG centralised model used in
the F-22, and likely to be the basis of the future F-32/35 fighters and
Comanche stealthy scout helicopter, is that it is not very practical as
a retrofit into a piece of sixties, seventies, eighties or nineties
built technology. The overhead of completely re-implementing all of the
custom built hardware in older generation aircraft or helicopters makes
it a non-player. The tremendous advantages in hardware and software
maintainability, and potential for performance growth, cannot thus
exploited for older machinery, much of which is going to remain in
service for another one, two or even three decades.
Australia is not immune to this situation. Aussie
taxpayers have an established investment in a fleet of 72 F/A-18 Hornet
lightweight fighters, and 35 F-111 strategic bombers, which are fitted
with CDC/GD AYK-14 and IBM AP-102B Mil-Std-1750A 16-bit processors,
respectively. No differently from the US and other OECD nations, we
taxpayers face exactly the same problems in keeping these machines
competitive until their planned retirement and replacement in 2015-2020.
This is a trivial problem compared to that faced by the US, which has
inventories of seventies, eighties and nineties built fighters running
into the thousands, but still a headache for our defence planners.
Wherein lies the solution to this looming technological
horror story ? If current trends in the US are any indication, the
humble VME-bus will solve the problem.
VME to the Rescue
The VersaModule Europa (VME) bus was developed in the
early eighties to provide an environment for Motorola 68000 based
equipment in industrial automation applications. Standardised initially
as IEC 821 in Europe, later in the US as IEEE 1014-1987, the standard
has since acquired a life of its own and is now managed by the VITA
standards association.
In mainstream, Unix oriented, computing applications the
VME bus was widely used for I/O applications, particularly for high
performance SCSI and IPI bus controllers. The most commonly used formats
were the large 9U, the much smaller 6U and the half size 3U printed
circuit board sizes. The 9U board size has almost vanished these days,
and most products employ the 6U format.
With the advent of single chip SCSI controllers, and
with increasing demands on I/O bus throughput, the VME bus is now very
much an endangered species in commercial computing. Some third party
OEM suppliers can still provide VME adaptors to much faster busses like
S-bus or PCI, to accommodate integration with older, specialised
hardware.
In the industrial computing market, however, VME reigns
supreme and holds about 30% of the total market, the rest scattered
across a wide range of other standards. Therefore VME is biggest single
player, and it would appear is yet to peak out in volumes. Indeed the
biggest selling VME processor boards use later 680X0 processors, despite
the availability of much faster CPUs in VME format.
VME has spawned a range of associated standards, mainly
to work around the performance limits of the original 32-bit standard.
The VMX bus provides memory extension, the VSB bus provides for fast
serial I/O, and the VME64 standard provides a 64 bit wide datapath on
the backplane, by multiplexing otherwise unused address lines. The most
recent additions are a standard allowing for the live insertion and
extraction of boards, and the Skychannel packet switched high speed bus.
The Skychannel incorporates a high speed backplane switch which allows
for peak transfer rates of up to 320 MegaBytes/s.
As a result of this, there are a wide range of upgrade
paths possible for VME users, some of which can provide highly
competitive performance against mainstream commercial bus standards.
Therefore it is not entirely surprising that when the US
DoD started casting around for a replacement for its enormous inventory
of clunky 16-bit embedded processors, attention fell upon the VME bus.
Since every conceivable processor type and I/O board type is available,
and a robust industrial base of manufacturers exists, there would be no
issues with getting competitively priced products with very long life
cycles in the commercial marketplace.
The snag with off-the-shelf VME is that it is simply too
fragile to bolt into an aeroplane, tank or ship. This has resulted in
some serious design and development effort to remedy this limitation,
and the definition of a VME standard variant for highly harsh
environments.
Known as militarised VME (IEEE 1101.2), boards built to
this standard must employ stiffening bars to prevent vibration from
flexing the boards to failure - military board format standards like
SEM-E are about one half the size of a 6U VME board for precisely this
reason. Conduction cooling, rather than convective or forced airflow
cooling must be employed. This is required especially for aircraft,
where the huge altitude range means that conventional air cooling
simply doesn't work well enough. So instead of dumping heat into the
airflow over the boards, heat must be conducted to the chassis, where
it is dissipated by radiation, or by an external cooling system.
Other issues do remain which the industry is working to
resolve. One issue is the basic reliability of many commercial
components, which are mostly packaged in resin rather than the ceramic
or metal cans mandatory for traditional Milspec Silicon. Resin packaged
chips are attractive for vibration intensive applications since they are
much lighter than ceramic or metal, however they are cooled primarily
by conduction of heat through their leads into the printed circuit
board itself. Another issue is that of storage in humid environments,
whereby moisture can penetrate to the leads and the die and cause
failures. The current approach is to pour serious design effort into
the boards to make sure that cooling is adequate, and ensuring that
components are hermetically packaged for storage.
Packaging at a system level has also proven to be a
major issue, since most embedded avionic and military computing
hardware comes in a range of "standard" box sizes, some of which are
not the best fit for a VME bus cardcage. The avionic game, be it
military or commercial, is the most painful in this respect, since
usually the cost of redesigning an airframe avionic rack is
astronomical and frequently extremely impractical. The ideal situation
is where an established 16-bit box can be pulled out and replaced by a
new processor box, with minimal or no changes to the established wiring
harnesses in the airframe (or vehicle chassis).
At this time a number of manufacturers can supply
airborne rated VME enclosures in the avionic ATR (ARINC 404 Air
Transport Rack) series formats. Radstone in the UK can supply boxes in
the "full" or 1ATR format, or the "half" or 1/2ATR format, with built
in power supplies compatible with the 28 Volt DC or 115 Volt 400 Hz
power distribution systems used in commercial or military aircraft. A
number of US manufacturers can now also supply similar products. A
number of these chassis are tested and certified to meet the extremely
rigourous US Mil-E-5400 Class II standard, guaranteed to break any
commercial hardware. A short 1/2 ATR sized box typically fits 4-5 6U
VME boards, a short 1ATR box 8-9 6U VME boards.
Building VME boards to meet the Mil-E-5400 Class II
standard is non-trivial. Usually the starting point is an established
industrial grade board. The printed circuit board layout has to be
revised, stiffeners fitted, conductive cooling accommodated, and any
particularly fragile component types replaced with tougher equivalents.
In production, the board has to be subjected to a similar range of
torture tests to conventional Milspec hardware.
The result is a VME board suitable for harsh
environments, which is software compatible with a cheapo industrial
grade board, and uses a contemporary CPU such as a PowerPC, 680X0,
SuperSPARC, Alpha or Pentium.
Military users wedded to the Mil-Std-1750A architecture
are not left out in the cold, Lital Electronics in the US now produce a
6U VME 1750A board using the Performance Semiconductor P1750A chipset
(used in the flight controls of the RAAF's F-111s). This board exhibits
a phenomenal MTBF of 74,000 hours, and is already used in the B-52
bomber.
The most prominent VME manufacturer in this market is
DY4, who can rightfully boast with their current portfolio of clients.
DY4 VME hardware is used in the Canadian Army LAV-25 armoured vehicle,
the US Army M1A2 Abrams main battle tank, the US Air Force's B-2
(Batwing) stealth bomber, the Swedish Navy's 43X2 torpedo, and the
RAN's Collins class submarines.
Their biggest win is however selection in the US Air
Force "Bold Stroke" program and the US Navy's OSCAR program. Both of
these are retrofit demonstrations for large fleets of in service
fighter aircraft. To date trial installations have been performed,
using PowerPC VME boards and C++ based software, on the F-15E fighter,
the F/A-18E fighter and the US Marines' AV-8B Harrier jump jets. In the
air force programs, ATR sized hardware has used. In the US Navy and
Marine Corps programs, the existing AYK-14 16-bit processor box is
essentially gutted, and a new VME card cage is installed, with other
appropriate modifications. Feedback I have received from Boeing, who
evaluated the aircraft, could be best described as "glowing praise".
This is excellent news for taxpayers on either side of
the Pacific, since the longer term costs of software and hardware
maintenance and upgrading of these aircraft will dramatically decline in
the coming decade. In Australia, the major concern is the 1750A based
F-111 which is operated by no other user, with the adoption of VME on a
large scale in the US, the issue of viable upgrade paths for the
aircraft's avionics over the next 20 years is now pretty much resolved.
With replacement aircraft costing between USD 50M and 90M apiece, the
longer such machines can be kept, the better the return to the
taxpayer.
So if anybody asks you what your secretary's Macintosh
has in common with the latest F/A-18 or F-15 fighter, you can
truthfully tell them that both share the same PowerPC processor. At
least the latter, hopefully, won't draw smiley faces on the screen as
it boots up!