ISO 26262功能安全实战：从HARA到ASIL分解与软硬件落地
简介这份PDF文档是一份ISO 26262汽车功能安全标准的详细解析与实践指南面向汽车功能安全工程师、项目经理以及具备电子电气和软件开发基础的研发人员尤其适合对功能安全有初步了解、希望系统掌握标准应用方法的读者。资源共1个PDF文件压缩包约4.87MB内容结构紧凑目前已有473人学习。文档按功能安全开发流程展开系统讲解概念阶段的HARA分析、FSR/FSC定义系统阶段的TSR/TSC开发以及软件、硬件阶段的详细方法同时覆盖功能安全管理、外部措施、安全确认等关键环节并详细说明安全分析方法、功能安全需求定义、安全机制设计和概率化度量。文中结合大量真实案例深入浅出地解释各阶段关键概念并提供操作步骤与工具使用建议可帮助读者在产品从概念到生产的全生命周期中有效落实功能安全要求快速上手实际项目。 刚接触汽车电子功能安全的人十有八九会在 ISO 26262 面前有点懵。这个标准不像一份普通技术手册那样告诉你电路怎么画、代码怎么写它更像是一整套贯穿产品生命周期的管理框架用大量流程、文档、分析和验证活动回答一个终极问题你怎么证明你的产品在失效的时候不会把人置于不可接受的风险中。我最早系统接触 ISO 26262是在做一款电动助力转向系统的安全评审。当时最大的感触是这标准不只是一本规范而是每个环节都要有意识去落地的工程方法。如果只是把条款读一遍跟实际项目对照不上后面审计基本是灾难。这篇文章我结合自己参与过的项目经验把 ISO 26262 的标准结构、ASIL 分解逻辑、安全需求追踪、软硬件安全分析、工具链建设以及常见的踩坑场景完整梳理一遍。不论你是刚开始接触功能安全的新人还是在项目里正为某个安全活动头疼的工程师这篇文章应该都能让你少走点弯路。1. ISO 26262 到底是什么标准全景与核心概念1.1 从 IEC 61508 到 ISO 26262 的演进逻辑ISO 26262 并不是凭空冒出来的标准。它的底层思想源自 IEC 61508那是工业领域通用的电气电子可编程系统功能安全标准。但 IEC 61508 覆盖的面太宽从工业控制、医疗设备、轨道交通到核电系统都能用针对汽车电子电气系统时很多条款不够具体操作起来非常别扭。所以汽车行业在 IEC 61508 的基础上结合整车开发的特点搞出了自己的专用标准也就是 ISO 26262。和通用标准相比它更贴合汽车产品开发的实际情况整车厂和零部件供应商之间的分工关系、平台化开发模式、短周期迭代压力、供应链的逐级释放等等都在标准里有对应安排。标准版本方面2011 年发布了第一版2018 年发布第二版2022 年还出过修正版。第二版最大的变化是把半导体器件单独拎出来做了个 Part 11又增加了摩托车内容作为 Part 12。这些变化背后其实是行业实践的反哺2018 版出来前很多团队已经在芯片层面做了大量安全分析但标准里没有明确的指导大家的做法五花八门审计时对不上。1.2 12 个 Part 各自管什么ISO 26262:2018 一共 12 个部分结构上看起来很长但你不用每一行都背关键是理解每个部分解决什么问题。Part内容核心作用Part 1术语统一词汇沟通基础Part 2功能安全管理组织级安全流程、项目安全计划Part 3概念阶段相关项定义、HARA、安全目标Part 4系统级开发系统架构、安全需求的分配与集成Part 5硬件级开发硬件设计、FMEDA、硬件失效率Part 6软件级开发软件架构、单元设计、代码与测试Part 7生产与运营生产、维护、报废阶段的安全Part 8支持过程需求管理、配置管理、变更管理、验证等Part 9ASIL 与安全导向分析ASIL 分解、FTA、依赖性失效分析Part 10ISO 26262 指南非规范性解读帮助理解意图Part 11半导体应用指南芯片级安全设计方法Part 12摩托车适用性针对摩托车的裁剪和调整做项目的时候我习惯先把 Part 3、Part 4、Part 5、Part 6 这四个部分的核心条款吃透因为它们是实际开发中最常打交道的。Part 2 和 Part 8 则对应到项目管理和支持流程审计时也跑不掉。Part 11 只有在做芯片或使用复杂半导体器件时才需要深入。1.3 功能安全的核心逻辑残余风险与 ASIL功能安全追求的从来不是零事故这在工程上做不到也没有意义。真正的目标是把残余风险降到社会可接受的水平。ASILAutomotive Safety Integrity Level就是这个可接受门槛的量化表达。ASIL 分为 A、B、C、D 四个等级D 是最严格的。等级越高意味着系统失效导致的后果越严重随之而来的开发要求也越高。此外还有 QM 等级表示不必按功能安全流程开发用常规质量管理流程保证质量即可。注意ASIL 并不是给整个系统打一个总分的而是针对每一个具体的危害事件分配一个等级。同一个系统里可能有 A 级的子功能也可能有 D 级的子功能开发时分开对待。这个差别后续会直接影响硬件失效率目标和软件验证方法的严格程度。2. 概念阶段HARA、安全目标与 ASIL 分析2.1 HARA 到底怎么操作HARA 的全称是 Hazard Analysis and Risk Assessment危害分析与风险评估是整个功能安全工作的源头。如果 HARA 做偏了后面所有安全需求都会跟着偏所以这里是整个项目中争议最多、开会最多的阶段。标准的 HARA 流程大致分四步。第一步明确相关项的功能定义比如电动助力转向系统根据驾驶员输入产生助力扭矩。第二步识别运行场景包括高速、低速、停车、雨雪天气、隧道等不同工况以及驾驶员可能的操作。第三步是核心分析功能失效或异常时会造成什么危害事件。举个例子如果 EPS 系统在驾驶员没有转动方向盘时突然输出一个非预期的助力扭矩危害事件就是车辆非预期转向可能导致的伤害就是车辆跑偏、撞到路边行人或障碍物。第四步从三个维度打分严重度 S评估伤害程度S0 是无伤害S1 是轻伤S2 是重伤可能危及生命S3 是危及生命或致命。暴露概率 E评估发生这个场景的频率E0 到 E4E4 是几乎每天都有。可控性 C评估驾驶员能否通过操控避免事故C1 是通常可控C2 是大概 90% 以上的人或多或少先少能应对C3 是难以控制。三个维度组合查表就能得出 ASIL 等级。下表是我项目里常用的简化版本严重度暴露率可控性ASILS1E1C1QMS1E4C2AS2E4C2BS3E3C3CS3E4C3D打分的时候团队里经常要吵很久。比如高速上 EPS 非预期转向这个场景S 给 S3 基本没争议但 E 到底是 E2 还是 E3取决于你定义的系统边界和使用场景。实际上没有绝对的对错关键是记录打分依据让评审时可以追溯。2.2 安全目标与功能安全概念的分解HARA 做完之后对于每一个 ASIL 等级不为 QM 的危害事件都要定义一条安全目标。安全目标是一句顶层安全要求描述系统应当避免什么危害并且要分配 ASIL 等级。比如 EPS 系统的安全目标可以写成避免在驾驶员未请求转向干预时产生非预期转向扭矩ASIL D。在助力扭矩失效时保持转向可控避免突然失去助力ASIL C。两条安全目标等级不同意味着这两个失效模式对系统安全的影响不同。设计时对高等级目标要投入更多的安全机制和验证资源。功能安全概念就是把这些安全目标转化为一系列功能层面的安全需求比如当检测到扭矩传感器信号异常时系统在 100ms 内进入降级模式停止输出助力并点亮警示灯。注意这里说的是功能层面的动作不涉及具体硬件和软件架构硬件和软件的安全需求要在系统设计阶段继续细化。2.3 ASIL 等级对开发过程的直接影响ASIL 等级不是贴个标签就完事了它直接影响开发全过程。硬件上ASIL 等级直接决定安全目标的失效率目标比如 ASIL D 的失效目标通常要求低于 10 FIT。这里补充一下FIT 指的是 Failures In Time1 FIT 等于 10 的负 9 次方每小时。也就是说一个 ASIL D 的系统级安全目标要实现平均十亿小时才允许一个随机硬件故障。这个数字单靠元器件本身的高可靠性很难实现必须通过诊断机制、冗余设计等手段来达成。软件上ASIL 等级决定了编码规范要求、静态分析要求、测试方法组合和覆盖率要求。比如 ASIL D 的软件通常强制要求 MISRA C 等编码规范做 100% 的需求覆盖率还要做 MC/DC 覆盖率分析。ASIL A 则相对灵活很多严格的验证手段可以选择性使用。流程上ASIL 等级还影响过程文档的裁剪程度。等级越高评审的层级越高、文档的粒度越细。我这里有个实用建议项目启动时就按最高 ASIL 等级来制定流程模板后续再根据不同模块的等级裁剪比中途不断加严格度要省事得多。中途加严意味着你要回头补很多文档和分析记录非常被动。3. 从安全需求到软硬件落地3.1 安全需求链的建立与追溯从安全目标往下安全需求链会经历一层一层的细化安全目标 - 功能安全需求 - 技术安全需求 - 硬件安全需求 / 软件安全需求。这条链必须完整、可追溯、可验证。需求追溯在实际项目中做得好的不多。我见过不少项目需求管理工具里有一条安全目标但往下追踪到软件需求时发现某个需求的来源是空的也就是说底层有人写了实现但没人说清楚它到底满足哪条安全目标。这种情况在安全审计时属于严重不符合项。实操层面我用过 Polarion 和 IBM DOORS 做需求管理但说实话工具不是关键关键是需求粒度。安全需求写得太大比如系统必须安全无法验证写得太小比如定了某个电阻用什么封装又失去了安全需求的控制意义。我建议技术安全需求的粒度以能被测试验证为准每条需求必须能写出一条明确的验证标准。3.2 硬件安全分析失效率、FMEDA 与安全机制硬件安全分析是 ISO 26262 实务里技术含量最高的一部分。核心工具是 FMEDAFailure Modes, Effects and Diagnostic Analysis。它是在传统 FMEA 的基础上叠加了诊断维度针对每个硬件失效模式分析它是否会被系统内的诊断机制检测并处理。FMEDA 的输出结果主要是一张表列出每个器件的每种失效模式、失效率、诊断覆盖率、是否 Safe Fault、是否算单点故障等。最后汇总计算出单点故障度量SPFM、潜在故障度量LFM和随机硬件失效概率目标PMHF。做 FMEDA 最容易踩的坑是失效率数据来源不统一。有的数据来自 SN 29500、有的来自 IEC TR 62380、有的来自供应商实测各系数据的基准条件不一样混用会导致最终计算结果缺乏说服力。我建议统一采用一个标准库并且记录版本。另一点是需求里的诊断机制要真正落到硬件设计里否则 FMEDA 里算出来的覆盖率就是纸上谈兵。以 EPS 系统为例扭矩传感器的调理电路里如果有直流偏置故障如何诊断通常做法是软件周期性地读传感器输出如果信号超出合理范围就在一定时间内检测到并进入安全状态。这个检测逻辑会在 FMEDA 里体现为一条诊断措施并计算对应的诊断覆盖率。3.3 软件安全架构与自由干扰分区与隔离设计软件部分ISO 26262-6 要求软件架构设计满足安全需求并且要防止不安全模块干扰安全模块。这个干扰指的是时序、内存、通信等资源上的冲突。比如一个 QM 级别的娱乐系统模块如果内存溢出后把安全相关的制动控制数据覆盖了那后果不堪设想。处理这个问题有两条路线。第一条是让所有模块都按最高 ASIL 等级开发简单但成本巨大第二条是采用分区隔离把不同 ASIL 等级的模块在软件层面隔离开这样低等级模块出问题也不会扩散到高等级模块。这几年比较热的方案是用系统虚拟化技术做隔离。思路是把不同安全等级的软件模块放到独立的虚拟机或轻量级分区中运行通过 Hypervisor 统一管理 CPU 时间片、内存区域和外设访问。这就要求底层 CPU 要有虚拟化扩展支持就像电脑要开启 CPU 虚拟化功能才能跑虚拟机一样。用虚拟化隔离的好处是每个分区的故障被限制在自身范围内不容易造成跨模块干扰。我参与过的一个项目就在一个多核 MCU 上跑了两个分区一个分区跑 A 等级的控制逻辑一个分区跑 QM 等级的监控和交互功能。分区间的通信走受保护的共享内存和消息队列访问权限由 Hypervisor 强制管理。调试阶段最大的问题是 CPU 虚拟化对实时性的影响必须仔细分配时间片并做最坏情况执行时间分析否则中断响应时间会失控。4. 流程建设与工具资质4.1 工具鉴定与置信度等级做功能安全开发不可能不依赖工具。编译器、静态分析工具、测试工具、模型检查工具等等都会出现在开发链路上。但问题来了这些工具本身也可能有 bug你怎么证明工具输出的结果是可信的ISO 26262 的处理方式是工具置信度等级Tool Confidence LevelTCL。简单说工具的分类要回答两个问题工具是否有可能引入错误以及工具能否检测出目标系统中的错误比如编译器。编译器若是有 bug可能生成错误的目标代码而且这个错误不会被工具自身发现那它的置信度要求就很高。通常做法是对编译器做工具鉴定收集用的不是这个编译器经过了充分测试的自证材料而是针对你的具体应用场景做大量的背靠背比对测试。实操中工具鉴定非常耗时。我建议项目立项初期就梳理工具清单评估哪些工具输出直接影响安全活动哪些只是辅助从而确定需要达到的 TCL。不要等到项目后期才想起来编译器没有认证那会非常被动。4.2 工作产物与流程审计流程审计是很多团队最头疼的部分。ISO 26262 对每个开发阶段都规定了产出物比如安全计划、HARA 报告、安全目标、功能安全需求、硬件安全分析报告、软件单元测试报告、安全案例等等。每一项缺了审计师就能开一个不符合项。但注意标准并不要求文档无限冗长而是要求充分。审计的核心逻辑是你能不能证明你做了该做的事而且做得对只要能通过评审记录、测试报告、分析文档来证明具体用什么模板并不是死板的。我有一个经验把工作产物模板化、字段标准化。比如 HARA 报告里哪些栏位必填、评估依据写哪里、版本号怎么管一开始就定死。这样做的好处是项目加速时不会出现格式混乱审计时也能快速检索到关键内容。4.3 敏捷开发与功能安全的融合第二版 ISO 26262 相比第一版一个重要的进步是对开发过程模型不再强制瀑布式而是允许团队用迭代和增量开发。这意味着敏捷开发可以和功能安全流程共存。实际操作中我会在每个冲刺灵期间明确安全相关任务比如某个功能的安全分析需要在迭代内完成测试覆盖率要达到什么水平。同时将安全活动的评审作为迭代验收的一部分。这样虽然增加了不少工作量但换来的是功能安全不再游离于开发之外而是成为迭代的自然组成部分。这里有一个实际教训不要把安全活动一条条排在迭代结束时集中做。那样做的问题在于进度压力会让这些活动变成走过场。比如评审变成随便找几个人签个字HARA 的场景讨论变成拍脑袋打分。功能安全一旦形式化比不做还危险因为你会误以为系统是安全的。5. 常见问题与踩坑实录5.1 常见问题速查表做功能安全项目时我整理过一份常见问题的速查表这里分享给大家。常见问题可能原因解决建议HARA 场景评审永远吵不完场景边界不清晰缺少统一的场景库建立标准场景库基于数据/法规/经验定义场景需求追溯链断裂需求管理只做了文档存储没有做链接用需求管理工具维护层级链接并在评审时抽查FMEDA 失效率数字对不上数据源混用基准条件不一致统一使用一个失效数据库注明版本工具鉴定结果审计不通过没有收集使用场景证据只提交了工具手册基于目标应用做背靠背测试留存过程记录敏捷迭代安全活动被跳过安全任务没有进迭代计划将安全检查设为 Definition of Done 的一部分安全机制被后期优化掉硬件资源不够时最先被砍安全机制作为硬性约束变更走安全评审5.2 三个典型踩坑场景踩坑一HARA 阶段场景定义太粗。我们之前做 BMS 时把充电过程中电池过温定义为一个场景评估出来是 ASIL C。但后来细化后发现充电场景还得分快充、慢充、冬季冷启动充电用户操作也不一样。细化后的危害事件中有一个因为冷却系统失效导致的热失控场景严重度直接升到 S3最终安全目标提到 ASIL D。如果一开始不细化开发过程中安全目标的等级就定低了后面整个设计都要推翻。踩坑二需求追溯链在工具迁移时断了。我们有一段时间从 DOORS 迁移到新的需求管理平台迁移脚本只搬了文字描述把链接关系弄丢了。审计前检查时发现技术安全需求往下到软件需求有好几条追溯是空的。这种情况只能翻旧文档人工补链特别痛苦。后续项目里我在每次迁移后都会跑一个自动化的追溯完整性检查确保从安全目标到测试用例整条链是通的。踩坑三FMEDA 计算了漂亮的覆盖率但对应的诊断措施根本没有实现。有一款控制器FMEDA 里写明当电源电压超过阈值时由硬件比较器触发故障信号规定了 99% 的诊断覆盖率。实际开发时设计团队为了节省物料清单成本把这个比较器芯片去掉了而软件里也没有做对应逻辑。问题是 FMEDA 是安全团队的输出硬件 BOM 的变更没有同步给团队直到审计师验证时才发现。从这个教训后我把安全机制列成了一个独立清单每个机制对应到原理图位号或代码模块任何变更都必须走安全影响评审。5.3 审计前自查清单功能安全审计前我喜欢用一张自查清单来快速评估项目状态安全计划是否更新到当前项目阶段HARA 是否基于最新版系统定义每条安全目标是否都有向下分解的需求每个安全需求是否都有验证记录硬件 FMEDA 是否反映了最新原理图软件测试是否达到要求的覆盖率工具鉴定记录是否齐全变更管理记录是否完整变更影响分析是否做了安全评估这张清单如果每一项都能打勾审计大概率能过。任何一项是No建议推迟审计先把问题闭环否则去了大概率是开一堆不符合项回来。6. 写在最后一点个人体会说实话ISO 26262 学起来枯燥用起来繁琐但它最大的价值不是让你多了一堆文档要写而是逼着你在开发的每个环节去想如果这里出了问题会怎样。这个如果的问题问得越早代价越小问得越晚事故概率越大。我现在的习惯是拿到一个新的功能需求第一反应不是想怎么实现而是先做危害分析如果这个功能错误执行了会怎样如果它该执行时没执行呢如果它执行了一半被中断呢把这些问题想清楚再回到实现层面很多架构决策就自然清晰了。最后再分享一个建议功能安全不是一个人或者一个部门的事。它需要硬件工程师、软件工程师、系统工程师和安全工程师坐在一起围绕同一个分析结果打配合。把安全活动做成跨部门协作而不是安全团队闭门造车这是我踩过不少坑之后最想说的一点。本文还有配套的精品资源点击获取
