page_title: Hardware Platform Interface
section_title: HPI architecture
hierarchical_section_title: Hardware Platform Interface / HPI architecture
caption_attribution_description: English: An example of a system spread over two equipment racks is shown with a few Entities identified with their unique Entity Paths.
context_page_description: 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.
context_section_description: 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.
  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 (RDRs) 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 (ATCA) platforms, each computing blade usually includes an IPMI Management Controller (IPMC) 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.
  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.
caption: Figure 3: An example of a system spread over two equipment racks is shown with a few Entities identified with their unique Entity Paths.
exif: {}