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

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

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

PMBus尚未解決另外兩個關(guān)注領(lǐng)域：

設(shè)備之間的交互。

故障日志

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

當然，有不同的方法可以處理這些功能：使用 PMBus 和電路板控制器，或使用內(nèi)置功能。這或多或少是調(diào)查的基礎(chǔ)。

讓我們開始吧...

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

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

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

該應(yīng)用程序大致如下：

警報/從過電流斷言

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

讀取STATUS_WORD

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

STATUS_WORD存儲在 FRAM 中

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

輸出電流存儲在 FRAM 中

設(shè)置了重試計時器

執(zhí)行重試

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

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

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

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

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

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

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

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

審核編輯：郭婷