KR100938718B1

KR100938718B1 - 플랫폼 관리 능력을 ｏｓ에 반출하기 위한 ｅｆｉ 기반메커니즘

Info

Publication number: KR100938718B1
Application number: KR1020070083026A
Authority: KR
Inventors: 판카즈 엔. 파마; 아자이 가르그
Original assignee: 인텔 코오퍼레이션
Priority date: 2006-08-18
Filing date: 2007-08-17
Publication date: 2010-01-26
Also published as: GB2441043A; NL2000811C2; GB2441043B; JP5182681B2; CN101131639A; DE102007039156A1; JP2008102906A; NL2000811A1; US20080046546A1; JP2012119000A; GB0715814D0; KR20080016505A

Abstract

본 발명의 소정의 실시예들에서, 아키텍처는 플랫폼 관리능력을 향상시키는 CM(capability Module)로 불리는 제3자측 관리 능력 확장들을 실행시킬 수 있는 호스트 OS에 독립적인 보안 실행 환경을 제공하기 위해 플랫폼 관리능력을 위한 크로스 플랫폼 스펙을 포함한다. 본 발명의 적어도 하나의 실시예는 자치적, 유틸리티, 및 온 디멘드(on-demand) 컴퓨팅을 가능하게 한다. OS 센서 효과기는 OS의 건강에 대한 정보를 플랫폼 관리능력(PM) 컴포넌트에 EFI 서비스들을 이용하여 송신한다. PM 컴포넌트는 재난 상황들로부터 회복하기 위해 회복 조치들 또는 가능한 치명적인 조건 또는 OS가 심각한 성능 열화에 처해질 수 있는 조건을 방지하기 위한 추천 조치들을 호스트 OS에 강제할 수 있다. 다른 실시예들이 기술되고 주장된었다.

BIOS, EFI, PM 컴포넌트, 호스트 OS, 회복

Description

플랫폼 관리 능력을 ＯＳ에 반출하기 위한 ＥＦＩ 기반 메커니즘{EFI BASED MECHANISM TO EXPORT PLATFORM MANAGEMENT CAPABILITIES TO THE OS}

본 발명의 실시예는 일반적으로 컴퓨팅 시스템들에 관련되고, 더 구체적으로는 플랫폼 관리능력(platform manageability)을 위한 크로스 플랫폼 스펙(cross platform specification)을 포함하는 아키텍처에 관한 것이다.

외부 소스로부터 플랫폼을 관리하기 위해 다양한 메커니즘들이 존재한다. 기존의 서버들은 원격 관리 시스템과 정보를 통신하기 위해 베이스보드 관리 컨트롤러(baseboard Management Controller: BMC) 프로세서를 활용할 수 있다. 다른 방법들은 서버, 데스크탑(desktops), 랩탑(laptops) 등에 대한 원격 플랫폼 관리를 가능하게 하기 위해 현재 개발중에 있을 수 있다. 많은 관리능력 메커니즘들은 관리될 플랫폼 상의 호스트 운영 시스템(OS)의 이용을 필요로 한다.

본 발명의 특징 및 이점은 본 발명의 다음의 상세한 설명으로부터 명백해질 것이다. 본 발명의 실시예는 호스트 운영 시스템에 독립적인 안전한 실행 환경을 제공하는 크로스-플랫폼 관리 아키텍처(cross-platform management architecture)를 이용하는 것에 관련된 시스템 및 방법이다. 적어도 일 실시예에서, 본 발명은 자치적(autonomic), 유틸리티, 및 온-디멘드 컴퓨팅(on-demand computing)을 가능하게 하고자 하는 것이다.

본 발명의 플랫폼 관리능력을 위한 시스템은, EFI(exensible firmware interface) 어웨어 플랫폼 펌웨어(BIOS) 및 호스트 OS(operating system)를 운영하기 위한 호스트 프로세서 -호스트 OS는 호스트 OS의 건강 및 성능에 관련된 정보를 플랫폼 관리능력(platform manageability) 컴포넌트에 전달하기 위한 OS 센서 드라이버를 가짐- 및 CM(capability module)이 호스트 OS 건강 및 성능에 관련된 정보를 처리할 수 있게 하는 센서 효과기 인터페이스(sensor effector interface: SEI)를 포함하는, OS와 독립적으로 작동하는 PM(platform manageability) 컴포넌트를 포함한다.

본 발명의 플랫폼 관리능력을 위한 방법은, 플랫폼 상의 호스트 OS를 OS 센서 드라이버에 의해 감시하여 OS 건강 상태를 판정하고 OS의 성능 정보를 모으는 단계; OS의 건강 상태 및 성능 정보를 PM 컴포넌트에 전달하기 위해 EFI 서비스를 호출하는 단계; 및 SEI를 통하여 PM 컴포넌트에 의해 OS의 건강 및 성능 정보를 수신하는 단계를 포함하며, PM 컴포넌트는 OS에 독립적으로 작동하는 방법이다.

본 발명의 머신 판독 가능 매체는, 저장된 명령어들을 갖는 머신 판독 가능 매체로서, 명령어들은 실행될 때 머신이, OS 센서 드라이버에 의해 플랫폼 상의 호스트 OS를 감시하여 OS의 건강 상태를 식별하고 OS의 성능 정보를 모으고, OS의 건강 상태 및 성능 정보를 PM 컴포넌트에 전달하기 위해서 EFI 서비스를 호출하고, SEI를 통하여 PM 컴포넌트에 의해 OS의 건강 및 성능 정보를 수신하도록 하며, PM 컴포넌트는 OS에 독립적으로 작동하는 머신 판독 가능 매체이다.

본 발명에 따르면, 자치적(autonomic), 유틸리티, 및 온-디멘드 컴퓨팅(on-demand computing)이 가능하게 된다.

명세서에서 본 발명의 "일 실시예" 혹은 "실시예"의 참조는 실시예와 연관되어 기술되는 특별한 특징, 구조, 혹은 특성이 본 발명의 적어도 일 실시예에 포함된다는 것을 의미한다. 따라서, 명세서를 통해 여러 군데에서 나타나는 "일 실시예에서"라는 문구의 출현은 반드시 모두 동일한 실시예를 참조하는 것은 아니다.

설명을 위해, 특수한 구성 및 상세한 사항들이 본 발명의 완전한 이해를 제공하기 위해 설명된다. 그러나, 본 발명의 실시예들은 본 명세서에 제시된 특수한 상세한 사항들이 없이도 실시될 수 있다는 것은 당업자에게 자명할 것이다. 또한, 본 발명을 모호하게 하지 않기 위해 공지된 특징들은 생략되거나 간략화된다. 이 설명을 통해 다양한 예들이 주어질 수 있다. 이들은 단순히 본 발명의 특수한 실시예들의 설명일 뿐이다. 본 발명의 범위는 주어진 예들로 제한되는 것이 아니다.

도 1은 실시 환경의 예에 따른, 플랫폼 관리 마이크로컨트롤러(PM μ컨트롤러)를 갖는 플랫폼의 특징들을 예시하는 블럭도이다. 플랫폼(100)은 호스트 프로세서(101)를 포함한다. 프로세서(101)는 메모리 컨트롤러 허브(103)를 통해 RAM(Random Access Memory)(105)에 접속될 수 있다. 프로세서(101)는 소프트웨어를 실행할 수 있는 임의의 타입의 프로세서일 수 있는데, 예를 들면 마이크로프로세서, 디지털 신호 프로세서, 마이크로컨트롤러 등일 수 있다. 도 1이 단지 하나의 그러한 프로세서(101)를 나타내지만, 플랫폼(100)에는 하나 이상의 프로세서들이 있을 수 있고, 하나 이상의 프로세서들이 다수의 스레드(threads), 다수의 코어(cores), 등을 포함할 수 있다.

프로세서(101)는 입력/출력 컨트롤러 허브(I/O controller hub: ICH)(107)를 통해 I/O 장치들에 더 접속될 수 있다. ICH는 로우 핀 카운트(low pin count: LPC) 버스(102)를 통해 다양한 장치들, 예를 들면, 수퍼 I/O 컨트롤러(super I/O controller: SIO), 키보드 컨트롤러(Keyboard controller: KBC), 혹은 신뢰되는 플랫폼 모듈(trusted platform module: TPM)에 결합될 수 있다. 예를 들어, SIO는 플로피 드라이브들(floppy drives), 혹은 ISA(Industry Standard architecture) 장치들에 대한 액세스를 가질 수 있다. 실시예에서, ICH는 SPI(Serial Peripheral Interface) 버스(104)를 통해 비휘발성 메모리에 결합된다. 비휘발성 메모리는 플래시 메모리(flash memory) 혹은 SRAM(Static Random Access Memory), 등일 수 있 다. 플랫폼 관리 μ컨트롤러(110n)는 플랫폼(100) 상에 존재할 수 있다. PM μ컨트롤러(110n)는 버스(112), 전형적으로 PCI(Peripheral component Interconnect: PCI) 혹은 PCI 익스프레스(Express) 버스를 통해 ICH에 접속될 수 있다. PM μ컨트롤러는 또한 SPI 버스(104)를 통해 비휘발성 메모리 저장소(NV 저장소)(117)와 결합될 수 있다. NV 저장소(117)는 플래시 메모리 혹은 SRAM 등일 수 있다. 많은 기존의 시스템들에서, NV 저장소는 플래시 메모리이다.

실시예들에서, PM μ컨트롤러(110n)는 "미니어처(miniature)" 혹은 내장된 프로세서에 비유될 수 있다. 전체 능력(full capability) 프로세서와 같이, PM μ컨트롤러는 RAM 및 ROM 메모리(113) 뿐만 아니라 캐시 메모리(115)에 동작적으로 결합될 수 있는 프로세서 유닛(111)을 갖는다. PM μ컨트롤러는 호스트 프로세서(101)가 활성이지 않을 때에도 대역외 통신을 가능하게 하기 위해 전원 공급장치(125)에 대한 내장 네트워크 인터페이스 및 독립적 접속을 가질 수 있다.

실시예들에서, 프로세서(101)는 NV 저장소(117) 내에 BIOS(Basic Input Output System)(119)를 갖는다. 다른 실시예들에서, 프로세서(101)는 원격 장치(도시되지 않음)로부터 부트(boots)하고, 부트 벡터(포인터)는 NV 저장소(117)의 BIOS 부분(119) 내에 상주한다. PM μ컨트롤러는 비휘발성 메모리의 BIOS 부분(119)과 보호된 부분(121)을 포함하여 NV 저장소(117)의 모든 컨텐트들에 대한 액세스를 가질 수 있다. 소정의 실시예들에서, 메모리의 보호된 부분(121)은 Intel

Active Management Technology(IAMT)로 보안될 수 있다. PM μ컨트롤러는 IAMT 소프트웨어 스택을 실행할 수 있다. IAMT에 관한 더 많은 정보는 URL www-intel-com/technology/manage/iamt/에 있는 공공 인터넷 상에서 찾아질 수 있다.(무심코 한 하이퍼링크(hyperlinks)를 회피하기 위해 본 명세서에 포함된 URL들에는 점(.)이 대시(-)로 대체된 것을 유의한다.)

비휘발성 메모리의 BIOS 부분이 OS 또는 OS 내에서 실행하는 에플리케이션들에 의해 변경될 수 있기 때문에, 악성 위조(malicious tampering)에 취약할 수 있다. 실시예들에서, PM μ컨트롤러에만 가용일 수 있는 메모리(121)의 보호된 영역은 위조의 위험 없이 중요한 부트 벡터 및 다른 정보를 저장하기 위해 이용될 수 있다. NV 저장소(117)의 PM μ컨트롤러측을 액세스하기 위한 유일한 방법은 PM μ컨트롤러를 통해 프록시(proxy)를 거쳐 인증을 통한 것, 즉 서명 인증 등과 같은 것을 통한 것일 수 있다.

많은 기존의 시스템들은 확장 가능한 펌웨어 인터페이스(Extensible Firmware Interface: EFI) 기반 플랫폼 펌웨어 및 그의 연관된 플래시 변수들을 이용한다. EFI는 BIOS로서 공지되어 있는, 운영 시스템들과 플랫폼 펌웨어 사이의 인터페이스를 위한 새로운 모델을 정의하는 스펙이다. 2002년 12월 1일 발행된 스펙 버전 1.10이 URL developer-intel-com/technology/efi/main_specification.htm에 있는 공공 인터넷에서 입수 가능하다.

본 발명의 실시예들은 플랫폼 관리능력을 위해 크로스 플랫폼 스펙을 포함하는 아키텍처를 이용할 수 있다. 도 2를 참조하면, 이 아키텍처는 소위 CM(Capability Modules)(253)으로 불리는 제3 자측 관리 능력 확장들을 실행할 수 있는 호스트 운영 시스템(210)과는 독립적인 실행 환경(230)을 가능하게 해줄 수 있다. CM(253)은 네트워크를 통해 동적으로 로드될 수 있고 PM(230)의 실행 환경 내로 삽입될 수 있는 바이너리 컴포넌트이다. CM(253)은 PM에 의해 제공되는 관리능력 기능성을 확장한다. CM(253)은 작동하기 위해 PM 런타임 환경(230)에 의해 제공되는 서비스들의 세트에 의존하고, 또한 센서 데이터를 수집하고 조치를 취하기 위해 예를 들면 SEI(231) 등의 상이한 인터페이스들을 이용한다. PM 런타임 환경(230)은 플랫폼 관리능력 경영 인터페이스(Platform Manageability Administrative Interface: PMAI)(239), 센서 효과기 인터페이스(Sensor Effector Interface: SEI)(231), 외부 동작 인터페이스(External Operations Interface: EOI)(237) 등과 같은 다수의 인터페이스들을 노출한다. 이 인터페이스들 각각은 고유의 목적을 수행한다.

EOI(237)는 외부 엔티티들이 PM 런타임 환경(230)을 원격으로 액세스하고 제어하도록 해준다. EOI(237)는 플랫폼 능력(platform capability), 센서, 자산 정보, 실행된 진단 에플리케이션, 시스템 준비 등의 발견 등과 같은 기능을 제공한다. PMAI(239)는 PM 런타임 환경(230)을 제어하기 위해 경영(administrative) 기능을 제공한다. PMAI(239)는 드라이버들, OS, CM들의 문의/패칭(querying/patching), CM들의 설치/삭제/시작/정지, PM 시작/정지 등과 같은 동작들을 허용한다. SEI(231)는 시스템 상의 장치들의 열거, 센서 데이터 판독, 효과기 데이터 기입 등을 일반적으로 허용하는 기능들을 정의한다. PMAI(239)와 EOI(237)는 IT 경영자에 의해 원격으로 호출(invoke)될 수 있다. 아키텍처는 호스트 운영 시스템(OS)(210)과 협동하기 위한 임의의 인터페이스 혹은 메커니즘을 정의하지 않는다. 데스크탑, 서버 혹은 휴대용 기기들 상에서 실행하는 플랫폼 관리 솔루션은 OS와 연동시에 더 많은 유연성과 제어를 제공할 수 있다. PM과 호스트 OS(210) 사이의 인터페이스는 225로 도시된다.

본 발명의 실시예들은 OS 상에서 실행하는 로컬 관리 엔티티(205)가 플랫폼 관리능력 컴포넌트(230)와 통신하는 것을 가능하게 해주기 위한, 그리고 플랫폼 관리능력 컴포넌트가 EFI(Extensible Firmware Interface) 런타임 서비스들(220(207, 209, 211)을 통해 OS 활동을 감시하도록 해주기 위한 메커니즘을 포함한다. 실시예들에서, 아키텍처는 플랫폼 관리능력 기반구조가 OS 건강을 감시하도록 허용하는 OS(210)와 관련하여 실행하는 "OS 센서들"(203)을 활용한다. EFI 런타임 드라이버들(220)은 OS 센서 정보가 플랫폼 관리능력 기반구조(230)에 제공될 수 있도록 인터페이스를 반출한다. EFI 런타임 드라이버는 또한 OS 센서 드라이버가 PM 런타임 환경(230)과 관련하여 실행하는 OS 특정 CM으로부터 명령들을 수신할 수 있도록 인터페이스를 노출한다. 플랫폼 관리능력 인터페이스를 OS에 노출하고, 플랫폼 관리능력 기반구조가 OS 활동을 감시하고 OS 회복 동작들을 제어하도록 허용함으로써, 본 발명의 실시예들은 기존의 플랫폼 관리능력 아키텍처를 보충하는 다기능의 관리 솔루션을 제공한다. 본 발명의 실시예들은 도 3과 관련하여 논의되는 전통적인 BMC(Baseboard Management Controller) 기반 플랫폼 관리 솔루션들과 구 호환(backward compatible)될 수 있다.

플랫폼 관리능력(PM) 런타임 환경(230)은 크래쉬(crash) 시점까지 OS 센서 드라이버(203)로부터 수신된 정보에 기초하여 크래쉬 후 (OS) 회복을 수행 가능할 수 있다. 런타임 정보는 OS 센서 드라이버(203)에 의해 수집될 수 있고 처리를 위해 PM 런타임 환경(230)으로 전달될 수 있다. 다양한 통신 방법들이 이용될 수 있다는 것을 당업자는 잘 알 것이다. 예를 들어, 정보는 메일박스, 공유 메모리, 혹은 다른 통신 방법들을 통해 전달될 수 있다. 시스템에 변경을 주기 위해, 추천 사항들(recommendations)이 관리 에플리케이션(201) 혹은 원격 스테이션(260)에 되보내질 수 있다. 기존의 시스템들은 플랫폼 하드웨어/BIOS와 플랫폼 OS/드라이버들 사이의 버전 호환성을 검사할 수 있다. 본 발명의 실시예들은 또한, 보다 지능적인 분석을 수행하기 위해 크래쉬 덤프(crash dump)를 분석할 수 있다. PM은 OS 크래쉬를 예측가능할 수 있거나, 혹은 SEI(211)를 통해 OS 센서 드라이버(203)로부터 수신되는 OS 성능 데이터를 감시함으로써 낮은 성능을 향상시키기 위해 추천들을 제공할 수 있다.

EFI 아키텍처는 플랫폼 펌웨어(BIOS로서 공지됨)와 운영 시스템(OS) 사이의 모듈러 인터페이스를 정의한다. EFI에 따른 펌웨어 수행은 EFI 시스템 테이블이라고 불리는 데이터 구조를 OS 및 OS 로더(loader)에 반출한다. OS는 데이터(예를 들면, ACPI 테이블)와 EFI 런타임 서비스들로 공지된 서비스들의 세트(함수 포인터들)을 포함하는 EFI 시스템 테이블을 액세스하기 위한 EFI-어웨어(EFI-aware)이어야 한다. 이 서비스들은 시스템 시간/날짜 검색/설정, NVRAM 변수들의 문의/설정 등과 같은 기능을 OS에 제공한다. 이들은 단지 소량의 표준 서비스들의 세트일 뿐이며, EFI 서비스들은 OS에 추가적인 가치있는 기능을 제공하기 위해 확장 가능하다. 본 발명의 실시예들은 OS에 독립적인 방식으로 플랫폼 관리능력 하드웨어에 인터페이스를 제공하고 OS 건강 정보를 플랫폼 관리능력 기반구조에 제공하기 위해 표준 EFI 런타임 서비스들을 확장한다. EFI 서비스들은 전통적인 BMC(Baseboard Management Controller) 기반 플랫폼 관리 하드웨어에 대해 제공될 수도 있다. 전통적인 BMC 기반 플랫폼 관리 솔루션들은 서버 플랫폼들에 공통이다.

실시예에서, 내장된 플랫폼 관리능력 컴포넌트(230)는 호스트 프로세서와 공존하는 보조 프로세서 혹은 마이크로컨트롤러를 포함하고, 도 1의 전형적인 실시예에서 논의된 바와 같이, 칩셋 내에 또는 PCI 장치로서 통합될 수 있다. 플랫폼 관리능력 프로세서는 저비용, 저전력 프로세서일 수 있고, 메인 OS/프로세서가 슬립 모드인 동안 네트워크에 항상 접속된 저전력을 제공하는 것과 같은 값들을 제공할 수 있거나, 혹은 원격 정보 기술(IT: Information Technology) 관리 기반구조를 통해 예를 들면 방화벽 능력(firewall capability)을 수행하기 위한 플랫폼 관리를 수행하기 위해 원격의 제3자측 관리 모듈들을 다운로드하기 위한 내장된 플랫폼으로서 실행할 수 있다.

이제 도 3을 참조하면, 레거시 서버 시스템들(legacy server systems) 상에서, BMC 칩(307)은 IPMB(Intelligent Platform Management Bus)(308)를 통해 다른 장치들과 통신한다. BMC(307)는 표준 메시지 전달 프로토콜로서 IPMI(Intelligent Platform Management Interface)를 이용한다. BMC는 또한, BT(Block Transfer), KCS(Keyboard Controller Style), SMIC(System Management Interface Chip)(306)과 같은 상이한 인터페이스들을 노출하는데, 이들에 의해 시스템 관리 소프트웨어 컴포넌트들이 통신한다. 도 2는 관리 스택을 도시한다.

도 2를 다시 참조하면, 실시예들에서, 호스트 프로세서 상에서 실행하는 관리 에플리케이션(201)은 운영 시스템(OS) 센서 드라이버(203) 및 플랫폼 관리능력(PM) 드라이버(205)를 통해 호스트 운영 시스템(210)과 통신한다. 호스트 OS는 확장가능 펌웨어 인터페이스(Extensible Firmware Interface: EFI) 런타임 환경(220)과 통신한다. EFI 런타임 환경(220)은 외부 동작 인터페이스(External Operations Interface: EOI) 드라이버(207), 플랫폼 관리능력 경영 인터페이스(PMAI) 드라이버(209), 및 센서 효과기 인터페이스(SEI) 드라이버(211) 등과 같은 PM이 지원하는 모든 인터페이스들을 포함할 수 있다. 옵션적으로 호스트 OS에 노출될 수 있는 이 인터페이스들은 원격 관리 엔티티의 부재시 호스트 OS가 PM을 제어하는 것을 허용할 수 있다.

도 3에서, OS 센서 드라이버(325)는 주기적으로 EFI 런타임 서비스들(340)에 호출함으로써, OS 성능, OS 활동, 소프트웨어 목록 등에 영향을 주는 모든 시스템 파라미터들을 PM 런타임 환경(230)에 보고하도록 구성될 수 있다. OS 건강의 런타임 분석은 PM과 관련하여 실행하는 CM에 의해 수행될 수 있다. CM은 EFI 인터페이스를 통해 OS 센서 드라이버에 전달될 수 있는 수행할 동작들을 추천할 수도 있다. OS 센서 드라이버는 그 동작들을 어떻게 실행할지를 안다. 대조적으로, BMC-중앙 관리는 열 센서 및 다른 하드웨어 기반 컴포넌트들과 같은 것들로 문제들(issues)을 식별할 수만 있다.

도 2를 다시 참조하면, 플랫폼은 플랫폼 관리능력 하드웨어 환경(230)과 결합된 보조 프로세서를 가질 수 있다. 이 런타임 환경(230)은 호스트 OS 상에서 실 행하는 EFI 런타임 환경에서의 드라이버들(207, 209, 211)에 대응하는 외부 동작 인터페이스(External Operations Interface: EOI)(237), 센서 효과기 인터페이스(SEI)(231), PMAI(239)를 가질 수 있다. PM 하드웨어 및 런타임 환경(230)은 또한 CM(Capability Modules)(235a-b)를 가질 수 있다. SEI(231)는 OS(232)용 SEI 드라이버들, 네트워크 인터페이스 카드(NIC)(234), 및 중앙 프로세서 유닛(CPU)(236) 등을 포함할 수 있다. SEI 드라이버들(221)은 저장 장치들(241), 메모리 장치들(243), NIC들(245), CPU들(247), 혹은 다른 하드웨어(249) 등과 같은 플랫폼 하드웨어 컴포넌트들(240)과 통신할 수 있다. 소정의 실시예들에서, PM은 NIC(245)를 통해 원격 관리 시스템(260)에 통신할 수 있다. 이 NIC(245)는 플랫폼 상의 호스트 OS(210)에 보이지 않을 수 있다.

도 3을 다시 참조하면, 전통적인 BMC 기반 플랫폼에서, 관리 에플리케이션(301)은 OS(303)와 통신할 수 있다. 플랫폼 관리 드라이버(305)는 BT(Block Transfer), KCS(Keyboard Controller Style), 또는 SMIC(System Management Interface Chip)와 같은 통신 프로토콜(306)을 통해 BMC(307)와 통신할 수 있다. BMC(307)는 IPMB(308)를 통해 여러 하드웨어 장치들(센서들)(309a-c)과 통신할 수 있다. 기존의 시스템들에서, BMC(307)는 메인 프로세서의 열, 전원 공급장치의 건강 또는 프로세서의 속도를 감지할 수 있다. BMC(307)는 전형적으로 IPMI 프로토콜을 이용하여 통신한다. 또한, BMC는 전형적으로 서버 시스템들과 활용만 된다.

기존 시스템들에서, BMC(307)는 OS의 건강에 대해 아무것도 모른다. 예를 들어, BMC는 OS 크래쉬를 모른다; BMC는 OS로부터 단절된다. 본 명세서에 개시된 플랫폼 관리능력의 실시예들에서, PM은 OS 문제들을 고치고 수리 가능할 수 있다. 전통적인 BMC-IPMI 관리와는 대조적으로, PM은 플랫폼 컴포넌트들과 확장가능 인터페이스 때문에 OS 크래쉬의 원인들을 식별하는 능력을 갖는다. PM 드라이버(327)는 하드웨어 드라이버 문제들을 식별하고 드라이버 업데이트를 실행하고 그런 다음 OS(323)를 재부트(reboot)하는 능력을 가질 수 있다. 다른 업데이트들, 예를 들면 운영 시스템(OS) 패치들, 및 BIOS 업데이트들을 수행할 수 있다. 전통적인 BMC 관리 시스템들은 엄격하게 플랫폼 하드웨어 관리-중심적이다. PM 시스템의 실시예들은 메모리 소모를 결정하기 위해, 시스템이 비효율적으로 실행하는지의 여부를 결정하거나, 혹은 특정 패치가 즉, 서비스 팩(service pack)이 설치되었는지의 여부를 결정하기 위해 OS에 문의할 수 있다. 실시예들은 플랫폼의 목록을 또한 관리할 수 있다. OS 센서 드라이버(325)는 이 정보를 PM 특정 EFI 런타임 드라이버들(340)을 통해 PM 시스템에 전달한다.

OS 센서 드라이버(325)는 또한 시스템이 원격 경영자에 의해 관리되는 경우 원격 엔티티(즉, 도 2의 260)에 같은 정보를 제공할 수 있다. PM 하드웨어 및 런타임 환경은 원격 관리 엔티티와 관련하여 플랫폼을 통제할 수 있다. 예를 들어, 원격 관리 엔티티가 호스트와 네트워크 접속을 상실할 때, 원격 관리 엔티티는 그 자신을 위한 조치를 취하기 위해 PM을 접촉할 수 있다. PM이 원격 엔티티로부터 어떠한 통지도 받지 못하면, PM은 플랫폼 통제권을 장악할 수 있고 문제를 고치려고 시도할 수 있다.

임의의 플랫폼 내에 내장된 플랫폼 관리 능력은 도 3의 우측에 도시된 바와 같이 런타임 EFI 서비스들로서 호스트 OS에 투명하게 노출될 수 있다. EFI 기반 플랫폼 관리능력 환경에서, 본 발명의 실시예들에 따르면, 관리 에플리케이션(321)은 OS 센서 드라이버(325) 및 플랫폼 관리 드라이버(327) 둘 다와 OS(323)를 통해 통신한다. EFI 런타임 서비스들(340)은 EFI PM 드라이버(341)와 EFI BT/KCS/SMIC 드라이버(343)를 포함할 수 있다. 도시된 바와 같이, OS 플랫폼 관리 드라이버는 BMC와 통신하기 위해 KCS, BT 종류의 인터페이스(306 참조)를 이용하지 않을 것이나, 플랫폼 상의 임의의 관리가능 엔티티를 제어하거나 문의하기 위해 EFI 런타임 서비스들을 통해 노출된 관리 에플리케이션 프로그램 인터페이스(Application Program Interface: API)(343)을 이용할 것이다. 런타임 서비스들은 대응하는 하드웨어, 예를 들면 PM 하드웨어(345) 또는 BMC(347)와 통신한다. PM 하드웨어 및 BMC 하드웨어는 전용 PM 관리 버스(348) 혹은 IPMB(349) 중 어느 하나를 통해 다양한 하드웨어 장치들(350a-d)과 통신할 수 있다. PM 관리 버스는 EFI 기반 런타임 서비스들 중 어떤 것도 변경하지 않는다. 예를 들어, PM 하드웨어는 고속 독점 PM 관리 버스(348) 상의 플랫폼 관리능력 컨트롤러(350a)와 통신할 수 있고, BMC는 CPU(350d), 팬(fan)(350b), 혹은 전원 공급장치(350c) 상의 센서들과 IPMB(349)를 통해 통신할 수 있다.

API는 하부 플랫폼 관리 하드웨어(345), 혹은 관리 버스 상의 다른 장치들과 통신하기 위해 그가 이용하는 인터페이스와 관계가 없다. EFI 런타임 서비스들(340)은, 프리-부트(pre-boot) 동안 EFI 기반 펌웨어에 의해 로드되어 포 스트-부트(post-boot) 후 메모리에 지속하는 런타임 EFI 드라이버들(341, 343)로서 구현될 수 있다. EFI에 따른 OS는 이 서비스들을 용이하게 이용할 수 있다. 도 3은 PM 및 BMC 기반 플랫폼 관리 솔루션들에 대한 상이한 드라이버들을 나타낸다. BMC 특정 EFI 드라이버(343)는 표준 인터페이스들(BT, KCS, 또는 SMIC) 중 하나를 이용하여 BMC 하드웨어(347)와 통신하고, 관리가능 장치들을 열거하고, 이벤트들을 로그하고, SDR(Sensor Data Records) 등을 검색하는 기능들을 OS에 노출한다. 유사하게, PM 런타임 드라이버(341)는 OS에 투명한 PM 하드웨어(345)와 통신하고, EOI(237), PMAI(239), 및 SEI(231) 등과 같은 상이한 PM 인터페이스 타입들에 따른 런타임 기능들을 노출한다.

도 2를 다시 참조하면, 실시예들에서, 센서 효과기는 메인 프로세서 팬의 속도를 제어할 수 있어서, 필요하면, 예를 들어 팬 속도를 감소시키거나 혹은 증가시키기 위해 변경할 수 있다. 예를 들어 CPU(236)용 SEI 드라이버는 프로세서 팬 속도, 프로세서 온도 등과 같은 프로세서 상의 센서들을 제어/감시하기 위한 로직 또는 코드를 포함하는 프로세서용 실제 SEI 드라이버일 수 있다. SEI(231)는 개별적인 드라이버로서 구현될 수 있는, 그리고 232, 234, 236과 같은 모든 플랫폼 컴포넌트 특정 드라이버들과 작업하기에 충분하게 일반화되는 인터페이스이다. OS 상의 관리 에플리케이션(201)은 (효과기 인터페이스를 통해) 동작들을 트리거하는 것이다. 대안적으로, 원격 관리 에플리케이션은 PM 하드웨어에 직접 접속할 수 있고, 동일한 조치를 취할 수 있거나, 혹은 PM 런타임 환경과 관련하여 실행하는 CM이 OS 센서용 효과기 인터페이스를 통해 독립적인 조치를 취할 수 있다. 센서 효과기 정보는 대응하는 SEI 드라이버(221)를 통해 전달될 수 있다. 앞서 논의된 바와 같이, CM(Capability Module)(253a)은 EOI(237)를 통해 원격으로 제어될 수 있다. CM들(253)은 자치 기능을 제공할 수 있는 컴포넌트들이다. 예를 들어, CM들(253)은 센서를 읽고 효과기 인터페이스를 통해 조치를 취한다. CM은 문제를 독립적으로 바로 잡을 수 있는 로컬 에이전트이다. CM이 없는 경우, PM은 원격 에플리케이션에 수정을 할당할 수 있다.

이제 도 4를 참조하면, EFI 아키텍처 상에서 이용될 플랫폼 관리능력을 위한 프로토콜을 위한 예시적인 구조가 도시되어 있다. EFI PLATMGMT 프로토콜 구조는 몇몇의 기능들, 혹은 다양한 EFI 런타임 드라이버들(207, 209, 211)을 위한 EFI 서비스들을 포함한다. 예를 들어, EOI 드라이버(207)는 플랫폼 관리 능력들 문의(EFI_PROTOCOL_PLATMGMT_QUERY_CAPS), 센서 정보의 발행 및 예약 구독(EFI_PROTOCOL_PLATMGMT_SENSOR_INFO), 플랫폼 상의 자산들의 문의 및 관리(EFI_PROTOCOL_PLATMGMT_ASSET_INFO)를 위한 기능들을 수행할 수 있다. PMAI 드라이버(209)는 플랫폼 관리능력 런타임 시작/정지 (EFI_PROTOCOL_PLATMGMT_START 및 EFI_PROTOCOL_PLATMGMT_STOP), 플랫폼 관리능력 구성 문의 (EFI_PROTOCOL _PLATMGMT_QUERY), 및 규칙 설치 (EFI_PROTOCOL_PLATMGMT_INSTALLRULE)를 위한 기능들을 포함할 수 있다. SEI 드라이버(211)는 장치들 열거(EFI_PROTOCOL_PLATMGMT _ENUMS_DEVS), 메모리에 맵핑되는 장치 레지스터들의 세트인 레지스터 데이터 레코드들(Register Data Records: RDRs)의 등록(EFI_PROTOCOL_PLATMGMT_REG_RDR), 센서/효과기 데이터 판독(EFI_PROTOCOL_PLATMGMT_READ_SEDATA), 및 예를 들어 장치 상의 센서들을 기술하는 센서 데이터 레코드들(Sensor Data Records: SDRs), 필드 교체가능 유닛(field replaceable unit: FRU) 상태들 등의 장치 정보의 저장소의 정의(EFI_PROTOCOL_PLATMGMT_INIT_DATA)를 위한 기능들 등을 포함할 수 있다.

OS 센서는 물리적 센서가 아니지만, OS 성능, 활동, 소프트웨어 목록 등에 관련된 데이터를 판독한다는 점에서 의사 센서(pseudo-sensor)이다. SEI 드라이버는 OS 센서 드라이버를 포함하는 모든 센서 드라이버에 의해 구현될 필요가 있는 SEI에 의해 정의된 기능들을 불러낸다. 센서가 물리적 센서인가 의사 센서인가는 중요하지 않다. 만약 요청된 데이터가 OS와 관련되어 있다면, OS 센서 드라이버는 물리적 센서와 동일한 방식으로 그 데이터를 EFI 서비스에 반환한다.

본 명세서에서 기술된 기법들은 임의의 특정한 하드웨어 또는 소프트웨어 구성에 제한되지 않는다. 그들은 임의의 컴퓨팅, 가전제품, 또는 프로세싱 환경에서 응용가능성(applicability)을 찾을 수 있다. 기법들은 하드웨어, 소프트웨어, 또는 그 둘의 조합으로 구현될 수 있다.

시뮬레이션들에 대해, 프로그램 코드는 하드웨어 기술 언어 또는 본질적으로 설계된 하드웨어가 어떻게 동작하리라고 기대되는지에 대한 모델을 제공하는 또다른 기능적인 기술 언어를 사용하여 하드웨어를 표현할 수 있다. 프로그램 코드는 어셈블리어 또는 기계어, 또는 컴파일 및/또는 인터프리트될(interpreted) 수 있는 데이터일 수 있다. 또한, 본 기술분야에서 소프트웨어에 대해서 말할 때, 조치를 취하거나 결과를 초래하는 하나의 형태 또는 또다른 형태로 말하는 것이 일반적이 다. 그러한 표현들은 단순히 프로세서가 하나의 작용을 수행하거나 결과를 생산하게 하는 프로세싱 시스템에 의한 프로그램 코드의 실행을 진술하는 간단한 전달방식이다.

각 프로그램은 프로세싱 시스템과 통신하기 위해 고급 절차적 또는 객체 지향적 프로그램 언어로 구현될 수 있다. 그러나, 프로그램들은 원한다면 어셈블리어 또는 기계어로 구현될 수도 있다. 어떤 경우든, 언어는 컴파일되거나 인터프리트될 수 있다.

프로그램 명령어들은 그 명령어들로 프로그램된 범용 또는 특수 목적 프로세싱 시스템이 본 명세서에서 기술된 작동들을 수행하도록 하는 데 사용될 수 있다. 대안적으로, 작동들을 수행하기 위한 하드웨어에 내장된 로직을 포함하는 특정한 하드웨어 컴포넌트들에 의해, 또는 프로그램된 컴퓨터 컴포넌트들과 종래의 하드웨어 컴포넌트들의 임의의 조합에 의해 작동들은 수행될 수 있다. 본 명세서에서 기술된 방법들은 그 방법들을 수행하도록 프로세싱 시스템 또는 다른 전자 디바이스를 프로그램하는 데 사용될 수 있는 명령어들을 저장한 머신 액세스 가능 매체를 포함하는 컴퓨터 프로그램 제품으로서 제공될 수 있다.

프로그램 코드, 또는 명령어들은 예를 들면, 고상 메모리, 하드 드라이브들, 플로피 디스크들, 광학 저장장치, 테이프들, 플래시 메모리, 메모리 스틱들, 디지털 비디오 디스크들, DVD들(digital versatile discs)을 포함하는 저장 디바이스들 및/또는 관련된 머신 판독 가능 또는 머신 액세스 가능 매체와 같은 휘발성 및/또는 비휘발성 메모리 뿐 아니라, 머신 액세스 가능 생물학적 상태 보존 저장소(biological state preserving storage)와 같은 보다 신종의 매체들에 저장될 수 있다. 머신 판독 가능 매체는 머신에 의해 판독될 수 있는 형태로 정보를 저장, 송신 또는 수신하기 위한 임의의 메커니즘을 포함할 수 있고, 매체는, 프로그램 코드를 인코딩하는 전기, 광, 음향학적 또는 다른 형태의 전파되는 신호들 또는 반송파가 통과하는, 안테나들, 광섬유들, 통신 인터페이스들 등과 같은 실재의 매체를 포함할 수 있다. 프로그램 코드는 패킷들, 직렬 데이터, 병렬 데이터, 전파되는 신호들 등의 형태로 송신될 수 있고, 압축되거나 암호화된 형식으로 사용될 수 있다.

휴대형 컴퓨터 또는 고정형 컴퓨터들, 개인 휴대 정보 단말기들, 셋톱 박스들, 셀룰러 전화기들 및 호출기들, (DVD 플레이어들, 개인 비디오 레코더들, 개인 비디오 플레이어들, 위성 수신기들, 스테레오 수신기들, 케이블 TV 수신기들을 포함하는) 가전 디바이스들, 및 각각이 프로세서, 그 프로세서에 의해 판독가능한 휘발성 및/또는 비휘발성 메모리, 적어도 하나의 입력 디바이스 및/또는 하나 이상의 출력 디바이스를 포함하는 다른 전자 디바이스들과 같은 프로그램 가능한 머신들 상에서 실행하는 프로그램들에서 프로그램 코드가 구현될 수 있다. 프로그램 코드는 입력 디바이스를 사용하여 입력된 데이터에 적용되어 기술된 실시예들을 수행하고 출력 정보를 생성할 수 있다. 출력 정보는 하나 이상의 출력 디바이스에 적용될 수 있다. 본 기술분야의 숙련자라면 기술된 주제의 실시예들이 멀티 프로세서 또는 다중 코어 프로세서 시스템들, 미니컴퓨터들, 메인프레임 컴퓨터들뿐만 아니라, 임의의 디바이스에 가상적으로 내장될 수 있는 편재형 또는 미니어처 컴퓨터들 또는 프로세서들을 포함하는 다양한 컴퓨터 시스템 구성을 이용하여 실시될 수 있다는 것을 이해할 것이다. 기술된 주제의 실시예들은 작업들 또는 그 부분들이 통신 네트워크를 통해 연결된 원격 프로세싱 디바이스들에 의해 수행될 수 있는 분산 컴퓨팅 환경들에서 실시될 수도 있다.

작동들이 연속된 프로세스처럼 기술되었지만, 작동들 중 몇몇은 사실 병렬로, 동시발생적으로 및/또는 분산된 환경에서, 및 국지적으로 저장되고 및/또는 단일 또는 멀티 프로세서 머신들에 의해 원격으로 액세스되는 프로그램 코드를 이용하여 수행될 수 있다. 게다가 소정의 실시예들에서 작동들의 순서는 기술된 주제의 사상에서 벗어나지 않고 재배열될 수 있다. 프로그램 코드는 내장된 컨트롤러들에 의해 또는 내장된 컨트롤러들과 관련하여 사용될 수 있다.

예시적인 실시예들을 참조하여 본 발명이 기술되었지만, 본 기술은 제한적인 의미로 해석되도록 의도되지 않았다. 예시된 실시예들의 다양한 수정들 뿐 아니라, 본 발명이 속하는 기술분야의 숙련자들에게 명백한 본 발명의 다른 실시예들이 본 발명의 사상 및 범주 내에 있는 것으로 간주된다.

도 1은 본 발명의 실시예들이 구현될 수 있는 플랫폼을 도시한 블럭도이다.

도 2는 본 발명의 실시예에 따른, 플랫폼 관리능력(PM) 하드웨어와 호스트 OS 사이의 인터페이스를 예시하는 블럭도이다.

도 3은 본 발명의 실시예에 따른, 예시적인 확장가능 펌웨어 인터페이스(EFI) 런타임 서비스들 기반의 관리 스택과 대비되는 전통적인 베이스보드 관리 컨트롤러(BMC) 관리 스택을 나타내는 블럭도이다.

도 4는 본 발명의 실시예에 따라, EFI에 따른 플랫폼 펌웨어(BIOS)에 의해 구현되고 EFI에 따른 호스트 OS에 의해 이용되는 플랫폼 관리능력을 위한 EFI 프로토콜에 대한 예시적인 구조를 도시한다.

<도면의 주요부분에 대한 부호의 설명>

201: 관리 에플리케이션

203: OS 센서 드라이버

205: PM 드라이버

207: EOI 드라이버

209: PMAI 드라이버

211: SEI 드라이버

Claims

확장가능 펌웨어 인터페이스(exensible firmware interface) 어웨어 플랫폼 펌웨어(aware platform firmware)(BIOS) 및 호스트 운영 시스템(operating system)을 운영하기 위한 호스트 프로세서 - 상기 호스트 운영 시스템은 상기 호스트 운영 시스템의 건강(health) 및 성능 관련 정보를 플랫폼 관리능력(platform manageability) 컴포넌트에 전달하기 위한 운영 시스템 센서 드라이버를 가짐 - ; 및

능력 모듈(capability module)이 호스트 운영 시스템 건강 및 성능 관련 정보를 처리할 수 있게 하는 센서 효과기 인터페이스(sensor effector interface)를 포함하며, 상기 운영 시스템과 독립적으로 작동하는 플랫폼 관리능력 컴포넌트

를 포함하는 플랫폼 관리능력을 위한 시스템.
제1항에 있어서,

상기 호스트 운영 시스템은 플랫폼 관리능력 하드웨어 컴포넌트와 통신하기 위한 플랫폼 관리-특정 확장가능 펌웨어 인터페이스 런타임 서비스들을 갖는 플랫폼 관리능력을 위한 시스템.
제2항에 있어서,

상기 플랫폼 관리-특정 확장가능 펌웨어 인터페이스 런타임 서비스들을 포함하는 기능들의 서브세트는 상기 호스트 운영 시스템 상에서 운영되는 플랫폼 관리 컴포넌트들에 제한된 변경들을 가지면서 레거시 베이스보드 관리 컨트롤러(baseboard management controller) 플랫폼 관리 하드웨어와 통신하기 위한 인터페이스를 제공하는 플랫폼 관리능력을 위한 시스템.
제2항에 있어서,

상기 플랫폼 관리-특정 확장가능 펌웨어 인터페이스 런타임 서비스들은 외부 동작 인터페이스(external operational interface) 드라이버, 플랫폼 관리능력 경영 인터페이스(platform manageability administrative interface) 드라이버, 및 센서 효과기 인터페이스를 구현하고, 상기 운영 시스템 센서 드라이버는 호스트 운영 시스템 건강 및 성능 관련 정보를 상기 센서 효과기 인터페이스를 통해 상기 플랫폼 관리능력 컴포넌트에 제공하는 플랫폼 관리능력을 위한 시스템.
제1항에 있어서,

상기 능력 모듈은 운영 시스템 활동을 감시하고, 운영 시스템 성능 데이터를 수집하고, 상기 호스트 운영 시스템 건강 상태를 판정하기 위한 것이고, 치명적인 작동 조건으로부터 상기 운영 시스템을 회복시키기 위한 조치를 추천하는 것과 치명적인 작동 조건으로부터 상기 운영 시스템을 회복시키기 위한 조치를 실행하는 것 중 적어도 하나를 수행하기 위한 것인 플랫폼 관리능력을 위한 시스템.
제5항에 있어서,

상기 치명적인 작동 조건으로부터 상기 운영 시스템을 회복시키기 위한 조치는 사용자가 상기 운영 시스템을 패치하도록 강제하는 것, BIOS, 드라이버를 업그레이드하는 것, 시스템 구성 파라미터들을 변경하는 것, 및 사용자에게 하드웨어 교체 추천을 통지하는 것 중 적어도 하나를 포함하는 플랫폼 관리능력을 위한 시스템.
제5항에 있어서,

상기 조치를 추천하는 것은 최종 사용자에게 시스템 성능을 개선하는 조치를 취하거나 또는 취약성들로부터 상기 시스템을 보호하도록 통지하는 것을 포함하는 플랫폼 관리능력을 위한 시스템.
제5항에 있어서,

상기 플랫폼 하드웨어를 감시하기 위한 베이스보드 관리 컨트롤러를 더 포함하는 플랫폼 관리능력을 위한 시스템.
제1항에 있어서,

상기 플랫폼 관리능력 컴포넌트와 결합되어 원격 스테이션과 통신하는 네트워크 인터페이스 카드를 더 포함하는 플랫폼 관리능력을 위한 시스템.
제8항에 있어서,

상기 플랫폼 관리능력 컴포넌트와 결합된 네트워크 인터페이스 카드는 상기 호스트 운영 시스템에 보이지 않는 플랫폼 관리능력을 위한 시스템.
플랫폼 상의 호스트 운영 시스템을 운영 시스템 센서 드라이버에 의해 감시하여 상기 운영 시스템의 건강 상태를 판정하고 상기 운영 시스템의 성능 정보를 모으는 단계;

상기 운영 시스템의 건강 상태 및 성능 정보를 플랫폼 관리능력 컴포넌트에 전달하기 위해 확장가능 펌웨어 인터페이스 서비스를 호출하는 단계; 및

센서 효과기 인터페이스를 통하여 상기 플랫폼 관리능력 컴포넌트에 의해 상기 운영 시스템의 건강 상태 및 성능 정보를 수신하는 단계

를 포함하며,

상기 플랫폼 관리능력 컴포넌트는 상기 운영 시스템에 독립적으로 작동하는 플랫폼 관리능력을 위한 방법.
제11항에 있어서,

상기 플랫폼 관리능력 컴포넌트에 의해 상기 건강 상태와 성능 정보 중 적어도 하나에 따라 조치하는 단계를 더 포함하는 플랫폼 관리능력을 위한 방법.
제12항에 있어서,

상기 조치하는 단계는 소프트웨어, 하드웨어 또는 펌웨어 컴포넌트를 갱신하고 상기 호스트 운영 시스템의 성능 구성 파라미터들을 미세 조정하는 단계; 및 상기 플랫폼을 재부팅하는 단계 중 적어도 하나를 포함하는 플랫폼 관리능력을 위한 방법.
제12항에 있어서,

상기 수신된 건강 상태 및 성능 정보에 기초하여 취할 적절한 조치를 판정하기 위해 상기 플랫폼 관리능력 컴포넌트에 의해 원격 스테이션과 통신하는 단계를 더 포함하는 플랫폼 관리능력을 위한 방법.
저장된 명령어들을 갖는 머신 판독 가능 매체로서, 상기 명령어들은 실행될 때 상기 머신이,

운영 시스템 센서 드라이버에 의해 플랫폼 상의 호스트 운영 시스템을 감시하여 상기 운영 시스템의 건강 상태를 식별하고 상기 운영 시스템의 성능 정보를 모으고;

상기 운영 시스템의 건강 상태 및 성능 정보를 플랫폼 관리능력 컴포넌트에 전달하기 위해서 확장가능 펌웨어 인터페이스 서비스를 호출하고;

센서 효과기 인터페이스를 통하여 상기 플랫폼 관리능력 컴포넌트에 의해 상기 운영 시스템의 건강 상태 및 성능 정보를 수신하도록 하며,

상기 플랫폼 관리능력 컴포넌트는 상기 운영 시스템에 독립적으로 작동하는 머신 판독 가능 매체.
제15항에 있어서,

실행될 때, 상기 머신이,

상기 플랫폼 관리능력 컴포넌트에 의해 상기 건강 상태 및 성능 정보를 분석하도록 하는 명령어들을 더 포함하는 머신 판독 가능 매체.
제15항에 있어서,

실행될 때, 상기 머신이,

상기 호스트 운영 시스템의 고장난(failed) 소프트웨어 컴포넌트를 갱신하는 것, 상기 호스트 운영 시스템의 고장난 펌웨어 컴포넌트를 갱신하는 것, 및 문제가 되는 하드웨어를 식별하는 것 중 적어도 하나를 수행함으로써 상기 건강 상태 및 성능 정보에 따라 조치하고,

상기 플랫폼을 재부팅하도록 하는 명령어들을 더 포함하는 머신 판독 가능 매체.
제16항에 있어서,

실행될 때, 상기 머신이,

능력 모듈이 없는 경우, 상기 건강 상태 및 성능 정보에 따라 조치하기 전에, 상기 수신된 건강 상태 및 성능 정보에 기초하여 적절한 조치를 판정하기 위해 상기 플랫폼 관리능력 컴포넌트에 의해 원격 스테이션과 통신하게 하고;

능력 모듈이 존재하는 경우, 상기 능력 모듈에 의해 적절한 조치를 판정하게 하는 명령어들을 더 포함하는 머신 판독 가능 매체.