Hardware Platform Interface

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.

A primary motivator for the development of the HPI specification was the emergence of modular computer hardware platforms and commercial off the shelf (COTS) systems in the late 1990s and early 2000s.

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, “Providing Open Architecture High Availability Solutions” in early 2001.

This work was migrated to the newly formed SA Forum consortium and was published as the Hardware Platform Interface in October 2002.

Although they are both intended to address functionality required for the highest levels of Service Availability, they are usable independently of each other.

Each Resource hosts a set of Management Instruments that can monitor and control parts of the hardware platform.

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.

The other three: Annunciators, DIMIs and FUMIs, are more complex and encapsulate logical functions that the platform management infrastructure can provide.

An HPI sensor reports status information about the hardware being monitored through a set of up to 15 individual bits, called Event States.

OEM (vendor specific) controls can be sent a block of data, which may be used in implementation-specific ways by the managed Entity.

Inventory Data Repositories are used to report or set identification and configuration information for hardware Entities.

The HPI Watchdog Timer Management Instrument is designed to interface with this sort of hardware mechanism.

Annunciators are logical Management Instruments that are used to interface with an alarm display function on a hardware platform.

are used on different hardware platforms, it is difficult for an application program to be written to display alarm information in a platform-independent way.

DIMIs are logical management instruments used to coordinate the running of on-line or off-line diagnostic firmware or software on various hardware entities.

This function is integrated with HPI to help standardize automatic diagnosis and repair of fault conditions and to support on-line serviceability.

FUMIs are logical management instruments that are used to support the installation of firmware updates to programmable hardware Entities.

The HPI interface provides three services at the Domain level that a user program can use to stay informed of exceptional conditions in the hardware platform.

Through this mechanism, user programs can stay informed of changes in the managed platform without needing to continually poll for status.

A key feature of the HPI specification is the way it handles dynamic reconfiguration, or hot-swap actions in the managed platform.

Often, especially in system architectures like AdvancedTCA, FRUs include their own platform management controllers.

When a Resource supports Managed Hot-swap, then a user program can interact with the HPI implementation and the underlying platform management infrastructure to coordinate the actions required to integrate newly added FRUs or to deactivate FRUs being removed from the system.

e) Data structures passed to HPI functions from the user may change in new versions of the HPI specification, as long as the change is made in a way such that an existing program passing the earlier defined structure will continue to operate correctly.

Because HPI is widely used on AdvancedTCA systems, the SA Forum published a Mapping Specification, labeled SAIM-HPI-B.01.01-ATCA in January 2006.

In the original version of the specification, Resources were defined and required for all “Slots” in the chassis or on carrier cards that could potentially host FRUs.

The second audience consists of HPI users that wish to create portable application or middleware programs across multiple AdvancedTCA or MicroTCA platforms.

The OpenHPI daemon process is designed to integrate with one or more plug-in modules, which handle the downstream communication with various platform management infrastructures.

Relation of the AIS and HPI interfaces in the system.
Figure 1: Relation of the AIS and HPI interfaces in the system.
HPI hardware management architecture
Figure 2: HPI hardware management architecture.
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.
HPI Domain-level functionality
Figure 4: HPI Domain-level functionality.
Hot-swap states with transitions applicable to managed hot-swap resources
Figure 5: Hot-swap states with transitions applicable to managed hot-swap resources.
A Typical HPI Implementation
Figure 6: A Typical HPI Implementation