Grundlegende Informationen zum CAN-Bus

1 Der CAN-Bus Grundlegende Informationen zum CAN-Bus von Thomas Wedemeyer1. Vorwort Dieser Text ist ein Ausschnitt aus meiner Studienarbeit, die sich mit der Entwicklung eines CAN auf RS232 / SSI-Interfaces besch ftigt. Der Text soll die grundlegenden Eigenschaften des CAN-Busses zusammen-fassen und einen berblick ber die Einsatzm glichkeiten geben. 2. Der CAN-Bus Grundlagen des CAN-Bus Beim CAN-Protokoll handelt es sich um ein Bus-Protokoll, das seit Anfang der 80'er Jahre auf betreiben der Automobilindustrie entwickelt wurde. Ziel der Entwicklung war es durch die Einf hrung eines Bussystems im Kraftfahrzeug die Verkabelung der einzelnen Systeme, Sensoren und Aktoren zu vereinfachen und Kosten zu sparen.

2 F r den Einsatz im KFZ-Bereich wurden deshalb die folgenden Anforderungen an das Kommunika-tionsprotokoll formuliert und sp ter im CAN-Protokoll realisiert:Der CAN-Bus muss f r so genannte Klasse-C Applikationen geeignet sein. , der Bus muss in der Lage sein zeitkritische Informationen mit Zykluszeiten von 1 bis 10ms und Botschafts-Latenzzeiten von unter 1ms zu bertragen. Die L nge der einzelnen Botschaften umfasst dabei nur wenige Byte. Die zu erwartende Datenrate bei dieser Anwendung liegt im Bereich von 250kBit/sec bis 1 MBit/sec. Beispiele f r typische Klasse-C Applikationen sind der Bereich des Motormanagements und der Stabilit ber hinaus sollte der CAN-Bus aber auch f r so genannte Klasse-A Applikationen geeignet sein.

3 In dieser Klasse sind Applikationen zusammengefasst, die nur geringe Datenraten ben tigen und eine gro e Zykluszeit zwischen den Datentransfers besitzen. Die Datenrate liegt bei dieser Applikation unterhalb von 10kBit/sec. Im KFZ-Bereich ist ein Beispiel f r diese Applikationsklasse die gesamte Chassis-Elektronik & Elektrik im Auto, also Zentralverriegelung, Bremsleuchten, Blinker Anforderung, die sich aus Sicherheitsgr nden ergibt, ist die Multimaster-F higkeit des CAN-Busses. Bei einem Multimaster-System ist jeder einzelne Knoten in der Lage eine Kommunikation einzuleiten. Dadurch wird vermieden, das durch einen Defekt in einem Knoten die Funktion des Gesamtsystems gef hrdet ist.

4 F r den Fall, das mehrere Knoten gleichzeitig versuchen auf dem Bus Daten zu bertragen, m ssen entspre-chende Vorkehrungen getroffen werden, um diese Zugriffskonflikte zu erkennen und aufzul sen. Der CAN-Bus bedient sich der Zugriffstechnik CSMA/CD+CR (Carrier Sense, Multiple Access/ Collision Detection + Collision Resolution). Einzelheiten zur Kollisionserkennung und Busarbitierung k nnen dem Kapitel ent-nommen weiterer Vorteil ist, da durch die Multimaster-F higkeit eine ereignisgesteuerte Kommunikation erm glicht wird. , jeder Teilnehmer ist in der Lage die bertragung von Informationen , die durch ein Ereignis erzeugt wurden, selbstst ndig auszul sen.

5 Dabei werden die Informationen mit einer so genannten File: 1 Thomas WedemeyerDer CAN-BusBroadcast-Kommunikation bertragen. Broadcast-Kommunikation hei t, dass die gesendete Information von allen Teilnehmern empfangen wird. Die Auswertung der empfangenen Daten in den Teilnehmern erfolgt anhand des gesendeten inhaltsbezogenen Identifiers der Nachricht. Aus diesem Grund wird jedem Ereignis ein eindeutiger Identifier zugeordnet. Weiterhin ist beim CAN-Protokoll auch die M glichkeit vorgesehen durch Anforderung das Versenden von Informationen auszul sen. Diese Abfrage von Informationen wird Remote Request genannt. Bei einem Remote Request wird ein spezieller Remote Frame gesendet, der keine Daten sondern nur den Identifier der gew nschten Nachricht enth lt.

6 Dieser Remote Frame wird dann von einem Teilnehmer mit einem normalen Datenframe beantwortet. Die Nachricht wird wiederum von allen Teilnehmer empfangen und die Daten-konsistenz im ganzen System ist der Entwicklung des CAN-Protokolls wurde auch darauf geachtet, dass M glichkeiten zur Erkennung von bertragungsfehlern vorhanden sind. Dazu wurde eine Fehlererkennung in mehreren Ebenen vorgesehen. Auf Botschaftsebene ist eine Fehlererkennung mittels einer im Telegramm bertragenen 15-Bit CRC-Pr fsumme (CRC:=Cyclic Redundancy Check) implementiert. Dar ber hinaus ist auch eine Fehlererkennung auf der physikalischen bertragungsebene vorgesehen.

7 Weitere Einzelheiten zur Fehlererkennung k nnen den nachfolgenden Kapiteln entnommen die oben beschriebenen Eigenschaften des Protokolls setzt sich der CAN-Bus in der Autoindustrie seit 1990 immer mehr durch. Inzwischen wird von fast allen Herstellern dieses Protokoll in ihren Fahrzeugen verwendet. Dar ber hinaus setzt sich der CAN-Bus auch im Bereich der Industriesteuerungen und der Automatisierungstechnik durch. Die weitere Verbreitung des CAN-Busses auch au erhalb der Automobil-industrie f hrte dazu, dass der Wunsch nach dem CAN-Protokoll als offenes Kommunikationsprotokoll immer gr er wurde. 1992 wurde dann von der CiA (CAN in Automation) damit begonnen die OSI Layer 1,2 & 7 zu zum Zugriff auf die Daten bereitstellen6 PresentationKonvertierung & Formatanpassung von Daten5 SessionDienste zum Auf- & Abbau von Sitzungen4 TransportVerbindung zwischen Prozessen herstellen3 NetworkVermittlung der Daten zwischen verschiedenen Quellen & Zielen2 Data LinkSichere bertragung der Telegramme sicherstellen1 PhysicalDefiniert die bertragung der einzelnen Bits auf dem bertragungs-mediumAbbildung 1.

8 Aufbau des OSI-ModellsIm OSI Layer 1 wurden detaillierte Spezifikationen f r die physikalische Ebene der Kommunikation festgelegt. In diesem Layer sind Empfehlungen f r Kabel, Stecker und Leistungstreiber zusammengefasst Der OSI Layer 2, der Data Link Layer, steuert und sch tzt die Kommunikation auf der Ebene eines Frames. Die OSI Layer 3 bis 6 sind f r CAN nicht notwendig. Die Spezifikation auf der Ebene des Application-Layers (Layer 7) File: 2 Thomas WedemeyerDer CAN-Busist nicht festgelegt. F r diesen Layer sind aber verschiedene Protokolle definiert worden ( SDS, DeviceNET, OpenCAN, usw.), aber es gibt keine bindende Aufbau des CAN-Frames F r den inhaltlichen Aufbau eines CAN-Frames, also eines CAN-Telegramms, existieren im Augenblick zwei Spezifikationen, die sich haupts chlich in der Anzahl der Identifierbits unterscheiden.

9 In einem Standard CAN-Frame gem der CAN-Spezifikation wird der Identifier durch 11-Bit festgelegt. Damit lassen sich 2032 verschiedene logische Adressen kodieren. Das hei t, dass in einem Netzwerk maximal 2048 ver-schiedene Informationen verschickt werden k nnen. Da dies f r viele Anwendungen nicht ausreicht ist die Anzahl der Identifier in der Spezifikation auf 29 Bit erweitert worden. Durch diese Erweiterung ist es m glich verschiedene Informationen zu bertragen. Telegramme, die gem der Spezifikation aufgebaut sind, werden als Extended-CAN-Frames bezeichnet. Der genaue Aufbau der Frames ist in der Abbildung 2 & Abbildung 3 2: Aufbau des Standard-CAN-TelegrammsAbbildung 3: Aufbau des Extended-CAN-TelegrammsEingeleitet wird ein CAN-Frame durch ein Startbit, das Low-Pegel f hrt (dominantes Bit), durch dessen fallende Flanke die einzelnen Teilnehmer synchronisiert werden.

10 Nach dem Startbit folgen 11 Bit, die den Identifier bilden. Der Identifier kennzeichnet die logische Adresse und die Priorit t der Nachricht. Je kleiner die logische Adresse der Nachricht ist, desto h her ist die Priorit t der Nachricht. Bei der bertragung des Identifiers wird das MSB zuerst bertragen. Nun folgt bei einem Standard CAN-Frame die bertragung des Remote Transmission Request Bits (RTR-Bit). Mit diesem Bit wird ein Remote-Frame gekennzeichnet. Dieser Frame-Typ enth lt keine Daten, sondern fordert eine Nachricht von einem anderen Teilnehmer an. Die bertragung der angeforderten Nachricht erfolgt direkt im Anschluss an die bertragung des Remote Frames, vorausgesetzt der Bus wird nicht vorher durch eine Nachricht mit h herer Priorit t n chstes wird das Control Feld bertragen, das aus 6 Bits besteht.