实现现代汽车SoC功能安全的实践和挑战

​说明

---

本内容编纂于论文Practices and Challenges for Achieving Functional Safety of Modern Automotive SoCs: A Tutorial Introduction。该论文可以从网络搜索下载，或者从下面链接访问：

https://ieeexplore.ieee.org/document/8678692

作者：Wen Chen, Member, IEEE, and Jayanta Bhadra*, Senior Member, IEEE

Wen Chen是NXP的高级首席工程师，负责为全球团队领导功能安全方法的研发。他的研究兴趣包括微处理器和SoC验证、数据挖掘、功能安全和保障。Wen 在加州大学圣巴巴拉分校获得电气和计算机工程博士学位

Jayanta Bhadra 是AMD的硬件设计工程总监。他在德克萨斯大学奥斯汀分校获得电气和计算机工程博士学位。Jay 是 IEEE 的高级成员，并且一直是德克萨斯大学奥斯汀分校计算机工程的兼职副教授。他对硬件验证、数理逻辑和安全相关研究有着浓厚的兴趣。

摘要—本文提供汽车SoC环境下功能安全的教程介绍。我们描述了在ADAS 和未来自动驾驶应用中实现汽车SoC设计、验证和确认功能安全的实践和挑战。

索引词—功能安全、ISO 26262、汽车 SoC、故障运行、ADAS

1  引言

---

汽车行业近年来出现了一些趋势。首先，随着政府推动更安全、更清洁的交通，向零排放汽车的过渡被提上汽车制造商的议事日程，这导致汽车加速电气化。其次，作为“物联网”的重要组成部分，汽车将与外界连接，实现信息娱乐和高级驾驶辅助系统（ADAS）。最后，随着人工智能和机器学习的快速发展，自动驾驶汽车成为许多传统汽车制造商和市场新参与者的新追求[21]。在这些大趋势的推动下，最近汽车中的大多数创新功能都在电子和软件中实现，导致车辆中电子和软件组件的复杂性急剧增加。现代汽车可以包含200多个电子控制单元 (ECU)、多个车载通信网络和数百MB的软件[22]。复杂性增加的一个明显后果是电子和软件中的缺陷和故障增加，这可能导致道路事故。因此，车辆中的电气和电子 (E/E) 系统的功能安全已成为重中之重。

作为整体车辆安全的一部分，功能安全要求电子和软件的故障不应对道路车辆和行人造成伤害。通常通过确保系统能够检测到功能故障，及时做出适当反应以减轻故障行为的危害来实现，例如，通过提供紧急反应或通知驾驶员采取行动，并最终通过系统进入安全状态。如何检测和减轻危害在很大程度上取决于发生故障的特定功能，以及该功能的环境条件，包括整个车辆架构。随着我们进入汽车自主性不断提高的时代，随着自主性水平的提高和车辆架构的发展，功能安全的要求可能会发生巨大变化。

SAE International为自动驾驶汽车的驾驶功能定义了六个级别的自动化，其中级别 0 表示完全没有自动化，级别 5 表示完全自动化 。目前，最先进的安全架构属于“fail safe”系统的范畴，这意味着当功能发生故障时，系统应该转换到已知的安全状态，这样功能的故障就不会导致任何伤害。在许多情况下，系统在安全状态下不再完全运行，驾驶员会收到通知，以便他/她需要采取行动。此类汽车E/E系统的功能安全通常依赖于假设车辆中有驾驶员作为最后的手段，并且某些功能仍由机械系统操作。然而，随着自动驾驶水平的提高，人为因素逐渐被排除在外，并且车辆的更多组件实现了电气化，fail safe架构将无法满足功能安全要求。fail operational 架构，即系统在存在组件故障的情况下软件仍然能够继续运行，将成为功能安全的要求。

传统上，汽车供应链的结构类似于分层金字塔，汽车供应链的层次结构以汽车制造商为顶端，通常称为 OEM（原始设备制造商）。原始设备制造商从Tier 1(一级供应商处)购买零件或系统并将它们集成到车辆中。Tier 1的零件或系统通常在车辆层面实现特定功能，例如发动机控制单元 (ECU)。在 Tier 1下是广泛的 Tier 2供应商，他们提供系统组件，例如 SoC和配套软件。半导体公司通常被视为Tier 2供应商。

由于功能安全要求与车辆级别的功能密切相关，它们传统上由 OEM 或 Tier 1驱动。事实上，通常Tier 1实现功能系统，他们在发展技术安全概念方面发挥了主导作用。汽车供应链的动态也在几个技术趋势的推动下发生了变化：（1）由于自动驾驶功能必须协调车辆中的广泛系统，OEM越来越多地参与技术安全概念并且更愿意获得半导体公司参与讨论。(2) 随着片上系统集成技术的进步，越来越多的系统功能可以集成到 SoC 或系统级封装 (SiP) 。距离单芯片实现车载级功能的日子已经不远了。(3) 一些半导体供应商也在向提供完整解决方案的系统供应商发展，作为市场差异化因素。简而言之，汽车供应链的层次结构已经扁平化 ，不同参与者的角色和职责之间的界限已经模糊。半导体公司在系统的功能安全开发中发挥着越来越积极的作用，功能安全知识对于开发汽车 SoC 的工程师来说非常抢手。

自 2011 年发布第一版以来，ISO 26262 一直是道路车辆 E/E 系统功能安全的强制要求。它提供了汽车E/E系统在其整个生命周期中的功能安全开发流程指南。由于汽车SoC是 E/E 系统的一部分，并且它们的开发不跨越系统的整个生命周期，因此半导体公司需要根据自己的需要定制ISO 26262开发流程。该标准的第一版没有提供特定于汽车级半导体开发的指南。2018 年发布的第二版增加了专门针对半导体指南的第11部分，因为汽车SoC的功能安全性最近获得了很大的关注。然而，ISO26262的总体描述是基于OEM或Tier 1的角度，而不是半导体公司的角度。

本文旨在介绍用于ADAS和未来自动驾驶应用的汽车SoC设计、Verification和Validation的功能安全性教程。我们回顾了当前的做法，并讨论了汽车领域半导体专业人士在实现功能安全方面面临的挑战。通过解释这一领域的问题并阐明挑战，我们希望引起半导体领域研究人员的注意，以期寻求先进的技术和解决方案来应对挑战。在本文的其余部分安排如下。第 2 节介绍什么是功能安全，什么不是，以及功能安全如何融入道路车辆的整体安全图景。第 3 节介绍了 ISO 26262 为车辆级产品定义的功能安全开发流程。第 4 节深入探讨了实现半导体开发功能安全的技术活动。第 5 节讨论了为当前和下一代汽车 SoC 实现功能安全所面临的挑战。第 6 节重点介绍了该领域最近的研究工作。第 7 节总结了论文

2  什么是功能安全 

---

自汽车诞生以来，道路车辆的安全性一直是汽车行业最关心的问题。从当代的角度来看，一辆安全的车辆包括四个要素[3]： 

• 道路安全关注减少人为失误造成的事故。截至今天，94% 的道路事故是由人为错误造成的 [9]。ADAS 技术的开发旨在减少人为错误造成的事故，许多汽车制造商正在积极致力于自动驾驶，最终将人为因素排除在外。 

• 设备可靠性涉及设备的零故障。目标是提高制造质量和设计稳健性，以降低组件的故障率。 

• 功能安全关注汽车系统故障不会造成任何事故(zero accidents)

• 鉴于每辆车都在不久的将来相互连接，Security是为了防止汽车被黑客入侵

当我们将功能安全定义为整体车辆安全的支柱之一时，我们回顾了功能安全与其他车辆安全支柱的区别。希望我们可以通过详细说明功能安全不是什么来阐明什么是功能安全。 

2.1 功能安全不是预期功能的安全 

Functional Safety is Not Safety of the Intended Function

ADAS 系统使用复杂的传感器和处理算法来感知周围环境和驾驶情况，以协助驾驶员，从而减少人为错误。ADAS系统正确的周围环境感知对车辆的安全性至关重要。与许多完善的系统（例如动态稳定控制系统）不同，ADAS 系统的意外行为，由于技术和系统缺陷和/或可合理预见的误用，可能导致危险事件。预期功能的安全性是在ISO 26262涵盖的故障范围下，涉及使用特定功能的安全性(通常在ADAS系统中)。例如，摄像头大量用于ADAS系统中的对象检测。但对摄像机的感知可能存在技术或性能限制，这应该在系统投入使用之前预见到。CMOS 摄像头的一个限制示例是，当车辆驶出长长的黑暗隧道时，摄像头可能会在几秒钟内处于过饱和状态，因此在此期间无法检测到物体。在这种情况下，摄像头没有故障或失效，因此不存在功能安全问题。但是，如果车辆仅依靠摄像头的感知来实现驾驶员辅助，摄像头的性能限制可能会导致危险事件。因此，应采取预防措施，例如使用各种传感器进行感知，以避免此类误用。预期功能的安全性应由正在开发的ISO 21448解决 [16]。 

2.2 功能安全不是可靠性 

Functional Safety is Not Reliability

可靠性工程关注组件的失效机制以及如何提高制造质量和设计稳健性以降低组件的故障率。故障率可以定义为 (1) 组件发生故障的频率，以每单位时间的故障数表示（半导体通常以小时为单位）或 (2) 总体中的故障总数除以测量特定总体的时间间隔。功能安全关注的是由于组件故障导致的系统故障，以及如何控制和减轻组件的故障影响以防止系统故障造成伤害。换句话说，功能安全旨在解决没有任何组件可以完全可靠的事实。

虽然可靠性并不等同于功能安全，但它确实会影响功能安全，因为故障率数据可能会影响用于控制和减轻组件故障的安全措施。例如，半导体技术扩展可能会加剧芯片上的Transient Fault和Soft Error，这将推动安全架构包含针对此类故障的更有效的安全机制。 

2.3 功能安全不是Security

Functional Safety is Not Security

Security要求车辆的 E/E 系统和软件组件必须能够抵御系统黑客攻击。损害系统中资产的机密性和完整性可能会侵犯系统的安全性。汽车 E/E 系统中的资产示例包括修整值(Trim Values)、固件执行流程、加密密钥和用户身份信息。Confidentiality 机密性要求未经授权的代理不能访问资产。此要求适用于用户隐私信息等资产。Integrity完整性要求保护资产免受未经授权的修改。这一要求通常对于作为信任根的资产至关重要，例如安全启动固件 [6]。传统上，Security过去对汽车来说不太重要，因为安全攻击只有在恶意代理可以物理访问汽车时才可行。但是，随着汽车之间和外部世界的高度连接，远程攻击成为可能。

Safety问题是系统故障不应导致有害事件，而故障可能归因于开发错误或随机硬件故障。Security问题是Confidentiality和Integrity不应被恶意代理破坏，而完整性的丧失可能会导致有害事件。一个显著且有点非正式的区别是，Security涉及由于恶意代理的故意攻击而导致的故障，而Safety涉及由于意外故障而导致的故障。汽车E/E系统的Security问题应该在 ISO 21434“道路车辆 - 网络安全工程”中得到解决，该标准正在开发中 [2]。

2.4 功能安全不是可用性

Functional Safety is Not Availability

系统的可用性通常是非常必要的，但是，对于维护车辆的安全性并不总是必要的。系统功能不可用并不总是意味着违反安全规定。例如，如果在发动机点火时的自检过程中检测到 ECU 出现故障，则 ECU 将中止发动机启动。在这种情况下，如果 ECU 功能出现故障，可用性就会丢失。然而，车辆仍处于安全状态并因此保持功能安全。

3 ISO26262: 基于风险的开发方法

---

ISO26262: Risk-based Development Approach

IEC 61508 是适用于各行各业E/E系统的基本功能安全标准。它涵盖了安全相关的E/E系统的安全管理、系统/硬件设计、软件设计、生产和运行。ISO 26262 是对 IEC 61508 的改编，作为汽车 E/E 系统功能安全的要求。ISO 26262 将功能安全定义为“由于E/E系统故障产生危害从而引起不合理风险，这样的风险是不存在的”(absence of unreasonable risks due to hazards caused by malfunctioning behavior of E/E systems)。ISO 26262 提供了一个确定风险的标准化框架，以及如何管理开发过程以将风险降低到可接受水平的指南 [15]。功能安全的管理贯穿安全相关产品的整个生命周期，包括概念阶段、开发阶段和生产阶段，如图1所示。由于汽车SoC是车辆级别的安全相关产品的一部分，它将有利于半导体专业人士了解整个安全生命周期以及 OEM、一级供应商和半导体供应商的相应角色和责任。因此，在关注汽车 SoC 之前，我们将在本节中描述生命周期各个阶段的开发活动。

3.1 安全产品概念 

3.1.1 项目定义

Item Defintion

产品概念的最开始是定义“Item”。ISO 26262 将Item定义为“在车辆级别实现功能或部分功能的系统或系统阵列”(system or array of systems that implement a function or part of function at the vehicle  level)。由于它涉及车辆级别的功能，因此通常由OEM完成。Item的定义可以包括功能描述、功能框图、项目交互的环境条件、法律要求和降低风险的外部措施。

3.1.2 安全生命周期的初始化 

Initialization of Safety Lifecycle

根据项目定义，安全生命周期是通过区分新开发或对现有项目的修改来启动的。如果是对现有项目的修改，则生命周期中的活动将根据需求进行定制。在本文中，我们将重点描述新开发的过程。