Liquid bulk storage terminal boosts responsiveness with
open field-based automation and FOUNDATION fieldbus
Article written by
Edward Lux, ChemPoint.com, Bellevue, Washington
Glenn Aycock and Mike Chlapowski, Vopak Terminals North America
Inc., Deer Park, Texas
 SITUATED
ON 30 ACRES fronting the Houston Ship Channel, Vopak Terminals
North America's liquid bulk storage terminal in Galena Park,
Texas, has 87 tanks with an aggregate capacity of about a
million barrels. The site was acquired in 1972 by Netherlands-based
Pakhoed, a world leader in commercial transport and storage
of chemicals and oil products. Pakhoed operated the terminal
through its Paktank subsidiary. In 1999, Pakhoed merged with
another Dutch giant in similar businesses, Van Ommeren, thus
creating Royal Vopak-the world's largest liquid bulk storage
and chemical distributing company (parent of Vopak Terminals
North America, Inc.) At Galena Park, we store a wide variety
of liquid materials for many different clients on a toll basis.
These chemicals move in and out via rail tank cars, tank trucks,
and barges and tanker ships.
Like most other facilities of this sort around the world,
the Galena Park terminal does not yet make heavy use of remote
data acquisition and control. Pumps and valves are turned
on and off mostly by hand. Levels, flow rates, temperatures,
and pressures are typically read by eye and keyed into computer
terminals connected to an HP-3000 mainframe at Vopak's headquarters
in Houston. Terminal management software in that computer
serves all 13 of Vopak Terminals North America's facilities,
keeping track of customers' materials, issuing invoices, etc.
By a feature called "Plug in to Vopak," customers
log onto the Vopak mainframe via dial-up modem to read inventory
levels, utility usage, and other information about their accounts
for efficient demand supply planning and management.
At the beginning of 1999, an opportunity appeared for beginning
a terminal-wide data acquisition and control system on a piecewise,
bootstrap basis. We would be storing two related petrochemical
products in 30,000-barrel API-650 tanks for a major customer.
In addition, this customer wanted us to remove traces of certain
impurities. The alternative was to barge the material to and
from a toll processing plant somewhere along the ship channel
at a rate of about 3,000 barrels per day. By installing a
treater unit on-site, we could save a great deal of money
for the customer and earn a little more ourselves.
The photograph in Figure 1 shows the product treater as it
was eventually built, consisting of three beds periodically
regenerated by hot nitrogen. As indicated by the simplified
piping and instrument diagram in Figure 2, this unit and its
four associated tanks would need substantially more remote
monitoring and control than traditional terminal operations.
The conventional automation method in a terminal such as
ours would involve a PLC (programmable logic controller) at
the product treater, with a computer providing a graphic user
interface (GUI) in the terminal operations control room. We
had recently installed a PLC-based control system for six
railcar loading spots. As time went on, we could use PLCs
throughout the terminal as the focal points for automation,
interconnecting all of them with a common data highway. The
result would be a conventional SCADA (supervisory control
and data acquisition) network. We would be well on our way
toward an important goal of providing customers with virtually
real-time, live data on our custody of their materials, conveniently
accessed via the Internet.
However, our experience with the railcar loading system was
not encouraging. In particular, the PLC and associated GUI
proved difficult and expensive to reprogram whenever we needed
to change procedures. Furthermore, we envisioned increasing
needs for more sophisticated process controls, on the order
of the distributed control systems (DCSs) commonly found in
refineries and chemical plants. After evaluating alternatives,
we chose instead the latest generation of process automation
architecture, called open field-based architecture. The version
of this architecture which we selected is Emerson Process Management's
PlantWeb digital plant architecture.
Open field-based automation architecture
 Open
field-based architecture is the successor to SCADA and DCS.
In both of the older concepts, programmable "intelligence"
is located mainly in computer-based units called PLCs or RTUs
(in the case of SCADA) or controllers (in the case of DCS).
These units exchange discrete (on-off) and analog (typically
4-to-20-milliamp) signals with field devices-level transmitters,
automated valves, limit switches, motor starters, etc. The
PLCs, RTUs, or controllers communicate with each other and
with operator stations via networks called data highways-or
in many cases by radio. A field-based architecture, by contrast,
pushes as much of the intelligence as possible out to the
field devices. That is, it makes the most of the newer "smart"
field instruments (Figure 3) which contain computer circuitry
and communicate as one computer to another.
"Open" means that the architecture uses operating
systems and communication methods which are standard rather
than proprietary, so that software and equipment from many
different manufacturers can readily be applied together. The
open standards employed by PlantWeb architecture include PCs
running Microsoft Windows NT; LANs (local area networks) using
Ethernet with TCP/IP Internet protocol; and field device communication
via HART or FOUNDATION fieldbus as well as traditional 4-to-20-milliamp
signals.
HART (Highway Addressable Remote Transducer) is a standard
system for superimposing 1.2-kilobaud digital serial data
transparently on the 4-to-20-milliamp signal of an analog
line connected to a transmitter, digital valve controller
(DVC), or other smart field instrument. A fieldbus, in turn,
is a multidrop data link for such instruments. The most widely
accepted standard variety is FOUNDATION fieldbus H1, which
carries all-digital data serially at 31.25 kilobaud on ordinary
twisted pairs as long as 1,900 meters (6,200 feet). One segment
can serve as many as 16 instruments. One party on each FOUNDATION
fieldbus segment-often a controller communicating with other
parts of the plant network-acts as a traffic director called
the Link Active Scheduler. The bus also provides power to
all the field devices, which are typically designed to draw
no more than about 20 mA apiece at a nominal 20 volts.
Open field-based architecture unleashes the computer power
in a plant's smart instruments and enables them to function
together as a communicating network. Thus the instruments
can optionally take over many of the tasks formerly done by
PLCs, RTUs, and DCS controllers, such as continuous control
(PID) algorithms. More importantly, entirely new possibilities
are opened up for improving a plant's performance, reliability,
economy, and responsiveness to customer requirements. For
example, pressure or temperature transmitters can perform
self-calibration and self-diagnosis to promote high accuracy
and dependability. Software running in the Windows environment
facilitates setting up and changing configuration and programming
by highly automated plug-and-play and drag-and-drop procedures.
Real-time operational data such as tank levels and utility
usage rates can be passed to management computer systems as
easily and transparently as information is shared among Windows
applications.
Initial application in a product treater unit
 As
shown in Figure 4, this instance of Emerson's PlantWeb
field-based architecture includes a DeltaV digital automation
system. The system's controller and I/O modules for the treater
unit area (Figure 5) are located in an electrical substation
a few hundred feet away from the treater. The system includes
a PC-based DeltaV operator station running standard Windows
NT (Figure 6), connected via an optical fiber Ethernet LAN.
The DeltaV system is scalable, in that hardware and software
can readily be expanded to any size to meet changing needs.
Software is modular and is efficiently integrated among controllers
and field instruments through communication over the field
network. A particularly important software module in this
installation is Asset Management Solutions (AMS) for advanced
instrument configuration, calibration, diagnostics, and preventive
maintenance.
 As
many of the field instruments as possible are intelligent
ones using H1 FOUNDATION fieldbus. More particularly, temperatures
are measured by Rosemount Model 3244MV multivariable transmitters,
each handling two RTD elements. Rosemount Model 3051 differential
pressure transmitters are used for gage pressure and Model
8800C vortex transmitters for nitrogen flow. The intelligent
DVC (digital valve controller) on the control valve at the
knockout tank is a Fisher Controls DVC5000 FIELDVUE® unit.
There are two fieldbus segments, both served by one I/O module.
The only 4-to-20-milliamp analog signals are inputs from the
four analyzers and the knockout tank level transmitter. The
particular instruments desired for those purposes do not have
computer intelligence.
At the time the Micro Motion Model 5300 Coriolis mass flow
and density transmitter was acquired, fieldbus communication
was not yet available, so its intelligent functionality is
accessed instead by a serial data link using MODBUS protocol.
The DeltaV control and I/O subsystem includes two I/O cards
for serial data, each accommodating two channels. The radar
level gages and related temperature transmitters on all four
tanks communicate on a multidrop serial data link, being polled
by a field communication unit (FCU) provided by the same manufacturer.
The FCU, in turn, communicates with the DeltaV controller
by MODBUS protocol on one of the serial data channels. Another
of those channels is used by the power meter, which also employs
MODBUS protocol. Discrete signals consist of three 110-volt
ac inputs from the rupture disks, over-temperature shutdown
alarms from the heater control panel, and a 24-volt dc permissive
output to the product pump control panel.
Software in the DeltaV system and intelligent instruments
can readily be configured for any sort of automatic control
that might be required in a bulk terminal, including complex
sequencing as well as advanced continuous control strategies.
In this particular application, however, there was no immediate
requirement for total automation and remote control of all
pumps and valves. Sequencing of bed regeneration is handled
by a controller which came packaged with the heater control
panel. The only continuous control loop performed in the DeltaV
system is the one which throttles the knockout tank inlet
valve to keep liquid out of the flare line.
The system's main function is to gather data and store it
in a data base which is accessible to the legacy computer
system. For this purpose, the operator station has a second
Ethernet port connected to the plant LAN. A particularly convenient
open method of communication would be OPC, which stands for
OLE (object linking and embedding) for process control. Until
such time as the legacy system acquires OPC capability, data
are passed by an equally simple and open method based on Windows:
flat files generated by Excel spreadsheets which are automatically
linked to the DeltaV data base.
Early payoffs from the field-based network
Approval for building the treater unit was secured in the
middle of March, and the unit had to be operational at the
first of June to meet our customer's requirements. The design
was a close copy of an existing unit owned by the customer,
and the equipment was readily available. It would be possible
to meet the schedule if we employed the usual local instruments
and manual control. However, a PLC-based SCADA system or DCS
would have been out of the question on account of the time
required for wiring, programming, and training of operators
and technicians. Emerson and its local representative
company, Puffer-Sweiven, were very helpful in our decision
to use open field-based architecture and then in making sure
that we received the hardware, software, and technical assistance
in timely fashion. All engineering, construction, and startup
work was bid out directly to independent contractors.
One key to meeting the tight schedule was that FOUNDATION
fieldbus eliminates the need for a separate cable run to every
instrument. In this case, 15 fieldbus instruments are served
by just two twisted pairs connected to the DeltaV unit. Only
one cable had to be run to the operations building: the optical
fiber Ethernet connection.
 The
speed and ease with which the fieldbus instruments were commissioned
was truly spectacular. In about 20 minutes at the operator
station, an Emerson engineer walked our chief operator
through the plug-and-play procedure with one transmitter,
while a contractor technician with a radio stood by in the
field. For most of that time, the operator (one of the authors,
an instrument technician) was simply investigating self-explanatory
alternatives in the familiar Windows environment. As soon
as an instrument is connected to the fieldbus, it powers up
and begins autonomous conversation with the DeltaV system.
An icon which fully identifies the instrument against a list
in the operator's hand pops up on a display resembling Windows
Explorer (Figure 7). Immediately, the operator is prompted
to incorporate the instrument into the predesigned data acquisition
and control scheme by simple drag-and-drop procedures. Initial
self-calibration takes just a few seconds. Time-consuming
loop checkouts become a thing of the past. Our operator commissioned
the second transmitter unassisted in ten more minutes. Then
he told the field technician to connect all the other transmitters
as quickly as possible. Within the next 30 minutes, accurate
data was being logged from all of them.
 Configuration
of the graphic user interface was likewise quick and easy.
The same chief operator created the displays, using intuitive
software tools (Figure 8). More importantly, any aspect of
the entire data acquisition and control system can be changed
just as easily, without the need for specially trained engineers
and programmers.
We found it highly valuable that the DeltaV system allows
us to include nearly any kind of field instrument in the same
network in an economical and transparent manner. Smart instruments
using FOUNDATION fieldbus provide the full benefits of open
field-based architecture. However, conventional analog signals
and serial data such as MODBUS are accommodated just as gracefully
by means of appropriate I/O modules. Thus we can freely use
existing conventional instruments as well as new ones for
which intelligent functionality is not yet available.
Periodic self-diagnosis and self-calibration by intelligent
transmitters not only eases the maintenance burden considerably,
but also makes instrument readings much more accurate and
trustworthy. We are able to present customers with data items
which are accompanied by a number indicating the degree of
confidence in the validity of each item.
Needless to say, the treater unit instrumentation performs
as expected. When the customer makes an on-line request for
the latest figures on its inventory and utility usage at this
terminal area, what is received is no longer based on hand
measurements made at the end of last month, or even yesterday.
Instead, the data came from electronic instruments just a
few minutes ago.
Immediate expansion to other terminal areas
Shortly after the decision was made to use open field-based
automation for the treater unit, plans for the network were
expanded to include three other terminal areas as shown in
Figure 9. As in the case of the treater unit, the DeltaV controllers
are mounted in electrical substation buildings near those
areas. The four controllers could be linked by one Ethernet
segment in multidrop fashion. However, in this case, the optimum
network topology is a star. Each controller has its own segment
radiating from a common hub.
One of the controllers primarily handles instruments related
to a storage tank which is maintained at a moderately elevated
temperature by hot water circulating in panel coils built
into the tank wall. Two other tanks in that vicinity were
also incorporated into the network. There is one FOUNDATION
fieldbus segment, which is connected to pressure and flow
transmitters and a DVC (digital valve controller). The only
analog signals are inputs from two analyzers at another storage
tank and an output to a variable-frequency drive for a product
pump. That pump not only recycles product for agitation in
the tank, but also supplies product at constant pressure to
several loading stations. Proprietary control panels at two
of those stations are incorporated into the network, each
through discrete inputs and outputs at a DeltaV controller.
One station loads trucks by weight, and the other loads railcars
by mass flowmetering.
The cost for the instrumentation network at the four-server
stage shown in Figure 9 was amazingly low-on the order of
$100,000. This amount included the DeltaV hardware and software
and related services; all the Fisher, Rosemount, and Micro-Motion
transmitters and DVCs; and related engineering and installation
contracts. Based on our earlier experience, doing the same
job with PLC-based automation could easily have cost three
or four times as much.
As opportunities appear, various other items of terminal
instrumentation are being added to the network, mostly using
generous spare I/O capacity provided in the original DeltaV
installation. For instance, turbine meters with mechanical
counters are being replaced by vortex meters on FOUNDATION
fieldbus. However, at one location (Substation A in Figure
9), the most convenient communication method for two intelligent
flowmeters turned out to be HART rather than FOUNDATION fieldbus.
In time, there will be other DeltaV controllers and other
operator stations. Besides getting real-time data which is
extremely valuable for terminal operation and on-line customer
inquiries as well as eventually detecting false alignment
of product transfer valving, we are opening up new horizons
for automatic remote control of operations which were formerly
limited to manual methods.
 As
of this writing in April, 2000, our latest innovation for
terminal automation is an NT Internet server on the plant's
main Ethernet LAN to which the DeltaV operator station is
connected (Figure 10). Located in the terminal office building,
this computer provides access to the corporation's new Internet-based
virtual private network via a high-speed router operating
at 1.54 megabits per second. Real-time customer data passed
up from the DeltaV servers updates files in the main Houston
office every five minutes. Customers will soon be accessing
their account data through a Vopak Web site, using appropriate
privacy features such as passwords.
Thus, open field-based automation at this bulk terminal is
advancing Vopak Terminals North American's plans for eventual
business-to-business integration of supply-chain management
via the Internet. We are installing the same technology at
the company's other terminals. Moreover, we expect that this
automation will interface very efficiently with the J. D.
Edwards ERP (enterprise resource planning) system which is
being globally implemented by Royal Vopak.
back to top
|
