A saját eszközeinket úgy akarjuk integrálni az autó elektromos rendszerébe hogy annak minél kisebb módosításával járjon, pontosabban a lehető legkevesebb interakciót akarjuk a Mazda kütyüivel. Ahogy még az első cikkek egyikében leírtuk, a PCM-et, azaz a benzinmotor vezérlőjét leválasztottuk az autóról, és beiktattuk útközbe a mi saját PCM Gateway névre keresztelt elektronikánkat. Ez az egység válogatja ki az autó üzenetei közül a számunkra fontosakat, illetve a mi rendszerünk üzeneteiből az autónak hasznosakat. Ezen felül a PCM üzeneteit írja felül, hogy az autónak ne legyen tudomása a motorcseréről, és ne játsza a dívát, hogy márpedig ő így nem hajlandó közlekedni. Továbbá elkülönítettük a hajtáslánc és az akkumulátorfelügyelet kommunikációját, mindkét feladat saját CAN-buszt kapott annak érdekében, hogy ne zavarják egymást és alacsonyan tartsuk a kommunikációs buszok terheltségét. A két CAN-hez egyszerre egyedül a járművezérlő elektronika, azaz a VCU (Vehicle Control Unit) fér hozzá, hiszen neki kell kézben tartania a teljes rendszert. Ez nem azt jelenti, hogy neki kell minden egyes munkafolyamatot végrehajtania, hanem sokkal inkább koordinálja az eseményeket. Kezdeményezi az akkumulátorok aktiválást, parancsokat küld a motorvezérlőnek, kezeli az előforduló hibákat. Ha úgy tetszik, ő csak egy feladatokat delegáló főnök, aki nagyban támaszkodik az alkalmazottai helyes munkavégzésére.

Ezen felül a VCU feladata, hogy rögzítse az eseményeket - az analógiával élve riportot készít az elvégzett munkáról, ezzel megkönnyíti számunkra a későbbi tesztelést és adatelemzést. Valós időben vezeték nélküli kapcsolaton keresztül is eljuttatja hozzánk a saját rendszerünk minden adatát, így teszt közben is egyszerűen monitorozhatjuk például az összes cella állapotát, terheltségét, a motorvezérlő helyes működését.

A VCU és a PCM Gateway hardveresen megegyezik, ugyanis így költséghatékonyabb volt a fejlesztés és a gyártás, csak és kizárólag szoftveresen térnek el egymástól. Két CAN csatornával, két 12V-os digitális kimenettel és 7 analóg csatornával rendelkeznek. Ebben a projektben viszont szinte csak és kizárólag CAN-en keresztül kell majd kapcsolatba lépniük az autó többi részével, illetve egymással. Ezen felül beépítésre került még az adattárolást lehetővé tevő SD kártya foglalat, WiFi és GPS modul is.

Két mikrovezérlő található az áramkörön, melyből egyik a funkcionalitásért, a másik pedig a biztonságért felel. Ez azért előnyös, mert hibatűrő lesz a rendszer, és a fő processzor meghibásodása esetén is biztonságosan le tudjuk állítani a járművet. Továbbá az is előny, hogy anélkül tudunk újabb funkciókat hozzáadni a szoftvercsomaghoz, hogy a biztonságért felelős modulokra bármilyen formában is hatást gyakorolnánk.

A járművezérlőn egy beágyazott rendszerekhez széles körben használt operációs rendszer, a FreeRTOS fut, és menedzseli a sok funkció egyidejű ellátását. Ezt nem úgy kell elképzelni mint egy PC-re szánt Windows-hoz vagy Linux-hoz hasonló operációs rendszert, nincs neki semmilyen csilivili grafikus kezelőfelülete (GUI), csak és kizárólag az erőforrások megfelelő szétosztásáért felel, az egész nem több néhány kilobájtnál. A nevéből két lényeges dologra lehet következtetni: egyfelől ingyenes, mitöbb nyílt forráskódú, így igény szerint módosítható is, másfelől pedig valós idejű (RT - Real Time), ami annyit tesz, hogy minden folyamat egy előre meghatározott időkeret (általában a 5-100 ezredmásodperc) alatt végrehajtásra kerül. Természetesen az eredmény lehet az, hogy nem sikerült befejezni az adott folyamatot, de a PC-s rendszereknél tapasztalható befagyás, nem reagálás, újraindulás jelenségektől teljesen mentes. Senki sem örülne neki, ha befagyna az autóját irányító számítógép 130-as, vagy akár 90-es, sőt még 50 km/h-s tempónál sem. Úgy istenigazából semmikor sem. A főbb funkciókat, mint akkumulátor kezelés, motorvezérlő vezérlés, adatrögzítés, WiFi-s adatküldés, periféria kezelés, nyomatékszámítás, külön feladatként, úgy nevezett task-ként definiáltuk, és egymástól függetlenül a saját időzítésükkel képesek futni. Természetesen egyszerre csak egy tud futni, mivel egyetlen ~170 MHz-es órajelű processzormag található a mikrovezérlőben, így időosztást kell alkalmazni az operációs rendszernek. A program memória (RAM) mérete a 200 kB-ot sem éri el, a háttértár (ROM) is éppen csak 1 MB-os. Ezek a számok ma extrém alacsonynak tűnhetnek, hiszen már a telefonokban szinte alapfelszereltség a négymagos 2 GHz-es processzor 2 GB RAM-mal. Viszont azok általános célú, bonyolultabb és kevésbé optimalizált rendszereket futtatnak. Egy autóipari felhasználáshoz ez a számítási kapacitás bőven elég, mivel elég jól meghatározott feladatokat kell ellátni, amik közé például a 4K felbontású YouTube videó lejátszása nem tartozik bele, sem a nagy adathalmazok mozgatása, elemzése, de 100x100-as mátrixokat sem kell invertálni. Igazából a processzor számítási teljesítménye erre a feladatra túl sok is, 10% alatt van a kihasználtsága, azonban a perifériák miatt szükség volt erre a vezérlőre.

Tesztelés

A tesztelrendezésben, amely három moduláris akkumulátorból, egy kötöződobozból, töltőből, motorvezérlőből, motorból és járművezérlőből áll, ellenőriztük a VCU helyes működését. Az első lépés az akkumulátorok kezelésének vizsgálata volt. Meggyőződtünk arról, hogy a CAN-en küldött adatokat megkapja, és helyesen is értelmezi a VCU. A tesztelés egyik legfontosabb része a hibainjektálás. Ezt a hobbi projekteknél szinte mindig elfelejtik az ötletgazdák, hiszen sosem adják ki a kezeik közül a kész eszközt, így nem is gondolnak arra, hogy hogyan kéne reagálnia a rendszernek egy adott hibára. Ott lesznek mellette és majd megjavítják. Ez ebben az esetben egyáltalán nem tud működni, hiszen emberek fognak beülni az autóba és ki is akarnak majd szállni belőle egy darabban. A mi rendszerünknél a hibák nagy általánosságban rossz kontaktusra, vezetékszakadásra, rövidzárra, kommunikációs problémára vezethetőek vissza. Szerencsére ezeket elég egyszerűen elő lehet idézni mesterségesen. Miután meggyőződtünk, hogy a hiba detektálása megtörtént és utána biztonságos állapotba juttatta a rendszert a VCU, következhetett a motorvezérlővel való kommunikáció. Itt mielőtt üzemkész állapotba kerülne a teljesítményelektronika, CAN-en keresztül el kell végeznünk néhány apró beállítást, és megadott állapotátmeneteket kell végrehajtanunk a vezérlővel. A VCU egy kis fejvakarás után sikeresen végre is hajtotta ezeket a folyamatokat. Nem teljesen egyezett meg a motorvezérlő által küldött üzenet tartalma az adatlapban leírtakkal, így az ellenőrzés során mindig hibaállapotba lépett a VCU. Sajnos nem ez volt az első, hogy nem volt valami rendesen ledokumentálva a motorvezérlővel kapcsolatban, így ezen nem is lepődtünk meg annyira, csak húztuk a szánkat miatta. Miután minden főbb funkciót leteszteltünk külön-külön, éreztük magunkban az igényt egy teljes rendszerteszre. Akkuk összekötve,  behuzalozva a kötöződobozba, onnan nagyáramú vezeték viszi tovább a teljesítményt a motorvezérlőhöz, majd végül a motorhoz. 12V-os felügyeleti rendszer összekötve, minden eszköz és csatlakozó a helyén, VCU rákötve az akkukra és a vezérlőre is.

Nehéz átadni szövegben annak az élményét, amikor először állítasz össze egy komplex rendszert teljes valójában, ráhelyezed az ujjad a 12V-os táp bekapcsológombjára, közben arra próbálsz gondolni, hogy “leteszteltünk mindent ... minden működik ... most sem lesz baj”, közben pedig egy ördögi hang suttogja a füledbe, hogy ha bármi balul sül el, akkor itt nagy csinnadratta lesz és sok nagyon drága söralátét fog készülni. Szóval szerintem nagyon izgalmas pillanat. Aztán megnyomod a gombot, és nem történik semmi. Legalábbis látszólag, mert vagy két másodperc, amíg lefutnak az ellenőrző algoritmusok, és az sok időnek tűnik ilyen izgatott állapotban. Amikor meghallod az első akkumulátor mágneskapcsolójának kattanását, tudod hogy minden jól működik, de azt is, hogy most tud csak igazán nagy baj történni. Türelmesen végigvárod, amíg a motorvezérlőben lévő kondenzátorok előtöltése megtörténik, és kattannak az utolsó relék is. Akkor nyugszol meg igazán, amikor meghallod a motornak azt a szép halk nagyfrekvenciás duruzsolását, amit álló helyzetben is hallat. Minden működött, és elkezdi felcsigázni a fantáziádat, hogy mi történne, ha most küldenénk neki egy “aprócska” nyomatékigényt, mondhatni virtuálisan rátaposnánk a gázpedálra.

Na ezt senkinek sem ajánlom, mivel egy ilyen villanymotornak elég kicsi tehetetlensége van a teljesítményéhez képest, emiatt terhelés nélkül úgy indul meg mintha nem lenne holnap. Erre ki is kell találnunk valamit, hiszen elég hamar az idegeinkre menne, ha minden váltásnál 6000-es fordulaton visítana a motor, mert nem vettük le teljesen a lábunkat a gázpedálról. Az egyik kézenfekvő dolog, amit a belsőégésű motoros autóknál is csinálnak a gyártók, az a pedálkarakterisztika módosítása. Ez azt jelenti, hogy a motornyomaték nem egyenesen arányos a pedál fizikai szöghelyzetével. A célunk az, hogy kis pedálállás esetén, mint az elindulás vagy araszolás, finomabban lehessen vezérelni a motort, de ha nagy gázt adunk, akkor rendelkezésünkre álljon a maximális teljesítmény. A kényelem szempontjából előnyös, ha a gázpedál véghelyzete környékén már lapos a görbe, és nincs kis szöghelyzetváltozás esetén nagy teljesítményugrás. A diagramon a narancssárga egyenes mutatja az eredeti karakterisztikát. A szürke görbe finom nyomatékadagolást biztosít egészen 70%-os pedálállásig, azonban nagyon kis tartományra szorul a nagyteljesítményű üzem. Az ideális valahol a kék görbe mentén van, ezért egy ehhez hasonlót implementáltunk a VCU szoftverében.

A következő lépésként a VCU szoftverkódjához hozzáírtuk az autó által küldött pedáljelek feldolgozását, és hogy ez alapján nyomatékigényt küldjön a motorvezérlőnek. Ezzel együtt megvalósítottunk néhány főbb biztonsági funkciót is, mint például gáz-fék egyszerre nyomása esetén zérus nyomaték, regeneratív fékezés kikapcsolása feltöltött akkumulátornál, hajtás kikapcsolása lemerült akkumulátornál. A számítógépünket rácsatlakoztatva a rendszerre, szimulált gázpedál jeleket küldtünk a VCU-nak, ezzel elhitetve vele, hogy már be van szerelve az autóba. A világoszöld vonal mutatja a gázpedál állását, míg a sötétzöld a motorfordulatszámot. Próbáltuk a fordulatszámot lassan és egyenletesen növelni, így az általunk kiadott gázpedál jel kicsit röcögős lett.

Úgy tűnik, hogy minden rendben van az elektromos hajtásrendszerrel. Alig várjuk, hogy minden bekerüljön végre az autóba, és élesben is letesztelhessünk mindent.