干货分享 | 功能安全常见疑难问题汇总

“功能安全常见疑难问题解答”

在智能驾驶及新能源汽车的飞速发展之下，功能安全已成为绕不开的关键领域。然而在实际应用中，一直面临着诸多问题和挑战。前不久，磐时举办了一场针对实操问题的线上答疑活动，我们分类整理了一些热门问题及解答，可作为大家日后实践中的参考。

关于功能安全机制及其诊断覆盖率问题

Q

外狗从功能上来讲是否可以完全覆盖内狗？什么情况下内狗和外狗都需要使用？

A

外狗虽然可以对程序流进行监控和保护，但无法完全替代内狗。内狗能够直接嵌入程序中，关注程序非预期跳转及执行时间异常等，与应用软件结合更加紧密。而外狗作为独立硬件，主要用于监控内狗本身，从而保证内狗的独立性。在某些极端情况下，可以仅保留外狗而取消内狗，但这种做法时延较长且外狗需要较高智能，实际效率较低，不推荐采用。

同时由于内狗与应用软件紧密相关，在一些情况下，如芯片内部振荡器发生错误时，即使内狗正常，诊断代码和功能执行代码也可能失效，此时内狗就无法提高检测覆盖率，因此外狗是必需的。

Q

什么样的CRC满足ASIL D？

A

对于通信协议，标准定义了几种失效模式，例如数据损坏、报文重复、错序、丢失、超时、错误寻址、伪装等等，通常采用CRC16/32、滚动计数器（RC值）、超时Timeout及帧ID等机制来覆盖。在评估E2E保护机制的残余风险时，需要根据CRC多项式计算出汉明距离，结合报文长度及每小时PDU发送量，推导出每小时的残余差错率。通常通信总线上的残余差错率定义为不超过item对应ASIL等级的1%。

Q

除了流程上满足，BSW怎么算满足了ASIL，常用的安全机制有哪些?

A

除了满足流程要求外，BSW满足ASIL还需要：

1）覆盖硬件未能诊断的随机失效；

2）基于防御性编程思路开发，保证软件确定性，采用标准推荐的方法。

Q

不同功能安全等级ABCD对安全机制的要求，有哪些区别？功能安全机制一般要包含哪些要素或注意的地方？

A

不同ASIL等级对安全机制的要求有所区别：

1）等级越高，可能需要更多组合的安全机制来覆盖所有失效模式；

2）对于同一安全机制，等级越高其诊断间隔要求就越短，以满足更短的FTTI周期要求。描述安全机制时，不仅需要阐述诊断功能，还应包括安全路径即达到安全状态的功能链路。

Q

关于安全机制的DC，是否存在两个low叠加能得出medium这种逻辑？

A

通常情况下，两个低DC的安全机制无法通过叠加得到更高的DC。原因是它们可能仅覆盖了同一种失效模式，无法涵盖所有失效模式。不同安全机制一般覆盖不同失效模式，需要组合使用才能获得高DC。

Q

在做程序流监控时，BSW或MCAL的周期任务是否也需要做监控？

A

对于BSW或MCAL等周期任务的程序流监控，需要通过外部独立的硬件看门狗来实现。

关于功能安全等级ASIL问题

Q

MPU的使用和ASIL等级是否相关，是否使用MPU还需要考虑哪些因素？

A

MPU作为内存分区的硬件机制，在操作系统等软件无法实现时通常需要使用，与ASIL等级无直接关系。MPU的使用主要是通过限制对指定内存区域的访问权限，从而提供通用的内存保护机制。MPU的使用与否并不仅仅取决于ASIL等级，还需要结合其他因素综合考虑，比如不同功能或安全等级的内存保护。

Q

功能安全对于D-FMEA是否有要求？以及对于这些特性后续在PFMEA或者control plan中是否有要求？

A

功能安全对D-FMEA是有一定要求的。对于影响安全的失效模式，严重程度通常需标注为9或10级；同时需标注CC（关键特征）和SC（特殊特征），这些特性后续需要在P-FMEA和控制计划中加以管控。

Q

TSR导出HSR和SSR时，请问FTTI如何分解？

A

在TSR分解为HSR和SSR时：

1）FTTI已在定义safety goal时确定；

2）到系统层面时，FTTI需进一步分解为FDTI和FRTI；

3）硬件FDTI和FRTI一般在几ms甚至us量级；

4）软件FDTI需考虑诊断间隔及误报滤波预留；

5）软件FRTI可根据相关诊断任务的执行周期确定。

Q

ASIL A的功能安全要求有哪些？硬件没看到有指标，软件这块需要做到什么程度，有没有需要注意的地方？

A

ASIL A产品的功能安全要求包括：

1）极少单独存在ASIL A功能，通常与更高等级需求合并；

2）满足ISO 26262相关篇章中ASIL A的基本要求，比如产品的可靠性测试和功能测试；

3）主要体现在功能安全管理流程方面,对诊断机制要求不会过高。

Q

系统阶段失效模式有什么参考的吗，进行系统架构设计的层次颗粒度怎么把握，并介绍做系统DFA的思路。

A

系统阶段FMEA/DFA分析的失效模式可以参考：

1）通常基于功能层面，如信号传输、数据转换、数据处理等进行分析，不会细化到具体器件；

2）使用“与预期相反”、“非预期执行”等引导词指导功能层面分析；

3）颗粒度应高于硬件或软件层面分析。系统DFA的思路也是首先定义分析对象的DFI要素，DFI可以参考标准的推荐，结合DFI类型进行影响分析和分配相关的安全探测机制。

关于软硬件架构和需求分解问题

Q

在软件架构设计阶段，如何对软件架构进行设计验证？比如，如何进行数据流和控制流分析；如何进行原型验证；如何进行动态行为仿真？

A

软件架构设计验证的常用方法包括：

1）设计评审；

2）原型验证；

3）绘制数据流图和控制流图,并进行软件FMEA分析；

4）动态行为仿真等。

Q

系统安全需求TSR和系统需求（把系统作为黑盒）是一个层级的需求吗？TSR是否得移植迭代直到一条TSR要不是给软件实现要不就是给硬件实现？TSR是否属于系统架构级别的需求？（因为它还需要allocate给你一个系统要素）？同理软件安全需求和软件需求的关系是不是也是这样？

A

1）系统安全需求TSR与系统需求虽属同一层级，但TSR的颗粒度更细，至少需将需求分配到具体的软硬件组件；

2）在定义TSR时，系统安全架构应已明确，TSR能够分解至具体软硬件实现；

3）软件安全需求SSR的描述原则与TSR相似，需分配到具体的软件组件，并完整描述功能链路。

Q

TSR和系统需求（aspice语境下是描述系统的黑盒需求）不是一个层级，TSR更适合放在系统架构设计里？SSR也更适合放在软件架构设计里？

A

可以将TSR视为系统架构级需求，SSR视为软件架构级需求。通过明确的TSR和SSR，可充分描述各功能安全链路，并组合形成系统和软件的完整安全架构设计。

Q

在实际开发过程中，系统需求应该去承接所有的客户需求(包含FSR？)，如果TSR认为和系统架构是一个层级，那TSR和系统需求是什么关系呢？它向上追溯怎么做呢？

A

1）系统需求承接客户所有需求（包括FSR）；

2）TSR和系统需求同级，前者描述所有系统需求（包括非功能安全、结构要求、性能要求等），后者偏功能安全描述；

3）两者共同构成产品全部需求；

4）TSR上溯源自FSR,系统需求上溯源自客户原始需求。

Q

怎么区分一个需求是FSR还是TSR，结合例子描述。

A

FSR和TSR的区分：

1）FSR更多从功能角度，侧重整车item层面，如防止非预期加速；

2）TSR更关注具体的功能安全要求，如（为了防止非预期加速）对输出加速信号进行E2E校验和输出合理性检擦等，关注使用何种安全机制等；

3）FSR的描述层级更高，侧重整车功能，TSR的颗粒度更细，侧重具体实现。

关于芯片/IC安全机制设计的相关问题

Q

IC设计中哪些电源和时钟是要监控的，时钟会有很多分频或分支出来，在使用前都要监控吗？

A

在IC设计中，需要监控的电源包括：

1）通常采用带ASIL等级的PMIC或SBC进行电压/电流监测；

2）传统设计中可能使用DCDC+比较器监测电压，但无法监测电流；

3）外部振荡器可利用芯片内置的安全机制进行监控；

4）芯片内部时钟树分支后，各个域可能有专门的PLL监测机制，具体取决于芯片安全机制。

同时对于IC内部电源和时钟监控，设计时需要基于一些假设前提，如定义安全域。针对这些域使用的供电和时钟，会有通用的域值检测机制，包括输入输出检测、配置检测等。

Q

芯片内部一些常用的Safety Mechanism的Diagnostic Coverage 通常该怎么定义？

A

芯片内部安全机制的诊断覆盖率DC无法直接采用ISO 26262中低/中/高的粗粒度定义方式，需要：

1）具体分析被分析对象的失效模式；

2）结合可靠性模型定义各失效模式的占比；

3）根据不同失效模式分配对应的安全机制；

4）通过芯片层面的故障注入测试,验证所有失效模式均被覆盖。

Q

芯片有300多个引脚，与该软件功能相关只有40~50个，那么其他引脚的失效需要考虑吗？

A

在进行芯片FMEDA计算时，会对与分析对象无关的非安全功能模块和管脚进行裁剪，非安全的管脚不予考虑。

Q

FMEDA中关于芯片的瞬态失效一般应该怎么处理？

A

针对芯片瞬态失效，常见的保护机制有：

1）内存ECC；

2）锁步等架构设计；

3）冗余RAM实时比对。

这些措施通常应用于高ASIL等级且检测间隔要求很短的场景。在产品级FMEDA中，个人建议应当考虑芯片瞬态失效的影响。虽然采用针对性保护机制能提供较高DC，但由于瞬态失效基数较高，残余风险仍较可观。不过，业内通常在采用一定保护措施后，不会过多关注瞬态失效问题。

关于安全性分析问题

Q

在做FMEDA时，标准中对于一些影响EMC相关的失效定义比较模糊，什么时候需要定义为单点，什么时候定义为潜伏或者安全故障？

A

通常EMC不会被视为需要在FMEDA中分析的随机失效，而是作为系统性失效的一个要素，在可靠性设计时需要考虑。只有在特定条件下缺少EMC保护措施时，EMC才可能被定义为单点失效进行分析。

举个例子，产品在正常的设计和使用状态下，通常都会有外壳等保护措施,能够防范EMC相关的静电放电风险对敏感元器件造成损害。但是，如果在生产或运行过程中，产品暴露于无外壳保护的特殊环境，那么人员操作或维修时可能会导致静电释放，对敏感元器件产生影响，此时就需要将这种EMC故障视为单点故障进行分析。不过，在产品设计阶段，通常已经充分考虑了这一风险。比如，通过EMC可靠性测试和系统测试，验证了产品在特殊环境下的稳定性能；同时，对于电气敏感元件也采取了外壳、封装等保护措施。因此，在正常的设计和使用条件下，EMC相关的故障极少被视为单点故障进行分析。

Q

FMEDA分析的时候，会有DC的概念，ISO内给了一部分的参考值。比如ECC，Parity。对于ISO没给的特殊的SM，通常如何判断其DC？比如，部分IP的故障模式可以被NOC的Timeout检测到，这个SM的DC该如何定义?

A

对于标准中未给出参考值的特殊安全机制，判断其DC的依据如下：

1）标准已涵盖80%常见器件失效模式，对芯片等新型器件也有所补充；

2）可根据器件功能定义分析潜在失效模式，采用失效模式占比平均分配的方法初步评估DC；

3）对自定义的检测方法，需从被检测对象的失效模式出发，分析所使用的安全机制能覆盖哪些失效模式，可通过故障注入测试验证机制有效性；

4）对于难以合理分配的失效模式，需结合可靠性模型进行定性定义，同时缺乏标准支持。

关于软件失效分析问题

Q

软件分析中对于软件的失效（不考虑硬件）是都可以通过流程措施来解决软件失效，还是必须增加实时运行的检测机制来监控软件（如程序流监控）？如果有的需要有的不需要，是什么依据来判断的？

A

功能安全相关软件的失效模式分为两个方面：系统性失效和随机失效。系统性失效如设计缺陷、编码错误等，可以通过改进流程、规范编码习惯等措施来解决。随机失效如受EMI干扰、硬件故障影响等，则需要采取诸如程序优先级分配、程序流监控、数据端到端保护等技术手段。因此，针对不同的软件失效模式，需要采取流程措施和技术手段相结合的方式。

Q

DFMEA和FMEA的区别

A

DFMEA考虑维度更广，不仅包括安全相关器件的随机故障，还包括非安全器件对性能的影响、制造过程问题等。而FMEA则专注于安全相关器件的随机故障模式分析，并提出相应的安全机制和诊断覆盖率，用于量化残余风险。在功能安全项目中，系统阶段需要同时开展FMEA（分析随机故障）、故障树分析等，也需要DFMEA分析，两者是互补而不冲突的。

其他问题

Q

关于硬件要素评估，3类要素除了做分析评估和测试以外，标准上还说要有措施来证明系统性失效足够低，现在主要有哪些比较认可的措施？

A

对于三类硬件元件（ASIL C等级），通常不会单独分配安全机制,而是通过其他措施来证明其系统性失效足够低。目前较为认可的措施是“经证实使用”（Proven in Use），即通过大量实践使用和测试来证明元件的可靠性。但这种方式的置信度相对较低。硬件组件鉴定活动通常采用“经证实使用”方法，如果一个元件在多款ASIL B级产品中使用并证明了相关可靠性，则可被视为满足ASIL B级使用要求，但不等于通过ASIL B级认证。目前无统一量化标准规定“经证实使用”的具体条件，大多数公司在这方面较为保守，认为这种方式最多只能达到ASIL B级，要更高级别还需要完整的分析评估过程。