Kommunikationsserver für die Feldebene

Die Schnittstellenvielfalt in Multi-Vendor-Umgebungen wächst weiterhin. Zu den etablierten seriellen Punkt-zu-Punkt-Verbindungen und Feldbus-Schnittstell kommt eine beständig anwachsende Anzahl echtzeitfähiger Industrial-Ethernet-Konzepte. Auf der Web-Seite [1] von Prof. Dr. Schwager der Hochschule Reutlingen werden inzwischen 19 verschiedene Verfahren vorgestellt. Zusätzlich verbreiten sich verschiedene Wireless-Technologien (Bluetooth, IEEE802.11-basiertes WLAN, ZigBee) in der Automatisierung. Konzepte und Lösungen für eine durchgängige und einheitliche Fernwartung (Remote Access) sind gegenwärtig Mangelware. Sie werden aber dringend benötigt, da jeder separate Fernwartungszugang (u.U. mit eigenem Modem oder Internet-Zugang) eine potenzielle Schwachstelle hinsichtlich der Anlagensicherheit und -verfügbarkeit darstellt und teilweise erhebliche Betriebskosten verursacht. Einführung Aus Sicherheits- und Kostengründen sollte es in einer Multi-Vendor-Anlage nur einen einzigen Zugangspunkt für die Fernwartung geben. Idealerweise sollte dieser Zugang auch die temporäre Anbindung mobiler Computer zulassen, um den Servicetechnikern der verschiedenen Hersteller den Zugang zu den Anlagenbestandteilen zu ermöglichen. Die Anforderungen an einen solchen Service-Gateway sind allerdings hoch. Auf der einen Seite muss diese Infrastruktur-Komponente alle erdenklichen Schnittstellen beherrschen, die man in der Feld- und Steuerungsebene vorfindet. Andererseits sind auch ausgefeilte Sicherheits-Mechanismen erforderlich, um die Anlage vor unberechtigten Zugriffen zu schützen und die Kommunikation zu verschlüsseln. Bild 2 illustriert ein mögliches Szenario mit einem Kommunikationsserver als Mittelpunkt. Durch einen solchen Server als Service-Gateway ist ein einheitlicher IP-basierter Fernzugriff (IP-based Remote Access) auf eine Multi-Vendor-Anlage realisierbar. In Richtung der Steuerungs- und Feldebene bietet der Gateway die jeweils benötigten Schnittstellen über ein Steckkartensystem. Die Kommunikation in dieser Ebene erfolgt in der Regel ungesichert. In Zielrichtung der Teleservice-Arbeitsplätze zur Fernwartung und der Zugangsschnittstelle für Servicetechniker erfolgt eine gesicherte Kommunikation mit Hilfe der TCP/IP-Protokolle SSH, SFTP und HTTPS. Der Datenverschlüsselung basiert auf SSL [2]. IP-Integration unterschiedlicher Schnittstellen In der Steuerungsebene findet man zunächst einmal verschiedene SPS-Systeme. Da es keine einheitliche Programmierschnittstelle gibt, werden hier Industrial Ethernet sowie konventionelle serielle Schnittstellen (RS232/ 422/485) für den Fernzugriff benötigt. Eventuell erforderliche PPI- bzw.- MPI-Spezialschnittstellen für S7-2xx- und S7-3xx-Steuerungen sind durch entsprechende Adapter realisierbar. In der Feldebene gibt es erfahrungsgemäß die größte Schnittstellenvielfalt. Neben dem Industrial Ethernet, teilweise in verschiedenen echtzeitfähigen Sondervarianten, findet man hier unterschiedliche Feldbusse, serielle Verbindungen auf Basis von RS232/422/485 und spezielle Sensor/Aktor-Schnittstellen, die nur über analoge oder digitale Ein-/Ausgänge angesprochen werden können. Der Kommunikationsserver kann für die seriellen Schnittstellen in der Steuerungs- und Feldebene als \“COM-Port Redirector\“ arbeiten. Ein solcher Redirector wird auf der einen Seite über einen internen UART (also dem physikalischen Baustein zur Realisierung einer seriellen Schnittstelle) mit der jeweiligen Funktionseinheit – z.B. einer SPS – verbunden (Bild 3). Die Gegenseite des COM-Port Redirectors ist mit einem IP-basierten Kommunikationskanal gekoppelt, an dessen Ende sich ein virtueller COM-Porttreiber (VCOM-Treiber) befindet, der z.B. auf dem Teleservice-Arbeitsplatz in Bild 1 läuft. Dieser Übertragungskanal kann beispielsweise durch ein Ethernet-LAN oder jede andere TCP/IP-fähige Verbindung gebildet werden. Sogar das Internet kommt als Verbindungsglied zwischen VCOM-Treiber und COM-Port Redirector in Frage. Mit anderen Worten: Durch einen virtuellen COM-Porttreiber und den dazu passenden COM-Port Redirector kann z.B. ein Windows-basierter Teleservice-Arbeitsplatz auf einen (sehr) weit entfernten COM-Port zugreifen, um einer SPS-Programmiersoftware ohne jede Änderung den Zugriff auf die SPS zu ermöglichen. Der Kommunikationsserver aus Bild 2 koppelt serielle Schnittstellen als COM-Port-Redirector vollständig transparent an IP-Netzwerke und ermöglicht so einen einheitlichen Fernzugriff. Da sich die meisten Feldbusse (z.B. Interbus und Profibus) per serieller Schnittstelle realisieren lassen, kann für den wartungsbedingten Fernzugriff ebenfalls das zuvor beschriebene Verfahren mit COM-Port-Redirector und virtuellem COM-Porttreiber genutzt werden. Eine Ausnahme bildet hier allerdings CAN. Dieser Feldbus lässt sich auf verschiedene Art und Weise an ein IP-basiertes Netzwerk anbinden. Kommt CANopen als Anwendungsprotokoll in der Steuerungs- oder Feldebene zum Einsatz, so empfiehlt sich die Umsetzung der CiA-Spezifikationen CiA309 (Interfacing CANopen with TCP/IP [3]). Der Service-Gateway in Bild 2 arbeitet in diesem Fall als CANopen-Gateway Server. Soll auf die unteren CAN-Protokollebenen per TCP/IP zugegriffen werden, so reicht beispielsweise eine Konvertersoftware, wie z.B. der Smart Command Line Interpreter (SCLI) des IGW/400-CAN [4]. Diese Software ermöglicht den transparenten Zugriff auf mehrere CAN-Feldbussysteme in der Steuerungs- und Feldebene über eine TCP-Socketverbindung [2]. Verfügen die Baugruppen in der Steuerungs- und Feldebene bereits über Industrial Ethernet-Schnittstellen, arbeitet der Kommunikationsserver in erster Linie als Proxy. Dabei ist die Umsetzung der unsicheren TCP/IP-Anwendungsprotokolle (z.B. Telnet, FTP, HTTP, TFTP) in die entsprechenden sicheren Varianten (SSH, SFTP, HTTPS) besonders wichtig. Weiterhin muss ein entsprechender Zugriffsschutz mit Nutzerprofilen für die Zugriffe der Anlagenbetreuer umgesetzt werden. Bild 4 illustriert die Absicherung der Zugriffe auf die ungesicherten HTTP-basierten Webserver in den Automatisierungskomponenten über das sichere HTTPS. Datenserver für Service und Wartung Durch die Verbindungen zu allen wichtigen Baugruppen in der Steuerungs- und Feldebene eignet sich ein Teleservice-Gateway auch als zentrale Datenbank zur Instandhaltung einer Anlage. Für die effektive Durchführung der Wartungs- und Servicearbeiten in Multi-Vendor-Anlagen wird aussagefähiges und aktuelles Datenmaterial benötigt. Schließlich ist in jedem Fall sicherzustellen, dass die Servicemitarbeiter der einzelnen Hersteller die jeweils erforderlichen Arbeiten ausführen können, ohne die Baugruppen der anderen Hersteller in ihrer Funktion zu beeinträchtigen. Eine zentrale Datenbank ist hier ein wichtiges Hilfsmittel. Insgesamt kann ein Teleservice-Gateway als Datenserver [5] vier wichtige Datenbankaufgaben übernehmen: 1. Abspeichern aller Alarm- und Störungsmeldungen: Sämtliche relevanten Meldungen einer Anlage sollten mit einem entsprechenden Zeitstempel versehen und in einer Datenbank gespeichert werden. Dadurch steht im Fall eines Anlagenstillstands die Vorgeschichte zur Verfügung. 2. Erfassen wichtiger Betriebsparameter: Neben den Betriebszeiten als Grundlage für eine proaktive (vorausschauende) Wartung können wichtige Betriebsparameter, wie die Temperaturen einzelner Baugruppen, Spannungsschwankungen und -unterbrechungen, Drehzahlüberschreitungen und wichtige Benutzereingriffe (z.B. das Herunter- und Hochfahren einer Anlage) in der Datenbasis des Teleservice-Gateway gespeichert werden. 3. Zentrales Speichern der Konfigurationsdaten: Zu den meisten Baugruppen einer Anlage gehören spezifische Konfigurationsdaten, durch die die Baugruppe für den Einsatz in einer bestimmten Anlage angepasst wurde. Diese Daten sollten auf dem Datenserver zur Verfügung stehen. 4. Protokollieren aller Servicearbeiten: Häufig ergeben sich Störungen direkt nach Service- und Wartungsarbeiten. Daher ist es gerade in einer Multi-Vendor-Anlage besonders wichtig, ein virtuelles Log-Buch über alle durchgeführten Arbeiten zu führen. Dadurch lassen sich komplexere Fehlerquellen viel schneller aufspüren. Weiterhin kann auf einem solchen Datenserver auch ein übersichtliches Abbild der jeweiligen Anlage abgelegt werden, damit jeder Servicetechniker schnellstmöglich den notwendigen Überblick zu den Gesamtzusammenhängen erhält. In der IT-Welt findet man mit dem Dreiergespann Apache (Webserver), mySQL (Datenbank) und PHP (Skriptsprache) die wichtigs-ten Grundbausteine zur Realisierung eines solchen Datenservers für Wartungs- und Serviceaufgaben in einer Multi-Vendor-Anlage. Der Ressourcenbedarf dieses Triumvirats ist relativ gering. Mit der richtigen Hard- und Softwareplattform reicht eine Flash-Speicherkarte mittlerer Größe als physikalisches Speichermedium aus, um die Datenbank direkt vor Ort in einem Schaltschrank zu betreiben (mit Hilfe der unternehmensweiten durchgängigen Vernetzung wird selbstverständlich eine Datenbankkopie auf den Festplatten der Unternehmens-IT abgelegt). Bild 5 illustriert das Zusammenspiel der Komponenten. Apache ist ein sehr leistungsfähiger Webserver, der für die Internetpräsenz unzähliger Websites benutzt wird. Zu den herausragenden Merkmalen von Apache gehören die Erweiterungen und Schnittstellen zu anderen Softwarepakten (MySQL, PHP, Java usw.). MySQL bildet ein hochleistungsfähiges, aber kompaktes SQL-Datenbankmanagementsystem, das unter einer freien Lizenz (GPL) zur Verfügung steht. Es gestattet den Aufbau und die Verwaltung von SQL-Datenbanken. PHP bildet als Skriptsprache ein Bindeglied zwischen einer MySQL-Datenbank und dem Web-basierten Zugriff auf diese Daten per Apache. Die zentrale Datenbank mit den Alarm- und Störungsmeldungen, Betriebsparametern, Konfigurationsdaten und den Protokollen durchgeführter Service- und Wartungsarbeiten einer Multi-Vendor-Anlage wird im Dateisystem des Teleservice-Gateways durch my-SQL verwaltet. Sämtliche Zugriffe auf diese Datenbank durch Servicetechniker erfolgen ausschließlich über das Web-Interface. Der Techniker benötigt dafür nur ein Notebook mit Web-Browser. Das Web-Interface für den Technikerzugriff wird durch Apache gebildet. Der Zugriff auf die gewünschten Daten erfolgt per PHP. Softwaremodule, die mit Hilfe dieser Skriptsprache erstellt wurden, erzeugen auf Anforderung dynamische Webseiten mit Inhalten aus der SQL-Datenbank. Quellenangaben [1] Website der Hochschule Reutlingen: www.real-time-ethernet.de [2] Walter: Embedded Internet in der Industrieautomation. Hüthig, Heidelberg 2004. [3] Website der CiA (CAN in Automation): www.can-cia.org [4] Produktbeschreibungen zum IGW/400-CAN: www.ssv-comm.de.