OPC Classic – or OLE for Process Control – quickly established itself on the market almost 20 years ago. This was, among other things, because the standard provided both users and controller and display system manufacturers’ significant advantages. OPC UA, the technology that replaced it, is available on the market and provides even more utility.
Figure 1: The OPC UA object with its values, methods, and events provides the basis for access via a number of different interfaces.
The OPC DA standard, whose variable access reduced the driver landscape to a single driver for the first time, is part of OPC Classic. The optional browser interface also optimized the engineering process. Instead of generating, editing, and re-importing Excel lists, all variable information could now be read directly out of the OPC server. The replacement OPC UA technology also offers basic services for reading out the namespace. However, in the OPC UA server, not only can variable names be displayed with the variable type, but many different objects can likewise be shown with any given information. The OPC UA object model provides other attributes, methods, and events in addition to names and values. Building on this, functions such as historical data or alarms are then defined (Figure 1).
Significantly more information
The client systems of the OPC UA standard can thus receive significantly more information through the subordinate system mapped in the OPC UA server if semantic rules are defined by way of profiles. For this to function independently of manufacturer, numerous profiles have been created in the last few years; these have, depending on the application scenario, their own standardized addressing models. One example that was mentioned is the PLCopen profile, which a joint working group made up of members of PLCopen and the OPC Foundation developed more than three years ago. The PLCopen profile is in wide use today and is currently being expanded to include more application cases. Besides the variables and their associated values, its addressing model uses the option of mapping additional IEC 61131 objects using metadata.
Metadata make further information available in order to describe the semantics of objects. Among the new objects are the IEC 61131 resource, the defined tasks, and the program/module types. In addition, variables from the IEC 61131 STRUCT type can be read out as a separate object with the complex data definition. For a given structure, the type definition and its elementary data types can be found in the OPC namespace.
Direct implementation in the controller
Figure 2: Waterworx objects in the controller as well as the associated symbols and operator pages allow entire systems to be automated quickly and in a user-friendly fashion.
One example is the Waterworx library from Phoenix Contact. The process library, which was developed for the PC Worx engineering environment, supports the automation of waterworks and wastewater treatment plants. The function modules and help texts were created based on the extensive practical knowledge of operators and planners from the industry. They allow waterworks and water treatment plant staff to easily perform even infrequent tasks such as adjusting measuring points in the program, optimizing process workflows, or diagnosing and removing faults. Moreover, systems integrators can use the Waterworx library to draw on tried and proven function modules that greatly simplify engineering tasks (Figure 2).
Figure 3: The UA server for PC Worx is designed for up to 200 controllers; configuration of and remote diagnostics on the server are also provided by means of OPC UA mechanisms.
The UA server for PC Worx maps all variables with the controller programmed with the engineering tool – even the Waterworx application variables – according to the PLCopen addressing model. It runs on the PC, but is designed so that it can be implemented on certain Phoenix Contact controllers in the future (Figure 3). Visualization objects for atvise suitable for the function modules and mapping in the UA server for PC Worx are in development. The solution, which is widely used in the area of water supply and treatment and based on powerful Web mechanisms, offers deep OPC-UA integration.
Parallel programming and visualization generation
If the structure definitions from the PLCopen profile are used, the engineering process can be greatly simplified. In the first step, the structures in the ObjectTypes area of the OPC UA server are imported and linked to objects or templates in the atvise project. The templates then use the structure’s basic information in the dynamics, displays, input fields, or scripts. atvise subsequently links the instantiated structures from the IEC 61131 program directly with automatically generated visualization objects. Manual modification or linking of OPC variables with the visualization elements, the latter which is prone to errors, is no longer necessary.
There are challenges associated with implementing this function. For instance, the complex data types have been installed in various ways to date. That means that not all information is available in the UA server for PC Worx in the form the client requires. Initial implementations confirm that there is potential for improvement. For instance, a substantial number of objects once generated can be automatically re-used.
The process works well if the workflow from the PLC program to the visualization is running. The PLC program is available first, the server offers end-to-end mapping in its namespace, and the visualization is then generated. Modifications in the PLC program must be followed in smaller steps by modifications in the visualization. However, if the system engineer wants more flexibility and programs and configures the visualization at the same time, a bidirectional exchange via a standardized offline interface must be available. Corresponding data exchange formats have been defined by the OPC Foundation.
Simple read-out of an AutomationML database
Figure 4: Automation ML describes the system while OPC UA specifies the interface which allows access to the system’s data.
Another powerful approach to making engineering processes more flexible is provided by AutomationML, a manufacturer-independent standard for exchanging engineering data in the automation environment. AutomationML proves to be an optimal solution for providing system structures, functional units, and the respective signal lists and device/network information. In a general standardization working group that includes members of the AutomationML users’ association and the OPC Foundation, AutomationML structures have now been mapped in an OPC namespace. The configurators for OPC UA clients and servers can thus read out further information about known methods from the AutomationML database and integrate it into their interfaces. This means that when performing general and detailed planning in other planning and engineering tools, information that the OPC UA configurators can use on the client and server side are automatically generated (Figure 4).
The described interface definition will also be released shortly. What future changes to the OPC UA configuration procedure depend on the adjustments made to the standard: which tools support OPC UA, and how easily will it be for the user to operate the interface. The goal of implementation must be to hide the complexity of the AutomationML data model from the user, who should only see elements that are necessary for the work step at hand. The client and server must also be able to rely on the completeness of the information.
Summary
OPC UA is more than an integrated, flexible interface for transferring runtime data between the client and server. Metadata regarding profiles and the adaptation of AutomationML allows the standard to make additional information available to the configurator on the client and server side; this information significantly reduces the engineering work involved in linking the controller with the visualization, control, and data management systems. There are still several tasks that need to be completed before this will be possible in every combination regardless of the manufacturer. OPC UA is an interface by programmers for programmers. The namespace and the numerous object types are therefore initially cause for confusion for new users. That is why it must be simply to implement. Nevertheless, OPC UA covers current and future communications requirements admirably. There’s good reason why the standard is mentioned as a solution for incorporating the Industry 4.0 concept into automation applications. That’s because there is no other interface in this area that enjoys such wholehearted support from manufacturers and that offers such a wide range of functions.
Dipl.-Ing. Robert Wilmes
Software Marketing
Business Unit Control Systems
Phoenix Contact Electronics GmbH
Bad Pyrmont, Germany