InTech

MAY-JUN 2018

Issue link: http://intechdigitalxp.isa.org/i/989516

Contents of this Issue

Navigation

Page 49 of 53

50 INTECH MAY/JUNE 2018 WWW.ISA.ORG New software for next-gen automation By Harry Forbes several software run-time environments will become commonplace in process automation. End users would be foolish and unrealistically demanding to ex- pect 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 left). Probably one environment will be an operating sys- tem, 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 fa vors solutions that present a small attack surface and that can be quickly and easily patched. Compactness and simplicity: An RTOS is usually sim- pler 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 re- mains 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 ana- lytics 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. Fundamental change is finally coming to auto- mation software. n T he rage right now in the world of enterprise IT are "containers" and "microservices." Con- tainer software technology enables applications to be packaged with only the needed software com- ponents 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 mi- croservices, 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 with a multiyear track record running applications for a familiar company—Google. In the world of process automation systems, the fo- cus 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 com- mon 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 tool- set represents a vendor differentiator and lock-in. In higher-level industrial software applications (such as data historians), the Windows software environ- ments leveled the playing field. But at the level of pro- cess 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) the final say | Views from Automation Leaders ABOUT THE AUTHOR Harry Forbes (hforbes@ arcweb.com) is ARC's lead analyst for the dis- tributed control system market. ARC leverages Forbes' utility expertise in its open process au- tomation initiatives and the electric power verti- cal industry. Forbes has 30 years of experience in industrial automa- tion, with a BSEE from Tufts University and an MBA from the Univer- sity of Michigan.

Articles in this issue

Links on this page

Archives of this issue

view archives of InTech - MAY-JUN 2018