Die Kommunikation zwischen den Komponenten des Navigationssystem im BMW E39 erfolgt über den sog. IBus (Instrumentenbus). Technisch gesehen ist IBus eine Version des LIN-Buses.
Hier ist das Diagramm, welche Geräte sich an der Kommunikation beteiligen:
Wie man sieht, stellt das IKE (Intrumentenkombination) das Gateway zu den anderen Bussystemen dar, wie zum Beispiel zum CAN-Bus (Motorsteuerung), D-Bus (Diagnosebus) und dem K-Bus (Karosseriebus). IKE spielt gleichzeitig auch die Rolle des Busmasters.
Protokoll des IBus:
In BMW Fahrzeugen ist das Protokoll über das die einzelnen Steuergeräte in den Netzwerken kommunizieren nach dem folgenden Schema aufgebaut:
- Quell ID: Identifikation des Teilnehmers der eine Nachricht an einen anderen BUS-Teilnehmer senden will
- Länge: Länge der kompletten Nachricht (ohne Quell ID und Längenangabe selbst)
- Ziel ID: Identifikation des Teilnehmers an den die Nachricht gesendet werden
- Daten: Nutzdaten den Nachricht
- XOR CRC: XOR CRC – Checksumme
Aufbau der Nachricht:
![]()
Jedes Netzwerk (K-Bus, I-Bus und D-Bus) überträgt Daten mit einer Baudrate von 9600 Bit pro Sekunde. Das Kommunikationsprotokoll hat 8 Daten-Bits, 1 Stop-Bit und gerade Parität (even).
Die Implementierung bei BMW sieht als Busmaster die Instumentenkombination vor. Nur wenn die IKE nichts sendet dürfen sich andere Busteilnehmer ‚unterhalten’. Dies erleichtert die Integration zusätzlicher Steuergeräte, z.B. MP3-Player und kann die Reaktionszeit verkürzen, z.B. Lenkradtasten. Auf dem I-Bus (wie auch den anderen Bussystemen) können bei hoher Buslast Kollisionen als Tribut an die Flexibilität auftreten. Daher verwendet BMW je nach Ausstattung mehrere Busse.
- Folgende Mechanismen sind für die Kommunikation am I-Bus implementiert:
- der Busmaster (IKE) hat Priorität
- bis auf Broadcasts ist jede Botschaft (Request) zu bestätigen (Response) (dies trifft nicht für alle Botschaften zu, hier sieht der I-Bus dann eine entsprechende Kodierung vor)
- wenn der Bus eine definierte Zeit (z.B. 20-100ms, nach Request erst nach dem Timeout, z.B. 100-1000ms) nicht belegt ist, dürfen andere Teilnehmer einen Request senden
- nicht jeder Busteilnehmer wartet die gleiche Zeit (dies ist zwar nicht explizit geregelt, ergibt sich aber aus den Signallaufzeiten und Timingunterschieden in den Steuergeräten)
- nach einer gewissen Übertragungszeit muss der Bus für andere Steuergeräte ‚geöffnet’ werden
- Kollisionserkennung ist zu verwenden, insbesondere sollte das Echo überprüft werden.
- es wird eine Adress-Arbitrierung verwendet: Der Sender mit der höchsten Adresse erhält den Buszugriff, wenn 2 oder mehr Teilnehmer gleichzeitig auf den Bus zugreifen. Dies funktioniert folgendermaßen: Während die Sendeadresse Bit für Bit auf den Bus gelegt wird, wird der Zustand der Leitung überprüft. Überträgt ein Steuergerät z.B. eine 0 (High-Pegel) und die Leitung wird Low, muss es den Bus abgeben (ohne die laufende Übertragung der anderen Steuergeräte zu stören). Bei Gleichheit entscheidet das nächste Bit. Adresse binär 00100100 ist höher als 00100011.
- Kommandos/Botschaften werden im Steuergerät intern priorisiert. Entsprechend der Priorität wird eine unterschiedliche Pause zwischen den Botschaften (‚Botschaftsabhängige Wartezeit’) verwendet: Prio 1 ab 1,7ms, 2 ab 2.3ms und 3 ab 10ms. Bei Kollisionen wird eine vordefinierte ‚Konfliktwartezeit’ verwendet, die für Steuergeräte in der gleiche Domäne (gleiche Position des ersten rezessiven Bits in der Adresse) unterschiedlich ist.
- sollte auf einen Request keine Antwort kommen, wird er bis zu 5 Mal nach jeweils 300ms Wartezeit wiederholt
Da die oben genannten Mechanismen nur aufwendig zu implementieren sin reicht in der Praxis das folgendes Vorgehen zum senden von Nachrichten aus:
Bevor eine Nachricht gesendet wird muß auf auf den Ruhezustand des Busses gewartet werden. Dieser ist erreicht wenn für eine gewisse Zeit kein Datentransfehr stattfindet. Die Zeit errechnet sich aus der Datenrate des Busses und dem Datenrahmen der Seriellen Verbindung von 10Bit/Zeichen. Dieser Datenrahmen ist in der nachfolgenden Rechnung bereits berücksichtigt (0,104ms/Bit * 10Bit).
Im Netzwerk werden die Geräte über eine eindeutige ID identifiziert. Die Länge der ID ist immer ein Byte:
| Gerät ID | Names des Geräts |
| 00 | Allgemeine Nachrichten, Broadcast |
| 18 |
CD-Wechsler |
| 30 |
SES, Spracheingabe |
| 3B |
Videomodul |
| 3F |
DIS |
| 43 |
Menübildschirm auf Bordmonitor |
| 50 |
Lenkradtasten, linker Tastenblock |
| 60 |
PDC |
| 68 |
Radio |
| 6A |
DSP (Signalprozessor) |
| 7F |
GPS-Sensor |
| 80 |
IKE, Instrumentenkombination |
| BB |
TV-Modul im Videomodul |
| BF |
LCM, Lichtkontrollmodul |
| C8 | Telefon |
| D0 |
Navigationsdaten |
| E7 |
Textzeile im IKE |
| F0 |
Bordmonitortasten |
| FF |
Allgemeine Nachrichte, Broadcast |
Die Liste der Geräte im BMW 850Ci ist sehr viel übersichtlicher als die des E39:
| Gerät ID |
Name des Gerätes |
| 01 |
MID, Multi Informations Display |
| 02 |
EKM, Elektronisches Karosserie Modul |
| 09 |
Zentralle Karosserie Elektronik |
| FF |
Broadcast |
Hier eine kleine Liste der LIN-Transceiver:
- Microchip: MCP201, MCP2021, MCP2022
- Infineon: TLE6258, TLE7259
- Melexis: TH3122, TH3044
- Philips: TJA1020
- AtMel: ATA66x2 oder ATA66x3, es gibt von AtMel sogar MCUs mit integrierten LIN-Transceiver, wie zum Beispiel ATA6613
