DE19739297A1 - Automatisierungssystem und Steuervorrichtung zur transparenten Kommunikation zwischen verschiedenen Netzwerken - Google Patents

Description

Die Erfindung betrifft ein Automatisierungssystem gemäß dem Oberbegriff des Anspruchs 1 und eine Anschaltvorrichtung gemäß dem Oberbegriff der Ansprüche 13 und 14.

Es sind heterogene Automatisierungssysteme bekannt, die ein Leitnetzwerk, beispielsweise das Ethernet, und mehrere dem Leitnetz untergeordnete Feldbusse, z. B. einen InterBus-S, umfaßt. Die Anbindung eines Feldbusses an das Ethernet erfolgt über sogenannte Gateways. Die an das Ethernet angeschlossenen Geräte kommunizieren über das TCP/IP-Pro­ tokoll miteinander, während die an die Feldbusse angeschalteten Geräte jeweils verschiedene Kommunikationsprotokolle verwenden können. Allerdings sind die bekannten Gateways nicht in der Lage, eine transparente Kommunikation zwischen den an das Ethernet angeschalteten Geräten und den an die untergeordneten Feldbusse angeschlossenen Geräte über das TCP/IP-Protokoll zu ermöglichen.

Der Erfindung liegt daher die Aufgabe zugrunde, ein System und eine Anschaltvorrichtung bereitzustellen, mit deren Hilfe die Kommunikation insbesondere bei der Inbetriebnahme, der Konfiguration und der Wartung des Systems im gesamten Automatisierungssytem vereinfacht wird.

Das technische Problem löst die Erfindung zum einen mit den Merkmalen des Anspruchs 1.

Der Kerngedanke der Erfindung ist darin zu sehen, eine Datenkommunikation unter Anwendung eines gemeinsamen Protokolls über das Leitnetz und alle damit verbundenen Feldbusse zu ermöglichen. Insbesondere soll das TCP/IP-Pro­ tokoll und seine Dienste eine solche einheitliche Kommunikation zwischen dem Leitnetz und den untergeordneten Feldbussen sicherstellen.

Dazu umfaßt das Automatisierungssystem ein erstes physikalisches Netzwerk, in dem alle angeschlossenen Einrichtungen auf der Grundlage eines ersten Kommunikationsprotokolls kommunizieren können und wenigstens ein zweites, über eine erste als Gateway fungiernde Steuereinrichtung mit dem ersten Netzwerk verbundenes physikalisches Netzwerk, in dem alle daran angeschalteten Einrichtungen auf der Grundlage eines zweiten Kommunikationsprotokolls kommunizieren können, wobei das erste und das zweite Netzwerk sowie das erste und zweite Kommunikationsprotokoll verschieden sind. Jeder ersten Steuereinrichtung ist eine logische Schnittstelle zugeordnet, die eine im wesentlichen transparente Kommunikation zwischen wenigstens einer an das erste Netzwerk angeschalteten Einrichtung und wenigstens einer an das zweite Netzwerk angeschalteten Einrichtung auf der Grundlage des ersten Kommunikationsprotokolls ermöglicht. Es sei angemerkt, daß das zweite Netzwerk auch eine einfache serielle Verbindungsleitung zu einem tragbaren Rechner sein kann.

Die logische Schnittstelle unterstützt insbesondere alle Inbetriebnahme-, Wartungs- und Archivierungsaufgaben. Mit Hilfe dieser Schnittstelle können Steuerungsprogramme, Visualisierungsdaten sowie weitere anlagenspezifische Datensätze zu den entsprechenden Einrichtungen transferiert und im laufenden Betrieb Diagnosedaten erfaßt werden, bzw. zur Archivierung in ein überlagertes Rechnersystem transferiert werden.

Vorteilhafte Weiterbildungen sind in den Unteransprüchen umschrieben.

Eine, ein Gateway enthaltende Steuervorrichtung ist in den nebengeordneten Ansprüchen 13 und 14 angegeben.

Die Erfindung wird nachfolgend anhand der Ausführungsbeispiele in Verbindung mit den Zeichnungen näher erläutert. Es zeigen:

Fig. 1 die prinzipielle Struktur eines heterogenen Automatisierungssystems, in dem die Erfindung verwirklicht ist,

Fig. 2 eine erfindungsgemäße Steuereinrichtung nach Fig. 1, die zwei untergeordnete Feldbusse mit dem Ethernet verbindet,

Fig. 3 die Softwarestruktur der Steuereinrichtung nach Fig. 2,

Fig. 4 den Industrie-PC nach Fig. 1, der über den Interbus mit zwei untergeordneten Steuerungseinrichtungen verbunden ist,

Fig. 5 die Softwarestruktur auf dem Industrie-PC und einer untergeordneten Steuerungseinrichtung nach Fig. 4, die über einen Interbus verbunden sind.

Die Struktur eines heterogenen Automatisierungssystems 10 ist vereinfacht in Fig. 1 dargestellt. An ein übergeordnetes Netz, in unserem Beispiel das Ethernet 17, ist ein PC-System 15 und eine z. B. UNIX-Workstation 20 über jeweils einen Ethernet-Anschluß angeschaltet. Darüber hinaus ist ein Industrie-PC 25 und eine speicherprogrammierte Steuereinrichtung 30, eine sogenannte Anschaltbaugruppe, an das Ethernet 17 angeschaltet, die über eine Gateway-Funk­ tionalität verfügen. In den Industrie-PC 25 sind beispielsweise zwei Anschaltkarten 40, 42 eingesteckt, die einen Feldbus 44 bzw. 46 mit dem Ethernet 17 verbinden. Bei dem Feldbus handelt es sich beispielsweise um den InterBus-S. Eine RFC (Remote Field Control)-Steuereinrichtung 50, die ebenfalls über eine Gateway-Funktionalität verfügt, verbindet den Interbus 44 mit einem weiteren Interbus 52. Die Anschaltbaugruppe 30 verbindet einen weiteren Interbus 54 mit dem Ethernet 17. Es sei angemerkt, daß beliebig viele Feldbusse miteinander oder mit dem Ethernet 17 verbunden sein können. An den Interbus 54 sind neben Eingabe-/Ausgabe-Bau­ gruppen 56, Identifizierungssysteme 54 auch Bedienterminals 57 mit einfachen Visualisierungsmöglichkeiten und ein Roboter 60 angeschaltet. An den Interbus-S ist beispielsweise eine Identifizierungseinrichtung 58 und ein Bedienelement 59 angeschaltet.

Alle Geräte, die miteinander kommunizieren können, bilden zusammen ein logisches Netzwerk. Voraussetzung für eine Kommunikationsbeziehung zwischen Geräten in einem logischen Netzwerk ist neben der physikalischen Verbindung in erster Linie ein gemeinsames Kommunikationsprotokoll.

Das Ethernet 17 benutzt als Kommunikationsprotokoll das TCP/IP-Protokoll, über das der PC 15, die Workstation 20, der Industrie-PC 25 und die Interbus-Anschaltbaugruppe 30 miteinander kommunizieren können.

Folgende Funktionen werden von dem TCP/IP-Protokoll über das Ethernet 17 im allgemeinen unterstützt:

• a) Herunterladen von Steuerungsprogrammen und Konfigurationsdaten über das Ethernet auf die INTERBUS Anschaltkarten 40, 42 des Industrie-PCs 25 oder der Anschaltbaugruppe 30 mit Ethernt-Schnittstelle,
• b) Archivierung von Programmen und Parametersätzen in der Workstation 20,
• c) Diagnose der angeschalteten Feldbusse 44, 50 und 52 und
• d) Übertragung von Visualisierungsdaten über das Ethernet.

Der Interbus 44, 54 oder 52 benutzt neben einem Prozeßdatenkanal einen Parameterkanal zur Übertragung von Daten. Über den Parameterkanal können komplexe und umfangreichere Daten zwischen zwei Interbus- Teilnehmern übertragen werden. Dieser Kanal wird insbesondere verwendet, um beispielsweise die Displays von den Bedienterminals zu aktualisieren, oder um Steuerungsprogramme auf die unterlagerte Steuereinrichtung 50 über den Interbus 44 zu übertragen. Das Kommunikationsprotokoll, das für die Datenübertragung über den Parameterdatenkanal des Interbus verwendet wird, heißt Peripheral Communication Protocol (PCP).

In Fig. 2 ist ein Ausschnitt aus dem Szenario nach Fig. 1 dargestellt. Der Industrie-PC 25, der in diesem Fall als Steuerungsrechner fungiert, ist über das Ethernet 17 mit dem übergeordneten Rechnersystem 15 verbunden. Ein Engineering-Rechner 70, der hier stilisiert als Laptop dargestellt ist, realisiert eine Verbindung zum Industrie-PC 25 über eine serielle Verbindung (V24). Die Steuerung der Interbusse 44 und 46 wird mit Hilfe der beiden verschiedenen PC-Anschaltkarten 40, 42 im Steuerungsrechner 25 umgesetzt. Die PC-Anschaltkarte 40 sei beispielsweise die IBS ISA FC/I-T und die PC-An­ schaltkarte 42 die IBS ISA FC/486 DX/I-T mit einem Coprozessor. Zusätzlich beinhaltet der Industrie-PC 25 neben den standardmäßig vorhandenen Massenspeichern, eine (PCMCIA) PC-Karte als Speichermedium für alle Steuerungsprogramme und die wesentlichen Konfigurationsdaten z. B. für die Visualisierung.

Die erfindungsgemäße einheitliche Kommunikationsstruktur auf der Basis von TCP/IP vereinfacht im wesentlichen die folgenden Datenübertragungen:

Herunterladen und Hinaufladen von Steuerungsprogrammen,
die Übertragung von Konfigurationsdaten für Steuerungen und Visualisierungen,
die Übertragung von Diagnosedaten und
die Übertragung von Daten an die Anzeigeeinrichtung der Bedienterminals.

Die nachfolgend in Verbindung mit Fig. 3 beschriebene Softwarestruktur ist auf dem Industrie-PC 25 notwendig, um die erfindungsgemäße TCP/IP-Kommunikationsstruktur zu unterstützen.

Um die Kommunikation zwischen dem Industrie-PC 25 und dem übergeordneten PC 15 zu verdeutlichen, ist auch dieser in der Fig. 3 dargestellt. Der Engineering-Rechner 70 ist nicht gezeigt. Er verhält sich aber kommunikationstechnisch wie der Industrie-PC 25, mit dem Unterschied, daß eine Verbindung zwischen dem Industrie-PC 25 und Engineering-Rechner 70 in diesem Beispiel über die serielle Schnittstelle erfolgt.

Im oberen Bereich der Fig. 3 ist der übergeordnete PC 15 schematisch dargestellt. PC WORX kann auf diesem PC 15 beispielsweise verwendet werden, um Diagnosedaten vom unterlagerten Industrie-PC 25 zu holen, oder um die unterlagerten Interbusse 44, 52 und 54 zu visualisieren.

Im mittleren Bereich der Fig. 3 ist die Softwarestruktur des Industrie-PCs 25 dargestellt. Eine Kommunikation auf der Basis des TCP/IP-Protokolls kann über den Ethernet-Netz­ werkanschluß und/oder über eine serielle Schnittstelle des Hauptrechners 80 des Industrie-PCs 25 ermöglicht werden. Über die serielle Leitung wird das Point-to-Point-Pro­ tocol (PPP) unterstützt. Dieses Protokoll kapselt das TCP/IP-Protokoll in eine geeignete Form, so daß eine serielle Übertragung (beispielsweise über ein Modem) möglich ist.

Auf dem Industrie-PC 25 kann ein Visualisierungsprozeß laufen, der z. B. über das Open Com Interface (OCI) auf Daten des Prozesses zugreift. Sollen diese Daten an einen überlagerten, an das Ethernet 17 angeschalteten Visualisierungsrechner übertragen werden, muß auf dem Industrie-PC 25 ein Serverprozeß (Ethernet-DDI-Server, nicht abgebildet) laufen, der die über das Ethernet 17 empfangenen DDI-Kommandos an die Gerätetreiberschnittstelle DDI (engl.: De­ vice Driver Interface) durchreicht. SYSTEM WORX ist in der Lage, DDI-Dienste per Datagramm über das Ethernet 17 zu übertragen. Über diesen Weg kann auch die Visualisierung des PC WORXremote mit Daten versorgt werden. Über einen Loader können Steuerungsprogramme und die notwendigen Konfigurationsdaten auf die Anschaltkarten 40,42 heruntergeladen werden. Dieser Vorgang kann allerdings nicht von einem entfernten Host initiiert werden.

Downloads und Uploads von Daten können in dem TCP/IP-basierten Ethernet mit Hilfe des FTP-Dien­ stes realisiert werden. Da dieser Dienst eine Client/Server-Struktur vorsieht, muß auf dem Zielsystem immer ein FTP-Server verfügbar sein. Mit Hilfe eines FTP-Clients können dann Daten an und vom Industrie-PC 25 übertragen werden. Windows NT bietet standardmäßig einen im System integrierten FTP-Client. Mit Hilfe des FTP-Dienstes können Steuerungsprogramme sehr komfortabel auf den Industrie-PC heruntergeladen werden. Der FTP-Server verwendet dabei das Dateisystem (oder eine PC-Karte) des Industrie-PCs, um die empfangenen Daten zu speichern. Von dort kann ein IB-Loader verwendet werden, um die Programme auf die Anschaltkarten 40, 42 zu transferieren. Um eine möglichst einheitliche und durchgängige Kommunikationsinfrastruktur im gesamten Automatisierungssystem 10 zu erreichen, müssen Steuerungsprogramme und Konfigurationsdaten mit dem FTP-Dienst auf die PC-Anschaltkarten 40, 42 heruntergeladen werden. Die hierfür notwendigen Anpassungen sind abhängig von der unterlagerten PC-Anschaltkarte 40, 42.

Die in Fig. 3 gezeigte Anschaltkarte 42 mit einem Coprozessor 85, wie die IBS ISA FC/486 DXfl-T oder die IBS S7/400 DSC/ETH, bietet die Möglichkeit, einen eigenen TCP/IP-Protokollstapel zu implementieren, und sie besitzet somit auch eine eigene IP-Adresse, mit der sie eindeutig in dem Automatisierungssystem 10 identifiziert werden kann. Hat der Coprozessor 85 keinen Ethernet-An­ schluß, so ist die einzige Schnittstelle, die den Coprozessor 85 mit dem überlagerten Hauptrechner 80 verbindet, ein Mehrtorspeicher MPM (engl.: Multi Port Memory). Deshalb müssen alle über den FTP-Dienst transferierten Daten über das MPM übertragen werden. Auf dem Coprozessor 85 müssen diese Daten über Dienste des DDI geholt werden und wieder in TCP/IP-Rahmen umgesetzt werden. Diese Aufgabe obliegt einem speziellen Serverprozeß, der auf dem Coprozessor 85 unter VxWorks läuft. Über den TCP/IP-Protokollstapel können die Daten dann an einen FTP-Server, der zusätzlich auf dem Coprozessor 85 läuft, durchgereicht werden. Auf dem überlagerten Hauptrechner 80 muß zudem ein spezieller TCP/DDI-NDIS-Treiber vorhanden sein. Daten, die über die Ethernet-Schnittstelle oder über PPP von der seriellen Schnittstelle kommen und für die unterlagerte PC-Anschaltkarte 42 bestimmt sind, müssen direkt auf diesen Treiber umgeleitet (geroutet) werden. Dies ist allerdings nur dann realisierbar, wenn im Industrie-PC 25 eine entsprechende Routinginformation zur Verfügung steht.

Weist der Coprozessor 85 der Anschaltkarte 42 hingegen einen Ethernet-Anschluß auf, übernimmt der auf diesem Coprozessor 85 arbeitende TCP/IP-Stapel alle diese Aufgaben.

Im Gegensatz zur Anschaltkarte 42 mit dem Coprozessor 85 verfügt die einfache Anschaltkarte 40 nicht über genügend Ressourcen, um einen eigenen TCP/IP-Protokollstapel zu ermöglichen. Da sie folglich auch keine IP-Adresse besitzen kann, muß ein sogenannter Stellvertreter oder Proxy-Server auf dem übergeordneten Hauptrechner dafür sorgen, daß die Anschaltkarte 40 im Automatisierungssystem 10 adressiert werden kann. Ein solcher Proxy-Server übernimmt die Rolle eines FTP-Servers, empfängt die heruntergeladenen Daten stellvertretend für die unterlagerte Anschaltkarte 40, und transferiert diese Daten dann über das MPM mit Hilfe der hierfür erforderlichen Dienste eines Interbus-Masters.

Fig. 4 zeigt einen einen Ausschnitt des Automatisierungssystems 10 nach Fig. 1, in dem der überlagerte Industrie-PC 25 über den Interbus 44 mit der unterlagerten Steuerungseinrichtung 50 und einer weiteren unterlagerten Steuerungseinrichtung 90 verbunden ist. Bei den direkt unterlagerten Steuerungseinrichtungen 50 und 90 handelt es sich beispielsweise um eine Fernfeld-Steu­ ereinrichtung RFC (engl.: Remote Field Controller (IBS 24RFC/ 486 DX) und zum anderen um einen Steuerungs-PC 90 mit einer Interbus-PC-Anschaltbaugruppe. Der unterlagerte Steuerungs-PC 90 steuert einen Interbus 92, in den wiederum eine dezentrale Steuerungseinrichtung 95 (IBS RT 24 DIO 16/16-T) als Slave integriert ist.

Steuerungsprogramme und Konfigurationsdaten sollen mit Hilfe des FTP-Dienstes vom übergeordneten Industrie-PC 25 über den Interbus 44 auf die unterlagerten Steuerungseinrichtungen 50, 90 heruntergeladen werden. Erforderlich ist hierzu die Übertragung der TCP/IP-Datenblöcke über den Interbus 44. Damit Interbus-Teilnehmer über den TCP/IP-Dienst FTP direkt angesprochen werden können, müssen sie eine IP-Adresse haben. Die Steuerungseinrichtungen 50 und 90 besitzen genügende Ressourcen, um einen eigenen vollwertigen TCP/IP-Protokollstapel zu ermöglichen, mit dem eine IP-Adresse assoziiert werden kann. Da als Übertragungsmedium zwischen dem übergeordneten Industrie-PC 25 und den unterlagerten Steuerungseinrichtungen 50 und 90 der Interbus 44 fungiert, kann der Zugriff auf die unterlagerten Steuerungseinrichtungen 50, 90 nicht mit den Standardverfahren realisiert werden, die in dem Ethernet 17 selbstverständlich sind. Zwischen dem Ethernet 17 und dem Interbus 44 muß insofern ein Gateway dafür sorgen, daß die Verbindung zustande kommt. Die IP-Adressen aller Interbus-Teilnehmer müssen in einem dem Interbus 44 übergeordneten Namensserver abrufbar sein.

Da die Interbus-Teilnehmer keine regulären Ethernet-Geräte sind, muß der Namensserver ebenso die für den jeweiligen Interbus-Teilnehmer zuständigen Steuerungsrechner beinhalten. Mit anderen Worten ist in dem Namensserver die IP-Adresse beispielsweise der Steuereinrichtung 50 und die der Identifizierungseinrichtung 58 und des Bedienterminals 59 abgelegt. TCP/IP-Dienste, die z. B. an den Teilnehmer 58 des Interbusses 52 gerichtet sind, gehen zuerst an den zuständigen Proxy-Server der Steuereinrichtung 50. Die IP-Adresse wird dann auf eine Interbus-spezifische Kommunikationsreferenz abgebildet, mit der eine Verbindung zwischen zwei Interbus-Teil­ nehmern über den Parameterdatenkanal beschrieben wird. Die empfangenen TCP/IP-Datenblöcke werden dann in PPP-Rahmen gekapselt und mit Hilfe einer Sequenz von PCP-Dienstaufrufen (Fragmentierung der Daten) an den entsprechenden Interbus-Teilnehmer 58 Übertragen. Die Übertragung der Daten kann entweder vom Proxy-Server selbst oder mit einem entsprechenden PPP/PCP-NDIS-Treiber in der Steuerungseinrichtung 50 vorgenommen werden.

Auf der unterlagerten Steuerungseinrichtung 50 und 90 muß ein Treiber oder Server-Prozeß) vorhanden sein, der über die Interbus- Slave-Anschaltung Zugriff auf den Parameterdatenkanal besitzt. Dieser Treiber wandelt die PCP-Rahmen wieder in TCP/IP-Rahmen (bzw. PPP-Rahmen) um. Über den TCP/IP-Protokollstapel gelangen die Daten dann beispielsweise an einen FTP-Server. Das Ergebnis des Dienstaufrufs wird vom Interbus-Teilnehmer über den Parameterdatenkanal entweder über den Treiber oder direkt an den Proxy-Server der entsprechenden als Gateway fungierenden Steuereinrichtung zurück geliefert. Von dort werden die Daten dann an das aufrufende System übertragen.

Die Übertragung von Daten an einfache dezentrale Steuerungseinrichtung (nicht dargestellt), die nicht genügend Ressourcen besitzet, um einen TCP/IP-Protokollstael zu ermöglichen, ist wiederum über den Proxy-Server auf der jeweiligen Steuereinrichtung möglich. Da die unterlagerte Steuerungseinrichtung nicht TCP/IP-fähig ist, muß ihr eine virtuelle IP-Adresse zugeordnet werden. Diese sollte, wie auch alle realen IP-Adressen, im gesamten Automatisierungssystem 10 eindeutig sein und vom zentralen Namensserver verwaltet werden. Das Herunterladen von Steuerungsprogrammen von einer übergeordneten Steuerungseinrichtung über den TCP/IP-Dienst FTP wird über den Proxy-Server umgesetzt. Stellvertretend für die unterlagerte Steuerungseinrichtung wird der FTP-Dienstaufruf vom Proxy-Server bearbeitet. Über die Abbildung der virtuellen IP-Adresse auf die Kommunikationsrerefenz bestimmt der Proxy-Server den richtigen Interbus-Teilnehmer und emuliert den FTP-Dienst, indem die entsprechenden Interbus-Dienstaufrufe (DDI) verwendet werden, die für ein Herunterladern der Software auf die Anschaltung notwendig sind. Die Ergebnisse des Herunterladens werden über den Proxy-Server in adäquater Form (FTP-konform) an den FTP-Client zurückgegeben.

In Fig. 5 ist die grobe Softwarestruktur für den als Gateway fungierenden Industrie-PC 25 und die unterlagerte Steuerungseinrichtung 50 vom Typ IBS 24 RFC/DX486 mit dem TCP/IP-Protokollstapel zu sehen.

Handelt es sich bei der unterlagerten Steuerungseinrichtung 50 um eine PC-basierte Steuerungseinrichtung, die den unterlagerten Interbus 52 steuert, dann befinden sich mindestens zwei Interbus-Anschaltungen in diesem System. Über eine Slave-Anschaltung ist die Steuerungseinrichtung 50 mit dem übergeordneten Interbus 44 verbunden. Die Steuerung des unterlagerten Interbus 52 übernimmt eine Master-Anschaltung.

Die über den Parameterdatenkanal des Interbusses 44 empfangenen Daten werden über einen PCP/PPP-NDIS-Treiber wieder in PPP-Rahmen umgewandelt und über den TCP/IP-Protokollstack zum Beispiel an den FTP-Server durchgereicht.

Damit Daten auch über mehrere als Gateways fungierende Steuereinrichtungen - beispielsweise die Steuereinrichtungen 25 und 50- hinweg an unterlagerte Interbusse transportiert werden können, muß auf jedem, zwei Interbusse verbundenen Gateway, das TCP/IP oder TCP/IP über PCP unterstützt, ein Interbus Proxy-Server vorhanden sein. Der Proxy-Server verwaltet alle unterlagerten Interbus-Teil­ nehmer, die PCP unterstützen. Damit diese Teilnehmer mit einem TCP/IP-Dienst angesprochen werden können, muß der Proxy-Server die IP-Adressen der unterlagerten Teilnehmer kennen und auf eine Interbus-spezifische Kommunikationsreferenz abbilden können. Der Proxy-Server verwendet einfache Namenstabellen, um unterlagerte Steuerungseinrichtungen und Interbus-Teilnehmer über den Interbus mit TCP/IP-Dienste wie FTP anzusprechen. Eine Kommunikation mit überlagerten Steuerungseinrichtungen ist nur dann möglich, wenn die unterlagerte Steuerungseinrichtung Kenntnis darüber besitzen, wie überlagerten Steuerungseinrichtungen zu erreichen sind (über welche Gateways etc.)
In einem Interbus wird die Verbindung zum überlagerten Gateway grundsätzlich über die Master-An­ schaltung des entsprechenden Interbus-Subnetzes erreicht. Das direkt übergeordnete Gateway kann von unterlagerten Busteilnehmern somit problemlos angesprochen werden. Verbindungen zu überlagerten Systemen über mehrere Gateways hinweg sind nur dann möglich, wenn der jeweilige Teilnehmer die notwendige Route kennt. Sinnvollerweise wird die hierfür notwendige Logik in den Proxy-Server verlagert, der auf jedem Gateway notwendig ist. Da der Proxy-Server Kenntnis über die Adressen der gesamten unterlagerten Interbus-Teilnehmer und über die Adresse des nächsten überlagerten Gateways besitzt, werden Dienste, die an andere IP-Adressen gehen grundsätzlich zum nächsten Gateway durchgereicht, bis die zuständige Steuerungseinrichtung gefunden ist. Auf der Ebene des Ethernets sorgt der spezielle Namensserver, der die gesamten IP-Adressen des Automatisierungssystems verwaltet, dafür, daß alle IP-Adressen (auch die virtuellen Adressen) aufgelöst werden, bzw. das die korrekten Routen identifiziert werden.

Eine wesentliche Voraussetzung für die Integration von Feldbus-Teilnehmern in eine Kommunikationsstruktur auf der Basis von TCP/IP ist zum einen die physikalische Verbindung zwischen Netzwerk und Teilnehmer und zum anderen die eindeutige IP-Adresse des jeweiligen Teilnehmers im Netzwerk. Die physikalische Verbindung zwischen den unterschiedlichen Übertragungsmedien (wie zum Beispiel Ethernet und Interbus) kann, wie bereits beschrieben, über Gateways umgesetzt werden. Hier kommen entweder PC-basierte Steuerungseinrichtungen mit Netzwerkkarte und Interbus-Anschaltungen, oder Ethernet-RFC (IBS 24 RFC/486DX/ETH-T) zum Einsatz. Die Verbindung zwischen einem überlagerten und einem unterlagerten Interbus wird auch mit Hilfe von als Gateways fungierenden Steuereinrichtungen umgesetzt, obwohl beide physikalischen Übertragungsmedien identisch sind. Gateways sind im Automatisierungssystem 10 grundsätzlich Steuerungseinrichtungen, die einen unterlagerten Feldbus steuern. Je nach Art des unterlagerten Feldbus-Teilnehmers erfolgen Datenübertragungen (wie Downloads und Uploads) zwischen Gateway und diesem entweder über
TCP/IP,
TCP/IP über PCP (PCP+),
oder PCP.

Steuerungseinrichtungen, die keinen eigenen TCP/IP-Protokollstapel besitzen, müssen über virtuelle IP-Adressen angesprochen werden können. Das Gateway muß als Stellvertreter des unterlagerten
Busteilnehmers eine entsprechende Namenszuordnung umsetzen. Über die Anschaltbaugruppe des Gateways können Kommunikationsreferenzen definiert werden, mit denen PCP -Verbindungen zwischen zwei PCP-fähigen Busteilnehmern charakterisiert sind. Prinzipiell kann über die Anschaltbaugruppe eine PCP-Kommunikation zu jedem Busteilnehmer mit PCP-Fähigkeit aufgebaut werden. Mit Hilfe einer geeigneten Abbildungsfunktion von Kommunikationsreferenz auf virtuelle IP kann einem Busteilnehmer eine eindeutige IP-Adresse zugeordnet werden. Diese Abbildung wird in einem übergeordneten Namensserver und auf dem jeweiligen Gateway-Rechner verwaltet.

Für die Realisierung dieser Struktur müssen im wesentlichen drei Softwarekomponenten umgesetzt werden:
Interbus-Proxy-Clients für alle direkt im Netzwerk befindlichen Rechnersysteme,
Interbus Proxy-Server für die entsprechenden Gateway-Rechner,
PCP/PPP-NDIS-Treiber für PC-basierte Rechnersysteme, die über eine Slave-Anschaltung mit dem Interbus und somit mit dem Gateway verbunden sind,
PCP/PPP-Server-Prozeß für dezentrale Steuerungen wie der IBS 24 RFC/486DX.

Interbus Proxy-Clients müssen zwischen realen und virtuellen IPs unterscheiden. Die meisten TCP/IP-Dienste, wie Telnet, Ping, oder FTP, erfordern die Angabe einer IP-Adresse, die kennzeichnet, welcher Host angesprochen werden soll. Unter Windows NT und in vielen anderen Betriebssystemen wird eine spezielle Softwarebibliothek (Socketlibrary) verwendet, um netzwerkspezifische Funktionen, wie Verbindungsaufbau, Datenübertragungen und die Namensauflösung durchführen zu können. Da alle TCP/IP-Standarddienste diese Bibliothek verwenden, muß der Proxy-Client noch vor dem Aufruf der Funktionen der eigentlichen Socket-Bibliothek die aufgerufene IP-Adresse überprüfen, um zu testen, ob es sich um eine virtuelle oder eine reale IP handelt. Im Falle einer realen IP-Adresse können alle Funktionsaufrufe an die Socketbibliothek durchgereicht werden. Im Gegensatz dazu muß bei einer virtuellen IP-Adresse der Dienst an einen Interbus Proxy-Server durchgereicht werden, da das gewählte Gerät ein Teilnehmer des Interbus und insofern nicht direkt im Netzwerk erreichbar ist. Den zuständigen Proxy-Server kann der Proxy-Client entweder über eine lokale oder eine zentrale Abbildungstabelle in einer Datenbank (Namensserver) ermitteln. Diese Tabelle beinhaltet alle einem Proxy-Server zugeordneten virtuellen IP-Adressen.

Neben der Verwendung virtueller IP-Adressen, besteht auch die Möglichkeit, einer Netzwerkkarte mehrere IP-Adressen zuzuordnen. Ein Gateway-Rechner könnte in diesem Fall alle IP-Adressen der unterlagerten Interbus-Teilnehmer auf die eigene Netzwerkkarte abbilden. Eine zentrale Namensverwaltung und der Proxy-Client sind in diesem Fall überflüssig. Jeder TCP/IP-Dienst, der mit einer IP-Adresse der untedagerten Interbus-Teilnehmer aufgerufen wird, muß auf dem Gateway-Rech­ ner abgefangen und an den unterliegenden Interbus-Teilnehmer weitervermittelt werden. Jeder Aufruf eines TCP/IP-Dienstes wird vom Proxy-Server analysiert. Wird dabei die definierte IP-Adres­ se eines unterlagerten Interbus-Teilnehmers gefunden, wird der Aufruf in PPP-Rahmen gekapselt und mit Hilfe der entsprechenden Interbus-Dienste über den Parameterdatenkanal an den zuständigen Empfänger übertragen. Nachteil dieses Ansatzes ist die Menge der gleichzeitig mit der Netzwerkkarte gebundenen IP-Adressen. Von Windows NT werden zur Zeit nur fünf unterschiedliche IP-Adressen unterstützt.

Der Interbus Proxy-Server läuft auf Gateway-Rechnern und ist verantwortlich für die TCP/IP-basierte Kommunikation zwischen Systemen über den Interbus. Zu den Aufgaben des Proxy-Servers zählen:
Erzeugung und Verwaltung virtueller "PPP über PCP"-Verbindungen zu unterlagerten und übergeordneten Systemen,
Emulation von TCP/IP-Diensten stellvertretend für Interbus-Teilnehmer ohne TCP/IP-Protokollstapel,
Bereitstellung des "Remote-DDI" für Konfiguration, Visualisierung,
Verwaltung lokaler Namentabellen mit virtuellen IP-Adressen unterlagerter Systeme,
Synchronisation der lokalen und globalen Namenseinträge Routing.

Der Proxy-Server verwaltet alle Verbindungen zwischen unterlagerten und übergeordneten Systemen.

Um eine ausreichende Flexibilität zu gewährleisten, muß der Proxy-Server mehrere simultane Verbindungen verwalten können. Da auch Verbindungen über mehrere Ebenen (und entsprechend mehreren Gateways) umgesetzt werden sollen, muß der Proxy-Server zu einer gegebenen IP-Adresse auch den Pfad ermitteln können. Über die Verwendung von statischen Routingtabellen, in denen alle unterlagerten Systeme in geeigneter Form eingetragen sind, kann die Route zu einem bestimmten unterlagerten Teilnehmer gefunden werden. Die Route zu einem überlagerten System kann nur durch einen Nachrichtenaustausch mit überlagerten Gateways festgelegt werden. Die Verbindung muß so unter Umständen über mehrere Gateways, bzw. deren Proxy-Server realisiert werden. Proxy-Server fungieren hier als Software-Router. Für diesen Zweck werden auch lokale Namenstabellen vom Proxy-Servern angelegt und verwaltet. Da der Proxy-Server für das Anlegen der Tabellen zuständig ist, müssen zusätzlich die lokalen Daten mit den globalen Daten des globalen Namensservers abgeglichen werden.

Für Busteilnehmer ohne die Möglichkeit eines eigenen TCP/IP-Protokolistapels müssen Proxy-Server zudem die wesentlichen TCP/IP-Dienste emulieren. Sinnvollerweise muß hier eine geeignete Auswahl an verfügbaren Emulationsdiensten vorgenommen werden. Zusätzlich sollte der Proxy-Server als Ethernet-DDI-Server fungieren, so daß Konfigurationstools und Visualisierungen "remote" auf das DDI zugreifen können.

Der Interbus-Proxy-Client wird grundsätzlich automatisch vor jedem Aufruf einer Socket-Funktion aktiv.

Handelt es sich bei diesem Aufruf um eine Funktion, die als Argument eine IP-Adresse beinhaltet, überprüft der Proxy-Client diese. Erkennt der Proxy-Client eine reale IP-Adresse, wird der Aufruf direkt an die entsprechende Socket-Funktion durchgereicht. Wird eine virtuelle IP-Adresse erkannt, wird der Funktionsaufruf in ein Datagramm gekapselt und an den entsprechenden Proxy-Server gesendet. Das Ergebnis des Funktionsaufrufs kommt dann entweder direkt vom realen Host oder aber vom Proxy-Server in Form eines Datagramms. Die Kommunikation zwischen Proxy-Client und Proxy-Server wird typischerweise über Remote Procedure Calls umgesetzt.

PC-Steuerungen, die über eine Slave-Anschaltung mit einem Interbus verbunden sind, benötigen einen NDIS-Treiber, der aus den über den Interbus empfangenen PCP-Daten wieder PPP-Rahmen (und umgekehrt aus PPP-Rahmen wieder PCP-Rahmen) erzeugt. Daten, die von der Interbus-Anschaltbaugruppe kommen, müssen vom Treiber in PPP-Datenpakete umgewandelt werden. Da das PCP-Protokoll nur kleine Datenmengen in einem Dienstaufruf übertragen kann, muß unter Umständen eine Defragmentierung der Daten vorgenommen werden. Zusätzlich muß eine Fehlerbehandlung bei unvollständigen Daten vorgesehen werden. In anderer Richtung müssen empfangene PPP-Datenpakete fragmentiert und über eine Sequenz von PCP-Dienstaufrufen übertragen werden.

Da auf PC-Anschaltkarten mit Coprozessor ein TCP/IP-Protokolistapel möglich ist, sollte über das Multi Port Memory zusätzlich das Protokoll TCP/IP gefahren werden. Dies würde zudem ermöglichen, Prozesse, die unter VxWorks auf einem Coprozessor-Board aktiv sind, über TCP/IP "remote" zu debuggen. Notwendig ist insofern ein NDIS-Treiber, der sich zum Host wie eine Netzwerkkarte verhält und auf der anderen Seite über das DDI auf das Mailbox-Interface des MPM zugreift.

Die Konfiguration eines Automatisierungssystems kann durch den Einsatz einer einheitlichen Kommunikationsebene deutlich vereinfacht werden. Durch die Verwendung des de facto Standards TCP/IP kann auf eine große Menge von sinnvollen Softwarewerkzeugen zurückgegriffen werden.

Das File Transfer Protocol (ftp) kann für die Übertragung von großen Datenmengen verwendet werden. Downloads und Uploads von Programmen und Konfigurationsdaten können so in einheitlicher Art und Weise umgesetzt werden. Eine weitgehende Automatisierung kann durch solch eine transparente Kommunikationsstruktur erheblich vereinfacht werden.

Umfangreiche Automatisierungssysteme beinhalten ein große Anzahl von verschiedenen dezentralen Steuerungen. Häufig müssen in großen Anlagen autarke Einheiten ausgetauscht oder neu initialisiert werden. Diese Bestandteile müssen dann möglichst automatisch wieder Hochfahren. In PC-basierten Steuerungseinrichtungen und in Fernfeld-Steuereinrichtungen, können Steuerungsprogramme und andere Konfigurationsdaten auf eine PC-Karte (Flash-Memory, ATA-Drive etc. siehe auch Anhang A) gespeichert werden. Während des Bootvorgangs können über den FTP-Dienst wieder alle Daten von diesen Speichermedien auf die unterlagerten Steuerungen heruntergeladen werden.

Auch die Überwachung des Automatisierungssystems wird durch den Einsatz des TCP/IP-Protokolls unterstützt. Angefangen von einfachen Monitoring - über komplexe Fernwartungsmöglichkeiten lassen sich auf der Grundlage von TCP/IP viel Einsatzgebiete abdecken. Zum Beispiel kann der einfache Ping-Dienst verwendet werden, um zu überprüfen ob ein System im Netzwerk vorhanden ist. Weit mehr Möglichkeiten bietet das Simple Network Management Protocol. Dieses Protokoll bildet die Grundlage für viel moderne Netzwerkmanagement-Anwendungen.

Die Verwendung des TCP/IP-Protokolls für die Realisierung einer einheitlichen Kommunikationsinfrastruktur in einem Automatisierungssystem bietet eine Reihe von Vorteilen. Dem zunehmenden Grad an Komplexität durch immer mehr dezentrale, autarke Funktionseinheiten kann durch Transparenz der Kommunikation entgegengewirkt werden. Inbetriebnahmen, Wartungen und Anpassungen der Systeme können erheblich vereinfacht werden. Bereits bewährte Mechanismen zur Übertragung von Daten, zur Fernwartung etc. können auf breiter Fläche zum Einsatz kommen. Eine große Zahl von verfügbaren Softwarewerkzeugen auf der Basis des TCP/IP-Pro­ tokolls machen viele Speziallösungen überflüssig. Wie bereits erwähnt lassen sich beispielsweise Steuerungsprogramme und andere Daten problemlos mit dem FTP-Dienst herunterladen, beliebige Funktionseinheiten auf der Basis von SNMP warten und Systemprozesse mit rexec fernstarten.

Claims (14)

1. Automatisierungssystem umfassend

• - ein erstes physikalisches Netzwerk (17), in dem alle angeschlossenen Einrichtungen (15, 20, 25, 30) auf der Grundlage eines ersten Kommunikationsprotokolls kommunizieren können und
• - wenigstens ein zweites, über eine erste, als Gateway fungierende Steuereinrichtung (25; 30) mit dem ersten Netzwerk verbundenes physikalisches Netzwerk (46, 52; 54), in dem alle daran angeschalteten Einrichtungen (25, 58, 59; 30, 54, 56, 57, 60) auf der Grundlage eines zweiten Kommunikationsprotokolls kommunizieren können, wobei das erste und das zweite Netzwerk (17; 46, 52, 54) sowie das erste und zweite Kommunikationsprotokoll verschieden sind,
  dadurch, gekennzeichnet, daß jede erste Steuereinrichtung (25, 30) eine logische Schnittstelle zur im wesentlichen transparenten Kommunikation zwischen wenigstens einer an das erste Netzwerk (17) angeschalteten Einrichtung (15, 20, 25, 30) und wenigstens einer an das zweite Netzwerk (46, 52, 54) angeschalteten Einrichtung (50, 58, 59; 54, 56, 57, 60) auf der Grundlage des ersten Kommunikationsprotokolls aufweist.

2. Automatisierungssystem nach Anspruch 1, gekennzeichnet durch wenigstens eine zweite als Gateway fungierende Steuereinrichtung (50), über die wenigstens zwei zweite Netzwerke (44, 52) miteinander verbindbar sind, wobei die zweite Steuereinrichtung (50) eine logische Schnittstelle zur im wesentlichen transparenten Kommunikation über die zweiten Netzwerke (46, 52) auf der Grundlage des ersten Kommunikationsprotokolls aufweist.

3. Automatisierungssystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß das erste Netzwerk ein Leitnetzwerk, insbesondere das Ethernet, das zweite Netzwerk ein Feldbus, insbesondere ein InterBus-S nach DIN 19258 ist, und das erste Kommunikationsprotokoll das TCP/IP-Protokoll ist.

4. Automatisierungssystem nach Anspruch 3, dadurch gekennzeichnet, daß die logischen Schnittstellen der ersten und zweiten Steuereinrichtungen jeweils zum Umsetzen eines Datenblocks gemäß dem TCP/IP-Protokoll in einen Datenblock gemäß dem zweiten Kommunikationsprotokoll, insbesondere des PCP (Peripheral Communikation Protocol) -Protokolls ausgebildet ist.

5. Automatisierungssystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß jede Steuereinrichtung eine Speichereinrichtung zum Speichern insbesondere von Steuerprogrammen, Diagnosedaten über das jeweilige zweite Netzwerk und Konfigurationsdaten enthält.

6. Automatisierungssystem nach Anspruch 4 oder 5 in Verbindung mit Anspruch 3, dadurch gekennzeichnet, daß die logische Schnittstelle der ersten Steuereinrichtung eine OCI (Open Com Interface)-Schnittstelle, einen DDI-(De­ vice Driver Interface)-Server und eine DDI-Schnitt­ stelle zum Empfangen und Verarbeiten von über das erste Netzwerk empfangenen DDI-Befehlen umfaßt.

7. Automatisierungssystem nach einem der Ansprüche 4 bis 6 in Verbindung mit Anspruch 3, dadurch gekennzeichnet, daß die logische Schnittstelle der ersten und zweiten Steuereinrichtung einen FTP (File Transmission Protocol) -Server und -Client zum Empfangen und Übertragen von Daten, insbesondere von Steuerungsprogrammen und Konfigurationsdaten sowie einen MPM (Multi Port Memory)-Speicher umfaßt.

8. Automatisierungssystem nach einem der Ansprüche 4 bis 7 in Verbindung mit Anspruch 3, dadurch gekennzeichnet, daß jeder Steuereinrichtung eine IP-Adresse zugeordnet ist.

9. Automatisierungssystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß die erste und/oder zweite Steuereinrichtung zum Aufnehmen wenigstens einer Anschaltkarte zum Anschalten eines zweiten Netzwerkes ausgebildet ist, wobei die Anschaltkarte einen Coprozessor enthält, auf dem die logische Schnittstelle implementiert ist, und daß jeder Anschaltkarte eine IP-Adresse zugeordnet ist.

10. Automatisierungssystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß die erste und/oder zweite Steuereinrichtung zum Aufnehmen wenigstens einer Anschaltkarte ausgebildet ist, daß die logische Schnittstelle auf einem der jeweiligen Steuereinrichtung zugeordneten Stellvertreter-Server implementiert ist, der wenigstens die virtuelle IP-Adresse der jeweiligen Anschaltkarte verwaltet.

11. Automatisierungssystem nach einem der Ansprüche 3 bis 10, dadurch gekennzeichnet, daß jede Steuereinrichtung einen Speicher aufweist, in dem die IP-Adressen von vorbestimmten übergeordneten und/oder untergeordneten Steuereinrichtungen sowie von vorbestimmten Einrichtungen, die an wenigstens ein vorbestimmtes zweites Netzwerk angeschaltet sind, abgelegt sind.

12. Automatisierungssystem nach einem der Ansprüche 3 bis 11, dadurch gekennzeichnet, daß dem System eine abrufbare Einrichtung zum Speichern der IP-Adressen und/oder virtuellen IP-Adressen aller an das erste und jedes zweite Netzwerk angeschlossenen Einrichtungen sowie der ersten und zweiten Steuereinrichtungen zugeordnet ist.

13. Anschaltvorrichtung zum Einsatz in einem Automatisierungssytem nach einem der Ansprüche 1 bis 12, die ein erstes physikalisches Netzwerk (17), in dem alle angeschlossenen Einrichtungen (15, 20, 25, 30) auf der Grundlage eines ersten Kommunikationsprotokolls kommunizieren können, mit einem zweiten physikalischen Netzwerk (54), in dem alle daran angeschalteten Einrichtungen auf der Grundlage eines zweiten Kommunikationsprotokolls kommunizieren können, verbindet, wobei das erste und das zweite Netzwerk (17, 54) sowie das erste und zweite Kommunikationsprotokoll verschieden sind, dadurch, gekennzeichnet, daß die Anschalteinrichtung (30) eine logische Schnittstelle zur im wesentlichen transparenten Kommunikation zwischen wenigstens einer an das erste Netzwerk (17) angeschalteten Einrichtung und wenigstens einer an das zweite Netzwerk (54) angeschalteten Einrichtung auf der Grundlage des ersten Kommunikationsprotokolls aufweist.

14. Anschaltvorrichtung zum Einsatz in einem Automatisierungssytem nach einem der Ansprüche 1 bis 12, die wenigstens zwei zweite, einem ersten physikalischen Netzwerk (17), in dem alle angeschlossenen Einrichtungen auf der Grundlage eines ersten Kommunikationsprotokolls kommunizieren können, untergeordnete Netzwerke (44, 52), in denen alle daran angeschalteten Einrichtungen auf der Grundlage eines zweiten Kommunikationsprotokolls kommunizieren können, verbindet, wobei das erste und das zweite Netzwerk sowie das erste und zweite Kommunikationsprotokoll verschieden sind, dadurch, gekennzeichnet, daß die Anschalteinrichtung (50) eine logische Schnittstelle zur im wesentlichen transparenten Kommunikation zwischen Einrichtungen, die an den zweiten Netzwerken angeschaltet sind, auf der Grundlage des ersten Kommunikationsprotokolls aufweist.