The Hardware Platform Interface: A proven abstraction layer for xTCA management

4The Hardware Platform Interface (HPI) is one of two sets of Application Programming Interfaces (APIs) that the Service Availability Forum (SAF) set out to define in 2001, as the move for communications systems to open modular platforms began in earnest (another sign of that move was the launch that same year of the AdvancedTCA (ATCA) initiative within the PCI Industrial Computer Manufacturers Group (PICMG)). A key goal for HPI (and its complementary layer, SAF's Application Interface Specification (AIS)), is to enable the development of "carrier-grade" software application suites that are hardware independent but still capable of delivering the high service availability of previous top-to-bottom proprietary and purpose-built communications systems.

The purpose of HPI is to expose, in a standardized way, the management and monitoring capabilities built into a hardware platform. The key elements of HPI include entities and management instruments. Entities are used to establish a containment hierarchy that models the structure of the managed system, such as an that contains slots, some occupied by boards, each of which may themselves implement (AMC) module slots. Management instruments model the management capabilities, such as temperature or fan speed measurements, supported by the managed system.

HPI is a collection of APIs that can be implemented for almost any hardware platform; carefully written client applications of those APIs can work with almost any underlying hardware platform that is supported with an HPI implementation. SAF provides a set of introductory webcasts on its specifications and their use in carrier-grade systems (see http://opsy.st/SAFspecs), the first of which is a 10-minute introduction to HPI.

One specific mission of HPI is to isolate AIS-compliant High Availability (HA) middleware from the underlying hardware platform to enable hardware independence for the layers above. "Engineered COTS for network systems," also in this issue, covers the facilities and benefits of AIS, along with further background on the SAF.

The HPI specification was adopted by SAF in September, 2002, just 3 months in advance of PICMG's adoption of the ATCA specification, but the scope of SAF's hardware platform ambitions were always much broader than just ATCA. Nevertheless, the benefits of the SAF interfaces complement the benefits of ATCA hardware platforms well, and the two initiatives have evolved together and strengthened each other.

By 2003, an open source implementation of HPI called OpenHPI was under development by a community of cooperating companies, and initial work had begun on mapping OpenHPI to the ATCA hardware platform management layer and other non-ATCA platforms, as well.

Where does HPI stand today?

Ten years later, HPI is widely used in communications platforms, including , Telecom Equipment Manufacturer (TEM)-proprietary, and various modular platforms driven by specific companies, such as IBM's BladeCenter and HP's BladeSystem. In some contexts, HPI is the foundation layer for implementations of SAF's AIS, just as originally envisioned. In others, HPI is the only SAF-defined interface and companies implement proprietary application layers above it.

HPI has substantially matured over the past decade, including in the following areas:

  • The main specification has grown from fewer than 115 pages to almost 315 pages.
  • A complementary specification defines, in another 250 pages or so, how to map HPI to the Hardware Platform Management (HPM) layer of xTCA; in the absence of such a mapping specification, independent HPI implementations for distinct xTCA platforms could make very different choices, weakening the hardware independence benefits of HPI.
  • There are multiple implementations of HPI, including commercial products and robust distributions of OpenHPI.
  • Polaris Networks offers an HPI Tester product, which aims to validate compliance with the HPI specification.

The Summer 2012 issue of CompactPCI, AdvancedTCA, and MicroTCA Systems includes multiple articles (including "COTS management building blocks for AdvancedTCA: Proven over the first decade") that address the HPM layer of xTCA, and HPI's overall complementary role with respect to that layer. The remainder of this article focuses on the use of HPI in xTCA platforms, primarily ATCA shelves.

How is HPI used today with xTCA platforms?

Also in the Summer 2012 issue of , AdvancedTCA and Systems, "How one TEM leverages ATCA Hardware Platform Management" provides the perspective of Nokia Siemens Networks (NSN) on how to implement HPI in xTCA platforms. Figure 1 shows how NSN uses HPI as the foundation layer for the software platform and allows that platform, which represents massive TEM and/or TEM customer investment, to be used with multiple generations of hardware, including both ATCA and pre-ATCA hardware.

21
Figure 1: HPI enables a software platform that is largely independent of the hardware platform.

NSN goes on in the article to emphasize that, in their experience, HPI plays an essential role in integrating communications systems from hardware building blocks supplied by various sources.

HPI plays an important role in most other Tier 1 TEMs' communications platform strategies as well, including both xTCA platforms and non-xTCA platforms. Some of those HPI-leveraging TEMs use HA middleware based on SAF's AIS architecture, while others have their own solutions above HPI. In some cases, as shown in NSN's diagram above, HPI enables a software platform to span multiple generations of hardware platforms, including both pre-ATCA and ATCA.

What is OpenHPI and how does it support HPI's hardware independence goals?

OpenHPI is an open source implementation of HPI (www.openhpi.org provides access to the source code, plus background information), with the following main elements, all shown in Figure 2:

  • Client Library: a C language library that is linked into each HPI client application and which communicates with an HPI server via the OpenHPI Remote Procedure Call (RPC) client-server protocol. Each call to an API in the library results in an RPC transaction with an HPI server via an Internet Protocol (IP) session between the two entities.
  • Daemon: a program that implements an HPI server, including handling RPC requests to perform particular APIs. The daemon takes the input parameters associated with each such request, takes the necessary steps to perform the relevant function, and returns the results via an RPC response. For most APIs, the daemon makes one or more calls to a plug-in to do the actual work of the invoked function.
  • Plug-in: a shared library that implements the core of most HPI APIs for a particular class of management platforms. For instance, the Pigeon Point plug-in shown in Figure 2 implements the APIs for ATCA platforms that are supervised by Pigeon Point Shelf Managers. This plug-in uses the Remote Management Control Protocol (RMCP) to interact with a Shelf Manager (which usually supports dual active/standby instances for reliability). An OpenHPI daemon can host multiple plug-ins, each focused on a different class of managed platforms.

22
Figure 2: The lifecycle of an HPI function call with OpenHPI for an example ATCA shelf.

Figure 2 shows how a function call originating in an HPI client ultimately results in a function return to that client after processing by the elements described above. OpenHPI supports HPI's hardware independence goals by enabling the development of different plug-ins, several of which can co-exist in a single OpenHPI daemon that is responsible for a heterogeneous, multi-platform system.

The Pigeon Point plug-in complies with the SAF's HPI-to-xTCA mapping specification, maximizing the likelihood that HPI client applications can move without change across independent HPI implementations from different vendors, including ones not based on OpenHPI.

There is one more area to mention about Figure 2. The Shelf Manager shown, like most xTCA Shelf Managers, supports redundancy. While the active Shelf Manager instance is managing and representing a shelf (including to the HPI layer above, in this case), there is a standby instance that gets continuous updates from the active instance via Hardware and Software Redundancy Interfaces (HRIs and SRIs). This continuous update process ensures that if the active instance goes down for any reason, the standby instance can seamlessly take over management of the shelf.

Assuming that the OpenHPI server layer executes on separate hardware from the Shelf Manager, it can continue to operate across a Shelf Manager switchover. Unfortunately, the current OpenHPI server is not itself redundancy capable, so if that server goes down for any reason, it must be started from scratch, which could take considerable time in a complex ATCA shelf.

What are the benefits of integrating an HPI server into an xTCA Shelf Manager?

One immediate potential benefit is taking advantage of the redundancy infrastructure that is already built into most xTCA Shelf Managers to enable redundancy awareness of the HPI server. Figure 3 shows a corresponding lifecycle for an HPI function call in the context of one that provides an option to configure an HPI server as a shared library module within the Shelf Manager. In such a configuration, the substantial state maintained by an HPI server (associated with a complex ATCA shelf, for instance) is continuously updated from the active instance of the server to the standby instance. If a Shelf Manager switchover is necessary, the standby instances of both the Shelf Manager and the HPI server can take over immediately.

Another benefit is that the design of an integrated HPI server can be jointly optimized with the design of the Shelf Manager. There is much overlap in the responsibilities of an ATCA-focused HPI server and its corresponding ATCA Shelf Manager (such as tracking the Field Replaceable Units (FRUs) and sensors of the shelf). An integrated HPI server can focus on just the additional needs of the HPI service, improving both time and resource utilization.

The efficiency benefits of an integrated HPI server can be particularly dramatic during the initial "discovery" of the shelf components that happens when the shelf powers on. During discovery, all FRUs in the shelf are identified and their sensors and inventory data are gathered. This process can be many times slower when OpenHPI and the Shelf Manager are independently and simultaneously polling all the management controllers in a shelf for their data. In contrast, an integrated HPI server can use the information collected by the Shelf Manager and overlapping polling is not needed. Exacerbating the difference, OpenHPI developers made a design choice to fetch all this data from all FRUs in a shelf before any HPI interaction with the OpenHPI daemon is allowed. Pigeon Point has measured physical shelf configurations where discovery took seconds with IntegralHPI and minutes with OpenHPI, even though the joint performance of the Pigeon Point plug-in and the Pigeon Point Shelf Manager has been optimized aggressively over several years.

23
Figure 3: The lifecycle of an HPI function call with IntegralHPI for an example ATCA shelf.

Finally, as shown in Figure 3, an integrated HPI server like Pigeon Point IntegralHPI can use the OpenHPI client library communication protocol, which means that binary applications linked with the OpenHPI client library can transparently and concurrently interact with IntegralHPI servers and OpenHPI daemons.

Mark Overgaard is the Founder and CTO of . Within PICMG, he chairs the HPM.x subcommittee.

Pigeon Point Systems

info@pigeonpoint.com

www.pigeonpoint.com