Forstå autosar og dets arkitektur

AUTOSAR (Automotive Open System Architecture) kan defineres som en felles plattform for hele bilindustrien som er designet for å forbedre anvendelsesområdet for kjøretøyfunksjonalitet uten å påvirke den gjeldende driftsmodellen. AUTOSAR er i utgangspunktet en åpen og standard programvarearkitektur som ble utviklet i fellesskap av bilprodusenter, leverandører og verktøyutviklere. I denne artikkelen vil vi lære hva som er AUTOSAR og om de forskjellige lagene i arkitekturen.

Hovedmottoet til AUTOSAR er "Samarbeid om standarder, konkurrer om implementering". Denne unike arkitekturen ble utviklet for å etablere og opprettholde en felles standard blant produsenter, programvareleverandører og verktøyutviklere, slik at resultatet av prosessen kan leveres uten behov for endringer.

AUTOSAR - Hvordan begynte det hele?

I 2003 ble AUTOSAR-partnerskapet dannet som en allianse av OEM (Original Equipment Manufacturer) produsenter, Dekk 1 billeverandører, halvlederprodusenter, programvareleverandører, verktøyleverandører og andre. De etablerte AUTOSAR som en åpen industristandard for bilprogramvarearkitektur ved å vurdere de forskjellige E / E-arkitekturene for biler som var til stede og som knytter seg og vil bli dannet i fremtiden.

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

Betydningen av AUTOSAR

Infrastrukturen til AUTOSAR er ikke enkel, men hvorfor er det nødvendig å introdusere en så kompleks infrastruktur for bilindustrien? På den første siden Hvorfor trenger vi AUTOSAR?

Etter hvert som etterspørselen etter det intelligente, tryggere og smartere kjøretøyet øker, vil også konkurransen i bilindustrien øke. All denne intelligensen og kjøretøyfunksjonaliteten kan ikke implementeres av en enkelt myndighet.

For eksempel har en bil kollisjonsputer, GPS-system, smart integrasjon, etc. Alle disse funksjonene er implementert på forskjellige ECUer (elektroniske styringsenheter) av forskjellige bilindustrier, slik at alle de forskjellige bilenhetene skal kunne jobbe hånd i hånd for å få ønsket utløp.

Dette hjelper også i programvareutviklingsprosessen, fordi programvaren utviklet for bilindustrien inntil nylig bare var fokusert på å levere systemets funksjonalitet, og de brydde seg aldri om hva som er effektene det kan gi systemet. Det ble mer komplisert på grunn av mange funksjoner over forskjellige ECUer på tvers av forskjellige bilnettverk. Det ble et mer kritisk problem med økningen i ikke-standardiserte utviklingsprosedyrer. Derfor har de utviklet AUTOSAR.

Ulike lag av AUTOSAR-arkitektur

Hvis du ser på bildet ovenfor, kan du identifisere at AUTOSARs arkitektur er laget av tre hovedlag som er

• Applikasjonslag
• Runtime Environment (RTE)
• Grunnleggende programvare (BSW)

Hvert av disse lagene har sitt eget formål og har en bestemt operasjon å utføre

Applikasjonslag

AUTOSAR-applikasjonslaget består av forskjellige applikasjoner og spesifikke programvarekomponenter som er designet for å utføre en bestemt oppgave i henhold til de gitte instruksjonene. Applikasjonslaget er det øverste laget av AUTOSARs programvarearkitektur, det er derfor det er viktig for alle kjøretøyapplikasjoner. Påføringslaget består av tre av de viktigste komponentene som bør tas i betraktning. De er programvarekomponenter, porter til disse komponentene og portgrensesnitt.

Programvarekomponentene sikrer funksjonaliteten til delsystemet, som involverer operasjonene og dataelementene som programvaren krever, og ressursene komponentene trenger. Og kilden til applikasjonen er uavhengig av plasseringen av de interaktive komponentene, typen ECUer som komponenten er kartlagt på, og antall ganger komponenten blir instantiert i et system.

Runtime Environment (RTE) Layer

Runtime-miljølaget skaper et passende miljø for drift av programvarekomponentene (SWCer). SWC er alltid avhengig av grensesnittet som tilbys av RTE.

Det kan betraktes som kommunikasjonssenteret mellom ECU-ene som er innenfor nettverket. Det hjelper programvarekomponentene til å operere uavhengig av kommunikasjonsmekanismer og kanaler. RTE gjør dette mulig ved å kartlegge kommunikasjonsforholdene mellom komponenter som er implementert i de forskjellige malene, til en spesifikk Intra-kommunikasjonsmekanisme som samtale eller en inter ECU-kommunikasjonsmekanisme som en COM-melding.

RTE har ansvaret for å administrere livssyklusen til SWC, den skal starte og stenge funksjonene basert på behovene. Det fungerer også som et separasjonslag mellom Application Software (ASW) og Base Software (BSW) der Base-programvaren hadde tillatelse til å ringe en hvilken som helst API-funksjon eller andre moduler direkte, men Application-programvaren kan bare kommunisere gjennom porter.

RTE genereres i to faser

• Kontraktsfase: Denne fasen er uavhengig av ECU, og den gir kontrakten mellom applikasjonsprogramvaren og RTE, det vil si at APIen til ASW-komponentene kan kodes mot.

Det har resultert i en ASW-komponent spesifisert overskrift som vi kan inkludere i kildekoden. Overskriftsfilen består av alle RTE API-funksjonene som kan brukes i ASW, og også de nødvendige datatypene og strukturene som trengs av ASW-komponentene blir deklarert i overskriftsfilen.

• Generasjonsfase: Denne fasen vil fokusere på å generere den konkrete koden for en gitt ECU. Med ASW-komponentene og headerfiler opprettet i kontraktsfasen og all nødvendig BSW-kode, kan den genererte koden kompileres til en kjørbar fil for ECU.

Grunnleggende programvare (BSW)

Basic Software-laget kan defineres som standardisert programvare som kan tilby tjenester til AUTOSAR-programvarekomponentene, og det brukes også til å kjøre den funksjonelle delen av programvaren. Basic-programvaren inkluderer standardiserte og ECU-spesifiserte komponenter.

Basic Software-laget er videre delt inn i 4 hoveddeler, nemlig Services Layer, ECU Abstraction Layer, Microcontroller Abstraction Layer og Complex Drivers.

I. Servicelag

Det er det øverste laget av det grunnleggende programvarelaget, det gir de grunnleggende programvaremodulene til applikasjonsprogramvaren, og det er uavhengig av mikrokontrolleren og ECU- maskinvaren.

Tjenestelaget gir funksjoner som

• Memory Services (NVRAM Management)
• Diagnostiske tjenester (inkludert UDS kommunikasjon og feilminne)
• Kommunikasjon og ledelse av bilnettverk
• ECU-statsledelse
• Operativsystem (OS)

Dette lagets montering er spesialisert for mikrokontroller (MCU), deler av ECU-maskinvaren og deres applikasjoner.

II. ECU Abstraction Layer

Dette laget fungerer som et grensesnitt for abstraksjonslaget for mikrokontroller som også inneholder noen drivere for eksterne enheter. Den har tilgang til periferiutstyr og enhetene uansett hvor de er plassert enten på innsiden eller utsiden av mikrokontrolleren. Det tilbyr også API for grensesnitt med mikrokontrolleren.

III. Microcontroller Abstraction Layer (MCAL)

Microcontroller-laget er tilgangsveien for å kommunisere med maskinvaren. Dette laget ble innrammet for å unngå direkte tilgang til mikrokontrollerregistre. Den mikro-styreenheten Abstraction Layer (Mcal) er en maskinvare lag er utformet for å sikre en standard grensesnitt for komponentene i basisprogramvare. Det gir mikrokontrolleruavhengige verdier for komponentene i den grunnleggende programvaren og administrerer også periferiutstyret til mikrokontrolleren.

MCAL er utstyrt med en varslingsmekanisme slik at den kan støtte distribusjon av kommandoer, svar og informasjon til forskjellige prosesser. Bortsett fra dette kan MCAL inkludere noen av funksjonene og enhetene som Digital I / O (DIO), Analog / Digital Converter (ADC), Pulse Width (De) Modulator (PWM, PWD), EEPROM (EEP), Flash (FLS), Capture Compare Uni (CCU), Watchdog Timer (WDT), Serial Peripheral Interface (SPI), I2C Bus.

IV. Kompleks enhetsdriver (CDD)

Dette laget har spesiell timing og funksjonskrav for å håndtere komplekse sensorer og aktuatorer. CDD brukes til å håndtere komplekse funksjoner, den finnes ikke i andre lag, og den har muligheten til å få tilgang til mikrokontrolleren direkte. De komplekse funksjonene inkluderer injeksjonskontroll, kontroll av elektriske verdier, posisjonsøkningsdeteksjon, etc.

Mål med AUTOSAR

AUTOSAR ble opprettet av visse grunner som er nyttige for tiden, og som også vil være nyttige i fremtiden. Noen av målene er oppført nedenfor.

• Implementering og standardisering av grunnleggende funksjoner som en bransjeløs “standardkjerne” -løsning.
• Integrasjoner av funksjonelle moduler fra forskjellige leverandører.
• Lett å vedlikeholde prosessen gjennom hele livssyklusen.
• Evnen til å skalere forskjellige kjøretøy uavhengig av plattformen.
• Aktivering av redundans.
• Hensyn til tilgjengelighet og sikkerhetskrav.
• Enkel overføring av funksjoner fra en ECU til en annen ECU i nettverket.
• Bruker kommersiell maskinvare (COTS) maskinvare mer.
• Regelmessige programvareoppdateringer og oppgraderinger gjennom kjøretøyets levetid.

Fordeler med AUTOSAR

AUTOSAR har forskjellige fordeler i forskjellige stadier av kjøretøyets livssyklus

OEM-er: Med AUROSAR kan du bruke den samme programvarekoden igjen og igjen for forskjellige OEM-er. Det er mer fleksibelt å tilpasse seg forskjellige design og reduserer også produksjonstiden og kostnadene.

Leverandører: Leverandører kan øke effektiviteten i funksjonell utvikling og lage sin egen forretningsmodell som passer for dem.

Verktøyleverandør: AUTOSAR har et felles grensesnitt som hjelper verktøyleverandøren med å standardisere utviklingsprosessen.

Ny markedsdeltaker: For de nye aktørene fungerer AUTOSAR som et gjennomsiktig og definert grensesnitt som kan hjelpe dem med å forstå bransjestandardene og også lage egne forretningsmodeller.

Hva kan du forvente deg gjennom AUTOSAR?

AUTOSAR er designet for å tjene forskjellige formål til forskjellige avdelinger i bilindustrien. Siden det er allsidig og fleksibelt, kan du gjøre mange ting fra det bortsett fra det. Noen av de grunnleggende resultatene som AUTOSAR kan gi deg, er muligheten til å gjenbruke programvaren i den til flere enheter, og programvaren som brukes kan byttes når den er nødvendig, fungerer AUTOSAR som en standard plattform for alle kjøretøyprogramvare, og den har ingen egen applikasjon.

Den har et operativsystem med grunnleggende funksjoner og grensesnittprogramvare, og den største fordelen er at det samme grensesnittet kan brukes i all grunnleggende programvare. Funksjonene til AUTOSAR leveres som programvarekomponenter, og alle komponentene som er involvert er maskinvareuavhengige.