智能汽车功能安全方案：看门狗和平台健康管理

前言

近年来，由于汽车技术的进步和各种组件的整合，汽车系统变得越来越复杂。随着汽车新四化的变革，配备的功能和特性越来越多，让汽车不再是传统观念里的汽车，而更加像一个“消费电子产品”，甚至像是一个“电动玩具”。

但这种智能化、电子化的趋势在增加产品功能、满足更多用户需求的同时，也增加了汽车系统本身的复杂性。这种复杂性带来了系统可靠性、维护和故障排除等方面的挑战。消费者会希望汽车更加智能互通，就像我们的智能手机等其他消费电子一样新颖酷炫。但相信消费者同时也希望汽车依然保持安全至上的产品属性，不会像消费电子一样动不动死机、卡屏或者变砖。

这种复杂的用户需求，无疑是当下智能汽车发展的重要推动力。各大厂家的工程技术人员也开发出更加强大的监控、故障诊断、测试和维护策略，以确保这些复杂系统的最佳性能和可靠性。这也跟我们经常强调的功能安全所强关联。这次我们就来看看其中两个重要的方案：看门狗（Watchdog）和平台健康管理（Platform Health Management）。

看门狗

看门狗的英语一般会说Watchdog Timer，虽然中文里往往省略了Timer的翻译，但是看门狗本质上是一个计时器机制。

抽象地来看，看门狗就是一个系统的守护狗，它会一直监控着它的“主人”，确保“主人”不会思想跑飞。怎么监控呢？它会期待“主人”（按照定时器）定期地给它喂食，如果按时投喂，则一切如常。如果超时了还没有被投喂，那看门狗可能会先吠叫几声，如果吠叫完还没有反应，那可能看门狗还会极端地去“咬”醒主人。

用工程语言再来描述的话，看门狗就是系统中的一个组件，用于监控其他组件的运行是否可能出现故障。当检测到可能的故障时，看门狗定时器系统会发出信号或启动适当的跳转指令，并根据当时的问题进行调整。信号或跳转指令可直接或间接触发其他合作的系统组件，从而解决问题。特别是在微控制器控制的设备中，经常可以看到看门狗的身影。这些看门狗定时器往往用来防止系统因软件故障而失效，看门狗会在固定的时间间隔内告知系统是否仍在正常工作。

那这个机制具体可以怎么实现呢？我们来看看下图的例子。

图：外置看门狗的实现原理示意图

图左方是TPS3850芯片和MCU芯片的电路连接原理图。TPS3850可以监控电压和提供看门狗功能，这里我们只关注看门狗功能，对应“WDI”和“WDO”端口，也就是看门狗的输入和输出端口。上图右方就是这两个端口的信号示意图。当MCU按照正常周期输出高电平脉冲给WDI端口时，WDO端口就会稳定输出高电平。但WDI超前或者延后输出高电平脉冲时，就会触发WDO输出低电平，触发MCU上的中断。该中断可以在MCU上触发复位等操作。

当然，这个只是其中一种实现看门狗机制的例子。实际上我们可以通过不同的软硬件来实现这个机制。比如我们可以做一个纯软件的计时器，来实现看门狗的功能，也可以用纯硬件来实现这个功能。当然，软硬件结合后，再细分不同的监控对象，用不同的方式喂狗，就可以丰富监控和响应效果。比如某些程序喂狗失败就会重启应用或者功能降级，关键程序喂狗失败就会直接重启系统等。

而按照是否采用外部的独立看门狗芯片来区分，我们又常常会分为“内狗”和“外狗”。在汽车行业实际应用中，我们往往会同时采用多种类型的看门狗，比如同时采用内狗和外狗，来让系统更加高效的同时更加鲁棒。比如常见的英飞凌AURIX芯片，就针对每个CPU都有一个内置的看门狗，对整个AURIX芯片系统也有一个看门狗。这些都是内狗。同时，MCU也会往往由一个外部看门狗芯片（也常集成在电源管理芯片中）来监控MCU的状态。

图：外狗、内狗示意图

平台健康管理

平台健康管理（Platform Health Management）则是AUTOSAR Adaptive Platform（AP）中一个重要的功能集群。它与执行管理（Execution Management）和状态管理（State Management）共同协作，是AP中的功能安全基石。

在监控内容方面，PHM可以对监控实体的存活（Alive Supervision）、逻辑性（Logical Supervision）和死线（Deadline Supervision）进行监控。

存活监控可检查受监控实体的运行频率是否过高或者过低。

死线监控可检查受监控实体中的步骤是否在Manifest中配置的最短和最长时间内执行。

逻辑监控可以检查执行过程中的控制流是否与设计的控制流相匹配。

这三种类型的监控可以独立使用，并基于被监控实体的检查点报告执行。

在操作系统拉起AP平台后，EM和SM就负责维护整个AP平台的进程、线程管理了，包括启动、终止和状态切换等。除了可以用来监控AP平台上的其他应用程序以外，PHM的一个关键任务就是监控EM和SM本身的状态。由于EM和SM是AP平台的关键基础特性，在任何正常的系统状态下，这两个功能集群都应该运行。当PHM监控到EM和SM出现异常时，PHM就需要重启整个机器（也就是重启操作系统）了，因为此时常规的系统状态切换和操作已经不可靠了。

图6：PHM从EM、SM接口获取信息的示意图

看门狗与平台健康管理的协同

看到这里，相信聪明的你也开始把看门狗和PHM两者联系起来了。没错，当PHM监控到EM和SM异常时，就需要对看门狗进行相应操作以恢复系统。如上图左方所示，PHM和看门狗接口（Watchdog Interface）模块的交互接口主要有两个:

lAliveNotification：PHM会根据配置，周期性地调用该接口，通知看门狗接口模块，PHM还正常工作着。

lFireWatchdogReaction：某些情况下，PHM监控到关键进程失效，比如EM和SM，PHM可以通过该接口触发看门狗接口模块，驱动硬件看门狗进行复位操作。

说到这里，我们就不得不重新提到整个Adaptive Platform和Classic Platform的最大差别：AP本质上是中间件，不包含操作系统和底层驱动，而CP是包含底层驱动和操作系统的。在这个背景下，AP平台设计的PHM，其监控对象就是AP中间件及Adaptive Application （AA）。而PHM的故障响应策略也不是直接驱动硬件底层进行看门狗操作，而是留了接口，由外部的看门狗接口模块（不属于AP中间件）来去实现看门狗驱动和硬件看门狗的操作执行。

这与实际工程中AP和CP的应用环境也是一致对应的。CP通常跑在高度嵌入式的MCU中。MCU上一般也有芯片内部的硬件看门狗逻辑模块。按照芯片开发CP软件的时候，就能适配好内置看门狗驱动。而AP经常跑在复杂异构的SOC上，这些SOC往往并没有内置硬件看门狗。

写在最后

总的来说，PHM和看门狗关系密切，是保障智能汽车这个复杂系统能够可靠安全地运行的关键手段。PHM监控应用程序和关键中间件平台，主动维护系统健康。而看门狗则是持续守护系统的基石，在系统异常时，能够充当守门员作为最后一关，触发系统重启等安全操作。PHM和看门狗的协同，在日益复杂智能的汽车系统中，既能提高系统总体效率，又能确保系统安全和可靠。在汽车消费者越来越把汽车当作“消费电子”的时代，我们从业者更应该时刻警惕：汽车终究是一个交通工具，汽车安全性是重中之重，不可或缺。

而作为汽车工程师，我们亦可紧跟趋势，在使用AUTOSAR等架构减少重复开发的同时，专注于关键设计，例如AP平台之上PHM需要监控哪些实体，在故障发生时配置哪些响应行为等。希望大家能利用好PHM和看门狗的工具箱，共同设计出既智能好玩又安全的汽车产品。

审核编辑：汤梓红