简介《IEC 61508-12010 第1部分一般要求》是功能安全领域的基础性国际标准文档适合电气、电子及可编程电子安全相关系统的设计、开发、验证、审查与认证人员使用用于解决安全要求定义、生命周期活动策划及合规依据查找等问题。文件包仅含1个PDF大小约2.11MB标准正文高清可复制且非扫描版条款检索、关键词定位和片段摘录都较方便。内容系统梳理风险评估、安全生命周期、系统架构与冗余、可靠性分析、软件开发、验证确认、变更管理、人员能力及文档记录等通用要求并交代其作为基本安全出版物的定位与适用边界。读者可据此搭建功能安全知识框架也可将其作为项目审查、培训备课和第三方认证准备时对照引用的底稿。已有617人学习下载。1. 一个反直觉的结论IEC 61508-1 通篇几乎不谈技术翻开 IEC 61508-1:2010 的目录八章正文里找不到一行讲冗余电路怎么接、看门狗怎么喂、诊断覆盖率怎么测。这套在功能安全领域被当作顶层依据的一般要求把绝大部分篇幅花在了「谁在什么阶段该产出什么证据」上。初学者常因此觉得它空泛做过一轮完整项目的人反而会觉得它严苛——因为它把「安全」从一种技术属性重新定义成了一条经得起审计的证据链。搞懂这条链条怎么搭起来比背下 SIL 2 对应哪几个数值有用得多。2. 整体安全生命周期为什么十六个阶段之间必须有明确的交接2.1 十六个阶段不是流程图是一张责任交接单IEC 61508-1 第 7 章用十几个小节把整体安全生命周期拆成十六个阶段从概念7.2一路排到停用与处置7.17。很多人第一眼把它当成项目流程模板照着画一条横线就完事这是最容易出错的读法。这十六个阶段的真正形态是一组串行的输入输出契约每个阶段的输出物就是下一个阶段唯一合法的输入。拿前五个阶段举例。概念阶段确定受控设备与被控设备的功能边界整体范围定义阶段把边界内的物理范围、时间范围、运行模式固定下来危险与风险分析阶段在这个边界内枚举危险事件并估算风险整体安全要求阶段把「不可接受的风险」翻译成「必须执行的安全功能及其完整性等级」整体安全要求分配阶段再把每条安全功能切分到 E/E/PE 系统、其他技术措施、外部风险降低措施三条路径上。顺序不可交换的原因很实际危险是相对于边界定义的。同样的超温事件在只考虑正常运行时是一个风险等级在把清机、检修、启动预热也算进范围后可能是另一个等级。如果先做风险分析再补范围定义风险分析的结论会变成一堆无法追溯前提的数字后面整条链都站不住。阶段关键输出物直接下游概念受控设备功能描述、环境条件范围定义整体范围定义边界、运行模式、时间跨度危险与风险分析危险与风险分析危险清单、风险估计、可容忍风险判据整体安全要求整体安全要求安全功能清单 每条功能的 SIL分配、三个前置计划整体安全要求分配分配结果与分配理由E/E/PE 系统安全要求规范这张表的用法不是背而是拿它当检查表任何一个阶段的输出无法逐条指向它在表格里的下游消费者说明这一步实际上没做完。2.2 验证7.18为什么被画成横线而不是方框第 7 章最后一个小节是验证标准正文里给它的定义是「确认某阶段的活动与输出满足该阶段的目标与要求」。注意这句话的主语不是产品是阶段输出。所以它没法画成一个方框接在流程末尾只能横贯所有阶段每个阶段都要配一条验证活动。这个设计带来的直接后果是第 7 章的每个阶段小节几乎都遵循同一套骨架先给 Objective这个阶段要达成什么再给 Requirements达成它必须满足哪些约束。验证活动对照的就是这两段文字而不是对照后面的实现。换句话说标准在逻辑上把「通过判据」和「生产动作」分开了生产动作可以随技术演进而变化通过判据不能。工作里踩过的坑大多出在这里验证被排成了项目末期的集中测试于是验证对象悄悄从「阶段输出是否满足阶段目标」漂移成了「实现是否符合当初的实现」。后一种验证永远能通过因为它自己证明自己。提示判断一个项目有没有真正在做阶段验证最快的办法是抽一条安全功能问它在整体安全要求阶段的验收判据是什么再看现场能不能拿出对应记录。2.3 三张生命周期图的嵌套realisation 阶段被展开两次标准给了三张图。Figure 2 是整体安全生命周期Figure 3 是 E/E/PE 系统安全生命周期Figure 4 是软件安全生命周期。Figure 3 和 Figure 4 都不是独立流程它们是把 Figure 2 中第 10 阶段E/E/PE 安全相关系统实现这一个方框掰开之后的内部结构。这是一个相当克制的分层设计。Part 1 作为一般要求只负责定义「实现阶段必须被展开成更细的生命周期」这件事以及展开后必须满足的目标具体怎么展开交给 Part 2系统和 Part 3软件。好处是分层稳定软件工程实践从瀑布演进到迭代、再到持续集成Part 1 的正文几乎不需要动只要 Part 3 在解释「软件安全生命周期各阶段如何映射到迭代开发」上更新即可。我一般会这么理解这套分层Part 1 定义的是收口条件Part 2 和 Part 3 定义的是收口方式。项目里真正落地时顶层计划书只需要引用 Part 1 的阶段编号把每个阶段的详略和裁剪写在自己的安全计划里再用 Part 2/3 的方法论填内容。这样一次裁剪可以复用到多个产品线不必为每个项目重写一遍生命周期。嵌套的代价也很清楚阶段的边界会因为两次展开而变得模糊。比如软件需求规范到底算整体安全要求的下游还是算 E/E/PE 系统安全要求的下游标准给的答案是后者软件需求必须是系统需求分解的结果而不是直接从危险分析跳过去。这条约束挡住了大量「危害直接变代码」的项目。2.4 三个前置计划为什么运行维护计划要写在设计之前第 7 章有一个非常反常规的安排整体运行与维护计划7.7、整体安全验证计划7.8、整体安装与调试计划7.9这三个阶段被排在了 E/E/PE 系统安全要求规范7.10和实现7.11之前。也就是说东西还没开始设计先要写清楚将来怎么运行、怎么验证、怎么装。这个顺序背后是三个硬约束。第一运行维护计划决定了设计参数。诊断覆盖率能做到多少、proof test周期性功能测试间隔设多长、在线可测还是只能停机测这些直接决定了后续计算出的 PFDavg 或 PFH 能达到哪一个 SIL 区间。先设计再定维护策略等于让架构去追一个还没确定的数字最后往往只能靠加冗余硬凑。第二验证计划前置是标准的「验收判据先于实现」思路。整体安全验证7.14的通过条件必须在实现开始之前写清楚否则验收标准会被实现结果反向塑造。这一点和后来软件工程里强调的测试先行是同一个道理只是这套要求 2010 年就已经是强制项。第三安装调试计划前置是为了防止设计超出场地能力。现场供电、接地、传感器安装位置、调试窗口期这些都会反向压缩设计空间。不少项目的返工不是算法问题是设计做完才发现现场根本没有足够的位置装第二套传感器。三个计划在实现阶段之后还会被反复回填但它们的位置固定在第 5 阶段之后、第 9 阶段之前。位置的固定比内容完备更重要。3. 从危害到 SIL安全要求分配如何把定性风险变成可判定的数字3.1 危害、风险、安全要求是三层不同的东西危险与风险分析7.4产出的是危险事件清单和对应的风险估计。整体安全要求7.5产出的是安全功能。「超温会导致起火」是危险描述「温度超过阈值后 200 ms 内切断加热回路」才是安全功能。这两者之间隔着一层翻译标准要求这一层翻译必须显式写出来不能隐含在分析报告里。一条合格的安全功能描述通常要固定四个要素触发条件输入、期望动作输出、响应时间约束、失效时的行为fail-safe 还是继续运行。少任何一个要素后面的验证就无法判定通过与否。整体安全要求分配7.6是在此之上再加一层这条功能由谁来实现。标准明确允许一条安全功能被拆分给三类实现路径——E/E/PE 安全相关系统、其他技术比如机械泄压阀、化学抑制剂、外部风险降低措施比如物理隔离、操作规程。分配结果必须连同分配理由一起记录因为分配本身就是风险论证的一部分。3.2 分配的本质是「剩余风险的算术」把一个整体风险目标拆到三条路径上做的是概率的组合运算。若三条路径独立整体失效概率近似为各路径失效概率之积的量级若不独立共因失效会把这个乘积抬高一个甚至几个数量级。标准在分配阶段要求考虑共因原因就在这里两条路径如果共用同一个电源、同一套传感器、同一批维护人员它们不是两条独立防线。常见的实现思路是先做粗分把安全功能的主体压到 E/E/PE 路径上用其他技术措施兜住 E/E/PE 路径的共因失效再靠外部措施降低人员暴露概率。粗分完成后再逐条回算看每一条路径承担的完整性目标是否落在可实现区间内。回算发现某条路径要求过高比如要求单通道做到 SIL 4工程上几乎不可行正确做法是回到分配表重新切分而不是在实现阶段硬加冗余。3.3 PFDavg 与 PFH两种量纲对应两种运行模式完整性等级对应的不是「可靠度百分比」而是一个失效概率区间而且区间取值取决于安全功能的运行模式。低要求模式指安全功能的操作频率不大于每年一次、或不大于 proof test 频率的两倍高要求模式和连续模式则按每小时危险失效频率衡量。SIL低要求模式PFDavg按需失效平均概率高要求/连续模式PFH每小时危险失效频率4≥ 10⁻⁵ 且 10⁻⁴≥ 10⁻⁹ 且 10⁻⁸3≥ 10⁻⁴ 且 10⁻³≥ 10⁻⁸ 且 10⁻⁷2≥ 10⁻³ 且 10⁻²≥ 10⁻⁷ 且 10⁻⁶1≥ 10⁻² 且 10⁻¹≥ 10⁻⁶ 且 10⁻⁵两个细节值得单独拎出来。第一区间是左闭右开数值正好等于上界时属于低一级工程上算出来的结果贴着上界评审时基本等同于不达标。第二模式判断发生在功能层面而不是设备层面。同一个控制器里某条安全功能一年触发两次是低要求模式另一条功能持续参与联锁是高要求模式。整台设备只写一个 SIL 数字语义是残缺的这也是现场最常被误读的地方。低要求模式为什么用 PFDavg 而不用 PFH逻辑在于检验周期。低要求模式下安全功能长期处于待命状态危险的隐性失效要等到下一次 demand 或下一次 proof test 才暴露所以关注的是「一次需求来临时它失效的概率」这个概率由检验周期和诊断覆盖率共同决定。高要求模式下功能持续动作失效暴露得快用单位时间的失效频率更自然。3.4 用一段检查脚本把分配结果固定下来分配表在文档里是文字在工具链里应该是一组可校验的数据。下面这段检查逻辑的作用是给定一条安全功能的运行模式和目标 SIL判断分配后估算出的完整性指标是否落在合法区间内。真实项目里这个检查要接在分配评审的出口而不是等项目结束再跑。# 完整性目标区间与运行模式绑定不在设备层面绑定 PFD_RANGES { # 低要求模式按需失效平均概率 4: (1e-5, 1e-4), 3: (1e-4, 1e-3), 2: (1e-3, 1e-2), 1: (1e-2, 1e-1), } PFH_RANGES { # 高要求 / 连续模式每小时危险失效频率 4: (1e-9, 1e-8), 3: (1e-8, 1e-7), 2: (1e-7, 1e-6), 1: (1e-6, 1e-5), } def check_allocation(sil: int, mode: str, achieved: float) - bool: mode 只能是 low 或 highachieved 是分配后估算的指标值 table PFD_RANGES if mode low else PFH_RANGES lo, hi table[sil] # 注意左闭右开achieved 等于 hi 时实际已降级到下一个 SIL return lo achieved hi # 反向用法由估算值反推它能支撑的最高 SIL def max_sil(mode: str, achieved: float) - int: table PFD_RANGES if mode low else PFH_RANGES for sil in (4, 3, 2, 1): if check_allocation(sil, mode, achieved): return sil return 0 # 连 SIL 1 都达不到必须回退重新分配这段代码里真正有价值的是max_sil。正向判断只能回答「达标没达标」反推能回答「这条路径现在最多能撑到几级」后者才是分配阶段要的答案。工程实践中常见的情况是分配表上写了 SIL 3反推出来实际只能到 SIL 2此时正确的动作是回到 7.6 重新切分比如把一部分诊断职责挪到其他技术措施上而不是在实现阶段靠堆冗余硬拽指标。参数说明achieved来自可靠性数据计算通常由元件失效率、诊断覆盖率、检验周期、共因因子共同推导不在 Part 1 的范围内Part 6 给了计算示例。函数里的区间表直接对应标准正文的完整性等级表修改这张表等于修改合规基线评审时必须显式记录版本。4. 文档与功能安全管理证据链是怎么被固定下来的4.1 第 5 章只提了两条要求重量全在附录里正文第 5 章关于文档的要求非常短文档要包含足够信息让执行生命周期活动的人和需要评审、审计的人都能完成各自工作文档要按阶段产出、可追溯、可维护。就这么两句看起来毫无操作性。真正的内容在资料性附录 A 里它给了一套文档结构示例从安全计划开始经危险与风险分析、整体安全要求、分配、各阶段验证记录一直排到功能安全评估报告。附录是「资料性」的意味着不强制照抄结构但它给出了一个绕不过去的东西——文档之间的引用关系。每一份文档都要能回答它引用了谁、被谁引用、对应哪个生命周期阶段。这个设计动机不难猜标准要适配机械、过程工业、医疗、轨道交通等各种领域写死文档模板会立刻失效。只规定关系不规定格式才能让领域标准在裁剪时保留追溯结构而替换文档形态。4.2 第 6 章管理的不是进度是能力和配置功能安全管理第 6 章常被理解成「成立一个安全委员会、开几次会」。实际要求指向三件更具体的事责任与权限的明确划分、参与人员的能力证据、贯穿生命周期的配置管理与变更控制。能力证据这一条最容易被忽略。标准要求的不是培训签到表而是能说明「这个人具备完成该项活动所需的技术能力」的记录且要与其承担的具体活动对应。做危险与风险分析的人和写软件单元测试的人能力证据的内容完全不同。配置管理在 Part 1 里的地位比想象中高。它要求所有安全生命周期输出物纳入配置管理包括工具、库、第三方组件。理由很直接功能安全的论证建立在「当时那一版」之上任何未经控制的变更都会让论证失效。这也是为什么很多项目的功能安全评估卡在工具链版本上——评估方要确认分析时用的建模工具版本和最终交付版本一致。4.3 追溯矩阵评估现场唯一能翻的东西把前面几章串起来看整条链的产物就是一张追溯矩阵危险 → 安全功能 → 完整性等级 → 分配路径 → 系统需求 → 软硬件需求 → 实现项 → 验证记录 → 评估结论。矩阵的每一行是一条完整论证每一列是一个阶段。这张矩阵的价值不在于好看而在于它能被机器检查。现场评审时最有效的一招是抽一行正向走到验证记录、反向走回危险清单任何一处断开都说明论证不完整。# 追溯链的最小闭环检查每条安全功能都必须有目标等级和验证记录 def audit_chain(functions, verifications): functions: [{id: SF-07, sil: 3, mode: low}, ...] verifications: {SF-07: [VR-07-01, VR-07-02], ...} 返回缺口列表空列表代表这一层闭合 gaps [] for fn in functions: if fn.get(sil) is None: gaps.append((fn[id], 未分配完整性等级回到 7.6)) if fn.get(mode) not in (low, high): gaps.append((fn[id], 运行模式未定义量纲无法确定)) if not verifications.get(fn[id]): gaps.append((fn[id], 无验证记录阶段输出未闭合)) return gaps代码之后要说明的是执行时机这个检查不是交付前跑一次而是在每个阶段的出口跑一次。阶段出口的缺口数量是最直观的进度指标比文档完成率可靠得多。参数mode缺失之所以单独报出来是因为量纲缺失会让后面所有数值比较失去意义这类错误在早期发现只需要改一行晚期发现要重做整套可靠性计算。5. 避坑五条反复出现的现场问题5.1 把 SIL 等级当成整机属性现象规格书首页写着「本产品满足 SIL 3」问是哪几条安全功能达到 SIL 3、运行模式是什么答不上来。原因SIL 挂在安全功能上安全功能挂在具体的受控设备与被控设备组合上。整机不具备 SIL 属性只有「在某应用场景下执行某条安全功能」才具备。厂商宣传语和工程论证说的是两件事。解决规格书里只写「可用于构建最高 SIL x 的安全功能」并附上安全功能清单、运行模式、以及使用限制条件。评审时按清单逐条核对不接受整机口径的结论。5.2 危险分析做完直接进设计跳过整体安全要求现象危险清单做得很细代码也写了但问某条安全功能的响应时间约束只能回答「实测大概几十毫秒」。原因危险描述被直接当成了需求。危险说「超温导致起火」需求要说「超过 T 阈值后 200 ms 内切断加热」。「大概几十毫秒」不是一个可验证的判据验证阶段只能记录实测值无法判定通过与否。解决在 7.5 和 7.10 之间加一道硬门槛每条安全功能必须凑齐触发条件、期望动作、响应时间、失效行为四要素才允许进入下游。凑不齐的退回危险分析重新推导。5.3 验证准则在实现完成之后才写现象验证报告全部通过但报告里的判据和设计文档里的描述几乎逐字相同。原因验证准则定义晚于实现写准则的人手里只有实现结果只能照着写。这时的验证已经退化成确认不再具备发现偏差的能力。解决把 7.8 的整体安全验证计划作为实现阶段的前置交付物验证准则必须能追溯到 7.5 的安全功能描述而不是追溯到 7.10 的系统需求。追溯方向反了独立性就没了。5.4 文档在项目末期集中补齐现象评审前两周集中写文档交付的文档体系看上去完整但版本号和代码仓库对不上。原因文档被当成交付物而不是过程产物。功能安全论证依赖的是「某个阶段当时依据的信息」事后补写的文档写的是「最终记得的情况」两者之间存在不可恢复的信息损失。解决文档按阶段出口产出纳入配置管理与代码、模型、工具版本绑定同一个基线号。任何一份文档如果无法指出它对应的基线视为不存在。5.5 修改只看代码评审不回生命周期入口现象更换一个传感器型号走完正常的代码评审和回归测试就发布了。半年后评估方指出该安全功能的论证失效。原因传感器变更影响了失效率数据、诊断覆盖率、共因分析结论也就是回到了 7.4 危险与风险分析和 7.6 分配阶段。只走软件开发流程等于把变更的影响范围人为截断在实现层。解决变更控制流程的第一步是影响范围判定判定依据是追溯矩阵而不是文件目录。凡是触及安全功能边界、完整性等级、分配路径中任意一项的变更强制回到对应的生命周期阶段重新走一遍再向下游传导。6. 设计取舍为什么一般要求只规定「做什么」读完前八章会有一种感觉这份标准几乎不告诉你任何具体做法。它不说该用几取几架构、不说诊断覆盖率要到多少、不说该用什么编程语言只在每个阶段前面写「目标」、后面写「要求」中间的技术手段留空。这个取舍有明确的定位原因。Part 1 被定义为基本安全出版物它的目标读者不只是直接做产品的团队还包括各个产品或应用领域的技术委员会。整套系列的分工是Part 1 给一般要求Part 2 给系统层要求Part 3 给软件层要求Part 4 给术语Part 5 给确定完整性等级的方法示例Part 6 给应用指南Part 7 给技术与措施概览。Part 1 处在最上游必须抽象到能被子标准裁剪而不失真的程度。抽象带来的收益是寿命。技术手段十年换一轮架构模式、编程语言、工具链全都会变但「阶段输出必须可验证」「验证准则必须先于实现」「变更必须回到影响入口」这三条几乎不受技术演进影响。把这三条下沉到 Part 1把具体措施上浮到 Part 2/3/7整套体系可以长期稳定领域标准也能按自己的行业特点替换实现细节。代价同样明显而且就摆在使用者面前合规和真正安全之间存在缝隙。一份追溯完整、文档齐全、每条安全功能都有验证记录的交付物在形式上完全合规但如果危险分析漏了一个工况整条链再完整也只是把一个错误论证得很漂亮。标准能约束的是论证的完整性约束不了论证的前提是否穷尽。所以真正决定项目质量的往往是标准里写得最轻的那一步——7.4 危险与风险分析。这一步没有模板可抄靠的是对工艺、对现场、对人为操作的了解。我见过追溯矩阵做得极其规范但危险清单只有五条的项目也见过文档平平无奇但危险清单列了六十多条、连清洗时的临时接管都算进去的项目后者的实际安全水平不在一个量级上。想验证自己对这套体系的理解到不到位有个成本很低的办法随便找一个在用设备试着写出它的三条安全功能凑齐四要素标上运行模式再反推它能支撑的完整性等级。写不出来的地方就是理解上的空洞。从那以后我每次评审功能安全材料都会先跳过文档结构那一叠直接抽一条安全功能往两头走一遍走到危险清单和验证记录都接上了才回头看格式。这个习惯比通读标准省时间也更接近这套体系真正想固定下来的东西。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 4:12:14 · 阅读 1.2k IEC 61508-1功能安全生命周期与SIL分配证据链解读
简介《IEC 61508-12010 第1部分一般要求》是功能安全领域的基础性国际标准文档适合电气、电子及可编程电子安全相关系统的设计、开发、验证、审查与认证人员使用用于解决安全要求定义、生命周期活动策划及合规依据查找等问题。文件包仅含1个PDF大小约2.11MB标准正文高清可复制且非扫描版条款检索、关键词定位和片段摘录都较方便。内容系统梳理风险评估、安全生命周期、系统架构与冗余、可靠性分析、软件开发、验证确认、变更管理、人员能力及文档记录等通用要求并交代其作为基本安全出版物的定位与适用边界。读者可据此搭建功能安全知识框架也可将其作为项目审查、培训备课和第三方认证准备时对照引用的底稿。已有617人学习下载。1. 一个反直觉的结论IEC 61508-1 通篇几乎不谈技术翻开 IEC 61508-1:2010 的目录八章正文里找不到一行讲冗余电路怎么接、看门狗怎么喂、诊断覆盖率怎么测。这套在功能安全领域被当作顶层依据的一般要求把绝大部分篇幅花在了「谁在什么阶段该产出什么证据」上。初学者常因此觉得它空泛做过一轮完整项目的人反而会觉得它严苛——因为它把「安全」从一种技术属性重新定义成了一条经得起审计的证据链。搞懂这条链条怎么搭起来比背下 SIL 2 对应哪几个数值有用得多。2. 整体安全生命周期为什么十六个阶段之间必须有明确的交接2.1 十六个阶段不是流程图是一张责任交接单IEC 61508-1 第 7 章用十几个小节把整体安全生命周期拆成十六个阶段从概念7.2一路排到停用与处置7.17。很多人第一眼把它当成项目流程模板照着画一条横线就完事这是最容易出错的读法。这十六个阶段的真正形态是一组串行的输入输出契约每个阶段的输出物就是下一个阶段唯一合法的输入。拿前五个阶段举例。概念阶段确定受控设备与被控设备的功能边界整体范围定义阶段把边界内的物理范围、时间范围、运行模式固定下来危险与风险分析阶段在这个边界内枚举危险事件并估算风险整体安全要求阶段把「不可接受的风险」翻译成「必须执行的安全功能及其完整性等级」整体安全要求分配阶段再把每条安全功能切分到 E/E/PE 系统、其他技术措施、外部风险降低措施三条路径上。顺序不可交换的原因很实际危险是相对于边界定义的。同样的超温事件在只考虑正常运行时是一个风险等级在把清机、检修、启动预热也算进范围后可能是另一个等级。如果先做风险分析再补范围定义风险分析的结论会变成一堆无法追溯前提的数字后面整条链都站不住。阶段关键输出物直接下游概念受控设备功能描述、环境条件范围定义整体范围定义边界、运行模式、时间跨度危险与风险分析危险与风险分析危险清单、风险估计、可容忍风险判据整体安全要求整体安全要求安全功能清单 每条功能的 SIL分配、三个前置计划整体安全要求分配分配结果与分配理由E/E/PE 系统安全要求规范这张表的用法不是背而是拿它当检查表任何一个阶段的输出无法逐条指向它在表格里的下游消费者说明这一步实际上没做完。2.2 验证7.18为什么被画成横线而不是方框第 7 章最后一个小节是验证标准正文里给它的定义是「确认某阶段的活动与输出满足该阶段的目标与要求」。注意这句话的主语不是产品是阶段输出。所以它没法画成一个方框接在流程末尾只能横贯所有阶段每个阶段都要配一条验证活动。这个设计带来的直接后果是第 7 章的每个阶段小节几乎都遵循同一套骨架先给 Objective这个阶段要达成什么再给 Requirements达成它必须满足哪些约束。验证活动对照的就是这两段文字而不是对照后面的实现。换句话说标准在逻辑上把「通过判据」和「生产动作」分开了生产动作可以随技术演进而变化通过判据不能。工作里踩过的坑大多出在这里验证被排成了项目末期的集中测试于是验证对象悄悄从「阶段输出是否满足阶段目标」漂移成了「实现是否符合当初的实现」。后一种验证永远能通过因为它自己证明自己。提示判断一个项目有没有真正在做阶段验证最快的办法是抽一条安全功能问它在整体安全要求阶段的验收判据是什么再看现场能不能拿出对应记录。2.3 三张生命周期图的嵌套realisation 阶段被展开两次标准给了三张图。Figure 2 是整体安全生命周期Figure 3 是 E/E/PE 系统安全生命周期Figure 4 是软件安全生命周期。Figure 3 和 Figure 4 都不是独立流程它们是把 Figure 2 中第 10 阶段E/E/PE 安全相关系统实现这一个方框掰开之后的内部结构。这是一个相当克制的分层设计。Part 1 作为一般要求只负责定义「实现阶段必须被展开成更细的生命周期」这件事以及展开后必须满足的目标具体怎么展开交给 Part 2系统和 Part 3软件。好处是分层稳定软件工程实践从瀑布演进到迭代、再到持续集成Part 1 的正文几乎不需要动只要 Part 3 在解释「软件安全生命周期各阶段如何映射到迭代开发」上更新即可。我一般会这么理解这套分层Part 1 定义的是收口条件Part 2 和 Part 3 定义的是收口方式。项目里真正落地时顶层计划书只需要引用 Part 1 的阶段编号把每个阶段的详略和裁剪写在自己的安全计划里再用 Part 2/3 的方法论填内容。这样一次裁剪可以复用到多个产品线不必为每个项目重写一遍生命周期。嵌套的代价也很清楚阶段的边界会因为两次展开而变得模糊。比如软件需求规范到底算整体安全要求的下游还是算 E/E/PE 系统安全要求的下游标准给的答案是后者软件需求必须是系统需求分解的结果而不是直接从危险分析跳过去。这条约束挡住了大量「危害直接变代码」的项目。2.4 三个前置计划为什么运行维护计划要写在设计之前第 7 章有一个非常反常规的安排整体运行与维护计划7.7、整体安全验证计划7.8、整体安装与调试计划7.9这三个阶段被排在了 E/E/PE 系统安全要求规范7.10和实现7.11之前。也就是说东西还没开始设计先要写清楚将来怎么运行、怎么验证、怎么装。这个顺序背后是三个硬约束。第一运行维护计划决定了设计参数。诊断覆盖率能做到多少、proof test周期性功能测试间隔设多长、在线可测还是只能停机测这些直接决定了后续计算出的 PFDavg 或 PFH 能达到哪一个 SIL 区间。先设计再定维护策略等于让架构去追一个还没确定的数字最后往往只能靠加冗余硬凑。第二验证计划前置是标准的「验收判据先于实现」思路。整体安全验证7.14的通过条件必须在实现开始之前写清楚否则验收标准会被实现结果反向塑造。这一点和后来软件工程里强调的测试先行是同一个道理只是这套要求 2010 年就已经是强制项。第三安装调试计划前置是为了防止设计超出场地能力。现场供电、接地、传感器安装位置、调试窗口期这些都会反向压缩设计空间。不少项目的返工不是算法问题是设计做完才发现现场根本没有足够的位置装第二套传感器。三个计划在实现阶段之后还会被反复回填但它们的位置固定在第 5 阶段之后、第 9 阶段之前。位置的固定比内容完备更重要。3. 从危害到 SIL安全要求分配如何把定性风险变成可判定的数字3.1 危害、风险、安全要求是三层不同的东西危险与风险分析7.4产出的是危险事件清单和对应的风险估计。整体安全要求7.5产出的是安全功能。「超温会导致起火」是危险描述「温度超过阈值后 200 ms 内切断加热回路」才是安全功能。这两者之间隔着一层翻译标准要求这一层翻译必须显式写出来不能隐含在分析报告里。一条合格的安全功能描述通常要固定四个要素触发条件输入、期望动作输出、响应时间约束、失效时的行为fail-safe 还是继续运行。少任何一个要素后面的验证就无法判定通过与否。整体安全要求分配7.6是在此之上再加一层这条功能由谁来实现。标准明确允许一条安全功能被拆分给三类实现路径——E/E/PE 安全相关系统、其他技术比如机械泄压阀、化学抑制剂、外部风险降低措施比如物理隔离、操作规程。分配结果必须连同分配理由一起记录因为分配本身就是风险论证的一部分。3.2 分配的本质是「剩余风险的算术」把一个整体风险目标拆到三条路径上做的是概率的组合运算。若三条路径独立整体失效概率近似为各路径失效概率之积的量级若不独立共因失效会把这个乘积抬高一个甚至几个数量级。标准在分配阶段要求考虑共因原因就在这里两条路径如果共用同一个电源、同一套传感器、同一批维护人员它们不是两条独立防线。常见的实现思路是先做粗分把安全功能的主体压到 E/E/PE 路径上用其他技术措施兜住 E/E/PE 路径的共因失效再靠外部措施降低人员暴露概率。粗分完成后再逐条回算看每一条路径承担的完整性目标是否落在可实现区间内。回算发现某条路径要求过高比如要求单通道做到 SIL 4工程上几乎不可行正确做法是回到分配表重新切分而不是在实现阶段硬加冗余。3.3 PFDavg 与 PFH两种量纲对应两种运行模式完整性等级对应的不是「可靠度百分比」而是一个失效概率区间而且区间取值取决于安全功能的运行模式。低要求模式指安全功能的操作频率不大于每年一次、或不大于 proof test 频率的两倍高要求模式和连续模式则按每小时危险失效频率衡量。SIL低要求模式PFDavg按需失效平均概率高要求/连续模式PFH每小时危险失效频率4≥ 10⁻⁵ 且 10⁻⁴≥ 10⁻⁹ 且 10⁻⁸3≥ 10⁻⁴ 且 10⁻³≥ 10⁻⁸ 且 10⁻⁷2≥ 10⁻³ 且 10⁻²≥ 10⁻⁷ 且 10⁻⁶1≥ 10⁻² 且 10⁻¹≥ 10⁻⁶ 且 10⁻⁵两个细节值得单独拎出来。第一区间是左闭右开数值正好等于上界时属于低一级工程上算出来的结果贴着上界评审时基本等同于不达标。第二模式判断发生在功能层面而不是设备层面。同一个控制器里某条安全功能一年触发两次是低要求模式另一条功能持续参与联锁是高要求模式。整台设备只写一个 SIL 数字语义是残缺的这也是现场最常被误读的地方。低要求模式为什么用 PFDavg 而不用 PFH逻辑在于检验周期。低要求模式下安全功能长期处于待命状态危险的隐性失效要等到下一次 demand 或下一次 proof test 才暴露所以关注的是「一次需求来临时它失效的概率」这个概率由检验周期和诊断覆盖率共同决定。高要求模式下功能持续动作失效暴露得快用单位时间的失效频率更自然。3.4 用一段检查脚本把分配结果固定下来分配表在文档里是文字在工具链里应该是一组可校验的数据。下面这段检查逻辑的作用是给定一条安全功能的运行模式和目标 SIL判断分配后估算出的完整性指标是否落在合法区间内。真实项目里这个检查要接在分配评审的出口而不是等项目结束再跑。# 完整性目标区间与运行模式绑定不在设备层面绑定 PFD_RANGES { # 低要求模式按需失效平均概率 4: (1e-5, 1e-4), 3: (1e-4, 1e-3), 2: (1e-3, 1e-2), 1: (1e-2, 1e-1), } PFH_RANGES { # 高要求 / 连续模式每小时危险失效频率 4: (1e-9, 1e-8), 3: (1e-8, 1e-7), 2: (1e-7, 1e-6), 1: (1e-6, 1e-5), } def check_allocation(sil: int, mode: str, achieved: float) - bool: mode 只能是 low 或 highachieved 是分配后估算的指标值 table PFD_RANGES if mode low else PFH_RANGES lo, hi table[sil] # 注意左闭右开achieved 等于 hi 时实际已降级到下一个 SIL return lo achieved hi # 反向用法由估算值反推它能支撑的最高 SIL def max_sil(mode: str, achieved: float) - int: table PFD_RANGES if mode low else PFH_RANGES for sil in (4, 3, 2, 1): if check_allocation(sil, mode, achieved): return sil return 0 # 连 SIL 1 都达不到必须回退重新分配这段代码里真正有价值的是max_sil。正向判断只能回答「达标没达标」反推能回答「这条路径现在最多能撑到几级」后者才是分配阶段要的答案。工程实践中常见的情况是分配表上写了 SIL 3反推出来实际只能到 SIL 2此时正确的动作是回到 7.6 重新切分比如把一部分诊断职责挪到其他技术措施上而不是在实现阶段靠堆冗余硬拽指标。参数说明achieved来自可靠性数据计算通常由元件失效率、诊断覆盖率、检验周期、共因因子共同推导不在 Part 1 的范围内Part 6 给了计算示例。函数里的区间表直接对应标准正文的完整性等级表修改这张表等于修改合规基线评审时必须显式记录版本。4. 文档与功能安全管理证据链是怎么被固定下来的4.1 第 5 章只提了两条要求重量全在附录里正文第 5 章关于文档的要求非常短文档要包含足够信息让执行生命周期活动的人和需要评审、审计的人都能完成各自工作文档要按阶段产出、可追溯、可维护。就这么两句看起来毫无操作性。真正的内容在资料性附录 A 里它给了一套文档结构示例从安全计划开始经危险与风险分析、整体安全要求、分配、各阶段验证记录一直排到功能安全评估报告。附录是「资料性」的意味着不强制照抄结构但它给出了一个绕不过去的东西——文档之间的引用关系。每一份文档都要能回答它引用了谁、被谁引用、对应哪个生命周期阶段。这个设计动机不难猜标准要适配机械、过程工业、医疗、轨道交通等各种领域写死文档模板会立刻失效。只规定关系不规定格式才能让领域标准在裁剪时保留追溯结构而替换文档形态。4.2 第 6 章管理的不是进度是能力和配置功能安全管理第 6 章常被理解成「成立一个安全委员会、开几次会」。实际要求指向三件更具体的事责任与权限的明确划分、参与人员的能力证据、贯穿生命周期的配置管理与变更控制。能力证据这一条最容易被忽略。标准要求的不是培训签到表而是能说明「这个人具备完成该项活动所需的技术能力」的记录且要与其承担的具体活动对应。做危险与风险分析的人和写软件单元测试的人能力证据的内容完全不同。配置管理在 Part 1 里的地位比想象中高。它要求所有安全生命周期输出物纳入配置管理包括工具、库、第三方组件。理由很直接功能安全的论证建立在「当时那一版」之上任何未经控制的变更都会让论证失效。这也是为什么很多项目的功能安全评估卡在工具链版本上——评估方要确认分析时用的建模工具版本和最终交付版本一致。4.3 追溯矩阵评估现场唯一能翻的东西把前面几章串起来看整条链的产物就是一张追溯矩阵危险 → 安全功能 → 完整性等级 → 分配路径 → 系统需求 → 软硬件需求 → 实现项 → 验证记录 → 评估结论。矩阵的每一行是一条完整论证每一列是一个阶段。这张矩阵的价值不在于好看而在于它能被机器检查。现场评审时最有效的一招是抽一行正向走到验证记录、反向走回危险清单任何一处断开都说明论证不完整。# 追溯链的最小闭环检查每条安全功能都必须有目标等级和验证记录 def audit_chain(functions, verifications): functions: [{id: SF-07, sil: 3, mode: low}, ...] verifications: {SF-07: [VR-07-01, VR-07-02], ...} 返回缺口列表空列表代表这一层闭合 gaps [] for fn in functions: if fn.get(sil) is None: gaps.append((fn[id], 未分配完整性等级回到 7.6)) if fn.get(mode) not in (low, high): gaps.append((fn[id], 运行模式未定义量纲无法确定)) if not verifications.get(fn[id]): gaps.append((fn[id], 无验证记录阶段输出未闭合)) return gaps代码之后要说明的是执行时机这个检查不是交付前跑一次而是在每个阶段的出口跑一次。阶段出口的缺口数量是最直观的进度指标比文档完成率可靠得多。参数mode缺失之所以单独报出来是因为量纲缺失会让后面所有数值比较失去意义这类错误在早期发现只需要改一行晚期发现要重做整套可靠性计算。5. 避坑五条反复出现的现场问题5.1 把 SIL 等级当成整机属性现象规格书首页写着「本产品满足 SIL 3」问是哪几条安全功能达到 SIL 3、运行模式是什么答不上来。原因SIL 挂在安全功能上安全功能挂在具体的受控设备与被控设备组合上。整机不具备 SIL 属性只有「在某应用场景下执行某条安全功能」才具备。厂商宣传语和工程论证说的是两件事。解决规格书里只写「可用于构建最高 SIL x 的安全功能」并附上安全功能清单、运行模式、以及使用限制条件。评审时按清单逐条核对不接受整机口径的结论。5.2 危险分析做完直接进设计跳过整体安全要求现象危险清单做得很细代码也写了但问某条安全功能的响应时间约束只能回答「实测大概几十毫秒」。原因危险描述被直接当成了需求。危险说「超温导致起火」需求要说「超过 T 阈值后 200 ms 内切断加热」。「大概几十毫秒」不是一个可验证的判据验证阶段只能记录实测值无法判定通过与否。解决在 7.5 和 7.10 之间加一道硬门槛每条安全功能必须凑齐触发条件、期望动作、响应时间、失效行为四要素才允许进入下游。凑不齐的退回危险分析重新推导。5.3 验证准则在实现完成之后才写现象验证报告全部通过但报告里的判据和设计文档里的描述几乎逐字相同。原因验证准则定义晚于实现写准则的人手里只有实现结果只能照着写。这时的验证已经退化成确认不再具备发现偏差的能力。解决把 7.8 的整体安全验证计划作为实现阶段的前置交付物验证准则必须能追溯到 7.5 的安全功能描述而不是追溯到 7.10 的系统需求。追溯方向反了独立性就没了。5.4 文档在项目末期集中补齐现象评审前两周集中写文档交付的文档体系看上去完整但版本号和代码仓库对不上。原因文档被当成交付物而不是过程产物。功能安全论证依赖的是「某个阶段当时依据的信息」事后补写的文档写的是「最终记得的情况」两者之间存在不可恢复的信息损失。解决文档按阶段出口产出纳入配置管理与代码、模型、工具版本绑定同一个基线号。任何一份文档如果无法指出它对应的基线视为不存在。5.5 修改只看代码评审不回生命周期入口现象更换一个传感器型号走完正常的代码评审和回归测试就发布了。半年后评估方指出该安全功能的论证失效。原因传感器变更影响了失效率数据、诊断覆盖率、共因分析结论也就是回到了 7.4 危险与风险分析和 7.6 分配阶段。只走软件开发流程等于把变更的影响范围人为截断在实现层。解决变更控制流程的第一步是影响范围判定判定依据是追溯矩阵而不是文件目录。凡是触及安全功能边界、完整性等级、分配路径中任意一项的变更强制回到对应的生命周期阶段重新走一遍再向下游传导。6. 设计取舍为什么一般要求只规定「做什么」读完前八章会有一种感觉这份标准几乎不告诉你任何具体做法。它不说该用几取几架构、不说诊断覆盖率要到多少、不说该用什么编程语言只在每个阶段前面写「目标」、后面写「要求」中间的技术手段留空。这个取舍有明确的定位原因。Part 1 被定义为基本安全出版物它的目标读者不只是直接做产品的团队还包括各个产品或应用领域的技术委员会。整套系列的分工是Part 1 给一般要求Part 2 给系统层要求Part 3 给软件层要求Part 4 给术语Part 5 给确定完整性等级的方法示例Part 6 给应用指南Part 7 给技术与措施概览。Part 1 处在最上游必须抽象到能被子标准裁剪而不失真的程度。抽象带来的收益是寿命。技术手段十年换一轮架构模式、编程语言、工具链全都会变但「阶段输出必须可验证」「验证准则必须先于实现」「变更必须回到影响入口」这三条几乎不受技术演进影响。把这三条下沉到 Part 1把具体措施上浮到 Part 2/3/7整套体系可以长期稳定领域标准也能按自己的行业特点替换实现细节。代价同样明显而且就摆在使用者面前合规和真正安全之间存在缝隙。一份追溯完整、文档齐全、每条安全功能都有验证记录的交付物在形式上完全合规但如果危险分析漏了一个工况整条链再完整也只是把一个错误论证得很漂亮。标准能约束的是论证的完整性约束不了论证的前提是否穷尽。所以真正决定项目质量的往往是标准里写得最轻的那一步——7.4 危险与风险分析。这一步没有模板可抄靠的是对工艺、对现场、对人为操作的了解。我见过追溯矩阵做得极其规范但危险清单只有五条的项目也见过文档平平无奇但危险清单列了六十多条、连清洗时的临时接管都算进去的项目后者的实际安全水平不在一个量级上。想验证自己对这套体系的理解到不到位有个成本很低的办法随便找一个在用设备试着写出它的三条安全功能凑齐四要素标上运行模式再反推它能支撑的完整性等级。写不出来的地方就是理解上的空洞。从那以后我每次评审功能安全材料都会先跳过文档结构那一叠直接抽一条安全功能往两头走一遍走到危险清单和验证记录都接上了才回头看格式。这个习惯比通读标准省时间也更接近这套体系真正想固定下来的东西。希望帮到你。本文还有配套的精品资源点击获取