Se afișează postările cu eticheta embedded C. Afișați toate postările
Se afișează postările cu eticheta embedded C. Afișați toate postările

vineri, 5 iulie 2019

AUTOSAR(6)- Communication Services In AUTOSAR – CAN Network Management (CanNm)


În acest articol vom discuta despre interfața NM (Network Management) și modulul NM specific pentru magistrala CAN, care fac parte din stratul de Servicii al arhitecturii Software Layered AUTOSAR.

Interfața de gestionare a rețelei:

Interfața de administrare a rețelei este un modul între modulul ComM și modulul NM (specific pentru un anumit tip de bus - CAN, LIN, FlexRay, Ethernet). În acest articol vom lua în considerare CANNM ca  parte a NM.
Interfața NM are două funcționalități:


  • Funcționalitatea de bază - este să acționeze ca un modul de adaptare între modulul NM  și modulul ComM. Interfețele pentru comunicații între interfața NM și modulul ComM sunt independente de bus.





  • Coordonator NM - utilizat de ECU-ul gateway-ului pentru a opri sincronizarea bus-urilor de comunicații. Utilizează un algoritm de coordonare NM pentru a opri busu-urile de comunicare la care este conectat un ECU. Un ECU care utilizează funcționalitatea NM este denumit Coordonator NM.


Oprirea trebuie să fie coordonată în rețeaua care este trează (comunicatie activă) și nu în modul "Bus-Sleep". Rețeaua care se află în modul "Bus-Sleep" este monitorizată. Atâta timp cât o magistrală din clusterul de coordonare (NM Cluster - Set de noduri NM coordonate cu utilizarea algoritmului NM) este trează,atunci coordonatorul NM trebuie să mențină în continuare rețeaua trează (comunicatie activă).

Când algoritmul de coordonare este pornit, se lansează un temporizator de întârziere de oprire pentru canalele actuale active în rețeaua de coordonare. Când expiră temporizatorul de oprire a închiderii, NM ar trebui să elibereze rețeaua NM. Când toate rețelele au fost lansate și toate rețelele sunt în modul "bus-sleep", închiderea coordonată a fost finalizată.

CAN Network Management:

CANNM are rolul de a coordona tranziția între modul normal de funcționare și modul "bus-sleep" al rețelei. Acesta poate fi, de asemenea, utilizat pentru a detecta toate nodurile prezente sau pentru a detecta dacă toate nodurile sunt gata să treaca in modul "sleep" în rețea.

CANNM pentru fiecare ECU trebuie să efectueze activități autosuficiente în funcție de PDU-urile de management al rețelei, care sunt recepționate sau transmise în cadrul sistemului de comunicații.

Algoritmul CANNM se bazează pe PDU-uri periodice de administrare a rețelei, care sunt recepționate de toate nodurile din cluster prin transmisie . Recepția PDU-urilor de gestionare a rețelei indică faptul că nodurile de trimitere doresc să țină clusterul de gestionare a rețelei trezite. Dacă un nod este gata să meargă în modul Bus-Sleep, acesta nu mai trimite PDU-uri de administrare a rețelei, dar atâta timp cât sunt primite PDU-uri de gestionare a rețelei de la alte noduri, acesta amână trecerea la modul Bus-Sleep. În cele din urmă, dacă scade un cronometru dedicat deoarece nu mai sunt primite PDU-uri de gestionare a rețelei, fiecare nod inițiază trecerea la modul Bus-Sleep.

Dacă un nod din clusterul de gestionare a rețelei necesită o comunicație prin magistrală, acesta poate să trezească clusterul de gestionare a rețelei din modul Bus-Sleep prin transmiterea PDU-urilor de administrare a rețelei.



Conceptul CANNM se bazează pe:

Nodul de rețea din clusterul NM ar trebui să transmită periodic mesaje NM până când are nevoie de acces la magistrala, altfel nu ar trebui să transmită niciun PDU NM.
Dacă este lansată comunicarea prin magistrala într-un cluster CanNm și nu există PDU-uri de administrare a rețelei pe magistrală pentru o perioadă de timp configurabilă determinată de CANNM_TIMEOUT_TIME + CANNM_WAIT_BUS_SLEEP_TIME (ambii parametri de configurare), se va efectua trecerea în modul Bus-Sleep.

Stările diferite pentru CANNM:

REPEAT MESSAGE: Fiecare ECU transmite propriul mesaj NM ciclic până la expirarea timerulului configurabil.

READY SLEEP: ECU este gata de "Sleep", nu este transmisă niciun mesaj NM, timerul este repornit când este recepționat un mesaj NM.

NORMAL OPERATION: Transmisia mesajelor NM și repornirea timer-ului la expedierea și recepția mesajelor.

PREPEARE BUS SLEEP MODE: Dacă expiră timer-ul și nu a fost transmis sau primit niciun mesaj NM.

BUS SLEEP MODE: Dacă un timer ajunge la limită, atunci rețeaua trece la modul Bus-Sleep, în care nu se poate comunica  pe magistrala.

Weekend plăcut tuturor!

joi, 23 mai 2019

Quadcopter (8) - Versiunea 3

Descriere proiect:
Am făcut un re-design la dronă, și i-am montat motoare noi. Cadrul de plastic l-am înlocui cu tije de aluminiu de 50cm montate în cruce. În rest configuratia electronica, controlerul Hkpilot, GPS-ul, controler radio, controlerele de viteza pentru motoare (ESC-urile) și power distribution board le-am păstrat. Testele fără elici au mers bine, calibrarea compasului deasemenea , la fel accelerometrul si calibrarea pentru radio au mers brici. Dar cred ca e prea frumos să fie adevărat și testul suprem este zborul efectiv.

Documentatie proiect:
Componente:


Configuratia elicilor:
Greutatea fara elici este de 650 de grame:
GPS-ul este montat sus (cu LED-ul verde):
Noile motoare Turnigy D2205-2300KV 28g Brushless montate pe conectorii făcuți de mine:
Controlerul radio si conexiunile, cutiuta neagra cu multe fire:

Imagine de ansamblu:
Urmează testul de zbor. O seară faină tuturor!

miercuri, 8 mai 2019

AUTOSAR(5) - ComStack CANTP

În acest articol vom discuta despre interacțiunea dintre module precum PDU Router (Layer Services), Layer de transport CanTP (Layer Services), CanIf (Layer Abstraction ECU) și CAN Driver (MCAL Layer). Acest articol va fi mai concentrat pe modulul CanTp, deoarece celelalte module sunt discutate în articolele anterioare. Dar se va atinge de celelalte module (PduR, CanIf și CanDrv) atunci când există o interacțiune între ele și CanTp.

CAN Transport Layer

Serviciile de bază oferite de modulul Can Tp sunt segmentarea mesajelor care au o sarcină utilă de peste 8 octeți, transmiterea mesajelor cu controlul fluxului și reasamblarea mesajelor segmentate la receptor.

În imaginea de mai jos este reprezentat un frame CAN, iar in segmentul Data ar fi informația utilă. În cazul nostru informații de diagnoză specifice CanTp. Pentru cazul în care semnalele CAN urmează să ajungă în modulul COM -> RTE iar apoi in applicatie, atunci cei 8 bytes de date contin semnalele utile.



Modulul CanTp trebuie să respecte standardul ISO 15765-2 pentru segmentarea mesajelor, transmisia segmentată și reasamblarea datelor segmentate. Protocolul de transport este folosit în principal pentru comunicarea peer-to-peer în CAN.

Protocolul ISO-TP

ISO 15765-2, cunoscută și ca ISO-TP, este un standard pentru trimiterea de pachete pe magistrala CAN care extinde limita CAN de 8 octeți pentru a suporta până la 4095 octeți prin legarea pachetelor CAN împreună. Cea mai obișnuită utilizare a ISO-TP este pentru diagnosticare (vezi "Servicii de diagnoză unificată") , dar poate fi fo,losit și în orice moment, pentru a transfera cantități mari de date.

Network Layer Protocol efectuează transmiterea / recepția de date de până la 4095 octeți și raportarea finalizării transmisiei / recepției.



Single Frame (SF) Transmisie:

Transmiterea / recepția mesajului de până la 7 octeți de date se realizează utilizând un N_PDU unic. Frame-ul unic este utilizat de către tester numai în cazul adresării funcționale în care testerul nu cunoaște adresa fizică a ECU sau dacă funcționalitatea ECU-ului este implementată ca un server distribuit pe mai multe ECU-uri.

Transmisie cu mai multe cadre:

Transmiterea mesajelor cu octeți de date mai lungi se realizează prin segmentarea mesajului și transmiterea ca mai multe N_PDU-uri. Recepția se realizează prin reasamblarea mai multor receptoare N_PDU.

First Frame (FF): Unitatea de date FF conține cea mai mare parte a lungimii datelor în octeți care va face parte din cadrul consecutiv (CF), iar octeții rămași pot fi utilizați octeți de date.

Flow control (FC): Receptorul are posibilitatea de a adapta capacitatea transmițătorilor folosind cadrul FC. Utilizând cadrul FC, receptorul poate solicita emițătorului să trimită octeți de date cu o anumită dimensiune a blocului (BS - numărul maxim de N_PDU, receptorul permite expeditorului să trimită înainte ca acesta să permită expeditorului să trimită din nou N_PDU) și la o rată fixă ​​(STmin - timpul minim pe care expeditorul trebuie să îl aștepte înainte de transmiterea următorului N_PDU consecutiv), astfel încât receptorul să proceseze datele recepționate.

Consecutive frame (CF): Conține octeții de date transmise împreună cu numărul de ordine (SN) care specifică numărul CF și acest SN este utilizat în timpul asamblării datelor la receptor.


Există mulți parametri de sincronizare implicați în comunicarea protocolului de transport. Mergeți la ISO 15765-2 pentru descrierea tuturor acestora.

Luați în considerare dacă 49 octeți de date trebuie transmise folosind adresarea obișnuită, atunci fluxul PDU ar putea să arate, primul cadru va conține numărul de octeți care urmează să fie transmiși, 49 numărul de CF-uri care vor fi utilizate pentru transmiterea acestor 49 octeți, 7. Cadrul FC va avea valorile BS și STmin specifice receptorului. Cele șapte cadre CF vor conține octeții de date.

Interacțiunea CanTp cu alte module

CanIf interacționează cu CanTp si va apela functiile TxConfirmation și RxIndication pentu primirea si trimiterea de PDU-uri.

CanTp nu are propriul buffer, deci folosește bufferul straturilor superioare (PDUR, DCM sau COM). Deci, pentru a menține consistența datelor în timpul Tx / Rx, bufferul este blocat. În timpul recepționării datelor, modulul CanTp notifică stratul superior (PDUR), iar stratul superior își rezervă și blochează bufferul pentru recepție.

Dacă stratul superior nu poate creea bufferul  disponibil pentru recepție din cauza unei erori sau a unei limitări a resurselor, acesta returnează o eroare. Apoi CanTp întrerupe recepția și transmisia cadrului FC depinde de codul de eroare din stratul superior.

În timpul transmisiei, CanTp utilizează formatul de adresare pentru a trimite cadrele SF, FF și CF. Transmisia poate să nu funcționeze dacă straturile superioare nu pot pune la dispoziție datele de transmisie înainte de trecerea timpului intern (consultați ISO 15765-2). CanTp reia transmisia atunci când datele sunt disponibile din stratul superior.

Modulul PDUR este notificat în prealabil cu un început de notificare de recepție atunci când primește un primul frame (FF) sau un singur frame (SF). Acest apel va fi trimis la modulul stratului superior respectiv. Sarcina utilă a fiecărui segment (N-PDU) este copiată în modulul stratului de destinație superior (DCM). După recepția ultimului N-PDU, modulul CanTP va indica modulului  PDUR că primită I-PDU-ul complet și modulul PDUR va transmite această indicație către modulul stratului superior respectiv.



Operația de transmisie a modulului PDUR este declanșată de o cerere de transmitere a unui PDU de la un modul sursă și înaintează cererea către un modul de pe un strat de destinație inferioară. În timpul transmisiei, PDUR nu stochează PDU-ul.

Gateway-on-the-fly: rutarea între două module TP unde se pornește redirecționarea datelor (când se atinge un prag specificat) înainte ca toate datele să fi fost primite. Dacă este transferată o cantitate mai mare de date între două interfețe, este de dorit să puteți porni transmisia în rețeaua de destinație înainte de a primi toate datele din rețeaua sursă. Acest lucru economisește memoria și timpul.

Bonus:
The Car Hacker's Handbook: A Guide for the Penetration Tester - Craig Smith (2016)

duminică, 14 aprilie 2019

AUTOSAR(4) - ComStack CAN

În acest articol vom discuta despre serviciile de comunicare în AUTOSAR w.r.t. Protocolul CAN. În acest articol mă voi limita la module CAN Interface (CanIf) și CAN Driver (CanDrv). Alte module ale ComStack referitoare la protocolul CAN vor fi explicate în articolele următoare.


Stivă de comunicare w.r.t. la protocolul CAN în AUTOSAR constau din module cum ar fi AUTOSAR COM (Layer de servicii), Router PDUR (strat de servicii), CAN Status Manager CANSM (Layer servicii), CAN Network Manager CANNM (Layer de servicii), CAN Transport Protocol  CANTP(Strat de abstractizare ECU), Driver extern CAN (strat de abstractizare ECU) și driver CAN (strat MCAL). Unele module legate de diagnosticare CANTP, multiplexarea PDU și CAN-Transceiver  CANTrcv sunt, de asemenea, parte din stivă.



Interfața CAN (CanIf) este un modul din stratul de abstractizare ECU, care este responsabil pentru servicii cum ar fi solicitarea de transmisie, confirmarea transmisiei, indicația recepției, controlul modului controlerului și controlul modului PDU.

Termenii de bază utilizați în CAN

Manevrabilitatea obiectelor hardware:

Mijloacele pentru obiectele hardware (HOH) pentru transmisie (HTH) precum și pentru recepție (HRH) reprezintă o referință abstractă la o structură de obiecte hardware CAN care conține parametri CAN, cum ar fi CanId, DLC și date. În timpul transmisiei, aceste handles sunt cunoscute sub numele de handle transmițătoare hardware (HTH) și în timpul recepției Hardware Receive Handles (HRH). CanIf apelează interfețele CAN driver folosind aceste referințe abstracte și niciodată nu utilizează hardware-ul real CanId, prin urmare CanIf rămâne independent de hardware.

BasicCAN și FullCAN:

CanIf distinge între manipularea BasicCAN și FullCAN pentru activarea filtrării de acceptare a software-ului.

Un obiect hardware CAN pentru operarea FullCAN permite doar transmisia sau recepția unor canale simple.

Un obiect hardware CAN pentru operarea BasicCAN a unui singur obiect hardware permite transmiterea sau recepționarea unei game de CanIds.

Obiectele BasicCAN și FullCAN pot coexista într-o singură configurare a configurației.

CanIf abstractizează obiectul hardware CAN, adică structura cadru CAN de la driverul MCAL CAN, folosind obiecte abstracte numite Hardware Object Handles (HOH).  PDU-ul este directionat către diferite controlere CAN și transceivere. CanIf controlează cererea de tranziții de stare a controlerului CAN de la CANSM și comunică modificările de stare către stratul superior.

În cazul transmisiei unui PDU, CanIf este responsabil pentru cartografierea handlerul transmisiei hardware cu obiectele hardware CAN, determinând driverul CAN pe care trebuie să fie transmis PDU, declanșând un apel către Can_Write api. Odată ce Can_Write este terminat, notificând partea superioară despre starea transmisiei PDU.



În cazul recepției unui PDU, CanIf este responsabil pentru filtrarea PDU-ului primit, verificarea DLC, tamponarea PDU-ului primit și indicarea stratului superior despre recepția PDU. Cele mai multe dintre aceste caracteristici furnizate de CanIf sunt configurabile.



Modulul CAN Driver (CanDrv) face parte din stratul MCAL și oferă acces hardware la serviciile superioare ale stratului și o interfață independentă de hardware pentru straturile superioare. CanIf este singurul modul care poate accesa driver-ul CAN.

CAN Driver CanDrv controlează transmisia cadrelor CAN pe hardware și notifică nivelul superior al recepției apelând funcțiile callback. De asemenea, furnizează interfețele pentru a controla starea  CAN-ului.

Mai jos am reprezentat interfetele folosite pentru activarea sau dezactivarea comunicatiei CAN:

Și la nivel de apeluri a le funcțiilor API starile CAN-ului :




Weekend plăcut !

sâmbătă, 6 aprilie 2019

AUTOSAR(3) - ComStack

Stackul de comunicare în AUTOSAR este un set de module cum ar fi COM (Layer Services), PDU Router (Layer Services), Module de interfață specifice busului (Layer Abstraction ECU), de ex. CanIf, LinIf, FrIf, driver extern de com  (strat de abstractizare ECU), drivere interne com (strat MCAL). Modulele enumerate aici sunt module foarte elementare în Stack-ul de comunicare. Există module cum ar fi modulele Bus Manager specific, manager de rețea și module de protocol de transport în stackul de comunicare, dar acestea vor fi descrise într-un set separat de articole.

TP - Protocol de transport, NM - Manager de rețea, Trcv - Transceiver, Ext. - Circuit integrat specific, extern, Asic

Înainte de a discuta despre stackul de comunicare, o să prezint câțiva dintre termenii de bază utilizați în Stack-ul de comunicare.

Ce este un PDU?

Protocol Data Unit, așa cum este ea, este o structură de date care conține o unitate de date SDU (Service Data Unit) și o informație PCI (Control Protocol Information). Un SDU reprezintă datele transmise de stratul superior pentru transmisie și extrase din PDU în timpul recepției. Un PCI conține în principiu informațiile despre sursă și destinație pentru PDU ce urmează a fi schimbate între straturi și module.



Un PDU este împachetat într-o structură (SDU + PCI) la stratul COM și este transmis la stratul inferior din Stack-ul de comunicare. La fiecare strat în timpul transmisiei, un PDU din stratul superior acționează ca un SDU pentru stratul inferior. Un PCI este adăugat la stratul inferior la acest SDU și este transmis la stratul inferior.

La partea receptorului, PDU-ul primit este despachetat prin separarea SDU și PCI și transmiterea SDU către stratul superior care acționează ca un PDU pentru acel strat.


Semnal, Grup de semnale și Semnale

Semnalul în AUTOSAR este un mesaj. Grupul de semnale este un set de semnale care trebuie transmise în același exemplu și semnalele ambalate într-un grup de semnale sunt cunoscute ca  semnale de grup.



AUTOSAR COM este un modul între RTE și PDUR. Acesta este responsabil pentru furnizarea unui nivel de acces la nivelul semnalului la nivelul aplicației și la un nivel de acces PDU la straturile inferioare, independent de protocol. Acesta împachetează semnalele la un PDU la transmițător și despachetează PDU-ul primit pentru a oferi un nivel de semnal acces la aplicație la receptor. La nivelul PDU, COM este responsabil pentru gruparea PDU-urilor, pornirea și oprirea grupurilor PDU.



COM grupează semnalele dintr-un grup de semnale pentru ca acestea să fie transmise simultan.

COM este responsabil pentru un gateway de nivel de semnal sau grup de semnale. Maparea unui grup  de semnale sau semnal recepționat la un semnal de transmisie sau un grup de semnale care urmează să fie gateway.

De asemenea, este responsabil pentru filtrarea semnalelor.

PduR este un modul responsabil pentru rutarea PDU-ului la modulele de interfață specifică corespunzătoare. Deasupra modulului PduR, toate PDU-urile sunt independente de protocol, iar sub PduR toate PDU-urile sunt direcționate către module specifice protocolului.




O seară bună!

sâmbătă, 16 martie 2019

Știri din domeniul embedded systems and software [16/03/2019]

electrical circuit by Arnau ramos Oviedo on 500px.com


Weekend plăcut tuturor !

AUTOSAR(2) - Arhitectura

Software-ul de bază poate fi împărțit în termeni de stive bazate pe serviciile de bază furnizate, cum ar fi Stack-ul de comunicare (include drivere de comunicare, interfață de comunicație și servicii de comunicații),

Memory Stack (include drivere de memorie, interfață de memorie și servicii de memorie) (include drivere I / O și strat I / O Abstraction).


Architectura completă conținând toate modulele de bază din AUTOSAR :

Există diferite tipuri de interfețe prin care modulele comunică sau schimbă date între ele:

1. Interfețe AUTOSAR: Definește informațiile schimbate între componenta software și modulele BSW. Interfețele AUTOSAR sunt independente de un limbaj de programare, hardware și tehnologie de rețea. Interfețele AUTOSAR sunt utilizate pentru a defini porturile prin intermediul componentei software și a datelor de bază de schimb de software.



2. Interfețele AUTOSAR standardizate: este o interfață AUTOSAR a cărei sintaxă și semantică sunt definite de AUTOSAR. Acestea sunt folosite pentru a furniza serviciile AUTOSAR standardizate ale software-ului de bază pentru componenta software-ului de aplicație.

3. Interfețe standardizate: Acestea sunt interfețele definite într-un limbaj de programare specific și utilizate în cea mai mare parte între module bazate pe același ECU. Modulele din software-ul de bază interacționează între ele folosind interfețe standardizate.



Clase de configurare în AUTOSAR:

1. Pre-compile time: Configurația este folosită pentru a include sau exclude părți ale codului sursă care nu sunt necesare în timpul rulării. Configurațiile de timp precompilate sunt statice, în care modulele software vor fi eficiente, bazate pe configurație, după timpul de compilare. Rezultă optimizarea dimensiunii și performanței codului. Configurațiile de timp precompilate se fac în fișierele * _Cfg.c și * _Cfg.h, '*' specifică numele modulului.

2. Link time: Acest tip de configurare este utilizat atunci când fișierele de configurare sunt disponibile ca cod de obiect. Codul obiect al software-ului primește părți ale configurației din alt fișier de cod obiect sau este definit prin opțiuni de linker. Configurația este selectată după compilare și înainte de conectare. Configurațiile disponibile în fișiere separate sunt considerate ca fiind constante externe. Conexiunile de "link time" se fac în fișierele * _Lcfg.c și * _Lcfg.h, '*' specifică numele modulului.

3. Post-build time: Configurarea modulului software este posibilă după construirea software-ului complet. O referință la configurație este disponibilă și configurația reală este disponibilă în timpul intermitentă a ECU-ului. Aceasta crește reutilizarea, astfel încât același ECU poate fi refolosit într-o altă mașină prin furnizarea unui set diferit de configurație ECU. Post-build configurațiile de timp se fac în fișierele * _PBcfg.c și * _PBcfg.h, '*' specifică numele modulului.




Post-build Loadable: În acest set de configurații, este disponibilă o structură de configurare, iar membrii individuali ai structurii pot fi modificați, dar o structură complet diferită nu poate fi selectată.


Post-build Selectable: În acest set de setări, pot fi disponibile seturi de configurare 'n' și un set complet poate fi selectat în timpul rulării a ECU-ului. Acestea sunt în mare parte disponibile ca o serie de structuri în care un set este selectat în timpul rulării pe ECU (în start-up init).


duminică, 10 martie 2019

AUTOSAR(1) Prezentare generală

AUTOSAR (Automative Open Architecture System) este un standard de dezvoltare a software-ului cu versiuni deschise, pentru, dar fără a se limita la, unitatea electronică de control pentru automobile (ECU).

AUTOSAR oferă o structură stratificată de sus în jos a software-ului cu relația dintre componentele software.

Arhitectura în straturi a AUTOSAR poate fi împărțită în software-ul de bază (BSW), Runtime Environment (RTE) și stratul de aplicație / componentă software.

Nivelul de bază software poate fi subdivizat în continuare în stratul de abstractizare microcontroler (MCAL), stratul de abstracție ECU, stratul de servicii și stratul driverului complex de dispozitive (CDD).


Micro-controlerul Abstraction Layer (MCAL) este cel mai mic strat din arhitectura AUTOSAR stratificat și comunică direct cu hardware-ul. Responsabilitatea sa principală este de a face stratul de deasupra acestuia independent de hardware. Acesta găzduiește driverele de nivel scăzut ale microcontrolerului.



Suprafața de suprapunere ECU este stratul deasupra stratului MCAL care găzduiește componentele de interfață și driverele componentelor hardware în afara microcontrolerului de pe ECU. Responsabilitatea sa principală este de a face stratul de deasupra acestuia independent de hardware-ul disponibil pe ECU. Interfețele sale inferioare sunt dependente de hardware, iar interfețele superioare sunt independente de hardware.




Stratul de servicii este stratul de deasupra stratului de abstractizare ECU, în mare parte independent de hardware și responsabil pentru furnizarea funcționalității BSW de bază a aplicației.



Runtime Environment este stratul care separă software-ul de bază și software-ul aplicației. Arhitectura software de deasupra devine nivel de componentă decât arhitectura cu straturi din Software-ul de bază. RTE este instanțierea nivelului ECU a magistralei de funcții virtuale (VFB). RTE este specifică ECU. Componentele software de aplicație fără BSW comunică între ele prin busul de funcții virtuale (VFB).



Driverul complex de dispozitive (CDD) este un strat prin care hardware-ul poate fi accesat prin RTE de către componenta software-ului de aplicație direct fără a trece prin diferitele straturi ale AUTOSAR. Acest strat este utilizat de aplicațiile care au constrângeri mari de sincronizare și de cerințele care nu sunt descrise de AUTOSAR. Acest strat este dependent de micro-controler și ECU.