车载软件架构——车载诊断软件框架

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

人们会在生活中不断攻击你。他们的主要武器是向你灌输对自己的怀疑：你的价值、你的能力、你的潜力。他们往往会将此伪装成客观意见，但无一例外的是，他们想让你怀疑自己。

本文主要讲述如下内容：

-> 1、车载功能安全诊断框架技术要求

-> 2、诊断框架技术学习

开门见山，正文开始。

对于车载安全，对于工程师就会提到功能安全与软件架构，可以从 如下两个方案考虑：

-> 符合功能安全的软件架构;

-> 功能安全软件架构.

这两个维度去看待它们之间的关系。

对于符合功能安全的车载软件架构，从软件开发角度看当下软件架构设计过程对功能安全的符合性，也就是软件架构设计过程需要满足ISO 26262提出的各种要求：

-> 标记方法；

-> 设计原则；

-> 设计要素要求；

-> 安全分析要求；

-> 错误探测机制要求；

-> 错误处理机制以及设计验证方法等，

软件架构层面的安全分析主流策略是软件FMEA（Failure Mode and Effects Analysis）和 软件 DFA（Dependent Failure Analysis）。

对于功能安全软件架构，重点是从嵌入式软件系统角度看对系统级功能安全的支撑。基于电动汽车安全架构的思想，私下认为 “分层监视思想” 、“安全措施” 和 “诊断框架” 是 “功能安全软件架构” 的核心，“，本文接下来内容主要围绕诊断框架进行说明。

无论我们使用的基础软件开发平台是 AUTOSAR CP、AP 或者是非 AUTOSAR，功能安全软件架构的设计思路是类似的，这里基于 AUTOSAR CP 进行说明。

一、车载功能安全诊断框架技术要求

对于功能安全，车载诊断架构检测预期风险，是其中重要一环：

结合 FTTI（故障容忍时间间隔，fault tolerant time interval）理解故障诊断过程。从故障发生到产生可能危害之间的这段时间就是FTTI时间，此期间主要有诊断测试、故障响应过程，并且希望在产生可能危害之前进入安全状态。诊断测试过程需要考虑诊断测试触发、故障确认（去抖）等，故障响应过程需要考虑进入合理的操作模式（如：Fail safe, Fail operational, Emergency operation 等）、故障存储等。

综上，车载诊断框架的核心设计需要考虑覆盖诊断测试、故障响应过程。主要的功能安全诊断框架技术要求有：

-> 1、故障统一管理：对车载软件多层监视框架各故障监视层上报的故障进行状态统一管理——保证数据一致性；

-> 2、故障响应时间要求：故障检出到进入安全状态需满足故障容忍时间间隔的要求——故障触发后与后续功能降级的执行动作保持紧密绑定；

-> 3、独立性要求：片上安全机制与功能存在共因问题，需支持独立性监视（MCU 片外监视）——对于软件对片上硬件监视提出更高的要求；

-> 4、多样化要求：软件架构须满足框架设计通用化和支持安全策略多样化；

-> 5、诊断测试时机：上下电，周期，条件触发——这些条件需要在规范中明确定义并释放给响应的功能实现方；

-> 6、故障去抖/延时检查：需支持安全机制的去抖测试功能，至少支持基于时间和基于计数去抖算法——这些消抖策略在AUTOSAR DEM模块都是现成的策略‘

-> 7、诊断事件和功能解耦：诊断事件和功能独立管理，之间存在映射关系——Diagnostic event、DTC和功能映射关系；

-> 8、故障存储：支持故障信息非易失存储——在对应的代码配置工具中，定义DTC、DTC Status、快照信息等与芯片内存地址一一对应。

二、诊断框架技术学习

在对诊断框架技术展开之前，有两个方面的思考点供参考：

1：根据需求确定车载诊断测试的时机

a. 车载ECU控制器上电时：结合一个典型应用需求进行说明。安全机制（safety mechanism）和对应的功能构成了双点，为了降低潜伏多点故障失效率，一般在系统启动阶段（上电时），安全机制需要做自检。此点共能对于具备车载操作系统的多核ECU更是如此！此处也需要注意，在多处理器系统中还需要考虑诊断测试同步问题。

b. 车载ECU控制器运行时：一般分周期性诊断测试和条件诊断测试。诊断周期的定义需要考虑 FDTI（fault detection time interval）的约束，而条件诊断测试一般是发生状态迁移时或在激活某个功能前对功能进行的诊断，此点有点类似于事件触发。

c. 车载ECU控制器下电时：选择执行一些比较耗时的测试，而测试结果一般放在下一次启动时处理。因此测试结果需要存储在一个掉电非易失内存中！！！

2：进行分组诊断测试

为了便于诊断管理（包括诊断触发和故障响应等），根据临界故障 / 非临界故障，诊断测试时机等因素进行分组。上电时如果检出临界故障（Critical fault），此处我在做平台级车载软件AUTOSAR研究时，此处就是就是一个非常重要的点，现在车载控制器多核多系统的状态，比如：核故障（Core Fault）、易失性存储器测试故障（Ram Test Fault）等，这时故障响应可以选择处在一个静默状态处理（如：MCU处在连续复位状态）。

对于车载三层监视框架：

-> Level 1(function level）;

-> Level 2(function monitoring level）位于ASW(application software,既软件上层应用SWC) 层；

-> Level 3(controller monitoring level） 位 于BSW(basic software) 层。

车载软件诊断框架，位于BSW层，主要覆盖诊断测试、故障响应过程，具体内容如下：

（1）、车载软件架构AUTOSAR中，BswM、 EcuM 主要负责上下电管理（State Management Module），在 STARTUP、UP、SHUTDOWN 阶段分别进行上电时、运行时、下电时的诊断测试；

（2）、ASW-Level 1覆盖功能输入/输出的诊断了，ASW-Level 2（E-Gas Level2）一般实现为 ASW-Level1 功能的冗余算法，实现 ASW-Level1 ASIL 等级的分解；

（3）、Test Manager 负责对软件库安全机制的诊断测试触发及相应测试结果的收集；

（4）、AUTOSAR DEM模块收集车载Level1/2/3的测试结果，诊断事件去抖，标记故障码及通过NvM进行故障信息存储（主要存储DTC、状态位、快照信息等）。FIM 根据DEM诊断测试结果（去抖后）标记已配置的功能，功能软件（ASW-Level1）根据标记来决定对功能的抑制。

三者作为一个机动性平台，保证车辆基本的共能安全。

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者！