Gdzieś między Polską a Niemcami, a szczególnie w NRD

Jak napisałem w poprzednim odcinku, na początku nie doceniłem stopnia komplikacji metamodelu AUTOSARa. A było to tak:

• Metamodel definiuje mnóstwo klas obiektów i relacje między nimi (parent-child i asocjacje), To jeszcze nie jest nic specjalnego, mimo że obiektów jest mnóstwo.
• Metamodel jest dystrybuowany jako projekt w EA. Można go sobie wyeksportować w formacie XMI, czyli wariancie XMLu. Jest też w formacie Ecore.
• Parsowanie XMLa nie jest żadnym problemem, wygenerowanie wczytanej informacji tak, jak potrzebuję to też trywiał.

No i ta trywialność mnie zmyliła. Przeoczyłem jedną, bardzo istotną rzecz: Typowy projekt w automotive musi obsługiwać warianty. O co chodzi? Po prostu ten sam kod jest używany na przykład w różnych modelach samochodów, z różnym wyposażeniem. Albo może współpracować na przykład z wyświetlaczami od różnych dostawców. To są właśnie te warianty. Typowo wariant wybiera się przy kompilacji przez ustawienia jakichś #define (pre-build) albo w jakiś sposób wybiera konfigurację przy wykonaniu programu (post-build), ale AUTOSAR usystematyzował to. Technicznie (i w uproszczeniu) wygląda to tak, że do wielu obiektów można podczepić obiekt klasy VariationPoint, w którym jest zapisane (jako logical expression), dla jakich wariantów dany obiekt obowiązuje, i kiedy najpóźniej ma nastąpić wybór wariantu.

No i w czym problem?

• Metamodel nie zawiera obsługi wariantów wprost - obiekty które mogą mieć warianty są tylko oznaczone odpowiednim stereotypem.
• Żeby metamodel dał się używać w praktyce, trzeba go przetransformować do takiego z wariantami. Transformacje modyfikują strukturę metamodelu i dodają nowe obiekty.
• Jest w opisie standardu dokument opisujący te transformacje, ale:
  • To jest skomplikowane jak jasna cholera.
  • W paru miejscach transformacje są niedospecyfikowane.
  • W innych miejscach dokument ma oczywiste błędy. Drobne, ale trzeba je znaleźć.
  • W praktyce trzeba zajrzeć do rzeczywistych plików zrobionych w działających narzędziach, żeby zobaczyć jak naprawdę ma być (a przynajmniej mieć tam takie same błędy jak wszyscy 🙂 - to się nazywa "kompatybilność").
• No i oprócz tego same metamodele mają trochę błędów, zwłaszcza we wczesnych wersjach, i trzeba co nieco skorygować ręcznie.

No dobrze, powiecie, ale przecież ktoś już to musiał zrobić, inaczej nie istniałyby jakiekolwiek narzędzia do tego AUTOSARa?

Tak, zrobiło to konsorcjum, w Javie, jako plugin do Eclipse. Znaczy to jest wygenerowany handler do plików ARXML i do zarządzania tymi obiektami. Nazywa się to Artop, i jest dostępne po rejestracji. Wszyscy (chyba z wyjątkiem IBMa, który raczej zrobił wszystko ręcznie, i LieberLiebera, który na pewno zrobił ręcznie) używają tego Artopa. Wyjaśnia to, dlaczego wszystkie toole do AUTOSARa bazowane są na Eclipse - po prostu nikt inny nie przebrnął przez ten problem i nie zrobił swojego handlera.

Logo Artop

Jak możecie się domyślać, nikt poza mną. To była druga najbardziej skomplikowana rzecz, jaką w życiu robiłem, dwa miesiące mi zajęło żeby doprowadzić to do działania, żeby móc importować i eksportować pliki AUTOSARowe zgodnie z metamodelem dla danej wersji. I jeszcze jak potem intensywnie rzecz testowałem, poznajdowałem i poprawiłem trochę błędów i problemów, co też dobry tydzień zajęło. Ale działa - jako jedyny na świecie niezależny taki handler. Nie wrzucam kodu transformera na żadną chmurę, githuba, ani nic podobnego - tylko na moje serwery niedostępne z zewnątrz, nie mogę ryzykować, że wycieknie.

Moje podejście jest inne, niż w Artopie - oni na podstawie metamodelu generują kod w Javie, ja generuje pliki z danymi metamodelu, interpretowane przez mój kod napisany ręcznie. Moje podejście jest elastyczniejsze - generuję raz, i używam do dowolnych celów, oni dla nowego celu muszą modyfikować generator i generować ponownie. Oprócz tego oni mają - według mnie - błędną koncepcję obsługi plików wygenerowanych według różnych wersji specyfikacji - używają najnowszej znanej wersji i bazują na kompatybilności wstecznej, a to może robić problemy. Ja obsługuję każdy plik w jego indywidualnej wersji, również jak są wczytane jednocześnie.

W następnym odcinku parę generalnych uwag na temat MDD.

Następny mój projekt był dla gwiazdkowców.

Wyświetlacze S-Klasse (Źródło: Materiały prasowe Daimler AG)

Tu nie był to cluster, tylko te dwa wyświetlacze, ten po prawej miał touch. Obraz dla nich był generowany przez inny kawałek sprzętu, nie od nas. Kod był w bardzo dużej części wspólny dla obu urządzeń, oba miały też mniejsze wersje dla E-Klasse.

Sytuacja rynkowa zmieniła się tymczasem:

• Moje korpo zrezygnowało z tworzenia własnych modułów standardowych, i po prostu kupiło firmę tworzącą takie. Na największego na rynku Vektora nie mieli dość kasy, kupili drugą firmę w kolejności - Elektrobit, z ich Tresosem.
• Korporacyjne narzędzie do ARXMLi zrobiło się abandonware, ale jest używane do dziś, bo nie ma nic lepszego do dyspozycji.
• Vektor udoskonalił swoje narzędzie do konfiguracji modułów, ale ono jest w korpo politycznie niekoszerne. To narzędzie też jest w Eclipse. Potrafi robić również diagramy, ale w ograniczonym asortymencie i nie w UMLu.
• Pojawiło się inne narzędzie do ARXMLi, francuskie, firmy Dassault (tak, ci od samolotów), też na bazie Eclipse, nazywa się Autosar Builder. Ładnie wygląda, ma dużo teoretycznie świetnych narzędzi, ale to niestety typowy przykład co wychodzi, gdy narzędzie tworzy ktoś, kto go nie używa. To się po prostu do niczego nie nadaje i szybko wypadło z obiegu.

Ten projekt był pierwszym w korpo, w którym użyto modułów i narzędzi od kupionego właśnie Elektrobitu. No i oczywiście to ja miałem doprowadzić to wszystko do działania. Przećwiczyłem generację projektu w różnych kombinacjach dobre kilkaset razy, zrozumiałem wszystko, doprowadziłem rzecz do działania, ale MDD nie było w tym nawet śladu.

Ale pewnego dnia pojawił się Autosar Engineer, małej firmy LieberLieber z Wiednia. Był to plugin do Enterprise Architecta. Obejrzałem go - i poczułem się poważnie ztriggerowany. A jeszcze poważniej gdy ktoś zaproponował, żeby go użyć w projekcie. Już od dłuższego czasu planowałem takie narzędzie zrobić, to miało być przecież moje!

(nie chcę linkować do stron LieberLiebera, istnieje niezerowe prawdopodobieństwo, że przez analitykę znajdą źródło linka, przetłumaczą sobie googlem i teraz oni poczują się ztriggerowani).

Wiec przyjrzałem się temu dokładniej. Oni zrobili to tak:

• Wybrali sobie z AUTOSARa trochę co częściej używanych obiektów
• Zrobili ręcznie profil UML i MDG Technology z tymi obiektami.
• Lekko scustomizowali EA tak, jak on na to pozwala w łatwy sposób.
• Dorobili parę funkcji przez API EA, parę ikonek i obrazków i tyle.

To było naprawdę mało, i to mnie ruszyło. Ponieważ miałem już sporo doświadczenia z EA (chociaż ponad 10 lat wcześniejszego) i wstępną analizę problemu już robiłem to stwierdziłem, że przecież w dwa tygodnie mogę mieć tyle samo, a w cztery coś znacznie lepszego!

Więc zacząłem. Kupiłem Enterprise Architecta (dał się odliczyć od podatku 🙂 ) wziąłem Visual Studio Community Edition i ostro ruszyłem. W Javie napisałem wczytanie danych z metamodelu AUTOSARa, zagenerowałem z tego pliki profili i technology dla EA i w C# porobiłem trochę potrzebnej funkcjonalności jako plugin EA.  Całość nazwałem dumnie MaximumAUTOSAR, że niby ma to być docelowo AUTOSAR to the max. W cztery tygodnie faktycznie miałem coś o wiele lepszego niż ten LieberLieber, ale oprócz tego bardzo istotny wniosek - że tak zrobione, to nigdy nie będzie dobre. Z dwóch przyczyn:

• Pierwsza to braki w API EA. Paru absolutnie podstawowych rzeczy nie dało się zrobić customizując ich standardowy Project Manager i inne okienka.
• Druga leżała po stronie AUTOSARa i mojej. Moim założeniem było że wezmę sobie metamodele udostępniane przez konsorcjum i przetransformuję je programowo na pliki profilu/technologii EA. I tu nie doceniłem problemu. Szczegóły w następnych odcinkach.

Tak więc pojawiło się prawdziwe wyzwanie - nikt na świecie dotąd nie zrobił odpowiedniego narzędzia do AUTOSARa, i nie wyglądało żeby ktoś - poza mną - był w stanie to zrobić. Padł na tym nawet IBM, a wszyscy inni ograniczali się do rozwiązań bazujących na Eclipse (nie bez przyczyny - o tym dalej). A w Eclipse nie za bardzo da się zrobić modeling tool (chociaż niektórzy próbują, na przykład coś takiego).

A dlaczego nikt poza mną ma nie być w stanie? Bo to jest tak:

• Fachowcy od takich narzędzi nie mają pojęcia o AUTOSARze i nigdy nie robili aktywnego developmentu w tej działce (to był przypadek IBMa i Dassault), stąd nie wiedzą, co jest naprawdę potrzebne i jak to ma działać.
• Fachowcy od AUTOSARa nie mają pojęcia o robieniu takich tooli (cała reszta próbujących).

I na placu boju pozostaję ja, cały na biało.

Oprócz tego wkrótce LieberLieber wywalił cały ten projekt do kosza, więc na boisku zostałem prawie sam. Prawie, bo jest jeszcze jeden team: jacyś ludzie zrobili support AUTOSARa w MatLabie. Umieją wczytywać i wypisywać te ARXMLe i cośtam z tego generować. Na szczęście nie są oni dla mnie prawdziwą konkurencją, bo MatLab zasadniczo nie umie w UMLa i design (on nie do tego został wymyślony), i prawdziwe MDD to to jednak nie jest.

Ciąg dalszy oczywiście nastąpi.

Moim pierwszym projektem AUTOSARowym był taki dla trójliterkowców.

Cluster BMW Gen4 (Źródło: gdzieś z sieci)

W tym okresie na poważnie zaczęły wchodzić clustery całkowicie wyświetlaczowe, ale niektórzy klienci mieli wątpliwości. Ten klient uważał, że użytkownicy chcą widzieć prawdziwe, trójwymiarowe wskaźniki, a nie płaski obraz. Robili u nas dla nich testowo modele z wyświetlaczem 3D, ale klient zdecydował się na cluster ze wskazówkami i sporym wyświetlaczem (zwracam uwagę, że dolne części dużych wskaźników są rysowane na wyświetlaczu). Ale żeby przyzwyczajać klientów do nowej technologii, szybka miała być ciemna. W związku z tym widać było tylko to, co świeci, i cluster wyglądał wcale nie 3D, tylko bardziej płasko niż odpowiednio narysowany obraz na płaskim wyświetlaczu. Zdjęcie jest znalezione w sieci, tu szybka jest całkiem przejrzysta, w sumie nie wiem kiedy to zmieniono. Przy całym developmencie mieliśmy tylko przyciemniane szybki. Ale dość dygresji.

To był też pierwszy prawdziwie AUTOSARowy projekt w fabryce, w związku z tym wszystko dla wszystkich było nowe. Zacznijmy od ówczesnego stanu rynku w tej działce:

• Moje korpo (w końcu jeden z głównych członków konsorcjum) zrobiło własne moduły standardowe i własne narzędzie do ich konfiguracji i robienia ARXMLi dla własnych modułów. Narzędzie było zrobione na bazie Eclipse, moduły miały duże braki w funkcjonalności.
• Moduły MCAL były dostarczone przez producenta procesora (Renesas) i konfigurowane przy pomocy narzędzia zwanego Tresos, zrobionego przez firmę Elektrobit z Erlangen. To narzędzie było też oparte na Eclipse.
• OS (system operacyjny) został kupiony od firmy Vektor Informatik. To jest wiodąca firma z branży narzędzi dla branży okołosamochodowej, wybiła się ona głównie na programie i sprzęcie do symulacji komunikacji na magistrali CAN, zwanym CANoe.
• Oprócz tego parę innych, mniejszych firm od narzędzi próbowało wtedy wejść na rynek AUTOSARa, ale bez większych sukcesów.

Zacząłem czytać specyfikację AUTOSARa, ale potrwało ze dwa miesiące zanim zacząłem chociaż z grubsza rozumieć, co tam jest napisane. Tymczasem zostałem poproszony żeby zrobić skrypty do generacji kodu przy pomocy tego korporacyjnego narzędzia, i tak się zaczęło.

Im dalej wgłębiałem się w specyfikację, tym bardziej widziałem, że to wszystko jest robione z myślą o modelowaniu, znaczy MDD (Model Driven Development). I to mi się podobało. Bo:

Mój pierwszy projekt w automotive, około 2001, był robiony w Rhapsody (wtedy jeszcze firmy I-Logix z Izraela), całkowicie MDD, z generacją kodu z modelu. Całego kodu - przede wszystkim ze statechartów. I wyszło nieźle. To był okres hype na modelowanie, wszyscy tego próbowali. Jeszcze następny projekt - nie w automotive - robiłem w MDD, z Enterprise Architect, tu akurat to ja opracowałem cały proces, i efekty były świetne. Potem hype opadł, bo w wielu zastosowaniach generacja kodu z modelu była zbyt wolna, albo ludzie mieli zbyt wygórowane oczekiwania, albo robili coś źle... Ale według mnie MDD to jest ten "właściwy" sposób robienia softu.

Więc zacząłem rozglądać się za narzędziem. Wcześniej w korpo używali Borland Together Architect, ale to była beznadzieja. Zauważyłem jednak, że właśnie przeszli na Rhapsody, tymczasem IBM Rhapsody. A po dokładnym obejrzeniu go odkryłem, że jest tam coś do AUTOSARa.

Coś tam było, ale dokumentacji do tego było wszystkiego kilka stron gdzieś bardzo głęboko w sieci, te strony mówiły o AUTOSARze v3.x, a dołączony pakiet implementował wersję 4.0.2. Co najmniej połowa informacji na tych stronach już na starcie nie zgadzała się z rzeczywistością. Musiałem mocno poeksperymentować, żeby dojść jak to w ogóle da się używać i co to robi. No ale jakieś ARXMLe do modułów dało się w tym wygenerować. Udało mi się też połączyć je z kodem, ale wygodne w użyciu to nie było. Przy generacji kodu pojawił się kolejny problem - generator kodu Rhapsody był w roku 2001 w pełni konfigurowalny i open source, w 2013 już nie. Konfigurować dał się on tylko setkami properties w ustawieniach, z których jakieś 3/4 było nieudokumentowane, przy większości trzeba było w ogóle wiedzieć, że takie nigdzie nie opisane property w ogóle istnieje. Do tego ten generator kodu był zrobiony dla programów pecetowych, był tam jakiś wbudowany scheduler (zwany frameworkiem), który oczywiście totalnie nie pasował do pojedynczego modułu schedulowanego z zewnątrz istniejącym schedulerem.

Po dłuższych poszukiwaniach znalazłem jakiś dokument opisujący oficjalnie niesupportowany wariant generowania kodu bez tego frameworku, i nawet udało mi się coś z sensem wygenerowac. Po drodze udało mi się nawiązać kontakt z dwoma głównymi developerami Rhapsody, byłem takim key userem tego całego ficzera, że dwa razy kopsnęli się do mnie z Izraela do Niemiec, żeby przedyskutować ze mną moje problemy. Nawet dołączyli rozwiązanie części tych problemów do następnego releasa Rhapsody (wersja 8.1.3, jeżeli dobrze pamiętam), ale nie przeszedłem na nią, bo pozmieniali tyle innych rzeczy, że nie udało mi się dopasować projektu do tej wersji w rozsądnym czasie.

Jednym z problemów było to, że po każdej generacji kodu musiałem robić drobne poprawki w generowanym kodzie. Ja mogłem z tym pracować, twardy jestem, ale nie dało się tego dać do ogólnego użytku. Ale nawet w takiej wersji uratowałem przed skancelowaniem przez klienta (i paroma bańkami w plecy dla korpo) projekt pochodny od tego pierwszego, robiąc statecharty i generując z nich kod. To była ta akcja z wyjazdem do Meksyku, o której pisałem.

Cluster BMW Gen 3.1 (Źródło: gdzieś z sieci)

Jak widać, ten cluster ma też fragment zegara rysowany na wyświetlaczu, ale tu klient od razu zrezygnował z ciemnej szybki. Nie wiem czemu podświetlenie jest na pomarańczowo - sam zmieniałem je na białe, bo klient już pod koniec projektu powiedział, że pomarańczowe jest odbierane jako dziaderskie i żeby to zmienić. No ale kolor podświetlenia był konfigurowalny przez coding, pewnie w niektórych wersjach wrócili do pomarańczowego

Niedawno zajrzałem, co IBM zrobił przez te kilka lat z supportem AUTOSARa w Rhapsody - i nic nie zrobił. Nadal znajdują się dokładnie te same strony z opisem do od lat nieaktualnej wersji, nic się nie zmieniło, sprawa umarła, największy gracz odpadł.

No ale to nie koniec. Dalej w następnym odcinku.

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 🙂