Forerunner to Industry 4.0 and the Internet of Things
Service-oriented architecture programmable logic controller (SOA-PLC) is the forerunner to Industry 4.0 and the Internet of Things. Large data quantities have to be exchanged, from the sensor to the IT level. The corresponding protocols and standards of PC-based control make it ideally suited for this task.
Industry 4.0 and the Internet of things (IoT) are concepts which require a high degree of networking and communication between devices and services. Large data quantities have to be exchanged, from the sensor to the IT level. The corresponding protocols and standards of PC-based control make it ideally suited for this task.
Another fundamental factor contributing to the feasibility of IoT and Industry 4.0 is the service-oriented architecture (SOA) programmable logic controller (PLC). PLC access via web service is not new-so what is SOA and what exactly is new in the "SOA-PLC"? And what added value does it offer?
Industry 4.0 concepts enabling fast, dynamic production require suitable networking and communication between devices and services. They must be able to communicate directly with each other. Sensors, measuring devices, radio frequency identification (RFID) chips, PLCs, human machine interface (HMI), manufacturing execution systems (MES), and enterprise resources planning (ERP) systems all provide important production data for enterprises. In conventional control architectures, data requests are event-driven or initiated cyclically, and are always in response to requests from above, that is, from the client level. The lower level always acts as a server and responds. Visualization, for example, can request status data from the PLC or transfer new production recipes to the PLC. The first step is the conversion of electrical sensor signals into digital information. This is followed by the allocation of a timestamp within the PLC and transmission of the information to the MES-IT level via further services (Figure 1).
With Industry 4.0, this strict separation of the levels and the top-down approach of the information flow will start to soften and mix. In an intelligent network, each device or service can autonomously initiate communication with other services.
B2B, B2M, M2M
Generally, all communication scenarios and use cases that are defined in Industry 4.0 and IoT groups can be distinguished from an abstracted perspective into two contexts of the communication architecture: on the one hand, services in "hard real-time" (such as the automation context, a deterministic PLC for control purposes); and on the other hand, services in a "soft real-time" context, such as in an IT context (Figure 2).
This results in precisely three potential communication transitions, as defined by the Industry 4.0 WG2 executive committee:
- Business to business (B2B) communication: Two business processes communicate with each other. Example: An ERP application exchanges information with an MES application. The exchange, such as between HMI and MES, MES and MES, or sensor and cloud, can take anywhere from a few milliseconds to several minutes.
- Business to machine (B2M) communication: A "soft real-time" process communicates with a "hard real-time" process. Example: A business application exchanges information with a machine. The time necessary for the exchange, for example, of live data between HMI and PLC, or MES and PLC controller, can vary from a few milliseconds to several minutes.
- Machine to machine (M2M) communication: Two processes communicate in the automation context with one another either in "hard" or "soft" real-time. Example: A robot platform controller exchanges control information horizontally with a handheld robot controller. The exchange must take place in a hard, deterministic real-time cycle ranging from µs to a few ms. Example: Two controllers exchange data horizontally-fast (in "soft" real-time), cyclically, and fieldbus-independently. Here, determinism can be seen as a quality of service (QoS) with certain requirements that a communication process might meet or not meet; these requirements would be defined by a guaranteed duration, such as a response time of 100 µs.
The term "M2M" is already used in mobile radio communication, where it refers to the interfacing of devices via mobile communication with IT processes. In this context, the view is widespread that M2M is present whenever a SIM card is used.
Whatever terms will eventually define the three categories, the fact is that in IoT and Industry 4.0, communication will no longer be based on pure data and the interoperability of the data communication. It will focus on the exchange of information models and, therefore, semantic interoperability. An important factor will be transmission integrity and security of the access rights to individual data or services. All these requirements are key aspects of the OPC Unified Architecture (OPC UA). It contains a description language and the communication services for information models. As an IEC 62541 standard, OPC UA is designed to map the information models of other organizations, such as BACnet, PLCopen, IEC 61850, AIM AutoID, and MES-DACH, among others. According to the German Federal Office for Information Security, BSI (Bundesamt für Sicherheit in der Informationstechnik), the "security by design" integrated into OPC UA is significantly better than in other protocols, and is therefore being evaluated in a current project, due to the high relevance for Industry 4.0.
Thanks to the standardized consolidation of data as well as their structure and purpose (metadata), OPC UA is particularly suitable for distributed, intelligent applications between machines, without the need for higher-level intelligence or central knowledge. The functionality of OPC UA components is scalable and is already available at the sensor level (such as wind turbine manufacturer Areva's current sensor memory usage, starting at 240 kB flash and 35 kB RAM) right up to SAP systems.
PLCopen: OPC UA client functionality in the PLC
For the "initiate communication" task, the PLC controllers must have a client component-ideally as a standardized interface. In October 2006, Beckhoff Automation proposed to define PLCopen communication blocks based on OPC UA. Three years later, this led to the formation of a joint PLCopen and OPC UA working group. In 2010, mapping of the IEC 61131-3 information model in OPC UA (server) was adopted as a common specification. In practice this means that one IEC 61131-3 compliant PLC program can be loaded unchanged onto PLCs using the different proprietary engineering tools of different manufacturers. The controllers make their data and information available externally in a semantically identical manner via OPC UA, such as for visualization and MES/ERP tasks. This significantly reduces the engineering effort. In a function block instance with 20 data points, for example, instead of linking each individual data point into a visualization mask or an MES system, it is now sufficient to link a single instance object, and to do this in the same way even for different manufacturers.
Further constructive group work resulted in the next step in April 2014 in the form of adopting the PLCopen specification "OPC UA client function blocks for IEC 61131-3." In this way the controller can play the active, leading part in the communication, in addition or as an alternative to the usual distribution of roles (Figure 3).
The PLC can thus horizontally exchange complex data structures with other controllers or vertically call up methods in an OPC UA server within an MES/ERP system, such as to retrieve new production orders or write data to the cloud. This enables the production line to act independently (Figure 4).
Customers realized the potential of these function blocks.
Silvo Merz from Zweckverband Wasser und Abwasser Vogtland (Vogtland Water and Wastewater Association) used compact embedded PC controllers to form an intelligent network between 300 local water management systems. Actual objects, such as pumps, were modeled in the IEC 61131-3 PLC controller as complex objects with interaction options. Because the OPC UA server is integrated in the controller used, these objects are automatically available as complex data structures for semantic interoperability with the outside world. The result is a decentralized intelligence that makes decisions independently and transmits information to its "neighbors" or queries statuses and process values for its own process to ensure a trouble-free process cycle. With the standardized PLCopen function blocks, the devices independently initiate communication from the PLC to other process devices as OPC UA clients, while being able to respond to their requests or to requests from higher-level systems such as supervisory control and data acquisition (SCADA), MES, and ERP as OPC UA servers.
The previous proprietary solution was replaced with the embedded controller with the integrated OPC UA client and server, "resulting in savings in initial license costs of more than 90%," according to Merz.
- Events & Awards
- Magazine Archives
- Digital Reports
- Global SI Database
- Oil & Gas Engineering
- Survey Prize Winners
- CFE Edu