Auf den ersten Blick erscheint ein Kommunikationssystem als ein einfaches Netzwerk physikalischer Geräte. Bei näherer Betrachtung wird jedoch deutlich, dass Geräte auch dann miteinander kommunizieren können, wenn sie physikalisch nicht direkt miteinander verbunden sind. Darüber hinaus kann ein Kabel oder Gerät durchaus mehrere Protokolle verarbeiten. Diese Überlegungen führen zur Unterscheidung zwischen physischen und logischen Geräten und Verbindungen (Bild 1). Eine logische Topologie betrachtet die Steuerungsapplikation aus Sicht der zwischen Applikationsteilen ausgetauschten Variablen und ignoriert die tatsächlichen physikalischen Verbindungen. Hierbei können die Anforderungen an den Datenaustausch hinsichtlich der Kommunikationseigenschaften sowie Eigenschaften der Steuerungsapplikationsteile wie Abarbeitungszeiten oder Eigenschaften der logischen Schnittstellen wie eine Portnummer modelliert werden. Die physikalische Topologie bildet die realen Kommunikationsgeräte und die zwischen ihnen aufgebauten Kommunikationsverbindungen mit Datenpaketaustausch ab. Hier sind neben den eigentlichen kommunizierenden Steuerungsgeräten auch aktive und passive Infrastrukturkomponenten, ihre Eigenschaften (wie Adressen, Schutzklassen oder Durchgangsraten) und die Anforderungen an die Kommunikation (wie Laufzeiten und Auslastungen) von Bedeutung. Beide Topologien stehen zueinander in Beziehung: die physikalische Topologie implementiert eine oder mehrere logische. Dieses Konzept ist flexibel auch für komplexe Systeme verwendbar.
Technologieunabhängige Basis- Bibliotheken
Zur Modellierung solcher Strukturen mit AutomationML wurden im AutomationML e.V. technologieunabhängige Bibliotheken erstellt, die alle notwendigen Basisklassen für eine Beschreibung von Kommunikationssystemen enthalten. Die entstandenen Bibliotheken sind in Bild 2 dargestellt.
- Die beinhaltet acht Basisrollenklassen für physikalische Netzwerke, physikalische Geräte und physikalische Verbindungen sowie für logische Netzwerke, logische Geräte und logische Verbindungen. Diese Klassen sind gemäß den Regeln von AutomationML von der Basisrolle abgeleitet.
- Die Interface-Klassenbibliothek stellt zwei Basis-Interface-Klassen für die Modellierung bereit. Die dort enthaltenen Interface-Klassen werden für die Beschreibung der physischen und logischen Schnittstellen verwendet.
Anwendungsbeispiel
Für eine bessere Erklärung des Vorgehens soll an dieser Stelle ein Teil der Lemgoer Lernfabrik des Anwendungszentrums Industrial Automation (INA) des Fraunhofer IOSB modelliert werden. Im Beispiel ist eine Steuerung über die Kommunikationstechnologie XY (z.B. ethernetbasiertes Profinet) mit zwei E/A Geräten verbunden (Bild 3). Dabei dienen die E/A Geräte zum Anschließen der Sensoren und Aktoren an das Steuerungssystem.
Modellierung in fünf Schritten
Schritt 1: Im ersten Schritt wird für jede der o.g. acht technologieunabhängigen Rollenklassen jeweils eine technologiespezifische Rollenklasse abgeleitet – diese Bibliothek kann später wiederverwendet werden. Im Beispiel wären dies die CommunicationTechnologyXY und die ApplicationXY stellvertretend für beispielsweise Profinet, EthernetIP, Interbus oder Sercos sowie für gebräuchliche Applikationen wie die Steuerung von Sensoren und Aktoren oder die Webserver basierte Konfiguration [1]. Daraus entsteht eine technologieabhängige Rollenbibliothek mit acht Rollenklassen (Bild 4).
