Inżynieria, Wywiady

Praca jako programista systemów automotive daje niesamowitą satysfakcję. Wywiad z Krzysztofem Kmiotkiem

bwm

Praca w branży automotive jest prawdziwym marzeniem programistów fascynujących się motoryzacją. W rozmowie z Krzysztofem Kmiotkiem Senior Software Engineerem w intive rozmawialiśmy o codziennej pracy programisty automotive, drodze do uzyskania takiego stanowiska oraz emocjach towarzyszących tworzeniu systemów umieszczanych w prawdziwych samochodach.

Jaka była Twoja ścieżka do aktualnego stanowiska? Co robiłeś przed podjęciem pracy w intive?

Podczas studiów na kierunku Automatyka i Robotyka na AGH byłem przekonany, że moim marzeniem
jest praca z robotami w fabryce. Byłem pewien, że chcę je programować oraz projektować całe linie
produkcyjne. Życie zweryfikowało moje marzenia podczas 2-miesięcznej wegetacji w fabryce, przy
utrzymaniu ruchu. Nadszedł czas, by poszukać nowych marzeń.

I tak trafiłem do świata programowania embedded. Moje pierwsze kroki to małe mikrokontrolery w
branży energetycznej. Jako że już wtedy był czas rynku pracownika, mogłem wybierać co, w jakiej branży i gdzie chcę robić. Wiedziałem już, że roboty i praca w fabryce nie są dla mnie, natomiast od dziecka, jak chyba każdy chłopiec, interesowałem się samochodami. Przyszedł czas na większe projekty w branży automotive.

Czy możesz opowiedzieć jak wygląda programowanie embedded w branży motoryzacyjnej? Czym różni się od kodowania w innych branżach?

W programowaniu embedded w branży motoryzacyjnej w dalszym ciągu króluje, i pewnie jeszcze przez
wiele lat królować, będzie język C. Wielu programistów narzeka na ten fakt, gdyż programowanie w tak
niskopoziomowym języku bywa wymagające, jednak w zamian daje znacznie większą kontrolę nad
sprzętem oraz zasobami mikrokontrolera.

Kolejnym nieodłącznym elementem programowania systemów wbudowanych w branży motoryzacyjnej
jest Autosar. Jest to system, który standaryzuje sposób implementacji oraz integracji modułów. Można
go kochać lub nienawidzić, z doświadczenia obserwuję, że większość ludzi zaczynających pracę w naszej branży przeraża Autosar, skomplikowanie niezbędnych narzędzi oraz ilość dokumentacji. Jednak z czasem system Autosar staje się coraz bardziej ludzki. Droga do pokochania Autosara nie jest łatwa,
przechodzimy przez kolejne fazy: szoku i zaprzeczenia (jak z tym g** można w ogóle pracować?),
następnie gniew i bunt (po co ja się za to brałem?), negocjacje (a może by tak prościej?), depresja (czy to jest w ogóle możliwe?) oraz ostatecznie akceptacja, która może przerodzić się w prawdziwe uczucie.

Programowanie w automotive nie kończy się na programowaniu systemów tuż przy sprzęcie, w języku C
wraz z Classic Autosarem. Z roku na rok w naszej branży coraz popularniejsza staje się koncepcja
connected cars, car sharing czy hardware as a service. Zmienia się spojrzenie na samochód: dotychczas
po prostu pojazd do przemieszczania się, a obecnie nowoczesna usługa. Taki nowoczesny samochód
możemy dostosować do tego, czego aktualnie potrzebujemy. Za pomocą dodatkowego abonamentu
możemy rozszerzyć jego funkcjonalność, dodać mu parę koni mechanicznych czy odblokować
podgrzewane fotele. Jako że samochód jest stale podłączony do sieci, możemy go podnajmować innym
kierowcom. I tak, samochód, z którego aktualnie nie korzystamy, w tym czasie może sam na siebie
zarabiać. 

Wszystkie te opisane wyżej trendy niosą ze sobą konieczność innego spojrzenia na samochód, przestaje
to być statyczny system, który od wyjazdu z fabryki ma stałą funkcjonalność i może działać offline.
Nowoczesny samochód wymaga innego podejścia, bardziej dynamicznego. I tu, na wprost oczekiwaniom
inżynierów, pojawia się system Adaptive Autosar, czyli system POSIX dający znacznie większą
elastyczność niż klasyczne podejście.

Programowanie w Adaptive Autosar odbywa się w języku C++ i nie kładzie już tak dużego nacisku na samą platformę sprzętową, pozwalając na skupienie się na samej
funkcjonalności. Podsumowując, w automotive jako programiści możemy pracować blisko sprzętu, używając języka C oraz Classic Autosara lub też pisząc aplikacje obiektowe w C++ pod Adaptive Autosar.

Czy czujesz presję podczas programowania systemów w prawdziwych samochodach? Jakie to uczucie mieć świadomość, że stworzony przez Ciebie kod będzie już za parę lat służył kierowcom na całym świecie?

Praca jako programista systemów automotive daje mi niesamowitą satysfakcję. Rozwiązania, nad
którymi obecnie pracujemy, już za 2/3 lata będą montowane w setkach tysięcy samochodów na całym
świecie. Za każdym razem, gdy mija mnie samochód wyposażony w system, przy którym pracowałem,
przypominam sobie te godziny zespołowej pracy, rozwiązywania niespodziewanych problemów oraz
testów systemowych. Daje mi to ogromną radość i satysfakcję, miła jest też świadomość, że w tym
samochodzie jest coś, nad czym pracowałem, czego sposób działania znam w 100%.

Czym zajmujesz się na aktualnym stanowisku? Co skłoniło Cię do rozpoczęcia pracy w tym zakresie?

Pracuję jako inżynier oprogramowania, aktualnie w projekcie dla niemieckiego producenta samochodów
premium. Sam projekt jest jednym z największych dotychczasowych projektów naszego klienta, łącznie
pracuje nad nim 400 inżynierów podzielonych na zespoły scrumowe. W Krakowie mamy własny,
niezależny zespół składający się z programistów, testerów, systemowców, nad całością czuwają Product
Owner oraz Scrum Master. W tak dużym projekcie wyzwaniem jest synchronizacja oraz rozplanowanie
pracy poszczególnych osób. Duży nacisk kładziemy na metodykę Agile oraz pracę w SAFE. 

Od strony technicznej używamy języka C. Sam projekt to zaawansowany Gateway składający się z 3
mikrokontrolerów, obsługujący sygnały z setek czujników rozmieszczonych po całym samochodzie.
Czujniki te połączone są po dziesiątkach magistrali komunikacyjnych, takich jak CAN/LIN czy też
Ethernet. Oczywiście całość jest pisana zgodnie z systemem Classic Autosar. Sam projekt jest
prowadzony w ASPICE, co definiuje nam sposób testowania oraz współpracy z systemowcami, czyli
ludźmi od wymagań.

Oprócz pracy nad komercyjnymi projektami, w krakowskim biurze rozwijamy również wewnętrzny
projekt KATE, którego mam przyjemność być leaderem.

Czy możesz zdradzić nieco więcej na temat projektu KATE?

Projekt KATE to zbudowany od zera system HIL (Hardware in Loop) wraz ze środowiskiem testowym.
Całość umożliwia symulacje urządzeń elektrycznych występujących w automotive, takich jak: przyciski,
przełączniki, silniki, grzałki, itp.

Kiedy i do czego można zastosować taki system? Wyobraźmy sobie, że naszym zadaniem jest stworzenie sterownika do świateł samochodu. Tego typu urządzenie wyposażone będzie w mikrokontroler, który zbiera informacje wejściowe z przycisków, pokręteł, manetek. Może mieć też podłączony czujnik zmierzchowy i, na podstawie tych sygnałów, załącza odpowiednie urządzenia wyjściowe, które w tym przypadku stanową odpowiednie światła. Na początku pracy nad tego typu projektem będziemy w stanie zadowolić się samym mikrokontrolerem, jednak wraz z rozwojem projektu coraz bardziej będzie nam potrzebny sprzęt.

Najłatwiej by było programować, będąc podłączonym bezpośrednio do modułu w samochodzie, jednak z wielu powodów jest to niemożliwe. Chociażby dlatego, że najczęściej samochody, nad którymi
pracujemy, jeszcze nie istnieją. Tu pojawia się miejsce na testebenche, czyli systemy, które zawierają
wszystkie komponenty niezbędne do pracy z danym modułem. Alternatywą bądź uzupełnieniem takiego
test benchu jest nasz system KATE. Mając do dyspozycji KATE, możemy zasymulować poszczególne
urządzenia wejściowe oraz wyjściowe, odcinając urządzenie od zewnętrznych przycisków oraz
aktywatorów. Do tego dajemy możliwość testowania zwarć i przeciążeń. KATE jest też stosowane do
pomiarów napięcia i prądu oraz sterowania zasilaczem. Całość nastawiona jest na jak największą
prostotę w użytkowaniu, udostępniamy GUI oraz API w Pythonie i C#.

Praca w projekcie KATE jest zgoła inna niż to, do czego przyzwyczaiła nas branża, prowadzimy to trochę
na zasadzie startupu. Wystartowaliśmy rok temu, w kilka osób, od ogólnej idei i prototypu na płytkach
ewaluacyjnych. Podczas konferencji automotive wzbudziliśmy zainteresowanie wewnątrz firmy i
akceptację na dalszy rozwój. Przez rok nasz zespół rozrósł się do 10 osób, aktualnie mamy działający
system z większością funkcjonalności. Wymagało to wymyślenia wielu rozwiązań koncepcyjnych
HW/SW, dziesiątek godzin burz mózgów oraz niezliczonych godzin implementacji, projektowania
układów elektronicznych oraz części mechanicznych. Wciąż mamy wiele pomysłów na rozszerzenie
systemu, jednak obecny plan zakłada, iż już niebawem wyślemy nasze prototypy na testy do klienta, by
poznać opinie branży. Wierzę, że tym projektem będziemy w stanie zaistnieć w branży automotive.

Co poradziłbyś osobom, które aspirują do zostania programistą w branży automotive? Czy trudniej jest znaleźć pracę w tej branży? Czy potrzebne są unikalne umiejętności, których nie wymaga się na innych projektach?

Od początkujących kandydatów na stanowisko programisty oczekujemy znajomości języka C lub C++
oraz ogólnopojęte rozumienie programowania dowolnych mikrokontrolerów. Oczywiście na plus jest
znajomość podstaw elektroniki, magistral komunikacyjnych czy języków skryptowych. Od nieco bardziej
zaawansowanych osób oczekujemy znajomości RTOS, Autosara, diagnostyki UDS, CAN, Etheret, Linux i
wiele więcej. Natomiast różnorodność projektów wymusza na nas elastyczne podejście, chyba jedynym
„must have” w naszej branży jest język C oraz mikrokontrolery.

Dla osób niemających doświadczenia, a chcących rozpocząć przygodę w świecie programowania
embedded w automotive, radziłbym zacząć od zabaw z płytką ewaluacyjną STM32. Wymyślenie jakiegoś problemu i, tworząc własne urządzenie, nauczenie się na niej programować w systemach czasu
rzeczywistego. Z takim projektem zapraszam do nas, do naszego krakowskiego biura na rozmowę.
Rekrutacja na stanowisko Junior Software Engineer jest otwarta, a każdy pomysłowy inżynier jest mile
widziany 🙂


Krzysztof Kmiotek

Krzysztof Kmiotek.

Senior Software Engineer w intive. Od 10 lat związany z programowaniem Embedded. W tym czasie pracował zarówno z małymi mikrokontrolerami programowanymi w języku C jak i większymi systemami pod Linuxem w C++. Pomysłodawca oraz leader krakowskiego systemu testowego hardware-in-loop KATE.

Zdjęcie główne pochodzi z unsplash.com.

Od trzech lat pracuje jako copywriterka, aktualnie zajmuje się tworzeniem treści dla branży IT oraz militarnej. Miłośniczka robienia szczegółowego researchu.

Podobne artykuły