Controller Area Network
CAN-Bus
(Controller Area Network) gehört zu den Feldbussen.
Serielles Bussystem, das von BOSCH für die KFZ-Automatisierung entwickelt wurde, um die Kabelbäume (bis zu 2km) zu reduzieren und dadurch Gewicht zu sparen.
Es können beliebige Geräte an den Bus angeschaltet werden, wenn sie die Spezifikationen erfüllen. Bisher existieren 2 Normen:
CAN20 A (11bit Objectidentifier) (--> theor. 2048 Teilnehmer)
CAN20 B (27bit Objectidentifier) (--> theor. 134217728 Teilnehmer)
Funktion
Übertragungs Verfahren
Der CAN-Bus arbeitet nach dem CSMA- (Carrier Sense Multiple Access) Verfahren (vgl. Ethernet). Die Daten sind [[[NRZ]]] -L codiert. Weiters wird zur Datensicherung Bit-stuffing verwendet (siehe unten).
Objectidentifier
Der Objectidentifier kennzeichnet die Nachricht,und ist keine Geräteadresse! Das heißt, das zum Beispiel in einem Messsystem einer Temperatur, Spannung, Drehzahl ein eigener Identifier zugewiesen. Dieses System ermögicht es jedem Teilnehmer, die für sich relevanten Daten anhand des Identifiers vom Bus zu nehmen, oder nicht.
Gleichzeitig dient der OI auch zur Festlegung der Sendeberechtigung bei gleichzeitiger Übertragung (Kollision) durch den Prozess der sog. bitweisen Arbitrierung.
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.
Arbitrierung der Daten, Priorität
Gleichzeitig mit dem Senden lauscht jeder Sender auch auf den Bus. Senden nun 2 Teilnehmer gleichzeitig, so überschreibt das erste dominante Bit eines der beiden, das entsprechend rezessive des anderen, welcher das erkennt und seine Übertragung beendet, damit der andere seine Daten übertragen kann. (=bitweise Arbitrierung)
Durch dieses Verfahren ist auch eine Hierarchie der Nachrichten untereinander gegeben. Die Nachricht mit dem höchsten Identifier darf "immer" übertragen werden. (Was von vorteil ist, wenn z.B. das ABS auslösen soll...)
Sicherung der Daten
Der CAN-Bus erreicht Bitfehlerraten (BER Bit Error Rate) in der Größenordnung von 0.00003. Zum einen verwendet man eine CRC (Cyclic Redundency Check = Prüfsumme) von 15Bit und zum anderen "Bit-stuffing". Dabei wird nach 5 rezessiven bits ein dominantes bit eingefügt, um die Konsistenz zu wahren, und keinen Fehler vorzutäuschen.
Im Falle einer von einem Empfänger erkannten Kollision sendet dieser einen Error-Frame aus, und veranlasst so alle Teilnehmer am Bus, den Frame zu verwerfen. Der Sender hat die Möglichkeit, sofort nach dem Errorframe seine Daten zu wiederholen. (im Standard werden noch aktive und passive Error-Frames unterschieden)
Frame Aufbau
Ein Frame enthält:
- Start of Frame (SOF) = ein dominantes bit
- Arbitrierungsfeld (Objectidenttifier [OI]) = 12 (28) bit (11 [27] bit + 1 RTR [=Remote Transmission Request] sh. unten)
- Kontrollfeld (CTRL) = 6 bit (2 bit reserviert + 4 bit Länge der Daten, entfällt bei Remote-Frame sh. unten)
- Datenfeld (DATA) = 0-64 bit
- Prüfsumme (CRC) = 16 bit (15 bit CRC + 1 bit dom. = CRC-Delimiter)
- Bestätigung (ACK, Acknowledge) = 2 bit (1 bit rez. = ACK-Slot + 1 bit dom. = ACK-Delimiter)
- End of Frame (EOF) = 7 bit rez.
- Intermission = 3 bit (=min. Anzahl der Bits die aufeinanderfolgende Botschaften trennt)
danach ist der Bus wieder im Idle-Modus und der nächste darf senden.
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.
Das CTRL-Feld wird ignoriert. Datenlänge = 0. 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.
weitere Quellen
Für weitere Informationen sei hier auf den Standard verwiesen, der im Internet relativ leicht auffindbar ist.