AP2 + AP3: Referenzarchitektur

AP2 + AP3: Referenzarchitektur

18.03.2014 Seite 1 itsowl-iv/ap2_3/1.0 it s OWL Intelligente Technische Systeme OstWestfalenLippe CQP 3 Intelligente Vernetzung (itsowl-iv) AP 2 Selbstkonfiguration und Protokolle auf Anwendungsebene / AP 3 Konnektivität und Middleware REFERENZARCHITEKTUR Referenz: Kategorie: Verantwortlich: Autoren: Abgabedatum: itsowl-iv/ap2_3/1.0 Dokument init L. Dürkop (init), H. Trsek (init), U. Mönks (init), J. Otto (IOSB-INA), K. Nußbaum (IOSB- INA), Uwe Pohlmann (IPT-EM), Christian Wördehoff (CITEC), Johannes Ax (CITEC), Jan Jatzkowski (C-LAB) M18 Datum: 18.03.2014 Projektstart: 01.07.2012 Projektdauer: Status: Verfügbarkeit: 60 Monate Ver. 1 (Work-in-Progress) itsowl Spitzencluster

18.03.2014 Seite 2 itsowl-iv/ap2_3/1.0 Executive Summary Dieses Dokument beschreibt die Referenzarchitektur des Clusterquerschnittsprojektes (CQP) Intelligente Vernetzung in Bezug auf die Kommunikation. Als Ausgangspunkt dienen die Anforderungen, die im Rahmen des Arbeitspaketes 1 des CQP Anforderungen und Referanzanwendungen identifiziert wurden. Es hat sich gezeigt, dass die Innovationsprojekte von diesem Querschnittsprojekt insbesondere Lösungsansätze und Transferleistungen in den Bereichen Rekonfigurierbarkeit, Selbstkonfiguration sowie Sensor- und Informationsfusion erwarten. Diese Herausforderungen werden im QP-IV durch verschiedene Funktionsblöcke gelöst. In der Referenzarchitektur werden diese Blöcke sowie die Schnittstellen zwischen ihnen definiert. Jeder der Blöcke ist innerhalb der Referenzarchitektur auf einer Ebene eines 3-Schicht-Modells angesiedelt. Die einzelnen Ebenen sind: Anwendungsebene In dieser Ebene ist die eigentliche Funktionalität eines intelligenten technischen Systems (ITS) in Form von rechnerausführbaren Softwarekomponenten angeordnet. Es wird davon ausgegangen, dass es in einem Netzwerk mehrere ITS gibt, die miteinander kommunizieren müssen. Hier liegt der Beitrag dieses CQPs darin, dass der Entwurf der Software unabhängig von der später zu verwendenden Netzwerktechnologie erfolgen kann. Stattdessen definiert der Entwickler der Software Anforderungen an die Kommunikationsschnittstelle. Die Referenzarchitektur sieht beispielsweise Anforderungen an die Sicherheit und die Transportgüte vor. Weiterhin müssen den auszutauschenden Daten semantische Informationen hinzugefügt werden. Middleware Die Middleware erfüllt hauptsächlich zwei Aufgaben. Zum einen vergleicht sie die Kommunikationsanforderungen der Anwendung mit den zur Verfügung stehenden Netzwerktechnologien und wählt für die Daten einen entsprechenden Übertragungskanal. Erfordert der Kanal zur Inbetriebnahme eine Konfiguration (z.b. Echtzeit-Ethernet), wird diese durch die Middleware durchgeführt. Des Weiteren stellt die Middleware die logischen Kommunikationsbeziehungen zwischen den verschiedenen ITS her. Dazu prüft sie die semantischen Informationen der im Netz vorhandenen Anwendungen und vermittelt bei Übereinstimmung die Daten zwischen ihnen. Konnektivität Diese Ebene kapselt die Funktionalität der verschiedenen Netzwerktechnologien und stellt sie der Middleware mit einer einheitlichen Schnittstelle zur Verfügung. Dadurch kann die Implementierung der Anwendungsebene und der Middleware technologieunabhängig erfolgen. Die Referenzarchitektur und die dort festgelegten Schnittstellen sind die Grundlage für die Umsetzung der einzelnen Funktionsblöcke in den Arbeitspaketen 2 und 3.

18.03.2014 Seite 3 itsowl-iv/ap2_3/1.0 Änderungsnachweis Versionen Version Status Datum Autor(en) 0.1 Entwurf 21.06.2013 H. Trsek, U. Mönks 0.2 Entwurf 26.06.2013 K. Nußbaum, U. Pohlmann 0.21 Entwurf 03.07.2013 J. Otto 0.3 Entwurf 11.07.2013 C. Wördehoff 0.31 Entwurf 01.10.2013 J. Jatzkowski 0.4 Entwurf 25.10.2013 L. Dürkop, J. Ax 0.41 Entwurf 25.11.2013 U. Pohlmann 0.5 Entwurf 24.01.2014 L. Dürkop, H. Trsek 1.0 Intern 05.02.2014 H. Trsek Änderungen Version Kapitel Zusammenfassung der Änderungen 0.1 Erste Gliederung gemäß Dokumentstruktur Diskussion des Gesamttreffens am 13.06. 0.2 2.4.1 Inhaltliche Überarbeitung, Echtzeitkommunikation integriert 0.21 2.1, 2.2.2 und Kapitel 2.3 Architekturentwurf, Selbstbeschreibungsfähigkeit und Middleware 0.3 2.2.2 Transport 0.31 2.3.4 Allgemeine Routing-Beschreibung und itsowl-iv bezogene Routing-Beschreibung 0.4 2 Referenzarchitektur näher beschrieben, Kapitel 3 komplett umstrukturiert 0.41 2.2 Anwendungsarchitektur integriert 0.5 Alle Integration Management Summary, Einleitung, Zusammenfassung; finale Überarbeitung 1.0 Alle Review Kommentare der Lenkungskreismitglieder integriert

18.03.2014 Seite 4 itsowl-iv/ap2_3/1.0 Inhaltsverzeichnis 1 Einleitung... 7 2 Architekturkonzept für die Intelligente Vernetzung... 9 2.1 Referenzarchitektur... 9 2.2 Anwendungsebene... 10 2.2.1 Anwendungsarchitekturbeschreibung durch Softwarekomponenten... 10 2.2.2 Syntaktische Schnittstellenbeschreibung... 11 2.2.3 Semantische Schnittstellenbeschreibung... 12 2.2.3.1 Semantische Bedeutung... 12 2.2.3.2 QoS-Anforderungen... 13 2.3 Middleware... 14 2.3.1 Zuordnungs-Dienst... 14 2.3.2 Discovery... 16 2.3.3 Sicherheit... 17 2.3.4 Routing... 18 2.3.4.1 Routing allgemein... 18 2.3.4.2 Routing innerhalb der Middleware... 19 2.4 Konnektivitätsebene... 20 2.4.1 Echtzeitkommunikation... 21 2.4.2 Bedarfskommunikation... 22 2.4.3 Inter-Layer-Kommunikation... 22 2.4.3.1 Kommunikation... 23 2.4.3.2 Konfiguration und Monitoring auf Transportebene... 24 2.4.3.3 Konfiguration und Monitoring auf Systemebene... 24 2.4.4 Automatische Protokollerkennung... 25 3 Praktische Anwendungen der Referenzarchitektur... 28 3.1 Anwendungsbeispiel 1 Dynamische Konfiguration in der industriellen Automatisierungstechnik... 28 3.1.1 Teil 1: Semantische Selbstbeschreibung der SPS-Anwendung... 30 3.1.2 Teil 2: Zuordnungsdienst und Discovery... 32 3.1.3 Teil 3: Routing/Autokonfiguration Echtzeit-Ethernet... 33 3.2 Anwendungsbeispiel 2 Einwicklung eines verteilt gesteuerten Automatisierungsprozesses mit autonomen Fahrzeugen... 35 3.2.1 Beschreibung der Softwarestruktur durch Komponentenmodelle... 35 3.2.2 Koordinationsbeschreibung durch Echtzeitkoordinationsprotokolle... 37 4 Zusammenfassung... 39 Literaturverzeichnis... 40

18.03.2014 Seite 5 itsowl-iv/ap2_3/1.0 Abbildungsverzeichnis Abbildung 1.1: Schichtenmodell der Intelligenten Vernetzung... 7 Abbildung 2.1: Referenzarchitektur... 10 Abbildung 2.2: Zuordnungs-Dienst der Middleware... 15 Abbildung 2.3: Selbstbeschreibung einer Anwendung... 16 Abbildung 2.4: Beispiel für das universelle Routing... 20 Abbildung 2.5: Kategorisierung der Echtzeitanforderungen... 21 Abbildung 2.6: Transportschnittstelle... 23 Abbildung 2.7: Aufbau eines Transportkanals... 25 Abbildung 2.8: Ethernet-Rahmen nach IEEE 802.3... 26 Abbildung 2.9: Vergleich Rahmenstruktur verschiedener Echtzeitprotokolle... 27 Abbildung 3.1: Schematischer Aufbau einer Automatisierungsanlage... 28 Abbildung 3.2: Automatische Konfiguration eines Automatisierungsprozesses... 30 Abbildung 3.3: Beispiel für einen IEC 61131-3 Funktionsblock... 31 Abbildung 3.4: Auszug aus einer PLCopen XML-Datei... 32 Abbildung 3.5: Auszug aus einer OPC UA XML-Datei... 32 Abbildung 3.6: Beispielhafte Verknüpfung des Zuordnungsdienstes... 33 Abbildung 3.7: Datenfluss der Prozessdaten... 34 Abbildung 3.8: Komponententypdefinition... 36 Abbildung 3.9: Systemtypdefinition... 36 Abbildung 3.10: System Komponenteninstanzkonfiguration... 37 Abbildung 3.11: Systemtypdefinition... 37 Abbildung 3.12: Echtzeit-Zustandsautomaten für das Koordinationsprotokoll Transportation_Request... 38

18.03.2014 Seite 6 itsowl-iv/ap2_3/1.0 Tabellenverzeichnis Tabelle 2-1: Ethertype verschiedener Echtzeitprotokolle... 26

18.03.2014 Seite 7 itsowl-iv/ap2_3/1.0 1 Einleitung Im Rahmen des Clusterquerschnittsprojekts (CQP) Intelligente Vernetzung soll als Bestandteil der clusterweiten Technologieplattform eine Evaluationsumgebung für die intelligente Vernetzung von Intelligenten Technischen Systemen (ITS) entwickelt werden, die anschließend teilweise oder komplett von den Innovationsprojekten (IPs) als Basis für die Umsetzung der dort adressierten Problemstellungen genutzt werden soll. Im ersten Schritt wurde dazu identifiziert, welche Anforderungen die IPs an die intelligente Vernetzung stellen. Dazu wurden im Rahmen des Arbeitspaketes 1 (AP) Anforderungen und Referenzanwendungen umfangreiche Interviews mit den Projektpartnern der einzelnen IPs geführt. Die Analyse hat ergeben, dass die Erwartungen der IPs an das QP-IV in die drei wesentlichen Gruppen Rekonfigurierbarkeit, Selbstkonfiguration sowie Sensor- und Informationsfusion eingeteilt werden können. Die detaillierten Ergebnisse liegen in Form einer strukturierten Anforderungsspezifikation vor [12], die u.a. Referenzanwendungen zur späteren Validierung definiert. Auf Grundlage dieser Anforderungen wird in diesem Dokument eine arbeitspaketübergreifende Referenzarchitektur entwickelt, in der die strukturellen Komponenten eines Intelligenten Technischen Systems festgelegt sind. Diese bilden die Grundlage für alle weiteren Entwicklungen im Clusterquerschnittsprojekt Intelligente Vernetzung. Als Basis für die Referenzarchitektur dient das in Abbildung 1.1 dargestellte 3-Schicht-Modell. Intelligentes Technisches System Anwendung Middleware Sensorik Konnektivität Abbildung 1.1: Schichtenmodell der Intelligenten Vernetzung Die intelligente Vernetzung soll es Entwicklern ermöglichen, sich auf die Funktionalität ihrer Anwendung zu konzentrieren. Derzeit fließt ein großer Anteil des Entwicklungsaufwandes von verteilen Systemen in die Umsetzung der Kommunikation zwischen den Teilnehmern des Systems, die Kommunikation ist hier ein elementarer Bestandteil der Anwendung. An dieser Stelle soll das Clusterquerschnittsprojekt ansetzen: Die komplette Kommunikation soll durch die Funktionen der intelligenten Vernetzung gekapselt werden. Dem

18.03.2014 Seite 8 itsowl-iv/ap2_3/1.0 Anwendungsentwickler werden dafür standardisierte Funktionen zur Verfügung gestellt, die alle Details des netzwerkgestützten Datenaustausches intern steuern. Die Interaktion zwischen Anwendung und intelligenter Vernetzung besteht im Idealfall nur noch aus dem Austausch der zu übermittelnden Daten. In der Referenzarchitektur ist weiterhin vorgesehen, dass die Anwendung ihre Kommunikationsanforderungen definiert und den Vernetzungsmethoden mitteilt. So könnte beispielsweise eine Anwendung zur Prozesssteuerung ihre Anforderungen in Bezug auf Zykluszeiten der Prozessdaten definieren. Die intelligente Vernetzung wird daraufhin eine geeignete Netzwerktechnologie wählen (sofern verfügbar) und diese so konfigurieren, dass die Daten in der geforderten Zykluszeit ausgetauscht werden können. Eine weitere wichtige Herausforderung an die intelligente Vernetzung ist es, dass diese die Kommunikationsbeziehungen zwischen den verteilten Teilnehmern automatisiert aufbauen kann. So soll der Entwickler in die Lage versetzt werden, eine verteilte Anwendung zu schreiben, ohne zum Entwicklungszeitpunkt zu wissen, welche konkreten physikalischen Geräte zur Laufzeit in dem verteilten System vorhanden sind. Zu diesem Zweck wird es nötig sein, Anwendungen durch semantische Beschreibungen zu ergänzen. Als Grundlage zur Verwirklichung dieser Ziele werden in der Referenzarchitektur grundsätzliche Funktionalitäten definiert und diese in den drei Schichten Anwendung, Middleware und Konnektivität angesiedelt. Zusätzlich werden die Schnittstellen zwischen den einzelnen Schichten definiert. Dieses Dokument bildet damit eine wichtige Arbeitsgrundlage für alle Partner des CQPs und definiert eine gemeinsame Sichtweise innerhalb des Konsortiums. Weiterhin wird durch die Referenzarchitektur festgelegt, welche Schnittstellen die Funktionsblöcke der einzelnen Partner zueinander aufweisen müssen. In Kapitel 2 dieses Dokuments werden die Referenzarchitektur und ihre einzelnen Funktionsblöcke vorgestellt, in Kapitel 3 werden beispielhafte Implementierungen der Architektur beschrieben. Das Dokument schließt mit einer Zusammenfassung in Kapitel 4. Die Sensorik wird als eine beispielhafte Anwendung auf der Grundlage der Referenzarchitektur umgesetzt, daher ist sie noch kein Teil dieses Dokumentes.

18.03.2014 Seite 9 itsowl-iv/ap2_3/1.0 2 Architekturkonzept für die Intelligente Vernetzung Abgeleitet aus der im Arbeitspaket 1 erstellten Anforderungsspezifikation wird in diesem Kapitel die Referenzarchitektur des Clusterquerschnittsprojektes Intelligente Vernetzung definiert. Diese Architektur soll es ermöglichen, technische Systeme zu erstellen, die Lösungen für die in AP1 analysierten Herausforderungen wie Rekonfigurierbarkeit und Selbstkonfiguration anbieten. In Kapitel 2.1 wird die allgemeine Referenzarchitektur vorgestellt und anschließend werden in den Kapiteln 2.2 bis 2.4 die einzelnen Architekturelemente näher beschrieben. 2.1 Referenzarchitektur Die Referenzarchitektur in Abbildung 2.1 beruht auf dem bereits im Projektantrag vorgestellten 3-Schicht Modell. Umgesetzt und realisiert wird die Architektur in sogenannten intelligenten Knoten, die abgeschlossene physikalische Einheiten bilden. Auf der obersten Ebene der Architektur steht die Anwendung. Diese stellt dabei die eigentliche Funktionalität des Knotens dar. Für ihre Funktion ist sie darauf angewiesen, mit anderen Anwendungen auf verschiedenen Knoten zu kommunizieren. Im Gegensatz zu bisherigen Ansätzen ist der Anwendung zum Entwurfszeitpunkt aber noch nicht bekannt, mit welchen physikalischen Einheiten sie kommunizieren wird. Auch ist es im Hinblick auf das Ziel der automatischen Konfiguration nicht wünschenswert, dass die Kommunikationsbeziehungen zwischen mehreren Knoten manuell von einem menschlichen Benutzer eingerichtet werden. Alle Komponenten der Referenzarchitektur, die im Folgenden beschrieben werden, haben daher zum Ziel, einen konfigurationslosen Austausch von Informationen zwischen verschiedenen Anwendungen zu ermöglichen.

18.03.2014 Seite 10 itsowl-iv/ap2_3/1.0 Softwarekomponente Anwendung Syntaktische Schnittstellenbeschreibung (Benötigt / Angebotene) Zyklische Prozessdaten - Name - Datentyp - Periode Asynchrone Nachrichten - Name - Parameter - Name - Datentyp Koordinationsprotokolle Semantische Schnittstellenbeschreibung Bedeutung QoS-Anforderungen Zuordnungsdienst Discovery Informationsmodell Middleware Sicherheit Verschlüsselung Integrität Identifizierung Routing Konnektivität Transportblock 1 Transportblock 2 Transportblock n Transportmanager Ad-hoc Konfigurationskanal 2.2 Anwendungsebene Abbildung 2.1: Referenzarchitektur Diese Ebene beinhaltet die eigentliche Funktionalität des intelligenten Knotens. Der Fokus dieses Projektes liegt auf Anwendungen, welche zur Laufzeit Daten und Nachrichten mit anderen Anwendungen oder Anwendungsteilen austauschen. 2.2.1 Anwendungsarchitekturbeschreibung durch Softwarekomponenten Die Anwendungen für intelligente technische Systeme werden aufgrund steigender Funktionalität und größerer Vernetzung komplexer. Um die Komplexität der Anwendung von intelligenten vernetzten Systemen handhabbar zu machen, kann die Anwendung in Komponenten unterteilt werden. Komponenten werden sowohl benutzt, um Anwendungen zu untergliedern, als auch um verschiedene Anwendungen zu repräsentieren. Abbildung 2.1 zeigt im Bereich Anwendung eine solche Softwarekomponente. Eine Komponente hat eine starke Kohäsion. Kohäsion wird hierbei als Maß für die Zusammengehörigkeit der Bestandteile einer Komponente benutzt. Eine

18.03.2014 Seite 11 itsowl-iv/ap2_3/1.0 Komponente stellt eine Anwendungseinheit für eine wohldefinierte logische Aufgabe dar. Eine Komponente kapselt ihre innere Struktur und ihr Verhalten, sodass ihre Funktionalität nur über die definierten Schnittstellen, die so genannten Ports, nutzbar ist. Aufgrund der Kapselung lässt sich eine Komponente durch eine andere Komponente mit gleicher Schnittstelle und ähnlicher Funktionalität auswechseln ohne das Gesamtsystem zu beeinflussen. Es wird zwischen strukturierten und atomaren Komponenten unterschieden. Strukturierte Komponenten werden zusammengesetzt aus atomaren Komponenten. Eine atomare Komponente enthält direkt eine Verhaltensbeschreibung. Komponenten verfügen über klar definierte Schnittstellen, so genannte Ports, zu anderen Komponenten auf dem gleichen System oder auf anderen Systemen. Ports werden miteinander verbunden, um anzuzeigen, dass eine Kommunikation zwischen den Komponenten über diese Ports zur Laufzeit möglich ist. Die Schnittstellen-/Portbeschreibung unterteilt sich in eine syntaktische Beschreibung und eine semantische Beschreibung. Diese Beschreibungen werden im Folgenden beschrieben. 2.2.2 Syntaktische Schnittstellenbeschreibung Die Art der Kommunikation zwischen zwei oder mehreren Anwendungen kann syntaktische in zwei verschiedene Typen unterteilt werden: (1) Zyklische Kommunikation (Abbildung 2.1, Syntaktische Schnittstellenbeschreibung links) Hier sendet bzw. empfängt die Anwendung Daten über zyklische Ports in regelmäßigen Intervallen. Zyklische Ports übersetzen kontinuierlich vorliegende Messwerte in zeitlich getaktete diskrete Messwerte. Die Zykluszeit wird in der Regel zur Entwicklungszeit festgelegt und ist während des Betriebes konstant. Ein Beispiel für zyklische Daten sind Prozessdaten, die von Sensoren regelmäßig an die Anwendung gesendet werden. (2) Asynchrone Kommunikation (Abbildung 2.1, Syntaktische Schnittstellenbeschreibung rechts) Bei der ereignisgesteuerten bzw. azyklischen Kommunikation werden Nachrichten über asynchrone Ports auf Anforderung bzw. beim Auftreten eines bestimmten Ereignisses gesendet. Asynchrone Kommunikation bedeutet, dass Senderkomponenten nicht blockieren, während sie auf eine Antwort warten. Sie können weiterarbeiten und auf andere eingehende Nachrichten reagieren. Dabei kann auch festgelegt sein, dass Anforderungen nur von bestimmten Knoten innerhalb eines Netzes gestellt werden dürfen. Beispiele für Ereignisse sind Alarme, Fehlermeldungen oder allgemeine Benachrichtigungen. Nachrichten sind nicht die Information die Komponenten einander übermitteln, sondern sind Träger von Informationen. Jede Nachricht verfügt über einen festgelegten Typen der die mitgelieferten Daten beschreibt. Daten können nur über festgelegte Nachrichten, welche Ports zugeordnet sind übertragen werden. Zur Laufzeit können keine Nachrichtentypen zu Ports hinzugefügt oder gelöscht werden. Es sind nur die Nachrichtentypen bekannt, die während des Entwurfs spezifiziert wurden. Für Ports werden zum Zeitpunkt der Systemerstellung Nachrichtenobjekte zum in der Middleware zum Senden und zum Empfangen erstellt. Abhängig von der Spezifikation des Anwendungsentwicklers wird entweder wird für jeden Nachrichtentyp ein Nachrichtenobjekt angelegt oder für alle an einem Port referenzierten Typen zusammen ein Nachrichtenobjekt. Nachrichtenobjekte können beim Senden direkt übertragen werden oder gepuffert werden. Nachrichten aus dem

18.03.2014 Seite 12 itsowl-iv/ap2_3/1.0 Sendepuffer können periodisch übertragen werden. Dies kann z.b. bei Übertragungskanälen, welche nur in festgelegten Zeitschlitzen zur Verfügung stehen notwendig sein. Ankommende Nachrichten werden in einen Empfangspuffer abgelegt. Neben den reinen Nachrichten, die Anwendungen miteinander austauschen, sind die Nachrichtenreihenfolgen und Zeitabstände zwischen den Nachrichten entscheidend, damit Anwendungen kooperieren können. Zur Spezifikation der asynchronen Nachrichtenkommunikation können die sogenannten Koordinationsprotokolle eingesetzt werden. Diese definieren für jeweils zwei Kommunikationsteilnehmer (Rollen genannt) in welcher Reihenfolge und zu welchen Zeitpunkten welche Nachrichten gesendet bzw. empfangen werden können. Diese Spezifikation des Rollenverhaltens wird abstrahiert von ihrer späteren Ausführungsplattform, durchgeführt. 2.2.3 Semantische Schnittstellenbeschreibung Die syntaktische Schnittstellenbeschreibung legt nicht fest, welches die physikalischen Kommunikationspartner der Softwarekomponenten sind und über welche Technologie der Datenaustausch erfolgt. Dies wird von der Middleware übernommen. Damit diese die entsprechenden Zuordnungen treffen kann, müssen die Softwarekomponenten durch die im Folgenden genannten Informationen semantisch beschrieben werden. 2.2.3.1 Semantische Bedeutung Die in der Anwendungsebene beschriebenen Softwarekomponenten incl. ihrer Ports und Konnektoren sind unabhängig von den unterliegenden Schichten. Alle Komponenten kommunizieren über einen virtuellen bzw. logischen Bus. Dieser logische Bus ist unabhängig von der zugrundeliegenden Hardwareinfrastruktur. Während der Konfiguration des Gesamtsystems werden die Verbindungen des logischen Busses auf lokale Mechanismen (falls sich die miteinander kommunizierenden Softwarekomponenten auf demselben intelligenten Knoten befinden) oder auf netzwerkspezifische Systeme (wie z.b. ein Feldbussystem) abgebildet. D.h. bei der Entwicklung der Softwarekomponenten ist es für den Entwickler völlig transparent, über welche Verbindungen diese Komponenten später tatsächlich kommunizieren. Ein Ziel dieses Querschnittsprojektes ist es, die Inbetriebnahme und Rekonfiguration von vernetzten Systemen mit möglichst geringen manuellem Konfigurationsaufwand zu ermöglichen. Die Definition der Kommunikationsbeziehungen zwischen verschiedenen Anwendungen spielt dabei die Hauptrolle. Die Datenquellen und senken in einem verteilten System auf Anwendungsebene müssen manuell von einem Benutzer eingerichtet werden. So muss beispielsweise die Verknüpfung zwischen einer Anwendung, die bestimmte Informationen in ihrem Programmablauf erwartet, und der Anwendung, die diese Information bereitstellt, hergestellt werden. Die Komplexität dieser Aufgabe ist abhängig vom verwendeten Kommunikationssystem. Es wird bei der Kommunikation zwischen interner und externer Kommunikation unterschieden. Die interne Kommunikation findet ohne Beteiligung der

18.03.2014 Seite 13 itsowl-iv/ap2_3/1.0 Konnektivitätsschicht statt. Nachdem die Nachricht vom Sender in der Anwendungsebene zum Senderobjekt in der Middleware übertragen wurde, wird diese direkt dem Empfangsobjekt in der Middleware zur Verfügung gestellt. Bei der externen Kommunikation benutzt die Middleware die Konnektivitätsschicht. Für die Anwendungsebene ist dieser Prozess nicht sichtbar. Für sie werden während der Laufzeit externe Nachrichten, genau wie interne Nachrichten gehandhabt. Nur während der Konfiguration wird der Middleware von der Anwendungsschicht mitgeteilt, welche Ports der Softwarekomponenten miteinander verbunden sind. Um die Konfiguration zu automatisieren, ist es notwendig, dass die Anwendung semantische Informationen über ihre Ein- und Ausgangsdaten der Middleware bereitstellt. Der Zuordnungs-Dienst vergleicht dann die angebotenen und benötigten Prozessdaten und Nachrichten aller Anwendungen und verbindet diese bei Übereinstimmung. Die Grundvoraussetzung für diese Vorgehensweise ist ein einheitlicher Formalismus zur Beschreibung der Schnittstellen. Dieser Formalismus umfasst zum einen die Beschreibungssprache, die von der Middleware ausgewertet werden kann, und zum anderen die inhaltlichen Aspekte, bei denen die Daten, Nachrichten und Protokoll in Form und Funktion semantisch beschrieben werden. Der Umfang dieser Beschreibung soll es ermöglichen, dass die Abhängigkeiten von Daten, Nachrichten und Protokollen automatisiert gefunden werden können. So kann es z.b. notwendig sein, die Ortsinformation eines Knotens (als Lage im Raum oder als Knoten in einer Netzwerktopologie) der semantischen Beschreibung hinzuzufügen. Eine globale einheitliche Semantik zu definieren, ist aufgrund der Komplexität dieses Vorhabens und den verschiedenen Anforderungen aus unterschiedlichen Domänen nicht möglich. Daher muss man sich auf bestimmte Domänen, wie z.b. die Automatisierungstechnik, beschränken. Auch durch den Einsatz der semantischen Selbstbeschreibung fällt die Notwendigkeit des manuellen Konfigurationsaufwandes nicht weg er wird allerdings verlagert in die Entwicklungsphase der Anwendung bzw. eines intelligenten Knotens. Durch Modularisierung und Wiederverwendung von Komponenten ist es häufig nur einmalig nötig, die benötigten Beschreibungsdaten zu erstellen. So kann ein intelligenter Knoten, der z.b. als Temperatursensor dient, unabhängig vom späteren Einsatz beschrieben werden. 2.2.3.2 QoS-Anforderungen Je nach Anwendung werden unterschiedliche Anforderungen an den Transport der Nutzdaten gestellt. So kann z.b. für Prozessdaten eine maximale Zykluszeit oder ein maximaler Jitter definiert sein. Für asynchrone Nachrichten wie Alarme ist die maximale Verzögerung zwischen dem Zeitpunkt der Alarmerstellung und dem Eintreffen beim Empfänger wichtig. Weitere Beispiele sind eine garantierte Datenübertragungsrate oder Mindestanforderungen an die Zuverlässigkeit, was z.b. durch eine maximal zulässige Paketverlustrate oder Bitfehlerhäufigkeit quantifiziert werden kann. Der Anwendungsentwickler muss diese Anforderungen an die Transportgüte für die konkrete Anwendung spezifizieren. Hierfür benötigt er eine standardisierte Schnittstelle zur Middleware. Diese soll eine feine Granularität erlauben, sodass für unterschiedliche Daten verschiedene Anforderungen definiert werden können. Die

18.03.2014 Seite 14 itsowl-iv/ap2_3/1.0 Middleware prüft anschließend unter Berücksichtigung der zur Verfügung stehenden Transportblöcke, ob die Transportgüte eingehalten werden kann oder konfiguriert alternativ die Transportblöcke den Anforderungen entsprechend. Dabei kann es sich um rekonfigurierbare Transportblöcke handeln, die die Möglichkeiten bieten, verschiedene Netzwerktechnologien zu unterstützen. Die Middleware würde dann die Technologie auswählen, die am besten mit den Anforderungen übereinstimmt. Dieses Verfahren ist auch möglich, wenn der Middleware mehrere statische Transportblöcke zur Verfügung stehen, die aber jeweils einer anderen Technologie angehören. Steht kein Transportblock zur Verfügung, der die Anforderungen erfüllt, gibt die Middleware eine Fehlermeldung an die Anwendung zurück, welche dann über Alternativstrategien entscheiden muss. Die üblichen Sicherheitsmaßnahmen, insbesondere im Umfeld der industriellen Automatisierungstechnik, beruhen auf der Abschottung eines Netzes gegenüber der Außenwelt, z.b. mit Firewalls. Die Komponenten innerhalb eines Netzes werden dabei als vertrauenswürdig angesehen. Dieser Ansatz greift im Rahmen der intelligenten Vernetzung allerdings zu kurz. Ein Ziel dieses Querschnittsprojektes ist es, eine möglichst einfache Vernetzung intelligenter Knoten über unterschiedliche Transporttechnologien und auch über räumlich getrennte Standorte zu realisieren. Eine Trennung bestimmter Netze von der Außenwelt wird durch diese Zielsetzung erschwert. Auch hilft eine Abschottung eines Netzes nicht gegen Angriffe von innen. Diese können z.b. durch Personen initiiert werden, die physikalischen Zugriff auf das Netz haben wie eigene Mitarbeiter oder Mitarbeiter von Fremdfirmen. Es ist weiterhin möglich, dass eine Firewall von außen durchbrochen wird. Ohne innere Sicherheitsmaßnahmen kann der Angreifer dann uneingeschränkten Zugriff auf das Netz erhalten. Um solche Angriffe zu erschweren, werden in diesem Projekt dem Anwender Möglichkeiten gegeben, um Anforderungen der Anwendung im Hinblick auf Verfügbarkeit, Integrität und Vertraulichkeit zu definieren. Die Umsetzung dieser Punkte liegt dann im Aufgabenbereich der Middleware und wird dort näher beschrieben. 2.3 Middleware Die grundlegende Aufgabe der Middleware ist es, einen Austausch von Nutzdaten zwischen Anwendungen zu ermöglichen, wobei die Auswahl der Kommunikationstechnologie und die Adressierung zur Laufzeit von der Middleware übernommen werden. Die einzelnen Komponenten der Middleware werden im Folgenden beschrieben. 2.3.1 Zuordnungs-Dienst Der Zuordnungs-Dienst der Middleware adressiert das Problem, die Nutzdaten verschiedener Anwendungen miteinander zu verbinden. Der prinzipielle Ablauf des Zuordnungs-Vorganges ist anhand eines vereinfachten Beispiels in Abbildung 2.2 dargestellt.

18.03.2014 Seite 15 itsowl-iv/ap2_3/1.0 Anwendung 1 Information A Anwendung benötigt Information B Information C Zuordnungs-Dienst Semantische Selbstbeschreibung A: Typ Temperatur B: Typ Druck C: Typ Helligkeit Intelligenter Knoten 1 A ( Temperatur ) B ( Druck ) C ( Helligkeit ) D ( Temperatur ) @ Knoten 2 E ( Helligkeit ) @ Knoten 2 F ( Druck ) @ Knoten 3 Discovery Ad-hoc Kommunikationkanal Anwendung 2 Anwendung 3 Anwendung liefert Semantische Selbstbeschreibung Anwendung liefert Semantische Selbstbeschreibung Information D Information E D: Typ Temperatur E: Typ Helligkeit Information F F: Typ Druck Intelligenter Knoten 2 Intelligenter Knoten 3 Abbildung 2.2: Zuordnungs-Dienst der Middleware Auf dem intelligenten Knoten 1 läuft eine Anwendung, die für ihre Funktion die drei Informationen A, B und C von anderen Anwendungen benötigt. Mit Hilfe der semantischen Selbstbeschreibung legt der Entwickler der Anwendung fest, um welche Art von Informationen es sich handelt. Im Beispiel werden dafür die Typen Temperatur, Druck und Helligkeit definiert. Wird die Anwendung des intelligenten Knotens 1 gestartet, überträgt sie ihre semantische Selbstbeschreibung an den Zuordnungs-Dienst. Der Discovery-Service, der auf demselben Knoten wie die Anwendung und der Zuordnungs-Dienst realisiert ist, fragt über den ad-hoc Konfigurationskanal die semantischen Beschreibungen aller anderen intelligenten Knoten ab und überträgt diese an den Zuordnungs-Dienst. Dieser überprüft, ob es zwischen den Beschreibungen von Knoten 1 und den anderen Knoten Übereinstimmungen gibt. Im Erfolgsfall ist dem Zuordnungs-Dienst nun bekannt, welche Knoten die Informationen liefern, die seine übergeordnete Anwendung benötigt. Die Voraussetzung für einen erfolgreichen Zuordnungs-Dienst ist das zugrundeliegende Informationsmodell, mit welchem die Informationen der Knoten modelliert werden. Eine beispielhafte Modellierung ist in Abbildung 2.3 gezeigt. Dort

18.03.2014 Seite 16 itsowl-iv/ap2_3/1.0 wird von Anwendungen ausgegangen, die entweder bestimmte Variablen benötigen oder anbieten. Die Variablen werden zur Selbstbeschreibung in Signalklassen eingeteilt. Im Beispiel stellt die Anwendung des intelligenten Knotens A (IK A) eine Variable namens Y bereit, die der Signalklasse Status angehört. Dazu passend benötigt die Anwendung des Knotens B eine Variable X derselben Signalklasse. Der Zuordnungs-Dienst stellt eine Übereinstimmung der Signalklassen fest und ordnet Variable Y der Variablen X zu. Abbildung 2.3: Selbstbeschreibung einer Anwendung Im Beispiel in Abbildung 2.2 wird ein Modell benutzt, in dem nur die physikalischen Größen der Informationen angegeben sind. Allerdings kann in beiden Beispielen keine eindeutige Zuordnung mehr getroffen werden, wenn mehrere Informationen derselben physikalischen Größe (Beispiel 1) oder mehrere Variablen derselben Signalklasse (Beispiel 2) vorhanden sind. In diesen Fällen muss eine Ersatzstrategie greifen, in der z.b. der Benutzer die Zuordnungen manuell treffen muss. Umso umfangreicher das Informationsmodell ist, desto seltener tritt dieser Fall ein. Die Entwicklung eines Informationsmodells für verschiedene Domänen ist eine der zukünftigen Aufgaben dieses Querschnittprojektes. Zum Beispiel könnte das Modell die Ortsinformation eines Knotens berücksichtigen. Steuert die Anwendung des Knotens 1 einen Heizprozess und benötigt zur Überwachung die Temperatur, ist es am wahrscheinlichsten, dass bei mehreren in Frage kommenden Knoten derjenige die gesuchte Information bietet, der sich in geringster Entfernung zu Knoten 1 befindet. Ob dies ein praktikables Vorgehen ist, muss allerdings näher untersucht werden, da fehlerhafte Zuordnungen insbesondere bei sicherheitskritischen Anwendungen ausgeschlossen werden müssen. Ein Beispiel für ein Informationsmodell in der Domäne der industriellen Automatisierungstechnik stellt mina-dl [4] dar. Zur Implementierung eines Modells bietet sich der Standard OPC UA [5] an, der komplexe Methoden zur Modellierung von Informationen und gleichzeitig zu deren Übertragung anbietet. 2.3.2 Discovery Der Discovery-Dienst der Middleware ist dafür zuständig, die intelligenten Knoten in einem Netz und ihre semantischen Eigenschaften zu erkennen. Für die Realisierung gibt es die Möglichkeit, eine zentrale Instanz des Dienstes pro Netz einzurichten, welche die Informationen über alle Knoten sammelt. Alternativ kann der Dienst verteilt realisiert werden. In diesem Fall ist jeder Knoten selber dafür zuständig, die notwendigen Informationen über andere Knoten zu sammeln.

18.03.2014 Seite 17 itsowl-iv/ap2_3/1.0 In beiden Fällen wird ein ad-hoc Konfigurationskanal vorausgesetzt, über den die Knoten entweder untereinander oder die Knoten mit der zentralen Discovery-Instanz kommunizieren können. Bei diesem Kanal handelt es sich um einen logischen, sich selbst-konfigurierenden Kanal, der allen Knoten zumindest beim Systemhochlauf zur Verfügung steht. Die Realisierung des ad-hoc Kanals ist abhängig von der eingesetzten Discovery-Technologie. Basiert letztere beispielsweise auf TCP/IP, muss eine IP-Kommunikation möglich sein, ohne dass der Benutzer die IP- Parameter manuell vorgibt. Dies kann beispielsweise durch DHCP (automatische Adressvergabe durch eine zentrale Instanz) oder Zeroconf (jeder Knoten wählt seine IP-Adresse aus einem vorgegebenen Subnetz selbst) gelöst werden. Sollen andere Netzwerktechnologien wie CAN eingesetzt werden, ist der Einsatz eines Gateways erforderlich, damit die CAN-Knoten auch über IP erreichbar sind. Der ad-hoc Kanal wird nur für Zwecke der Konfiguration im Rahmen des Discovery-Prozesses genutzt. Die Nutzdaten werden über andere logische Kanäle übertragen, die sich jedoch zusammen mit dem ad-hoc Kanal dasselbe physikalische Medium teilen können. Für die Implementierung des Discovery-Dienstes bieten sich Techniken an, die neben dem dynamischen Erkennen von Knoten auch den Austausch von Gerätebeschreibungen unterstützen. Beispiele für bereits bestehende Technologien sind DPWS [6] und OPC UA [5]. Beide Verfahren bieten Möglichkeiten zur Implementierung der notwendigen semantischen Selbstbeschreibung. 2.3.3 Sicherheit Diese Komponente der Middleware setzt die Sicherheitsanforderungen der Anwendungsebene um. Ziel ist es, Eingriffe von Angreifern in die Kommunikation zwischen intelligenten Knoten zu erkennen und zu verhindern. Der Schutz der IT- Infrastruktur gegen Angriffe von außen oder gegen die Infektion durch Schadsoftware liegt nicht im Fokus dieses Projektes. Stattdessen wird davon ausgegangen, dass ein Angreifer bereits Zugriff auf das Kommunikationsnetzwerk erlangt hat. Die Anforderungen an Sicherheit auf Kommunikationsebene können in zwei Bereiche aufgeteilt werden: Integrität Ein Angreifer kann falsche Nutzdaten in das Netzwerk einschleusen. Bei der Steuerung von physikalischen Prozessen kann dies im Extremfall zu Sach- oder Personenschäden führen. Verschlüsselung Die Nutzdaten, die zwischen den Knoten ausgetauscht werden, können sensible Informationen enthalten. Wenn ein Angreifer diese Informationen abfängt, kann er beispielsweise Rückschlüsse auf die Prozessabläufe oder andere Geschäftsgeheimnisse erlangen. Die beiden Anforderungen Integrität und Verschlüsselung können durch den Einsatz kryptographischer Verfahren sichergestellt werden. Zur Wahrung der Integrität bietet sich ein asymmetrisches Kryptoverfahren wie RSA an. Dabei kann die Middleware des sendenden Knotens die Nutzdaten mit einer digitalen Signatur versehen. Zur

18.03.2014 Seite 18 itsowl-iv/ap2_3/1.0 Sicherstellung der Authentizität der digitalen Signatur bietet es sich bei räumlich begrenzten Systemen an, dass ein zentraler Benutzer ein Schlüsselpaar zur Signierung der Daten für jeden Knoten erzeugt und dieses Paar mit einem zentralen privaten Schlüssel zertifiziert. Jeder Knoten kann dann beispielsweise eine SD-Karte erhalten, auf der das Schlüsselpaar des jeweiligen Knoten und der zentrale öffentliche Signierungsschlüssel gespeichert sind. Mit diesem Verfahren kann sichergestellt werden, dass keine Signaturen akzeptiert werden, die von einem Angreifer erstellt worden sind. Für die Verschlüsselung können asymmetrische Schlüsseltauschverfahren wie der Diffie-Hellmann-Schlüsseltausch verwendet werden. Diese Verfahren sind nicht mehr anwendbar, wenn ein Angreifer die Kontrolle über einen intelligenten Knoten übernimmt und Zugriff auf den privaten Schlüssel erlangt. Dies geschieht in der Regel durch Software-Sicherheitslücken. In einem weiteren Szenario könnte ein Angreifer Kontrolle über den Entwicklungsrechner erlangen, in dem die Anwendung für einen intelligenten Knoten erstellt wird und seinen Schadcode direkt in die Anwendung einfügen (Beispiel: Stuxnet). Die Abwehr und Prävention solcher Angriffe sind nicht Aspekt dieses Projekts. Ein weiterer Sicherheitsaspekt sind Angriffe auf die Verfügbarkeit. Beispielsweise können durch Attacken wie z.b. das Fluten eines Netzes mit Paketen die Kommunikationsstacks einzelner Knoten oder der Netzwerkinfrastruktur überlastet werden. Weiterhin sinkt durch die hohe Last der eingeschleusten Pakete die Bandbreite, die den eigentlichen Anwendungen zur Verfügung stehen sollte. Gegenmaßnahmen setzen hier idealerweise nicht auf der Ebene der intelligenten Knoten, sondern bei der Netzwerkhardware wie Switches an. Diese könnten nur authentifizierten Geräten die Teilnahme am Netzverkehr erlauben. Dabei ist es möglich, die oben beschriebene Infrastruktur zur Sicherstellung der Nachrichtenintegrität ebenfalls zur Geräteauthentifikation zu nutzen. 2.3.4 Routing Das Routing innerhalb eines Netzwerks beschreibt die Pfade, auf denen Informationen zwischen einzelnen Knoten des Netzwerks ausgetauscht werden. In diesem Abschnitt werden zunächst allgemeine Aspekte des Routings erläutert, gefolgt von dem IV-spezifischen Routing innerhalb der Middleware. 2.3.4.1 Routing allgemein Die einzelnen Knoten eines Netzwerks können dabei eindeutig unterschieden werden, z.b. mit Hilfe einer IP-Adresse oder eines anderen Identifikators (ID). Diese Identifikation der einzelnen Knoten wird mitunter für den Aufbau der Routing-Tabelle verwendet, die beim Versenden und Weiterleiten von Daten durch einen Netzwerk- Knoten typischerweise genutzt wird. Sollen nämlich Daten von einem Quellknoten A zu einem Zielknoten B gesendet werden, kann beispielsweise Knoten A anhand der Routing-Tabelle bestimmen, über welchen Transportkanal die Daten zu welchem seiner Nachbarknoten gesendet werden müssen, um schließlich zum Zielknoten B zu gelangen. Zu diesem Zweck enthält die Routing-Tabelle eines Knotens A für jeden weiteren, ihm bekannten Netzwerkknoten B die Information, über welche Transportkanäle und an welchen Nachbarknoten von A Daten weitergeleitet werden

18.03.2014 Seite 19 itsowl-iv/ap2_3/1.0 sollen, wenn sie für Knoten B bestimmt sind. Die Routing-Tabelle kann gegebenenfalls auch Alternativen enthalten, um beispielsweise den Ausfall einzelner Transportkanäle bzw. Knoten in einem Netzwerk durch die Nutzung eines Alternativ- Pfades im Netzwerk möglicherweise kompensieren zu können. In diesem Fall werden die Alternativpfade typischerweise durch eine Gewichtung relativ zueinander bewertet, sodass abhängig von einer gewählten Metrik zur Bestimmung der Routing- Tabelle z.b. kürzere oder auch schnellere Pfade bevorzugt ausgewählt werden. Da die Routing-Tabelle sich auf Transportkanäle zu Nachbarknoten bezieht, hat jeder Knoten eine eigene Routing-Tabelle und die Routing-Tabellen verschiedener Knoten können sich unterscheiden. Der Aufbau einer Routing-Tabelle sollte aufgrund der identifizierten Anforderungen an die Middleware dynamisch erfolgen. Hierbei werden Routing-Protokolle verwendet, die den Aufbau und die Aktualisierung der Routing-Tabellen innerhalb des Netzwerks regeln. Somit kann auf Änderungen im Netzwerk, wie z.b. der Verfügbarkeit einzelner Knoten, reagiert werden. 2.3.4.2 Routing innerhalb der Middleware Die in itsowl-iv entwickelte Referenzarchitektur soll insbesondere die Verwendung von Netzwerk-Protokollen unterstützen, die als Standard definiert und etabliert sind sowie bereits in der Industrie eingesetzt werden. Daher soll das Routing innerhalb von Subnetzen weiterhin entsprechend der verwendeten Netzwerk-Protokolle erfolgen. Um jedoch auch Knoten, die über mehrere unterschiedliche Netzwerk-Anbindungen verfügen, berücksichtigen zu können, wird oberhalb der Netzwerk-Protokolle und damit innerhalb der Middleware ein zusätzliches Routing eingesetzt. Dieses Routing ermöglicht somit auch die Kommunikation eines Netzwerk-Knotens über unterschiedliche Subnetze hinweg, wie z.b. einem Profinet- und einem CAN- Subnetz. Da sich die Subnetze auch in ihrer Art der Identifizierung einzelner Knoten unterscheiden können, wird das Routing innerhalb der Middleware eine eigene Routing-Tabelle beinhalten, in der die einzelnen Netzwerk-Knoten über Subnetz- Grenzen hinweg eindeutige IDs (sogenannte UUIDs (Unique Universal IDs)) erhalten, die mit den Identifikatoren der einzelnen Subnetze assoziiert werden. Ein Netzwerk-Knoten, der beispielsweise sowohl in ein Profinet-Netzwerk als auch an einen CAN-Bus angeschlossen ist, erhält somit eine im gesamten Netzwerk eindeutige ID, die sowohl mit der IP-Adresse des Knotens im Profinet-Netzwerk als auch mit der ID des Knotens im CAN-Bus assoziiert ist. Stehen mehrere Kommunikationswege zur Verfügung, wird die Entscheidung über die Route anhand der von der Anwendung definierten Transportgüte getroffen. Dazu muss das Routing die Anforderung der Anwendung mit den Eigenschaften der Transporttechnolgie vergleichen. Die Middleware muss eine Routing-Tabelle aufbauen, welche die UUID auf den entsprechenden Transport und die protokollspezifische ID abbildet. Der Aufbau dieser Routing-Tabelle kann entweder automatisiert oder durch einlesen eines Konfigurations-Files, der durch den Anlagenbauer erstellt wird, erfolgen. In Abbildung 2.4 zeigt ein abstraktes Beispiel die Funktion des universellen Routings mit Hilfe einer Routingtabelle. In diesem Beispiel Kommuniziert eine Anwendung mit 3 verschiedenen Knoten, die drei unterschiedliche Funktionen innerhalb der

18.03.2014 Seite 20 itsowl-iv/ap2_3/1.0 Anwendung bereitstellen. Innerhalb der Anwendung hat jede dieser Funktionen eine eigene UUID (A, B und C). Vor der Anwendung selbst bleibt verborgen, dass sich die Knoten die diese Funktionen bereitstellen in zwei unterschiedlichen Subnetzen befinden. Knoten 1 und 2 befinden sich in einem Profinet-Netz, welches von der Konnektivität durch Transport TRANS 1 bereitgestellt wird. Knoten 3 befindet sich in einem EtherCAT-Netz, welches über TRANS 2 angesprochen werden kann. Innerhalb der Netze haben die Knoten ihre eigenen protokollspezifischen Adressen. Knoten 1 hat beispielsweise die IP-Adresse X und Knoten 2 die IP-Adresse Y. Um zu zeigen, dass jedes Netz einen eigenen Adressraum hat, ist die IP-Adresse von Knoten 3 in diesem Beispiel ebenfalls X. Will die Anwendung nun mit Knoten 1 kommunizieren, wird eine Anfrage zusammen mit der UUID an die Middleware übergeben. Diese Anfrage wird nun von der Middleware mit Hilfe der Routing Tabelle bearbeitet und der Konnektivität zusammen mit dem entsprechenden Transport (TRANS 1) und der protokollspezifischen Adresse X übergeben. Anwendung Funktion 1 UUID: A Funktion 2 UUID: B Funktion 3 UUID: C Middleware Routing Tabelle A -> {TRANS 1, ADDR X} B -> {TRANS 1, ADDR Y} C -> {TRANS 2, ADDR X} TRANS 1 (z.b. Profinet) Konnektivität TRANS 2 (z.b. EtherCAT) Knoten 1 (Funktion 1) ADDR: X Knoten 2 (Funktion 2) ADDR: Y Knoten 3 (Funktion 3) ADDR: X Abbildung 2.4: Beispiel für das universelle Routing 2.4 Konnektivitätsebene Die Konnektivitätsebene ist die unterste Schicht des intelligenten Knotens. Sie kapselt die vorhandenen Transportkanäle und entspricht abhängig vom jeweiligen Protokoll den Schichten eins bis drei (Bitübertragung, Sicherung und Vermittlung) des ISO/OSI Referenzmodells [7]. Die Konnektivitätsebene stellt den darüber liegenden Schichten beliebige und beliebig viele Transportkanäle mit definierter Transportgüte zur Verfügung. Die einzelnen Transportprotokolle sollen zur besseren

18.03.2014 Seite 21 itsowl-iv/ap2_3/1.0 Handhabbarkeit auf Anwendungsebene weitestgehend transparent behandelt werden können. Dieses Ziel wird mit Hilfe einer transparenten Inter-Layer- Kommunikation realisiert. 2.4.1 Echtzeitkommunikation Die Echtzeitkommunikation kommt in Anwendungen zum Einsatz, die einen deterministischen Datenaustausch erfordern. In diesem Fall erfordert die Anwendung die Zustellung der Daten innerhalb einer bestimmten Zeitspanne. Dieser Determinismus kann in zwei Gruppen aufgeteilt werden die harte- und weiche Echtzeitfähigkeit. Erfordert eine Anwendung die Zustellung einer jeden Nachricht innerhalb einer bestimmten, endlichen Zustellzeit und ist eine verspätete Zustellung aus Sicht der Anwendung dem Verlust der Nachricht gleichzusetzen, spricht man von harter Echtzeitanforderung. Bei weicher Echtzeitanforderung ist eine verspätete Zustellung unter Inkaufnahme des Verlusts einer Teilinformation tolerierbar. Ein Kommunikationssystem, welches diese rechtzeitige Auslieferung einer Nachricht nur eingeschränkt garantieren kann, bedient demnach weiche Echtzeitanforderung. Es wird der harten Echtzeitanforderung gerecht, wenn jede Nachricht innerhalb der von der Anwendung geforderten Zustellzeit dem Empfänger vorgelegt werden kann. Als Sonderform der harten Echtzeitanforderung ist die isochrone Echtzeitanforderung zu benennen, bei der die Ankunftszeit einer Nachricht zu einem festgelegten Zeitpunkt gefordert wird. Die Zustellzeit ist in diesem Fall eine feste, vorhersagbare Systemgröße. Die Kategorisierung eines Echtzeit-Kommunikationssystems ist also im Kontext der Anwendung vorzunehmen. Aus der Anwendung heraus lässt sich eine Funktion D(t) angeben, die den Nutzen D einer empfangenen Nachricht in Abhängigkeit der Zustellzeit t mit der zugehörigen Deadline T D angibt, siehe Abbildung 2.5. D D D 1 1 1 0 0 0 t t T D Abbildung 2.5: Kategorisierung der Echtzeitanforderungen T D T D t weiche- (links), harte- (mittig) und isochrone- (rechts) Echtzeitanforderung Üblicherweise findet die Echtzeitkommunikation zyklisch statt. Die Zykluszeit ist eine zentrale Systemgröße eines Echtzeit-Kommunikationssystems. Ein Kommunikationssystem wird den Echtzeit-Anforderungen einer Anwendung gerecht, wenn für die Zykluszeit T C der Zusammenhang D(t=T C ) = 1 gilt.

18.03.2014 Seite 22 itsowl-iv/ap2_3/1.0 2.4.2 Bedarfskommunikation Auf der Anwendungsebene sind Applikationen denkbar, die neben der Echtzeitkommunikation einen Bedarfskommunikationskanal erfordern. Dies könnten beispielsweise kritische Meldungen (Alarme) oder Konfigurationsnachrichten sein. Eine solche Kommunikation darf den Echtzeitkanal in seinem Echtzeitverhalten im Idealfall nicht beeinflussen. Aus diesem Grund müssen in einem echtzeitfähigen Kommunikationssystem die Ressourcen für die beiden Kommunikationsarten aufgeteilt werden. Die Aufteilung der physikalischen Ressourcen einer Kommunikationsstrecke ist systemabhängig und wird auf unterschiedliche Arten umgesetzt (Zeit-, Frequenz- und andere Multiplexverfahren). Nachteilig hierbei ist jedoch die sinkende Effizienz, da zeitweise ungenutzte Ressourcen freigehalten werden. Die feste Zuweisung von Ressourcen ist jedoch die einzige Möglichkeit, den zyklischen Datentransfer vom Bedarfskommunikationskanal zu entkoppeln und findet vorwiegend bei IRT-fähigen Echtzeitkommunikationssystemen Einsatz. Ist eine gewisse Abhängigkeit der beiden Kommunikationsarten tolerierbar (dies ist bei Kommunikationssystemen der Fall, die weiche bis harte Echtzeitanforderungen erfüllen), kann zugunsten der Effizienzsteigerung anstatt der Ressourcenreservierung eine Priorisierung vorgenommen werden. Dabei werden Nachrichten, abhängig vom Dienst, priorisiert behandelt. Im Kontext des intelligenten Technischen Systems ist als Anwendungsschicht der Konnektivität die Middleware zu verstehen. Den Diensten der Middleware sind die verfügbaren Transportprotokolle der Konnektivitätsschicht transparent zur Verfügung zu stellen. Auf die Abstraktion der einzelnen Protokolle geht das folgende Kapitel ein. 2.4.3 Inter-Layer-Kommunikation Die Inter-Layer-Kommunikation wird durch die transparente Schnittstelle Transport realisiert.

18.03.2014 Seite 23 itsowl-iv/ap2_3/1.0 Anwendung Middleware Routing Discovery Transport-IF Transport-IF Transportmanager Transport 1 RT NRT Protokoll Stack... Transport N RT NRT Protokoll Stack Treiber Treiber Konnektivität Abbildung 2.6: Transportschnittstelle Im Detail besteht die Schnittstelle aus einer Bibliothek, die den darüber liegenden Layern protokollunabhängige (transparente) Funktionen zur Verfügung stellt. Diese ermöglichen einen prioritätsgestützten Datentransfer, die Konfiguration und Überwachung der einzelnen Transportkanäle, sowie der gesamten Konnektivitätsebene. Diese homogenisierten Funktionen werden auch als CallBack Funktionen bezeichnet. Die Gegenstelle bildet das transportspezifische Interface (Transport-IF), dass das Kommunikationsprotokoll weitgehend kapselt. Diverse Transportkanäle wie Echtzeit Ethernet-Varianten erfordern eine umfangreiche Konfiguration bevor eine Kommunikation möglich ist. Diese Aufgabe wird vom Transportmanager übernommen, der die Konfigurations- und Überwachungsfunktionen der Konnektivitätsebene kapselt. 2.4.3.1 Kommunikation Die Kommunikation besteht im Wesentlichen aus dem Austausch von Nutzdaten mit einem anderen Knoten. Dieser Austausch wird von der Middleware durch eine Sende- und Empfangsfunktion durchgeführt. Das Senden von Nutzdaten wird von der Middleware eingeleitet, indem der Konnektivität eine protokollunabhängige Funktion als Sendeanfrage übergeben wird. Diese Funktion enthält zum einen die Nummer des gewünschten Transportkanals, zum anderen die protokollspezifische Zieladresse, über welche der Zielknoten erreichbar ist (siehe Abschnitt 2.3.4.2). Die Nummer des Transportkanals beinhaltet implizit die Information zur Transportgüte, da innerhalb der Konnektivität ein Echtzeitkanal und ein Nicht-Echtzeitkanal des gleichen Protokolls in zwei

18.03.2014 Seite 24 itsowl-iv/ap2_3/1.0 unterschiedliche logische Kanäle aufgeteilt werden. Weitere Parameter die der Konnektivität bei einer Sendeanfrage übergeben werden müssen sind die Daten (Adresse auf Speicher, an dem die Daten liegen) sowie eine Angabe über die Menge an Daten, die versendet werden sollen. Diese protokollunabhängige Funktion wird innerhalb der Konnektivität auf die transportspezifische Schnittstelle (Transport-IF) umgesetzt. Auch das Empfangen von Nutzdaten wird von der Middleware eingeleitet, wobei der Konnektivität eine für alle Kommunikationsprotokolle einheitliche Funktion zum Empfangen übergeben wird. Alternativ kann eine eventbasierte Kommunikation verwendet werden, sodass der Middleware durch einen Event ein Empfang mitgeteilt werden kann. Eine allgemeine Empfangsfunktion enthält neben der Nummer des gewünschten Transportkanals auch die protokollspezifische Adresse des Knoten von dem Nutzdaten empfangen werden sollen. Auch beim Empfangen beinhaltet die Nummer des Transportkanals implizit die Information zur Transportgüte, da innerhalb der Konnektivität ein Echtzeitkanal und ein Nicht-Echtzeitkanal des gleichen Protokolls in zwei unterschiedliche logische Kanäle aufgeteilt werden. Weitere Parameter, die der Konnektivität bei einer Empfangsanfrage übergeben werden können, sind die Adresse im Speicher, an der die zu empfangenden Daten abgelegt werden sollen sowie eine Angabe über die Menge an Daten, die empfangen werden sollen. Alternativ kann jedoch auch eine feste Speicherstruktur von der Konnektivität verwaltet werden, so dass der Middleware die Adresse auf die Daten mitgeteilt werden kann. 2.4.3.2 Konfiguration und Monitoring auf Transportebene Auf Transportebene bietet die Inter-Layer-Kommunikation eine einheitliche Schnittstelle zur Konfiguration einzelner Transportkanäle. Auch hierbei werden die protokollspezifischen Aspekte der Schnittstelle durch ein einheitliches Mapping homogenisiert. Zudem erfolgt eine Arbitrierung der Statusinformationen durch den zentralen Transport Manager. Dies bedeutet, dass alle Statusinformationen wie Error Events oder ein Nachrichtenausfall im Transport Manager gebündelt werden und so vereinheitlicht der Middleware übergeben werden können. 2.4.3.3 Konfiguration und Monitoring auf Systemebene Auf Systemebene bietet der Transportmanager eine Konfigurations- und Monitoringschnittstelle. Der Konnektivitätslayer lässt sich somit zentral von der Middleware überwachen und konfigurieren. Neben aktuellen Statusinformationen, wie zum Beispiel einer Liste der verfügbaren Transportkanäle (Kanal ist konfiguriert und aufgebaut), können auch allgemeine Statusinformationen, wie zum Beispiel alle verfügbaren Transportkanäle (unterstütze Protokolle), an die Middleware übergeben werden. Optional stellt der Transportmanager eine Link- und Protokollerkennung (siehe folgender Abschnitt) zur Verfügung. Abbildung 2.7 zeigt den prinzipiellen Ablauf eines Kommunikationsaufbaus.

18.03.2014 Seite 25 itsowl-iv/ap2_3/1.0 1. Erkenne Protokoll Middelware 2. Konfiguriere Transportkanal 3. Transportkanal ist aufgebaut dyn. Systemkonfiguration Protokollerkennung Transportkanal verfügbar Aufbau des Transportkanals Konnektivität Abbildung 2.7: Aufbau eines Transportkanals 2.4.4 Automatische Protokollerkennung Wie in Abschnitt 2.3.2 beschrieben wird zur Selbstkonfiguration des Systems ein adhoc Konfigurationskanal vorausgesetzt. Um eine sogenannte Plug-and-play - Funktionalität eines Knotens zu ermöglichen muss der ad-hoc Konfigurationskanal automatisch von der Konnektivität zur Verfügung gestellt werden. Dies muss ohne Informationen über das vorhandene Protokoll von der Middleware geschehen. Insbesondere bei Hinzufügen eines Knotens in ein Netzwerk mit isochronen Echtzeitanforderungen kann ein ad-hoc Konfigurationskanal nur unter Kenntnis des jeweiligen Protokolls zur Verfügung gestellt werden. Soll beispielsweise ein Knoten in ein Ethernet-basiertes isochrones Echtzeitsystem hinzugefügt werden, kann dieser Knoten zunächst kein Standard TCP-IP-Protokoll für die Selbstkonfiguration verwenden. Sollte der Knoten dieses tun, wäre die isochrone Echtzeitfähigkeit des gesamten Systems verletzt, da der neu hinzugefügte Knoten auch in sogenannten roten Phasen senden würde, in denen nur ein Knoten des gesamten Systems senden darf. Da es sich bei isochronen Echtzeitsystemen meist um Ethernet-basierte Systeme handelt, sollen im Folgenden auch nur diese betrachtet werden. Damit ein Knoten in ein unbekanntes System hinzugefügt werden kann, ist zunächst eine Protokollerkennung nötig, um anschließend einen ad-hoc Konfigurationskanal im entsprechenden Protokoll bereit zu stellen. Diese Protokollerkennung sollte vor der Konfiguration des Transportkanals durchgeführt werden, so dass anschließend der benötigte Transportkanal mit dem richtigen Protokoll konfiguriert werden kann. Während der Protokollerkennung befindet sich der Knoten in einem passiven Modus, in dem er nur auf Pakete lauscht, jedoch selbst keine versendet. Anhand von eingehenden Paketen kann nun mithilfe der Rahmenstruktur eines Ethernet-Frames das Protokoll erkannt werden.

18.03.2014 Seite 26 itsowl-iv/ap2_3/1.0 Zieladresse (6 Byte) Quelladresse (6 Byte) Ethertype (2 Byte) Nutzdaten (46-1500 Byte) FCS (4 Byte) Abbildung 2.8: Ethernet-Rahmen nach IEEE 802.3 Da alle Ethernet basierten Echtzeitprotokolle auf dem Standard-Ethernet-Rahmen (Abbildung 2.8) aufsetzen, kann zunächst mit Hilfe des 2 Byte große Bereichs Typ das Protokoll herausgefunden werden. Dieser Bereich kann zum einen die Länge des folgenden Datenbereichs in ganzen Bytes angeben. Weil die Maximallänge des Datenbereiches in einem gültigen Ethernet-Rahmen 1500 Byte nicht überschreiten darf, kennzeichnen ausschließlich Werte von 1500 und kleiner die Länge des Datenbereiches. Ist der Wert des Bereiches Typ größer als 1500, handelt es sich um den Ethertype. Der Ethertype wird verwendet um die Ethernet-Rahmen den unterschiedlichen Protokollen zuordnen zu können. Tabelle 2-1 listet eine Auswahl an Echtzeitprotokollen und ihren zugehörigen Ethertype auf: Protokoll VARAN SERCOS Powerlink PROFINET EtherCAT Ethertype 0x88FA 0c88CD 0x88AB 0x8892 0x88A4 Tabelle 2-1: Ethertype verschiedener Echtzeitprotokolle Manche Ausführungen von Protokollen (z.b. Profinet RT) verwenden zusätzlich einen sogenannten VLAN Tag (Virtual Local Area Network Tag) der im Frame durch den Ethertype 0x8100 angegeben wird. Hat ein Frame diesen Ethertype müssen zusätzlich Bereiche der Daten eines Standard-Ethernet-Rahmens analysiert werden, um schließlich das entsprechende Protokoll zu erkennen. Abbildung 2.9 zeigt einen Vergleich der Rahmenstrukturen verschiedener Echtzeitprotokolle mit Bezug auf den Standard-Ethernet-Rahmen.

18.03.2014 Seite 27 itsowl-iv/ap2_3/1.0 Ethernet Zieladresse (6 Bytes) Quelladresse (6 Bytes) Ethertype Länge (2 Byte) Daten (46-1500 Bytes) CRC (4 Bytes) Profinet RT Zieladresse (6 Bytes) Quelladresse (6 Bytes) TPID Ethertype 0x8100 VLAN Tag (4 Byte) TCI (2 Byte) Ethertype 0x8892 Frame ID (2 Bytes) Daten (1-1440 Bytes) CRC (4 Bytes) Profinet RToverUDP Zieladresse (6 Bytes) Quelladresse (6 Bytes) VLAN Tag (4 Byte) Ethertype 0x0800 IP / UDP (28 Byte) Frame ID (2 Bytes) Daten (1-1364 Bytes) CRC (4 Bytes) Profinet IRT Zieladresse (6 Bytes) Quelladresse (6 Bytes) Ethertype 0x8892 Frame ID (2 Bytes) Daten (1-1440 Bytes) CRC (4 Bytes) Powerlink Zieladresse (6 Bytes) Quelladresse (6 Bytes) Ethertype 0x88AB MT (1 Byte) DA (1 Byte) SA (1 Byte) Daten (43-1497 Bytes) CRC (4 Bytes) EtherCAT Zieladresse (6 Bytes) Quelladresse (6 Bytes) Ethertype 0x88A4 Header (2 Bytes) Daten (48-1470 Bytes) CRC (4 Bytes) Abbildung 2.9: Vergleich Rahmenstruktur verschiedener Echtzeitprotokolle

18.03.2014 Seite 28 itsowl-iv/ap2_3/1.0 3 Praktische Anwendungen der Referenzarchitektur 3.1 Anwendungsbeispiel 1 Dynamische Konfiguration in der industriellen Automatisierungstechnik Im Folgenden wird anhand eines Beispiels aus dem Bereich der industriellen Automatisierungstechnik gezeigt, wie eine dynamische Konfiguration von Automatisierungsprozessen erreicht werden kann. Dazu werden die in der Referenzarchitektur vorgestellten Funktionsblöcke semantische Selbstbeschreibung (Referenz), Zuordnungs-Dienst (Referenz), Discovery (Referenz), Routing (Referenz) und der ad-hoc Kommunikationskanal verwendet und implementiert. Das Anwendungsbeispiel basiert auf der Referenzanwendung, die im Kapitel 2.1.1 des Dokuments AP 1.1/AP1.2 Anforderungsspezifikation [12] vorgestellt wurde. Die Referenzanwendung wird im Folgenden noch einmal kurz beschrieben. Ausgangspunkt ist ein typischer Automatisierungsprozess mit einer zentralen Steuerung und einer Vielzahl von dezentralen I/O-Geräten. Der schematische Aufbau der Steuerung solch eines Prozesses in Abbildung 3.1 dargestellt ist. SPS Steuerungsprogramm (IEC 61131) Feldgeräte Netzwerktechnologie Sensoren/Aktoren, IOs,... Sensoren/Aktoren, IOs,... Kommunikationsschnittstelle Kommunikationsschnittstelle Kommunikationsschnittstelle Kommunikationsschnittstelle Sensoren/Aktoren, IOs,... Abbildung 3.1: Schematischer Aufbau einer Automatisierungsanlage Die Software zur Steuerung des Prozesses wird auf einer speicherprogrammierbaren Steuerung (SPS) implementiert. Die physikalische Schnittstelle zum Prozess bilden die Sensoren und Aktoren, bei denen es sich beispielsweise um analoge Messwertaufnehmer für verschiedene physikalische Größen, digitale Schalter oder auch um Motoren handeln kann. Die Sensoren und Aktoren werden in der Regel nicht direkt an die SPS angeschlossen, sondern an Vertreter der Geräteklasse der Feldgeräte. Diese sind für die Ansteuerung der Sensoren und Aktoren verantwortlich. So führen sie z.b. eine Analog-/Digitalumwandlung bei analogen Sensoren durch oder erzeugen die notwendigen Ströme und Spannungen zum Antreiben eines Elektromotors. Die Messwerte der Sensoren sowie die Steuersignale für die Aktoren geben die Feldgeräte an die SPS weiter bzw. erhalten sie von ihr. Die

18.03.2014 Seite 29 itsowl-iv/ap2_3/1.0 Kommunikation zwischen SPS und Feldgeräten wird über eine geeignete Netzwerktechnologie wie ein Echtzeit-Ethernet-Derivat wie Profinet durchgeführt. Zur Inbetriebnahme eines solchen Systems sind drei Schritte erforderlich, die in der Regel in einem Engineering-Werkzeug des SPS-Herstellers durchgeführt werden: 1. Das eigentliche Steuerungsprogramm muss erstellt werden. Daten, die mit den Feldgeräten ausgetauscht werden, werden dabei als Variablen deklariert. 2. Alle im Prozess vorhandenen Feldgeräte müssen dem Werkzeug bekanntgemacht werden. Dazu wählt der Nutzer die entsprechenden Feldgeräte aus einer Gerätebibliothek aus und fügt sie dem Werkzeug hinzu. Weiterhin müssen für jedes Feldgerät je nach verwendeter Netzwerktechnologie spezifische Einstellungen durchgeführt werden. 3. Der Nutzer teilt dem Werkzeug mit, welche Variablen des Steuerungsprogrammes auf die Ein- und Ausgänge der Feldgeräte abgebildet werden. Ziel ist es nun, die manuelle Konfiguration, die zur Inbetriebnahme eines Automatisierungsprozesses notwendig ist, auf ein Minimum zu reduzieren. Für eine automatische Konfiguration ergeben sich zwei zentrale Herausforderungen: 1. Die Steuerungsvariablen müssen auf die Feldgeräte abgebildet werden. 2. Die zum echtzeitfähigen Austausch der Prozessdaten benutzte Netzwerktechnologie muss konfiguriert werden. Ein Überblick über den vorgeschlagenen Lösungsansatz ist in Abbildung 3.2 skizziert. Die einzelnen Bestandteile der Lösung werden im Folgenden detaillierter beschrieben.

18.03.2014 Seite 30 itsowl-iv/ap2_3/1.0 Anwendung 1: SPS 1 OPC UA Server Semantische Selbstbeschreibung IEC 61131-3 Laufzeitumgebung Nutzdaten 3 Routing/ Autokonfiguration Echtzeit-Ethernet Ad-hoc Konfigurationskanal 2 Zuordnungsdienst & Discovery OPC UA Client Zuordnung Nutzdaten/Anwendung Echtzeit-Ethernet OPC UA Server Semantische Selbstbeschreibung Sensor/ Aktor Nutzdaten Anwendung 2: Feldgerät Abbildung 3.2: Automatische Konfiguration eines Automatisierungsprozesses 3.1.1 Teil 1: Semantische Selbstbeschreibung der SPS-Anwendung Den Ausgangspunkt der Lösung bildet das IEC 61131-3 Steuerungsprogramm. Dieses Programm beinhaltet die Logik des zu steuernden Prozesses. Zur Logikbeschreibung stehen dem Entwickler mehrere Möglichkeiten offen. Er kann beispielsweise das Programm aus vordefinierten Funktionsblöcken (z.b. Logik- Verknüpfungen, Timer) zusammensetzen oder er benutzt eine Hochsprache (Structured Text), die der Programmiersprache C ähnelt. Im Rahmen der Referenzarchitektur könnte das Steuerungslogik auch aus einzelnen Softwarekomponenten zusammen gesetzt sein (siehe Kapitel 2.2.1). In allen Fällen muss der Entwickler das Programm mit der Außenwelt verknüpfen, um auf die Daten der Sensoren lesend und auf die Daten der Aktoren schreibend zugreifen zu können. Dazu werden im Steuerungsprogramm entsprechende Eingangs- und Ausgangsvariablen deklariert. Diese Variablen verknüpft der Entwickler anschließend mit den Feldgeräten, an die die Sensoren und Aktoren angeschlossen sind. Dieser Zuordnung zwischen Variablen und Feldgeräten soll durch die hier vorgestellten Methoden automatisch erfolgen. Dazu muss der Entwickler die Variablen um semantische Informationen ergänzen, die die Grundlage für die

18.03.2014 Seite 31 itsowl-iv/ap2_3/1.0 Entscheidungsfindung im Zuordnungs-Dienst bilden. Zu diesem Schritt ist es notwendig, dass ein passendes Informationsmodell festgelegt wird und die Variablen mit semantischen Informationen verknüpft werden. 1. Das festgelegte Informationsmodell beschreibt, wie die Variablen semantisch beschrieben werden. Die Auswahl eines passenden Modells ist eine sehr komplexe Aufgabe. Beispielsweise könnte ein einfaches Modell jeder Variablen die physikalische Größe zuordnen, die durch die Variable repräsentiert wird (siehe auch Abbildung 2.2). Diese Vorgehensweise stößt aber an Grenzen bei dimensionslosen Größen. Auch kann eine Größe in einem Automatisierungsprozess mehrfach vorkommen. In dem Fall muss das Informationsmodell Möglichkeiten bieten, weitere Informationen zu einer bestimmten Größe zu modellieren, wie z.b. die räumliche Lokalisation des Sensors. Eine zukünftige Aufgabe des QP-IV wird es sein, Konzepte für die Informationsmodellierung in der Automatisierungstechnik zu erstellen. Für die Umsetzung dieses Anwendungsbeispiels wird vorerst ein sehr vereinfachtes Informationsmodell benutzt. So wird jeder Variablen ein einzelner Begriff zugeordnet, welche Information durch sie beschrieben wird. Beispiele wären Temperatur, Förderband voll, Not-Aus betätigt. 2. Die Verknüpfung der semantischen Informationen mit den Variablen ist ein rein technischer Vorgang. Es wäre denkbar, dass die Entwicklungsumgebung des Steuerungsprogrammes um Möglichkeiten zur Eingabe der Semantik ergänzt wird. Dazu könnte das Informationsmodell in die Umgebung importiert werden und jeder Variablen wird die Semantik grafisch zugewiesen. In diesem Anwendungsbeispiel wird die Verknüpfung manuell vorgenommen. Dazu exportiert der Anwender das IEC 61131-3 Steuerungsprogramm in das PLCopen XML-Format [10]. PLCopen ist eine Organisation, die sich der Standardisierung im Bereich der industriellen Automatisierungstechnik verschrieben hat. So ist es u.a. ein Ziel, die Interoperabilität zwischen verschiedenen Entwicklungswerkzeugen für IEC 61131-3 zu verbessern. Dazu wurde eine auf XML basierende Definition entworfen, mit der 61131-3 Programme herstellerunabhängig beschrieben werden können. Dies ermöglicht es beispielsweise, Steuerungsprogramme zwischen verschiedenen Entwicklungsumgebungen auszutauschen. Abbildung 3.3 zeigt als Beispiel ein sehr einfaches 61131-3 Steuerungsprogramm, in der zwei Eingänge (E1 und E2) mit einem AND -Funktionsblock verknüpft werden und das Ergebnis auf die Variable A1 ausgegeben wird. Abbildung 3.3: Beispiel für einen IEC 61131-3 Funktionsblock Dieser Funktionsblock lässt sich in der verwendeten Entwicklungsumgebung in das PLCopen XML-Format exportieren.