Is VMEbus Stuck in a Time Warp?
More than 20 years old and still going strong, VMEbus is seeing a very definite revival in interest and not just in defense and aerospace, one of its strongest markets. Defense and aerospace applications have a number of special requirements, which the VME community works hard to address without losing contact or compatibility with products for other marketplaces. There are two key requirements that are worthy of further exploration:
- How to balance the need for continuous product evolution to maintain competitive advantage while sustaining existing customers' programs for the extended lifecycle
- How to evolve the VME standard to meet the needs of the future
Sure signs of a healthy marketplace include a large number of competitive suppliers continuously developing new and improved products to fuel their competitive edge. VMEbus is in the fortunate position of being able to leverage technology such as the PowerPC, PCI bus, graphics devices, memory technology, and software development tools that have an even broader market reach than just VME. VME product suppliers are able to offer the latest technology and to spin new and improved versions of their products on shorter and shorter cycles. New product cycles can now be as short as 18 months from one generation to the next. This is the direct result of the competitive pressures in the market and it is the customer that benefits. Or is it? The COTS movement has brought undeniable benefits to the defense and aerospace system development team, such as faster time to deployment, lower development costs, and lower risk as their system development is no longer dependent on a singular in-house solution that has no equivalent in the open market. With COTS, the failure of one supplier to perform can generally be mitigated by substitution with another.
With the benefits come the specter of rapid component obsolescence and the rapidly rising costs of sustaining a deployed system for as long as 30 or 40 years. Obsolescence is affecting deployed defense and aerospace systems in a number of ways. There are legacy systems, which were designed and deployed before the COTS era, and then there are the effects resting on newly designed systems, which have successfully deployed VME and are now running into obsolescence issues.
Legacy systems are beginning to become a real issue to the end users as they were probably designed before the COTS initiatives were embraced. They would have used MIL-STD components (most of which are now unobtainable), software development tools, and languages that are no longer supported. The skills to maintain dead languages such as Pascal and Jovial are tough to find. Maintaining these legacy systems is becoming an increasing drain on Operation and Maintenance (O&M) budgets, resulting in restriction of the amount of money available for the procurement of new or replacement systems. O&M is now a substantial part of any defense budget. Very often these systems use proprietary architectures and have form factors that are very different from VME boards (such as the SEM standards).
In avionics, board form factor directly affects the size and shape of the electronics enclosures, which impacts the space allocated to them on the platform itself. Changing the size of a legacy enclosure to accommodate VMEbus is usually impractical, as any changes to the platform structure often result in the need for recertification. COTS and VME-derived technology can be leveraged to replace legacy modules (most often obsolete processor, memory, and graphics modules) by utilizing design modules from state-of-the-art VME cards and producing a functionally compatible product on a form factor to suit legacy equipment. This may or may not have a VME bus to interface to the rest of the modules in the box, but because it is compatible with a standard COTS product, software development can take place using the latest tools and language support. But even this solution will become obsolete one day and this is where the choice of vendor becomes so important to the success of any COTS-based project.Whether you are using standard COTS products, derived-COTS products, or totally proprietary designs you are vulnerable to obsolescence in today's marketplace. It is important to understand the options available and their impact on Total Cost of Ownership (TCO). Buying inexpensive and replacing often is not necessarily the right answer. There are basically three options available, select the most appropriate option to achieve lowest TCO:
- Freeze the design at EMD and negotiate with your supplier for extended warranty, longevity of supply, and long-term repair/support services. This is appropriate for subsystems that are unlikely to change for the life of a platform.
- Use technology refresh where it is feasible to replace all items of the same type in a platform with a replacement of a newer generation. Typically this is effective for a small number of identical platforms where more functionality and performance is needed as a result of a capability upgrade.
- Use technology insertion, where there are many versions of the same basic platform type, to upgrade one version to the next or to add extra functionality.
In a practical system, using a combination of option 2 and 3 over a long period of time, coupled with the longevity option provided by option 1, is likely to offer the lowest TCO.
VME has continued to evolve to maintain its position as the bus architecture of choice in embedded, real-time systems. It continues to be designed into new defense and aerospace platform applications, which will still be in operation 20 or 30 years from now. If VME is going to be around this long to support technology refresh and technology insertion it has to continue to evolve at the same pace as potentially competitive technologies in order to realize the TCO benefits just discussed or it will be unceremoniously ousted - so the incentive is there for the industry to maintain its momentum.
How are embedded systems expected to evolve over the next few years and what is the impact on VME? In avionics there is a great deal of development focus on Integrated Modular Avionics (IMA) and it has parallels in other segments of the defense and aerospace markets - in particular, land vehicles and remotely operated vehicles. Many platform architectures today still use individual subsystems to control just one function of the vehicle. Each subsystem produces status, control, or data in a highly condensed (processed) form to be distributed to other subsystems by Ethernet, FDDI, or MIL-STD-1553B. This is a federated architecture that has many semi-independent subsystems with little shared data. Functions can only be added to the system by adding another semi-independent subsystem and plumbing it into the existing messaging or network protocols, often with the need to change many other subsystems to interact with the new functionality.
IMA systems use a much smaller number of centralized processors with shared access to data coming in from sensors and instrumentation. IMA processors run multiple tasks in segregated partitions, thus reducing the number of individual subsystems in a platform, saving cost, weight, power, spares, and, importantly, TCO over the platform lifecycle. VME has to adapt to these future requirements:
Support technology refresh and technology insertion in existing platforms
Support IMA type architectures in new platforms
Both requirements will continue to demand more processor performance, memory, I/O bandwidth, bus bandwidth, integration, as well as long-term physical compatibility to support refresh and insertion. Switched fabrics will play an increasingly important role over the next few years, both internally between cards within subsystems and externally between enclosures. Typical of these will be Fibre Channel, StarFabric, RapidIO, 3GIO, and GigE. The VME standard must find a way to accommodate them. For defense and aerospace applications VME faces a few challenges:
Power requirements of complex boards continue to rise. The number of 3.3V and 5V power pins will need to be increased and/or a new power source such as 48V could be distributed across the backplane for on-card regulation.
In defense and aerospace applications it is preferred practice for backplane I/O to be used. The number of I/O pins is becoming a limiting factor for SBCs with, for example, 2 PMC modules fitted using both the maximum number of backplane I/O pins.
Signals of greater than 2 GHz will be required through the connectors for switched fabrics, sensor images, and graphics applications in the future.
Motorola is to be applauded for their VME Renaissance initiative. The development of a new VMEbus interface device is long overdue and the new "Tempe" device will offer a real boost in performance for many VME applications. In addition to "Tempe," VME Renaissance accommodates high-speed, serial switched fabrics with centralized switching (VITA-41). This requires a change of the VME P0 connector (losing backplane I/O connectivity) and the addition of centralized switch cards to a VME card rack. This provides a level of functionality similar to PICMG 2.16 within a VMEbus subsystem.
VITA-41 addresses many of the functional and performance needs of future defense and aerospace applications, but a review of the challenges quickly reveals that it is not wholly adequate at addressing the entire spectrum of future needs. While there are no firm proposals on the table today, the challenges will have to be resolved. With the number of already deployed systems using VME it would be impractical for an evolved VME standard to move away from the current card size. Technology refresh and insertion will need to utilize existing sizes of enclosures. IMA systems may have more flexibility in terms of card size, as they do not really exist today in a standardized form, but it is anticipated that older systems will also partially transition into IMA, making a good case for maintaining commonality of card size and bus architecture between the old and new. Centralized switching within a subsystem is a proven solution, but it is likely that distributed switching will be a much more flexible network topology both inside and between subsystems. It will also provide much greater resistance to battle damage or single point failures.
Backward compatibility, meeting the power distribution challenge, multi-GHz signaling, distributed fabric switching, and more backplane I/O connectivity are all that is needed. And that is only for the next seven or eight years. Evolution of VME is inevitable and it has by no means reached its ultimate potential, but there are certainly some challenges ahead that the industry will resolve with its usual spirit of cooperation and innovation.