ISO 26262-1术语实战：对齐评审口径与安全需求追溯

简介这份PDF是ISO 26262-1:2018《道路车辆功能安全 第一部分术语》的中文版面向汽车行业电气/电子系统研发人员、功能安全工程师及相关研究者。它解决的是功能安全术语理解不统一、中英文对照困难的问题适合具备一定汽车工程与电气知识、希望系统掌握标准基础概念的中高级读者。资源包内仅1个PDF文件大小约632KB内容涵盖标准前言、引言、范围、规范性引用文件、术语和定义及缩略语等模块其中术语定义部分篇幅最重是后续各部分标准阅读的基石。目前已有1352人学习下载。读者可借此准确理解安全完整性等级、危害、风险、安全目标等核心术语把握2018版相对2011版在卡车、公共汽车、挂车、半挂车及摩托车要求上的扩展以及网络安全、安全异常管理、硬件架构指标更新等新增内容为功能安全开发、评审与认证工作提供权威的术语依据。1. 术语不是背的是拿来对齐评审口径的做汽车电子的人大多有过这种场面评审会上有人把 ASIL 和 SIL 混着说有人把 FTTI 当成诊断周期还有人把“安全状态”和“故障容错时间”当成一回事。争论半小时最后发现大家说的根本不是同一个东西。ISO 26262-1:2018 这一部分就是干这个用的——它不教你怎么设计只把整套标准里反复出现的词钉死。道路车辆功能安全这套体系横跨概念、系统、硬件、软件、支持过程术语不统一后面所有工作都会在接口上打滑。这份中文版 PDF 的价值不在于“读完”而在于当字典查写安全计划、做 DFA、定安全需求、跟供应商对边界时随手翻到对应词条把口径拉齐。适合谁系统工程师、功能安全经理、软硬件开发、测试和评审人员尤其是刚接手 26262 项目、被一堆缩写砸晕的人。先把词对齐再谈方法论顺序不能反。2. ISO 26262-1 术语体系怎么读才不散2.1 从“安全生命周期”串起整份术语表术语表按字母或拼音排直接从头读到尾会散。我一般按安全生命周期的主线去串先看 item、system、element 这组“对象词”再看 hazard、risk、harm 这组“风险词”接着是 safety goal、functional safety requirement、technical safety requirement 这组“需求词”最后落到 ASIL、FTTI、safe state、fault tolerance 这组“指标与状态词”。这条线走完术语之间是有因果的item 识别出 hazardhazard 导出 safety goalsafety goal 分配 ASILASIL 决定 FTTI 和诊断覆盖率的严苛程度。术语组代表词条在项目里对应什么对象item / system / element / component界定分析边界和接口风险hazard / harm / risk / exposureHARA 的输入输出需求safety goal / FSR / TSR需求分解与追溯指标ASIL / FTTI / SPFM / LFM设计与验证的量化目标状态safe state / degraded state故障响应策略提示中文版里同一个英文词可能有多种译法跨部门文档务必以标准词条为准别自造缩写。2.2 容易混的三组词用代码做一次口径校验术语最容易出错的地方是“看起来像”。ASIL 和 SIL、fault 和 failure、FTTI 和诊断测试间隔这三组混用会直接导致需求写错。我习惯写个小脚本把项目需求文档里的关键词扫一遍标出可疑用法评审前先自查。# 术语口径自查扫描需求文本中的高风险混用词 import re # 左列是标准术语右列是常见误用/易混词 confusable { ASIL: [SIL, 安全完整性等级], # SIL 属于 IEC 61508 体系 fault: [failure, 错误], # fault 是缺陷failure 是失效表现 FTTI: [诊断周期, diagnostic interval], # FTTI 是容错时间不是测试周期 safe state: [安全模式, shutdown], # 安全状态是定义好的运行状态 } def scan(text): hits [] for std, wrongs in confusable.items(): for w in wrongs: for m in re.finditer(re.escape(w), text): hits.append((std, w, m.start())) return hits if __name__ __main__: doc open(safety_requirements.txt, encodingutf-8).read() for std, wrong, pos in scan(doc): print(f疑似混用: 应为[{std}] 出现[{wrong}] 位置{pos})逻辑说明confusable字典把标准术语和易混词配对scan用re.finditer找出所有出现位置并返回上下文偏移。参数上wrongs列表可以按团队历史评审问题持续补充pos用于定位到具体段落。这个脚本不判断对错只把可疑点捞出来人工确认避免评审时才发现口径不一致。2.3 中文版 PDF 的检索与引用姿势PDF 直接翻效率低我一般先转成可全文检索的文本再建关键词索引。用pdftotext抽文本配合grep -n定位词条比在阅读器里点搜索快得多。# 抽取中文版 PDF 文本保留页码分隔 pdftotext -layout ISO26262-1-2018.pdf iso26262_1.txt # 查某个术语出现的所有位置带行号 grep -n 功能安全 iso26262_1.txt | head -20 # 查 ASIL 相关词条上下文 grep -n -A3 -B1 ASIL iso26262_1.txt参数说明-layout保留原始排版表格和分栏不容易串行-n输出行号便于回查-A3 -B1显示匹配行后 3 行前 1 行看词条定义够用。注意扫描版 PDF 抽不出文本需要先做 OCR这一步别省否则后面检索全是空。3. 把术语落进 HARA 与安全需求的最小闭环3.1 用术语定义驱动 HARA 的输入输出HARA 是术语密度最高的活动。按第 1 部分的定义hazard 是“潜在伤害来源”harm 是“实际伤害”risk 是“伤害严重度与发生概率的组合”。这三个词定死了HARA 的表格列就不会乱填。我一般把术语定义直接做成 HARA 模板的表头注释谁填谁知道边界在哪。HARA 列对应术语填写要求功能item function描述 item 提供的功能故障行为malfunctioning behavior功能失效后的表现危害hazard潜在伤害来源非伤害本身严重度 Sseverity按标准分级不拍脑袋暴露率 Eexposure场景出现概率可控性 Ccontrollability驾驶员可控程度ASILASIL由 S/E/C 查表得出注意hazard 和 harm 别写反。hazard 是“可能造成伤害的条件”harm 是“已经发生的伤害”。HARA 里填的是 hazard。3.2 从 safety goal 到 TSR 的术语追溯safety goal 是顶层安全目标functional safety requirement 是功能层分解technical safety requirement 是技术层落地。三者是逐级细化关系术语定义里对每一层都有约束。追溯断了评审必挂。我一般用一张追溯表加脚本校验完整性。# 安全需求追溯完整性校验SG - FSR - TSR 不能断链 requirements [ {id: SG-01, type: SG, parent: None}, {id: FSR-01,type: FSR, parent: SG-01}, {id: TSR-01,type: TSR, parent: FSR-01}, {id: TSR-02,type: TSR, parent: FSR-99}, # 故意断链 ] ids {r[id] for r in requirements} for r in requirements: if r[parent] and r[parent] not in ids: print(f断链: {r[id]} 的父需求 {r[parent]} 不存在)逻辑说明先收集所有需求 ID 到集合ids再遍历检查每个需求的parent是否在集合里。参数上type字段用于区分 SG/FSR/TSR 层级parent为空表示顶层。这个校验放在需求管理工具导出后跑一遍比人工对表可靠。断链输出直接对应评审整改项。3.3 ASIL 分解与术语边界ASIL 分解是术语误用重灾区。标准允许 ASIL D 分解为 ASIL B(D) ASIL B(D) 这类组合但分解有前提条件不是随便拆。术语定义里对 ASIL 分解的适用条件有明确约束分解后的需求必须独立、无共因失效。我一般先确认分解前提再动需求。# 在抽取的术语文本里查 ASIL 分解相关词条 grep -n -A5 分解 iso26262_1.txt | grep -i ASIL参数说明先grep定位“分解”词条再管道过滤含 ASIL 的行快速拿到分解定义的原文段落。这一步是为了在写分解方案前把标准原文的约束条件抄进设计说明避免评审时被问“依据哪一条”。4. 术语一致性在评审与供应商协同中的实战4.1 评审 checklist用术语表反查文档评审前我一般做一轮术语反查把安全计划、HARA、安全需求、DFA 报告里的关键词对照第 1 部分术语表逐个核对。重点查三类缩写是否首次出现时给了全称、中英文是否混用、自定义词是否有定义。下面这个 checklist 可以直接抄。检查项判定标准常见问题缩写全称首次出现给全称缩写直接写 ASIL 不解释中英一致同一概念全文统一一会儿“安全状态”一会儿“安全模式”自定义词有明确定义和出处自造“安全等级”代替 ASIL层级词SG/FSR/TSR 不混用把 TSR 写成 FSR状态词safe state 有明确定义把 shutdown 当 safe state提示checklist 跑完把问题按文档归类评审会上直接按类过比逐页翻快。4.2 供应商接口DIA 里的术语对齐和供应商签 DIA开发接口协议时术语不对齐是后期扯皮的根源。我一般把第 1 部分里与接口相关的词条摘出来附在 DIA 术语附录里明确每个词在本项目中的含义。比如“安全状态”在供应商那边可能指断电在整车这边可能指降级运行不写清楚验收时各说各话。# 生成 DIA 术语附录从术语表筛选接口相关词条 interface_terms [safe state, FTTI, ASIL, fault, failure, safety goal, functional safety requirement] with open(dia_glossary.md, w, encodingutf-8) as f: f.write(# DIA 术语附录\n\n) for t in interface_terms: f.write(f- **{t}**: 本项目定义为 ……引用 ISO 26262-1:2018 词条\n)逻辑说明interface_terms列出接口高频词脚本生成 Markdown 附录骨架人工补定义。参数上词条列表按项目接口范围增删输出文件直接并入 DIA。这样做的目的是让术语定义有出处、可追溯而不是口头约定。4.3 用脚本做跨文档术语一致性抽查多份文档并行时人工核对容易漏。我一般写个抽查脚本把术语表里的标准词和文档里的实际用词做比对输出不一致项。# 跨文档术语一致性抽查 import glob, re standard {安全状态: [安全模式, shutdown], 功能安全需求: [功能安全要求, FSR需求]} for path in glob.glob(docs/*.md): text open(path, encodingutf-8).read() for std, wrongs in standard.items(): for w in wrongs: if w in text: print(f{path}: 建议用[{std}] 替换[{w}])逻辑说明standard字典维护标准词与建议替换词glob遍历文档目录逐个比对输出。参数上docs/*.md按实际文档格式调整替换建议只提示不自动改避免误伤。这个脚本放在评审前跑能捞出一批低级不一致。5. 术语查询效率与版本比对的进阶技巧术语表用得多了会发现两个进阶需求一是快速定位某个词在第 1 部分和其他部分如第 5、6、8 部分的定义差异二是比对 2011 版和 2018 版的术语变化。这两个需求靠手工翻很痛苦我一般用脚本做。先做跨部分术语定位。把各部分的 PDF 都抽成文本按词条名建索引查一个词就能看到它在各部分出现的位置和上下文。# 批量抽取各部分文本 for p in 1 5 6 8; do pdftotext -layout ISO26262-$p-2018.pdf iso26262_$p.txt done # 查“安全状态”在各部分的定义位置 for p in 1 5 6 8; do echo Part $p grep -n -A2 安全状态 iso26262_$p.txt | head -6 done参数说明for循环按部分号批量抽取-layout保留排版第二个循环按部分输出“安全状态”的上下文head -6控制输出量。这样能快速看出同一个词在不同部分的定义侧重比如第 1 部分是通用定义第 5 部分是硬件层面的具体化。再做版本比对。2011 版到 2018 版术语有增删改用diff能快速看出变化。# 比对两版术语文本差异 diff iso26262_1_2011.txt iso26262_1_2018.txt term_diff.txt # 只看新增词条2018 有而 2011 无 comm -13 (sort iso26262_1_2011.txt) (sort iso26262_1_2018.txt) | head -30参数说明diff输出全量差异到文件备查comm -13取只在 2018 版出现的行即新增内容。注意两版文本需先做清洗去页眉页脚否则差异里全是排版噪声。这一步做完版本升级时术语影响面一目了然。最后一个技巧把术语表做成可检索的本地知识库。用ripgrep替代grep速度更快配合-C看上下文日常查词效率明显提升。# 用 ripgrep 快速查术语带上下文 rg -C 2 故障容错时间 iso26262_1.txt参数说明-C 2显示匹配行前后各 2 行rg默认递归且忽略二进制文件。把常用查询封装成 shell 函数比如t() { rg -C 2 $1 iso26262_1.txt; }查词就是一行命令的事。术语查询从“翻 PDF”变成“敲命令”评审前临时查证不再手忙脚乱。本文还有配套的精品资源点击获取