1. 先確認資料的來源與範圍

每個 controller 依 NPSS 提供 PS0 到 PSn；NPSS 採 zero-based 編碼，例如 4 代表 5 個狀態。

先確認 Power Management 適用於此 controller，再查 NPSS 與各筆 PSD。對不支援此功能的 controller，Host 應忽略 PSD。

2. 欄位、單位與判讀例子

NOPS 區分工作與非工作狀態；MP 配合功率尺度，ENLAT／EXLAT 以微秒描述進出延遲。RRT、RRL、RWT、RWL 是相對效能排序；IDLP、ACTP 各有尺度與量測條件，MBW 配合 MBWS 表示宣告的最高頻寬。

先比較 NOPS 與最大功率，再比較進出延遲，最後以相同種類的相對效能欄位排序。不同欄位的數字不能交叉比較。

Identify 成功後，Host 能挑出合適狀態；真正設定仍須透過 Power Management 或 APST。

3. 判讀時要保留的條件

超出 NPSS 的狀態不是合法選項；設定非法 Power State 時應回報 Invalid Field in Command。未宣告的量測值也不能解讀成零功耗或零延遲保證。

把 PSD 的 NOPS、功率尺度與 Feature 選中的狀態一起核對；不要把相對排名當作實際 IOPS。

1. 差別在哪裡

NOPS=0 為工作狀態；NOPS=1 為非工作狀態。非工作狀態仍可能處理 Register、Admin 命令與允許的背景工作。

APST 可自動進入非工作狀態；NOPPME 控制非工作狀態中的背景工作政策，不能當成禁止所有 Admin 存取的開關。

2. 如何選擇與確認

查 PSD.NOPS、目前 Power Management 設定與 Non-Operational Power State Config。

進入非工作狀態後若需處理 I/O，controller 自動回到最近的工作狀態，再處理 I/O；這項恢復不以 APST 是否啟用為前提。

I/O 能在恢復工作狀態後完成；Host 不需先用 Set Features 喚醒每一筆 I/O。

3. 比較時要保留的條件

不能因合法 I/O 到達非工作狀態就直接判定命令非法；若指定不存在的 Power State，才是設定參數問題。

看到非工作狀態期間仍有 Admin 活動或暫時較高功耗，不足以單獨判定違規；須核對允許的操作與功率上限。

1. 先確認資料的來源與範圍

ENLAT 描述進入目標狀態，EXLAT 描述離開原狀態；切換路徑涉及多個狀態時，不能只取其中最小值。

讀取原狀態與目標狀態的 PSD；非工作狀態恢復 I/O 時也需知道最近的工作狀態。

2. 欄位、單位與判讀例子

以微秒為單位計算原狀態 EXLAT 加目標狀態 ENLAT。ITPT 則是進入轉換之前的閒置等待時間，單位是毫秒。

先確認切換開始時間與路徑，量測恢復可處理命令的時間，再另計命令執行與 Host 排程延遲。

例如假設 PS3.EXLAT=2000 μs、PS0.ENLAT=500 μs，這段轉換的宣告上限為 2500 μs；不能要求完整 Read 也一定在 2500 μs 內完成。

3. 判讀時要保留的條件

Host 量到較慢的 CQE 不會直接產生一個「Exit Latency Error」Status；必須先證明超時發生在受規範限制的轉換階段。

CQE

Completion Queue Entry，佇列中的完成項目

比對 PSD、實際原始狀態、APST 路徑與量測邊界，而不是只比 Read 總延遲。

1. 操作前先準備什麼

每個來源 Power State 有一筆 8-byte entry；整份資料有 32 筆，共 256 bytes。

確認 Identify.APSTA 與 NPSS，並核對目標 PSD.NOPS。

FID0Ch 的 APSTE 啟用整體功能；entry.ITPT 指定閒置毫秒數，ITPS 指定目標。ITPT=0 停用該來源狀態的自動轉換。

2. 先後順序與完成條件

3. 未符合條件時如何處理

ITPT 非零時，ITPS 必須是非工作狀態；指定工作狀態應以 Invalid Field in Command 中止。停用整體功能使用 APSTE=0。

Get 回傳的是設定表，不是每次切換的歷史。若背景工作阻止進入較低功耗狀態，還要核對背景功耗與政策。

1. 先保留哪些證據

先限定一個 controller、一條已知狀態路徑與一次喚醒。

保存 PSD、APST、Power Management、溫度與目前背景操作。

使用原狀態 EXLAT 與目標 ENLAT；若測的是 RTD3，則是另一套供電恢復與初始化條件，不能沿用 NOPS 退出公式。

2. 依什麼順序排除原因

先確認延遲起點是否真的代表 controller 開始離開該 Power State。

先排除命令尚未提交、Host 排程、中斷合併及媒體執行時間，再定位真正的轉換區間。

3. 把觀察結果接回規格條件

在前提一致下，量測可支持「轉換符合／超過宣告」；前提不明時，只能說端到端延遲較高。

EXLAT 超出不是要求 controller 回傳某個固定 CQE 的命令參數錯誤。

CQE

Completion Queue Entry，佇列中的完成項目

用重複的受控量測核對宣告上限，保留時間解析度與量測誤差，不用單次應用程式時間直接定罪。

1. 操作前先準備什麼

以 Composite Temperature 作判斷，作用於目標 controller 的熱管理。

查 Identify.HCTMA、MNTMT、MXTMT；不是所有 controller 都支援 Host 控制熱管理。

FID10h 的 CDW11[31:16] 為 TMT1，[15:0] 為 TMT2，單位都是 Kelvin；0 停用對應部分。

2. 先後順序與完成條件

將非零門檻設在宣告範圍；兩者皆非零時必須 TMT1<TMT2。Set 成功後 Get 確認，不要直接填攝氏數字。

假設允許 300～360 K，設定 330 K 與 340 K 合法；設定 340 K 與 330 K 則顛倒輕重門檻。

3. 未符合條件時如何處理

非零門檻超出範圍，或兩個啟用門檻不符合先後關係，須回 Invalid Field in Command。

Get 的門檻、SMART 溫度與熱管理累計應一起看；溫度警告 FID04h 另有自己的設定。

1. 機制與適用範圍

判斷使用 Composite Temperature，而不是任選一個實體 sensor。

TMT1 啟用且溫度達 TMT1、未達啟用的 TMT2 時，controller 應開始較輕措施；達啟用的 TMT2 時，必須採取措施而不受效能影響限制。

2. 用操作與結果理解

先確認 HCTM 已啟用的門檻，以及 SMART 的 CTEMP、TMT1TC、TMT2TC 與累計秒數。

追蹤升溫跨越門檻及降溫恢復的過程。恢復溫度有廠商定義的遲滯，不能要求溫度一低於 TMT2 就立即完全恢復。

可觀察到功率或效能調整，且對應 transition count／time 有一致紀錄；實際措施可由廠商決定。

3. 容易誤判的地方

低於 TMT2 後仍降速，不足以直接判定錯誤；先核對 TMT1、遲滯及其他熱保護來源。

把 should 與 shall 分開檢查，不把輕度門檻的建議要求提高成重度門檻的強制要求。

1. 先界定觸發方式與影響對象

逐一檢查 Power Management、APST、HCTM 與 NOPS Config，不能將它們當成一個 Feature。

Get Features SEL=3 查保存能力，SEL=0／1／2 分別觀察 Current、Default、Saved；另查 Feature scope。

2. 哪些狀態改變，恢復後怎麼處理

SV=1 的成功 Set 更新 Saved；SV=0 只改 Current。不可保存的 Feature 依明定的持續性恢復。

重設前保存四種查詢結果，重設後先恢復 Admin Queue，再重新 Get，最後檢查狀態轉換是否符合恢復後的設定。

Current 應等於該範圍與重設條件所要求的恢復值；不是一定等於重設前最後一次 SV=0 的值。

3. 如何驗證保留或恢復結果

不支援 Save 卻要求 SV=1 時，應使用對應 Feature Not Saveable 等明定錯誤；不能把失敗 Set 當成已保存。

SMART 溫度與累計計數不因 Feature 回到 Default 就必須歸零。

先檢查最後一次 Set 的 SV、實際 CQE，以及重設是否涵蓋全部共用範圍。

1. 先確認資料的來源與範圍

每個 bit 獨立，可同時成立；讀取時的狀態可能與先前 AER 產生時不同。

讀 SMART LID02h，並核對 AEC 的 SHCW 啟用遮罩與相關硬體能力。

2. 欄位、單位與判讀例子

bit0 備用容量低於門檻；bit1 溫度達上限或下限；bit2 可靠性降低；bit3 全部媒體唯讀；bit4 揮發記憶體備援失敗；bit5 PMR 唯讀或不可靠；bit6 personality 設定處於未定狀態。bit7 保留。

PMR

Persistent Memory Region，持久性記憶體區域

先找出設為 1 的 bits，再讀對應欄位與事件資訊。例如 bit1 必須核對上、下溫度門檻，不能一律翻成過熱。

成功讀取回傳目前狀態；多個 bits 為 1 不代表 Log 格式錯誤。

3. 判讀時要保留的條件

Namespace Write Protection 造成的唯讀不得設定 AMRO；備援不存在時，也不能把無效 VMBF 當作故障證據。

用警告類型、相應數值及 AER 發生時間互相核對，而不是要求稍後讀到的 CW 永遠等於事件當時。

1. 先確認資料的來源與範圍

SMART 描述所定義的整體健康範圍；它不是 namespace 的剩餘檔案空間。

讀 AVSP、AVSPT、PUSED 及 CW.ASCBT；需要分組健康時另查 Endurance Group Log。

2. 欄位、單位與判讀例子

AVSP 與 AVSPT 為 0～100%；AVSP<AVSPT 才是低於門檻。PUSED 是廠商估算，100 不代表當下必然故障，且允許超過 100；大於 254 表示為 255。

例如 AVSP=8、AVSPT=10 表示已低於門檻；PUSED=105 則表示估計耐用額度已用超過，兩者可以同時存在。

成功讀取取得估計值；PUSED 在非睡眠期間每個 power-on hour 更新一次，不要求每次 Write 立即改變。

3. 判讀時要保留的條件

不能因 PUSED>100 判為非法欄位，也不能因 AVSP=AVSPT 就要求「低於」警告。

交叉比較警告與 AVSP，而不要用 PUSED 直接推算剩餘 spare。

1. 先確認資料的來源與範圍

計數涵蓋 SMART 定義的範圍；多條 queue 的重疊工作時間不能直接相加成 Busy Time。

讀 DUR、DUW、HRC、HWC、CBT、PWR_CYC 與 POH，並保留快照時間。

2. 欄位、單位與判讀例子

Data Units 以 1000 個 512-byte units 為單位並向上取整，0 表示未回報。Busy Time 以分鐘計，從 I/O 提交 Doorbell 到 CQE 寫入之間有未完成 I/O 即可能計入；不是等 Host 消費 CQE 才結束。

以兩次快照算差，再依單位轉換。Host Read／Write Commands 依命令集定義的已完成命令類別累計；POH 可不含非工作狀態的時間。

例如資料量欄增加 2，只支持增加約 2×512000 bytes 的量化刻度；短小操作可能因取整而未立即增加。

3. 判讀時要保留的條件

不能用應用程式 I/O 次數要求 Host Command 計數完全相等，因為合併、重試與命令類型可能不同。

核對 controller 真正完成的命令與計數單位，而不是只比檔案大小或壁鐘時間。

1. 先確認資料的來源與範圍

它們是生命週期累計，不是目前 Log 裡仍保留多少筆紀錄。

讀 UPL、MDIE、NEILE，並保存失電前 CSTS.SHST 與是否因 OOB 管理而繼續存取媒體。

2. 欄位、單位與判讀例子

Base 2.4 將舊稱 Unsafe Shutdowns 的欄位稱為 Unexpected Power Losses。主電源失去時，SHST 不是 10b，或媒體因適用的 OOB Ignore Shutdown 操作尚未關閉，才符合規定的累計條件。

先辨認是否真的失去主電源，再判斷當時狀態；另外以未恢復的完整性錯誤核對 MDIE，以實際新增 Error entry 核對 NEILE。

Reset 而未失電不增加 UPL；完成 Abrupt Shutdown 且符合可斷電狀態後失電，也不能只因「Abrupt」就要求增加。

3. 判讀時要保留的條件

一次命令失敗不必然同時增加 MDIE 與 NEILE。Write Uncorrectable 引入的錯誤是否計入 MDIE，規範允許實作選擇。

Error entries 被覆寫或重設後建議清除，不會讓生命週期 NEILE 倒退。

1. 先確認資料的來源與範圍

在工作狀態中，依 Composite Temperature 與 WCTEMP、CCTEMP 判斷，單位為分鐘。

讀 Identify.WCTEMP、CCTEMP 與 SMART 的 WCTT、CCTT，並確認適用的溫度遲滯設定。

2. 欄位、單位與判讀例子

WCTT 對應 WCTEMP≤溫度<CCTEMP 的警告區間；CCTT 對應溫度≥CCTEMP。門檻未實作的零值有指定的零回報規則。

按時間序列確認每段工作狀態及溫度區間，再累計；不要把取樣到一次高溫直接算成一整分鐘。

假設持續 2 分鐘處於危急區間，應檢查 CCTT 的變化；不能同時要求這 2 分鐘全部加進警告區間。

3. 判讀時要保留的條件

WCTEMP 或 CCTEMP 為 0 時，WCTT 為 0；CCTEMP 為 0 時，CCTT 為 0。零值不能一律解釋為裝置從未過熱。

另把 HCTM 的累計秒數分開比較，因為門檻、單位與事件意義都不同。

1. 先確認資料的來源與範圍

sensor 位置與 Composite 的計算方式由實作定義；跨產品比較前需知道量測意義。

讀 SMART.CTEMP 與 TSEN1～TSEN8，再查看裝置提供的 sensor 對應說明。

2. 欄位、單位與判讀例子

數值以 Kelvin 表示；TSEN=0 表示未實作，不能當成 0 K 的有效溫度。

先排除未實作欄位，再轉換成需要的單位；例如 300 K 約為 26.85°C。警告門檻要搭配它所選的 sensor。

Get Log 成功可回傳彼此不同的溫度，差異本身不代表資料損壞。

3. 判讀時要保留的條件

不能要求所有 TSEN 都非零，也不能因 Composite 不等於平均值就判定違規。

把警告、門檻所選 sensor 與該 sensor 的數值一起比對。

1. 事件何時成立、由誰觀察

SMART／Health 事件報告規範定義的警告，不是每次溫度或計數變動都發通知。

查 AEC.SHCW、SMART.CW、待處理 AER 數量，以及相關溫度或 spare 門檻。

事件類型與資訊指向相應健康條件，LID 通常指向 SMART；Host 依實際 AER 回覆的 LID 讀取資料。

LID

Log Page Identifier，紀錄頁識別碼

2. 通知、讀取與確認的關係

先掛入 AER，再啟用需要的通知；事件發生後保存 CQE，讀對應 Log 並依 RAE 完成確認，再補送 AER。

符合通知條件且有可完成的 AER 時，Host 能取得事件；稍後 CW 已恢復不代表先前通知錯誤。

3. 沒有通知或紀錄時怎麼判斷

沒有 AER Completion 時，不能直接判定韌體漏報；未啟用、已遮蔽或尚無可用 request 都要先查。

以事件當時設定與條件核對，不只看事後單一 SMART 快照。

先確認 SHCW 對應 bit 已啟用，且前一次同類事件已按規定確認。

4. Asynchronous Event 的通知條件

本題討論的就是 SMART／Health AER；事件條件、SHCW、遮蔽狀態及 outstanding request 必須一起判斷。普通計數增加不要求另外發送事件。

1. 要查哪個對象、哪份資料

Base 2.4 的 SMART／Health Log 不提供 namespace-specific 資訊；接受不同 NSID 不表示資料因此成為該 namespace 專屬。

NSID

Namespace Identifier，邏輯儲存空間識別碼

查本版 SMART 定義與 Get Log Page 的選擇規則；需要 Endurance Group 資料時改查相應 Log。

Get Log Page 的 NSID 與 LID 仍須正確填寫，但每個回傳欄位的實際範圍由定義決定。

NSID

Namespace Identifier，邏輯儲存空間識別碼

2. 查詢順序與回覆判讀

先記錄查詢的 controller 與 NSID，再比較回覆。對不同 NSID 回傳相同 SMART 資料，是本版定義允許且要求理解的行為。

成功讀取取得整體資訊，不能據此分攤哪個 namespace 消耗多少壽命。

3. 證據不足或不一致時怎麼判斷

不能沿用舊版 namespace-specific SMART 的理解，要求每個 namespace 有不同計數。

把 Identify 版本、Log 定義與實際回覆一起核對，避免只憑舊工具標籤判斷。

先檢查是否把合法 NSID 的接受能力誤當成 per-namespace 計數能力。

1. 先保留哪些證據

先固定 controller、操作時間區間與各資料的 scope；不同時間或不同物件不能直接相減。

保存支援能力、SMART 前後快照、CQE、Error entries 與可用的 PEL context。

用 SQID／CID 對回命令，以 Error Count 區分紀錄，以 PEL Event Type 與事件資料確認操作；SMART 則依單位與累計條件解讀。

SQID

Submission Queue Identifier，提交佇列識別碼

CID

Command Identifier，同一提交佇列內的命令識別碼

2. 依什麼順序排除原因

先檢查每個被期待改變的欄位，是否真的由這個操作觸發。

先預測這個操作應改變哪些資料，再執行一次可隔離的情境，最後比較每一條預期關係。

3. 把觀察結果接回規格條件

例如一次正常讀取可增加 Read Commands 與資料量，卻不要求新增 Error entry 或 PEL 命令紀錄。

缺少非必要紀錄不能算違規；若 More=1 卻找不到補充資訊，則須進一步檢查覆寫、讀取時序與記錄規則。

結論分成「規範要求已滿足」、「明確不符」與「證據不足」，不要把無法觀察寫成已證明失敗。