Der Telecontrol-Aspekt
Fortsetzung des Artikels von Teil 1
Die Netz-Kopplung
Die Menge aller VAN-Geräte, die innerhalb einer gemeinsamen Applikation agieren, wird als VAN-Domäne bezeichnet. Eine VAN-Domäne setzt sich in der Regel aus mehreren Subdomänen zusammen; innerhalb einer Subdomäne sind weitere Subdomänen-Strukturen realisierbar. Eine Subdomäne kann auch aus einem Einzelgerät bestehen, wie beispielsweise im Fall einer Pumpstation in einem klassischen Telecontrol-Szenario. Ist die Subdomäne Teil eines Industrienetzes, sieht die Struktur typischerweise wie folgt aus: In der DMZ (demilitarisierte Zone) des Firmennetzes befindet sich ein so genannter Bastion-Host – aus VAN-Sicht ein VAN-Access-Point. In der DMZ ist der VANAP der Firmenpolicy entsprechend vor unerlaubten Zugriffen von Außen und auch von Innen geschützt.
Der Zugang der VAN-Subdomäne zum WAN erfolgt über den VAN-AP, über den alle in dieses Netz ein- und ausgehenden VAN-Messages geleitet werden. Eine Subdomäne kann auch mehrere solcher VAN-AP für unterschiedliche Zugänge zum öffentlichen Netz haben. Üblicherweise sind die Geräte eines Industrienetzes nicht im öffentlichen Netz bekannt, und auch auf IP-Ebene sind sie unter anderem durch die Verwendung privater IP-Adressbereiche nicht ohne weiteres erreichbar. Da also nicht davon auszugehen ist, dass eine VAN-Message direkt an ihr Ziel gelangt, wurde ein spezieller VAN-Routingmechanismus entwickelt.
Das VAN-Routing ist eine fundamentale VAN-Funktion, die namensbasiert arbeitet. Das heißt: Die Routing-Entscheidung wird nicht aufgrund einer IP- oder MAC-Adresse, sondern basierend auf dem VAN-Namen getroffen. Bei einem VAN-Namen handelt es sich um eine vollständige URL, welche auch die Zugehörigkeit zur jeweiligen Domänenstruktur enthält (Beispiel: robot1.ifakvantestside. testproject.van-eu.eu). Darüber hinaus ist das VAN-Routing unabhängig von der unterlagerten Transportschicht und stellt eine Gateway-Funktion auf Applikationsebene (nach OSI-7-Schichtenmodell) dar.
Nicht zuletzt steht das VAN-Routing für einen proaktiven, tabellenbasierten „Next-Hop“-Routingmechanismus, welcher ein Weiterleiten von Webservice-Messages von „Hop zu Hop“ erlaubt, ohne den gesamten Pfad kennen zu müssen. Als erstes überprüft das VAN-Routing hierbei, ob das Ziel innerhalb der eigenen Subdomäne liegt. Ist dies der Fall, kann die Message lokal zugestellt werden. Liegt das Ziel in einer anderen Subdomäne, ist die Nachricht nicht lokal zustellbar. Daher wird namensbasiert in der im Gerät hinterlegten Routingtabelle der nächste Hop – also das VAN-Gerät, an das die Message als nächstes weitergeleitet werden soll – für den Weg zum Endziel der VAN-Message bestimmt. Die Routingtabelle ist in der Routing-ASE (VAN-internes Service-Element) hinterlegt; sie besteht aus einer Liste von Zielsubdomänen. Für die Auswahl der Zielsubdomäne bei der Bestimmung des nächsten Hops kommt ein Best-Match-Verfahren zwischen Endziel und vorhandenen Zielsubdomänen-Einträgen zur Anwendung. Jede Zielsubdomäne enthält wieder eine Liste mit den Hops, über die diese Zielsubdomäne zu erreichen ist. Existieren mehrere Hops zu einer Zielsubdomäne, so wird anhand der zu den Hops gehörenden Metrik-Attribute der am besten geeignete ausgesucht. Die Bestimmung der zugehörigen IP-Adresse des nächsten Hops erfolgt unter Verwendung der Standardautomatismen der unteren Kommunikationsschichten.
Die auf diese Weise gerouteten Webservice-Messages dienen der Koordinierung des eigentlichen Verbindungsaufbaus. Über die gegebene Infrastruktur veranlassen sie den Aufbau eines Tunnels zwischen den jeweiligen Endgeräten, durch welchen dann die Prozessdaten ausgetauscht werden. Jede Ende-zu-Ende-Verbindung ist über das VAN-Engineering in den beiden Endgeräten vorkonfiguriert. Dabei ist festgelegt, welches Gerät den Aufbau der Verbindung initiiert. Dieses Gerät sendet einen entsprechenden Request an den Kommunikationspartner. Da der Request an ein entferntes Ziel außerhalb der eigenen Subdomäne adressiert ist, sendet der Initiator diesen an seinen VANAP. Letzterer weiß, über welchen weiteren VAN-AP die Subdomäne des Zielgerätes (entweder direkt oder indirekt) erreichbar ist, und reicht den Request entsprechend weiter. Hat der Request sein Ziel erreicht, wird eine Response gesendet; daraufhin beginnt der Tunnelaufbau.
Über den durch das VAN-Routing bestimmten Pfad werden zwischen allen beteiligten VAN-Geräten einzelne Tunnelsegmente aufgebaut, die alle zu einer Verbindung gehören. In einem einfachen Fall baut der Initiator einen Tunnel zu seinem VAN-AP auf, letzterer baut wieder einen Tunnel zu dem VAN-AP des Zielgerätes auf, und ein weiteres Tunnelsegment wird zwischen dem VAN-AP des Zielgerätes und dem Zielgerät selbst aufgebaut. Im Anschluss erfolgt die Verbindung der einzelnen Tunnel-Enden in den VAN-APs, wodurch ein kaskadierter Tunnel entsteht. Eine weitere Option besteht darin, innerhalb des kaskadierten Tunnels einen zusätzlichen Tunnel direkt zwischen den Endgeräten aufzubauen.
Sämtliche Daten zu den Tunnelsegmenten einer Verbindung werden erst zur Laufzeit auf die entsprechenden Infrastrukturkomponenten gebracht, da die Bestimmung des Pfades dynamisch erfolgt. Als Tunneltechnologie dient openVPN mit Layer-2-Tunnel (TAP-Devices). Ist die VAN-Verbindung aufgebaut, sind beide Geräte über einen Tunnel, welcher als virtuelle Leitung anzusehen ist, miteinander verbunden. Die VAN-Funktion sorgt dafür, dass die Komplexität des heterogenen Netzwerkes für die eigentliche Automatisierungsapplikation vollständig verborgen bleibt. Jetzt kann der standardmäßige Verbindungsaufbau des Feldbus-Systems erfolgen. Zu berücksichtigen ist dabei, dass die maximale zeitliche Leistungsfähigkeit des VAN-Tunnels deutlich unter den Möglichkeiten einer echten lokalen Verbindung liegt. Dies korreliert jedoch auch mit den Anforderungen, da in der Automatisierung mit räumlichem Abstand im Allgemeinen die zeitlichen Anforderungen an den Datenaustausch sinken. Im Kontext Telecontrol greift hier die Zwischenspeicherung und Zeitstempelung der Prozessdaten. Insbesondere mit der Weiterentwicklung der Dienstgüte öffentlicher Netzwerke ist jedoch eine stetige Annäherung der Leistungsfähigkeit abzusehen, von der letztlich auch virtuelle Automatisierungsnetze profitieren.
Günter Herkommer, Conmputer&AUTOMATION
Autoren
Ralf Messerschmidt
ist wissenschaftlicher Mitarbeiter am Ifak und dortiger Leiter des EU-Projektes VAN.
Thomas Werner
ist wissenschaftlicher Mitarbeiter des Instituts für Automation und Kommunikation (Ifak) Magdeburg.
- Der Telecontrol-Aspekt
- Die Netz-Kopplung
