一文讲透从IP层面如何实现汽车功能安全

如今，汽车行业变革迅猛，汽车的设计、使用和销售模式都在快速演变。驾驶员安全技术、交通拥堵、环境问题及汽车作为代步工具的基本前提都影响着新一代汽车的研发。为解决这些难题，很多汽车厂商都试图强化计算能力以优化车辆控制。

欧盟新车安全评鉴协会（EuroNCAP）颁布的新标准规定，车道变换支持等安全辅助功能是获得五星安全评级的必要条件。车载处理器的数量在所有细分市场都稳步上升，目前平均为40-50个，而一些高端车型则已经搭载近120个处理器。

据Semicast Research预测，到2022年，仅发动机引擎罩下的电子控制单元（ECU）组件就将达到近860亿美元的市场规模，相较2015年的530亿年复合增长率达到7%。半导体厂商将有机会在汽车电子领域挖掘一大桶金。

高科技芯片可以改善动力系统排放、增强安全性能、并利用蜂窝网络实现车辆间及道路基础设施之间的互联。但是，随着系统的复杂化，保证驾驶员安全就变得更为关键，必须打造更加自动化，系统化，且能患于未然的解决方案——即我们通常所称的“功能安全”。

什么是功能安全

简而言之，功能安全的最终目的是确保产品安全运行，即便出现问题也可以继续保驾护航。基于这一理念，ARM将保证安全视为头等大事，而非单纯依照市场导向随波逐流，不断加强研发，推出更多功能安全相关产品。

各行各业都会制定标准，指导未来发展并限定最低准入门槛。在汽车电子行业，这一标准就是ISO 26262，它将功能安全定义为：“避免因电气／电子系统故障而导致的不合理风险”。

不同领域的标准并不完全一致，例如针对电气和电子系统的IEC 61508以及飞行器电子硬件的DO-254都有各自的定义方式。更需值得注意的是，它们都拥有专用术语，并提供了包括目标参数在内的工程研发指导。因此，开始产品研发前确定目标市场并制定合适的流程至关重要，因为中途修改研发流程必然会导致效率低下。图1展示了硅片IP的不同应用标准。实际操作中，如果需要满足多套标准，则可以求同存异，先列出专属需求，再执行质量管理等通用准则；最一开始就要做到安全第一。

　　图1：硅片IP的功能安全标准

实际操作中，功能安全系统必须由独立评估员认证，符合所有安全标准。实现功能安全需要具备预测能力的故障模式，实时判断系统状态是功能完整、部分功能损坏、还是系统必须关闭进行重启或重置。

并不是所有故障都会立刻引发严重事故。比如，汽车动力转向系统故障可能会导致突发性的错误转向，但是由于电气和机械设计天然的时间延迟，故障并不会马上产生后果，这一延迟通常是几毫秒以上，ISO 26262将之定义为容错时间间隔，间隔长短取决于潜在的事故类型和系统设计。所以，不难理解，对系统安全要求越高，产生不安全事件的故障就越应该避免。

理想情况下，功能安全不会影响系统性能；但现实生活中，现行的许多安全措施都会严重影响系统性能、功率和面积（PPA）。如何在保证功能安全的前提下减轻对系统性能的不利影响以及设计制造成本的上升，是设计师们面临的一大难题。

为什么需要功能安全

芯片IP的功能安全曾是非常小众的领域，只有少数汽车、工业、航空航天和其他类似市场的芯片与系统开发商感兴趣。然而，随着过去几年各类汽车应用的兴起，情况已经发生巨大变化。除了汽车外，还有很多其他行业也能从电子器件的增加受益，当然保障功能安全是大前提。医疗电子和航空就是两个典型例子。

自动驾驶过去几年吸引了不少人的眼球，但一直是雾里看花；如今，随着高级驾驶辅助系统（ADAS）及富媒体车载信息娱乐系统（IVI）的普及，尽管高度自动化驾驶的时代依然遥远，但自动驾驶汽车的前景已变得愈发清晰，尺寸形状各异的无人机和日益普及的物联网也是亟需功能安全的领域，ARM 的技术将成为一大助力。

ARM功能安全技术

与其他技术市场一样，新兴的功能安全应用也需要半导体的驱动，这并不是纸上谈兵，日新月异的产品创新已经引起了ARM合作伙伴的浓厚兴趣。多数功能安全嵌入式系统都需要具备安全防护及实时处理两大核心要素，ARM Cortex-R系列处理器为此需求量身定制，为嵌入式系统提供高性能运算解决方案，确保产品的高可靠性、高可用性、容错、以及强大实时自主判断能力。这些特性为实现ADAS和IVI系统的高安全完整性打下基础，不仅可以执行关键行为处理，应对安全相关的中断事件，与其他系统通讯，还可以对集成度较低的复杂功能进行监管。

什么是故障？

故障可能是系统性的（如规范制定和设计过程中的人为因素），也有可能与使用的工具有关。减少故障的一种方法是执行严苛的质量管控流程，必须包括详细的规划、审查和量化评估。合理的规划使用工具认证非常重要，管理与追踪需求变更的能力也同样关键。ARM的Compiler 5编译器已经通过南德集团（TÜV SÜD）认证，助力安全研发，客户无需对编译器进行额外认证。

还有一种故障类型被称为随机硬件故障。它们可能是图2显示的永久性故障，比如短路；也有可能是由于天然辐射而造成的软性故障。这类故障可以利用集成在软硬件的方案进行处理，因此系统级的技术也同样重要。举例来说，逻辑内建自测试（BIST）可以应用于系统启动和关闭，区分软性和永久性故障。

　　图2：故障类型

应对措施

故障检测和控制措施的选择和设计是流程设计师最喜欢的环节，因为他们可以同时用系统级和微架构级的技术大展手脚。建立故障模式概念和效果分析（FMEA）是个不错的开始，列举出所有可能出现的故障模式及其后果的严重程度。有了这些信息，加上设计师对复杂系统的深入理解，即可鉴别出最严重的故障模式，并设计出应对措施。

应对潜在故障的方法较多，下面列出了一些最常用的技术：

1、多样化检查器：使用另一条电路检查主电路是否发生故障。举个例子，检查器可以为中断控制器计数，持续记录人为及系统引起的中断总数。

2、完整锁步复制：该技术主要用于Cortex-R5处理器，对一个IP元件（如一个处理器）进行多次实例化，利用循环产生操作延迟，生成时间和空间冗余。大容量存储通常由多个实例共享，以降低所需面积。尽管这一技术非常可靠，但也极为昂贵。

3、选择性硬件冗余：这个方案里，只有硬件的关键部分可以复制，如仲裁器。

4、软件冗余：硬件冗余通常非常复杂，而且会产生间接成本，是对资源的不合理使用。硬件运算的替代方法就是，在多个处理器内核上运行同一次计算，检查结果是否匹配。

5、错误检测和校正码是另一种为人熟知的技术，通常被用于保护存储器和总线。代码类型多种多样，但目标只有一个，既通过少量附加位获得更高冗余，无需复制所有底层数据。汽车系统中，这一尖端技术可以利用足够多的冗余检测出一个存储字的2位错误；并支持错误修正。

故障日志

检测出故障后就必须进行记录，以帮助监管软件判断系统的健康和安全状况。安全故障（如存储器修正）和危险故障（如不能挽回的硬件故障）必须分别记录。

故障记录通常从故障计数开始，可以由系统级架构记录有信号事件（类似于中断）的数量；或者由IP计数器记录。为了解这些事件发生的原因，最好还能将过去的事件作为参考，判断当前时间的发生原因。为支持这一需求并进行调试纠错，可以允许一些IP捕捉额外信息，如被侦查的存储地址。因为该地址通常会由软复位保存，所以可以在系统启动和系统自检过程中被读取。

有一点需要牢记，故障也可能发生在安全架构本身。与硬件故障不同的地方是，后者通常可以在使用过程中被很快发现，但安全检查器中的故障可能是潜伏的，它已经无法侦测危险故障，但故障却已经悄悄地蔓延开了。这样的故障被称为潜伏故障，定期测试检查器是个不错的方法。

安全完整性等级

不同的标准体系反应安全等级的方法也各不相同，但其主要目的是直观的反映功能的关键性。比如说，控制挡风玻璃雨刮、安全气囊或制动器的ECU，完整性必须高于控制车速表或泊车传感器的ECU，因为前方视野至关重要，突然刹车或气囊充气可能造成致命后果，驾驶员也会凶多吉少；而车速表或泊车传感器对安全停车的重要性就低得多了。

换句话说，安全完整性等级是与人避免危险情况的必要性和能力相关的；而各项标准的作用就是指导人们如何定义安全完整性等级，并提供相关参数，帮助其对系统完整性进行量化。

IEC 61508将安全完整性等级（SIL）分成4级，第4级为最高完整性。与之相似，ISO 26262提出了汽车安全完整性等级（ASIL），最低为ASIL A，最高为ASIL D。此外，就表二所示，针对ASIL B到ASIL D，ISO 26262分别就单点故障、潜伏故障和硬件故障概率指标（PMHF，业内也称及时故障）提出了建议参数。可检测故障的比例被称为诊断覆盖率。