FOCUS – BEST PRACTICES 18 / UdZ 02.22 Kommandos, Anfragen und Antworten austauschen, werden in der EDA zentralisiert Statusänderungen (= „Events“) ausgetauscht. Systeme kommunizieren lediglich mit einem Vermittlersystem, dem Broker, und teilen diesem jegliche relevanten Ereignisse mit, sobald diese auftreten. Systeme, die sich für diese Ereignisse interessieren, verbinden sich mit dem Broker und erhalten die notwendigen Daten in Echtzeit. Anstatt Information direkt bei Systemen mittels Transaktionen anzufragen, wird auf zentral verfügbare und systemunabhängige Informationen reagiert. Der Clou dabei ist, dass jedes System nur mit dem Broker verbunden ist und die anderen Systeme gar nicht „kennt“. Es ist nicht notwendig, die Protokolle, Datenformate und Mechanismen der Systeme zu kennen, von denen Information benötigt wird. Wichtig sind in dieser Architektur nur die Daten, die zentral in Echtzeit und einem einheitlich definierten Datenschema bereitgestellt werden. Technisch muss ein System also nur noch die Verbindung zum Broker implementieren, um auf sämtliche Ereignisse im gesamten Unternehmen reagieren zu können. Publiziert eine Maschine beispielsweise das Event „Arbeitsgang abgeschlossen“ und fügt die notwendigen Datenpunkte an (z. B. Maschinen-ID, Auftragsnummer und Prozessdaten), kann das Ereignis sowohl durch ein MES, zum Abschluss des Auftrags, und gleichzeitig durch ein Instandhaltungssystem, zur Erkennung eines Wartungsbedarfs, konsumiert werden. Das publizierte Event bedarf keiner Adressaten und kann von beliebig vielen Empfängern verarbeitet werden; keines der Systeme muss dafür eine andere Schnittstelle als die des Brokers implementieren oder überhaupt die anderen Systeme kennen. Aus dieser systemischen und semantischen Unabhängigkeit leitet sich eine ungeahnte Datenverfügbarkeit und insbesondere Flexibilität im Kontext der Industrie 4.0 ab. Eventgetriebene Architekturen sind dabei keine bahnbrechende Neuerung. In der Softwareentwicklung sind sie schon seit Beginn leistungsstarker Betriebssysteme ein fester Bestandteil System / component Interface D Relevant data F Function Event-driven architecture ERP OT OT MES IoT Event-Broker D D D D D D D D Application F F F F F F Practical system-oriented IT architecture Application Application ERP MES IoT-Platform Other System D OT D OT D F F D Broker F F D D Broker F D D Broker Figure 2: Compared to a traditional, evolved IT architecture (in which systems with EDA already create their own data ecosystems), the event-driven architecture clearly separates relevant data and systemic functions in the enterprise for improvedmodularization. This is where event-driven architecture (EDA for short) comes into play. It is characterized by a rethinking of the communication between systems. Instead of traditional 1:1 interfaces between two systems, which exchange their commands, requests, and responses via specific protocols and data formats, in an EDA, status changes (= events) are exchanged in a centralized manner. Systems communicate withone intermediary systemonly, thebroker, and informitof any relevant events as soon as they occur. Systems interested in these events connect to the broker and receive the necessary data in real time. Instead of requesting information directly from systems via transactions, the broker responds to centrally available and system-independent information. The key idea is that each system is connected to the broker only and does not “know” the other systems at all. It is not necessary to know the protocols, data formats, and mechanisms of the systems from which information is required. In this architecture, only the data that is provided centrally, in real time, and a uniformly defined data schema is important. Technically speaking, a system therefore only needs to implement the connection to thebroker inorder tobe able to react to any event in the entire company. For example, if a machine publishes the event “operation completed” and attaches the necessary data points (e.g., machine ID, job number, and process data), the event can be processed both by an MES – to complete the job – and simultaneously by a maintenance system – to detect whether maintenance is required. The published event requires no addressees and can be processed by any number of receivers; none of the systems need to implement an interface other than that to the broker, or even “know” the other systems. This systemic and semantic independence results in unprecedented data availability and, in particular, the flexibility required by Industrie 4.0. Event-drivenarchitectures arenot agroundbreaking innovation. In software development, they have been an integral part of highlyreactive,modularsystemssincethebeginningofpowerful
RkJQdWJsaXNoZXIy NzcyMw==