McKinsey: przemyślenie na nowo architektury oprogramowania i elektroniki w motoryzacji

McKinsey: przemyślenie na nowo architektury oprogramowania i elektroniki w motoryzacji

W miarę jak przemysł motoryzacyjny kontynuuje transformację od napędzanej sprzętem do opartej na oprogramowaniu, zasady konkurencji w przemyśle motoryzacyjnym zmieniają się dramatycznie.

Silnik był technologicznym i inżynieryjnym rdzeniem samochodu XX wieku. Dziś tę rolę coraz częściej pełni oprogramowanie, większa moc obliczeniowa i zaawansowane czujniki; większość innowacji obejmuje to wszystko. Od tych rzeczy zależy wszystko, począwszy od wydajności samochodów, ich dostępu do Internetu i możliwości autonomicznej jazdy, aż po elektromobilność i nowe rozwiązania w zakresie mobilności.

Jednakże w miarę jak elektronika i oprogramowanie zyskują na znaczeniu, wzrasta także poziom ich złożoności. Weźmy na przykład rosnącą liczbę linii kodu (SLOC) zawartych w nowoczesnych samochodach. W 2010 r. niektóre pojazdy miały około dziesięciu milionów SLOC; do 2016 r. liczba ta wzrosła 15-krotnie do około 150 milionów linii kodu. Lawinowa złożoność powoduje poważne problemy z jakością oprogramowania, o czym świadczą liczne recenzje nowych samochodów.

Samochody mają większą autonomię. Dlatego osoby pracujące w branży motoryzacyjnej za kluczowe wymagania mające zapewnić bezpieczeństwo ludzi uznają jakość i bezpieczeństwo oprogramowania i elektroniki. Przemysł motoryzacyjny musi ponownie przemyśleć nowoczesne podejście do oprogramowania oraz architektury elektrycznej i elektronicznej.

Rozwiązanie palącego problemu branżowego

W miarę jak przemysł motoryzacyjny przechodzi od urządzeń sterowanych sprzętowo do urządzeń opartych na oprogramowaniu, średnia ilość oprogramowania i elektroniki w pojeździe szybko rośnie. Obecnie oprogramowanie stanowi 10% całkowitej zawartości samochodów segmentu D lub większych samochodów (około 1220 dolarów). Oczekuje się, że średni udział oprogramowania wzrośnie o 11%. Przewiduje się, że do 2030 r. oprogramowanie będzie stanowić 30% całkowitej zawartości pojazdów (około 5200 USD). Nic dziwnego, że osoby zaangażowane w jakąś fazę rozwoju samochodu starają się czerpać korzyści z innowacji, które umożliwiają oprogramowanie i elektronika.

McKinsey: przemyślenie na nowo architektury oprogramowania i elektroniki w motoryzacji

Producenci oprogramowania i inni gracze cyfrowi nie chcą już pozostać w tyle. Próbują przyciągnąć producentów samochodów jako dostawców pierwszego rzędu. Firmy poszerzają swój udział w stosie technologii motoryzacyjnych, przechodząc z funkcji i aplikacji na systemy operacyjne. Jednocześnie firmy przyzwyczajone do pracy z systemami elektronicznymi odważnie wkraczają w świat technologii i aplikacji technologicznych gigantów. Producenci samochodów klasy premium idą naprzód i opracowują własne systemy operacyjne, abstrakcje sprzętu i przetwarzanie sygnałów, aby nadać swoim produktom wyjątkowy charakter.

Powyższa strategia ma swoje konsekwencje. W przyszłości architektura zorientowana na usługi pojazdów (SOA) będzie oparta na wspólnych platformach obliczeniowych. Twórcy dodadzą mnóstwo nowości: rozwiązania z zakresu dostępu do Internetu, aplikacje, elementy sztucznej inteligencji, zaawansowaną analitykę i systemy operacyjne. Różnice nie będą dotyczyć tradycyjnego sprzętu samochodu, ale interfejsu użytkownika oraz sposobu jego współpracy z oprogramowaniem i zaawansowaną elektroniką.

Samochody przyszłości przejdą na platformę nowych, markowych przewag konkurencyjnych.

McKinsey: przemyślenie na nowo architektury oprogramowania i elektroniki w motoryzacji

Będą one prawdopodobnie obejmować innowacje w zakresie informacji i rozrywki, możliwości jazdy autonomicznej oraz inteligentne funkcje bezpieczeństwa oparte na zachowaniu „bezawaryjnym” (np. system zdolny do wykonywania swojej kluczowej funkcji, nawet jeśli jego część ulegnie awarii). Oprogramowanie będzie nadal przesuwane w dół stosu cyfrowego, aż stanie się częścią sprzętu pod przykrywką inteligentnych czujników. Stosy zostaną zintegrowane poziomo i otrzymają nowe warstwy, które przeniosą architekturę do SOA.

Trendy w modzie zmieniają zasady gry. Wpływają na oprogramowanie i architekturę elektroniczną. Tendencje te wpływają na złożoność i współzależność technologii. Powstaną na przykład nowe inteligentne czujniki i aplikacje „boom danych” w pojeździe. Jeśli firmy motoryzacyjne chcą pozostać konkurencyjne, muszą skutecznie przetwarzać i analizować dane. Modularne aktualizacje SOA i aktualizacje bezprzewodowe (OTA) staną się kluczowymi wymogami w zakresie obsługi złożonego oprogramowania we flotach. Są również bardzo istotne przy wdrażaniu nowych modeli biznesowych, w których funkcjonalności pojawiają się na żądanie. Coraz powszechniejsze będzie wykorzystanie systemów informacyjno-rozrywkowych, choć w mniejszym stopniu, zaawansowanych systemy wspomagania kierowcy (ADAS). Powodem jest to, że coraz więcej zewnętrznych twórców aplikacji dostarcza produkty do pojazdów.

Ze względu na wymogi bezpieczeństwa cyfrowego strategia konwencjonalnej kontroli dostępu przestaje być interesująca. Czas przejść na zintegrowana koncepcja bezpieczeństwa, mające na celu przewidywanie, zapobieganie, wykrywanie i ochronę przed cyberatakami. W miarę pojawiania się możliwości wysoce zautomatyzowanej jazdy (HAD) będziemy potrzebować konwergencji funkcjonalności, najwyższej mocy obliczeniowej i wysokiego poziomu integracji.

Badanie dziesięciu hipotez dotyczących przyszłej architektury elektrycznej lub elektronicznej

Ścieżka rozwoju zarówno technologii, jak i modelu biznesowego nie jest jeszcze jasno określona. Jednak w oparciu o nasze szeroko zakrojone badania i opinie ekspertów opracowaliśmy dziesięć hipotez dotyczących przyszłej architektury pojazdów elektrycznych lub elektronicznych i jej konsekwencji dla branży.

Konsolidacja elektronicznych jednostek sterujących (ECU) będzie coraz bardziej powszechna

Zamiast wielu konkretnych ECU dla określonych funkcji (jak w obecnym stylu „dodaj funkcję, dodaj okno”), branża przejdzie na ujednoliconą architekturę ECU pojazdów.

W pierwszej fazie większość funkcjonalności będzie skupiona na stowarzyszonych kontrolerach domeny. W przypadku podstawowych domen pojazdów częściowo zastąpią one funkcjonalność obecnie dostępną w rozproszonych ECU. Prace już trwają. Gotowego produktu spodziewamy się pojawić na rynku za dwa, trzy lata. Konsolidacja najprawdopodobniej nastąpi w stosach związanych z funkcjami ADAS i HAD, podczas gdy bardziej podstawowe funkcje pojazdu mogą zachować wyższy stopień decentralizacji.

Zmierzamy w stronę jazdy autonomicznej. Dlatego też wirtualizacja funkcji oprogramowania i abstrakcja od sprzętu staną się niezbędne. To nowe podejście można wdrożyć na różne sposoby. Możliwe jest łączenie sprzętu w stosy spełniające różne wymagania dotyczące opóźnień i niezawodności. Przykładem może być stos o wysokiej wydajności obsługujący funkcje HAD i ADAS oraz oddzielny stos sterowany czasem o niskim opóźnieniu dla podstawowych funkcji bezpieczeństwa. Możesz też zastąpić ECU jednym zapasowym „superkomputerem”. Inny możliwy scenariusz to całkowita rezygnacja z koncepcji jednostki sterującej na rzecz inteligentnej sieci komputerowej.

Zmiany wynikają przede wszystkim z trzech czynników: kosztów, nowych uczestników rynku i popytu na HAD. Obniżenie kosztów rozwoju funkcji i wymaganego sprzętu komputerowego, w tym sprzętu komunikacyjnego, przyspieszy proces konsolidacji. To samo można powiedzieć o nowych uczestnikach rynku motoryzacyjnego, którzy prawdopodobnie zrewolucjonizują branżę dzięki skoncentrowanemu na oprogramowaniu podejściu do architektury pojazdów. Rosnące zapotrzebowanie na funkcjonalność i redundancję HAD będzie również wymagać wyższego stopnia konsolidacji ECU.

Niektórzy producenci samochodów premium i ich dostawcy są już aktywnie zaangażowani w konsolidację ECU. Podejmują pierwsze kroki w celu aktualizacji swojej architektury elektronicznej, choć na ten moment nie ma jeszcze prototypu.

Przemysł ograniczy liczbę stosów używanych dla określonego sprzętu

Obsługa konsolidacji normalizuje limit stosu. Oddzieli funkcje pojazdu od sprzętu ECU, co obejmuje aktywne wykorzystanie wirtualizacji. Sprzęt i oprogramowanie sprzętowe (w tym system operacyjny) będą zależeć od podstawowych wymagań funkcjonalnych, a nie stanowić część domeny funkcjonalnej pojazdu. Aby zapewnić separację i architekturę zorientowaną na usługi, liczba stosów musi być ograniczona. Poniżej znajdują się stosy, które mogą stanowić podstawę dla przyszłych generacji samochodów za 5-10 lat:

  • Stos sterowany czasem. W tej dziedzinie kontroler jest bezpośrednio podłączony do czujnika lub elementu wykonawczego, podczas gdy systemy muszą spełniać rygorystyczne wymagania w czasie rzeczywistym, zachowując jednocześnie niskie opóźnienia; planowanie zasobów opiera się na czasie. W stosie tym znajdują się systemy, które zapewniają najwyższy poziom bezpieczeństwa pojazdów. Przykładem jest klasyczna domena Automotive Open Systems Architecture (AUTOSAR).
  • Stos sterowany czasem i zdarzeniami. Ten hybrydowy stos łączy w sobie wysokowydajne aplikacje zabezpieczające z obsługą na przykład ADAS i HAD. Aplikacje i urządzenia peryferyjne są oddzielone systemem operacyjnym, a aplikacje mają harmonogram. W aplikacji planowanie zasobów może opierać się na czasie lub priorytecie. Środowisko operacyjne zapewnia, że ​​aplikacje o znaczeniu krytycznym działają w izolowanych kontenerach, wyraźnie oddzielając te aplikacje od innych aplikacji w pojeździe. Dobrym przykładem jest adaptacyjny AUTOSAR.
  • Stos sterowany zdarzeniami. Ten stos skupia się na systemie informacyjno-rozrywkowym, który nie jest krytyczny dla bezpieczeństwa. Aplikacje są wyraźnie oddzielone od urządzeń peryferyjnych, a zasoby są planowane przy użyciu planowania optymalnego lub opartego na zdarzeniach. Stos zawiera widoczne i często używane funkcje: Android, Automotive Grade Linux, GENIVI i QNX. Funkcje te umożliwiają użytkownikowi interakcję z pojazdem.
  • Stos chmur. Ostatni stos obejmuje dostęp do danych i koordynuje go oraz funkcje pojazdu zewnętrznie. Stos ten odpowiada za komunikację, a także weryfikację bezpieczeństwa aplikacji (uwierzytelnienie) oraz ustanawia specyficzny interfejs motoryzacyjny, w tym zdalną diagnostykę.

Dostawcy branży motoryzacyjnej i producenci technologii zaczęli już specjalizować się w niektórych z tych stosów. Doskonałym przykładem jest system informacyjno-rozrywkowy (stos sterowany zdarzeniami), w którym firmy rozwijają możliwości komunikacji - 3D i zaawansowaną nawigację. Drugim przykładem jest sztuczna inteligencja i czujniki do zastosowań o wysokiej wydajności, w przypadku których dostawcy współpracują z kluczowymi producentami samochodów w celu opracowania platform obliczeniowych.

W dziedzinie sterowanej czasem AUTOSAR i JASPAR wspierają standaryzację tych stosów.

Oprogramowanie pośredniczące wyodrębni aplikacje ze sprzętu

W miarę ewoluowania pojazdów w kierunku mobilnych platform obliczeniowych oprogramowanie pośrednie umożliwi rekonfigurację pojazdów oraz instalację i aktualizację ich oprogramowania. Obecnie oprogramowanie pośredniczące w każdym ECU ułatwia komunikację pomiędzy urządzeniami. W pojazdach nowej generacji będzie łączyć kontroler domeny z funkcjami dostępowymi. Wykorzystując sprzęt ECU w samochodzie, oprogramowanie pośrednie zapewni abstrakcję, wirtualizację, SOA i przetwarzanie rozproszone.

Istnieją już dowody na to, że przemysł motoryzacyjny przechodzi na bardziej elastyczne architektury, w tym oprogramowanie pośrednie. Na przykład platforma adaptacyjna AUTOSAR to dynamiczny system, który obejmuje oprogramowanie pośredniczące, kompleksową obsługę systemu operacyjnego i nowoczesne wielordzeniowe mikroprocesory. Jednakże dostępne obecnie rozwiązania ograniczają się do tylko jednego ECU.

W średnim terminie liczba czujników pokładowych znacząco wzrośnie

W ciągu najbliższych dwóch–trzech generacji pojazdów producenci samochodów będą instalować czujniki o podobnych funkcjach, aby zapewnić wystarczające rezerwy związane z bezpieczeństwem.

McKinsey: przemyślenie na nowo architektury oprogramowania i elektroniki w motoryzacji

W dłuższej perspektywie przemysł motoryzacyjny będzie opracowywał dedykowane rozwiązania z zakresu czujników, aby zmniejszyć ich liczbę i koszt. Uważamy, że połączenie radaru i kamery może być najpopularniejszym rozwiązaniem w ciągu najbliższych pięciu–4 lat. W miarę ciągłego wzrostu możliwości pojazdów autonomicznych konieczne będzie wprowadzenie lidarów. Zapewnią redundancję zarówno w zakresie analizy obiektów, jak i w zakresie lokalizacji. Na przykład konfiguracja jazdy autonomicznej SAE International L360 (wysoka automatyzacja) początkowo prawdopodobnie wymagałaby czterech do pięciu czujników lidarowych, w tym czujników zamontowanych z tyłu, umożliwiających nawigację miejską i widoczność w zakresie niemal XNUMX stopni.

Trudno w dłuższej perspektywie cokolwiek powiedzieć na temat liczby czujników w pojazdach. Ich liczba albo wzrośnie, zmniejszy się, albo pozostanie taka sama. Wszystko zależy od przepisów, dojrzałości technicznej rozwiązań i możliwości wykorzystania wielu czujników w różnych przypadkach. Wymogi prawne mogłyby na przykład zwiększyć monitorowanie kierowcy, co doprowadziłoby do umieszczenia większej liczby czujników w pojeździe. Możemy spodziewać się większej liczby czujników elektroniki użytkowej stosowanych we wnętrzu pojazdów. Czujniki ruchu, monitorowanie stanu zdrowia (tętno i senność), rozpoznawanie twarzy i tęczówki to tylko niektóre z możliwych zastosowań. Aby jednak zwiększyć liczbę czujników lub nawet utrzymać wszystko na tym samym poziomie, wymagana będzie szersza gama materiałów, nie tylko w samych czujnikach, ale także w sieci pojazdu. Dlatego znacznie bardziej opłacalne jest zmniejszenie liczby czujników. Wraz z pojawieniem się pojazdów wysoce zautomatyzowanych lub w pełni zautomatyzowanych zaawansowane algorytmy i uczenie maszynowe mogą poprawić wydajność i niezawodność czujników. Dzięki wydajniejszym i wydajniejszym technologiom czujników niepotrzebne czujniki mogą nie być już potrzebne. Stosowane dziś czujniki mogą stać się przestarzałe – pojawią się czujniki bardziej funkcjonalne (np. zamiast asystenta parkowania opartego na kamerze czy lidara mogą pojawić się czujniki ultradźwiękowe).

Czujniki staną się inteligentniejsze

Architektury systemów będą wymagały inteligentnych i zintegrowanych czujników do zarządzania ogromnymi ilościami danych wymaganych do wysoce zautomatyzowanej jazdy. Funkcje wysokiego poziomu, takie jak łączenie czujników i pozycjonowanie XNUMXD, będą działać na scentralizowanych platformach obliczeniowych. Pętle przetwarzania wstępnego, filtrowania i szybkiego reagowania będą prawdopodobnie zlokalizowane na krawędzi lub wykonywane w samym czujniku. Według szacunków ilość danych, które samochód autonomiczny będzie generował co godzinę, wynosi cztery terabajty. Dlatego sztuczna inteligencja przejdzie z ECU do czujników, aby przeprowadzić podstawowe przetwarzanie wstępne. Wymaga małych opóźnień i niskiej wydajności obliczeniowej, zwłaszcza gdy porówna się koszt przetwarzania danych w czujnikach z kosztem przesyłania dużych ilości danych w pojeździe. Nadmiarowość decyzji drogowych w HAD będzie jednak wymagać konwergencji w celu scentralizowanego przetwarzania danych. Najprawdopodobniej obliczenia te zostaną obliczone na podstawie wstępnie przetworzonych danych. Inteligentne czujniki będą monitorować swoje własne funkcje, a redundancja czujników poprawi niezawodność, dostępność, a tym samym bezpieczeństwo sieci czujników. Aby zapewnić prawidłowe działanie czujnika w każdych warunkach, wymagane będzie zastosowanie środków do czyszczenia czujnika, takich jak odladzanie oraz usuwanie kurzu i brudu.

Wymagane będzie pełne zasilanie i redundantne sieci danych

Kluczowe i krytyczne dla bezpieczeństwa aplikacje, które wymagają wysokiej niezawodności, będą wykorzystywać w pełni redundantne cykle do wszystkiego, co jest potrzebne do bezpiecznego manewrowania (przesyłanie danych, zasilanie). Wprowadzenie technologii pojazdów elektrycznych, komputery centralne i energochłonne rozproszone sieci komputerowe będą wymagały nowych, nadmiarowych sieci zarządzania energią. Systemy odporne na awarie obsługujące sterowanie przewodowe i inne funkcje HAD będą wymagały opracowania systemów redundantnych. Znacząco poprawi to architekturę nowoczesnych, odpornych na awarie wdrożeń monitorowania.

„Automotive Ethernet” stanie się kręgosłupem samochodu

Dzisiejsze sieci samochodowe nie są wystarczające, aby zaspokoić potrzeby przyszłego transportu. Zwiększone szybkości transmisji danych, wymagania dotyczące redundancji dla HAD, potrzeba bezpieczeństwa i ochrony w połączonych środowiskach oraz potrzeba stosowania międzybranżowych standardowych protokołów prawdopodobnie doprowadzą do pojawienia się samochodowego Ethernetu. Stanie się kluczowym czynnikiem, szczególnie w przypadku redundantnej centralnej magistrali danych. Aby zapewnić niezawodną komunikację między domenami i sprostać wymaganiom w czasie rzeczywistym, wymagane będą rozwiązania Ethernet. Będzie to możliwe dzięki dodaniu rozszerzeń Ethernet, takich jak mostkowanie audio-wideo (AVB) i sieci wrażliwe na czas (TSN). Przedstawiciele branży i OPEN Alliance wspierają przyjęcie technologii Ethernet. Wielu producentów samochodów zrobiło już ten duży krok.

Tradycyjne sieci, takie jak lokalne sieci wzajemne i sieci sterowników, będą nadal wykorzystywane w pojeździe, ale tylko w przypadku zamkniętych sieci niższego poziomu, takich jak czujniki. Technologie takie jak FlexRay i MOST zostaną prawdopodobnie zastąpione przez samochodowy Ethernet i jego rozszerzenia AVB i TSN.

Oczekujemy, że w przyszłości branża motoryzacyjna będzie wykorzystywać także inne technologie Ethernet – HDBP (produkty o dużej przepustowości) i technologie 10-Gigabitowe.

Producenci OEM zawsze będą mieli ścisłą kontrolę nad łącznością danych, aby zapewnić bezpieczeństwo funkcjonalne i HAD, ale otworzą interfejsy, aby umożliwić stronom trzecim dostęp do danych

Centralne bramy komunikacyjne, które przesyłają i odbierają dane krytyczne dla bezpieczeństwa, zawsze będą łączyć się bezpośrednio z zapleczem OEM. Dostęp do danych będzie możliwy dla osób trzecich, jeżeli nie zabrania tego regulamin. Infotainment jest „dodatkiem” do pojazdu. W tym obszarze powstające otwarte interfejsy umożliwią dostawcom treści i aplikacjom wdrażanie swoich produktów, podczas gdy producenci OEM będą przestrzegać standardów najlepiej, jak potrafią.

Dzisiejszy pokładowy port diagnostyczny zostanie zastąpiony połączonymi rozwiązaniami telematycznymi. Dostęp serwisowy do sieci pojazdu nie będzie już wymagany, ale będzie mógł przepływać przez backendy OEM. Producenci OEM zapewnią porty danych z tyłu pojazdu do określonych zastosowań (śledzenie skradzionego pojazdu lub ubezpieczenie osobiste). Jednak urządzenia z rynku wtórnego będą miały coraz mniejszy dostęp do wewnętrznych sieci danych.

Duzi operatorzy flot będą odgrywać większą rolę w doświadczeniach użytkowników i tworzyć wartość dla klientów końcowych. Będą mogli oferować różne pojazdy do różnych celów w ramach tego samego abonamentu (na przykład do codziennych dojazdów do pracy lub weekendowych wypadów). Będą musieli korzystać z wielu backendów OEM i konsolidować dane w swoich flotach. Duże bazy danych umożliwią operatorom flot zarabianie na skonsolidowanych danych i analizach niedostępnych na poziomie OEM.

Samochody będą korzystać z usług w chmurze, aby łączyć informacje pokładowe z danymi zewnętrznymi

Dane „niewrażliwe” (czyli dane, które nie są powiązane z tożsamością lub bezpieczeństwem) będą coraz częściej przetwarzane w chmurze w celu uzyskania dodatkowych informacji. Dostępność tych danych poza producentem OEM będzie zależeć od przyszłych przepisów i regulacji. W miarę wzrostu wolumenów bez analizy danych nie będzie to możliwe. Analityka jest potrzebna do przetwarzania informacji i wydobywania ważnych danych. Jesteśmy zaangażowani w jazdę autonomiczną i inne innowacje cyfrowe. Efektywne wykorzystanie danych będzie zależeć od wymiany danych pomiędzy wieloma uczestnikami rynku. Na razie nie wiadomo, kto i w jaki sposób to zrobi. Jednak główni dostawcy branży motoryzacyjnej i firmy technologiczne już budują zintegrowane platformy motoryzacyjne, które poradzą sobie z tym nowym bogactwem danych.

W samochodach, które będą wspierać komunikację dwukierunkową, pojawią się komponenty, które można ulepszać

Pokładowe systemy testowe umożliwią pojazdom automatyczne sprawdzanie dostępności aktualizacji. Będziemy mogli zarządzać cyklem życia pojazdu i jego funkcjami. Wszystkie ECU będą wysyłać i odbierać dane z czujników i siłowników, pobierając dane. Dane te posłużą do opracowania innowacji. Przykładem może być budowanie trasy w oparciu o parametry pojazdu.

Możliwość aktualizacji OTA jest koniecznością dla HAD. Dzięki tym technologiom będziemy mieli nowe funkcje, cyberbezpieczeństwo oraz szybsze wdrażanie funkcji i oprogramowania. W rzeczywistości możliwość aktualizacji OTA jest siłą napędową wielu ważnych zmian opisanych powyżej. Dodatkowo funkcja ta wymaga również kompleksowego rozwiązania bezpieczeństwa na wszystkich poziomach stosu – zarówno na zewnątrz pojazdu, jak i wewnątrz ECU. Rozwiązanie to nie zostało jeszcze opracowane. Ciekawie będzie zobaczyć, kto i jak to zrobi.

Czy aktualizacje samochodu będzie można instalować jak na smartfonie? Branża musi przezwyciężyć ograniczenia w umowach z dostawcami, wymagania regulacyjne oraz obawy dotyczące bezpieczeństwa i prywatności. Wielu producentów samochodów ogłosiło plany wprowadzenia usług OTA, w tym bezprzewodowych aktualizacji swoich pojazdów.

Producenci OEM będą standaryzować swoje floty na platformach OTA, ściśle współpracując z dostawcami technologii w tym obszarze. Łączność w pojazdach i platformy OTA wkrótce staną się bardzo ważne. Producenci OEM to rozumieją i chcą zyskać więcej własności w tym segmencie rynku.

Pojazdy otrzymają aktualizacje oprogramowania, funkcji i zabezpieczeń przez cały okres użytkowania. Organy regulacyjne prawdopodobnie zapewnią konserwację oprogramowania w celu zapewnienia integralności projektu pojazdu. Konieczność aktualizacji i konserwacji oprogramowania doprowadzi do powstania nowych modeli biznesowych w zakresie konserwacji i eksploatacji pojazdów.

Ocena przyszłego wpływu oprogramowania samochodowego i architektury elektronicznej

Trendy wpływające na przemysł motoryzacyjny powodują znaczną niepewność związaną ze sprzętem. Przyszłość oprogramowania i architektury elektronicznej wygląda jednak obiecująco. Przed branżą otwarte są wszystkie możliwości: producenci samochodów mogliby tworzyć stowarzyszenia branżowe w celu ujednolicenia architektury pojazdów, cyfrowi giganci mogliby wdrażać pokładowe platformy chmurowe, podmioty zajmujące się mobilnością mogłyby produkować własne pojazdy lub opracowywać zestawy pojazdów z otwartym kodem źródłowym i oprogramowaniem funkcyjnym, producenci samochodów mogliby wprowadzić coraz bardziej wyrafinowane samochody autonomiczne z dostępem do Internetu.

Produkty wkrótce nie będą już skupiać się na sprzęcie. Będą zorientowani na oprogramowanie. To przejście będzie trudne dla firm motoryzacyjnych przyzwyczajonych do produkcji tradycyjnych samochodów. Jednak biorąc pod uwagę opisane trendy i zmiany, nawet małe firmy nie będą miały wyboru. Będą musieli się przygotować.

Widzimy kilka głównych kroków strategicznych:

  • Oddzielne cykle rozwoju pojazdów i funkcje pojazdu. Producenci OEM i dostawcy poziomu XNUMX muszą zdecydować, w jaki sposób będą opracowywać, oferować i wdrażać funkcje. Muszą być niezależne od cykli rozwoju pojazdów, zarówno z technicznego, jak i organizacyjnego punktu widzenia. Biorąc pod uwagę obecne cykle rozwoju pojazdów, firmy muszą znaleźć sposób na zarządzanie innowacjami w oprogramowaniu. Ponadto powinni rozważyć opcje modernizacji i modernizacji (takich jak jednostki obliczeniowe) dla istniejących flot.
  • Zdefiniuj docelową wartość dodaną w zakresie rozwoju oprogramowania i elektroniki. Producenci OEM muszą określić wyróżniające cechy, dla których mogą ustanowić punkty odniesienia. Ponadto niezwykle istotne jest jasne określenie docelowej wartości dodanej w zakresie własnego rozwoju oprogramowania i elektroniki. Powinieneś także zidentyfikować obszary, w których produkty będą potrzebne oraz tematy, które należy omawiać wyłącznie z dostawcą lub partnerem.
  • Ustaw wyraźną cenę oprogramowania. Aby oddzielić oprogramowanie od sprzętu, producenci OEM muszą ponownie przemyśleć wewnętrzne procesy i mechanizmy, aby bezpośrednio kupować oprogramowanie. Oprócz tradycyjnego dostosowywania ważne jest również przeanalizowanie, w jaki sposób zwinne podejście do tworzenia oprogramowania można powiązać z procesem zaopatrzenia. W tym miejscu dostawcy (pierwszy, drugi i trzeci) również odgrywają kluczową rolę, ponieważ muszą zapewnić wyraźną wartość biznesową swoim ofertom oprogramowania i systemów, aby móc zdobywać większą część przychodów.
  • Opracuj konkretny schemat organizacyjny dla nowej architektury elektroniki (w tym backend). Branża samochodowa musi zmienić procesy wewnętrzne, aby dostarczać i sprzedawać zaawansowaną elektronikę i oprogramowanie. Muszą także wziąć pod uwagę różne ustawienia organizacyjne w zakresie zagadnień elektronicznych związanych z pojazdami. Zasadniczo nowa architektura „warstwowa” wymaga potencjalnego zakłócenia obecnej konfiguracji „pionowej” i wprowadzenia nowych „poziomych” jednostek organizacyjnych. Ponadto istnieje potrzeba poszerzania możliwości i umiejętności programistów i elektroników w zespołach.
  • Opracuj model biznesowy dla poszczególnych komponentów pojazdu jako produktu (szczególnie dla dostawców). Niezwykle istotne jest przeanalizowanie, które funkcje dodają rzeczywistą wartość do przyszłej architektury i w związku z tym można na nich zarobić. Pomoże Ci to zachować konkurencyjność i zdobyć znaczną część wartości w branży elektroniki samochodowej. Następnie konieczne będzie znalezienie nowych modeli biznesowych sprzedaży oprogramowania i systemów elektronicznych, niezależnie od tego, czy będzie to produkt, usługa, czy coś zupełnie nowego.

Rozpoczęcie nowej ery oprogramowania i elektroniki samochodowej zasadniczo zmienia wszystko w modelach biznesowych, potrzebach klientów i charakterze konkurencji. Wierzymy, że uda się na tym sporo zarobić. Aby jednak wykorzystać nadchodzące zmiany, wszyscy w branży muszą ponownie przemyśleć swoje podejście do produkcji samochodów i mądrze ustalać (lub zmieniać) swoją ofertę.

Artykuł ten powstał we współpracy z Global Semiconductor Alliance.

Źródło: www.habr.com

Dodaj komentarz