Comment

01 April 2004

Ultimate connection

Alarm management can bridge legacy systems with current technology.

By Marc Lawson

Nearly every industrial facility, in every sector of the economy, has multiple alarm systems addressing individual process operations that are mandatory for plant efficiency, product quality, and facility safety.

Over time, users install system upon separate system, each addressing a vital aspect of operational safety, but with each independent system conversely contributing to a far larger operational and safety problem. That problem is how to respond, manage, and make singularly functional, multiple independent alarm systems with separate displays, separate distinct protocols, and, most importantly, individually distinct response and operating procedures for plant personnel. Compound-ing the technical difficulties and the operational perspective is the limited physical space within most facilities. Another layer of solution consideration is the flow of data between field instrumentation, the distributed control system (DCS), the in-plant communications, and the archiving and retrieval of information. This solution can apply to several industrial environments with similar conditions.

System dynamics

The system includes two separate identical programmable logic controller (PLC) racks operating on their own high-speed networks. An additional high-speed network provides communication between PLCs. Each rack has its own power supply, processor, communication modules, and high-density direct-current input modules. The system is capable of processing up to 2,400 alarm points. The reading and writing of configuration data is from the controlling processor.

The controlling processor updates the noncontrolling processor with the necessary configuration data, such as the local bypass, remote bypass, and type. Upon detection of a fault on the processor or any of the communication modules, the reading and writing of data switches to the backup processor rack, and the system generates an alarm. The PLCs communicate to the PLC communication driver, which resides on the alarm management server, via the PLC Ethernet network using TCP/IP protocol. The PLC also reads and writes data to the bidirectional DCS communication gateway (DCS interface hardware) via RS-485 using Modbus protocol. The PLC operates regardless of the status of the DCS. The PLC will support 1,008 input alarms and 16 diagnostic alarms for each PLC network up to five PLC networks.

The overall system is broken into four independent monitoring groups. Each group corresponds to one of the four DCS communication modules in the Honeywell TDC 3000 DCS. The monitoring groups function independently from one another, and no one failure in any given group can disrupt the operations of the remaining groups. The relative size of a monitoring group is dependent upon the makeup of its associated DCS communication module, and while the overall size of the monitoring groups may differ, they are all comprised of varying quantities of the same three building blocks called work modules. The following list represents the makeup of the two DCS gateways:

Data distribution

The human-machine interface (HMI) alarm-monitoring server application is on the Win2000 file servers and can monitor and configure the annunciator system.

Once the configuration wraps up, you save it to the off-line database. The off-line database then needs to download to the online database. Controls for downloading to the online database are on the system overview screen. The HMI alarm-monitoring server updates the PLC using the online database without any interruption to the operation of the system. All alarm events log into date-stamped text files.

The data transfer is digital (system has analog capabilities for future use). The DCS continuously monitors alarm states from PLC alarm-monitoring systems (Each data highway will also support 16 bits of diagnostic data to be read by the DCS—to be determined at SAT). The DCS will write alarm bypass instructions to the alarm-monitoring system (Each data highway will also support 8 bits of command instructions written by the DCS—to be determined at SAT) and the starting box number for each data highway in 16-bit words into the PLC alarm-monitoring systems. The alarm states are available in 16-bit words from the PLC.

The PLCs use the standard Modbus remote terminal unit protocol. Consider the bidirectional interface PLC node address to the Modbus station number and the file number to be the Modbus command number. Note that one set of command numbers are for reading data and another for writing data. The PLCs connect to the bidirectional interfaces using RS-485 serial ports with at least 9,600 baud, 19,200 baud if available. There are two separate PLC connections requiring two serial ports on the bidirectional interface. If the bidirectional interface fails to receive response from a node on one serial port, it will attempt to get the information from the same node on the other serial port. The bidirectional interface mounts in a 19-inch rack enclosure with data highway connections for the bidirectional interfaces and power supply terminals at the rear. The rack is capable of supporting up to five bidirectional interface modules in addition to the Modbus controller per DCS communication module.

Alarm acknowledgements

The field device inputs wired into the I/O panel map from the PLC network gateways into PLC buffers called virtual input tables. These virtual inputs then go within the PLC programs to perform alarm signal processing.

When the I/O communications fail and are unreadable by either PLC, the virtual inputs do not update, leaving the input status in the last state. The PLCs will pass an invalid data bit to the alarm server for each bit of invalid I/O data. The alarm server will display invalid data on the annunciator screens by placing a large "X" across the annunciator cell for each invalid point.

For an input to alarm, the bypass bits must not be in their active state and the alarm enable must be set. Under force the alarm will also engage.

DCS interface

There is one bidirectional interface between the DCS networks and the PLC systems for a given DCS communication module. The system consists of a number of DCS data highways and a varied number of gateways on each data highway. All references to data highway gateways assume a use of redundant media. There is one bidirectional interface per gateway, configurable via the DCS console. The configuration is through a 32-slot analog box on the gateway. Set the bidirectional interface configuration box address using the keyboard and video port switch in the server panel.

The scan rate parameter is available to determine how often the bidirectional interface polls the PLC node for data. The bidirectional interface supports a means of redundant PLC communication paths. There are several bidirectional interfaces for each PLC node. Bidirectional interfaces that share PLC nodes must communicate between them so that only one of the bidirectional interfaces (or an attached communication controller) connects to the PLC node.

Engineering design

The HMI alarm server application uses a redundant media Ethernet network to collect processed alarm data from the PLCs. The collected data is then made available to all client computers running the HMI alarm annunciation application over one of two Ethernet networks.

Architecture

HMI server ALARMSERV1 serves as a primary I/O server for HMI clients ALARMCLIENT1 to ALARMCLIENT6 and as a secondary server for HMI clients BRRCTLSPALM16 to BRRCTLSPALM19. HMI server ALARMSERV2 serves as a primary I/O server for HMI clients ALARMCLIENT16 to ALARMCLIENT19 and as a secondary for server for HMI clients ALARMCLIENT1 to ALARMCLIENT6.

Upon detection of failure of the primary server, the secondary server takes over and activates an alarm to notify the operator.

Hardware

The high-speed PLC gateway processor has 2 megabytes of battery-backed user memory for the PLC program. The multitasking operating system supports 32 configurable continuous or periodic tasks that can be prioritized for executing the application's program code. Symbolic addressing lets you identify data by its use in the application, independent of the hardware. Multiple processors can share common input data.

The Modbus module is a single-slot back plane compatible Modbus solution. This module provides configurable support of both Modbus master and slave implementations and communicates to the bidirectional communication gateway via an RS-485 network using Modbus protocol.

The Ethernet Module connects the PLC to the PLC Ethernet network using standard TCP/IP protocol; 10 Base-T media is used.

The computers will use Microsoft Networking as part of the ALARM work group.

Network communications

There are five separate Ethernet networks (subnets) for the whole system. The servers use NETBIOS over TCP/IP. In addition to their computer names, the HMI alarm server's application will publish the following NETBIOS names on all the connected Ethernets:

• AnnunServerA, AnnunServerB
• Server A, Server B
• ServerAAlarm, ServerBAlarm
• ServerATrend, ServerBTrend
• ServerAReport, ServerBReport

Ergonomics

The annunciator package consists of a 50-inch gas plasma display with a compact Windows NT workstation mounted to the backside. The NT workstation acts as the brain of the annunciator and drives the display via its audio and video outputs.

Each workstation is equipped with the following: two Ethernet ports, a sound card, and a solid-state hard drive. The annunciator package hangs from the ceiling over its corresponding DCS operator console.

The annunciator workstation will execute an HMI manager client that runs a common annunciator application located on the HMI alarm server over a redundant Ethernet network. The common annunciator application displays a 10 by 14 grid of alarm cells. The user configures the data displayed on the screen. The sound card plays the sound file specified for the annunciator.

If an annunciator has a backup annunciator configured and the annunciator is not communicating to the server, the backup annunciator will cycle between displaying its alarm information and that of the failed annunciator. The backup annunciator designation and cycle period is configurable for each annunciator via the HMI alarm. Each DCS console will also have a hardwired input to the alarm-monitoring system PLC. The push button connected to the input will acknowledge all the alarms on the associated console. The user can acknowledge each alarm point from the operator consoles or from the HMI alarm server application on the system overview screen, input status screen, or the associated annunciator screen.

Installation requirements

A standalone VB6 application compiles and downloads system configuration data into the off-line database locally. Saving the database during exiting synchronizes the off-line and online databases. The utility runs in a container under the HMI program, and the operator will not be given access to the operating system during use.

The database maintenance utility loads a new database to the off-line database, backing up the existing off-line database to disk automatically.

The new annunciator/alarm system should accomplish four main objectives:

• Provide a transformer-based intrinsically safe barrier between approximately 5,500 field devices and the alarm system itself
• Provide a bidirectional communications gateway between the hardwired alarm system and the customer's DCS system
• Provide a 160-window alarm annunciator capable of sending and receiving data via a high-speed industrial communications network (Ethernet) and of displaying tristate alarm conditions (yellow, red, and blue) without the use of proprietary electronics from annunciator manufacturers
• Provide a system designed to blend in to the existing monitoring architecture with as little disruption as possible, while still offering the required improvements in performance, functionality, and reliability

The alarm management system provides an architecture and methodology to log and manage large-volume alarm traffic with a legacy distributed controls system using up-to-date high-speed PLC and data monitoring technologies. ?

Behind the byline

Marc Lawson is manager of business development at Houston-based technology services provider TransAmerican Automation Inc. His e-mail is MLawson@tai-hou.com.