Reverse Engineering des Batterie-Sensors

So langam frage ich mich ob Ford das würfelt?

Nachdem ich nun auch einen Batteriesensor im Fahrzeug habe, gebe ich mich mal ans Decoding der Nachrichten die dieser mit dem BCM so austauscht. Mein erster Test war einfach mal ein Oszi dran hängen (kleiner Tipp: mit einem "Ossi" klappt es leider nicht!) und siehe da: nach dem einschalten der Zündung habe ich dort heftigen Grenzverkehr

Dann werde ich mir jetzt mal einen kleinen LIN-Bus Sniffer zusammenbauen und mal schauen was ich dort so finde. LIN ist ja im Grunde nichts anderes als ein Serieller-Port mit ein paar Spezialitäten (BREAK). Ich wollte mir immer mal einen LIN-Bus Adapter für PC kaufen, stattdessen habe ich mir immer was zusammengelötet... naja.

Ich habe jetzt dem Signal erstmal zur Bestimmung der Baudrate mittels einem Logic-Analyzer auf den Zahn gefühlt. Hier habe ich nach dem LIN-Transceiver (ich habe einen TJA1020 verwendet, den "Klassiker"):

Mit 2M/s aufgezeichnet ergibt sich eine Bit-Zeit von 104,5 µs, was nach der Formel Baudrate = 1 / Bit-Zeit in s eine Baudrate von 9.600 ergibt. Das ist schon etwas ungewöhnlich, da LIN standardmäßig 19.200 Baud benutzt, gut das ich nachgemessen habe! LIN nutzt 8N1, also 8 Daten-Bits (das LSB zuerst), kein Parity-Bit und 1 Stopp-Bit. Nie mit angegeben aber immer enthalten ist auch ein Start-Bit. Ein LIN-Frame, die kleinste Informationseinheit also, besteht aus insgesamt 10 Bits.

So habe ich den Protocol-Interpreter vom Logic-Analyzer eingestellt und sehe damit dann auch diese Frame-Daten in Form von Bytes.

Wie schon erwähnt gibt es auf einem LIN-Bus einen Master und mehrere (bis zu 63) Slaves. Auf unserem Batteriesensor-Bus zum glück nur diesen einen Slave. Die senden nur wenn sie vom Master dazu aufgefordert werden. Die Kommunikation läuft immer so ab das der Master einen Request (Header) auf den Bus legt. Dieser besteht aus einem BREAK, einem SYNC und einem PID.

Das BREAK ist (mind.) 13 Bits lang und besteht als 0-Bits (Leitung wird auf LOW gezogen). Im gemessenen Signal ist es 1,352 ms lang (13 * 104 µs):

Das BREAK gibt den Slaves auf dem Bus Zeit aufzuwachen, falls diese sich im Tiefschlaf befinden. Dann folgt das SYNC, welches aus einer Folge von 0 und 1 im Wechsel besteht (daraus resultiert der Hex Bytewert 0x55). Dies verwenden die Slaves um sich auf die Baudrate und Phase des Masters einstellen zu können.

Als letztes überträgt der Master das PID, quasi die Adresse des Slaves der angesprochen wird. Die eigentliche ID ist dabei 6 Bit lang, wodurch sich eine maximale Anzahl von 63 Nodes ergibt. Weil die ID wichtig ist wird sie mit zwei Paritäts-Bits gesichert (die höchstwertigen Bits). Der Wert des Partitäts-Bits P0 ergibt sich aus einem XOR von ID0 ^ ID1, sowie einem ID2 ^ ID4 und einem XOR beider Ergebnisse. Das Parity Bit P1 verwendet ID1, ID3, ID4 und ID5 zur Berechnung. Im obigen Datagramm ist 0x20 die LIN-Bus Adresse. Bei dieser Adresse sind beide Paritäts-Bits "0" wodurch sich keine Werteänderung ergibt. Die Adresse ist auch gleichzeitig sowas wie ein Befehl. Ein LIN-Slave kann auf mehreren Adressen reagieren um damit unterschiedliche Daten zu senden.

Im Anschluß an dieses Anforderungs-Signal vom Master sendet der sich angesprochene Slave dann seine Daten. Das ist aus dem obigen Beispiel:

0x84 0x80 0x00 0x00

Wieviele Bytes das sind, bestimmt allein der Slave, es dürfen aber maximal 8 sein. Dem folgt dann ein CHECKSUM Byte (ob im Beispiel 0xFA).

So sieht dann eine solche Datensalve aus:

0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x20 0x84 0x80 0x00 0x00 0xFA
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x09 0xB6 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x50 0x00 0x0A 0xF5 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x09 0xB6 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x20 0x84 0x80 0x01 0x00 0xF9
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x08 0xB7 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x0D 0xDE 0x1F 0xD4 0xE0 0x4C
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x20 0x84 0x80 0x01 0x00 0xF9
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x8E 0x00 0xB2 0x06 0xFF 0x47
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x20 0x84 0x80 0x01 0x00 0xF9
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0xCF 0x9E 0x8B 0xB3 0xFF 0x22
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x20 0x94 0x80 0x01 0x00 0xE9
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x8E 0x00 0xB2 0x06 0xFF 0x47
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x20 0x94 0x80 0x01 0x00 0xE9
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x0D 0x75 0x1E 0xD0 0xE0 0xBA
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x20 0x94 0x80 0x01 0x00 0xE9
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x08
0x00 0x55 0x06 0x00 0x00 0xFF
0x00 0x55 0x85 0x40 0x02 0xBD
0x00 0x55 0x06 0x00 0x00 0xFF
0x00 0x55 0x20 0x94 0x82 0x03 0x00 0xE5
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x8E 0x00 0xB2 0x06 0xFF 0x47
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x06 0x00 0x00 0xFF 
0x00 0x55 0x20 0x94 0x82 0x03 0x00 0xE5
0x00 0x55 0x85 0x40 0x02 0xBD 
0x00 0x55 0x50 0x00 0x4A 0xB5 
0x00 0x55 0x2B 0x02 0x41 0x47 0x39 0x4E
0x00 0x00 0x00 0xED 
0x00 0x55 0x6A 0xFF 0xFF 0xFF 0xFF 0xFF

Als nächstes versuche ich dann mittels meines Selbstbau LIN-Sniffers, bestehend aus dem TJA1020 und einem ESP32 die reinen Nutzdaten zu extrahieren und daraus schlau zu werden.

Zitat von gobang

Die Werte für Batterie-Strom, -SOC, -Temperatur und cumulative Charge/Discharge dürfte es ja nur mittels des Batteriesensors geben:

Davon habe ich aktuell nur einige wenige, die CUM_* finde ich garnicht.

Evtl. nur bei den Euro5 Diesel wurde ja schon spekuliert, aber egal. Also muss der Sensor auch eine Funktion ohne Start/Stopp haben, auch für normale (also nicht EPB) Batterien und evtl. haben beide Systeme auch nichts miteinander zu tun.

Ich habe inzwischen mein LIN-Sniffer Projekt etwas vorangetrieben, nicht trivial, davon werde ich mal später berichten wenn alles läuft, aber bereits eine Erkenntnis gewonnen: Beim rumspielen mit dem LIN-Bus hatte ich mal eine Situation das beim Anschließen meines Sniffers an Betriebsspannung der Scheibenwischer immer einmal auslöste! Bis dato dachte ich der Batteriesensor wäre einzeln an einem eigenen LIN-Bus. Als mein Projekt soweit war das ich den LIN als Bytestrom sniffen konnte habe ich den Klassiker beim Rev-Eng gemacht, mir diesen nicht nur als HEX sondern auch als ASCII ausgeben zu lassen. Und was finde ich da?

02 42 56 36 54 00 00 00  → ASCII: "BV6T"
03 31 37 44 35 34 37 00  → ASCII: "17D547"
04 41 44 00 00 00 00 00  → ASCII: "AD"
=> "BV6T-17D547-AD"

Das ist Teilenummer des Regensensors (BV6T, weil ich den beim Frontscheibenwechsel mal ausgetauscht hatte). Das hat meine Neugierde geweckt und ich habe mir die Schaltpläne nochmal ganz genau angesehen und musste feststellen das es faktisch nur drei getrennte LIN-Busse im BCM gibt, LIN0, LIN1 und LIN2:

Der hier im Plan angegebene "LIN8" des Batteriesensors, welcher seltsamerweise im Schaltplan nirgendwo an die "internal HW" führt:

scheint in Wirklichkeit also auch einfach nur ein "LIN2" zu sein. Auch daran angeschlossen ist der Scheibenwischermotor:

Schaut man bei den anderen LIN2 Membern wird dort auch lustig LIN2 und LIN8 durcheinander gewürfelt:

Also wieder mal ein kleines Geheimnis aufgedeckt das in keiner Dokumentation steht

LIN-Busse des Mondeo MK4

1. LIN0
2. LIN1
3. LIN2 (aka "LIN8")

Ich habe das im Wiki https://mk4-wiki.denkdose.de/artikel/lin-bus/start entsprechend ergänzt.

Hier noch der LIN vom PCM zum Generator, der mit dem BCM freilich nichts zu tun hat:

Nachdem das nun mal geklärt ist muss ich natürlich etwas anders an die Interpretation der Daten auf dem Bus herangehen. Es ist definitiv so, das erst nach einschalten der Zündung Daten auf dem LIN2/LIN8 laufen, vorher ist da Totenstille. Nach ausschalten der Zündung laufen noch eine kurze Zeitlang Daten, bis der "Battery-Safer" zuschlägt, wie üblich.

Da ich keine LDF-Dateien habe (und Ford die sicher auch nicht rausrückt) muss man die einzelnen IDs selbst identifizieren. Bei LIN ist es so das nur der Master eine Kommunikation initiiert, die ganzen o.g. LIN-Slaves verhalten sich passiv und antworten nur wenn sie gefragt werden. Ein Slave kann durchaus mehrere IDs besitzen, aber eine ID kann nur einem Slave zugeordnet sein. Hat ein Slave mehrere IDs, dann dient das unterschiedlichen Funktionen, z.B. grundlegend der Schreibrichtung vom Master zum Slave oder umgekehrt und verschiedenen Nachrichtentypen/Längen. All das würde in einer LDF (LIN Definition File) stehen.

Die ID entscheidet also WER angesprochen ist und WIE. Am Bytestream selbst kann man ohne LDF nicht wissen ob die Bytes nun vom Master zum Slave oder vom Slave zum Master übertragen wurden, man kann also Programmierung und auslesen nicht differenzieren. Elektrisch könnte man das durch einlegen eines Widerstandes zwischen LIN-Master-Ausgang und LIN-Bus-Anschluß realisieren. Dann gäbe es einen Pegelunterschied beim rezessiven Bit zwischen Master und Slaves und man wüsste wer die 0en sendet. So macht man das üblicherweise beim Rev-Eng von Eindraht-Bussen. Aber ich glaube ich komme auch ohne diesen Eingriff in die Bordelektrik aus durch bloße Analyse der Daten und wie sich diese verändern.

Problem dabei könnte sein das LIN nicht wie CAN ständig Botschaften sendet, sondern nur dann wenn der LIN-Master (hier ist es unser BCM) etwas wissen oder programmieren will. Es kann also sein das bestimmte Botschaften nur sehr selten oder nur bei bestimmten Aktionen (z.B. Batteriesensor zurücksetzen) auf dem Bus liegen. Das macht das Rev-Eng etwas aufwändiger und zeitintensiver...

Ein Kern-Problem bei der Entwicklung des Sniffers ist, die Länge der Nutzdatenbyte aus einer Nachricht zu identifizieren, bzw. Nachrichten auf die kein Slave antwortet. Da tüftele ich gerade noch, denn es gibt im LIN Protokoll kein Längenbyte wie beim CAN. Ich teste gerade mit unterschiedlichen, teils heuristischen Algorithmen, welche stabil laufen und welche nicht. Das klingt total trivial, ist es in der Praxis aber leider nicht.

Hast Du denn vielleicht im ForScan noch mehr als ich mal hier als Screenshot gepostet hab? Ich habe auch mit nachgerüstetem und per CCC aktiviertem Batteriesensor keine weiteren PIDs mit im BCMii bei ForScan als ich ohne hatte. Sowas wie von gobang gezeigt hätte ich erwartet, also SOC, SOH, usw.