AUTOSAR CDD – „do’s”, „don’ts” and best practices

Powstałe w 2003 roku konsorcjum AUTOSAR (AUTomotive Open System ARchitecture) postawiło sobie za główny cel zestandaryzowanie architektury oprogramowania dla branży Automotive.

Standaryzacja została wymuszona ogromnym wzrostem ilości oprogramowania we współczesnych samochodach, mnogością platform sprzętowych, dużą ilością niekompatybilnych ze sobą konkurencyjnych rozwiązań, małym reusability między systemami (oraz generacjami).

Konsorcjum skupiło się na standaryzacji najważniejszych komponentów systemu: stosów komunikacyjnych (CAN, Eth, SPI), stosu obsługi pamięci nieulotnej, obsługi watchdogów, systemu zarządzania błędami (DTC).

Oczywiście zdawano sobie sprawę, iż nie uda się zdefiniować standardu dla wszystkich funkcjonalności, zwłaszcza bardzo specyficznych dla końcowego klienta (OEM) czy też obszaru działania systemu. Z tego powodu zarezerwowano w architekturze AUTOSAR obszar zwany Complex Device Drivers (CDD), w którym powinna się znaleźć obsługa funkcjonalności nieopisanych w dokumentacji. Niestety nie zawsze CDD jest wykorzystywane zgodnie ze swoim przeznaczeniem. Co dokładnie powinno się w nim znaleźć, a czego tam nie umieszczać – omówimy w tym artykule.

1. Architektura AUTOSAR

Aby przejść do sedna, przypomnijmy ogólny zarys architektury AUTOSAR oraz przeznaczenie poszczególnych warstw. Pozwoli nam to lepiej zrozumieć kontekst w jakim znajduje się CDD.

1.1. Spojrzenie wysokopoziomowe

Na najbardziej ogólnym poziomie, architektura AUTOSAR składa się z 3 warstw (Rysunek 1).

Warstwa Aplikacji, jak nazwa wskazuje, jest przeznaczona na komponenty aplikacyjne. Tutaj powinniśmy umieszczać software komponenty (SW-C), które odpowiadają za logikę systemu. SW-C powinny być zaimplementowane tak, aby były zupełnie niezależne od sprzętu i operowały na pojęciach abstrakcyjnych, jak temperatura, ciśnienie, stan ON/OFF… – bez znaczenia czy dane te pochodzą od innych SW-C, czujników fizycznych, obliczeń symulacji, czy też z danych przysłanych protokołami komunikacyjnymi.

W warstwie Aplikacji AUTOSAR nie definiuje modułów ani ich funkcjonalności (jest to oczywiście zależne od projektu), narzuca natomiast rodzaje interfejsów i punktów dostępu (zwanych PORTAMI) oraz sposobów, w jaki SW-C mogą się komunikować ze sobą oraz światem zewnętrznym. Często OEM dostarcza cześć lub wszystkie SW-C. Standaryzacja AUTOSAR ułatwia integrację warstwy aplikacji.

Warstwa RTE łączy ze sobą BSW oraz APP, jest także odpowiedzialna za całą komunikację pomiędzy SW-C. Odcina warstwę aplikacji od świata fizycznego i uniezależnia od sprzętu. RTE wraz z BSW implementuje koncepcję Virtual Functional Bus (VFB) – po szczegóły odsyłam do dokumentacji AUTOSAR.

Najniższa warstwa – BSW – odpowiada za obsługę sprzętu, a jej implementacja jest mocno od niego zależna. AUTOSAR bardzo szczegółowo definiuje moduły tej warstwy – ich zachowanie oraz interfejsy. W tej warstwie nie powinniśmy implementować logiki aplikacyjnej.

1.2. Basic Software (BSW)

Przyjrzyjmy się nieco dokładniej warstwie BSW

Możemy tutaj wyróżnić 3 podwarstwy oraz interesujący nas blok CDD.

Tym razem zaczniemy od warstwy najniższej – Microcontroller Abstraction Layer (MCAL). Odpowiada ona za obsługę mikrokontrolera, na którym uruchomiony jest nasz system. Warstwa ta najczęściej dostarczana jest przez producenta procesora. MCAL ujednolica interfejs do peryferiuów uC, umożliwia to stosunkowo łatwe portowanie systemu na inne platformy – „wystarczy” podmienić MCAL dedykowany dla nowego sprzętu.

Electronic Control Unit Abstraction Layer (ECUAL) to kolejna warstwa obsługi sprzętu, odpowiedzialna za obsługę elementów współpracujących z naszym uC (wszelkie ASIC, zewnętrzne pamięci, watchdogi, sensory, etc). Oczywiście do komunikacji ze światem zewnętrznym używa ona   abstrakcji MCAL.

Warstwa serwisów (Services Layer) odpowiada za zarządzanie i ujednolicenie interfejsów dla obsługi konkretnych urządzeń, np. dostarcza interface Nvm_Write(idx) do obsługi pamięci nieulotnych w systemie. Warstwa ta zawiera także system operacyjny czasu rzeczywistego, dlatego z lewej strony rysunku, styka się bezpośrednio z uC. Service Layer odpowiada za dostarczenie informacji warstwie aplikacji poprzez RTE.

W przeciwieństwie do warstwy aplikacji, wszystkie powyższe warstwy BSW są bardzo szczegółowo zdefiniowane przez standard AUTOSAR (interfejsy, zachowanie modułów, w jaki sposób moduły muszę się ze sobą komunikować, jakie są możliwe konfiguracje). Szczegółowa dokumentacja jest dostępna na stronie autosar.org.

No i wreszcie blok CDD (Complex Device Drivers), rozciągający się bezpośrednio od uC do warstwy RTE, który omówimy w dalszej części.

1.3. Stosy

Warstwę BSW możemy także rozpatrzyć pod kątem realizowanych funkcjonalności. Jak widać na rysunku 3, da się wyodrębnić stosy rozciągające się przez wszystkie warstwy BSW, realizujące konkretne funkcjonalności poprzez obsługę peryferiów uC, układów zewnętrznych (ASIC) oraz dostarczanie abstrakcyjnych interfejsów dla RTE.

Poniżej bardziej szczegółowy przykład stosów watchdog oraz NVM:

2. Complex Device Drivers

Jak to było przedstawione w rozdziale 2.2, CDD to obszar zdefiniowany w BSW. Standard zakłada, iż powinny w nim znaleźć się moduły, których nie definiuje dokumentacja AUTOSAR. Obszar rozciąga się w pionie przez całą warstwę BSW, styka się bezpośrednio z uC oraz warstwą RTE, tak więc ma bezpośredni dostęp do sprzętu, może także udostępniać porty dla SW-C. Możemy więc w CDD implementować zarówno sterowniki do peryferii uC, obsługę ASIC’ów, a także komunikować się z warstwą aplikacji.

2.1. Kiedy implementować moduły w CDD i jak należy to robić

• Sterownik sprzętu nie zdefiniowany przez standard AUTOSAR
  • Jest to najbardziej oczywisty przypadek. Gdy musimy obsłużyć peryferia uC lub układ zewnętrzy, którego nie definiuje architektura AUTOSAR, powinniśmy jego implementację umieścić właśnie w obszarze CDD. Nie możemy naszego kodu umieścić w warstwie aplikacji, ponieważ będzie on mocno zależny od sprzętu. Poza tym nie będziemy mieli możliwości (lub będzie to bardzo utrudnione), aby operować na rejestrach uC, gdyż warstwa RTE będzie nas mocno izolować od sprzętu.
• Stos komunikacyjny protokołu niezdefiniowany przez standard AUTOSAR (np. one-wire)
  • Jest to niejako rozwinięcie poprzedniego punktu. Implementację obsługi stosów komunikacyjnych AUTOSAR przechowuje w BSW, tak więc i nasz stos powinien się tutaj znaleźć. Zapewne nasz kod będzie „rozciągnięty” w pionie (jak w modelu OSI), warto więc zachować modułowość i warstwowość podobnie do struktury Basic Software. Pomoże nam to w utrzymaniu kodu, a także np. w przypadku portowania na inną platformę sprzętową.
• Sterownik zdefiniowany przez AUTSOAR, ale z brakiem wsparcia dla potrzebnej nam funkcjonalności:
  • Może się zdarzyć, iż w naszym rozwiązaniu potrzebujemy funkcjonalności, których AUTOSAR nie definiuje do konkretnych sterowników. Możemy w takim przypadku zaimplementować braki w obszarze CDD, rozszerzając tym samym moduł(y) AUTOSAR o dodatkową funkcjonalność (nakładka/wrapper) bądź też stworzyć zupełnie nową, odpowiadającą naszym potrzebom implementację modułu AUTOSAR – najlepiej nadal będąc kompatybilnym ze standardem.
• Sterownik zdefiniowany przez AUTOSAR, ale niespełniający wymogów wydajnościowych
  • Sytuacja występująca np. w systemach hard real time lub tam, gdzie mamy bardzo mocno ograniczone zasoby sprzętowe. Może się zdarzyć, iż dostępna implementacja modułu AUTOSAR nie spełnia naszych oczekiwań, jeśli chodzi o czas wykonania, gwarantowany czas reakcji, zużycie RAM lub rozmiar kodu. Niestety sytuacje takie w chwili obecnej zdarzają się „dość często”. Masowa produkcja modułów samochodów osobowych wymusza oszczędności na podzespołach (także kosztach uC), z drugiej strony firmy dostarczające implementacje zgodne z AUTOSAR tworzą rozwiązania uniwersalne, co oczywiście nie może iść w parze z wysoką optymalizacją pod każdym aspektem. Dodatkowo standard AUTOSAR definiuje ujednolicone API (funkcjonalności i interfejsów sterowników), a uC różnych rodzin udostępniają bardzo zróżnicowane możliwości peryferiów – ostatecznie tutaj także implementacja nie jest optymalna pod kątem czasu wykonywania oraz zużycia pamięci, a może także prowadzić do sporych narzutów. W tym przypadku najczęściej tworzy się implementacje sterowników bardzo mocno zoptymalizowanych pod ściśle określone potrzeby projektowe. Implementacja jest mocno zależna od sprzętu (wykorzystuje maksymalnie feature’y peryferiów, utylizuje wszelkie możliwości jakie dostarcza uC, (np. DMA, przerwania). Taki sterownik jako niezgodny ze standardem ATUSOAR oczywiście musimy umieścić w CDD.
• Wysoce wydajne rozwiązanie
  • Punkt będący rozwinięciem dla zoptymalizowanych sterowników, ale skupiający się na bardziej abstrakcyjnych funkcjonalnościach. Przykładem takiego rozwiązania może być potrzeba stworzenia wysoce wydajnej obsługi komunikacji między rdzeniami uC.
• Pośrednik dla modułu AUTOSAR
  • agregator danych, który przekazuje zebrane informacje do modułu AUTOSAR, często stosowany dla DEM (ze względów wydajnościowych).
• Legacy code/migracja na architekturę AUTOSAR
  • Ze względów biznesowych bardzo rzadko zdarza się, aby projekty automotive były tworzone zupełnie od zera. Zazwyczaj rozwiązanie opiera się o istniejący produkt (skrócony czas rozwoju nowego rozwiązania, dojrzałe i przetestowane implementacje). Z tego też względu migracja na architekturę AUTOSAR, tak aby projekt był w 100% zgodny z nowym standardem następuje etapowo. Przyjętym jest, aby w tym czasie kod legacy umieszczać właśnie w obszarze Complex Device Drivers. Rozwiązanie to jest często najprostszym, sposobem migracji. Kod nie AUTOSARowy niejako „naturalnie” pasuje w obszar CDD, nie musi być zgodny z portami wymaganymi dla SW-C, ma bezpośredni dostęp do sprzętu. Projekt może zachować pełną funkcjonalność z punktu widzenia sytemu. Z czasem można przeprowadzać migrację na rozwiązanie w pełni zgodne z AUTOSARem, przenosząc kolejno funkcjonalności w odpowiadające im obszary aplikacji lub BSW, zostawiając kod mocno specyficzny w obszarze CDD.

2.2. Czego nie implementować w CDD

• Application SW Component – jak wspomnieliśmy wyżej, warstwa aplikacji zawiera logikę systemu i powinna znajdować się powyżej RTE. Jeśli taki komponent umieścimy w BSW, utracimy elastyczność jaką daje nam VFB – umieszczenia komponentu w dowolnym rdzeniu lub nawet osobnym ECU. Logika nie powinna być zależna od sprzętu, z zasady BSW jest obszarem, gdzie znajduje się kod mający zapewnić tą niezależność. Oczywiście wyjątkową sytuacją jest integracja kodu legacy, który zamierzamy w przyszłości migrować do SW-C.
• Parameter SW Component – komponent zawierający parametry konfiguracyjne aplikacji, nie powinny zależeć od BSW. Taka parametryzacja znajduje się wewnątrz RTE, udostępnia jedynie porty wyjściowe.
• ECU Abstraction Component – dostarcza sygnałowy interfejs do sprzętu takiego jak: ADC, DIO, PWM. Jeśli potrzebujemy zaimplementować udostępnienie takich funkcjonalności dla warstwy aplikacji, to powinniśmy to umieścić w ECU Abstraction Component, a nie w CDD

2.3. Dobre praktyki przy implementacji CDD

• Zachowanie warstwowości zbliżonej organizacyjnie do standardu AUTSOAR: MCAL, ECUAL, Service Layer, itd.
• Maksymalnie opieranie się na istniejących modułach AUTOSAR BSW, tworzenie kodu w CDD jedynie w sytuacjach tego wymagających
• Unikanie rozwiązań opartych o wskaźniki w przypadku potrzeby komunikacji z warstwą aplikacji. Komunikacja taka zawsze musi przebiegać przez RTE, które operuje na sygnałach (które są wartościami). Należy więc oprzeć się o struktury i tablice.
• Jeśli jest taka możliwość, korzystać z komunikacji poprzez RTE, a nie bezpośredniego wywoływania interfejsów modułu – to rozwiązanie jest bardziej elastycznie pod kątem przenaszalności. Takie połączenie jest automatycznie generowane z poziomu architektury projektu (arxml).
• Przy tworzeniu CDD korzystać z AUTOSAR_EXP_CDDDesignAndIntegrationGuideline.pdf

3. Podsumowanie

Dzięki istnieniu obszaru CDD w architekturze AUTOSAR możemy w systemie umieścić kod odpowiedzialny za obsługę urządzeń lub peryferii nieprzewidzianych podczas opracowywania standardu, implementować bardzo specyficzne lub mocno optymalizowane rozwiązania. CDD ułatwia także migrację projektów do standardu AUTOSAR.

Warto rozumieć do czego służy obszar CDD, wykorzystując go świadomie i w zgodzie z przyjętą praktyką.