Auta z przyszłości są już dziś - tylko kod musi nadążyć. Co trzeba wiedzieć o Software Defined Vehicles?

Gotowi? Zaczynamy! Witamy wszystkich słuchaczy w kolejnym naszym podcaście z serii TechChatter. Będziemy rozmawiać na temat Software Defined Vehicles. Ja nazywam się Paweł Kmiecik i będę miał przyjemność poprowadzić rozmowę razem z Łukaszem Okoniem. Dzień dobry Łukaszu. Cześć Pawle. Zanim jeszcze przejdziemy do meritum, może jeszcze krótko się przedstawimy, a więc ja jestem Software Test Engineer, pracuję w branży automotive 5 lat. Głównie właśnie w dziale testów. Zajmuję się testowaniem oprogramowania, tworzeniem e-symulacji i środowisk testowych. I posiadam też tytuł inżyniera z automatyki i robotyki. Czy Łukasz możesz też coś o sobie powiedzieć? Jestem też inżynierem teleinformatyki. Pracuję w branży embedded już od 12 lat. Natomiast z branży automotive spotkałem się 5 lat temu.

Pracuję jako architekt oprogramowania. Możemy przejść już do meritum. Łukasz, co to są te Software Defined Vehicles? Czy możesz nam przedstawić pokrótce temat? Temat to tak naprawdę podejście do sposobu projektowania samochodów, który kilka lat temu został zaprezentowany. Software Defined Vehicles to nic innego jak samochody, które mają być zdefiniowane poprzez software. Ogólnie rzecz biorąc koncepcja mówi o tym, że samochód Może poprzez zmianę oprogramowania, jego aktualizację, nawet w trakcie życia takiego samochodu, zostać zaktualizowane, dodane nowe feature, nowe funkcje do naszych samochodów. Natomiast jeżeli chodzi o platformę hardware'ową, czyli to na czym to oprogramowanie jest wykonywane, ona jest standardowe.

Możemy sobie ją w tańszy sposób przetestować, powiedzmy przez miesiąc, dwa, trzy. Czy na pewno jest to nam potrzebne i czy na pewno chcielibyśmy za to zapłacić tyle pieniędzy, ile ta funkcja kosztuje. Więc z punktu widzenia użytkownika jest to dosyć ciekawe rozwiązanie. Natomiast jeżeli chodzi o producentów samochodów, tutaj jest to również optymalizacja kosztów. Jeżeli mamy duże koncerny motoryzacyjne, Które produkują i projektują nie tylko jeden model, albo nawet niejedną markę samochodów. Pozwala to na optymalizację kosztów, ponieważ taka platforma sprzętowa będzie aplikowalna do wielu samochodów i wielu modeli. Może być nawet taka sama. Natomiast poprzez software zmieniamy jego konfigurację, która jest specyficzna dla danej marki, dla danego modelu.

Wszystko zależy tak naprawdę od modelu biznesowego jaki producent dla danego modelu albo nawet dla całej marki będzie chciał zaimplementować. Możliwości przy tym podejściu Software Defined Vehicles dla branży automotive umożliwiają praktycznie wykorzystanie jakiejkolwiek strategii. W zależności od decyzji biznesowych może to być sytuacja taka, że zadane funkcje płacimy tylko w modelu subskrypcyjnym powiedzmy. Nie wiem, 20 złotych, 100 złotych miesięcznie, tak? I tylko w ten sposób są one dostępne.

Mogą być rozwiązane w inny sposób, że dostępne są tylko w momencie, kiedy płacimy pełną kwotę za daną funkcję i nie potrzebujemy jechać do serwisu, bo ona nawet zdalnie może być uruchomiona poprzez aktualizację takiego oprogramowania albo nawet niecałego oprogramowania albo lego konfiguracji, tak? Więc jest dużo różnych możliwości. Dla mnie taką najciekawszą opcją, która mogłaby zostać zaaplikowana, to taka moja prywatna opinia, że możemy sobie wykupić dwojako. Jeżeli wiemy, że z tego samochodu chcemy korzystać w dłuższej perspektywie i wiemy, że takie funkcje Co trzeba wiedzieć o Software Defined Vehicles?.

Albo też możemy rozpatrywać to w krótszym czasie, np. jeżeli będziemy wiedzieć, że w tym miesiącu jeździmy bardzo dużo samochodem, możemy wykupić sobie subskrypcję np. na autonomiczną jazdę, a w następnym miesiącu, jeżeli wiemy, że nie będziemy jeździć w tym stylu, to możemy tej subskrypcji nie odnawiać. Jeżeli chodzi o technologie, to są producenci samochodów, którzy już wdrożyli Software Defined Vehicles, ten sposób tworzenia, oprogramowania dla samochodów i z powodzeniem udaje im się zyskiwać nowych użytkowników na naszym rynku. Aczkolwiek też napotykają się z pewnymi problemami, ponieważ to nie tylko plusy, ale również wyzwania dla producentów i myślę, że dla użytkowników czasem również. Natomiast wracając do swojej poprzedniej wypowiedzi, że możemy też w krótszym okresie czasu rozpatrywać taką subskrypcję.

Natomiast oprogramowanie musi być na tyle przygotowane tak, żeby można było je w łatwy sposób skonfigurować pod dany model. To jest clue całego podejścia Software Defined Vehicles. Branża automotive musi przejść tą transformację, ponieważ historycznie tradycyjne podejście do tworzenia oprogramowania w automotive nie miało takiej konieczności tworzenia takiego podejścia, z tego względu, że samochody bardzo różniły się od siebie. Każdy nowy model samochodu to był nowy projekt. Ten samochód miał różne elementy wykonawcze, inne wycieraczki, inne mają składane lusterka, inne nie. I w zależności od tego, co ten samochód posiadał, To takie elementy się aplikowało bądź nie do tego samochodu.

Teraz podejście jest trochę inne. Mamy duże koncerny, które skupiają wiele modeli, wiele marek. Takie podejście do tworzenia samochodów jest bardzo nieefektywne. Dlatego właśnie Software Defined Vehicles. Wszystko, co właśnie teraz przedstawiłeś zabrzmiało tak, jakbyśmy chcieli stworzyć jeden uniwersalny hardware, czyli tzw. komputer pokładowy. Co się dokładnie zmieniło, że w tym momencie jest to możliwe i na czym polega ta cała transformacja? Czy ta architektura musiała być tworzona od nowa, czy po prostu została ulepszona i dzięki temu możemy właśnie korzystać z takich opcji jak Software Defined Vehicles?

Gdy mieliśmy jedno ECU dla jednej funkcji, tam tych zależności nie było. Nie musieliśmy myśleć o tym, że oprogramowanie musi być skalowalne, reuszywalne itd., że musimy unikać zależności, że ta architektura musi być spójna, bo to nie miało znaczenia. Teraz ma. No i ta transformacja to jest takie największe wyzwanie dla producentów samochodów. Nie tylko ze względu na samych producentów, ale dla zespołów, które pracowały technicznie w poprzednich generacjach tworzenia samochodów. Inżynierowie niekoniecznie musieli się skupiać na takich aspektach. Teraz muszą, czyli muszą się tego douczyć. Jest wiele wyzwań i technicznych i administracyjnych, które takie firmy muszą przejść, żeby móc osiągnąć właśnie tą optymalizację kosztów i uzyskać funkcje, które zapewnią nam podejście Software Defined Vehicles.

To jest kolejne wyzwanie również dla inżynierów oprogramowania, dla software developerów, ponieważ tego elementu jeszcze kilka lat temu w samochodach nie było. Nie było infotainmentu rozbudowanego, gdzie mieliśmy wiele ekranów, kupę kamer w samochodzie, że mogliśmy sobie podglądać na żywo obraz, że te kamery śledziły nasze zachowanie na drodze, czy nie przysypiamy. To powoduje, że wzrost zapotrzebowania na moc obliczeniową rośnie diametralnie. Jeżeli takie funkcje są implementowane w samochodzie. Co za tym idzie? Tworzenie oprogramowania tzw. klasycznej platformy, czyli tworzenia oprogramowania tylko i wyłącznie na mikrokontrolery.

Tutaj właśnie wspomniałeś o mocy obliczeniowej. Ja chciałem jeszcze tylko napomknąć, że w samochodach Software Defined Vehicles też duży nacisk będzie kładzione na integrację z chmurą, a więc niektóre obliczenia będą wykonywane w aucie, te bardziej krytyczne. Szczególnie ze względów bezpieczeństwa oraz te, które muszą wykonać się natychmiast. Szczególnie tutaj mam na myśli jakiś moduł hamowania, czy to na przykład poduszek powietrznych. Natomiast dużo danych będzie zbieranych i wysyłanych do chmury, gdzie tam też będą wykonywane jeszcze bardziej zaawansowane obliczenia. Tutaj mam na myśli jakieś, na przykład analiza Big Data z większej ilości samochodów, co w przyszłości też będzie mogło wpływać na... W tym momencie poprzez integrację z chmurą te dane będą mogły być wysłane i każdy inny pojazd pobierze sobie takie dane z chmury i wyświetli nam informację o tym, że za 100 metrów jest oblodzona droga, ponieważ już jakieś auto tam przejechało.

Często wymaga się, żeby to wszystko, co zostało już wcześniej odpowiednio przygotowane, które było aplikowane przez kilkadziesiąt lat w samochodach, te rozwiązania muszą zostać pogrzebane i musimy podejść do tych tematów na nowo, żeby móc zaaplikować właśnie takie, a nie inne podejście do tego software'u, który w samochodach ma być zaimplementowany. Cały czas branża musi być up-to-date, że tak to powiem, czyli jakby na topie i obserwować co się dzieje, jakie nowe technologie wchodzą i są integrowane oraz co nam umożliwiają. Nieodłączną częścią Software Defined Vehicles jest też AI i musimy być na tą... Też transformacje gotowi oraz wiedzieć jakie zagrożenia idą przez integrację właśnie sztuczej inteligencji do samochodów.

Jest to też ciekawy temat i niesie za sobą bardzo wiele różnych zawiłości, ponieważ umożliwia nam bardzo dużo nowych funkcjonalności np. tutaj jak wcześniej też wspomnieliśmy o analizowaniu Big Data i zbieraniu danych z drogi oraz sensorów z kamer, uploadowanie ich do chmury i następnie wyciąganie bardzo ciekawych wniosków, które Co trzeba wiedzieć o Software Defined Vehicles?. Names mentioned Taką koncepcję, że samochody będą troszeczkę takimi jeżdżącymi obserwatorami i będą nam mówić o stanie kondycji drogi w danym mieście.

Często jest to bardzo ciężkie i czasami nawet niewykonalne, biorąc pod uwagę złożoność przypadków np. takiej autonomicznej jazdy. Aczkolwiek tutaj właśnie w przetestowaniu Artificial Intelligence dochodzi nam jeszcze taki czynnik, że cały wektor jakby testowy, jeżeli dobrze byśmy przewidzieli i przetestowali nawet wszystkie możliwe kombinacje, to i tak możemy otrzymać inny wynik, który taka sieć neuronowa nam zwróci. To wynika bezpośrednio z braku deterministyczności takiej sieci, a więc ten wynik może być często różny Na podstawie tego, jak ta sieć zadziała i często też biorąc pod uwagę liczbę tych wszystkich przypadków testowych, które możemy wygenerować, duży nacisk się kładzie na symulację, a więc tutaj już nie badamy tego na realnym samochodzie, znaczy finalnie badamy, to jest nasz cel, ale dużo właśnie przypadków testowych możemy zasymulować sobie, zanim taki software zostanie wgrany na prawdziwy hardware.

Zobaczmy zachowanie tego naszego software'u. Dlatego dużą część kładzie się na technologię SIL , gdzie mamy sam software napisany, bez hardware'u i testujemy wszystkie możliwe kombinacje, jakie są tylko. Plusem też tego rodzaju testowania jest to, że nie ogranicza nas sprzęt, a więc możemy głównie tylko liczba komputerów albo liczba licencji na dane oprogramowanie. I możemy przez noc zasymulować ileś tysięcy przypadków testowych na kilkunastu komputerach i już będziemy mieli większe pokrycie. Aczkolwiek często jest to nie do przewidzenia. Dobrym przykładem jest autonomous driving i roboty drogowe. A więc ja jako tester mogę zasymulować rozmieszczenie pachołków na drodze, symulujących jakieś tam prace drogowe.

Jeśli tutaj jesteśmy już właśnie przy temacie zbierania danych i wymiany z chmurą, też ciekawym pojęciem, o którym ostatnio się dowiedziałem, jest Mobility as a Service, a więc jest to takie pojęcie, które mówi nam, że jeżeli my będziemy chcieli się przetransportować z punktu A do punktu B, to nasz samochód, jeżeli już będzie bardziej autonomiczny, Co trzeba wiedzieć o Software Defined Vehicles?.

I ono wyjeżdża do tramwaju, a potem z niego wyjeżdża i my o tym nie wiemy, że jesteśmy przetransportowani jakimś innym środkiem transportu. To jest ciekawa wizja i to też jakby umożliwia to po prostu właśnie to zbieranie danych, wysyłanie do chmury, integracja wielu systemów. To też jest taka pieśń przyszłości, taka futurystyczna bym powiedział nawet. Jak dużo dzisiejszych tematów tutaj, ale mówimy też o przeszłości i staramy się to zrobić. Branża idzie w tą stronę. Zobaczymy, w jakim tempie to pójdzie. Nie wiem, co Łukasz o tym sądzisz? Kwestia jest taka, że software pozwala nam na zmiany. Hardware nam nie pozwala na zmiany, tak? W trakcie nawet cyklu takich urządzeń. Im więcej mamy software'u, który zastępuje nam hardware, sprowadza się to do tego, że nawet podczas cyklu życia urządzeń, pojazdów, czegokolwiek możemy dodać, zmienić, usunąć pewne funkcje, poprawić je.

Kwestia też jest taka, że żeby zrozumieć inżynierię oprogramowania, to trzeba parę projektów zepsuć. Taka jest prawda. To ja mogę powiedzieć z mojego własnego doświadczenia. Już 12 lat pracuję zawodowo. Wcześniej trochę programowałem na studiach. Na studiach miałem inżynierię oprogramowania. Dobrze wytłumaczono. To był przedmiot, którego wysłuchałem, nauczyłem się, zdałem i potem zapomniałem. Potem dołączyłem do pewnej takiej małej firmy, w której pracowałem nad systemami embedded jako Software Developer. Czasem byłem odpowiedzialny nawet za całe projekty, ale to były bardzo małe projekty. W trakcie trwania tego procesu deweloperskiego zmieniały się wymagania co do tego projektu, nowe funkcje klient sobie do nich życzył.

W pewnym momencie dodanie nowej funkcji było tak trudne, że wymagało przerobienia połowy rzeczy, które przez rok wykonywałem. Czyli dodanie jednej funkcji trwało kilka miesięcy mojej pracy. I to był jeden projekt, drugi projekt, trzeci projekt. W końcu sobie uświadomiłem, no przecież tak nie może być. Tak nie może być, że dodanie czegoś po prostu tyle kosztuje. Przecież to ma być software. Software z angielskiego, coś miękkiego, soft. Czyli giętkie, które można naciągnąć w łatwy sposób w jedną i w drugą stronę. To spowodowało, że wróciłem do tego tematu, który był na studiach, do tej architektury oprogramowania, do inżynierii oprogramowania. Zacząłem się kształcić w tym kierunku, czytałem kilka książek, zająłem się nowymi projektami, właśnie też również prywatnymi i znalazłem sposoby na to, żeby te akcje, które chciałem wykonać i które były potrzebne dla moich poprzednich projektów, były możliwe do zrealizowania.

Współpracy między całymi zespołami i długofalowe wyciąganie wniosków, tak jak Łukasz powiedział, z każdego projektu i z każdej porażki. Paweł, co byś jeszcze dodał na zakończenie tego naszego podcastu? Bardzo dużo tematów poruszyliśmy naokoło też Software Defined Vehicles, aczkolwiek trzeba pamiętać, że każdy z tych tematów jest integrowany z tym tematem, a więc jakby to jest wszystko zgrywa się w jedną całość, a dokładnie w innowacyjny samochód, który udostępni nam nowe funkcje i który będzie bardziej Co trzeba wiedzieć o Software Defined Vehicles?. Names mentioned.