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!