简介IEC 61508-1:2010 是功能安全领域的基石标准面向电气/电子/可编程电子E/E/PE安全相关系统的设计、开发、验证与维护人员。该标准系统阐述了从风险评估、生命周期管理到系统架构、软件开发、变更管理等通用要求为缺乏产品或应用部门标准时的功能安全工作提供了通用框架。这份 PDF 为 2010 年第二版正式国际标准内容高清可复制非扫描版共 1 个文件压缩包大小 2.11MB方便直接检索与引用。目前已有 615 人学习下载。通过阅读可快速掌握 IEC 61508-1 的术语定义、总体流程与合规评估思路适用于功能安全工程师、认证人员以及撰写产品安全方案的技术团队作为权威依据。建议结合第 27 部分配套使用以完整支撑安全生命周期各阶段的活动。1. 先别急着翻SIL等级IEC 61508-1到底在管什么拿到《IEC 61508-12010_Part 1General requirements.pdf》这份标准大部分人的第一反应是去查SIL等级分配表或者找安全完整性等级的判定门槛。真到用的时候才发现Part 1作为整个IEC 61508系列的总纲压根不是只讲SIL怎么算它最狠的地方是把一个安全相关系统从概念设计到退役的全生命周期活动全部框死了一遍。当年我做某图像处理Demo的升级改造以为只要把安全功能做到“看起来够可靠”就行结果被审核员问住了你的安全需求规格书是按Part 1的7.2章节结构写的吗验证计划里有没有覆盖每个V模型阶段彼时我连这些条目对应什么都没翻过只能现场认怂、回头补课。这份PDF值不值得精读答案是如果有半点念头想把产品做成功能安全相关系统就必须把它从头到尾啃干净。Part 1不教你具体算失效率也不给各种冗余架构的公式那些是Part 2和Part 6的地盘它给的是框架、流程和证据链你该在什么时候做什么事、留什么记录、以什么标准评审。换句话说它把“怎么证明你的产品在功能安全上不是黑匣子”这件事程序化了适合系统架构师、项目经理、测试工程师、甚至现场维护的仪表工程师读。插一句关于标准的适用边界IEC 61508-12010是通用功能安全基础标准特定行业还在它基础上派生了自己的版本。做核电看IEC 61513、做流程工业看IEC 61511、做机械看ISO 13849但不管哪个分支源头都绕不开Part 1这套生命周期管理逻辑。这篇笔记就按正文顺序把“整体框架—安全生命周期—SIL分配—文档化和验证—避坑”这几条线讲清楚常年在项目里反复踩的坑也会一并披露。2. 安全生命周期与V模型Part 1的骨架也是审核最爱考的点2.1 从概念到退役安全生命周期到底切了几刀IEC 61508-1的正文结构很清晰第7章“安全生命周期”占了整份标准近一半的篇幅。这一章把系统从“想法”到“报废”切成了若干个阶段每个阶段有指定的输入、活动、输出和验证要求。常见做法是把这些阶段归纳为概念设计、整体范围定义、危险与风险分析、整体安全要求分配、安全要求规格书、设计实现、安装调试、运行维护、退役。每一刀都对应一个文档产出这和我以前以为“只要最后拿来测试通过就算安全”的粗糙认知完全是两码事。标准里明确讲了两种生命周期视角整体安全生命周期Overall Safety Lifecycle和E/E/PE系统安全生命周期。前者面向整个受控设备或流程后者聚焦于具体的安全相关控制系统。做产品开发的通常两者都要走一遍——先做系统级的危险分析和风险降低再把安全功能落到自己这套软硬件上实现验证。很多团队只在第二个视角里忙活结果既漏了系统级的假设前提又没法证明自己执行的验证活动确实降低了整体风险属于典型的本末倒置。我一般建议团队在第一遍消化这份标准时先把标准中图2和图3的生命周期段复制出来作为工作底稿在每个阶段后面写上“本阶段我要输出什么文档”和“验证这个文档的输入来自哪里”。实际上这个表就是你们整套功能安全认证的证据清单。在模拟项目X里我们就是这么干的——把生命周期阶段做成一张Excel看板什么阶段该出什么文档一目了然审核员来看时直接打开对应格子快速就对上了。2.2 V模型与验证活动每一层都得有对应的验证证据Part 1对“验证”的要求可以用一句话概括每个生命周期阶段的活动都要有对应的验证活动且验证发现的不足要留痕、闭环。这就是常说的V模型左侧是需求逐层分解右侧是逐层集成验证需求从哪个阶段来验证就回哪个阶段去。软件部分的具体执行在Part 3但Part 1的7.8节把硬件和软件集成的验证要求框得很细尤其是软硬件集成测试证据需要能追溯到安全要求规格书中的每一条。实际做的时候最容易漏掉的是“验证计划”本身。Part 1要求每个阶段都得有验证计划内容包括验证对象、方法、通过准则、责任人、工具环境。很多项目的做法是项目都快交付了才补一份总验证计划里面全是“已验证/合格”的空洞结论——这比没做还糟糕因为审核员一眼就能看出你是在“补卷子”而不是在“做验证”。见惯了这种翻车现场后我对团队的要求变成了每个阶段开工前先写验证计划哪怕一页纸也行重点写清楚怎么证明这个阶段的输出达到了它定义的输入要求。再提一个容易被忽略的验证方法分类。IEC 61508-1把验证方法分为“分析”和“测试”两大类维修过程中的修改、异常工况下的表现、甚至人为误操作都应该有对应的验证活动覆盖。有些团队测试用例做得密密麻麻却没有任何危险分析与风险评估的记录来证明为什么要测这些用例缺失了完整链条。标准讲究的是完整证据链“测得多”不如“测得有依据”这个观念越早建立越好。2.3 功能安全管理计划、评审、变更一个都不能少Part 1第八章讲功能安全管理这一章内容看起来“软”实际审核时问得最细因为它是整个生命周期的“监理角色”。核心要求有三条第一必须有安全管理计划说明谁在什么时间用什么资源做什么安全活动第二必须有独立评审机制评审人不能是干活的人自己第三必须有变更管理流程所有安全相关变更要走影响分析和回归验证闭环。尤其是独立评审这一条小公司落实起来很痛苦。就那么五六号人怎么做到文审分离常见的做法是让做硬件的人审软件的需求追溯性让测试的人审系统架构文档实在不行就请外部顾问当独立评审员。标准本身没有规定“独立”必须是物理上不同公司而是强调“独立性充分”所以内部交叉评审配合评审记录也能满足要求。最怕的是评审只是走过场记录上写着“同意”却没有实质修改意见这反而是审核员最反感的形式主义。变更管理大概是在役系统最痛的点。设备上了现场跑得好好的某天操作员嫌报警阈值太灵敏让改一个参数结果你改了参数却没有评估这个变更对SIL等级的影响——这种事在流程工业现场太常见了。IEC 61508-1的意图很直白安全相关参数改之前要有变更申请改之后要做回归验证整套记录都要存档。这套机制看着麻烦实则在真正出了事故复盘时可以保护整个项目组你有证据链证明这个变更是经过评估、验证和批准的还是背着组织偷偷改的性质完全不一样。3. 从危险分析到安全要求规格书把SIL从口号变成硬指标3.1 危险与风险分析没有这一步后面的SIL都是空中楼阁Part 1对安全功能要求的源头是危险与风险分析所以七章第2小节先把方法选项列了一遍。常见的危险分析方法包括HAZOP危险与可操作性分析、FMEA失效模式与影响分析、故障树分析等。标准没有强制你必须选哪一种但要求你以结构化的方式识别危险事件、评估风险、确定风险降低的必要程度。实际做项目时多数情况下是几种方法混合用——先拿HAZOP把过程危险捋一遍再对特定安全功能做FMEA要是还要评估多个系统组合导致的共因失效再补一个FTA。这个环节最容易犯的错是团队一边做危险分析一边在心里已经预设了答案——“这个功能肯定要SIL 2”。在预设前提下凑分析和数据得出的结论自然就“刚刚好是SIL 2”。这也是功能安全前几年在圈内被嘲讽为“靠PPT凑证据”的核心原因所在。正确做法是先不带结论做分析把危险事件、起因、后果、现有防护措施都列干净然后再按标准选择的算法评估残余风险看它是否落在可容忍范围内最后推导出SIL需求推导链条每一步都有据可查。一个具体的坑危险分析把“人为误操作”当作了一个安全功能需要应对的起因但分析时却没有定义操作人员的能力和培训前提。结果系统设计按“操作员绝不会在3秒内连续按错两个按钮”来假设逻辑上站不住。审核时对方直接问你这个假设是哪里来的当时项目组被问得鸦雀无声——这种假设必须来源于明确的操作员模型或人因分析而不是拍脑袋。所以写完危险分析不妨反过来自查一遍哪些风险降低措施隐含了对人的行为假设这些假设是否被写进了约束条件3.2 安全功能分配与SIL等级看懂目标失效量那张表如果只看一页IEC 61508-1那多半是SIL等级与目标失效量对应表。这张表把SIL 1到SIL 4分别对应了安全功能在低需求模式下和高需求模式下的目标失效概率/失效率。低需求模式看的是“每十年里需求发生时功能失效的概率”高需求模式看的是“每小时危险失效概率”。同一个SIL等级两种模式下的量化指标完全不同千万别跨模式比对数据。理念也不复杂安全功能不是越“快”越好而是要在“需求真正到来时”足够可靠。SIL 1对应低需求模式10^-1到10^-2的失效概率SIL 2对应10^-2到10^-3SIL 3对应10^-3到10^-4SIL 4是10^-4到10^-5。乍一看SIL 4比SIL 1严格了一千倍实际做起来影响是爆炸式的到了SIL 3以上常见的单通道PLC架构就基本算不过来了必须上冗余比较、诊断覆盖率很高的方案而且软件部分还得上形式化方法级别的证据支撑。绝大多数项目做到SIL 2、SIL 3就差不多了SIL 4多见于核电、航空这些特殊领域。见过有人一上来就说“我们这功能要做SIL 4”多半是把“安全等级高”和“SIL 4”两码事搅在一起了。一定要分清楚“整体SIL”和“系统SIL”的差异。Part 1反复提醒同一套设备可能承担多个安全功能每个安全功能有自己独立的SIL要求。整个设备本身不存在“某一个”笼统的SIL等级除非所有安全功能恰好都在同一等级。实际项目中经常看到甲方招标文件写“本系统满足SIL 2”但到了功能安全规格书阶段却发现里面混杂着SIL 1、SIL 2、SIL 3三个不同等级的安全功能。这说明需求阶段就没按标准拆清楚后面整个生命周期都得为这个模糊买单。3.3 安全要求规格书Part 1的精髓也是全文信息密度最大的一节安全要求规格书Safety Requirements SpecificationSRS是整个Part 1里我认为信息密度最高的一节。它把“安全功能要求”和“安全完整性要求”分成两条线功能要求描述的是“系统做什么”——检测到超压时在2秒内关闭阀门完整性要求描述的是“做得有多可靠”——该功能要满足SIL 2。两者缺一不可也不能混为一谈。实际踩过最典型的坑是团队把安全功能描述写得洋洋洒洒比如“紧急停车时切断所有输出”但压根没写这个功能要在多长时间内完成也没写检测到故障后系统的目标状态是什么这根本没法验证。标准明确安全要求规格书要包含这些主题安全功能的功能行为、实现方式约束、诊断覆盖率相关要求、响应时间、降级模式、操作员接口、软件系统安全要求、以及维修设计需求等。换句话讲它应该是后续硬件设计、软件开发、测试验证、现场验收共同的“唯一需求源头”。你在V模型左侧写下的每一行设计源头都要能追溯到SRS里的某一条。后续做FTA、FMEDA、可靠性建模也是以SRS里对每个安全功能分配的SIL为基准。写SRS的实操技巧把每条需求写成一个可测试的条目格式为“当[触发条件]发生时系统应在[时间]内完成[动作]目标安全状态为[状态描述]本条需求对应SIL X”。禁止写“应具有可靠的超压保护功能”这种模糊表述。A同学当年在项目里检查同事写的SRS看到一条“系统应能检测供电异常”直接退回检测什么异常电压低于多少伏算异常检测到以后做什么用什么方式指示全部没说清这条需求从源头就废了。没经验的团队写SRS时建议开个强制评审会邀请测试工程师和现场维护的人一起参加——他们的视角最能抓出“不可测试”或“维护不了”的废需求。4. 文档化落地按Part 1的框架搭一套能过审的项目卷宗4.1 文档框架怎么搭结构上对齐标准内容上各行其道IEC 61508-1对文档化的要求散见于多个章节第5章讲文档化总体要求第7章每个阶段都标注了“输出文档”第8章要求计划类文档、记录类文档、评审类文档各归其位。实际做文件结构时我习惯按“计划 → 记录 → 证据”三个层级文件夹组织安全生命周期计划的文档内容包括安全活动范围、阶段划分、交付物清单和评审安排记录类文档存放危险分析记录、SRS、验证报告、变更申请单证据类文档包括评审会议纪要和测试追溯矩阵。文档编号带版本号和日期强烈不建议叫“最终版”。这套框架的优势在于审核员可以按标准章节号逐条索引不用在几十份文档的海洋里打捞他想要的东西。文档层级不必照抄标准的措辞但结构上要让一个没参与项目的人也能按图索骥。两份常见的小公司文档套路一是把SRS与设计说明混在一起写出来的东西既不满足需求侧的可追溯要求又让设计侧细节无处落脚二是把评审记录全部写在邮件往来里而不是作为正式文档归档。狭隘的经验之谈既然要做功能安全就按功能安全的规矩来文档体系越早搭建越好中途再补生成的工作量和被审核方挑战的风险都会显著增加。4.2 模板开发与追溯矩阵把“证据链”落到Excel里文档模板方面我推荐每个阶段至少准备四类输入检查单、活动记录、输出文档模板、验证报告模板。把这些模板按Part 1的阶段顺序编号做成T01、T02这类编号格式。模板里只放结构和填写指引不预先填好内容。某个团队曾经图省事直接把上一份项目的SRS拿来改个产品名就用结果内部指标、预算上下文、安全状态描述全部残留审核时还被对方挑出来。追溯矩阵是文档体系的“脊柱”。常见的做法是维护一张Excel纵轴是SRS中的安全功能需求编号横轴是设计文档章节、测试用例编号、验证结论、变更记录。任何一条需求纵向能从上到下追溯横向能从一个环节跳到另一个环节缺了哪一格一目了然。维护追溯矩阵的关键不在多花哨而在及时更新——每次变更必须同步刷新矩阵而不是攒半年再补真到补的时候就只能靠回忆和猜了。我经手过的项目里追溯矩阵做得好的团队通常也是返工最少的设计被改掉一个参数立刻能看到哪些测试用例要重新执行立刻能看到哪些验证结论受影响而不是凭感觉办事。提示Part 1的文档化要求从来不规定具体格式它只看“可读性、可追溯性、可维护性”三点。因此别花大量时间去做漂亮的文档管理系统先把内容写扎实、把追溯关系理清楚比用什么管理工具重要得多。4.3 配置管理与版本控制修改得有记录记录得能回溯既然生命周期覆盖“退役”阶段那就意味着项目的文档、图纸、软件代码、配置参数、验证记录在系统整个服役期都要保持可访问。Part 1要求对安全相关项目的所有元素实施配置管理说白了就是每一版改动都要有人批准、有变更说明、有对应版本号。硬件的配置管理其实比软件还难做因为现场换一个传感器型号对应的安全分析结论可能全部作废、必须重新评估。软件方面用Git是不错的习惯但注意别把功能安全配置管理和软件开发流程画等号。功能安全要求的是“有控制的发布”每个正式发布版本都要对应已验证的配置基线包括源代码版本、编译工具版本、配置文件版本、测试报告版本一套全部锁死。曾经有团队软件代码管得明明白白但编译用的工具链版本没记录后来换电脑重装环境编出来的二进制跟原版有细微差异整个验证结论都要打上问号。这种“工具链版本未锁定”的问题几乎每个项目都会遇到处理方案也很简单把编译环境和依赖库版本写进发布记录最好连容器镜像都一并存档。配置管理最容易被忽略的一块是硬件EOL停产替代某天某个传感器停产了采购换了另一个厂家的型号按IEC 61508-1的变更管理逻辑这属于安全相关变更必须重新做适配性验证而不能只看电气参数差不多就装上去。实际发生过的事故中不少就源于此——新传感器的响应时间或故障行为模式和旧版有差异系统整体失效概率悄然上升而安全分析文档还停留在旧型号的参数上隐患就此埋下。5. 常见认知误区与审核翻车现场这六个坑我帮你踩过了5.1 坑一误把“PLC本身有SIL认证”当“整个系统满足SIL”现象项目组买了一批已认证的PLC和仪表然后对外宣称系统整体达到SIL 2。审核时对方要求提供整个安全功能回路的失效概率计算和诊断覆盖率分析项目组却拿不出原因安全认证通常是按产品类型和应用条件来覆盖的但具体到你的传感器—逻辑—执行机构组合接口失效模式、共因失效、系统架构受到应用方式的巨大影响整机认证不包含这些集成。解决把认证证书当作“部件级合格证据”使用但整个安全功能回路的SIL论证仍然需按Part 1要求做系统级分析。5.2 坑二SIL验证只看“失效概率”绕开了系统安全性能现象某个SIL 2紧急停车功能的平均失效概率算出来达标了但反应时间比SRS要求的慢了5秒项目组觉得“反正SIL达到了就不用管响应时间”结果被审核员翻出SRS打脸。原因SIL是完整性维度响应时间是SRS里定义的功能维度两个必须同时满足。解决验证SIL时把SRS里的功能需求和完整性需求都拉出来逐条核对缺一不可。概率模型再漂亮都不等于整个安全功能合格。5.3 坑三把“测试通过”等同于“验证完成”的情况现象按测试用例跑完了功能测试功能表现正常项目组便宣告验证完成。原因功能测试只是“功能行为验证”的一部分还需要故障注入测试、异常工况测试和鲁棒性测试去证明系统在故障情况下仍然安全。解决验证矩阵里明确列出故障注入用例的场景与判据覆盖传感器断线、执行机构卡死、电源跌落和通信中断等常见失效情况。只测Happy Path的验证报告在真正的审核中往往过不完第一轮就会被驳回。5.4 坑四SRS需求描述得过于模糊根本没有可测试性现象SRS里的需求写成“系统应能在紧急情况下可靠地停车”测试团队无从下手只能自创测试场景最后需求无法追溯。原因需求没有量化触发条件、时间窗和预期行为也没有定义“可靠”的判定指标。解决拿第3.3节的可测试需求模板重新写SRS每条需求必须让一个没参与过项目的测试工程师读了之后也能直接写用例。过了这个标准才算真的有效。5.5 坑五变更管理形同虚设现场改参数不留痕现象现场维护人员因为生产便利修改了安全PLC的程序逻辑未走变更管理流程半年后出现安全事故时调取记录发现逻辑已经偏离了验证过的版本。原因公司文档管理体系对现场维护的约束太弱大家又普遍缺乏“安全相关变更必须受控”的意识。解决把变更申请、影响分析、回归验证做成必填流程与生产管理系统的工单打通——允许范围之外的修改一律进不了运行环节。5.6 坑六外部输入没有管理安全功能被悄悄改掉了现象通信协议升级或外部数据库字段变更后原有的安全功能变得不可达但没有人把这次的变更和SRS的映射关系理清。原因只把变更管理聚焦在“主动改动”上忽略“外部环境变化”对系统造成的潜在影响。解决定期把系统外部接口清单拿来做差异对比看外围环境状态是否正在以未受控的方式改变系统的安全行为。把外部依赖全部列入配置管理范围而不是只管内部的代码和硬件。6. 抓住审核员视角去干活验证可追溯性的实战技巧与长期习惯理解Part 1最简单的方式不是我教你反复读标准而是直接站到审核员的位置上去审视自己的项目你生产的每一份文档其实都在回答“凭什么相信这个系统是安全的”这个终极提问。推荐一个简单但极其有效的自查动作把SRS里编号的每一条安全功能需求打印出来逐条追问“哪个设计实现落实了它哪项测试证明了它哪份分析算清了它的失效率”——三连问如果答不上来就是证据链上的窟窿。用这个方法审视模拟项目X补掉了不少自己以为早就闭环的追溯关系审核前安全感强了很多。追溯矩阵的进阶用法是做成“反向追溯”从每条测试用例出发反查它验证的是哪条需求。正向追能看出“需求有没有落地”反向追能看出“测试有没有多余”。双向都闭合才是真正的完整追溯。我习惯在矩阵里加一列“覆盖状态”凡是双向能闭合的标记绿色、有疑问的标黄、完全找不到归宿的标红。验收前把标红清到零标黄逐项说明理由这套动作比任何高谈阔论都有说服力。具体操作时可把矩阵导成CSV配合脚本做差异分析。用一个小脚本就能扫出孤儿需求和孤儿用例#!/usr/bin/env python3 # 读取需求编号和用例编号找出没有落在追溯矩阵里的条目 import csv reqs set(row[0] for row in csv.reader(open(srs_requirements.csv))) mapped set(row[0] for row in csv.reader(open(trace_matrix.csv))) orphan_reqs reqs - mapped print(未覆盖需求:, len(orphan_reqs)) for r in sorted(orphan_reqs): print(r)这段脚本的价值在于把追溯关系从Excel的“人工目测”升级为“自动比对”每周CI跑一次谁改了SRS或删了用例而没有同步矩阵一眼就能看出来。配合变更管理流程矩阵的更新就真正落地成机制了。分析结果时注意区分“需求未实现”和“需求号写错”两种情形后者在Excel手填场景下极常见。自动比对之后还要抽查几行做人工复核以防需求文字与实际用意不符的灰色情况。长期做功能安全下来我对这份标准最深的感受是它不是一叠供查询的技术说明书更像一套思考习惯——每个决策都追问“依据是什么”、每次变更都评估“影响是什么”、每份输出都回答“怎么证明它正确”。这套习惯能倒逼出的好处远超过应付审核本身。希望你读完这篇笔记对怎么用Part 1心里更有数一些能把这套思维带进自己手头的项目里希望帮到你。本文还有配套的精品资源点击获取