摘要：
从实现过程功能安全要求的基本规范IEC61511所给出过程工业中工厂安全保护防灾结构体系（见图l），可以清晰地看出安全仪表控制系统SIS是过程工业预防灾害和减灾的两个重要环节，确保安全仪表系统的功能安全则是预防和减灾的一种基础保证。本文希望从功能安全的基本概念出发讨论怎么才能切实实现控制系统的概念安全。
一、控制系统功能安全的标准
IEC61508/GB20438《电子/电气/可编程电子安全相关系统的功能安全》是一个宏标准，规范了满足安全相关系统功能安全的基本要求和规则。通过应用严格的系统性的过程，以可追溯性、关键性分析、验证（verifiCation）和确认（validation）的程序为重点，来评估是否满足功能安全的标准要求。IEC61508标准的一个重要突破就是制订了一整套完整的开发程序和一系列的技术措施，通过严格的质量管理与全生命周期的程序控制，达到实现避免故障、排除故障及一定程度上容许故障的目的。
·IEC61508共有8个部分，即:
·IEC61508-O:功能安全和IEC61508;
·IEC61508-l:一般要求；
·IEC61508-2:电气/电子/可编程电子安全相关系统的要求；
·IEC61508-3:软件要求；
·IEC61508-4:定义和缩略语；
·IEC61508-5:确定安全完整性等级的方法示例；
·IEC61508-6:IEC61508-2和IEC61508-3的应用指南；
·IEC61508-7:技术和措施概述。
在不同应用领域更细化和具体实现功能安全，又开发了进一步的规范，如:
·实现机械功能安全要求的基本规范IEC62061;
·实现过程功能安全要求的基本规范IEC61511;
·实现核电功能安全要求的基本规范IEC61513;
·实现医疗设备的功能安全要求的基本规范IEC60601;
·实现铁道运输安全的规范EN50128;
二、控制系统功能安全的基本概念
安全系统的关键性分多个层次:
·安全关键（Safety-eritiCal）系统:单个缺陷或失效会造成危险的故障，如核电站原子反应堆的停堆系统。
·安全相关（Safety-relevant）系统:单个缺陷或失效与第二个缺陷或失效会造成危险的故障，如石化行业的安全仪表系统。
·非安全相关（interferenCe-free）系统:即使多个缺陷或失效也不致造成危险的故障。
对安全要求zui高的安全关键系统，必然为实现其安全要求而zui耗费时间、成本zui高，认证的过程和程序zui复杂。对安全的要求相对较低的安全相关系统，以及对安全要求更低的非安全相关系统，相应在时间、成本和认证所耗费的努力逐级递减。
在IEC61508的标准中，对石化和化工行业广泛应用的安全相关系统有着严格的定义和要求:
·必须在受控装置EUCI高近风险或危险状态情况下，能执行所要求的安全功能，使EUC达到或保持安全状态；
·依靠安全相关系统本身，或与其它E/E/PE安全相关系统、其它技术的安全相关系统或外部风险降低设施共同作用，达到所要求的安全功能必需的安全完整性。例如图2所示的一个化工厂常见的加热搅拌系统，除了用圆圈标出的是一个安全仪表系统（SIS）而外，安全阀就是使用机械保护的安全系统，它们配合使用达到必需的安全完整性。
这将安全相关系统在工厂预防和减灾中的作用明确规定如下:首先，由安全相关系统与外部风险降低设施共同作用，使受控设备达到必要的风险降低量，以满足所要求的允许风险。其次，安全相关系统是在接受命令时，采取适当的顺序动作防止EUC进入危险状态。一旦安全相关系统失效，也属于导致危险或危害的事件。第三，即使还有其他的具备安全功能的系统，但所的安全相关系统仅靠其本身的能力（而非其西系统）就能达到所要求的允许风险。第四，安全相关系统一般分为安全控制系统和安全防护系统，并且具有两种操作模式。
从安全相关系统的构成来看，它可以是EUC控制系统的一个组成部分，也可用
传感器和/或执行器与EUC接口，即可通过实现EUC控制系统中的安全功能（也可能通过分开的和独立的附加系统）达到要求的安全完整性等级，或者利用分离的、独立、专门的安全相关系统实现安全功能。
这就明确告诉我们，安全相关系统的功能可能包括:用于防止危险事件发生，即安全相关系统一旦执行其安全功能，则不致发生有危险事件；用来减轻危险事件的影响，即通过减轻后果降低风险。或者同时具有上述的组合功能。人也可作为安全相关系统的一部分，例如，人可以接收来自可编程电子装置的信息，并通过该装置按接收信息要求执行安全动作。
安全相关系统包括执行安全功能所需的全部硬件、软件以及支持服务（如电源、传感器和其它输入装置、执行器和其它输出装置也包括在安全相关系统中）。
安全相关系统的技术基础范围可以十分广泛，包括电气、电子、可编程电子、液压和气动等。
由于在工厂安全保护防灾的体系结构中对不同的装置、系统，甚至系统内的各个子系统或部件的安全要求常常有很大差异，因此，IEC61508标准允许对一个系统的子系统和部件进行独立的评估。所以，我们在谈论功能安全时要严格区分所指的对象是系统，还是构成系统的部件或子系统。
三、控制系统的安全完整性及其等级
安全完整性是指在规定的条件下、规定的时间内，安全相关系统成功地实现所要求的安全功能的概率。*，控制系统由构成其系统的各种硬件（控制系统装置、现场仪表、通信网络等等）以及执行控制要求和功能的软件综合而成，因此控制系统的安全完整性由硬件的安全完整性和系统的安全完整性组成。硬件安全完整性是在危险失效模式中对应于安全相关系统安全完整性的硬件随机失效的那一部分，一般可以通过所要求的硬件安全功能失效率予以量化；而系统安全完整性则是指在危险失效模式中对应于安全相关系统安全完整性的系统失效的部分（包括软件失效）。控制失效与避免失效涉及设计、操作模式等诸多环节。显然，硬件随机失效和系统失效的机制不同，控制失效的方法也不同（见图3）。
在安全相关系统中，安全完整性的要求用4个离散的等级予以划分，即SIL4,SIL3,SILZ和SILI。安全完整性的等级越高的安全相关系统，其执行所要求的安全功能的概率也越高。根据安全相关系统的使用方式、所要求发生的频率，可分为低要求操作模式和高要求（或连续）操作模式。低要求操作模式对应于每年发生风险的次数多于等于1次的安全相关系统；高要求（或连续）操作模式对应于每年发生风险的次数少于1次的安全相关系统。表l是IEC615081/GB/T20438规定的低要求操作模式下的安全完整性的目标失效概率和目标风险降低因子，表2是高要求（或连续）操作模式的安全完整性的目标失效概率。SIL3被认为是单个可编程系统中可达到的风险降低的zui高等级。
四、安全系统的多样性（diverSity）原则
安全系统可以采取多样性原则克服可能发生的故障，或设计分析中存在的不确定性。多样性是指用不同方法执行所要求同一功能。例如:可用不同的物理方法或不同的设计途径来达到多样性。
多样性分为:①信号多样性；②功能多样性；③设备多样性；④软件多样性（如指令运算的多样性）；⑤人员多样性等等。其中较为常用和有效的是信号多样性和功能多样性。
对所采用的多样性措施是否适当应加以论证。为了保证能切实执行多样性，对设备的多样性或仪表控制系统的软件多样性所进行的论证，必须扩展到这些设备的硬件、软件部件，如实时操作系统RT0S。图4是57-400F运用指令运算的多样性和时间冗余来提高安全功能的可靠性。操作数A、B在CPUI进行“与”运算，结果为C;A、B经过编码变成字A、B，在CPU2中做“或”运算，结果为D=/C。在比较器中进行比较运算，仅当D特/C时输出停机信号。
再如某核电站的紧急停堆系统由两个*独立的系统构成。其安全控制系统由不同的供应商提供。一个停堆控制系统采用安全PLC系统，由3个独立的3机冗余表决的分系统（D、E、F）组成（见图5）。每个分系统都具备停堆功能，但其停堆输出还要送给3取2的继电器硬逻辑进行表决，zui终给出停堆信号口该安全PLC系统硬件平台配有操作系统，运用符合工业控制编程语言的标准IEC61131-3所规范的功能块图语言（FBD）编制应用软件。这套停堆控制系统采用T综合法（IntegratedApproach）设计。
值得注意的是，为了实现安全系统的机理多样性，还设置了另一套*不同机理的停堆系统，通过将有害的中子吸收剂（poison）注入反应堆中的慢化剂（moderator）的方法进行停堆控制。这一停堆控制系统采用没有操作系统的工控机硬件平台，安全控制软件运用高安全的具有子集的MODULA-2语言编写。这一套系统使用的是另一种设计方法一合理设计流程法（rationaldeSignProCeSS），用确定离子室记录的功率信号的合理性来检查异常差错信息。由此可见，在要求*的安全关键系统中充分运用了多样性的原则，有:机理的多样性、设计方法的多样性、设备的多样性、编程语言的多样性，这样就从系统的层面上把同时发生差错的概率降至尽可能的小。
五、重视处理假事件
各种安全系统（包括紧急停车系统ESD）如果对假事件作出响应，造成非计划停车，不但要付出高昂代价，而且在大多数情况下具有危险性。大量的假报警还会导致操作人员产生矛盾心理，以至于对危险的真报警都不予理会，或者反映很慢。
产生假事件的原因:①现场设备的硬件故障，如压力开关、
电磁阀的线圈或常闭触点存在高电阻，PLC的I/O模块有故障，现场设备中电子器件有故障，热电偶断偶，热电阻断线等，这些明显的设备故障都会引发假事件。②一些公用故障如电源、气源故障也会引发假事件。③缺乏维护，不及时对工作有缺陷的仪表、传感器进行测试、校验，是引发假事件的重要原因。
下面讨论信号多样性问题。看一个用3个
浮球液位开关测量液位的简单例子（图6）。我们可以有4种配置。采用单信号、双信号还是三信号更有利于安全和可靠的平衡呢？概括地说:采用单机（单信号）系统不安全且不可靠，在故障安全（假事件）或危险方面存在50/50的概率；采用双机（双信号）系统配置为二取一（1002），可能较安全，但存在高的假故障率；双机（双信号）系统配置为二取二（2002），由假事件引起的故障率较低，但安全性差；三机（三信号）冗余系统为三取二（2003），提供可以接受的安全与可靠的平衡。
显然，SlS/ESD不能选择单机（单信号）系统。选用双机（双信号）系统，在一定程度上可达到安全和可用性。二取一（1002）安全性较好，但可靠性及假事件的影响大；二取二（2002）可靠性较好，安全性却较差。即使双机（双信号）系统具有很好的自诊断性能，可以确定采用哪个通道或处理器故障，将坏的通道或处理器剔除，但这时双机系统降格为单机系统。三取二（2003）*的优点是不考虑哪个通道发生故障，是怎么发生故障的；也不*依靠自诊断来确定哪个通道投用。其亮点在于它仅要求所接收到的信息。三取二表明，若有一个信号不同于另外两个信号，立即报警，而这两个信号相同的通道处于安全工作状态。
从图6所示的例子可知，如果流程要求用于液位测量的仪表每年只能发生1次故障，而且每半年对浮球开关进行一次维护测试，那么对于不同的浮球液位开关配置，因故障造成危险的年概率如表3所示。
六、软件的可靠性难以量化
软件可靠性的基本问题是:①软件不受物理故障的影响。随着硬件元器件的可靠性越来越高，并可以采用冗余技术，因而安全问题的矛盾集中到了软件，以至于今天我们看到大多数的系统失效源自软件。失效常常由于一些非明显的事件组合造成，而不是由于机械应力超过一定程度造成。而这些非明显因素往往事先没有估计到，所以在软件的编制中考虑不到。②软件是由人来设计的，软件的设计不可能面面俱到，总有些因素在设计时没有考虑到，因此，设计的缺陷导致软件的故障。③数字系统本质上是非连续的，所以输入对输出的映射一定是不连续的。④软件建立在模型化和测试的基础上，这些工作都是人在做的。人难免犯错误，所以影响软件的可信度。
因为以上这些不可避免的问题，可以得出软件的可靠性难以量化的结论。另外，从趋势上讲，软件和人为因素导致失效、事故和停机的比例越来越高。因为现在对软件的依赖越来越高，软件变得越来越复杂，因而难以控制。人犯错误不可避免。硬件失效可能是系统失效的原因，系统的失效会引起软件的失效。有鉴于此，要保证工业控制软件的功能安全就不得不依赖于对软件进行严格的验证和确认。
七、工业控制软件的功能安全概念和方法
IEC6508-1规定了整体安全生命周期的16个阶段，包括:概念，整体范围定义，危险和风险分析，整体安全要求，安全要求分配，整体操作和维护计划编制，整体安全确认计划编制，整体安装和试运行计划编制，E肥尸E安全相关系统:实现，其他技术安全相关系统:实现，外部凤险降低设施:实现，整体安装和试运行，整体安全确认，整体操作维护和修理，整体修改和改型，停用及处理。与软件相关的是第9阶段“E/E/PE安全相关系统:实现”
在IEC615O8-3中详细地规定了执行安全功能的软件如何满足功能安全的要求。它规范的工控软件的功能安全问题包括以下方面:软件质量管理系统，软件安全生命周期要求，软件功能安全评估。它给出的是在软件的安全生命周期的各个阶段应该满足什么要求，以及如何来验证工控软件达到了功能安全的标准。IEC61508-3的突出贡献在于制订了一整套完整的开发程序和一系列技术措施，通过严格的质量管理与全生命周期的控制程序，实现避免故障、检测故障和排除故障，以及容许存在故障，从而保证软件的安全完整性能。总之，IEC61508-3给出了在安全相关系统的软件编制时应遵循哪些规范就能够达到功能安全的要求。这好比它编织了安全软件开发的“鸟笼”，以及在“鸟笼”里飞必须遵守的规则和约束；一旦飞出“鸟笼”就不能保证软件的安全。但它并没有具体规定工控软件在选用编制系统软件和编制应用软件时，应该如何选择适当的编程语言、指令集和数据类型，就可以从基础上保证软件的功能安全性。这些问题有些可以通过IEC61508-6（IEC61508-2和IEC61508-3的应用指南）和IEC61508-7（技术和措施概述）找到相应的具有实用性的参考规定和资料，有些就必须再进一步查找其它围绕不同应用领域的工业控制软件的功能安全的规范，如美国核管制委员会NRC发布的《核电站软件语言导则》、PLCopen组织发布的在IEC61131-3的开发环境下有关机械功能安全的规范《SafetySoftwareTechnioalSpecification》等等。
*，安全相关系统包括硬件、软件，软件必须运行于硬件系统环境中才能实现其价值和功能，在完成系统的功能安全时，一定要认识这二者之间的关系。通过图7所揭示的IEC61508-3与IEC61508-2的关系就能一目了然:IEC61508-2是总体，IEC61508-3只是局部。尽管它们可能是由不同的团队独立开发，但zui终还是要集成起来经过总体检验，才能够判断是否满足安全要求。软件的安全完整性等级采用表1低要求操作模式下的安全完整性的目标失效概率划分。达到SIL4等级的软件相当于每1.14年至11.4年之间发生1次失效。
八、安全系统的软件构成
与控制系统的软件构成一样，安全系统的软件也包括系统软件和应用软件两部分（见图8）。它们分别用全可变语言（fUnvariabilitylangUage,FVL）和有限可变语言（limitedvariability1angUage,LVL）编写（见图7）。这些概念都是将软件引入功能安全时建立起来的。
什么是全可变语言呢？其实此类语言就是计算机编程人员广泛使用的语言，它提供实现各种功能和应用的能力。典型的利用全可变语言的系统就是通用计算机。在过程工业中，只有在嵌入式软件（一般指固件或系统软件）中才使用全可变语言，极少在应用程序中使用。ADA、C、C++、指令表IL、Pasoal、Java、SQL均属于全可变语言。
有限可变语言在IEC61508-4中定义为:在工业和商业可编程电子控制器中使用且范围局限于应用程序的文本的或图形的软件编程语言。例如:引自IEC61131-3和其它标准或规范的有限可变语言，用来编写PLC系统的应用程序。它们分别是梯形图语言LD；布尔代数语言:带有增加某些记忆指令能力的，基于布尔运算符（如AND、OR和NOT）的低级语言；功能块图语言FBD:除布尔运算符外，可使用更复杂的功能，如数据传输文件、块传输读/写，移位寄存器和序列发生器指令等；顺序功能图语言SFC:有顺序之程序的图形表示，由相互的步骤、动作和带转换条件的定向连接线构成。
九、软件功能安全对编程语言的要求
编程语言并不是专为安全系统开发的，它们在出现安全软件的概念之前就发展了很长的时间。所以要用FVL和LVL完成安全系统的软件编写，首先必须对这些语言和用它们编写的程序提出要求和进行评估，以确定在什么条件下使用这些语言就能确保安全软件完成其保证功能安全的任务。
从另一方面来看，由于嵌入式系统已渗透到各行各业，这些年来，凡是对安全有重要要求的行业都很关注这个问题，制定了各自的规范。例如汽车行业建立了汽车工业软件可靠性协会MISRA，发布了专门用在汽车行业的C++语言的子集MISRAC++。美国核管制委员会NRC早在1996年就发布了《核电站软件语言导则》，之后97年又公布了其修正版NUREG/CR6463Rev.1。因为其性，直至现在它已成为安全软件的经典规范。不仅仅是核电，其它行业的软件安全问题也经常以此作为引经据典的文献。
在美国的核管制委员会发布了《核电站软件语言导则》NUREG/CR6463Revl中，对用语言编写的用于安全系统的软件进行了安全评述，着重指出以往发现的软件安全性问题和缺陷，从对应用重要性的理解、设计的方法论、学科发展和测试等方面加以阐述。
NUREG/CR6463Revl将软件安全的属性按三级架构加以分类和编排:*属性、中间属性和基本属性，如图9所示。
软件的可靠性属性是在所规定的条件下软件的可预测、且恒定一致的性能。由于软件的可靠性属性旨在减少在软件开发实现期间可能被导入源代码而造成误操作的故障，所以此*属性对安全来说是很重要的。
软件的鲁棒性是在异常条件或事件下，安全系统的软件以一种可接受的方式进行操作的能力。由于它加强了软件处理例外情况、从内部故障中恢复，以及阻止因异常环境而致使故障传播的能力，因此此*属性也很重要。
软件的可追溯性表现为:①对源代码和所引用的程序库部件的源头进行检查和识别；②通过对开发过程的可行性进行检查，来验证已执行的代码在其开发过程中是否按规范的方法完成其实现；③审视代码与高一级的设计文档相关联的能力。此属性之所以重要是因为这将便于对软件进行验证和认证（V&V），这是软件质量保证的另一方面。
软件的可维护性是在软件交付使用后若需对源代码做改动时，导致将故障引入的可能性减少的必要手段。此属性之所以对安全来说很重要，是因为在对软件进是因为在对软件进行适应、校正或完善期间可以尽量减少可能发生的误操作的故障。根据IEEE所给出的规定，软件可靠性是在软件编制、调试和执行运行全过程的环境下，既可以是在所定义的时间间隔内和所定义的条件下成功执行的几率，也可以是按照命令成功操作的几率。软件执行完成是其对于系统存贮器和程序逻辑恰当行为的结果。这意味着软件所产生的适时输出是编程人员对所使用的语言结构和运行期间环境特性理解的函数。因此可靠性的中间属性包括:存贮空间利用可预测性（软件不致造成处理器会向非预期的或不允许存贮空间进行存取的高概率）；控制流可预测性（处理器按编程员预期的顺序执行指令的高概率）；时序可预测性（软件在所定义的运行环境下满足响应时间和处理能力约束的高概率）；数学结果或逻辑结果可预测性（软件在所定义的运行环境下产生编程员所预期结果的高概率）。详见图10。
所谓软件鲁棒性是指在异常或其他未曾预计的情况下软件继续执行的能力。鲁棒性的同义词是耐久性（SUrviVability）。对安全系统而言鲁棒性之所以重要是因为在一个意外或偏离额定工况时会发生未曾预料的事件，在这样的情况下软件持续的对系统监控和控制的能力仍能有效作用。软件鲁棒性的中间属性和基础属性见图11。
软件的可追溯性是指与软件设计相比较，安全软件的那些支持其正确性和完整性验证的属性。可追溯性的基础属性有:可读性（这也是可维护性的属性），内嵌函数的可控的使用，编译库的可控使用。
软件的可维护性是为了有效减少在对软件进行修改时可能引入的差错。会影响安全的与可维护性有关的中间属性（见图12）包括:可读性一便干项目人员对软件的理解的软件属性；数据的抽象一对于那些代码被划分和模块化的区域，这样做可以使在修改软件时意想不到的副作用和次生的影响减至zui小；函数的内聚性一对代码中的软件元素给予设计水平的函数适当的存贮地址；可移植性一避免一种语言的非标准函数对安全的重大威胁；可塑性一将可能修改的代码区与软件代码的其余部分隔离开。
十、编程语言实现软件功能安全的方法
在NRC的NUREG/CR6463Rev.1完整版本中给出了将9种编程语言（Ada,Ada95,C/C++,PaSCal,PL/M,IEC61131-3规定的梯形图、顺序功能图、结构化文本和功能块图）用于安全系统时，应该关注它们特定的存在问题和如何加以克服注意点。譬如，对于C语言来说，是其指针的初始化问题；对于IEC61131-3所规范的编程语言，则应关注其时序、正常运行的监控，以及故障处理等问题。
从*属性中的可靠性、中级属性中的可预测性的控制流和基础属性中的在使用前变量的初始化这三方面导出对指针初始化的指导原则。所有的变量和指针在使用前都应该初始化。C语言支持通过说明来初始值的方式进行初始化，但并不要求所有的对象（指变量、数据结构或数组）进行初始化。在若干情况下，一个对象的初始化不仅要为对象的存贮地址一个特定的位的组合值，而且还要采取特殊的动作来为对象的生命（例如为对象赋予对应的源）进行平滑初始化。在C++中，可能要考虑任意相关数据作为对象，并提供构造数据组一个实例的工具。这样便会以系统的方式破坏数据组当前的实例。
考虑到上述情况，必须对初始化提出以下导则:①不要对超出其说明范围的变量自动使用指针。存贮在指针的值对一个自动变量会包含超出其函数范围的无用输入。②指针的初始化，初始化问题也会在指针中发生。在安全系统中所有C语言中的指针变量，其初值都应该为NU11；所有C++中的指针变量，其初值都应该为0。在被使用之前，指针应对一个有效值予以测试。当一个指针被定义时，它没有一个地址与其相关联。使用一个未初始化的指针，会造成重写未曾预想到的指针的存贮地址。错误地重写存贮内容会引起严重的问题，包括对系统的崩溃。③要确保每一个指针的说明间接的运算符都是存在的。每个指针都应该有一个间接运算符（*）。
IEC61131-3所定义的5种语言除指令表语言（IL）与汇编语言相似外，其它语言都纳入了NRC关于编程语言的导则中。对这些语言特定的指导原则源于鲁棒性*属性和异常处理的中间属性。应该专注于在机组紧急停车时PLC的行为。通常此时所有的输出均应切断，但往往并非总是如此。一般PLC系统总是设计成在紧急停车时系统处于故障安全状态。某些PLC在遇到这样的情况时具有处理器能自动停止主梯形图程序的执行，转而执行“故障程序”的子程序。这使系统的设计者可以决定采取适当的动作，包括以一种安全的方式让系统停下来。问题在于:IEC61131-3规范中未涉及到允许PLC系统本身包含有某种预先设计好的硬件故障程序，当检侧到一定范围的故障条件时便会自动执行。不过，IEC61131-3允许建立非周期的任务，通过触发适当的内部诊断信息来执行处理特定类型的出错（I/*时降级运行模式、向操作员见面报警等）。
对于PLC系统，在编程的设计阶段就应在程序结构中考虑故障程序问题。这时必须遵从如下原则:①完整性故障程序不能依赖于检测到程序崩溃的所有特例，因此遇到PLC的主要故障时要有针对附加措施的安全保证。②可观察性故障程序要有状态记录和报警的能力。故障程序应显性执行，不被掩盖。③真实性检查在启动故障程序的情况下有可能将可以反映原来条件的程序存贮内容、数据文件或I/O状态破坏，因此故障程序应保证在执行故障处理前将这些环境加以保存，以便事后分析。④在故障程序不起作用时的靛障安全特性万一PLC系统的故障处理程序不起作用，系统设计仍要保证安全状态的后备措施。
PLC系统一般以的位和字的形式提供对应用程序的正常运行状况的监控，这些信息包括特定任务的执行时间、I/O刷新信息、I/O操作状态信息、电池状态信息和其它用来确定PLC正常运行状态的信息。遗憾的是IEC61131-3规范中对这些信息的典型值、范围和类型并未做出规定。而安全系统恰恰应该具备这些信息，作为判断其是否运行正常的检查和是否需要异常处理的*的部分。
在IEC61131-3的规范关于“任务”这节中，阐述了制造厂应向用户提供所有任务执行的信息的zui低要求。关键在于由干这一问题的分类落在出错检查，而未能在规范中描述，于是我们也得不到这些任务执行时在运行时应以何种形式接受检查的规定。另外，许多PLC和类似的符合IEC6113卜3的系统一般只给出每次执行所有任务的周期（即所谓的扫描周期），却忽略了单个任务执行周期信息和标志的提供。如果因为安全原因需要在执行某个任务超时N次时必须紧急停车，在PLC现有的能力下是无能为力的。为了解决这个问题，必须让应用程序能够对单个任务执行其超时的检测，并给出单任务超时的标志，这样才能做出适当的反应。对于安全关键系统，监控任务超时的问题尤其要紧。必须在程序开发的检查阶段关注。
十一、在安全系统中推荐采用的编程语言
在IEC61508-7的附录C.4.5中给出了适合用于安全系统的软件编制推荐的语言（见表4），表中列举了24种编程语言，其中适用于安全系统的软件编制的语言共9种，它们是:属于全可变语言FVL有5种（具有子集的ADA，具有子集的MODULA-2，具有子集的Pascal，具有子集的FORTRAN77，具有子集和编程标准并使用静态分析工具的C）；属于有限可变语言LVL有4种（具有定义的语言子集的梯形图，具有定义的语言子集的功能块图，具有定义的语言子集的结构化文本，具有定义的语言子集的顺序功能图）。
PLCopen组织与专业从事安全认证的机构TUV一起定义了在IEC61131-3的环境下涉及机械安全的规范《SafetySoftwareTechnicalSpecification》。其中仅规定了两种具有定义子集的语言（功能块图语言FBD和梯形图语言LD）可用于机械安全系统。
