Basic process control, what we now call level 2 in the Purdue Enterprise Reference Architecture, has been the basis for successful process manufacturing for decades. Industry has witnessed several revolutions in technology, which has produced more accurate, more precise, faster process control leading to better quality and throughput. Innovations have moved from mechanical, to electrical, and on to computational. Currently, the innovation in process control has moved further up the architecture leaving changes at level 2 being mostly incremental.
The Open Process Automation Forum (OPAF) has formed to vocalize the need for standardization of level 2. This need doesn’t focus on technical innovation, but lifecycle costs. What, then, can industry expect in the future from this level in the architecture?
Basic Process Control Innovation and OPAF
This realization is one of the factors behind the Open Process Automation Forum (OPAF) initiative. The ARC Industry Forum has dedicated several sessions to this topic and has written a significant amount on it, as well. OPAF focuses on standardizing systems for ISA95 level 1 and 2 functions. These are basic inputs and outputs from field devices and regulatory control function block execution. ExxonMobil and other end user firms envision control systems with many more, but much smaller, process control. These smaller hardware devices would control as few as one to two loops each, creating what are in effect microservices for process control.
Members aren’t looking for a technical innovation to revolutionize basic process control. All the technical innovation required to achieve their goals has been created. Instead, they want to innovate the business aspect of process control; cost less to engineer, cost less to hire staff, install once, incrementally update, etc. In fact, much of the recent innovation from process control suppliers centers around project and lifecycle costs, not better control of the process. It would seem all the opportunities have been taken at level 2.
All this parallels what has already occurred with process field devices. When you consider the valves and transmitters in your plant, they are pretty much commodity items. Each manufacturer might have functionality that makes it more attractive, but any of them will accomplish the goal. While these devices used to consume a considerable amount of engineering time, end users now send the supplier the process data and receive the properly configured device. Technicians install it and it’s done.
The approach the market is taking with level 2 control is taking is very similar. The value proposition on most field devices centers around ease of configuration, ease of use, ease/cost of support, and initial cost. All new value in the space is found in software applications supervising the devices. The approach being pursued by OPAF means there will be little to no intellectual property at the control level to safeguard, just like a transmitter today. Instead, critical information will be maintained at a higher level in the control strategy. An OPAF architecture certainly enables suppliers to safely embed proprietary (and potentially superior) Level 2 control algorithms in products. It is an open question whether supplier would focus on this level rather than higher value applications such as model predictive control for multiple loops.
About ARC Advisory Group (www.arcweb.com): Founded in 1986, ARC Advisory Group is a Boston based leading technology research and advisory firm for industry and infrastructure.
For further information or to provide feedback on this article, please contact RPaira@arcweb.com
About the Author:
Mark has nearly 30 years of expertise in process control, SCADA, and Industrial IT applications. He began his career as a Process Control Engineer with Mobay Corporation (Bayer) in Baytown, TX working with instrumentation, PLCs, and DCSs. He later joined Honeywell as an Applications Engineer working with DCS and SCADA and later joined the sales group as a Systems Consultant for SCADA, batch, Foundation Fieldbus, and hybrid control products. At Plant Automation Services, he managed the alarm management products and wrote the initial specification for PlantState Suite.