Zeltwanger Titelei - VDE
Werbung
3 CAN-Protokoll
Die Entwicklung des CAN-Protokolls begann 1983 bei der Robert Bosch GmbH.
Das Entwicklungsziel war der Einsatz eines Kommunikationssystems für den Einsatz im Antriebsstrang von Kraftfahrzeugen. Dabei standen vor allem folgende
Randbedingungen im Vordergrund:
• geringe Ausdehnung des gesamten Netzwerks
• schnelle Übertragung von kleinen Datenmengen
• Ausfallsicherheit
• integrierte Fehlerbehebung
• geringe Kosten
Diese Randbedingungen sollte man sich immer wieder in das Gedächtnis rufen,
wenn man über den Einsatz eines CAN-basierenden Systems nachdenkt. Im Jahre
1985 wurde die erste CAN-Spezifikation fertig gestellt, und bereits ein Jahr später
erfolgte die Realisierung der ersten CAN-Chips durch die Firma Intel (82526). Seit
1988 stand der erste in Serie gefertigte CAN-Controller zur Verfügung. Ab 1989
lieferte Philips Semiconductors ebenfalls einen CAN-Controller (82C200).
Serielle Bussysteme arbeiten immer nach demselben Schema: Ein Sender prägt die
zu übertragende digitale Information Bit für Bit einem Übertragungsmedium auf.
Potentielle Empfänger tasten das Übertragungsmedium ab und wandeln die seriell
transferierte Information wieder in ein maschineninternes, paralleles Datum um.
Unterschiede zwischen verschiedenen physikalischen Schnittstellen beruhen überwiegend auf der Interpretation der Buspegel. In CAN-Netzwerken unterscheidet
man dominante und rezessive Buspegel, wobei der dominante den rezessiven Pegel
überschreibt (Bild 8). Wenn gleichzeitig von verschiedenen Busstationen dominante und rezessive Buspegel gesendet werden, stellt sich am Bus der dominante Pegel
ein. Der rezessive Pegel kann sich nur einstellen, wenn er gleichzeitig von sämtlichen Busstationen gesendet wird. Der rezessive Pegel hat den logischen Wert 1, der
dominante den logischen Wert 0.
Die physikalische Darstellung von dominanten und rezessiven Bits auf dem Busmedium ist eine Grundvoraussetzung für das CAN-Buszugriffsverfahren und für die
Fehlermitteilung. Bild 8 zeigt einen einfachen Bustreiber für CAN (Open-Kollektor-Kopplung). Der rezessive Pegel auf der Busleitung beträgt 5 V, der dominante
Pegel entspricht der Sättigungsspannung der Transistoren und beträgt nahezu 0 V.
Das Bild zeigt die Entstehung dominanter und rezessiver Pegel. Außerdem entspricht die Polarität des physikalischen Signalverlaufs dem logischen Signalverlauf.
Es ist empfehlenswert, zur Veranschaulichung der Busvorgänge bei CAN stets die-
23
se Schaltung zu verwenden. Die Erzeugung rezessiver und dominanter Pegel ist allerdings auf verschiedene Arten möglich (u. a. auch auf optischen Medien).
%LOG Dominante und rezessive Pegel
3.1 Telegramm-Formate
Um die übertragene Information am Bus sinnvoll erkennen zu können, muss sie in
einem bestimmten definierten Format verpackt werden (Bild 9). Ein solches Format
wird durch einen Frame (Rahmen) beschrieben. Insgesamt gibt es vier verschiedene
Bild 9 Format des Datentelegramms
24
Telegrammarten: Datentelegramm, Remote-Telegramm, Fehlertelegramm und
Überlasttelegramm.
Das SOF-Bit (Start of Frame) kennzeichnet den Beginn eines Daten- oder oder Remote-Telegramms. Die rezessiv-dominante Flanke des SOF-Bits wird von den anderen Teilnehmern im System zur Synchronisation genutzt. Daran schließt sich das
Identifier-Feld an. Mit diesem Feld wird die zu übertragende Nachricht eindeutig
gekennzeichnet. Der Zahlenwert des Identifiers legt gleichzeitig die Priorität für die
Busvergabe fest. Diese Nachrichtenkennung muss deshalb entsprechend der Wichtigkeit im Gesamtsystem festgelegt werden. Für Standardrahmen ist hier ein Wert
zwischen 0 und 2047 möglich. Das nächste Bit (RTR: Remote Transmission Request) in der Nachricht ermöglicht eine Unterscheidung zwischen Daten- und Remote-Telegramm. Bei einem Datentelegramm ist dieses Bit stets dominant. Es ist
darauf zu achten, dass in einem Netzwerk niemals zwei Knoten gleichzeitig eine
Nachricht mit demselben Identifier, aber unterschiedlichen Dateninhalten senden.
Der Bereich des Steuerfelds (Control Field) besteht aus den reservierten Bits r1, r0
sowie dem 4-bit DLC (Data Length Code). Der DLC gibt an, wie viele Bytes im Datenfeld der entsprechenden Nachricht übertragen werden. Der Wertebereich beträgt
DLC = {0 ... 8}. Wird ein höherer Wert eingetragen, so darf dieser Wert auch über
den Bus übertragen werden. Die maximale Länge des Datenfelds der CAN-Nachricht wird aber trotzdem auf acht Bytes begrenzt. Dieses Verhalten sollte bei einer
Auswertung der Nachricht unbedingt beachtet werden.
Das Datenfeld trägt die eigentliche Nutzinformation, die durch die Nachricht übertragen wird (0 bis 8 Bytes). Die Übertragung beginnt mit dem ersten Byte, und innerhalb eines Bytes mit dem höchstwertigen Bit (MSB: Most Significant Bit). An
das Datenfeld schließt sich das CRC-Feld (CRC: Cyclic Redundancy Check) an. Es
besteht aus der CRC-Sequenz und dem CRC-Delimiter. Mit Hilfe der CRC-Sequenz können die Empfänger verfälschte Nachrichten erkennen (siehe unten). Im
ACK-Feld (ACK Slot + ACK Delimiter; ACK: Acknowledgement) überträgt der
Sender einer Nachricht im ACK-Slot einen rezessiven Pegel. Empfänger, die die
Nachricht bis dahin korrekt empfangen haben, bestätigen dies durch Senden eines
dominanten Pegels. Der Pegel-Wert des ACK-Slots gibt nur an, ob gar keiner oder
mindestens ein Empfänger die aktuelle Nachricht richtig empfangen hat. Der ACKMechanismus dient deshalb nur zur Ausfallerkennung, aber nicht zur Fehlermeldung. Abgeschlossen wird jede Nachricht mit einer EOF-Kennung (EOF: End of
Frame). Diese EOF-Kennung für die Nachricht ist 7 bit lang (rezessiv). Während
der Übertragung der EOF-Kennung besteht letztmalig die Chance, während der
Übertragung aufgetretene Fehler zu melden.
Nach der Endekennung muss noch das Intermission-Feld (ITM) eingefügt werden,
bevor mit der Übertragung der nächsten Nachricht begonnen werden kann. Das In-
25