ipConv Architektur

Generell sind zwei Lösungsansätze zur Implementierung von Gateways denkbar:

• direkte Konvertierung von einem Protokoll in das andere
• Konvertierung eines Protokolls in eine normierte, protokollunabhängige Form und umgekehrt

Der erste Ansatz ist gut geeignet für einfache eins-zu-eins Konvertierungen zwischen verwandten Protokollen. Die Protokolle sind eng miteinander verbunden, d. h. es besteht eine sehr enge Beziehung zwischen der Informationsdarstellung auf dem einen und auf dem anderen Protokoll. Das Konzept bietet nur eine geringe Flexibilität im Bezug auf die Erweiterbarkeit und Entkopplung der Protokolle voneinander. Das muss nicht unbedingt ein Nachteil sein, wenn die Flexibilität nicht von Bedeutung ist, wie z. B. bei Konvertierungen von Profibus-DP auf Modbus.

Beim zweiten Ansatz werden die Daten aus einem Protokoll in eine normierte, protokollunabhängige Universalform konvertiert. Diese Universaldarstellung muss so mächtig sein, dass alle möglichen Protokolle damit abgedeckt werden. Das Konzept eignet sich viel besser für universelle Konvertierungen, wobei das Zielprotokoll nicht feststeht. Es bietet den höchsten Grad an Flexibilität und Erweiterbarkeit und erlaubt eine weitgehende Entkopplung unterschiedlicher Protokolle voneinander.

ipConv ist entsprechend dem zweiten Ansatz konzipiert. Dabei werden die Daten aus der protokollspezifischen Darstellung in die normierte, protokollunabhängige Darstellung konvertiert und umgekehrt.

ipConv ist ein modulares System aus mehreren Protokollstacks, die protokollspezifische Kommunikationsaufgaben übernehmen. Nach außen stehen die Protokollstacks mit externen Kommunikationspartnern in Verbindung. Nach innen sind sie in der Lage, Daten über eine normierte Schnittstelle mit dem Knotenmodul (Node) auszutauschen. Die Protokollstacks haben in der Regel keine direkte Verbindung zueinander.

Die normierte Schnittstelle erlaubt die Darstellung von Informationen in einer protokollunabhängigen Form, damit diese zwischen verschiedenen Protokollstacks ausgetauscht werden können.
Das Knotenmodul übernimmt die Aufgabe der Verarbeitung, Vermittlung und evtl. Konvertierung von normierten Informationen zwischen verschiedenen Protokollstacks.
Protokollstacks konvertieren die Informationen aus der protokollspezifischen Darstellung in die normierte Darstellung und umgekehrt. Dabei werden Telegramme in atomare Einheiten, wie z. B. einzelne Einzelmeldungen zerlegt.

Protokollstacks bestehen aus einem oder mehreren Modulen, die autarke, funktionale Einheiten bilden. Einfache Protokollstacks bestehen in der Regel aus einem Modul. Komplexe, nach dem OSI Layer Modell definierte Protokolle, bestehen aus mehreren Modulen. Dabei übernimmt ein Modul die Funktion eines OSI-Layers (z. B. Link Layer oder Application Layer). Jedes Modul (auch Link Layer Module) besitzt eine eigene Schnittstelle zum Knotenmodul. Dadurch lassen sich administrative Informationen übertragen, wie z. B. der Verbindungsstatus mit einer bestimmten RTU.

Administrative Module übernehmen zusätzliche Aufgaben wie die Redundanzsteuerung, Zeitsynchronisation usw.

Der Knoten (Node) ist zuständig für Empfang, Verarbeitung und Weitervermittlung von normierten Informationen. Dazu stellt er während der Anlaufphase zu allen Modulen eine Verbindung her, die dann auch zur internen Datenübertragung verwendet wird.

Alle Informationen vom und zum Knoten werden in normierter Form übertragen. Jede normierte Information verfügt über folgende Attribute:

• Informationsadresse
• Informationstyp
• Status, Qualität
• Wert
• Zeitstempel (wenn verfügbar)
• weitere typabhängige Attribute

Der Informationstyp legt fest, wie die Attribute zu interpretieren sind. Die Adressierung der Informationen erfolgt mittels einer normierten Adresse (NA). Diese Adresse identifiziert eine Information eindeutig innerhalb eines Moduls in einer bestimmten Übertragungsrichtung. Der Aufbau der normierten Adressen erlaubt jederzeit den Rückschluss auf die protokollspezifische Adresse und umgekehrt. Wie die normierte Adresse strukturiert ist, wird durch einen Protokollstack festgelegt.

Jede Information im Knoten durchläuft folgende Phasen:

• Empfang vom Quellmodul
  Hier wird überprüft, ob die empfangene Information konfiguriert ist oder nicht. Falls dies nicht der Fall ist, wird die Information verworfen und eine entsprechende Meldung im Logfile ausgegeben.
• Verarbeitung
  Eine konfigurierte Information kann entsprechend den Konfigurationsparametern verarbeitet werden, z.B. skalieren, invertieren, umrechnen usw.
• Weitervermittlung
  Ebenfalls in der Konfiguration wird festgelegt, wohin,d.h. an welches Modul und mit welcher Ziel-NA die Information zu übertragen ist. An dieser Stelle erfolgt dann normalerweise auch die Konvertierung des Informationstyps, falls der Quelltyp nicht dem Zieltyp entspricht.
• Senden an das Zielmodul
  Vor dem Senden einer Information an das Zielmodul wird überprüft, ob die Ziel-NA konfiguriert ist. Falls dies nicht der Fall ist, wird auch hier die Information verworfen und eine entsprechende Meldung im Logfile ausgegeben. Wie beim Empfang kann eine zusätzliche Verarbeitung der Information stattfinden.

Die Bearbeitung von Informationen erfolgt in Abstimmung mit der Knoten-Konfiguration. Diese legt exakt fest, welche Informationen (Adresse, Typ) von einem Modul kommen und welche zu einem Modul gehen.

Die Übertragung von Informationen im Knoten erfolgt bei Informationen in Überwachungsrichtung (Einzelmeldungen, Messwerte, usw.) nur bei Änderung von Wert bzw. Status. In Steuerrichtung (Befehle, Sollwerte, usw.) werden alle Informationen direkt übertragen. Generell hängt das Verhalten vom normierten Informationstyp ab.

Ein Protokollstack ist eine organisatorische Einheit von einem oder mehreren Protokollmodulen, die dem Zwecke der Konfigurationsvereinfachung dient. Zur Laufzeit treten nur die einzelnen Protokollmodule in Erscheinung.

Ein Protokollmodul steht einerseits mit einem entfernten Kommunikationspartner und andererseits mit dem Knoten in Verbindung. Seine Aufgabe ist es, entsprechend dem bestimmten Kommunikationsprotokoll, den Datenfluss mit der Gegenstelle aufrechtzuerhalten und Daten zwischen protokollspezifischer und normierter Form zu wandeln.
Ein Protokollmodul verfügt über einen fest definierten „Wortschatz“ an normierten Informationen, die er mit dem Knoten austauschen kann. Hier werden prinzipiell zwei Kategorien unterschieden:

• Prozessinformationen
• Interne Informationen

Prozessinformationen sind solche, die direkt vom/zum Kommunikationspartner übertragen werden. Im Protokollmodul erfolgt lediglich eine Umsetzung der Adressen und Werte zwischen der protokollspezifischen- und der normierten Form. Der Funktionsumfang eines Protokolls gibt vor, welche normierten Informationstypen von einem Protokollmodul verarbeitet werden.

Interne Informationen dagegen hängen nur indirekt mit der Gegenstelle zusammen. Sie werden direkt im Protokollmodul gebildet bzw. verarbeitet und haben organisatorischen Charakter. Wenn z. B. die Gegenstelle nicht antwortet, wird diese Tatsache oft mit einer internen Meldung an den Knoten signalisiert.

Protokollmodule sind autarke Einheiten, die in der Lage sind ohne Anweisung von außen, den Datenverkehr mit der Gegenstelle aufzubauen und aufrechtzuerhalten. Zum Beispiel hat ein Slavemodul ein Abbild aller Informationen, die zum entsprechenden Master übertragen werden sollen und kann alle Abfragen selbst beantworten, ohne beim Knoten nachfragen zu müssen. Welche Übertragungsart dazu verwendet wird (spontan, abgefragt, usw.) hängt vom Protokoll ab. Vom Knoten bekommt das Modul alle Informationen bei Änderung von Wert/Status.
Umgekehrt sorgt ein Mastermodul dafür, dass automatisch eine Generalabfrage durchgeführt wird, wenn eine neue RTU erkannt wird und stellt damit sicher, dass alle, diese RTU betreffenden Informationen auf dem neuesten Stand sind.

Zur Verfolgung des Datenverkehrs auf der Kommunikationsschnittstelle bietet auch jedes Protokollmodul die Möglichkeit, die Daten auf unterschiedlichen Abstraktionsstufen zu protokollieren.

Zusätzlich zu Protokollmodulen existieren weitere Module, die keine direkten Kommunikationsaufgaben übernehmen. Zum Beispiel, übernimmt das Modul „NTP“ die Uhrzeitsynchronisation des Systems über das NTP Protokoll. Auch administrative Module kommunizieren mit dem Rest des Systems über die normierte Schnittstelle.