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

专家分析

彭瑜，男，中国自动化学会理事。中国自动化学会仪表和装置专业委员会常务委员。中国自动化学会专家咨询委员会委员，上海市自动化学会常务理事，中国仪器仪表学会专家委员会委员，ＰＬＣｏｐｃｎ国际组织中国委员会主席。长期从事现场设备的无线通信等方面的研究。

从实现过程功能安全要求的基本规范ＩＥＣ６１５１１所给出过程工业中工厂安全保护防灾结构体系（见图１），可以清晰地看出安全仪表控制系统ＳＩＳ是过程工业预防灾害和减灾的两个重要环节，确

保安全仪表系统的功能安全则是预防和减灾的一种基础保证。本

文希望从功能安全的基本概念出发讨论怎么才能切实实现控制系

统的概念安全。

圈１工厂安全保护防灾结构体系

４０－Ａ自Ｕｉ慧剿。罂慧腮

万方数据

上海工业自动化仪表研究院彭瑜

ｌ

控制系统功能安全的国际标准

ＩＥＣ６１５０８／ＧＢ２０４３８《电子／电气厂可编程电子安全相关系统的

功能安全》是一个宏标准，规范了满足安全相关系统功能安全的基本要求和规则。通过应用严格的系统性的过程，以可追溯性，关键性分析、验证（ｖｅｒｉｆｉｃａｔｉｏｎ）和确认（ｖａｌｉｄａｔｉｏｎ）的程序为重点，来评估是否满足功能安全的标准要求。ＩＥＣ６１５０８标准的一个重要突破就是制订了一整套完整的开发程序和一系列的技术措施，通过严格的质量管理与全生命周期的程序控制。达到实现避免故障、排除故障及一定程度上容许故障的目的。

１ＥＣ

６１５０８共有８个部分，即：

・

ＩＥＣ

６１５０８－０：功能安全和ＩＥＣ

６１５０８Ｉ

・

ＩＥＣ６１５０８一ｌ：一般要求Ｉ・

ＩＥＣ

６１５０８－２：电气／电子，可编程电子安全相关系统的要

求Ｉ

・

ＩＥＣ６１５０８－３：软件要求；・

ＩＥＣ６１５０８－４：定义和缩略语Ｉ・

ＩＥＣ

６１５０８－５：确定安全完整性等级的方法示例ｌ

・

ＩＥＣ６１５０８－６：ＩＥＣ

６１５０８—２和ＩＥＣ６１５０８・３的应用指南Ｉ

・

ＩＥＣ６１５０８－７：技术和措施概述。

在不同应用领域更细化和具体实现功能安全，又开发了进一步的规范，如：

・

实现机械功能安全要求的基本规范ＩＥＣ

６２０６１。

・

实现过程功能安全要求的基本规范ＩＥＣ６１５１１。・

实现核电功能安全要求的基本规范ＩＥＣ

６１５１３Ｉ

・

实现医疗设备的功能安全要求的基本规范ＩＥＣ６０６０１ｌ

・

实现铁道运输安全的规范ＥＮ

５０１２８，

２

控制系统功能安全的基本概念

安全系统的关键性分多个层次：

・

安全关键（ｓａｆｃｔｙ－ｃｒｉｔｉｃａｌ）系统：单个缺陷或失效会造成危

险的故障，如核电站原子反应堆的停堆系统。

・

安全相关（ｓａｆｅｔｙ－ｒｅｌｅｖａｎｔ）系统：单个缺陷或失效与第二

个缺陷或失效会造成危险的故障，如石化行业的安全仪表系统。

・

非安全相关（ｉｎｔｅｒｆｅｒｅｎｃｅ・ｆｒｅｅ）系统：即使多个缺陷或失

效也不致造成危险的故障。

对安全要求最高的安全关键系统，必然为实现其安全要求而最耗费时间、成本最高，认证的过程和程序最复杂。对安全的要求相对较低的安全相关系统，以及对安全要求更低的非安全相关系统，相应在时间、成本和认证所耗费的努力逐级递减。

在ＩＥＣ６１５０８的标准中，对石化和化工行业广泛应用的安全相关系统有着严格的定义和要求：

・

必须在受控装置ＥＵＣＪ临近风险或危险状态情况下，能执

行所要求的安全功能，使ＥＵＣ达到或保持安全状态，

・

依靠安全相关系统本身，或与其它Ｅ／Ｅ／ＰＥ安全相关系

统、其它技术的安全相关系统或外部风险降低设施共同作用，达到所要求的安全功能必需的安全完整性。例如图２所示的一个化工厂常见的加热搅拌系统，除了用圆圈标出的是一个安全仪表系统（ＳＩＳ）而外，安全阀就是使用机械保护的安全系统，它们配合使用达到必需的安全完整性。

这将安全相关系统在工厂预防和减灾中的作用明确规定如下：首先，由安全相关系统与外部风险降低设施共同作用，使受控设备达到必要的风险降低量，以满足所要求的允许风险。其次，安全相关系统是在接受命令时，采取适当的顺序动作防止ＥＵＣ进入危险状态。一旦安全相关系统失效，也属于导致危险或危害的事件。第三，即使还有其他的具备安全功能的系统，但所指定的安全相关系统仅靠其本身的能力（而非其他系统）就能达到所要求的允许风险。第四，安全相关系统一般分为安全控制系统和安全防护系统，并且具有两种操作模式。

从安全相关系统的构成来看，它可以是ＥＵＣ控制系统的一个组成部分，也可用传感器和／或执行器与ＥＵＣ接口，即可通过实现ＥＵＣ控制系统中的安全功能（也可能通过分开的和独立的附加系统）达到要求的安全完整性等级，或者利用分离的、独立．专门的安全相关系统实现安全功能。

这就明确告诉我们，安全相关系统的功能可能包括：用于防止危险事件发生，即安全相关系统一旦执行其安全功能，则不致发生有危险事件；用来减轻危险事件的影响，即通过减轻后果降低风险。或者同时具有上述的组合功能。

人也可作为安全相关系统的一部分，例如，人可以接收来自可编程电子装置的信息，并通过该装置按接收信息要求执行安全动作。

安全相关系统包括执行安全功能所需的全部硬件、软件以及支持服务（如电源、传感器和其它输入装置、执行器和其它输出装置也包括在安全相关系统中）。

万方数据

安全相关系统的技术基础范围可以十分广泛，包括电气，电子，可编程电子、液压和气动等。

图２

ＳＩＳ和安全阀配合使用的化工加热搅拌系统的Ｐ＆ＩＤ

由于在工厂安全保护防灾的体系结构中对不同的装置，系统，甚至系统内的各个子系统或部件的安全要求常常有很大差异，因此，ＩＥＣ６１５０８标准允许对一个系统的子系统和部件进行独立的评估。所以，我们在谈论功能安全时要严格区分所指的对象是系统，还是构成系统的部件或子系统。

３

控制系统的安全完整性及其等级

安全完整性是指在规定的条件下，规定的时间内，安全相关

系统成功地实现所要求的安全功能的概率。众所周知，控制系统由构成其系统的各种硬件（控制系统装置，现场仪表、通信网络等等）以及执行控制要求和功能的软件综合而成，因此控制系统的安全完整性由硬件的安全完整性和系统的安全完整性组成。硬件安全完整性是在危险失效模式中对应于安全相关系统安全完整性的硬件随机失效的那一部分，一般可以通过所要求的硬件安全功能失效率予以量化，而系统安全完整性则是指在危险失效模式中对应于安全相关系统安全完整性的系统失效的部分（包括软件失效）。控制失效与避免失效涉及设计，操作模式等诸多环节。显然，硬件随机失效和系统失效的机制不同，控制失效的方法也不同（见图３）。

可以通过改变设计、生产过程、摄作梗式、操作指令或其他影响因子，来清除原因确定的失效，

ｌ

ｌ

鼍免失效估算由于随机硬件失效造成的每控铡失效

个安全功能的失效概率

田３控制系统失效机理

票鬻测驰篙貉４１

—五ＤＴ０１神Ａ彳ｉ石Ｎ—］亭鬲嗣。膏五丽

专冢分析

在安全相关系统中，安全完整性的要求用４个离散的等级予以划分，ＩｉｐＳｌｔＡ，ＳＩＬ３。ＳＩＬ２和ＳＩＬｌ。安全完整性的等级越高的安全相关系统，其执行所要求的安全功能的概率也越高。

根据安全相关系统的使用方式、所要求发生的频率，可分为低要求操作模式和高要求（或连续）操作模式。低要求操作模式对应于每年发生风险的次数多于等于１次的安全相关系统；高要求（或连续）操作模式对应于每年发生风险的次数少于１次的安全相关系统。表ｌ是ＩＥＣ

６１５０８ｌ／ＧＢ／Ｔ

２０４３８规定的低要

求操作模式下的安全完整性的目标失效概率和目标风险降低因子，表２是高要求（或连续）操作模式的安全完整性的目标失效概率。

ＳＩＬ３被认为是单个可编程系统中可达到的风险降低的最高等级。

寰１低要求操作模式下的安全完整性的目标失效概率和

目标风险降低因子

安全完整性等级目标平均失效概率

目标风险降低因子

（ＳＩＬ）

４

２ｌ旷一＜１０４＞１００００一≤１０００００３２１０４一＜１０

３

＞１０００一！１００００２２ｌＯ。’一＜１０。２

＞１００一！１０００

１

＞１０。’一＜１０。１

＞１０一！１００

表２高要求（或连续）操作模式的安全完整性的

目标失效概率（每小时）

安全完整性等级

目标平均失效概率平均发生１次失效的

（ＳＩＬ）

（每小时）

年数

４＞１０一一＜１０。８１１４００一１１４０００

３＞１０一一＜１０’７１１４０一１１４００２≥１０～一＜１０。６１１４—１１４０ｌ

＞１０４一＜１０。５

１１．４—１１４

４

安全系统的多样性（ｄｉｖｅｒｓｉｔｙ）原则

安全系统可以采取多样性原则克服可能发生的故障，或设计

分析中存在的不确定性。多样性是指用不同方法执行所要求同一功能。例如：可用不同的物理方法或不同的设计途径来达到多样性。

多样性分为；①信号多样性；②功能多样性，③设备多样性ｌ④软件多样性（如指令运算的多样性），⑤人员多样性等等。其中较为常用和有效的是信号多样性和功能多样性。

对所采用的多样性措施是否适当应加以论证。为了保证能切实执行多样性，对设备的多样性或仪表控制系统的软件多样性所进行的论证，必须扩展到这些设备的硬件、软件部件，如实时操作系统ＲＴＯＳ。

图４是Ｓ７．４００Ｆ运用指令运算的多样性和时间冗余来提高安全功能的可靠性。操作数Ａ．Ｂ在ＣＰＵＩ进行。与”运算，结果

４２

自勋化．博览２０１０年１２月刊

７旺『ｉｎ冒啊五Ｔ兀玎ｒ．ｊ万霸ｏＲＡＭ五一

万方数据

为Ｃｌ

Ａ，Ｂ经过编码变成字Ａ，Ｂ，在ＣＰＵ２ｑｂ傲。或”运算，

结果为Ｄ＝／Ｃ。在比较器中进行比较运算，仅当Ｄ≠／Ｃ时输出停机信号。

！！竺竺！！！竺！塑！空

－Ｔｉｍｅ

圈４运用指令运算的多样性和时间冗余来提高安全功能的可靠性再如某核电站的紧急停堆系统由两个完全独立的系统构成。其安全控制系统由不同的供应商提供。一个停堆控制系统采用安全ＰＬＣ系统，由３个独立的３机冗余表决的分系统（Ｄ、Ｅ、Ｆ）组成（见图５）。每个分系统都具备停堆功能，但其停堆输出还要

送给３取２的继电器硬逻辑进行表决，最终给出停堆信号。该安全ＰＬＣ系统硬件平台配有操作系统，运用符合工业控制编程语言的国际标准ＩＥＣ６１１３１－３所规范的功能块图语言（ＦＢＤ）编制应用软件。这套停堆控制系统采用了综合法（ＩｎｔｅｇｒａｔｅｄＡｐｐｒｏａｃｈ）设计。

值得注意的是，为了实现安全系统的机理多样性，还设置

了另一套完全不同机理的停堆系统，通过将有害的中子吸收剂（ｐｏｉｓｏｎ）注入反应堆中的慢化剂（ｍｏｄｅｒａｔｏｒ）的方法进行停堆

控制。这一停堆控制系统采用没有操作系统的工控机硬件平台，安全控制软件运用高安全的具有子集的ＭＯＤＵＬＡ－２语言编写。这一套系统使用的是另一种设计方法一合理设计流程法（ｒａｔｉｏｎａｌ

ｄｅｓｉｇｎ

ｐｒｏｃｅｓｓ），用确定离子室记录的功率信号的合理性来检查

异常差错信息。由此可见，在要求极高的安全关键系统中充分运用了多样性的原则，有：机理的多样性、设计方法的多样性、设

备的多样性，编程语言的多样性，这样就从系统的层面上把同时发生差错的概率降至尽可能的小。

田５采用３套３机冗余表决的安全ＰＬＣ系统构成的停堆控制系统

５重视处理假事件

各种安全系统（包括紧急停车系统ＥＳＤ）如果对假事件作出响应，造成非计划停车，不但要付出高昂代价，而且在大多数

ＯＴＵ３

情况下具有危险性。大量的假报警还会导致操作人员产生矛盾心理，以至于对危险的真报警都不予理会，或者反映很慢。

产生假事件的原因：①现场设备的硬件故障，如压力开关、电磁阀的线圈或常闭触点存在高电阻，ＰＬＣ的Ｉ／Ｏ模块有故障，现场设备中电子器件有故障，热电偶断偶，热电阻断线等，这些明显的设备故障都会引发假事件。②一些公用故障如电源、气源故障也会引发假事件。⑦缺乏维护，不及时对工作有缺陷的仪表、传感器进行测试、校验，是引发假事件的重要原因。

下面讨论信号多样性问题。看一个用３个浮球液位开关测量液位的简单例子（图６）。我们可以有４种配置。采用单信号、双信号还是三信号更有利于安全和可靠的平衡呢？概括地说：采用单机（单信号）系统不安全且不可靠，在故障安全（假事件）或危险方面存在５０／５０的概率ｌ采用双机（双信号）系统配置为二取一（１００２），可能较安全，但存在高的假故障率，双机（双信号）系统配置为二取二（２００２），由假事件引起的故障率较低，但安全性差；三机（三信号）冗余系统为三取二（２００３），提供可以接受的安全与可靠的平衡。

圉６用３个浮球液位开关测量液位可能的配置

显然，Ｓ１Ｓ／ＥＳＤ不能选择单机（单信号）系统。选用双机

（双信号）系统，在一定程度上可达到安全和可用性。二取一（１００２）安全性较好，但可靠性及假事件的影响大，二取二（２００２）可靠性较好，安全性却较差。即使双机（双信号）系统具有很好的自诊断性能，可以确定采用哪个通道或处理器故障，将坏的通道或处理器剔除，但这时双机系统降格为单机系统。三取二（２００３）独特的优点是不考虑哪个通道发生故障，是怎么发生故障的；也不完全依靠自诊断来确定哪个通道投用。其亮点在于它仅要求所接收到的信息。三取二表明，若有一个信号不同于另外两个信号，立即报警，而这两个信号相同的通道处于安全工作状态。

从图６所示的例子可知，如果流程要求用于液位测量的仪表每年只能发生１次故障，而且每半年对浮球开关进行一次维护测试，那么对于不同的浮球液位开关配置，因故障造成危险的年概率如表３所示。

万方数据

裹３浮球液位开关不同配置的因故障造成危险的概率

仪表信号配置

故障危险概率

假事件故障概率

故障危险概率（每半年维修１次）

ｌｏｏｌ１／１０１／１０ｌ／２０ｌ００２ｌ／１００

ｌ／５１／１６００２００２ｌ／５

ｌ门００ｌ／２０２００３

ｌ／３３

ｉ／３３

ｌ／５３４

６

软件的可靠性难以精确量化

软件可靠性的基本问题是：①软件不受物理故障的影响。随

着硬件元器件的可靠性越来越高，并可以采用冗余技术，因而安全问题的矛盾集中到了软件，以至于今天我们看到大多数的系统失效源自软件。失效常常由于一些非明显的事件组合造成，而不是由于机械应力超过一定程度造成。而这些非明显因素往往事先没有估计到，所以在软件的编制中考虑不到。②软件是由人来设计的，软件的设计不可能面面俱到，总有些因素在设计时没有考虑到，因此，设计的缺陷导致软件的故障。③数字系统本质上是非连续的，所以输入对输出的映射一定是不连续的。④软件建立在模型化和测试的基础上，这些工作都是人在做的。人难免犯错误，所以影响软件的可信度。

因为以上这些不可避免的问题，可以得出软件的可靠性难以精确量化的结论。另外，从趋势上讲，软件和人为因素导致失效，事故和停机的比例越来越高。因为现在对软件的依赖越来越高，软件变得越来越复杂，因而难以控制。人犯错误不可避免。硬件失效可能是系统失效的原因，系统的失效会引起软件的失效。有鉴于此，要保证工业控制软件的功能安全就不得不依赖于对软件进行严格的验证和确认。

７

工业控制软件的功能安全概念和方法

ＩＥＣ

６１５０８—１规定了整体安全生命周期的１６个阶段，包括：概

念，整体范围定义，危险和风险分析，整体安全要求，安全要求分

配，整体操作和维护计划编制，整体安全确认计划编制，整体安装和试运行计划编制，Ｅ／Ｅ／ＰＥ安全相关系统：实现，其他技术安全相关系统：实现，外部风险降低设施：实现，整体安装和试运行，整体安全确认，整体操作维护和修理，整体修改和改型，停用及处理。与软件相关的是第９阶段“Ｆ．／Ｅ／ＰＥ安全相关系统：实现”在ＩＥＣ６１５０８—３中详细地规定了执行安全功能的软件如何满足面：软件质量管理系统，软件安全生命周期要求，软件功能安全么要求，以及如何来验证工控软件达到了功能安全的标准。ＩＥＣ６１５０８—３的突出贡献在于制订了一整套完整的开发程序和一系列避免故障、检测故障和排除故障，以及容许存在故障，从而保证嚣燃一鱼咝４—Ａ

ＭＡｆｒ石Ｎ一——

ＰＡＮＯＲＡＭＡ

技术措施，通过严格的质量管理与全生命周期的控制程序，实现评估。它给出的是在软件的安全生命周期的各个阶段应该满足什功能安全的要求。它规范的工控软件的功能安全问题包括以下方

专家分析

软件的安全完整性能。总之，ＩＥＣ６１５０８—３给出了在安全相关系统的软件编制时应遵循哪些规范就能够达到功能安全的要求。这好比它编织了安全软件开发的。鸟笼”，以及在“鸟笼”里飞必须遵守的规则和约束；一旦飞出。鸟笼”就不能保证软件的安全。但它并没有具体规定工控软件在选用编制系统软件和编制应用软件时，应该如何选择适当的编程语言、指令集和数据类型，就可以从基础上保证软件的功能安全性。这些问题有些可以通过ＩＥＣ６１５０８・６（ＩＥＣ６１５０８—２和ＩＥＣ６１５０８．３的应用指南）和ＩＥＣ

６１５０８

－７（技术和措施概述）找到相应的具有实用性的参考规定和资料，有些就必须再进一步查找其它围绕不同应用领域的工业控制软件的功能安全的规范，如美国核管制委员会ＮＲＣ发布的《（核电站软件语言导则》．ＰＬＣｏｐｅｎ国际组织发布的在ＩＥＣ６１

１３１・３的

开发环境下有关机械功能安全的规范《ＳａｌｔｙＳｏｆｔｗａｒｅＴｅｃｈｎｉｃａｌ

Ｓｐｅｃｉｆｉｃａｔｉｏｎ））等等。

众所周知，安全相关系统包括硬件、软件，软件必须运行于硬件系统环境中才能实现其价值和功能，在完成系统的功能安全时，一定要认识这二者之间的关系。通过图７所揭示的ＩＥＣ６１５０８－３与ＩＥＣ６１５０８—２的关系就能一目了然：ＩＥＣ６１５０８－２是总体，ＩＥＣ６１５０８—３只是局部。尽管它们可能是由不同的团队独立开发，但最终还是要集成起来经过总体检验，才能够判断是否满足安全要求。

图７在实现系统功能安全时ＩＥＣ６１５０８－３与ＩＥＣ６１５０８．２的关系

软件的安全完整性等级采用表１低要求操作模式下的安全完整性的目标失效概率划分。达到ＳＩＬ４等级的软件相当于每１．１４年至１１．４年之间发生１次失效。

８安全系统的软件构成

与控制系统的软件构成一样，安全系统的软件也包括系统软件和应用软件两部分（见图８）。它们分别用全可变语言（ｆｕｌｌ

ｖａｒｉａｂｉｌｉｔｙ

ｌａｎｇｕａｇｅ，ＦＶＬ）和有限可变语言（１ｉｍｉｔｅｄｖａｒｉａｂｉｌｉｔｙ

ｌａｎｇｕａｇｅ，ＬＶＬ）编写（见图７）．这些概念都是将软件引入功能安全时建立起来的。

什么是全可变语言呢？其实此类语言就是计算机编程人员广泛使用的语言，它提供实现各种功能和应用的能力。典型的利

４４慧然乒雩２黧三熙

万方数据

用全可变语言的系统就是通用计算机。在过程工业中，只有在嵌入式软件（一般指固件或系统软件）中才使用全可变语言，极少在应用程序中使用。ＡＤＡ、Ｃ、Ｃ＋＋、指令表ＩＬ、Ｐａｓｃａｌ、Ｊａｖａ、ＳＱＬ均属于全可变语言。

有限可变语言在ＩＥＣ

６１

５０８—４中定义为：在工业和商业可编

程电子控制器中使用且范围局限于应用程序的文本的或图形的软件编程语言。例如：引自ＩＥＣ６１１３Ｉ－３和其它标准或规范的有限可变语言，用来编写ＰＬＣ系统的应用程序。它们分别是梯形图语言ＬＤ・布尔代数语言：带有增加某些记忆指令能力的，基于布尔运算符（女Ｉ］ＡＮＤ、ＯＲ和ＮＯＴ）的低级语言Ｉ功能块图语言ＦＢＤ：除布尔运算符外，可使用更复杂的功能，如数据传输文件、块传输读／写，移位寄存器和序列发生器指令等；顺序功能图语言ＳＦＣ：有顺序之程序的图形表示，由相互联系的步骤、动作和带转换条件的定向连接线构成。

图８功能安全用编程语言的构成

９

软件功能安全对编程语言的要求

编程语言并不是专为安全系统开发的，它们在出现安全软件

的概念之前就发展了很长的时间。所以要用ＦＶＬ和ＬＶＬ完成安全系统的软件编写，首先必须对这些语言和用它们编写的程序提出要求和进行评估，以确定在什么条件下使用这些语言就能确保安全软件完成其保证功能安全的任务。

从另一方面来看，由于嵌入式系统已渗透到各行各业，这些年来，凡是对安全有重要要求的行业都很关注这个问题，制

定了各自的规范。例如汽车行业建立了汽车工业软件可靠性协会ＭＩＳＲＡ，发布了专门用在汽车行业的ｃ＋＋语言的子集ＭＩＳＲＡＣ＋＋。美国核管制委员会ＮＲＣ早在１９９６年就发布了《核电站软件语言导则》，之后９７年又公布了其修正版ＮＵＲＥＧ／ＣＲ

６４６３

Ｒｅｖ．１。因为其权威性，直至现在它已成为安全软件的经典规范。

不仅仅是核电，其它行业的软件安全问题也经常以此作为引经据典的文献。

在美国的核管制委员会发布了《核电站软件语言导则》

ＮＵＲＥＧ／ＣＲ６４６３Ｒｅｖ．１中，对用高级语言编写的用于安全系统的

软件进行了安全评述，着重指出以往发现的软件安全性问题和缺陷，从对应用重要性的理解、设计的方法论、学科发展和测试等方面加以阐述。

ＮＵＲＥＧ／ＣＲ

６４６３

Ｒｅｖ．１将软件安全的属性按三级架构加以分

类和编排：顶级属性．中间属性和基本属性，如图９所示。豳９软件安全的三级架构属性

软件的可靠性属性是在所规定的条件下软件的可预测、且恒定一致的性能。由于软件的可靠性属性旨在减少在软件开发实现期间可能被导入源代码而造成误操作的故障，所以此顶级属性对安全来说是很重要的。

软件的鲁棒性是在异常条件或事件下，安全系统的软件以一种可接受的方式进行操作的能力。由于它加强了软件处理例外情况、从内部故障中恢复，以及阻止因异常环境而致使故障传播的能力，因此此顶级属性也很重要。

软件的可追溯性表现为：①对源代码和所引用的程序库部件的源头进行检查和识别－⑦通过对开发过程的可行性进行检查，来验证已执行的代码在其开发过程中是否按规范的方法完成其实现；⑦审视代码与高一级的设计文档相关联的能力。此属性之所以重要是因为这将便于对软件进行验证和认证（Ｖ＆Ｖ），这是软件质量保证的另一方面。

软件的可维护性是在软件交付使用后若需对源代码做改动时，导致将故障引入的可能性减少的必要手段。此属性之所以对安全来说很重要，是因为在对软件进是因为在对软件进行适应、校正或完善期间可以尽量减少可能发生的误操作的故障。

根据ＩＥＥＥ所给出的规定，软件可靠性是在软件编制，调试和执行运行全过程的环境下，既可以是在所定义的时间间隔内和所定义的条件下成功执行的几率，也可以是按照命令成功操作的几率。软件执行完成是其对于系统存贮器和程序逻辑恰当行为的结果。这

墨嚣三’哥娃：：曩

Ｉ

ｌ

ｌ

ｌ

【存贮空问藕用的可预舅性ｌ

控制流的可预舅性ｌ。时序的可琢舅性．］

Ｉ－动态存贮分配的・４、化

一结构最大化

卜

Ｌ内存分页和存贮空同对

二嚣蔫荔耄蓑雌批Ｌ尽可蠢少用任务

挠的最小化

一子程序的进入点和出口锅妙一用务

一不用赋值语句一界面歧义最小化一采用敦据健入

一准确度．精度进行记曩一捧定优先级

一蕾免执行于程序产生的

状态变化一将求值与赋值焉开一动奄绑定量小化

图ｌＯ可靠性的中间属性

万方数据

意味着软件所产生的适时输出是编程人员对所使用的语言结构和运行期间环境特性理解的函数。因此可靠性的中间属性包括：存贮空间利用可预测性（软件不致造成处理器会向非预期的或不允许存贮空间进行存取的高概率）；控制流可预测性（处理器按编程员预期的顺序执行指令的高概率）ｔ时序可预测性（软件在所定义的运行环境下满足响应时间和处理能力约束的高概率）・数学结果或逻辑结果可预测性（软件在所定义的运行环境下产生编程员所预期结果的高概率）。详见图ｌＯ。

所谓软件鲁棒性是指在异常或其他未曾预计的情况下软件继

全系统而言鲁棒性之所以重要是因为在一个意外或偏离额定工况时会发生未曾预料的事件，在这样的情况下软件持续的对系统监控和控制的能力仍能有效作用。软件鲁棒性的中间属性和基础属性见图１ｌ。

图１１软件鲁棒性的中间属性和基础属性

软件的可追溯性是指与软件设计相比较，安全软件的那些支持其正确性和完整性验证的属性。可追溯性的基础属性有：可读的可控使用。

软件的可维护性是为了有效减少在对软件进行修改时可能引入的差错。会影响安全的与可维护性有关的中间属性（见图１２）包括：可读性一便于项目人员对软件的理解的软件属性；数据的改软件时意想不到的副作用和次生的影响减至最小；函数的内聚可移植性一避免一种语言的非标准函数对安全的重大威胁；可塑田１２可维护性有关的中间属性

名慧蒜熊燃４Ｓ

—百ＩＪ亍。葡哺ｉ耵石葡——乒Ａ对。再五ｌ－晤

续执行的能力。鲁棒性的同义词是耐久性（ｓｕｒｖｉｖａｂｉｌｉｔｙ）。对安性（这也是可维护性的属性），内嵌函数的可控的使用，编译库抽象一对于那些代码被划分和模块化的区域，这样做可以使在修性一对代码中的软件元素给予设计水平的函数适当的存贮地址，性一将可能修改的代码区与软件代码的其余部分隔离开。

专冢分析

ｌ

０编程语言实现软件功能安全的方法

在ＮＲＣ的ＮＵＲＥＧ／ＣＲ

６４６３Ｒｅｖ．１完整版本中给出了将９种编

程语言（Ａｄａ，Ａｄａ９５，∞＋＋，Ｐａｓｃａｌ，ＰＬ／Ｍ，ＩＥＣ６１１３１・３规定

的梯形图、顺序功能图，结构化文本和功能块图）用于安全系统时，应该关注它们特定的存在问题和如何加以克服注意点。譬如，对于Ｃ语言来说，是其指针的初始化问题ｌ对于ＩＥＣ

６１１３１－３

所规范的编程语言，则应关注其时序、正常运行的监控，以及故障处理等问题。

从顶级属性中的可靠性、中级属性中的可预测性的控制流和基础属性中的在使用前变量的初始化这三方面导出对指针初始化的指导原则。所有的变量和指针在使用前都应该初始化。Ｃ语言支持通过说明来指定初始值的方式进行初始化，但并不要求所有的对象（指变量、数据结构或数组）进行初始化。在若干情况下，一个对象的初始化不仅要为对象的存贮地址指定一个特定的位的组合值，而且还要采取特殊的动作来为对象的生命（例如为对象赋予对应的源）进行平滑初始化。在ｃ＋＋中，可能要考虑任意相关数据作为对象，并提供构造数据组一个实例的工具。这样便会以系统的方式破坏数据组当前的实例。

考虑到上述情况，必须对初始化提出以下导则：①不要对超出其说明范围的变量自动使用指针。存贮在指针的值对一个自动变量会包含超出其函数范围的无用输入。②指针的初始化，初始化问题也会在指针中发生。在安全系统中所有ｃ语言中的指针变量，其初值都应该为ｎｕｌｌ；所有Ｃ＋＋中的指针变量，其初值都应该为０。在被使用之前，指针应对一个有效值予以测试。当一个指针被定义时，它没有一个地址与其相关联。使用一个未初始化的指针，会造成重写未曾预想到的指针的存贮地址。错误地重写存贮内容会引起严重的问题，包括对系统的崩溃。⑦要确保每一个指针的说明间接的运算符都是存在的。每个指针都应该有一个间接运算符（。）。

ＩＥＣ

６１１３１．３所定义的５种语言除指令表语言（ＩＬ）与汇编语

言相似外，其它语言都纳入了ＮＲＣ关于编程语言的导则中。对这些语言特定的指导原则源于鲁棒性顶级属性和异常处理的中间属性。应该专注于在机组紧急停车时ＰＬＣ的行为。通常此时所有的输出均应切断，但往往并非总是如此。一般ＰＬＣ系统总是设计成在紧急停车时系统处于故障安全状态。某些ＰＬＣ在遇到这样的情况时具有处理器能自动停止主梯形图程序的执行，转而执行。故障程序”的子程序。这使系统的设计者可以决定采取适当的动作，包括以一种安全的方式让系统停下来。问题在于：ＩＥＣ６１１３１—３规范中未涉及到允许ＰＬＣ系统本身包含有某种预先设计好的硬件故障程序，当检测到一定范围的故障条件时便会自动执行。不过，ＩＥＣ６１１３１．３允许建立非周期的任务，通过触发适当的内部诊断信息来执行处理特定类型的出错（ＦＯ故障时降级运行模

４６躲篇阮孑叩燃

万方数据

式、向操作员见面报警等）。

对于ＰＬＣ系统，在编程的设计阶段就应在程序结构中考虑故障程序问题。这时必须遵从如下原则：①完整住故障程序不能依赖于检测到程序崩溃的所有特例，因此遇到ＰＬＣ的主要故障时要有针对附加措施的安全保证。②可观察性故障程序要有状态记录和报警的能力。故障程序应显性执行，不被掩盖。⑦真实性检查在启动故障程序的情况下有可能将可以反映原来条件的程序存贮内容、数据文件或Ｉ／Ｏ状态破坏，因此故障程序应保证在执行故障处理前将这些环境加以保存，以便事后分析。④在故障程序不起作用时的故肇安全特性万一ＰＬＣ系统的故障处理程序不起作用，系统设计仍要保证安全状态的后备措施。

ＰＬＣ系统一般以指定的位和字的形式提供对应用程序的正常运行状况的监控，这些信息包括特定任务的执行时间，Ｉ／Ｏ刷新信息．Ｉ／Ｏ操作状态信息，电池状态信息和其它用来确定ＰＬＣ正常运行状态的信息。遗憾的是ＩＥＣ６１１３１・３规范中对这些信息的典型值、范围和类型并未做出规定。而安全系统恰恰应该具备这些信息，作为判断其是否运行正常的检查和是否需要异常处理的不可或缺的部分。

在ＩＥＣ

６１

１３１－３的规范关于。任务。这节中，阐述了制造厂

应向用户提供所有任务执行的信息的最低要求。关键在于由于这一问题的分类落在出错检查，而未能在规范中描述，于是我们也得不到这些任务执行时在运行时应以何种形式接受检查的规定。另外，许多ＰＬＣ和类似的符合ＩＥＣ６１１３１－３的系统一般只给出每次执行所有任务的周期（即所谓的扫描周期），却忽略了单个任务执行周期信息和标志的提供。如果因为安全原因需要在执行某个任务超时Ｎ次时必须紧急停车，在ＰＬＣ现有的能力下是无能为力的。为了解决这个问题，必须让应用程序能够对单个任务执行其超时的检测，并给出单任务超时的标志，这样才能做出适当的反应。对于安全关键系统，监控任务超时的问飚尤其要紧。必须在程序开发的检查阶段关注。

１

ｌ在安全系统中推荐采用的编程语言

在ＩＥＣ６１５０８－７的附录Ｃ．４．５中给出了适合用于安全系统的软

件编制推荐的语言（见表４），表中列举了２４种编程语言，其中适用于安全系统的软件编制的语言共９种，它们是：属于全可变语言ＦＶＬ确泌种（具有子集的ＡＤＡ，具有子集的ＭＯＤＵＬＡ一２，具有子集的Ｐａｓｃａｌ，具有子集的ＦＯＲＴＲＡＮ７７，具有子集和编程标准并使用静态分析工具的Ｃ），属于有限可变语言ＬＶＬ有４种（具有定义的语言子集的梯形图，具有定义的语言子集的功能块图，具有定义的语言子集的结构化文本，具有定义的语言子集的顺序功能图）。

＞）．＞、＇＞＞＞＞＞≯哆下转５０页

柔例推歹ｒ

场调试中最初软件工程师设置的采样时间全为１ｓ，死区为０，这样文件很大。环保检查时要求调出一个月的相关历史数据，在历史站调出１个月的趋势图的时间很长，甚至长达几个小时，让核查人员无法忍受。经过优化以后，采用本文前面的办法，历史数据文件容量减小为原来的ｌ％以下，调出同样时间段的数据的时间减少到ｌ￣２分钟，这个时间应能接受。

在调试现场要检验参数设置优化后的效果，是否只有等待１个月的时间，等一个月的历史数据形成后才能验证调出时间？答案是否定的，采用好的办法，可以在半个小时内检验调出１个月历史趋势记录的时间：

（１）ｉＦｉｘ的历史记录参数优化后，重新启动软件，２４小时后得到ＩＸ的数据文件ｌ

（２）拷贝并复制３０个这样的文件；

（３）逐个修改文件名，即修改文件的生成时间。

这样快速地得到了１个月历史记录数据，数据是重复的，每天相同。用于来测试参数优化后历史数据的调出时间是合适和可行的，可以调出重复的３０天或更多天的数据。我们在做文件复制前，应将已经生成的历史数据做好备份，以便事后恢复。这个方法只能用于试验，生产运行中不能对历史数据做修改和拷贝，如果有操作也将被记录。对脱硫装置这样的环保设施，如果数据作假，查实后将会受到环保部门的严厉惩罚。

６结束语

ＧＥ

ｉＦＩＸ作为优秀的ＳＣＡＤＡ软件，适合于多数的工业自动

化生产过程控制。对项目中具体参数的历史记录应按工艺过程的条件和要求，设置采取合理的参数，实现历史记录数据的有效和优化。如果企业对历史数据记录的要求更高，如毫秒级采样，数据量大（全厂级，几万点），则应采用Ｐｒｏｆｉｃｙ

Ｈｉｓｔｏｒｉａｎ

（ｉＨｉｓｔｏｒｉａｎ作为企业级实时历史数据库平台，可以极高的速度采集，归档并发布海量实时的现场过程信息【５１）或其它的专用数

据库软件。够

参考文献：

【ｌ】基于ＡＤＯ技术的ｉＦｉｘ历史报表的设计与实现【Ｊ】．自动化信息，２０１０．８．【２】ｉＦＩＸ监控软件在烟草制丝线的集成应用（二）【ＥＢ／ｏＬ】．ｈａｐ：／／ｗｗｗ．ｚｇｚｎｈ．

ｃｏｍ／ａｒｔｉｃｌｅ—ｓｈｏｗ．ａｓｐ？ａｒｔｉｃｌｅｉｄ＝５８０８１０。２０１０—０６—０９．

【３】ＰｒｏｆｉｃｙＨＭＩＳＣＡＤＡ．ｉＦｉｘ４．０电子书．

【４】曲晓俊，马彩．ｉＦＩＸ组态软件中通用趋势曲线的没计与实现【Ｊ】．工业控制计算机，２００９（２２）３．

【５】ｉＨｉｓｔｏｒｉａｎ在电厂厂级实时监视系统中的解决方案［ＥＢ／ＯＬ］．ｈａｐ：／／ｓｂ９１．

ｉｄｚｊ．ｃｏ．Ａｒｔｉｃｌｅ／２００８０９／２００８０９２４１７２９４０—１２５１４．ｈｔｍｌ，２００８・０９－２４．

５ｏ

ｉＵＴ瓣ＴＩ围盯一Ｐ－－ＡＮＯＲＡＭＡ－

自勋ｆⅥ辱笕２０１０年１２，ＥＪ刊万方数据

＜．“＜＜＜＜（＜＜＜＜上接４６页

表４ＩＥＣ

６１５０８．７推荐的适用于安全系统的软件编制的语言

编程语言

ＳＩＬｌＳＩＬ２ＳＩＬ３ＳＩＬ４ＡＤＡ

ＨＲ

ＨＲ

Ｒ

Ｒ具有子集的ＡＤＡ

ＨＲＨＲＨＲＨＲＭＯＤＵＬＡ．２

ＨＲ

ＨＲ

ＲＲ具有子集的ＭＯＤＵＬＡ－２

ＨＲＨＲ

ＨＲＨＲＰａｓｃａｌ

ＨＲ

ＨＲ

ＲＲ具有子集的ＰａｓｃａｌＨＲＨＲ

ＨＲＨＲＦＯＩ汀ＲＡＮ７７

ＲＲＲＲ

具有子集的ＦＯＲＴＲＡＮ７７ＨＲＨＲ

ＨＲＨＲ

Ｃ语言

ＲＮＲ

ＮＲ具有子集和编程标准并使用静态分析工

ＨＲ

ＨＲＨＲ

ＨＲ

具的Ｃ语言

ＰＬ／Ｍ

Ｒ

ＮＲＮＲ具有子集和编程标准的ＰＬ／Ｍ

ＨＲＲ

Ｒ

Ｒ

汇编语言

ＲＲ具有子集和编码标准的汇编语言

ＲＲ

Ｒ

Ｒ梯形图语言

ＲＲ

ＲＲ具有专门定义的语言子集的梯形图语言ＨＲＨＲ

ＨＲＨＲ功能块图语言

Ｒ

Ｒ

ＲＲ具有专门定义的语言子集的功能块图语

ＨＲＨＲ

ＨＲ

ＨＲ

言

结构化文本语言

ＲＲＲＲ具有专门定义的语言子集的结构化文本

ＨＲ

ＨＲ

ＨＲ

ＨＲ

语言顺序功能图

ＲＲＲＲ

具有专门定义的语言子集的顺序功能图ＨＲ

ＨＲ

ＨＲ

ＨＲ

语言指令表语言

ＲＮＲＮＲ具有专门定义的语言子集的指令表语言

ＨＲ

Ｒ

Ｒ

Ｒ

表４中Ｒ为推荐，ＨＲ为强烈推荐。

ＰＬＣｏｐｅｎ国际组织与专业从事安全认证的权威机构ＴＯＶ一起定义了在ＩＥＣ６１１３１－３的环境下涉及机械安全的规范《Ｓａｆｅｔｙ

ＳｏｆｔｗａｒｅＴｅｃｈｎｉｃａｌ

Ｓｐｅｃｉｆｉｃａｔｉｏｎ））。其中仅规定了两种具有定义子

集的语言（功能块图语言ＦＢＤ和梯形图语言ＬＤ）可用于机械安全

系统。囝

●考文献：【ｌ】ＩＥＣ６１５０８Ｆｕｎｃｔｉｏｎａｌ

ＳａｆｅｔｙｏｆＥｌｅｃｔｒｉｃａｌ／Ｅｌｅｃｔｒｏｎｉｃ／Ｐｒｏｇｒａｍｍｉｎｇ

ＥｌｅｃｔｒｏｎｉｃＳａｆｅｔｙ．ＲｅｌａｔｅｄｓｙｓｔｅｍｓＰａｒｔ

０－Ｐａｒｔ７．

［２１

ＩＥＣ６１５ｌｌ

Ｆｕｎｃｔｉｏｎａｌ

Ｓａｆｅｔｙ—Ｓａｆｅｔｙｌａｓｍａｎｅｎｔ捌ｌＳｙｓｔｅｍｓｆｏｒｔｈｅ

ＰｒｏｃｅｓｓＩｎｄｕｓｔｒｙＳｅｘｔｏｒ．

【３】ＭｉｎｄａＺｈａｏ（ＡＥＣＬ，加拿大原子能公司）．ＮｕｃｌｅａｒＳａｆｅｔｙ－Ｃｒｉｔｉｃａｌ

ＳｏｆｔｗａｒｅＶ＆ＶＴｅｃｈｎｏｌｏｇｙ．

【４】Ｍ．Ｈｅｅｈｔ，Ｒ．Ｂｒｉｌｌ．ＲｅｖｉｅｗＧｕｉｄｅｌｉｎｅ

ｆｏｒ

Ｓｏｆｔｗａｒｅ

Ｗｒｉｔｔｅｎ

ｉｎＨｉｇｈＩ．ｅｖｅＩ

Ｐｒｏｇｒａｍｍｉｎｇ

ＬａｎｇｕａｇｅｓＵｓｅｄｉｎＳａｆｅｔｙＳｙｓｔｅｍｓ．

【５】ＰＬＣｏｐｅｎ．ＳａｆｅｔｙＳｏｆｔｗａｒｅ

Ｔｅｃｈｎｉｃａｌ

Ｓｐｅｃｉｆｉｃａｔｉｏｎ．

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

作者：作者单位：刊名：英文刊名：年，卷(期)：

彭瑜

上海工业自动化仪表研究院自动化博览

AUTOMATION PANORAMA2010,27(12)

参考文献(5条)

1. PLCopen Safety Software Technical Specification

2. M.Hecht;R.Brill Review Guideline for Software Written in High Level Programming Languages Used inSafety Systems

3. Minda Zhao Nuclear Safety-Critical Software V&V Technology

4. IEC 61511,Functional Safety-Safety Instrunented Systems for the Process Industry Sector

5. IEC 61508,Functional Safety of Electrical/Electronic/Programming Electronic Safety-Related systemsPart O-Part 7

本文链接：http://d.g.wanfangdata.com.cn/Periodical_zdhbl201012009.aspx

专家分析

彭瑜，男，中国自动化学会理事。中国自动化学会仪表和装置专业委员会常务委员。中国自动化学会专家咨询委员会委员，上海市自动化学会常务理事，中国仪器仪表学会专家委员会委员，ＰＬＣｏｐｃｎ国际组织中国委员会主席。长期从事现场设备的无线通信等方面的研究。

从实现过程功能安全要求的基本规范ＩＥＣ６１５１１所给出过程工业中工厂安全保护防灾结构体系（见图１），可以清晰地看出安全仪表控制系统ＳＩＳ是过程工业预防灾害和减灾的两个重要环节，确

保安全仪表系统的功能安全则是预防和减灾的一种基础保证。本

文希望从功能安全的基本概念出发讨论怎么才能切实实现控制系

统的概念安全。

圈１工厂安全保护防灾结构体系

４０－Ａ自Ｕｉ慧剿。罂慧腮

万方数据

上海工业自动化仪表研究院彭瑜

ｌ

控制系统功能安全的国际标准

ＩＥＣ６１５０８／ＧＢ２０４３８《电子／电气厂可编程电子安全相关系统的

功能安全》是一个宏标准，规范了满足安全相关系统功能安全的基本要求和规则。通过应用严格的系统性的过程，以可追溯性，关键性分析、验证（ｖｅｒｉｆｉｃａｔｉｏｎ）和确认（ｖａｌｉｄａｔｉｏｎ）的程序为重点，来评估是否满足功能安全的标准要求。ＩＥＣ６１５０８标准的一个重要突破就是制订了一整套完整的开发程序和一系列的技术措施，通过严格的质量管理与全生命周期的程序控制。达到实现避免故障、排除故障及一定程度上容许故障的目的。

１ＥＣ

６１５０８共有８个部分，即：

・

ＩＥＣ

６１５０８－０：功能安全和ＩＥＣ

６１５０８Ｉ

・

ＩＥＣ６１５０８一ｌ：一般要求Ｉ・

ＩＥＣ

６１５０８－２：电气／电子，可编程电子安全相关系统的要

求Ｉ

・

ＩＥＣ６１５０８－３：软件要求；・

ＩＥＣ６１５０８－４：定义和缩略语Ｉ・

ＩＥＣ

６１５０８－５：确定安全完整性等级的方法示例ｌ

・

ＩＥＣ６１５０８－６：ＩＥＣ

６１５０８—２和ＩＥＣ６１５０８・３的应用指南Ｉ

・

ＩＥＣ６１５０８－７：技术和措施概述。

在不同应用领域更细化和具体实现功能安全，又开发了进一步的规范，如：

・

实现机械功能安全要求的基本规范ＩＥＣ

６２０６１。

・

实现过程功能安全要求的基本规范ＩＥＣ６１５１１。・

实现核电功能安全要求的基本规范ＩＥＣ

６１５１３Ｉ

・

实现医疗设备的功能安全要求的基本规范ＩＥＣ６０６０１ｌ

・

实现铁道运输安全的规范ＥＮ

５０１２８，

２

控制系统功能安全的基本概念

安全系统的关键性分多个层次：

・

安全关键（ｓａｆｃｔｙ－ｃｒｉｔｉｃａｌ）系统：单个缺陷或失效会造成危

险的故障，如核电站原子反应堆的停堆系统。

・

安全相关（ｓａｆｅｔｙ－ｒｅｌｅｖａｎｔ）系统：单个缺陷或失效与第二

个缺陷或失效会造成危险的故障，如石化行业的安全仪表系统。

・

非安全相关（ｉｎｔｅｒｆｅｒｅｎｃｅ・ｆｒｅｅ）系统：即使多个缺陷或失

效也不致造成危险的故障。

对安全要求最高的安全关键系统，必然为实现其安全要求而最耗费时间、成本最高，认证的过程和程序最复杂。对安全的要求相对较低的安全相关系统，以及对安全要求更低的非安全相关系统，相应在时间、成本和认证所耗费的努力逐级递减。

在ＩＥＣ６１５０８的标准中，对石化和化工行业广泛应用的安全相关系统有着严格的定义和要求：

・

必须在受控装置ＥＵＣＪ临近风险或危险状态情况下，能执

行所要求的安全功能，使ＥＵＣ达到或保持安全状态，

・

依靠安全相关系统本身，或与其它Ｅ／Ｅ／ＰＥ安全相关系

统、其它技术的安全相关系统或外部风险降低设施共同作用，达到所要求的安全功能必需的安全完整性。例如图２所示的一个化工厂常见的加热搅拌系统，除了用圆圈标出的是一个安全仪表系统（ＳＩＳ）而外，安全阀就是使用机械保护的安全系统，它们配合使用达到必需的安全完整性。

这将安全相关系统在工厂预防和减灾中的作用明确规定如下：首先，由安全相关系统与外部风险降低设施共同作用，使受控设备达到必要的风险降低量，以满足所要求的允许风险。其次，安全相关系统是在接受命令时，采取适当的顺序动作防止ＥＵＣ进入危险状态。一旦安全相关系统失效，也属于导致危险或危害的事件。第三，即使还有其他的具备安全功能的系统，但所指定的安全相关系统仅靠其本身的能力（而非其他系统）就能达到所要求的允许风险。第四，安全相关系统一般分为安全控制系统和安全防护系统，并且具有两种操作模式。

从安全相关系统的构成来看，它可以是ＥＵＣ控制系统的一个组成部分，也可用传感器和／或执行器与ＥＵＣ接口，即可通过实现ＥＵＣ控制系统中的安全功能（也可能通过分开的和独立的附加系统）达到要求的安全完整性等级，或者利用分离的、独立．专门的安全相关系统实现安全功能。

这就明确告诉我们，安全相关系统的功能可能包括：用于防止危险事件发生，即安全相关系统一旦执行其安全功能，则不致发生有危险事件；用来减轻危险事件的影响，即通过减轻后果降低风险。或者同时具有上述的组合功能。

人也可作为安全相关系统的一部分，例如，人可以接收来自可编程电子装置的信息，并通过该装置按接收信息要求执行安全动作。

安全相关系统包括执行安全功能所需的全部硬件、软件以及支持服务（如电源、传感器和其它输入装置、执行器和其它输出装置也包括在安全相关系统中）。

万方数据

安全相关系统的技术基础范围可以十分广泛，包括电气，电子，可编程电子、液压和气动等。

图２

ＳＩＳ和安全阀配合使用的化工加热搅拌系统的Ｐ＆ＩＤ

由于在工厂安全保护防灾的体系结构中对不同的装置，系统，甚至系统内的各个子系统或部件的安全要求常常有很大差异，因此，ＩＥＣ６１５０８标准允许对一个系统的子系统和部件进行独立的评估。所以，我们在谈论功能安全时要严格区分所指的对象是系统，还是构成系统的部件或子系统。

３

控制系统的安全完整性及其等级

安全完整性是指在规定的条件下，规定的时间内，安全相关

系统成功地实现所要求的安全功能的概率。众所周知，控制系统由构成其系统的各种硬件（控制系统装置，现场仪表、通信网络等等）以及执行控制要求和功能的软件综合而成，因此控制系统的安全完整性由硬件的安全完整性和系统的安全完整性组成。硬件安全完整性是在危险失效模式中对应于安全相关系统安全完整性的硬件随机失效的那一部分，一般可以通过所要求的硬件安全功能失效率予以量化，而系统安全完整性则是指在危险失效模式中对应于安全相关系统安全完整性的系统失效的部分（包括软件失效）。控制失效与避免失效涉及设计，操作模式等诸多环节。显然，硬件随机失效和系统失效的机制不同，控制失效的方法也不同（见图３）。

可以通过改变设计、生产过程、摄作梗式、操作指令或其他影响因子，来清除原因确定的失效，

ｌ

ｌ

鼍免失效估算由于随机硬件失效造成的每控铡失效

个安全功能的失效概率

田３控制系统失效机理

票鬻测驰篙貉４１

—五ＤＴ０１神Ａ彳ｉ石Ｎ—］亭鬲嗣。膏五丽

专冢分析

在安全相关系统中，安全完整性的要求用４个离散的等级予以划分，ＩｉｐＳｌｔＡ，ＳＩＬ３。ＳＩＬ２和ＳＩＬｌ。安全完整性的等级越高的安全相关系统，其执行所要求的安全功能的概率也越高。

根据安全相关系统的使用方式、所要求发生的频率，可分为低要求操作模式和高要求（或连续）操作模式。低要求操作模式对应于每年发生风险的次数多于等于１次的安全相关系统；高要求（或连续）操作模式对应于每年发生风险的次数少于１次的安全相关系统。表ｌ是ＩＥＣ

６１５０８ｌ／ＧＢ／Ｔ

２０４３８规定的低要

求操作模式下的安全完整性的目标失效概率和目标风险降低因子，表２是高要求（或连续）操作模式的安全完整性的目标失效概率。

ＳＩＬ３被认为是单个可编程系统中可达到的风险降低的最高等级。

寰１低要求操作模式下的安全完整性的目标失效概率和

目标风险降低因子

安全完整性等级目标平均失效概率

目标风险降低因子

（ＳＩＬ）

４

２ｌ旷一＜１０４＞１００００一≤１０００００３２１０４一＜１０

３

＞１０００一！１００００２２ｌＯ。’一＜１０。２

＞１００一！１０００

１

＞１０。’一＜１０。１

＞１０一！１００

表２高要求（或连续）操作模式的安全完整性的

目标失效概率（每小时）

安全完整性等级

目标平均失效概率平均发生１次失效的

（ＳＩＬ）

（每小时）

年数

４＞１０一一＜１０。８１１４００一１１４０００

３＞１０一一＜１０’７１１４０一１１４００２≥１０～一＜１０。６１１４—１１４０ｌ

＞１０４一＜１０。５

１１．４—１１４

４

安全系统的多样性（ｄｉｖｅｒｓｉｔｙ）原则

安全系统可以采取多样性原则克服可能发生的故障，或设计

分析中存在的不确定性。多样性是指用不同方法执行所要求同一功能。例如：可用不同的物理方法或不同的设计途径来达到多样性。

多样性分为；①信号多样性；②功能多样性，③设备多样性ｌ④软件多样性（如指令运算的多样性），⑤人员多样性等等。其中较为常用和有效的是信号多样性和功能多样性。

对所采用的多样性措施是否适当应加以论证。为了保证能切实执行多样性，对设备的多样性或仪表控制系统的软件多样性所进行的论证，必须扩展到这些设备的硬件、软件部件，如实时操作系统ＲＴＯＳ。

图４是Ｓ７．４００Ｆ运用指令运算的多样性和时间冗余来提高安全功能的可靠性。操作数Ａ．Ｂ在ＣＰＵＩ进行。与”运算，结果

４２

自勋化．博览２０１０年１２月刊

７旺『ｉｎ冒啊五Ｔ兀玎ｒ．ｊ万霸ｏＲＡＭ五一

万方数据

为Ｃｌ

Ａ，Ｂ经过编码变成字Ａ，Ｂ，在ＣＰＵ２ｑｂ傲。或”运算，

结果为Ｄ＝／Ｃ。在比较器中进行比较运算，仅当Ｄ≠／Ｃ时输出停机信号。

！！竺竺！！！竺！塑！空

－Ｔｉｍｅ

圈４运用指令运算的多样性和时间冗余来提高安全功能的可靠性再如某核电站的紧急停堆系统由两个完全独立的系统构成。其安全控制系统由不同的供应商提供。一个停堆控制系统采用安全ＰＬＣ系统，由３个独立的３机冗余表决的分系统（Ｄ、Ｅ、Ｆ）组成（见图５）。每个分系统都具备停堆功能，但其停堆输出还要

送给３取２的继电器硬逻辑进行表决，最终给出停堆信号。该安全ＰＬＣ系统硬件平台配有操作系统，运用符合工业控制编程语言的国际标准ＩＥＣ６１１３１－３所规范的功能块图语言（ＦＢＤ）编制应用软件。这套停堆控制系统采用了综合法（ＩｎｔｅｇｒａｔｅｄＡｐｐｒｏａｃｈ）设计。

值得注意的是，为了实现安全系统的机理多样性，还设置

了另一套完全不同机理的停堆系统，通过将有害的中子吸收剂（ｐｏｉｓｏｎ）注入反应堆中的慢化剂（ｍｏｄｅｒａｔｏｒ）的方法进行停堆

控制。这一停堆控制系统采用没有操作系统的工控机硬件平台，安全控制软件运用高安全的具有子集的ＭＯＤＵＬＡ－２语言编写。这一套系统使用的是另一种设计方法一合理设计流程法（ｒａｔｉｏｎａｌ

ｄｅｓｉｇｎ

ｐｒｏｃｅｓｓ），用确定离子室记录的功率信号的合理性来检查

异常差错信息。由此可见，在要求极高的安全关键系统中充分运用了多样性的原则，有：机理的多样性、设计方法的多样性、设

备的多样性，编程语言的多样性，这样就从系统的层面上把同时发生差错的概率降至尽可能的小。

田５采用３套３机冗余表决的安全ＰＬＣ系统构成的停堆控制系统

５重视处理假事件

各种安全系统（包括紧急停车系统ＥＳＤ）如果对假事件作出响应，造成非计划停车，不但要付出高昂代价，而且在大多数

ＯＴＵ３

情况下具有危险性。大量的假报警还会导致操作人员产生矛盾心理，以至于对危险的真报警都不予理会，或者反映很慢。

产生假事件的原因：①现场设备的硬件故障，如压力开关、电磁阀的线圈或常闭触点存在高电阻，ＰＬＣ的Ｉ／Ｏ模块有故障，现场设备中电子器件有故障，热电偶断偶，热电阻断线等，这些明显的设备故障都会引发假事件。②一些公用故障如电源、气源故障也会引发假事件。⑦缺乏维护，不及时对工作有缺陷的仪表、传感器进行测试、校验，是引发假事件的重要原因。

下面讨论信号多样性问题。看一个用３个浮球液位开关测量液位的简单例子（图６）。我们可以有４种配置。采用单信号、双信号还是三信号更有利于安全和可靠的平衡呢？概括地说：采用单机（单信号）系统不安全且不可靠，在故障安全（假事件）或危险方面存在５０／５０的概率ｌ采用双机（双信号）系统配置为二取一（１００２），可能较安全，但存在高的假故障率，双机（双信号）系统配置为二取二（２００２），由假事件引起的故障率较低，但安全性差；三机（三信号）冗余系统为三取二（２００３），提供可以接受的安全与可靠的平衡。

圉６用３个浮球液位开关测量液位可能的配置

显然，Ｓ１Ｓ／ＥＳＤ不能选择单机（单信号）系统。选用双机

（双信号）系统，在一定程度上可达到安全和可用性。二取一（１００２）安全性较好，但可靠性及假事件的影响大，二取二（２００２）可靠性较好，安全性却较差。即使双机（双信号）系统具有很好的自诊断性能，可以确定采用哪个通道或处理器故障，将坏的通道或处理器剔除，但这时双机系统降格为单机系统。三取二（２００３）独特的优点是不考虑哪个通道发生故障，是怎么发生故障的；也不完全依靠自诊断来确定哪个通道投用。其亮点在于它仅要求所接收到的信息。三取二表明，若有一个信号不同于另外两个信号，立即报警，而这两个信号相同的通道处于安全工作状态。

从图６所示的例子可知，如果流程要求用于液位测量的仪表每年只能发生１次故障，而且每半年对浮球开关进行一次维护测试，那么对于不同的浮球液位开关配置，因故障造成危险的年概率如表３所示。

万方数据

裹３浮球液位开关不同配置的因故障造成危险的概率

仪表信号配置

故障危险概率

假事件故障概率

故障危险概率（每半年维修１次）

ｌｏｏｌ１／１０１／１０ｌ／２０ｌ００２ｌ／１００

ｌ／５１／１６００２００２ｌ／５

ｌ门００ｌ／２０２００３

ｌ／３３

ｉ／３３

ｌ／５３４

６

软件的可靠性难以精确量化

软件可靠性的基本问题是：①软件不受物理故障的影响。随

着硬件元器件的可靠性越来越高，并可以采用冗余技术，因而安全问题的矛盾集中到了软件，以至于今天我们看到大多数的系统失效源自软件。失效常常由于一些非明显的事件组合造成，而不是由于机械应力超过一定程度造成。而这些非明显因素往往事先没有估计到，所以在软件的编制中考虑不到。②软件是由人来设计的，软件的设计不可能面面俱到，总有些因素在设计时没有考虑到，因此，设计的缺陷导致软件的故障。③数字系统本质上是非连续的，所以输入对输出的映射一定是不连续的。④软件建立在模型化和测试的基础上，这些工作都是人在做的。人难免犯错误，所以影响软件的可信度。

因为以上这些不可避免的问题，可以得出软件的可靠性难以精确量化的结论。另外，从趋势上讲，软件和人为因素导致失效，事故和停机的比例越来越高。因为现在对软件的依赖越来越高，软件变得越来越复杂，因而难以控制。人犯错误不可避免。硬件失效可能是系统失效的原因，系统的失效会引起软件的失效。有鉴于此，要保证工业控制软件的功能安全就不得不依赖于对软件进行严格的验证和确认。

７

工业控制软件的功能安全概念和方法

ＩＥＣ

６１５０８—１规定了整体安全生命周期的１６个阶段，包括：概

念，整体范围定义，危险和风险分析，整体安全要求，安全要求分

配，整体操作和维护计划编制，整体安全确认计划编制，整体安装和试运行计划编制，Ｅ／Ｅ／ＰＥ安全相关系统：实现，其他技术安全相关系统：实现，外部风险降低设施：实现，整体安装和试运行，整体安全确认，整体操作维护和修理，整体修改和改型，停用及处理。与软件相关的是第９阶段“Ｆ．／Ｅ／ＰＥ安全相关系统：实现”在ＩＥＣ６１５０８—３中详细地规定了执行安全功能的软件如何满足面：软件质量管理系统，软件安全生命周期要求，软件功能安全么要求，以及如何来验证工控软件达到了功能安全的标准。ＩＥＣ６１５０８—３的突出贡献在于制订了一整套完整的开发程序和一系列避免故障、检测故障和排除故障，以及容许存在故障，从而保证嚣燃一鱼咝４—Ａ

ＭＡｆｒ石Ｎ一——

ＰＡＮＯＲＡＭＡ

技术措施，通过严格的质量管理与全生命周期的控制程序，实现评估。它给出的是在软件的安全生命周期的各个阶段应该满足什功能安全的要求。它规范的工控软件的功能安全问题包括以下方

专家分析

软件的安全完整性能。总之，ＩＥＣ６１５０８—３给出了在安全相关系统的软件编制时应遵循哪些规范就能够达到功能安全的要求。这好比它编织了安全软件开发的。鸟笼”，以及在“鸟笼”里飞必须遵守的规则和约束；一旦飞出。鸟笼”就不能保证软件的安全。但它并没有具体规定工控软件在选用编制系统软件和编制应用软件时，应该如何选择适当的编程语言、指令集和数据类型，就可以从基础上保证软件的功能安全性。这些问题有些可以通过ＩＥＣ６１５０８・６（ＩＥＣ６１５０８—２和ＩＥＣ６１５０８．３的应用指南）和ＩＥＣ

６１５０８

－７（技术和措施概述）找到相应的具有实用性的参考规定和资料，有些就必须再进一步查找其它围绕不同应用领域的工业控制软件的功能安全的规范，如美国核管制委员会ＮＲＣ发布的《（核电站软件语言导则》．ＰＬＣｏｐｅｎ国际组织发布的在ＩＥＣ６１

１３１・３的

开发环境下有关机械功能安全的规范《ＳａｌｔｙＳｏｆｔｗａｒｅＴｅｃｈｎｉｃａｌ

Ｓｐｅｃｉｆｉｃａｔｉｏｎ））等等。

众所周知，安全相关系统包括硬件、软件，软件必须运行于硬件系统环境中才能实现其价值和功能，在完成系统的功能安全时，一定要认识这二者之间的关系。通过图７所揭示的ＩＥＣ６１５０８－３与ＩＥＣ６１５０８—２的关系就能一目了然：ＩＥＣ６１５０８－２是总体，ＩＥＣ６１５０８—３只是局部。尽管它们可能是由不同的团队独立开发，但最终还是要集成起来经过总体检验，才能够判断是否满足安全要求。

图７在实现系统功能安全时ＩＥＣ６１５０８－３与ＩＥＣ６１５０８．２的关系

软件的安全完整性等级采用表１低要求操作模式下的安全完整性的目标失效概率划分。达到ＳＩＬ４等级的软件相当于每１．１４年至１１．４年之间发生１次失效。

８安全系统的软件构成

与控制系统的软件构成一样，安全系统的软件也包括系统软件和应用软件两部分（见图８）。它们分别用全可变语言（ｆｕｌｌ

ｖａｒｉａｂｉｌｉｔｙ

ｌａｎｇｕａｇｅ，ＦＶＬ）和有限可变语言（１ｉｍｉｔｅｄｖａｒｉａｂｉｌｉｔｙ

ｌａｎｇｕａｇｅ，ＬＶＬ）编写（见图７）．这些概念都是将软件引入功能安全时建立起来的。

什么是全可变语言呢？其实此类语言就是计算机编程人员广泛使用的语言，它提供实现各种功能和应用的能力。典型的利

４４慧然乒雩２黧三熙

万方数据

用全可变语言的系统就是通用计算机。在过程工业中，只有在嵌入式软件（一般指固件或系统软件）中才使用全可变语言，极少在应用程序中使用。ＡＤＡ、Ｃ、Ｃ＋＋、指令表ＩＬ、Ｐａｓｃａｌ、Ｊａｖａ、ＳＱＬ均属于全可变语言。

有限可变语言在ＩＥＣ

６１

５０８—４中定义为：在工业和商业可编

程电子控制器中使用且范围局限于应用程序的文本的或图形的软件编程语言。例如：引自ＩＥＣ６１１３Ｉ－３和其它标准或规范的有限可变语言，用来编写ＰＬＣ系统的应用程序。它们分别是梯形图语言ＬＤ・布尔代数语言：带有增加某些记忆指令能力的，基于布尔运算符（女Ｉ］ＡＮＤ、ＯＲ和ＮＯＴ）的低级语言Ｉ功能块图语言ＦＢＤ：除布尔运算符外，可使用更复杂的功能，如数据传输文件、块传输读／写，移位寄存器和序列发生器指令等；顺序功能图语言ＳＦＣ：有顺序之程序的图形表示，由相互联系的步骤、动作和带转换条件的定向连接线构成。

图８功能安全用编程语言的构成

９

软件功能安全对编程语言的要求

编程语言并不是专为安全系统开发的，它们在出现安全软件

的概念之前就发展了很长的时间。所以要用ＦＶＬ和ＬＶＬ完成安全系统的软件编写，首先必须对这些语言和用它们编写的程序提出要求和进行评估，以确定在什么条件下使用这些语言就能确保安全软件完成其保证功能安全的任务。

从另一方面来看，由于嵌入式系统已渗透到各行各业，这些年来，凡是对安全有重要要求的行业都很关注这个问题，制

定了各自的规范。例如汽车行业建立了汽车工业软件可靠性协会ＭＩＳＲＡ，发布了专门用在汽车行业的ｃ＋＋语言的子集ＭＩＳＲＡＣ＋＋。美国核管制委员会ＮＲＣ早在１９９６年就发布了《核电站软件语言导则》，之后９７年又公布了其修正版ＮＵＲＥＧ／ＣＲ

６４６３

Ｒｅｖ．１。因为其权威性，直至现在它已成为安全软件的经典规范。

不仅仅是核电，其它行业的软件安全问题也经常以此作为引经据典的文献。

在美国的核管制委员会发布了《核电站软件语言导则》

ＮＵＲＥＧ／ＣＲ６４６３Ｒｅｖ．１中，对用高级语言编写的用于安全系统的

软件进行了安全评述，着重指出以往发现的软件安全性问题和缺陷，从对应用重要性的理解、设计的方法论、学科发展和测试等方面加以阐述。

ＮＵＲＥＧ／ＣＲ

６４６３

Ｒｅｖ．１将软件安全的属性按三级架构加以分

类和编排：顶级属性．中间属性和基本属性，如图９所示。豳９软件安全的三级架构属性

软件的可靠性属性是在所规定的条件下软件的可预测、且恒定一致的性能。由于软件的可靠性属性旨在减少在软件开发实现期间可能被导入源代码而造成误操作的故障，所以此顶级属性对安全来说是很重要的。

软件的鲁棒性是在异常条件或事件下，安全系统的软件以一种可接受的方式进行操作的能力。由于它加强了软件处理例外情况、从内部故障中恢复，以及阻止因异常环境而致使故障传播的能力，因此此顶级属性也很重要。

软件的可追溯性表现为：①对源代码和所引用的程序库部件的源头进行检查和识别－⑦通过对开发过程的可行性进行检查，来验证已执行的代码在其开发过程中是否按规范的方法完成其实现；⑦审视代码与高一级的设计文档相关联的能力。此属性之所以重要是因为这将便于对软件进行验证和认证（Ｖ＆Ｖ），这是软件质量保证的另一方面。

软件的可维护性是在软件交付使用后若需对源代码做改动时，导致将故障引入的可能性减少的必要手段。此属性之所以对安全来说很重要，是因为在对软件进是因为在对软件进行适应、校正或完善期间可以尽量减少可能发生的误操作的故障。

根据ＩＥＥＥ所给出的规定，软件可靠性是在软件编制，调试和执行运行全过程的环境下，既可以是在所定义的时间间隔内和所定义的条件下成功执行的几率，也可以是按照命令成功操作的几率。软件执行完成是其对于系统存贮器和程序逻辑恰当行为的结果。这

墨嚣三’哥娃：：曩

Ｉ

ｌ

ｌ

ｌ

【存贮空问藕用的可预舅性ｌ

控制流的可预舅性ｌ。时序的可琢舅性．］

Ｉ－动态存贮分配的・４、化

一结构最大化

卜

Ｌ内存分页和存贮空同对

二嚣蔫荔耄蓑雌批Ｌ尽可蠢少用任务

挠的最小化

一子程序的进入点和出口锅妙一用务

一不用赋值语句一界面歧义最小化一采用敦据健入

一准确度．精度进行记曩一捧定优先级

一蕾免执行于程序产生的

状态变化一将求值与赋值焉开一动奄绑定量小化

图ｌＯ可靠性的中间属性

万方数据

意味着软件所产生的适时输出是编程人员对所使用的语言结构和运行期间环境特性理解的函数。因此可靠性的中间属性包括：存贮空间利用可预测性（软件不致造成处理器会向非预期的或不允许存贮空间进行存取的高概率）；控制流可预测性（处理器按编程员预期的顺序执行指令的高概率）ｔ时序可预测性（软件在所定义的运行环境下满足响应时间和处理能力约束的高概率）・数学结果或逻辑结果可预测性（软件在所定义的运行环境下产生编程员所预期结果的高概率）。详见图ｌＯ。

所谓软件鲁棒性是指在异常或其他未曾预计的情况下软件继

全系统而言鲁棒性之所以重要是因为在一个意外或偏离额定工况时会发生未曾预料的事件，在这样的情况下软件持续的对系统监控和控制的能力仍能有效作用。软件鲁棒性的中间属性和基础属性见图１ｌ。

图１１软件鲁棒性的中间属性和基础属性

软件的可追溯性是指与软件设计相比较，安全软件的那些支持其正确性和完整性验证的属性。可追溯性的基础属性有：可读的可控使用。

软件的可维护性是为了有效减少在对软件进行修改时可能引入的差错。会影响安全的与可维护性有关的中间属性（见图１２）包括：可读性一便于项目人员对软件的理解的软件属性；数据的改软件时意想不到的副作用和次生的影响减至最小；函数的内聚可移植性一避免一种语言的非标准函数对安全的重大威胁；可塑田１２可维护性有关的中间属性

名慧蒜熊燃４Ｓ

—百ＩＪ亍。葡哺ｉ耵石葡——乒Ａ对。再五ｌ－晤

续执行的能力。鲁棒性的同义词是耐久性（ｓｕｒｖｉｖａｂｉｌｉｔｙ）。对安性（这也是可维护性的属性），内嵌函数的可控的使用，编译库抽象一对于那些代码被划分和模块化的区域，这样做可以使在修性一对代码中的软件元素给予设计水平的函数适当的存贮地址，性一将可能修改的代码区与软件代码的其余部分隔离开。

专冢分析

ｌ

０编程语言实现软件功能安全的方法

在ＮＲＣ的ＮＵＲＥＧ／ＣＲ

６４６３Ｒｅｖ．１完整版本中给出了将９种编

程语言（Ａｄａ，Ａｄａ９５，∞＋＋，Ｐａｓｃａｌ，ＰＬ／Ｍ，ＩＥＣ６１１３１・３规定

的梯形图、顺序功能图，结构化文本和功能块图）用于安全系统时，应该关注它们特定的存在问题和如何加以克服注意点。譬如，对于Ｃ语言来说，是其指针的初始化问题ｌ对于ＩＥＣ

６１１３１－３

所规范的编程语言，则应关注其时序、正常运行的监控，以及故障处理等问题。

从顶级属性中的可靠性、中级属性中的可预测性的控制流和基础属性中的在使用前变量的初始化这三方面导出对指针初始化的指导原则。所有的变量和指针在使用前都应该初始化。Ｃ语言支持通过说明来指定初始值的方式进行初始化，但并不要求所有的对象（指变量、数据结构或数组）进行初始化。在若干情况下，一个对象的初始化不仅要为对象的存贮地址指定一个特定的位的组合值，而且还要采取特殊的动作来为对象的生命（例如为对象赋予对应的源）进行平滑初始化。在ｃ＋＋中，可能要考虑任意相关数据作为对象，并提供构造数据组一个实例的工具。这样便会以系统的方式破坏数据组当前的实例。

考虑到上述情况，必须对初始化提出以下导则：①不要对超出其说明范围的变量自动使用指针。存贮在指针的值对一个自动变量会包含超出其函数范围的无用输入。②指针的初始化，初始化问题也会在指针中发生。在安全系统中所有ｃ语言中的指针变量，其初值都应该为ｎｕｌｌ；所有Ｃ＋＋中的指针变量，其初值都应该为０。在被使用之前，指针应对一个有效值予以测试。当一个指针被定义时，它没有一个地址与其相关联。使用一个未初始化的指针，会造成重写未曾预想到的指针的存贮地址。错误地重写存贮内容会引起严重的问题，包括对系统的崩溃。⑦要确保每一个指针的说明间接的运算符都是存在的。每个指针都应该有一个间接运算符（。）。

ＩＥＣ

６１１３１．３所定义的５种语言除指令表语言（ＩＬ）与汇编语

言相似外，其它语言都纳入了ＮＲＣ关于编程语言的导则中。对这些语言特定的指导原则源于鲁棒性顶级属性和异常处理的中间属性。应该专注于在机组紧急停车时ＰＬＣ的行为。通常此时所有的输出均应切断，但往往并非总是如此。一般ＰＬＣ系统总是设计成在紧急停车时系统处于故障安全状态。某些ＰＬＣ在遇到这样的情况时具有处理器能自动停止主梯形图程序的执行，转而执行。故障程序”的子程序。这使系统的设计者可以决定采取适当的动作，包括以一种安全的方式让系统停下来。问题在于：ＩＥＣ６１１３１—３规范中未涉及到允许ＰＬＣ系统本身包含有某种预先设计好的硬件故障程序，当检测到一定范围的故障条件时便会自动执行。不过，ＩＥＣ６１１３１．３允许建立非周期的任务，通过触发适当的内部诊断信息来执行处理特定类型的出错（ＦＯ故障时降级运行模

４６躲篇阮孑叩燃

万方数据

式、向操作员见面报警等）。

对于ＰＬＣ系统，在编程的设计阶段就应在程序结构中考虑故障程序问题。这时必须遵从如下原则：①完整住故障程序不能依赖于检测到程序崩溃的所有特例，因此遇到ＰＬＣ的主要故障时要有针对附加措施的安全保证。②可观察性故障程序要有状态记录和报警的能力。故障程序应显性执行，不被掩盖。⑦真实性检查在启动故障程序的情况下有可能将可以反映原来条件的程序存贮内容、数据文件或Ｉ／Ｏ状态破坏，因此故障程序应保证在执行故障处理前将这些环境加以保存，以便事后分析。④在故障程序不起作用时的故肇安全特性万一ＰＬＣ系统的故障处理程序不起作用，系统设计仍要保证安全状态的后备措施。

ＰＬＣ系统一般以指定的位和字的形式提供对应用程序的正常运行状况的监控，这些信息包括特定任务的执行时间，Ｉ／Ｏ刷新信息．Ｉ／Ｏ操作状态信息，电池状态信息和其它用来确定ＰＬＣ正常运行状态的信息。遗憾的是ＩＥＣ６１１３１・３规范中对这些信息的典型值、范围和类型并未做出规定。而安全系统恰恰应该具备这些信息，作为判断其是否运行正常的检查和是否需要异常处理的不可或缺的部分。

在ＩＥＣ

６１

１３１－３的规范关于。任务。这节中，阐述了制造厂

应向用户提供所有任务执行的信息的最低要求。关键在于由于这一问题的分类落在出错检查，而未能在规范中描述，于是我们也得不到这些任务执行时在运行时应以何种形式接受检查的规定。另外，许多ＰＬＣ和类似的符合ＩＥＣ６１１３１－３的系统一般只给出每次执行所有任务的周期（即所谓的扫描周期），却忽略了单个任务执行周期信息和标志的提供。如果因为安全原因需要在执行某个任务超时Ｎ次时必须紧急停车，在ＰＬＣ现有的能力下是无能为力的。为了解决这个问题，必须让应用程序能够对单个任务执行其超时的检测，并给出单任务超时的标志，这样才能做出适当的反应。对于安全关键系统，监控任务超时的问飚尤其要紧。必须在程序开发的检查阶段关注。

１

ｌ在安全系统中推荐采用的编程语言

在ＩＥＣ６１５０８－７的附录Ｃ．４．５中给出了适合用于安全系统的软

件编制推荐的语言（见表４），表中列举了２４种编程语言，其中适用于安全系统的软件编制的语言共９种，它们是：属于全可变语言ＦＶＬ确泌种（具有子集的ＡＤＡ，具有子集的ＭＯＤＵＬＡ一２，具有子集的Ｐａｓｃａｌ，具有子集的ＦＯＲＴＲＡＮ７７，具有子集和编程标准并使用静态分析工具的Ｃ），属于有限可变语言ＬＶＬ有４种（具有定义的语言子集的梯形图，具有定义的语言子集的功能块图，具有定义的语言子集的结构化文本，具有定义的语言子集的顺序功能图）。

＞）．＞、＇＞＞＞＞＞≯哆下转５０页

柔例推歹ｒ

场调试中最初软件工程师设置的采样时间全为１ｓ，死区为０，这样文件很大。环保检查时要求调出一个月的相关历史数据，在历史站调出１个月的趋势图的时间很长，甚至长达几个小时，让核查人员无法忍受。经过优化以后，采用本文前面的办法，历史数据文件容量减小为原来的ｌ％以下，调出同样时间段的数据的时间减少到ｌ￣２分钟，这个时间应能接受。

在调试现场要检验参数设置优化后的效果，是否只有等待１个月的时间，等一个月的历史数据形成后才能验证调出时间？答案是否定的，采用好的办法，可以在半个小时内检验调出１个月历史趋势记录的时间：

（１）ｉＦｉｘ的历史记录参数优化后，重新启动软件，２４小时后得到ＩＸ的数据文件ｌ

（２）拷贝并复制３０个这样的文件；

（３）逐个修改文件名，即修改文件的生成时间。

这样快速地得到了１个月历史记录数据，数据是重复的，每天相同。用于来测试参数优化后历史数据的调出时间是合适和可行的，可以调出重复的３０天或更多天的数据。我们在做文件复制前，应将已经生成的历史数据做好备份，以便事后恢复。这个方法只能用于试验，生产运行中不能对历史数据做修改和拷贝，如果有操作也将被记录。对脱硫装置这样的环保设施，如果数据作假，查实后将会受到环保部门的严厉惩罚。

６结束语

ＧＥ

ｉＦＩＸ作为优秀的ＳＣＡＤＡ软件，适合于多数的工业自动

化生产过程控制。对项目中具体参数的历史记录应按工艺过程的条件和要求，设置采取合理的参数，实现历史记录数据的有效和优化。如果企业对历史数据记录的要求更高，如毫秒级采样，数据量大（全厂级，几万点），则应采用Ｐｒｏｆｉｃｙ

Ｈｉｓｔｏｒｉａｎ

（ｉＨｉｓｔｏｒｉａｎ作为企业级实时历史数据库平台，可以极高的速度采集，归档并发布海量实时的现场过程信息【５１）或其它的专用数

据库软件。够

参考文献：

【ｌ】基于ＡＤＯ技术的ｉＦｉｘ历史报表的设计与实现【Ｊ】．自动化信息，２０１０．８．【２】ｉＦＩＸ监控软件在烟草制丝线的集成应用（二）【ＥＢ／ｏＬ】．ｈａｐ：／／ｗｗｗ．ｚｇｚｎｈ．

ｃｏｍ／ａｒｔｉｃｌｅ—ｓｈｏｗ．ａｓｐ？ａｒｔｉｃｌｅｉｄ＝５８０８１０。２０１０—０６—０９．

【３】ＰｒｏｆｉｃｙＨＭＩＳＣＡＤＡ．ｉＦｉｘ４．０电子书．

【４】曲晓俊，马彩．ｉＦＩＸ组态软件中通用趋势曲线的没计与实现【Ｊ】．工业控制计算机，２００９（２２）３．

【５】ｉＨｉｓｔｏｒｉａｎ在电厂厂级实时监视系统中的解决方案［ＥＢ／ＯＬ］．ｈａｐ：／／ｓｂ９１．

ｉｄｚｊ．ｃｏ．Ａｒｔｉｃｌｅ／２００８０９／２００８０９２４１７２９４０—１２５１４．ｈｔｍｌ，２００８・０９－２４．

５ｏ

ｉＵＴ瓣ＴＩ围盯一Ｐ－－ＡＮＯＲＡＭＡ－

自勋ｆⅥ辱笕２０１０年１２，ＥＪ刊万方数据

＜．“＜＜＜＜（＜＜＜＜上接４６页

表４ＩＥＣ

６１５０８．７推荐的适用于安全系统的软件编制的语言

编程语言

ＳＩＬｌＳＩＬ２ＳＩＬ３ＳＩＬ４ＡＤＡ

ＨＲ

ＨＲ

Ｒ

Ｒ具有子集的ＡＤＡ

ＨＲＨＲＨＲＨＲＭＯＤＵＬＡ．２

ＨＲ

ＨＲ

ＲＲ具有子集的ＭＯＤＵＬＡ－２

ＨＲＨＲ

ＨＲＨＲＰａｓｃａｌ

ＨＲ

ＨＲ

ＲＲ具有子集的ＰａｓｃａｌＨＲＨＲ

ＨＲＨＲＦＯＩ汀ＲＡＮ７７

ＲＲＲＲ

具有子集的ＦＯＲＴＲＡＮ７７ＨＲＨＲ

ＨＲＨＲ

Ｃ语言

ＲＮＲ

ＮＲ具有子集和编程标准并使用静态分析工

ＨＲ

ＨＲＨＲ

ＨＲ

具的Ｃ语言

ＰＬ／Ｍ

Ｒ

ＮＲＮＲ具有子集和编程标准的ＰＬ／Ｍ

ＨＲＲ

Ｒ

Ｒ

汇编语言

ＲＲ具有子集和编码标准的汇编语言

ＲＲ

Ｒ

Ｒ梯形图语言

ＲＲ

ＲＲ具有专门定义的语言子集的梯形图语言ＨＲＨＲ

ＨＲＨＲ功能块图语言

Ｒ

Ｒ

ＲＲ具有专门定义的语言子集的功能块图语

ＨＲＨＲ

ＨＲ

ＨＲ

言

结构化文本语言

ＲＲＲＲ具有专门定义的语言子集的结构化文本

ＨＲ

ＨＲ

ＨＲ

ＨＲ

语言顺序功能图

ＲＲＲＲ

具有专门定义的语言子集的顺序功能图ＨＲ

ＨＲ

ＨＲ

ＨＲ

语言指令表语言

ＲＮＲＮＲ具有专门定义的语言子集的指令表语言

ＨＲ

Ｒ

Ｒ

Ｒ

表４中Ｒ为推荐，ＨＲ为强烈推荐。

ＰＬＣｏｐｅｎ国际组织与专业从事安全认证的权威机构ＴＯＶ一起定义了在ＩＥＣ６１１３１－３的环境下涉及机械安全的规范《Ｓａｆｅｔｙ

ＳｏｆｔｗａｒｅＴｅｃｈｎｉｃａｌ

Ｓｐｅｃｉｆｉｃａｔｉｏｎ））。其中仅规定了两种具有定义子

集的语言（功能块图语言ＦＢＤ和梯形图语言ＬＤ）可用于机械安全

系统。囝

●考文献：【ｌ】ＩＥＣ６１５０８Ｆｕｎｃｔｉｏｎａｌ

ＳａｆｅｔｙｏｆＥｌｅｃｔｒｉｃａｌ／Ｅｌｅｃｔｒｏｎｉｃ／Ｐｒｏｇｒａｍｍｉｎｇ

ＥｌｅｃｔｒｏｎｉｃＳａｆｅｔｙ．ＲｅｌａｔｅｄｓｙｓｔｅｍｓＰａｒｔ

０－Ｐａｒｔ７．

［２１

ＩＥＣ６１５ｌｌ

Ｆｕｎｃｔｉｏｎａｌ

Ｓａｆｅｔｙ—Ｓａｆｅｔｙｌａｓｍａｎｅｎｔ捌ｌＳｙｓｔｅｍｓｆｏｒｔｈｅ

ＰｒｏｃｅｓｓＩｎｄｕｓｔｒｙＳｅｘｔｏｒ．

【３】ＭｉｎｄａＺｈａｏ（ＡＥＣＬ，加拿大原子能公司）．ＮｕｃｌｅａｒＳａｆｅｔｙ－Ｃｒｉｔｉｃａｌ

ＳｏｆｔｗａｒｅＶ＆ＶＴｅｃｈｎｏｌｏｇｙ．

【４】Ｍ．Ｈｅｅｈｔ，Ｒ．Ｂｒｉｌｌ．ＲｅｖｉｅｗＧｕｉｄｅｌｉｎｅ

ｆｏｒ

Ｓｏｆｔｗａｒｅ

Ｗｒｉｔｔｅｎ

ｉｎＨｉｇｈＩ．ｅｖｅＩ

Ｐｒｏｇｒａｍｍｉｎｇ

ＬａｎｇｕａｇｅｓＵｓｅｄｉｎＳａｆｅｔｙＳｙｓｔｅｍｓ．

【５】ＰＬＣｏｐｅｎ．ＳａｆｅｔｙＳｏｆｔｗａｒｅ

Ｔｅｃｈｎｉｃａｌ

Ｓｐｅｃｉｆｉｃａｔｉｏｎ．

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

作者：作者单位：刊名：英文刊名：年，卷(期)：

彭瑜

上海工业自动化仪表研究院自动化博览

AUTOMATION PANORAMA2010,27(12)

参考文献(5条)

1. PLCopen Safety Software Technical Specification

2. M.Hecht;R.Brill Review Guideline for Software Written in High Level Programming Languages Used inSafety Systems

3. Minda Zhao Nuclear Safety-Critical Software V&V Technology

4. IEC 61511,Functional Safety-Safety Instrunented Systems for the Process Industry Sector

5. IEC 61508,Functional Safety of Electrical/Electronic/Programming Electronic Safety-Related systemsPart O-Part 7

本文链接：http://d.g.wanfangdata.com.cn/Periodical_zdhbl201012009.aspx