工控网首页
>

应用设计

>

安全PLC嵌入式软件实现可靠性的技术

安全PLC嵌入式软件实现可靠性的技术

来源:automationworld There is a strong trend toward the use of programmable electronics in safety instrumented systems. Yet some users still avoid software-based systems. They cite the unpredictability of software and case histories of software failure. However, a special class of PLC called a “safety PLC” does meet the need for safety and high availability in critical automation. A safety PLC must meet the requirements of a set of rigorous international standards that cover the design, the design methods and testing of software and hardware. Third party experts (typically T¥V in GERMANY) enforce the rigor when the products go through the certification process. Some of the methods used to build “high integrity software” for safety PLCs are described in this paper. 绪论 用于关键过程控制和安全仪表系统的设备的软件数量持续增长。这是因为在安全仪表系统中,使用灵活的安全PLC代替继电器或DCS有强大的趋势。安全PLC是基于微型计算机的控制器,设计用于高安全和高可靠性的应用。安全PLC提供应用灵活性、自诊断、到其他工厂自动化系统的通讯接口、帮助阻止人为错误的自动应用工具以及在常规PLC/DCS设备中不能得到的可靠性等级和安全等级。 当通过一系列由第三方认证机构(例如,德国TUV或美国FMRC)提供的测试时,PLC才具有安全PLC的资格。安全PLC通过每个国际标准认证,主要是IEC61508 [2]和VDE0801/A1[3]。这些标准要求广泛的软硬件的安全分析。分析的关键部分是PLC的诊断能力。在VDE0801/A1标准中,定性规则是“未知危险不能检测故障”的应用。在IEC61508标准中,必须完成硬件故障的详细量化分析[4,5]。那个分析决定了“诊断覆盖率”,在0%到100%之间。根据目标安全完整性等级以及安全冗余的量,期望的诊断覆盖率是90%。安全PLC也被评估从而确保电气安全、用户手册完整性、容错架构和软件完整性。软件完整性是常规PLC/DCS设备和安全PLC的另一个关键区别。 高完整性的软件 当在某些地理区域,一些调整机构仍不允许基于软件的设备应用到关键过程控制或安全保护应用中,大部分已经认识到在安全认证的基于软件的控制器中可以得到加强的诊断值。这些调整机构不允许软件引用复杂软件和软件故障历史[6]的非预测性。 也许有理由怀疑一些类型的客户级软件的可靠性和安全,但是安全PLC的设计人员使用的国际标准有严格的要求从而增加软件的完整性。标准强调根据生命周期模型进行产品开发的过程。当一些模型仍可用时,由于在产品开发过程中设计和测试规范之间的联系,“V-模型”是推荐的选择(见图1)。兼容这些要求的软件技术会在以后讨论。
图1.V-模型,软件开发过程图1.V-模型,软件开发过程
标准覆盖从产品的功能要求到最终测试的整个开发过程,不只是软件实施。国际标准要求一整套设计用于确保最好的软件质量,避免故障以及故障控制的开发活动。这些活动包括程序执行诊断、数据校验测试、数据存储完整性、简化复杂性以及一套广泛的软件开发过程要求。通过认证机构的帮助,紧密遵守这些方针,从而实现“高完整性软件。” 总之,安全标准要求许多类型的产品(带软件或不带软件)所没有的质量和鲁棒性。VDE0801/A1 和 IEC61508规则是否在被应用,它们规定更严格的产品开发成就。这些产品的软件开发必须包括许多技术,这些技术对普通的软件供应商来说极端昂贵(在时间和资金)的。 关键软件过程 Juran 和 Deming开发的以工厂运行为质量原则而闻名与世。这些质量原则要求估计过程,然后按照过程进行。当按照过程进行时,也许看到明显之处,很容易把软件质量认为是理所当然的,以及在初始设计完成后,简化过程。这意味着有时是“软件文化”的一部分,特别是当一个项目延期时。 关键安全软件开发过程强调V-模型,该模型从产品要求出发。要求回顾决定所有安全相关的要求是否存档。如V-模型所示,产品校验测试和产品要求同时开发。当产品要求完成时,测试计划能完成,也应该完成。测试计划回顾提供好的任何特定要求的可测试性(要求合理性的测试)的交叉校验。测试计划回顾也在很多设计发生前揭示缺少的要求。 要求考虑整个工程的基础,并应严肃对待。每个要求必须在可量化的术语(“模拟量通道应能在一秒内检测任何引起一个值大于量程的+/- 2%的故障”)中陈述安全功能。过程的一个重要方面是要求测试的可追踪性。当核对这个步骤容易时,它也帮助开发人员识别缺少的和重复的要求。测试努力必须显示满足产品要求的正确性和完整性。正确性意味着软件运行平台严格地按设计进行,满足匹配的要求以及为故障检测采取恰当的行动。完整性意味着所有要求必须满足。 管理机会 对开发项目组来说,保持对变化要求的控制非常重要。应恰当地识别文件(包括版本历史)。以前的回顾应通过满足的细节保持,这些细节包括问题决议和达成一致的行动项目。如果决定影响要求,项目组必须返回过程,并判断对产品其他方面的影响。项目经理必须回顾和确保所有行动项目的完成。更重要的是,项目组必须把设计问题的非正式决议转换到设计文件。不是所有的设计决定都是通过正式的回顾做出的,许多决定能在、也应该在恰当地实施决定的级别上做出。当以这种方式做出决定时,应更新恰当的设计文件。文件跟踪通知所有项目股东已做出变更。 安全PLC软件技术 软件故障不会任意发生,也不能克服软件故障;所有软件故障都在系统里设计。当特定输入、定时、数据的结合在系统的正确条件下出现时,每次都会出现故障。由于这个原因,软件系统的故障以“系统”故障闻名。制造特定软件是以前打算完成的,软件必须校验自身从而确定软件已完成它必须完成的功能。软件诊断被编程到嵌入式编码中。一个最有效的软件诊断是“流程控制”。程序流程校验确保以正确的顺序执行必需的功能。在程序的关键点,最好用时间戳设置“标志”,(见图2)。在校验每个程序扫描的标志的结尾处,在标志设置之间的时间差异能用参考值比较,从而做出进一步的错误检测。
图2.图2. 程序流程控制
另一个软件诊断称为“合理化校验”。当计算的结果一直在已知范围内,能测试计算的结果从而发现它们是否超出这些已知范围。在这种方式下,能在错误系统动作发生前检测系统故障。除了计算结果之外,在软件控制下得到并存储许多状态和值。当值是互斥的,这个数据的另外的合理化校验能在错误状态发生时标志故障。相同的机制能被用于基于软件的系统的信息方案。 在安全PLC里使用的数据必须保护崩溃。关键数据通过分析关键软件功能的执行流程识别。通常用数据流程图来实现,这个分析识别在安全要求里完成的关键功能软件过程。这些功能包括诊断和用户安全程序的执行。和这些软件过程相关的数据被命名为关键数据。关键数据通过不能检测的方式利用系统软件故障或硬件故障以不能变成崩溃的方式存储。 图2显示带过程链和反向考虑校验的数据流程图。#8过程提供#1过程到#3过程的交叉校验,检测正常处理链的故障。当#1至#3过程也能提供高度准确的基于产品规范的结果时,#8过程提供一个在产品安全精度范围内的比较,它常常精度低,但能检测一个错误的软件条件。
图3.带反向考虑比较的数据流程图图3.带反向考虑比较的数据流程图
关键功能的防火墙 当关键的安全功能必须与非安全软件功能结合时,设计必须为非干扰包括充分的安全措施。这意味着任何非安全的运行,例如从安全系统到工厂经理控制屏的数据采集,不能以任何方式妨碍或抑制安全系统的安全运行或故障检测机制。如果任何非安全功能有写数据到安全系统的可能性,写必须在可控环境下,并以允许的组态模式。系统设计必须拒绝对系统的任何意外变更。 软件复杂性 安全PLC标准要求专用技术从而降低软件复杂性。操作系统仔细检查任务的相互作用。要避免实时相互作用,例如多任务和中断。这是因为许多阴险的软件故障已被跟踪软件程序和多软件任务使用的通用资源之间的非预期的相互作用。当使用多任务时,实时多任务的相互作用要求广泛的回顾和测试。在多任务环境中,通过异步任务,避免通用资源(例如I/O寄存器和内存)的使用是非常重要的。 测试 在软件开发过程中,安全PLC需要额外的软件测试技术。必须证实关键分析的发现和假设。必须运行一系列“强制软件故障”测试从而校对数据完整性校验。在测试中,程序被有意中断,从而确保可预测性以及对软件的安全响应。专用于微处理器的硬件仿真器,常设置断点,改变程序数据,然后程序允许连续发现是否检测到故障。另一个测试模式使用内嵌到程序的定制软件。这要求一个监视程序接收用户专用测试码的输入。这些测试码调用时间独立的故障强制功能,通过一个仿真器很难完成。这些测试必须完全归档以便第三方调查员能理解运行。当这个活动在大部分软件开发中没有被证明是正当时,大部分有害的和隐蔽的软件设计故障怎样被发现是精确的。 故障和变更跟踪 当在软件设计和编码中发现可疑的问题时,它们必须记录以及使用正式系统[8]回顾。不是所有报告的问题都真正有缺陷,这些应该根据基本原理决定是否屏弃。不是所有发现的问题都是不可靠或与安全无关的。当问题被研究以及认为足够重要需要修复时,开发组应完成可疑缺陷的受影响分析。这些分析应包括:  ·精确问题描述;  ·在关
投诉建议

提交

查看更多评论
其他资讯

查看更多

基于Modbus的智能工业控制器监控系统的设计

不要忽略PC总线技术的发展

基于PLC的电梯高精度位置控制的实现

蓝牙工业现场总线应用模型

一种基于PID神经网络的解耦控制方法的研究 /