Controller Area Network
Es handelt sich dabei um ein asynchrones, serielles Bussystem, das seit 1983 von Bosch für die Vernetzung von Steuergeräten im Automobil entwickelt wird 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- (Carrier Sense Multiple Access) Verfahren (vergleiche Ethernet). Die Daten sind NRZ-L codiert. Des Weiteren kommt zur Datensicherung das CRC-Verfahren zum Einsatz. Zur fortlaufenden Synchronisierung der Busteilnehmer wird Bit-Stuffing verwendet (siehe unten). Der Bus ist entweder mit Kupferleitungen oder über Glasfaser ausgeführt. 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.
Übertragungsrate und Leitungslänge
Die maximale Datenübertragungsrate beträgt 1Mbit/s. Dabei ist eine maximale Leitungslänge von 40m möglich. Bei 500kBit/s sind zum Beispiel 100m möglich und bei 125kBit/s 500m. Als Busmedium werden nach ISO1189811898-2 (High-Speed Medium Access Unit) Twisted-Pair-Kabel mit einem Wellenwiderstand von 108...132 Ohm empfohlen. Alle Teilnehmer kommunizieren mit der gleichen Baudrate.
Topologie
Das CAN-Netzwerk wird als Linienstruktur mit 2 Abschlusswiderständen von je 120 Ohm (zwischen CAN_HIGH und CAN_LOW) aufgebaut. Stichleitungen sind in eingeschränktem Umfang zugänglich.Objectidentifier
Der Objectidentifier 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 "Basic CAN frame" genannt
- 29-bit Identifier, auch "Extended CAN frame" genannt
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.
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 im Gegensatz zum FlexRay Bussystem zeitlich nicht genau vorher bestimmt werden (nichtdeterministisches Verhalten).
Folien zur Erläuterung der Arbitrierung
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
- 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 rezessiven ACK-Slot plus einem rezessiven ACK-Delimiter
- End of Frame (EOF) 7 bit (rezessiv)
- Intermission = 3 bit (=min. Anzahl der Bits die aufeinanderfolgende Botschaften trennt)
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.
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 zu quittieren. Jeder Empfänger, der keinen Fehler feststellen konnte, setzt einen dominanten Pegel an der Stelle des ACK-Slots.
Sampling
Bei manchen Controllern ist es möglich 3 Samplepoints zu verwenden. Mehrheit siegt und gibt den aktuellen Wert an.
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 wie 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.
CANopen/DeviceNet
CANopen und DeviceNet[1] 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[1] gepflegt und ist inzwischen als Europäische Norm EN 50325-4 standardisiert.
DeviceNet hingegen ist mehr in Amerika verbreitet. Es wurde von Allen-Bradley[1] (gehört zu Rockwell Automation[1]) entwickelt und später als offener Standard an die ODVA[1] (Open DeviceNet Vendor Association) übergeben.
Das im maritimen Bereich sich langsam ausbreitende Protokoll NMEA2000 der NMEA Organisation ist eine Erweiterung von SAE J1939.
weitere Quellen
- Bosch CAN homepage
- ISO 11898-1:2003 Road vehicles — Controller area network — Part 1: Data link layer and physical signalling
- ISO 11898-2:2003 Road vehicles — Controller area network — Part 2: High-speed medium access unit
- ISO 11898-3:2005 Road vehicles — Controller area network — Part 3: Low-speed, fault-tolerant, medium dependent interface
- ISO 11898-4:2004 Road vehicles — Controller area network — Part 4: Time-triggered communication
- CAN wiki (Englisch)
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
