我从自动化行业的一些新用户那里听说,他们仅仅只了解工业自动化中一些使用的产品技术,对于那些技术的概念却一知半解。
而今天这篇文章就旨在帮助那些不熟悉工业自动化领域的一些专业人士,无论是在职业生涯的开始,还是从IT或者其他背景进入到操作技术(OT)世界的你们。
在这篇文章中,我将讨论冗余问题。这个术语经常被广泛使用,有时它可以是一个简单的应用程序,但它也可以快速解释为具有大量技术细节的复杂讨论问题,它的存在比一篇博客文章关于它所能涵盖的范围更广。
我的重点是深入了解使用冗余的原因,推动冗余程度的业务因素,自动化系统中的类型或级别,以及自动化软件系统实施的注意事项。
什么是冗余?
冗余是指系统中的备份组件可以在主要组件发生故障时接管它们的工作。但是备份哪些组件?我会说,任何对你的操作至关重要的组件,都可能是一个会阻止整个过程的单点故障。
我们可以看到人们在冗余系统中实现的一些组件包含但不限于:
物理网络
网络适配器,网卡(NIC)
PLC的
输入传感器
输出控制设备
OPC服务器软件
物理服务器
HMI / SCADA操作员站和服务器
电源/ UPS
冗余的目标是消除单点故障,并为你的过程提供可靠的正常运行时间。在考虑你的冗余需求时,你应该检查整个系统,并了解任何一个部分失败后的后果。非计划停机的一些主要后果是以生产能力的损失,生产废料以及工人和设施安全等因素来衡量。这些因素的业务成本越高,冗余对于最大化系统生产至关重要的可能性就越大。
你可以在冗余上花费的数量没有限制,但所有决策都必须考虑在没有冗余系统的情况下失败的代价。
冗余中的常见术语是“碰撞”。“碰撞”是指过程中断,例如计划外停机,机器停机。每个工业过程在碰撞的后果方面都是不同的。如果你处于连续钢板生产过程中,输入原材料流量恒定,连续钢板输出,下游机器将钢材切割成不同尺寸,你可以想象任何一个部件的停工都会造成多么大的破坏!
连续过程通常会使用累加器来缓冲一定数量的产品以允许短暂停止或暂停,但即便是那些只能走到这一步。在纸张生产中,其涉及将湿纸浆连续进料到以极高速度移动的幅材上,超过几百毫秒的碰撞可能都是不被接受的。你的生产过程可以承受的“碰撞”越短,那么你的自动化系统中的冗余就越重要。
影响冗余要求的另一个因素是:如果生产过程停止,重新启动生产过程需要多长时间。在关闭后,有一些连续的过程可能需要数小时甚至数天才能重新启动。重启的时间越长,冗余就越重要。
同样,过程关闭的要求也很重要。化学品和炼油的过程无法做到以无序方式关闭而不会造成灾难性后果。通过这些系统,你将找到专业供应商,他们制造三重冗余安全关闭系统,具有三重冗余输入和输出,以及复杂的三分之二投票方案,以确保无论如何都能使该过程有序地降低!从逻辑上讲,在完全冗余的系统中是没有单点故障的。每个硬件或软件组件都需要是冗余的,或者根据需要支持冗余架构。
作为控制工程师,你的工作是寻找适合你流程的冗余级别,然后确定最有可能导致故障的系统组件,并且这些组件需要多少冗余才能达到预期的系统可靠性水平。
一旦了解了要冗余的内容,接下来要做的就是必须决定何时以及如何在系统之间进行故障转移。你需要确定将使用哪些信号和标准来确定一个主系统不可用?这些信号能够以足够快的速度告诉你,以确保你的故障转移,而不会在你的过程中造成不可接受的碰撞吗?选择正确的标准和信号是一种谨慎的平衡。如果你选择过于敏感的东西,你可能会得到误报并产生不必要的故障转移。如果它们不够敏感,你会得到不必要的碰撞。
你需要决定哪个系统将决定故障转移到备份系统。如果发生这种决定,将针对每个流程和应用程序以及可接受的碰撞时间而定。
对于非常重要的事情,你显然希望确保合适的人知道故障转移已经发生,何时以及为什么,以便他们可以采取措施来修复主系统,并为备份系统可能出现的更大问题做好准备,然后做到失败只在主服务器返回服务之前。 要做到这一点,那些决定故障转移的系统应提供可由警报系统监视的数据,这些警报系统会向正确相关的人员发送电子邮件,短信或其他提示。这些系统甚至可能具有生成通知的内置功能。 关键是你必须随时了解系统状态,以及一些主动通知异常状态的方法。
接下来你需要决定,我怎么知道主系统又回来了?你是否希望主系统在返回时成为新的辅助系统,或者你是否希望在主系统返回指定的时间段后进程自动故障回复到主系统?你是否希望被告知主系统已经返回,然后手动故障回复到主系统?在你开始选择软件和硬件组件之前,这些都是你想要了解的因素。
接下来,让我们探讨一些常见的冗余区域,这些区域是用户将软件应用程序集成到自动化系统中时常听到的。
网络冗余的目标是为了防止通过网络丢失与其他系统的连接。这对你来说是否重要主要取决于你运行的系统类型。独立的HMI与单个PLC通信,直接连接到PLC,否则只能将网络访问作为“不错的”功能,可能不需要冗余。
具有多个操作员站,通过以太网连接的多个PLC,通过以太网连接到驱动器的PLC,多个服务器或系统间通信的系统可能具有严重的冗余要求。如果失去网络连接则意味着你的过程可能会停止和失控,与此相关的成本是不可被接受的,那么你此时将需要拥有一个冗余网络。
这可能涉及冗余网络布线,交换机,可能的环网以及任何其他网络基础设施,以确保即使网络中的一个网络出现故障,网络流量也将始终有效。目标是提供冗余通信路径。
在PC或服务器级别,你可能需要计算机中的冗余网卡(NIC)。这样,如果主NIC失败,则网络流量可以使用备份NIC。
无论你拥有多少冗余,你用于数据收集,记录和报告的软件都需要能够通过故障转移顺利地与你的架构协同工作。网络基础设施的某些部分对计算机和软件是透明的,并且可能不需要软件中的任何特殊功能。通常来说,冗余网络交换机属于此类别。
当你开始在计算机中使用冗余网卡以及具有不同IP地址的冗余网络路径到达同一目标设备时,你的数据收集软件(如OPC服务器软件)可能需要进行设置以了解何时应该将故障转移到备份网络。
运行对生产至关重要的任务的PLC也很常见。其想法是为控制设备提供冗余。通常,这是你的数据收集软件还需要支持冗余的区域。
如果你正在使用OPC服务器软件,并且具有冗余PLC,那么与这些PLC通信的软件必须能够支持该架构。软件需要知道哪个PLC是主PLC,哪个是次级PLC,什么条件会导致故障转移到辅助PLC,以及何时切换回主PLC。
理想情况下,该软件还将为你提供在HMI,SCADA或报警系统中监视和显示OPC服务器与之通信的PLC(主要或次要)的方法。
我们不想在这里停下来让我们的OPC服务器运行的计算机成为单点故障。这意味着我们需要冗余PC上的冗余OPC服务器。为此,我们的OPC客户端能够支持冗余OPC服务器。
支持冗余OPC服务器意味着OPC客户端 - 你的HMI / SCADA系统,报警系统,MES系统或其他系统 - 将需要知道与哪个OPC服务器进行通信。你还需要确定是否希望两个OPC服务器同时轮询你的设备,或者你是否希望一个OPC服务器进行轮询,备份是否处于备用状态而不是轮询。通过管理OPC服务器中项目的活动状态,这是 OPC 客户机在 OPC 主从式架构(OPC客户端到OPC服务器)中的责任,因此有可能实现上述两种情况。
大多数OPC客户端不处理冗余管理的这些细节。一些HMI / SCADA系统支持冗余,但有时它涉及脚本和其他自定义编写的代码。因此,在许多情况下,你需要一个软件来管理和优化与两个OPC服务器的连接。你的OPC客户端与冗余管理软件对话,就好像它是实际的OPC服务器一样。
显然,有很多与这些配置相关的细节超出了我这篇文章所能涵盖的范围。冗余可以很简单,也可以根据你的业务需求迅速变得复杂。去仔细考虑,了解你的业务需求,并了解你当前的应用程序在冗余方面可以处理和不能处理的内容是非常重要的。
目前有现成的软件应用程序,如TOP Server,可以帮助你管理冗余要求。