Kontakt
Impressum

CAN-Bus

CAN ist die Abkürzung für Controller Area Network und wurde als Bus für Kommunikation im Controller-Netzwerk entwickelt. Es ist möglich mittels CAN-Bus-Telegramm ohne vielstufige Abstraktion hardwarenah zu programmieren.

Der CAN-Bus wurde 1983 von der Firma Bosch entwickelt. Bosch und Intel haben den Bus gemeinsam im Jahre 1985 zur Vernetzung von Steuergeräten in Automobilen vorgestellt. Hauptidee war eine verringerte Kabellänge zur Gewichtsreduzierung. Anfang 1991 wurde der CAN-Bus zum ersten Mal in der Mercedes S-Klasse serienmäßig eingebaut. Seit 2001 findet der CAN-Bus auch in Kleinwagen Verwendung.

Der CAN-Bus ist ein asynchroner serieller Bus von der Kategorie Feldbusse. Besondere Eigenschaft eines Feldbusses ist seine Flexibilität hinsichtlich der Geschwindigkeit, die Baudraten von einigen kBit bis 1 MBit ermöglicht. In Kraftwagen wird in der Regel ein schnellerer Bus für Motor und Sicherheitssteuerung getrennt von einem langsameren Bus für die Komfort-Elektronik verbaut.

Verschiedene Maßnahmen zur Fehlerbehandlung machen den CAN-Bus in besonders hohem Grad fehlerfrei. Zum Beispiel garantiert das realisierte CRC-Polynom in CAN-Bus eine theoretische Hamming-Distanz von 6. Dies bedeutet, dass fünf zufällig verteilte Bit-Fehler in einem Frame erkannt werden können. Nach genaueren Berechnungen ist die Wahrscheinlichkeit eines unerkannten Fehlers etwa 1 in 1000 Jahren.

CAN-Bus und OSI-Referenzmodel

Das als Designgrundlage geltende OSI-Referenzmodel für die Kommunikationsprotokolle reduziert sich im Falle vom CAN (Abbildung) auf drei Schichten. Hier sind anwendungsbedingt die Schichten Vermittlung, Transport, Sitzung und Darstellung nicht relevant. 1987 folgte die Definition und Standardisierung von CAN als ISO 11898 für Layer1 (physikalische Schicht) und Layer 2 (Datensicherungsschicht) im ISO/OSI-Referenzmodell.

oci

Signal-Propagation, Bus-DatenRate und Bus-Länge

Die Bus-Datenrate und Bus-Länge stehen zueinander in einer nichtlinearen Beziehung so, mit der Zunahme der Distanz die nominale Bitzeit zunimmt. Das hat mit der Signal-Propagation zwischen Empfänger und Sender der Nachricht zu tun.

Jede Art Verzögerung bei der Bearbeitung des Signals führt zur Verlängerung der Gesamtübertragungszeit. Jede Koppelstufe hat eine Latenzzeit. Die Hardware-Synchronisation beim Anfang und die Behandlung von "Identifier" und "Ack" am Ende der Signalübertragung verlangsamen die Fortpflanzung des Signals.

Bus-Topologie, Bausteine und Signale

Das CAN-Netzwerk dehnt sich zweiadrig als eine parallele Linienstruktur aus und braucht an beiden Enden des Busses Abschlusswiderstände zu je 120 Ohm, welche einfach zu platzieren sind. Die einzelnen Geräte werden einfach an dem Bus geschaltet und wirken als ein Knoten des Netzwerks. Jeder Knoten besteht aus einem Device, einem Mikrocontroller, einem CAN-Controller und einem CAN-Transceiver. Dabei können der Mikrocontroller und der CAN-Controller auf einem Baustein implementiert sein. Mit Device wird hier das eigentliche arbeiterrichtende Gerät bezeichnet. Das Signal auf der Strecke (auf dem Bus) zwischen zwei CAN-Transceivern ist ein Differenzsignal und nicht mehr nur ein einfaches digitales Signal. (Abbildung) Es ist möglich CAN als Ein-Draht-Lösung gegen Masse auszuführen, was besonders bei niedriger übertragungsrate oder beim Ausfallen einer Ader der Verbindung geeignet ist.

cannetwork

NRZ-Kodierung, CAN-Transceiver

Die Leitungskodierung beim CAN verläuft nach der NRZ-Kodierung. Dies bedeutet, dass im Verlauf der Lebenszeit eines Bits und auch zwischen zwei aufeinanderfolgenden, gleichwertigen Bits kein Wertwechsel in Form einer Flanke stattfindet (Abbildung). Auf den CAN-Bus-Adern liegen jeweils die Differenzsignale CAN_HIGH und CAN_LOW (Abbildung). CAN_LOW enthält den komplementären Pegel von CAN_HIGH. So entsteht aus der Differenz der beiden ein "Dominantbit" oder " Rezessivbit". Es gibt Vereinbarungen über Signaldifferenzen und deren technische Bedeutungen (Tabelle). Ein dominantes Bit überschreibt naturgemäß ein rezessives Bit. So kann sich der Sender eines Dominantbits beim Zugriff auf den Bus behaupten und durchsetzen. Durch das Unterdrücken der Gleichtaktstörungen mittels Differenzsignale ist der CAN-Bus gegenüber elektromagnetischer Störungen der Umgebung unempfindlich, wodurch die Fehlerrate reduziert wird. Der Can-Bus ist NRZ-Kodiert, was bewirkt, dass alle CAN-Bus-Bausteine nur zwei Buszustände wahrnehmen können. Für die Synchronisation kommen keine Flankenänderungen zur Hilfe. Deswegen gibt es beim CAN-Bus besondere Maßnahmen zur Synchronisation und der Erkennung einzelner Bits.

NRZ-Kodierung

Differenzsignale CAN_HIGH und CAN_LOW

Differenz der CAN-H und CAN-L, Bus-Pegel, Bus-Zustand

Bit-Timing und Bit-Stuffing

Eine Bit-Zeit besteht aus vier Zeitsegmenten, die sich nicht überlappen. Jedes Bitsegment besteht aus mehreren Zeitquanten. Ein Zeitquantum ist die kleinste verwendete diskrete Zeitspanne jedes Knotens. Die Länge dieser Zeitspanne wird aus der Oszillatorfrequenz von CAN-Konten generiert. Je nach Anwendung kann die Anzahl der Zeitquanten für ein Bit variieren. Zum Synchronisieren zwischen Empfänger und Sender ist das Synchronisationssegment von einem Zeitquantum vereinbart. Das Propagationssegment und Phase-Segment 1 und Phase-Segment 2 können auch je nach Hersteller und Anwendungsbereich anders eingestellt sein. Das Propagationssegment dient zur Kompensation der Verzögerungen des Signals im Netzwerk. Phase-Segment 1 ist dient zum Ausgleich von Flanken-Phasenfehlern. Es kann während der Resynchronisation verlängert werden. Das Phase-Segment 2 dient zum Ausgleich von Flanken-Phasenfehler. Es kann während der Resynchronisation verkürzt werden. Die Zahl der Zeitquanten eines Phase-Segments 2 ist gleich der Anzahl der Zeitquanten im Phase-Segment 1. Zwischen den Phase-Segmenten liegt der Abtastpunkt. Somit ist die Bit-Zeit so organisiert, dass am Abtastpunkt ein korrektes Lesen des Buszustandes "Bit-Wert" möglich ist.

bittiming

Eine weitere Maßnahme zur Erkennung und zur Synchronisation der Bits ist Bit-Stuffing. Trotz Bit-Timing kann es zur Verfälschung der gelesenen Bits kommen, wenn viele gleichwertige Bits hintereinander am Bus geschickt werden. Zum Vorbeugen dieser Kategorie von Fehler fügt man senderseitig nach fünf gleichwertigen Bits ein so genanntes "Stuff-Bit" dem Bitstrom zu. Stuff-Bits können daraufhin vom Empfänger erkannt und gefiltert werden (Abbildung).

CAN-Bus und Bit-Stuffing

Bus-Zugriff, Arbitrierung

Das CAN-Bus Protokoll erlaubt den gleichzeitigen Zugriffsversuch von mehreren Knoten auf das Kommunikationsmedium. Damit sich diese Zugreifer nicht gegenseitig stören, verwendet CAN-Bus die nicht-destruktive, bitweise Arbitrierung CSMA/CD + AMP ( Carrier Sense Multiple Access with Collision Detection and Arbitration on Message Priority ). Die Priorität einer Nachricht ist mit ihrem "Identifier" für jeden Knoten festgelegt. Ein "Identifier" ist ein Bestandteil der Nachricht und steht gleich am Anfang vom "Frame". Die Bits mit dem Wert 1 heißen "rezessiv" und werden von den Bits mit dem Wert 0 "dominant" überschrieben. So haben die Identifier mit kleinerem Wert eine höhere Priorität und bekommen bei gleichzeitigem Zugriffsversuch den Zugriff auf den Bus. Im Beispiel (Abbildung) hat der Knoten 2 mit CAN-ID: 0x031 die höhere Priorität und bekommt den Zugriff auf dem Bus.

Bus-Zugriff, Arbitrierung

Kommunikationsprinzip

Die Art der Kommunikation auf dem CAN-Bus ist Rundfunk "broadcasting". Dies bedeutet, dass alle Knoten des Netzwerks die vom Sender verschickte Nachricht mithören. Nach dem Empfang der Nachricht entscheidet jeder Knoten anhand seines Filters, ob die Nachricht für ihn relevant ist. In dieser Art Kommunikation gibt es stets ein Sender "Producer" und beliebig viele Empfänger "Consumer". RTR (Remote Transmission Request) verhält sich wie eine Abfrage seitens Empfänger, die in der zweiten Kommunikation von dem Sender beantwortet wird. Diese Antwort "data frame" kann dann von mehreren "Consumer" empfangen werden. Es sind zwei Kommunikationsdienste im CAN-Bus-Protokoll vorgesehen. Diese werden mit "write object" und "read object" bezeichnet. Beim "write object" handelt es sich um Daten, die der Sender in einer Einzelkommunikation dem Empfänger zur Verfügung stellt. Beim "read object" fragt der Empfänger in einer ersten Kommunikation mittels RTR den Sender nach den gewünschten Daten. Ein "Remote Transmission Request" enthält keine Daten, aber bereits anhand des "Identifier" sind die verlangten Daten bekannt. Der Sender sendet daraufhin im zweiten Kommunikationsschritt die gewünschten Daten (Abbildung).

Frame-Aufbau

Der Datenaustausch auf dem Bus verläuft nach dem CAN-Bus-Telegramm. Es gibt sowohl die CAN-Spezifikation 2.0 A (Basisversion) als auch die verlängerte Version 2.0 B. Dabei handelt es sich um die Länge vom "Identifier". Die beiden Versionen "CAN base frame" und "CAN extended frame" sind in ISO11898-1 standardisiert. Die Kommunikation beginnt und verläuft nach dem folgenden Schema: Der Bus befindet sich im Leerlauf im rezessiven Zustand. Ein CAN-Telegramm wird auf den Bus gelegt, dann passieren 3 rezessive Bits, "Intermission-Bits" genannt, und erst danach kann ein neues Telegramm geschickt werden. Nach diesem Muster geht die Kommunikation weiter. Telegramme werden mittels Intermission auseinander gehalten. Eine tabellarische Darstellung zu beiden Protokollversionen wird in der Abbildung veranschaulicht.

canframe
Die magentafarbigen Bit-Werte bleiben konstant.
Die blaufarbige Bit-Werte sind bei Push- und Pullmodel verschieden.
Die grünfarbige Bits können je nach Identifier und Daten verschieden Werte annehmen.

Ein CAN-Telegramm besteht aus mehreren Feldern, die im Einzelnen wie folgt heißen, funktionieren und organisiert sind.

  • Startfeld(SOF): Das ist ein dominantes Bit und zeigt den Beginn eines Telegramms.
  • Statusfeld: In diesem Feld findet die Arbitrierung statt. Einträge zu Lese- und Schreibbetrieb und Protokollversion nehmen hier Platz.
    • In der Version 2.0 A besteht das Feld aus einem Identifier-Segment aus 11 Bits und einem RTR-Bit für (Remote Transmission Request). Im "remote frame" ist das RTR-Bit rezessiv und im "data frame" ist es dominant einzustellen
    • In der Version 2.0 B besteht es aus einem Identifier-Segment aus 11 Bits, einem rezessiven SRR-Bit für (Substitute Remote Request), einem rezessiven IDE-Bit für (IDentifier Extension), einem zweiten Identifier-Segment aus 18 Bits und einem RTR-Bit für (Remote Transmission Request). Im "remote frame" ist das RTR-Bit rezessiv und im "data frame" ist es dominant einzustellen. Zur Unterscheidung des "base format" und "extended format" sind das SRR-Bit und IDE-Bit immer rezessiv zu halten.
  • Kontrollfeld(CTRL): Dieses Feld beinhaltet 4 DLC-Bits zur Kontrolle der Datenlänge.
    • In der Version 2.0 A besteht das Feld zudem aus einem dominanten IDE-Bit (Identifier Extension) und einem dominanten reservierten r0-Bit.
    • In der Version 2.0 B besteht das Feld auch aus zwei dominanten reservierten r0- und r1-Bits.
  • Datenfeld: Hier stehen bis 8 Bytes Daten für "data frame" oder 0 Bytes im Falle von "remote frame"
  • Sicherungsfeld: Das Feld beinhaltet 15 CRC-Bits (Cyclic Redundancy Check) und ein rezessives "CRC delimiter bit". Mit CRC wird eine Prüfsumme bezeichnet. Sie wird vom Sender aus der Division des Message-Polynoms durch das Polynom x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1 berechnet und mit der Nachricht mitgeliefert. Der Empfänger vergleicht daraufhin die beiden Komponenten und stellt den eventuellen Fehler fest.
  • Bestätigungsfeld: In diesem Feld sind "ACK slot bit" und das rezessive "ACK delimeter bit" eingebaut. Der Sender schickt das "ACK slot bit" rezessiv und der Empfänger überschreibt es dominant im Falle der korrekten Nachricht.
  • Endfeld: Dieses Feld fungiert als ein Delimeter für das Ende des Frames und besteht aus 7 rezessiven Bits. Es ermöglicht eine Benachrichtigung innerhalb des laufenden Frames, wenn der CRC-Bereich einen Fehler verursacht.

Der CAN-Standard fordert, dass eine Implementierung das "base frame format" akzeptiert werden muss. Beim "extended frame format" ist dies optional, es muss jedoch zumindest toleriert werden.

CAN-Bus Fehlerbehandlung

Die Fehlerbehandlung beim CAN-Bus gewährleistet eine netzwerkweite Datenkonsistenz. Dazu darf kein Knoten im Error-Passive-Zustand oder im Bus-Off-Zustand sein. Beim Eintreten eines lokalen Fehlers wird er globalisiert, in dem ein "Error-Flag" gesendet wird. Damit wissen andere Knoten, dass ein Fehler aufgetreten ist, und sie die aktuelle Nachricht verwerfen können. Der Fehlerzähler wird daraufhin beim Sender inkrementiert, gefolgt von einem erneuten Sendeversuch.

Es gibt im CAN-Protokoll verschiedene Bitfelder mit einem besonderen Zusammenhang, die einen Fehler anzeigen können.

  • Error-Flag: Ein "Error-Flag" besteht aus 6 gleichwertigen Bits.
  • Error-Frame: Ein "Error-Frame" besteht aus einem 6 Bits langem dominanten "Error-Flag", 0 bis 6 dominanten "Error-Flag"- Bits als Antwort auf die erste Fehlermeldung und 8 rezessiven Bits als "Error-Delimeter".
  • Bit-Stuffing Area: Das ist der Bereich von "Bit-Stuffing", wo nach 5 gleichwertigen Bits ein Bit mit dem Gegenwert in den Bitstrom eingefügt wird. Der Bereich beinhaltet SOF (Start Of Frame), Arbitrationsfeld, Kontrollfeld, Datenfeld und CRC-Feld. Ausgenommen vom "Bit-Stuffing" sind "CRC-Delimeter", "ACK-Feld" und EOF. Empfangen von 6 gleichwertigen Bits in der "Bit-Stuffing Area" löst eine Error-Meldung und danach die Error-Behandlung aus.
  • Bit-Monitoring Area: Das ist der Bereich SOF bis Ende CRC, ausgenommen dem Arbitrierungsfeld. Jeder Knoten überwacht den Bus und vergleicht den Zustand des Busses mit dem von ihm gesendeten Bit der Nachricht. Wenn die übereinstimmung verletzt wird, sendet er ein "Error-Frame", die Error-Behandlung beginnt. In das Arbitrierungsfeld und im Bestätigungsbereich ist der Zugriff der anderen Knoten erlaubt.
  • CRC Area: Der Bereich erstreckt sich vom SOF bis Ende Datenfeld. Der Sender berechnet in diesem Bereich eine Prüfsumme nach dem "Cyclic Redundancy Check" und sendet diese im CRC-Feld im Frame. Der Empfänger berechnet seinerseits die Prüfsumme und vergleicht sie mit der gesendeten Prüfsumme des Senders. Bei einer Nichtübereinstimmung sendet er ein "Error-Frame" an der Stelle nach "Ack-Delimeter", die Error-Behandlung beginnt.
  • Acknowledgement Area: Der Sender einer Nachricht sendet das "Ack-Slot" rezessiv. Wenn ein Sender merkt, dass seine Nachricht nicht mit einem dominanten Bit an der Bestätigungsstelle bestätigt wurde, löst er ein "Error-Frame" aus.
  • Delimeter Area: Wenn der Sender im Delimeter-Bit vom CRC oder "Ack" oder im Bereich EOF (End Of Frame) einen dominanten Zustand feststellt, folgt ein Form-Error sowie das Generieren eines Error-Frames.

Ein weiterer Mechanismus zur Fehlerbehandlung im CAN-Bus ist der Fehlerzustand des CAN-Knoten, "Error States Of CAN Node" genannt. Zur Unterscheidung zwischen dem zufälligen und dauerhaften Fehler sind zwei Fehlerzähler im CAN-Controller implementiert. Diese heißen REC (Receive Error Counter) und TEC (Transmit Error Counter). Die Zähler werden beim Auffinden des Fehlers inkrementiert und bei jedem korrekt gesendeten oder empfangenen Frame dekrementiert. Je nach Zählerstand ändert sich der Zustand des Knoten. Der Ausgangszustand eines CAN-Bus-Controllers ist Fehler Aktive, d.h. der Controller kann aktive Fehler-Flags senden. Der Controller geht nach einer gewissen Anhäufung von Fehlern in den error-passiven Zustand. Eine extreme Anhäufung von Fehlern führt zum statischen übergang in den Bus-Off Zustand. Die Steuerung wird von dem Bus getrennt, indem er in einem Zustand mit hohem Widerstand versetzt wird. Der Bus-Off Zustand sollte nur von einem Software-Reset verlassen werden.