故障管理架构

我最近对使用 PMBus 通信来管理故障与内置故障管理进行了一些询问。问题是双重的：使用 PMBus 做出故障决策有什么影响，以及可以做些什么来构建系统范围的故障日志？

在我深入研究PMBus的这两种用途之前，让我们考虑一下PMBus规范中的内容以及PMBus创建者的意图。PMBus 规范包括各个设备的警告、故障和响应：

有两种方法可以传达故障信息：警报响应地址 （ARA） 和主机通知协议 （HNP）。ARA 从断言 ALERTB 开始中断电路板控制器，该控制器使用 PMBus 地址查询进行响应，以列出断言 ALERTB 的所有设备。HNP由设备启动，成为PMBus主站，并将STATUS_WORD直接发送到电路板控制器。实际上，设备首先响应，然后通知电路板控制器。这通过确保对故障的最快响应来保护设备和负载，主要是停止电力传输。

PMBus尚未解决另外两个关注领域：

设备之间的交互。

故障日志

这两个问题都被故意忽略了，因为PMBus委员会认为这些功能最好留给供应商创新。

当然，有不同的方法可以处理这些功能：使用 PMBus 和电路板控制器，或使用内置功能。这或多或少是调查的基础。

让我们开始吧...

我使用基于多线程 RTOS 的电路板控制器参考设计构建了一个原型。这给了我实际的结果，而不是在实践中可能无法实现的最佳情况计算。

对于硬件，我使用了带有伪静态Ram（PSRAM）和铁氧体Ram（FRAM）的飞思卡尔Kinetis K60。PSRAM是一个方便的问题：我已经有了驱动程序。使用FRAM是因为它具有数据由其写入事务的最后一个时钟提交的属性，它不需要在块中写入，并且磨损前的程序周期数非常大。对于 PMBus 器件，我使用了 LTC3880、LTC2974 和 LTC2977。我在 V 上放了一个当前的负载箱出0的 LTC3880 导致故障。

遥测在其自己的线程中运行，错误处理在另一个线程中运行，并且有一些实用程序线程的优先级较低。

该应用程序大致如下：

警报/从过电流断言

执行 ARA 以获取地址

读取STATUS_WORD

制定并执行断电决策

STATUS_WORD存储在 FRAM 中

从所有 13 个电源轨读取输出电流

输出电流存储在 FRAM 中

设置了重试计时器

执行重试

这是一个近似值，因为如果多个电源轨同时发生故障，则更多状态将存储在 FRAM 中。这是很常见的，因为过电流会导致欠压，并且电源轨可能会相互作用。

此范围捕获显示结果。您可以看到 I2C 总线上的遥测对所有 13 个电源轨大约需要 40 毫秒，结果在 200 毫秒内存储在 SD 卡上。但后来的遥测需要 300 毫秒。 （查看“存储到 SD 卡”） 这就是为什么 SD 卡适用于遥测但不适用于故障日志的原因。原因很复杂，但请记住，SD卡具有FAT文件系统，因此操作次数包括读取目录结构等。

您可以在 ALERT/ 引脚上看到多个断言，总故障处理时间约为 50 毫秒。此时需要执行多个 ARA，从多个电源轨读取状态，收集一些输出电流读数，并存储到 FRAM。该故障触发序列关闭，需要超过400ms。最终会重试。

有一些好消息和坏消息。好消息是，具有多个故障的13个轨道系统日志可以在50ms内存储故障数据。这接近最坏情况的数字。典型故障可以在不到 10 毫秒的时间内收集和存储数据。如果您仔细查看重试中的故障，您可以看到几个 FRAM 事务，因为执行 ARA 的速度非常快。在这种情况下，原始故障在几毫秒内被捕获。

但现在坏消息是：关闭轨道所需的时间是数百毫秒。好的，我知道，这不是真实系统的典型特征。我只是想让你看看，如果你不考虑你的PMBus故障响应是如何编码的，你关闭电源的速度有多慢。

通过切换到立即关闭，请注意电源轨关闭的速度有多快。让我们放大一点：

立即关闭时，需要 2.5 毫秒才能断电。时间是读取状态寄存器、与遥测共享总线以及脱离轨道命令的组合。因此，这个数字会四处移动，有时会很快，有时会很慢。最好的情况是 ARA 后跟状态读取，然后是全局关闭命令。即读取字节（3 个字节）、读取状态字（5 个字节）、全局关闭（6 个字节）。在 400kHz 时，即 375us。但这不包括任何驱动程序开销。注意：三个电源轨的斜坡下降非常慢，因为它们只有几毫安的负载。您可以快速杀死电源，但您需要负载将其拉到地面。但这是另一个话题。这要好得多，但我们能做得更好吗？当然：如果使用设备的内置故障管理。让我们看看这能做什么。

轨道在30us内关闭，在不到100us内下降到地面。这是一个非常轻载的轨道：小于1A。如果我使用 20A 负载，它会关闭得更快。这种短暂的延迟不必与其他活动竞争：它只是一个比较因素。您的代码可以随心所欲地执行，而不会影响此内置错误响应。那么有什么收获呢？使用 PMBus 进行遥测和系统范围的故障日志记录是有意义的。您可以收集系统范围的数据，并足够快地将其放入非易失性存储器中。这可以增加大多数设备中内置故障日志记录的价值。通常，内置日志将包含有关原始故障源的更多详细信息和更好的信息。外部记录器将具有有关整个系统的全局时间戳信息。使用这两个日志，您有最好的诊断机会。但是，使用串行总线保护负载不是一个好主意。400Khz串行总线的理论最佳情况比内置解决方案慢10倍。让我们换个角度看这个问题。假设串行总线必须在30uS内关闭电源轨，那么它的时钟必须有多快？使用 14 字节的理想情况，等于 112 位。为中断延迟和/或决策逻辑增加一点时间，约为 4Mhz。现在考虑一下如果总线上有 10 个设备同时出现故障会发生什么。这需要40Mhz。现在建立一个100铁路系统...在负载保护和故障记录这两种情况下，PMBus 在功能上都能够制定响应。但在日志的情况下，最好作为内置日志的增强，而在负载保护的情况下，最好利用设备共享故障信息的能力。这正是最初的PMBus委员会的意图。创建一个共享标准，解决常见问题，同时支持创新。

审核编辑：郭婷