Proof of Concept of An Integrated Automotive Architecture

Master Automotive Technology Department of Mathematics and Computer Science Software Engineering and Technology Research Group
Proof of Concept of an Integrated Automotive Architecture

Master Thesis J.G.S. (Johan) van Uden, BSc
Supervisor: prof.dr. M.G.J. van den Brand Committee: prof.dr. M.G.J. van den Brand dr.ir. R.J. Bril dr.ir. T. Hofman
Final Version
Eindhoven, November 2013
Abstract
A little over 30 years ago, in 1977, General Motors (GM) introduced the worlds rst Electronic Control Unit (ECU) in a production vehicle. A few years later (May 1983) an engineer at GM predicted 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. An average modern premium production vehicle contains 70 to 100 ECUs, which run a total of around 100 million Lines of Code (LoC) [10]. A car is no longer just a mechanical machine with a few electronic systems, it has become a high-tech integrated system which includes various engineering disciplines. This means that automotive engineers need new ways of developing modern vehicles. The one-function-one-ECU design philosophy, which is still common practice in the automotive industry, will no longer suce. This design philosophy has led to the fact that a modern car now contains around 100 million LoC. In order to reduce this enormous amount of software, automotive engineers will have to use a systems oriented approach to develop future vehicles. In the graduation project described in this master thesis, a systems oriented approach is used to design an integrated automotive architecture, which contains just ve ECUs. The implementation of a Proof of Concept (PoC) that proves the feasibility 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 in the vehicle by using only ve ECUs. This architecture features localised control, which resembles a reex in the human body. This control can yield a substantial performance improvement. Furthermore, the architecture provides certain safety related advantages over the existing alternatives by design. As mentioned above, the designed architecture has been implemented in a PoC, which has been used to prove the feasibility of the architecture. Tests conducted on the PoC validated its functional correctness. However, the PoC suered a lack of performance. Recommendations to overcome this problem are presented, showing the feasibility of implementing the architecture in an actual vehicle. Keywords: automotive, architecture, systems oriented approach, model based design, software, real-time systems, embedded systems
iii
Preface
This master thesis is the result of my graduation project, which nalises my Automotive Technology master at Eindhoven University of Technology (TU/e). This project has been conducted within the Software Engineering and Technology (SET) group of the Mathematics and Computer Science 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 1 car while being durable enough to nish a 24h endurance race. First of all, I would like to express my sincere gratitude to prof.dr. M.G.J. van den Brand for coaching me during this project. His feedback, valuable advice and the useful discussions helped me 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 the time to assess my research. I would also like to thank all the team members of InMotion for the wonderful time and the valuable discussions on dierent technical topics. Working in such a multidisciplinary team has been a truly valuable experience. Furthermore, my thanks go out to the people who helped me by reviewing dierent versions of this thesis, and provided me with valuable feedback in order to improve it. I thank Yaping Luo, from the SET 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 my girlfriend Anne van Dijk, who has supported and motivated me during my entire study at the TU/e. Johan van Uden Eindhoven, November 2013
Contents
Contents List of Figures List of Abbreviations 1 Introduction 1.1 Context . . . . . . . . . . . . . . . . 1.2 Problem Description . . . . . . . . . 1.3 Project Goal . . . . . . . . . . . . . 1.4 Research Scope . . . . . . . . . . . . 1.5 Research Method and Thesis Outline vii ix xi 1 1 2 2 3 3 5 5 6 7 7 9 11 11 12 13 13 15 15 16 17 18 19 20 20 21 23 23 23 24 25 26 26 vii
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
2 Preliminaries 2.1 One-Function-One-ECU Design Philosophy . . . 2.2 Systems Approach . . . . . . . . . . . . . . . . . 2.3 Networking Technologies . . . . . . . . . . . . . . 2.3.1 Controller Area Network . . . . . . . . . . 2.3.2 Time Triggered Controller Area Network 3 Related Work 3.1 From Federated to Integrated Architectures 3.2 Fully Centralized Control . . . . . . . . . . 3.3 Integrated Architecture on Chip . . . . . . 3.4 Conclusion . . . . . . . . . . . . . . . . . . 4 Integrated Automotive Architecture 4.1 System Architecture . . . . . . . . . 4.2 Hardware Topology . . . . . . . . . . 4.3 Software Architecture . . . . . . . . 4.4 Communication . . . . . . . . . . . . 4.5 Performance . . . . . . . . . . . . . . 4.6 Safety . . . . . . . . . . . . . . . . . 4.7 Security . . . . . . . . . . . . . . . . 4.8 Conclusion . . . . . . . . . . . . . . 5 Proof of Concept 5.1 Use Cases . . . . . . . . . . . . . . . 5.1.1 Active Aerodynamics System 5.1.2 Anti-Lock Braking System . . 5.1.3 Power Windows System . . . 5.2 Implementation . . . . . . . . . . . . 5.2.1 Hardware Setup . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
CONTENTS
5.3
5.2.2 Software Setup 5.2.3 Design Choices 5.2.4 Implementation Conclusion . . . . . .
. . . . . . . . . . . . . . . . . . . . of the Use Cases . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
29 31 34 37 39 39 40 40 41 41 43 45 45 45 45 46 47 47 47 48 49 50 51 53 57 57 58 58 60 62 64 64 68 71 71 72 73 74
6 Validation 6.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Active Aerodynamics Model . . . . . . . . . . . . . . . 6.1.2 Anti-Lock Braking Model . . . . . . . . . . . . . . . . 6.1.3 Power Windows Model . . . . . . . . . . . . . . . . . . 6.1.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Safety Argumentation . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Goal Structuring Notation (GSN) . . . . . . . . . . . 6.3.2 Semantics of Business Vocabulary and Rules (SBVR) 6.3.3 Power Windows Safety Case . . . . . . . . . . . . . . . 6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Implementation 7.1 Towards Realisation . . . 7.1.1 Practical Problems 7.1.2 IM01 . . . . . . . . 7.2 Beyond Realisation . . . . 7.3 Conclusion . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
8 Conclusions and Recommendations Bibliography Appendix A Developed Hardware B Developed Software B.1 USB-CAN Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2 CAN Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3 I/O Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C Simulation Results C.1 Simulation results of individual functions . . . . . . . . . . . . . . . . . . . . . . . C.2 Simulation results of full system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D Safety Argumentation D.1 Functional Safety Requirements . . D.2 GSN diagram . . . . . . . . . . . . D.3 GSN pattern . . . . . . . . . . . . D.4 GSN diagram with SBVR applied .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
viii
List of Figures
2.1 2.2 2.3 2.4 2.5 2.6 3.1 3.2 4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 7.1 7.2 Overview of electronic functions in a premium vehicle [24] SIMILAR process [4] . . . . . . . . . . . . . . . . . . . . . Contents of a standard CAN data frame . . . . . . . . . . Reference point for synchronisation in TTCAN . . . . . . Basic cycle in TTCAN [41] . . . . . . . . . . . . . . . . . System matrix in TTCAN [41] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 8 9 10 10 12 13 16 17 17 18 18 24 25 26 27 28 29 30 32 34 35 35 36 36 40 41 41 42 43 44 44 46 48 49 57 ix
Centralized control architecture in the Formula 1 . . . . . . . . . . . . . . . . . . . Integrated architecture on chip [33] . . . . . . . . . . . . . . . . . . . . . . . . . . . High level system architecture for the IM01 . Hardware topology for the IM01 . . . . . . . High level software architecture for the IM01 Mapping of software function parts to ECUs . Architecture for a software function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Active aerodynamics system schematic . . . . . ABS schematic . . . . . . . . . . . . . . . . . . Power windows schematic . . . . . . . . . . . . Block diagram of hardware used for the PoC . Microchip MCP2515DM-BM board setup . . . I/O Interface Boards . . . . . . . . . . . . . . . Block diagram of software running on the PoC Synchronisation mechanism . . . . . . . . . . . In- and output signals used by the PoC . . . . Communication schedules . . . . . . . . . . . . Central ECU model . . . . . . . . . . . . . . . Front satellite ECU model . . . . . . . . . . . . Rear satellite ECU model . . . . . . . . . . . .
Simulink model used for simulation . . . . . . . . . . . . . . . . . . . Active aerodynamics control model . . . . . . . . . . . . . . . . . . . ABS control model . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power windows control schematic . . . . . . . . . . . . . . . . . . . . Simulation results of full system model: brake delay . . . . . . . . . Measurement results on PoC: brake delay . . . . . . . . . . . . . . . Measurement results on PoC: time triggered communication scheme Conceptual model of the power windows system . . . . . . . . . . . .
Overview of electronic functions in the IM01 . . . . . . . . . . . . . . . . . . . . . Hardware topology for a production vehicle . . . . . . . . . . . . . . . . . . . . . .
A.1 Schematic of the I/O interface board for the front satellite ECU . . . . . . . . . . . Proof of Concept of an Integrated Automotive Architecture
LIST OF FIGURES
A.2 Schematic of the I/O interface board for the rear satellite ECU . . . . . . . . . . . B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 C.1 C.2 C.3 C.4 C.5 C.6 Components for the CAN drivers . . . . . . . . . . . . . . . . . . . . . . Structure diagram for the CAN drivers . . . . . . . . . . . . . . . . . . . Sequence diagram for the CAN drivers . . . . . . . . . . . . . . . . . . . Flowchart of original polling CAN rmware . . . . . . . . . . . . . . . . Flowchart of adapted interrupt based CAN rmware . . . . . . . . . . . Components for the I/O drivers . . . . . . . . . . . . . . . . . . . . . . . Sequence diagram for the update of a servos position in the I/O drivers Sequence diagram for an analog to digital conversion in the I/O drivers Simulation results for the active aerodynamics controller Simulation results for the ABS controller . . . . . . . . . Simulation results for the power window controller . . . Full system simulation input signal . . . . . . . . . . . . Full system simulation calculated internal values . . . . Full system simulation output signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57 58 58 59 60 61 62 62 63 65 66 67 68 69 70 72 73 74
D.1 GSN diagram of power window use case . . . . . . . . . . . . . . . . . . . . . . . . D.2 GSN pattern used to create the GSN diagram . . . . . . . . . . . . . . . . . . . . . D.3 GSN diagram of power window use case with SBVR applied . . . . . . . . . . . . .
List of Abbreviations
ABS ACK CAN CPU CRC DLC ECU EoF GPS GM GSN HAL HARA HIU HLR I/O I2 C IC ICE ID IDE IFS INCOSE IP LaQuSo LLR Anti-lock Braking System Acknowledge Controller Area Network Central Processing Unit Cyclic Redundancy Check Data Length Code Electronic Control Unit End of Frame Global Positioning System General Motors Goal Structuring Notation Hardware Abstraction Layer Hazard Assessment by Risk Analysis Hub Interface Unit High Level Requirement Input/Output Inter-Integrated Circuit Integrated Circuit Internal Combustion Engine Identier Identier Extension Intermission Frame Space International Council on Systems Engineering Intellectual Property Laboratory for Quality Software Low Level Requirement xi
LIST OF FIGURES
LoC NTU OEM OMG OS OSI PC PoC PoP RTAI RTLinux RTOS RTR SBVR SET SoC SoF SPI TDMA TTCAN TTL TU/e USB
Lines of Code Network Time Unit Original Equipment Manufacturer Object Management Group Operating System Open Systems Interconnection Personal Computer Proof of Concept Proof of Product Real-Time Application Interface Real-Time Linux Real-Time Operating System Remote Transmission Request Semantics of Business Vocabulary and Rules Software Engineering and Technology System-on-Chip Start-of-Frame Serial Peripheral Interface Time Division Multiple Access Time Triggered Controller Area Network Transistor-Transistor Logic Eindhoven University of Technology Universal Serial Bus
xii
Chapter 1
Introduction
This master thesis is the result of a graduation project for the Automotive Technology master at Eindhoven University of Technology (TU/e). The project is carried out within the Software Engineering and Technology (SET) group of the Mathematics and Computer Science department of the TU/e. The SET research group investigates and develops methods and tools for timeand cost-ecient evolution of high-quality software systems. The group has two main research themes; Software maintenance and evolution and Theory, methods and tools for model-driven software engineering. This graduation project is part of the InMotion project. The objective of the InMotion project is to design and build a series-hybrid performance vehicle, which contains the newest cutting-edge technologies and combines various research topics. This vehicle should be able to beat a modern Formula 1 car while being durable enough to nish a 24h endurance race. In order to integrate all the electronic systems for such a performance vehicle, existing hard- and software architectures will 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 Section 1.3, followed by the research scope in Section 1.4. This chapter 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 rst Electronic Control Unit (ECU) in a production vehicle. A few years later (May 1983) an engineer at GM predicted 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. An average modern premium production vehicle contains 70 to 100 ECUs, which run a total of around 100 million Lines of Code (LoC) [10]. A car is no longer just a mechanical machine with a few electronic systems, it has become a high-tech integrated system which includes various engineering disciplines. This means that automotive engineers need new ways of developing modern vehicles. The one-function-one-ECU design philosophy, which is still common practice in the automotive industry, will no longer suce. Chapter 2 explains how this design philosophy has led to the fact that a modern car now contains around 100 million LoC. In order to reduce this enormous amount of software, automotive engineers 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 dierent functions in a vehicle creates a complex network of interconnected ECUs. In an average modern vehicle there are multiple networks to interconnect dierent sets of ECUs. In their turn, these networks are connected through gateways, resulting in a complex network topology for the overall Proof of Concept of an Integrated Automotive Architecture 1
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 approach in an eective 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% of the software that is used in modern premium vehicles. Furthermore, the network topologies of these aircrafts have become a lot less complex over the last 30 years because of the use of systems approach for developing aircrafts [38].
1.2
Problem Description
As described in the previous section, the way automotive engineers currently design and implement electronic systems in vehicles is (highly) inecient and results in large amounts of overhead and complex network topologies. If the one-function-one-ECU design philosophy will be used for the development of future vehicles, the amount of software in a car may increase to half a billion LoC 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 most important aspects in the automotive domain, this increasing amount of code and thus increasing amount of bugs increases the risk of an unacceptable situation. When each function has its own ECU, complexity of the overall system can simply be divided over the dierent ECUs, making the complexity management very straightforward. However, upon integration of all the dierent functions, the network topologies become larger and more complex. These large networks lead to an enormous amount of wiring and connectors. Increased wiring adds a lot of weight to the vehicle which makes it less fuel ecient. Furthermore, wires and connectors are a common point of failure and therefore an increased amount of wires and connectors also leads to a less reliable car. Most of the ECUs in a vehicle are idling a large amount of their lifetime. For instance the safety-critical airbag controllers are most probably not used for years, but when they are needed they must react within milliseconds. This means that the hardware for these ECUs needs to be powerful 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 idle period, the hardware in a vehicle could be used a lot more eciently. When the aspect of power consumption is considered, measurements show that an average automotive ECU consumes 3.5 watts.1 Given the fact that a modern premium vehicle contains around 100 ECUs, the total power consumption sums up to around 350 watts. Therefore, reducing the number of ECUs would reduce the power consumption of the overall electronic system, which would increase the vehicles fuel eciency.
1.3
Project Goal
The ideal future avionics system would combine the complexity management advantages of the federated approach, but would also realise the functional integration and hardware eciency benets of an integrated system. [19] This quote by Robert Hammett from 2002 applies seamlessly to the automotive domain and therefore forms a solid base for the project goal. The main research question for this graduation project is: Is it possible to design and implement an architecture that minimises the number of ECUs in a 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
1 Measurements
conducted on a Bosch Motronic MP3.1 ECU at a supply voltage of 14 volts.
CHAPTER 1. INTRODUCTION
Concept (PoC). Furthermore, the goal is to use standardised hardware components for implementing the PoC, because standardising the hardware leads to a cost reduction and has several other advantages that are described in Chapter 4. The PoC will also be used to conduct experiments and perform measurements concerning certain predened metrics. Based on the analysis of these metrics, 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 of sub questions, which together form the scope of the project. Each of this sub questions will be covered in a separate chapter: What eorts have already been made to create an integrated architecture? Chapter 3 What would a desired integrated automotive architecture look like? Chapter 4 What is needed to prove the feasibility of the proposed integrated architecture? Chapter 5 Does the PoC meet the requirements? Chapter 6 What improvements should be made to the PoC in order to implement the proposed integrated architecture in an actual vehicle? Chapter 7
1.5
Research Method and Thesis Outline
To satisfy the project goal, the following research steps are taken: Perform a structured literature review A literature study has been conducted to investigate existing results and form a clear view on 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 the automotive domain. The results of the literature study are presented in Chapter 3. Design an integrated architecture Chapter 4 contains the architectural design that has been developed and the main design considerations that have been taken into account. In order to follow the systems oriented approach, 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 Concept To prove that the designed architecture is an achievable solution, a PoC has been built. Chapter 5 contains a description on how this PoC has been implemented and a discussion on the design considerations. Furthermore, descriptions of the use cases that are dened for the PoC are given. Validate architecture and Proof of Concept The PoC has been simulated and tested. The results of these simulations and tests are used to validate the architecture and PoC. This process is described in Chapter 6. Perform an analysis on the realisation of the designed architecture in a vehicle Because the PoC is created to discuss and prove the feasibility of the architecture, this is not yet an actual realisation. Chapter 7 describes the steps that need to be taken and the problems that have to be overcome in order to implement the proposed architecture in a vehicle. This has been done for both the IM01 racing vehicle and for a premium production vehicle. Conclude Chapter 8 contains the conclusions that can be drawn from this project and the results.
Chapter 2
Preliminaries
This chapter describes the preliminary concepts that are used throughout this thesis. These preliminary concepts contain technologies and principles which are outside the scope of the graduation project, but which are used within the project to base the research upon. An explanation of the one-function-one-ECU design philosophy, which is the main reason behind the problem described in the previous chapter, is given in Section 2.1. Section 2.2 describes the systems approach, which is 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 is concluded by Section 2.3, which gives a brief introduction to the networking technologies that are used 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 manufacturers function as Original Equipment Manufacturers (OEMs), whose main task is to integrate all the systems that are supplied by external suppliers into their vehicle. These suppliers are called Tier 1 suppliers and some well known examples are Denso, Valeo and Bosch. Because the source code that is part of a system is Intellectual Property (IP) of its Tier 1 supplier, the OEMs and other suppliers do not get to see this code. This means that the development, integration and testing needs to be done with a black box model of these systems. These black box models usually consist of a list of specications and interfaces [8] and are supplied as complete embedded systems containing both the hardware and the software. As the OEMs integrate all the black boxes in the vehicle, each function is represented by a certain black box. Because each black box comes with its own ECU, each function in the vehicle ends up having its own private ECU, this is called a federated architecture. Figure 2.1 shows 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 software subfunction that calculates the vehicle speed could be reused by functions like the instrument cluster, electronic stability control, adaptive cruise control, etc. With the one-function-one-ECU design philosophy, instead of reusing the same subfunction, it will be duplicated by all the systems that use it, with possible conicts in functionality. In this way a lot of overhead and unnecessary LoC are introduced in the vehicle. The advantage of the one-function-one-ECU design philosophy is that the unit testing of dierent systems is very straightforward. Each system can be tested and changed individually, without aecting any of the other systems, as long as there are no dependencies between them. Therefore, this design philosophy proved to be very benecial a couple of years back, when vehicles still had a limited number of electronic functions. However, when the number of electronic functions increased, the dependencies between the functions also increased. Even though unit testing still Proof of Concept of an Integrated Automotive Architecture 5
CHAPTER 2. PRELIMINARIES
remained straightforward, problems arose upon system integration. The one-function-one-ECU design philosophy is furthermore characterized by a bottom-up approach, 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 ordered and the integration phase starts only after all the components are available. After the system is composed of the separate components the integrated system will be evaluated. If any components cause a deviation from the functional requirements, they are changed or the systems conguration is altered. This makes the bottom-up approach a classical iterative engineering approach, which leads to systems that rarely meet the functional requirements after the rst iteration [30].
Driver Event Data Active Alertness Recorder Cabin Noise Cabin Entertainment Suppression Monitoring Environment System Auto-Dimming Windshield Controls Mirror Head-Up Wiper Control Battery Accident Display Interior Management Recorder Voice/Data Lighting Communications DSRC Lane Engine Instrument Airbag Correction Control Parental Cluster Deployment Controls Electronic Toll Collection Adaptive Front Night Vision Lighting Adaptive Cruise Control Automatic Braking Electric Power Steering Electronic Throttle Control Electronic Valve Timing Digital Turn Signals Navigation System Secutity System Active Exhaust Noise Suppression Active Suspension Anti-lock Electronic Braking Hill-Hold Stability Control Control Active Remote Seat Position Regenerative Vibration Keyless Parking Control Braking Tire Control Entry System Lane Pressure Departure Active Cylinder Blindspot Monitoring Yaw De-activation Detection Warning Control Idle Stop/Start OBDII Transmission Control
Figure 2.1: Overview of electronic functions in a premium vehicle [24]
2.2
Systems Approach
There are various dierent denitions of the systems approach. Actually even the denition of a system is not unanimous. After reviewing various sources, a choice was made to follow the denition proposed by the International Council on Systems Engineering (INCOSE) for this project. The INCOSE denes a system as follows: A system is a construct or collection of dierent elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required 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 among the parts; that is, how they are interconnected. [1]. The systems approach is characterized by a top-down approach. The top-down approach will reduce the systems complexity by decomposing it into separate parts. This process can be applied to any part of the system. Usually one starts with the system as a whole, after which the process can be applied to the subsystems that are dened after the rst step. This can be repeated in order to create various levels of system hierarchy. This will nally result in a decomposition of the system in the low-level parts [30]. By following this approach, the relationship among the parts is automatically generated by the process. 6 Proof of Concept of an Integrated Automotive Architecture
The systems approach is also characterized by being multidisciplinary. In order to take every aspect of a system into account, dierent technical disciplines are involved. As INCOSE states in their denition 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 engineers work together to make sure all viewpoints on these relationships and all aspects of the system are considered. Because it is important to consider every aspect of the system, the systems approach is also characterized as being heuristic. Terry Bahill and Bruce Gissing [4] dened the SIMILAR process, which has later been adopted by the INCOSE fellows [1] to describe the systems engineering process. The SIMILAR process is shown in Figure 2.2 and the acronym stands for: State, Investigate, Model, Integrate, Launch, Assess and Re-evaluate. The SIMILAR process has also been followed for this project, however this process should not be followed in a sequential way. It is an iterative process and some of the steps need to be executed in parallel.
Customer Needs
State the Problem
Investigate Alternatives
Model the System
Intergrate
Launch the System
Assess Performance
Outputs
Re-evaluate
Re-evaluate
Re-evaluate
Re-evaluate
Re-evaluate
Re-evaluate
Figure 2.2: SIMILAR process [4] The rst step of the SIMILAR process, stating the problem, has been described in Chapter 1. Secondly the existing alternatives have been investigated and are described in Chapter 3. The proposed system has been modelled and described in Chapter 4, in this chapter the heuristic approach 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 of the modelling process. Finally the performance is assessed, the results of that assessment can be found in Chapter 6. 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, dierent networking technologies are available. However only the ones which are used to base the research for this graduation project upon 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 specic technologies will be discussed in Chapter 4. Other networking technologies that are needed for the implementation of the designed architecture in an actual vehicle will be discussed in Chapter 7.
2.3.1
Controller Area Network
CAN is a communication bus that is widely used in the automotive domain and has become an industry standard over the last years. CAN has been developed to have a few very important properties for automotive applications, especially in the eld of reliability and robustness. For instance CAN features a low latency, network-wide bus access priority, instant bit monitoring and control features to recover from frame errors [14]. Amongst others, these features have lead to the fact that CAN has become one of the most used vehicle network technologies in todays automotive industry. A brief overview of the properties of CAN which are used throughout this thesis are given in this section. For a comprehensive description of CAN the reader is referred to the ISO-11898 standard [40]. The information in this section is based on this standard. The ISO-11898 standard describes Proof of Concept of an Integrated Automotive Architecture 7
the data link layer and some aspects of the physical layer of the Open Systems Interconnection (OSI) reference model [16]. A CAN message is called a frame and four types of frames are dened: data frame, remote frame, error frame and the overload frame. The data frame is the only type that is relevant for this thesis. Each frame on the bus has an unique Identier (ID), which also represents the priority of the frame. The lower the numerical value of the ID, the higher the priority of the frame. CAN uses two types of data frames: standard data frames and extended data frames. The former uses IDs that consist of 11 bits, while the latter uses 29 bits long IDs, enabling more unique IDs on a single bus. In this thesis only standard data frames are being used. The contents of a standard data frame, which consists of at least 52 bits, are shown in Figure 2.3 and consists of the following elds: Start-of-Frame (SoF) = 1 bit (logical 0) Arbitration eld = 12 bits Identier (ID) = 11 bits Remote Transmission Request (RTR) = 1 bit (logical 0) Control eld (CTRL) = 6 bits Identier Extension (IDE) = 1 bit (logical 0) Reserved = 1 bit (logical 0) Data Length Code (DLC) = 4 bits (Number of bytes in the data eld) Data eld (DATA) = 0 64 bits (Divided in 0 8 bytes) Cyclic Redundancy Check eld (CRC) = 16 bits Cyclic Redundancy Check (CRC) = 15 bits CRC-Delimiter = 1 bit (logical 1) Acknowledge eld (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)
1 0
Length (bits) 1
11 ID
1 1 1 RTR IDE reserved
4 DLC
0...64 DATA
15 CRC
1 1 1 CRC-Delimiter ACK-Slot ACK-Delimiter
7 EoF IFS
SoF
Arbitration field
CTRL field
DATA field
CRC field
ACK field
Figure 2.3: Contents of a standard CAN data frame The physical connection of a CAN bus consists of two wires, on which bits are transmitted as either 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 8 Proof of Concept of an Integrated Automotive Architecture
bit (the bit with the highest priority on the line) is the logical 0. When the bus is idle, the lines are kept at the 5 volt level (logical 1). A CAN controller can start the transmission of a frame whenever the bus is idle. The CAN arbitration mechanism that is used when two controllers start transmission at the same time is a bitwise logical AND between the two arbitration elds of the frames. In this way, if one of the bits is a logical 0, the resulting bit on the bus is a 0. Only when both bits are a logical 1, the resulting bit is a 1. If a controller senses that the resulting bit is dierent from the bit it wants to transmit, it gives up transmission since it has lost the arbitration. Therefore, the frame containing the most consecutive zeros from the beginning of its arbitration eld wins the arbitration. The frame with the most consecutive zeros from the beginning is also the frame with the lowest numerical ID, hence the frame with the highest priority. The most important elds that will be used and varied throughout this thesis are the data, control and arbitration elds. The other elds will be generated automatically by the CAN controller, based on predened settings and are therefore not explained in further detail in this section.
2.3.2
Time Triggered Controller Area Network
Within this project, principles dened in the TTCAN standard are used for synchronisation. This section describes the relevant synchronisation properties of TTCAN, a comprehensive description of TTCAN can be found in the ISO-11898-4 standard [41]. The information in this section is based on this standard. The main objective of TTCAN is to keep the latency of each frame at a specied value, independent of the CAN bus load. The time unit in TTCAN is called a Network Time Unit (NTU). ISO-11898-4 denes two levels of TTCAN: level one, in which each node runs an individual timer that counts NTUs, which are dened by the bit time on the bus and level two, in which a concept of Global time is introduced and a NTU is a fraction of a physical second. Level one basically resets the individual clocks to zero at a certain time, but because not every individual clock has a very small rate deviation, drift is introduced. Level two oers a mechanism to constantly adjust the rate of each clock, creating a system that is perfectly in sync. In order to implement level two, specic TTCAN compatible hardware is required, which is not commonly available. TTCAN level one can be implemented in software on each CAN controller that is able to run in one-shot mode. In one-shot mode the controller does not try to retransmit a CAN frame after the arbitration has been lost. Furthermore, the CAN controller needs to be equipped with a local timer. Because standard CAN hardware is used in this project, only level one will be explained in this section. On a TTCAN bus, the time master is responsible for the synchronisation. This time master sends a reference frame periodically in order synchronise the individual clocks of the nodes.
Nominal bit time
previous bit
Sync
Propagation
Phase 1
Phase 2
Sample point
next bit
SoF bit
Reference point
Figure 2.4: Reference point for synchronisation in TTCAN 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 all controllers on a bus, but can be adjusted per CAN bus. The sample point of each bit is located between phase 1 and 2. When looking at the very rst bit of a CAN frame, the SoF bit, the sample point of that bit is used as a reference point in the TTCAN protocol. This is shown in Figure 2.4. Proof of Concept of an Integrated Automotive Architecture 9
At each SoF bit that is received by the CAN controllers, the value of the local timer is saved at the referenceISO point. If this SoF bit turned out to be the SoF of the time masters reference frame, 11898-4:2004(E) 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 cycle 5.2 reference General principle protocol starts with the frameof of the time master, and contains several time windows. Each time window is reserved for a specic message, however it is possible to introduce arbitrating windows. 5.2.1 System matrix Matrix cycle In these windows the normal arbitration mechanism of CAN allows controllers to send event based In a time-triggered system, all messages of all nodes in the network may be organised as components of a data. Furthermore, it is tospecifies add free windows into the schedule, exibility. system matrix. Thepossible system matrix the correlation between the messages and the for time enhanced windows in which they shall be sent. In time-triggered CAN, the system matrix shall be organised in basic cycles (rows of These windows can be lled later on, without the need for an entire new basic cycle. Each cycle the matrix) and transmission columns (columns of the matrix). The number of basic cycles in the system matrix shall be a of power two (2), its minimum value 1. Each basic cycle starts with a specially ends with the beginning theofnext one, marked by is the reference frame.
characterised message: the reference message (see Figure 1).
ISO 11898-4:2004(E)
2.5: of Basic cycle in TTCAN [41] In time-triggered CAN, three Figure different types time windows shall be provided: Not each basic cycle needs to be the same. Several dierent cycles together can form a system time matrix, as free shown in Figure 2.6. The consists of time several dierent basic cycles, which all Within a windows; basic cycle, a message may bematrix assigned to more than one window, i.e. a specific message may belong to more than one transmission column. The cycle of all basic cycles in the system matrix shall that be the needs to be contain a dierent windows. In this way it is possible to implement a message arbitrating time windows. matrix cycle. Within a matrix cycle, Cycle_Count shall count the number of the basic cycles. The counting transmitted shall at astart high frequency (in every cycle of the matrix), togethershall with messages that only at zero and shall end at Cycle_Count_Max. The current value of Cycle_Count be transmitted bycycle the time master as part of the reference In particular, it shallAll be time cyclically incremented each basic may consist of time windows of message. different type and needs length. windows of aall transmission need to A be transmitted once in each matrix. This matrix to be known by the controllers basic cycle by the time master. Anymay FSE have receiving a valid reference message use the cycle count matrix column shall have the same length but different types (see Figure 2, shall which shows a system transmitted inthe that reference bus. message. The number of basic cycles within a matrix cycle that are connected to TTCAN with Cycle_Count_Max = 3).
(Cycle_Count_Max+1) shall be an integer power of two (2). A column of the matrix cycle is called a transmission column. Within a transmission column, a specific message may be transmitted periodically with a period that is a power of two (2) that is not greater than the number of rows in the system matrix. The unit of the period is rows in the system matrix. The number (as a value of Cycle_Count) of the basic cycle in which this specific message is transmitted first is called Cycle_Offset; the period is called Repeat_Factor. A specific message may belong to more than one transmission column and may be transmitted in more than one time window of a transmission column. 5.2.2 Time windows
exclusive time windows;
Figure 1 Basic cycle of time-triggered CAN
Each message shall be transmitted in a particular time window. Within a time window, the transmission of a message may only be started during the Tx_Enable window (see 7.2.2), i.e. the SOF-bit of the message shall be within the Tx_Enable window.
ISO 2004 All rights reserved
2 matrix System matrix Figure 2.6: Figure System in TTCAN [41] Exclusive time windows are assigned to a specific message transmitted periodically without competition for the CAN bus. Only one FSE in the network may start a transmission in an exclusive time window. Arbitrating time windows are assigned to messages that share the same time window. Within arbitrating time windows, Proof of Concept anin Integrated Automotive Architecture bus conflicts are resolved by CAN identifier arbitration. Several of FSEs the network may start a transmission in the arbitrating time window. In case of a lost arbitration, the automatic retransmission shall be disabled (exception: merged arbitrating windows). Consecutive arbitrating time windows may be merged to one single window. Frames that lost arbitration or were disturbed by an error may be retransmitted inside the merged arbitrating time window. Free time windows are reserved for future extensions of the network.
NOTE For details concerning the Tx_Enable windows, see 7.2.2.
10
Chapter 3
Related Work
This chapter contains the results of a literature study that has been conducted in order to get an insight in the related work that has been done in the eld of software and system architectures in an automotive context. The main question answered in this chapter is: What eorts have already been made to create an integrated architecture? Section 3.1 describes the need to evolve from a federated to an integrated architecture in the automotive domain. Section 3.2 describes the architecture that is currently being used in Formula 1 racing. An architecture that combines ECUs by integrating them on a System-on-Chip (SoC) is described in Section 3.3. This chapter is concluded in Section 3.4, which gives a brief overview of the existing alternatives that have been realised in order to create an integrated automotive architecture.
3.1
From Federated to Integrated Architectures
The traditional federated electronic architectures, created by following the one-function-one-ECU approach, suited the automotive industry for a long time. A lot of control systems used to be mechanical or hydraulic, and electronic functions were basic and independent. Electronic functions used to have their own (limited number of) sensors and actuators, and straightforward control strategies. Modern cars contain an increasing number of electronic functions, both to replace their mechanical and hydraulic predecessors [33] as well as to implement complete new functionality. Not only the number of electronic functions increases, but the functions themselves are also becoming more complex. This increasing complexity is due to the use of a larger number of sensors and actuators, and more complicated control strategies. Furthermore, the electronic functions are no longer independent, but they share their resources, such as sensors and actuators, and communicate an 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 also being used by other functions like the Anti-lock Braking System (ABS) and are therefore not independent. A modern vehicle nowadays contains around 270 of these functions [8], of which an increasing number are interdependent. The advantage of a federated architecture, when dealing with independent functions, is the straightforward way of integrating these functions. They can be unit-tested separately because they are independent. When the unit-tests are passed, there are no predicted problems with the integrated system, because the independent functions have proven to work correctly and will not inuence each other. However, when functions become interdependent, this advantage disappears completely. 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 systems and software. Furthermore, it is stated in various literature sources [25], [20], [8] that the electronic systems make up to 80% of the innovations in a vehicle. This means that cost reductions in Proof of Concept of an Integrated Automotive Architecture 11
CHAPTER 3. RELATED WORK
this area of the automotive domain will greatly reduce the total costs of the vehicle. Using an integrated architecture instead of a federated one, reduces the amount of ECUs and therefore the amount of hardware, housings, wires and connectors. Because the industry standard for in-vehicle communication networks is the CAN bus, and the maximum number of ECUs connected to a CAN bus is around 20 (this is explained in Section 2.3.1), the network in a vehicle typically consist of multiple CAN busses which are connected through gateways. Using an integrated architecture can 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 electronic systems, is based on a star topology, which is shown in Figure 3.1. This system consists of a single centralized ECU and four Hub Interface Units (HIUs). The centralized ECU is responsible for the control of every electronic subsystem in the car, while the HIUs only convert Input/Output (I/O) signals to CAN frames [43]. These CAN frames are interpreted by the central ECU as normal I/O signals. In this way the only advantage of the HIUs is the extension of the I/O ports to the four corners of the car, without using a lot of wires to reach these corners and connect all sensors and actuators. The sensors and actuators are connected locally to the HIUs, which in their turn connect through only two CAN wires to the central ECU.
Figure 3.1: Centralized control architecture in the Formula 1 This architecture has the advantage of reducing the total number of ECUs to one. However, this system is not a distributed control system since all the intelligence of the control functions is in a single place. The main drawback of this topology is a very high network load, because all the I/O values to control the sensors and actuators are sent through this network. This also means that if a network link fails, all sensor values of the HIU connected to it are not received by the central ECU and that all actuators on that HIU become uncontrollable. This leads to a possible 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 the HIUs are only used to connect sensors for monitoring the overall vehicle state, which are not critical for the operation of the car. This reduces the advantage of the HIUs, because the critical sensors and actuators are still connected directly to the central controller. 12 Proof of Concept of an Integrated Automotive Architecture
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 Figure 3.2 is proposed as a suitable solution to reduce the number of ECUs in a production vehicle. This architecture is based on multi-core SoCs and thus consists of multiple cores on a single Integrated Circuit (IC). The cores in this architecture are dened as IP cores, delivered by dierent Tier 1 suppliers. The advantage of using IP cores, for the suppliers, is that their IP is protected while IP of dierent suppliers can be combined on a single IC. In this architecture, each IP core fullls the task of a conventional ECU in a federated architecture. In this way a lot of conventional ECUs are combined together in a single hardware unit. Therefore, this architecture succeeds in the objective of reducing the total number of ECUs and reducing the costs due to the amount of hardware. However, the ECUs that are used are far from generic. Since each SoC represents some specic ECUs, it needs to be customized for each specic vehicle model. The costs could be reduced even further if these SoC are replaced by general purpose Central Processing Units (CPUs) and the customization of each system is done by the use of software blocks instead of using customized hardware.
SoC On-chip network Replacement of ECU in a federated System
Off-chip network
Figure 3.2: Integrated architecture on chip [33] The reason for integrating multiple ECUs in hardware is to create new hardware which is backwards compatible with existing federated architectures [33]. This enables implementing a change from a federated to an integrated architecture in an incremental fashion. In the rst step a few of the ECUs of an existing vehicle can be combined into a single hardware unit, while leaving all other ECUs in the vehicle untouched. This makes it easier for the OEMs to actually implement parts of this architecture into existing designs. However, the goal of this graduation project is not to improve an existing vehicle, but to create a design for an entirely new vehicle using a systems approach. Therefore, the idea proposed in From a Federated to an Integrated Automotive 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 eorts which have been made in the automotive domain in order to shift from a traditional federated architecture to an integrated architecture. The results that have been found in the literature give a view on the current state-of-art and on the main reasoning behind these architectures. The architectures described in these literature sources form a solid base to continue the research in order to propose an architecture that minimises the number of ECUs 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 still drawbacks that need to be addressed.
13
Chapter 4
Integrated Automotive Architecture

The main question answered in this chapter is: What would a desired integrated automotive architecture look like? The starting point for the integrated architecture is based on the results of the literature review described in Chapter 3. The overall system architecture is described in Section 4.1. This architecture consists of a hard- and software architecture, which are described in Section 4.2 and Section 4.3 respectively. The desired properties of the communication protocol are the subject of Section 4.4. Because of the heuristic nature of the systems approach, which has been followed in this project, important aspects like performance, safety and security have been taken into account. Due to the scope of this project these aspects are considered briey, since an exhaustive research on each of these aspects could be captured in separate graduation projects themselves. 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, this chapter is concluded in Section 4.8.
4.1
System Architecture
While the Formula 1 uses a fully centralized architecture where all the intelligence is located in a single ECU which contains all the processing power [43], the desired architecture for the IM01 would use distributed control. The main advantage of distributed control is having processing power available in all nodes. Therefore, certain functions can use localised control, which can be compared to a reex in the human body. In a reex muscles are actuated based on local nerves only, without inuence of the brain. Only after the muscle has been controlled, the brain will be 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 ECU is informed afterwards. Therefore, this kind of control does not only react much faster, it also reduces the network load. The only communication which is needed serves the purpose of informing the central ECU about the action that has been taken, instead of communicating the sensor values to the central ECU rst, waiting for the calculated actuator values and than informing the central ECU once again on the current status. In order to provide this functionality, all the ECUs in the architecture must provide sucient processing power. Another architecture that has been proposed combines the dierent ECUs on a SoC [33]. This does reduce the hardware, but uses very specic hardware for each dierent implementation. The reason for this architecture is to support backward compatibility with existing vehicles and federated architectures. Since the IM01 is designed as a complete new vehicle there is no requirement on backward compatibility. Furthermore, the general trend in the automotive domain is to develop an increasing amount of software- instead of hardware-based solutions [37]. Therefore, the next logical step is to create an architecture that combines the dierent functions in software instead Proof of Concept of an Integrated Automotive Architecture 15
CHAPTER 4. INTEGRATED AUTOMOTIVE ARCHITECTURE
of hardware and thus enabling the usage of general purpose hardware in order to implement the architecture.
System Architecture
Soft ware Architecture
Hardware Architecture
Central ECU Soft ware
Satellite ECU Soft ware
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: a hardware architecture and a software architecture. The hardware architecture for the IM01 is given by a hardware topology that has already been described by InMotion (and is therefore depicted in a dashed block) [17] and will be explained in further detail in Section 4.2. The software architecture consists of two parts which are derived from the given hardware topology. These parts are software for the central ECU and software for the satellite ECUs. The high level architecture for the software is shown in Figure 4.3 and 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 four satellite ECUs. The satellite ECUs are placed in the four corners of the IM01. This reduces the wiring to the sensors and actuators, because the location of most of the sensors and actuators are near one of the vehicles corners. Furthermore, the topology contains two additional function specic ECUs for practical reasons. These additional ECUs are used for the control of the Internal Combustion Engine (ICE) and for the autonomous driving behaviour of the IM01. The ECU that is used to control the ICE is packaged together with the ICE itself and the ECU for the autonomous driving system still needs to be developed in the future. The reason for this is that the objective of InMotion is to realise the IM01 as a vehicle that is controlled by a driver rst and add autonomous driving once the vehicle has been realised. Therefore, the additional ECUs will not be considered as part of the integrated architecture described in this thesis, leading to the reduced topology for the IM01 which is shown in Figure 4.2. The ECUs are interconnected through a network bus for which dierent options are described in Section 4.4.
16
C e n t r a l E C U
S a t e l l i t e E C U
C o m m u n i c ao n b u s
Figure 4.2: Hardware topology for the IM01
4.3
Software Architecture
The software for both types of ECU consist of two layers, the application layer and the Operating System (OS) layer. On the application layer the dierent functions that will be available in the vehicle 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 satellite ECUs and the process part will be running on the central ECU. The OS layer consists of a Real-Time Operating System (RTOS) and the drivers for the dierent ECU-specic hardware. For the central ECU this will only be the driver for the communication device. For the satellite ECUs additional I/O drivers will be used.
Central ECU Vehicle level part of functions (focus on computational power) RTOS Communication drivers Satellite ECU Local level part of functions (focus on I/O operations) Communication drivers RTOS I/O drivers
Communication
Generic Hardware Platform
Generic hardware platform
Figure 4.3: High level software architecture for the IM01 The way the parts of a function are mapped to the dierent ECUs is shown in Figure 4.4. The in- and output part both map to a satellite ECU and the processing part is mapped to the central ECU. If the left and right satellite ECU in Figure 4.4 (containing the green and yellow part) are the same physical ECU for a certain function, localised control (as described in Section 4.1) becomes possible for that function. Figure 4.5 shows a detailed decomposition of a function. A function is executed in a continuous iterative fashion. On the left the input part of a function is shown, which exists of reading the values of the sensors that are used for the function. After reading the inputs, optionally preprocessing of the input can be executed, after which the sensor values are communicated. The processing part receives the (optionally preprocessed) sensor values and starts the processing. In this step dierent dependent functions are allowed to interact, by using data from other functions. The Proof of Concept of an Integrated Automotive Architecture 17
Function Sensors Input Processing Output Actuators
Satellite ECU Local level part of functions (focus on I/O operations) Communication drivers RTOS I/O drivers
Central ECU Vehicle level part of functions (focus on computational power) RTOS Communication drivers
Satellite ECU Local level part of functions (focus on I/O operations) Communication drivers RTOS I/O drivers
Generic Hardware Platform
Figure 4.4: Mapping of software function parts to ECUs processed data is sent to the output part of the function, which optionally applies postprocessing to the data in order to control the actuators. A status update of the current actuator values is communicated back to the processing part for the next iteration of the process. If and only if the in- and output part of a function run on the same satellite ECU, the communication between these parts can skip the processing part, resembling a reex in the human body. The processing from input to output will then take place in the pre- and postprocessing steps.
Function
Input Sensors Inputs (Preprocessing) Communication
Local control only if in- and output steps run on the same ECU
Processing Communication Processing* Communication
Output Communication (Postprocessing) Outputs Communication Actuators
*Interaction with other functions possible
Figure 4.5: Architecture for a software function
4.4
Communication
For the communication between the ECUs dierent network protocols have been considered. Due to the fact that all electronic control functions will run on the integrated architecture, the communication protocol must meet the demands of both safety-critical functions as well as functions that are high demanding regarding the data that needs to be transferred, but which are less safety-critical. A safety-critical function needs guarantees when looking at the real-time behaviour (latency and synchronisation) and robustness of the communication protocol, while a less critical 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 connected ECUs. Since messages are sent arbitrarily, collisions on the network bus can occur if multiple ECUs try 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 messages with a higher priority. Therefore, no guarantees can be given on the message latency, unless the 18 Proof of Concept of an Integrated Automotive Architecture
message has the highest possible priority on the bus. The advantage of an event based protocol, is the systems ability to react instantaneously to a critical situation. Furthermore, the very ecient usage 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 is called Time Division Multiple Access (TDMA) and requires a predened schedule which prevents collisions from happening on the bus. This makes the temporal behaviour of the bus predictable [32]. Each ECU needs to be aware of this schedule and they need to be synchronised in order to prevent collisions from happening. The main advantage of a time triggered protocol is that guarantees can be given on the latency of the messages on the bus, making this type of protocol very suitable for safety-critical control functions. Furthermore, a lost message can be detected more easily when using a time triggered protocol, since it is known when to expect a certain message. This increases the dependability of the network [2]. A general drawback of a time triggered protocol is decreased exibility and scalability, because the schedule needs to be known by all ECUs on forehand. Therefore, a new schedule needs to be composed every time an ECU is added or removed from the system [2]. However, this will not be a major issue with the topology described in Section 4.2, because the number of ECUs is xed. First of all, an important aspect of the desired communication protocol is the real-time behaviour, which means the predictability of the temporal behaviour. Because safety-critical distributed control functions will run on the integrated architecture, the communication needs to be time triggered instead of event based. Secondly, safety-critical functions require a robust networking protocol, since there is no tolerance for errors. Even if a fault occurs the function must ensure the safety. Robustness of the communication protocol ensures the correctness of the transmitted data, which increases the fault-tolerance of the overall system [26]. The available bandwidth of the communication network is also a very important aspect. Because all the functions communicate over a single bus in the integrated architecture, this bus needs to be able to transmit enormous amounts of data. This is only possible if the communication protocol for this bus has sucient bandwidth available. Taking everything into account, the most suitable type of communication protocol is a time triggered protocol. This type of protocol is preferred when real-time distributed control is preformed because of its predictable temporal properties.
4.5
Performance
Performance is an important aspect to take into account when preforming real-time distributed control. Especially when all functions of the vehicle are integrated in an architecture with minimal hardware. This will lead to increased communication and the ECUs processing power must be sucient 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 can be identied [2]: Sensor delay (S ): The delay between the reading of a sensor and the availability of its input value for the ECU. Communication delay (C ): The delay between sending data from one ECU and receiving it by another. Processing delay (P pre ,P ,P post ): The delay between the availability of the desired input data and the calculated output. Actuator delay (A ): The delay between the availability of a calculated output value and the actual movement of the actuator. These delays add up to a total I/O latency for a single function. If a function runs entirely on a single ECU, like for the reex analogy described in Section 4.3 the minimal latency (Tmin ) for that function is given by: Tmin = S + P + A (4.1) Proof of Concept of an Integrated Automotive Architecture 19
However, the worst case latency (Tmax ) for a function which requires both pre- and postprocessing is given by: Tmax = S + P pre + C 1 + P + C 2 + P post + A (4.2) This shows that the performance gain by running a function completely on a single satellite ECU is 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 desired precision of a real-time function like active suspension, active aerodynamics or braking is about 10 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 be implemented on the IM01.
4.6
Safety
Certain safety aspects are inherent to the design of the proposed integrated architecture. Because the architecture has computational power both in the central ECU as well as in the satellite ECUs, redundancy for safety-critical functions can be implemented in software instead of hardware. A safety-critical function that executes on the central ECU and communicates to the satellite ECUs, can also be available on the satellite ECUs as a, normally unused, back-up function. Whenever the central ECU or a communication-link fails and the satellite ECU does not receive the expected data anymore (which can easily be detected in a time-triggered communication protocol, as described in Section 4.4), the back-up function can take over the computations. If the computational power needed for the back-up functions of the safety-critical systems is larger than the unused available computation power at that satellite ECU, non-safety-critical functions that are running on that satellite ECU can be temporarily disabled. This ensures a safe operation for the safety-critical functions. This back-up mechanism can be implemented in the RTOS layer of each ECU. This mechanism can not be implemented when the architecture would use customized hardware for each function, like in the architecture described in Section 3.3, unless the hardware itself is redundantly implemented. It is also not possible to implement this mechanism on an architecture that has only a single ECU that is powerful enough to run the functions, like described in Section 3.2. In order to give guarantees concerning additional safety aspects, the proposed architecture needs further investigation. Due to limited time this falls outside the scope of this graduation project. Furthermore, some additional safety aspects, such as the redundant implementation of certain soft- or hardware parts, are a trade-o between safety and costs and can be decided upon during implementation. A more detailed safety argumentation of a single function is given in Section 6.3.
4.7
Security
A potential drawback of an integrated architecture that uses general purpose hardware can be identied when looking at the security aspect. This is especially the case when such an architecture becomes an automotive standard that is adopted by various OEMs. Currently the de facto industry standard regarding the communication protocol is CAN. This is an open protocol, which makes it very straightforward to add custom hardware to an existing CAN bus. As described in Chapter 2, the CAN specication only species the way a CAN frame looks. It does not specify which IDs are being used on the bus and what data is contained in which specic frame. Each automotive OEM uses a specic protocol on top of CAN to specify these frames. In order to breach security via the CAN bus, the CAN bus of the targeted vehicle needs to be reverse-engineered. With the knowledge gained from such an operation, specic 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 aerodynamics engineer within InMotion.
20
In order to verify this, experiments have been conducted on a Volkswagen Lupo within this project. First of all, the CAN bus of the Lupo has been monitored in order to see what CAN frames were used by the vehicle for certain functions. With this information CAN frames with the same IDs that the vehicle uses, but with false data have been sent via the CAN bus. When this false data is sent very fast and repeatedly, it becomes possible to block the actual data from getting through. This enables the taking over of certain controls as the brake pedal or the gear lever. Reverse engineering of an Existing CAN bus can only be done with physical access to the vehicle and only yields information about a vehicle of a specic make and model. However, if the hardware used in future vehicles is standardised hardware, reverse engineering a single vehicle yields enough information in order to gain unauthorized access to a whole range of vehicles. Therefore, before implementing an integrated automotive architecture, an intelligent assessment has to be made on what aspects need to be standardised and what aspects need to remain OEM or even model specic. This will not be taken into account for the PoC described in the next chapter, since the goal of the PoC is 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 integrated automotive architecture look like? This question is answered by describing the designed architecture together with its advantages with respect to the alternatives that have been investigated in Chapter 3. A description of both the hard- and software architecture has been given, after which the desired properties of the communication bus have been explained. The performance of certain modes of operation within the architecture has been shown and a view on how the architecture ensures the safety aspect is given. A concern on the security aspect of the proposed architecture has 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 automotive architecture has been described, the next chapter will contain an description of the PoC in which this architecture has been implemented in order to prove its feasibility.
21
Chapter 5
Proof of Concept
To answer the main research question and thus prove that the designed architecture meets its requirements, a PoC has been implemented. This chapter describes the steps taken to implement this PoC and discusses the design choices that have been made. Firstly, Section 5.1 describes three use cases that have been dened to test the PoC. Then all the choices and considerations concerning the implementation are described in Section 5.2. Finally this chapter is concluded in Section 5.3. The main question answered in this chapter is: What is needed to prove the feasibility of the proposed integrated architecture?
5.1
Use Cases
In order to test the PoC and prove the designed architectures ability to execute several functions using both central as well as local control, the following three use cases have been dened: active aerodynamic control, ABS and power windows. The control strategies are simplied models of the systems that can be implemented on the IM01 or a production vehicle. The control strategy for the active aerodynamics use case has been discussed with the aerodynamics engineer within the InMotion team. The strategy for the ABS has been developed together with the engineer responsible for the overall braking system of the IM01. The power window system has been developed using preliminary knowledge about power windows on a production vehicle. The chosen use cases are interdependent systems because they communicate data over the CAN bus and share several sensors and actuators. The active aerodynamics use case is a system that uses distributed control. While most of its control takes place on the central ECU there is also an input on a satellite ECU that is coupled directly to the actuator on that same ECU. The ABS use case demonstrates central control, for this system the satellite ECUs only communicate with 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 overridden by higher priority models running on the central ECU.
5.1.1
Active Aerodynamics System
The rst use case that has been dened is the active aerodynamics system. The purpose of this system is to inuence the vehicles aerodynamic properties at dierent speeds. In order to transfer the power generated by the electric motors or ICE to the road, traction is needed. The more traction, the more power can be transferred without causing the wheels of a vehicle to spin upon acceleration. One way of generating additional traction in a car is using its aerodynamic shape in order to generate downforce. The unwanted side-eect of generating downforce is that by the same aerodynamic shape drag is created as well. Drag is the force which is needed to move an object through air (also known as air resistance). Thus, increasing the downforce of a vehicle also increases the drag, making it harder to move the vehicle through the air. Since the downforce and Proof of Concept of an Integrated Automotive Architecture 23
CHAPTER 5. PROOF OF CONCEPT
drag of a vehicle are coupled, reducing the drag would also mean reducing the downforce. The inuence of this eect can be reduced by using active aerodynamics, changing the aerodynamic shape of the vehicle as a function of predened inputs.
Brake pedal
Wheel speed sensor
Wing angle actuator
Steering angle sensor
Electronic controller
Figure 5.1: Active aerodynamics system schematic Figure 5.1 shows the schematic of an active aerodynamics system. The inputs to the system consist of four wheel speed sensors to measure the vehicles speed, the brake pedal sensor to detect if the driver is braking and the steering angle sensor to determine if the vehicle is taking a corner or if it is traveling along a straight line by its steering angle. The output is an actuator that regulates the angle of the rear wing. Both the downforce and drag of the vehicle are directly proportional 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 smaller the angle of the wing becomes; this reduces the drag at high speeds. The angle of the wing will start to decrease only after a certain speed threshold; this ensures maximum downforce during acceleration. Steering angle: Above a certain threshold of the steering angle, increase the angle of the wing for more downforce (even if the speed is still high); this increases traction and thus stability in high-speed corners. Brake pedal: Instantly increase the angle of the wing to its maximum if the brake pedal is pressed; 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 four wheels are not the same. This eect is called slip and is caused by the inertia of the vehicle. The slip percentage of a single wheel is given by Equation 5.1. While braking, a certain amount of slip is allowed, but when the slip becomes too large1 (typically above 20% in practice) the wheels will lock up. When the wheels lock up, the friction with respect to the road is reduced, decreasing the braking force. The objective of the ABS is to prevent the wheels from locking up, by regulating the brake pressure depending on the calculated slip. The brake pressure will drop if the slip exceeds a
1 Typically a threshold of around 20% is used in practice, because an eectively shortened stopping distance, while maintaining steering controllability, is achieved if the slip is kept between 8% and 30% [45].
24
predened threshold, releasing the wheel that has the risk of locking up. By releasing this wheel, its wheel speed will increase thereby reducing the slip value again. V ehicle speed W heel speed 100 (5.1) V ehicle speed As shown in Equation 5.1, the inputs needed by the ABS in order to calculate the slip are the individual wheel speeds and the vehicle speed. The vehicle speed for the PoC is an average of the individual wheel speeds, but on an actual vehicle this value could be enhanced by the application of sensor fusion. In this way additional sources, like pitot tubes or the Global Positioning System (GPS) can be added to the system. Figure 5.2 shows that the brake pedal is also an input to the ABS controller. The output of the ABS is a control signal to the hydraulic unit that regulates the brake pressure. For the PoC this output is modelled as a binary signal per ECU that actuates the brakes rather than a pressure regulation signal for the hydraulic unit, but the main principle of the system and the calculations by the controller remain the same. The control strategy rules for determining the systems outputs are: Slip % = Brake pedal: The brakes will be engaged if and only if the brake pedal is pressed. Slip: The brakes will only be engaged on the wheels for which the slip value is smaller than a certain predened percentage (normally 20%); if the slip value exceeds this threshold the brakes are released until the slip is below the threshold again.
Brake pedal
Wheel speed sensor
Hydraulic unit
Figure 5.2: ABS schematic
5.1.3
Power Windows System
Power windows are a very well known electronic system in the automotive domain. The very rst implementation of a power window system appeared 37 years before the rst ECU has been introduced. The 1940 Packard 180 contained the rst power window system, which back then was a hydro-electric system that didnt need an ECU to operate. A lot has changed over time, like in all automotive system, in todays power window systems, the ECU plays a central role. The schematic overview of a modern power window system is shown in Figure 5.3. The power windows are controlled by two buttons per window. When the up button is pressed, the corresponding window moves up and when the down button is pressed the window moves down. However, when the ECU receives a command from another controller preventing the windows to move, the buttons will be disabled. An example of such a command is an airbag ECU closing the windows when a crash is detected in order to prevent the passengers to get thrown out of the vehicle. Proof of Concept of an Integrated Automotive Architecture 25
The control strategy rules for the power windows use case in the PoC have been dened as follows: Buttons: The window will move in the direction of the button that is pushed. The window will keep its current position if no button is pushed or if both buttons are pushed simultaneously. Limits: The window will not exceed its limits. If the up button is pushed when the window is in the maximum position, or the down button is pushed when the window is in the minimum position, the window will not be actuated. Communication: The current position of the window will be communicated over the CAN bus. The window controls can be overridden by an external function with higher priority, this will also be communicated over the CAN bus.
Servo actuator
Up and down buttons
Figure 5.3: Power windows schematic
5.2
5.2.1
Implementation
Hardware Setup
The hardware used for the PoC exists of three main parts. The computational part of the ECUs are the most important part. In order to meet the goal of using standardised hardware the choice was made to use generic Intel x86 based personal computers to represent this part. The second part are the communication devices to interconnect the ECUs. The protocol that has been chosen for the communication is the CAN bus. This decision is based on both experience and costs of the available hardware. In order to interact with the sensors and actuators, custom I/O interface boards have been designed and built for the PoC, which form the third part. These boards are connected through the parallel port because this provides enough digital I/O pins and makes implementing driver software in C code for these boards a straightforward task. The hardware setup used to implement the PoC is shown in Figure 5.4 and each of the parts shown in this gure will be described in the following sections. 26 Proof of Concept of an Integrated Automotive Architecture
Front satellite ECU

I/O Interface board
Front satellite ECU

I/O Interface board
Parallel port
Central ECU
Parallel port
Dell precision 380 Intel Pentium 4 3.20GHz 2 GB RAM
Dell precision 380 Intel pentium 4 3.20 GHz 4 GB RAM
Dell precision 380 Intel pentium 4 3.20 GHz 2 GB RAM
USB
USB
USB
MCP2515 DM-BM CAN board
CAN bus
Time Master
MCP2515 DM-BM CAN board Tiny-CAN I-XL CAN Monitor
Figure 5.4: Block diagram of hardware used for the PoC
Simplifying assumption In order to reduce the hardware needed to implement the PoC, it consists of a half vehicle model. A half vehicle model suces to demonstrate the principles of the architecture proposed in Chapter 4. A choice was made to use a single front and a single rear satellite ECU instead of a front left, front right, rear left and rear right. This choice is justied by the fact that systems dened in the use cases, which are described in Section 5.1, are symmetrical. Therefore, the satellite ECUs on the right and those on the left become full duplicates. This assumption holds for the created PoC, but that does not mean that it is true in general. When the architecture will be implemented in an actual vehicle still ve ECUs are needed.
Electronic Control Units The x86 platform has been chosen to provide enough computing power to run multiple functions on a single CPU in the rst place. Furthermore, the community support for the Linux OS for this platform makes developing the PoC on x86 platforms very attractive. Standard Personal Computers (PCs) equipped with an Intel Pentium 4 3.20GHz CPU are used to represent the ECUs. The chosen memory sizes are 4GB for the central and 2GB for the satellite ECUs. These computers have been chosen because of the availability. Additionally, the processing power is more than sucient for the models that will be used for the PoC. Alternative hardware has also been considered, like the Janztec emPC-X1600 [3], which is an embedded computer equipped with CAN and therefore a really suitable platform for the PoC. However the added value of these platforms, compared to the PCs, was not worth the costly investment. Another advantage of the x86 platform is that when more computing power is demanded for the actual implementation, the x86 platform can still be used, since more powerful and multi-core x86 based CPUs are readily available, keeping the software architecture (almost) unchanged. Proof of Concept of an Integrated Automotive Architecture 27
Communication boards Due to experience and low costs, the CAN bus will be used for inter-ECU communication. FlexRay [11] and automotive ethernet have also been considered as alternative options. The available FlexRay hardware for a desktop PC, running Linux was very expensive at the time the PoC was implemented and was therefore not a viable option. Automotive ethernet is still in development, and currently mainly used for infotainment and driver assistant systems [9], which are both nonsafety-critical. The advantage of automotive ethernet is the large bandwidth, however it lacks some of the mechanisms that ensure robustness, which are available in CAN and FlexRay. Therefore, CAN has been chosen for the PoC. The setup which has been implemented, is shown in Figure 5.5. It was chosen to use the Microchip MCP2515DM-BM CAN bus demo boards. These boards are low cost Universal Serial Bus (USB)-CAN demo boards, which oer a lot of exibility due to the availability of open source rmware. The main components of the MCP2515DM-BM are: a PIC18F4550 microcontroller, a MCP2515 CAN controller and a MCP2551 CAN transceiver. The microcontroller on these boards can be reprogrammed to the users needs and the original rmware is open source and available from the Microchip website. In this way the time triggered synchronisation protocol can be programmed in the rmware. Therefore, the applications on the ECUs do not need to be bothered with the synchronisation issues. Ideal synchronised communication can be assumed by the applications. Furthermore, a Tiny-CAN I-XL USB-CAN board is used as CAN monitor to inspect all the frames on the bus.
Tiny-CAN I-XL USB-CAN monitor CAN bus
PIC18F4550 microcontroller
MCP2551 CAN transciever
MCP2515 CAN controller
MCP2515DM-BM CAN bus demo board
Figure 5.5: Microchip MCP2515DM-BM board setup
I/O Interface Boards The I/O boards that provide an interface between the ECU and the sensors and actuators used in the PoC, have been designed within this project. Each satellite ECU is equipped with a custom I/O interface board. Figure 5.6 shows the I/O interface boards, with all the in- and outputs needed for the PoC. The detailed schematics of both interface boards can be found in Appendix A. Figure A.1 shows the schematic for the interface board of the front ECU and the schematic for the rear ECU can be found in A.2. The interface board for the front ECU consists of an analog-to-digital converter connected through a Serial Peripheral Interface (SPI) [31] bus, a digital input and a digital output. The interface board for the rear ECU combines the same I/O as the interface board for the front ECU with a servo motor controller connected through an Inter-Integrated Circuit (I2 C) [39] bus and two additional digital inputs. The connection used to connect the interface boards to the ECUs is the parallel port. 28 Proof of Concept of an Integrated Automotive Architecture
Rear brake actuator LED Window servo actuator output Up button Down button
Front brake actuator LED
Brake pedal
Wing servo actuator output
Rear wheel speed input Front wheel speed input Enable active aerodynamics switch Steering angle input
Figure 5.6: I/O Interface Boards
5.2.2
Software Setup
The software used to implement the PoC consists of a RTOS, C Code generated from Simulink models, USB-CAN drivers, CAN rmware and I/O drivers. Which part of the software runs on which hardware is shown in Figure 5.7. Each of theses parts will be described in further detail in the following sections.
Real-Time Operating System The RTOS chosen for the PoC is a Linux based OS. Linux provides a lightweight OS, runs on multiple embedded platforms, supports an enormous amount of hardware, has great community support and is open-source and free to use. Other RTOSs (such as Windows Embedded and C/OS-II) have been considered, but they either require expensive licenses or lack hardware support. A drawback of a standard Linux kernel is that it is not real-time, as it does not provide any guarantees that deadlines set for the applications are eectively met [46]. In order to convert a standard Linux distribution into a RTOS, two primary options have been investigated for the PoC: Real-Time Linux (RTLinux) [5] and Real-Time Application Interface (RTAI) [36]. Actually RTAI is based on RTLinux but oers some additional advantages over RTLinux such as an improved maintainability and MATLAB Simulink support. Both systems run a small realtime kernel besides the standard Linux kernel in which the standard Linux kernel is treated as the lowest priority real-time task. Other real-time tasks are implemented as kernel modules in both systems. Where RTLinux applies the changes directly to the source les of the standard Linux kernel, RTAI introduces a Hardware Abstraction Layer (HAL). This HAL consists of a structure of pointers to interrupt vectors in order to handle hardware interrupts. The advantage of introducing a HAL, instead of applying the changes to the kernel directly, is that the changes to the standard kernel are minimized. This improves the maintainability of both RTAI and the standard kernel and oers the possibility to revert to the standard kernel at any given time for debugging purposes. The most important reason to choose for RTAI over other options, is that RTAI comes equipped with RTAI-Lab, which enables the support of running C code generated from MATLAB Simulink directly as a real-time task. The PoC uses Fedora Core 15, which oers kernel version 2.6.38 by default. This is the latest stable x86 kernel supported by RTAI 3.9.1. RTAI 3.9.1 was the latest stable version at the time of realisation of the PoC. Proof of Concept of an Integrated Automotive Architecture 29
Front satellite ECU
Front satellite ECU
Parallel port I/O Drivers ---------------------------------Linux RTAI Realtime Simulink Model ---------------------------------USB-CAN Drivers
Central ECU
Linux RTAI Realtime Simulink Model ----------------------------------
Parallel port I/O Drivers ---------------------------------Linux RTAI Realtime Simulink Model ---------------------------------USB-CAN Drivers
USB-CAN Drivers USB Time Triggered CAN Firmware
USB Time Triggered CAN Firmware
USB Time Triggered CAN Firmware
CAN bus
Time Master
Time Master CAN Firmware CAN Monitor Software
Figure 5.7: Block diagram of software running on the PoC
USB-CAN Drivers Device drivers are needed in order to control the MCP2515DM-BM boards described in Section 5.2.1. The driver package supplied by Microchip contains only Windows drivers and Microchip provides no Linux support. Therefore, customized drivers have been developed within this project. The diagrams that describe the behaviour of the USB-CAN drivers can be found in Appendix B.1. These drivers are based on libusb [35]. Libusb is an open-source C library that gives applications easy access to USB devices on dierent operating systems. The usage of libusb implies that kernel drivers are not needed and thus no threat is caused to the real-time behaviour of the Linux kernel. In order to develop the drivers, the open-source rmware has been used as a source of information. The drivers have a volume of around 500 LoC. CAN Firmware The original rmware that was supplied with the MCP2515DM-BM boards consists of a polling loop which handles all the functions. A owchart of this rmware can be found in Figure B.4 in Appendix B.2. It checks a USB buer for incoming USB messages rst and executes a USB handler depending on the existence of these messages. After that it follows the same procedure for CAN frames. This means that the execution of the loop does not take a constant amount of time. This variance in time is an unwanted property when the boards are used in a real-time system. Therefore, the rmware has been rewritten to an interrupt based version, of which a owchart can be found in Figure B.5. In order to realise this, the polling loop has been removed and the interrupts for incoming USB and CAN have been enabled. Whenever an incoming USB message or CAN frame is detected, an interrupt is generated and the corresponding handler code is executed. In this way the temporal behaviour of each of the handlers becomes predictable. Furthermore, the time triggered protocol layer, based on TTCAN principles, has been implemented in the rmware as well. This protocol layer is responsible for the time triggered communication 30 Proof of Concept of an Integrated Automotive Architecture
and synchronisation and its way of working is described in Section 5.2.3. The modied CAN rmware has a volume of around 2.500 LoC for each board connected to an ECU. As will be explained in Section 5.2.3, another MCP2515DM-BM board will be used as stand-alone timemaster for synchronisation purposes. This board runs around 1.250 LoC, since no USB support is implemented and the board only oers CAN functionality. I/O Drivers The I/O interface boards are connected to the ECUs through the parallel port because programming I/O communication via this port in C is straightforward. In order to communicate with these boards a parallel port driver is created that consists of three parts: a part that handles the I/O using the I2 C protocol, a part that uses the SPI protocol and a part that is responsible for the direct digital signals. Diagrams that describe the behaviour of the drivers, together with an explanation of how the I2 C and SPI protocols have been realized, can be found in Appendix B.3. All parts of the I/O drivers are implemented using C code, which makes the process of including these drivers in the application code very straightforward. In this way, the drivers actually consist of a library of functions which are available to the C applications. The I/O drivers have a volume of around 300 LoC, which is divided evenly over the SPI and I2 C parts. MATLAB Simulink The applications that run on the ECUs are created as MATLAB Simulink models. Embedded Coder, which is part of MATLAB Simulink, serves the purpose of creating source code for embedded platforms from Simulink models. Using Embedded Coder, together with modied RTAI templates, C code is generated from these models. Because of the use of RTAI provided templates which are modied for the target hardware, the generated C code is directly compilable and executable on the ECUs. The modication of these templates automatically includes the driver libraries created for the CAN and I/O hardware. The only alteration that still needs to be done by hand is the linking of the available CAN and I/O driver functions to the correct in- and outputs of the Simulink model. All models for the PoC are created using the latest MATLAB version currently available: MATLAB R2013a. The C code generated from the Simulink models consists of 2.500 to 3.000 LoC per ECU. Developed software As described above, software needed to be developed within this project in order to be able to implement the PoC. To summarise, the amount of software that has been developed for the PoC is shown in Table 5.1. USB-CAN drivers CAN rmware I/O drivers Electronic functions Total 500 LoC 2.500 LoC 300 LoC 9.000 LoC 12.300 LoC
Table 5.1: Amount of software developed
5.2.3
Design Choices
Synchronisation In order to synchronise the communication of the ECUs, a time triggered communication protocol has been implemented in the rmware of the CAN communication boards. It has been chosen to Proof of Concept of an Integrated Automotive Architecture 31
implement this layer on top of the CAN protocol inside the rmware of the boards, because the applications that run on the dierent ECUs can run with their own timer. They do not need to be bothered with the synchronisation issues and can assume ideal communication. The principle of the synchronisation mechanism is shown in Figure 5.8 for two electronic functions. Inside the rmware a hardware timer has been used to generate an interrupt, which forms the internal clock. In order to synchronise the clocks of the dierent CAN boards, a time-master board sends out a CAN timer-reset frame periodically. Each board has the communication schedule available, so when the timer of an individual board reaches the point in time that this board is supposed to send a message, a CAN frame will be transmitted. This frame contains the latest information that is stored in a local buer. This buer will be updated by the ECU, making use of USB messages. Whenever a CAN frame is put on the bus, it is received by all other boards that are connected. These boards send the content of the CAN frame directly to the ECU, also using the USB connection.
Part of electronic function (Simulink model)
B
USB message
A B
Buffer for outgoing CAN frames in CAN firmware
A
Incoming CAN frame
USB-CAN driver
CAN data frames
CAN data frames MCP2515DM-BM Timer-reset frames
A B
Electronic function A Electronic function B Stand-alone time master
Figure 5.8: Synchronisation mechanism
Multiple models on a single ECU The code generated from each Simulink model will run on a Linux machine as a separate process. Libusb, which is used as a base for the CAN driver is based on the Linux USB kernel driver. This driver does not allow multiple processes to communicate with a single device at the same time, which means only one model can communicate with the CAN hardware at any given time. In order to allow multiple functions to run on the same ECU simultaneously, while they all use the same CAN hardware, there are a few possible solutions that have been evaluated: Open and close the USB connection each time a model wants to update the buer Combine multiple Simulink models into a single (large) model Combine multiple generated C code sources into a single process Write a custom Linux kernel USB driver Use a separate USB-CAN device for each model 32 Proof of Concept of an Integrated Automotive Architecture
The advantage of opening and closing the USB connection each time a model wants to update the buer, is that the implementation is very straightforward, as the created driver library contains functions to open and close the USB connection. However, the time that opening and closing the connection takes (due to initialization of the driver) will greatly increase the communication delay for each time the ECU updates the data-buer over the USB connection. This will negatively aect the performance of the complete PoC and the timing requirements will probably not be met. This means that this solution is not desired for the PoC. Combining multiple Simulink models into a single model could result in a very large and possibly slow model when a complete vehicle is implemented. Furthermore, it is not possible to give dierent models (and thus functions) dierent priorities. Another eect of this solution is that all functions will run on a single sampling time, there is no dierence between models that need to react within milliseconds and the ones that will suce with an update frequency of seconds. Finally this option reduces the exibility and scalability. Each time a small change to a single function is made code needs to be generated for the complete system. This means that this solution will not be suitable for a nal implementation of a complete system, however the aspects mentioned are not important for the PoC and implementation is very straightforward. Therefore, this option is suitable for the PoC. Combining multiple generated C code sources into a single process, is based on a tool that is able to merge the separate source code les automatically [44]. However, such a tool still needs further development in order to be of practical for use. Currently, the available tool still requires a lot of manual code editing, which makes the entire process quite cumbersome. If such a tool where to be developed in the future, this solution might prove very useful for a nal implementation. However, due to the restricted time available this solution is not desirable for the PoC. Writing a custom Linux kernel USB driver might be a suitable solution for the PoC. However the lack of knowledge in this eld might result in a driver which is not as stable as the provided driver. Therefore, both the real-time behaviour and the reliability of the PoC might be at danger. Furthermore, this process might take such a large amount of time that it does not t within the time available for this project. Therefore, this is not a desired solution for the PoC. Using a separate USB-CAN device for each model might be a solution for the PoC since only three models are being used. However, it is not a very realistic and practical solution since the goal of the project was to reduce the amount of hardware. Concluding, the best solution for the PoC is to combine multiple Simulink models into a single model. However, one should keep in mind that an actual implementation of the system will not be using personal computers as ECUs, but embedded systems. Therefore, the communication hardware will probably not be connected through an USB bus, eliminating the problem for a nal implementation altogether. Timing Schedule In Figure 5.9 it is shown which sensors and actuators are connected to the dierent satellite ECUs. Using this gure, the signals that each ECU transmits over the CAN bus have been dened. These signals have been used in order to create a communication schedule. The following signals have been dened: Central ECU: Wing angle Brakes engaged (front and rear) Window open Window close Front satellite ECU: Front wheel speed Steering angle Brake pedal status Rear satellite ECU: Rear wheel speed Window position Based on these signals two communication schedules have been considered. Firstly a communication schedule in which each signal has a private CAN ID. In this schedule all the ECUs on the Proof of Concept of an Integrated Automotive Architecture 33
Front wheel speed (SPI protocol)
Central ECU
Down button (1 bit signal)
Rear wheel speed (SPI protocol) Up button (1 bit signal)

Enable active aerodynamics (1 bit signal)
Steering angle (SPI protocol) Brake pedal (1 bit signal)
Satellite ECU (Front)

Front brake actuator (1 bit signal)
CAN bus
Satellite ECU (Rear)

Rear brake actuator (1 bit signal)
Wing servo actuators (I2C protocol)
Window servo actuator (I2C protocol)
Figure 5.9: In- and output signals used by the PoC bus know which signal is corresponding to which CAN ID. In order to transfer all the information over the bus, ten separate CAN frames have to be sent (nine dierent signals as listed above and a timer reset frame). As explained in Section 2.3.1, each CAN frame contains at least 52 bits, which is also true for the single bit signals. This creates a large amount of overhead on the bus. Furthermore, experiments with the MCP2515DM-BM boards showed that the latency of sending a USB message from one ECU to receiving the sent data on another is around 20 ms. It is clear that when sending ten CAN frames the overall latency becomes unacceptable. For the reason mentioned above, a dierent schedule has been considered, in which each ECU has a private CAN ID instead of each signal. In the CAN frame of a single ECU all the signals from that ECU are being combined. By using this schedule, only four CAN frames (three2 data frames from the ECUs and a timer reset frame) are needed to send the same information. This means that the overhead on the bus is greatly reduced. Figure 5.10a shows the original schedule which has been composed this way. The red arrow indicates the latest moment in the cycle on which a change to an input will be communicated in that same cycle. The green arrow indicates the moment that all required input information is available at the central ECU in order to calculate the corresponding output. In this scheme it is shown that this moment occurs after the central ECU transmitted its information. Therefore, a change in the output as result of a certain input will be observed the next cycle. This means that the communication latency is 25 ms (30 ms for the cycle time minus 5 ms at which the red arrow is located) plus 15 ms, which is the moment in time the output is communicated by the central ECU in the next cycle. This sums up to a total minimum latency of 40 ms. However, in the worst case situation, an input at the front satellite ECU is changed just later than 10 ms after a new cycle started, in that case it will take 30 ms (the next cycle) until this change is communicated by the front satellite ECU. At that point in time the situation is the same as for the minimum latency. Thus, the worst case latency is 30 ms + 40 ms = 70 ms. Figure 5.10b shows an improved schedule in which the open frame is enlarged and moved forward. In this way the green arrow occurs before the central ECU starts communicating, therefore the minimum communication latency is only 26 ms (28 ms at which the central ECU communicates the output, minus 2ms at which the red arrow is located). For this schedule also the worst case scenario is that the input at the front satellite is changed just after the frame for that ECU has passed. In this case also the cycle time needs to be added to the minimum latency. This results in a worst case latency of 26 ms + 30 ms = 56 ms.
5.2.4
Implementation of the Use Cases
As described in Section 5.2.2, the functions which represent the use cases are implemented as MATLAB Simulink models. As argumented in Section 5.2.3, all the functions are combined in a
2 For the PoC only three data frames are needed. This results from the simplifying assumption described in Section 5.2.1
34
Legend:
Time master
Front satellite
Rear satellite
Central ECU
Open frame
USB-CAN delay
0 ms
5 ms
10 ms
15 ms
20 ms
30 ms
(a) Original communication schedule

USB-CAN delay
0 ms
2 ms
4 ms
6 ms
28 ms
30 ms
(b) Improved communication schedule
Figure 5.10: Communication schedules
single model per ECU. This means that in total three Simulink models have been created for the PoC. One for the central ECU and one for each of the satellite ECUs. Figure 5.11 shows the Simulink model for the central ECU. This model contains two major subsystems: The ABS controller and the active aerodynamics controller. These subsystems each represent the processing part of the functions they belong to, as is indicated by the red block in Figure 4.4. Furthermore, the model contains two CAN unpack blocks (shown in green), which unpack the CAN frames that are received from the rear and front satellite ECUs and send the signals contained in the frames to the subsystems. In the right a blue block depicts the CAN pack block, which packs all the output signals in a CAN frame.
WheelspeedFront WheelSpeedRear
WheelSpeedFront WingAngle WheelSpeedRear SteeringAngle

WindowClose WingAngle
WheelSpeedFront CAN Msg Message: ECU2 Standard ID: 512

ECU2
SteeringAngle BrakePedal
SteeringAngle BrakePedal
BrakePedal
WindowClose WingAngle BrakeEngagedFront BrakeEngagedRear WindowOpen WindowClose
1
CANMsgIn
Active Aero Controller
0
WheelSpeedRear CAN Msg Message: ECU3 Standard ID: 768 WindowPosition
ECU3 WheelSpeedRear BrakeEngagedRear BrakePedal WheelspeedFront BrakeEngagedFront
Message: ECU1 Standard ID: 256
CAN Msg
1
CANMsgOut
ECU1
ABS Controller
Figure 5.11: Central ECU model
Figure 5.12 shows the Simulink model for the front satellite controller, which only contains a CAN pack and unpack block. This ECU basically only packs inputs to send them over the CAN bus and receives CAN frames from the central controller in order to actuate the brake output. This means that the functions which are used for the PoC and which have their input part (which is shown on the left side of Figure 4.5) on this satellite ECU, do not make use of preprocessing. This Simulink model contains the green block which is shown in Figure 4.4 for the active aerodynamics and ABS functions. Proof of Concept of an Integrated Automotive Architecture 35
BrakeEngagedOut
1
CANMsgIn
CAN Msg
BrakeEngagedFront BrakeEngagedRear Message: ECU1 WingAngle Standard ID: 256 WindowOpen WindowClose
ECU1
2
WheelSpeedFrontIn
WheelSpeedFront SteeringAngle BrakePedal

ECU2
3
SteeringAngleIn
CAN Msg
1
CANMsgOut
4
BrakePedalIn
Figure 5.12: Front satellite ECU model
Figure 5.13 shows the Simulink model for the rear satellite controller. This model contains both a CAN pack and unpack block for communication, a major subsystem which handles the control for the power window system locally and two smaller subsystems for postprocessing the values that control the connected actuators. The power windows subsystem on this satellite ECU demonstrates localised control (shown in Figure 4.5 as a the input and output parts connected by the dotted line). It controls an output based on inputs which are available locally. The smaller white subsystems represent the postprocessing for the active aerodynamics and power window system (shown in Figure 4.4 as the yellow block).
1
CANMsgIn
CAN Msg
BrakeEngagedFront BrakeEngagedRear WingAngle WindowOpen WindowClose
2
[deg] Enable
BrakeEngagedOut
ServoPos
3
ServoPositionOut
ECU1
Angle -> Servo
2
EnableActiveAeroIn
Close Open
[%]
WindowPos
4
WindowPositionOut
4
ButtonUpIn
ButtonUp ButtonDown
Percentage -> Servo
5
ButtonDownIn
Electric Window Controller
WindowPosition Message: ECU3 Standard ID: 768 CAN Msg
1
CANMsgOut
3
WheelSpeedRearIn
WheelSpeedRear
ECU3
Figure 5.13: Rear satellite ECU model
36
5.3
Conclusion
This chapter describes the steps that have been taken in order to create a PoC which shows the feasibility of the integrated architecture that has been proposed in Chapter 4. Firstly three use cases have been dened which together show the most important properties of the integrated architecture. The ABS shows a system that is completely controlled on the central ECU, whereas the active aerodynamics system has its control spread over both local and the central ECUs. The power window system uses purely local control. Furthermore, these use cases share a lot of in- and outputs and communicate data over the network protocol. They are therefore inter-dependant systems. A description of the hard- and software setup that is used to realise the PoC is given, along with the motivation as to why this hard- and software has been chosen. Furthermore, the design choices that have been made are described, together with their alternatives. Finally, it is stated how the functions that correspond with the use cases have been implemented on the PoC. This chapter therefore gives a description on how the PoC that proves the feasibility of the integrated architecture has been realised and thus answers the question: What is needed to prove the feasibility of the proposed integrated architecture? The way in which this PoC is used to check if the integrated architecture meets the requirements is the subject of the following chapter.
37
Chapter 6
Validation
This chapter describes the validation of the PoC by verifying its functional correctness and measuring its performance. The main question answered in this chapter is: Does the PoC meet the requirements? Section 6.1 describes the simulation models which have been used, together with the simulation results. Because the systems approach used in this project takes the aspects of performance, safety and security into account, these aspects are covered briey in the following sections. Section 6.2 describes both the functional and performance testing and presents the results of these tests. A safety case has been dened for one of the electronic functions. This shows how the safety of each function can be validated when an integrated architecture, described in Chapter 4, would be implemented. The way this safety case has been built is described in Section 6.3. Security is not taken into account, because this is not a concern for the PoC, as has been described in Section 4.7. Finally, this chapter is concluded in Section 6.4.
6.1
Simulation
The MATLAB Simulink models that have been created to generate the C code for the PoC, have also been used to simulate the behaviour of the dierent functions. The main advantage of this approach is that a single model suces for both validation and code creation, which lead to an ensured consistency between the simulations and the implementation. Because the Simulink models for the individual functions are available, combining them in a higher-level system model as subsystems, creates a simulation model of the entire system. This model is shown in Figure 6.1 and contains all the relevant aspects of the PoC, which are described in Chapter 5. The full system model contains the models for the individual ECUs (shown in Figures 5.11 - 5.13) as subsystems, together with a model of the CAN bus. The CAN bus is modelled using the Vehicle Network Toolbox [28], which is available as toolbox for MATLAB Simulink. Together with Kvaser Virtual CAN Drivers, this toolbox enables the virtualisation of a CAN bus by using communication blocks. The communication blocks in the model also simulate periodic communication and the USB-CAN latency. This communication model is thus an approximation of the time triggered schedule shown in Figure 5.10b. However, due to the inability of providing a time oset to the periodic frames, the communication model is not fully equivalent to the time triggered communication scheme of the PoC. The communication of each ECU is periodic, but no synchronisation mechanism between the simulated ECUs is realised. Dierent input proles can be specied to simulate the inputs that correspond to various situations. These proles can either be created by hand to perform a simulation of a specic situation, or actual vehicle-data, gathered by telemetry can be imported into a prole. The simulation model creates and stores a log le, containing all the outputs generated by the system. Furthermore, a log le with all the CAN frames is created and stored to validate correct communication. In this way the entire systems behaviour is known before it is actually implemented on the PoC. This simulation model can furthermore be used to see the eects of changes to the systems layout. For Proof of Concept of an Integrated Automotive Architecture 39
CHAPTER 6. VALIDATION
CANMsgIn
CAN Configuration
Front CAN Receive

WheelSpeedFront
FrontBrake
WheelSpeedFront SteeringAngle BrakePedal

SteeringAngle CANMsgOut BrakePedal
CAN Log
Front Input Signals Profile
Front Satellite
Front CAN Transmit 0x200
CANMsgIn
CANMsgOut
Central CAN Receive Central CAN Transmit 0x100 Central
CANMsgIn
RearBrake WingServo
Rear CAN Receive

EnableAero WheelSpeedRear ButtonUp ButtonDown
EnableAero WheelSpeedRear WindowServo ButtonUp ButtonDown CANMsgOut
Rear Input Signals Profile
Rear Satellite Rear CAN Transmit 0x300
Figure 6.1: Simulink model used for simulation instance a function can be positioned dierently (from central to local control, or the other way around) and the log containing the CAN frames will show the eects on the bus load whereas the log with the outputs will approximate the performance of the system in terms of input-output latencies.
6.1.1
Active Aerodynamics Model
The model used for the active aerodynamics system is shown in Figure 6.2. This model implements the control strategy rules described in Section 5.1.1 with the three controllers that are depicted in the green blocks. The vehicle speed is calculated as an average of both front and rear wheel speeds in the blue subsystem. The wing angle is calculated by adding contributions of three separate controllers. The vehicle speed controller calculates the contribution to the wing angle based on the current speed of the vehicle. The steering angle controller calculates the contribution to the wing angle based on the steering angle information. The brake pedal controller calculates the contribution to the wing angle based on the brake pedal signal. These individual contributions are added together and saturated, so that the actuator will never be overloaded. Furthermore, the active aerodynamics controller sends a signal to close the power windows above a certain speed1 to improve the vehicles aerodynamic properties. This shows the interaction between two individual functions.
6.1.2
Anti-Lock Braking Model
The model for the ABS, as described in Section 5.1.2, is shown in Figure 6.3. Just like in the active aerodynamics system, the vehicle speed is calculated as an average of both front and rear wheel speeds in the blue subsystem. The yellow subsystems calculate the slip of the front and rear wheels, according to Equation 5.1. This slip is compared with a threshold of 20%, which is the desired slip for a typical ABS controller as has been described in Section 5.1.2. If this threshold is
1 160 km/h has been chosen as the speed at which the windows will close for the simulations, however this value can easily be altered to meet a specic vehicles aerodynamic properties
40
>= 160
WheelSpeedFront
2
WindowClose
1 2
WheelSpeedRear
WheelSpeedFront VehicleSpeed WheelSpeedRear VehicleSpeed WingA ngle
Speed Limit
Vehicle Speed1
VehicleSpeed Controller
3
SteeringAngle
SteeringA ngle WingA ngle
1
Max Angle WingAngle
SteeringAngle Controller
4
BrakePedal
BrakePedal
WingA ngle
BrakePedal Controller
Figure 6.2: Active aerodynamics control model exceeded by either the front or the rear wheels, the brakes at that set of wheels will not be engaged. The input from the brake pedal is used to make sure that the brakes are engaged if and only if the brake pedal is being pressed. The fact that this model contains only a separation between the front and rear wheels instead of a division per individual wheel, is due to the simplifying assumption for the PoC which is described in Section 5.2.3. A normal modern ABS system would implement the regulation of the brakes per individual wheel.
WheelSpeedFront Slip
< 20
Desired Slip front
WheelSpeedFront
VehicleSpeed WheelSpeedFront VehicleSpeed WheelSpeedRear
AND
1
BrakeEngagedFront
1 2
WheelSpeedRear
Slip Front
Vehicle Speed Slip WheelSpeedRear
Vehicle Speed
< 20
Desired Slip rear
Slip Rear
3
BrakePedal
AND
2
BrakeEngagedRear
Figure 6.3: ABS control model
6.1.3
Power Windows Model
Figure 6.4 shows the model for the power windows system, which has been described in Section 5.1.3. The subsystem indicated in red is the position controller, which calculates the window position based on the directional buttons. The output of this subsystem varies between 0% (fully open) and 100% (fully closed). If the open signal is given by another function2 , a value of 100% is subtracted from the position calculated by the position controller. Because the output is saturated between 0% and 100%, the result will then always be 0%, thus the window will be fully open. This is of course not the case if the close signal is also given3 . In that case a value of 200% is added, resulting in an output that is always 100% after saturation. In this way the higher priority of the close function, over the open function is implemented. Of course, it could be debated which signal, open or close, should have the highest priority in an actual implementation and arguments for either signal are situation specic.
6.1.4
Results
The models of the individual functions have been used in order to validate functional correctness of the functions themselves. This is equivalent to functional unit-testing when the simulation is
2 For example when a safety related function detects that the vehicle gets into water, the windows open signal can be given in order to prevent passengers from getting trapped. 3 For example by the active aerodynamics system as described in Section 6.1.1.
41
ButtonUp
3 4
ButtonDown
ButtonUp Position ButtonDown
Position Controller
Close
1
Open
200
Gain Saturation
1
WindowPosition
100
Gain1
Figure 6.4: Power windows control schematic compared to actual tests. In order to simulate the behaviour of a single function, the control model of this function is executed with a predened set of input signals. The output signals generated by the model have been inspected in order to check the functional behaviour of the function in various situations. Simulation results of each of the three functions are shown in Appendix C.1. In order to check the behaviour in specic situations the simulations have been executed with a set of input signals that show dierent situations for all the functions. The results show that each function behaves as described in Section 5.1. Furthermore, the full system simulation model, as shown in Figure 6.1, has been used to verify the behaviour of the system after integration of the separate functions and measure the systems performance. Full results of an example simulation can be found in Appendix C.2. To actuate the brakes, based on a changing input at the brake pedal, two CAN frames need to be sent: one from the satellite to the central ECU and one from the central back to the satellite. Because the ECUs in the simulation model communicate periodically with a period of 26 ms without synchronisation and the sample time of the model is set to 0.1 ms, in the ideal case the two CAN frames are sent within 1 sample period of each other. The minimum latency than becomes 26.1 ms. This approximates the minimum latency of 26 ms described in Section 5.2.3. In Section 5.2.3 it has been explained that the worst case latency due to the communication scheme is 56 ms for the PoC. Because each 26 ms a CAN frame is sent by all the ECUs in the simulation model, the upper bound of the communication delay (C ) is 26 ms for a single CAN frame. The sample time of the model is set to 0.1 ms, therefore the processing delay (P ) becomes negligible compared to C . Because no other delays are taken into account in the simulation and C >> P , Equation 4.2 reduces to: T = C 1 + C 2 (6.1) Therefore, the upper bound of total delay (T) is 26 + 26 = 52 ms in the simulation, instead of the 56 ms which is the actual worst case delay in the PoC. Figure 6.5 shows the results of two braking action simulations, executed with the exact same parameters. This gure shows the delay of the front and rear brakes, which is mainly caused by the C . It is shown that this delay is not constant, as the delay experienced in the simulation shown in Figure 6.5a is 28 ms, and the delay in Figure 6.5a is 46 ms. The cause of this variance is the lack of a synchronisation mechanism between the ECUs in the simulation model, as described in Section 6.1. Therefore, it can be concluded that the simulation model provides great value looking at the systems functional behaviour, but in order to reliably measure the performance, actual tests need to be carried out, in which the communication is time triggered and synchronised.
42
Full model simulation: Brake delay

1.5
FrontBrake RearBrake BrakePedal
Full model simulation: Brake delay

1.5
FrontBrake RearBrake BrakePedal
0.5
0.5
-0.5
0.99
1.01
1.02
1.03
1.04
1.05
1.06
-0.5
0.99
1.01
1.02
1.03
1.04
1.05
1.06
(a) Simulation results: 28 ms delay
(b) Simulation results: 46 ms delay
Figure 6.5: Simulation results of full system model: brake delay
6.2
Testing
During the realization of the PoC, the V-model [29] has been used to test and integrate the system. Every part of the system has been unit tested to validate functional behaviour of the individual parts, after which system integration testing has been performed for the system as a whole. Firstly, the PCs running the RTOS and a simple Simulink model, has been tested to validate the correct execution of the Simulink model. The USB-CAN drivers have been tested separately, to check the USB communication. The time triggered CAN rmware has been tested, to validate the Synchronisation. In order to establish a connection to the I/O interface boards, the communication with the parallel port has been tested in isolation. After that, the I/O interface boards themselves have been tested together with their drivers, to validate correct behaviour of the sensors and actuators. Only after every unit-test was passed successfully, integration of the individual parts into the complete PoC was carried out. In order to validate the functional behaviour of the complete PoC, tests have been carried out on the implemented setup. The I/O boards have been used to send the input signals to the ECUs and drive the connected actuators with the signals coming from the ECUs. The states of the actuators have been observed in order to validate that the systems behaviour was as expected. In all tests the behaviour of the integrated system was as expected and all functions followed the control strategy rules described in Section 5.1. Furthermore, tests on the implemented setup have been carried out to gain insight in the performance of the PoC, something which was not available from the simulation results. In order to measure the systems performance, the metric has been dened: the time that has passed between changing an input signal at a sensor and observing the reaction to that change at the designated actuator (I/O delay). In order to measure this metric, the brake pedal has been used as input signal and the rear brake signal as output. Both signals have been connected to a oscilloscope and the time has been measured. The tests have been carried out with dierent sample times for the Simulink models, but whenever the sample times were smaller than 20 ms, there was no measurable inuence on the I/O delay, showing that the processing delay is negligible compared to the communication delay. Figure 6.6 shows two dierent measurements. Channel 1 is connected to the brake pedal input signal and channel 2 is connected to the rear brake output signal. The brake pedal signal is an inverted signal, whenever the brake pedal is pressed, it becomes low and when the pedal is released it becomes high. The measured I/O delay was not the same in every test conducted with the same sample time, but varied between 52 ms in the best case and 106 ms in the worst case. These results are not as expected, because the theoretical worst case I/O delay is 56 ms. The fact that the measured delay is larger than expected can have two possible causes, as the processing delays have already been eliminated. The rst possible cause is that the communication scheme to transmit the CAN frames, as shown in 5.10b, is not executed correctly by the MCP2515DM-BM boards. The other possibility is that the USB communication between the ECUs and the MCP2515DM-BM boards is not fast enough and therefore an incoming CAN Proof of Concept of an Integrated Automotive Architecture 43
(a) Measurement results: 52 ms delay
(b) Measurement results: 106 ms delay
Figure 6.6: Measurement results on PoC: brake delay
frame with updated data is not instantly transferred to the ECU. In order to eliminate the rst possibility as a cause of the delays, measurements on the CAN bus have been carried out while the PoC was in operation. The result of these measurement is shown in Figure 6.7. Channel 1 is the CAN high line and channel 2 is the CAN low line, and a CAN frame is shown as a peak on both lines. It is shown in this gure that four CAN frames are transmitted on the bus, which are each approximately 2 ms apart. After that, for a period of 24 ms, no CAN frames were being transmitted. This is exactly the scheme from Figure 5.10b, in which a CAN frame is transmitted at the beginning of each time frame. Therefore, it has been proven that the time triggered communication scheme is executed correctly by the CAN hardware.
Figure 6.7: Measurement results on PoC: time triggered communication scheme Furthermore, the CAN messages themselves have been inspected with the Tiny-CAN I-XL board (described in Section 5.2.1) connected to a PCs with Tiny-CAN View monitor software. All inspected CAN messages contained the correct data and the calculated output signal was transmitted over the bus during the same cycle in which the input was changed, theoretically bounding the delay between 26 ms and 56 ms. This leaves the CAN-USB communication as only possible cause for the additional delay experienced during the measurements. This problem can either be located in the CAN-USB drivers on the ECUs, or in the rmware located in the MCP2515DM-BM boards. The problem has not been investigated further. As Chapter 7 will explain, this delay is only relevant when the proposed architecture will be implemented in a vehicle and eliminating the CAN-USB altogether by using embedded hardware with an on-board network controller will solve this delay. 44 Proof of Concept of an Integrated Automotive Architecture
6.3
Safety Argumentation
In order to address the safety aspect, the power windows system has been used to build a safety case in collaboration with the Laboratory for Quality Software (LaQuSo). LaQuSo participates as partner in the OPENCOSS project, which is a project dedicated to produce the rst Europeanwide open safety certication platform [15]. The collaboration is performed in context of this project, for which LaQuSo developed a method to ensure the safety argumentation is both correct and clear. This is achieved by making use of modelling techniques to support safety certication and reducing the ambiguity of the natural language in safety cases by utilizing Semantics of Business Vocabulary and Rules (SBVR). Thereby the condence of the claimed safety assurance is increased. Furthermore, a supporting tool is introduced, which enables syntax highlighting and content assistant while editing safety cases. In order to evaluate both the method and the tool, LaQuSo used the power window system use case. Furthermore, the created safety argumentation is used within this graduation project to show how safety can be validated for each individual function. Especially when using the systems approach to create a system, safety is an important aspect to consider. When creating a safety argumentation for the overall system, the same method and tool can be used. This section shows how the safety case for the power windows system was created.
6.3.1
Goal Structuring Notation (GSN)
The Goal Structuring Notation (GSN) [22] a graphical argumentation notation explicitly represents the individual elements of any safety argument (requirements, claims, evidence and context) and (perhaps more signicantly) the relationships that exist between these elements (i.e. how individual requirements are supported by specic claims, how claims are supported by evidence and the assumed context that is dened for the argument). [21] The GSN is used to model the safety case of the power window system. The purpose of the created GSN diagram is to visually represent the break-down of the safety case into subgoals. This process is repeated until the claim of a subgoal can be supported by evidence. The safety (sub)goals are represented by rectangular blocks, the strategies used for the break-down are represented by parallelograms, and circles represent the evidence to support a claim. The context in which a certain goal or strategy is dened is given by the rounded rectangles.
6.3.2
Semantics of Business Vocabulary and Rules (SBVR)
The use of the GSN increases the clarity of the safety case over a textual description, however the goals and strategies are still formulated in natural language. Since arguments formulated in natural language are prone to ambiguities, the method developed by LaQuSo uses SBVR [34] in order to formulate the goals and strategies. SBVR is a standard which aims to formalize natural language in order to make it machine processable. SBVR captures expressions as formal logic structures, based on a vocabulary for conceptual modelling. The logic structures are dened following certain rules. Because SBVR itself is outside the scope of this graduation project, an exhaustive explanation of the vocabulary and rules can be found in the Object Management Group (OMG) standard [34].
6.3.3
Power Windows Safety Case
In order to create the safety case for the power window system, rst a Hazard Assessment by Risk Analysis (HARA)[42] has been conducted. This HARA has led to the denition of several High Level Requirements (HLRs). The HLRs have been subdivided into several Low Level Requirements (LLRs). The HLRs and LLRs together form the functional safety requirements for the power window system, which can be found in Appendix D.1. From the HARA and the functional safety requirements a GSN diagram has been created, which is shown in Appendix D.2. This forms the rst basic safety case for the power windows system. Proof of Concept of an Integrated Automotive Architecture 45
Furthermore, a conceptual model of the power windows system has been created, which is shown in Figure 6.8. This model contains all concepts which are related to the power windows system. This model includes concepts like hardware components, designs, documents, etc. The conceptual model is used for the implementation of the SBVR vocabulary into the safety case. The improved model of the safety case is based on a GSN pattern created by LaQuSo, which is shown in Appendix D.3, and the conceptual model, resulting in a safety case that is shown in Appendix D.4. This safety case has been developed to be both correct and clear, which is extremely important in a multi-disciplinary eld like the automotive domain.
Figure 6.8: Conceptual model of the power windows system
6.4
Conclusion
By performing both simulations and actual tests on the implemented PoC, the main question for this chapter: Does the PoC meet the requirements? can be answered. To answer this question, the requirements break down into two parts, namely functional and non-functional requirements, for each of which the question has a dierent answer. The functional requirements describe the functional behaviour of the PoC and the non-functional requirements describe aspects like performance. The simulation and test results show that the functional requirements of the PoC have been met. The behaviour of the functions is as expected and follows the control strategies that have been described in Section 5.1. Running multiple functions next to each other on a single ECU does not inuence the behaviour of the functions. After integration the functions still behave as expected. For the rst part of the requirements, this leads to a positive answer to the question. The PoC does meet the functional requirements. However, the non-functional requirements have not been met. The desired performance, as described in Section 4.5, was not met in both the simulation and measurement results. In Section 4.5 a maximum tolerable delay (Tmax ) for the IM01 of 1 ms has been determined. The results in this chapter showed that the maximum delay experienced with the PoC is 104 ms, more than 100 times larger than the desired delay. The main contribution to this delay is the communication delay, which is caused by the specic CAN hardware used for the PoC. Furthermore, this chapter demonstrated how to create a safety case for a single function, to validate the requirements concerning the safety aspect. This safety case has been created, in order to demonstrate the process and because safety is an important aspect to consider from a systems approach point of view. The creation of an exhaustive safety case for all the implemented functions and the system as a whole is outside the scope of this graduation project. The next chapter evaluates options that can be implemented in order to create a solution that does meet the requirements, and thus can be implemented on the IM01. 46 Proof of Concept of an Integrated Automotive Architecture
Chapter 7
Implementation
As described in the previous chapter, the PoC does not meet all the non-functional requirements for implementation in the IM01. Furthermore, the objective of the PoC is to show that the proposed architecture can indeed be realised and not to actually implement it in a vehicle. If the proposed architecture were to be implemented in the IM01, some practical problems still need to be overcome. This chapter gives an overview of those problems. The main question answered in this chapter is: What improvements should be made to the PoC in order to implement the proposed integrated architecture in an actual vehicle? This chapter also provides an insight in the demands for implementing the proposed architecture in a production vehicle and presents future work. Section 7.1 explains the steps that need to be taken in order to implement the architecture on the IM01, after which the possibility of implementing the architecture in a production vehicle is discussed in Section 7.2. Conclusions can be found in Section 7.3.
7.1
Towards Realisation
The PoC described in Chapter 5 proves that the integrated architecture which has been proposed in Chapter 4 is a feasible future architecture for the automotive domain. However, in order to actually realise an implementation of this architecture in a vehicle, improvements to the performance achieved by the PoC need to be made. Furthermore, a solution is needed for running multiple functions simultaneously, which all use the same communication hardware. These practical problems, which are considered as possible future research topics, are described in this section.
7.1.1
Practical Problems
The main reason that the implemented PoC is not suitable for implementation in an actual vehicle is its lack in performance. As described in Section 6.2 the cause of the I/O delay is isolated to the communication hard- and/or software. In case the architecture were to be implemented in a vehicle, this problem would be overcome by using dedicated embedded hardware to implement the ECUs, instead of the PCs used by the PoC. The ideal hardware would consist of an embedded platform with a x86 based CPU, combined with an on-board network controller. The usage of an on-board network controller would eliminate all the delays that occur as a result of the USB-CAN communication. Furthermore, using Flexray communication instead of a CAN bus would reduce the communication delay even further. Flexray is already a time-triggered protocol, thus the additional synchronisation layer in the communication controllers rmware can be eliminated. This layer has been used by the PoC and is described in Section 5.2.2. An additional advantage of Flexray over CAN is the available bandwidth. Flexray oers 10 Mbit of bandwidth, whereas CAN only oers a maximum bandwidth of 1 Mbit. The proposed embedded platforms which combine an x86 based CPU with an on-board Flexray Proof of Concept of an Integrated Automotive Architecture 47
CHAPTER 7. IMPLEMENTATION
controller do not currently exist and have to be developed specically to enable the implementation of this architecture. If these boards where to be developed in the future, additional hardwarespecic software needs to be created as well. Linux kernel drivers for the Flexray controllers are needed, which ideally resemble the behaviour of the readily available socketCAN [23] drivers. These drivers enable the usage of (supported) CAN hardware as normal network devices, connecting to them by using sockets. In this way, the drivers enable multiple processes which are running simultaneously on the hardware platform, to use the shared CAN hardware at the same time. This eliminates the problem of running multiple functions on a single ECU, which was observed with the PoC and has been described in Section 5.2.3. Assuming that this hardware will be developed together with the desired drivers as a part of future research, the main practical problems that have been identied while implementing and validating the PoC will be eliminated. This enables the implementation of the architecture on an actual vehicle. The logical next step would be to implement a Proof of Product (PoP) of such an architecture on the IM01.
7.1.2
IM01
As described above, an implementation of a PoP on the IM01 would be the rst logical step. Because the IM01 is a one of a kind prototype, security is not a concern for this vehicle (as has been described in Section 4.7), which simplies the implementation process. Furthermore, the number of electronic functions that need to be implemented on the IM01 is a lot lower than for a production vehicle. Figure 7.1 shows the electronic functions that have been identied for the IM01 by the InMotion team. Compared to Figure 2.1, which shows the electronic functions of a premium production vehicle, the IM01 is a less complex system. The reason for this is that the purpose of the IM01 is to be operated on a racetrack, which basically is a controlled environment when compared to everyday trac. Therefore, the IM01 features mainly passive safety, by the structural design of the vehicle, rather than active safety systems, which are mostly controlled electronically. Airbags are an example of such an active safety system. Furthermore, the IM01 does not feature any infotainment or comfort system like navigation or climate control because these systems are not needed in a race car.
Power Steering Human Interface Adaptive Front Lighting Telemetry
Autonomous Driving
Range-extender Control
Active Aerodynamics
Brake-by-wire
Electric Propulsion
Active Suspension Throttle-by-wire
Anti-lock Braking Vehicle Dynamics
Battery Management
Regenerative Braking
Figure 7.1: Overview of electronic functions in the IM01 This reduced complexity makes the IM01 the ideal vehicle to implement and showcase the proposed integrated architecture with the hardware described in Section 7.1.1. 48 Proof of Concept of an Integrated Automotive Architecture
7.2
Beyond Realisation
Once an implementation of the proposed architecture in the form of a PoP has been realised for the IM01, the next step is to implement the architecture in a production vehicle. For this implementation, the hardware topology will remain unchanged, as is shown in Figure 7.2. To enable this, certain aspects of the architecture will need further research because there are some elementary dierences between the IM01 and a production vehicle. The main dierences between the implementation of the PoP in the IM01 and an implementation of the architecture in a production vehicle are caused by: the environment in which the system will be operated, the number of electronic functions available, the importance of the security aspect and the availability of the system.
C e n t r a l E C U
S a t e l l i t e E C U
C o m m u n i c ao n b u s
Figure 7.2: Hardware topology for a production vehicle The environment in which a production vehicle will be operated (daily trac) is a lot less predictable and controlled than the racetrack on which the IM01 will be used. This leads to the fact that more complex electronic functions will need to be implemented. For example parking assist, lane departure warning, object detection and collision avoidance are functions that assist the driver in operating the vehicle in daily trac, but are not needed on the IM01. These functions introduce additional sensors and actuators, which generate a lot of real-time data to be processed, increasing both the network load as well as the required processing power. As described in the previous section, the number of electronic functions that need to be implemented on a production vehicle is much higher than for the IM01. This leads to an increased systems complexity upon integration of all the individual functions, especially when these functions are interdependent. This makes the validation of the entire system by testing a cumbersome, or even impossible process which increases the importance of simulations. The demand for a robust network protocol that supports high bandwidth will increase, as the load of the network will increase with the number of functions that are implemented. It is expected that the bandwidth provided by Flexray will be sucient for an implementation in a production vehicle. However, alternative networking protocols might be investigated as well. CAN FD [18] could be a possible option, as this protocol supports even higher bandwidths than Flexray. However, CAN FD is an event triggered protocol and would thus need an additional time triggered communication layer, as described in Section 5.2.3. Automotive ethernet might also become a viable alternative, as it oers a higher bandwidth than both Flexray and CAN FD. However, automotive ethernet is currently still in development and the robustness of this network protocol needs to be improved before it becomes a suitable solution. A system design in which the proposed localised control is used by the functions that support this, can reduce the overall network load, making optimal use of the available bandwidth. Proof of Concept of an Integrated Automotive Architecture 49
The required processing power will also increase as the number of functions increases. The chosen x86 platform (described in Section 5.2.1) provides CPUs that are amongst the most powerful processors available, making it a suitable choice for the implementation in a production vehicle. Using a combination of both central and localised control, an optimal distribution of processing power over the dierent ECUs can be achieved. The security aspect, as described in Section 4.7, has not been considered for the PoC and is neither of importance for the IM01. However, this is a concern that really needs to be taken into account for the implementation of an integrated architecture, in order to be successful in a production vehicle. If standardised hard- and software components are to be used in all the major production vehicles, it is of the utmost importance that security of these vehicles is guaranteed. The experiments carried out on the Volkswagen Lupo, as described in Section 4.7, show that gaining unauthorized access to a vehicles functions is not that dicult. The only protection against this is the need for physical access to a vehicle that can be reverse engineered. Once standardised hard- and software is implemented in the majority of production vehicles, the reverse engineering of a single vehicle will suce in order to gain access to a whole range of vehicles. Another aspect in which a production vehicle diers from the IM01 is the availability. As a production vehicle is built for everyday use, the IM01 will spend most of its lifetime in the garage. The IM01 will only be used during racing events in a controlled environment. During its use, every sensor of the IM01 will be constantly monitored, so if anything unexpected happens, the vehicle can be called into the pitbox for service. This is clearly not the case for a production vehicle, which needs to be reliably available at virtually any given point in time in any circumstance (for example changing weather conditions). This demand for availability leads to an increased need for robustness of all the implemented functions and the system as a whole. In order to guarantee such robustness and thereby the availability of the vehicle, further research is needed. The dierences between an implementation in the IM01 and a production vehicle are not only related to technical aspects. The way vehicles are currently developed by the OEMs does not support the implementation of an integrated architecture. As described in Section 2.1, the OEMs are currently only responsible for integrating the dierent functions, which are supplied to them as black boxes. The responsibility for the software of these black boxes lies currently with the Tier 1 suppliers. In case the OEMs were to implement an integrated architecture in their vehicles, they will become responsible for the software development, integration and validation. It remains to be seen if and when OEMs are willing to make such a change.
7.3
Conclusion
The question that has been answered in this chapter is: What improvements should be made to the PoC in order to implement the proposed integrated architecture in an actual vehicle? It has been reviewed what practical problems have been identied while implementing the PoC, which need to be solved in order to implement the integrated architecture in an actual vehicle. Possible solutions to these problems have been described. The main problems are related to the performance of the PoC and the implementation of multiple functions that need to share the networking hardware. These problems can be overcome by using embedded hardware which combines the processing power of an x86 platform with an on-board network controller. On top of this, the communication protocol itself should be replaced by a protocol that oers more bandwidth and time triggered communication by default. Flexray has been identied as a possible solution. It has been described why the IM01 would be an ideal vehicle for the implementation of a PoP. This is mainly because the IM01 is a less complex system than a production vehicle and because it is a one of a kind prototype, which leads to a simplied implementation process. Finally, it has been discussed what the main dierences are between the IM01 and a production vehicle. The consequences of these dierences, in case the architecture would be implemented in a production vehicle, have been presented.
50
Chapter 8
Conclusions and Recommendations

For the graduation project described in this master thesis, an integrated automotive architecture has been designed. In order to research the feasibility of this integrated architecture, a PoC has been realised. This PoC has been used to validate the proposed architecture. The PoC has been implemented using standardised hardware components because standardising the hardware has several advantages, exibility being the most important. The main question that has been answered by this research is: Is it possible to design and implement an architecture that minimises the number of ECUs in a vehicle, while maintaining the functionality of a one-function-one-ECU architecture? In order to answer this question, a systems oriented approach has been followed within this project. After the problem was stated in the introduction, an overview of the existing alternatives was provided. This overview consisted of a description of the eorts which have been made in the automotive domain to shift from a traditional federated architecture to an integrated architecture. It also provided an insight in the state-of-art in this area, together with the reasons behind the existing architectures. This formed a solid base to continue the research, as non of the presented architectures satised the goal of this project completely. The main contribution of this graduation project is the design of an integrated architecture. This architecture consists of a hard- and software architecture. The hardware architecture was derived from the results of a previous research conducted within the InMotion project. This architecture is composed of a central ECU together with four satellite ECUs. The software architecture consists of two layers per ECU: the OS layer, containing a RTOS and the application layer, containing the individual functions. All functions are implemented in software and split up into three parts: an input, processing and output part. The in- and output parts focus mainly on I/O interactions and are mapped to satellite ECUs, while the processing part ensures the execution of real-time processing models and is mapped to the central ECU. The ECUs are interconnected using a time triggered communication protocol. The architecture features localised control, which resembles a reex in the human body. Actuators can be controlled locally by a satellite ECU, based on sensor data gathered by the same ECU. This type of control can yield a substantial performance improvement, both due to a reduced network load as well as to the balancing of the required processing power. Furthermore, the architecture provides certain safety related advantages over the existing alternatives by design. In order to prove the feasibility of the proposed architecture a PoC was implemented. This PoC features three dierent use cases, each demonstrating dierent properties of the architecture. The active aerodynamics system demonstrates distributed control, the ABS demonstrates central control and the power windows system demonstrates localised control capabilities. The Proof of Concept of an Integrated Automotive Architecture 51
CHAPTER 8. CONCLUSIONS AND RECOMMENDATIONS
combination of these use cases demonstrates the possibility to run several interdependent functions simultaneously, while sharing sensors and actuators and communicating over a shared bus, without inuencing each others behaviour. In collaboration with LaQuSo a safety case was created for one of the use cases. This contributed to the heuristic view on the architecture as a result of the systems oriented approach which was followed. The safety case also demonstrated how the safety of the proposed architecture can be validated. After all the components of the PoC separately passed unit-tests, the PoC was integrated. The functional correctness of the PoC was validated by performing both simulations on the control models and tests on the implemented setup. The results of both the simulations and the tests showed the successful implementation of the PoC. Thus, it was proven to be possible to design and implement an architecture that minimises the number of ECUs in a vehicle, while maintaining the functionality of a one-function-one-ECU architecture. However, the performance requirements were not met by the implemented PoC. Therefore, it was identied that improvements are necessary in order to actually implement the architecture in a vehicle. There are improvements that should be made to implement the architecture in the IM01. The rst recommendation is to develop embedded hardware, based on the same x86 platform which was used for the PoC with an on-board network controller. This will eliminate the performance issues which were experienced when the PoC was tested. The second recommendation is to use Flexray as a communication protocol for an implementation, instead of CAN which was used for the PoC. Flexray oers more bandwidth and is already a time triggered protocol. Finally, recommendations are made for implementing the proposed architecture in a production vehicle. It has been identied that a production vehicle features more electronic functions, leading to an increased network load and an increased amount of processing power required. It is recommended that further research is conducted in order to dene requirements on the networking capabilities and processing power needed. Furthermore, the security aspect has not been researched in this project, because there was no requirement regarding security for the IM01. However, this is an important aspect in the systems oriented approach and its real value becomes apparent when the proposed architecture is to be implemented in a production vehicle. It is recommended that this aspect is the topic of an exhaustive research before the architecture will be implemented in a production vehicle. If all problems concerning the technical aspects are overcome, the OEMs still need to be willing to make a change to the way vehicles are currently developed before an integrated architecture can be implemented successfully.
52
Bibliography
[1] International Council on Systems Engineering (INCOSE). A consensus of the incose fellows. viewed October 16, 2013 http://www.incose.org/practice/fellowsconsensus.aspx. 6, 7 [2] Amos Albert. Comparison of event-triggered and time-triggered concepts with regard to distributed control systems. Embedded World, 2004:235252, 2004. 19 [3] Janztech Industrial Computing Architects. empc-x1600 datasheet - fanless embedded pc system with lowest dimensions and intels atom technology. viewed November 9, 2013 http://www.janztec.com/fileadmin/downloads/datasheets/emPC/datasheet_ empc_x1600.pdf. 27 [4] A Terry Bahill and Bruce Gissing. Re-evaluating systems engineering concepts using systems thinking. Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on, 28(4):516527, 1998. ix, 7 [5] Michael Barabanov and Victor Yodaiken. Real-time linux. Linux journal, 23, 1996. 29 [6] Jonas Bereisa. Applications of microcomputers in automotive electronics. Industrial Electronics, IEEE Transactions on, SE-9(2):8796, 1983. iii, 1 [7] Christian K uhnel Bernhard Sch atz and Michael Gonschorek. Flexray protocol. In Automotive embedded systems handbook, chapter 5. CRC Press, Boca Raton, FL, USA, 2009. 18 [8] Manfred Broy, Ingolf H Kruger, Alexander Pretschner, and Christian Salzmann. Engineering automotive software. Proceedings of the IEEE, 95(2):356373, 2007. 5, 11 [9] Robert Bruckmeier. Ethernet for automotive applications. FTF Orlando Robert Bruckmeier BMW Group, 2010. 28 [10] Robert N. Charette. This Car Runs on Code. IEEE Spectrum, feb 2009. iii, 1, 2 [11] FlexRay Consortium et al. Flexray communications system-protocol specication. Version, 2(1):198207, 2005. 28 [12] Mercer Management Consulting and Hypovereinsbank. Studie, automobiltechnologie 2010, Aug 2001. 11 [13] Marco Di Natale and Alberto Luigi Sangiovanni-Vincentelli. Moving from federated to integrated architectures in automotive: The role of standards, methods and tools. Proceedings of the IEEE, 98(4):603620, 2010. 11, 12 [14] Juan Pimentel et al. Dependable automotive can networks. In Automotive embedded systems handbook, chapter 6. CRC Press, Boca Raton, FL, USA, 2009. 7 [15] Open Platform for EvolutioNary Certication of Safety-critical Systems (OPENCOSS). Opencoss homepage. viewed November 12, 2013 http://www.opencoss-project.eu/. 45 Proof of Concept of an Integrated Automotive Architecture 53
BIBLIOGRAPHY
[16] International Organization for Standardization, International Electrotechnical Commission, et al. Iso/iec 7498-1: 1994. Information TechnologyOpen Systems InterconnectionBasic Reference Model: The Basic Model, 1994. 8 [17] Daan Gerrits. Towards an architectural description of the im01. Technical report, Eindhoven University of Technology, 2012. 16 [18] Robert Bosch GmbH. Can with exible data-rate. viewed November 22, 2013 http://www. bosch-semiconductors.de/media/pdf_1/canliteratur/can_fd.pdf. 49 [19] R Hammett. Flight-critical distributed systems-design considerations. In Digital Avionics Systems Conference, 2002. Proceedings. The 21st, volume 2, pages 13B31. IEEE, 2002. 2 [20] Bernd Hardung, Thorsten K olzow, and Andreas Kr uger. Reuse of software in distributed embedded automotive systems. In Proceedings of the 4th ACM international conference on Embedded software, pages 203210. ACM, 2004. 11 [21] Tim Kelly and Rob Weaver. The goal structuring notationa safety argument notation. In Proceedings of the dependable systems and networks 2004 workshop on assurance cases. Citeseer, 2004. 45 [22] Tim P Kelly. Arguing safety-a systematic approach to safety case management. Department of Computer Science, The University of York, 1998. 45 [23] Marc Kleine-Budde. Socketcan - the ocial can api of the linux kernel. viewed November 24, 2013 http://www.can-cia.org/fileadmin/cia/files/icc/13/kleine-budde.pdf. 48 [24] The Clemson University Vehicular Electronics Laboratory. Clemson vehicular electronics laboratory: Automotive electronic systems. viewed October 15, 2013 http://www.cvel. clemson.edu/auto/systems/auto-systems.html. ix, 6 [25] Gabriel Leen and Donal Heernan. Expanding automotive electronic systems. Computer, 35(1):8893, 2002. 11 [26] Kuen-Long Leu, Yung-Yuan Chen, Chin-Long Wey, and Jwu-E Chen. Robustness analysis of the exray system through fault tree analysis. In Vehicular Electronics and Safety (ICVES), 2010 IEEE International Conference on, pages 3035. IEEE, 2010. 19 [27] Myron Lipow. Number of faults per line of code. Software Engineering, IEEE Transactions on, SE-8(4):437439, 1982. 2 [28] MathWorks. Vehicle network toolbox - communicate with in-vehicle networks and access ecus using can and xcp protocols. viewed November 13, 2013 http://www.mathworks.nl/ products/datasheets/pdf/vehicle-network-toolbox.pdf. 39 [29] Zhang Shuai Michael Atmadja. Testing. In A Fresh Graduates Guide to Software Development Tools and Technologies, 2nd edition, chapter 3. School of Computing, National University of Singapore, Singapore, 2012. viewed November 17, 2013 http://www.comp.nus.edu.sg/ ~seer/book/2e/. 43 [30] Krishna B Misra. The Handbook of Performability Engineering, chapter 2, pages 1324. Springer, 2008. 6 [31] Robert MUIR et al. Serial peripheral interface, July 19 1996. WO Patent 1,996,021,974. 28 [32] Nicolas Navet and Fran coise Simonot-Lion. A review of embedded automotive protocols. In Automotive embedded systems handbook, chapter 4. CRC Press, Boca Raton, FL, USA, 2009. 19 54 Proof of Concept of an Integrated Automotive Architecture
BIBLIOGRAPHY
[33] Roman Obermaisser, Christian El Salloum, Bernhard Huber, and Hermann Kopetz. From a federated to an integrated automotive architecture. Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, 28(7):956965, 2009. ix, 11, 13, 15 [34] OMG. Semantics of business vocabulary and rules (sbvr). Version, 1(1), 2013. 45 [35] Libusb project. Libusb homepage. viewed October 31, 2013 http://www.libusb.org/. 30 [36] RTAI project founded by the Department of Aerospace Engineering of Politecnico di Milano (DIAPM). Rtai homepage. viewed October 30, 2013 http://www.rtai.org. 29 [37] J org Sch auele and Thomas Zurawka. Automotive software engineering-principles, processes, methods and tools. SAE International, Warrendale, PA, USA, 2005. 15 [38] Teresa Schuster and Dinesh Verma. Networking concepts comparison for avionics architecture. In Digital Avionics Systems Conference, 2008. DASC 2008. IEEE/AIAA 27th, pages 1D. IEEE, 2008. 2 [39] Philips Semiconductors. The i2c-bus specication. Philips Semiconductors, 9397(750):00954, 2000. 28 [40] ISO Standard. Iso 11898, 1993. Road vehiclesinterchange of digital informationController Area Network (CAN) for high-speed communication, 1993. 7 [41] ISO Standard. Iso 11898-4, 2000. Road vehicles-Controller Area Network (CAN)-Part 4: Time-Triggered Communication, 2000. ix, 9, 10 [42] ISO Standard. Iso 26262, 2011. Road vehicles Functional safety, 2011. 45 [43] McLaren Electronic Systems. Formula 1 control systems. viewed October 18, 2013 http: //www.mclarenelectronics.com/Systems/CaseStudy/Formula%20One. 12, 15 [44] Johan van Uden. Mapping multiple matlab simulink applications to a real-time operating system using a hierarchical scheduling framework. Technical report, Eindhoven University of Technology, 2013. 33 [45] Ming-chin Wu and Ming-chang Shih. Simulated and experimental study of hydraulic anti-lock braking system using sliding-mode pwm control. Mechatronics, 13(4):331351, 2003. 24 [46] Karim Yaghmour, Jonathan Masters, and Gilad Ben. Introduction to real-time linux. In Building embedded linux systems, 2nd edition, chapter 12, pages 351364. OReilly & Associates, Inc., Sebastopol, CA, USA, second edition, 2008. 29
55
Appendix A
Developed Hardware
Figure A.1: Schematic of the I/O interface board for the front satellite ECU
Figure A.2: Schematic of the I/O interface board for the rear satellite ECU
57
Appendix B
Developed Software
B.1 USB-CAN Drivers
Electronic Function
- Data[8] : uint8_t - Id : unsigned int - Extended : int - Length : int - main(int argc, char*argv[]) : int
USB
- kernelDriverDetached : int - USBinit() : libusb_device_handle* - clearUSBBuffer (libusb_device_handle* handle) : int - closeUSB(libusb_device_handle* handle) : int - sendMessage (CAN_MESSAGE_OUT CANMessage, libusb_device_handle* handle) : int - receiveMessage(libusb_device_handle* handle) : CAN_MESSAGE_IN - setCANBusSpeed (libusb_device_handle* handle, int speed) : int
CAN
- setId (unsigned int Id, int Ext) : CAN_MESSAGE_OUT - setData (CAN_MESSAGE_OUT Message, int length, uint8_t data[8]) : CAN_MESSAGE_OUT - getId (CAN_MESSAGE_IN Message) : unsigned int - getData (CAN_MESSAGE_IN Message, uint8_t *data) : int
Figure B.1: Components for the CAN drivers
USB_MESSAGE_OUT
- Can1 : CAN_MESSAGE_OUT - Can2 : CAN_MESSAGE_OUT - Can3 : CAN_MESSAGE_OUT - Can4 : CAN_MESSAGE_OUT - Registers : USB_REGISTERS
USB_MESSAGE_IN
- Can1 : CAN_MESSAGE_IN - Can2 : CAN_MESSAGE_IN - Can3 : CAN_MESSAGE_IN - Can4 : CAN_MESSAGE_IN - Registers : USB_REGISTERS
USB_REGISTERS
- CANmsgs : unsigned char - CANINTF : unsigned char - EFLAG : unsigned char - TEC : unsigned char - REC : unsigned char - CANSTAT : unsigned char - CANCTRL : unsigned char - STATUS : unsigned char - SPI : unsigned char - REG : unsigned char - DATA : unsigned char - res : unsigned char
CAN_MESSAGE_OUT
- Id : CAN_ID - Length : unsigned char - Data : CAN_DATA
CAN_MESSAGE_IN
- Init : unsigned char - Id : CAN_ID - Data : CAN_DATA
CAN_ID
- Byte1 : unsigned char - Byte2 : unsigned char - Byte3 : unsigned char - Byte4 : unsigned char
CAN_DATA
- Byte1 : unsigned char - Byte2 : unsigned char - Byte3 : unsigned char - Byte4 : unsigned char - Byte5 : unsigned char - Byte6 : unsigned char - Byte7 : unsigned char - Byte8 : unsigned char
Figure B.2: Structure diagram for the CAN drivers 58 Proof of Concept of an Integrated Automotive Architecture
APPENDIX B. DEVELOPED SOFTWARE
Electronic Function
USBinit()
USB
CAN
handle : libusb_device_handle*
setId(unsigned int Id, int Extended) MessageOut : CAN_MESSAGE_OUT setData(CAN_MESSAGE_OUT Message, int length, uint8_t data[8])
MessageOut : CAN_MESSAGE_OUT
sendMessage(CAN_MESSAGE_OUT CANMessage, libusb_device_handle* handle)
Succeeded : int
receiveMessage(libusb_device_handle* handle)
MessageIn : CAN_MESSAGE_IN
getId(CAN_MESSAGE_IN MessageIn) Id : unsigned int

getData(CAN_MESSAGE_IN MessageIn, uint8_t data[8]) Length : int
closeUSB(libusb_device_handle* handle)
Succeeded : int
Figure B.3: Sequence diagram for the CAN drivers
59
60
USB Power? No USB Configured? Yes Read USB Data No No USB Data Available? Read CAN Data CAN Data Available?
B.2
Start
Initialize System
Yes
No
Yes Yes
Check USB Status
Check Number of CAN Messages
Copy CAN Message to USB Buffer
CAN Firmware
USB Driver Service

No
Number of CAN Messages > 0?
Set USB Flag
Yes
Send CAN Messages to Buffer USB Flag Set? No
Wait 21,25 ms
Yes
All Buffers Full?
Yes
No
Send USB Message
Send CAN Message
Set USB Flag
Figure B.4: Flowchart of original polling CAN rmware

Check CTRL and SPI Messages Process CTRL and SPI Messages CTRL or SPI Message Available? No Yes
Start
Initialize System
Check USB Status
Incomming CAN Message Interrupt No Set USB Flag USB Flag Set?
Yes
Check CAN ID
Time Master Message?
Copy CAN Message to USB Buffer
Send USB Message
End
Yes
No Reset Timer
Timer Interrupt Yes
Increase Timer
Timer Reached Scheduled Time?
Yes All Buffers Full?
Check Which ID is Scheduled
Send Selected CAN Message to Buffer
No
Send CAN Message
End
No

Wait 21,25 ms
Incomming USB Message Interrupt

Yes
USB Driver Service
Read USB Data Yes No
USB Data Available?
Save USB data to Selected CAN Buffer
Process CTRL and SPI Messages Yes Check CTRL and SPI Messages CTRL or SPI Message Available?
No
Figure B.5: Flowchart of adapted interrupt based CAN rmware

Send USB Message
End
USB Configured?
No
61
B.3
I/O Drivers
Electronic Function
- ServoID : int - ServoPosition : int - ADChannel : int - PortNumber : int - main(int argc, char*argv[]) : int - initParalelPort (int PortNumber) : void
ADConversion
- channel1ControlByte : char - channel2ControlByte : char - getADCvalue(int ChannelID) : int
ServoControl DigitalIO
- checkINpin (int pinID) : int - setOUTpin (int pinID, int status) : void - ControllerID : char - initServoController (char ControllerID) : void - sendPosition (int ServoID, int ServoPosition) : void
SPI
- sendSPIByte(char byte) : void - readSPIvalue (void) : int - checkDOUTline(void) : int - setDINline(int status) : void - setCLKline (int status) : void - setCSline(int status) : void
I2C
- sendI2Cbyte(char byte) : void - sendI2Cbit (bool bit) : void - startCondition(void) : void - stopCondition (void) : void
Figure B.6: Components for the I/O drivers
Electronic Function
ServoControl
I2C
sendPosition(int ServoID, int ServoPosition)
startCondition(void)
loop
[for all bytes: -Device address - Servo address - Position byte 1 - Position byte 2 ]
sendI2Cbyte(char byte)
loop
[for all bits in byte] sendI2Cbit(bool bit)
stopCondition(void)
Figure B.7: Sequence diagram for the update of a servos position in the I/O drivers
62
Electronic Function
ADConversion
getADCvalue(int ChannelID)
SPI
sendSPIByte(char channel1ControlByte )
loop
[for all bits in channel1ControlByte] setDINline(int status) setCLKline(int status) setCSline(int status)
readSPIvalue(void)
loop
[for all bits on DOUT line] checkDOUTline(void)
int : ADCvalue int : ADCvalue
Figure B.8: Sequence diagram for an analog to digital conversion in the I/O drivers
63
Appendix C
Simulation Results
C.1 Simulation results of individual functions
64
APPENDIX C. SIMULATION RESULTS
Input: Wheel speed 300 250 Speed [km/h] 200 150 100 50 0 Input: Steering angle 50 40 Angle [] 30 20 10 0 -10 Input: Brake pedal 1.5 Brake pedal 1 0.5 0 -0.5 Output: Window close 1.5 Window close 1 0.5 0 -0.5 Output: Wing angle contribution per controller 80 60 Angle [] 40 20 0 Output: Wing angle 80 Wing angle 60 Angle [] 40 20 0 0 10 20 30 Time [s] 40 50 60 Vehicle speed Steering angle Brake pedal Steering angle Wheel speed front Wheel speed rear Vehicle speed
Figure C.1: Simulation results for the active aerodynamics controller
65
Input: Wheel speed 120 100 80 Speed [km/h] 60 40 20 0 Input: Brake pedal 1.5 Brake pedal Wheel speed front Wheel speed rear Vehicle Speed
0.5
-0.5 Calculated slip 50 40 30 20 10 0 -10 Output: Brakes 1.5 Brakes front Brakes rear 1 Slip front Slip rear ABS boundary
Slip [%]
0.5
-0.5
10
20
30 Time [s]
40
50
60
Figure C.2: Simulation results for the ABS controller
66
Input: Buttons 1.5 Button Up Button Down
0.5
-0.5 Input: External signals 1.5 Open signal Close signal
0.5
-0.5 120 Output: Window position (100% = fully closed) Position controller Window position 100
80
Position [%]
60
40
20
-20
10
15
20 Time [s]
25
30
35
40
Figure C.3: Simulation results for the power window controller
67
C.2
150
Simulation results of full system

POC_total/Front Input Signals Profile : TestCase WheelSpeedFront
100 20 10 0 1 0.5 0 0 10 20 30 Time (sec) 40 50 60 SteeringAngle
BrakePedal
POC_total/Rear Input Signals Profile : TestCase
0.5 0 180 160 140 120 1 0.5 0 1 0.5 0 0
EnableAero
WheelSpeedRear
ButtonUp
ButtonDown 10 20 30 Time (sec) 40 50 60
Figure C.4: Full system simulation input signal
68
Speed 180 WheelSpeedFront WheelSpeedRear VehicleSpeed
160
Speed [km/h]
140
120
100
80
60
40 35 30 25 20 Slip [%] 15 10 5 0 -5 -10 0 10 20
Slip SlipFront SlipRear ABS boundary
30 Time [s]
40
50
60
Figure C.5: Full system simulation calculated internal values
69
1.5
Brakes FrontBrake RearBrake BrakePedal
0.5
-0.5 Wing angle
75
70
Angle []
65
60
55
50
45 Window position (100% = fully closed) 100 90 80 70 Position [%] 60 50 40 30 20 10 0 0 10 20 30 Time [s] 40 50 60
Figure C.6: Full system simulation output signals
70
Appendix D
Safety Argumentation
D.1 Functional Safety Requirements
HLR 1. It is obligatory that the window moves in the direction of the button that is pressed. LLR 1.1. It is obligatory that the window moves up when the up button is pressed. LLR 1.2. It is obligatory that the window moves down when the down button is pressed. LLR 1.3. It is obligatory that the window keeps its position when no button is pressed. LLR 1.4. It is obligatory that the window keeps its position when both buttons are pressed simultaneously. HLR 2. It is prohibited that the window exceeds the limits. LLR 2.1. It is prohibited that the window moves up from the maximum position. LLR 2.2. It is prohibited that the window moves down from the minimum position. HLR 3. It is obligatory that the controller shares the position of the window with other functions. LLR 3.1. It is obligatory that the controller sends the position of the window over the CAN bus. HLR 4. It is permitted that an external function operates the window only if the external function has a higher priority than the window controller. LLR 4.1. It is permitted that an external function moves the window to its maximum position. LLR 4.2. It is permitted that an external function moves the window to its minimum position. LLR 4.3. It is obligatory that the window moves to its maximum position if both maximum and minimum signal are given simultaneously. HLR 5. It is obligatory that the window moves to its maximum position when the vehicle exceeds a speed threshold. HLR 6. It is obligatory that the window moves to its minimum position when the vehicle gets into water. HLR 7. It is obligatory that the window moves to its maximum position when the vehicle crashes. HLR 8. It is obligatory that the window moves to its maximum position when the vehicle gets locked.
71
72
Top_Goal Power window is acceptable safe to operate
Window_Design Power window design
D.2
GSN diagram
Window_HARA HARA report of power window
Str_Hazard Argument by addressing all identified power window hazards
Window_Hazard1 Hazards for interaction with other functions are sufficiently mitigated
Window_Hazard2 Hazards for stand-alone functions of power window are sufficiently mitigated Window_Hazard3 Hazards for power window hardware are sufficiently mitigated.
Window_Hazard4 Hazards for power window deployment are sufficiently mitigated.
APPENDIX D. SAFETY ARGUMENTATION
Str_Functional_Hazard Argument by addressing all identified functional hazards
Windwo_Hazard1 Hazard of the window not moving according the selected controls is sufficiently mitigated.
Windwo_Hazard2 Hazard of the window exceeding its limits, braking the actuator is sufficiently mitigated.
BD_FSR Functional safety requirement of button design WCD_FSR Functional safety requirement of window controller design
Window_FSR1 The window must move in direction of button that is pressed
Window_FSR2 The window cannot exceed limits
Figure D.1: GSN diagram of power window use case

Button_Req3 The window will keep position when no button is pressed
Button_Req1 The window will move up when up button is pressed
Button_Req2 The window will move down when down button is pressed
Button_Req4 The window will keep position when both button are pressed at the same time
Max_Pos Maximum position
Window_Controller_Req1 Window will not move up from maximum position.
Window_Controller_Req1 Window will not move down from minimum position.
Min_Pos Minimum position

Button control design
Simulation results
Simulation results
Simulations results
Simulations results
Simulations results
Window controller design
Simulations results
D.3
GSN pattern
TopGoal {System Y} is acceptably safe to operate.
Con:system {Description of {System Y}}
Ass:hazards All hazards of {System Y} have been correctly identified
Strat:allHazards Argument over all identified hazards of {System Y}
S=# number of parts which may contribute to {System Y} hazards
Goal: hazards Hazards for {Part S} is sufficiently mitigated.
Strat:allCatHazards Argument over all identified hazards of {Part S}
T=# number of hazards of{Part S}
Goal: hazard {Hazard T} is sufficiently mitigated.
Con:system {Description of {Hazard T}}
Ass:safetyreqs All SRS for {Hazard T} have been correctly designed.
Strat:allEleHazards Argument over all safety requirements for {Hazard T}
R=# number of SRs designed for {Hazard T}
Goal: FSR {SR R} is acceptably managed.
Con:system {Description of {SR R}}
Figure D.2: GSN pattern used to create the GSN diagram
73
74
Top_Goal It is obligatory that power window is operated in an acceptable safe level.
Window_Design Power window design Window_HARA HARA report of power window Str_Hazard The argument covers all identified hazards of power window.
D.4
Window_Hazard1 Hazards of the power window interaction functions are sufficiently mitigated. Window_Hazard3 Hazards of power window hardware are sufficiently mitigated.
Window_Hazard2 Hazards of the power window stand-alone functions are sufficiently mitigated.
Window_Hazard4 Hazards of power window deployment are sufficiently mitigated.
Str_Functional_Hazard The argument covers all identified functional hazards.
Windwo_Hazard1 It is obligatory that Hazard HD1 is sufficiently mitigated.

HARA_report HARA report of power window WCD_FSR Functional safety requirement of window controller design
Windwo_Hazard2 It is obligatory that Hazard HD2 is sufficiently mitigated.

Window_FSR2 It is prohibited that the power window exceeds a given limit.
GSN diagram with SBVR applied
BD_FSR Functional safety requirement of button design
Window_FSR1 It is necessary that the power window moves in direction of pressed button.
Figure D.3: GSN diagram of power window use case with SBVR applied
Button_Req3 It is obligatory that if no button is pressed then the power window keeps its position.
Button_Req1 It is obligatory that if the up button is pressed then the power window moves up.
Button_Req2 It is obligatory that if the down button is pressed then the power window moves down.
Button_Req4 It is obligatory that if the up button and the down button are pressed then the power window keeps its position.
Max_Pos Maximum position
Window_Controller_Req1 It is prohibited that the power window moves up at a given maximum position.
Window_Controller_Req1 It is prohibited that the power window moves down at a given minimum position.
Min_Pos Minimum position

Button control design
Simulations results Simulations results Simulations results
Simulation results
Simulation results
Window controller design
Simulations results

Proof of Concept of An Integrated Automotive Architecture

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Proof of Concept of An Integrated Automotive Architecture

Enviado por

Direitos autorais:

Formatos disponíveis

Master Automotive Technology Department of Mathematics and Computer Science Software Engineering and Technology Research Group

Proof of Concept of an Integrated Automotive Architecture

Eindhoven, November 2013

Proof of Concept of an Integrated Automotive Architecture

Proof of Concept of an Integrated Automotive Architecture

Proof of Concept of an Integrated Automotive Architecture

5.2.2 Software Setup 5.2.3 Design Choices 5.2.4 Implementation Conclusion . . . . . .

. . . . . . . . . . . . . . . . . . . . of the Use Cases . . . . . . . . . .

Proof of Concept of an Integrated Automotive Architecture

Proof of Concept of an Integrated Automotive Architecture

Proof of Concept of an Integrated Automotive Architecture

Proof of Concept of an Integrated Automotive Architecture

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

Proof of Concept of an Integrated Automotive Architecture

Research Method and Thesis Outline

Proof of Concept of an Integrated Automotive Architecture

One-Function-One-ECU Design Philosophy

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

State the Problem

Model the System

Launch the System

Controller Area Network

1 1 1 RTR IDE reserved

1 1 1 CRC-Delimiter ACK-Slot ACK-Delimiter

Time Triggered Controller Area Network

exclusive time windows;

Figure 1 Basic cycle of time-triggered CAN

ISO 2004 All rights reserved

From Federated to Integrated Architectures

CHAPTER 3. RELATED WORK

Fully Centralized Control

CHAPTER 3. RELATED WORK

Integrated Architecture on Chip

Proof of Concept of an Integrated Automotive Architecture

Integrated Automotive Architecture

CHAPTER 4. INTEGRATED AUTOMOTIVE ARCHITECTURE

Soft ware Architecture

Central ECU Soft ware

Satellite ECU Soft ware

Proof of Concept of an Integrated Automotive Architecture

CHAPTER 4. INTEGRATED AUTOMOTIVE ARCHITECTURE

Figure 4.2: Hardware topology for the IM01

Generic Hardware Platform

Generic hardware platform

CHAPTER 4. INTEGRATED AUTOMOTIVE ARCHITECTURE

Function Sensors Input Processing Output Actuators

Generic hardware platform

Generic Hardware Platform

Generic hardware platform

Processing Communication Processing* Communication

Output Communication (Postprocessing) Outputs Communication Actuators

*Interaction with other functions possible

Figure 4.5: Architecture for a software function

CHAPTER 4. INTEGRATED AUTOMOTIVE ARCHITECTURE

CHAPTER 4. INTEGRATED AUTOMOTIVE ARCHITECTURE

Proof of Concept of an Integrated Automotive Architecture

CHAPTER 4. INTEGRATED AUTOMOTIVE ARCHITECTURE

Proof of Concept of an Integrated Automotive Architecture

Active Aerodynamics System

CHAPTER 5. PROOF OF CONCEPT

Wheel speed sensor

Wing angle actuator

Steering angle sensor