Proof of Concept of an Integrated Automotive Architecture

8/13/2019 Proof of Concept of an Integrated Automotive Architecture

1/86

Proof of Concept of an Integrated

Automotive Architecture

Master Thesis

J.G.S. (Johan) van Uden, BSc

Master Automotive TechnologyDepartment of Mathematics and Computer Science

Software Engineering and Technology Research Group

Supervisor:prof.dr. M.G.J. van den Brand

Committee:

prof.dr. M.G.J. van den Branddr.ir. R.J. Brildr.ir. T. Hofman

Final Version

Eindhoven, November 2013


2/86


3/86

Abstract

A little over 30 years ago, in 1977, General Motors (GM) introduced the worlds first ElectronicControl Unit (ECU) in a production vehicle. A few years later (May 1983) an engineer at GMpredicted that software development will become the single most important consideration innew product development engineering. [6]This prediction has proven to be more than true. An

average modern premium production vehicle contains 70 to 100ECUs, which run a total of around100 million Lines of Code (LoC)[10].

A car is no longer just a mechanical machine with a few electronic systems, it has becomea high-tech integrated system which includes various engineering disciplines. This means thatautomotive engineers need new ways of developing modern vehicles. The one-function-one-ECUdesign philosophy, which is still common practice in the automotive industry, will no longer suffice.This design philosophy has led to the fact that a modern car now contains around 100 millionLoC. In order to reduce this enormous amount of software, automotive engineers will have to usea systems oriented approach to develop future vehicles. In the graduation project described in thismaster thesis, a systems oriented approach is used to design an integrated automotive architecture,which contains just fiveECUs. The implementation of a Proof of Concept(PoC) that proves thefeasibility of this architecture is also part of the graduation project.

First, an overview has been presented of the available architectures in the automotive domain.Following, an integrated architecture has been designed that controls every electronic function inthe vehicle by using only fiveECUs. This architecture features localised control, which resemblesa reflex in the human body. This control can yield a substantial performance improvement. Fur-thermore, the architecture provides certain safety related advantages over the existing alternativesby design.

As mentioned above, the designed architecture has been implemented in a PoC, which hasbeen used to prove the feasibility of the architecture. Tests conducted on thePoCvalidated itsfunctional correctness. However, thePoC suffered a lack of performance. Recommendations toovercome this problem are presented, showing the feasibility of implementing the architecture inan actual vehicle.

Keywords: automotive, architecture, systems oriented approach, model based design, software,

real-time systems, embedded systems

Proof of Concept of an Integrated Automotive Architecture iii


4/86


5/86

Preface

This master thesis is the result of my graduation project, which finalises my Automotive Tech-nology master at Eindhoven University of Technology (TU/e). This project has been conductedwithin the Software Engineering and Technology (SET) group of the Mathematics and ComputerScience department. This research is also part of the InMotion project, which has the objective

to design and build a series-hybrid performance vehicle that is able to beat a modern Formula 1car while being durable enough to finish a 24h endurance race.

First of all, I would like to express my sincere gratitude to prof.dr. M.G.J. van den Brand forcoaching me during this project. His feedback, valuable advice and the useful discussions helpedme to conduct the research presented in this thesis. Furthermore, I would like to thank dr.ir. R.J.Bril and dr.ir. T. Hofman for their participation in my graduation committee and for taking thetime to assess my research.

I would also like to thank all the team members of InMotion for the wonderful time and thevaluable discussions on different technical topics. Working in such a multidisciplinary team hasbeen a truly valuable experience.

Furthermore, my thanks go out to the people who helped me by reviewing different versions ofthis thesis, and provided me with valuable feedback in order to improve it. I thank Yaping Luo,from theSET group, for the collaboration on the safety argumentation research.

Of course, my special thanks go out to my parents and two sisters for their continuous support.The achieved result wouldnt have been possible without them. The same holds true for mygirlfriend Anne van Dijk, who has supported and motivated me during my entire study at theTU/e.

Johan van UdenEindhoven,November 2013

Proof of Concept of an Integrated Automotive Architecture v


6/86


7/86

Contents

Contents vii

List of Figures ix

List of Abbreviations xi

1 Introduction 11.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Project Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Research Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Research Method and Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Preliminaries 52.1 One-Function-One-ECU Design Philosophy . . . . . . . . . . . . . . . . . . . . . . 52.2 Systems Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Networking Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1 Controller Area Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Time Triggered Controller Area Network . . . . . . . . . . . . . . . . . . . 9

3 Related Work 113.1 From Federated to Integrated Architectures . . . . . . . . . . . . . . . . . . . . . . 113.2 Fully Centralized Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Integrated Architecture on Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Integrated Automotive Architecture 154.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Hardware Topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.5 Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.6 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Proof of Concept 235.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Active Aerodynamics System . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.2 Anti-Lock Braking System. . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.1.3 Power Windows System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2.1 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Proof of Concept of an Integrated Automotive Architecture vii


8/86

CONTENTS

5.2.2 Software Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2.3 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2.4 Implementation of the Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6 Validation 396.1 Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1.1 Active Aerodynamics Model. . . . . . . . . . . . . . . . . . . . . . . . . . . 406.1.2 Anti-Lock Braking Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.1.3 Power Windows Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.1.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3 Safety Argumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3.1 Goal Structuring Notation (GSN) . . . . . . . . . . . . . . . . . . . . . . . 456.3.2 Semantics of Business Vocabulary and Rules (SBVR) . . . . . . . . . . . . 45

6.3.3 Power Windows Safety Case. . . . . . . . . . . . . . . . . . . . . . . . . . . 456.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7 Implementation 477.1 Towards Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.1.1 Practical Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.1.2 IM01. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2 Beyond Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8 Conclusions and Recommendations 51

Bibliography 53

Appendix 57

A Developed Hardware 57

B Developed Software 58B.1 USB-CAN Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58B.2 CAN Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60B.3 I/O Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

C Simulation Results 64C.1 Simulation results of individual functions . . . . . . . . . . . . . . . . . . . . . . . 64C.2 Simulation results of full system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

D Safety Argumentation 71D.1 Functional Safety Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71D.2 GSN diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72D.3 GSN pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73D.4 GSN diagram with SBVR applied. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

viii Proof of Concept of an Integrated Automotive Architecture


9/86

List of Figures

2.1 Overview of electronic functions in a premium vehicle[24] . . . . . . . . . . . . . . 62.2 SIMILAR process[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Contents of a standardCAN data frame . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Reference point for synchronisation inTTCAN . . . . . . . . . . . . . . . . . . . . 92.5 Basic cycle inTTCAN[41] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6 System matrix inTTCAN[41] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Centralized control architecture in the Formula 1 . . . . . . . . . . . . . . . . . . . 123.2 Integrated architecture on chip [33] . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 High level system architecture for the IM01 . . . . . . . . . . . . . . . . . . . . . . 164.2 Hardware topology for the IM01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.3 High level software architecture for the IM01 . . . . . . . . . . . . . . . . . . . . . 174.4 Mapping of software function parts toECUs. . . . . . . . . . . . . . . . . . . . . . 184.5 Architecture for a software function . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.1 Active aerodynamics system schematic . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 ABSschematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3 Power windows schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.4 Block diagram of hardware used for thePoC . . . . . . . . . . . . . . . . . . . . . 275.5 Microchip MCP2515DM-BM board setup . . . . . . . . . . . . . . . . . . . . . . . 285.6 I/OInterface Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.7 Block diagram of software running on thePoC . . . . . . . . . . . . . . . . . . . . 305.8 Synchronisation mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.9 In- and output signals used by thePoC . . . . . . . . . . . . . . . . . . . . . . . . 345.10 Communication schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.11 CentralECU model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.12 Front satelliteECU model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.13 Rear satelliteECU model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.1 Simulink model used for simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.2 Active aerodynamics control model . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.3 ABScontrol model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.4 Power windows control schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.5 Simulation results of full system model: brake delay . . . . . . . . . . . . . . . . . 436.6 Measurement results onPoC: brake delay . . . . . . . . . . . . . . . . . . . . . . . 446.7 Measurement results onPoC: time triggered communication scheme . . . . . . . . 446.8 Conceptual model of the power windows system. . . . . . . . . . . . . . . . . . . . 46

7.1 Overview of electronic functions in the IM01 . . . . . . . . . . . . . . . . . . . . . 487.2 Hardware topology for a production vehicle . . . . . . . . . . . . . . . . . . . . . . 49

A.1 Schematic of theI/O interface board for the front satellite ECU. . . . . . . . . . . 57

Proof of Concept of an Integrated Automotive Architecture ix


10/86

LIST OF FIGURES

A.2 Schematic of theI/O interface board for the rear satelliteECU . . . . . . . . . . . 57

B.1 Components for theCAN drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

B.2 Structure diagram for theCAN drivers. . . . . . . . . . . . . . . . . . . . . . . . . 58B.3 Sequence diagram for theCAN drivers . . . . . . . . . . . . . . . . . . . . . . . . . 59B.4 Flowchart of original pollingCAN firmware . . . . . . . . . . . . . . . . . . . . . . 60B.5 Flowchart of adapted interrupt basedCAN firmware . . . . . . . . . . . . . . . . . 61B.6 Components for theI/Odrivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62B.7 Sequence diagram for the update of a servos position in theI/O drivers . . . . . . 62B.8 Sequence diagram for an analog to digital conversion in theI/O drivers . . . . . . 63

C.1 Simulation results for the active aerodynamics controller . . . . . . . . . . . . . . . 65C.2 Simulation results for the ABS controller. . . . . . . . . . . . . . . . . . . . . . . . 66C.3 Simulation results for the power window controller . . . . . . . . . . . . . . . . . . 67C.4 Full system simulation input signal . . . . . . . . . . . . . . . . . . . . . . . . . . . 68C.5 Full system simulation calculated internal values . . . . . . . . . . . . . . . . . . . 69C.6 Full system simulation output signals. . . . . . . . . . . . . . . . . . . . . . . . . . 70

D.1 GSNdiagram of power window use case . . . . . . . . . . . . . . . . . . . . . . . . 72D.2 GSNpattern used to create theGSN diagram . . . . . . . . . . . . . . . . . . . . . 73D.3 GSNdiagram of power window use case with SBVRapplied . . . . . . . . . . . . . 74

x Proof of Concept of an Integrated Automotive Architecture


11/86

List of Abbreviations

ABS Anti-lock Braking System

ACK Acknowledge

CAN Controller Area Network

CPU Central Processing Unit

CRC Cyclic Redundancy Check

DLC Data Length Code

ECU Electronic Control Unit

EoF End of Frame

GPS Global Positioning System

GM General Motors

GSN Goal Structuring Notation

HAL Hardware Abstraction Layer

HARA Hazard Assessment by Risk Analysis

HIU Hub Interface Unit

HLR High Level Requirement

I/O Input/Output

I2C Inter-Integrated Circuit

IC Integrated Circuit

ICE Internal Combustion Engine

ID Identifier

IDE Identifier Extension

IFS Intermission Frame Space

INCOSE International Council on Systems Engineering

IP Intellectual Property

LaQuSo Laboratory for Quality Software

LLR Low Level Requirement

Proof of Concept of an Integrated Automotive Architecture xi


12/86

LIST OF FIGURES

LoC Lines of Code

NTU Network Time Unit

OEM Original Equipment Manufacturer

OMG Object Management Group

OS Operating System

OSI Open Systems Interconnection

PC Personal Computer

PoC Proof of Concept

PoP Proof of Product

RTAI Real-Time Application Interface

RTLinux Real-Time Linux

RTOS Real-Time Operating System

RTR Remote Transmission Request

SBVR Semantics of Business Vocabulary and Rules

SET Software Engineering and Technology

SoC System-on-Chip

SoF Start-of-Frame

SPI Serial Peripheral Interface

TDMA Time Division Multiple Access

TTCAN Time Triggered Controller Area Network

TTL Transistor-Transistor Logic

TU/e Eindhoven University of Technology

USB Universal Serial Bus

xii Proof of Concept of an Integrated Automotive Architecture


13/86

Chapter 1

Introduction

This master thesis is the result of a graduation project for the Automotive Technology masterat Eindhoven University of Technology (TU/e). The project is carried out within the SoftwareEngineering and Technology(SET) group of the Mathematics and Computer Science departmentof the TU/e. The SET research group investigates and develops methods and tools for time-and cost-efficient evolution of high-quality software systems. The group has two main researchthemes; Software maintenance and evolution and Theory, methods and tools for model-drivensoftware engineering.

This graduation project is part of the InMotion project. The objective of the InMotion projectis to design and build a series-hybrid performance vehicle, which contains the newest cutting-edgetechnologies and combines various research topics. This vehicle should be able to beat a modernFormula 1 car while being durable enough to finish a 24h endurance race. In order to integrate allthe electronic systems for such a performance vehicle, existing hard- and software architectureswill not meet all requirements. Therefore, a new, model-driven, architecture has been developed

within this project.This chapter will provide an introduction into electronic automotive systems. The context of

this master thesis is given in Section 1.1. The problem is described in more detail in Section 1.2.The goal for this project is given in Section1.3,followed by the research scope in Section 1.4. Thischapter is concluded by a description of the research method and thesis outline in Section 1.5.

1.1 Context

A little over 30 years ago, in 1977, General Motors (GM) introduced the worlds first ElectronicControl Unit (ECU) in a production vehicle. A few years later (May 1983) an engineer at GMpredicted that software development will become the single most important consideration in

new product development engineering. [6] This prediction has proven to be more than true. Anaverage modern premium production vehicle contains 70 to 100ECUs, which run a total of around100 million Lines of Code (LoC)[10].

A car is no longer just a mechanical machine with a few electronic systems, it has becomea high-tech integrated system which includes various engineering disciplines. This means thatautomotive engineers need new ways of developing modern vehicles. The one-function-one-ECUdesign philosophy, which is still common practice in the automotive industry, will no longer suffice.Chapter 2 explains how this design philosophy has led to the fact that a modern car now con-tains around 100 millionLoC. In order to reduce this enormous amount of software, automotiveengineers will have to use a systems oriented approach to develop future vehicles.

Another aspect of the one-function-one-ECU philosophy is that integrating all the differentfunctions in a vehicle creates a complex network of interconnected ECUs. In an average modernvehicle there are multiple networks to interconnect different sets of ECUs. In their turn, thesenetworks are connected through gateways, resulting in a complex network topology for the overall

Proof of Concept of an Integrated Automotive Architecture 1


14/86

CHAPTER 1. INTRODUCTION

vehicle. This makes the testing and debugging upon system integration almost an impossible job.

The avionics industry is a good example of an industry that has embraced the systems approachin an effective way. This resulted in the fact that the Joint Strike Fighter requires about 5.7 million

LoC and the Boeing 787 Dreamliner runs about 6.5 million LoC[10]. This is less than 10% ofthe software that is used in modern premium vehicles. Furthermore, the network topologies ofthese aircrafts have become a lot less complex over the last 30 years because of the use of systemsapproach for developing aircrafts [38].

1.2 Problem Description

As described in the previous section, the way automotive engineers currently design and implementelectronic systems in vehicles is (highly) inefficient and results in large amounts of overhead andcomplex network topologies. If the one-function-one-ECU design philosophy will be used for thedevelopment of future vehicles, the amount of software in a car may increase to half a billionLoC

in the very near future.According to the formula found in the article Number of faults per line of code [27] half

a billion LoC will result in approximately 9.3 million bugs. Because safety is one of the mostimportant aspects in the automotive domain, this increasing amount of code and thus increasingamount of bugs increases the risk of an unacceptable situation.

When each function has its own ECU,complexity of the overall system can simply be dividedover the differentECUs, making the complexity management very straightforward. However, uponintegration of all the different functions, the network topologies become larger and more complex.These large networks lead to an enormous amount of wiring and connectors. Increased wiring addsa lot of weight to the vehicle which makes it less fuel efficient. Furthermore, wires and connectorsare a common point of failure and therefore an increased amount of wires and connectors alsoleads to a less reliable car.

Most of the ECUs in a vehicle are idling a large amount of their lifetime. For instance thesafety-critical airbag controllers are most probably not used for years, but when they are neededthey must react within milliseconds. This means that the hardware for theseECUs needs to bepowerful enough to react real-time, but this processing power is wasted for 99.9% of the time.If these processors would be used for other non-safety-critical low priority tasks during their idleperiod, the hardware in a vehicle could be used a lot more efficiently.

When the aspect of power consumption is considered, measurements show that an averageautomotive ECUconsumes 3.5 watts.1 Given the fact that a modern premium vehicle containsaround 100ECUs, the total power consumption sums up to around 350 watts. Therefore, reducingthe number ofECUs would reduce the power consumption of the overall electronic system, whichwould increase the vehicles fuel efficiency.

1.3 Project Goal

The ideal future avionics system would combine the complexity management advantages of thefederated approach, but would also realise the functional integration and hardware efficiency be-nefits of an integrated system. [19]This quote by Robert Hammett from 2002 applies seamlesslyto the automotive domain and therefore forms a solid base for the project goal. The main researchquestion for this graduation project is:

Is it possible to design and implement an architecture that minimises the number of ECUs ina vehicle, while maintaining the functionality of a one-function-one-ECU architecture?

The main objective is to prove the possibility of such an architecture by implementing a Proof of

1Measurements conducted on a Bosch Motronic MP3.1 ECU at a supply voltage of 14 volts.

2 Proof of Concept of an Integrated Automotive Architecture


15/86

CHAPTER 1. INTRODUCTION

Concept (PoC). Furthermore, the goal is to use standardised hardware components for implement-ing thePoC, because standardising the hardware leads to a cost reduction and has several otheradvantages that are described in Chapter 4. ThePoCwill also be used to conduct experiments

and perform measurements concerning certain predefined metrics. Based on the analysis of thesemetrics, the feasibility of this architecture will be indicated.

1.4 Research Scope

The main research question, described in the previous section, can be divided into a number ofsub questions, which together form the scope of the project. Each of this sub questions will becovered in a separate chapter:

What efforts have already been made to create an integrated architecture? Chapter3

What would a desired integrated automotive architecture look like? Chapter4

What is needed to prove the feasibility of the proposed integrated architecture? Chapter5Does the PoC meet the requirements? Chapter6

What improvements should be made to the PoC in order to implement the proposed integratedarchitecture in an actual vehicle? Chapter7

1.5 Research Method and Thesis Outline

To satisfy the project goal, the following research steps are taken:

Perform a structured literature reviewA literature study has been conducted to investigate existing results and form a clear viewon what research has already been conducted in the scope of this project. This leads to

an overview of the current state of technology in the area of architectural design in theautomotive domain. The results of the literature study are presented in Chapter 3.

Design an integrated architectureChapter 4 contains the architectural design that has been developed and the main designconsiderations that have been taken into account. In order to follow the systems orientedapproach, important aspects of the designed architecture are also discussed in this chapter.These aspects are performance, safety and security.

Design and implement a Proof of ConceptTo prove that the designed architecture is an achievable solution, a PoChas been built.Chapter5contains a description on how thisPoChas been implemented and a discussionon the design considerations. Furthermore, descriptions of the use cases that are defined for

thePoCare given.Validate architecture and Proof of Concept

ThePoChas been simulated and tested. The results of these simulations and tests are usedto validate the architecture and PoC. This process is described in Chapter6.

Perform an analysis on the realisation of the designed architecture in a vehicleBecause thePoC is created to discuss and prove the feasibility of the architecture, this isnot yet an actual realisation. Chapter7describes the steps that need to be taken and theproblems that have to be overcome in order to implement the proposed architecture in avehicle. This has been done for both the IM01 racing vehicle and for a premium productionvehicle.

Conclude

Chapter8 contains the conclusions that can be drawn from this project and the results.



16/86


17/86

Chapter 2

Preliminaries

This chapter describes the preliminary concepts that are used throughout this thesis. These pre-liminary concepts contain technologies and principles which are outside the scope of the graduationproject, but which are used within the project to base the research upon. An explanation of theone-function-one-ECU design philosophy, which is the main reason behind the problem describedin the previous chapter, is given in Section2.1. Section2.2describes the systems approach, whichis a way of designing systems top-down as a whole, rather than the sum of the individual parts.This approach has been proven to be a part of the solution in other industries. This chapter isconcluded by Section2.3,which gives a brief introduction to the networking technologies that areused for this graduation project.

2.1 One-Function-One-ECU Design Philosophy

The one-function-one-ECU design philosophy, which is currently used in the automotive industry,is an artifact of the factorization of the global automotive market. Todays car manufacturersfunction as Original Equipment Manufacturers (OEMs), whose main task is to integrate all thesystems that are supplied by external suppliers into their vehicle. These suppliers are called Tier1 suppliers and some well known examples are Denso, Valeo and Bosch. Because the source codethat is part of a system is Intellectual Property (IP)of its Tier 1 supplier, the OEMsand othersuppliers do not get to see this code. This means that the development, integration and testingneeds to be done with a black box model of these systems. These black box models usuallyconsist of a list of specifications and interfaces[8]and are supplied as complete embedded systemscontaining both the hardware and the software. As theOEMs integrate all the black boxes in thevehicle, each function is represented by a certain black box. Because each black box comes withits ownECU,each function in the vehicle ends up having its own private ECU, this is called a

federated architecture.Figure2.1shows an example of the electronic functions in a modern premium vehicle. A lot

of these electronic functions could use the same software subfunctions. For example a softwaresubfunction that calculates the vehicle speed could be reused by functions like the instrumentcluster, electronic stability control, adaptive cruise control, etc. With the one-function-one-ECUdesign philosophy, instead of reusing the same subfunction, it will be duplicated by all the systemsthat use it, with possible conflicts in functionality. In this way a lot of overhead and unnecessaryLoCare introduced in the vehicle.

The advantage of the one-function-one-ECU design philosophy is that the unit testing of differ-ent systems is very straightforward. Each system can be tested and changed individually, withoutaffecting any of the other systems, as long as there are no dependencies between them. Therefore,this design philosophy proved to be very beneficial a couple of years back, when vehicles stillhad a limited number of electronic functions. However, when the number of electronic functionsincreased, the dependencies between the functions also increased. Even though unit testing still



18/86

CHAPTER 2. PRELIMINARIES

remained straightforward, problems arose upon system integration.

The one-function-one-ECU design philosophy is furthermore characterized by a bottom-upapproach, where a given set of components is integrated by the OEMs into a complete system.This means that for all the desired electronic functions a certain subsystem or component is orderedand the integration phase starts only after all the components are available. After the system iscomposed of the separate components the integrated system will be evaluated. If any componentscause a deviation from the functional requirements, they are changed or the systems configurationis altered. This makes the bottom-up approach a classical iterative engineering approach, whichleads to systems that rarely meet the functional requirements after the first iteration [ 30].

AirbagDeployment

Adaptive Front

Lighting

Adaptive Cruise

Control

Automatic

Braking

Electric

Power Steering

Electronic Throttle

Control

Electronic

Valve

Timing

Idle

Stop/Start

Cylinder

De-activation

Active

Vibration

Control

OBDII

Remote

Keyless

Entry

Blindspot

Detection

Lane

Departure

Warning

Transmission

Control

Seat Position

Control

Electronic

Stability

Control

Active

Yaw

Control

Parking

System Tire

Pressure

Monitoring

Anti-lock

Braking

Regenerative

Braking

Hill-Hold

Control

Active Suspension

Active Exhaust

Noise Suppression

Secutity System

Navigation

System

Digital Turn Signals

Electronic

Toll Collection

Lane

Correction

Battery

Management

Entertainment

System

DSRC

Cabin

Environment

Controls

Voice/Data

Communications

Active

Cabin Noise

Suppression

Interior

Lighting

Auto-Dimming

Mirror

Event Data

RecorderDriver

Alertness

Monitoring

Accident

Recorder

InstrumentCluster

Head-Up

Display

Night Vision

Windshield

Wiper Control

EngineControl Parental

Controls

Figure 2.1: Overview of electronic functions in a premium vehicle [ 24]

2.2 Systems Approach

There are various different definitions of the systems approach. Actually even the definitionof a system is not unanimous. After reviewing various sources, a choice was made to followthe definition proposed by the International Council on Systems Engineering ( INCOSE) for this

project. TheINCOSEdefines a system as follows: A system is a construct or collection of differentelements that together produce results not obtainable by the elements alone. The elements, orparts, can include people, hardware, software, facilities, policies, and documents; that is, all thingsrequired to produce systems-level results. The results include system level qualities, properties,characteristics, functions, behaviour and performance. The value added by the system as a whole,beyond that contributed independently by the parts, is primarily created by the relationship amongthe parts; that is, how they are interconnected. [1].

The systems approach is characterized by a top-down approach. The top-down approach willreduce the systems complexity by decomposing it into separate parts. This process can be appliedto any part of the system. Usually one starts with the system as a whole, after which the processcan be applied to the subsystems that are defined after the first step. This can be repeated inorder to create various levels of system hierarchy. This will finally result in a decomposition of thesystem in the low-level parts[30]. By following this approach, the relationship among the parts isautomatically generated by the process.



19/86


The systems approach is also characterized by being multidisciplinary. In order to take everyaspect of a system into account, different technical disciplines are involved. AsINCOSEstatesin their definition of a system, the added value of a system as a whole lays in the relationship

between the parts. Therefore, it is very important that a team of multidisciplinary engineerswork together to make sure all viewpoints on these relationships and all aspects of the system areconsidered. Because it is important to consider every aspect of the system, the systems approachis also characterized as being heuristic.

Terry Bahill and Bruce Gissing [4]defined the SIMILAR process, which has later been adoptedby theINCOSEfellows [1] to describe the systems engineering process. The SIMILAR processis shown in Figure2.2and the acronym stands for: State, Investigate, Model, Integrate, Launch,Assess and Re-evaluate. The SIMILAR process has also been followed for this project, howeverthis process should not be followed in a sequential way. It is an iterative process and some of thesteps need to be executed in parallel.

Figure 2.2: SIMILAR process [4]

The first step of the SIMILAR process, stating the problem, has been described in Chapter1. Secondly the existing alternatives have been investigated and are described in Chapter3. Theproposed system has been modelled and described in Chapter 4, in this chapter the heuristicapproach has been used by taking into account multiple important aspects. Both the integration

and launching of the system are part of Chapter 5, this chapter also contains additional parts ofthe modelling process. Finally the performance is assessed, the results of that assessment can befound in Chapter6. The re-evaluation of the system altogether is part of Chapter 7.

2.3 Networking Technologies

In order to interconnect the various ECUs in a vehicle, different networking technologies areavailable. However only the ones which are used to base the research for this graduation projectupon will be discussed in this section. These technologies are Controller Area Network(CAN)and Time Triggered Controller Area Network (TTCAN) and have been used to realise the PoC.The reasons for using these specific technologies will be discussed in Chapter 4. Other networkingtechnologies that are needed for the implementation of the designed architecture in an actual

vehicle will be discussed in Chapter7.

2.3.1 Controller Area Network

CANis a communication bus that is widely used in the automotive domain and has become anindustry standard over the last years. CANhas been developed to have a few very importantproperties for automotive applications, especially in the field of reliability and robustness. Forinstance CAN features a low latency, network-wide bus access priority, instant bit monitoringand control features to recover from frame errors [14]. Amongst others, these features have leadto the fact that CAN has become one of the most used vehicle network technologies in todaysautomotive industry.

A brief overview of the properties ofCANwhich are used throughout this thesis are given in thissection. For a comprehensive description ofCANthe reader is referred to the ISO-11898 standard[40]. The information in this section is based on this standard. The ISO-11898 standard describes



20/86


the data link layer and some aspects of the physical layer of the Open Systems Interconnection(OSI) reference model [16].

ACANmessage is called a frame and four types of frames are defined: data frame, remote

frame, error frame and the overload frame. The data frame is the only type that is relevant forthis thesis. Each frame on the bus has an unique Identifier (ID), which also represents the priorityof the frame. The lower the numerical value of theID, the higher the priority of the frame. CANuses two types of data frames: standard data frames and extended data frames. The former usesIDs that consist of 11 bits, while the latter uses 29 bits long IDs, enabling more uniqueIDs on asingle bus. In this thesis only standard data frames are being used. The contents of a standarddata frame, which consists of at least 52 bits, are shown in Figure 2.3 and consists of the followingfields:

Start-of-Frame (SoF) = 1 bit (logical 0)

Arbitration field = 12 bits

Identifier (ID) = 11 bits

Remote Transmission Request (RTR) = 1 bit (logical 0)

Control field (CTRL) = 6 bits

Identifier Extension (IDE) = 1 bit (logical 0)

Reserved = 1 bit (logical 0)

Data Length Code (DLC) = 4 bits (Number of bytes in the data field)

Data field (DATA) = 0 64 bits (Divided in 0 8 bytes)

Cyclic Redundancy Check field (CRC) = 16 bits

Cyclic Redundancy Check (CRC) = 15 bits

CRC-Delimiter = 1 bit (logical 1)

Acknowledge field (ACK) = 2 bits

ACK-Slot = 1 bit

ACK-Delimiter = 1 bit (logical 1)

End of Frame (EoF) 7 bits (logical 1)

Intermission Frame Space (IFS) 3 bits, minimum bits before next SoF (logical 1)

Figure 2.3: Contents of a standardCAN data frame

The physical connection of aCAN bus consists of two wires, on which bits are transmitted aseither ones or zeros. The bits are represented by Transistor-Transistor Logic ( TTL) voltage levels,in which a logical 1 is represented by a level of 5 volts and a logical 0 by 0 volts. The dominant



21/86


bit (the bit with the highest priority on the line) is the logical 0. When the bus is idle, the linesare kept at the 5 volt level (logical 1). ACANcontroller can start the transmission of a framewhenever the bus is idle. TheCANarbitration mechanism that is used when two controllers start

transmission at the same time is a bitwise logical AND between the two arbitration fields of theframes. In this way, if one of the bits is a logical 0, the resulting bit on the bus is a 0. Onlywhen both bits are a logical 1, the resulting bit is a 1. If a controller senses that the resultingbit is different from the bit it wants to transmit, it gives up transmission since it has lost thearbitration. Therefore, the frame containing the most consecutive zeros from the beginning ofits arbitration field wins the arbitration. The frame with the most consecutive zeros from thebeginning is also the frame with the lowest numerical ID,hence the frame with the highest priority.

The most important fields that will be used and varied throughout this thesis are the data,control and arbitration fields. The other fields will be generated automatically by the CANcontroller, based on predefined settings and are therefore not explained in further detail in thissection.

2.3.2 Time Triggered Controller Area Network

Within this project, principles defined in theTTCANstandard are used for synchronisation. Thissection describes the relevant synchronisation properties ofTTCAN, a comprehensive descriptionofTTCAN can be found in the ISO-11898-4 standard [41]. The information in this section isbased on this standard.

The main objective of TTCAN is to keep the latency of each frame at a specified value,independent of theCANbus load. The time unit inTTCANis called a Network Time Unit (NTU).ISO-11898-4 defines two levels ofTTCAN: level one, in which each node runs an individual timerthat countsNTUs, which are defined by the bit time on the bus and level two, in which a conceptof Global time is introduced and a NTUis a fraction of a physical second. Level one basicallyresets the individual clocks to zero at a certain time, but because not every individual clock has avery small rate deviation, drift is introduced. Level two offers a mechanism to constantly adjustthe rate of each clock, creating a system that is perfectly in sync.

In order to implement level two, specificTTCANcompatible hardware is required, which is notcommonly available. TTCANlevel one can be implemented in software on each CANcontrollerthat is able to run in one-shot mode. In one-shot mode the controller does not try to retransmitaCANframe after the arbitration has been lost. Furthermore, theCANcontroller needs to beequipped with a local timer. Because standardCANhardware is used in this project, only levelone will be explained in this section.

On aTTCANbus, the time master is responsible for the synchronisation. This time mastersends a reference frame periodically in order synchronise the individual clocks of the nodes.

Figure 2.4: Reference point for synchronisation inTTCAN

Each bit on the CAN bus has a certain nominal bit time, which is divided into four phases:synchronisation, propagation, phase 1 and phase 2. The duration of each phase is the same for allcontrollers on a bus, but can be adjusted per CAN bus. The sample point of each bit is locatedbetween phase 1 and 2. When looking at the very first bit of a CANframe, theSoFbit, the samplepoint of that bit is used as a reference point in the TTCANprotocol. This is shown in Figure2.4.



22/86


At eachSoFbit that is received by the CANcontrollers, the value of the local timer is saved atthe reference point. If thisSoF bit turned out to be the SoFof the time masters reference frame,this value is used to adjust the local timer.

A TTCAN schedule consists of a basic cycle, which is shown in Figure 2.5. A basic cyclestarts with the reference frame of the time master, and contains several time windows. Each timewindow is reserved for a specific message, however it is possible to introduce arbitrating windows.In these windows the normal arbitration mechanism ofCANallows controllers to send event baseddata. Furthermore, it is possible to add free windows into the schedule, for enhanced flexibility.These windows can be filled later on, without the need for an entire new basic cycle. Each cycleends with the beginning of the next one, marked by the reference frame.

Figure 2.5: Basic cycle inTTCAN[41]

Not each basic cycle needs to be the same. Several different cycles together can form a systemmatrix, as shown in Figure 2.6. The matrix consists of several different basic cycles, which allcontain a different windows. In this way it is possible to implement a message that needs to betransmitted at a high frequency (in every cycle of the matrix), together with messages that onlyneed to be transmitted once in each matrix. This matrix needs to be known by all the controllersthat are connected to theTTCANbus.

Figure 2.6: System matrix in TTCAN[41]



23/86

Chapter 3

Related Work

This chapter contains the results of a literature study that has been conducted in order to get aninsight in the related work that has been done in the field of software and system architectures inan automotive context. The main question answered in this chapter is: What efforts have alreadybeen made to create an integrated architecture?

Section3.1describes the need to evolve from a federated to an integrated architecture in theautomotive domain. Section3.2describes the architecture that is currently being used in Formula1 racing. An architecture that combinesECUs by integrating them on a System-on-Chip (SoC)is described in Section3.3. This chapter is concluded in Section 3.4, which gives a brief overviewof the existing alternatives that have been realised in order to create an integrated automotivearchitecture.

3.1 From Federated to Integrated Architectures

The traditional federated electronic architectures, created by following the one-function-one-ECUapproach, suited the automotive industry for a long time. A lot of control systems used to bemechanical or hydraulic, and electronic functions were basic and independent. Electronic functionsused to have their own (limited number of) sensors and actuators, and straightforward controlstrategies. Modern cars contain an increasing number of electronic functions, both to replace theirmechanical and hydraulic predecessors[33]as well as to implement complete new functionality. Notonly the number of electronic functions increases, but the functions themselves are also becomingmore complex. This increasing complexity is due to the use of a larger number of sensors andactuators, and more complicated control strategies. Furthermore, the electronic functions are nolonger independent, but they share their resources, such as sensors and actuators, and communicatean increasing amount of information among the network resources [ 13]. For instance the active

aerodynamics control uses the wheel speed and brake pressure sensors as input, which are alsobeing used by other functions like the Anti-lock Braking System (ABS) and are therefore notindependent. A modern vehicle nowadays contains around 270 of these functions[8], of which anincreasing number are interdependent.

The advantage of a federated architecture, when dealing with independent functions, is thestraightforward way of integrating these functions. They can be unit-tested separately becausethey are independent. When the unit-tests are passed, there are no predicted problems with theintegrated system, because the independent functions have proven to work correctly and will notinfluence each other. However, when functions become interdependent, this advantage disappearscompletely.

A study by Mercer Management Consulting and Hypovereinsbank conducted in 2001 [12]predicted a 35% share of the production costs of a vehicle in 2010, due to the electronic systemsand software. Furthermore, it is stated in various literature sources [ 25], [20], [8]that the electronicsystems make up to 80% of the innovations in a vehicle. This means that cost reductions in



24/86

CHAPTER 3. RELATED WORK

this area of the automotive domain will greatly reduce the total costs of the vehicle. Using anintegrated architecture instead of a federated one, reduces the amount ofECUs and therefore theamount of hardware, housings, wires and connectors. Because the industry standard for in-vehicle

communication networks is theCANbus, and the maximum number ofECUs connected to aCANbus is around 20 (this is explained in Section 2.3.1), the network in a vehicle typically consist ofmultiple CAN busses which are connected through gateways. Using an integrated architecturecan also reduce the number of gateways, reducing the costs even further[13].

3.2 Fully Centralized Control

The current state-of-art in Formula 1 racing, with respect to the architecture of the electronicsystems, is based on a star topology, which is shown in Figure3.1. This system consists of a singlecentralizedECUand four Hub Interface Units (HIUs). The centralizedECUis responsible for thecontrol of every electronic subsystem in the car, while the HIUs only convert Input/Output (I/O)

signals toCAN frames[43].TheseCAN frames are interpreted by the centralECU as normalI/O signals. In this way the

only advantage of theHIUs is the extension of theI/Oports to the four corners of the car, withoutusing a lot of wires to reach these corners and connect all sensors and actuators. The sensors andactuators are connected locally to theHIUs, which in their turn connect through only two CANwires to the centralECU.

Figure 3.1: Centralized control architecture in the Formula 1

This architecture has the advantage of reducing the total number ofECUs to one. However,this system is not a distributed control system since all the intelligence of the control functionsis in a single place. The main drawback of this topology is a very high network load, becauseall theI/Ovalues to control the sensors and actuators are sent through this network. This alsomeans that if a network link fails, all sensor values of the HIUconnected to it are not receivedby the central ECU and that all actuators on that HIU become uncontrollable. This leads to apossible reliability risk if the system is not implemented redundantly. To overcome this problem,in Formula 1 the critical I/O is connected directly to the central controller and theHIUs are onlyused to connect sensors for monitoring the overall vehicle state, which are not critical for theoperation of the car. This reduces the advantage of the HIUs, because the critical sensors andactuators are still connected directly to the central controller.



25/86

CHAPTER 3. RELATED WORK

3.3 Integrated Architecture on Chip

In the article From a Federated to an Integrated Automotive Architecture [33] the architecture

shown in Figure3.2is proposed as a suitable solution to reduce the number ofECUs in a productionvehicle. This architecture is based on multi-core SoCs and thus consists of multiple cores on asingle Integrated Circuit (IC). The cores in this architecture are defined as IP cores, delivered bydifferent Tier 1 suppliers. The advantage of usingIPcores, for the suppliers, is that their IPisprotected whileIPof different suppliers can be combined on a single IC. In this architecture, eachIPcore fulfills the task of a conventional ECUin a federated architecture. In this way a lot ofconventional ECUs are combined together in a single hardware unit. Therefore, this architecturesucceeds in the objective of reducing the total number of ECUs and reducing the costs due tothe amount of hardware. However, the ECUs that are used are far from generic. Since each SoCrepresents some specificECUs, it needs to be customized for each specific vehicle model. The costscould be reduced even further if these SoCare replaced by general purpose Central ProcessingUnits (CPUs) and the customization of each system is done by the use of software blocks instead

of using customized hardware.

Figure 3.2: Integrated architecture on chip[33]

The reason for integrating multiple ECUs in hardware is to create new hardware which isbackwards compatible with existing federated architectures [33]. This enables implementing achange from a federated to an integrated architecture in an incremental fashion. In the first stepa few of the ECUs of an existing vehicle can be combined into a single hardware unit, whileleaving all otherECUs in the vehicle untouched. This makes it easier for the OEMs to actuallyimplement parts of this architecture into existing designs. However, the goal of this graduationproject is not to improve an existing vehicle, but to create a design for an entirely new vehicleusing a systems approach. Therefore, the idea proposed in From a Federated to an IntegratedAutomotive Architecture [33]is a very solid base for the architecture that will be described in the

next chapter.

3.4 Conclusion

This chapter gives an overview of the efforts which have been made in the automotive domainin order to shift from a traditional federated architecture to an integrated architecture. Theresults that have been found in the literature give a view on the current state-of-art and on themain reasoning behind these architectures. The architectures described in these literature sourcesform a solid base to continue the research in order to propose an architecture that minimisesthe number ofECUs while maintaining the functionality of a one-function-one-ECU architecture.All the architectures described in this chapter satisfy a part of this goal, however there are stilldrawbacks that need to be addressed.



26/86


27/86

Chapter 4

Integrated AutomotiveArchitecture

The main question answered in this chapter is: What would a desired integrated automotivearchitecture look like? The starting point for the integrated architecture is based on the resultsof the literature review described in Chapter 3. The overall system architecture is described inSection4.1. This architecture consists of a hard- and software architecture, which are describedin Section4.2 and Section4.3 respectively. The desired properties of the communication protocolare the subject of Section4.4. Because of the heuristic nature of the systems approach, which hasbeen followed in this project, important aspects like performance, safety and security have beentaken into account. Due to the scope of this project these aspects are considered briefly, since anexhaustive research on each of these aspects could be captured in separate graduation projectsthemselves. Firstly, the performance aspect of the proposed architecture is assessed in Section 4.5.

The safety and security aspects are described in Sections 4.6 and 4.7 respectively. Finally, thischapter is concluded in Section4.8.

4.1 System Architecture

While the Formula 1 uses a fully centralized architecture where all the intelligence is located ina singleECUwhich contains all the processing power [43], the desired architecture for the IM01would use distributed control. The main advantage of distributed control is having processingpower available in all nodes. Therefore, certain functions can use localised control, which can becompared to a reflex in the human body. In a reflex muscles are actuated based on local nervesonly, without influence of the brain. Only after the muscle has been controlled, the brain willbe informed. The same principle applies to localised control, where a local actuator is directly

controlled based on the sensor values that are available locally and the central ECUis informedafterwards. Therefore, this kind of control does not only react much faster, it also reduces thenetwork load. The only communication which is needed serves the purpose of informing the centralECU about the action that has been taken, instead of communicating the sensor values to thecentralECU first, waiting for the calculated actuator values and than informing the centralECUonce again on the current status. In order to provide this functionality, all the ECUs in thearchitecture must provide sufficient processing power.

Another architecture that has been proposed combines the different ECUson aSoC[33]. Thisdoes reduce the hardware, but uses very specific hardware for each different implementation. Thereason for this architecture is to support backward compatibility with existing vehicles and feder-ated architectures. Since the IM01 is designed as a complete new vehicle there is no requirementon backward compatibility. Furthermore, the general trend in the automotive domain is to developan increasing amount of software- instead of hardware-based solutions [37]. Therefore, the nextlogical step is to create an architecture that combines the different functions in software instead



28/86

CHAPTER 4. INTEGRATED AUTOMOTIVE ARCHITECTURE

of hardware and thus enabling the usage of general purpose hardware in order to implement thearchitecture.

System

Architecture

Sofware

Architecture

Hardware

Architecture

Satellite ECU

Sofware

Central ECU

Sofware

Figure 4.1: High level system architecture for the IM01

The system architecture for the IM01 is shown in Figure 4.1 and consists of two parts: ahardware architecture and a software architecture. The hardware architecture for the IM01 isgiven by a hardware topology that has already been described by InMotion (and is thereforedepicted in a dashed block) [17] and will be explained in further detail in Section 4.2. Thesoftware architecture consists of two parts which are derived from the given hardware topology.These parts are software for the centralECU and software for the satellite ECUs. The high levelarchitecture for the software is shown in Figure 4.3and a detailed description is given in Section

4.3.

4.2 Hardware Topology

The hardware topology for the IM01 has been the subject of previous research within InMotion[17]. This topology contains a distributed control system that consists of a central ECU and foursatelliteECUs. The satelliteECUs are placed in the four corners of the IM01. This reduces thewiring to the sensors and actuators, because the location of most of the sensors and actuatorsare near one of the vehicles corners. Furthermore, the topology contains two additional functionspecificECUs for practical reasons. These additionalECUs are used for the control of the InternalCombustion Engine (ICE) and for the autonomous driving behaviour of the IM01. TheECUthatis used to control theICEis packaged together with theICEitself and theECUfor the autonomous

driving system still needs to be developed in the future. The reason for this is that the objective ofInMotion is to realise the IM01 as a vehicle that is controlled by a driver first and add autonomousdriving once the vehicle has been realised. Therefore, the additionalECUs will not be consideredas part of the integrated architecture described in this thesis, leading to the reduced topology forthe IM01 which is shown in Figure 4.2. TheECUs are interconnected through a network bus forwhich different options are described in Section4.4.



29/86


Figure 4.2: Hardware topology for the IM01

4.3 Software Architecture

The software for both types ofECUconsist of two layers, the application layer and the OperatingSystem (OS) layer. On the application layer the different functions that will be available in thevehicle will be represented by software blocks. Each function will be split in three parts: the input,process and output part. Typically the in- and output parts will be running on the satelliteECUsand the process part will be running on the central ECU. TheOSlayer consists of a Real-Time

Operating System (RTOS) and the drivers for the differentECU-specific hardware. For the centralECUthis will only be the driver for the communication device. For the satellite ECUs additionalI/Odrivers will be used.

Central ECU Satellite ECU

Generic Hardware Platorm

RTOS

Generic hardware platorm

RTOS

Vehicle level part of funcons

(focus on computaonal power)

Local level part of funcons

(focus on I/O operaons)

Communicaon

Communicaon

drivers

Communicaon

drivers

I/O

drivers

Figure 4.3: High level software architecture for the IM01

The way the parts of a function are mapped to the different ECUs is shown in Figure 4.4.The in- and output part both map to a satellite ECUand the processing part is mapped to thecentralECU. If the left and right satelliteECUin Figure4.4 (containing the green and yellowpart) are the same physicalECUfor a certain function, localised control (as described in Section4.1) becomes possible for that function.

Figure4.5shows a detailed decomposition of a function. A function is executed in a continuousiterative fashion. On the left the input part of a function is shown, which exists of reading the valuesof the sensors that are used for the function. After reading the inputs, optionally preprocessingof the input can be executed, after which the sensor values are communicated. The processingpart receives the (optionally preprocessed) sensor values and starts the processing. In this stepdifferent dependent functions are allowed to interact, by using data from other functions. The



30/86


Central ECU Satellite ECU

Generic Hardware Platorm

RTOS


RTOS

Vehicle level part of funcons

(focus on computaonal power)



Communicaon

drivers

Communicaon

drivers

I/O

drivers

Satellite ECU


RTOS



Communicaon

drivers

I/O

drivers

Funcon

Input Processing OutputSensors

Actuators

Figure 4.4: Mapping of software function parts to ECUs

processed data is sent to the output part of the function, which optionally applies postprocessingto the data in order to control the actuators. A status update of the current actuator values iscommunicated back to the processing part for the next iteration of the process. If and only ifthe in- and output part of a function run on the same satellite ECU,the communication betweenthese parts can skip the processing part, resembling a reflex in the human body. The processingfrom input to output will then take place in the pre- and postprocessing steps.

Input Processing Output

Inputs

Communicaon

Communicaon

Communicaon

Processing*

Outputs

Communicaon

Local control only if in- and output steps run on the same ECU

(Preprocessing) (Postprocessing)

Communicaon

Sensors

Actuators

*Interacon with other funcons possible

Funcon

Figure 4.5: Architecture for a software function

4.4 CommunicationFor the communication between theECUs different network protocols have been considered. Dueto the fact that all electronic control functions will run on the integrated architecture, the com-munication protocol must meet the demands of both safety-critical functions as well as functionsthat are high demanding regarding the data that needs to be transferred, but which are lesssafety-critical. A safety-critical function needs guarantees when looking at the real-time beha-viour (latency and synchronisation) and robustness of the communication protocol, while a lesscritical high demanding function may impose requirements on the available bandwidth [7].

In an event based protocol messages are being sent arbitrarily (whenever a certain event occurs)and there is no synchronisation between the connectedECUs. Since messages are sent arbitrarily,collisions on the network bus can occur if multiple ECUstry to access the bus at the same time.Each time a collision is detected messages with a lower priority will have to wait for the messageswith a higher priority. Therefore, no guarantees can be given on the message latency, unless the



31/86


message has the highest possible priority on the bus. The advantage of an event based protocol, isthe systems ability to react instantaneously to a critical situation. Furthermore, the very efficientusage of bandwidth is also a desired property of event based protocols.

In a time triggered protocol each sender or message gets its own time-slot on the bus. This iscalled Time Division Multiple Access (TDMA) and requires a predefined schedule which preventscollisions from happening on the bus. This makes the temporal behaviour of the bus predictable[32]. Each ECUneeds to be aware of this schedule and they need to be synchronised in orderto prevent collisions from happening. The main advantage of a time triggered protocol is thatguarantees can be given on the latency of the messages on the bus, making this type of protocolvery suitable for safety-critical control functions. Furthermore, a lost message can be detectedmore easily when using a time triggered protocol, since it is known when to expect a certainmessage. This increases the dependability of the network [2]. A general drawback of a timetriggered protocol is decreased flexibility and scalability, because the schedule needs to be knownby allECUs on forehand. Therefore, a new schedule needs to be composed every time an ECU isadded or removed from the system [2]. However, this will not be a major issue with the topology

described in Section4.2,because the number ofECUs is fixed.First of all, an important aspect of the desired communication protocol is the real-time beha-

viour, which means the predictability of the temporal behaviour. Because safety-critical distrib-uted control functions will run on the integrated architecture, the communication needs to be timetriggered instead of event based. Secondly, safety-critical functions require a robust networkingprotocol, since there is no tolerance for errors. Even if a fault occurs the function must ensurethe safety. Robustness of the communication protocol ensures the correctness of the transmitteddata, which increases the fault-tolerance of the overall system[26]. The available bandwidth of thecommunication network is also a very important aspect. Because all the functions communicateover a single bus in the integrated architecture, this bus needs to be able to transmit enormousamounts of data. This is only possible if the communication protocol for this bus has sufficientbandwidth available.

Taking everything into account, the most suitable type of communication protocol is a timetriggered protocol. This type of protocol is preferred when real-time distributed control is pre-formed because of its predictable temporal properties.

4.5 Performance

Performance is an important aspect to take into account when preforming real-time distributedcontrol. Especially when all functions of the vehicle are integrated in an architecture with minimalhardware. This will lead to increased communication and the ECUs processing power must besufficient to run multiple models. Therefore, delays can occur on several places in the process.Regarding the performance of a distributed control system, there are four types of delays that canbe identified[2]:

Sensor delay (S): The delay between the reading of a sensor and the availability of itsinput value for theECU.

Communication delay (C): The delay between sending data from oneECUand receivingit by another.

Processing delay (Ppre,P,Ppost): The delay between the availability of the desired inputdata and the calculated output.

Actuator delay (A): The delay between the availability of a calculated output value andthe actual movement of the actuator.

These delays add up to a totalI/O latency for a single function. If a function runs entirely ona singleECU, like for the reflex analogy described in Section4.3the minimal latency (Tmin) forthat function is given by:

Tmin= S+ P+A (4.1)



32/86


However, the worst case latency (Tmax) for a function which requires both pre- and postprocessingis given by:

Tmax= S+ Ppre+C1+P+C2+Ppost+A (4.2)

This shows that the performance gain by running a function completely on a single satellite ECUis therefore substantial.

The maximum tolerable delay Tmax for a real-time function on the IM01 can be calculated.Assuming the top speed of the IM01 is 360 km/h, which is the same as 100 m/s, and the desiredprecision of a real-time function like active suspension, active aerodynamics or braking is about10 cm1, which is 0.1 m. The desired reaction time of the system is 0.1 m divided by 100 m/s,which results in 0.001 s, or 1 ms. Therefore, Tmax is 1 ms for a real-time function that will beimplemented on the IM01.

4.6 Safety

Certain safety aspects are inherent to the design of the proposed integrated architecture. Becausethe architecture has computational power both in the central ECUas well as in the satellite ECUs,redundancy for safety-critical functions can be implemented in software instead of hardware. Asafety-critical function that executes on the central ECUand communicates to the satellite ECUs,can also be available on the satellite ECUs as a, normally unused, back-up function. Whenever thecentralECUor a communication-link fails and the satelliteECUdoes not receive the expected dataanymore (which can easily be detected in a time-triggered communication protocol, as describedin Section4.4), the back-up function can take over the computations. If the computational powerneeded for the back-up functions of the safety-critical systems is larger than the unused availablecomputation power at that satellite ECU, non-safety-critical functions that are running on thatsatellite ECU can be temporarily disabled. This ensures a safe operation for the safety-criticalfunctions. This back-up mechanism can be implemented in the RTOSlayer of eachECU.

This mechanism can not be implemented when the architecture would use customized hardwarefor each function, like in the architecture described in Section 3.3, unless the hardware itself isredundantly implemented. It is also not possible to implement this mechanism on an architecturethat has only a singleECUthat is powerful enough to run the functions, like described in Section3.2.

In order to give guarantees concerning additional safety aspects, the proposed architectureneeds further investigation. Due to limited time this falls outside the scope of this graduationproject. Furthermore, some additional safety aspects, such as the redundant implementation ofcertain soft- or hardware parts, are a trade-off between safety and costs and can be decided uponduring implementation. A more detailed safety argumentation of a single function is given inSection6.3.

4.7 SecurityA potential drawback of an integrated architecture that uses general purpose hardware can beidentified when looking at the security aspect. This is especially the case when such an architecturebecomes an automotive standard that is adopted by variousOEMs. Currently the de facto industrystandard regarding the communication protocol is CAN. This is an open protocol, which makesit very straightforward to add custom hardware to an existing CANbus. As described in Chapter2, theCANspecification only specifies the way aCANframe looks. It does not specify which IDsare being used on the bus and what data is contained in which specific frame. Each automotiveOEMuses a specific protocol on top ofCAN to specify these frames. In order to breach securityvia theCAN bus, theCAN bus of the targeted vehicle needs to be reverse-engineered. With theknowledge gained from such an operation, specific functions can be overridden or disabled.

1

The precision of about 10 cm for a real-time function is the result of a consultation with the active aerodynamicsengineer within InMotion.



33/86


In order to verify this, experiments have been conducted on a Volkswagen Lupo within thisproject. First of all, the CANbus of the Lupo has been monitored in order to see what CANframes were used by the vehicle for certain functions. With this information CANframes with

the sameIDs that the vehicle uses, but with false data have been sent via the CAN bus. Whenthis false data is sent very fast and repeatedly, it becomes possible to block the actual data fromgetting through. This enables the taking over of certain controls as the brake pedal or the gearlever.

Reverse engineering of an ExistingCANbus can only be done with physical access to the vehicleand only yields information about a vehicle of a specific make and model. However, if the hardwareused in future vehicles is standardised hardware, reverse engineering a single vehicle yields enoughinformation in order to gain unauthorized access to a whole range of vehicles. Therefore, beforeimplementing an integrated automotive architecture, an intelligent assessment has to be madeon what aspects need to be standardised and what aspects need to remain OEMor even modelspecific. This will not be taken into account for thePoCdescribed in the next chapter, since thegoal of thePoCis only to show the possibility of the concept. Security will also not be a main

concern for the IM01, as it will be a one of a kind prototype.

4.8 Conclusion

In this chapter an answer has been given to the question: What would a desired integratedautomotive architecture look like? This question is answered by describing the designed architec-ture together with its advantages with respect to the alternatives that have been investigated inChapter3. A description of both the hard- and software architecture has been given, after whichthe desired properties of the communication bus have been explained. The performance of certainmodes of operation within the architecture has been shown and a view on how the architectureensures the safety aspect is given. A concern on the security aspect of the proposed architecturehas been described, however the solution is left as an assessment during the implementation of

such an architecture, which will be described in Chapter 7. Now that the desired integrated auto-motive architecture has been described, the next chapter will contain an description of the PoCin which this architecture has been implemented in order to prove its feasibility.



34/86


35/86

Chapter 5

Proof of Concept

To answer the main research question and thus prove that the designed architecture meets itsrequirements, aPoChas been implemented. This chapter describes the steps taken to implementthis PoC and discusses the design choices that have been made. Firstly, Section 5.1 describesthree use cases that have been defined to test the PoC. Then all the choices and considerationsconcerning the implementation are described in Section5.2. Finally this chapter is concluded inSection5.3. The main question answered in this chapter is: What is needed to prove the feasibilityof the proposed integrated architecture?

5.1 Use Cases

In order to test thePoCand prove the designed architectures ability to execute several functionsusing both central as well as local control, the following three use cases have been defined: active

aerodynamic control, ABS and power windows. The control strategies are simplified models ofthe systems that can be implemented on the IM01 or a production vehicle. The control strategyfor the active aerodynamics use case has been discussed with the aerodynamics engineer withinthe InMotion team. The strategy for the ABS has been developed together with the engineerresponsible for the overall braking system of the IM01. The power window system has beendeveloped using preliminary knowledge about power windows on a production vehicle.

The chosen use cases are interdependent systems because they communicate data over theCANbus and share several sensors and actuators. The active aerodynamics use case is a systemthat uses distributed control. While most of its control takes place on the centralECUthere isalso an input on a satelliteECU that is coupled directly to the actuator on that same ECU. TheABSuse case demonstrates central control, for this system the satellite ECUs only communicatewith the sensors and actuators, but all the intelligence is in the central ECU. The power windows

have been chosen as an example of a system that is locally controlled, however it can be overriddenby higher priority models running on the centralECU.

5.1.1 Active Aerodynamics System

The first use case that has been defined is the active aerodynamics system. The purpose of thissystem is to influence the vehicles aerodynamic properties at different speeds. In order to transferthe power generated by the electric motors or ICE to the road, traction is needed. The moretraction, the more power can be transferred without causing the wheels of a vehicle to spin uponacceleration. One way of generating additional traction in a car is using its aerodynamic shapein order to generate downforce. The unwanted side-effect of generating downforce is that by thesame aerodynamic shape drag is created as well. Drag is the force which is needed to move anobject through air (also known as air resistance). Thus, increasing the downforce of a vehicle alsoincreases the drag, making it harder to move the vehicle through the air. Since the downforce and



36/86

CHAPTER 5. PROOF OF CONCEPT

drag of a vehicle are coupled, reducing the drag would also mean reducing the downforce. Theinfluence of this effect can be reduced by using active aerodynamics, changing the aerodynamicshape of the vehicle as a function of predefined inputs.

Electronic controller

Wheel speed

sensor

Steering angle

sensorWing angle

actuator

Brake pedal

Figure 5.1: Active aerodynamics system schematic

Figure5.1shows the schematic of an active aerodynamics system. The inputs to the systemconsist of four wheel speed sensors to measure the vehicles speed, the brake pedal sensor to detectif the driver is braking and the steering angle sensor to determine if the vehicle is taking a corneror if it is traveling along a straight line by its steering angle. The output is an actuator thatregulates the angle of the rear wing. Both the downforce and drag of the vehicle are directlyproportional with the angle of the wing. The angle of the wing is calculated by the electronic

controller following this control strategy rules:

Vehicle speed: The higher the vehicle speed (average of the wheel speed sensors), the smallerthe angle of the wing becomes; this reduces the drag at high speeds. The angle of the wingwill start to decrease only after a certain speed threshold; this ensures maximum downforceduring acceleration.

Steering angle: Above a certain threshold of the steering angle, increase the angle of thewing for more downforce (even if the speed is still high); this increases traction and thusstability in high-speed corners.

Brake pedal: Instantly increase the angle of the wing to its maximum if the brake pedal ispressed; this helps braking by increasing both the drag and the traction as a result of an

increased downforce.

5.1.2 Anti-Lock Braking System

When a vehicle brakes, the speed of the vehicle itself and the individual wheel speed of the fourwheels are not the same. This effect is called slip and is caused by the inertia of the vehicle. Theslip percentage of a single wheel is given by Equation5.1. While braking, a certain amount of slipis allowed, but when the slip becomes too large1 (typica

Proof of Concept of an Integrated Automotive Architecture

Documents

Transcript of Proof of Concept of an Integrated Automotive Architecture