智能驾驶系统：硬件融合设计案例分析文档
|
文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改 |
|
发文件起草分工： 1. |
|
编制： |
签名： 日期： |
|
审核： |
签名： 日期： |
|
批准： |
签名： 日期： |
|
所有权声明 |
|
该文档及其所含的信息是财产。该文档及其所含信息的复制、使用及披露必须得到的书面授权。 |
上图为未实施安全要求时的车辆纵横向控制模块的硬件架构，主要由四个部分组成：主控 MCU 、外围设备、通讯电路以及电源模块组成。其中域控制器 SOC 模块通过 ETH 接发器与域控制器 MCU 进行以太网通讯，将规划好的换道轨迹发送给 MCU ； P-BOX 、 T-BOX 以及毫米波雷达分别通过 CAN 处理电路和 CAN 接发器与域控制器 MCU 进行 CAN 通讯，将车辆定位信息、远程通讯指令、目标车辆信息发送给 MCU ； MCU 通过 CAN 处理电路和 CAN 接发器分别与线控转向系统、线控制动系统以及人机交互系统进行 CAN 通讯，分别将控制指令发送给它们；电源模块提供电源给 MCU 以及各收发器。从原始硬件架构可以看出，未实施安全要求的情况下，任何一个组件发生异常的情况下，横向控制功能均不能正常的工作，因此原始硬件架构是不足够安全的，需要实施安全要求来保证控制功能的正常工作。
技术安全要求导出硬件安全要求，如下图所示，即需要在硬件层面采取具体措施来实现技术安全要求，这些措施应包括避免硬件内部系统失效的措施、应对硬件外部相关失效的措施以及避免硬件随机失效的度量要求，因此为了更加全面地实现技术安全要求，在技术安全要求导出硬件安全要求中，需要借助分析方法，结合原始的硬件架构，对每一条技术安全要求进行细致的异常分析，对技术安全要求所涉及的可能存在的硬件内部系统失效以及外部相关失效进行提取，进而提出相应的措施来实现技术安全要求，完成硬件安全要求的导出。对于硬件安全要求的导出，本案例中采用 FTA 故障树的方法，结合原始硬件架构，对技术安全要求逐一进行分析，提出相应措施来避免内部系统失效以及硬件外部相关失效，硬件随机失效的度量要求即所提出相应措施的安全完整性等级。在硬件安全要求导出中，仅围绕车辆定位、车辆横向控制以及线控转向系统进行分析与讨论。
对于硬件安全要求的导出，对技术安全要求分三个部分进行展开分析，分别为输入端异常安全要求导出、控制端异常安全要求导出以及输出端异常安全要求导出，其中输入端异常安全要求导出、输出端异常安全要求导出进行分析以应对硬件外部相关失效，对控制端异常安全要求导出来避免硬件内部系统失效。硬件安全要求的导出过程如下所示。
|
(F)TSR-01 |
实时对车辆定位信息进检测，确保定位信息真实准确 , 避免定位故障导致车辆控制失效 |
D |
DC |
|
|
|||
|
(F)HSR-01-01 |
实时对定位信息通讯进行故障检测，确保定位信息通讯正常 |
D |
DC |
|
(F)HSR-01-02 |
实时对车辆定位模块进行故障检测，确保车辆定位正常 |
D |
DC |
|
(C)TSR-01 |
实时对车辆定位信息进检测，确保定位信息通讯真实准确 , 避免定位遭到网络攻击导致车辆控制失效 |
D |
DC |
|
|
|||
|
(C)HSR-01-01 |
实时对定位信息通讯进行网络攻击检测，确保定位信息通讯正常 |
B |
DC |
|
(C)HSR-01-02 |
配备硬件加密模块，对定位信息进行加密传输，保护通讯安全 |
B |
DC |
|
(C)HSR-01-03 |
实时对车辆定位模块进行网络攻击检测，确保车辆定位正常 |
B |
DC |
|
(S)TSR-01 |
采用高速传输通讯方式，确保车辆定位信息传输实时可靠，避免定位通讯不足导致车辆控制失效 |
D |
DC |
|
|
|||
|
(S)HSR-01-01 |
配备高速的传输接口，确保定位信息通讯高速传输 |
D |
DC |
|
(S)HSR-01-02 |
采用高传输速率的通讯协议，确保定位信息通讯高速传输 |
D |
DC |
|
(S)HSR-01-03 |
微控制器应具备高速接发传输的通讯能力 |
D |
DC |
|
(F)TSR-02 |
定位信息传输通道冗余与故障隔离设计，确保主通道故障时能够切换到冗余通道 |
D |
DC |
|
|
|||
|
(F)HSR-02-01 |
设计独立的冗余通信通道，包括 CAN 绞线、 CAN 收发器以及 CAN 控制器 |
B |
DC |
|
(F)HSR-02-02 |
通信通道应具备故障隔离功能，防止主通道故障影响冗余通道 |
D |
DC |
|
(F)HSR-02-03 |
微控制器具备多 CAN 通道接口，满足 CAN 通讯冗余设计 |
B |
DC |
|
(C)TSR-02 |
定位信息传输通道冗余设计与安全防护设计，确保主通道遭到网络攻击时能够切换到冗余通道 |
B |
DC |
|
|
|||
|
(C)HSR-02-01 |
通讯接口应具备良好的抗干扰能力，减少物理网络攻击对通讯的影响 |
B |
DC |
|
(C)HSR-02-02 |
配备硬件加密模块，对定位信息进行加密传输，保护通讯安全 |
B |
DC |
|
(C)HSR-02-03 |
微控制器具备多 CAN 通道接口，满足 CAN 通讯冗余设计 |
A |
DC |
|
(F)TSR-03 |
控制器具备定位信息故障容错控制，确保在定位故障时保持一定的控制能力 |
D |
DC |
|
|
|||
|
(F)HSR-03-01 |
微控制器具备在定位信息丢包下保持一定的车辆控制能力 |
D |
DC |
|
(F)HSR-03-02 |
微控制器具备在定位信息时延下保持一定的车辆控制能力 |
D |
DC |
|
(F)HSR-03-03 |
微控制器具备定位估计能力，在定位信息丢失下保持一定的车辆控制能力 |
D |
DC |
|
(C)TSR-03 |
控制器具备定位信息攻击容错控制，确保在定位遭到网络攻击时保持一定的控制能力 |
B |
DC |
|
|
|||
|
(C)HSR-03-01 |
微控制器具备定位估计能力，在定位信息篡改下保持一定的车辆控制能力 |
B |
DC |
|
(C)HSR-03-02 |
微控制器具备定位估计能力，在定位信息重放下保持一定的车辆控制能力 |
B |
DC |
|
(C)HSR-03-03 |
微控制器具备定位估计能力，在定位信息丢失下保持一定的车辆控制能力 |
B |
DC |
|
(F)TSR-04 |
算法数据冗余备份，确保车辆控制正常启动 , 避免故障导致车辆控制失效 |
D |
DC |
|
|
|||
|
(F)HSR-04-01 |
配备额外的冗余数据存储模块，确保数据存储故障时车辆控制正常启动 |
B |
DC |
|
(F)HSR-04-02 |
配备额外的数据读取线路，确保数据读取线路故障时车辆控制正常启动 |
B |
DC |
|
(F)HSR-04-03 |
微控制器具备冗余读取启动模块，确保车辆控制正常启动 |
B |
DC |
|
(C)TSR-04 |
算法数据安全存储，确保车辆控制正常启动 , 避免网络攻击导致车辆控制失效 |
B |
DC |
|
|
|||
|
(C)HSR-04-01 |
具备硬件安全模块，采用安全的密钥存储机制，确保数据不被篡改 |
B |
DC |
|
(C)HSR-04-02 |
具备身份验证与权限管理模块，确保算法数据不被恶意植入病毒软件 |
B |
DC |
|
(C)HSR-04-03 |
配备额外的数据安全存储模块，确保数据不会丢失，车辆控制正常启动 |
B |
DC |
|
(F)TSR-05 |
应实时检测控制器故障状态，确保车辆控制正常运行 , 避免故障导致车辆控制失效 |
D |
DC |
|
|
|||
|
(F)HSR-05-01 |
实时检测电源管理模块故障状态，确保微控制器正常供电 |
D |
DC |
|
(F)HSR-05-02 |
实时检测时钟模块故障状态，确保微控制器时钟信号稳定 |
D |
DC |
|
(F)HSR-05-03 |
实时检测微控制器存储模块故障状态，确保微控制器正常读写数据 |
D |
DC |
|
(F)HSR-05-04 |
实时检测微控制器输入输出接口故障状态，确保微控制器正常传输数据 |
D |
DC |
|
(F)HSR-05-05 |
实时检测微控制器核心处理模块故障状态，确保微控制器正常处理数据 |
D |
DC |
|
(C)TSR-05 |
应实时检测控制器网络攻击状态，确保车辆控制正常运行 , 避免网络攻击导致车辆控制失效 |
B |
DC |
|
|
|||
|
(C)HSR-05-01 |
实时检测电源管理模块攻击状态，确保微控制器正常供电 |
B |
DC |
|
(C)HSR-05-02 |
实时检测时钟模块攻击状态，确保微控制器时钟信号稳定 |
B |
DC |
|
(C)HSR-05-03 |
实时检测微控制器存储模块攻击状态，确保微控制器正常读写数据 |
B |
DC |
|
(C)HSR-05-04 |
实时检测微控制器输入输出接口攻击状态，确保微控制器正常传输数据 |
B |
DC |
|
(C)HSR-05-05 |
实时检测微控制器核心处理模块攻击状态，确保微控制器正常处理数据 |
B |
DC |
|
(F)TSR-06 |
车辆控制模块冗余与故障隔离设计，确保主控制模块故障时能够切换到冗余控制模块 |
D |
DC |
|
|
|||
|
(F)HSR-06-01 |
配置冗余的电源管理模块，主电源故障时切换至冗余模块，确保微控制器正常供电 |
B |
DC |
|
(F)HSR-06-02 |
配置冗余的时钟模块，主时钟故障时切换至冗余模块，确保微控制器时钟信号稳定 |
B |
DC |
|
(F)HSR-06-03 |
微控制器具备冗余的存储模块，主存储故障时切换至冗余模块，确保微控制器正常读写数据 |
B |
DC |
|
(F)HSR-06-04 |
微控制器具备冗余的输入输出接口，主输入输出接口故障时切换至冗余模接口，确保微控制器正常传输数据 |
B |
DC |
|
(F)HSR-06-05 |
微控制器具备冗余的核心处理模块，主核心处理故障时切换至冗余模块，确保微控制器正常处理数据 |
B |
DC |
|
(F)HSR-06-06 |
车辆控制冗余模块独立于主模块进行设计，进行故障隔离设计 |
B |
DC |
|
(C)TSR-06 |
车辆控制模块防护、冗余与安全隔离设计，确保主控制模块遭到网络攻击时能够切换到冗余控制模块 |
B |
DC |
|
|
|||
|
(C)HSR-06-01 |
配置电源滤波与稳压电路，保护电源免受干扰攻击，配置冗余的电源管理模块，主电源遭到攻击时切换至冗余模块，确保微控制器正常供电 |
B |
DC |
|
(C)HSR-06-02 |
时钟信号线路采用屏蔽措施，配备备用时钟源，并设计时钟校准电路，主时钟组件遭到攻击时切换至冗余模块，确保微控制器时钟信号稳定 |
B |
DC |
|
(C)HSR-06-03 |
集成硬件加密模块，保护存储组件免受网络攻击，微控制器具备冗余的存储模块，主存储遭到攻击时切换至冗余模块，确保微控制器正常读写数据 |
B |
DC |
|
(C)HSR-06-04 |
关键的通信接口，采用物理隔离技术，保护通信接口免受网络攻击，主通信接口遭到攻击时切换至冗余模接口，确保微控制器正常传输数据 |
B |
DC |
|
(C)HSR-06-05 |
车辆控制冗余模块独立于主模块进行设计，进行网络安全隔离设计 |
B |
DC |
|
(S)TSR-02 |
提高控制器的运行能力 ：采用更 高性能 的 处理器 ， 实时准确进行车辆控制，确保车辆控制的高效 |
D |
DC |
|
|
|||
|
提升微控制器处理能力 |
|||
|
|
|||
|
(S)HSR-02-01 |
选择更高主频的微控制器，以满足复杂控制算法和大量数据处理的需求 ； 采用具有多核心或多线程处理能力的微控制器，提高系统的并行处理能力 |
D |
DC |
|
(S)HSR-02-02 |
配置足够大的高速缓存，以减少 CPU 访问内存的时间，提高数据读取和写入的速度 |
D |
DC |
|
提升微控制器存储容量 |
|||
|
|
|||
|
(S)HSR-02-03 |
根据控制程序和数据的规模，选择具有足够闪存容量的微控制器 ；考虑具有闪存扩展接口的微控制器，以便在需要时可以通过外部闪存芯片进一步扩展存储容量，满足系统不断升级和数据量增长的需求 |
D |
DC |
|
(S)HSR-02-04 |
确保微控制器具有足够的 RAM 容量，以保证数据的临时存储和快速访问； 选择具有动态内存管理功能的微控制器，能够根据任务的需求自动分配和回收内存，提高内存的使用效率，避免内存泄漏和数据溢出 |
D |
DC |
|
提升微控制器通讯传输能力 |
|||
|
|
|||
|
(S)HSR-02-05 |
确保微控制器的通信接口与外部设备和传感器的接口类型完全匹配，具备多种常见的接口类型 |
D |
DC |
|
(S)HSR-02-06 |
微控制器应具备可灵活配置通信速率的功能，能够与外部设备进行速率匹配，确保数据传输的稳定性和准确性 |
D |
DC |
|
提升微控制器供电电压稳定 |
|||
|
(S)HSR-02-07 |
微控制器配备高性能的电源管理芯片，能够提供稳定的电压输出 ，保证微控制器的正常工作 |
D |
DC |
|
提升微控制器时钟精度 |
|||
|
(S)HSR-02-08 |
选用具有高精度时钟源控制器，满足各种定时任务和控制周期的要求 |
D |
DC |
|
(S)TSR-03 |
车辆控制模块应具备较高的鲁棒性，确保车辆控制在多工况下保持有效 |
D |
DC |
|
|
|||
|
提升微控制器供电稳定 |
|||
|
|
|||
|
(S)HSR-03-01 |
增加电源滤波器、共模扼流圈等元件，提高电源对电磁干扰的抑制能力 |
D |
DC |
|
(S)HSR-03-02 |
根据微控制器及其外设的最大功耗需求，选择具有至少 30% 功率裕量的电源模块 ，确保在高负载情况下能稳定供电 |
D |
DC |
|
提升微控制器时钟稳定 |
|||
|
|
|||
|
(S)HSR-03-03 |
对时钟信号进行良好的屏蔽和隔离，防止受到其他信号的干扰 |
D |
DC |
|
(S)HSR-03-04 |
通过专用的时钟同步芯片或利用微控制器的定时器和通信接口实现时钟同步，确保各微控制器之间的时钟偏差足够小 |
D |
DC |
|
提升微控制器抗干扰能力 |
|||
|
|
|||
|
(S)HSR-03-05 |
对微控制器和关键电路进行电磁屏蔽，使用金属屏蔽罩或电磁屏蔽涂料，提高系统的抗干扰能力 |
D |
DC |
|
(S)HSR-03-06 |
设计静电防护电路，保护微控制器的接口和内部电路免受静电冲击 |
D |
DC |
|
(F)TSR-0 7 |
应实时监控整个系统的故障状态，发生故障时采取相应的降级措施 |
D |
DC |
|
|
|||
|
( F )HSR-0 7-01 |
配置实时检测收集各传感器的故障状态的模块，发生故障时采取相应的降级措施 |
D |
DC |
|
(F)HSR-07-0 2 |
配置实时检测收集 控制器组件的 故障状态的模块，发生故障时采取相应的降级措施 |
D |
DC |
|
(F)HSR-07-0 3 |
配置实时检测收集 各执行器的 故障状态的模块，发生故障时采取相应的降级措施 |
D |
DC |
|
(F)HSR-07-04 |
配置实时检测收集各 通讯 的故障状态的模块，发生故障时采取相应的降级措施 |
D |
DC |
|
( C )TSR-0 7 |
应实时监控整个系统的网络攻击状态，发生网络攻击时采取相应的降级措施 |
B |
DC |
|
|
|||
|
( C )HSR-0 7-01 |
配置实时检测收集各传感器的 网络攻击 状态的模块，发生故障时采取相应的降级措施 |
B |
DC |
|
(C)HSR-07-0 2 |
配置实时检测收集控制器组件的网络攻击状态的模块，发生故障时采取相应的降级措施 |
B |
DC |
|
(C)HSR-07-0 3 |
配置实时检测收集各执行器的网络攻击状态的模块，发生故障时采取相应的降级措施 |
B |
DC |
|
(C)HSR-07-04 |
配置实时检测收集各通讯的网络攻击状态的模块，发生故障时采取相应的降级措施 |
B |
DC |
|
( S )TSR-0 4 |
设计一套独立的备份横向控制系统，当主系统出现故障或控制异常时，备份系统能够迅速接管车辆的横向控制，确保车辆的行驶安全 |
D |
DC |
|
|
|||
|
(S)HSR-0 4-01 |
配置实时 评估系统 状态的模块，发生 异常 时 能够迅速 采取相应的降级措施 |
D |
DC |
|
(S)HSR-04-0 2 |
配置实时 降级处理 的模块，发生异常时能够迅速采取相应的降级措施 |
D |
DC |
|
(F)TSR-0 8 |
实时对车辆控制信息 进行 检测，确保控制信息通讯真实可靠 , 避免 控制 故障导致车辆控制失效 |
D |
DC |
|
|
|||
|
(F)HSR-0 8-01 |
实时对车辆控制信息通讯进行故障检测，确保车辆控制信息通讯正常 |
D |
DC |
|
(F)HSR-08-0 2 |
实时对车辆 控制 模块进行故障检测，确保车辆控制正常 |
D |
DC |
|
(C)TSR-0 8 |
实时对车辆控制信息进检测，确保控制信息通讯真实准确 , 避免定位遭到网络攻击导致车辆控制失效 |
B |
DC |
|
|
|||
|
(C)HSR-0 8-01 |
实时对车辆控制信息通讯进行网络攻击检测，确保车辆控制信息通讯正常 |
B |
DC |
|
(C)HSR-08-0 2 |
配备硬件加密模块，对车辆控制信息进行加密传输，保护通讯安全 |
B |
DC |
|
(C)HSR-08-0 3 |
实时对车辆控制模块进行网络攻击检测，确保车辆控制正常 |
B |
DC |
|
(S)TSR-0 5 |
采用高速传输通讯方式，确保车辆控制信息传输实时可靠，避免车辆控制通讯不足导致车辆控制失效 |
D |
DC |
|
|
|||
|
(S)HSR-0 5-01 |
配备高速的传输接口，确保车辆控制信息通讯高速传输 |
D |
DC |
|
(S)HSR-0 5-02 |
采用高传输速率的通讯协议，确保车辆控制信息通讯高速传输 |
D |
DC |
|
(S)HSR-05-0 3 |
微控制器应具备高速接发传输的通讯能力 |
D |
DC |
|
(F)TSR-0 9 |
车辆控制 信息传输通道冗余与故障隔离设计，确保主通道故障时能够切换到冗余通道 |
D |
DC |
|
|
|||
|
( F )HSR-0 9-01 |
设计独立的冗余通信通道，包括 CAN 绞线、 CAN 收发器以及 CAN 控制器 |
B |
DC |
|
(F)HSR-09-0 2 |
通信通道应具备故障隔离功能，防止主通道故障影响冗余通道 |
D |
DC |
|
(F)HSR-09-0 3 |
微控制器具备多 CAN 通道接口，满足 CAN 通讯冗余设计 |
D |
DC |
|
(C)TSR-0 9 |
车辆控制 信息传输通道冗余设计与安全 防护 设计，确保主通道遭到网络攻击时能够切换到冗余通道 |
B |
DC |
|
|
|||
|
( C )HSR-0 9-01 |
通讯接口应具备良好的抗干扰能力，减少物理网络攻击对通讯的影响 |
B |
DC |
|
( C )HSR-09-0 2 |
配备硬件加密模块，对定位信息进行加密传输，保护通讯安全 |
B |
DC |
|
( C )HSR-09-0 3 |
微控制器具备多 CAN 通道接口，满足 CAN 通讯冗余设计 |
B |
DC |
|
(F)TSR- 10 |
应实时监控线控转向系统的故障状态，发生故障时采取相应的降级措施 |
D |
DC |
|
|
|||
|
( F )HSR- 10-01 |
应实时监控线控转向系统 电源模块 故障状态，发生故障时采取相应的降级措施 |
D |
DC |
|
(F)HSR-10-0 2 |
应实时监控线控转向系统 ECU 模块故障状态，发生故障时采取相应的降级措施 |
D |
DC |
|
(F)HSR-10-0 3 |
应实时监控线控转向系统 电机 模块故障状态，发生故障时采取相应的降级措施 |
D |
DC |
|
(F)HSR-10-04 |
应实时监控线控转向系统 通讯 模块故障状态，发生故障时采取相应的降级措施 |
D |
DC |
|
(F)HSR-10-05 |
应实时监控线控转向系统 传感器 模块故障状态，发生故障时采取相应的降级措施 |
D |
DC |
|
(C)TSR- 10 |
应实时监控线控转向系统的网络攻击状态，发生网络攻击时采取相应的降级措施 |
B |
DC |
|
|
|||
|
(C)HSR-10-01 |
应实时监控线控转向系统 电源模块 的网络攻击状态，发生网络攻击时采取相应的降级措施 |
B |
DC |
|
( C )HSR- 10-02 |
应实时监控线控转向系统 CAN 通讯模块 的网络攻击状态，发生网络攻击时采取相应的降级措施 |
B |
DC |
|
(C)HSR-10-0 3 |
应实时监控线控转向系统的 ECU 网络攻击状态，发生网络攻击时采取相应的降级措施 |
B |
DC |
基于原始的硬件架构，根据所导出的硬件安全要求，对原来的硬件架构重新进行修改与设计，来达到硬件安全要求，进一步实现技术安全要求。对于硬件架构设计，采取硬件安全要求的模块进行红框圈出，并标注来源，其中（ F ） -01-01 、（ S ） -01-01 、（ C ） -01-01 分别代表（ F ） HSR-01-01 、（ S ） HSR-01-01 、（ C ） HSR-01-01 ，硬件融合安全架构设计如下所示。
输入端原硬件架构：
输入端融合安全硬件架构：
控制 端原硬件架构：
控制端 融合安全硬件架构 硬件架构：
输 出 端原硬件架构：
输出端 融合安全 硬件架构：
硬件详细设计过程是硬件架构的具体设计实现过程，本案例仅对输入端融合安全硬件架构进行详细硬件设计。对于处理器中的硬件安全要求，通讯异常检测以及定位模块异常检测以及其他措施视为安全机制 2 ， CAN 通讯的冗余设计视为安全机制 1 ，对于安全机制 2 不进行详细的设计，仅对安全机制 1 进行详细设计。 CAN 通讯冗余设计如下图所示。
其中：
完成两条独立的 CAN 通道设计来满足安全冗余设计；
冗余模块进行安全隔离设计来实现故障隔离与切换；
TJA1462CAN 收发器来满足 CAN FD 高速通讯；
MCU 的 CAN FD 控制器来满足 CAN FD 高速通讯；
MCU 的多 CAN FD 通道来满足冗余设计；
限流、稳压、滤波处理电路来满足物理隔离通信；
PTC 对通讯输入进行限制电流，保护收发器不因电流过大损坏；
TVS 对通讯输入进行限制电压，保护收发器不因电压过大损坏；
C\L 对通讯输入进行滤波，提高差分信号的质量；
R 使得 CAN 通讯的阻抗平衡，防止信号反射，提高差分信号质量。
完成硬件设计后，需要对硬件的整体的架构设计进行安全评估，来评估硬件架构对随机失效的有效性，并且用于补充对随机硬件失效故障导致违背安全要求的评估。对硬件架构进行安全分析，首先分析硬件架构中个元器件的失效率、失效模式及分布与安全相关的失效判断，其次根据是否采取安全机制来判断失效故障为单点故障或者是残余故障，最后对失效故障是否能够被检测或者感知来判断是否为潜伏故障。硬件安全分析，为硬件架构安全度量评估提供依据。
元器件的失效率以及失效模式与分布均借鉴于功能安全标准中的附件示例，是否为安全相关的判断准则为是否会影响到功能的正常使用，对于硬件设计中的一些保护措施，只要失效后不影响正常功能，则认为与安全不相关。
|
元器件 |
失效率（ FIT ） |
失效模式 |
失效模式分布 |
是否为安全相关 |
|
R1 R2 |
2 |
开路 |
35% |
是 |
|
短路 |
35% |
|||
|
偏移 |
30% |
|||
|
PTC1 PTC2 PTC3 PTC4 |
2 |
开路 |
35% |
是 |
|
短路 |
35% |
否 |
||
|
偏移 |
30% |
是 |
||
|
TVS1 TVS2 TVS3 TVS4 |
2 |
开路 |
40% |
否 |
|
短路 |
60% |
是 |
||
|
C1 C2 C3 C4 |
2 |
开路 |
20 % |
是 |
|
短路 |
70% |
|||
|
偏移 |
10% |
|||
|
L1 L2 L3 L4 |
2 |
开路 |
60 % |
是 |
|
短路 |
40% |
|||
|
U1(MCU) |
100 |
CAN 失效 |
40% |
是 |
|
其他 |
60 % |
否 |
||
|
U2(TJA1462) U3(TJA1462) |
20 |
CAN 丧失 |
40% |
是 |
|
CAN 错误 |
60 % |
单点故障判断条件：失效模式违背功能安全目标，且没有安全机制。
残余故障判断条件：失效模式违背功能安全目标，且至少有一个安全机制预防器违背安全目标 。
硬件采取硬件电路冗余并且进行通讯异常检测，因此 CAN 通讯通道上的元器件不存在单点故障，且通过硬件冗余以及故障异常检测的硬件安全机制下，安全机制覆盖率为 99% 。
|
元器件 |
失效率（ FIT ） |
失效模式 |
失效模式分布 |
是否为安全相关 |
是否为单点故障 |
是否为残余故障 |
|
R1 R2 |
2 |
开路 |
35% |
是 |
否 |
是 |
|
短路 |
35% |
否 |
是 |
|||
|
偏移 |
30% |
否 |
是 |
|||
|
PTC1 PTC2 PTC3 PTC4 |
2 |
开路 |
35% |
是 |
否 |
是 |
|
短路 |
35% |
否 |
否 |
否 |
||
|
偏移 |
30% |
是 |
否 |
是 |
||
|
TVS1 TVS2 TVS3 TVS4 |
2 |
开路 |
40% |
否 |
否 |
否 |
|
短路 |
60% |
是 |
否 |
是 |
||
|
C1 C2 C3 C4 |
2 |
开路 |
20 % |
是 |
否 |
是 |
|
短路 |
70% |
否 |
是 |
|||
|
偏移 |
10% |
否 |
是 |
|||
|
L1 L2 L3 L4 |
2 |
开路 |
60 % |
是 |
否 |
否 |
|
短路 |
40% |
否 |
是 |
|||
|
U1(MCU) |
100 |
CAN 失效 |
40% |
是 |
否 |
是 |
|
其他 |
60 % |
否 |
否 |
否 |
||
|
U2(TJA1462) U3(TJA1462) |
20 |
CAN 丧失 |
40% |
是 |
否 |
是 |
|
CAN 错误 |
60 % |
否 |
是 |
通常 认为超过双点以上的故障为安全故障，所以在本例中只分析双点故障，而双点故障包括了可探测的双点故障，可感知的双点故障，潜伏的双点故障。
双点故障判断条件：与另一个独立失效组合，是否违背安全目 。
如果故障可以被安全机制探测，则为可探测的双点故障 。
如果故障在规定时间内可以被驾驶员感知，则为可感知的双点故障 。
如果故障既不可探测，也不可感知，则故障为潜伏的双点故障。
硬件采取硬件电路冗余并且进行通讯异常检测， CAN 通讯通道上的元器件发生与安全相关的故障都能够被检测到，因此该 CAN 通讯不存在潜伏故障，因此总潜伏故障率为 0 。
完成硬件安全分析后，进行硬件设计安全度量，来评估采取安全机制后的硬件设计是否能够达到安全要求中汽车完整性的等级的要求，通过两个评估指标来判断是否达到要求，一个是单点故障度量与多点潜伏故障度量指标，另外一个为随机硬件失效度量指标，只有在两个度量指标均达到的条件下，所涉及的硬件架构才符合安全目标，在其他情况下，均需要对所设计的硬件架构重新制定额外的安全机制，然后再重新进行安全分析以及安全度量评估，直到达到度量指标要求为止，否则重复进行设计。
单点故障率 = 失效率 * 失效模式分布
残余故障率 = 失效率 * 失效模式分布 * （ 1 - 安全机制覆盖率）
|
元器件 |
失效率（ FIT ） |
失效模式 |
失效模式分布 |
是否为安全相关 |
是否为单点故障 |
单点故障率 |
是否为残余故障 |
安全机制覆盖率 |
残余故障率 |
|
R1 R2 |
2 |
开路 |
35% |
是 |
否 |
NA |
是 |
99% |
0.007 |
|
短路 |
35% |
否 |
NA |
是 |
99% |
0.007 |
|||
|
偏移 |
30% |
否 |
NA |
是 |
99% |
0.006 |
|||
|
PTC1 PTC2 PTC3 PTC4 |
2 |
开路 |
35% |
是 |
否 |
NA |
是 |
99% |
0.007 |
|
短路 |
35% |
否 |
否 |
NA |
否 |
NA |
NA |
||
|
偏移 |
30% |
是 |
否 |
NA |
是 |
99% |
0.006 |
||
|
TVS1 TVS2 TVS3 TVS4 |
2 |
开路 |
40% |
否 |
否 |
NA |
否 |
NA |
NA |
|
短路 |
60% |
是 |
否 |
NA |
是 |
99% |
0.012 |
||
|
C1 C2 C3 C4 |
2 |
开路 |
20 % |
是 |
否 |
NA |
是 |
99% |
0.004 |
|
短路 |
70% |
否 |
NA |
是 |
99% |
0.014 |
|||
|
偏移 |
10% |
否 |
NA |
是 |
99% |
0.002 |
|||
|
L1 L2 L3 L4 |
2 |
开路 |
60 % |
是 |
否 |
NA |
否 |
NA |
NA |
|
短路 |
40% |
否 |
NA |
是 |
99% |
0.008 |
|||
|
U1(MCU) |
100 |
CAN 失效 |
40% |
是 |
否 |
NA |
是 |
99% |
0.4 |
|
其他 |
60 % |
否 |
否 |
NA |
否 |
NA |
NA |
||
|
U2(TJA1462) U3(TJA1462) |
20 |
CAN 丧失 |
40% |
是 |
否 |
NA |
是 |
99% |
0.08 |
|
CAN 错误 |
60 % |
否 |
NA |
是 |
99% |
0.12 |
|||
|
失效率总和 |
176 |
NA |
NA |
NA |
NA |
0 |
NA |
NA |
0.852 |
|
总失效率 176 FIT 总安全相关 110 FIT 总非安全相关 66 FIT 单点故障度量计算公式： 1- (( 总单点故障率 + 总残余故障率） / 安全相关故障率 ) 单点故障度量 = 1-(0+0.852)/110=99.23% 潜伏故障度量计算公式： 1- (( 总潜伏故障率） / 安全相关故障率 - 总单点故障率 - 总潜伏故障率 ) 潜伏故障度量 = 1-[0/(116-0.852)]=100% |
|||||||||
单点故障度量与多点潜伏故障度量指标：
|
|
ASIL D |
|
单点故障度量 |
≥ 99% |
|
潜伏故障度量 |
≥ 90% |
根据标准中对于 ASIL D 的要求，很容易得出结论单点故障指标与潜伏故障指标均符合功能安全目标，所采取的安全机制能够满足安全要求。
对于处理器中的硬件安全要求，通讯异常检测以及定位模块异常检测以及其他措施视为安全机制 2 ， CAN 通讯的冗余设计视为安全机制 1 。通过对预期功能 IF 以及安全机制 SM1 单点故障率、残余故障率、潜伏故障率以及可探测多点故障的分析，来度量随机硬件失效。预期功能 IF 以及安全机制 SM1 的失效率为单通道 CAN 通讯的总和故障率，失效模式分为安全、丧失以及错误，不安全下的失效分布总和为各部件的安全相关失效率之和与总失效率的比值。不安全下的失效分布和为 55% ，现在假设丧失分布 25% ，错误分布 30% 。随机硬件失效度量分析如下所示。
|
组件名 |
失效率 FIT |
失效模式 |
失效模式分布 |
安全机制缺失导致失效模式可能违背安全目标 |
安全机制 SM 阻止失效模式违背安全目标 |
违背安全目标的失效模式诊断覆盖率 |
残余或单点故障失效率 |
双点故障失效率 |
描述 |
阻止失效模式成为潜伏故障的探测方法或安全机制 |
对于潜伏失效的失效模式覆盖率 |
潜伏多点故障失效率 |
描述 |
可探测多点故障失效率 |
描述 |
|
IF |
138 |
安全 |
45% |
|
|
|
|
|
|
|
|
|
|
|
|
|
丧失 |
25% |
是 |
SM1 |
99% |
0.345 |
34.155 |
λ IF,DPE,secondary |
SM1 |
100% |
0 |
λ IF,DPE,latent,secondary |
34.155 |
λ IF,DPE,detected,secondary |
||
|
错误 |
30% |
是 |
SM1 |
99% |
0.414 |
40.986 |
λ IF,DPE,primary |
SM1 |
100% |
0 |
λ IF,DPE,latent,primary |
40.986 |
λ IF,DPE,detected,primary |
||
|
SM1 |
138 |
安全 |
45% |
|
|
|
|
|
|
|
|
|
|
|
|
|
丧失 |
25% |
是 |
SM2 |
99% |
0.345 |
34.155 |
λ SM1,DPE,secondary |
SM2 |
100% |
0 |
λ SM1,DPE,latent,secondary |
34.155 |
λ SM1,DPE,detected,secondary |
||
|
错误 |
30% |
是 |
SM2 |
99% |
0.414 |
40.986 |
λ SM1,DPE,primary |
SM2 |
100% |
0 |
λ SM1,DPE,latent,primary |
40.986 |
λ SM1,DPE,detected,primary |
λ SPR + λ RF = 0.345 + 0.414 + 0.345 + 0.414 = 1.518 FIT
λ IF,DPE = λ IF,DPE,primary + λ IF,DPE,secondary = 34 . 155 + 40.986 = 75.141 FIT
λ SM1,DPE = λ SM1,DPE,primary + λ SM1,DPE,secondary = 34 . 155 + 40.986 = 75.141 FIT
λ IF,DPE,latent = λ IF,DPE,latent,primary + λ IF,DPE,latent,secondary = 0 + 0 = 0 FIT
λ SM1,DPE,latent = λ SM1,DPE,latent,primary + λ SM1,DPE,latent,secondary = 0 + 0 = 0 FIT
λ IF,DPE,detected = λ IF,DPE,detected,primary + λ IF,DPE,detected,secondary = 34 . 155 + 40.986 = 75.141 FIT
λ SM1,DPE,detected = λ SM1,DPE,detected,primary + λ SM1,DPE,detected,secondary = 34 . 155 + 40.986 = 75.141 FIT
现假设整车生命周期为 10000h, 驾驶员被告知后去维修的预计时间为 20h, 则：
M PMHF = λ SPR + λ RF
+ 0.5 × λ SM1,DPE,latent × λ IF,DPE × T lifetime
+ λ SM1,DPE,detected × λ IF,DPE × T service
+ 0.5 × λ IF,DPE,latent × λ SM1,DPE × T lifetime
+ λ IF,DPE,detected × λ SM1,DPE × T service
= 1.518 FIT
+ 0.5 × 0 FIT × 75.141 FIT × 10000 h
+ 75.141 FIT × 75.141 FIT × 20 h
+ 0.5 × 0 FIT × 75.141 FIT × 10000 h
+ 75.141 FIT × 75.141 FIT × 20 h
= 1.518 FIT + 0 FIT + 0.00012923 FIT + 0 FIT + 0.00012923 FIT
= 1.518 FIT + 0.000258 FIT
= 1.518258 FIT = 1.518258 10 -9 /h
随机硬件失效目标值 :
|
ASIL 等级 |
随机硬件失效目标值 |
|
D |
< 10 -8 /h |
|
C |
< 10 -7 /h |
|
B |
< 10 -6 /h |
1.518258 10 -9 /h <10 -8 /h ，随机硬件失效指标达到随机硬件失效目标值，该安全机制满足 ASIL D 的安全目标。
进过单点故障度量与多点潜伏故障度量和随机硬件失效度量的硬件架构评估度量可知，所设计的硬件架构满足 ASIL D 的安全目标，因此该硬件架构足够安全，无需在采取额外的安全机制。