4. 安全生命周期模型

IEC 61508 标准的核心思想之一,是将功能安全视为一个贯穿系统全生命周期的系统性工程,而非仅仅依赖某一阶段的测试或验证。该标准将安全活动组织为三个相互关联、逐层细化的生命周期模型:整体安全生命周期(Overall Safety Lifecycle)、E/E/PE 系统安全生命周期(E/E/PE System Safety Lifecycle)以及软件安全生命周期(Software Safety Lifecycle)。这三个模型构成了从概念设计到退役拆除的完整安全治理框架,是实施功能安全管理的路线图和审计依据。

IEC 61508 三层安全生命周期模型关系图 整体安全生命周期(Overall Safety Lifecycle) 概念 → 风险分析 → 安全要求分配 → 整体规划 → 实现与运行 → 退役 范围:整个 EUC(受控设备)及其安全系统,包括所有安全相关系统与其他风险降低措施 输出:安全要求规范(Safety Requirements Specification, SRS) E/E/PE 系统安全生命周期 安全要求分配(E/E/PE 部分) 安全功能设计 → 硬件设计 → 集成测试 安全完整性等级(SIL)分配与验证 系统安全验证 → 安装调试 → 运行维护 范围:传感器、逻辑控制器、执行器及其接口 软件安全生命周期 软件安全要求规范(SSRS) 软件架构设计 → 模块设计 → 编码实现 软件集成测试 → 软件验证 → 软件评估 支持工具与文档管理 范围:嵌入式软件、应用软件、诊断软件 共同支撑要素 安全管理体系(SMS) | 安全文化 | 能力管理 | 文档化 | 变更管理 独立安全评估(FSA) | 验证与确认(V&V) | 配置管理 | 追溯性管理 所有活动均需形成可审计的记录,并接受独立评估

上图清晰地展示了三个生命周期之间的层级关系:整体安全生命周期处于最上层,负责定义“做什么”和“为什么做”;E/E/PE 系统安全生命周期与软件安全生命周期处于执行层,负责解决“怎么做”和“如何证明做对了”。三者并非孤立运行,而是通过安全要求分配、验证活动、变更控制等机制紧密耦合。下面分别对三个模型进行深入剖析。

4.1 整体安全生命周期:从概念到退役的战略框架

核心原理

整体安全生命周期(Overall Safety Lifecycle)是 IEC 61508 的顶层框架,覆盖从系统概念形成到最终拆除的全部阶段。其核心原理在于:安全不能事后附加,必须在系统设计之初就作为一项核心约束条件嵌入到业务流程中。该模型强调对风险的全生命周期管理,包括风险识别、风险评估、风险降低措施的规划与实施,以及残余风险的持续监控。

整体安全生命周期共分为 16 个阶段(Part 1 第 7 章),从概念(Concept)开始,经过范围定义、危险与风险分析、安全要求分配、整体安全规划(包括运行、维护、安装、验证等子规划),再到安全相关系统的实现、安装、运行、维护、改造,直至最终退役。每个阶段都有明确的输入、输出、活动内容和评审要求。

判断方法与操作流程

在实际项目中,判断是否完整执行了整体安全生命周期,可依据以下关键流程节点进行核查:

  1. 概念与范围定义:明确 EUC(Equipment Under Control)的边界、工作模式(如连续模式、需求模式)以及与其他系统的接口。
  2. 危险与风险分析:采用 HAZOP、FMEA、故障树分析等方法识别所有合理可预见的危险事件,并评估其风险等级。
  3. 安全要求分配:将整体安全功能分配给 E/E/PE 系统、其他技术系统(如液压、气动)或外部风险降低措施(如围栏、警示标志)。这是连接整体生命周期与 E/E/PE 生命周期的关键接口。
  4. 整体安全规划:制定安全验证计划、安装计划、运行与维护计划、退役计划等,明确各阶段的责任人、时间节点和验收标准。
  5. 安全确认(Safety Validation):在系统投入运行前,依据安全要求规范进行整体确认,确保所有安全功能在真实环境下满足 SIL 要求。

案例拆解:化工反应釜的安全生命周期管理

某化工企业新建一套间歇式反应釜系统,反应过程涉及高温高压和易燃易爆物料。项目组按照整体安全生命周期模型推进:

  • 概念阶段:定义反应釜的工艺边界,明确其工作模式为“需求模式”(安全功能仅在异常时触发)。
  • 风险分析:通过 HAZOP 分析识别出“反应釜超温导致爆炸”这一重大危险事件,初始风险等级为“不可接受”。
  • 安全要求分配:决定采用独立的 E/E/PE 安全仪表系统(SIS)实现紧急停车功能(SIL 2),同时设置爆破片作为外部风险降低措施(降低约 30% 风险)。
  • 整体规划:制定了详细的安装调试计划、操作员培训计划以及每季度一次的在线功能测试计划。
  • 运行与维护:在运行三年后,因工艺变更需提高反应温度上限,项目组启动了变更管理流程,重新进行了风险分析和安全确认,确保变更后的系统仍满足 SIL 2 要求。

该案例表明,整体安全生命周期并非一次性活动,而是需要随着系统变更持续迭代的动态过程。

常见误区:许多项目团队将“安全生命周期”等同于“项目开发流程”,忽略了运行、维护和退役阶段的安全管理。实际上,IEC 61508 明确规定,运行和维护阶段的安全活动(如定期功能测试、故障响应、维护后的恢复)同样是生命周期的重要组成部分,且往往占据系统全生命周期成本的 60% 以上。

4.2 E/E/PE 系统安全生命周期:硬件与系统集成的工程化路径

核心原理

E/E/PE 系统安全生命周期(E/E/PE System Safety Lifecycle)聚焦于安全相关系统中电气/电子/可编程电子部分的实现。其核心原理是:通过结构化的设计流程和量化分析,确保硬件和系统架构能够满足从整体生命周期分配下来的安全功能要求和 SIL 等级要求。该模型涵盖了从安全要求规范(System Safety Requirements Specification)到系统安全验证的完整工程链条。

关键阶段与操作流程

E/E/PE 系统安全生命周期的主要阶段包括:

阶段 关键活动 主要输出 典型方法/工具
安全要求规范 将整体 SRS 中的 E/E/PE 部分细化为系统级安全功能要求和 SIL 要求 系统安全要求规范(SSRS) 需求管理工具、SIL 分解
系统架构设计 确定传感器、逻辑控制器、执行器的拓扑结构,选择冗余架构(1oo1、1oo2、2oo3 等) 系统架构图、硬件可靠性模型 可靠性框图(RBD)、马尔可夫模型
硬件设计 元器件选型、电路设计、失效模式分析、诊断覆盖率设计 硬件原理图、FMEDA 报告 FMEDA、元器件降额设计
系统集成与测试 将硬件与软件集成,进行功能测试、接口测试、环境应力测试 集成测试报告、系统验证报告 HIL 测试、边界扫描
系统安全验证 独立于设计团队,验证系统是否满足 SSRS 中的全部安全要求 安全验证报告 FTA、FMEA 复核

实战场景:安全 PLC 的冗余架构设计

某石油天然气管道项目需要配置一套紧急关断系统(ESD),要求 SIL 3 等级。项目团队在 E/E/PE 系统生命周期框架下进行了以下工作:

  • 架构选择:对比了 1oo1D(带诊断的单通道)和 2oo3(三取二)架构。通过可靠性计算,1oo1D 在诊断覆盖率 ≥99% 时可达到 SIL 3 的 PFH 要求,且成本更低,最终选择 1oo1D 架构。
  • 硬件设计:对输入卡件、CPU、输出卡件分别进行 FMEDA 分析,识别出关键失效模式并设计诊断措施(如看门狗、输入信号合理性检查)。
  • 系统集成:在 HIL 测试平台上模拟管道泄漏、阀门卡涩等故障场景,验证安全响应时间小于 2 秒。
  • 验证结果:最终系统 PFH 计算值为 1.2×10⁻⁸ /小时,满足 SIL 3 要求(PFH < 10⁻⁷)。

该案例体现了 E/E/PE 系统生命周期中“设计-分析-验证”闭环的重要性,任何环节的缺失都可能导致 SIL 等级不达标。

经验提醒:在硬件设计中,务必保留完整的 FMEDA 分析记录和元器件降额计算书。这些文档不仅是安全验证的依据,也是后续进行失效分析和寿命评估的基础。许多企业在审计时因缺乏这些记录而被开具不符合项。

4.3 软件安全生命周期:保障可编程电子系统安全性的关键

核心原理

软件安全生命周期(Software Safety Lifecycle)是 E/E/PE 系统生命周期在软件维度的细化。其核心原理在于:软件本身不会“磨损”,但其复杂性导致系统性失效(Systematic Failures)难以完全避免,因此必须通过严格的开发流程、设计规范和验证活动来预防和发现缺陷。IEC 61508-3 将软件安全生命周期划分为从软件安全要求规范到软件评估的 11 个阶段,每个阶段都要求与 SIL 等级相适应的严格程度。

操作流程与 SIL 等级对应

软件安全生命周期的关键阶段及其与 SIL 等级的对应关系如下:

  1. 软件安全要求规范(SSRS):从系统 SSRS 中提取软件相关的安全功能要求,包括功能行为、时序约束、诊断覆盖率、响应时间等。SIL 3/4 要求使用形式化方法(如时序逻辑、Petri 网)进行描述。
  2. 软件架构设计:划分软件模块,定义模块间接口和数据流。SIL 3/4 要求采用半形式化或形式化方法(如 UML 结合 OCL 约束)。
  3. 软件模块设计与编码:遵循编码标准(如 MISRA C),实施代码审查、静态分析。SIL 3/4 要求使用更强的静态分析工具(如 Polyspace)并达到 100% 语句覆盖率和分支覆盖率。
  4. 软件集成与测试:自底向上进行模块集成测试,验证模块间接口和交互行为。SIL 3/4 要求使用动态分析工具进行边界值测试和鲁棒性测试。
  5. 软件验证与评估:独立于开发团队,对照 SSRS 逐项验证软件实现,并评估是否达到目标 SIL 等级。

案例拆解:核电站保护系统软件的开发与验证

某核电站反应堆保护系统(RPS)需要开发一套 SIL 3 等级的停堆逻辑软件。项目组在软件安全生命周期框架下实施了以下措施:

  • 需求管理:使用 DOORS 工具管理 200 余条软件安全需求,每条需求均与系统级需求建立双向追溯。
  • 架构设计:采用分层架构(应用层、诊断层、驱动层),各层之间通过受控接口通信,禁止跨层调用。
  • 编码与审查:遵循 MISRA C:2012 标准,使用 Coverity 进行静态分析,消除所有高优先级缺陷。每行代码至少经过两名工程师的独立审查。
  • 测试策略:执行了 100% 语句覆盖、100% 分支覆盖和 100% MC/DC 覆盖的单元测试;集成测试中模拟了 50 余种故障注入场景(如传感器漂移、通信中断、CPU 寄存器损坏)。
  • 独立评估:由第三方机构进行独立安全评估,确认软件满足 SIL 3 的系统性能力要求(SC 3)。

该案例表明,软件安全生命周期需要投入大量资源进行验证活动,但这是确保高 SIL 等级软件可信赖性的必要代价。

总结复盘:三个安全生命周期模型构成了 IEC 61508 的方法论骨架。整体安全生命周期回答“需要什么安全”,E/E/PE 系统安全生命周期回答“如何用硬件和系统实现安全”,软件安全生命周期回答“如何用软件保障安全”。在实际项目中,三者必须协同推进,任何一层的缺失或薄弱都会导致整体安全目标无法实现。建议企业在建立功能安全管理体系时,首先梳理三个生命周期的接口关系,明确各阶段的输入输出和责任矩阵,再逐步细化实施。
常见误区:部分团队将软件安全生命周期视为“瀑布式开发流程”,忽略了其迭代特性。实际上,IEC 61508-3 允许在架构设计和模块设计之间进行迭代,但每次迭代都必须重新进行影响分析和验证。此外,软件工具(如编译器、测试工具)本身也需要进行工具鉴定(Tool Qualification),确保其不会引入未检测的缺陷。