Controller Area Network

Der CAN-Bus (Controller Area Network) gehört zu den Feldbussen.

Es handelt sich dabei um ein asynchrones, serielles Bussystem, das 1983 von Bosch für die Vernetzung von Steuergeräten im Automobil entwickelt und 1985 zusammen mit Intel vorgestellt wurde, um die Kabelbäume (bis zu 2 km pro Fahrzeug) zu reduzieren und dadurch Gewicht zu sparen.

Funktion

Übertragungsverfahren

Der CAN-Bus arbeitet nach dem CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance) Verfahren (nicht zu verwechseln mit CSMA/CD wie beim Ethernet). Dabei werden Kollisionen beim Buszugriff durch die Arbitrierung oder Bit-Arbitrierung vermieden (siehe unten). Die Daten sind NRZ-L kodiert. Des Weiteren kommt zur Datensicherung die Zyklische Redundanzprüfung (ZRP bzw. engl. CRC) zum Einsatz. Zur fortlaufenden Synchronisierung der Busteilnehmer wird Bitstopfen (bit stuffing) verwendet (siehe unten). Der Bus ist entweder mit Kupferleitungen oder über Glasfaser ausgeführt. Zur schnellen Datenübertragung zwischen den Steuergeräten wird in der Kfz-Technik das CAN-Bussystem verwendet. Der CAN-Bus arbeitet nach dem "Multi-Master Prinzip": Mehrere gleichberechtigte Steuergeräte (=Busteilnehmer) sind durch eine topologische Anordnung (siehe unten) miteinander verbunden.

Im Falle von Kupferleitungen arbeitet der CAN-Bus mit Differenzsignalen. Er wird normalerweise mit 3 Leitungen ausgeführt: CAN_HIGH, CAN_LOW und CAN_GND (Masse). CAN_LOW enthält den komplementären Pegel von CAN_HIGH gegen Masse. Dadurch können Gleichtaktstörungen unterdrückt werden, da ja die Differenz gleich bleibt.

Die Übertragung der Daten erfolgt so, dass ein Bit, je nach Zustand, entweder dominant oder rezessiv auf den Busleitungen wirkt. Ein dominantes überschreibt dabei ein rezessives Bit.

Übertragungsrate und Leitungslänge

Es wird zwischen einem Highspeed und einem Lowspeed Bus unterschieden. Bei einem Highspeed Bus beträgt die maximale Datenübertragungsrate 1Mbit/s, bei Lowspeed 125kBit/s.

Die maximale (theoretische) Leitungslänge beträgt z.B. bei 1Mbit/s 40m, bei 500kBit/s sind 100m möglich und bei 125kBit/s 500m. Diese Maximalwerte beruhen darauf, dass die Zeit, die ein Signal am Bus anliegt (Bitzeit, Bit/Sekunde), umso kürzer ist, je höher die Übertragungsrate ist. Mit zunehmender Leitungslänge steigt jedoch die Zeit, die ein Signal braucht, bis es am anderen Ende des Busses angekommen ist (Ausbreitungsgeschwindigkeit). Daher darf die Zeit, die ein Signal am Bus liegt, nicht kürzer sein als die Zeit, die ein Signal braucht, um sich auszubreiten. Zu beachten ist, dass sich das Signal nicht nur ausbreitet, sondern auch innerhalb der Signalzeit der Empfänger auf den Sender reagieren muss (siehe ACK).Der Sender muss wiederum die eventuelle Buspegeländerung des/der Empfänger mitbekommen (siehe auch Arbitrierung). Deshalb ist die max. Leitungslänge etwas komplexer zu berechnen. Es müssen Verzögerungszeiten auf der Leitung, des Tranceiver (Sender und Empfänger), des Controllers (Sender und Empfänger) und der gesetzte Abtastzeitpunkt (Sender und Empfänger) berücksichtigt werden. Die Formel zur Berechnung und nähere Informationen entnehmen Sie bitte der Literatur.

Als Busmedium werden nach ISO11898-2 (High-Speed Medium Access Unit) Twisted-Pair-Kabel mit einem Wellenwiderstand von 108...132 Ohm empfohlen.

Die maximale Teilnehmeranzahl auf physikalischer Ebene hängt von den verwendeten Bustreiberbausteinen (Transceiver, physikalische Anschaltung an den Bus) ab. Mit gängigen Bausteinen sind 32, 64 oder bis zu 110 (mit Einschränkungen bis zu 128) Teilnehmer pro Leitung möglich (Erweiterungsmöglichkeit über Repeater oder Bridge).

Topologie

Das CAN-Netzwerk wird als Linienstruktur aufgebaut. Stichleitungen sind in eingeschränktem Umfang zulässig. Des weiteren sind auch ein ringförmiger Bus (Infotainment Bereich) sowie ein sternförmiger Bus (Zentralverrieglung) möglich. Beide Varianten haben im Vergleich zum linienförmigen Bus jeweils einen Nachteil:

Im ringförmigen Bus sind alle Steuergeräte in Reihe geschaltet, so daß bei einem Ausfall eines Steuergeräts der gesamte Bus ausfällt.
Der sternförmige Bus wird meist von einem Zentralrechner gesteuert, da diesen alle Informationen passieren müssen, mit der Folge, daß bei einem Ausfall des Zentralrechners keine Informationen weitergeleitet werden können. Bei einem Ausfall eines einzelnen Steuergeräts funktioniert der Bus weiter.

Der lineare Bus hat den Vorteil, daß alle Steuergeräte parallel zu einer zentralen Leitung gehen. Nur wenn diese ausfällt, funktioniert der Bus nicht mehr.

Bei einem Highspeed Bus müssen zusätzlich 2 Abschlusswiderstände von je 120 Ohm (zwischen CAN_HIGH und CAN_LOW) an dem jeweiligen Ende verwendet werden.

Objektidentifier

Der Objektidentifier kennzeichnet den Inhalt der Nachricht, nicht das Gerät. Zum Beispiel kann in einem Messsystem den Parametern Temperatur, Spannung, Druck jeweils ein eigener Identifier zugewiesen sein. Die Empfänger entscheiden anhand des Identifiers, ob die Nachricht für sie relevant ist oder nicht.

Zudem dient der Objektidentifier auch der Priorisierung der Nachrichten.

Die Spezifikation definiert zwei verschiedene Identifier-Formate:

11-bit Identifier, auch "Base frame format" genannt.
29-bit Identifier, auch "Extended frame format" genannt.

Ein Teilnehmer kann Empfänger und Sender von Nachrichten mit beliebig vielen Identifiern sein, aber umgekehrt darf es zu einem Identifier immer nur maximal einen Sender geben (damit die Arbitrierung funktioniert).

Arbitrierung (Aushandeln des Medienzugriffs), Priorität

Der Buszugriff wird verlustfrei mittels der bitweisen Arbitrierung auf Basis der Identifier der zu sendenden Nachrichten aufgelöst. Dazu sensiert jeder Sender den Bus, während er gerade den Identifier sendet. Senden zwei Teilnehmer gleichzeitig, so überschreibt das erste dominante Bit eines der beiden, das entsprechend rezessive des anderen, welcher dieses erkennt und seinen Übertragungsversuch beendet, damit der andere seine Daten übertragen kann. Verwenden beide Teilnehmer den gleichen Identifier wird ein Error-Frame erzeugt (siehe Frame-Aufbau). Daher empfiehlt der Standard, dass ein Identifier auch nur von maximal einem Teilnehmer verwendet werden soll.

Durch dieses Verfahren ist auch eine Hierarchie der Nachrichten untereinander gegeben. Die Nachricht mit dem niedrigsten Identifier darf "immer" übertragen werden. Für die Übertragung von zeitkritischen Nachrichten kann also ein Identifier hoher Priorität (= niedrige ID, z.B. 0) vergeben werden, um ihnen so Vorrang bei der Übertragung zu gewähren. Dennoch kann selbst bei hochprioren Botschaften der Sendezeitpunkt zeitlich nicht genau vorher bestimmt werden (nichtdeterministisches Verhalten).

Folien zur Erläuterung der Arbitrierung

can-dataframe.jpg

Frame-Aufbau

Es gibt vier verschiedene Arten von Frames

Daten-Frame dient dem Transport von bis zu 8 Oktetten Daten
Remote-Frame dient der Anforderung eines Daten-Frames von einem anderen Teilnehmer
Error-Frame signalisiert allen Teilnehmern eine erkannte Fehlerbedingung in der Übertragung
Overload-Frame dient als Zwangspause zwischen Daten- und Remote-Frames

Ein Daten-Frame ist logisch wie folgt aufgebaut:

Start of Frame (SOF) = ein dominantes bit
Arbitrierungsfeld bestehend aus einem Identifier-Segment (11 bit oder 29+2 bit) plus einem RTR bit (Remote Transmission Request, siehe unten )
Kontrollfeld (CTRL) = 6 bit (2 bit reserviert + 4 bit Länge der Daten)
Datenfeld (DATA) = 0-64 bit (in Einheiten von 8 bit)
Prüfsummenfeld (CRC) = 16 bit (15 bit CRC plus einem rezessiven CRC-Delimiter bit)
Bestätigungsfeld (ACK) 2 bit, bestehend aus einem ACK-Slot (siehe untenstehende Erläuterung) plus einem rezessiven ACK-Delimiter
End of Frame (EOF) 7 bit (rezessiv)
Intermission (IFS - Intermission Frame Space) = 3 bit (=min. Anzahl der Bits die aufeinanderfolgende Botschaften trennt)

Bitstopfen (bit stuffing) kann die physikalische Länge eines Frames vergrößern. Beim Bitstopfen wird nach fünf gleichpoligen Bits ein komplementäres Bit (sog. Stopfbit) in den logischen Bitstrom eingefügt. Bitstopfen wirkt auf Start of frame (SOF) bis einschließlich Prüfsummenfeld (CRC) von Daten- sowie Remote-Frames und dient der Nachsynchronisation der Teilnehmer innerhalb eines Frames.

RTR (Remote Transmission Request)

Ein gesetztes RTR-Bit kennzeichnet einen Remote-Frame (rezessiv). Mit Hilfe eines Remoteframe kann ein Teilnehmer einen anderen auffordern, seine Daten zu senden.

Im Falle eines "Extended Identifiers" (siehe oben), wird das RTR-Bit durch das SSR-Bit (Substitute Remote Request) ersetzt und ebenfalls rezessiv gesendet. In diesem Fall wird das nachfolgende IDE-Bit ebenfalls rezessiv gesendet, wodurch ein "Extended Identifier" signalisiert wird. Im Anschluss werden die restlichen 18 Bit des Identifiers und anschließend das eigentliche RTR-Bit gesendet. Das IDE-Bit zählt hierbei logisch zum "Arbitrierungsfeld", wobei das Kontrollfeld aber weiterhin aus 6 Bit besteht.

Die Datenlänge muss entsprechend der zu erwartenden Datenlänge gesetzt werden (Fehlerquelle: Viele Entwickler setzen die Datenlänge = 0 - dies ist falsch; ebenso sind CAN-Controller am Markt, welche RTR-Frames nur mit der Datenlänge 0 senden können). Der Objectidentifier ist derselbe, wie der der angeforderten Nachricht.

ACK-Slot

Der Acknowledge-Slot wird verwendet, um den Empfang eines korrekten CAN-Frames zu quittieren. Jeder Empfänger, der keinen Fehler feststellen konnte, setzt einen dominanten Pegel an der Stelle des ACK-Slots und überschreibt somit den rezessiven Pegel des Senders.

Sampling

CAN-Controller können den Bus einmal oder dreimal pro Bit abtasten. Beim 3fach-sampling entscheidet die Mehrheit über den aktuellen Zustand (dominant = 0 oder rezessiv = 1).

Synchronisierung und Zeitquanten

Ein Bit wird in sog. Zeitquanten unterteilt. Sie entsprechen einem Vielfachen des Controllertaktes. In jedem Zeitquantum wird nur einmal abgetastet. Eine Flanke wird erkannt, wenn der Abtastwert vor dem Zeitquantum einen anderen Wert hat als der Wert danach. Die Nachsynchronisierung synchronisiert somit nur auf ein Zeitquantum und nicht auf die Flanke. Sync_Seg Prop_Delay Phase_Seg1 und 2

Sicherung der Daten

Erkennt ein Empfänger eine Fehlerbedingung, sendet er einen Error-Frame und veranlasst so alle Teilnehmer, den Frame zu verwerfen. Sollten andere Teilnehmer diese Fehlerbedingung nicht erkannt haben, senden sie ihrerseits direkt im Anschluss ein weiteres Error-Frame. Hiermit wird eine weitere Sicherheitsfunktion des CAN Protokolls möglich. Um zu vermeiden, dass einzelne Teilnehmer durch irrtümlich erkannte Fehlerbedingungen dauerhaft den Nachrichtentransport blockieren, enthält jeder Teilnehmer Fehlerzähler. Diese Zähler erlauben nach den Regeln der Spezifikation, einen fehlerhaft arbeitenden Teilnehmer in zwei Stufen des Betriebszustands vom Bus zu trennen, wenn er wiederholt Fehler erkennt, welche andere Teilnehmer nicht erkennen oder wiederholt fehlerhafte Frames versendet. Die Zustände nennen sich error active (normal), error passive (Teilnehmer darf nur noch passive - das heißt rezessive - Error-Frames senden) und bus off (Teilnehmer darf nicht mehr senden).

Der Sender wiederholt nach dem Error-Frame seine Datenübertragung. Auch der Sender kann durch die zuvor erwähnten Fehlerzähler vom Bus getrennt werden, wenn die Datenübertragung dauerhaft fehlschlägt. Verschiedene Fehlerfälle führen zu einer unterschiedlich großen Erhöhung des Fehlerzählers.

CANopen/DeviceNet

CANopen und DeviceNet sind auf CAN basierende Schicht-7-Kommunikationsprotokolle, welche hauptsächlich in der Automatisierungstechnik verwendet werden.

Das Verbreitungsgebiet von CANopen ist dabei mehr Europa. Es wurde vorwiegend von deutschen klein- und mittelständischen Firmen initiiert und im Rahmen eines Esprit Projektes unter Leitung von Bosch erarbeitet. Seit 1995 wird es von der CiA^* gepflegt und ist inzwischen als Europäische Norm EN 50325-4 standardisiert.

DeviceNet hingegen ist mehr in Amerika verbreitet. Es wurde von Allen-Bradley(gehört zu Rockwell Automation^* (Open DeviceNet Vendor Association) übergeben.

Das im maritimen Bereich sich langsam ausbreitende Protokoll NMEA2000 der NMEA Organisation ist eine Erweiterung von SAE J1939.

CleANopen

Eine Arbeitsgruppe der internationalen Nutzer- und Herstellervereinigung CAN in Automation (CiA), die CANopen Special Interest Group (SIG) "Municipal Vehicles" entwickelt das CANopen Anwendungsprofil für Abfallsammelfahrzeuge (CleANopen) ^*.

weitere Quellen

Literatur

Wolfhard Lawrenz (Hrsg.): CAN Controller Area Network - Grundlagen und Praxis. Hüthig, ISBN 3-7785-2780-0
Konrad Etschberger (Hrsg.): CAN Controller Area Network - Grundlagen, Protokolle, Bausteine, Anwendungen. Hanser, ISBN 3-446-19431-2
Horst Engels : CAN-Bus - Technik einfach, anschaulich und praxisnah vorgestellt. Franzis, ISBN 3-7723-5146-8
Werner Zimmermann / Ralf Schmidgall : Bussysteme in der Fahrzeugtechnik - Protokolle und Standards. Vieweg, ISBN 3-8348-0166-6

Automatisierungstechnik | Automobilelektronik | Bussystem | Kraftfahrzeugtechnik

Gourt Home::Gourt :: Controller Area Network