本文由刘法旺，李艳文，王伟，李京泰联合创作
车载智能计算基础平台是汽车产业发展的重要基础和支撑重构下一代汽车电子产业链的关键纽带，安全问题至关重要。本文首先针对车载智能计算基础平台，从安全策略和系统设计两个层面进行功能安全分析；然后对平台的异构硬件、操作系统、开发工具链，分别研究提出功能安全要求；最后从流程、设计开发、测试验证三个层面，研究提出车载智能计算基础平台功能安全的评估框架。
在智能化、网联化、电动化的背景下，汽车电子电气架构由分布式向集中式持续演进，自动驾驶成为产业竞争的焦点。作为实现自动驾驶的关键，车载智能计算基础平台的重要性更加凸显。
发展车载智能计算基础平台，有利于聚集多领域、跨行业的创新资源，打通基础研究、应用示范、成果转化与产业化的链条，集中力量在自动驾驶核心竞争领域形成原始创新能力和竞争优势。特斯拉、奥迪、英伟达、华为等整车企业和科技公司纷纷推出计算基础平台。
车载智能计算基础平台是基于异构分布式硬件平台，融合并集成系统软件、功能软件的复杂系统，可根据差异化需求进行硬件定制和应用软件加载，满足自动驾驶等功能需求。计算基础平台硬件架构主要包括 AI 单元、计算单元和控制单元。面向自动驾驶的车控操作系统，包含基于复杂嵌入式系统的汽车定制化系统软件和密切结合自动化需求的通用功能软件。其中，功能软件包括深度学习和视觉模块、传感器模块、网联云控、自动驾驶通用框架等模块。
自动驾驶强化了智能网联汽车基础计算平台对功能安全的要求。随着自动驾驶等级的提升，汽车的环境感知、决策权和操控权逐步实现由驾驶员为主体向自动驾驶系统为主体的过渡，智能网联汽车的安全风险大幅增加。异构分布硬件系统需要满足高诊断覆盖率和低失效率指标要求，自动驾驶车控操作系统需要满足实时性、安全性、可靠性等要求，工具链则需要满足置信度等要求。
本文基于自动驾驶功能应用背景，对计算基础平台参考架构从功能安全分析、要求、评估三个方面展开研究。
智能网联汽车计算基础平台的应用环境主要包含用于环境感知（如摄像头、激光雷达、毫米波雷达、超声波雷达等）和位置定位（如 GNSS、高精度地图等）的传感器，整车底盘域、动力域以及车身域的执行器，人机交互的 HMI（Human Machine Interface，人机界面），以及外部互联与通信的 T-Box（Telematics Box，远程车载信息交互系统）和 OBD（On Board Diagnostics，车载自动诊断系统）等。随着自动驾驶等级的不断提高，智能网联汽车计算基础平台对应用环境的传感器、执行器、人机接口和外部互联通信有更高的功能要求及功能安全要求。
计算基础平台参考架构如图 1 所示。
图1 计算基础平台参考架构
1.1 安全策略要求
自动驾驶功能目前的系统安全策略大体分为两种，即 Fail-Safe（失效—安全）以及 Fail-Operational（失效—可操作）。Fail-Safe 要求系统监控关键的部件以达到失效后系统关断的目的。但是对于 L3 及以上的功能，驾驶员处于脱眼、脱手的状态，系统的关断并不能保证可靠地完成驾驶权的转移。例如，高速公路场景中，车辆紧急停止在本车道是一种潜在的风险状态，很容易发生高速追尾。Fail-Operational 安全策略旨在解决这一问 题，即使在主功能系统失效的情况下，仍然有备份系统可以保证车辆进行降级操作，让车辆转移到安全区域。
1.2 系统设计功能安全要求
智能网联汽车计算基础平台的安全策略可以是独立的监控模块或冗余的系统设计。独立的监控模块实时监控功能实现模块的软硬件故障，一旦检测到有安全相关故障，车辆即进入安全状态，如需要可先进入紧急运行模式（Emergency Operation）。例如，功能降级、当前车道停车、安全地点停车。
冗余的系统设计是指两个或多个功能模块互为备份。例如，计算基础平台可以采用“主处理单元 + 辅处理单元”双处理架构，以确保 L3 级及以上自动驾驶的安全。在该架构下，主处理单元对车辆的运动轨迹进行规划和控制。辅处理单元的作用是监控主处理单元。同时两个单元不断地进行交叉检查，当两个通道在规划轨迹和控制策略存在较大偏差时，系统就会进入降级模式。主处理单元和辅处理单元可以按照 ASIL B 设计开发，仲裁模块可以按照 ASIL D 开发来设计。
在系统阶段进行设计时，需要考虑不同功能单元的故障以及对应的处理策略，具体包括传感器接入能力失效，比如丢帧、乱序等；通用计算能力或 AI 计算能力失效，比如代码跑飞、执行超时等；内部通信及 V2X 能力失效，比如超时等；存储失效，比如高精度地图数据损坏等；电源失效 ；时钟失效。
计算基础平台加载自动驾驶应用程序，进而实现自动驾驶功能。对高等级自动驾驶功能进行分析，涉及到转向和制动的功能安全等级要达到 ASIL D 要求。根据功能安全 ASIL 等级分配和分解原则，计算基础平台需要满足 ASIL D 要求。基于计算基础平台的不同实现技术方案，自动驾驶操作系统和异构硬件分布架构需要各自的 ASIL 等要求。
2.1 异构硬件架构功能安全要求
异构架构主要包括 AI 单元、计算单元和控制单元。根据不同的架构需求，这些单元可由一个或多个芯片组成，芯片的种类可能包含 GPU/FPGA/ASIC、SoC、MCU 等。
由于现有关键器件的功能安全能力的局限性与 ASIL D 系统对单点失效度量的严格要求，硬件冗余是实现高功能安全等级安全目标的常见方式。冗余式硬件架构的主体是通过对冗余计算单元输出结果的相互校验达到提高计算单元硬件故障诊断覆盖率的目的。由于对相互冗余系统的独立性要求，相互冗余的系统需尽可能的避免由同源输入、共用资源、环境影响等因素引起的共因失效。
功能安全在硬件层面关注硬件器件中的安全相关故障可以通过自检或外部监控的方式被检测到，并在故障容忍时间内实现安全状态。硬件器件实现安全状态的方式多为重启、断电、报错、禁言等，因此单硬件通路的硬件架构可以满足 Fail-Safe 概念的需求。根据车载智能计算硬件平台所承载功能与功能安全要求分配的不同，AI 单元、计算单元与控制单元所选用的芯片可通过单器件或冗余的方式实现相应的功能安全等级，如图 2 所示。
图2 单硬件通路Fail-Safe抽象硬件架构
图3 多硬件通路Fail-Operational抽象硬件架构
随着自动驾驶的发展，Fail-Safe 的安全策略难以满足高等级自动驾驶的安全要求。基于 L3 以上自动驾驶功能对系统 Fail-Operational 的需求，越来越多的车载智能计算平台在主通路实现 ASIL C-ASIL D 的基础上增加与主通路相互监控的 Fail-Operational 通路来实现主通路失效情况下硬件层面的失效可操作性，以提高系统的安全性和可用性，如图 3 所示。
2.2 车控操作系统软件功能安全要求
自动驾驶操作系统软件是计算基础平台的核心，包括功能软件和系统软件两部分。功能软件融合多种跨产业技术，基于自动驾驶共性需求对通用模块进行定义和实现，主要包括自动驾驶通用框架模块、传感器抽象功能、感知融合功能、预测功能、定位功能、决策规划功能、执行器抽象功能等。系统软件是提供公共服务和管理、支撑软件运行的载体，面向底层提供基于异构分布式硬件 / 芯片组合的硬件系统，为上层的软件系统提供与硬件无关的运行环境和开发接口，主要包括虚拟化软件、操作系统内核、中间件等组件。
基于不同的自动驾驶应用场景，功能软件需满足对应的 ASIL 等级要求。主要通过软件功能安全技术和流程来保障。技术上，功能软件需采用容错技术和避错技术，在每个软件层级的每个功能安全相关软件节点都有相应的故障监测和处理机制；流程上，需按照软件功能安全、ASPICE 等要求，避免系统性失效。
系统软件同样需要满足软件功能安全技术和流程要求。由于计算基础平台架构中各单元有多重不同安全等级的需求，是典型的混合关键性系统，需要多内核功能安全设计。多内核应满足安全性和实时性要求，提供空间地址保护，保障各操作系统服务通过协作的用户进程实现，在独立的地址空间运行。
系统软件的虚拟化组件需满足高等级功能安要求。如 Hypervisor 组件可以将关键安全系统与非关键安全系统分区和隔离，从而确保关键系统被隔离并在系统发生故障时进行安全管理。不同 ASIL 等级要求的软件组件在共享资源时应使用有免于干扰的机制，避免冲突。
图4 软件架构组件免干扰机制
如图 4 所示，一个 QM 软件要素干扰并阻止了 ASIL 等级软件要素的及时执行。这样的干扰也可能发生在不同 ASIL 等级的软件组件之间。通过在软件中引入“检测点”并对检测点进行超时监控，可探测到时序干扰并触发合适的响应， 实现有免于干扰的机制。
系统软件需要借鉴 Adaptive AUTOSAR，采用 POSIX 接口，并满足功能安全要求。POSIX 能够满足自动驾驶所需要的高性能计算和高宽带通信等需求。系统软件让不同的内核支持 POSIX API 以支撑 AUTOSAR 规范中的规定的基础功能及服务。通过 CRC 校验、定时器等功能安全措施识别报文丢失、报文延迟和报文篡改等通信接口失效，保障 API 接口的功能安全满足需求。
2.3 工具链能安全要求
功能安全标准提出了对软件工具的置信度要求。计算基础平台工具链主要包括开发工具、集成工具、仿真工具、调试工具和测试工具，属于含软件的工具类别，为保障自动驾驶功能达到 ASIL D 等级，工具链需满足功能安全工具置信度要求。
软件工具置信度的相关安全分析工作主要分为三个阶段：分级阶段，对工具进行分析和评估，是否需要鉴定；鉴定阶段，对有需求的关键性工具进行鉴定；使用阶段，安全地使用这个工具。
图5 工具链置信度分析
在软件工具置信度分析过程中，主要得到四个文档，如图 5 所示。工具分级报告（TCR，Tool Classification Report），工具分级的结果，包含对工具中潜在错误的风险分析；工具安全手册（TSM，Tool Safety Manual），工具使用时应遵守的手册，包含对用户使用工具时重要的安全说明，如工具中的潜在错误、实际错误、其他的已知错误（Known Bug），以及用户需要执行的各项缓解措施等；工具鉴定计划（TQP，Tool Qualification Plan），描述工具鉴定时，针对工具的某个功能或某个步骤所计划执行的相关措施（主要是测试）；工具鉴定报告（TQR， Tool Qualification Report），工具鉴定的结果，主要是测试结果。
TSM 中的内容也体现了分级的结果。如果分级时将工具的某些功能归为“未使用”，则用户在实际开发时也不允许使用它们。如果在分级的时候指定通过缓解措施可以识别 / 避免一些潜在错误，那么这个措施也必须写在安全手册中，用户在使用时也必须如此执行。如果将一些潜在的工具错误被分级为无法 / 很难检测到，那么必须对这个工具进行鉴定，即通过测试的手段，以确保这些潜在的错误不再造成麻烦。通过测试，一些潜在错误会被排除，一些潜在错误会转化为实际的、具体的工具错误。针对这些存在的错误，需要采取一些相应的检测 / 避免措施，这些措施也必须包括在安全手册中。另外，在 TSM 中还需要包括相关的已知错误（Known Bug）的处理对策。
为确认计算基础计算平台达到了 ASIL D 的要求， 需要对其进行功能安全评估。本文提出了三维评估框架，从流程、开发过程、测试验证三个方面展开，综合确认计算基础平台的功能安全合规性。
3.1 流程评估
流程评估主要是对功能安全管理、生产和运行、支持过程等内容进行审核，确认计算基础平台在这些阶段的活动符合要求，能够通过合规的流程避免或减少系统性风险，提高开发效率。功能安全管理要符合整体功能安全管理、产品开发过程的安全管理和生产发布后的安全管理预期。计算基础平台要符合生产、运行、服务和报废相关的活动要求。要满足功能安全支持过程要求，如变更管理、配置管理、文档管理、分布式开发接口、安全要求的定义和管理、软件组件鉴定、硬件要素评估等。
3.2 设计开发评估
开发过程评估主要是对系统阶段、硬件阶段和软件阶段进行审核，确认计算基础平台产品在开发过程中符合各阶段功能安全技术要求。系统阶段功能安全评估主要是确认计算基础平台按照功能安全要求进行了系统架构设计及分析，提出技术安全要求，分配给软硬件接口规范。硬件阶段功能安全评估主要是确认计算基础平台按照功能安全要求进行了硬件安全要求定义、硬件功能安全指标评估。软件阶段功能安全评估主要是确认计算基础平台按照功能安全要求进行了软件安全要求定义和软件架构设计。
3.3 测试验证评估
测试验证评估主要是对计算基础平台软硬件以及系统集成测试结果进行评估，确认产品开发的安全需求得以实现。
自动驾驶系统完成硬件和软件开发后，进入集成和测试阶段，主要验证在自动驾驶系统架构层面开展的安全分析所定义的安全措施是否得到了正确实施，为集成后的系统满足根据自动驾驶系统架构所设计的安全要求提供充足的证明。软硬件集成测试的对象是自动驾驶系统内 / 外部的软硬件接口，为软硬件接口是否符合接口规范定义提供证明。系统集成测试的对象是集成后的自动驾驶系统，为自动驾驶系统的要素正确交互、符合技术要求和功能安全要求提供证明，并为不可能导致违背安全目标的非预期行为提供足够的置信度水平。整车集成测试的对象是集成了自动驾驶系统的整车，为集成后整车系统故障造成的非预期风险足够低提供证明。
智能网联汽车计算基础平台基于异构分布的硬件平台，集成自动驾驶操作系统，提供高性能计算力，实现集中控制策略，保障智能网联汽车感知、决策、规划、控制模块的高速可靠运行。随着自动驾驶级别的提升，自动驾驶系统所需要处理的数据呈几何倍增，自动驾驶系统实时性要求、安全等级要求不断提高。
本文以智能网联汽车计算基础平台为对象进行功能安策略和系统设计分析。对异构分布硬件的单硬件通道和多硬件通道分别提出 Fail-Safe、Fail-Operational 要求；对车控操作系统软件进行免干扰机制分析；对工具链提出置信度分析过程。最后，提出智能网联汽车计算基础平台多维功能安全评估框架，确认平台产品开发符合功能安全要求。
参考文献
[1] 李克强.智能网联汽车系统基础平台及其产业化对策[J].智 能网联汽车,2019(1):40.
[2] 中国软件评测中心.车载智能计算基础平台参考架构1.0[J]. 智能网联汽车,2019(4):85-94.
[3] 汽车工程学会.中国智能网联汽车产业发展报告[M].北京: 社会科学文献出版社,2020.
[4] Collin A,Siddiqi A,Imanishi Y,et al.Autonomous driving systems hardware and software architecture exploration:optimizing latency and cost under safety constraints[J].Systems Engineering,2020,23:327-37.
[5] Behere S,Törngren M.A functional reference architecture for autonomous driving[J].Information and Software Technology.2016,73:136-50.
[6] Pimentel J.Fail-Operational Safety Architecture for ADAS Systems Considering Domain ECUs[C]//The Safety of Controllers,Sensors,and Actuators.2018.
[7] 中国软件评测中心.车载智能计算平台功能安全白皮书[J]. 智能网联汽车,2020(4):18-24.
[8] 赵正旭,白英杰,吴晓进.国产操作系统JSP服务器部署策略的设计与实现[J].软件,2018,39(6):196-200.
[9] 李洁,何军.云计算操作系统网络虚拟化模块Neutron分析研究[J].软件,2016,37(01):21-23.
[10] 胡杨.Rtems 嵌入式操作系统的移植[J].软件,2015,36(12): 108-113.
[11] 严刚,肖堃,褚文博.智能网联汽车计算平台虚拟化技术研究[J].汽车工程,2020,42(1):33-37+58.
[12] 马文辉,郭云川,张会兵,等.安全多执行机制的无干扰性研 究[J].软件,2015,36(6):83-87.
[13] 苏奎,张彦超,董默.一种计算机安全评价系统设计[J].软 件,2015,36(4):119-122.
[14] ISO 26262 Road vehicles-Functional safety-Part 8: Supporting processes,2018.
[15] Slotosch O.Model-Based Tool Qualification[C]// International conference on software engineering and formal methods;International symposium on Innovation and sustainability in education;International symposium on modelling and knowledge management for sustainable development;International workshop.
