半导体在ADAS和自动驾驶系统中发挥着核心作用。而安全（功能安全）具有最高优先级。但如何在复杂的ASIC和SoC中实现对安全的要求？

随着ADAS和AD的出现，汽车电子已经成为增长最快的细分市场之一。在这个领域，那先先进的技术催生了复杂的IC和SoC的广泛使用，它们将数字、模拟、射频和电源管理整合到一个芯片中。简而言之，当一个错误可能带来灾难性的后果时，传统的硬件和软件开发方法就需要更新。

 ISO 26262：现在有了Part 11

安全关键型电子产品开发的最重要的行业标准是IEC 61508和自2011年以来的特定应用汽车标准ISO 26262。从IEC 61508到ISO 26262的变化是由汽车行业的性质决定的：系列化生产和在几个供应商之间的分布式开发。最初分为Part 1 ~ 10，ISO 26262涉及整个产品生命周期的各个方面：从概念到硬件开发的Part 5。然而，自其首次出版以来，电子行业有许多批评者认为，IC开发和预期功能安全（SOTIF）没有得到充分的解决。

作为回应，2019年ISO增加了Part 11，专门针对半导体设计，对IC设计必须在ISO 26262的框架内进行全面解释。2019年初，一个新的补充标准（ISO/PAS 21448）发布，该标准涉及SOTIF，并涵盖人为错误导致的系统误用等主题。这两个更新（经过多年的学习和完善）给汽车行业提供了一套全面的电子系统（包括SoC）运行安全标准，大多数汽车制造商指定他们的ECU一级供应商符合ISO 26262的安全相关系统。

 ADAS和自动驾驶系统的现状 

自动驾驶功能或ADAS失败的后果已被充分记录。前几年，发生了第一起涉及L3（有条件自动驾驶）车辆的死亡事故，一名行人被一辆自动驾驶的Uber车辆杀害。此外，自2016年以来，还有五起涉及（部分自动驾驶）L2车辆的死亡事故，均为特斯拉自动驾驶。

首先看L1系统，对2017年美国5000起车祸的分析表明，车道偏离和盲点警告等ADAS功能使车祸率下降了11%，受伤率下降了21%。

关于L2，有人员死亡，但这5人的死亡只有在事件背景下才能得到充分解释。首先，特斯拉规定在任何时候都要有一个人控制自动驾驶设备，其次，特斯拉在2018年11月报告说，他们用于半自动驾驶汽车的自动驾驶技术已经使用了10亿英里（16亿公里）。当时，只有3人死亡（相当于每1亿英里0.3人死亡）。相比之下，在美国，人类驾驶的汽车每1亿英里（1.6亿公里）造成1.18人死亡（2016年数据）。同样，特斯拉在2019年4月报告说，在2019年第一季度，装有自动驾驶的汽车每行驶287万英里（459万公里）就会发生一起事故，而没有自动驾驶仪的汽车每行驶176万英里（282万公里）就会发生一起事故。

为了衡量L3+级自动驾驶软件的状况，值得关注的是加利福尼亚州，该州要求自动驾驶汽车制造商记录并公布每年在道路上的人工干预次数，以及行驶的距离。领先的公司Waymo（谷歌的前自动驾驶部门）在这方面的记录是每11,000英里（17,600公里）有一次干预。然而，各公司之间的差距很大，最差的公司每英里（每公里）有三次干预记录。

图1：加州车辆管理局2018年关于干预自主车辆功能的报告

 是否需要对安全关键型系统进行改变？

与消费类产品相比，安全关键型IC的开发需要在项目管理、开发、文件和工具方面付出大量的额外努力。一个安全关键型的设计必须既为所需的系统功能提供一个最佳的解决方案，又记录这个解决方案如何失败或再次失败。同样重要的是，要说明失败的后果以及如何将风险降低到可接受的水平。

ISO 26262（像所有的安全标准）能够分析一个系统和其可能的故障。该标准表明，已经采取了足够的措施来确保系统安全，并要求具有充分的文件记录并具有可追溯性的一致过程。

因此，SoC开发需要不同的技能，从系统架构到硬件/软件分别开发，再到验证和制造--每一项都对安全关键型产品有具体的影响。

对于硬件开发，除了传统的基于仿真的方法（使用RTL描述或原理图）外，还需要进行评估。这表明故障或失效的子块如何结合起来违反安全目标，建议采取必要的补救措施。因此，必须对随机误差和软误差及其对不同芯片结构的影响进行量化，这对一个拥有几百万个逻辑门的设备来说是一项具有挑战性的任务。

软件开发也是所有安全关键型应用的一个挑战。最近最引人注目的例子可能来自航空业，波音737 Max的坠毁是由软件错误造成的。在ADAS应用中，开发者不仅需要将错误降到最低：美国的第一起死亡事故是由一个软件错误引起的，该错误同时对图像数据（一辆白色拖车穿过马路被检测为天空）和雷达数据进行了误读。开发者还必须做出更复杂的伦理考虑，由于不同地区的道德选择而变得复杂（图2）。

图2：自动驾驶车辆决策背后的道德规范有多普遍？根据《自然》杂志2018年的公布数据

如果要将软件集成到SoC的ROM中，这项工作就变得特别困难。为了满足安全标准，一个强大的过程对于规格设计、编码、文档和验证软件是必不可少的。推荐的软件编码方法指出了某些语言的一些限制，如MISRA-C。通常需要质量指标，如代码或条件覆盖率或需要测试每个软件单元的要求。所有这些步骤都是为了符合ISO 26262和IEC 61508的要求。

安全标准还涉及到某些组织方面。所有的安全标准中都确立了 "对于任何工作，测试人员必须独立于开发者"的原则。然而，这两个标准以及其他标准，如用于航空电子设备的DO-167和用于医疗设备的ISO 62304，其独立程度各不相同。这个过程的最后一步是向客户/项目伙伴证明SoC是安全的。

安全标准要求对所涉及的项目进行独立评估，根据安全级别的不同，可能有具体的变型。需要一个独立的评估员来验证安全案例：收集文件和工作成果，表明一个项目已经按照适用的标准适当地进行了。

 安全关键型ASIC/SoC开发注意事项 

许多公司遵守国际质量标准，获得了ISO 9001:2015证书，这保证了所有商业活动都是按照严格的流程进行的。然而，符合安全标准，如ISO 26262或IEC 61508，需要更多的东西。

任何安全关键型ASIC或SoC的一个重要步骤是选择EDA工具进行逻辑综合、仿真、物理实现和验证，这些工具应该已经通过相关标准要求的验证过程。

同样，基于V型模型的安全关键型SoC的开发过程应贯穿整个过程：从概念到最终制造。这需要强大的文档和配置管理及可追溯性流程，并确保严格的硬件和软件验证流程，并得到所有项目利益相关者的批准。每个安全关键项目都需要一个安全分析过程。在这里，开发人员的专业知识在了解电路或IP模块可能出现的问题等方面起着至关重要的作用，从而使必要的缓解措施可以实施（图3）。

图3：安全分析过程描述了工作流程，并根据相关标准的要求，导致独立的第三方确认

为了验证所选安全措施的有效性，根据ISO 26262（和所有的安全标准），还需要一个额外的步骤。在复杂的SoC的情况下，需要特殊的软件工具来进行故障注入。这些允许模拟经常发生的故障（包括随机和软故障），并检查它们是否被正确检测和纠正，以便确保安全的系统行为。

 共同仿真而不是调试 

当然，复杂的SoC可能涉及处理器IP，如MCU或DSP，其行为往往取决于以ROM、OTP等形式编码在芯片中的软件。调试嵌入式软件一直是一个挑战，当代码在芯片中时，这种挑战就会大大增加，使传统的调试工具失去作用。相反，需要硬件和软件的共同仿真的模型，允许对整个系统的行为有一个整体的视角，甚至在实际芯片可用之前。

在供应商和内部开发安全关键系统的最后一个关键方面是，半导体制造商和供应商必须证明能够按照汽车安全标准来制造部件。应在供应商和客户之间建立一个沟通流程，遵守安全计划和开发接口协议（DIA）的严格规则。

对于内部组织来说，需要在功能安全（FuSa，Functional Safety）的框架内建立一个独立于项目的管理结构，在建立FuSa流程方面创造必要的独立性，并为所有参与安全关键产品的开发者提供必要的培训和支持。

本文部分图文引用自《汽车电子》杂志