BY JERRY GIPPER
Executive Director
VITA
www.vita.com
Increased complexity of the electronics systems in large defense platforms has inspired several open systems architecture (OSA) initiatives to step up their game. As working groups from these initiatives are collaborating on strategies to solve remaining challenges, matching solutions for high-performance embedded computing systems continue to emerge.
The Department of Defense does not provide a standardized open architecture framework for common embedded system services. This is forcing programs to look to the commercial world for solutions. For example, many military branches have initiatives underway espousing the module interoperability, maintainability, openness, usability, and reliability virtues of an OSA.
These initiatives are utilizing several different OSAs for board and system form factors. The programs see many different approaches as appropriate (not conflicting); there is no “one architecture to rule them all.” Each of these initiatives has at least one common goal: interoperability. Yet this single goal itself is a daunting challenge.
Numerous OSA-related initiatives have active working groups meeting to discuss, develop, and implement strategies. Table 1 lists key initiatives for defense applications that are implementing OSAs.
Table 1: Relevant OSA initiatives with system management strategies that are an imperative for interoperable modules.Table Source: VITA.
| Initiative | Sponsor | Mission |
|---|---|---|
| TENA integrated Network Enhanced Telemetry (iNET) Project | Test Resource and Management Center (TRMC) and supported by the U.S. Joint Staff | TENA is enabling interoperability among ranges, facilities, and simulations in a quick and cost-efficient manner and fostering reuse of range resources and range system developments. |
| Modular Open Systems Approach (MOSA) | Department of Defense (DoD) | The DoD’s MOSA is to design systems with highly cohesive, loosely coupled, and severable modules that can be competed separately and acquired from independent vendors. |
| Vehicular Integration for C4ISR/EW Interoperability (VICTORY) | Industry | Military ground vehicle electronics integration. |
| Modular Open Radio Architecture (MORA) | VICTORY, Army CERDEC I2WD | Extends VICTORY to support radio frequency (RF) systems. |
| Future Airborne Capabilities Environment (FACE) | The Open Group | A government-industry software standard and business strategy for acquisition of affordable software systems that promotes innovation and rapid integration of portable capabilities across global defense programs. |
| Sensor Open Systems Architecture (SOSA) | The Open Group, FACE | Enables government and industry to collaboratively develop open standards and best practices to enable, enhance, and accelerate the deployment of affordable, capable, interoperable sensor systems. |
| Joint Common Architecture — Airborne Mission Systems |
The Open Group,
U.S. Army
|
Instantiation of FACE. |
| Hardware Open Systems Technology (HOST) | NAVAIR | Defines virtual and physical interfaces to hardware such that interoperability and reuse of hardware components can be realized. |
The breadth of standards-based solutions makes it very difficult to ensure the interoperability necessary to design long-life-cycle platforms that handle products from multiple sources. One of the biggest problem areas is a standardized platform, system, or chassis management strategy that supports the various standards in play today.
System management and interoperability is a missing link
System management involves many tasks and is usually scalable to match the complexity of the platform. Typical tasks include diagnostics (at start-up and while running), hardware inventories, system availability monitoring and metrics, software inventory and installation, anti-virus and anti-malware management, user’s activities monitoring, capacity monitoring, security management, storage management, network capacity and utilization monitoring, anti-manipulation management, and more.
Unfortunately, system management functionality is often missing or inadequate in many of the commonly used standards. To address this gap, standards development organizations, such as VITA and the Open Group, are working on solutions, as are board suppliers and defense-program offices.
The interoperability challenge is both a hardware and a software problem. From the hardware perspective, OSA solutions that enable interoperability without prescribing a specific hardware design or implementation are preferred. This frees designers to implement management with any of a variety of general-purpose processors or FPGAs or other hardware.
On the software side, a system management standard should support access to and usability of all system-relevant data in a module. In addition, it should provide a standardized method of gathering data for analysis to support system and chassis management. Finally, a standardized suite of core system services (interfaces and data structures) that provide a common framework for system integration should be defined. The more data that can be collected, the better, and it can be left to the designer to implement what they need. At the same time, a system management standard should not:
- Prescribe design, logic, or otherwise inhibit innovation or the implementation of unique platform-specific requirements. The sensitive nature of defense platforms often means that creative liberties are required.
- Have dependencies regarding the use of an operating system to manage time and space resources, high-order software languages, or use of application software open architectures. Programmers do not want to be locked into specific solutions.
- “Reinvent the wheel” — make every effort to point to existing standards where possible rather than invent new interfaces and protocols.
Implementation strategy
Different system management strategies are used by the initiatives. The TENA integrated Network Enhanced Telemetry (iNET) project has led to development of a basic system management standard. The standard primarily relies on the Simple Network Management Protocol (SNMP) to pass management information through the system. The standard defines an SNMP Management Information Base (MIB) to provide a dictionary for management information. The devices carry applications, called agents, which use the MIB to provide their internal status and accept controls and configuration. This solution fits well with networked systems requiring basic system management capability.
The VICTORY initiative includes an Ethernet in-vehicle network as part of the vehicle infrastructure; basically, management is baked into the architecture. The VICTORY path to a management solution is based on the iNET system management standard. The MORA initiative, as part of VICTORY, is taking the same path.
For complex platforms with many high-performance embedded computing modules, the foundation for robust system management comes from the Intelligent Platform Management Interface (IPMI) specification developed by Intel. IPMI is a set of computer interface specifications for an autonomous computer subsystem that provides management and monitoring capabilities independently of the host system’s CPU, firmware (BIOS or UEFI), and operating system.
IPMI defines a set of interfaces used by system administrators for out-of-band management of computer systems and monitoring of their operation. For example, IPMI provides a way to manage a computer that may be powered off or otherwise unresponsive by using a network connection to the hardware rather than to an operating system or login shell. From this widely implemented IPMI foundation, other standards organizations have built standards specific to their served industries.
For its part, PICMG developed the PICMG 3.0 Hardware Platform Management standard, focused primarily on the telecom industry. It was founded on IPMI 1.5 and has proven interoperability and significant field-testing.
The VPX standard is called out in several of the OSA initiatives. VITA members developed the ANSI/VITA 46.11 “System Management Architecture for VPX Systems” standard that leverages PICMG 3.0 but with considerations for defense system platforms. Overly complex or unnecessary functions from PICMG 3.0 were dropped while the following enhancements were made to better enable deployed defense systems. These enhancements include:
- Optimized field replaceable unit (FRU) state diagram (power-on/power-off state machine)
- Optimized FRU discovery (faster system management availability)
- Enhanced security feature enablement (NVMRO, additional FRU state bits/behaviors)
- Standardized diagnostic management features (initiation and result collection)
- DO-178B and DO-254 aware (tiered controller architecture)
New concerns are now arising from the Hardware Open Systems Technology (HOST) initiative asking if the existing standards are complete and sufficient in defining all of the required interfaces and protocols. The current HOST Tier 2 specification allows two incompatible chassis management approaches. Out-of-band (dedicated) communications use the low-bandwidth I2 C bus, per ANSI/VITA 46.11, but limitations in speed and data structure size restrict some desired functionality. The in-band communication channel utilizes high-bandwidth Ethernet but is not well-defined by HOST. At this point, in-band and out-of-band chassis management are incompatible, per the HOST specification.
A HOST working group has been polling potential users, system integrators, and prime contractors for their inputs. Early feedback is highlighting potential insufficiency in ANSI/VITA 46.11. Most of the concern centers on whether or not I2 C has sufficient bandwidth for everything that must be monitored.
Fortunately, the flexibility of VPX presents plenty of suitable options for picking up additional bandwidth. The challenge for the HOST and VITA working groups is to zero in on the solution that works best for deployed platforms. One option on the table is to upgrade ANSI/VITA 46.11 to add applicable features of IPMI 2.0 that address some of the missing capabilities. Improvements in firmware management, diagnostic management, and security are being considered.
Solutions emerging
The VPX family of standards continues to add capabilities as influenced by the user community, especially mil/aero users. Shipping products from the likes of Abaco Systems, Curtiss-Wright Defense Solutions, Elma Electronics, and Mercury Systems include support for ANSI/VITA 46.11 System Management. They are providing backplanes and individual processing and I/O modules all the way up to complete systems ready for integration into a defense platform.
In many cases, modules from several of these suppliers will be used, so the level of system management support becomes critical. Elma Electronics’ OpenVPX backplane (Fig. 1 ) includes system management interfaces. Also, several members of Mercury Systems Ensemble 3000 and Ensemble 6000 OpenVPX board products include on-board IPMI controllers (Fig. 2 ).
Fig. 1: OpenVPX backplanes from Elma Electronics include a system management interface according to VITA 46.11. Image Source: Elma Electronics.
Fig. 2: Several members of Mercury Systems’ Ensemble 3000 and Ensemble 6000 OpenVPX board products include on-board IPMI controllers.
Advertisement
