3.2 Feldbusse

90
1 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 3.2 Feldbusse Feldbusse Spezielle Peripheriebusse mit schärferen Anforderungen, z.B. für Automatisierungssysteme 3.2.1 Überblick und Anwendungen Hierarchische Struktur eines Automatisierungs- systems, z.B. einer vollautomatischen Produktionsanlage:

description

3.2 Feldbusse. Feldbusse Spezielle Peripheriebusse mit schärferen Anforderungen, z.B. für Automatisierungssysteme 3.2.1 Überblick und Anwendungen Hierarchische Struktur eines Automatisierungs- systems, z.B. einer vollautomatischen Produktionsanlage:. 3.2 Feldbusse. - PowerPoint PPT Presentation

Transcript of 3.2 Feldbusse

Page 1: 3.2 Feldbusse

1Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Feldbusse

Spezielle Peripheriebusse mit schärferen Anforderungen, z.B. für Automatisierungssysteme

3.2.1 Überblick und Anwendungen Hierarchische Struktureines Automatisierungs-systems, z.B. einervollautomatischenProduktionsanlage:

Page 2: 3.2 Feldbusse

2Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Diese Hierarchie erlaubt es, die extrem komplexen und vielfältigen Aufgaben, die bei der Automation einer großen Produktionsanlage anfallen, zu ordnen und in überschaubare Teile zu zerlegen  strukturierter und modularer Aufbau eines

komplexen eingebetteten Systems

Page 3: 3.2 Feldbusse

3Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Wesentliche Ebenen und deren Aufgaben:Sensor/Aktor-Ebene

Ebene der Feldgeräte. Hier werden mittels Sensoren die Prozeßgrößen gemessen und mittels Aktoren auf sie

eingewirkt

ProzeßebeneEbene der Prozeßrechner. Hier werden die gemessenen

Größen überwacht und verarbeitet. Mittels Steuer- und

Regelalgorithmen werden die Stellgrößen ermittelt. (operative Aufgaben)

SystemebeneEbene der Systemrechner. Zusammenfassung aller

Aufgaben zur Führung, Planung und Koordination eines aus mehreren Prozessen bestehenden technischen Systems (z.B. einer Fertigungszelle). (operative und dispositive Aufgaben)

Page 4: 3.2 Feldbusse

4Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

LeitebeneEbene der Leitrechner. Hier werden alle Aufgaben zur

Führung, Planung und Koordination eines aus mehreren Teilsystemen

bestehenden Automatisierungssystems (z.B. einer Fertigungsstraße) durchgeführt. Es werden entsprechend

die Systemrechner koordiniert und synchronisiert.(dispositive Aufgaben)

BetriebsebeneEbene der Unternehmensführung. Hier werden alle zur

Führung einer Fabrik oder eines Unternehmens notwendigen

langfristigen Planungen und Vorgaben erarbeitet und an die Leitebene

weitergeleitet(dispositive Aufgaben)

Page 5: 3.2 Feldbusse

5Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Zwischen den einzelnen Ebenen müssen Informationen ausgetauscht werden

Nachrichtenverbindungen müssen vorhanden sein

 

Je nach Ebene wurdenhierfür verschiedeneKommunikationsmedienund –mechanismendefiniert:

Page 6: 3.2 Feldbusse

6Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Anforderungen an Feldbusse:

• geringer Verdrahtungsaufwand => serielles Bussystem

• bidirektionaler Informationsfluss zu oder von jedem angeschlossenen Gerät,

Sensor, Aktor, ...

• keine Rückwirkung von angeschlossnen Geräten auf andere Geräte am Bus

• keine Beeinträchtigung des Busses bei Ausfall eines Gerätes

• einheitliche Anschlusstechnik, genormte Busprotokolle einfacher Einsatz

und Austausch von Geräten verschiedener Hersteller

• optional eigene Stromversorgung der Geräte oder Stromversorgung über den

Bus

• Erweiterbarkeit zur Ausdehnung der Kommunikation bis zur Systemebene

 

Page 7: 3.2 Feldbusse

7Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Um Hard- und Softwareunabhängigkeit zu erreichen Feldbusse benutzen die genormten Protokollschnittstellen des

ISO-OSI* Referenzmodells

 

ISO-OSI 7-Schichten Modell:

* International Standard Organisation - Open System Interconnect

 

Page 8: 3.2 Feldbusse

8Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Page 9: 3.2 Feldbusse

9Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Schicht 1 - Physical Layer (Bitübertragungsschicht)ist für die physikalische Datenübertragung verantwortlich, d.h. elektrische Verbindung, elektrische Bitdarstellung (Bitkodierung), Steckertyp, Anschlussbelegung, Leitungsart und -länge, ... (z.B. RS 232, RS 485)

Schicht 2 - Data Link Layer (Sicherungsschicht)ist für eine fehlerfreie Punkt-zu-Punkt Übertragung zwischen benachbarten Systemen verantwortlich. Wesentliche Aufgaben: Zugriffsmechanismen (Medium Access Control, z.B. Bus-Zugriffsstrategien und -Kollisionsbehandlung) Datensicherung (Logical Link Control, z.B. mittels Prüfsummen, CRC, ...)

Schicht 3 - Network Layer (Vermittlungsschicht)ist für die Datenübertragung zwischen den Endsystemen verantwortlich. Wesentliche Aufgaben: Wegwahl (Routing), Multiplexen des Verbindungsmediums, Regelung der Datenflüsse zwischen den Endsystemen, ...

Page 10: 3.2 Feldbusse

10Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Schicht 4 - Transport Layer (Transportschicht)ist für eine Datenübertragung zwischen Endsystemen mit symbolischen Transportadressen in definierter Dienstgüte verantwortlich. Wählt je nach benötigter Dienstgüte (Datendurchsatz, Übertragungsdauer, Restfehlerrate, ...) ein Transportverfahren aus den unteren Schichten aus

Schicht 5 - Session Layer (Kommunikationssteuerschicht)ist für die Verwaltung einer Kommunikationssitzung verantwortlich. Wesentliche Aufgaben: Verbindungsauf- und abbau, Datensynchronisation

Schicht 6 - Presentation Layer (Darstellungschicht)ist für die Datendarstellung verantwortlich, also z.B. für netzeinheitliche Datenformate, Verschlüsselung, Kompression, ...

Schicht 7 - Application Layer (Anwendungsschicht)stellt dem Anwendungsprogramm anwenderspezifische Kommunikationsfunktionen und Protokolle zur Verfügung (z.B. verteilte Dateiverwaltung, verteilte Programmausführung, Datenbankzugriffe, ...)

 

Page 11: 3.2 Feldbusse

11Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Einige Feldbusse:

Profi-Bus (Process Field Bus)

in dem BMFT-Verbundprojekt 'Feldbus' in Deutschland von verschiedenen Firmen und Hochschulen entwickelter Feldbus

P-NET-Bus

von der dänischen Firma PROCES-DATA entwickelter und dem Anwender lizenzfrei zur Verfügung stehender Feldbus

Interbus S

von einem Verbund mehrere Firmen(z.B. Phönix Kontakt) entwickelter Aktor/Sensor-Bus

Page 12: 3.2 Feldbusse

12Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

ASI (Aktor Sensor Interface)

Verbundprojekt zur Entwicklung einer einfachen Schnittstelle für binäre Feldgeräte

Bitbus

von Intel entwickelter Feldbus

CAN-Bus (Controller Area Network Bus)

von Bosch und Intel für die Zusammenschaltung von Mikroprozessoren, Aktoren und Sensoren in Fahrzeugen entwickelter Feldbus

 

Page 13: 3.2 Feldbusse

13Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

DIN-Meßbus

von einem DIN-Ausschuss unter Mitarbeit von Messgeräteherstellern und der physikalisch technischen Bundesanstalt genormter Bus zur Datenübermittlung im Bereich Mess- und Prüftechnik

FIP-Bus (Flux Information Processus Bus)

französischer und italienischer Standard für einen Feldbus

FAIS-Bus (Factory Automation Interconnection System Bus)

japanischer Feldbus-Standard

 

Page 14: 3.2 Feldbusse

14Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

3.2.2 Der ProfiBus

Für die hohen Schichten der Automatisierungs-Hierarchie:

MAP-Protokoll (Manufactoring Automation Protocol)

Vernetzung von Verwaltungs- und Leitrechnern bis zur SPS

hohe Schnittstellenkosten

Für die Vernetzung von Feldgeräten sind jedoch kostengünstige Schnittstellen erforderlich

Gründung des Verbundprojektes 'Feldbus' im Jahr 1987

Beteiligt: 13 Firmen und 5 Hochschulen

 

Page 15: 3.2 Feldbusse

15Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Anforderungen:

• einfache, kostengünstige Übertragungstechnik

• Verwendung bestehender Normen

• anwenderfreundliche Schnittstelle

• projektierbare Freiheitsgrade

 Ergebnis: Din Norm 19245 Teil 1 und 2: PROFIBUS

Innerhalb der PROFIBUS-Norm finden verschiedene andere Normen Verwendung, z.B. RS 485, IEC 955, DIN 19244, ...

Durch wachsende Anforderungen: ständige Erweiterungen der Profibus-Normen (z.B. Profi-Bus DP [Dezentrale Peripherie], PA, ...)

Page 16: 3.2 Feldbusse

16Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Konfiguration des Profi-Bus

Bus-Topologie:

 

• Grundtopologie: Linie (Segment) mit über Stich-leitungen angekoppelten Komponenten

• Linienlänge je nach Übertragungs ge-

schwindigkeit bis 1200 m

• Segmente können über Leitungsverstärker(Repeater) erweitertwerden

Page 17: 3.2 Feldbusse

17Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

maximale Entfernungen in Abhängigkeit von Baudrate und Repeateranzahl:

Maximale Teilnehmeranzahl pro Segment: 32

Maximale Gesamtteilnehmerzahl : 127

(begrenzt durch Teilnehmeradressbereich 0 .. 126)

 

 

Baudrate

maximale Entfernung

< 93 kB

187,5 kB

500 kB 12 MB

ohne Repeater 1200 m 600 m 200 m 50 m1 Repeater 2400 m 1200 m 400 m 100 m2 Repeater 3600 m 1800 m 600 m 150 m3 Repeater 4800 m 2400 m 800 m 200 m

Page 18: 3.2 Feldbusse

18Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Bevor ein solches Profibus-Netz in Betrieb genommen wird, müssen die einzelnen Teilnehmer konfiguriert werden

Hierbei werden die logischen Verbindungen (Kommunikationsbeziehungen) und die zu übertragenden Daten (Kommunikationsobjekte) festgelegt

die Kommunikation ist vor Inbetriebnahme projektierbar

Der Profi-Bus unterscheidet aktive Teilnehmer (Profi-Bus Master) und passive Teilnehmer (Profi-Bus Slave). Er erlaubt hierbei das Vorhandensein mehrerer Master (Multi-Master System, näheres hierzu später)  

 

Page 19: 3.2 Feldbusse

19Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Kommunikationsbeziehungen:

legen fest, welcher Teilnehmer mit wem Daten austauscht

Die Kommunikationsbeziehungen werden in der Kommunikationsbeziehungsliste (KBL) abgelegt

Jedes Gerät besitzt eine KBL, in der seine möglichen Kommunikationspartner aufgeführt sind

 

Page 20: 3.2 Feldbusse

20Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Beispiel einer KBL fürzwei Geräte:

 

 

Gerät A Gerät B Kommunikationsreferenz #1 #6 eigener Dienstzugangspunkt 17 20 Teilnehmeradresse des Partners 22 21 Dienstzugangspunkt des Partners 20 17

eine Nachricht, die unter

Kommunikationsreferenz #1

von Gerät A abgeschickt wurde, wird von Gerät B unter Kommunikations-referenz #6 empfangen

Page 21: 3.2 Feldbusse

21Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Grundsätzlich wird beim Profi-Bus zwischen zwei verschiedenen Kommunikationstypen unterschieden:

1. Verbindungsorientierte Kommunikation

Kommunikation zwischen zwei Teilnehmern (wie in obigem Beispiel)

Zwei Varianten:

• Kommunikation Master - Master

Kommunikation zwischen zwei aktiven Profi-Bus-Teilnehmern

• Kommunikation Master - Slave

Kommunikation zwischen einem aktiven und einem passiven

Profi-Bus-Teilnehmer

Page 22: 3.2 Feldbusse

22Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

2. Verbindungslose Kommunikation

Hierbei sendet ein Teilnehmer an viele andere. Es erfolgt keine Rückantwort

Zwei Varianten:

• Broadcast

Nachricht an alle Teilnehmer

• Multicast

Nachricht an eine Gruppe von Teilnehmern

 

Page 23: 3.2 Feldbusse

23Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Kommunikationsobjekte:

 

Wollen zwei Teilnehmer Daten über das Netz austauschen, so muß zwischen ihnen vereinbart sein, um welche Daten es sich handelt

 

Kommunikationsobjekte

 

Jeder Teilnehmer hält ein Objektverzeichnis (OV), welches die von ihm benötigten Kommunikationsobjekte beschreibt

 

Page 24: 3.2 Feldbusse

24Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Informationen des OV über ein Kommunikationsobjekt:

• Objekttyp: einfache Variable, Array, ...• Startadresse: interne Adresse des Objekts• Anzahl: Länge des belegten Speicherbereichs• Datentyp: Integer 8, Integer 16, Unsigned 8, ...• Passwort: optional, wenn Zugriffschutz erforderlich• Zugriffsrechte: Festlegung der zulässigen Operationen

 

Ein Teilnehmer, der Daten anfordert oder schickt, muss dem Partner zunächst eine Kennung senden, welche die zu übermittelnden Kommunikationsobjekte identifiziert (z.B Index oder symbolischer Name des Kommunikationsobjekts)

Page 25: 3.2 Feldbusse

25Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Der Aufbau des Objektverzeichnis kann statisch oder dynamisch erfolgen:

statischer Aufbau: das Objektverzeichnis wird fest projektiert, alle

Kommunikationsobjekte werden in der Projektierungsphase definiert

Jeder Teilnehmer besitzt bereits beim Systemstart alle Kommunikationsobjekte, die er benötigt, in seinem OV

 

 

Vorteil: kein Kommunikationsaufwand zur Bekanntmachung von Kommunikationsobjekten erforderlich

Nachteil: starre Konstruktion, Konfigurationsänderungen

erfordern viel Aufwand

Page 26: 3.2 Feldbusse

26Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

dynamischer Aufbau: die Objektbeschreibungen existieren bei

dem Teilnehmer, bei dem die Objekte real

existieren. Ein Teilnehmer, der auf ein Objekt zugreifen will, fordert vorher die Objektbeschreibung an

 

 

Vorteil: Flexibilität zur Laufzeit

Nachteil: zusätzlicher Kommunikationsaufwand

Page 27: 3.2 Feldbusse

27Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Einordnung des Profi-Bus in das ISO-OSI Modell

 

 

Um den Protokollverwaltungs-aufwand zu minimieren und eine kostengünstige, schnelle Netzverbindung zu schaffen:

Nur die Schichten 1, 2und 7 sind beim Profi-Bus implementiert

Die restlichen Schichten sind leer und werden durch den unteren Teil der Schicht 7 (LLI - Lower Layer Interface) substituiert

Page 28: 3.2 Feldbusse

28Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

A

B

Cenable

Schema eines differenziellen Treiber der RS-485

+ +

Slave #n

Slave#1 Master

Steuereingang(Tx Enable)

Steuereingang(Tx Enable)

Sendedaten Empfangsdaten

Empfangsdaten Sendedaten

Bus A (-)

Bus B (+)

++ ++

Steuereingang(Tx Enable)

Empfangsdaten

Sendedaten

Bidirektionaler Bus

Zweidraht-Variante, Vierdraht-Variante auch möglich

Schicht1: physikalische Übertragungstechnik

 

 

Page 29: 3.2 Feldbusse
Page 30: 3.2 Feldbusse

30Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Schicht 2 - Buszugriff und Datensicherung

Buszugriffsverfahren (Medium Access Control - MAC)

hybrides Multi-Master/Token-Ring Verfahren

Unterscheidung zwischen Master- und Slave-Teilnehmer:

Nur ein Master darf selbstständig Nachrichten über den Bus senden, Slave-Teilnehmer dürfen nur auf Anforderung von Mastern antworten

Koordinierung mehrerer Master (Multi-Master System) mittels Token-Passing-Verfahren:

Nur der Master, welcher das Token gerade besitzt, darf am Bus aktiv werden, nach Abschluss Weitergabe des Tokens

 

 

Page 31: 3.2 Feldbusse

31Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Vorteile des hybriden Verfahrens:• mehrere intelligente Feldgeräte mit Eigeninitiative möglich (Token Passing)• schneller Echtzeit-Datenaustausch zwischen intelligenten Feldgeräten und

einfacher Prozessperipherie (Master/Slave)

2 4 6

1 3 5 7

Token

Master

Slaves

Page 32: 3.2 Feldbusse

32Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Gesicherte Verbindung (Fieldbus Data Link - FDL) 

Anforderungen:

• geringer Protokolloverhead für hohe Nettodatenrate

• hohe Datenübertragungssicherheit

 

Telegrammaufbau:

Es existieren verschiedene Telegrammvarianten, die durch unterschiedliche Start- und Steuerbytes gekennzeichnet sind

Page 33: 3.2 Feldbusse

33Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Beispiel:

a,b: feste Telegrammlänge (SD3),

Vorhandensein von 8 Byte Daten wird durch unterschiedliches FC

angezeigt

c: variable Telegrammlänge (SD2),

Längenangabe wird zur Sicherheit wiederholt (LE,

LEr)

Page 34: 3.2 Feldbusse

34Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Dienste, Dienstzugangspunkte und Dienstprimitive  Die Funktionalität einer Schicht wird der darüber liegenden Schicht in Form von Diensten zur Verfügung gestellt  Die logischen Schnittstellen, über die solche Dienste erreichbar sind, heißen Dienstzugangspunkte (Service Access Points - SAP). Über einen Dienstzugangspunkt wird auch eine Implementierung einer Schicht (Instanz) identifiziert 

Page 35: 3.2 Feldbusse

35Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Alle wesentlichen Dienste im Profi-Bus werden durch vier Dienstprimitive gesteuert: 

Dienst.Request(Anforderung)

Dienst.Confirm(Bestätigung)

Dienst.Indication(Anzeige)

Dienst.Response(Antwort)

Dienstprimitive

Page 36: 3.2 Feldbusse

36Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Teilnehmer A

SDA.Confirm

SDA.Request

SDA.Indication

Telegramme

Teilnehmer B

Basisdienste der Schicht 2

2 wesentliche Basisdienste:

• SDA (Send Data with Acknowledge)Erlaubt einem Teilnehmer A, Daten an einen Teilnehmer B zu senden. Teilnehmer A erhält eine Bestätigung. Im Fehlerfall wiederholt der Dienst die Datenübertragung

 Dienstablauf:

Page 37: 3.2 Feldbusse

37Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

• SDN (Send Data with no Acknowledge)Erlaubt einem Teilnehmer A, Daten an einen, mehrere (Multicast) oder alle (Broadcast) anderen Teilnehmer zu senden. Teilnehmer A erhält eine Bestätigung über das Ende der Übertragung, jedoch nicht über den korrekten Empfang

 Dienstablauf:

Teilnehmer A

SDN.Confirm

SDN.Request

SDN.Indication

Telegramme

Teilnehmer B,C, ...

Page 38: 3.2 Feldbusse

38Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Schicht 7 - Anwendungen Schicht 7a: LLI (Lower Layer Interface) - Dienste Enthält die für Profi-Bus notwendigen Funktionen der Schichten 3 - 6 Stellt eine von Schicht 2 unabhängige Dienstschnittstelle zur Schicht 7b (FMS) und somit zu Anwendungsdiensten zur Verfügung 

Page 39: 3.2 Feldbusse

39Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Basisdienste der Schicht 7a:

• ASS (Associate)Einrichtung einer Verbindung für die spätere Nutzung zur Datenübertragung

• DTU (Data Transfer Unconfirmed)unbestätigte Datenübertragung für verbindungslose Kommunikation (Multicast, Broadcast)

• DTC (Data Transfer Confirmed)bestätigte Datenübertragung für verbindungsorientierte Kommunikation

• ABT (Abort)Auflösung einer Verbindung

 

Page 40: 3.2 Feldbusse

40Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Schicht 7b: FMS (Fieldbus Message Specification) - Dienste Hier werden dem Anwender eine Vielzahl von Diensten zur Verfügung gestellt, die sich in Klassen und Gruppen teilen lassen: Basisdienste der Klasse Anwendungsdienste: Gruppe Variable Access

• Read, WriteÜbertragung von Variablen (einfache und zusammengesetzte Variablen)

Page 41: 3.2 Feldbusse

41Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Gruppe Domain Access

• Domain Upload, Domain DownloadÜbertragung von zusammenhängenden Speicherbereichen

 Gruppe Program Invocation

• Start, Stop, Resume, Kill, ResetAusführen von Programmen in Feldbus-Teilnehmern

 Gruppe Event Management

• Event NotificationEreignisgesteuerte Übertragung wichtiger Meldungen (z.B. Alarm)

Page 42: 3.2 Feldbusse

42Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Basisdienste der Klasse Verwaltungsdienste  Gruppe VFD-Support • Status, Identify

Übertragung der Kommunikationsdaten eines Feldgerätes an andere Teilnehmer (aktueller Betriebszustand, herstellerspezifische Angaben). Diese Daten stehen in einem gesonderten Speicherbereich, der sich den anderen Teilnehmern als ‘virtuelles Feldgerät’ (Virtual Field Device - VFD) darstellt

 

Page 43: 3.2 Feldbusse

43Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Gruppe OV-Management

• Get-OV, Put-OVÜbertragung der Objektverzeichnisse zwischen verschiedenen Teilnehmern

 Gruppe Context-Management

• Initiate, Abort, RejectAufbau (Initiate) und Abbau (Abort) einer Verbindung, Ablehnung (Reject) einer Verbindung (z.B. wenn ein angesprochener Teilnehmer den von ihm geforderten Dienst nicht erbringen kann)

 

Page 44: 3.2 Feldbusse

44Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Basisdienste der Klasse Netzmanagementdienste Gruppe Context-Management

• FMA7-Initiate, FMA7-AbortAuf- und Abbau einer Verbindung zum Netzwerkmanagement

 Gruppe Configuration-Management 

• Status-Lokal/Remote, Set/Read-Value, Live-ListVerschiedene Funktionen zur Konfigurationsverwaltung, z.B. zum Laden und Lesen der Kommunikationsbeziehungs-liste (KBL), Zugriff auf Statistikdaten, aktuelle Busteilnehmererfassung

Page 45: 3.2 Feldbusse

45Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Gruppe Fault-Management • FMA7-Reset, FMA7-Event

Funktionen zur Fehlerverwaltung, Anzeige von Fehlerereignissen und Rücksetzen von Busteilnehmern

Page 46: 3.2 Feldbusse

46Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Beispiel: Dienstablauf des Read-Dienstes

Page 47: 3.2 Feldbusse

47Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Projektierung eines Profi-Bus Systems

Übliche Vorgehensweise bei der Projektierung:

1. Übersicht

Mit Hilfe eines Übersichtsbildes werden alle notwendigen Automatisierungsgeräte erfasst, die an der Kommunikation beteiligt sind. Weiterhin werden die Segmente innerhalb der Netzhierarchie festgelegt

2. Festlegung der Topologie

Festlegung allgemeiner Konfigurationsparameter wir Baudrate, Teilnehmeradressen, etc. Wird durch Konfigurationssoftware unterstützt

Page 48: 3.2 Feldbusse

48Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

3. Festlegung der Kommunikationsbeziehungen

Definition aller Kommunikationsbeziehungen durch Eintrag in der Kommunikationsbeziehungsliste. Wird ebenfalls durch Konfigurationssoftware unterstützt

4. Erstellen der Objektverzeichnisse

Eintragung aller Daten, die über das Netz ausgetauscht werden, in das Objektverzeichnis. Dieser Schritt beendet die Konfiguration, alle Teilnehmer, Verbindungen und auszutauschende Daten sind hiermit bekannt5. Programmierung der Kommunikationsaufgabe

Erstellung der Anwendersoftware, welche die Profi-Bus Dienste benutzt

Page 49: 3.2 Feldbusse

49Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

6. Montage und Installation

Eigentliche Montage der Busverdrahtung, Geräte, etc.

7. Übertragung der Anwenderprogramme

Übertragung der Anwendersoftware in die einzelnen Busteilnehmer (Feldgeräte, Prozessrechner, ...)

8. Übertragung der Konfiguration

Die Konfigurationsdaten werden zu den einzelnen Geräten transferiert (über den Profi-Bus selbst oder über separate Schnittstellen)

Page 50: 3.2 Feldbusse

50Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

9. Inbetriebnahme

Aufbau und Prüfung der Verbindungen, Test und Inbetriebnahme der Anwendersoftware

  durch umfangreiche Planung im Vorfeld kann die

kostenintensive Inbetriebnahmephase verkürzt werden

Page 51: 3.2 Feldbusse

51Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Prinzipieller Aufbau einer Profibus-SchnittstelleEntlastet die CPU des übergeordneten Rechnersystems von den Protokollverwaltungs-Aufgaben der unteren Profi-Bus Schichten

Eine Watchdog- und Reset-Schaltung übernimmt die Systemüberwachung

Indirekte Busankopplung an das übergeordnete Mikrorechnersystem mittels Zwei-Tor-Speicher

Page 52: 3.2 Feldbusse

52Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

3.2.3 Der CanBus

CAN: Controller Area Network

entwickelt von Bosch und Intel

Ursprünglich hauptsächlich im Automobilbereich eingesetzt

Heute auch in anderen Bereichen der Automation zu finden

Page 53: 3.2 Feldbusse

53Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Varianten

CAN 2.0A: 11 Bit Adressraum

CAN 2.0B: 29 Bit Adressraum

CAN-Bus Controller können interne Puffer besitzen:

Full CAN: Speicher für mehrere Botschaften

Basic CAN: Speicher für eine Botschaft

SLIO CAN: Serial Linked IO

direkte Verbindung zum IO-Kanal

Page 54: 3.2 Feldbusse

54Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CAN-Knoten

CAN-Knoten

CAN-Knoten

CAN-Knoten

CAN-Knoten

CAN-Knoten

CAN-Knoten

CAN-Knoten

Topologie bei CAN (Linien- bzw. Bustopologie)

Page 55: 3.2 Feldbusse

55Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Aufbau

Schicht1: RS485 wie beim ProfiBus

Schicht 2: Ebenfalls Multi-Master fähig

Zugriffskontroller aber nach CSMA/CA Verfahren

anstelle von Token-Ring beim ProfiBus

(CSMA/CA = Carrier Sense Multiple Access with

Collision Avoidance)

Bei Konflikt Busvergabe nach Prioritäten

Page 56: 3.2 Feldbusse

56Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Fall 1 2 3 4

A sendet 0 0 1 1 B sendet 0 1 0 1 C empfängt (resultierender Buspegel)

0

0

0

1

CAN-Teilnehmer

‚A’

CAN-Teilnehmer

‚C’

CAN-Teinehmer

‚B’

CAN-Bus

Dominante 0 und rezessive 1 bei der CAN Übertragung

Page 57: 3.2 Feldbusse

57Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CAN-Teilnehmer

‚A’

CAN-Teilnehmer

‚C’

CAN-Teinehmer

‚B’

CAN-Bus

Bit-Nr = 1 2 3 4 5 6 7 8 9 10 11

A: Sendewunsch mit Identifier = 4210

= 000001010102 0 0 0 0 0 1 0 1 0 1 0

B: Sendewunsch mit Identifier = 2410

= 000000110002 0 0 0 0 0 0 1 1 0 0 0

C: empfängt (resultierender Identifier)

0 0 0 0 0 0 1 1 0 0 0

Bemerkung: Zum Zeitpunkt t=6 erkennt A die höhere Priorität von B und

zieht sich vom Senden zurück, danach sendet nur noch B.

Arbitrierung bei CAN

Page 58: 3.2 Feldbusse

58Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Startbit(1 Bit)

Identifier(11 Bits)

RTR-Bit(1 Bit)

Kontrollfeld(6 Bits)

Datenfeld(0..8 Bytes) ...

CRC-Sequenz(15 Bits)

CRC-Ende(1 Bit)

ACK-BIT(1 Bit)

ACK-Ende(1 Bit)

Endefeld(7 Bits)

Trennfeld(3 Bits)...

Startbit(1 Bit)

Identifier(11 Bits)

RTR-Bit(1 Bit)

Kontrollfeld(6 Bits)

Datenfeld(0..8 Bytes) ...

CRC-Sequenz(15 Bits)

CRC-Ende(1 Bit)

ACK-BIT(1 Bit)

ACK-Ende(1 Bit)

Endefeld(7 Bits)

Trennfeld(3 Bits)...

SRR-Bit(1 Bit)

IDE-Bit(1 Bit)

Identifier(18 Bits)

Aufbau eines CAN-2.0a Data Frame bzw. Remote Frame

Aufbau eines CAN-2.0b Data Frame bzw. Remote Frame

4 verschiedene Telegrammtypen: Data Frame: Zur Datenübertragung Remote Frame: Sendeaufforderung an andere Teilnehmer Error Frame: Meldung von Fehler an andere Teilnehmer Overload Frame: Signalisation der aktuellen Nicht-Bereitschaft

Page 59: 3.2 Feldbusse

59Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Topologie Linie mit Stichleitungen, abgeschlossen an beiden Enden

Buslänge 5 km bei 10 kbit/sec

25 m bei 1 Mbit/secÜbertragungsmedium zweiadrig, verdrillt, abgeschirmt, seltener: LWL

Anzahl Nutzdatenbytes pro Telegramm

0 - 8

Anzahl E/A Stationen Nur beschränkt durch die Treiberbausteine der CAN-Transceiver, nicht durch das Protokoll. Üblich: 30, mehr mit Repeatern/Spezialtreibern

Bitkodierung NRZ-Kodierung mit dominanter 0 und rezessiver 1

Übertragungsrate 10 kbit/sec bis 1 Mbit/sec

Übertragungssicherheit CRC-Check (mit Hamming-Distanz 6)

Buszugriffsverfahren Polling- oder ereignisgesteuerter Betrieb möglich (CSMA/CA: bitweise, nicht zerstörende Arbitrierung)

Busverwaltung Multimaster: Alle Teilnehmer sind gleichberechtigt, prioritätsgesteuert über Identifier

Eigenschaften

Page 60: 3.2 Feldbusse

60Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CAN Grunddefinition (Basisprotokoll) definiert nur die Schichten 1 und 2

Darauf aufbauend gibt es die verschiedensten höheren Layer,welche die Felder der Telegramme des CAN-Basisprotokolls auf ihre eigene Art interpretieren (z.B. den Identifier)

Page 61: 3.2 Feldbusse

61Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CA

N-B

us

Kommunikation

PDOs, SDOs, spezielle Funktionsobjekte, NMT-Objekte

Objektverzeichnis

Datentypen, Kommuni-kations- und Anwendungsobjekte

Anwendung

Anwendungsprogramm, Implementation des Geräteprofils

Ein-/

Ausgabe

Beispiel 1: CANopen zur genormten Interaktion veschiedener Geräte mittels CAN-Bus (auf Basis von CAN 2.0a)

Page 62: 3.2 Feldbusse

62Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CANopen-Geräteprofil für Ein-/Ausgabe-Module (CiA DSP-401)

CANopen-Geräteprofil für Antriebe (CiA DSP-402) CANopen-Geräteprofil für Encoder (CiA DSP-406) CANopen-Geräteprofil für Mensch-Maschine-

Schnittstellen (CiA WD-403), CANopen-Geräteprofil für Messwertaufnehmer

und Regler (CiA WD-404) CANopen-Geräteprofil für IEC-1131-kompatible

Steuerungen (CiA WD-405).

CANopen Geräteprofile

Page 63: 3.2 Feldbusse

63Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CAN-Bus

8 digitale Ausgänge 8 digitale Ausgänge

Steuerrechner CANopen

Gerätenummer 1

Teilnehmer B CANopen

Gerätenummer 3

Teilnehmer A CANopen

Gerätenummer 2

Schematischer Aufbau eines einfachen CANopen Bussystems

Page 64: 3.2 Feldbusse

64Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CAN- Bezeichnung

Identifier Kontroll-

feld ...

CANopen Bedeutung

Funktions-Code

Gerätenummer (bei NMT nicht verwendet)

Daten-länge

...

Feldlänge (4 Bit) (7 Bit) (4 Bit) ...

Wert 0 0 0 0 0 0 0 0 0 0 0 0x2 ...

...

Datenbytes

...

NMT-Code

Geräte-nummer

- - - - - -

... (1 Byte) (1 Byte) - - - - - -

... 0x01 0x02 - - - - - -

NMT Objekt (Starten) Steuerrechner Teilnehmer 2

Page 65: 3.2 Feldbusse

65Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CAN- Bezeichnung

Identifier Kontroll-

feld ...

CANopen Bedeutung

Funktions-Code

Gerätenummer (bei NMT nicht verwendet)

Daten-länge

...

Feldlänge (4 Bit) (7 Bit) (4 Bit) ...

Wert 0 0 0 0 0 0 0 0 0 0 0 0x2 ...

...

Datenbytes

...

NMT-Code

Geräte-nummer

- - - - - -

... (1 Byte) (1 Byte) - - - - - -

... 0x01 0x03 - - - - - -

NMT Objekt (Starten) Steuerrechner Teilnehmer 3

Page 66: 3.2 Feldbusse

66Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CAN- Bezeichnung

Identifier Kontroll-

feld ...

CANopen Bedeutung

Funktions-Code

Gerätenummer

Daten-länge

...

Feldlänge (4 Bit) (7 Bit) (4 Bit) ...

Wert 0 1 0 0 0 0 0 0 0 1 0 0x1 ...

...

Datenbytes

...

8 digitale Ausgänge

- - - - - - -

... (1 Byte) - - - - - - -

... 0xff - - - - - - -

PDO (Setzen von Ausgängen) Steuerrechner Teilnehmer 2

Page 67: 3.2 Feldbusse

67Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Objekt Funktions-Code (binär)

Resultierender Identifier (dezimal)

Typ

NMT 0000 0 Broadcast SYNC 0001 128 Broadcast

TIME-STAMP 0010 256 Broadcast EMERGENCY 0001 129 – 255 Peer-to-Peer

PDO1 (tx) 0011 385 – 511 Peer-to-Peer PDO1 (rx) 0100 513 – 639 Peer-to-Peer PDO2 (tx) 0101 641 – 767 Peer-to-Peer PDO2 (rx) 0110 769 – 895 Peer-to-Peer SDO (tx) 1011 1409 – 1535 Peer-to-Peer SDO (rx) 1100 1537 – 1663 Peer-to-Peer

Nodeguard 1110 1793 – 1919 Peer-to-Peer

Zuordnung von Objekten, Funktionscodes und Identifiern bei CANopen

Page 68: 3.2 Feldbusse

68Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CAN- Bezeichnung

Identifier Kontroll-

feld ...

CANopen Bedeutung

Funktions-Code

Gerätenummer

Daten-länge

...

Feldlänge (4 Bit) (7 Bit) (4 Bit) ...

Wert 0 1 0 0 0 0 0 0 0 1 1 0x1 ...

...

Datenbytes

...

8 digitale Ausgänge

- - - - - - -

... (1 Byte) - - - - - - -

... 0xf0 - - - - - - -

PDO (Setzen von Ausgängen) Steuerrechner Teilnehmer 3

Page 69: 3.2 Feldbusse

69Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Gefahrenbereich

Sicherheitszaun

Zu

ga

ng

stü

r Prozess

Feldbus

Türschalter

Not-Aus

Licht-gitter

Freigabe

Sicherheits-steuerung

Prozess-steuerung

Beispiel 2: SafetyBus p für sicherheitsrelevante Anwendungen

ohne Bus

Page 70: 3.2 Feldbusse

70Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Gefahrenbereich

Sicherheitszaun

Zu

ga

ng

stü

r Prozess

Feldbus

Türschalter

Freigabe

Sicherheits-steuerung

Licht-gitter

SafetyBUS p

Not-Aus

Prozess-steuerung

mit SafetyBus p

Page 71: 3.2 Feldbusse

71Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

• Wiederholung von Telegrammen

• Einfügung von Telegrammen

• Falsche Abfolge von Telegrammen

• Verzögerung von Telegrammen

• Verlust von Telegrammen

Mögliche Übertragungsfehler

Page 72: 3.2 Feldbusse

72Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

AP

BIP

SafetyBUS p (CAN Bus)

Transceiver

SafetyBUS p Kanal 1

SafetyBUS p Kanal 2

Mikrocontroller MC1

Mikrocontroller MC2

Teilredundante Hardware bei ‚sicheren Teilnehmern’

Page 73: 3.2 Feldbusse

73Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

CAN-

Bezeichnung Identifier(11 Bits)

...

SafetyBUS p Verwendung

Start -bit

(1 Bit) Klasse(3 Bit)

Senderadresse(8 Bit)

RTR (1 Bit)

Kontroll -feld

(6 Bits) ...

...

... Datenbytes(0-8 Bytes)

... Kopf(1 Byte)

Empfänger(1 Byte)

Sichere Nutzdaten(max. 4. Byte)

CRC(2 Byte)

CRC-Feld

(16 Bit)

ACK-Feld

(2 Bit)

Ende -feld

(7 Bit)

Trenn -feld

(3 Bit)

...

Klasse: SicherheitsklasseKopf: Laufende Nummer eines TelegrammsEmpfänger: Empfängeradresse

Aufbau eines SafetyBUS p Telegramms (CAN-2.0a)

Page 74: 3.2 Feldbusse

74Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Aufbau eines INTERBUS-Systems

Busklemme max. 64

Fernbus max. 12,8 km

Peripheriebus max. 10m

E/A-Modul 1

E/A-Modul n

E/A-Modul m E/A-Modul max. 256

E/A-Modul n+7

E/A-Modul max. 8......

...

...

...

...

Busklemme 1

Busklemme k

Master

... ...

3.2.4 Der INTERBUS

Page 75: 3.2 Feldbusse

75Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Master

Busklemme

E/A Modul (Peripheriebusgerät)

E/A Modul (Fernbusgerät)

Realisierung einer Baumstruktur mit Hilfe der bei INTERBUS verwendeten Ringstruktur

Page 76: 3.2 Feldbusse

76Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Zyklus der Datenübertragung bei INTERBUS: Summenrahmentelegramm durchläuft Schieberegister-

Master

Teilnehmer 1 Teilnehmer n ...

Daten von

Slave 1 (E)

Daten von

Slave 2 (E)

Daten von

Slave n (E) ...

Slave Slave 2 (A) Slave n (A) ...

SR 2

( Empfangen)

SR 1

(Senden)

Teilnehmer 2 ...

Slave

Slave...

Daten für ...

Date für Daten für

1 (A)

Loop Back Word

Loop Back Word

Frame Check Sequence

Frame Check Sequence

Page 77: 3.2 Feldbusse

77Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Summenrahmentelegramme bei INTERBUS

Summenrahmentelegramm beim Absenden im Master:

Name LBW Daten für Gerät 1

Daten für Gerät 2 ...

Daten für Gerät n FCS

Länge 16 Bit 4-64 Bit 4-64 Bit ... 4-64 Bit 32 Bit

Summenrahmentelegramm beim Empfangen im Master (nach Durchlaufen des Rings):

Name Daten von Gerät 1

Daten von Gerät 2

... Daten von Gerät n

LBW FCS

Länge 4-64 Bit 4-64 Bit ... 4-64 Bit 16 Bit 32 Bit

Page 78: 3.2 Feldbusse

78Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Topologie aktiver Ring

Buslänge max. 12,8 km (Fernbus)

max. 10 m (Peripheriebus)Übertragungsmedium Paarweise verdrillt, abgeschirmt;

LichtwellenleiterAnzahl Nutzdaten 4-64 Bit individuell für jeden Teilnehmer

Anzahl E/A Stationen max. 256 mit insgesamt max. 4096 E/As

Protokoll Summenrahmen Telegramm

Bitkodierung NRZ-Kodierung

Übertragungsrate 500 kBit/sec

Übertragungssicherheit CRC-Check (mit Hamming-Distanz 4),Loopback Word

Buszugriffsverfahren Festes Zeitraster

Busverwaltung Monomaster

Eigenschaften

Page 79: 3.2 Feldbusse

79Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Master

Stern

SPS, NC, RC, PC

Feldbus

Master

Stern

SPS, NC, RC, PC

Feldbus

3.2.5 ASI (Aktor Sensor Interface)

Page 80: 3.2 Feldbusse

80Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Mastertelegramm:

Start-bit

(1 Bit)

Steuer-bit

(1 Bit)

Slaveadresse

(5 Bit)

Befehl an Slave

(5 Bit)

Parität

(1 Bit)

Ende-Bit

(1 Bit)

Slavetelegramm:

Start-bit

(1 Bit)

Antwort an Master

(4 Bit)

Parität

(1 Bit)

Ende-Bit

(1 Bit)

Basistelegramme von Master und Slave beim ASI-Bus

Page 81: 3.2 Feldbusse

81Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Topologie Linie, Baum, Stern

Buslänge max. 100m (300m mit Repeater)

Übertragungsmedium ungeschirmte 2-Drahtleitung für Daten undEnergie

Anzahl Nutzdaten pro Telegramm

5 Bit (Master Slave)4 Bit (Slave Master)

Anzahl Stationen max. 31

Anzahl Eingänge pro Station max. 4 ( => insgesamt max. 124)

Anzahl Ausgänge pro Station max. 4 ( => insgesamt max. 124)

Bitkodierung Modifizierte Manchester-Codierung:Alternierende Puls Modulation

Übertragungsrate 150 kBit/sec

Übertragungssicherheit Identifikation und Wiederholung gestörter

TelegrammeBuszugriffsverfahren Polling

Busverwaltung Monomaster

Eigenschaften (vor Version 2.1)

Page 82: 3.2 Feldbusse

82Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Topologie Linie, Baum, Stern

Buslänge max. 100m (300m mit Repeater)

Übertragungsmedium ungeschirmte 2-Drahtleitung für Daten undEnergie

Anzahl Nutzdaten pro Telegramm

5 Bit (Master Slave)4 Bit (Slave Master)

Anzahl Stationen max. 62

Anzahl Eingänge pro Station max. 4 ( => insgesamt max. 248)

Anzahl Ausgänge pro Station max. 3 ( => insgesamt max. 186)

Bitkodierung Modifizierte Manchester-Codierung:Alternierende Puls Modulation

Übertragungsrate 150 kBit/sec

Übertragungssicherheit Identifikation und Wiederholung gestörter

TelegrammeBuszugriffsverfahren Polling

Busverwaltung Monomaster

Eigenschaften (ab Version 2.1)

Page 83: 3.2 Feldbusse

83Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

3.2.6 EIB

Europäischer Installations Bus

Feldbus für die Gebäudeautomatisierung – das Gebäude als eingebettetes System

Ziel: das intelligente Haus

Heute bereits in Büro- und Industriegebäuden zur zentralen Steuerung von Jalousien etc. implementiert

Page 84: 3.2 Feldbusse

84Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Neben EIB gibt es neben herstellerspezifischen auch weitere offene Systeme, z.B.

LON (Local Operating Network) Technik der Firma Echelon aus den USA

Convergence und Konnex Initiative zur Standardisierung einer EIB-

Weiterentwicklung gemeinsam mit Batibus und EHS (European Home System)

Page 85: 3.2 Feldbusse

85Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Dezentrales Bussystem für die Anwendung in der Gebäudeinstallation Flexible Vernetzung von elektrischen Geräten

wie Schaltern, Lampen, Sensoren etc.

Drei Übertragungsmedien Twisted Pair (verdrillte

Niederspannungsleitung) Powerline (Aufmodulierung auf das Stromnetz) Funk

Häufigste Implementierung: Zweiadrige Busleitung zur Informationsübermittlung als auch zur Spannungsversorgung der Busteilnehmer

EIB-Merkmale:

Page 86: 3.2 Feldbusse

86Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Bussystem in Linien organisiert Jede Linie bis zu 64 Geräte Bis zu 12 Linien über Linienkoppler zu Bereich

zusammengeschlossen Gesamtsystem besteht aus bis zu 15 Bereiche

zulässiger Adressraum von bis zu 11520 Geräten

Datenrate: 9600 Bits/s bei Twisted PairAusreichend für kurze Event- und SteuernachrichtenSprach- oder Bildübertragung ausgeschlossen

Page 87: 3.2 Feldbusse

87Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Übertragungsprotokoll: Physikalische Schicht: Twisted Pair:

Gleichspannung, 28 V, seriell asynchron Sicherungsschicht:

Prüfbyte für jedes TelegrammBestätigung erfolgreich empfangener Telegramme mit ACKCSMA/CA: Kollisionen gleichzeitiger Telegramme werden erkannt

und behoben, der Teilnehmer mit geringerer Priorität zieht zurück Netzwerkschicht: vier Adressierungsarten

Physikalische Adressierung: bei Inbetriebnahme zugeordnete 2-Byte Adresse, spiegelt die Konfiguration wider, für Singlecast verwendet

Broadcast: Adresse 0x0000 richtet sich an alle TeilnehmerGruppenadressierung: 2-Byte Multicast-AdressePolling Adressierung: spezielle Multicast-Adresse an Busknoten

derselben Linie; Abfrage gemeinsamer Statusmeldungen möglich

Page 88: 3.2 Feldbusse

88Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Telegrammaufbau im EIB-System

Page 89: 3.2 Feldbusse

89Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Typisches EIB-Gerät: Buskoppler (physikalischer Buszugriff und 8-Bit-Mikroprozessor für die Protokollsoftware) und Applikationsmodul

Page 90: 3.2 Feldbusse

90Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte

3.2 Feldbusse

Weitere EIB-Anwendungsmodule