一文深度解析智驾算力芯片功能安全设计的特点和难点

ADAS（Advanced Driver Assistance System）自动驾驶辅助系统功能的不断迭代成为当下汽车智能化赛道的发展主线。 其系统主要包含感知、决策和控制三大环节，通过接收传感器感知到的环境信息，结合运动预测和决策规划环节输出车辆控制信号，从而指挥车辆完成相应行驶动作。

自动驾驶技术当前处在一个快速发展和迭代阶段，传感器组合、系统方案及算法等都在快速迭代，特别是高等级的智驾系统。在这一背景和浪潮下，智驾SoC（System on Chip）作为核心的算力和控制底座，其研发和设计也在快速迭代和演进中，本文针对智驾系统的发展探讨智驾SoC发展趋势，以及在这个趋势下为达成功能安全要求而面对的挑战和应对策略探讨，以期抛砖引玉。

随着自动驾驶技术的发展，对芯片的算力要求越来越高。高级别的自动驾驶系统需要实时处理大量的传感器数据，并进行复杂的决策和控制，这需要更为强大的AI算力支撑。

• 更高的CPU算力

包括应用处理器CPU及实时处理Real-time CPU，典型如ARM Cortex-A78AE 和 R52+ 内核。

• 单芯片高度融合集成

单SoC内集成更多的处理单元和外设资源，以满足智驾、座舱、车辆动态控制、附件管理等多种应用需求所涉及的芯片IP资源，高度融合集成。

• 更先进车规工艺

芯片工艺节点快速提升以期提升算力降低功耗，当前已提升到5nm车规工艺节点，后续4nm节点也很快有产品入市。

• 更高的功能安全和信息安全等级要求

智驾SoC承担了车辆控制的关键功能，并支持丰富的网络互联功能，其功能安全和信息安全等级要求随自动驾驶等级的提升而趋于更加严格。

• 支持灵活的系统应用场景

配合车辆EE架构的变化和不同用户的车辆控制融合功能的差异，智驾SoC产品从需求角度看需要支持灵活的系统应用场景要求，并支持灵活的扩展。典型如以图像为主和以激光雷达为主的感知应用场景对芯片设计会有不同的侧重要求，对应SoC设计上硬件需综合考量以支持灵活的系统应用场景。

• 新型加速计算方案的探索

如何提升智驾芯片的AI加速计算能力，同时考虑如下约束：时延、功耗、Die面积、吞吐率、可扩展性、算法支持的灵活性、热管理等维度。一方面在现有主流的CMOS工艺上通过优化架构设计，提高工艺节点等方式增强AI加速器能效。另一方面，现有工艺亦逐步接近工艺极限，新的材料和设计方案也正在被业内研究和探索，包括新型封装技术、光电芯片、新型存算一体方案、类脑芯片等。

为满足智驾系统层面的功能安全要求，智驾芯片功能安全设计目标日趋严格，从当前的fail-safe向着未来fail-operational方向发展。 SoC作为典型的SEooC(Safety Element Out of Context)，其功能安全设计目标的达成，需要贯穿从芯片定义、应用场景分析、系统架构设计、前端/中端/后端设计、硅前硅后验证、质量和可靠性测试验证等不同阶段的工作中，需要在全流程开发过程中贯彻功能安全标准的要求，不仅在技术部分，项目管理也是非常重要和关键的维度。

1、可供适用的功能安全标准

AI算法当前普遍应用在智驾系统中，且由于新的自动功能竞争激烈，汽车制造商及其供应商正在秘密合作将最新技术推向市场，而秘密研发和快速迭代的现况事实上制约了AI相关功能安全标准的制定。

AI的功能安全同样从软件和硬件两方面考虑，其中硬件部分核心是智驾芯片。从智驾芯片设计的维度看，当前业内并没有直接的标准/法规适用于智驾芯片的AI部分（典型如NPU-Nueral Processing Unit）。实际开发中仍以ISO 26262：2018为主，主要使用的方法和设计目标围绕控制SoC硬件带来的不可接受失效风险。而AI应用于智驾更多体现出来的是系统整体的概率性风险问题，需要采用新的方法来处理。就当前来说，根据智驾SoC承载的功能和硬件实际的异构架构包含的多种除AI加速单元之外的功能电路，采用ISO 26262标准是必要的且能够提供硬件层面的安全基础，以支持上层应用算法的可靠运行。

预期年内发布的ISO/DPAS 8800已承担起为汽车行业提供人工智能技术使用指导的任务，一个可能的方向是，ISO委员会在下一版本中扩展ISO 26262，结合ISO/DPAS 8800的经验教训，并可能包含规范要求。此外，SAE、SAFEXPLAIN 等组织正在组建一些其他计划，例如自主地面车辆人工智能 (GVAI) 委员会，其目标是通过创建技术和方法来开发和审查这些人工智能系统，从而找到确保人工智能系统安全的方法。

2、功能安全挑战

当前智驾芯片所处的状态来看，存在如下不同维度上的挑战，对于SoC原厂以及产业链上下游来说需要协同一起来应对和解决。具体梳理如下：

2.1 芯片规模带来的IP和模块安全性达成挑战

智驾SoC往往包括多种类型的IP：

- 安全IP：包括硬件信任根（Hardware Root of Trust）、安全引导和访问控制（Secure Boot & Access Control ）、V2X安全身份认证（ Secure Identification & Authentication）等。

上述IP来源主要是2个方面：

- SoC厂商自研

需要SoC原厂在IP开发过程中遵循功能安全标准的要求进行，符合SoC整体的功能安全设计目标。

- 来自于第三方IP供应商

需要SoC原厂在IP选型阶段做好IP质量的审查，并分析评估第三方IP是否适用于SoC分解下来的安全需求。典型方式是采购第三方符合ISO 26262标准要求的IP产品。这里有挑战的点在于IP的配置和集成过程中需要重点处理好IP vendor提供的Safety Manual与SoC本身设计提出的安全需求之间的匹配和不一致项的合理分析处理。

2.2 平衡功能安全与研发周期/难度以及芯片PPA（Performance Power Area）等目标

基于功能安全标准的要求和开发流程，使智驾SoC满足功能安全要求需要在功能芯片研发的基础上额外增加相当工作量的功能安全设计开发以及验证工作。这个过程中普遍会在SoC原厂中遇到功能安全设计目标同产品研发周期，开发实现难度以及芯片PPA之间的目标冲突。

首先，这无疑会增加开发的时间周期，以及设计验证的难度，对芯片上市时间带来挑战。

另外，为达成功能安全设计目标，往往需要在原有功能链路上增加各类功能安全诊断，保护或控制机制，这些新增的电路无疑会增加SoC Die Size，且有些机制会影响原有功能电路的Performance（典型如ECC增加的访问延迟，或做周期性自检而占用的硬件有效工作时间进而影响Perfomance）。

在开发实践中，如何平衡上述不同目标之间的冲突，基于既有经验行之有效的解决方法包括如下：

- 设计分析和需求明确，并前置并同设计验证团队保持高效同步和迭代。

2.3 高效灵活的芯片故障管理

智驾SoC产品包含多个不同类型和安全等级要求的IP，并划分成不同的功能子系统。在设计整体的故障收集和管理系统时，如何实现如下目标：

- 满足故障的分层处理和软硬件管理通路可配置的要求

上述目标要求需要在SoC设计时充分考虑预期集成的IP本身的故障信息特征，既有的功能处理策略和成熟驱动软件的处理做法，以及功能安全相关故障的特性来综合设计。同时需要考虑好和功能电路之间的FFI（Free From Interference）设计要求以及芯片规模巨大带来的后端走线和Timing约束等问题。

2.4 硬件资源的隔离和避免干扰设计

智驾SoC内部集成的多个IP和子系统服务的上层应用任务的安全等级要求不一，在SEooC设计时，给定的安全等级要求势必存在不同安全等级模块的共存问题需要做好隔离和FFI设计。典型总结如下：

- 功能电路和安全机制之间的FFI要求

上述FFI的设计，除功能逻辑层面之外，还需要考虑共用的SoC基础设施如Power，Clock，Reset等，以及后端布局布线、温度电压采样、封装等层面的FFI要求。

2.5 适应灵活应用场景配置下系统架构设计

智驾应用场景多样，不同的客户使用SoC产品的需求和应用方案各异，往往芯片原厂在设计产品时为尽量支持多种应用场景，会在设计上提供多种软件可配置的使用方案，配置的灵活性额外带来了对于功能安全目标的达成以及不同场景下使用约束的详细分析和阐明的挑战。

典型如利用GPU硬件实现的虚拟GPU并支持ASIL B/QM 等不同应用的部署，需要硬件能够支持GPU core资源的灵活配置，以及不同配置下安全机制的有效覆盖和灵活调用。如采用采用周期性调用方式的Online LBIST覆盖计算逻辑core的永久性失效，则需要在SoC LBIST设计时，power，clock，reset和isolation的设计支持LBIST的范围可跟随客户的配置方案进行覆盖，且不影响其他不做LBIST的内核的正常工作。

2.6 自研安全机制的有效性证实

对于SoC原厂来说，为了满足自研IP的功能安全要求或者处理多个IP在芯片内部关键的复杂的数据处理流上实现功能安全要求，自研功能安全机制往往是一个合理且需要的选择。伴随而来的需要对自研安全机制的有效性做充分验证，并提供有力的证据证实功能安全覆盖度指标的达成。

这里典型的场景是基于软件的自测patterns设计，通常用STL（Self-test Liberary）代指。STL常用于复杂硬件处理逻辑或长链路的硬件通路上（涉及多个IP时）提供一套覆盖方案。而STL设计本身存在较大难度，典型包括：如何选择自测的pattern，链路如何设计，如何降低对功能电路性能的影响，如何证实STL对诊断覆盖度的达成。

一个可行的闭环方案是利用故障注入测试工具从SoC硬件本身进行故障注入仿真，带入STL来观测故障检测覆盖的情况，并提供估计的诊断覆盖度DC（Diganostic Coverage）值。通过迭代仿真来推进STL的设计和优化，并最终提供其有效性和DC的定量化证据。当前业内有不同的EDA工具商可提供类似的工具来实现上述目标。但开发过程的时间消耗以及设计STL的能力对SoC原厂来说是一个挑战。

2.7 软件及开发工具链的功能安全符合性挑战

智驾SoC的功能安全达成需要仰赖ADAS系统方案的设计以及SoC驱动软件，中间件，OS以及AI加速器开发工具链对功能安全的支持。这部分的开发和测试涉及的工作量对SoC原厂来说，面临开发周期和成本与客户应用多样化之间的挑战。同时智驾算法本身的快速迭代以及软件定义汽车SDV（Software Defined Vehicle）的趋势下，大大增加了智驾软件的体量和复杂性，为其功能安全符合性的达成带来挑战。

除此之外，广泛应用的开源软件或组件也为实践中实现软件的功能安全目标达成带来额外的工作，这方面预期需要行业内的共同努力以及新的更高效方法或商业模式的创新来协助解决。

2.8 支持Fail-Operational的挑战

多芯片向单芯片方案演进

主流量产智驾系统方案为ASIL D MCU加ASIL B SOC双芯片方案。ASIL D MCU作为整个域控的故障处理，监控SOC的硬件完整度。同时，接收前向/侧向雷达目标数据，以支持故障降级策略。