导航：安全管理网>> 安全论文>> 综合安全论文>>正文

过程工业控制系统及其软件的功能安全

文档作者：彭瑜文档来源：上海工业自动化仪表研究院		点击数：	更新时间： 2021年06月06日
下载地址：点击这里	文件大小： 702.64 KB 共8页	文档格式： PDF	下载点数： 1 点（VIP免费）

全屏查看

内容预览 [文件共8页]

本文件共8页，如需编辑使用，请下载。

注：预览效果可能会出现部分文字乱码（如口口口）、内容显示不全等问题，下载是正常的。

	文件大小：702.64 KB 共8页文件格式：PDF 下载点数：1 点（VIP会员免费）

下一篇：工业控制系统信息安全研究综述

上一篇：工业控制软件功能安全的实现方法和评估

文本预览

仅提取页面文字内容，供快速阅读使用。

专冢分析
彭瑜， 男， 中国自动化学会理事，
中国自动化学会仪表和装置专业委
员会常务委员， 中国自动化学会专
家咨询委员会委员，上海市自动化
学会常务理事，中国仪器仪表学会
专家委员会委员，PLCopen国际组织
中国委员会主席。长期从事现场设
备的无线通信等方面的研究。
从实现过程功能安全要求的基本规范IEC 61511所给出过程工
业中工厂安全保护防灾结构体系(见图1)，可以清晰地看出安全
仪表控制系统SIS是过程工业预防灾害和减灾的两个重要环节，确
保安全仪表系统的功能安全则是预防和减灾的一种基础保证。本
文希望从功能安全的基本概念出发讨论怎么才能切实实现控制系
统的概念安全。
4 0
图1工厂安全保护防灾结构体系
自动化博览2010年12~-]：lJ
上海工业自动化仪表研究院彭瑜
l 控制系统功能安全的国际标准
IEC 61508／GB 20438《电子／电气／可编程电子安全相关系统的
功能安全》是一个宏标准，规范了满足安全相关系统功能安全的
基本要求和规则。通过应用严格的系统性的过程，以可追溯性、
关键性分析、验证(vermcation)和确认(validation)的程序为重点，
来评估是否满足功能安全的标准要求。IEC6 l 508标准的一个重
要突破就是制订了一整套完整的开发程序和一系列的技术措施，
通过严格的质量管理与全生命周期的程序控制，达到实现避免故
障、排除故障及一定程度上容许故障的目的。
IEC 61508共有8个部分，即：
· IEC 61508—0：功能安全SHIEC 61508；
· IEC 61508—1：一般要求；
· IEC 61508—2：电气／电子／可编程电子安全相关系统的要
求；
· IEC 61508—3：软件要求；
· IEC 61508—4：定义和缩略语；
· IEC 61508—5：确定安全完整性等级的方法示例；
· IEC 61508—6：IEC 61508—2~nIEC 61508—3的应用指南；
· IEC 61508—7：技术和措施概述。
在不同应用领域更细化和具体实现功能安全，又开发了进一
步的规范，如：
· 实现机械功能安全要求的基本规范IEC 62061；
· 实现过程功能安全要求的基本规范IEC 61511；
· 实现核电功能安全要求的基本规范IEC 61513；
· 实现医疗设备的功能安全要求的基本规范IEC 60601；
· 实现铁道运输安全的规范EN 50128；
2 控制系统功能安全的基本概念
安全系统的关键性分多个层次：
· 安全关键(safety—critica1)系统：单个缺陷或失效会造成危
险的故障，如核电站原子反应堆的停堆系统。
· 安全相关(safety—relevant)系统：单个缺陷或失效与第二
个缺陷或失效会造成危险的故障，如石化行业的安全仪表系统。
· 非安全相关(interference—free)系统：即使多个缺陷或失
效也不致造成危险的故障。
对安全要求最高的安全关键系统，必然为实现其安全要求而
最耗费时间、成本最高，认证的过程和程序最复杂。对安全的要
求相对较低的安全相关系统，以及对安全要求更低的非安全相关
系统，相应在时间、成本和认证所耗费的努力逐级递减。
在IEC 61 508的标准中，对石化和化工行业广泛应用的安全
相关系统有着严格的定义和要求：
· 必须在受控装置Eucll~近风险或危险状态情况下，能执
行所要求的安全功能，使EUC达到或保持安全状态；
· 依靠安全相关系统本身，或与其它E／E／PE安全相关系
统、其它技术的安全相关系统或外部风险降低设施共同作用，达
到所要求的安全功能必需的安全完整性。例如图2所示的一个化工
厂常见的加热搅拌系统，除了用圆圈标出的是一个安全仪表系统
(SIS)而外，安全阀就是使用机械保护的安全系统，它们配合使
用达到必需的安全完整性。
这将安全相关系统在工厂预防和减灾中的作用明确规定如
下：首先，由安全相关系统与外部风险降低设施共同作用，使受
控设备达到必要的风险降低量，以满足所要求的允许风险。其
次，安全相关系统是在接受命令时，采取适当的顺序动作防止
EUC进入危险状态。一旦安全相关系统失效，也属于导致危险或
危害的事件。第三，即使还有其他的具备安全功能的系统，但所
指定的安全相关系统仅靠其本身的能力(而非其他系统)就能达
到所要求的允许风险。第四，安全相关系统一般分为安全控制系
统和安全防护系统，并且具有两种操作模式。
从安全相关系统的构成来看， 它可以是EUC控制系统的一个
组成部分，也可用传感器和／或执行器与EUC接口，即可通过实现
EUC控制系统中的安全功能(也可能通过分开的和独立的附加系
统)达到要求的安全完整性等级，或者利用分离的、独立、专门
的安全相关系统实现安全功能。
这就明确告诉我们，安全相关系统的功能可能包括：用于防
止危险事件发生，即安全相关系统一旦执行其安全功能，则不致
发生有危险事件；用来减轻危险事件的影响， 即通过减轻后果降
低风险。或者同时具有上述的组合功能。
人也可作为安全相关系统的一部分，例如，人可以接收来自
可编程电子装置的信息，岸通过该装置按接收信息要求执行安全
动作。
安全相关系统包括执行安全功能所需的全部硬件、软件以及
支持服务(如电源、传感器和其它输入装置、执行器和其它输出
装置也包括任安全相关系统中)。
安全相关系统的技术基础范围可以十分广泛，包括电气、电
子、可编程电子、液压和气动等。
图2 SIS~n安全阀配合使用的化工加热搅拌系统的P&amp;amp;ID
由于在工厂安全保护防灾的体系结构中对不同的装置、系
统，甚至系统内的各个子系统或部件的安全要求常常有很大差
异，因此，1EC61508标准允许对一个系统的子系统和部件进行独
立的评估。所以，我们在谈论功能安全时要严格区分所指的对象
是系统，还是构成系统的部件或子系统。
3 控制系统的安全完整性及其等级
安全完整性是指在规定的条件下、规定的时间内，安全相关
系统成功地实现所要求的安全功能的概率。众所周知，控制系统
由构成其系统的各种硬件(控制系统装置、现场仪表、通信网络
等等)以及执行控制要求和功能的软件综合而成，因此控制系统
的安全完整性由硬件的安全完整性和系统的安全完整性组成。硬
件安全完整性是在危险失效模式中对应于安全相关系统安全完整
性的硬件随机失效的那一部分，一般可以通过所要求的硬件安全
功能失效率予以量化；而系统安全完整性则是指在危险失效模式
中对应于安全相关系统安全完整性的系统失效的部分(包括软件
失效)。控制失效与避免失效涉及设计、操作模式等诸多环节。
显然，硬件随机失效和系统失效的机制不同，控制失效的方法也
不同(见图3)。
可以通过改变设计、生产过程、揉作
模式、操作指令或其他影响因子，
来消除原因确定的失效，
避免失效
控制失效
图3 控制系统失效机理
估算由于随机硬
件失效造成的每
个安全功能的失
效概率
2010．~12月刊自动l匕博览 4 1
专家分析
在安全相关系统中，安全完整性的要求用4个离散的等级予
以划分，H~SIL4，SIL3，SIL2~SIL1。安全完整性的等级越高的
安全相关系统，其执行所要求的安全功能的概率也越高。
根据安全相关系统的使用方式、所要求发生的频率，可分
为低要求操作模式和高要求(或连续)操作模式。低要求操作
模式对应于每年发生风险的次数多于等于1次的安全相关系统；
高要求(或连续)操作模式对应于每年发生风险的次数少于1
次的安全相关系统。表1是IEC 61 5081／GB／T 20438规定的低要
求操作模式下的安全完整性的目标失效概率和目标风险降低因
子，表2是高要求(或连续)操作模式的安全完整性的目标失效
概率。
SIL3被认为是单个可编程系统中可达到的风险降低的最高等
级。
表1低要求操作模式下的安全完整性的目标失效概率和
目标风险降低因子
安全完整性等级 目标平均失效概率 目标风险降低因子
(SIL)
4 >10～一<10。 >10000— 100000
3 10。一<10一 >1000一 10000
2 l0一一<10’ >100——~1000
1 兰10～一<10一 >l0一Sl00
表2 高要求(或连续)操作模式的安全完整性的
目标失效概率(每小时)
安全完整性等级 目标平均失效概率 平均发生1次失效的
(SIL) (每小时) 年数
4 1O 一<10。 l1400～ 114000
3 >10一一<10 1140一l1400
2 >10～一<10一 l14— 1140
l >10一一<10。 11．4一l14
4 安全系统的多样性(diversity)原则
安全系统可以采取多样性原则克服可能发生的故障，或设计
分析中存在的不确定性。多样性是指用不同方法执行所要求同一
功能。例如：可用不同的物理方法或不同的设计途径来达到多样
性。
多样性分为：① 信号多样性；② 功能多样性；③ 设备多样
性；④ 软件多样性(如指令运算的多样性) ；⑤ 人员多样性等
等。其中较为常用和有效的是信号多样性和功能多样性。
对所采用的多样性措施是否适当应加以论证。为了保证能切
实执行多样性，对设备的多样性或仪表控制系统的软件多样性所
进行的论证，必须扩展到这些设备的硬件、软件部件，如实时操
作系统RTOS。
图4是s7—400F运用指令运算的多样性和时间冗余来提高安
全功能的可靠性。操作数A、B在CPU1进行“与”运算，结果
4 2 自勋化搏笕2010年12月刊
为C； A、B经过编码变成字A、B，在CPU2中做“或”运算，
结果为D=／C。在比较器中进行比较运算，仅当D≠／C时输出停
机信号。
Time redundancy Time
图4 运用指令运算的多样性和时间冗余来提高安全功能的可靠性
再如某核电站的紧急停堆系统由两个完全独立的系统构成。
其安全控制系统由不同的供应商提供。一个停堆控制系统采用安
全PLC系统，由3个独立的3机冗余表决的分系统(D、E、F)组
成(见图5)。每个分系统都具备停堆功能，但其停堆输出还要
送给3取2的继电器硬逻辑进行表决，最终给出停堆信号。该安全
PLC系统硬件平台配有操作系统，运用符合工业控制编程语言的
国际标准IEC 61131-3所规范的功能块图语言(FBD)编制应用软
件。这套停堆控制系统采用了综合法(Integrated Approach)设
计。
值得注意的是，为了实现安全系统的机理多样性，还设置
了另一套完全不同机理的停堆系统，通过将有害的中子吸收剂
(poison)注入反应堆中的慢化剂(moderator)的方法进行停堆
控制。这一停堆控制系统采用没有操作系统的工控机硬件平台，
安全控制软件运用高安全的具有子集的MODULA一2语言编写。这
一套系统使用的是另一种设计方法一合理设计流程法(rational
design process)，用确定离子室记录的功率信号的合理性来检查
异常差错信息。由此可见，在要求极高的安全关键系统中充分运
用了多样性的原则，有：机理的多样性、设计方法的多样性 设
备的多样性、编程语言的多样性，这样就从系统的层面上把同时
发生差错的概率降至尽可能的小。
通道E
通道F
— — — — — — — — —
I
f藤
图5 采用3套3机冗余表决的安全PLC系统构成的停堆控制系统
5 重视处理假事件
各种安全系统(包括紧急停车系统ESD)如果对假事件作
出响应，造成非计划停车，不但要付出高昂代价，而且在大多数
信停 参Ir¨ L- 一瑟
或 j 一巫袭= 蕃
情况下具有危险性。大量的假报警还会导致操作人员产生矛盾心
理，以至于对危险的真报警都不予理会，或者反映很慢。
产生假事件的原因： ① 现场设备的硬件故障，如压力开
关、电磁阀的线圈或常闭触点存在高电阻，PLC的I／O模块有
故障，现场设备中电子器件有故障，热电偶断偶，热电阻断线
等，这些明显的设备故障都会引发假事件。② 一些公用故障如
电源、气源故障也会引发假事件。③ 缺乏维护，不及时对工作
有缺陷的仪表、传感器进行测试、校验，是引发假事件的重要
原因。
下面讨论信号多样性问题。看一个用3个浮球液位开关测量
液位的简单例子(图6)。我们可以有4种配置。采用单信号、双
信号还是三信号更有利于安全和可靠的平衡呢?概括地说：采用
单机(单信号)系统不安全且不可靠，在故障安全(假事件)或
危险方面存在50／50的概率；采用双机(双信号)系统配置为二
取一(1002)，可能较安全，但存在高的假故障率；双机(双信
号)系统配置为二取二(2002)， 由假事件引起的故障率较低，
但安全性差；三机(三信号)冗余系统为三取二(2003)，提供
可以接受的安全与可靠的平衡。
■
—
— #—-一——— —f r 1一珊一一
— — O ) 一
2oo3
三取二
图6 用3个浮球液位开关测量液位可能的配置
显然，sIS／ESD不能选择单机(单信号)系统。选用双机
(双信号)系统，在一定程度上可达到安全和可用性。二取一
(1002)安全性较好，但可靠性及假事件的影响大；二取二
(2002)可靠性较好，安全性却较差。即使双机(双信号)系统
具有很好的自诊断性能，可以确定采用哪个通道或处理器故障，
将坏的通道或处理器剔除，但这时双机系统降格为单机系统。三
取二(2003)独特的优点是不考虑哪个通道发生故障，是怎么发
生故障的；也不完全依靠自诊断来确定哪个通道投用。其亮点在
于它仅要求所接收到的信息。三取二表明，若有一个信号不同于
另外两个信号，立即报警，而这两个信号相同的通道处于安全工
作状态。
从图6所示的例子可知，如果流程要求用于液位测量的仪表
每年只能发生1次故障，而且每半年对浮球开关进行一次维护测
试，那么对于不同的浮球液位开关配置，因故障造成危险的年概
率如表3所示。
表3 浮球液位开关不同配置的因故障造成危险的概率
仪表信号配置 故障危险概率 假事件故障概率 故障危险概率
(每半年维修1次)
1ool 1／10 1／10 1／2O
1002 1／100 1／5 1／1600
2002 1／5 1／100 l／20
2003 1／33 1／33 1／534
f] 软件的可靠性难以精确量化
软件可靠性的基本问题是：① 软件不受物理故障的影响。随
着硬件元器件的可靠性越来越高，并可以采用冗余技术，因而安
全问题的矛盾集中到了软件，以至于今天我们看到大多数的系统
失效源自软件。失效常常由于一些非明显的事件组合造成，而不
是由于机械应力超过一定程度造成。而这些非明显因素往往事先
没有估计到，所以在软件的编制中考虑不到。② 软件是由人来设
计的，软件的设计不可能面面俱到，总有些因素在设计时没有考
虑到，因此，设计的缺陷导致软件的故障。③ 数字系统本质上是
非连续的，所以输入对输出的映射一定是不连续的。④ 软件建立
在模型化和测试的基础上，这些工作都是人在做的。人难免犯错
误，所以影响软件的可信度。
因为以上这些不可避免的问题，可以得出软件的可靠性难
以精确量化的结论。另外，从趋势上讲，软件和人为因素导致失
效、事故和停机的比例越来越高。因为现在对软件的依赖越来越
高，软件变得越来越复杂，因而难以控制。人犯错误不可避免。
硬件失效可能是系统失效的原因，系统的失效会引起软件的失
效。有鉴于此，要保证工业控制软件的功能安全就不得不依赖于
对软件进行严格的验证和确认。
7 工业控制软件的功能安全概念和方法
IEC 61508—1规定了整体安全生命周期的16个阶段，包括：概
念，整体范围定义，危险和风险分析，整体安全要求，安全要求分
配，整体操作和维护计划编制，整体安全确认计划编制，整体安装
和试运行计划编制，E／E／PE安全相关系统：实现，其他技术安全相
关系统：实现，外部风险降低设施：实现，整体安装和试运行，
整体安全确认，整体操作维护和修理，整体修改和改型，停用及处
理。与软件相关的是第9阶段“E／E／PE安全相关系统：实现”
在IEC61508—3中详细地规定了执行安全功能的软件如何满足
功能安全的要求。它规范的工控软件的功能安全问题包括以下方
面：软件质量管理系统，软件安全生命周期要求，软件功能安全
评估。它给出的是在软件的安全生命周期的各个阶段应该满足什
么要求，以及如何来验证工控软件达到了功能安全的标准。IEC
61 508—3的突出贡献在于制订了一整套完整的开发程序和一系列
技术措施，通过严格的质量管理与全生命周期的控制程序，实现
避免故障、检测故障和排除故障，以及容许存在故障，从而保证
201O年12Pl~~l 自动化博览 4 3
二
⑨
～
A ～ B AB

类和编排：顶级属性、中间属性和基本属性，如图9所示。
麟
I
l l l
一《 誊囊囊嘲瑚 眭毒点量
I《锄 拦鲢罐脯‘ 辩?键懿 瓣 雕醣蹙赣舞性， 攘 缝 I(掘 。对庠孵蘑獯薯lI谯》
I
箍虢毫性
《煎lt 旃森辔憋分配的最甜、化)
I
《 语誊专嚣桀l戤
(知 特蹙软肋韵爱咖化)
图9 软件安全的三级架构属性
软件的可靠性属性是在所规定的条件下软件的可预测、且恒
定一致的性能。由于软件的可靠性属性旨在减少在软件开发实现
期间可能被导入源代码而造成误操作的故障，所以此顶级属性对
安全来说是很重要的。
软件的鲁棒性是在异常条件或事件下，安全系统的软件以一
种可接受的方式进行操作的能力。由于它加强了软件处理例外情
况、从内部故障中恢复，以及阻止因异常环境而致使故障传播的
能力，因此此顶级属性也很重要。
软件的可追溯性表现为：① 对源代码和所引用的程序库部件
的源头进行检查和识别；② 通过对开发过程的可行性进行检查，
来验证已执行的代码在其开发过程中是否按规范的方法完成其实
现；③ 审视代码与高一级的设计文档相关联的能力。此属性之所
以重要是因为这将便于对软件进行验证和认证(V&amp;amp;V)，这是软
件质量保证的另一方面。
软件的可维护性是在软件交付使用后若需对源代码做改动
时，导致将故障引入的可能性减少的必要手段。此属性之所以对安
全来说很重要，是因为在对软件进是因为在对软件进行适应、校正
或完善期间可以尽量减少可能发生的误操作的故障。
根据IEEE所给出的规定，软件可靠性是在软件编制、调试和
执行运行全过程的环境下，既可以是在所定义的时间间隔内和所定
义的条件下成功执行的几率，也可以是按照命令成功操作的几率。
软件执行完成是其对于系统存贮器和程序逻辑恰当行为的结果。这
0 移
J
I l I
霄贮窑瞎 用的 蓖曩I性I l 控利流雕霹蓣赫性 Il l 时 擎的簿撷潮瞧
l I l l
一结构最大化
一控制流复杂性的最小化I
一变量的初始化 L 尽可能少用任垒
一子程序的进入点和}J_；l=_】谴用
点只有一个
一不用赋值语句
一界面歧义龋小化
一采用数据键入
一准确度、耪度进行记录
一捧定优先缀
一避免执{}子程序产生的
状态变化
一将求值与赋值瞒开
一动态绑定最小化
一
- - ●
图10 可靠性的中间属性
意味着软件所产生的适时输出是编程人员对所使用的语言结构和运
行期间环境特性理解的函数。因此可靠性的中间属性包括：存贮空
间利用可预测性(软件不致造成处理器会向非预期的或不允许存贮
空间进行存取的高概率)；控制流可预测性(处理器按编程员预期
的顺序执行指令的高概率)；时序可预测性(软件在所定义的运行
环境下满足响应时间和处理能力约束的高概率)；数学结果或逻辑
结果可预测性(软件在所定义的运行环境下产生编程员所预期结果
的高概率)。详见图10。
所谓软件鲁棒性是指在异常或其他未曾预计的情况下软件继
续执行的能力。鲁棒性的同义词是耐久性(survivability)。对安
全系统而言鲁棒性之所以重要是因为在一个意外或偏离额定工况
时会发生未曾预料的事件，在这样的情况下软件持续的对系统监
控和控制的能力仍能有效作用。软件鲁棒性的中间属性和基础属
性见图11。
图1 l软件鲁棒性的中间属性和基础属性
软件的可追溯性是指与软件设计相比较，安全软件的那些支
持其正确性和完整性验证的属性。可追溯性的基础属性有：可读
性(这也是可维护性的属性)，内嵌函数的可控的使用，编译库
的可控使用。
软件的可维护性是为了有效减少在对软件进行修改时可能引
入的差错。会影响安全的与可维护性有关的中间属性(见图12)
包括：可读性一便于项目人员对软件的理解的软件属性；数据的
抽象一对于那些代码被划分和模块化的区域，这样做可以使在修
改软件时意想不到的副作用和次生的影响减至最小；函数的内聚
性一对代码中的软件元素给予设计水平的函数适当的存贮地址；
可移植性一避免一种语言的非标准函数对安全的重大威胁；可塑
性一将可能修改的代码区与软件代码的其余部分隔离开。
糍读性 赚|抽豢l l函数 舅酣虫
遵照认证导则广全局搴 用
使用专业变量I 得越少越好
名 一接I3尽可
加注释和内部 能简单
文档
控制进程的大小
运用单目
的函数
运用单目
的变萧
编程最好不用多种语言
编程结构要请晰
相关元素尽可能集中，切忌分散
图12 可维护性有关的中间属性
隔离非标准结构
2010年12,EJ刊自动化博览 4 5
专家分析
】0编程语言实现软件功能安全的方法
在NRC的NUREG／CR 6463 Rev．1完整版本中给出了将9种编
程语言(Ada，Ada95，C／C++，Pascal，PL／M，IEC61131-3规定
的梯形图、顺序功能图、结构化文本和功能块图)用于安全系统
时，应该关注它们特定的存在问题和如何加以克服注意点。譬
如，对于C语言来说，是其指针的初始化问题；对于IEC 61131-3
所规范的编程语言，则应关注其时序、正常运行的监控，以及故
障处理等问题。
从顶级属性中的可靠性、中级属性中的可预测性的控制流
和基础属性中的在使用前变量的初始化这三方面导出对指针初始
化的指导原则。所有的变量和指针在使用前都应该初始化。C语
言支持通过说明来指定初始值的方式进行初始化，但并不要求所
有的对象(指变量、数据结构或数组)进行初始化。在若干情况
下，一个对象的初始化不仅要为对象的存贮地址指定一个特定的
位的组合值，而且还要采取特殊的动作来为对象的生命(例如为
对象赋予对应的源)进行平滑初始化。在c十+中，可能要考虑任
意相关数据作为对象，并提供构造数据组一个实例的工具。这样
便会以系统的方式破坏数据组当前的实例。
考虑到上述情况，必须对初始化提出以下导则：① 不要对超
出其说明范围的变量自动使用指针。存贮在指针的值对一个自动
变量会包含超出其函数范围的无用输入。② 指针的初始化，初始
化问题也会在指针中发生。在安全系统中所有C语言中的指针变
量，其初值都应该为null；所有c++中的指针变量，其初值都应该
为0。在被使用之前，指针应对一个有效值予以测试。当一个指针
被定义时，它没有一个地址与其相关联。使用一个未初始化的指
针，会造成重写未曾预想到的指针的存贮地址。错误地重写存贮
内容会引起严重的问题，包括对系统的崩溃。③ 要确保每一个指
针的说明间接的运算符都是存在的。每个指针都应该有一个间接
运算符( )。
IEC 61131-3所定义的5种语言除指令表语言(IL)与汇编语
言相似外，其它语言都纳入了NRC关于编程语言的导则中。对
这些语言特定的指导原则源于鲁棒性顶级属性和异常处理的中间
属性。应该专注于在机组紧急停车时PLC的行为。通常此时所有
的输出均应切断，但往往并非总是如此。一般PLC系统总是设计
成在紧急停车时系统处于故障安全状态。某些PLC在遇到这样的
情况时具有处理器能自动停止主梯形图程序的执行，转而执行
“故障程序” 的子程序。这使系统的设计者可以决定采取适当
的动作，包括以一种安全的方式让系统停下来。问题在于：IEC
61 13 1-3规范中未涉及到允许PLC系统本身包含有某种预先设计
好的硬件故障程序，当检测到一定范围的故障条件时便会自动执
行。不过，IEC 61131—3允许建立非周期的任务，通过触发适当的
内部诊断信息来执行处理特定类型的出错(I／O故障时降级运行模
4 6 自勋化博笕2010年12月刊
式、向操作员见面报警等)。
对于PLC系统，在编程的设计阶段就应在程序结构中考虑故
障程序问题。这时必须遵从如下原则：① 完整性故障程序不能依
赖于检测到程序崩溃的所有特例，因此遇到PLC的主要故障时要
有针对附加措施的安全保证。② 可观察性故障程序要有状态记录
和报警的能力。故障程序应显性执行，不被掩盖。③ 真实性检查
在启动故障程序的情况下有可能将可以反映原来条件的程序存贮
内容、数据文件或UO状态破坏，因此故障程序应保证在执行故障
处理前将这些环境加以保存，以便事后分析。④ 在故障程序不起
作用时的故障安全特性万一PLC系统的故障处理程序不起作用，
系统设计仍要保证安全状态的后备措施。
PLC系统一般以指定的位和字的形式提供对应用程序的正常
运行状况的监控，这些信息包括特定任务的执行时间、I／O~1]新
信息、I／0操作状态信息、电池状态信息和其它用来确定PLC正常
运行状态的信息。遗憾的是IEC 61131-3规范中对这些信息的典型
值、范围和类型并未做出规定。而安全系统恰恰应该具备这些信
息，作为判断其是否运行正常的检查和是否需要异常处理的不可
或缺的部分。
在IEC 61131．3的规范关于“任务”这节中，阐述了制造厂
应向用户提供所有任务执行的信息的最低要求。关键在于由于这
一问题的分类落在出错检查，而未能在规范中描述，于是我们也
得不到这些任务执行时在运行时应以何种形式接受检查的规定。
另外，许多PLC~I]类似的符合IEC 61131-3的系统一般只给出每次
执行所有任务的周期(即所谓的扫描周期)，却忽略了单个任务
执行周期信息和标志的提供。如果因为安全原因需要在执行某个
任务超时N次时必须紧急停车，在PLC现有的能力下是无能为力
的。为了解决这个问题，必须让应用程序能够对单个任务执行其
超时的检测，并给出单任务超时的标志，这样才能做出适当的反
应。对于安全关键系统，监控任务超时的问题尤其要紧。必须在
程序开发的检查阶段关注。
¨ 在安全系统中推荐采用的编程语言
在IEC 61508—7的附录C．4．5中给出了适合用于安全系统的软
件编制推荐的语言(见表4)，表中列举了24种编程语言，其中适
用于安全系统的软件编制的语言共9种，它们是：属于全可变语
言FvL有5种(具有子集的ADA，具有子集的MODULA一2，具有
子集的Pascal，具有子集的FORTRAN77，具有子集和编程标准并
使用静态分析工具的C) ；属于有限可变语言Ll VL有4种(具有定
义的语言子集的梯形图，具有定义的语言子集的功能块图，具有
定义的语言子集的结构化文本，具有定义的语言子集的顺序功能
图)。
>>>>>>>>>>>>下转50页
案例推介
场调试中最初软件工程师设置的采样时间全为1s，死区为0，这样
文件很大。环保检查时要求调出一个月的相关历史数据，在历史
站调出1个月的趋势图的时间很长，甚至长达几个小时，让核查人
员无法忍受。经过优化以后，采用本文前面的办法，历史数据文
件容量减小为原来的l％以下，调出同样时间段的数据的时间减少
到1-2分钟，这个时间应能接受。
在调试现场要检验参数设置优化后的效果，是否只有等待1
个月的时间，等一个月的历史数据形成后才能验证调出时间?答
案是否定的，采用好的办法，可以在半个小时内检验调出1个月历
史趋势记录的时间：
(1)iFix的历史记录参数优化后，重新启动软件，24小时后
得到1X的数据文件；
(2)拷贝并复$r130个这样的文件；
(3)逐个修改文件名，即修改文件的生成时间。
这样快速地得到了1个月历史记录数据，数据是重复的，每
天相同 用于来测试参数优化后历史数据的调出时间是合适和可
行的，可以调出重复的3O天或更多天的数据。我们在做文件复制
前，应将已经生成的历史数据做好备份，以便事后恢复。这个方
法只能用于试验，生产运行中不能对历史数据做修改和拷贝，如
果有操作也将被记录。对脱硫装置这样的环保设施，如果数据作
假，查实后将会受到环保部门的严厉惩罚。
6 结束语
GE iFIX作为优秀的SCADA软件，适合于多数的工业自动
化生产过程控制。对项目中具体参数的历史记录应按工艺过程
的条件和要求，设置采取合理的参数， 实现历史记录数据的有
效和优化。如果企业对历史数据记录的要求更高，如毫秒级采
样，数据量大(全厂级，几万点)，则应采用Proficy Historian
(iHistorian作为企业级实时历史数据库平台，可以极高的速度
采集、归档并发布海量实时的现场过程信息 )或其它的专用数
据库软件。
参考文献：
【1]基于ADO技术的iFix历史报表的设计与实现[j]．自动化信息，2010．8．
[2]iFIX躲控软件在烟草制丝线的集成应用(7~．)[EB／OL]．http：／／www．zgznh
corn／article show asp?articleid=580810，2010—06·09
『31 Proficy HMI SCADA—iFix4 0电子
[4]曲晓俊，马彩iFIX组态软件中通用趋势曲线的设计与实现[J]．工 控制
计算机，2009(22)3
[5]iHistorian在电厂厂级实时躲视系统中的解决方案[EB／OL]http：／／sbg1．
jdzj．corn／Article／200809／2008092417294o_l2514．html，2008—09—24．
5 o 自动 匕{等笕2010年12月刊
<<<<<<<<<<<<上接46页
表4 IEC 61508—7推荐的适用于安全系统的软件编制的语言
编程语言 SIL1 SIL2 SIL3 SIL4
ADA HR HR R R
具有子集的ADA HR HR HR HR
MoDULA一2 HR HR R R
具有子集的MODULA-2 HR HR HR HR
Pascal HR HR R R
具有子集的Pascal HR HR HR HR
FoRTRAN77 R R R R
具有子集的FORTRAN77 HR HR HR HR
C语言 R NR NR
具有子集和编程标准并使用静态分析工 HR HR HR HR
具的C语言
PL／M R NR NR
具有子集和编程标准的PL／M HR R R R
汇编语言 R R
具有子集和编码标准的汇编语言 R R R R
梯形图语言 R R R R
具有专门定义的语言子集的梯形图语言 HR HR HR HR
功能块图语言 R R R R
具有专门定义的语言子集的功能块图语 HR HR HR HR
言
结构化文本语言 R R R R
具有专门定义的语言子集的结构化文本 HR HR HR HR
语言
顺序功能图 R R R R
具有专门定义的语言子集的顺序功能图 HR HR HR HR
语言
指令表语言 R NR NR
具有专门定义的语言子集的指令表语言 HR R R R
表4中R为推荐，HR为强烈推荐。
PLCopen[~际组织与专业从事安全认证的权威机构TOV一
起定义了在IEC 61 13 1-3的环境下涉及机械安全的规范((Safety
Software Technical Specification))。其中仅规定了两种具有定义子
集的语言(功能块图语言FBDff~梯形图语言LD)可用于机械安全
系统。
参考文献：
⋯ IEC 61508 Functional Safety ofElectrical／Electronic／Programming
Electronic Safety·Related systems Part 0-Part 7
『22 JIEC 6151l Functional Safety— SafetyInstrumented Systemsforthe
Process Industr Sector．
[3]MindaZhao(AECL，加拿大原子能公司)．Nuclear Safety—Critical
Software V&amp;amp;V Technology．
[4]M．Hecht，R．Brill Review Guideline for Software Written in High Level
Programming Land au s Used in Safety Systems．
[5]PLCopen．Safety Software Technical Specification．

网友评论 more

综合安全论文最新内容

05-04