Szoftver, ami autók millióiban fogja a volánt (x)

A sofőrök különböző vezetési preferenciáihoz mára rengeteg személyautó képes igazodni, legyen szó a "kisujjal tekerős" városi kormányzásról vagy épp a sportosabb vezetésről, ahol a sofőr az utolsó kavics döccenését is érezni szeretné a kormányon. Sok járműben ráadásul már gombnyomásra válthatunk a különböző vezetési élmények között - a modern autók hasonló mutatványai mögött pedig rendkívül komoly mérnöki teljesítmény áll. Ez utóbbi messze nem merül ki a kormányoszlop és -rúd kialakításában, az azok mozgatását segítő szervomotorok hatékony és biztonságos vezérlésének megtervezése rendkívül komoly kihívást jelent. Különösen igaz ez az olyan korszerű autóknál, ahol a kormányszervo már a fejlett vezetéssegítő rendszereket, sávtartó és parkoló automatikákat is kiszolgálja.

Ez a tervezés áll a thyssenkrupp fókuszában is, amely autóipari beszállítóként az elektronikus kormányrendszerek hardveres és szoftveres komponenseivel is ellátja autógyártó partnereit. Miután biztonságkritikus rendszerekről van szó, a vállalatnál a szoftverfejlesztés jelentősen eltér egy "mezei" ügynökségnél megszokott gyakorlattól, a termékeknek szigorú autóipari szabványoknak kell megfelelniük és többszörös, átfogó tesztelésen kell, hogy átessenek.

Azt, hogy biztonságkritikus rendszerről van szó, nyugodtan érthetjük a szó legszorosabb értelmében - vélhetően nem kell sokat ecsetelni, milyen kockázattal jár, ha az autópályán a kormányrendszer nem az elvárásoknak megfelelően működik. Erről a működésről az ECU-k (Electronic Control Unit), azaz a vállalat saját fejlesztésű, mikrokontrollerekre építő vezérlőegységei gondoskodnak. Ilyen egységből egy modern autóban százat is jócskán meghaladó darabot találunk, ezek a legkülönbözőbb funkciókért felelnek, a fékektől kezdve az ablakemelőkig, ezek közül azonban már jóval kevesebb, amelyik biztonságkritikus feladatokat lát el.

MEGBÍZHATÓSÁG MINDENEK FELETT

Hogy ebbe a besorolásba mi kerül, azt a kapcsolódó autóipari szabványok határozzák meg: értelemszerűen az említett ablakemelők vezérlése nem kapott kiemelt helyet a listán, a fékeké viszont annál inkább - ugyanakkor egy esetleges vészhelyzetben, a fék elvesztése esetén még mindig ott a motorfék vagy épp a kézifék az autó lelassítására, megállítására. Ha valamilyen okból a kormány blokkol le, abban az esetben már nincs hová nyúlni, ennek megfelelően ez a rendszer a legszigorúbb biztonsági besorolásban kapott helyet.

Ennek fényében nem meglepő, hogy a "hagyományos" szoftverprojektekhez képest az egyik legnagyobb különbség, hogy az elektronikus kormányrendszerek komponensei a fejlesztés során kiemelten sok tesztelésen esnek át, hogy az ECU-k, illetve a thyssenkrupp azokon futó kódja is a lehető legmegbízhatóbb legyen. Az iparági szabványok, mint az AUTOSAR, az ECU-kon dolgozó szoftverek tervezésének, illetve fejlesztésének útját is kijelölik, továbbá arra vonatkozóan is megfogalmaznak elvárásokat, hogy a terméknek milyen ellenőrzéseken kell átmenniük.

A fejlesztés a vállalatnál jól definiált folyamatok mentén, a „V” modellt követve zajlik: a „V” bal szárán lefelé haladva, szabvány követelményeihez igazodva történik a megvalósítás, majd jobboldalt felfelé a, tesztelés, mind szoftver-, mind hardveregységekkel. Mindezek mellett az összes lépést több mérnök ellenőrzi szigorú szempontok szerint. A cég gyakorlatilag a teljes feldolgozási láncot automatizálta, continuous testing folyamatainak hála pedig azonnali visszajelzések érkeznek az esetleges anomáliák kapcsán. A vállalat dedikált részlege által készített, saját fejlesztésű tesztek, illetve automata verifikáció mellett természetesen a fejlesztők egymás kódját is rendszeresen ellenőrzik. A cégben továbbá az Functional Safety (ISO 26262) szabvány biztosítására megfelelés biztosítására is létezik egy önálló divízió.

Maga a cég budapesti fejlesztőközpontjában készülő szoftver egyébként C programozási nyelven íródik, annak hardverközeliségéből adódó, rendkívül jó teljesítménye miatt, hiszen a gyors, stabil kód elengedhetetlen a regiszterek, perifériák megfelelő sebességű elérése és a valós idejű reakciók biztosítása érdekében – az utakon már egy másodperces késés is számottevő biztonsági kockázatot jelent.

AZ ALAPOKBA BETONOZOTT REDUNDANCIA

A rendszernek az esetleges, akár külső behatásból, akár hardverelemek öregedéséből adódó potenciális hibákat is azonnal tudnia kell detektálni, és reagálni azokra. Ilyen esetekben a vezérlés, ha még tud biztonságosan működni - akár egy másik szenzor jeleit használva fallback mechanizmusként - továbbra is kiszolgálja a járművet, ugyanakkor súlyosabb meghibásodás esetén teljes leállásra is szükség lehet, ilyenkor szervokormány nélkül mehet tovább az autó.

Persze a cél, hogy az elektronikus kormányrendszer minél tovább tudjon beavatkozás nélkül működni, éppen ezért abban a cég többszörös redundanciát biztosít, mielőtt még alternatív funkciókat ellátó érzékelőkhöz, alrendszerekhez fordulna probléma esetén. Azonban, ha a szükség úgy hozza, a fő jel elvesztésével két-három másik jel alapján, matematikai modelleket használva a thyssenkrupp rendszere be tudja foltozni a funkcionalitáson keletkezett lyukat – ezeket a lehetséges alternatív útvonalakat már a tervezés kezdeti szakaszában ki kell jelölni.

A tesztelés ugyanakkor lehet bármilyen rigorózus, százszázalékos hibamentességet nem lehet biztosítani – az ugyanakkor a megfelelően szigorú ellenőrzésekkel elérhető, hogy a hibák lehetséges előfordulásának arányait egészen minimálisra csökkentsék. Ez jelen esetben azt jelenti, hogy probléma akár több millió esetből egyszer fordul csak elő, ennek megfelelően könnyen lehet, hogy egy-egy gépjárműszéria egyetlen legyártott modelljében sem jelentkezik.

Az elkészült szoftvert (és a hardverkomponenseket) nem csak a thyssenkrupp szakértői veszik górcső alá, annak biztonságosságáról kiterjedt, külső felek által végzett auditok során is meggyőződnek. Utóbbiakat egyrészt az autógyártó-partnerek, másrészt maga a vállalat is rendszeresen megrendeli, hogy az átadott termék már garantáltan minden biztonsági rubrikát kipipáljon. Az auditorok az elkészült kódba is belenéznek, amelynek működését, funkcióit, illetve a megvalósítást, a fejlesztők mutatják be nekik.

KERESD A HIBÁT!

A szegmensben ugyanakkor a munka egyik legizgalmasabb része éppen az, ha valamilyen hiba mégis átcsúszik a szűrőn – persze nem a közutakig, csupán a tesztelés egy későbbi szakaszáig, ahol már nem kisebb komponenseket, hanem a rendszer nagyobb részeit, vagy akár annak egészét ellenőrzik. A teljes ECU teszteléstől vagy a tesztpadról visszanézve a hibák lokalizálása és a „debugolás” már komoly kihívást jelent, ami a teljes szoftverre nagy rálátást igényel. A kérdőjelek kiiktatásában persze nagy segítség, hogy a teljes fejlesztés egy budapesti épületben zajlik, így nem kell messzire menni, ha tanácsra van szükség az egyes kódrészek készítőitől.

A hibakeresés sokszínűségére érdekes példa a vállalatnál egy alkalommal az ECU tesztelés során észlelt hiba, mikor az egység legkülönbözőbb részei jeleztek problémát, látszólag bármilyen logikus mintázat nélkül – ráadásul az egyes elemek nem is minden vizsgálatnál dobtak hibákat, időnként gond nélkül működtek. Végül kiderült, hogy nem szoftveres probléma állt a háttérben, az eszközbe a gyártás során egy apró, felmágneseződött fémforgács került, amely ide-oda ugrálva véletlenszerűen zárta rövidre az egyes komponensek lábait.

Annak érdekében, hogy a fejlesztők a megfelelő rálátást szerezzenek valamennyi rendszerre és azok elemeire, a thyssenkrupp budapesti központjában is erős képzési programot is vezet. Az újonnan érkező kollégák az első 1-2 hónapot csak tanulással töltik, különböző példákkal, az éles rendszereket szimuláló gyakorlóanyagokkal, persze még „tét nélkül”.  Ezen blokk elvégzése után kerülnek csak éles feladatokhoz. A tudásbővítés később sem áll meg, a szakértő kollégák folyamatos előadásokkal tartják naprakészen a thyssenkrupp fejlesztői gárdáját – hogy egyetlen fémszilánk se csúszhasson át az elektromos kormányrendszerek biztonsági szűrőin.

[A thyssenkrupp megbízásából készített, fizetett anyag.]