Werking

Hoe zijn we te werk gegaan?

Eerst en vooral moesten we een manier vinden om de CAN-informatie in te lezen in LabVIEW. In een Toyota RAV4 (2008) zitten 2 CAN-netwerken waarvan de voornaamste rechtstreeks toekomt op de EOBD-stekker die bedoeld is voor diagnose. De stekker bevindt zich (net als in veel moderne wagens onderaan het dashboard). De CAN-high, CAN-low en signal-ground van de diagnosestekker kunnen rechtsreeks met de NI-CAN USB-8473 verbonden worden. De nodige programmaonderdelen voor het inlezen van de ruwe data werden al meegeleverd met de NI-CAN USB-8473, het was dus vrij snel mogelijk een lijst te krijgen met alle identifiers en hun waarde op dat ogenblik. De identifiers hebben elk een uniek nummer met een waarde erbij maar we hadden geen idee welke identifier welke functie van de wagen weergaf. De nummers van de identifiers kunnen van merk tot merk en zelfs van model tot model en bouwjaar verschillen, en ook het verkrijgen van een lijst met deze identifiers en hun functie via Toyota zelf is niet mogelijk. Er kon nu met enkele LabVIEW-functies een programma gemaakt worden dat de gewenste identifier alleen weergaf en niets meer.  Dit was een eerste succes, maar nog vrij betekenisloos.
De enige manier om nu te weten te komen wat we eigenlijk binnenlazen was reversed engineering. Het uitgangspunt hiervan is: als we zelf de toestand van de wagen zo constant mogelijk houden, en dan een toestand veranderen dan is de veranderende identifier het ding waarvan we de toestand veranderden. In praktijk niet simpel omdat vaak samen met het een ook het ander verandert, en omdat bepaalde identifiers constant (een op het eerste zicht willekeurige) verandering ondergaan. Een aanpassing aan onze uitlees-software zorgde ervoor dat enkel en alleen de identifiers die van waarde veranderden (ten opzichte van de waarde die ze hadden bij het opstarten van de software) getoond werden. Als nu een deur werd geopend of de dimlichten werden aangezet kwam een identifier tevoorschijn in een lijst. Door deze nauwlettend in de gaten te houden en steeds de toestandsveranderingen te noteren konden we een lijst maken met alle identifiers en welke waarde nu precies waarvoor diende. Combinaties zijn in de meeste gevallen gewoon een optelling van alle bediende opnemers.
Bijvoorbeeld de deuren, dit is identifier 0620 (hexadecimaal):
Alle deuren dicht: 10 00 00 00 30 00 0D 50 (Hex) = 00000000 (Bin)
Linksvoor open:    10 00 00 00 30 20 0D 50 (Hex) = 00100000 (Bin)
Rechtsvoor open:  10 00 00 00 30 10 0D 50 (Hex) = 00010000 (Bin)
Beide open:         10 00 00 00 39 30 0D 50 (Hex) = 00110000 (Bin)

Na lang testen en uitproberen konden we met vrij veel zekerheid de volgende identifiers identificeren: stuurhoek, gaspedaalstand, rempedaalstand, koppeling ingedrukt, stand ventilatie, deuren open/dicht, stand lichten, cruise-control aan/uit, langsdifferentieelblokkering aan/uit en handrem, gordels aan/uit.
Het visueel weergeven van de stand van elk van deze sensoren kan door middel van foto's . LabVIEW kan een foto tonen van de toestand van elke identifier zodat meteen duidelijk wordt wat in de wagen bediend is. Dit is ons eigen virtuele dashboard.

Het programma dat we maakten zet dus alle data die op de CAN-bus beschikbaar is om in een begrijpbare vorm, we kunnen zelf kiezen wat getoond wordt en hoe.

Het aansturen van de wagen met de laptop was de volgende stap, hierin zijn we niet helemaal geslaagd. De main body-ECU stuurt de actuatoren aan maar doet dit helaas niet via CAN, alleen het dashboard (en mogelijk bepaalde delen van de motor) worden aangestuurd met CAN. Als we dus de lichten aansturen via onze PC gaat wel het controlelampje op het dashboard aan, maar blijven de lichten zelf uit. Dit is spijtig, maar niet onze fout, op sommige andere voertuigen is meer mogelijk op gebied van aansturing.