設計ガイド

この PC 温度管理設計ガイドは、 "温度が高すぎる" 場合と "温度が低すぎる" 場合の PC 温度値を決定する方法に関する情報を提供します。

これらを決定することは、PC の優れたユーザー エクスペリエンスを提供する設計に重要な要件です。 また、これらのしきい値は、複数の温度ゾーンに置かれている PC コンポーネントに対して最初に実行される軽減アクションを選択するのに役立ちます。

温度しきい値の設計

変数と前提条件

PC の熱挙動には、次の要因が影響します。

• ハードウェアの設計

  優れたハードウェア設計が重要であることは、いくら強調してもし足りないほどです。 詳細については、「 ハードウェアの温度モデリングと評価」を参照してください。

• 環境

  これらは、システムの熱挙動に影響する外的な要因です。 ソフトウェアで環境に影響を与えることができるのは、温度の制約が問題であることをユーザーに通知することによってのみです。たとえば、ブートする際のサーマルエラーのロゴが表示されることによってです。 ユーザーは、次のような要因を変更するには、別の環境に移動する必要があります。

  • 日光の放射

    画面またはシステムのどこかに影響を与える日光の強度と角度。

  • 大気温度

    環境の温度。

  • エアフロー

    空気循環あり、または、なし。 風が強い、またはコンピューター ケース内。

  • 湿度

    湿度が低い、または高い。

• ワークロードと電力消費

  ここでは、ワークロードと電力消費量が互いに比例していることを前提としています。 つまり、PC またはコンポーネントの処理量が多いほど、消費電力が増加し、生成される熱も多くなります。 これはすべてのケースで当てはまるとは限りませんが、ここではこの簡略化されたモデルでほぼ十分です。 ここでソフトウェアの軽減策が登場します。 ワークロードを減らすことで、生成される熱が少なくなり、PC の動作が維持されます。

ハードウェアを設計およびモデル化する場合、前の一覧で説明したパラメーターを考慮してください。 環境には、最悪のケースの値を使用してください。 ソフトウェアによって直接制御できるパラメーターは、ワークロードだけです。

温度の基本事項

一定のワークロードを実行している PC の熱挙動を検討します。 ワークロードが開始されると、CPU や GPU などの PC のハードウェア コンポーネントによって熱が生成され、温度が上昇します。 周囲温度に対して温度が高くなると、最終的に熱の生成が熱の放散と等しくなるまで、PC はより速く熱を放散し始めるので、温度は安定した状態に達します。 この一定のワークロードの全期間、調整は関係しないので、パフォーマンスとスループットは一定です。

次の図は、調整が関係ない場合の熱の生成、温度、パフォーマンスの関係を示しています。 PC の温度は、周囲温度と調整温度によって制限された温度エンベロープ内にとどまることに注意してください。

次に、PC が一定だがリソースを集中的に消費する別のワークロードを実行している場合の PC の熱挙動を検討します。 このワークロードが実行されると、生成される熱は、システムが周囲環境に放散できる熱よりはるかに高くなり、その結果、温度が確実に上昇します。 パッシブ冷却を使用しないと、最終的にシステムが熱くなりすぎてエンド ユーザーの快適性と安全性が悪影響を受けるまで、温度が上昇し続けるおそれがあります。 ハードウェアは、高温でも破損する可能性があります。 温度調整は、PC がこのような高温に達しないようにするのに役立ちます。 温度が定義済みの調整温度トリップ ポイントを超えて上昇すると、システムではパフォーマンスの調整が開始されます。 その結果、熱の生成が減少し、徐々に (熱の生成と放散が等しくなった後)、システム温度は安定した状態に達します。

次の図は、熱の生成を減らすためにパフォーマンスが調整された場合の、熱の生成、温度、パフォーマンスの関係を示しています。

前の図に示したどちらの場合も、システム温度が安全な範囲を超えないように、ワークロードは温度エンベロープ内で動作する必要があります。 エンベロープは周囲温度から調整温度までです。 また、どちらの場合も、熱の生成と放散が最終的にバランスの取れた状態に達し、システム温度は安定します。

温度エンベロープの定義

適切に設計された PC では、温度エンベロープをできるだけ大きくする必要があります。これにより、軽減策を使用しないエクスペリエンスを長時間ユーザーに提供できます。 前の図に示したように、温度エンベロープの下限は、周囲温度によって決まります。 上限は、調整温度によって決まります。 周囲温度はシステムの設計者が制御できる変数ではありませんが、優れたハードウェア設計によって上限を高くすることができます。 詳細については、「 ハードウェアの温度モデリングと評価」を参照してください。 ただし、ハードウェアが主要な制限ではないと仮定した場合でも、温度エンベロープを定義する際には、他の重要な要因を考慮する必要があります。

必要な動作範囲は、これらの制限要因に影響を受けることなく、できるだけ大きくする必要があります。

• 安全性

  システムの温度は、まず、ユーザーがシステムを使用してもけがをしないようにする必要があります。 この要件は、主に表面温度センサーに適用されます。

• ハードウェア保護

  温度により、システム コンポーネントが "溶ける"、または熱による損傷を与えるのを防ぐ必要があります。 この要件は、主にコンポーネント温度センサー (プロセッサ上に設置されているセンサーなど) に適用されます。

• 政府の規制

  消費者向け電気機器の安全性を確保するために、すべてのシステムが該当する業界標準 (IEC 62368 など) を満たしている必要があります。

ハードウェアの温度モデリングと評価

ハードウェア設計を補完するソフトウェア

ハードウェアを設計する場合には、温度管理を考慮することが重要です。 低電力のパーツを選択する、高温のコンポーネントを互いに離して配置する、断熱を組み込むといったことは、ハードウェアにより温度エクスペリエンスを大幅が向上する方法のほんの数例にすぎません。 これらの方法は、ソフトウェアに置き換えることができません。 そのため、ソフトウェア ソリューションは、全体的な温度エクスペリエンスのハードウェア設計を補完するためのものにすぎません。

ハードウェアの目標

一般的なワークロードの実行には、ソフトウェアの形式の熱軽減策は必要ありません。 このようなワークロードによる熱は、ハードウェアの温度設計だけで放散できる必要があります。

モデリング

モデリングは、前に説明したハードウェア目標を実現するための反復的なプロセスです。 このプロセスでは、ソフトウェアの軽減策は考慮しません。 ハードウェア機能のみを使用し、必要に応じて調整します。

1. 一般的なワークロードを定義します。 電話からサーバーまで、システムのプラットフォームに応じて、一般的なワークロードの標準セットが各システムに必要です。 これらは、HD ビデオ会議などの負荷の高いワークロードではなく、Web を閲覧する、音楽を聴くといった、平均的なワークロードである必要があります。

2. 熱はシャーシ全体に均等に分散されないので、一般的なワークロードでのシステムと個々のコンポーネントの電力消費量をモデル化します。 プロセッサなど、多くの電力を消費するコンポーネントは特に注意してください。

3. ワークロードの電力消費量の見積もりに基づいて、コンポーネントと表面の温度上昇の推移をモデル化します。

4. システムの機械設計を調整して、コンポーネントの温度が、すべての周囲温度に対してハードウェアの安全性限界とユーザーの快適性限界内にあるようにします。 機械設計の問題に対処する方法は次のとおりです。

   1. 優れた熱伝導材料を追加して、放熱機能を向上させます。
   2. 絶縁層を追加して、表面と内部の温度との間のデルタ温度を上げます。

5. 手順 1 から 4 までを満足するまで繰り返します。

6. ハードウェアを構築して評価します。

評価

ハードウェアのリビジョンごとに、代表的なワークロードに対する温度と電力を測定して熱挙動を評価する必要があります。また、必要に応じて機械設計を変更する必要があります。

このような温度評価を実行するには、次の手順をお勧めします。

1. 温度測定テスト マトリックスを定義します。

   1. このマトリックスは、通常と最大の両方の周囲温度に対応する必要があります。
   2. マトリックスには、温度モデリングの一部として識別された一般的なワークロードすべてが含まれる必要があります。すべてのワークロードについて、少なくとも 1 時間はデータをキャプチャする必要があります。
   3. マトリックスは、一貫性のある結果が生成されるように、複数の PC で複数回実行する必要があります。

2. テスト マトリックスで定義されているワークロードごとに、次のデータをキャプチャします。

   1. システムおよびコンポーネントの電力消費データ。
   2. 周囲、内部コンポーネント、表面の温度データ。
   3. 温度調整、パフォーマンス メトリック、プロセッサ使用率を検出するソフトウェア トレース。

表面とコンポーネントの温度データは、システムで達する可能性のある最高表面温度と、この温度が許容可能かどうかを直接示します。 クリティカル シャットダウンの前に、システムにどのくらいの温度上限があるか検討します。 パフォーマンス メトリック データは、システムで必要なパフォーマンスが提供されるかどうかを判断するのに役立ちます。 温度調整ソフトウェアによって記録されたトレース データは、温度調整の割合を示します。 電力消費量データと CPU 使用率データは、温度の変化に影響する要因を特定するのに役立ちます。

次の表で示しているのは、次の構成の PC についてこのようなデータを収集した例です。

構成

• マシン名: 温度テスト-1
• 平均周囲温度: 23^oC
• 温度ゾーンのトリップ ポイント (_PSV): 80^oC

カテゴリ	サブカテゴリ	ビデオのストリーミング	カジュアル ゲーム	金魚鉢	3D ゲーム	TDP
ワークロードのセットアップ		Wi-Fi 経由の 720p H.264 の全画面ビデオ ストリーミング	ゲーム名 CPU 使用率	100 匹の魚が表示される従来の IE	ゲーム名 CPU 使用率	CPU と GPU 100%
電力消費	システム電源
	SoC 電力
	ディスプレイの電源
	バックライトの電源
気温	SoC の最大温度
	最大表面温度
パフォーマンス メトリック		平均フレーム レート	平均フレーム レート	平均フレーム レート	平均フレーム レート

Windows の温度管理フレームワーク

Windows の温度管理フレームワークでは、ソフトウェアの温度管理のための包括的なソリューションを提供します。 次の例は、温度管理を実装する方法を示しています。 適切な温度モデリング、検証、温度の効果的な機械設計により、すべてのシステムでは、多くのワークロードで、対象となるほとんどの周囲温度でスムーズなユーザー エクスペリエンスを実現できる必要があります。 温度軽減策が必要な場合、Windows では効果的で拡張可能な温度管理アーキテクチャを提供します。

Windows の温度管理では、アクティブ冷却とパッシブ冷却の両方がサポートされています。 アクティブ冷却では、ファンがオンになって空気を循環させ、システムの冷却を支援します。 パッシブ冷却では、デバイスは、過度な温度条件に応じて、デバイスのパフォーマンスを低下させます。 パフォーマンスが低下すると電力消費が減り、生成される熱が少なくなります。

この Windows 温度管理フレームワークでは、システム設計者によって指定されたポリシーを使用して、システムに温度管理を適用します。 大まかに言えば、設計者は、各温度センサーから取得した測定値が各コンポーネントによってどのように影響を受けるのか指定する必要があります。 このような仕様がないと、Windows では温度によってシステムを管理することができません。 したがって、優れた温度設計を実現するために、それぞれのシステム設計者は、温度によるシステムの特性を示す必要があります。

システムでは Windows の温度管理フレームワークは必要ありませんが、オペレーティング システムと密接に統合されているので、このソリューションをお勧めします。 ただし、使用する温度管理ソリューションに関係なく、すべてのモダン スタンバイ PC は、診断のために HCK 要件に準拠している必要があります。

温度管理アーキテクチャ

Windows の温度管理アーキテクチャは、ACPI の 温度ゾーンの概念に基づいています。 ACPI 温度ゾーン モデルでは、ファームウェア、オペレーティング システム、ドライバー間の連携が必要です。 このモデルでは、明確に定義されたインターフェイスを通じて、中央の温度管理コンポーネントからセンサーと冷却デバイスを抽象化します。 温度管理の機能強化は、 ACPI 5.0 仕様の第 11 章 に基づいています。 Windows の温度管理フレームワークでは、この章で説明する機能のサブセットを実装しています。

モデルの重要なコンポーネントは次のとおりです。

• ファームウェアを使用して Windows に記述されたプラットフォームの 温度ゾーン 定義。 温度ゾーンは、温度の値が関連付けられている抽象エンティティです。 オペレーティング システムでは、ゾーン内のデバイスに温度軽減策を適用できるよう、この温度を監視します。 このゾーンには、熱を生成する一連の機能デバイスと、パフォーマンスを調整して熱の生成を制御できるデバイスのサブセットが含まれています。
• 領域の温度を表す 温度センサー 。 このセンサーには、ファームウェアまたは Windows の温度ドライバーからゾーンの温度を取得するために、温度読み取りインターフェイスを実装する必要があります。
• 温度ゾーン内のデバイスのドライバーがパッシブ冷却アクションを実行するための 熱冷却インターフェイス 。 各マネージド ドライバーには、Windows の温度インフラストラクチャに含まれる冷却インターフェイスが必要です。
• 温度ゾーンの定義を解釈し、必要なタイミングでインターフェイスを呼び出して冷却を調整する集中型の 温度マネージャー 。 温度マネージャーは Windows カーネルに実装されているので、システム設計者による作業は必要ありません。

次のブロック図は、Windows の温度管理アーキテクチャの概要です。 主なコンポーネントは、温度マネージャー、温度ゾーン、マネージド ドライバー、温度センサーです。 温度ゾーンでは、温度マネージャーによって提供される制約に基づいて、マネージド デバイスの調整動作を決定します。 温度マネージャーによって使用されるアルゴリズムでは、温度ゾーンのセンサーの温度測定値を入力パラメーターとして使用します。

システム内の温度ゾーンは、ACPI ファームウェアで記述し、ACPI を介して温度マネージャーに公開する必要があります。 構成情報を使用することで、温度マネージャーでは、管理する必要がある温度ゾーンの数、各温度ゾーンの調整を開始するタイミング、ゾーンに含まれるデバイスを認識します。 温度を監視するために、システム設計者は ACPI ファームウェアで温度通知をサポートします。

温度マネージャーは、列挙されたゾーン内の温度イベントが通知された場合、ゾーンの温度の定期的な評価を開始し、温度ゾーン内のデバイスに適用する温度調整パフォーマンス率を決定します。 この評価は、ACPI 仕様で説明されている温度調整アルゴリズムによって行われます。 次に、温度マネージャーがゾーン内のすべてのデバイスに対して特定の割合でパフォーマンスを調整することを通知し、デバイス ドライバーが調整率をデバイス クラス固有のアクションに変換してパフォーマンスを低下させます。 定期的な評価と調整は、温度ゾーンの温度が調整しきい値の温度を下回り、それ以上の調整が不要になると停止します。

フィードバック ループ

温度管理アーキテクチャを考えるもう 1 つの方法は、入力、ポリシー ディレクター、マネージド デバイスに関する点です。 次のブロック図で、フィードバック ループへの入力は温度と電力です。 これらの入力は、実装する温度ポリシーを決定するために使用されます。 温度マネージャーでは温度入力のみを使用するので、ポリシー ドライバーでは必要になるどの入力でも使用できます。 その後、温度ゾーンによって、そのポリシーがマネージド ドライバーに適用されます。 ポリシーが適用されると、センサーによって値が更新され、ループが閉じされます。

次のブロック図は、温度応答モデルの 3 つの段階を示しています。 温度と電流のセンサーからの入力により、適用する温度ポリシーを決定するのに役立つ情報が提供されます。 このポリシーはマネージド ドライバーに適用され、センサーの測定値に影響します。 この手順はフィードバック ループで繰り返されます。

システム実装者の責任

前述のように、多くのコンポーネントには、Windows の完全な温度ソリューションが必要です。 温度フレームワークのアーキテクチャは、ハードウェア ベンダーとシステム インテグレーターの責任を分けることができるよう特別に設計されています。

パートナーが実装するために必要なコンポーネントは次のとおりです。

• センサー

  温度センサー ドライバーは、ハードウェア ベンダーが提供する必要があります。 温度センサーで、使用する温度ゾーンの知識が必要ない場合、その機能は、さまざまなプラットフォーム設計で標準である必要があります。 電流センサーなど、ポリシー ドライバー用のカスタム センサーもハードウェア ベンダーの責任です。

• 温度ゾーン

  温度ゾーンは、ハードウェア ベンダーおよび/またはシステム インテグレーターが定義できます。 すべてのシステムには、ハードウェア ベンダーまたはシステム インテグレーターが実行できるクリティカル シャットダウンの温度 (およびサポートされている場合は休止温度) を実装する少なくとも 1 つの温度ゾーンが必要です。 ただし、特定のデバイスまたは軽減策のために表面温度を監視する他の温度ゾーンについては、一般的に、システム インテグレーターがシステムの熱挙動に関する具体的な知識を持っています。 したがって、これらの温度ゾーンは通常、システム インテグレーターによって実装されます。

• デバイス ドライバー用の熱冷却インターフェイス

  温度を管理するデバイスのドライバーを書く開発者も、冷却インターフェイスを実装する開発者である必要があります。 デバイス ドライバーでは、このインターフェイスを使用して、温度管理フレームワークを選択します。 デバイス ドライバーには、デバイスの機能に関する特定の知識があります。 これらの同じドライバーには、温度ゾーンによって要求されたアクションを適切に解釈できるよう、熱冷却インターフェイスを実装する必要があります。

センサー

センサーでは、温度ポリシーを決定する入力を提供します。 Windows では、温度マネージャーへの入力として温度センサーのみをサポートしています。 ただし、ポリシー ドライバーで、電流センサーのドライバーなどのカスタム ドライバーからさらに入力を受け取る場合があります。

温度センサー

温度センサーには、次の機能のモードが用意されています。

• 温度マネージャーや温度ゾーンを使用せずに、温度の変化を継続的に監視します。
• 温度が _PSV、_HOT、または _CRT で定義されたしきい値を超えたときに、温度マネージャーに通知します。
• 温度クエリに応答し、現在の温度の値を返します。

次の図は、調整中に温度監視がどのように機能するかを示しています。 ACPI ファームウェアまたは温度センサー ドライバーでは、温度が _PSV、_HOT、_CRT などの定義済みのしきい値に達すると温度マネージャーに通知し、その後、温度マネージャーからの現在の温度に対する定期的なクエリに応答する必要があります。 温度クエリの期間は、_TSP によって定義されます。

温度がしきい値を超えたときに温度マネージャーが常に通知を受け取ることができるように、温度センサーの割り込みを常にウェイク可能にする必要があります (システムがモダン スタンバイで、SoC が低電力状態の場合でも)。 温度センサーの割り込みが常にウェイク可能ではない場合、割り込みが失われる可能性を避けるために、少なくとも割り込みをレベル トリガーとして構成する必要があります。

温度センサーは複数の温度ゾーンで使用できます。ただし、1 つの温度ゾーンで複数の温度センサーを使用することはできません。

センサー ハードウェアの精度は +/- 2^oC にすることをお勧めします。

_TMP または温度センサー ドライバーによって報告される温度は、センサーの実際の値、または複数のセンサーに基づく挿入値である場合があります。

これは通常、ハードウェア ベンダーによって提供されます。 Windows では、温度を監視する 2 つの実装をサポートしています。

• 温度センサー ドライバー
• ACPI ベース

実装 1: 温度センサー ドライバー

温度センサー ドライバー は、センサーの温度を報告するだけです。 ACPI ドライバーでは、1 つの未処理の IOCTL をセンサー ドライバーに発行して、いずれかのトリップ ポイントとの交差を検出します。 さらに、ACPI はタイム アウトのない IOCTL を 1 つ発行して、現在の温度を読み取る場合があります。 センサー ドライバーでは、タイムアウトの期限が切れるのを待っている間に取り消された場合、読み取り IOCTL の取り消しを処理する必要があります。 温度センサーで、次のインターフェイスを実装する必要があります。

typedef struct _THERMAL_WAIT_READ {  
    ULONG Timeout;  
    ULONG LowTemperature;  
    ULONG HighTemperature;  
} THERMAL_WAIT_READ, *PTHERMAL_WAIT_READ;

#define IOCTL_THERMAL_READ_TEMPERATURE\  
        CTL_CODE(FILE_DEVICE_BATTERY, 0x24, METHOD_BUFFERED, FILE_READ_ACCESS)

次の表は、温度読み取りインターフェイスの入力パラメーターと出力パラメーターの説明です。

パラメーター	説明
タイムアウト	温度データを返すまでの待ち時間 (ミリ秒単位)。 0 は、待ち時間なしで直ちに温度が読み取られることを示します。 -1 は、読み取りがタイムアウトにならないことを示します。
LowTemperature	新しい温度を返すための下限しきい値。 温度が下限しきい値を下回ったらすぐに、ドライバーは IOCTL を完了する必要があります。 既に下限の温度を下回っている場合、IOCTL は直ちに完了する必要があります。
HighTemperature	新しい温度を返すための上限しきい値。 温度が上限しきい値を上回ったらすぐに、ドライバーは IOCTL を完了する必要があります。 既に上限の温度を上回っている場合、IOCTL は直ちに完了する必要があります。
IOCTL の戻り値	現在の温度を 10 分の 1 ケルビンで返す ULONG サイズの出力バッファー。

1 つの温度センサーは、1 つの温度ゾーンまたは複数の温度ゾーンで使用できます。 温度ゾーンに使用する温度センサーを指定するには、温度の _DSM を温度ゾーンに指定し、関数 2 を実装する必要があります。 (下位互換性のために、温度センサー ドライバーを熱ゾーン スタックの上に読み込むことができます。ただし、推奨される実装は、センサー ドライバーを熱ゾーン スタックから分離することです)。この_DSMは次のように定義されます。

ArgumentsArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 2 Arg3: 空のパッケージは、温度ゾーンの温度を返すデバイスへの "単一の" 参照を 返し ます。

また、温度ゾーンでは、_DEP を使用する温度センサー デバイスへの依存関係も指定する必要があります。 センサー デバイスの _DSM 実装の簡単な例を次に示します。

Device(\_SB.TSEN) {
    Name(_HID, "FBKM0001")     // temperature sensor device
}

ThermalZone(\_TZ.TZ01) {
    Method(_DSM, 0x4, NotSerialized){
        Switch (ToBuffer(Arg0)) {
            Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 and 2 (bits 0 and 2) are supported
                        Return (Buffer() {0x5})
                    }       
                    Case (2) {
                        Return ("\_SB.TSEN")
                    }
                }
            }
        }
    }

    Method(_DEP) {
        Return (Package() {\_SB.TSEN})
    }

    // Other thermal methods: _PSV, etc.

}

詳細については、「 Microsoft 熱拡張機能に対するデバイス固有のメソッド」を参照してください。

実装 2: ACPI ベース

ACPI ファームウェアでは、ACPI 仕様で定義されている _TMP と Notify(0x80) をサポートする必要があります。 この方法の利点は、システムに追加のドライバーをインストールする必要がないということです。 ただし、この方法は、ACPI 操作リージョンを介してアクセスできるリソースとの対話に限定されます。

温度ポリシー制御

温度ゾーン

温度ゾーンは、個々の温度調整エンティティです。 これには、トリップ ポイント、調整サンプル レート、調整式定数など、温度調整の独自の特性があります。 1 つの温度ゾーンには、複数の温度調整デバイスが含まれる場合があります。各デバイスは、温度ゾーン内の温度上昇の一因となる可能性があります。 同じ温度ゾーン内のすべてのデバイスは、温度ゾーンに適用されているものと同じ制約に従う必要があります。

温度ゾーンとそのパラメーターが正確に定義されていることを確認するには、システム設計者は次のことを実行する必要があります。

• システムのシャーシ内のホット スポットを特定し、これらのホット スポットが温度センサーに対して熱を放散する方法を決定します。 (理想的には、表面温度センサー以外の温度センサーはシステム上のホット スポットに設置されています)。
• システムの温度関係の特性を示します。 温度センサーの測定値をコンポーネントの温度と表面温度にマップします。

オーバースロットルしきい値

Windows 10 より、Windows 温度管理には、 温度ゾーン状態と呼ばれる新しい機能が 過剰に調整されているという 1 つの状態とともに導入されました。 温度ゾーンがデバイスの設計されたスロットル レベルを超えると、温度マネージャーにより、システムが過剰に調整されていることがオペレーティング システム コンポーネントに通知されます。 この通知により、システムはワークロードを減らし、温度状態を改善できます。

温度マネージャーでは、過剰に調整されている状態にある温度ゾーンの数のグローバル カウントを保持します。 カウントがゼロ (0) を超えた場合、温度マネージャーにより、過剰に調整されていることを示す Windows Notification Facility (WNF) 通知をシステムに送信されます。 過剰に調整されているゾーンの数がゼロ (0) に戻ると、温度マネージャーにより、過剰に調整されているゾーンが存在しないことを示す別の WNF 通知がシステムに送信されます。

温度ゾーンのオーバースロットルしきい値を指定するには、関数 3 を実装して、温度の _DSM を温度ゾーンで指定する必要があります。 この _DSM は次のように定義されます。

ArgumentsArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 3 Arg3:: 空のパッケージは、現在のオーバースロットルしきい値をパーセントで表す "整数" 値を 返し ます。

次に示すのは、調整レベルの 0% から 49% でゾーンが過剰に調整されていることを示す _DSM の例です。

 ThermalZone (TZ4) {
    Name (_HID, "QCOM24AE")
    Name (_UID, 0)
    Name(_TZD, Package (){\_SB.CPU4, \_SB.CPU5, \_SB.CPU6, \_SB.CPU7})
    Method(_PSV) { Return (3530) }
       Name(_TC1, 1)
       Name(_TC2, 1)
       Name(_TSP, 1)
       Name(_TZP, 0)
       // _DSM - Device Specific Method
       // Arg0: UUID Unique function identifier
       // Arg1: Integer Revision Level
       // Arg2: Integer Function Index (0 = Return Supported Functions)
       // Arg3: Package Parameters
       Method(_DSM, 0x4, NotSerialized) {
          Switch (ToBuffer(Arg0)) {
             Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                   Case(0) {
                      // _DSM functions 0 and 3 (bits 0 and 3) are supported
                      Return (Buffer() {0x9})
                   }
                   Case (3) {
                      Return (50)  // overthrottled below 50%
                   }
                }
             }
          }
       }
 } // end of TZ4

オーバースロットルしきい値は、温度ゾーンを参照して Notify(0x81) を受信すると再読み取りされます。

ACPI オブジェクトの実装

次の表に、温度ゾーンを定義するために ACPI ファームウェアに実装する必要があるすべての ACPI オブジェクトを示します。

カテゴリ	制御メソッド
ゾーン内に含まれるデバイスを識別する	_TZD 温度ゾーン内のデバイスの一覧を表示します。 _PSL (省略可能) 温度ゾーン内のプロセッサの一覧を表示します。 代わりに _TZD にプロセッサを含めることができます。Windows では両方の実装をサポートしています。
アクションを実行する必要がある温度のしきい値を指定します	_PSV 調整を開始する温度。 詳細については、「 温度エンベロープの定義」を参照してください。 _HOT (省略可能) オペレーティング システムがシステムを休止状態にする温度。 休止状態をサポートしていないシステムでは、オペレーティング システムによりクリティカル シャットダウンが開始されます。 これは、ユーザー データを保存する休止状態の利点により、すべての x86/x64 システム用の少なくとも 1 つの温度ゾーンに強く推奨されます。 _CRT オペレーティング システムでクリティカル シャットダウンが開始される温度。 ユーザー モードの通知はありません。 システム上の少なくとも 1 つのサーマルゾーンで _CRT を指定する必要があります。 そうしないと、システムがクリティカルな温度に達したときに、システムでシャットダウン パスが実行されません。 代わりに、ファームウェアのフェールセーフ トリップ ポイントに達したため、オペレーティング システムから電力が引き出されている可能性があります。
パッシブ冷却の動作の説明	_TC1 温度変化に対する温度調整パフォーマンスを、温度マネージャーがどの程度積極的に適用するかを制御します。 _TC2 現在の温度と _PSV との温度差に対する温度調整パフォーマンスを、温度マネージャーがどの程度積極的に適用するかを制御します。 _TSP ゾーンの適切な温度サンプリング間隔を 10 分の 1 秒単位で指定します。 温度マネージャーでは、この間隔を使用して、温度調整パフォーマンスを評価する頻度を決定します。 0 より大きくなければなりません。 詳細については、「 温度調整アルゴリズム」を参照してください。
アクティブ冷却の動作の説明	_ACx (省略可能) ファンをオンにする温度。 _AC0 を最大とし、最大から最小の順にする必要があります。 _ALx アクティブ冷却デバイスの一覧。
アクティブ/パッシブ冷却ポリシーを設定する	_SCP (省略可能) アクティブ冷却とパッシブ冷却の両方がゾーンでサポートされている場合に、ユーザーの優先する冷却ポリシーを設定します。
最小スロットル制限	_DSM UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 を使用して、最小スロットル制限を設定します。 これは Windows の温度フレームワークではカスタムであり、ACPI では定義されていないことに注意してください。 詳細については、「 最小スロットル制限」を参照してください。
温度をレポートする	_TMP 温度ゾーンの温度を読み取ります。 _HID Windows の温度ドライバーを読み込むベンダー固有のハードウェア識別子。 _DTI (省略可能) ゾーンの温度しきい値の 1 つを超過したことをプラットフォーム ファームウェアに通知するため。 この方法を使用すると、ファームウェアでは、ゾーンのしきい値を変更してヒステリシスを実装できます。 _NTT (省略可能) プラットフォームのファームウェアにも _DTI 経由で通知する必要がある、大幅な温度変化を指定する場合。
温度マネージャーに通知する	Notify 0x80 しきい値 (_PSV) を超えたことをオペレーティング システムに通知します。 Windows 温度マネージャーによって、温度制御が開始されます。 Notify 0x81 (省略可能) ゾーンのしきい値が変更されたことをオペレーティング システムに通知します。 Windows 温度マネージャーは、新しい値を使用するように自身を更新します。 通常、このメソッドはヒステリシスを実装するために使用されます。
温度センサー デバイスの指定	_DSM UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 を使用します。 詳細については、「 温度センサー」を参照してください。 _DEP 温度センサーが参照しているデバイスを読み込みます。

最小スロットル制限

最小スロットル制限は、調整されたデバイスの _PSV 要求に対して下限を作成する Microsoft 熱拡張機能 _DSM メソッドです。 つまり、制御するデバイスのパフォーマンスが温度ゾーンによってどのくらい制限されるかを決定します。 指定されている場合、最小スロットル _DSM は、起動時、および温度ゾーンが ACPI の Notify(0x81) を受信するたびに読み込まれます。 パッシブ冷却のアルゴリズムが繰り返されるたびに、次のものを使用して、温度マネージャがゾーン内のデバイスに適用するパフォーマンス制限 (DP) の変化を計算します。

DP [%] = _TC1 × (Tₙ – Tₙ₋₁) + _TC2 × (Tₙ – Tₜ) 次に、以下を使用して、実際のパフォーマンス制限を計算します。

Pₙ = Pₙ₋₁ – DP 最小スロットル制限 (MTL) が実装されている場合、この 2 番目の式は次のように変更されます。

Pₙ = max(Pₙ₋₁ – DP, MTL) 温度ゾーンの最小スロットル制限を指定するには、関数 1 を実装して、温度の _DSM を温度ゾーンで指定する必要があります。 この _DSM は次のように定義されます。

ArgumentsArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 1 Arg3:: 空のパッケージは、現在の最小スロットル制限をパーセントで表す "整数" 値を 返し ます。

次に示すのは、スロットルを 50% 未満に制限する _DSM の簡単な例です。

ThermalZone(\_TZ.TZ01) {
    Method(_DSM, 0x4, NotSerialized) {
        Switch (ToBuffer(Arg0)) {
            Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 and 1 (bits 0 and 1) are supported
                        Return (Buffer() {0x3})
                    }       
                    Case (1) {
                        Return (50)
                    }
                }
            }
        }
    }

カーネル内の温度マネージャー

Windows 温度マネージャーは、Windows カーネルの一部として実装されています。 すべての温度ゾーンの温度を監視し、必要に応じて温度調整を適用します。

温度マネージャーは、ACPI ドライバーに対して現在の温度についてのクエリを実行するたびに、温度ゾーン内のすべての温度調整デバイスに適用する必要がある温度調整パフォーマンス率を計算します。 温度の上限は、パッシブ冷却のしきい値 (_PSV) を超えた時、また、温度がそれ以下に冷却されて温度の上限が 100% に戻るまで温度サンプリング間隔 (_TSP) ごとに、評価されて適用されます。 ハードウェアでは、_PSV を超過したことを検出し、ハードウェア ACPI イベント通知を介して通知する必要があります。

温度調整アルゴリズム

温度調整アルゴリズムでは、次の式が使用されます。これは、ACPI 仕様で定義されています。

DP [%] = _TC1 × ( Tₙ – Tₙ₋₁ ) + _TC2 × (Tₙ – Tₜ) where

Tₙ = 温度ゾーン内の温度センサーによる現在の温度の測定値 (10 分の 1 ケルビン)。 Tₙ₋₁ = 以前の測定値の温度。 Tₜ = ターゲット温度 (10 分の 1 ケルビン) (_PSV)。 DP = 必要なパフォーマンスの変更。 これは、ゾーン内の各冷却デバイスに適用される 0 (完全に調整済み) - 100% (未調整) の間の線形値です。 この式が表すのは、温度の変化とパフォーマンスの調整との間のフィードバック ループです。 ループの各反復処理では、現在と以前の温度の測定値との間の温度差によって、DP% 減少するパフォーマンス P を求めます。 DP の値は、適用する 温度調整 の量です。 冷却装置の多くには、冷却の軽減策に対する温度の線形応答がありません。 これらのデバイスでは、温度制限は、どのくらい冷却する必要があるかデバイスに示すヒントです。 各冷却デバイスでは、この線形値をデバイス固有の温度軽減策に独自にマッピングします。 デバイスのパフォーマンスを調整すると、電力消費と熱生成が減少し、それにより温度が低下します。

_TC1 と _TC2 の 2 つの定数は、このフィードバック ループにおいてどのくらい積極的に温度調整を適用するか制御します。 _TC1 が大きいほど、安定した温度を維持するために、より積極的に温度調整が使用されます。 _TC2 が大きいほど、トリップ ポイントに温度を近づけるために、より積極的に温度調整が使用されます。

次の表は、温度マネージャーが DP を計算して適用する方法の例を示しています。 この例では、次のパラメーター値を使用します。

Configuration

• _PSV = 325^oK
• _TC1 = 2
• _TC2 = 3
• _TSP = 5000 ミリ秒
• 温度は、5 秒ごとに 1 度増加していると仮定します。

次の表の一番右の列 (ラベルは P) は、これらのパラメーターで指定した制約を適用した結果として得られる、調整されたパフォーマンス レベルを示しています。

反復	時刻	Tₙ	DP	P
1	0 秒	326oK	= 2 × 1 + 3 × 1 = 5%	95%
2	5 秒	327oK	= 2 × 1 + 3 × 2 = 8%	87%
3	10 秒	328oK	= 2 × 1 + 3 × 3 = 11%	76%
4	15 秒	320oK	= 2 × 1 + 3 × 4 = 14%	62%
5	20 秒	330oK	= 2 × 1 + 3 × 5 = 17%	45%
...

ポリシー ドライバー

既定では、ACPI 仕様に従って調整率を判断するために使用されるアルゴリズムは、すべての温度ゾーンで使用されます。 既に説明したように、このアルゴリズムは、温度ゾーンに接続されている温度センサーのみに基づいています。これは制限できます。

別のアルゴリズムが優先される場合、システム設計者は、優先するアルゴリズムを具体化するためのポリシー ドライバーを実装できます。 ポリシー ドライバーは、制御するゾーンの温度ゾーン スタックの上にあります。 このゾーンでは、温度マネージャーの ACPI アルゴリズムの代わりにポリシー ドライバーのアルゴリズムを使用できます。 ポリシー ドライバーのアルゴリズムには、入力としてアクセスできるすべての情報を考慮する機能があります。 ドライバーによって行われたポリシーの決定は、その情報をログに記録し、それを温度ゾーンに渡して実行するために、温度マネージャーに渡されます。

温度ゾーンにポリシー ドライバーを使用することは、(ACPI ではなく、オペレーティング システムではない) ポリシー ドライバーが、ゾーンをどのように調整するかを決定するだけの役割を担います。ゾーンを調整するタイミングとその量を決定するだけで済むことを意味します。

ポリシー ドライバーが存在する場合、すべてのトリップ ポイント、すべての温度定数、最小スロットル制限などが完全に無視されます。 オペレーティング システムには、現在の調整レベルで温度ゾーンが設定されている理由についての詳細情報がありません。 専用のソリューションの代わりにポリシー ドライバーを使用すると、いくつかの利点があります。 ポリシー ドライバーでは、デバイスを調整する組み込みプロセスを利用します。 温度の軽減策を実現するために温度ゾーンで実行できることは、ポリシー ドライバーでも実行できます。 さらに、Windows の温度管理の診断が自動的に継承されます。

温度ポリシー インターフェイスは、ゾーンが過剰に調整されているかどうかを示す新しいパラメーターを含むように更新されました。 このパラメーターは FALSE に初期化されています。 以前のポリシー ドライバーでは新しいパラメーターを認識しませんが、新しいドライバーでは '2' のポリシー バージョンを検出すると、新しいパラメーターがサポートされていることを認識します。

#define TZ_ACTIVATION_REASON_THERMAL      0x00000001  
#define TZ_ACTIVATION_REASON_CURRENT      0x00000002

#define THERMAL_POLICY_VERSION_1          1
#define THERMAL_POLICY_VERSION_2          2

typedef struct _THERMAL_POLICY {  
    ULONG           Version;  
    BOOLEAN         WaitForUpdate;  
    BOOLEAN         Hibernate;  
    BOOLEAN         Critical;  
    ULONG           ActivationReasons;  
    ULONG           PassiveLimit;  
    ULONG           ActiveLevel;
    BOOLEAN         OverThrottled;  
} THERMAL_POLICY, *PTHERMAL_POLICY;

ポリシー ドライバーは、 OverThrottled パラメーターが TRUE に設定されているポリシー IOCTL を完了することで、温度ゾーンが過剰に調整されていることを示している可能性があります。 温度条件が改善すると、温度ポリシー ドライバーは、温度ゾーンが復旧したことを示すために、 OverThrottled を FALSE にリセットして IOCTL を完了させることができます。 過剰調整フラグが設定されている場合、Windows ではポリシー ドライバーを調整する必要はありません。

温度によって管理されたデバイス

温度ゾーンでは、管理されているデバイスのカーネル モード ドライバーを使用して熱挙動を制御します。 1 つの温度調整デバイスが複数の温度ゾーンに存在する場合があります。 複数の温度ゾーンで異なる温度調整パフォーマンス率が要求された場合、温度調整デバイスに適用される最小の温度調整パフォーマンス率が温度マネージャーによって選択されます。

冷却装置の多くには、冷却の軽減策に対する温度の線形応答がありません。 このような場合、温度制限は、デバイスに対する必要な冷却レベルのヒントです。 各冷却デバイスでは、この線形値を固有の温度軽減策に独自にマッピングします。

各デバイス ドライバーが読み込まれると、ACPI では温度冷却インターフェイスを照会し、それぞれの応答デバイスを冷却デバイスとして登録します。 その後、パッシブ冷却が処理中で、ゾーンの温度制限が変更されると、ACPI はゾーン内の各冷却デバイスでこのインターフェイスを呼び出します。 すると、冷却デバイスでは指定された温度制限を特定の冷却特性にマップし、適切な冷却対策が実装されます。 冷却デバイスが複数の温度ゾーンに表示される場合、デバイスを最大限制限する温度の上限 (最も低い割合) がデバイスに渡されることに注意してください。

注意 Windows には、プロセッサ、バックライト、ACPI コントロール方式のバッテリ用に温度調整の組み込み実装が用意されています。

温度冷却インターフェイス

Windows には、デバイス ドライバーが温度調整デバイスとして登録し、温度調整率の要求を受けるための拡張ポイントが用意されています。 そのため、デバイスで、その割合を自身にとって意味のあるアクションに変換する必要があります。

温度調整デバイスとして追加するデバイスでは、まず、_HIDs を温度ゾーンの温度デバイスの一覧に追加し、次に示すインターフェイスのセットを実装する必要があります。 各デバイス ドライバーが読み込まれると、ACPI はこのインターフェイスを照会し、それぞれの応答デバイスを冷却デバイスとして登録します。 その後、パッシブ冷却が処理中で、ゾーンの温度制限が変更されると、ACPI はゾーン内の各冷却デバイスでこのインターフェイスを呼び出します。 すると、冷却デバイスでは指定された温度制限を特定の冷却特性にマップし、適切な冷却対策が実装されます。 冷却デバイスが複数の温度ゾーンに表示される場合、デバイスを最大限制限する温度の上限 (最も低い割合) がデバイスに渡されることに注意してください。

//  
// Thermal client interface (devices implementing  
// GUID_THERMAL_COOLING_INTERFACE)  
//

typedef  
_Function_class_(DEVICE_ACTIVE_COOLING)  
VOID  
DEVICE_ACTIVE_COOLING (  
    _Inout_opt_ PVOID Context,  
    _In_ BOOLEAN Engaged  
    );  

typedef DEVICE_ACTIVE_COOLING *PDEVICE_ACTIVE_COOLING;  

typedef  
_Function_class_(DEVICE_PASSIVE_COOLING)  
VOID  
DEVICE_PASSIVE_COOLING (  
    _Inout_opt_ PVOID Context,  
    _In_ ULONG Percentage  
    );  

typedef DEVICE_PASSIVE_COOLING *PDEVICE_PASSIVE_COOLING;  

typedef struct _THERMAL_COOLING_INTERFACE {  
    //  
    // generic interface header  
    //  
    USHORT Size;  
    USHORT Version;  
    PVOID Context;  
    PINTERFACE_REFERENCE    InterfaceReference;  
    PINTERFACE_DEREFERENCE  InterfaceDereference;  
    //  
    // Thermal cooling interface  
    //  
    ULONG Flags;  
    PDEVICE_ACTIVE_COOLING ActiveCooling;  
    PDEVICE_PASSIVE_COOLING PassiveCooling;  
} THERMAL_COOLING_INTERFACE, *PTHERMAL_COOLING_INTERFACE;  

#define THERMAL_COOLING_INTERFACE_VERSION 1

プロセッサ

プロセッサの場合、温度マネージャーは、プロセッサ電源マネージャー (PPM) に温度調整率を伝えます。 プロセッサの温度調整は、Windows の組み込み機能です。

プロセッサ アグリゲーター

プロセッサ アグリゲーター デバイスは、温度を軽減するために コア保留 を許可します。 プロセッサ アグリゲーター デバイスが温度ゾーンに所属している場合、ゾーンでは温度を軽減するためにコア保留を指定できます。 コア保留が発生するようにプロセッサを調整する必要はありません。 この実装は、 論理プロセッサのアイドリング (LPI) と並行して動作します。 ただし、これはコア保留の注意事項の対象となることに注意してください。 具体的には、保留中のコアに関連付けられているどの作業によってもコアが実行されます。

Device(\_SB.PAGR) {
    Name(_HID, "ACPI000C")
}
ThermalZone(\_TZ.TZ01) {
    Name(_TZD, Package() {"\_SB.PAGR"})
    // Other thermal methods: _PSV, etc.
}

グラフィックス

サードパーティ製のグラフィックス ミニポート ドライバーを温度で管理するには、Windows グラフィックス ポート ドライバー (Dxgkrnl.sys) とやり取りする必要があります。 Dxgkrnl.sys には温度冷却インターフェイスが備わっていて、すべてのスロットル要求がミニポート ドライバーに渡されます。 要求をデバイス固有のアクションに変換するのは、ミニポート ドライバーの役割です。

次のブロック図は、GPU を制御する温度ゾーンのアーキテクチャを示しています。

バックライト

バックライトを減らすと、モバイル プラットフォームの温度条件が大幅に改善します。 Windows では、操作中にシステム画面の明るさが 100 ニット未満に熱的に制限されないようにすることをお勧めします。

バックライト制御の場合、温度マネージャーは、温度調整の割合をモニター ドライバー (Monitor.sys) に伝えます。 Monitor.sys では、この熱入力と Windows のその他の入力に基づいて実際のバックライト レベルの設定を決定します。 次に、Monitor.sys では、ACPI またはディスプレイ ドライバーを使用して、バックライト レベルの設定を適用します。

バックライトが含まれる温度ゾーンの温度が上昇し続ける場合、要求された温度調整率は最終的に 0% に低下する可能性があることに注意してください。 ACPI またはディスプレイ ドライバーでのバックライト レベルの実装では、パフォーマンス コントロールで使用できる明るさの最小レベルがエンド ユーザーに引き続き表示されるようにする必要があります。

注意 操作中に、システム ディスプレイの明るさが 100 ニット未満に熱的に制限されることはありません。

バッテリー

システムのもう 1 つの主な熱源はバッテリの充電です。 ユーザーの観点からは、制限された温度条件では充電を減らし、完全に停止する必要があります。 ただし、通常のユース ケースでは、バッテリの充電が妨げられないようにする必要があります。

注意 システムが (1) アイドル状態で、周囲温度が 35^oC を下回る範囲内、または (2) 周囲温度が 25^oC を下回っている場合は、バッテリの充電を調整しないことをお勧めします。

Windows 制御メソッド バッテリ ミニクラス ドライバー (Cmbatt.sys) では、前述のように、熱冷却インターフェイスを直接使用します。 ファームウェアでは、充電を行う際に現在の温度制限を考慮する必要があります。 充電の温度制限を設定するには、新しい ACPI の制御メソッドが必要です。 このメソッドは、 ACPI 5.0 仕様のセクション 9.14.1 で定義されているデバイス固有のメソッド (_DSM) として実装されます。

温度調整率を適用するために、Cmbatt.sys はデバイス固有のメソッド (_DSM) の制御メソッドを評価して、ACPI ファームウェアに充電の温度制限を設定する要求を行います。 _DSM の制御 メソッド内で、温度の制限を示す GUID が定義されます。

Arg #	値	説明
Arg0	4c2067e3-887d-475c-9720-4af1d3ed602e	UUID
Arg1	0	リビジョン
Arg2	1	関数
Arg3	0 から 100 までの整数値	バッテリ充電の温度制限。 計算されたパッシブ スロットルの割合に相当します。
戻り値	該当なし	戻り値はありません

アクティブ冷却

オペレーティング システムの観点から、プラットフォームには、ファン制御を実装するために使用できる 2 つの戦略があります。

• アクティブなトリップ ポイントを含む 1 つ以上の ACPI 温度ゾーンを実装して、ファンを有効/無効にします。

  Windows のこの温度フレームワークでは、非常に基本的なレベルでアクティブ冷却デバイスをサポートしています。 サポートされている唯一のデバイスの受信トレイは ACPI ファンであり、オン/オフ シグナルでのみ制御できます。

• (ドライバー、埋め込みコントローラーなどを介して) ファンを制御する独自のソリューションを実装します。

  Windows では、ファン専用のソリューションの動作は制御しませんが、Windows により、診断情報とテレメトリを収集できるよう、埋め込みコントローラーを含むすべての実装について、温度マネージャーへのファン通知がサポートされています。 そのため、すべてのモダン スタンバイ PC にはオペレーティング システムへファンが公開されている必要があり、それ以外の PC には強く推奨されています。

アクティブ冷却の実装は、前に説明したパッシブ冷却の軽減策とは完全に切り離されていることに注意してください。

ACPI 温度ゾーンによるファン制御

Windows では、ACPI 1.0 D 状態ベースのファンの定義がサポートされています。 (詳細については、ACPI の仕様 を参照してください)。したがって、コントロールはファン のオン と オフに制限されます。 ファンのドライバーは、Windows の ACPI ドライバー (Acpi.sys) に用意されています。

1. 温度センサーは、温度がトリップ ポイントを越えたことを読み取り、関連付けられている温度ゾーンで Notify(0x80) を発行します。
2. 温度ゾーンは、_TMP 制御メソッドを使用して温度を読み取り、温度をアクティブなトリップ ポイント (_ACx) と比較して、ファンをオンまたはオフする必要があるかどうかを判断します。
3. オペレーティング システムでは、ファン デバイスを D0 または D3 の状態にして、ファンをオンまたはオフにします。

次のブロック図は、ACPI 温度ゾーンによって制御されるファンの制御フローを示しています。

Scope(\_SB) {
    Device(FAN) {
        Name(_HID, EISAID("PNP0C0B"))
        // additional methods to turn the fan on/off (_PR0, etc.)
    }

    ThermalZone(TZ0) {
        Method(_TMP) {...}
        Name(_AC0, 3200)
        Name(_AL0, Package() {\_SB.FAN})
    }
}

ACPI のマルチスピード ファン

ACPI 1.0 を使用してファンの速度を複数実現するには、次の 2 つのオプションがあります。

• 物理ファンが 1 つしか存在しない場合、温度ゾーンには複数の "ファン" を含めることができます。 一度に多くの "ファン" をオンにすることは、ファンの速度が速くなることを意味します。 詳細については、 ACPI 5.0 仕様のセクション 11.7.2 のこのオプションの例を参照してください。
• ファンがオンの場合は、それ自体で回転する速度を決定できます。 たとえば、埋め込みコントローラーを備えたシステムでは、このオプションを選択できます。

ファン専用ソリューション

Windows では、いずれかの実装を使用してファンのアクティビティを検出できる必要があります。 プラットフォームで ACPI 温度モデルを使用する場合、Windows ではファンのオンとオフを担当するため、アクティブであることを既に認識しています。 専用のソリューションを使用してファンを制御する場合は、Windows にはファンが実行中であるという通知が必要です。 これを有効にするために、Windows では、ACPI 4.0 ファン拡張機能の一部のサブセットがサポートされます。これは次の表に示します。

特徴量	説明	サポートされています
_FST	ファンの状態を返します。	はい
Notify(0x80)	ファンの状態が変更されたことを示します。	はい
_FIF	ファン デバイス情報を返します。	いいえ
_FPS	ファンのパフォーマンス状態の一覧を返します。	いいえ
_FSL	ファンのパフォーマンス状態 (速度) を設定します。	いいえ

Windows では _FST オブジェクトを使用して、ファンが実行中である (コントロール フィールドが 0 以外) かオフ (コントロール フィールドが 0) かどうかを判断します。 また Windows では、_FST が変更され、再評価する必要があることを示すものとして、ファン デバイスでの Notify(0x80) もサポートされます。

_FST オブジェクトを実装するファンは、温度ゾーンの _ALx デバイスの一覧に含まれている必要はありません。ただし、オプションとしてこのリストに含まれる場合があります。 このオプションを使用すると、通常、ファンがサードパーティのドライバーによって制御されるハイブリッド ソリューションが有効になりますが、サードパーティのドライバーがインストールされていない場合は、OS の温度ゾーンによって制御できます。 ファンが _ALx デバイスの一覧に含まれていて、温度ゾーンによって有効になっている (D0 に配置) 場合、_FST オブジェクトは 0 以外の Control 値を示すために必要です。

すべてのファンについて、Windows では次のアルゴリズムを使用してファンの状態を決定します。

1. ファンが D0 内にある場合 (温度ゾーンの _ACx トリップ ポイントを超過した結果)、ファンは有効です。
2. ファンが D3 内にあり、ACPI 4.0 拡張機能がサポートされていない場合、ファンは無効です。
3. ファンが D3 内にあり、ACPI 4.0 拡張機能がサポートされている場合、オペレーティング システムでは _FST の [制御] フィールドに 0 以外の値があるかどうかをチェックし、ファンが有効かどうかを確認します。

例 1: ハードウェア ファン制御

この例では、ファンは埋め込みコントローラーによって制御されます。

1. 埋め込みコントローラーでは、独自の内部アルゴリズムに基づいてファンを起動または停止します。
2. ファンを起動または停止した後、埋め込みコントローラーではファン デバイスで Notify(0x80) を発行します。
3. オペレーティング システムでは新しい _FST を評価し、ファンの新しい状態を読み取ります。

次のブロック図は、埋め込みコントローラーによって制御されるファンの制御フローを示しています。

次の ASL の例では、ファン状態の変更をオペレーティング システムに通知できる "FAN" デバイスを定義します。

Scope(\_SB) {
    Device(FAN) {
        Name(_HID, EISAID("PNP0C0B"))
        Name(_FST, Package() {0, 0, 0xffffffff})

        // \_SB.FAN.SFST called by EC event handler upon fan status change
        Method(SFST, 1) {
            // Arg0 contains the new fan status
            Store(Arg0, Index(_FST, 1))
            Notify(\_SB.FAN, 0x80)
        }
    }

    // Omitted: EC event handler
}

例 2: ドライバーのファン制御

この例では、サードパーティのドライバーがファンを制御しています。

1. ドライバーでは、独自の内部アルゴリズムに基づいてファンを起動または停止します。
2. ドライバーは、ファンの状態を変更し、その温度デバイスでカスタム制御メソッド (SFST) を評価します。
3. 温度デバイス制御メソッドは、ファン デバイスで _FST の内容と問題の Notify(0x80) を更新します。
4. オペレーティング システムでは新しい _FST を評価し、ファンの新しい状態を読み取ります。

次のブロック図は、サードパーティによって制御されるファンの制御フローを示しています。

Scope(\_SB) {
    Device(FAN) {
        Name(_HID, EISAID("PNP0C0B"))
        Name(_FST, Package() {0, 0, 0xffffffff})
    }

    Device(THML) {
        Name(_HID, "FBKM0001")
        Method(SFST, 1) {
            // Arg0 contains the new fan status
            Store(Arg0, Index(\_SB.FAN._FST, 1))
            Notify(\_SB.FAN, 0x80)
        }
    }
}

ファンの存在

プラットフォームでは、ACPI 名前空間にファン デバイス (PnP ID PNP0C0B) を含めることによって、システムにファンがあることを示します。 Windows では、システムにファンがあることを示すものとして、また、このデバイスがシステムにファンがないことを示すものとして、このデバイスの存在を示します。

モダン スタンバイに固有のガイダンス

Windows の温度管理フレームワークはカーネルの一部であり、すべての Windows システムに付属しています。 このため、上記のマテリアルはすべてのコンピューターに適用されます。 ただし、さまざまな種類のコンピューターでは、モダン スタンバイに特化した追加のガイダンスが必要です。

モダン スタンバイにより、スマートフォンの電源モデルが PC に取り込まれます。 これにより、ユーザーが携帯電話に期待するようになる、すばやく電源をオンまたはオフできるユーザー エクスペリエンスが実現されています。 また、携帯電話の場合と同様に、モダン スタンバイを使用すると、適切なネットワークが利用可能になるたびに、システムを最新の状態に維持し、到達可能な状態にすることができます。 Windows 10 では、特定の Windows 認定要件を満たす低電力プラットフォームでのモダン スタンバイをサポートしています。

モダン スタンバイ PC は、薄型および軽量のフォーム ファクターの高度なモバイル デバイスです。 さらに、モダン スタンバイ PC は常にオンで、ACPI S0 状態です。 堅牢で信頼性の高いカスタマー エクスペリエンスを実現するために、機械設計からファームウェアおよびソフトウェアの実装まで、システム全体を温度特性に注意して設計する必要があります。 このため、すべてのモダン スタンバイ PC は、温度の要件に準拠する必要があります。

モダン スタンバイの要件

すべてのモダン スタンバイ PC は、次の HCK テストに合格する必要があります。

• すべてのモダン スタンバイ PC には、クリティカル シャットダウンの温度 (_CRT) が定義されている 1 つ以上の温度ゾーンが必要です。 x86 システムの場合は、ユーザーデータの保存をトリガーするために、クリティカルな休止の温度 (_HOT) を定義することをお勧めします。 _HOT は _CRT よりも小さくする必要があり、_CRT はファームウェアの緊急時の温度トリップ ポイントよりも低くする必要があります。
• 各温度管理ゾーンでは、センサーの実際の温度 (_TMP) が報告される必要があります。 テストでは、PC 上でさまざまなワークロードを実行するので、温度が変化することが予想されます。

さらに、各 PC に SoC 用の温度センサーを少なくとも 1 つ搭載することをお勧めします。

アクティブ冷却の要件

ファンを使用するモダン スタンバイ PC は、次の追加要件に従う必要があります。これは HCK でテストされます。

• ファンはオペレーティング システムに公開されている必要があります。 詳細については、「 ファンの存在」を参照してください。
• オペレーティング システムでは、ファンがオンになっているかまたはオフになっているかを常に把握している必要があります。 モダン スタンバイでアイドル状態の回復性がある場合でも、ファン アクティビティの変更は、SoC をウェイク (スリープ解除) して状態を更新する必要があります。 ファン通知の実装の詳細については、「 ACPI 温度ゾーンによるファン制御」を参照してください。
• PC がモダン スタンバイ状態にある間は、ファンの電源をオンにしないでください。 モダン スタンバイ中の現実的なワークロードの場合、画面がオフになるたびに、ファンの電源をオンにしないようにする必要があります。

ユーザーの観点からは、PC はモダン スタンバイ状態のときにオフになっているように見えます。 ユーザーは、モダン スタンバイ状態の PC がシステムの "スリープ" 状態であるかのように動作することを期待しています。 このため、ユーザーは、スリープ中の従来の PC の場合と同様に、ファンが起動することはないと想定します。 ファンが起動している場合、ユーザーは、音が聞こえたり、熱風が循環しているのを感じたりするので、コンピューターが正しく動作していないと考える可能性があります。 そのため、モダン スタンバイ状態のときはファンの電源をオンにしないでください。 必要な動作の詳細については、「 モダン スタンバイ PC の HCK テスト要」を参照してください。

これらの要件は、画面がオンになっているときの冷却ポリシーが、画面がオフになっているときとは異なる必要があることを意味します。 PC は、画面がオンになっている間はアクティブ冷却を使用する場合がありますが、画面がオフになっている場合はパッシブ冷却のみを使用する必要があります。 画面がオフになっているときよりオフになっているときの方が、ファンのアクティブなトリップ ポイントはるかに少なくなる可能性があります。 ACPI 実装では、モダン スタンバイに入るときに _ACx を更新する必要があります。 独自のソリューションの場合は、埋め込みコントローラーのポリシーを更新してください。

プロセッサの調整

PPM は、最大の、目的の、最小のパフォーマンス レベルを PEP に伝えます。 温度制限の条件下では、最大のパフォーマンス レベルは、温度マネージャーに要求された調整するパフォーマンスと同じである必要があります。 そのため、PEP は、PPM のパフォーマンス レベルの要件に基づいて、CPU の物理的な電圧と周波数を設定します。

ファンノイズ信号

Windows 11 以降では、デバイスは、ユーザーにクールで静かなエクスペリエンスを提供することを目的として、リソース管理の決定に使用するために OS にファン ノイズ信号を送信できます。 このオプトイン インターフェイスを使用すると、ファームウェアはファン RPM 情報を 0 (ファンオフ) から Max RPM に値として OS に送信できます。これは、OS がリソース管理の決定で必要に応じてデバイスを冷却するために使用できます。 これは、次の 2 つの主な利点に寄与します。

1. 静かなユーザーエクスペリエンス: ファンの騒音と熱風の吹き出しは、顧客の不満の重要な原因です。 これは特に、デバイスで実行されている作業量が少ない場合やフォアグラウンド作業がない場合など、ユーザーが大量のファン アクティビティを期待していない場合に当てはまります。
2. バッテリ寿命の向上: ファン速度が高いほど電力使用量が増加し、DC時のバッテリドレインが速くなり、AC時の充電速度が遅くなります。

現時点では、このシグナルを使用して Search Indexer タスクを管理できます。また、追加のバックグラウンド タスクでもこのシグナルを使用できるようにする予定があります。

次の図は、ファームウェアからソフトウェアへのレイヤーでのファン ノイズ信号の送信方法をまとめたものです。

ファンノイズ信号のしくみ

ACPI インターフェイスの詳細

この機能をサポートするために使用されるデバイス固有メソッド (_DSM、UUID: A7611840-99FE-41ae-A488-35C75926C8EB) の 4 つの関数を次に示します。 _FST (ファンの状態) については、ACPI 仕様 のセクション 11.3.1.4 と 例 1: 熱管理デバイスの ハードウェア ファン制御 に関するページを参照してください。

次の図は、これらの関数の使用方法のフローをまとめたものです。

以下のブロック図は、Notify(0x80)制御方式を含む、組込コントローラによって制御されるファンの制御フローを示しています。

関数の列挙 (関数 0)

オペレーティング システムがプラットフォームと対話するには、名前空間を介してACPIデバイスを公開する必要があります。 このデバイスには、EISAID("PNP0C0B") を含む _CID オブジェクトが含まれている必要があります。 このデバイスのスコープには、デバイスがサポートする _DSM を示す次の _DSM 定義が含まれている必要があります。

UUID	リビジョン	関数	説明
A7611840-99FE-41ae-A488-35C75926C8EB	0	0	関数の列挙

戻り値: 上記の関数0から3のサポートを示すために、関数列挙関数 (関数0) は0xFを返す必要があります。 詳しくは、ACPI 仕様の セクション 9.1.1 をご覧ください。

ファントリップポイントサポート機能の取得(機能1)

ハードウェアは、RMM の観点から何がサポートされるかを OS に伝えます。

UUID	リビジョン	関数	説明
A7611840-99FE-41ae-A488-35C75926C8EB	0	1	ファントリップポイントのサポートを受ける

引数

Arg0: UUID: A7611840-99FE-41ae-A488- 35C75926C8EB

Arg1:リビジョン:0

Arg2: 関数: 1

Arg3: 空のパッケージ

戻り値: ファン トリップ ポイントでサポートされる粒度 (RMM) を含む整数値。 0 以外の場合、OS は通知の粒度の倍数であるトリップ ポイントを選択できます。 たとえば、細分性が 200 の OSPM では、0、200、400、600 などの RPM で乗車ポイントを選択できます。 値 0 は、乗車ポイントがサポートされていないことを示します。

ファントリップポイント設定機能(機能2)

OS は、次の通知トリップ ポイントとは何かをハードウェアに通信します。ハードウェアは、それが発生したときに OS に通知します。

UUID	リビジョン	関数	説明
A7611840-99FE-41ae-A488-35C75926C8EB	0	2	ファンの乗車ポイントを取得する

引数

Arg0: UUID: A7611840-99FE-41ae-A488- 35C75926C8EB

Arg1::リビジョン:0

Arg2: 関数: 2

Arg3: 下と上の乗車ポイントを含むパッケージ。 (2 要素 int。インデックス 0 の下位、インデックス 1 の上)

OSPM では、機能 1 で指定されたトリップ ポイントの粒度の倍数であるトリップ ポイントのみが選択されます。 ファンの実際の速度が上または下の乗車ポイントの上または下に行く場合、プラットフォームはファン デバイスで Notify(0x80) を発行する必要があります。 OSPM は、_FST (ファンの状態) を評価して、現在のファン速度を決定します。 乗車ポイントが設定されているときにファン速度が指定された乗車ポイントの外側にある場合、プラットフォームは直ちに Notify(0x80) を発行する必要があります。

上部の乗車ポイントは、細分性の倍数になります。 低い乗車ポイントは (粒度の倍数) + 1 (下の乗車ポイントの上の乗車ポイント < ) になります。 RPM が 0 の場合、OS は低いトリップ ポイントを 0 に、上のトリップ ポイントを 1 に設定します。

戻り値: なし。

ファン動作範囲の取得機能 (機能 3)

RPM 間のマッピング –> 影響。 このインターフェイスを実装できるのは 1 つのファン (SoC に最も近いもの) だけであることに注意してください。ACPI 仕様の セクション 9.1.1の 3 つの関数と関数 0 をすべて実装する必要があります。

UUID	リビジョン	関数	説明
A7611840-99FE-41ae-A488-35C75926C8EB	0	3	ファンの動作範囲を取得する

引数

Arg0: UUID: A7611840-99FE-41ae-A488- 35C75926C8EB

Arg1::リビジョン:0

Arg2: 関数: 3

Arg3: 空のパッケージ

戻り値: 次の形式を含むパッケージ。

Package () {
	Impact1MaxRPM,		// Integer (DWORD)
	Impact2MaxRPM, 		// Integer (DWORD)
	Impact3MaxRPM, 		// Integer (DWORD)
	MaxRPM				// Integer (DWORD)
}

フィールド	書式	説明
Impact1MaxRPM	整数 (DWORD)	ファン影響範囲 1 の最大 RPM。
Impact2Max RPM	整数 (DWORD)	ファン影響範囲 2 の最大 RPM。 >= Impact1Max RPM である必要があります。
Impact3MaxRPM	整数 (DWORD)	ファン影響範囲 3 の最大 RPM。 >= Impact2Max RPM である必要があります。
MaxRPM	整数 (DWORD)	ファンが動作できる最大 RPM。 >=Impact3MaxRPM である必要があります。

この表は、ファンの影響レベルごとに RPM 範囲を導き出すために使用されます。

影響スコア	下限RPM値	上限RPM値
1	1	Impact1MaxRPM
2	Impact1Max RPM + 1	Impact2Max RPM。
3	Impact2MaxRPM + 1	Impact3MaxRPM
4	Impact3Max RPM + 1	MaxRPM

影響範囲がプラットフォームで使用されていない場合 (たとえば、ファンが影響範囲 2 から影響範囲 4 に直接遷移する場合)、未使用の影響範囲の最大 RPM を低い影響範囲の最大 RPM と同じに設定することで、これを示すことができます。

例マッピング

OSに送信される値	RPM換気扇	ユーザーの作業	RPM Ceiling
0–低	1 ~ 4000 RPM (<=25 dBA)	ファンがオンでもオンでも、迷惑が少ない	Impact1Max RPM = 4000
1–中	4001-5000 RPM (25-30 dBA)	中程度の迷惑でファンオン	Impact2MaxRPM = 5000
2 –中、高	5001-6000 RPM (30-36 dBA)	中高迷惑でファンオン	Impact3Max RPM = 6000
3 – 高	6001+ RPM (36+ dBA)	ファンオンと高い迷惑	Max RPM = 9000

ASLコード例

    ...
 
    // _DSM - Device Specific Method
    // Arg0: UUID Unique function identifier
    // Arg1: Integer Revision Level
    // Arg2: Integer Function Index (0 = Return Supported Functions)
    // Arg3: Package Parameters
    Method(_DSM, 0x4, NotSerialized) {
            If(LEqual(Arg0, ToUUID("A7611840-99FE-41ae-A488-35C75926C8EB"))) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 through 3 are supported
                        Return (Buffer() {0xf})
                    }
                    Case(1) {
                        // Report 200 RPM granularity for trip points
                        Return (\_SB.FAN0.GRAN)
                    }
                    Case(2) {
                        // Save lower RPM trip point
                        Store(DeRefOf(Index(Arg3, 0)), \_SB.FAN0.LRPM)
                        // Save upper RPM trip point
                        Store(DeRefOf(Index(Arg3, 1)), \_SB.FAN0.URPM)
                        // Configure hardware for the trip points, Tell EC to set fan speed trip point.
                        \_SB.FAN0.CRNF()
                        Return (0)
                    }
                    Case(3) {
                        Return (Package(4) { 
                            4000, // 1-4000 RPM is impact score 1
                            5000, // 4001-5000 RPM is impact score 2
                            6000, // 5001-6000 RPM is impact score 3
                            9000})// 6001-9000 RPM is impact score 4
                    }
                    Default {
                        Return(Buffer(One) { 0x00 }) // Guid mismatch
                    }
                }
            }
            Else {
                Return(Buffer(One) { 0x00 }) // Guid mismatch
            }
    }  
 
} // end of FAN0
}

テストとトレース

Windows パフォーマンス アナライザー (WPA)でログとビューを収集するには、次の手順を参照してください。

1. 設定 -> Windows の検索 -> 高度な検索インデクサー 設定 -> 詳細 -> インデックスの削除と再構築 (再構築)
2. wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
3. システムを再起動します
4. 設定の チェックインdex 状態 -> Windows の検索 (デバイスが AC 電源に接続されていることを確認してください)。
5. インデックスが完了したら、トレースを停止します: wpr -boottrace -stopboot AcpiFanNoiseImpact.etl (保存せずにトレースをキャンセルする: wpr -boottrace –cancel)
6. Windows パフォーマンス アナライザー (WPA) を使用して AcpiFanNoiseImpact.etl を開きます。

AcpiFanNoiseImpact.zip または 、次のファイルをダウンロードし、AcpiFanNoiseImpact.wprp として 保存します。

<?xml version="1.0" encoding="utf-8"?>
<WindowsPerformanceRecorder Version="1.0" Comments="Test" Company="Microsoft Corporation" Copyright="Microsoft Corporation">
    <Profiles>
        <!-- BufferSizes are in KB in WPRP -->
        <!-- System Collectors -->
        <SystemCollector Id="MySystemCollector" Name="NT Kernel Logger">
            <BufferSize Value="1024" />
            <Buffers Value="100" />
            <StackCaching BucketCount="2048" CacheSize="20480" />
            <FlushThreshold Value="70" />
        </SystemCollector>

        <!-- Event Collectors -->
        <EventCollector Id="MyEventCollector" Name="User Session Logger">
            <BufferSize Value="1024" />
            <Buffers Value="100" />
            <StackCaching BucketCount="2048" CacheSize="20480" />
            <FlushThreshold Value="70" />
        </EventCollector>

        <!-- System Providers for collecting kernel events. -->
        <SystemProvider Id="SP_AcpiFanNoiseImpactTrace">
            <Keywords Operation="Add">
                <Keyword Value="Loader" />
                <Keyword Value="Power" />
                <Keyword Value="ProcessThread" />
            </Keywords>
        </SystemProvider>
        <!-- System Providers for collecting kernel events. -->
        <!---->

        <EventProvider Id="EP_Microsoft-Windows-Kernel-Power" Name="Microsoft-Windows-Kernel-Power" Level="5" NonPagedMemory="true">
            <Keywords>
                <Keyword Value="0x2" />
            </Keywords>
            <CaptureStateOnStart>
                <Keyword Value="0x0" />
            </CaptureStateOnStart>
            <CaptureStateOnSave>
                <Keyword Value="0x0" />
            </CaptureStateOnSave>
        </EventProvider>
        <EventProvider Id="EP_Microsoft-Windows-Kernel-Acpi" Name="Microsoft-Windows-Kernel-Acpi" Level="5">
            <Keywords>
                <Keyword Value="0xffffffff" />
            </Keywords>
            <CaptureStateOnSave>
                <Keyword Value="0xffffffff" />
            </CaptureStateOnSave>
        </EventProvider>
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" Name="7073707A-0587-4E03-B31F-6443EB1ACBCD" Level="5" />
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" Name="C42BBFDB-4140-4ada-81DF-2B9A18AC6A7B" Level="5" />
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" Name="63bca7a1-77ec-4ea7-95d0-98d3f0c0ebf7" Level="5" />
        <EventProvider Id="CustomEventProvider_AcpiTraceGuid_WPP" Name="03906A40-CCE8-447F-83F4-E2346215DB84" Level="7" />
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" Name="8215e965-d26e-548e-af0e-940c1f06f250" Level="5" NonPagedMemory="true">
            <CaptureStateOnSave>
                <Keyword Value="0xFFFFFFFFFFFFFFFF" />
            </CaptureStateOnSave>
        </EventProvider>

        <Profile Id="PowerTrace.Verbose.File" LoggingMode="File" Name="PowerTrace" DetailLevel="Verbose" Description="Power trace logging">
            <Collectors>
                <SystemCollectorId Value="MySystemCollector">
                    <SystemProviderId Value="SP_AcpiFanNoiseImpactTrace" />
                </SystemCollectorId>
                <EventCollectorId Value="MyEventCollector">
                    <EventProviders>
                        <EventProviderId Value="EP_Microsoft-Windows-Kernel-Power" />
                        <EventProviderId Value="EP_Microsoft-Windows-Kernel-Acpi" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" />
                        <EventProviderId Value="CustomEventProvider_AcpiTraceGuid_WPP" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" />
                    </EventProviders>
                </EventCollectorId>
            </Collectors>
        </Profile>
    </Profiles>
    <TraceMergeProperties>
        <TraceMergeProperty Id="TraceMerge_Default" Name="TraceMerge_Default" Base="">
            <DeletePreMergedTraceFiles Value="true" />
            <FileCompression Value="true" />
            <CustomEvents>
                <CustomEvent Value="ImageId" />
                <CustomEvent Value="BuildInfo" />
                <CustomEvent Value="VolumeMapping" />
                <CustomEvent Value="EventMetadata" />
                <CustomEvent Value="PerfTrackMetadata" />
                <CustomEvent Value="WinSAT" />
                <CustomEvent Value="NetworkInterface" />
            </CustomEvents>
        </TraceMergeProperty>
    </TraceMergeProperties>
</WindowsPerformanceRecorder>

次の図は、ファンが大きいときに検索インデクサーの作業がバッキングオフされていることを示す WPA グラフの例です。

検索インデックスを完全にオフにするファンのレベルが 1 つあります (最も高く、影響スコア 4 である必要があります)。ただし、ファンの他のすべてのレベルは、中断ではなくアクティビティを減らす必要があります。 たとえば、ACPI が関数 3 で Impact3Max RPM = 4000 RPM (ファン動作範囲の取得機能) を宣言した場合、ファン RPM > 4000 (4100 RPM、4500 RPM) の場合、SearchIndexer.exeが表示され、CPU 使用率SearchProtocalHost.exe中断されます。

次の図は、SearchIndexer.exeと SearchProtocolHost の中断を示す WPA グラフの例を示しています