Förstå autosar och dess arkitektur

AUTOSAR (Automotive Open System Architecture) kan definieras som en gemensam plattform för hela fordonsindustrin som är utformad för att förbättra tillämpningsområdet för fordonsfunktionalitet utan att påverka den aktuella driftsmodellen. AUTOSAR är i grunden en öppen och standardiserad programvaruarkitektur som utvecklades gemensamt av biltillverkare, leverantörer och verktygsutvecklare. I den här artikeln lär vi oss vad som är AUTOSAR och om de olika lagren i dess arkitektur.

Autosars huvudmotto är ”Samarbeta om standarder, konkurrera om implementering”. Denna unika arkitektur utvecklades för att upprätta och upprätthålla en gemensam standard bland tillverkare, programvaruleverantörer och verktygsutvecklare så att resultatet av processen kan levereras utan några ändringar.

AUTOSAR - Hur började det hela?

År 2003 bildades AUTOSAR-partnerskapet som en allians av OEM-tillverkare (originalutrustningstillverkare), däck 1 billeverantörer, halvledartillverkare, programvaruleverantörer, verktygsleverantörer och andra. De etablerade AUTOSAR som en öppen industristandard för bilprogramvaruarkitektur genom att överväga de olika E / E-arkitekturen för fordon som fanns och som knyter samman och skulle bildas i framtiden.

De 10 kärnpartnerna för AUTOSAR är BMW Group, Bosch, Continental, DaimlerChrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, SiemensVDO, Toyota Motor Corporation och Volkswagen.

Betydelsen av AUTOSAR

AUTOSAR: s infrastruktur är inte enkel, men varför är det nödvändigt att införa en sådan komplex infrastruktur för bilindustrin? För det första Varför behöver vi AUTOSAR?

När efterfrågan på det intelligenta, säkrare och smartare fordonet ökar kommer konkurrensen inom bilindustrin också att öka. All denna intelligens och fordonsfunktionalitet kan inte implementeras av en enda myndighet.

Till exempel har en bil krockkuddar, GPS-system, smart integration osv. Alla dessa funktioner är implementerade på de olika styrenheterna (elektroniska styrenheter) av olika bilindustrier, så alla olika fordonsenheter bör kunna arbeta hand i hand få önskat utlopp.

Detta hjälper också till i mjukvaruutvecklingsprocessen, eftersom programvaran som utvecklats för fordonsindustrin fram till nyligen gick bara in på att leverera systemets funktioner och de brydde sig aldrig om vilka effekter det kan ge systemet. Det blev mer komplicerat på grund av många funktioner över olika styrenheter i olika fordonsnätverk. Det blev ett mer kritiskt problem med ökningen av icke-standardiserade utvecklingsförfaranden. Därför har de utvecklat AUTOSAR.

Olika lager av AUTOSAR-arkitektur

Om du tittar på bilden ovan kan du identifiera att AUTOSARs arkitektur är gjord av tre huvudskikt som är

Applikationsskikt
Runtime Environment (RTE)
Basprogramvara (BSW)

Var och en av dessa lager har sitt eget syfte och har en specifik operation att utföra

Applikationsskikt

AUTOSAR-applikationslagret består av olika applikationer och specifika programvarukomponenter som är utformade för att utföra en specifik uppgift enligt de givna instruktionerna. Applikationsskiktet är det översta lagret i AUTOSAR: s programvaruarkitektur, det är därför det är viktigt för alla fordonsapplikationer. Applikationsskiktet består av tre av de viktigaste komponenterna som bör beaktas. De är programvarukomponenter, portar för dessa komponenter och portgränssnitt.

Programvarukomponenterna säkerställer delsystemets funktionalitet, vilket involverar de funktioner och dataelement som programvaran kräver och de resurser som krävs av komponenterna. Och källan till applikationen är oberoende av platsen för de interaktiva komponenterna, vilken typ av ECU: er som komponenten är mappad på och antalet gånger komponenten installeras i ett system.

Runtime Environment (RTE) Layer

Miljöskiktet för runtime skapar en lämplig miljö för drift av programvarukomponenter (SWC). SWC är alltid beroende av gränssnittet som tillhandahålls av RTE.

Det kan betraktas som kommunikationscentret mellan ECU: erna inom nätverket. Det hjälper mjukvarukomponenterna att fungera oberoende av kommunikationsmekanismer och kanaler. RTE gör detta möjligt genom att mappa kommunikationsförhållandena mellan komponenter som implementeras i de olika mallarna, till en specifik Intra-kommunikationsmekanism som samtal eller en inter-ECU-kommunikationsmekanism som ett COM-meddelande.

RTE har ansvaret för att hantera SWC: s livscykel. Den bör starta och stänga av funktionerna baserat på behoven. Det fungerar också som ett separationslager mellan applikationsprogramvaran (ASW) och basprogramvaran (BSW) där basprogramvaran hade tillstånd att anropa alla API-funktioner eller andra moduler direkt, men applikationsprogramvaran kan bara kommunicera via portar.

RTE genereras i två faser

Kontraktfas: Denna fas är oberoende av ECU och den ger kontraktet mellan applikationsmjukvaran och RTE, det vill säga att API för ASW-komponenterna kan kodas mot.

Det har resulterat i en ASW-komponentspecifik rubrik som vi kan inkludera i källkoden. Rubrikfilen består av alla RTE API-funktioner som kan användas i ASW och även nödvändiga datatyper och strukturer som behövs av ASW-komponenterna deklareras i Header-filen.

Generationsfas: Denna fas kommer att fokusera på att generera den konkreta koden för en given ECU. Med ASW-komponenterna och rubrikfilerna som skapats i kontraktsfasen och all nödvändig BSW-kod kan den genererade koden sammanställas till en körbar fil för ECU.

Basprogramvara (BSW)

Basic Software-lagret kan definieras som den standardiserade programvaran som kan tillhandahålla tjänster till AUTOSAR-programvarukomponenterna och det används också för att köra den funktionella delen av programvaran. Grundprogramvaran innehåller de standardiserade och ECU-specificerade komponenterna.

Basic Software-lagret är vidare uppdelat i fyra huvudsakliga delar, nämligen Services Layer, ECU Abstraction Layer, Microcontroller Abstraction Layer och Complex Drivers.

I. Servicelager

Det är det översta lagret i det grundläggande mjukvarulagret, det ger de grundläggande mjukvarumodulerna till applikationsprogramvaran och det är oberoende av mikrokontrollern och ECU- hårdvaran.

Servicelagret tillhandahåller funktioner som

Memory Services (NVRAM Management)
Diagnostiska tjänster (inklusive UDS kommunikation och felminne)
Kommunikation och hantering av fordonsnätverk
ECU-statlig förvaltning
Operativsystem (OS)

Det här lagrets montering är specialiserat för mikrokontroller (MCU), delar av ECU-hårdvaran och deras applikationer.

II. ECU-abstraktionsskikt

Detta lager fungerar som ett gränssnitt för mikrokontrollers abstraktionsskikt som också innehåller några drivrutiner för externa enheter. Den har tillgång till kringutrustning och enheter oavsett var de är placerade antingen på insidan eller utsidan av mikrokontrollen. Det erbjuder också API för gränssnitt med mikrokontrollern.

III. Microcontroller Abstraction Layer (MCAL)

Microcontroller-lager är åtkomstvägen för att kommunicera med hårdvaran. Detta lager inramades för att undvika direkt tillgång till mikrokontrollerregister. Den mikrostyrenheten Abstraction Layer (Mcal) är en maskinvaruskikt utformade för att säkerställa standardgränssnittet till komponenterna i grundläggande programvara. Det tillhandahåller mikrokontroller oberoende värden för komponenterna i basprogramvaran och hanterar även kringutrustning för mikrokontroller.

MCAL är försedd med en aviseringsmekanism så att den kan stödja distributionen av kommandon, svar och information till olika processer. Bortsett från detta kan MCAL innehålla några av funktionerna och enheterna 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. Complex Device Driver (CDD)

Detta lager har speciell timing och funktionskrav för hantering av komplexa sensorer och ställdon. CDD används för att hantera komplexa funktioner, den kan inte hittas i några andra lager och den har möjlighet att komma åt mikrokontrollern direkt. De komplexa funktionerna inkluderar injektionskontroll, kontroll av elektriska värden, positionshöjningsdetektering etc.

Mål för AUTOSAR

AUTOSAR skapades av vissa skäl som är till hjälp för närvarande och som också kommer att vara till hjälp i framtiden. Några av målen listas nedan.

Implementering och standardisering av grundläggande funktioner som en branschomfattande "standardkärna" -lösning.
Integrationer av funktionella moduler från olika leverantörer.
Lätt att underhålla processen under hela livscykeln.
Möjligheten att skala olika fordon oberoende av plattformen.
Redundansaktivering.
Hänsyn till tillgänglighet och säkerhetskrav.
Enkel överföring av funktioner från en ECU till en annan ECU inom nätverket.
Använda kommersiell hylla (COTS) hårdvara mer.
Regelbundna programuppdateringar och uppgraderingar under hela fordonets livstid.

Fördelar med AUTOSAR

AUTOSAR har olika fördelar i olika stadier av fordonets livscykel

OEM: Med AUROSAR kan du använda samma programvarukod om och om igen för olika OEM-tillverkare. Det är mer flexibelt att anpassa sig efter olika konstruktioner och minskar också produktionstiden och kostnaden.

Leverantörer: Leverantörer kan öka effektiviteten i funktionell utveckling och skapa sin egen affärsmodell som passar dem.

Verktygsleverantör: AUTOSAR har ett gemensamt gränssnitt som hjälper verktygsleverantören att standardisera sin utvecklingsprocess.

Ny marknadsdeltagare: För de nya aktörerna fungerar AUTOSAR som ett transparent och definierat gränssnitt som kan hjälpa dem att förstå branschstandarderna och även skapa egna affärsmodeller.

Vad kan du förvänta dig med AUTOSAR?

AUTOSAR är utformat för att tjäna olika syften till olika avdelningar inom bilindustrin. Eftersom det är mångsidigt och flexibelt kan du göra många saker utöver det, några av de grundläggande resultaten som AUTOSAR kan ge dig är möjligheten att återanvända programvaran i den för flera enheter och den använda programvaran kan utbytas närhelst den är behövs, fungerar AUTOSAR som en standardplattform för alla fordonsprogramvaror och den har ingen egen tillämpning.

Den har ett operativsystem med grundläggande funktioner och gränssnittsprogramvaror och den största fördelen är att samma gränssnitt kan användas i all grundläggande programvara. Funktionerna hos AUTOSAR levereras som mjukvarukomponenter och alla komponenter som är inblandade är maskinvaruoberoende.