To jest 215. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o pojazdach definiowanych programowo. 

Sponsorem tego odcinka jest firma ZF. Notatkę, linki oraz transkrypcję do dzisiejszego odcinka znajdziesz pod adresem porozmawiajmyoit.pl/215. Podcast Porozmawiajmy IT jest dostępny zupełnie za darmo. Obowiązuje tylko jedna zasada: jeśli jesteś tu przynajmniej po raz drugi, to po pierwsze rozgość się, a po drugie odwdzięcz za te treści, wystawiając ocenę w Twojej aplikacji podcastowej lub polecając odcinek w social media. Dziękuję. 

Ja się nazywam Krzysztof Kempiński. Moją misją jest poszerzanie horyzontów ludzi z branży IT, co realizuję m.in. poprzez ten podcast. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

 

Cześć, mój dzisiejszy gość to dyrektor działu inżynierii oprogramowania w Centrum Inżynieryjnym Elektroniki firmy ZF w Łodzi. Ze światem IT, w szczególności z inżynierią oprogramowania, związany od blisko 20 lat. Swój kapitał zawodowej wiedzy i doświadczenia budował przez lata, pracując w wielu projektach rozwoju oprogramowania dla kontrolerów stacji bazowych sieci komórkowych technologii drugiej, trzeciej i czwartej generacji. Pełnił rolę, począwszy od dewelopera, a skończywszy na technicznym koordynatorze. Od 6 lat w roli liniowego lidera w firmie ZF, wspólnie z działem rozwoju oprogramowania bierze udział w ewolucji sektora automotive pod względem zaawansowanych systemów wspomagania kierowcy. Moim i Waszym gościem jest Radosław Pełka. 

Cześć, Radku, bardzo mi miło gościć Cię w podcaście. 

 

Cześć, witam serdecznie. Mnie również jest bardzo miło, że możemy się spotkać. 

 

Dzisiaj z Radkiem będę rozmawiał o temacie, którego w Porozmawiam IT jeszcze nie było, czyli samochody. Ale nie będziemy się tutaj spierać nad wyższością elektryków nad samochodami spalinowymi czy tego typu rzeczach, będziemy mówić o oprogramowaniu i jak software obecnie wspiera rozwój branży automotive. 

Zanim jednak do tego przejdziemy, to chciałbym cię Radku zapytać, czy słuchasz podcastów. Jeśli tak, to jakie audycje najczęściej u Ciebie goszczą? 

 

Mówiąc całkiem szczerze, zdarza mi się słuchać podcastów. Nie w sposób regularny, bardziej wynika to z potrzeby chwili. Mam tu na myśli np. kwestie poszukiwanej wiedzy bądź jakiegoś zagadnienia, rzadziej jako typowa rozrywka. Tam, gdzie słucham podcastów, na pewno mogę wskazać tutaj swoją firmę, gdzie takowa forma dystrybucji też informacji, wiadomości jest używana, więc są to podcasty firmy ZF. 

A jeżeli chodzi o takie bardziej ogólnodostępne, no to mogę tutaj polecić na przykład Autoline. I tutaj mamy takie dwie wersje: After Hours oraz Autoline Daily. Tak jak same nazwy wskazują, może pierwsza jest taka trochę bardziej poświęcona różnorodnej tematyce i trochę w bardziej sposób taki ogólny i dłuższy dyskutowane są tematy. Druga natomiast jest to taki krótki, dzienny, powiedzmy, raport z tego, co ciekawego, co nowego itd. Tak więc z mojej strony ewentualnie taka rekomendacja. 

 

Dzięki za te rekomendacje. Mówi się o tym, że obecnie ta branża automotive coraz bardziej konkuruje właśnie jeśli chodzi o oprogramowanie, że cała mechanika, cały ten sprzęt, który de facto napędza i rozpędza auta, nie jest już tym obszarem, który stanowi tutaj element właśnie konkurencji pomiędzy producentami samochodów. Dlatego chciałbym Cię zapytać, jak dużo oprogramowania obecnie jest w tych właśnie autach, które są teraz produkowane. 

 

Krótka odpowiedź byłaby taka: bardzo dużo. Myślę, że ponad takie przeciętne wyobrażenie użytkownika, takiego przeciętnego użytkownika samochodu, czy ogólnie mówiąc pojazdu. Jeśli byśmy tutaj konkretnie chcieli przywołać jakieś liczby, to mogę powiedzieć, że w najnowszych modelach szacuje się, albo nawet potwierdza się, że jest to ok.100 mln linii kodu. Jeżeli chodzi o pojazdy bardziej luksusowe, w których mamy dużo więcej elektronicznych jednostek kontrolujących różne funkcjonalności, może to być nawet ok. 150 mln linii kodu. I ta liczba nadal rośnie, czyli tutaj różne względy na to wpływają. Myślę, że podczas dzisiejszej rozmowy może też o to zahaczymy. 

Ale też powiem dla porównania. Dla osoby, która chciałaby poczuć, czy to jest duża wartość, czy to jest niewielka wartość. W samolocie pasażerskim jest to ok. 15 mln linii kodu. W popularnym systemie operacyjnym komputerów klasy PC jest to ok. 50 mln linii kodu. Tak więc to pokazuje, jaką mamy tutaj proporcję. Co więcej, szacuje się, że właśnie ten trend wzrostowy będzie nadal bardzo wyraźny. Jeszcze patrząc na to z innej perspektywy, bo np. nawiązując tutaj do biznesu, szacuje się, że w roku 2030 ten biznes czy zyski potencjalnie z produkcji oprogramowania mogą podwoić się w stosunku do roku 2020, więc to wyraźnie pokazuje tendencję rozwojową. A mówimy tutaj o setkach miliardów dolarów, więc to też daje pewny pogląd. 

Jeśli byśmy tutaj konkretnie chcieli przywołać jakieś liczby, to mogę powiedzieć, że w najnowszych modelach szacuje się, albo nawet potwierdza się, że jest to ok.100 mln linii kodu. Jeżeli chodzi o pojazdy bardziej luksusowe, w których mamy dużo więcej elektronicznych jednostek kontrolujących różne funkcjonalności, może to być nawet ok. 150 mln linii kodu. I ta liczba nadal rośnie, czyli tutaj różne względy na to wpływają.

 

Jasne, niebotyczne liczby. Czyli właściwie komputer na kółkach, można by powiedzieć. Zaskoczyłeś mnie tutaj taką aż dużą liczbą linii kodów w oprogramowaniu, które z nami jeździ. Jestem ciekaw, z czego to wynika, że tych linii coraz bardziej przybywa, że ten trend jest właśnie wzrostowy, tak jak powiedziałeś. Czy to są kolejne featury, kolejne rzeczy, które gdzieś jako kierowcy odbieramy, widzimy, zauważamy, czy może właśnie wynika to z tego, że te mechanizmy, te urządzenia po prostu potrzebują obecnie coraz więcej software’u, żeby działać?

 

Jedno i drugie, szczerze mówiąc, czyli na pewno jest to ta kwestia, która jest zauważalna, również marketingowo, czyli głównie tutaj mam na myśli reklamy, które w tym momencie już trafiają gdzieś do nas, którymi jesteśmy tutaj karmieni, pokazujące nowe funkcjonalności samochodu, ale są też rzeczywiście takie aspekty, których nie widać na pierwszy rzut oka, dotyczące głównie kwestii bezpieczeństwa. I tutaj takim driverem, jeśli chodzi o ten rozwój, są też regulacje prawne, które narzucają na producentów pojazdów pewnego rodzaju obowiązki i z tego to wynika. 

Ale tak ogólnie rzecz biorąc, jest kilka aspektów, o których warto wspomnieć. Na pewno pewnego rodzaju zmiana sposobu myślenia i postrzegania samochodu z punktu widzenia użytkownika. Mam na myśli to, że oczekuje się, że samochód przyszłości, bo tak naprawdę my wykonując swoją misję, czyli mówiąc o mobilności przyszłych pokoleń, ten horyzont mamy dużo dalej niż w dniu dzisiejszym czy za rok, więc ten samochód przyszłości będzie w dużym stopniu oraz elastycznie konfigurowalny. 

Takie jest oczekiwanie użytkownika. I tutaj mam na myśli te różne funkcjonalności pojazdu, które są dla użytkownika widoczne, których doświadcza bezpośrednio. Użytkownik też chce np. płacić za nie tylko wtedy, kiedy faktycznie ich używa. Więc i aktywować je wtedy, kiedy ich potrzebuje, i wówczas za nie ponosi koszty, i oczywiście chce, żeby to się działo bez potrzeby wizyty w serwisie. Czyli taki zupełnie inny, powiedziałbym, pogląd na samochód, na pojazd, niż to było w przeszłości. 

Oczekuje się również – to też jest bardzo taki silny trend – że samochód zapewni możliwość pozostania podłączonym w sposób ciągły do internetu i korzystania z jego dobrodziejstw. Ponadto trend mobilności takiej współdzielonej może okazać się wiodący w przyszłości, są już ku temu pewne sygnały, więc taki scenariusz też należy brać pod uwagę i myśleć o pojazdach z punktu widzenia np. systemów służących do rezerwacji czy zarządzania flotą pojazdów współdzielonych. Więc tutaj też zaczynamy tak troszeczkę mówić o oprogramowaniu, które wspiera pojazd, niekoniecznie jeżdżąc w nim, ale też na zasadzie takiego backendu, nazwijmy to. 

Również bardzo ważnym właśnie tym aspektem są kwestie bezpieczeństwa, regulacje wcześniej wspomniane, podnoszenie komfortu użytkowania. I oczywiście taki cel długofalowy, to są pojazdy w pełni autonomiczne. Wszystko to napędza rozwój software’u po to, aby sprostać tym celom. 

 

Czy to, co właśnie opisałeś, to jest pojazd definiowany programowo? Czy można tutaj postawić znak równości? Rozszerzając to pytanie: czy o samochodzie coraz bardziej będziemy myśleć, jak o kolejnym urządzeniu, na które możemy instalować oprogramowanie, które właśnie jest podłączone do internetu, które jest sterowane tym oprogramowaniem, podobnie jak tablety, smartwatche itd.? 

 

To skojarzenie jest całkiem dobre. Rzeczywiście tutaj zmienia się paradygmat postrzegania pojazdu jako takiego i to podłączenie, ta możliwość rozszerzania według własnych potrzeb przywołuje nam takie skojarzenia. I one są dobre. 

Czy to jest dokładnie znak równości? Ja bym powiedział, że pojazd definiowany programowo to przede wszystkim pojazd, którego charakterystyka, funkcjonalności, czy ogólnie mówiąc, możliwości są definiowane poprzez pryzmat software’u. I co istotne, te możliwości mogą ewoluować w czasie wraz ze zmianą potrzeb użytkownika. I ten software powinien właśnie to umożliwić. 

To również pojazd, w którym następuje zasadnicza separacja software’u od hardware’u. W tym sensie, że obie te domeny mogą, co do idei oczywiście, być projektowane niezależnie. Z innej perspektywy można również powiedzieć, że jest to koncepcja, która umożliwia otwarcie nowych perspektyw biznesowych dla producentów pojazdów. Czyli ten strumień zysku nie polega tylko na sprzedaży pojazdu i jego serwisowaniu od strony mechaniczno-elektrycznej, ale na długoletniej możliwości wzbogacania tego pojazdu o funkcjonalności, za które użytkownik będzie gotowy zapłacić. I tak bym powiedział, że należy patrzeć na definicję czy na koncepcję pojazdu definiowanego programowo. 

 

Mówimy tutaj głównie o softwarze, który napędza rozwój branży, napędza samochody, ale gdybyśmy chwilkę mogli spojrzeć na ten hardware, który też jest niezbędny mimo wszystko na koniec dnia, jednak te fizyczne urządzenia są niezbędne, żeby auto sprawowało swoje funkcje. Na ile rozwój tych dwóch gałęzi, czyli tej elektroniki, która jest później sterowana oprogramowaniem, i oprogramowania jako takiego idzie w parze, na ile obecnie można powiedzieć, że te branże rozwijają się równolegle, czy też może oprogramowanie już jest do przodu, a elektronika sprawuje taką drugorzędną rolę?

 

Absolutnie tutaj musi to iść w parze. Ten rozwój musi być równoległy i tak naprawdę software w tym nowym ujęciu, czy w ujęciu przyszłościowym wymaga odpowiedniej platformy, wymaga odpowiedniej elektroniki w pojeździe. Ta elektronika musi sprostać tym potrzebom, myśląc tutaj też o jej elastyczności, skalowalności, ponieważ musimy rozpatrywać też przypadki użycia, które na dzień dzisiejszy są może dla nas jeszcze niezdefiniowane. Tak jak sobie powiedzieliśmy, te potrzeby użytkownika mogą się z czasem zmieniać. Mówimy tu o takiej długoterminowej wizji wzbogacania pojazdu, więc też ta strona hardware’owa musi być też na to przygotowana z pewnym zapasem. 

Więc musi ona podążać za wizją rozwoju pojazdów. W ich podstawowym przypadku użycia, czyli takiej platformy służącej do przemieszczania się z punktu A do punktu B, ale brać pod uwagę te wszystkie nowe przypadki. 

To bardziej skomplikowane oprogramowanie, o którym my tutaj mówimy, wymaga też nowego podejścia. I tutaj mamy na  myśli taką ideę centralizacji zarządzania funkcjami pojazdu, która wymaga wysoko wydajnych platform obliczeniowych, czyli tzw. high performance computers, które są w stanie w ułamku sekundy przeanalizować aktualną sytuację, w jakiej znajduje się pojazd, agregując dane z wielu sensorów i odpowiednio zareagować do tej sytuacji. 

Tak jak wspomniałem, musi też istnieć pewna rezerwa mocy obliczeniowej na przyszłe potrzeby. Takie komputery wysokowydajne, bo już tak trzeba na to patrzeć, to nie są jakieś proste electronic control unit, które są wyposażone w proste mikrokontrolery. Mówimy tutaj już o zaawansowanych mikrokontrolerach. Są to rozwiązania typu system on chip. Czyli tak naprawdę mamy jedną kość, ale w tej kości siedzi nam dużo komponentów składowych, wiele tak naprawdę rdzeni, wielu typów procesorów stopionych gdzieś tam w jedną kość, ale łącznie sprawująca tę główną funkcję na takim komputerze. Mówimy tu o wyższych częstotliwościach taktowania, większej pamięci dostępnej, obsłudze wydajnych kanałów przesyłu danych, bo to też jest niezmiernie istotny aspekt. Jak możemy sobie wyobrazić, ta ilość danych przetwarzanych rośnie i będzie nadal rosła, jeśli chodzi o funkcję pojazdu. Jest to zupełnie inny świat, można powiedzieć, inny pogląd na architekturę, w związku z czym i ta elektronika również musi ewoluować adekwatnie. 

Może warto też tu jeszcze wspomnieć o tym, że pojazd, tak jak powiedzieliśmy, to połączenie pojazdu do sieci, czyli pojazd staje się elementem internetu rzeczy, IoT. W związku z tym właśnie ten fokus na dane jest też niezmiernie istotny. One muszą być zarządzane, procesowane, dystrybuowane do chmury. Elektronika musi też podążać za takimi potrzebami. 

To bardziej skomplikowane oprogramowanie, o którym my tutaj mówimy, wymaga też nowego podejścia. I tutaj mamy na  myśli taką ideę centralizacji zarządzania funkcjami pojazdu, która wymaga wysoko wydajnych platform obliczeniowych, czyli tzw. high performance computers, które są w stanie w ułamku sekundy przeanalizować aktualną sytuację, w jakiej znajduje się pojazd, agregując dane z wielu sensorów i odpowiednio zareagować do tej sytuacji.

 

Bardzo ciekawe. Zastanawiam się jednak, jak wyglądają te początki, bo każdy nowy model auta musi przejść przez ten przysłowiowy etap deski kreślarskiej. Wobec tego, na ile to, że coraz więcej software’u w aucie jest, wpływa na to, jak się taki nowy model auta projektuje?

 

Tutaj moglibyśmy wspomnieć o takim koncepcie czy takim sloganie jak Software First, czyli w tym momencie nastąpił też taki przełom czy zmiana sposobu myślenia o projektowaniu pojazdu pod względem jego funkcjonalności. Właśnie na początek myślimy o tym, jaką funkcję chcemy zrealizować w pojeździe, i jak ją zaprojektować pod względem software’owym, a potem zastanawiamy się na jakich danych, z jakich sensorów i jakie elementy wykonawcze powinny być w pojeździe użyte, żeby osiągnąć zamierzony cel. 

Generalnie architektura pojazdu na poziomie elektrycznym czy elektronicznym, tak jak wspomniałem, staje się bardziej scentralizowana. Mówimy tutaj o tych kontrolerach obszarowych, czyli zamiast wielu, a w tym wypadku jest to nawet liczba ok. 100 odrębnych elektronicznych jednostek kontrolujących w obrębie pojazdu, zastępujemy je określoną liczbą czterech, pięciu takich zon kontrolerów. One również potrzebują spełniać taką rolę łatwej integracji komponentów hardware’owych z komponentami software’owymi. Więc tutaj też zaczynamy wkraczać trochę na taki koncept zwany middleware, czyli oprogramowania, które właśnie jest takim pośrednikiem i umożliwia bardzo łatwy, przystępny sposób integrowania poszczególnych komponentów na poziomie hardware’owym, jak i software’owym. 

 

Tutaj coraz bardziej noszę wrażenie, że rola software’u w automotive już jest duża, a pewnie będzie rosła. Wobec tego rośnie też rola i odpowiedzialność podmiotów, które zajmują się tworzeniem tego typu oprogramowania. Tutaj przedstawiając Ciebie, mówiłem, że już od wielu lat zajmujesz się właśnie tego typu działaniami, od ponad 6 lat w firmie ZF. Czy z tego, jak obserwujesz rynek, wynika, że koncerny motoryzacyjne tak wewnętrznie tworzą sobie tego typu działy, inżynierie programowania, które rozwijają ten software, czy też może raczej powstają specjalizowane firmy, które przejmują ten kawałek tortu?

 

Tutaj ten ekosystem jest dosyć złożony. Nie ma tutaj prostej odpowiedzi, czy prostej strategii. Na pewno koncerny motoryzacyjne, czyli tutaj te marki, które kojarzymy z pojazdami, tzw. OEM-s, oczywiście posiadają swoje działy rozwoju oprogramowania. Dodatkowo Firmy np. takie jak ZF, które są dostawcami komponentów, rozwiązań dla właśnie takich original equipment manufacturers, mają dedykowane działy R&D, które służą rozwojowi oprogramowania dla potrzeb pojazdów przyszłości, czy w tym wypadku Software Defined Vehicle. 

Mówimy tu też o pewnych poziomach tych dostawców, czyli mamy tzw. tier 1, tier 2 itd., w zależności od tego, jak oni są daleko od tego producenta. Ale to nie koniec, bo wszyscy tutaj wymienieni, czy takie wszystkie firmy, również posiłkują się firmami outsourcingowymi, czyli powstają firmy, które również specjalizują się w oprogramowaniu automotive i wypożyczają inżynierów do projektów realizowanych w tym celu. 

Są też firmy, które specjalizują się w opracowywaniu tej części software’u, która jest wspólna, uniwersalna dla zastosowań w automotive, ponieważ taka część wspólna istnieje i firmy producenckie szukają ułatwień. Wiadomo, że skorzystanie z takiego gotowca skraca nam czas opracowania rozwiązania i dostarczania go na rynek. Więc również są firmy, które specjalizują się w tego typu oprogramowaniu. 

Ale tak jak powiedziałem, ekosystem jest złożony i nie będzie zaskakujący jeśli wspomnę o tym, że również są startupy, które starają się wejść jakby w ten rynek, w ten sektor i uszczknąć kawałek tortu dla siebie. Co ciekawe, nawet firmy mocno osadzone w tym segmencie same powołują startupy po to, żeby zaangażować też społeczność do tworzenia nowych wizji, nowego typu oprogramowania właśnie na potrzeby software-defined vehicle, czy startupy z jednej strony, ale również np. rozwiązania typu open source. 

Myślę, że Eclipse wiele osób kojarzy ze środowiska oprogramowania jako firmę. Jest coś takiego np. jak Eclipse automotive powołany przez Eclipse Foundation, które zrzesza również firmy takie jak nasza w tym celu, aby opracować właśnie software bardziej od strony modularnej, takiej uniwersalnej, gotowej do tego, żeby stosować w pojazdach przyszłości. I jeszcze taka jednak dygresja, bo to może nie tylko dotyczyć software’u, który rzeczywiście jeździ w pojeździe, ale np. jest też wykorzystywany do produkcji komponentów, czyli mówimy tutaj o np. Open Manufacturing Platform, czyli coś, co umożliwia łatwiejsze, sprawniejsze produkowanie komponentów wykorzystywanych w pojazdach. 

 

To faktycznie rozszerza nieco ten zakres oddziaływania software’u na całą branżę automotive. Ale może spójrzmy na przykładzie firmy ZF, którą tutaj reprezentujesz. To jest już, można powiedzieć, gracz z ugruntowaną pozycją. Jakie miejsce ta firma zajmuje na tym rynku, o którym wspomniałeś? Jakie usługi, w jakich obszarach świadczy? 

 

Myślę, że tutaj z nieukrywaną satysfakcją mogę powiedzieć, że firma ZF jest wiodącym dostawcą usług na rynku automotive. Nasz wachlarz możliwości i portfolio jest tutaj dosyć szerokie. Jeżeli skupilibyśmy się tylko na tej części bliżej software’u, to ta wizja mobilności przyszłości to dla ZF w szczególności mowa o kompletnych systemach, które zarówno pod względem hardware’u, jak i software’u realizują określone funkcje w pojeździe. 

Ja mówię o przyszłości, aczkolwiek te systemy już istnieją i one są już w ofercie dostępne. Czyli taka implementacja idei See, Think, Act, czyli percepcja, analiza tych danych oraz uruchomienie odpowiednich funkcji w pojeździe. Do tego można dołożyć jeszcze inny zmysł, czyli jego substytut w postaci tutaj uszu, powiedzmy, czyli hear, ponieważ również tego typu produkty istnieją i pozwalają na to, żeby pojazd również słyszał to swoje otoczenie i mógł na przykład zareagować na syrenę pojazdu uprzywilejowanego. 

Następną kwestią może być łączność pojazdów, wspomniana wcześniej jako istotny aspekt rozwojowy, w celu wymiany danych związanej tutaj z szeroko pojętą analityką, w tym również z dużym naciskiem na rozwiązania typu Artificial Intelligence, więc tutaj działamy również mocno i prężnie. 

Efektywne zarządzanie energią. Tutaj może troszeczkę na innym gruncie przez chwilę, ale właśnie też bardzo widoczny trend, czyli elektromobilność. Dla nas istotne jest, aby też w pojeździe zarządzanie tą energią było, czyli jej magazynowanie, konwersja, optymalizacja zużycia była na wysokim poziomie. No i oczywiście te wspomniane wcześniej systemy nie mogą istnieć bez zaawansowanych sensorów takich jak kamery, radary czy lidary i elementach wykonawczych wszelkiego rodzaju, czyli coś np. związanego z hamowaniem, coś ze sterowaniem, coś związanego z amortyzatorami – czyli wszystko to, co wpływa też na komfort oraz funkcję bezpieczeństwa. 

I te wspomniane wcześniej high performance computing, platformy, czyli tutaj jesteśmy w tym momencie już, można powiedzieć, producentem najbardziej zaawansowanego komputera w tym momencie na rynku automotive oferowanego do tych zastosowań. 

Jeśli mogę trochę jeszcze dalej rozwinąć tutaj ten temat, te cele nadrzędne skupiają w takich obszarach technologicznych, nad którymi, i tutaj też coś bardzo wyraźne, rozpięty jest taki parasol w postaci digitalization and software, czyli to już pokazuje właśnie rolę software’u tak naprawdę w mobilności nowej generacji. I tu mówimy o autonomous driving, mówimy o właśnie electric mobility, o integrated safety – czyli również bezpieczeństwo pod względem pasywnym, jak np. poduszki bezpieczeństwa, poduszki powietrzne, pasy bezpieczeństwa, vehicle motion control, czyli  kontrola pojazdu, jego ruchu względem dowolnej osi tak naprawdę. 

O sensorach wspomniałem, o high performance computing wspomniałem, o platformie do połączenia wspomniałem. Możemy też wspomnieć właśnie o tym wcześniej sygnalizowanym middleware, czyli tym rozwiązaniu software’owym, służącym potrzebom integracji komponentów hardware’owych z software’owymi dla pojazdu definiowanego programowo. Ale nie zapominajmy też jeszcze o właśnie tych rozwiązaniach takich pomocniczych, można powiedzieć, służących podczas rozwoju produktu, czyli tutaj o rozwiązaniach wspomagających testowanie, walidację oraz tymi backendowymi, np. zarządzanie pojazdami. 

W tym momencie np. ZF już widząc tę przyszłość odległą, oferuje system zarządzania pojazdami autonomicznymi na poziomie miasta. Czyli jest to dosyć wszechstronny zakres naszej działalności, ale też bardzo już mocno ukierunkowany na właśnie tą ideę Software Defined Vehicle. ,

Te cele nadrzędne skupiają w takich obszarach technologicznych, nad którymi, i tutaj też coś bardzo wyraźne, rozpięty jest taki parasol w postaci digitalization and software, czyli to już pokazuje właśnie rolę software’u tak naprawdę w mobilności nowej generacji. I tu mówimy o autonomous driving, mówimy o właśnie electric mobility, o integrated safety – czyli również bezpieczeństwo pod względem pasywnym, jak np. poduszki bezpieczeństwa, poduszki powietrzne, pasy bezpieczeństwa, vehicle motion control, czyli  kontrola pojazdu, jego ruchu względem dowolnej osi tak naprawdę. 

 

Rozumiem. Myślę, że ta mnogość dziedzin jednoznacznie świadczy o tym, że ta branża będzie się jeszcze szybciej rozwijała pewnie. Ale myślę sobie, że ci ze słuchaczy, którzy zajmują się inżynierią oprogramowania, nie wybaczyliby mi, gdybym nie zapytał Cię, jakie języki oprogramowania, jakie technologie się na co dzień obecnie stosują do tworzenia oprogramowania w tej branży.

 

Tutaj też od razu zrobię taką klauzulkę: to zależy. Oczywiście jeśli mówimy tutaj o tym oprogramowaniu stricte jeżdżącym w pojeździe, kontrolującym rzeczywiście te elementy wykonawcze, czyli powiedzmy sobie, oprogramowanie wbudowane, to będziemy mówili tutaj o języku C, o języku C++. Są to wiodące języki oprogramowania w branży automotive i te języki są rekomendowane. Co więcej, istnieją pewnego rodzaju standardy ich użycia w naszej branży.

Aczkolwiek, oczywiście, to nie koniec. Możemy też wykorzystywać języki skryptowe, np. język Python. Najczęściej jako pomocnicze języki, chociażby w obszarze testów, ewentualnie przy algorytmach uczących, bo wiemy też, że Python zapewnia pewne biblioteki bardzo szeroko stosowane i przydatne, jeśli chodzi o machine learning.

Języki modelujące – myślę, że o tym też warto wspomnieć, czyli nie mówimy konkretnie w tym wypadku o programowaniu, ale o projektowaniu, bo to jest bardzo też istotna część i element produkcji takiego oprogramowania, czyli np. język SysML, czyli takie projektowanie systemu oraz UML, czyli projektowanie np. architektury oprogramowania. Czyli tutaj diagramy wszelkiego rodzaju wykorzystujemy.

Warto też wspomnieć, że oprogramowanie wbudowane może powstawać również jako model-based development, czyli tutaj narzędzia typu MATLAB, Simulink, wykorzystywane są do tego, aby tak naprawdę algorytm zaprojektować w postaci modelu, a kod wykonywalny jest generowany z takiego modelu i tego typu rozwój również prowadzimy.

Inne języki programowania, bardziej kojarzone z wysokim poziomem, zarówno do zastosowań frontendowych, jak i backendowych, również są wykorzystywane, ale tutaj mówimy bardziej o tworzeniu narzędzi wspomagających, proces tworzenia oprogramowania dla pojazdu, np. jakieś elementy wizualizacyjne danych, które pokazują to, co widzi ta kamera, czy co widzi ten radar faktycznie, jak on sobie tłumaczy tę informację z odbicia np. fali na ten świat, który otacza pojazd. Takie narzędzia również powstają.

I oczywiście nie zapominajmy o tym trendzie data analytics, data science czy w jakimś ujęciu ostatecznym sztucznej inteligencji, czyli dedykowane języki, tutaj np. język R, który służy chociażby mocno do zastosowań machine learningowych można wspomnieć.

 

Faktycznie zależy, ale weźmy to oprogramowanie, które, jak nazwałaś, jeździ w aucie, tworzone z wykorzystaniem C++. Myślę sobie, czy to jest jedyne wymaganie stawiane przed osobami chcącymi wejść do tej branży – znajomość języków oprogramowania – czy też może jakieś zaznajomienie z elektroniką, z przemysłem automotive też jest potrzebne, żeby w tej branży rozpocząć swoje działania?

 

Powiedziałbym, że jest to taka podstawa, która jest potrzebna i na pewno jest bardzo solidna do tego, aby wystartować, jeżeli ktoś jeszcze nie miał tutaj styczności. Natomiast wymagane byłoby w dłuższej perspektywie dobre zaznajomienie się również ze sferą sprzętową. Dlaczego? Ponieważ przy oprogramowaniu wbudowanego mówimy często też o takich niskopoziomowych aspektach, które jeżeli przychodzi do analizy jakichś błędów bądź przypadków problematycznych, wymagają po prostu użycia zaawansowanych narzędzi. Chociażby taki debugger.

U nas występuje często w postaci sprzętowej, która rzeczywiście ma dużo więcej funkcji zaawansowanych niż taki software’owy debugger. Również narzędzia laboratoryjne bardzo często są przydatne, więc taki inżynier oprogramowania systemów wbudowanych to w idealnym ujęciu jest ktoś, kto zarówno posiada wiedzę i umiejętności stricte programistyczne, jak i taką umiejętność wykorzystania rzeczywiście narzędzi wspomagających cały proces tworzenia.

To jest istotne właśnie z punktu widzenia tego oprogramowania wbudowanego. Co jeszcze różni, o czym warto wiedzieć, ewentualnie, tworzenie oprogramowania tutaj w naszym sektorze i tego typu oprogramowania, to są dosyć szczegółowo określone standardy, jakieś wymogi takie formalne, które muszą być spełnione.

I tu mówimy chociażby o takich wytycznych tworzonych przez gremia, takie jak np. MISRA. MISRA to jest Motor Industry Software Reliability Association, który wydał pewnego rodzaju zalecenia. Jak używać języka C czy języka C++, aby to oprogramowanie było bezpieczne, wiarygodne, niezawodne – w szczególności niezawodne. To jest nawet w samej nazwie tego gremium – reliability.

Tutaj dodatkowo w procesie tworzenia oprogramowania, wykorzystywanie narzędzi, które analizują ten kod pod względem jakości. Jakości takiej programistycznej mam na myśli, czy jest to taka statyczna analiza kodu, czy on jest zgodny z wytycznymi właśnie. Również elementy dynamicznej analizy kodu. Zanim przejdziemy tak de facto nawet do fazy testowania, to już takie elementy są wykorzystywane.

Tak jak mówię, to są też pewnego rodzaju obostrzenia, które nie pozwalają korzystać z pewnego rodzaju metod dostępnych w języku programowania, jak np. dynamiczna alokacja pamięci czy funkcje rekurencyjne. One są albo zakazane, albo nierekomendowane wręcz, ponieważ wiemy, że mogą być problematyczne. Właśnie, na czym nam głównie zależy, żeby to programowanie było bezpieczne, bo ono ma bezpośredni wpływ na życie człowieka w wielu przypadkach.

Sam proces tworzenia oprogramowania też jest dosyć szczegółowo opisany w standardzie. Tutaj np. możemy przywołać standard Automotive SPICE, czyli ASPICE w skrócie, czyli coś, co mówi, w jaki sposób procesowo podchodzić do rozwoju oprogramowania.

Również charakterystyka poszczególnych komponentów, czyli jeśli popatrzymy modularnie na oprogramowanie, niektóre moduły mogą być określone jako safety critical i tych poziomów krytyczności też jest kilka. Z każdym takim poziomem związany jest zestaw praktyk, które trzeba wykonać, aby udowodnić, że to oprogramowanie jest bezpieczne, jest pozbawione błędów.

Firmy takie jak nasza, np., aby móc sprowadzić taką działalność produkcji oprogramowania dla automotive, podlegają też audytom. Audytom pod kątem specyficznych wymogów, specyficznych certyfikatów, czyli potrzebujemy tak naprawdę certyfikatu, który potwierdza, że robimy to we właściwy sposób.

Z innej perspektywy bardzo ważnym zagadnieniem jest np. cyber security, czyli też spora działka, na której należy się skupić i zapewnić, że w niepowołany sposób nikt nie jest w stanie się dobrać do takiego komponentu elektronicznego i do oprogramowania w nim zawartego.

Jeśli chodzi o sprzęt jeszcze, to tutaj testowanie tego oprogramowania do poziomu, powiedzmy, unit testów w zasadzie nie potrzebujemy dodatkowego sprzętu. Jeżeli przechodzimy na testy funkcjonalne, dobrze jest, jeżeli pracujemy de facto na jakiejś próbce produktu, fizycznej, faktycznej próbce produktu. Aczkolwiek, czy wręcz jest to wymóg od pewnego etapu, czyli już, powiedzmy, testy kwalifikacyjne, czy testy systemowe, czyli kwalifikacyjne, software’owe, jeszcze posiłkują się też rozwiązaniami typu Virtual ECU, czyli mamy pewnego rodzaju symulowane środowiska. Ale już testy systemowe absolutnie działają tutaj na żywym sprzęcie. Jest to pewnego rodzaju inny świat, może taki charakteryzujący tutaj inżyniera oprogramowania i jego pracy z tymi produktami, ale niezmiernie też ciekawy, bo bardzo wszechstronny.

 

Czy ta specyfika, te wymogi, te standardy branżowe, o których wspomniałeś, powodują też, że inaczej podchodzi się do samego procesu wytwarzania oprogramowania? Np. czy ten dostęp do urządzeń fizycznych jest niezbędny na każdym kroku? Trochę o tym powiedziałeś, ale myślę, że dobrze byłoby porównać taką klasyczną branżę, jakakolwiek by to była, i automotive, jeśli chodzi o wytwarzanie oprogramowania. Czy są jakieś różnice?

 

Czyli chciałbyś tutaj nawiązać do np. metodyk, do tej strony takiej…

 

Tak, ale też testowanie, też naprawianie błędów, dajmy na to.

 

Dobrze, to zacznę od tych metodyk, bo to będzie prostsze, że tak powiem, krótsze, może do powiedzenia. Same metodyki, tak jak wspomniałem, z jednej strony są sugerowane przez pewnego rodzaju procesowe wytyczne, ale jak najbardziej też adaptujemy metodyki takie bardziej popularne, typu Scrum, czy ogólnie pojęty Agile, czy w tym wypadku jakieś Scalable Agile. Tak naprawdę podejście iteracyjne jest w zasadzie wymogiem współczesnych czasów, gdzie ten kontakt z klientem musi być bliski, musi być bieżący, musimy mieć ten feedback, musimy mieć tę informację zwrotną, czy idziemy w dobrą stronę, dostosowywać się itd. Ale też i w klasyczny sposób, kiedy mamy dobrze ugruntowane zbiory wymagań klienckich, tutaj nie musimy de facto postępować w ten sposób, możemy bardziej klasycznie skupiać się na swoich wybranych obszarach.

Pod względem testowania ważne, myślę, żeby wspomnieć, że w grę wchodzi np. tuningowanie algorytmów, czyli np. to oprogramowanie, które rozwijamy, może z jednej strony odpowiadać za podstawowe funkcje kontrolera, powiedzmy sobie taki system operacyjny, sterowniki, funkcje utrzymania tej platformy, monitoringu, diagnostyki. I to, można powiedzieć, nie wymaga takiego różnorodnego dostosowania do konkretnej platformy, do konkretnego pojazdu. Ale np. algorytmy wykonujące czy realizujące już takie funkcje zauważalne, powiedzmy te funkcje typu trzymanie się pasa ruchu, czy hamowania awaryjnego, czy funkcja rozpoznawania znaków. Takie rzeczy dosyć często wymagają fizycznego sprawdzenia, czy to działa tak, jak powinno w tym konkretnie pojeździe.

I tutaj np. możemy wspomnieć o tej kalibracji, o testach na torze testowym, czyli mamy też flotę pojazdów testowych, które wykorzystywane są do tego, aby sprawdzić, czy ten software opracowany działa tak, jak powinien. Albo rzeczywiście go stuningować odpowiednio, żeby to hamowanie było np. we właściwym momencie po prostu rozpoczynane, żeby nie za wcześnie, nie za późno np. zatrzymać się przed tym pojazdem ostatecznie.

Duże są wymogi, jeśli chodzi o testowanie oprogramowania pod kątem różnych przypadków, więc jest tutaj mowa o np. jazdach już poza torem testowym, czyli jazdach w prawdziwym terenie, po prawdziwych drogach w warunkach rzeczywistego ruchu drogowego. I tutaj jak najbardziej też takie elementy muszą występować. To są wymogi stawiane też przez naszych klientów.

I tutaj też jest taki ciekawy aspekt właśnie poszukiwania usprawnień, optymalizacji, aby starać się digitalizować pewnego rodzaju procesy testowania, aby minimalizować potrzebę fizycznego wyjeżdżania np. na drogi. To może przynieść oczywiście określone oszczędności czasu, a przez to oczywiście też środków finansowych. Mam nadzieję, że odpowiedziałem na pytanie.

 

Tak, tak. Myślę, że w dużym stopniu na pewno tak. Oczywiście ta branża ma swoją specyfikę, co na pewno musi wpływać na to, w jaki sposób wytwarza się oprogramowanie, w jaki sposób się testuje itd., ale chociażby poprzez to podejście zwinne, o którym wspomniałeś, też widać, że to nie jest tak, że to jest zupełnie osobna gałąź inżyniery programowania, tylko faktycznie te procesy są w dużym stopniu zbieżne i wyglądają podobnie, tak jak w innych tutaj dziedzinach.

Tak sobie myślę, że w powszechnej świadomości związek motoryzacji z informatyką jest głównie driveowany przez samochody autonomiczne. To o tym się pewnie najwięcej mówi, to trafia do tego przysłowiowego mainstreamu. Chciałbym Cię zapytać, czy to jest jedyny związek, który będzie się tak szybko rozwijał w przyszłości? O jakich perspektywach rozwoju możesz powiedzieć?

 

Na pewno autonomiczność to nie jedyny powód obecnego i przyszłego rozwoju, jeśli chodzi o pojazdy. Wymieńmy chociażby pojazdy elektryczne, czyli elektromobilność. Na tę chwilę to jest w zasadzie dominujący trend w naszym sektorze.

Również wspomniana wcześniej łączność, czyli ogólnie pojęte connectivity, samochód jako urządzenie sieciowe. Czyli idea taka Always Connected. Przykładowy scenariusz, gdzie samochód wykorzystywany jest również do monitorowania sytuacji drogowej. Czyli to nie tylko to z punktu widzenia takiego użytkownika, który używając smartfona, wsiadając do samochodu, chce, aby ten kontakt z tym internetem, możliwość korzystania z aplikacji była podobna, porównywalna, w każdym razie nie odcinamy się w momencie, kiedy siadamy za kółkiem, to jest jeden aspekt, ale właśnie – te dane, które są gromadzone i przesyłane, analizowane, mogą być również wykorzystywane w innych celach, czyli to Connectivity daje nam możliwość np. monitorowania sytuacji drogowej.

I nie tylko tutaj pod kątem np. niebezpiecznych zatorów, które tworzą się w jakichś miejscach dróg, np. za zakrętem, i tego jeszcze kierowca nie widzi, a warto, aby jego pojazd już to wiedział, ale też np. jakości nawierzchni, czyli dziury w drodze, czyli oblodzenie nawierzchni drogowej, dane z czujników, zawieszenia w tym wypadku, są procesowane jakoś wstępnie w pojeździe, potem są przesyłane do chmury, procesowane i rozsyłane do innych pojazdów. Dzięki temu poprawia się komfort podróżowania i oczywiście zwiększa się bezpieczeństwo podróżowania.

Czyli ja tutaj już tak nawiązuję mocno do tej idei Vehicle to anything, czyli jeżeli spotkacie się z takim skrótem V2X, to tak naprawdę dotyczy kontaktu, komunikacji samochodu z otoczeniem szeroko pojętym, czyli connectivity w skrócie.

Co jeszcze może wpływać na ten związek? Jest tych rzeczy naprawdę kilka. Powiedzmy symulacja i taki koncept digital twin, czyli perfekcyjne odwzorowanie pojazdu lub jego poszczególnych elementów w postaci cyfrowej. Mówimy tutaj o elementach mechanicznych czy elektrycznych, elektronicznych, software’owych – po to, aby być w stanie badać taki pojazd lub jego element, na różne sposoby, w tym symulowanym środowisku, który jak najbardziej oczywiście oddaje to środowisko naturalne, i dzięki temu przyspieszamy proces developmentu.

To jest takie cyfrowe prototypowanie, można powiedzieć. Tutaj również taka koncepcja Lean Validation, czyli możliwość w pewnym sensie walidowania produktów, które jeszcze fizycznie nie powstały. Bardzo też potrzebny trend i tutaj związek jak najbardziej z IT będzie umacniany.

Kolejny, już też wielokrotnie wspominany aspekt, data driven, czyli zbieranie danych właśnie, karmienie algorytmów uczących i wykorzystywanie ich do różnych celów. Bardzo nośny związek, znowu taka specyficzna działka, która tutaj się dosyć prężnie musi rozwijać. Wspomniane narzędzia testowania, weryfikacji, które wspomagają ten proces bez potrzeby fizycznych jazd samochodem de facto. Wspomniany również wcześniej trend, czyli mega istotny aspekt cyber security.

Tutaj wręcz również istnieją pewnego rodzaju standardy. Jest taki standard ISO SAE 21434, to jest Road Vehicle Cyber Security Engineering Standard. pokazuje to jakby samo przez się, że ten aspekt musi być rozwijany i tutaj związek z IT szeroko pojętym jest niezbędny.

Inne takie pomniejsze, ale nie mniej ważne jakby rzeczy, które mi przychodzą do głowy, to np. predictive maintenance, czyli taki aspekt przy zarządzaniu właśnie flotą pojazdów, czyli to nie jest żadna funkcja komfortu, to nie jest żadna funkcja widoczna bezpośrednio przez użytkownika. Ale to, że sensory potrafią zgłaszać swój poziom zużycia, czy jakieś związane z tym aspekty, może się przyczynić do tego, że taki pojazd jest wezwany, w cudzysłowie, na przegląd czy do warsztatu z odpowiednim wyprzedzeniem, zanim coś złego się rzeczywiście w nim wydarzy.

Zapomniałbym wspomnieć oczywiście o Safety Regulations ponownie, czyli trend, tak naprawdę to, co nam legislacja przynosi, czyli ten katalog sytuacji, na które pojazd ma być gotowy, aby zabezpieczyć kierowcę – to z jednej strony. Z drugiej, innych użytkowników ruchu, czyli np. tego pieszego czy rowerzystę. To jest cały czas rozszerzane, te nowe scenariusze muszą być pokrywane. Oczywiście to wymaga rozwoju, również pod kątem jak i elektronicznym, tak i oprogramowania. Sztuczna inteligencja, shared mobility, to są takie rzeczy również tutaj mające wpływ.

Może taka rzecz jeszcze mało intuicyjna, ale odpowiedzialność środowiskowa, czyli to, że tworzymy pojazdy w taki sposób, aby jak najmniej ingerować w naszą planetę, mówię w sensie negatywnym. Tak więc tutaj też rozwiązania IT są bardzo pomocne.

Jakbym chciał to wszystko pod jakiś jeden parasol zebrać, to ogólnie rozwój idei mobilności nowej generacji, czyli to wszystko, co ma wpływ na to, jak postrzegamy i chcemy podróżować w przyszłości, nie będzie istniało bez rozwiązań IT.

Kolejny, już też wielokrotnie wspominany aspekt, data driven, czyli zbieranie danych właśnie, karmienie algorytmów uczących i wykorzystywanie ich do różnych celów. Bardzo nośny związek, znowu taka specyficzna działka, która tutaj się dosyć prężnie musi rozwijać. Wspomniane narzędzia testowania, weryfikacji, które wspomagają ten proces bez potrzeby fizycznych jazd samochodem de facto.

 

Czyli bardzo szeroka paleta związków IT z motoryzacją, a dzisiaj o pojazdach definiowanych programowo opowiadał Radosław Pełka z firmy ZF.

Radku, bardzo Ci dziękuję za to spotkanie.

 

Dziękuję ślicznie również i zachęcam do śledzenia trendów zmian na rynku automotive. Są naprawdę imponujące i zaskakujące być może.

 

Przyłączam się do tego wyzwania. A powiedz jeszcze, gdzie Cię możemy znaleźć w internecie, gdzie możemy ewentualnie słuchaczy odesłać.

 

Myślę, że takim najprostszym sposobem będzie LinkedIn, mój profil na LinkedInie. Jeżeli ktoś ma życzenie, zachęcam do kontaktu. Myślę, że łatwo mnie tam znaleźć.

 

Oczywiście link będzie w notatce do odcinka.

Radku, jeszcze raz bardzo dziękuję. Miłego dnia, trzymaj się. Cześć!

 

Dziękuję, cześć!

 

I to na tyle z tego co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz, lub w social mediach.

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o pojazdach definiowanych programowo.

Zapraszam do kolejnego odcinka już wkrótce.

Cześć!