The decision on the overall functionality to provide with a car is first of all a marketing decision and independent of the in-car networking technologies used and available. However, as soon as decisions have to be made on how to enable the functionality, in-car networking becomes important. Aspects like flexibility, scalability, or how to distribute functions are severely impacted by the properties of in-car networking. This chapter thus discusses the opportunities and changes Automotive Ethernet brings to system development.

A brief overview of the system development process

The development process in automotive follows the V-cycle. While Section 2.3.1 used the V-cycle to explain the responsibilities shared between car manufacturer and Tier 1 supplier, in this section the model is used to explain the changes the introduction of Ethernet-based communication brings to the development process. The important idea of the V-cycle is to follow a top-down approach on the development side and a bottom-up approach on the test side. On both sides, each new step requires the conclusion of the previous. During the development, the later need for testing is directly supported with the provision of test cases. This ensures stringent test coverage.

Preface

On 11 November 2013, I [Kirsten Matheus] attended a celebration of 40 years since the invention of Ethernet at an IEEE 802 plenary meeting. During the celebration Robert Metcalfe, David Boggs, Ronald Crane, and Geoff Thompson were honoured as the pioneers of Ethernet. If I had to name the people without whom Automotive Ethernet would not have happened, I would name Thomas Königseder, technical expert at BMW and co-author of this book, and Neven Pischl, EMC expert at Broadcom.

It all started in 2004, when Thomas received the responsibility for speeding up the software flash process for BMW cars. With the CAN interface used at the time, flashing the 1 Gbyte of data anticipated for 2008 would have required 16 hours to complete. After careful evaluation, Thomas chose and enabled the use of standard 100BASE-TX Ethernet for this purpose. Thus in 2008 the first serial car with an Ethernet interface, a BMW 7-series, was introduced to the world.

Role of in-car networking

An explanation of the needs, the development, and some of the choices in in-car networking starts with the windows. When automobiles were invented they were simply machines on wheels without windows. It was only later that windows were added, first at the front, then at the sides and back. The windows were static or insertable in one piece. This obviously was not very comfortable, neither for the handling of the windows, nor for the temperature regulation in the passenger cabin. Thus, in 1928 the first mechanical window winder, able to hold a window at any position desired, was presented to the public [1]. The first power windows were introduced in 1941 [2]. BMW was the first company to introduce power windows in Europe and the first BMW with all electric power windows was a “Serie 2 BMW 503,” which had an SOP at the end of 1957 [3]. This is where it gets interesting.

It is quite straightforward to imagine a switch in a vehicle door that actuates the electric motor for a window located in the same door. Everything is in one physical location and the wiring will be short. The wiring gets longer when all movable windows are required to be controllable by the driver, in addition to the “local” control in every door. More wiring between almost exactly the same locations is needed if a central door lock plus an electronic side mirror adjustment are also discretely wired. Figure 2.1(a) indicates that with only the basic comfort functions the size, weight, and number of wires will soon become prohibitive. In the case of discrete wiring, inventiveness quickly circles around the question of “How is it possible to fit another wire onto this inline connector or through this opening between e.g. body and door?” instead of fully exploring the possibilities of creating a new feature. On top of this, large wiring bundles are not only heavy, costly, and hard to install, but also error prone and difficult to diagnose [4].

To understand physical transmission in in-car networks two aspects are important: the actual automotive environment in which the communication happens and how the properties of the PHY technology ensure its use in this environment. This chapter will therefore start with the PHY technologies in Section 4.1, explain the automotive channel in Section 4.2, and discuss ElectroMagnetic Compatibility (EMC) in Section 4.3. Other important requirements in this context, such as semiconductor quality, Power over Data Line (PoDL), and Energy Efficient Ethernet (EEE), are introduced in Section 4.4.

The Physical Layer (PHY) technology

100 Mbps BroadR-Reach (OABR)

It all started with the IEEE 802.3 1000BASE-T standard. During its development, the engineers at Broadcom learned to handle the communication challenges that needed to be mastered for such a high data rate transmission. So when Ethernet in the First Mile (EFM) was being developed at IEEE, Broadcom reused some of the basic principles of 1000BASE-T for a suitable solution: instead of four pairs of wiring one pair was used and the channel coding was made more robust, so that it was possible to transmit 100 Mbps data over a worse, i.e. longer, channel. IEEE standardized a different solution for EFM, while Broadcom proposed their technology for EFM in China [1]. When BMW was looking for an Ethernet solution suitable for automotive another interesting use case was found for the Broadcom technology.

From the beginning

In 1969 employees at AT&T/Bell Labs developed the first version of Unix. The original intention was to aid the company’s internal development of software on and for multiple platforms, but over time Unix evolved to be a very widespread and powerful operating system, which facilitated distributed computing. An important reason for the successful proliferation of Unix was that for antitrust reasons AT&T was neither allowed to sell Unix nor to keep the intellectual property to itself [1]. In consequence Unix – in source code – was shared with everybody interested.

It was especially, but not only, embraced by universities and the community that evolved provided the basis for the computing environment we are used to today and in which also Ethernet has its place. At a time when computing was dominated by large, proprietary, and very expensive mainframe computers few people could use, Unix created a demand for Local Area Networking (LAN) while at the same time providing an affordable, common platform for developing it [2]. As one example, a group at the University of California, Berkeley created a Unix derivative. The Berkeley Software Distribution (BSD) was first released in 1978 and its evolutions became as established as the “BSD-style license” attached to it [3]. Another example is the TCP protocol. The first version of this, published in 1974, was implemented for Unix by the University of Stanford by 1979 [4]. Later in 1989, the then up-to-date TCP/IP code for Unix from AT&T was placed in the public domain and thus significantly helped to distribute the TCP/IP Internet Protocol Suite [5].

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.

One of the reasons for the automotive industry to adopt Ethernet-based communication as an in-car networking system is the chance for synergies, i.e. the possibility of reusing protocols that have been developed and tested in other applications. Across the various protocol layers for the various applications it therefore needs to be carefully investigated whether to adopt, adapt, or to add protocols. Figure 5.1 gives an example overview of the protocol stack. This chapter discusses three areas that require special care: how to adopt and potentially adapt Audio Video Bridging (AVB, see Section 5.1); how to use the Internet Protocol (IP) and Virtual LANs (VLANs, see Sections 5.2 and 5.3); and what is needed in terms of command and control (see Section 5.4). Be aware that there might be other solutions that work. The described solutions make no claim to be complete; nevertheless they do work.

Quality of Service (QoS) and Audio Video Bridging (AVB)

Ethernet as such, i.e. the PHY and MAC layers as defined by IEEE 802.3, provide best-effort traffic only. Going to “full-duplex,” in the sense of switched Ethernet networks, improved the determinism of each individual link, since a number of units no longer needed to contend for the same medium at potentially the same time and have to go into random, i.e. non-deterministic, back-off periods. However, in a switched network, data of different sources with different destinations might have to be sent over the same link at the same time. It is therefore in the switch – often also referred to as a bridge – that many QoS requirements can effectively be supported. Today, it is mainly at IEEE 802.1 that the respective standards are being developed. The following sections will give some background information on the standards’ activity (Section 5.1.1), and enlighten the differences between the originally envisioned use cases and automotive deployment (Section 5.1.2). In return, this allows describing how each QoS standard can best be used in in-car networking (Section 5.1.3), before the efforts of how to go beyond the QoS for audio and video are described (Section 5.1.4).

There are in principle two types of innovations: incremental and radical. While incremental innovations improve key market features on the basis of existing methods and technologies, radical innovations are based on new technologies that either revolutionize an existing market and/or even create a new one. The uncertainty of the consequences of an innovation increases from incremental to radical. For example, the costs and improvements for an incremental innovation can generally be assessed more easily than for a radical innovation. A radical innovation often requires more investment and holds a greater risk of technological failure. The important aspect, however, is that a radical innovation has the chance to change a market so profoundly that – among other consequences – it will leave behind those who did not perform the change (see e.g. [1]).

At the time of writing, there were two automotive innovation fields with potentially far-reaching consequences: alternative drives/electric vehicles and automated driving. For both innovations, networking is extremely important and both require the vehicle to be connected to the worldwide network. Furthermore, both have the potential to change the car related user behavior, significantly more fundamentally than e.g. the introduction of navigation systems did. With the limitations of current battery technologies, the reach of an electric car is shorter than that of a car with a combustion engine. Because of the shorter reach, it is extremely important to be able to correctly predict the remaining reach at any time. Users will then become aware of the difference it makes if they switch off the air conditioning or infotainment and they might develop new behavior patterns. This includes wearing gloves, opening the windows, or accepting a detour if this avoids very hilly terrain. The impact of electric cars will be profound.