Forståelse af autosar og dets arkitektur

AUTOSAR (Automotive Open System Architecture) kan defineres som en fælles platform for hele bilindustrien, der er designet til at forbedre anvendelsesområdet for køretøjsfunktionalitet uden at påvirke den aktuelle driftsmodel. AUTOSAR er grundlæggende en åben og standard softwarearkitektur, som blev udviklet i fællesskab af bilproducenter, leverandører og værktøjsudviklere. I denne artikel lærer vi, hvad der er AUTOSAR, og om de forskellige lag i dens arkitektur.

Hovedmottoet for AUTOSAR er "Samarbejd om standarder, konkurrer om implementering". Denne unikke arkitektur blev udviklet for at etablere og opretholde en fælles standard blandt producenter, softwareleverandører og værktøjsudviklere, så resultatet af processen kan leveres uden behov for ændringer.

AUTOSAR - Hvordan det hele begyndte?

I 2003 blev AUTOSAR-partnerskabet dannet som en alliance af OEM-producenter (Original Equipment Manufacturer), Dæk 1-billeverandører, halvlederproducenter, softwareleverandører, værktøjsleverandører og andre. De etablerede AUTOSAR som en åben industristandard for bilsoftwarearkitektur ved at overveje de forskellige E / E-arkitektur til biler, der var til stede, og som blev bundet og ville blive dannet i fremtiden.

De 10 kernepartnere for AUTOSAR er BMW Group, Bosch, Continental, DaimlerChrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, SiemensVDO, Toyota Motor Corporation og Volkswagen.

Betydningen af AUTOSAR

Infrastrukturen i AUTOSAR er ikke enkel, men hvorfor er det nødvendigt at introducere en så kompleks infrastruktur til bilindustrien? På den første side Hvorfor har vi brug for AUTOSAR?

Da efterspørgslen efter det intelligente, sikrere og smartere køretøj øges, vil konkurrencen i bilindustrien også øges. Al denne intelligens og køretøjsfunktionalitet kan ikke implementeres af en enkelt myndighed.

For eksempel har en bil airbags, GPS-system, smart integration osv. Alle disse funktioner er implementeret på de forskellige ECU'er (elektroniske styreenheder) af forskellige bilindustrier, så alle de forskellige bilenheder skal kunne arbejde hånd i hånd for at få det ønskede udløb.

Dette hjælper også med softwareudviklingsprocessen, for indtil den seneste tid var den software, der blev udviklet til bilindustrien, kun fokuseret på at levere systemets funktionalitet, og de var aldrig interesserede i, hvilke effekter det kan give systemet. Det blev mere kompliceret på grund af mange funktioner over forskellige ECU'er på tværs af forskellige køretøjsnetværk. Det blev et mere kritisk problem med stigningen i ikke-standardiserede udviklingsprocedurer. Derfor har de udviklet AUTOSAR.

Forskellige lag af AUTOSAR-arkitektur

Hvis du ser på ovenstående billede, kan du identificere, at AUTOSARs arkitektur er lavet af tre hovedlag, som er

Applikationslag
Runtime Environment (RTE)
Grundlæggende software (BSW)

Hvert af disse lag har sit eget formål og har en bestemt operation at udføre

Applikationslag

AUTOSAR-applikationslaget består af forskellige applikationer og specifikke softwarekomponenter, der er designet til at udføre en bestemt opgave i henhold til de givne instruktioner. Applikationslaget er det øverste lag i AUTOSARs softwarearkitektur, hvorfor det er afgørende for alle køretøjsapplikationer. Påføringslaget består af tre af de vigtigste komponenter, der skal tages i betragtning. De er applikationssoftwarekomponenter, porte på disse komponenter og portgrænseflader.

Softwarekomponenterne sikrer delsystemets funktionalitet, som involverer de operationer og dataelementer, som softwaren kræver, og de ressourcer, som komponenterne har brug for. Og applikationens kilde er uafhængig af placeringen af de interaktive komponenter, typen af ECU'er, som komponenten er kortlagt på, og antallet af gange, komponenten instantieres i et system.

Runtime Environment (RTE) lag

Runtime-miljølaget skaber et passende miljø til driften af softwarekomponenterne (SWC'er). SWC er altid afhængig af grænsefladen, der leveres af RTE.

Det kan betragtes som kommunikationscentret mellem de ECU'er, der er inden for netværket. Det hjælper softwarekomponenterne med at fungere uafhængigt af kommunikationsmekanismerne og kanalerne. RTE gør dette muligt ved at kortlægge kommunikationsforholdene mellem komponenter, der er implementeret i de forskellige skabeloner, til en specifik Intra-kommunikationsmekanisme som opkald eller en inter ECU-kommunikationsmekanisme som en COM-besked.

RTE har ansvaret for at styre livscyklussen for SWC, det skal starte og lukke funktionerne baseret på behovene. Det fungerer også som et separationslag mellem applikationssoftwaren (ASW) og basissoftwaren (BSW), hvor basesoftwaren havde tilladelse til at ringe direkte til enhver API-funktion eller andre moduler, men applikationssoftwaren kan kun kommunikere gennem porte.

RTE genereres i to faser

Kontraktfase: Denne fase er uafhængig af ECU'en, og den giver kontrakten mellem applikationssoftwaren og RTE, dvs. at ASW-komponenternes API kan kodes mod.

Det har resulteret i en ASW-komponentspecifik header, som vi kan medtage i kildekoden. Overskriftsfilen består af alle RTE API-funktioner, der kan bruges i ASW, og også de nødvendige datatyper og strukturer, der kræves af ASW-komponenterne, erklæres i headerfilen.

Generationsfase: Denne fase vil fokusere på at generere den konkrete kode for en given ECU. Med ASW-komponenterne og headerfiler oprettet i kontraktfasen og al nødvendig BSW-kode kan den genererede kode kompileres til en eksekverbar fil til ECU'en.

Grundlæggende software (BSW)

Basissoftwarelaget kan defineres som den standardiserede software, der kan levere tjenester til AUTOSAR-softwarekomponenterne, og det bruges også til at køre den funktionelle del af softwaren. Basic-softwaren inkluderer de standardiserede og ECU-specificerede komponenter.

Basissoftwarelaget er yderligere opdelt i 4 hoveddele, nemlig Services Layer, ECU Abstraction Layer, Microcontroller Abstraction Layer og Complex Drivers.

I. Servicelag

Det er det øverste lag af det grundlæggende softwarelag, det giver de basale softwaremoduler til applikationssoftwaren, og det er uafhængigt af mikrocontrolleren og ECU- hardware.

Servicelaget giver funktioner såsom

Memory Services (NVRAM Management)
Diagnostiske tjenester (inklusive UDS kommunikation og fejlhukommelse)
Kommunikation og styring af køretøjsnetværk
ECU-statsledelse
Operativsystem (OS)

Dette lags montering er specialiseret til mikrokontroller (MCU), dele af ECU-hardware og deres applikationer.

II. ECU-abstraktionslag

Dette lag fungerer som en grænseflade til mikro-controller-abstraktionslaget, som også indeholder nogle drivere til eksterne enheder. Det har adgang til periferiudstyr og enheder, uanset hvor de er placeret enten inden i eller uden for mikrocontrolleren. Det tilbyder også API'en til interface med mikrocontrolleren.

III. Microcontroller Abstraction Layer (MCAL)

Microcontroller-lag er adgangsruten til at kommunikere med hardwaren. Dette lag blev indrammet for at undgå direkte adgang til mikrocontrollerregistre. Den mikro-controller Abstraction Layer (Mcal) er en hardware lag, der skal sikre den standard interface til komponenterne i grundlæggende software. Det giver mikrokontroller uafhængige værdier for komponenterne i den grundlæggende software og administrerer også perifere enheder til mikrokontrolleren.

MCAL er forsynet med en meddelelsesmekanisme, så den kan understøtte distributionen af kommandoer, svar og information til forskellige processer. Bortset fra dette kan MCAL omfatte nogle af funktionerne og enhederne, såsom Digital I / O (DIO), Analog / Digital Converter (ADC), Pulsbredde (De) Modulator (PWM, PWD), EEPROM (EEP), Flash (FLS), Capture Compare Uni (CCU), Watchdog Timer (WDT), Serial Peripheral Interface (SPI), I2C Bus.

IV. Complex Device Driver (CDD)

Dette lag har speciel timing og funktionelt krav til håndtering af komplekse sensorer og aktuatorer. CDD'en bruges til at håndtere komplekse funktioner, den findes ikke i andre lag, og den har mulighed for at få direkte adgang til mikrocontrolleren. De komplekse funktioner inkluderer injektionskontrol, kontrol af elektriske værdier, positionsforøgelsesdetektering osv.

Formål med AUTOSAR

AUTOSAR blev oprettet af visse grunde, der er nyttige for nutiden, og som også vil være nyttige i fremtiden, nogle af målene er anført nedenfor.

Implementering og standardisering af grundlæggende funktioner som en industriel "standard core" -løsning.
Integrationer af funktionelle moduler fra forskellige leverandører.
Let at vedligeholde processen gennem hele livscyklussen.
Evnen til at skalere forskellige køretøjer uafhængigt af platformen.
Redundansaktivering.
Overvejelse af tilgængelighed og sikkerhedskrav.
Nem overførsel af funktioner fra en ECU til en anden ECU inden for netværket.
Brug mere kommerciel fra hylden (COTS) hardware.
Regelmæssige softwareopdateringer og opgraderinger i hele køretøjets levetid.

Fordele ved AUTOSAR

AUTOSAR tjener forskellige fordele i forskellige faser af køretøjets livscyklus

OEM'er: Med AUROSAR kan du bruge den samme softwarekode igen og igen til forskellige OEM'er. Det er mere fleksibelt at tilpasse til forskellige designs og reducerer også produktionstiden og omkostningerne.

Leverandører: Leverandører kan øge deres effektivitet i funktionel udvikling og skabe deres egen forretningsmodel, der passer til dem.

Værktøjsudbyder: AUTOSAR har en fælles grænseflade, der hjælper værktøjsudbyderen med at standardisere deres udviklingsproces.

Ny markedsdeltager: For de nye deltagere fungerer AUTOSAR som en gennemsigtig og defineret grænseflade, der kan hjælpe dem med at forstå industristandarderne og også skabe deres egne forretningsmodeller.

Hvad kan du forvente gennem AUTOSAR?

AUTOSAR er designet til at tjene forskellige formål til forskellige afdelinger i bilindustrien. Da det er alsidigt og fleksibelt, kan du gøre mange ting ud fra det bortset fra det, nogle af de grundlæggende resultater, som AUTOSAR kan give dig, er muligheden for at genbruge softwaren i den til flere enheder, og den anvendte software kan udveksles, når det er nødvendigt, fungerer AUTOSAR som en standardplatform for alle køretøjets software, og den har ingen egen anvendelse.

Det har et operativsystem med grundlæggende funktioner og grænsefladesoftware, og den største fordel er, at den samme grænseflade kan bruges i al grundlæggende software. Funktionerne i AUTOSAR leveres som softwarekomponenter, og alle de involverede komponenter er hardwareuafhængige.