- AUTOSAR - Hoe het allemaal begon?
- Belang van AUTOSAR
- Verschillende lagen van AUTOSAR-architectuur
- Doelstellingen van AUTOSAR
- Voordelen van AUTOSAR
- Wat kunt u van AUTOSAR verwachten?
AUTOSAR (Automotive Open System Architecture) kan worden gedefinieerd als een gemeenschappelijk platform voor de hele auto-industrie dat is ontworpen om het toepassingsgebied van voertuigfunctionaliteit te vergroten zonder het huidige operationele model te beïnvloeden. AUTOSAR is in feite een open en standaard softwarearchitectuur die gezamenlijk is ontwikkeld door autofabrikanten, leveranciers en ontwikkelaars van tools. In dit artikel zullen we leren wat AUTOSAR is en over de verschillende lagen in zijn architectuur.
Het belangrijkste motto van AUTOSAR is "Samenwerken aan standaarden, concurreren bij implementatie". Deze unieke architectuur is ontwikkeld om een gemeenschappelijke standaard tot stand te brengen en te handhaven tussen de fabrikanten, softwareleveranciers en toolontwikkelaars, zodat het resultaat van het proces kan worden geleverd zonder dat er enige wijzigingen nodig zijn.
AUTOSAR - Hoe het allemaal begon?
In 2003 werd het AUTOSAR-partnerschap gevormd als een alliantie van OEM-fabrikanten (Original Equipment Manufacturer), autoleveranciers van Tire 1, halfgeleiderfabrikanten, softwareleveranciers, leveranciers van gereedschappen en anderen. Zij vestigden AUTOSAR als een open industriestandaard voor automotive software-architectuur door te kijken naar de verschillende auto-E / E architectuur die aanwezig is en dat tie waren en in de toekomst zou worden gevormd.
De 10 kernpartners van AUTOSAR zijn BMW Group, Bosch, Continental, DaimlerChrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, SiemensVDO, Toyota Motor Corporation en Volkswagen.
Belang van AUTOSAR
De infrastructuur van AUTOSAR is niet eenvoudig, maar waarom is het nodig om zo'n complexe infrastructuur in de auto-industrie te introduceren? Enerzijds Waarom hebben we AUTOSAR nodig?
Naarmate de vraag naar het intelligente, veiligere en slimmere voertuig toeneemt, zal ook de concurrentie in de auto-industrie toenemen. Al deze intelligentie en voertuigfunctionaliteit kunnen niet door één autoriteit worden geïmplementeerd.
Een auto heeft bijvoorbeeld airbags, een gps-systeem, slimme integratie, enz. Al deze functies worden geïmplementeerd op de verschillende ECU's (Electronic Control Units) door verschillende auto-industrieën, dus alle verschillende auto-eenheden moeten hand in hand kunnen werken om verkrijg het gewenste stopcontact.
Dit helpt ook bij het softwareontwikkelingsproces, omdat tot voor kort de software die voor de auto-industrie werd ontwikkeld, alleen gericht was op het leveren van de functionaliteit van het systeem en het hen nooit kon schelen wat de effecten zijn die het op het systeem kan hebben. Het werd ingewikkelder vanwege de vele functionaliteiten van verschillende ECU's in verschillende voertuignetwerken. Het werd een kritischer probleem met de toename van niet-standaard ontwikkelingsprocedures. Daarom hebben ze de AUTOSAR ontwikkeld.
Verschillende lagen van AUTOSAR-architectuur
Als u naar de bovenstaande afbeelding kijkt, kunt u zien dat de architectuur van de AUTOSAR bestaat uit drie hoofdlagen, namelijk
- Applicatielaag
- Runtime-omgeving (RTE)
- Basissoftware (BSW)
Elk van deze lagen heeft zijn eigen doel en moet een specifieke bewerking uitvoeren
Applicatielaag
De AUTOSAR-applicatielaag bestaat uit verschillende applicaties en specifieke softwarecomponenten die zijn ontworpen om een specifieke taak uit te voeren volgens de gegeven instructies. De applicatielaag is de bovenste laag van AUTOSAR's softwarearchitectuur en daarom is deze van cruciaal belang voor alle voertuigtoepassingen. De applicatielaag omvat drie van de belangrijkste componenten waarmee rekening moet worden gehouden. Het zijn toepassingssoftwarecomponenten, poorten van deze componenten en poortinterfaces.
De softwarecomponenten zorgen voor de functionaliteit van het subsysteem, dat de bewerkingen en gegevenselementen omvat die de software nodig heeft en de middelen die de componenten nodig hebben. En de bron van de applicatie is onafhankelijk van de locatie van de interactieve componenten, het type ECU waarop de component is afgebeeld en het aantal keren dat de component in een systeem wordt geïnstantieerd.
Runtime Environment (RTE) -laag
De runtime-omgevingslaag creëert een geschikte omgeving voor de werking van de softwarecomponenten (SWC's). De SWC is altijd afhankelijk van de interface die door de RTE wordt geboden.
Het kan worden beschouwd als het communicatiecentrum tussen de ECU's die zich binnen het netwerk bevinden. Het helpt de softwarecomponenten onafhankelijk van de communicatiemechanismen en kanalen te werken. De RTE maakt dit mogelijk door de communicatierelaties tussen componenten die in de verschillende sjablonen zijn geïmplementeerd, in kaart te brengen met een specifiek intra-communicatiemechanisme zoals een oproep of een inter-ECU-communicatiemechanisme zoals een COM-bericht.
RTE is verantwoordelijk voor het beheer van de levenscyclus van de SWC. Het moet de functies opstarten en afsluiten op basis van de behoeften. Het fungeert ook als een scheidingslaag tussen de applicatiesoftware (ASW) en de basissoftware (BSW) waar de basissoftware toestemming had om een API-functie of andere modules rechtstreeks aan te roepen, maar de applicatiesoftware kan alleen communiceren via poorten.
De RTE wordt gegenereerd in twee fasen
- Contractfase: deze fase is onafhankelijk van de ECU en biedt het contract tussen de applicatiesoftware en de RTE, dat wil zeggen dat de API van de ASW-componenten kan worden gecodeerd.
Het heeft geresulteerd in een ASW-component gespecificeerde header die we kunnen opnemen in de broncode. Het header-bestand bestaat uit alle RTE API-functies die kunnen worden gebruikt in de ASW en ook de benodigde datatypes en structuren die nodig zijn voor de ASW-componenten worden gedeclareerd in het header-bestand.
- Generatiefase: deze fase zal zich richten op het genereren van de concrete code voor een bepaalde ECU. Met de ASW-componenten en headerbestanden die in de contractfase zijn gemaakt en alle benodigde BSW-code, kan de gegenereerde code worden gecompileerd tot een uitvoerbaar bestand voor de ECU.
Basissoftware (BSW)
De Basic Software-laag kan worden gedefinieerd als de gestandaardiseerde software die diensten kan verlenen aan de AUTOSAR-softwarecomponenten en wordt ook gebruikt om het functionele deel van de software uit te voeren. De basissoftware bevat de gestandaardiseerde en door de ECU gespecificeerde componenten.
De basissoftwarelaag is verder onderverdeeld in 4 hoofdonderdelen, namelijk Services Layer, ECU Abstraction Layer, Microcontroller Abstraction Layer en Complexe stuurprogramma's.
I. Servicelaag
Het is de bovenste laag van de basissoftwarelaag. Het levert de basissoftwaremodules voor de toepassingssoftware en is onafhankelijk van de microcontroller en ECU- hardware.
De servicelaag biedt functies zoals
- Geheugendiensten (NVRAM-beheer)
- Diagnostische services (inclusief UDS
communicatie- en foutgeheugen) - Voertuig netwerkcommunicatie en beheer
- ECU staatsbeheer
- Besturingssysteem (OS)
De montage van deze laag is gespecialiseerd voor microcontroller (MCU), onderdelen van de ECU-hardware en hun toepassingen.
II. ECU-abstractielaag
Deze laag fungeert als een interface van de abstractielaag van de microcontroller die ook enkele stuurprogramma's van externe apparaten bevat. Het heeft toegang tot de randapparatuur en de apparaten, ongeacht waar ze zich binnen of buiten de microcontroller bevinden. Het biedt ook de API om te communiceren met de microcontroller.
III. Microcontroller Abstraction Layer (MCAL)
De microcontrollerlaag is de toegangsroute om met de hardware te communiceren. Deze laag is omkaderd om directe toegang tot microcontrollerregisters te vermijden. De microcontroller Abstraction Layer (MCAL) is een hardwarelaag die is ontworpen om de standaardinterface met de componenten van basissoftware te waarborgen. Het biedt microcontroller-onafhankelijke waarden voor de componenten van de basissoftware en beheert ook de randapparatuur van de microcontroller.
De MCAL is voorzien van een meldingsmechanisme zodat het de distributie van commando's, reacties en informatie naar verschillende processen kan ondersteunen. Afgezien hiervan kan de MCAL enkele van de functies en apparaten bevatten, zoals digitale I / O (DIO), analoog / digitaal converter (ADC), pulsbreedte (de) modulator (PWM, PWD), EEPROM (EEP), flitser (FLS), Capture Compare Uni (CCU), Watchdog Timer (WDT), Serial Peripheral Interface (SPI), I2C Bus.
IV. Complex Device Driver (CDD)
Deze laag heeft speciale timing en functionele vereisten voor het omgaan met complexe sensoren en actuatoren. De CDD wordt gebruikt voor het afhandelen van complexe functies, kan niet in andere lagen worden gevonden en heeft de mogelijkheid om rechtstreeks toegang te krijgen tot de microcontroller. De complexe functies omvatten injectiecontrole, controle van elektrische waarden, detectie van positieverhoging, enz.
Doelstellingen van AUTOSAR
AUTOSAR is gemaakt om bepaalde redenen die nuttig zijn voor het heden en die ook in de toekomst nuttig zullen zijn. Enkele van de doelstellingen worden hieronder vermeld.
- Implementatie en standaardisatie van basisfuncties als een industriebrede "standaard kern" -oplossing.
- Integraties van functionele modules van verschillende leveranciers.
- Gemakkelijk om het proces gedurende de hele levenscyclus te onderhouden.
- De mogelijkheid om verschillende voertuigen onafhankelijk van het platform te schalen.
- Redundantie-activering.
- Overweging van beschikbaarheid en veiligheidseisen.
- Eenvoudige overdracht van functies van de ene ECU naar de andere ECU binnen het netwerk.
- Meer commerciële off-the-shelf (COTS) hardware gebruiken.
- Regelmatige software-updates en upgrades gedurende de levensduur van het voertuig.
Voordelen van AUTOSAR
AUTOSAR biedt verschillende voordelen in verschillende stadia van de levenscyclus van het voertuig
OEM's: Met AUROSAR kunt u dezelfde softwarecode keer op keer gebruiken voor verschillende OEM's. Het is flexibeler om aan te passen aan verschillende ontwerpen en vermindert ook de tijd en kosten van productie.
Leveranciers: leveranciers kunnen hun efficiëntie van functionele ontwikkeling verhogen en hun eigen bedrijfsmodel creëren dat bij hen past.
Tool Provider: AUTOSAR heeft een gemeenschappelijke interface die de tool provider helpt bij het standaardiseren van hun ontwikkelingsproces.
Nieuwkomer op de markt: Voor nieuwkomers fungeert AUTOSAR als een transparante en gedefinieerde interface die hen kan helpen de industriestandaarden te begrijpen en ook om hun eigen bedrijfsmodellen te creëren.
Wat kunt u van AUTOSAR verwachten?
AUTOSAR is ontworpen om verschillende doeleinden te dienen voor verschillende afdelingen van de auto-industrie. Omdat het veelzijdig en flexibel is, kunt u er veel andere dingen mee doen. Enkele van de basisresultaten die de AUTOSAR u kan bieden, zijn de mogelijkheid om de software erin te hergebruiken voor meerdere eenheden en de gebruikte software kan op elk moment worden uitgewisseld. AUTOSAR fungeert als een standaardplatform voor alle voertuigsoftware en heeft geen eigen applicatie.
Het heeft een besturingssysteem met basisfuncties en interfacesoftware en het belangrijkste voordeel is dat dezelfde interface in alle basissoftware kan worden gebruikt. De functionaliteiten van AUTOSAR worden geleverd als softwarecomponenten en alle betrokken componenten zijn hardware-onafhankelijk.