What You Should Know About Foundation Fieldbus
Introduction
Foundation Fieldbus has become a
popular choice in the implementation of new (greenfield) process control
systems in the past 17 years since its creation at the end of the last century.
However, these new installations have rarely used the H2 network defined in the
international Fieldbus standard, Foundation Fieldbus HSE which is needed to
compete the full Foundation Fieldbus architecture. HSE has not been used mostly
because their DCS (Distributed Control Systems) supplier has not offered or
integrated HSE into their product line. Users usually encounter bids for new
control systems from their traditional suppliers that revert to control systems
using the older, more traditional instruments (4-20 mA with HART) rather than Foundation
Fieldbus. In most cases, the system is constructed with Foundation Fieldbus
instruments in which each H1 segment terminated in an H1 I/O card much like
older analog and HART instruments were terminated in an analog input card. Users
seeking to revamp or modernize older control systems (brownfield) cannot
justify the replacement of existing and working field instruments, therefore their
control systems are “modernized” with a new DCS that does not use Foundation
Fieldbus.
Foundation Fieldbus was created for
process control system users to lower the cost of new control systems. At the
time (late 1980’s) we (the ISA SP50 standards committee) just ignored the brownfield
problems, which at the time were only 4-20 mA analog. Now some 25 years later,
the brownfield problem has become real with millions of HART instruments
installed, but there is still no practical solution that enables a Foundation
Fieldbus solution without replacement of working field instrumentation with
Foundation Fieldbus instruments. Furthermore, since Foundation Fieldbus has
been used only in greenfield plants, many users at older plants remain
unfamiliar with it.
Now, several end user companies are
facing the modernization of many DCSs with conventional (HART) field
instruments in good working order, but are unwilling to once again install a
new DCS with a closed/proprietary I/O (Input/Output) architecture. There is no
commercial method or product that allows them to install a new control system
with an open I/O architecture (based on an international standard. This situation
has led them to consider the standards involved with Foundation Fieldbus and
other IEC (International Electrotechnical Committee – a UN electrical standards
body) standards currently not fully supported by their traditional DCS
suppliers.
This paper is written as a tutorial
for end users unfamiliar with Foundation Fieldbus, to explain why there has
been so little use of this technology, and to introduce the technologies that
need to be developed to adapt Foundation Fieldbus to viable/economic brownfield
modernizations. This is not a tutorial for the product design of a process
control system, but is highly technical in terms that should be familiar to process
control end users.
Architecture
Foundation Fieldbus is a process
control system architecture specification that includes two different
communication network protocols, an extensive set of process control algorithms
intended for operation in either field instrumentation or host systems (DCS controllers),
and a complete set of validation testing methods and software. All of this was
created by the sponsoring organization the Fieldbus Foundation, now a part of
the FieldComm Group based upon the work of the ISA S50 standards committee.
Process control suppliers may be members of the FieldComm Group or not, but they
must obtain their specifications in order to build and test products made to
meet these specifications. Additionally, the FieldComm Group lists the
commercial products that have successfully completed the prescribed tests and
are then “Registered” by the Fieldbus Foundation.
Communications networks for
Foundation Fieldbus are functionally divided into H1 for peer-to-peer interconnecting
intelligent field instruments on the same network segment, and HSE for
interconnecting H1 segments to each other and also to the DCS controllers and
HMIs (Human Machine Interfaces/Operator Consoles.) A gateway, called a Linking
Device, interconnects H1 and HSE. The H1 network is specifically designed for
the process industries field environment including intrinsic safety, and it is
capable of supplying DC power to field instruments. HSE uses any commercial off-the-shelf
(COTS) Ethernet metallic wiring or fiber optics to make its connections at high
speed and low cost. Wired Ethernet may supply power to Linking Devices using
existing IEEE 802.3af or 802.3at PoE (Power on Ethernet) standards. Power may
also be delivered by copper wires embedded in commercial fiber optic cables.
The architecture of Foundation
Fieldbus systems enables the functionality of “smart field instrumentation,” to
implement the first Industrial Internet of Things (IIoT) for Process Control
systems. Foundation Fieldbus systems may use the intelligence of smart
instruments to run some, most, or all of the computationally intensive signal
processing and closed loop control functions formerly run only in computer
control or DCS. This is known as CiF, or Control in the Field. The process
control functionality of Foundation Fieldbus is assigned to “Function Blocks”
that are the basic object-oriented set of computational applications with algorithms
detailed by the Fieldbus Foundation specifications. In fact, the function
blocks of Foundation Fieldbus systems may be freely located or relocated to
either an appropriate field instrument or to a host DCS multifunction
controller. This may be used to offload function blocks from DCS multifunction
controllers to field instruments in order to free the controllers to run
computationally intensive software such as Dynamic Matrix Control, Model
Predictive Control, or other advanced control or optimization programs.
Foundation Fieldbus explicitly allows function blocks operating in field
devices to be in full cascade linkage with function blocks operating in other
field instruments or in conforming DCS multifunction controllers.
Why is Foundation Fieldbus Useful?
In the beginning, we (the ISA 50
standards committee) had hoped that the standard on which Foundation Fieldbus
was based, would reduce the cost of the wiring used to connect field
instruments to host controllers. Wire reduction is possible since many (between
4 and 16) H1 instruments can share a single connection to either a host DCS H1
interface card or a single port on an HSE Linking Device. While there is some
wiring and engineering savings with respect to traditional analog wiring, it
has actually proven to be insignificant, and is not a sufficient reason to
install Foundation Fieldbus systems. The ability to run about 80-85% of control
loops in the field instruments (CiF) means that fewer DCS multifunction
controllers are required for a functioning control system, and often those
controllers do not need to be redundant since the critical control loops are
distributed to the field instruments. This allows a very significant cost
reduction for the initial purchase of the control system. In their defense
against potential loss of controllers, the suppliers of Foundation Fieldbus
systems advise users to provide controller capacity to run all control loops in
redundant controllers in order to negate the urge to reduce the number of
controllers. Similarly, using CiF instruments makes the control system
independent of the DCS or PLC supplier, another issue that the control system
supplier would prefer that the user did not know.
A little more complex issue concerns
the way that Foundation Fieldbus handles communications between H1 segments.
First we need to discuss the architecture of Foundation Fieldbus. When the IEC
61158/ISA50.02 standards were approved, the architecture was designed for a
two-level network structure:
- Field segments – a group of devices/instruments physically
located in close proximity that may interact with each other. Commonly this
network level is referred to as H1.
- Backbone or homerun network – a network intended to aggregate all
H1 field segments for communications among the field devices and also to connect
a host system. Formerly this network level is referred to as H2, but now is
referred to as HSE.
The H1 network technology was
specified to support both intrinsic safety and to provide power to the field
devices, much as the older ISA S50.1 (4-20mA DC) analog standard had done.
These power limitation requirements naturally limit the number of devices
connected to an H1 network to between 4 and 16 instruments, fewer than the 255
devices enabled by the addressing in H1 protocol. The number of instruments
that may be connected to a single H1 segment is dependent on the total power
consumed and the need to support intrinsic safety. H1 segments may be connected
to a host system directly using an H1 interface card that typically provides
terminations for 2 or 4 segments. H1 was originally intended to be connected to
a host system through a network switch (or Gateway) and a higher level network
such as Foundation Fieldbus HSE, however HSE has not been widely implemented by
the DCS vendors, which would require that they be able to communicate I/O data
through an Ethernet interface using the HSE protocol. Actually, most DCS
vendors do communicate with their own proprietary I/O equipment using high
speed Ethernet, but with their own proprietary protocol. As a result, most H1
field networks are terminated in H1 interface cards; part of the control
systems proprietary I/O infrastructure. When HSE and Linking Devices are configured
into the control system, there is no need for the traditional DCS or PLC I/O
interface since all field data is exchanged with the controllers through
Ethernet ports. The Linking Device becomes a distributed I/O infrastructure.
Elimination of the entire wire-spreading/termination facility and all of the
traditional I/O interface cards is a very large cost savings. Note that HSE is
required to achieve this savings.
Foundation Fieldbus HSE is
standardized within the Type 1 grouping of IEC61158 and is specified to use unmodified
high speed Ethernet for the Physical and MAC (Medium Access Control part of the
Data Link Layer) and UDP/IP at the Transport and Network Layers. The
Application Layer of HSE is identical with ISA50.02 and IEC61158-Type 1, which
means that Fieldbus instrument data, including function blocks, appears the
same to a DCS that is HSE enabled, as it would appear to the same DCS with
field instruments connected via an H1 interface.
The fundamental element of process
control is the closed loop, which requires a process variable, a controller,
and an actuator. A closed loop has a setpoint or target value of the process
variable, and the controller is tuned to manipulate the actuator to hold the
value of the process variable constant at the setpoint. In many processes, it
is necessary to link a control loop for a high speed independent variable to a control
loop for a slow speed process variable to remove the undesirable effects of
high speed variations from the primary slow speed control loop; this is called
cascade control. Very often, the elements of the high speed control loop and the
slow speed control loop are not physically close together, such that they
cannot be connected on the same H1 network segment. When the two network
segments of this example are terminated on H1 interface cards, there is no way
to form the desired cascade linkage using CiF. Instead, at least one of the two
control loops must be located in the process controller of the DCS, typically
the slow speed control loop. However, when the two H1 segments are terminated
on the HSE network using Linking Devices, this restriction is removed. There
are no restrictions on the linkages for cascade control when using an HSE
network, and both control loops may be located in different field devices using
CiF. Publish/subscribe messaging is used to synchronize data for all control
loops, even those that span across the HSE network.
When control loops are closed either
on a single H1 segment, or across H1 segments using HSE, users have reported a
significant improvement over control in controllers located in a DCS or any
other type of control system. The improvement seems to be related to reduction
in deadtime allowed by the direct peer-to-peer access of CiF. A secondary
benefit of CiF is to make those control loops independent of the control
system, which is of primary interest to users who realize the control systems must
be updated much more often than instrumentation systems. Finally, CiF offers a
path to incrementally update obsolete control systems one loop at a time,
benefiting users seeking to minimize disruption of their production processes
during control system modernization.
Finally, when HSE is used, the HMI no
longer needs to depend upon the DCS controller to gather data for the real-time
displays of the HMI. The HMI may use the same Foundation Fieldbus publish/subscribe
protocol that is used in the H1 protocol allowing the HMI to obtain real time
data directly from the field instrumentation. This eliminates the need for the DCS
vendor to supply data to the HMI on their proprietary network. While the DCS
vendors all offer full-function HMI packages tuned to their proprietary
network, the nature of that HMI package is typically one of the features to
keep the user from considering the use of a competitive DCS, or an independent
HMI package. If HSE were to become more common in the architecture of DCSs,
then independent HMI suppliers would be better able to bring their technology
to the users. In today’s DCS market, the DCS, proprietary network, and HMI are
an integrated package, and the user cannot easily integrate HMI from an
independent supplier.
DCS suppliers have recognized that using
Foundation Fieldbus HSE provides an open architecture eliminating the I/O
infrastructure, and making the HMI and controllers open to competition. Their
major position has been to provide a fully integrated but closed control
system. Necessarily they have resisted the implementation of HSE.
Function Block Control
This section describes the functions
of each of the 22 approved Foundation Fieldbus function blocks. Note that
suppliers may offer variations of these “standard function blocks,” which may
offer a different mathematical solution (algorithm.)
Foundation Fieldbus defines ten (10)
function blocks, listed in Table 1, that are required for all conforming
devices. The Fieldbus Foundation specifications include standard function
blocks that reflect the types of computations and controls expected of field
instruments as part of Control in the Field.
Table 1 – Foundation Fieldbus Required Function Blocks
|
Symbol
|
Function Block Name
|
|
AI
|
Analog Input
|
|
AO
|
Analog Output
|
|
BG
|
Bias/Gain
|
|
CS
|
Control Selector
|
|
DI
|
Discrete Input
|
|
DO
|
Discrete Output
|
|
ML
|
Manual Loader
|
|
PD
|
Proportional/Derivative
|
|
PID
|
Proportional/Integral/Derivative
|
|
RA
|
Ratio
|
The I/O blocks all have an element
called the transducer that performs the necessary computations to convert
between the digital values of the sensor and the binary values used by the
applicable function block. Each of the I/O blocks (AI, AO, DI, and DO) contains
a transducer element.
Analog Input - The
basic functionality of measurement and signal processing is provided. The “raw
value” from the transducer element is converted to engineering units, smoothed,
and checked for alerts. The result becomes a scalar value that is the primary
value (PV) of the block. The quality of this value is indicated in the status
variable that may be GOOD, UNCERTAIN, or BAD. It also provides the set of alerts:
Hi-Hi, Hi, Lo, and Lo-Lo.
Analog Output - The
output value from a control block is converted to the form required for the
output transducer element, usually a scalar number normalized (between zero and
one) as a fraction of full scale. The AO block also determines the status of
the output hardware, typically from the output transducer element, and
sometimes from external limit switches. For example, when a control valve is
fully open or fully closed, this condition may be sensed with limit switches
attached to the valve mechanism. The AO block reports this condition in its
status as BAD or UNCERTAIN, since the cascaded upstream PID control block will
begin to wind-up when this occurs and may need to take anti-windup action.
Bias/Gain - The
input value is summed with the BIAS value that is a block tuning value. This is
sometimes used in some feedforward control schemes, and also used with the PD
controller that lacks the ability to correct offset error. For other applications,
a scaling multiplier value is also provided.
Control Selector - One
of two different controller outputs is selected for actual output. This is can
be used for override control. This is useful when two or more alternative
controllers are configured such as in boiler control when the air damper
position may be controlled to regulate excess oxygen or carbon monoxide content
of the flue gas. The non-selected controllers will wind-up if the control
selector is not used. One output of the Control Selector feeds the actual
output back to the unselected controller with the BAD status set causing that
controller to initialize, or change to Local Override mode.
Discrete Input - This
block accepts a single discrete input from the local Transducer element. The
only conversion option is to invert the state, if required. As with other input
blocks, the state is tested for alert status. The purpose of this block is to
allow the DI to be named.
Discrete Output - This
block sends its single discrete input to the local Transducer element. The only
conversion is an option to invert the output state. The desired output state is
the setpoint value. There are provisions for reading back the actual state of
the output and alert if the desired state has not been achieved.
Manual Loader - This
block provides for an operator input into the control block flow using the
setpoint of this block. The output takes on the setpoint value when the block
is in operation.
Proportional/Derivative
- This is a form of the PID block in which the entire Integral term has been
disabled. In this form, there is no reset windup because the entire integral
term has been removed. There is also no remote reset capability. Some control
loops seem to perform better with the PD algorithm. Since there is no Integral
term, this controller does not correct for offset error when the proportional
constant is other than 1.
Proportional/Integral/Derivative - This block is a PID control algorithm in a form that emulates a
pneumatic controller. The proportional constant interacts with both the
integral and derivative tuning constants in order to conform to the tuning
rules of analog controllers using the Ziegler-Nichols method. Many suppliers
have implemented some form of auto-tuning in this algorithm, although the
standard does not require auto-tuning. Use of this block in control loops with
a Control Selector block requires configuration using the external reset option
in which the actual selected loop output is fed back to the block allowing it
to initialize the reset remainder term to prevent integral/reset windup. Most
suppliers offer the option to decouple the derivative term from any setpoint
change to prevent bumping the process when the setpoint changes. Bumpless
transfer from MAN to AUTO or CAS mode is usually specified by initializing the
setpoint to prevent any change in block output, or by holding the setpoint
value and zeroing the reset remainder to prevent sudden output changes as the
block moves the process to the setpoint using only the reset term.
Ratio - The
ratio block is a multiplier. The setpoint of the ratio block is multiplied by
the input value to generate an output. This is useful in control of several
flows being blended or charged to a reactor. One flow rate is considered the
master flow, and the other flows can be controlled in proportion to the master
flow using a ratio block.
Additionally, there are twelve (12) extended
function blocks, listed in Table 2, that are considered optional, but are
usually offered on appropriate devices. These are often necessary to construct
control cascades or feedforward controls.
Table 2 – Foundation Fieldbus Extended Function Blocks
|
Symbol
|
Function Block Name
|
|
DC
|
Device Control
|
|
OS
|
Output Splitter
|
|
SC
|
Signal Characterizer
|
|
LL
|
Lead-Lag
|
|
DT
|
Deadtime
|
|
IT
|
Integrator (Totalizer)
|
|
SPG
|
Setpoint Ramp Generator
|
|
IS
|
Input Selector
|
|
AR
|
Arithmetic
|
|
TMR
|
Timer
|
|
AAL
|
Analog Alarm
|
|
FFB
|
Flexible Function Block
|
Device Control - This
block has both digital input and output functions with the ability to construct
interlocks for the control of motors, pumps, solenoid valves, and motor
operated valves.
Output Splitter - The
splitter block takes a single scalar input and sends it to two different
outputs after scaling. The most frequent use of the splitter is for split-range
control such as when a single PID controller is used for temperature control of
both heating and cooling. The splitter arranges for the cooling medium flow to
be modulated when the temperature is above the setpoint, and for heating medium
to be modulated when the temperature is below the setpoint. The splitter
algorithm can be arranged to provide a deadband where neither heating nor
cooling is required.
Signal Characterizer
- This block converts an input value to an output value using an X-Y “curve”
composed of straight line segments between a number of specified points. The
curve may be highly non-linear.
Lead-Lag - The
Lead-Lag block provides the exponential time-dependent functions that are used
in the building of model reference or feedforward controls. A complex
first-order dynamic process model can be constructed using both Lead-Lag and
Dead Time function blocks.
Dead Time - The
Dead Time block provides the pure time lag used in the building of model
reference or feedforward controls.
Integrator (Totalizer) -
The input value is summed with a total each scan cycle and compared with a
setpoint value. When the sum matches or exceeds the setpoint, a discrete output
changes state.
Setpoint Ramp Generator
- The setpoint of a control block is changed over time according to a curve
specified by several values of the setpoint over a time period. This is useful
in batch processing.
Input Selector - This
block selects one of up to four scalar input signals based on a configured
criterion. Each input consists of a primary value and its status. The algorithm
of the Input Selector evaluates which inputs have “Good” status. The criterion
is to select the first Good input, the highest Good input, the lowest Good
input, the middle value Good input, or the numeric average of all Good inputs.
Arithmetic - Often
a fixed set of calculations is required, such as for pressure and/or
temperature compensation for gas flow or polynomials. This algorithm may also
include the ability to use a form of programming to solve an equation.
Timer - The
Timer Block inserts a pure time delay for discrete functions. The time delay
may be used for the ON/OFF transition, the OFF/ON transition, both transitions,
or it may be used to time the duration of the state change to create a variable
width pulse.
Analog Alert - This
block creates the set of alerts (Hi-Hi, Hi, Lo, Lo-Lo) for a scalar signal.
These alerts are also included in the Analog Input and PID function blocks. Note:
the term alert is used to indicate an exception event. The term alarm
is reserved to be used as an HMI function that may use alert conditions to
become priority alarms.
Flexible Function Block - Programmable discrete logical control is supported through the
use of IEC 61131-3 programming languages, such as ladder diagrams, function
block diagrams, structured text, or instruction list.
Linking Of Function Blocks
All function blocks may be described
as “objects” containing both methods (algorithms) and attributes
that are named values used in the computational methods. When the attributes
are made visible to external access, they provide ways to change or affect the
function block dynamic computation and/or behavior. Other attributes may be hidden from external
view and are either constants or may be calculation results. One of the most
powerful properties of Foundation Fieldbus is the capability to link output
attributes of one function block to an input attribute of another function
block. The two function blocks may be in the same network node (instrument) or
not, as long as the two function blocks can communicate with each other across
the Fieldbus network. Extensive calculations and even time-dependent complex
functions can be made by linking function blocks in this way. This method can
be used to build cascade control loops by linking the output of a primary
(upstream) control block to the setpoint of a secondary (downstream) control
block.
Function block linking has been a
feature of process control systems for many years. Foundation Fieldbus enables
this type of control configuration for operation in field instruments. In fact,
it is possible for the host control system (DCS) to implement identical control
blocks and for these linkages to occur between function blocks implemented in
both field devices and in the host DCS. Any combination is possible independent
of function block location. The only observable limitation related to control block
location relates to the time necessary to communicate data from the output
attribute to the next block’s input attribute. The configured structure of
linked function blocks is called strategy. Control systems have
strategy builder software that is usually graphical in nature allowing function
blocks to be selected from a menu, and then to construct linkages by clicking
and dragging arrows on a screen. When the linkage is specifically to route the
output of one control function block to the setpoint of a downstream control
block, the strategy is called cascade control. Construction of
strategies is identical for both the DCS and for function blocks resident in
field instrumentation.
It is not enough to say that a
function block is ON or OFF in deciding how it is to control a process. Rather
Foundation Fieldbus function blocks have a set of defined states which define
it behavior in terms of:
- Where does the setpoint come from?
- Is the block computing its own output?
- Where does the measurement or process variable come from?
- Is the output actually connected to the actuator or next block
in a cascade?
The set of states describing these
situations is call the MODE of the
function block. Table 3 defines the only acceptable function block modes.
Following Table 3, is a brief discussion of the meaning of each of the modes.
Table 3 – Foundation Fieldbus Function Block MODEs
Mode
|
Description
|
Meaning
|
Source of Setpoint
|
State of Computation
|
|
OOS
|
Out Of Service
|
Function block has not been
activated
|
-----
|
OFF
|
|
IMAN
|
Initialization Manual
|
Function block has been
initialized and is in MAN
|
-----
|
OFF
|
|
LO
|
Local Override
|
Function block is not in control
of the device. A local function is operating or positioning the output
|
-----
|
OFF
|
|
MAN
|
Manual
|
Function block output is under
control of the process operator
|
-----
|
OFF
|
|
AUTO
|
Automatic
|
Function block is controlling,
setpoint is under control of process operator
|
Operator
|
ON
|
|
CAS
|
Cascade
|
Function block is controlling,
setpoint is being set by another block output
|
Upstream block output
|
ON
|
|
RCAS
|
Remote Cascade
|
Function block is controlling,
setpoint is under control of a host controller
|
Host system
|
ON
|
|
ROUT
|
Remote Output
|
Function block output is being set
by a host controller
|
Tracking the block Input
|
OFF
|
It is important to understand the
common control architectures supported by FOUNDATION™ Fieldbus.
- all function blocks conform to the FOUNDATION™ Fieldbus
specifications and all cascades are between these blocks
- a higher level controller, such as a DCS, that does not
participate in the fieldbus information flow, but requires access to
certain attributes of control function blocks
The RCAS mode allows cascade control to begin in a DCS to directly
adjust the setpoint of a Fieldbus control function block. However, RCAS does
not necessarily use the Fieldbus information for control initialization. The ROUT mode allows the DCS to perform the
control functions and directly set the output of a control function block.
These two modes allow complete backup of the control loop in the fieldbus
function block logic that may assume control if communications to the DCS is
lost, as may be detected by a timeout of a watchdog timer associated with each
function block.
The LO mode is included to allow an operator to directly take over the
output of a field device, often with a local handheld terminal. The LO mode
indicates to the normal control data flow that such a condition exists, and
control blocks should not windup under these conditions.
MAN, AUTO, and CAS are the
normal states of control blocks as indicated in the table. These modes of
control are set by actions of the process operator, usually from the display
(HMI). Notice that they reflect the state of the control computation (ON/OFF)
and the source of the setpoint attribute.
OOS normally means that the function
block is not yet configured, or is being modified.
IMAN is a transient state in which the
function block is in MAN mode, but its output has just been initialized.
Initialization is one of the most important concepts of FOUNDATION™ Fieldbus as
it relates to the transition from completely manual control to automatic
control of a process. Process control engineers prefer that this transition to
be bumpless, that is, initialization does not cause the process to suddenly
become upset when values are changed.
Bumpless transfer implies that the
control block output does not suddenly change when the loop mode is changed
from MAN to AUTO. There are usually two choices for bumpless transfer:
a) The setpoint of the loop is adjusted to the current value of the
process variable so that the error term is zero. The effect is that the output
term is not moved by an action causing initialization, or
b) The setpoint remains set at the current value and the reset
remainder is set to zero and the derivative term is disabled. With this option,
the output term begins to change only from the effect of the reset term – a
gradual process change determined to be bumpless.
What Must Happen With Foundation Fieldbus
This is the age of the Internet of
Things, and Foundation Fieldbus must change to become a valid part of this
sweeping movement. Foundation Fieldbus has been the leader in the distribution
of intelligence to the edge of the network, but it is NOT Internet-based
protocol to the edge. When ISA S50 was creating the network technology that
became Foundation Fieldbus H1, there was no consideration of network security
on this private wired network. Likewise, when HSE was created using 100BaseTx
Ethernet and UDP over IPv6, it was considered a private network and security
was ignored. Clearly security must now be woven into both Foundation Fieldbus
H1 and HSE. Both H1 and HSE do provide limited authentication through the use
of a whitelist of the names of devices allowed to use the network. However,
there is no protocol for either privacy or data protection.
While H1 protocol is an achievement
for its long line length and its ability to reject electrical noise in a
typical plant environment, it is slow and expensive. Since HSE is already
designed, it seems that the industry would be ready to accept HSE directly to
field instruments.
This is the work of standards
committees, but is not currently on the agenda for any standards committee, nor
is such work scheduled by the FieldComm Group. Additionally, since the
instrument suppliers have not achieved financial success with the original Foundation
Fieldbus H1, there is some doubt that they would make the business decision to revise
the electrical nature of these instruments to use a direct HSE connection.
These are in most cases the same companies that already sell the DCS, and which
have been reluctant to use HSE for their I/O infrastructure because of the open
competitive nature of HSE.
In recognition of these problems and
the near and present situation of needing to update many 30-40 year old obsolete
brownfield DCSs, ExxonMobil has begun an industry effort to change the DCS market
so that their new/updated DCS will not use proprietary technology for the
network or I/O infrastructure. With the assistance of ExxonMobil, the Open
Process Automation Forum (OPAF) has been formed with a mission to develop a new
architecture and identify the existing standards necessary to implement it. When
necessary, new standards or changes to existing standards will be defined. Since
ExxonMobil and the other end user members of OPAF represent real buying power
for updating their obsolete brownfield DCSs, it seems realistic that the
results of the OPAF will be successful. Furthermore, many current users who have
recently installed new DCSs also recognize the advantages of an architectural
change that would enable them to install new systems with less dependence on the
DCS supplier for future update to those systems.
One of the compelling reasons for
the conceptual architecture that has been proposed by ExxonMobil to the OPAF is
that it allows a concept of best-in-class components to be used in the
construction of a new DCS. Components such as controllers, operator stations
(MMI), historians, and advanced control/optimization may then be incorporated
directly at layer 2 of the control system without depending upon the DCS supplier
for data access.
One of the penalties for an open
architecture is the lack of a single vendor responsibility for integration of
the entire system. For the past 40 years, DCS vendors have built their systems
around proprietary interfaces and networks and “productize” these systems to minimize
their costs of integration. ExxonMobil believes that by each component supplier
building to standardized interfaces and the use of a standardized network
supporting those interfaces, that there will be few problems of system
integration.
Currently the only standardized network
that fully supports distribution of intelligence to process control field
devices is Foundation Fieldbus H1 and HSE. While HSE is an IPv6 protocol
network, H1 is not. Therefore, H1 devices cannot fully participate in IIoT functions
such as hosting a web page, sending email, or easily providing remote management.
The Linking Device is also far more complicated and costly than an Ethernet switch.
Finally, there is very little security bound into the protocol for either the
exchange of data or for provisioning a new member unit into an operating
network. Yet standards for all of these deficiencies currently exist and can easily
be applied to an updated specification for Foundation Fieldbus – both H1 and HSE.
Furthermore, the Foundation Fieldbus ROM specification defines the functional
requirements for the DCN device identified by the ExxonMobil reference model to
provide the brownfield solution necessary to integrate the vast installed base
of HART and 4/20mA instruments already installed.
