PMBus系统的故障管理架构

作者：Michael Jones 凌力尔特科罗拉多设计中心的应用工程师

最近有些人问到关于运用内建故障管理与PMBus（电源管理总线）通讯技术这方面的事宜。这个问题可分为两个层面：运用PMBus对故障-关闭(fault-off)决策所产生的影响，以及该如何建构涵盖整个系统的故障纪录？在深入探究这两个PMBus的应用之前，我们先来看PMBus规格，以及PMBus制订者的意图。

PMBus规格涵盖了警示、故障、以及个别装置的反应；传递故障信息有两种方法，亦即警示响应地址(Alert Response Address，ARA)，以及主装置通知协议(Host Notify Protocol，HNP)。ARA一开始会透过发出ALERTB来中断机板控制器，而控制器则会利用PMBus地址查询，汇整出所有使用ALERTB的装置列表。

由装置启动HNP，之后它会成为一个主控PMBus，并把STATUS_WORD直接传送到机板控制器。在实务上，装置会先响应，之后再通知机板控制器。这种流程能保护装置与负载端，确保对故障事件最快做出反应，方法就是停止电源传送。

PMBus规格的内容

PMBus还有两方面的问题尚未解决：1. 装置之间的互动；2. 故障纪录。

这两个问题都刻意被搁置，因为PMBus委员会认为这些功能留给厂商自行研发解决更为适合。当然，发展这些功能有许多途径: 运用PMBus与机板控制器，或利用内建功能。这些大致上就是所询问内容需要的基础。以下开始解说。

第2页：解说PMBus尚未解决问题:1.装置之间的互动；2. 故障纪录。

第3页：好消息与坏消息

第4页：最终的结论

{pagination}

用机板控制器的参考设计方案建构一个原型系统，此系统采用多线程的RTOS实时操作系统(multi-threaded RTOS)。这个原型说不上是最佳的运算例子，但确实会产生实用的数据，在实务上甚至可能无法达到这样的结果。

在硬件方面，使用Freescale的Kinetis K60，搭配虚拟静态存取内存(PSRAM)以及铁磁体磁心内存(FRAM)。使用PSRAM是为了方便:我的系统已经装有硬盘机。使用FRAM是因为数据在写入交易的最后频率才会送出，不需要写入扇区(block)，而且老化失效前可写入得次数非常大。在PMBus装置上，我使用LTC3880、LTC2974、以及LTC2977。我在LTC3880的VOUT 0内置入一个电源负载，由它来产生一个故障事件。

遥测是在它自己的线程内运作，故障处理则在另一个线程，另外还有一些优先权限较低的运用程序线程。应用大致工作如下：

1. ALERT/在过电流发生时送出；

2. 透过ARA来获得地址；

3. 读取STATUS_WORD；

4. 做出Power off决定并执行；

5. STATUS_WORD 储存于 FRAM；

6. 输出电流从所有13个电源端读取；

7. 输出电流储存于 FRAM；

8. 设定retry 定时器；

9. 执行Retry。

这只是个近似模拟，因为若同时有多个电源端故障发生，就会有更多状态储存在FRAM。这种状况很常见，因为过电流会导致低压，而多个电源端间可能产生交互影响。

在I2C总线上进行遥测，所有13个电源端花费约40ms

上面的波形图撷取各项结果。我们可以看到在I2C总线上进行遥测，所有13个电源端花费约40ms，结果则储存在SD记忆卡，花费不到200ms的时间。但后面一个遥测则花费300ms。由此可见SD记忆卡适合用在遥测，但不适合用在故障纪录。其理由相当复杂，但只须记得SD记忆卡含有FAT文件系统，所以作业数包含读取目录结构等步骤。

在ALERT/接脚上可看到多个步骤，故障处理的总时间约为50ms。这个时间包含执行多个ARA、从多个电源端读取状态、收集一些输出电流读数、然后将数据储存到FRAM。故障事件会触发关闭程序，会花上超过400ms的时间。最后则是执行重试程序。

第3页：好消息与坏消息

第4页：最终的结论

{pagination}

进行到这里有好消息也有坏消息。好消息是在一个13个电源端的系统中，要把多个故障事件记录到日志，储存故障数据的程序得花50ms。这个数据很接近最糟状况的数值。一般的故障事件从收集一直到储存数据，只须不到10ms就能完成。若从重试开始仔细观察故障事件，可以看到多个FRAM传送，因为执行ARA的速度非常快。在这种状况中，系统仅须数毫秒的时间就需撷取到原始的故障事件。

现在来说说坏消息：关闭电源端得花费数百毫秒。没错，我知道这不是一般的真实系统，目的只是想让大家看看如果没有考虑到你的PMBus故障响应是如何设定的情况下，系统得花多长的时间来关闭电源。

未考虑PMBus故障响应所需的电源关闭时间

现在切换到立即关闭模式，注意到电源端关闭的速度变得多快。我们放大一点来看：

切换到立即关闭模式的电源关闭时间

切换到立即关闭后，系统须花2.5ms来关闭电源端。这个时间包含了读取状态缓存器、用遥测来分享总线、以及命令电源端关闭。因此，这个数值可能会有些变动，有时会较快，有时则会较慢。最好的可能状况是一个ARA之后读取状态，再接着一个全局关闭指令。使用的是一个读取byte(长度为3 byte)、读取状态字符(5个byte)、全局关闭(6个byte)。

在400kHz的频率速度下，时间为375us。不过这不包括任何驱动程序的消耗时间。注意，3个电源端会很慢地缓降，因为它们的负载只有数毫安。电源虽然很快就关闭，但还是需要一个负载才能压低到地电位，这则是另外一个问题。虽然这已经好得多，但是否还能做得更好？当然，如果装置有内建故障管理机制，还有改进的空间。我们来看看能做些什么。

内建故障管理机制的电源关闭时间

电源端在30us内关闭，并在不到100us内降至接地电位。这是负载很轻的电源端。如果我使用一个20安培的负载，那么关闭的速度就快上许多。如此短暂的延迟无须和其他替代方案评比──只是简单的比较。你的程序代码不一定得做这些，因为对内建故障回应没有影响。

第4页：最终的结论

{pagination}

那么最终的结论是什么？遥测方面使用PMBus，全系统故障日志确实有用。你可以搜集整个系统的数据，然后很快存入到非挥发性内存。除了大多数装置上内建故障日志功能，还能增加更多价值。

一般来说，内建日志对于故障事件的来源会记载更细部且更实用的信息。外部日志通常会有整个系统的时间戳信息。同时利用两种日志，成功诊断的机会就会大增。然而想要用一个串行端口来保护负载，并不是好的方法。对于一个400kHz的序列总线而言，理论上最好的作法来比内建解决方案速度慢上10倍。

我们以不同的角度来看问题。假设一个串行总线必须在30us内关闭电源端，那么它的频率得要多快？以一个14 byte的理想状况来说，等于112 bit。再预留一点时间给中断延迟与/或决策逻辑，则可推算出约4MHz。接着考虑若总线上同时有10个装置故障，会发生什么状况。将会需要40MHz。

接着再考虑一个100电源端的系统…在两种状况中，亦即负载保护与故障日志，PMBus的功能都足以做出回应。但在日志方面，最好的作法是在日志内建改良，在负载保护方面，最好是运用装置的功能来分享故障信息。而这也正是PMBus委员会想要达到的目的，就是建立一个共享的标准来解决问题，同时亦支持创新研发。