★ FEATURED ARTICLE 简介《ISO 26262-1-2018 道路车辆功能安全 第1部分术语》中文版PDF是针对道路车辆电气/电子系统功能安全的基础性标准文件基于IEC 61508改编面向汽车行业及电气、软件、功能安全相关研发人员。内容系统定义了安全生命周期、汽车安全完整性等级ASIL、危害、风险、安全目标等关键术语并覆盖从概念设计到生产、运行、服务及报废全流程的安全活动可帮助读者建立统一术语体系降低系统失效与随机硬件失效风险。资源为单个PDF文件大小仅632KB便于下载与离线阅读目前已有1355人学习下载。该中文版特别梳理了2018版相比2011版的主要变化包括卡车、巴士、挂车及摩托车要求网络安全考量半导体指南基于模型的开发指导硬件架构指标更新等便于把握新版标准要点。建议具备基础汽车与电气知识的读者结合英文原版对照学习以深入理解功能安全术语的准确含义。1. 为什么功能安全从业者都该有一份ISO 26262-1:2018术语中文版先过术语关再谈合规做功能安全这行最难熬的阶段往往不是审核前的冲刺而是刚接手项目、翻开英文原版标准的那一个月。ISO 26262-1:2018是整个系列标准的第一部分也是唯一以术语和缩略语为核心的章节它定义了后续所有Parts共用的概念框架比如ASIL等级、安全目标、故障容错时间间隔FTTI、相关失效DFI这些词在第3到第10部分里被反复引用。如果术语理解偏差后面做的HARA、安全概念、FMEDA、DFA全是白费。这份ISO 26262-1:2018《道路车辆功能安全-第一部分术语》中文版PDF价值恰恰在于它把200多个概念性条目翻译成了中文并且保留了英文原文对照适合三种人一是刚入门功能安全、需要把英文术语和中文语境对齐的新人二是要跟供应商或认证机构反复对齐术语定义的工程师三是做培训材料、内部评审汇报时需要标准口径表达的负责人。相比官网按页付费下载英文原版这一份直接可查的中文版能帮你省掉大量翻词典、猜定义的时间。标准本身是2018年12月发布的第二版相较于2011版扩展了卡车、客车、挂车、摩托车的要求也引入了网络安全相关术语所以读2018版而不是旧版是避免概念过时的一条基本底线。2. 读懂ISO 26262-1的目录结构术语标准不是词典是功能安全的概念骨架2.1 从范围到缩略语ISO 26262-1的五段式结构如何读拿到PDF先不要跳着翻术语ISO 26262-1:2018的结构是典型的“范围—引用文件—术语—缩略语—参考文献”五段式。第1章范围很短但它是判断“这份标准到底管不管我们项目”的门槛。它明确适用范围是除轻便摩托车外的量产车辆上包含一个或多个电气/电子系统的安全相关系统。做过商用车项目的人应该留意2018版特别把卡车、公共汽车、挂车、半挂车纳入了讨论还专门定义了“车辆上装制造商BB”和“基础车辆”的概念这直接对应了商用车改装的场景。范围里还有一条非常容易被忽略的边界条款已经完成生产发布的系统及其组件不适用于本文件除非发生了变更。这意味着做维护阶段项目时你只需要对变更部分的安全生命周期进行调整而不是全盘重来。很多人在启动一个售后变更项目时不知道工作量和文档要求从哪一级开始其实先读第1章范围就能判断出变更是否触发完整开发流程。第2章规范性引用文件更简短就是指向ISO 26262所有部分。第3章术语和定义是正文的核心从3.1到3.185共200多条术语第4章缩略语则把全系列用到的缩写集中列出来这一章建议直接配合做一张速查卡。我一般建议团队把第3章和第4章打印出来放在工位上因为评审会议、故障树分析、FMEDA表格中涉及的“诊断覆盖率DC”“失效率λ”“耦合系数”这些词经常在跨部门沟通中出现歧义统一的术语口径本身就是一种沟通效率。2.2 术语定义是精读还是泛读三个优先级帮你分配时间200多条术语全部精读既不现实也没必要。按照实际使用频率我建议把术语分成三个优先级。第一优先级是“安全完整性等级 ASIL”“安全目标”“危害事件”“可控性”“暴露度”这五个它们直接决定了HARA分析结果和后续ASIL等级的分配需要做到能够背诵定义并用原话表述。第二优先级是“诊断覆盖率DC”“失效率”“单点故障”“潜伏故障”“故障容错时间间隔FTTI”这些是硬件计算和FMEDA工作的基础参数。第三优先级才是“开发接口协议DIA”“供应协议”“在用证明”这类流程管理术语。一个典型的场景是在做硬件FMEDA时如果分不清“残余故障率”和“潜伏故障率”的统计口径则SPFM和LFM的计算结果必然出错。术语标准对这两个概念的定义差异非常细微前者关注安全机制未覆盖的部分后者关注安全机制本身失效导致的多点故障。这种细微差异在单个术语看并不起眼但在审核时被问到“你这里为什么用残余故障率而不用失效率”时答案就藏在ISO 26262-1的3.8.4和3.8.5条定义中。另一个值得关注的术语群是“相关失效”级联失效、共因失效、共模失效这三者的关系经常被混淆。文档中配了图2和图3来说明差异共因失效是一个根因直接导致多个要素失效而级联失效是一个失效引起另一个失效共模失效则特指多个要素以相同方式失效。DFA相关失效分析的输入就建立在准确区分这三者的基础上否则识别出的耦合系数会漏洞百出。2.3 网络安全的引入2018版相比2011版的关键术语变化ISO 26262-1:2018的引言部分明确列出了相较于2011版的主要变化其中有两条对工程师的实际工作影响最大一是提及了网络安全二是为半导体器件新增了指南。这两者都对应了新的术语比如“安全异常管理”和“安全相关的特殊特性”。做域控制器项目的人应该能感受到2020年以后主机厂对“功能安全与网络安全融合”的要求越来越多ISO 26262-1:2018先把网络安全写进术语体系实际上是为后续ISO 21434的协同工作铺路。具体到术语层面2018版新出现了“紧急运行时间间隔EOTI”和“紧急运行容错时间间隔EOTTI”这两个概念在新能源车的降级策略中非常常用。我做过一个制动项目故障后系统不是立即进入安全状态而是先进入跛行模式此时就需要用EOTI和EOTTI来定义“还能跑多久、跑多远”。如果团队里没有这两个术语的统一理解功能概念阶段写出来的降级策略文档会被安全审核员打回重写。所以读这份术语标准时建议重点标出2018版新增的术语它们是审核时容易被问到、又最体现项目是否跟上标准版本迭代的地方。3. ISO 26262-1核心术语精讲ASIL、故障与失效、生命周期三个概念群串起整个标准3.1 ASIL等级体系从A到D以及QM的边界在哪里ASILAutomotive Safety Integrity Level是ISO 26262系列最核心的产出概念术语3.6给出的定义是四个等级之一A表示最低严格等级D表示最高严格等级而QM不是ASIL等级。这个定义的隐含信息是ASIL等级是通过危害分析和风险评估HARA得出的不是拍脑袋定的。HARA的三个输入参数是暴露度E、可控性C、严重度S三者综合后映射到QM到ASIL D的等级。我见过很多项目在概念阶段确定ASIL等级时直接把“这个功能很重要”等同于“ASIL D”这是错误的。重要性和ASIL等级之间没有必然关系一个对安全影响很低的功能可能就是QM要求只要按一般质量管理流程做即可不需要额外的功能安全活动。与之相关的还有“ASIL能力”和“ASIL等级分解”这两个术语。ASIL能力描述的是要素或相关项满足给定ASIL要求的能力而ASIL等级分解则是一种设计手段将冗余的安全要求分配给具有充分独立性的要素从而降低每个要素需要满足的ASIL等级。但要注意备注中的关键限制ASIL等级分解不适用于随机硬件失效要求而且认可措施保持与安全目标相同的等级。也就是说你可以通过架构冗余把软件部分的ASIL B分解成两个ASIL A但硬件随机失效指标不能通过分解来降低要求。这个边界在术语3.3的注1、注2、注3里写得非常清楚。3.2 故障、失效、错误三兄弟定义之间的链条关系故障fault、错误error、失效failure这三个词在日常沟通中经常混用但在ISO 26262-1中它们是严格递进关系。故障是能够引起要素或相关项失效的异常情况错误是计算值、观测值或测量值与真实值之间的差异失效是要素或相关项预期行为终止。整个链条是故障发生 → 导致错误 → 错误传播到输出 → 最终表现为失效。举例来说内存中的一个比特翻转是故障它导致计算得到的车速值偏大是错误车速信号异常导致功能异常终止是失效。理解这条链对故障注入测试特别重要。ISO 26262-1的3.57定义了故障注入方法可以在不同抽象层面注入故障、错误或失效来验证安全机制。很多测试工程师做故障注入时只关注“注入后系统有没有进入安全状态”而忽略了“注入点应该选在故障层、错误层还是失效层”这个跟测试目的相关的问题。如果目的是验证诊断覆盖率应该在硬件故障层注入如果目的是验证安全机制的反应路径则可以在错误层注入。这两个做法测出来的结论完全不同却在术语上共用“故障注入”这个名字。建议做测试方案前先回到术语3.57确认你注入的对象是fault还是error。3.3 安全生命周期与相关项为什么“满足ISO 26262”要先定义边界术语3.84定义了“相关项”item指实现车辆层面功能或需求的系统或系统组合。这个边界定义是整个安全生命周期活动的起点。在ISO 26262-2的框架里相关项的概念阶段要先做初步危害分析确定安全目标和ASIL等级然后进入系统、硬件、软件层级的开发。如果相关项边界划得不对后面所有工作都可能做偏。最常见的错误是把“一套完整的域控制器”当作相关项但实际上安全分析的对象应该是“实现某一安全功能比如自动紧急制动的传感器、控制器、执行器组合”这才是相关项的正确粒度。另一个容易出错的地方是“要素”element的定义它是系统、组件、硬件元器件或软件单元的统称。做DFA分析时要素的颗粒度直接决定了耦合系数的识别范围。如果要素划分太大耦合关系会被掩盖划分太小分析工作量会爆炸。术语3.29到3.30定义了相关失效DFI和耦合系数其中DFI是通过耦合系数导致多个要素失效的单一根本原因示例包括“两个软件单元共享同一RAM导致数据踩踏”和“两个ECU在同一舱室因进水同时失效”。这些示例在写DFA报告时可以直接作为参考模板使用。4. 从术语到实战用ISO 26262-1的框架推导HARA参数与硬件指标计算4.1 HARA分析中的三个参数E、C、S如何从术语定义中找到依据做危害分析和风险评估时三个参数E暴露度、C可控性、S严重度的定义分别对应ISO 26262-1的三个术语条目。E的定义是3.48“暴露”指处于某运行场景的状态在该运行情况下如果发生所分析的失效模式可能导致危害注意它强调的是“运行场景的暴露时间占比”不是失效概率。C的定义是3.2_5“可控性”指通过涉及人员的及时反应避免特定伤害或损伤的能力示例中包括了驾驶员、乘客和车外人员。S的定义是3.7_4“伤害”但严格来说S的分级还要参考ISO 26262-3的表格。做HARA最常翻车的地方是把E和“失效概率”混为一谈。E只描述行车场景的暴露程度比如高速公路上逆行的暴露度很低城市道路交叉口的暴露度很高而失效本身的发生概率是通过“失效率λ”来描述的两者是正交维度。在HARA表格里E的赋值应该来自场景频率数据而不是FMEA的失效模式概率。这个区分如果不做评估结果很容易被人为调高ASIL等级导致过度设计。术语3.25的注释部分也提醒了“C”表示可控性的可能性而评估可控性时需要考虑驾驶员反应时间、车辆动态响应和外部措施支持。这里的“外部措施”指3.49“外部措施”典型例子是交通标志引导或路侧预警系统。4.2 硬件指标计算的前提失效率、诊断覆盖率与故障分类ISO 26262-5的硬件架构度量指标包括SPFM单点故障指标、LFM潜伏故障指标和PMHF随机硬件失效概率指标而这些计算的输入参数全部来自ISO 26262-1术语体系。首先是“失效率”3.53定义为概率密度除以幸存概率通常用λ表示假设为常数。实际项目中λ值主要来自SN 29500或IEC 62380等可靠性手册。然后是“诊断覆盖率DC”3.33定义为由安全机制探测或控制的失效率占硬件要素失效率的百分比评估时可以通过残留故障或潜伏多点故障来计算。这句话的意思是说DC不是靠仿真“算”出来的而是靠FMEDA逐故障模式分析得出来的。做FMEDA时需要对每一个硬件元器件列失效模式、失效分布、安全机制覆盖情况然后分类为“安全故障”“单点故障”“残余故障”“潜伏故障”。这些分类对应的术语条目分别是安全故障safe fault、单点故障single-point fault、残余故障residual fault、潜伏故障latent fault和多点故障multi-point fault。其中最容易出错的是“潜伏故障”和“多点故障”的关系。潜伏故障指在多点失效被探测前未被安全机制探测到的故障而多点故障本身又分为“双点故障”和“双点失效”。双点失效的定义是两个独立硬件故障组合且直接导致违背安全目标。理解了这条链才能解释为什么系统需要周期性的诊断测试例如自检因为如果没有诊断测试一个潜伏故障永远不会被暴露出来也就谈不上在双点失效发生前及时干预。4.3 安全机制的时间属性FTTI、FDTI、FRTI之间的时序约束安全机制是否存在、是否及时反应体现在一组时间间隔术语中。故障容错时间间隔FTTI定义为在安全机制未被激活情况下从相关项内部故障发生到可能发生危害事件的最短时间间隔。故障探测时间间隔FDTI定义为从故障发生到被探测到的时间间隔。故障响应时间间隔FRTI定义为从探测到故障到进入安全状态或紧急运行的时间间隔。故障处理时间间隔FHTI定义为FDTI加FRTI的总和。这四者的约束关系非常清晰FHTI必须小于FTTI否则危害事件会在安全机制完成响应之前发生。但在实际项目中FTTI不是一个固定值它是通过危害分析确定的与该危害对应的安全目标直接相关。比如一个EPS系统的FTTI可能要求40ms这意味着FDTI加FRTI的总和必须被设计压缩到40ms以内。做系统架构时如果你把安全机制的检测部分和反应部分分属两个供应商就需要在开发接口协议DIA中明确时间预算分配否则集成测试阶段大概率会出现“整体超时、相互甩锅”的情况。2018版还增加了“紧急运行容错时间间隔EOTTI”这个术语其定义是在无风险的前提下能够维持紧急运行的特定时间间隔。EOTTI是EOTI的上限值适用于无法立即进入安全状态的系统典型做法是先降到可控的跛行状态再寻找安全停车时机。这块设计在新能源车的动力电池热失控相关功能安全场景中用得特别多。5. 绕开ISO 26262-1的解读误区四个高频踩坑点与阅读建议5.1 被缩略语表误导同一缩写在不同章节可能指代不同内容第4章缩略语表收集了全系列通用的缩写但实际阅读时要注意同一个缩写有多重含义的情况。比如“BFR”在术语3.8中定义为“基础失效率”但在硬件评估的章节中BFR也可能被混用为“批次故障率”Batch Failure Rate语义完全不同。再比如“DIA”是开发接口协议这是流程管理的概念但做OSEK网络管理的工程师看到DIA会第一时间想到Diagnostic Interface Adapter这是完全不同的东西。这种歧义在跨部门评审时非常容易引发低效争论。建议团队内部维护一份“自用术语表”以ISO 26262-1为准再补充项目中涉及到的行业惯用语与供应商交流时统一使用标准定义。另外缩略语表中的条目不一定覆盖所有章节中的缩写尤其在ISO 26262-5硬件部分和ISO 26262-6软件部分中还有大量只在局部出现的缩写没有进入总表。从实际检索场景来看很多工程师把ISO 26262-1当作“术语字典”来用查某个词时只搜关键词出现位置这种做法虽然快捷但容易忽略术语在具体章节中的语境限定。因此更推荐的做法是先通读第3章一遍对术语全貌有个印象再带着问题去精读具体条目最后回到各Part的上下文中理解术语的应用约束。5.2 “基于安全目标的确认措施”不等于“测试通过”2018版在引言中提到了“目标导向的确认措施”这一变化让很多团队以为只要完成了一系列测试用例就能证明安全目标被满足。但实际上ISO 26262中确认措施的核心是找到证据证明“安全目标在真实车辆场景中不会以不可接受的概率被违背”。这是两回事测试只能证明已测场景的表现符合预期而确认措施要覆盖的是未测场景和残余风险。ISO 26262-4中明确要求确认措施的制定要基于安全目标、ASIL等级和潜在的失效模式并且确认措施本身也需要独立于开发团队进行评审所谓的认可措施。术语3.23对“认可措施”的定义是与功能安全相关的认可评审、审核或评估。也就是说确认活动的结果需要被放到认可评审的框架下接受质询不能自说自话。实际项目中最常见的现象是测试报告写了“所有用例通过”但审核员依然从故障覆盖率、测试环境等价性、极端工况覆盖三个角度提出质疑。这不是审核员刁难而是确认措施设计时没有回到安全目标本身去推导需要哪些证据链。因此做测试规划时应该先写出这个安全目标对应的FTTI、EOTTI约束再反推需要哪些测试来覆盖这些时间参数的实际表现。5.3 2018版标准与2011版标准的差异不能靠“感觉”判断有些团队的内部流程文件上写的还是“参考ISO 26262:2011”却在实际项目中引用2018版标准的术语。这个混用状态在审核中会被视为管理瑕疵。2018版不仅仅是换了个年份确实有明显内容变化扩展了卡车、公共汽车、挂车、半挂车的要求新增了摩托车要求引入了网络安全相关概念更新了硬件架构指标的目标值增加了半导体指南还给出了基于模型的开发和软件安全分析指导。如果团队的项目范围涉及商用车改造就必须使用2018版框架因为2011版根本不适用于这些场景。另外2018版对“目标导向的确认措施”和“安全异常管理”给出了更细致的定义这也影响了项目管理文档和工作成果的结构。建议每一个新项目启动前在项目计划里明确写出“本项目的功能安全活动依据ISO 26262:2018系列标准其中第一部分为术语基准”并依据标准把项目裁量项记录下来。这个动作看起来小但在审核时直接决定了“你的准则文件是否有效”这一项的结论。5.4 中文版PDF用于内部培训可行但不能作为审核依据文件中文版PDF最大的价值是辅助理解和内部培训官方审核时提交的证据必须是英文原版或者满足特定翻译规范的正式译本。如果你所在的公司需要通过第三方认证机构审核提交的文件清单里必须包含ISO 26262-1:2018的官方英文版。中文版只可以出现在内部流程文件中作为参考附件且需要标注“非官方翻译仅供内部参考”字样。我从团队使用效果看推荐的做法是由功能安全经理把中文版作为基准进行内部培训把关键术语的中英文对照做成卡片所有对外交付文档仍然用英文术语原词。这样既提升了团队的理解效率又不影响审核正式性。另外中英文对照阅读时要注意“术语翻译一致”的问题。同一个英文术语在不同公司的内部文件中可能被翻译成不同中文词比如“confirmation measure”有人叫“认可措施”有人叫“确认措施”翻译差异还不小。第3章第23条的精确含义是“认可措施”包括认可评审、审核、评估三类活动。建议在项目开始时做一次术语对齐会议以这份PDF为准把项目里涉及安全词汇的中文表述统一起来避免做评审时反复澄清定义。6. 把术语标准用成工具建立团队术语卡、对照原版快速定位、接入项目裁量真正用好这份ISO 26262-1:2018中文版PDF需要把它从“读过一遍的资料”变成“随取随用的工具”。我自己的习惯是每接手一个新功能安全项目先花半天时间在这份术语表上做三件事第一把与本项目强相关的术语挑出来做成双栏术语卡英文术语、中文定义、项目中的应用场景各占一组字段放入项目共享目录后加入的工程师第一天就要求通读这些术语卡第二凡是内部评审中出现歧义的术语记录到一个“争议术语清单”里统一裁决后同步给所有合作方包括供应商那边也要有专人确认口径一致第三在合规范式文档的模板里加入“术语依据”栏每一项关键决策都对应到本标准的术语条目。这样做的好处是审核员在检查设计文档时可以从术语引证上看到整个团队的体系性理解。例如报告中写“根据ISO 26262-1:2018术语3.61FTTI定义为在安全机制未被激活情况下从相关项内部故障发生到可能发生危害事件的最短时间间隔”这句话比光写一个FTTI数值有说服力得多。2018版标准对不同场景的适应性本身也是一种裁量能力。ISO 26262-1中很多描述给了灵活性空间——例如分布式开发的责任分配通过开发接口协议来约定并没有规定格式模板。在供应链合作中常见做法是用DIA明确客户和供应商各自负责的安全活动、需要交换的工作成果以及评审介入方式。很多团队只关注技术内容而忽略DIA的管理价值结果项目中期出现“安全需求变更了但供应商设计文档没同步更新”这种典型的接口失效场景。如果DIA中提前写明了变更管理的触发条件和信息传递路径这种问题是完全可以避免的。术语3.32把DIA定位为“客户与供应商之间的协议”定义虽然简短但它是整个分布式开发安全责任划分的基石。最后分享一个切实的建议把ISO 26262-1:2018中文版和英文原版放在同一个文件夹里中文版负责快速理解、培训宣贯英文版负责正式引用和审核佐证。文件中涉及的“专业摩托车驾驶员”“车辆上装制造商”等新术语恰恰是2018版相对2011版扩展的产物也是日常项目交流中最容易出交流盲区的地方。做完上述的术语卡和维护工作后从中体验最明显的改变就是团队在安全评审会上不再纠结某个名词是什么意思而是直接把讨论推进到“这个定义下我们该做什么、怎么做”。从那以后我每次启动功能安全相关项目都强制走完一遍“术语卡对齐、争议术语裁决、参考条款标注”这组动作操作不费力却在后续的评审、供应商沟通和文档编写环节省下了大量返工时间。也希望这份中文版术语标准能帮你在功能安全的路上走得比预期更顺利。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
