Ettersom bilen fortsetter overgangen fra maskinvaredrevet til programvaredrevet, endrer konkurransereglene i bilindustrien seg dramatisk.
Motoren var den teknologiske og tekniske kjernen i det 20. århundres bil. I dag fylles denne rollen i økende grad av programvare, større datakraft og avanserte sensorer; de fleste innovasjoner involverer alt dette. Alt avhenger av disse tingene, fra effektiviteten til bilene, deres tilgang til Internett og muligheten for autonom kjøring, til elektrisk mobilitet og nye mobilitetsløsninger.
Men etter hvert som elektronikk og programvare blir viktigere, øker også kompleksitetsnivået. Ta som et eksempel det økende antallet kodelinjer (SLOC) som finnes i moderne biler. I 2010 hadde noen kjøretøy omtrent ti millioner SLOC-er; innen 2016 hadde dette tallet økt 15 ganger til omtrent 150 millioner linjer med kode. Skredlignende kompleksitet forårsaker alvorlige problemer med programvarekvaliteten, noe som fremgår av en rekke anmeldelser av nye biler.
Biler har økt grad av autonomi. Derfor anser folk som jobber i bilindustrien kvaliteten og sikkerheten til programvare og elektronikk som nøkkelkrav for å sikre menneskers sikkerhet. Bilindustrien må revurdere moderne tilnærminger til programvare og elektrisk og elektronisk arkitektur.
Løse et presserende bransjeproblem
Ettersom bilindustrien går fra maskinvaredrevne til programvaredrevne enheter, øker den gjennomsnittlige mengden programvare og elektronikk på et kjøretøy raskt. I dag utgjør programvare 10 % av det totale innholdet i biler for D-segmentet eller større biler (omtrent $1220 11). Den gjennomsnittlige andelen programvare forventes å vokse med 2030 %. Det er spådd at innen 30 vil programvare utgjøre 5200 % av det totale kjøretøyinnholdet (omtrent $XNUMX XNUMX). Det er ikke overraskende at folk som er involvert i en eller annen fase av bilutviklingen prøver å dra nytte av innovasjoner aktivert av programvare og elektronikk.
Programvareselskaper og andre digitale aktører ønsker ikke lenger å stå bak. De prøver å tiltrekke seg bilprodusenter som førsteklasses leverandører. Bedrifter utvider sin deltakelse i bilteknologistabelen ved å gå fra funksjoner og applikasjoner til operativsystemer. Samtidig går selskaper som er vant til å jobbe med elektroniske systemer frimodig inn i riket av teknologier og applikasjoner fra teknologigiganter. Premium bilprodusenter går fremover og utvikler sine egne operativsystemer, maskinvareabstraksjoner og signalbehandling for å gjøre produktene deres unike i naturen.
Det er konsekvenser av strategien ovenfor. Fremtiden vil se kjøretøyserviceorientert arkitektur (SOA) basert på vanlige dataplattformer. Utviklerne vil legge til mange nye ting: løsninger innen internettilgang, applikasjoner, , avanserte analyser og operativsystemer. Forskjellene vil ikke ligge i bilens tradisjonelle maskinvare, men i brukergrensesnittet og hvordan det fungerer med programvare og avansert elektronikk.
Fremtidens biler vil flytte til en plattform med nye merkede konkurransefortrinn.
Disse vil sannsynligvis omfatte infotainmentinnovasjoner, og intelligente sikkerhetsfunksjoner basert på "feilsikker" oppførsel (f.eks. et system som er i stand til å utføre sin nøkkelfunksjon selv om en del av det svikter). Programvare vil fortsette å bevege seg nedover den digitale stabelen for å bli en del av maskinvaren under dekke av smarte sensorer. Stabler vil bli horisontalt integrert og vil motta nye lag som vil flytte arkitekturen til SOA.
Motetrender endrer spillereglene. De påvirker programvare og elektronisk arkitektur. Disse trendene driver kompleksiteten og gjensidig avhengighet av teknologier. For eksempel vil nye smarte sensorer og applikasjoner skape . Hvis bilselskaper ønsker å forbli konkurransedyktige, må de behandle og analysere data effektivt. Modulære SOA-oppdateringer og over-the-air (OTA) oppdateringer vil bli nøkkelkrav for å støtte kompleks programvare i flåter. De er også svært viktige for implementering av nye forretningsmodeller der funksjoner vises på forespørsel. Det vil bli en økende bruk av infotainmentsystemer og, om enn i mindre grad, avansert . Årsaken er at det er flere og flere tredjeparts apputviklere som leverer produkter til kjøretøy.
På grunn av digitale sikkerhetskrav slutter strategien med konvensjonell tilgangskontroll å være interessant. Det er på tide å bytte til , designet for å forutsi, forhindre, oppdage og beskytte mot cyberangrep. Etter hvert som funksjoner for høyautomatisert kjøring (HAD) dukker opp, vil vi trenge konvergens av funksjonalitet, overlegen datakraft og høye integreringsnivåer.
Utforsker ti hypoteser om fremtidig elektrisk eller elektronisk arkitektur
Utviklingsveien for både teknologien og forretningsmodellen er ennå ikke klart definert. Men basert på vår omfattende forskning og ekspertuttalelser har vi utviklet ti hypoteser angående fremtidens elektriske eller elektroniske kjøretøyarkitektur og dens implikasjoner for industrien.
Konsolidering av elektroniske kontrollenheter (ECU) vil bli stadig mer vanlig
I stedet for flere spesifikke ECU-er for spesifikke funksjoner (som i den nåværende stilen "legg til en funksjon, legg til et vindu"), vil industrien gå over til en enhetlig kjøretøy-ECU-arkitektur.
I den første fasen vil det meste av funksjonaliteten være fokusert på forente domenekontrollere. For kjernebildomener vil de delvis erstatte funksjonaliteten som for øyeblikket er tilgjengelig i distribuerte ECUer. Utviklingen er allerede i gang. Vi forventer det ferdige produktet på markedet om to til tre år. Konsolidering vil mest sannsynlig skje i stabler relatert til ADAS- og HAD-funksjoner, mens mer grunnleggende kjøretøyfunksjoner kan beholde en høyere grad av desentralisering.
Vi beveger oss mot autonom kjøring. Derfor vil virtualisering av programvarefunksjoner og abstraksjon fra maskinvare bli avgjørende. Denne nye tilnærmingen kan implementeres på forskjellige måter. Det er mulig å kombinere maskinvare til stabler som oppfyller ulike latens- og pålitelighetskrav. Et eksempel kan være en høyytelsesstabel som støtter HAD- og ADAS-funksjonalitet, og en separat tidsdrevet stack med lav latens for kjernesikkerhetsfunksjoner. Eller du kan erstatte ECU med en backup "superdatamaskin". Et annet mulig scenario er når vi helt forlater konseptet med en kontrollenhet til fordel for et smart datanettverk.
Endringene drives først og fremst av tre faktorer: kostnader, nye markedsaktører og etterspørsel etter HAD. Å redusere kostnadene for funksjonsutvikling og nødvendig datamaskinvare, inkludert kommunikasjonsutstyr, vil fremskynde konsolideringsprosessen. Det samme kan sies for nye aktører i bilmarkedet som sannsynligvis vil forstyrre industrien med en programvaresentrisk tilnærming til kjøretøyarkitektur. Den økende etterspørselen etter HAD-funksjonalitet og redundans vil også kreve en høyere grad av ECU-konsolidering.
Noen premiumbilprodusenter og deres leverandører er allerede aktivt involvert i ECU-konsolidering. De tar de første skrittene for å oppdatere sin elektroniske arkitektur, selv om det for øyeblikket ikke er noen prototype ennå.
Industrien vil begrense antallet stabler som brukes til spesifikt utstyr
Konsolideringsstøtte normaliserer stabelgrensen. Det vil skille funksjonene til kjøretøyet og ECU-maskinvaren, som inkluderer aktiv bruk av virtualisering. Maskinvaren og fastvaren (inkludert operativsystemet) vil avhenge av kjernefunksjonskravene i stedet for å være en del av kjøretøyets funksjonelle domene. For å sikre separasjon og serviceorientert arkitektur må antallet stabler begrenses. Nedenfor er stablene som kan danne grunnlaget for fremtidige generasjoner biler om 5-10 år:
- Tidsdrevet stabel. I dette domenet er kontrolleren direkte koblet til sensoren eller aktuatoren, mens systemene må støtte strenge sanntidskrav og samtidig opprettholde lav latens; ressursplanlegging er tidsbasert. Denne stabelen inkluderer systemer som oppnår det høyeste nivået av kjøretøysikkerhet. Et eksempel er det klassiske Automotive Open Systems Architecture (AUTOSAR)-domenet.
- Tids- og hendelsesdrevet stabel. Denne hybridstakken kombinerer høyytelses sikkerhetsapplikasjoner med støtte for for eksempel ADAS og HAD. Applikasjoner og periferiutstyr er atskilt av operativsystemet, mens applikasjoner er tidsbestemt. Innenfor en applikasjon kan ressursplanlegging være basert på tid eller prioritet. Driftsmiljøet sikrer at virksomhetskritiske applikasjoner kjører i isolerte beholdere, og skiller disse applikasjonene tydelig fra andre applikasjoner i kjøretøyet. Et godt eksempel er adaptiv AUTOSAR.
- Hendelsesdrevet stabel. Denne stabelen fokuserer på infotainmentsystemet, som ikke er sikkerhetskritisk. Applikasjoner er tydelig frikoblet fra periferiutstyr, og ressursene planlegges ved hjelp av optimal eller hendelsesbasert planlegging. Stabelen inneholder synlige og ofte brukte funksjoner: Android, Automotive Grade Linux, GENIVI og QNX. Disse funksjonene lar brukeren samhandle med kjøretøyet.
- Skystabel. Den siste stabelen dekker datatilgang og koordinerer den og kjøretøyets funksjoner eksternt. Denne stabelen er ansvarlig for kommunikasjon, samt applikasjonssikkerhetsverifisering (autentisering) og etablerer et spesifikt bilgrensesnitt, inkludert fjerndiagnostikk.
Billeverandører og teknologiprodusenter har allerede begynt å spesialisere seg på noen av disse stablene. Et godt eksempel er infotainmentsystemet (hendelsesdrevet stack), hvor bedrifter utvikler kommunikasjonsmuligheter – 3D og avansert navigasjon. Det andre eksemplet er kunstig intelligens og sansing for høyytelsesapplikasjoner, der leverandører slår seg sammen med viktige bilprodusenter for å utvikle dataplattformer.
I det tidsdrevne domenet støtter AUTOSAR og JASPAR standardiseringen av disse stablene.
Mellomvare vil abstrahere applikasjoner fra maskinvare
Ettersom kjøretøyer fortsetter å utvikle seg mot mobile dataplattformer, vil mellomvare tillate kjøretøyer å bli rekonfigurert og deres programvare installert og oppdatert. I dag letter mellomvare i hver ECU kommunikasjon mellom enheter. I neste generasjon kjøretøy vil den koble domenekontrolleren til tilgangsfunksjonene. Ved å bruke ECU-maskinvaren i bilen, vil mellomvare gi abstraksjon, virtualisering, SOA og distribuert databehandling.
Det er allerede bevis på at bilindustrien går over til mer fleksible arkitekturer, inkludert mellomvare. For eksempel er den adaptive AUTOSAR-plattformen et dynamisk system som inkluderer mellomvare, støtte for komplekse operativsystemer og moderne multi-core mikroprosessorer. Imidlertid er utviklingen tilgjengelig for øyeblikket begrenset til bare én ECU.
På mellomlang sikt vil antallet sensorer ombord øke betydelig
I de neste to til tre generasjonene med kjøretøy vil bilprodusenter installere sensorer med lignende funksjoner for å sikre at sikkerhetsrelaterte reserver er tilstrekkelige.
På lang sikt vil bilindustrien utvikle dedikerte sensorløsninger for å redusere antall og kostnader. Vi tror at det å kombinere radar og kamera kan være den mest populære løsningen de neste fem til åtte årene. Ettersom mulighetene for autonom kjøring fortsetter å vokse, vil introduksjonen av lidarer være nødvendig. De vil gi redundans både innen objektanalyse og lokalisering. For eksempel vil en SAE International L4 (høy automatisering) autonom kjørekonfigurasjon i utgangspunktet sannsynligvis kreve fire til fem lidar-sensorer, inkludert de som er montert bak for bynavigasjon og nesten 360-graders sikt.
Det er vanskelig å si noe om antall sensorer i kjøretøy på lang sikt. Enten vil antallet øke, reduseres eller forbli det samme. Alt avhenger av regelverket, løsningenes tekniske modenhet og muligheten til å bruke flere sensorer i ulike tilfeller. Reguleringskrav kan for eksempel øke førerovervåkingen, noe som fører til flere sensorer inne i kjøretøyet. Vi kan forvente å se flere forbrukerelektronikksensorer brukt i kjøretøyets interiør. Bevegelsessensorer, helseovervåking (puls og søvnighet), ansikts- og irisgjenkjenning er bare noen av de mulige bruksområdene. For å øke antallet sensorer eller til og med holde ting ved like, vil det imidlertid kreves et bredere utvalg av materialer, ikke bare i selve sensorene, men også i kjøretøynettverket. Derfor er det mye mer lønnsomt å redusere antall sensorer. Med bruken av høyautomatiserte eller helautomatiske kjøretøyer, kan avanserte algoritmer og maskinlæring forbedre sensorytelsen og påliteligheten. Takket være kraftigere og dyktigere sensorteknologier kan det hende at unødvendige sensorer ikke lenger er nødvendige. Sensorene som brukes i dag kan bli utdaterte – mer funksjonelle sensorer vil dukke opp (for eksempel kan ultralydsensorer dukke opp i stedet for en kamerabasert parkeringsassistent eller lidar).
Sensorer vil bli smartere
Systemarkitekturer vil trenge intelligente og integrerte sensorer for å håndtere de enorme datamengdene som kreves for svært automatisert kjøring. Høynivåfunksjoner som sensorfusjon og XNUMXD-posisjonering vil kjøre på sentraliserte dataplattformer. Forbehandlings-, filtrerings- og hurtigresponsløkkene vil sannsynligvis være plassert ved kanten eller utført i selve sensoren. Ett estimat anslår mengden data en autonom bil vil generere hver time til fire terabyte. Derfor vil AI flytte fra ECU til sensorene for å utføre grunnleggende forhåndsbehandling. Det krever lav ventetid og lav beregningsytelse, spesielt når du sammenligner kostnadene ved å behandle data i sensorer og kostnadene ved å overføre store datamengder i et kjøretøy. Redundans av veivedtak i HAD vil imidlertid kreve konvergens for sentralisert databehandling. Mest sannsynlig vil disse beregningene bli beregnet basert på forhåndsbehandlede data. Smarte sensorer vil overvåke sine egne funksjoner, mens sensorredundans vil forbedre påliteligheten, tilgjengeligheten og dermed sikkerheten til sensornettverket. For å sikre riktig sensorytelse under alle forhold, vil sensorrenseapplikasjoner som avisingsmidler og støv- og smussfjernere være nødvendig.
Full strøm og redundante datanettverk vil være nødvendig
Nøkkel- og sikkerhetskritiske applikasjoner som krever høy pålitelighet vil bruke fullstendig redundante sykluser for alt som trengs for sikker manøvrering (datakommunikasjon, strøm). , sentrale datamaskiner og strømkrevende distribuerte datanettverk vil kreve nye redundante strømstyringsnettverk. Feiltolerante systemer som støtter kablet kontroll og andre HAD-funksjoner vil kreve utvikling av redundante systemer. Dette vil forbedre arkitekturen til moderne feiltolerante overvåkingsimplementeringer betydelig.
"Automotive Ethernet" vil stige for å bli ryggraden i bilen
Dagens bilnettverk er ikke tilstrekkelige til å møte behovene til fremtidig transport. Økte datahastigheter, redundanskrav for HAD-er, behovet for sikkerhet og beskyttelse i tilkoblede miljøer, og behovet for standardiserte protokoller på tvers av bransje vil sannsynligvis føre til fremveksten av bil-Ethernet. Det vil bli en nøkkelaktiverer, spesielt for en redundant sentral databuss. Ethernet-løsninger vil være nødvendig for å gi pålitelig kommunikasjon mellom domener og møte sanntidskrav. Dette vil være mulig takket være tillegg av Ethernet-utvidelser som Audio Video Bridging (AVB) og tidssensitive nettverk (TSN). Bransjerepresentanter og OPEN Alliance støtter innføringen av Ethernet-teknologi. Mange bilprodusenter har allerede tatt dette store skrittet.
Tradisjonelle nettverk som lokale sammenkoblingsnettverk og kontrollernettverk vil fortsatt bli brukt i kjøretøyet, men kun for lukkede nettverk på lavere nivå som sensorer. Teknologier som FlexRay og MOST vil sannsynligvis bli erstattet av automotive Ethernet og dets utvidelser AVB og TSN.
I fremtiden forventer vi at bilindustrien også vil bruke andre Ethernet-teknologier – HDBP (high-delay bandwidth products) og 10-Gigabit-teknologier.
OEM-er vil alltid ha streng kontroll over datatilkobling for å sikre funksjonell sikkerhet og HAD, men de vil åpne grensesnitt for å gi tredjeparter tilgang til data
Sentrale kommunikasjonsgatewayer som sender og mottar sikkerhetskritiske data vil alltid kobles direkte til OEM-backend. Tilgang til data vil være åpen for tredjeparter når dette ikke er forbudt etter reglene. Infotainment er et "vedlegg" til kjøretøyet. På dette området vil nye åpne grensesnitt tillate innholdsleverandører og applikasjoner å distribuere produktene sine mens OEM-er følger standarder så godt de kan.
Dagens diagnostiske port om bord vil bli erstattet av tilkoblede telematikkløsninger. Vedlikeholdstilgang for kjøretøynettverket vil ikke lenger være nødvendig, men vil kunne flyte gjennom OEM-backends. OEM-er vil tilby dataporter på baksiden av kjøretøyet for visse brukstilfeller (sporing av stjålne kjøretøy eller personlig forsikring). Imidlertid vil ettermarkedsenheter ha mindre og mindre tilgang til interne datanettverk.
Store flåteoperatører vil spille en større rolle i brukeropplevelsen og skape verdier for sluttkundene. De vil kunne tilby ulike kjøretøy for ulike formål innenfor samme abonnement (for eksempel for daglig pendling eller helgeturer). De vil bli pålagt å bruke flere OEM-backends og konsolidere data på tvers av flåtene deres. Store databaser vil da tillate flåteoperatører å tjene penger på konsoliderte data og analyser som ikke er tilgjengelig på OEM-nivå.
Biler vil bruke skytjenester for å kombinere informasjon om bord med eksterne data
«Ikke-sensitive» data (det vil si data som ikke er knyttet til identitet eller sikkerhet) vil i økende grad bli behandlet i skyen for å innhente tilleggsinformasjon. Tilgjengeligheten av disse dataene utenfor OEM vil avhenge av fremtidige lover og forskrifter. Ettersom volumene vokser . Analytics er nødvendig for å behandle informasjon og trekke ut viktige data. Vi er forpliktet til autonom kjøring og andre digitale innovasjoner. Effektiv bruk av data vil avhenge av deling av data mellom flere markedsaktører. Det er fortsatt uklart hvem som skal gjøre dette og hvordan. Imidlertid bygger store billeverandører og teknologiselskaper allerede integrerte bilplattformer som kan håndtere denne nye mengde data.
Oppgraderbare komponenter vil vises i biler som vil støtte toveiskommunikasjon
Testsystemer om bord vil tillate kjøretøyer å automatisk se etter oppdateringer. Vi vil kunne styre livssyklusen til kjøretøyet og dets funksjoner. Alle ECU-er vil sende og motta data fra sensorer og aktuatorer, og hente data. Disse dataene vil bli brukt til å utvikle innovasjoner. Et eksempel kan være å bygge en rute basert på kjøretøyparametere.
OTA-oppdateringsevne er et must for HAD. Med disse teknologiene vil vi få nye funksjoner, cybersikkerhet og raskere distribusjon av funksjoner og programvare. Faktisk er OTA-oppdateringsevnen drivkraften bak mange av de viktige endringene beskrevet ovenfor. I tillegg krever denne muligheten også en omfattende sikkerhetsløsning på alle nivåer av stabelen – både utenfor kjøretøyet og inne i ECU. Denne løsningen er ennå ikke utviklet. Det blir spennende å se hvem som skal gjøre det og hvordan.
Vil biloppdateringer kunne installeres som på en smarttelefon? Bransjen må overvinne begrensninger i leverandørkontrakter, regulatoriske krav og sikkerhets- og personvernhensyn. Mange bilprodusenter har annonsert planer om å rulle ut OTA-tjenestetilbud, inkludert over-the-air oppdateringer for kjøretøyene deres.
OEM-er vil standardisere sine flåter på OTA-plattformer, i tett samarbeid med teknologileverandører på dette området. Tilkobling i kjøretøy og OTA-plattformer vil snart bli svært viktige. OEM-er forstår dette og ser etter å få mer eierskap i dette markedssegmentet.
Kjøretøyene vil motta programvare, funksjoner og sikkerhetsoppdateringer for deres designliv. Regulerende myndigheter vil sannsynligvis sørge for programvarevedlikehold for å sikre integriteten til kjøretøyets design. Behovet for å oppdatere og vedlikeholde programvare vil føre til nye forretningsmodeller for vedlikehold og drift av kjøretøy.
Vurdere den fremtidige effekten av bilprogramvare og elektronisk arkitektur
Trender som påvirker bilindustrien skaper betydelige hardwarerelaterte usikkerhetsmomenter. Fremtiden for programvare og elektronisk arkitektur ser imidlertid lovende ut. Alle muligheter er åpne for industrien: bilprodusenter kan danne bransjeforeninger for å standardisere kjøretøyarkitektur, digitale giganter kan implementere skyplattformer om bord, mobilitetsaktører kan produsere sine egne kjøretøy eller utvikle kjøretøystabler med åpen kildekode og funksjoner programvare, bilprodusenter kan introdusere stadig mer sofistikerte autonome biler med Internett-tilkobling.
Produktene vil snart ikke lenger være maskinvaresentriske. De vil være programvareorienterte. Denne overgangen vil være vanskelig for bilselskaper som er vant til å produsere tradisjonelle biler. Men gitt trendene og endringene som er beskrevet, vil selv små selskaper ikke ha noe valg. De skal forberede seg.
Vi ser flere strategiske hovedtrinn:
- Separate kjøretøyutviklingssykluser og kjøretøyfunksjoner. OEM-er og Tier XNUMX-leverandører må bestemme hvordan de vil utvikle, tilby og distribuere funksjoner. De må være uavhengige av kjøretøyutviklingssykluser, både fra et teknisk og organisatorisk synspunkt. Gitt dagens kjøretøyutviklingssykluser, må bedrifter finne en måte å administrere programvareinnovasjon på. I tillegg bør de vurdere alternativer for oppgraderinger og oppgraderinger (som dataenheter) for eksisterende flåter.
- Definer mål merverdi for utvikling av programvare og elektronikk. OEM-er må identifisere differensierende funksjoner som de kan sette standarder for. I tillegg er det avgjørende å tydelig definere måltilleggsverdien for deres egen programvare- og elektronikkutvikling. Du bør også identifisere områder hvor det vil være behov for produkter og emner som kun bør diskuteres med leverandøren eller partneren.
- Angi en eksplisitt pris for programvaren. For å koble programvare fra maskinvare, må OEM-er revurdere interne prosesser og mekanismer for å kjøpe programvare direkte. I tillegg til tradisjonell tilpasning er det også viktig å analysere hvordan en smidig tilnærming til programvareutvikling kan knyttes inn i anskaffelsesprosessen. Det er her leverandører (tier XNUMX, tier to og tier three) også spiller en kritisk rolle ettersom de trenger å gi tydelig forretningsverdi til programvare- og systemtilbudene deres slik at de kan ta en større andel av inntektene.
- Utvikle et spesifikt organisasjonsdiagram for den nye elektronikkarkitekturen (inkludert backends). Bilindustrien må endre interne prosesser for å levere og selge avansert elektronikk og programvare. De må også vurdere ulike organisatoriske innstillinger for kjøretøyrelaterte elektroniske emner. I utgangspunktet krever den nye "lagdelte" arkitekturen potensiell forstyrrelse av det nåværende "vertikale" oppsettet og innføring av nye "horisontale" organisasjonsenheter. I tillegg er det behov for å utvide kapasitetene og ferdighetene til programvare- og elektronikkutviklere i team.
- Utvikle en forretningsmodell for individuelle kjøretøykomponenter som et produkt (spesielt for leverandører). Det er avgjørende å analysere hvilke funksjoner som gir reell verdi til den fremtidige arkitekturen og derfor kan tjene penger. Dette vil hjelpe deg å holde deg konkurransedyktig og ta en betydelig andel av verdien i bilelektronikkindustrien. Deretter må det finnes nye forretningsmodeller for salg av programvare og elektroniske systemer, enten det er et produkt, en tjeneste eller noe helt nytt.
Når den nye æraen for bilprogramvare og elektronikk begynner, endrer den fundamentalt alt om forretningsmodeller, kundebehov og konkurransens natur. Vi tror det vil være mye penger å tjene på dette. Men for å utnytte de forestående endringene, må alle i bransjen revurdere sin tilnærming til bilproduksjon og sette (eller endre) tilbudene sine med omhu.
Denne artikkelen ble utviklet i samarbeid med Global Semiconductor Alliance.
Kilde: www.habr.com