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.

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.