Validating the interoperability of VITA 46.11-based system management elements

4VITA 46.11 was adopted by the VITA Standards Organization (VSO) as a Draft Standard for Trial Use in November 2013. VITA 46.11 aims to enable the creation and integration of standardized, independently implemented, chassis and plug-in module system management components, reducing integration time and cost, as well as time to theatre. The article “System management on VPX: Leveraging VITA 46.11 for VPX plug-in modules,” in the Spring 2014 issue of VITA Technologies introduced the standard, with an emphasis on its plug-in module level.

A key premise of the VITA 46.11 initiative and an important basis for high expectations on its benefits is that independently implemented management components, such as Intelligent Platform Management Controllers (IPMCs) on plug-in modules and Chassis Managers can successfully interoperate. The VITA 46.11 working group has realized that this premise requires not only careful attention to the content of the standard, but complementary live interoperability testing as well. Consequently, the group has organized the first VPX System Management Interoperability Workshop (VSM-IW) to perform such testing. This first VSM-IW is scheduled in early September 2014, and will be hosted by the current VITA 46.11 working group chair, Mercury Systems.

This article discusses the approach to interoperability testing that will be used in these VSM-IWs, including how that approach leverages corresponding work by PICMG for ATCA.

How is the VSO taking advantage of PICMG’s interoperability testing experience?

The VSO made a conscious choice to base VITA 46.11 on the corresponding management layer of PICMG’s AdvancedTCA (ATCA) architecture, rather than start from scratch. This choice accelerated development of the standard and will hasten availability and maturity of VITA 46.11-compliant products.

This choice is also benefiting the VITA 46.11 interoperability initiative. PICMG has held dozens of interoperability testing events (now called TCA-IWs, or Telecom Computing Architecture Interoperability Workshops) dating back to 2002. Continuing its strong cooperation in this area, PICMG has authorized the VSO to use the relevant subset of the test plans from those events as a basis for VSM-IW testing. PICMG uses over 30 of these plans, each developed by IW participants, then reviewed and iterated with other participants.

Each test plan focuses on a functional area where interoperability testing is important. The VITA 46.11 working group has picked a subset of the PICMG plans for review and adaptation, as necessary, to the VPX context. The group has also defined a further set of test areas that are specific to VITA 46.11 and is developing test plans for each of those areas as well.

PICMG has also passed on to the VSO the organizational tools that it has developed over its decade-plus of TCA-IWs. Several of the active VITA 46.11 working group members, including Pigeon Point Systems, participated in most or all of the PICMG TCA-IWs, and are contributing that overall experience as well.

What are the critical interoperability interfaces for VITA 46.11?

Figure 1 shows the management stack defined by VITA 46.11, starting at the bottom with the IPMC on each compliant plug-in module. Next up is the Chassis Manager, which monitors and supervises the IPMCs in a chassis and represents the chassis to a logical System Manager. The Chassis Manager may be implemented on a redundant basis, but even in that case, would still implement a single logical Chassis Manager function.

Figure 1: VITA 46.11 system management stack, highlighting critical interoperability interfaces between: a) System Manager and Chassis Manager; b) Chassis Manager and IPMCs.
(Click graphic to zoom)

Interoperability across the Chassis Manager-to-IPMC interface (System IPMB in the figure) facilitates combining plug-in modules from multiple vendors, each of which can potentially make different implementation choices for their IPMCs. Some IPMCs in a given chassis may be adapted from generic commercial off-the-shelf (COTS) cores, as recommended in the earlier article referenced above. Other plug-in modules may integrate IPMCs implemented from scratch by their respective vendors.

Interoperability across the System Manager Interface allows potentially large investments in upper level management applications (all encompassed within the logical System Manager) to be applied across multiple independent Chassis Manager implementations. VITA 46.11 does not attempt to define the functionality of the System Manager, only the minimum characteristics of its interface to the Chassis Manager.

The lead-in photo for this article shows an example VITA 46.11-enabled OpenVPX chassis with modules that would be suitable for use in a VSM-IW. The Chassis Manager Ethernet interfaces on the front of the chassis could be used as the System Manager interface.

How will VITA 46.11 interoperability be tested in VSM-IWs?

Interested vendors with VITA 46.11 products will bring equipment for testing at each VSM-IW. For the Chassis Manager to IPMC (or System IPMB) interface, the basic idea is to allocate a test session for each important [Chassis Manager + IPMC] pair where that pair is exercised according to the applicable test plans. This typically means a session for each [VITA 46.11 chassis provider + VITA 46.11 plug-in module provider] pair. Each chassis and plug-in module supplier may have multiple chassis or plug-in modules, possibly with some variations in their VITA 46.11 implementations. The idea for each of these sessions is to use the test plans to check interoperability of that set of chassis and plug-in modules. The overall VSM-IW is a series of test blocks, perhaps two or three hours each, with parallel test sessions in each test block and a goal to have at least one session for each pair of participating chassis and module vendors by the end of the event.

Participant companies use the group-developed test plans during these sessions in whatever way they wish. Ideally, they will have automated test scripts that make the testing quick and reproducible. Any such test automation is developed by each participating company for its own use.

In the PICMG TCA-IWs, there are mutually agreed ground rules, including that testing results are confidential to the vendor of a component under test and are not to be used for competitive purposes. Comparable rules have been adopted for VSM-IWs so that potential participants can be confident that their participation is a constructive experience.

How does the tiered architecture of VITA 46.11 affect interoperability testing?

VITA 46.11 defines two tiers of functionality for the Chassis Manager and IPMC components. Tier 1 components have minimal facilities, which can be simpler and less expensive to implement. Tier 2 components deliver more functionality in the management layer, allowing greater reuse of those facilities across applications. Each component asserts compliance with one of those tiers. Figure 2 shows the tier architecture.

Figure 2: HPM.1 architecture for VITA 46.11.
(Click graphic to zoom)

VITA 46.11 requires that tier 2 Chassis Managers work with a chassis that contains either tier of IPMCs, including a mixture of both tiers. Tier 1 Chassis Managers are required to work only with tier 1 IPMCs. Other combinations are optionally supported. Given these requirements, the VSM-IW test sessions and test plans need to consider the tier level of components under test and any test automation should be designed to support at least the mandatory tier combinations.

How do other PICMG management layer specs affect VITA 46.11 interoperability?

Because of the strong affinity between ATCA management and VITA 46.11, there are two other specifications in the PICMG Hardware Platform Management (HPM) series that can be applied, essentially as-is, in the VITA 46.11 context. HPM.1 and HPM.2 define implementation-independent frameworks that enable: 1) upgrading firmware on management controllers, especially IPMCs and 2) connecting IPMCs to an inside-the-box Ethernet to supplement communication on the much slower (System) IPMB.

Of these two specifications, HPM.1 is the most crucial for a VITA 46.11 IPMC, since an IPMC is virtually certain to need firmware upgrade(s) across a potentially long lifetime. HPM.1 is the only vendor-independent firmware upgrade architecture available for management frameworks based on the Intelligent Platform Management Interface (IPMI). Both VITA 46.11 and ATCA management are based on IPMI.

The VSO may eventually do an explicit adaptation of HPM.1 and HPM.2 PICMG specifications to the VITA 46.11 context, but they can benefit VITA 46.11 users immediately, especially HPM.1.

Figure 3 shows the HPM.1 architecture for a VITA 46.11 context. HPM.1 defines a fairly sophisticated firmware upgrade facility. Firmware upgrade images and IPMCs are identified and matched by the upgrade agent to be sure that only compatible firmware is loaded on an IPMC (see the IPMC types A and B in Figure 3). IPMCs can have multiple upgradeable elements, such as microcontroller (µC) firmware and a supporting Programmable Logic Device (PLD). Type A IPMCs in the figure have just the first element class, while type B IPMCs have both.

Figure 3: The VITA 46.11 architecture defines functionality tiers for both Chassis Managers and IPMCs to make it easier to adapt the management layer for differing application needs, while preserving predictable interoperability.
(Click graphic to zoom by 1.9x)

As Figure 3 shows, there are two ways to transfer upgrade images to an IPMC. In the first way, the upgrade agent establishes a Remote Management Control Protocol (RMCP) session with the Chassis Manager, which proxies that session to the IPMC being upgraded via System IPMB. RMCP is a UDP-based protocol defined by IPMI. It is important to demonstrate interoperability for this upgrade method, so that a single upgrade agent can successfully upgrade firmware for multiple types of IPMCs in a single chassis or group of chassis that make up a system.

In the second upgrade approach, an upgrade agent could run on a main payload CPU (perhaps a Xeon or a PowerPC) and communicate with the IPMC over what VITA 46.11 calls the payload interface between them. This approach is much more likely to be vendor-specific, since it depends on the implementation details of the payload CPU and its operating system, as well as the payload interface. Therefore, this path is much less important for interoperability testing.

How can VPX vendors and users help to ensure VITA 46.11 interoperability?

VPX users who need VITA 46.11 support in their platforms should insist on system elements (including chassis and plug-in modules) with a demonstrated interoperability record, developed by vendors with a commitment to interoperability.

VPX vendors who incorporate VITA 46.11 support into their chassis and/or plug-in modules can maximize interoperability for their products by:

  • Basing their management layer on COTS components, adapted to their specific needs, since they are likely to have a better interoperability record;
  • Choosing COTS management component vendor(s) who are participating in the VITA 46.11 VSM-IW initiative and whose components have already benefited from thorough interoperability testing and field validation in the ATCA context.

Pigeon Point Systems’ Chassis Manager and IPMC solutions are both examples of COTS management components for VITA 46.11 that meet the above criteria.

Mark Overgaard is the Founder and CTO of Pigeon Point Systems. He is a leader in the VITA 46.11 working group and actively contributed to the development of VITA 46.11. Within PICMG, he chairs the HPM.x subcommittee and participates in numerous others. Readers may reach him at

Pigeon Point Systems 760-757-2304