简单说说汽车MCU会有哪些功能用以满足ISO26262功能安全要求
ISO 26262 要求汽车原始设备制造商和供应商必须遵循并记录功能安全开发流程（从开始制定规格直到量产发布），以使其设备具备在商用车辆（轿车）内运行的资格。该标准列出了风险分类体系（汽车安全完整性等级，ASIL），旨在降低电气电子 (E/E) 系统故障行为可能造成的危害。
根据定义，功能安全意味着不存在由于系统故障而造成的风险。要大幅降低发生故障的风险，关键是了解并评估可能发生的故障类型。这些故障可分为两类：1. 系统故障，可归因于某个原因，只能通过变更制造过程、操作流程、文档的设计或其它相关因素消除。借助强大的开发流程可降低发生系统故障的概率。（系统故障起因于设计和规范的问题; 软件故障和部分硬件故障是系统性的。） 2. 随机故障，这表示在硬件元件的生命周期内发生的不可预知的故障，按照概率分布。这些故障可能是由于永久性或短暂的干扰环境，也可能是在系统的生命周期中，由内部技术的性能而导致。可通过专用架构和IC策略降低随机故障的风险。（随机硬件故障起因于物理过程,比如疲劳、 物理退化或环境应力。）举个官方文档中的例子：
随机硬件故障的分类：
a) single-point fault;单点故障;
b) residual fault;残余故障;
c) detected dual-point fault;可探测的双点故障;
d) perceived dual-point fault ;可感知的双点故障;
e) latent dual-point fault; 潜伏的双点故障;
f) safe fault. 安全故障。
先重点讲两个故障
a) single-point fault 单点故障
该故障:
——可直接导致违背安全目标; 及
——是硬件要素的故障, 对于该硬件要素, 没有任何安全机制预防其某些故障违背安全目标。
示例: 一个未被监控的电阻, 该电阻至少有一种失效模式(例如: 开路) 有违背安全目标的潜在可能。
注: 如果一个硬件元器件有至少一个安全机制( 例如: 微控制器的看门狗) , 则该元器件的故障不被归类为单点故障。对于安全机制未预防其违背安全目标的故障, 被归类为残余故障。
e) latent dual-point fault; 潜伏的双点故障
该故障:
——促使安全目标的违背, 但仅与另一个独立硬件故障联合, 才会导致安全目标的违背; 及
——不被安全机制所探测也不被驾驶员感知。直到第二个独立故障发生前, 系统始终可以运行且驾驶员也不知道发生了故障。
）
（关于随机硬件故障的分类有一个很大的图，挺复杂的，下次再细说。）
MCU的功能安全相关软硬件机制
比如：
delayed lockstep 锁步核 。一个内核在跑，另一个核延时几个clock后执行同样的指令，进行对比检查。
End-to-End ECC模块，确保存储数据的安全。
Clock and power, generation and distribution, are supervised by dedicated monitors。电源和时钟的监控模块。
The safety of the periphery is ensured by application-level measures (such as connecting one sensor to different I/O modules, sensor validation by sensor fusion, and so on). Hardware supports this application-level redundancy by providing redundant I/O modules connected to different peripheral bridges (PBRIDGE) to maximize the independence between the monitored and monitoring resources . （太长了，不会翻译
） 提供硬件冗余，比如SPI0在一条总线上，SPI5在另一条独立的总线上（SPI0 与 SPI5隔离开，不会因为总线的问题导致同样的错误）。Built-In Self-Test (BIST) 模块。The BIST can be performed on the device's embedded memories and logic。
故障收集和控制单元（Fault Collection and Control Unit）负责收集各个模块的故障信息并作出反应（比如产生中断，芯片复位，发送故障信号给外部器件）。
Memory Protection Unit
Watchdog
...
有了以上模块，汽车级MCU在功能安全方面一般会有以下策略：
在安全软件应用程序启动之前执行完整性检查或初始检查。比如运行BIST模块，MCU上电时可以先检查内存以及各个模块逻辑是否正确。
对BIST模块没有覆盖的安全机制进行测试，比如可以对ECC模块进行故障注入测试，检测ECC模块本身是否工作正常。
周期性地检查关键参数，比如安全有关外设的初始化值，检查关键寄存器配置以防止未知的位翻转（bit-flip ）。
使能故障收集和控制单元，对安全相关的故障进行收集和报告。
通过硬件方式监控和测量时钟模块，电源模块。
使用某些ADC参考值检查ADC转换可靠性。
检查看门狗的有效期限。
测试检查计时器单元是否仍在运行。
测试检查温度传感器是否仍在可接受范围内。
...
总结起来，至少有这两类：
对安全机制本身进行测试验证，增加潜在故障覆盖。（1，2，4）
开启更多的安全机制，并且能够对监控到的故障进行相应处理，增加单点故障覆盖。（1，3，4，5，6，7，8，9）
所以说，为了功能安全，汽车级MCU会有很多需要做的工作，一个能达到ASIL-D级别产品的软硬件也远比想象中复杂。毕竟手机死机了，重启就好，而汽车控制器总不是经常死机，导致车开不动停在长安街吧？
ISO/FDIS 26262:2018；
GB/T 34590—2017；
NXP 白皮书《集成了安全性的硬件解决方案，为ASIL-D应用提供支持》；
各大厂芯片手册。
- 用户评论
