MeinA4.de
CAN-Bus - Bussyteme im Audi A4
In diesem Teil beschreibe ich die CAN-Busse, wie sie im Audi A4 zu finden sind und wie die Steuergeräte untereinander
via CAN verbunden sind.
Weiter werde ich hier mein selbst entworfenes und gebautes CAN-Interface vorstellen, welches zusätzlich die Fähigkeit hat, in Abhängigkeit von vordefinierten CAN-Botschaften bis zu drei Relais zu schalten oder zu tasten.
Der CAN-Bus arbeitet nach dem CSMA/CR (Carrier Sense Multiple Access/Collision Resolution) Verfahren, einem Verfahren, das der Entdeckung und Vermeidung von Kollisionen auf geteilten Medien dient. Bei CSMA/CR werden Kollisionen durch Bitarbitrierung vermieden. Die Bitarbitrierunglogik stellt eine Funktionseinheit in Form einer elektrischen, digitalen Schaltung oder einer Softwareroutine dar, die Zugriffskonflikte oder Zugriffskollisionen löst oder priorisiert. Dadurch wird erreicht, dass am Ende einer jeden Arbitrierungsphase lediglich der Teilnehmer, der über die höchste Nachrichtenpriorität verfügt, das Medium belegt.
Der Bus ist entweder mit Kupferleitungen oder über Glasfaser ausgeführt. Der CAN-Bus arbeitet nach dem "Multi-Master Prinzip": Mehrere gleichberechtigte Steuergeräte (bzw. Busteilnehmer) sind durch eine topologische Anordnung (beim Audi und bei den meisten anderen Fahrzeugen ist dies ein linearer Bus mit kurzen Stichleitungen) miteinander verbunden. Im Falle von Kupferleitungen arbeitet der CAN-Bus bei höheren Datenraten mit Differenzsignalen. Die Differenzsignale werden normalerweise mit 2 oder 3 Leitungen ausgeführt: CAN_HIGH, CAN_LOW und optional CAN_GND (Masse). CAN_LOW enthält den komplementären Pegel von CAN_HIGH gegen Masse. Dadurch können Gleichtaktstörungen unterdrückt werden, da die Differenz gleich bleibt.
Bei langsameren Bussen ('Komfort-Bus' z.B. zur Betätigung von Elementen durch den Benutzer) kann ein Eindrahtsystem mit der Karosserie als Masse reichen. Praktisch wird es meistens doch als Zweidrahtsystem ausgeführt, verwendet aber beim Lowspeed-CAN im Fehlerfall eines Aderbruchs den Eindrahtbetrieb als Rückfallebene, um den Betrieb weiterführen zu können. Um dort Störungen zu vermeiden wird es grundsätzlich verdrillt.
Die Busterminierung erfolgt beim CAN Bus mit 120 Ohm. Eine Terminierung ist auch schon bei kurzen Leitungen mit niedrigen Baudraten erforderlich, da sie bei CAN gleichzeitig als kombinierter Pullup und Pulldown Widerstand für alle Teilnehmer arbeitet. Ohne Terminierung gibt es nicht nur Reflexionen, sondern beide CAN Leitungen hängen in der Luft. In der Praxis reicht bei kurzen Leitungen eine Terminierung an einem Ende, idealerweise wird der Bus aber an beiden Enden (und nur dort) mit jeweils 120 Ohm terminiert.
Die Übertragung der Daten erfolgt so, dass ein Bit, je nach Zustand, entweder dominant oder rezessiv auf den Busleitungen wirkt. Ein dominantes (0) überschreibt dabei ein rezessives (1) Bit.
Die maximale Teilnehmeranzahl auf physikalischer Ebene hängt von den verwendeten Bustreiberbausteinen (Transceiver, physikalische Anschaltung an den Bus) ab. Mit gängigen Bausteinen sind 32, 64 oder bis zu 110 (mit Einschränkungen bis zu 128) Teilnehmer pro Leitung möglich (Erweiterungsmöglichkeit über Repeater oder Bridge).
Es wird zwischen einem Highspeed- und einem Lowspeed-Bus unterschieden. Bei einem Highspeed-Bus beträgt die maximale Datenübertragungsrate 1 Mbit/s, bei Lowspeed 125 kbit/s. Alle CAN-Knoten müssen die Nachricht gleichzeitig verarbeiten können; damit ergeben sich die maximalen (theoretischen) Leitungslängen, wie in der nachfolgenden Tabelle:
Der Objekt-Identifier kennzeichnet den Inhalt der Nachricht, nicht das Gerät. Er dient zudem auch der Priorisierung der Nachrichten. Zum Beispiel kann in einem Messsystem den Parametern Temperatur, Spannung, Druck jeweils ein eigener Identifier zugewiesen sein. Die Empfänger entscheiden anhand des Identifiers, ob die Nachricht für sie relevant ist oder nicht.
Die Spezifikation definiert zwei verschiedene Identifier-Formate:
Weiterführende Details siehe Quellen bei Wikipedia: CAN-Bus, CSMA/CR, Arbitrierung
Daraufhin habe ich mich dann entschieden, mir ein CAN-Interface zu bauen, dass ich vielseitiger nutzen kann.
Motiviert wurde ich von den Fähigkeiten des CAN-Adapters, den "Fuchs" 2005 entworfen und gebaut hat, wie man im umfangreichen Can-Hack-Forum nachlesen kann.
Er verwendet das von www.canusb.com bekannte Lawicel-Protokoll, das ASCII-basierend ist (Download CANUSB ASCII Command Manual).
Besondere Features des Adapters in Kombination mit der eigens dafür entwickelten Software Can-Hacker sind laut Forumsauszug:
Alle diese Punkte haben mich schnell überzeugt, da sie genau dem entsprechen, was ich benötige und so bin ich auf das Projekt von Mictronic gestoßen, dessen Projekt ich im Ansatz als Basis für meine Entwicklung genommen habe.
Mictronics verwendet einen AVR ATmega162, der mit dem doch sehr beliebten Philips SJA1000 Standalone CAN-Bus Controller, mit einem Philips PCA82C250 als CAN-Bustreiberbaustein (Transceiver), kommuniziert. Ein FT245BL sorgt in Kombination mit einem kleinen EEPROM (zum Speichern des "Multi Device Template" für den FT245BL) für die Kommunikation via USB mit dem PC.
Ich habe nun diesen Ansatz weiter verfolgt und habe als erstes den ATmega162 aus dem SMD-Gehäuse in ein DIL40-Gehäuse gesteckt, da ich diesen gesockelt einsetzen bzw. austauschen können will und so letzlich auch einfacher verlöten kann :o). Natürlich geschieht dieses auf Kosten der Platinengestaltung, insbesondere der Größe, was ich aber bereit war, in Kauf zu nehmen. Meine Platine hat nun die Maße 90mm x 126mm.
Weiter habe ich die Ausgänge des ATmega162 ein wenig optimiert, in dem ich diese umgelegt habe; zum Einen habe ich die JTAG-Pins mit rausgeführt, dafür die LEDs verschoben und die letzten drei freien PINs dazu verwendet drei Mini-Relais anzusteuern. Zum Anderen habe ich die CAN-Pins nicht nur auf einen Sub-D Stecker, sondern auch auf eine Wannenbuchse und eine Schraub-Klemme geführt, dabei habe ich auch die Pin-Belegung angepasst, so dass diese dem CiA entsprechen (Sub-D CAN-Stecker: CiA DS 102, RJ45 CAN-Stecker: CiA DRP 303-1, siehe z.B. auch CAN Pinbelegung).
Damit sieht mein Schaltplan dann folgendermaßen aus:
Die Bauteile habe ich auf meinem komplett umgestalteten Board, wie folgt angeordnet. Dieses hat nun somit auch eigentlich nichts mehr mit der Version von Mictronics zu tun, die ich mir als Vorbild genommen hatte:
Die nachfolgende Grafik zeigt meine vollstänig neu gestaltete Platine in einem ersten Eagle-Entwurf (es sind leider nicht alle Bauteile zum Rendern verfügbar, weshalb z.B. die Relais fehlen, sowie der SJA1000, Transistoren, Quarze etc.):
Die Firmware ist komplett in C geschrieben und basiert auch auf der veröffentlichten Version von Mictronics. Sobald diese vollständig fertig und getestet ist, werde ich diese hier neben den Eagle-Files zum Download anbieten.
Die entscheidenden Gedanken bei dem Design dieser CAN-Interface-Karte gehen über die Verwendung als einfachen CAN-Bus-Adapter hinaus. Über die USB-B-Buchse kann ein USB-Kabel angesteckt werden, welches das Interface dann als "normalen" CAN-Adapter einsetzbar macht. Es lassen sich so alle Funktionalitäten in Kombination mit dem CAN-Hacker umsetzen, wie oben von "Fuchs" zitiert.
Entfernt man jedoch den USB-Stecker, dann wird die USB-Peripherie stromlos gemacht und das Interface muss über die extra Schraubklemme mit der Fahrzeug-Boardspannung betrieben werden. Dadurch läuft die Firmware normal weiter und lauscht weiterhin auf dem CAN-Bus, reicht diese jedoch nicht an den USB weiter.
Bei bestimmten vorher definierten CAN-Identifieren mit bestimmten Daten kann dieser dann reagieren und entsprechend eines der drei Relais schalten oder kurz anziehen. Auf diesem Weg lässt sich beispielsweise über einen Taster des RNS-E ein Car-PC auf Wunsch einschalten und booten. Es können so beliebig drei physikalische Taster verwendet werden, die in ihrem Wirkungskreis von bestimmten CAN-Nachrichten des aktuellen CAN-Bus, der mit dem Interface abgehört wird, gesteuert werden.
Im Audi A4 gibt es drei CAN-Busse, die entsprechend durch signifikante Kabelfarben markiert und so gut erkennbar sind:
TO DO!
Da ich bisher noch keine Zeit hatte, dauert es hier noch ein wenig.
Also bitte habe noch etwas Geduld!
MfG. Andreas
Weiter werde ich hier mein selbst entworfenes und gebautes CAN-Interface vorstellen, welches zusätzlich die Fähigkeit hat, in Abhängigkeit von vordefinierten CAN-Botschaften bis zu drei Relais zu schalten oder zu tasten.
CAN-Einleitung
Der CAN-Bus (Controller Area Network) ist ein asynchrones, serielles Bussystem und gehört zu den Feldbussen. Um die Kabelbäume in Fahrzeugen zu reduzieren und dadurch neben der Flexibilität insbesondere Gewicht zu sparen, wurde der CAN-Bus 1983 von Bosch für die Vernetzung von Steuergeräten in Automobilen entwickelt und 1987 zusammen mit Intel vorgestellt.Der CAN-Bus arbeitet nach dem CSMA/CR (Carrier Sense Multiple Access/Collision Resolution) Verfahren, einem Verfahren, das der Entdeckung und Vermeidung von Kollisionen auf geteilten Medien dient. Bei CSMA/CR werden Kollisionen durch Bitarbitrierung vermieden. Die Bitarbitrierunglogik stellt eine Funktionseinheit in Form einer elektrischen, digitalen Schaltung oder einer Softwareroutine dar, die Zugriffskonflikte oder Zugriffskollisionen löst oder priorisiert. Dadurch wird erreicht, dass am Ende einer jeden Arbitrierungsphase lediglich der Teilnehmer, der über die höchste Nachrichtenpriorität verfügt, das Medium belegt.
Der Bus ist entweder mit Kupferleitungen oder über Glasfaser ausgeführt. Der CAN-Bus arbeitet nach dem "Multi-Master Prinzip": Mehrere gleichberechtigte Steuergeräte (bzw. Busteilnehmer) sind durch eine topologische Anordnung (beim Audi und bei den meisten anderen Fahrzeugen ist dies ein linearer Bus mit kurzen Stichleitungen) miteinander verbunden. Im Falle von Kupferleitungen arbeitet der CAN-Bus bei höheren Datenraten mit Differenzsignalen. Die Differenzsignale werden normalerweise mit 2 oder 3 Leitungen ausgeführt: CAN_HIGH, CAN_LOW und optional CAN_GND (Masse). CAN_LOW enthält den komplementären Pegel von CAN_HIGH gegen Masse. Dadurch können Gleichtaktstörungen unterdrückt werden, da die Differenz gleich bleibt.
Bei langsameren Bussen ('Komfort-Bus' z.B. zur Betätigung von Elementen durch den Benutzer) kann ein Eindrahtsystem mit der Karosserie als Masse reichen. Praktisch wird es meistens doch als Zweidrahtsystem ausgeführt, verwendet aber beim Lowspeed-CAN im Fehlerfall eines Aderbruchs den Eindrahtbetrieb als Rückfallebene, um den Betrieb weiterführen zu können. Um dort Störungen zu vermeiden wird es grundsätzlich verdrillt.
Die Busterminierung erfolgt beim CAN Bus mit 120 Ohm. Eine Terminierung ist auch schon bei kurzen Leitungen mit niedrigen Baudraten erforderlich, da sie bei CAN gleichzeitig als kombinierter Pullup und Pulldown Widerstand für alle Teilnehmer arbeitet. Ohne Terminierung gibt es nicht nur Reflexionen, sondern beide CAN Leitungen hängen in der Luft. In der Praxis reicht bei kurzen Leitungen eine Terminierung an einem Ende, idealerweise wird der Bus aber an beiden Enden (und nur dort) mit jeweils 120 Ohm terminiert.
Die Übertragung der Daten erfolgt so, dass ein Bit, je nach Zustand, entweder dominant oder rezessiv auf den Busleitungen wirkt. Ein dominantes (0) überschreibt dabei ein rezessives (1) Bit.
Die maximale Teilnehmeranzahl auf physikalischer Ebene hängt von den verwendeten Bustreiberbausteinen (Transceiver, physikalische Anschaltung an den Bus) ab. Mit gängigen Bausteinen sind 32, 64 oder bis zu 110 (mit Einschränkungen bis zu 128) Teilnehmer pro Leitung möglich (Erweiterungsmöglichkeit über Repeater oder Bridge).
Es wird zwischen einem Highspeed- und einem Lowspeed-Bus unterschieden. Bei einem Highspeed-Bus beträgt die maximale Datenübertragungsrate 1 Mbit/s, bei Lowspeed 125 kbit/s. Alle CAN-Knoten müssen die Nachricht gleichzeitig verarbeiten können; damit ergeben sich die maximalen (theoretischen) Leitungslängen, wie in der nachfolgenden Tabelle:
| Übertragungsrate | Leitungslänge |
| 10 kbits/s | 6,7 km |
| 20 kbits/s | 1,3 km |
| 125 kbits/s | 530 m |
| 250 kbits/s | 270 m |
| 500 kbits/s | 130 m |
| 1 Mbits/s | 40 m |
Der Objekt-Identifier kennzeichnet den Inhalt der Nachricht, nicht das Gerät. Er dient zudem auch der Priorisierung der Nachrichten. Zum Beispiel kann in einem Messsystem den Parametern Temperatur, Spannung, Druck jeweils ein eigener Identifier zugewiesen sein. Die Empfänger entscheiden anhand des Identifiers, ob die Nachricht für sie relevant ist oder nicht.
Die Spezifikation definiert zwei verschiedene Identifier-Formate:
- 11-Bit-Identifier, auch "Base frame format" genannt (CAN 2.0A)
- 29-Bit-Identifier, auch "Extended frame format" genannt (CAN 2.0B).
Weiterführende Details siehe Quellen bei Wikipedia: CAN-Bus, CSMA/CR, Arbitrierung
Mein CAN-Interface
Nachdem ich mich lange Zeit nach einem geeigneten CAN-Adapter umgesehen habe und prinzipiell eine Menge guter Geräte gefunden hatte, war ich am Ende dann doch zu geizig mindestens 100 Euro für einen Adapter auszugeben, auf dessen Firmware ich keinen Einfluss habe und dessen Funktionsrahmen dann für zukünftige Situation zu unflexibel ist.Daraufhin habe ich mich dann entschieden, mir ein CAN-Interface zu bauen, dass ich vielseitiger nutzen kann.
Motiviert wurde ich von den Fähigkeiten des CAN-Adapters, den "Fuchs" 2005 entworfen und gebaut hat, wie man im umfangreichen Can-Hack-Forum nachlesen kann.
Er verwendet das von www.canusb.com bekannte Lawicel-Protokoll, das ASCII-basierend ist (Download CANUSB ASCII Command Manual).
Besondere Features des Adapters in Kombination mit der eigens dafür entwickelten Software Can-Hacker sind laut Forumsauszug:
- Feste Baudraten (10/20/50/100/125/250/500/800/1000bps)
- Benutzerdefinierte Baudraten
- Identifier Filter (Bitmaske, Bereich, einzelne ID's)
- 11 Bit Identifier
- 29 Bit Identifier
- Listen Only Modus
- Nachrichten senden (Anzahl beliebig)
- Nachrichten automatisch wiederholen
- Datalogger mit Speicher- und Abspielfunktion
- Hinzufügen von Kommentaren
- Automatisches Abspeichern der Einstellungen
- Detaillierte Darstellung als Hex und Dezimalwert + Bargraph
- Darstellung in ASCII und Dezimal
- Unterstützung vom d2xx USB Treiber für größeren Datendurchsatz
- Unterscheidung zwischen RTR und DLC=0 nachrichten
- Automatisches antworten auf RTR anfragen
- Antwort auf definierbare Nachrichten
- Windows Vista kompatibel
- Einfache Bedienung
Alle diese Punkte haben mich schnell überzeugt, da sie genau dem entsprechen, was ich benötige und so bin ich auf das Projekt von Mictronic gestoßen, dessen Projekt ich im Ansatz als Basis für meine Entwicklung genommen habe.
Mictronics verwendet einen AVR ATmega162, der mit dem doch sehr beliebten Philips SJA1000 Standalone CAN-Bus Controller, mit einem Philips PCA82C250 als CAN-Bustreiberbaustein (Transceiver), kommuniziert. Ein FT245BL sorgt in Kombination mit einem kleinen EEPROM (zum Speichern des "Multi Device Template" für den FT245BL) für die Kommunikation via USB mit dem PC.
Ich habe nun diesen Ansatz weiter verfolgt und habe als erstes den ATmega162 aus dem SMD-Gehäuse in ein DIL40-Gehäuse gesteckt, da ich diesen gesockelt einsetzen bzw. austauschen können will und so letzlich auch einfacher verlöten kann :o). Natürlich geschieht dieses auf Kosten der Platinengestaltung, insbesondere der Größe, was ich aber bereit war, in Kauf zu nehmen. Meine Platine hat nun die Maße 90mm x 126mm.
Weiter habe ich die Ausgänge des ATmega162 ein wenig optimiert, in dem ich diese umgelegt habe; zum Einen habe ich die JTAG-Pins mit rausgeführt, dafür die LEDs verschoben und die letzten drei freien PINs dazu verwendet drei Mini-Relais anzusteuern. Zum Anderen habe ich die CAN-Pins nicht nur auf einen Sub-D Stecker, sondern auch auf eine Wannenbuchse und eine Schraub-Klemme geführt, dabei habe ich auch die Pin-Belegung angepasst, so dass diese dem CiA entsprechen (Sub-D CAN-Stecker: CiA DS 102, RJ45 CAN-Stecker: CiA DRP 303-1, siehe z.B. auch CAN Pinbelegung).
Damit sieht mein Schaltplan dann folgendermaßen aus:
Die Bauteile habe ich auf meinem komplett umgestalteten Board, wie folgt angeordnet. Dieses hat nun somit auch eigentlich nichts mehr mit der Version von Mictronics zu tun, die ich mir als Vorbild genommen hatte:
Die nachfolgende Grafik zeigt meine vollstänig neu gestaltete Platine in einem ersten Eagle-Entwurf (es sind leider nicht alle Bauteile zum Rendern verfügbar, weshalb z.B. die Relais fehlen, sowie der SJA1000, Transistoren, Quarze etc.):
Die Firmware ist komplett in C geschrieben und basiert auch auf der veröffentlichten Version von Mictronics. Sobald diese vollständig fertig und getestet ist, werde ich diese hier neben den Eagle-Files zum Download anbieten.
Die entscheidenden Gedanken bei dem Design dieser CAN-Interface-Karte gehen über die Verwendung als einfachen CAN-Bus-Adapter hinaus. Über die USB-B-Buchse kann ein USB-Kabel angesteckt werden, welches das Interface dann als "normalen" CAN-Adapter einsetzbar macht. Es lassen sich so alle Funktionalitäten in Kombination mit dem CAN-Hacker umsetzen, wie oben von "Fuchs" zitiert.
Entfernt man jedoch den USB-Stecker, dann wird die USB-Peripherie stromlos gemacht und das Interface muss über die extra Schraubklemme mit der Fahrzeug-Boardspannung betrieben werden. Dadurch läuft die Firmware normal weiter und lauscht weiterhin auf dem CAN-Bus, reicht diese jedoch nicht an den USB weiter.
Bei bestimmten vorher definierten CAN-Identifieren mit bestimmten Daten kann dieser dann reagieren und entsprechend eines der drei Relais schalten oder kurz anziehen. Auf diesem Weg lässt sich beispielsweise über einen Taster des RNS-E ein Car-PC auf Wunsch einschalten und booten. Es können so beliebig drei physikalische Taster verwendet werden, die in ihrem Wirkungskreis von bestimmten CAN-Nachrichten des aktuellen CAN-Bus, der mit dem Interface abgehört wird, gesteuert werden.
CAN im Audi A4
Im Audi A4 gibt es drei CAN-Busse, die entsprechend durch signifikante Kabelfarben markiert und so gut erkennbar sind:
- CAN-Antrieb (500 kBaud) [CAN-High Kabelfarbe: orange/schwarz]
- CAN-Komfort (100 kBaud) [CAN-High Kabelfarbe: orange/grün]
- CAN-Infotainment (100 kBaud) [CAN-High Kabelfarbe: orange/violett]
Bekannte CAN-Identifier
| Identifier | Daten | Beschreibung | Absender/Bedingungen | Takterate |
| 0x261 | 8 Byte mit FIS-Zeichen | erste Zeile FIS | rotes Display | min. jede Sekunde |
| 0x263 | 8 Byte mit FIS-Zeichen | zweite Zeile FIS | rotes Display | min. jede Sekunde |
TO DO!
Da ich bisher noch keine Zeit hatte, dauert es hier noch ein wenig.
Also bitte habe noch etwas Geduld!
MfG. Andreas
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Aktualisiert am 09.11.2021, 22:01:56 Uhr
