michael bauer1 can controller area network kommunikationsnetze
Post on 05-Apr-2015
128 Views
Preview:
TRANSCRIPT
Michael Bauer 1
CANCANCController ontroller AArea rea NNetworketwork
Kommunikationsnetze
Michael Bauer 2
GliederungGliederung
I. Einleitung
II. Grundlegende Eigenschaften des CAN Protokolls
III. Aufbau eines Datenframes
IV. Bitweise Arbitrierung
V. Fehlererkennung und Fehlerbehandlung
Michael Bauer 3
I.I. EinleitungEinleitung
CAN Bussystem auch als Feldbus bezeichnet zur Kommunikation zwischen niedrigen Prozessoren (Sensoren/Aktoren)
Entwicklung von CAN als Autobus Mitte der 80-er Jahre bei der Firma Bosch GmbH und 1985 mit Intel erstmalig in Silizium realisiert
heute hat jeder große Halbleiterhersteller mind. ein CAN Produkt im Angebot
Notwendigkeit der Entwicklung war durch Automobilindustrie gegeben, da immer komplexere Kabelbäume in Fahrzeugen integriert wurdenBeispiel: Kabellänge > 2000m mit Gewicht > 100kg dazu kamen bis zu 600 verschiedene Kabelbäume pro Modell
Michael Bauer 4
I.I. EinleitungEinleitung
1992 erstmalig in Serienmodell (S-Klasse) eingesetzt und heute in fast allen Automobiltypen verwendet, auch im echtzeitkritischen Bereich
weitere Anwendungen: - Verkehrsmittel:
PKW,LKW,Flugzeuge,Züge,Schiffe,
landwirtschaftliche Maschinen, Baumaschinen etc.
- Industriesteuerungen: programmierbare Steuerungen,
Handhabungsautomaten,Roboter,intelligente
Motorsteuerungen,Geldautomaten,Spielzeuge u.v.m.
Michael Bauer 5
II.II. Grundlegende Eigenschaften des Grundlegende Eigenschaften des CAN ProtokollsCAN Protokolls
CAN Protokoll auf OSI Schicht 1 bis 2 baut auf eine Multimaster Hierarchie, das bedeutet bei
defekt eines Knoten läuft das Gesamtsystem trotzdem stabil weiter
Zugriffsverfahren CSMA/CD+CR:CS – Carrier SenseMA – Multiple AccessCD – Collision DetectionCR – Collision ResolutionJeder Knoten wartet bis der Bus frei ist und startet dann die Übertragung, andernfalls erfolgt eine Bitweise Arbitrierung.
Michael Bauer 6
II.II. Grundlegende Eigenschaften des Grundlegende Eigenschaften des CAN ProtokollsCAN Protokolls
Ereignisgesteuerte Kommunikation:
Sobald ein Ereignis auftritt was zu einer zu übertragenden Information führt, sorgt der Teilnehmer für die Übertragung.
Kommunikation ist grundsätzlich Broadcast-orientiert:
- Zugriffssieger sendet grundsätzlich an alle anderen
Knoten, diese prüfen auf Fehler erst dann wird durch
Empfänger geprüft ob für ihn bestimmt
Michael Bauer 7
II.II. Grundlegende Eigenschaften des Grundlegende Eigenschaften des CAN ProtokollsCAN Protokolls
Remote Request – Antwort:
- Nachfrage kann von jedem Knoten ausgelöst werden
- erfolgt über ein „Remote Request Frame“
- gerade aktuelle Daten werden dann gesendet
Michael Bauer 8
II.II. Grundlegende Eigenschaften des Grundlegende Eigenschaften des CAN ProtokollsCAN Protokolls
Grenzwerte des System-Layout:
- 32 Knoten pro System (bei Standard
Leitungstranceivern)
- bis zu 128 Knoten möglich
- 211 Botschaften pro System (CAN 2.0A)
- 229 Botschaften pro System (CAN 2.0B)
- 0 bis 8 Byte Daten pro Botschaft
- 117 Bits pro Botschaft (CAN 2.0A)
- 136 Bits pro Botschaft (CAN 2.0B)
- Bit-Rate programmierbar zwischen 5kBit/s und 1MBit/s
Michael Bauer 9
II.II. Grundlegende Eigenschaften des Grundlegende Eigenschaften des CAN ProtokollsCAN Protokolls
Leitungstreibereigenschaften
- Differential mode (+NRZ):
zwei Signalleitungen die mit komplementären Signalen
- Unsymmetrische Übertragung (+NRZ):
nur eine Signalleitung
- Gleichspannungsloser Betrieb:
Transformatorkopplung zur Unterdrückung
unterschiedlicher Erdungspotentiale
Michael Bauer 10
III.III. Aufbau eines DatenframesAufbau eines Datenframes
Format nach CAN 2.0A
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER1 CONTROL1 DATA(Byte)
1 1 15 1 1 1 7 311 2 0-8
IDENTIFIER2
18
CONTROL2
6
Format nach CAN 2.0B
Michael Bauer 11
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
SOF
1
Michael Bauer 12
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Michael Bauer 13
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Michael Bauer 14
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Arbitrierung
Michael Bauer 15
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Michael Bauer 16
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Michael Bauer 17
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Michael Bauer 18
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Michael Bauer 19
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Michael Bauer 20
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Michael Bauer 21
III.III. Aufbau eines DatenframesAufbau eines Datenframes
SOF: Start of Frame Identifier:Kennzeichnung und Priorität der Nachricht RTR: Remote Transmission Request Bit Control: Datenlänge und Extended ja/nein Data: Daten CRC: x15+ x14+ x10+ x8+ x7+ x4+ x3+1 DEL: Begrenzungsbit ACK: Bestätigungsbit/Bestätigungsslot EOF: End of Frame IFS: Interframe Space Bits minimaler Abstand zum nächsten
Frame
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER CONTROL DATA(Byte)
1 1 15 1 1 1 7 311 6 0-8
Michael Bauer 22
III.III. Aufbau eines DatenframesAufbau eines Datenframes
Standardformat und erweitertes Format sind kompatibel zueinander
Unterscheidung durch zwei Bits SRR und IDE Bit Substitute Remote Request Bit ersetzt RTR und bedeutet, dass ein Standardformat prinzipiell Höherprior ist Identifier Extension Bit kennzeichnet Extended Format
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER1 CONTROL1 DATA(Byte)
1 1 15 1 1 1 7 311 2 0-8
IDENTIFIER2
18
CONTROL2
6
SOF
RTR
IFS
EOF
DEL
ACK
DEL
CRC
IDENTIFIER1 CONTROL1 DATA(Byte)
1 1 15 1 1 1 7 311 2 0-8
IDENTIFIER2
18
CONTROL2
6
Michael Bauer 23
IV.IV. Bitweise ArbitrierungBitweise Arbitrierung
Wenn mehrere Teilnehmer gleichzeitig auf den Bus zugreifen, wird in einer Auswahlphase (Arbitrierung) entschieden wer am Bus bleiben darf.
Arbitrierungsfeld besteht aus RTR-Bit + Identifier jeder Knoten liest den aktuellen Wert des
Kommunikationsmedium und vergleicht mit dem gesendeten wenn Vergleich negativ ausfällt schaltet er sofort auf
Empfang physikalische Grundlage sind dominante bzw. rezessive
Buspegel („wired and“, „open collector“), d.h. das dominante Bit überschreibt das rezessive
00...00 ist also höchstpriore und 11...11 ist die am wenigsten wichtige Botschaft
Michael Bauer 24
IV.IV. Bitweise ArbitrierungBitweise Arbitrierung
Beispiel:
SOF
RTR
IDENTIFIER1 DATA(Byte)
1 1 0-8
CONTROL
610 9 8 7 6 5 4 3 2 1 0
Teilnehmer 1
Teilnehmer 2
Teilnehmer 3
Buspegel
Arbitrierungsphase
Michael Bauer 25
IV.IV. Fehlererkennung und Fehlererkennung und FehlerbehandlungFehlerbehandlung
Jeder erkannte Fehler wird allen Teilnehmer mitgeteilt, welche die empfangene Botschaft verwerfen.
Gesendet wird ein sogenanntes Errorframe, welches durch alle Teilnehmer erkannt wird.
Damit der Bus bei einer lokalen Störung eines Teilnehmers nicht dauerhaft belegt wird, zieht sich dieser nach und nach vom Busgeschehen zurück.
Part ofData Frame
6-Bit ActiveError Flag
0-6-Bits ActiveError Flag
8 Bits of ErrorDelimiter
Active Error Frame
Michael Bauer 26
IV.IV. Fehlererkennung und Fehlererkennung und FehlerbehandlungFehlerbehandlung
1. Bit-Fehler:
empfangenes Bit gesendetes Bit außer Arbitrierungsphase bzw. Acknowledgement
2. Bit-Stuffing-Fehler:
mehr als 5 aufeinanderfolgende gleiche Bits zwischen Start of Frame und CRC-Delimiter
3. CRC-Fehler:
CRC Prüfsumme stimmt nicht 4. Format-Fehler:
Verletzung des Datenformats 5. Acknowledgement-Fehler:
während des Acknowledgement Slot kein dominantes Bit empfangen
Michael Bauer 27
IV.IV. Fehlererkennung und Fehlererkennung und FehlerbehandlungFehlerbehandlung
Reihenfolge der Fehlerbehandlung:
1. Fehler wird erkannt
2. Errorframe wird von jedem Teilnehmer der den Fehler erkennt gesendet.
3. Telegramm wird von allen verworfen.
4. Fehlerzähler wird bei jedem Teilnehmer in entsprechender Weise beeinflusst.
5. Telegramm wird erneut komplett gesendet.
Michael Bauer 28
LiteraturLiteratur
Wolfhard Lawrenz (Hrsg.): CAN Controller Area Network, 3., bearbeitete Auflage, Hüting Verlag 1999
Konrad Etschberger: CAN Controller-Area-Network, Carl Hanser Verlag 1994
Robert Bosch GmbH: CAN Specification, Version 2.0, Sep. 1991
Michael Bauer 29
FIN
top related