Best practices for connecting to process control, machine control, and condition monitoring systems.
Thirty years ago, the phrase “islands of automation” was commonplace. It described instrument and control systems that exhibited very poor connectivity and were thus “islands unto themselves.” What little connectivity existed might consist only of analog 4-20mA outputs or discrete signals from relays. Although the phrase may not be as common these days, the ability to properly connect systems to one another remains a concern. However, where at one time connectivity may have meant simply fitting a platform with the right digital protocol so that it could talk to other systems, the issue of cybersecurity is today a primary concern where it wasn’t even in the dictionary three decades ago. Indeed, the issue in the past could normally be overcome by selecting from among the various digital communication protocols used in industrial automation: Profibus, Modbus, ControlNet, Foundation Fieldbus, HART, OPC, etc. Manufacturers had to decide which of these to support in their instruments, users needed to decide which ones to use, and third-party entities sprang up in abundance with hardware protocol converters and software that gave rise to the term “middleware” and could be used to allow systems with dissimilar protocols to communicate.
A typical plant has at least three other systems with which a machinery protection platform like the VM600 must be able to communicate:
1) The Process Control System (often a DCS)
2) The Machine Control System (often a PLC or purpose-built platform specifically for machinery control such as by the machine OEM or a supplier like Woodward, Compressor Controls Corporation, Tri-Sen, etc.)
3) The Condition Monitoring System (usually from the same supplier that provides the machinery protection system)
In addition to these three, there are other systems that touch rotating machines and must be considered as well. These include:
• The Emergency Shutdown (ESD) System which will often exist independently of the machine control system. Its task is to bring not only the machine, but the surrounding process to a safe state. Because it controls the shutdown of the process – and not just the machine – it is often separate and distinct from the machine control system and may well incorporate SIL ratings if implemented as part of risk reduction and process safety.
• The Combustion Dynamics Monitoring System which is generally present on all so-called “Low-NOx” gas turbines and often integrated tightly with (i.e., in the same chassis as) the machinery protection system. However, this system will not be present when the prime mover is something other than a gas turbine, or when the gas turbine does not use Low NOx combustor designs.
• The Process Historian (sometimes called “Operational Data Historian”) which is basically a large database that archives all of the data from the DCS plus instruments that may not send all of their available data to the DCS. The OSIsoft PI System is one popular example of a process historian. Others include the Yokogawa Exaquantum™ system, the AVEVA Historian (formerly Wonderware™), InfoPlus.21® from AspenTech, the SIMATIC Process Historian from Siemens, and many others. Fundamentally, these systems take the quasi-static data produced by field instruments and allow the data to be trended and archived for many years rather than the shorter-term historical data (days, weeks, or months) available in the DCS’s limited archive.
• The Overspeed Protection (OSP) System which is separate and distinct from the machine control system that controls speed. The OSP exists precisely because the speed control system may itself fail and a secondary system is needed to ensure that the machine cannot experience “run away” acceleration to speeds that would destroy it and damage property, the environment, and even human life.
Although this list is not exhaustive, it serves to illustrate the idea that the machinery protection system itself does not exist as an island in a typical plant and instead must communicate directly or indirectly with numerous other systems. In the remainder of this article, we will address the four primary interfaces that are present where the VM600 platform is most often used: protective, process control, condition monitoring, and combustion dynamics.
Hardwired relays remain the preferred and accepted way of interfacing the protective signals to the corresponding shutdown system such as an ESD or the machine control system; relays can often be hardwired directly to so-called “final control elements” such as a motor contact or valve that removes energy from the machine and thus stops it.
The protective interface consists of the signals that will be used to automatically trip a machine when it exceeds pre-determined alarm setpoints. There are usually two such alarms: ALERT and DANGER. In some instances, such as machinery standards from the American Petroleum Institute, these alarms are called HI and HI-HI (or LOW and LOW-LOW when an under-alarm is relevant). The highest level of alarm is often used to automatically trip the machine without the requirement for human intervention. The lower level of alarm is used to annunciate to operators that the machine is in distress and outside of normal operational bounds, even if not severe enough to warrant an automatic trip. While at one time there was no such thing as digital communications protocols and the only way to connect such signals to the machine control system, DCS, or ESD was by means of hardwired relay outputs, this remains the preferred way to connect so-called “shutdown” or “trip” signals. Although this might seem like an antiquated way to make such connections, there are several reasons for this.
First, a relay is a very simple device that is unlikely to fail. Indeed, it can be programmed to “fail safe” if the consequences of a missed trip are sufficiently high. Fail safe generally means that the relay is normally energized and thus if it loses power for any reason, it will change state and thus trip the machine.
Second, relays are fast and can act within milliseconds as opposed to a digital protocol that may introduce unacceptable latencies at both the transmitting and receiving sides. When the signal is sent digitally via a protocol like Modbus or Profibus, the interface itself is usually a computer of some kind (or even “middleware”) that can stop communicating. Although redundant media (copper or fiber) can be used, there is often only redundant media and not redundant interfaces. Then, there must be digital “handshaking” between the machinery protection system and the connected system (such as a PLC or turbine control system) using a so-called “gateway” device that communicates using the selected digital protocol. Unless the scan time of the PLC has been set to look at these inputs or query its gateway several times per second, too much time can elapse between the protection system entering a DANGER condition and this making its way to the ultimate shutdown system.
Third, although it is less common to wire a protection system relay directly to a final control element (FCE) such as a fuel valve solenoid, a steam valve solenoid, an electric motor breaker (via an interposing relay), or other device, this “direct” connection is occasionally encountered in practice when all of the voting logic is performed inside the machinery protection system and not in a separate device (such as an ESD system). Indeed, this is one reason why the larger power handling capabilities of electromechanical relays are often preferred in machinery protection systems rather than solid-state relays. Even if not connected to an FCE, another reason electromechanical relays are preferred is that solid-state relays may have unacceptably large leakage currents that result in erroneous logic states being detected at the receiving PLC, ESD, or machinery control device. In fact, this specific concern is addressed in API 670 section 10.7 where inputs to EDS systems are discussed. Thus, whether the shutdown signals will go directly to the machine control system, PLC, ESD, or FCE, hardwired relays are still considered good engineering practice. Indeed, API Standard 670 for machinery protection systems continues to preclude the use of digital protocols for protection, specifying the use of solid-state or electromechanical relays instead (refer to Std 670 sections 4.12 and 7.3). This is likely to persist into the 6th edition of the standard, currently in preparation.
Because communications with the process control system (usually a DCS) provide operator information but are not used for auto-shutdown protective purposes, digital communication using open, industry-standard protocols such as Profibus and Modbus remains the preferred way of connecting the machinery protection system to the process control system. This link allows operators to see current values, alarm statuses, and trends.
The interface with the process control system was at one time done entirely via analog hardwiring. Going far enough back in time, the vibration monitor itself was often located in the operator control room and analog meter movements on the front of the protection system served as the human machine interface that gave operators current readings and alarm statuses. When racks were instead located remotely at the machine, relays were wired back to the control room and connected to annunciator panels similar to the one below.
A typical annunciator panel found in machinery control panels and in plant control rooms. At one time, interfacing to such panels was done primarily by means of relay contacts. Today, it is more common for digital protocols to be used for sending status and values to the control room, whether directly to DCS screens or to an annunciator panel.
To complement statuses available via annunciator panels, trending was done via paper chart recorders and the most common interface between the protection system and such recorders was a proportional DC output – usually 4-20mA but sometimes a true voltage signal such as 1-5 Vdc or 0-10Vdc. These recorders literally traced out a trend on a slowly-moving piece of paper. With the advent of the DCS, such recorders became largely of historical interest and computer screens in the DCS console took the place of panel-mounted instruments such as annunciator panels and chart recorders. When the trends within DCS exceeded the available length, archival was done to the so-called process historian or operational data historian. The link between the machinery protection system and the process control system thus moved away from analog hardwiring to digital protocols such as Profibus, Modbus, and others. At one time these protocols used purely serial communications but now more commonly employ industrial Ethernet communications, such as PROFINET and Modbus TCP.
Analog chart recorders were used for trending and could be circular, such as shown here, or linear on roll of paper in so called “strip chart” format. Image courtesy of Eurotherm Chessell
Today, it is considered a best practice to employ digital communications between the protection system and the DCS (or PLC) for the purpose of displaying current values and statuses, and to allow trending of overall variables. It is important to recognize that these communication links are not used for carrying out shutdown commands and are instead considered “informational only”. Although it may be distressing for the operator to lose this communication link, it does not compromise the machinery protection functionality itself because that is hardwired via relays, as discussed in the previous section. Many operators choose to employ redundant media so that if a communications cable is cut, the other will continue to carry the necessary traffic. Indeed, some operators insist that redundant cables be segregated in different cable trays or underground conduit so that if one cable is cut or damaged, the other is not immediately adjacent and damaged as well.
The CPUMMk2 is an example of a digital communications card designed to connect a machinery protection system to a process control system using standard, open protocols such as Profibus and Modbus. The card forms part of the new VM600Mk2 architecture from vibro-meter.
There are several reasons why digital communications are preferred. The first is installation costs. Wiring statuses for two levels of alarm from every single channel can entail many wires. For example, consider a 24-channel monitoring system monitoring a machine with 20 radial vibration sensors, 2 axial position sensors, and 2 redundant phase triggers. If two alarm levels are set on all 24 channels, this corresponds to 48 relays, each with a twisted pair of wires to annunciate its condition. If we add to this the overall vibration values that will be trended, this is another 24 wires with 4-20mA signals that must be wired; in other words, a total of 72 wires. The cost of this wiring can be substantial and in some cases may exceed the cost of the machinery protection system itself. In contrast, a single digital communications cable can carry all of these signals as well as many other variables for each channel that are produced by the machinery protection system and can be trended such as Smax, 1X amplitude, 1X phase, probe gap voltage, and others. Thus, digital communications are preferred not only because installation costs are dramatically less, but because a much richer data set is available at the DCS and in the process historian. Indeed, “soft” alarms can be set in the DCS on some of these variables if desired to augment the alarms in the machinery protection system. In the VM600Mk2, alarms are also available inside the rack for these additional variables and do not have to be created in the DCS.
The condition monitoring interface is designed to deliver all the same data that goes to the process control system, but also dynamic waveforms that allow rotating machinery specialists to diagnose problems using rich vibration data. Proprietary protocols via industrial Ethernet are used for this purpose and considerable attention is paid to cybersecurity to ensure people accessing the system remotely are not able to compromise the machinery protective functions.
The interface between the condition monitoring software and the machinery protection system is digital and uses proprietary communications. There are no exceptions to this rule, regardless of manufacturer. The reasons that proprietary protocols are used derive from the fact that most “open” industrial protocols are not designed to carry the high throughput of data entailed by the dynamic waveforms of vibration sensors. It is generally not desirable to stream every single waveform for every shaft revolution to the condition monitoring software, and instead the monitoring hardware makes decisions regarding what data to collect and what data to send. These settings are user-configurable in most systems, including the VibroSight Suite software from vibro-meter.
The new MPC4Mk2 module combines machinery protection and condition monitoring on the same card, but with cybersecure segregation between the two. Ethernet communications on each module allow connectivity to vibro-meter’s VibroSight condition monitoring software.
The VM600Mk2 platform continues to offer integrated combustion dynamics monitoring, just as its predecessor did. Like the process control system interface, it uses an open, industry-standard protocol such as Profibus or Modbus to form closed-loop combustion control with the machine control system.
For gas turbines using low-NOx combustor designs, damaging pressure pulsations can occur that will shorten the life of combustor cans if not detected and controlled. The pulsations occur because the combustion process runs as lean as possible and the flame becomes meta-stable under such conditions, creating damaging pressure pulsations when operating too close to the flame’s stability margin. On these co-called DLE (Dry Low Emissions) machines, the dynamic pressure pulsations are monitored via special filtering profiles on the signal that detect when the combustor is incurring incipient or fully manifest pulsations.
The XMC16 module in the VM600Mk2 is used to provide 16 channels of integrated combustion dynamics monitoring. An Ethernet port is provided on both the front and rear of this module for digital communications with the turbine control system using an open, industry-standard protocol such as Profibus, forming closed-loop combustion control.
When the pulsations are detected, along with numerous other parameters that allow accurate combustion control and prevention of combustor damage, a signal is sent to the turbine control system where the fuel/air ratio is modified to continue running the gas turbine as lean as possible, yet without remaining in a state where these damaging pulsations are present. Because modern turbines can have more than a dozen combustors, the link between the machine protection system (where the embedded combustion dynamics monitoring occurs) and the turbine control system is generally an open, industry-standard digital communications protocol such as Profibus rather than hardwiring a dozen or more signals to convey the presence or absence of damaging conditions in each combustor. Although redundant digital communications can be used, in practice this link has proven to be so reliable that simplex links are today used almost exclusively when the VM600 is supplied.
With the VM600Mk2, we have built on the strong foundation of our 1st generation VM600 “legacy” platform to ensure that each of the links discussed in this article are more robust and functional than ever before, yet reflecting modern cybersecurity concerns – particularly the condition monitoring interface and its segregation from machine protection. You can learn more in an extensive whitepaper we have put together for the new VM600Mk2 platform, detailing what has changed, what has stayed the same, and why it remains a world-class product for a diverse, demanding customer base spanning power generation, oil & gas, and other industries where critical and essential rotating and reciprocating machinery is found.