Entwicklung eines TCP/IP-Interfaces für einen Kommunikationsprozessor über MODBUS

Emberger, Ralf

Entwicklung eines TCP/IP-Interfaces für einen Kommunikationsprozessor über MODBUS

Zusammenfassung

Inhaltsangabe:Gang der Untersuchung:
Im Zuge der Modernisierung in der Automatisierungstechnik (Industrieautomation) und dem damit verbundenen weitreichenden Ineinandergreifen der verschiedenen Ebenen (CIM-Ebenenmodell) wird es immer mehr erforderlich, Prozessdaten nicht nur in der Prozessleitebene, sondern auch in der Produktionsleitebene oder gar den Unternehmensleitebenen sichtbar zu machen. Immer mehr spielt es einen bedeutende Rolle, dass Daten durchgängig in mehreren Ebenen verfügbar sind und Informationen beispielsweise nicht nur noch vom Betreuer der Produktionsanlage, sondern auch von den Planer in der Unternehmensführung gesammelt und ausgewertet werden können.
Für die Ankopplung der Geräte in der Automatisierungstechnik spielt außer den weit verbreiteten Feldbussen das Kommunikationssystem Ethernet-TCP/IP zunehmend eine Schlüsselrolle und findet durch verschiedene Faktoren immer mehr Einsatz in technischen Prozessen. Allerdings kann das Kommunikationssystem nicht unbesehen aus der Büroautomation in die Industrieumgebung übernommen werden. Diffizile Betrachtungen sind für den Einsatz von Ethernet in der Industrieautomation von Nöten.
In der vorliegenden Diplomarbeit ist die Aufgabe - bestehende Geräte über einen Kommunikationsprozessor an Ethernet anzukoppeln realisiert worden. Dabei wurde für den Kommunikationsprozessor eine Interfacekarte entwickelt, welche den Anschluss verschiedener Endgeräte über Ethernet ermöglicht. Die Entwicklung umfasste außer der Hardware-Auslegung auch die Software-Ankopplung an den Kommunikationsprozessor sowie die Auswahl der höheren Protokolle (bzw. dem Anwendungsprotokoll). Der Gesamtaufbau ermöglicht es nun, die Daten der angekoppelten Geräte über Engeräte wie Webbrowser, Prozessleitsystem, OPC-Server/Client, usw. zu visualisieren und umgekehrt auch über diese Endgeräte zu manipulieren.
Dem nachfolgenden Inhaltsverzeichnis ist zu entnehmen, dass in Kapitel 2 zunächst umfangreiche theoretische Grundlagen im Bereich Ethernet, TCP/IP, OSI-Referenzmodell, Anwendungsprotokolle (API´s), Modbus, Feldbusse, usw. erarbeitet wurden, bevor in Kapitel 3 eine Marktanalyse vorgenommen und auf deren Basis die Konzeption für die Umsetzung erarbeitet wurde. Die Realisierung (Kap. 4) beschreibt ausführlich die Hardware-Entwicklung der Interfacekarte sowie die softwaremässige Ankopplung der Karte an den Kommunikationsprozessor. Am Ende des 4.ten Kapitel werden die Inbetriebnahme sowie der Anschluss der potentiellen […]

Leseprobe

Inhaltsverzeichnis

ID 7218

Emberger, Ralf: Entwicklung eines TCP/IP-Interfaces für einen

Kommunikationsprozessor über MODBUS

Hamburg: Diplomica GmbH, 2003

Zugl.: Hochschule für Technik Esslingen (FH), Fachhochschule, Diplomarbeit, 2003

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

Vorwort, Danksagung

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Vorwort, Danksagung

Mit dem Thema ,,Entwicklung eines TCP/IP Interfaces für einen

Kommunikationsprozessor über Modbus" habe ich ein sehr interessantes

Themengebiet bearbeiten dürfen. Für die Bereitstellung dieser Möglichkeit

und der intensiven Betreuung meiner Arbeit möchte ich der Firma Lamtec

im Allgemeinen, meinem Betreuer Dipl.Ing. (FH) Olaf Winne und dem Leiter

der Entwicklungsabteilung Dipl.Ing. (FH) Bernd Jülg im Speziellen danken.

In dem 4,5-monatigen Bearbeitungszeitraum hat mir mein Betreuer immer

wieder Wege zur optimierten Hard- und Softwareauslegung aufgezeigt und

mich bei der Umsetzung des Projektes in jeglicher Hinsicht unterstützt.

Dafür möchte ich mich herzlich bedanken.

Mein besonderer Dank gilt ebenfalls Prof. Dr.-Ing. Harald Töpfer, der mich

während der Diplomarbeit seitens der FH betreute und meiner Tätigkeit

stets volle Aufmerksamkeit schenkte.

Inhaltsverzeichnis

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Inhaltsverzeichnis

Abkürzungsverzeichnis...

Kapitelübersicht...

1 Einleitung... 4

2 Theoretische

Grundlagen... 9

2.1

OSI-Schichten

Modell...

2.2

Server,

Client...

2.3

Master,

Slave...

2.4

Ethernet...

2.5

TCP/IP

und

UDP...

2.5.1

Internet

Protocol

(IP)...

2.5.2 Transport Control Protocol (TCP)...

2.5.3 User Datagram Protocol (UDP)...

2.5.4 Zusammenhang Ethernet und TCP/IP...

2.6

Höhere Protokolle, Anwendungsprotokolle...

2.6.1

Standard-Anwendungsprotokolle...

2.6.2

Anwendungsprotokolle

in der Automatisierungstechnik...

2.7

Ethernet/IP...

2.8

Modbus...

2.8.1 Modbus RTU, ASCII...

2.8.2

Modbus

TCP...

2.9

OPC...

2.10

Feldbus...

2.11

Profibus...

2.12

DeviceNet...

2.13

Prozessleitsystem...

3 Konzeption,

Marktanalyse... 68

3.1

Aufgabenstellung

und

Lösungsansätze...

3.1.1

Lösungsansatz

Software-Implementierung...

3.1.2 Lösungsansatz Stackauslagerung mit SoC...

3.2

Marktanalyse, Stand der Technik...

3.3

Gewählte Lösung, Realisierungsmodell...

4 Realisierung,

Umsetzung... 84

4.1

Eingesetzte Werkzeuge, Tools... 84

4.1.1

Entwicklungsumgebung,

Emulator...

4.1.2

Eingesetzte

Tools...

4.1.3 HyperTerm, Monitor Interface IC...

4.1.4 Demoversion Prozessleitsystem / OPC...

4.2 Anybus

IC... 89

4.2.1

Technische

Daten...

4.2.2

Interner

Aufbau...

4.2.3

Schnittstellen,

Anbindung...

4.2.4

Unterstützte

Anwendungsprotokolle...

Inhaltsverzeichnis

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

4.2.5

Datenmapping...

4.2.6

Parameter...

4.2.7 Monitor Interface (MIF)...

4.3 Ethernet

Modul,

Hardware-Realisierung... 96

4.3.1

Bauteilauswahl...

4.3.2

Testboard...

4.3.3

Schaltplanentwurf... 101

4.3.4

Layout... 106

4.3.5

Schnittstellen

des

Moduls... 112

4.3.6

Kurzresümee

Hardware-Realisierung... 113

4.4

Ethernet

Modul,

Software-Realisierung... 114

4.4.1 Modbus RTU über die serielle Schnittstelle, Einarbeitung.. 115

4.4.2 Senden und Empfangen eines Zeichens über UART... 120

4.4.3

Testprogramm... 122

4.4.4 Modbus RTU Master Software, Struktur... 124

4.4.5

Codierung,

Umsetzungsbeispiele... 131

4.4.6

Kurzresümee

Software-Realisierung... 139

4.5

Tests,

Inbetriebnahme...

140

4.5.1

Tests... 140

4.5.2

Inbetriebnahme... 140

4.5.3

Analyse

Ethernet-Datenverkehr... 142

4.6

Endgeräte...

144

4.6.1

Anschlussmöglichkeiten... 144

4.6.2 Beispiele, Anschluss verschiedener Endgeräte... 145

4.7

Gesamtaufbau...

155

4.7.1

Rückblick... 155

4.7.2

Realisierter

Gesamtaufbau... 156

4.7.3 Technische Daten des Moduls... 159

5 Zusammenfassung,

Ausblick... 160

Literaturverzeichnis...

164

Cybergraphie...

166

Abbildungsverzeichnis... 167

Anhang

Schaltplan

(Testboard,

Ethernet-Modul)... I

Layout,

Stückliste... III

Bild

Ethernet-Modul... X

Datenblätter, Sonstige Dokumente... XI

Source-Code... XX

Abkürzungsverzeichnis 1

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Abkürzungsverzeichnis, Begriffserklärungen

ABIC

Any Bus IC

ADU

Application Data Unit

ALI

Application Layer Interface

API

Application Program Interface

ARP

Adress Resolution Protocol

ASCII American

Standard

Code

for Information Interchange

CAM

Computer Aided Manufacturing

CAN

Controller Area Network

CENELEC

Comité Européen de Normailisation Electrotechnique

CI ControlNet

International

CIM Computer

Integrated

Manufacturing

CIP

Control and Information Protocol

COM

Component Object Model (Basis für OLE)

CRC

Cyclical Redundancy Check

DCOM

Distributed Component Object Model

DIN

Deutsches Institut für Normung

(ehemals : Deutsche Industrie Norm)

DLL Dynamic

Link

Libary

DP Dezentrale

Peripherie

DRC

Design Rule Check

EPROM

Erasable Programmable Read Only Memory

Function Code, Modbus Funktions-Code

FCS

Frame Check Sequence

FET Feld

Effekt

Transistor

FMS

Fieldbus Management System

FMS Feuerungs-Management-System

FTP

File Transfer Protocol

GND Ground,

Erde

HTTP

Hyper Text Transfer Protocol

IANA Internet

Assigned Numbers Authority

IAONA Industrial

Automation

Open Networking Alliance

IC Integrated

Circuit

ICMP

Internet Control Message Protocol

IEA Industrial

Ethernet Association

IEC

International Electrotechnical Commission

IEEE Institute

Electrical and Electronics Engineers

IP Internet

Protocol

ISO

International Standards Organisation

ISR

Interrupt Service Routine

KP Kommunikations - Prozessor

LED

Light Emitting Diode

MB Modbus

MBAP-Header Modbus

Applicaton Protocol Header

MIF Monitor

Interface

NEMS

Neuwert-, Erstwert- und Betriebsmeldesystem

Abkürzungsverzeichnis 2

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Abkürzungsverzeichnis (Fortsetzung):

ODVA

Open DeviceNet Vendor Association

OLE

Object Linking and Embedding

OPC

OLE für Process Control

OSI

Open Systems Interconnection

PA Process

Automation

PDU

Protocol Data Unit

PE Protective

Earth

PLS Prozessleitsystem

POP3

Post Office Protocol, Version 3

PROFIBUS

PROcess FIeld BUS

QoS

Quality of Service (Dienstqualität)

Query

Anfrage, Anforderung, Kommando (auch: Request)

Response Antwort,

Rückantwort

RTU

Remote Terminal Unit

RxD Receive

Data

SCI Serial

Communication

Interface

SMTP Simple

Mail

Transfer

Protocol

SNMP Simple

Network

Management Protocol

SOAP

Simple Open Acess Protocol

SoC System

Chip

SPS

Speicher Programmierbare Steuerung

SSC Synchronous

Serial Channel

TCP Transport

Control

Protocol

Token Senderecht,

Buszugriffsberechtigung

TxD Transmit

Data

UART

Universell Asynchronous Receiver / Transmitter

UDP

User Datagram Protocol

URL

Universal Resource Identifier

XML Extended

Markup

Language

Kapitelübersicht

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Kapitelübersicht

Der Aufbau der Diplomarbeit soll kurz in einer Kapitelübersicht dargestellt

werden.

Kapitel 1 Einleitung

Die Firma Lamtec sowie Ihr Tätigkeitsspektrum wird kurz erläutert, darüber

hinaus wird die Aufgabenstellung und das Projektziel umrissen.

Kapitel 2 Theoretische Grundlagen

In diesem Kapitel werden theoretische Grundlagen zu den Themen TCP/IP,

Modbus, Feldbus, Anwendungsprotokoll u.v.m.

erläutert. Dieses Kapitel

dient als Grundlage zu den Ausführungen in Kapitel 3 und 4.

Kapitel 3 Konzeption, Marktanalyse

Hier wird dargestellt, welche Hard- und Software-Lösungen es bereits auf

dem Markt gibt und welche Realisierungsmöglichkeiten zur Diskussion

standen. Die Auswahl und Konzeption der realisierten Lösung wird im

Anschluss dargestellt.

Kapitel 4 Realisierung und Umsetzung

Das vierte Kapitel beschreibt alle Schritte der realisierten Arbeit. Dies

bedeutet Beschreibungen über die eingesetzten Mittel und Werkzeuge, die

Soft- und Hardwareentwicklung, den Gesamtaufbau und das Testen des

Systems.

Kapitel 5 Schluss und Zusammenfassung

In der Zusammenfassung wird das Ergebnis kurz dargestellt sowie ein

Ausblick auf noch zu lösende Problemstellungen gegeben.

Anhang

Im Anhang sind sämtliche wichtigen Projektskizzen, Gedankenmodelle,

Schaltplan und Layout sowie der Source-Code u.v.m. aufgelistet.

das Kapitel Profibus wurde hier aufgenommen, weil bei der realisierten Lösung Anfangs

Ersatzweise mit einem Profibus-System entwickelt wurde. Das Kapitel DeviceNet wurde

aufgenommen, weil das fertige Modul außer Ethernet auch eine Schnittstelle zu DeviceNet zur

Verfügung stellt.

1. Einleitung

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

1. Einleitung

Die vorliegende Diplomarbeit wurde im Zeitraum Mitte Februar bis Ende Juni

2003 bei der Firma Lamtec GmbH & Co KG angefertigt. Die Firma Lamtec

stellt Geräte und Sensoren für den Bereich der Feuerungstechnik her. Die

1995 gegründete Firma wurde von ABB-Deutschland als sog. ,Management-

Buy-Out' mit dem Produktbereich Lambda-Sonde aufgebaut.

Lamtec

Die Firmengruppe besteht aus der Hauptverwaltung Lamtec Mess- und

Regeltechnik für Feuerungen GmbH & Co KG ansässig in Walldorf, Lamtec

Leipzig GmbH & Co KG für den Bereich Flammüberwachung und der in Neu-

Anspach gelegenen Entwicklungsabteilung. Das Produktspektrum reicht von

der Brennersteuerung und -Regelung inklusive Flammüberwachung, über

die Rest-Sauerstoff-Messung bis hin zu Betriebs- und Störmeldegeräten.

Damit bietet Lamtec ein vollständiges Produktspektrum zum Betrieb von

Industriefeuerungen, welche beispielsweise in Kraftwerken

(Kesselfeuerungen) oder Schiffen eingesetzt werden. Alle Lamtec-Geräte

können über einen firmeneigenen CAN-Bus (Lamtec-System-Bus) vernetzt

werden. Die Ankopplung an gängige Feldbusse wie etwa Profibus, Interbus,

usw. erfolgt über einen Kommunikationsprozessor.

Die folgende Abbildung zeigt eine Kurzübersicht einer geregelten Feuerung,

die mit Lamtec-Systemkomponenten realisiert ist:

Abb. 1-1

Übersicht einer Feuerungsanlage mit Regelgeräten und Sensoren

1. Einleitung

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Die einzelnen Geräte, z.B. die FMS (Feuerungs-Management System) oder

das NEMS (Neuwert-, Erstwert- und Betriebsmeldesystem) sind im Anhang

ab Seite XVII mit einer kurzen Beschreibung erläutert.

Die Entwicklungsabteilung von Lamtec liegt wie bereits erwähnt in Neu-

Anspach. Hier sind 4 feste und 3 freie Mitarbeiter mit der Entwicklung neuer

Geräte und Sensoren beschäftigt. Dort habe ich in dem 4,5-monatigen

Zeitraum meine Diplomarbeit bearbeitet und angefertigt.

Abb. 1-2

Bild von der Entwicklungsabteilung, Neu-Anspach

Rahmenbedingungen und Hintergründe zur Aufgabe

In [1] wird das moderne Verständnis des Begriffes ,,Industrieautomation"

(Automatisierungstechnik) als die Steuerung und die Überwachung von

technischen Prozessen durch Rechner, genauer gesagt durch die Software in

den Rechnern, beschrieben. Dabei ist mit einem ,technischen Prozess'

heutzutage eine weitreichende Systempalette gemeint, angefangen von

klassischen Produktions- und Verfahrenstechniken im Anlagen- und

Maschinenbau, über Embedded-Systeme bis zu Anwendungen in

Fahrzeugen, Flugzeugen, Schiffen, usw.

Die Unterscheidung zwischen technischen und kommerziellen Prozessen

(Geschäftsprozessen) wird immer mehr nur noch durch die

Ablaufbedingungen (zeitliche Bedingungen) und den Betriebsumgebungen

(extreme Temperaturen, Vibrationen, Schmutz, usw.) bestimmt, d.h. der

Unterschied zwischen einem technischen und einem kommerziellen Prozess

reduziert sich zunehmend. Deshalb ist es naheliegend, dass Entwicklungen

die im kommerziellen Bereich mit enormem Aufwand erarbeitet worden

sind, immer mehr den Einzug in die Industrieautomation finden.

1. Einleitung

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Dies hat Auswirkungen auf den Einsatz auf der Hardwareebene (PC-

Technologie), der Systemsoftware und bei den Kommunikationssystemen

(z.B. Ethernet-TCP/IP und Internet-Technologien).

Im Zuge dieser Modernisierung in der Automatisierungstechnik und dem

damit verbundenen weitreichenden Ineinandergreifen der verschiedenen

Ebenen (siehe CIM-Ebenenmodell, Kapitel 2.10) wird es immer mehr

erforderlich, Prozessdaten nicht nur in der Prozessleitebene, sondern auch

in der Produktionsleitebene oder gar Unternehmensleitebene sichtbar zu

machen. Immer mehr spielt es eine bedeutende Rolle, dass Daten

durchgängig in mehreren Ebenen verfügbar sind und Informationen

beispielsweise nicht nur noch vom Betreuer der Produktionsanlage, sondern

auch von den Planern in der Unternehmensführung gesammelt und

ausgewertet werden können.

Dabei wird die Rolle des Kommunikationssystems Ethernet-TCP/IP

zunehmend wichtiger, nicht zuletzt aufgrund folgender Faktoren:

· TCP/IP unterstützt das Server/Client-Prinzip (Kap. 2.2) optimal

· Ethernet-TCP/IP stellt einen Hersteller unabhängigen und weit

akzeptierten Standart für den Datentransport dar (Kap. 2.5.4)

· TCP/IP ermöglicht eine nahtlose Anbindung an die kommerzielle Welt

(PC´s und Mainframe-Systeme)

· TCP/IP erlaubt den Datenaustausch über das Internet und über

Intranets (Firmeneigene Netzwerke)

· Ethernet und TCP/IP entwickeln sich aufwärtskompatibel weiter und

halten Schritt mit den Möglichkeiten der neuen Technologien

(100Mbit/s, 1Gbit/s, Switching, usw.), Kap. 2.4 und 2.5

[1, Seite 9]

Ethernet-TCP/IP kann allerdings nicht ,unbesehen' aus der Büroautomation

in die Industrieumgebung übernommen werden. Es müssen Maßnahmen

getroffen werden, um die geforderten Zeitverhältnisse zu erreichen, um

geeignete API´s (Application Programmers Interface, siehe Kap. 2.6)

anzubieten und um eine industrietaugliche Installation zu gewährleisten.

[1, Seite 9]

Deshalb ist ein Vergleich bzw. eine Betrachtung der bereits etablierten

Feldbusse (Kap. 2.10 bis 2.12) von Vorteil und auch die Betrachtung der

API bzw. der höheren Protokolle (Anwendungsprotokolle, Kap. 2.6) ist

erforderlich, wenn man Ethernet (als Feldbus) in der Industrieautomation

einsetzten möchte.

Aufgrund der Entwicklung, dass Ethernet immer häufiger im Bereich der

Industrieautomation eingesetzt wird, wurden auch bei Lamtec Überlegungen

angestellt, ob und wie eine Ankopplung der vorhandenen Lamtec-Geräte

über Ethernet realisiert werden könnte. Dabei war die Vorstellung, dass die

1. Einleitung

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Daten beispielsweise von der Brennersteuerung (FMS/VMS) über ein

firmeninternes Netzwerk (Intranet) dargestellt und manipuliert werden

können. Die Vernetzung über Ethernet stellte dabei eine Herausforderung

dar, sich der Entwicklung in diesem Bereich anzupassen und auf dem

neuesten Stand der Technik zu bleiben. Auch der zunehmend geäußerte

Kundenwunsch, diese Möglichkeit der Vernetzung der Lamtec-Gerätefamilie

zu erhalten begründete die Aufgabe, diese Ankopplung zu realisieren.

Daraus ergab sich dann die Aufgabenstellung für meine Diplomarbeit.

Aufgabenstellung

Um Prozessdaten der Lamtec-Geräte (z.B. Brennersteuerung/Regelung)

über einen Feldbus zugänglich zu machen, wird ein eigenentwickelter

Kommunikationsprozessor mit verschiedenen Aufsteckkarten eingesetzt. Die

vorhandenen Aufsteckkarten (Interfacekarten) stellen Schnittstellen zu

Profibus, Interbus, Modbus seriell, RS232 und RS485 sowie CANOpen zur

Verfügung.

Der Wunsch, die Lamtec-Geräte an das Ethernet zu koppeln ist demnach

mit der Entwicklung einer weiteren Interfacekarte verbunden. Wie bereits

im vorigen Abschnitt beschrieben ist mit Ethernet auch die Verwendung des

weit verbreitenden TCP/IP etabliert worden. Das Einsetzen eines

Anwendungsprotokolls und die Ankopplung verschiedener Endgeräte

hingegen erfordern eine Auswahl. Diese begründet sich zum einen durch

den Kundenwunsch (bereits vorhandene Endgeräte) und der geforderten

Möglichkeit, Daten auf der Prozessleitebene möglichst breitgefächert (d.h.

je mehr Anwendungsprotokolle zur Verfügung stehen, desto mehr

Anschlussmöglichkeiten ergeben sich daraus) zu Visualisieren- und

Manipulieren. Die erklärten Ziele des Projekts sind zusammengefasst:

· Entwicklung einer Interfacekarte für Ethernet

· Ausarbeitung einer Konzeption, um sämtliche Lamtec-Geräte an

Ethernet anschließen zu können

· Auswahl eines Anwendungsprotokolls und damit der

Anschlussmöglichkeiten

· Hard- und softwaremäßige Umsetzung der Konzeption

· Test und Inbetriebnahme der Interfacekarte mit einem oder

mehreren potentiellen Endgeräten

Daraus ergibt sich ein geplanter Gesamtaufbau, der im folgenden Schaubild

dargestellt ist. An das Ethernet können mehrere potentielle Endgeräte

angeschlossen werden, um die Datenvisualisierung- und Manipulation

1. Einleitung

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

vornehmen zu können. In diesem Beispiel ist der Anschluss eines

Prozessleitsystems (PLS) als Endgerät dargestellt. Die rot markierten

Bereiche zeichnen die Bereiche aus, die in der Diplomarbeit bearbeitet und

umgesetzt werden sollen.

Abb. 1-3

Möglicher Aufbau des geplanten Gesamtsystems

Lösungsweg

Die Aufgabe, die Lamtec-Geräte über Ethernet an verschiedene Endgeräte

zu koppeln, setzte zunächst die Erarbeitung theoretischer Grundlagen

(dargestellt in Kapitel 2) voraus, um die prinzipielle Ankopplung verstehen

und planen zu können.

Aus einer Analyse über den Stand der Technik und den potentiellen

Möglichkeiten wie diese Ankopplung realisiert werden kann, sollten dann

Lösungsvorschläge erarbeitet werden. Nach einer Gegenüberstellung und

Diskussion der einzelnen Merkmale sollte eine favorisierte Lösung

umgesetzt werden (siehe Kapitel 3).

Anschließend wurde eine Konzeption zur Umsetzung dieser Lösung

erarbeitet. Auf der Basis dieser Konzeption fand dann die Realisierung in

Hard- und Software statt (Kapitel 4). Aus Verfügbarkeitsgründen wurde

zunächst auf einem Profibus-System (Kap. 2.11) entwickelt und erst später

auf Ethernet (Kap. 2.4) übergegangen. Dabei bot es sich bei der Lösung an,

DeviceNet (Kap. 2.12) als ,Nebenprodukt' zu integrieren.

Nach der Entwicklung der Interfacekarte und der zugehörigen Software

folgte die Inbetriebnahme und die Tests, insbesondere die der Endgeräte

um den Gesamtaufbau verwirklichen zu können (Kapitel 4.5 bis 4.7).

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

2. Theoretische

Grundlagen

2.1 OSI-Schichten

Modell

Das von der ISO (International Standards Organisation) genormte Modell ist

für die Verbindung offener Systeme erarbeitet worden. Das sogenannte

OSI-Referenzmodell (OSI = Open Systems Interconnection) gliedert die

Kommunikationsfunktionen in 7 Schichten und definiert die Funktionen

jeder Schicht. Die einzelnen Schichten stellen bestimmte Dienste zur

Verfügung. Die Aufgabe jeder Schicht ist es dabei, der nächsthöheren

Schicht Dienste zur Verfügung zu stellen unter der Benutzung der Dienste

der darunter liegenden Schichten.

Somit ergibt sich ein Denkmodell für Kommunikationssysteme, welches

aufgrund der klar definierten Funktionen jeder Schicht und den

Schnittstellen zwischen den Schichten auch eine große praktische

Bedeutung erreicht hat. Der Hauptvorteil ist, dass einzelne Schichten durch

andere technische Implementationen zu ersetzten sind, ohne an den

übrigen Schichten Änderungen vornehmen zu müssen

(Modularitätsgedanke). So ist es beispielsweise möglich, die physikalische

Übertragung von der Telefonleitung auf ein Satellitensystem zu ändern,

ohne dass sich die Grundstruktur des Netzwerkes ändert (da dies keine

Auswirkung auf die oberen Schichten hat). Dieser Vorteil erlaubt Flexibilität

bei der technischen Implementierung und Unabhängigkeit von Hardware

Herstellern. [1, S.35 und 2, Kapitel 2.0]

Die Schichtkommunikation läuft immer nach demselben Schema ab: eine

Schicht N auf Maschine A kommuniziert mit der Schicht N auf Maschine B.

Dabei gibt es eine Verbindung zwischen den Schichten, eine sog. Peer-

Verbindung. ,,Peer" (engl.) heißt gleichrangig, oder gleichberechtigt und soll

zum Ausdruck bringen, dass die Arbeitseinheiten einer Schicht (Summe

aller Dienste) auf Maschine A Dienste bereitstellen die es auf Maschine B in

derselben Schicht in gleicher Form gibt. Die Regeln und Vereinbarungen für

die Kommunikation werden als Protokoll bezeichnet. Aus diesem

Zusammenhang entsteht dann auch der Begriff: Peer-to-Peer Protokoll.

Es werden dabei keine Daten direkt von Schicht zu Schicht übertragen,

sondern Daten und Kontrollinformationen (Header, CRC, usw.) werden

Schicht für Schicht nach unten bzw. oben durch die Hierarchie der Ebenen

gereicht. Die eigentliche physikalische Übertragung der Daten zwischen den

zwei Maschinen erfolgt über das physikalische Medium, das unter der

tiefsten Schicht liegt.

Die oberen drei Schichten des OSI-Modells entsprechen

anwendungsorientierten Funktionen in der Kommunikation, die unteren vier

Transport-Funktionen. Die Schichten werden von unten nach oben

nummeriert, so dass Schicht 1 (Physical Layer) dem physikalischen

Übertragungsmedium und Schicht 7 (Application Layer) dem Endbenutzer

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

am Nächsten steht. Bei einigen technischen Implementationen kommt es

vor, dass von den 7 Schichten des Modells nur Dienste in z.B. 2 oder 3

Schichten bestehen, die physikalische Übertragungsschicht gibt es dabei

immer. [1, S.35 und 2, Kapitel 2.0]

Die folgende Tabelle zeigt die 7 Schichten und umreißt kurz die Funktionen

der einzelnen Schichten:

7. Anwendungsschicht (Application Layer)

Diese Schicht bietet Dienste für die anderen Teilnehmer im Netz an, wie z.B.

Lesen od. Schreiben, in Form von z.B. Telnet. Die ALI (Application Layer

Interface) bzw. API (Application Program Interface) stellen die Schnittstelle zu

den Anwendungsprogrammen dar. Als Schicht 7b oder 8 werden oftmals die

Anwenderprogramme selbst bezeichnet.

6. Darstellungsschicht (Presentation Layer)

Hier wird die Umsetzung von Daten entsprechend der Codierung

vorgenommen (Syntaxumsetzung). Zeichensätze, Textdarstellungen, grafische

Darstellungen, usw. werden für den Rechner verständlich gemacht. Bietet

Unabhängigkeit von der Darstellung.

5. Sitzungsschicht (Session Layer)

Kommunikationssteuerungsschicht

Organisiert den geregelten Ablauf von Tasks, im Speziellen Verbindungen. Hier

wird der z.B. der Aufbau, Unterhalt und der Abbau einer Verbindung

organisiert.

4. Transportschicht (Transport Layer)

Steuerung und fehlerfreie, folgerichtige Ablieferung der Telegramme

3. Netzwerkschicht (Network Layer) Vermittlungsschicht

Die Suche und Benutzung von geeigneten Übertragungswegen durch das

Netzwerk zwischen Sender und Empfänger. Stichworte: Adressierung,

Pfadsuche, Pakets, realisiert über das IP.

2. Datenübertragungsschicht (Data Link Layer)

Sicherungsschicht

Hier wird das Versenden und Empfangen von Daten geregelt. Diese Schicht

umfasst 2 Aufgaben: die Rahmenbildung (Framing) und den Buszugriff (MAC).

Bei der Rahmenbildung wird ein Paket gebildet, das Elemente wie Adressfeld,

Controlbits, Daten aus Schicht 3-7, Prüfbits, usw. enthält Datentelegramm.

Beim Buszugriff ist es wichtig wie eine Station den Zugriff auf den Bus

vornimmt. Hier kommt die fehlergesicherte Übertragung von Datenblöcken

zum Einsatz.

Kommun

ika

tionss

yst

(Eint

in Sc

hic

n, d

ie Diens

zur

erfü

ung

len)

1. Physikalische Schicht (Physical Layer)

Bitübertragungsschicht

Physikalische Realisierung der Übertragung. Hier wird das

Übertragungsmedium (Koax, Zweidraht, usw.), die Spannungspegel, Form der

0/1-Impulse, Modulation, max. Übertragungsrate uvm. festgelegt.

Tab. 2-1

Die 7 Schichten des OSI-Referenzmodelles

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Die Kommunikation findet nach dem OSI-Modell immer zwischen

gleichgestellten Arbeitseinheiten (Summe aller Dienste einer Schicht) statt.

Deshalb spricht man auch von einer horizontalen Verbindung. Der

eigentliche Weg der Nachricht ist jedoch vertikal, denn die Nachricht geht

von der höchsten implementierten Schicht den Weg nach unten bis zur

Schicht 1 und wird dann schließlich über das physikalische Medium

übertragen.

Wird beispielsweise ein Sendeprozess von Maschine A gestartet, werden die

Daten der Anwendungsschicht mit einem Header (Nachrichten-Kopfteil)

versehen, und an die Darstellungsschicht weitergeleitet. Dort können die

Daten (in diesem Falle zählen die Daten und der Header der

Anwendungsschicht zum Datenteil von der Darstellungsschicht) manipuliert

und wiederum weitergereicht werden. Beim Weiterreichen zur nächsten

Schicht wird dabei wiederum der Header der Darstellungsschicht

hinzugefügt, usw. So wird die Nachricht durch das Weiterreichen in den

verschiedenen Schichten immer länger und schließlich in Schicht 1

übertragen. [2, Kapitel 2.0]

Abb. 2-1

OSI-Referenzmodell und seine vertikalen Verbindungen [2, Kapitel 2.0]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Abb. 2-2

OSI-Referenzmodell, Header-Generierung [2, Kapitel 2.0]

2.2 Server

Client

Das Server-/Client-Modell ist ein weit verbreitetes Modell im Bereich

Kommunikationsnetzwerke. Denn außer dem Buszugriffsverfahren (im

Kapitel 2.10 erläutert) muss auch die sog. Betriebsphilosophie festgelegt

werden. Dies bedeutet, dass den verschiedenen Stationen unterschiedliche

Aufgaben zugeteilt werden.

Derjenige Teilnehmer eines Netzes, der die Verbindung aktiv aufbaut, nennt

man Client (Kunde). Der Netzteilnehmer zu dem die Verbindung aufgebaut

wird, nennt man Server (Anbieter von Dienstleistungen).

Außerdem wird unterschieden, ob der Server ein sog. ,Iterativer Server'

oder ein ,Concurrent Server' ist. Der Iterative Server kann nur eine Anfrage

des Clients beantworten und ist bis zu dessen Abarbeitung besetzt. Der

Concurrent Server hingegen kann mehrere Anfragen von mehreren Clients

behandeln.

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Eine Server-/Client Beziehung muss vom Client aufgebaut und vom Server

akzeptiert werden, bevor der Client von der Dienstleistung des Servers

Gebrauch machen kann. Ebenso muss die Beziehung vom Client nach der

Benutzung der Server-Funktionen wieder abgebaut werden.

[1, Seite 105]

2.3 Master / Slave

Beim Master-Slave-Verfahren ist ein einziger Teilnehmer der Master (Herr)

über den Bus und teilt den anderen Teilnehmern (Slaves) das Senderecht

zu. Der Master kann also selbst ein Telegramm senden oder er kann einem

Slave das Senderecht zuteilen, so dass der Slave ein Telegramm zum

Master sendet. Slaves können untereinander nicht (ohne Master)

kommunizieren, d.h. es ist immer ein Master erforderlich.

Die Kommunikation wird beim Master-Slave-Verfahren meist über ein

,,Kommando-Antwort-Schema" (Query-Response-Schema) abgewickelt.

Hierzu schickt der Master mit dem Kommando eine Nachricht an den Slave,

dieser quittiert den korrekten Empfang durch die Antwort. Auf diesem Weg

kann der Master auch Daten vom Slave erhalten.

In der Regel werden die Slaves streng zyklisch angesprochen. Dies

bedeutet, in einem vorgegebenen Zeitrahmen werden die Stationen

wiederholt (zur Datenübermittlung) angesprochen. So werden die Daten im

Master gesammelt und ausgewertet. Das hat zur Folge, dass die Slaves

meist recht einfach ausgeführt sind, während der Master die ,,Intelligenz"

des Systems trägt.

[1, Seite 68]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

2.4 Ethernet

Ethernet ist der heute am weitesten verbreitete Netzwerkstandard im

Office-Bereich. Bereits 1996 waren ca. 86% aller bestehenden Netzwerke in

dieser Technologie realisiert. Ethernet stellt die physikalische Grundlage zur

Verbindung von Geräten dar.

Ethernet bezeichnet das physikalische Medium der Übertragung und findet

sich im OSI-Referenzmodell (Kap. 2.1) in der untersten Schicht wieder. Der

Buszugriff sowie das Framing (Rahmenbildung, Paket) sind in der 2.ten

Schicht angesiedelt, diese Aufgaben übernimmt in der Realität der Ethernet-

Controller.

Ursprünglich wurde Ethernet mit einer Übertragungsgeschwindigkeit von

10Mbit/s entwickelt, die kontinuierliche Weiterentwicklung hat über Fast

Ethernet (100Mbit/s) bis zu Gigabit-Ethernet (1000Mbit/s) zu einer Reihe

von verschiedenen Standards geführt. Im folgenden ist eine Grobübersicht

über die verschiedenen Entwicklungsstufen aufgeführt.

[4, Seite 11ff]

10Base2

Thin Ethernet, Cheapernet oder auch BNC-Netzwerk. Alle

Netzteilnehmer werden parallel auf ein Koaxialkabel (RG58,

50 Ohm Wellenwiderstand) geschaltet. Das Kabel muss an

beiden Seiten mit einem 50 - Terminator (Endwiderstand)

abgeschlossen werden.

10BaseT

Twisted Pair wird über einen Hub (Sternverteiler)

angeschlossen.

100Base T4

Ebenso wie bei 10BaseT wird jeder Netzteilnehmer über ein

Twisted-Pair Kabel an einen Hub angeschlossen. Der

Unterschied liegt in der Übertragungsrate von 100Mbit/s

anstatt bisher 10Mbit/s

100Base TX

Twisted Pair, Kabelkategorie 5. Stellt den heute üblichen

Standart für 100Mbit Netzwerke dar.

Tab 2-2:

Grobübersicht, Ethernet-Übertragungsmedien

Die heutige, zuständige Norm IEEE 802 ist in den ersten beiden Schichten

des OSI-Referenzmodelles angesiedelt. In der Regel werden 100Mbit-

Netzwerke in Twisted-Pair Technik ausgeführt. Ein technisches Gerät besitzt

eine vom Hersteller vergebene Ethernet-Adresse (auch MAC-ID

genannt).

Diese ist 6 Byte groß, und wird üblicherweise in hexadezimaler Schreibweise

angegeben.

MAC-ID = Medium Access Control Identification, auch Node-Adress oder Ethernet-Adresse

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Ein typisches Beispiel wäre: 00-C0-3D-00-27-8B, wobei die ersten 3 Bytes

den Hersteller-Code angeben, die weiteren 3 Bytes laufende Nummern sind,

welche ebenfalls vom Hersteller vergeben werden.

Ethernet an sich besitzt nicht die Möglichkeit verschiedene Netze zu

adressieren. Deshalb muss das aufgesetzte IP-Protokoll (Schicht 3, Kap. 2.1

OSI-Referenzmodell) einen geeigneten Pfad suchen, um ein Paket zustellen

zu können. Dies erfolgt über Router oder Gateways, die Beschreibung für

die Verbindung von Einzelnetzen ist in Kap. 2.5.1 zu finden.

Darüber hinaus arbeitet Ethernet verbindungslos, d.h. der Absender erhält

keine Bestätigung darüber ob sein Paket angekommen ist oder nicht.

Deshalb wird eine Paketsicherung im Sinne einer sicheren Übermittlung

eingesetzt, hierfür verwendet man das TCP-Protokoll (Kap. 2.5.2) welches

wie IP auf Ethernet aufsetzt und in der 4.ten Schicht des OSI-

Referenzmodells zu finden ist.

[4, Seite 13ff]

Ethernet-Datenpaket:

Abb. 2-3

Aufbau eines Ethernet-Datenpaketes [4, Seite 14]

Über die MAC-ID, der Ethernetadresse wird dem Gerät ein Datenpaket

zugestellt. Dort angekommen werden die Nutzdaten verarbeitet. Diese

enthalten sämtliche Informationen der darüber liegenden Schichten. Diese

Nutzdaten werden nach dem Zwiebelprinzip extrahiert und dann schließlich

im Anwenderprogramm als höchster Ebene verarbeitet.

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Zugriffsverfahren CSMA / CD

Es gibt verschiedene Möglichkeiten des Buszugriffs, diese werden im Kapitel

2.10 (Feldbus) erläutert. Bei Ethernet erfolgt der Buszugriff bei Bedarf, d.h.

der Teilnehmer sendet unmittelbar wenn Daten zum Versand anstehen.

Dazu wird das sog. CSMA/CD-Verfahren (Carrier Sense Multiple Access with

Collision Detection) angewendet.

Dieses Verfahren funktioniert nach folgendem Prinzip: will eine Station

senden, so prüft sie zuerst ob keine andere Kommunikation aktiv ist

(Carrier Sense, Trägererkennung). Falls das Netz frei ist, beginnt die Station

sofort zu senden. Während des Sendens beobachtet die Station jedoch das

Netz, um mögliche Kollisionen zu erkennen (Collision Detetction,

Kollisionserkennung). Wird eine Kollision erkannt, wird das Senden sofort

eingestellt. Danach bestimmen verschiedene Algorithmen, nach welchen

Zeitabständen eine Sendung wieder aufgenommen wird.

[1, Seite 60]

Durch dieses Buszugriffsverfahren ist eine grundsätzliche Echtzeitfähigkeit

nicht gegeben, allerdings können ,,Worst-Case-Fälle" aufgestellt werden. Um

in der Automatisierungstechnik trotzdem ein Echtzeitverhalten garantieren

zu können, wurden spezielle Geräte (Switches) entworfen, welche einen

vorherbestimmten Übertragungsweg (nur 2 Teilnehmer, kollisionsfrei) und

damit eine vorherbestimmte Zeit garantieren können. Mehr Informationen

dazu in Kapitel 2.7 (Ethernet/IP).

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Ethernet-Standards

Seit 1985 haben sich einige Standards entwickelt, diese wurden von der

IEEE (Institute of Electrical and Electronics Engineers) entwickelt. Die

folgende Tabelle zeigt eine Übersicht über sämtliche Standards.

Tab. 2-3

Übersicht: Ethernet-Standards, [1, Seite 69]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

2.5 TCP / IP und UDP

Schon in den 60er Jahren vergab das amerikanische Militär den Auftrag, ein

Protokoll zu entwickeln, welches unabhängig von der verwendeten Hard-

und Software einen standardisierten Informationsaustausch zwischen einer

beliebigen Anzahl verschiedener Netzwerke möglich machen sollte. Im Jahre

1974 wurde dann aus dieser Vorgabe die TCP/IP Protokollfamilie, übrigens

weit vor der Einführung des OSI-Referenzmodelles (1984).

Trotzdem lässt sich die Protokollfamilie eindeutig den Schichten des OSI-

Referenzmodelles zuordnen. So ist das IP (IP = Internet Protocol) in der

Schicht 3 (Vermittlungsschicht), dass TCP (Transport Control Protocol) in

der Schicht 4 (Transportschicht) zu finden. Dies bedeutet, dass TCP auf dem

IP-Protokoll aufbaut. Im Folgenden sollen nun beide Protokolle separat

erläutert werden. [4, Seite 15]

2.5.1 Internet Protocol (IP)

Das Internet Protocol macht es möglich, eine unbestimmte Anzahl von

Einzelnetzen zu einem Gesamtnetzwerk zusammenzufügen. Es ermöglicht

also den Datenaustausch zwischen zwei beliebigen Netzteilnehmern, die

jeweils in beliebigen Einzelnetzen positioniert sein können. Dabei spielt die

physikalische Ausführung der Netze bzw. Übertragungswege (Ethernet,

ISDN, usw.) keine Rolle. Die Daten werden ungeachtet dieser Unterschiede

an den Empfänger übermittelt. [4, Seite 15]

Abb. 2-4

Verbindung von Einzelnetzen, Übertragungswege [4, Seite 15]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Das Internet Protocol erfüllt also die Aufgabe, Datagramme (Datenpakete)

von einem Netzteilnehmer zu einem anderen Netzteilnehmer im gleichen

oder in einem verbunden Netz zu übertragen. Befindet sich der andere

Netzteilnehmer nicht im selben Netz, wird der Pfad mittels eines Routers

aufgebaut. Der Router stellt eine Vermittlung (Weitergabe) des Paketes in

ein anderes Netz bereit. Somit stellt IP einen Datagramm-Übertragungsweg

vom Sender zum Empfänger, der unabhängig von der Anzahl und den

Eigenschaften der durchlaufenen Netzwerke ist.

Die Funktionen vom Internet Protocol sind folgende:

· Datagramm-Übermittlung (vom Sender zum Emfpänger)

· Adress-Management (mittels ARP = Adress Resolution Protocol)

· Segmentierung (Datagramm-Aufteilung, Fragmentierung)

· Routing (Pfadsuche, Weitervermittlung)

· Netzwerkkontrollfunktionen (über ICMP

)

· QoS-Gewährleistung

Das Internet-Protocol erhält von der übergeordneten

Kommunikationssoftware (z.B. TCP) ein Datagramm mit je einer Internet-

Source-Adresse (Quelladresse) und einer Internet-Destination-Adresse

(Zieladresse). Das IP-Datagramm kann bis zu 216 Bytes (inkl. Header,

Kopfteil) lang sein. Der IP-Treiber (Software im Sender) zerlegt das

Datagramm in kleinere Fragmente (falls das betroffene

Kommunikationsnetzwerk dies verlangt), wählt für jedes Datagramm oder

Fragment den momentan optimalen Kommunikationspfad für die

Übertragung und sendet das Datagramm bzw. die Fragmente ab.

Sämtliche Switches, Bridges, Router und Gateways im Netzwerk hören den

Telegrammverkehr mit und übernehmen die für sie bestimmten Pakete auf

Grund der IP-Destination-Adresse. So kann ein Datenpaket also dem

Empfänger über die IP-(Destination)-Adresse zugestellt werden.

[1, Seite 81ff]

Die IP-Adresse ist ein 32-Bit Wert, der in Form von vier durch Punkte

getrennten Dezimalzahlen (8-Bit-Werten) dargestellt wird, der sog. Dot-

Notation. Dabei unterteilt sich die IP-Adresse in die Net-ID und die Host-ID.

Die Net-ID dient zur Adressierung des Netzes und die Host-ID zur

Adressierung des Netzteilnehmers. Welcher Teil der IP-Adresse zur Net-ID

bzw. Host-ID gehören, hängt von der Größe des Netzes ab. Hierbei

unterscheidet man vorwiegend 3 Netzwerkklassen:

[4, Seite 16]

ICMP = Internet Control Message Protocol

QoS = Quality of Service (Dienstqualität)

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Class A:

Das erste Byte der IP-Adresse dient der Adressierung des Netzes, die

letzten drei Bytes adressieren den Netzteilnehmer:

Abb. 2-5

IP-Adresse mit Aufteilung nach Class A [4, Seite 16]

Class B:

Die ersten zwei Byte dienen der Netzadressierung, die letzten zwei Bytes

der Adressierung der Netzteilnehmer.

Class C:

Die ersten drei Bytes dienen der Netzadressierung, das letzte Byte der

Adressierung der Netzteilnehmer.

Daraus ergeben sich folgende Eckdaten der verschiedenen Netzklassen:

Tab. 2-4

Eigenschaften der Netzklassen A-C, Netzwerke [4, Seite 17]

Im Folgenden soll kurz der Aufbau eines IP-Datenpaketes erläutert werden.

Wie bereits aus der Erklärung des OSI-Referenzmodelles bekannt, enthält

das Datenpaket nicht nur die Nutzdaten, sondern auch Zusatzinformationen

im sog. Header (Nachrichten-Kopfteil).

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Abb. 2-6

Aufbau eines IP-Datenpaketes [4, Seite 18]

VERSion Protokollversion

HLENgth

Header-Length, Länge des Kopfteils

SERVICE TYPE

Art des Services, z.B. welche Kanäle benutzt werden

sollen

IDENTIFICATION Datagramm-Identifizierung

PROTOCOL

Typ des höheren Protocols zur Übergabe

PADDING

Bitauffüller bis zur Wortgrenze

Tab. 2-5

Erklärungen der IP-Datenpaket-Belegung (Auszug)

Außer der Übergabe von der IP-Adresse hat der IP-Treiber noch eine

weitere Aufgabe: die Zuordnung von IP-Adresse zur Ethernet-Adresse

(MAC-ID). Wie im vorangegangenen Kapitel 2.4 (Ethernet) beschrieben,

dient die MAC-ID der Zustellung des Ethernet-Pakets an das entsprechende

Gerät. Dies bedeutet, dass IP-Adresse und Ethernet-Adresse verknüpft

werden müssen. Das geschieht in der sog. ARP-Tabelle. Dabei steht ARP für

Adress Resolution Protocol, und beschreibt damit die Adressauflösung.

Der IP-Treiber schaut also in einer solchen ARP-Tabelle nach, ob die

gewünschte IP-(Destination)-Adresse in der Tabelle vorhanden ist. Ist dies

der Fall, gibt der IP-Treiber die ermittelte Ethernet-Adresse zusammen mit

seinem IP-Paket an den Ethernet-Kartentreiber weiter. Kann die

gewünschte IP-Adresse nicht gefunden werden, startet der IP-Treiber einen

ARP Broadcast Request (Rundruf). Liegt die IP-Adresse in einem anderen

Netz, wird zunächst die Ethernet-Adresse des zuständigen Routers ermittelt,

dieser hat dann wiederum die Zuordnung der Ziel-IP-Adresse und der

Ethernet-Adresse gespeichert und kann so das Datenpaket weiterleiten.

[4, Seite 26]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Abb. 2-7

ARP-Tabelle, Adressauflösung [4, Seite 26]

2.5.2 Transport Control Protocol (TCP)

Das Transport Control Protocol (TCP) setzt auf dem Internet Protocol (IP)

auf und ist im OSI-Referenzmodell (Kap. 2.1) in Schicht 4 angesiedelt. Dies

bedeutet, dass die Daten von TCP (inkl. Header) im Nutzdatenbereich des

IP-Telegramms zu finden sind. Die Hauptaufgaben von TCP sind die

Sicherung und das Handling der Nutzdaten.

Um das Handling der Daten organisieren zu können, hat TCP folgende

Funktionen bzw. Eigenschaften implementiert:

· Zuverlässige Übertragung:

Fehlerfreie, vollständige und sequenzgerechte Übermittlung der

Daten vom Sender zum Empfänger.

· Voll-Duplex-Datenstrom:

TCP überträgt gleichzeitig und unabhängig einen kontinuierlichen

Strom (sog. Stream) an Bytes zwischen den Netzwerkstationen in

beiden Richtungen.

· Verbindungsorientiertes Protokoll:

Zwischen den beiden kommunikationswilligen Netzwerkstationen

muss vor der Datenübermittlung eine Verbindung aufgebaut werden.

Ebenso muss diese Verbindung nach der Übertragung wieder

abgebaut werden. Hierfür stehen spezielle Funktionen zur Verfügung.

· Zwischenspeicherung und Aufbereitung der Datenblöcke:

Die Anwendersoftware übergibt dem TCP Daten in beliebig großen

Segmenten und in beliebigen zeitlichen Abständen. Die Segmente

werden gespeichert bis sie übermittelt werden können. Bei Bedarf

werden sie in kleinere, dem Übertragungssystem angepasste Blöcke,

zerlegt.

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

· Dynamische Ports:

Zur Bezeichnung der Schnittstelle zwischen TCP und der

Anwendersoftware werden Port-Nummern benutzt. Die Port-Nummer

kann sich dynamisch ändern und wird beim Verbindungsaufbau

definiert.

[1, Seite 91 und 5, Seite 172]

TCP stellt also für die Dauer der Datenübertragung eine Verbindung

zwischen den Netzteilnehmern her (Kommunikationskanal). Beim

Verbindungsaufbau werden Bedingungen wie z.B. die Größe der

Datenpakete festgelegt, diese gelten dann für die gesamte

Verbindungsdauer. Dem Verbindungsaufbau liegt das Server/Client-Prinzip

zugrunden, wobei der Verbindungsaufbau immer vom Client gestartet wird.

Der Server stellt verschiedene Dienste bereit und kann je nach Dienst auch

mehrere Clients gleichzeitig bedienen.

Abb. 2-8

Modell einer TCP-Verbindung [1, Seite 91]

Netzwerkstation A = Client, Netzwerkstation B = Server

TCP ist ein gesichertes ,,End-to-End-Protocol", das bedeutet die

Datenübermittlung ist vom Senden bis zur korrekten Ablieferung an den

Empfänger gesichert und überwacht. Der Sicherungsmechanismus für die

TCP-Segmente beruht auf den folgenden Grundlagen:

· Erkennung von Übertragungsfehlern

es wird eine 32-bit Prüfsumme gebildet, diese umfasst ebenfalls die

unterliegenden IP-Adressen

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

· Bestätigung von erhaltenen Segmenten

Die korrekt erhaltenen TCP-Segmente werden bestätigt (sog.

,,Acknowledgement", Quittung)

· Wiederholung im Fehler- oder Verlustfall

Bei Telegrammverlust oder auftretenden Fehlern wird das Datenpaket

nochmals gesendet (,,Repeat").

· Zeitüberwachung

Zeitüberwachung zwischen Senden und Bestätigen (sog. ,,Time Out")

mit automatischer Wiederholung bei nicht zeitgerechter Quittung.

Jedes TCP-Segment wird über den Vollduplex-Kanal quittiert. Nicht

quittierte TCP-Segemente werden vom Sender aufbewahrt, damit sie beim

Ausbleiben der Bestätigung wiederholt werden können. Man beachte, dass

die Bestätigung kein eigenes TCP-Segment sein muss, sondern im Feld

,,Acknowledge Number" eines TCP-Segments enthalten ist. Sobald die

Bestätigung eintrifft, werden die noch nicht quittierten TCP-Segmente aus

dem Sendebuffer gelöscht.

[1, Seite 92]

Abb. 2-9

Quittierung eines übermittelten TCP-Segmentes [1, Seite 93]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Das TCP-Datenpaket, auch TCP-Segment genannt, ist 32 Bit breit und

beinhaltet sämtliche Informationen die nötig sind um die

Sicherungsmechanismen auszuführen und die Daten zu verarbeiten.

Abb. 2-10

Aufbau eines TCP-Segmentes [1, Seite 92]

Die Verbindung zwischen dem Kommunikationskanal und dem

Anwendungsprogramm von den beiden Netzteilnehmern stellt TCP über sog.

Ports her. Jeder Port wird durch eine Nummer identifiziert (0..65535) und

im TCP-Header mitgeführt (Source- und Destination Port). Ports haben

damit eine große Bedeutung für die Adressierung von Diensten,

Anwendungsprogrammen, E/A-Funktionen, usw. Die Port-Nummern werden

von der Internet Assigned Numbers Authority (IANA) vergeben und

verwaltet. Die Port Nummern unter 1024 sind die sog. ,,Well-Know-Ports"

und sind für bekannte Dienste reserviert. Die Tabelle 2-8 enthält die

Erklärungen für die weiteren Datenfelder im TCP-Segment.

[1, Seite 95]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Tab. 2-6

Bedeutung der Felder im TCP-Segment [1, Seite 93]

TCP ist durch seine Eigenschaften in der Lage, Datenpakete in sequentiell

richtiger Reihenfolge beim Empfänger sicher abzuliefern. Treffen die

Datenpakete dort ein, müssen die Daten durch das Anwenderprogramm

bzw. das Anwenderprotokoll verarbeitet werden (siehe Kapitel 2.6).

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

2.5.3 User Datagram Protocol (UDP)

Das User Datagram Protocol (UDP) ist wie TCP in der Schicht 4

(Transportschicht) des OSI-Referenzmodells angesiedelt und stellt eine

einfachere Protokollvariante im Vergleich zu TCP dar. UDP baut ebenfalls auf

dem Internet Protocol (IP) auf, ist aber ein verbindungsloses Protokoll.

Die Haupteigenschaften von UDP sind:

· Verbindungsloses Protokoll:

Es ist kein Verbindungsaufbau notwendig, dadurch ist das Protokoll

schnell und einfach.

· Sicherungsmechanismen:

Es gibt keine Paket-Quittierungen, keine Kontrolle über die

Reihenfolge der Pakete und keine Flusskontrolle. Der Vorteil ist der

minimale Overhead was Schnelligkeit bedeutet, der Nachteil ist das

sämtliche Überwachungsmechanismen fehlen und diese von der

darüber liegenden Schicht übernommen werden müssen.

· Direkte Portadressierung:

Die Anwendung wird direkt über die Adressierung der Ports

angesprochen. Auch hier gibt es keine Rückbestätigung, falls es den

Port nicht gibt oder dieser nicht nutzbar ist.

Die abgesendeten Datagramme werden auf Grund der IP Destination Adress

(Zieladresse) zugestellt. Beim Empfänger angekommen können dann

Programme oder Prozesse über die Port-Nummern direkt angesprochen

werden. Dabei ist die Übertragung verbindungslos und damit unzuverlässig.

Es gibt zwar eine Prüfsumme im Header des UDP-Datagramms, aber diese

kann nur Übertragungsfehler in einem ankommenden Datagramm

ausschließen. Sollten Pakete verloren gehen, oder in einer falschen

Reihenfolge eintreffen, wird dies von UDP nicht bemerkt. Dies ist bei diesem

Protokoll die Aufgabe des höheren Protokolls bzw. des

Anwenderprogramms. Das Anwenderprogramm muss also die indirekte

Übertragungssicherung übernehmen.

Die Vorteile von UDP sind zusammenfassend die direkte Adressierbarkeit

von Programmen über die Port-Nummern, die Schnelligkeit (wenig

Overhead) und die fehlergesicherte Datenübertragung durch die

Prüfsumme. UDP wird vorwiegend dort eingesetzt, wo das unterliegende

Kommunikationssystem eine sehr hohe Fehler-Erkennungs-

Wahrscheinlichkeit hat und das Anwenderprogramm eine Fehlerbehandlung

durchführt.

[1, Seite 97]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

UDP Segment

Das UDP-Segment ist ebenfalls 32-Bit breit und besitzt einen einfachen

Aufbau:

Abb.2-11

Aufbau eines UDP-Segmentes [1, Seite 98]

Der Source-Port (Quell-Port) identifiziert das Anwendungsprogramm des

Senders. Der Destination-Port (Ziel-Port) spricht das Anwendungsprogramm

vom Empfänger an. Die Länge gibt die Gesamtlänge des UDP-Pakets inkl.

Header an, die Prüfsumme wird über das gesamte UDP-Segment gebildet,

wobei die IP-Adressen miteinbezogen werden können.

2.5.4 Zusammenhang Ethernet und TCP/IP

TCP/IP ist ein rein logisches Protokoll und benötigt immer eine physikalische

Grundlage. Wie bereits in den vorangegangenen Kapiteln erläutert wurde,

bauen die Protokolle TCP IP Ethernet (Übertragungsmedium)

aufeinander auf. Im Folgenden ist jetzt nochmals eine Gesamtübersicht

gegeben, um die Zusammenhänge der Ebenen herauszustellen.

Abb. 2-12

Einbettung von TCP/IP Datagramm in Ethernetframe [4, Seite 23]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Die Nutzdaten passieren auf ihrem Weg von der Applikation auf dem PC bis

ins Netzwerk mehrere Ebenen:

Das Anwenderprogramm entscheidet, an welchen anderen Netzteilnehmer

die Daten gesendet werden sollen und übergibt IP-Adresse und TCP-Port

dem TCP/IP-Treiber, dem sog. TCP/IP-Stack. Der TCP/IP-Stack ist ein Teil

des Betriebssystems (oder ein auf das Betriebssystem aufgesetzter

Treiber), welcher alle für die Unterstützung des TCP und IP-Protokolls

benötigten Funktionen und Treiber zur Verfügung stellt.

Der TCP/IP-Stack koordiniert dann den Aufbau der TCP-Verbindung

(Verbindungsmanagement). Die vom Anwendungsprogramm übergebenen

Nutzdaten werden vom TCP/IP-Stack je nach Größe in kleinere,

übertragbare Blöcke geteilt und in ein TCP-Paket gefasst.

Abb. 2-13

Datenübergabe vom Anwendungsprogramm zum TCP/IP-Stack

TCP-Paket mit Portnummer im Header [4, Seite 24]

Anschließend übergibt der TCP-Treiber das Paket und die IP-Adresse des

Empfängers an den IP-Treiber, welcher diese Daten wiederum in ein IP-

Paket zusammenfasst.

Abb. 2-14

TCP-Paket wird dem IP-Treiber übergeben, dieser fügt im Header

die IP-Adresse hinzu. [4, Seite 24]

Der IP-Treiber sucht in der bereits in Kap. 2.5.1 erwähnten ARP-Tabelle

(Adress Resolution Protocol) nach der zugehörigen Ethernet-Adresse des

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

durch die IP-Adresse angegebenen Empfängers und übergibt das IP-Paket

zusammen mit der ermittelten Ethernet-Adresse an den Ethernet-

Kartentreiber (Ethernet-Controller). Dieser Ethernet-Kartentreiber wiederum

verpackt das IP-Paket in ein Ethernet-Paket und gibt dieses Paket über die

Netzwerkkarte auf das Netzwerk aus.

Abb. 2-15

IP-Paket wird in Ethernet-Paket eingefasst [4, Seite 24]

Beim Empfänger auf der Gegenseite findet die Prozedur in umgekehrter

Reihenfolge statt. Die Ethernetkarte (der Ethernet-Ziel-Adresse) erkennt,

dass das Paket für den Teilnehmer bestimmt ist und gibt es an den

Ethernet-Treiber weiter. Der Ethernet-Treiber isoliert das IP-Paket und gibt

es an den IP-Treiber weiter. Der IP-Treiber wiederum isoliert das TCP-Paket

und gibt es an den TCP-Treiber weiter. Der TCP-Treiber überprüft dann den

Inhalt des TCP-Paketes auf Richtigkeit und übergibt die Daten anhand der

Portnummer an die richtige Applikation.

Diese strikte Trennung von logischem Protokoll (TCP/IP) und physikalischen

Protokoll (Ethernet) macht es möglich, netzübergreifend und

hardwareunabhängig Daten auszutauschen.

[4, Seite 23]

Bei der heutigen Verbreitung des physikalischen Mediums Ethernet wird in

den meisten Fällen das TCP/IP-Protokoll in den Schichten 3 und 4

verwendet, um die Daten zu Adressieren und eine sichere Zustellung zu

gewährleisten. Insofern ist eine Nutzung des TCP/IP-Protokolls in

Verbindung mit Ethernet weit verbreitet bzw. erprobt und bildet damit auch

die Grundlage für einen Einsatz in der Automatisierungstechnik.

2.6 Höhere

Protokolle,

Anwendungsprotokolle

Nachdem über TCP wie in Kap. 2.5.2 beschrieben die Daten dem Empfänger

richtig zugestellt wurden, erfolgt nun die Verarbeitung durch das

Anwenderprogramm- bzw. Protokoll. Dabei werden die Daten über die Ports

dem Anwenderprogramm- / Protokoll zur Verfügung gestellt.

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Ein Anwenderprogramm ist ein Programm, welches zur Lösung eines

individuellen Problems geschrieben wurde. Ein Anwendungsprotokoll

hingegen ist ein Satz von Programmen, welcher allgemein verwendbare

Funktionen über TCP/IP zur Verfügung stellt.

[1, Seite 97]

Um von einem Anwendungsprogramm bzw. Anwendungsprotokoll auf die

Kommunikationsfunktionen von TCP zuzugreifen, benötigt man ein

Programminterface. Dieses wird als ALI (Application Layer Interface) oder

auch API (Application Programmers Interface) bezeichnet. Das

Programminterface findet sich in Schicht 7 des OSI-Referenzmodells (Kap.

2.1) wieder und definiert eine Schnittstelle zwischen Anwendung und den

Kommunikationsfunktionen (TCP). Um die Kommunikationsfunktionen zu

nutzen, wird sehr häufig das ,,Socket Interface" bzw. die ,,Socket Libary"

verwendet, welche die Daten dem Programminterface zugänglich macht.

Das Socket-Interface oder die Socket-Libary stammt ursprünglich aus der

UNIX-Betriebssystemwelt, ist aber mittlerweile auf allen modernen

Rechnerplattformen implementiert. Das Socket Interface ist eine Definition

von Zugriffsfunktionen auf den TCP/IP-Kommunikationskanal. Über die

Socket-Libary kann man bei der Programmierung der eigenen Anwendung

auf diese Funktionen zugreifen, und so beispielsweise das

Verbindungsmanagement implementieren.

[1, Seite 103]

Abb. 2-16

Verbindungsaufnahme Client / Server mit Hilfe von Socket-Funtionen

[1, Seite 110]

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

Einen weiteren Auszug der Socket-Libary Funktionen sind in der Tabelle 2-9

zusammengestellt:

Tab. 2-7

Socket-Libary Funktionen (Auszug) [1, Seite 109]

Das Socket-Interface liefert die Daten dem Programminterface in einer

neutralen, transparenten und unstrukturierten Form (Folge von

Nutzdatenbytes). Die ALI bzw. API müssen dann Vereinbarungen über die

Ausnutzung des Datenstromes treffen, dies betrifft vor allem Format, Inhalt,

Bedeutung und Darstellung der Daten. Bündelt man einige dieser

Funktionen, welche diese Vereinbarungen festlegen, erhält man ein

Protokoll ein Anwendungsprotokoll.

In der Office-verbreitenden TCP/IP-Welt wurden dabei Standard-ALI/API´s

definiert, welche die gebräuchliche Funktionen wie z.B. File-Transfers oder

Remote Aufgaben in Standard-Protokollen bereitstellen. Deshalb werden

diese höheren Protkolle im Folgenden als ,Standard-Anwendungsprotokolle'

bezeichnet. [1, Seite 189]

In der Automatisierungstechnik wird schon seit einiger Zeit die Forderung

nach einer Art ,einheitlichen, industriellen Steuerungs-API/ALI' laut, die

dann auch noch von Hardware- oder Betriebssystem unabhängig sein soll.

Offensichtlich wird es nicht gelingen einen einheitlichen Standard zu

entwickeln. Daher wird es auch in Zukunft mehrere spezifische ALI/API´s

und damit verschiedene Anwendungsprotokolle in der Industrieautomation

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

geben. Diese Protokolle sollen im Folgenden als ,Anwendungsprotokolle in

der Automatisierungstechnik' bezeichnet werden.

2.6.1 Standard-Anwendungsprotokolle

Als integralen Bestandteil der TCP/IP-Welt (im Office-Bereich) sind

heutzutage normalerweise die gebräuchlichsten Standard-

Anwendungsprotokolle (auf dem PC) enthalten. Die folgende Auflistung

zeigt die Gebräuchlichsten mit Ihren Eigenschaften kurz auf:

· Telnet:

Erlaubt den Fernbetrieb eines Rechners über TCP/IP

(Terminalfunktion). Auf dem entfernten Rechner können Aufträge

ausgeführt werden, dies nennt man Remote Job Entry.

· FTP = File Transfer Protocol

Protokoll zum Austausch von Daten von verschiedenen Hosts. Eine

populäre Anwendung ist z.B. das Hochladen von Webseiten auf den

Server über FTP.

· eMail

Elektronische Post wird über die Protokolle SMTP, POP3 ausgetauscht

(SMTP und POP3, Maildienste, siehe Abkürzungsverzeichnis). Dabei

wird über Mailboxen mit Authentifizierung gearbeitet.

· Internet Management (SNMP)

SNMP bedeutet Simple Network Management Protocol und beschreibt

die Sammlung von Hilfsprogrammen, welche der Fehlersuche und der

Organisation im Internet dienen.

· HTTP, Grundlagenprotokoll des Internets

HTTP (Hyper Text Transfer Protocol) regelt die Anforderung und

Übertragung von Webinhalten zwischen HTTP-Server und Browser

[1, Seite 97]

Die Protokolle in der Auflistung sind populär und auf den meisten Rechnern

mit modernen Betriebssystemen implementiert. Im Gegensatz zu diesem

Standard der vor allem aus der IT / Office Welt kommt, gibt es in der

Automatisierungstechnik zahlreiche individuelle API/ALI´s und deren

Anwendungsprotokolle. Diese sollen im nächsten Abschnitt erläutert

werden.

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

2.6.2 Anwendungsprotokolle in der Automatisierungstechnik

Wie bereits in den vorangegangenen Kapiteln erläutert, stellt Ethernet-

TCP/UDP/IP als Kommunikationssystem die zuverlässige Übertragung von

Daten zur Verfügung. Dabei verhält es sich bezüglich Format, Inhalt,

Bedeutung und Darstellung des Nutzdatenstromes transparent. Die

Teilnehmer eines Netzwerkes sind also gezwungen, Vereinbarungen über

die Ausnutzung des Datenstromes und über die bereitgestellten Funktionen

zu treffen. Speziell in der Automatisierungstechnik hat man deshalb

verschiedene Ansätze für das Anwendungsprotokoll getroffen.

[1, Seite 189]

Um in einem industriellen Ethernet-TCP/IP Umfeld diese Vereinbarungen

offen

und austauschbar realisieren zu können, beschäftigten sich zur Zeit

einige Gremien, Nutzerorganisationen und Hersteller mit der Definition einer

,,industriellen Steuerungs-ALI/API". Diese industrielle Steuerungs-ALI/API

soll dann Funktionen bereitstellen, die Hardware- und Betriebssystem-

Unabhängig ist. Leider zeichnet sich jedoch der Trend ab, dass nur schwer

eine einheitliche Lösung gefunden werden kann. Die IAONA (Industrial

Automation Open Networking Alliance) hat es sich zum Ziel gemacht, ,,...die

internationale Verbreitung von offenen Netzwerkstandards der

Informationstechnik wie Ethernet in der Automatisierungstechnik zum

Nutzen der Allgemeinheit und der Anwender zu unterstützen".(Zitat aus der

Satzung der IAONA, [17] und [URL2])

Da es also in absehbarer Zeit nicht nur ein einziges, universal gültiges

Anwendungsprotokoll geben wird, mit dem man alle Anforderungen erfüllen

kann, wird es wohl bei einer Protokollvielfalt auch in diesem Bereich bleiben.

Der regelrechte ,,Protokollkampf, Standardisierungskrieg" ist ja schon aus

dem Feldbusbereich bekannt, wo einige Feldbusse um die Anerkennung als

den ,,ultimativen Feldbus" kämpf(t)en. So ist zusammenfassend über ein

Beispiel ausgedrückt nicht möglich, eine SPS von Siemens mit einer SPS

von Rockwell über Ethernet kommunizieren zu lassen. Werden verschiedene

Anwendungsprotokolle eingesetzt, kann ein Datenaustausch immer nur über

Umwege bzw. Protokollwandlungen stattfinden.

Im Folgenden erfolgt nun eine auszugsweise Auflistung von höheren

Protokollen, die in der Automatisierungstechnik Anwendung finden.

· TCP/IP Instrument Protocol

Definiert die Mechanismen zum Datenaustausch zwischen Client und

Server. Die 17 Funktionen des Protokolls werden in 3 verschiedenen

Kanälen bereitgestellt (Kommunikationskanal, Kanal für den Abbruch

Unter einem offenen Standard versteht man eine vollständige, eindeutige, stabile, umfassend

dokumentierte, uneingeschränkt erhältliche und nutzbare Spezifikation eines Teilsystems.

Derartige Standards werden von Firmen, Nutzerorganisationen oder Standardisierungsgremien

geschaffen.

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

von Funktionen, Meldungskanal). Die Spezifikation ist unter ,,TCP/IP-

IEEE 488.1 und 488.2" zu finden.

· Interface for Distributed Automation (IDA)

Das von einer Gruppe von Unternehmen entwickelte Protokoll hat

eine hierarchielose Kommunikation zum Ziel. Dabei können die

Teilnehmer gleichberechtigt kommunizieren. Echtzeitdatenverkehr ist

grundsätzlich über dieses Protokoll möglich. Außerdem umfasst es

auch ein Safety Protocol (Sicherheits-Protokoll). [URL3]

· ProfiNet

Wie der Name bereits anmuten lässt, ist ProfiNet die Portierung des

klassischen Feldbusses ,Profibus' auf die Ethernet und TCP/IP-Welt.

Um die Kompatibilität zu bereits bestehenden Profibus-Geräten zu

haben, wurde eine Migrationsstrategie entwickelt. Das Protokoll nutzt

COM / DCOM / OLE und ist somit Windows-basierend.

· Ethernet/IP

Ethernet/IP (Kap. 2.7) ist die Umsetzung des CIP (Control and

Information Protocol) für Ethernet. Das CIP beruht auf der

Darstellung von Automatisierungskomponenten als Objekte und hat

ein detailliert definiertes Objektmodell. Das Protokoll ist grundsätzlich

Echtzeitfähig.

Foundation Fieldbus

Unter dem Zusammenschluss von amerikanischen Firmen entstand

der Feldbus H1 und HSE. Diese Feldbusse sind in Segmenten definiert

und unterteilt und lehnen sich somit an die ,Switched Ethernet

Technologie' an. Im Prinzip wird zwischen dem Aktor/Sensor-nahen

Bus H1 und dem HSE (Bus zwischen Steuerungen) eine Buskopplung

durchgeführt.

· Modbus TCP

Die Erweiterung des seriellen Protokolls Modbus RTU / ASCII führte

zu Modbus TCP welches die Portierung auf Ethernet darstellt. Das

Protokoll ist in einfacher Form in ein TCP/IP/Ethernet-Frame

eingebunden (in Kapitel 2.8.2 beschrieben) und unterstützt die

Server/Client Technologie.

[1, Seite 192ff]

Als in den letzten Jahren klar wurde, dass sich keine der

Kommunikationsarchitekturen wie IDA, ProfiNet, Ethernet/IP, usw.

dominant durchsetzen wird, kam das dringende Bedürfnis nach einem

standardisierten Datenaustausch zwischen diesen Ethernet-basierenden,

koexistierenden aber inkompatiblen Systemen auf. So wurde die Forderung

nach einem Standard eine Ebene höher geschoben, da es auf Feldbus-

sowie Ethernetebene nicht erfolgreich war einen gemeinsamen Standard zu

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

finden. Hierzu wurde eine Foundation gegründet, die mit OPC ein Konzept

vorlegt, welches einen gemeinsamen Standard realisieren soll (siehe Kap.

2.9, OPC). [1, Seite 217]

Zusammenfassend kann festgehalten werden, dass es den einen,

dominanten Standard für ein Anwendungsprotokoll in der

Automatisierungstechnik nicht gibt. So liegt es beim Anwender, das

Protokoll für die jeweilige Applikation bzw. das Gerät auszusuchen. Hierbei

spielen sicherlich Faktoren wie Echtzeitfähigkeit, Netzwerkstruktur, Modell

und Aufbau des Protokolls u.v.m. eine tragende Rolle.

In den folgenden drei Kapiteln sollen nun Ethernet/IP und Modbus TCP

sowie OPC näher erläutert werden.

2.7 Ethernet/IP

Anfang 1998 hat ein Arbeitskreis von ControlNet International ein Verfahren

definiert, wie man das im Rahmen von ControlNet und DeviceNet bereits

veröffentlichten Applikationsprotokoll CIP (CIP = Control and Information

Protocol) auf Ethernet aufsetzten kann. Daraus ist im März 2000 ein offener

Industriestandart geworden, welcher nun das bekannte Ethernet aus der

,Office-Welt' um ein Industrieprotokoll für die Automatisierung erweitert.

Für die maßgebliche Weiterentwicklung dieses Standards ist vor allem die

ControlNet International (CI), die Open DeviceNet Vendor Association

(ODVA) und die Industrial Ethernet Association (IEA) verantwortlich.

Der Begriff Ethernet/IP beschreibt die Kombination: Ethernet

Industrieprotokoll CIP und bildet somit das ,,Ethernet Industrial Protocol

(Ethernet/IP) ".

Control Information Protocol (CIP)

Das CIP baut auf ein netwerkunabhängiges, objektorientiertes Modell auf,

welches die Eigenschaften von Steuerungskomponenten beschreibt. Dies

können Geräteklassen, Instanzen, Attribute, Datentypen, Profile, Services,

u.v.m. sein. Daraus ergeben sich Geräteprofile, die eine spezifische

Kombination von Objekten enthalten.

Darüber hinaus stellt CIP sog. implizite und explizite Nachrichten zur

Verfügung, mit deren Hilfe es möglich ist einen echtzeitfähigen

beziehungsweise informationsbasierten Nachrichtenaustausch zu realisieren.

Die implizite Nachricht ist für den regulären, zyklischen Datenaustausch

da Modbus TCP in seiner Struktur stark von dem seriellen Modbus (Modbus RTU / ASCII)

abhängig ist, werden in dem Kapitel 2.8 (Modbus) beide Variationen erläutert.

2. Theoretische Grundlagen

Diplomarbeit Ralf Emberger, Entwicklung eines TCP/IP Interfaces über Modbus

gedacht, die Nachrichten sind dabei sehr kompakt, haben wenig Overhead

und sind auf dem UDP-Protokoll aufgebaut (typischerweise: E/A-Daten).

Das Ereignis welches diese Art von Nachrichten auslöst ist entweder

Ereignis- oder Zeitgesteuert, Pollend, oder Applikationsabhängig.

Hingegen wird bei dem Versand von individuellen Nachrichten der explizite

Nachrichtentyp verwendet. Diese Nachrichten werden bei Steuerbefehlen

wie: ,,Get Attribute", ,,Start/Stopp" oder ,,Reset" eingesetzt. Dabei werden

diese Nachrichten meist verbindungsorientiert zugestellt, daher nutzt man

hier das TCP-Protokoll als Grundlage.

[14]

Abb. 2-17

Ethernet/IP Protokollstack (Aufbau) [1, Seite 205]

Weitere Ethernet/IP Eigenschaften

Ethernet/IP lässt also die unteren 4 Schichten des OSI-Referenzmodelles

unberührt und baut erst in den oberen Schichten mit CIP auf. Dafür

verwendet Ethernet/IP einen eigenen Protokoll-Stack. Dieser setzt das CIP

um und unterstützt darüber hinaus das Producer / Consumer Modell.

Damit ist eine hohe Übertragungseffizienz zu erreichen. Dies wird durch die

Unterstützung von 10 und 100 MBit Netzwerkstrukturen (Vollduplex-

Betrieb) noch ausgebaut.

Daher ist es naheliegend als Topologie die Sternstruktur zu wählen. Über

den Einsatz von Ethernet-Switches ist es so möglich, die Übertragungsraten

von 10 bzw. 100 MBit kombiniert zu unterstützen. Da ein Switch die

Eigenschaft hat mögliche Kollisionen zu reduzieren, kann über eine spezielle

Ausführung Echtzeit-Fähigkeit erreicht werden. In diesem Zusammenhang

spricht man dann von ,Switched Ethernet'. Dabei werden mit speziellen

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2003
ISBN (eBook): 9783832472184
ISBN (Paperback): 9783838672182
DOI: 10.3239/9783832472184
Dateigröße: 21.3 MB
Sprache: Deutsch
Institution / Hochschule: Fachhochschule Esslingen Hochschule für Technik Esslingen – Mechatronik und Elektrotechnik
Erscheinungsdatum: 2003 (September)
Note: 1,0
Schlagworte: ethernet anwendungsprotokoll feldbus tcp/ip

Autor

Ralf Emberger (Autor:in)

Entwicklung eines TCP/IP-Interfaces für einen Kommunikationsprozessor über MODBUS

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Ralf Emberger (Autor:in)