本頁面由 Cloud Translation API 翻譯而成。

RFC-0230：Fuchsia 中的「Pause-To-Idle」

RFC-0230：在 Fuchsia 中暫停使用
狀態	已接受
領域	電源
說明	介紹 Fuchsia 如何處理系統電源狀態變更，透過「暫停使用至閒置」用途改善設計
問題	127897
毛皮變化	865570
作者	harshanv@google.com
審查人員	andresoportus@google.com cja@google.com claridge@google.com cpu@google.com jamesr@google.com jmatt@google.com maniscalco@google.com quiche@google.com surajmalhotra@google.com
提交日期 (年-月-日)	2023-06-02
審查日期 (年-月-日)	2023 年 10 月 24 日

編輯此 RFC

編輯 RFC 中繼資料

摘要

此 RFC 提議支援使用 Suspend-to-Idle 系統，以及從這個狀態重新啟用本文件介紹高階需求和設計。這是定義程序和整體設計的第一層 RFC。我們還會提供涵蓋實作的更多 RFC 或設計文件並提供各單元的詳細資料

因為電源管理機制的運作模式它沒有積極使用的程度，也加回所有功能。系統層級可與 ACPI S 狀態進行比較。不同類型的系統對電源和喚醒延遲時間有不同的要求，「系統功率」可以做為轉換機制電源管理系統進行完整 (或主動) 時，關閉或移除較低耗電的系統稱為執行階段電源管理。

定義一組標準系統電源等級，並且僅實施相關等級無法達到「獲得最佳功率」的目標並遵循系統恢復時間延遲情形部分 OS 嘗試翻新執行階段電源管理，但尚未實現充分的優勢。

為瞭解決這個問題，Fchsia 將採用精細的電源管理機制也整合了 Power 架構電源架構是本文旨在介紹所有電源管理元件制定及落實政策系統的每部子裝置 (包括 SoC/週邊裝置/匯流排等) 可以自由定義任意數量的功率實現相應的喚醒延遲時間進入 Power Framework。Power Framework 扮演重要的角色做出明智的政策決策並付諸實行，藉此掌握將系統降到低電量Power Framework 會根據從使用者空間系統元件接收到的資訊 (例如並且保證恢復時間、電板配置來降低耗電量資訊（支援系統電源設定，恢復時間和喚醒功能）並瞭解系統目前的功率 (例如每個子裝置的層級、喚醒延遲時間以及其電力資源依附元件及其 I/O 佇列)。

例如：

Power Framework 收到來自使用者空間中系統元件的要求降低系統所需的功率，確保延遲時間計算的是 500 毫秒Power Framework 含有以及部分或所有喚醒延遲時間根據這些資訊 Power Framework 可能決定只讓次要 CPU 離線喇叭 (而非麥克風) 處於離線狀態、低耗電模式的 Wi-Fi。並將畫面轉換成較低的刷新率系統執行這些動作的原因就能在 500 毫秒內還原成完全正常運作。幾乎無法取回電源速度較低，因為這可能需要或喚醒延遲時間超過 500 毫秒。
Power Framework 收到來自使用者空間中系統元件的要求沒有活躍使用者，因此將系統降到較低的電量互動。電源架構沒有在關掉系統所需的電量不足電源架構可能會決定讓系統進入「暫停使用」狀態，請盡快暫停。這就是我們明確定義的 Fuchsia 模型 Power Framework 能夠瞭解及採取行動的電源等級。

提振精神

隨著 Fuchsia 的擴充，支援不同類型的電池產品電源管理是支援的關鍵功能這個該文件專門收錄 Fuchsia 系統取用系統本身即可進入閒置狀態，並恢復完全啟用狀態。採用的設計原則

驅動程式和元件可能會成為「感知能力」方法是定義明確的通訊協定和介面並未在墨西哥的 RFC。我們會在詳細的設計文件中討論它們。
這些驅動程式和元件在系統層級變更時不適用。
這項設計將納入基礎設施，實現任何類型的未來強制執行功率政策 (例如其他系統功率轉換、執行階段電源管理)，而不必變更驅動程式庫程式碼。

這需要 Fuchsia 的多層次才能參與定義明確的當中涵蓋的各項功能。此 RFC 不包含評估系統電力和效能所需的指標在不同系統電源供應器中運作

需求條件

如果系統想節省電力及使用可用的低電量， Fuchsia 應導入到低功耗系統層級的轉換機制 (實際情形視採用 ACPI S-state 或任何專屬方式) 來自使用者空間系統元件的電源管理請求。這個 RFC 目標進入閒置系統電源等級基本規定「暫停使用」和「恢復使用」的運作方式如下：

Fuchsia 應採用使用者空間系統元件的提示，並依照系統能力和狀態自行選擇暫停使用。
如果使用者空間提供恢復延遲時間的要求，Fchsia 應該也同樣尊重他人如未提供恢復延遲時間，Fchsia 應該進入盡可能縮短恢復延遲時間。
Fuchsia 提供一種方法，可以取得董事會專屬設定但系統能將系統完全恢復運作將啟用模式從「暫停使用」切換為「閒置狀態」。
「暫停使用」功能應有相等或更佳的效用對比其他作業系統的耗用量
Fuchsia 應公開 CPU、記憶體和子裝置的健康與指標以便根據使用者空間元件進行偵錯、效能測量和制定政策。
Fuchsia 能讓您將各項元件的作業排序所需的電源依附性
Fuchsia 必須在支持權力的子裝置上公開遙測資料，以及拒絕/忽略要求的子裝置。如果變更要求遭拒，應說明原因而這些子裝置會記錄下來，可用於偵錯及微調比較耗電
Fuchsia 駕駛人應使用適當的定義介面

設計

「暫停至閒置」是許多作業系統支援的低功耗系統級別。每個作業系統會以不同方式定義這種低功率位。在 Fuchsia 中不僅可以享有最佳省電模式的定義，規定。這項功率定義是以 (而非) 為基礎只能遵循 ACPI 標準規格中的定義。根據 ACPI 規格的定義，S1 的定義為低喚醒延遲休眠狀態我們在規格。Fchsia 的「暫停至閒置狀態」的目標是盡可能靠近轉換至其中一個 ACPI S1 狀態實作項目

以下摘錄自詳細實作規格的規格說明目標。

In this ACPI S1 implementation, all system context is preserved
except CPU caches. Before entering S1, the system caches are flushed and the
hardware is expected to

1. Place processor in stop grant state.

2. Stop the processor input clock, placing the processor into the stop clock
state.

3. Placing system memory into a self-refresh or suspend-refresh state.
Refresh is maintained by the memory itself or through some other reference
clock that is not stopped during the sleeping state.

4. Stopping all system hardware clocks (asserts standby signal to system
PLL)

Normally the RTC will continue running. In this case, all clocks in the
system have been stopped (except for the RTC). Hardware must reverse the
process (restarting system clocks) upon any enabled wake event whereby
OSPM must first invalidate the CPU caches and then transition back
into the working state.

不同 OS 會以自己的方式實作「停權」模式，定義 ACPI 規格的定義本文件將概述「暫停至閒置狀態」，討論 Fuchsia 可如何改進。簡單來說，Fuchsia 會實作「Pause-to-Idle」勝過無法完全實作下表的其他作業系統。

子系統	功率	附註
啟動 CPU	C0 (Pn)	以最低耗電量狀態執行啟動 CPU
非啟動 CPU	關閉或較低 C 狀態 (如果有的話)	非開機 CPU 的最低電量 (如果無法離線時)
記憶體	自行重新整理	系統是否提供該選項
子裝置	最低電量 (例如 ACPI 中定義的 D3Hot)	副裝置會根據恢復時間要求的最低功率調整。
時鐘樹和電源軌	盡力	電源架構根據主機板配置和已知的系統喚醒要求，關閉某些時鐘樹和電源軌的某些部分

副裝置電源狀態轉換範例：

Considering a sub-device can support power levels as follows;

0 - off state with wake latency to fully functional being at most 650 ms
1 - higher power level with wake latency being at most 500 ms
2 - higher power level with wake latency being at most 450 ms
3 - higher power level with wake latency being at most 100 ms

If Fuchsia receives a request to go to low power state and the resume time
to be <=500ms, it can choose to take down the sub-device to level 2.

與其他 OS 的廣泛比較：

Linux kernel 無法查詢驅動程式的電源狀態例如喚醒延遲、精細的電源轉換狀態和電源每狀態的使用量並未提供這項資訊。Linux 並未將任何政策決策整合至核心層應遵循重要原則，避免在 Linux 核心以外提供不可開放原始碼的專屬程式碼。以 Linux 為基礎的作業系統 (如 Android 及 Ubuntu) 會建構電源管理機制 Linux kernel 提供的電源管理功能他們擁有只執行查詢並提供給使用者空間的最少量資訊。沒有喚醒延遲時間和耗電量等詳細資料，因此能限制 Linux 的 OS 可完全發揮節省電力和擴充能力所需的電力電池續航力。舉例來說，Android 電源管理做為包裝函式 Linux 電源管理。此制定了多項電源政策和功能，例如「早期暫停架構」、「Wake Lock 機制」獲得能量的好處但仍在設法延長電池壽命及降低系統就會恢復作業

另一方面，Windows 會查詢驅動程式產生運作的延遲時間供駕駛人選擇是否提供電源狀態。這有助於 Windows 可主動管理執行階段電源管理。Windows 驅動程式必須使用開放原始碼，因此廠商可以建立驅動程式嵌入功能專屬資訊但是 Windows 並未接收任何主機板特定設定，限制自訂執行階段權政策決策也可能導致專屬主機板同時存在多個驅動程式庫版本專屬設定

Fuchsia 不僅會結合運用這兩個 OS 所得到的結果，同時也確保解決已知的設計問題晶片上有許多種限制 Fuchsia 採用的差異化技術讓人們瞭解 AI 系統如何做出決策

a) 每個晶片各有自己的電源軌管理和時鐘樹例如管理、CPU 狀態管理和 RTC 時鐘管理紫紅色基礎架構，足以提供符合適用政策的資訊讓人們瞭解 AI 系統如何做出決策

b) Fuchsia 為駕駛人提供基礎設施，讓他們定義並且讓他們自行轉換，而不是執行配備固定電源等級，例如 ACPI D 狀態 (D0、D0i1/2/3、D1、D2 和 D3)。

c) Fuchsia 應提供作業基礎設施，方便駕駛人回報電力設定，例如喚醒延遲時間和其他驅動程式的依附元件 Power Framework 必須取得這項資訊，才能積極進行電源管理。這有助於覆蓋其他嘗試中的 OS 改造此資訊，做出與電源相關的決策。

高階設計

啟動/設定：

Power Framework 會是第一個獲得低功耗的 Fuchsia 模組從使用者空間中系統元件發出的模式要求如要執行安裝後

整個系統的強大拓撲

Power Framework 需要建立或接收電源拓撲圖和擁有權都一樣如此一來，Power Framework 才能導入子裝置切換至較低的電量建構電源拓撲的最終設計會進一步影響在 Power Framework 設計文件中。下列有助於建立及維護 Power 拓撲圖表。

a) 元件依附元件 DAG：

使用 DFv2 時，所有驅動程式都是元件，元件管理員則具備能力圖表」驅動程式和其他元件這個依附關係圖適合做為 Power Framework 的參考，用來建構功率拓撲圖表。驅動程式管理器和元件管理員具備不同的與交換庫連線的系統檢視畫面元件管理員終於是做為單一可靠資料來源的元件依附元件圖表電力架構都應該能查詢或存取這項資訊這張圖表對於 Power Framework 而言是不夠的

b) 電源元件依附性資訊：

電力拓撲必須擷取不同的次裝置，並時時維持相同的動態感知能力。在任何指定時間必須確保已執行指定裝置的電源依附元件。目前元件和驅動程式庫拓撲都無法執行這項作業。
驅動程式和元件的目前狀態

驅動程式變更的執行階段資訊存在與力量都應該傳達給 Power Framework舉例來說，插座和遊戲引入新的驅動程式並終止部分驅動程式庫執行個體。無法運作，且相應的驅動程式可能會停止運作個值。有些駕駛人可透過系統聰明地關閉導致執行階段電源管理受到影響

所有電量變更都必須向電源架構傳達。其中部分可能是元件管理員提供的執行階段資訊，或其中部分可能是驅動程式管理器，驅動程式。
系統的狀態，例如 CPU、記憶體、時鐘和電源狀態。(選填)？

除了上述的所有資訊外，Power Framework 也採用了存取 CPU 狀態、時鐘樹、記憶體和電源軌等資訊這有助於我們做出正確的決策確保資料故障相應的驅動程式或核心電源架構用於查詢目前的電量，以及對在暫停和繼續期間執行一組活動。
接收靜態主機專屬設定和特定產品相關資訊此外還會從 0 自動調整資源配置您完全不必調整資源調度設定
接收「暫停使用」和「恢復」的使用者設定，例如喚醒以及「恢復」延遲時間
在改用較低的功率前，先確定喚醒能力。

Power Framework 能夠列出可喚醒的子裝置透過各種可存取的設定來提供不同的系統低功耗等級。知道/學習能喚醒系統低電量的駕駛等級可以登錄打斷機的打斷機，使其能夠使用電源喚醒架構。Power Framework 會將這項資訊與董事板的資訊搭配使用設定、產品設定和使用者空間設定哪些子裝置可以喚醒核心。

以下是啟動/啟動程序的整體流程。

說明文字：開始/程序序列圖

暫停使用進入流程：

Power Framework 會負責將整個系統藉由與 Fuchsia 模組溝通，實現任何指定系統力量例如元件管理員、驅動程式管理器和 Zircon如果模式/狀態/電源使用者空間的要求層級，Power Framework 可以選擇拒絕要求進行每個模式/州/省/電源等級時，都需要使用按特定順序觸發一組不同的動作。

本文討論的具體模式是低耗電模式之一暫停使用。此模式處於低喚醒延遲時間的睡眠狀態。力量架構需要維護元件和系統的狀態機器整體情況

轉入/退出模式或決定拒絕模式轉換全都會由 Power Framework 內部處理。
當系統已進入指定模式，且 Power Framework 收到要求系統進入其他模式Power Framework 需要瞭解狀態機器及其轉換程序，以進入新的系統模式。
部分轉換作業可能無法成功，系統模式可能不會變更。這類情況應交由 Power Framework 處理。電源架構應該在每次模式轉換後注意產生的模式/電源等級。

當 Fuchsia 選擇進入閒置模式以節省電力/電池時， Power Framework 會顯示系統最新的電源供應器。拓撲Power Framework 會判斷哪些元件需要轉換然後叫用介面進行轉換。這需要所有元件和驅動程式，以便註冊並實作介面調整架構所定義的功率層級，讓好處電源架構會詳細說明這項設計設計文件，以及電源感知驅動程式和元件設計文件。

請務必定義哪些硬體/軟體中斷可設為 Wake。電源架構將叫用電源元件擁有者適當的介面觸發他們的喚醒程序您可以選擇要求核心設定 Wake 來源暫存器 (如果可以的話，以及需要時)。這類設計相關細節，請參閱電源感知核心設計文件。

在驅動程式庫/元件無法更換電量時， Power Framework 您可以選擇終止作業或按照程序執行。

Power Framework 應發出暫停單調時間的要求， CPU 離線或將 CPU 設為低耗電狀態，然後關閉時鐘並以及其他架構相關操作 (如果有的話)。這可能是直接對核心發出系統呼叫，或是透過驅動程式庫轉送以及元件或 HAL，這會在後續設計文件中討論

以下是接到「暫停」呼叫時的高階流程圖。

說明文字：暫停至閒置序列圖表

從「暫停使用」流程繼續：

系統會在開機 CPU 收到幹擾您起床只有在程式語言中中斷控制器，或在某些情況下，或在特定情況下，而是透過硬體將每部裝置提供給 CPU並非完全乾擾繼續播放。導致觸發條件恢復運作的中斷活動就是由 Power Framework 設計，並且在轉換系統前進行程式設計進入閒置狀態。

由於啟動 CPU 不會離線，因此中斷會傳遞至或開機 CPU，這會叫用正確的中斷服務常式。力量架構會從以下位置收到暫停呼叫的狀態：做為 syscall 函式傳回或透過驅動程式庫轉送核心。兩者皆可驅動程式庫或 Power Framework 必須依照反向順序採取行動，啟動整個系統，從啟用時鐘和電源網域開始讓開機 CPU 才能正常運作讓次要 CPU 更加耗電使記憶體不再發生自我重新整理和其他架構相關動作時會很有幫助Power Framework 將負責恢復所有裝置並依照順序使用對應的驅動程式與元件

以下是從暫停使用暫停流程的高階履歷範例。

說明文字：接續程序圖表

模組責任

Power Framework 元件：

Power Framework 元件則會由負責以及繼續流程電源架構需要

使用元件架構和驅動程式的服務來維護效能拓撲這個架構的重點在於
維持元件 (包括驅動程式) 之間的依附元件關係。
使用核心或適當驅動程式庫中的服務來接收以及 CPU 功能和目前狀態
由核心或相關驅動程式呼叫服務，

a. 為了將 CPU 載於線上/離線

b. 設定 Wake 來源中斷事件登錄作業 (如果有需要的話)

c. 如何暫停單調時間

d.架構特有變更和程式設計

以上所有步驟都可以是個別的服務呼叫，也可以是單一透過服務呼叫這項設計決策和細節將 Power Framework 和 Power 的相關設計文件中記錄認識核心設計文件。
接收電源元素及其屬性 (例如功率) 電源、依附元件以及驅動程式和元件的喚醒延遲時間
用於為駕駛人和元件設定適當電源等級的介面依序列出
如要公開電源拓撲的目前狀態、狀態等指標，以及每個驅動程式庫/元件的喚醒觸發條件，用於偵錯和遙測。

驅動因素

管理電源資源的每個 Fuchsia 驅動程式庫都需要實作下列以積極節省電力。

使用 Power Framework 註冊管道

a. 提供支援的電源元件及其功率相關資訊等級、依附元件和喚醒延遲時間

b. 實作會改變電源等級的介面

c. 隨時提供電源狀態資訊 (例如：會在內部觸發)。

d.公開目前狀態和內部設定等指標用於偵錯和遙測用途

核心

整體來說，核心可實作下列各項責任為獨立系統呼叫或單一系統呼叫

確保系統進入「Pause-to-Idle」狀態時暫停單調時間。系統處於停權模式時，請勿提前。繼續時，這樣可確保執行緒能一致地瞭解相對度量系統處於啟用狀態的時間這樣可確保但不會對程式的正確性造成影響。是一定要有一致的行為模式系統暫停期間
在 CPU 之前編寫 Wake Source (如適用) 的程式調整功率。適用特定架構和核心必須根據主機類型設定適當的暫存器
將 CPU 離線或恢復連線。
匯出 CPU 指標。系統會在履歷完成時傳回這個項目，或是可能是 Power Framework 叫用的個別系統呼叫；偵錯工具/驅動測量工具，以取得每個 CPU 的狀態。

使用者空間叫用的「暫停至閒置狀態」與時間表無關系統的行為。不過，排程器務必要知道並採取適當行動本單元稍後會說明採用「Power Aware 核心」。

全新互動的高階設計

使用 Power Framework 註冊為喚醒功能的驅動程式

裝置駕駛人可得知幹擾能否從看板上喚醒像是驅動程式庫或其他來源的因素這個架構的簡短總覽例如：音訊、觸控和蓋子時產生的干擾裝置可定義為可喚醒功能。在目前的設計中對應的裝置驅動程式會將 SetWakeDevice() 做為暫停參數的一部分函式註冊為喚醒來源。(例如：ACPI 蓋子驅動程式)。 )。這會在內部叫用 ACPI 驅動程式庫的 SetWakeDevice() 呼叫。此為特定架構，且無法擴充。

Power 架構是集中處理電力決策的中心位置會決定哪些項目可以從電量喚醒系統那就是將整個系統轉換為因此可喚醒功能的干擾情形應與 Power Framework 分享資訊使用預先定義和共用管道電源架構可以設定或與驅動程式庫程式通訊來設定完全一樣。這項設計決策將是電力架構 (Power Framework) 的一部分。設計、電源感知核心設計和電源感知驅動程式和元件設計說明文件

透過靜態設定佈建主機板的電源設定

每個 Jamboard 都可定義設定和屬性，做出明智的權力政策決定以下列舉幾個例子子裝置/週邊裝置必須各自獨立，系統功率不同以及能夠從低耗電模式下喚醒系統的副裝置級別。例如，某些可喚醒系統的子裝置系統可能無法透過「暫停至閒置狀態」功能喚醒系統。因此，Power Framework 必須知道子裝置可以從目前的電量等級喚醒系統啟動系統時

這個主機板可能會由電源讀取 (一次性設定) 啟動後的架構 (例如：中央熱行程點) 設定) 或者是主機板驅動程式庫提供給其他裝置的資訊驅動程式。駕駛人接著會處理資訊，然後設定存取 Power Framework 。

建立電源拓撲

Power Framework 應維護電源拓撲，以維持高效電力並做出適當的變更電源架構會或由元件管理員和驅動程式管理員進行設定收集元件本身

電源元件
支援的對應功率
依附於其他功率元件
轉換至各級別的延遲時間
喚醒能力
自行啟動的電源等級變更狀態

在驅動程式庫初始化期間，驅動程式和元件應進行通訊整合了 Power Framework 檔案。

此外，驅動程式和元件也可將此管道用於以及 Runtime Power Management。舉例來說，假設驅動程式庫或元件就會知道 BERT 元件目前並未使用要求變更電源。Power Framework 可以忽略或遵從根據系統狀態、依附元件和電源政策來處理要求。如果是想要回應該請求，可以利用管道並請求元素來換到特定電源等級。

定義及叫用每個驅動程式庫/元件的功率變化

電源架構會決定要將哪些子裝置轉換至較低規格電量 (由驅動程式庫回報的支援音量選擇)。電源架構將基於特定元素表示來自拓撲以外的政策，但一組代表一組電源依附規則電源架構會改用建立適當頻道駕駛/元件必須回報返回同一管道，直到嘗試轉移後的狀態。完成。

實作

暫停/恢復流程是 Fuchsia 眾多電源管理流程的第一步這項功能橫跨 Fuchsia 的多個構成元素 RFC 是整體設計。還要能提供進一步的 RFC 或設計文件當中涵蓋各單元的實作詳細資料。每個模組都有一組繫結不只如此，他們需要多方面改變才能完成整個導入作業

測試

這項功能涵蓋 Fuchsia 的多個構成元素。所有變更 Fuchsia 每個部分都應進行單元測試。模型的整合測試應能正常執行各模組的互動和流程，確保其他功能不會打破這個複雜的流程反之亦然驅動程式測試運作範圍可用於獨立測試驅動程式。耗時 (如準備就緒) 可用於建立及執行主機測試。任何新建立的介面應該都能成為合作夥伴的一員且應進行 CTF 測試來加以檢查。

需要其他文件

您必須製作下列設計文件，已順利完成導入程序

Power Framework Design 文件
Power-Aware 核心設計文件
電源感知驅動程式和元件文件
各網域的電源管理，例如音訊/圖像/連線能力 (選用)

缺點、替代方案和未知

本提案需要許多導入階段，並涵蓋所有模組例如核心、驅動程式、電源架構、驅動程式架構和元件架構並在各個階段中推出應用程式如要設計電源管理流程的基準，導入各種電源管理功能，讓 Fuchsia 成為針對電池供電產品的理想 OS。導入這個提案將橫跨四季放送

還有其他策略可暫停/恢復運作。如下所示：

使用現有的暫停流程暫停驅動程式和元件

這項策略無法提供完整的解決方案，並無法電池續航力。這項解決方案無法考量驅動程式/元件的各種電源依附性根據相依電源元素和處理方式，建立子裝置叢集以便根據其電源網域建立背景資料。這種設計由於缺乏程式設計執行階段喚醒等功能變更原始碼，並在使用者空間中公開子裝置資訊。
遵循在 Linux 中暫停/繼續的設計

這項策略只能確保 Fuchsia 等於 Linux。紫紅色必須在限制的情況下運作，例如 Linux 為單體式架構而非娛樂性的政策決定這項策略不允許就能充分發揮 Fuchsia 的優勢。Linux 電源管理大致上是排定特定回呼的順序執行 kubectl 指令相反地， Fuchsia 的因此，我們的電源管理支援必須更加分散

雖然這些策略或許能快速導入，但其中列出這些策略的缺點或不接受。

目前的設計是全新的，添加了許多對 Fuchsia 所做的變更。這項策略需要時間和心力，但確保我們以安全且可擴充的方式，在紫紅色。這確保電源管理流程不會溯及既往部署到作業系統上。

設計中的未知因素會在下一層的設計文件展開並提供解決措施

詞彙解釋

電源元素：電源元素是代表實體硬體副裝置 (包括電源軌和時鐘) 或組合將這些硬體元素歸入更高階的抽象層，例如音訊串流超音波，即相機子系統
功率：電源元件可能佔用不同電量。功率是一系列遵循下列限制的狀態：已建立索引除以非負整數等級 0 沒有電源等級依附元件」以及大部分的設為「關閉」state;排列順序提高用量上限(衡量功率的方法有很多種，目前意圖和需要先根據情境使用「一般」定義耗電量 suffices.)在最簡單的情況下，元素會有兩種可能其中 0 表示關閉，1 為開啟。ACPI D 狀態也可以對應至縮放程度，但順序反轉：D3cold=0、D3hot=1、D2=2 D1=3、D0=4。
喚醒觸發條件：系統處於低耗電模式 (暫停) 和 CPU 時離線，造成乾擾系統觸發的結果，就是從低電量啟動系統喚醒系統。。
副裝置：SoC 的一部分、週邊設備或有驅動程式庫系統匯流排。
系統電源層級/睡眠狀態：妥善定義的系統層級狀態，已知的喚醒延遲時間、約略耗電量。這與 ACPI S-State。
Wake 延遲時間：單一裝置或系統整個轉換所需的時間從低功率狀態到完全功能狀態。
恢復時間：系統從低電量電量充到耗電後可繼續執行的最長時間直到可以完全正常運作
OSPM：作業系統導向設定和電源管理
ACPI S0 狀態：完全啟用或完全啟用，且耗電量高。
ACPI S1 狀態 - S1 狀態定義為低喚醒延遲睡眠狀態。在此狀態中，除了 CPU 快取以外，所有系統內容都會保留。
單調時間 - 單調時間是系統測量到所經過的時間並且由核心維護。