This second in the series of posts on The Open Process Automation Forum concerns an in-depth analysis of a proposed system orchestration standard written by Harry Forbes of the ARC Advisory Group. This was written for Red Hat, but you can download a copy.
SYSTEM ORCHESTRATION FOR OPEN INDUSTRIAL AUTOMATION
ARC Whitepaper August 2024
Forbes looks at OPAF’s latest intention:
The Open Process Automation Forum (OPAF) recently announced its intention to base its System Orchestration O-PAS specification on the OASIS TOSCA standard. In the context of open heterogenous industrial automation systems, the term “System Orchestration” has a very broad meaning. It includes automated configuration, deployment, coordination, integration, and management of distributed systems and services. System Orchestration is essential for successfully managing complex software environments in modern, cloud-native application architectures. As industrial automation adopts these same architectures, it will also become critical for the industrial automation systems of the Future.
It has been too many years since that first meeting with OPAF leaders in Florida. I seem to remember that they had hired a consulting group (Nassim Nicholas Taleb notes that mathematicians begin with a problem and create a solution while consultants begin with a solution and create a problem) who had ties to the aerospace industry. The foundation standards came from there. I’m not surprised by this OPAF proposal.
Forbes continues:
Over the last 20 years in the IT and cloud computing space, many software tools have been developed and commercialized to serve these types of functions. These tools originated in open source, and several are now supported by commercial suppliers. Some have large installed bases in major enterprises. They also have large and active end user communities. They do not comply with a single standard, but rather support distinct Domain Specific Languages (DSL). During the same period, the vendor-neutral TOSCA specification has been employed in academic research and reportedly in some proprietary software in the telecom industry but has had negligible impact in commercial markets.
I side with Forbes in this preliminary conclusion:
Open automation supporters should leverage the large existing IT communities, human talent pools, and documented best practices that leading commercial products provide. While this precludes adopting a single standard, the OPAF could instead focus on carefully defining orchestration use cases for O-PAS systems, enabling end users to implement them with the commercial software that OT suppliers and industrial automation end users both prefer.
