IEC 61508-1:2010功能安全解读：安全生命周期与SIL分配

简介：IEC 61508-1:2010《电气/电子/可编程电子安全相关系统的功能安全 第1部分：一般要求》是功能安全领域的基础性标准，面向从事E/E/PE安全相关系统设计、开发、验证与维护的工程师、项目经理及安全评审人员，也为产品与应用部门标准的制定提供统一框架。资源包内共1个PDF文件，大小约2.11MB，为高清可复制的非扫描版，便于检索引用标准条款。当前已有615人学习下载。标准内容系统覆盖风险评估、全生命周期管理、系统架构与冗余设计、可靠性分析、软件开发质量保证、验证与确认、变更管理、人员资质、文档记录及合规性评估等核心要求，并附有大量术语定义与实施指南，可作为功能安全认证、产品开发及内部培训的案头参考。标准以系统化方法统筹安全要求与技术实现，清晰界定了安全完整性等级的分配与验证路径，对过程工业、机械、轨道交通等领域的工程实践具有直接指导意义。第二版相比1998年第一版做了全面技术修订，充分反映了技术进步与行业最佳实践，适用性更广。

1. 先搞清 IEC 61508-1：2010 Part 1：它给的是流程，不是参数

功能安全圈里有句玩笑话：读完 IEC 61508-1：2010 Part 1：General requirements 的人，第一反应往往是“好像什么都说了，又好像什么都没说”。这不是你的理解力问题，是这份标准的定位问题。它尽力避免给出具体数字和计算公式，因为那些内容被刻意拆到了 Part 2、Part 3 和 Part 5；Part 1 只负责回答三个更前置的问题：谁来为安全负责、按什么顺序做、每一步留下什么证据。

如果你正在负责一个需要过功能安全评估的产品，第一份该精读的文本就是它。它能帮你把“我们要做功能安全”这句口号，翻译成“先出危险分析报告、再出安全要求规格书、最后做验证记录”这样可执行的文件清单。这篇文章就按这条主线走：先讲 Part 1 的骨架，再给模板与避坑点，最后给你一个审查前自查的技巧。

2. 安全生命周期是主骨架：把 16 个阶段映射到条款顺序与交付物

2.1 为什么 Part 1 按“生命周期”组织，而不是按“电路”组织

很多工程师第一次读这份标准时，习惯性地去找“我的传感器电路应该怎么设计”“软件要跑多快才算安全”，结果发现找不到。这不是标准写得空，而是它一开始就不打算按硬件模块来讲。原因很直接：安全不是某一个元器件的属性，而是产品从概念、设计、生产、运行到退役整个过程中，风险始终被控制在可接受范围的状态。

Part 1 把产品的一生切成了若干个阶段，每个阶段都要求你回答一组固定问题：这个阶段的风险是什么、要满足什么安全要求、用什么方法验证达到了要求。这种组织方式的好处是它不绑定任何具体技术。你今天用继电器搭安全链，明天换成可编程逻辑控制器（PLC），后天再用单片机实现，标准要求你完成的阶段动作是一样的。

我最初读的时候也犯过同样的错：拿着 Part 1 当产品设计手册去查，越查越焦虑。后来意识到，这份 PDF 里几乎每条要求背后都对应“某个角色在某个时点要做某件事并留下记录”。想清楚这一点，再回头看条款顺序，就顺了。

2.2 十六个阶段与每个阶段的关键输出

下表按主流的解读习惯，把安全生命周期拆成 16 个阶段。其中前 5 个阶段属于“分析侧”，决定你要做什么；中间是“实现侧”，决定你怎么做；后面的阶段属于“验证与运行侧”，决定你怎么证明它有效。

你注意看，整个生命周期里，真正“写代码、画原理图”的只有第 9 阶段。剩余阶段全部是分析、计划、验证和管理动作。这正是 Part 1 被称为“一般要求”的原因：它把大部分篇幅花在保证“在正确的时间做了正确的事”，而不是规定某个电路怎么搭。

实际项目里，我不建议直接拿这 16 个阶段去套进度计划，因为很多阶段会并行或迭代。我更常做的是先把上述表格中的“典型输出文档”列成一个交付物清单，再按项目里程碑反推每份文档最晚什么时候要定稿。你会发现，最容易拖期的不是设计文档，而是阶段 3 的危险分析报告——它没写完，后面所有安全要求都是空中楼阁。

2.3 用 V 模型理解两条活动链

这 16 个阶段如果画成图，通常被整理成 V 模型：左半边从上到下是“概念 → 危险分析 → 整体安全要求 → 安全要求分配 → 系统实现”，右半边从下到上是“部件验证 → 集成验证 → 整体安全验证 → 运行监控”。Part 1 的条款排列基本沿着这个逻辑走，左半边强调“你要把要求写清楚”，右半边强调“你要把证据收齐”。

V 模型最大的作用不是画图好看，而是让你一眼看出“断层”在哪。如果左半边的安全要求只写了一句“系统应防止超压”，但没有给出允许的失效概率或 SIL 等级，那么右半边的验证根本无从下手，因为你不知道验证到什么程度算通过。反之，如果验证计划写得非常详细，但危险分析里漏掉了一个高频危险场景，那所有验证工作都在证明一个错误的目标。

理解了这个结构，你再看任何一份功能安全文档，都会先问一句：“这份文档在 V 模型哪一侧？它对应哪个阶段？输入是什么？输出给谁？”这个问题能帮你快速判断一份文档是没写完，还是本来就不该在这个阶段出现。

3. 把条款翻译成交付物：安全管理、SRS 与验证证据的三套模板

3.1 功能安全管理：先定角色，再谈技术

Part 1 开篇没多久就进入“功能安全管理”部分。这部分常被新手跳过，因为读起来像管理体系文件，不像技术内容。但实际审查中，我发现评估机构最喜欢先看的就是这一块——他们要先确认你这个项目有没有人负责安全、职责是否清晰、能力是否匹配。

常见做法是把安全管理落到一份《安全管理计划》（Safety Management Plan, SMP）里。这份文档不需要写得像制度汇编，但要明确回答四个问题：项目经理是谁、安全经理是谁、安全相关活动的评审人是谁、每个角色的能力要求是什么。特别是“能力”这一项，很多项目写“由有经验的工程师担任”，这种描述在正式评估里容易被挑战——什么叫有经验？建议写成“具备 3 年以上同类产品开发经验，并完成功能安全基础培训”，让它可以被记录和验证。

另一个容易漏的是“质量体系与功能安全活动的关系”。如果你的公司已经有 ISO 9001 之类的质量体系，SMP 里要说明安全管理活动哪些是复用现有流程，哪些是额外补充。这里我踩过坑：把两份体系完全并列，结果同一份设计文档要过两套评审，项目进度直接失控。更顺滑的做法是让功能安全活动嵌入现有评审节点，只是在评审清单里增加安全相关检查项。

3.2 安全要求规格书（SRS）的章节骨架

安全要求规格书是左半边的核心交付物，也是评审老师最常逐条核对的文件。很多第一次写 SRS 的人会把它写成“产品需求文档”的翻版，罗列一堆功能，却没有把每个功能与危险场景挂钩。这样写的后果是：验证阶段根本没法追溯，因为每个安全要求都得回答“它对应哪个危险事件、失效后会造成什么后果”。

下面是一份我常用的 SRS 章节骨架，你可以直接拿来当大纲用：

重点是第 4 章和第五章的联动。第 4 章写“目标”，第 5 章写“怎么实现”，两者不能脱节。比如第 4 章定了“防止压力容器超压”这个目标，第 5 章就必须出现对应的安全功能“检测压力超过阈值且持续超过 200ms 时，切断加热电源”。如果第 4 章有目标、第 5 章找不到对应功能，审查时这就是一个不符合项。

响应时间这类参数要写具体，不要写“尽快”。我见过一条要求写“压力异常时应尽快切断电源”，等到了验证环节没人能说清楚“尽快”是多快，只能回头改 SRS 重新评审。所以从第一版开始，所有响应时间、阈值、精度都要给数值和单位，哪怕后面要更新。

3.3 验证活动怎么留证据：计划、报告与独立性

验证不是测试做完才算开始，而是从计划阶段就要落笔。Part 1 对验证的要求层层递进：先写验证计划，再按计划执行并生成报告，同时验证者要有一定独立性。

验证计划里至少要有三部分内容：验证对象清单、每项的验证方法、通过准则。方法可以选评审、测试、分析或相似设计类比，但要写明为什么选这个方法。比如安全功能靠软件实现，通常既要代码走查，也要功能测试；如果只写“测试”，评估老师会问“你怎么知道没有遗漏的分支逻辑”。

独立性是另一个高频问题。标准给了三个梯度：独立于设计者的人、独立于设计部门的人、独立于组织的机构。项目预算有限时，最常见的做法是第一层独立性——由另一位没参与该模块设计的同事执行验证。这里要注意，哪怕同属一个部门，也必须能证明这位同事没有参与该模块的设计评审和代码编写，否则验证记录会被视为无效。

我在实际项目里会把验证报告做成“一条安全功能一个章节”，每个章节开头附上该功能在设计文档中的位置索引，结尾附测试环境与结论。这样评估老师按 SRS 的目录一条条看下去，不需要来回翻文档，沟通成本低很多。

4. 读标准时的常见问题排查：5 个最容易跑偏的理解与纠正

4.1 把 Part 1 条款当 checklist 逐条打勾

现象：项目组拿着 Part 1 的目录，逐条核对自己“做了没”，每条都打勾，自认为符合要求，结果正式评估时还是开出一堆不符合项。原因是标准里的要求往往带条件，不是每个项目都触发同样的条款。比如部分条款只适用于“安全相关系统”，如果你的产品里有一个与安全无关的普通功能模块，硬套条款反而会给自己增加不必要的工作量。

解决：不要从条款反推工作，而要从危险分析反推条款。先把产品可能造成的伤害场景列清楚，再确定哪些功能是安全功能，最后只对这些安全功能及其生命周期活动应用相应条款。把 Part 1 当作“找漏”的检查工具，而不是“生成工作”的模板。

4.2 只读 Part 1 就动手做 SIL 验证

现象：把 Part 1 里对 SIL 的描述当成全部规则，拿着一个系统开始算可靠性和诊断覆盖率。原因是没注意到 Part 1 是总纲，具体到硬件架构约束、软件安全生命周期、诊断覆盖率计算方法，都在 Part 2 和 Part 3 里。只看 Part 1，很多事情连参数都找不到。

解决：读 Part 1 之前先想清楚你的项目要按哪条行业标准裁剪。流程行业会去读 IEC 61511，机械行业看 ISO 13849，汽车行业是 ISO 26262，这些标准都从 IEC 61508 衍生而来，同时把总纲里的要求细化了。如果你的产品不属于任何细分行业，就直接把 Part 1 + Part 2 + Part 3 + Part 5 四本一起组成最小阅读集，缺一不可。

4.3 把安全功能等同于所有保护性功能

现象：设计文档里把所有带“保护”“监测”“报警”字样的功能都分类为安全功能，SRS 越写越长，验证工作量爆炸。原因是没区分“安全功能”与“辅助功能”。安全功能的定义是：当它失效时，会直接导致或无法减轻危险事件。而一个报警灯，即使坏了，系统还有独立的安全链兜底，它就不该算安全功能。

解决：做安全功能识别时，逐个问“如果这个功能失效，危害会不会发生”，如果答案是不确定，再问“有没有另外一套机制能防止危害”。有兜底机制的，归类为辅助功能，不进 SRS 的安全功能清单。这样一来，安全功能的边界收窄了，后续 SIL 分配、硬件计算的精力才能集中在真正重要的链路上。

4.4 独立验证做成“自己验证自己”

现象：验证报告里写验证人是该模块的设计者本人，或者验证人和设计人座位挨着，共用同一套测试用例。原因是项目组人手不足，默认“自己最了解自己的设计，验证效率最高”。结果是在评估时被质疑取证有效性，测试结果不被认可。

解决：哪怕在小团队里，也至少让另一位同事做交叉验证，并记录下他没有参与该模块设计的证据。如果实在抽不出人，退而求其次的方法是让验证人自己写“自查声明”，但要在验证计划里提前说明为什么采用这种降级方案。最忌讳的是验证计划写得漂亮，执行记录却暴露验证人就是设计人，这种前后矛盾在审查现场几乎无法解释。

4.5 跳过风险分析直接“借鉴”别人的 SIL 定级

现象：看到一个同类产品用了 SIL 2，于是给自己的系统也定为 SIL 2，理由是“大家都这么做”。原因是没理解 SIL 不是产品的固有属性，而是针对特定风险场景、由风险降低需求推导出的结果。使用场景不同、频率不同、后果不同，SIL 就不同。

解决：从危险分析报告里找每个危险事件的频率和严重度，按 Part 5 推荐的方法做风险矩阵，得出每个事件需要的风险降低量，再换算成每个安全功能的 SIL。这个过程确实花时间，但它决定了硬件冗余要几重、诊断要做多深，过早拍脑袋定 SIL，后面改架构的代价远大于前期分析的成本。

5. 安全要求分配：从整体安全要求到每个安全功能的 SIL 怎么拆

5.1 先分清需求模式：低要求模式 vs 高要求模式

Part 1 里的 SIL 不是一个简单的数字，它绑定“需求模式”这个概念。低要求模式指安全功能一年内被请求的次数不超过一次，比如大多数紧急停机系统；高要求或连续模式指功能频繁被请求，甚至一直在线运行，比如连续工作的温度监控回路。同一个 SIL 等级，在两种模式下对应的量化指标差别很大。

这个区分直接决定你怎么计算和验证。低要求模式看的是平均失效概率（PFDavg），关注点是在“需要时能不能动作”；高要求或连续模式看的是每小时失效概率（PFH），关注点是在“持续运行过程中会不会误动或漏动”。如果你的产品既被当紧急保护用，又频繁参与正常控制，那要按高要求模式来考核，指标会更严苛。实际项目里这块容易翻车：明明是紧急停机按钮，统计请求频率时发现操作员每个班次都会用它来正常停机，结果发现需求模式其实应该按高要求重新计算。

5.2 SIL 四个等级的量化目标

Part 1 给出了四个 SIL 等级对应的量化范围，这是标准里少见的具体数字，也是之后所有计算的落脚点。下面这张表值得保存在手边：

注意这张表不能用来“证明”你的系统是 SIL 几级，而是用来做“目标管理”。比如你在分配阶段给一个紧急停机功能定了 SIL 2，意味着后续的硬件设计要让整个安全功能的 PFDavg 落在 1E-3 到 1E-2 之间，并且软件部分要达到相应的系统化能力等级。这个目标要写进 SRS，设计人员才知道自己要做什么。

5.3 安全功能分配表怎么填：一个过压保护示例

把整体安全要求拆到具体安全功能时，我一般会建一张“安全功能分配表”，每一行承载一个安全功能。下面用一个假想的压力容器过压保护场景做演示，注意这里只展示分配方法，不涉及具体电路。

这张表一旦填完，后续 Part 2 的硬件架构设计和 Part 3 的软件设计就都有了输入。SIL 2 的要求通常意味着至少要考虑一定的硬件故障约束和诊断覆盖，不能像 SIL 1 那样用简单单通道结构就收工。这些细节不在 Part 1 里展开，但分配表会把需求明确地传导给下游。

填表时最容易犯的错是“一行填多个功能”。如果一个触发条件导致两个独立动作，比如既切断加热又打开泄压阀，这其实是两条安全功能，因为它们可能由不同部件执行，失效模式也不一样。强行合并成一行会让自己在后续验证时说不清“失效”到底指哪一半。

6. 一个我在审查前必用的技巧：用追溯矩阵找文档断层

6.1 追溯矩阵的最小列与每列必须回答的问题

我拿到一个新项目的第一件事，不是翻原理图，而是先看有没有需求追溯矩阵。这份矩阵不需要复杂的工具，一个表格就能承载，核心是让每个安全需求从头到尾都有迹可循。

有了这个表，审查前的自查就变成机械劳动：逐行扫过去，任何一列出现空白，就意味着一个断层。最常见的断层是“SRS 里写了需求，设计文档里找不到实现”，其次是“实现了但验证报告里没有对应条目”。这两个断层在审查现场都是必开不符合项的。

我在项目实践中会把矩阵的一部分在需求阶段就开始填，而不是最后补。每写一条安全需求，就在矩阵里加一行，哪怕设计出处和验证记录暂时空着。等设计完成，再逐行补设计出处；验证收尾，再补记录编号。整个过程变成三次填空，而不是一次突击整理。这个习惯帮我躲过不少通宵补文档的夜。

你也可以把矩阵做成两份：一份完整版用于归档，一份精简版用于周会同步。精简版只保留前三列和最后一列，让项目成员快速看到每个安全功能当前的验证状态。评审老师来的时候，直接打开完整版，按列过滤，所有断点和空白一目了然。希望这个矩阵习惯能帮到你，也祝你的项目在审查时少一些“惊喜”，多一些从容。

本文还有配套的精品资源，点击获取