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

Czas nieutracony (2) – Standardy

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

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.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Programowanie

Sledz donosy: RSS 2.0

Wasz znak: trackback

-----------------------------------------------------------------------------------------------------------------------


1 komentarz do “Czas nieutracony (2) – Standardy”

  1. Avatar photo boni pisze:

    Nahle poczułem potrzebę, że też muszę opisać naszą graciarnię za ostatni rok, a szczególniej Epopeję Drukarkową w kontekście dostaw na kraniec cywilizowanego świata, bo dalej, to już się spada z krawędzi (tj. do Irlandii).

    PS. A wszystkie literki o projekcie, systemach i programowaniu wyczytałem z najwyższą przyjemnością, oczywiście. Kiedyś myślałem, że jak będę duży, to też będę robił rzeczy „w tym stylu”, w mojej branży, ale potem mi przeszło…

Skomentuj i Ty

Komentowanie tylko dla zarejestrowanych i zalogowanych użytkowników. Podziękowania proszę kierować do spamerów