HIMAF3221

HIMAF3221

非致命故障

        非致命故障是PLC可以探测到，但不至于使PLC离开运行模式的故障。有些可探测的硬件问题，如内存的后备电池电压低，只导致非致命故障。非致命故障也可以由组态和编程错误引起，如一个定时中断程序的执行被一个更高优先级的程序的运行而延迟，或者一个算术操作产生了一个太大以致无法存入 目标内存的数，等等。

        非致命故障导致PLC设定相关的状态位或者将相关的错误代码写到内存中。当结果太大或太小以致无法保存时，数据字处理指令将把内存中的算术标志位设置为1。用户程序应当检查这些状态位或代码，并作出响应，因为PLC将像没有错误发生一样继续执行程序，有些非致命错误状态位在前面的章节已经讨论过，本章我们将讨论另外一些。

        编程或组态逻辑错误

        这些错误是PLC不能自动检查出来的，但可以用程序中的故障检测指令或者编程单元的程序监视功能来检查。

        逻辑错误的例子包括一个用户将一位设为OFF而不是ON，两段用户程序试图控制同一个输出，或者结构化编程旁路了一段需要的程序等等。

 安全PLC与常规PLC的不同还在于：安全PLC需要得到第三方专业机构的安全认证，满足苛刻的安全性和可靠性国际标准。必须*地采用系统方法，来设计和测试安全PLC。德国的TUV专家和美国的FM专家会提供对安全PLC设计和测试过程的、第三方独立的确认和验证。

        特殊的电子线路，细致的诊断软件分析，再加上对所有可能失效进行测试的完整性设计，确保了安全PLC具有测定99％以上的内部元件潜在危险失效的能力。一种失效模式、影响和诊断分析（FMEDA）方法一直指导着设计，这种方法会指出每个元件是怎样引起系统失效，并且告诉你系统应该如何检测这个失效。TUV的工程师会亲自执行失效测试，把它作为他们认证过程的一个部分。

        严格的国际标准软件应用于安全PLC。这些标准需要特殊技术，避免复杂性。更进一步的分析和测试，细致地检查操作系统的任务交互操作。这种测试包括实时的交互操作，比如多任务（当使用时）和中断。还需要进行一种特殊的诊断，被称为“程序流控制”和“数据确认”。程序流检查能确保基本功能能按正确的顺序执行，数据确认使所有的关键数据在存储器里进行冗余存储，并且在使用前进行有效性测试。在软件开发过程中，一个安全PLC需要附加的软件测试技术。为了核实数据完整性检查，必须执行一系列“软件失效注入”测试，也就是人为对程序进行故意破坏，来检查PLC的响应是否运行在预计的安全方式。软件的设计和测试带有详细的文件资料，这样第三方的检查员就能够明白PLC的运行原理，而多数软件开发没有使用这种规范的操作流程，这也正好说明为什么众多的垃圾软件会出现那么多的臭虫而无法发现了。

Siemens 6AV8100-1BA00-0AA1 

Kuhnke KDT.636

Siemens 6FX1138-5BA01 

Siemens 6SG2010-1CA11

Siemens 6SG2210-1CA00/6SG2 210-1CA00

VLT6004/VLT6004HT4C54STR3DLF00A00C0

Siemens 6FC3551-0AC-Z

Siemens 6SG2210-1CA00/6SG2 

Siemens 6FC3551-0AC-Z 

Siemens 6SG2210-1CA00 

VLT6004/VLT6004HT4C54STR3DLF00A00C0 

Siemens 6SG2010-2CA10 

Bosch SR600 

Okuma BL-MC24E-30SN 

Siemens Sinumerik 6FC5111-0BA01-0AA0

Siemens CPU416-3 6ES7416-3XL04-0AB0

Siemens Sinumerik 6FC5111-0BA01-0AA0