Development of Process Control Systems

By Dick Caro

July 13, 2022

Reading the content of the article by Sandy Vasser, retired IC&E Manager at ExxonMobil in the April 2022 edition of InTech, has stirred me to reflect on how our industry has approached the development of process control systems. I have been involved in all of the approaches in the past half century of my working career. While I am now retired and unfunded to continue involvement and am sitting on the sidelines, it may be useful for me to reflect upon some of the history of how we got to where we are. I was there and either was a participant or a leader in many of those movements.

 

Sandy is correct in his description of the three paths that a well-funded manufacturing company can use to develop process control systems, except that there is a fourth path: Internal Development; and a fifth path: International Open Standards. The three paths mentioned by Sandy I would describe as three business paths to “Digitalization” of conventional and pre-existing analog process control. To the degree possible with each generation of microprocessor the early versions of the DCS (Distributed Control Systems) were digital versions of the old analog control systems with shared digital controller (at first 8 loops sharing one controller, now thousands), digital serial communications replacing hard wired signals, and shared video displays as previously implemented on Foxboro’s SPEC-200. The Fourth path, internal development was successfully carried out by Dow Chemical Company in their development of their own MOD5 control system. Dow’s internal development team assembled available hardware and put together the software to automate the startup, regulatory control, emergency shutdown, and all operator-oriented visual displays. In my own humble opinion, Dow actually achieved more than any of the commercial DCS suppliers in automation of their processes, although at great cost.

 

In early 2000, I was contracted by Invensys/Foxboro to evaluate the Dow MOD5 system for potential merger with the Foxboro I/A DCS. Dow had decided that Internal Development was too expensive to continue to make the necessary revisions they had planned, and it was time for at least one of the DCS vendors to bear those costs and to be the source of future updates, particularly to the hardware. Dow had decided to switch to Sandy Vasser’s Approach 2 – but with a burden of porting the Dow MOD5 software to a new system base. Foxboro had hired me to interview Dow control system development engineers to explain to Foxboro’s development programmers what exactly they had to support in order for Dow to begin using Foxboro’s I/A system with the Dow implementation methods.

 

The Dow process control software implementation method was based on a system of FORTRAN programs developed for each individual unit operations such as a distillation column, heat exchanger, surge tank, etc. Each program had been previously developed for Dow’s most complex unit. To implement the control for a new unit, the control engineer would download the FORTRAN source code and modify it to remove the comment markers at the beginning of the line of code that would need to become active for the new unit. Process control loops were implemented simply as Called subroutines. This was very unlike the function-block-oriented control diagrams of Foxboro’s I/A. However, I/A had been implemented using the UNIX operating system for which excellent FORTRAN compilers were widely available. I described all of this to the Foxboro software developers and they formed a team to estimate costs and scheduling to develop a proof of concept to present to Dow. My assignment was complete. By early 2001, Foxboro had failed to demonstrate a proof of concept prototype and Dow cancelled the contract and awarded it to ABB to be based on their 800xA DCS. Within a year, ABB had successfully demonstrated a proof of concept and became the sole process control system supplier to Dow Chemical worldwide.

 

Exxon Research and Engineering (ER&E), before the merger of Exxon with Mobile Oil (and years before Sandy Vasser’s time), started an Approach 2 development for its digital process control system, before there was a DCS. In 1973, while I was employed as a Software Development Manager at Foxboro, we received an inquiry from ER&E to determine if we (Foxboro) were interested in a joint venture with ER&E to develop a digital process control system. Paul Griem, another Foxboro software development manager and I traveled to ER&E in Florham Park, New Jersey. We met with Roy Zumwalt and his staff who walked us through a giant functional specification document describing the digital control system they were planning. In the 700+ pages they described a computer-based control system consisting of a central primary computer connected by communications lines to satellite computers each performing the feedback regulatory control for a specific plant area. The specification explicitly spelled out the control algorithms they required and the use of the RTL/2 programming language to be embedded into each control function block to modify the “standard” algorithms as necessary for an application. This specification linked the function blocks similar to the way that Foxboro’s George Woodley had created for Foxboro’s own PCP 88 control systems, and had also been implemented in Foxboro’s Fox/1 computer-based controller. Ultimately, Foxboro’s management decided that we did not have sufficient development staff for this project and declined the opportunity. Honeywell, on the other hand, was at the right place and time and undertook the joint development with ER&E, developing the TDC-2000 under the leadership of Renzo Dallimonti. By the time Honeywell developed TDC-2000, microprocessors became available to implement the controllers. Honeywell implemented the RTL/2 programming calling it their CL (Control Language.) Honeywell marketed TDC-2000 as the first DCS (Distributed Control System.) IBM also developed a mainframe version conforming to this same specification, installed it at one Exxon refinery, but did not attempt to further commercialize it.

 

Through the years, Honeywell’s TDC-2000 and 3000 became the leading DCS in the process industries to the point at Exxon, Mobile, Union Carbide, and many others, it was their only choice for new control systems. As a result, some of the users at these companies began looking at the competition in order to reestablish competitive bidding, but found that they were captive to Honeywell.

 

In 1985, ISA founded the SP50 Fieldbus standards committee. The original stated purpose was to develop a digital communications technology standard to replace the 4-20mA analog data transmission standard. While the committee had volunteer members from most of the DCS vendors to work on network items and protocol, a core group of users were included under the chairmanship of Dick Lasher, PhD who worked for Exxon Chemical. I was the editor for this “User Layer” group. Under Dr. Lasher’s leadership, the User Layer formed a whole new process control architecture that was explicitly designed to allow the process control vendors to compete for new systems by the movement (in today’s language) of the simple single and two-element cascade controls to the edge, all sensor linearization, filtering, and control would be done in smart microprocessor-based field instruments. This user-led architecture development points to an Approach 5 to add to Sandy’s list: an industry standards-based control system architecture.

 

The Fieldbus story is not a good one. Eventually, I was assigned to be the Chairperson of the ISA 50 committee and the newly formed IEC SC65C/WG6 to bring the Fieldbus standard to completion in the face of major objections from international competitors, and short-cummings of the technology of the day. One of the primary problems was the lack of a high speed local communications technology restricting the 4-20mA replacement (H1) to a speed of only 31.25 kbps in order to meet power requirements for intrinsic safety. The other problem was the lack of high speed communications technology for the upper level H2 communications network. In 1999 an H2 version based on high speed Ethernet (FOUNDATION Fieldbus HSE) became available and was eventually included into the IEC standard. The third problem was an international political problem; while the SP 50 Fieldbus protocol was based on a French (FIP) arbitration solution developed in full by the late Thom Phinney that satisfied both link arbitration requirements, it was not exactly PROFIBUS that was a German requirement.

 

Eventually, the IEC Fieldbus problem was resolved by the adoption of a new form of “standard” that was designed to resolve a problem of the European Union – countries within the EU were using local/country standards to restrain trade from other EU countries and even foreign nations. By including the entirety of each local/country standard into an IEC world standard, restraint of trade could be avoided. This new form of standard made no attempt at commonality and was known as a “café standard.” With this change, there was no longer the need to adopt a single protocol for the process control Fieldbus, and it did not happen.

 

The other part of the Fieldbus story is commercial. While the entire Fieldbus, both H1 and HSE were defined in detail, internationally standardized, and supported by the Fieldbus FOUNDATION, the major vendors of process control DCSs uniformly refused to accept system responsibility for systems that contained conforming elements not of their own design, except for FOUNDATION Fieldbus H1 field instruments. While most DCS suppliers used the FOUNDATION Fieldbus HSE design specification to build their own networks, they still recommended that users installing H1 field instruments terminate them in I/O cards specifically designed for H1 termination, rather than terminate H1 wiring segments in HSE Linking Devices, the element of HSE that was designed to aggregate H1 field signals onto an Ethernet-based common network. Without HSE support, the installation cost savings promised by FOUNDATION Fieldbus was lost and the competitive advantage of FOUNDATION Fieldbus vanished.

 

In 2014 ExxonMobil realized that they had a serious problem – there were hundreds of TDC-2000/3000 DCSs that were at their end of life. They initiated a project within their corporate Research, Development, and Engineering division to develop a path to replace these DCSs with more modern equipment in such a way that they would no longer be restricted to the supply/support by a single vendor. At the time, there were no FOUNDATION Fieldbus H1 instruments connected to the TDC DCSs at any ExxonMobil upstream or downstream plants, although the ExxonMobil Chemical Division had some FOUNDATION Fieldbus H1 instruments connected to DCSs supplied by vendors other than Honeywell. A study team was formed and I was one of two outside consultants participating. We developed the ExxonMobil Reference Architecture (EMRA) that was similar to the FOUNDATION Fieldbus HSE architecture except that it recognized that the majority of field instruments were HART-compatible (without function block capability.) Instead of Linking Devices, this architecture included a DCN (Digital Control Node) to move the majority of feedback, feedforward, and cascade control loops to the field. ExxonMobil patented the DCN concept to keep it from being claimed by a vendor; I am one of the patent holders.

 

ExxonMobil attempted to influence the DCS suppliers to support EMRA, but none were willing to risk this conversion. Meanwhile, Honeywell proposed their proprietary solution to the TDC obsolescence problem by offering a gateway between the TDC Data Hiway and their own Experion network, enabling the currently installed instrumentation to communicate with the Experion controllers. Honeywell also enabled users to port the TDC controller software to execute in a virtual machine environment in the Experion system. While the Honeywell proposal solved their immediate problem, along with buying spare TDC parts from Azbil (formerly Yamatake), it did not solve the future problem of dependence upon a single vendor for their process control systems.

 

ExxonMobil’s next step was to submit the EMRA as a starting point to a new Open Process Automation Forum (O-PAS) within the Open Group, an industry-independent standards body. Beginning at the formation meeting in late 2018, I participated in the first year of development by creating a set of process control requirements that the final O-PAS was to meet. The eventual O-PAS was to be a standard-of-standards. As of early 2022, the second of three phases of the O-PAS standard has been released and demonstrations have been built to prove the concept using equipment supplied by member companies. Function blocks were built using the IEC 61499 standard, and systems software conforms to OPC UA.  While most of the traditional process control suppliers have participated in the O-PAS effort, notably Honeywell and Emerson have not.

 

One company, CSI-Automation has been formed to act as a system integrator for O-PAS. The CEO is Don Bartusiak, PhD formerly the Chief Process Control Engineer at ExxonMobil and Co-Chair of the Open Process Automation Forum. Their mission is to install working process automation systems using qualified hardware and software components that meet the O-PAS requirements/specifications. CSI has demonstrated several proofs of concept. Two questions remain: will end user organizations installing new process control systems risk using O-PAS conforming systems; and second, will these system integrators full systems responsibility for their standards-based products.  It is also very clear that there are many other companies ready willing and able to act as system integrators for process control systems. I believe that eventually, the “traditional” process control vendors will be driven to offer O-PAS systems which they integrate and offer full systems responsibility.

 

The big difference between FOUNDATION Fieldbus and O-PAS is that the former was designed only for new or Greenfield installations since it depended upon new Fieldbus H1 instruments. O-PAS does not! The DCN built into O-PAS allows Fieldbus H1, HART, WirelessHART, and ISA100 Wireless instruments to be integrated into a digital control system. Of course, I expect to see lots more evolution in field instrumentation as Ethernet APL and even 5G wireless are integrated. There will always be challenges to process control systems, but the days of the user being captive to a single supplier are probably over.