Studie naar de niet-functionele eigenschappen van AUTOSAR gebaseerde software

IWT Beursaanvraag

Studie naar de niet-functionele eigenschappen van AUTOSAR gebaseerde software

Auteur: Joachim D ENIL Karel de Grote Hogeschool [email protected] Promotor: Prof. dr. Serge D EMEYER Universiteit Antwerpen Lab On REengineering [email protected] Co-Promotor: dr. Paul D EMEULENAERE Karel de Grote Hogeschool Labo Automotive-ICT [email protected]

versie: 1.00

Samenvatting Software speelt een steeds belangrijkere rol in voertuigen, getuige de recente standaardisatie inspanningen rond het AUTOSAR platform. Er rijzen echter vragen betreffende de impact van deze standaardisatie op de nietfunctionele eigenschappen van de software. Daarom zal dit onderzoek een vergelijkende studie uitvoeren van AUTOSAR gebaseerde software op geheugengebruik, snelheid en real-time gedrag met verschillende AUTOSAR configuraties. Keuzes in het ontwerpproces van AUTOSAR gebaseerde software hebben een invloed op de geheugen- en snelheidseigenschappen van de software. Door indentificatie van deze keuzes en hun uitwerking op het systeem te meten, zullen wij patterns voorstellen die het ontwerp optimaliseren voor deze niet-functionele vereisten. Op het ontwerpniveau laat AUTOSAR verschillende communicatieparadigma’s toe; daarom zullen wij de relatieve invloed van die paradigma’s onderzoeken. Ontwikkelaars kunnen hierdoor beter de real-time eigenschappen van hun applicatie inschatten. Eens de software ontwikkeld is, moeten de taken gepland worden op het AUTOSAR besturingssysteem en de berichten op de bus. Verschillende heuristieken werden ontwikkeld om dit proces te optimaliseren. Wij zullen verschillende bestaande heuristieken vergelijken in functie van hun haalbaarheid. Uiteindelijk zal dit resulteren in een heuristiek die een backbone topologie met AUTOSAR kan optimaliseren. Door dit onderzoek kunnen automotive bedrijven, vroeger in de ontwerp cyclus de impact op de niet-functionele eigenschappen van hun software inschatten. Het zal bijdragen tot een beter begrip van de AUTOSAR standaard wat op termijn een competitief voordeel zal opleveren voor de toeleveranciers in de Vlaamse automobielindustrie. Het onderzoek zal worden uitgevoerd aan de Karel de Grote Hogeschool in de onderzoeksgroep Automotive-ICT. Er wordt intensief samengewerkt met het Lab On REengineering van Prof. Demeyer.

1

1

Probleemstelling

Sinds het begin van de jaren ’90 speelt software een steeds belangrijkere rol in de ontwikkeling van automotive elektronica. Tegenwoordig zijn meer dan 80% van de innovaties in wagens software gerelateerd [1]. De stuwende kracht voor deze ontwikkelingen is te danken aan de marktvraag naar nieuwe, innovatieve toepassingen op comfortgebied. Denken we maar aan de opkomst van parkeerassistentie [2], nachtvisie [3] en innovaties op gebied van cruisecontrol [4] . Een andere stuwende kracht voor deze innovaties zijn de overheden. Deze leggen de autoconstructeurs steeds scherpere normen op betreffende: (a) emissie: de beperkingen op de uitstoot van vervuilende emissies [5]; (b) veiligheid: regelgeving met betrekking op passagiers en kwetsbare weggebruikers [6]; (c) beveiliging: regelgeving met betrekking tot de beveiliging[7]. De meeste deelsystemen in de wagen hebben een eigen stuurdoos, opgebouwd rond een microcontroller met eigen software. Dit impliceert dat in een gemiddelde personenwagen al vlug 25 tot 35 microcontrollers aanwezig zijn. In luxevoertuigen kan dit zelfs oplopen tot 80 microcontrollers [8]. Om uniformiteit binnen de ontwikkeling van automotive software te bekomen is het AUTOSAR consortium opgericht. Dit consortium, bestaande uit automobielconstructeurs en toeleveranciers, heeft als doel het ontwikkelen van een open systeemarchitectuur. Door het defini¨eren van standaarden bevordert AUTOSAR de samenwerking tussen verschillende producenten en garandeert meer functionaliteit van elektronische componenten en/of hun software [9]. De AUTOSAR standaarden hebben een dubbele focus. Enerzijds defini¨eren ze een platform voor embedded automotive systemen via gestandaardiseerde interfaces. Anderzijds standaardiseert AUTOSAR het ontwikkelingsproces van nieuwe automotive software toepassingen. Dat brengt ons tot volgende probleemstelling: • De automotive industrie werkt in een zeer competitieve markt waarbij kostprijs een bepalende factor is. Als gevolg hiervan wordt veel ontwerptijd ge¨ınvesteerd in het reduceren van geheugen- en snelheidsvereisten van de software, zodat de gekozen geheugengroottes en processorperformantie optimaal zijn [1]. De impact van de ontwerpkeuzes op deze niet-functionele eigenschappen moet gekend zijn om effici¨ente en betrouwbare software te ontwikkelen voor het onderliggende hardware platform [10]. • Vele huidige en toekomstige toepassingen binnen de automotive context zijn zeer tijdkritisch, bijvoorbeeld X-by-Wire systemen[11]. Om veilige software voor dergelijke systemen te kunnen ontwikkelen, moet de impact van ontwerp keuzes op het real-time gedrag van de software onderzocht worden[12]. • Eens de software ontwikkeld is, moet de data gepland worden op het netwerk en de taken gepland worden op het AUTOSAR besturingssysteem. Belangrijk is dat de deadlines van de taken nagekomen worden. 2

2

Doelstellingen

Gedurende dit onderzoek zal ik enerzijds de geheugen- en snelheidsvereisten en anderzijds het real-time gedrag van AUTOSAR gebaseerde software in kaart brengen voor verschillende configuraties. Dit moet leiden naar een beter inzicht in deze niet-functionele eigenschappen op AUTOSAR gebaseerde software. Hierdoor kunnen er sneller in de ontwikkelingscyclus al inschattingen gedaan worden van deze eigenschappen. We defini¨eren volgende subdoelen:

2.1

Doelstellingen in de ontwerp fase van de software

Geheugen- en snelheidsvereisten: Dit onderdeel spitst zich toe op de geheugenen snelheidsvereisten van AUTOSAR-gebaseerde applicaties. In een eerste fase identificeer ik de beslissingsfazen in het ontwikkelingsproces die een invloed kunnen hebben op deze eigenschappen. Met de resultaten uit deze eerste fase ga ik de invloed van de te maken keuzes na op het eindresultaat. Hierdoor kunnen de relaties tussen de verschillende keuzes en de uiteindelijke uitvoerbare code worden vastgelegd. Dankzij deze relaties kunnen er patterns worden opgesteld die toelaten het ontwerpproces systematisch te sturen. Real-time gedrag van AUTOSAR communicatieparadigma’s: AUTOSAR stelt communicatieparadigma’s voor die kunnen gebruikt worden in het ontwikkelen van een applicatie [13]. Deze verschillende paradigma’s kunnen een effect hebben op het real-time gedrag van de applicatie. De impact hiervan moet gekend zijn om de juiste beslissingen te nemen tijdens het designproces. In dit onderdeel zal ik de impact van deze paradigma’s karakteriseren. Met de opgedane ervaring in deze doelstelling kunnen indicaties van het real-time gedrag worden gegeven.

2.2

Doelstellingen in de integratie fase van het systeem

Invloed van de onderliggende hardware-architectuur op het real-time gedrag: AUTOSAR beoogt de ontkoppeling van de applicatie met de onderliggende HW-architectuur. Maar real-time gedrag kan echter onmogelijk worden losgekoppeld van deze onderliggende architectuur [12]. Om tijdskritische applicaties te ontwikkelen is het belangrijk dat de invloed van de onderliggende architectuur kan worden ingeschat. In deze doelstelling zal ik de invloed van de onderliggende architectuur onderzoeken. Er worden heuristieken vergeleken die de bus- en processorplanning optimaliseren voor de real-time eisen van de applicatie.

3

3 3.1

Projectomschrijving Inleiding tot AUTOSAR

Deze inleiding moet de lezer een introductie geven tot de concepten, methode en architectuur van het AUTOSAR-platform. 3.1.1

Concepten

Het AUTOSAR consortium werd 6 jaar geleden opgericht door enkele grote spelers in de automobiel industrie. Ondertussen bevat het consortium meer dan 100 bedrijven uit de industrie. De grootste doelstelling van AUTOSAR omvat de hergebruik van software tussen verschillende voertuigplatformen, autoconstructeurs en toeleveranciers [14]. Het fundamentele concept van AUTOSAR is de volledige scheiding van de applicaties en de onderliggende infrastructuur. Deze applicaties worden gerealiseerd door AUTOSAR software-componenten (SW-C). Een SW-C is een deel van de functionaliteit van een applicatie. SW-C’s zijn eveneens atomisch, dit wil zeggen dat we ze niet kunnen opsplitsen over verschillende gedistribueerde ECU’s. Deze ECU of electronic control unit is een embedded systeem dat een of meerdere (sub)systemen controleert in de wagen. Iedere software-component heeft buiten z’n bron- of objectcode ook metadata. Deze metadata, opgenomen in de software component description, omvat eisen naar de gevraagde diensten, geleverde diensten en resource vereisten [13]. Om de mogelijkheid van herlocatie aan te bieden zijn de SW-C volledig onafhankelijk van de hardware. Deze onafhankelijkheid wordt bereikt door de virtuele functie-bus die optreedt als de virtuele hardware. De virtuele bus zorgt voor een snellere integratie van de software componenten in vergelijking met de traditionele manier van werken [13]. Figuur 1 verduidelijkt dit concept.

Figuur 1: De Virtual Functional Bus (uit [13])

4

3.1.2

ECU software architectuur

Figuur 2: Software Architectuur van een AUTOSAR node (uit [13]) Figuur 2 toont de software structuur van een enkele ECU. SW-C’s worden uitgevoerd in de applicatielaag van de node. Alle interacties tussen deze SWC’s en SW-C’s op andere nodes worden doorgeschakeld via de run-time environment (RTE). De services die de RTE moet aanbieden zijn afhankelijk van de SW-C die worden uitgevoerd. Onder de RTE is de basic software gesitueerd. Deze biedt services aan de SW-C’s aan. De basic software bestaat uit gestandaardiseerde en nodespecifieke componenten. 3.1.3

Methodologie

Figuur 3: AUTOSAR methode (uit [15])

5

Figuur 3 geeft een overzicht van de AUTOSAR methode. De methode start met het system configuration bestand. Deze bevat de architectuur van het systeem waaronder de topologie van het netwerk, de software-componenten en een formele beschrijving van de verschillende ECU’s. De volgende activiteit, configure system, is het mappen van de SW-C’s op de ECU’s. Hierbij moet rekening gehouden worden met de grootte van het geheugen en de snelheid van de processoren. De output van dit proces, het system description configuration bestand, bevat alle informatie over het systeem. Hieruit wordt de ECU specifieke informatie gehaald waarna de eigenschappen van de taken kunnen worden vastgelegd. Uit deze ECU specifieke informatie wordt de uitvoerbare code gegenereerd.

3.2

Geheugen- en snelheidsvereisten

Probleemstelling Zoals eerder reeds vermeld is de automotive sector zeer competitief. Het toevoegen van een meer geheugen of een zwaardere processor op een subsysteem verhoogt de kostprijs van het systeem aanzienlijk. De redenering is als volgt: een component kan geproduceerd worden voor 7 jaar of langer met ongeveer 500000 stuks per jaar. Een hardware reductie van e1 voor 20 van dergelijke componenten (bijv. kleinere processor) in elke auto leidt tot een kost reductie van e70 miljoen. AUTOSAR heeft een directe impact op de geheugenen snelheidsvereisten voor automotive toepassingen. AUTOSAR is zeer modulair opgebouwd. De ontwerpkeuzes die gemaakt worden tijdens het modelleren van de software, bepalen de verschillende basic software componenten die in de uitvoerbare code opgenomen worden. Ook de Run-Time Environment wordt volledig gegenereerd. Het is dus van belang om te weten op modelleringsniveau wat de impact is van deze keuzes. Bestaande technieken Op dit vlak van AUTOSAR werd nog slechts weinig werk verricht vanuit de onderzoeksgemeenschap. In [10] werd een verkennende studie uitgevoerd naar het geheugengebruik van de communicatieparadigma’s die in AUTOSAR aanwezig zijn. Er worden enkele patterns voorgesteld die het geheugengebruik kunnen verminderen. In andere domeinen van de embedded systems gemeenschap werd de laatste jaren veel energie gestoken in het onderzoek naar geheugen- en snelheidsvereisten. In [16] werden schattingen van het geheugengebruik en snelheidvereisten onderzocht op UML niveau. De paper gaat uit van een reeds volledig gekarakteriseerd platform en bibliotheken. Recent werd in [17] de invloed van data-structuren op het geheugengebruik en de energieconsumptie gekarakteriseerd. Er werden patterns voorgesteld zodat een optimale oplossing kan worden bekomen. Deze en andere expertise uit de embedded systems gemeenschap zal ingezet worden in ons project waar de opportuniteiten zich

6

voordoen. Tekortkomingen Op gebied van AUTOSAR is nog heel wat werk te verrichten in de karakterisatie van het volledige systeem. Het onderzoek in [10] is een eerste stap in deze richting. Dit onderzoek is evenwel zeer beperkt en neemt enkel de communicatieparadigma’s op het hoogste niveau in beschouwing. Tijdens het AUTOSAR ontwikkelingsproces zijn andere zaken ook van belang. Een voorbeeld hiervan is het verdelen van de SW-C’s in runnables: de verschillende atomische SW-C’s moeten verdeeld worden in verschillende taken. Deze taken worden dan uitgevoerd op het AUTOSAR besturingssysteem. Hoe deze SW-C’s verdeeld worden, is een beslissing van de ontwikkelaar. Concrete uitwerking In de eerste fase van dit onderzoek wordt een representatieve applicatie voor de automotive industrie gemodelleerd. Deze applicatie moet voldoen aan enkele eigenschappen. Volgende gevalstudie wordt uitgevoerd: gevalstudie 1 - Deurvergrendelingssysteem: Het deurvergrendelingssysteem bevat verschillende SW-C’s. Deze SW-C’s interageren met elkaar door middel van zowel interne als externe communicatie. Het deurvergrendelingssysteem wordt voorgesteld in [18]. Deze applicatie zal in een labo-opstelling verwezenlijkt worden. In het labo Automotive-ICT zijn voldoende hardwareplatformen ter beschikking om dit te realiseren. Daarna begint de exploratie van de ontwerpruimte. De applicatie wordt een aantal keer gemodelleerd waarbij andere ontwikkelingskeuzes gemaakt worden. Door de uitvoerbare code te vergelijken kunnen relaties gelegd worden tussen de niet-functionele eigenschappen van de applicatie en het design model. Belangrijk is te weten hoe deze verschillen ontstaan. Met de kennis opgebouwd in de vorige fase kan een pattern-handboek worden opgesteld dat gebruikt kan worden door software ontwikkelaars. Hiervoor zal ik steunen op de ervaring binnen het Lab On Reengineering dat al verschillende pattern catalogi heeft uitgebracht [19, 20, 17]. Om de patterns te valideren wordt een tweede applicatie gemodelleerd die aan dezelfde eisen als het deurvergrendelingssysteem voldoet. De keuze van deze applicatie moet nog worden gemaakt, maar een mogelijkheid is het verlichtingssysteem van een wagen.

7

3.3

Real-time gedrag van communicatieparadigma’s

Probleemstelling AUTOSAR biedt de software ontwikkelaars 2 communicatieparadigma’s aan die kunnen gebruikt worden bij het sturen en ontvangen van data. Dit kan een client-server interface of een sender-receiver interface zijn. Het gedetailleerde gedrag van deze paradigma’s wordt bepaald door de eigenschappen. Deze eigenschappen omvatten het type van de queue, het gedrag van de verzender en het gedrag van de ontvanger [13]. Zo kan een taak, omdat ze moet wachten op data van een server, naar een wacht status gaan, wat een impact betekent op het real-time gedrag van de applicatie. Anderzijds moeten er op een 2e ontwerpniveau, wanneer het abstracte communicatiemodel reeds opgesteld is, keuzes gemaakt worden voor de communicatie -eigenschappen van de data. Zo is er de keuze voor het type transmissiemode (direct, periodic, ...) en de transfereigenschappen (triggered, pending) van de data. Deze hebben ook een impact op het real-time gedrag van de applicatie [21]. Om tijdskritische applicaties te ontwikkelen moeten applicatie ontwikkelaars op de hoogte zijn van de impact van een communicatie-paradigma. Indien er wordt gekozen voor een verkeerd paradigma moet dit later in de ontwerpcyclus worden weggewerkt. Dit kan leiden tot suboptimale oplossingen. Bestaande technieken In andere domeinen werden communicatieparadigma’s reeds vergeleken. Zo werd in [22] een analytische methode voorgesteld om het real-time gedrag van verschillende communicatie paradigma’s te vergelijken. Op het einde worden ook enkele praktische richtlijnen gegeven voor ontwikkelaars. Tekortkomingen Voor het AUTOSAR platform werd dergelijke studie nog niet uitgevoerd. Omdat real-time gedrag zeer sterk afhankelijk is van de onderliggende hardware, kunnen enkel indicatoren gegeven worden. Concrete uitwerking Om een goed begrip van de eigenschappen van deze paradigma’s te vormen, wordt eerst een theoretische studie uitgevoerd. In deze theoretische studie achterhalen we het gedrag van de software componenten onder invloed van deze paradigma’s. Parameters van deze studie omvatten de eigenschappen van de paradigma’s, het verschil tussen interne en externe communicatie, het type transmissie-mode en de transfereigenschappen. Uit deze studie volgt een model die de relatieve eigenschappen van de paradigma’s beschrijft. Na het opstellen van dit theoretische model worden deze eigenschappen getoetst aan de realiteit. De testapplicatie moet inter en intra ECU communi-

8

catie ondersteunen. Aangezien het deurvergrendelingssysteem uit de eerste gevalstudie voldoet aan deze eis, kunnen veel software componenten worden hergebruikt. De resultaten worden geanalyseerd en vergeleken met het theoretische model. Met de ervaring opgedaan bij het modelleren van de applicaties en het theoretische model kunnen patterns worden opgesteld die als richtlijnen kunnen dienen voor ontwikkelaars. Om de toepasbaarheid van de patterns te bewijzen wordt een nieuwe applicatie gemodelleerd aan de hand van deze patterns. Hierbij moet ook inter en intra ECU communicatie worden ondersteund. Grote delen van de tweede case-studie kunnen hierbij hergebruikt worden.

3.4

Invloed van de HW-architectuur op het real-time gedrag

Probleemstelling System level design methodologie in een actief onderzoeksveld in de embedded systems gemeenschap. Hieronder wordt een zeer gesimplificeerde voorstelling van de methode gegeven. Door middel van de specificaties van het systeem wordt er een systeemmodel opgesteld. Een exploratie van verschillende architecturen, verschillende manieren om de software componenten op de hardware te plaatsen en alternatieve bus- en processorplanning worden onderzocht zodat het uiteindelijke systeemmodel aan de eisen van de applicatie voldoet[23]. In de automobielsector komt hier nog een gegeven bij. Zo verschilt de uitgave van een type wagen met dezelfde wagen 2 jaar later. De ontwikkelaars moeten rekening houden met toekomstige uitbreidingen [1]. Op gebied van busstructuren hebben de systeemontwikkelaars keuze uit verschillende types van netwerken. Deze verschillen onderling van doelstellingen en paradigma’s. Het meest bekende netwerk dat tegenwoordig gebruikt wordt is het controller area network (CAN). Deze bus gebruikt een eventtriggered schema gebaseerd op het CSMA/BA protocol [24]. Om tijdskritische systemen te realiseren zijn andere paradigma’s ontwikkeld zoals een puur time-triggered schema (vb TTP/C [25]). Om aan de toekomstige eisen van automotive datacommunicatie te voldoen werd een combinatie van beide ontwikkeld, nl. FlexRay [26]. Elk van deze bussen vraagt zijn eigen specifieke benadering van de scheduling problematiek. Om het geheel nog meer complexiteit te geven, wordt er niet met een enkele bus gewerkt. Sommige wagens hebben tot 5 bussen in de wagen die verbonden zijn via een gateway [27]. Het werk dat in deze fase verricht wordt, situeert zich in de fase waarin de scheduling van de bus en de taken gebeurt. We formuleren het probleem als volgt: vanuit de systeemarchitectuur, bouw een cyclische planning voor de

9

taken en berichten zodat alle deadlines van de applicatie gehaald worden. Bestaande technieken Er werd de laatste decennia reeds veel onderzoek verricht in de problematiek van planning en de planningsanalyse. Een van deze methoden, het holistische plannen, werd reeds zeer vaak toegepast in de automotive context. Denk maar aan de Volcano tool suite die een bus- en netwerk planning opstelt voor het CAN en LIN1 netwerk [28]. Recenter werd in [23] en [29] een holistische methode opgesteld voor het FlexRay netwerk. Tekortkomingen Zoals in de vorige sectie reeds besproken is, bestaan er reeds verschillende heuristieken voor systemen die slechts 1 bus gebruiken. Ik wens de verschillende heuristieken te vergelijken voor het gebruik met de AUTOSAR scheduler. We vergelijken de heuristieken op basis van (a) oplossing: geeft de gegeven heuristiek een planning die de deadlines haalt? (b) uitbreidbaarheid: is er nog voldoende processortijd / netwerk bandbreedte om toekomstige toepassingen toe te laten? (c) uitvoeringstijd: hoe lang duurt voor een oplossing gevonden wordt? De invloed van de AUTOSAR gebaseerde gateway’s tussen netwerken en de combinatie van verschillende netwerken is in een automotive context nog niet voldoende onderzocht [23]. Ik wens de kennis opgebouwd van de verschillende heuristieken voor de CAN en FlexRay bus te combineren en de invloed van de gateways hierin mee te rekenen. Omdat holistische methodes moeilijk schaalbaar zijn, vernauwen we de problematiek. We nemen slechts een enkele topologie in beschouwing. Deze topologie is een backbone topologie die werd voorgesteld in [30]. Deze topologie bevat een FlexRay backbone netwerk met voor de verschillende domeinen (powertrain, drivetrain, comfort, ...) een CAN of FlexRay netwerk. Deze topologie zal een praktische navolging hebben in de toekomstige automotive architectuur [31]. Concrete uitwerking Dit deel van het onderzoek start met een uitgebreide literatuurstudie naar de huidige technieken die gebruikt worden voor bus- en netwerk planning. Het aantal heuristieken wordt beperkt tot diegene die speciaal ontwikkeld zijn voor een CAN-bus of voor een FlexRay-bus. We beperken ons tot deze 2 bussen omdat de backbone topologie deze ondersteunt. Om de heuristieken te testen op hun geldigheid moet een simulatie omgeving worden opgezet. Verschillende tools zijn in de academische wereld ter beschikking. Zo is er bijvoorbeeld de fortissimo simulator die wordt voorgesteld in [32] of een die werd ontwikkeld in SystemC [33]. Kleine aanpassingen zullen moeten gebeuren aan de simulator zodat deze afgesteld is op de AUTOSAR scheduler en de onderliggende bus. 1 Local

Interconnect Network: ontwikkeld als subnetwerk voor de CAN-bus

10

De gevonden heuristieken worden gesimuleerd onder verschillende omstandigheden. Hierbij kunnnen het aantal processoren, de task-load en busload als parameter dienen. De resultaten van de simulator worden verder geanalyseerd om tot een vergelijking te komen. Als laatste wordt met de verworven kennis een heuristiek opgesteld die een planning kan realiseren voor de backbone topologie.

3.5

Onderzoeksomgeving

Het onderzoek zal worden uitgevoerd in de onderzoeksgroep Automotive-ICT van de Karel de Grote-Hogeschool. In dit lab is een zeer toegepaste kennis van automotive datacommunicatie protocollen aanwezig dankzij het hobuCAN en FlexRay (TETRA) project. Dit jaar start ook een nieuw TETRA-project dat kennis disseminatie van de AUTOSAR standaard beoogt. Verder zijn er nog enkele kortere-termijn projecten in aanmaak. De onderzoeksgroep is mee gestapt in het onderzoeksvoorstel ASIL dat zal worden aangevraagd in het kader van Flanders’ Drive 2. De onderzoeksgroep zal het deel op zich nemen waarbij de AUTOSAR standaard wordt getoetst aan de ASIL2 -normen. Een ander project, in samenwerking met LMS, beoogt het gebruik van model based design met AUTOSAR. In het labo zijn reeds verschillende hardware platformen, met bijhorende tools, aanwezig die speciaal ontwikkeld zijn voor de automobiel sector. Een AUTOSAR compatibel besturingssysteem is gratis te verkrijgen [34]. Andere tools die nodig zijn voor het AUTOSAR platform worden in het kader van het TETRA-project gekocht. De academische garanties voor een doctoraat worden geleverd door de Universiteit Antwerpen. Er zal daarbij intensief worden samengewerkt met het Lab On REengineering (LORE) van Prof. Demeyer, dat in gelijkaardige omstandigheden al aanleiding heeft gegeven tot een doctoraat [17]. Naast de algemene academische expertise rond academisch onderzoek (publiceren, presenteren van wetenschappelijke resultaten) draagt LoRE ook expertise bij rond het opstellen van patterns en pattern handboeken [19, 20], software architectuur en hoe die te analyseren, en tools en hoe die te exploiteren.

2 Automotive

Safety Integrity Level

11

4

Planning

Tijdsindeling: Het projectvoorstel wordt opgedeeld in 4 fases. Ik vat deze periodes kort samen en geef een takenlijst. In de eerste fase worden 2 onderzoeksvragen onderzocht, nl. “Op welke plaatsen in het ontwikkelingsproces kunnen er keuzes gemaakt worden die invloed hebben op geheugen- en snelheidseigenschappen?” en “Wat is de invloed van deze keuzes?”. Deze vragen kunnen slechts beantwoord worden door het hele AUTOSAR ontwikkelingsproces te doorlopen. Daarom wordt een eerste gevalstudie uitgewerkt, het deurvergrendelingssysteem. Door het exploreren van de ontwerpruimte worden relaties gelegd tussen het model en de uitvoerbare code. Met de kennis van deze relaties wordt een pattern handboek opgesteld.

Figuur 4: Fase 1: Oktober 2008 - november 2009 De tweede fase beantwoordt de vraag “Wat zijn de invloeden van de voorgestelde communicatieparadigma’s op het real-time gedrag van AUTOSAR gebaseerde applicaties?”. Een theoretisch model van het gedrag wordt opgesteld en getoetst aan de realiteit met behulp van de eerste gevalstudie. Veel van het werk uit de eerste fase kan hierbij hergebruikt worden.

Figuur 5: Fase 2: november 2009 - mei 2010 Om de opgestelde patterns te valideren, wordt een tweede gevalstudie uitgevoerd. Indien blijkt dat de gekozen applicatie niet relevant is om de hypothese te testen, zijn er nog tal van gevalstudies aanwezig in [18].

12

Figuur 6: Fase 3: mei 2009 - november 2010 De laatste fase van het onderzoek is onafhankelijk van de eerste 3 fases. De vraag “Hoe kunnen we bus- en processorplanning optimaliseren voor de eigenschappen van de applicatie?” wordt beantwoord. Een literatuurstudie en vergelijking van bestaande heuristieken wordt uitgevoerd. Dit moet leiden tot een heuristiek die een backbonetopologie met het AUTOSAR platform kan plannen.

Figuur 7: Fase 4: november 2010 - april 2012 In de laatste 6 maanden rond ik het onderzoek en de rapportering af en schrijf ik de doctoraatsverhandeling. Publiceren: De publicatiestrategie bestaat erin de initi¨ele resultaten voor te stellen op een workshop. Na de verificatie van de patterns kunnen deze worden gebundeld in een conference paper. Mogelijke doelen voor deze publicatie zijn de conferenties: Automotive Electronics Conference of de Design, Automation and Test in Europe conferentie. Naar het einde van het onderzoek, tracht ik de resultaten te publiceren in een journal zoals de Journal on Real-Time Systems of de Journal on Systems and Software.

13

5

Toepassingsmogelijkheden

De automobiel industrie is traditioneel zeer modulair opgebouwd. Vanuit de constructeurs wordt veel van het ontwikkelingswerk uitbesteed aan de toeleveranciers. Toeleveranciers halen ook voordelen uit deze modulaire opbouw van de markt, ze kunnen een subsysteem bouwen voor verschillende constructeurs. Door de opkomst van elektronica en de interactie van verschillende deelsystemen is de taak van de constructeur gewijzigd van een assemblage taak naar een integratietaak [1]. Een grondige kennis van AUTOSAR is van groot economisch belang voor de Vlaamse automotive industrie. Deze bestaat uit een groot deel uit toeleveranciers (GPS-systemen, transmissies, ...) en enkele constructeurs. De interesse voor AUTOSAR vanuit de Vlaamse insdustrie is zeer groot. Dit bewijst het aantal bedrijven die zijn meegestapt in het TETRA-project ”AUTOSAR - gestandardiseerde software in voertuigen”, dit zijn o.a. DSP Valley, Flanders’ Drive, Flanders’ Mechatronics Technolgy Centre, Dana Spicer OffHighway, EIA Electronics NV, LMS International NV, Luperco, Melexis NV, NXP Semiconductors, Open License Society, Punch Powertrain, Triphase en Verhaert new products and services NV. Dit project werd aangevraagd door de Karel de Grote Hogeschool. Ook het aantal deelnemers op de workshop autosar3 , georganiseerd door Flanders’ DRIVE, wijst in deze richting. Flanders ’DRIVE wenst in het ASIL4 -project, partners uit de Vlaamse industrie samen te brengen die in de toekomst AUTOSAR zullen gebruiken. Enkele van deze partners zijn Altreonic, Dana Spicer Off-Highway, EIA Electronics NV, Karel de Grote Hogeschool, Punch Powertrain, Triphase en PsiControl. Dit project draagt op twee vlakken bij tot een beter begrip en toepasbaarheid van de AUTOSAR standaard. Enerzijds worden de geheugen- en snelheidsvereisten van AUTOSAR gebaseerde software in kaart gebracht. Ontwikkelaars kennen de impact van hun keuzes op deze niet-functionele eisen en kunnen hierop inspelen. Anderzijds wordt de bus- en processor scheduling geoptimaliseerd voor de eisen van de applicatie. Zo kan er voor gezorgd worden dat de deadlines, die belangrijk zijn voor tijdskritische applicaties, gehaald worden.

3 Autosar

Information Day, 16 november 2006, Lanaken Safety Integrity Level

4 Automotive

14

Referenties [1] M. Broy, I. Kruger, A. Pretschner, and C. Salzmann. Engineering automotive software. Proceedings Of the IEEE, 95, February 2007. [2, 9, 14] [2] Li Li, Jingyan Song, Fei-Yue Wang, Wolfgang Niehsen, and Nan-Ning Zheng. Ivs 05: New developments and research trends for intelligent vehicles. IEEE Intelligent Systems, 20(4):10–14, 2005. [2] [3] T. Tsuji, H. Hattori, M. Watanabe, and N. Nagaoka. Development of night-vision system. Intelligent Transportation Systems, IEEE Transactions on, 3(3):203–209, 2002. [2] [4] P. Ioannou and C. Chien. Autonomous intelligent cruise control. IEEE Transactions on Vehicular Technology, 42(4), 1993. [2] [5] Europese Unie. Euro 5- en euro 6-normen: van de vervuilende emissies van lichte voertuigen. http://europa.eu/scadplus/, 2007. [2]

beperking online:

[6] Europese Unie. Technische implicaties van de verkeersveiligheid. online: http://europa.eu/scadplus/, 2007. [2] [7] Europese Unie. Directive 74/61/eec. online: http://ec.europa.eu/enterprise/automotive/, 1973. [2] [8] M. Ruff. Reducing power consumption in battery-powered applications. EDN, 2007. http://www.edn.com/index.asp?layout=article& articleid=CA6442438. [2] [9] G.R. AUTOSAR. Automotive open system architecture. www.autosar.org, 2008. [2]

online:

[10] DL Buttle, SE Mitchell, and NS Walker. Guiding AUTOSAR Design Decisions for Memory Constrained Electronic Control Units. VDI BERICHTE, 1931:799, 2006. [2, 6, 7] [11] C. Wilwert, N. Navet, Y.Q. Song, and F. Simonot-Lion. Design of automotive X-by-Wire systems. The Industrial Communication Technology Handbook, 2004. [2] [12] W Damm. Findings of the artist2 workshop: Beyond autosar. 2006. [2, 3] [13] G.R. AUTOSAR. Technical overview, versie 2.2.1. www.autosar.org. [3, 4, 5, 8]

2008.

online:

[14] H. Fennel, S. Bunzel, H. Heinecke, J. Bielefeld, S. Fuerst, K.P. Schnelle, W. Grote, N. Maldener, T. Weber, F. Wohlgemuth, et al. Achievements and exploitation of the AUTOSAR development partnership. AUTOSAR Convergence, 2006. [4] 15

[15] G.R. AUTOSAR. Autosar methodology, versie 1.2.1. www.autosar.org. [5]

2008.

online:

[16] M.F.S. Oliveira, L. Brisolara, F.R. Wagner, and L. Carro. Embedded SW Design Exploration Using UML-based Estimation Tools. DAC Workshop on UML for SoC Design (UML-SOC), Anaheim, USA, 2005. [6] [17] M. Temmerman. Optimizing Abstract Data Type Models for Dynamic and Data-Dominant Embedded Applications. PhD thesis, Universiteit Antwerpen, 2007. [6, 7, 11] [18] G.R. AUTOSAR. Explanation of application interfaces of the body and comfort domain, versie 1.0.1. 2008. online: www.autosar.org. [7, 12] [19] S. Demeyer, S. Ducasse, and O.M. Nierstrasz. Object-Oriented Reengineering Patterns. Morgan Kaufmann, 2003. [7, 11] [20] B. Van Rompaey and M. Rieger. Serious refactoring handbook. SERIOUS Project Deliverable. [7, 11] [21] R. Racu, A. Hamann, R. Ernst, and K. Richter. Automotive software integration. Proceedings of the 44th annual conference on Design automation, pages 545–550, 2007. [8] [22] A. Puliafito, S. Riccobene, and M. Scarpa. Which paradigm should I use? An analytical comparison of the client-server, remote evaluation and mobile agent paradigms. Concurrency and Computation: Practice and Experience, 13(1):71–94, 2001. [8] [23] T. Pop. Analysis and Optimisation of Distributed Embedded Systems with Heterogeneous Scheduling Policies. PhD thesis, Linkoping University, Dep. of computer and information science, 2007. [9, 10] [24] N. Navet. Controller area network [automotive applications]. Potentials, IEEE, 17(4):12–14, 1998. [9] [25] H. Kopetz. Specification of the TTP/C Protocol. TTTech, A, 1040:131–7, 1999. [9] [26] R. Makowitz and C. Temple. Flexray-A communication network for automotive control systems. Factory Communication Systems, 2006 IEEE International Workshop on, pages 207–212, 2006. [9] [27] G. Leen and D. Heffernan. Expanding Automotive Electronic Systems. COMPUTER, pages 88–93, 2002. [9] [28] S. Byhlin, A. Ermedahl, J. Gustafsson, and B. Lisper. Applying Static WCET Analysis to Automotive Communication Software. Real-Time Systems, 2005.(ECRTS 2005). Proceedings. 17th Euromicro Conference on, pages 249–258, 2005. [10] 16

[29] S. Kanajan. A Hierarchical Flexray Bus and Task Scheduler. 2007. [10] [30] EASIS. Deliverable d2.2, conceptual hardware architecture specification, versie 1.0. online: http://www.easis-online.org/, 2006. [10] [31] A Schedl. Goals and architectures for flexray at bmw. Vector FlexRay Symposium, 2007. [10] [32] Thorsten Kramp, Matthias Adrian, and Rainer Koster. An open framework for real-time scheduling simulation. 2000. online: http://wwwagss.informatik.uni-kl.de/. [10] [33] P. Hastrono, S. Klaus, and S.A. Huss. An integrated SystemC framework for real-time scheduling. Assessments on system level. Proceedings of the 25th IEEE International Real-Time Systems Symposium (RTSS04), 2004. [10] [34] J.L. Bechennec, M. Briday, S. Faucou, and Y. Trinquet. Trampoline An Open Source Implementation of the OSEK/VDX RTOS Specification. Emerging Technologies and Factory Automation, 2006. ETFA’06. IEEE Conference on, pages 62–69, 2006. [11]

17