Hardware Platform Interface
The Hardware Platform Interface is an open specification that defines an application programming interface for platform management of computer systems. The API supports tasks including reading temperature or voltage sensors built into a processor, configuring hardware registers, accessing system inventory information like model numbers and serial numbers, and performing more complex activities, such as upgrading system firmware or diagnosing system failures.
HPI is designed for use with fault-tolerant and modular high-availability computer systems, which typically include automatic fault detection features and hardware redundancy so that they can provide continuous Service Availability. Additional features common in hardware platforms used for high-availability applications include online serviceability and upgradeability via hot-swappable modules.
The HPI specification is developed and published by the Service Availability Forum and made freely available to the public.
History
A primary motivator for the development of the HPI specification was the emergence of modular computer hardware platforms and commercial off the shelf systems in the late 1990s and early 2000s. This included CompactPCI platforms and, later, the AdvancedTCA and MicroTCA platforms standardized by the PCI Industrial Computer Manufacturers Group. These platforms include hardware management infrastructures based on the Intelligent Platform Management Interface. Concurrently, major Enterprise vendors such as HP and IBM also developed modular and bladed systems.The need for the HPI specification was first identified by an industry group called the “High Availability Forum,” which met for several months in 2000 to discuss issues relating to building high-availability computer systems using open architecture technology. This group published a white paper, in early 2001. Growing out of that work, Intel Corporation began a project to define a standard hardware platform management API named the Universal Chassis Management Interface. This work was migrated to the newly formed SA Forum consortium and was published as the Hardware Platform Interface in October 2002. The original HPI specification, SAI-HPI-A.01.01, was the first specification published by the SA Forum.
From 2002 onwards, several updates to the HPI specification have been published. Additionally, specifications for accessing an HPI implementation via Simple Network Management Protocol and specifications describing the use of HPI on AdvancedTCA and MicroTCA platforms have been produced. Table 1 lists all specifications published by the SA Forum in the HPI family.
| Specification Label | Date of Publication | Notes |
| SAI-HPI-A.01.01 | October 7, 2002 | Original HPI specification |
| SAI-HPI-B.01.01 | May 3, 2004 | Major revision to the base HPI specification. Addressed implementation and usability issues in original specification |
| SAI-HPI-SNMP-B.01.01 | May 3, 2004 | SNMP MIB for accessing HPI implementations |
| SAI-HPI-B.02.01 | January 18, 2006 | Minor revision to the base HPI specification. Added FUMI, DIMI and Load Management capability. |
| SAIM-HPI-B.01.01-ATCA | January 18, 2006 | HPI to AdvancedTCA mapping specification |
| SAI-HPI-B.03.01 | October 21, 2008 | Minor revision to the base HPI specification. Enhancements to FUMI; some new API functions |
| SAI-HPI-B.03.02 | November 20, 2009 | Minor corrections to the base HPI specification |
| SAIM-HPI-B.03.02-xTCA | February 19, 2010 | Major revision to the AdvancedTCA mapping specification. Includes mapping for MicroTCA platforms as well as AdvancedTCA. |
The HPI specifications and the Application Interface Specification have been developed separately within the SA Forum. Although they are both intended to address functionality required for the highest levels of Service Availability, they are usable independently of each other. The AIS specifications can be implemented and used for high-availability clustering middleware that does not implement hardware platform management, and the HPI specification can be implemented by platform providers and used directly by application or management programs without the use of other SA Forum management middleware.
Image:HPIWikiFigures1.png|thumb|center|upright=2.0|alt=Relation of the AIS and HPI interfaces in the system.|Figure 1: Relation of the AIS and HPI interfaces in the system.
The primary intersection between the AIS and HPI specifications is found in the AIS Platform Management Service. The PLM service is defined with an expectation that hardware platform management will be provided via an implementation of the HPI specification on the target hardware platform.
HPI architecture
The HPI specification does not dictate or assume which platform management capabilities should be present in a hardware platform. Rather, it provides a generic and consistent way to model whatever capabilities are present and provides a way for user application programs to learn the details of the platform management capabilities that are available.Image:HPIWikiFigures2.png|thumb|center|upright=2.0|alt=HPI hardware management architecture|Figure 2: HPI hardware management architecture.
HPI organizes hardware platform management capabilities into a set of Resources. Each Resource hosts a set of Management Instruments that can monitor and control parts of the hardware platform. The Management Instruments abstract management components built into the platform, like temperature or voltage sensors, configuration registers and display elements, or provide interfaces to management functions, such as upgrading firmware and running diagnostics. These Management Instruments are described in Resource Data Records that are accessible by the user application, so the application can discover the configuration and capabilities of each Resource.
While HPI Resources are abstract structures, typically, they are used to model the management capabilities of individual management controllers in the hardware platform. For example, in AdvancedTCA platforms, each computing blade usually includes an IPMI Management Controller responsible for hardware management tasks related to that blade. An HPI interface for an ATCA platform will normally include a Resource for each IPMC.
Resources in HPI are organized into Domains. Often, an HPI implementation will implement only one Domain for all Resources, but it is possible to subdivide the system into multiple Domains, if needed. For example, in some modular systems, various modules may be owned and managed by different users. To support this with HPI, all the Resources used to manage the modules owned by a specific user may be placed in a single Domain, and that user is given access only to that Domain.
HPI user programs access the platform management infrastructure by opening a Session with a specific HPI Domain. With this Session established, the user program may then make various HPI function calls to query or update information about that Domain, or about any of the Resources that are currently members of that Domain.
Image:HPIWikiFigures3.png|thumb|alt=An example of a system spread over two equipment racks is shown with a few Entities identified with their unique Entity Paths.|Figure 3: An example of a system spread over two equipment racks is shown with a few Entities identified with their unique Entity Paths.While HPI Management Instruments are organized and addressed by Domain and Resource, the hardware components that are managed by those Management Instruments are identified individually in the RDRs associated with each Management Instrument. Physical hardware components in HPI are called Entities and are identified with an Entity Path. An Entity Path contains multiple elements, with the first element describing where the hardware Entity is located in a containing Entity, the second element describing where that Entity is located in a larger container, and so on. For example, a redundant power supply for a chassis in a system that spans multiple racks might have the entity path of POWER_SUPPLY.2,SUBRACK.3,RACK.1.
Because each Management Instrument is associated with a specific Entity Path, it is possible for one HPI Resource to handle platform management for more than one Entity. It is also possible for a single Entity to be managed via multiple HPI Resources. This possibility of an arbitrary mix-and-match between HPI Resources and the hardware Entities being managed can seem confusing, but it is an important feature of the HPI architecture. This is because it allows modeling of complex management infrastructures that may include both in-band and out-of-band management elements of a single hardware Entity, and systems where a management controller on one piece of equipment provides management for another piece of equipment.
Management Instruments
HPI Resources may host a set of Management Instruments. Each Management Instrument models the ability to monitor or control some aspect of a hardware Entity. A set of RDRs in each Resource describes the Management Instruments hosted by that Resource, including information on what is being monitored or controlled.There are seven types of Management Instruments that may be used to model various capabilities of the platform management infrastructure. The first four: Sensors, Controls, Inventory Data Repositories and Watchdog Timers, are basic Management Instruments that usually map to discrete platform management capabilities. The other three: Annunciators, DIMIs and FUMIs, are more complex and encapsulate logical functions that the platform management infrastructure can provide.