Analysis and Design of a Policy based approach to Software Download in a Distributed Automotive Middleware

ANDREAS LINDELL

Master of Science Thesis Stockholm, Sweden 2007

This sentence was intentionally made white.

Analysis and Design of a Policy based approach to Software Download in a Distributed Automotive Middleware

Andreas Lindell This sentence was intentionally made white.

Master of Science Thesis MMK 2007:76 {MDA 308} KTH Industrial Engineering and Management Machine Design SE-100 44 Stockholm This sentence was intentionally made white.

This Master Thesis was written at, and in cooperation with,

Keywords: Automotive Middleware, Embedded System, Distributed System, Software Load, Policy, Repository, Policy Repository, DySCAS, AUTOSAR, OSE Epsilon, Linux, Polyhedra

The contents, results and conclusions of this master thesis represents the au- thor’s opinion only, and is not in any way affiliated with those of the DySCAS or AUTOSAR consortium, or that of Enea AB or the Royal Institute of Technology.

c 2007 Andreas Lindell .

Master of Science Thesis MMK2007:76 MDA 308

Analysis and Design of a Policy based approach to Software Download in a Distributed Automotive Middleware

Andreas Lindell

Approved: Examiner: Supervisor: 2007-12-18 Martin T¨orngren Magnus Persson Commissioner: Contact Person: Enea Detlef Scholle . Abstract . DySCAS is an automotive research project with the purpose of providing a future standard within the vehicle electronics layer satisfying the needs of both today’s and tomorrow’s automotive producers. This master thesis was carried out at Enea during the fall of 2007 with the purpose of investigating the implementation of software download through an external and secure communication link to every node in a DySCAS system. Furthermore it aimed at investigating how policies, which are a part of making the system behave autonomously, should be managed in the DySCAS project when it came to storing these in a repository. Finally, the AUTOSAR standard- ization, another automotive project, was studied for an investigation to be made about which requirements that should be set on the architecture of DySCAS, for it to co-exist with the AUTOSAR standardization. After an initial literature study, addressing the issues presented above, a design of the software system was carried out followed by an implementation and testing of this software. A general design of a system supporting software load, allowing both the replacement of one middleware component as well as the update of an entire node running in the DySCAS middleware, has been presented. In the subse- quent implementation the possibility of using the CAN network to upgrade the software running on one or more DySCAS nodes with the help of an externally connected ”upgrading node” has been explored and successfully implemented in the demonstrator platform. Furthermore, a Repository Service, using Enea’s Polyhedra real-time database as the underlying repository, has been designed and implemented in the DySCAS demonstrator platform at Enea. The implemented software component supports the storage of policies and context information and thus aids the system in the objective of behaving autonomously. The Repository Service also provides the DySCAS system with a general storage facility, allowing other parts of the mid- dleware or applications running on top of the middleware to store data. Finally, a design of how DySCAS and AUTOSAR should be elaborated to fit together in one bigger system has been presented.

iii .

iv .

Examensarbete MMK2007:76 MDA 308

Analys och Design av ett Policybaserad angrepss¨att till Programladdning i en Distribuerad Mellanprogramvara f¨orfordon

Andreas Lindell

Godk¨ant: Examinator: Handledare: 2007-12-18 Martin T¨orngren Magnus Persson Uppdragsgivare: Kontaktperson: Enea Detlef Scholle . Sammanfattning . DySCAS ¨arett forskningsprojekt inom bilindustrin som syftar till att ta fram en framtida standard f¨orelektroniksystemet i bilar som tillfredsst¨allerb˚adedagens och framtidens krav ifr˚anbiltillverkarna. Detta examensarbete genomf¨ordesp˚aEnea under h¨osten2007 med syftet att utreda hur programladdning genom en extern och s¨aker kommunikationsl¨anktill varje nod i ett DySCAS-system ska implementeras. Vidare ska examensarbetet utreda hur policys, som ¨aren del av angreppss¨attetf¨or att f˚asystemet att bete sig autonomt, ska hanteras inom DySCAS n¨ardet kommer till att lagra dessa i systemet. Slutligen ska AUTOSAR, som ¨aren redan befintlig standardisering inom bilindustrin, studeras f¨oratt utreda vilka krav som ska st¨allasp˚aDySCAS- arkitekturen f¨oratt den ska kunna samexistera med AUTOSAR. Efter en inledande litteraturstudie, d¨ar de ovan presenterade omr˚adenastud- erades ing˚aende,gjordes en design av mjukvarusystemet som senare skulle im- plementeras i referensplattformen p˚aEnea. Implementationen av detsamma f¨oljdes¨aven av omfattande tester. En allm¨andesign av hur systemet ska hantera programvaruladdning har tagits fram som till˚aterb˚adeenstaka komponenter likv¨alsom inneh˚alletp˚aen hel nod att uppdateras. I den efterf¨oljandeimplementationen s˚ahar m¨ojligheten att anv¨andasig av CAN-n¨atverket f¨oratt uppdatera programvaran som k¨orsp˚a en eller flera noder i ett DySCAS system, med hj¨alpav en externt p˚akopplad ”uppdaterarnod”, utnyttjats. Vidare s˚ahar en Repository Service, som anv¨anderEneas realtidsdatabas Polyhedra som den underliggande lagringsplatsen, designats och implementer- ats i DySCAS-demonstrator-plattformen p˚aEnea. Den implementerade mjuk- varukomponenten tillhandah˚allerm¨ojlighetenatt lagra policys och kontextin- formation och ¨ard¨arav en del i att f˚aDySCAS-systemet att bete sig autonomt. Repository Servicen tillhandah˚allerocks˚aDySCAS-systemet med en allm¨anla- gringsplats som l˚aterb˚adeandra mellanprogramvarukomponenter och applika- tioner som k¨orsovanp˚amellanprogramvaran att lagra data. Slutligen har en design av hur DySCAS och AUTOSAR b¨orutvecklas f¨or att de tv˚asystemet ska kunna samexistera i ett st¨orresystem tagits fram..

v vi Preface

I would like to send a warm thank you to all the people at Enea that made this master thesis possible, especially to Detlef Scholle and Barbro Claesson for all your support during the course of my work. Also a big thank you to my supervisor Magnus Persson and my examiner Martin T¨orngrenat the Royal Institute of Technology for all your help and ideas and for having the patience to endure my wordy way of writing. And finally, thanks to all my master thesis colleagues at Enea for all your in- spiring ideas and our invaluable discussions during our months together. Bj¨orn, Joakim, Joakim, Martin and Mikael - thanks for 20 both funny and interesting weeks. . . /Andreas

vii viii Contents

1 Introduction1 1.1 Purpose...... 1 1.2 Goal...... 1 1.3 Delimitations...... 2 1.4 Method and Outline...... 2 1.5 Previous work...... 3

2 Background5 2.1 Layers of a Vehicle...... 5 2.2 DySCAS...... 5 2.2.1 Use cases, functionalities and requirements...... 6 2.3 Autonomic Computing...... 7 2.4 AUTOSAR...... 8 2.4.1 Purpose...... 8 2.4.2 AUTOSAR today...... 8

3 Use Cases and Existing Architecture9 3.1 Use Cases and Requirements...... 9 3.1.1 Applicable Generic Use Cases...... 9 3.1.2 Selection of Specific Use Cases and System Requirements 10 3.2 Existing DySCAS Demonstrator Platform...... 11 3.2.1 Architecture...... 12 3.2.2 APIs...... 13 3.2.3 Repository...... 13 3.3 Conceptual DySCAS Architecture...... 15 3.3.1 Software Load Management Service...... 15 3.3.2 Autonomic Configuration Management Service...... 17 3.3.3 Repository Service...... 17 3.3.4 Independent Application (e.g. AUTOSAR)...... 17

4 Software Load in a Distributed System 19 4.1 Literature Study...... 19 4.1.1 Linking and Loading...... 20 4.1.2 Object File Formats...... 21 4.1.3 Dynamic Linking and Loading...... 22 4.1.4 The Absence of Dynamic Linking...... 24 4.1.5 On-Board Diagnostics...... 27 4.1.6 Security, Safety and Software Load...... 28

ix 4.1.7 Conclusions...... 29 4.2 Design of a Software Load system...... 30 4.2.1 General Design of a Software Load System...... 30 4.2.2 Software Load and Dynamic Linking...... 32 4.2.3 Software Load Without Dynamic Linking Capabilities.. 33 4.2.4 Software Load via the CAN network...... 33 4.2.5 Application-Triggered Software Load...... 34 4.2.6 Security and Software Load...... 35 4.2.7 Two Descriptive Examples...... 36 4.3 Implementation of Software Load via the CAN bus...... 37 4.3.1 The different modes of the Receiver node...... 38 4.3.2 The process of triggering the receiver mode...... 39 4.3.3 Provided functionality...... 40 4.3.4 The CAN messages...... 41 4.3.5 Using an Upgrade Server on the Epsilon platform..... 42 4.3.6 Summary...... 42 4.4 Testing of the implemented components...... 43

5 Storage of Policies in a Repository 45 5.1 Literature Study...... 45 5.1.1 Policies...... 45 5.1.2 Different types of policies...... 46 5.1.3 Policy-driven Self-management...... 47 5.1.4 Policy Expression Language...... 48 5.1.5 Repository...... 48 5.1.6 Security...... 50 5.1.7 Summary...... 50 5.2 Design of the Repository Service...... 50 5.2.1 Implementation of the Repository Service...... 51 5.2.2 Retrieving information from the Repository...... 51 5.2.3 Alternative implementation of the Repository...... 53 5.2.4 Services provided by the Repository Service...... 53 5.3 How Policies should be managed in the Repository...... 53 5.3.1 The Definition of a Policy...... 54 5.3.2 Context Manager...... 54 5.3.3 An Active Database...... 55 5.4 Implementation of the Repository Service...... 55 5.4.1 Polyhedra as an Active Database...... 55 5.4.2 Repository Service Functionality appertaining to Policies...... 56 5.4.3 General Repository Service Functionality...... 57 5.5 Testing of the implemented components...... 58

6 Merging DySCAS with AUTOSAR 59 6.1 Literature Study...... 59 6.1.1 Software Architecture Concept...... 59 6.1.2 ECU Software Architecture...... 61 6.1.3 Operating System...... 62 6.1.4 Interfaces...... 63 6.1.5 A static configuration...... 63

x 6.1.6 The finalized AUTOSAR system...... 63 6.1.7 Summary...... 64 6.2 Design of a joint DySCAS and AUTOSAR system...... 64 6.2.1 Configuration Considerations...... 64 6.2.2 Communication Considerations...... 65 6.2.3 DySCAS Architectural Considerations...... 66 6.2.4 AUTOSAR Architectural Considerations...... 66

7 Results and Experiences 69 7.1 The new Demonstrator Platform Architecture...... 69 7.1.1 Software Load in a Distributed System...... 70 7.1.2 Repository Service...... 70 7.1.3 Merging DySCAS with AUTOSAR...... 71 7.1.4 Conclusions...... 71 7.2 Experiences...... 71 7.2.1 Dividing the work into different phases...... 71 7.2.2 Concurrent Programming and Revision Control...... 72 7.2.3 Working separately in a bigger group toward a common goal...... 72

8 Future work 73 8.1 Connecting the two demonstrator platforms...... 73 8.2 Upgrade Server...... 73 8.3 Versioning of Software Load components...... 74 8.4 Security and Software Load...... 74 8.5 Versioning of Policies...... 74 8.6 AUTOSAR...... 74

Bibliography 75

A Abbreviationsi

B The DySCAS Demonstrator Platform iii

C Earlier Reference Platform Architecturev

D Demonstrations vii D.1 Software Load...... vii D.2 Policy Repository...... vii

xi xii Chapter 1

Introduction

This master thesis is a part of the DySCAS (Dynamically Self-Configuring Au- tomotive Systems) research project which is partially funded by the European Commission and a cooperation between a number of companies within the au- tomotive industry as well as a number of European Universities. The vehicle industry is growing as fast as ever and over the last twenty years more than 70 percent of automotive innovations have been related to information and communication technologies within the vehicle’s electronics layer [1]. The main purpose of the DySCAS research project is to provide a future standard for the automotive industry within the vehicle electronics layer, satisfying the needs of today’s and tomorrow’s automotive producers when it comes to having a flexible platform to build upon. This master thesis was carried out at Enea, during the fall of 2007. Enea is one of the companies working in the DySCAS project and the company’s part in the project has been to implement a reference platform, that has been set up during previous master theses. This master thesis was carried out with supervisors from both Enea and the Royal Institute of Technology.

1.1 Purpose

The purpose of this master thesis is to investigate the areas of software load, the storage of policies in a repository and the AUTOSAR standardization to see how the DySCAS architecture should be altered to fit in with these issues. This master thesis shall fall into a design and an implementation in the reference platform at Enea in the above mentioned areas. The results from this work shall also be fed back to the DySCAS consortium, to aid in the work of developing the open specification that will be the final product of the DySCAS project.

1.2 Goal

This master thesis shall investigate different ways of loading software into an embedded system through an external communication link connected to any ECU in the system, and analyze which one of the possible options to software load that should be used in the DySCAS platform. The thesis aims at looking

1 2 into areas of software load such as upgrade and downgrade of functionality and rollbacks to earlier configurations. The question to be answered is: how should software load be implemented in the DySCAS demonstrator platform? (Q1) This master thesis shall also analyze the design and implementation of a Repository Service within the DySCAS middleware and how this service should be constructed to support storing different sets of policies that will later be used by the system to control its behavior during run-time. The Repository Service should provide the system with the ability to change policy during run-time, depending on the context it is working in. To sum it up, this master thesis aims at answering the question how should a repository be used to store policies within the DySCAS demonstrator platform? (Q2) As a side track, the approach of the AUTOSAR standardization shall be looked upon to investigate which requirements that should be set upon the architecture of DySCAS for it to co-exist with AUTOSAR. More specifically, it aims at answering the question what needs to be added to the DySCAS and AUTOSAR architectures respectively for them to be able to co-exist? (Q3)

1.3 Delimitations

The literature study part of this master thesis is the result of five weeks worth of work and hence not all areas of interest could be fully covered. The study puts its main focus on the area of software load, as this is the main area for the subsequent master thesis to investigate. The area of policies was studied from two perspectives, both to provide an overview of what policies is and also to study more in detail how the Reposi- tory Service in the DySCAS architecture should be implemented to support the storage of policies. Finally, the area of studying the AUTOSAR standardization was given the lowest priority, limiting the work to getting a good overview of the standard- ization and studying the main mechanisms of it, in order to identify the main things to consider when integrating the two standardizations of DySCAS and AUTOSAR.

1.4 Method and Outline

The first few weeks of this master thesis was mainly of an organizational kind, where the direction of the work to be done was laid down and the planning for the rest of the thesis, as well as an initial pre-study of the DySCAS project, related technologies and the existing demonstrator platform at Enea were made. The result of this will mainly be seen in this Introduction chapter and the following Background chapter. In chapter3, Use Cases and Existing Architecture, an investigation of the DySCAS use cases and requirements affecting this master thesis as well as the existing demonstrator platform at Enea will be presented together with the parts of the conceptual DySCAS architecture presented by the DySCAS consortium that are of interest to this master thesis. The main work of this master thesis was essentially divided into three phases. First, a Literature Study was undertaken with the approach of studying current 1.5. PREVIOUS WORK 3 research in the areas of interest both in the form of research papers and re- lated literature as well as a deeper study of the specifications produced by the DySCAS consortium so far. Following this, the Design phase took on an ana- lytical approach to the information gathered in the previous phases of the work to form a design of the implementation to be made in the architecture of the demonstrator platform at Enea. This was then followed by the Implementation phase where parts of the designed software systems were implemented in the DySCAS demonstrator platform at Enea. In order to get a better structure in this master thesis report the description of this work has been divided up into different chapters depending on the area studied. In chapter4 the work concerning Software Load in a Distributed System (Q1) is described. This is followed by chapter5 describing Storage of Policies in a Repository (Q2) and finally the work on Merging DySCAS with AUTOSAR (Q3) is described in chapter6. To sum up the report the Results and Experiences of this master thesis is described in chapter7, followed by suggestions for Future work which are presented in chapter8. In appendixA, a list of abbreviations used through out this report will be presented.

1.5 Previous work

The work of this masters thesis is highly influenced by several previous theses carried out at Enea concerning both the DySCAS architecture as well as the hardware platform used in the DySCAS demonstrator platform. Much work has also been done in the DySCAS project by the collaborating members of the DySCAS consortium and this master thesis is of course highly influenced by this. The setup of the existing demonstrator platform at the beginning of this master thesis can be seen in appendixB. 4 Chapter 2

Background

This chapter will lay a foundation for the rest of this master thesis and in brief terms introduce the automotive standardization AUTOSAR as well as the DySCAS project. To start off, this chapter will present the concept of different layers within a vehicle’s electronic architecture.

2.1 Layers of a Vehicle

The electronic architecture of a modern car can be divided into different layers, as described in figure 2.1. These different layers contains different parts of the car’s functionality, as described in [2]: Vehicle Dynamics Control divided into power-train (for engine and trans- mission control for example) and chassis control (with functionality such as brake, suspension and vehicle dynamics sensors). Body Electronics controlling such things as doors, coupe climate and the instrument cluster1. Infotainment2/ Telematics3 with functionality such as navigation, telemat- ics and audio. These different layers in a modern car all have different demands on safety and network bandwidth, the vehicle dynamics layer being the most safety- critical one in terms of robustness while the infotainment / telematics layer have the highest demands on the bandwidth. Because of this they might run on different network technologies but, as shown in figure 2.1, they are all connected with the help of gateways.

2.2 DySCAS

As described in [3] and [4] DySCAS is a research project partially funded by the European Commission within the 6th framework program. It started in June 1In the automobile context this refers to a set of instrumentation, including the speedome- ter, in front of the driver. 2In the automobile industry this term refers to the in-vehicle entertainment system. 3In this context, telematics refers to the science of sending, receiving and storing informa- tion via telecommunication devices.

5 6 CHAPTER 2. BACKGROUND

Figure 2.1: Layers of a vehicle

2006 and will end in November 2008 and is a cooperation between a number of companies in related industries, including Volvo, Daimler Chrysler, Enea and Bosch, as well as a number of European universities; the Royal Institute of Technology, University of Greenwich and University of Paderborn. The DySCAS project focuses on the Infotainment / Telematics layer of the car’s electronics as well as some parts of the body electronics layer. The main focus of the project is an embedded automotive system that emphasizes a dy- namic self-configuration of the system with the goal to create an intelligent networked automotive middleware system with properties such as a high degree of robustness and fault-tolerance due to its self-adaptability at run-time. Fur- ther benefits with a standard includes making it easier for third part devices to be used in different vehicles. The platform is to support automatic discovery and integration of mobile devices such as mobile phones, mp3-players and satellite navigation as well as to have the ability to dynamically and automatically upgrade software with never versions or new functionality.

2.2.1 Use cases, functionalities and requirements In the document ”Scenario and System Requirements” [5] a number of use cases, functionalities and requirements of the behavior and functionality of a DySCAS system has been set up by the DySCAS consortium. The relationships between these are described in figure 2.2. The idea behind this concept will be described in this section and later on in chapter3 the specific use cases and system requirements that this master thesis needs to focus on will be presented and explained more in detail.

Generic Use Cases (GUC) Four generic use cases, grouping together com- mon functionality of the specific use cases are described. These are: 2.3. AUTONOMIC COMPUTING 7

Figure 2.2: Graphical presentation of use cases

• GUC1: New Device Attached to the Vehicle • GUC2: Integrating New Software Functionality • GUC3: Closed Reconfiguration • GUC4: Resource Optimization

Specific Use Case (SUC) The main idea with the SUCs is to describe basic conditions and behaviors that a DySCAS system and the applications in it must fulfill; this could for example be a description on how a navigation system on a mobile device should be used.

System Functionality (SF) This layer consists of a set of abstract system functionalities that are necessary in a DySCAS system for it to carry out the different use cases in a correct way. Any functionality belongs to exactly one specific or generic use case. An example of a functionality con- nected to the specific use case described above could be the functionality to attach a detected mobile device to the DySCAS system.

System Requirements (SR) The system requirements are meant to decou- ple the design of the DySCAS middleware from the concrete use cases described above. This could for example be the requirement that the at- tachment of a mobile phone should take no more than two seconds for the system to perform.

2.3 Autonomic Computing

The DySCAS consortium aims at a self-managing, or autonomous, system as described in [6]. Although DySCAS does not have the exact same approach to this, the aspects of a self-managing system is well described by IBM in [7] and [8], two papers on what they refer to as Autonomic Computing. The thought behind Autonomic Computing is to have a computer system that can adapt itself during runtime to comply with high-level objectives sup- plied by the administrator of the system. Four attributes of an autonomous system are described by IBM:

Self-configuring: a system which can dynamically adapt itself to changing environments. 8 CHAPTER 2. BACKGROUND

Self-healing: a system which can discover, diagnose and react to malfunctions or disruptions within itself.

Self-optimizing: is a system which can tune its resources and balance the workload within it automatically in order to maximize the use of informa- tion technology resources. Self-protection: a system’s ability to anticipate, detect, identify and protect itself against threats.

The approach to implementing these self-managing attributes suggested by the DySCAS consortium is using policies, for example describing how the system should react to a certain event.

2.4 AUTOSAR

The AUTOSAR4 project, as presented in [9] and [10], was initiated by a number of automotive producers and their closest sub-contractors in 2003 and now, four years into the project, it includes a large number of automotive, electronics, semiconductor, hard- and software companies.

2.4.1 Purpose The main goal of the AUTOSAR project is to make it possible to re-use soft- and hardware components between different vehicle platforms, OEMs5 and suppliers. The goal is to establish a standardization that could serve as a platform for vehicle applications in the future. The catch phrase ”cooperate on standards, compete on implementation” is often used by the AUTOSAR participants [9] and the idea behind it is for the automotive producers and their sub-contractors to avoid the huge costs of developing a new platform for every new car introduced to the market by having a standardized platform that can be re-used in new car models. By doing this each part can instead focus on the functionality of their contributions to a new car model.

2.4.2 AUTOSAR today Today AUTOSAR is a standardization with more than a hundred partners and it is expected to have the first compliant products incorporated in production vehicles starting in 2008. With this in mind, it is of course of interest for the DySCAS consortium to take a closer look at AUTOSAR for many reasons. The main reason for this master thesis to investigate AUTOSAR is that it is of obvious interest for a future DySCAS standardization to be able to interoperate with the by then existing AUTOSAR standardization.

4AUTomotive Open System ARchitecture 5Original Equipment Manufacturers Chapter 3

Use Cases and Existing Architecture

This section will present the DySCAS use cases and requirements that are rele- vant to this master thesis. Furthermore the architecture of the existing DySCAS demonstrator platform at Enea will be presented more in detail, together with the conceptual DySCAS architecture as presented by the DySCAS consortium.

3.1 Use Cases and Requirements

There are a number of use cases and requirements that that will affect the design of the future alterations of the DySCAS demonstrator platform. These generic and specific use cases, as well as the requirements, as presented by the DySCAS consortium, will be presented in this section.

3.1.1 Applicable Generic Use Cases The only Generic Use Case directly applicable to this master thesis, mostly related to the software download part, is the GUC2: Integrating New Software Functionality, described together with the other GUCs in [5]. In short, this Generic Use Case describes two main issues:

• Installation or removal of functions by installing or removing software components. • Improving software by exchanging software patches or by updating soft- ware components.

This includes both application and operational software and it is of impor- tance that the system integrates the new software and ensures that the new configuration works properly or else the old software configuration must be re- installed. It is also of importance that this is done as seamlessly as possible for the driver of the vehicle and that it does not in any way affect the behavior of the vehicle. It is, however, also of interest to keep GUC1: New device attached to the Vehicle in mind which describes the process of attaching an external device to

9 10 CHAPTER 3. USE CASES AND EXISTING ARCHITECTURE the vehicle, since this will be necessary for a software load from an external device to take place. There is no specific use case describing this process more in detail. However, there are a number of non-functional requirements that will have influence on the final implementation:

• The integration must be as transparent as possible for the user.

• It must not be possible to corrupt the vehicle information system (VIS) using the interface for external devices or the external device itself.

• Only authorized devices may be connected to the VIS.

• If confidential data are transferred between devices and the VIS these data must be protected against unauthorized access.

3.1.2 Selection of Specific Use Cases and System Require- ments There are two Specific Use Cases described in the document [5] that directly will affect this master thesis:

SUC2/3: Software update and upgrade According to this SUC three different cases of software load can be distinguished; software update, software upgrade and installation of new applications. This SUC assumes that the source containing the new software has already been attached to the vehicle, a process with requirements briefly described in the previous section, as well as that the software that is to be installed is certified. Further on, a number of technical requirements on the vehicle IT system is described by this SUC:

• Functionality to start and perform the download to the appropriate ECU1 in the system.

• An algorithm to decide on which ECU the application is to be installed or operated.

• A way to transfer software to the right ECU and install it there.

• Capability to reinstall the previous configuration if the new one doesn’t work properly.

• Means to prove the identity of process or person who downloads the soft- ware.

• Means to prove the certification of the software.

Due to time constraints not all of these topics will be fully covered by this master thesis.

1Electronic Control Unit 3.2. EXISTING DYSCAS DEMONSTRATOR PLATFORM 11

SUC2/4: Downgrade of Software As explained by the DySCAS consortium, software downgrade is the opposite of software upgrade and the purpose of a software downgrade would be to reduce the functionality of the vehicle’s IT system. At this point no specific technical requirements have been set by the DySCAS consortium on the vehicle’s IT system with regards to the SUC downgrade of software. Two different solutions, from a technical point of view, are however described:

• The software module which implements the functionality remains installed in the vehicle IT system but the access to this module is prohibited.

• The software module implementing the functionality is uninstalled.

Security A number of requirements deals with the issue of security during a software load:

REQ-A-22 Download acceptance Before any new software is downloaded a trusted (authorized) person or process must approve the download.

REQ-A-26 Download security Software downloaded into the system shall be protected.

REQ-A-67 Secure external communication It shall not be possible to ac- cess and corrupt the vehicle information system using an external interface to it.

REQ-A-68 Secure external communication Confidential data sent from the vehicle information system to the external world or vice verca must be kept confidential.

Non-DySCAS Entities Of special interest is also one of the requirements, REQ-A-63 Non DySCAS entities. This requirement describes that the DySCAS middleware shall be able to communicate with remote entities/devices that are not fully DySCAS compliant, for example an AUTOSAR device.

Policies Policies, responsible for making the system self-managing, is not directly ad- dressed among the requirements and use cases and will therefore not be covered in this section.

3.2 Existing DySCAS Demonstrator Platform

This section will present the existing demonstrator platform at Enea and the architecture of relevance to this master thesis. 12 CHAPTER 3. USE CASES AND EXISTING ARCHITECTURE

The Enea implementation aims at being as architecturally coherent as pos- sible with the conceptual architecture of DySCAS. The parts of the conceptual architecture of interest for this master thesis will be presented in section 3.3. At Enea two different DySCAS demonstrator platforms exists. The first platform consists of a number of weaker nodes running Enea’s own RTOS OSE Epsilon distributed over a CAN network, meant to symbolize the body electron- ics layer of the car. The second platform is a network with more powerful nodes running a distribution of Linux as operating system, interconnected over an ethernet network. This implementation is meant to symbolize the infotainment / telematics layer of a car (see section 2.1). It is in the latter domain that most existing applications developed for the platform reside today.

3.2.1 Architecture

Figure 3.1 shows the existing implementation of the architecture in the DySCAS demonstrator platform at Enea:

Figure 3.1: The implemented DySCAS architecture

The architecture has been divided into a number of different layers where the platform layer is at the very bottom, consisting of the actual hardware, the operating system including the drivers and the repository. It is then up to the instantiation layer to solve all the dependencies in the platform layer on the hardware and operating system. In other systems this layer is sometimes called the portability layer. This is to make it possible for the DySCAS middleware layer to exist both under the Linux operating system as well as OSE Epsilon without having to be adopted. Applications in a DySCAS system are only allowed to used functions in the middleware by making calls to functions in the DySCAS API (see section 3.2.2). 3.2. EXISTING DYSCAS DEMONSTRATOR PLATFORM 13

This also matches with the conceptual architecture [14] where the middle- ware is presented as a standardized component that should be able to run under any kind of platform whereas the instantiation layer (or portability layer, as it is referred to) solves all dependencies on the underlying hardware, RTOS and other basic components.

3.2.2 APIs As can be seen in figure 3.1 there exists two separate APIs in the DySCAS architecture. The System API should be used only by the middleware and no other calls than to the System API may exist in the middleware in order to make it platform independent. On the other hand the DySCAS API will be used only by the applications while these under no circumstances may use the System API or make calls directly to the actual platform. The DySCAS API’s main purpose is to hide the underlying functionality of the middleware by just exposing methods that can be used.

3.2.3 Repository The existing demonstrator platform also implements Enea’s own real-time data- base (RTDB) Polyhedra as described in [11]. This section will provide a brief presentation of the features of Polyhedra of interest for this master thesis as well as the existing implementation of Polyhedra in the demonstrator platform. Polyhedra is an object-oriented2 RTDB with the ability to provide persistent storage. Polyhedra consists of a number of different modules, see figure 3.2.

Figure 3.2: The modules of Polyhedra

The Real-Time Relational DataBase (RTRDB) is the central part of Polyhe- dra, containing the data that exists during run-time as well as the definitions of the current database while the Journaling module is the part of the system re- sponsible for storing data marked as persistent to a data load file. The Server is the way for the Clients to request data from or change data within the database.

2E.g. it allows inheritance, and tables can derive from other tables 14 CHAPTER 3. USE CASES AND EXISTING ARCHITECTURE

There are two ways to write clients for the Polyhedra database, either using the ODBC API or the Callback API. Since the Callback API is the one that provides the thinnest layer between the programmer and the underlaying system as well as having the feature of being non-blocking, i.e. the client is never blocked while waiting for the server to complete a task, it is this API that has so far been used in the Polyhedra applications running on the demonstrator platform at Enea. Except for the client-server approach there are two other ways, and lan- guages, to communicate with the system. Control Language, or CL, is the object-oriented programming language used to develop Polyhedra applications and for defining methods on tables in the database as well as the behavior of data in the RTRDB, the Control language Client (CLC) is the client responsi- ble for handling CL calls. The Structured Query Language Client (SQLC), is a client supporting a command line SQL-interface to a Polyhedra server and ways for accessing and updating data in a server.

Active queries A very interesting feature of Enea’s Polyhedra is that it supports active queries [12]. Whilst an ordinary query (request of data) to the database just returns the requested data, an active query returns the requested data and then continues to provide notification to the client should the requested data change.

Security in Polyhedra The RTRDB supports standard SQL security features as described in [12]. These security features supports concepts such as user, user privileges and table ownership as well as optional password security, thus providing the system with a way to control who can enter or extract what (kind of) information into or out of it.

Polyhedra’s real-time features In the product documentation [12] Polyhedra is described as an RTDB but in- vestigations by a previous master thesis [11] shows that it actually lacks a very important feature that an RTDB should have, namely the ability to prioritize different processes when communicating with the RTRDB. Instead, almost ev- erything is done on a first-in first-out queue, a limitation that this master thesis needs to keep in mind at the design and implementation stages.

Polyhedra implementation in the existing platform A design of how to implement a Configuration Resolver using the Polyhedra database in the reference platform was designed by [11] and this setup is de- scribed in figure 3.3. Even though this design was not fully implemented in the platform it still works as a good base for how the database and middleware components using its services should be implemented in a DySCAS system. On each node in the designed system there exists a configuration resolver that handles communication with the Polyhedra Client. It is then this client that handles all communication with the RTRDB residing on the same node as the client. With this setup the nodes can communicate with the Polyhedra 3.3. CONCEPTUAL DYSCAS ARCHITECTURE 15

Figure 3.3: Polyhedra implementation in the existing platform

client through regular DySCAS communication and then the Polyhedra client should handle the Polyhedra communication with the RTRDB.

3.3 Conceptual DySCAS Architecture

The DySCAS consortium document on the System Architecture [14] describes architectural concepts and middleware and service features that should be ex- pected of a DySCAS system. The presentation is of a very conceptual kind and independent of implementation and technology details. Figure 3.4 shows an overview of the conceptual architecture. Just like the work in this master thesis the DySCAS system architecture takes its basis in the use cases and system requirements that has been discussed earlier in this report in section 2.2.1. The purpose of this section is to describe the parts of the conceptually designed architecture that has relevance to this master thesis.

3.3.1 Software Load Management Service

The software load management service has the overall system role of being the executor of dynamic load operations and it mainly deals with the self-configuring aspect of the DySCAS system. It is a core service responsible for initializing and controlling the loading and unloading of software components. Two key-concepts to successfully implement software load in the DySCAS architecture as identified by the DySCAS consortium are the support for dy- namic linking and dynamic loading. The topic of dynamic loading and linking will be addressed further and more in depth later on in the literature study, this section will only introduce these concepts, as described in the document on the DySCAS system architecture. 16 CHAPTER 3. USE CASES AND EXISTING ARCHITECTURE

Figure 3.4: The Conceptual DySCAS Architecture [14]

Dynamic Loading Dynamic loading is the ability for a system and operating system to start a process at runtime. There are two requirements of a system for dynamic loading to be possible:

• The system needs to have the ability to add binary after start-up to the memory area where the program is stored. In some cases, but not all, a re-start of the system could be acceptable. • Secondly, the operating system needs to have support for instantiation of new applications after start-up.

Dynamic Linking Dynamic linking is going even one step further, giving the operating system the ability to delay binding to a specific code library at least until application start-up. Aside from a system that is more flexible, this approach gives two main advantages as opposed to working with statically compiled code:

• Storage space is saved as library code is included only once and not du- plicated as is often the case with static configurations. • The reduction of duplications of code also reduces the effort of updating since only one library has to be updated and recompiled. 3.3. CONCEPTUAL DYSCAS ARCHITECTURE 17

Software Upgrade The conceptual architecture also describes a number of alternatives to how the issue of making a software upgrade could be approached.

• The application itself could be responsible for checking for upgrades and if needed download these. • The Repository Service, where all applications are stored, takes on the re- sponsibility to check regularly for updates for any of these, and downloads and installs the updates available.

• OEM’s could be responsible for ”pushing” out updates. • Upgrades are installed manually, e.g. by inserting a CD-ROM into the multimedia player or attaching a USB stick into the system. • The On-Board Diagnostics (OBD), usually used by mechanics to analyze the various electronic sub-systems of a car, could be used.

3.3.2 Autonomic Configuration Management Service The Autonomic Configuration Management Service is the core service in the DySCAS middleware responsible for assessing and planning all the dynamic reconfigurations of the system. Having the ability to overlook the system the service has the ability to reason about the system’s current and potential con- figurations, as well as verifying the potential impacts on the configuration of the system a reconfiguration of it would lead to.

3.3.3 Repository Service The Repository Service has a number of overall system roles. It is supposed to serve as a repository of files, components and diagnostics information and to have knowledge of configuration and decision policies. Among other things, the DySCAS consortium states that the Repository Service should be responsible for storing ”the files of software components as well as the policies and rules for online decision-making” . The conceptual architecture states that the Repository Service is allowed to have interactions with any other middleware services and suggests that it could be implemented either as a database, a file system, or as a mix of the two. The Repository Service could also be implemented both as a centralized service or as a distributed service.

3.3.4 Independent Application (e.g. AUTOSAR) The box Independent Application (e.g. AUTOSAR) in the conceptual architec- ture is not implicitly described in the DySCAS system architecture as this is a part of the architecture that the consortium has yet to decided on an approach to. This leaves a lot of space for this master thesis to suggest it’s own solution to how the two architectures should be made to co-exist. 18 CHAPTER 3. USE CASES AND EXISTING ARCHITECTURE Chapter 4

Software Load in a Distributed System

This master thesis shall investigate different ways of loading software into an embedded system through an external communication link connected to any ECU in the system, and analyze which one of the possible options to software load that should be used in the DySCAS platform. The thesis aims at looking into areas of software load such as upgrade and downgrade of functionality and rollbacks to earlier configurations. The question to be answered is how should software load be implemented in the DySCAS demonstrator platform? (Q1)

4.1 Literature Study

The area of software load, as approached by this master thesis, can be divided into two parts. It is the part of getting the new code to be executed in the embedded system into it, and it is the part of coupling this new code together with the already existing code in the system and the loading of this into the memory of a particular microcontroller. This master thesis will be working with the overall architecture of software load in the DySCAS demonstrator platform at Enea. With the previously dis- cussed division into the two parts of software load it will mainly be working with the first part of this area in the implementation phase. The purpose of this part of the literature study is to provide a deeper study of the full scope of software load, and while parts of the investigations are not directly coupled with the scope of this master thesis, it is still important to get the full picture before a design of the system can be made. While it is usually easier to start from the beginning, this master thesis will begin by looking into the area of coupling the new and existing code together, or rather the area of linking and loading, as this will later be the starting point of the discussion on how, and in which form that, code can be moved into an embedded system.

19 20 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

4.1.1 Linking and Loading The usual approach in the embedded systems world, as described by Simon in [15], going from files of source code to an up-and-running system can be seen in figure 4.1.

Figure 4.1: The process of Compiling, Linking and Loading

Using this approach the original source code, in the case of the DySCAS demonstrator code written in the C language, must first be compiled by a cross- compiler on the host system on which the code has been written. The cross- compiler will then produce the binary instructions, in the form of object files, that can be understood by the target microprocessor(s). Each C file will be turned into one corresponding object file. The output from the cross-compiler needs then to be linked together into one executable file that can be run on its own on the microprocessor in question, and it is up to the developer tools linker and locator to handle this part of the process. In most systems these two tools are combined into one; the linker/locator and from this point and on the term linker will be used for this combined tool. One big part of the work of the linker is called address resolution and refers to the work of solving the fact that many microprocessor instructions contains references to variables that needs to be stored somewhere in the memory of the microcontroller, so for example a reference to the variable a_variable in the code needs to be changed into the address of the variable. The process of address resolution starts with the compiler which, at compile time, does not know what the address of a_variable will be and therefore leaves flags in the corresponding object file for the linker to resolve when it puts all the object files together. If, as in the case of the DySCAS demonstrator platform, a Real-Time Op- erating System (RTOS) is being used the linker will glue the application code together with that of the RTOS. The linker also needs to be aware of where in the memory of the microcontroller the program will reside in order to fix up all the addresses correctly. Other tasks performed by the linker, as described by [16], are relocation, where the information of the object files are loaded into non-overlapping ad- dresses and symbol resolution which fixes references between different subpro- grams so that the calls refers to the correct address in memory - basically the same type of work as address resolution but performed with a system- overlooking view in mind. The output format of the linker varies depending on the system in use but the two file formats of interest for this master thesis are Intel’s HEX file format (being used in the OSE Epsilon part of the platform) and the ELF file format 4.1. LITERATURE STUDY 21

(being used in the Linux part).

Object Code Libraries The main principle of object code libraries, as described in [16], is that it is a set of object code files bunched together. After the linker has processed the regular input files (i.e. the object files) it runs through the library (libraries) and links in any of the files in the library (libraries) into the resulting executable file, see figure 4.2.

Figure 4.2: The Linking Process with Libraries

If the library is on the form Shared Library the process is delayed a bit further, as the linker merely notes in the output file the names of the libraries where symbols can be found, and leaves it to the loader to finish the process of binding everything together.

4.1.2 Object File Formats The ELF format ELF, Executable and Linking Format, as described in [16] is an object file format originally developed by AT&T since they needed a file format that better supported cross-compilation and dynamic linking. The ELF format has been made popular among other reasons for being adopted by Linux. ELF comes in two different versions for 32 and 64 bit variants and there are three different kinds of ELF files:

Relocatable A file created by the compiler/assembler that needs to be pro- cessed by a linker before it can run on its target system. Executable A file that has had all its relocation done and all symbols resolved (except for possible shared libraries that are resolved at runtime as de- scribed in section 4.1.1). Shared Object These are essentially shared libraries, containing both symbol information for the linker and directly runnable code for runtime. 22 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

The HEX format In [31] Intel describe the HEX, or HEXadecimal, object file format. It comes in three different versions, for 8-, 16-, and 32-bit microcontrollers and is one of the oldest object file formats available with the first versions of it having been used since the 1970s. The HEX format represents the binary object code in ASCII with each line containing one hex record that represents either machine code and/or constant data and is a format that is suitable to use as input to EEPROM or Flash programmers, hardware emulators, and such. Once a HEX file has been created it cannot be dynamically re-linked (see section 4.1.3).

4.1.3 Dynamic Linking and Loading The process described in section 4.1.1 produces an executable file that can run on the corresponding microcontroller. If for example a software module needs to be added or a part of the system needs to be changed after the initial compilation the standard approach would be to have the altered files re-compiled and then to have all these re-compiled files re-linked - a very inflexible and time consuming approach. Also, this approach does not comply very well with the demands on a DySCAS system of being self-managing. Another approach, described by Levine in [16], is to use the approach of dynamic linking. With dynamic linking the linking part of the process can be delayed until the object code is residing inside of the embedded system since different parts of the system does not need to be bound to actual addresses in the memory of the microcontroller until the program starts running. Furthermore new libraries can be bound to the program as it is running, even in the middle of program execution, providing the system with a way to extend or change the functionality of a program. Stadel [17] also discusses Dynamic Linking as the solution to the problem of replacing software components on the fly in a running program (which is also the name of his paper), and he writes that this service should be provided by the (real-time) operating system. Furthermore, Stadel suggests a configuration manager that should be responsible for providing a user interface allowing the user to enter maintenance commands. Depending on what kind of maintenance command the user enters, the configuration manager should call the dynamic link loader ”to dynamically load and bind requested new modules or to unload old modules no longer in use.” Kramer and Magee has done a lot of work on dynamic (re-)configuration of distributed systems. In [18] they discuss a model for dynamic configuration of an embedded system as well as the requirements of the (operating) system to support dynamic configuration. They also suggest a configuration manager as the part of the system responsible for commanding the underlying operating system to be modified during run-time. Furthermore they list a number of es- sential properties of an operating system to support a dynamic re-configuration of a distributed system:

Module Management The operating system’s ability to load or delete code in the form of module types into parts of the operating system and the ability to create or delete instances of module types. It must also allow the 4.1. LITERATURE STUDY 23

configuration manager to control the execution of modules and to query the state of the system.

Connection Management The system must provide the service of establish- ing and deleting connections between modules.

Communication Support The system must support intermodule communi- cation.

The configuration manager, as described by Kramer and Magee, translates the change commands given to it into executable commands to the operating system, to change the current system. Since this translation may require knowl- edge of the current state of the system, Kramer and Magee suggests that this information about the system may either be obtained from a database main- tained by the configuration manager, or from the system itself.

Configuration and Change Specifications Kramer and Magee also suggests a configuration language used to describe the logical structure of a system, as well as the modifications to a system. They list a number of essential properties of such a language, where the most important ones are the following:

Context Definition A description of the set of module types from which the system is constructed.

Instantiation A specification of the instances of module types which are to be created in the system.

Interconnection A description of the way that module instances are inter- connected.

Inverse function A specification of the inverse functions of the ones listed above, e.g. which modules to remove from the system.

Dynamic Reconfiguration Service Bidan et al [32] describes an interesting approach to dynamically changing com- ponents in a system during run-time, causing minimum disruption to it. Al- though this area of software load is outside of the scope of this master thesis a short and non-technical description of their approach will still be considered. Bidan et al describes an algorithm which passivate all links affected by a reconfiguration before the actual reconfiguration of the system is started. With this approach, only the activities directly connected to the part of the system that is being upgraded (or downgraded) is being affected, while the rest of the system can continue to run. Figure 4.3 gives a graphical description of this algorithm. In this case a module can be for example a part of the DySCAS middleware that needs to be replaced, as well as an application in the system that needs to be updated. What is left undiscussed in the above section is the matter of getting this new software module into the system, ready to be linked into it. 24 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

Figure 4.3: The algorithm described by Bidan et al

4.1.4 The Absence of Dynamic Linking While dynamic linking/loading seems to be the obvious approach to having a self-configuring system that can be changed during run-time, not all systems has the capability to conduct such operations. If the real-time kernel used in the system does not support the processes of creating or destroying tasks at runtime, other approaches to (un-)loading software in the system has to be taken. Three different approaches to this will be described in the following sections.

Upgrade Server Ajmani et al [19] discusses a system where an entire node in it is updated at once. They describe a system consisting of an upgrade server, an upgrade database and upgrade layers at the nodes, see figure 4.4. In this system, each part is responsible for different parts of the upgrade process: Upgrade Server (US) Provides the system with a central repository of infor- mation about upgrades as well as the upgrade database. Upgrade Database (UD) Provides a central store for information about up- grade status of nodes. Upgrade Layer (UL) Localized on each node, responsible for installing up- grades on the particular node. In this system the nodes can learn about upgrades through communication with the upgrade server, either having the ULs polling the US for new upgrades or the US notifying the ULs of new upgrades available. Once the UL learns about there being a newer version of its software it communicates with the upgrade server to download a small upgrade description allowing the UL to assess whether the upgrade concerns this particular node or not. If it does, it downloads the upgrade and installs it on the node, before notifying the UD that its node is running the new version of the software. 4.1. LITERATURE STUDY 25

Figure 4.4: The upgrade system described by Ajmani et al

Reconfiguration Execution Engine L´egeret al [20] suggests a Reconfiguration Execution Engine (REE) to be the part of the system in charge of the reconfiguration process in the absence of dynamic linking facilities in the RTOS. Their methodology relies on three main principles:

• software encapsulation and decomposition by the means of proxies1,

• a language to express an initial configuration, a reconfiguration and the constraints that must be respected during the reconfiguration phase,

• and a reconfiguration execution engine.

Figure 4.5 shows the reconfiguration process as described by L´egeret al. In this system, the REE is distributed between the embedded system itself and the maintenance facilities, e.g. the host computer used to develop the modified architecture of the system. In this approach the process of reconfiguring the application on-board an embedded system consists of several steps. After an informal description of the needed behavior of the embedded system, i.e. the reason for a reconfiguration being necessary, a modified architecture of the system is developed by the ap- plication designer. This falls into a set of reconfiguration orders that needs to be applied to the running code. Next, these orders are tested by the part of the REE residing outside of the embedded system before it is being transmitted into the actual system where they are executed in order to modify the system. With this approach, several different reconfigurations can be tested by the REE outside of the system, that decides which one is most suitable for the ”real” system - and then executes this reconfiguration in the actual system. This solution leads to a non-monolithic code2 composed of several smaller pieces corresponding to one item of the high-level description of the system, and all bound together by the means of proxies - bindings that can be changed according to modifications described by the reconfiguration language.

1in this case, a proxy is a component in the system that handles the relationship and communication between two different software modules 2In this case, a monolith is defined as when all applications and the RTOS are compiled together into one chunk of code that is loaded into the system. 26 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

Figure 4.5: Reconfiguration Process Overview

The Reconfiguration Language L´egeret al describes the semantics of the reconfiguration language more in detail:

• It is used to describe each component of the application, including all properties of it that is necessary and sufficient in order to manipulate this component.

• The language is used to describe the architecture of the application; the items used in the configuration, their state in the configuration and the binds between these items. What is described is the actual loading or deletion of items, the modification of their states and the changes to the binds between the items that makes up the configuration.

• The language is also used to describe the constraints that affects the re- configuration of the system, for example if there is a maximum time for the reconfiguration to be finished in.

The Infineon approach Infineon [21] presents an entirely different approach to the problem of software load that does not have all the dynamic properties of a software load that this master thesis is looking for, but it is nevertheless interesting. Infineon presents a system in which one node acts as a transmitter and another as a receiver where the transmitting node can upgrade the receiving node with a new application over the CAN bus. The approach, presented in figure 4.6, is quite straight forward and the only restrictions on the nodes participating in this transaction is that the first few 4.1. LITERATURE STUDY 27

Figure 4.6: Programming an external flash over CAN [21]

sectors of flash memory in each node is reserved for the transmitter and receiver program respectively. The transmitter program should contain an algorithm to copy the contents of its flash memory and send it on the CAN bus to the transmitter node. Similarly, the receiver program will need to contain an algorithm to receive data over the CAN bus and to then program this data into its flash memory. The restriction that the receiver program needs to be programmed into the first sectors of flash on the receiver node comes from the fact that this is the program that should be executed when the node is (re-)started, to initially check if an application has been programmed into the node or not. For this setup to work, the memory setup for the application to be flashed over CAN needs to be altered for it to start executing from a higher sector in the flash memory. Furthermore the interrupt vector of this application needs to be moved. These changes will also affect the behavior of the program used to initially flash the application into the transmitter node, and that is why the first few sectors of flash memory will need to be used for the transmitter program. Another feature is that the receiver program needs to move a number of its operations into RAM before being able to execute them, this is because operations cannot be performed on the flash memory from another part of the flash memory, something that is solved by moving these operations into RAM before executing them.

4.1.5 On-Board Diagnostics On-Board Diagnostics (OBD) [22][23] is a de facto standard within the auto- motive industry today and ever since the introduction of the OBD II standard 28 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM in 1996 more and more cars are now equipped with an OBD system. Since 1996 OBD II has been mandatory in cars sold in the United States and since 2001 the European Union made it mandatory for all new petrol vehicles sold in the European Union as well. The system was originally designed to monitor all components in a car that can affect its emission performance, but today more and more information about the car can be extracted through this system. This data does not only concern the engine performance of the car but also parts of the chassis and body elec- tronics layer (as described in section 2.1) as well as in some cases parts of the vehicle electronics layer are being monitored. There are three different ISO standards in use for the actual communication with the OBD, all of which with just some minor variations on how the com- munication is handled. Mutual for all these standards is that they use the same hardware interface, the J1962 connector, and that they all implement the CAN protocol on the same pins in the connector. Furthermore, the OBD connector is to be located in the driver’s compartment, making it easily accessible yet un- available for unauthorized persons. Thus, the OBD provides a secure external entry-point into the CAN-network of a car.

4.1.6 Security, Safety and Software Load Any computer system is vulnerable to security attacks, as is an automotive one, and especially in the context of a software load this is an important question to consider. The DySCAS consortium states that ”ideally, software will need some kind of approval, either from the car owner or the manufacturer, to be allowed to be installed” [14]. The DySCAS consortium also list a number of different strategies to deal with the safety aspects of performing a software load. The system could for example only allow the software in the car to be changed when the car is in a special safe mode (i.e. when it is parked or at the automobile workshop) or it could install the new software and let it run in parallel with the old version for a while, with a safe fall-back controller allowing the software to ”fall-back” to using only the old version of the software should the new one not work properly. This latter approach is called Simplex architecture.

A secure communication link Although a big investigation into the security aspects of a software load is not in the scope of this master thesis a short study of some existing security standards, as presented by the DySCAS consortium in [2] will be made.

HIS Security module A number of German car manufacturers has together developed a number of standard software modules in a number of different areas, among them flash programming. In their work a security module has been de- veloped with the intent to handle all ”relevant aspects of the flash programming process”, and the overall security goals of this module is:

• Error detection

• Authenticity 4.1. LITERATURE STUDY 29

• Copy protection

• Confidentiality

• Authorization of external programming tool

ISO 15764/20828 for Road Vehicles Two interesting ISO standards are the 15764 ”Road Vehicles - Extended data link security” and 20828 ”Road vehi- cles - Security certificate management” which together covers data transmitted within, between or from and to road vehicles guaranteeing both their confiden- tiality and integrity.

ISO 24534 Automatic vehicle and equipment identification Another interesting new ISO standard is the Electronic Registration Identification as described in ISO 24534. The purpose of this new standard is to provide a way to uniquely identify road vehicles by the means of certificates. If communication between different vehicles are to be allowed, this new standard provides an interesting way to establish the authority of the communication to take place.

A safe reconfiguration Cailliau and Bellenger [24] discusses reconfiguration of real-time systems in space-born instruments and has some interesting remarks on safety and secu- rity of the reconfiguration process. They suggest that some kind of system for checking the soundness of the reconfiguration orders should be implemented, limiting the impact of human mistakes. Furthermore they discuss the matter of reversibility, meaning the ability to reverse any of the reconfiguration operations to recover a previous state of the system. This implies that ”the software needs to keep a record of the various reconfigurations it sustained, including a safe validated Default Configuration systematically loaded after reset”, and being able to switch back to a stable configuration, should problems arise.

4.1.7 Conclusions In what way a software load is performed in a DySCAS system is very depend- ing on the underlying hardware being used. On more advanced microcontrollers RTOS:s with more advanced functionality can be used, e.g. allowing new com- ponents to be dynamically linked into the system at run-time. An interesting approach, allowing for components in a system to be dynam- ically changed during run-time has been studied, as well as a language with to express these changes to the part of the system in charge of the changes in it. Furthermore, a number of essential properties of a system that is to allow a dynamic reconfiguration has also been presented. Other more resource constrained microcontrollers only allow for the smallest RTOS:s to be used, and thus the option of dynamically linking in new compo- nents is not offered. For these systems other ways of implementing software load, albeit of a less dynamic nature, has to be taken and a number of approaches to this has been presented. Whichever approach to software load that is implemented in the DySCAS demonstrator architecture, it is essential that the security aspects of adding new 30 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM software components to it is looked upon, and a number of different approaches to this has been presented.

4.2 Design of a Software Load system

As discussed earlier two reference platforms have been built at Enea illustrating different layers of the embedded system of a vehicle. On a number of more powerful nodes a version of Linux is running as operating system while on the more weaker nodes Enea’s own OSE Epsilon is the operating system being used. While Linux supports dynamic linking during run-time, OSE Epsilon does not, and thus two different approaches to Software Load has to be taken in these two platforms respectively. This is however a limitation that serves this master thesis quite well, as it illustrates the current design of embedded systems in vehicles with a number of different ECUs: some weaker and some more powerful, that are being used for different purposes within the system.

4.2.1 General Design of a Software Load System According to the DySCAS consortium [5] a software load should be performed as seamlessly as possible for the driver of the vehicle, and should not affect the behavior of the vehicle. Furthermore the DySCAS consortium emphasizes the importance of having the ability to return to an old configuration of a DySCAS system, should the integration of new software not work properly. This is also discussed by Cailliau and Bellenger [24] who also state that the system should keep a record of older configurations, as well as a validated default configuration that it could return to should it be necessary. The approach of Ajmani et al [19], using an Upgrade Server with an Upgrade Database, can be generalized to be used both in systems with dynamic linking capabilities and in systems without it. The responsibility of the Upgrade Server should also be expanded to include storing old software modules that has been replaced in the system. In the DySCAS system the repository will contain an upgrade database and the Repository Service within the middleware will be the service responsible for communicating with this upgrade database. This master thesis suggests the introduction of a new middleware component within the Autonomic Configuration Management Service to be introduced: a Dynamic Software Manager. This Dynamic Software Manager would have the responsibility to be communicating with the Upgrade Server to find out if there are any relevant upgrades for any parts of the system. The Dynamic Software Manager then has the system overlooking role to assess the new upgrade and to decide, with the help of the Dynamic Policy Manager, if the update should be allowed or not. If the update is to be made, the Dynamic Software Manager notifies the Software Load Management Ser- vice, that is a middleware service that will be present on all nodes in a DySCAS system about the upgrade (the DySCAS equivalent of Ajmani et al’s Upgrade Layer (UL)), and the Software Load Management Service is responsible for per- forming the actual upgrade. Before an update is made the UL of the respective node should also be responsible for distributing the software component that is to be replaced to the Repository Service to have it stored there (should it 4.2. DESIGN OF A SOFTWARE LOAD SYSTEM 31 not already have been stored there) if a fall-back to the previous configuration would be needed.

Upgrade Communication Two different approaches to the communication between the Dynamic Software Manager and the Upgrade Database has been identified, either the Dynamic Software Manager should be responsible for periodically checking with the Up- grade Database if there are any new software upgrades available for it, or the Upgrade Database is responsible for informing the Dynamic Software Manager whenever a new software upgrade becomes available to any parts of the system. To minimize the communication between different parts of the system the latter approach is the better one. To ensure that all ECU:s in the system retrieve information about all upgrades available in the system they are responsible for responding to any message of new software upgrades being made available in the system, irrespective of if they are interested in the particular upgrade or not.

More Complex Software Load Issues In a complex system such as DySCAS comes the issue of asserting the system’s stability and integrity during a software upgrade or downgrade. For example that the more complex issue of updating several nodes at the same time are handled correctly. An example of such a case would be that a new update becomes available to two nodes at the same time, but for the integrity of the system to be kept the updates needs to be performed in a certain order. This, and other complex issues, are described by the DySCAS consortium in [14] and according to them they should be handled by the Autonomic Configuration Handler. According to the DySCAS consortium the handler should also be responsible for handing the overall process of performing a software load. This master thesis suggests, however, that this task also should be per- formed by the Dynamic Software Manager, that is a part of the Autonomic Configuration Manager Service - a more high-level middleware component than the Autonomic Configuration Handler. Using this approach any possible de- pendency problems, or other related information, should be a part of the meta information stored together with a software upgrade in the Upgrade Database so that the system can perform the software upgrade in a correct way. If for example the repository has been implemented as a mixture of a file system and a database the database should not only contain the reference to where in the file system the new software component to upgrade with has been stored but also a number of fields describing dependency issues and other related meta information to replacing the old software component to the system with this new one.

Making an upgrade available to the system As identified by the DySCAS consortium and described in section 3.3.1 there are a number of different ways for a software upgrade to be made available to the system. As previously described an upgrade should go through the upgrade 32 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM database, or Repository Service, within the DySCAS middleware and there are a number different ways how a software upgrade could have ended up there. Either the user of the vehicle could have inserted an external device con- taining the update into the vehicle (for example using a USB storage device or a CD) or the vehicle could have passed a wireless hot-spot and through a con- nection to the vehicle manufacturer’s web-servers an upgrade could have been downloaded to the vehicle. For only relevant upgrades to be downloaded into the vehicle’s upgrade database it should be responsible for keeping information on the current config- uration of the system stored, to be able to make a match with upgrades being ”offered” to it.

A Summary of the General Software Load Design Figure 4.7 provides an overview of the general design of a software load system. Some kind of update is made available to the system through the Upgrade Database and the Dynamic Software Manager is notified of this (1). It then checks with the Dynamic Policy Manager (2) if the system is in such a state that an upgrade of it is possible or not. If the Dynamic Software Manager receives a positive response to this question (3) it passes the request on to the Software Load Management Service on the respective node (4) that is responsible for performing the actual update of for example a middleware component. Before the actual update is made (6) the part of the system to be updated is copied into the upgrade database (5) for a safe fall-back to be made possible should the new configuration of the system not be functioning correctly.

Figure 4.7: General design of software load system

4.2.2 Software Load and Dynamic Linking In the case of a system consisting of more powerful nodes with the ability to run an operating system with dynamic linking capabilities, such as the Linux-part of the DySCAS demonstrator platform at Enea, a fully dynamic approach to 4.2. DESIGN OF A SOFTWARE LOAD SYSTEM 33 software load can be taken and it should be possible to dynamically update software components during run-time in this kind of system. Exactly how this process should be designed is outside of the scope of this master thesis but since it is up to this master thesis to design the overall archi- tecture of software load some concepts will be discussed here. The Object File Format used on the Linux-platform is the Executable and Linking Format (ELF) and to provide the system with the ability to dynami- cally update parts of itself during runtime the software module to be updated needs to be delivered to the system in the form av a Relocatable ELF file, to- gether with some kind of description on how this module fits in with the rest of the system, as described by Kramer and Magee [18] when they describe the concept of Configuration and Change Specifications. As previously described this information should be stored together with the actual software update in the Upgrade Database.

4.2.3 Software Load Without Dynamic Linking Capabili- ties In a system with an RTOS without dynamic linking capabilities a less dynamic approach to software load has to be taken. Essentially, this means that the entire content of these nodes needs to be updated at once, with pre-compiled and linked code. Even though the trend in the automotive industry is for the ECU:s to con- tain more and more functionality, many ECU:s in a modern vehicle today only provide one functionality and thus the update of this functionality might as well imply the update of the software on the entire node. Furthermore, even though an ECU in the system provides the system with more than one functionality it is still interesting to have the possibility to ”wipe” the entire node and replace its contents, should there be a problem with the soft- ware running on it for example. One situation where this would be interesting would be if the car manufacturer discovers problems in the software of a newly released car model they could, using this approach to updating the software run- ning on one or more nodes in the car, they could then easily solve this problem through making an update on all sold vehicles this way. In this kind of system the Dynamic Software Manager would still be respon- sible for assessing upgrades and decide if the system is in such a state that it can be updated or not. However, since the entire content of the node is to be upgraded the actual update cannot be done unless the system is in a special safety mode, for example when the car is parked, since the upgrade will need the node to be restarted since its entire content will be changed.

4.2.4 Software Load via the CAN network The Infineon approach presented in section 4.1.4 is a very interesting approach to use on the nodes without dynamic linking capabilities to provide the system with updating capabilities. Furthermore, the OBD interface in all vehicles being produced today provides an external entry point into the CAN network of the vehicle and thus the use of the CAN network to update an entire node in it is interesting to build upon. 34 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

The suggested approach would be to insert an external device into the OBD connection, and thus the CAN network, of the vehicle. This external device would act as a transmitter of an application (that would also be present on this external device) destined for one or more nodes in the CAN-network. Another possible way to use the CAN Flashing approach would be to use one of the more powerful nodes in a DySCAS network as the transmitter (or ”updater node”) of a software upgrade destined for one the less powerful nodes in the system. This master thesis suggests that the master node in the system, where the Dynamic Software Manager exists, should be responsible for handling also this functionality when it learns from the upgrade database (the Repository Service) that there is a new software update for one of the weaker nodes in the system. If it found an update for another node in the network it would alert the driver that there is a possible update for one of these nodes available, upon which the driver is responsible for triggering the upgrade. All the weaker nodes in the vehicle, where this CAN flashing approach is of interest, would have the ability to receive new applications over the CAN network and also to install this new application ”on itself”. The respective node would also, before installing this new application, transmit its old contents to the Repository Service to have it stored for future use - should the new application be erroneous the system would have the ability to fall-back into this old and functioning configuration. Since an update using this approach means replacing the full contents of a node in the system the only safe approach would be to have the system somehow stopped (i.e. stop the car and then put it in a ”safe to upgrade mode”) before making the upgrade. This master thesis suggests that it should be the responsibility of the driver, or car mechanic, to manually put the car in this state by turning a switch in the driver’s compartment of the vehicle.

Issues specific to the Enea platform

The reference platform at Enea where this approach to software load would be interesting, to implement is the one with the less powerful nodes running OSE Epsilon on Infineon’s C167 microcontrollers, connected over a CAN network. The current approach when updating functionality on one or more nodes in this network is to download new code over a serial connection to each and every node in the network. The downloaded executable is in the form of an Intel HEX executable object file. The suggested approach to software download via CAN on this platform is presented in figure 4.8. The idea is to use one of the nodes in the system as an ”upgrading node” that can be used to upgrade the application on one or more of the other nodes on the CAN-network.

4.2.5 Application-Triggered Software Load Also applications running on top of the DySCAS middleware should have the possibility to be updated and in this special case there are some special issues to consider. Just as in the case of an update of parts of the DySCAS middleware being conducted the new application-component to be installed will have to go through the upgrade database before being installed in the system. 4.2. DESIGN OF A SOFTWARE LOAD SYSTEM 35

Figure 4.8: Software load via CAN flash.

Just as with regular middleware components, the upgrade database should be responsible for keeping information of the system’s current configuration, in terms of which applications are running on top of the DySCAS middleware. With the help of this information the system can decide which of the updates ”offered” to it should be downloaded into the upgrade database and then offered to the rest of the system, and which should not.

4.2.6 Security and Software Load The DySCAS consortium states in the scenario and system requirements docu- ment [5] that a software load should require approval, either from the car owner or the manufacturer in order to be made (REQ-A-22). On the other hand, as previously discussed, a software load should be performed as seamlessly as possible for the driver. This contradiction does of course have to be handled in some way, and this master thesis suggests this to made by the means of policies describing in which context which kinds of upgrades are to be allowed. A number of interesting approaches, in the form of ISO standardizations, to security in the context of a software load have also been briefly presented in the literature study and the scope of these should be further investigated for a possible use within the DySCAS standardization. The Polyhedra RTDB also provides a means of providing a secure approach to software load since it supports the ability to grant different users different privileges when it comes to adding information to or extracting information from the database.

Offline Verification Offline verification of a software upgrade outside of the embedded system, what is basically described both by L´egeret al in their description of the Recon- figuration Execution Engine [20] and also by Cailliau and Bellenger in their work on reconfiguration of real-time systems in space-born instruments [24] is an interesting aspect to the security questions concerning a software load. 36 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

L´egeret al’s Reconfiguration Execution Engine provides the functionality to test a reconfiguration outside the embedded system before it is deployed into it to examine if the specific reconfiguration of the embedded system is possible to make, while Cailliau and Bellenger states that checking the soundness of the reconfiguration orders to a system first and foremost is important for limiting the impact of human mistakes. Since the embedded system in a vehicle obviously is a very safety critical one, the possibility to perform offline testing of a reconfiguration before it is deployed into the system is a very interesting functionality to ensure the integrity of the system. For example: when updating an application component running on top of the DySCAS middleware the matter of assuring that this new application com- ponent can be installed in such a way that the rest of the system is not affected by it could be solved using this approach. This master thesis suggests that this should be handled through the use of Upgrade Certificates that can be issued only by the DySCAS consortium. Through this system of certificates a DySCAS system would check with a cen- tralized database (for example when passing a wireless hot spot) for the upgrade certificate adhering to the upgrade of an application component before installing it.

Security during a CAN Flash In the special case of the OBD being used for the upgrade of one or several nodes the security aspects of a software load are somewhat different from the regular approach. In this special case it can be assumed that the person performing the software load is authorized to do so since the OBD connector is located in the driver’s compartment and thus you will need to have access to the car (e.g. have the car keys or have been let into the car by someone in possession of the car keys) in order to access the OBD connector. The status of the new code being deployed into the system is however still uncertain, and thus the repository should, as earlier mentioned, be responsible for storing the old code residing on the particular node so that the possibility to go back to the previous version of the software on the node is present.

4.2.7 Two Descriptive Examples This section will provide two descriptive examples of how a software load could be conducted in two systems with and without dynamic linking capabilities respectively.

A Wireless Dynamic Upgrade One possible chain of events with a system supporting dynamic linking would be the following. The vehicle passes a wireless hot spot that makes it possible for the car to connect through the Internet to the car manufacturer. Through this commu- nication the car learns about the availability of a new upgrade for the GPS 4.3. IMPLEMENTATION OF SOFTWARE LOAD VIA THE CAN BUS 37 application used by the vehicle. After proving the authenticity of the wire- less hot spot to download information into the vehicle, the authenticity of the server from which the upgrade is downloaded and finally checking with the car manufacturer or the OEM for an upgrade certificate for this particular upgrade the system decides to download the application into the repository of the car and alerts the Dynamic Software Manager in the system that a new upgrade is available. The Dynamic Software Manager checks with policies if this is an update that is possible to perform on the system and if this request passes, it forwards the request to the SW Load Management Service of the node where the update is to be performed. The SW Load Management Service residing on the actual node to update is then responsible for downloading and installing this new upgrade after having stored away the old application component in the Repository Service for a future safe fall-back.

A Less Dynamic Upgrade in the Automobile Workshop A descriptive example of the ”special approach to software load” presented above, using the approach of Infineon, would be the following: An upgrade of some functionality concerning one or more of these ”less powerful nodes” are made available by the car manufacturer and all vehicle owners concerned by this upgrade are notified in some way, e.g. could the vehicle through periodic communication with servers owned by the car manufacturer, via wireless hot spots, find out about an upgrade. The vehicle could then inform the driver through the car’s interfaces that a software upgrade is available. Depending on what kind of upgrade that is to be made the driver then either visits an automobile workshop certified by the car manufacturer and, via the OBD interface, deploys this new software upgrade into the vehicle’s embedded system or the master node in the system can itself download the update through the wireless hot spot and then, after having been triggered by the driver, put the vehicle in a ”safe to upgrade mode” and perform the update of the concerned node in the system. The old configuration of the system is at the same time saved by the Repository Service for a possible re-use should there be a problem with the new configuration.

4.3 Implementation of Software Load via the CAN bus

The approach to software load that this master thesis deemed most interesting to implement was the usage of the CAN network to upgrade the entire functionality on one or more nodes in the DySCAS demonstrator platform, as described and designed in section 4.2.4. The work started from the basics only illustrating the functionality by send- ing a diode blinking program from one node to another over a single cable CAN-network using two nodes, building on from the design elaborated from the Infineon approach presented in section 4.1.4. In this first version one trans- mitter and one receiver was used to send an application from one node (the transmitter) to another (the receiver) and this proved to be a success. 38 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

The DySCAS demonstrator platform, however, consists of six nodes on a bigger CAN-network and thus the problem of identifying each and every node exclusively needed to be addressed. This proved to be much simpler than ex- pected though, as this was already something that was dealt with on the demon- strator platform where a number of pins of the respective microcontroller was ”hard coded” either high or low from the power supply. These pins can then be read by the respective node and a value between one and six calculated based on this hard coding. This problem is also one that needs to be addressed when implementing this kind of functionality in a real car so that the system or the individual performing a software upgrade can identify which node it wants to perform an upgrade on. The proposed solution would use a kind of client server approach where the master node in the system is responsible for assigning an ID to each node in the system, and each node to keep the master node updated on its current configuration. Using this approach it should be possible to see which node contains which functionality when connecting to the system with an ”upgrading node” so that the system or individual performing a software upgrade can know which specific node it is to upgrade.

4.3.1 The different modes of the Receiver node When a node programmed to be a receiver node, i.e. it contains the receiver program, is started it first checks if it contains an application or not. It does this by calculating a checksum over the programmable sectors of the on-board Flash memory and comparing this to the last two bytes of Flash memory for a checksum that would have been put there should an application have been programmed into the node by a transmitter node. If the checksum does not match, i.e. no application resides on a receiver node or an incomplete or otherwise faulty application resides there, it is in ”receiver mode”, which means that it listens for CAN flash messages on the CAN-bus and is ready to perform actions affecting it. Once an application has been flashed onto a node in receiver mode it needs to be reset (another action that can be performed on it while in receiver mode) after which the newly loaded application will start running. The node is now in ”application mode”. A node that is in application mode will need to have the ability to go back into receiver mode for updates of it to be made possible. This is however an action that should not be allowed to happen without checking with current policies in the system if it is ready to be updated. This mode switch was easily performed when running just a simple diode blinking application since this application could just be setup to check incoming CAN messages, just like the receiver program does when in receiver mode, and if it received a ”go to receiver mode” signal it would do just that - go into receiver mode. However, when running DySCAS nodes the CAN bus on the demonstrator platform is scheduled using Time Tokens3 which means that the

3When using time tokens the LINKHANDLER on the respective DySCAS node in the system is only allowed to send messages on the CAN bus when it receives a time token from the master node in the system. This time token also specifies what amount of data a node is allowed to send. It is only at system startup nodes can register with the master node and a node that has hasn’t received a time token won’t be able to send messages on the CAN bus. 4.3. IMPLEMENTATION OF SOFTWARE LOAD VIA THE CAN BUS 39 transmitter node won’t be able to send out its ”go to receiver mode” messages on the CAN bus while a DySCAS system is running. The solution to this was to use a key circuit switch as a way of telling the system’s master node to prepare for a software update instead. This would also better symbolize what would happen in ”the real world” where a car would be delivered to the car shop where the mechanic, having access to the driver compartment of the car, could connect its ”updating equipment” to the OBD connector of the car and trigger an update using - for example - a special key. Before this action can be taken the system checks with its current policies if it is possible to enter receiver mode, and if that is the case then puts the system in this state, i.e. stops sending out time tokens and instead jumps into the receiver mode of the receiver application. This final setup is illustrated in figure 4.9.

Figure 4.9: Illustration of the implementation of software load via CAN

4.3.2 The process of triggering the receiver mode Figure 4.10 describes the process of triggering the DySCAS system to go into ”receiver mode”, i.e. to prepare it for an update of one or more of its nodes over the CAN network. As previously described the initial trigger for putting the system into ”re- ceiver mode” has been implemented as a key switch. A Key Handler has been implemented that keeps track of the key switch and is responsible for passing on information to related middleware components whenever the key is switched. In this case the key handler is responsible for notifying the Dynamic Software Manager, that is a part of the Autonomic Configuration Management Service, whenever the key has been switched (1). The Dynamic Software Manager is the centralized middleware component responsible for overlooking the process of replacing a component in the middle- ware as well as updating an entire node in a DySCAS network, as described in section 4.2.1. The Dynamic Software Manager will therefore, with the help of 40 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

Figure 4.10: How the receiver mode is triggered through a key switch

the Dynamic Policy Manager and the Resource Manager Service (2) - (5) assess the current state of the system to decide whether an upgrade of one or more nodes in the system should be allowed or not. If an upgrade is allowed by the system the Dynamic Software Manager starts by notifying all applications running in the system that the system is about to be upgraded (6), giving them a chance to terminate before the upgrade takes place. In the Enea reference platform this will imply that the head and indicator lights on the platform will be turned off if they are lit. Once this is done the Dynamic Software Manager notifies the Software Load Management Service residing on each node (7) in the system to put the node in ”receiver mode”, enabling a software upgrade through the CAN network to be made (8).

4.3.3 Provided functionality There are three different kinds of actions that can be performed on a node in receiver mode:

Erase Erases the contents on all but the protected sectors (where the receiver program is stored) of the flash memory of the receiver node.

Program Program the application loaded onto the transmitter node into the receiver node’s empty flash sectors.

Reset Perform a software reset on the receiver node. If an application has been flashed onto the receiver node this will lead into this application starting to execute instead of the receiver program. 4.3. IMPLEMENTATION OF SOFTWARE LOAD VIA THE CAN BUS 41

Before the erase and program operations can be performed the code in the receiver node performing the respective operation is moved into IRAM since it cannot perform operations on the flash from code running in the flash. The user of the upgrade system connects to the transmitter node using a program such as Hyper Terminal on a standard PC and triggers the different actions using a keyboard, for an example of the user interface see figure 4.11 which illustrates the process of erasing the contents on a chosen node in the system, load new software onto this node over the CAN network and then performing a software reset on the node, which starts the application that was flashed onto the node.

Figure 4.11: The user interface of the Transmitter program

4.3.4 The CAN messages Figure 4.12 describes the usage of the CAN message payload in the CAN Soft- ware Load implementation. The first data byte (eight bits) in the payload of the CAN message describes on which node to operate and which operation to be taken on this node, while the rest of the CAN message payload is used in different ways depending on the action. When a new software load is to be made these message objects contains the data to be flashed onto the remote node and to which address in the remote node to flash this data. The system is set up so that the receiving node always sends back an ac- knowledge to the transmitting node after each received message containing the same first message object (receiver id and action id). To ensure the integrity of the application that is flashed onto the receiving node the transmitting node will not continue to send a new message until this acknowledge-message has been returned. If no acknowledge-message has been received for five seconds the transmitter node will assume that there either was no node in the network with the cor- responding receiver id or that the node with the corresponding receiver id was 42 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

Figure 4.12: The CAN flash message payload

removed from the network during the transmission and alert the user of this. It is then up to the user of the system to try and perform a retransmission, after having erased the flash memory of the receiver node again. When the entire application has been flashed onto the receiving node the transmitter sends a message telling the receiving node that the entire application has been programmed into its flash memory as well as a checksum that the receiving node is to program into the highest byte of flash memory for the receiver node to use to check if a correctly flashed application resides on it or not.

4.3.5 Using an Upgrade Server on the Epsilon platform The designed approach of using an upgrade server as the central storage place for new software upgrades as well as a storage place for earlier software config- urations for a safe fall-back should the new version malfunction, as described in section 4.2.1, could unfortunately not be implemented since the OSE Epsilon platform is not connected with the Linux platform where the repository is resid- ing, and the scope of connecting these two networks together was beyond that of this master thesis. This is however a functionality that would be of extreme interest for the future since this gives the system the ability to fall-back into an earlier working configuration should an upgrade of a node somehow fail.

4.3.6 Summary An overview of the process of using the provided functionality of the transmit- ter and receiver programs is shown in figure 4.13 where it is indicated which actions are performed by the ”administrator” of the software upgrade (i.e. a car mechanic or the owner of the vehicle for example). Figure 4.14 on page 44 shows a more detailed description of the process of performing a software upgrade of a DySCAS node over the CAN-network. This picture shows the process once the application to be programmed over the 4.4. TESTING OF THE IMPLEMENTED COMPONENTS 43

Figure 4.13: An overview of using the Transmitter program

CAN-network is present in the transmitter node and the receiver node has been put in ”receiver mode”.

4.4 Testing of the implemented components

The software components allowing for an application to be loaded over the CAN network into any node in the DySCAS demonstrator platform was tested ex- tensively during the last weeks of this master thesis as this approach of loading an application into the nodes in the demonstrator platform was used when de- veloping other parts of the DySCAS architecture and testing these components on the demonstrator platform. A number of different tests were also carried out, trying to perform illegal or impossible operations during a SW-load, to verify that the software components’ behaved in the expected manner during these events. 44 CHAPTER 4. SOFTWARE LOAD IN A DISTRIBUTED SYSTEM

Figure 4.14: The process of performing a software load via CAN Chapter 5

Storage of Policies in a Repository

This master thesis shall analyze the design and implementation of a Repository Service within the DySCAS middleware and how this service should be constructed to support storing different sets of policies that will later be used by the system to control its behavior during run-time. The Repository Service should provide the system with the ability to change policy during run-time depending on the context it is working in. To sum it up, this master thesis aims at answering the question how should a repository be used to store policies within the DySCAS demonstrator platform? (Q2)

5.1 Literature Study

As presented earlier in section 2.3, using policies to describe how a system should react to certain events is a possible approach to making a system self-managing, something the DySCAS specification aims at. A huge amount of work has been done in the area of policies and self-managing systems and this section will after a description of what policies actually are discuss the area of storing policies in a repository.

5.1.1 Policies Using a Policy-based system is one of the possible solutions to having a system behave autonomously. With policies the behavior of a system can be expressed to the system in terms of high-level goals for its behavior, and it is then up to the system to comply with these policies. According to IBM [7] a policy is knowledge that is consulted to determine whether or not changes need to be made in the system.

Autonomic Manager IBM’s basic approach to autonomic computing has already been discussed in section 2.3.

45 46 CHAPTER 5. STORAGE OF POLICIES IN A REPOSITORY

IBM also describes an Autonomic Manager responsible for monitoring and keeping track of the system, i.e. assuring the self-managing behavior of it. It then analyzes the system’s behavior, if necessary plans for changes to it and then executes these changes in it - a process described in figure 5.1.

Figure 5.1: The Autonomic Manager as presented by [7]

The parts of the autonomic manager of most interest to this master thesis is the analyze and the plan functions since these functions needs to have direct access to the policies describing the system. The analyze function is responsible for checking if the policies describing how the system should be reacting are being met, and if not to create a change request that is passed on to the plan function. This function is then responsible for reacting to this and, according to the policies describing the system generate a change plan that is passed to the execute function within the autonomic manager.

5.1.2 Different types of policies

Kephart and Walsh at IBM write about three different types of Policies in [25]. They take their starting point in the field of Artificial Intelligence (AI) and from there identifies three policy types. This section will briefly describe these different types of policies, since they give a greater understanding of what policies are, and how they could be implemented in the DySCAS demonstrator platform.

States and Actions

From the realm of AI, Kephart and Walsh takes the notions of states and actions. A system or a system component is in a state S at a given moment in time and this state can be described as a vector of attributes. These attributes could for example be measured directly by a sensor. If a policy would want this system or system component to change state it would either directly or indirectly cause an action to be taken, which would result in the system or system component to change state to a new state.

Action Policies

An action policy dictates which action the system should take when it is in a specific current state. It can be written on the form If(...) Then(...). 5.1. LITERATURE STUDY 47

Goal Policies

Goal policies specifies either one - or a set of several - desired state(s) that the system should aim at. The system itself is responsible for computing one (or several) action(s) to take to reach the desired state(s).

Utility Function Policies

Utility Function Policies can be described as a generalization of goal policies. Instead of just stating which states are desirable and which aren’t, utility func- tion policies ascribe a real-valued scalar describing how desirable each state is. This often falls into a multidimensional set of preferences which requires some kind of optimization algorithm to identity which is the most desirable state. The objective is then to place the system into the feasible state with the highest utility.

Mixing different policy types in one system

Kephart and Walsh state that while Action policies are the most primitive ones, they are still the ones that will dominate in early autonomic computing systems. In the end, however, they expect to see systems which mix these three types of policies supplying a system that ”cover the entire state space and provide unambiguous guidance to the system”.

5.1.3 Policy-driven Self-management

In [26] Anthony and Ekelin, two members of the DySCAS consortium, describe why policy-based computing is the solution to autonomic management in the DySCAS middleware as well as which specific policy technology that should be used within it. Anthony and Ekelin describe two different approaches to implementing poli- cies in a system, either with templates or a policy configuration, and claims the latter as the more interesting and flexible approach. Using templates to define policies within a system means that all the policy logic is embedded into the actual application code and configuration parameters, for example flags, are passed to the application - allowing it to change according to the state of the system. The approach named policy configuration is, as mentioned, a much more flexible one - even allowing the policies to be changed after the deployment of software code into the system, sometimes even during run-time. In this approach, configuration values as well as policy rules are stored externally from the application code, e.g. in a repository. Anthony and Ekelin even states that this is the only realistic approach to be used in a real-time system since other solutions only lets policies be loaded or updated at initialization. Using policies does not, however, rule out the possibility to use templates in a system. Instead templates can be used to let the user configure a policy at run-time instantiation. 48 CHAPTER 5. STORAGE OF POLICIES IN A REPOSITORY

5.1.4 Policy Expression Language Anthony has also developed a language with which to express Policies, called AGILE. It is presented in [27]. With AGILE, Anthony suggests a system con- sisting of meta policies and regular policies. The idea is that a meta-policy should select the most appropriate regular policy for the system in its current context, see figure 5.2.

Figure 5.2: Meta policies and regular policies.

Just like Kephart and Walsh in [25], Anthony points out that a system with a wide potential behavioral space, one with many degrees of freedom, should not be governed by a single policy but rather by a collection of such - where the most appropriate one at the moment (as chosen by a meta-policy) is being used. Anthony also introduces templates which provides configuration parameters that are used to initialize both regular and meta policies. In order for policies to be able to be used on all nodes in a heterogeneous network, AGILE policy scripts are formatted in XML (eXtensible Markup Lan- guage). One policy script file should be used to describe the behavior of each set of policies of the same type (where policies of the same type are policies that address the same business-logic problem) since this improves the scalability of the system when each set of policies can be stored in one easily changed module. In order to be compliant with more resource constrained environments, such as the DySCAS middleware, a more lightweight version, AGILE-Lite, is being developed by Anthony and his fellow researchers in the language C, chosen for its high portability and code efficiency.

5.1.5 Repository This master thesis aims at investigating how a repository should be used to store policies within the DySCAS demonstrator platform. Another approach would be to store policies in some kind of file system, but this approach is outside of the scope of this master thesis to investigate. In [34] Anthony et al discusses Embedding dynamic behavior into a self- configuring critical software system (which is also the name of their paper) and presents a very interesting methodology for embedding policies into a system. Anthony et al discusses three main principles for the decision making behav- ior of a system such as DySCAS:

• The decision making behavior must be determined outside of the running system, for example at design time. 5.1. LITERATURE STUDY 49

• It is desirable that the decision making behavior can be changed after the initial start-up of the system. • The decision making logic should be embedded into many individual com- ponents rather than a centralized node or service.

To achieve this kind of behavior of the system Anthony et al suggests a software system as shown in figure 5.3.

Figure 5.3: The software system proposed by Anthony et al [34].

In the paper the concept of decision points and functional blocks is pre- sented, where functional blocks provides the function’s basic functionality and decision points are left ”open” - to later be filled with a decision making process. Two main parts of this system is the Decision Evaluation Module (DEM) and the Decision Configuration Module (DCM) which matched together forms the behavior of one decision point. As shown in figure 5.3 the DEM of one software component is (generally) fixed, and compiled offline before system instantiation, whereas the DCM is loaded from an external (from the software component’s point of view) storage facility and thus the behavior of the decision point is changed whenever a new DCM is loaded (or in terms of the earlier used vocabulary of this master thesis, when the policy is changed). An important aspect in the system described by Anthony et al, as well as in IBM’s Autonomic Manager as described in figure 5.1, is context awareness. In this case context awareness refers to the ability for the decision points of the system to know about the behavior of this and other software components in the system, as well as the behavior of the surrounding environment the system is currently working in, in the case of a car this could for example be the 50 CHAPTER 5. STORAGE OF POLICIES IN A REPOSITORY information on if the weather is sunny or if it’s raining where the car currently is located. In Anthony et al’s proposed system this information is provided by the context manager.

5.1.6 Security Just as in the case of a software load, it is obviously very important to ensure that no ”bad” policies enters or executes in the system, thus the system must provide a way to ensure that a policy loaded into the repository is a ”good” one. The area of security has already been discussed in section 4.1.6 about security in the context of software load. The same kind of security aspects are relevant when it comes to adding new policies to the repository. Furthermore there is the area of ensuring that added policies in the repos- itory cannot be altered in an un-allowable way or by an unauthorized person or system component. The Polyhedra RTRDB, used to implement the reposi- tory in the DySCAS demonstrator platform at Enea, allows the administrator of the system to setup different users (with passwords) with different kinds of privileges within the system [33], a helpful feature when implementing a secure policy repository.

5.1.7 Summary As a start IBM’s autonomic computing and different aspects of it has been discussed as an example of what polices can be used for in a computer system, furthermore the concept of policies has been discussed more in detail. Different types of policies have been discussed as well as different approaches to implementing policies within a system. Anthony’s policy description lan- guages AGILE and AGILE-Lite are also discussed. Furthermore, a proposed system architecture for ”embedding dynamic be- havior into a self-configuring critical software system” [34] by Anthony et al has been presented as one possible approach to embed policies in a system. Finally, some aspects of security in the context of policies was discussed. All this to provide a solid foundation for the design of a policy repository within a system.

5.2 Design of the Repository Service

In the DySCAS layered architecture the actual repository will be a part of the Platform layer and could be implemented in a number of different ways by different DySCAS system suppliers. Important is that all communications with it from the middleware should be made through the System API (see section 3.2.2) and that other middleware components should not have to be aware of how the repository has been implemented in the platform, an abstraction that should be handled by the respective instantiation layer. Other middleware components should just use the Repository Service in the middleware, which can be accessed by standardized DySCAS communication, when requesting information from or adding information to the repository. 5.2. DESIGN OF THE REPOSITORY SERVICE 51

This middleware component then calls the Repository Abstraction Module, that is a component made to work with Enea’s RTDB Polyhedra, within the Instantiation Layer, through the Repository System API, that handles the actual communication with the repository. The repository in the Enea implementation will as previously mentioned be Enea’s RTDB Polyhedra. For an application running on top of the DySCAS middleware to be able to use the services of the Repository Service it will have to go through the Repository DySCAS API. Given all this, the middleware service will be of a very general nature, while the abstraction module in the instantiation layer handles the actual calls to the Polyhedra database. For an overview of the designed system see figure 5.4.

Figure 5.4: DySCAS system architecture for the Repository

5.2.1 Implementation of the Repository Service The Repository Service will be implemented as a single centralized service run- ning on the same node as the actual repository has been implemented on. The reason for this, as also presented earlier in section 3.2.3, is that the Polyhedra RTRDB requires communication to be made with it using standardized Polyhe- dra communication, and this is something that can not be allowed between dif- ferent DySCAS nodes where only standardized DySCAS communication should be used.

5.2.2 Retrieving information from the Repository As previously described, both other parts of the DySCAS middleware and ap- plications running on top of the middleware should have the ability to use the 52 CHAPTER 5. STORAGE OF POLICIES IN A REPOSITORY services provided by the Repository Service, however there are some different conditions to take into account for these different kinds of users of the middle- ware component.

Middleware components

As previously discussed the DySCAS middleware should not have to be aware of how the repository has been implemented. Instead the communication between the Repository Service and other parts of the middleware needs to be standard- ized and independent of how the actual repository has been implemented. The internal communication in the DySCAS middleware originally builds on the approach of OSE Epsilon to use direct message passing as the means of internal communication. A middleware component that wants to use services from the Repository Service needs only to use a number of standardized mid- dleware messages1 that it passes on to the service, depending on which of its services it wants to use. The Repository Service will then pass this information on, in a standardized form, to the Repository Abstraction Module in the instantiation layer. Since the Enea implementation will implement the repository as a database the module in the instantiation layer will then be responsible for converting this to an SQL query to pass on to the database, using the API provided by the database. In the standard case it is assumed that middleware components use prede- fined storage rooms in the repository (in the case of a database a storage room would be a separate table in the database) for storing information, however the Repository Service should provide the service of creating a new storage room (a new table in the repository) for middleware services making such a request.

Applications on top of the middleware

For applications to use the services of the Repository Service they will have to go through functions in the DySCAS API. To ensure the integrity of the system, an application should need to be authorized to be able to use the services of the Repository Service. When other middleware components use the services of the Repository Ser- vice it should be assumed that the Repository Service is already familiar with what kind of services the respective middleware component is interested in us- ing, and the needed storage rooms in the repository should per default have been created by the system. This can, however, not be said to be the case if an application running on top of the middleware would want to use the services of the Repository Service. Instead the application would itself be responsible for setting up the storage room it needs with the correct properties, for example a GPS application inter- ested in logging coordinates in the repository would need to tell the repository that it is interested in logging a coordinate, matched with a time stamp, in the repository before it can start to use this service. In the Polyhedra case a table

1Due to secrecy reasons the form of these messages can not be presented in detail, but the middleware component essentially describes which kind of information it wants to store in / retrieve from the repository in an intuitive way and the Repository Service then organizes this information so that it can be easily processed by components in the instantiation layer. 5.3. HOW POLICIES SHOULD BE MANAGED IN THE REPOSITORY 53 in the database, with the properties needed, would need be be created by the Repository Service before data can be stored in it.

5.2.3 Alternative implementation of the Repository As previously discussed the implementation of the repository could be made in a number of different ways, a database is just one way to implement it. As described in section 3.2.1 the Instantiation layer is responsible for solving all dependencies on the underlying platform, and the implementation of the repos- itory is by this master thesis considered to be one such platform component, and hence the instantiation layer components should be made Polyhedra-specific in the reference implementation at Enea, and it is these components that needs to be altered if another kind of repository should be used.

5.2.4 Services provided by the Repository Service There are a number of services that should be provided by the Repository Service to the rest of the system: Insert information It should be possible for a middleware component or an authorized application to insert information into the repository at run- time. Update information Information in the repository should be able to be up- dated by middleware components or authorized applications at run-time. Delete information For middleware components or authorized applications it should be possible to delete information in the repository Retrieve information Middleware components and authorized applications should have the possibility to retrieve information from the repository. Create a new storage room It should be possible for middleware compo- nents or authorized applications to create a new storage room (in the case of Polyhedra a new table in the database) where information can be stored in the repository. These are standard actions that any database application should be able to perform, but as mentioned earlier the Repository Service could also be im- plemented in another way. As long as these operations can be performed the system should not be affected by the implementation of the repository. To ensure the generality of the system the way of triggering these events, through passing certain standardized DySCAS messages to the Repository Ser- vice containing information on the operation to perform, has been implemented in a very general way so that the data in the end could be stored in any kind of database, as well as in a file system.

5.3 How Policies should be managed in the Repos- itory

This master thesis is responsible for the design of the part of the system respon- sible for storing policies (or Decision Configuration Modules (DCMs)) as well 54 CHAPTER 5. STORAGE OF POLICIES IN A REPOSITORY as to deliver these policies to the ”policy engine” (or the Decision Evaluation Module (DEM)).

5.3.1 The Definition of a Policy The implementation of policies in the DySCAS reference platform at Enea will be of policies of the type Action policy as described in section 5.1.2. Each policy will belong to a certain decision point in the system (see section 5.1.5) which is described in the system with each specific decision point having policies with a specific policy name belonging to it. Furthermore to each de- cision point there can be more than one policy belonging to it and these will then be identified with the policy’s policy number. Finally, the system can be in different global states, for example under heavy load or running easily, and this is illustrated with there being different policies for the same decision point under different global states. These three types of information on a policy: global state, policy name and policy number, defines exactly one set of policies for one decision point in one system state. In the implementation each policy will be of a specific compare type (less than, equal to, greater than etc.), describe which two variables that should be compared, where in the system these variables can be found (for example if they are context variables - variables describing the state of the system) and what the outcome of the decision point should be, depending on the outcome of the compare (true or false).

Anthony et al’s AGILE Lite AGILE Lite is a policy expression language developed within the DySCAS project (already presented in section 5.1.4) and it would obviously be very in- teresting to implement this framework in the reference platform at Enea. However, since the policy engine related to this language or the exact XML semantics pertaining to it has not yet been made available it was up to this master thesis to develop such a system from scratch to present the abilities of a policy based autonomous system and a less complex way of doing this, as previously presented in this section, was decided upon. There are however no limitation using the Polyhedra database making it not possible to store larger binaries such as the larger XML-files describing a set of policies that has been created by Anthony et al. Furthermore, the Decision Evaluation Module (DEM) in the DySCAS middleware has also been made in such a way that it could easily be changed to instead run the DEM pertaining to the AGILE Lite policy expression language.

5.3.2 Context Manager This master thesis also has a part in the implementation of the Context Manager in the system (see section 5.1.5). As described by Anthony et al [34] the context manager is responsible for keeping track of the behavior of the system and the surrounding environment it is working in, this could for example be to keep track of how much memory is being used in each ECU in the system and how high the CPU utilization is in each ECU. 5.4. IMPLEMENTATION OF THE REPOSITORY SERVICE 55

In the DySCAS reference platform the Context Manager, or the Resource Manager Service as the middleware service is called, will be connected to the Repository Service since the Repository Service should offer the context manager the possibility to store more long-lived context information in the repository, so that the information can easily be used in the future. The context information can for example be used at a decision point to decide if a certain action within the system should be allowed or not, for example should it not be possible to play music louder than at a certain level while the mobile phone in the car is being used by the driver.

5.3.3 An Active Database

As previously described Polyhedra has the functionality to work as an active database, something this master thesis aims at exploiting in order to provide the policy engine with updates should the type of policy currently being used in the system be updated in any way, or if new policies affecting the system are added at run-time. With active queries this service would be provided to the system by the Polyhedra RTRDB and each time a row was added to the database that matched any active query currently running in the database the content of this new row would be delivered by the database through this active query.

5.4 Implementation of the Repository Service

Enea’s RTDB Polyhedra has been implemented as the repository in the DySCAS demonstrator platform. The design of how the repository should be imple- mented, presented in section 5.2 has been followed and the Repository Service now contains the functionality to provide the system with a number of services.

5.4.1 Polyhedra as an Active Database

The original plan was to implement the active database functionality provided by Polyhedra using Active Queries to ensure that updates of policies, for ex- ample, would always be made available to the part of the system requesting them. This approach could unfortunately not be implemented. The reason being that this proved to be too resource consuming for a system such as DySCAS since a restriction when using active queries is that each active query would require a blocking process of its own, to continually be executing in the microprocessor, keeping track of the particular active query. At the same time another restriction is that each active query can only con- tain one select statement. Thus, for each kind of information in the repository that the system would like to continually monitor a new process would have to be started, something that could not be allowed in a resource constrained system such as DySCAS. 56 CHAPTER 5. STORAGE OF POLICIES IN A REPOSITORY

5.4.2 Repository Service Functionality appertaining to Policies The Repository Service today has the following functionality: Insert information New policies and context information can be added at runtime. Update information An existing policy or context information can be altered by the system at runtime. Delete information An existing policy or context information can be deleted from the system at runtime. Retrieve information When asked, the Repository Service provides the in- terested part of the system with information on policies or with context information. Furthermore, information can be retrieved in two different ways, either just once or using a subscription. It was this subscription functionality that origi- nally was planned to be implemented using active queries, but since this proved impossible an approach using linked lists that enables the Repository Service to provides the same functionality was implemented instead. If another middleware service makes a subscription of a certain set of policies it gets the corresponding policy (or policies) and are listed as subscriber for this type of policy. Thus, if a new policy of this type is added, or changes are made to any policy of this type, the subscribing middleware service will get the new set of corresponding policies sent to it. Figure 5.5 describes how the Repository Service and the underlying layers of the architecture belonging to it has been implemented in the demonstrator platform when it comes to supporting the use of policies in the platform. Middleware components are allowed to use the Repository Service residing in the middleware layer through standardized DySCAS communication (1) and the Repository Service processes the received signal, for example if the signal contains a subscription of a policy the Repository Service is responsible for keep- ing track of the actual subscription. The Repository Service is then responsible for re-arranging the information and passing it on through the System API to components in the instantiation layer (2). The highest order component in the instantiation layer is then responsible for rearranging this into a standardized SQL query and then passes the request on (3) to the module responsible for making the actual query on the Polyhedra database (4). This module then uses Polyhedra’s CallBack API when com- municating with the database. This component is also responsible for taking care of the responses from the database (5) and to finally pass the retrieved information on from the database to the middleware component that made the initial request (6) for the extracted information through standardized DySCAS communication. The above described separation of the functionality in the instantiation layer into two separate modules adds to the portability of the system by making it easy to change the Polyhedra database into another database, and then only having to make changes to the lowest layer component, as long as this new database supports the kind of standard SQL queries used when making operations on the Polyhedra database. 5.4. IMPLEMENTATION OF THE REPOSITORY SERVICE 57

Figure 5.5: How middleware components can use the Repository Service to access Policies

5.4.3 General Repository Service Functionality Besides supporting the storage of policies and related information, and allowing for other middleware components to access these stored policies, the Reposi- tory Service also provides a general storage service to both other middleware components and to applications running on top of the DySCAS middleware. Figure 5.6 shows how an application can use this service. To ensure the integrity of the DySCAS middleware an application would have to go through the DySCAS API to use this middleware service. If a middleware component would want to use the general storage service it is however allowed to access it directly. The Repository Service provides the following functionality:

Create storage room The biggest difference from the storage of for example policies is that while how a policy is stored in the repository is something that is standardized, there is no way for the Repository Service to know what kind of information a random application would want to store in the repository. Hence, the functionality to create a new storage room, in the case of having the repository implemented as a database to create a new table in this database with the correct layout, is provided. Insert information Information can be added in a created storage room dur- ing run time. Update information Information earlier added to a created storage room can be altered during run time. Delete information Information earlier added to a created storage room can be deleted during run time. 58 CHAPTER 5. STORAGE OF POLICIES IN A REPOSITORY

Figure 5.6: How an application can use the Repository Service

Retrieve information When asked, the Repository Service provides the in- terested part of the system with information stored in the created storage room.

This part of the functionality in the Repository Service was added during the final week of this master thesis, and hence there is still room for improve- ments to be made and also more tests should be performed on this component before this functionality can be said to have been finalized, the above described functionality is however offered by the Repository Service.

5.5 Testing of the implemented components

The implemented Repository Service has been used by other parts of the DySCAS middleware in the demonstrator platform for a number of weeks, verifying the functionality of the Repository Service. Furthermore, a number of test- applications, both using the service from the middleware layer and the appli- cation layer - using the respective ways of using the services of the Repository Service - has been produced to verify the behavior of the Repository Service. These test applications has tried to perform both valid and invalid operations on the Repository Service and the results of these tests were all positive. Chapter 6

Merging DySCAS with AUTOSAR

As a side track, the approach of the AUTOSAR standardization shall be looked upon to investigate which requirements that should be set upon the architecture of DySCAS for it to co-exist with AUTOSAR. More specifically, it aims at answering the question what needs to be added to the DySCAS and AUTOSAR architectures respectively for them to be able to co-exist? (Q3)

6.1 Literature Study

This master thesis will investigate the AUTOSAR standardization and, from a DySCAS perspective, identify conflicts and opportunities between the two as well as suggest an approach of how the two systems could be made to co-exist. The more technical aspects of the AUTOSAR standardization is presented in [28] and it is with this document that the discussion of AUTOSAR in this master thesis takes its starting point. This section will first begin with introducing some of the basic concepts of AUTOSAR and then proceed to go into some interesting details of the AU- TOSAR architecture.

6.1.1 Software Architecture Concept With its software architecture the AUTOSAR initiative aims at presenting a standard platform for future vehicle applications. The concept is presented in figure 6.1 and further explained below: A very important concept in the AUTOSAR architecture is the Software Component (SW-C). A SW-C refers to either a hardware of software component that is used within the system to realize a defined functionality. An applica- tion consists of one or (usually) several interconnected components. Another attribute of an AUTOSAR SW-C is that it cannot be distributed over several ECUs but rather needs to be assigned to one ECU. To each SW-C there also exists a Software Component Description, describ- ing the interfaces and other aspects needed to be known for the integration of

59 60 CHAPTER 6. MERGING DYSCAS WITH AUTOSAR

Figure 6.1: The AUTOSAR Software Architecture Concept [28].

the SW-C in a system. This description is done in a standard description format provided by AUTOSAR. AUTOSAR does not provide actual rules for how SW-Cs are to be imple- mented, but rather just a complete description of how SW-Cs are to interact with the system. The Virtual Functional Bus (VFB) is AUTOSAR’s way of separating appli- cations from the underlying architecture of the system. The VFB is an abstrac- tion of the interconnections between different SW-Cs in an AUTOSAR system, providing a way to specify communication between different SW-Cs indepen- dently of the underlying hardware. The System Constraints and ECU Descriptions are needed in order for the SW-Cs to be mapped onto different ECUs and for a system of concrete ECUs to be built, including the configuration and generation of the Runtime Environ- ment and Basic Software (both to be described later) for each ECU. The Runtime Environment (RTE) can be seen as an implementation of the VFB functionality on each specific ECU in the system. It is responsible for providing a communication abstraction to AUTOSAR SW-Cs attached to it using the same interface regardless of which communication channels are being 6.1. LITERATURE STUDY 61 used. The RTE’s task is to make the SW-C independent from the mapping to a specific ECU. The Basic Software (BS) is the standardized software layer in an AUTOSAR system, providing services to the SW-Cs. The basic software will be explained more in detail in section 6.1.2. Figure 6.2 basically describes the work performed in the ”Tool supporting deployment of SW components” part of the software architecture concept of AUTOSAR presented in figure 6.1, i.e. the process of going from a description of the system and its component and and up to executable files to be run on each ECU.

Figure 6.2: The Configuration of an individual AUTOSAR ECU [28].

6.1.2 ECU Software Architecture A description of the Basic Software, and its layered architecture, can be seen in figure 6.3.

Figure 6.3: The Layered Architecture of the Basic Software [28].

The Application layer and the RTE, which has already been defined above, are not a part of the Basic Software - nor is the ”Microcontroller” part of the architecture. The four different layers of the Basic Software are described by AUTOSAR as follows: 62 CHAPTER 6. MERGING DYSCAS WITH AUTOSAR

Microcontroller Abstraction Layer The lowest layer of the BS responsible for making the higher software layers independent of the microcontroller. As a part of achieving this the layer contains drivers with direct access to the internal peripherals of the microcontroller. ECU Abstraction Layer This layer makes higher software layers indepen- dent of the ECU hardware layout; partly by providing interfaces to the drivers of the Microcontroller Abstraction Layer and partly by containing drivers for external devices. Thus, the ECU Abstraction Layer provides APIs to access peripherals and devices both internally and externally to the microcontroller regardless of how these are connected to the microcon- troller. The ECU Application Layer provides the applications with access to I/O signals. Services Layer The highest layer of the Basic Software is also the layer re- sponsible for most of the interfaces to the applications in an AUTOSAR system. More in detail, the service layer offers: • Operating system functionality. • Vehicle network communication and management services. • Memory services. • Diagnostic services. • ECU state management. Complex Drivers Not a true layer as such, the complex drivers are responsible for handling the special functional and timing requirements of the most complex sensors and actuators in the system.

6.1.3 Operating System As described earlier, the operating system in AUTOSAR is a part of the sys- tem services of the services layer. Since a common architecture for all vehicle domains is the goal in AUTOSAR, specifications of the requirements on the op- erating system to be used is presented, though it is assumed that some domains with high demands on the operating system (e.g. the telematics/infotainment layer of a vehicle) may use proprietary OSs with compliant interfaces to AU- TOSAR components. The AUTOSAR document [29] describes the operating system, AUTOSAR OS, that is to be used in an AUTOSAR system. The AUTOSAR OS is described to have a number of features, the two most interesting for this master thesis are the following two: • The AUTOSAR OS is configured and scaled statically. • The AUTOSAR OS is hostable on low-end controllers and without exter- nal resources. The functionality of the AUTOSAR OS is based on the functionality of the OSEK OS, which is a standardization for how to make RTOS:es for vehicles that is widely used within the automotive industry today. Using this approach the AUTOSAR OS will be a system that the automotive industry is already familiar with. The new AUTOSAR OS will also be backward compatible with older OSEK OS compatible applications. 6.1. LITERATURE STUDY 63

6.1.4 Interfaces

In the AUTOSAR architecture three different kinds of interfaces between the different parts of the system are described:

AUTOSAR Interface An AUTOSAR Interface describes the information exchanged between SW-Cs, independently of programming language, ECU or network topology and is to be used when the information sent should be possible to route through a network.

Standardized AUTOSAR Interface A Standardized AUTOSAR Interface is an AUTOSAR Interface but with a standardized syntax and semantics, typ- ically used by the AUTOSAR Services when communicating with the SW-Cs.

Standardized Interface Provides a standardized way of communication, typically defined for specific programming languages, without using the two AUTOSAR Interfaces. Standardized Interfaces are typically to be used between software modules residing on the same ECU.

6.1.5 A static configuration

The AUTOSAR approach described in section 6.1.1 produces a statically con- figured system, as described in [30]. The AUTOSAR Basic Software supports three different configuration classes, where different kinds of configuration can be performed in the different stages:

Pre compile time The preprocessor instructions and code generation has to be performed in this stage.

Link time Constant data outside a software module can be configured after the actual module has been compiled.

Post build time Loadable constant data outside the module can be changed. The difference between this and the link time stage is that now the data has to be located in a specific memory segment that can be altered externally without disrupting other parts of the memory, i.e. the only option offered is to tweak parameters.

Thus, the AUTOSAR configuration is - as opposed to the one in DySCAS - a very static one and it does not allow for software components to be added or removed after compile time.

6.1.6 The finalized AUTOSAR system

Figure 6.4 provides a schematic view of the architecture of the AUTOSAR software on one ECU. It shows the interconnections, through different kinds of Interfaces, between different components in the system, including Applications. 64 CHAPTER 6. MERGING DYSCAS WITH AUTOSAR

Figure 6.4: A schematic view of the software of an AUTOSAR ECU [28].

6.1.7 Summary This section has briefly presented the basics of the AUTOSAR standardization. The software architecture concept has been discussed together with the lay- ered architecture of an AUTOSAR ECU. Furthermore the AUTOSAR operating system and different kinds of interfaces within and into an AUTOSAR system has been discussed followed by a description of the level of staticness in the AUTOSAR standardization.

6.2 Design of a joint DySCAS and AUTOSAR system

This section will present a suggested approach of how the AUTOSAR and DySCAS standardizations should be adapted in order to work together in one vehicle’s embedded system.

6.2.1 Configuration Considerations The biggest contradiction between the two systems is that an AUTOSAR system is configured statically and does not allow any significant changes to be made upon it after compile time (see section 6.1.5) whereas one of the purposes of DySCAS is to allow for changes to the system to be made after its start-up. This contradiction needs to be resolved somehow and the suggestion of this master thesis is to allow for the two kinds of systems to exist together but still to be separated from each other to a big extent, see figure 6.5. 6.2. DESIGN OF A JOINT DYSCAS AND AUTOSAR SYSTEM 65

Figure 6.5: DySCAS and AUTOSAR nodes in one system

On a system overlooking view the DySCAS nodes in the system should manage themselves, just as a stand-alone DySCAS system would, and the same goes for the AUTOSAR nodes in the system. This would allow for the DySCAS nodes to still contain the regular DySCAS functionality, such as the ability to perform a software load or to be controlled by policies, while at the same time the two systems can interact with each other, for example sharing information about the state of the system. It should also be possible for different kinds of nodes to use functionality on each other, for example could an application on a DySCAS node use function- ality provided by one of the AUTOSAR nodes or vice versa. This setup would for example allow for all nodes running basic functionality, and nodes that does not need to have the ability to perform dynamic upgrades or other DySCAS-like functionalities, to be ”AUTOSAR nodes” while the parts of the system where more advanced system functionalities are needed would be ”DySCAS nodes”. While running a certain functionality on a DySCAS node would provide the producer of the specific node with more advanced system services, for example the ability to update the node’s functionality after the point of production, run- ning the functionality on an AUTOSAR node would instead imply lower cost of production for each node, because of AUTOSAR’s higher degree of standardiza- tion and because of its less advanced system services these nodes could also be run on less powerful microcontrollers, again implying lower cost of production.

6.2.2 Communication Considerations If both AUTOSAR and DySCAS nodes are to be able to reside on the same network the communication on this bus needs to be either standardized so that all communication on the bus is made in the same way, or the bus needs to be scheduled so that both systems can use it for its needs. Since a change in the way AUTOSAR has standardized its internal communication is not a likely option the suggestion of this master thesis is to use some algorithm to schedule the bus and to let the two systems use their own means of communication when communicating internally. In the DySCAS reference platform at Enea today, the Node handler on the master node is responsible for scheduling the communication and this master 66 CHAPTER 6. MERGING DYSCAS WITH AUTOSAR thesis suggests that the functionality in the node handler should be expanded, making it responsible for scheduling the bus also when there are AUTOSAR nodes present on it. Furthermore there is the issue of having the two systems communicating with each other over the platform boundaries. In order for communication to be performed in a correct way between different nodes in the system the reference platform at Enea contains a Link Handler. This instantiation layer functionality is responsible for abstracting the communication in the system and to pass messages on to the correct node and process when receiving them. Some similar kind of functionality would be needed in a joint system of DySCAS and AUTOSAR nodes for the communication to be handled between them, and this master thesis suggests that this functionality should be provided by the DySCAS system much in the same way as today. All DySCAS nodes should, just like today, be responsible for registering their services to the link handler, and the functionality of AUTOSAR should be expanded to include registering on the DySCAS name service when any DySCAS nodes are present in the system. The reason for using the DySCAS system as the master system when the two systems are combined together is because of its more dynamic functional- ities that still needs to be considered in a joint system. At the same time the AUTOSAR nodes in the system will not have all these dynamic functionalities, and thus will not have the ability to take these questions into account. Another issue arises because of DySCAS’s more dynamic functionalities - providing the system with the ability to be updated during run-time - could lead into problems if a newly installed functionality in the DySCAS part of the system leads to problems in the AUTOSAR part, so called ”feature interference”. One solution to handling this problem is the one proposed in section 4.2.1 where the old software configuration is stored before an update is performed so that the system can fall-back to this older configuration should any problems with the new configuration appear.

6.2.3 DySCAS Architectural Considerations To be able to communicate with the AUTOSAR-parts of the system, the DyS- CAS nodes would need a part in the instantiation layer responsible for handling the communication, an AUTOSAR abstraction module, illustrated in figure 6.6, that is responsible for handling the actual DySCAS-to-AUTOSAR communica- tion as well as to decide what communication that should be passed on to the AUTOSAR nodes in the system and what should only be kept internally among the DySCAS nodes.

6.2.4 AUTOSAR Architectural Considerations Also the AUTOSAR system architecture needs to be altered in order for the communication with the DySCAS parts of the system to be made possible. This master thesis suggests add-ons to be made to the Runtime Environment (RTE) part of the layered AUTOSAR architecture. As described earlier in section 6.1.1 the RTE is responsible for the communication abstractions in the AUTOSAR nodes. 6.2. DESIGN OF A JOINT DYSCAS AND AUTOSAR SYSTEM 67

Figure 6.6: How DySCAS and AUTOSAR could be made to co-exist

AUTOSAR Interface One part of handling the communication, from the AUTOSAR point-of-view, is to introduce a new kind of AUTOSAR interface (see section 6.1.4), a Standard- ized AUTOSAR to DySCAS interface responsible for the communication from AUTOSAR to DySCAS components in the same system. 68 CHAPTER 6. MERGING DYSCAS WITH AUTOSAR Chapter 7

Results and Experiences

7.1 The new Demonstrator Platform Architec- ture

Figure 7.1 describes the state of the DySCAS demonstrator platform as of De- cember 2007 when this master thesis was finalized.

Figure 7.1: The new state of the demonstrator platform architecture

Compared to the old architecture (see appendixC) a number of function-

69 70 CHAPTER 7. RESULTS AND EXPERIENCES alities has been added and the mapping toward the conceptual DySCAS archi- tecture (see section 3.3) has been further improved by this and the consecutive master theses written at Enea during the fall of 2007. The following sections will present what was to be investigated in the re- spective parts of this master thesis and summarize the results of the work.

7.1.1 Software Load in a Distributed System How should software load be implemented in the DySCAS demon- strator platform? (Q1)

A design of how software load should be implemented both on nodes that does and does not provide the functionality of dynamic linking has been presented by this master thesis but unfortunately time did not permit for all of the design to be implemented in the DySCAS reference platform. The part of software load that was deemed to be most interesting to im- plement was that of performing an upgrade of the software running on a less powerful node in a DySCAS network, one that does not support the function- ality of dynamic linking. Means to upgrade an entire node over the CAN-network has therefore been implemented on the reference platform at Enea running OSE Epsilon. The implementation allows for the user to trigger a running DySCAS system to go into ”receiver mode” using a key switch. When the platform is in this mode the contents of one or more nodes in it can be upgraded from an externally connected device containing the new software upgrade, after which the system can be restarted - now running the upgraded version of the DySCAS system instead.

7.1.2 Repository Service How should a repository be used to store policies within the DySCAS demonstrator platform? (Q2)

The initial plan to implement a repository for storing policies was expanded into implementing a more generalized Repository Service in the DySCAS middle- ware. The Repository Service was implemented using Enea’s real-time database Polyhedra as the actual repository running in the platform layer of the DySCAS architecture while the implementation of how other middleware components use the services of the Repository Service has been kept independent of how the repository was implemented. The implemented Repository Service supports all operations needed by it to ensure that the system can be fully governed by policies, which would create an autonomously behaving system that can react to internal and external events. The Repository Service also allows for both other middleware components and applications running on top of the DySCAS middleware to use its services after having defined what kind of information it wants to store in the repository. While the middleware implementation is platform independent, the instan- tiation layer implementation is not. All possible steps have however been taken to ensure that the code is as portable as possible, so for example only a small work-around needs to be made if the Polyhedra database is to be changed to 7.2. EXPERIENCES 71 another kind of database. The middleware implementation is also portable, in the sense that it easily allows for extensions allowing more components in the middleware to use the services of the Repository Service.

7.1.3 Merging DySCAS with AUTOSAR What needs to be added to the DySCAS and AUTOSAR architectures respectively for them to be able to co-exist? (Q3)

A design of how the DySCAS and AUTOSAR standardizations should be made to co-exist in the future has been presented in the design chapter of this master thesis. Just as was originally planned the works on this topic stayed at the design stages and no implementation in the reference platform at Enea has been made. In short the design suggests that the two systems in the future should be kept as two separate systems running together but on different nodes in the same vehicle electronics system. The mechanisms needed for them to co-exist in this way has been discussed and presented together with what the two stan- dardizations has to offer each other.

7.1.4 Conclusions The implemented software components, both those that are a part of the mid- dleware and also those that allows for a node in the DySCAS demonstrator platform to be updated over the CAN network has been tested in a number of different ways. However, it is of course impossible to test a program completely, so even though a number of bugs in the implemented software components have been found and fixed, there is no way to guarantee that the implemented soft- ware components are fault free. However, after having performed numerous tests on the implemented system, it is in the firm believe of this master thesis that the implemented software components provides the services specified in this document in a well behaved manner.

7.2 Experiences

This section will present the experiences drawn during the work of this master thesis.

7.2.1 Dividing the work into different phases The first few weeks of this master thesis was spent analyzing what work that was to be done by reading official DySCAS documentation, studying the existing reference platform at Enea and reading the previous master theses from the DySCAS project at Enea. In this phase of the work a specification of the work to be performed during the rest of the master thesis was also produced, together with a time table, dividing the rest of the work into three phases: Literature Study, Design and Implementation. Once the actual work started, the planned approach of dividing the work into three phases was not fully followed. The literature study that was planned to five weeks worth of work was kept as planned and the time was spent searching for relevant literature and publications and studying these. This work also fell 72 CHAPTER 7. RESULTS AND EXPERIENCES into a literature study report, presenting the results of the study, as well as a presentation at Enea for the persons related to the project. Once the literature study was over, however, the time plan was not followed exactly as was planned but rather after a week and a half of the planned three weeks of design the need to start implementing parts of the design to confirm or discard the initial ideas was felt. To start the initial stages of the implementation phase earlier than first planned turned out to be a very good approach since some ideas for the design could be elaborated further while some could be discarded - for example the plan to use active queries when fetching information from the Polyhedra database. Since these first trial-implementations turned out to be so helpful in the work of designing, the design and implementation stages were subsequently merged together into one joint stage.

7.2.2 Concurrent Programming and Revision Control Working a number of people on the architecture of one common software system has had some implications on how the work of this master thesis could be carried out. The OSE Epsilon platform has been developed using the Tasking VX-toolset for C166 from Altium. While Tasking offers an easy-to-use development en- vironment it has the disadvantage that it makes it extremely difficult for two persons to work on the same code base on two different computers. Instead the decision was made to separate the code, so that each person in the project worked with implementing their parts to the DySCAS system archi- tecture separately, and then these different code bases were manually merged together a number of times during the course of the work. After each one of these merges the code was labeled and checked into IBM’s Rational Clear Case revision control system. Rational Clear Case also has the functionality to merge different code bases together but this functionality was not used. Instead, the work of merging the code base into one set of DySCAS code was done manually. This merge worked without any major obstacles. However, the work would have been even smoother should Rational Clear Case have been used more extensively.

7.2.3 Working separately in a bigger group toward a com- mon goal This master thesis has been the work of one individual, but at the same time there has been six people working concurrently on different parts of the DySCAS demonstrator platform at Enea and thus many valuable discussions could be held over how different parts of the system should be designed and implemented in the best possible way. This way of working individually, while at the same time being surrounded by other people with a common interest in and knowledge of the project, proved to be extremely helpful both in terms of spawning new ideas of how parts of the design and implementation would best be made and in terms of getting support when working with complex issues. Chapter 8

Future work

Due to the time constrained nature of working on a master thesis not all ideas presented by this master thesis could be implemented in the DySCAS demon- strator platform at Enea. This chapter will present the most interesting parts that were left unimplemented as well as some topics that arose during the course of the work, and that were left untouched.

8.1 Connecting the two demonstrator platforms

A number of interesting opportunities would arise if the two demonstrator plat- forms at Enea (the OSE Epsilon one and the Linux one) were interconnected, however this is something that was outside of the scope of this master thesis to investigate further. This would for example make it possible to use the services offered by the Repository Service also on the weaker nodes running OSE Epsilon, where such a service otherwise would not be possible to implement.

8.2 Upgrade Server

As described in section 4.2.1 the functionality of the Repository Service could be expanded to allow for old or new software configurations to be stored within it. In the case of having the repository implemented as a database this information could be stored either as binary data or if also a file system exists in the system only a reference to a location in the file system, where the old software module is stored, could be stored in the database. Using an Upgrade Server within the system, as described in section 4.1.4, together with Infineon’s CAN flashing approach (see section 4.1.4) would add the ability to store the old configuration on a node before replacing it with a new one, so that the system could use this as a safe fall-back if any problems should arise with the newly updated application.

73 74 CHAPTER 8. FUTURE WORK

8.3 Versioning of Software Load components

One part of software load that has not been discussed in this master thesis is the issue of versioning. If old configurations are to be stored in the upgrade database a system of how to keep track of versions of a certain software component needs to be elaborated. This system could also be used during an update, where for example a new software component to be installed might require another software component in the system to be of a certain version in order to function correctly.

8.4 Security and Software Load

The security aspects of a software load are extremely vital to ensure the integrity of the underlying system. While this master thesis has just briefly touched upon the subject by mentioning a number of interesting ISO standardizations, further work in the area and possibly the implementation of one or more of these security standards in the demonstrator platform are left for the future.

8.5 Versioning of Policies

Functionality making it possible to update the entire set of policies stored in the repository, but still keep the old version for a possible reuse in the future, should be added to the demonstrator platform. This should be relatively easy to implement in the demonstrator platform residing at Enea today, adding a new column in the database where the policy version can be stored and making smaller changes in the Repository Service and the related components so that either the newest or a specific version of a set of policies can be extracted from the repository.

8.6 AUTOSAR

The work on AUTOSAR stayed at the design phase, as was decided from the beginning of this master thesis. It would however be extremely interesting to work with a system consisting of both AUTOSAR and DySCAS nodes and, in practice, try to make these work together. This is however a project with a huge scope and far beyond that of this master thesis. Bibliography

[1] High-level group on Embedded Systems, Building Artemis,(http://www. research.thalesgroup.com/software/embedded software and solutions/ building artemis final report en.pdf ). [2] Internal DySCAS consortium document: DySCAS Existing Technologies (D1.1), Lead contractor for deliverable: The University of Greenwich (Richard Anthony), August 2007. [3] DySCAS website, (http://www.dyscas.org), August 2007. [4] R Anthony, A Retterberg, O Redell, T Qureshi, M T¨orngren,C Ekelin and G deBoer, Dynamically Reconfigurable Automotive Control Systems, at ”Advanced Automotive Electronics” in Gaydon, UK, January 31 2007. [5] Internal DySCAS consortium document: DySCAS Scenario and System Requirements (D1.2), Lead contractor for deliverable: Daimler Chrysler AG (Viktor Friessen), August 2007. [6] R Anthony, A Leonhardi, C Ekelin, D Chen, M T¨orngren,G de Boer, I Jahnich, O Redell, A Weber and V Vollmer, A Future Dynamically Recon- figurable Automotive Software System, at ”Elektronik im Kraftfahrzeug”, Dresden, Germany, June 27-28 2006. [7] IBM, An architectural blueprint for autonomic computing, (http://www.ibm.com/ ), April 2003. [8] Jeffrey O. Kephart and David M. Chess, The Vision of Autonomic Com- puting, IEEE Computer Society, January 2003. [9] AUTOSAR website, (http://www.autosar.org), August 2007. [10] Harald Heinecke et al, Achievements and exploitation of the AUTOSAR development partnership, AUTOSAR Partnership 2006. [11] Malin Grudeholm, Analysis and design of real-time database Polyhedra in the DySCAS architecture platform, A master thesis written at the Royal Institute of Technology, Presented in June 2007. [12] Polyhedra product documentation: Enea Polyhedra - Polyhedra Overview, (http://www.enea.com), Version 7.0.2. [13] Isabell Jahnich and Achim Reterberg, Toward Dynamic Load Balancing for Distributed Embedded Automotive Middleware, at ”International Embedded Systems Symposium” in Irvine, CA, USA, May 29-June 1 2007.

75 76 BIBLIOGRAPHY

[14] Internal DySCAS consortium document: DySCAS System Architecture (D2.1), Lead contractor for deliverable: The Royal Institute of Technol- ogy (DeJiu Chen), August 2007. [15] David E. Simon, An Embedded Software Primer, Addison-Wesley, 1999. [16] John Levine, Linkers and Loaders,(http://www.iecc.com/linker/ ), Morgan-Kaufman, 2001. [17] Manfred Stadel, Object-Oriented Programming Techniques to Replace Soft- ware Components on the Fly in a Running Program, ACM Sigplan Notices, Vol. 26, No. 1, January 1991. [18] Jeff Kramer and Jeff Magee, Dynamic Configuration for Distributed Sys- tems, IEEE Transactions on Software Engineering, Vol. SE-11, No. 4, April 1985. [19] Sameer Ajmani, Barbara Liskov and Liuba Shrira, Modular Software Up- grades for Distributed Systems, European Conference on Object-Oriented Programming (ECOOP), July 2006. [20] Arthur L´eger, Bertil Folliot and Damien Cailliau, Platform for Software Reconfiguration in Embedded Systems, European Research Seminar on Ad- vances in Distributed Systems, May 2001. [21] Infineon Technologies, Programming an external flash memory via the CAN bus,(http://www.infineon.com), Application Note, V1.0, July 2001. [22] The United States Environmental Protection Agency - On-Board Diagnos- tics (http://www.epa.gov/obd/questions.htm), September 6, 2007. [23] The OBD II Home Page, (http://www.obdii.com), September 6, 2007. [24] Damien Cailliau and Remy Bellenger, The Corot Instrument’s Software: Toward Intrinsically Reconfigurable Real-time Embedded Processing Soft- ware in Space-borne Instruments, 4th IEEE International Symposium on High-Assurance Systems Engineering, 1999. [25] Jeffrey O. Kephart and William E. Walsh, An Artificial Intelligence Per- spective on Autonomic Computing Policies, Proceedings of the 5th IEEE International Workshop on Policies for Distributed Systems and Networks, 2004. [26] Richard John Anthony and Cecilia Ekelin, Policy-driven self-management for an automotive middleware, at ”First International Workshop on Policy- Based Autonomic Computing (PBAC 2007)” at the ”Fourth IEEE Inter- national Conference on Autonomic Computing”, in Jacksonville, Florida, USA, June 11-15, 2007. [27] Richard John Anthony, The AGILE Policy Expression Language for Auto- nomic Systems, International Transactions on Systems Science and Appli- cations, 2006. [28] AUTOSAR Technical Overview (2.0.1),(http://www.autosar.org), June 2006. BIBLIOGRAPHY 77

[29] AUTOSAR Specification of Operating System (2.0.1), (http://www.autosar.org), June 2006.

[30] AUTOSAR Layered Software Architecture (2.0.0), (http://www.autosar.org), March 2006. [31] Intel, Hexadecimal Object File Format Specification, (http://www.intel.com), Revision A, January 6, 1988. [32] Christophe Bidan, Val´erieIssarny, Titos Saridakis and Apostolos Zarras, A Dynamic Reconfiguration Service for CORBA, In Proceedings of the Fourth International Conference on Configurable Distributed Systems, IEEE Com- puter Society Press, May 1998. [33] Polyhedra product documentation: Enea Polyhedra - Real-Time Relational Database,(http://www.enea.com), Version 7.0.12.

[34] Richard Anthony, Paul Ward, Mariusz Pelc, James Hawthorne, Embed- ding dynamic behavior into a self-configuring critical software system, Dept. Computer Science, The University of Greenwich, September 2007. 78 BIBLIOGRAPHY Appendix A

Abbreviations

The purpose of this section is just to provide a means to gather up all the used acronyms in this report, to make it easier for the reader.

AI Artificial Intelligence API Application Programming Interface AUTOSAR AUTomotive Open System ARchitecture

BS Basic Software (in AUTOSAR)

CAN Controller Area Network CL Control Language (in Polyhedra) CLC Control Language Client (in Polyhedra)

DCM Decision Configuration Module DEM Decision Evaluation Module DySCAS Dynamically Self-Configuring Automotive Systems

ECU Electronic Control Unit ELF Executable and Linking Format

GUC Generic Use Cases

HEX HEXadecimal object file format

OBD On-Board Diagnostics OEM Original Equipment Manufacturer

REE Reconfiguration Execution Engine RNRM Realm Network Resource Management RTDB Real-Time DataBase RTE RunTime Environment (in AUTOSAR) RTOS Real-Time Operating System RTRDB Real-Time Relational DataBase

i ii APPENDIX A. ABBREVIATIONS

SF System Functionality SQL Structured Query Language (in Polyhedra) SQLC Structured Query Language Client (in Polyhedra) SR System Requirements SUC Specific Use Case SW-C SoftWare-Component (in AUTOSAR)

UD Upgrade Database UL Upgrade Layer US Upgrade Server

VFB Virtual Functional Bus (in AUTOSAR) VIS Vehicle Information System

QoS Quality of Service

XML eXtensible Markup Language

This sentence was intentionally made white. Appendix B

The DySCAS Demonstrator Platform

This is a graphical representation of the DySCAS demonstrator platform as of the starting date of this master thesis.

Figure B.1: The existing DySCAS demonstrator platform

iii iv APPENDIX B. THE DYSCAS DEMONSTRATOR PLATFORM Appendix C

Earlier Reference Platform Architecture

Figure C.1 shows the architecture of the DySCAS reference platform at Enea before the start of this and the parallel master theses.

Figure C.1: The Architecture of the DySCAS reference platform as of June 2007

v vi APPENDIX C. EARLIER REFERENCE PLATFORM ARCHITECTURE Appendix D

Demonstrations

One part of the initial pre-study of this master thesis was to suggest one or a number of demonstrations to be recorded for the final presentation at the end of the master thesis. A demonstration should demonstrate the contributions to the the Enea DySCAS reference platform that this master thesis has added, as well as illustrate one or more DySCAS use cases as described in [5]. As the areas that this master thesis is looking into are quite diverse, two different demonstration use cases will be presented.

D.1 Software Load

An entire node in the DySCAS demonstrator platform shall be updated using the CAN-network. The idea is to build upon the Infineon approach as described in section 4.1.4, and to be able to update the contents on one or more nodes in a (CAN) network of nodes by introducing a new ”updater node” into the system through the CAN network.

D.2 Policy Repository

Another parallel master thesis is responsible for the overall architecture of poli- cies within the DySCAS demonstrator platform while this master thesis mainly looks into the area of storing policies in a repository and enable the system to use these policies. The demonstration use case would illustrate a policy change within the sys- tem, where policies are extracted from the repository and then deployed in the system.

vii