在現代伺服器與資料中心的架構中，儲存裝置的角色早已超越單純的資料讀寫。隨著雲端運算、AI 應用對「智慧化管理」的需求日益增加，SSD 如何與整個平台（BMC、BIOS、OS）進行高效、標準化的溝通，已成為驗證工程師面臨的關鍵挑戰。這其中，PLDM（Platform Level Data Model）協定扮演了核心角色，它不僅是韌體更新的基礎，更是實現平台級自動化管理的基石。
一、PLDM 是什麼？為何 SSD 驗證也要關心？
PLDM，全名為平台級數據模型（Platform Level Data Model），是由 DMTF（Distributed Management Task Force）組織制定的一系列標準化通訊協定 [1]。其核心目標是為平台內的各種智慧裝置（如 SSD、網路卡、記憶體）與管理控制器（如 BMC）之間，提供一個統一、高效且與傳輸層無關的資訊交換模式。
過去，PLDM 主要應用於伺服器主機板或由 BMC 團隊負責。然而，隨著資料中心對裝置可管理性、可維護性的要求越來越高，具備 NVMe-MI（NVMe Management Interface）與 MCTP（Management Component Transport Protocol）傳輸能力的智慧型 SSD 應運而生。這些裝置不再是被動的執行單元，而是需要主動回報狀態、接收管理指令的平台一份子。因此，支援 PLDM 已成為高階伺服器與頂級雲端客戶的明確需求。
核心觀念： 如果您正在驗證的 SSD 需要與 BMC 進行帶外（Out-of-Band）通訊以實現韌體更新、狀態監控或遠端管理，那麼 PLDM 將是您不可或缺的知識領域。
二、PLDM 完整架構：從 Redfish API 到實體線路
PLDM 的運作並非獨立存在，它是一個分層協定堆疊的一部分，每一層各司其職，共同實現了從高階管理 API 到低階硬體通訊的完整流程。一個典型的管理訊息流如下：
PLDM 協定層：功能明確的指令分類 (PLDM Types)
PLDM 根據管理功能定義了不同的「類別」（Types），每種類別包含一組相關的指令。在 SSD 驗證中，最核心的是：
• Type 0: Base：所有 PLDM 裝置都必須支援的基礎指令集，用於裝置探索、取得裝置資訊與管理響應。關鍵指令包含 `GetTID`（取得終端 ID）、`GetPLDMVersion`、`GetPLDMTypes`（查詢支援的類別）等 [2]。
• Type 5: Firmware Update：定義了完整的韌體更新流程，是目前 SSD 應用最廣泛、驗證最複雜的部分。它將韌體更新拆解為探索、請求、傳輸、驗證、套用、啟用等多個原子步驟，確保更新過程的穩定性與可恢復性 [3]。
• 其他重要類別：還包括 Type 2（平台監控與控制）、Type 4（FRU 資料）、Type 6（Redfish 裝置啟用）等，共同構成了完整的平台管理能力。
傳輸層：MCTP 與多樣化的實體介面
MCTP（Management Component Transport Protocol）是為 PLDM 提供底層通訊能力的傳輸層協定 [4]。它最大的特點是「傳輸層無關」，可以綁定到多種不同的實體介面（Physical Bindings）上，讓 PLDM 訊息得以在各種硬體環境中傳遞。以下介紹三種最常見的傳輸層技術：
SMBus/I2C 是最早期的實作方式，其速度相對較慢，通常在 100 kHz 到 1 MHz 之間。它採用開漏（Open-Drain）設計，需要上拉電阻，因此功耗較高。雖然實作簡單、成本低廉，但在現代高速應用中已逐漸被取代。主要應用於舊系統或對速度要求不高的低速裝置。
PCIe VDM（Vendor Defined Message） 是目前資料中心的主流選擇。它利用 PCIe 匯流排本身的高速通道來傳輸管理訊息，因此速度極快，且無需額外的實體線路。然而，它的缺點在於依賴 PCIe 匯流排的可用性，當 PCIe 進入低功耗狀態或關閉時便無法使用。此外，並非所有平台都支援 PCIe VDM 路徑，需要 PCIe Root Complex 與 BMC 的協作支援。
I3C（Improved Inter-Integrated Circuit） 是新一代標準，正迅速成為未來的主流。它在速度上達到 12.5 MHz（SDR 模式）甚至 25+ MHz（HDR 模式），比傳統 I2C 快了 10 到 25 倍。I3C 採用推挽（Push-Pull）設計，功耗極低，且支援動態電壓調整與低功耗模式。更重要的是，I3C 支援動態位址分配（DAA），這意味著裝置可以熱插拔，系統會自動分配位址，非常適合大規模 SSD 陣列的管理。此外，I3C 提供頻內中斷（In-Band Interrupt, IBI）功能，裝置可以主動通知 BMC 發生的事件，無需額外的中斷線路。最後，I3C 向下相容 I2C，可以在同一條匯流排上混合使用新舊裝置，大幅降低系統升級的複雜度。
憑藉這些優勢，I3C 正迅速成為下一代伺服器、AI 系統以及大規模 SSD 陣列管理的最佳選擇 [5]。
管理層：Redfish 的抽象與封裝
Redfish 是 DMTF 推出的新一代 RESTful API 管理標準，它將底層複雜的 PLDM 操作封裝成統一、易用的 HTTP/JSON 介面 [6]。管理員無需了解 PLDM 的指令細節，只需呼叫 Redfish 的 `UpdateService` API，即可觸發 BMC 在底層執行完整的 PLDM 韌體更新流程。
三、PLDM 驗證實戰：從工具到測試案例
PLDM 驗證涵蓋了從基礎連通性到複雜異常情境的完整測試，以下將介紹核心工具與關鍵測試案例。
驗證環境建置
一個典型的 PLDM 驗證環境需要以下元件：
• 硬體：一部搭載 OpenBMC 的主機或開發板、待測 SSD、以及對應的 I3C Fixture 或 PCIe 連接器。
• 軟體：包含 `pldmd`（PLDM 守護程式）與 `mctpd`（MCTP 守護程式）的 OpenBMC 映像檔，以及 `pldmtool` 指令列工具。
核心驗證工具：pldmtool
`pldmtool` 是 OpenBMC 專案中最重要的 PLDM 驗證工具，它允許工程師直接在 BMC 上發送 PLDM 指令並檢視回應 [7]。
常用指令範例：
PLDM 韌體更新 (Type 5) 驗證重點
韌體更新是 PLDM 驗證的重中之重，除了驗證正常流程外，更重要的是測試各種異常情境下的系統穩定性與恢復能力。
正常流程驗證：
確保 `RequestUpdate`、`PassComponentTable`、`UpdateComponent`、`TransferFirmwareData`、`VerifyComplete`、`ApplyComplete`、`ActivateFirmware` 等一系列指令能依序成功執行，並在裝置重啟後回報新的韌體版本。
關鍵異常測試案例：
• 傳輸中斷：在 `TransferFirmwareData` 過程中模擬網路中斷或 Host 異常，驗證裝置是否能正確回報錯誤狀態並中止更新。
• 資料驗證失敗：提供一個損壞或雜湊值不符的韌體映像檔，驗證裝置是否能在 `Verify` 階段拒絕更新。
• 啟用前斷電：在 `ActivateFirmware` 指令發出前模擬 BMC 或裝置意外斷電，驗證裝置重啟後是否仍保留舊版韌體，避免「變磚」。
• 版本不相容：嘗試刷入一個不相容（例如針對不同硬體）的韌體，驗證裝置的防呆機制。
Redfish API 整合驗證
在底層 PLDM 功能驗證完畢後，需進一步驗證上層 Redfish API 的整合。
# 使用 curl 透過 Redfish API 觸發 SSD 韌體更新
curl -k -X POST https://<BMC_IP>/redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate \
-H "Content-Type: application/json" \
-H "X-Auth-Token: <token>" \
-d '{
"ImageURI": "http://<server>/ssd_fw.img",
"Targets": ["/redfish/v1/Systems/1/Storage/NVMe1"]
}'
驗證重點在於 Redfish 服務是否能正確解析請求、將其轉換為底層的 PLDM 指令序列，並將執行結果以 Redfish Task 的形式回報給使用者。
四、驗證時常見問題與建議
在實務驗證中，您可能會遇到以下幾個典型問題：
• 問題：SSD 不回應任何 PLDM 指令
◦ 建議解法：首先，使用 `mctp link` 和 `i3cdetect` 等工具檢查實體層與傳輸層的連通性。其次，確認 SSD 的 NVMe-MI Handler 是否已正確掛載，以及 BMC 分配的 MCTP Endpoint ID 是否設定正確。最後，檢查 `pldmd` 的日誌，確認是否有訊息路由或權限問題。
• 問題：Firmware Update 流程在特定步驟卡住
◦ 建議解法：最常見於 `Apply Firmware` 階段。使用 `pldmtool fw_update GetStatus` 查詢裝置當前的狀態。檢查 Host 是否在韌體傳輸完成後正確呼叫了 `Apply` 相關指令，並確認裝置是否有足夠的時間與資源完成韌體燒錄。
• 問題：Redfish 無法觸發 SSD 韌體更新
◦ 建議解法：此類問題通常是跨層級的整合議題。需與平台 BIOS/BMC 團隊協調，確認 Redfish Schema 是否已正確對應到目標 SSD 的 PLDM 資源，以及相關的帶外管理功能是否已在平台層級啟用。
五、PLDM 驗證的未來趨勢
PLDM 及其相關技術生態系正快速演進，未來的驗證工作將面臨新的挑戰與機遇：
• Redfish + PLDM 成為標準：越來越多的企業級 SSD 將原生支援此架構，實現真正的遠端、無代理程式（Agentless）管理。
• I3C 全面普及：隨著 PCIe Gen6 與 AI 伺服器的發展，I3C 將憑藉其高效能與低功耗特性，取代 PCIe VDM 和 SMBus，成為主流的帶外管理匯流排。
• 安全性整合加深：SPDM（Security Protocol and Data Model）協定將與 PLDM 更緊密地整合，提供從裝置認證到訊息加密的端到端安全防護，這也將成為驗證的新重點。
• 跨團隊協作常態化：PLDM 驗證不再是單一團隊的工作，它需要韌體、硬體、BMC、BIOS 乃至上層應用軟體團隊的緊密協作，共同確保整個平台的穩定性。
六、總結：掌握 PLDM，站在 SSD 驗證的最前線
PLDM 驗證不僅僅是測試 SSD 韌體的一項功能，它更代表了您對整個「平台通訊架構」成熟度的深刻理解。當您能熟練地運用 `pldmtool` 進行底層除錯，透過 Redfish API 進行高階整合測試，並能從容應對跨團隊的協作挑戰時，無論是面對要求嚴苛的雲端客戶、參與 OCP（Open Compute Project）的下一代專案，或是投入最前沿的 AI 伺服器開發，您都將是團隊中不可或缺的關鍵工程師。
