冯国元先生在汽车芯片功能安全领域具有丰富的工作经验，主导曦华科技蓝鲸系列车规MCU产品顺利通过功能安全ASIL-D流程及ASIL-B产品认证工作。
一、前言
汽车行业正经历着“新四化”从概念向实际转化的过程（新四化即电动化、智能化、网络化、共享化），各大车企也将调整发展布局，混合动力及电动汽车成为主要关注点。汽车行业近年来出现了一些趋势：
首先，随着政府推动更安全、更清洁的交通，进一步地综合降低排放被提上汽车制造商的议事日程，这导致汽车加速电气化。
其次，自动驾驶汽车成为许多传统汽车制造商和市场新参与者的新追求。随着人工智能和机器学习的快速迭代和发展，以及软件定义汽车等新兴概念，需要先进制程支持的超高算力SoC作为硬件支持。而作为执行端的边沿节点需要完成局部的安全管控，并未降低安全要求。
另外，作为“物联网”的重要组成部分，汽车将与外界连接，实现信息娱乐和高级驾驶辅助系统（ADAS）。新的网络架构及部署，需要SoC或MCU从硬件上支持巨大的数据吞吐率，包括数据交换及处理能力。比如，以千兆甚至更高速率以太网作为on-board通讯骨干网络，芯片间高速通讯如HSSL、PCIe等PHY接口。这些说明数据信息也更重要，应得到有效的保护。
在这些大趋势的推动下，最近汽车中的大多数创新功能都在电子和软件中实现，导致车辆中电子和软件组件的复杂性急剧增加。现代汽车可以包含200多个电子控制单元 (ECU)、多个车载通信网络和数百MB的软件。复杂性增加的一个明显后果是电子和软件中的缺陷和故障增加，这可能导致道路事故。因此，车辆中的电气和电子 (电子电器) 系统的功能安全已成为重中之重。
作为整体车辆安全的一部分，功能安全要求电子和软件的故障免于对道路车辆和行人造成伤害。通常来说，要求确保所设计的系统通过检测出功能故障，并及时采取适当的反应和处理，将故障行为可能带来的危害能够减轻或者免除，例如，通过系统的紧急反应或通知到驾驶员采取行动，并最终通过系统进入安全状态。如何检测和减轻危害在很大程度上取决于发生故障的特定功能，并综合考虑整个车辆上下文及功能运行的环境条件。
二、功能安全关注点
自汽车诞生以来，道路车辆的安全性一直是汽车行业最关心的问题。从当前车辆的发展来看，一辆安全的车辆包括四个要素：
- 道路车辆功能安全关注减少人为失误造成的事故。
截至今天，94% 的道路事故是由人为错误造成的。ADAS 技术的开发旨在减少人为错误造成的事故，许多汽车制造商正在积极致力于自动驾驶，最终将人为因素排除在外。
- 产品可靠性及产品的零缺陷(Zero Defect)目标。目标是要求提高制造质量和设计鲁棒性，以满足功能安全对于汽车产品可靠性的基本要求。
- 功能安全关注汽车系统故障不会造成任何事故(zero accidents caused by E/E system)
- 车辆参与“万物互联”，数据信息安全应被确保
当我们将功能安全定义为整体车辆安全的支柱之一时，我们回顾了功能安全与其他车辆安全支柱的区别。希望我们可以通过详细说明功能安全不是什么来阐明什么是功能安全。
2.1 功能安全与可靠性
Functional Safety is based on Reliability, but not Reliability
可靠性是指元件、产品、系统在一定时间内、在一定条件下无故障地执行指定功能的能力或可能性。假定一个产品运行足够长的时间，一定会发生故障造成功能失效。通常可通过可靠度、失效率、平均无故障间隔等来评价产品的可靠性。车规级，工业级，军工级芯片对可靠性提出了更严苛要求，下表给出的影响可靠性的因素和不同应用对于芯片产品可靠性的要求。
可靠性工程关注组件的失效机制以及如何提高制造质量和设计鲁棒性以降低组件的失效率。失效率可以定义为组件工作到时间t之后发生失效的概率，以每单位时间的故障数表示（半导体通常以小时为单位）。功能安全关注的是由于组件故障导致的系统级故障，以及如何控制和减轻组件的故障影响以防止系统故障造成伤害。换句话说，虽然没有办法保证任何组件可以做到完全可靠，功能安全旨在解决某个组件发生故障时，仍能保证进一步的系统故障带来危害。
虽然可靠性并不等同于功能安全去理解，但它确实会影响功能安全，因为失效率数据可能会影响用于控制和减轻组件故障的安全措施。例如，随着半导体新工艺的应用及芯片电路规模的扩展，可能会造成芯片上的Transient Fault和Soft Error进一步增加，但这也将会推动功能安全从架构上采取针对此类故障的更有效的安全机制。
2.2 功能安全与Semiconductor
芯片上系统所构成的电路，可按照功能划分为一些能够处理的模块，定义模块之间的关系；设计时通过电学特性规范，给出时序信息作为设计的约束。在芯片架构设计、详细设计，在以下层级展开设计实现和验证：
- 系统级：行为和性能的描述，初步确定应用对芯片功能和性能指标的要求，以及哪些功能可以集成，哪些功能只能外部实现，芯片工艺及工艺平台的选择，芯片管脚数量，封装形式等。
- 算法级：快速验证算法的正确性，不一定可以综合成实际电路结构。
- 结构级：更接近电路的实际结构，电路的层次化描述，类似电路框图。
- 行为级：行为级是RTL级的上一层，更符合人类思维的描述方式。用于快速验证算法、逻辑的正确性，不关注电路的具体结构，不一定可以综合成实际电路结构。
- RTL级：使用寄存器这一级别的描述方式来描述电路的数据流方式。接近实际电路结构的描述，可以精确描述电路的原理、执行顺序等。
- 门级：使用逻辑门这一级别来描述。RTL 中的寄存器和组合逻辑，其物理实现对应到具体门电路。一般EDA工具可以把RTL描述编译为门级描述。
- 器件级：完整描述了电路的细节，最底层的电路描述，可以描述PMOS/NMOS。
假如从根本的失效机理，对于半导体产品可以从器件级（Device Level）进行分析，有三种常见机理：
- HCI (Hot Carrier Injection)
- N\PBTI (Negative/Positive Bias Temperature Instability)
- TDDB (Time Dependent Dielectric Break-down)
这三种效应会使得器件的性能随着时间的推移发生衰减，进而影响整个芯片产品的可靠性，或导致器件上一级部件/子部件的功能失效。
对于半导体产品应在合适的层级进行安全分析及验证：
- 从使用者角度，根据电路不同目的，可以按照功能抽象在不同的层级进行故障注入(例如，半导体组件顶层、部件或子部件级别、或者门级等)。
- 在相应的抽象层级设置观测点观察故障及其影响，和诊断点以测试安全机制反应。
2.3 功能安全与信息安全
功能安全开发的一个思路是将产品运行时，可能到来危害的风险准确的识别出来，这样在产品的开发及生产过程中采取必要的措施进行风险的管控，降低风险水平。在最终产品交付时，产品已实现的安全措施包括：失效率数据、安全机制，应以文档化的形式明确给出。
信息安全要求车辆的电子电器(E/E)系统和软件组件必须能够抵御系统黑客攻击。损害系统中资产的机密性和完整性可能会侵犯系统的安全性。汽车电子电器(E/E)系统中的资产示例包括修整值(Trim Values)、固件执行流程、加密密钥和用户身份信息。Confidentiality 机密性要求未经授权的代理不能访问资产。此要求适用于用户隐私信息等资产。Integrity完整性要求保护资产免受未经授权的修改。这一要求通常对于作为信任根的资产至关重要，例如安全启动固件。传统上，Security过去对汽车来说不太重要，因为安全攻击只有在恶意代理可以物理访问汽车时才可行。但是，随着汽车之间和外部世界的高度连接，远程攻击成为可能。汽车的数据越多，汽车的问题也会越多。数据变得越来越有用和及时，但并不是每个人都可以访问它。
随着汽车越来越智能化，从汽车流向云端的数据量正在迅速增长，这些数据对于设计更好的系统至关重要。GDPR(欧盟的通用数据保护条例)准确地规定了哪些数据可以移动以及如何移动它。整车厂确保移动的数据不会泄露任何私人信息，也不会增加安全风险。
2020年，UN/WP.29(联合国世界车辆法规协调论坛)发布了首个汽车网络安全强制法规R155。其主要适用范围包括了欧洲、日本、 韩国等“1958 协议” 缔约国（以下简称“58 协议国” ），要求2024年7月在“58协议国”上市的汽车必须通过网络安全管理体系认证和车辆类型审批认证。
上述法规限制在体系的认证，而车辆完整生命周期的网络安全实施落地则需要进一步细化，因此SAE和ISO基于R155于2021年8月底发布了汽车网络安全领域的首个国标，即现在的ISO/SAE 21434。主要关注道路车辆电子系统中的网络安全风险，涵盖车辆生命周期的所有阶段。汽车电子电器(E/E)系统的信息安全问题将在ISO 21434“道路车辆 – 汽车网络安全工程”中得到解决。
“功能安全”问题是系统故障不应导致危害事件，而故障可能归因于开发错误或随机硬件故障。信息安全问题是Confidentiality和Integrity不应被恶意破坏，导致数据完整性的丧失，进而可能会导致有害事件。一个显著的区别是，信息安全涉及由于恶意“代理人”的故意攻击而导致的故障，而Safety涉及由于“意外事件”而导致的故障。
2.4 功能安全与可用性
系统的可用性通常是非常必要的，但是，对于维护车辆的安全性并不总是必要的。系统功能不可用并不总是意味着违反安全规定。例如，如果在发动机点火时的自检过程中检测到 ECU 出现故障，则 ECU 将中止发动机启动。在这种情况下，如果 ECU 功能出现故障，可用性就会丢失。然而，车辆仍处于安全状态并因此保持功能安全。
2.5 功能安全与预期功能的安全
ADAS 系统使用复杂的传感器和处理算法来感知周围环境和驾驶情况，以协助驾驶员，从而减少人为错误。ADAS系统正确的周围环境感知对车辆的安全性至关重要。与许多完善的系统（例如动态稳定控制系统）不同，ADAS 系统的意外行为，由于技术和系统缺陷和/或可合理预见的误用，可能导致危险事件。
预期功能的安全是在ISO 26262涵盖的故障范围下，针对使用特定功能的安全性(通常在ADAS系统中)。比如，摄像头被大量用于ADAS系统中的对象检测。但摄像头的感知可能存在技术或性能限制，这应在系统投入使用前是可预见的。CMOS 摄像头的一个限制的例子是，当车辆从一个长的黑暗隧道驶出时，摄像头可能会在几秒钟内处于过饱和状态，因此在一段时间内无法检测到物体。这种情况摄像头并没有故障或失效，因此不是功能安全的问题。但如果车辆仅依靠摄像头的感知来实现驾驶辅助，摄像头的性能限制可能会导致危险事件。
按照功能安全的定义和要求，不因为“设计行为改变”而受到影响。意味着，如果 “设计行为改变”现象发生，系统的其他部分应该能够做出反应，以确保整个汽车在安全状态下运行。ADAS从许多传感器获取输入，并使用人工智能来确定和决策下一步要做什么。通过将此类要求用于ADAS，安全的定义将是，“如果任何输入，例如激光雷达，发送了错误的图像或其中有故障，系统的其余部分应该能够纠正或检测，或至少警告用户系统中发生了一些事情，不再能够做出决策。”
因此，应采取预防措施，例如使用多种传感器进行感知，以避免此类错误,预期功能的安全性应由正在开发的ISO 21448解决。但功能安全所要求的对硬件涉及安全故障的识别和危险判断，是ADAS系统进行正确感知和决策的基本条件。
三、汽车芯片功能安全开发
无论按照功能安全相关项的开发，或者按照SEooC方式进行的产品开发，都应明确定义其安全生命周期。虽然相关项或者SEooC的生命周期的部分活动可以进行合理的裁剪，可能涉及基于某个变更或者不适用的条件，但功能安全产品开发的起始都是基于风险的分析和识别，并以此推导和建立产品顶层的安全需求（比如，相关项的安全目标），从而开展进一步的安全开发活动。
3.1 风险的分析与识别
IEC 61508 是适用于各行各业电子电器(E/E)系统的基本功能安全标准。它涵盖了安全相关的电子电器(E/E)系统的安全管理、系统/硬件设计、软件设计、生产和运行。ISO 26262 是对作为汽车电子电器(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所示。由于汽车MCU是车辆级别的安全相关产品的一部分，它将有利于半导体专业人士了解整个安全生命周期以及 OEM、一级供应商和半导体供应商的相应角色和责任。因此，在关注汽车 MCU 之前，我们将在本节中描述生命周期各个阶段的开发活动。
3.2 必要的措施防范风险
3.2.1 系统性风险
系统性故障在ISO 26262中的定义为“以确定的方式，或与特定原因相关的故障，只能通过改变设计或制造过程、操作程序、文件或其他相关因素来消除。” 或者换一个角度，系统性故障是设计中的错误或疏忽，是开发过程、制造过程中的人为错误的结果。系统性故障的根本原因都通过过程的完善和优化进行改进，防止系统性风险的发生。
具体硬件组件的故障也可分为系统性故障和随机性故障，如下图所示。系统故障源于设计、开发或制造过程中的不足，通常源于开发过程中的差距。芯片缺陷是一种系统故障，因为它在开发的设计验证阶段是可以检测到的。例如，设计一辆汽车并指定它将有方形车轮将被认为是一个系统错误，因为汽车不能与这种形状的车轮一起工作。通过坚持严格的开发过程，可以通过持续的过程改进来管理和减轻系统错误——甚至完全消除它们。
3.2.2 硬件随机失效的检测
相比系统性故障，随机硬件故障是无法预测硬件会何时发生故障。ISO 26262中随机硬件故障定义为“在硬件元素的生命周期内可能不可预测地发生的故障，随机故障的发生遵循一定概率分布”。随机故障背后的逻辑是，“某个硬件可以在设计和制造过程中完美无缺地避免任何系统性故障，但硬件并不是永远100%可靠的，随着时间的推移，它可能发生会故障或者说发生故障的可能性。”
- 硬错误/Hard Error
另一方面，随机的硬件故障是无法消除的。它们源于所有电子系统最终都会失效的事实。因此，处理随机硬件故障的能力仅限于检测和可能的预防故障。就汽车电气、电子和可编程电子系统而言，提醒驾驶员注意问题可以在一定程度上控制随机硬件故障的影响。
基本故障率(BFR)量化了半导体元件在正常环境条件下工作时的内在可靠性。BFR通常乘以温度、电压和工作小时数等因素，以得出组件质量的定量度量。
Technologybased
Stress factor: not considered for noninterface IC
Missionprofiles:temperaturecyclefactor
Thermal expansion factor and package type
Missionprofiles:temperaturecycle,duration
- 软错误/Soft Error
由可能导致随机硬件故障的辐射事件(内部或外部)引起的软错误，必须在BFR估计中考虑在内。然而，由电磁干扰或串扰引起的软误差不包括在BFR计算中，因为这些被归类为系统故障，通过坚持良好的设计实践可以管理。可以通过以下属性来对瞬态故障进行管控：
- 使用的工艺
- 故障的影响和适用的时机
- 封装中的标准、低alpha、超低alpha封装材料
架构脆弱性因子(Architectural Vulnerability Factor, AVF)是指由于软错误而导致设计结构中的错误，在功能的最终输出中导致可见错误的概率。根据ISO 26262，软错误的BFR不应该基于AVF或“错误检测及校正”电路等安全机制而降低。
因此，对于半导体元件中的随机存取存储器和逻辑块，最好分别计算软错误的BFR。
- 适合的安全机制/Safety Mechanisms
Safety Mechanisms Categorized by Error Detection Methods
许多安全机制有效性依通过检测故障和错误的能力，即诊断覆盖率进行评估。检测方法大致分为三种：冗余、监控和测试。
冗余错误检测利用冗余计算或存储来检测目标函数中是否存在错误。冗余通常来说有三种不同类型：
硬件冗余：Hardware redundancy 在不同的硬件模块上执行相同的计算，因此如果功能模块中存在导致错误的故障，则很可能通过比较结果来检测冗余模块。双模块冗余 (Dual Module Redundancy，DMR) 常用于汽车 MCU，其中两个处理单元同时执行相同的计算任务（在锁步模式下），它们的结果由检查器模块进行比较。DMR 允许错误检测，但不能自行纠正错误。错误处理通常由系统的其他部分完成。三模块冗余 (Triple Module Redundancy，TMR) 允许错误检测和纠错，但需要额外代价。TMR 主要用于 MCU 级别的关键寄存器，例如存储修整值的寄存器，由三重投票触发器 (Triple Voting for Flip-flops，TVF) 实现。
信息冗余：Information Redundancy 利用信息编码的冗余来检测并有时纠正错误。示例包括纠错码 (ECC) 、循环冗余校验码(CRC)和奇偶校验(Parity)。这种类型安全机制通常用于通信通道和内存的数据保护。
时间冗余：Time redundancy 重复执行相同的计算或者复杂逻辑，物理上的冗余技术上已经不可行时，可在相同的硬件中但使用不同的算法。通过重复计算，它也可能检测出计算中是否存在Soft Error。在计算中使用不同算法的情况下，甚至可以检测到硬件中的永久性故障，因为不同的算法可能会使用同一硬件元件的不同部分。
注意冗余通常与多样性结合使用，以避免共因故障。多样性可以是时间、算法或物理实现。用不同的算法重复执行相同的计算任务是算法多样性的一个例子，但存在相同硬件的共因，必要的硬件独立的看门狗定时器，对计算完成的时间进行监控是必要的。另外在以上 DMR 锁步配置中，当处理单元被复制时，冗余模块的物理布局通常会取反（反逻辑设计）以实现物理多样性。此外，在 DMR 中，通常会采用延迟的锁步配置来实现时间上的多样性。框图给出了DMR延迟锁步配置的简化框图。
四、需求驱动的开发方法
4.1 安全需求识别和定义
项目开发过程，其中所有的活动都有明确的“需求”输入。根据项目的复杂性，要对各个抽象层次的需求进行区分和管理。在安全生命周期过程中，安全需求通过分层结构进行定义和细化。如下图所示，安全需求被分配给要素或在要素间接口。
对于安全性需求的定义，应基于风险进行充分分析，并和市场、设计、验证成员讨论和确认。由上而下的安全性需求的推导，从安全目标，功能安全需求，技术安全需求，至硬件/软件安全需求及接口，推导过程是符合标准要求的，但对团队来说其实面临比较大的挑战。另一个可行的方法，对于某些component，可根据设计经验或者IP 供应商提供的安全资料，基于一定的分析，在较低的层面提出比较具体的安全需求，并与至顶而下的安全需求从概念上合并完善。对于安全性需求，有个大的原则：
- As much as necessary, as little as possible
为保证适宜的安全性，尽必要地多、尽可能的少
- The Higher the Risk, the Greater the Care We Must Exercise
风险越高，我们必须越小心地关注和处理
4.2 需求的特性
一般来说需求是自然语言描述的，这让我们很难量化评价其好坏，暂且给出需求的几个特性做参考，尤其对于安全需求应具备的特性：
- 明确的：对需求的意思存在共同的理解。
- 可理解的：需求的相关者和使用者理解需求的意思。
- 不可分割的：一个层面的安全需求在所考虑的层面上不能被分解为至少两个独立的安全需求。
- 内部的一致性：每个单独的安全需求不包含自相矛盾的内容。
- 可行的和可达成的：个需求在相关项的开发限制(资源、当前技术水平)内可被实现，不需要有重大的技术进步。
- 可验证的：在指定的层级上有方法可以检查需求是否被满足；或收集到的相关项的证据表明相应的需求已经得到满足。
- 必要的：需求定义了基本的能力、特征、约束和/或质量因素。如果将其删除，会导致产品或流程的其他功能无法满足。
- 便于实现的：需求在处理相关项的必要和充分条件的同时，避免对架构设计设置不必要的约束。需求说明了需要什么，而不是应该如何满足需求。
- 完整的：所阐述的需求是清晰的，不需要进一步的扩展。
- 合规的：所阐述的需求符合政府、汽车行业和产品标准。
需求的制定主要目标是将对产品所提的技术要求和安全要求，有效地传递给设计团队，进行设计开发和有针对性的验证。所以需求可以按照规范化的格式进行表达，比如以下格式。
基本构成要素：
- 在什么前提条件（逻辑条件或事件发生或时间段）下，
- 什么系统（或组件）
- 必须（英文中常分别用具备法律强制意义的shall），或应该（可以有争论空间的should），或将会及一般性描述的will）
- 实现途径（能够或通过什么流程）
- 什么目标以及其他细节。
4.3 需求评审
评审是我们解决个体能力不足的几乎唯一的手段，对于需求的评审是非常必要的，尤其针对功能安全的部分。本文这里不再展开。
五、总结
安全是非常严谨的系统工程，从产品市场调研，需求分析及系统构架，再到具体的设计人员，充分的验证及测试，直至生产的质量的管控。而产品投放市场后，现场数据的搜集，安全异常的有效解决及跟踪追溯，需要各个环节的工程师并肩合作。从开发的角度，安全本质上是产品的一个属性，至关重要，将安全需求视为功能需求的一个子集，脱离产品开发实际讨论安全设计会使安全无用武之地；另一方面、开发工程师是产品正真的设计和实现人员，对产品的设计及测试有深刻的认识，将安全需求解读成设计理解的语言，需要做充分的对齐。
作者：冯国元
文章来源：汽车电子与软件
推荐阅读
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
