2020年车载智能计算平台功能安全白皮书.pdf

车载智能计算平台功能安全白皮书 （ 2020年） 中国软件评测中心 智能网联驾驶测试与评价工业和信息化部重点实验室 赛迪（浙江）汽车检测服务有限公司 二二年 十二 月 顾 问 李克强 清华大学 尚 进 国汽智控 （北京） 科技有限公司 黄子河 中国电子信息产业发展研究院 编写单位 （ 按笔画排序 ） 工业和信息化部计算机与微电子发展研究中心（中国软件评测中心） 北京百度网讯科技有限公司 北京地平线机器人技术研发有限公司 北京经纬恒润科技 股份 有限公司 华为技术有限公司 国汽智控 （北 京） 科技有限公司 国汽（北京）智能网联汽车研究院有限公司 英博超算（南京）科技有限公司 参研单位 （ 按笔画排序 ） 中汽创智科技有限公司 中国汽车电子产业联盟 中国第一汽车集团有限公司 北京艾迪智联科技有限责任公司 泛亚汽车技术中心有限公司 浙江吉利控股集团有限公司 编 写 专家 （ 按笔画排序 ） 王亚丽 王 伟 王舜琰 田 峰 刘法旺 李怀洲 李艳文 吴丹丹 余 响 沈伟锋 宋 娟 张妍嫣 张 斌 张露阳 高 远 褚文博 版权声明 本白皮书版权属于中国软件评测中心，并受法律保护。转载、摘 编或利用 其它方式使用本白皮书文字或者观点的，应注明 “来源：中 国软件评测中心 ”。违反上述声明者，本单位将追究其相关法律责任。 I 目 录 编制概要 . 1 （一）编制方法 . 1 （二）特别说明 . 1 一、研究背景 . 3 （一）智能网联汽车的安全体系不断完善，其中功能安全是关键要素 . 3 （二）国内外企业竞相发力车载智能计算平台，其功能安全备受重视 . 3 （三）车载智能计算平台功能安全缺少共识，亟需行业专家 联合研究 . 4 二、车载智能计算平台功能安全概述 . 5 （一）功能安全及相关标准 . 5 （二）安全生命周期 . 7 （三）功能安全管理 . 8 三、车载智能计算平台概念阶段功能安全 . 11 （一）相关项定义及要素划分 . 11 （二）相关项层面的影响分析 . 12 （三）危害分析和风险评估 . 12 （四）功能安全概念 . 13 四、基于功能安全的车载智能计算平台开发 . 14 （一）系统层面 . 14 （二）硬件层面 . 18 （三）软件层面 . 24 五、车载智能计算平台生产、运行、服务和报废 . 30 （一）软件升级 . 30 （二）安全事件应急响应机制 . 30 六、发展建议 . 31 （一）明确需求统一认识 . 31 （二）推进配套工具研发 . 31 （三）完善检测认证体系 . 31 （四）加强专业人才培养 . 32 附件：缩略语 . 33 1 编制概要 （一）编制方法 一是研究学习国内外相关文献，充分参考借鉴国内外最新产业动 态和研究成果。 二是调研国内外 智能网联汽车、功能安全 相关企业，汇集整理和 分析来自实践应用的相关素材。 三是邀请行业专家进行技术研讨和咨询评审。 （二）特别说明 1）研究聚焦车载智能计算平台功能安全 汽车产业是我国国民经济的重要支柱产业，是推动实现制造强国 和网络强国建设的重要支撑和融合载体。在 “新四化 ”背景下，汽车电 子电气架构正在由分布式向集中式持续演进，自动驾驶成为产业竞争 的焦 点，汽车电子产业链和技术链面临重构。在此背景下，支撑实现 自动驾驶功能的车载智能计算平台 的 重要性更加凸显。国内外企业都 在积极布局，加快推进产品研发和应用示范。 功能安全、预期功能安全和信息安全构成了智能网联特别是 自动 驾驶 系统 的安全要素。为凝聚共识、形成合力，加强车载智能计算平 台安全体系的研究，推动智能网联汽车产业高质量发展，在车 载智 能计算平台白皮书（ 2018年）车载智能计算基础平台参考架构 1.0 （ 2019年）研究的基础上，本白皮书聚焦车载智能计算平台的功能 安全。 2 2）研究内容仍有待进一步丰富完善 本白 皮书 的主要观点和内容仅代表编制组目前对车载智能计算 平台功能安全的研判和思考， 与此同时车载智能 计算平台的功能安全 仍在探索推进， 欢迎各方专家学者和企业代表提出宝贵意见，共同推 动研究的及时更新和纠偏。后续中国软件评测中心将会继续推出汽 车智能计算平台白皮书（系列）。 3 一、 研究背景 （一）智能网联汽车 的 安全体系 不断完善 ， 其中功能安全是 关键要素 在汽车产业朝着智能化、网联化、电动化、共享化的 “新四化 ”趋 势不断深入发展的同时，汽车电子电气系统的复杂度与集成度不断提 高，新的功能越来越多地触及到系统安全工程领域。 安全 是智 能网联 汽车 持续健康发展的前提 。 智能网联汽车安全 体系 的内涵和外延也在 不断发生变化 ，功能安全、预期功能安全和信息安全构成了智能网联 特别是 自动驾驶 体系 的安全要素。 功能安全的融入是自动驾驶技术发展的客观要求。功能安全在自 动驾驶系统的全生命周期中起着指引、规范、控制的作用。明确的功 能 安全要求 、 技术方案 和规范的功能安全开发流程 可以 降低和避免 来 自系统性失效和随机硬件失效的风险。系统在运行过程中出现故障时， 也依赖于功能安全机制 确保 系统进入安全状态 。 （二） 国内外企业竞相发力 车载智能计算平台， 其 功能安全 备受重视 自动驾 驶技术 不断发展， 车载智能计算平台是 L3 及以上自动驾 驶的必要解决方案 ，也是汽车新型电子电气架构的核心 。其包含异构 处理芯片、模组、接口等硬件以及车控操作系统、应用软件等软件， 处理海量多源异构数据，是用于实现全部或部分动态驾驶任务和（或） 执行动态驾驶任务接管功能的软硬件一体化平台。 国内外企业如英伟 4 达、特斯拉、华为、中兴、地平线、百度、恒润等纷纷推出高性能产 品。 随着自动驾驶 等级 的提升，汽车的 环境感知、 决策权 和 控制 权逐 步 实现由驾驶员为主体向自动驾驶系统 为主体 的 过渡 ，智能网联汽车 的安全风险急剧增加。 车载智能计算平台的 功能安全重要性日益 凸显。 车载智能计算平 台及关键零部件的开发和集成验证强化 了 对安全相 关系统开发流程的需求。 整车企业和 零部件供应商 重视功能安全的研 究和实施， 重新赋能技术人员，组织架构 或 随之调整。 （三）车载智能计算平台功能安全 缺少共识， 亟需 行业 专家 联合 研究 车载智能计算平台 的 功能安全 目前尚未形成行业 共识。功能安全 在 ADAS（ Advanced Driver Assistance System， 高级驾驶辅助系统 ） 领域的实践已形成一定的共识，并主要由 Tier 1（ 汽车零部件一级供 应商 ） 巨头企业 主导。当前对于整车企业、 零部件供应商以及 自动驾 驶 解决方案提供商，功能安全在 L3 及以上自动驾驶领域的具体实践 仍在 探索推进 ，行业共识尚未形成，影响了车载智能计算平台产品功 能安全 开发 以及 上车 应用。 联合行业优势资源共同研究车载智能计算平台的功能安全， 可以 为我国车载智能计算平台的技术创新、标准研制、试验验证、应用实 践、产业生态构建等提供 指导 ， 促进行业上下游达成共识，加速汽车 产业和电子产业的融合， 推动车载智能计算平台的持续健康发展。 5 二、车载智能计算平台功能安全概述 （一）功能安全及相关标准 道路车辆 功能安全 的提 出主要是 降低汽车电子电气 系统的功能 异常表现引起的危害而导致的不合理风险。电子电气系统的失效 包括 硬件自身的随机 失效 及研发过程中引入的系统性失效（软件失效属于 系统性失效） 。 车载智能计算平台实现自动驾驶功能，需要具备可靠 冗余的安全设计，其核心系统须达到功能安全相关标准的要求。 1） ISO 26262 ISO 26262 Road vehicles Functional safety 为汽车电子电气系统提 供了整个安全生命周期功能安全活动的指导。 该标准 定义了汽车安全 生命周期 ， 同时还提出 ASIL（ Automotive Safety Integrity Level， 汽车 安全完整性等级 ）概念 。 ASIL分为 A、 B、 C、 D四个级别，系统的 功能安全风险越大，对应的安全要求越高。 ASIL D 为最高安全完整 性等级，对功能安全的要求最高。 ISO 26262于 2011年发布第一版， 2018 年发布第二版，目前第三版正在研制过程中。国家标准 GB/T 34590-2017道路车辆 功能安全修改采用了 ISO 26262-2011。 2） SAE J2980 SAE（ SAE International，国际自动机工程师学会 ） 发布了 SAE J2980 Considerations for ISO 26262 ASIL Hazard Classification（ ISO 26262 ASIL危险分类的注意事项 ） 标准， 用于指导 ASIL定级。 SAE J2980标准基于 ISO 26262 的既有定义，在 S（ Severity， 严重度）、 E 6 （ Exposure， 暴露率）、 C（ Controllability， 可控 性 ）三个指标的评估 方面做了更详细的说明， 为整车及零部件企业 功能安全开发 提供 参考。 3） UL 4600 UL 4600自动驾驶安全评价标准由 UL（ Underwriters Laboratories， 美国保险商实验室 ） 与 Edge Case Research（ 自动驾驶研究机构 ） 合 作开发，是针对自动驾驶 系统 的安全 评估 标准。 该标准 旨在为 自动驾 驶 设计提供完整的安全评价原则和体系，为机器学习、感知操作环境 和自动驾驶所需的硬件和软件提供安全性及可靠性评估。 UL 4600根 据自动驾驶系统的当前状态和对其操作环境的感知，评估自动驾驶系 统在无人为干预的情况下安全地执行预期功能的能力，帮助厂商梳理 所有 与 自动驾驶安全相关的领域，标明所有必需测试的项目，从而建 立系统 的 方法，确保设计团队不会遗漏某个 可 合理预见的问题。 4） ISO TR4804 2019年，由宝马发起，安波福、奥迪、百度、宝马、大陆、戴姆 勒、 克莱斯勒 、 HERE、英飞凌、英特尔、大众等 11 家公司共同发布 了自动驾驶 安全第一白皮书，阐述了如何在自动驾驶系统上综 合运用功能安全 、 预期功能安全 和 信息安全的方法论。 ISO （ International Organization for Standardization， 国际标准化组织 ） 基 于这份白皮书，将发布 全球第一个专门针对自动驾驶的应用安全标准 ISO TR4804 Road vehicles - Safety and cybersecurity for automated driving systems - Design, verification and validation（道路车辆 自动驾 驶系统的功能安全和网络安全 设计、验证和确认 ） 。 7 5） A-SPICE A-SPICE（ Automotive Software Process Improvement and Capacity dEtermination，汽车软件过程改进及能力评定）是汽车行业用于评价 软件开发团队的研发能力水平的模型框架。最初由欧洲 20 多家整车 企 业在 SPICE（ ISO 15504）的基础上共同制定，是专门针对汽车软件 开发的行业标准。多年以来， A-SPICE在欧洲汽车行业内被广 泛用于 研发流程改善及供应商的研发能力评价。 A-SPICE根据 度量框架 将企 业的软件研发能力划分为 6个级别， 0级为最低， 5级为 最高。 （ 二 ）安全生命周期 功能安全明确定义了 安全 生命周期 ，要求 将安全生命周期要求融 入到自身的流程体系中， 建立安全文化，对企业的功能安全做全面管 理 ， 满足 ISO 26262中对流程活动的要求。功能安全生命周期包括概 念阶段、产品研发、生产、运行、服务和报废 等阶段 。 概念阶段包括 相关项定义、危害分析和风险评估、功能安全概念 的确定 。系统 层面 的产品开发基于 V模型，包含技术安全要求、系统架构、系统设计和 实施、集成、验证和安全确认。硬件层面的开发过程也是基于 V 模 型，包括硬件需求规范、硬件设计和实现、硬件集成和验证。软件层 面 的开发过程 同样 是基于 V 模型，包括软件需求规范、软件架构设 计 、软件单元设计 和实现、软件 单元测试、 集成和验证。生产、运行、 服务和报废阶段的计划以及相关要求规范是在系统 层面 的产品开发 阶段开始的，并且与系统 层面 的产品开发、硬件层面的开发、软件层 面的开发同步进行。此阶 段确保相关项或 要素 的生产、运行、服务和 8 报废 的功能安全。 车载智能计算平台 开发 一般为 SEooC（ Safety Element out of Context， 独立于环境的安全要素 ） 方式 。 这种开发方式不会受限于某 个具体的项目 ， 需要基于前期市场调研或以往项目积累， 对车载智能 计算平台承接的安全目标、功能 安全要求 以及 汽车电子电气 架构做基 础假设 。 企业可根据自身的产品和业务特性对 ISO 26262中不必要的 章节进行裁剪，将裁剪后的安全生命周期应用到实际的项目中。 图 1 为车载智能计算平台功能安全生命周期参考示意图。 图 1 车载智能计算平台功能安全生命周期参考示意图 （三）功能安全管理 车载智能计算平台功能安全管理贯穿于整个安全生命周期，并与 安全生命周期的每个阶段并行，大体可以分为整体安全管理、产品开 发阶段安全管理以及产品发布后的安全管理 。整体安全管理侧重于企 9 业或部门层面，聚焦功能安全文化建设、功能安全能力建设等。开发 阶段安全管理侧重于产品开发过程中的组织 架 构、人员配置、开发活 动计划以及文档交付计划等。产品发布后的安全管理主要是关注生产 和售后层面，包括生产、运行、 服务 、报废。 在整体安全管理中， 质量管理是功能安全管理的基础， 相关企业 或部门须具备质量体系，具有独立的质量部门实施产品质量审核。 功 能安全部门和质量管理部门可以合二为一，但是功能安全需要满足独 立性要求。 功能安全的管理要求应该融入到基础质量管理活动中， 根 据产品不同的功能安全等级要求选择不同的安全活动以及安全措施 。 在企业或部门内部要建立一种正向的功能安全文化，鼓励能够提升产 品安全性的活动。对于功能安全相关人员必须建立完整的能力培养及 评定体系，培养识别优秀的功能安全经理及功能安全工程师。同时应 当建立起必要的沟通机制以及异常管理机制。 在产品开发过程中，需要配备独立的安全经理跟 踪安全相关的活 动，解决安全相关的问题。对每 个开发阶段 ， 需要制定详细的开发计 划、验证计划以及认可评审计划 。 如果涉及到供应商，需要通过签署 DIA（ Development Interface Agreement，开发接口协议）明确双方责 任和义务。在开发计划中，必须定义各个阶段的交付产物以及责任人、 交付时间点等 。 在交付产物中相关内容要建立关联关系，做到需求和 设计、设计和开发、开发和测试双向可追溯 。 安全经理需要跟踪这些 活动以及要求的落地 ， 对因为安全导致的成本问题、交付时间问题需 要及时沟通，合理有效地协调资源以更好地平 衡功能安全和成本、开 10 发时间之间关系。认可评审产品不同的 ASIL等级需要满足不同的 独 立性要求，必要时可以引入第三方机构进行独立 功能安全评估 。 在生产、运行、服务和报废阶段，功能安全管理需要定义明确的 生产操作规范、维修流程、报废回收流程保证最终产品在全生命周期 不会影响环境及人身安全。 11 三、车载智能计算平台 概念阶段功能安全 （一） 相关项 定义及 要素 划分 相关项是实现车辆层面或部分功能的系统或者系统组。相关项定 义并描述 系统或系统组 ，以及其与环境、其他相关项之间的依赖关系 和交互影响，为充分理解相关项提供支持，以便执 行后续阶段的活动。 车辆层面的相关项定义 如图 2所示 ，主要包括相关项的功能、系统边 界 与 接口、环境条件和法律要求等。车载智能计算平台的相关要素主 要包括传感器接入及管理、 AI（ Artificial Intelligence， 人工智能 ） 计 算、通用计算、车控、 内部通信 、 V2X（ Vehicle to Everything，车用 无线通信技术） 、 高精度地图 数据 存储 等。 图 2 相关项定义 12 （二） 相关项 层面的影响分析 车载智能计算平台的开发项目分为新开发、修改或复用，若为修 改和复用，则需要进行相关项层面的影响分析。 影响分析应识别和指 出因相关项的修改、相关项使用条件的修改所带来的影响， 可能 的修 改 包括运行场景和运行模式 、 与环境的接口 、 安装特性 、 环境条件 等 。 高级别自动驾驶相对于辅助驾驶在运行环境感知范围和驾驶任 务上会发生变化，例如： 1）设计运行范围对感知要求的变化 相对于辅助驾驶系统面临的运行环境条件，高级别自动驾驶系统 相对减少对驾驶员的依赖， 需要感知 的 车内外环境范围更广 ， 以确保 自车行驶过程中 的 道路安全。 在某些场景和系统设计中，需要对自车 周围影响道路安全及自车定位的动态和静态物体感知。 2）动态驾驶任务和人为因素的变化 L3 及以上的自动驾驶系统相对于辅助驾驶系统容许一定程度的 驾驶员不在环。在 系统发现预期无法处理或者无法保证动态驾驶任务 安全执行等紧急情况时，为 使车辆控制权被快速接管并避免危害，驾 驶员状态也需要被感知（如监测驾驶员专注度、心率等生理状态）。 （三）危害分析和风险评估 通过危害分析和风险评估确定 ASIL等级和安全目标，以避免不 合理的风险。 为此，根据相关项中潜在的危害事件，对相关项进行评 估。安全目标以及分配给它们的 ASIL等级是通过对危害事件进行系 13 统性的评估所确定的。 ASIL 等级是通过对影响因子严重度、暴露率 和可控性的 预估所确定的，影响因子的确定基于相关项的功能行为， 因而不一定需要知道 相关项的设计细节。 关键步骤 具体 包括 场景分析 及危害识别 、 危害分级 、 ASIL 等级的确定、 安全目标的确定 。 由于 在动态驾驶任务中， L3 及以上 自动驾驶相对于辅助驾驶，容许一定 程度的驾驶员不在环 ， 将会导致对危害的可控性降低，在进行危害分 析与风险评估时， 可控性 或 将变为 C3， 可能会引起 功能安全等级需 求的 提升。 （四） 功能 安全概念 功能安全概念 是 从安全目标中 导出 功能 安全要求 ，并将其分配给 相关项的初步架构 要素 或外部措施。功能安全概念包括 安全目标、初 步安全架构设计、安全分析、安全要求。 安全架构设计方面， L3 自动驾驶系统已经允许 驾驶员的手长时 间脱离方向 盘， 无需 时刻观察道路状况 ， 从系统出现失效到驾驶员 反 应并 接管控制存在一定时间间隔。在这段时间间隔内，系统要确保车 辆的安全性 ， 需要做到某一个单元失效的情况下， 车辆能够维持横纵 向控制直到驾驶员接管或安全停车，因此需要冗余的架构设计 。一般 来说，对于整个自动驾驶系统的 冗余设计 又可以细分为电源冗余、执 行机构冗余、传感器冗余、 计算平台 冗余 、 用户交互链路冗余 等 。 从安全目标可以导出 安全要求 ， 安全要求 继承安全目标的 ASIL 等级。一个 安全要求 可以 分解为两个 或多个子 安全要求 ，分配到 独立 冗余的安全架构设计中 。 独立性是 ASIL分解 的重要要求，即 冗余单 元之间 应避免共因失效和级联失效 。 14 四、 基于 功能安全的车载智能计算平台 开发 （一）系统层面 1） 应用 环境 车载智能计算 平台，作为自动驾驶的主要部件，其 应用 环境 参考 如 图 3所示： 图 3 车载智能计算平台 应用 环境 参考 示意图 车载智能计算平台的 应用 环境主要包含用于环境感知（如摄像头、 激光雷达、毫米波雷达、超声波雷达等）和位置定位（如 GNSS、高 精度地图等）的传感器，整车底盘域、动力域以及车身域的执行器 ， 人机交互的 HMI（ Human Machine Interface， 人机界面） ，以及外部互 联与通信的 T-Box（ Telematics Box，远程车载信息交互系统） 和 OBD （ On Board Diagnostics，车载自动诊断系统） 等。随着自动驾驶等级 的不断提高， 车载智能 计算 平台 对 应用 环境 中的传感器 、 执行器 、 人 15 机接口和外部互联通信有更高的功能要求 及 功能 安全要求。 2）功能划分 车载智能计算平台按照功能可以分为传感器接入及管理、 AI 计 算、通用计算、通信、 存储 和车控等。不同的功能依赖不同的系统模 块实现。传感器接入与管理单元提供丰富的软硬件接口， 使能传感器 接入及管理。 AI 计算提 供深度 神经网络算法加速计算能力。通用计 算主要是 指面向 常规算法 的 计算能力。 车载智能计算平台 内部通信提 供车载智能计算平台内部各个 要素 之间通信能力。 V2X 通信 提供车 载智能计算平台连接 车辆 外部设备能力。 存储功能 提供 诸如 高精 度 地 图存储及服务 能力 。车控提供车控下发能力，对接车辆执行器。 车载 智能计算平台 功能单元参考 ASIL等级 如表 1所示 。 表 1 车载智能计算平台 功能单元参考 ASIL等级 1 功能单元 ASIL等级 传感器接入 与管理 B AI计算 B 通用计算 D 计算平台内部通信 D V2X D 存储 B 车控 D 1 鉴于各企业的解决方案并不相同，表 1 提供 的 部分功能单元 ASIL 等级 并 非通用 性参考 。 16 3）安全策略 自动驾驶 功能目前 的 系统安全 策略 大体分为两种，即 Fail-Safe （ 失效 -安全 ） 以及 Fail-Operational（ 失效 -可操作 ） 。 Fail-Safe要求系 统监控关键的部件以达到失效后系统 关断的目的 。但是 对于 L3 及 以 上的功能，驾驶员处于脱眼 、 脱手的状态，系统的关闭并 不能 保证可 靠 地 完成驾驶权的转移。 例如， 高速公路 场景中， 车辆紧急停止在本 车道是一种潜在的风险状态，很容易 发 生高速追尾。 Fail-Operational 安全 策略 解决了这一问题 ， 即使 在 主功能系统失效的情况下，仍然有 备份系统可以保证车辆进行降级操作，让车辆转移到 安全区域 。 4）系统设计 车载智能计算平台的安全策略可以是独立的监控模块或冗余的 系统设计。独立的监控模块实时监控功能实现模块的软硬件故障，一 旦检测到有 安全相关故障 ， 车辆 即 进入 安全状态，如需要 可先 进入紧 急 运行 模式 （ Emergency Operation） 。 例如， 功能降级、 当前车道停车 、 安全地点停车 等 。 冗余的系统设计是指两个或多个功能模块互为备份。 例如， 车载 智能计算平台可以采用“主处理单元 +辅处理单元”双处理 架构，以 确保 L3 及以上自动驾驶车辆的安全。在该架构下，主处理单元 对 车 辆的运动轨迹 进行 规划和控制 ， 辅处理单元的作用是监控主处理单元 。 同时两个单元不断地进行交叉检查，当两个通道在规划轨迹和控制策 略存在较大偏差时，系统就会进入降级模式 。 主处理单元和辅处理单 元 可以 按照 ASIL B设计开发，仲裁模块 可以 按 照 ASIL D设计 开发。 17 在系统阶段进行设计时，需要考虑不同系统单元的故障以及对应 的处理策略，具体包括传感器接入能力失效，比如丢帧、乱序等；通 用计算能力 或 AI 计算能力失效，比如代码跑飞、执行超时等；内部 或 V2X 通信能 力失效，比如超时等； 存储 失效，比如 高精度地图 数 据损坏等；车控失效，比如非预期发送车控等；电源失效 ； 时钟失效 。 5）技术安全概念 技术安全概念是 车载智能 计算平台系统设计中安全策略与安全 设计的集合。技术安全概念的内容主要包含基于系统架构的功能安全 分析 ， 基于上级 功能安全要求 与功能安全分析导出的技术安全要求 ， 最终集成安全设计的系统架构 ， 以及后续生产过程中需要采取的安全 措施。技术安全要求需要定义具体的安全机制并分配到相应的架构 要 素中，以确保在下一级的开发过程中，安全机制可以被进一步细化与 实施。在 车载智能计算平台 的开发 过程中，技术安全概念可能针对于 某一系统或子系统，因而技术安全要求 涉及的 架构层级可 以 不止 一层。 在 车载智能 计算平台的技术安全要求中， 若 采取多层次的技术安全 要 求，其基本原则不变，即技术安全要求要与架构层级相映射并最终被 分配到软件与硬件中，以保证软件与硬件的功能安全开发有明确和完 整的输入。 6）测试验证 车载智能计算平台在功能安全概念阶段开发或假设了上层的安 全目标和 功能安全要求 ，安全 要 求在之后各个阶段被逐渐细化和实现。 最终 完成 硬件层面及软件层面 开发和集成的车载智能计算平台能否 18 正确实现安全 要求 ，以及是否存在非预期的功 能，需要通过系统层面 的集成测试进行验证。系统 层面的 测试验证 ， 一方面需要确保安全 要 求能够被正确地 使能 ，另一方面还需要确保车载智能计算平台不会因 为 安全要求 非预期 使能 而导致系统可用性降低。 制定有序的系统层面测试计划，并进行持续的过程跟踪管理，是 保障 车载智能计算平台 测试验证工作有序可靠进行的必要途径。开发 测试团队应重点考虑 项目整体时间计划、 测试验证的人员安排与责任 分工 、 测试方法、测试环境、测试工具 等 方面的内容，综合评估和确 认之后形成测试计划 。 基于 SEooC 模式开发的车载智能计算平台实际应用到目标车型 时，系统集成测 试和整车集成测试是发现系统性故障不可或缺的安全 活动。在系统集成测试和整车集成测试活动中，需重点验 证目标车型 的功能安全要求是否得到正确实现 ， 集成真实的传感器和执行器等其 他其它 要素 之后的系统响应是否满足安全机制的要求 ， 车载智能计算 平台与目标车型其他 要素 之间的接口与交互过程是否正确 ， 以及安全 要求在外界严苛的环境条件和运行工况下能否正常实现。 （二）硬件层面 作为 车载智能计算平台 功能软件与系统软件的载体 ， 硬件的失效 可能 直接导致功能软件输出不可信任的结果 ， 从而违背安全目标。由 于硬件故障在硬件生命周期中发生时间的随机性 ，在通过改善流程降 低系统性失效的同时， ISO 26262功能安全标准在硬件层面重点关注 识别安全相关的硬件故障以及采取安全机制诊断相应硬件故障， 并对 19 发现的硬件故障进行处理（例如进入安全状态）， 从而将硬件随机失 效对安全目标的影响降低到可接受的程度。 1）随机失效概率量化指标 根据硬件故障对安全目标产生影响的不同， 硬件故障可分为安全 相关故障与非安全相关故障 ， 其中安全相关故障又进一步分为单点故 障 、 残余故障 、 多点可探测故障 、 多点可感知故障 、 多点 潜伏故障与 安全故障。其中 ， 单点故障和残余故障可以直接导致安全目标的违背。 多 点 潜伏故障虽然不会单独导致安全目标的违背 ， 但可能会在与其它 故障同时发生时导致安全目标的违背。 因此用于表示单点故障与残余 故障诊断覆盖率的 SPFM（ Single-Point Fault Metric， 单点 故障 度量 ） ， 多点 潜伏故障诊断覆盖率的 LFM（ Latent Fault Metric， 潜伏 故障 度量 ） 与 PMHF（ Probabilistic Metric for random Hardware Failures， 随机硬 件失效概率度量 ） 2是 功能安全用于衡量随机硬件失效率是否达到可 接受程度的重要衡量指标。针对于不同的 功能安全等级， ISO 26262 针对上述指标给出了 表 2中的参考性量化目标。下列数值是广泛应用 于业界评估安全系统是否满足相应功能安全等级的重要 指标 。 2 对违背安全目标的每个原因进行评估（ EEC）是另一种可选度量，参考 ISO 26262-5。 20 表 2 硬件随机失效度量参考量化目标 硬件度量指标 ASIL B ASIL C ASIL D SPFM 90 % 97 % 99 % LFM 60 % 80 % 90 % PMHF 107 h1 107h1 108 h1 2）关键器件的选型与集成 车载智能计算平台 的硬件 主要由 AI 单元 、 计算单元与控制单元 组成。根据不同的架 构需求，上述单元可由一个或多个芯片组成 ， 芯 片的种类可能包含 GPU（ Graphics Processing Unit， 图形处理器 ） /FPGA （ Field Programmable Gate Array， 现场可编程逻辑门阵列 ） /ASIC （ Application Specific Integrated Circuit， 专用集成电路 ） 、 SoC（ System on Chip， 系统级芯片 ） 、 MCU（ Micro Control Unit，微控制单元） 等。 芯片多采取 SEooC 开发模式 。 安全相关 芯片 供应商 在提供产品 的同时会 提供给 车载智能计算平台 的系统集成者相应的安全使用手 册。安全使用手册一般包含芯片 供应商 对系统功能 安全要求 的假设， 可支持的最高功能安全等级，集成的安全机制以及实现承诺功能安全 等级需要满足的假设条件。 车载智能 计算 平台选用的安全相关器件需要满足分配到该器件 的技术 安全要求 。 芯片 通常会对内部处理单元、存储单元、 通信 总线、 接口等元件提供相应的安全机制以满足安全相关故障的诊断覆盖率 要求 。除此之外，由于芯片的正常性能表现受限于一定的条件约束， 保证时钟、温度、供电等在可操作范围内的安全机制也对功能安全的 21 实现极为重要。车载智能 计算 平台需要按照各芯片厂商提供的安全手 册 搭建安全芯片外围电路和配置内部参数，确保芯片的安全内外部安 全机制正常运行，从而在出现故障时能够及时进入安全状态。 确保每 个 芯片 正确集成的同时，还需确保集成后的硬件架构满足所有安全目 标的随机失效概率量化指标 要求 。 3）硬件架构设计 由于现有关键器件的功能安全能力的局限性与 ASIL D系统对单 点失效度量的严格要求，硬件冗余是实现高功能安全等级安全目标的 常见方式。冗余式硬件架构的主体是通过对冗余计算单元输出结果的 相互校验达到 提高计算单元硬件故障诊断覆盖率的目的 。由于对相互 冗余 系统的独立性要求，相互冗余的系统需尽可能的避免由同源输入、 共用资源、环境影响等因素引起的共因失效。 功能安全在硬件层面 ， 关注硬件器件中的安全相关故障可以通过 自检或外部监控的方式被检测到 ， 并在故障容忍时间内实现安全状态。 硬件器件实现安全状态的方式多为重启、断电、报错、禁 言等，因此 单硬件通路的硬件架构 可 以满足 Fail-Safe 概念的需求。 根据车载智 能计算 硬件平台所承载功能与功能 安全要求 分配的不同， AI 单元 、 计算单元与控制单元所选用的芯片可通过单器件或冗余的方式实现 相应的功能安全等级，如 图 4所示。 22 图 4 单硬件通路 Fail-Safe抽象硬件架构示例 随着自动驾驶的发展 ， Fail-Safe的安全 策略难以 满足 高级别自动 驾驶 的 安全要求 。基于 L3 以上自动驾驶功能对系统 Fail-Operational 的需求，越来越多的车载智能计算平台在主通路实现 ASIL C-ASIL D 的基础 上增加与主通路相互监控的 Fail-Operational 通路 ， 实现主通路 失效情况下硬件层面的失效可操作性 ， 以提高系统的安全性和可用性， 如 图 5所示。需要注意的是 ， 根据自动驾驶功能等级对 Fail-Operational 系统在主通路失效情况下需要完成 的紧急 运行模式 的不同， Fail- Operational通路所包含的硬件单元可能会有所差异。 图 5 多硬件通路 Fail-Operational抽象硬件架构示例 23 4）供电系统设计 电源 是 整车电子电气架构中最基础的共用资源 。 如若电源系统发 生失效， 则 可能导致 车载智能计算平台的 所有功能失效，对于 L3 及 以上 自动驾驶系统是不可接受的风险。车载 智能 计算平台的供电系统 需要满足 Fail-Operational的要求，通常会采用双电源供电的方式。需 要考虑双路电源供电有足够的隔离措施，确保一路供电出现故障（电 压过高、过低甚 至出现短路） 时 ，另外一路供电不受影响。 为满足车载 智能 计算平台系统 ASIL D的要求，参考 ISO 26262- 5附录 E中关于电源系统失效模式与应对措施的要求，车载 智能 计算 平台的供电系统需要能够监控电源输入和输出是否存在异常，尤 其是 电源系统输出的监测和控制。若电源系统出现输出电压过高或过低故 障时，车载 智能 计算平台内部的主芯片有可能会因为供电电压不稳而 导致运算结果异常，最终导致违反安全目标。因此，电源系统需在输 出电压异常时，及时关断对应的主芯片供电，确保车载 智 能计算平台 输出为确定状态。 5）通信系统设计 车载智 能计算平台 作为 L3 及以上 自动驾驶的运算核心，通常通 过专用的 通信 通道传输外界环境信息，而 车载智能计算平台 实现融合 决策和车辆控制之后，将车辆运动控制指令通过 通信 总线发送至车辆 的纵向和横向控制执行器。总线 通信 通道可能因为线束破损、外界电 磁干扰和其他节点损坏等因素导致通信失效，包括报文丢失、报文延 迟和报文篡改等多种类型的失效模式。参考 ISO 26262-5附录 D的要 24 求，采用多种安全监测工具的组合可以满足高诊断覆盖率的要求，但 此种方法只能满足 Fail-Safe的要求，即发现 通信 故障，但无法维持系 统正常工作。 为了实现 L3自动驾驶功能 Fail-Operation的要求，可采 用硬件冗余的方式，一方面提高了诊断覆盖率，另一方面可满足 Fail- Operation的要求。 通信通道的 冗余设计需要考虑二者的独立性，例如 采用不同类型的 通信 协议（如 CAN-FD 和 FlexRay），避免 发生 共因 失效。 6） 硬件 测试 车载智能计算平台的硬件集成 完成 后，需要对硬件的安全性做全 面的测试。硬件测试用例的导出方法包含硬件 安全要求 分析、内部 及 外部接口分析、等价类生成和分析、边界值分析等。硬件测试需要涵 盖功能测试、故障注入测试、电气测试等测试方法来验证硬件 安全要 求 的正确性和完整性，另外还需要涵盖最恶劣情况测试、超限测试、 EMC（ Electromagnetic Compatibility，电磁兼容 ） 测试 和 ESD（ Electro- Static Discharge，静电放电 ） 测试等测试方法来验证车载智能计算平 台硬件的鲁棒性和耐久性。测试完成后需要输出全面的测试报告作为 硬件安全的佐证。 （三）软件层面 车载智能计算平台作为智能汽车的安全关键系统，软件层面的安 全性至关重要。由于车载智能计算平台功能丰富，应用场景复杂，对 软件的实时性、安全性、可靠性要求极高，应通过技术和 流程两个方 面保障软件的功能安全。技术上 确保 软件层级的每个功能安全相关软 25 件节点都有相应的故障监测和处理机制， 流程上按照软件安全生命周 期模型规范软件开发过程。 1）软件 安全要求 车载智能计算平台 软件 安全要求 是对软件安全相关的功能和性 能的具体要求，主要是通过技术 安全要求 在软件层面的分配得到，并 通过继承或分配得到相应的 ASIL等级。另外，在软件架构阶段执行 的软件安全分析也可能会识别出额外的软件 安全要求 。 采用专业的需 求管理工具来实现需求的编写、评审、管理以及双向追溯性检查可大 幅降低软件层面的系