CAN - Controller Area Network

Transkript

1 CAN - Controller Area Network Seminar Fahrzeugkommunikation Friedrich-Alexander-Universität Erlangen-Nürnberg - Institut für Informatik Florian Rathgeber Inhaltsverzeichnis 1 Motivation Einordnung und Geschichtliches Datenübertragungsschicht Kennzeichnung von Nachrichten Busarbitrierung - Auflösung von Sendekonflikten Aufbau einer Nachricht Fehlererkennung und -behandlung Eingrenzung defekter Knoten Physikalische Schicht Dominanter und rezessiver Pegel Busmedium Signaldarstellung und Busankopplung Höhere Schichten Zusammenfassung Motivation Längst vorbei sind die Zeiten, in denen ein Auto fast ausschließlich mechanisch und hydraulisch funktionierte und elektrische Teile die Ausnahme darstellten. Seit einigen Jahrzehnten nimmt der Anteil an Elektronik immer mehr zu, vor allem der Sicherheit und dem Komfort der Fahrgäste geschuldet. Durch die stetig steigende Zahl von Steuergeräten nahm auch der Verkabelungsaufwand ständig zu. Bis Ende der 80er Jahre waren Punkt-zu-Punkt-Verbindungen üblich, das heißt zwischen je zwei Steuergeräten, die miteinander kommunizieren können sollten, musste ein Kabel verlegt werden. Je mehr Steuergeräte und je stärker die Vernetzung unter ihnen desto mehr Kabel kamen zusammen. Dabei kann die Länge des Kabelbaums bis zu 2000m betragen, sein Gewicht bis zu 100kg [Lawrenz, 2000]. Dazu kommt noch, dass verschiedene Zulieferer verschiedene Kabelbaumtypen verlangen. Es ist leicht einzusehen, dass diese Lösung auf die Dauer unbefriedigend war und man Abhilfe suchte. Die Ziele dabei waren, Gewicht und Kosten zu senken und gleichzeitig mehr Flexibilität bei der Verkabelung zu haben. Sinnvoll wäre es doch, wenn ein Steuergerät gleich mit einer ganzen Gruppe von anderen Steuergeräten kommunizieren könnte, ohne dass dafür ein Kabel zu jedem Kommunikationspartner einzeln verlegt werden muss. Gleichzeitig sollte die Kommunikation standardisiert werden, um die Interoperabilität von Geräten verschiedener zulieferer zu vereinfachen. Die Lösung die die Robert Bosch GmbH in den 80er Jahren in Zusammenarbeit mit Intel entwickelte, war der CAN-Bus (Controller Area Network). Nun hingen alle Geräte an einem Strang, man brauchte nur noch eine Leitung für den ganzen Bus und jedes Steuergerät, das an diesem Bus hing, konnte mit jedem anderen Nachrichten austauschen. 1

2 2 Einordnung und Geschichtliches 2 Fig. 1: Kabelbaum für 24 Geräte (Quelle: 2 Einordnung und Geschichtliches CAN ist ein Felbbussystem, das im Automobil- und Nutzfahrzeugbereich, in Zügen und Schiffen und in der Automatisierungstechnik, z.b. zur Robotersteuerung und zur Sensor-/Aktorkommunikation zum Einsatz kommt [Lawrenz, 2000]. Feldbus bedeutet, dass es verschiedene Geräte vernetzt, die auch räumich stark voneinander getrennt sein können. Es ist ein ereignisgesteuertes und nachrichtenorientiertes Protokoll, der Botschaftsaustausch findet also nicht in regelmäßigen Zeitintervallen, sondern nach Bedarf statt und nicht auf Empfänger- sondern auf Nachrichtenebene. Der Buszugriff erfolgt nach dem CSMA/CD+CR-Verfahren (Carrier Sense Multiple Access / Collission Detection and Collision Resolution). Die Teilnehmer greifen also gleichzeitig auf den Bus zu und müssen sich das Senderecht gegebenenfalls durch einen Arbitrierungsvorgang erkämpfen. Kollisionen werden dabei frühestmöglich erkannt und sofort aufgelöst [Lawrenz, 2000]. Alle Busteilnehmer sind dabei gleichberechtigt, CAN ist also ein Multi-Master-System, nur die Nachrichten haben unterschiedliche Prioritäten. Das CAN-Protokoll implementiert lediglich die Schichten 1 und 2 des ISO-OSI-Schichtenmodells, also nur die physikalische oder Bitübertragungsschicht (physical layer) und die Sicherungsschicht (data link layer). Höhere Schichten können von Zusatzprotokollen bereitgestellt werden, was aber im Automobilbereich unüblich ist. Die aktuelle CAN Specification 2.0 spezifiziert einen HighSpeed-Bus mit einer Datenübertragungsrate von mehr als 125 kbit/s bei einer maximalen Leitungslänge von 40m und einen LowSpeed-Bus mit einer Datenübertragungsrate von bis zu 125 kbit/s wobei die Leitungslänge bis zu 500m betragen kann. SAE-Klassen für Bussysteme im Fahrzeugbereich Nach [Reif, 2006] spezifiziert die Society of Automotive Engineers (SAE) folgende Anwendungsklassen für Elektronik im Fahrzeug: A Diese Klasse umfasst die Kommunikation von Sensoren und Aktoren untereinander. Hier sind die Botschaften sehr kurz und die dafür notwenigen Bitraten sehr niedrig, meist kleiner als 10 kbit/s. Fehlererkennungs- und Behebungsmechanismen sind kaum vorhanden und notwendig. Dafür ist dieser Bereich sehr kostensensitiv und ein typisches Anwendungsgebiet für den LIN-Bus. B Hierunter fällt die Vernetzung von Steuergeräten im Komfortbereich und die Karosserieelektronik. Dabei hat man üblicherweise Datenraten im Bereich von 125 kbit/s und Mechanismen zur Fehlererkennungund Behandlung sind bereits sehr komplex. Typischerweise setzt man hier den LowSpeed CAN-Bus ein.

3 3 Datenübertragungsschicht 3 C In dieser Klasse fasst man Steuergeräte für einfache Echtzeitanwendungen zusammen, beispielsweise im Antriebsstrang. Die Datenraten in diesem Bereich sind mit bis zu 1 MBit/s bereits sehr hoch, genauso die Anforderungen an Fehlererkennung und -Behebung. Hier kann man den HighSpeed CAN-Bus einsetzen. D Darunter fasst man Multimedia-Anwendungen mit sehr hohen Datenraten von bis zu 10 MBit/s und sehr großer Botschaftslänge. Der CAN-Bus ist für solche Anwendungen ungeeignet, hier verwendet man den eigens dafür entwickelten MOST-Bus. Zur Geschichte von CAN Anfang der 80er begannen einige Automobilhersteller und Zulieferer mit der Entwicklung von Bussystemen, um dem Verkabelungschaos im Fahrzeug Herr zu werden. Die Entwicklung von CAN wurde 1983 bei Bosch begonnen. Als Technologiepartner arbeitete man mit dem Chiphersteller Intel zusammen und 1985 wurde das Projekt von den beiden Partnern gemeinsam vorgestellt. Die Schnittstelle wurde dann 1987 fertiggestellt, die ersten Chips standen 1988 zur Verfügung wurde CAN dann erstmals in der S-Klasse von Mercedes-Benz eingesetzt [ Zu dieser Zeit wurden auch Automatisierungstechnikunternehmen auf CAN aufmerksam und bereits 1992 wurde die Anwendergruppe CAN in Automation (CiA) gegründet, weitere folgten. Diese trieben vor allem die Standardisierung der Stecker und Verbindungen voran und entwickelten Zusatzprotokolle die auf den CAN-Schichten 1 und 2 aufsetzten. Mitte der 90er beschlossen dann auch andere Automobilhersteller, die bisher auf eigene Lösungen gesetzt hatten, CAN in ihren Fahrzeugen einzusetzen. Seither kann man CAN als das Standard-Bussystem im Fahrzeugsektor ansehen. 3 Datenübertragungsschicht Die Datenübertragungsschicht ist die Schicht 2 des ISO-OSI-Schichtenmodells und eine der beiden vom CAN-Standard spezifizierten Schichten. Zu ihren Aufgaben gehören die Zustellung und Anforderung von Nachrichten und der Medienzugriff, das Auflösen von Sendekonflikten durch Busarbitrierung, die Fehlerüberprüfung und deren Signalisierung sowie die Eingrenzung und Abschaltung defekter Teilnehmer. 3.1 Kennzeichnung von Nachrichten Jede Nachricht, die ein Steuergerät über den CAN-Bus senden kann, hat eine eindeutige Kennzeichnung, den sogennanten Nachrichten-Identifier, die wie eine Art Betreff den Typ und Zweck dieser Nachricht beschreibt. Jeder Teilnehmer der eine Nachricht empfängt kann anhand dieser Kennung entscheiden, ob die Nachricht für ihn relevant ist und er sie weiterverarbeiten möchte oder ob er sie einfach ignoriert. Der Hersteller oder Betreiber des Busses legt bereits vor der Inbetriebnahme fest, welche Nachricht welche Kennung erhält und welches Steuergerät sie senden darf, sowie für welche anderen Steuergeräte diese relevant ist. Dabei bestimmt der Identifier gleichzeitig die Priorität der Nachricht im Falle eines Sendekonfliktes. In der CAN Spezifikation 2.0A wird eine Identifier-Länge von 11 bit spezifiziert, was auch als Standardformat bezeichnet wird. Die Spezifikation 2.0B gibt eine Länge von 29 bit vor, das sogennante erweiterte Format. Diese Kennung wird unterteilt in einen Basis-Identifier mit 11 bit und einen erweiterten Identifier mit 18 bit. Dabei sind beide Formate zueinander kompatibel und können auch auf einem einzelnen Bus gemeinsam verwendet werden. Man bezeichnet CAN daher als Nachrichtenorientiertes Protokoll, weil Nachrichten keine spezifische Empfängeradresse haben, sonder an alle Teilnehmer des Busses gesendet werden, welche dann selbst entscheiden, ob sie die Nachricht weiterverarbeiten oder nicht. [Etschberger, 2002] 3.2 Busarbitrierung - Auflösung von Sendekonflikten Das Senden einer Nachricht durch einen Busteilnehmer ist nur dann möglich, wenn der Bus frei ist. Da aber der Zugriff auf den Bus durch alle Teilnehmer gleichzeitig passiert, kann es vorkommen, dass

4 3 Datenübertragungsschicht 4 1 Station 1 gewinnt Arbitrierung 2 Station 2 zieht sich zurück 3 Station 3 zieht sich zurück Bus rezessiv dominant Fig. 2: Beispielhafter Arbitrierungsvorgang mit drei sendewilligen Stationen zwei Steuergeräte auch gleichzeitig, das heißt innerhalb eines Bitzeitintervalls, einen Sendevorgang starten wollen. Der hierbei auftretende Konflikt wird durch einen Arbitrierungsvorgang aufgelöst, der entscheidet, welchem Teilnehmer das Senderecht zugesprochen wird. Der ganze Vorgang ist verlustlos, was bedeutet, dass die Nachricht, die gerade gesendet wird nicht zerstört wird. Nach Abschluss des Arbitrierungsvorganges kann also das dann sendeberechtigte Steuergerät direkt weitersenden, ohne dass der Beginn der Nachricht bis zu diesem Zeitpunkt noch einmal gesendet werden muss. Die Nachricht kommt beim Empfänger trotzdem vollständig an. Entscheidend bei der Arbitrierung ist die Kennung der Nachricht, wodurch die Priorität jeder Nachrichten die zu senden begonnen wurde bestimmt ist. Dabei ist das Bit 0 dominant weil es das Bit 1 überschreibt, das deshalb als rezessiv bezeichnet wird. In Fig. 2 ist ein Arbitrierungsvorgang mit drei sendewilligen Stationen beispielhaft dargestellt. Dabei wird so vorgegangen, dass jeder Teilnehmer der senden möchte in jedem Bitzeitintervall der Arbitrierungsphase den Pegel den er selbst angelegt hat mit dem Pegel vergleicht der auf dem Bus ankommt. Stellt er dabei fest, dass beide Pegel übereinstimmen, behält er die Sendeberechtigung und legt im nächsten Bitzeitintervall Pegel entsprechend dem nächsten Bit seines Identifiers an. Das heißt er hat dominant angelegt und dominant liegt auf dem Bus oder er hat rezessiv angelegt und rezessiv liegt auf dem Bus. Im anderen Fall, dominanter Pegel liegt auf dem Bus, der Teilnehmer hat aber rezessiven angelegt, verliert er die Arbitrierung und damit die Sendeberechtigung und zieht sich zurück. Das bedeutet die Station geht in den Empfangsmodus und empfängt die Nachricht, die von den weiterhin sendeberechtigten Stationen kommt. Bei mehr als zwei konkurrierenden Stationen ziehen sich somit nach und nach alle bis auf eine zurück, die den Arbitrierungsvorgang gewinnt und ihre Nachricht senden darf. Neben dem Identifier wird auch noch das Remote-Transmission-Request-Bit (RTR) mit in die Arbitrierung einbezogen. Dieses auf die Kennung direkt folgende Bit bestimmt, ob mit der Nachricht Daten gesendet oder Daten angefordert werden. Dabei hat das Datentelegramm die höhere Priorität, da die Anforderung dann hinfällig wird, wenn die angeforderten Daten bereits gesendet werden. Ein erneutes senden ist dann überflüssig und die anfordernde Station wird nicht noch einmal versuchen, das Anforderungstelegramm zu senden. [Etschberger, 2002]

5 3 Datenübertragungsschicht 5 rezessiv bits dominant Identifier Field Data Length Code (DLC) CRC-Field End of Frame (EOF) Start of Frame (SOF) Remote Transmission Request (RTR) Identifier Extension Bit (IDE) reserved Data Field CRC Delimiter Acknowledge Slot (ACK) Acknowledge Delimiter Intermission Space Arbitration Field Bitstuffing Fig. 3: Aufbau einer CAN-Nachricht im Standardformat 3.3 Aufbau einer Nachricht In Fig. 3 ist der Aufbau einer Nachricht im Standardformat, also mit 11 bit Identifier, dargestellt. Die einzelnen Felder haben folgende Bedeutung: Start of Frame (SOF) Dieses Bit signalisiert den Beginn einer Nachricht und wird immer dominant gesendet. Alle Teilnehmer werden dann darauf synchronisiert. Es darf nur angelegt werden, wenn der Bus frei ist, also nach 11 rezessiven Bits. Arbitrierungsfeld (Identifier + Remote Transmission Request Bit RTR) Dieses Feld besteht aus dem 11 Bit langen Nachrichten-Identifier, der die Nachricht eindeutig kennzeichnet und die Priorität beim Arbitrierungsvorgang bestimmt und dem RTR-Bit. Dieses bestimmt, ob mit der Nachricht Daten gesendet (Datentelegramm) oder angefordert werden (Datenanforderungstelegramm). Im Falle eines Datentelegramms wird es dominant gesendet um die Priorität gegenüber einem gleichen Datenanforderungstelegramm, bei dem das RTR-Bit rezessiv gesendet wird, zu erhöhen. Steuerfeld (Identifier Extension Bit IDE + reserviertes Bit r0 + Datenlängencode DLC) Dieses Feld enthält das IDE Bit, das anzeigt ob es sich um eine Nachricht im Standard- (wie in Fig. 3 dargestellt) oder im erweiterten Format handelt. Im Standardformat wird es dominant gesendet und somit hat eine Nachricht im Standardformat eine höhere Priorität als eine Nachricht im erweiterten Format mit gleichem Basisidentifier. Dann folgt ein dominant gesendetes reserviertes Bit und der Datenlängecode, der die Länge in Bytes des Datenfeldes angibt, die 0 bis 8 betragen kann. Werte größer 8 sind zulässig für spezielle Zwecke, das Datenfeld ist in diesem Fall 8 Byte lang. Datenfeld Hier stehen die eigentlich Nutzdaten. Das Datenfeld darf eine Länge von 0 bis 8 Byte haben. CRC-Feld (CRC-Prüfsumme + CRC-Delmimiter) Dieses Feld enthält eine Prüfsumme über den Header, also das SOF-Bit, das Arbitrierungs- und das Steuerfeld und das Datenfeld. Dabei kommt das Cyclic Redundancy Check Verfahren (CRC) zum Einsatz, wobei die zu prüfende Sequenz als Koeffiezienten eines Polynoms betrachtet werden die durch eine festgelegtes hier 15-stelliges Generatorpolynom geteilt werden und der auftretende Rest ist die Prüfsumme. Die vom Sender gebildete Prüfsumme wird mit übertragen und der Empfänger kann durch Vergleich mit der selbst gebildeten Prüfsumme erkennen, wenn Fehler aufgetreten sind. Der rezessiv übertragene CRC-Delimiter markiert den Abschluss der CRC-Prüfsumme. Bestätigungsfeld (Acknowledge-Slot ACK + Acknowledge-Delimiter) Im Acknowledge-Slot quittiert jeder Empfänger den erfolgreichen Empfang einer Nachricht mit dem

6 3 Datenübertragungsschicht 6 anlegen des dominanten Bits, unabhängig davon, ob er die Nachricht verarbeitet oder ignoriert. Im Fehlerfall legt er rezessiven Pegel an, den der Sender aber nur dann sieht, wenn keiner der Teilnehmer erfolgreichen Empfang signalisiert, der den rezessiven Pegel überschreiben würde. Das Bestätigungsfeld wird mit dem rezessiv gesendeten Acknowledge-Delimiter abgeschlossen. End of Frame (EOF) Der Abschluss der Nachricht wird eine Folge von sieben rezessiven Bits signalisiert. Anschließend muss auf dem Bus für den sogenannten Intermission Space von drei Bit noch rezessiver Pegel anliegen, danach ist der Bus frei und es kann wieder eine neue Nachricht gesendet werden. [Etschberger, 2002] 3.4 Fehlererkennung und -behandlung Der CAN-Standard sieht im Wesentlichen vier Maßnahmen zur Erkennung von Fehlern vor: Bitmonitoring Jede sendende Station überwacht zu jeder Bitzeit den Buspegel und vergleich diesen mit dem Pegel den sie selbst angelegt hat. Abweichungen bedeuten einen Fehler beim Senden. Message Frame Check Bitfelder die eine feste Form haben, wie die Delimiter oder das Frameende werden überprüft, ob hier unzulässige Bits vorkommen. Auch die CRC-Prüfung auf den Bereich vom Start of Frame bis zum Ende des Datenfeldes fällt darunter. Empfangsbestätigung Ein Sender interpretiert eine fehlende Empfangsbestätigung, das heißt eine rezessives ACK-Slot, als von ihm verursachter Fehler, denn dies kann nur dann auftreten, wenn kein einziger Empfänger den fehlerfreien Empfang quittiert hat. Bitstuffing Im Bereich vom Start of Frame bis zum Ende der Prüfsumme werden vom Sender sogenannte Stuffbits eingefügt, die der Nachsynchronisation dienen. Das heißt immer, wenn in der Nachricht fünf gleichwertige Bits nacheinander kommen, fügt der Sender als sechstes Bit ein komplementäres Bit mit genau der anderen Wertigkeit ein, das vom Empfänger wieder entfernt wird. Dadurch kann es in diesem Bereich nicht vorkommen, dass sechs gleichwertige Bits in Folge auftreten und wenn das passiert muss ein Fehler aufgetreten sein. Durch diese Maßnahmen wird eine sehr geringe Fehlerwahrscheinlichkeit, also die Wahrscheinlichkeit eines nicht erkannten Fehlers, von weniger als erreicht. Statistisch gesehen müsste ein CAN-Bussystem weit über 1000 Jahre ohne Unterbrechung laufen, bis es zu einem nicht erkannten Fehler kommt. Fehlerbehandlung Sofort nach der Erkennung eines Fehlers, d.h. bereits im nächsten Bitzeitintervall, beginnt der Teilnehmer der den Fehler erkannt hat, mit dem Senden eines Fehlerflags. Eine Ausnahme stellen CRC-Fehler dar, die erst nach dem Acknowledge-Delimiter signalisiert werden, um die Quittiermöglichkeit der anderen Teilnehmer nicht einzuschränken. Ein Fehlerflag besteht aus sechs gleichwertigen Bits und verstößt damit bewusst gegen die Bitstuffing- Regel. Somit erkennen alle anderen Busteilnehmer auch einen Fehler und schalten ihrerseits das Fehlerflag auf, der fehlererkennende Knoten teilt die Störung quasi busweit mit. Dadurch wird systemweite Datenkonsistenz gesichert, denn jedes Steuergerät wird die nun als fehlerhaft markierte Nachricht verwerfen. Der sendende Knoten versucht dann sofort die Nachricht noch einmal zu senden, was sich je nach momentanem Nachrichtenaufkommen durch die Arbitrierung verzögern kann. [Etschberger, 2002] 3.5 Eingrenzung defekter Knoten Im CAN-Bus betreiben alle Teilnehmer eine Art von freiwilliger Selbstkontrolle. Zu diesem Zweck hat jedes Steuergerät einen getrennten Sende- und Empfangsfehlerzähler. Steigen diese über bestimmte Schwellenwert, werden die Buszugriffsrechte des Knotens eingeschränkt. Somit ist eine Eingrenzung defekter Knoten möglich, die dann den Busverkehr nicht mehr stören können. Fehlerhaftes Senden / Empfangen Schlägt das Senden einer Nachricht fehl oder erkennt ein Empfänger einen Fehler in einer gesendeten

7 4 Physikalische Schicht 7 Nachricht, wird sein Sende- bzw. Empfangsfehlerzähler um einen bestimmten Wert inkrementiert. Die Höhe dieser Inkrementierung hängt entscheidend davon ab, ob der Knoten den Fehler als erstes erkennt oder nicht. Zusätzlich zu der normalen Erhöhung um 1 wird der Zählerstand in diesem Fall um 8 weitere Punkt erhöht. Dadurch wird der Tatsache Rechnung getragen, dass der Knoten den Fehler auch durch einen defekt seinerseits erkannt haben könnte, wohingegen alle anderen Knoten nur durch das nun folgende Fehlerflag den Fehler signalisieren mussten. Erfolgreiches Senden / Empfangen In diesem Fall wird der entsprechende Zähler um den Wert 1 dekrementiert. Knotenzustände Ob das Fehlerflag dominant oder rezessiv gesendet wird und einige andere Berechtigungen hängen davon ab, in welchem Zustand sich der Knoten befindet. Die drei möglichen Zustände fehleraktiv, fehlerpassiv und abgeschaltet richten sich nach dem Zählstand der beiden Fehlerzähler. Fehleraktiv (error active): beide Fehlerzählstände < 128 In diesem Zustand nimmt der Knoten ohne Einschränkungen am Busverkehr teil und sendet ein aktives, d.h. dominantes, Fehlerflag. Fehlerpassiv (error passive): einer der beiden Fehlerzählstände 128 In diesem Zustand darf der Knoten nur ein passives, d.h. rezessives, Fehlerflag senden, so dass er dadurch keine Nachricht zerstören kann. Weiterhin muss er vor dem Senden einer Nachricht eine zusätzliche Sperrzeit von 8 Bitzeiten gegenüber den fehleraktiven Knoten abwarten. Abgeschaltet (bus off): Sendefehlerzählstand > 255 Ein abgeschalteter Knoten darf den Bus in keiner Weise mehr beeinflussen, d.h. er darf gar nichts senden, auch kein Fehlerflag oder Acknowledge Bit. Ob er in diesem Zustand noch Nachrichten empfangen darf ist implementierungsabhängig. Die Höhe des Empfangsfehlerzählstandes ist hier unerheblich, ein Teilnehmer kann sich als nicht nur durch fehlerhaftes Empfangen in den Zustand bus off befördern, er muss auch mindestens 32 mal fehlerhaft gesendet haben. Der Knoten muss dann zurückgesetzt werden, d.h. nach Abwarten von 128 weiteren Nachrichten werden seine Zählerstände auf 0 gesetzt und er erhält wieder den Status fehleraktiv. [Etschberger, 2002] 4 Physikalische Schicht Die andere Schicht, die vom CAN-Standard implementiert wird, ist die Schicht 1 des ISO-OSI-Modells, die physikalische oder Bitübertragungsschicht. Zu Ihren Aufgaben zählen die Darstellung Codierung des Signals, die Synchronisation der Busteilnehmer, die Bereitstellung des physikalischen Busmediums und die Ankopplung der einzelnen Teilnehmer an dieses Medium, die Topologie des Netzwerkes und Maßnahmen zur Verbesserung der elektromagnetischen Verträglichkeit. 4.1 Dominanter und rezessiver Pegel Wie in Fig. 4 dargestellt, kann man eine CAN-Busleitung durch eine Open-Collector-Schaltung des Typs Wired-And realisieren. Dabei liegt der Bus im Ruhezustand auf dem Pegel der Versorgungsspannung von 5 V. Alle Sendetreiber sind über einen Transistor an die Busleitung gekoppelt, so dass der Bus auf Massepotential herunter gezogen wird, sobald wenigstens einer der Transistoren leitend ist, d.h. der Sendetreiber eine genügend große Spannun anlegt. Nun wird dem Potential 5 V der Versorgungsspannung der rezessive Pegel und das Bit 1 zugeordnet. Der dominante Pegel, dem das Bit 0 zugeordnet ist, entspricht dem Massepotential. Dieser Pegel ist deshalb dominant, weil er sofort den gesamten Bus auf Massepotential herunter zieht, sobald er von einer einzigen Station angelegt wird. Will ein Sender also ein rezessives Bit senden, legt er im entsprechenden Bitzeitintervall keine Spannung an den Sendetreiber an, will er dominant senden, legt er genügend Spannung an, so dass der Transistor leitend wird. [Etschberger, 2002]

8 4 Physikalische Schicht 8 5V Busleitung Sender 1 Empfänger 1 Sender 2 Empfänger 2 Sender 3 Empfänger 3 Fig. 4: Realisierung einer CAN-Busleitung durch eine Open-Collector-Schaltung (Wired-And-Schaltung) Protokoll- Controller 120 Ohm CAN_H CAN_L 120 Ohm Fig. 5: Zweidrahtleitung für Differenzsignalübertragung mit 120 Ω Abschlusswiderständen 4.2 Busmedium Der CAN-Standard sieht als Busmedium eine Zweidrahtleitung vor, wie in Fig. 5 dargestellt. Dabei kommt eine Differenzsignalübertragung zum Einsatz, d.h. eine der beiden Leitungen hängt an der Versorgungsspannung +5V (CAN H), die andere an -5V (CAN L) und beide haben eine gemeinsame Masse. Zur Signalübertragung wird dabei der Differenzpegel zwischen der CAN H und der CAN L Leitung benutzt. Der Vorteil dabei ist, dass sich die Pegelhübe addieren und der gesamt Pegelhub somit doppelt so groß ist. Weiterhin ist die Übertragung weniger störanfällig, da sich eine Potentialverschiebung, z.b. durch ein äußereres Magnetfeld, dann auf beide Leitungen auswirkt, die Pegeldifferenz dabei aber gleich bleibt. Die Abschlusswiderstände von 120 Ω sorgen für eine Dämpfung von hochfrequenten Signalreflexionen. Im Fall, dass ein Draht durch Bruch oder Kurzschluss ausfällt, ist die Leitung mit dem verbleibenden Draht weiter funktionsfähig und fällt nicht gleich komplett aus. Für sehr kostensensitive Anwendungen kann man aber auch auf den zweiten Draht verzichten. Dann hängt jedes Steuergerät statt am zweiten Draht an einer gemeinsamen Masse. Dieses System ist dadurch sehr viel störanfälliger und man erhöht deshalb den Pegelhub zwischen Masse und Versorgungsspannung. Weiterhin muss man geringere Datenübertragungsraten in Kauf nehmen. [Etschberger, 2002] 4.3 Signaldarstellung und Busankopplung Signalcodierung Beim CAN kommt die Non-Return-to-Zero (NRZ) Codierung zum Einsatz. Das bedeutet zwischen zwei gleichwertigen Bits bleibt der Pegel konstant und springt nicht auf ein Nullniveau zurück. Bitsynchronisation Diese Art der Signalcodierung erschwert allerdings die Bitsynchronisation, die immer nur an Flanken, d.h. an Signalpegelwechseln, stattfinden kann. Auf das Start of Frame Bit werden alle Busteilnehmer hart synchronisiert, d.h. alle anderen werden auf die Flanke desjenigen Knotens synchronisiert, der das SOF-Bit angelegt hat. Eine Nachsynchronisation kann später an jeder Flanke innerhalb eines gewissen Rahmens erfolgen. Das ist auch der Grund für das Bistuffing, wodurch sichergestellt wird, dass wenigstens nach fünf Bitzeiten wieder nachsynchronisiert werden kann.

9 5 Höhere Schichten 9 Busankopplung Jeder CAN-Protokollcontroller ist über einen Transceiverbaustein an das physikalische Busmedium angekoppelt. Dieser sorgt neben seiner Hauptaufgabe der Sende- und Empfangsverstärkung auch dafür, dass im Falle des Ausfalles eines Drahtes bei der Zweidrahtleitung ein Zurückfall auf eine Eindrahtübertragung möglich ist. [Etschberger, 2002] 5 Höhere Schichten Der CAN-Standard ist bewusst sehr offen gehalten und klammert einige Bereiche komplett aus. In der Spezifikation sind nur die Schichten 1 un 2 des ISO-OSI-Modells standardisiert, was für die Automobilindustrie auch ausreichend ist. Bei den hohen Stückzahlen in diesem Sektor kann jeder Hersteller den Bus auf seine Befürfnisse hin maßschneidern. Für die Automatisierungsindustrie ist aber wegen der geringeren Stückzahlen mehr Standardisierung wünschenswert, um die Interoperabilität von Geräten verschiedener Hersteller zu erleichtern. Dazu gehört die weitere Standardisierung von Schnittstellen und Vorgaben für Steckverbindungen, Kabel und dergleichen. Zu diesem Zweck und auch um die Protokollfunktionalität um zusätzliche Dienste der Schichten 3-7 des ISO-OSI-Schichtenmodells zu erweitern, wurden auf CAN aufsetzende Zusatzprotokolle entwickelt. Dadurch kann man die beiden Kommunikationsdienste unbestätigtes Senden und Anfordern von Nachrichten um zusätzliche Datenübertragungsmöglichkeiten erweitern, beispielsweise das Übertragen längerer Datensätze auf mehrere Nachrichten aufgeteilt oder die spezifische Bestätigung des Nachrichtenempfangs durch einen bestimmten Empfänger. CANopen Die Protokollerweiterung CANopen wurde von der Anwendergruppe CAN in Automation (CiA) entwickelt, einer Vereinigung von über 400 Firmen vorwiegend im europäischen Raum. Diese Schicht-7- Erweiterung bietet standardisierte Geräte- und Kommunikationsprofile mit denen man CANopen wie ein Baukastensystem auf die geforderte Anwendung zuschneiden kann. DeviceNet Ursprünglich von Allen-Bradley, einer Tochter der Nordamerikanischen Rockwell Automation, entwickelt, wird die Protokollerweiterung DeviceNet heute von der eigens gegründeten Open DeviceNet Vendor Association (ODVA) verwaltet und vertrieben. Sie bietet ebenfalls Geräteprofile und erlaubt neben dem Multi-Master-System von CAN auch Master/Slave und Peer-to-Peer Kommunikation. Daneben wurde standardisiert, dass Geräte über den Bus auch mit Strom versorgt werden können. [Etschberger, 2002] 6 Zusammenfassung CAN ist ein Feldbussystem, das ursprünglich entwickelt wurde, um den Verkabelungsaufwand in der Automobiltechnik zu reduzieren und Gewicht zu sparen. Heute kann man es als Standard für die Vernetzung von Steuergeräten im Automobil betrachten. Durch die hohe Verbreitung und die hohen Stückzahlen im Fahrzeugsektor sind Protokollcontroller und andere Komponenten sehr günstig. Für die Automatisierungstechnik wurden Zusatzprotokolle entwickelt, die den Funktionsumfang von CAN erweitern und die Vernetzung weiter standardisieren.

10 6 Zusammenfassung 10 Es handelt sich bei CAN um ein nachrichtenorientiertes Protokoll, d.h. die Nachrichten haben feste Kennungen und werden an alle Teilnehmer des Busses geschickt (Broadcast), tragen also keine Empfängeradresse. Der Buszugriff erfolgt nach dem CSMA-Verfahren (Carrier Sense Multiple Access) wobei alle Teilnehmer gleichberechtigt sind, es liegt also ein Multi-Master-System vor. Durch das Verfahren der Busarbitrierung werden Kollissionen von vornherein vermieden. Gleichzeitig wird so die Sendepriorität bestimmt, wobei höherpriore Nachrichten zuerst gesendet werden. Dabei ist CAN sehr zuverlässig und bietet sehr komplexe Fehlererkennungsmaßnahmen die eine sehr hohe Fehlererkennungsrate gewährleisten. Durch sofortige Fehlersignalisierung wird auch eine schnelle Sendewiederholung im Fehlerfall sichergestellt. Bei Verwendung der Zweidrahtübertragung profitiert man zusätzlich von hoher Ausfallsicherheit und geringer Anfälligkeit gegenüber elektromagnetischen Feldern. Als Nachteil kann man auslegen, dass CAN nicht deterministisch ist, wobei man aber obere Schranken für die maximale Übertragungszeit einer Nachricht einer bestimmten Priorität angeben kann. Hier gibt es aber auch schon eine Erweiterung, das Time Triggered CAN (TTCAN), das den Bus um eine zeitgesteuerte Variante ergänzt. Das größere Problem ist aber die begrenzte Datenübertragungsrate von maximal 1 MBit/s, was den CAN-Bus für Multimedia und andere Anwendungen die sehr hohe Datenraten benötigen ungeeignet macht. Literatur [Etschberger, 2002] [Lawrenz, 2000] Konrad Etschberger, et. al. Controller-Area-Network, 3. Auflage München / Wien: Carl Hanser Verlag, Wolfhard Lawrenz, et. al. CAN Controller Area Network - Grundlagen und Praxis, 4. Auflage Heidelberg: Hüthig Verlag, 2000 [Zimmermann, 2006] Werner Zimmermann, Ralf Schmidgall Bussysteme in der Fahrzeugtechnik - Protokolle und Standards Wiesbaden: Vieweg Verlag, 2006 [Reif, 2006] Konrad Reif Automobilelektronik - Eine Einführung für Ingenieure Wiesbaden: Vieweg Verlag, 2006 [ Harald Huppertz Kfz-Technik, Wissenswertes, Simulation, Fragen, Aufgaben