Author: Robert Schachner, RST Industrie Automation GmbH or Embedded4You eV.<\/p>\n
IoT \u2013 the \u201eInternet of Things\u201c and \u201eIndustry 4.0\u201c: These two buzzwords are currently haunting events and trade fairs everywhere. What's said often sounds promising; the ultimate goal, the great success, is announced. However, it usually remains just a collection of buzzwords whose deeper meaning remains elusive. This presentation clarifies what lies behind these concepts and uses a machine as an example to demonstrate how these technologies can be implemented effectively.<\/strong><\/p>\n The image (PDF<\/a>The diagram shows the communication model found in every PLC controller. A global memory \u2013 the process data model \u2013 serves as a storage location for all process parameters (process variables or flags). Electrical signals are cyclically input and output via various I\/O functions.<\/p>\n A control program accesses these process variables, processes the data, and writes process variables back into the process data model.<\/p>\n Since this method overwrites the "old" value in each update phase, only the most up-to-date process variables are always available. Real-time control, as well as real-time regulation, can thus be implemented universally and easily. However, this simple and elegant approach becomes a disadvantage when multiple values or status messages (e.g., commands or error messages) are written to a process variable faster than they can be read from the remote system.<\/p>\n Important information is lost because it is overwritten too quickly. In such situations, the model fails.<\/p>\n This type of communication is almost always behind the "IoT" discussion. At first glance, both communication methods sound very similar. However, upon closer examination, it becomes clear that the two methods differ fundamentally in their impact. In the message-based communication model, messages are serialized, and as in the example above (PDF<\/a>) distributed to other clients via a central intermediary, the so-called broker. In contrast to the process data model, the focus here is on reliable delivery.\u00a0all<\/strong>\u00a0Information \u2013 overwriting values that have not yet been retrieved is no longer possible. The system offers advantages and disadvantages; for example, implementing controllers is extremely difficult.<\/p>\n Besides the usual addressing, where the sender specifies the recipient (request\/response), there is the publish\/subscribe mechanism, which is something entirely new in the embedded world. The sender (publisher) no longer addresses their message to a specific recipient, but simply makes it available under a unique topic. Any recipient (subscriber) can then subscribe to this topic as needed and will subsequently receive all relevant information from the broker until they unsubscribe. Thus, sender and recipient are no longer directly connected; this enables the distribution of information as needed.<\/p>\n To return to the IoT terminology, this has essentially created a "cloud"\u2014a universal storage location for data that can be made available to any number of participants. Contrary to popular belief, this cloud doesn't have to be located on the internet; it can also function as a so-called "private cloud" within a machine control system. This ensures data security.<\/p>\n With this knowledge, we now want to develop strategies for modern machine control. The reference architecture model RAMI4.0, proposed by the VDI and ZVEI, can also be considered in this context.<\/p>\n With the process data model already described, we again rely on the methodology currently used to implement control in almost every machine. Whether a high-level language, structured text, function block diagram, or a model-based approach is used as the programming method is independent of the communication model and depends primarily on the programmer's skills. When using PLC technology, the only requirement is that the hardware is integrated into an open operating system. With middleware platforms like Gamma V, the integrated process data model can be used with virtually any embedded hardware on a Linux or Windows operating system.<\/p>\n It is also advantageous to reuse existing I\/O concepts. Up to this point, our considerations have remained within the standard environment. Now, we want to demonstrate how effectively and elegantly broker architectures can enhance traditional control systems. We will present two examples to illustrate this.<\/p>\n In traditional control systems, this issue is implemented very differently. Often, only process variables are used for temporarily storing error values. However, if two error messages are generated in quick succession, the older one can be overwritten if it is not read quickly enough; frequently, only the most recent error message reaches the application. As a workaround, flags can be created; however, in the worst case, this leads to hundreds of flags, each assigned an error number. Thus, one dilemma is avoided by creating another.<\/p>\n This can be solved much more elegantly using message-based communication methods.<\/p>\n The control systems (Control 1 \u2013 Control 3,\u00a0PDF<\/a>These correspond to the previously described classic architecture, but each has been extended to include a messaging client. This client allows error messages to be sent via the Client RPC API. These messages can contain various details via properties, such as error number, error class, date and time, etc. Within the communication model, each controller now acts as a so-called publisher, making its error messages available via a topic (for example, "ERROR").<\/p>\n The broker can run either on a dedicated computer or \u2013 in a multi-broker concept \u2013 distributed as a separate instance on each participating computer. It then distributes the data received from publishers on the "ERROR" topic to the various subscribers.<\/p>\n This data is then received and processed by services registered as subscribers on the network. Thanks to the previously described separation between senders and receivers, any service can be connected to process the error data. These services communicate exclusively with the topic "ERROR," completely independent of the publishers and other subscribers. As illustrated, a wide variety of applications can be programmed to perform universal tasks such as archiving or, for example, to send emails or SMS messages to service technicians in case of an error. The architecture even allows for any number of error visualizations to run on the machine or on remote terminals, all of which can be operated independently.<\/p>\n This creates a cross-computer fault management system whose flexibility and simplicity are unmatched by any other technology. Entire machines with their dedicated controllers can now be networked without further configuration, and their services can be used centrally. Thus, in an entire machine hall, only a single central UMTS interface is needed to notify the service technician.<\/p>\n Machines are now mostly networked via fieldbuses. Depending on the number of connections, networking can involve considerable configuration effort and a corresponding potential for errors.<\/p>\n The publish\/subscribe mechanism also offers a highly elegant alternative here. As shown in Figure 4 (PDF<\/a>As shown in the diagram, application A, for example, generates a part number and the corresponding status signal "PartReady" via the docked RFID reader. As a publisher, this information is made available on the network. Other machine parts connected to the network can then subscribe to this and any other information as subscribers. In this example, system 2, as a subscriber, receives the information about which part (PartNumber) is ready for pickup and when (PartReady).<\/p>\n This creates a private cloud through which individual machine components exchange information. Machine components can now automatically assemble themselves into a networked machine \u2013 solely via the relevant topics. Since a complex overall system may require managing a large number of topics, it is important to structure the topic names uniformly within a topology or even an ontology.<\/p>\n Message-based communication offers many more possibilities for making control systems more effective. Therefore, in addition to the points briefly summarized here, the presentation will also highlight strategies for networking with production networks and, as a practical example, discuss a successfully implemented machine control system in detail.<\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topics of IoT\/Industry 4.0\/system and hardware development.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in IoT\/Industry 4.0\/system and hardware development is available.\u00a0here<\/strong>\u00a0<\/a>Available for you to download free of charge.<\/p>\n\u00a0Forms of communication<\/h2>\n
1. The process data model<\/strong><\/h3>\n
2. Message-based communication<\/h3>\n
Application in machine control<\/h2>\n
Example 1: Error Management<\/h3>\n
Example 2: Ad-hoc networking of machine parts<\/h3>\n
\nIoT \/ Industry 4.0 \u2013 our training courses & coaching<\/h2>\n
\nIoT \/ Industry 4.0 \u2013 Expertise<\/h2>\n