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
versie: 0.13
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 niet-functionele 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. Hierdoor kunnen automotive bedrijven, vroeger in de design cyclus de impact op de niet-functionele eigenschappen van hun software inschatten. Dit onderzoek 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.
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 zijn te danken aan de marktvraag voor nieuwe, innovatieve toepassingen op comfortgebied. Denken we maar aan de opkomst van parkeer assistentie [2], nacht-visie [3] en innovaties op gebied van cruisecontrol [4] . Een andere stuwende kracht voor deze innovaties zijn de overheden, deze leggen de constructeurs steeds scherpere normen op: (a)emissie: De beperkingen op de uitstoot van vervuilende emissies [5]; (b)veiligheid: Regelgeving met betrekking passagiers en kwetsbare weggebruikers [6]; (c)beveiliging: Regelgeving met betrekking tot de beveiliging van voertuigen [7] De meeste van deze deelsystemen hebben een eigen stuurdoos, opgebouwd rond een microcontroller met elk met hun 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 automobiel constructeurs 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 definieert ze een platform voor automotive embedded systemen met gestandardiseerde 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 kost een bepalende factor is. Als gevolg hiervan wordt veel energie ge¨ınversteerd in het reduceren van geheugen- en snelheidsvereisten van de software waardoor de gekozen geheugengrootte en processorperformantie optimaal zijn [1]. De impact van de design keuzes op deze nietfunctionele eigenschappen moet gekend zijn om 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 design keuzes op het real-time gedrag van de software onderzocht worden[12]. • Eens de software ontwikkeld is, moet de data gescheduled worden op het netwerk en de taken gescheduled worden op het AUTOSAR besturingssysteem. Belangrijk is dat de deadlines van de taken gehaald worden.
2
2
Doelstellingen
Gedurende dit onderzoek zal ik enerzijds de geheugen- en snelheidsvereisten en anderzijds real-time gedrag van AUTOSAR gebaseerde software in kaart brengen voor verschillende configuraties. Dit moet leiden naar een beter inzicht in de niet-functionele eigenschappen van 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 design fase
• Geheugen- en snelheidsvereisten: Dit onderdeel spitst zich toe op de geheugen- en snelheidsvereisten van AUTOSAR-gebaseerde applicaties. In een eerste fase identificeer ik de plaatsten in het ontwikkelingsproces die een invloed kunnen hebben op deze eigenschappen. Met de resultaten uit de eerste fase ga ik de invloed van deze 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 design patterns worden opgesteld die het proces optimaliseren. NOTE IGoal: karakterisatie van resource consumptie. Questions: Op welke plaatsen in het ontwikkelingsproces kunnen er keuzes gemaakt worden die invloed hebben op geheugen- en snelheidseigenschappen?, Wat is de invloed van deze keuzes?J
• Real-time gedrag van AUTOSAR communicatie paradigma’s: AUTOSAR stelt communicatie paradigma’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 design-proces. 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. NOTE IGoal: Karakterisatie van real-time gedrag van communicatieparadigma’s. Questions: Wat zijn de invloeden van de voorgestelde communicatie-paradigma’s op het real-time gedrag van AUTOSAR gebaseerde applicaties?J
2.2
Doelstellingen in de integratie-fase
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 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 vergele-
3
ken die de bus- en processorscheduling optimaliseren voor de real-time eisen van de applicatie. NOTE IGoal: Karakterisatie van real-time gedrag onder invloed van de onderliggende architectuur. Questions: Wat zijn de invloeden van de onderliggende architectuur? Hoe kunnen we bus- en processor scheduling optimaliseren voor de eigenschappen van de applicatie?J
4
3 3.1
Projectomschrijving Inleiding tot AUTOSAR
Deze inleiding moet de lezer een introductie geven tot de concepten, methodologie en architectuur van het AUTOSAR-platform. 3.1.1
Concepten
Het AUTOSAR consortium werd 6 jaar geleden opgericht door enkele grote spelers in de automotive industrie. Ondertussen bevat het consortium meer dan 100 bedrijven uit de automotive industrie. De grootste doelstelling van AUTOSAR omvat de herbruik van software tussen verschillende voertuigplatformen, autoconstructeurs en toeleveranciers [14]. Het fundamentele concept van AUTOSAR is de volledige scheiding van 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 ECU1 ’s. 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 services, geleverde services 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. 3.1.2
ECU software architectuur
Figuur 2 toont de software structuur van een enkele ECU. SW-C’s worden uitgevoerd in de applicatie laag van de node. Alle interacties tussen deze SWC’s en SW-C’s op andere nodes worden gerouteerd 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 node specifieke componenten. 1 Electronic Control Unit: Een embedded systeem dat een of meerdere elektrische (sub)systemen controleert in de wagen
5
Figuur 1: De Virtual Functional Bus
Figuur 2: Software Architectuur van een AUTOSAR node 3.1.3
Methodologie
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 stukken 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.
6
AUTOSAR is zeer modulair opgebouwd. Door design keuzes die gemaakt worden in het modelleren van de software worden verschillende basic software componenten in de uitvoerbare code opgenomen. Ook de Run-time Environment wordt volledig gegenereerd. Het is dus van belang om te weten op modelleringsniveau wat de impact is van de keuzes op geheugen- en snelheid. 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 communicatie-paradigma’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 reeds veel energie gestoken in het onderzoek naar geheugen- en snelheidsvereisten. In [15] 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 [16] de invloed van datastructuren op het geheugengebruik en de energieconsumptie gekarakteriseerd. Er werden patterns voorgesteld zodat een optimale oplossing kan worden bekomen. Tekortkomingen Op gebied van AUTOSAR is nog heel wat werk te verrichten in de karakterisatie van het volledige systeem. De paper [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 is het verdelen van de SW-C’s in runnables2 . Concrete doelstellingen In een eerste fase wordt een representatieve applicatie voor de automotive industrie gemodelleerd. Deze applicatie moet voldoen aan enkele eigenschappen. Ze moet (a)verschillende SW-C bevatten, (b)zowel inter-ECU als intra-ECU communicatie ondersteunen, (c)concrete deadlines voor de uitvoering van subsystemen hebben. Ik heb gekozen om een deel van het door-lock systeem te modelleren zoals voorgesteld in [17]. Deze applicatie zal in een labo-opstelling verwezenlijkt worden. Een meetmethodiek moet worden opgesteld zodat de resultaten betrouwbaar zijn en niet onderhevig aan optimalisaties die gebeuren door de compiler. AUTOSAR basic software is eveneens zeer implementatie-afhankelijk. Hiermee moet rekening gehouden worden om de impact van design-keuzes goed te kunnen inschatten. 2 SW-C’s worden verdeeld in runnables. Deze runnables kunnen dan gescheduled worden als taken op het AUTOSAR OS.
7
In een tweede fase modelleren we de applicatie opnieuw waarbij andere design keuzes 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 designers. Om de correctheid van de patterns te bewijzen wordt een tweede applicatie gemodelleerd die aan dezelfde eisen als de eerste voldoet.
3.3
Real-time gedrag van communicatie paradigma’s
Probleemstelling AUTOSAR biedt de software ontwikkelaars 2 communicatie paradigma’s aan die kunnen worden gebruikt bij het sturen en ontvangen van data. Dit kan enerzijds een client-server interface of een sender-receiver interface zijn. Het gedetailleerde gedrag van deze paradigma’s wordt bepaald door z’n 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 waiting status gaan wat een impact betekent op het real-time gedrag van de applicatie. Anderzijds moeten er op een 2e design niveau, wanneer het abstracte communicatiemodel reeds opgesteld is, keuzes gemaakt worden voor de communicatieeigenschappen van de data. Zo is er de keuze voor het type transmissie mode en de transfereigenschappen van de data. Deze hebben ook een impact op het real-time gedrag van de applicatie [18]. Om tijdskritische applicaties te ontwikkelen moeten applicatie designers op de hoogte zijn van de impact van een communicatie-paradigma. Indien er wordt gekozen voor een verkeerd paradigma moet dit later in de design fase worden weggewerkt. Dit kan leiden tot sub-optimale oplossingen. Bestaande technieken Tekortkomingen Indicatoren opstellen Concrete doelstellingen
3.4
Invloed van de HW-architectuur op het real-time gedrag
Probleemstelling System level design methodologie evolueert continu, we geven een gesimplificeerde voorstelling van het geheel. Door middel van de specificaties van 8
het systeem wordt er een system model opgesteld, hieruit kan een architectuur gekozen worden die aan de vereisten voldoet. Eens de architectuur vastligt en de software componenten bepaald zijn kan het mappen van de software op de hardware beginnen. Daarna volgt het proces om de bus en de taken te schedulen. Als laatste gebeurt er een analyse om te kijken dat de eisen van de applicatie, waaronder de deadlines, gehaald zijn. Indien dit niet het geval is kan er opnieuw een mapping en schedule worden opgesteld of voor een andere architectuur worden gekozen [19]. In de automotive sector komt hier nog een gegeven bij. Zo verschilt de release 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 systeem ontwikkelaars keuze uit verschillende types van netwerken. Deze verschillen onderling van doelstellingen en paradigma’s. De meest bekende netwerk dat tegenwoordig gebruikt wordt is het controller area network (CAN), deze bus gebruikt een event-triggered schema gebaseerd op het CSMA/BA protocol [20]. Om tijdskritische systemen te gebruiken zijn andere paradigma’s ontwikkeld zoals een puur timetriggered schema (vb TTP/C [21]). Om aan de toekomstige eisen van automotive datacommunicatie te voldoen werd een combinatie van beide ontwikkeld, nl. FlexRay [22]. Elk van deze bussen vraagt zijn eigen specifieke benadering tot 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 geconnecteerd zijn via een gateway [23]. 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 systeem architectuur, bouw een cyclische schedule voor de taken en berichten zodat alle deadlines van de applicatie kunnen gehaald worden. Bestaande technieken Er werd de laatste decennia reeds veel onderzoek verricht in de problematiek van scheduling en de schedulability analyse. Een van deze methoden, het holistische schedulen, werd reeds zeer vaak toegepast in de automotive context. Denk maar aan de Volcano tool suite die een bus- en netwerk schedule opstelt voor het CAN en LIN3 netwerk [24]. Recenter werd in [19] en [25] 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 schedule die de deadlines haalt? (b) uitbreidbaarheid: Is er nog 3 Local
Interconnect Network: ontwikkeld als subnetwerk voor de CAN-bus
9
voldoende processortijd / netwerk bandbreedte om toekomstige toepassingen toe te laten? (c) snelheid tot oplossing: Is de heuristiek bruikbaar voor het gebruik in een tool-suite? 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 [19]. Ik wens de kennis opgebouwd voor de verschillende bussen 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 [26]. 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 TOFIX IBMW paper J. Concrete doelstellingen • Literatuurstudie: evaluatie van bestaande heuristieken die gebruikt worden voor bus- en netwerk scheduling. • Simulator aanpassen van [27]. Hier is scheduling policy reeds OK maar de bus moet nog worden meegesimuleerd. Ofwel simulator vanuit van [28] aanpassen aan de AUTOSAR OS scheduler. • Evaluatie van de verschillende heuristieken met verschillende processorloads, aantal taken, bus-loads. • Proberen generaliseren van een heuristiek
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. TOFIX IMarijn haar onderzoek, eveneens in samenwerking met LORE, ook over niet-functionele vereisten van software maar gericht op geheugen en power consumptie optimalisatieJ TOFIX ILORE lab: kennis op gebied van design patterns zie design pattern boek over reengineering en optimalisatieJ
10
4
Planning
Tijdsindeling: Publiceren:
11
5
Toepassingsmogelijkheden
De automotive industrie is traditioneel zeer verticaal opgebouwd. Vanuit de constructeurs wordt veel van het ontwikkelingswerk verdeeld naar 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 electronica 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 autosar4 , georganiseerd door Flanders’ DRIVE, wijst in deze richting. TOFIX Iklein voorbeeldje wie autosar in de toekomst wenst te gebruiken DANA?J
Dit project draagt op twee vlakken bij tot een beter begrip 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.
4 Autosar
Information Day, 16 november 2006, Lanaken
12
Referenties [1] M. Broy, I. Kruger, A. Pretschner, and C. Salzmann. Engineering automotive software. Proceedings Of the IEEE, 95, February 2007. [2, 9, 12] [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: beperking van de vervuilende emissies van lichte voertuigen. online: http://europa.eu/scadplus/leg/nl/lvb/l28186.htm, 2007. [2] [6] Europese Unie. Technische implicaties van de verkeersveiligheid. online: http://europa.eu/scadplus/leg/nl/s06022.htm, 2007. [2] [7] Europese Unie. Directive 74/61/eec. online: http://ec.europa.eu/enterprise/automotive/directives/vehicles/dir74 61 cee.html, 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, 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, 5, 8]
13
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. [5] [15] 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. [7] [16] Marijn Temmerman. Optimizing Abstract Data Type Models for Dynamic and Data-Dominant Embedded Applications. PhD thesis, Universiteit Antwerpen, 2007. [7] [17] G.R. AUTOSAR. Explanation of application interfaces of the body and comfort domain, versie 1.0.1. 2008. online: www.autosar.org. [7] [18] 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] [19] Traian 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] [20] N. Navet. Controller area network [automotive applications]. Potentials, IEEE, 17(4):12–14, 1998. [9] [21] H. Kopetz. Specification of the TTP/C Protocol. TTTech, A, 1040:131–7, 1999. [9] [22] 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] [23] G. Leen and D. Heffernan. Expanding Automotive Electronic Systems. COMPUTER, pages 88–93, 2002. [9] [24] 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. [9] [25] S. Kanajan. A Hierarchical Flexray Bus and Task Scheduler. 2007. [9] [26] EASIS. Deliverable d2.2, conceptual hardware architecture specification, versie 1.0. online: http://www.easis-online.org/, 2006. [10] [27] Thorsten Kramp, Matthias Adrian, and Rainer Koster. An open framework for real-time scheduling simulation. 2000. online: http://wwwagss.informatik.uni-kl.de/. [10] 14
[28] 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]
15
