Open Process Automation (OPA) is often talked about as a “system of systems.” The term acknowledges the nature of the open automation concept with its multiple, heterogeneous interoperating systems. As envisioned, a functional OPA system could well include the integration of multiple run-time engines and controllers from multiple vendors as well as I/O, communication protocols, human-machine interface (HMI) and other related subsystems.
But to be effective, an OPA system will need to function as an integrated platform, performing at a level that is greater than the simple sum of its parts. Achieving this synergy is one of the more complex tasks facing industry and the OPA Forum (OPAF) as it works to create the O-PAS “standard of standards,” where other existing standards are leveraged to bring forward the best of what we've achieved in the evolution of the process industry. Indeed, such a common sense of “systemness” will prove critical to the adoption and acceptance of this new architecture.
What is 'systemness'?
According to Wikipedia, “systemness” is the state, quality or condition of a complex system, that is, a set of interconnected elements that behave as, or appear to be, a whole, exhibiting behavior distinct from the behavior of the parts. Therefore, systemness is the attribute that will most directly affect the usability of new technology such as an OPA system.
Conceptually, OPA is the next step in the evolution of process control systems that have advanced over the decades from local field control to centralized, single-loop control, followed by fully proprietary, multi-loop control systems that today incorporate some open standards as well as commercial off-the-shelf (COTS) technologies from the broader IT world.
OPAF is the industry group working to go a step further and define a next-generation architecture that's both open and based on industry standards. (Please note: O-PAS forms the basis for the requirements for an OPA system, and can be reviewed by OPAF non-members at: https://www.opengroup.org/forum/open-process-automation-forum.)
For operators, the use of a single HMI will result in a common look and feel. In many aspects, simple aggregation of data and logs may meet the basic needs of the designers and support personnel.
Using lingo borrowed from the IT world (and Star Trek), a federation of heterogeneous systems is one way to envision those requirements being satisfied. At a minimum, it will be important to provide a uniform user interface that enables users to interact with data from the multiple disparate databases. Check out O-PAS for a glimpse of the underlying AutomationML formats for exchange of configuration and application formats in OPA systems.
In considering areas of system requirements there are six general areas of services, including alarm management, application management, configuration management, security management, system management and other notifications services.
Alarm management systemness
Alarm management is a concept that is generally understood, so it's the easiest to use as an example of systemness. One generally accepted requirement is that an OPA system will aggregate alarm information for one alarm summary from all control nodes and/or run times. This could be a separate service or the “master” run time, or the HMI system could manage the data.
The system also needs to manage acknowledgement of alarms as well as other advanced options of the alarm state engine (shelving, suppression and out-of-service states). As defined in the ISA 18 standard, the alarm system is about more than just creating alarms. It also includes presenting them on a panel HMI and/or control console for interaction with operations staff, as well as satisfying requirements related to the alarm log and historian. Simply put, there's a fair bit of engineering in existing systems around alarm management. In an open system, this needs to be recreated to the same requirements (at a minimum).
Figure 1: Log event transitions (green circles) are derived from end-user actions and the HMI system, and some are derived from process data interaction with alarm design parameters.
In managing the alarm state engine, alarm log and alarm historian, it's important to understand the state transition diagram from ISA 18.2 (Figure 1). From a logging perspective, log event transitions can be seen as green circles. Some elements of the log record are derived from end-user actions and the HMI system, and some are derived from process data interaction with alarm design parameters.
In a proprietary system, compliance with ISA18.2 is handled in the system or in combination with additional software. In OPA, it's important to understand that this may require specific design constructs in the function blocks or application design. Alarm management can be managed by the controller, the run time, the HMI, or it can be shared among them. Some of the key considerations include:
- Persistence of alarm design information, amenable to audit and online enforcement.
- Location of the alarm state engine (controller, HMI or both).
- Requirements of logging alarm information with a mix of configuration, event and process data.
- Alarm data handling on loss of communication between the controller and the system, and requirements of processing alarm information on restoration of communication.
- Data management on alarm system overloads, including definition of what's shed and buffered.
- Management of complex alarm states (shelving, suppression and out of service), all of which have requirements and recommendations for presentation of information to the end-user in ISA18.2.
Notifications and other services
Meanwhile, ISA18 Work Group 8 is developing a new standard for alerts and other notifications. This effort is ongoing, but has produced a definition for types of notifications that include Alarm, Alert, Event, Notice and Prompt. Most of these have potential implications for handling methods and logging.
For an OPA system to be readily usable, the notification systems need to appear to the end-user as a single system. It would not be reasonable to expect users to log in to each node containing process tags to gather alarm and event data. Logging is expected to be required for alarms, alerts, “operator” change events, system status change events and cybersecurity events.
The other services follow a similar pattern of aggregation and management of data for applications, system configuration, security and system aspects of the OPA subsystems:
- Application management services include the management of persistent data for applications and versions for templates. Further, these services may be able to use “pseudo” containers to help supportability, and leverage the namespace to manage productivity tools.
- Configuration management services include management of persistent data for node configuration, and leverage the namespace to manage productivity tools.
- Security management services encompass user security patching and versioning, as well as user roles and privileges.
- System management services encompass system monitoring and logging as well as system performance and reporting. (OPAF is looking to leverage Redfish for some aspects of system management. Learn more.)
Figure 2: Reference OPA architecture with systemness services indicated. The single letter boxes correspond to the relevant services required for the indicated subsystems: Alarm, Notification, Application management, Configuration management, Security management and System management.
Integrating legacy with new
The complexity of managing the systemness of OPA depends heavily on the level of integration with legacy proprietary systems. As OPA systems become more commercially available, distributed control systems and PLC-style systems will likely integrate into this new architecture. Legacy systems may be migrated to interact with these new platforms directly, or potentially use gateways for connectivity. The legacy systems may support only some portions of full systemness of the new technology, while alarms and security are seen as minimum expectations. The single letter boxes in Figure 2 align with the service types noted above. This is an example architecture, loosely based on the reference OPA architecture.
The degree of integration of legacy proprietary systems with OPA adds complexity to achieving systemness. Simple use of new OPA controllers from different suppliers is less complex, though full integration with legacy systems is likely required for ease of adoption and acceptance.
Initially, the challenge of OPA systems seemed to be the integration of heterogeneous control systems to manage applications across distributed control nodes. However, for ease of adoption and acceptance, the more complex challenges may lie in achieving a seamless “system of systems” integration.
