我最近對使用 PMBus 通信來管理故障與內置故障管理進行了一些詢問。問題是雙重的：使用 PMBus 做出故障決策有什么影響，以及可以做些什么來構建系統(tǒng)范圍的故障日志？

在我深入研究PMBus的這兩種用途之前，讓我們考慮一下PMBus規(guī)范中的內容以及PMBus創(chuàng)建者的意圖。PMBus 規(guī)范包括各個設備的警告、故障和響應：

有兩種方法可以傳達故障信息：警報響應地址 （ARA） 和主機通知協(xié)議 （HNP）。ARA 從斷言 ALERTB 開始中斷電路板控制器，該控制器使用 PMBus 地址查詢進行響應，以列出斷言 ALERTB 的所有設備。HNP由設備啟動，成為PMBus主站，并將STATUS_WORD直接發(fā)送到電路板控制器。實際上，設備首先響應，然后通知電路板控制器。這通過確保對故障的最快響應來保護設備和負載，主要是停止電力傳輸。

PMBus尚未解決另外兩個關注領域：

設備之間的交互。

故障日志

這兩個問題都被故意忽略了，因為PMBus委員會認為這些功能最好留給供應商創(chuàng)新。

當然，有不同的方法可以處理這些功能：使用 PMBus 和電路板控制器，或使用內置功能。這或多或少是調查的基礎。

讓我們開始吧...

我使用基于多線程 RTOS 的電路板控制器參考設計構建了一個原型。這給了我實際的結果，而不是在實踐中可能無法實現(xiàn)的最佳情況計算。

對于硬件，我使用了帶有偽靜態(tài)Ram（PSRAM）和鐵氧體Ram（FRAM）的飛思卡爾Kinetis K60。PSRAM是一個方便的問題：我已經(jīng)有了驅動程序。使用FRAM是因為它具有數(shù)據(jù)由其寫入事務的最后一個時鐘提交的屬性，它不需要在塊中寫入，并且磨損前的程序周期數(shù)非常大。對于 PMBus 器件，我使用了 LTC3880、LTC2974 和 LTC2977。我在 V 上放了一個當前的負載箱出0的 LTC3880 導致故障。

遙測在其自己的線程中運行，錯誤處理在另一個線程中運行，并且有一些實用程序線程的優(yōu)先級較低。

該應用程序大致如下：

警報/從過電流斷言

執(zhí)行 ARA 以獲取地址

讀取STATUS_WORD

制定并執(zhí)行斷電決策

STATUS_WORD存儲在 FRAM 中

從所有 13 個電源軌讀取輸出電流

輸出電流存儲在 FRAM 中

設置了重試計時器

執(zhí)行重試

這是一個近似值，因為如果多個電源軌同時發(fā)生故障，則更多狀態(tài)將存儲在 FRAM 中。這是很常見的，因為過電流會導致欠壓，并且電源軌可能會相互作用。

此范圍捕獲顯示結果。您可以看到 I2C 總線上的遙測對所有 13 個電源軌大約需要 40 毫秒，結果在 200 毫秒內存儲在 SD 卡上。但后來的遙測需要 300 毫秒。 （查看“存儲到 SD 卡”） 這就是為什么 SD 卡適用于遙測但不適用于故障日志的原因。原因很復雜，但請記住，SD卡具有FAT文件系統(tǒng)，因此操作次數(shù)包括讀取目錄結構等。

您可以在 ALERT/ 引腳上看到多個斷言，總故障處理時間約為 50 毫秒。此時需要執(zhí)行多個 ARA，從多個電源軌讀取狀態(tài)，收集一些輸出電流讀數(shù)，并存儲到 FRAM。該故障觸發(fā)序列關閉，需要超過400ms。最終會重試。

有一些好消息和壞消息。好消息是，具有多個故障的13個軌道系統(tǒng)日志可以在50ms內存儲故障數(shù)據(jù)。這接近最壞情況的數(shù)字。典型故障可以在不到 10 毫秒的時間內收集和存儲數(shù)據(jù)。如果您仔細查看重試中的故障，您可以看到幾個 FRAM 事務，因為執(zhí)行 ARA 的速度非常快。在這種情況下，原始故障在幾毫秒內被捕獲。

但現(xiàn)在壞消息是：關閉軌道所需的時間是數(shù)百毫秒。好的，我知道，這不是真實系統(tǒng)的典型特征。我只是想讓你看看，如果你不考慮你的PMBus故障響應是如何編碼的，你關閉電源的速度有多慢。

通過切換到立即關閉，請注意電源軌關閉的速度有多快。讓我們放大一點：

立即關閉時，需要 2.5 毫秒才能斷電。時間是讀取狀態(tài)寄存器、與遙測共享總線以及脫離軌道命令的組合。因此，這個數(shù)字會四處移動，有時會很快，有時會很慢。最好的情況是 ARA 后跟狀態(tài)讀取，然后是全局關閉命令。即讀取字節(jié)（3 個字節(jié)）、讀取狀態(tài)字（5 個字節(jié)）、全局關閉（6 個字節(jié)）。在 400kHz 時，即 375us。但這不包括任何驅動程序開銷。注意：三個電源軌的斜坡下降非常慢，因為它們只有幾毫安的負載。您可以快速殺死電源，但您需要負載將其拉到地面。但這是另一個話題。這要好得多，但我們能做得更好嗎？當然：如果使用設備的內置故障管理。讓我們看看這能做什么。

軌道在30us內關閉，在不到100us內下降到地面。這是一個非常輕載的軌道：小于1A。如果我使用 20A 負載，它會關閉得更快。這種短暫的延遲不必與其他活動競爭：它只是一個比較因素。您的代碼可以隨心所欲地執(zhí)行，而不會影響此內置錯誤響應。那么有什么收獲呢？使用 PMBus 進行遙測和系統(tǒng)范圍的故障日志記錄是有意義的。您可以收集系統(tǒng)范圍的數(shù)據(jù)，并足夠快地將其放入非易失性存儲器中。這可以增加大多數(shù)設備中內置故障日志記錄的價值。通常，內置日志將包含有關原始故障源的更多詳細信息和更好的信息。外部記錄器將具有有關整個系統(tǒng)的全局時間戳信息。使用這兩個日志，您有最好的診斷機會。但是，使用串行總線保護負載不是一個好主意。400Khz串行總線的理論最佳情況比內置解決方案慢10倍。讓我們換個角度看這個問題。假設串行總線必須在30uS內關閉電源軌，那么它的時鐘必須有多快？使用 14 字節(jié)的理想情況，等于 112 位。為中斷延遲和/或決策邏輯增加一點時間，約為 4Mhz?，F(xiàn)在考慮一下如果總線上有 10 個設備同時出現(xiàn)故障會發(fā)生什么。這需要40Mhz?，F(xiàn)在建立一個100鐵路系統(tǒng)...在負載保護和故障記錄這兩種情況下，PMBus 在功能上都能夠制定響應。但在日志的情況下，最好作為內置日志的增強，而在負載保護的情況下，最好利用設備共享故障信息的能力。這正是最初的PMBus委員會的意圖。創(chuàng)建一個共享標準，解決常見問題，同時支持創(chuàng)新。

審核編輯：郭婷