Nazwa AUTOSAR często pojawia się w ogłoszeniach o pracę dla programistów embedded. Również na stanowiska juniorów. Rodzi to naturalne pytania. Czym jest AUTOSAR? Po co jest używany? Jak się go nauczyć? Ile muszę umieć do pierwszej pracy? Jak wygląda praca z AUTOSARem? W tym wpisie odpowiem na najczęstsze pytania.

Co to jest AUTOSAR?

Skrót AUTOSAR oznacza AUTomotive Open System Architecture. Jest standardem dla softu w branży automotive. Ale w praktyce mówiąc AUTOSAR mamy na myśli jedną z implementacji tego standardu. W praktyce jest to framework dla branży automotive zawierający system operacyjny, drivery sprzętowe, typowe biblioteki jak na przykład CRC, krypto, CAN. Można obrazowo powiedzieć, że to taki STM Cube MX dla samochodówki. Mamy graficzne narzędzie, gdzie możemy wyklikać konfigurację sprzętową, potrzebne moduły i inne informacje o projekcie i dostaniemy wygenerowany projekt, który następnie możemy rozszerzać.

Jest oczywiście kilka różnic. W Cube, PIC Harmony, LPC eXpresso i innych tego typu narzędziach generujemy projekty na sprzęt jednego producenta i możemy zintegrować popularne biblioteki open source jak lwIP, FatFS, FreeRTOS. AUTOSAR działa trochę inaczej.

Najpierw o tym standardzie i implementacjach. Na stronie projektu znajdziemy specyfikację AUTOSARa (jest ogromna, kilkaset pedeefów, łącznie dziesiątki tysięcy stron). Dodam jeszcze, że mówimy tutaj o AUTOSAR Classic. Od niedawna istnieje jeszcze AUTOSAR Adaptive. Aby robić oprogramowanie dla branży automotive trzeba spełniać AUTOSARa. Możemy albo pisać swoją implementację (w praktyce nikt tego nie robi), albo kupić istniejącą. To koszt rzędu dziesiątek tysięcy euro za pojedynczą licencję. Ale bez tego naszych produktów nie użyje żaden większy producent samochodów.

Mamy więc taki wielki generator projektów do branży automotive. Potrafi on wygenerować projekt na procesory różnych producentów i zintegrować ich peryferia z różnymi bibliotekami spełniającymi certyfikację dla branży samochodowej np. normę ISO26262.

Jaki problem rozwiązuje AUTOSAR?

Jak widzicie z poprzedniego akapitu – na pewno rozwiązuje problem zbyt małych zysków firm i zbyt dużej konkurencji na rynku, ale oczywiście nie jest to oficjalna wersja 😀

AUTOSAR powstał w 2003 roku przy współpracy największych graczy na rynku samochodowym takich jak BMW, Volkswagen, Ford i innych. Miało to ułatwić współpracę z podwykonawcami, przenoszenie softu na nowsze platformy sprzętowe i certyfikację produktów. Więcej o historii AUTOSARa znajdziesz na Wikipedii albo w dowolnym artykule z Googla. W każdym razie autorzy skupiali się na portowalności, integracji między różnymi producentami i zgodnością z normami dla branży samochodowej.

Wspólny standard spowodował również rozwój całego ekosystemu zawierającego narzędzia do debugowania, komunikacji, testowania, zarządzania wymaganiami, analizy kodu… krótko mówiąc – każdego elementu procesu wytwarzania oprogramowania. Dzięki temu każdy projekt w branży automotive wygląda z grubsza tak samo. Używa tych samych narzędzi, ma podobną architekturę, dokumentację, kod, wymagania itp.

Mimo, że AUTOSAR ma w nazwie Open, to tak naprawdę zamyka drzwi do branży automotive małym graczom. Wszystkie te narzędzia są cholernie drogie. A jeśli ich nie kupimy – najwięksi producenci samochodów nie będą używać naszych produktów. Stąd moja zgryźliwa uwaga na początku tego rozdziału.

A jak to wygląda z perspektywy programistów a nie firm?

Zacznijmy chronologicznie. Zanim będziemy robić projekty w AUTOSARze musimy się go jakoś nauczyć i dostać pracę w branży automotive. Logiczne wydawałoby się, żeby najpierw zdobyć trochę praktyki pisząc projekt „do szuflady”, a dopiero potem aplikować. Niestety w praktyce nie jest to możliwe.

Cena narzędzi powoduje, że jedyną drogą nauki jest tak naprawdę praca w firmie automotive. Nie jesteśmy w stanie zdobyć praktycznych umiejętności w temacie na własną rękę zanim podejmiemy pracę. Szkolenia z AUTOSARa również nam za bardzo nie pomogą. Nie ma sensu się uczyć na sucho bez możliwości pobawienia się samemu z kodem. Możliwe, że są już jakieś opcje np. dla studentów, ale nic mi o tym nie wiadomo.

Jak więc załapać się do pracy w automotive? Najlepszym, co możesz zrobić to po prostu zdobyć solidny warsztat jako programista embedded. Musisz znać język C, mieć doświadczenie z aparaturą pomiarową, debugiem na sprzęcie, komunikacją, peryferiami, Gitem, czy RTOSami. Najlepiej to wszystko przetestowane w boju na własnych projektach (mogą być hobbystyczne). A szczegółów już się nauczysz w pracy.

Firmy wiedzą jak wygląda sytuacja. Dlatego albo rekrutują osoby, które już pracowały w innych projektach Automotive, albo biorą pod uwagę, że nową osobę będzie trzeba wdrożyć w AUTOSARa. To, że masz doświadczenie w embedded, ale akurat nie w samochodówce nie ma większego znaczenia. Narzędzia tutaj są tak specyficzne, że i tak minie trochę czasu zanim staniesz się produktywnym AUTOSAR Developerem. Tak samo w drugą stronę – doświadczenie z AUTOSARa nie przenosi się w pełni do „normalnych” projektów.

Co dokładnie znajdziemy w AUTOSARze?

Standard definiuję architekturę dla systemów automotive. Wszystko znajdziesz na ich oficjalnej stronie.

Mamy tutaj kilka głównych elementów:

• Application Layer – Tutaj piszemy nasz kod
• RTE – Run Time Environment – to API do wywoływania elementów z niższych warstw
• Basic Software – to na diagramie wszystkie trzy rzędy między RTE a mikrokontrolerem. Tutaj znajdziemy drivery peryferiów, RTOSa, protokoły komunikacyjne itp.

Basic Software dzieli się na kolejne elementy:

Skrót ECU oznacza Electronic Control Unit. Każdy ECU obsługuję jakiś moduł elektrroniki samochodowej i najczęściej te moduły łączą się ze sobą po CANie.

W oficjalnej dokumentacji mimo, że jest bardzo obszerna, trudno znaleźć przydatne informacje. A wszystko przez bardzo formalistyczne podejście do pisania dokumentów. Najlepiej zobacz samemu – tak wygląda większość dokumentów w automotive. Dlatego nie polecam zaczynać nauki od studiowania wszystkich wymagań i specyfikacji. Mogę natomiast polecić dokument AUTOSAR Layered Software Architecture. Jest to prezentacja w powerpoincie, która omawia najważniejsze elementy autosara.

W projektach automotive rozwijamy Application Software – czyli najwyższą warstwę na schematach AUTOSARowej architektury. Mamy tu stosunkowo małe pole do popisu. Nasze funkcje są wywoływane jako callbacki we frameworku na przykład jako taski w systemie operacyjnym będącym częścią Basic Software. Najczęściej wywołujemy jakieś funkcje biblioteczne z wyklikanej konfiguracji i robimy operacje na danych. Następnie przekazujemy je znowu do funkcji bibliotecznych. Najczęściej w jakiś sposób interpretujemy komendy z CANa.

Tutaj znajdziesz projekt w AUTOSARze na GitHubie na podstawie przykładu od NXP. Daje całkiem dobre pojęcie jak wygląda kod w branży samochodowej.

A jak praca w Automotive wygląda w praktyce?

Przede wszystkim jest baaardzo sformalizowana. Mamy tutaj z jednej strony całą biurokrację z typowych korpo. W końcu projekty robimy dla dużych firm, albo jako ich podwykonawcy. Do tego dochodzi biurokracja związana z programowaniem pod normy safety-critical. Tak więc musimy wypełniać specjalne dokumenty, mamy różne specyficzne narzędzia, bardzo szczegółowe wymagania. A wszystko to w intuicyjnym formacie (sprawdziliście już dokumenty z oficjalnej strony AUTOSARa?). Częścią naszej pracy jest również rysowanie diagramów UML, różnych opisów, określanie jakie fragmenty kodu spełniają jakie wymagania.

W Polsce najczęściej mamy do czynienia z firmami z Europy, przede wszystkim z Niemiec. A one same w sobie mają duży stopień biurokracji.

Po zsumowaniu tego wszystkiego otrzymujemy stężenie korpobiurokracji niespotykane chyba nigdzie indziej. Czy to dobrze, czy źle? To zależy. Jednym taki tryb pracy pasuje, innym mniej. Wszystko zależy od indywidualnych preferencji.

Jeżeli dopiero startujesz w branży embedded – polecam w pierwszych latach spróbować swoich sił w branży automotive. Chociaż w jednym takim projekcie. A najlepiej w dwóch, żeby mieć porównanie co jest specyfiką projektu/firmy a co samego automotive. Wtedy na pewno dowiesz się, czy automotive jest dla Ciebie. A przy okazji będziesz już mieć w CV doświadczenie z AUTOSARem i zawsze Ci się to przyda w przyszłości. Bo jednak ofert jest bardzo dużo.

Warto też mieć na uwadzę, że jak chcesz dojść wyżej w automotive to musisz stricte specjalizować się w takich projektach. Właśnie dlatego, że są specyficzne narzędzia i sposób developmentu znacząco różni się niż w innych branżach. Kilka lat doświadczenia pozwoli Ci piąć się w górę w Automotive, natomiast do projektów niesamochodowych może być niezbyt użyteczne. Dlatego w pewnym momencie musisz podjąć decyzję, czy chcesz iść w tą stronę na poważnie, czy nie.

Mało programowania

Procesy i standardy takie jak AUTOSAR dążą w dużej mierze do ograniczenia swobody programistów do podejmowania decyzji albo wręcz do pisania kodu. W ten sposób firmy zmniejszają ryzyko błędów (szczególnie takich specyficznych dla ich konkretnej aplikacji) i ułatwiają sobie certyfikację. Za to developerzy często stają przed problemami w stylu – skąd w AUTOSARze wziąć dane X, albo co się dzieje pod spodem w Basic Software, kiedy wywołam te 5 linijek kodu?

Jak już wspomniałem – duża część projektu jest wygenerowana. My mamy kontrolę tylko nad małym fragmentem, który musi się wpasować do schematu. Architektura części aplikacyjnej i proces jej tworzenia również są mocno sformalizowane.

Developer często implementuje to, co wcześniej zostało narysowane w UMLu. Nieraz okazuje się, że diagram nie uwzględnia jakiś szczegółów i nie da się tego przenieść w 100% do kodu. Musimy wtedy ustalić wspólną wersję. Oto przykładowy UML z dokumentacji AUTOSAR:

Debugowanie i testowanie również jest oparte na gotowych narzędziach. Najczęściej klikamy jakieś przyciski w GUI i w ten sposób powodujemy wysłanie ramek po CANie. Następnie GUI się odświeża na skutek odebranych ramek. Możemy to nieraz oskryptować i zautomatyzować. Możemy konfigurować działanie własnych elementów GUI.

Po raz kolejny to kwestia preferencji, czy lubimy taki tryb pracy. Ja na przykład zawsze męczyłem się w projektach dla korpo z wielkimi zespołami i dużym stopniem formalizacji. Miałem poczucie, że narzędzia zmniejszają moją rolę z programisty do klikacza. Ale znam osoby, które cenią sobie stabilność, formalizację i taki shierarchizowany flow. Natomiast męczą się w małych projektach, gdzie mamy większą dowolność, musimy sami podejmować decyzje projektowe, a potem żyć z ich skutkami. Sytuacja szybko się zmienia, eksperymentujemy, nie jesteśmy pewni jakie rozwiązanie się sprawdzi. Ja z kolei takie projekty uwielbiam.

Ktoś ujął problemy AUTOSARa w śmiesznej i nieco przerysowanej opinii na Reddicie. Ale na pewno jest w niej ziarno prawdy. Może tylko przerysowane do absurdalnych rozmiarów.

Podsumowanie

Mam nadzieję, że teraz masz już jakiś ogląd na temat AUTOSARa i projektów, które go wykorzystują. Aby dowiedzieć się, czy praca w Automotive Ci odpowiada – musisz po prostu spróbować. Tym bardziej, że raczej nie zrobisz hobbystycznego projektu w AUTOSARze.

A jeżeli masz swoją opinie o pracy w Automotive, albo chcesz coś jeszcze dodać w temacie – koniecznie podziel się uwagami w komentarzu! Pomożesz w ten sposób wszystkim zastanawiającym się nad pracą w samochodówce.