自动驾驶车辆新型验证技术(一):部件开发流程

20世纪70年代末，为满足节油需求与早期汽车污染管控法规，微控制器开始用于控制车辆功能，计算机化系统最早应用于发动机控制，尤其是汽油发动机点火系统。80年代，早期电子燃油喷射系统、自动变速箱控制、自适应悬架相继出现，逐步形成集成式动力总成控制方案。

90年代，体积更小、单位算力成本更低的计算系统快速普及，更多车辆功能从机械/机电方案转向微控制器控制，依托安全气囊、防抱死制动系统（ABS）、牵引力控制、电子稳定程序等技术提升安全性；同时舒适性配置开始普及，如电动车窗、电动座椅、巡航控制、自动空调、电子仪表、信息娱乐与导航系统等众多先进功能。

2005年前后，片上系统（SoC）的普及开启了智能手机时代，这类单芯片完整计算机系统凭借通用性、算力与极高灵活性，在汽车行业中实现了更复杂的功能。最初引入泊车雷达、环视摄像头等辅助驾驶配置，随后自适应巡航控制（ACC）逐步普及；近十年，基于雷达、激光雷达、计算机视觉的更高级ADAS快速发展，如自动紧急制动（AEB）、避撞与缓解、车道辅助系统等。

近十年，子系统集成化成为趋势，以应对汽车行业同时面临的三大挑战：

1. 电动化：集成电力驱动系统，作为唯一动力源或提升内燃机效率；

2. 自动驾驶；

3. 网联化：实现车与车、车与路侧基础设施、车与云端的通信，实现音乐流媒体、导航交通信息更新，更重要的是支持嵌入式软件远程升级，尤其基于机器学习的软件组件。

图1.1：Cypress PSoC 5片上系统（SoC）的艺术化呈现

1.0.1 软件：机遇与问题

车载计算机系统带来了丰富的功能优势，但也存在隐患：用软件可编程逻辑替代物理过程或机械连接，可能引入可靠性问题，导致系统异常。这类问题在任务关键场景会造成巨额经济损失，在安全关键场景则可能引发事故，危及人员安全与环境。

为规避此类风险，需引入功能安全理念——从功能维度定义的安全观。功能安全并非汽车行业首创，其起源于60年代核工业、国防、航空航天行业计算机化系统普及后的安全需求。

汽车行业软件复杂度

某高端车企发布的文章显示，其车载嵌入式软件包含约1亿行高级语言代码，其中约1000万行为条件判断语句，分布在约300万个函数中，函数调用点达3000 万个；软件部署在超过120个电子控制单元（ECU）上，管理约7000路外部信号。

即便部分复杂度源于软件架构（如遗留代码复用、第三方组件），也无法大幅降低。

解决这类复杂度带来的可靠性问题，需通过严格开发流程保证软件质量：

· 遵循MISRA等规范，保证代码统一性、可读性，避免因平台相关指令引发未定义行为；

· 借助静态分析工具强制落地上述要求；

· AUTOSAR标准从高层抽象层面简化复杂度，统一软件组件接口；

· 基于模型的软件设计（MBSD）在保证质量无缺陷的前提下加速开发，同时模型可直接作为代码文档，实现平台无关的软件单元实现，简化测试工作。

1.1 车辆安全与驾驶功能自动化行业趋势

近年来，自动驾驶赛道竞争持续白热化，从商业视角看，这一阶段的核心特征为：

· 新型号研发投入巨大；

· 车企倾向于组建联盟，共享技术、分摊高额投入；

· 小型车企被淘汰或被大型车企收购。

1.1.1 商业应用

私人乘用车具备一定驾驶自动化能力的私人乘用车已上市多年，这类车辆采用驾驶员监控模式，对应SAE分级的L2级，或ECR分级的监督模式。

车辆安全策略以人类驾驶员为核心，驾驶员负责安全、持续监控自动驾驶系统，始终保持注意力在道路上，随时准备接管。

文献记载的典型事故：

· 多起致命碰撞（图1.2），源于驾驶员对自动驾驶系统过度依赖，部分事故从正常状态到致命碰撞仅用时不足10秒；

· 2018年美国亚利桑那州坦佩市致命事故：美国国家运输安全委员会（NTSB）初步报告指出，事故源于人机交互设计缺陷、行人违规横穿道路，自动驾驶软件未识别 “推自行车的行人” 这一特殊目标；且该系统设计中，驾驶员接管会禁用自动紧急制动，导致驾驶员无法及时制动避撞。

图1.2:2018年3月，加利福尼亚州发生一起涉及特斯拉汽车的撞车事故

SAE L4级及以上（或ECR自动化级）车辆——由车辆自身承担驾驶安全责任——已落地的应用包括：低速接驳车、包裹配送、车队运营（Robotaxi）。

低速接驳车这类公共交通车辆最多可搭载15名乘客，在固定路线低速行驶（低于30km/h），已在全球多城示范运营。按SAE分级为L5级，ECR分级为自动化模式，因需随车人员负责非驾驶类安全事项。

包裹配送轻型车辆（微型车尺寸）已进入示范阶段，用于商店到住宅的包裹配送，专为城市短途配送设计，依据当地法规与车型，可在机动车道、人行道、自行车道行驶。

其安全性依托低速、轻重量（低动能）与远程人工操作员，车辆遇异常可请求远程接管。这类专用车辆无法纳入SAE分级，ECR分级为自动化模式，因需远程驾驶员应急介入。

已发生的小事故包括：人行道机器人阻塞轮椅通道、行人对人行道空间占用产生矛盾。

车队车辆Waymo（图1.3）、亚马逊Zoox（图1.4）已小规模部署Robotaxi，中长途货运卡车在2020年起成为热点领域，大量企业布局。

图1.3：Waymo自动驾驶出租车

图1.4：亚马逊Zoox机器人出租车

这类Robotaxi按SAE分级为L5级，ECR分级为自主模式，无需随车人员。早期安全策略依赖随车安全驾驶员，当前趋势改为：车辆请求时，远程操作员随时可用。美国加州测试期间仅报告轻微事故。

1.2 自动驾驶车辆分级

1.2.1 SAE J3016标准

SAE J3016《道路机动车自动驾驶系统相关术语分类与定义》2014年1月首次发布，2016年9月、2018年6月两次更新。

分级依据：

· 运行设计域（ODD）范围（限定/不限定）；

· 动态驾驶任务（DDT）后备方案责任主体（驾驶员/后备用户/系统）。

DDT分为两大子项：

· 持续横向与纵向车辆控制；

· 目标与事件检测响应（OEDR）。

SAE J3016分级表如图1.5。

图1.5:SAE J3016自动驾驶汽车分类

1.2.2 ECR分级：基于责任的视角

Edge Case Research公司2021年1月提出替代分级方案，以用户为中心，定义四种工作模式（基本对应SAE L2~L5），明确驾驶、驾驶安全、其他安全的责任主体（驾驶员/车辆），如图1.6。

图1.6：Edge Case Research提出的操作模式分类

相比SAE分级，其优势是明确驾驶员在各模式下的责任。

辅助驾驶车辆仅配备ADAS功能，驾驶员需主动驾驶，如ACC、AEB、车道保持等。

监督驾驶车辆完成全部动态驾驶任务，但驾驶员需持续关注道路，系统提示异常时必须及时接管。商用代表：特斯拉Autopilot、通用Super Cruise。

自动化驾驶驾驶员可脱离道路注意力，车辆承担驾驶与驾驶安全责任；此类车辆发生碰撞，责任不在驾驶员。非驾驶类安全事项（如乘客系安全带、儿童座椅固定、火灾疏散等）仍需车内成年人负责；公共交通场景需随车人员全程值守。

自主驾驶无现场人员、无持续监控，车辆全权负责驾驶与所有安全事项。

1.3 功能安全

本文研究内容仅针对ISO 26262定义的功能安全（FuSa），但需明确其与自动驾驶系统整体安全、车辆安全、网络安全、动态驾驶功能、质量管理的交互关系，如图1.7。

图1.7：自主驾驶系统开发中涉及的标准之间的关系

涉及标准：

· 系统安全：UL 4600（自动驾驶产品评估标准，2020年4月发布）

· 车辆安全：FMVSS（美国联邦机动车安全标准）、NCAP（新车评价规程）

· 网络安全：SAE J3061（2016年1月）、ISO/SAE DIS 21434（2020年2月）

· 动态驾驶功能：ISO/PAS 21488（预期功能安全，2019年1月）、ISO/TR 4804（自动驾驶安全与网络安全，2020年12月）

· 功能安全：ISO 26262（道路车辆功能安全，2011年发布，2018年更新）

功能安全（FuSa） 核心：避免车辆非预期运行带来的不合理风险。ISO 26262仅关注道路车辆电子电气（E/E）部件故障引发的风险，不覆盖标称功能安全；标称行为安全由预期功能安全（SOTIF，ISO/PAS 21488）与UL 4600覆盖。

功能安全的最终目标：设计系统在任何场景下（包括故障发生时）都能及时、正确响应外部环境。

功能安全不覆盖：蓄意篡改、应用范围假设错误，仅覆盖可预防的误用、软硬件缺陷、随机硬件失效引发的安全风险。

所有未被FuSa覆盖的事项，仍需在质量管理（QM）框架下，在安全相关系统的概念、设计、生产、运维、退役全流程中考虑。

功能安全方法演进

ISO 26262面向非自动驾驶车辆，基于确定性软件，行为完全可预测，依赖危害分析与风险评估（HARA），通过ASIL等级定义后续开发严格度。危害清单依赖工程师经验、文献、同类部件，风险评估（严重度/暴露度/可控性）也依赖经验，最终导出安全目标并分配ASIL。

ISO 26262的局限：高度依赖驾驶员可控性，不适合无驾驶员的自动驾驶车辆，只能强制分配最高可控性等级。其设计反馈仅来自HARA，适合ABS、巡航、气囊等环境完全已知、软件确定性的功能。

图1.8：ISO26262框架内的HARA过程

ISO/PAS 21488（SOTIF）：面向L2及以上、基于机器学习的非确定性软件，覆盖标称功能风险，设计→测试→部署全流程闭环，发现异常需通过OTA持续更新软件，用关键绩效指标（KPI） 衡量偏差。

图1.9：ISO/PAS 21488（SOTIF）框架内的HARA过程

UL 4600：面向L5完全自主车辆，基于安全案例（Safety Case），将设计、测试、部署与安全案例绑定，结构为主张-论据-证据，引入上下文外元件（EooC），用安全绩效指标（SPI） 监控安全案例有效性。

图1.10:UL 4600框架内的HARA流程

图1.11:UL 4600安全箱的结构，带EooC

KPI vs SPI

· KPI：车辆是否按预期工作（精度、准确率、统计指标）；

· SPI：车辆超出风险预算、导致安全案例失效的频次。

图1.12：KPI和SPI之间的差异总结

1.3.2 FIDES指南

FIDES指南2004年发布、2009年更新，由航空航天企业联合制定，用于评估硬件设计中组件的随机硬件失效概率，见2.8节。

1.3.3 AIAG&VDA FMEA手册

AIAG与VDA 2019年6月联合发布FMEA手册，指导汽车行业开展失效模式与影响分析，用于概念阶段（2.2节），与硬件设计阶段的FMEDA（2.7节）区分。

1.4 本文技术贡献

本文围绕功能安全提出多项技术方案，提升车载微控制器基电子电气安全关键系统的可靠性。所有贡献均以仿真为核心，分为三大方向（图1.13）：

1. 基于仿真的FMEDA（6项方案）

2. 基于仿真的HARA（1项方案）

1. 实时软件验证（3项方案）

图1.13：本文讨论的主题，包括汽车项目的常见应用及其在ISO 26262安全生命周期中的地位

1.4.1 面向FMEDA优化的方案

FMEDA是ISO 26262第6部分（硬件开发）强制要求的技术，用于验证硬件设计是否满足对应ASIL的可靠性指标（表2.7）。方案主要应用于汽车行业案例，最后两项方案分别面向工业与移动机器人场景。FMEDA对所有安全相关电子电气部件强制要求，车企也会将其用于非安全舒适/车身功能，提升系统可用性与用户满意度。

1.4.2 面向 HARA优化的方案

HARA是ISO 26262安全生命周期的关键环节（概念阶段，第3部分），目标是定义安全目标并分配ASIL，等级对应安全目标失效时车内/车外人员面临的最大风险。

该方法从仿真FMEDA的方案演进而来，适配HARA的特点：

· HARA在概念阶段开展，无硬件原理图，仅基于车辆行为模型；

· 失效模式仅描述部件异常行为；

· 借助整车仿真，评估部件异常对整车与驾驶安全的影响；

· 仿真可量化严重度与可控性两项风险参数，提升评估客观性与可重复性。

主要应用场景：ADAS测试与验证。

1.4.3 面向实时软件验证优化的方案

实时软件验证对安全关键嵌入式硬实时系统至关重要，目标是验证嵌入式软件（应用+驱动+支撑组件）在规定时间内无截止期错过、正确输出结果。

核心工具：实时仿真器，管理主机（HMI）与实时机的通信，实时机运行被控对象模型并响应被测设备。硬件在环（HIL）测试已广泛用于工业闭环控制系统，但以下三类场景缺乏成熟方案：

1. 汽车车身控制模块（BCM）（该文“第三部分”5.1节）

2. 航空混合关键度系统（该文“第三部分”5.2节）

3. 多智能体机器人系统（该文“第三部分”5.3节）

混合关键度与多智能体技术看似与汽车无关，但行业需求快速上升：

· 混合关键度系统可减少车内ECU数量，降低成本；

· 多智能体策略优化网联车辆与他车、基础设施的协同。

本章介绍汽车行业功能安全现状，内容结构：2.1节：ISO 26262安全生命周期，包括标准结构、功能安全管理、确认措施；2.2节：概念阶段（第3部分），部件定义、危害分析与风险评估；2.3节：功能安全概念；2.4节：系统级开发流程（第4部分）；2.5节：技术安全概念；2.6节：系统级FMEA；2.7~2.8节：硬件级开发（第5部分），FMEDA、FIDES；2.9节：故障注入；2.11节：软件级开发（第6部分）。

2.1 安全生命周期

2.1.1 ISO 26262标准结构

ISO 26262:2018结构如图2.1。

图2.1：ISO26262:2018结构

2.1.2 功能安全管理

功能安全管理（FSM）是ISO 26262的核心，是安全生命周期落地的基础，并非独立流程，而是质量管理体系（QM）的增强。

前提：企业已落地ISO 9001、IATF 16949质量管理体系，再结合ISO 26262、ISO/PAS 21448、ISO/SAE 21434、UL 4600实施。

功能安全管理分为项目无关与项目特定两部分。

项目无关要求

· 功能安全培训与资质体系（安全文化）；

· 企业级安全生命周期与支撑流程；

· 功能安全持续改进流程；

· 前置实施ISO 9001 + IATF 16949。

项目无关工作产物

· 企业功能安全规则与流程；

· 员工能力证明；

· 质量管理体系证明；

· 安全异常上报规则。

项目特定活动每个项目必须制定安全计划，明确：

· 活动目标；

· 输入文档；

· 安全活动责任人；

· 时间与周期；

· 资源；

· 供应商接口；

· 工作产物标识。

安全计划还需定义验证与确认（V&V） 活动：

· 每项安全需求的验证方法（评审/分析/仿真/测试）；

· 各开发阶段验证步骤；

· 测试验证策略；

· 测试结果文档。

项目安全角色

· 安全经理：负责FSM，制定维护安全计划、监控执行、规划安全活动、记录进展、分配任务、管理交付物；

· 项目经理：任命安全经理，确保安全活动执行、合规性、资源保障；

· 安全团队：执行安全相关活动；

· 安全工程师：安全团队成员。

2.1.3 确认措施

确认措施需满足独立性要求：

· -：无要求/无建议；

· I0：建议执行，执行人需与工作产物创建人不同；

· I1：必须由与创建人不同的人员执行；

· I2：必须由独立于开发团队的人员执行（非同一直属上级）；

· I3：必须由管理与发布权限完全独立的团队执行。

表2.1、2.2列出各工作产物的验证要求。

表2.1：验证措施概述。o：无相关要求，也不对此提出支持或反对的建议；X：为必需项；X*：本综述的范围还包含被评定为QM类别的危害事件

表2.2：验证措施概述。o：无相关要求，也不对此提出支持或反对的建议；+：推荐采用；++：强制要求/必需项

2.2 概念阶段

概念阶段解决电子电气系统异常引发的危害，考虑系统间交互；仅关注E/E故障引发的危害，不覆盖电击、火、烟、热、辐射、毒性、易燃性、腐蚀等（除非由E/E故障直接导致）。

核心阶段与工作产物

1. 部件定义

2. 危害分析（HARA）

3. 功能安全概念（FSC）

核心目标

· 识别危害、制定安全目标并分配ASIL；

· 输出部件功能安全需求（FSR）；

· 输出初步框图，明确各模块安全目标与ASIL。

HARA流程如图2.2：安全目标由HARA导出，功能安全需求从安全目标分解，最终分配到系统架构设计。

图2.2：安全目标和功能安全需求的层次结构

2.2.1 部件定义

明确被分析的部件/系统，提供足够信息：功能、依赖、与其他系统交互，支撑HARA与功能安全概念开展（ISO 26262-3:2018第5章）。

2.2.2 危害分析与风险评估（HARA）

按ISO 26262-3:2018第6章执行，目标：

· 识别并分类部件异常行为引发的危害事件；

· 评估风险等级；

· 制定安全目标并分配ASIL，规避不合理风险。

HARA分为5个阶段（图2.3）。

图2.3：HARA分阶段细分

场景分析与危害识别（SA/HI）系统梳理驾驶场景，归纳式分析部件可预见异常行为引发的所有危害；需明确排除分析的故障与危害清单。

危险与可操作性分析（HAZOP）用于识别潜在失效与整车级危害，从流程行业引入，适配车辆功能，关键词：

· NO/NOT：无功能；

· MORE THAN INTENDED：过量；

· LESS THAN INTENDED：不足；

· NOT REQUESTED：非请求激活；

· INCORRECT DIRECTION：反向；

· EARLY/LATE：过早/过晚；

· LOCKED：锁死。

场景梳理通过以下维度组合生成场景：

· 地点：停车场、路口、城市、乡村路、高速；

· 速度：低/中/高/超高速；

· 交通：行人、前车、对向车、后车；

· 操作：轻/重制动、紧急停车、轻/重加速、超车、转弯、掉头、起步、直行；

· 驾驶员在/离车。

笛卡尔组合会产生海量场景，需剔除矛盾、违规场景；过度碎片化会导致暴露度评估失真，建议仅分析有意义、可能产生危害的场景，逐项给出定性分析依据。

危害分级导出三项风险参数：严重度（S）、暴露度（E）、可控性（C）。评估参考同类功能安全分析、文献资料，结合工程师经验适配具体案例。

严重度按表2.3分级：

· S0：无伤害

· S1：轻/中度伤害

· S2：重度/危及生命（存活不确定）/致命

· S3：危及生命（存活不确定）/致命

表2.3：ISO 26262-3表B1：严重程度分级示例

可控性按表2.4分级：

· C0：完全可控

· C1：简单可控

· C2：通常可控

· C3：难以控制/不可控

表2.4：改编自ISO 26262-3表6可控性等级

暴露度按时间占比或场景频次分级（图2.4、表2.5）：

· E1：极低概率

· E2：低概率

· E3：中等概率

· E4：高概率

图2.4：持续时间或频率的暴露分类

表2.5：改编自ISO 26262-3表6暴露等级；（“持续时间”行提取自ISO26262:2018-3表B.2；“场景发生频率” 行提取自ISO26262:2018-3表B.3）

ASIL确定技术风险降低措施分为4级：A、B、C、D，D最高。ASIL仅绑定安全目标，不绑定部件。通过三项参数组合，用风险矩阵（图2.5）确定ASIL。

摩托车MSILISO 26262第二版为摩托车定义MSIL，共4级，映射到ASIL（表2.6）。

图2.5：ASIL确定矩阵

表2.6：MSIL到ASIL的映射

安全目标定义危害评估完成后，为部件定义安全目标（SG），即“禁止发生的危险状态”，如“车辆不发生非预期加速”。每个安全目标分配最高等级 ASIL（对应其失效时人员面临的最高风险）。

独立评审HARA必须经I3 级独立评审（完全独立部门），验证完整性、准确性、分级一致性。

2.2.3 上下文外安全元件（SEooC）

多数场景下，部件/系统为特定车辆开发；但实际常使用商用现货（COTS）组件，或部件本身作为COTS出售，这类部件称为SEooC。

SEooC：不针对特定应用/功能/车辆开发的安全相关元件，如微控制器、驱动桥、仪表。开发时基于假设应用场景，设计满足假定安全需求与ASIL，遵循完整ISO 26262流程。集成方需验证假设与接口的有效性。

2.3 功能安全概念

功能安全概念描述如何实现安全目标，以功能安全需求（FSR）形式定义，分配到初步系统架构或外部措施。

图2.6：设计假设与SEooC开发之间的关系

建议用状态图描述部件状态：

· 标称工作模式；

· 紧急工作模式；

· 降级工作模式；

· 安全状态。

需明确状态切换逻辑。

2.3.1 功能参数

· 工作条件；

· 容错时间与间隔；

· 向安全状态/降级/紧急模式切换；

· 功能冗余。

警告与降级策略

· 故障安全（Fail-safe）：失效后关闭功能；

· 故障运行（Fail-operational）：降级性能继续工作（优雅降级）。

驾驶员动作若需驾驶员配合，需描述动作、平均驾驶员响应依据、无响应/错误响应后果、驾驶员培训方案。

2.3.2 安全架构

功能安全概念需用框图描述功能冗余与模块独立性，明确各模块ASIL要求与分解方案。

2.3.3 ASIL分解

ASIL分解：将安全需求的ASIL分配到多个独立元件，需满足独立性，规则如图2.7。

图2.7：ISO26262-9图2分解安全需求时ASIL的分类方案

2.3.4 功能安全需求

编写原则：最大化车辆可用性，同时保证运行安全。关键点：

· 基于潜在失效模式定义安全状态；

· 定义状态切换、降级、安全状态触发条件。

失效分类故障分为系统性失效与随机（硬件）失效（图2.8）：

· 系统性失效：确定性原因导致，仅能通过设计/工艺/流程/文档修改消除，软件仅存在系统性失效；

· 随机失效：硬件生命周期内不可预测发生，服从概率分布，分为永久性（损坏不可恢复）与瞬时性（一段时间后自愈，如存储器软错误）。

图2.8：系统和随机（硬件）之间的失效分类

功能安全应对策略：

· 系统性失效：预防，严格执行安全计划；

· 随机失效：失效发生后安全响应。

失效还可分为独立失效与相关失效（图2.9）：

图2.9：独立和依赖之间的失效分类

· 独立失效：联合概率=单失效概率乘积；

· 相关失效：不满足独立条件，分为级联失效与共因失效。级联失效需具体分析，共因失效可通过相关故障分析规避（图2.10）。

图2.10：相关失效分析

功能安全时序系统不仅要正确，还要及时，关键时间间隔（图2.11）：

· FDTI：故障发生→检测的最大时间；

· DTTI：在线诊断执行间隔；

· FRTI：检测→进入安全状态 / 紧急模式的时间；

· FHTI = FDTI + FRTI；

· FTTI：故障发生→危害事件的容忍时间；

· 缓解延迟：故障注入→进入安全状态的时间，必须 ≤ FTTI。

图2.11：与安全相关的时间间隔

2.4 实施阶段

技术安全概念（2.5节）完成并通过确认措施后，启动产品实施阶段，由ISO 26262第4（系统）、5（硬件）、6（软件）部分管理，软硬件并行开发，软硬件交互（HSI） 是可靠性关键点，尤其硬件故障的软件检测与缓解。

图2.12：系统级开发过程及主要涉及的文件

2.5 技术安全概念

系统级开发依据第4部分，核心输出技术安全概念（TSC），从功能安全需求与初步架构导出，包含技术安全需求（TSR）：

· 系统内部故障检测与控制机制；

· 外部系统故障检测与控制机制；

· 安全状态实现/维持措施（切换、容错、紧急运行间隔）；

· 警告与降级实现措施；

· 安全验证规范（独立验证计划）；

· 潜伏故障避免机制（测试间隔）；

· 潜伏故障控制机制（双点失效安全措施），ASIL需求：D→B，C/B→A，A→QM。

2.6 FMEA

AIAG&VDA 2019年FMEA手册分为7步（图2.13）：

1. 策划准备

2. 结构分析

3. 功能分析

4. 失效分析

5. 风险分析

6. 优化

1. 风险沟通

图2.13：AIAG和VDA FMEA手册描述的7个步骤

分为设计FMEA（评估设计）与过程FMEA（评估生产过程），本文关注设计FMEA。

2.7 硬件设计与 FMEDA

ISO 26262第4部分表1要求用归纳法+演绎法开展系统架构分析，FMEDA是归纳法核心，用于评估随机硬件失效后果，需结合FIDES（2.8节）计算失效率。

2.7.1 分级规则

FMEDA核心是失效模式影响分级，输出表格（图2.14），包含：

· 组件失效率（FIT，FIDES计算）；

· 失效模式、发生率、影响。

图2.14：FMEDA分析结果的内容

分级目标：判断失效是否可检测、是否单独导致安全目标违反（图2.15）。

图2.15：失效模式分类标准

2.7.2 速率与指标

（部件的）失效率

失效率，在下文中表示为λ^c，是可能影响FIT中表示的组件c的随机硬件失效的发生率。

从所有组件的失效率λ^c（作为硬件验证的输出结果）出发，工程师需通过计算随机硬件失效率、单点故障指标和潜伏故障指标，并证明这些指标满足该组件对应 ASIL 等级的目标值，以此提供其健壮性的验证证据。

由于单个组件可能以多种方式失效（每种失效方式称为一个失效模式），因此定义组件失效模式的发生概率λ^f是很方便的，基于此可针对特定失效模式f定义各类失效率与指标。

组件c的λ^c由λ^f乘以该失效模式f的发生概率计算得到。

组件失效率

组件总失效率λ指整个组件的故障发生概率，单位为FIT（失效时间，1 FIT =10⁻⁹/小时）。其定义为该组件物料清单（BOM）中所有组件（或所有组件失效模式）失效率的总和，如公式 (2.1) 所示：

危险未检测故障（单点故障）率

危险未检测故障率λ^f_DU指未被组件内置的任何功能安全机制检测到，且可** 单独（即单点）**导致一项或多项安全目标被违反，从而对组件使用者造成危害的故障发生概率。

单点故障率（spf） 定义为所有危险未检测故障率的总和，如公式 (2.2) 所示：

危险已检测故障（残余故障）率（Dangerous detected (Residual fault) rate）

危险已检测故障率λ^f_DD指被组件内置的功能安全机制检测到的故障发生概率。需要注意的是，若此类故障未被检测到，安全机制显然无法触发其缓解策略，此时仍可导致一项或多项安全目标被违反（即残余故障），从而对组件使用者造成危害。

残余故障率（rf）定义为所有危险已检测故障率的总和，如公式 (2.3) 所示：

安全未检测故障（潜伏故障）率

安全未检测故障率λ^f_SU指未被组件内置的任何功能安全机制检测到（即潜伏），且无法单独导致一项或多项安全目标被违反的故障发生概率。不过，这类故障在FMEDA（失效模式、影响与诊断分析）中会被重点关注，因为一旦叠加一个或多个其他故障，其组合可能违反一项或多项安全目标，从而对组件使用者造成危害。

潜伏故障率（lf） 定义为所有安全未检测故障率的总和，如公式 (2.4) 所示：

安全已检测故障率

安全已检测故障率λ^f_SD指被组件内置的功能安全机制检测到，且无法单独导致一项或多项安全目标被违反的故障发生概率。其定义如公式 (2.5) 所示：

该比率不用于计失效指标。

2.7.3 失效指标

随机硬件失效指标：

单点故障指标：

潜伏故障指标：

ASIL 指标限值（表2.7）：

当计算出的指标满足表2.7中基于目标ASIL级别的rhf、spfm和lfm的需求时，硬件设计验证即告完成。

表2.7：随机硬件失效指标限制

2.8 FIDES

FIDES 2009指南用于计算随机硬件失效概率，单位FIT（1 FIT=1次/10⁹小时）。

2.8.1 指南结构

· 预测可靠性评估指南；

· 可靠性过程控制与审核指南。

2.8.2 定义

注意：FIDES术语与ISO 26262存在差异，本文统一使用ISO 26262词汇：

· 可靠性：产品在规定条件、规定时间完成规定功能的能力；

· 系统：完成运营角色的设备集合（汽车、飞机、计算机）；

· 子系统：系统内完成运营功能的设备集合（ABS、GPS）；

· 设备：完成完整功能的组件集合（ABS计算机、GPS屏幕）；

· 组件：装配后实现功能的单元（电阻、电容、PCB）；

· 产品：被研究可靠性的装配实体；

· 元件：不可拆分的可靠性研究基本单元（对应ISO 26262组件）。

失效原因、机理、模式、可靠性影响因子如图2.16。

图2.16：失效原因、机制、模式和可靠性贡献系数之间的关系

2.8.3 模型覆盖

FIDES考虑：

· 开发/制造错误引发的失效；

· 电/机械/热过应力（应用相关、未明确声明）；不考虑：

· 软件失效；

· 未确认失效；

· 未执行预防性维护导致的失效；

· 已确认的意外攻击（失效传播、超规格使用、误操作）。

2.8.4 可靠性预测

FIDES输出失效率λ，产品寿命分为三段（浴盆曲线，图2.17）：

1. 早期失效：可通过老化筛选规避；

2. 有效寿命：失效率近似恒定（随机失效）；

1. 耗损失效：失效率上升，需定期更换。

图2.17：浴管曲线，显示了产品寿命的三个阶段

FIDES仅评估有效寿命的随机失效。

2.8.5 预测可靠性评估输入

· 环境与使用条件：工作温度、温度循环幅值/频率、振动、湿度、污染、意外过应力；

· 产品定义：物料清单、元件技术参数；

· 应用信息：元件应力、局部温度/环境参数。

2.8.6 通用模型

通用模型（见公式2.9）在综合考虑物理因素与过程因素的基础上，计算组件的失效率。

λ 代表失效率，∑Physical contributions是一个以加法为主的构造项，包含了对可靠性产生影响的物理与技术因素；而 ∏Process contributions是一个乘法项，代表开发、生产和运行过程对可靠性的影响。

公式2.9可改写为：

其中：

· λPhysical：代表物理贡献（即基础物理失效率）

· ΠPM（PM为Part Manufacturing的缩写）：代表对组件制造环节的质量与技术控制水平

· ΠProcess：代表对包含该组件的产品在开发、制造及使用全流程中的质量与技术控制水平

2.8.7 寿命剖面（Life profile）

对FIDES指南的完整阐述超出了本论文的研究范畴。FIDES指南的核心概念是寿命剖面。

在为可靠性预测构建寿命剖面时，需要梳理在组件全生命周期内可能导致失效的各类因素。这需要采用工程化的可靠性分析方法，且对可靠性评估至关重要，因为它会显著影响预测的准确性。

FIDES 模型的设计对物理影响因素高度敏感。若在构建寿命剖面时选取偏高或偏严苛的取值以保持保守性，会大幅削弱结果的预测价值。安全工程师可将寿命剖面描述的详细程度与精度，限制在产品寿命可被预测的精度水平内。

寿命剖面的总体描述

第一步是从定性角度进行描述，需明确：

· 产品集成到系统中时所属平台的具体类型；

· （如适用）产品在平台中的安装位置；

· 所考虑的地理或气候区域；

· 产品的使用类型。

阶段划分（Choice of phases）

阶段的划分必须足够全面，以完整描述不同的使用场景。为便于理解复杂的寿命剖面，可对每个阶段标注：

· 清晰的阶段标题；

· 描述性段落。

当环境条件在应力层面发生显著变化时，必须重新定义一个新的阶段。目前尚无通用的阶段划分方法，通常可基于产品典型的单日使用场景开展分析。

阶段时长（Phase duration）

建议设计者构建总时长为1年（即8760小时）的寿命剖面。其目标是计算以日历FIT表示的失效率，这比使用“每运行小时”或“每任务小时”等其他单位更受推荐。阶段时长必须以小时为单位，尽可能真实地描述产品的活动状态。

由于失效率λ需以FIT（每10⁹小时1次失效）为单位，因此需要按每年的小时数对各阶段时长进行加权计算，如公式 (2.11) 所示：

适用域（Applicability domain）

适用域（即需要为每个阶段识别的物理影响因素）包括：

· 温度（及热电）应力；

· 温度循环；

· 湿度；

· 振动；

· 化学应力；

· 应用类型。

一般而言，可靠性预测仅适用于组件已通过认证的环境域。

2.9 故障注入

故障注入是评估系统故障敏感性的通用技术：刻意引入故障，观察系统响应。可用于：容错方案验证、可靠性验证、故障预测、容错等级评估。分为硬件故障注入与软件故障注入，软件故障注入用于评估缺陷（bug）对安全关键系统的影响。

2.10 FMEA与FMEDA区别

· FMEA：概念阶段开展，行为级预测失效，早期缓解措施；

· FMEDA：硬件设计阶段开展，评估硬件（+嵌入式软件）可靠性。

2.11 嵌入式系统软件开发

在 ISO 26262 框架下开发负责执行安全关键任务的软件，需要遵循其第6部分所描述的严格开发流程。

软件开发涉及的主要规范工作产物是配置管理计划。基于该计划，将编制一份软件安全需求规范文档。

一旦我们拿到后一份文档（软件安全需求规范），就需要编写一份软件验证计划，用以说明如何对软件进行测试；在软件实现并完成测试后，还需编制一份软件验证报告，作为已开展测试与验证活动的证明。这些文档之间的关系如图2.18所示。

图2.18：从配置管理计划到软件验证报告的WP之间的关

配置管理计划（CMP）的编制需综合考虑安全计划、组织特定的功能安全准则，以及生命周期各阶段的适用前提条件。

CMP明确了复现软件（SW）所需的工作产物：

·模型（和/或）源代码；

· 软件开发环境（含其配置）；

· 软件交付物（包括源代码与二进制文件）；

· 驱动程序；

· 操作系统；

· 各项开发活动的佐证材料。

聚焦于软件实现流程，除已提及的软件安全需求规范外，预期产出的工作产物还包括：软件架构设计规范、软硬件交互规范，以及针对架构中规划的每个软件单元，编制一份软件单元设计规范。这些文档之间的关系如图2.19所示。

图2.19：软件实施过程中准备的WP之间的关系

2.11.1 术语

· 组件（Component）：逻辑/技术可分离，包含多个硬件部分/软件单元；

· 硬件部分（HW part）：硬件组件一级分解单元（电阻、CPU）；

· 元件（Element）：系统、组件、硬件部分、软件单元；

· 嵌入式软件（Embedded SW）：运行在处理元件上的完整集成软件；

· 软件组件（Software Component (SWC)）：一个/多个软件单元组合；

· 软件单元（Software Unit）：可独立测试的最小软件组件。

2.11.2 V模型

软件开发通用流程（图2.20），左侧开发、右侧验证，闭环修复缺陷。

图2.20：软件开发的V图

2.11.3 基于模型的软件设计（MBSD）

用Simulink等工具建立软件单元与架构模型，仿真验证后自动生成C/C++代码，可与手写代码集成，加速开发、保证质量、简化测试。

2.11.4 软件单元测试

单元测试目标：消除系统性缺陷，覆盖：

· 语句覆盖：执行语句百分比；

· 分支覆盖：执行分支百分比；

· 修正条件/判定覆盖（MC/DC）：独立影响结果的条件百分比。

MIL：模型在环，仿真环境运行模型；

SIL：软件在环，对比模型与自动生成代码/手写代码；

PIL：处理器在环，目标硬件执行代码，验证工具链、测量最坏执行时间（WCET）。

2.11.5 软件集成测试

调试器：嵌入式系统无键盘屏幕，需外部调试器监控内存、变量、运行时；实时测试：硬实时系统必须按时序执行，需Trace工具测量运行时；硬件在环（HIL）：目标运行完整软件，实时机运行被控对象模型，电信号等效真实环境，“欺骗”控制器以为在真实世界（图2.21）。

图2.21:HIL概念结构与实际实现的比较，基于National Instruments cRIO作为实时模拟器和ZedBoard作为控制器

在该系列文的后续“第二部分”中，我们将重点解析基于仿真的FMEDA方法研究成果。请持续关注“猿力部落”公众号后续发布的该系列文章后续篇章。

免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系TechApe@yeah.net告知，我们会在第一时间做出处理。