Enrique Martinez ，safety manager at EnSilica.

    先进的驾驶辅助系统(ADAS)使当今的汽车更加安全，并使自动驾驶汽车的出现成为可能，这对汽车电子行业提出了新的挑战，使其复杂性、性能和安全性达到了新的水平。这些应用的独特需求导致了复杂的ASIC的广泛使用，这些ASIC将数字处理、模拟、射频和电源管理功能结合在一个硅片上。因此，关键的安全功能都可以在片上进行管理。

    虽然任何非娱乐性的汽车电子产品都被认为是关键任务，但ADAS系统是安全链中特别关键的一环。一个典型的ADAS单元负责将一个或多个计算单元与多种基础技术（如雷达/激光雷达、GPS和无线通信）集成在一起，以产生可操作的、几乎没有错误的信息，使驾驶辅助或自动驾驶系统能够以极高的安全性运行。此外，它们必须能够满足汽车行业严格的空间、功率和成本限制。为了应对这些挑战，许多汽车OEM和系统制造商都在使用SoC作为ADAS系统和其他复杂汽车产品的基础。

    即使在考虑安全管理之前，开发能够提供足够的处理能力以运行复杂的多线程嵌入式软件的硅芯片本身就是一个相当大的挑战。在这些ASIC的开发过程中，再加上安全方面的限制，执行关键任务的驾驶辅助或自动驾驶功能的SoC给原本已经是跨学科的工作带来了更多类型的技能。

    要为这些应用程序开发系统，就像载人航天一样，"失败是不允许的"，设计人员和设计经理必须重新思考并考虑采用新的方法来处理他们多年来一直依赖的硬件和软件开发方法。

行业标准

    多年来，汽车电子技术的许多方面都受IEC 61508的规范，这是一份管理各种应用中安全关键型电子器件设计的多用途文件。IEC 61508已被2011年推出的针对汽车应用的国际标准组织(ISO)26262所补充，并在许多方面超越了IEC 61508。从IEC 61508到ISO 26262的转变，是由于汽车行业的高产量和越来越多地依赖跨越多个供应商的分布式开发工作的结果。

    ISO 26262标准最初分为10个部分，致力于涵盖整个产品生命周期的不同方面：从概念开始，第5部分专门用于硬件开发。然而，自最初发布以来，电子行业的许多批评者都担心该标准没有妥善解决与集成电路开发和预期功能安全（SOTIF）管理有关的问题。

    作为回应，ISO去年添加了第11部分，专门用于半导体开发。 新部分提供了有关如何在ISO 26262框架内解释IC设计的广泛指导。 最近，ISO 26262已对标准ISO / PAS 21448进行了补充。该标准于2019年发布，深入解决了SOTIF问题，涉及诸如人为错误导致的系统滥用等主题。

    这两个更新（以及多年的学习和完善）共同为汽车行业提供了一套解决电子系统安全的全面标准，大多数汽车制造商都规定其ECU一级供应商遵循与安全相关的系统的ISO 26262法规。

ADAS和自主系统的现状

    自动驾驶汽车和ADAS故障的后果已经有了充分的记录。去年发生了第一起涉及Level-3级（条件自动驾驶）车辆的死亡事故，一名行人被一辆自动驾驶的Uber撞死。自2016年以来，已经发生了5起Level-2（部分自动驾驶）汽车死亡事故，均涉及运行Autopilot的特斯拉。

    先看Level-1系统，2017年对美国5000起事故的分析表明，ADAS技术，如车道偏离和盲点警告等，使车道偏离和盲点警告等车祸发生率降低了11%，受伤率降低了21%。至于Level 2，确实发生过死亡事故，但这5起死亡事故需要结合实际情况。首先，特斯拉规定，特斯拉的汽车是不具备自动驾驶资格的，即使在特斯拉的Autopilot运行时，驾驶员必须处于一个能让他们立即对车辆进行物理控制的位置。还有一点很重要的是，在2018年11月，特斯拉报告称其Autopilot半自动驾驶技术已经投入使用了10亿英里（16亿公里），而在这段时间内，特斯拉已经发生了3起死亡事故----结果是每1亿英里的死亡人数为0.3人。

    相比之下，2016年美国人工驾驶汽车每1亿英里的死亡人数为1.18人。同样，在2019年4月，特斯拉报告称，2019年第一季度期间，他们的汽车在运行Autopilot系统时，每287万英里（459万公里）记录了一起事故，而在没有运行Autopilot系统时，每176万英里（282万公里）记录了一起事故。

    为了衡量3级以上的自主驾驶软件的状况，我们可以将目光投向加州，加州要求自动驾驶汽车制造商每年记录并公布在其道路上进行人工干预的次数和行驶距离（图1）。这个数据显示，领先的公司Waymo（原谷歌的自主汽车部门）每11000英里（17600公里）只需要进行一次人工干预。然而，不同的开发者之间的差距很大，表现最差的公司的车辆每英里需要三次干预（每公里2次）。

这张人工干预的图被收录在加州车管所2018年的脱离报告中

安全关键系统所需的变化

    那么，在开发ADAS和自动驾驶系统的安全关键IC时，需要做哪些类型的额外努力呢？我们将看到，这些努力主要需要应用于项目管理、开发、文档和工具等方面。

    在顶层，一个安全关键设计既要为所要求的系统功能提供一个最佳的解决方案，又要记录这个解决方案如何失败，并说明这样做的后果，以及如何将风险降低到可接受的程度。

    ISO 26262（与所有安全标准一样）提供了：a）分析系统的框架，以及系统可能发生故障的原因；b）记录已采取足够的措施保证系统安全的方法；c）设计和管理团队有一个一致的流程，并有机制确保有足够的文件和可追溯性。在ISO 26262/21448的指导下开发SoC需要多个学科的协调，包括系统架构、硬件/软件分区、设计验证和生产计划等。

    在硬件开发过程中，传统的基于仿真的方法(根据RTL描述或原理图)必须辅以专门的研究，以确定一系列故障子块组合在一起违反安全目标的操作场景，以及每个问题的潜在解决方案。这种类型的分析需要量化随机错误和软性错误，以及它们在不同芯片结构中的影响；这是一项艰巨的任务，即使是在一个相对 "小 "的器件中，即使是包含不到1亿个门的器件也是如此。

    用于安全关键应用的软件工程也面临着类似的挑战。最近发生的几起波音737 Max客机坠毁事故中由软件引起的死亡事件只是其他数字定时炸弹在商用飞机上肆虐的最臭名昭著的例子。同样，美国首起涉及自动驾驶汽车的死亡事故也是由软件错误造成的，它误读了成像数据（认为横穿马路的白色拖车是天空）和雷达数据。对于ADAS应用来说，软件工程师的工作就更加复杂了，这也涉及到伦理方面的考虑，以及设计中必须考虑到的道德问题。 图2提供了在设计过程中加入伦理和道德问题所涉及的一些考虑因素的高层视图。

自动驾驶汽车决策背后的道德规范有多普遍?(节选自《自然- 2018》杂志)

    软件开发的另一个关键阶段是将实时的软件转换为可以嵌入到SoC的ROM中的固件映像。要实现产品完全符合规范的安全规范要求，需要一个强大的流程来指定、编码、记录和验证软件。在准备生成固件映像时，最好查看一下目前推荐的软件编码实践。一些比较值得注意的建议包括：对某些语言的限制（如MISRA-C），使用质量指标来衡量代码或条件覆盖率，以及根据要求对每个软件单元进行单独测试。所有这些步骤对于实现ISO 26262和IEC 61508的符合性都是必要的。

    安全标准还涉及到具体的组织方面。"对于任何工作产品，核查员必须独立于作者 "这一原则在所有安全规范中都有规定，然而，在这两项标准和其他标准之间的独立性程度各不相同，如DO-167(适用于机载电子技术，ISO 62304(适用于医疗系统)。

    流程的最后一步是向客户或项目合作伙伴证明SoC是安全的。安全规范要求所涉及的项目经过一个独立的评估，具体的变化取决于安全水平。将需要一个独立的审核员来验证安全案例，即文件和工作产品的收集，以证明一个项目已经根据相关标准正确执行。

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

    许多公司将遵循ISO 9001:2015认证的国际质量标准，以确保所有的业务活动都在严格的流程中进行。然而，对安全标准的遵守，如ISO 26262或IEC 61508，需要更多的东西。

    在任何安全关键的ASIC或SoC中，关键的一步是选择EDA工具，用于逻辑综合、仿真、物理实现和验证的EDA工具，这些工具应该已经通过了管理标准要求的验证过程。

    同样的，在开发安全关键型SoC时，也应采用V型模型，并从构思到最后的生产过程中都要坚持。这将使文档管理、配置管理和可追溯性等方面的流程更加稳健，同时确保严格的硬件和软件验证流程到位，并召开涉及所有项目涉众的专门批准会议。

    每个安全关键项目都需要一个彻底的安全分析过程。设计者的专业知识在这里起着至关重要的作用，他可以了解电路或IP区块中可能出现的问题，并制定必要的缓解策略（图3）。

安全分析过程描述了工作流程，并引了出相关规范经常要求的独立第三方确认

    为确保所选的安全措施有效，ISO 26262（以及所有可靠的与安全相关的标准）需要采取额外的步骤。在复杂SoC的情况下，这是通过使用专用的故障注入软件工具来实现的。这些工具可以模拟发生的常见故障（包括随机故障和软错误），并验证这些故障是否被正确地检测到和/或纠正，从而仍能产生安全的系统行为。

    顾名思义，SoC包括处理元件，如MCU或DSP，它们的行为通常依赖于以ROM、OTP或类似的集成逻辑元件的形式在硅片内部编码的软件映像。调试嵌入式软件一直是一项具有挑战性的工作，当代码映像在其运行的硅片内部时，这种情况就会大大增加，使许多传统的调试工具变得不那么有效，甚至无法使用。相反，需要对硬件和软件进行联合仿真模型，以提供给开发人员对系统行为的整体观察，甚至是在实际的硅片出现之前，就可以对系统的行为进行整体观察。

    供应商验证是开发安全关键系统的最后一个关键环节。如果您的设备将用于ISO 26262或类似标准的应用中，那么您所使用的硅晶圆厂和分包商必须有能力制造符合汽车安全标准的部件，并应使用与供应商和客户的沟通流程，遵守与安全计划和开发接口协议（DIA）相关的严格规定。

    在内部组织方面，需要一个独立于项目的功能安全（FuSa）管理结构，这为建立FuSa流程提供了必要的独立性，并为所有参与安全关键产品的工程师提供必要的培训和支持。