Konsorcjum skupi\u0142o si\u0119 na standaryzacji najwa\u017cniejszych komponent\u00f3w systemu: stos\u00f3w komunikacyjnych (CAN, Eth, SPI), stosu obs\u0142ugi pami\u0119ci nieulotnej, obs\u0142ugi watchdog\u00f3w, systemu zarz\u0105dzania b\u0142\u0119dami (DTC).<\/p>\n\n\n\n
Oczywi\u015bcie zdawano sobie spraw\u0119, i\u017c nie uda si\u0119 zdefiniowa\u0107 standardu dla wszystkich funkcjonalno\u015bci, zw\u0142aszcza bardzo specyficznych dla ko\u0144cowego klienta (OEM) czy te\u017c obszaru dzia\u0142ania systemu. Z tego powodu zarezerwowano w architekturze AUTOSAR obszar zwany Complex Device Drivers (CDD), w kt\u00f3rym powinna si\u0119 znale\u017a\u0107 obs\u0142uga funkcjonalno\u015bci nieopisanych w dokumentacji. Niestety nie zawsze CDD jest wykorzystywane zgodnie ze swoim przeznaczeniem. Co dok\u0142adnie powinno si\u0119 w nim znale\u017a\u0107, a czego tam nie umieszcza\u0107 – om\u00f3wimy w tym artykule.<\/p>\n\n\n\n
1. Architektura AUTOSAR<\/h2>\n\n\n\n
Aby przej\u015b\u0107 do sedna, przypomnijmy og\u00f3lny zarys architektury AUTOSAR oraz przeznaczenie poszczeg\u00f3lnych warstw. Pozwoli nam to lepiej zrozumie\u0107 kontekst w jakim znajduje si\u0119 CDD.<\/p>\n\n\n\n
1.1. Spojrzenie wysokopoziomowe<\/h3>\n\n\n\n
Na najbardziej og\u00f3lnym poziomie, architektura AUTOSAR sk\u0142ada si\u0119 z 3 warstw (Rysunek 1).<\/p>\n\n\n\n
![\"Architektura](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2019\/11\/arch.png\")
<\/a>Warstwa Aplikacji, jak nazwa wskazuje, jest przeznaczona na komponenty aplikacyjne. Tutaj powinni\u015bmy umieszcza\u0107 software komponenty (SW-C), kt\u00f3re odpowiadaj\u0105 za logik\u0119 systemu. SW-C powinny by\u0107 zaimplementowane tak, aby by\u0142y zupe\u0142nie niezale\u017cne od sprz\u0119tu i operowa\u0142y na poj\u0119ciach abstrakcyjnych, jak temperatura, ci\u015bnienie, stan ON\/OFF\u2026 – bez znaczenia czy dane te pochodz\u0105 od innych SW-C, czujnik\u00f3w fizycznych, oblicze\u0144 symulacji, czy te\u017c z danych przys\u0142anych protoko\u0142ami komunikacyjnymi.<\/p>\n\n\n\n
W warstwie Aplikacji AUTOSAR nie definiuje modu\u0142\u00f3w ani ich funkcjonalno\u015bci (jest to oczywi\u015bcie zale\u017cne od projektu), narzuca natomiast rodzaje interfejs\u00f3w i punkt\u00f3w dost\u0119pu (zwanych PORTAMI) oraz sposob\u00f3w, w jaki SW-C mog\u0105 si\u0119 komunikowa\u0107 ze sob\u0105 oraz \u015bwiatem zewn\u0119trznym. Cz\u0119sto OEM dostarcza cze\u015b\u0107 lub wszystkie SW-C. Standaryzacja AUTOSAR u\u0142atwia integracj\u0119 warstwy aplikacji.<\/p>\n\n\n\n
Warstwa RTE \u0142\u0105czy ze sob\u0105 BSW oraz APP, jest tak\u017ce odpowiedzialna za ca\u0142\u0105 komunikacj\u0119 pomi\u0119dzy SW-C. Odcina warstw\u0119 aplikacji od \u015bwiata fizycznego i uniezale\u017cnia od sprz\u0119tu. RTE wraz z BSW implementuje koncepcj\u0119 Virtual Functional Bus (VFB) \u2013 po szczeg\u00f3\u0142y odsy\u0142am do dokumentacji AUTOSAR<\/a>.<\/p>\n\n\n\n Najni\u017csza warstwa \u2013 BSW – odpowiada za obs\u0142ug\u0119 sprz\u0119tu, a jej implementacja jest mocno od niego zale\u017cna. AUTOSAR bardzo szczeg\u00f3\u0142owo definiuje modu\u0142y tej warstwy – ich zachowanie oraz interfejsy. W tej warstwie nie powinni\u015bmy implementowa\u0107 logiki aplikacyjnej.<\/p>\n\n\n\n Przyjrzyjmy si\u0119 nieco dok\u0142adniej warstwie BSW<\/p>\n\n\n\n Mo\u017cemy tutaj wyr\u00f3\u017cni\u0107 3 podwarstwy oraz interesuj\u0105cy nas blok CDD.<\/p>\n\n\n\n Tym razem zaczniemy od warstwy najni\u017cszej \u2013 Microcontroller Abstraction Layer (MCAL). Odpowiada ona za obs\u0142ug\u0119 mikrokontrolera, na kt\u00f3rym uruchomiony jest nasz system. Warstwa ta najcz\u0119\u015bciej dostarczana jest przez producenta procesora. MCAL ujednolica interfejs do peryferiu\u00f3w uC, umo\u017cliwia to stosunkowo \u0142atwe portowanie systemu na inne platformy \u2013 \u201ewystarczy\u201d podmieni\u0107 MCAL dedykowany dla nowego sprz\u0119tu.<\/p>\n\n\n\n Electronic Control Unit Abstraction Layer (ECUAL) to kolejna warstwa obs\u0142ugi sprz\u0119tu, odpowiedzialna za obs\u0142ug\u0119 element\u00f3w wsp\u00f3\u0142pracuj\u0105cych z naszym uC (wszelkie ASIC, zewn\u0119trzne pami\u0119ci, watchdogi, sensory, etc). Oczywi\u015bcie do komunikacji ze \u015bwiatem zewn\u0119trznym u\u017cywa ona abstrakcji MCAL.<\/p>\n\n\n\n Warstwa serwis\u00f3w (Services Layer) odpowiada za zarz\u0105dzanie i ujednolicenie interfejs\u00f3w dla obs\u0142ugi konkretnych urz\u0105dze\u0144, np. dostarcza interface Nvm_Write(idx) do obs\u0142ugi pami\u0119ci nieulotnych w systemie. Warstwa ta zawiera tak\u017ce system operacyjny czasu rzeczywistego, dlatego z lewej strony rysunku, styka si\u0119 bezpo\u015brednio z uC. Service Layer odpowiada za dostarczenie informacji warstwie aplikacji poprzez RTE.<\/p>\n\n\n\n W przeciwie\u0144stwie do warstwy aplikacji, wszystkie powy\u017csze warstwy BSW s\u0105 bardzo szczeg\u00f3\u0142owo zdefiniowane przez standard AUTOSAR (interfejsy, zachowanie modu\u0142\u00f3w, w jaki spos\u00f3b modu\u0142y musz\u0119 si\u0119 ze sob\u0105 komunikowa\u0107, jakie s\u0105 mo\u017cliwe konfiguracje). Szczeg\u00f3\u0142owa dokumentacja jest dost\u0119pna na stronie autosar.org.<\/p>\n\n\n\n No i wreszcie blok CDD (Complex Device Drivers), rozci\u0105gaj\u0105cy si\u0119 bezpo\u015brednio od uC do warstwy RTE, kt\u00f3ry om\u00f3wimy w dalszej cz\u0119\u015bci.<\/p>\n\n\n\n Warstw\u0119 BSW mo\u017cemy tak\u017ce rozpatrzy\u0107 pod k\u0105tem realizowanych funkcjonalno\u015bci. Jak wida\u0107 na rysunku 3, da si\u0119 wyodr\u0119bni\u0107 stosy rozci\u0105gaj\u0105ce si\u0119 przez wszystkie warstwy BSW, realizuj\u0105ce konkretne funkcjonalno\u015bci poprzez obs\u0142ug\u0119 peryferi\u00f3w uC, uk\u0142ad\u00f3w zewn\u0119trznych (ASIC) oraz dostarczanie abstrakcyjnych interfejs\u00f3w dla RTE.<\/p>\n\n\n\n Poni\u017cej bardziej szczeg\u00f3\u0142owy przyk\u0142ad stos\u00f3w watchdog oraz NVM:<\/p>\n\n\n\n1.2. Basic Software (BSW)<\/h3>\n\n\n\n
<\/a>1.3. Stosy<\/h3>\n\n\n\n
<\/a>