汽车SoC功能安全最佳实践与挑战

欢迎大家来到IT世界,在知识的湖畔探索吧!

1►

汽车SoC的功能安全性

在本节中，我们将详细介绍与安全相关的汽车SoC中硬件和软件的功能安全开发。关于如何开发安全相关的汽车SoC，有两种范例。一方面，SoC可以进行定制开发，即满足Tier 1供应商针对特定系统的特定要求。

在这种情况下，SoC开发从系统级技术安全概念作为输入，以得出SoC级技术安全概念。另一方面，SoC可以开发为非定制的安全元素（SEooC），这意味着它不受特定系统的约束，但可以用于类似的几个系统的应用。

在这种情况下，SoC开发从系统级技术安全概念和系统设计的假设开始。随着半导体公司努力通过使用其设计的芯片作为Tie 1供应商的设计参考来推动价值创造,SEooC开发模式最近越来越受欢迎。SEooC的开发需要更多的努力，因为它倾向于对系统做出更保守的假设。

请注意，由于汽车SoC仅是功能的一部分，相关项的概念阶段的许多主要步骤（相关项定义、HARA和功能安全概念）将不会出现在汽车SoC的开发中。除安全确认仅在车辆级别进行外，安全相关SoC的开发过程中的其他步骤与裁剪的“ISO26262：基于风险的开发方法”一节中描述的类似。

因此，在本节中，我们不再重复解释该过程，而是将深入探讨该过程中的一些技术活动。由于故障的概念对于理解安全架构和实施至关重要，我们首先从功能安全的角度回顾故障。然后，我们讨论了用于推动安全架构开发和验证的安全分析。我们还详细介绍了汽车芯片中常用的安全机制，然后讨论了安全相关SoC的验证。

功能安全方面的故障

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

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

系统性故障是由规范或设计问题引起的，并以确定性的方式表现出来。系统性故障可能发生在软件和硬件上，只有通过改进开发过程，包括安全分析和验证等措施。最常见的系统性故障是开发缺陷。

随机性硬件故障在硬件组件的使用寿命内不可预测地发生，并且是由于物理过程造成的，如磨损、物理退化或环境压力。随机的硬件故障可以通过可靠性工程来减少，但不能完全消除。

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

永久性故障发生，并一直持续到移除或修复为止。示例包括固定性故障和桥接故障。

瞬时故障发生一次，然后消失。由于电磁干扰或阿尔法粒子等原因，可能会出现瞬时故障。随着技术节点规模的缩小，触发器和存储器阵列等存储器元件越来越容易出现瞬时故障。例子包括单粒子翻转（SEU）和单粒子瞬态（SET）。

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

图 1. ISO 26262 定义的故障分类

（感知多点故障在此处不被考虑视为与SoC级别无关）

要对故障进行分类，我们首先需要确定故障是否在安全相关元素内。如果不是，则该故障无关紧要，可以视为安全故障，不包括在安全分析中。如果该元素是安全相关的，那么问题是，在没有安全机制的情况下，故障本身是否有可能直接违反安全目标。如果不是，则可以暂时搁置该故障，之后再考虑。如果该故障可能违反安全目标，那么下一个问题是是否存在安全机制。

如果没有，则该故障属于单点故障 (SPF)，这对于安全架构来说通常是不希望出现的。在存在安全机制的情况下，并不是所有的故障都能被覆盖。如果故障不能被安全机制覆盖，则将其归类为残余故障。

对于被安全机制所覆盖的单点故障，在存在安全机制的情况下，它们不会违反安全目标。连同没有潜在违反安全目标的故障（我们之前将其搁置一旁），根据它们违反安全目标的可能性以及另一个独立故障（二阶效应）对它们进行评估。如果没有这种可能性，则该故障被认为是安全故障。如果双点故障有可能违反安全目标，则评估是否有安全机制来防止它发生。

如果没有这方面的安全机制或安全机制无法覆盖，则归类为潜伏多点故障（MPFs,Latent）或简称潜伏故障。否则为可检测到的多点故障（MPFs,Detected）。无需将故障与其他两个独立故障一起考虑，ISO 26262将阶数大于2的多点故障视为安全故障（在汽车领域发生的概率极低）。

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

安全分析

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

故障树分析

FTA 是一种自上而下（演绎）的分析方法，从故障影响开始分析所有可能的故障原因。它使用故障树作为故障逻辑组合的图形表示。图 3 显示了一个示例故障树，用于分析微控制器单元 (MCU) 的故障。它从一个顶事件开始，然后使用 AND 或 OR 等逻辑门将其分解为底事件。对于每个安全目标，可以绘制故障树，顶事件通常是导致违反安全目标的危害。在此示例中，顶事件是 MCU 执行错误计算而没有指示。

MCU的顶事件可归因于 MCU 子组件失效的逻辑组合。可以进一步分析 MCU 的子组件失效，例如CORE0，以将原因追溯到其子组件。底事件是无法进一步分析的事件，它在叶节点处停止故障树分析。通过将失效原因追溯到底事件，安全架构师可以识别架构中的位置，以分配安全机制来控制基本事件。因此，FTA 可以作为推动安全架构发展的有效工具。

在构建故障树后，可以进行割集分析以确定安全架构中是否存在单点故障。割集是可以导致顶事件的底事件的组合。具体来说，如果当从集合中删除任何底事件时，其余事件将不再是一个割集，则称该割集为最小割集。割集的阶级是指割集中底事件的数目。例如，在图2中，EV1和EV2构成了2阶最小割集。

1阶最小割集表示安全架构中存在单点故障，这表明应该添加安全机制来控制它。虽然FTA通常用作定性分析方法，但FTA也可进行定量分析，可以计算顶事件的概率。

图 2. 用于分析 MCU 失效的故障树示例

失效模式和影响分析

FMEA 是一种自下而上（归纳）的分析方法，重点关注系统的各个部分如何失效（失效模式），以及这些失效对系统的影响。FMEA 可以作为 FTA 的补充，并可用于交叉检查。

失效模式、影响和诊断分析

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

假设与安全相关的硬件元素的原始故障率为 λ。从故障分类中，我们有

(1)

其中λSPF是与单点故障相关的失效率，λRF是与残余故障相关的失效率，λMPF ,D是与探测到的多点故障相关的失效率，λMPF ,L是与潜伏多点故障相关的失效率，λS是与安全故障相关的故障率。

诊断覆盖率可以声明与残余故障和潜伏故障有关的安全机制。SPFM定义为

(2)

其中

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

LFM 定义为

(3)

其中

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

除了SPFM和LFM，还可以计算硬件随机失效 (PMHF) 的概率度量，以评估违反系统级安全架构安全目标的总体概率。这是为了证明由于随机硬件故障而导致违反安全目标的剩余风险足够低。虽然PMHF通常是在系统级计算的，但有时会假设PMHF在SoC层级不应超过特定安全等级对应的量化要求，并提供给系统设计人员以供参考。PMHF可以通过使用 FMEDA或定量 FTA 来计算的失效率。

相关失效分析

相关失效分析(DFA)包括识别和分析给定元素之间可能的共因失效和级联失效，违背安全目标（或安全需求）的风险评估以及定义减轻风险的必要安全措施。其目的是评估潜在的安全概念的弱点，从而提供满足独立性要求和免于干扰的要求的证据。

相关失效的发起点（DFI）表示在安全范围内相关故障的根本原因。这些相关失效的发起点（DFIs）无法通过标准的安全分析进行分析，但是可以通过DFA用定性的方式处理。这些DFIs包括以下：

➡共享资源的失效

➡单个物理根本原因

➡环境因素的错误

➡开发错误

➡生产错误

➡安装错误

➡维修错误

需要制定不同的措施来应对不同类型的DFI。

安全设计实现

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

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

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

冗余错误检测利用冗余计算或存储来检测目标功能中是否存在错误。通过有三种不同类型的冗余方法。

➡硬件冗余通常在不同的硬件模块上执行相同的计算，这样，如果功能模块中出现了导致错误的故障，就有可能通过比较冗余模块的结果来检测。双模块冗余(Dual module redundancy, DMR)通常用于汽车soc中，其中两个处理单元以相同的方式(lockstep模式)执行相同的计算任务，它们的结果由检查器模块进行比较。

DMR允许错误检测，但不能自行纠正错误。错误处理通常由系统的其它部分完成。三个模块冗余(Triple module redundancy,TMR)允许错误检测和错误纠正，但需要额外的成本。TMR主要用于soc级关键寄存器，例如，存储调整值的寄存器，由三个表决触发器(triple voting flip-flops,tvf)实现。

➡信息冗余利用了冗余信息编码的检测和纠正错误。例如ECC(error correction code)和奇偶校验。这种安全机制通常用于保护数据通信通道和存储器。

➡时间冗余重复执行相同的计算，可能是在同一个硬件上，但是使用不同的算法。通过重复计算，很可能检测到是否有软计算故障。当不同的算法执行在相同硬件元素的不同部分时，用不同的算法甚至可以检测出硬件的永久性故障。

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

图3延迟锁步简图

输入数据直接输入到主处理单元而延迟一到两个时钟周期送入冗余处理单元。主处理单元的输出直接输出给系统。同时主处理单元也有分支并经过时间延迟后再与冗余处理单元的输出信号进行比较，这个时间延迟周期应与前面输入给冗余处理单元的延迟周期相同，这种配置可以防止由于时钟故障引起的共因失效。

另一种错误检测方法是连续或周期性地监测关键部件或参数的异常。监控通常假设部件或参数的行为应该在预先假定的正常范围内，并标记不在该范围内的行为。监控的例子包括电源电压、电流、时钟或总线协议接口的监控。另一个例子是软件看门狗，它监控处理器单元是否死机。

测试探测故障是指通过将运行测试模式或程序得到的计算结果与预先计算的结果进行比较。测试和监控之间的主要区别是监控通常是与元素的工作并行执行。然而,测试通常是在该元素没有正常运行时而进入测试模式。因此,与监控相比，测试对正常运行有破坏性。一些测试的例子包括逻辑内置自检(LBIST)和内存内置自检(MBIST)，通常是当SoC启动或关闭时运行。另一个例如在雷达MMICs中进行环回测试通信数据路径连通性。

安全机制按故障分类

另一个安全机制分类可以基于他们所针对的故障类型。例如，可以根据其目的分为针对单点故障的安全机制还是针对潜伏故障的安全机制。针对单点故障的安全机制是首要的安全机制，是因为单点故障可以直接违反安全目标的故障。通过冗余来故障探测和持续监控通常就属于这一类。潜伏故障通常通过基于测试的安全机制来保护，如LBIST和MBIST。

基于测试的安全机制并不总是用于探测潜伏故障。BIST机制通常不能用来防止单点故障是因为BIST的持续时间比FTTI长，而且天然地对正常运行有破坏性，因此当芯片在运行时，它们通常不能运行。对MCU而言如此，但对于雷达前端的mmic来说，由于雷达工作周期的特点，这并不总是正确的。

在某些雷达应用中，每个雷达工作周期分为运行期和和静默期。MMIC在运行期收发数据，在静默期是空闲的，因此，测试通常在静默期。在一些雷达应用中，FTTI被认为是一到两个雷达工作周期，也就是说测试持续时间可以适应FTTI。此外,MMICs作为雷达的发射器和接收器然后将采集到的数据发送到单片机进行处理。雷达数据记录经常靠MCU进行。因此，MMICs往往可以认为是无状态的，可以考虑测试对雷达功能无干扰。

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

安全验证

安全验证是确保安全需求通过安全架构的实现来满足。注意，在ISO 26262中定义的术语验证与确认与半导体领域定义的有所不同。在ISO26262中，验证方法包括评审，走查、检查、仿真、形式验证，工程分析等等。安全确认具体指整车层面的确认。在本文中，我们重点关注汽车SoC安全问题的前期验证（通过仿真和形式化方法)。

功能安全验证的有效手段之一是故障注入行为(常称为故障注入)。它注入故障到设计模型，观察故障探测以及安全机制的故障响应。故障注入结果可以作为在FMEDA中的诊断覆盖率的有力证据。故障注入的目标包括:

➡确定安全机制的诊断覆盖率

➡确定诊断时间和故障处理时间

➡确定故障影响

进行故障注入另外的作用还有：

➡设计模型:可以寄存器转化级/门级别，甚至更高的级别（系统层）

➡故障位置和故障类型:故障列表可以随机选择，也可以来自确定的关键失效模式

➡功能激励:它应表示工作负载或用例

➡观察点:应该观察故障影响和故障诊断点

基于故障注入的测试结果，同时结合专家的判断，根据“功能安全中的故障”一节中的分类标准就可以讲故障分类了。根据故障分类和诊断覆盖率，依据详细设计实现中得到的更准确的数据来更新FMEDA报告。我们将在下一节讨论故障注入的技术挑战。

2►

当前及新出现的挑战

在本节中，我们识别出了为了获得当前和下一代产品的功能安全，在汽车SoC设计和验证方面的几个挑战。

在安全性和PPA之间的权衡

获得功能安全是要付出代价的。安全机制的实现必然带来在性能、功率和面积上的开销(Performance,Power,Area,PPA)。例如，DMR增加了超过一倍的面积。运行整个芯片的LBIST导致很大的功耗。现有的安全分析只关注故障和诊断覆盖率，并没有从定量角度去考虑设计上的花销。从PPA角度，安全分析和设计的过程往往是单独进行的，虽然SoC架构师和安全架构师也意识到功能安全和PPA的权衡，但通过系统性的分析以便得到最优的架构仍是个挑战。这样的分析可以从架构定义的早期开始同时在不同设计阶段不断迭代。传统设计过程中需要考虑的参数已经十分巨大了，还要增加功能安全维度，这将使问题更有挑战性了。

故障注入活动的挑战

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

对于当代汽车SoCs来说，故障范围是巨大的。如果我们使用低层级的故障模型，考虑到当今汽车SoCs的大小，在一个大小合理的IP块中可能会有数百万个故障。如果再考虑到瞬时故障，其中额外的时间维度使得故障空间更加难以处理。有时，会模拟数十个或数百个测试，以确保故障注入的功能能够代表SoCs的实际工作负载，这使得它在计算上更加困难。

在实际应用中，采用人工选择和统计抽样的方法来减少故障空间。人工选择的局限性在于，它通常需要专家的判断和对特定设计的深入了解。它也很难计算出人工选择故障的概率分布，以计算诊断覆盖率。一种常用的统计抽样方法是基于置信水平和置信区间的抽样。其局限性在于，当置信水平较高且置信区间较窄时，它通常给出一个非常保守的边界，因此，样本量可能仍然很大。

对于数字电路，对故障模拟技术的研究已经进行了至少三十年，并且市场上可以买到先进的算法，通过同时模拟数千个故障来加速模拟。然而，对于模拟电路的故障模拟，即使同时模拟故障，也是非常具有挑战性的。在某些情况下，已经有研究使用敏感性分析来加快模拟速度。然而，并行故障模拟在模拟电路领域的普遍应用仍然是一个悬而未决的问题。对于模拟和混合信号电路，当前的仿真技术侧重于低层级故障模型，这限制了它们在更大范围内的使用。正确的抽象级别故障建模非常有助于模拟和混合信号SoCs的故障模拟。

为了分析故障的传播和检测，在故障注入中也引入了形式验证方法。这里有几个限制，形式化方法的可扩展性本质上妨碍了对大型设计的应用。此外，如果设计的环境约束没有得到适当的表述，形式化方法往往会发现不切实际的情况，这可能会成为工程调试时间的黑洞。

基于测试模式的安全机制的诊断覆盖率

如今，基于测试模式的安全机制越来越受到重视，因为它们需要更少的硬件资源，并且更加灵活。然而，这种测试模式的开发工作和复杂性可能是具有挑战性的。

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

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

新兴加速器的安全机制

随着特定领域计算的普及，加速器在芯片产业中占有越来越大的份额。在汽车领域，正在为视觉处理、雷达和激光雷达数据处理以及深度神经网络（DNN）推理设计新的加速器。与SoC上的通用组件（如CPU、结构和内存）不同，加速器是为特定领域的计算任务而设计的。将DMR等传统安全机制简单地应用于加速器可能既不有效也不经济。

为了有效地设计新兴加速器的安全机制，利用加速器的特定领域特性将是有益的。它需要硬件和软件的交替思考，以及对系统级安全机制的深入理解。为特定领域的加速器设计有效的安全机制是一个开放的研究领域，该领域的创新备受追捧。

实现失效可运行的挑战

自动驾驶系统的发展趋势要求未来的汽车电子/电气系统能够失效可运行。该要求也可能传递给汽车SoCs，这意味着SoCs可以继续正常运行或在降级模式下运行。直觉上，这通常可以通过冗余计算资源来实现。然而，由于汽车市场仍然是一个对成本敏感的市场，这意味着应在不导致不可接受的资源增加的情况下实现此类故障可运行行为。

虚拟化是一个可能的发展方向，因为它可以提供高可用性以实现故障操作可运行行为。它需要在硬件上进行有效的故障定位，并在软件级别处理错误。尽管虚拟化在云计算中已被证明是成功的，但将其应用于汽车嵌入式应用程序仍存在许多悬而未决的问题。

3►

研究总结

本节重点介绍了最近提出的一些更新和研究工作，以实现汽车SoCs的功能安全，从而进入自动驾驶时代。这绝不是一篇全面的评论，但其目的是让读者领略本文中一些有趣的内容。

启用特定于应用程序的安全机制

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

最近一项引人注目的创新是软件安全概念，通过可配置的安全机制实现，如时间监控比较器（TMC）和定时多看门狗处理器（TMWDP）。TMC在软件锁定步骤的环境中工作，其中相同的计算任务由两个软件线程执行，很可能使用不同的实现方式。一个软件线程可能是精确的，并且会消耗资源，而另一个线程可能会使用较少的资源在一定范围内产生较不精确的结果。传统上，软件锁定步骤要求两个软件线程同步并定期比较其结果，然后才能继续，这可能会影响性能。TMC通过使用专用硬件监视器在受控时间间隔内比较两个软件线程生成的结果来提高性能。因此，它确保两个线程的结果具有可比性，并且两个线程的进度在有限的时间间隔内。

TMWDP保护应用软件控制流的完整性。假设系统应用程序开发人员了解应用软件的高级控制流。定时看门狗是从控制流转换而来的定时状态机。它检查错误的状态序列和错误的状态序列计时以及饥饿（应用程序在某个状态中停留的时间过长）。

深层神经网络的安全性

随着计算机视觉中深度学习应用的最新突破，DNNs在从ADAS到自动驾驶的道路上越来越有吸引力。在探索和部署用于感知任务（如行人检测、车辆跟踪、路标分类和距离检测）的DNN方面，已经付出了巨大的研究和开发努力。一些人甚至尝试使用DNN进行端到端的自动驾驶。已经开发了专用加速器，以支持为实时应用部署DNN。然而，一如既往，此类应用和特殊加速器的安全问题一直是一个关键问题。

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

DNNs的安全包括两个方面：预期功能的安全和功能安全。预期功能的安全性涉及以下问题：如果我的DNN模型将停车标志分类为限速标志，会对安全产生什么影响？我如何减轻这种影响？功能安全涉及到这样一个问题：如果我的DNN加速器中有一个缺陷改变了其假定的行为，那么会对安全产生什么影响？在训练或推理过程中可能会出现故障。由于训练通常是离线完成的（作为开发的一部分），因此可以通过详尽的验证来控制训练阶段的故障。而推理阶段主要针对随机硬件故障的失效影响和缓解。

最近的工作探索了现代神经网络中故障的错误传播，并基于实验学习提出了安全措施。这些工作的重点是研究推理机的体系结构和设计参数对安全性的影响。此外，还可以探索训练过程中的超参数对推理的安全影响。更具体地说，Dropout是DNN训练中最近的一种正则化技术，以避免过度拟合。Dropout的想法是断开神经网络在训练期间分层，以使激活不是依赖于少数神经元。Dropout会增加模型中的信息冗余，因此可能会使推理阶段有更好的故障恢复能力。从定量的方面探讨其含义将是一件有趣的事情。

我们概述了安全相关汽车SoCs的功能安全开发。我们描述了相关项的功能安全开发的总体流程，并阐述了实现汽车SoCs功能安全的实践。我们强调了在ADAS和未来自动驾驶应用中实现汽车SoCs功能安全的挑战和研究工作。尽管本文涵盖了与汽车SoCs功能安全相关的广泛主题，但我们相信我们只触及了挑战和研究机遇的表面。

此外，由于篇幅的限制，与ISO 26262相关的某些主题，如ASIL分解和软件工具置信水平，未涵盖在内。尽管如此，我们希望本文能为半导体专业人士和研究人员提供一个起点，帮助他们了解工业实践和功能安全方面的挑战。迫切需要将研究推进到当前范围之外，以便为未来的自动驾驶开发故障可运行系统。

活动推荐：

ICVS中国智能汽车及自动驾驶博览会，暨同期：中国智能汽车产业链展

2022年9月26-29日

江苏·苏州国际博览中心

30,000m²展览面积

100场会议演讲

500家参展企业

30,000专业观众

点击进入ICVS智能汽车产业联盟主页—>进入菜单栏展会报名页面，即可免费领取参观门票，现阶段报名还将获取更多报告福利。