하드웨어 플랫폼인터페이스
Hardware Platform Interface |
HPI(Hardware Platform Interface)는 컴퓨터 시스템의 플랫폼 관리를 위한 API(Application Programming Interface)를 정의하는 개방형 사양입니다.API는 프로세서에 내장된 온도 센서 또는 전압 센서 읽기, 하드웨어 레지스터 구성, 모델 번호 및 시리얼 번호 등의 시스템 인벤토리 정보 액세스, 시스템 펌웨어 업그레이드 또는 시스템 장애 진단 등의 보다 복잡한 작업을 수행할 수 있습니다.
HPI는 폴트 톨러런스 및 모듈러형 고가용성 컴퓨터 시스템에서 사용하도록 설계되어 있습니다.일반적으로 자동 장애 검출 기능과 하드웨어 용장성을 갖추고 있어 지속적인 서비스 가용성을 제공합니다.고가용성 애플리케이션에 사용되는 하드웨어 플랫폼에서 공통되는 추가 기능으로는 핫 스왑 대응 모듈을 통한 온라인 보수 및 업그레이드 용이성이 있습니다.
HPI 사양은 Service Availability Forum(SA 포럼)에서 개발 및 공개되며 일반인에게 무료로 제공됩니다.
역사
HPI 사양 개발의 주된 동기는 1990년대 후반과 2000년대 초반에 모듈러형 컴퓨터 하드웨어 플랫폼과 상용 기성품(COTS) 시스템의 출현이었습니다.여기에는 콤팩트도 포함되어 있습니다.PCI 플랫폼과 그 후 어드밴스드PCI Industrial Computer Manufacturers Group(PICMG)에 의해 표준화된TCA 및 MicroTCA(xTCA) 플랫폼.이러한 플랫폼에는 Intelligent Platform Management Interface(IPMI) 기반의 하드웨어 관리 인프라스트럭처가 포함됩니다.동시에 HP 및 IBM과 같은 주요 엔터프라이즈 벤더도 모듈러형 및 블레이드형 시스템을 개발했습니다.
HPI 규격의 필요성은 2000년 오픈 아키텍처 기술을 사용한 고가용성 컴퓨터 시스템 구축과 관련된 문제를 논의하기 위해 수개월간 개최된 "High Availability Forum"이라는 업계 그룹에 의해 처음 확인되었습니다.이 그룹은 2001년 초에 "오픈 아키텍처 고가용성 솔루션 제공"이라는 백서를 발표했습니다.그 결과 인텔은 Universal Chassis Management Interface (UCMI)라는 이름의 표준 하드웨어 플랫폼 관리 API를 정의하는 프로젝트를 시작했습니다.이 작업은 새롭게 구성된 SA 포럼 컨소시엄으로 이행되어 2002년 10월에 하드웨어 플랫폼 인터페이스로 발행되었습니다.원래의 HPI 사양 SAI-HPI-A.01.01은 SA 포럼에 의해 공개된 최초의 사양이었습니다.
2002년 이후 HPI 사양에 대한 몇 가지 업데이트가 발표되었습니다.또한 SNMP(Simple Network Management Protocol)를 통해 HPI 구현에 액세스하기 위한 사양 및 Advanced에서의 HPI 사용을 설명하는 사양TCA 및 MicroTCA 플랫폼이 생성되었습니다.표 1은 HPI 패밀리의 SA 포럼에 의해 공개된 모든 사양을 나타내고 있습니다.
| 사양 라벨 | 발행일 | 메모들 |
|---|---|---|
| SAI-HPI-A.01.01 | 2002년 10월 7일 | 오리지널 HPI 사양 |
| SAI-HPI-B.01.01 | 2004년 5월 3일 | 기본 HPI 사양의 메이저리비전구현 및 조작성 문제를 원래 사양으로 해결 |
| SAI-HPI-SNMP-B.01.01 | 2004년 5월 3일 | HPI 구현에 액세스하기 위한 SNMP MIB |
| SAI-HPI-B.02.01 | 2006년 1월 18일 | 기본 HPI 사양의 마이너 리비전.FUMI, DIMI 및 부하 관리 기능 추가. |
| SAIM-HPI-B.01.01-ATCA | 2006년 1월 18일 | HPI에서 Advanced로TCA 매핑 사양 |
| SAI-HPI-B.03.01 | 2008년 10월 21일 | 기본 HPI 사양의 마이너 리비전.FUMI 기능 강화, 새로운 API 기능 추가 |
| SAI-HPI-B.03.02 | 2009년 11월 20일 | 기본 HPI 사양에 대한 약간의 수정 |
| SAIM-HPI-B.03.02-xTCA | 2010년 2월 19일 | 어드밴스드 메이저리비전TCA 매핑 사양MicroTCA 플랫폼 및 Advanced 매핑 포함TCA. |
HPI 사양과 Application Interface Specification(AIS; 응용 프로그램인터페이스 사양)은 SA 포럼 내에서 별도로 개발되었습니다.둘 다 최고 수준의 서비스 가용성에 필요한 기능에 대처하기 위한 것이지만 서로 독립적으로 사용할 수 있습니다.AIS 사양은 하드웨어 플랫폼 관리를 구현하지 않는 고가용성 클러스터링 미들웨어에 구현 및 사용할 수 있으며 HPI 사양은 플랫폼 공급자에 의해 구현되어 다른 SA 포럼 관리 미들웨어를 사용하지 않고 애플리케이션 또는 관리 프로그램에 의해 직접 사용할 수 있습니다.
AIS 사양과 HPI 사양의 주요 교차점은 AIS Platform Management Service(PLM; 플랫폼 관리 서비스)에 있습니다.PLM 서비스는 타깃 하드웨어 플랫폼에 HPI 사양을 구현함으로써 하드웨어 플랫폼 관리를 제공할 것을 상정하여 정의됩니다.
HPI 아키텍처
HPI 사양은 하드웨어 플랫폼에 어떤 플랫폼 관리 기능을 탑재해야 하는지를 지시하거나 상정하지 않습니다.대신 존재하는 모든 기능을 모델화하는 일반적이고 일관된 방법을 제공하고 사용자 애플리케이션 프로그램이 사용 가능한 플랫폼 관리 기능의 세부 정보를 학습할 수 있는 방법을 제공합니다.
HPI는 하드웨어 플랫폼 관리 기능을 일련의 리소스로 정리합니다.각 리소스는 하드웨어 플랫폼의 일부를 감시 및 제어할 수 있는 일련의 Management Instruments를 호스트합니다.Management Instruments는 플랫폼에 내장된 온도 또는 전압 센서, 구성 레지스터 및 디스플레이 요소 등의 관리 구성 요소를 추상화하거나 펌웨어 업그레이드 및 진단 실행과 같은 관리 기능에 대한 인터페이스를 제공합니다.이러한 Management Instruments는 사용자 응용 프로그램에서 액세스할 수 있는 RDR(Resource Data Records)에 설명되어 있으므로 응용 프로그램은 각 리소스의 구성 및 기능을 검색할 수 있습니다.
HPI 리소스는 추상적인 구조이지만 일반적으로 하드웨어 플랫폼에서 개별 관리 컨트롤러의 관리 기능을 모델링하기 위해 사용됩니다.예를 들어 [Advanced]의 경우TCA(ATCA) 플랫폼에는 보통 각 컴퓨팅 블레이드에는 해당 블레이드와 관련된 하드웨어 관리 태스크를 담당하는 IPMI Management Controller(IPMC)가 포함되어 있습니다.ATCA 플랫폼의 HPI 인터페이스에는 보통 각 IPMC의 리소스가 포함됩니다.
HPI의 리소스는 도메인으로 구성됩니다.대부분의 경우 HPI 구현에서는 모든 리소스에 대해 하나의 도메인만 구현되지만 필요에 따라 시스템을 여러 도메인으로 세분화할 수 있습니다.예를 들어 일부 모듈러 시스템에서는 다양한 모듈이 다른 사용자에 의해 소유 및 관리될 수 있습니다.HPI를 사용하여 이를 지원하기 위해 특정 사용자가 소유한 모듈을 관리하기 위해 사용되는 모든 리소스를 단일 도메인에 배치할 수 있으며 해당 사용자는 해당 도메인에 대한 액세스 권한만 부여받을 수 있습니다.
HPI 사용자 프로그램은 특정 HPI 도메인과의 세션을 열어 플랫폼 관리 인프라스트럭처에 액세스합니다.이 세션이 확립되면 사용자 프로그램은 다양한 HPI 함수를 호출하여 해당 도메인 또는 현재 해당 도메인의 멤버인 리소스에 대한 정보를 조회 또는 업데이트할 수 있습니다.
HPI Management Instruments는 도메인과 리소스에 의해 구성 및 처리되지만 이들 Management Instruments가 관리하는 하드웨어 컴포넌트는 각 Management Instrument와 관련된 RDR에서 개별적으로 식별됩니다.HPI의 물리 하드웨어 컴포넌트는 엔티티라고 불리며 엔티티 패스로 식별됩니다.엔티티 경로에는 여러 요소가 포함됩니다.첫 번째 요소는 하드웨어 엔티티가 포함된 엔티티 내의 위치를 나타내고 두 번째 요소는 엔티티가 더 큰 컨테이너 내의 위치를 나타냅니다.예를 들어 여러 랙에 걸쳐 있는 시스템의 섀시에 대한 다중 전원 장치의 엔티티 경로가 POWER_SUBRACK.2, SUBRACK.3, RACK.1일 수 있습니다.
각 Management Instrument는 특정 엔티티 경로와 관련되어 있기 때문에 1개의 HPI 리소스가 여러 엔티티의 플랫폼 관리를 처리할 수 있습니다.여러 HPI 리소스를 통해 단일 엔티티를 관리할 수도 있습니다.HPI 리소스와 관리 대상 하드웨어 엔티티가 임의로 조합될 가능성은 혼란스러워 보이지만 HPI 아키텍처의 중요한 기능입니다.이는 단일 하드웨어 엔티티의 대역내 및 대역외 관리 요소를 모두 포함하는 복잡한 관리 인프라스트럭처의 모델링을 가능하게 하며, 한 기기의 관리 컨트롤러가 다른 기기의 관리를 제공하는 시스템도 가능하게 하기 때문입니다.
관리 도구
HPI 리소스는 일련의 Management Instruments를 호스트할 수 있습니다.각 Management Instrument는 하드웨어 엔티티의 일부 측면을 감시 또는 제어하는 기능을 모델링합니다.각 자원의 RDR 세트에는 감시 또는 제어 대상 정보를 포함하여 해당 리소스가 호스팅하는 Management Instruments가 설명되어 있습니다.
플랫폼 관리 인프라스트럭처의 다양한 기능을 모델링하기 위해 사용할 수 있는 Management Instruments에는 7가지 유형이 있습니다.첫 번째 네 가지:센서, 컨트롤, 인벤토리 데이터 저장소 및 워치독 타이머는 일반적으로 개별 플랫폼 관리 기능에 매핑되는 기본적인 관리 도구입니다.나머지 세 가지:어넌시에이터, DIMI 및 FUMI는 플랫폼 관리 인프라스트럭처가 제공할 수 있는 보다 복잡하고 논리적인 기능을 캡슐화합니다.
센서
센서는 엔티티의 일부 측면을 모니터링하는 기능을 모델링하는 데 사용됩니다.HPI 센서는 IPMI 센서를 기반으로 모델화되어 있습니다.
HPI 센서는 이벤트 상태라고 불리는 최대 15개의 개별 비트 세트를 통해 모니터링되는 하드웨어에 대한 상태 정보를 보고합니다.각 이벤트 상태는 개별적으로 아사트 또는 아사트 해제 가능하며 이벤트 상태가 변경되면 비동기 이벤트를 생성하여 HPI 사용자에게 보고할 수 있습니다.각 이벤트 상태의 해석은 정의된 센서 범주(예: 임계값, 성능, 존재감, 심각도)에 따라 다르거나 특정 센서에 대해 고유할 수 있습니다.임계값 범주의 센서에는 추가 기능이 있습니다.임계값 센서는 모니터링되는 값이 설정 가능한 임계값을 초과하거나 밑돌면 보고합니다.어느 방향으로든 표준으로부터의 Minor, Major 및 Critical 편차에 대해 최대 3개의 상한 임계값과 3개의 하한 임계값을 정의할 수 있습니다.
HPI 센서는 이벤트 상태를 통해 모니터링되는 하드웨어의 상태를 보고할 뿐만 아니라 센서 판독치라는 값도 보고할 수 있습니다.센서 판독값은 모니터링 중인 모든 항목의 현재 값을 해당 단위로 축척하여 반영합니다.센서 판독치는 정수 값, 부동 소수점 값 또는 최대 32바이트의 임의 데이터 블록일 수 있습니다.
컨트롤
컨트롤은 엔티티의 일부 측면을 업데이트하는 기능을 모델링하는 데 사용됩니다.HPI에는 몇 가지 유형의 컨트롤이 정의되어 있으며, 이러한 컨트롤은 업데이트 시 사용할 수 있는 데이터의 유형에 따라 달라집니다.디지털 컨트롤은 켜거나 끌 수 있으며 펄스를 켜거나 끌 수 있습니다.아날로그 및 이산 컨트롤은 32비트 값으로 설정할 수 있습니다.스트림 및 텍스트 컨트롤은 LED의 깜박임, 신호음 울림 또는 제어판의 데이터 표시를 제어하기 위해 더 많은 양의 데이터를 제공할 수 있습니다.OEM(벤더 고유) 제어는 데이터 블록을 전송할 수 있으며, 관리 엔티티에 의해 구현 고유의 방식으로 사용될 수 있습니다.
인벤토리 데이터 저장소(IDR)
인벤토리 데이터 저장소는 하드웨어 엔티티에 대한 식별 및 구성 정보를 보고하거나 설정하는 데 사용됩니다.일반적으로 모델 번호, 시리얼 번호, 기본 구성 데이터 등의 항목은 하드웨어 엔티티의 ROM 또는 플래시 메모리에 저장됩니다.이 정보는 HPI 인벤토리 데이터 저장소를 통해 읽을 수 있으며 경우에 따라 업데이트될 수 있습니다.
워치독 타이머
워치독 타이머는 하이 어베이러빌리티 시스템에서 특수한 하드웨어와 함께 구현되는 디바이스입니다.이러한 장치는 먼저 프로그래밍 방식으로 재설정되지 않은 경우 일정 시간 후 엔티티를 자동으로 중단, 재설정 또는 전원 껐다 켜도록 설정됩니다.워치독 타이머 디바이스의 목적은 장애 검출 메커니즘을 제공하는 것입니다.HPI Watchdog Timer Management Instrument는 이러한 종류의 하드웨어 메커니즘과 상호 작용하도록 설계되었습니다.이것은 IPMI 워치독타이머에 따라 매우 밀접하게 모델화되어 있습니다.
어넌시에이터
어넌시에이터는 하드웨어 플랫폼에서 알람 표시 기능과 인터페이스하는 데 사용되는 논리적 Management Instruments입니다.LED, 가청 경보, 텍스트 표시 패널 등 다양한 알람 표시 하드웨어가 다른 하드웨어 플랫폼에서 사용되기 때문에 플랫폼에 의존하지 않고 알람 정보를 표시하기 위한 애플리케이션 프로그램 작성은 어렵습니다.HPI Annunciator Management Instrument는 알람 정보를 HPI 구현 또는 기본 관리 인프라스트럭처에 전달하는 추상 인터페이스를 제공합니다.그러면 HPI는 특정 플랫폼에 해당 정보를 표시하기 위한 적절한 조치를 취할 수 있습니다.
DIMI(진단 이니시에이터 관리 기기)
DIMI는 다양한 하드웨어 엔티티에서 온라인 또는 오프라인 진단 펌웨어 또는 소프트웨어의 실행을 조정하기 위해 사용되는 논리 관리 도구입니다.DIMI는 진단 실행이 서비스에 미치는 영향을 나타내는 정보를 HPI 사용자 프로그램에 제공하고 진단 프로그램의 실행 시작, 중지 및 감시를 위한 공통 인터페이스를 제공합니다.이 기능은 HPI와 통합되어 고장 상태의 자동 진단 및 수리를 표준화하고 온라인 서비스 가용성을 지원합니다.
펌웨어 업그레이드 관리 기기(FUMI)
FUMI는 프로그램 가능한 하드웨어 엔티티에 대한 펌웨어 업데이트 설치를 지원하기 위해 사용되는 논리 관리 도구입니다.현장에서 업그레이드 가능한 펌웨어를 포함하는 하드웨어 엔티티의 경우 FUMI는 현재 설치되어 있는 펌웨어 버전에 대한 정보를 제공하고 로드하는 새로운 버전을 식별하기 위한 표준 인터페이스를 제공합니다.또한 업그레이드프로세스를 조정하기 위한 표준 인터페이스(필요한 경우 백업 및 이전 버전으로의 롤백 포함)도 제공합니다.
자원 레벨의 기능
위의 Management Instruments 세트 외에 HPI 리소스는 최대 4개의 추가 관리 기능을 제공할 수 있습니다.이러한 자원 레벨의 기능은 기본적으로 특수한 관리 수단이며, 자원에서는 각 타입별로 최대 1개까지 지원할 수 있습니다.특정 리소스가 이러한 다양한 기능을 제공하는지 여부와 이러한 기능을 적용하는 엔티티는 HPI 사용자가 해당 리소스에 액세스할 수 있는 데이터 레코드에 설명되어 있습니다.이 레코드에는 1개의 엔티티 패스가 정의되어 있기 때문에, 이러한 기능이 존재하는 경우는, 같은 엔티티에 적용됩니다.
- 자원 레벨의 전원 관리 기능은, 지정된 엔티티의 전원을 온/오프 하는 특수한 컨트롤로서 기능합니다.
- 자원 레벨의 리셋 기능은 지정된 엔티티에서 하드 리셋 또는 소프트 리셋 조작을 일으키거나 지원되고 있는 경우 엔티티가 동작하지 않도록 리셋 신호를 아사트 상태로 유지하는 특수한 컨트롤 역할을 합니다.
- 리소스 수준의 로드 관리 기능은 지정된 엔티티의 부트스트랩 프로그램과 연계하여 부트스트랩 조작이 실행될 때 로드해야 하는 운영 체제 또는 기타 소프트웨어를 식별하는 특수 제어 역할을 합니다.
- 리소스 수준 구성 관리 기능을 사용하면 HPI 사용자가 영구 스토리지 미디어 간에 센서 임계값 수준 등의 구성 정보를 저장 또는 복원하도록 리소스에 지시할 수 있습니다.
도메인 함수
사용자 프로그램은 도메인과의 세션을 열어 HPI 기반 플랫폼 관리에 액세스합니다.사용자 프로그램은 도메인 식별자를 지정하여 특정 도메인과의 세션을 열 수 있으며, 더 일반적으로 기본 도메인으로 세션을 열 수도 있습니다.세션이 확립되면 사용자 프로그램은 다양한 도메인 수준의 기능에 액세스하거나 현재 도메인의 구성원으로 나열된 리소스에 액세스할 수 있습니다.세션에서는 현재 도메인의 멤버인 리소스에 대한 액세스만 허용되므로 HPI 구현에서는 각 도메인의 멤버인 리소스를 제한하고 해당 도메인과의 세션을 확립할 수 있는 사용자를 제한함으로써 사용자 액세스 제어를 수행할 수 있습니다.
도메인의 가장 중요한 기능 중 하나는 RPT(Resource Presence Table)를 통해 도메인의 구성원인 모든 리소스에 대한 정보를 제공하는 것입니다.두 번째 표인 Domain Reference Table(DRT; 도메인 참조 테이블)은 추가 세션을 열어 액세스할 수 있는 다른 HPI 도메인에 대한 정보를 제공합니다.
HPI 인터페이스는 도메인 레벨에서 3개의 서비스를 제공하며, 사용자 프로그램은 하드웨어 플랫폼의 예외적인 상태를 지속적으로 파악할 수 있습니다.그 중 가장 중요한 것은 이벤트 관리 서비스입니다.사용자는 열려 있는 세션에서 도메인에서 이벤트 전송을 요청할 수 있습니다.도메인의 멤버인 리소스 중 하나에 의해 감시되는 하드웨어 엔티티에 중요한 이벤트가 발생하면 이벤트메시지가 생성되어 이러한 요구를 한 모든 열린 세션에 큐잉됩니다.이 메커니즘을 통해 사용자 프로그램은 상태를 지속적으로 폴링할 필요 없이 관리 대상 플랫폼의 변경 사항을 계속 파악할 수 있습니다.이벤트는 도메인 이벤트 로그에 저장했다가 나중에 이력 분석을 위해 가져올 수도 있습니다.마지막으로 도메인 알람테이블은 사용자 프로그램에서 액세스할 수 있으며 도메인의 멤버인 리소스에 존재하는 현재 알람 상태를 보고합니다.
핫 스왑 관리
HPI 사양의 주요 기능은 관리 플랫폼에서의 동적 재구성 또는 핫 스왑 작업을 처리하는 방법입니다.핫스왑이란 실행 중인 플랫폼에서 하드웨어 컴포넌트를 추가 또는 삭제하는 기능을 말합니다.HPI는 필드 교환 가능 유닛(FRU)으로 핫 스왑할 수 있는 하드웨어 엔티티를 말합니다.많은 경우, 특히 Advanced 등의 시스템 아키텍처에서는TCA, FRU에는 자체 플랫폼 관리 컨트롤러가 포함되어 있습니다.따라서 FRU를 핫스왑하면 관리하는 하드웨어 엔티티 세트와 해당 관리에 사용할 수 있는 인프라스트럭처를 동시에 변경할 수 있습니다.
핫 스왑 관리에 대한 HPI 접근법은 도메인 내의 리소스를 추가 또는 삭제함으로써 하드웨어 엔티티의 추가 또는 삭제를 모델링함으로써 이를 반영합니다.FRU에 자체 관리 컨트롤러가 포함되어 있지 않은 경우 리소스에는 관리 기능이 할당되어 있지 않을 수 있지만 FRU가 시스템에 존재함을 보고하기 위해 사용됩니다.한편 FRU에 관리 컨트롤러가 포함되어 있는 경우 도메인에 추가된 리소스는 새로운 Management Instruments 또는 기타 기능을 호스트하여 HPI 사용자가 사용할 수 있도록 할 수 있습니다.
FRU와 관련된 리소스는 항상 HPI 사용자가 읽을 수 있는 5개의 핫 스왑 상태 중 하나입니다.없음, 비활성, 삽입 보류 중, 활성, 추출 보류 중.시스템에 FRU가 존재하지 않는 경우 리소스가 도메인의 구성원으로 존재하지 않기 때문에 실제로 리소스에 의해 존재하지 않는 상태는 보고되지 않음 상태는 리소스에 의해 보고되지 않습니다.그 외의 4개의 상태는, 완전하게 동작하고 있는지 아닌지에 관계없이, 시스템에 물리적으로 존재하는 FRU 에 적용할 수 있습니다.리소스가 새로운 핫 스왑 상태로 변경되면 HPI 이벤트가 이벤트 알림을 요청한 사용자 프로그램으로 전송됩니다.
핫 스왑 대응 FRU를 모델화하는 HPI 리소스는 관리 대상 외 핫 스왑 또는 관리 대상 핫 스왑 중 하나를 지원하도록 구성할 수 있습니다.관리대상 외 핫스왑을 지원하는 리소스는 현재 핫스왑 상태를 보고하지만 사용자는 FRU의 핫스왑 작업을 제어할 수 없습니다.리소스가 관리 대상 핫스왑을 지원하는 경우 사용자 프로그램은 HPI 구현 및 기본 플랫폼 관리 인프라스트럭처와 상호 작용하여 필요한 작업을 조정할 수 있습니다.새로 추가된 FRU를 통합하거나 시스템에서 삭제되는 FRU를 비활성화합니다.
하위 호환성
SA 포럼의 목표는 새로운 버전의 사양이 이전 버전과 하위 호환되도록 유지하는 것입니다.HPI 사양의 경우, 이는 특정 버전의 HPI 구현과 함께 작업하도록 작성된 사용자 프로그램이 최신 버전의 사양을 지원하는 HPI 구현과 함께 변경되지 않고 계속 작동해야 함을 의미합니다.이 목표는 SAI-HPI-B.01 규격 이후 발표된 HPI 규격으로 충족되었습니다.HPI 사양의 "B" 시리즈는 SAI-HPI-A.01.01 사양과 하위 호환성이 없습니다.
HPI 규격의 하위 호환성을 달성하기 위해 다음과 같은 몇 가지 전략이 사용됩니다.
a) 이전 버전의 HPI 규격에 정의된 기능은 최신 버전에 포함되며 기능 프로토타입은 변경되지 않습니다.오래된 기능은 유지되지만 새로운 사용자 프로그램에서 사용하지 말라는 조언이 사양에 포함되어 있습니다.
b) 기존 프로그램에 의해 새로운 기능이 필요하지 않은 한 새로운 버전의 HPI 사양에 새로운 기능이 추가될 수 있습니다.
c) HPI 사양에서는 하드웨어 엔티티 유형, 센서 유형 등의 데이터를 보고하는 다양한 열거가 오픈 엔드로 선언되어 있습니다.HPI 함수가 반환할 수 있는 오류 반환 코드 목록도 오픈 엔드로 선언됩니다.HPI 사양의 새 버전에서는 기존 열거 값을 제거하거나 변경하지 않지만 열려 있는 열거에 새 값이 추가될 수 있습니다.사용자 프로그램은 현재 정의되지 않은 값을 받아들여 "유효하지만 정의되지 않음"으로 취급해야 합니다.이렇게 함으로써 프로그램이 HPI 사양의 새로운 버전에 구축된 구현과 함께 사용되었을 때 계속 작동할 수 있습니다. HPI 사양은 열거에 대한 새로운 값을 정의했을 수 있습니다.
d) HPI 기능에서 사용자에게 전달되는 데이터 구조는 새로운 버전의 HPI 사양에서 길이가 증가하거나 이전 버전에서 정의된 데이터 형식을 변경할 수 없습니다.단, 비트필드에서 이전에 정의되지 않은 비트는 HPI 사양의 새로운 버전에서 정의될 수 있으며 새로운 비트 또는 사용되지 않는 공간의 새로운 사용을 인식하지 않는 프로그램이 계속 올바르게 동작하는 한 유니언에서 사용되지 않는 공간을 사용할 수 있습니다.
e) 사용자로부터 HPI 기능에 전달된 데이터 구조는 HPI 사양의 새로운 버전에서 변경될 수 있습니다.단, 이전에 정의된 구조를 통과하는 기존 프로그램이 계속 올바르게 작동하는 방식으로 변경되는 한 변경될 수 있습니다.
HPI에서 xTCA로의 매핑 사양
HPI는 Advanced에서 널리 사용되고 있기 때문에TCA 시스템, SA 포럼은 2006년 1월에 SAIM-HPI-B.01.01-ATCA라는 라벨이 붙은 매핑 사양을 발표했습니다.이 사양의 목적은 HPI 관리 인터페이스 구현자에게 HPI를 사용하여 복잡한 시스템 아키텍처를 모델링하기 위한 권장 방법을 안내하는 것입니다.2010년 2월에 새로운 맵핑 사양 SAIM-HPI-B.03.02-xTCA가 발표되었습니다.이러한 맵핑은 수정되어 MicroTCA 시스템으로 확장됩니다.
HPI에서 xTCA로의 매핑 사양은 HPI에서 xTCA 플랫폼의 관리성을 단일 HPI 도메인에서 나타내는 방법을 정의합니다.xTCA 시스템컴포넌트의 엔티티 패스의 이름이 지정되어 있으며 Management Instruments는 이러한 플랫폼에서 사용할 수 있는 플랫폼 관리 정보와 제어 기능을 반영하여 정의되어 있습니다.
매핑 사양에서는 xTCA 섀시, 쉘프 매니저, 캐리어 매니저 및 기타 FRU 자원도 정의합니다.사양의 원래 버전에서는 리소스가 섀시 또는 FRU를 호스트할 가능성이 있는 캐리어 카드 상의 모든 "슬롯"에 대해 정의되어 필요했습니다.2010년에 발행된 업데이트에서는 이러한 슬롯 리소스는 옵션으로 지정되었습니다.
HPI에서 xTCA로의 매핑 사양은 2명의 독자에게 제공됩니다.첫 번째는 플랫폼 개발자로 구성되며, 이들은 HPI 인터페이스를 Advanced에 통합하고자 합니다.TCA 또는 MicroTCA 플랫폼.사양은 시스템을 모델링하기 위한 템플릿을 제공합니다.
두 번째 대상자는 여러 Advanced에서 휴대용 애플리케이션 또는 미들웨어 프로그램을 만들고 싶은 HPI 사용자입니다.TCA 또는 MicroTCA 플랫폼단, xTCA 및 기타 하드웨어 플랫폼 아키텍처용 휴대용 프로그램을 제공하고자 하는 HPI 사용자는 반드시 HPI와 xTCA의 매핑 사양을 참조할 필요는 없습니다.이는 HPI에서 xTCA로의 매핑 사양에 따라 HPI를 구현하면 표준 HPI 인터페이스를 통해 검출 및 사용할 수 있는 기본적인 플랫폼 관리 기능이 제공되기 때문입니다.xTCA 플랫폼 고유의 플랫폼 관리 기능 중 일부는 매핑 사양을 참조하지 않으면 사용할 수 없지만 대부분의 범용 HPI 사용자 애플리케이션에 의해 이러한 기능은 무시될 수 있습니다.
HPI 구현
HPI 사양의 광범위한 구현이 몇 가지 이루어졌으며, 특히 Advanced를 구축한 플랫폼 벤더가 그 대부분을 차지하고 있습니다.TCA 컴퓨터 시스템 또는 기타 고가용성 컴퓨터 플랫폼.대부분의 구현에서는 HPI Application Program Interface 자체가 애플리케이션 프로그램에 링크된 라이브러리를 통해 제공됩니다.이 라이브러리 모듈은 일반적으로 데몬 프로세스로 실행되는 HPI 서버와 통신합니다.HPI 서버는 HPI 도메인 및 리소스의 기능을 수행하며 필요에 따라 기본 관리 인프라스트럭처와 통신합니다.
여러 HPI 구현은 OpenHPI라고 불리는 HPI 규격의 오픈 소스 구현을 기반으로 합니다.또한 OpenHPI는 애플리케이션 프로그램과 링크하는 라이브러리 모듈과 라이브러리 모듈이 통신하는 데몬 모듈을 포함하고 있다는 점에서 그림 6과 같은 일반적인 설계를 따릅니다.오픈HPI 데몬 프로세스는 다양한 플랫폼 관리 인프라스트럭처와의 다운스트림 통신을 처리하는 하나 이상의 플러그인 모듈과 통합되도록 설계되었습니다.
SA Forum[permanent dead link] Implementation Registry는 SA Forum 사양의 구현을 등록하고 공개적으로 이용할 수 있도록 하는 프로세스입니다.구현을 등록하기 위해 멤버십이 필요하지 않습니다.정상적으로 등록된 구현을 "Service Availability Forum Registered"라고 부릅니다.
