JP2008102906A - プラットフォーム管理能力をｏｓにエクスポートするｅｆｉに基づく機構 - Google Patents

Abstract

【課題】ホストオペレーションシステムとは独立した安全な実行環境を提供する。
【解決手段】オペレーティングシステム（ＯＳ）センサエフェクタは、ＯＳの健康に関する情報を、ＥＦＩサービスを用いてプラットフォーム管理容易性（ＰＭ）要素に伝送する。ＰＭ要素は、可能性のある致命的な状態、または、ＯＳが重度の能力低下に陥るような状態を避けるべく、壊滅的な状態から回復させる回復動作または勧告動作をホストＯＳに強制する。
【選択図】図２

Description

本発明の一実施形態は、概ねコンピュータシステムに関し、より詳しくは、プラットフォーム管理容易性のクロスプラットフォーム仕様を含むアーキテクチャに関する。

外部ソースからプラットフォームを管理するさまざまな機構が存在する。
既存のサーバは、ベースボード管理コントローラ（ＢＭＣ）プロセッサを利用して情報を遠隔管理システムに伝達することもできる。サーバ、デスクトップ、ラップトップなどの遠隔プラットフォーム管理を実現する他の方法も目下開発中かもしれない。多くの管理容易性機構は、管理されるべきプラットフォームにおいてホストオペレーティングシステム（ＯＳ）の使用を要する。

本発明の一実施例は、ホストオペレーティングシステムとは独立した安全な実行環境を提供するクロスプラットフォーム管理アーキテクチャの使用に関連するシステムおよび方法である。少なくとも1つの実施形態において、本発明は、自動、ユーティリティ、および、オンデマンドコンピューティングを実現することを目的とする。

本願明細書中の「１つの実施形態」または「一実施形態」への言及は、実施形態に関連して述べられる特定の特徴、構造、または、特性が本発明における少なくとも1つの実施形態に含まれていることを意味する。したがって、本願明細書中随所に見られる「1つの実施形態において」という言い回しは、必ずしも同じ実施形態にすべて言及しているとは限らない。本発明の完全なる理解を提供すべく、説明のための特定の構成および詳細が記載されている。

しかしながら、本発明の実施形態は、本願明細書中に示される特定の詳細なしでも実施し得ることは、当業者にとり明らかであろう。さらに、本発明をあいまいにしないよう、よく知られた特徴は、省略または簡略化しているかもしれない。本記載の全体を通じてさまざまな例が挙げられる。それらは、本発明の特定の実施形態の単なる説明に過ぎない。本発明の範囲は、挙げられた例に限定されない。

図１は、本発明の一実施形態に従う、プラットフォーム管理マイクロコントローラ（ＰＭ μコントローラ）を有するプラットフォームの特徴を示すブロック図である。プラットフォーム１００は、ホストプロセッサ１０１を含む。

プロセッサ１０１は、メモリコントローラハブ１０３を介し、ランダムアクセスメモリ１０５に接続されてよい。
プロセッサ１０１は、マイクロプロセッサ、デジタル信号プロセッサ、マイクロコントローラなど、ソフトウェアを実行できるいかなるタイプのプロセッサであってもよい。図１は、唯一のこのようなプロセッサ１０１を示すが、プラットフォーム１００には1つまたはそれ以上のプロセッサがあってもよいし、1つまたはそれ以上のプロセッサが多数のスレッド、多数のコアなどを含んでもよい。プロセッサ１０１は、さらに、入出力コントローラハブ（ＩＣＨ）１０７を介し、Ｉ／Ｏデバイスに接続されてよい。ＩＣＨは、ローピンカウント（ＬＰＣ）バス１０２を介し、スーパーＩ／Ｏコントローラ（ＳＩＯ）、キーボードコントローラ（ＫＢＣ）、または、信頼できるプラットフォームモジュール（ＴＰＭ）などの様々なデバイスに接続されてよい。例えば、ＳＩＯは、フロッピードライブまたは工業標準アーキテクチャ（ＩＳＡ）デバイスへアクセスしてよい。一実施例では、ＩＣＨは、シリアルペリフェラルインターフェース（ＳＰＩ）バス１０４を介し不揮発性メモリに接続される。不揮発性メモリは、フラッシュメモリ、または、スタティックＲＡＭ（ＳＲＡＭ）などであってよい。プラットフォーム管理μコントローラ１１０ｎは、プラットフォーム１００上にあってよい。ＰＭμコントローラ１１０ｎは、一般的にＰＣＩまたはＰＣＩ高速バスであるバス１１２を介しＩＣＨに接続されてよい。ＰＭμコントローラは、また、ＳＰＩバス１０４を介し不揮発性メモリ（不揮発性記憶装置）１１７に接続されてもよい。不揮発性記憶装置１１７は、フラッシュメモリまたはスタティックＲＡＭ（ＳＲＡＭ）などでよい。多くの既存のシステムでは、不揮発性メモリはフラッシュメモリである。

複数の実施例においては、ＰＭμコントローラ１１０ｎは、「小型」または埋込み型プロセッサにたとえられてよい。全能力プロセッサのように、ＰＭμコントローラは、ＲＡＭおよびＲＯＭメモリ１１３同様、キャッシュメモリ１１５に有効に接続されるプロセッサユニット１１１を有する。ＰＭμコントローラは、ビルトインネットワークインターフェースおよび電源１２５への独立した接続を有することにより、ホストプロセッサ１０１がアクティブでなくとも帯域外通信ができる。

複数の実施例では、プロセッサ１０１は、不揮発性記憶装置１１７内に基本入出力システム（ＢＩＯＳ）１１９を有する。他の実施例では、プロセッサ１０１は、遠隔装置（図示せず）から立ち上がり、ブートベクトル（ポインタ）は、不揮発性記憶装置１１７のＢＩＯＳ部分１１９内に存在する。ＰＭμコントローラは、不揮発性メモリのＢＩＯＳ部分１１９および保護された部分１２１を含む不揮発性記憶装置１１７のすべての内容にアクセスする。いくつかの実施形態では、メモリの保護された部分１２１は、インテル（登録商標）アクティブマネジメントテクノロジー（ＩＡＭＴ）により安全を保護されている。ＰＭμコントローラは、ＩＡＭＴソフトウェアスタックを稼働させる。ＩＡＭＴに関する更なる情報は、公共のインターネットのURL ｗｗｗ−ｉｎｔｅｌ−ｃｏｍ／ｔｅｃｈｎｏｌｏｇｙ／ｍａｎａｇｅ／ｉａｍｔ／ で見つけることができる。（不用意なハイパーリンクを避けるべく、本願明細書中に含まれるＵＲＬのピリオドは、ダッシュに置き替えている）。

不揮発性メモリのバイオス部分は、ＯＳまたはＯＳ内で動作するアプリケーションにより変更できるので、悪質な改ざんをされる可能性がある。複数の実施例では、ＰＭμコントローラのみが利用可能なメモリ１２１の保護された領域は、改ざんされる危険なしにクリティカルブートベクトルおよび他の情報を格納するのに用いられる。不揮発性記憶装置１１７のＰＭμコントローラ側への唯一のアクセス方法は、ＰＭμコントローラによるプロキシを介した確認、すなわち、サイン承認などを通してであってもよい。

多くの既存のシステムは、Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ（ＥＦＩ）ベースのプラットフォームファームウェアおよびそれに関連するフラッシュメモリを使用する。ＥＦＩは、一般的にＢＩＯＳとして知られる、複数のオペレーティングシステムとプラットフォームファームウェアとの間のインターフェース用のニューモデルを定義する仕様である。２００２年１２月１日に公開された仕様バージョン１．１０は、インターネットのＵＲＬ ｄｅｖｅｌｏｐｅｒ−ｉｎｔｅｌ−ｃｏｍ／ｔｅｃｈｎｏｌｏｇｙ／ｅｆｉ／ｍａｉｎ＿ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｈｔｍで入手可能である。

本発明の複数の実施形態は、プラットフォーム管理容易性のためのクロスプラットフォーム仕様を含むアーキテクチャを利用してよい。図２を参照すると、本アーキテクチャは、能力モジュール（ＣＭ）２５３と呼ばれる第三者管理能力拡張子を実行できるホストオペレーティングシステム２１０とは独立した実行環境２３０を実現できる。ＣＭ２５３は、ネットワーク全体に動的にロードされ、ＰＭ２３０の実行時環境へと挿入されることができるバイナリ成分である。ＣＭ２５３は、ＰＭにより提供された管理容易性機能を拡張する。ＣＭ２５３は、異なるインターフェース、例えばセンサデータを収集して措置を講じるＳＥＩ２３１を操作しかつ使用するＰＭ実行時環境２３０により提供される一組のサービスに依存する。ＰＭ実行時環境２３０は、プラットフォーム管理容易性管理インターフェース（ＰＭＡＩ）２３９、セミナエフェクタインターフェース（ＳＥＩ）２３１、（外部オペレーションインターフェース）ＥＯＩ２３７などの多数のインターフェースを示している。これらのインターフェースのそれぞれは、独自の目的を果たす。

ＥＯＩ２３７は、外部エンティティがＰＭ実行時環境２３０に遠隔アクセスして制御できるようにする。ＥＯＩ２３７は、プラットフォーム能力、センサ、アセット情報、実行診断アプリケーション、システム提供の発見などの機能を提供する。ＰＭＡＩ２３９は、ＰＭ実行時環境２３０を調整する管理機能を提供する。ＰＭＡＩ２３９は、ドライバ、ＯＳ、ＣＭの問合せ／パッチング、ＣＭのインストール／除去／開始／停止、および、ＰＭの開始／停止などの動作を許容する。ＳＥＩ２３１は、一般的に、システム上のデバイス、読み取りセンサデータ、書込みエフェクタデータなどの列挙を可能にする機能を定義する。ＰＭＡＩ２３９およびＥＯＩ２３７は、ＩＴ管理者により遠隔で起動される。アーキテクチャは、ホストオペレーティングシステム（ＯＳ）２１０と協働するいかなるインターフェースまたは機構をも定義しない。デスクトップ、サーバ、または、ハンドヘルドにおいて動作するプラットフォーム管理ソリューションは、ＯＳと協働するときにさらなる柔軟性および制御を提供できる。ＰＭとホストＯＳ２１０との間のインターフェースは、225として示される。

本発明の実施形態は、ＯＳ上で動作するローカル管理エンティティ２０５によるプラットフォーム管理容易性要素２３０との通信を実現し、プラットフォーム管理容易性要素２３０のためにＥｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ（ＥＦＩ）実行時サービス２２０（２０７、２０９、２１１）を介してＯＳアクティビティをモニタする機構を含む。複数の実施形態では、アーキテクチャは、プラットフォーム管理容易性インフラがＯＳの健康をモニタできるＯＳ２１０の状況において動作する"ＯＳセンサ"２０３を利用する。ＥＦＩ実行時ドライバ２２０がインターフェースをエクスポートすることにより、ＯＳセンサ情報は、プラットフォーム管理容易性インフラ２３０に提供されることができる。また、ＥＦＩ実行時ドライバは、インターフェースを提示しているため、ＯＳセンサドライバは、ＰＭ実行時環境２３０において動作するＯＳ特定ＣＭからコマンドを受信してよい。プラットフォーム管理容易性インターフェースをＯＳに示し、プラットフォーム管理容易性インフラがＯＳアクティビティをモニタしかつＯＳの回復動作を制御できるようにすることにより、本発明の複数の実施例は、既存のプラットフォーム管理容易性アーキテクチャを補う多目的マネジメントソリューションを提供する。本発明の複数の実施形態は、図３に関連して述べられるような従来のＢＭＣ（ベースボード管理コントローラ）に基づくプラットフォームマネジメントソリューションと旧版互換性があってよい。

プラットフォーム管理容易性（ＰＭ）実行時２３０は、ＯＳセンサドライバ２０３から受信されたクラッシュポイントに至るまでの情報に基づき、ポストクラッシュ（ＯＳ）リカバリを実行することもできる。実行時情報は、ＯＳセンサドライバ２０３により収集されて、処理のためにＰＭ実行時２３０へと送られてよい。さまざまな通信方法が用いられ得ることは等業者にとり明らかである。例えば、情報は、メールボックス、共有メモリ、または、他の通信方法を介し伝達される。マネジメントアプリケーション２０１または遠隔局２６０へと勧告が返送されることにより、システム内に変更をもたらすことができる。既存のシステムは、プラットフォームハードウェア／ＢＩＯＳとプラットフォームＯＳ／ドライバとの間のバージョン互換性を調べることができる。本発明の複数の実施形態は、よりインテリジェントな分析を実行すべく、クラッシュ・ダンプを分析することもできる。ＰＭは、ＯＳクラッシュに前もって対処するか、または、ＳＥＩ２１１を介しセンサドライバ２０３から受信されたＯＳパフォーマンスデータをモニタすることにより、低いパフォーマンスを向上させるよう勧告することもできる。

ＥＦＩアーキテクチャは、プラットフォームファームウェア（一般的にはＢＩＯＳとして知られる）とオペレーティングシステム（ＯＳ）との間のモジュラーインターフェースを定義する。ＥＦＩ対応ファームウェアを実行することにより、ＥＦＩシステムテーブルと呼ばれるデータ構造をＯＳおよびＯＳローダにエクスポートする。ＯＳは、データ（例えばＡＣＰＩテーブル）およびＥＦＩ実行時サービスとして知られるサービスのセット（ファンクションポインタ）を含むＥＦＩシステムテーブルにアクセスすべくＥＦＩを認識している必要がある。これらのサービスは、システム時間／日付の検索／設定、ＮＶＲＡＭの問合せ／設定などの機能をＯＳに提供する。これらは、一握りの標準的サービスに過ぎないが、ＥＦＩサービスは、ＯＳに付加価値機能を提供するまでに拡張できる。本発明の複数の実施形態は、ＯＳに依存しない方法でプラットフォーム管理容易性ハードウェアにインターフェースを提供し、かつ、プラットフォーム管理容易性インフラにＯＳ健康情報を提供するよう、標準ＥＦＩ実行時サービスを拡張する。ＥＦＩサービスは、プラットフォーム管理ハードウェアに基づく従来のＢＭＣ（ベースボード管理コントローラ）にも提供されてよい。従来のＢＭＣベースのプラットフォーム管理ソリューションは、サーバプラットフォーム上で共通である。

一実施形態では、埋め込み型プラットフォーム管理容易性要素２３０は、ホストプロセッサと共存する補助プロセッサまたはマイクロコントローラを含み、図1の例示的実施形態において説明したようなチップセット内に、または、ＰＣＩデバイスとして集積されてよい。プラットフォーム管理容易性プロセッサは、低価格、低消費電力のプロセッサであってよく、主ＯＳ／プロセッサがスリープモード中も常にネットワークに接続される低電力を供給するような価値を提供できるか、または、埋め込み型プラットフォームとして、例えば、遠隔情報テクノロジー（ＩＴ）管理インフラを介しファイアウォール機能を遂行するプラットフォーム管理を実行する遠隔第三者管理モジュールのダウンロードを実行できる。

図３を参照すると、レガシーサーバシステムにおいて、ＢＭＣチップ３０７は、ＩＰＭＢ（インテリジェントプラットフォーム管理バス）３０８上で他のデバイスと通信する。ＢＭＣ３０７は、ＩＰＭＩ（インテリジェントプラットフォーム管理インターフェース）を標準メッセージパッシングプロトコルとして使用する。ＢＭＣは、また、システム管理ソフトウェア要素が通信する、ＢＴ（ブロックトランスファ）、ＫＣＳ（キーボードコントローラスタイル）、ＳＭＩＣ（システムマネジメントインターフェースチップ）３０６のような異なるインターフェースも示している。図２は、管理スタックを示す。

再び図２を参照すると、複数の実施形態では、ホストプロセッサ上で動作する管理アプリケーション２０１は、オペレーティングシステム（ＯＳ）センサドライバ２０３およびプラットフォーム管理容易性（ＰＭ）ドライバ２０５を介しホストオペレーティングシステム２１０と通信する。ホストＯＳは、Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ（ＥＦＩ）実行時環境２２０と通信する。ＥＦＩ実行時環境２２０は、外部オペレーションインターフェース（ＥＯＩ）ドライバ２０７、プラットフォーム管理容易性管理インターフェース（ＰＭＡＩ）ドライバ２０９、および、センサエフェクタインターフェース（ＳＥＩ）ドライバ２１１などのＰＭサポートであるすべてのインターフェースを含んでよい。任意でホストＯＳに示されるこれらのインターフェースにより、ホストＯＳは、遠隔管理エンティティなしにＰＭを制御できるようになる。

図３では、ＯＳセンサドライバ３２５は、ＥＦＩ実行時サービス３４０に周期的に呼び掛けることにより、ＯＳ性能、ＯＳアクティビティ、ソフトウェアインベントリなどに影響を与えるすべてのシステムパラメータを報告するよう構成されてよい。ＯＳの健康の実行時分析は、ＰＭにおいて動作するＣＭにより実行されてよい。ＣＭは、ＥＦＩインターフェースを介しＯＳセンサドライバと通信することができる勧告動作であってもよい。ＯＳセンサドライバは、それらの動作をどのように実行するか知っている。その一方、ＢＭＣ中心の管理は、熱センサおよび他のハードウェアベースの要素のようなものにより問題点を識別することだけできる。

図２を再び参照すると、プラットフォームは、プラットフォーム管理容易性ハードウェア環境２３０に接続される補助プロセッサを有することもある。
この実行時環境２３０は、ホストＯＳ上で動作するＥＦＩ実行時環境におけるドライバ２０７、２０９、および、２１１と対応させるよう、外部オペレーションインターフェース（ＥＯＩ）２３７、センサエフェクタインターフェース（ＳＥＩ）２３１、および、ＰＭＡＩ２３９を有してよい。また、ＰＭハードウェアおよび実行時環境２３０は、能力モジュール（ＣＭ）２３５ａ−ｂを有してもよい。ＳＥＩ２３１は、ＯＳ２３２用ＳＥＩドライバ、ネットワークインターフェースカード（ＮＩＣ）２３４、および、中央処理装置（ＣＰＵ）２３６などを含んでよい。ＳＥＩドライバ２２１は、記憶デバイス２４１、メモリデバイス２４３、ＮＩＣ２４５、ＣＰＵ２４７または他のハードウェア２４９のようなプラットフォームハードウェア要素２４０と通信してよい。いくつかの実施形態では、ＰＭは、ＮＩＣ２４５を介し遠隔管理システム２６０と通信してもよい。このＮＩＣ２４５は、プラットフォーム上のホストＯＳ２１０には見えない。

再び図３を参照すると、従来のＢＭＣベースのプラットフォームでは、管理アプリケーション３０１は、ＯＳ３０３と通信してよい。プラットフォーム管理ドライバ３０５は、ＢＴ（ブロックトランスファ）、ＫＣＳ（キーボードコントローラスタイル）またはＳＭＩＣ（システム管理インターフェースチップ）のような通信プロトコル３０６を介し、ＢＭＣ３０７と通信してよい。ＢＭＣ３０７は、ＩＰＭＢ３０８を介し様々なハードウェアデバイス（センサ）３０９ａ−ｃと通信してよい。

既存のシステムでは、ＢＭＣ３０７は、主プロセッサの温度、電源の健康、または、プロセッサの速度を検知できる。ＢＭＣ３０７は、一般的にＩＰＭＩプロトコルを用いて通信する。さらに、ＢＭＣは、一般的にサーバシステムにより配備されるだけである。既存のシステムでは、ＢＭＣ３０７は、ＯＳの健康について何も知らない。例えば、ＢＭＣは、ＯＳのクラッシュには気づかない、ＢＭＣは、ＯＳに接続されていない、などである。本願明細書中に開示されるプラットフォーム管理容易性の複数の実施形態において、ＰＭは、ＯＳの問題を回復させ、修復する。 従来のＢＭＣ−ＩＰＭＩ管理に反し、ＰＭは、プラットフォーム要素を備える拡張可能なインターフェースによるＯＳクラッシュの原因を識別する能力を有する。ＰＭドライバ３２７は、ハードウェアドライバ問題を識別し、ドライバをアップデートした後、ＯＳ３２３を再起動する能力を有してよい。他のアップデート、例えば、オペレーティングシステム（ＯＳ）のパッチ、ＢＩＯＳのアップデートなどが実行されてよい。従来のＢＭＣ管理システムは、厳密言えば、プラットフォームハードウェア管理中心である。ＰＭシステムの実施形態は、メモリ消費、システムが非効率に稼働しているか、または、特定のパッチがインストールされているか、すなわちサービスパックかどうかを決定すべくＯＳに問い合わせてよい。実施形態は、また、プラットフォームのインベントリの管理もしてよい。ＯＳセンサドライバ３２５は、ＰＭ特定ＥＦＩ実行時ドライバ３４０を介し、この情報をＰＭシステムに伝える。

システムが遠隔管理者によって管理されている場合、ＯＳセンサドライバ３２５は、同じ情報を遠隔エンティティ（すなわち図２の２６０）に提供してもよい。ＰＭハードウェアおよび実行時環境は、遠隔管理エンティティと共にプラットフォームを制御してよい。例えば、遠隔管理エンティティがホストとのネットワーク接続を失った場合、それに代わって対処するＰＭと接触することもできる。ＰＭが遠隔管理エンティティからいずれの通知を受信するのに失敗した場合、遠隔管理エンティティは、プラットフォーム制御を引き継ぎ、問題を解決することができる。

図３の右側に見られるように、いずれかのプラットフォームに埋め込まれたプラットフォーム管理能力は、実行時ＥＦＩサービスとしてホストＯＳに対しトランスペアレントに示されてよい。本発明の実施形態に従うＥＦＩベースのプラットフォーム管理容易性環境において、管理アプリケーション３２１は、ＯＳ３２３を介し、ＯＳセンサドライバ３２５およびプラットフォーム管理ドライバ３２７の両方と通信する。ＥＦＩ実行時サービス３４０は、ＥＦＩ ＰＭドライバ３４１およびＥＦＩ ＢＴ／ＫＣＳ／ＳＭＩＣドライバ３４３を含んでよい。図に示すように、ＯＳプラットフォーム管理ドライバは、ＢＭＣと通信すべくＫＣＳ、ＢＴ種のインターフェース（３０６参照）を使用しなくてもよく、ＥＦＩ実行時サービスを介し示された管理アプリケーションプログラムインターフェース（ＡＰＩ）３４３を用いてプラットフォーム上の任意の管理可能なエンティティを制御または問い合わせることができる。実行時サービスは、例えばＰＭハードウェア３４５またはＢＭＣ３４７などの対応するハードウェアと通信する。ＰＭハードウェアおよびＢＭＣハードウェアは、専用ＰＭ管理バス３４８またはＩＰＭＢ３４９のいずれかを介し、様々なハードウェアデバイス３５０ａ−ｄと通信してよい。ＰＭ管理バスは、いずれのＥＦＩベースの実行時サービスも変更しない。例えば、ＰＭハードウェアは、高速専用ＰＭ管理バス３４８においてプラットフォーム管理容易性コントローラ３５０ａと通信してもよいし、ＢＭＣは、ＩＰＭＢ３４９を介し、ＣＰＵ３５０ｄ、ファン３５０ｂ、または、電源３５０ｃにおけるセンサと通信してもよい。

ＡＰＩは、下にあるプラットフォーム管理ハードウェア３４５またはインターフェースとは関係がなく、管理バス上の他のデバイスと通信するために用いる。ＥＦＩ実行時サービス３４０は、プレブートの間にＥＦＩベースのファームウェアによりロードされる実行時ＥＦＩドライバ３４１および３４３のように実行され、ポストブート後もメモリ内に存続してよい。ＥＦＩ対応ＯＳは、これらのサービスを容易に使用できる。図３は、ＰＭ用の異なるドライバ、および、ＢＭＣベースのプラットフォーム管理ソリューションを示す。ＢＭＣ特定ＥＦＩドライバ３４３は、標準インターフェース（ＢＴ、ＫＣＳまたはＳＭＩＣ）の１つを用いてＢＭＣハードウェア３４７と通信し、管理可能なデバイス、ログ事象を列挙し、センサデータレコード（ＳＤＲ）などを検索する機能をＯＳに対して示す。同様に、ＰＭ実行時ドライバ３４１は、ＯＳにトランスペアレントなＰＭハードウェア３４５と通信し、ＥＯＩ（２３７）、ＰＭＡＩ（２３９）およびＳＥＩ（２３１）などの異なるＰＭインターフェースタイプに準拠する実行時機能を示す。

再び図２を参照すると、複数の実施形態において、センサエフェクタは、主プロセッサファンの速度を制御し、必要であれば、例えば、ファンの速度を遅くするまたは速くするなど変化させてよい。例えば、ＣＰＵ２３６のＳＥＩドライバは、プロセッサファン速度、プロセッサ温度など、プロセッサにおけるセンサを制御／モニタするロジックまたはコードを含むプロセッサ用の実際のＳＥＩドライバであってよい。ＳＥＩ２３１は、２３２、２３４、２３６のようなすべてのプラットフォーム要素特定ドライバと協働できるほどに一般化されている独立したドライバとして実行できるインターフェースである。ＯＳ上の管理アプリケーション２０１は、（エフェクタインターフェースを介し）動作を起こす管理アプリケーションである。一方、遠隔管理アプリケーションは、ＰＭハードウェアと直接接続し、同じ措置を講じてもよいし、または、ＰＭ実行時環境において動作するＣＭは、ＯＳセンサ用のエフェクタインターフェースを介し、独立した措置を講じてもよい。センサエフェクタ情報は、対応するＳＥＩドライバ２２１を介し伝達される。前述のように、能力モジュール（ＣＭ１）２５３ａは、ＥＯＩ２３７を介し遠隔で制御される。ＣＭ２５３は、自律機能を提供できる構成要素である。例えば、ＣＭ２５３は、センサを読み取り、エフェクタインターフェースを介し、措置を講じてもよい。ＣＭは、個別に問題を修正できるローカルエージェントである。ＣＭがない場合、ＰＭは、修正を遠隔アプリケーションに割り当ててよい。

図４を参照すると、ＥＦＩアーキテクチャで用いられるべきプラットフォーム管理容易性のためのプロトコルの典型的構造が示されている。ＥＦＩ ＰＬＡＴＭＧＭＴプロトコル構造は、いくつかの機能、または、様々なＥＦＩ実行時ドライバ２０７、２０９、２１１のためのＥＦＩサービスを含む。例えば、ＥＯＩドライバ２０７は、プラットフォーム管理能力を問い合わせる機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＱＵＥＲＹ＿ＣＡＰＳ）、センサ情報を発行して購読する機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＳＥＮＳＯＲ＿ＩＮＦＯ）、プラットフォーム上のアセットを問合せかつ管理する機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＡＳＳＥＴ＿ＩＮＦＯ）を実行してよい。ＰＭＡＩドライバ２０９は、プラットフォーム管理容易性実行時を開始／停止する機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＳＴＡＲＴ）および（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＳＴＯＰ）、プラットフォーム管理容易性構成を問合せる機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＱＵＥＲＹ）、ルールをインストールする機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＩＮＳＴＡＬＬＲＵＬＥ）を含む。ＳＥＩドライバ２１１は、デバイスを列挙する機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＥＮＵＭＳ＿ＤＥＶＳ）、メモリにマップされるデバイスレジスタのセットであるレジスタデータレコード（ＲＤＲ）を登録する機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＲＥＧ＿ＲＤＲ）、センサ／エフェクタデータを読み取る機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＲＥＡＤ＿ＳＥＤＡＴＡ）、例えば、デバイス上のセンサを記述するセンサデータ記録（ＳＤＲ）、フィールド交換可能ユニット（ＦＲＵ）状態などのデバイス情報のレポジトリを定義する機能（ＥＦＩ＿ＰＲＯＴＯＣＯＬ＿ＰＬＡＴＭＧＭＴ＿ＩＮＩＴ＿ＤＡＴＡ）を含んでよい。

ＯＳセンサは、物理的センサではないという意味で擬似センサであるが、ＯＳパフォーマンス、アクティビティ、ソフトウェアインベントリなどに関するデータを読み取る。ＳＥＩドライバは、ＯＳセンサドライバを含むすべてのセンサドライバにより実行されるよう要求されるＳＥＩにより定義される機能を呼び出す。センサが物理的センサか擬似センサであるかは問題ではない。要求されるデータがＯＳに関連する場合、ＯＳセンサドライバは、物理的センサと同じやり方でデータをＥＦＩサービスに返送する。

本願明細書中に記載される技術は、いかなる特定のハードウェアまたはソフトウェア構成に限定されず、いずれのコンピュータ、家庭用電化製品、または、処理環境においても適用性を見出せる。本技術は、ハードウェア、ソフトウェア、または、それらの組み合わせにおいて実行することもできる。

シミュレーションのために、プログラムコードは、ハードウェア記述言語、または、設計されたハードウェアが動作すると思われる方法のモデルを本質的に提供する他の関数的記述言語を用いてハードウェアを表わしてよい。プログラムコードは、コンパイルおよび／または翻訳され得るアセンブリまたはマシン語、あるいは、データであってよい。さらに、１つの形式またはそれ以外において、措置を講じるかまたは結果を生じるソフトウェアに関する記述は、技術的に共通している。このような表現は、プロセッサに動作を実行させるかまたは結果を生じさせる処理システムによるプログラムコードの実行の記載を簡略化したものにすぎない。

それぞれのプログラムは、ハイレベル手続きまたはオブジェクト指向プログラミング言語で実行されることにより、処理システムと通信してよい。しかしながら、プログラムは、必要であれば、アセンブリまたは機械言語でも実行できる。いずれのケースでも、言語は、コンパイルまたは翻訳される。

プログラム命令は、命令によりプログラムされる汎用または特殊用途の処理システムに本願明細書中に記載された動作を実行させるよう用いられてよい。または、動作は、動作を実行するためのハードワイヤードロジックを含む特定のハードウェア要素により、あるいは、プログラムされたコンピュータ構成要素とカスタムハードウェア構成要素との任意の組み合わせにより実行されてよい。本願明細書中に記載される方法は、処理システムまたは他の電子デバイスをプログラムすることにより本方法を実行するよう用いられる命令を格納した機械アクセス可能な媒体を含み得るコンピュータプログラム製品として提供されてよい。

プログラムコードまたは命令は、例えば、固体メモリ、ハードドライブ、フロッピーディスク、光記憶装置、テープ、フラッシュメモリ、メモリスティック、デジタルビデオディスク、デジタル多用途ディスク（ＤＶＤ）などを含む記憶装置、および／または、付随する機械読み取りまたは機械アクセス可能な媒体のような揮発性および／または不揮発性メモリに格納されてよく、さらには、機械アクセス可能な生物学的状態を保持する記憶装置など、より新規な媒体に記憶されてもよい。機械読み取り可能な媒体は、機械により読み取り可能な形式で情報を格納する、伝送する、または、受信するためのあらゆる機構を含んでよく、また、アンテナ、光ファイバ、通信インターフェースなど、電気、光、アコースティック、または、他の形式のプログラムコードを符号化する伝搬信号または搬送波が通過する有形媒体を含んでよい。

プログラムコードは、パケット、シリアルデータ、パラレルデータ、伝搬信号などの形式で伝送されてよく、圧縮または暗号化フォーマットで用いられることもできる。プログラムコードは、モバイルまたは固定のコンピュータ、パーソナル携帯情報機器、セットトップボックス、携帯電話およびポケットベル（登録商標）、一般電子機器デバイス（ＤＶＤプレーヤ、パーソナルビデオレコーダ、パーソナルビデオプレーヤ、衛星受信機、ステレオレシーバ、ケーブルＴＶ受像器を含む）、プロセッサ、該プロセッサにより読み取られる揮発性、および／または、不揮発性メモリ、少なくとも１つの入力デバイス、および／または、１つまたはそれ以上の出力デバイスをそれぞれ含む他の電子デバイスのようなプログラム可能な機械において実行しているプログラムに実装できる。入力デバイスを用いて入力されるデータにプログラムコードを適用することにより、記載された実施形態を実行し、かつ、出力情報を生成することもできる。出力情報は、１つまたはそれ以上の出力デバイスに適用されてよい。開示された内容の実施形態は、マルチプロセッサまたはマルチコアプロセッサシステム、ミニコンピュータ、メインフレームコンピュータ、同様に、仮想的に任意のデバイスに埋め込まれることのできる一般的またはミニチュア・コンピュータ、または、プロセッサを含む様々なコンピュータシステム構成により実施可能であることは、当業者であれば当然理解できるであろう。また、開示された内容の実施形態は、タスクまたはその一部が通信ネットワークを介し接続される遠隔処理デバイスにより実行できる分散型コンピューティング環境においても実施できる。

動作は連続プロセスとして説明されているが、実際には、そのいくつかは、並列に、同時に、および／または、分散環境において、シングルまたはマルチプロセッサマシンによるアクセスのために局所的に、および／または、遠隔に格納されるプログラムコードにより実行されてよい。さらに、いくつかの実施形態では、動作の順序は、開示された内容の趣旨に逸脱せずに並べ替えることもできる。プログラムコードは、埋め込み型コントローラによりまたはそれと共に使用されてよい。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることができる。その様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本発明の特徴及び利点は、以下の本発明の詳細な説明から明らかになるであろう。

本発明の実施形態が実行されるプラットフォームを示すブロック図である。

本発明の一実施例に従う、プラットフォーム管理容易性（ＰＭ）ハードウェアとホストＯＳとの間のインターフェースを示すブロック図である。

本発明の実施形態に従う、典型的なＥｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ（ＥＦＩ）実行時サービスに基づく管理スタックと比較したときの従来のベースボード管理コントローラ（ＢＭＣ）管理スタックを示すブロック図である。

本発明の一実施形態に従う、ＥＦＩ対応プラットフォームファームウェア（ＢＩＯＳ）により実行され、かつ、ＥＦＩ対応ホストＯＳにより用いられるプラットフォーム管理容易性のためのＥＦＩプロトコルの典型的な構造を示す。

Claims (18)

1. プラットフォーム管理容易性システムであって、
   一のＥｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ（ＥＦＩ）認識プラットフォームファームウェア（ＢＩＯＳ）、および、ホストオペレーティングシステム（ＯＳ）を動作させる一のホストプロセッサであって、前記ホストＯＳは、該ホストＯＳの健康およびパフォーマンス関連情報を一のプラットフォーム管理容易性要素に伝達する一のＯＳセンサドライバを有し、
   前記プラットフォーム管理容易性（ＰＭ）要素は、一の能力モジュール（ＣＭ）が前記ホストＯＳ健康およびパフォーマンス関連情報を処理できるようにする一のセンサエフェクタインターフェース（ＳＥＩ）を含み、前記ＯＳとは別個に動作する、
   プラットフォーム管理容易性システム。
2. 前記ホストＯＳは、前記ＰＭハードウェア要素と通信する複数のプラットフォーム管理特定ＥＦＩ実行時サービスを有する、
   請求項１に記載のシステム。
3. 機能の一のサブセットは、ホストＯＳ上で動作するプラットフォーム管理要素への限られた変更をレガシーＢＭＣプラットフォーム管理ハードウェアと通信するための一のインターフェースに提供する、ホストＯＳ上で動作する前記プラットフォーム管理特定ＥＦＩ実行時サービスを含む、請求項２に記載のシステム。
4. 前記プラットフォーム管理特定ＥＦＩ実行時サービスは、一の外部操作インターフェース（ＥＯＩ）ドライバ、一のプラットフォーム管理容易性管理インターフェースドライバ（ＰＭＡＩ）、および、一のセンサエフェクタインターフェース（ＳＥＩ）を実行し、前記ＯＳセンサドライバは、ホストＯＳ健康およびパフォーマンス関連情報を、前記ＳＥＩを介し前記ＰＭ要素に提供する、請求項２に記載のシステム。
5. 前記ＣＭは、ＯＳアクティビティをモニタし、ＯＳパフォーマンスデータを収集し、前記ホストＯＳ健康状態を決定し、前記ＯＳを一の致命的な動作状況から回復させる一の動作を勧告すること、および、前記ＯＳを一の致命的な作動状態から回復させる一の動作を実行することの少なくとも1つを実行する、請求項１に記載のシステム。
6. 一の動作は、一のユーザに前記オペレーティングシステム（ＯＳ）のパッチを強制すること、一のバイオス、ドライバをアップグレードすること、システム構成パラメータを変更すること、および、ハードウェアの交換を勧告する通知を一のユーザに送ることの少なくとも1つを含む、請求項５に記載のシステム。
7. 一の動作の勧告は、システムパフォーマンスを間に合わせで実行するか、または、前記システムの脆弱性を保護する動作をとるよう一のエンドユーザに通知することを含む、請求項５に記載のシステム。
8. 前記プラットフォームハードウェアをモニタする一のベースボード管理コントローラ（ＢＭＣ）をさらに含む、請求項５に記載のシステム。
9. 一の遠隔局と通信するよう、前記ＰＭ要素と接続する一のネットワークインターフェースカード（ＮＩＣ）をさらに含む、請求項１に記載のシステム。
10. 前記ホストＯＳからは前記ＰＭ要素に接続される前記ＮＩＣが見えない、請求項８に記載のシステム。
11. プラットフォーム管理容易性のための方法であって、
    一のホストオペレーティングシステムセンサドライバにより一のプラットフォームにおける一のホストオペレーティングシステムをモニタすることにより、ＯＳ健康状態を決定し、かつ、前記オペレーティングシステムのパフォーマンス情報を集めることと、
    前記オペレーティングシステムの前記健康状態およびパフォーマンス情報を一のプラットフォーム管理容易性要素に伝達するよう一のＥｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅサービスを起動することと、
    一のセンサエフェクタインターフェースを介し、前記オペレーティングシステムとは別個に動作する前記プラットフォーム管理容易性要素により前記オペレーティングシステムの前記健康およびパフォーマンス情報を受信することと、
    を含む方法。
12. 前記プラットフォーム管理容易性要素により、前記健康状態およびパフォーマンス情報の少なくとも1つに働きかけることをさらに含む、請求項１１に記載の方法。
13. 働きかけることは、一のソフトウェア、ハードウェア、または、ファームウェア要素をアップデートすること、
    前記ホストオペレーティングシステムのパフォーマンス構成パラメータを微調整すること、および、
    前記プラットフォームを再起動すること、
    の少なくとも１つを含む、請求項１２に記載の方法。
14. 前記受信した健康状態およびパフォーマンス情報に基づき起こされる一の適切な動作を決定すべく、前記プラットフォーム管理容易性要素により一の遠隔局と通信することをさらに含む、請求項１２に記載の方法。
15. 命令を含む機械可読媒体であって、前記命令は実行されるとき、前記機械に、
    一の健康状態を識別すべく、一のオペレーティングシステムセンサドライバにより、一のプラットフォームにおいて一のホストオペレーティングシステムをモニタし、かつ、前記オペレーティングシステムのパフォーマンス情報を集めることと、
    前記オペレーティングシステムの前記健康状態およびパフォーマンス情報を一のプラットフォーム管理容易性要素に伝達すべく一のＥｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅサービスを起動することと、
    一のセンサエフェクタインターフェースを介し、前記オペレーティングシステムとは別個に動作する前記プラットフォーム管理容易性要素により、前記オペレーティングシステムの前記健康およびパフォーマンス情報を受信することと、
    を実行させる、機械可読媒体。
16. 実行されたとき前記機械に、
    前記プラットフォーム管理容易性要素により前記健康状態およびパフォーマンス情報を分析させる複数の命令をさらに含む、
    請求項１５に記載の媒体。
17. 実行されたとき前記機械を、
    前記ホストＯＳの一の欠陥のあるソフトウェア要素をアップデートすること、前記ホストＯＳの一の欠陥のあるファームウエア要素をアップデートすること、および、問題のあるハードウェアを識別することの少なくとも１つを実行することにより、前記健康状態およびパフォーマンス情報に働きかけ、
    前記プラットフォームを再起動させるよう動作させる複数の命令をさらに含む、
    請求項１５に記載の媒体。
18. 実行されたとき、前記機械を
    前記プラットフォーム管理容易性要素により一の遠隔局と通信し、一の能力モジュールがない場合、前記健康状態およびパフォーマンス情報に働きかける前に、前記受信された健康状態およびパフォーマンス情報に基づき一の適切な動作を決定し、一の能力モジュールが存在する場合、該能力モジュールにより一の適切な動作を決定するよう動作させる複数の命令をさらに含む、請求項１６に記載の媒体。

Images