Die automatisierungsspezifischen Komponenten

Beispiel eines Kommunikationspfades zwischen zwei geographisch entfernten Feldgeräten, gekennzeichnet durch eine Folge (dünner) roter Pfeile. Der (dicke) blaue Pfeil illustriert, dass die Objekte eines an ein Feldbus-System angeschlossenen Feldgerätes (FD) durch jeweils ein Objekt im Proxy (VAN-PD) repräsentiert werden. (ÜT ”“ Übertragungstechnik; FD ”“ Feldgerät; VAN-AD ”“ VANfähiges Automatisierungsgerät; VAN-PD ”“ Proxy; VAN-VD ”“ virtuelles Gerät, das heißt Feldgeräte-Objekte sind auf ein VAN-PD abgebildet.)

Die automatisierungsspezifischen Komponenten dienen der Einbeziehung der automatisierungstechnischen Anwendungsobjekte von Feldgeräten in eine VAN-Domäne. Dabei lassen sich zwei Möglichkeiten unterscheiden: Zum einen die Integration durch die VAN-Eigenschaften von VAN-ADs (die Verwaltung der Anwendungsobjekte der Feldgeräte erfolgt dabei durch die automatisierungstechnischen Anwendungsfunktionen des VAN-AD), zum anderen die Integration des gesamten Objektbestandes eines Netzwerksegmentes (verbunden durch nicht-VAN-fähige industrielle Kommunikationssysteme) mittels eines Proxy (VANPD).

Die VAN-fähigen Automatisierungsgeräte (VAN-AD) sind mit gleichartigen Geräten in der VAN-Domain verbunden, da sie über die notwendigen Kommunikationseigenschaften verfügen. Alle anderen Geräte eines Sub-Netzwerkes in einem VAN-Segment einer industriellen Anwendungsdomäne müssen mittels VAN-AP oder VAN-PD einbezogen werden.

Da ein VAN ein heterogenes Kommunikationssystem verwendet, besteht es aus Abschnitten (Netzwerksegmenten) mit unterschiedlichen Übertragungstechniken (ÜTi) entlang eines Kommunikationspfades. Abhängig von der jeweiligen verwendeten Übertragungstechnik gibt es unterschiedliche Adressierungsmechanismen und Übertragungseigenschaften innerhalb der verbundenen Netzwerksegmente. Grundsätzlich gilt, dass der Kommunikationspfad aus mehreren physischen Kommunikationsverbindungen mit unterschiedlichen Übertragungstechniken zwischen den Knotenkomponenten bestehen kann. Die Übertragungstechniken dieser unterschiedlichen Verbindungen müssen von den Knotenkomponenten (VANAP) beherrschbar sein.

Überblick über die Funktionen von Geräten, die über den Runtime-Tunnel verbundenen sind. Zu erkennen ist, dass die Runtime-Kommunikation die web-service-basierte VAN-Infrastruktur umgeht, um die Echtzeit-Eigenschaften deutlich zu erhöhen.

Zur Gewährleistung der geforderten Dienstgüte kommen die Mechanismen „Switching“ und „Routing“ zum Einsatz. Switching bedeutet, dass zwischen zwei VAN-fähigen Komponenten des heterogenen Netzwerkes bei erkanntem Abfall der Dienstgüte eine Umschaltung zwischen den verfügbaren Übertragungstechniken erfolgt. Das ist für den Runtime-Tunnel – sprich für den Austausch der produktiven Daten – nicht sichtbar; der Runtime-Tunnel arbeitet ohne Unterbrechung weiter. Routing bedeutet, dass bei erkanntem Dienstgüte-Abfall und erfolglosem Umschalten der Übertragungstechniken im zuständigen Segment des Netzwerks der Runtime-Tunnel geschlossen und eine neue Route gesucht wird. Danach wird der Runtime-Tunnel wieder freigegeben.

Innerhalb einer VAN-Anwendungsdomäne sind lediglich die Automatisierungs-Applikationen (Anwendungsobjekte) der VAN-fähigen Automatisierungsgeräte und die auf virtuelle Geräte abgebildeten Objekte der Feldgeräte sichtbar; nicht jedoch diejenigen Objekte von Feldgeräten, die direkt an VAN-fähige Automatisierungsgeräte (VAN-AD) angeschlossen sind. Diese Objekte werden von der Applikation im VAN-AD verwaltet. Das heißt: Sub-Netzwerke von Feldgeräten, die mittels am Markt erhältlicher industrieller Kommunikationssysteme wie Profibus, Devicenet, Profinet oder Ethernet/IP verbunden sind, lassen sich auf zwei Wegen in VAN-Domänen integrieren: durch VAN Access Points (VAN-AP) oder durch VAN Proxies (VANPD). Lediglich die Objekte der auf diese Weise integrierten Feldgeräte sind dann in der gesamten VAN-Domäne sichtbar.

Das Adressierungskonzept

Eine VAN-Domäne bildet einen Namensraum einer geographisch verteilten Automatisierungs-Applikation. Beim Verbindungsaufbau zwischen den logischen Kommunikations-Endpunkten (Einrichten des Runtime-Tunnels) und für Management-Aufgaben werden zur Adressierung logische Adressen (Namen) verwendet, und zwar unabhängig von den verwendeten Übertragungstechniken und deren Adressierungsmechanismen (zum Beispiel IP- und MAC-Adressen) in einem heterogenen Netzwerk. Die Identifizierung der VAN-domänenweiten Dienste (Plug&Play-Service, Management, Certification Authority) erfolgt durch den Präfix VAN. Zur weiteren Untergliederung werden Sub-Domänen verwendet. Diejenigen Teile des heterogenen Netzwerks mit eigener Subnetz-Adresse, welche über einen VAN-AP miteinander verbunden sind, bilden jeweils eine eigene Sub-Domäne. Somit sind standardisierte DNSMechanismen für den Zugriff zu den Sub-Domänen nutzbar. Weiterhin lassen sich Sub-Domänen definieren, die von der physischen und logischen Struktur der Netzwerk-Installation abgeleitet werden. Das erleichtert das Engineering der Automatisierungsprojekte und erhöht die Übersichtlichkeit.

Beispiel Profinet: Ein so genanntes „Native Interface”œ ermöglicht die Benutzung von LAN-basierten VAN-Geräten im lokalen Bereich mit Profinet-IO-Verkehr ohne irgendeinen Overhead. Somit ist im lokalen Bereich ein isochroner Betrieb mit harten Echtzeit-Eigenschaften möglich. Der Tunnel über öffentliche Netzwerksegmente wird mittels Open VPN und Profinet IO (Echtzeit-Datenaustausch über UDP) errichtet. Open VPN unterstützt Security-Eigenschaften für den Runtime-Tunnel und ist firewall-„freundlich”œ.

Der Namensraum kann ein „öffentlicher“ oder ein „privater“ (in der Regel ein lokaler) sein. Der öffentliche Namensraum ist beispielsweise in der Internet-Umgebung sichtbar. Hingegen beinhaltet der private Namensraum Installationen, welche nicht im öffentlichen Namensraum sichtbar sein sollen. Ist der Runtime-Tunnel eingerichtet, werden beim Austausch der Produktivdaten die IP- und MAC-Adressen benutzt, welche während des Verbindungsaufbaus ausgehandelt wurden.

Der Runtime-Tunnel

Der Nutzdatenaustausch erfolgt, wie bereits erwähnt, über einen Runtime-Tunnel, wobei die erreichbare Dienstgüte verständlicherweise von den Eigenschaften des unterlagerten heterogenen Kommunikationssystems abhängig ist. Somit sind Anwendungsszenarien etwa für Antriebssteuerungen, welche den isochronen harten Echtzeit-Betrieb erfordern, bei der Übertragung über Weitverkehrsnetze zurzeit nicht denkbar. Nichtsdestotrotz verfügt der Runtime-Tunnel über skalierbare Dienstgüten wie Echtzeit-Eigenschaften, Safety Integry Level oder Security Level. Zur Vorbereitung des Produktivdatenaustausches sind zwei Phasen zu unterscheiden:

1. Errichtung des Runtime-Tunnels, das heißt Ausrichtung der VAN-Infrastruktur auf die Verbindung zweier Kommunikationsendpunkte, vergleichbar mit der Verlegung einer Leitung zwischen zwei Applikationsobjekten. Hierbei kommen Web-Services zum Einsatz. Im Ergebnis ist der Runtime-Tunnel aktiv.

2. Verbindungsaufbau zwischen den Applikationsobjekten selbst unter Nutzung des aktiven Runtime-Tunnels. Der Verbindungsaufbau folgt den Regeln desjenigen Protokolls, welches den Austausch verteilter Automatisierungsobjekte ermöglicht – zum Beispiel dem Application Layer eines der industriellen Kommunikationssysteme nach IEC 61158/61784. Deshalb sind die Mechanismen für diese Phase nicht Gegenstand des VAN-Projektes. Zur Erprobung des VAN-Konzeptes dient das Runtime-Objektmodell von Profinet. Natürlich können auch andere Objektmodelle eingesetzt werden, wenn sie auf dem VAN-Kommunikations-Stack basieren. Alle Geräte mit demselben Objektmodell können mittels der VAN-Infrastruktur interagieren. Geräte mit anderen Objektmodellen sind über Proxy-Geräte (VAN-PD) anschließbar.

Autor

Prof. Dr. Peter Neumann ist Berater des Instituts für Automation und Kommunikation (ifak) Magdeburg, das er 1991 gründete und bis 2004 leitete.