
Automotive Inter-networking
Beschreibung
Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.
Weitere Details
Weitere Ausgaben
Andere Ausgaben


Personen
Dr Timo Kosch, Team Manager, BMW Group Research and Technology, Germany Timo Kosch works as a team manager for BMW Group Research and Technology where he is responsible for projects on distributed systems, including such topics as cooperative systems for active safety and automotive IT security. He has been active in a number of national and international research programs and serves as coordinator for the European project COMeSafety, co-financed by the European Commission. He's also heading the system development for the German national Car2X field test. For more than 3 years, until recently, he had chaired the working group Architecture and was a member of the Technical Committee of the Car-to-Car Communication Consortium. He regularly presents at conferences and has written papers and journal articles and is currently the editor of IEEE Communications Magazine: Automotive Networking Series.
Markus Strassberger, BMW Group Research and Technology, Munich, Germany
Christoph Schroth, St. Gallen University / SAP Research, Switzerland PhD student at the University of St. Gallen and Research Associate at the SAP Research CEC St. Gallen, Sitzerland. He has presented a number of papers at conferences and co-authored numerous journal articles.
Inhalt
Preface xi
List of Abbreviations xiii
1 Automotive Internetworking: The Evolution Towards Connected and Cooperative Vehicles 1
1.1 Evolution of In-Vehicle Electronics 1
1.2 Motivation for Connected Vehicles 4
1.3 Terminology 7
1.4 Stakeholders 10
1.5 Outline of this Book 10
References 12
2 Application Classifications and Requirements 13
2.1 Classification of Applications and their Implications 14
2.1.1 Driving-Related Applications 15
2.1.2 Vehicle-Related Applications 19
2.1.3 Passenger-Related Applications 22
2.2 Requirements and Overall System Properties 25
2.3 Overview on Suitable Communication Technologies 28
2.3.1 Communication Technologies 28
2.3.2 Suitability for AutoNet Applications 31
2.4 Summary 34
References 34
3 System Architecture 37
3.1 Domain View of AutoNets 37
3.2 ISO/OSI Reference Model View 40
3.3 Profiling 42
3.4 Standardised Architectures 43
3.4.1 Architecture of the C2C Communication Consortium (C2C-CC) 44
3.4.2 ISO TC204 CALM Architecture 45
3.4.3 ETSI TC ITS Architecture: EN 302 655 47
3.4.4 IEEE WAVE Architecture Featuring IEEE802.11p and IEEE1609.x Standards 49
3.5 Subsystem Architectures 50
3.5.1 Vehicle Architecture 51
3.5.2 Roadside Architecture 55
3.5.3 Infrastructure Architecture 56
3.5.4 Mobile Device Architecture 61
3.6 Summary 62
References 63
4 Applications: Functionality and Protocols 65
4.1 Foresighted Safety Case Study: Environmental Notifications 67
4.1.1 Data Collection and Individual Situation Analysis 68
4.1.2 Cooperative Situation Analysis 71
4.1.3 Distributed Knowledge Management 73
4.1.4 Individual Relevance and Interface to the Driver 75
4.1.5 Data Security and Privacy 77
4.1.6 Reliable Estimation of the Current Driving Condition 78
4.1.7 Communication and Information Dissemination 79
4.1.8 Standardisation Issues 80
4.2 Active Safety Case Study: Cooperative Collision Avoidance and Intersection Assistance 81
4.2.1 Data Collection 82
4.2.2 Situation Analysis and Application Logic 83
4.2.3 Knowledge Management 88
4.2.4 Communication 90
4.2.5 Security and Privacy 93
4.2.6 Driver Interaction 95
4.3 Green Driving Case Study: Traffic Lights Assistance 98
4.3.1 Green Light Optimal Speed Advisory 99
4.3.2 Example: TRAVOLUTION 107
4.4 Business and Convenience Case Study: Insurance and Financial Services 107
4.4.1 Accident Management Services 108
4.4.2 Examples for Insurance and Financial Services (IFS) 116
References 118
5 Application Support 121
5.1 Application Support in the AutoNet Generic Reference Protocol Stack 121
5.2 Communication Aspects in the Application Support 123
5.2.1 CAM: Cooperative Awareness Messages 123
5.2.2 DENM: Decentralised Environmental Notification Messages 125
5.3 AutoNet Facilities 125
5.3.1 Application Plane 126
5.3.2 Information Plane 128
5.3.3 Communication Plane 130
5.4 Implementation Issues for the Application Support Layer 131
5.5 Summary 133
References 133
6 Transport Layer 135
6.1 Transport Layer Integration in the AutoNet Generic Reference Protocol Stack 135
6.1.1 AutoNet Transport 137
6.1.2 Tcp, Udp 138
6.2 TCP in AutoNets 139
6.2.1 Congestion Control in TCP 140
6.2.2 Impact of AutoNets 141
6.2.3 Enhancements of TCP and Technical Requirements for AutoNet Scenarios 143
6.2.4 The MOCCA Transport Protocol 144
6.2.5 Evaluation Results 148
6.3 Summary 151
References 152
7 Networking 155
7.1 Networking Principles in the AutoNet Generic Reference Protocol Stack 155
7.1.1 Network Layer Functionality in AutoNets 155
7.1.2 Network Protocol Data Units 158
7.2 AutoNet Ad-Hoc Networking 160
7.2.1 AutoNet Ad-Hoc Network Characteristics 160
7.2.2 AutoNet Ad-Hoc Network Addressing and Routing 165
7.2.3 Beaconing 176
7.2.4 Network Utility Maximisation in AutoNets 177
7.3 AutoNet Cellular Networking 187
7.3.1 Communication Architecture for AutoNet Cellular Networking 189
7.3.2 Deployment Strategies 190
7.3.3 Interactions and Cross-Layer Optimisations 192
7.4 IPv6 and Mobility Extensions 192
7.4.1 IPv 6 193
7.4.2 Mobility Extensions 194
7.4.3 Deployment Issues 197
References 200
8 Physical Communication Technologies 205
8.1 Wireless Networks in the AutoNet Generic Reference Protocol Stack 206
8.2 Automotive WLAN and DSRC 208
8.2.1 Spectrum Policies 209
8.2.2 IEEE 802.11p 213
8.2.3 Etsi G5a 221
8.3 Utility-Centric Medium Access in IEEE 802.11p 221
8.3.1 Data Differentiation 221
8.3.2 Inter-Vehicle Contention 222
8.3.3 Cross-Layer Issues 223
8.3.4 Evaluation of Utility-Centric Medium Access 225
8.4 Technology Comparison 230
8.5 Conclusion 231
References 231
9 Security and Privacy 233
9.1 Stakes, Assets, Threats and Attacks 235
9.1.1 Stakeholders and Assets 235
9.1.2 Threats and Attacks 236
9.2 Challenges and Requirements 238
9.3 AutoNet Security Architecture and Management 241
9.4 Security Services 244
9.4.1 Cryptographic Mechanisms 244
9.4.2 Digital Signatures 246
9.5 Certification 247
9.5.1 Trust 247
9.5.2 Trusted Third Platforms: Certificate Authorities 249
9.5.3 Certificate Generation and Distribution 250
9.5.4 Certificate Revocation 253
9.6 Securing Vehicles 253
9.7 Secure Communication 254
9.7.1 Secure Messaging 254
9.7.2 Secure Routing and Forwarding 255
9.7.3 Secure Group Communication 255
9.7.4 Plausibility Checks 255
9.8 Privacy 256
9.8.1 Secret Information 256
9.9 Conclusion 258
References 259
10 System Management 261
10.1 System Management in the AutoNet Generic Reference Protocol Stack 261
10.2 Functional Management Building Blocks 263
10.3 Selected Management Issues of an AutoNet Station 264
10.3.1 Cost/Benefit Management 264
10.3.2 Congestion Control 265
10.3.3 Mobility Management 265
10.3.4 TCP Management 268
10.4 Implementation Issues of the Management Layer 270
10.5 Summary 271
References 271
11 Research Methodologies 273
11.1 Early Activities to Investigate AutoNets 274
11.1.1 Activities at the University of Duisburg 274
11.1.2 Activities at the Ohio State University 275
11.2 Methodologies 277
11.2.1 Model Domains for AutoNets 278
11.2.2 Dependency Examples 280
11.3 Simulation Methodology 282
11.3.1 Communication Network Simulation 284
11.3.2 Traffic Simulation 287
11.3.3 Implementation Issues 290
11.4 Field Operational Testing Methodology 298
11.4.1 Applications and Requirements 300
11.4.2 System Architecture 302
11.4.3 Trials 304
11.4.4 Analysis 306
11.5 Summary 307
References 307
12 Markets 309
12.1 Current Market Developments 310
12.1.1 Technological Push 311
12.1.2 Economic Pull 311
12.1.3 Stakeholder Analysis 312
12.2 Challenges 327
12.2.1 Harmonisation and Standardisation 328
12.2.2 Life Cycle 330
12.2.3 Costs and Revenues in an Emerging Business Ecosystem 330
12.2.4 Customer Acceptance 331
12.3 Driving the Emergence of a Coherent Business Ecosystem 333
12.3.1 Strategies for the Development of a Modular Business Ecosystem 333
12.3.2 Early Examples of Telematic Business Ecosystems 339
12.4 Summary 342
References 342
13 Impact and Future Projections 345
A Appendix 351
A.1 Standardisation Bodies for AutoNets 351
A.. 1 Etsi 351
A.1. 2 Cen 352
A.1. 3 Iso 353
A.1. 4 Ietf 354
A.1. 5 Ieee 354
A.1. 6 Car2Car Communication Consortium 354
A.2 Research Projects on AutoNets 355
A.2.1 Early Activities 355
A.2.2 The eSafety Initiative 358
A.2.3 COMeSafety 360
A.2.4 Coopers 361
A.2.5 Cvis 361
A.2.6 Safespot 363
A.2.7 SeVeCom 363
A.2.8 GeoNet 363
A.2.9 Frame, E-frame 364
A.2.10 VII and Intellidrive 364
A.2.11 Travolution 365
A.2.12 Aktiv 365
A.2.13 Pre-drive C2x 366
A.2.14 simTD 367
References 368
Index 369
1
Automotive Internetworking: The Evolution Towards Connected and Cooperative Vehicles
Safety on the road is one of the most important aspects of mobility: people want to be highly mobile, but they also have a great interest in travelling safely to their destinations. This is of particular importance since the request for mobility is permanently growing, and thus travelling on the road is getting more and more crowded and dangerous. According to surveys in 2009 of the Federal Statistical Office in Germany (destatis) shown in Figure 1.1, the total mileage of people travelling in Germany continuously increased, and was three times higher in 2008 compared to 1970. At the same time, the number of accidents has also increased by 70% over the past 30 years.
However, Figure 1.1 also shows that the total number of road fatalities - that is severe accidents where death results - continuously decreased in this time interval to about 25% compared to 1970. This is mainly due to the fact that both active and passive safety of the vehicles have been improved and vehicles have become more 'intelligent'. As we will see in the following sections, this intelligence has been mainly driven by the introduction of electronics and software in vehicles, which are basically focused on the 'autonomous perception' of the vehicle itself, that is the vehicle only gets information about its surrounding from its own sensors. In this book, we will address the next logical step where cooperative vehicles exchange information between each other and with their environment. Experts agree that this is one of the key technologies to reduce both fatalities and the number of accidents in everyday traffic.
Figure 1.1 Development of accidents in Germany in the context of mileage and road fatalities.
In the following sections, we will introduce the advances in in-vehicle electronics, and we will explain the idea of connected and cooperative vehicles. We will also define the terminology we use throughout this book, and we will introduce the different stakeholders involved in such a cooperative system. Finally, an outlook about the contents of this book concludes this chapter.
1.1 Evolution of In-Vehicle Electronics
In the 1950s, automobiles were still basically mechanical products. Vehicle development in those days was focused on the mechanical components needed to get vehicles moving quickly and safely. In the past few decades, electronics has risen as another major component of a vehicle's value, making up around 5% in the early 1970s, growing to 20% in the 1990s and today reaching a mean share of around one third of the value of modern cars. Software has become a major part of this value share, divided approximately into 20% of sensor value, 40% of electronics hardware value and another 40% of software value. This means that the share of software has doubled within the last ten years.
The first generation of vehicle electronics were stand-alone in-vehicle systems that were basically automating or supporting certain driving tasks or comfort features. Prominent examples for systems supporting the driving task are servo (power) steering and anti-lock braking systems. Comfort-oriented systems included the car stereo, electronic windows and automated locking systems. These systems have been implemented with so-called ECUs (electronic control units). The number of ECUs in a typical mid-class vehicle has increased from only a few in the mid-to-late 1990s up to around 50 and more at the end of the first decade of the new millenium. The ECUs control almost every activity in a modern vehicle in order to improve travel comfort and safety and to reduce fuel consumption. Compared to the desktop computer market, the embedded system market has featured a far greater variety of platforms and operating environments. As a move to reduce costs, speed up development and improve quality, French vehicle manufacturers founded VDX (vehicle distributed executive) in 1988, and German vehicle manufacturers and suppliers, together with the University of Karlsruhe, founded OSEKTin 19931 in order to establish an industry standard for an open-ended architecture for distributed control units. The two consortia became one joint OSEK/VDX group in 1994. With OSEK-OS, a specification for a real-time operating system for ECUs was published. In 2005, it became an international standard as ISO 17356-3.2
Besides architecture and system platforms, special communication networks have been developed to interconnect the originally stand-alone systems. For the data exchange of ECUs in vehicles, special vehicle communication systems have been introduced. In 1983, the company Bosch developed the CAN (controller area network) bus which was used commercially in automobiles less than ten years later. Today, it is standardised as ISO 11898. The MOST (media oriented systems transport) [3] bus system defines an optical network and was introduced to satisfy multimedia requirements. Specifications are defined and published by the MOST Cooperation, which was founded in 1998. Around the same time, the LIN consortium (Local Interconnected Network) started as a working group and the first specification of the low-cost solutions-oriented LIN bus was published in 2000. The Flexray consortium was then founded in that same year and has since then defined the FlexRay as a real-time bus system. Many of these activities have been addressed by the AUTOSAR consortium (Automotive Open System Architecture) since 2003. AUTOSAR defines an in-vehicle software architecture with a purpose to support re-use, exchange and integration of software components across platforms and to integrate the different bus systems.
The in-vehicle networks allow the ECUs to exchange data and to realise ever more complex functionality. At the same time, the interface to the driver has become more complex as many of these new functions need to be controlled or interact with the driver. These in-vehicle networks also enable highly sophisticated driver assistance systems that use interconnected sensor technology to constantly monitor the vehicle's environment. Complex sensor-actuator networks have been developed, enabling features such as active cruise control (ACC) , electronic stability programs (ESP) and night vision systems.
While complex in-vehicle networks are state of the art, they are still not or barely connected to systems outside. Hence, a vehicle today is still a relatively autonomous system, because most of the functionality of the vehicle relies on information generated by itself. During the last few years, manufacturers have started to provide connectivity to and from vehicles. BMW's ConnectedDrive technology was the first available system establishing a communication channel between specifically equipped vehicles and a dedicated BMW back-end infrastructure. This connectivity has largely been used for driver-oriented information services like traffic or weather information, emergency call support or mobility assistance through remote vehicle diagnostics.
These features were not originally addressed directly to driving-related tasks; in fact, this type of connectivity was rather viewed as a key technology to introduce new types of applications and services to drivers. Most likely, vehicle connectivity to the outside will be restricted to the non-driving related domain and remain running through the manufacturer's server infrastructure in the near future. Nevertheless, enabling this data exchange between vehicles and dedicated back-end systems can be seen as the origin of a 'connected vehicle'. As new wireless communication standards have emerged, security solutions are on the horizon and hardware prices are decreasing, we presume that the next important step in-vehicle electronics will be the connectivity of vehicles with traffic infrastructure entities and other traffic participants. This connectivity will then be used not only to provide convenience services to the driver, but more importantly to improve their original task: driving. It will not be only the driver information unit, but the vehicle ECUs in general will be networked with other ECUs in other vehicles and with traffic infrastructure controllers.
1.2 Motivation for Connected Vehicles
The main motivation for the application of wireless network technology to road traffic scenarios is to optimise driving with respect to safety and efficiency. Safety has long been one of the main drivers of vehicle communications. At the end of the 20th century, when many of the bigger research activities started in North America as well as in Europe and Japan, the global number of injuries caused by road traffic accidents was close to 40 million people and the number of fatalities was almost 1.2 million people.3
Statistics from the United States Department of Transportation's (US DoT) National Highway Traffic Safety Administration (NHTSA)4 show a total of 37,261 people killed in traffic accidents in 2008 in the United States alone, with about 2.35 million people injured. Estimates of the economic impact (from 2003) state a cost of 230 billion US Dollars related to traffic accidents.
While passive safety systems have been very effective in protecting the passengers, they will typically not help avoid the accident itself. Accident statistics show that the rate of fatalities and injuries over vehicle miles travelled has gone down in many developed countries. In the US, for instance, the injury rate was around 150 per 100 million vehicle miles travelled (VMT) around 1990, decreasing to about 120 at the turn of the millenium and going down...
Systemvoraussetzungen
Dateiformat: ePUB
Kopierschutz: Adobe-DRM (Digital Rights Management)
Systemvoraussetzungen:
- Computer (Windows; MacOS X; Linux): Installieren Sie bereits vor dem Download die kostenlose Software Adobe Digital Editions (siehe E-Book Hilfe).
- Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions oder die App PocketBook (siehe E-Book Hilfe).
- E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)
Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet – also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an.
Mit Adobe-DRM wird hier ein „harter” Kopierschutz verwendet. Wenn die notwendigen Voraussetzungen nicht vorliegen, können Sie das E-Book leider nicht öffnen. Daher müssen Sie bereits vor dem Download Ihre Lese-Hardware vorbereiten.
Bitte beachten Sie: Wir empfehlen Ihnen unbedingt nach Installation der Lese-Software diese mit Ihrer persönlichen Adobe-ID zu autorisieren!
Weitere Informationen finden Sie in unserer E-Book Hilfe.