登陆

基于功能安全的车载计算平台开发：硬件层面

来源：智车Robot ，作者Bruce Jiang

2022-12-14

作为车载智能计算平台功能软件与系统软件的载体，硬件的失效可能直接导致功能软件输出不可信任的结果，从而违背安全目标。由于硬件故障在硬件生命周期中发生时间的随机性，在通过改善流程降低系统性失效的同时，ISO 26262功能安全标准在硬件层面重点关注识别安全相关的硬件故障以及采取安全机制诊断相应硬件故障，并发现的硬件故障进行处理（例如进入安全状态），从而将硬件随机失效对安全目标的影响降低到可接受的程度。

01 硬件架构设计

由于现有关键器件的功能安全能力的局限性与ASIL D系统对单点失效度量的严格要求，硬件冗余是实现高功能安全等级安全目标的常见方式。冗余式硬件架构的主体是通过对冗余计算单元输出结果的相互校验达到提高计算单元硬件故障诊断覆盖率的目的。由于对相互冗余系统的独立性要求，相互冗余的系统需尽可能的避免由同源输入、共用资源、环境影响等因素引起的共因失效。

功能安全在硬件层面，关注硬件器件中的安全相关故障可以通过自检或外部监控的方式被检测到，并在故障容忍时间内实现安全状态。硬件器件实现安全状态的方式多为重启、断电、报错、禁言等，因此单硬件通路的硬件架构可以满足Fail-Safe概念的需求。根据车载智能计算硬件平台所承载功能与功能安全要求分配的不同，AI单元、计算单元与控制单元所选用的芯片可通过单器件或冗余的方式实现相应的功能安全等级。

单硬件通路Fail-Safe抽象硬件架构示例

随着自动驾驶的发展，Fail-Safe的安全策略难以满足高级别自动驾驶的安全要求。基于L3以上自动驾驶功能对系统Fail-Operational的需求，越来越多的车载智能计算平台在主通路实现ASIL C-ASIL D的基础上增加与主通路相互监控的Fail-Operational通路，实现主通路失效情况下硬件层面的失效可操作性，以提高系统的安全性和可用性。需要注意的是，根据自动驾驶功能等级对Fail-Operational系统在主通路失效情况下需要完成的紧急运行模式的不同，Fail-Operational通路所包含的硬件单元可能会有所差异。

多硬件通路Fail-Operational抽象硬件架构示例

诊断覆盖率指的是硬件要素失效率中，由实施的安全机制探测或控制的失效率所占的比例。由该定义直接评估诊断覆盖率，需要基于大量的硬件随机失效事件考察安全机制的有效性，实际操作中很难实现。一般情况下，对诊断覆盖率分为三个等级：Low（60％）、Medium（90％）和High（99％）。基于ISO 26262，提供以下两种较为简单的确定诊断覆盖率的方法。

1、基于能够探测的失效模式

一个典型的系统（包含传感器、控制器、执行器）硬件要素如图所示。

常见系统硬件

对于硬件要素来说，其失效模式分布呈一定的统计规律。基于硬件要素的失效模式分布，能够诊断某些失效模式或失效模式的组合，得出相应的诊断覆盖率（DC, Diagnostic Coverage）。针对图5-20所示系统所含硬件要素，低诊断覆盖率（Low DC）、中诊断覆盖率（Medium DC）和高诊断覆盖率（High DC）三种不同的诊断覆盖率与其所需要能够覆盖的失效模式如表。

系统硬件要素失效模式与诊断覆盖率

A、卡滞是一个故障类型,可以描述为要素针脚上持续的“0” “1”或者“打开”。该故障只针对具有要素层针脚接口的要素才是有效的。

B、直流故障模型包含下列失效模式:卡滞故障、卡滞开路、开路或者高阻抗输出,以及信号线间的短路。这里的意图不是一定需要全面的分析,比如要求对于微控制器内或者来自于一个复杂的PCB板上任何理论可能的信号组合的桥接故障进行详尽的分析。分析着重于主要信号或者在布局层面分析中识别出的高度耦合互连。

C、“软错误模型”:软错误(比如位翻转)是由封装衰变的α粒子或者中子等引起的瞬态故障的结果。这些瞬态故障也就是单粒子翻转(SEU)和单粒子瞬态(SET)。

2、基于采用的安全机制

根据对硬件要素采用的安全机制，ISO 26262同样给出了可供参考的诊断覆盖率。例如：针对传感器，若只采用短电源、短地诊断，诊断覆盖率为Low；若采用双冗余传感器做相互校验，诊断覆盖率为high。

ISO 26262 Part5 传感器安全机制与诊断覆盖率

根据能够覆盖的失效模式与根据采用的安全机制评估诊断覆盖率，双方并无本质的不同。上表中安全机制与诊断覆盖率的关联，其背后逻辑依然是安全机制—能够覆盖的失效模式—失效模式分布。

诊断覆盖率的评估方法适用场景

02 随机失效概率量化指标

根据硬件故障对安全目标产生影响的不同，硬件故障可分为安全相关故障与非安全相关故障，其中安全相关故障又进一步分为单点故障、残余故障、多点可探测故障、多点可感知故障、多点潜伏故障与安全故障。其中，单点故障和残余故障可以直接导致安全目标的违背。

多点潜伏故障虽然不会单独导致安全目标的违背，但可能会在与其它故障同时发生时导致安全目标的违背。因此用于表示单点故障与残余故障诊断覆盖率的SPFM（Single-Point Fault Metric，单点故障度量），多点潜伏故障诊断覆盖率的LFM（Latent Fault Metric，潜伏故障度量）与PMHF（Probabilistic Metric for random Hardware Failures，随机硬件失效概率度量）是功能安全用于衡量随机硬件失效率是否达到可接受程度的重要衡量指标。针对于不同的功能安全等级，ISO 26262针对上述指标给出了参考性量化目标。下列数值是广泛应用于业界评估安全系统是否满足相应功能安全等级的重要指标。

硬件随机失效度量参考量化目标

“单点故障度量”和“潜伏故障度量”计算示例，如下图的系统在一个ECU中实现了两个功能。

“单点故障度量”和“潜伏故障度量”计算示例

功能1有一个输入(通过传感器R3测量温度)和一个输出(通过I71控制阀2),功能1的表现是当温度高于90℃时打开阀2。

如果没有电流经过I71,阀2打开。

相关联的安全目标1是“当温度高于100℃时关闭阀2的时间不得长于x ms”。安全目标被分配为ASILB。安全状态是:阀2打开。

微控制器的ADC读取传感器R3的值。R3的电阻值随着温度升高而减小。该输入没有监控。控制T71的输出级由模拟输入InADC1(表中的安全机制SM1)来监控。在这个例子中,假设安全机制SM1能够对T71违背安全目标的某些失效模式的探测提供90%的诊断覆盖率。如果SM1探测到失效,安全状态被激活但是没有点灯。因此,声明针对潜伏故障的诊断覆盖率只有80%(驾驶员将通过功能降级获悉失效)。

功能2有两个输入(通过传感器I1和I2生成脉冲来测量轮速)和一个输出(通过I61控制阀1),功能2的表现是当车速高于90km/h时打开阀1。

如果没有电流经过I61,阀1打开。

相关联的安全目标2是“当速度超过100km/h时阀1的关闭时间不得长于y ms”。安全目标被分配为ASIL C。安全状态为:阀1打开。

微控制器读取I1和I2的脉冲值。通过这些传感器给出的平均值计算轮速。安全机制2(表中的安全机制SM2)比较两个输入。它对每个输入的失效探测达到99%的诊断覆盖率。如果出现不一致,输出1设为0。阀1打开(晶体管电压为“0”则打开栅极。I61电压为“0”则打开阀1)。因此,99%可能导致违背安全目标的故障能被探测到并且进入安全状态。当安全状态被激活时,灯L1点亮。因此,这些故障是100%能被察觉的。剩下的1%的故障是残余故障而不是潜伏故障。

控制T61的输出级被模拟量输入InADC2(表中的安全机制SM3)监控。轮速由该传感器给出的平均值计算得到。

微控制器没有内部冗余。如果不具备关于复杂元器件的安全故障比例的详细信息,可假定安全故障的保守比例为50%,并假定通过内部自检和外部看门狗(表中的安全机制SM4)达到对违背安全目标的总体覆盖率为90%。看门狗通过微控制器的输出0得到喂狗信号。当看门狗不再被刷新,其输出变低。SM4(看门狗和微控制器自检)提供的故障探测把这两个功能切换到它们的安全状态并点亮L1。因此,针对潜伏故障的诊断覆盖率声称是100%。

L1是仪表板上的一个LED灯,当探测到多点故障(其中只有一部分可以被探测到)时点亮它,并提示驾驶员功能1(打开阀1)的安全状态已被激活。

安全目标1中,安全机制对硬件要素的给定失效模式的覆盖率,称为“失效模式覆盖率”。

安全目标1

安全目标1被分配为ASIL B,对于ASIL B,单点故障度量推荐为≥90%,以及潜伏故障度量推荐为≥60%。单点故障度量的计算值为93.2%，表明此度量已被满足,同时潜伏故障度量的计算值为90%，表明潜伏故障度量也被满足。

安全目标2

安全目标2被分配为ASIL C,其中,单点故障度量要求≥97%;潜伏故障度量建议≥80%。单点故障度量的计算值为96.5%表明此度量未被满足,同时潜伏故障度量的计算值为91.6%表明潜伏故障度量得到满足。

03 关键器件的选型与集成

车载智能计算平台的硬件主要由AI单元、计算单元与控制单元组成。根据不同的架构需求，上述单元可由一个或多个芯片组成，芯片的种类可能包含GPU/FPGA/ASIC、SoC、MCU等。

芯片多采取SEooC开发模式。安全相关芯片供应商在提供产品的同时会提供给车载智能计算平台的系统集成者相应的安全使用手册。安全使用手册一般包含芯片供应商对系统功能安全要求的假设，可支持的最高功能安全等级，集成的安全机制以及实现承诺功能安全等级需要满足的假设条件。

车载智能计算平台选用的安全相关器件需要满足分配到该器件的技术安全要求。芯片通常会对内部处理单元、存储单元、通信总线、接口等元件提供相应的安全机制以满足安全相关故障的诊断覆盖率要求。除此之外，由于芯片的正常性能表现受限于一定的条件约束，保证时钟、温度、供电等在可操作范围内的安全机制也对功能安全的实现极为重要。车载智能计算平台需要按照各芯片厂商提供的安全手册搭建安全芯片外围电路和配置内部参数，确保芯片的安全内外部安全机制正常运行，从而在出现故障时能够及时进入安全状态。确保每个芯片正确集成的同时，还需确保集成后的硬件架构满足所有安全目标的随机失效概率量化指标要求。

处理单元

04 供电系统设计

电源是整车电子电气架构中最基础的共用资源。如若电源系统发生失效，则可能导致车载智能计算平台的所有功能失效，对于L3及以上自动驾驶系统是不可接受的风险。车载智能计算平台的供电系统需要满足Fail-Operational的要求，通常会采用双电源供电的方式。需要考虑双路电源供电有足够的隔离措施，确保一路供电出现故障（电压过高、过低甚至出现短路）时，另外一路供电不受影响。

为满足车载智能计算平台系统ASIL D的要求，车载智能计算平台的供电系统需要能够监控电源输入和输出是否存在异常，尤其是电源系统输出的监测和控制。若电源系统出现输出电压过高或过低故障时，车载智能计算平台内部的主芯片有可能会因为供电电压不稳而导致运算结果异常，最终导致违反安全目标。因此，电源系统需在输出电压异常时，及时关断对应的主芯片供电，确保车载智能计算平台输出为确定状态。

电源

05 通信系统设计

车载智能计算平台作为L3及以上自动驾驶的运算核心，通常通过专用的通信通道传输外界环境信息，而车载智能计算平台实现融合决策和车辆控制之后，将车辆运动控制指令通过通信总线发送至车辆的纵向和横向控制执行器。总线通信通道可能因为线束破损、外界电磁干扰和其他节点损坏等因素导致通信失效，包括报文丢失、报文延迟和报文篡改等多种类型的失效模式。采用多种安全监测工具的组合可以满足高诊断覆盖率的要求，但此种方法只能满足Fail-Safe的要求，即发现通信故障，但无法维持系统正常工作。为了实现L3自动驾驶功能Fail-Operation的要求，可采用硬件冗余的方式，一方面提高了诊断覆盖率，另一方面可满足Fail-Operation的要求。通信通道的冗余设计需要考虑二者的独立性，例如采用不同类型的通信协议（如CAN-FD和FlexRay），避免发生共因失效。

通信总线(串行,并行)

06 硬件测试

车载智能计算平台的硬件集成完成后，需要对硬件的安全性做全面的测试。硬件测试用例的导出方法包含硬件安全要求分析、内部及外部接口分析、等价类生成和分析、边界值分析等。硬件测试需要涵盖功能测试、故障注入测试、电气测试等测试方法来验证硬件安全要求的正确性和完整性，另外还需要涵盖最恶劣情况测试、超限测试、EMC测试和ESD测试等测试方法来验证车载智能计算平台硬件的鲁棒性和耐久性。测试完成后需要输出全面的测试报告作为硬件安全的佐证。

上一篇：基于功能安全的车载计算平台开发：软件层面下一篇：智能座舱域控制器技术发展趋势分析