- By Harry Forbes
- The Final Say
Summary
By Harry Forbes
The rage right now in the world of enterprise information technology (IT) are "containers" and "microservices." Container software technology enables applications to be packaged with only the needed software components that are then deployed ("pushed") to a set of target systems where they execute. Microservices refers to breaking large applications into many small parts and deploying these parts on cloud computing platforms by the hundreds or even thousands. In microservices, the application code for individual apps is much simpler, but monitoring and managing them ("orchestration") is much more difficult. However, these orchestration tasks are done by mature open-source software that has a multiyear track record running applications for a familiar company-Google.
In the world of process automation systems, the focus of the Open Process Automation Forum (OPAF) is on standardizing ISA-95 Level 1 and 2 functions; these are basic I/O from field devices and regulatory control loop execution. Today these functions are performed in proprietary DCS and PLC process controllers, sized to support roughly 100 to 1000 function blocks each. ExxonMobil and other end users envision automation systems with many more, but much smaller, process controller hardware. These devices would control as few as one or two loops each.
What changes are required to deploy and manage the functions of an industrial control system using open-source enterprise software technologies? What advantages do end users gain to justify the change?
Common software run-time environment
Industrial controllers have never benefited from a common software run-time environment. Instead, each automation supplier developed and delivered its own software environment, which is normally invisible to the end user. End users interacted with the controllers only via the vendor's controller configuration software toolset. If you bought a controller from a different vendor, you had to learn a different software toolset. Thus, in the marketplace the controller software toolset represents a vendor differentiator and lock-in.
In higher-level industrial software applications (such as data historians), the Windows software environments leveled the playing field. But at the level of process controllers, the software environment has been a real-time operating system (RTOS), and the end user, by design, has been shielded from it.
This will not be the case in the next generation of process automation systems. One or (more likely) several software run-time environments will become commonplace in process automation. End users would be foolish and unrealistically demanding to expect one single and universal solution. Recall that this never happens for the most common "standards" (e.g., 50 Hz versus 60 Hz, drive on right versus drive on left). Probably one environment will be an operating system, one a hypervisor, and one a container run-time engine. Some important features of these software environments will determine the extent of their use in industrial process automation. Criteria that suppliers (and standardization bodies) should use to evaluate any candidate as a standard software run time are:
Longevity and support: Only a software system that is likely to be long lived with a solid open-source support community is realistic.
Cybersecurity: Security is a major priority, which favors solutions that present a small attack surface and that can be quickly and easily patched.
Compactness and simplicity: An RTOS is usually simpler and more compact than "rich" operating systems (OS). By the march of Moore's Law, the footprint of a full OS (Linux at least) is less of a barrier. Simplicity remains a virtue for many reasons, though, which bodes against a full-featured OS serving widely in this role.
Ecosystem: The platforms need more than just a support community. They need an active software ecosystem that provides other features and services.
The fundamental question is why move away from a software model that has been in service for decades? What advantages drive this transition? Here are a several:
Greater vendor independence: Today, the degree of vendor lock-in is equivalent to the minicomputer market in the 1970s, when each supplier supported its own application software. End users do not benefit.
Enterprise-wide visibility: Management and analytics of automation systems now take place at a process unit level (if they take place at all). Critically important analytic applications are almost impossible to implement across a set of proprietary automation software environments, yet end users badly need to extend these apps across all their operations.
Better skill sets: The high degree of vendor-specific knowledge required today greatly limits the ability to develop and use human resources. This becomes a problem for end users and automation suppliers alike, and neither can afford the current situation any longer.
Reader Feedback
We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.