2009 phdthesis schreiner

Dissertation

Component Based CommunicationMiddleware for AUTOSAR

Ausgefhrt zum Zwecke der Erlangung des akademischen Grades einesDoktors der technischen Wissenschaften unter der Leitung von

o.Univ.Prof. Dr.techn. Mehdi Jazayeriund

Dr.techn. Karl M. Gschka

184-1Institut fr Informationssysteme

Arbeitsbereich fr Verteilte Systeme

eingereicht an der Technischen Universitt WienFakultt fr Informatik

von

Dipl.-Ing.(FH) Dietmar SchreinerMatr.Nr. 9026735

Wien, Oktober 2009

Die approbierte Originalversion dieser Dissertation ist an der Hauptbibliothek der Technischen Universitt Wien aufgestellt (http://www.ub.tuwien.ac.at). The approved original version of this thesis is available at the main library of the Vienna University of Technology (http://www.ub.tuwien.ac.at/englweb/).

This work has been partially funded by the FIT-IT Embedded Systemsinitiative of the Austrian Federal Ministry of Transport, Innovation, andTechnology, and managed by Eutema and the Austrian Research AgencyFFG within research project COMPASS under contract 809444, and by the7th EU R&D Framework Program within research project ALL-TIMES undercontract 215068.

Kurzfassung

Aufgrund stndig wachsender Anforderungen und innovativer Neuerungenim Automobilbereich haben sich automotive Elektroniksysteme innerhalbder letzten Jahre zu komplexen, verteilten Echt-Zeit-Systemen entwickelt.Um der daraus resultierenden Kostenschere zwischen steigender Komplexittund vertretbarem Entwicklungsaufwand entgegenzuwirken, legt der jungeIndustriestandard AUTOSAR Komponentenbasierte Software-Entwicklung(CBSE) als Methodik fr zuknftige automotive Anwendungen fest.Durch den Einsatz des Komponentenparadigmas auf Applikationsebene wirdeine klare Aufgabentrennung innerhalb automotiver Software festgelegt: An-wendungen werden aus wiederverwendbaren und austauschbaren Bausteinen,den Software-Komponenten, zusammengesetzt, deren Implementierung nuranwendungsspezifische Funktionalitt enthlt. Infrastrukturelle Funktional-itt wird durch standardisierte Komponenten-Middleware, der AUTOSARBasic Software und dem AUTOSAR Run-Time Environment , realisiert, undden Software-Komponenten zur Verfgung gestellt. Die so gewhlte Ar-chitektur soll zu einer Steigerung der Wiederverwendbarkeit, Wartbarkeitund Qualitt automotiver Software, und daher zu einer Eindmmung vonKosten und Entwicklungszeit fhren.Die vom AUTOSAR Standard definierte Middleware ist allerdings alsSchichtenarchitektur spezifiziert, die nur im Groben an Anwendungsan-forderungen angepasst werden kann. Hufig ist daher ungenutzte Funktional-itt in eingesetzter Middleware enthalten, und trgt dazu bei, da herkmm-liche AUTOSAR konforme Komponenten-Middleware oft berdimensioniertund verschwenderisch im Umgang mit verfgbaren Ressourcen ist. DieseTatsache stellt gerade im Bereich von ressourcenbeschrnkten automotiveneingebetteten Systemen eine Schwche des AUTOSAR Standards dar.Die vorliegende Dissertation trgt zur Entschrfung der Middleware-Problematik in AUTOSAR bei, indem sie den Einsatzbereich von CBSEber die Anwendungsschicht hinaus auf die Komponenten-Middleware, imspeziellen auf das Kommunikationssubsystem, ausdehnt.Dazu wird in einem ersten Schritt gezeigt, wie die schichtenbasierte Architek-tur der AUTOSAR Middleware durch eine komponentenbasierte ersetzt wer-den kann. Die vorgeschlagene komponentenbasierte Architektur wird mittelseiner statischen Analyse, der Kohsionsanalyse, aus einer herkmmlichen in-dustriellen Implementierung extrahiert, und bietet bei grerer Flexibilittvollwertigen, standardkonformen Ersatz fr diese. Zustzlich werden aufunterschiedliche Anwendungsflle hin optimierte Implementierungsvariantender errechneten Middleware-Komponentenklassen definiert, durch deren Ein-

satz mageschneiderte, komponentenbasierte Middleware erzeugt werdenkann.In einem zweiten Schritt wird eine Modell-Transformation, die Konnektor-Transformation, fr AUTOSAR Applikationsmodelle vorgestellt, die eineautomatische Synthese von applikationsspezifisch optimierter Middlewarebewerkstelligt. Die Konnektor-Transformation ersetzt alle Vorkommnissevon so genannten expliziten Konnektoren in plattformunabhngigen App-likationsmodellen durch Middleware-Komponentenarchitekturen, bestehendaus vorgefertigten Middleware-Komponenten. Die so generierten und demVerteilungsszenario der Applikation entsprechenden plattformspezifischenModelle enthalten als Ergebnis die Applikation, sowie genau jene Middleware-Funktionalitt, die von der Applikation bentigt wird. Schlussendlich werdendie plattformspezifischen Modelle in ausfhrbaren Code fr jeden System-knoten der (eventuell verteilten) Applikation transformiert.Um die entwickelte Methodik zu evaluieren, wurde eine einfache automo-tive Anwendung sowohl in herkmmlicher als auch in der vorgeschlagenenArt und Weise entwickelt. Wie Messungen zeigen, weist die synthetisierteKommunikationsmiddleware eine eindeutige Verbesserung im Bezug auf Pro-grammgre und Prozessorlast auf: Synthetisierte Middleware ist bezglichihres Programmspeicherbedarfs um bis zu 30% kleiner, und bentigt um biszu 10% weniger Ausfhrungszeit, als herkmmliche AUTOSAR Kommunika-tionsmiddleware.

Abstract

Driven by steadily increasing requirements of innovative applications, auto-motive electronics has evolved into highly dependable, distributed, real-timeembedded systems. To close the rising gap between increasing complexityand affordable costs, the upcoming automotive software standard AUTOSARconstitutes Component Based Software Engineering (CBSE ) as developmentmethodology for future automotive applications. CBSE introduces a clearseparation of concerns into AUTOSARs system architecture: Any applica-tion is built from reusable and exchangeable so called Software Componentsthat deal with business logic only, whereas standardized infrastructural ser-vices are provided by component middlewarethe AUTOSAR Basic Soft-ware and the AUTOSAR Run-Time Environment . This design leads to anincrease in reusability, maintainability, and application quality, and hence toa reduction of costs and time-to-market. However, AUTOSAR componentmiddleware is specified as layered software architecture that is customizableon a coarse-grained level only, and thus tends to be heavy-weight and im-practical in resource constrained embedded systems.This thesis contributes by extending the scope of CBSE within AUTOSARbeyond the application layer to the component middleware, especially to itscommunication subsystem. In a first step, the layered AUTOSAR middle-ware architecture is replaced by a component based design that is extractedfrom an existing layered reference implementation by static analysistheCohesion Analysis . The proposed component based communication middle-ware completely resembles the standards functionality, but is more flexible interms of application specific customization. In addition, use-case based vari-ants of identified component classes are defined to enable improved middle-ware optimization. In a second step, a model transformation for AUTOSARapplication models is specified that enables automatic middleware synthesisin line with the AUTOSAR methodology. The Connector Transformationinjects middleware component architectures in place of all explicit connec-tors within the application models. Thereby, platform-specific models foreach system node are generated, which completely and solely reflect the ap-plications middleware requirements.To evaluate the proposed approach, it is applied to a simple automotive ap-plication. The hereby gained synthesized communication middleware showsan improvement of nearly 30% with respect to its memory footprint and areduction in CPU usage of up to 10% compared to its conventional counter-part.

Acknowledgements

I would like to thank all those persons, who supported me during the pro-cess of writing this thesis: Dr. Karl M. Gschka for supporting and guid-ing my research activities, o.Univ.Prof. Dr. Mehdi Jazayeri for being mysenior adviser and providing helpful pointers, Prof. Dr. Uwe Amann for re-viewing the thesis, o.Univ.Prof. Dr. Jens Knoop and Dr. Markus Schordanfor fruitful discussions on static analysis, Dr. Martin Horauer for hissupport within project COMPASS, Dr. Thomas Galla for the numerousAUTOSAR specific discussions, and finally Dipl.-Ing.(FH) Wolfgang Forsterand Dipl.-Ing. Gerg Barany for their support at the proof-of-concept imple-mentation and the measurements.

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Technological Baseline and State-of-the-Art 92.1 Component Based Software Engineering . . . . . . . . . . . . 9

2.1.1 Components . . . . . . . . . . . . . . . . . . . . . . . . 102.1.1.1 Component Definition . . . . . . . . . . . . . 112.1.1.2 Interfaces . . . . . . . . . . . . . . . . . . . . 132.1.1.3 Ports . . . . . . . . . . . . . . . . . . . . . . 14

2.1.2 Connectors . . . . . . . . . . . . . . . . . . . . . . . . 152.1.3 Component Middleware . . . . . . . . . . . . . . . . . 17

2.2 Model Driven Development . . . . . . . . . . . . . . . . . . . 202.2.1 Viewpoints and Models . . . . . . . . . . . . . . . . . . 212.2.2 Transformations . . . . . . . . . . . . . . . . . . . . . . 232.2.3 MDA Development Phases . . . . . . . . . . . . . . . . 25

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Automotive Open System Architecture 283.1 History of AUTOSAR . . . . . . . . . . . . . . . . . . . . . . 283.2 Hardware Architecture . . . . . . . . . . . . . . . . . . . . . . 293.3 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Application Software Architecture . . . . . . . . . . . . 313.3.2 System Software Architecture . . . . . . . . . . . . . . 32

3.4 AUTOSAR Software Components . . . . . . . . . . . . . . . . 353.4.1 Software Component Definition . . . . . . . . . . . . . 363.4.2 Composition and Interaction . . . . . . . . . . . . . . . 383.4.3 Component Middleware . . . . . . . . . . . . . . . . . 40

3.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

vi

3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 COMPASS Middleware 434.1 Component Based Middleware . . . . . . . . . . . . . . . . . . 434.2 Component Model . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . 454.2.2 Component Definition . . . . . . . . . . . . . . . . . . 47

4.2.2.1 Embodiment of COMPASS Components . . . 484.2.2.2 Component Type . . . . . . . . . . . . . . . . 51

4.2.3 Composition and Interaction . . . . . . . . . . . . . . . 534.3 Middleware Components . . . . . . . . . . . . . . . . . . . . . 54

4.3.1 Manual Component Classification . . . . . . . . . . . . 544.3.2 Component Recognition by Static Analysis . . . . . . . 56

4.3.2.1 Basic Principle . . . . . . . . . . . . . . . . . 574.3.2.2 Cohesion Analysis Algorithm . . . . . . . . . 59

4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 Middleware Synthesis 665.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2 COMPASS Application Models . . . . . . . . . . . . . . . . . 69

5.2.1 Explicit Connectors . . . . . . . . . . . . . . . . . . . . 695.2.1.1 Deployment Anomaly . . . . . . . . . . . . . 715.2.1.2 Interaction Styles . . . . . . . . . . . . . . . . 73

5.2.2 Contracts . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.2.1 Emerging Contracts . . . . . . . . . . . . . . 76

5.3 Connector Transformation . . . . . . . . . . . . . . . . . . . . 775.3.1 Connector Templates . . . . . . . . . . . . . . . . . . . 79

5.3.1.1 Sender-Receiver Connector Architecture . . . 805.3.1.2 Client-Server Connector Architecture . . . . . 82

5.3.2 Connector Transformation Algorithm . . . . . . . . . . 845.3.3 Model-to-Code Transformation . . . . . . . . . . . . . 89

5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6 Discussion 926.1 Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.1.1 Middleware Component Recognition . . . . . . . . . . 926.1.1.1 Comparison of Approaches . . . . . . . . . . . 94

6.1.2 Testbed Application . . . . . . . . . . . . . . . . . . . 966.1.3 Middleware Synthesis . . . . . . . . . . . . . . . . . . . 98

6.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.2.1 Component Models . . . . . . . . . . . . . . . . . . . . 102

vii

6.2.2 Static Analysis . . . . . . . . . . . . . . . . . . . . . . 1046.2.3 Model Driven Development . . . . . . . . . . . . . . . 105

6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Appendices 109

A SPEM 109

B Used UML 2 Diagram Types 112

C FlexRay Communication Layers 114

D Manual Annotations for Component Recognition 117D.1 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117D.2 Structure Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 120

List of Figures 121

List of Algorithms 123

List of Tables 124

Bibliography 125

Publications 135

Curriculum Vitae 137

viii

Abbreviations

AST . . . . . . . . . . . . . Abstract Syntax TreeAUTOSAR . . . . . . Automotive Open System ArchitectureBSW . . . . . . . . . . . . Basic SoftwareCBSE . . . . . . . . . . . . Component Based Software EngineeringCC . . . . . . . . . . . . . . Communication ControllerCIM . . . . . . . . . . . . . Computation Independent ModelCOMPASS . . . . . . . Component Based Automotive System SoftwareECU . . . . . . . . . . . . . Electronic Control UnitIPC . . . . . . . . . . . . . . Intra Process ConnectorISR . . . . . . . . . . . . . . Interrupt Service RoutineMCU . . . . . . . . . . . . Micro Controller UnitMDA . . . . . . . . . . . . Model Driven ArchitectureMOF . . . . . . . . . . . . Meta Object FacilityMWBB . . . . . . . . . . Middleware Building BlockOEM . . . . . . . . . . . . Original Equipment ManufacturerOMG . . . . . . . . . . . . Object Management GroupPDU . . . . . . . . . . . . . Protocol Data UnitPIM . . . . . . . . . . . . . Platform Independent ModelPSM . . . . . . . . . . . . . Platform Specific ModelQoS . . . . . . . . . . . . . Quality-of-ServiceQVT . . . . . . . . . . . . Query/View/TransformationRAM . . . . . . . . . . . . Random Access MemoryROM . . . . . . . . . . . . Read-Only MemoryRTE . . . . . . . . . . . . . Run-Time EnvironmentSPEM . . . . . . . . . . . Software Process Engineering MetamodelUML . . . . . . . . . . . . Unified Modeling LanguageVFB . . . . . . . . . . . . . Virtual Function BusXML . . . . . . . . . . . . Extensible Markup LanguageXNC . . . . . . . . . . . . . Extra Node ConnectorXPC . . . . . . . . . . . . . Extra Process Connector

ix

Chapter 1

Introduction

1.1 MotivationDriven by market demands, the application of automotive embedded systemsexperienced a significant upturn over the last few years. A wide variety ofnew fields of application introduced new market opportunities, but also newchallenges to the systems developers. Functionality like steer/break-by-wire,ambient-intelligence or multimedia functionality is exemplary for those newlyarising services, modern vehicles provide. State-of-the-art vehicles containmore than 70 Electronic Control Units (ECUs), typically connected by upto 10 diverse bus systems [Han05]. Todays automotive applications areno longer simple programs executed on one single ECU. In fact, they areheterogeneous software systems in distributed and often safety and missioncritical environments.

By considering the large number of automobiles manufactured every yearin2007 a total of 73, 2 million vehicles [OIC08] have been produced worldwideand the rather long life-cycles of more than 10 years, it becomes obviousthat software for automotive electronic systems has become a key factor notonly in cost1 and quality, but also in time-to-market of current vehicles.As pointed out by Pretschner et al. [PBKS07], the characteristics of theautomotive domain lead to a wide spectrum of research challenges like interalia:

System models and techniques that enable semantics-preserving trans-formation and modification of models and code

1Overall costs contain not only expenditures for development and manufacturing, butalso costs for maintenance, which are highly affected by the vehicles large number andlong life-cycle.

1

1.1. MOTIVATION

Design methodologies at different levels of abstraction that addressthe heterogeneity of the systems involved as well as the compatibilityproblem

Design and coding practices that lead to reusable code and thus to areduction in complexity and costs

Communication middleware for highly distributed heterogeneous sys-tems

Therefore, it was self-evident that major automotive manufacturers strovefor a standardization not only of software modules deployed within theirvehicles, but also for an appropriate software engineering process. In 2002,automotive manufacturers, suppliers, and tool developers jointly founded theAutomotive Open System Architecture (AUTOSAR) consortium [HSF+04] tospecify those required standards.

The main aims of AUTOSAR are:

Increase the quality of automotive software, its maintainability, and itsscalability

Optimize costs and time to market

To achieve these aims, the well established paradigm of Component BasedSoftware Engineering (CBSE) has been adopted for the automotive domain:Applications are assembled across product lines by connecting prefabricatedtrusted building blocks, so called commercial-off-the-shelf components, whichinteract by their connected interfaces at run-time.

In fact, interaction implies inter-component communication that stronglydepends on the physical system structure and the components deploymentscenario. In distributed heterogeneous systems the process of interaction canbecome rather complicated and difficult to handle. It is good practice to keepthe complex and error-prone interaction logic separated, if possible hidden,from the application components. Therefore, component based architecturestypically utilize communication middleware, to cope with the process of dis-tributed interaction in a transparent way. Application components interactdirectly (at least seemingly), irrespective of their deployment scenario, byutilizing transparent communication middleware. Hence, application com-ponents do not have to provide any implementation for means of distributedinteraction. This fact keeps them focused on their actual purpose, thereby

2

1.1. MOTIVATION

staying small in size and less error prone. However, generic middleware, likee.g. middleware for the CORBA Component Model [OMG06], has to pro-vide implementations for all types of interaction that could occur within anyexerting component architecture. Thus, this kind of middleware typicallytends to be heavy-weight and often monolithic software.

Due to the large number of manufactured automotive electronic systems,the price per unit has to be kept as low as possible. As a consequence, au-tomotive embedded systems are inherently resources constrained and thusdo not meet the resource requirements of heavy-weight generic middleware.However, CBSE has been well accepted within the automotive domain andhence, demand for light-weight resource saving component middleware arose.By adopting CBSE for the automotive domain, the AUTOSAR standard ex-tensively addresses the issue of customizable standardized component mid-dleware.

AUTOSAR provides a precise specification for a standardized componentand communication middleware. Its logic abstraction is called Virtual Func-tion Bus (VFB) and its functionality is accessible only via the so calledRun-Time Environment (RTE ). All application components interact in alocation transparent way only through the RTE. In addition, the RTE pro-vides all infrastructural services implemented within the underlying BasicSoftware (BSW ) module. The Basic Softwarethe implementation of theAUTOSAR middleware and the operating systemis specified as layeredsoftware that can be trimmed with respect to application requirements inorder to save valuable system resources. Trimming is done by specifyingvarious compile-time switches2 to exclude middleware layers with unusedfunctionality. Although this proposed approach targets at economizing sys-tem resources, it turns out to be suboptimal: Manual management of oftenundocumented, proprietary, and vendor specific compile-time switches is ex-tremely error-prone. Minor changes at application level can lead to majorchanges in middleware functionality, requiring detailed knowledge of mid-dleware internals from application developers and system integrators. Inaddition, only coarse-grained middleware customization can be achieved dueto the coarse-grained modularization of the Basic Software.

The research presented within this thesis aims at an improvement ofAUTOSARs middleware in terms of reusability, maintainability and poten-tial for application specific optimizations with respect to system immanent

2These switches are, for example, preprocessor defines for conditional compilation inC source code.

3

1.2. APPROACH

resource constraints. Following the same advisement that has been taken intoconsideration by the AUTOSAR consortium for automotive applications, therequired improvements can be achieved by applying the component paradigmto AUTOSARs middleware itself. However, this idea leads to two major re-search questions, covered within this thesis:

1. Is it possible to apply the component paradigm not only at theapplication level but also to the AUTOSAR component mid-dleware, especially to the communication subsystem, itself?All benefits of CBSE would become available not only at applicationlevel but also within the middleware, including better quality, reusabil-ity and maintainability, and higher cost efficiency.

2. If question one can be answered with yes, the second question unfolds:Can component based, application specific, and hence custom-tailored AUTOSAR middleware be automatically synthesizedfrom application models and prefabricated middleware com-ponents? A middleware implementation that is optimal in terms of re-source usage for a specific network node provides only services requiredby application components deployed on this particular node. If com-ponent based middleware that is optimal in the above mentioned sensecould automatically be generated, overall software quality would in-crease whereas costs for development and maintenance would decrease.In accordance to the component paradigm, middleware componentscould be provided by third parties (e.g., communication middlewarecomponents by bus system manufacturers), thus relaxing the applica-tion developers know-how requirements.

1.2 ApproachAs described above, this thesis aims at an improvement of AUTOSAR mid-dleware by applying the component paradigm at the middleware itself. Forthat purpose, several aspects of automotive software engineering are takeninto account:

1. AUTOSAR: The standards component model and the prescribedsoftware engineering methodology are analyzed, to understand not onlyall provided mechanisms of component interaction and communication,but also the related engineering process.

4

1.3. CONTRIBUTION

2. Model Driven Development: Models provide different views of aspecific application. With respect to CBSE and AUTOSAR, model ar-tifacts that contain information regarding communication middlewarefunctionality are identified within AUTOSAR compliant applicationmodels.

3. Middleware Architecture: To design component based communica-tion middleware for AUTOSAR, it is mandatory to analyze the stan-dardized layered AUTOSAR Basic Software and the AUTOSAR Run-Time Environment . A set of basic middleware components as well as ageneral component architecture representing the full AUTOSAR mid-dleware functionality is identified. In addition light-weight variants ofthe identified component classes are specified for improved middlewareoptimization.

4. Software Synthesis: To automatically synthesize AUTOSAR com-pliant communication middleware from application models and prefab-ricated building blocks, a model driven process is defined. This pro-cess on the one hand extracts information from application models andsystem descriptions, and on the other hand automatically assemblesprefabricated middleware components to form an applications custom-tailored middleware. To support model level validation of functionaland non-functional requirements, as well as model checking approachesin general, the defined process conserves annotated properties and re-quirements over its different phases.

1.3 ContributionThis thesis contributes by introducing component based communication mid-dleware into the AUTOSAR standard and by integrating the three domainsof Component Based Software Engineering, Model Driven Development andAUTOSAR into one consistent methodology that helps to gain cost-effective,high-quality software for automotive distributed embedded systems. In de-tail, the contribution is twofold:

1. The component paradigm is applied to AUTOSARs originallylayered communication middleware. Thereunto, the AUTOSARcommunication middleware layers are horizontally sliced into blocks ofrelated functionality. By rejoining tightly coupled blocks, irrespectiveof their originating layer, self-contained building blocksthe middle-ware componentsare created. This process is on the one hand ex-

5

1.3. CONTRIBUTION

ecuted by a static analysis, the so called Cohesion Analysis [1]3, andon the other hand manually by domain-experts in order to get a re-liable reference design for evaluation of the calculated results. Thetotal of all component class interfaces for the identified componentbased middleware design resembles the full functionality and the fullinterface of the conventional layered middleware. However, to reducesize and resource usage of the communication middleware, the com-ponent based middleware design allows the substitution of full-fledgedheavy-weight components by light-weight variants, providing only nec-essary, and hence reduced, functionality. In case a components func-tionality is not required by the application or other middleware com-ponents, this component may even be completely omitted from themiddleware binaries [2, 3]. Supplementary, a component modeltheComponent Based Automotive System Software (COMPASS ) compo-nent model [COM07]for the AUTOSAR communication middlewareis specified, to prescribe how middleware components have to be used,how they may be composed, and how they interact [4]. Based on theCOMPASS component model, reusable architectural middleware pat-terns are specified [5]. These patterns describe functionality of client-server and of sender-receiver communication, which are the two com-munication styles implemented by AUTOSAR within the AUTOSARRun-Time Environment .

2. A model driven component based development process for au-tomatic middleware synthesis is specified. This process is closelyrelated to the Model Driven Architecture (MDA) [OMG03a], but alsoadheres to the AUTOSAR methodology [AUT08b]. The core of thespecified process is a model transformation, called Connector Transfor-mation [6]. It automatically transforms platform independent models(PIMs), describing the applications component architecture, into plat-form specific models (PSMs), containing application components andcomponent equivalent middleware structures. The Connector Transfor-mation mainly transforms PIMs into PSMs by injecting platform andcommunication specific middleware component architectures4 in placeof explicit connector artifacts, contained within the PIMs. The gener-ated middleware structures depend on the set of prefabricated middle-

3The authors publications related to this thesis are referenced with plain numbers. Forthe remainder of this thesis these publications results are used without being explicitlyreferenced.

4The term component architecture denotes a piece of software that is realized by awell-defined set of composed components and their connectors.

6

1.4. THESIS STRUCTURE

ware components, architectural middleware patterns, and the applica-tions deployment specification [7, 8]. As a result, only utilized commu-nication functionality of the AUTOSAR communication middleware iscontained within the middleware binaries. The PSMs moreover reflectthe systems physical structure, so one PSM is created for each systemnode. Hence, this synthesized communication middleware is applica-tion and node specific, and thus exhibits a smaller memory footprintthan conventional AUTOSAR communication middleware. In addition,functional and non-functional contracts (by means of model level an-notations) of middleware components are preserved during transforma-tion, and thus are contained within the PSMs. Therefore, annotationsof application components and of assembled middleware componentsprovide a sound foundation for model checking and system validationof automotive software systems [9].

1.4 Thesis StructureTo answer the research questions issued in Section 1.2, the thesis is structuredas follows:

Chapter 2, Technological Baseline and State-of-the-Art, overviewsComponent Based Software Engineering (Section 2.1) and ModelDriven Development (Section 2.2), and describes how these domainsare related to each other. It provides basics on the key elements ofCBSE and MDD, and summarizes all necessary vocabulary and nota-tions, used within the remaining chapters.

Chapter 3, Automotive Open System Architecture, provides an outlineof the AUTOSAR hardware and software architecture. It is focused onthe standards sub-domains that are of specific relevance for the subjectof this thesis: the component model, and all system parts related tocommunication middleware.

Chapter 4, COMPASS Middleware, comprises the first major contri-bution of this thesis: On the one hand it defines the COMPASS com-ponent model that is applied to the AUTOSAR communication mid-dleware, in order to solve the research challenges covered within thisthesis (Section 4.2). On the other hand, the chapter identifies mid-dleware component classes by decomposing conventional AUTOSARmiddleware via the static Cohesion Analysis (Section 4.3).

7

1.4. THESIS STRUCTURE

Chapter 5, Middleware Synthesis, comprises the second contributionof this thesis. It describes how to utilize augmented AUTOSAR ap-plication models to synthesize application specific component basedcommunication middleware. In Section 5.2 the COMPASS applicationmodel, especially the model artifact of explicit connectors, is intro-duced, while in Section 5.3 the Connector Transformation is described,which performs the middleware synthesis.

In Chapter 6, Discussion, the proposed methodology is applied to anautomotive application at proof-of-concept level. Gathered results arediscussed for the Cohesion Analysis and for the Connector Transfor-mation (Section 6.1). Finally, related work that has not explicitly beenmentioned within the previous chapters is discussed (Section 6.2), anda brief outlook on future work is given (Section 6.3).

8

Chapter 2

Technological Baseline andState-of-the-Art

This chapter provides an overview of state-of-the-art technology, represent-ing the baseline for the contribution of this thesis. It provides fundamentalconcepts of component based software engineering and model driven devel-opment. As a result, a common terminology is defined for the remainder ofthis thesis.

2.1 Component Based Software EngineeringOne substantial challenge in todays software engineering is to master the de-velopment of cost-effective and reliable software in the face of increasing sizeand complexity. Various approaches have been proposed over the last years,some of them made it into industry. Most of them have identified softwarereuse as a main candidate for better and cheaper software development.

Component Based Software Engineering (CBSE) is one widely accepted con-cept in developing cost-effective and sound software, that builds on reuse[NT95], and therefore aims at increasing software quality and productivity.In CBSE applications are built by assembling small, well-defined, and trustedbuilding blocks, so called components. Related components are connected bytheir interfaces, to form a new software system with combined functionality.As components provide means of exchangeability and reusability, implicitcontext dependencies are strictly prohibited.

Components are subject to third party composition; therefore componentsof different vendors have to interact seamlessly. This can only be assured bydefining a frameworka set of rules, utilities, programming abstractions, and

9

2.1. COMPONENT BASED SOFTWARE ENGINEERING

an infrastructurecalled component model that has to be strictly obeyedand utilized by all components. A component model provides the semanticframework of what components are, and how they are constructed, composed,deployed and used [WS01, LW05]. Thus it provides the foundation for anycomponent based application.

A component model contains at least the following specifications:

1. Component Definition: The component model defines, what com-ponents are. It gives a precise description of properties and constraints,which a building block has to satisfy in order to be a component.

2. Composition Standard: By defining how, where, and when com-ponents may be connected, the component model clearly defines rulesthat are of great relevance for the design process of a component basedapplication.

3. Interaction Standard: At run-time, connected components interactby exchanging data or flow of control. The interaction standard defines,how data is exchanged and what happens to the flow of control withinthe interacting components.

4. Infrastructure Specification: One main issue of CBSE is to provideseparation of concerns. To keep components focused on their appli-cation purpose, any implementation of infrastructural concerns, e.g.communication issues or life-cycle management, is shifted to the com-ponent middleware, which in consequence is often referred to as appli-cation server. The component middleware consequently has to provideall infrastructural services required by the application components, andthus is the vital environment for them. As a result, application com-ponents stay highly specialized to their primary purpose, small in size,and less error-prone.

Component models are usually categorized into flat or hierarchical models,or by means of component composition [LW05]. Both, the AUTOSAR com-ponent model [AUT08c, AUT08g] and the COMPASS component model (seeSection 4.2), are hierarchical component models.

2.1.1 Components

In CBSE, the most common entity is called component. Unfortunately,literature shows many, very often contradictory, definitions of that term

10


[BDH+98, Bro98]. So the first thing to do when dealing with CBSE, isto clarify the semantic meaning of this appellation, and to provide a clearvocabulary for the domain as basis for the remainder of this thesis.

2.1.1.1 Component Definition

Within the following paragraphs, some of the most accepted component def-initions are summarized to obtain a general one, which serves as foundationfor all more specialized refinements, discussed and developed within this the-sis.

Szyperski [Szy99] defines a component to be a composable unit that interactsby specified interfaces only:

A software component is a unit of composition with contrac-tually specified interfaces and explicit context dependencies only.A software component can be deployed independently and is sub-ject to composition by third parties.

The definition of Heineman and Council [CH01] differs from most definitionsby postulating that a component has to adhere to a component model:

A [component is a] software element that conforms to a com-ponent model and can be independently deployed and composedwithout modification according to a composition standard.

To obtain reliable behavior from composed software architectures, Mayer[Mey03] introduces the concept of trust in CBSE and therefore defines acomponent to be a trusted element of reuse:

A component is a software element (modular unit) satisfyingthe following conditions:

1. It can be used by other software elements, its clients.

2. It possesses an official usage description, which is sufficientfor a client author to use it.

3. It is not tied to any fixed set of clients.

[. . . ]A Trusted Component is a reusable software element possessingspecified and guaranteed property qualities.

11


For the CORBA Component Model [OMG06], the Object Management Group(OMG) specifies a component in a more abstract, syntactic way, related tothe design phase of the development process:

A [component is a] specific, named collection of features thatcan be described by an IDL [Interface Definition Language] com-ponent definition or a corresponding structure in an InterfaceRepository.

Finally, for their Unified Modeling Language (UML)1, they define a com-ponent as an executable element within a system, which has an externalspecification in the shape of one or more provided and required interfaces,and an internal implementation, consisting of one or more classifiers thatrealize the components behavior:

A component represents a modular part of a system thatencapsulates its contents and whose manifestation is replaceablewithin its environment.

A component defines its behavior in terms of provided andrequired interfaces. As such, a component serves as a type whoseconformance is defined by these provided and required interfaces(encompassing both their static as well as dynamic semantics).

By taking all these considerations into account, a general component defini-tion that is used for the remainder of this thesis can be formulated:

Components are trusted architectural elements of execution that interactonly by their well-defined interfaces, according to contractual guarantees,and strictly contain no other external dependencies. Components conformto a component model, so they adhere to a composition and interactionstandard, and can be independently deployed and composed without mod-ification. Therefore, components are well suited for reuse and third-partycomposition.

1Within this thesis UML 2.1 [OMG07b] is used to describe components, component ar-chitectures, deployment specifications, and architectural templates. It provides a useful setof predefined classifiers that can easily be extended to meet domain specific requirementsof architectural modeling [RMRR98].

12


A set of well composed components is referred to as component architecture,while the term component model denotes the framework and standards, acomponent has to adhere to.

Both, the AUTOSAR component model, described in Section 3.4, as well asthe COMPASS component model, described in Section 4.2, adhere to thisdefinition.

2.1.1.2 Interfaces

The behavior of a component is completely determined by its implementa-tion and the specification of its interfaces. Following the given componentdefinition, interfaces describe a components points of interaction.

An interface is a set of operationsthe servicesand accessible memory lo-cations, also referred to as data elements. Operations are uniquely specifiedby their signature, a tuple consisting of the operations name and its orderedparameter list. Data elements are specified by a tuple containing the ele-ments name and data type. Due to the descriptive nature of an interface, itdoes neither offer any implementation of its operations, nor does it provideany data element. An interface rather refers to a component implementationthat provides all of that [CHJK02]. Depending on the interfaces role in acomponent description, two kinds of them have to be distinguished:

1. Provided-Interfaces expose services implemented by and data ele-ments contained within a component, for proper use by other compo-nents.

2. Required-Interfaces represent a components need for external ser-vices or data elements, provided by other components via theirprovided-interfaces. Within a valid component architecture, allrequired-interfaces have to be connected to related provided-interfaces,while dangling provided-interfaces may occur.

Both kinds of interfaces are representable in UML 2, and can be expressedin various ways. Figure 2.1 depicts one sample component, named A, thatprovides services via one provided-interface, called IAServices and demandsexternal services via one required-interface, called IBServices.

Figure 2.1 depicts component A and its interfaces, using the Ball-and-Socketnotation of UML 2 : Provided-interfaces are denoted as ball, while required-interfaces are denoted as socket. Although this notation is more intuitive

13


IAServices

IBServicesA

component

Figure 2.1: UML 2 notation of a component

to read, less information, especially on the interfaces properties, is visibleand has to be described within extra artifacts, e.g. interface descriptions orinterface contracts.

2.1.1.3 Ports

Interfaces may be exposed by a component itself, as depicted in Figure 2.1,or by a components port, as depicted in Figure 2.2. A port is a dedicatedpoint of interaction; it is used to group related interfaces. Ports in generalare typed by all interfaces comprised within. If a port comprises more thanone interface, it is referred to as a complex port. As depicted in Figure 2.2ports in UML are denoted as rectangles, placed on the component artifactsborder.

Ports are typically used for

Interaction Modeling: When describing and verifying run-time be-havior of composite structures, the sequence of interface invocationsplays an important role. As ports are used to group interfaces, it isfeasible to bind interface states [Sel99]. Interface states are the currentphase of an invocation sequence of a specific port.

Logic Grouping of Interfaces: Grouping semantically related inter-faces increases a models comprehensibility. All interfaces exposed byone port are of concern for the samethe portspurpose of interac-tion.

Model Abstraction: As ports are typed by their interfaces, they canbe used as placeholder for all the interfaces they comprise. In this way,models with a higher level of abstraction like the architectural patternsdefined within Section 5.3.1 can be created.

14


2.1.2 Connectors

Composing components connotes joining related provided- and required-interfaces. The junction between component interfaces or ports is called con-nector. At run-time, connected components interact through their associatedinterfaces via joining connectors only. While connectors in local componentarchitectures typically represent simple issues of control- and data-flow, theybecome hot-spots of interaction within distributed, heterogeneous systems.

UML provides various ways to express component composition with connec-tors. Figure 2.2 shows the three most common UML notations for compo-nent connectors by a simple example: Component A provides services by aprovided-interface of type IA, while component B requires at least one ser-vice from that interface, thus it comprises IA as required-interface. All threenotations, depicted in Figure 2.2a, 2.2b, and 2.2c, show the involved com-ponents with their interfaces and ports, but use a different syntax2 for thesame connector. However, the port connector, depicted in 2.2c, semanticallydiffers from the others. A port connector provides a higher-level of abstrac-tion of a set of connected interfaces. It is typically used to simply expressthat two components are connected for a specific purpose, whereas detailedinformation on interfaces is not of interest.

1. Usage Relation Notation: A component that requires external ser-vices by comprising a required-interface, makes use of that services,provided by another component via a provided-interface. Figure 2.2adepicts this fact by connecting the associated required- and providedinterfaces with a usage-relation, represented as dotted arrow. This no-tation lays stress on usage and, as e.g. in AUTOSAR, on the existenceof a communication channel, also symbolized by the dotted line of thearrow.

2. Ball-And-Socket Notation: A short-cut to the usage-relation nota-tion is shown in Figure 2.2b. The required-interface and its associatedprovided-interface is directly joined into one symbol. Due to its simplic-ity, this notation is widely used to represent component dependencies.Within this thesis, this notation is mainly used for local connectionswithin middleware architectures, as no external communication chan-nel is used within that connections.

3. Port Notation: Ports, as described in Section 2.1.1.3, may represent acomponents points of interaction at a higher level of abstraction. They

2UML provides a graphical notation for describing software models. Model elementsare represented by distinct shapesthe syntax for the elements.

15


component B

component A use

Provided-Interface Required-Interface

Connector

Port Port

IA IA

(a) Usage relation

component B

component A

Connector

IA

(b) Ball-And-Socket connector

component B

component A

Connector

PT PT

Typed Port

(c) Port connector

Figure 2.2: UML connector notations

16


comprise a well defined set of interfaces that gives them a unique type.As two components are often connected by multiple related interfaces,it is often expedient to omit the interface artifacts and simply wire thematching ports of associated components. A well known example isthat of a call-back mechanism, which requires at least one provided-and one required-interface for each participant. The wire is symbol-ized by a simple line, connecting the corresponding ports, as shown inFigure 2.2c.

2.1.3 Component Middleware

Due to the concept of separation of concerns within component basedsoftwarecomponents have to deal with their business purpose onlyallinfrastructural requirements are provided by the component models middle-ware. Therefore, the middleware is the vital environment for each applicationcomponent. It provides means of life-cycle management and component ex-ecution, communication and interaction services, and many other features,required by the application components to fulfill their task.

In typical component models, like the CORBA Component Model (CCM)and Microsofts Component Object Model (COM), application componentsare embedded within a component container, which provides an abstractionof the component models middleware to the application components. Al-though related components are seemingly connected to each other via theirconnectors, in reality they are connected to the middleware container thatprovides a virtual function bus (VFB) in a transparent way. Figure 2.3shows two components named A and B, where B requires services from A.Sub-figure 2.3a shows the components point of view: they seem to be di-rectly connected over the VFB. Sub-figure 2.3b shows the physical view: thecomponents are connected to the component container that manages thecomponent interaction.

Within existing (but also proposed) component middleware implementations,a wide set of architectural paradigms is used. This fact results from thevariety of middleware purposes, but also from the great amount of systemproperties. Many of these properties are domain- and/or application-specific,and have to be taken into consideration, when designing middleware [KG99,ICG07].

Two common architectural styles are of relevance for this thesis: the layeredand the component based design.

17


component B

component A

use

IA IA

Virtual Function Bus

(a) Logical view

component B

component A

use

IA IA

Virtual Function Bus

component Component Middleware

use

(b) Physical view

Figure 2.3: Virtual function bus (VFB)

18


1. Layered Middleware: Layered middleware, like proposed in[AUT08a, MSM06, Sch02], is constructed as a horizontally layered soft-ware stack. Lower layers are concealed by upper ones. Therefore, eachlayer interacts with adjacent ones only. Application components resideon top of this software stack, and hence are connected to the stackstop-layer.

Even though this type of architecture is modular in terms of layers,intra-layer modularity is hardly possible. The middleware itself istypically deployed as monolithic block, thus customization or middle-ware adaption usually requires a full rebuild. Another disadvantage ofstrictly layered middleware is that services from bottom layers can notbe directly accessed from the application components, and thus haveto be delegated through all intermediate layers. These forced servicedelegations cause unnecessary run-time overhead, which offers space foroptimization especially in resource constrained domains like embeddedsystems. However, due to the well understood mechanisms in layeredsoftware, and due to easy-to-understand designs, this middleware typestill plays an important role in CBSE.

The conventional AUTOSAR component middleware is specified in alayered style as described in Section 3.3. Its top-most layer is calledRun-Time Environment .

2. Component Based Middleware: Component based middleware,sometimes also referred to as modular middleware, like describedin [PCCB00, LQS05], is designed in accordance to the componentparadigm. Middleware functionality is divided into functional blocksthat contain closely related, often tightly coupled functionality only.The implementation of each blocks functionality represents one spe-cific middleware component. Middleware components may seamlesslyinteract with each other, but also with application components. How-ever, a container component is often used to provide functionality ofinterface adaption between generic middleware components and user-defined application components.

Due to the component based design, middleware of this type can be re-configured, reused and adapted to altering requirements without a fullrebuild. Service delegations across multiple layers, which often arise instrictly layered software architectures, are omitted, as related middle-ware components may be arbitrarily connected without restrictions interms of layers.

In addition, component based middleware can be assembled automati-

19

2.2. MODEL DRIVEN DEVELOPMENT

cally according to application demands, and thus can provide custom-tailored, resource efficient middleware.

2.2 Model Driven DevelopmentWhen building component based applications, software is constructed by as-sembling prefabricated components. These component architectures reflectthe applications functional decomposition, and thus provide a high level viewof the developed software. Components are often also hierarchically com-posed architectures themselves, hiding their internals behind published inter-faces. Hence, a component architectures level of abstraction can successivelybe lowered by refining the views granularity, thereby revealing internal struc-tures of assembled building blocks. Each level of abstraction provides specificarchitectural details of the represented application. This fact can be capital-ized on within a development process by introducing highly specialized views,corresponding to expert knowledge of the views specific domain. In addi-tion, standardized architectures and building blocks enable production-linelike development cycles. Consequently, when developing component basedsoftware, a proper engineering methodology is mandatory to reach CBSEsgoals of better and cheaper software. A well suited development process hasto be formalized and wherever possible unified. It has to cope with variouslevels of abstraction and their correlation, and also has to provide supportfor software- and architectural reuse [Pas02].

One approach that can perfectly be adopted for CBSE is Model Driven De-velopment (MDD). In MDD, system descriptions, so called models, are usedto obtain a coherent total representation of the softwares characteristics.Models are the focal points of a model driven development process and aresubject to specification, refinement and manipulation. By applying modeltransformations, models can be transformed into new typically more specificones. Transformations can also be used to extract model inherent informa-tion from source models. To subsume, a MDD process is characterized bythe activity of modeling a software system and by transforming the specifiedmodels, to finally gain the required product.

A common definition of the term model is provided in [KWB03]:

A model is a description of (part of) a system written in awell-defined language.

20


A well-defined language is a language with well-defined form(syntax) and meaning (semantics), which is suitable for auto-mated interpretation by a computer.

The first definition assesses a model to be a representation, most times anabstraction, of a system. It is typically simplified and focused on a specificsubset of the systems features. The second definition more precisely stateshow a model has to be specified. The assumption, that a model has to beautomatically interpretable by a computer, seems rather rigorous at the firstlook and is not demanded by most model driven approaches. Nevertheless, itis good practice, since software development, and thus MDD, is a computeraided process that relies on automation to exploit its full potential.

One of the precursors of MDD is the OMG, who defined the Model DrivenArchitecture (MDA) framework [OMG03a], which has become rather pop-ular within software industry. MDA specifies concepts and languages3, andthe relation between them, but does not define a specific development pro-cess. In fact, any favored process can be adopted and adapted, if it meetsthe requirements of MDA: models and transformations at various levels ofabstraction have to play a central role.

Within the following sections we revisit the most important aspects of MDDand MDA that are used within this thesis.

2.2.1 Viewpoints and Models

To express the level of abstraction, MDA utilizes so called views [IEE00]:

A viewpoint model or view of a system is a representation ofthat system from the perspective of a chosen viewpoint.

To render this definition more precisely, the term viewpoint is also clarified[OMG03a]:

A viewpoint on a system is a technique for abstraction usinga selected set of architectural concepts and structuring rules, inorder to focus on particular concerns within that system. Hereabstraction is used to mean the process of suppressing selecteddetail to establish a simplified model.

3MDA requires models to be expressed in a Meta Object Facility (MOF ) based[OMG03b] language.

21


Following the given definitions, models are descriptionsalso referred to asviewsof a system that are typically focused on specific system aspects.The specific aspect covered within a model, strictly depends on the modelsviewpoint.

OMGs MDA proposes three distinct viewpoints on a system, which are ofgreat importance in model driven development:

1. Computation Independent Viewpoint: By focusing on the sys-tems environment and its requirements, the computation independentviewpoint hides details of the systems structure and processing. Thisviewpoints main purpose is to separate the fundamental logic of a sys-tem, e.g. process- or business-models, from its technical specification.

2. Platform Independent Viewpoint: The platform independentviewpoint aims at the operation of a system while disregarding plat-form specific details. A platform is considered to be a set of subsys-tems and technologies, which provide a coherent set of functionalitythrough interfaces and specific usage patterns. Platform independentviews expose aspects of a system that are shared between distinct tar-get platforms, and are typically specified in general-purpose modelinglanguages such as UML.

3. Platform Specific Viewpoint: The platform specific viewpoint isfocused on the use of a specific platform. It exposes aspects of a systemthat can not be shared between different target platforms.

These distinct viewpoints help to gain a clear separation of concerns withina model driven development process, and also lead to a better comprehensi-bility of the overall system.

In accordance to the viewpoints aspects, MDA proposes four types of mod-els that are all used within the following chapters. Thus, their purpose issummarized here:

1. Computation Independent Model (CIM): A description of a sys-tem from the computation independent viewpoint is called computationindependent model. A CIM describes the situation and the context inwhich the system will be used. Therefore, it includes no details of asystems structure. However, a CIM typically not only serves as aid tounderstand a problem, but also as source of system specific vocabularyfor use in other models. CIMs are often referred to as domain mod-els, and play an important role in bridging the gap between domain

22


experts on the one hand, and experts in design and construction ofsystem artifacts, on the other hand.

2. Platform Independent Model (PIM): A view of a system from theplatform independent viewpoint is called platform independent model.A PIM exposes aspects of a system that primarily deal with logicaland structural concerns, independent of any implementation technol-ogy. Within this thesis PIMs are used to specify component architec-tures at application level. Matters of distribution or heterogeneity arenot of concern within this models.

3. Platform Specific Model (PSM): A platform specific model is aview of a system from the platform specific viewpoint. A PSM containsaspects of a system that are directly related to a specific platform, theassociated implementation technology. It augments relevant aspectsof a PIM with details on how the system uses a particular type ofplatform.

4. Platform Model: A platform model specifies technical concepts, sys-tem parts, and provided as much as required services of a specific plat-form. It also provides concepts on how the platform has to be usedby an application, and how this usage has to be described within aPSM. Platform models are a vital source of information for the modeltransformation, specified within this thesis.

By utilizing distinct viewpoints, a system is described by multiple models ofvarious types. As these models represent different abstractions of one system,they are related to each other. Well-defined relations between models of thesame system may be used to (sometimes even automatically) translate modelsof one type into another. To aid this process of translation, models may beannotated with marks. Within this thesis, marks are attached to elementsof PIMs (connectors in component diagrams), to guide proper translationof PIMs to PSMs. In MDD, the process of translation is referred to astransformation.

2.2.2 Transformations

The real value of MDD, especially of MDA, results from its ability to trans-form models of distinct viewpoints into each other. Platform independentmodels can be transformed to platform specific models. Platform specificmodels can be translated to code. Traditionally, most of this work has beendone by hand. To automate this process, model transformations have been

23


ModelMA

Meta-ModelMMA

ModelMB

Meta-ModelMMB

Meta-ModelMMT

MOF

TransformationTAB

Transformation Tool

M2

M3

M1

input output

conforms to conforms toconforms to

conforms toconforms to

conforms to

based on based on

Figure 2.4: Model transformation

subject to research and development over the last years. Automated trans-formations impose big potential in reducing costs, and in increasing softwarequality in MDD, as they reduce the amount of error prone human interven-tion.

Transformations are typically specified as set of rules, denoted in atransformation language like OMGs Query/View/Transformation (QVT )[OMG07a] or the Atlas Transformation Language [ATL06, JK06]. Theserules are applied to a source model by a transformation tool to generate atarget model.

Figure 2.4 depicts an MDA compliant model hierarchy of the transformationstep: A transformation TAB, executed by a transformation tool, translatesthe source model MA into a target model MB. The transformation itself is amodel4, therefore MA, MB, and TAB are elements of model level M1. WhileMA and MB conform to their meta-models MMA and MMB respectively,TAB not only conforms to its meta-model MMT , but is also based on the

4Source code is also considered to be a model of an executable program.

24


meta-models of the source and the target model, as it has to cope with bothof them. All three meta-models are elements of model level M2 and finallyconform to the Meta-Object Facility at model level M3.

Depending on the meta-model, to which the source and target models complyto, two types of transformation can be distinguished:

1. Endogenous Transformation: Any transformation, translating asource model into a target model that complies to the source modelsmeta-model, is called endogenous transformation. For an endogenoustransformation, MA and MB within Figure 2.4 both have to comply tothe same meta-model (MMA = MMB). Within this thesis, endoge-nous transformations are used to translate UML models (PIMs) intoother UML models (PSMs).

2. Exogenous Transformation: If a transformation translates a sourcemodel into a target model that complies to a different meta-model,the transformation is called exogenous transformation. If MA and MBin Figure 2.4 comply to distinct meta-models (MMA 6= MMB), thetransformation is an exogenous one. This type of transformation is usedwithin this thesis primarily when generating glue code, configurationfiles, and build control files.

2.2.3 MDA Development Phases

With respect to the previously defined views, a typical model driven develop-ment cycle for a software application as outlined by MDA contains followingphases:

1. Specification of CIMs: System requirements and domain specificenabling technologies are described within CIMs that primarily de-scribe the applications context, and define a common vocabulary forall forthcoming models used within the applications development cy-cles. Requirements of the computation independent models later onmay be mapped to platform independent but also to platform specificmodels and vice versa.

2. Specification of PIMs: Platform independent models are developedin accordance to the applications domain models (CIMs). They mainlyprovide information on the applications logical structure, but also anarchitectural overview of the software system under development.

25


3. Platform Specification: The underlying systems technical concepts,like available interfaces, usage patterns, architectural properties, butalso physical parts, and available resources are specified within platformspecifications.

PIM

PIMmarked

PSM

Additional Information

Additional Information

Pattern Names

Patterns Platform

Sub-Transformation

Sub-Transformation

Transformation

Figure 2.5: Guided transformation

4. Transformation of PIMs to PSMs: The heart of an MDA compli-ant MDD process is the transformation of PIMs to PSMs, or in caseof model-to-code transformations the transformation of PIMs or PSMsinto source code. Figure 2.5 depicts a guided transformation as pro-posed in [OMG03a]: The main transformation is decomposed into twosub-transformations.

(a) The first sub-transformation (the upper one in Figure 2.5) trans-lates a PIM into another PIM, by adding platform specific marksthe platform related pattern namesto the PIM. The so gainedmarked PIM is still platform independent in sense of its originalelements and design, but it contains cluesthe marksthat help

26

2.3. SUMMARY

to associate the elements of the PIM with platform specific coun-terparts or patterns. Both sub-transformations in addition allowthe specification of information like Quality-of-Service (QoS) at-tributes or architectural styles.

(b) The second sub-transformation (the lower one in Figure 2.5 ) fi-nally translates the marked PIM into a PSM, utilizing platformspecific patterns and usage descriptions from the platform model.

5. Transformation of PSMs to Code: A final step within a modeldriven development process is that of code generation. Typically, PSMsare translated into deployable executable code. This transformation ismost times carried out by translating PSMs to source code that in suc-cession is compiled and linked into an executable binary. However, codecan also be generated directly from PIMs by model-to-code transforma-tions, or via model-to-source transformations including the additionalcompiler- and linker-runs.

To improve a development process following this work flow, the process hasto be cyclic for iterative refinement. This so called round trip engineeringrequires transformations to be bijective. Changes within a target model haveto be transformed back to the source model to guarantee model consistency.Otherwise those changes would get lost, when transforming the source modelduring the following iteration of the development cycle.

2.3 SummaryOutlining the state-of-the-art of component based software engineering andmodel driven development, this chapter provided the basic concepts and vo-cabulary that come to use within this thesis. The term component, as muchas terms related to components, like connector and middleware, were dis-cussed; based on these given definitions a component model will be intro-duced in Chapter 4. Additionally, concepts of model driven developmentwere summarized; the model driven middleware synthesis that is describedin Chapter 5 was developed in line with the concepts of OMGs MDA.

The next chapter provides a short introduction to the Automotive Open Sys-tem Architecture (AUTOSAR), which is the target domain of this thesis.The chapters main focus is set to component based software engineeringand model driven development as specified by AUTOSAR, to provide thebackground for the contribution of this thesis.

27

Chapter 3

Automotive Open SystemArchitecture

Based on the technological baseline, provided in Chapter 2, this chaptergives an introduction to the Automotive Open System Architecture. Besidesa general overview, the main focus is set on aspects of AUTOSAR that areof interest for the contributions of this thesis: the software architecture ofAUTOSAR applications, and the architecture of AUTOSAR system software,especially of its communication services and middleware.

3.1 History of AUTOSARDriven by an increasing number of requirements of innovative applications,automotive electronic systems have reached a level of complexity that requiresa technological breakthrough in order to manage them cost-effectively andat high quality. This breakthrough can be achieved with a standardizedengineering process similar to that of production lines that besides are veryfamiliar to the automotive industry since Henry Ford. By building complexsoftware from standardized components, and by using standardized toolswithin a standardized process, better and cheaper automotive software canbe realized.

To develop an open and standardized automotive software architecture andadequate development paradigms for automotive electronic systems, theAUTOSAR consortium was jointly founded by automobile manufacturers,suppliers, and tool developers in 2002 [HSF+04]. Preparatory discussions onthe common challenges and objectives were held by BMW, Bosch, Continen-tal, Daimler Chrysler, Volkswagen, and Siemens VDO in August 2002. A

28

3.2. HARDWARE ARCHITECTURE

joint technical team was set up in November of that year, to establish a tech-nical implementation strategy. The partnership between the AUTOSAR coremembers was formally signed off in July 2003. Ford Motor Company, PeugeotCitron Automobiles S.A., Toyota Motor Corporation and General Motorsjoined the consortium as core partners later on. Today the AUTOSAR con-sortium consists of 9 core partners, more than 50 premium members, morethan 80 associate members, and 7 development members1. The main objec-tives of AUTOSAR are to increase the quality of automotive software, itsmaintainability, and its scalability, to support usage of Commercial-Off-The-Shelf (COTS) components across product lines, and finally to optimize costsand time to market.

The consortium so far created detailed specifications in several releases:In December 2006, AUTOSAR phase I was finalized with the release ofversion 2.1 of the AUTOSAR standard. At the moment, phase II is inprogress, and is scheduled to last until end of 2009, with the finalizationof the AUTOSAR standard, version 4.0. The actual standard under releaseis that of version 3.1, finalized in June 2008. Most of the AUTOSAR specificassumptions within this thesis are based on version 2.1 but also comply toversion 3, the most actual version while writing.

3.2 Hardware ArchitectureThe hardware architecture of automotive systems can be viewed at differentlevels of abstraction.

On the highest level of abstraction, the system level, an automotive systemconsists of a number of networks interconnected via gateways. In generalthese networks correspond to the different functional domains that can befound in todays cars (i.e., chassis domain, power train domain, body do-main).

The networks themselves comprise a number of electronic control units(ECUs), which are interconnected via a communication media. The physicaltopology used for the interconnection is basically arbitrary. However, bus,star, and ring topologies are the most common topologies in todays cars.The network level represents the medium level of abstraction, used for thespecifications of automotive electronic systems.

1Numbers were extracted from the AUTOSAR web site at http://www.autosar.org/last visited on 11.01.2009

29

3.3. SOFTWARE ARCHITECTURE

MCU

Communication Controler

(CC)

I-Ports

O-Ports

Transceiver

HCIEnvironmental

Interface

ECU

NetworkInterface

Figure 3.1: ECU design

On the lowest level of abstraction, the so called ECU level, the major partsof an ECU are of interest, like exemplarily depicted in Figure 3.1. An ECUcomprises one or more micro controller units (MCUs) as well as one or morecommunication controllers (CCs). In most cases, exactly one MCU and oneCC are used to build up an ECU. In order to be able to control physicalprocesses within the car (e.g., control of the engines injection pump) theECUs MCU is connected to actuators via analogue or digital output ports.To obtain environmental information, sensors are connected to the MCUsanalogue or digital input ports. This interface is referred to as the ECUsenvironmental interface. The CC facilitates the physical connectivity of theECU to the respective network. This interface of an ECU is called networkinterface. The CC, as depicted in Figure 3.1, may contain a host controllerinterface (HCI) that provides dual ported memory. This memory is usedto buffer data, which is received by the CC from the network interface forthe MCU, or sent to the network by the MCU via the CC. In addition,an ECU may contain a so called transceiver. This building block is usedto encode and decode logical bits into their physical representation withinnetwork communication, and thus is connected to the MCU as much as tothe CC.

3.3 Software ArchitectureThe AUTOSAR software architecture, as depicted in Figure 3.2, specifiesa rather strict distinction between application software and system soft-

30


ware, also referred to as Basic Software [AUT08a]. The Basic Softwareis organized as layered software architecture, which provides functionalitylike communication protocol stacks for automotive communication protocols(e.g., FlexRay [MHB+01, FHHW03]), the operating system, and diagnosticmodules. The application software is component based, and comprises allapplication specific software items like control loops and sensor/actuator in-teraction. Consequently, the basic/system software provides the basis, onwhich the application software is built upon.

The so-called Run-Time Environment (RTE) [AUT08g] provides the inter-face between application software components and the basic software. It im-plements means of execution, coordination, and interaction patterns, but alsoprovides interface adaptation for application components and the AUTOSARBasic Software. The Run-Time Environment maps application specific com-munication requirements to fundamental communication facilities within theBasic Software. It is generated at compile-time to omit unused functionalitywithin the systems executables, hence providing means of optimization forthe AUTOSAR middleware. However, this type of resource-aware optimiza-tion is performed at a rather high level of the system software. Thus, itoffers coarse-grained optimization facilities only, compared to the approachdiscussed within this thesis.

The term communication middleware as used within this thesis maps to thoseparts of the Run-Time Environment and the Basic Software that are relatedto interaction and communication.

3.3.1 Application Software Architecture

AUTOSAR compliant application software consists of application softwarecomponents that are ECU and location independent, and sensor-actuatorcomponents that depend on specific ECU hardware, and therefore are loca-tion dependent. Whereas instances of application software components caneasily be deployed to arbitrary ECUs, instances of sensor-actuator compo-nents have to be deployed to a specific ECU for reasons of hardware depen-dency. Deploying multiple instances of the same component on one singleECU is supported by the AUTOSAR component model. However, race con-ditions and data conflicts that might occur due to multiple instantiation orreentrancy, have to be solved by the component developer and are not withinthe scope of AUTOSAR middleware.

31


AUTOSAR Runtime Environment (RTE)

Hardware

Services Layer

Microcontroller Abstraction Layer

SystemServices

MemoryServices

COMServices

Com

ple

xD

evic

e D

rive

rs

Bas

ic S

oft

war

eApplication Layer

Software Component

Software Component

Com

ponen

t Bas

ed

Applic

atio

n

Virtu

al F

unct

ion B

us

(VFB

)

I/OServices

ECU Abstraction Layer

Figure 3.2: AUTOSAR software architecture [AUT08a]

Application software components as well as sensor-actuator components areinterconnected via so-called connectors. These connectors represent the com-ponents run-time interaction, like the exchange of signals2 or remote methodinvocations among the connected components. A more detailed descriptionof the AUTOSAR component model is provided in Section 3.4

3.3.2 System Software Architecture

Due to the designated separation of concerns AUTOSAR software compo-nents rely on component middleware as described in Section 2.1.3. However,AUTOSAR middleware does not support dynamic operations like service dis-covery or late binding, as automotive applications are statically typed andbound for safety reasons. Nevertheless, the middleware has to provide a ba-sic platform for the execution of application components. In AUTOSAR,this functionality is provided by a layered architecture of system softwaremodules. Figure 3.2 gives a coarse overview of the major categories of thesemodules.

2In AUTOSAR the term signal denotes any type of variable.

32


1. System Services: The System Services module encompasses all func-tionality that provides standardized (e.g., operating system, timer sup-port, error loggers) and ECU specific (e.g., ECU state management,watchdog management) system services and library functions.

2. Memory Services: TheMemory Services module comprises function-ality that facilitates the standardized access to internal and externalnon-volatile memory for means of persistent data storage.

3. I/O Services: The Input/Output Services module contains function-ality that provides standardized access to sensors, actuators and ECUon-board peripherals (e.g., D/A or A/D converters).

4. Communication Services: Last but not least, the Communica-tion Services module contains functionality that provides standard-ized access to vehicle networks (i.e., the Local Interconnect Network(LIN) [LIN06], the Controller Area Network (CAN) [ISO03a, ISO03b],and FlexRay [MHB+01, FHHW03].

It is important to mention that the AUTOSAR nomenclature clearly distin-guishes between the Communication Services module, included within Fig-ure 3.2, and the Communication Stack, which is depicted in Figure 3.3 for aFlexRay network. The Communication Stack provides a logic view for com-munication functionality provided by the Communication Services module,as much as by lower layers like the ECU Abstraction layer or the Micro-controller Abstraction layer.

Research for this thesis was conducted within the context of automotive sys-tems utilizing the FlexRay time-driven bus system. Therefore, the FlexRaycommunication stack has been analyzed, decomposed, and re-engineered ina component based way, and hence will be described in more detail withinthe following paragraphs. However, the proposed approach can be appliedto other communication subsystems like the CAN stack in the same way.

The internal structure of the Communication Services module for theFlexRay communication system is depicted in Figure 3.3. It contains fol-lowing (sub)modules:

1. Com: The Com module provides signal based communication to higherlayers, especially to the RTE . This signal based communication serviceis used for intra-ECU communication, as well as for inter-ECU commu-nication. In case of intra-ECU communication Com mainly uses shared

33


COMDiagnostic

Communication Manager

GenericNetwork

Management

FlexRay Transport Protocol

FlexRayNetwork

Management

FlexRay Interface

FlexRay Driver

Communication Controller

PDU RouterCommunicationServices Layer

ECU Abstraction Layer

MCU Abstraction Layer

Figure 3.3: Simplified FlexRay communication stack

memory, whereas in case of distributed (inter-ECU) communication amore complex mechanism is provided: At the sender side, Com packsmultiple signals into one Protocol Data Unit (PDU). Thereafter, Compasses this PDU down to a PDU router in order to issue the PDUstransmission via the respective network interface. At the receiver side,Com obtains a PDU from the PDU router , extracts the signals con-tained within, and then forwards the extracted signals to the highersoftware layers.

2. Diagnostic Communication Manager: The Diagnostic Commu-nication Manager (Dcm) module provides services for ECU diagno-sis via the communication network. The Dcm supports the KeywordProtocol 2000 (KWP2000) standardized in ISO/DIS 14230-3 [ISO99]and the Unified Diagnostic Services (UDS) protocol standardized inISO/DIS 14229-1 [ISO06].

3. Network Management: The Network Management modules providemeans of coordinated transition of the systems ECUs into, and out ofa low-power (or even power down) sleep mode. AUTOSAR networkmanagement is divided into two modules: a bus system independentmodule named Generic Network Management (Nm) and a bus systemdependent module named FlexRay Network Management (FrNm) in

34

3.4. AUTOSAR SOFTWARE COMPONENTS

case of a FlexRay bus.

4. PDU Router: The PDU Router module (PduR) provides two majorservices: On the one hand, it dispatches PDUs, received from the un-derlying interfaces (e.g., FlexRay Interface) to the higher layers (e.g.,COM, Diagnostic Communication Manager). On the other hand, itperforms gateway functionality between multiple communication net-works, connected to the same ECU. The PDU Router forwards PDUsfrom one network interface to another, which may be either of same(e.g., FlexRay to FlexRay), or of different type (e.g., CAN to FlexRay).

5. FlexRay Transport Protocol: The FlexRay Transport Protocolmodule (FrTp) is used to perform segmentation and reassembly of largePDUsalso referred to as messagestransmitted and received by up-per layers like the Diagnostic Communication Manager. This protocolis rather similar to the ISO TP for CAN specified in ISO/DIS 15765-2.2 [ISO04].

6. FlexRay Interface: Relying on frame-based services provided by theFlexRay Driver (see below) the FlexRay Interface module (FrIf) fa-cilitates transmission and reception of PDUs. Multiple PDUs may bepacked into one single network frame at the sending ECU, and in returnhave to be extracted at the receiving ECU. The temporal executionschedule of so called communication jobs governs when packing andunpacking of frames takes place, and when frames are handed over toor from the underlying FlexRay Driver. Each of these communicationjobs consists of communication operations, where each is able to handleexactly one network frame including all PDUs contained within.

7. FlexRay Driver: The FlexRay Driver module provides the basis forthe FlexRay Interface module, by facilitating frame based transmissionand reception of data via a FlexRay communication controller.

3.4 AUTOSAR Software ComponentsAs outlined in Section 3.3, component based software engineering isAUTOSARs development paradigm at application level. It provides clearseparation of infrastructural and application concerns. Any application spe-cific functionality is assigned to AUTOSAR software components in theapplication layer. Functionality related to the systems infrastructure hasto be provided by layered software modules beneath (and including) theAUTOSAR Run-Time Environment .

35


The following sections provide a description of the AUTOSAR componentmodel. Due to its design it is well suited at application level, but is notapplicable at Basic Software level. However, as the AUTOSAR componentmodel specifies the requirements for its component middleware, it plays animportant role for work described within this thesis.

3.4.1 Software Component Definition

An AUTOSAR software component [AUT08c] is a unit of execution thatimplements a part of the applications functionality. It may be of atomicor composed nature. However, it has to be atomic in terms of deployment.Therefore, it cannot be distributed over several AUTOSAR ECUs. This re-striction results from the fact, that AUTOSAR software components mustnot implement communication and interaction specific logic. Applicationcomponents are not allowed to directly interact with the operating system orthe communication hardware, but have to interface to the Virtual FunctionBus . In consequence, software components are transferable, and hence maybe assigned to their final deployment location very late within the develop-ment process.

A software component is described by its ports. Ports are well-defined pointsof interaction that are characterized by interfaces. An interface may beprovided or required, thus in AUTOSAR a port may be of class required(R-port) or of class provided (P-port). One port comprises exactly one inter-face. Hence, this interface is called port interface. An interface can either bea client-server interfacedefining a set of operations that can be invokedora sender-receiver Interfaceallowing the usage of data-oriented communica-tion mechanisms over the VFB (see Section 3.4.2).

The AUTOSAR component definition presented so far, maps to the compo-nent definition provided in Section 2.1.1. The restrictions described aboveform a specialization of the common definition provided there. The followingcharacteristics of AUTOSAR components describe, how the components areembedded within the standards environment, and how they are executed.These properties are not explicitly mentioned within the component defini-tion in Section 2.1.1. However, they are addressed on a general level by theterm elements of execution.

Atomic AUTOSAR software components generally consist of a set ofrunnable entities. These entities correspond to implementation descriptionsand behavior specifications, and are basic blocks of execution and scheduling

36


component SW-Component

Runnable 1b

Runnable 2

Runnable 1a

P-Port

R-Port

Figure 3.4: Software component and runnable entities

for the RTE. Figure 3.4 depicts an AUTOSAR software component and itsinternal runnable entities, whereas the entities Runnable 1a and Runnable 1bare associated with the components P-port, and the entity Runnable 2 isassociated with the components R-port.

AUTOSAR software components have to cope with various system statesthat are controlled by a Mode Manager, which is part of the BSWs Serviceslayer. As the behavior of a software component is mainly determined by itsrunnable entities, mode awareness, as much as mode-change awareness, istypically implemented as configuration of runnable entities. In Figure 3.4,the P-port is associated with two entities, each for a specific set of modes.To adjust its behavior to a specific mode, a component may use one of twostandardized mechanisms:

1. ModeSwitchEvent: By defining a specific ModeSwitch event, a com-ponent registers one of its runnable entities to be executed by the Run-Time Environment on mode change (entry and/or exit).

2. ModeDisablingDependency: A components configuration specifiesif a runnable entity is executed on arrival of its associated executionevent (RTEEvent) in the systems actual mode. This mechanism israther handy if, e.g., the system is in low-power mode and certainentities simply should not be executed to save power.

To specify a component within AUTOSAR, a Software Component Descrip-

37


tion has to be provided. This description is formalized within predefinedExtensible Markup Language (XML) documents and contains the followinginformation:

1. Interface Definitions: By specifying the components ports and in-terfaces, all provided and required operations, as much as data elementsare defined. AUTOSAR interfaces may contain operation definitionsfor method invocations, and data elements that are typically used insender-receiver interaction.

2. Infrastructural Requirements: The infrastructural requirementsspecify system level services that have to be provided by AUTOSARsystem software.

3. Resources Needs: The components requirements on system re-sources are typically related to memory consumption and CPU usage.Res

2009 phdthesis schreiner

Documents