【转】芯片功能安全

背景

目前，汽车发展逐渐电子化，汽车产业也逐步智能化。在汽车领域，与功能安全相关的软件和硬件出现任何一个失效，都有可能会给人员、设备及环境带来严重的后果。汽车制造厂商面临的最大问题就是如何在产品设计阶段规避潜在的风险，所以，在汽车芯片的设计验证阶段，功能安全验证就显得非常重要。功能安全验证就是检验产品的安全机制的有效性。

目前国际上对产品进行功能安全验证的研究基于 ISO(International Standardization Organization)26262 标准。

功能安全 fusa

ASIL 等级

对于芯片安全机制检测故障的能力，ISO26262 中做了明确的汽车安全
完整性等 级（ASIL）规定, 由低到高分别为 ASIL A、ASIL B、ASIL C 和 ASIL D 四个级别，级别越高，芯片检测故障能力需求越高。

安全机制

1、处理器Lockstep技术

Lockstep 中文译为锁步，Lockstep 架构处理器采用 2 套复制的处理器、存 储器、比较逻辑、总线/背板接口，存在逻辑控制两套总线进行比较之后输出，这种设 计能够有效提高处理器对于指令级错误的检测能力。

• 数据校验
  a) 奇偶校验：8bit带1bit校验位，一般用于检测顶层寄存器值是否发生变化。
  b) ECC校验：8bit带5bit校验位，往后每增加一倍的数据位宽，增加1bit校验位。可以纠正1bit错误，对于2bit只能检错，不能纠错。
  c) CRC校验：一般用于检测总线接口数据流。
• 内存保护模块(MPU)
  对内存进行分区并赋予不同权限管理，若出现超越权限的内存访问，产生异常信号，上报cpu
• watchdog
  用于检测系统基于时间的错误，如死循环，让系统重启。
• clk monitor
  对于芯片内PLL功能以及晶振实时监测，包括：lockdead失锁时钟无效，error输出错误频率，jitter/skew过大的时钟抖动和偏斜。
• safty monitor
  监视系统中的错误中断，并汇聚成一个单一的错误中断，上报给CPU

功能安全方案

如图所示，当模块A将数据传递给模块B时，为了保证数据传输的正确性，在传输的过程中会通过ECC产生一个校验码，始终伴随原始的数据传输。一旦模块B接收到数据和校验码之后便会进行数据校验，如果发现数据有错误，就会将报警信息传递给功能安全控制器。

ECC校验覆盖了整个SoC，包括独立安全岛、系统总线、DDR控制器、显示接口、视频输入接口、以太网控制器等等，关键模块达到了99%的诊断覆盖率。

下表列出ISO 26262 part 5 所提供的微控制器安全机制参考设计，这些安全机制都具有99%的DC值，欲达成ASIL-D的要求，建议加入这些具有高故障诊断率的安全机制到微控制器设计中。

故障注入仿真

对于一些安全机制，比如处理器 Lockstep 技术，ECC校验, CRC校验等，其单点故障诊断覆盖率被证明是符合ASILD要求的(单点故障诊断覆盖率大于99%)，拥有以上安全机制的模块经过分析可认为是符合ASILD的。

但并不是每个模块都适合加安全机制去检测故障，比如在synopsys建议的汽车部件ASIL等级划分中，CV部分是属于ASILB等级的，其内部图形视频处理过程大多是没有加安全机制的，因为图形处理过程是无法预知结果的，输出取决于输入以及配置参数（当然也可以采取处理器Lockstep 技术，但消耗的面积难以接受），这个时候该怎么保障模块处理结果的正确性呢？

答案是开发 safety testpattern（输入固定，输出固定），并在车上定时执行testpattern看模块输出结果是否和testpattern预期结果一致，如果一致，则说明模块没有故障，如果不一致，则说明模块存在故障，计算结果可能会导致致命后果。

前辈原文链接：
https://zhuanlan.zhihu.com/p/546924366