当前浏览器版本较低,部分功能响应较差。使用完整功能,请升级浏览器到最新版本或IE9以上。谢谢!

浅析IEC 61508 2.0版对安全仪表系统产品开发提出的新要求

来源:时间:2013-09-04

| 北京888贵宾会系统工程有限公司 周有铮 发表于《中国仪器仪表》2013年第8 
 
摘要:
功能安全基础标准IEC 61508 2.0版对包含安全仪表系统在内的功能安全产品开发提出了新的要求。本文就系统性能力、硬件安全完整性、软件安全完整性、功能安全管理等几个方面对这些要求进行分析,探讨这些新要求在安全仪表系统产品开发中的实现方式。
关键词:
功能安全;IEC 61508;安全仪表系统
 
Abstract:
The version 2.0 of basic functional safety standard IEC 61508 raises new requirements on the development of functional safety products including Safety Instrumented Systems. The new requirements are analyzed with systematic capability, hardware safety integrity, software safety integrity and functional safety management addressed, and the practical realization methods regarding the new requirements in the development of Safety Instrumented System product are discussed.
Keywords:
Functional safety, IEC 61508, Safety Instrumented System
 
1. 引言
近年来,随着功能安全技术的快速发展,功能安全的理念在工业自动化领域逐渐得到重视,安全仪表系统(SIS)成为实现功能安全、保障安全生产的重要组成部分。
为了证实一个SIS产品能够满足安全需求,必须依据一定的标准,从功能安全角度对其进行评估。国际电工委员会(IEC)于2000年发布了IEC 61508《电气/电子/可编程电子安全相关系统的功能安全》标准,对功能安全、SIL等基本概念进行定义,也对功能安全产品的设计、开发、使用和评估做出了要求。目前,IEC 61508已成为对包括SIS在内的功能安全产品进行功能安全评估的基础标准。
2010年,在总结了近十年的技术发展和应用经验基础上,IEC 61508发布了2.0版本。新版本标准不仅与时俱进地更新了几乎所有技术相关的内容,也依据功能安全技术的发展趋势提出了诸多新的要求条款。对于SIS制造商、集成商和用户,如何使产品的设计、集成和使用尽快满足新版标准成为一个关键问题。本文针对新版IEC 61508标准中与产品开发相关的新要求,探讨这些要求如何在SIS开发过程中得以实现。
2. 系统性能力要求
对失效的避免和控制是确定SIL的关键因素。IEC 61508将失效分为随机硬件失效(random hardware failure)和系统性失效(systematic failure)两大类。其中,系统性失效是指与设计、制造、操作流程或文档中存在的问题相关的失效。系统性失效具有确定的原因,因此可以采取技术和措施来避免或控制。
在新版IEC 61508中,定义了一个新的概念,即系统性能力(SC, systematic capability),来表征一个组件的系统性安全完整性是否符合指定的SIL的要求。系统性能力也分为4个级别,SC 1 ~ SC 4,与SIL的4个级别分别对应。也就是说,一个组件具有SC n,就代表着其系统性安全完整性满足SIL n。要使一个组件具有SC n,需要按照标准的要求,采用满足SIL n的技术和措施来控制和避免系统性失效。
以上要求本质上并非新的内容,但SC概念的提出明确地强调了SIL并非只与系统冗余程度和安全参数有关,而同时也与避免和控制系统性失效的措施有效性紧密相关。当使用两个或多个具有较低SIL的组件来实现更高SIL时,就必须考虑组合后的系统是否具有足够的SC。例如,如图1所示,两个完全相同的SIL 2组件,均具有SC 2系统性能力。当二者并联冗余时,虽然硬件故障裕度(HFT)增加了1,但如果任意一个系统性失效就会导致组合后的系统丧失安全功能,则组合后的系统仍只具有SC 2,也就是说组合后的系统最高仍只能达到SIL 2,而不是SIL 3。要实现SIL 3,就必须采用满足SC 3的技术和措施来避免和控制系统性失效。例如,冗余的两个组件通过使用多样性设计等方法来避免共因失效。
 

图1 冗余系统SC与SIL关系示意图
 
SC概念的提出,为用户对如何真正实现所需的SIL提供了更清晰的思路,也对制造商和集成商的功能安全设计提出了更苛刻的要求。为了达到要求的SIL,SIS产品的制造商必须在设计开发过程中严格遵守标准,实施相应SC级别所要求的避免系统失效的技术和措施。集成商在设计安全回路时,除了考虑回路的冗余架构和安全参数是否满足要求的SIL,也必须同时达到相应的SC等级。
此外,对于已有使用经验的组件,新版IEC 61508标准还允许通过提供这些组件满足规定的使用中证实(Proven-in-use)的证据,来证实组件具有一定级别的SC。对于未根据IEC 61508第3部分的要求开发的软件组件而言,如果要在安全相关应用中使用,标准也规定了可通过提供一些特殊的证据来证实其具有一定级别的SC。
3. 硬件安全完整性要求
硬件安全完整性是系统安全完整性与随机硬件失效有关的部分,取决于系统冗余架构、安全失效分数和要求时危险失效概率(PFD/PFH)数值。
与系统性失效不同,随机硬件失效是由于硬件元器件的功能退化而导致的失效,是随机发生的。由于其必然性和随机性,因此只能通过设计合理的诊断措施来控制硬件随机失效,而不能完全避免。IEC 61508-1中规定,要声称具有一定的SIL,就必须在给定的系统冗余架构下满足一定的安全失效分数(SFF)要求和PFD/PFH要求。其中,SFF和PFD/PFH的计算与硬件元器件失效分析和失效率直接相关。
在第一版IEC 61508标准中,随机硬件失效被分为危险失效和安全失效两类。其中,安全失效包含了所有不会导致SIS拒动的失效。而在新版IEC 61508标准中,安全失效被重新定义为只会导致SIS误动的失效。对于其他既不会导致SIS拒动、也不会导致SIS误动的失效,根据其是否执行安全功能而分为无关失效和无影响失效,并且这两类失效不参与诊断覆盖率(DC)、SFF和PFD/PFH的计算。如图2所示。

图2 第一版和第二版标准中的失效分类区别
 
失效分类的变化要求SIS设计过程中对随机硬件失效做更详尽的分析,并且会使计算出的DC和SFF更低。因此SIS设计者需要设计更强大的诊断措施,保证系统的DC和SFF满足SIL的要求。
此外,对于已有使用经验的组件,新版IEC 61508标准还允许通过提供现场反馈的可靠性数据和允许的系统架构来证实组件具有一定级别的硬件安全完整性等级。但可靠性数据必须具有一定的置信度(至少90%),并且对系统架构的HFT要求更加苛刻。
4. 软件安全完整性要求
软件安全完整性是与软件失效有关的部分。对于软件,考虑的失效仅为系统性失效。在IEC 61508标准中,与SIS设计相关的软件包括系统软件和软件工具两大类,而不包括与应用场合相关的应用软件(对这类软件,一般在应用相关标准中做要求)。新版IEC 61508标准对这两种软件都有新的要求。
系统软件的安全生命周期各阶段中,需要采用合适的技术和措施来避免系统性失效。为了使对技术和措施的选择更合理、更完善,新版IEC 61508第3部分中对软件安全生命周期各阶段定义了多个希望得到满足的属性,并对每种技术和措施给出了能够满足某种属性的严格度等级(R1~R3)。开发过程中,应结合考虑能否满足标准对措施的强制性要求和能否满足所有属性,来选择合适的技术和措施,并针对希望达到的SIL,来选择措施需要实施的严格度。
例如,在软件架构设计阶段,对于各种SIL,表A.2中的“模块化方法”都是标准强烈推荐的,因此需要选择该措施。在表C.2中,软件架构设计阶段希望实现“针对软件安全需求规格的完整性”、“针对软件安全需求规格的正确性”、“避免内在设计问题”、“简洁和可理解性”、“行为可预测性”、“可测性”和“故障容忍”等若干属性。根据表C.2,“模块化方法”针对上述属性中除“针对软件安全需求规格的完整性”之外的所有属性都有贡献。如果希望满足SIL 3,则应选择至少R2等级的严格度来执行该措施。除该措施之外,还必须选择合适的措施来满足“针对软件安全需求规格的完整性”属性。
SIL的实现不仅与系统软件(嵌入式软件)有关,也与用于组态、配置等功能的软件工具有关。新版IEC 61508中,着重强调了这些软件工具对实现安全的重要性。对于在线的软件工具,即在安全产品运行时可直接影响产品功能的软件工具,必须与安全相关的嵌入式软件相同对待。而对于离线的软件工具,根据其对安全产品的影响程度的不同分为T1、T2、T3三类,要求有所不同。根据IEC 61508对这三类离线软件工具的定义,T1工具可认为是对安全无影响的,例如代码编辑工具,使用时无需进行特殊考虑。T2工具会间接影响安全软件代码的质量,例如代码动态分析工具,需要对工具可能存在的缺陷进行分析评估,并在使用中避免。T3工具直接生成安全软件的代码和数据,例如用于生成安全相关二进制代码的编译器,需要采用必要的测试手段验证其功能符合其规格,或提供其在类似安全应用中的成功使用证据。
上述标准条款进一步提高了对SIS系统软件及外部支持软件工具的要求,对避免系统性失效更为有效。对于SIS制造商和集成商,无论是选择现有的软件,还是开发新的软件,都需要针对以上要求进行必要的分析、论证和测试,以证实避免软件系统性失效的措施具有足够的有效性。
5. 功能安全管理要求
从功能安全管理方面,新版IEC 61508标准最大的变化体现在安全生命周期的变化和对安全手册的要求。

 

图3 ASIC安全生命周期(引自IEC 61508)
新版IEC 61508标准将原来的总体安全生命周期中的“E/E/PES实现”阶段分为了“E/E/PES安全需求规格”和“E/E/PES实现”两个阶段。其中,新的“E/E/PES实现”阶段增加了“E/E/PES设计需求规格”子阶段。这个变化的主要目的是为了将由用户提出的“E/E/PES安全需求规格”与产品设计者编制的“E/E/PES设计需求规格”明确区分。前者的重点在于明确从总体安全需求规格分配而来的E/E/PES所需实现的安全功能需求和安全完整性需求,而后者必须从系统设计者的角度将用户从应用角度提出的需求转化为可实现的系统设计指标。
安全生命周期的另一个重大变化是提出了专用集成电路(ASIC)的V-模型,如图3所示。随着ASIC、现场可编程门阵列(FPGA)和复杂可编程逻辑器件(CPLD)等大规模可编程逻辑器件在安全产品中的应用日益广泛,这些器件的开发过程是否符合安全要求对整个产品的功能安全起着举足轻重的作用,V-模型的提出旨在将功能安全的理念融入这些器件的开发过程中。由于这些器件的开发过程与软件类似,因此标准也采用了和软件开发过程类似的V-模型。同时,在IEC 61508第2部分附录F(资料性)中,给出了ASIC、FPGA、CPLD等器件在其安全生命周期中需考虑的避免系统失效的技术和措施,需要在V-模型的实施过程中遵循。
安全手册是安全产品制造商提供给集成商和用户的指南文档,用于提供产品针对IEC 61508标准的所有符合项信息,以使产品能够被按照IEC 61508的要求进行集成和使用。新版IEC 61508第2部分和第3部分的附录分别规定了E/E/PES和软件的安全手册要求。由于这些要求是规范性要求,因此制造商必须提供详尽的安全手册,通过这个桥梁为在产品集成和使用中实现功能安全提供便利。
6. 结语
IEC 61508是国际通用的功能安全的基础标准,其核心内容之一即为对包括SIS在内的功能安全产品的系统、硬件、软件设计做出详尽的要求,以使其能够按满足功能安全的方式进行设计和开发。新版IEC 61508基于功能安全理念的发展趋势和技术的更新进步,从系统性能力、硬件/软件安全完整性要求、功能安全管理等各方面提出了若干新的要求。可以预期,由IEC 61508衍生而出的各领域功能安全应用标准也将逐步进行更新。由于功能安全产品需经过评估认证,标准增加的新要求对于SIS产品开发的技术和成本提出了新的挑战。然而,这也是一个契机,满足新标准的产品将具有更高的质量和技术优势,也由于体现了更接近实际的功能安全理念而有助于为用于创造更多的价值。
 
 
参考文献:
1. IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems, Part 1~7.
2. IEC 61511:2003, Functional safety - Safety instrumented systems for the process industry sector, Part 1~3.
3. D.J. Smith, Reliability, maintainability and risk - Practical methods for engineers, 8th edition, Elsevier, 2011.
4. IEC Functional Safety. http://www.iec.ch/functionalsafety
 
 
作者简介:
周有铮,功能安全经理,从事功能安全管理、技术研究和产品开发工作。
XML 地图