做功能安全这几年我最大的感受是ISO 26262这个标准很多人在概念阶段讲得头头是道什么危害分析、ASIL评级、安全目标都能聊几句。但一旦进入产品开发过程真正能把活儿干明白的人立刻少了一大半。原因不复杂。概念阶段说到底是在“想清楚要保什么”而产品开发过程是在“把保命的东西造出来还得证明它真能保命”。后者涉及系统、硬件、软件三条线的并行推进每条线上都有必须交付的工件、必须达到的指标、必须遵守的方法。文档量巨大时间跨度长跨角色协作多任何一个环节脱节后面评审都会非常难看。这篇文章我就聚焦在ISO 26262标准的“产品开发过程”这一块把系统层面、硬件层面、软件层面到底要做什么、交付什么、怎么证明以及我踩过的一些坑一次讲透。1. 为什么产品开发过程才是功能安全的“主战场”1.1 标准在管什么从整体安全到技术落地的三级跳ISO 26262的标准全称是《道路车辆 功能安全》它覆盖的是车辆电子电气系统的整个安全生命周期。很多人只看概念阶段的HARA危害分析与风险评估觉得做完这个就算懂功能安全了这是大错特错的。HARA的输出是安全目标ASIL等级也是在这里定下来的但它本质上只是给整个开发过程定了“方向和难度”。真正实现安全目标靠的是产品开发阶段一步一个脚印做出来的系统设计、硬件设计、软件开发以及贯穿其中的验证、测试、评审。我习惯把ISO 26262的产品开发过程理解成一个三级跳第一跳是系统层面也就是标准里的Part 4。它要回答的问题是安全目标怎么转化为技术安全需求系统架构上怎么布置安全机制探测器、执行器、控制器各自承担什么安全职责系统集成之后怎么测试第二跳是硬件层面Part 5和软件层面Part 6。到了这里技术安全需求被进一步分解成硬件安全需求和软件安全需求硬件设计要算出失效率、诊断覆盖率软件设计要满足架构分层和单元测试覆盖率要求。第三跳是最后的生产和运维这部分虽然不在“产品开发过程”的狭义范围内但开发阶段的很多设计约束比如诊断的维护策略、软件刷写的要求都直接来自开发过程输出所以开发阶段必须想得足够远。这三跳是一个逐步细化的过程所有需求都有明确的来源和追溯关系不允许出现“拍脑袋设计”“做了再说”的情况。1.2 一个容易踩的误区把功能安全当成文档操作我见过不少团队一开始做功能安全特别亢奋表格建了一堆模板整理得比咨询公司还漂亮。但做着做着就会发现一个问题文档写得很好设计却完全对不上。举一个我实际遇到的例子系统设计文档里写了“当传感器信号异常时应在100ms内进入安全状态”硬件工程师却没有为这个100ms做任何预算分析。因为信号的采集周期是20ms软件处理周期又是20ms加上执行器的响应时间100ms根本不够用。评审的时候大家面对面坐着谁都没话说。这类问题的根源就是功能安全被当成了“文档操作”而不是“工程操作”。ISO 26262的每个交付物背后都对应着一个真实的工程活动。比如技术安全需求不是写作文它是系统设计的基础FMEDA不是填表它是硬件设计选型、降额设计的依据。做产品开发过程我建议每个团队都要树立一个基本意识每份文档背后必有一个设计决策每个设计决策一定要落到某份文档里。两者对不上开发过程就是失控的。这也解释了一个现象为什么功能安全做得好的企业开发流程本身也往往很规范。因为ISO 26262本质上是把一个“靠谱的工程过程”用标准化的语言刻画了出来。你不需要为了功能安全发明一套全新的流程你需要的是一次成熟度极高的开发管理能力。2. 系统层面开发把安全目标拆成能落地的技术需求2.1 从安全目标到技术安全概念拆需求的核心套路系统层面开发的输入是概念阶段产出的安全目标。比如某个转向系统的安全目标是“避免在行驶过程中发生非预期的助力丧失”ASIL等级是ASIL D。到了系统开发阶段我们要做的第一件事就是把这条安全目标转化成技术安全需求Technical Safety RequirementsTSR。技术安全需求的写法有几个硬性要求。首先它是技术语言不能停留在“助力不能失效”这种功能级描述而要明确到“控制器应能在10ms内检测到扭矩传感器信号无效并在50ms内转换至降级模式同时通过CAN向整车发出故障信息”。其次每个技术安全需求都要继承安全目标的ASIL等级并且在分配架构单元后这个ASIL等级可以随之分解、转移但最终必须被验证为“满足”。拆解需求时最容易犯的毛病是把“系统的外部行为”和“内部实现”混在一起。比如说系统设计文档里直接写“MCU应每10ms执行一次A/D采样”这就是典型的过度设计因为它约束了内部实现。正确做法是把这个需求定义为“扭矩传感器信号更新周期应不高于10ms从信号异常到系统识别异常的时间应不高于20ms”至于用A/D中断、DMA、还是软件轮询那是硬件与软件分配的事。需求定义阶段只管“要什么”不管“怎么做”。在需求拆解的方法上我强烈建议用层次化方法安全目标Safety Goal→ 技术安全需求TSR→ 系统设计导出需求。TSR可以分配到硬件也可以分配到软件甚至可以分配到系统外部接口。每个TSR都要有唯一的ID方便后续做追溯管理和变更管理。如果你用DOORS或Jama之类的需求管理工具这个ID体系从一开始就要定好不然后面维护起来会让人崩溃。2.2 系统架构、安全机制与集成测试为什么说“架构定生死”技术安全需求定下来之后接下来就是系统架构设计。系统架构在这里不只是画个框图它必须要能回答“安全机制放在哪里、怎么触发、故障如何传播”这些问题。ECU的系统架构一般包括传感器、控制器、执行器、通信总线、电源管理等多个要素。功能安全特别关注的是安全回路的设计。举个例子电机控制器的过流保护既可以在硬件上做比较器直接送驱动芯片的STOP引脚也可以在软件里通过ADC采样判断过流后关断PWM。两种方案的安全机制完全不同故障检测时间、覆盖率、避免共因失效的能力都不一样。系统架构师必须在设计阶段就明确每一种安全机制的原理、检测对象、检测方式、容错时间间隔FTTI、安全状态定义。这里引入一个概念叫FTTIFault Tolerant Time Interval容错时间间隔。通俗理解就是从故障发生到系统进入安全状态的“最晚允许时间”。FTTI不是一个拍脑袋定的数字它是由危害分析得出的。制动辅助系统可能要求FTTI在50ms以内而某些信息娱乐功能可能几百毫秒都可以接受。FTTI一旦确定系统架构里每个组件传感器、MCU、执行器的故障检测时间预算之和必须小于FTTI这个时间预算的分配要写进系统设计文档作为硬件和软件开发共同遵守的约束条件。系统集成测试是另一个容易在计划阶段被忽视、到了项目后期疯狂赶工的部分。集成测试的目的是验证系统层面的安全需求和软硬件协同工作是否满足设计要求。实际执行中需要明确的几点测试环境是HIL硬件在环还是台架、测试用例与系统需求的追溯关系、故障注入方式、判定的通过准则。以故障注入为例你要验证一个过压保护功能就得能模拟过压场景你要验证通信丢失后的降级策略就得能切断CAN信号。很多团队到后期才发现在台架上做故障注入极其困难因为硬线没有预留测试点通信报文又无法修改。这些都是系统架构阶段就该考虑到的可测试性设计问题。2.3 系统层面的交付物清单照着准备就不会漏第一次做系统层面开发的人最常问的问题是我到底要交什么。我列一个常用清单系统开发计划含功能安全活动安排技术安全需求规格书TSR系统设计规格书含系统架构、安全机制设计、FTTI分配系统集成测试计划系统集成测试报告功能安全确认报告包括车辆级/系统级的确认测试安全案例分析输入可能有专门的安全经理去汇总这些交付物并非做完就完了它们之间还有很强的追溯关系。我在项目管理中最看重的是两条追溯链一条是“安全目标→TSR→硬件/软件安全需求→测试用例”的正向追溯另一条是“测试失败→测试用例→需求→安全目标”的反向追溯。只要这两条追溯链清晰评审会上大概率不会出大问题。3. 硬件层面开发量化风险是硬功夫3.1 硬件安全需求与FMEDA失效率和诊断覆盖率怎么算硬件设计的核心交付物是硬件安全需求Hardware Safety RequirementsHSR它们来自TSR的硬件部分分配。HSR不仅要定义功能行为还要明确诊断措施、故障检测覆盖率、安全机制响应时间、硬件失效的概率指标等要求。硬件安全需求确定后接下来就是硬件设计。在这个阶段FMEDAFailure Modes, Effects and Diagnostic Analysis失效模式、影响和诊断分析是躲不开的关键活动。FMEDA的输出直接决定了硬件能否满足ASIL等级要求的安全指标。很多工程师第一次接触FMEDA会觉得头大表格列了几百行每个元器件都要分析。我把它简化一下FMEDA其实就是对每个硬件元器件回答四个问题。第一这个器件有哪些失效模式比如电阻就有开路、短路、漂移三种常见模式。第二每种失效模式会造成什么影响是导致安全机制失效还是被安全机制覆盖第三系统是否能检测到这个失效如果能诊断覆盖率是多少第四按照失效率数据库这个器件的基础失效率是多少故障率乘以未被诊断覆盖的比例就是单点故障贡献。FMEDA的基础失效率数据来源也有讲究常见的有IEC TR 62380、SN 29500、IEC 61709等手册。不同手册给出的数值差异可能很大所以我在项目里通常固定采用一本手册并在FMEDA报告里明确写明数据来源和选择理由避免评审时被人质疑。3.2 硬件安全指标SPFM、LFM、PMHF一次说清FMEDA算完之后值不值得信就看几个关键指标SPFM单点故障指标、LFM潜伏故障指标、PMHF随机硬件失效概率指标。SPFM衡量的是“单点故障”被安全机制覆盖的比率。单点故障是指一个故障直接导致安全目标违背并且没有安全机制兜底的故障。SPFM越高说明单点故障被处理得越好。ISO 26262对不同ASIL等级有量化要求例如ASIL D的单点故障指标要大于等于99%ASIL B要大于等于90%。LFM衡量的是潜伏故障的覆盖情况。潜伏故障是指故障本身不立即导致安全目标违背但它会导致另一个故障发生时的安全机制失效。这类故障最阴险因为不坏则已一坏就是双重失效。PMHF则是一个时间维度的指标单位是Fit表示每十亿小时的平均失效概率。ASIL D一般要求小于10 Fit。这三个指标的计算都不复杂难的是收集数据的过程需要硬件设计工程师、可靠性工程师、功能安全经理三方共同参与反复迭代。FMEDA的表格在早期一定是不完整的不要指望一次就做完我建议按“原理图评审→FMEDA初版→配合诊断设计定稿”的节奏推进。3.3 硬件测试从元器件级到电路板级硬件设计完成后验证测试不能漏。硬件测试包括元器件级、电路板级和系统集成级。电路板级测试要特别关注安全机制的故障注入测试比如通过外部强制拉高某个引脚来模拟短路故障或者断掉某个电源轨来观察诊断逻辑是否按设计触发。这里的实操经验是在做硬件评审时就要和硬件工程师确认每个故障注入点的可访问性。如果MCU引脚不足、测试点没引出来后面故障注入只能靠飞线效率极低。尤其在一些高密度Layout的板子上飞线找信号简直是噩梦。提前在硬件需求里加入“测试性设计”要求比如为关键安全链路预留测试接口是最划算的投入。4. 软件层面开发ISO 26262-6的那些细节4.1 软件安全需求与架构设计分层是你最好的朋友软件开发对应的标准部分是ISO 26262-6这也是嵌入式软件工程师最关心的章节。软件层面的起点是软件安全需求它同样来自TSR的软件部分分配。软件安全需求要按功能拆分比如安全状态控制、故障诊断、故障记忆、降级策略等每一条都要有明确的ASIL属性。软件架构设计是这里我最想强调的部分。根据标准要求软件架构应该采用分层的结构设计。分层的好处非常明显一是有利于把安全相关功能和非安全相关功能进行隔离避免非安全模块的故障影响安全功能二是有利于需求追溯和测试每一层的职责边界清晰三是有利于复用尤其对在多个车型项目上使用同一套基础软件的组织来说分层设计能大幅减少重复验证成本。受ASIL等级影响的是同一ECU内安全相关软件和非安全相关软件的关系。硬件上不支持足够资源隔离时软件层面要考虑“自由从干扰”分析FFIFreedom From Interference。这是什么意思呢比如非安全相关的功能霸占了CPU导致安全相关任务无法按时执行或者篡改了共享内存里的安全标志这类干扰必须被分析并排除。处理手段包括内存保护MPU、资源预算分配、任务优先级设计等。很多软件问题排查到最后才发现是低安全等级模块引发的内存踩踏把高安全等级模块的数据破坏了这在ISO 26262里是明确不被允许的。4.2 软件单元测试与集成测试别让覆盖率变成形式主义软件单元测试是最花时间、也最容易被糊弄的环节。标准对不同ASIL等级提出了不同的覆盖率要求语句覆盖率、分支覆盖率、MC/DC覆盖率修正条件判定覆盖Modified Condition/Decision Coverage。ASIL D要求MC/DC覆盖率这是最严格的等级。我在实际项目里发现覆盖率工具跑出来的“绿色100%”并不等于测试有效。MC/DC的要求不是“每个条件真/假都出现一次”而是要求“每个条件都能独立地影响判定结果”。这句话翻译成人话就是你要证明一个条件改变时整个判断式的结果确实会改变。仅仅让每个条件都出现过True和False但判定结果始终不变是不满足MC/DC要求的。被测软件里特别容易出问题的就是那些“短路的与或逻辑”和带副作用的函数测试用例设计必须围绕这些场景打。软件集成测试时还有一个经常被忽略的点编译器和链接选项、内存映射、启动代码这些运行时环境在单元测试中通常不会验证但很多故障恰恰发生在真实环境与测试环境不一致的地方。所以集成测试的通过不能拿来弥补单元测试的缺失两者各有各的目标不能互相替代。4.3 软件验证方法速查哪些方法对应什么安全等级为了帮大家快速定位标准对软件验证方法的要求我整理了一个精简版速查表。注意标准允许一些方法根据ASIL等级被“强烈推荐”“推荐”或“不推荐”实际项目中以项目安全计划为准。验证活动ASIL BASIL D说明语句覆盖率推荐强烈推荐每个可执行语句至少执行一次分支覆盖率推荐强烈推荐每个分支的真假都被覆盖MC/DC覆盖率不要求强烈推荐ASIL D的硬门槛需求追溯测试强烈推荐强烈推荐每条安全需求对应到测试用例静态代码分析推荐强烈推荐MISRA C等规则集有一点要提醒覆盖率只是验证充分性的必要条件不是充分条件。就算覆盖率100%也不能说明软件正确因为测试数据的正确性、运行环境的真实性仍然取决于测试设计。覆盖率是“便于证明”的手段不是“为了好看”的数字。5. 贯穿整个开发过程的安全活动5.1 ASIL分解与相关失效分析处理复杂度的关键手段ASIL分解是ISO 26262里一个极具工程价值的概念。它的核心思想是一个ASIL D的需求可以通过冗余设计分解为两个独立的ASIL B(D)需求其中括号里的D表示这个需求的“父级”ASIL等级。举个常见的例子制动系统的一致性校验功能可以分解为“主路径计算制动扭矩满足ASIL B(D)”和“监控路径校验制动扭矩合理性满足ASIL B(D)”。两个路径独立开发、独立实现最终只要两者同时失效的概率足够低就能满足ASIL D的安全目标。ASIL分解最大的价值在于降低开发成本。毕竟ASIL D的开发流程、测试要求、独立性要求都比ASIL B苛刻得多。但这里有个前提两个分解后的路径必须满足独立性和充分性要求否则分解无效。评审时审核员一定会关注两条路径之间是否存在共因失效。为了排查共因失效就要做DFADependent Failure Analysis相关失效分析。DFA主要分析两类问题一是共同原因失效比如两个冗余路径的芯片来自同一批次、共用同一路电源、PCB布线靠在一起二是级联失效比如路径A的失效导致路径B也失效。DFA的输出是设计改进措施的清单比如隔离电源、分布布线、不同批次物料采购、独立的时钟源等。我在项目中建议把DFA和FMEDA联动起来看因为很多FMEDA里被认为是“安全机制覆盖”的故障放在DFA视角下可能就是共因失效的“漏网之鱼”。5.2 安全计划、安全案例与独立评审让安全不只是口号产品开发过程中有几个贯穿性活动容易被项目经理当成“流程负担”安全计划、安全案例、独立评审。安全计划是整个功能安全活动的纲领性文件。它要定义清楚范围、角色与职责、开发活动时间表、交付物清单、评审计划、验证计划、标准剪裁说明如果对ISO 26262进行了剪裁。我个人强烈建议安全计划和项目开发主计划同步制定不然等项目大纲定了再补安全计划很多安全活动的时间根本排不进去。安全案例则是在项目开发过程中持续积累、最终汇总的安全论证。它的形式可以多样但核心是提供一个清晰的安全论据从安全目标出发逐层论证到需求、设计、测试结果最终得出“系统是安全的”这个结论。很多工程师觉得安全案例是最后拼凑出来的文档这种想法很危险。正确做法是每个阶段结束时就把该阶段的安全论证片段写进安全案例最后汇总时只是“拼图”不是“编故事”。独立评审的目的是确保安全活动不被项目进度压力绑架。ISO 26262要求独立于设计团队的人员或组织对安全活动进行评审。独立性的等级取决于ASIL等级ASIL D往往要求最高级别的独立性。实操上独立评审不只是“看一下文档有没有错别字”而是要去看技术方案是否满足安全目标、测试结果是否支持安全声明、遗留问题是否被合理处理。我自己的体会是独立评审最好邀请有实际产品经验的人来做而不是让一个完全不懂技术的“流程专家”对着检查表打钩。真正有价值的评审意见永远是“你这里的安全机制覆盖率计算有遗漏”“你这条需求的时间约束在系统架构里没被满足”这类技术性的发现。6. 实操中的常见问题与经验教训6.1 交付物与计划完整的项目计划怎么排这是我每次和新手团队沟通时都要讲的一件事功能安全的产品开发计划中排第一位的不是设计任务而是安全交付物的评审时间。以我经历的一个控制器项目为例从TSC技术安全概念到量产的周期大概18个月其中安全相关的交付物就有几十项。如果不提前梳理清楚中间任何一个评审延期都会导致后续开发活动连锁延期。我建议在项目启动时的安全计划里至少包含这样一张核心交付物与时间表。阶段核心交付物建议最早启动时间概念HARA报告、安全目标项目启动即启动系统TSR、系统设计、集成测试计划TSC前完成需求初稿硬件HSR、FMEDA、硬件测试报告原理图设计阶段同步开始FMEDA软件软件安全需求、架构方案硬件方案冻结前启动验证确认报告、安全案例项目启动即持续积累特别注意FMEDA的启动时间。很多硬件工程师觉得FMEDA是硬件设计完成后的事其实这个想法会害死人。原因在于FMEDA的结果直接决定了你芯片选型是否够“硬”你的安全机制覆盖是否能达到指标你的诊断电路是否有必要增加。等PCB都画完再发现SPFM指标不达标改板成本和进度损失都是巨大的。我的经验是在原理图设计的第一版就同步做FMEDA的初版然后跟着设计迭代更新。6.2 工具链与流程工具置信度和开发流程的匹配软件工具认证是另一个特别容易被低估的工作。ISO 26262-8中有一个概念叫“工具置信度”Tool Confidence LevelTCL它由两个因素决定工具是否可能违反或未能检测到安全需求以及工具本身出错后是否能被发现。工具置信度的结果决定了你要不要做工具鉴定Tool Qualification。比如你用的代码生成工具它可以被配置为自动生成生产代码如果出错可能导致安全目标被违反且不易察觉这种情况下工具置信度会很高通常需要做工具鉴定。反过来一个静态代码分析工具如果只是“可能发现错误”但不会引入错误置信度就低一些。实际项目中我见过不少团队因为忽视工具鉴定在功能安全审查时被开严重不符合项。解决这个问题没有捷径只能提前梳理软件工具链识别每个工具的功能和潜在风险评估TCL再制定相应的鉴定措施。常用的做法包括对比测试用工具输出与已知正确结果做比对、增加额外的验证步骤、使用已有经验数据等。6.3 需求追溯与变更管理最容易失控的环节产品开发到了中后期需求变更是常态而功能安全最怕的恰恰是“不追溯的变更”。研发过程中最常见的失控场景是一个CAN报文信号定义变动了软件改了硬件和测试团队不知道结果安全机制因为报文格式不对没触发测试还测不出来。需求追溯矩阵是解决这个问题的核心工具。每一份TSR、HSR、软件安全需求都要能追溯到来源和去向。来源可能是安全目标、系统需求、客户需求去向可能是设计实现、测试用例、验证结果。任何一行发生变更都要评估它对上下游的影响范围这就是变更管理的闭环。实操中我推荐在项目早期就建立需求/测试的BIEBoth In Effect双向追溯。虽然这会增加一些前期工作量但它带来的收益非常明显任何一条需求发生变化影响分析可以在几分钟内完成而不是开两小时的会议还扯不清。另外每次变更都要把这个变更的影响重新发回给安全经理由他判断是否需要重新评估FMEDA或者DFA。不要怕变更怕的是变完之后没人知道变了。6.4 技术细节上容易被挑战的点最后分享几个评审中经常暴露问题的技术细节。第一个是看门狗Watchdog的设计。很多人都知道要“喂狗”但功能安全视角下真正重要的是看门狗过期之后系统要进入哪个安全状态以及这个看门狗是否独立于被监控的MCU。软件看门狗和硬件看门狗、片上狗和片外狗安全等级和理解都不同。如果你的MCU本身因为时钟故障跑飞片内看门狗可能也同样失效这就是需要额外设计独立硬件安全机制的原因。第二个是RAM与Flash的测试。RAM自检如March C算法、Flash自检CRC校验是ASIL C/D项目中必须明确覆盖的内容。具体检测周期、覆盖率、检测时机上电自检还是运行周期检测都要在FSR/TSR里写清楚。很多团队只在启动时做一次RAM测试运行时完全不覆盖对于高安全等级系统来说这通常是不够的。第三个是通信协议的余度校验。车载CAN通信很容易受电磁干扰产生位错误因此安全相关的信号一般要用CRC、滚动计数器、超时监控等机制来实现通信层面的故障检测。这些机制的参数如CRC多项式的选择、计数器翻转位宽、超时阈值都应有明确的推导依据而不是随便抄个参考设计。第四个是系统状态机的设计。安全状态、降级状态、故障状态之间的切换逻辑必须明确每个状态下允许执行的动作、禁止执行的动作以及状态切换的触发条件和时间约束。状态机设计不合理会导致系统在进入安全状态后又被错误地唤醒或退出这是很危险的事情。写在最后做功能安全产品开发这几年回头看最大的心得反而是ISO 26262的确不容易但它给工程带来的秩序感和可预见性是扎扎实实的价值。每一次评审表面上在审查文档本质上是在审查一个团队的工程思维是否闭环、设计能力是否过硬、流程纪律是否可依赖。如果你正准备启动一个功能安全项目我的建议很简单不要从“写文档”开始而是从“想清楚设计”开始。文档是设计过程的结果不是设计本身。把系统架构、安全机制、FTTI、覆盖率、诊断这些技术问题先一个一个掰扯明白了文档自然写得出来。反过来拿着模板硬套写出来的只能是废纸。另外提醒一句功能安全的落地没有“万能模板”。项目不同、平台不同、团队不同具体的剪裁和实施方案一定会有差异。本文提到的方法和清单是我在具体项目中的实践总结可以作为参考基线但真正落地时还是要基于自己的产品特点做适配。毕竟标准是死的工程是活的能解决问题的方案才是好方案。