Ez egy hosszabb téma ismét és nehéz lesz egy hozzászólásba beleszorítani. Fogalmam sincs, hogy a VW hogyan csinálja, de gyanítom hogy az egész iparban elég hasonló a gyakorlat.

A fejlesztés nem 0-ról 1-re ugrással fut. Sem a HW, sem a SW területén. Mind a két oldalon vannak különféle prototípus szériák, csak a HW oldalon ez tipikusan kézzel is megfogható protókat jelent, míg SW oldalon meg különféle releasek vannak. Ezeket igyekeznek nagyjából összehangolni, mert ha jön egy új protó széria egy bizonyos érettségi fokkal, akkor ahhoz kell egy megfelelő funkciókat és kalibrációt tudó SW is.

A korábban érvényes fejlesztési irány, hogy sok-sok ECU van különféle funkciókra és alrendszerekre kezdett teljesen tarthatatlan lenni, mert már sokszáz különféle ECU van egy kocsiban és nagyon komplikált az egész. Többek között a Tesla is átállt a „szuperszámítógépes” topológiára, amikor korábban sosem látott számítási teljesítményű központi rendszerekről beszélünk. Ez nem csak a Tesla sajátja, mások is ilyet használnak az új fejlesztésekben.

Ez azért még nem azt jelenti, hogy csak egy nagy doboz van középen egy villogó piros leddel és mindent az csinál. A szoftver még mindig borzasztó komplikált erre. És még mindig kell hozzá integrálni az összes alrendszert, biztosítani a robosztus működést és mindenféle diagnosztikai követelménynek meg kell felelnie a rendszernek.

A fejlesztés tipikusan kicsiről nagyra lépések sorozatával történik. Először legtöbbször csak MIL (model in the loop) van, aztán SIL (SW in the loop), aztán jön a fejlesztés és tesztelés azon szakasza, amikor HIL (HW in the loop) megy. Egy HIL lehet egy dupla hűtőszekrény méretű EUR-ban is sokszámjegyű rack cucc, ami egy egész autó összes funkcióját valós időben futtatja és szimulálja és ebbe kötsz bele mondjuk egy ECU-t, amit aztán a Gabibácsi melójához hasonló automatizált tesztelési case-ek sorozatával próbálsz kiakasztani.

Ha ezeken a lépéseken is átmentél, akkor jöhet a különféle rigekben tesztelés, amikor mondjuk „csak” egy hajtáslánc (akár elektromos, akár fosszilis) fut egy tesztpadon. Körülötte szimulált autóval. Vagy lehet egyre nagyobb részegységeket rigben nyúzni. És a végső stáció a kocsiban tesztelés. Ez a legdrágább, leglassabb és mégis sok esetben ez adja a leginkább valósághoz közeli helyzetet, mert a modellek még nem 100%-os megbízhatóságúak. Annak ellenére, hogy folyamatosan javítják őket.

Az egészet meg lehet fűszerezni azzal, hogy sosem a nagy VW csinál minden alkatrészt, hogy vesznek termékeket, amiket esetleg még fejleszt a kocsi fejlesztésével párhuzamosan a beszállító. Tehát a sourcing idején még csak egy fejlesztési terv van csak, ami viszont feltételezi, hogy mondjuk a kocsi hard tool fázisára már egy közepesen érett szuperszámítógép HW és SW lesz majd. Aztán ha mondjuk csúszik a beszállító, akkor részben a bőrt is lenyúzzák róla a szerződéseben rögzített feltételek mentén, de ugyanakkor a VW is oboázik, mivel mondjuk a következő protó szériára még nem tud 85%-os készültséget adni az a bizonyos alrendszer, hanem csak mondjuk 65%-os. Ez késlelteti az integrációs teszteket, a többi ezzel kapcsolatos rendszer fejlesztése is csúszik és végső soron a folyamat végére remélt közel 100%-os készültségi szint helyett lesz mondjuk 80%.

Ez nem azt jelenti, hogy az egész használhatatlan, de a projekt kezdetén megálmodott feature set elérése nem valósult meg. Ki lehetne akár adni a kocsit piacra, de a projekt által definiált vevőkör által elvárt funkciók nem működnének vagy nem jól működnének. Vagy esetleg a homologizációhoz szükséges attribútumok nem érhetőek el. Valami miatt úgy dönt a projekt, hogy kisebb rizikó behúzni a kéziféket és várni az SOP-vel, mint rizikózni és kiadni félkészen.

Szó nincs róla, hogy behazudtak valamit. Egyszerűen egy felfoghatatlanul komplikált folyamat egyes részei késtek valamilyen általunk nem ismert faktor miatt, ami megcsúsztatta az egész folyamatot.

Nem védem a VW-t, de túl hamar törsz pálcát felettük, miközben a részleteket nem ismered.