McKinsey: a szoftver és az elektronikai architektúra újragondolása az autóiparban

McKinsey: a szoftver és az elektronikai architektúra újragondolása az autóiparban

Ahogy az autó továbbra is áttér a hardver-vezéreltről a szoftvervezéreltre, a versenyszabályok az autóiparban drámaian megváltoznak.

A motor volt a 20. századi autók technológiai és mérnöki magja. Ma ezt a szerepet egyre inkább szoftverek, nagyobb számítási teljesítmény és fejlett érzékelők töltik be; a legtöbb innováció magában foglalja mindezt. Ezeken a dolgokon minden múlik, az autók hatékonyságától, az internethez való hozzáféréstől és az autonóm vezetés lehetőségétől kezdve az elektromos mobilitásig és az új mobilitási megoldásokig.

Az elektronika és a szoftverek fontosabbá válásával azonban bonyolultságuk is növekszik. Vegyük példaként a modern autókban található kódsorok (SLOC) növekvő számát. 2010-ben egyes járművek körülbelül tízmillió SLOC-val rendelkeztek; 2016-ra ez a szám 15-szörösére, körülbelül 150 millió kódsorra nőtt. A lavinaszerű összetettség komoly problémákat okoz a szoftverminőségben, amint azt az új autókról szóló számos vélemény is bizonyítja.

Az autók fokozott autonómiával rendelkeznek. Ezért az autóiparban dolgozók a szoftverek és az elektronika minőségét és biztonságát tekintik kulcsfontosságú követelménynek az emberek biztonsága érdekében. Az autóiparnak újra kell gondolnia a szoftver, valamint az elektromos és elektronikus architektúra modern megközelítését.

Egy sürgető iparági probléma megoldása

Ahogy az autóipar áttér a hardvervezérelt eszközökről a szoftvervezérelt eszközökre, a járművön lévő szoftverek és elektronikai eszközök átlagos mennyisége gyorsan növekszik. Napjainkban a szoftverek a D szegmensű vagy nagyobb autók teljes tartalmának 10%-át teszik ki (körülbelül 1220 dollár). A szoftverek átlagos részesedése várhatóan 11%-kal nő. Az előrejelzések szerint 2030-ra a szoftverek a teljes járműtartalom 30%-át teszik ki (körülbelül 5200 dollár). Nem meglepő, hogy az autófejlesztés egyes szakaszaiban részt vevő emberek a szoftverek és az elektronika által lehetővé tett innovációk előnyeit próbálják kihasználni.

McKinsey: a szoftver és az elektronikai architektúra újragondolása az autóiparban

A szoftvercégek és más digitális szereplők többé nem akarnak lemaradni. Elsőrangú beszállítóként próbálják az autógyártókat vonzani. A vállalatok bővítik részvételüket az autóipari technológiai halmazban azáltal, hogy a szolgáltatásokról és alkalmazásokról az operációs rendszerek felé haladnak. Az elektronikus rendszerekkel való munkához szokott cégek ugyanakkor bátran belépnek a technológiai óriáscégek technológiáinak és alkalmazásainak birodalmába. A prémium autógyártók haladnak előre, és fejlesztik saját operációs rendszereiket, hardveres absztrakcióikat és jelfeldolgozásukat, hogy termékeiket egyedivé tegyék.

A fenti stratégiának megvannak a következményei. A jövőben a jármű-szolgáltatás-orientált architektúra (SOA) közös számítási platformokra épül. A fejlesztők sok újdonsággal egészítenek ki: megoldásokat az internetelérés területén, alkalmazásokat, mesterséges intelligencia elemei, fejlett analitika és operációs rendszerek. A különbségek nem az autó hagyományos hardverében lesznek, hanem a felhasználói felületben, valamint abban, hogy hogyan működik szoftverekkel és fejlett elektronikával.

A jövő autói új, márkás versenyelőnyök platformjára költöznek.

McKinsey: a szoftver és az elektronikai architektúra újragondolása az autóiparban

Ezek valószínűleg az infotainment innovációkat, autonóm vezetési képességek valamint a „hibabiztos” viselkedésen alapuló intelligens biztonsági funkciók (pl. olyan rendszer, amely akkor is képes ellátni kulcsfontosságú funkcióját, ha egy része meghibásodik). A szoftverek továbbra is lefelé haladnak a digitális stackben, hogy az intelligens érzékelők leple alatt a hardver részévé váljanak. A veremek vízszintesen integrálódnak, és új rétegeket kapnak, amelyek áthelyezik az architektúrát a SOA-ba.

A divatirányzatok megváltoztatják a játékszabályokat. Befolyásolják a szoftvereket és az elektronikus architektúrát. Ezek a trendek a technológiák összetettségét és kölcsönös függését eredményezik. Például új intelligens érzékelők és alkalmazások jönnek létre „adatboom” a járműben. Ha az autóipari vállalatok versenyképesek akarnak maradni, akkor hatékonyan kell feldolgozniuk és elemezniük az adatokat. A moduláris SOA-frissítések és az OTA-frissítések kulcsfontosságú követelményei lesznek a flották komplex szoftvereinek támogatásához. Nagyon fontosak az új üzleti modellek megvalósításában is, amelyekben a funkciók igény szerint jelennek meg. Egyre elterjedtebbek lesznek az infotainment rendszerek, és bár kisebb mértékben, de fejlettek vezetőtámogató rendszerek (ADAS). Ennek az az oka, hogy egyre több külső alkalmazásfejlesztő kínál járművekhez termékeket.

A digitális biztonsági követelmények miatt a hagyományos hozzáférés-szabályozás stratégiája már nem érdekes. Ideje váltani integrált biztonsági koncepció, amelyet a kibertámadások előrejelzésére, megelőzésére, észlelésére és az ellenük való védekezésre terveztek. A magas szinten automatizált vezetési (HAD) képességek megjelenésével a funkcionalitás konvergenciájára, a kiváló számítási teljesítményre és a magas szintű integrációra lesz szükségünk.

Tíz hipotézis feltárása a jövő elektromos vagy elektronikus architektúrájáról

Mind a technológia, mind az üzleti modell fejlődési pályája még nincs egyértelműen meghatározva. Kiterjedt kutatásaink és szakértői véleményeink alapján azonban tíz hipotézist dolgoztunk ki a jövő elektromos vagy elektronikus járművek architektúrájával és annak iparági vonatkozásaival kapcsolatban.

Az elektronikus vezérlőegységek (ECU) összevonása egyre gyakoribb lesz

A konkrét funkciókhoz több specifikus ECU helyett (mint a jelenlegi „függvény hozzáadása, ablak hozzáadása” stílusban), az iparág egységes jármű-ECU-architektúrára fog térni.

Az első fázisban a legtöbb funkció az egyesített tartományvezérlőkre összpontosul. Az alapvető járműtartományok esetében ezek részben felváltják az elosztott ECU-kban jelenleg elérhető funkciókat. A fejlesztések már folyamatban vannak. A készterméket két-három éven belül várjuk a piacra. A konszolidáció legvalószínűbb az ADAS és HAD funkciókkal kapcsolatos veremekben, míg az alapvetőbb járműfunkciók nagyobb fokú decentralizációt őrizhetnek meg.

Az autonóm vezetés felé haladunk. Ezért elengedhetetlenné válik a szoftverfunkciók virtualizálása és a hardvertől való elvonatkoztatás. Ez az új megközelítés többféleképpen is megvalósítható. Lehetőség van a hardverek különböző késleltetési és megbízhatósági követelményeknek megfelelő veremekbe történő kombinálására. Példa lehet egy nagy teljesítményű verem, amely támogatja a HAD és ADAS funkciókat, és egy különálló, alacsony késleltetésű, idővezérelt verem az alapvető biztonsági funkciókhoz. Vagy lecserélheti az ECU-t egy tartalék „szuperszámítógépre”. Egy másik lehetséges forgatókönyv az, amikor teljesen feladjuk a vezérlőegység koncepcióját egy intelligens számítástechnikai hálózat javára.

A változások mögött elsősorban három tényező áll: a költségek, az új piaci belépők és a HAD iránti kereslet. A szolgáltatások fejlesztésének és a szükséges számítástechnikai hardvernek – beleértve a kommunikációs berendezéseket is – költségeinek csökkentése felgyorsítja a konszolidációs folyamatot. Ugyanez mondható el az autóipari piac új belépőiről, akik valószínűleg megzavarják az iparágat a járműarchitektúra szoftverközpontú megközelítésével. A HAD funkcionalitás és redundancia iránti növekvő igény szintén megköveteli az ECU nagyobb mértékű konszolidációját.

Néhány prémium autógyártó és beszállítóik már aktívan részt vesznek az ECU konszolidációjában. Megteszik az első lépéseket az elektronikus architektúra frissítésére, bár jelenleg még nincs prototípus.

Az ipar korlátozni fogja az egyes berendezésekhez használt kötegek számát

A konszolidációs támogatás normalizálja a veremkorlátot. Ez különválasztja majd a jármű és az ECU hardver funkcióit, amely magában foglalja a virtualizáció aktív használatát. A hardver és a firmware (beleértve az operációs rendszert is) az alapvető funkcionális követelményektől függ, nem pedig a jármű funkcionális tartományának része. Az elválasztás és a szolgáltatás-orientált architektúra biztosítása érdekében korlátozni kell a veremek számát. Az alábbiakban felsoroljuk azokat a halmazokat, amelyek 5-10 év múlva az autók jövő generációinak alapját képezhetik:

  • Idővezérelt verem. Ebben a tartományban a vezérlő közvetlenül az érzékelőhöz vagy működtetőhöz csatlakozik, míg a rendszereknek támogatniuk kell a szigorú valós idejű követelményeket, miközben alacsony késleltetést kell tartaniuk; Az erőforrás-ütemezés időalapú. Ez a köteg olyan rendszereket tartalmaz, amelyek a legmagasabb szintű járműbiztonságot érik el. Példa erre a klasszikus Automotive Open Systems Architecture (AUTOSAR) tartomány.
  • Idő- és eseményvezérelt verem. Ez a hibrid verem egyesíti a nagy teljesítményű biztonsági alkalmazásokat például az ADAS és a HAD támogatásával. Az alkalmazásokat és a perifériákat az operációs rendszer választja el, míg az alkalmazások ütemezettek. Egy alkalmazáson belül az erőforrások ütemezése lehet idő vagy prioritás alapján. A működési környezet biztosítja, hogy a kritikus fontosságú alkalmazások elszigetelt tárolókban fussanak, egyértelműen elkülönítve ezeket az alkalmazásokat a járműben lévő egyéb alkalmazásoktól. Jó példa erre az adaptív AUTOSAR.
  • Eseményvezérelt verem. Ez a köteg az infotainment rendszerre összpontosít, ami nem kritikus a biztonság szempontjából. Az alkalmazások egyértelműen el vannak választva a perifériáktól, és az erőforrások ütemezése optimális vagy eseményalapú ütemezéssel történik. A verem látható és gyakran használt funkciókat tartalmaz: Android, Automotive Grade Linux, GENIVI és QNX. Ezek a funkciók lehetővé teszik a felhasználó számára, hogy kapcsolatba lépjen a járművel.
  • Felhőverem. Az utolsó verem az adatokhoz való hozzáférést fedi le, és külsőleg koordinálja azokat, valamint a jármű funkcióit. Ez a verem felelős a kommunikációért, valamint az alkalmazások biztonsági ellenőrzéséért (hitelesítésért), és egy speciális autóipari interfészt hoz létre, beleértve a távdiagnosztikát is.

Az autóipari beszállítók és a technológiai gyártók már elkezdtek szakosodni ezeknek a készleteknek egy részére. Kiváló példa erre az infotainment rendszer (eseményvezérelt stack), ahol a vállalatok kommunikációs képességeket – 3D-t és fejlett navigációt – fejlesztenek. A második példa a mesterséges intelligencia és az érzékelés a nagy teljesítményű alkalmazásokhoz, ahol a beszállítók kulcsfontosságú autógyártókkal együttműködve fejlesztenek számítástechnikai platformokat.

Az idővezérelt tartományban az AUTOSAR és a JASPAR támogatja ezeknek a veremeknek a szabványosítását.

A köztes szoftver elvonja az alkalmazásokat a hardvertől

Ahogy a járművek folyamatosan fejlődnek a mobil számítástechnikai platformok felé, a köztes szoftverek lehetővé teszik a járművek újrakonfigurálását, valamint szoftvereik telepítését és frissítését. Manapság az egyes ECU-kban található köztes szoftverek megkönnyítik az eszközök közötti kommunikációt. A járművek következő generációjában összekapcsolja a tartományvezérlőt a hozzáférési funkciókkal. Az autóban található ECU hardver használatával a köztes szoftver absztrakciót, virtualizációt, SOA-t és elosztott számítást biztosít.

Már van bizonyíték arra, hogy az autóipar rugalmasabb architektúrák felé mozdul el, beleértve a köztes szoftvereket is. Például az AUTOSAR adaptív platform egy dinamikus rendszer, amely köztes szoftvert, komplex operációs rendszer támogatást és modern többmagos mikroprocesszorokat tartalmaz. A jelenleg elérhető fejlesztések azonban csak egy ECU-ra korlátozódnak.

Középtávon a fedélzeti érzékelők száma jelentősen növekedni fog

A következő két-három járműgenerációban az autógyártók hasonló funkciójú szenzorokat szerelnek fel, hogy biztosítsák a biztonsággal kapcsolatos tartalékok elegendőségét.

McKinsey: a szoftver és az elektronikai architektúra újragondolása az autóiparban

Hosszú távon az autóipar dedikált szenzormegoldásokat fejleszt ki számuk és költségük csökkentése érdekében. Úgy gondoljuk, hogy a radar és a kamera kombinálása lehet a legnépszerűbb megoldás a következő öt-nyolc évben. Mivel az autonóm vezetési képességek folyamatosan bővülnek, szükséges lesz a lidarok bevezetése. Redundanciát biztosítanak mind az objektumelemzés, mind a lokalizáció területén. Például egy SAE International L4 (magas automatizálású) autonóm vezetési konfigurációhoz kezdetben valószínűleg négy-öt lidar érzékelőre lenne szükség, beleértve azokat is, amelyeket a hátsó részen szereltek fel a városi navigációhoz és a közel 360 fokos láthatósághoz.

Hosszú távon nehéz bármit is mondani a járművekben lévő érzékelők számáról. Számuk vagy növekedni fog, csökkenni fog, vagy változatlan marad. Minden az előírásoktól, a megoldások műszaki érettségétől és attól, hogy különböző esetekben több szenzort lehet használni, függ. A szabályozási követelmények például fokozhatják a járművezetői felügyeletet, ami több érzékelőt eredményezhet a járműben. Várhatóan több szórakoztató elektronikai érzékelőt fogunk használni a jármű belsejében. A mozgásérzékelők, az állapotfigyelés (pulzusszám és álmosság), az arc- és íriszfelismerés csak néhány a lehetséges felhasználási esetek közül. A szenzorok számának növeléséhez, vagy akár a dolgok változatlan maradásához azonban szélesebb körű anyagokra lesz szükség, nemcsak magukban az érzékelőkben, hanem a járműhálózatban is. Ezért sokkal jövedelmezőbb az érzékelők számának csökkentése. A magasan automatizált vagy teljesen automatizált járművek megjelenésével a fejlett algoritmusok és a gépi tanulás javíthatják az érzékelők teljesítményét és megbízhatóságát. A nagyobb teljesítményű és jobb szenzortechnológiáknak köszönhetően előfordulhat, hogy nincs szükség felesleges érzékelőkre. A ma használt szenzorok elavulhatnak - több funkcionális szenzor is megjelenik (például a kamera alapú parkolóasszisztens vagy lidar helyett ultrahangos szenzorok jelenhetnek meg).

Az érzékelők okosabbak lesznek

A rendszerarchitektúráknak intelligens és integrált érzékelőkre lesz szükségük a nagymértékben automatizált vezetéshez szükséges hatalmas mennyiségű adat kezeléséhez. A magas szintű funkciók, mint például a szenzorfúzió és a XNUMXD pozicionálás központi számítási platformokon futnak majd. Az előfeldolgozási, szűrési és gyorsreakciós hurkok valószínűleg a peremen helyezkednek el, vagy magában az érzékelőben hajtják végre. Egy becslés szerint egy autonóm autó óránként generált adatmennyiséget négy terabájtra teszi. Ezért az AI az ECU-tól az érzékelőkhöz fog költözni, hogy elvégezze az alapvető előfeldolgozást. Alacsony késleltetést és alacsony számítási teljesítményt igényel, különösen, ha összehasonlítja az érzékelőkben történő adatfeldolgozás költségeit és a nagy mennyiségű adat járműben történő továbbításának költségeit. A HAD-ban a közúti döntések redundanciája azonban konvergenciát igényel a központosított számítástechnika számára. Valószínűleg ezeket a számításokat előre feldolgozott adatok alapján számítják ki. Az intelligens érzékelők saját funkcióikat figyelik, míg az érzékelő redundancia javítja az érzékelőhálózat megbízhatóságát, rendelkezésre állását és ezáltal biztonságát. Az érzékelők megfelelő működésének biztosításához minden körülmények között szenzortisztító alkalmazásokra, például jégtelenítőkre, valamint por- és szennyeződéseltávolítókra lesz szükség.

Teljes teljesítményre és redundáns adathálózatokra lesz szükség

A nagy megbízhatóságot igénylő kulcsfontosságú és biztonság szempontjából kritikus alkalmazások teljesen redundáns ciklusokat használnak mindenre, ami a biztonságos manőverezéshez szükséges (adatkommunikáció, áramellátás). Elektromos jármű technológiák bevezetése, a központi számítógépek és az energiaéhes elosztott számítástechnikai hálózatok új redundáns energiagazdálkodási hálózatokat igényelnek. A vezetékes vezérlést és egyéb HAD funkciókat támogató hibatűrő rendszerek redundáns rendszerek fejlesztését teszik szükségessé. Ez jelentősen javítani fogja a modern hibatűrő felügyeleti megvalósítások architektúráját.

Az "Automotive Ethernet" az autó gerincévé válik

A mai autóipari hálózatok nem elégségesek a jövőbeli közlekedési igények kielégítésére. A megnövekedett adatsebesség, a HAD-okkal szembeni redundancia-követelmények, a csatlakoztatott környezetekben a biztonság és védelem iránti igény, valamint az ágazatok közötti szabványosított protokollok iránti igény valószínűleg az autóipari Ethernet megjelenéséhez vezet. Főleg a redundáns központi adatbusz számára lesz kulcsfontosságú eszköz. A tartományok közötti megbízható kommunikáció biztosításához és a valós idejű igények kielégítéséhez Ethernet-megoldásokra lesz szükség. Ez az Ethernet-bővítmények, például az Audio Video Bridging (AVB) és az időérzékeny hálózatok (TSN) hozzáadásának köszönhetően lehetséges. Az iparág képviselői és az OPEN Alliance támogatja az Ethernet technológia átvételét. Sok autógyártó már megtette ezt a nagy lépést.

A hagyományos hálózatok, például a helyi összekötő hálózatok és a vezérlőhálózatok továbbra is használhatók lesznek a járműben, de csak a zárt alacsonyabb szintű hálózatok esetében, mint például az érzékelők. Az olyan technológiákat, mint a FlexRay és a MOST, valószínűleg felváltja az autóipari Ethernet és annak bővítményei, az AVB és a TSN.

A jövőben arra számítunk, hogy az autóipar más Ethernet-technológiákat – HDBP-t (nagy késleltetésű sávszélességű termékek) és 10 gigabites technológiákat – is alkalmaz majd.

Az OEM-ek mindig szigorúan ellenőrizni fogják az adatkapcsolatot a funkcionális biztonság és a HAD biztosítása érdekében, de interfészeket nyitnak meg, hogy harmadik felek hozzáférhessenek az adatokhoz.

A biztonsági szempontból kritikus adatokat továbbító és fogadó központi kommunikációs átjárók mindig közvetlenül csatlakoznak az OEM-háttérrendszerhez. Az adatokhoz való hozzáférés harmadik felek számára nyitva áll, ha ezt a szabályok nem tiltják. Az Infotainment egy „tartozék” a járműhöz. Ezen a területen a kialakulóban lévő nyílt interfészek lehetővé teszik a tartalomszolgáltatók és alkalmazások számára termékeik bevezetését, miközben az OEM-ek a lehető legjobban betartják a szabványokat.

A mai fedélzeti diagnosztikai portot csatlakoztatott telematikai megoldások váltják fel. A járműhálózathoz már nem lesz szükség karbantartási hozzáférésre, de az OEM-háttérrendszereken keresztül folyhat. Az eredeti gyártók adatportokat biztosítanak a jármű hátulján bizonyos használati esetekben (lopott jármű nyomon követése vagy személyi biztosítás). Az utángyártott készülékek azonban egyre kevésbé férnek majd hozzá a belső adathálózatokhoz.

A nagy flottaüzemeltetők nagyobb szerepet fognak játszani a felhasználói élményben, és értéket teremtenek a végfelhasználók számára. Különböző járműveket kínálhatnak majd különböző célokra ugyanazon az előfizetésen belül (például napi ingázáshoz vagy hétvégi kiruccanáshoz). Több OEM-háttérrendszert kell használniuk, és konszolidálniuk kell az adatokat a flottáik között. A nagy adatbázisok ezután lehetővé teszik a flottaüzemeltetők számára, hogy az OEM-szinten nem elérhető konszolidált adatokat és elemzéseket bevételre tegyék.

Az autók felhőszolgáltatásokat fognak használni a fedélzeti információk külső adatokkal való kombinálására

A „nem érzékeny” adatok (azaz olyan adatok, amelyek nem kapcsolódnak személyazonossághoz vagy biztonsághoz) egyre gyakrabban kerülnek feldolgozásra a felhőben további információk megszerzése érdekében. Ezen adatok OEM-en kívüli elérhetősége a jövőbeli törvényektől és szabályozásoktól függ. Ahogy nőnek a mennyiségek lehetetlen lesz adatelemzés nélkül. Az elemzésre az információk feldolgozásához és a fontos adatok kinyeréséhez van szükség. Elkötelezettek vagyunk az autonóm vezetés és más digitális innovációk mellett. Az adatok hatékony felhasználása a több piaci szereplő közötti adatmegosztáson múlik. Egyelőre nem világos, hogy ezt ki és hogyan fogja megtenni. A nagy autóipari beszállítók és technológiai vállalatok azonban már építenek olyan integrált autóipari platformokat, amelyek képesek kezelni ezt az új adatmennyiséget.

Az autókban olyan fejleszthető alkatrészek jelennek meg, amelyek támogatják a kétirányú kommunikációt

A fedélzeti tesztrendszerek lehetővé teszik a járművek számára, hogy automatikusan ellenőrizzék a frissítéseket. Képesek leszünk kezelni a jármű életciklusát és funkcióit. Az összes ECU adatokat küld és fogad az érzékelőktől és működtetőktől, adatokat kérve. Ezeket az adatokat az innovációk fejlesztésére használják fel. Példa erre egy útvonal felépítése a jármű paraméterei alapján.

Az OTA frissítési képesség elengedhetetlen a HAD számára. Ezekkel a technológiákkal új funkciókat, kiberbiztonságot, valamint a funkciók és szoftverek gyorsabb telepítését biztosítjuk. Valójában az OTA frissítési képesség a hajtóereje a fent leírt fontos változtatások közül. Ezenkívül ez a képesség átfogó biztonsági megoldást igényel a köteg minden szintjén – a járművön kívül és az ECU belsejében egyaránt. Ezt a megoldást még ki kell dolgozni. Érdekes lesz látni, hogy ki és hogyan csinálja.

Az autófrissítéseket úgy lehet majd telepíteni, mint egy okostelefonra? Az iparágnak le kell küzdenie a szállítói szerződések, a szabályozási követelmények, valamint a biztonsági és adatvédelmi aggályok korlátait. Sok autógyártó bejelentette, hogy OTA szolgáltatást kíván bevezetni, beleértve a járműveikhez tartozó, vezeték nélküli frissítéseket.

Az OEM-ek szabványosítják flottájukat OTA platformokon, szorosan együttműködve a technológiai szolgáltatókkal ezen a területen. Hamarosan nagyon fontossá válnak a járműben való kapcsolódás és az OTA platformok. Az OEM-ek megértik ezt, és szeretnének nagyobb tulajdonjogot szerezni ebben a piaci szegmensben.

A járművek szoftver-, funkció- és biztonsági frissítéseket kapnak tervezési élettartamuk idejére. A szabályozó hatóságok valószínűleg szoftverkarbantartást biztosítanak a jármű tervezésének integritásának biztosítása érdekében. A szoftver frissítésének és karbantartásának szükségessége új üzleti modellekhez vezet a járművek karbantartása és üzemeltetése terén.

Az autóipari szoftverek és az elektronikus architektúra jövőbeli hatásainak felmérése

Az autóipart érintő trendek jelentős hardverrel kapcsolatos bizonytalanságokat okoznak. A szoftverek és az elektronikus architektúra jövője azonban ígéretesnek tűnik. Minden lehetőség nyitva áll az ipar előtt: az autógyártók iparági szövetségeket alakíthatnak a járműarchitektúra szabványosítására, a digitális óriáscégek fedélzeti felhőplatformokat valósíthatnak meg, a mobilitási szereplők saját maguk gyárthatnák járműveiket vagy fejleszthetnének járműcsomagokat nyílt forráskóddal és szoftverekkel, az autógyártók bevezethetnének egyre kifinomultabb autonóm autók internetkapcsolattal.

A termékek hamarosan már nem hardverközpontúak lesznek. Szoftverorientáltak lesznek. Ez az átállás nehéz lesz azoknak az autógyártó cégeknek, amelyek hozzászoktak a hagyományos autók gyártásához. A leírt trendek és változások ismeretében azonban még a kis cégeknek sem lesz más választásuk. Fel kell készülniük.

Számos fő stratégiai lépést látunk:

  • Külön járműfejlesztési ciklusok és járműfunkciók. Az OEM-eknek és az XNUMX. szintű beszállítóknak el kell dönteniük, hogyan fejlesztik, kínálják és telepítik a funkciókat. Függetleneknek kell lenniük a járműfejlesztési ciklusoktól, mind műszaki, mind szervezési szempontból. Tekintettel a jelenlegi járműfejlesztési ciklusokra, a vállalatoknak meg kell találniuk a módot a szoftverinnováció kezelésére. Ezenkívül fontolóra kell venniük a meglévő flották frissítési és frissítési lehetőségeit (például számítási egységeket).
  • Határozza meg a szoftver- és elektronikai fejlesztés cél hozzáadott értékét. Az OEM-eknek meg kell határozniuk azokat a megkülönböztető jellemzőket, amelyekhez viszonyítási alapokat állíthatnak fel. Emellett kritikus fontosságú, hogy egyértelműen meghatározzák a saját szoftver- és elektronikai fejlesztéseik cél hozzáadott értékét. Meg kell határoznia azokat a területeket is, ahol termékekre lesz szükség, és azokat a témákat, amelyeket csak a szállítóval vagy partnerrel szabad megvitatni.
  • Állítson be egy kifejezett árat a szoftverhez. A szoftver és a hardver szétválasztása érdekében az OEM-eknek újra kell gondolniuk a belső folyamatokat és mechanizmusokat a szoftver közvetlen megvásárlásához. A hagyományos testreszabás mellett azt is fontos elemezni, hogy a szoftverfejlesztés agilis megközelítése hogyan kapcsolható be a beszerzési folyamatba. Itt a szállítók (első, második és harmadik szint) szintén kritikus szerepet játszanak, mivel egyértelmű üzleti értéket kell biztosítaniuk szoftver- és rendszerajánlataikhoz, hogy a bevételek nagyobb részét megszerezhessék.
  • Készítsen konkrét szervezeti diagramot az új elektronikai architektúrához (beleértve a háttérrendszereket is). Az autóiparnak meg kell változtatnia a belső folyamatokat a fejlett elektronikai és szoftverek szállítása és értékesítése érdekében. Ezenkívül figyelembe kell venniük a különböző szervezeti beállításokat a járművekkel kapcsolatos elektronikai témákhoz. Alapvetően az új "réteges" architektúra a jelenlegi "vertikális" felépítés esetleges megszakítását és új "horizontális" szervezeti egységek bevezetését igényli. Emellett bővíteni kell a szoftver- és elektronikai fejlesztők képességeit és készségeit csapatokban.
  • Üzleti modell kidolgozása az egyes járműalkatrészekre, mint termékre (különösen a beszállítók számára). Kritikusan fontos elemezni, hogy mely funkciók adnak valódi értéket a jövőbeli architektúrához, és amelyek ezért pénzzé tehetők. Ez segít abban, hogy versenyképes maradjon, és megragadja az autóelektronikai ipar értékének jelentős részét. Ezt követően új üzleti modelleket kell találni a szoftverek és elektronikus rendszerek értékesítéséhez, legyen az termék, szolgáltatás vagy valami teljesen új.

Ahogy kezdődik az autóipari szoftverek és elektronika új korszaka, alapvetően megváltoztat mindent az üzleti modellekkel, a vásárlói igényekkel és a verseny természetével kapcsolatban. Hiszünk abban, hogy ebből sok pénzt lehet keresni. De ahhoz, hogy hasznot húzzon a közelgő változásokból, az iparágban mindenkinek át kell gondolnia az autógyártással kapcsolatos megközelítését, és bölcsen kell beállítania (vagy módosítania) kínálatát.

Ez a cikk a Global Semiconductor Alliance-szal együttműködésben készült.

Forrás: will.com

Hozzászólás