Book contents
- Frontmatter
- Contents
- Preface
- Abbreviations
- Timeline
- 1 A brief history of “Ethernet” (from a car manufacturer’s perspective)
- 2 A brief history of in-car networking
- 3 A brief history of Automotive Ethernet
- 4 The physical transmission
- 5 Protocols for Automotive Ethernet
- 6 Ethernet in automotive system development
- 7 Outlook
- Index
- References
3 - A brief history of Automotive Ethernet
Published online by Cambridge University Press: 05 December 2014
- Frontmatter
- Contents
- Preface
- Abbreviations
- Timeline
- 1 A brief history of “Ethernet” (from a car manufacturer’s perspective)
- 2 A brief history of in-car networking
- 3 A brief history of Automotive Ethernet
- 4 The physical transmission
- 5 Protocols for Automotive Ethernet
- 6 Ethernet in automotive system development
- 7 Outlook
- Index
- References
Summary
When a new technology is being developed and enabled in an industry, there are various factors that impact the success of that technology. In the authors’ opinion the most important ones are its benefit, its costs, and the framework that allows an industry to develop around it. This chapter will discuss these topics with respect to Automotive Ethernet. However, as is also frequently pointed out (see e.g. [1–3]), it is not only technical facts but also individuals who act as the driving force behind a new technology. In respect to Automotive Ethernet, both authors feel that they have their share in the events. In consequence, the events in this chapter will sometimes be described from a personal viewpoint.
The first use case: programming and software updates
Architectural challenges
In 2004, BMW decided to introduce a central gateway in its cars starting from 2008 Start of Production (SOP) onwards. This central gateway was to combine two functions: (1) to route data between the different CAN, FlexRay, and MOST busses inside the cars; and (2) to function as the diagnostic and programming interface with the outside world. For the latter, BMW has always used a centralized approach. This means that software can only be flashed with an external tester device that is connected via the OnBoard Diagnostics (OBD) connector [4] and that all flashable Electronic Control Units (ECUs) inside the car are updated with their latest software versions. This approach assures that the customer always has the latest software in the car and that there are no sudden software inconsistencies in functional domains, in which some units have been updated and others have not. This is an architectural choice that, as it happens, was decisive for the introduction of Automotive Ethernet. Nevertheless, there are car manufacturers that use decentralized approaches for software updates and handle the version management differently. They might update e.g. only the multimedia/infotainment units via USB or DVD.
- Type
- Chapter
- Information
- Automotive Ethernet , pp. 63 - 91Publisher: Cambridge University PressPrint publication year: 2014