Normierte Schnittstellen in der Datenkommunikation verteilter Automatisierungssysteme
©2001
Diplomarbeit
106 Seiten
Zusammenfassung
Inhaltsangabe:Zusammenfassung:
Das Ziel der Arbeit bestand darin, einen Übergang zwischen einem Feldbus und einem PC Netzwerk zu schaffen. Es sollte möglich werden Daten zwischen dem Profibus und dem Ethernet auszutauschen.
Zu Begin der Diplomarbeit wurden die vorhandenen Schnittstellen auf Hardware und Softwareseite aufgearbeitet. Der Profibus verwendet RS485 und im Ethernet wird heute hauptsächlich Twisted Pair eingesetzt.
Softwareseitig wird kurz auf die Dienste DCOM und CORBA eingegangen. Beide Dienste stellen Methoden zur Kommunikation von Programmen in einem Netzwerk zur Verfügung. Für die Implementierung des Protokollüberganges wird in der Arbeit dann CORBA verwendet, da es als einziger Dienst die geforderte Heterogenität von Betriebssystemen unterstützt.
Im Dritten Teil soll ein Überblick über bereits vorhandene Systeme mit ähnlicher Funktionalität gegeben werden. Es wird eine Auswahl von bereits vorhandenen Lösungen verschiedener Firmen vorgestellt und miteinander verglichen. Dabei kommt der Autor zu dem Schluss, das es Systeme mit der Möglichkeit zur Kopplung von Profibus und Ethernet bereits gibt, jedoch nicht als Implementation in Form eines Profibus Masters.
Im vierten Teil der Arbeit werden die Unterschiede der Profibusausführungen FMS, DP und PA aufgezeigt und ausführlich auf das DP Protokoll eingegangen.
Der folgende Abschnitt beinhaltet einige wichtige Gedanken zum Einsatz von Linux als Embedded- PC Betriebssystem unter den Gesichtspunkten der Automatisierungstechnik. Es wird eine reduzierte Hardwarekonfiguration beschrieben sowie Software, die bei embedded Systemen der Standardsoftware vorzuziehen ist.
Der Aufbau der Testumgebung bestand auf der einen Seite aus einer Profibus Master Karte der Firma Softing, die in einem einfachen PC, auf dem Linux als Betriebsystem eingesetzt wurde, eingebaut war. An diese Karte waren einige einfache Standard-Feldbusgeräte angeschlossen. Die andere Seite bestand aus dem erwähnten Linux PC, sowie ein bis testweise drei Clients auf Microsoft Windows Basis. Die serverseitige Software wurde unter Linux in C++ geschrieben. Als CORBA-ORB kam mico zum Einsatz. Die Parametrierung des Profibusses erfolgte mit Hilfe von XML- Dateien, die aus GSD- Dateien erstellt wurden. Die Clientsoftware unter Windows wurde in Delphi geschrieben. Hier wird dorb als CORBA-ORB eingesetzt.
Im Ergebnis existiert eine Testumgebung, mit der es möglich ist Daten zwischen Profibus und Ethernet zu […]
Das Ziel der Arbeit bestand darin, einen Übergang zwischen einem Feldbus und einem PC Netzwerk zu schaffen. Es sollte möglich werden Daten zwischen dem Profibus und dem Ethernet auszutauschen.
Zu Begin der Diplomarbeit wurden die vorhandenen Schnittstellen auf Hardware und Softwareseite aufgearbeitet. Der Profibus verwendet RS485 und im Ethernet wird heute hauptsächlich Twisted Pair eingesetzt.
Softwareseitig wird kurz auf die Dienste DCOM und CORBA eingegangen. Beide Dienste stellen Methoden zur Kommunikation von Programmen in einem Netzwerk zur Verfügung. Für die Implementierung des Protokollüberganges wird in der Arbeit dann CORBA verwendet, da es als einziger Dienst die geforderte Heterogenität von Betriebssystemen unterstützt.
Im Dritten Teil soll ein Überblick über bereits vorhandene Systeme mit ähnlicher Funktionalität gegeben werden. Es wird eine Auswahl von bereits vorhandenen Lösungen verschiedener Firmen vorgestellt und miteinander verglichen. Dabei kommt der Autor zu dem Schluss, das es Systeme mit der Möglichkeit zur Kopplung von Profibus und Ethernet bereits gibt, jedoch nicht als Implementation in Form eines Profibus Masters.
Im vierten Teil der Arbeit werden die Unterschiede der Profibusausführungen FMS, DP und PA aufgezeigt und ausführlich auf das DP Protokoll eingegangen.
Der folgende Abschnitt beinhaltet einige wichtige Gedanken zum Einsatz von Linux als Embedded- PC Betriebssystem unter den Gesichtspunkten der Automatisierungstechnik. Es wird eine reduzierte Hardwarekonfiguration beschrieben sowie Software, die bei embedded Systemen der Standardsoftware vorzuziehen ist.
Der Aufbau der Testumgebung bestand auf der einen Seite aus einer Profibus Master Karte der Firma Softing, die in einem einfachen PC, auf dem Linux als Betriebsystem eingesetzt wurde, eingebaut war. An diese Karte waren einige einfache Standard-Feldbusgeräte angeschlossen. Die andere Seite bestand aus dem erwähnten Linux PC, sowie ein bis testweise drei Clients auf Microsoft Windows Basis. Die serverseitige Software wurde unter Linux in C++ geschrieben. Als CORBA-ORB kam mico zum Einsatz. Die Parametrierung des Profibusses erfolgte mit Hilfe von XML- Dateien, die aus GSD- Dateien erstellt wurden. Die Clientsoftware unter Windows wurde in Delphi geschrieben. Hier wird dorb als CORBA-ORB eingesetzt.
Im Ergebnis existiert eine Testumgebung, mit der es möglich ist Daten zwischen Profibus und Ethernet zu […]
Leseprobe
Inhaltsverzeichnis
ID 6197
Becker, Andreas: Normierte Schnittstellen in der Datenkommunikation verteilter
Automatisierungssysteme
Hamburg: Diplomica GmbH, 2003
Zugl.: Leipzig, Fachhochschule, Diplomarbeit, 2001
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
Inhaltsverzeichnis
Aufgabenstellung...i
1. Einleitung... 1
2. Schnittstellen ... 2
2.1. Hardware... 2
2.1.1. Serielle Übertragung ... 2
2.1.2. RS232... 2
2.1.3. RS422... 3
2.1.4. RS485... 4
2.1.5. LWL ... 5
2.1.6. TP... 5
2.2. Software ... 6
2.2.1. COM ... 6
2.2.1.1. Was ist COM? ... 6
2.2.1.2. Was leistet COM? ... 7
2.2.1.3. DCOM... 7
2.2.2. OPC - COM/DCOM in der Automatisierungstechnik... 8
2.2.3. CORBA ... 8
2.2.3.1. Grundlagen CORBA ... 8
2.2.3.2. Bilden eines Objektes ... 10
3. Protokollkoppler in der Automatisierungstechnik ... 13
3.1. Allgemeines ... 13
3.2. Hilscher GmbH ... 13
3.2.1. Überblick über die Firma ... 13
3.2.2. Protocol Converter ... 13
3.2.3. Protocol Converter Ethernet... 14
3.3. Softing AG ... 14
3.3.1. Überblick über die Firma ... 14
3.3.2. PROFIgate... 14
3.4. Wiesemann & Theis GmbH ... 14
3.4.1. Überblick über die Firma ... 14
3.4.2. Gateway ... 15
3.5. ISK Automation GmbH ... 15
3.5.1. Überblick über die Firma ... 15
3.5.2. TCP/IP Koppler... 15
3.6. Profibus Nutzer Organisation e.V... 15
3.6.1. Aufgaben der PNO... 15
3.6.2. PROFInet ... 16
4. Profibus ... 17
4.1. Allgemeines ... 17
4.1.1. Entstehung... 17
4.1.2. Verschiedene Anforderungen, verschiedene Ausführungen ... 17
4.1.3. Gegenüberstellung technischer Daten der PROFIBUS-Familie ... 19
iii
4.2. Zugriffsverfahren beim Profibus ... 20
4.2.1. Das hybride Konzept... 21
4.2.2. Master / Slave... 21
4.2.3. Token Passing ... 21
4.3. Typen von Geräten ... 22
4.3.1. Passiver Slave... 22
4.3.1.1. Allgemeine Beschreibung ... 22
4.3.1.2. Sync Mode ... 22
4.3.1.3. Freeze Mode... 22
4.3.2. Aktiver Slave... 22
4.3.3. Master Typ 1 (DPM1) ... 23
4.3.4. Master Typ 2 (DPM2) ... 23
4.4. Schichten des Profibusses ... 24
4.4.1. ISO/OSI 7 Schichten Referenzmodell ... 24
4.4.2. Schicht 1 - PHY ... 25
4.4.2.1. Elektrische Spezifikation ... 25
4.4.2.2. Übertragungsraten... 25
4.4.2.3. UART-Zeichen ... 26
4.4.2.4. OCTET... 26
4.4.2.5. Bitzeit, [Tbit]... 26
4.4.3. Schicht 2 - FDL... 27
4.4.3.1. Telegrammaufbau... 27
4.4.3.2. Vergleich mit Ethernet ... 29
4.4.3.3. CRC- Check ... 31
4.4.3.4. Dienste der Schicht 2 ... 31
4.4.4. Schicht 7 - DDLM ... 32
4.4.4.1. Überblick über die Dienste ... 32
4.4.4.2.
DDLM_Data_Exchange
... 33
4.4.4.3.
DDLM_Global_Control
... 33
4.4.4.4.
DDLM_Set_Prm
... 34
4.4.4.5.
DDLM_Chk_Cfg
... 35
4.4.4.6.
DDLM_Slave_Diag
... 36
4.4.5. Schichten des Profibus FMS ... 37
4.4.5.1. Allgemeiner Überblick... 37
4.4.5.2. Das FMS-Layer... 37
4.4.6. Schicht 2,7 FMB ... 39
4.4.6.1. FMB_Set_Configuration... 39
4.4.6.2. FMB_set_busparameter ... 41
4.4.6.3. weitere Dienste... 42
4.4.6.3.1.
FMB_Set_Value
... 42
4.4.6.3.2.
FMB_read_busparameter
... 42
4.4.6.3.3.
FMB_read_value
... 42
4.4.6.3.4.
FMB_LSAP_Status
... 42
4.4.6.3.5.
FMB_get_live_list
... 43
4.4.6.3.6.
FMB_FM2_Event
... 43
iv
4.4.6.3.7.
FMB_exit
... 43
4.4.7. Inbetriebnahme eines Profibusses ... 43
4.4.7.1. Grundvoraussetzungen... 43
4.4.7.2. Geräte-Stamm-Dateien ... 44
4.4.7.3. Zeitverhalten des Profibusses... 48
5. Embedded Linux in der AT... 51
5.1. Einsatzgebiete ... 51
5.2. Hardware... 51
5.3. Der Kernel... 53
5.3.1. Was ist der Kernel? ... 53
5.3.2. Wichtige Eigenschaften des Kernels... 53
5.3.3. Module und der monolithische Kernel ... 54
5.3.4. Was ist notwendig? ... 55
5.4. Systemanforderungen ... 56
5.5. Bibliotheken ... 56
5.6. Spezielle Gegebenheiten bei Embedded Systemen ... 57
5.6.1. Booten mit Lilo ... 57
5.6.2. Busybox ... 58
5.6.3. LEM 0.61 ... 59
5.7. Anforderungen an den Host ... 60
5.8. Statisch oder dynamisch binden?... 60
6. Softwarekopplung zwischen Profibus und Ethernet mittels CORBA... 62
6.1. Aufbau der Testumgebung ... 62
6.1.1. Übersicht über die Testumgebung... 62
6.1.2. Koppelrechner ... 63
6.1.2.1. Hardware... 63
6.1.2.2. Softing Karte... 63
6.1.2.3. Benutzen der Softing Karte... 65
6.1.2.4. Software ... 69
6.1.3. Steuerung S7-300... 71
6.1.3.1. Aufbau der Steuerung ... 71
6.1.3.2. Funktionalität des Programms ... 72
6.1.4. ET 200B ... 73
6.2. Programm zur Datenkopplung ... 73
6.2.1. Allgemeines ... 73
6.2.2. Klasse
PB_small_api
... 74
6.2.2.1. Aufgaben der Klasse ... 74
6.2.2.2. Arbeitsweise... 75
6.2.2.2.1. Datenpakete für den Controller... 75
6.2.2.2.2. Methoden ... 76
6.2.3. Klasse
C_PB_Config
... 77
6.2.3.1. Aufgaben der Klasse ... 77
6.2.3.2. Arbeitsweise der Klasse... 77
6.2.3.2.1. Überblick... 78
6.2.3.2.2. Aufgaben der Threads... 78
v
6.2.3.2.3. Konfigurationsdaten ... 78
6.2.3.2.4. Datenaustausch ... 79
6.2.4. Klasse
C_expat
... 80
6.2.4.1. Aufbau von XML- Dateien ... 80
6.2.4.2. Aufgabe von
C_expat
... 81
6.2.4.3. Funktionsweise der Klasse
C_expat
... 81
6.2.4.4. Elemente der XML-Daten... 83
6.2.5. Hauptprogramm ... 84
6.2.6. Delphi- Client... 84
7. Zusammenfassung, Ausblick... 87
Literatur... 89
A. Konfiguration des Kernels... 91
B. wichtige Konfigurationsdateien ... 93
C. Verarbeitung der XML-Dateien ... 95
D. Eidesstattliche Erklärung... 96
vi
Tabellenverzeichnis
2-1. RS 232 Steckerbelegung... 3
2-2. Steckerbelegung eines RJ45 Steckers... 6
4-1. Technischen Daten des PROFIBUS-FMS ... 19
4-2. Technischen Daten des PROFIBUS-DP ... 19
4-3. Technischen Daten des PROFIBUS-PA ... 20
4-4. Vollständige Steckerbelegung beim Profibus DP ... 25
4-5. Übertragungsraten beim Profibus-DP... 25
4-6. DDLM-Dienste... 32
4-7. Laufzeiten beim Profibus... 48
6-1. Konfigurationsdateien auf Little unter
/etc/
... 70
6-2. Aufbau der SPS ... 71
6-3. Parameter der Expat Handler... 82
Abbildungsverzeichnis
2-1. Prinzip der Datenübertragung bei der RS422 Schnittstelle nach [DY00] ... 4
2-2. Prinzip der Datenübertragung bei der RS485 Schnittstelle nach[DY00] ... 4
2-3. Aufbau der Object Managment Architecture [Red96] ... 8
2-4. Aufbau eines ORBs [Red96] ... 9
2-5. Aufruf eines Objektes [Red96]... 9
2-6. IOR-Dump ... 11
2-7. Kommunikation zwischen Client und Server [Hös01] ... 11
4-1. Eingliederung des Profibusses in das ISO/OSI Modell [PbDaKo]... 24
4-2. Telegramme im Profibus... 27
4-3. Adressen im Telegramm ... 29
6-1. Schema des Testnetzes... 62
6-2. Profiboard PCI Einsteckkarte ... 63
6-3. Ausgabe beim Lesen von
/dev/pbboard0
... 65
6-4. Aufbau eines Datenblocks ... 66
6-5. Programm in der SPS ... 72
6-6. Programmablauf von Profiboard ... 73
6-7. Zugriff auf Feldvariablen... 79
6-8. Prinzipielle Funktion von
Expat
... 81
6-9. Klassenabhängigkeiten im Hautprogramm ... 84
6-10. Screenshot Delphi-Client... 85
Beispiele
5-1. Bibliothekskonzept ... 56
6-1. Verwenden des Service Devices (write) ... 66
6-2. Schreibender Zugriff auf
/dev/pbdata0
... 68
vii
6-3. Aufteilen des Puffers in Datenbereiche. ... 76
6-4. Einfache XML Datei ... 80
6-5. Allgemeine Elemente in XML-Dateien... 83
viii
Aufgabenstellung
Die Schnittstellenproblematik bei der Realisierung von Automatisierungsprojekten stellt eine
grosse Herausforderung an die Projektierung dar. Die Beschreibung normierter Schnittstellen
und deren Einsatz ist in verteilten Automatisierungssystemen unverzichtbar. Am Beispiel einer
Testumgebung sollen die Probleme der Protokollkopplungen zwischen heterogenen Betriebs-
systemen untersucht werden.
Im besonderen sind dazu folgende Teilaufgaben zu lösen:
·
Beschreibung vorhandener Schnittstellen (Hard- und Software)
·
Recherche zur softwaretechnischen Realisierung von Protokollkopplern (soft- und hardwa-
reseitig).
·
Realisierung eines Schnittstellenumsetzers für die Anbindung definierter CORBA oder
COM+ Objekte für den direkten Datenzugriff auf die Hardware (Zielprotokoll Profibus
oder Interbus)
·
Dokumentation und Test der Applikation an einem Beispiel.
Beginn: 23.05.2001
Betreuer: Prof. Dr. Pretschner
i
Kapitel 1. Einleitung
Das Ziel bei der Bearbeitung dieser Diplomaufgabe besteht in der Schaffung einer Möglichkeit
des Datenaustausches zwischen dem Ethernet und einem Feldbus. Für die Realisierung sollten
keine bereits vorhandenen Standardkomponenten, wie sie bereits bei verschiedenen Herstellen
im Angebot sind, verwendet werden.
Die Verfügbarkeit von Daten aus der Feldebene in übergeordneten Netzen gewinnt immer mehr
an Bedeutung. In den Firmen ist man bestrebt, in der Betriebsleitebene über aktuelle Daten aus
der Fertigung zu verfügen. So kann zum Beispiel die Lagerhaltung auf ein absolut notwendiges
Minimum reduziert werden. Ein weiteres Ergebnis dessen ist die schnelle Weiterleitung von
Störzuständen in der Fertigung an übergeordnete Überwachungsstellen.
Das Ethernet ist in den Bereichen der Bürokommunikation dominant. Aufgrund der angestreb-
ten durchgängigen Vernetzung von der Betriebsleitebene bis in die Feldebene dringt es immer
weiter in die Domäne der Feldbusse vor. Jedoch bleibt die Kommunikation der prozessnahen
Komponenten untereinander dem Ethernet bisher verschlossen. In diesen Bereichen herrschen
Forderungen nach deterministischen Antwortzeiten und sicherer Übertragung mit möglichst
wenigen Wiederholungen vor. Diese Forderungen sind vom Ethernet bisher nicht oder nur
schwer erfüllbar.
In dieser Diplomarbeit soll ein System aufgebaut werden, das die Umsetzung zwischen Profi-
bus und Ethernet möglichst kostengünstig und effizient vornimmt.
Die Realisierung sollte mit Hilfe eines PCs erfolgen, der für die benötigten Schnittstellen mit
Erweiterungskarten aufgerüstet wurde. Als Betriebssystem für den PC wurde Linux gewählt.
Für den Einsatz von Linux fallen keine Lizenzkosten an, was erheblich die Kosten für den
Aufbau senkt. Des weiteren ist für das gesamte Betriebssystem der Quelltext frei verfügbar,
wodurch die Programmierung besonders effizient vollzogen werden kann.
Im zweiten Kapitel der Diplomarbeit wurden vorhandene Standards für die Datenübermittlung
bezüglich der Hardware und der Software aufgearbeitet.
Das dritte Kapitel zeigt einige bereits vorhandene und zukünftige Lösungen der Industrie auf.
Das vierte Kapitel stellt sich der Aufarbeitung der Grundfunktionen des verwendeten Feld-
busses. Für diese Diplomarbeit standen die konkurrierenden Feldbusstandards Profibus und
Interbus zur Auswahl. Die Wahl fiel, aufgrund seiner weiten Verbreitung in Europa und den
vielfältigen am Markt erhältlichen Komponenten, auf den Profibus.
Im fünften Kapitel werden Untersuchungen zu PCs für den Schaltschrankbereich angestellt,
dabei wird auf spezielle Gegebenheiten beim Einsatz dieser PCs und dem Betriebssystem Li-
nux eingegangen.
Das sechste Kapitel beschreibt die Softwarelösung und einige wichtige Aspekte bei der Pro-
grammierung ausführlich. Die Quelltexte sind auf der beiliegenden CD enthalten.
1
Kapitel 2. Schnittstellen
2.1. Hardware
2.1.1. Serielle Übertragung
Für die Übertragung von Daten über grössere Distanzen (>5m) werden heutzutage fast aussch-
liesslich serielle Datenübertragungsformen verwendet. Bei der seriellen Übertragung benutzt
man zwei Leitungen für den Datentransport und zusätzlich einige Handshake-Leitungen zur
Steuerung des Datenflusses. Ein wichtiger Vorteil der seriellen Übertragung ist die Einsparung
von Leitungen. Im Gegensatz dazu steht aber die wesentlich geringere Datenübertragungsge-
schwindigkeit als bei parallelen Übertragungsverfahren.
Bei der seriellen Übertragung werden die Daten-Bytes in ihre Bits zerlegt und dann nacheinan-
der in einer bestimmten Geschwindigkeit übertragen. Um die Übertragung weniger fehleran-
fällig zu gestalten, wird eine bestimmte Anzahl von Bits, meist acht, zu einem Zeichen zusam-
mengefasst. Die Übertragung beginnt mit einem Startbit. Dazu findet ein Spannungswechsel
auf dem Bus von logisch HIGH auf LOW statt. Danach folgen die weiteren Datenbits im Ab-
stand des vorher festgelegten Taktes. Die Zeichenfolge wird mit einem Stopbit abgeschlossen.
Bei seriellen Übertragungen wird zum überwiegenden Teil asynchron gearbeitet. Damit wird
nicht vorgeschrieben, wann sich ein neues Telegramm an ein altes anschliessen muss.
Die Übertragungsgeschwindigkeit über eine serielle Datenverbindung wird üblicherweise in
Bit pro Sekunde angegeben. Man muss dabei beachten, dass nicht die Anzahl von Nutzdaten
gemeint ist, sondern vielmehr die gesamten übertragenen Bits, also inklusive Start-, Stop- und
Paritätsbit. Die Angabe in Baud bedeutet, wie viele Zustände pro Sekunde übertragen werden
können. Die Anzahl der möglichen Zustände muss somit immer mit angegeben werden oder
bekannt sein. Bezieht sich die Angabe von Baud auf eine digitale Verbindung, die nur genau
zwei Zustände kennt, kann sie einer Angabe von Bit pro Sekunde gleichgesetzt werden. Die
Zahl an verschiedenen Ausführungen und Normen für serielle Schnittstellen ist sehr gross und
jede hat ihre eigenen Vor- und Nachteile. Hier sollen die wichtigsten, in der Industrie verwen-
deten Schnittstellen vorgestellt werden.
2.1.2. RS232
RS232 ist die klassische serielle Computer-Schnittstelle, die auch unter der Bezeichnung ,,seri-
elle Schnittstelle", ,,COM-Schnittstelle" oder auch ,,V24 Schnittstelle"(RS232-C) bekannt ist.
Die RS232 wird hauptsächlich für die Datenübertragung über kürzere Entfernungen verwen-
det. Entsprechend der Belegung der Anschlüsse wird zwischen dem Typ DEE (Datenendein-
richtung), wie z.B. Computer oder Drucker und dem Typ DÜE (Datenübertragungseinrich-
tung), wie z.B. Modem unterschieden. Die RS232-Norm definiert als Standard Steckverbin-
dung einen 25 poligen Sub-D Stecker. Es ist jedoch ohne grosse Umstände auch möglich,
einen 9 poligen Sub-D Stecker zu verwenden. In der folgenden Tabelle werden die Steckerbe-
2
Kapitel 2. Schnittstellen
legungen für die beiden Steckertypen und die dazugehörigen Bezeichnungen dargestellt:
Tabelle 2-1. RS 232 Steckerbelegung
Sub-D
25pol.
Sub-D
9pol.
Funktion
Bezeichnung
Richtung
DEE-
>DÜE
7
5
Signalmasse
Signal GND
-
2
3
Sendedaten
TxD (Transmit Data)
-->
3
2
Empfangsdaten
RxD (Receive Data)
<--
20
4
Betriebsbereitschaft
DTR (Data Terminal
Ready)
-->
6
6
Betriebsbereitschaft
DSR (Data Set Ready)
<--
4
7
Versenden möglich
RTS (Request To
Send)
-->
5
8
Sendebereitschaft
CTS (Clear To Send)
<--
22
9
Ankommender Ruf
RI (Ring Indicator)
<--
8
1
Verbindung erkannt
DCD (Data Carrier
Detect)
<--
Die Übertragung bei der RS232 ist unsymmetrisch, d.h. die Spannungspegel auf den Daten-
leitungen sind auf die gemeinsame Masse bezogen. Ein Spannungspegel von -15V bis -3V
bedeutet dabei eine logische ,,1". Ein Pegel von +3 bis +15V wird als logische ,,0" verstanden.
Der Sender muss unter Last mindestens einen Pegel von ±5V erzeugen, da beim Empfänger
noch mindestens ±3V anliegen müssen. Die zulässige Last liegt dabei bei 3 k. Als zulässige
Kapazität der Leitung werden 2500 pF angegeben. Die Entfernung zwischen zwei Teilnehmern
sollte 15m nicht übersteigen. Abhängig von der Leistungsfähigkeit der beiden Teilnehmer ist
bei einer Übertragungsrate von über 115.000 kBaud die Entfernung auf unter 10m beschränkt.
Die RS232-Schnittstelle besitzt eine Vielzahl von Handshake-Leitungen, die jedoch in ihrer
Gesamtheit lediglich zur Verbindung eines Modems mit einem Datenendgerät benötigt wer-
den. Der weitaus häufigere Fall, der Verbindung zweier Datenendgeräte miteinander, lässt sich
in der Regel mit einer reduzierten Anzahl von Handshake-Leitungen ohne Probleme realisie-
ren. So können beispielsweise die Leitungen RI und DCD meist entfallen. Auch RTS und
CTS sind nur für einen vollständigen Hardware-Handshake unbedingt erforderlich. Nicht be-
nötigte Handshake-Eingänge werden einfach durch Verbindung mit den eigenen Handshake-
Ausgängen auf Freigabepegel gelegt. [DY00]
2.1.3. RS422
RS422- und RS485-Schnittstellen sind für serielle Hochgeschwindigkeits- Datenübertragun-
gen über grosse Entfernungen entwickelt worden und werden im industriellen Bereich häufig
eingesetzt. Die seriellen Daten werden ohne Massebezug als Spannungsdifferenz zwischen
zwei korrespondierenden Leitungen übertragen. Für jedes zu übertragende Signal existiert ein
3
Kapitel 2. Schnittstellen
Adernpaar, das aus einer invertierten und einer nicht invertierten Signalleitung besteht. Die
invertierte Leitung wird in der Regel durch den Index "A" oder "-" gekennzeichnet, während
die nicht invertierte Leitung mit "B" oder "+" bezeichnet wird. Der prinzipielle Aufbau der
Datenübertragung wird in Abbildung 2-1 dargestellt.
Abbildung 2-1. Prinzip der Datenübertragung bei der RS422 Schnittstelle nach [DY00]
Der Empfänger wertet lediglich die Differenz zwischen beiden Leitungen aus, so dass Gleich-
takt-Störungen auf der Übertragungsleitung nicht zu einer Verfälschung des Nutzsignals füh-
ren. Durch die Verwendung von abgeschirmtem, paarig verdrillten Kabeln lassen sich Da-
tenübertragungen über Distanzen bis 1200 m bei einer Geschwindigkeit bis 2000 kBaud rea-
lisieren. RS422-Sender stellen unter Last Ausgangspegel von ± 2Volt zwischen den beiden
Ausgängen zur Verfügung. Die Empfängerbausteine erkennen Pegel von ± 200mV noch als
gültiges Signal. Der Lastwiderstand darf dabei bis zu 100
betragen. Die RS422 ist auch unter
der Bezeichnung ,,V.11 Schnittstelle" bekannt.
2.1.4. RS485
Die RS485-Schnittstelle stellt eine Erweiterung der RS422-Definition dar. Während die RS422
lediglich den unidirektionalen Anschluss von bis zu 10 Empfängern an einen Sendebaustein
zulässt, ist die RS485 als bidirektionales Bussystem mit bis zu 32 Teilnehmern konzipiert.
Physikalisch unterscheiden sich beide Schnittstellen nur unwesentlich. Ein Schema für die
elektrische Zusammenschaltung der Schnittstellen wird in Abbildung 2-2 dargestellt.
Abbildung 2-2. Prinzip der Datenübertragung bei der RS485 Schnittstelle nach[DY00]
4
Kapitel 2. Schnittstellen
Da mehrere Sender auf einer gemeinsamen Leitung arbeiten, muss durch ein Protokoll si-
chergestellt werden, dass zu jedem Zeitpunkt maximal ein Datensender aktiv ist. Alle anderen
Sender müssen sich zu dieser Zeit im hochohmigem Zustand befinden. Die Aktivierung der
Senderbausteine kann durch Schalten einer Handshake-Leitung oder datenflussgesteuert, also
automatisch erfolgen. Eine Terminierung des Kabels ist bei RS422-Leitungen nur bei hohen
Baudraten und grossen Kabellängen, bei RS485-Verbindungen dagegen grundsätzlich notwen-
dig. Obwohl beide Schnittstellen für grosse Entfernungen bestimmt sind, bei denen Potenti-
alverschiebungen unvermeidbar sind, schreibt die Norm für keine der beiden Schnittstellen
eine galvanische Trennung vor. Bei der Installation muss ausserdem auf korrekte Polung der
Adernpaare geachtet werden, da eine falsche Polung zur Invertierung der Datensignale führt.
Die Spannungspegel am Sender liegen zwischen 0 und 5 Volt. Für ein HIGH Signal 5V auf
der A und 0 V auf der B Leitung. Ein LOW Signal wird mit 0V auf der A und 5V auf der B
Leitung übertragen. Beim Empfänger werden Spannungen grösser 2V als positives und kleiner
2V als negatives Signal interpretiert. nach [DY00]
2.1.5. LWL
Die Datenübermittlung mittels LWL (Lichtwellenleiter) wird in der Automatisierungstechnik
oft als eine Wandlung von den vorhandenen, kupfergebundenen Schnittstellen ausgeführt, so
kann man die vorhandenen Geräteschnittstellen weiterhin nutzen. Mit einem OLM (Optical
Link Modul) wird das Signal am RS485 Stecker direkt in ein Lichtsignal gewandelt. Im ein-
fachsten Fall passt ein OLM in das Gehäuse eines herkömmlichen Sub-D Steckers und versorgt
sich mit den benötigten Spannungen aus dem angeschlossenen Gerät. Es ist keine weitere Ver-
drahtung erforderlich. Licht auf dem Bus bedeutet dabei eine 0, kein Licht wird als eine 1
verstanden. Der Einsatz von Lichtwellenleitern hat gegenüber der herkömmlichen Übertra-
gungstechnik drei wesentliche Vorteile:
·
LWL ist vollkommen unanfällig gegen ein EM (elektromagnetisch) verseuchtes Umfeld.
·
Mit LWL lassen sich grössere Entfernungen zwischen den Teilnehmern überbrücken.
·
Durch den Einsatz von LWL sind Sender und Empfänger galvanisch voneinander getrennt.
Der Nachteil von LWL ist der höhere Kostenanteil für die Verkabelung und das Material. Als
preiswerteste Lösung gibt es LWL auf Kunststoffbasis, jedoch liegt die mit Kunststoff-LWL
überbrückbare Länge nur bei ca. 50m. Die Kosten sind in dem Fall ca. doppelt so hoch wie
beim Einsatz herkömmlicher kupferbasierter Übertragungstechnik. Als teuerste Lösung ist der
Einsatz von Glas-LWL möglich. Mit ,,echtem" Glas ist es möglich bis zu 20 Kilometer mit der
höchsten Übertragungsrate zu überbrücken. Die Kosten für die Installation sind dann haupt-
sächlich von der Lichtdämpfung im Kabel (angegeben in dB/km) abhängig.
2.1.6. TP
Twisted Pair(TP) ist das im Moment am häufigsten eingesetzte Medium für das Ethernet. Es
5
Kapitel 2. Schnittstellen
gibt drei Übertragungsstandards 10MBit/s, 100MBit/s und 1000MBit/s. Das Kabel muss mit
mindestens 4 Adern (1000MBit/s braucht 8) ausgestattet sein. Der Wellenwiderstand sollte ca.
100
betragen. Das Kabel muss mindestens 6x pro Meter verdrillt sein. Der Gleichstrom-
widerstand darf auf 330 m nicht grösser als 28.6
sein. Als Stecker wird ein RJ45 Stecker,
der beim Telefon auch unter der Bezeichnung Westernstecker bekannt, verwendet. Mit einem
Kabel der Kategorie 5 (CAT5) (für 100 MBit/s erforderlich) sollte die Adernbelegung folgen-
dermassen aussehen:
Tabelle 2-2. Steckerbelegung eines RJ45 Steckers
Pin
Farbe
Signal
1
Weiss/Orange
Transmit -
2
Orange
Transmit +
3
Weiss/Grün
Receive -
4
Blau
5
Weiss/Blau
6
Grün
Receive +
7
Weiss/Braun
8
Braun
Die Übertragung kann im ,,Half-Duplex" oder ,,Full-Duplex" Modus stattfinden. Im ,,Full-
Duplex" Modus kann ein Teilnehmer gleichzeitig senden und empfangen. Im ,,Half-Duplex"
Modus kann entweder gesendet, oder empfangen werden.
2.2. Software
2.2.1. COM
2.2.1.1. Was ist COM?
COM (Component Object Model) ist eine von Microsoft entwickelte Spezifikation, deren Auf-
gabe es ist, die Kommunikation zwischen Anwendungen zu ermöglichen. COM besteht aus
zwei Teilen:
1. Einem binären Standard, der lediglich die Regeln definiert, nach denen Anwendungen mit-
einander kommunizieren können. Im wesentlichen besteht dieser Standard aus einer Rei-
he von Schnittstellen, die COM-Anwendungen implementieren müssen. Dieser Standard
ist an keine Programmiersprache gebunden. Die Sprache muss lediglich den Aufruf von
Funktionen über Zeiger und die Implementierung von Referenzzählern gestatten. Damit
zwei Anwendungen miteinander kommunizieren können, muss ihr binärer Code COM-
kompatibel sein. In welcher Sprache der Quelltext der Anwendung aufgesetzt wurde, ist
unerheblich.
6
Kapitel 2. Schnittstellen
2. Der Implementierung einer Reihe von Diensten, die in das Windows-Betriebssystem inte-
griert sind (OLE32.dll und OLEAut32.dll) und COM ermöglichen.
[BKPS]
2.2.1.2. Was leistet COM?
1993 führte Microsoft COM als grundlegenden Mechanismus für die Interprozess- Komm-
unikation unter Windows ein. Die erste auf COM aufbauende Technologie zur Interprozess-
Kommunikation war OLE 2.0. Die vorangehenden Mechanismen zur Interprozess-Kommuni-
kation (DDE, OLE 1.0) basierten noch nicht auf COM. OLE 2.0 erlaubte :
·
Drag & Drop
·
Direkten Datentransfer zwischen Anwendungen
·
Verknüpfen und Einbetten von Objekten (OLE).
·
Automatisierung
Drag & Drop. Mit Nehmen & Fallenlassen ist es möglich, die Objekte der einen Anwendung
in den Fensterbereich einer anderen Anwendung mit der Maus zu ziehen. Die Objekte werden
dann erkannt und eingebunden. Es wird automatisch auf die Methoden des Objektes zugegrif-
fen.
Verknüpfen und Einbetten. Über diesen Mechanismus können Anwendungen, die Dateien
verarbeiten, Objekte anderer Anwendungen in ihre Dateien einbinden. Entweder indem Sie
die Daten des Objekts aufnehmen und speichern (Einbettung) oder indem Sie einen Link auf
die Datei des Objekts speichern (Verknüpfung). Typisches Beispiel sind Textanwendungen,
die es dem Anwender gestatten, in seinen Dokumenten neben reinem Text auch andere Ob-
jekte (Grafiken, Videos etc.) abzuspeichern. Statt selbst die Funktionalität zum Erzeugen und
Bearbeiten dieser Objekte bereitzustellen, ruft die Text-Anwendung über COM andere Anwen-
dungen auf, die auf die Bearbeitung dieser Objekte spezialisiert sind. Voraussetzung dafür ist,
dass diese Anwendungen unter Windows als OLE-Server registriert sind und dass die Text-
Anwendung als Container für OLE-Serverobjekte fungieren kann. Um ein eingebettetes oder
verknüpftes Objekt zu bearbeiten, ruft der OLE-Container den zugehörigen OLE-Server auf.
Dieser wird entweder als eigenständige Anwendung gestartet oder direkt im OLE-Container
ausgeführt (In-Place-Activation), wobei er sein Menü und seine Werkzeugleisten in den Rah-
men des OLE-Containers integriert. Die In-Place-Activation steht nur für eingebettete Objekte
zur Verfügung.
Automatisierung. Von Automatisierung spricht man, wenn eine Anwendung einen Teil ihrer
Funktionalität in Form von COM-Objekten anderen Anwendungen zur Verfügung stellt.
Anwendungen, die einen Teil ihrer Funktionalität auf diese Weise exportieren, nennt man
Automatisierungs-Server. Anwendungen, die diese Funktionalität nutzen, also Methoden der
COM-Objekte aufrufen, nennt man Automatisierungs-Controller oder -Clients.[BKPS]
7
Kapitel 2. Schnittstellen
2.2.1.3. DCOM
Dank DCOM (Distributed COM) kann eine Anwendung den Code eines auf dem lokalen Rech-
ner registrierten COM-Servers ausführen. DCOM ist die Erweiterung von COM für Netzwerke.
Mit DCOM kann eine Anwendung den Code eines DCOM-Servers ausführen, der auf einem
beliebigen Rechner im Netzwerk installiert ist.[BKPS]
2.2.2. OPC - COM/DCOM in der Automatisierungstechnik
In der Automatisierungstechnik hat COM/DCOM seit einigen Jahren einen festen Verwen-
dungszweck gefunden - durch OPC. OPC steht für OLE for Process Control, welches auf dem
Component Object Model basiert. Die OPC-Schnittstelle definiert einen bestimmten Kompo-
nententyp und legt fest, welche Leistungen diese Komponente erbringen muss. Einen solchen
"Dienste-Erbringer" nennt man einen OPC-Server. Typische OPC-Server realisieren die An-
bindung an die bestehenden Kommunikationssysteme. Ein Nutzer dieser Dienste ist der OPC-
Client. Solche Clients können Bedien- und Beobachtungssysteme, Archivierungssysteme und
andere Anwender von Prozessdaten sein. Jeder OPC-Server bietet denselben Satz von Eigen-
schaften und Methoden an, wodurch eine problemlose Zusammenarbeit von Komponenten
verschiedener Hersteller möglich ist.
Der Hersteller einer Baugruppe, die Prozessdaten liefert, stellt mit der Baugruppe einen OPC-
Server zur Verfügung. Der OPC-Server leistet die Anbindung an die Datenquelle. Die Details
der Umsetzung der Kommunikation mit der Datenquelle sind alleinige Sache des Baugrup-
penherstellers. Der Anwender des OPC-Servers wird durch herstellerspezifische Einzelheiten
nicht belastet. Ein OPC-Client ist nicht auf einen Server beschränkt, sondern kann beliebig
viele OPC-Server nutzen. Die Verbindung zwischen dem OPC-Server und dem OPC-Client
wird über das Component Object Model (COM) realisiert. COM ist die Basis für die OPC-
Kommunikation, die Erweiterung DCOM ermöglicht auch verteilte Anwendungen. Das OPC-
Konzept ist für die Anwendung in der Zell- und Leitebene konzipiert. Die OPC Foundation
besitzt zur Zeit über 150 Mitglieder, darunter alle bedeutenden, weltweit aktiven Hersteller
von Automatisierungssystemen.[BKPS] Zum genauen Aufbau von OPC, DCOM und COM+
sei auf [FS01] verwiesen.
2.2.3. CORBA
2.2.3.1. Grundlagen CORBA
CORBA (Common Object Request Broker) ist die Standardisierung des ORB (Object Request
Broker). Dieser ORB ist das Kernstück der, von der OMG (Object Management Group) her-
ausgegebenen OMA (Object Managment Architecture).
Mit der Veröffentlichung dieser Architektur sollte ein plattform-unabhängiger Standard zur
Entwicklung von objektorientierter, verteilter Software geschaffen werden.
8
Kapitel 2. Schnittstellen
Abbildung 2-3. Aufbau der Object Managment Architecture [Red96]
Wie in der Abbildung 2-3 dargestellt ist, kann man sich einen ORB auch als Objektbus
vorstellen. Wie bei einem Bussystem in der Automatisierungstechnik hat der ORB die beiden
Hauptaufgaben der Kommunikation und der Adressierung zu erfüllen. Auch diese Aufgaben
sind durch die OMG standardisiert.
Abbildung 2-4. Aufbau eines ORBs [Red96]
Mit Angabe der IOR (Interoperable Object Reference) ist die Adressierung und mit dem GIOP/
IIOP-Protokoll die Kommunikation zwischen den einzelnen ORBs gewährleistet. Nach dieser
kurzen Vorstellung der Architektur stellt sich nun die Frage:
,,Wie können damit verteilte, plattform-unabhängige Anwendungen erstellt werden?"
Zur Beantwortung dieser Frage sollte man zunächst den Namen des Standards
untersuchen. "Common Object Request Broker" steht - frei übersetzt - für "allgemeiner
Objektaufruf-Makler".
9
Kapitel 2. Schnittstellen
Abbildung 2-5. Aufruf eines Objektes [Red96]
Das heisst, ein ORB ermöglicht es, die Methoden eines CORBA Objektes irgendwo auf der
Welt zu veröffentlichen (Server) oder sie aufzurufen (Client). Dies soll schematisch in der
Abbildung 2-5 verdeutlicht werden. [BKPS]
2.2.3.2. Bilden eines Objektes
Um ein Objekt veröffentlichen zu können, muss es erst einmal gebildet werden. Um es aufzu-
rufen zu können, muss es bekannt und auffindbar sein. Daraus leitet sich der einfachste Ablauf
für die Entwicklung eines CORBA- Programms ab:
a. Definition des Objektes in IDL
b. Übersetzung in die jeweilige Zielsprache
c. Implementierung des Skeleton (Server)
d. Finden des Objektes mittels IOR
e. Aufruf der Serverobjekte durch Stub (Client)
Zur näheren Erläuterung:
Definition des Objektes in IDL. Zur Bildung eines Objektes sieht die OMA eine neue
Programmiersprache vor. Diese IDL (Interface Definition Language) wurde von der OMG
definiert und ist stark an C++ angelehnt. Mit dieser Sprache wird ein Objekt nur grob
definiert, d.h. es werden alle Datentypen und Methoden, die das Objekt besitzen soll,
festgelegt. Die Implementierung dieses Objektes erfolgt aber erst im Serverprogramm.
Übersetzung in die jeweilige Zielsprache. Da jedes CORBA Objekt in dieser Sprache be-
schrieben wird, ist es notwendig, diese IDL Datei in die jeweilige Zielsprache zu übersetzen.
Für diesen Zweck bringt jeder ORB einen IDL-Compiler mit, der mit Hilfe von sogenannten
Language Mappings diese Übersetzung vornimmt. Das Ergebnis sind meist 2 neue Dateien, in
denen ein Skeleton (Gerippe) und ein Stub (Stummel) gebildet wird.
Implementierung des Skeleton (Server). Das Skeletonobjekt enthält die Methodenrümpfe
aus dem IDL Objekt und der Stub ist ein Stellvertreterobjekt, um die Servermethoden aufrufen
10
Kapitel 2. Schnittstellen
zu können. Zur Fertigstellung des Servers ist es also notwendig, die bisher leeren Methoden zu
implementieren. Dazu wird ein neues Objekt im Quellcode des Servers gebildet, welches alle
Eigenschaften des Skeletons erbt. In diesem Objekt werden alle Methoden ausprogrammiert.
Die restliche Arbeit im Server ist meist die Initialisierung des ORBs und die Bildung einer
neuen Instanz des CORBA-Objektes.
Finden des Objektes mittels IOR. Jede Objektimplementierung erhält bei der Bildung einer
neuen Instanz, die für die Kommunikation notwendige IOR. Diese IOR ist weltweit eindeutig
und hat folgenden Aufbau:
Abbildung 2-6. IOR-Dump
CORBA sieht es vor, dass jeder ORB die Objektimplementierung (Server) mit dieser Ref-
erenz finden kann. Aus diesem Grund enthält die IOR die IP - Adresse, die Portnummer und
den Namen des Objektes. Es bleibt jetzt nur noch ein Problem: "Wie kommt die IOR zum
Client?". Dafür sieht CORBA mehrere Lösungen vor. Die erste ist die Ausgabe der IOR im
Server und das Einlesen im Client mittels einer Textdatei. Eine viel elegantere Möglichkeit
stellt die Benutzung eines der CORBA Object Services und zwar des Namensdienstes dar.
Dieser Dienst wird an einen IP-Port des Servers gebunden und bietet die Möglichkeit, CORBA-
Objekte unter einem freien Namen zu registrieren. Auf Anfrage hin liefert der Namensdienst
die entsprechende Objektreferenz IOR.[BKPS]
11
Kapitel 2. Schnittstellen
Abbildung 2-7. Kommunikation zwischen Client und Server [Hös01]
Aufruf der Serverobjekte durch Stub (Client). Das Stub-Objekt ist der lokale Stellvertreter
(Proxy) der Objektimplementierung. Es enthält nur die Aufrufe der Objektmethoden, die bei
entsprechendem Bedarf ausgeführt werden können. Dazu muss vom Stub-Objekt eine neue In-
stanz gebildet werden und mittels der IOR wird dieses lokale Objekt mit der Objektimplemen-
tierung verbunden. Für alle nun folgenden Methodenaufrufe ist jetzt der ORB verantwortlich.
Die Abbildung 2-7 macht die beschriebene Struktur deutlich. Dabei können unterschiedliche
ORBs und Rechner zum Einsatz kommen.
12
Kapitel 3. Protokollkoppler in der
Automatisierungstechnik
3.1. Allgemeines
In der Industrie werden schon seit einiger Zeit Protokollkoppler zwischen verschiedenen Feld-
bussen verwendet. In den meisten Fällen kommt dabei für die Übertragung OPC und DCOM
zum Einsatz (siehe Abschnitt 2.2.2). Auf der Koppeleinheit läuft dabei ein Microsoft kompati-
bles Betriebssystem, meist Windows CE. Einen anderer Weg wird beschritten, wenn die Daten
über serielle Schnittstelle aus dem Feld ausgekoppelt werden. Dann arbeitet in der Kopplerein-
heit meist nur ein Mikrokontroler. Leider halten sich die Firmen sehr bedeckt, wenn es um die
Technologie ihrer Geräte geht.
Die Lösungen spalten sich grob betrachtet in zwei Lager auf: Auf der einen Seite übernimmt
die Koppeleinheit die Masterfunktion auf dem Bus, es sind immer alle Daten im Ethernet ver-
fügbar. Auf der anderen Seite übernimmt die Koppeleinheit nur die Slave Funktionen. Dann
stehen nur einige Worte für den Datentransfer zur Verfügung. Es muss zusätzlich noch ein
Feldbus-Master in Betrieb sein. Diese Möglichkeit ist hauptsächlich zur Erweiterung bereits
vorhandener Lösungen vorgesehen, oder soll in Systemen eingesetzt werden, wo der Feldbus-
master integraler Bestandteil der Lösung ist.
3.2. Hilscher GmbH
3.2.1. Überblick über die Firma
Die Firma Hilscher ist seit 10 Jahren auf dem Gebiet der Industriellen Kommunikation tätig.
Die Firma versteht sich als Entwickler von Kommunikationsgeräten für verschiedene Feldbus-
se. Zur Produktpalette gehören PC-Einsteckkarten und OEM- Module für eigene Anschaltun-
gen zu eigenen Geräten. Der Firmensitz befindet sich in Hattersheim, im Rhein-Main Gebiet.
Die Produktbeschreibungen der erwähnten Geräte befinden sich auf der beigelegten CD.
3.2.2. Protocol Converter
Hinter dem Namen Protocol Converter, Produktbezeichnung PKV30, steht ein Gerät mit einem
seriellen- und einem Feldbusanschluss. Die Kopplung erfolgt hier von einem Sensor/Aktor, der
nur eine serielle Schnittstelle zum Datenaustausch besitzt. Im Feldbus tritt das PKV30 als Slave
auf. Unterstützt werden InterBus, Profibus, DeviceNET und CANopen. Auf der seriellen Seite
werden verschiedene Standardprotokolle oder eine nutzereigene Implementation angeboten.
Das Gerät ist für den Einsatz im Schaltschrank konzipiert und benötigt eine Eingangsspannung
von 18-30V.
13
Kapitel 3. Protokollkoppler in der Automatisierungstechnik
Der Listenpreis für das PKV 30 sind 455 Euro. Dazu wird noch ein Systempaket zur Admini-
strierung benötigt. Dieses kostet 43 Euro.
3.2.3. Protocol Converter Ethernet
Dieses Gerät, der firmeninterner Name ist PKV40, ist ein vollwertiger PC für den Hutschienen-
einsatz. Es stellt die Kopplung zwischen einem Feldbus und dem Ethernet mit TCP/IP her.
Je nach spezieller Ausführung übernimmt das Gerät die Masterfunktionalität für die Busse:
Profibus, Interbus, DeviceNET, CANopen und AS-Interface.
Die Hardware besteht aus einem 486'er Prozessor mit 66 MHz. An Speicher sind 4MB Flash
und 8MB RAM vorhanden. Für die Parametrierung ist eine serielle Schnittstelle vorgesehen.
Für die Energieversorgung wird auch hier eine Spannung von 18-24V benötigt.
Als Besonderheit wird zusätzlich ein WEB-Server auf dem Gerät angeboten.
Der Listenpreis für dieses Gerät beträgt 844 Euro.
3.3. Softing AG
3.3.1. Überblick über die Firma
Die Firma Softing bietet Lösungen für Steuerungssysteme und industrielle Kommunikation an.
Sie verfügt über ein 4CONTROL genanntes Projektierungs-, Visualisierungs- und Steuerungs-
programm. Einen weiteren Geschäftsbereich bildet die Entwicklung von Datenkommunikati-
onskomponenten für den Automobilbereich.
3.3.2. PROFIgate
Hinter dieser Produktbezeichnung verbirgt sich ein Gateway zwischen dem Profibus und dem
Ethernet. Das Gateway besteht aus zwei Teilen: Dem PROFIgate Server und dem PROFIgate
Client. Der Server ist die Hardwarekomponente. Sie verfügt über einen Profibus und einen
TCP/IP Anschluss. Der Client ist ein Treiber für Windows NT. Darüber können Programme,
die auf dem gleichen Rechner laufen, auf den Profibus zugreifen. [SPG]
3.4. Wiesemann & Theis GmbH
3.4.1. Überblick über die Firma
Die Firma ist in Wuppertal ansässig. In ihrer Produktpalette finden sich Nischenlösungen auf
dem Gebiet der Kommunikation der Feldebene direkt mit dem Ethernet und Internet. So gibt
14
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2001
- ISBN (eBook)
- 9783832461973
- ISBN (Paperback)
- 9783838661971
- Dateigröße
- 2 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Hochschule für Technik, Wirtschaft und Kultur Leipzig – unbekannt
- Note
- 1,0
- Schlagworte
- profibus protokollkoppler embedded linux gateway
