For a classical automation engineer, the following Wikipedia definition is most likely well known and almost trivial:
“… A control loop is the fundamental building block of industrial control systems. It consists of all the physical components and control functions necessary to automatically adjust the value of a measured process variable (PV) to equal the value of a desired set-point (SP). It includes the process sensor, the controller function, and the final control element (FCE) which are all required for automatic control. …” *source: https://en.wikipedia.org/wiki/Control_loop
And whoever reads this short article is most likely well aware of OPC UA as the fundamental and most powerful technology for access to process variables and set-points in order to exchange this data with other software layers like Supervisory Control and Data Acquisition Systems (SCADA), Manufacturing Execution Systems (MES), Enterprise Resource Planning Systems (ERP) or various cloud-based applications.
On the other hand, many recent discussions with customers and partners have shown, that the focus and mindset with regard to data exchange between automation and business process related software like MES, ERP and Cloud-Applications is too often limited to a kind of “one way street”. Meaning: interoperability is many times about pure data acquisition – time series of sensor values shall be recorded. No doubt, value-added use-cases can be found in Big Data Analytics (including Machine Learning based insights) and/or in classical track and trace (due diligence) scenarios. Also, the intelligent monitoring of process variables can trigger complex business processes like planning maintenance and service (e.g. including smart ordering of relevant spare parts) or automatic material replenishment.
Notification Scenario
In the below figure, such use cases would be based on a pattern that we could name “Notification Scenario” (A). In other words, from a machine or Programmable Logic Controller (PLC) perspective, it is pretty much a “fire and forget” and often relatively easy to implement. Usually it is “just” about configuring an OPC UA Client for subscribing to tag changes (or in some cases to implement a layer according to the OPC UA Publish&Subscribe specification) and about configuring the corresponding follow up processes in case of relevant tag change events.
Query Scenario
Compared to the “Notification Scenario”, the so called “Query Scenario” (B) is – regarding the initially mentioned Control Loop perspective – also rather unobtrusive. Process variables are read based on dedicated user-interaction (e.g. a dashboard which shows upon start or refresh a current machine status) or background jobs trigger a timer-based read of data. Besides the user interface and display-related use-cases, similar processes like with the aforementioned notification-based configuration are seen.
If, on the other hand, the query is not only about reading tag values, but rather about writing tag values (store query) to the OPC Server, the query scenario is opening the door to this article’s title: “The power of business context when thinking about automation”.
It is certainly not new, that the value of a desired set-point (SP) needs to be written from an application like a SCADA System to a PLC – thanks to OPC UA no longer a big technical challenge. Usually, a certain material specific recipe is known in the SCADA, MES or even ERP system and upon a user interaction event like “transfer data for current production order to machine”, the relevant OPC UA tags are written. In more and more cases, the OPC Server already offers a method-based interaction and the result is, that the configuration of the integration between OPC UA client (as a technical “spearhead” of the business system) and OPC UA server can be much more convenient and consistent than a tag-by-tag mapping.
Let’s consider for now a highly automated manufacturing environment and at the same time the requirement to produce configurable or even customizable products (small batches or even lot-size 1). Here, the configuration and customization of a customer-specific product is usually known in and mastered by a business system like an MES and/or ERP (e.g. SAP Digital Manufacturing Solutions and/or SAP S/4 HANA).
Material Master, Bill of Material, Routing, Operations and Resources are examples of the classical master data entities which define the abstract model of a real-life manufacturing process.
However, automation related data like set-points (recipe) are and were often maintained in additional software layers (SCADA, PLC itself …) and the negative effect of distributed and inconsistent data is/was just taken as given.
But thanks to the standardization success of OPC UA the bi-directional integration between Information Technology (IT – Business Context) and the Operational Technology (OT – Physical Components and their Control Functions) is nowadays much less complex and costly than in the past.
The next logical and value-added step in a fully integrated environment along and beyond the classical automation pyramid would be the bold, permanent and automated consideration of additional business context entities like sales order specific data, customer-specific master data, supplier-specific details, ad-hoc priorities, statistical process insights etc. and their corresponding influence on automation related set-points.
Reimagining the Control Loop
Simplified example: a certain customer is willing to pay an extra fee, if the products that he orders is wrapped in water-proof packing material. Let’s assume an automated packing machine which wraps material by default in non-water-proof foil. Based on OPC UA it could be an easy task to configure a process from PLC via MES to ERP or Cloud, where the packing machine “asks” for every new order, which packing material shall be used for the next operation. The “answer” is known by accessing the specific sales order or the customer master data record. In other words, the control loop is extended beyond the OT layer and spans into the IT layer.
Better transparency, better data consistency (single source of truth) and the increased flexibility are the essential benefits, when companies design their manufacturing processes under the paradigm of built in access to business context.
