在功能安全项目当中，依赖失效分析到底该怎样去开展，依赖失效的证据又该怎样去整理，这两样事情常常容易被做得不够扎实。它并不是把FMEA、FTA再拿出来重新做一遍，而是要判断系统里边那些原本希望相互独立的元素，会不会由于同一个原因一块儿失效，或者一个元素出了毛病之后又接着去影响另一个元素。就比方说主功能与监控功能之间、主通道跟冗余通道之间，还有做完ASIL分解之后的两个子元素之间，要是在实际的设计里共用了电源、通信链路、时钟、复位或者软件资源，那就不能简简单单地写上一句“相互独立”就交代过去了。

　　一、ISO 26262依赖失效分析怎么开展

　　在开展依赖失效分析的时候，不能光把眼睛盯在单个模块上头，而得把模块相互之间的关系拉出来看一看。尤其在安全机制、冗余通道、监控链路，还有不同ASIL等级的元素搅在一块的场合，分析的重点倒不是“存不存在故障”，而是“某一个故障会不会在同一时间拖累好几个对象”。

　　1、明确分析对象

　　依赖失效分析首先得定下来，到底是哪些元素之间需要保持住独立性。常见的对象里边，包括了主控制功能与监控功能、主通道与备份通道、ASIL分解之后的那两个子元素，还有QM软件跟ASIL软件挤在一块儿的情况。在这个地方，要把分析的目的给写明白，到底是为了证明安全机制是管用的，还是去证明低等级的元素不会反过来干扰到高等级的元素。

　　2、核对项目输入

　　对照【Item定义】、【HARA结果】、【安全目标】和【技术安全需求】，确认依赖失效分析覆盖的功能边界和安全目标范围。

　　这些用来做输入的材料，主要的用处是帮我们圈出来分析的范围，免得DFA到头来只分析了局部的一小块儿，却把那些真正会冲击到安全目标的功能链路给漏掉了。要是中途安全目标、ASIL的等级或者架构的方案发生过变动，那依赖失效分析也得跟着同步去更新，不能再把旧版本的结论继续拿出来用。

　　3、查找共享资源

　　依赖关系很多时候并不是摆在功能框图上的，而是悄悄藏在实现的细节里边。在硬件这个层面，要留神供电、地线、时钟、复位、传感器、执行器，还有通信总线；到了软件层面，就得去看有没有共享内存、全局变量、任务的调度方式、通信协议栈、诊断服务，还有那些配置参数。只要发现两个元素一块儿用着同一类资源，那就得接着去判断，这种资源万一出了故障，会不会把两个元素同时给牵连进去。

　　二、ISO 26262依赖失效证据怎么整理

　　到了证据整理这一步，重心是让做评审的人顺着材料就能看清楚，分析的结论到底是打哪儿得来的。DFA不能光靠一张表格撑着，也不能只用一句“风险可接受”来交差，它需要把输入的资料、架构的关系、安全方面的措施，还有验证得到的结果，一股脑儿地串到一起去。

　　1、建立DFA分析表

　　在【DFA分析表】中记录分析对象、依赖来源、失效类型、传播路径、安全影响、安全措施、验证方式和结论。

　　表格本身用不着做得多么复杂，可是每一条记录都得能撑得起后面的判断。打个比方，主控MCU和监控MCU如果共用着一路电源，那就不能只写“有电源监控”这寥寥几个字，还得说明白是哪个模块来负责检测，检测要满足什么条件，发现异常以后系统会执行哪些动作，到了最后到底能不能稳稳地进到安全状态里面去。

　　2、补充架构证据

　　架构证据这一块，主要是拿来说清楚系统各个元素之间真实到底是怎么连起来的，不能随便丢上一张过分简化过的功能框图就算完事儿。比较有说服力的材料，一般会包括系统的架构图、硬件之间的连接关系、软件任务之间的关系、接口的说明，还有资源是怎么分配的说明。评审的人需要从这些材料里头，看出有哪些资源被共享了，哪些接口会把错误给传过去，又有哪些安全机制可能会被同一个失效的源头给影响到。

　　3、整理安全措施证据

　　将【看门狗策略】、【电源监控设计】、【通信保护机制】和【降级策略】对应到具体风险项。

　　整理证据的时候，重心并不在于堆上多少附件，而在于让DFA表里头的每一个结论，都有它对应的出处。比方说表格里头讲通信出错能够被识别，那证据那边就得能拿出校验、计数、超时还有错误处理的逻辑来；要是表格里头写着软件资源已经隔离开了，证据那边就要能看到任务是怎么划分的、内存是怎么被限制的、访问的权限又是怎样被管控住的。

　　三、依赖失效分析落地时要注意什么

　　依赖失效分析在真正往下落的时候，最怕遇见的一种情形，就是表格乍一看填得密密实实的，实际上却只盖住了表面的那一层关系。在一个项目里头，真正容易引出麻烦的地方，往往藏在共享的资源、特殊的运行阶段，还有监控机制本身是不是足够独立这些事情上。

　　1、不要只盯硬件依赖

　　不少项目会抢先去检查电源、时钟、复位，还有传感器这些硬件层面上的东西，这些当然都非常要紧，可是软件层面的依赖反倒是更加容易被漏过去。比方说不同ASIL等级的软件跑在同一个控制器上面，一起共用着操作系统的服务、通信的缓存、诊断的状态，或者是配置的参数，这个时候就有可能出现时间上的干扰、内存上的干扰、通信上的干扰，还有执行顺序上的干扰。软件这部分如果没有说清楚，那整份DFA通常就不能算是完整的。

　　2、不要把监控写成万能结论

　　在DFA表里头，我们很容易看到“已经有监控，风险关闭”这一类写法，可是光有这句话本身是不够的。项目组还要接着去判断，这套监控机制到底是不是独立的，监控它自己会不会也被同一个原因给牵连进去，监控要是真发现了问题，它能不能在规定的时间内做出有效的响应。举例来说，主功能和监控功能如果都仰仗着同一个输入信号，那当输入信号本身出了毛病的时候，监控这一头也很可能照样判断不出来，碰到这样的情况，就得再往下补充合理性的检查，或者是独立的诊断能力了。

　　3、覆盖特殊运行阶段

　　检查【上电】、【复位】、【刷写】、【标定】、【诊断】和【降级】阶段是否会产生新的依赖关系。

　　有一部分问题，在正常运行的稳稳当当的状态下是不太显眼的，可是一旦到了模式来回切换的关口，就容易一下子暴露出来。比方说在刷写的期间，有一部分诊断功能被临时关掉了；标定的参数一旦写错，就会牵扯到好几个功能；诊断会话如果占去了大量的通信资源，又可能让安全相关的报文出现延迟，这些情况全都有可能成为依赖失效的源头。把这些特殊的阶段补充进去，整份分析的结果才会更加贴近项目真实的样子。

　　总结

　　总的说起来，依赖失效分析怎么去开展，依赖失效的证据又该怎么去整理，关键的步骤是先要找出那些需要保持独立的元素，然后再顺着共享的资源、共因造成的影响，以及失效传播的路径，一项一项地去排查。等到整理证据的那个时候，也不能仅仅留下一张DFA表格，而是要把输入的文档、架构上的说明、安全措施、验证记录，还有风险关闭的结论全都串到同一条线上。这样做出来的材料，才不至于变成单纯为了填表而填表，而是能够实实在在地撑起功能安全评审和安全论证的东西。