OIL & GAS AMR WebSphere MQSeries Business Integration

This document describes the added benefit available with the complete TCP/IP infrastructure of enabling the delivery of SCADA data from the field to the complete business infrastructure via IBM's WebSphere MQSeries message broker.

 

Poll / Response Paradigm

Typical SCADA systems since first deployed in the 70's generally have followed the same model of a poll/response network as seen in SCADA networks. This requires protocol drivers to be written and maintained on a Host to talk to the various types of field equipment in their native language to receive data. This process makes the protocol layer and transport layer one and the same disabling the SCADA system from meeting the market demand and business objectives for competition in its marketplace. 

 

Technology today requires data not only for control but also for optimum performance in relaying data to other business models such as the spot market, accounting, ERP systems and any other various applications. The topology of a poll/response network as shown in the diagram below fail to meet current objectives now placed on it. To get around this paradigm trap, companies employ a lot of time and money creating custom applications cracking the data out of Host without a common set of tools or infrastructure in place causing even more problems down the road for future equipment, technology and change.

 

 

The disadvantages of a poll/response network are:

· Poll/Response Paradigm uses %100 of available bandwidth.

· The data "Transport" is the "Application". You can't break them apart.

· One protocol for all field equipment limits deployment of new technology & impedes migration to new topologies.

· It is not a "managed" network.

· One-to-One data relationship between the Host and field equipment

 

 

Above shows a typical application in SCADA retrieving data from a Flow Computer. The process variables, meter ticket and alarm audits are and retrieved in a poll/response protocol. However, the process variables are the only requirement for the SCADA Host (Native Application) for it to control and operate the pipeline. The other applications, for Alarm Auditing and Metering, have different requirements and data formats than that of the Host. Therefore, custom polling and even different communication networks are combined with custom adapters to stuff the data into the new applications.

 

 

There is no "single" backend solution application. We need to provide a "data engine" concept that delivers data in a multitude of formats, running on a multitude of platforms. We cannot let OS or hardware platforms be a market barrier. This platform is already being used within the business integration on a large scale but and adaptation is required for SCADA data. Arcom and IBM did the adaptation in integrating SCADA data within the IBM Middleware offering called "WMQI."

 

 

Publish / Subscribe Middleware Paradigm

SCADA data should look and feel like the Internet. Common, off-the-shelf tools should enable applications to simply connect to a data stream and access desired information in real-time. Field data should be available to all business applications in common formats across TCP/IP Intranet networks or the Internet. Though this sounds like a pipe dream, the recent advances made by Arcom and IBM are making this dream come true. The model of a publish/subscribe topology is shown below:

 

 

 

A Publish and Subscribe implementation consists of three basic components, a data Publisher (producer), a data Subscriber (consumer), and a data Broker (Middleware). Data is exchanged between the publishers and the subscribers by way of the "subject" or "topic" that the data is published. The producer sends data on an event-based scheme. The event is the trigger to send data from the data producer to the broker. The event can be described as a time-of-day, scan rate, change of state on an I/O point, exceed a pre-defined deadband or any other mechanism available.

 

 

The Field Requirement

As with the Internet, routers are needed to link the different networks together. However in SCADA, not only are there different networks but also different application protocols such as MODBUS, DNP3.0, HART and many more. Therefore, SCADA requires a so-called "SCADA Router" to link different protocol and communication networks into a common platform. Arcom's Director Series Industrial Network Gateway is the "SCADA Router", it combine years of experience in protocol emulation and communications networks, so that virtually any device data can be brought into any TCP/IP communication system.

 

The SCADA router's job is to acquire the data and strip down to the individual field values and publish on the network in real-time. Existing network infrastructure and capital investment can be retained and data can be made available via new or existing TCP/IP communication systems utilizing Wireless, Frame Relay, Ethernet, CDPD, Spread Spectrum Radio or Satellite.

 

 

Director Data Aquisition

The Director Series has a software core called APEX. This APEX core is symbolized below showing the different components.

 

 

The data from the field device(s) is acquired based on a configuration file loaded into the Director into Flash memory. They include protocol type, com port, baud rate, parity, stop bits, different I/O points as defined by the individual protocol, scan rate, etc. The configuration sets up the polling for the data available in the field device. The Director pushes the poll/response paradigm out into the field and eliminates this headache and time-consuming work from the Host application. This allows a corporation to be free to pick field devices based on price vs. performance and keep capitol infrastructure and investment rather than replacing equipment that is costly and time-consuming regardless of proprietary protocols.

 

 

Data Formatting and MQIsdp

IBM and Arcom created a mechanism to deliver different data types for use in diverse business applications. The development is MQIsdp (MQSeries Integrator SCADA Device Protocol). It enables the separation of the TRANSPORT from the DATA. MQIsdp provides a transport: the means of reliably sending and receiving data between applications. It provides a data-agnostic wrapper to provide the required message management and acknowledgements to ensure the reliable delivery of the data payloads. This allows application and system designers to focus all their attention on the format of the data itself, and how to most usefully represent the field data values coming form the end devices. This may include the unification of message formats into a standardized report, which hides the differences between devices from the different manufacturers, different field devices, protocols, etc…

 

The MQIsdp is very SCADA-focussed. Knowing bandwidth is neither free nor unlimited, it minimizes the overhead and data transmission into three bytes tied to subject and payload. If the data transmission or "publish" is going over a WAN or over a satellite, it will minimize the cost and time to transmit.

 

 

The different data types and application have different requirements for Quality of Service (QOS). MQIsdp includes three types of QOS for data delivery on a "publish" to the broker.

· QOS of 0 – This represent a publish mechanism of "Fire and Forget." In SCADA, process variables will use this service. For

example, publishing the temperature or level on a 2-minute scan rate.

· QOS of 1 – This represents guaranteed delivery of receipt from the broker by receiving an "ack" and that the message could

be sent more than once. Metering applications such as ticket information or alarm audits use this service.

· QOS of 2 – This represents a publish guaranteed but sent once and only once. This is for transaction based messaging like

purchasing an airline ticket where you only want to send the message once and make sure that the broker receives it.

 

 

Publishing from the Director

Publishing via the MQIsdp requires a rules-engine located within the Director. There is an IEC-1131 logic engine that initiates the "publish" based on rules per the field site data application. The rules can be time, change of state, a deadband or any other variable to trigger the event. The logic is created from the following languages within the IEC-1131 programming suite and downloaded into flash memory of the Director.

· Sequential Function Chart (SFC)

· Function Block Diagram (FBD)

· Ladder Diagram (LD)

· Structured Text (ST)

· Instruction List (IL)

 

 

MQSeries Message Broker

The last problem is the delivery of the data in real-time to the many different present or future business applications and systems. What is required here? The answer… a so-called "Middleman", already known in the industry as "Middleware". IBM's WMQI message broker is the Middleware of choice today, having more than 75% of the market share. Some 70 of the top Fortune 100 companies currently use WMQI for business message brokering. The MQ broker acts as a translator between the many different protocols and applications supplying and receiving data. MQ receives data, re-formats it into a common structure (for example: XML, Java, C, COBOL) according to a user-defined data model, and then in near real time the data is sent automatically to any subscribers (ERP, SAP, Oracle, SQL, etc.) using appropriate client adapters.

 

 

 

Now looking at that flow computer example, the Director is polling for the data and is publishing it to the broker via MQIsdp. The Director accesses data upon an end-of-batch flag for a custody transfer, polls for Alarm Audit Archive and scans for the for the process data on a time interval. The data is published to the broker and sent to applications subscribing to all or a subset of the data in its required format. Thus, accounting or billing receives data using different application IT links without developing different communication networks and client adapters. Therefore, adding new field equipment or new applications is a simple process utilizing best-in-class software and techniques minimizing the time and costs while maximizing profit and performance.

 

 

Technical Benefits

The following is the benefits realized when implementing a TCP/IP SCADA network topology teamed together with an event driven publish/subscribe data delivery paradigm.

  • No more custom applications for business programs such as SAP to acquire data.

  • One centralized point for data

  • Protocol neutrality allowing any format of data to be sent on the network

  • Event driven data for near real-time updates

  • One-to-many topology

  • Equipment and Application neutrality

  • Lower Cost and Faster Implementation Cycles

  • Capitol Infrastructure is retained

  • Fewer communication paths and costs required

 

Financial Benefits

The following lists a few of the benefits for the in having a network topology utilizing a message broker and Publish/Subscribe data format for a near real-time data neutral broker topology.

· Higher accuracy for modeling increasing system performance versus cost

· Real-time data available for business logic and asset management

· Billing cycles increased without increased cost acquiring billing data in near real-time

· Increase Profits from Spot-Market selling from real-time data increasing business logic for accuracy and available asset

allocation

· Decrease communication costs due to event driven data

· Shorten Deployment of green field application and asset acquisition into business infrastructure

· Decrease hardware costs by competition based on price versus performance not proprietary applications

Availability of re-sale or competitive edge of having real-time data available to CRM (Customer Resource Management) systems.

 

 

This article is provided by Arcom Control Systems (www.arcomcontrols.com)

Arcom Control Systems, a Spectris company (LSE:SXS.L), is a leading supplier of embedded computer and communications technology to industry. Founded in 1982, Arcom Control Systems has developed a broad range of standard embedded hardware and software solutions for control, data acquisition, and data delivery systems. From its design centers in Kansas and Cambridge England, Arcom is also able to offer Design Services to meet the needs of high volume OEM and specialized customer requirements.