Auta z przyszłości są już dziś – tylko kod musi nadążyć.

Łukasz Okoń
Ta branża się nam dalej rozrasta. Jest duże zapotrzebowanie na inżynierów, którzy są dobrymi specjalistami, których wcześniej w branży automotive nie było, a teraz mają szansę, żeby dołączyć, ponieważ te umiejętności wykorzystali w innych branżach. Gdzie tego typu transformacje skalowalności, reużywalności inżynierii i oprogramowania już zaszła kilkanaście lat temu.
 
Intro
Słuchasz trzeciego sezonu podcastu TechChatter – audycji Capgemini Polska, w której zanurzymy się w świecie technologii. Posłuchaj rozmów naszych ekspertek i ekspertów, odkryj projekty realizowane w Polsce i zobacz, jak innowacje, które współtworzymy, kształtują naszą przyszłość. Przekonajmy się, że praca w sektorze IT może być naprawdę pasjonująca. Gotowi? Zaczynamy!
 
Paweł Kmiecik
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.
 

Łukasz Okoń
Cześć Pawle.
 
Paweł Kmiecik
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 symulacji i środowisk testowych i posiadam też tytuł inżyniera z automatyki i robotyki. Czy Łukasz możesz też coś o sobie powiedzieć?
 

Łukasz Okoń
Jestem też inżynierem teleinformatyki, pracuję w branży embedded już od 12 lat, natomiast z branżą automotive spotkałem się 5 lat temu, pracuję jako architekt oprogramowania.
 
Paweł Kmiecik
Możemy przejść już do meritum. Łukasz, co to są te Software Defined Vehicles? Czy możesz nam przedstawić pokrótce temat?
 
Łukasz Okoń
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’y, nowe funkcje do naszych samochodów. Natomiast jeżeli chodzi o platformę hardware’ową, czyli to na czym to oprogramowanie jest wykonywane, ono jest standardowe. Daje nam to dużo plusów i z punktu widzenia użytkownika, a także z punktu widzenia producenta, dzięki czemu samochody mogą zostać tańsze, bardziej przyjazne i nawet jeżeli podczas zakupu takiego nowego samochodu nie zdecydujemy się na pewne funkcje, będziemy mieli możliwość uzupełnienia tych funkcji, zakupienia ich w późniejszym czasie, ponieważ cały sprzęt, który jest potrzebny dla tych funkcji będzie standardowo w samochodzie już zaimplementowany od samego początku. Jeżeli chodzi o użytkownika, to tutaj mamy taką możliwość, że dodamy sobie te funkcje w późniejszym czasie, możemy skorzystać z pewnych możliwości subskrypcyjnych. To znaczy zanim zdecydujemy się na zakup jakiegoś funkcji, która może kosztować kilka tysięcy złotych powiedzmy, 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. No więc też optymalizacja kosztów pod względem czasu wykonania samego oprogramowania. Nie musimy wiele czasu poświęcać na to, żeby każdy samochód został przygotowany w inny sposób, tylko mamy platformę, którą możemy konfigurować w zależności od potrzeb i specyfikacji, którą chcielibyśmy zachować w takim samochodzie. Ale ja myślę, że na ten temat trochę powiemy później, bo mamy tutaj jeszcze jedną rzecz, którą chciałem powiedzieć. Dlaczego? Dlaczego branża automotive kieruje się w taką stronę? I dlaczego teraz? Przechodzimy wielką transformację w branży automotive. Właśnie ze względu na to, że samochody stawały się coraz droższe przez dłuższy okres czasu. Na rynku powstały konkurencyjne firmy z różnych stron świata. No i branża automotive musi się do tych kosztów, niskich kosztów samochodów, bo tego oczekują klienci, dostosować. Więc szukają różnych możliwości na to, aby zoptymalizować koszty, a móc udostępniać użytkownikom jak najwyższą jakość i funkcjonalność, którą użytkownicy też oczekują.
 
Paweł Kmiecik
Wracając jeszcze do tych subskrypcji, ja to tak rozumiem, że to będzie i plus i minus, ponieważ ta subskrypcja może wpływać na cenę auta, ponieważ jeżeli nie będziemy chcieli mieć jakichś modułów aktywnych od samego początku, po prostu ich nie wykupimy, natomiast jeżeli będziemy je chcieli mieć w późniejszym czasie już po zakupieniu samochodu.
 
Łukasz Okoń
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, ale jego konfiguracji. 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ższym perspektywie i wiemy, że takie funkcje są dostępne, to zanim przystąpię do zakupu funkcji, która może kosztować kilka tysięcy złotych, wykupuję jej tylko miesięczną albo dwumiesięczną subskrypcję, zanim podejmę decyzję, że chcę ją wykupić dożywotnie, czyli takie dwojakie podejście, i subskrypcyjne, i dożywotnie.
 
Paweł Kmiecik
Albo też możemy rozpatrzać to w krótszym czasie, na przykład jeżeli będziemy wiedzieć, że w tym miesiącu jeździmy bardzo dużo samochodem, możemy wykupić sobie subskrypcję na przykład na autonomiczną jazdę, a w następnym miesiącu jeżeli wiemy, że nie będziemy jeździć w tym stylu, no to możemy tej subskrypcji nie odnawiać.
 
Łukasz Okoń
Jeżeli chodzi o technologię, 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 twojej poprzedniej wypowiedzi, że możemy też w krótszym okresie czasu to rozpatrywać, taką subskrypcję – może też dotyczyć chęci posiadania autonomicznej jazdy tylko i wyłącznie na jakąś długą podróż. Tak, że jedziemy do Chorwacji na wakacje i chcemy sobie pospać w samochodzie zamiast przez 12 godzin skupiać się za kierownicą na tej jeździe. No to odpalamy sobie takiego autopilota, wykupujemy subskrypcję dwutygodniową, miesięczną na tego autopilota, czy jak ta funkcja mogłaby się również nazywać. No i przesypiamy sobie te 12 godzin i budzimy się rano na plaży w jakimś pięknym miejscu i możemy od razu cieszyć się swoimi wakacjami, a nie, że musimy później odespać po południa, żeby móc jakoś żyć po tej drodze, którą żeśmy przebyli.
 
Paweł Kmiecik
Brzmi wspaniale, może dożyjemy jakichś tych czasów, mam nadzieję, że tak. Bardzo fajna wizja. Ja jeszcze chciałem zapytać mianowicie o to, że producenci samochodów, tak jak wspomniałeś, produkują jedną platformę, co umożliwia kompatybilność całego hardware’u. z różnymi samochodami, a więc zakładam też, że to wpłynie długofalowo na obniżenie ceny samochodu, albo i nie, właśnie i to jest moje pytanie, czy właśnie wyzwanie, które teraz musi jakby ta cała branża automotive przejść i zmierzyć się z tą transformacją jak wspomniałeś, czy długofalowo to wpłynie na obniżenie ceny samochodu, czy te wyzwania są na tyle ogromne, że będzie po prostu z tym duży problem?
 
Łukasz Okoń
Tutaj nie da się wprost odpowiedzieć na to pytanie, natomiast ja myślę, że długofalowo taka obniżka cen jest realna. Wszystko zależy od tego jak ta transformacja w danej firmie zostanie przeprowadzona. Tutaj mówimy o pewnej konfigurowalności. Tak, że mamy platformę, która zawiera sprzęt, który umożliwia nam wszystkie możliwe funkcje w samochodzie i chcemy tą platformę też używać w różnych innych modelach. Wymaga czasem zmiany tego oprogramowania. To nie jest tak, że to jest to samo oprogramowanie, które jest we wszystkich samochodach i czy to jest taki samochód, czy taki sam, one zmienią się tylko konfiguracją. Niestety nie wszystko w ten sposób da się zrobić, ale żeby to osiągnąć trzeba zmienić podejście do tworzenia takiego oprogramowania. Tutaj kwestią, która umożliwia nam osiągnięcie takiego celu jest zachowanie pewnych zasad tworzenia oprogramowania. Tworzenia oprogramowania, tworzenia jego architektury, skupienie się na tym, żeby ono było reużywalne oprogramowanie, a także żeby była możliwość jego skalowania. Bo nie widzimy sensu, żeby np. do jakiegoś małego samochodu pchać funkcje, które powinny być dostępne tylko w bardzo dużym samochodzie. Czyli jeżeli mamy mały samochód, i chcemy mieć funkcję autonomicznej jazdy, to nie potrzebuje mieć aż tyle czujników jak duży samochód, ponieważ jego powierzchnia, którą zajmuje na pasie jest mniejsza, więc nie musimy tych wszystkich kątów i każdego milimetra samochodu wokół monitorować. Więc ta specyfikacja techniczna samych elementów wykonawczych może być niższa w zależności od klasy takiego samochodu. 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, jedne 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 i takie podejście do tworzenia samochodów jest bardzo nieefektywne. Dlatego właśnie Software Defined Vehicles.
 
Paweł Kmiecik
Wszystko co właśnie teraz przedstawiłeś zabrzmiało tak jakbyśmy chcieli stworzyć jeden uniwersalny hardware, czy to tak zwany można powiedzieć komputer pokładowy. który będzie sterowany w zależności od modelu jaki chcemy oraz naszych zapotrzebowań w aucie na funkcjonalności, które będą dointegrowane przez producentów samochodów. I wspomniałem też o tym, że w poprzednich latach nie było to możliwe, więc moje pytanie brzmi, 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 Define Vehicles?
 
Łukasz Okoń
Standardowo samochody, czyli mówię o poprzedniej generacji, sprzed takiego podejścia dla pewnych elementów samochodu miały tak zwane własne ECU. ECU to tak naprawdę jest można powiedzieć taki minikomputer, który zarządza jakąś funkcją. Każda funkcja w samochodzie miała swój taki minikomputer, więc tworzenie oprogramowania wymagało integracji w tym jednym minikomputerze, tylko jednej funkcji. To powodowało, że samochód był zbudowany z kilkudziesięciu, może nawet więcej takich minikomputerów, które były połączone ze sobą poprzez jakąś magistralę komunikacyjną, ze sobą rozmawiały. Postęp technologiczny spowodował, że mikrokontrolery, czyli elementy tych minikomputerów, zwiększyły swoją wydajność obliczeniową, pamięciową, ilości możliwości obsługi peryferiów, mamy architektury wielocore’owe, co spowodowało, że wiele takich funkcji może zostać zintegrowane w jeden taki minikomputer, czyli możemy zredukować liczbę tych minikomputerów w samochodzie do mniejszej liczby, co powoduje możliwość obniżenia kosztów. Obniżenia kosztów poprzez tworzenie układów, płytek PCB, układów stalonych, układów analogowo-cyfrowych, ilość przewodów komunikacyjnych w samochodzie, zastosowanie zamiast klasycznych bezpieczników tzw. e-fuses, czyli elektronicznych bezpieczników. To wszystko powoduje, że koszt wytworzenia takiego samochodu radykalnie się zmniejsza. Ale żeby to było możliwe, musimy pamiętać o tych zasadach tworzenia oprogramowania, bo jeżeli mamy minikomputer, który robi tylko jedną funkcję, to bardzo prosto taki system przetestować, co Paweł możesz trochę więcej powiedzieć o tych testach. Bo jest to proste do zrobienia, jest łatwo udowodnić, że system jest bezpieczny, bo on tylko jedną rzecz wykonuje. Natomiast kiedy mamy sytuację, gdzie mamy wysoką moc obliczeniową, takiego mikro kontrolera, mamy wiele rdzeni. Programiści muszą zapewnić też synchronizację pomiędzy tymi wątkami na tych rdzeniach, które są uruchamiane, muszą zapewnić o synchronizacji danych, które są wykorzystywane do tych operacji i funkcji, które tam są. Mamy coraz gęstszą integrację w tych systemach. To powoduje, że wyzwania do przetestowania i udowodnienia, że taki ECU jest bezpieczny, jest wyzwaniem. Nie jest to proste do zrobienia, ponieważ ilość zależności w takim oprogramowaniu rośnie wykładniczo. Jeżeli nie będziemy zachowywać odpowiednich sposobów tworzenia takiego oprogramowania, to możemy dojść do takiej sytuacji, że mimo tego, że mamy bardzo wiele mocy obliczeniowej, nam jej zabraknie, ponieważ nie będziemy redukować zależności pomiędzy tymi komputerami, które mamy, nie będziemy minimalizować komunikacji, która musi się między nimi dziać dla spełnienia pewnych funkcji. A także będziemy na wyrost tworzyć powiązania pomiędzy funkcjami, które są zaaplikowane dla danych rdzeni. Jeden rdzeń będzie czekał na drugi i zamiast wykorzystać większą moc obliczeniową staniemy przy ścianie i stwierdzimy, że nie da się tego zrobić, bo mimo tego, że mamy cztery rdzenie, czy osiem, czy więcej, to nie jesteśmy w stanie wykonać tych funkcji, ponieważ wszystko na wszystko czeka i nic się nie jest w stanie wykonać. Więc jeżeli nie będziemy myśleć o tych wszystkich kwestiach, o których mówi inżynieria oprogramowania, bo to jest tak naprawdę dziedzina inżynierii oprogramowani z dziedziną, która mówi o tym jak tworzyć to oprogramowanie tak, żeby unikać tych zależności i móc dostosowywać oprogramowanie do pewnych ograniczeń hardware’u, żeby efektywnie ten hardware wykorzystywać. 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, reużywalne i tak dalej. Że musimy unikać zależności. 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 zapewnia nam podejście Software Defined Vehicles.
 
Paweł Kmiecik
Dokładnie, ja jeszcze z perspektywy testera tutaj dodam, że kiedyś testowaliśmy mniejsze jednostki, tak zwane ECUs, które były jakby wyspecjalizowane w wykonywaniu danej czynności, czy to danego modułu i tam było, dajmy na to, 100 w aucie, tak? I w tym momencie mieliśmy 100 osobnych modułów, które mogły być testowane, które tylko się komunikują ze sobą, jeżeli jest taka potrzeba, natomiast teraz mamy całą nową architekturę, gdzie mamy jeden wielki komputer pokładowy, tak zwany HPC, i kilka zonali, a więc to też jest duża, duża zmiana, o której może też Łukasz zaraz dopowie. Ja tylko chciałem powiedzieć, że właśnie te testy stają się coraz bardziej skomplikowane przez właśnie liczbę zależności między tymi modułami, a więc teraz wszystko się komunikuje ze sobą, głównie też po sieci Ethernet, która w Automotive coraz więcej zyskuje popularności, przez co te testy są coraz bardziej skomplikowane. Aczkolwiek są o tyle dobre, że testujemy jeden kod, że mamy jedną wielką platformę. Mamy też pewnie wsparcie od innych zespołów, jeżeli czegoś nie wiem, jak działa dany moduł, możemy zawsze się skomunikować z innym zespołem. Natomiast trzeba o tym pamiętać, że liczba tych zależności rośnie wykładniczo, w zależności od tych serwisów, które mamy, co też utrudnia nam nasze testy. Przez co coraz więcej firm też idzie w Continuous Integration, tak, żeby raz napisane automatyczne testy były wykonywane bez naszej wiedzy, znaczy z naszą wiedzą, aczkolwiek mówię tutaj o takich sytuacjach, kiedy na przykład testy są wykonywane w tak zwanym pipeline, czyli jeden po drugim automatycznie wykonują się, na przykład w nocy, a więc dokonujemy jakichś zmian w kodzie, przychodzimy rano do pracy i mamy wykonanych dziesięć tysięcy testów, które na przykład w nocy się wykonały i już wiemy, czy te zmiany były dobre i czy nie popsuły nam innych modułów. A więc tutaj też od strony testów następuje jakby większy nacisk na niektóre obszary, które wcześniej były, aczkolwiek właśnie przy takiej mniejszej granulacji tych testów nie było aż takiego nacisku na takie właśnie rzeczy jak continuous integration. Wspomniałem jeszcze tutaj właśnie o architekturze Zonali, czy Łukasz mógłbyś coś więcej na ten temat też powiedzieć?
 
Łukasz Okoń
Zonale, czyli tak zwane ECU strefowe, tak jak powiedziałem kiedyś mieliśmy kilkanaście, nawet kilkadziesiąt takich ECU w samochodzie, które były odpowiedzialne za minimalną liczbę funkcji. Teraz z racji rozwoju technologicznego, te mikrokontrolery są coraz większe, coraz więcej możliwości mają, kilkadziesiąt integruje się w jeden i Ten jeden mikro kontroler, ten jeden ECU jest zaaplikowany do jakiejś strefy samochodu. Samochód może mieć np. 4 strefy w każdym rogu tego samochodu, czyli jeden mikro kontroler będzie odpowiedzialny za obsługę silnika, lewych świateł, szyb, przycisków, które się gdzieś tam będą pojawiały. Prawa strona będzie odpowiedzialna na przykład załadowanie akumulatora elektrycznego, ponieważ z tamtej strony ten akumulator będzie się zajmował i tak dalej i tak dalej. Natomiast centralną, takim komputerem, którym też wspomniałeś, Pawle, HPC, to ja może przybliżę skrót, High Performance Computer, czyli to już jest ECU, które ma duże możliwości obliczeniowe, zazwyczaj składa się z kilku mikro kontrolerów, składa się również z procesora ogólnego przeznaczenia, czyli takiego dużego komputera prawdziwego, który mieliśmy, który ma zapewniać obsługę infotainmentu, jakiegoś kokpitu, systemów ADASowych, czyli takich funkcji, które wymagają naprawdę dużych mocy obliczeniowych do ich wykonywania. 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 tak. No i to powoduje, że ta 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 dla mikrokontrolery, na to już nie ma miejsca. Znaczy, dalej ma, ale tylko w niektórych przypadkach. Jeżeli chodzi o te funkcje infotainmentowe i tak dalej, tych wymagających dużych mocy obliczeniowej, tam już się wykorzystuje inne platformy, tak zwanego ogólnego przeznaczenia. Komputery, które macie na biurkach, mają podobną specyfikację do tego, co w takim samochodzie się znajduje do wykonywania takich innych funkcji. Co za tym idzie dalej? Skoro inżynierowie pracujący w Automotive nigdy nie musieli pracować nad takimi wysokowydajnymi aplikacjami, które już mają dynamiczną architekturę, dynamicznie się zmieniają, czyli takiego ogólnego przeznaczenia, wykonywania ogólnego przeznaczenia, nie czasu rzeczywistego, tak? No to branża wymaga od takich inżynierów nowych umiejętności. Można ich zatrudnić z zewnątrz, zatrudnić nowych pracowników i tak dalej. Natomiast to powoduje, że ta branża się nam dalej rozrasta. Jest duże zapotrzebowanie na inżynierów, którzy są dobrymi specjalistami, których wcześniej w branży automotive nie było, a teraz mają szansę, żeby dołączyć, ponieważ te umiejętności wykorzystali w innych branżach. Gdzie tego typu transformacja skalowalności, reużywalności inżynierii oprogramowania już zaszła kilkanaście lat temu. Więc jest dużo możliwości rozwoju na dzień dzisiejszy dla każdego programisty w branży automotive.
 
Paweł Kmiecik
Tak jest. A propos jeszcze specjalistów, tutaj chciałbym dodać, że bardzo właśnie wiele jest obszarów, które teraz są rozwijane dopiero w Automotive. Tutaj właśnie wspomniałeś o mocy obliczeniowej. Ja chciałem też szybko napomknąć, że w samochodach Software Defined Vehicles też duży nacisk będzie kładziony na integrację z chmurą, a więc niektóre obliczenia będą wykonywane jakby 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 jakaś 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 wymianę danych między tymi autami, co też jest dużą transformacją, a więc jeżeli jeden z samochód nam zgłosi informację o wypadku, czy o jakiejś kondycji, o kondycji drogi, na przykład o oblodzeniu, 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, tak? A więc tutaj też tak w ten sposób rozwiązujemy troszeczkę problem tych ogromnych zapotrzebowań na moc obliczeniową, co zwiększa nam możliwości oraz zapotrzebowanie na specjalistów w całej branży.
 
Łukasz Okoń
Wszystkie nowe samochody są połączone z siecią, czy to GSM, może w przyszłości satelitarnie, więc cały czas ten samochód jest online, co nam umożliwia pewne rzeczy. Jedną z tych rzeczy, o których powiedział Paweł, wymiana informacji nawet pomiędzy samochodami, co ma poprawiać nam bezpieczeństwo. Ja mogę nawet powiedzieć taką ciekawostkę, jest taka firma motoryzacyjna, która ma taką funkcję, jeżeli jedziemy używając nawigacji w samochodzie, on wykrywa w jaki sposób będziemy, jakie zakręty są na naszej drodze i zmienia ustawienia twardości zawieszenia po drodze w zależności, w którą stronę mamy zakręt, tak żeby samochód mógł szybciej ten zakręt pokonać, żeby lepiej nam, więcej komfortu nam zapewnić i tak dalej. To co powiedział Paweł, nie musimy się opierać tylko i wyłącznie na nawigacji, ale także na zmianę tych warunków atmosferycznych i tak dalej. Mogą zmieniać się ustawienia samochodu, zawieszenia, hamowania, nawet pracy silnika w zależności od tego co się dzieje na drodze, coś co mogłoby zostać zebrane przez inne samochody te dane. Czyli mamy tutaj również jakieś big data, które może zostać gdzieś tam przetwarzane w chmurach, rozsyłane, broadcastowane do samochodów, które poruszają się po drodze. To jest ciekawa rzecz, aczkolwiek jeszcze nie powiedzieliśmy o jednej rzeczy. Z racji tego, że samochód jest cały czas online, może zbierać te dane, może je wysyłać, może zmieniać swoje ustawienia w czasie rzeczywistym, jest jeszcze możliwość zdalnej aktualizacji tego oprogramowania. No wiadomo, no nie chcielibyśmy się, żeby taki samochód nam zaczął się aktualizować, jak jedziemy. Każdy z nas pewnie miał już sytuację, że chciał skorzystać z komputera, ale on stwierdził, że on się musi teraz aktualizować. Jeżeli mielibyśmy taką sytuację w samochodzie, to ja sobie nie wyobrażam takiej rzeczy. Aczkolwiek gdy samochód jest na postoju, kiedy użytkownik zgodzi się na taką aktualizację, taka aktualizacja bez wizyty w serwisie może zostać przeprowadzona. I nie tylko samego infotainmentu, czyli tego wysokiej wydajności komputera, jakiegoś tam naszego interfejsu graficznego, jakiejś funkcji, która to zapewnia, ale również tych wszystkich komputerów strefowych, które się znajdują, które umożliwiają integrację z pewnymi elementami wykonawczymi w naszym samochodzie, również mogą zostać zaktualizowane. Tak samo jak w swoim czasie jedna z dużych marek motoryzacyjnych wprowadziła subskrypcję na wyższą most silnika w samochodzie. Taka ciekawostka. Wymaga ona zmiany tak zwanej mapy sterownika silnika, bo mapa definiuje w jaki sposób ma być dawkowane paliwo, jakie ma się przepływy, jakie powietrza powinny być. Wiele takich parametrów, które w silniku są i poprzez zmianę ustawień dostarczania silnika odpowiednimi parametrami możemy zwiększyć lub zmniejszyć jego moc, zwiększyć moc, zmniejszyć oszczędność paliwa i odwrotnie no to, jeżeli ktoś chce mieć 220 koni zamiast 190 to może zapłacić 10 złotych czy nawet 20 złotych miesięcznie żeby mieć tą wyższą moc w danym silniku. To samo tyczy się silników elektrycznych, samochodów elektrycznych, tam już to pole manewru jest dużo wyższe i te widełki, które mogą zostać ustalone przez producenta samochodu, ponieważ regulatory elektryczne mają wyższą elastyczność aniżeli silniki spalinowe i tam mamy więcej możliwości, jeżeli chodzi o takie ustawienia.
 
Paweł Kmiecik
Brzmi to bardzo dziwnie, bo jakby rozmawiamy tutaj jeszcze po granicze jakby update’u na komputerze, a tutaj mamy do czynienia z samochodem i widzimy jak realnie może to wpłynąć na cały jakby performance, tak? Na przykład wspomniałeś o mocy silnika. Tutaj też słyszałem kiedyś o takim przypadku, że producent samochodów wykrył za pomocą map, wiadomo, i prognoz, że nadchodzi huragan. I też właśnie szybko dał update do samochodu, pozwalający aby elektryki zwiększyły swój zasięg, ponieważ one były limitowane, maksymalny zasięg był limitowany software’owo, a w razie właśnie takiego zagrożenia życia producent dał szybki update, żeby ściągnąć właśnie te blokady, żeby użytkownicy mogli jeszcze dalej tym samochodem zajechać.
 
Łukasz Okoń
Ja bym tutaj chciał uniknąć teorii spiskowych, ta limitacja zasięgu samochodu elektrycznego wynika z przede wszystkim bezpieczeństwa, żebyśmy nie rozładowali tego akumulatora zbyt nisko, więc dla bezpieczeństwa tego akumulatora daje się takie limity poprzez oprogramowanie. A także zwiększa się cykl życia takiego akumulatora, bo jeżeli mniej go rozładowujemy, nie doładowujemy go też do 100%, które tak naprawdę takie akumulatory litowo-jonowe pozwalają. Każde doładowanie go do maksymalnego możliwego napięcia powoduje, że ta degradacja tego akumulatora jest wyższa. Czyli za bardzo załadować zmniejsza nam ilość cykli życia tego akumulatora. Tak samo jak go zbyt bardzo rozładujemy, też może to spowodować. Więc to nie jest tak, że software’owo ograniczamy funkcję samochodu po to, żeby wymusić na użytkownikach wykupienie wyższych wersji i droższych wersji samochodu, tylko robi się to ze względów bezpieczeństwa, a także by wydłużyć cykl życia takiego samochodu. No bo nie chcielibyśmy chyba wykupić samochodu elektrycznego, który po 400 cyklach ładowania, czyli powiedzmy dwóch latach użytkowania stwierdzi, że jego akumulator jest do wyrzucenia i trzeba za duże pieniądze go wymienić. Więc to są takie możliwości, które również oprogramowanie nam pozwala na to tak, bo to oprogramowanie steruje tymi elementami.
 
Paweł Kmiecik
A propos jeszcze funkcji dodatkowych w takim samochodzie, ostatnio też słyszałem o koncepcji phone as a key, że możemy używać naszego telefonu jako kluczyka. Co też jest bardzo imponujące, że już nie będziemy musieli mieć fizycznego kluczyka, który też nam służył jako tradycyjny kluczyk, tak? Nie mówię tutaj o stacyjce, bo już ta technologia jest znana. Aczkolwiek tutaj od razu miałem myśl a propos cyber security. Jakby coraz więcej modułów integrujemy, coraz więcej ciekawostek dodajemy, aczkolwiek to wszystko musi być zabezpieczone odpowiednio, nie uważasz?
 
Łukasz Okoń
Tak i to jest kolejne wyzwanie tak naprawdę dla tej branży, ponieważ wcześniej samochody nie były połączone z siecią internetową, nie miały takich funkcji. Teraz okazało się, że mają. No i musimy zapewnić jako inżynierowie, żeby te funkcje były bezpieczne. Nie wyobrażam sobie, żeby było dobrze, gdyby ktoś podszedł do mojego samochodu udając mój telefon komórkowy i nim odjechał, w jakiś sposób emulował działanie mojego klucza, który byłby wpisany w mój telefon, więc te wszystkie funkcje muszą być ze sobą zintegrowane. Natomiast, co chciałem jeszcze powiedzieć, to taka rewolucja w branży automotive nakłada nie tylko wymagania na zmianę podejścia do budowy samochodów, ale także udostępnienia pewnych funkcji, które są implementowane w smartfonach. Czyli mają producentów telefonów komórkowych, mamy producentów samochodów. Oni muszą ze sobą współpracować, żeby te rozwiązania po jednej i z drugiej strony były ze sobą kompatybilne, a przy okazji również bezpieczne. Powiedziałeś też o tej magistrali Ethernet, która jest wykorzystywana często w zamian lub przy współpracy z magistralą CAN, standardową magistralą samochodową, ona również musi zapewniać pewne poziomy bezpieczeństwa. Było kilka takich przypadków, gdzie brak takich zabezpieczeń cyber security spowodował niezbyt ciekawe rezultaty. Na przykład jeden z producentów oprogramowania pozwalał wpiąć się do takiej magistrali, transmisja pomiędzy modułami samochodu, w tym przypadku pomiędzy samochodem, który umożliwiał autonomiczną jazdę, a kierownicą samochodu, czyli wydawanie komend z autonomicznej jazdy, jaki powinien być kąt kierownicy i jak powinien skręcać samochód, a także przyspieszać i hamować. Ta transmisja na pewnym etapie, oczywiście wczesnym, nie była zabezpieczona i umożliwiło paru entuzjastom wpięcie się do tej magistrali komunikacyjnej, zbudowania takiego swojego minikomputerka, który symulował działanie tego systemu autodrive. Było to połączone z padem z konsoli, którą wykorzystujemy do gier, no i ktoś z tylnej kanapy mógł sobie takim samochodem za pomocą takiego pada sterować. Nie byłoby problemu, jeżeli to robimy sobie sami, a nie wyobrażam sobie, gdyby ktoś zewnątrz podczas jazdy na autostradzie z dużą prędkością miałby przyjąć kontrolę nad moim samochodem i doprowadzić do wypadku. Więc tutaj to cybersecurity, o którym mówi Paweł, jest też bardzo ważne. Tak samo safety, bo cybersecurity mówi o zabezpieczaniu, wymianie informacji przed niepożądanym dostępem, a natomiast jest jeszcze kwestia safety, czyli w jaki sposób zabezpieczamy nasze oprogramowanie, a także sprzęt w razie awarii jakichś elementów, żeby awaria nie doprowadziła do jakiejś krytycznej sytuacji na drodze.
 
Paweł Kmiecik
Wymieniliśmy bardzo dużo obszarów, które muszą ulec zmianie lub zostać dointegrowane do całego samochodu. Czy uważasz, że branża jest na to gotowa? Bo jest to jednak duży krok milowy.
 
Łukasz Okoń
Jest to bardzo duży krok milowy i jest bardzo problematyczny z tego względu, o którym mówiliśmy wcześniej, że mamy wielu inżynierów, setki inżynierów w pewnej branży motoryzacyjnej, którzy są przyzwyczajeni do wykonywania innej pracy. teraz nie tylko ci ludzie, ale także zarządzający, zarządzają projektami. Wszystko się musi zmienić.  Dlatego łatwiej jest firmom, które dopiero zaczynają branżę automotive, są tego typu startupami, bo mogą sobie zrobić wszystko od początku po swojemu. To podejście to będzie pierwsze podejście dla nich w tej dziedzinie. Natomiast jeżeli mamy koncerny, które mają kilkadziesiąt lat na rynku, niektóre mają już nawet setkę lub więcej, one mają pewne przyzwyczajenia, pewne wypracowane sposoby radzenia sobie z tymi problemami w motoryzacji. 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 a w samochodach ma być zaimplementowany.
 
Paweł Kmiecik
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 define vehicles jest też AI i musimy być na tą też transformacje gotowi oraz wiedzieć jakie zagrożenia idą przez integrację właśnie sztucznej 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, na przykład tutaj jak wcześniej też wspomnieliśmy o analizowaniu big data i zbieraniu danych z drogi oraz sensorów z kamer, uploadowanie jej do chmury i następnie wyciąganie bardzo ciekawych wniosków, które być może będą ulepszać nasze algorytmy, uczyć nasze sieci AI, które będą stawały się coraz lepsze na podstawie właśnie realnych danych z drogi, czy to też zbieranie tych danych, aby analizować jakieś ciekawe rzeczy i być może wykorzystywać je do różnych celów. Ja mam na myśli na przykład, taką koncepcję, że samochody będą troszeczkę takimi jeżdżącymi obserwatorami i będą nam mówić o stanie i kondycji drogi w danym mieście. Takie dane mogą być zbierane i wysyłane do chmury i następnie analizowane. No i ciekawe wnioski mogą być z tego wyciągnięte. I też, tak jak wcześniej wspomnieliśmy, dużo rzeczy może być analizowanych, wysyłanych do chmury i bezpośrednio możemy dostawać update’y, które będą wpływały na zachowanie naszego samochodu. Także brzmi bardzo fajnie, aczkolwiek czy widzisz jakieś zagrożenia w tej całej koncepcji?
 
Łukasz Okoń
Brzmi fajnie, tak jak powiedziałeś, natomiast zagrożenia są takie, które wynikają z samych założeń wykorzystywania sztucznej inteligencji. To co powiedziałeś, czyli zastosowanie sztucznej inteligencji, to jest nieodzowny element pracy systemów autonomicznej jazdy. Wykorzystuje się wiele algorytmów, rozpoznają nam obrazy, rozpoznają obiekty na drodze, przewidują pewne zachowania na drodze i tak dalej. Do tego wszystkiego wykorzystywana jest właśnie sztuczna inteligencja. Wykorzystywana też jest do tych elementów, może być wykorzystana do takich może asystentów głosowych, których możemy mieć w przyszłości dostępnych w samochodzie. Może też być wykorzystywana do zmiany tych parametrów, elementów mechanicznych, elektromechanicznych naszego samochodu, które będzie dostosowywać samochód do warunków na drodze. Natomiast musimy pamiętać, że sztuczna inteligencja w swoim założeniu pracuje na pewnych prawdopodobieństwach, czyli rozpoznanie obiektu na drodze mówi programowaniu, że to jest na tyle i tyle procent taki obiekt z takim prawdopodobieństwem. Zawsze jest ta druga strona prawdopodobieństwa, tak, czyli nawet jeżeli mamy 99,999% szans, że to jest to, a ileś miejsc po przecinku 0,1 to jest coś innego, to to jest zawsze ryzyko, że ten oprogramowanie może zachować się inaczej w innych przypadkach. Druga kwestia jest taka, że w zależności od tego w jaki sposób ta sztuczna inteligencja jest wytrenowana, bo trenujemy sztuczną inteligencję, ona ma takie same warunki wyjściowe, może wykonać inny wynik. Dlatego testowanie takiej sztucznej inteligencji jest takie problematyczne, ale myślę, że Paweł ty możesz więcej na ten temat powiedzieć niż ja.
 
Paweł Kmiecik
Często właśnie w testowaniu rozpatrujemy jakąś liczbę tak zwanych przypadków testowych, czyli jeżeli mamy jakiś algorytm, który działa w dany sposób, staramy się przewidzieć każdy przypadek, na który może być narażony ten nasz algorytm i zasymulować wszystkie dane wejściowe, jakie ten algorytm nasz może otrzymać. 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 przy testowaniu Artificial Intelligence dochodzi nam jeszcze taki czynnik, że cały wektor 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 symulacje. 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. żeby zobaczyć zachowanie tego naszego software’u, dlatego dużą część kładzie się na technologię SIL, software in the loop, 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 ograniczona 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 no ja jako tester mogę zasymulować rozmieszczenie pachołków na drodze, symulujących jakieś tam prace drogowe. No i zobaczyć jak nasz cały zasymulowany pojazd się zachowuje. No aczkolwiek dobrze wiemy, że tyle ile z krajów na całym świecie, to tyle różnych rozmieszczeń tych pachołków może być i tutaj jest właśnie problem i tutaj z pomocą troszeczkę przychodzi właśnie analizowanie big data, więc jeżeli nasze auto, nawet jeżeli my jesteśmy kierowcami, może zebrać dane jak my przejechaliśmy przez takie roboty drogowe, wysłać informacje do chmury, jeżeli takich pojazdów producent sprzeda kilka tysięcy, no to uzyskamy bardzo dużą liczbę danych i możemy za pomocą bardzo dużych mocy obliczeniowych coś z tych danych wyciągnąć i ulepszyć nasz algorytm, aby on wiedział już po jakimś tam okresie czasu nauki, jak właśnie przez takie roboty drogowe przejechać. I to jest dobry przykład, który pokazuje właśnie wyzwania obecne w branży, że to już nie jest tak jak kiedyś, że mieliśmy moduł sterowania, czy to kierownicą, czy to, nie wiem, wycieraczkami i testowaliśmy my sobie na przykład integrację wycieraczki z czujnikiem deszczu, tak? I no działa, nie działa, jest deszcz, nie ma deszczu, no to było okej. Aczkolwiek teraz to już te przypadki nie są takie proste i są coraz bardziej złożone, co stanowi ogromne wyzwanie dla też testerów w tej branży, aby zapewnić bezpieczeństwo tych algorytmów i dopuścić je do użytkowania i żeby taki samochód przeszedł też proces registracji, tak?
 
Łukasz Okoń
Jest jeszcze taki case, o którym powiedzieliśmy wcześniej, że mamy roboty drogowe, samochód może się poruszać manualnie w trybie manualnym, zanim jedzie samochód, który jedzie w trybie autonomicznym, ten manualny przejedzie, może przesłać te informacje do autonomicznego, jak je przejechał. Czyli takie online learning też jest możliwe w tym przypadku. Sytuacje, w których nie mamy tego dynamizmu w samochodach i możemy mieć sytuację, że samochód autonomicznie poruszający się nie będzie w stanie sobie polecieć i każe nam przejąć kontrolę nad tym samochodem. To jest taki przypadek, gdzie możemy już go nauczyć tej trasy, ponieważ ktoś przed chwilą ją przejechał w jakiś sposób, może dać na tyle informacji temu samochodowi poruszającemu się w trybie autonomicznym, że to wystarczy do tego, żeby sobie poradził w takich, a nie innych sytuacjach. Tu roboty drogowe są dobrym przykładem, bo to nie tylko między krajami są różnice, ale między nawet każdymi robotami drogowymi mogą być różnice w zależności jak firmy, czy tam panowie, albo panie, które się zajmują takimi remontami mogą poustawiać te pachołki na drodze, zamknąć jeden, drugi pas, przejazd na sąsiednią jezdnię i tak dalej, więc to wszystko może być rozwiązane poprzez właśnie te pomysły, które są realizowane.
 
Paweł Kmiecik
Tutaj jeszcze miałem na myśli taki dobry przykład a propos wypadków drogowych i zachowania takiego autonomicznego pojazdu w jakichś sytuacjach zagrożenia życia. A więc jeżeli projektujemy taką sieć, która będzie jeździć w samochodach, to musimy jakoś przewidzieć różne dziwne przypadki, tak? A więc na przykład jeżeli stoimy na czerwonym świetle i widzimy, że na środku skrzyżowania jest wypadek i samochód, który uległ kolizji, zmierza w naszą stronę. Co ma taki samochód zrobić? Człowiek by nie zważał na to, że jest czerwone światło, tylko jeśli nie ma pieszych, wjechałby na przykład na pasy, żeby uniknąć kolizji z tym nadlatującym w jego stronę pojazdem, taki na przykład przypadek. Aczkolwiek sieć neuronowa musi jakoś wiedzieć, że coś takiego może zrobić w danej sytuacji zagrożenia. I to też wydaje mi się, że to jest do przewidzenia takich sytuacji, no są tysiące, nie da się wszystkich ich przewidzieć i szczególnie bardzo ogromnym wyzwaniem jest zrobić taką sieć, która będzie wiedziała, jak się w takich przypadkach zachować. No tutaj też, dlaczego o tym mówię, no ktoś by pomyślał, no to wtedy autopilot się wyłącza i człowiek ma kontrolę nad pojazdem. No jest to, jest to oczywiście prawdą, aczkolwiek trzeba pamiętać, że dążymy tutaj do wyższych leveli autonomiczności. Tutaj mam na myśli levele 4-5 autonomicznych pojazdów, gdzie 5 to jest już pełna automatyzacja, bez kierownicy w samochodzie i kierowca czy tam pasażer może siedzieć tyłem do toru jazdy i po prostu będzie się odbywał transport z punktu A do punktu B. Jest to bardzo daleka wizja, aczkolwiek dążymy do tego, tak? No i obecnie jesteśmy na takim poziomie, że no te autonomiczne pojazdy są. aczkolwiek no do jakiegoś poziomu, tak, że jakby jeżeli ten pojazd sobie nie poradzi z danym przypadkiem, który się obecnie dzieje na drodze, no to poprosi nas o przejęcie kontroli i wtedy musi już człowiek zadziałać. Dlatego też to integrowanie AI jest bardzo ważne właśnie do takich przypadków, gdzie zbieramy dane po prostu od użytkownika i wiemy, jak powinien się zachować algorytm w danych sytuacjach.
 
Łukasz Okoń
Zbieranie tych danych to też jest taka możliwość ich analizy, jeżeli mamy jakieś wypadki na drodze, co się wydarzyło, w jaki sposób samochód mógł zareagować wcześniej. Tak mamy moduły, które odpowiadają za automatyczne hamowanie na drodze, na ewentualnie nawet skręcanie w miejsce, gdzie jest puste na drodze, żeby nie doprowadzić do wypadku analizy na drodze itd. To zbieranie informacji z sytuacji, które miały już takie miejsce może właśnie pozwolić na to, że te algorytmy, które są do tego wykorzystane mogą zostać ulepszone o te dane, analizę tych danych, które wydarzyły się na drodze.
 
Paweł Kmiecik
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, będzie mógł współpracować na przykład z całym transportem publicznym w danym mieście. To jest też taka bardzo daleka wizja, aczkolwiek ciekawa, że będziemy mieli wszystkie usługi publiczne, czy to tramwaj, czy to jakiś autobus, czy to poruszanie się po jakiejś drodze, będziemy mieli zsynchronizowane w jednym miejscu, gdzie nasz pojazd dosłownie będzie taką kapsułą do transportu nas. I taka wizja, że nasze auto jest taką jeżdżącą kapsułą autonomiczną, i ono wjeżdża do tramwaju, a potem z niego wyjeżdża i my nawet 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, a staramy się to zrobić. Branża idzie w tą stronę i zobaczymy w jakim tempie to pójdzie. Nie wiem, co Łukasz o tym sądzisz.
 
Łukasz Okoń
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ę do tego, że nawet podczas cyklu życia urządzeń, pojazdów, czegokolwiek możemy dodać, zmienić, usunąć pewne funkcje, poprawić je. Więc cała ta pieśń przyszłości, o której powiedziałeś Paweł, będzie tylko i wyłącznie możliwa, jeżeli sposób tworzenia oprogramowania dla tych urządzeń będzie zgodny, zbudowany w taki sposób, aby te zmiany były możliwe. Jeżeli napiszemy sobie oprogramowanie, które nie będzie w prosty sposób umożliwiało dodanie nowych funkcji i spowoduje to, że koszt dodania funkcji, mimo że samochód jest na drodze i został wyprodukowany będzie tak duży, że będzie nieopłacalny. Więc to się nie tyczy tylko samochodów, to się tyczy wszystkiego tak naprawdę co nas otacza. Niestety branża automotive jest trochę z tyłu, jeżeli chodzi o inne branże i ta transformacja, którą teraz przechodzimy jest trudna dla wielu producentów samochodów, ale ona niestety musi się wydarzyć. Z jednej strony jest to trudność, a z drugiej strony jest to okazja. Jest to okazja dla nas jako inżynierów na to, żeby się rozwijać, na to, żeby ulepszać, żeby być dumnym z tego, że samochody, których coś tam robiliśmy wcześniej jeżdżą po drogach i ludzie są z nich zadowoleni. To też jest szansa dla inżynierów, którzy pracowali w innych dziedzinach i tamte elementy, które są wdrażane teraz w branży automotive, oni już je znają, więc mogą przejść do tej branży i będą mogli wspomóc tą transformację, zyskać na tym. Rynki w innych branżach mogą być już trudne, ponieważ ta transformacja tam już została przeprowadzona wcześniej. Te elementy już tam zostały zastosowane wcześniej, więc dla tych ludzi… branża Automotive potrzebuje ludzi, którzy mają takie doświadczenie i taką wiedzę, więc to jest dla nich okazja, że może być to dla nich łatwiejszy rynek, aniżeli ten rodzimy, w którym całe życie się, czy swoją karierę zawodową, której się obracali. Więc nie tylko problemy, ale również okazja.
 
Paweł Kmiecik
Tak, szczególnie, że tych kompetencji brakuje, bo tak jak wspomniałeś, no wcześniej nikt na to nie zwracał uwagi, ponieważ nie było takiego zapotrzebowania. W tym momencie, jeżeli kupimy auto, no to ta wizja tych update’ów i wgrywania nowych funkcjonalności jest, nie powiem, bardzo ciekawa. I tutaj właśnie musi być to jakoś zrealizowane, tak jak wspomniałeś, a wcześniej nie było takiej potrzeby, a więc nikt się na tym nie skupiał po prostu.
 
Łukasz Okoń
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łumaczoną. 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 developerskiego zmieniały się wymagania co do tego projektu, nowe funkcje klient sobie do nich życzył. No i 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. To przecież to ma być software, tak? To software z angielskiego, coś miękkiego, soft, tak? 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. Tak odkryłem inżynierię oprogramowania. Więc żeby zrozumieć, że ta inżynieria oprogramowania jest potrzebna, to trzeba parę tych projektów zepsuć. Trzeba parę razy nadziać się na swoje własne przemyślenia tworzenia oprogramowania i mieć też wizję pełnego takiego konspektu całego systemu, który budujemy. Bo jeżeli całe życie projektowaliśmy tylko małą część tego systemu, ona potem jakoś była integrowana i jakoś ona tam działała w tym naszym systemie. to my nie będziemy widzieć to, że jak coś dodamy, to coś innego się może zepsuć. Dla nas to będzie niepojęte z punktu widzenia inżyniera oprogramowania. Więc to też jest problem w tym automotive, bo większość mając duży koncern motoryzacyjny, w którym inżynierowie są tylko odpowiedzialni za małą część. Każdy jest za inną część odpowiedzialny. Często nie widzą tego szeregu kontekstu i to, że oni coś robią to nie znaczy, że to będzie dobrze działało. działać i że to będzie można łatwo dodać, zintegrować. To jest transformacja, którą z racji tego, co się dzieje na rynku, z racji tego, że samochody są coraz, udostępniają coraz więcej funkcji, wymagamy od nich coraz więcej oraz to, żeby były tańsze, wymagają na inżynierach zmiany tego podejścia i to jest bardzo trudne.
 
Paweł Kmiecik
Dokładnie, to też mogę potwierdzić z perspektywy testów, jeżeli wcześniej właśnie to testowanie było na całkiem innym poziomie, a w tym momencie, jeżeli mamy ten system taki złożony, to też wymaga to dużej współpracy. 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.
 
Łukasz Okoń
Paweł, co byś jeszcze dodał na zakończenie tego naszego podcastu?
 
Paweł Kmiecik
Bardzo dużo tematów poruszyliśmy, naokoło Software Define Vehicles, aczkolwiek trzeba pamiętać, że każdy z tych tematów jest integrowany z tym tematem, tak, a więc jakby to jest wszystko zgrywa się w jedną całość, a dokładnie w innowacyjny samochód, tak, który udostępni nam nowe funkcje i który będzie bardziej że tak powiem flexible, czyli będzie mógł się dostosować do wielu warunków i będzie mógł być przez wiele lat udoskonalany przez producentów, a więc dlatego ten przekrój jest taki ogromny. Szczególnie, że tak jak wspomniałeś, te technologie w innych branżach już są, a tutaj są dopiero rozwijane i będą wprowadzane na rynek. Ogólnie zmierzamy w dobrą stronę, tak, rozwijamy oprogramowanie i z mojej perspektywy staramy się bardzo dobrze testować, żeby było bezpieczne i żeby finalnie było dopuszczone do użytkowania. Dlatego już słowem końcowym mam nadzieję, że za kilka lat każdy z nas będzie miał okazję przejechać się takim autem lub nawet nie będzie miał wyboru może, bo już wszystkie nowe auta będą produkowane w ten sposób, ponieważ no umożliwia to bardzo dużo dodatkowych opcji, które wpłyną na finalnie poprawę naszego stylu życia oraz jazdy i przyjemności z tej jazdy.
 
Łukasz Okoń
To dzięki Paweł, dzięki za rozmowę.
 
Paweł Kmiecik
To dzięki za rozmowę Łukasz. Do zobaczenia.
 
Łukasz Okoń
Do zobaczenia.
 
Outro
Aby nie przegapić kolejnych odcinków zasubskrybuj podcast TechChatter w swojej ulubionej aplikacji. A jeśli spodobał Ci się ten odcinek, daj nam znać, wystawiając ocenę na Spotify lub Apple Podcasts. Wszystkie linki do zagadnień poruszanych w odcinku znajdziesz w jego opisie.