As the convergence of IT with operations technology (OT) tools has accelerated, process automation practitioners now have at their disposal an increasingly diverse variety of solutions—many of which are designed to leverage common standards to work together toward new, synergistic objectives.
Openness at the “low” end of this converged IT-OT spectrum is on display in the article, “Raspberry Pi vs. PLC for model-based control.” While there certainly were differences in implementation ease (spoiler alert), both the PLC and the off-the-shelf microcontroller were able to successfully execute a model-predictive control (MPC) strategy.
Meanwhile, openness and interoperability at the far other end of the process automation spectrum is embodied by the work of the Open Process Automation Forum (OPAF). As Bridget Fitzpatrick and Jeffrey Shannon of Wood discuss in the article, the "standard of standards" that OPAF is defining must result in "systemness," a synergy among heterogeneous, interopering subsystems that is greater than the sum of its parts, for the OPA movement to succeed.
And, if Jim Montague's OPA cover story update is to be believed, they're further along on their interoperability mission than many of us might have thought.
One part of the Open Process Automation Standard (O-PAS) that's likely to become especially important is a portion of the just-released, preliminary O-PAS, Version 2 (V.2) on portable DCS configuration. This section, "Part 6.4—Information and Exchange Models: Function Block Standard Set," is being developed by OPAF's Technical Working Group (TWG), and it covers small sets of function blocks, regulatory control foundations, and non-exclusive programming standards, such as IEC 68104 for electronic device descriptions (EDD), IEC 61131 for PLCs and IEC 61499 for function blocks. It also specifies data models, inter-block and execution interfaces, as well as functional logic, which can be used to further specify O-PAS systems and field device interfaces.
The reason it's becoming a pivotal part of O-PAS, V.2, is that programmers, software developers, suppliers and pretty much anyone with a useful idea could potentially use it to create, market and sell function blocks that could serve O-PAS devices, as long as they comply with the standard and its interoperability requirements.
Function blocks swapped seamlessly
In a late-breaking addendum to this month's cover story, Steve Bitar, automation advisor at ExxonMobil Research and Engineering and former TWG co-chair, reports he invited its team members in early January to submit function blocks for measurement and control, so he could test if they were interoperable enough to be swapped in and out of a basic control system on a simulated distillation column.
The blocks are created in the IEC 61499 development environment, and must agree on a common plug-and-socket method for allowing bidirectional data flow between them. He also developed an ExxonMobil function block for a PID controller in his control system, and in early February, Schneider Electric delivered one function block and interface for a PID controller, and Yokogawa and Siemens each submitted one block and source code for an analog input.
Bitar downloaded and connected the first function block on the night of Saturday, Feb. 1, and after an initial adjustment, he replaced his ExxonMobil block with the contributed control block. It and the others worked right out of the box.
"We successfully controlled temperature; bumpless transfer worked, too; and we reestablished the cascade connection with bidirectional data flow," says Bitar. "The new block was successful even though the logic in the ExxonMobil block and the Schneider Electric block were different. This means suppliers or anyone can innovative and write software for process control, and it will work on an applicable device if it complies with O-PAS."
