Softwareentwicklung für die Feldbussysteme - INTERBUS, PROFIBUS, CAN und ETHERNET

Aschauer, Christian

Softwareentwicklung für die Feldbussysteme - INTERBUS, PROFIBUS, CAN und ETHERNET

Am PC unter MS-Windows mit proprietären Softwarebibliotheken und dem Industriestandard OLE for Process Control (OPC) unter Verwendung der Programmiersprachen Visual Basic und Visual C++

von Christian Aschauer (Autor:in)

Informatik - Software

Zusammenfassung

Inhaltsangabe:Einleitung:
Um PC-basierende Prüfsysteme in bestehende Produktionsanlagen zu integrieren ist eine Einbindung in bestehende Feldbussysteme erforderlich. Für diese PC-basierenden Systeme ist es notwendig Software zu entwickeln welche dies ermöglicht. Die vorliegende Diplomarbeit beschreibt in Theorie und Praxis wie Software für Feldbussysteme am PC unter MSWindows mit den Programmiersprachen Visual Basic und Visual C++ entwickelt werden kann. Diese Arbeit bietet Softwareentwicklern theoretisches und praktisches Wissen, welches zur Softwareentwicklung für diese Technologien notwendig ist.
Kapitel 1 gibt einen allgemein gehaltenen Überblick über den Bereich Bussysteme. Warum diese Technologien immer mehr zum Einsatz kommen und welche Rolle sie in Unternehmen spielen. Weiters werden Kosten, Nachteile und Vorteile behandelt.
Kapitel 2 befasst sich mit dem Thema Softwareentwicklung im industriellen Umfeld. Techniken wie Multithreading und die Verwendung von Zeitgebern werden erklärt und verglichen.
Kapitel 3 erläutert die Grundlagen des INTERBUS. Weiters wird die Theorie erläutert welche erforderlich ist, um Software für die Realisierung einer PC-Interbus-PC Verbindung mit einer PC-Karte der Firma Phoenix Contact zu entwickeln. Im dritten Teil des Kapitels Interbus wird die Entwicklung von Software in C++ anhand von Programmcode beschrieben.
Kapitel 4 fasst im ersten Teil die Grundlagen des PROFIBUS zusammen. Weiters wird die Theorie erklärt welche notwendig ist um Software für die Realisierung einer PCPROFIBUS- SPS Anbindung mit einer PC-Karte und einer speicherprogrammierbaren Steuerung der Firma Siemens zu entwickeln. Im dritten Teil des Kapitels Profibus wird die Entwicklung der Software für Visual Basic und C++ anhand von Programmcode gezeigt.
Kapitel 5 verschafft einen Einblick in die Grundlagen des Controller Area Networks (CAN). Weiters wird die Theorie beschrieben welche notwendig ist um Software für die Realisierung einer PC-CAN-SPS Verbindung mit dem Parallelport Interface BU104 der Firma Sigmatek zu entwickeln. Im dritten Teil des Kapitels CAN wird die Entwicklung der Software mitVisual Basic und Visual C++ anhand von Programmcode gezeigt.
Kapitel 6 verschafft Einblicke in die Grundlagen von ETHERNET. Weiters wird die Theorie behandelt welche notwendig ist um Software für die Realisierung einer PCEthernet- PC Verbindung mit Standard Ethernetkarten zu realisieren. Im dritten Teil des Kapitels Ethernet wird detailliert die […]

Leseprobe

Inhaltsverzeichnis

ID 8668

Aschauer, Christian: Softwareentwicklung für die Feldbussysteme - INTERBUS,

PROFIBUS, CAN und ETHERNET - am PC unter MS-Windows mit proprietären

Softwarebibliotheken und dem Industriestandard OLE for Process Control (OPC) - Unter

Verwendung der Programmiersprachen Visual Basic und Visual C++

Hamburg: Diplomica GmbH, 2005

Zugl.: Fachhochschul-Studiengänge der Wiener Wirtschaft GmbH, Diplomarbeit, 2004

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 2005

Printed in Germany

ABSTRACT

The basis of this thesis is the development of software to integrate personal computer based

test equipment into existing production lines.

This thesis describes the different possibilities to establish communication between a

Microsoft Windows driven personal computer and other field devices like programmable

logic controllers. Software development for the communication over INTERBUS,

PROFIBUS, CAN and ETHERNET with Visual C++ and Visual Basic is described in

detail.

Chapter 1 portrays the basics of field-bus-systems, where and why such systems make

sense. The basics and problems of the vertical integration are also explained in this chapter.

Chapter 2 is about the fundamentals of software development for personal computers. It

deals with the problems of timing in software using threads, polling and timer mechanisms.

The development of software to get access to above mentioned field bus systems using

proprietary software libraries is explained in chapter 3, 4, 5 and 6. The most important

things are explained with pieces of software code.

Chapter 7 works on the international standard for process automation also called OPC. The

development of OPC-clients with Visual C++ and Visual Basic is described in detail.

A summary and recommendations for selecting the rigth technique to gain access to the

desired information are given in chapter 8.

KURZFASSUNG

Um PC-basierende Prüfsysteme in bestehende Produktionsanlagen zu integrieren ist eine

Einbindung in bestehende Feldbussysteme erforderlich. Für diese PC-basierenden Systeme

ist es notwendig Software zu entwickeln welche dies ermöglicht. Die vorliegende Diplom-

arbeit beschreibt in Theorie und Praxis wie Software für Feldbussysteme am PC unter MS-

Windows mit den Programmiersprachen Visual Basic und Visual C++ entwickelt werden

kann. Diese Arbeit bietet Softwareentwicklern theoretisches und praktisches Wissen,

welches zur Softwareentwicklung für diese Technologien notwendig ist.

Kapitel 1 gibt einen allgemein gehaltenen Überblick über den Bereich Bussysteme. Warum

diese Technologien immer mehr zum Einsatz kommen und welche Rolle sie in

Unternehmen spielen. Weiters werden Kosten, Nachteile und Vorteile behandelt.

Kapitel 2 befasst sich mit dem Thema Softwareentwicklung im industriellen Umfeld.

Techniken wie Multithreading und die Verwendung von Zeitgebern werden erklärt und

verglichen.

Kapitel 3 erläutert die Grundlagen des INTERBUS. Weiters wird die Theorie erläutert

welche erforderlich ist, um Software für die Realisierung einer PC-Interbus-PC

Verbindung mit einer PC-Karte der Firma Phoenix Contact zu entwickeln. Im dritten Teil

des Kapitels Interbus wird die Entwicklung von Software in C++ anhand von

Programmcode beschrieben.

Kapitel 4 fasst im ersten Teil die Grundlagen des PROFIBUS zusammen. Weiters wird die

Theorie erklärt welche notwendig ist um Software für die Realisierung einer PC-

PROFIBUS-SPS Anbindung mit einer PC-Karte und einer speicherprogrammierbaren

Steuerung der Firma Siemens zu entwickeln. Im dritten Teil des Kapitels Profibus wird die

Entwicklung der Software für Visual Basic und C++ anhand von Programmcode gezeigt.

Kapitel 5 verschafft einen Einblick in die Grundlagen des Controller Area Networks

(CAN). Weiters wird die Theorie beschrieben welche notwendig ist um Software für die

Realisierung einer PC-CAN-SPS Verbindung mit dem Parallelport Interface BU104 der

Firma Sigmatek zu entwickeln. Im dritten Teil des Kapitels CAN wird die Entwicklung der

Software mitVisual Basic und Visual C++ anhand von Programmcode gezeigt.

Kapitel 6 verschafft Einblicke in die Grundlagen von ETHERNET. Weiters wird die

Theorie behandelt welche notwendig ist um Software für die Realisierung einer PC-

Ethernet-PC Verbindung mit Standard Ethernetkarten zu realisieren. Im dritten Teil des

Kapitels Ethernet wird detailliert die Entwicklung von Software für VB und C++ anhand

von Programmcode gezeigt.

Kapitel 7 umfasst im ersten Teil die Grundlagen von OPC und dem Component Object

Modell (COM) und zeigt, welche Vorteile OPC bringt. Die Theorie, welche für die

Realisierung von OPC-Clients notwendig ist, wird erläutert. Auch die Entwicklung von

Client-Software in VB und C++ wird anhand von Programmcode gezeigt. Den Abschluss

dieses Kapitels bildet eine Schritt für Schritt Anleitung um Daten aus der Feldebene von

einer SPS über den OPC-Server der Firma Sigmatek mit einem Visual Basic-Client zu

visualisieren.

Kapitel 8 fasst die Realisierungen zusammen, analysiert die Ergebnisse, Vorteile,

Nachteile, Erfahrungen und ungelöste Probleme.

Inhaltsverzeichnis

ABSTRACT... 3

KURZFASSUNG...4

1 BUSSYSTEME... 9

1.1 WAS SIND BUSSYSTEME ?... 9

1.2 WARUM WERDEN BUSSYSTEME VERWENDET ?...9

1.2.1 Von der seriellen zur parallelen Verdrahtung... 9

1.2.2 Kostenersparnis durch Feldbussysteme ?...11

1.2.3 Anforderungen an Feldbussysteme... 12

1.2.4 Die vertikale Integration... 13

1.3 AUFBAU VON FELDBUSSYSTEMEN... 16

1.3.1 Busstrukturen... 16

1.3.1.1 Linien- oder Busstruktur... 16

1.3.1.2 Baumstruktur...16

1.3.1.3 Ringstruktur...17

1.3.1.4 Kombinationen von Baum- und Ringstruktur...17

1.3.2 Modelle... 18

1.3.2.1 Producer-Consumer / Client-Server... 18

1.3.2.2 Nachrichtenorientiert vs. E/A-orientiert ...20

1.3.3 Physikalische Medien... 22

1.3.4 Buszugriffsverfahren...22

1.3.4.1 Master-Slave Verfahren... 22

1.3.4.2 Token-Passing Verfahren... 23

1.3.4.3 Summenrahmen-Verfahren... 24

1.3.4.4 CSMA/CD-Verfahren... 26

1.3.4.5 CSMA/CA-Verfahren... 26

1.3.5 Datensicherung...26

1.3.5.1 Paritybit... 27

1.3.5.2 Prüfsumme... 28

1.3.5.3 CRC-Cyclic Redundancy Check...28

2 SOFTWAREENTWICKLUNG AM PC ...29

2.1 DIE ROLLE DES WINDOWS PC´s IN DER FELDEBENE... 29

2.2 DIE VERSCHIEDENEN AUFGABEN DER SOFTWARE... 29

2.2.1 Polling... 31

2.2.2 Multithreading...32

2.2.3 Timer...33

3 INTERBUS...36

3.1 THEORIE... 36

3.1.1 Buszugriffsverfahren...36

3.1.2 Topologie... 36

3.1.3 Das INTERBUS Übertragungsprotokoll...37

3.1.4 Prozessdaten / Parameterdaten...37

3.1.5 INTERBUS und das ISO/OSI -Modell... 39

3.1.6 Systemdaten... 39

3.2 PRAXIS... 40

3.2.1 Die Software... 40

3.2.2 Die Hardware... 40

3.2.2.1 Der Aufbau zu Softwareentwicklung... 40

3.2.2.2 Die INTERBUS Systemkoppleranschaltbaugruppe ...41

3.2.2.3 Die CMD-Software von Phoenix Contact...43

-6-

3.2.3 Projektierung...43

3.2.4 Die realisierte Software...44

3.2.4.1 Zugriff mit C++ über das Device Driver Interface ...44

4 PROFIBUS DP...55

4.1 THEORIE... 55

4.1.1 Datenübertragungsverfahren & Topologie...55

4.1.2 Leistungsdaten... 56

4.1.3 GSD-Datei...57

4.2 PRAXIS... 57

4.2.1 Die Software... 57

4.2.1.1 Funktionsübersicht der Firmware...57

4.2.2 Die Hardware... 58

4.2.2.1 Die PROFIBUS PC-Einsteckkarte CP5611 für den PC ...58

4.2.2.2 Die Simatic S7-314 DP... 58

4.2.2.3 Der Aufbau zur Softwareentwicklung...59

4.2.3 Die realisierte Software ...59

4.2.3.1 Zugriff mit C++...59

5 CAN-CONTROLLER AREA NETWORK... 64

5.1 THEORIE... 64

5.1.1 Datenübertragungsverfahren & Topologie...64

5.1.2 Leistungsdaten... 64

5.1.3 Datenorganisation in der SPS... 64

5.2 PRAXIS... 65

5.2.1 Der Aufbau zur Softwareentwicklung... 65

5.2.2 Die Software... 65

5.2.2.1 Die Funktionen der Firmware... 65

5.2.2.2 C++ Beispielapplikation...68

5.2.2.3 Visual Basic Beispielapplikation... 70

5.2.2.4 Das Programm in der SPS DCC080 ...71

6 ETHERNET... 72

6.1 THEORIE... 72

6.1.1 Datenübertragungsverfahren & Topologie...72

6.1.2 Echtzeitverhalten...74

6.1.3 Windows Sockets...76

6.1.3.1 Das Winsock 2 Control... 76

6.2 PRAXIS... 77

6.2.1 Der Aufbau zur Softwareentwicklung... 77

6.2.2 Die realisierte Software ...78

6.2.3 Ein Client-Server Anwendung in VBasic mit dem Winsock2 Control... 78

6.2.3.1 Der Ethernet UDP-Server...78

6.2.3.2 Der Ethernet UDP-Client... 80

7 OPC-OLE FOR PROCESS CONTROL... 83

7.1 WAS IST OPC?...83

7.2 WIE & WO HILFT OLE FOR PROCESS CONTROL?... 83

7.3 THEORIE... 87

7.3.1 COM - Component Object Modell... 87

7.3.3 Der OPC-Server... 91

7.3.4 Die Schnittstellen des OPC-Servers...93

7.3.5 OPC-DA...93

7.4 PRAXIS... 94

7.4.1 Cliententwicklung mit C++...94

-7-

7.4.2 Cliententwicklung mit Visual Basic... 100

7.4.2.1 Schritt 1 - Programmierung der SPS... 103

7.4.2.2 Schritt 2 - Generieren der Konfigurationsdatei für den OPC-Server... 103

7.4.2.3 Schritt 3 - Programmierung des OPC-Clients ... 104

8 ZUSAMMENFASSUNG...115

8.1 ALLGEMEINES...115

8.2 EMPFEHLUNGEN FÜR SOFTWAREENTWICKLER... 115

8.3 ÜBERSICHT DER ENTWICKELTEN APPLIKATIONEN...117

8.4 ETHERNET - DER FELDBUS DER ZUKUNFT ?... 117

Literatur und Datenblätter im Internet...118

Literaturverzeichnis...119

Abbildungsverzeichnis... 120

Tabellenverzeichnis...121

-8-

1 BUSSYSTEME

1.1 WAS SIND BUSSYSTEME ?

Definition:

Ein Feldbus lässt sich wie folgt beschreiben, adaptiert von [1]

Ein Feldbus ist ein Netzwerk zur seriellen und digitalen Datenübertragung. Es gibt keine

direkte Verkabelung sondern alle Aktoren und Sensoren sind über ein Bussystem

miteinander verbunden. Feldbussysteme ersetzen die analogen und parallelen

Verkabelungen durch eine seriell arbeitende Busleitung.

1.2 WARUM WERDEN BUSSYSTEME VERWENDET ?

Folgende Kapitel beantworten die Frage warum Bussysteme zur Anwendung kommen,

welche Kostenersparnisse sich ergeben und welche Anforderungen an Feldbussysteme

gestellt werden. Auch auf die Problematik der vertikalen Integration wird eingegangen.

1.2.1 Von der seriellen zur parallelen Verdrahtung

Als in den sechziger Jahren erstmals Digitalrechner zur Führung von technischen

Prozessen zum Einsatz kamen, wurden zunächst streng zentrale Strukturen verwendet. Ein

einzelner Prozessrechner wurde mit einem Prozess verbunden. Über digitale Ein/Ausgänge

wurden binäre Sensoren wie Schalter und Relais mit dem Prozessrechner verbunden.

Über analoge Eingänge war es möglich Sensoren mit analogem Ausgangssignal

(z.B.:Temperatursensor) einzulesen und zu verarbeiten. Mit Hilfe analoger Ausgänge

konnten Aktoren angesteuert werden (Bsp.: Drehzahl eines Motors). Wie aus Abbildung 1

ersichtlich, ist der Verdrahtungsaufwand direkt proportional zur Anzahl der Sensoren und

Aktoren. Die Übertragung von analogen Signalen über lange Leitungen in

elektromagnetisch belasteter Umgebung stellt ein Problem dar. Es kann zur Induktion von

Strömen kommen welche das Messsignal überlagern und verfälschen.

In modernen Prozessleitsystemen werden die einzelnen Aufgaben der Prozessführung auf

hardwaremäßig getrennte Geräte aufgeteilt. Die Kommunikation zwischen diesen Geräten

erfolgt über ein seriell arbeitendes Bussystem. Diese Struktur ist in Abbildung 2

dargestellt.

-9-

-10-

Abbildung 2: serielle Verdrahtung mit dezentralen Einheiten adaptiert von [1]

Anzeige und

Bedienkomponente

PC / SPS

Regler

Sensor

Engineeringsystem

Datenbank

Aktor

Sensor

PC / SPS

Gateway

offener Bus

z.B.:

Ethernet

Aktor/Sensor

Bus

SPS

Aktor

Feldbus

geschlossener

Bus

Aktor / Sensor

Bus

Abbildung 1: parallele Verdrahtung mit Prozessrechner adaptiert von [1]

Prozessrechner

mit

digitalen und

analogen Ein- und

Ausgängen

Sensor 1

z.B.:

Endschalter

Sensor 2

z.B.:

Temperaturfühler

Sensor n

Aktor 1

z.B.: Relais

Aktor 2

z.B.:Antrieb

Aktor n

1.2.2 Kostenersparnis durch Feldbussysteme ?

Einerseits wird der Verkabelungsaufwand reduziert andererseits müssen die Aktoren und

Sensoren mit einem Interface zum Anschluss an den Feldbus ausgestattet werden. Die Ein-

sparungen durch den geringeren Materialaufwand gleichen sich durch teurere Aktoren und

Sensoren wieder aus.

Einsparungen ergeben sich jedoch auf jedem Fall durch die geringeren Installationskosten

die einfachere und schnellere Verdrahtung. ,,Ein serielles Buskabel lässt sich schneller

durch eine Maschinenhalle schleifen als riesige Kabelbäume."

Zusammengefasst ergeben sich folgende Einsparungspotenziale [1]:

Senkung der Planungskosten da aufwendige Rangierverteiler entfallen.

Verkürzung der Inbetriebnahme Hilfe von Bussystemen. Fehler können

leichter lokalisiert werden. Verdrahtungsfehler sind in dicken

Leitungsbündeln der Parallelverdrahtung nur schwer zu finden.

Änderungen oder Erweiterungen sind aufgrund des modularen Aufbaus

schneller, einfacher und kostengünstiger zu realisieren.

Als Grundlage für die vertikale Integration wie in [17] beschrieben, sind auch

Betrachtungen des Investitionsschutzes nicht zu vernachlässigen.

Dabei sollte berücksichtigt werden:

die Technologie auf welcher das Kommunikationssystem basiert - nicht

unwesentlich ist ob die Technologie bereits im Betrieb verwendet wird

der Verbreitungsgrad der Produkte je weiter verbreitet und häufiger ver-

wendet eine Technologie ist desto ausgereifter ist diese

die zukünftige Weiterentwicklung der Produkte

die Offenheit von Protokoll- und Dienstspezifikationen proprietäre

Produkte und Dienste gewährleisten nicht die notwendige Transparenz und

führen in Abhängigkeiten von Herstellern oder Interessengruppen

-11-

1.2.3 Anforderungen an Feldbussysteme

Folgende Forderungen werden an Feldbussysteme gestellt:

Vereinfachung der Installation

Echtzeitfähigkeit

Vielfalt an zur Verfügung stehender Geräte

Robustheit

hohe Übertragungsgeschwindigkeit

leichte Inbetriebnahme

einfache Diagnose und Fehlerbehandlung

Offenheit und Standardisierung

Je nach Anwendungsfall ergeben sich Kombinationen aus oben genannten Forderungen.

-12-

1.2.4 Die vertikale Integration

Weitere wichtige Argumente für eine Vernetzung und Standardisierung sind durch die

immer notwendiger werdende vertikale Integration gegeben. War es vor einiger Zeit noch

üblich den kaufmännischen Bereich und den technischen Produktionsbereich getrennt zu

organisieren, erfordert der immer stärker werdende Kostendruck eine Verbindung dieser

Bereiche. Der Optimierung der einzelnen Bereiche folgt die Optimierung des gesamten

Systems [1].

Abbildung 3 zeigt die unterschiedlichen Ebenen welche für die vertikale Integration von

Bedeutung sind und folgend genauer beschrieben werden.

Feldebene/Automatisierungsebene/Prozessleitebene:

Die Feldebene umfasst Sensoren, Aktoren und Feldbusse. In der Automatisierungsebene

finden sich prozessnahe Komponenten wie z.B.: eine SPS. Zur Visualisierung und

Bedienung kommen in der Automatisierungsebene und auch der Prozessleitebene oft PC-

-13-

Abbildung 3: Darstellung der vertikalen Integration adaptiert von [1]

Unternehmensleitebene (ERP)

Prozessleitebene

Produktionsleitbene (MES)

Automatisierungsebene

Feldebene (Aktoren/Sensoren)

basierende Systeme zum Einsatz.

Unternehmensleitebene (ERP-Enterprise Resource Planning)nach [1]

Dieser betriebswirtschaftlich orientierte Teil des Unternehmens organisiert und bearbeitet

Tätigkeiten wie:

Auftragseingang

Vorratswirtschaft

Materialbeschaffung

Terminplanung

Lieferung

Rechnungserstellung usw.

Produktionsleitebene (MES-Manufactoring Execution System):

Die Produktionsleitebene stellt die Verbindung zwischen Prozessleitebene und Unter-

nehmensleitebene her. Nach [1] sind die Aufgaben eines MES:

Verteilung der Produktionsmittel

Betriebs- und Maschinendatenerfassung

Prozessmanagement, Dokumentenverwaltung, Wartungsmanagement

Leistungsanalyse

Ressourcenverwaltung und Ressourcenstatus

Qualitätsmanagement

Produktmanagement

Feinplanung der Arbeitsabläufe

Um die vertikale Integration zu verwirklichen, ist es notwendig dass diese drei Ebenen mit-

einander Daten und Informationen austauschen. Bei der Terminisierung eines neuen

Auftrages im ERP-Bereich sind dazu Informationen über den Anlagenstatus notwendig.

Erst mit Informationen wie Auslastung und Betriebsbereitschaft ist es dem ERP-Bereich

möglich, sinnvolle und effiziente Terminplanungen zu realisieren. Nach der Planung durch

die Unternehmensleitebene müssen die Informationen auch in die Prozessleitebene

gelangen um die Planung umzusetzen. Eine effiziente Realisierung der Philosophie der

vertikalen Integration erfordert eine Vernetzung aller Ebenen über Bussysteme. Eine

deutliche Reduzierung der Vorbereitungszeit und Durchlaufzeit um bis zu 35% bei der

Produktion ist wie in [13] beschrieben möglich.

-14-

In Summe bedeutet dies die Notwendigkeit eines durchgehenden Informationsflusses vom

ERP-System bis in die Feldebene. Aufgrund dessen ist eine durchgängige Vernetzung und

Standardisierung notwendig.

Prinzipiell sind die Kosten für die Umsetzung der vertikalen Integration stark projekt-

spezifisch und unter anderem von folgenden Faktoren abhängig.

Notwendige Infrastrukturmaßnahmen

Lizenzgebühren für verfügbare Softwarelösungen

Aufwand für individuelle Softwareanpassungen

Inbetriebnahme und Konfigurationsaufwand

Weiterverwendungsmöglichkeiten vorhandener Systeme

-15-

1.3 AUFBAU VON FELDBUSSYSTEMEN

1.3.1 Busstrukturen

Je nachdem wie die einzelnen Teilnehmer verbunden werden ergeben sich unterschiedliche

Strukturen. Diese werden in folgendem Abschnitt beschrieben.

1.3.1.1 Linien- oder Busstruktur

Ein Beispiel für in Abbildung 4 realisierte Busstruktur ist das Controller Area Network.

1.3.1.2 Baumstruktur

Eine weitere Möglichkeit Busteilnehmer zu verbinden zeigt Abbildung 5 in Form einer

Baumstruktur.

-16-

Abbildung 4: Linien- oder Busstruktur adaptiert von [1]

SPS/PC

Aktor

Sensor

Aktor

Abbildung 5: Baumstruktur adaptiert von [1]

SPS/PC

Sensor

Aktor

Sensor

Aktor

SPS/PC

Aktor

Sensor

1.3.1.3 Ringstruktur

Die in Abbildung 6 dargestellte Ringstruktur wird bei INTERBUS verwendet.

1.3.1.4 Kombinationen von Baum- und Ringstruktur

-17-

Abbildung 6: Ringstruktur adaptiert von [1]

Aktor

SPS/PC

Sensor

Aktor

Abbildung 7: Kombination von Baum- und Ringstruktur adaptiert von [1]

Busklemme

Sensor

Aktor

Sensor

Aktor

Busklemme

SPS

Aktor

1.3.2 Modelle

Bei der Vorgehensweise wie Busteilnehmer am Feldbus Daten untereinander austauschen

werden im wesentlichen zwischen dem Producer-Consumer Modell und dem Client

Server-Modell unterschieden.

1.3.2.1 Producer-Consumer / Client-Server

Client Server-Modell:

Der Client schickt eine Anforderung an den Server. Der Server bearbeitet diese und

antwortet in Abhängigkeit vom Ergebnis der Bearbeitung. In der Automatisierungs- und

Feldebene ist der Client meist eine SPS oder ein PC und der Server ein einfacher Sensor

(z.B.: Temperatursensor). Diese Art der Verbindung zwischen Client und Server wird auch

Eins-zu-Eins Verbindung oder oft auch Peer to Peer, genannt. Es handelt sich um eine

verbindungsorientierte Übertragung wobei eine Verbindung aufgebaut und nach

Beendigung der Datenübertragung wieder abgebaut wird. Meist wird mit Bestätigung

gearbeitet wodurch die Sicherheit aber auch die Datenmengen erhöht wird. Im Falle eines

Fehlers wird das Telegramm wiederholt.

Bei einer Temperaturregelung würde der Client in fest vorgegebenen Zeitintervallen eine

Anforderung an den Server schicken, der Server mit der aktuellen Isttemperatur antworten.

Abbildung 8 zeigt einen typischen den Ablauf einer Client-Server Kommunikation.

-18-

Producer-Consumer-Modell:

Beim Producer-Consumer Modell schickt ein Teilnehmer als Producer ein Telegramm ab.

Jeder Teilnehmer der an diesem Telegramm interessiert ist, nimmt dieses als so genannter

Consumer auf. Das heißt die Adressinformation bezeichnet nicht einen Teilnehmer sondern

ein Objekt zum Beispiel die Ist-Temperatur. Anhand der Adressinformation erkennen die

restlichen Teilnehmer worum es sich in dem folgenden Telegramm handelt. Tritt ein Fehler

auf, wird die Übertragung nicht wiederholt sondern der aktuelle Wert gehalten und erst

wieder die nächste gültige Information verwertet. Diese Vorgangs weise ermöglicht den

Determinismus der Übertragung zu erhöhen.

Bei dieser verbindungslosen Übertragung ist auch eine so genannte Multicastversendung

möglich, wobei ein Telegramm an eine Gruppe von Teilnehmern gesendet wird. Dies ist

-19-

Abbildung 8: Client-Server Kommunikationsablauf

(

ykl

Client

Server1

Temperatur

Sensor

Client

1. Client sendet Anfrage an

Server

(Ist-Temperatur?)

2.Temp.Sensor

mißt die

Ist-Temperatur

3.Server sendet Ist-

Temperatur an Client

4.Client

vergleicht

Ist-Temperatur

mit

Solltemperatur

und berechnet

Stellgröße

Server2

Heizung

4.Client sendet

Stellgröße an

Heizung

5.Heizung

beeinflußt

Prozess durch

neue

Stellgröße

Start des nächsten Zyklus beginnt

mit Anfrage des Clients (SPS) an

Server1 (Temperatursensor)

der Fall wenn aufgrund der Adressinformation mehrere Teilnehmer angesprochen werden.

Verwendung der 2 Modelle bei Feldbusrealisierungen:

Bei den meisten Feldbusvarianten werden meist beide Modelle verwendet um die Vorteile

des jeweiligen Modells zu nutzen.

Bsp.1:

PROFIBUS arbeitet zur Übertragung der Sensor- und Aktordaten mit dem Client-

Server-Modell. PROFIBUS kennt auch Multicast- und Broadcastübertragung.

Bsp.2:

CAN überträgt mit dem Producer-Consumer Verfahren Sensor- und Aktordaten, zur

Übertragung von Parametrierungsdaten oder Diagnosedaten ist jedoch auch eine

Datenübertragung basierend auf dem Client-Server Modell möglich.

Das Client Server Modell kommt für die Übertragung von größeren (meist nicht zeit-

kritischen) Datenmengen zur Anwendung.

1.3.2.2 Nachrichtenorientiert vs. E/A-orientiert

Ein weiteres Unterscheidungsmerkmal von Feldbussystemen ist durch die Unterscheidung

von nachrichtenorientierten und eingangs- / ausgangsorientierten Übertragungsverfahren

gegeben.

Bei der nachrichtenorientierten Übertragung werden Nachrichten wie zum Beispiel

,,Temperatur überschritten" übertragen. Der Telegrammaufbau bei diesem Übertragungs-

verfahren ist aus Abbildung 9 ersichtlich.

-20-

Abbildung 9: Telegrammaufbau bei nachrichtenorientierten Übertragungsverfahren [8]

Start Adresse Steuer

Datensicherung

Daten

Ende

Mit Hilfe des Start- und Endteiles kann jeder Teilnehmer erkennen wo ein Telegramm

beginnt (Start) und wo es endet (Ende). Aus der Adresse erkennt der Teilnehmer für wen es

bestimmt ist. Der Steuerteil (Steuer) informiert über die Bedeutung der Daten. Mit Hilfe

des Datensicherungsteiles erfolgt eine Überprüfung der korrekten Übertragung des

Telegramms. Dabei läuft die Kommunikation zwischen zwei Teilnehmern meist in

folgenden Schritten ab:

1. Teilnehmer 1 sendet Anfrage an Teilnehmer 2

2. Teilnehmer 2 bestätigt Anfrage von Teilnehmer 1

Ein Beispiel für eine Feldbusrealisierung welche nachrichtenorientiert arbeitet, ist das

Controller Area Network (CAN).

Die E/A-orientierte Übertragung liefert direkt den Wert eines Sensors/Aktors. Bei diesem

Verfahren werden alle Sensoren und Aktoren in einem Telegramm angesprochen. Das

bedeutet in einem Zyklus wird gesendet und empfangen. Das Telegramm bei diesem

Verfahren ist in Abbildung 10 ersichtlich

Die Protokolleffizienz ist dabei prinzipiell nach [2] besser als bei den nachrichten-

orientierten Verfahren. Was aber meist nur für die Protokolleffizienz gilt. Die Effizienz des

Bussystems in einer konkreten Anwendung ist jedoch auch von anderen Faktoren

abhängig.

Bsp.: Sind am Bus Sensoren / Aktoren angeschlossen deren Aktualisierungsraten sehr

unterschiedlich sind (schnell und langsam) bewirkt dies bei einem E/A-orientierten Über-

tragungsverfahren dass mehrere Zyklen von den langsamen Sensoren/Aktoren ,,alte" nicht

geänderte Werte übertragen werden. Diese Daten können nicht als Nutzdaten bezeichnet

werden und mindern somit die Effizienz. Ein realisiertes Bussystem, welches mit diesem

Protokoll arbeitet, ist der INTERBUS.

-21-

Abbildung 10: Telegrammaufbau bei E/A-orientierten Übertragungsverfahren [8]

Loopcheck

Daten für

Gerät 2

Ende

Daten für

Gerät 3

Datensicherung

Daten für

Gerät 2

1.3.3 Physikalische Medien

Im wesentlichen wird zwischen Draht und Lichtwellenleiter unterschieden. Lichtwellen-

leiter (LWL) werden dort verwendet wo hohe Geschwindigkeit und hohe Störsicherheit

gefordert ist. Dabei kommt die LWL-Technologie dort zum Einsatz wo aufgrund der

Umgebungsbedingungen (elektromagnetische Beeinflussung) die drahtgebundene Daten-

übertragung Probleme bereitet.

1.3.4 Buszugriffsverfahren

Buszugriffsverfahren beschreiben wie der Zugriff auf den Bus zwischen den Busteil-

nehmern organisiert wird. Da viele Teilnehmer über eine Leitung kommunizieren, muss

vor allem das Senden von Informationen auf den Bus koordiniert werden. Wäre das nicht

der Fall, könnten zwei Teilnehmer gleichzeitig Daten senden, was zu einer Zerstörung der

Informationen führen würde.

Auch das Buszugriffsverfahren beeinflusst die Echtzeitfähigkeit, die Übertragungsrate, die

Komplexität des Businterfaces und die mögliche Leitungslänge [1].

Die folgend beschriebenen Verfahren lassen sich in zwei Gruppen unterteilen.

In eine Gruppe bei welcher der Zugriff bei Bedarf und in eine bei welcher der Zugriff nach

Zuteilung erfolgt.

1.3.4.1 Master-Slave Verfahren

Beim Master-Slave-Verfahren ist ein Teilnehmer vorhanden welcher regelt wer auf den

Bus, wann zugreifen darf. Dieser als Master bezeichnete Teilnehmer teilt den Slaves das

Sende-recht zu. Der Master kann selbst ein Telegramm senden oder einem Slave das

Senderecht erteilen.

Meist läuft die Kommunikation nach einem ,,Kommando-Antwort-Schema" ab. Die zwei

dabei auftretenden Abläufe sind:

Master schickt Kommando an Slave, Slave führt Kommando aus und Slave quittiert

den korrekten Empfang durch eine Antwort an den Master

Master fordert den Slave auf Daten/Informationen zum Master zu senden

-22-

Üblicherweise werden die Slaves streng zyklisch angesprochen.

Damit Anwenderprogramm und Kommunikationssystem nicht zu stark miteinander

verwachsen, wird der Busmaster als eigene Baugruppe realisiert. Diese kommuniziert mit

dem Rechner auf dem das Anwenderprogramm läuft über ein Dual-Port-RAM oder einen

Multi-Port-RAM.. Ein Beispiel dafür ist die in Kapitel 3 beschriebene Systemkopplerkarte

IBS-PCI-RI/LK. Der Busmaster sendet und empfängt kontinuierlich Daten. Empfangene

Daten werden in den Dual-Port-RAM geschrieben und dadurch dem Anwenderprogramm

zugänglich gemacht. Daten welche der Master über den Bus versenden soll, werden vom

Anwenderprogramm in den RAM geschrieben und vom Master dort gelesen.

Vorteile:

Die Intelligenz konzentriert sich im Master wodurch es möglich ist die Bus-

interfaces der Slaves sehr einfach auszuführen.

Der Zugriff der Teilnehmer auf den Bus wird durch den Master streng

geregelt. Echtzeitfähigkeit ist dadurch gewährleistet.

Nachteile:

Bei einem Ausfall des Masters stoppt das gesamte Bussystem.

Eine Slave zu Slave Kommunikation ist aufwändig da zuerst die Daten vom

sendenden Slave zum Master und dann vom Master zum Ziel-Slave über-

tragen werden müssen.

Aufgrund der zyklischen Arbeitsweise werden oft die selben Daten über-

tragen wie beim vorhergehenden Zyklus. Das bedeutet am Bus werden oft

Daten transportiert die keine neuen Informationen beinhalten.

Bei steigender Teilnehmerzahl steigt die Zykluszeit.

1.3.4.2 Token-Passing Verfahren

Dieses Verfahren ermöglicht es einem Master-Slave System mehrere Teilnehmer ab-

wechselnd als Master arbeiten zu lassen. Um abzustimmen wer gerade Master ist, wird ein

spezielles kurzes Diagramm verwendet, welches als Token bezeichnet wird. Dieser Token

wird von Teilnehmer zu Teilnehmer weitergereicht. Derjenige der es besitzt hat das Sende-

recht. Der aktuelle Master kann Telegramme senden oder wenn nichts zu senden ist, das

Telegramm weitergeben. Die maximale Zeitdauer die jedem Tokenbesitzer zur Verfügung

-23-

steht wird bei der Initialisierung / Projektierung festgelegt. Auch die Reihenfolge in der die

Teilnehmer das Token erhalten wird beim Einrichten des Busses festgelegt.

Vorteile:

Grundsätzlich echtzeitfähig

Gegenseitige Überwachung der Teilnehmer. Tritt bei einem Teilnehmer ein

Fehler auf, kann dieser vom Tokenbesitz ausgeschlossen werden und der

Bus ohne diesen Teilnehmer weiter betrieben werden.

Wenn ein Teilnehmer nichts zu senden hat, kann der Token weitergegeben

werden. Die gewonnene Zeit kann einem anderen Teilnehmer zur Verfügung

stehen.

Die Teilnehmer können direkt und ohne Umweg miteinander

kommunizieren. Bei einem reinem Master-Slave Verfahren ist dies nicht

möglich.

Nachteile:

Steigende Teilnehmerzahl lässt die Tokenumlaufzeit steigen.

Neukonfiguration des gesamten Bussystems bei hinzufügen oder ent-

nehmen eines Teilnehmers erforderlich.

Hoher Aufwand für die Busverwaltung aufgrund der Komplexität.

Teure Businterfaces der Teilnehmer.

PROFIBUS verwendet das Token-Passing Verfahren in Kombination mit dem Master-

Slave -Verfahren.(Siehe auch Kapitel 5)

1.3.4.3 Summenrahmen-Verfahren

Das Summenrahmenverfahren stellt eine spezielle Variante des Master-Slave Verfahrens

dar. Der Bus ist wie aus Abbildung 11

ersichtlich eine Ringstruktur. Alle Teilnehmer

bilden ein räumlich verteiltes Schieberegister. Ein Teilnehmer ist der Master (meist SPS

oder PC). Dieser Master versendet ein Telegramm in Form eines Summenrahmens. Jedes

Byte dieses Rahmens durchläuft alle Teilnehmer. Jeder Slave besitzt ein Schieberegister

durch welches der Summenrahmen Bit für Bit durch geschoben wird. Die Anzahl der Bits

über welcher ein Slave verfügt, ist abhängig von der Hardware des Slaves. Wenn z.B.: ein

einfacher Slave acht Relais besitzt dann verfügt er über ein Byte. Für jedes Byte, welches

-24-

den Ausgangsdaten eines Slaves entspricht, dass der Master hinausschiebt, wird ein Byte

(Eingangsdaten der Slaves) in den Master geschoben. Abbildung 11 zeigt den Zustand der

Eingangsdaten vor einem Zyklus und Abbildung 12 zeigt die Zustände danach.

-25-

Abbildung 11: Verteilung der Daten vor dem Datenzyklus

Master

z.B.: SPS / PC

Slave 2

Eingabe Daten 2

Eingabe Daten 1

Slave1

Slave 4

Eingabe Daten 4

Eingabe Daten 3

Slave 3

Ausgabe Daten 1

Ausgabe Daten 2

Ausgabe Daten 3

Ausgabe Daten 4

Sensoren

Aktoren

Sensoren

Abbildung 12: Verteilung der Daten nach dem Datenzyklus

Master

z.B.: SPS / PC

Slave 2

Eingabe Daten 2

Eingabe Daten 1

Slave1

Slave 4

Eingabe Daten 4

Eingabe Daten 3

Slave 3

Ausgabe Daten 1

Ausgabe Daten 2

Ausgabe Daten 3

Ausgabe Daten 4

Sensoren

Aktoren

Sensoren

1.3.4.4 CSMA/CD-Verfahren

Bei den in den Kapiteln 1.3.4.3, 1.3.4.2 und 1.3.4.1 genannten Verfahren wird der Bus-

zugriff zentral organisiert. CSMA steht für Carrier Sense Multiple Access. CD steht für

Collision Detection. Dieses Verfahren ermöglicht Busteilnehmern den Zugriff auf den Bus

bei Bedarf. Wenn ein Busteilnehmer senden will, hört dieser den Bus ab, ist dieser frei

beginnt der Teilnehmer zu senden. Aufgrund der Signallaufzeiten und der Erfordernis dass

Kollisionen erkannt werden, ergibt sich eine Mindestlänge des Telegramms (Bei Ethernet

nach Norm 802.3 mindestens 72 Bytes). Wird eine Kollision erkannt, brechen beide Sender

ihr Telegramm ab und geben den Bus frei. Nach einer, durch einen Zufallsgenerator

generierten Zeitspanne, versuchen die Busteilnehmer erneut ihre Nachricht zu senden.

Dieses Verfahren kommt bei Ethernet zur Anwendung.

1.3.4.5 CSMA/CA-Verfahren

CA steht für Collision Avoidance - bei diesem Verfahren werden im Gegensatz zu dem in

Kapitel 1.3.4.4 beschriebenen CSMA/CD-Verfahren, Kollisionen vermieden. Dies wird

durch eine entsprechende physikalische Ankopplung bei der ein Zustand z.B. binär 0,

dominant ist. Das bedeutet wenn ein Sender eine binäre 0 und der Andere eine binäre 1

sendet stellt sich am Bus aufgrund der Dominanz der binären 0 dieser Zustand ein.

Eine Datenübertragung bei der zwei Teilnehmer gleichzeitig senden, läuft wie folgt ab:

Beide übertragen ein Startbit welches immer dominant ist. Darauf folgt die Adress-

information. Bei der Übertragung dieser Adressinformation kommt die Dominanz

des CA-Verfahrens zum Tragen. Das heißt je niedriger die Adressinformation desto

mehr dominante Nullen sind enthalten. Über diese Adressinformation wird die

Priorität der Nachricht festgelegt.

1.3.5 Datensicherung

Bei der Übertragung von Daten kann es passieren, dass ein oder mehrere Bits ihren Wert

ändern. Die Hauptursache für solche Störungen sind elektromagnetische Fremdfelder

welche in technischen Anlagen zum Beispiel durch elektrische Antriebe oder Trans-

formatoren erzeugt werden. Durch diese Fremdfelder anderer Anlagenteile werden in

-26-

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2004
ISBN (eBook): 9783832486686
ISBN (Paperback): 9783838686684
DOI: 10.3239/9783832486686
Dateigröße: 1.8 MB
Sprache: Deutsch
Institution / Hochschule: FHWien der WKW – unbekannt
Erscheinungsdatum: 2005 (März)
Note: 1,0
Schlagworte: phoenix contact sigmatek siemens sc/ri-lk vertikale integration

Autor

Christian Aschauer (Autor:in)