What You Should Know About Foundation Fieldbus

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:

1. 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.

2. 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.