知从木牛功能安全SBC系列软件旨在打造知从科技自主研发的满足客户功能安全要求的System Basis Chip（SBC）平台化软件产品，适配不同厂家的SBC芯片。本手册说明了基于恩智浦FS26系列SBC实现的功能安全应用方案、软件架构等内容。本软件产品可帮助系统工程师和软件工程师能够快速地应用到客户产品中，满足功能安全需求。

NXP FS26是一款集成了多个开关式稳压器（Switchers）、线性稳压器（LDOs）、高边驱动（HSDs）、低边驱动（LSDs）以及完整安全功能的车规级电源管理芯片。其设计符合ISO 26262 ASIL D等级标准，是面向下一代汽车域控制器、ADAS、网关等关键应用的理想选择。

本产品实现了的FS26芯片软件驱动功能包含：

•      多路电源输出管理；

•      SBC状态机控制、低功耗控制与唤醒管理；

•      输出电压诊断管理；

•      MCU与SBC的SPI通信处理；

•      SBC片内ABIST/LBIST自检管理；

•      看门狗管理；

•      MCU错误监控管理；

•      SBC片外安全关断路径处理。

看门狗协议栈介绍

在汽车电子系统中，功能安全（Functional Safety）的核心目标是通过系统化的设计和安全机制，防止因电子电气系统故障导致的人身伤害或财产损失。WdgM（Watchdog Manager） 作为 AUTOSAR 标准中的关键安全模块，其设计严格遵循 ISO 26262 标准，并通过多层次的监控、容错和恢复机制来满足不同 ASIL（Automotive Safety Integrity Level）等级的要求。

WdgM 里面主要部分是 Supervised Entity(SE) 和 CheckPoint(CP) 。

l  SE ：每一个 SE 可以有 Alive 、 deadline 、 Logical 三种形式的监督方式【 Logical Supervision 分为两种，同一个 SE 内部的程序流监督、不同 SE 内部的程序流监督】。一个 SE 可以是一个算法、一个函数、一个任务。

l  Check Point ：用于作为区分不同的监控方式，可以属于下面的一种或多种监控方式的类型

1.1    周期监控

程序流监控：外部看门狗实现WdgM模块的Alive Supervision监控机制，用于监控周期性的Task；WdgM模块通过计算程序运行时检查点出现的个数，然后与期望值(配置信息)进行比较，如果超出容差范围，即视为违反程序流程, WdgM模块将会记录为检查点故障。

以AEB模块Task的Alive Supervision举例：

图3：Alive监控示例

WdgM的调用周期为20ms，AEB模块Task的周期为25ms，如图6.21所示, 配置监控周期为100ms，即：在5个WdgM_MainFunction区间，CheckPoint到达数量为3-5个为正常。 如果发生的次数不在3-5之间 ,WdgM模块将认为检测到AEB模块Task的周期异常，同时通过图6.20所示的喂狗数据流传输不喂狗请求给PMIC模块，PMIC模块停止喂狗, 等待看门狗喂狗超时（超时时间64ms*3）后，触发复位。

1.2     截止时间监控

Deadline Supervision需要关注某段程序运行的时间，过长或过短都说明程序执行异常。抽象为监控两个 Check Point 之间运行的时间 。 具体算法如下 ：在 WdgM 中配置Deadline Supervision的起始 Check Point、结束 Check Point、最小时间门限和最大时间门限 。 在运行到起始 Check Point 时启动Deadline Supervision， 获取系统时间， 在运行到结束 Check Point 时， 获取系统时间， 计算运行时间是否配置合理范围内。

注意 ： 两个CP属于相同的SE，两个CP不能相同 。

1.3     逻辑监控

Logical Supervision主要用于监控应用程序的运行顺序是否正确，包括各个 SE 本地的运行路径的检查，和 SE 之间的全局路径检查。

比如程序按照： 1 -> 2 -> 3 -> 4 的顺序运行。程序在运行至 1 时，检查是否为第一个应该运行到的点，运行至 2 时则检查前一个到达的 check point 点是否为 1 。依次检查相邻两个点之间的实际运行顺序与配置之间的运行顺序是否匹配。当程序以 1 -> 2 -> 4 的顺序运行时，在运行至 4 处会检查到程序出错，更改 Logical Supervison 的 SE 状态。

图4：WdgM监控概述

2      知从木牛介绍

知从木牛配置工具基于最新ARTOP架构，支持最新AUTOSAR R21-11标准所提供的基础平台上，根据AUTOSAR开发方法中定义的ECU配置步骤，实现了从配置、验证到代码生成的ECU配置全流程的功能。主要优势可以总结为以下几个方面：配置、验证和代码生成全流程功能的实现，完整的实现了AUTOSAR开发方法中ECU配置阶段的开发要求。

下面将简单介绍一下使用ZC.MuNiu进行WdgM模块配置的过程：

2.1     WdgM配置简介

2.1.1  添加SE监控实例

通过在WdgMMode界面可以添加Alive监控相关的监控实例。

图5: 木牛Supervision Entities配置界面示例1

2.1.2  配置SE打卡点

在对应的监控实例配置页面下可以添加多个SE打卡点。

图6: 木牛Checkpoints配置界面示例

另外，在WdgMInternalTransition页面中可以设置打卡点的执行顺序，以此来实现逻辑监控功能。

图7: 木牛Internal Transaction配置界面示例

2.1.3  添加监控实例的状态参数配置

在WdgMAliveSupervision0页面下，可以配置Alive监控需要的相关参数，例如监控周期、可容忍的打卡次数限制、监控目标等等。

图8: 木牛Alive Supervison配置界面示例

2.1.4  生成配置代码

在配置完所有功能后即可生成WdgM相关的配置代码。

图9: 木牛代码生成配置界面示例

SafetyLibrary可应用于有功能安全等级需求的控制器。例如：

Ø  电机控制器

Ø  电池管理系统(BMS)

Ø  底盘系统应用

Ø  电气稳定控制(ESC)

Ø  电动助力转向(EPS)

Ø  安全气囊和传感器集成应用

Ø  雷达的应用

SPI周期性故障监控与响应

This feature enables the MCU to perform active, periodic health checks on the FS26. The MCU reads the FS26's fault status register set via the SPI interface at fixed time intervals (e.g., 10ms), thereby detecting faults such as voltage monitoring anomalies, overheating, watchdog errors, and communication failures in real time. Based on the severity level of the fault, it immediately executes corresponding safety measures.

软件实施流程

1.    初始化阶段：配置FS26的看门狗模式、故障报警引脚(FAILB)、各电源通道使能等。

2.    定时任务触发：由MCU的实时操作系统（RTOS）定时器或中断服务程序（ISR）周期性触发监控任务。

3.    SPI通信与读取：MCU发起SPI读取序列，获取FAIL_STAT_1, FAIL_STAT_2, DIAG_STAT等关键寄存器值。

4.    数据校验与解析：对SPI数据进行CRC校验，确保通信完整性，随后解析寄存器标志位，确定故障源。

5.    故障响应：根据预设的故障响应策略，执行相应操作。

故障分级响应策略

注：停止喂狗（Stop Feeding WDG）机制：这是最高级别的软件安全响应。当MCU侦测到无法处理的致命故障时，将主动停止刷新FS26的看门狗。FS26将在超时后自动执行其硬件安全响应（如触发芯片复位），确保系统强制进入已知的安全状态，这是实现安全机制独立性的关键。

ABIST自检功能驱动与诊断

1.1  ABIST功能简介

ABIST（Analog Built-In Self-Test）是FS26内部的模拟模块自检功能，用于检测芯片内部的潜在缺陷。

Ø  ABIST1：快速自检，耗时短，覆盖核心模块。

Ø  ABIST2（ABIST On Demand）：完整自检，耗时长，覆盖全部模块。

1.2  自检触发策略

Ø  启动自检（Ignition On）：车辆上电后，在执行主功能前，进行一次全面的ABIST2自检，确保FS26初始状态正常。

Ø  周期性自检：在车辆运行期间，每隔一定时间（如24小时）或在特定条件下（如车辆静止）触发ABIST1快速自检，实现运行中的在线诊断。

1.3  自检执行与结果处理流程

Ø  请求自检：MCU通过SPI向ABIST控制寄存器写入特定命令序列启动自检。

Ø  等待完成：MCU延迟等待t_ABIST1或t_ABIST2时间，或轮询DIAG_STAT.ABIST_DONE状态位。

Ø  验证结果：自检完成后，读取DIAG_STAT.ABIST_PASS位。

Ø  结果处理：

n  通过（PASS）：系统继续正常运行。

n  失败（FAIL）：此为严重硬件故障指示。MCU将记录最高优先级的DTC，并立即执行Level 3响应（停止喂狗），引导系统进入安全状态。

看门狗功能介绍

为什么看门狗是必须的？原因是运行在硬件世界中的软件会受到各种外界因素的影响，比如：汽车上使用的诸多零部件，鉴于汽车环境的恶劣，各类ECU中的软件均有可能遭受如外部电磁干扰，高温等环境因素的影响，从而导致程序“跑飞”或者“死机”现象，此时如果有看门狗的存在，便可以主动触发系统复位机制保证能够再次正常使用。

看门狗在使用时软件必须在规定的时间间隔内向其发送特定信号，这个行为被形象地称为"喂狗"，以免watchdog记时超时引发系统重启。硬件看门狗一般是一块专门的芯片，它通过监控电路的电压和电流等指标来判断系统是否正常运行。在下图是NXP的一款SBC芯片，该芯片就提供了看门狗功能，在使用时需要MCU通过SPI进行看门狗初始化及喂狗操作：

图2：外狗模块框图

知从木牛配置工具，给ECU控制器软件开发提供友好的人机界面。可以支持标准的AUTOSAR基础软件代码模块的配置，以及复杂驱动的配置界面开发。目前主要应用于如下场景：

图10:知从木牛标准平台框图

Ø  知从木牛基础软件平台标准AUTOSAR模块配置

Ø   知从木牛基础软件平台复杂驱动模块配置

u  SAFETY FRAME

u  CRYPTO LIBRARY

u  BCCIC

u  SBC

Ø  同芯片企业合作，提供MCU MCAL 的配置工具

Ø  ZC.MuNiu Basic Software Platform Standard AUTOSAR Module Configuration

Ø  ZC.MuNiu Basic Software Platform Complex Driver Module Configuration

u  SAFETY FRAME

u  CRYPTO LIBRARY

u  BCCIC

u  SBC

Ø  Collaboration with chip companies to provide configuration tools for MCU MCALs

目前，汽车上的电子电气架构越来越复杂，对汽车电子的安全性要求也越来越高，为了满足汽车的安全性需求，汽车功能安全越来越受到重视。提到功能安全，大家首先想到的是功能安全的标准ISO26262。其中，ISO 26262-5(2018) Clause 8中介绍了2个度量：Single-point fault metric(单点故障度量)和Latent-fault metric(潜伏故障度量)。根据不同的ASIL等级要求，单点故障度量和潜伏故障度量需要达到相应的等级。

对于微控制器(MCU，以下简称MCU)，在电子电气系统中，作为SEooC(safety element out of context)进行设计开发。MCU为了满足以上提到的2个度量要求，需要实现相应的安全机制。而安全机制可以分配到硬件和软件模块中。MCU的SafLib就是实现分配到软件上的安全机制。

图1：SafetyLibrary-FS26软件架构框图

Ø  可作为复杂驱动集成到AUTOSAR中

Ø  可集成到非AUTOSAR软件架构中，灵活适配

Ø  高安全性：搭配NXP-SAF软件可实现高达ASIL-D需求

点击下载产品手册