Oil
and Gas SCADA and its Business Integration
This
article 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 says, Kurt Hochanadel.
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. Thisprocess 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 application.
 |
The
topology of a poll/response network as shown in the Fig. 1 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 the available bandwidth.
- The
data “Transport” is the “Application”. You can not break them apart.
- One
protocol for all field equipment limits deployment of new technology
and impedes migration to new topologies.
- It
is not a “managed” network.
- One-to-One
data relationship between the Host and field equipment.
The
Fig. 2 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. The OS or hardware platforms cannot be
a market barrier. This platform is already being used within the business
integration on a large scale but adaptation is required for SCADA data.
Arcom and IBM did the adaptation in integrating SCADA data within the
IBM Middleware offering called “Websphere MQ.”
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 are making this dream come true. The model of a
publish/subscribe topology is shown in Fig. 3.
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. With the SCADA Router, 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 utilising
Wireless, Frame Relay, Ethernet, CDPD, Spread Spectrum Radio or Satellite.
Router
Data Acquisition
The
router has a software core which is symbolized in Fig. 4 showing the
different components.
Each
router has protocol drivers that access data from field devices and
represents this data as field points within virtual databases located
in memory. The databases are protocol neutral and strip the data down
into fields such as UNIT16s, UNIT32s, IEEE Floating-Point and so on.
The
data from the field device(s) is acquired based on a configuration file
loaded into the router 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 router
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.
