A vízhőfoktól a turbónyomásig, új funkciók a gyári BMW óracsoportban

Az egész egy egyszerű igénnyel indult: jó lenne a hűtőfolyadék hőmérsékletét a fedélzeti számítógép menüjében látni, külön kijelző és a rejtett menü megnyitása nélkül.

Ebből végül jóval nagyobb projekt lett. A vízhőfok mellé akkufeszültség, nyomaték, számított teljesítmény és turbónyomás is került. Közben foglalkoznunk kellett a motorvezérlő belső változóival, a CAN-üzenetek felépítésével, a gateway továbbítási szabályaival és az óracsoport grafikus megjelenítésével.

Kívülről mindebből néhány szám és egy kis ikon látszik. A háttérben viszont minden kijelzett adatnak meg kellett találni a forrását, az útját és a megfelelő feldolgozását.

A cél az volt, hogy a funkciók a gyári óracsoportban jelenjenek meg, utólag beépített adatközvetítő modul nélkül. A leírás a saját vizsgált hardvereinkre és szoftverváltozatainkra vonatkozik, a boost fejlesztésénél konkrétan a 1037500776-os DDE-szoftverre és a hozzá illesztett óraszoftverre.

Vízhőfok: meglévő adat, új helyen

A vízhőfokkal azért lehetett kezdeni, mert az adat már rendelkezésre állt az órában. A vizsgált rendszerben a motorvezérlő gyárilag továbbítja a hűtőfolyadék hőmérsékletét, az óracsoport pedig feldolgozza. A rejtett menüben megjelenő érték is azt mutatja, hogy a számhoz vezető gyári adatút létezik.

A feladat ezért ennél a funkciónál elsősorban az óraszoftver módosítása volt. Meg kellett találni a hőmérséklet tárolási helyét, a hozzá tartozó érvényességi állapotot, a BC-menü kezelését és a kijelző rajzoló rutinjait. Ezután lehetett az adatot egy kényelmesen elérhető menüpontba tenni.

A hűtőfolyadék hőmérséklete saját fedélzeti számítógép menüpontban, hőmérő ikonnal.

A hőmérő ikonhoz szintén az óra saját grafikus rendszeréhez kellett alkalmazkodni. Egy ilyen kijelzőn az ikon nem egyszerűen egy bemásolt képfájl. Számít a képpontok tárolási sorrendje, a színmélység, a szélesség, a magasság és az a leíró is, amelyből a rajzoló rutin megtudja, hogyan jelenítse meg a képet.

A kis és nagy kijelzős óracsoportok, illetve az eltérő firmware-verziók között ezek a részletek változhatnak. Ugyanaz a kívánt funkció ezért több változatnál is külön vizsgálatot és illesztést igényelt. Egy másik firmware-ben talált cím vagy gépi kódrészlet nem vihető át ellenőrzés nélkül.

CAN alapok: hogyan beszélnek egymással a vezérlők

Ahhoz, hogy érthető legyen, miért lett a turbónyomás ennél összetettebb feladat, előbb érdemes megnézni, hogyan kommunikálnak egymással az autó vezérlőegységei.

A CAN, vagyis Controller Area Network egy olyan kommunikációs rendszer, amelyen rövid adatüzeneteket cserélnek a résztvevők. A vizsgált autókban használt klasszikus CAN adatkerete legfeljebb nyolc adatbájtot tartalmaz. Az üzenethez tartozik egy azonosító, a CAN-ID, valamint a hasznos adathossz jelzése, a DLC.

A CAN-ID nem egyszerűen egy vezérlőegység címe. Az azonos buszon lévő egységek számára elérhető a forgalom, a hardveres szűrők és a szoftver döntik el, melyik üzenettel foglalkoznak. A 0x1D0 vagy a 0x3B3 önmagában csak egy azonosító. A tartalom jelentését a küldő és a fogadó szoftver közös szabályai adják. A 0x előtag hexadecimális, vagyis tizenhatos számrendszerben megadott számot jelöl. (Kvaser CAN-protokollismertető)

Ha egyszerre több vezérlő szeretne adni, a CAN prioritási mechanizmusa dönti el, melyik üzenet kerül először a buszra. A többi küldő később próbálkozik. Emiatt a küldési gyakoriság és a hálózat terhelése is része a tervezésnek. (Kvaser, buszhozzáférés és prioritás)

Az autóban ráadásul több külön hálózat működik. A mi fejlesztésünkben két CAN-hálózat volt lényeges:

Az E90 hálózati felépítésében a JBE, vagyis a Junction Box Electronics látja el a központi átjáró szerepét. Összeköti a külön hálózatokat, és lehetővé teszi a szükséges információk továbbítását közöttük. Az itt megadott sebességek ehhez a generációhoz tartoznak, más BMW-knél eltérő hálózatok és sebességek is előfordulnak. (BMW E90 Voltage Supply & Bus Systems, gyári oktatási anyag, 22-25. oldal)

A gateway szerepe

A gateway működésének később döntő szerepe lett. Attól, hogy egy adat megjelenik a PT-CAN-en, még nem következik, hogy az óracsoport K-CAN hálózatán is ott lesz.

A vizsgált gateway-szoftverek továbbítási szabályok alapján dolgoznak. Bizonyos azonosítókat átengednek, másokat nem. A keret hossza és a továbbítás módja szintén számíthat. A mi esetünkben olyan üzenetre volt szükség, amelynél a hozzáadott két adatbájt is eljut az óráig.

Mit küld valójában a DDE?

Először ezért a tényleges CAN-forgalmat naplóztuk. Megnéztük, mi jelenik meg a motorvezérlő oldalán, és mit lehet látni az óra hálózatán.

A köznyelvben broadcastnak neveztük az ECU külön lekérdezés nélkül, rendszeresen vagy esemény hatására küldött üzemi üzeneteit. Ez a projekt szempontjából azért fontos, mert nem ugyanaz, mint amikor egy diagnosztikai eszköz konkrét adatot kér le a vezérlőtől.

A DDE belül sokkal több értékkel dolgozik, mint amennyit folyamatosan továbbít a többi vezérlőnek. Az, hogy egy nyomás, hőmérséklet vagy számított állapot létezik a memóriájában, még nem bizonyítja, hogy az adat valamelyik üzemi CAN-üzenetben is szerepel.

A naplóinkban például ezek az üzenetek jelentek meg:

Ez a felsorolás a nálunk vizsgált forgalom egy része, nem minden BMW minden DDE-változatának teljes üzenetlistája.

Akkufeszültség: az óra saját mérése

Az akkufeszültség kijelzésénél végül az óracsoport saját feszültségmérését használtuk. A DDE-hez tartozó 0x3B4 üzenetet ugyan megtaláltuk a K-CAN naplóban, de az ott rögzített két keretből nem igazoltunk használható feszültségértéket.

A kijelzett feszültség tehát nálunk az óra saját tápellátásának méréséből származik. Ez nem azonos azzal, mintha közvetlenül az akkumulátor saruin mérnénk, hiszen a kábelezésen és csatlakozásokon is lehet feszültségesés.

Akkufeszültség saját menüpontban, akkumulátor ikonnal. Az érték az óracsoport tápoldali méréséből származik.

Nyomaték és számított teljesítmény

A nyomatékkijelzés következő lépésként adódott. A szükséges üzenet már eljutott az óra hálózatára, de a saját NM/LE oldalhoz külön feldolgozást kellett készíteni.

A nyomatékadat nem úgy érkezik, hogy az üzenetben szövegként szerepel például "350 Nm". Egy meghatározott bitmezőben található nyers számot kell kiolvasni, figyelembe véve az előjelet, a skálázást és az állapotjelzéseket. Az üzenetben más mezők is lehetnek, például számláló és alkalmazásszintű ellenőrzőösszeg.

A lóerőhöz nincs szükség külön teljesítményüzenetre, ha rendelkezésre áll az összetartozó nyomaték és fordulatszám. A metrikus lóerő közelítő képlete:

Például 350 Nm és 3000-es fordulatszám körülbelül 150 LE-nek felel meg.

Ezt a számítást az óracsoportba tett rutin végzi. A bemenet azonban a DDE által számított nyomaték, ezért a kijelzett teljesítmény becslés. Pontosságát a motorvezérlő nyomatékmodellje és az aktuális adatok érvényessége is befolyásolja. Ez nem teljesítménypadon végzett mérés.

A padpróbák során ennek gyakorlati jelentősége is lett. Előfordult, hogy az üzenet megérkezett, az ellenőrzőösszege rendben volt, de a nyomatékhoz tartozó állapotjelzés eltért a kijelzőrutin által elfogadottól. Ilyenkor a kommunikáció működött, mégsem jelent meg szám.

Külön tesztváltozatban a 2-es státuszú nyomatékadat megjelenítését is engedélyeztük. Ezzel a számítás és a kijelzés vizsgálhatóvá vált, de a státusz elfogadása önmagában nem bizonyítja a nyomaték fizikai pontosságát. A próbapadon az Arduino a DDE bemeneti jeleit szimulálta, a CAN-üzeneteket maga a DDE állította elő.

A saját NM/LE oldal padpróba közben: a nyomaték a DDE nyomatékmodelljéből jön, a teljesítményt az óra számolja hozzá.

Turbónyomás: a küldőoldalt is bővíteni kellett

A turbónyomásnál már a küldőoldalon is hozzá kellett nyúlni a rendszerhez. A vizsgált változatban nem azonosítottunk olyan, használható gyári boostmezőt, amely a szükséges formában eljutott volna az órához. A DDE belső nyomásadata viszont megvolt.

Itt került elő a firmware részletes visszafejtése. A firmware a vezérlőegység futó programja: ebből derül ki, hogyan dolgozza fel az érzékelőket, hol tárolja az eredményeket, és milyen adatokat készít elő a kommunikációhoz.

A Ghidra segített követni a gépi kód működését és az egyes rutinok közötti kapcsolatokat. A változók azonosításához referenciaadatokat és A2L-leírást is használtunk. Az A2L mérési és kalibrációs információkat adhat a változókról, de más szoftververzióból származó címeket itt sem lehet ellenőrzés nélkül átvenni.

A vizsgált DDE-ben a feldolgozott abszolút töltőnyomást és a környezeti nyomást külön RAM-változókból olvassuk. A RAM a vezérlő futás közbeni munkamemóriája, itt vannak az aktuálisan feldolgozott értékek.

A képeken látható magyar függvénynevek az elemzés során adott elnevezések. Ezek segítenek megérteni a kódot, de nem azt jelentik, hogy az eredeti firmware magyar nevű függvényeket tartalmazott.

A DDE CAN-küldése

A DDE CAN-küldése több egymásra épülő lépésből áll. A saját vizsgált kódunkban leegyszerűsítve ez történik:

• 1. A program előállítja vagy kiolvassa a továbbítandó belső értékeket.
• 2. A jelíró rutinok a megfelelő bitekre és bájtokra csomagolják az adatokat.
• 3. Az elkészült üzenet egy RAM-pufferbe kerül.
• 4. A keretkezelő ellenőrzi a küldési feltételeket és az ütemezést.
• 5. A gyári CAN-kezelés átadja a keretet a hardvernek.

A mi kiegészítésünk ebbe a meglévő folyamatba illeszkedik. A gyári küldéskérés előtt kitölti a boosthoz rendelt két bájtot, majd továbbadja a vezérlést az eredeti rutinnak.

A konkrét 500776-os változatban az új segédrutin a 0x0002D000 címen található, a gyári küldőág pedig a 0x000AE56C címen hívja meg. A belépéskor használt regiszterek és állapotok megőrzése azért fontos, hogy a gyári kód a visszatérés után ugyanazzal a környezettel folytathassa a munkát.

A DDE oldali segédrutin eleje Ghidrában (0x0002D000): stack-frame, LR, CR, CTR és XER mentése, majd a keretazonosító és az aktív konfiguráció ellenőrzése.

Az első próbálkozás: saját CAN-ID

Az első változat saját, 0x5E8 azonosítójú üzenetet küldött. Ez megjelent a PT-CAN-en, a vizsgált gateway azonban nem továbbította a K-CAN-re. Az óra így hiába kapott volna hozzá fogadó rutint, az adat fizikailag nem jutott el a hálózatára.

Ez mutatta meg, miért nem elég egy új CAN-ID-t választani és elkezdeni sugározni.

A végleges megoldás: a gyári 0x3B3 bővítése

A végleges megoldáshoz a 0x3B3 üzenetet választottuk. Ezt a mi DDE-nk gyárilag is küldte, hat adatbájttal, és volt hozzá megfelelő gateway-továbbítási szabály. Az eredeti hat bájt jelentését megtartottuk, a keretet pedig nyolc bájtra bővítettük.

A bájtok számozása nullától indul, tehát D6 és D7 a hetedik és nyolcadik adatbájt.

A nyomást előjel nélküli, 16 bites számként továbbítjuk, mbar egységben, little-endian bájtsorrenddel. Ez azt jelenti, hogy az alacsonyabb helyi értékű bájt kerül előre.

D6 = 0xDC, D7 = 0x05
szó  = 0x05DC = 1500 mbar     ; az órán 1,50 bar

Az eredeti hat bájt megtartása mellett a kerethossz és a küldési gyakoriság is változott. Ezeket ezért külön vizsgálni kell. Az, hogy a gateway átenged egy üzenetet, önmagában még nem bizonyítja, hogy minden más gyári fogyasztó változatlanul kezeli a kibővített keretet.

Abszolút és relatív nyomás

A megjelenített boosthoz az abszolút és a relatív nyomást is meg kellett különböztetni. A DDE belső nyomásértéke abszolút nyomás, a kijelzőn viszont a környezethez viszonyított túlnyomást szeretnénk látni. A számítás ezért:

Ha az abszolút nyomás 2500 mbar, a környezeti pedig 1000 mbar, akkor az eredmény 1500 mbar, vagyis 1,50 bar.

A kivonást már a DDE-ben elvégezzük, az órának ezt nem kell megismételnie. A jelenlegi protokoll a negatív különbséget nullára korlátozza, tehát vákuumot nem jelenít meg.

Az adatút a gateway-en át

A módosított üzenet útja így alakult: DDE, PT-CAN, gateway, K-CAN, óracsoport. A gateway szoftverét nem kellett módosítani. A padon a K-CAN oldalon is megjelent a nyolcbájtos 0x3B3, benne a hozzáadott nyomásadattal.

CAN-napló a padról: a kijelölt 0x3B3 már 8 bájttal érkezik. Ebben a keretben D6-D7 = D5 0B, vagyis 0x0BD5 = 3029 mbar.

Az óracsoport oldala

Az órában ezután is szükség volt új feldolgozásra. A végleges célverzió gyári üzenetlistájában nem volt kész boostkezelés, ezért a bővítés a beérkező keretből külön olvassa ki a szükséges adatokat.

A fogadó rutin ellenőrzi az azonosítót, a kerethosszt és az érvénytelenségi értéket. A nyomás mellé frissességi állapot is tartozik: ha túl sokáig nem érkezik új adat, az óra nem tarthatja korlátlan ideig a kijelzőn az utolsó számot.

A boost- és nyomatéküzenetek fogadása az óraszoftverben (F2MC-16LX), a saját patch-rutinok listájával a szimbólumfában.

Rövid keretnél, FFFF értéknél vagy lejárt adatnál ezért vonalak jelennek meg. A 0,00 bar ettől különbözik, az lehet teljesen érvényes mérési eredmény.

Érvényes, friss adat alacsony relatív nyomással: 0,10 bar a turbó ikon mellett.

Diagnosztikai kijelzés

A hibakereséshez ideiglenes diagnosztikai kijelzést is készítettünk. Ezen látszott a vételi számláló, a kerethossz, az elfogadási állapot, a nyers nyomásszó és az adat kora. Így külön lehetett választani, hogy nem érkezik üzenet, rossz hossz érkezik, a DDE érvénytelen értéket küld, vagy a megjelenítéssel van probléma.

A MAP-jel hiányában például megérkezett a nyolcbájtos keret, de a nyomásmező FFFF volt. A vonalas kijelzés ebben az esetben helyesen jelezte az érvénytelen bemenetet. Megfelelő bemeneti jellel az adat érvényessé vált.

A diagnosztikai oldal MAP-jel nélkül: R a vételi számláló, D a kerethossz (8), V az elfogadási állapot, H a nyers nyomásszó (FFFF, érvénytelen), A az adat kora.

A vételi számláló 255 után nulláról indult újra. Ez az egybájtos számláló természetes körbefordulása volt, nem az óracsoport újraindulása.

Villogó ikonok és szövegek

Közben egy másik probléma is előkerült: az új menükben az ikonok, majd a szövegek vibráltak.

Elsőre kézenfekvő lett volna egyszerűen ritkábban frissíteni a kijelzőt. A javítás azonban a kirajzolás módját érintette. Az előzetes háttértörlés rövid időre eltüntette a már kirajzolt elemeket, mielőtt azok újra megjelentek.

A módosított rutin megtartja az ikon területét, a szöveget pedig úgy frissíti, hogy ne kelljen előtte az egész rajzterületet kiüríteni. Arra is figyelni kellett, hogy rövidebb érték után ne maradjon ott egy korábbi számjegy. A padpróbán az ikon- és szövegvillogás is megszűnt.

Végpontig tartó próba

A MAP-jel maximális bemeneti értékével végül 3,06 bar jelent meg a gyári kijelzőn, a turbóikon mellett. Ez a próba a teljes adatút működését mutatta meg a DDE belső adatától az órán látható számig. Nem terhelés alatti motorvizsgálat volt, és nem helyettesíti a teljes mérési tartomány diagnosztikai összehasonlítását.

Maximális MAP-bemenettel 3,06 bar a gyári kijelzőn: a DDE belső nyomásadata végigment a PT-CAN, gateway, K-CAN úton.

Ellenőrzés és továbblépés

A fejlesztés során ezért többféle ellenőrzést használtunk:

• Emuláció: segített a számítás, a keretkezelés és a gépi kód ellenőrzésében.
• CAN-napló: bizonyította, hogy mi jelent meg a buszon.
• Fizikai padpróba: megmutatta a tényleges megjelenítést és az olyan időzítési hibákat is, mint a villogás.

Más paramétereknél, például kipufogógáz-hőmérsékletnél ugyanezt az adatútkérdést kell először tisztázni. Létezik-e az érték az adott ECU-ban, mért vagy számított adat, van-e hozzá érvényességi jelzés, és eljut-e az óracsoportig?

Ha már megfelelő formában jelen van az óra hálózatán, elegendő lehet az óraszoftver bővítése. Ha csak a DDE belsejében érhető el, a küldést is ki kell egészíteni. Másik lehetőség egy külső modul, amely diagnosztikán lekéri az elérhető adatokat, majd az óra számára feldolgozható formában továbbítja őket.

A vízhőfok és a boost között így jóval több különbség van, mint a hőmérő és a turbó ikonja. Az egyiknél egy már meglévő adatot tettünk könnyebben elérhetővé, a másiknál a motorvezérlő küldésétől az óracsoport rajzolásáig végig kellett építeni a funkciót. A további vizsgálatokban a teljes nyomástartomány egyezése, a tényleges küldési időközök és a különböző üzemi állapotok viselkedése is külön ellenőrzést igényel.

Források

Kvaser CAN-protokollismertető
Kvaser, buszhozzáférés és prioritás
BMW E90 Voltage Supply & Bus Systems, gyári oktatási anyag