Kod, algorytmy i cztery koła: technologia w automotive

Łukasz Okoń
Możemy sobie wyobrazić taką sytuację, że mamy jakieś skrzyżowanie. To skrzyżowanie nie posiada takiej sygnalizacji świetlnej. Dlaczego? Ponieważ samochody łącząc się ze sobą, a także ze skrzyżowaniem, skrzyżowanie może mieć jakiś access point, do którego samochód się połączy, zbliżając się do niego i on jest swoistym kontrolerem ruchu dla tego skrzyżowania. Można to porównać do kontrolera ruchu samolotów. Jest nadzorca skrzyżowania, który wysyła samochodom trajektorię, po której muszą się poruszać, żeby dotrzeć do celu, co może zwiększyć przepustowość takiego skrzyżowania. Samochody mogą jechać szybciej, mijać się na centymetry, ponieważ ich ruch jest z góry przewidziany. I taka mapa rozładowania takiego skrzyżowania może działać dużo wiele efektywniej aniżeli to, co mamy teraz.

Szymon Głowania
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!

Łukasz Okoń
Cześć, witam was wszystkich na naszym podcaście. Tutaj Łukasz Okoń i Paweł Kmiecik. Cześć Paweł.

Paweł Kmiecik
Cześć Łukasz. Nazywam się Paweł Kmiecik. Z wykształcenia jestem inżynierem automatyki i robotyki. W branży automotive obecnie posiadam ponad cztery lata doświadczenia, głównie w obszarach testów software i walidacji, jak i również rozwoju środowisk testowych i tworzenia symulacji do tych środowisk, co często jest nieodłączną częścią testów w obecnych czasach.

Łukasz Okoń
Nazywam się Łukasz Okoń, też pracuję od niedawna w Capgemini. Jestem architektem oprogramowania systemów budowanych dla branży automotive. Moja historia zaczęła się na studiach, skończyłem teleinformatykę na Politechnice Śląskiej i w ramach ciekawostki mogę Wam powiedzieć, że kończąc te studia, nigdy nie chciałem programować, nigdy nie chciałem się zajmować oprogramowaniem. Aczkolwiek po rozpoczęciu kilku takich moich własnych projektów jednak gdzieś udało mi się zaczepić w pracy dla takiej małej firmy, która zajmowała się systemami budowanymi na potrzeby przemysłu. Okazało się, że jednak to jest ciekawy temat i okazało się, że to jest jednak to, czym chcę się w życiu zajmować.
W tej pracy spędziłem kilka lat, po czym przeszedłem do kolejnej firmy, tym razem w branży automotive, co spowodowało, że poznałem ten świat od drugiej strony. I ten świat chcielibyśmy dzisiaj z Pawłem zademonstrować. Każdemu inżynierowi, który może zastanawia się nad tym, powiemy trochę więcej o tej motoryzacji, o pewnych słowach kluczach, których możecie się spotykać podczas takiej pracy lub poszukiwania takiej pracy w ofertach. I też myślę, że pokażemy z Pawłem, że ten świat jest bardzo fajny i ciekawy i nie tylko jest wyzwaniem, ale też możliwościami, które się przed wami otworzą, gdybyście zechcieli w takim projekcie kiedyś wystartować.

Paweł Kmiecik
Mamy nadzieję, że przedstawimy to w bardzo jasny i klarowny sposób, pomimo czasami zawiłości. Dany temat może wydawać się taki bardzo obcy, aczkolwiek postaramy się go przedstawić w bardzo łatwy i przystępny sposób.

Łukasz Okoń
Przede wszystkim może czym zajmują się projekty automotive i na co kładzie się taki największy nacisk? Czym zajmują się dzisiejsze koncerny i z jakimi projektami możecie się spotkać podczas Waszej przygody z automotivem? Przede wszystkim, czym zajmują się tacy inżynierowie, to jest jeden ważny taki aspekt dotyczący tworzenia oprogramowania, którym jest bezpieczeństwo. Każdy z nas chce jeździć samochodami, które są bezpieczne, poruszać się z punktu A do punktu B w taki sposób, który pozwoli nam na to, żebyśmy się czuli bezpiecznie.

Paweł Kmiecik
Tutaj też warto dodać, że rozpatrujemy to pod dwoma względami. Jakby najpierw ten sprzęt, który jakby jest fizycznie w samochodzie, który musi być niezawodny i działać w każdych okolicznościach. Natomiast drugą jakby stroną medalu jest oprogramowanie, jakiś algorytm, software czy aplikacja, która steruje daną funkcjonalnością samochodu. Postaramy się dzisiaj to właśnie też od tej strony bardziej opisać jak takie algorytmy są rozwijane oraz jak duży aspekt kładzie się na bezpieczeństwo tych algorytmów oraz jak są testowane, co jest moim też konikiem, jeśli tutaj chodzi o te tematy techniczne.

Łukasz Okoń
Paweł, wymyśla nam sposoby na to, jak zepsuć to, co co deweloperzy stworzyli, jak architekci zaprojektowali, szuka case’ów, o których moglibyśmy zapomnieć, po to, żeby produkt, który zostaje wprowadzony na rynek, był w pełni bezpieczny. Ja cały czas będę się obracał gdzieś w tym temacie bezpieczeństwa, ponieważ on ma wiele aspektów, nie tylko w automotivie, ale też w różnych innych branżach. Możecie usłyszeć, gdybyście chcieli kiedyś się zajmować projektami motoryzacyjnymi, o czymś takim, co się nazywa ASIL. ASIL to jest tak naprawdę norma, która reguluje, w jaki sposób powinniśmy zaprojektować oprogramowanie, tak żeby one były stosunkowo bezpieczne. Dane funkcje mają przypisane tzw. poziomy ASILów, bądź też bez tego poziomu, jeżeli ta funkcja nie wpływa na bezpieczeństwo i zdrowie użytkowników i w ten sposób projektujemy oprogramowanie zgodne z tymi wytycznymi. Dodatkową taką normą, która również opowiada o tym, jak taki development powinien wyglądać, o czym projektanci powinni myśleć, jest norma ISO 262 i ona właśnie pozwala nam na to, żebyśmy mogli mieć jakąś pewność, że to, co zrobiliśmy, jeżeli zrobiliśmy to zgodnie z tymi normami, dołożyliśmy wszelkich możliwych starań do tego, aby nasza funkcjonalność działała poprawnie, możemy właśnie tymi wytycznymi się gdzieś tam po drodze posługiwać. Mówimy tutaj o bezpieczeństwie, ale to bezpieczeństwo w dzisiejszych samochodach jest podzielone na dwa tematy: tematy safety i tematy cyber security.
Może zaczniemy od tych pierwszych. Pewnie wielu z was słyszało taki przykład, w branży lotniczej problem konstrukcyjny, który się wydarzył, a mianowicie w pewnej linii samolotów postanowiono zmienić silniki na bardziej oszczędne, pasażerskich dosyć dużych samolotów. Zmieniając te silniki zmieniła się trochę charakterystyka lotu tego samolotu, przez co samolot miał tendencję do podnoszenia nosa podczas lotu, czyli do wspinania się na wysokość. Żeby piloci dalej mieli komfort pilotowania takiego samolotu, żeby nie nastręczało to żadnych problemów, dana firma wymyśliła sobie, że zastosuje oprogramowanie, dodatkowo funkcjonalność w oprogramowaniu, które automatycznie będzie korygować ten kąt nachylenia dziobu samolotu w zależności od tego, jaki jest aktualny kąt.
I ten aktualny kąt był pobierany z takiego czujnika, czujnika kąta nachylenia samolotu. Niestety tutaj zawiodły procedury bezpieczeństwa, sposób prowadzenia takiego developmentu i całą tą funkcjonalność oparto na czujniku, który nie jest zbytnio bezpieczny, tzn. ten czujnik jest jeden i on ma tendencję do uszkadzania się, np. podczas startu, po uderzeniu w jakieś ptactwo lub na dużych wysokościach do zamarzania, czyli przestaje mierzyć nam poprawnie dany kąt, co automatycznie przekłada się na błędną regulację tej wysokości. Niestety sytuacja ta doprowadziła do wielu katastrof, skończyło się dosyć dużym śledztwem i firma na pewno miała z tego powodu duże problemy z racji tego, że też wiele osób zginęło w takich katastrofach.
Jak więc widzimy, te tematy bezpieczeństwa są niezwykle istotne nie tylko w branży automotive, ale w każdej innej branży, w której ludzie są narażeni na utratę zdrowia i życia, a w automotive bardzo dużą rolę przykłada się właśnie do takich tematów. Ja tutaj nie chcę teraz straszyć, że dokładając jakąś funkcję, będziemy powodować jakieś zagrożenie dla tych ludzi, nie, nie, nie. Te normy, o których wspomniałem, a także dobre praktyki, które główni producenci samochodów mają wypracowane, pozwalają na to, że każda funkcjonalność jest sprawdzana na wielu poziomach. Ta pewność oprócz samej analizy i developmentu, czyli ta walidacja powoduje, że ta wielopoziomowość powoduje, że zanim taki samochód wyjedzie na drogi, musi przejść wiele testów, zaczynając od testów software’owych przez testy na hardware, w pojeździe, w platformie, tysiące godzin, które samochód musi wyjeździć na torze, zanim ten wejdzie do produkcji seryjnej, powoduje, że też jako inżynierowie jesteśmy trochę chronieni przed tą ewentualnym pomyłką, że z naszego powodu komuś się coś stanie.

Paweł Kmiecik
Ja chciałbym tylko dodać tutaj, że właśnie jeśli wspomniałeś o tych ASIL-ach, to tutaj rozpoznajemy kilka leveli, dokładnie cztery, oznaczone literkami od A do D. I właśnie każdy z tych leveli tego ASIL-a też definiuje nam to, w jaki sposób dany system powinien być zaprojektowany, jeśli chodzi o bezpieczeństwo. Tutaj mam na myśli takie stwierdzenia, czy takie pojęcia jak mitygacja czy np. redundancja. Jeśli chodzi o mitygację, to np. robiąc jakiś dany algorytm lub projektując jakiś dany układ zawsze musimy wziąć pod uwagę w jaki sposób on działa i jaki jest skutek jego działania i co się stanie w przypadku kiedy ten algorytm przestanie działać lub zgłosi jakiś krytyczny błąd.
Wtedy w najlepszym wypadku możemy po prostu ten system wyłączyć, ten algorytm wyłączyć. Aczkolwiek w niektórych przypadkach, tak jak np. Łukasz wspomniał, przypadek z branży lotniczej, no nie możemy do tego dopuścić, żeby taki system wyłączyć, no bo skutki są katastrofalne. I tutaj mam na myśli albo ludzkie życie, albo możemy też, jeśli mówimy o branży samochodowej, no to akcji serwisowej, tak? Że producent samochodu wypuści nowe auto na rynek z jakimś błędem, który jest niepoprawnie mitygowany. No i mamy dużą akcję serwisową i to są często koszty horrendalnie duże, tak? A więc tutaj jakby właśnie ten ASIL i ta norma ISO262 definiuje nam to po prostu w jaki sposób powinniśmy to rozwijać.
I często właśnie jeśli mówimy o samej aplikacji też decydujemy się na jakiś taki poziom redundancji, a więc projektując jakiś dany układ możemy na przykład równolegle dointegrować algorytm lub też tutaj sprzęt, czyli mam na myśli tutaj dodatkowy procesor, który działa nam równorzędnie z tym pierwszym tak zwanym masterem i w momencie kiedy jeden procesor lub jakiś komponent czy to algorytm przestanie działać no to ten drugi przejmuje pracę i jesteśmy w stanie wyjść z tej sytuacji krytycznej. I to wszystko trzeba właśnie wziąć pod uwagę w procesie projektowania. Aczkolwiek tak jak Łukasz wspomniał, no te systemy często są na tyle złożone i duże, czy mówimy tutaj o branży lotniczej pewnie też, ale głównie o automotive, że te testy są rozbite na bardzo wiele poziomów i każdy poziom sprawdza coś innego na innym jakby stopniu szczegółowości, żeby właśnie nie było takiej sytuacji, że budujemy piętnaście algorytmów czy tam tysiąc, bo zakładam, że taka liczba nawet może dojść w samochodzie jeśli mówimy o algorytmach i integrujemy, czyli łączymy je wszystkie w jedno oprogramowanie i testujemy.
No bo to raczej się nie uda i złożoność tych systemów jest z reguły ogromna, dlatego często rozbijamy je na różne testy, o czym może też powiemy w późniejszej części podcastu.

Łukasz Okoń
Zgodzę się w 100% z Pawłem. Z tego co mogę dodać, jeszcze te dwa terminy redundancja i mitygacja. Tutaj redundancję Paweł dosyć dobrze opisał. Natomiast jeżeli mówimy o mitygacji, to są zabiegi software’owe lub hardware’owe, które zwiększają nam dostępność danej funkcji, czyli pomimo, że w danej funkcji jakiś element doświadczył krytycznego błędu, to mimo to mamy sposoby i techniki wypracowane, które pozwalają nam dalej utrzymać tę funkcję w działaniu, czyli np. mamy jakąś sytuację, która wymaga od nas jakichś pomiarów, jakichś sensorów, no i ten sensor jest zwielokrotniony, czyli tutaj zastosowano redundancję, nadmiarowość. Jest kilka sensorów, które mierzą taką samą wielkość.
No i w momencie utraty jednego z nich, gdy mamy kilka takich sensorów, możemy sobie stwierdzić, że ten jeden się zepsuł, to korzystamy z tych wartości, które są nadal prawdziwe. Więc to jest taka trochę definicja wyjaśnienia tej mitygacji, a także tej redundancji, o której też Paweł wspomniał. Drugim przykładem, który chcielibyśmy poruszyć, jest temat cyber security. Praktycznie każdy samochód ostatnimi laty wypuszczany do seryjnej produkcji jest już w pełni skomunikowany ze światem zewnętrznym poprzez łącze GSM, przez też inne media transmisyjne, które nam pozwalają połączyć się z internetem, bądź też z innymi usługami, a także możliwość ingerencji zewnętrznej w oprogramowanie i działanie samochodu wymusiło na producentach pewnych mechanizmów, które uniemożliwiają taką niechcianą ingerencję.
Przykładem takiego naruszenia takiej ingerencji możecie sobie państwo obejrzeć w takim portalu wideo na YouTube bezpośrednio po prostu, gdzie grupa inżynierów połączyła się za pomocą kontrolera popularnej konsoli do gier z samochodem poprzez magistralę CAN, czyli taką magistralę, która komunikuje różne elementy w samochodzie, poprzez złamanie wiadomości, które są wymieniane na tej magistrali i za pomocą tego kontrolera z tylnej kanapy mogły sobie sterować samochodem. Czyli siedząc na tylnej kanapie samochodu i mając pada, którym mogą kierować samochodem. Wiadomo, że tutaj musiało dojść do jakiegoś naruszenia, rozkodowania tych wiadomości itd. Natomiast to znaczy, że te wiadomości nie zostały odpowiednio zaszyfrowane.
Czyli wszystkie magistrale, które wymieniają informacje pomiędzy urządzeniami w samochodzie, które wymagają pewnych poziomów bezpieczeństwa, tutaj wracamy znowu do tego ASILa, czyli umożliwiają nam jakąś ingerencję w tym samochodzie, muszą zostać w jakiś sposób zaszyfrowane. I to jest druga taka branża, oprócz samego safety, czyli tzw. cyber security, w którym inżynierowie też muszą się gdzieś tam wykazywać i myśleć o tym podczas projektowania algorytmów, a także oprogramowania w samochodzie.

Paweł Kmiecik
Bardzo fajny przykład podałeś i od razu nasunęło mi się na myśl system KeyLess tak zwany, czyli otwieranie jakby samochodu zdalnie, jeżeli wykryjemy, że użytkownik danego kluczyka jest blisko i wysyła sygnał do otwarcia auta. W poprzednich latach było mnóstwo przypadków kradzieży tych samochodów i to jest też idealny przykład jak możemy zbudować dobry algorytm, dobre rozwiązanie, które działa i jest przetestowane. Aczkolwiek znalazła się grupa ludzi, po prostu złodziei, którzy po prostu chcieli to wykorzystać. No i stworzyli oprogramowanie do oprogramowania, tak? Czyli coś, co potrafi ten sygnał z kluczyka skopiować, następnie go wzmocnić no i otworzyć taki samochód zdalnie.
I to też właśnie pokazuje jak bardzo musimy szeroko patrzeć jeśli rozwijamy jakąś technologię, którą wypuszczamy do samochodów. No i tak jak Łukasz wspomniał, tutaj kwestia tylko security engineers tak zwanych i po prostu zabezpieczenia tych algorytmów czy tych rozwiązań jakimś szyfrowaniem dodatkowym. No jest to niewątpliwie ciężka działka. No bo tutaj jakby ścigamy się, że jakby technologia musi być ponad technologią, czyli ktoś coś wymyśla, a ktoś myśli, jak to złamać. I tutaj jest cały właśnie dylemat tego cyber security z mojej strony przynajmniej patrząc.

Łukasz Okoń
Może odejdziemy trochę od tematu bezpieczeństwa, cyber security, powiemy też o ciekawych innych aspektach pracy w automotivie. Jak już wspomniałem, główne projekty, którymi zajmują się producenci samochodów są bardzo duże i stosunkowo skomplikowane. Przez to są to projekty globalne. Z racji tego, że to są globalne projekty, możemy mieć możliwość wyjazdu do krajów, w których te projekty się odbywają poprzez jakieś konsultacje, jakieś konferencje techniczne itd. W których będziemy lub będziemy mogli uczestniczyć, co też daje nam możliwość takiego podróżowania, daje nam możliwość poznawania nowych kultur, ludzi, nie tylko właśnie przez komunikatory internetowe, ale tak na żywo. Więc te projekty też dają nam właśnie taką możliwość.

Paweł Kmiecik
Jeżeli mówimy też o poziomie skomplikowalności branży automotive, jak na początku szukałem pracy, widziałem różne oferty pracy i przerażały mnie niektóre stwierdzenia dodatkowe i właśnie chciałem się o nie dopytać, w jaki sposób byś je opisał dla osoby, która być może nie jest w branży. Tutaj mam na myśli takie stwierdzenia jak Aspice i Autosar. Czy mógłbyś bardziej rozwinąć te pojęcia?

Łukasz Okoń
Aspice to tak naprawdę jest opis procesu wytwarzania, produkcji, w jaki sposób powinniśmy projektować, testować, po prostu przejść cały proces, który umożliwia nam przejście od pomysłu do realizacji. Zapisane są tam wszystkie etapy, które np. cały zespół, którym oprogramowanie jest wytwarzane, bo to nigdy nie jest jedna osoba, to są zawsze zespoły, które muszą najpierw przeanalizować wymagania dotyczące danej funkcjonalności, zaprojektować odpowiedzi systemowe, przejść przez przypadki możliwe użycia tych funkcjonalności, tych feature’ów. Później trzeba zaprojektować architekturę, architekturę trzeba zaimplementować, trzeba ją przetestować na wszystkich poziomach testów. No i Aspice tak naprawdę to jest opis wszystkich etapów, które musimy przejść po to, żeby mieć pewność, że dane oprogramowanie zostało wykonane zgodnie ze sztuką, poprawnie i jest duża doza prawdopodobieństwa, że nie będzie z tym oprogramowaniem problemów.
Więc tak samo jak poprzednie normy, o których mówiliśmy, Aspice jest dokumentem, który chroni nas, chroni firmy, inżynierów od tego, żeby nie popełniali błędów. Tak naprawdę cały czas poruszamy się w kwestii tego bezpieczeństwa, ponieważ ono jest zawsze najważniejsze i dlatego tworzą się takie standardy, normy, dokumenty, które mają chronić nas przed ewentualnymi pomyłkami, chronić ludzi przez to, tak? Dla ich zdrowia i życia. A jeżeli mówimy o drugim słowie zagadkce, o którym Paweł tutaj wspomniał, czyli Autosar, można rozwinąć ten skrót, jest to Automotive Open Software Architecture. To jest architektura, która umożliwia nam poprzez jej strukturę tworzenie oprogramowania dla potrzeby motoryzacji.
Jest to oprogramowanie otwarte, jego części projektują w konsorcjum wiele firm, między innymi producentów samochodów oraz inne firmy zewnętrzne. Ma dosyć bardzo bogatą historię. Praktycznie w każdym samochodzie, którego używacie, ten Autosar widnieje, a on się dzieli na takie dwie podgrupy. Jest to Autosar Adaptive i Autosar Classic. Różnią się strukturą. Autosar Classic ma strukturę warstwową, która wymusza na architektach oprogramowania wykorzystanie jej, a dzięki temu standaryzuje development. Pozwala używać funkcji, które już są zaprojektowane przez te konsorcjum, używać ich ponownie dla nowych projektów, tak żeby nie musieć wynajdywać za każdym razem koła na nowo, co też zwiększa efektywność takiej pracy.
Drugą odmianą Autosaru jest Autosar Adaptive. Nie ma struktury warstwowej, ale dzięki temu pozwala nam na dynamiczne tworzenie funkcjonalności w systemie, osadzanie dynamiczne, osadzanie funkcjonalności w systemie, przez co jest bardziej otwartym środowiskiem na jakieś update’y, na jakieś dokładanie funkcjonalności. Jest bardziej elastycznym systemem niż ustrukturyzowanym, tak jak Autosar Classic, ale też ma inne, powiedziałbym, use case’y, a po polsku przypadki użycia. Autosar Classic wykorzystuje się często w projektach, które wymagają od nas tzw. real-time opration, czyli operowania w czasie rzeczywistym na częstotliwościach dosyć wysokich, czyli takie, które regulują nam jakieś procesy, np. sterownik silnika, w którym muszą być obliczane dawki paliwa, w zależności od sensorów, które są podłączone do tego sterownika, takim jak wspomaganie kierownicy elektrycznej.
Jest wiele takich przykładów, w których ten Autosar Classic ma bardzo dużo zastosowań, natomiast Autosar Adaptive wykorzystuje się w funkcjach, które nie mają takich zależności, czyli np. w infotainmencie, czyli np. w naszym radiu, jakimś kokpicie, sterowaniu, który ma nam wyświetlać parametry i to, czy funkcja wykona się w ciągu kilkunastu mikrosekund czy kilkunastu milisekund, nie robi tak naprawdę żadnej różnicy dla nas jako użytkowników tego samochodu, bo nawet nie jesteśmy w stanie zauważyć tej różnicy. Więc dla takich projektów używamy wtedy Autosar Adaptive, a dla tych, które wymagają krytycznego czasu wykonania, używamy wtedy Autosar Classic.

Paweł Kmiecik
Jedyne co bym też dodał tutaj do Aspice’a, że jakby jest to o tyle pojęcie złożone, że wynika jakby z z rozwijania algorytmów w branży automotive. Mam tutaj na myśli V-model, że jakby rozwijamy oprogramowanie w strukturze tzw. V-modelu. To jest jeden właśnie ze sposobów, w jaki podchodzimy do projektu i właśnie złożoności. Tam jest bardzo dużo kroków. Też nie będę się w to za bardzo zagłębiał, aczkolwiek każdy z tych kroków poprzez analizę wymagań, potem projekt systemu, jakieś porady architektury i potem możemy jeszcze to rozbić na jakieś moduły. I w końcu jeśli mamy zdefiniowane co chcemy osiągnąć, jak to ma wyglądać, jakie ma spełniać wymagania, Przechodzimy do tej fazy kodowania, a potem jest ta faza testów, które też są rozbite na wiele poziomów.
Tutaj mamy jeszcze jakieś testy jednostkowe, testy integracyjne, jak już łączymy wiele komponentów, większy algorytm. Następnie testy całe systemowe no i potem już testy na finalnym obiekcie, czyli tutaj mam na myśli pojazd, tak? A więc złożoność tego procesu właśnie definiuje to, w jaki sposób podchodzić do projektu i właśnie Aspice nam o tym mówi, w jaki sposób powinniśmy to robić. Natomiast jeśli mówimy też o Autosarze tutaj mam wrażenie, że też wynikało to, jeśli patrzymy na podwalinę tego Autosara, to wynikało to z problemu takiego, że producenci aut mieli bardzo wiele jednostek tzw. ECU Electronic Control Unit i jakby każdy producent tutaj ma na myśli na przykład światła, wycieraczki, kierownica, tak?
No tutaj każdy producent dostarczał osobne oprogramowanie i trzeba było znaleźć jakiś taki wspólny standard właśnie architektury, żeby te komponenty mogły ze sobą potocznie mówiąc porozmawiać, tak? Czyli po prostu, żeby mogły się ze sobą komunikować i żeby jakaś jednostka sterująca nadrzędna mogła podejmować decyzje na poziomie właśnie samochodu. Także tutaj nic dodać, nic ująć w tym temacie Łukaszu. 

Łukasz Okoń
Przechodząc do kolejnego takiego pojęcia, z którym możecie się spotkać w skrócie MBD, rozwijając ten skrót, to jest Model-Based Design. Jest to dosyć szeroko używana praktyka w tworzeniu oprogramowania w motoryzacji, a polega ona na tym, że przy pomocy pewnych narzędzi komputerowych jesteśmy w stanie tworzyć oraz weryfikować oprogramowanie przy pomocy tzw. modelowania. Na przykładzie: mamy jakiegoś Matlaba, Matlab Simulink, każdy, kto gdzieś tam na studiach technicznych przebywał, na pewno z tym narzędziem się spotkał. Matlab Simulink pozwala nam na tworzenie modeli matematycznych pewnych algorytmów oraz ich weryfikację. Te algorytmy możemy zawierać w modelach, te modele nawet możemy sobie ze sobą łączyć i możemy testować system mimo tego, że nie działa on na danym hardware, czyli tak naprawdę wirtualizujemy sobie środowisko, że mimo tego, że hardware nie istnieje, jeszcze nie został zaprojektowany, nie mamy do niego dostępu, jest drogi i wyprodukowanie tylu prototypów dla każdego inżyniera mogłoby się skończyć katastrofą finansową danej firmy, powoduje, że wiele rzeczy możemy przetestować również w tej wczesnej fazie, udowadniając przez to, że to oprogramowanie, ten algorytm zostało dobrze zdefiniowany, on działa poprawnie i spełnia wymagania, które się od niego odszukuje.
Dzięki temu możemy przyspieszyć też development z tego oprogramowania, spowodować, że jest on troszeczkę efektywniejszy, tańszy i pozwala nam wykrywać błędy w oprogramowaniu na wczesnej fazie jego developmentu. To znaczy nie potrzebujemy kosztownego hardware’u, żeby móc sprawdzić, czy to co zostało zaprojektowane działa poprawnie.

Paweł Kmiecik
Ja bym tutaj z mojej strony dodał, że z punktu widzenia testera jest to dla mnie pewnego rodzaju, można powiedzieć błogosławieństwo, widzę, że po prostu te testy właśnie nie jest integracja typu tzw. Big Bang, tak? Że wtedy łączymy, budujemy dziesięć algorytmów, tak jak wspomniałem wcześniej, łączymy w jedno i testujemy. No bo często wynik testów jest tragiczny i nie umiemy znaleźć jakby błędu. A więc tutaj właśnie Model-Based Design pozwala nam wykonać te testy już od najwyższego poziomu abstrakcji. A więc jak już stworzymy ten algorytm, to zanim połączymy go z innym algorytmem, możemy po prostu sprawdzić, czy ten algorytm działa poprawnie, czy reaguje poprawnie na dane wartości wejściowe i zwraca nam poprawny rezultat, który oczekujemy.
I jakby to jest też sposób rozwoju, który pozwala nam wykonać te testy jeszcze w bardzo wczesnej fazie projektu. Teoretycznie wiele algorytmów bierze sygnały z realnego świata, tak? Czyli tutaj na przykład sygnał z kamery albo sygnał z jakiegoś czujnika. My w tym wypadku jesteśmy w stanie sobie taki sygnał zasymulować, czy to zbudować jakiś model takiego czujnika i w tym wypadku zanim mamy dostęp do fizycznego sprzętu, z czym często jest problem. Tutaj mam na myśli np. o płytkach elektronicznych, które często są po pewnym czasie, a jeśli są to jest ich też ograniczona ilość. To w tym wypadku obojętnie jak duża grupa jest właśnie deweloperów, możemy sobie testować algorytmy, można powiedzieć wirtualnie, tak? A więc sprawdzając ich działanie już na bardzo wczesnej fazie projektu, co jest ogromnym plusem, tak? I dla testerów to bardzo ułatwia pracę potem, bo ta złożoność tych problemów, które znajdujemy jest rozbita na kilka poziomów.

Łukasz Okoń
Tak, dzięki takiemu testowaniu usuwamy sobie zależność losową hardware’u i w ogóle hardware’u, jego ograniczeń, co ma swoje plusy i minusy. Plusem jest takim, że jeżeli mamy algorytm i jesteśmy w stanie udowodnić, czy on poprawnie działa, po integracji w sprzęcie, jeżeli on przestaje działać, możemy spodziewać się, że to jest bardziej problem hardware’owy bądź optymalizacyjny danego algorytmu i wiemy, gdzie tych problemów szukać. Czyli uruchamianie takiego systemu też jest stosunkowo szybsze, co często jest błogosławieństwem dla inżynierów. Nie muszą tygodni spędzać na to, żeby znaleźć miejsce, w którym jest ten bug i trzeba zrobić szybki fix. Zmniejsza to ten czas, który jest potrzebny na te aktywności.

Paweł Kmiecik
Teraz chciałbym jeszcze porozmawiać o takich, jeśli już przeszliśmy przez te technikalia, które już wiemy, jak się ten Software rozwija, wiemy, jakie mamy standardy, które obowiązują w branży. Łukasz, dokąd dąży obecny świat automotive według ciebie?

Łukasz Okoń
To takim top tematem, jeżeli ktoś chciałby zaczepić się teraz w świat motoryzacji, obojętnie u jakiego producenta, obojętnie w jakiej firmie, to pośrednio lub bezpośrednio dotknie tematu tzw. ADAS, czyli Autonomous Driving, jazdy autonomicznej. Tak naprawdę jest to funkcjonalność samochodu, która pozwala nam z jakąś dozą uwagi kierowcy, samochód porusza się w ten sposób samodzielnie, czyli w jakiś autonomiczny sposób. ADAS jest podzielony na pewne poziomy. Tych poziomów jest z tego, co pamiętam pięć, natomiast Paweł tutaj jest ekspertem w tej dziedzinie ostatnio, więc może przybliżysz tutaj naszym słuchaczom, jak te poziomy wyglądają i o co w nich w ogóle chodzi.

Paweł Kmiecik
Tak, tak troszeczkę bardziej ostatnio się zagłębiłem w temat Autonomous Driving. Jest to bez wątpienia fascynująca technologia, która jest cały czas rozwijana i zapewniam tutaj słuchaczy, że dalej będzie rozwijana, bo wyzwania są przeogromne, takie jakich jeszcze ludzkość nie widziała. Natomiast jeśli mówimy o samym ADASie, no to są to jakby poziomy autonomiczności jazdy samochodu, tak? I jak wcześniej wszystkie samochody miały level 0, czyli po prostu kierowca musi być w samochodzie oczywiście, musi kierować, czyli jakby wykonywać manewry skręcania, musi jeszcze obsługiwać pedały gazu i czy tam gaz, czy to hamulec. To był po prostu level 0. I z czasem po prostu rozwoju algorytmów sterowania w samochodzie, większość osób tutaj zna, pojawił się tak zwany tempomat, czyli jest to już jakiś sposób autonomiczności można powiedzieć, no bardzo, bardzo mały.
Jest to tak zwany level właśnie pierwszy. Czyli kiedy możemy po prostu jechać autostradą i ten samochód trzyma daną prędkość, co jeżeli ktoś kiedyś był w jakiejś dłuższej trasie no to wie jak bardzo pomocny jest algorytm. Równorzędnie z tym możemy mieć też również algorytmy do trzymania pasa ruchu, tak? A więc tak zwany Line Keeping Assist, co też jest bardzo wygodne. Możemy przez chwilę na przykład wyciągnąć coś ze schowka jeśli jedziemy samochodem i nasz samochód będzie trzymał pas ruchu, tak? Następnie możemy przejść do poziomu drugiego i mianowicie jest to już troszeczkę wyższy level autonomiczności, kiedy możemy zastosować te algorytmy razem.
Bo tyle o ile w pierwszym levelu nie mogliśmy stosować tych algorytmów razem, no to w drugim levelu właśnie możemy już stosować takie algorytmy, czyli sterowanie jakby prędkością pojazdu i kierunkiem tego pojazdu, tak? Czy skręcamy, czy w prawo, w lewo, czy trzymamy dany pas ruchu. I jakby idąc jeszcze wyżej w tej samej strukturze, jeśli już wchodzimy na level trzeci, to już jest taki level, na którym powiedziałbym, że obecnie motoryzacja jest i stara się go jakoś okiełznać w większym lub mniejszym stopniu. A mianowicie jest to już autonomiczność pełna, aczkolwiek wymagająca uwagi kierowcy, a więc tutaj mówimy o algorytmach, które pozwalają nam np. odpisać na SMSa i nie sprawdzać drogi przez jakiś dłuższy okres czasu. Aczkolwiek jeżeli samochód wykryje jakieś niebezpieczeństwo lub zgłosi nam jakiś krytyczny błąd, wtedy musimy być za kierownicą i szybko podjąć reakcję, żeby nie doprowadzić do jakiegoś wypadku lub też kolizji. No i idąc jeszcze właśnie wyżej w tej strukturze, no jest to poziom czwarty. Poziom czwarty, który jest już bardzo zaawansowany w mojej opinii, mówiący nam o tym, że możemy jakby pozwolić pojazdowi na autonomiczną jazdę, aczkolwiek jest to ograniczone pewnymi warunkami zdefiniowanymi przez środowisko, w którym znajduje się samochód. To jest już taki case, że możemy realnie zasnąć za kierownicą w teorii, tylko pod warunkiem, że znajdujemy się w danym środowisku.
Mam tutaj np. na myśli autostradę albo jakiś parking itd. Często te samochody są po prostu przystosowane do danego rejonu i do danych jakby zagrożeń, które mogą w niej wystąpić. Tutaj dobrym przykładem będą taksówki autonomiczne, często już w Ameryce widziane i te taksówki często są tak przystosowane, że one i jeżdżą po danym terenie, danym terenie miasta, który jest bardzo dobrze znany i badany przez inżynierów wcześniej. Wiemy jakie tam np. mogą wystąpić np. roboty drogowe, wiemy gdzie są skrzyżowania, jak te skrzyżowania wyglądają i np. tutaj też ograniczeniem jest pogoda. Tak więc zakładamy, że musi być to słoneczny dzień i wtedy te algorytmy będą nam poprawnie działać.
No i następnie level piąty to już pełna autonomiczność, do której dąży cały świat automotive. To jest taki można powiedzieć American Dream, że wsiadamy w samochód, zaznaczamy palcem na mapie, gdzie chcemy dojechać obojętnie w jakiej części świata jesteśmy, jaka jest pogoda i jakie są obecne roboty drogowe w naszym mieście. Nasz samochód powinien tam dojechać bez naszej uwagi i wtedy możemy się dosłownie odwrócić od kierownicy o ile ona tam będzie w tych samochodach autonomicznych.
I wtedy dojechać z punktu A do punktu B. Także to warto wiedzieć jak właśnie rozróżniamy te poziomy i na jakim obecnie etapie jesteśmy, bo wyzwania, które za tym stoją są przeogromne.

Łukasz Okoń
Bardzo wiele osób sceptycznie podchodzi do tego typu tematów. Z jednej strony ludzie obawiają się bezpieczeństwa, czyli to, co się im może wydarzyć będąc użytkownikami takich systemów, bądź też będąc świadkami, jak inni używają takich systemów. Aczkolwiek myślę, że punktem numer jeden, tak jak już za każdym razem to też podkreślam, jest bezpieczeństwo użytkowników i to jest najwyższy priorytet każdego producenta samochodów. Ja pracowałem z kilkoma producentami samochodów, jednym z największych i mogę Wam powiedzieć, że ten punkt to jest zawsze punkt numer jeden w każdej funkcji, którą producent udostępnia użytkownikowi. Druga obawa ludzi. Ja lubię jeździć np. samochodem, choć nie ukrywam, że zdarza mi się korzystać z dobrodziejstw systemów, o których tutaj Paweł wspomniał, tak jak aktywny tempomat czy utrzymanie pasa ruchu.
Nie chciałbym, żeby tę kierownicę mi z samochodu zabrano. I to, co mogę wam powiedzieć, czyli w naszej najbliższej przyszłości raczej to się nie wydarzy. Czyli ludzie będą mogli dalej prowadzić swoje samochody, obojętnie jaki level autonomiczności one będą wspomagać. A druga kwestia też jest taka, że producenci samochodów chcą sprzedawać to, czego ludzie potrzebują. Czyli jeżeli większość osób nie będzie chciało pozbywać się tej kierownicy, to samochody z tą kierownicą nadal będą dostępne w sprzedaży. Więc nie musimy się tutaj obawiać jakichś zagrożeń wynikających z zabierania naszej wolności czy pozbawiania nas frajdy, jeżdżenia samochodami. Ja myślę, że tutaj każdy inżynier pracujący w automotive gdzieś te samochody w jakiś sposób lubi w taki czy inny sposób, więc oni też będą zwracać na takie rzeczy uwagę.
Aczkolwiek nie ukrywam, że samochody bez kierownicy kiedyś się mogą pojawić jako opcja dla ludzi, którzy chcą się poruszać z punktu A do punktu B w efektywny sposób i nie chcą brać żadnego udziału w tej podróży, że muszą kierować tym samochodem.

Paweł Kmiecik
Tak, tak, dokładnie też jestem tego zdania, że to wszystko będzie po prostu dostosowane do odpowiedzi społeczeństwa, więc jeżeli ludzie będą chcieli takich samochodów używać i będą je kupować, to ten rozwój jakby automatycznie będzie szedł do przodu i będzie dalej to wszystko rozwijane. Aczkolwiek jeśli chodzi o to samo bezpieczeństwo, to też jest bardzo ważne, ponieważ żaden producent samochodu nie zdecydowałby się na wypuszczenie takiego autonomicznego samochodu bez odpowiednich testów ze względu na to, że po prostu renoma marki. Jeżeli mielibyśmy jakiś śmiertelny wypadek, co już zdarzało, no to po prostu renoma marki bardzo podupada. Może być coś takiego, że ludzie będą się bali jeździć tymi samochodami ze względu na to, że ten pojazd miał śmiertelny wypadek i my nie chcemy się na to narażać.
I wtedy musimy my jako inżynierowie albo ktoś kto rozwija właśnie te algorytmy sterowania i automatyczne, autonomiczne pojazdy zbudować w społeczeństwie takie zaufanie do tych pojazdów, co będzie też ogromnym wyzwaniem w mojej opinii. Też tutaj chciałbym przejść do tematu, że tych plusów jest też mnóstwo, o których normalnie nie myślimy i zagrożeń też jest mnóstwo. I na przykład tutaj z plusów możemy wymienić coś takiego, że czas reakcji, tak? A więc jeżeli my jako kierowcy mamy ten czas reakcji zdefiniowany na danym poziomie. Nie wiem czy Łukasz pamiętasz ile to tam było?

Łukasz Okoń
Standardowy czas reakcji kierowcy jest uwzględniany jako jedna sekunda, czyli od pojawienia się przeszkody zazwyczaj upływa jedna sekunda do momentu, kiedy możemy zacząć generować jakąś reakcję. Czas potrzebny z funkcjonalnością Autonomous Driving na reakcję, na jakąś przeszkodę, na jakąś niespodziewaną sytuację, to są milisekundy, jeżeli nie mikrosekundy, czyli tak naprawdę biorąc pod uwagę jakąś tam prędkość autostradową, że w ciągu jednej sekundy przemierzamy kilkadziesiąt metrów, a taki algorytm, który działa za nas w tym przypadku, zaoszczędza nam te kilkadziesiąt metrów, co powoduje, że zwiększa prawdopodobieństwo braku narażenia się na jakąś utratę zdrowia i ich życia. Uważam, że w ten sposób wiele żyć można uratować na drodze, a także zmniejszyć ilość uszczerbku na zdrowiu dla ludzi, którzy biorą udział w takich sytuacjach.

Paweł Kmiecik
I też tutaj drugim aspektem, który chciałem poruszyć jest liczba parametrów, które mierzymy. My jako ludzie mamy jedną parę oczu, tak? A więc jakby skupiamy się na drodze to już nie patrzymy w lusterko albo patrzymy w lusterko to nie skupiamy się na drodze, tak? Tutaj trzeba pamiętać, że autonomiczne pojazdy mają tych sensorów, czujników multum i badają całe otoczenie jeszcze w danym promieniu, tak? A więc jadąc autonomicznym samochodem jesteśmy w stanie wiedzieć z pewną dozą dokładności jakie obiekty są wokół nas, z jaką prędkością się poruszając. No i algorytmy już też estymują jakby położenie tych obiektów, a więc jakby badają prędkość innego pojazdu i już wiedzą, że za kilka sekund ten pojazd prawdopodobnie, jeżeli nagle nie zniknie i będzie utrzymywać daną prędkość, no to będzie w tym miejscu, tak?
A więc my automatycznie nie wykonamy danego manewru np. zmiany pasa ruchu wiedząc, że nadjeżdża jakieś auto z daną prędkością. No i takie sytuacje jak np. Jakieś kolizji spowodowanej tym, że pojazd jest w martwym punkcie no nie miałyby miejsca, tak? Bo ten pojazd na pewno by to wykrył. Stwierdzenie na pewno jest bardzo odważnym stwierdzeniem, bo jeżeli mówimy o dokładności określenia właśnie parametrów w autonomicznej jeździe no to tutaj często już dotykamy tematu AI, także sieci neuronowych, które definiują nam z pewną dozą prawdopodobieństwa położenie danego obiektu, czy co to jest za obiekt. Rozpoznają ten obiekt. Cała percepcja otoczenia często jest jakby zrzucana na sztuczną inteligencję AI.

Łukasz Okoń
To jest temat rzeka. To jest hot-topic ostatnimi czasy w ogóle na całym świecie, więc to jest technologia, która rozwija się bardzo dynamicznie. Na pewno jest wykorzystywana w tych algorytmach, w tych funkcjach autonomicznej jazdy, przede wszystkim do rozpoznawania obiektu, rozpoznawania sytuacji na drodze, które są w jakiś sposób zamodelowane i ta sieć neuronowa, o której Pawle wspomniałeś jako jedna z metod sztucznej inteligencji, pozwala nam na to, żeby ta jazda wyglądała prawidłowo, żeby trajektoria ruchu samochodu była odpowiednia, żeby dynamika jazdy tym samochodem była odpowiednia, a także wykrywała nam zagrożenia na drodze, o której już tutaj też wspomniałeś. Temat jest o tyle ciekawy, że jest też wymagający.
Jest wymagający od inżynierów, aby algorytmy, które zostały zbudowane nie działały tylko i wyłącznie prawidłowo, ale także szybko, co wymusza pewną multidyscyplinarność od osób, które zajmują się tymi tematami. Będąc programistą, czy też architektem, czy też testerem, na każdym poziomie musimy też się zastanawiać nad pewnymi elementami takiego działania systemowego, czyli dodając funkcję do naszego samochodu jakąkolwiek, nawet najprostszą, musimy zawsze się zastanowić nad tym, jaki wpływ ta funkcja będzie miała na oddziaływanie całego systemu. Wymaga to odpowiedniej wiedzy, doświadczenia i rozpatrywania też przypadków, mimo tego, że mamy te poziomy testów, które nas zabezpieczają przed błędami. A dlaczego wymagają? Skoro mamy te testy, mamy te levele tych testów, to po co?
Musimy się zastanawiać zawsze nad całością, a nie tylko nad własną ścieżką, własną funkcją, którą ktoś polecił mi wykonać, bądź też sam z taką inicjatywą gdzieś tam wychodzę i uważam, że jest potrzebna. Wynika to z tego, że przypadki, które zdefiniujemy sobie już na wczesnym etapie, zrozumiemy ich wpływ na cały system, skracają nam ilość testów i zwrot tego z testerów, gdzie musimy poprawiać te nasze algorytmy. Czyli jeżeli jestem w stanie przeanalizować ten wpływ na dany system, zanim ten algorytm zostanie dointegrowany i zacznie być testowany, to ja już wiem, w jakich przypadkach użycia tej funkcji możemy mówić i jaki ona będzie miała wpływ na cały system.
Przez to jesteśmy lepszymi inżynierami, zwiększamy efektywność produkcji oprogramowania, też jesteśmy bardziej cenni z punktu widzenia naszego pracodawcy. Więc taka multidyscyplinarność to jest możliwość zrozumienia i zwiększania swojego doświadczenia poprzez rozumienie tego, co robimy i po co to robimy. To są główne pytania, które też inżynier sobie powinien zajmować. Po co jest ta funkcja i czemu ja ją robię? I jaki ona będzie miała wpływ na inne funkcje, które już istnieją? No i to jest właśnie fajne, to jest fajne. Z jednej strony to są wyzwania od ludzi, którzy biorą udział w tym developmencie, w tym wdrażaniu tych nowych funkcji, aczkolwiek nie tylko wyzwania, ale również możliwości, bo wiedza i doświadczenie bardzo szybko przychodzą podczas pracy z takimi projektami. Ilość zwrotek od Pawła na samym początku nas na pewno przerazi, a po jakimś czasie nawet już nie będziecie wiedzieć, że myślicie i zadajecie sobie pytania, o których kiedyś nawet nie przyszłoby wam do głowy pomyśleć. I wracając do tego tematu Artificial Intelligence, czyli tej sztucznej inteligencji, to jest hot-topic ostatnio i na pewno, jeżeli zaangażowalibyście się w jakiś projekt ADASowy w motoryzacji, to tego AI będziecie musieli gdzieś tam dotknąć, ta sieć neuronów też musi być w jakiś sposób wytrenowana, więc wiele godzin, tysięcy godzin pracy ludzi trzeba poświęcić na to, żeby mieć pewność, że to, co użytkownik danego samochodu robi i to, co może zrobić za tą kierownicą jest dla niego bezpieczne.

Paweł Kmiecik
Pierwsza część twojej wypowiedzi to brzmiało tak troszeczkę jak jakiś sposób na nieśmiertelność. Wiesz o co chodzi? Że zawsze jest, jak będziesz w automotive, to zawsze musisz być up to date, czyli po prostu na bieżąco z najnowszymi technologiami. Wychodzi AI i to AI gdzieś tam jest jakby integrowane z samochodów. Musisz wiedzieć jak działa, musisz wiedzieć jak to przetestować, jak to dointegrować. I oczywiście gdzieś te tematy się cały czas przeplatają. Także to jest na pewno super, jeśli chodzi o branżę automotive. No i też ta wieloprzekrojowość, że często pracujemy nad jednym tematem i musimy mieć, jakby wziąć pod uwagę, jak działa cały system, który często jest jakby stworzony wiadomo z elektroniki.
Musi to działać na jakiejś płytce elektronicznej. Następnie mamy też części mechaniczne. Warto wiedzieć jak one działają, żeby np. definiując jakiś algorytm np. do mitygowania, jak już wspominaliśmy danego błędu, żeby wiedzieć jakie mogą być skutki. A więc tutaj ta multidyscyplinarność jest pozytywnym aspektem według mnie, bo nawet jeżeli mamy wykształcenie z danej dziedziny no to gdzieś podczas właśnie tej pracy będziemy chcieli się douczyć innej też dziedziny. Tutaj mam na myśli mój przekaz jakby ma na celu to, żeby powiedzieć, że jeżeli ktoś jest na przykład na wykształcenie czysto mechaniczne np. budowa maszyn czy coś, to na pewno też znajdzie coś dla siebie w branży automotive, bo to też jest jakby spora część, lwia część budowa fizyczna samochodu, tak?
Programiści również oczywiście znajdą coś dla siebie, na elektrotechnice na pewno też znajdą coś dla siebie, także ta multidyscyplinarność jest jakby nieodłączną częścią tego przemysłu. Natomiast jeśli wracając też do tematu AI no to mówimy o developmencie i o testach no to ciężko jakby mówić o działaniu algorytmu jeżeli nie zdefiniujemy sobie jakiegoś drzewa decyzji, tak? No bo możemy mieć jakieś algorytmy, które nam działają w lepszy lub gorszy sposób. Natomiast każdy z tych algorytmów może zwrócić nam daną informację i my jako inżynierowie czy to tutaj np. Łukasz architekt musi zdefiniować w jaki sposób dane auto powinno się zachować pod względem danych wejściowych.
Tak więc tutaj mam na myśli to, że stosujemy też często coś takiego, że mamy kilka sensorów, które mierzą nam dane wartości i musimy podjąć decyzję, która z tych wartości jest prawidłowa. W momencie, jeżeli mówimy tutaj o sieciach neuronowych, no to często ta decyzja może być no po prostu to jest prawdopodobieństwo, tak? Nie oszukujmy się. A więc ktoś by się zapytał: a po co nam te AI w tym aucie? No po to dokładnie, że w złożonych przypadków, które są na drodze, często jest tak złożona ta liczba tych przypadków, że nasz mózg jako człowieka jest stworzony do tego, żeby łatwo się adaptować.
My się łatwo adaptujemy do sytuacji na drodze, widzimy jakiś znak, który jest na przykład zaśnieżony, no to my jesteśmy w stanie stwierdzić: no tutaj jest skrzyżowanie, tutaj zawsze była linia stopu, ten znak ma kształt linii stopu, a więc no prawdopodobnie jest to stop. No i zatrzymamy się, tak? No logicznie myśląc. Aczkolwiek no trzeba brać pod uwagę, że ten algorytm musi to zrobić za nas, tak? On musi też powiedzieć. No i tutaj jakby sposób taki, że definiujemy wszystkie znaki drogowe na całym świecie i wgrywamy je do samochodu, żeby samochód wiedział jakie to są znaki, jest dobrym pomysłem.
Tylko jeśli już zaczniemy rozpatrywać jakieś przypadki takie nieliniowe bym powiedział, takie bardzo nietypowe, no to ten algorytm po prostu może nie działać. No i tutaj właśnie jest od tego sztuczna inteligencja, że np. jeżeli mamy tak jak wspomniałem wcześniej ośnieżony znak, no to sztuczna inteligencja powinna rozpoznać co to jest za znak, czy jest on ośnieżony, jaki on ma kształt itd. I z jakąś dozą prawdopodobieństwa powiedzieć, że powinniśmy się zatrzymać. Następny przypadek to już bardziej taki kreatywny. Zakładamy, że jedziemy przez miasto i widzimy też znak stopu czy jakikolwiek inny znaku. Stąd pierwszeństwa na przykład i mamy kałuży na drodze i ten znak jakby zachodzi refrektancja, tak?
Ten znak odbija się od kałuży i nasze auto jakoś to wychwyci, tak? Przyjeżdżamy obok jakiegoś wieżowca w Warszawie i jest po prostu szkło, szyba i też jest jakieś odbicie. Refrektancja się robi. Algorytm AI nam rozpozna, że ten znak jest w dwóch pozycjach naraz, on jest jakby od odbiciem. No i pytanie jak się zachowa ten algorytm? Jak bardzo my go przetestowaliśmy? Jeżeli przetestujemy go i rozpatrzymy taki case, że to jest błędna informacja i powinniśmy brać pod uwagę tylko jeden znak, no to ok, ten algorytm zadziała. Co w przypadku, jeżeli ten algorytm stwierdzi, że ja widzę dwa znaki, a więc prawdopodobnie jest to jakiś błąd systemu, jakiś niezidentyfikowany obiekt.
No i w tym wypadku nie robimy nic, tak? No i wtedy się może nie zatrzymać. Inżynierowie cały czas nad tym pracują, tak? Żeby takie przypadki nie miały miejsca. Dobrym przykładem tutaj będzie pierwszy wypadek, który miał miejsce w 2018 roku, kiedy autonomiczny samochód nie rozpoznał prawidłowo kobiety, która prowadziła rower wzdłuż ulicy. On nie zauważył, że jest to jakiś obiekt i najpierw zidentyfikował ten obiekt jako po prostu człowieka. Następnie zauważył rower, a więc już się pojawił jakiś taki błędny sygnał, że kurczę, chyba jest to obiekt rower, że jakby nie jest to osoba żywa. I jakby wskutek tego algorytm podjął decyzję, że jest to prawdopodobnie jakaś błędna informacja i nie robimy nic.
No i wtedy doszło do takiej sytuacji, że ten samochód autonomiczny po prostu przejechał tą kobietę no i skończyło się tragicznie. To był pierwszy oficjalny przypadek śmiertelny z użyciem autonomicznej jazdy, co na pewno zostało dobrze rozważone potem i te algorytmy już działają, zakładam, o niebo lepiej. Aczkolwiek też to pokazuje tą słuszność tego problemu, że często możemy mieć jakieś sytuacje na drodze, o których nie mamy pojęcia albo po prostu człowiek by się zachował w dany sposób logiczny dla nas, aczkolwiek algorytm czy tutaj sieć neuronowa musi tą decyzję podjąć zaraz. Innym

Łukasz Okoń
Innym wyzwaniem dla sztucznej inteligencji, tym, który wydaje mi się, nie wiem czy jest rozwiązany czy nie, są roboty drogowe. Roboty drogowe dlatego, że one nie mają zdefiniowanej struktury i sposobu, w jaki są budowane. Pewnie każdy z was miał nieraz sytuację, że mimo tego, że jest się człowiekiem, czyli mamy własną prawdziwą inteligencję i jesteśmy w stanie ocenić sytuację wokół, napotykamy roboty drogowe i nie wiemy jak się zachować. I człowiek sam gubi się w tej sytuacji, więc nie możemy też oczekiwać, że komputer zrobi to lepiej albo możemy oczekiwać i trzeba go do tego wytrenować, aczkolwiek jest to bardzo trudne do realizacji.
Tak samo jak świat rzeczywisty, to co się dzieje wokół nas itd. ma wpływ na to, w jaki sposób samochody się rozwijają, to wydaje mi się, że też taki proces będzie zachodził w drugą stronę. Jeżeli będziemy chcieli dopuścić do ruchu autonomiczne samochody, to też muszą pojawić się regulacje dotyczące m. in. np. takich robotów drogowych, które będą standaryzować, w jaki sposób one mają być oznaczone dla ludzi, którzy się nimi zajmują i żeby one były tak modelowe, bardziej modelowe, tak żeby sztuczna inteligencja nie miała wielkich problemów z rozpoznawaniem tych sytuacji. Więc ten wpływ developmentu i rozwoju motoryzacji zawsze ma, może nawet nie zawsze miał, może teraz ma takie sytuacje, w których ten proces też jest trochę odwrócony.
Nie tylko spełnia nasze potrzeby, budujemy samochody, nie tylko żeby spełniać nasze potrzeby, ale też zamieniamy naszą rzeczywistość po to, żeby te samochody mogły być bardziej bezpieczne, lepsze, wygodniejsze itd. itd. No i tutaj dotykamy też takiego tematu, powiedzieliśmy, że samochody mogą działać szybciej niż człowiek, budować drzewa zdarzeń, czyli rozpatrywać bardzo szybko, co się może wydarzyć, jaką decyzję taki samochód podejmie. Np. są algorytmy szachowe, jeżeli chcielibyśmy rywalizować z komputerem, to komputer jest w stanie kilkadziesiąt albo kilkaset, albo kilka tysięcy ruchów do przodu budowania tzw. drzewa gry, czyli wszystkich możliwości, które mogą wystąpić i postępować w taki sposób, żeby doprowadzić do zwycięstwa.
W algorytmach autonomicznej jazdy, skoro komputery są szybsze niż nasze mózgi, my gdzie jako kierowcy działajmy intuicyjnie. Często jest to wypracowana jakaś sytuacja na drodze, kierowcy wyścigowy mają jakieś wypracowane odruchy, które może im pozwalają też szybciej klasyfikować dane sytuacje i znaleźć jakieś odpowiednie rozwiązania trudnych, tragicznych zdarzeń na drodze. Tak samo komputer jeszcze bardziej, wydaje mi się, jest w stanie rozpoznawać tę sytuację i generować właśnie takie drzewa zdarzeń, które się mogą zdarzyć. No i tutaj dotykamy problemu etycznego, no bo skoro mamy taki samochód, jesteśmy jego kierowcą i dochodzimy do sytuacji trudnej na drodze i teraz w takim drzewie sytuacji komputera pojawiają się dwie opcje: albo kierowca zostanie uszkodzony, poniesie jakieś zdrowotne konsekwencje danej sytuacji bądź też chronimy kierowcę, a innego uczestnika tego zdarzenia narażamy na jakieś niebezpieczeństwo.
Mogą być takie dylematy, które taki komputer będzie musiał rozwiązać, a on postąpi tak, jak zostanie skonfigurowany. Komputer zawsze będzie dążył do realizacji jakiegoś celu. Tak działa sztuczna inteligencja, więc jeżeli każemy jej chronić zawsze kierowcę, to będzie robić wszystko, żeby tego kierowcę ochronić i pasażerów danego samochodu. I tutaj właśnie są te tematy etyczne, które nie są rozwiązane, które możliwe, że w przyszłości będą, w jaki sposób to ma zostać skonfigurowane, będzie narzucone prawnie, może będzie na ten temat jakieś szersze dyskusje, może to prowadzi do jakichś takich dyskusji społeczno-politycznych, które nie wiadomo, w jaki sposób się pojawią, natomiast te problemy, czyli te poziomy autonomicznej jazdy, które mamy już dziś, w jakiś sposób wymagają już podejmowania takich decyzji.
Na szczęście jako inżynier nie muszę takich decyzji podejmować i budować takiej konfiguracji dla tych modeli, natomiast ktoś prędzej czy później będzie musiał się tym tematem zająć, myślę, że prędzej niż później. Jeszcze

Paweł Kmiecik
Chciałem wrócić do samego początku twojej wypowiedzi a propos tego przypadku, który rozpatrywaliśmy. Nie wspomniałem o tym, że ten pojazd anatomiczny był w fazie testów developmentu właśnie tych algorytmów i w blackboxie podczas tego wypadku można było zauważyć, że ta kobieta jakby była wykryta przez sensor, który jest zamontowany na samym przodzie samochodu. Aczkolwiek algorytm nie zadziałał ponieważ był wyłączony. A więc na potrzeby właśnie developmentu głupotą wtedy było tak, żeby wyłączyć ten nadrzędny algorytm, który spowodowałby drastyczne zahamowanie pojazdu. Aczkolwiek gdzieś on pewnie wchodził w interakcje z tymi algorytmami autonomicznej jazdy i po prostu został wyłączony, przez co też mieliśmy taki przypadek.
Troszeczkę pozytywizmu dodając do tej wypowiedzi, że mamy multum tych sensorów. Tutaj rozpoznajemy kamery lidar, radar czy to ultradźwiękowe sensory, które działają nam w każdym wypadku czy jest mgła, czy jest ciemno, czy pada deszcz itd. No to wtedy próbujemy przeciwdziałać właśnie tym wszystkim przypadkom właśnie integrując takie rozwiązania, takie sensory i takie pomiary, żeby zachować pełne bezpieczeństwo. I zakładam, że już te najnowsze samochody mają na pewno dointegrowane takie rozwiązania, żeby bezpieczeństwo było na odpowiednim poziomie. Natomiast jeśli wspomniałeś o tym drzewie decyzji to tak, jest to niewątpliwie ogromny problem. Na szczęście wydaje mi się, że nie na poziomie inżynieryjnym tylko na poziomie właśnie takim społecznym, że musielibyśmy zdefiniować w jakiś sposób to drzewo decyzji, jak się ma samochód zachować w tych tragicznych przypadkach, wybierając np. kogo potem gdzieś na pasach, tak? Bo wiemy, że nie wyhamujemy, bo mamy za dużą prędkość, a dwie osoby nam wyskakują na pasy. No to wtedy musimy jakoś zdefiniować, tak? Czyli jedziemy po prostu prosto i koniec. Po prostu decydujemy się na podstawie jakichś kryteriów, które przez kogoś muszą być zdefiniowane, żeby ten algorytm jakoś się zachował. Wspomniałeś też o tym, że sieć może mieć nadrzędny cel, aby chronić kierowcę i wtedy patrzy, co jest dobre dla kierowcy. Też właśnie wynik takiego zdefiniowania takiego celu w sieci neuronowej może być szeroko mówiąc no nie zbadany, tak? Bo tutaj miałem na myśli taki przypadek jak kiedyś właśnie oglądałem wywiad z pewnym deweloperem sieci AI i on wspomniał o tym, że taki ciekawy przypadek mógłby zaistnieć jeżeli byśmy integrowali taką sieć neuronową do Rumby odkurzacza, który sprząta nam dom.
I tutaj np. moglibyśmy zdefiniować, że dom zawsze ma być czysty. To jest nadrzędny cel, tak? Musisz utrzymać dom i podłogę czystą. I w tym wypadku ta sieć neuronowa działając na takiej Rumbie mogłaby po jakimś czasie zobaczyć, że taki przypadek sobie zbadać, że zawsze jak mam niski stan baterii to przychodzi właściciel i daje mi do ładowania. Wiadomo, że te Rumby prawdopodobnie już automatycznie tam dojeżdżają. Aczkolwiek rozpatrując tylko ze względu do sieci neuronowych taka Rumba mogłaby stwierdzić: no ale chwila, ja mam nadrzędny cel, żeby posprzątać dom. A więc w tym wypadku, jeżeli Rumba wykryje, że właściciel się zbliża w jej kierunku, żeby ją dać do ładowania, to wtedy może przed nim zacząć uciekać.
Bo ona ma cel, żeby mieszkanie było czyste, a nie żeby ona była naładowana. I to też są takie przypadki, które trzeba gdzieś rozważyć przy tym developmencie tych sieci neuronowych, co jest niesamowicie ciężkie, tak? Żeby wszystkie te przypadki rozpoznać. A niektórych przypadków tak jak wspomniałeś o robotach drogowych jest niezmiernie ciężko jakby je przewidzieć i o tyle o ile jakiś np. pojazd przejedzie tam przed nami i jakoś nie wiem wyśle informację do chmury, którą my potem pobierzemy, że tam są takie roboty drogowe i w ten sposób przez nie przejedziemy, no to to jest jakiś sposób rozwiązania, tak?
No ale nie możemy tylko na tym polegać. No może my musimy rozprawiać przypadki, że my jesteśmy tym pierwszym kierowcą o piątej rano, kiedy te roboty powstały, tak? Nie musimy się zachować w dany określony sposób. Także to też jest może jakiś sposób, żeby wymieniać jakby informacje między autonomicznymi samochodami. Czy to właśnie na podstawie jakichś robotów drogowych, czy jakieś sytuacje, które miały miejsce na drodze, czy to nawet wypadków. Że np. jeżeli my mamy wypadek, to powiemy swoim bliskim, jaka była sytuacja niebezpieczna sytuacja, czy zobaczymy sobie filmik na YouTubie i ta informacja gdzieś się przejdzie, tak? Że nie wiem, ktoś tam nie zapiał pasów i miał wypadek i wiemy jakie są skutki.
A np. w autonomicznych samochodach może mieć taki przypadek, że producenci aut będą współpracować ze sobą i będą sobie te jakby wiadomości o wypadkach samochodowych między sobą wymieniać. I wtedy automatycznie będziemy to musieć uczyć, jak się zachowywać podczas wypadków, bo to też jest taki ciekawy case, co robi autonomiczne auto w przypadku, kiedy widzi, że np. stoi na czerwonym świetle i na środku skrzyżowania jest zderzenie aut. No i to auto leci w naszą stronę. To auto ma zacząć cofać? Czy ono ma przyspieszyć w prawo, w lewo, żeby uniknąć tego wypadku? A co jak tam ktoś będzie stał na tym pasie po boku?
No to mamy w niego uderzyć czy nie? Ludzki organizm zareagowałby w stresie pewnie w dany sposób, nie wiadomo też jaki. Aczkolwiek te algorytmy mogą uczyć się nawzajem też, że ja się zachowałem w taki sposób, bo to jest poprawne, to jest niepoprawne. No ale to widzimy, jak bardzo jest to złożony problem. Jeszcze setki godzin, tysiące, miliony godzin testów i to pewnie jeszcze potrwa kilka lat.

Łukasz Okoń
I tutaj Paweł, fajnie przeszedłeś płynnie do sytuacji, w której też chciałem trochę poruszyć, a propos tej łączności, o której wspomniałeś. Zakładając, że mamy level piąty, czyli samochody są w pełni autonomiczne, możemy sobie wyobrazić taką sytuację, że mamy jakieś skrzyżowanie. To skrzyżowanie nie posiada takiej sygnalizacji świetlnej. Dlaczego? Ponieważ samochody łącząc się ze sobą, a także ze skrzyżowaniem, skrzyżowanie może mieć jakiś access point, do którego samochód się połączy, zbliżając się do niego i on jest swoistym kontrolerem ruchu dla tego skrzyżowania. Można to porównać do kontrolera ruchu samolotów, czyli jest nadzorca skrzyżowania, który wysyła samochodom trajektorię, po której muszą się poruszać, żeby dotrzeć do celu, co może zwiększyć przepustowość takiego skrzyżowania.
Samochody mogą jechać szybciej, mijać się na centymetry, ponieważ ich ruch jest z góry przewidziany i taka mapa rozładowania takiego skrzyżowania może działać dużo wiele efektywniej aniżeli niż to, co mamy teraz. Co może spowodować, że chcąc się poruszać z punktu A do punktu B, możemy skrócić czas w podróży o wiele bardziej. Jeżeli mamy szybsze czasy reakcji takiego samochodu na pewne zdarzenia, możemy zwiększyć limity prędkości takich samochodów. Czyli wyobraźmy sobie sytuację, że chcielibyśmy pojechać w Polsce popularny kierunek wakacyjny to Chorwacja. Standardowo to jest 14 godzin jazdy samochodem, może zamiast tego by było 6. Wieczorem stwierdzę rano chcę być w Chorwacji, pakuję się, wsiadam do samochodu, idę w kimę, rano jestem nad morzem, już samochód jeszcze mi kawę pewnie zrobił, jakiś ekspres zabudowany może mieć, idąc tutaj dalej po bandzie, jesteśmy wypoczęci, jesteśmy zadowoleni, a nawet jeżeli mamy tylko i dwa dni, no to wieczorem albo jeden dzień wieczorem pakujemy się z powrotem i rano jesteśmy w domu, bądź też pod pracą, bo to może być poniedziałek, ciężki poniedziałek, trzeba być w biurze i mamy wyprasowane koszule w schowku.
Nawet do takich sytuacji gdzieś tam kiedyś możemy dojść, więc dzięki właśnie rozwojowi tej technologii, dzięki systemom autonomicznym, dzięki pracy tylu inżynierów, tysięcy inżynierów, ludzi i godzin, które nas tam spędzają, możemy zmieniać ten nasz świat, którym się otaczamy. No i to jest właśnie też fajne. Fajne w automotive jest to, co już powiedzieliśmy, że to są nie tylko wyzwania, ale też możliwości. Porównując prace nad systemami wybudowanymi, a pracą takiego developmentu webowego czy też aplikacji, możemy dotknąć tego, co zrobiliśmy. Będąc z inżynierami może kupimy sobie samochód, w którym braliśmy udział w jakiejś tej funkcji i próbować ją zepsuć, przetestować, tak jak te sceny robią podczas jazdy i mieć czynny wkład w życie milionów ludzi na całym świecie, bo taka jest prawda.
My projektując taki samochód, będąc inżynierami czy te oprogramowania, czy tworząc to oprogramowanie, implementując, czy je testując, mamy czynny wpływ na to, jak będzie wyglądał ten nasz świat.

Paweł Kmiecik
Tak, ja tylko dodam, że ta wizja tej Chorwacji tak brzmiała jak utopia, tak to brzmiało jak marzenie, tak wsiadamy i wysiadamy i jesteśmy w Chorwacji. Ale mam nadzieję, że właśnie jeszcze może za naszego życia jeszcze tego doświadczymy. Tak jak właśnie wspomniałeś, to jest też niesamowite branża automotive, że jakby budując te algorytmy czy biorąc czynny udział w rozwoju tych autonomicznych samochodów czy to zwykłych też aut, no mamy jakby okazję te algorytmy testować na co dzień, tak? My też jeździmy samochodami, widzimy jak te algorytmy działają i tak jak właśnie wspomniałeś zawsze możemy kupić auto, wiedząc jakie algorytmy tam są, bo np. jest szansa, że je projektowaliśmy i wtedy wiemy, że jeździmy bezpiecznym autem i to jest też niesamowite, że będąc inżynierem bierzemy ten czynny udział w tym procesie rozwoju tych najnowszych technologii, których używa cała ludzkość. To jest niesamowite, że czujesz czynny udział w tym całym procesie. To jest taka praca po pierwsze twórcza a po drugie taka, że czujesz się potrzebny, że jest to coś użytecznego, że widzi, że realne działanie tego. Oczywiście nie mówię, że w innych branżach tego nie ma, ale mówię, że u nas tak to działa, że wtedy rozwijają. O super, super.

Łukasz Okoń
Dla mnie też jest ważna satysfakcja z pracy. Dla mnie poczucie satysfakcji to nie tylko wynagrodzenie, czy tam wakacje, które mogę na to poświęcić, ale to też jest poczucie wkładu w tą rzeczywistość, zmianę tego świata. I tutaj już podsumowując, chciałbym powiedzieć, że chcieliśmy z Pawłem przybliżyć wam trochę ten świat automotive, tego inżynieringu, developmentu oprogramowania i też chcieliśmy pokazać, że bezpieczeństwo na tej drodze dla tych użytkowników to jest zawsze punkt numer jeden, o którym wszyscy pamiętają, dla ludzi, którzy biorą w tym udział, później też jeżdżąc tymi samochodami. Na pewno bym chciał w jakiś sposób zachęcić was do tego świata, do tego świata motoryzacji.
Ja myślę, że każdy z nas choć trochę lubi samochody, czy to jeździć nimi, czy być wożonym, czy właśnie z takimi wizjami, jak przed chwilą powiedzieliśmy sobie z Pawłem tutaj wychodząc naprzeciw przyszłości. Więc no nic no, mogę was tylko zaprosić do tego.

Paweł Kmiecik
Pracy jest ogrom, także na pewno jeszcze będzie dużo rzeczy do rozwijania i do developmentu tak zwanego szerokiego. Także proszę się nie bać i mam nadzieję, że właśnie udało nam się troszeczkę z Łukaszem tą taką bańkę, która być może gdzieś narosła wokół branży automotive, że to jest taki obcy teren troszeczkę ją rozbić i pokazać na czym ona polega i że nie jest taka straszna. Także dziękujemy za uwagę i pozdrawiamy.

Łukasz Okoń
Tak, dziękuję.

Szymon Głowania
Aby nie przegapić kolejnych odcinków zasubskrybuj podcast TechChatter w swojej ulubionej aplikacji. A jeśli spodobał ci się ten odcinek daj znać wystawiając oceny na Spotify lub Apple Podcasts. Wszystkie linki do zagadnień poruszanych w odcinku znajdziesz w jego opisie.