(Snapshots from the near future: Part 4)
Introduction: The Next Generation Control System Initiative
A couple of years ago, while reading an online magazine or a web page, I found out the initial details of the so-called Exxon Mobil’s Next Generation Control System initiative (let’s call it the NGCS).f
This initiative originated in the following way:
Exxon had been doing some budget calculations for the Distributed Control System’s (DCS) upgrade in their plants and facilities spread around the globe and had found out that quite a few of them were due for an update.
One’s problem is another’s blessing
DCS updates are the lifeblood of DCS companies. This is because the competition is so hard in the green field project market, that the DCSs suppliers usually issue their project proposals with very small margins and sometimes even none.
The idea is that they may have a marginal profit in the project’s bid, but after winning the project, the associated services, customizations, expansions, and upgrades that come along with the DCS’s plant implementation can become quite expensive, and this is where the real core business of DCS suppliers’ lays.
By locking customers to their systems, and persuading them to perform regular system updates, they generate a constant source of revenue.
Also, end users are dissuaded from keep running their old systems because spares become increasingly more expensive and difficult to obtain. Additionally, software support becomes harder over time and some of the stuff employed just turns obsolete.
In the past, I’ve seen a couple of refineries that had upgraded their old Foxboro IA Unix based DCS. In the control room, they had expensive looking and perfectly working Unix Silicon Graphics workstations gathering dust, after being replaced by Windows servers running the newer I/A version that ran on Microsoft’s OS.
A bold new approach to an old problem
Exxon did the numbers and the final figure they got was so big that they started to think if, for that kind of money, whether they could develop their own control system, preferably based on open standards.
After making this decision, they hired Lockheed Martin, a company that had some experience doing integration work with open standards-based technologies employed in mission critical applications (a.k.a. aerospace). The mission assigned was to serve as a systems integrator for the initial development of an architecture for a next generation automation system for the process industry.
They expect to make advances in quite a short time frame since the concept is to use already available and proven technologies in a brand-new concept, rather than to develop a solution from scratch.
The idea certainly is quite interesting. I googled for some time looking for more details but it seemed that basically, the same info was appearing everywhere. Then my curiosity focused on Smart I/O systems.
A little bit of history
Traditional control systems have been based on a controller (CPU based) that solved control loops and interacted with the process via the I/O system.
The I/O system initially was a group of cards that enabled the controller to receive input data from the field sensors and outputs that send command data to the field actuators. This group of cards initially was part of the controller, but eventually became a subsystem that could be located farther away from the controller as industrial communications technology evolved.
With the advent of serial field buses first and Ethernet-based ones later, the I/O subsystems became known as RIO systems (Remote I/O).
These subsystems could be supplied by the DCS (usually built by an OEM) or by a third party associated supplier.
All of them featured basically a backplane upon which you could add communication head-stations, power supplies and a wide variety of I/O cards or modules.
A controller could handle a few of the RIO subsystems and the trick was to correctly calculate the processing power required by the plant (quantity and type of Inputs and outputs and type of control loops required) to supply the proper sized controller or controllers if the plant was big enough.
The guessing came when one had to estimate the reserve space in the RIO subsystems and in the controller’s processing power to cope with future expansions or upgrades.
If the future requirements overcame your controller’s capabilities, then you had to add another controller, thereby doubling your costs.
The same happened with your I/O reserve. If your demand exceeded the RIO subsystem I/O allowance you had to add another subsystem.
Enter the Smart I/O concept
The Smart IO concept, also known as Intelligent Marshalling, Electronic Marshalling or Virtual Marshalling, consists of variations of the following ideas:
- First: you develop a universal IO subsystem, that can be tailored to your needs by offering single channel I/O cards configurable by “characterization” modules (the slot based approach) or multichannel I/O cards configurable by software (the software based approach).
- Second: you connect your Smart I/O subsystems to the controllers via a (typically) redundant high-speed deterministic Ethernet based network backbone.
- Third: you make possible that each I/O channel could be accessed by any controller available in the network.
- Fourth: you standardize the cabinet layout, let’s say for indoor or outdoor applications and make them modular.
The obvious benefits are:
- First: you no longer need marshaling cabinets, since you can land your field cables directly to the I/O’s terminal block since each channel can be configured individually you don’t have to reroute the wiring or do any cross wiring.
- Second: by using Ethernet as a backbone, you can use COTS hardware, which is significantly cheaper than any serial cabling infrastructure hardware due to economies of scale, even if it is industrial strength hardware.
- Third: You no longer must worry about running out of I/O points locally, you can connect any field device to any I/O, configure it and send the data to whichever controller requires it.
- Fourth: There’s no need for custom cabinets, they can be built at the supplier’s facilities and, due to their modularity, an expansion just means adding more cabinets.
A new approach to project execution
There is another advantage in the use of Smart I/O: since your cabinets are standardized, you can build them while your plant is also being built. This is known as parallel project execution.
In this way, and given the fact that virtualization techniques are becoming commonplace, you can greatly achieve lower hardware costs and shorter project schedules.
But the Smart IO systems currently in use by ABB, Emerson, Honeywell, Schneider/Invensys and Yokogawa are designed for 4-30 mA Hart field devices. So where does the fieldbus technology, once supposed to replace analog technology in the industry fits in the NGCS fits in? My first impression was that the NGCS idea left the fieldbus behind. I even wrongly posted a comment on my previous post, a mistake that was quickly detected and corrected by Jonas Berge (he seems to be aware of any mistake or misconception committed by anybody on Linkedin, I wonder if he ever sleeps…). Afterward, he sent me to do my homework.
Forgive me, Jonas, for I have not fully researched my subject…
I started by reading the NGCS’s patent application, which is available here.
After reading the patents that Jonas mentioned, I found out additional information on the NGCS, especially about the Distributed Control Node (DCN) concept.
One of the most interesting ideas that Foundation Fieldbus offers is the CIF or Control In the Field concept. The idea is to enable field devices to communicate with each other and to be able to solve control loops or execute function blocks independently from the controller. The issue that CIF couldn’t face is that if a device is replaced by a similar one but from a different supplier (let’s say a multipoint temperature transmitter) the replacement may not contain the same function blocks as the original, therefore making impossible to keep the CIF loop working.
This is where the DCN appears. Until now, all DCSs were based on monolithic controllers; one solution for all applications. But the processing power of COTS CPUs has increased as exponentially as their price decreased, thus making it possible to design supercomputers using, for example, COTS GPU hardware originally designed for the gaming industry.
Like Legos, DCN’s come in several formats, but they are always modular
The NGCS concept features so-called Application DCNs and Device DCNs.
Device DCNs are standardized single loop controllers (but the CPU included in each DCN has processing power like the CPU of a DCS controller) that are connected via a real-time deterministic Ethernet network backbone. Since they are all connected in real time, they can work in cooperative mode. Each DCN contains a standardized set of control blocks, meaning that any loop can be solved in any controller or controllers working cooperatively. The DCN’s I/O interface will also feature some kind of Smart IO technology, so you could connect 4-20 mA, Hart or any kind of available device, therefore protecting prior investments and legacy hardware
The beauty of this concept is that you no longer are tied to a fixed size controller. You can start with a single DCN and start adding DCNs as your processing needs grow. If the DCN concept is combined with the Smart IO concept, you can do CIF with any device. The NGCS also includes support for DCNs working as gateways, so legacy field busses can be integrated into the DCN network. Again, DCN gateways share the standard function block set. Wireless gateways with embedded DCNs can extend the system’s functionality.
Application DCNs are assigned the advanced control applications such as Historians, interfaces to business applications, Asset management, alarms end events, etc. They can be hosted on any computing platform that supports the Real Time OS in which the Application DCN can run. These include physical servers or virtualized servers. A support technology concept called Network Functions Virtualization (NFV) can virtualize all kinds software and resources on top of high-performance servers, network hardware, and storage systems. It can even run on cloud-based infrastructure.
Other more esoteric concepts include Software Defined Networking (SDN) that makes network control programmable and enhances network availability abstracting the network resources from the physical infrastructure.
A sort of container framework platform would be used to host engineering applications and tools via a plugin model.
The patent goes on with further descriptions of additional concepts, but I guess you get the idea.
I’d rather be a user than a supplier. Yes I would, if I could, I surely would
Obviously, DCS suppliers were shocked by this initiative. It is a complete paradigm shift for their business model. But since the NGCS concept is being supported by companies like Aramco Services, BASF, Chevron, Dow Chemical, ExxonMobil, Koch Industries, Merck, Praxair and Shell, control system suppliers just joined the effort
The latest offerings of control systems suppliers seem to be oriented towards the NGCS general goals. Since the previous month, I had started to write a series of posts about my experiences on visiting the Hannover Messe industrial fair, and writing about the Smart I/O trend that the main DCS suppliers seem to have adopted. While doing this, I asked myself why such a big player in the field as Siemens had not made any approaches to this area.
Germans think in aa different way, always
So, when I visited the Siemens booth I found out some interesting products: a new version of the ET200 RIO system and a radical approach to the Smart I/O concept called the Simatic Compact Field Unit (CFU).
The ET200S HA (High Availability) RIO system offers native PROFINET IO support, small I/O pluggable modules that can be configured to work in single or redundant mode by using different backplane mounting bases and can be replaced without resetting the controller. The ET200s HA supports Configuration in the Run and redundant PROFINET connections, either with copper or fiber optic connections. With this system, Siemens follows the trend towards cabinet standardization, Zone 2 approvals and the ability to offer prewired cabinets available before I/O module connection.
Nice, but not groundbreaking at first sight.
But one of the available I/O modules is the highlight: a 16 channels universal module that can be configured as either DI, DO and AI with HART support. Each channel can be configured individually.
Smart IO with a PROFIBUS flavor
Enter the Simatic Compact Field Unit: Siemens designed a sort of a smart PROFINET field distribution box that features 16 channels, 8 of them are digital and can be software configurable as either DI’s or DO’s on a per channel basis. The other 8 offer support for PROFIBUS PA field devices.
This is something bold to do because other suppliers have put their cards on advanced support for 4-20 mA Hart field devices. Siemens is trying to use their expertise in PROFIBUS technology by solving most of the caveats of PROFIBUS PA fieldbus technology:
- First: They eliminate the need of a segment coupler. PROFIBUS PA devices can be directly connected to the CFU, which is a PROFINET IO device. In this way, all the arguments about transparent and non-transparent couplers become pointless, as well as all the discussions about telegram size limitations that affected the DP/PA Links.
- Second: Since the CFU is a PROFINET IO device, it can be accessed by any controller present in the network at any time by the use of the “shared device” PROFINET concept.
- Third: CFU’s can detect the device profile directly from the device’s firmware, enabling automatic device detection and addressing. Automatic device replacement detection becomes possible. There is no need for GSD files since the device’s functionality is read from its firmware.
Some details remain unknown
The CFU is certified for Zone 2 installation, and since is rated as an Ex ic [ic] associated apparatus, it means that intrinsically safe PROFIBUS PA devices mounted in Zone 2 can be connected directly to the CFU, no device couplers are required. It can be mounted on a DIN rail (IP20) in a cabinet or in a field cabinet (IP66).
What I don’t know, and could not found out yet, is the length of the PROFIBUS PA cable that can be run from the CFU to the field device. It’s supposed to comply with the FISCO concept, but whether each PROFIBUS PA connection works as a trunk (offering cable runs up to 1000 m long) or as a spur (supporting cable runs in the 60 to 120 m range) will be a key factor in the CFU commercial outcome. Maybe they went for something in between, like the first spur of the AFDIS, which supports cable runs of 400 m.
Just when I knew all the answers, they changed all the questions…
Although I like this bold and radical approach to the Smart I/O concept, I also feel somewhat nostalgic. Because suddenly, all the knowledge I had accumulated over the years on PROFIBUS PA topologies, infrastructure, and device installation techniques seemed to be old fashioned.
Think of the CFU as a downgraded, controller-less first generation approach to the DCN concept, it has the ability to extend the network to the field while offering support for digital field devices, but in doing this it converts all the existing PROFIBUS PA infrastructure technology into legacy stuff. At least if you just have Zone 2 applications.
I suppose the next step for Siemens is extending these concepts for Zone 1 and Zone 0 applications. That will be something interesting to see.
Mirko Torrez Contreras is a Process Automation consultant and trainer who tries to be aware of the current trends in his field and is barely able to do so. He and the AUTEX SA team are looking forward to meet you at the upcoming PROFINET trainings at the PITC/PICC (Profibus International Training Center / Profibus International Competence Center.
Please check the training schedules at www.profibus.com.ar
You can find the first article of the series here, the second one here, the third one here and the fourth one here
This series will continue next week.