ipConv/Cloud

Universelle Protokollkonvertierung für Cloud-Umgebungen und Linux-basierte Edge-Geräte

  • ipConv/Cloud

    ipConv/Cloud ist eine Lösung zur universellen Protokollkonvertierung in der Cloud-Umgebung oder auf Edge-Geräten und ermöglicht die Datenübertragung zwischen verschiedenen Protokollen.

    ipConv/Cloud basiert auf ipConv und bietet grundsätzlich die gleiche Funktionalität mit Ausnahme von systemabhängigen Merkmalen, wie z.B. VPN- und Netzwerkkonfiguration. Bei Bedarf müssen diese Funktionen durch den Benutzer auf Systemebene verwaltet werden.

    Für die Konvertierung mit ipConv/Cloud stehen etablierte Standardprotokolle für den flexiblen Einsatz auf vorhandener Hardware oder in einer gehosteten Umgebung, z.B. einem Cloud-Dienst, zur Verfügung. Zur Kommunikation über serielle Protokolle unterstützt ipConv/Cloud die Anbindung sog. "Serial Device Server".

    Bereitstellung

    ipConv/Cloud ist eine Softwarelösung, die aus zwei Archivdateien besteht und auf Linux-basierten Geräten installiert werden kann, die die erforderlichen Mindestanforderungen erfüllen. Die Anwendung wird als systemd-Dienst innerhalb der Linux-Umgebung bereitgestellt.

    Durch den Betrieb auf einer Standard Linux-Distribution haben Sie die volle Kontrolle über das Betriebssystem und können so die leistungsstarken Werkzeuge zum Betrieb und der Verwaltung der Betriebssystem-/Hostumgebung in vollem Umfang nutzen. Wartung und Aktualisierung des Hostsystems obliegen folglich dem Betreiber.

    Lizenzierung

    Die Lizenzierung einer ipConv/Cloud-Instanz erfordert keinen USB-Dongle: Eine spezifische Lizenz erhalten Sie von uns in Form einer Lizenzdatei, die an die Betriebsumgebung/Hardware gebunden ist. Für virtuelle Instanzen bleibt die Lizenz beim Verschieben oder Migrieren der Systemumgebung bestehen. Durch Klonen bzw. Kopieren der Host-Umgebung wird die eingespielte Lizenz ungültig und muss erneut angefordert werden.

    Vorteile im Überblick

    • Leistungsstarke 64-Bit-Architektur
    • Einsatz in Cloud-basierten Umgebungen
    • Verwendung bestehender Hardware
    • Reduktion physischer Geräte, d.h. Betriebskosten- und Energieeinsparung
    • Nutzung freier Ressourcen durch Konsolidierung mehrerer Systeme
    • Effiziente Bereitstellung und Administration (Verschieben von Instanzen, Live-Migration)
    • Schnelle Inbetriebnahme von Systemen
    • Geringerer Wartungsaufwand

    Folgende Anwendungsbei­spiele ipConv/Cloud veranschaulichen einige Einsatzmöglichkeiten.

Besonderheiten
    • Sicherheit auf höchstem Niveau
    • Kommunikation zwischen verschiedenen Datenquellen
    • Gleichzeitiger Einsatz unterschiedlicher Protokolle
    • Beliebiges Mapping von Informationen
    • Intelligente Informationsverarbeitung
    • Keine Programmierung erforderlich
    • Redundanz
Cybersicherheit
    • Gesicherter Zugriff auf alle administrativen Dienste (HTTPS, SSH, SFTP)
    • Rollenbasierte Zugriffskontrolle über Login/Passwort
    • Benutzerverwaltung für lokale Benutzer
    • Unterstützung von Zwei-Faktor-Authentifizierung 2FA (TOTP, WebAuthn)
    • Zentrale Benutzerverwaltung über Active Directory (LDAP) und / oder RADIUS
    • PKI und Crypto-Store zur Verwaltung von Zertifikaten
    • Generierung von selbst-signierten Zertifikaten und Certificate Signing Requests (CSRs)
    • Import und Export von Zertifikaten
    • IEC 62351-3 TLS-Absicherung für IEC 60870-5-104, IEC 61850, DNP 3.0, TASE.2 Protokollstacks
Konfiguration
  • Die Konfiguration des Systems erfolgt komplett über einen Webbrowser. Weitere, spezielle Konfigurationstools sind nicht erforderlich.

    Die aktuelle ipConv Version 4 bietet die Möglichkeit der verschlüsselten Kommunikation zwischen Webserver und Browser über das HTTPS-Protokoll.

    ipConv main menu

    Die Hauptnavigation erlaubt den Zugriff auf alle relevanten Funktionen von ipConv und zeigt auf einen Blick den Zustand des Systems.

    Folgende Funktionen stehen hier zur Verfügung:

    • Wechseln in den Betriebsmodus (unbeaufsichtigte Station) oder Wartungsmodus (Freischaltung der konfigurationsändernden Funktionen)
    • Sicherung und Wiederherstellung der kompletten Konfiguration
    • Lizenzverwaltung (ADMIN)
      Installation von (Demo-) Lizenzen, Lizenzen mit und ohne Laufzeitbeschränkung
    • Softwareupgrade (ADMIN)
    • Import von Konfigurationsinformationen aus Tabellen
      Die Excel-Datei kann direkt importiert werden (Unterstützte Formate: .xlsx, .xlsm, .csv)
    • Bearbeitung der Konfigurationsparameter
    • Freigabe und Versionierung einer Stationskonfiguration
    • Starten und Stoppen des Systems
    • Zugriffe auf Diagnoseinformationen (siehe Diagnose)
    • Zugriff auf das Prozessabbild und Simulation von Daten (siehe Simulation)
    • Anlegen eigener Logbücher
      Zustandsänderungen von normierten Informationen können bei Bedarf gezielt in konfigurierbare Logbücher übertragen werden, um sie über einen bestimmten Zeitraum zu verfolgen oder zu protokollieren.
    • Zugriff auf aktuelle Logdateien (siehe Logging)

    Das folgende Beispiel zeigt die Konfiguration eines Protokollstacks (in diesem Fall IEC 60870-5-101, Master). Hier werden alle Parameter mit den eingestellten Werten, den dazugehörigen Maßeinheiten und einer Kurzbeschreibung angezeigt.
    Durch Klicken auf den Parameternamen kann der Wert verändert werden. Dazu wird auch eine Langhilfe, falls vorhanden, eingeblendet. Der eingegebene Wert wird sofort auf den erlaubten Wertebereich überprüft bzw. durch eine Auswahlliste von vornherein auf gültige Werte eingeschränkt.

    ipConv protocol stack configuration

    Es werden nur die notwendigen Parameter eingeblendet, d.h. wenn z.B. der Typ der Linkschicht auf "unbalanced" gesetzt wird, werden auch nur die entsprechenden Parameter eingeblendet.

    Um große Mengen an Datenpunkten schnell und effektiv bearbeiten zu können, bietet ipConv die Möglichkeit, Daten aus Tabellen zu importieren. Die Tabellen werden aus Vorlagen erstellt und können mit einem Tabellenkalkulationsprogramm (z.B. MS Excel) bearbeitet werden. Durch Verwendung von Formeln wird die einzugebende Datenmenge auf ein Minimum reduziert. Dadurch wird auch die Fehlerrate erheblich gesenkt.

    ipConv datapoint table import

Diagnose
  • Bei einem Protokollkonverter ist es wichtig, jederzeit auf einen Blick den Zustand der Kommunikation auf allen Schnittstellen feststellen zu können. Besonders dann, wenn kein mit dem System vertrautes Personal auf der Anlage verfügbar ist, muss auch ein Laie dazu in der Lage sein.

    Über den Button DIAGNOSTICS auf der ersten Seite können die Diagnoseinformationen abgerufen werden. Hier werden in einer klar gegliederten Form die wichtigsten Informationen in Klartext mit Uhrzeit angezeigt. Durch farbliche Hinterlegung wird signalisiert, ob der Zustand normal ist oder nicht.

    ipConv diagnostics

    Welche Informationen hier dargestellt werden, mit welchen Texten und in welcher Farbe, wird mittels Konfiguration festgelegt.

    Neben reinen Meldungen und Messwerten können hier auch Steuerbefehle, z.B. ein Button zum Auslösen einer Generalabfrage, dargestellt werden.

Logging
  • Bei Kommunikationsanwendungen ist es wichtig, jederzeit feststellen zu können, welche Daten über das Protokoll übertragen werden und wie die Daten von einem Protokoll in das andere konvertiert werden. Das ist besonders dann wichtig, wenn es Probleme bei der Übertragung gibt. ipConv verfügt über Fähigkeiten, alle Daten mitzuschreiben und diese zu archivieren.

    Zur Verfolgung des Systemzustands und des Informationsflusses innerhalb des Gateways bietet ipConv die Möglichkeit, alle bei den einzelnen Modulen anfallenden Informationen mitzuschreiben und für eine bestimmte Zeit zu archivieren. Folgende Daten können protokolliert werden:

    • Alle über das entsprechende Kommunikationsmodul gesendeten und empfangenen Daten zu/von ipConv
    • Systemmeldungen d.h. Verbindungsabbrüche, Kommunikationsfehlermeldungen etc.
    • Konfigurations- und Softwarefehlermeldungen
    ipConv data logging

    Der Umfang der Daten, die protokolliert werden, wird durch die Loggingebene festgelegt, die dynamisch (zur Laufzeit) oder statisch (in der Konfiguration) pro Modul verändert werden kann.

    Die Loggingebene legt fest, in welcher Form die gesendeten und empfangenen Daten dargestellt werden. Man kann die Daten sowohl in Rohform (d.h. Hexdarstellung) als auch in dekodierter, symbolischer Form anzeigen lassen oder beides. Das folgende Beispiel zeigt den Inhalt einer Logdatei erzeugt vom IEC 60870-5-101, Master-Protokollstack.

    Die Daten werden direkt im lesbaren ASCII-Format abgelegt. Die Logdateien können über das Webinterface angezeigt, durchsucht und zur Offline-Diagnose heruntergeladen werden.

    Alle protokollierten Daten werden zyklisch archiviert. Damit lässt sich die Kommunikation über Tage bzw. sogar über Wochen (in Abhängigkeit vom Datenaufkommen) verfolgen.

    29.01.20 11:38:15 IECAppl3 communication with link layer established !
    29.01.20 11:38:15 cid=1 open !
    29.01.20 11:38:15 cid=3 open !
    29.01.20 11:38:15 cid=4 open !
    29.01.20 11:38:15 cid=1 connected !
    29.01.20 11:38:15 CA=1: starting GI ...
    (2): << 15.473 [1] C_IC_NA_1 SQ=0 NUM=1 T=0 P/N=0 CT=<act> ORG=<0> CA=<65535>
                   0: QOI=<14> 
    29.01.20 11:38:15 CA=2: starting GI ...
    (2): >> 15.526 [1] M_DP_TB_1 SQ=0 NUM=4 T=0 P/N=0 CT=<spon> ORG=<0> CA=<1>
                 115: DIQ=<OFF  Q=OK> BT7=<29.01.20 11:38:04.980 STD> 
                 116: DIQ=<OFF  Q=OK> BT7=<29.01.20 11:38:04.980 STD> 
                 117: DIQ=<OFF  Q=OK> BT7=<29.01.20 11:38:04.981 STD> 
                 118: DIQ=<OFF  Q=OK> BT7=<29.01.20 11:38:04.981 STD> 
    (2): >> 15.527 [1] M_ME_NA_1 SQ=0 NUM=4 T=0 P/N=0 CT=<spon> ORG=<0> CA=<2>
                 142: NVA=<27944> QDS=<OK> 
                 143: NVA=<27968> QDS=<OK> 
                 144: NVA=<28013> QDS=<OK> 
                 145: NVA=<28095> QDS=<OK> 
    (2): >> 15.527 [1] M_DP_TB_1 SQ=0 NUM=1 T=0 P/N=0 CT=<spon> ORG=<0> CA=<1>
                 114: DIQ=<OFF  Q=OK> BT7=<29.01.20 11:38:06.982 STD> 
    (2): >> 15.527 [1] M_ME_NC_1 SQ=0 NUM=2 T=0 P/N=0 CT=<spon> ORG=<0> CA=<2>
                 135: SFP=<267> QDS=<OK> 
                 136: SFP=<140> QDS=<OK> 
    (2): >> 15.527 [1] M_SP_TB_1 SQ=0 NUM=1 T=0 P/N=0 CT=<spon> ORG=<0> CA=<133>
             7750142: SIQ=<OFF Q=OK> BT7=<29.01.20 11:38:07.430 STD> 
    29.01.20 11:38:15 ERROR: ASDU from CA=133, unknown CA or received on unexpected connection !
    (2): >> 15.527 [1] M_DP_TB_1 SQ=0 NUM=2 T=0 P/N=0 CT=<spon> ORG=<0> CA=<2>
                 118: DIQ=<ON   Q=OK> BT7=<29.01.20 11:38:07.981 STD> 
                 119: DIQ=<ON   Q=OK> BT7=<29.01.20 11:38:07.981 STD>
    (2): >> 15.527 [1] M_ME_NC_1 SQ=0 NUM=3 T=0 P/N=0 CT=<spon> ORG=<0> CA=<2>
                 137: SFP=<120> QDS=<OK> 
                 138: SFP=<226> QDS=<OK> 				 
    		
Simulation
  • Besonders hilfreich bei Signaltests während der Inbetriebsetzungsphase erweist sich die Fähigkeit von ipConv, alle Signale in einfacher, projektbezogener Form darstellen und simulieren zu können. Dadurch wird das Auffinden von Verdrahtungs- und Konfigurationsfehlern erheblich erleichtert.

    Alle Datenpunkte können in einer hierarchischen Form, die durch die Konfiguration vorgegeben wird, angezeigt werden. Die Benennung, Schachtelungstiefe und der Signalumfang sind frei wählbar und können projektspezifisch konfiguriert werden. Dadurch wird der Abruf von Informationen auch durch Personal möglich, das nicht mit ipConv bzw. dem entsprechenden Protokoll vertraut ist.

    testing signals, data and control commands with ipConv

    Neben dem Signalnamen wird der Informationstyp, Wert, Qualitätskennung und der Zeitstempel (falls vorhanden) angezeigt.

    Gleichzeitig können die Daten und Befehle direkt im Webbrowser simuliert werden. Dies ist besonders dann interessant, wenn nur ein Kommunikationspartner angeschlossen ist (Leitstelle oder RTU). Bei Vorabtests lassen sich so im Vorfeld die meisten Konfigurationsfehler ausräumen, auch wenn noch nicht die gesamte Kommunikationsstrecke in Betrieb ist.

Redundanz
  • Um auch erhöhten Sicherheitsansprüchen zu genügen, ist ipConv/Cloud mit Einsatz einer zweiten Instanz voll redundanzfähig.

    • Linienredundanz (hot-standby)
    • Informationsredundanz
    • Geräteredundanz (Parallelbetrieb)

    Bei redundant ausgeführten Protokollkonvertern kann die Ausfallsicherheit nach dem "hot-standby" Prinzip sichergestellt werden. Dabei übernimmt jeweils nur eine Instanz die aktive Rolle, während die passive Instanz die aktive überwacht und bei deren Ausfall die Initiative übernimmt.
    Dadurch können beispielsweise Ausfallzeiten durch Wartungsarbeiten, oder Ausfälle von Kompo­nenten und Schnitt­stellen minimiert werden.

    redundancy with ipConv/Cloud

    Die nebenstehende Abbildung zeigt die Ethernet-basierte Redundanzkopplung mit ipConv/Cloud.

Anforderungen
  • Die Linux-basierte Umgebung muss folgende Anforderungen erfüllen:

    • x86 64-Bit Architektur
    • Systemd Umgebung
    • OpenSSL Bibliothek, libcrypto ≥ 1.1.1n
    • NCurses Bibliothek, libncurses5 ≥ 5.7
    • Crypto Bibliothek, libcrypt1 ≥ 1.44
    • Admin- und allgemeine Benutzergruppen
    • Offener Port 22 für SSH-Zugang
    • Offener Port 443 für webbasierte Konfigurationsschnittstelle

    Die erforderlichen Ressourcen für eine Instanz hängen von der Größe des Projekts ab:

    • 4 CPU | 8 GB RAM | 4 GB Massenspeicher
      (Standardinstanz für normale und größere Projekte)
    • 1 CPU | 256 MB RAM | 4 GB Massenspeicher
      (Mindestanforderung für zwei Protokollstacks und eintausend Datenpunkte)

    Die Anwendung ipConv/Cloud wurde mit dem folgenden Linux-Image getestet:

    • Canonical, Ubuntu, 20.04 LTS, amd64 focal build on 2022-06-10, 64-Bit (x86)

    Die Wahl des Ubuntu-Linux-Images erfolgte aufgrund seiner Popularität und beruht nicht auf technischen Gesichtspunkten.

Verfügbare Protokollstacks

BACnet, Client

BACnet, Server

Database, Client

DNP V3.00, Master

DNP V3.00, Slave

ELCOM-90 Initiator, Client

ELCOM-90 Responder, Server

Simatic Fetch/Write, Master

IEC 60870-5-101, Master

IEC 60870-5-101, Slave

IEC 60870-5-104, Master

IEC 60870-5-104, Slave

IEC 61850, Client

IEC 61850, Server

MQTT, Publisher

MQTT, Subscriber

Modbus, Master

Modbus, Slave

Modbus TCP/IP, Master

Modbus TCP/IP, Slave

OPC DAXML 1.01, Server

OPC UA 1.02, Client

OPC UA 1.02, Server

S7 Protokoll, Client

SNMP, Client

TASE.2, Client

TASE.2, Server