Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner. CAN-Bus

Transkript

1 Universität Stuttgart Prof. Dr.-Ing. Dr. h. c. P. Göhner 1 Allgemeines 1.1 Historie CAN-Bus Die Abkürzung CAN steht für Controller Area Network. Das Bussystem wurde von der Robert Bosch GmbH in den 80er-Jahren entwickelt und hatte ihr ursprünglichen Anwendungsfeld im Kfz-Bereich. Grund der Entwicklung war der zunehmende Anteil an Steuerungs- und Regelungstechnik (ABS, ASR), der eine Kommunikation unterschiedlicher Komponenten erfordert. Durch die hohen Stückzahlen und die weite Verbreitung, die sich durch das Anwendungsfeld Kfz ergaben, wurden die Vorraussetzungen für eine Standardisierung und niedrigere Preise geschaffen. Dies hatte zur Folge, dass CAN mittlerweile in weiteren Bereichen, die einen Feldbus benötigen, eingesetzt wird. 1.2 Grundlagen Im Anwendungsgebiet Kfz-Elektronik gibt es strenge zeitliche Anforderungen, sowie einen regen Datenaustausch, d.h. eine hohe Anzahl von Kommunikationsvorgängen, aber nur kleine Datenpakete. (Erweiterung heute: Navigationssystem usw. => anderes Kommunikationssystem dafür notwendig) Minimierung des Verkabelungsaufwands hohe Fehlersicherheit (stör-/ausfallsicher), Robustheit geringe Latenzzeit (d.h. Zeit zwischen gewünschtem Sendebeginn und tatsächlichem Sendebeginn so gering als möglich) verteilte Systeme, mehrere Adressaten gute Erweiterbarkeit Priorisierung von Nachrichten kostengünstig Um den Verkabelungsaufwand zu verringern kam nur ein Bussystem in Frage. Die Robert Bosch GmbH setzte die Anforderungen in ein Protokoll, das CAN-Protokoll um.

2 Automatisierungstechnik 1 Theorie zu Übung 2: CAN-Bus Überblick über ISO/OSI -Schichtenmodell Application Layer (7) Layer 7: Durchführung der Feldbusaufgaben Presentation Layer (6) Session Layer (5) Transportation Layer (4) Network Layer (3) Data Link Layer (2) Physical Layer (1) Layer 2: Buszugriff, Rahmenformat & -prüfung, Adressierung Layer 1: Definition Übertragungsmedium & Steckverbindungen, Pegel, Codierung, Bitrate Von den 7 Schichten finden die blau eingefärbten Schichten (1,2 und 7) bei den Feldbussen Berücksichtigung.

3 Automatisierungstechnik 1 Theorie zu Übung 2: CAN-Bus 3 2 CAN-Beschreibung 2.1 OSI-Schicht 1: physical layer Grundsätzlich ist CAN für die serielle Datenübertragung in einer Bus-Topologie ausgelegt. Die CAN-Spezifikation legt das Übertragungsmedium aber nicht fest. In den ISO-Standards wird als Übertragungsmedium für CAN eine elektrische, differenzielle 2-Drahtleitung (RS 485) vorgesehen. Im Fehlerfall kann die Übertragung jedoch auch mit einer 1-Drahtleitung und gleichem Bezugspotenzial (Massepotenzial) vorgenommen werden. Der Vorteil der Differenzspannungsübertragung auf einer 2-Drahtleitung gegenüber einer 1-Drahtleitung ist die geringere Anfälligkeit für Potenzialunterschiede und Störeinkopplungen auf der Leitung. 2.2 OSI-Schicht 2a: MAC = Media Access Control Als Zugriffsverfahren verwendet der CAN-Bus CSMA/CA (Carrier Sense Multiple Access / Collision Avoidence). Dabei arbeitet das Verfahren nach dem folgenden Schema: Jeder sendewillige Teilnehmer hört, ob der Bus belegt ist (Carrier Sense) und beginnt mit seinem Sendevorgang, wenn der Bus eine gewisse Zeit unbelegt war. Es besteht dabei die Möglichkeit, dass mehrere Teilnehmer gleichzeitig zu senden beginnen (Multiple Access). Die Auflösung einer evtl. auftretenden Kollision erfolgt im Rahmen des Arbitrierungsprozess. Dabei beginnen alle sendewilligen Teilnehmer damit den Frame (beginnend mit dem Identifier) Bit für Bit aufzuschalten. Nach jedem au Bit überprüft der Sender, ob der von ihm aufgeschaltete Pegel auch tatsächlich dem auf dem Bus anliegenden Pegel entspricht. Ist dies nicht der Fall, stellt er sofort seinen Sendevorgang ein. Dies hat zur Folge, dass die höchstpriore Nachricht den Buszugriff erhält, ohne dass dabei die Nachricht zerstört wird (Collision Avoidance). Die Realisierung von dominantem und rezessiven Pegel lässt sich anhand einer wired-and Schaltung erläutern. Null entspricht dabei dem dominanten Pegel, da bei einem Masseschluss der gesamte Bus auf das Massepotential gezogen wird, während eine logische Eins den rezessiven Pegel darstellt, der bei vorhandenem Masseschluss nicht gehalten wird. Pegel 5V S S S Bus Busleitung S1 E1 S2 E2 S3 E3 Abbildung 1: wired-and Schaltung

4 Automatisierungstechnik 1 Theorie zu Übung 2: CAN-Bus OSI-Schicht 2b: LLC- Logical Link Control Die Kommunikation auf dem Bus basiert auf vier unterschiedlichen Telegrammformaten: 1.) Datentelegramm (data frame) Das Datentelegramm dient zur Übertragung von Daten von einer Quelle zu einem oder mehreren Empfängern auf Initiative des Senders (der Quelle). rezessiv RTR-Bit (Remote-Transmission-Request) Begrenzungsbits Anzahl Bits Objekt- Datenfeld End-of- Identifier Frame Feld Arbitrierungsfeld Steuerfeld CRC- Segment ACK Slot Interframe Space Start-of-Frame-Bit Data Frame CRC-Feld Acknowledge- Feld Abbildung 2: Aufbau eines Datentelegramms Format Anforderungsrahmen: RTR-Bit= 1 kein Datenfeld Start of Frame: 1 dominaten Bit zur Kennzeichnung des Beginns Arbitrierungsfeld: 11 Bit Identifier + 1 Bit RTR Steuerfeld: 2 Bits reserviert für extended CAN, 4 Bits für Datenlänge Datenfeld: 0-8 Byte an Daten möglich beginnend mit MSB CRC-Feld: 15 Bit Generator-Polynom(x 15 +x 14 +x 10 +x 8 +x 7 +x 4 +x 3 +1) + 1 rezessives CRC Begrenzungsbit ACK-Feld: 1 Bit ACK-Slot + 1 Bit ACK-Begrenzung (rezessiv): sendender Knoten überträgt rezessives Bit im Slot; Knoten, die fehlerfrei empfangen haben, senden dominantes Bit im Slot. End of Frame: 7 Bit Insgesamt ergibt sich somit eine Mindestrahmenlänge von 44 Bit. Dazu kommen noch 0-64 Datenbits und evtl. Stuff-Bits. 2.) Datenanforderungstelegramm (remote frame) Das Datenanforderungstelegramm dient einem Busteilnehmer dazu das Senden eines bestimmten Datentelegramms mit demselben Identifier durch eine Datenquelle

5 Automatisierungstechnik 1 Theorie zu Übung 2: CAN-Bus 5 auszulösen. Dabei unterscheiden sich Datentelegramm und Datenanforderungstelegramm lediglich in einem unterschiedlichen RTR-Bit (bei Datenanforderungstelegramm RTR-Bit = 1, für Datentelegramm RTR-Bit = 0) und einem fehlenden Datenfeld beim Datenanforderungstelegramm. Daraus ergibt sich, dass bei zeitgleicher Anforderung und Übertragung einer Nachricht sich das Datentelegramm durchsetzen wird. 3.) Fehlertelegramm (error frame) Erkennt ein Busteilnehmer eine fehlerhaft übertragene Nachricht (z.b. durch falsche Prüfsumme im CRC-Feld), so meldet er dies durch das Aussenden eines Fehlertelegramms. Dabei wird eine im normalen Betrieb nicht zulässige Signalfolge (6 Bits mit gleicher Polarität) auf den Bus aufgeschaltet. Dies hat zur Folge, dass alle anderen (funktionstüchtigen Knoten) ihrerseits ein Fehlertelegramm aufschalten, da die Bit-Stuffing Regel verletzt wurde. Beendet wird ein Fehlertelegramm durch 8 rezessive Bits. 4.) Überlasttelegramm (overload frame) Ein Überlasttelegramm wird zur Vergrößerung des Telegrammzwischenraums verwendet. Dabei kann ein Überlasttelegramm nur zu Beginn eines Telegrammzwischenraums gesendet werden. Durch das Aufschalten von 6 dominanten Bits (Überlastflag) wird die festgelegte Form des Telegrammzwischenraums zerstört und damit die Überlast signalisiert. Als Folge davon senden alle Netzknoten ebenfalls ein Überlasttelegramm. 2.4 OSI-Schicht 7: Applikationen Während für die Schichten 1 und 2 bereits internationale Standardisierungen vorgesehen sind (ISO-DIS und ISO-DIS ), gibt es für die Applikationsschicht noch keine Norm. Durch die Einführung einer Schicht 7 kann man Applikationsprozesse vollständig von den Kommunikationsprozessen abkoppeln. Die Nutzerorganisation CiAe.V. ist bestrebt, eine einheitliche Applikationsschicht-Definition CAL (CAN Application Layer) herbeizuführen, um für die Entwicklung von verteilten Anwendungen auf eine einheitliche Sprache zurückgreifen zu können. Sie soll die Kommunikation von CAN-Modulen unterschiedlicher Hersteller ermöglichen. Für weiter gehende Informationen sei hier auf das Buch von Konrad Etschberger CAN-Controller Area-Network Grundlagen, Protokolle, Bausteine, Anwendungen erschienen 1994 im Carl Hanser Verlag München verwiesen. 2.5 Sicherheitsmechanismen: Um die Störanfälligkeit des CAN-Bus zu verringern, sind die folgenden Sicherheitsmechanismen realisiert: 1.) Bit Monitoring Beim Bit Monitoring überprüft jeder Sender, ob ein von ihm aufgeschalteter Pegel auch tatsächlich auf dem Bus anliegt. Ist dies nicht der Fall, so ist entweder eine Störung aufgetreten, die aufgelöst werden muss oder der Sendevorgang muss eingestellt werden (Arbitrierungsphase).

6 Automatisierungstechnik 1 Theorie zu Übung 2: CAN-Bus 6 2.) Überprüfung des Telegramm-Format Durch die feste Vorgabe des Telegrammformats ist es jedem Busteilnehmer möglich zu überprüfen, ob dieses eingehalten wird (z.b. rezessive Begrenzungsbits). Ist dies nicht der Fall, so liegt eine Störung vor. 3.) Cyclic Redundancy Check Die übertragene Nachricht wird mittels CRC nochmals gesichert. Dabei wird die Nachricht durch ein spezielles Generatorpolynom dividiert und dieses Ergebnis im CRC- Feld abgelegt. Beim Empfang einer Nachricht wird diese vom Empfänger nochmals durch das Generatorpolynom dividiert und das Ergebnis mit dem übertragenen CRC-Feld überprüft. Stimmen beide nicht überein, so ist ein Übertragungsfehler aufgetreten. (Generatorpolynom x 15 +x 14 +x 10 +x 8 +x 7 +x 4 +x 3 +1) 4.) Bit-Stuffing Beim CAN-Bus wird eine sog. NRZ Codierung verwendet ( No Return to Zero ). Dies bedeutet jedoch, dass es längere Phasen ohne Bitflanken zur Synchronisation gibt. Um dies zu vermeiden wird nach 5 gleichwertigen Bit ein invertiertes Stuff-Bit gesetzt. Dieses Bit ermöglicht die Synchronisation der einzelnen Knoten und wird beim Empfang wieder entfernt. 2.6 Ausführliches Bitzeiten-Modell nominelle Bitzeit Signalausbreitungssegment Synchronisationssegment Phasensegment 1 Phasensegment 2 Abbildung 3 : Bitzeitenmodell des CAN Die Bitzeit der CAN-Nachricht setzt sich aus mehreren Controllerzeiteinheiten zusammen und kann/muss an das Netzwerk angepasst werden. Eine Zeiteinheit entspricht dabei der Periodendauer des auf dem Controller vorhandenen Oszillator. Synchronisationssegment 1 Zeiteinheit lang, Empfänger startet internes Bittiming Signalausbreitungssegment 1..8 Zeiteinheiten lang, Fängt doppelte Signallaufzeit und elektrische Schaltzeiten ab Phasensegment Zeiteinheiten lang, Dient zur Nachsynchronisation, wenn Senderoszillator langsamer als Empfängeroszillator

7 Automatisierungstechnik 1 Theorie zu Übung 2: CAN-Bus 7 Phasensegment 2 Maximalwert aus Phasensegment 1 und Informationsverarbeitungszeit Dient zur Nachsynchronisation, wenn Empfängeroszillator langsamer als Senderoszillator 3 Ergänzung 3.1 unterschiedliche Spezifikationen Zunächst muss man zwischen CAN-Controllern der Spezifikation 2.0A und 2.0B differenzieren. 2.0A legt einen Identifier von 11 Bit fest, es können 2032 Nachrichtentypen unterschieden werden (die Einschränkung gegenüber dem theoretisch möglichen Wert von 2048 wird durch einen Intel-Controller mit eingeschränkter Verarbeitung bedingt). Die ExtendedCAN -Version 2.0B weist einen 29-Bit langen Identifier auf, womit über 500 Millionen verschiedene Nachrichtentypen definiert werden können. In einem CAN-Netze können zwar gemischt CAN-Controller nach 2.0A und 2.0B betrieben werden, es dürfen dann allerdings nur 11-Bit- Identifier verwendet werden. 3.2 Versionen der Controller Hinsichtlich der Implementierung des CAN-Protokolls differenziert man zwischen BasicCAN und FullCAN. Beides betrifft die Nachrichtenfilterung auf dem Netz. Da die Nachrichten keine Zieladresse beinhaltet, sondern als Broadcast über das Netz geschickt werden, muss jeder Netzknoten selbst entscheiden, welche Nachrichten für ihn interessant sind und diese durch Akzeptanzfilter herausfiltern. Bei FullCAN geschieht diese Filterung durch den CAN- Controller selbst, bei BasicCan erst durch den nachgeschalteten Mikrocontroller. Auf die Buskommunikation wirkt sich dies jedoch nicht aus, beide Arten können also wiederum gemischt im Netz betrieben werden.