Z poprzedniego odcinka można wywnioskować, jakie były wtedy największe problemy w software developmencie dla automotive:

1. Wynajdywanie koła ciągle od nowa - każdy dostawca wymyślał swoje rozwiązania dla standardowych funkcji systemu, a i to nie tylko raz. To są wielkie koszty i duże ryzyko że czegoś się nie uwzględniło albo nie przetestowało dobrze.
2. Brak jakichkolwiek standardów w kodowaniu specyficznych dla projektu modułów - to jest C, tu można wszystko. A jak można wszystko, to na pewno znajdzie się ktoś, kto zrobi coś paskudnego.

AUTOSAR (uwaga: piszę tu o wariancie zwanym Classic, tymczasem powstał jeszcze wariant Adaptative, przewidziany dla developmentu w C++ i raczej dla tych części nie real-time) stara się rozwiązać oba te problemy. Przy pierwszym: Do standardowej funkcjonalności wymyślono standardowe moduły, z dobrze wyspecyfikowanym API, konfigurowane przy pomocy plików XML (rozszerzenie .arxml). Idea jest taka, żeby te standardowe moduły były produkowane przez wyspecjalizowane firmy, a wszyscy mają je po prostu kupować i stosować. Wymyślono również standardowe moduły driverów sprzętu - producenci używanych procesorów dostarczają te drivery (zwane MCAL - MicroController Abstraction Layer) użytkownikom.

Drugi problem ma załatwić standardowa metodologia tworzenia modułów, Idea jest taka, że tworzymy opis modułu z jego portami, interfejsami itd. w ARXMLu. Od swojej strony uzupełniamy go tylko trochę kodem, a połączenia międzymodułowe są również definiowane w ARXMLu. W trakcie budowania systemu generowany jest kod "klejący" te moduły.

Logo AUTOSAR

Ogólnie idea nie jest zła. Zalety:

• Moduły standardowe mogą być porządnie zrobione i solidnie przetestowane przez wyspecjalizowane zespoły, koszt tego rozkłada się na mnóstwo projektów, a nie tylko na kilka u jednego dostawcy.
• Moduły specyficzne dla projektu dostają sensowne ograniczenia swobody robienia głupot.
• Reusowalność modułów jest lepsza, dzięki porządnej, formalnej definicji ich interfejsów.
• Rozwiązanie idzie cokolwiek w modnym obecnie kierunku low code. To nie jest złe.

Są też problemy:

• To jest jednak zasadnicza zmiana paradygmatów, z niskopoziomowego rzeźbienia w C na modelowanie obiektów. Niestety użytkownicy (czytaj: developerzy) nie są w szerokiej masie do tego przygotowani.
• Przy modułach standardowych problem w sumie tylko przesunął się z poprawnego kodowania na poprawne konfigurowanie, ale nie stał się przez to wiele prostszy. A nawet przeciwnie - specyfikacja jest o wiele bardziej złożona niż własne rozwiązania, ma o wiele więcej możliwości i jest trudniej.
• Nie wszystko wyszło super - są kawałki w których specyfikacja nie jest zbyt dobra i trzeba mocno kombinować, albo wręcz ją omijać.
• W specyfikacji przyjęto pewien model hardware, który nie zawsze jest spełniony. Na przykład w aktualnym projekcie używamy procesora który jest de facto niekompatybilny z AUTOSARem w jednym punkcie (długo by opisywać, ale chodzi o pewne, dość nieoczekiwane zależności w sprzęcie) i trzeba było się narobić żeby ten problem ominąć.

Pierwszą jako-tako nadającą się do użytku wersję specyfikacji AUTOSARa wypuszczono w roku 2007 jako wersję 3.0, a w końcu 2009 pojawiła się wyraźnie lepsza wersja 4.0. Podejście proponowane przez konsorcjum było jednak na tyle inne od dotychczasowego, że akceptacja standardu była bardzo powolna. Najpierw projekty tylko eksperymentowały z nową technologią. No ale członkowie konsorcjum chcieli wreszcie mieć coś z tych lat wkładania kasy, i powoli zaczęli wymuszać używanie nowego standardu przez dostawców. Pierwszy całkiem AUTOSARowy projekt zrobiony u nas zaczął się gdzieś w 2013, i ja tam trafiłem już w stosunkowo wczesnej fazie.

Dalej w następnym odcinku.

Trzy lata to sporo czasu, uzasadnione jest pytanie co ja właściwie robiłem, że nie miałem czasu nawet na naprawienie bloga. Bardzo chętnie o tym opowiem, opowieść będzie dłuższa. Czas nie był zmarnowany, stąd tytuł (zapożyczony oczywiście). I uprzedzam z góry, że cykl będzie zawierać spore elementy autoreklamy 🙂 No i pewnie wykorzystam to, co tu piszę jako pierwszy szkic szkicu moich przyszłych prezentacji.

Zacznijmy od tego, że praca w branży samochodowej nie zaspokaja mojej potrzeby kreatywności. Typowy projekt w tej branży to implementacja dokładnych requirementów klienta. Nieważne jak dobre są twoje pomysły, trzeba spełnić requirementy i już. Niektóre z tych requirementów są negocjowalne, ale dotyczy to raczej zbyt wygórowanych wyobrażeń klienta co do tego, co jest możliwe. Nowa funkcjonalność, albo znaczące zmiany w zdefiniowanej funkcjonalności mają przyzerowe szanse na akceptację przez klienta.

W związku z tym można coś tworzyć jedynie w architekturze, implementacji i toolingu. Z tym że z tym toolingiem to też nie tak prosto - w korpo jest specjalny dział, który zajmuje się toolingiem i przeforsowanie swoich pomysłów na skalę większą niż aktualny projekt jest mało realne.

Mój pierwszy projekt w automotive robiłem około roku 2001 (Headunit AUDI C6, to ta skrzyneczka ze szczeliną na CD i przyciskami, ta w głębi).

Małe stanowisko testowe elektroniki do Audi A6

Cały nasz zespół był nowy w tej działce, musieliśmy nauczyć się mnóstwa rzeczy, jak to się robi w automotive. A robi się tak:

• Większość kawałków do automotive to są rzeczy real-time (zainteresowanym radzę nie czytać hasła z polskiej wiki, bo bez sensu jest) - znaczy muszą reagować w czasie nie dłuższym niż zdefiniowany. W większości wypadków nie ma żadnego GUI.
• Jeżeli jakieś GUI jest (na przykład cluster, navi czy HUD), to typowo rozdziela się część real-time i część od GUI. Znaczy każda z tych części ma osobny core procesora (każdy core może być totalnie inny), albo mieć swój procesor.

Dalej skupimy się na tej części niegraficznej - bo jednak ta grafika to jest w nielicznych kawałkach elektroniki samochodowej. Więc te kawałki niegraficzne:

• Są podłączone do jakiegoś busa, zazwyczaj CAN. No i oczywiście muszą obsługiwać komunikację w dwie strony i z wymaganiami (teraz wiele telegramów jest E2E protected i/lub szyfrowanych)
• Ponieważ to jest real-time, to musi w tym chodzić regularny multitasking, z przerwaniami oczywiście też.
• Każdy kawałek zapamiętuje swoje błędy, czyli musi mieć pamięć nieulotną.
• Ostatnimi czasy w to wszystko wchodzi poważne security z kluczami publicznymi i prywatnymi, certyfikatami, Certificate Authority itd.
• Część z tych kawałków jest istotna dla bezpieczeństwa i w tym momencie wchodzą wymagania functional safety, z wszystkimi tego konsekwencjami.
• Używany sprzęt jest bardzo różny, procesory użyte w kolejnych projektach mogą się różnić wszystkim, nawet byte orderem, i trzeba o tym pamiętać przy kodowaniu.
• Językiem w którym to się pisze jest najczęściej C, znacznie rzadziej C++ (to raczej przy tych częściach z GUI, ale nie tylko).
• Niemal każde urządzenie jest produkowane w różnych wariantach, na przykład do różnych modeli samochodów, albo może używać przykładowo wyświetlaczy od różnych producentów. W związku z tym, kod zawiera mnóstwo konstrukcji #ifdef #else #endif.
• Programiści pecetowi nie zdają sobie tego sprawy, ale w embedded pamięć występuje w wielu rodzajach w jednym systemie. Pecet ma RAM i już - w embedded mamy szybki RAM, wolny RAM, szeregowy RAM, video RAM, code FLASH, data FLASH, EEPROM, RAM z podtrzymaniem, ..., każdy rodzaj ma inne właściwości, prędkość, sposób dostępu ... . I przy każdym obiekcie musimy powiedzieć, w której pamięci on ma wylądować. I pilnować, żeby się zmieściło. Do tego bywa że na przykład, że dostęp do adresów nieparzystych jest o wiele wolniejszy niż do parzystych, i trzeba to uwzględniać.
• Przy programowaniu na pececie operujemy na abstrakcjach sprzętu. Mechaniczny wyłącznik ma na pececie stany wyłączony i włączony, a w embedded musimy uwzględniać na przykład drgania styków. Innego sprzętu to też dotyczy - trzeba uwzględniać całą fizykę stojącą za sprzętem.
• O, fizyka - pamięci EEPROM/FLASH mają ograniczoną ilość zapisów, które są w stanie znieść, i trzeba liczyć, czy to wystarczy na planowany czas życia samochodu. W Tesli dowiedzieli się o tym dopiero niedawno i musieli zrobić recall na sto kilkadziesiąt tysięcy samochodów z wymianą sprzętu, bo coś bez umiaru pisało logi do flasha.
• W pececie nie musimy martwić się zasilaniem - ono po prostu jest. W samochodzie musimy uwzględniać, że napięcie zasilania może być zbyt niskie lub zbyt wysokie (chwilowo lub trwale), i odpowiednio reagować.
• Podobnie z temperaturą - jak urządzenie robi się za gorące, trzeba reagować (na przykład wyłączając coś, co się grzeje).
• I tak można jeszcze długo - w automotive praktycznie nie występują programiści po "normalnej", pecetowej informatyce. Niemal wszyscy są po studiach mniej lub bardziej związanych z elektroniką, informatycy którzy tu czasem trafiają wkrótce uciekają z krzykiem.
• Używany procesor nigdy nie jest za mocny - zawsze jest dobrany tak sknersko, że trzeba się nagimnastykować żeby się wyrobił. Podobnie pamięci nigdy nie ma za dużo.

Dla porządku jeszcze trochę o kawałkach z GUI:

• GUI zazwyczaj chodzi na derywatach UNIXa, z klasycznym POSIXowym API.
• Część graficzna ma często podłączony jakiś mocniejszy bus, na przykład Ethernet albo MOST.
• Języki programowania są tu różne, najczęściej to C++, ale widziałem na przykład projekt w Javie.

Jeszcze jakieś 10 lat temu, każda z firm robiących te kawałki prawie wszystko robiła sama - udział standardowego kodu był znikomy. Projekty dla różnych klientów przez jedną firmę miały często tą samą funkcjonalność robioną całkiem inaczej, reusability było niewielkie. To jest oczywiście koszt i potencjalne ryzyko, więc większość wiodących firm samochodowych i główni poddostawcy zawiązali w roku 2002 konsorcjum, które miało ten stan rzeczy zmienić. Nazwano to AUTOSAR. Założenia AUTOSARa omówię w następnej notce, a potem dojdę do miejsca, w którym wkraczam do gry 🙂