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

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

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

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

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

故障日志

這兩個(gè)問題都被故意忽略了，因?yàn)镻MBus委員會(huì)認(rèn)為這些功能最好留給供應(yīng)商創(chuàng)新。

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

讓我們開始吧...

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

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

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

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

警報(bào)/從過電流斷言

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

讀取STATUS_WORD

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

STATUS_WORD存儲(chǔ)在 FRAM 中

從所有 13 個(gè)電源軌讀取輸出電流

輸出電流存儲(chǔ)在 FRAM 中

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

執(zhí)行重試

這是一個(gè)近似值，因?yàn)槿绻鄠€(gè)電源軌同時(shí)發(fā)生故障，則更多狀態(tài)將存儲(chǔ)在 FRAM 中。這是很常見的，因?yàn)檫^電流會(huì)導(dǎo)致欠壓，并且電源軌可能會(huì)相互作用。

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

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

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

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

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

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

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

審核編輯：郭婷