实现现代汽车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

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

3.1.3 危害分析和风险评估

Hazard Analysis and Risk Assessment (HARA)

HARA的目标是量化因功能失效而导致的危害风险。这通常是 OEM 的责任。首先，定义项目的所有可能故障。故障的定义通常考虑两个方面：（1）功能没有在需要时正确执行；(2) 不需要时却执行了该功能。然后考虑可能发生故障的车辆运行条件和驾驶场景。故障、车辆运行条件和驾驶场景的组合被视为所有可能的危险事件。对于每个危险事件，相关风险根据三个因素进行评估：severity 严重性（伤害有多大？）、exposure 暴露（它可能发生的频率？）和controllability 可控性（危害可以控制的可能性有多大？）

根据可能发生的伤害，Severity涉及危险事件可能对处于危险中的人造成的潜在伤害。ISO 26262 定义了四个严重等级，如表 1 所示。

Exposure考虑了所考虑情况的持续时间或频率。持续时间用于在所考虑的情况下由于突然故障而发生危险事件。例如，夜间在乡间公路上行驶时，前照灯熄灭。Frequency在故障存在且仅在所考虑的情况发生时才发生危险事件时使用。例如，当驶入隧道并试图打开大灯时，大灯无法打开。ISO 26262 定义了五个Exposure等级，如表 2 所示。

Controllability考虑了驾驶员和/或其他交通参与者（如行人）对危险的控制。ISO 26262 定义了五个Controllability等级，如表 3 所示。

与危险事件和驾驶场景组合相关的风险等级可以根据这三个因素来确定，称为汽车安全完整性等级 (Automotive Safety Integrity Level ASIL)。ISO 26262 定义了四种 ASIL：ASIL A、ASIL B、ASIL C 和 ASIL D，其中 ASIL A 是最低的安全完整性等级，ASIL D 是最高的安全完整性等级。除了这四个 ASIL 之外，QM（质量管理）等级表示标准质量保证就足够了，无需遵守 ISO 26262。根据Severity、Exposure和Controllability等级确定 ASIL 的经验法则是：（1）如果三者中的任何一个都属于“0”类（即S0、E0、C0），那么它属于QM。(2) 否则，将S、E、C的等级相加。如果总和为10，则为ASIL D；如果值为 9，则为 ASIL C，如果值为 8，则为 ASIL B，如果值为 7，则为 ASIL A，如果值小于 7，则为 QM。

对于每个故障，根据不同驾驶场景下的故障引起的危险事件的最高ASIL分配相应的ASIL等级。并且为每个故障确定一个安全目标(Safety Goal)以及分配的ASIL。如果多个安全目标相似，可以将它们合并为一个安全目标，并将最高 ASIL 分配给合并的安全目标。

3.1.4 功能安全概念

Functional Safety Concept (FSC)

FSC通常由OEM或Tier 1完成。基于Item Definition和安全目标，FSC是在考虑初步架构假设的情况下指定的。FSC的目标是导出安全需求(Safety Requirements, SR)并将其分配给架构元素。在实践中，FSC遵循五个步骤：

首先，针对每个安全目标，列出并检查特定于功能的安全相关特性。特性包括但不限于以下内容：

Safe State，安全状态，在项目发生故障时没有不可接受的风险的运行模式
Fault tolerance time interval (FTTI) ：容错时间间隔，出现故障时，系统不会违反Safety Goal的最大时间跨度
Warning concept：警告概念，将有关潜在危险情况的信息传递给驾驶员的措施。
Emergency operation：应急运行，当检测到故障后不能直接达到安全状态时，可采用应急运行来提供安全，直到达到安全状态的过渡。

其次，为每个Safety Goal出至少一个安全需求。安全需求与Item的行为有关，并且独立于实施。要求可以包括但不限于以下几个方面：

对功能限制条件的要求，例如，功能不应该在限速范围内有效。
实现Safety Goal的功能冗余和/或附加功能要求
对非E/E 元素的功能的要求，例如机械硬件
对驾驶员控制的安全功能的要求，例如手动关闭功能的能力。

第三，基于功能安全需求，通过细化项目的功能架构，得出初步的功能安全架构。它通常通过从项目定义中获取功能框图并通过考虑功能安全需求对其进行扩展来完成。如有必要，可以添加新需求或修改现有需求。细化是一个迭代过程。

第四，将功能安全需求分配给架构元素，并相应地分配 ASIL。通常，除非存在 ASIL 分解，否则功能安全需求的 ASIL 是从相关的安全目标继承而来的。

最后，FSC需要经过一定程度的独立性验证审核。

3.2 安全产品开发

Safety Product Development

安全产品开发开始后，就计划了各种活动。计划的活动通常包括系统设计和技术安全概念、硬件开发、软件开发、系统集成和测试、安全验证、功能安全评估，最后是产品发布(system design and technical safety concept, hardware development, software development, system integration and testing, safety validation, functional safety assessment, release for production)。本节重点介绍产品(Product)作为一个项目(Item)的开发。对于Item的每个组成部分，可以应用类似的方法。此外，硬件开发和软件开发通常遵循和系统开发相似的过程。因此，我们在本节中不详细阐述硬件和软件开发，并将在下一节中提供汽车 SoC 的更多细节。

3.2.1 系统设计和技术安全概念

System Design and Technical Safety Concept(TSC)

项目的系统设计和TSC通常是Tier 1的职责。系统设计通过与实现相关的技术视图细化架构的功能视图，而TSC将安全需求细化为分配给具体架构元素的技术安全要求(Technical Safety Requriements, TSR)。系统设计和TSC通常在以下步骤中齐头并进。

首先，基于功能框图和FSC，开发包含所有相关组件和所有接口的系统设计草案。这将架构的功能视图映射到架构的技术视图。例如，在功能架构中，我们可以有一个称为目标检测的模块，而不指定它是如何实现的。在系统设计中，会规定目标检测是通过雷达、激光雷达或它们的组合来实现的。

其次，技术安全需求源于功能安全需求(SR)。ASIL继承自相应的安全需求。此外，还包括对硬件架构指标的需求和由于随机硬件故障导致的故障率而违反安全目标的需求。

第三，为组件分配技术安全需求。有时，需要扩展系统以添加额外的措施，以满足安全需求，例如冗余系统元素或其他安全机制。安全机制是指由 E/E 系统或其他技术实现的功能，用于检测故障或控制故障，以实现或保持安全状态。

最后，通常通过安全分析验证系统设计和技术安全概念。此类分析包括故障树分析 (Fault Tree Analysis, FTA)、故障模式和影响分析 (Failure Modes and Effects Analysis, FMEA) 以及故障模式、影响和诊断分析 (Failure Modes, Effects, and Diagnostic Analysis, FMEDA)。分析和优化安全系统设计是一个迭代过程。

上述流程适用于车辆级的系统设计。对于系统的每个组件，可以对组件的TSC应用类似的流序。此外，对于组件级的TSC，往往需要将技术安全需求分配给硬件和软件，并决定硬件软件接口（HardwareSoftware Interface，HSI）。

3.2.2 系统集成和测试

System Integration and Testing

系统的组件或组件的子组件既可以在内部设计，也可以从Tier 2或Tier 3供应商处购买，然后集成到系统中。集成分为三个级别：组件内的硬件软件集成（通常由组件供应商完成）、系统内的组件集成（通常由Tier 1完成）和Item的车辆集成（通常由 OEM 完成）。

必须在每个集成级别执行测试。可以使用各种测试方法来表明已实现以下目标：

Correctness of system safety requirements implementation: 系统安全需求实施的正确性。用于此目标的示例测试方法是基于需求的测试
Correctness of safety mechanism functionality: 安全机制功能的正确性。一个示例测试方法是故障注入测试，它将逻辑或物理故障引入组件或系统以调用安全机制
Correctness and completeness of internal and external interfaces implementation: 内部和外部接口实现的正确性和完整性。这可以通过测试接口的连接性、兼容性和时序以及检查接口协议的一致性来完成
Diagnostic coverage of hardware fault detection mechanisms: 硬件故障检测机制的诊断覆盖率。这可以通过故障注入测试来完成。
Level of robustness：稳健性水平。这可以通过压力测试来完成，该测试验证系统在高运行负载或高环境要求（例如极端温度）下的正确运行

3.2.3 安全验证

Safety Validation

对集成在代表性车辆上的项目执行安全验证，通过在车辆级别上针对功能安全要求进行测试来验证安全目标。它旨在提供证据证明所有安全措施在预期用途下都是有效的，并且安全目标是正确的并在车辆层面完全实现。测试用例必须考虑安全目标和功能安全概念。验证方法包括但不限于：

长期测试，例如车辆行驶时间表和捕获的测试车队
真实条件下的用户测试、小组或盲测、专家小组

3.2.4 功能安全评估

Functional Safety Assessment

在产品发布之前，对产品实现的功能安全进行评估。功能安全评估可以作为一个完整的单个步骤进行，也可以作为开发过程中的多个步骤进行。评估的范围包括以下内容：

对先前功能安全评估的建议和纠正措施的跟进（如果有的话）
评估安全计划要求的工作产品(Work Product)的合规性
评估功能安全流程的实施
审查已实施安全措施的正确性和有效性

评估报告包含对产品已实现功能安全的接受、有条件接受或拒绝的建议。

3.2.5 产品发布

Release of Product

当安全案例和功能安全评估完成并获得批准后，允许产品发布。

3.3 安全相关产品的生产经营情况

Production and Operation of Safety Related Products

功能安全的管理在产品发布后不停止。应采取适当措施管理以下情况。

3.3.1 变更管理

Change Management

如果在生产过程中需要对项目进行任何变更，在进行变更之前应彻底评估对功能安全的潜在影响。

3.3.2 客户退货

Customer Returns

现场监控流程应配备仪器以收集要分析的数据，以检测是否存在任何功能安全问题。应仔细分析客户退货，以确定是否存在任何与功能安全相关的问题及其影响。

3.3.3 异常事件

Anomalous Events

应对生产过程中的异常事件进行分析，评估其是否会影响产品的功能安全。

4 汽车SoC的功能安全

在本节中，我们将在安全相关的汽车SoC的背景下深入探讨硬件和软件的功能安全开发。与安全相关的汽车SoC的开发有两种范式。一方面，可以在上下文中设计SoC，即为特定系统完成Tier 1的定制订单。在这种情况下，SoC的开发就以系统级技术安全概念为输入，提出SoC级技术安全概念。另一方面，SoC可以开发为脱离环境的安全元素 (Safety Element Out of Context，SEOoC)，这意味着它不受特定系统的约束，而是可以在多个系统中用于类似应用。在这种情况下，SoC 开发从系统级技术安全概念和系统设计的假设开始。随着半导体公司努力通过使用他们的芯片为Tier 1开发参考设计来推动价值创造，SEOoC 开发范式最近越来越受欢迎。SEOoC 开发需要更多的努力，因为它倾向于对系统做出更保守的假设。

请注意，由于汽车 SoC 仅满足部分项目，因此项目概念阶段的许多主要步骤（项目定义、HARA 和功能安全概念）将不会出现在汽车SoC的开发中。安全相关 SoC 开发过程的许多其他步骤与第 3 节中描述的定制项目类似，只是安全验证仅在车辆级别执行。因此，在本节中，我们不会重复解释该过程，而是会深入探讨该过程中的一些技术活动。由于故障的概念对于理解安全架构和实施至关重要，我们首先在功能安全的背景下对故障进行回顾。然后我们讨论用于推动安全架构开发和验证的安全分析。我们还详细阐述了汽车芯片中使用的常见安全机制，然后讨论了与安全相关的 SoC 的验证。

4.1 功能安全下的故障

Faults in Context of Functional Safety

通过检测、控制或减轻可能导致违反安全目标的故障来降低风险。ISO 26262 对故障(Fault)、错误(Error)和失效(Failure)进行了区分。可能导致元素或项目发生故障的异常情况是Fault。Error是指计算的、观察的或测量的值或条件与真实的、指定的或理论上正确的值或条件之间的差异。Failure是指元素或项目按要求执行功能的能力终止。如果不及时控制或减轻故障，Fault可能会发展为Error并最终导致Failure。请注意，组件级别的Failure可能是系统级别的Fault。

ISO 26262 涉及两种类型的故障：

Systematic faults：系统性故障是由于规范或设计问题，并以确定性的方式表现出来。系统性故障可能发生在软件和硬件上，只有通过安全分析和验证等措施改进开发过程才能消除。最常见的系统故障是开发错误。
Random hardware faults：随机硬件故障，在硬件组件的生命周期中发生，不可预测，并且是由于物理过程（例如磨损、物理退化或环境压力）造成的。随机硬件故障可以通过可靠性工程减少，但不能完全消除。

随机硬件故障可进一步分为两类：

Permanent faults：永久性故障，发生并一直持续到消除或修复。示例包括固定故障和桥接故障。
Transient faults：瞬态故障)发生一次，随后消失。由于电磁干扰或阿尔法粒子等原因，可能会出现瞬态故障。随着技术节点的缩小，触发器和存储阵列等存储元件越来越容易受到瞬态故障的影响。示例包括单事件扰乱 (SEU) 和单事件瞬态 (SET)。

安全机制(Safety Mechanism)是产品中用于检测、控制和缓解随机硬件故障的措施和技术。SoC 安全架构中安全机制的整体有效性可以通过硬件架构指标来量化。在给出指标的定义之前，我们首先介绍 ISO 26262 的故障分类，如图 2 中的流程图所示。分类假设有一个安全目标，并且很大程度上依赖于对安全方面的故障影响的判断目标。

要对故障进行分类，我们首先需要确定故障是否在安全相关元素内。如果不是，则该故障无关紧要，可以视为安全故障，不包括在安全分析中。如果元素与安全相关，那么问题是故障本身是否有可能在没有安全机制的情况下直接违反安全目标。如果不是，则可以暂时搁置故障，稍后再考虑。如果故障可能违反安全目标，那么下一个问题是是否有任何安全机制。如果不是，则故障是单点故障 (Single Point Fault SPF)，这通常是安全架构所不希望的。在有安全机制的情况下，不一定能涵盖所有故障。如果故障不能被安全机制覆盖，则将其归类为残余故障(Residual Fault)。

对于 SPF 相关的安全机制所涵盖的故障，在存在安全机制的情况下，它们不会违反安全目标。根据它们违反安全目标的可能性以及与另一个独立故障（二阶效应）对它们进行评估，如果没有这种可能性，则该故障被认为是安全故障。如果双点故障有可能违反安全目标，则评估是否有安全机制来防止它发生。如果没有这方面的安全机制或安全机制无法覆盖，则归类为潜在多点故障（MPF，Latent）或简称潜在故障。否则为检测到的多点故障（MPF，Detected）。此处无需将故障与其他两个独立故障一起考虑（在汽车领域发生的概率极低），ISO26262 将大于2的多点故障视为安全故障。

还要注意潜在故障(Latent Fault)和潜在缺陷(Latent Defect)之间的区别。潜在缺陷是一个可靠性问题，是指在生产测试期间未被发现并在设备的使用寿命期间表现出来的缺陷。潜在故障是一个安全问题，是指本身不会造成伤害但在存在另一个独立故障时可能造成伤害的故障。在功能安全的背景下，潜在缺陷可以属于任何故障类别。

4.2 安全分析

Safety Analysis

安全分析方法可用于构建 SoC 安全架构、识别系统弱点和分配安全机制。安全分析最初可以在架构设计阶段进行，之后可以作为验证安全架构实施稳健性的一种手段来执行。我们将回顾汽车 SoC 开发中使用的几种常见安全分析方法。

4.2.1 故障树分析

Fault Tree Analysis

FTA是一种自上而下（演绎）的方法，从故障效果开始分析所有可能的故障原因[23]。它使用故障树作为故障逻辑组合的图形表示。图 3 显示了用于分析 MCU 故障的示例故障树。

它从一个顶级事件开始，然后使用 AND 或 OR 等逻辑门将其分解为基本事件。对于每个安全目标，可以绘制故障树，最重要的事件通常是导致违反安全目标的危险。在此示例中，最重要的事件是 MCU 执行错误计算而没有指示。MCU 上的顶级事件可归因于 MCU 子组件故障的逻辑组合。MCU 的子组件（例如CORE0）的故障可以进一步分析，以追踪其子组件的原因。基本事件是无法进一步分析的事件，它在叶节点处停止故障树。通过将故障原因追溯到基本事件，安全架构师可以识别架构中的位置，以分配安全机制来控制基本事件。因此，FTA 可以作为推动安全架构发展的有效工具。

在构建故障树后，可以进行割集分析(Cut Set Anaylysis)以确定安全架构中是否存在单点故障 [13]。切割集(Cut Set)是可以导致顶级事件的基本事件的独特组合。具体来说，如果当从集合中删除任何基本事件时，其余事件共同不再是一个割集，则称该割集为最小割集。割集的顺序是指割集中基本事件的个数。例如，在图 3 中，EV1 和 EV2 构成了 2 阶最小割集。1 阶最小割集表示安全架构中存在单点故障，这表明应该添加安全机制来控制它。虽然 FTA 通常用作定性分析方法，但也有定量版本的 FTA，可以计算顶部事件的概率 [19]。

4.2.2 故障模式和影响分析

Failure Mode and Effects Analysis

FMEA是一种自下而上（归纳）的方法，侧重于系统的各个部分、它们如何发生故障（故障模式）以及这些故障对系统的影响[8]。FMEA 可以作为 FTA 的补充，并可用于交叉检查。

4.2.3 故障模式、影响和诊断分析

Failure Modes, Effects, and Diagnostic Analysis

FMEDA是识别和评估故障模式、影响和诊断技术并记录的系统方法。在硬件元素的 FMEDA 中，为元素的每个组件识别原始故障率和故障模式，以及故障模式分布。然后评估失效影响——失效模式是否有可能违反安全目标。此外，还确定了与故障模式及其诊断范围有关的安全机制。基于上述数据，FMEDA 通过硬件架构指标来量化安全架构的鲁棒性：单点故障指标 (SPFM) 和潜在故障指标 (LFM)。

假设安全相关硬件元件的原始故障率为 λ。根据故障分类，我们有以下等式：

其中 λSPF 是与单点故障相关的故障率，λRF 是故障与残余故障相关的故障率，λMPF;D 是与检测到的多点故障相关的故障率，λMP F;L 是与潜在多点故障相关的故障率，λS 是与安全故障相关的故障率。

可以为与残留故障和潜在故障有关的安全机制声明诊断覆盖率。单点故障度量 (SPFM) 定义为

其中

是要考虑的安全相关硬件元素的 λx 之和。SPFM 通过安全机制的覆盖率或设计（主要是安全故障）来量化硬件元件对单点故障和残余故障的鲁棒性。高 SPFM 意味着硬件元件中单点故障和残余故障的比例较低。表 4 显示了 ASIL B 到 ASIL D 的单点故障度量的目标值。

潜在故障度量 (LFM) 定义为

其中

是要考虑的安全相关硬件元素的 λx 之和。LFM 通过安全机制的覆盖率或设计来量化硬件元素对潜在故障的鲁棒性。高 LFM 意味着硬件元素中的潜在故障部分较低。表 5 显示了单点故障度量目标值。

除了 SPFM 和 LFM，还可以计算硬件随机故障概率度量 (Probabilistic Metric for Hardware Random Failures，PMHF) 来评估在系统级别违反安全架构的安全目标的总体概率。这是为了证明由于随机硬件故障导致违反安全目标的剩余风险足够低。虽然 PMHF 通常在系统级计算，但有时假设 PMHF 的某个部分不应在 SoC 级超过，并提供给系统设计人员以供参考。PMHF 可以通过使用 FMEDA 的故障率或定量 FTA 来计算。

4.2.4 相关故障分析

Dependent Failure Analysis

DFA包括识别和分析给定要素之间可能的共同原因和级联故障，评估其违反安全目标（或衍生安全要求）的风险以及定义安全措施必要时减轻此类风险。它旨在评估潜在的安全概念弱点，并提供满足有关独立性或不受干扰的要求的证据。相关故障发起者 (Dependent Failures Initiator，DFI) 代表了安全范围内相关故障的根本原因。DFA 以定性的方式解决了这些在标准安全分析中无法解决的 DFI。DFI 的类型包括：

共享资源失效
单一的物理原因
环境故障
开发故障
制造故障
安装故障
修复故障

需要采取不同的措施来应对不同类型的DFI。

4.3 安全设计实现

Safety Design Implementation

汽车SoC分布在广泛的产品中，包括微控制器单元或微处理器 (MCU/MPU)、雷达前端单片微波集成电路 (MMIC)、电源管理集成电路 (PMIC)、系统基础芯片 (SBC)、和各种传感器。根据产品架构，汽车SoC中使用了广泛的安全机制。在本节中，我们根据安全机制的工作方式和用途对它们进行分类。

4.3.1 按错误检测方法分类的安全机制

Safety Mechanisms Categorized by Error Detection Methods

许多安全机制依赖于检测故障和错误的能力。检测方法大致分为三种：冗余、监控和测试。

冗余错误检测利用冗余计算或存储来检测目标函数中是否存在错误。通常利用三种不同类型的冗余：

硬件冗余：Hardware redundancy 通常在不同的硬件模块上执行相同的计算，因此如果功能模块中存在导致错误的故障，则很可能通过比较结果来检测冗余模块。双模块冗余 (Dual Module Redundancy，DMR) 常用于汽车 SoC，其中两个处理单元同时执行相同的计算任务（在锁步模式下），它们的结果由检查器模块进行比较。DMR 允许错误检测，但不能自行纠正错误。错误处理通常由系统的其他部分完成。三重模块冗余 (Triple Module Redundancy，TMR) 允许错误检测和纠错，但需要额外付费。TMR 主要用于 SoC 级别的关键寄存器，例如存储修整值的寄存器，由三重投票触发器 (Triple Voting Flip-flops，TVF) 实现。
信息冗余：Information Redundancy 利用信息编码的冗余来检测并有时纠正错误。示例包括纠错码 (ECC) 和奇偶校验 [11]。这种安全机制通常用于保护数据通信通道和内存。
时间冗余：Time redundancy 重复执行相同的计算，可能在相同的硬件中但使用不同的算法。通过重复计算，它可能会检测到计算中是否存在Soft Error。在计算中使用不同算法的情况下，甚至可以检测到硬件中的永久性故障，因为不同的算法可能会使用同一硬件元件的不同部分。

注意冗余通常与多样性结合使用，以避免共因故障。多样性可以是时间、算法或物理实现。用不同的算法重复执行相同的计算任务是算法多样性的一个例子。在 DMR 锁步配置中，当处理单元被复制时，冗余模块的物理布局通常会旋转以实现物理多样性。此外，在 DMR 中，通常会采用延迟的锁步配置来实现时间上的多样性。图 4 显示了 DMR 延迟锁步配置的简化框图。

输入数据直接进入主处理单元，同时延迟一或两个时钟周期，然后进入冗余处理单元。主处理单元的输出作为系统的输出。在与冗余处理单元的输出进行比较之前，它也被分支出来通过延迟块。来自两个延迟块的延迟量应该相同。此配置可防止由时钟毛刺引起的常见故障。

另一种错误检测方法是连续或定期监控(Monitor)关键部件或参数是否有任何异常。监控通常假定零件或参数应在预先假定的正常范围内运行，并标记不在该范围内的行为。监控的示例包括监控电源电压、电流、时钟或总线协议接口。另一个例子是监视处理器单元是否挂起的软件看门狗。

测试(Test)是通过运行Test Pattern或程序并将结果与预先计算的结果进行比较来检测故障。测试和监控之间的主要区别在于监控通常与元素的工作负载执行并行执行。但是，测试通常在元素不主动执行工作负载的测试模式下运行。因此，与监控相比，测试可能会破坏执行上下文。作为安全机制的测试示例包括逻辑内置自检 (LBIST) [14] 和内存内置自检 (MBIST) [26]，它们通常在 SoC 启动或关闭时运行。另一个例子是雷达 MMIC 中的环回测试，用于测试通信数据路径的连通性 [28]。

4.3.2 按目标故障分类的安全机制

Safety Mechanisms Categorized by Targeted Faults

另一种安全机制分类可以基于它们所针对的故障类型。例如，安全机制可以根据它们是否旨在防止单点故障或潜在故障进行分类。单点故障的安全机制是主要的安全机制，因为单点故障本身可能直接违反安全目标。基于冗余错误检测和持续监控的安全机制通常属于这一类。潜在故障通常通过基于测试的安全机制来保护，例如 LBIST 和 MBIST。

但是，基于测试的安全机制并不总是用于检测潜在故障。BIST 机制通常不能用于防止单点故障的原因是 BIST 的持续时间通常比 FTTI 长，并且由于它们的上下文破坏性，它们通常不能在芯片执行工作负载时运行。虽然这通常适用于 MCU，但由于雷达工作周期的特性，雷达前端 MMIC 并不总是如此。在一些雷达应用中，每个雷达工作周期分为一个啁啾期(Chirping)和射频静默期(RF-silence )。MMIC 在啁啾期间发送和接收数据，在射频静默期间处于空闲状态。因此，测试通常在射频静默期运行。在某些雷达应用中，FTTI 被认为是一到两个雷达工作周期，这意味着测试持续时间可以在 FTTI 范围内。此外，MMIC 执行雷达波发射器和接收器的功能，然后将捕获的数据发送到 MCU 进行处理。雷达数据的簿记(bookkeeping)通常发生在 MCU 端。因此，MMIC 通常可以被认为是“无状态的”，并且测试可以被认为是对雷达功能的非侵入性。

另一种分类可以基于安全机制是否旨在防止永久性故障或瞬态故障，尽管有些可以同时防止两者。例如，ECC 可以检测由永久性故障和瞬态故障引起的错误。测试机制通常只能用于检测永久性故障，因为瞬态故障的影响可能在测试运行时已经消失。

4.4 安全验证

Safety Verification

安全验证确保安全架构的实施满足安全要求。请注意，ISO 26262 中定义的术语“Verification”和“Validation”与半导体设计界所指的不同。在 ISO 26262 中，verification的方法包括审查、走查、检查、模拟、形式验证、工程分析等(review, walkthrough, inspection, simulation, formal verification, engineering analysis)。而safety validation具体是指车辆级别的validation。在本文中，我们重点关注汽车SoC安全方面的设计模型的pre-silicon verification （通过仿真和形式化方法）。

functional safety verification 的一种有效载体是故障注入（通常称为故障注入或简称故障活动fault injection or fault campaign ）。它将故障注入设计模型，并通过在相应的点观察安全机制对故障的反应。故障注入仿真的结果可用作支持 FMEDA 中声称的安全机制的诊断覆盖率的证据。故障注入的目标包括：

确认安全机制的诊断覆盖率
确认诊断时间间隔和反应时间
确认故障影响

为了设置故障注入活动，附带内容包括：

Design model：设计模型，可以在寄存器传输级别/门级别，甚至更高级别（例如，SystemC）
Fault sites and fault models：故障地点和故障模型，故障列表可以随机选择或来自已指定关键故障模式
Functional stimulus，功能刺激，它应该代表工作负载或用例。
Observation points：观察点，应观察故障影响和诊断的地方。

根据故障注入的仿真结果结合专家判断，可以根据第 4.1 节中的分类标准对故障进行分类。基于故障分类和诊断覆盖率，FMEDA 报告可以更新为来自详细设计实施的更准确信息。我们将在下一节讨论故障注入的一些技术挑战

5 当前和新出现的挑战

在本节中，我们确定了汽车 SoC 设计和验证方面的几个挑战，以实现当前和下一代产品的功能安全。

5.1 安全和 PPA 之间的权衡

Trade-off between Safety and PP

功能安全是有代价的。安全机制的实施不可避免地会带来性能、功耗和面积 (performance, power and area PPA) 方面的开销。例如，DMR 将模块的面积增加了 1 倍以上。对整个芯片运行 LBIST 会消耗过多的功率。现有的安全分析侧重于故障和诊断覆盖率，并没有将设计开销以定量方式加以考虑。有关 PPA 的安全分析和设计空间探索通常作为单独的过程进行。尽管 SoC 架构师和安全架构师意识到功能安全和 PPA 之间的权衡，但系统地分析它以找到最佳架构仍然具有挑战性。这种分析可以从架构定义的早期阶段开始，并在设计阶段进行迭代。传统设计空间探索中的参数已经非常庞大，增加一个额外的功能安全维度将使问题更具挑战性。

5.2 故障注入的挑战

Challenges with Fault Injection Campaigns

故障注入是验证安全机制有效性和确认安全分析中声称的诊断覆盖率的有效工具。当今的故障注入面临着几个主要挑战

对于现代汽车 SoC 而言，故障领域本质上是巨大的。如果我们使用底层的固定故障模型(lowlevel stuck-at fault models)，考虑到当今汽车 SoC 的大小，在一个合理大小的 IP 块中可能会有数百万个故障。考虑到瞬态故障，额外的时间维度使故障空间更加难以处理。有时，会模拟数十或数百个测试，以确保故障注入的功能上下文能代表 SoC 的实际工作负载，这使其在计算上更加难以承受。

实际上，已经使用人工选择和统计抽样来减少故障空间。手动选择的局限性在于它通常需要专家判断和对特定设计的深入了解。找出手动选择的故障的概率分布以计算诊断覆盖率也是一项挑战。一种常用的统计抽样方法是基于置信水平和置信区间的抽样(confidence levels and confidence intervals)。局限性在于，当置信水平较高且置信区间较窄时，它通常给出一个相当保守的界限，因此样本量可能仍然很大。

对于数字电路，故障仿真(fault simulation )技术的研究已经进行了至少 30 年，并且先进的算法已经商业化，通过同时仿真数千个故障来加速过程[18]。然而，对于模拟故障(analog fault)的仿真，即使可能并发仿真故障，它仍然非常具有挑战性。已经有一些工作使用敏感性分析来加速某些场景中的仿真[12]。然而，在模拟领域(analog domain)中普遍使用并发故障仿真仍然是一个悬而未决的问题。对于模拟和混合信号电路，当前的仿真技术侧重于低级故障模型，这限制了其在更大范围内的仿真应用。正确抽象级别的故障建模对于启用模拟和混合信号 SoC 的故障仿真非常有帮助。

正式的验证方法(Formal verification methods)也被引入故障注入中，以分析故障的传播和检测。有几个限制。形式化方法的可扩展性固有地阻止了对大型设计的应用。此外，如果设计的环境约束条件制定不当，形式化方法往往会发现不切实际的情况，这可能成为工程调试时间的黑洞。

5.3 基于测试模式的安全机制的诊断覆盖范围

Diagnostic Coverage of Test Pattern Based Safety Mechanisms

如今，基于Test Pattern的安全机制越来越受到关注，因为它们需要更少的硬件资源并且更加灵活。但是，此类测试模式的开发工作和复杂性可能具有挑战性。

LBIST 是一种传统上常见的基于测试模式的安全机制，截至目前，它在功能安全方面存在局限性。LBIST 旨在防止潜在故障。然而，LBIST 模式的构建是针对结构性故障覆盖，并没有考虑功能安全背景下的故障分类。LBIST 的 PPA 开销是巨大的。扫描链(Scan Chain)的使用使测试时间变长，因此通常很难满足客户的要求。减少测试时间的技术通常会导致过多的功耗，因为它们往往会增加芯片上的同时活动。因此，工业界一直在向使用功能测试模式(functional test patterns )的自测机制发展，因为它们更加灵活和轻量级，并且可以针对感兴趣的故障进行开发。已经在开发软件测试库上付出了努力，这使得用户不仅可以在重置时运行测试，还可以在应用程序空闲时运行测试。

尽管有明显的好处，但功能测试模式的开发在技术上可能具有挑战性。功能测试模式不能利用扫描链等 DFT 特性，因此在故障的可控性和可观察性方面可能受到限制。由于缺乏功能测试生成工具，可能需要花费大量的工程精力来手动开发测试以实现所需的诊断覆盖率。对帮助生成功能测试的 DFT 技术的研究对于解决这些挑战是非常需要的。

5.4 新兴加速器的安全机制

Safety Mechanisms for Emerging Accelerators

随着特定领域计算的普及，加速器占据了越来越多的芯片资产。在汽车领域，正在为视觉处理、雷达和激光雷达数据处理以及深度神经网络推理设计新的加速器。与 SoC 上的通用组件（例如 CPU、总线和内存）不同，加速器是为特定域中的计算任务而设计的。将传统安全机制（例如 DMR）简单地用于加速器可能并不有效且不具有成本效益。为了有效地为新兴加速器设计安全机制，利用加速器的特定领域性质将是有益的。它要求对硬件和软件进行全面思考，并深入了解系统级安全机制。为特定领域的加速器设计有效的安全机制是一个开放的研究领域，该领域的创新备受追捧。

5.5 实现Fail operational面临的挑战

Challenges with Reaching Fail operational

自动驾驶系统的发展趋势要求未来的汽车电子电气系统实现故障运行。这一要求也可能会传递给汽车 SoC，这意味着 SoC 可以继续正常运行或在降级模式下运行。直观地说，这通常可以通过冗余计算资源来实现。然而，由于汽车市场仍然是一个成本敏感的市场，这意味着应该在不导致不可接受的资源增加的情况下实现这种故障操作行为。虚拟化是一个可能的追求方向，因为它可以提供高可用性来实现故障操作行为。它需要在硬件中进行有效的故障定位并在软件级别处理错误。尽管虚拟化已在云计算中证明是成功的，但在将其应用于汽车嵌入式应用程序时仍有许多悬而未决的问题。

6 近期研究亮点

本节重点介绍最近提出的一些创新和研究工作，这些创新和研究工作旨在为自动驾驶时代的汽车 SoC 实现功能安全。这绝不是一个全面的评论，但其目的是让读者了解该领域的一些有趣作品。

6.1 使能应用相关的安全机制

Enbling Application Specific Safety Mechanisms

由于违反安全目标与项目的功能密切相关，因此对功能的认识将使安全机制最有效地检测和控制系统级别的故障。汽车 SoC 开发的挑战在于应用程序的细节是不可见的，特别是如果它是作为 SEOoC 开发的 MCU。因此，如果 SoC 中有可配置和可扩展的机制，可以提供给Tier 1以实施特定于应用程序的保护，这是非常可取的。最

近一项值得注意的创新是“软件安全”(Safety by Software)概念，通过可配置的安全机制实现，例如“时间监控比较器”（Time Monitored Comparator TMC）和“定时多看门狗处理器”（Timed Multiple-Watchdog Processor TMWDP）[1]“时间监控比较器”在软件锁步的上下文，其中相同的计算任务由两个软件线程执行，很可能具有不同的实现。一个软件线程可能是准确的并且会消耗资源，而另一个线程可能会通过使用较少的资源在一定范围内产生不太准确的结果。传统上，软件锁步要求两个软件线程在前进之前定期同步并比较它们的结果，这会损害性能。TMC 通过使用专用硬件监视器来比较两个软件线程在受控时间间隔内产生的结果来提高性能。因此，它确保了两个线程的结果具有可比性，并且两个线程的推进在有限的时间间隔内。

"定时多看门狗处理器"保护应用软件控制流程的完整性。假设系统应用程序开发人员会知道应用程序软件的高级控制流程。定时看门狗是从控制流转换而来的定时状态机。它检查不正确的状态序列和不正确的状态序列时序和超时（应用程序在一个状态中停留的时间过长）。

6.2 深度神经网络的安全性

Safety of Deep Neural Networks

随着最近在计算机视觉中深度学习应用的突破，深度神经网络（DNN）在从 ADAS 到自动驾驶的道路上越来越受欢迎。在探索和部署 DNN 以完成行人检测、车辆跟踪、路标分类和距离检测等感知任务方面，已经投入了大量的研发工作。有些人甚至尝试使用 DNN 进行端到端自动驾驶 [4]。已经开发了专用加速器，以支持为实时应用程序部署 DNN。然而，与往常一样，此类应用和特殊加速器的安全问题一直是一个关键问题。

DNN 的使用包括两个阶段：训练和推理。训练是指在不失一般性的情况下找到适合训练样本的最优模型的过程。该模型本质上是与 DNN 架构中的神经元相关的整套权重。该模型可以存储在芯片上并加载到应用程序中以对新的数据样本进行预测，这称为推理。

深度神经网络的安全性包括两个方面：预期功能的安全性和功能安全性(safety of the intended function and functional safety )。预期功能的安全性涉及以下问题：如果 DNN 模型将停车标志分类为限速标志，会对安全产生什么影响，该如何减轻这种影响？功能安全涉及的问题是：如果 DNN 加速器中的缺陷改变了它的假定行为，那么安全影响是什么？[10] 在训练或推理过程中可能会发生故障。由于训练通常是离线完成的（作为开发的一部分），训练阶段的故障可以通过彻底的验证来控制。推理阶段随机硬件故障的故障影响和缓解是研究的主要兴趣。

最近的工作探索了现代神经网络中故障的错误传播，并提出了基于实验学习的安全措施[27][7][20]。这些工作的重点是研究推理引擎的架构和设计参数造成的安全影响。或者，也可以探索训练过程中hyper-parameters 对推理的安全影响。更具体地说，dropout 是 DNN 训练中最近的一种正则化技术，用于避免过度拟合 [24]。dropout 的想法是在训练期间断开神经网络层之间的特定连接部分，以便激活不依赖于少数神经元。Dropout 增加了模型中的信息冗余，因此可能使推理更具故障恢复能力。定量地探索其影响将会很有趣。

7 结论

我们概述了与安全相关的汽车 SoC 的功能安全开发。我们描述了一个项目的功能安全开发的整体流程，并详细阐述了实现汽车 SoC 功能安全的实践。我们重点介绍了在 ADAS 和未来自动驾驶应用中实现汽车 SoC 功能安全的挑战和研究工作。尽管本文涵盖了与汽车 SoC 功能安全相关的广泛主题，但我们相信我们只触及了挑战和研究机会的表面。此外，由于篇幅限制，未涵盖与 ISO 26262 相关的某些主题，例如 ASIL 分解和软件工具置信度(ASIL decomposition and software tool confidence level) 。尽管如此，我们希望本文能为半导体专业人士和研究人员提供一个起点，让他们了解工业实践和功能安全方面的挑战。迫切需要将研究推向当前范围之外，以便为未来的自动驾驶开发故障操作系统。

致谢

作者要感谢 Franck Galtie 博士、David Dolezal 和匿名审稿人提供的宝贵反馈和技术建议

参考文献

[1] D. Baca. Safety by software, 2017.

[2] A. Barber. Status of work in process on iso/sae 21434 automotive cybersecurity standard.
[3] M. Blazy-winning. Seooc component safety architectures for fail safe and fail operational systems. In IQPC Application of ISO 26262 to Semiconductors Conference, 2017.
[4] M. Bojarski, D. D. Testa, D. Dworakowski, B. Firner,B. Flepp, P. Goyal, L. D. Jackel, M. Monfort, U. Muller,J. Zhang, X. Zhang, J. Zhao, and K. Zieba. End to end learning for self-driving cars. CoRR, abs/1604.07316, 2016.
[5] W. Chen and J. Bhadra. Striking a balance between soc security and debug requirements. In 29th IEEE International System-on-Chip Conference, SOCC 2016, Seattle, WA, USA,September 6-9, 2016, pages 368–373, 2016

[6] W. Chen and J. Bhadra. Striking a balance between soc security and debug requirements. In 29th IEEE International System-on-Chip Conference, SOCC 2016, Seattle, WA, USA,September 6-9, 2016, pages 368–373, 2016.

[7] F. F. dos Santos, L. Draghetti, L. Weigel, L. Carro, P. O. A. Navaux, and P. Rech. Evaluation and mitigation of softerrors in neural network-based object detection in three GPU architectures. In 47th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops, DSN Workshops 2017, Denver, CO, USA, June 26-29, 2017, pages 169–176, 2017.
[8] R. E. McDermott, R. Mikulak, and M. R. Beauregard. The basics of FMEA. 01 2008.
[9] N. N. C. for Statistics and Analysis. Critical reasons for crashes investigated in the national motor vehicle crash causation survey, 2015.
[10] K. Greb. Safety of deep neural networks (dnns) for autonomous driving. In IQPC Application of ISO 26262 to Semiconductors Conference, 2017.
[11] R. W. Hamming. Error detecting and error correcting codes. The Bell System Technical Journal, 29(2):147–160, April 1950.
[12] H. Hashempour, J. Dohmen, B. Tasic, B. Kruseman, C. Hora, M. van Beurden, and Y. Xing. Test time reduction in analogue/mixed-signal devices by defect oriented testing: An industrial example. In Design, Automation and Test in Europe, DATE 2011, Grenoble, France, March 14-18, 2011, pages 371–376, 2011.
[13] R. T. Hessian, B. B. Salter, and E. F. Goodwin. Fault-tree analysis for system design, development, modification, and verification. IEEE Transactions on Reliability, 39(1):87–91, April 1990.

[14] G. Hetherington, T. Fryars, N. Tamarapalli, M. Kassab, A. Hassan, and J. Rajski. Logic bist for large industrial designs: real issues and case studies. In International Test Conference 1999. Proceedings (IEEE Cat. No.99CH37034), pages 358–367, Sep. 1999.

[15] Road vehicles – functional safety. Standard, ISO, 2011.
[16] Road vehicles – safety of the intended functionality. Standard, ISO.
[17] Taxonomy and definitions for terms related to driving automation systems for on-road motor vehicles. Standard, SAE International, Jun 2018.
[18] H. K. Lee and D. S. Ha. An efficient, forward fault simulation algorithm based on the parallel pattern single fault propagation. In Proceedings of the IEEE International Test Conference on Test: Faster, Better, Sooner, pages 946–955, Washington, DC, USA, 1991. IEEE Computer Society.
[19] W. S. Lee, D. L. Grosh, F. A. Tillman, and C. H. Lie. Fault tree analysis, methods, and applications amp;2013; a review. IEEE Transactions on Reliability, R-34(3):194–203, Aug 1985.
[20] G. Li, S. K. S. Hari, M. Sullivan, T. Tsai, K. Pattabiraman, J. Emer, and S. W. Keckler. Understanding error propagation in deep learning neural network (dnn) accelerators and applications. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC ’17, pages 8:1–8:12, New York, NY, USA, 2017. ACM.
[21]PricewaterhouseCoopers. Five trends transforming the automotive industry. Technical report, 2017.
[22] S. Ray, W. Chen, J. Bhadra, and M. A. Al Faruque. Extensibility in automotive security: Current practice and challenges: Invited. In Proceedings of the 54th Annual Design Automation Conference 2017, DAC ’17, pages 14:1–14:6, New York, NY, USA, 2017. ACM.
[23] E. Ruijters and M. Stoelinga. Fault tree analysis. Comput. Sci. Rev., 15(C):29–62, Feb. 2015.
[24] N. Srivastava, G. Hinton, A. Krizhevsky, I. Sutskever, and R. Salakhutdinov. Dropout: A simple way to prevent neural networks from overfitting. Journal of Machine Learning Research, 15:1929–1958, 2014.
[25] K. L. Tai. System-in-package (sip): challenges and opportunities. In Proceedings 2000. Design Automation Conference, pages 191–196, Jan 2000.
[26] M. H. Tehranipour, Z. Navabi, and S. M. Fakhraie. An efficient bist method for testing of embedded srams. In ISCAS 2001. The 2001 IEEE International Symposium on Circuits and Systems (Cat. No.01CH37196), volume 5, pages 73–76 vol. 5, May 2001.
[27] O. Temam. A defect-tolerant accelerator for emerging high-performance applications. SIGARCH Comput. Archit. News, 40(3):356–367, June 2012.
[28] J. . Yoon and W. R. Eisenstadt. Embedded loopback test for rf ics. IEEE Transactions on Instrumentation and Measurement, 54(5):1715–1720, Oct 2005.

实现现代汽车SoC功能安全的实践和挑战相关推荐

汽车SoC全生命周期功能+网络安全架构设计
随着汽车电子产业的快速发展,供应链中复杂的SoC设计,硅片生命周期管理(SLM)以及芯片现场监控和管理面临新的挑战. 要确保这些复杂设备正确和安全的运行,不仅需要功能安全来检查由于硅缺陷和老化导致的可 ...
汽车SoC安全故障的自动识别（下）：案例展示和指标分析
概要 <汽车SoC安全故障的自动识别>专题连载共分为"上.下"两个篇章.此文为该连载系列的"下"篇章,在该专题连载的"上&q ...
汽车SoC芯片IP供应商
汽车SoC芯片IP供应商汽车IP主要包括接口IP.存储IP.处理操作IP以及安全IP.细分开来看,在接口IP方面,目前主流的是1Gbps的Ethernet TSN,未来汽车以太网将迁移到2.5Gb. ...
智能汽车预期功能安全保障关键技术
本文作者邵文博.李骏.张玉新由于性能局限.规范不足或可合理预见误用导致的预期功能安全问题层出不穷,严重阻碍了智能汽车的快速发展.本综述聚焦智能汽车预期功能安全保障关键技术,分别从系统开发.功能改进和 ...
Mobileye、地平线、芯擎、寒武纪、芯驰等汽车SoC芯片背后的IP供应商——Arteris
"智能汽车生态群"加微信Time-machine-(备注公司+姓名) Mobileye.地平线.芯擎.寒武纪.芯驰.黑芝麻.杰发.宸芯这些汽车SoC芯片厂家背后都有Arteris的 ...
Flink SQL 1.11 新功能与最佳实践
#2020云栖大会#阿里云海量offer来啦!投简历.赢阿里云限量礼品及阿里云ACA认证免费考试资格!>>> 整理者:陈婧敏(清樾) 本文整理自 Apache Flink PMC,阿 ...
汽车APP功能开发特点主要有哪些
移动汽车行业蕴藏着巨大的市场发展潜力,一方面是汽车行业市场规模增大,另一方面是移动互联网日渐发达.全国民用汽车量逐年稳定攀升,私人汽车数量持续增长. 汽车APP功能提供各种汽车车型对比.驾照试题.买车 ...
智能网联汽车-网联功能与应用（CFA）标准制定路线图
智能网联汽车-网联功能与应用(CFA)标准制定路线图智能网联汽车-网联功能与应用(CFA)标准制定路线图摘要一.分析国内外汽车网联技术发展战略.应用状态和标准法规进展情况. 二.明确汽车网联技术 ...
HTML5期末大作业：汽车商城网站设计——汽车商城-功能齐全(42页) 大学生汽车商城网页设计模板代码网购网页作业成品汽车商城网站设计成品
HTML5期末大作业:汽车商城网站设计--汽车商城-功能齐全(42页) 大学生汽车商城网页设计模板代码网购网页作业成品汽车商城网站设计成品常见网页设计作业题材有个人. 美食. 公司. 学校. ...

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

实现现代汽车SoC功能安全的实践和挑战相关推荐

最新文章

热门文章