自动驾驶车载SoC设计功能安全
我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。
老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：
所有人的看法和评价都是暂时的，只有自己的经历是伴随一生的，几乎所有的担忧和畏惧，都是来源于自己的想象，只有你真的去做了，才会发现有多快乐。人就应该满脑子都是前途，不再在意别人的看法不再害怕别人讨厌自己，不再畏手畏脚忧心忡忡也不会在睡前反回忆白天的行为，是否让对方产生误解用你那精神内耗的态度去搞学习搞事业搞钱，然后用躺平和摆烂的态度对待人际关系，烦恼能消失一大半。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。
时间不知不觉中，快要来到深秋。国庆假期结束，又开始新的忙碌。成年人的我也不知道去哪里渡自己的灵魂，独自敲击一些文字算是对这段时间做一个记录。
一、前言
随着汽车技术的不断进步，车辆架构设计正经历着深刻的变革。其中，一个显著的趋势是向更集中的域处理模式转变。这种模式将车辆的功能划分为不同的域，如自动驾驶、车辆连接和移动性解决方案等，每个域都配备有专门的处理器来管理相关任务。
域处理器在这种架构中扮演着至关重要的角色。它们不仅是车辆功能实现的核心，还直接影响着车辆的性能、安全性以及购车者的使用体验。因此，购车者在选择车辆时，需要特别关注域处理器的性能和功能，以确保所选车辆能够满足他们的需求。
自动驾驶、车辆连接和移动性解决方案等领域是现代汽车技术的关键组成部分。这些领域依赖于复杂的人工智能算法和密集的计算能力。例如，自动驾驶系统需要实时处理大量的传感器数据，以做出准确的决策；车辆连接系统需要支持高速的数据传输和稳定的网络连接；而移动性解决方案则需要确保车辆在不同场景下的灵活性和适应性。
为了满足这些领域对计算能力的需求，SoC（系统级芯片）需要进行针对性的优化。由于每个应用领域都面临着不同的挑战，如自动驾驶对实时性和安全性的高要求，车辆连接对数据传输速度和稳定性的需求，以及移动性解决方案对低功耗和灵活性的追求，因此SoC必须针对每种应用的具体需求进行优化。
为了创建满足这些需求的定制芯片，许多汽车制造商正在内部进行芯片设计和验证。通过自主研发和定制设计，制造商可以确保芯片在提供所需功能的同时，还能满足严格的功耗、性能和面积要求。这不仅有助于提升车辆的整体性能，还能降低生产成本，提高市场竞争力。
二、SOC芯片验证
尽管为自动驾驶汽车设计 SoC 面临诸多挑战，但阻碍其成功的重大障碍在于赢得公众的信任。自动驾驶汽车 (AV) 制造商要想建立这种信任，可以采用的一种方式是，通过安全标准和认证来证明其平台的安全性和可靠性。为此，汽车行业已经建立起一套针对电气和电子系统安全性的程序和标准，并称之为功能安全。
功能安全的目标是降低因失效导致电气和电子元器件发生故障的风险。在汽车行业，此类程序和要求已在 ISO 26262 标准中正式成为明文规定。ISO 26262 要求对电子设备进行随机硬件失效和系统故障测试。ISO 26262也代表了汽车电子设备安全性方面的先进技术水平，对于所发布的产品容易受到责任诉讼影响的汽车制造商和供应商而言，符合其要求是不可或缺的。
系统性故障是指可导致集成电路无法按照产品规格正常运行的故障。这类故障可能包括设计缺陷、硬件／软件接口问题、错误解释或不完整的规范，等等。在应对系统性故障方面，IC 行业已积累大量的知识、工具和流程。相比之下，自动驾驶汽车行业还缺乏经验，也不具备良好的发现和解决随机硬件故障的能力。随机硬件故障是不可预测的，并且会随着 IC 运行时间的推移而发生。
ISO 26262 要求芯片持续运行，或在出现随机硬件故障的情况下可以安全失效。确保 IC 针对随机性故障安全失效，需要四个关键过程：
生命周期管理涵盖了从计划到合规性的功能安全生命周期。这包括变更／配置、项目、需求、质量保证和审核／合规性管理。
安全分析有助于设计人员了解设计如何因随机硬件故障而失效。失效模式和影响诊断分析 (FMEDA)可确定设计的潜伏失效模式、失效率、每种模式将如何影响设计功能，以及自动化诊断捕获每种失效模式的概率。然后，由工程师进行安全差距分析，确定达到其安全目标所需的安全增强。
安全增强了设计，以减少因随机硬件故障造成的潜伏失效。这可以通过在设计中插入用于检测和纠正故障行为的安全机制来实现，从而确保设计能够正常运行或安全失效。
安全验证通过故障注入过程对一组故障指标进行确认，证明设计是安全的。故障指标集包括单点和潜伏故障指标 (SPFM/LFM) 以及诊断覆盖率 (DC)。
这些过程以闭环流程运作，其中每个过程的结果将为下一步骤提供信息。这对于解决随机硬件故障和构建一次成功的安全 IC 设计至关重要。本文将讨论其中每个过程以及可提高工程师在每个阶段的效率的先进验证技术。
三、生命周期管理
ISO 26262 包括跟踪和管理设计变更、测试结果和安全指标方面的指南。许多公司仍然依靠他们的工程师手动跟踪和收集这些信息。手动方法在记录的数据中引入错误的可能性更大，并且总体速度要慢得多。此外，手动管理数据不能将重要信息链接到一起，使得可追溯性变得非常困难。变更和配置数据、设计要求、验证结果等都是单独存储的。因此，工程师要想创建进行审核和评估所需的工作产品，需要花时间将信息拼凑在一起。随着汽车 IC 变得日益复杂，手动管理需求和合规性已经跟不上要求了。
应用生命周期管理 (ALM) 软件有助于自动跟踪和管理设计需求与合规性。有了这些解决方案，公司可以采用需求驱动的验证流程，并管理从测试计划到合规性认证的整个功能安全生命周期。在功能安全验证方面，ALM 工具可以简化结束验证循环的过程。
FMEDA 存储在 ALM 工具中，允许工程师快速填充来自安全验证阶段的指标。于是，所有相关团队都能轻松访问这些安全指标和 FMEDA 结果。需求驱动的验证过程对于角逐汽车 IC 业务的公司来说至关重要。应用生命周期管理 (ALM) 解决方案通过为整个功能安全过程提供数字化平台实现了需求驱动的流程。ALM 为工程师提供了证明关键汽车电子设备功能安全所需的信息，消除了手动收集这些数据的耗时过程。
四、安全分析
生命周期管理解决方案部署到位后，证明功能安全的第一步就是进行安全分析。安全架构师通常首先通过创建 FMEDA 来确定设计的高层次失效模式。FMEDA 是一个重要的步骤和一项关键的工作产品，但由于它是专家驱动的自上而下的分析，因而也容易受到人为错误的影响。通过对设计进行安全分析，安全架构师可以验证其专家驱动的判断。安全分析还会计算设计的基础失效率 (FIT)，并估算单点和潜伏故障指标 (SPFM/LFM)。
接下来，设计人员会进行安全探索，确定设计中需要提升安全性的区域，以及为了达到目标安全级别而需要使用的安全机制类型。利用安全探索，安全架构师可以评估各种安全架构以及这些架构可实现的安全指标。这种早期分析使安全架构师能够确定符合 PPA 和安全目标的理想架构。安全探索的工作产品是为实现安全目标而必须在设计中部署的基于硬件和软件的安全机制列表。然后生成一份故障列表，用于指导在安全验证期间选择需要注入和测试的故障。
安全分析应在设计的结构层面进行。在此层面，分析将会产生更加准确的数字，并能更好地表示从安全验证中获得的最终指标。这将增加安全 IC 设计一次成功的概率，从而节省昂贵且耗时的迭代设计。
五、安全设计
现在用户已经通过安全分析了解如何使他们的设计更加安全，下一步是在设计中插入安全机制。针对这些安全机制的插入，西门子提供了一个完整的解决方案。使用 Austemper 安全综合工具，用户可以自动将安全机制插入 RTL，以实现运行时设计强化技术（即 ECC、CRC、奇偶校验、重复和复制）。这些机制是基于硬件的，能够直接解决永久和瞬态单点故障。然后可以使用 Tessent 插入 LBIST 和 MBIST 结构，以及一个 MissionMode 控制器，从而可以在汽车运行时使能这些检查。这些片上测试设施可以识别现场发生的潜伏故障，提高汽车芯片的长期安全性和可靠性。
安全工具的自动化设计为进入 IC 设计领域的汽车公司和进入汽车市场的 IC 设计公司提供了诸多好处。首先，自动化减少了工程师在这些任务上投入的时间，使他们能够专注于芯片的差异化功能。其次，自动化安全设计简化了在架构未知的模块（例如第三方 IP 或机器生成的代码）中插入安全机制的过程。第三，自动化在跨个人和团队的安全机制实现中灌输了一致性。最后，自动化加速了将传统 IP 提升到符合功能安全标准的过程，特别是在无法联系到原始设计人员时。
六、 安全验证
安全验证首先使用安全分析阶段生成的故障列表。在 RTL 级别，IC 设计的所有节点、寄存器和端口都可能存在故障。往下一层，门电路级网表的故障数量可能要翻很多番，达到数百万个。如果考虑安全指标，则会进一步增加潜伏故障的数量。
为了将仿真时间保持在可控范围，工程师使用一系列技术来缩小注错分析和仿真或故障列表的范围，这被称为故障优化。故障抽样便是其中一个例子，期间会随机选择数以千计的故障样本。这会减少在安全验证期间需要激活的故障数量。
对于大多数功能，没有必要针对所有可能的故障来验证设计的安全性。但是，安全关键组件需要进行全面验证，确保它们完全没有错误。即使在相对普通的操作上实现这一级别的验证，仿真能力很快就会变得捉襟见肘。
要想缩短验证时间，一种行之有效的方法是减少必须验证的输入组合数量。随机抽样可以产生较小的列表，但不能确保安全关键组件所需的全面验证。一种被越来越广泛采用的选择是进行形式验证。形式验证可以显著减少验证安全关键设计所需的故障数量。为此，形式验证将设计综合为布尔表示式，以便执行分析。这让形式验证工具能够通过所有可能影响信号的逻辑来跟踪该信号。这种逻辑路径被称为 “影响锥”。
在随机硬件失效分析的上下文中，影响锥 (COI)可以自动修剪所有在结构上安全的故障，而无需进一步的分析。按照定义，锥外的任何故障都被分类为安全故障。此外，影响锥还能揭示安全机制已覆盖或未覆盖的逻辑，指示单点、残余和潜伏故障。该结构分析可在执行任何故障注入前提供快速分类，并展示了诊断覆盖率计算的最坏情况或理想情况场景。
形式验证也保证了详尽的故障分析。形式验证按照“宽度优先” 的原则验证设计。这意味着它会自动考虑所有可能的输入条件。基于此，形式验证可以分析给定起始条件下可到达的整个状态集。它将按顺序遍历此状态空间，并在运行过程中验证每个状态。最终得到一组最坏情况的安全指标，解释设计中所有可能的故障。对于必须达到相当高的可靠性和功能安全标准的安全关键功能或模块，进行这种级别的验证非常有益。
通过仿真注入故障完成安全设计后，工程师创建了他们认为安全的设计。接下来，他们必须证明它是安全的。这是通过在设计中注入故障来实现的，以了解设计和安全机制在出现硬件故障时的行为。
安全验证阶段会产生另一组 SPFM/LFM 和 DC 安全指标。参照安全分析阶段估算的 SPFM/LFM 和 DC 指标对这些指标进行验证，从而结束验证循环。经确认的安全指标作为产品安全性的证据进入最终 FMEDA。通过硬件加速仿真注入故障鉴于自动驾驶汽车 SoC 的高度复杂性和必须满足的严格安全标准，验证其功能和功能安全所需的时间将会构成一项严峻的挑战。除了通过形式验证技术优化故障列表外，采用更强大的验证引擎也能进一步改善验证时间。
硬件加速仿真在硬件设计中以兆赫 (MHz) 的速度执行测试，速度比普通仿真要快几个数量级。这使得芯片设计在硅片实现前便可以开始系统验证，并能提供全面的硬件设计可见性，以提高调试效率。此外，硬件加速仿真还支持对安全关键型汽车应用进行故障注入、监控和结果分析。
硬件加速仿真在不改变设计流程的情况下，为整个供应链的协作提供了出色的灵活性。硬件加速器可以在硅片制造之前就运行特定的 IP 或整个 SoC 设计，包括基于软件的安全机制。相比之下，在 SoC 级别执行故障注入仿真几乎不可能，特别是在满软件负载的情况下。利用硬件加速仿真，工程师可以开始编写软件，并在将要实施软件的不断演进的 SoC 上对软件进行测试。然后，工程师可以将综合的传感器数据馈入到硬件加速仿真，并输出到为车辆行为建模的环境中，以测试 IP 和软件如何响应激励。通过硬件加速仿真，供应链的各个级别将能够更早地开始开发，同时在整个系统的模型内进行测试。
六、转向全车验证
随着车辆自动化从 1 级发展到 5 级，正确验证车辆必须研究的潜伏场景数量激增至数百万个。据估计，要想全面测试和验证自动驾驶汽车的安全性和功能，将需要超过 80 亿英里的里程。要实现这种数量的验证，唯一的方法是在设计过程的早期采用虚拟测试环境。
硬件加速仿真可支持模型、软件和硬件在环验证。通过集成传感器和机电仿真，硬件加速仿真可以在获得任何芯片或车辆硬件之前，提供用于对 IC 或整个自动驾驶汽车平台进行测试、编程和调试的环境。
首先是传感器数据。为了在没有传感器硬件的情况下生成这些数据，基于物理特性的先进传感器仿真为硬件加速仿真提供了仿真的激光雷达、雷达、摄像头和其他传感器数据。先进的传感器仿真器还能生成交通模式并模拟 V2X 通信，以全面测试自动驾驶汽车平台的功能。
其次是运行自动驾驶 IC 的硬件加速器所提供的计算数据。当今的硬件加速器具有数十亿门电路的容量，甚至支持非常先进的 SoC 设计。硬件加速器将以MHz 的速度运行，接收和传播与设计在实际硅片中接收和传播的相同信号。这为工程师了解设计功能提供了出色的可见性，从而增强了调试和优化。
机电仿真器提供来自转向、制动和传动系统的执行器数据。现代系统仿真解决方案使制造商能够在投入样机之前对机电一体化系统的性能进行仿真和优化。这些解决方案包括多物理特性模型库，用于准确描述热、液压、气动、电气和机械系统。硬件加速器可以利用这些解决方案的输出为被测设计提供真实的车辆控制数据。换句话说，在任何物理部件准备就绪之前，被测设计就可以像在实际车辆中一样进行转向、制动和加速。
有了这些验证技术，芯片设计人员就可以在设计过程中更早地开始对其自动驾驶芯片进行验证和确认。新的移动性验证自动驾驶汽车的成功取决于由先进传感器和强大芯片构成的系统实时感知和处理大量数据的能力。因此，这些芯片将需要全新的架构来满足自动驾驶的功耗、性能和面积要求。此外，即使在恶劣的环境条件下，自动驾驶 IC 也需要以近乎理想的可靠性和准确性运行，并且运行时间要比传统消费电子产品中的 IC 长得多。
设计这些芯片仅仅是个开始。自动驾驶汽车 IC 设计必须证明能够正确运行，并在出现随机硬件失效的情况下安全失效。类似 ISO 26262 这样的功能安全标准必须非常严格，安全关键 IC 的目标是达到每十亿件产品缺陷率 (DPPB) 为零。在异常复杂的自动驾驶IC 中，要确保这种质量水平，需要一种全新的流程，将仿真和硬件加速仿真结合起来，在设计过程中进行“左移” (Left-shift) 验证。这类 IC 还必须在系统内进行验证，而不能等到真实测试之后。
汽车初创企业、成熟的 OEM 和系统公司面临市场先行者承受的巨大压力，需要一套先进的验证工具，及时满足这些严格的安全要求。验证团队在需要处理高度复杂的芯片时，将依赖自动化来加速关键过程。此外，硬件加速仿真将为这些团队提供准确、及时地完成验证所需的灵活性和能力。
