EN 
DE How can this be achieved? Technologies, methods, and goals.
Author: Robert Schachner, RST Industrie Automation
Contribution – Embedded Software Engineering Congress 2017
The implementation of production facilities, as described by the Industry 4.0 Reference Architecture Model (RAMI 4.0) or the parallel IoT development with its Industrial Internet Reference Architecture (IIRA), has now become a reality. Companies and operators are ready to digitize their production facilities.
But who can accompany the operator on this path? Naturally, one first thinks of companies like IBM with its Watson or Siemens with MindSphere. These big players are primarily needed on the office floor. However, the most important player is the operator itself, with its service personnel and IT department. Only they are capable of defining the requirements and processes. And it also requires medium-sized specialist companies as a third player in the network, capable of integrating these requirements and processes machine by machine, service by service, on the shop floor in collaboration with the operator. (see PDF, Fig. 1)
Reference Architecture Model Industry 4.0 (RAMI4.0)
The aim of this standard (DIN SPEC 91345) is to establish a common understanding of the fundamental concepts as well as a consensus on reference models and architectures. For successful implementation, it is essential to become familiar with the key criteria of the implementation recommendations contained in the standard. (see PDF, Fig. 2)
It is important to understand that a modern production system no longer consists of an automation pyramid, but rather of two communication levels that form the corresponding connectivity or a shared semantic model. The three-dimensional representation of all relevant levels is equally important for a fundamental understanding.
– Layer level with detailed layering from asset to business layer
– Lifecycle and value stream with the representation of the life cycles of assets and products
– Hierarchy level that allows for a functional classification of elements
(see PDF, Fig. 3)
For the integration of assets or machines, a so-called "Industry 4.0 component" was defined in the standard. The graphic illustrates very clearly how this is to be done. (see PDF, Fig. 4)
The subject here refers to machine controls, drives, but also manual workstations that are integrated into a unified service shell – the administration shell.
Communication methods on the shop floor
Traditionally, machines are controlled by PLCs (Programmable Logic Controllers). These are integral parts of the machines and should not be modified due to the effort involved and the risk of voiding the warranty. Process data is cyclically read, processed, and output. Only the most recent information is important, as it provides a timely reflection of reality. The amount of data is easily reduced by overwriting older data. (see PDF, Fig. 5)
Due to a lack of persistence, this model is unsuitable for handling error or status values. Serialized communication of data and commands (messages) via brokers, which then organize their distribution, is much more suitable for persistent data communication. The data then remains in the system until it is retrieved by a client. This method forms the sole basis for communication in most middleware technologies. The synchronous process data model is usually not supported, even though it is essential for cyclic processing. (see PDF, Fig. 6)
However, this form of communication is not slow. Control programming commonly used in automation via "state machines" can be implemented faster and more efficiently with messages.
Information is now sent to dedicated clients via addressing. Alternatively, messages can be sent to so-called topics (semantically addressed, virtual channels) (publish). Clients can then connect to topics (subscribe) and thus receive the publisher's messages. Powerful wildcard functions facilitate the selection of appropriate topics.
Publish/subscribe is the only form of communication that does not involve a direct connection between sender and receiver. It is the most important innovation in communication, as a cloud would be impossible without this mechanism.
And there are Quality-of-Service features, such as "Last Will", a predefined message that is distributed when a client disappears from the network.
A crucial factor in selecting middleware is a multi-broker architecture. This allows clients to communicate locally much faster and independently of the network via their own dedicated broker. Across the entire system, messages are then distributed only via the brokers. This makes communication redundant, and the Industry 4.0 components remain functional even if the network fails. (see PDF, Fig. 7)
Although the shop floor is usually not connected to the internet, adequate security measures such as certificates for authentication and encryption of transmitted data should still be implemented. Role-specific restrictions on communication are also recommended.
Services in the administration shell
Services are utilities that aggregate and process information from one or more machines. In an Industry 4.0 component, services form the administration shell and communicate with higher-level services via the Resource Manager. They centralize and coordinate information across machines.
An important example of services in a production plant is fault management. A service in the administration shell uses the available information to detect the fault condition and publishes it to a predefined topic. If the available information indicates that a fault will occur shortly, this is also called predictive maintenance. Higher-level services subscribe to these messages and store them in a database or inform the service technician. (see PDF, Fig. 8)
Implementation
For implementation, all information from quality management processes, service technicians, production line employees, and the IT department is compiled into user stories and use cases. Specifications are then derived from this information and subsequently implemented in manageable steps.
For implementation, data is read from the existing controllers using a variety of methods. The middleware should already provide interfaces for fieldbuses. Since no changes may or can be made to the existing machine controller, the data is now mirrored in a digital twin, i.e., a synchronous process data model. Further data processing and aggregation can then take place at this level via the administration shell services. (see PDF, Fig. 9)
When new machines are developed, the same model can be used. Instead of a PLC, a fieldbus is adapted to capture the I/O signals and transfer them to the process data model. Now the control software can coordinate the processes while the higher-level services of the administration shell process the data.
In addition to various tools for control and service development, the middleware must also provide tools for testing and simulation. On-site programming, which paralyzes production until errors are eliminated, is no longer feasible. Continuous integration with automated rollout should be the goal here.
In this way, all machines in production are now being integrated into a unified service landscape where all assets can be processed and coordinated uniformly. In many cases, in addition to message-based communication between the machines and their synchronous controllers, a synchronous network must also be established. Synchronized real-time data is transmitted via this network when necessary. (see PDF, Fig. 10)
Only now does the integration with the higher-level office floor become meaningful and possible.
A protocol converter handles the translation of data between the office and shop floors. This creates connectivity to any endpoints and thus a common semantic model.
The successful implementation of digitized manufacturing is only possible if operators, SMEs, and large corporations collaborate. In addition to implementation strategies, migration strategies must also be developed. Unilateral or haphazard implementations, which unfortunately are currently common, significantly jeopardize such projects and the operators themselves.
Bibliography and list of sources
[1] https://www.zvei.org/themen/industrie-40/das-referenzarchitekturmodell-rami-40-und-die-industrie-40-komponenten/
author
Robert Schachner, Dipl.-Ing. (FH), is Managing Director of RST Industrie Automation GmbH and Technical Director of Embedded4You e.V. For 30 years, he has worked with middleware-based embedded systems. To date, he and his team have demonstrated efficiency in more than 250 different projects in production, machine control, and testing. Regarding middleware, he is involved with the VDI/VDE 2657 guideline, gives computer science lectures and training courses, and provides consulting services to clients.
IoT / Industry 4.0 – our training courses & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topics of IoT/Industry 4.0/system and hardware development.
Training & coaching on the other topics in our portfolio can be found here. here.
IoT / Industry 4.0 – Expertise
Valuable expertise in IoT/Industry 4.0/system and hardware development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
