简介：《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的边界在哪里
ASIL（Automotive 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.61，FTTI定义为在安全机制未被激活情况下，从相关项内部故障发生到可能发生危害事件的最短时间间隔”，这句话比光写一个FTTI数值有说服力得多。
2018版标准对不同场景的适应性本身也是一种裁量能力。ISO 26262-1中很多描述给了灵活性空间——例如分布式开发的责任分配通过开发接口协议来约定，并没有规定格式模板。在供应链合作中，常见做法是用DIA明确客户和供应商各自负责的安全活动、需要交换的工作成果以及评审介入方式。很多团队只关注技术内容而忽略DIA的管理价值，结果项目中期出现“安全需求变更了，但供应商设计文档没同步更新”这种典型的接口失效场景。如果DIA中提前写明了变更管理的触发条件和信息传递路径，这种问题是完全可以避免的。术语3.32把DIA定位为“客户与供应商之间的协议”，定义虽然简短，但它是整个分布式开发安全责任划分的基石。
最后分享一个切实的建议：把ISO 26262-1:2018中文版和英文原版放在同一个文件夹里，中文版负责快速理解、培训宣贯，英文版负责正式引用和审核佐证。文件中涉及的“专业摩托车驾驶员”“车辆上装制造商”等新术语，恰恰是2018版相对2011版扩展的产物，也是日常项目交流中最容易出交流盲区的地方。做完上述的术语卡和维护工作后，从中体验最明显的改变就是：团队在安全评审会上不再纠结某个名词是什么意思，而是直接把讨论推进到“这个定义下我们该做什么、怎么做”。从那以后，我每次启动功能安全相关项目都强制走完一遍“术语卡对齐、争议术语裁决、参考条款标注”这组动作，操作不费力，却在后续的评审、供应商沟通和文档编写环节省下了大量返工时间。也希望这份中文版术语标准能帮你在功能安全的路上走得比预期更顺利。
本文还有配套的精品资源，点击获取
