Energy Consumption of In-Vehicle Communication in Electric Vehicles : A comparison between CAN, Ethernet and EEE

(1)

Linköpings universitet SE–581 83 Linköping

Linköping University | Department of Computer and Information Science

Master thesis, 30 ECTS | Computer Science

2019 | LIU-IDA/LITH-EX-A--19/051--SE

Energy Consumption of

In-Vehicle Communication in

Electric Vehicles

–

A comparison between CAN, Ethernet and EEE

Energikonsumtion vid intern kommunikation i elbilar – En

jäm-förelse mellan CAN, Ethernet och EEE

Kimberley French

Supervisor : Klervie Toczé Examiner : Ola Leiﬂer

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Över-föring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och till-gängligheten ﬁnns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet än-dras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

(3)

Abstract

As a step towards decreasing the greenhouse gas emissions caused by the transport sector, electrical vehicles (EVs) have become more and more popular. Two major problem areas the EV industry is currently facing are range limitations, i.e. being restricted by the capacity of the battery, as well as a demand for higher bandwidth as the in-vehicle communication increases. In this thesis, an attempt is made to address these problem areas by examin-ing the energy consumption required by Controller Area Network (CAN) and Ethernet. In addition, the effects of Energy-Efficient Ethernet (EEE) are reviewed. The protocols are examined by performing a theoretical analysis over CAN, Ethernet and EEE, physical tests over CAN and Ethernet, as well as simulations of EEE. The results show that Ethernet re-quires 2.5 to four times more energy than CAN in theory, and 4.5 to six times more based on physical measurements. The energy consumption of EEE depends on usage, ranging from energy levels of 40 % less than CAN when idle, and up to equal amounts as regular Ethernet at high utilisation. By taking full advantage of the traits of Time-Sensitive Net-working, EEE has the potential of significantly decreasing the amount of energy consumed compared to standard Ethernet while still providing a much higher bandwidth than CAN, at the cost of introducing short delays. This thesis provides insight into the behaviour of a transmitter for each of the three protocols, discusses the energy implications of replacing CAN with Ethernet and highlights the importance of understanding how to use Ethernet and EEE efficiently.

(4)

Acknowledgments

The author would like to take this opportunity to extend her thanks to all involved in ensur-ing the completion of this project:

Thank you, Björn Bergholm and the others at Broccoli Engineering, for providing office space, hardware components and both mental and technical support during this project. In addition, you have all been very open and welcoming to your community, making me feel like part of the team.

To my supervisor, Klervie Toczé, who has been supportive and honest even during the tough times, and provided me with valuable feedback to make this thesis as good as possible, I would like to say a big thank you. Further, my examiner, Ola Leifler, has been involved in setting me on the right path when I have become lost, and has taken his time to help me proceed in my work and be always optimistic, to which I am very grateful. I would also like to thank Rickard Hellenberg for his helpful comments and kind words, as well as being so accommodating in his time plan.

My dear friend August has always been available when I’ve needed someone to juggle ideas with. Even when my work has made no sense to him, he has tried his best to help me on my way, coming up with all kinds of ideas and listening to my whinging. Thank you for always being there for me, and providing me with a home away from home during my visits to Linköping.

A special thanks goes to my partner, who has encouraged me to keep up the good work, even when it hasn’t been so good, and cheered me up after the days I’ve felt extra heavy. He has continuously offered to help in any way he can, even at times when he himself has been so stressed that he cannot think straight. Although not accepting my proposal of writing this thesis for me, he has provided honest and insightful feedback on my work whenever I have asked for it. You’re the best!

Finally, I would like to thank my friends and family who have encouraged, inspired and supported me throughout my studies, giving me lots of valuable memories over the years filled with happiness and pride.

(5)

List of Figures

2.1 Illustration of the OSI model layers. . . 7

2.2 CAN bus setup. . . 8

2.3 Voltage states of a CAN bus. . . 8

2.4 CAN frame format. . . 9

2.5 Simple Ethernet network using a single UTP wire. . . 10

2.6 Data processed in three steps according to the 100BASE-T1 specification. . . 10

2.7 Standard Ethernet frame format. . . 11

2.8 Transition times and approximate power consumption of different states in EEE. . 13

3.1 Typical network architecture of a modern vehicle. . . 16

3.2 Hierarchical domain-based architecture using an Ethernet backbone, derived from [35]. . . 17

5.1 Physical setup of CAN bus . . . 25

5.2 Physical setup of Ethernet bus . . . 25

5.3 Illustration of the amount of messages sent every second in test case A (upper) and B (lower). . . 26

5.4 Current measurements from test A for CAN. . . 28

5.5 Current measurements from test A for Ethernet. . . 29

5.6 Current measurements from test B for CAN. . . 30

5.7 Current measurements from test B for Ethernet. . . 30

6.1 State transition diagram for the EEE model. . . 33

6.2 Result from utilisation test of 10 Gbit/s EEE. . . 34

6.3 Result from utilisation test of 100BASE-TX, with and without energy saving states. 35 6.4 Focus on the first 10 seconds of the result from test case A of 100BASE-TX EEE. . . 36

6.5 Focus on the first 10 seconds of the result from test case B of 100BASE-TX EEE. . . 36

6.6 Cycle phases of the TSN model. . . 38

6.7 First six cycles from a simulation of standard TSN (no EEE). . . 40

6.8 First six cycles from a simulation of TSN with EEE. . . 40

A.1 Full simulation result from test case A of 100BASE-TX EEE. . . 53

A.2 Full simulation result from test case B of 100BASE-TX EEE. . . 54

B.1 Three full iterations of the simulation of standard TSN (no EEE). . . 56

(8)

List of Tables

2.1 Standards established by the TSN task group. . . 12

3.1 Classifications of in-vehicle networks . . . 15

5.1 Component specifications for physical bus assembly. . . 24

5.2 Sample of extracted data from the OBD-II port of a Volvo V60. . . 27

5.3 Sample of simplified data used for testing. . . 28

6.1 Parameters used for simulation of 100BASE-TX EEE . . . 33

(9)

1 Introduction

As society becomes more aware of environmental issues and global warming, an ever rel-evant topic of the 21stcentury is environmental protection. According to data collected by United Nations Framework Convention on Climate Change (UNFCCC) in 2016, almost 30 % of the greenhouse gas emissions within the EU came from the transport sector, of which road transport constituted 72 % [1]. On a global scale, road transport represented 23 % of the CO2

emissions in 2010 [2]. An important component against further pollution is more viable vehi-cle technology. This has not gone unnoticed by consumers, leading to a growth in the market for electric vehicles (EVs) over the years [3]. Other than the apparent environmental benefits, EVs are also reported to be a more economical option compared to conventional, fuel-driven vehicles, further encouraging people to make the transition to an electric alternative [4]. However, the electric automotive industry is facing two major problems affecting user con-venience. First, the range limitation, referring to the distance that can be travelled on a single charge; and second, battery charging, where both long refuelling times and access to charg-ing stations come into play. To give an idea of these numbers, consider the specifications of a Nissan Leaf, the most popular electric vehicle in Sweden at the time of writing [5]. According to the Electrical Vehicle Database [6], a Nissan Leaf has a range of 230 km, with an energy consumption of 16.5 kWh per 100 km. To recharge an empty battery, seven hours of charge time is required, or in the case of fast charging, 40 mins can offer up to 80 % of battery ca-pacity. Compared to conventional vehicles, the refuelling time has drastically increased, in combination with a significant cutback in range. These concerns, together with the percep-tions of high cost, are making consumers feel apprehensive about purchasing EVs [7], thus making manufacturers hesitant toward investing in them. The fear of becoming stranded in a limited range vehicle has become known as range anxiety and is often associated with de-laying the advancement of EVs. Several strategies exist to counter range anxiety including providing information on areas that are reachable with the current charge, showing which charging stations are available and improving the vehicle’s ability to fast charge [8]. From these concerns it can be derived that a crucial step towards changing consumers’ attitude is to improve the range of EVs, and one way it could be achieved is by reducing the battery load. If successful, more people may be willing to switch to EVs, which could lead to a decrease in CO2emissions created by personal vehicles.

(10)

1.1. Problem Description

In modern EVs there are between 70–100 so called Electronic Control Units (ECUs); devices used to control various electrical systems and transmissions and to improve road safety (in-cluding components such as airbags, anti-lock breaking systems, etc). These ECUs constitute a large interconnected network that enables essential communication between different sub-systems e.g. feedback from sensors, or instructions to perform different controls, such as engine control. As the number of ECUs keep growing, the complexity of connecting net-works also increases, providing challenges to further development of EVs [9]. In addition, the wiring today constitutes the third heaviest and third most costly component of a vehicle [10].

In order to meet the requirements on reliability, transmission rate and cost, architects must choose what type of network to use based on the needs of a specific subsystem of the ve-hicle. These networks consist of a number of different protocols, the most common being Local Interconnect Network (LIN), Controller Area Network (CAN) and FlexRay, as well as the more recent Media-Oriented System Transport (MOST) and in some cases, although still uncommon, Ethernet. [11]

1.1 Problem Description

As vehicles consist of an increasing number of electrical and automated components, a large amount of communication is required between the vehicle’s many ECUs. The conventional architecture of this communication network, such as the one described in Chapter 3, is becom-ing outdated, slowly reachbecom-ing its limit trybecom-ing to support the intensified demand for higher bandwidth. This means new solutions must be presented that can satisfy the upcoming needs for hard real-time, reliable communication. The architecture of a network will not only affect the bandwidth, but also have implications on the energy consumption, depending on the communication protocol and setup in use.

By changing the in-vehicle communication network to a solution providing higher band-width, there is a risk of significantly increasing the amount of power required, potentially decreasing the vehicle range further. In order avoid hindering the progress in development of EVs, it is vital to understand the effects regarding battery load that changing the commu-nications protocols could cause. Therefore, learning more about the protocols and how they can be utilised efficiently is important.

In this thesis, the energy consumption of two communication protocols are examined in an at-tempt to determine whether is it possible to meet the demands for higher bandwidth without causing a substantial increase in power consumption or violating any constraints. Although several works have proposed beneficial solutions in terms of bandwidth and latency (see Section 3.3), little consideration has been taken to the energy impact such a change could in-cur. By reviewing the protocols, the energy consumption can be derived and the effects and possible solutions discussed.

The protocols under inspection are high-speed CAN (ISO 15765-2 over ISO 11898) and Eth-ernet (Time-Sensitive Networking (TSN) using 100BASE-T1/TX) where the first is widely used in vehicles today and Ethernet is used only sparsely. In addition to standard Ether-net, Energy-Efficient Ethernet (EEE) (IEEE 802.3az using 100BASE-TX) is also considered, which, to the author’s knowledge, is not yet in use in vehicles. Through analytical evalua-tion, physical measurement and simulaevalua-tion, these protocols are examined and assessed on energy consumption, bandwidth and delays.

(11)

1.2. Aim

1.2 Aim

The aim of this thesis is to determine how the energy consumption in electrical vehicles is affected by the choice of in-vehicles communication protocols. By comparing CAN, a pro-tocol commonly used by the automotive industry, to Ethernet, often suggested as the suc-cessor of CAN, an evaluation of the energy consumption for a two-node network can be performed. In addition, EEE is included in an attempt to determine the possibility of exploit-ing the speed provided by Ethernet without drastically increasexploit-ing the energy consumption. TSN offers time- and bandwidth-scheduling features to Ethernet, allowing for several traf-fic classes within the same network. By looking at related works, this thesis provides some insight into how this scheduling could be configured, as well as how EEE can be integrated into certain phases of the scheduling cycle.

In short, the thesis strives to address the following two research questions:

1. What is the difference in energy consumption between CAN, Ethernet and Energy-Efficient Ethernet when passing messages over a network with two nodes?

Both theoretical and physical comparisons of the energy consumption of CAN and Eth-ernet are presented, revealing not only the difference in consumption but also whether the analytical and measured results coincide. In addition, a simulation model of EEE is implemented, presenting the benefits and drawbacks of introducing energy-saving states to Ethernet.

2. To what extent can Energy-Efficient Ethernet be exploited for in-vehicle communication without violating constraints set by real-time applications?

In order to explore how systems with real-time traffic can utilise EEE, a simulation model using the time-scheduling feature of TSN is implemented, allowing for simu-lations with, as well as without, the use of EEE.

In completing this study and revealing the characteristics of CAN, Ethernet and EEE, it may aid architects in designing the internal communication network of future EVs. This could lead to improved bandwidth without the need to sacrifice vehicle range.

1.3 Delimitations

In this thesis, the protocols under inspection are high-speed CAN (CAN V2.0B over ISO 11898), Ethernet (TSN over 100BASE-T1/TX) and EEE (IEEE 802.3az using 100BASE-TX). For the physical implementation, TSN is replaced with UDP/IP, due to availability restrictions of components and compatible software. Although the implementation uses UDP/IP instead of TSN, the energy requirements are thought to be similar and provide sufficient accuracy to meet the expectations of this thesis. In this thesis, the term Ethernet and automotive Ethernet are used interchangeably. Unless otherwise stated, the term refers to TSN over 100BASE-T1/TX.

Realistic test cases are constructed by using real data from a vehicle, obtained during a driv-ing session. In order to avoid dismantldriv-ing a car, this data is acquired via the On-Board Diag-nostics (OBD-II) port. Through this port, access to a high-speed CAN bus is gained, which serves as a backbone to the networking architecture. This data is not sufficient to simulate the communication within a sub-network or specific domain, as only the data passed between sub-networks is available. However, as this thesis does not focus on specific sub-networks or domains, replicating the traffic sent over the backbone is considered adequate.

(12)

1.4. Approach

Throughout the paper, when talking about EVs, the vehicles referred to are pure battery elec-tric, meaning the drive train is provided with battery power only. The vehicles of concern are modern-day, 21stcentury passenger cars, and do not refer to luxury designs.

1.4 Approach

This section presents an overview of the approach taken to answer the research questions stated in the previous section. Further details on the method pertaining to each part can be found in Chapters 4, 5 and 6.

1.4.1 Theoretical Analysis

In order to understand and answer research question one, a good starting point is looking at the specifications of standards. Different communication protocols will add a varying num-ber of overhead bits as padding to the message being transferred. This can be referred to as transmission efficiency, calculated according to Equation (1.1). The total number of bits include the number of information bits as well as addressing, error checking and any other overhead that exist according to the standards. The result reveals what percentage of the transmission rate that is available for actual data.

Transmission efficiency= Number of information bits

Total number of transmission bitsˆ100 (1.1) Further, by referencing data sheets of different components pertaining to the same standard and estimating an average, the power required during active message passing as well as when the bus is idle is estimated.

1.4.2 Physical Implementation

In addition to the theoretical analysis, a physical network is set up for CAN and Ethernet, allowing for power usage during active and idle states to be measured, as well as the amount of energy consumed when sending a specific set of messages. The small networks consist of two nodes, one transmitter and one receiver, each composed of a microcontroller and a networking interface pertaining to each specific protocol. By measuring the current of the networking interfaces, the known operating voltage can be used to calculate the power and energy consumption during different test scenarios.

1.4.3 Simulation

In order to provide some insight into what energy savings and packet delays EEE could con-tribute to the automotive industry, a simulation model of EEE is implemented and tested using the same scenarios as for the physical implementation. In addition, a model is con-structed to help with understanding the effects TSN could have on a heterogeneous network, as well as explore how well EEE can be integrated with the TSN protocols.

1.5 Thesis Structure

The rest of this thesis is structured as follows: First, relevant theory regarding the protocols is presented (2), including the OSI-model of protocol layers. Second, a model of the in-vehicle communication network is introduced (3), allowing the reader to gain some background to the subject area, as well as introducing related works. Chapter 4 consists of a theoretical analysis, calculating the transmission efficiency and theoretical power consumption of CAN and Ethernet. This is followed by a chapter on the physical implementation (5), starting with the setup, then describing the test cases before concluding with the results from testing.

(13)

1.5. Thesis Structure

Chapter 6 presents the models used for simulation of EEE and TSN, as well as results from testing. The 7thchapter provides a discussion of theoretical, physical and simulation methods and results, as well as a comparison between the protocols. Lastly, the thesis rounds off with a conclusion (8) of the presented work and discusses future work to be carried out within the subject area.

(14)

2 Theory

This chapter introduces theory necessary to understand the content of this thesis, starting with the OSI model in order to better understand the presentation of CAN and Ethernet. The protocols are introduced with some background to the standard, before moving into characteristics and frame formats.

2.1 The OSI Model

The Open Systems Interconnection (OSI) model serves as a theoretical representation of com-munication over an open network. It was established in the 1980’s by the International Orga-nization for Standardization (ISO), who saw a need for a standardised specification of open computer-to-computer communication. Today, the model is used to study and develop net-work communication schemes. The model consists of seven layers, described in the next section, where each layer offers services according to a specific protocol. These protocols set up the communication rules, as well as interacts with other protocols in adjacent layers of the model. As the OSI model is a generalisation, there may be implementations where all layers are not required, or where a specific protocol is represented by several layers. [12]

Figure 2.1 provides an overview of the different layers of the OSI model. Below they are presented in more detail, starting with the lowest level [12] [13]:

1. Physical layer – Generates signalling over the physical transmission medium, which can be copper wire (as voltage levels), fibre optics (as light pulses) or wireless through the air (using electromagnetic waves). Detects and accepts signals, passing them on to the Data Link layer.

2. Data Link layer – Divides data into appropriate frames in preparation for physical transmission. Each frame includes the raw data, the sender’s and receiver’s identi-fiers, and information for error checking and control. Detects errors that have occurred at the physical level.

(15)

2.2. Controller Area Network

Figure 2.1: Illustration of the OSI model layers.

3. Network layer – Translates network addresses into their physical identifiers, and de-termines the route based on priority, network congestion, quality of service parameters and routing costs.

4. Transport layer – Manages end-to-end delivery of data by ensuring reliable and error-free transmission. Handles flow control, i.e. estimates the transmission rate based on the recipient’s ability to accept data. Distincts between connection oriented protocols, using acknowledgement and checksums; and connectionless protocols, which has no error detection.

5. Session layer – Maintains and coordinates communication between nodes on the net-work. Keeps the session alive by synchronising transmission and determining whether a connection link needs to be terminated or restarted; as well as secure, monitoring the session participants to ensure only authorised nodes have access.

6. Presentation layer – Performs formatting, encryption and compression of data, allow-ing for distinct applications to be used by the nodes in the network. Works as a transla-tor, providing syntax independence at application level.

7. Application layer – Provides an interface between software applications and the net-work services. Interprets the requests and requirements of an application, determining an acceptable quality of service.

2.2 Controller Area Network

The Controller Area Network (CAN) protocol was introduced during the 1980’s to meet the need for new functionality in communication between a vehicle’s ECUs. Within Europe’s automotive industry, the protocol has become a de facto standard because of its robustness, bounded communication delays and low cost [14]. CAN is a serial bus, meaning one node can transfer data at a time while all others listen. The protocol corresponds to the two low-est levels of the OSI model. Collisions are handled through Carrier Sense, Multiple Access with Collision Avoidance and Arbitration on Message Priority (CSMA/CA+AMP), where the idea is to avoid collisions, rather than detect them, by listening to the bus for activity.

(16)

Colli-2.2. Controller Area Network

sions that do arise are resolved by bit-wise arbitration, where the highest priority identifier succeeds in transmitting while others must make another attempt [15].

Standard CAN has the capacity to transfer up to 1 Mbit/s, depending on the bus length and number of nodes. However, in the automotive industry it is common to differentiate between high speed and low speed CAN. The former is commonly used at a transmission rate of at most 500 kbit/s, whereas the latter has a maximum of 125 kbit/s [16].

2.2.1 CAN Characteristics

In order to achieve a transfer rate of 1 Mbit/s, it is assumed the bus consists of a 40 m twisted-pair cable (shielded or unshielded) with a characteristic impedance of 120Ω. It can support at most 30 nodes, where each node is connected via a stub cable with a maximum length of 0.3 m. The bus is terminated using a 120Ω resistor at each end. As can be seen in Figure 2.2, each CAN node incorporates a controller which manages message filtering and framing, error detection and handling, and arbitration. The controller is linked to the physical medium through a transceiver, represented by the physical layer of the OSI model. The transceiver is connected to two wires, CANH and CANL. In the recessive state (logical 1), both wires reside at ~2.5 V, while in dominant state (logical 0), CANH is driven to ~3.5 V and CANL to ~1.5 V, creating a signal with 2 V difference. An illustration of these states can be found in Figure 2.3. [15] [17]

Figure 2.2: CAN bus setup.

Figure 2.3: Voltage states of a CAN bus.

2.2.2 Frame Format of CAN

The CAN message format can be seen in Figure 2.4. A short description of each field follows [15]:

(17)

2.3. Automotive Ethernet

• Identifier (11 bits) – Determines the priority of the message.

• RTR (1 bit) – Remote Transmission Request. Determines whether information is re-quired from another node.

• IDE (1 bit) – Identifier Extension. Classification of the identifier, differentiating between standard or extended.

• r0 (1 bit) – Reserved for possible future use.

• DLC (4 bits) – Data Length Code. The number of bytes of data being transferred. • Data (8–64 bits) – The data to be transmitted. A maximum of 8 bytes (64 bits) allowed. • CRC (16 bits) – Cyclic Redundancy Check. The checksum of the data to be transmitted.

Used for error detection.

• ACK (2 bits) – Acknowledgement. Used for error detection and to ensure preserved data integrity.

• EOF (7 bits) – End Of Frame. Marks the end of a message and determines whether a bitstuffing error has occured.

• IFS (7 bits1_{) – Interframe Space. An intermission to separate the preceding frame from}

the next activity on the bus.

Figure 2.4: CAN frame format.

The format described above applies to the Standard CAN protocol. In Extended CAN, the identifier consists of 29 bits and has some additional fields, listed below [15]:

• SRR (1 bit) – Substitute Remote Request. Replaces RTR of the standard format as a placeholder.

• IDE (1 bit) – Identifier Extension. A recessive bit indicates that more identifier bits will follow.

• r1 (1 bit) – Additional reserved bit for possible future use.

2.3 Automotive Ethernet

Although Ethernet has been used for many years in commercial and industrial applications, it has only recently started being used in the automotive industry. The IEEE 802.3bw stan-dard, also known as 100BASE-T1, was released in 2015. It corresponds to the physical layer of the OSI model and is often referred to as the 100 Mbit/s automotive Ethernet [18]. The motivation behind developing this new protocol has not only been the increased demand for high bandwidth, but also a need for lightweight and cost-effective wiring. The protocol of-fers full-duplex over a single twisted-pair cable, allowing for transmission in both directions simultaneously over the same pair and thus, no collisions will occur [19].

(18)

Perhaps more common in the automotive industry today is 100BASE-TX, as many vehicles use this Ethernet standard for diagnostics and software updates. However, it does not meet the constraints regarding electromagnetic interference and therefore cannot be integrated fur-ther into the in-vehicle communication network. In addition, the 100BASE-TX requires two twisted-pair cables, meaning twice the weight of its -T1 counterpart. [18]

The next level of the OSI model is represented by a Media Access Controller (MAC). It is here, at the data link layer, that the IEEE 802 management protocols come in [20]. The features of Time-Sensitive Networking (TSN) and Audio/Video Bridging (AVB) are presented in Section 2.3.3.

2.3.1 Ethernet Characteristics

The 100BASE-T1 standard supports transmission rates of up to 100 Mbit/s over a single un-shielded twisted-pair wire of at most 15 m, possessing a characteristic impedance of around 100Ω [21]. Each node consists of a transceiver (PHY), a MAC and some application, illus-trated in Figure 2.5 as a microcontroller. Before transmission, the data is processed in several steps: using (i) 4-bit to 3-bit encoding (4B3B); (ii) 3-bit to 2-ternary pair encoding (3B2T); and (iii) three-level pulse amplitude modulation (PAM3) encoding onto the physical medium, which transmits data over the cable using three voltage levels: +1 V, 0 V, and -1 V.Figure 2.6 shows an example of how the data is represented before and after each processing step. [18]

Figure 2.5: Simple Ethernet network using a single UTP wire.

(19)

2.3.2 Frame Format of Ethernet

The standard Ethernet IEEE 802.3 frame is comprised as seen in Figure 2.7. Each field is described below [22]:

• PRE (7 bytes) – Preamble. Synchronises the physical layer.

• SFD (1 byte) – Start of Frame Delimiter. Signals the start of a transmission. • DST (6 bytes) – Destination address.

• SRC (6 bytes) – Source address.

• LEN/Type (2 bytes) – Specifies message length or protocol type.

• Data (46–1500 bytes) – The data to be transmitted, including padding from higher lay-ers. If the data consists of less than 46 bytes, padding of up to this minimum will be added. A maximum of 1500 bytes allowed.

• FCS (4 bytes) – Frame Check Sequence. A cyclic redundancy check used to validate the received data.

• IPG (12 bytes) – Interpacket Gap. An interlude used to separate two succeeding frames.

Figure 2.7: Standard Ethernet frame format.

The PRE and SFD fields are added at physical level of the OSI model. The MAC header (DST, SRC and LEN/TYP) as well as the FCS field are added at the data link layer. At higher layers, additional padding may have been added to the data, resulting in the data field mentioned above. In the physical implementation of this thesis, UDP (User Datagram Protocol) and IP (Internet Protocol) are used for the Ethernet network, functioning at the transport and network layers of the OSI model. The UDP header consists of eight bytes, while the IP header requires 20 bytes [23], meaning each packet can contain at most 1472 bytes of data.

Looking instead at TSN, a 802.1Q tag (also called a VLAN tag) is added, consisting of four bytes and precedes the Type field mentioned above. The data field in turn consists of a header of at least 12 bytes, where more padding may be required depending on the formats for streamed data, control messages, time-synchronous messages etc. [24].

2.3.3 Time-Sensitive Networking

The IEEE 802.1 TSN task group (previously called the AVB Task Group) has defined a number of augmentations of Ethernet, rendering AVB Ethernet suitable not only for use in infotain-ment applications, but also other vehicular systems pertaining to driver assistance (DAS) and body control [25]. Further extension of AVB has resulted in TSN, enhancing the real-time capabilities by providing improved timing guarantees, scalability and reliability. Such devel-opment has made automotive Ethernet using TSN a state-of-the-art option for DAS networks [26]. AVB and TSN consists of a set of standards [27], presented in Table 2.1.

(20)

2.4. Energy-Efficient Ethernet

Table 2.1: Standards established by the TSN task group. TSN standards

IEEE standard Features

802.1Qbu Frame preemption

802.1Qbv Scheduled traffic enhancements 802.1Qca Path control and reservation 802.1Qch Cyclic queuing and forwarding 802.1Qci Filtering and policing

802.1CB Frame replication and elimination for reliability 802.1CM TSN for Fronthaul

802.1Qcc Stream Reservation Rrotocol (SRP) enhancements and performance improvements 802.1cp YANG model for bridging

AVB standards

IEEE standard Features

802.1AS Timing and synchronisation 802.1Qat Stream Reservation Protocol (SRP) 802.1Qav Forwarding and queuing enhancements 802.1BA Audio Video Bridging (AVB) Systems

The TSN extensions to Ethernet allow the protocol to handle multiple traffic classes, which can be a mixture of real-time traffic with strict timing constraints as well as nonreal-time, best-effort traffic without the need for any timing guarantees. Each class is linked to a prior-ity level, which can be used to ensure that low priorprior-ity traffic does not block higher priorprior-ity transmissions. Different queues are used to separate the traffic classes, and by sharing a com-mon understanding of time throughout the network, a schedule can be determined, allowing for time and/or bandwidth reservations for the different traffic types [28]. This schedule is customisable and decides at what points in time specific traffic classes are allowed to be trans-mitted. In addition, frame preemption can be used to break up longer low-priority packets into several fragments, avoiding it from blocking transmission of packets with higher priority levels [29]. An example of how this can be implemented is presented in Section 6.3, where three different traffic classes are used and scheduled.

2.4 Energy-Efficient Ethernet

For Ethernet networks with a bandwidth of 100 Mbit/s or higher, the transmitting nodes are always active. Even when there are no messages to be sent, the nodes transmit an IDLE signal to maintain alignment between transmitters and receivers. As the network grows, this leads to large amounts of energy being consumed. In order to preserve energy, an addition to Ethernet has been developed, allowing the network to enter a low-power state when not transmitting or receiving data. This augmentation has become known as Energy-Efficient Ethernet (EEE) and enables the possibility of achieving great energy savings for networks with low utilisation. [30]

To describe the states and transitions of EEE, assume a transmitting node starts in the active state. While there are packets available for transmission, the node will remain active, con-suming full power. But when there are no more messages waiting to be sent, the node will enter a low power idle (LPI) mode, which only requires 10 % of peak energy consumption [30]. However, in order to transition from the active state to the low-power state, the node must first transmit a sleep signal for Ts seconds, notifying other nodes in the network that

there are no more transmissions at this time. Once in LPI, the node will wake up to send a re-fresh signal every Tqseconds, ensuring the alignment between sending and receiving nodes.

(21)

2.4. Energy-Efficient Ethernet

The duration of the refresh signal is very short in comparison to the quiet time between trans-missions, and lasts for Trseconds. As soon as a packet arrives, the transmitter leaves LPI to

re-enter active mode, requiring a wake up time of Tw seconds. During this period, a signal

is sent to the other nodes to notify of coming network activity [31]. According to Graf, Glaß and Teich [32], the sleep transition state requires approximately 60 % of maximum power, while waking the node up requires less than 30 %. On the other hand, Christensen et al. [30] assume both transitional states require somewhere between 50–100 % power, depending on the implementation. Figure 2.8 shows an illustration of the transition times, as well as an approximation of the amount of power consumed in each state.

Figure 2.8: Transition times and approximate power consumption of different states in EEE.

The benefits of saving energy when using EEE come at the cost of introduced delays, caused by the system transitioning between states. As a worst case, a packet arrives just as the transmitting node leaves the active state, at which point the sleep transition is aborted and an additional static delay (approx. 30 µs according to Graf et al. [32]) is required before the system can proceed to wake up. The duration of the transition times depend on the PHY used and is specified in the IEEE 802.3az EEE standard [31].

In Section 6.1, a simplified simulation model of EEE is presented in detail. Table 6.1 presents the transition times derived for a 100BASE-TX PHY.

(22)

3 In-Vehicle Communication

Model

This section presents a model of the in-vehicle communication architecture utilised by the automotive industry today. In doing so, a better understanding of the constraints on different domains can be achieved, which is required in order to draw any conclusions regarding the types of networks that can be used in different subsystems.

3.1 Current Architecture

The network for in-vehicle communication can be divided into the following domains [14]: • Powertrain domain – Controls the engine and transmission. Scheduling of

communi-cation tasks must meet strict time constraints and provide frequent transmission with other domains. High bandwidth of around at least 1 Mbit/s as well as low latency is required.

• Chassis domain – Controls components related to braking, steering and external driv-ing conditions. Requirements on communication are similar to that of the powertrain domain but even higher reliability is necessary due to the safety critical elements of this domain.

• Body domain – In charge of less pressing functions such as window wipers, lights and climate control. For many nodes in this domain, less bandwidth and longer delays are acceptable.

• Active and passive safety domain – Handles occupant safety systems such as airbag deployment, rollover sensors and collision avoidance systems. The amount of band-width required in this domain keeps increasing as vehicles become more automated, thus adding more and more sensors and cameras whose data needs to be collected and processed. Due to the real-time constraints of this domain, low latency is required. • Telematics, multimedia and human-machine interface (HMI) domains – Controls the

so called infotainment systems: components linked to information (navigation sys-tems, wireless communication and vehicle statistics) and entertainment (audio/video

(23)

3.2. Architectural Limitations

and displays). Communication must support multimedia data streams, requiring high bandwidth and time synchronisation, however some latency is acceptable.

The networks used for in-vehicle communication are commonly categorised into four classes. These are presented in Table 3.1 together with bandwidth requirements, common applica-tions and regularly used protocols [11][33]. Figure 3.1 presents a simplified model of a typical in-vehicle network architecture with domains, ECUs and common protocols. Each box in the figure represents a node, or a collection of nodes with similar functionality, in the network. The different domains are highlighted using a coloured area around the involved nodes, with the domain names stated in italics. In this model, the FlexRay protocol (illustrated as a green double line) is used as a backbone, tying the different domains together and allowing for communication between them.

Table 3.1: Classifications of in-vehicle networks

Class Bandwidth Usage Protocol

A <10 kb/s Convenience functions found in low

end body domain LIN

B 10 – 125 kb/s

General information sharing of non-critical and non-diagnostic body do-main

Low-speed CAN

C 125 kb/s – 1 Mb/s Real-time critical functions in

power-train, chassis and safety domains High-speed CAN

D >1 Mb/s

Hard real-time & reliable parameters of powertrain, chassis and safety do-mains

FlexRay Multimedia streaming of infotainment

domain MOST & Ethernet

3.2 Architectural Limitations

As vehicles consist of more and more electronic components, the demand for higher band-width increases drastically. The described model uses different networks in the various do-mains, constituting inflexible combinations of protocols and topologies [34]. As stated by Chakraborty et al., the current architecture is becoming a barrier to innovation, expressing a need for redesign [9]. This has lead to several years of research trying to find a better solution to the communication problem, and many works suggest Ethernet as the way forward. In the next section, an overview of several such works is presented.

3.3 Next Generation In-Vehicle Networking

In 2012, Chakraborty et al. [9] described the growing expectations regarding network perfor-mance of in-vehicle communication. The authors argued that it was becoming increasingly difficult to motivate the choice of CAN due to the accelerated bandwidth demand. Instead, Chakraborty et al. suggested Ethernet as a possible replacement candidate, due to its ability to handle much larger amounts of data.

Touhy et al. [34] performed a review of in-vehicle networks, presenting Ethernet as the future solution to a more interoperable network architecture. They disclosed the inadequacy of de-fault Ethernet configurations, such as TCP/IP, describing its failure to support deterministic and real-time functionality. Two alternatives were instead proposed as being viable solutions for use in automotive networks: Audio/Video Bridging (AVB) Ethernet and Time-Triggered

(24)

3.3. Next Generation In-Vehicle Networking

Figure 3.1: Typical network architecture of a modern vehicle.

Ethernet (TTEthernet). Although producing similar results in regard to performance, Touhy et al. suggested AVB as the better option due to its benefits in handling multimedia. The authors presented advantages gained from a implementing an Ethernet-based solution, in-cluding bandwidth, implementation flexibility and its ability to operate using 100 Mbit/s full-duplex unshielded twisted-pair (UTP) cables. Touhy et al. envisioned the automotive industry’s initial adoption of Ethernet as a high-speed backbone of inter-domain communi-cation, before the full commitment of an end-to-end Ethernet solution.

A similar solution, implementing a top-down approach using master controllers in each do-main and allowing for inter-dodo-main communication via an Ethernet backbone, was also pre-sented by Hank et al. [35]. Figure 3.2 shows an illustration of their domain-based architecture. This type of architecture is assumed to provide more flexibility and lower complexity, while offering high-speed data transfer over inexpensive, lightweight cable.

(25)

Figure 3.2: Hierarchical domain-based architecture using an Ethernet backbone, derived from [35].

In a more recent study from 2018, Bello et al. [36] presented the challenges and trends of in-vehicle embedded systems and network architectures that the automotive industry must face, further developing the idea of a domain-based architecture. They suggest that although AVB has been considered suitable for several in-vehicle applications due to its low latency streaming, timing and synchronisation traits, it cannot meet the requirements on transferring small, time-sensitive packets according to time schedule. Thus, it is rendered unfit as back-bone. Bello et al. instead proposed a Time Sensitive Networking (TSN) enabled Ethernet as backbone in the next generation of autonomous vehicles.

So what exactly is Automotive Ethernet? The term is used for several different standards of Ethernet, but most common for the physical level are 100BASE-TX (100 Mbit/s over two twisted pairs) and 100BASE-T1 (100 Mbit/s over a single twisted pair), where the latter is also known as BroadR-Reach [18]. For higher levels, mentions of TCP/IP and UDP/IP oc-cur, but in order to meet real-time requirements and minimise latency of a switched network, Time-Triggered (TTEthernet), Audio/Video Bridging (AVB), and Time Sensitive Networking (TSN) offer more promising features [36]. TSN is a continuation of AVB, offering an even lower latency, more reliable data transmission, as well as a scalability which comes with in-troduced message classes [26]. In this thesis, automotive Ethernet is used to denote TSN using 100BASE-T1 or 100BASE-TX at the physical level.

3.3.1 Energy Implications of an Ethernet-Based Architecture

So far, the benefits of switching to an Ethernet-based architecture have been presented, of-fering the flexibility, scalability and bandwidth that is missing from the model in Section 3.1. However, not much concern has been taken to possible implications, other than the ability to support real-time requirements, that such a solution might incur. This section focuses on the energy aspect, presenting research that explores how communication protocols can affect the energy consumption of different systems.

Major improvements can be gained from modifying existing protocols by introducing differ-ent modes. A well-known example is the adaption of Ethernet known as Energy-Efficidiffer-ent Ethernet (EEE), described by Christensen et al. [30]. A low power mode is introduced which only requires 10 % of the power consumed in active mode. This approach does however lead to compromises in performance, in terms of delays for transitioning between modes. Chris-tensen et al. suggest packet coalescing, i.e. collecting all incoming packets over a set amount

(26)

of time before transmitting them, in order to maximise the savings of EEE without having too great an impact on performance.

As another example of modifying protocols to preserve energy, Bolla et al. [37] mapped the energy consumption when sending or receiving data over a TCP connection. Their work showed that the energy consumption varied widely between the send and receive mode and depending on which function was in use. They proposed methods with the potential of saving energy in the magnitude of up to 90 % in receiver mode and up to 11 % in sender mode.

An aspect of introducing power-saving modes that need be considered is the delay that is added before the system is ready to transmit an incoming packet. Tramarin and Vitturi [38] discuss how EEE can be integrated in networks with hard real-time constraints, presenting both the issue and a proposed solution using the same scheduling strategy as TSN. This solution is presented further in Section 6.3.

In a paper from 2011, Balbierer et al. [39] compare the power consumption of Ethernet and EEE to CAN, FlexRay and Media-Oriented Systems Transport (MOST). They conclude that Ethernet is not a good alternative for neither CAN nor FlexRay in terms of power consump-tion. EEE requires similar amounts of power as FlexRay, but consumes 2.5 times more than CAN. In comparison to MOST, both Ethernet and EEE are apt substitutions. However, what the authors have not taken into consideration is that the Ethernet and EEE networks would not be utilised in the same way as the networks they compare them to. As an example, using Ethernet to send CAN traffic is highly inefficient due to a small packet size and low transmis-sion rate. Although this thesis uses a similar approach to Balbierer et al. by sending the same data over CAN and Ethernet, it has been acknowledged as an issue and a discussion is held in Section 7.5.

This thesis builds upon the insights and ideas proposed in these works, allowing for further examination of the energy consumption in CAN, Ethernet and EEE. They provide justifica-tion to the methods used for theoretical analysis of the three protocols, as well as support in implementing and verifying the simulation models of EEE and TSN. The works mentioned indicate that there is relevancy in comparing energy consumption between protocols and provide further motivation on the importance of managing energy-saving states in a good way.

(27)

4 Theoretical Analysis

In this chapter a theoretical analysis is performed, revealing the transmission efficiency and expected power consumption for CAN and Ethernet. The values disclosed in this section are based on the theory from Chapter 2, as well as looking into the specifications of different components and deriving a feasible interval of power consumption for networking interfaces of these standards.

4.1 Transmission Efficiency

The transmission efficiency is based on the theory presented in sections 2.2.2 and 2.3.2 re-garding the frame formats of CAN and Ethernet. It is expressed as a percentage of bits in the frame or packet that contain actual data, in accordance to Equation (1.1).

Transmission efficiency= Number of information bits

Total number of transmission bitsˆ100 (1.1) Starting with CAN, using the standard 11 bit identifier and 7 bit interframe space, each frame contains a total of 115 bits, 64 of which contain actual data. According to Equation 1.1, this results in a transmission efficiency of approximately 56 %.

Moving on to Ethernet, when using TSN, a four byte VLAN tag as well as a 12 byte data header is added, meaning a maximum of 1488 bits are available for actual data. Assuming a 12 byte interpacket gap, each packet consists of 1542 bits in total. Put into Equation 1.1, the transmission efficiency is calculated to be approximately 96 %.

At a first glance, Ethernet may look like it is at a great advantage, surpassing the transmission efficiency of CAN by 40 %. However, this is highly dependent on the amount of data actually included in the packet. Looking at the frame formats, although Ethernet has the potential to send many times more data than CAN with each message, the overhead introduced by headers and footers are also significantly larger. This means that for small amounts of data, Ethernet could be very inefficient. To achieve comparable results to CAN, at least 64 bytes of data is required, which corresponds to a transmission efficiency of 54 %.

(28)

4.2. Theoretical Power Consumption

4.2 Theoretical Power Consumption

In this section, equations on how to calculate the theoretical power consumption in active and idle states are presented. By referencing specifications (data sheets) of transceivers and con-trollers pertaining to the standards under inspection, an interval of plausible power values are established. In addition, the expected power consumption of the particular components used in physical implementation are given. The components in use are presented in more detail in Table 5.1 of the next chapter.

4.2.1 Expected CAN Power Values

With CAN, each networking interface consists of a transceiver (PHY) and a controller (CTL), where the controller is assumed to require constant power (PCTL) regardless of state. The

transceiver, however, consumes more when transmitting (PPHY_active) than when receiving,

which is equal to being idle (PPHY_idle) [39]. The data sheets of different components reveal

the power usage during the two modes: recessive (Prec) and dominant (Pdom).

When the transmitter is idle or receiving data, it remains in its recessive state. Thus, PPHY_idle

is given directly by Prec, as expressed in Equation 4.1.

PPHY_idle=Prec (4.1)

Deciding the value of PPHY_activeis done by observing the known bit settings of a standard

CAN frame (see 2.2.2). The SOF, RTR, IDE and r0 bits are set to logical 0 (dominant), whereas the last bit of CRC as well as the ACK, EOF and IFS bits are logical 1 (recessive) [17]. In a frame containing 8 bytes of data and assuming a seven bit IFS, this results in four bits that are always 0, 17 bits that are always 1, and the remaining 94 bits are equally as likely to consist of 0 or 1. Given this information, the averaged power consumption of a transceiver in active transmission is given by the following equation:

PPHY_active= 64 ¨ Prec

+51 ¨ Pdom

115 (4.2)

As the power consumption of a sending node depends on the utilisation, i.e. how much time is spent in idle or active state, an expression can now be determined given Equations 4.1 and 4.2. Although CAN supports a transfer rate of 1 Mbit/s, it is uncommon to use more than 50 % of maximum, due to its collision handling scheme [39]. The power consumption of a single network interface can therefore be described as in Equation (4.3) and (4.4).

PCAN_idle=PCTL+PPHY_idle (4.3)

PCAN_active=PCTL+0.5 ¨ PPHY_active+0.5 ¨ PPHY_idle (4.4)

Referencing the data sheets of six transceivers and four controllers, an interval over feasible power values are obtained. Calculating PPHY_idle and PPHY_activein accordance to Equations

(4.1) and (4.2) produce the following spans:

PPHY_idleP[25, 50]mW

PPHY_activeP[116, 201]mW

PCTLP[55, 150]mW

Upon focusing on the specific components used in implementation, namely a MCP2551 transceiver and MCP2515 controller, power values obtained from the data sheet give

(29)

PMCP2551_idle = 50 mW, PMCP2551_active = 194 mW and PMCP2515 = 55 mW. These values,

put into into Equations (4.3) and (4.4), give the expected power consumption of the CAN networking interface:

PCAN_idle =105 mW

PCAN_active=177 mW

Listed below are the transceivers and controllers used to determine the span of power values for CAN.

Transceivers:

• Analog Devices ADM3051 • Atmel ATA6600 • Infineon IFX1040 • Maxim MAX13041 • Microchip MCP2551 • NXP TJA1040. Controllers: • Microchip MCP2515 • Microchip MCP25625 • NXP SJA1000T • Siemens SAE 81C90/91

4.2.2 Expected Ethernet Power Values

In an Ethernet network, each networking interface includes a transceiver (PHY) and a con-troller (MAC). Unlike CAN, both components are presumed to draw constant power (PMAC,

PPHY) irrespective of being in an active transmission or idle. This is due to the network

oper-ating in full duplex [39]. The average power consumption is calculated according to Equation 4.5.

PEthernet=PMAC+PPHY (4.5)

Data sheets from five transceivers and five controllers with integrated transceivers result in the following interval over probable amounts of power:

PPHY P[158, 455]mW

PMAC+PHY P[317, 436]mW

Referencing the specification of the component used in implementation, a W5500 controller with an integrated PHY, the power is determined to be PW5500=436 mW. Because the PHY is

already integrated for this component, there is no need to add it to the calculations. Therefore, the resulting power consumption of the Ethernet networking interface is expected to be:

PEthernet=436 mW

The components referenced to determine the span of power values for Ethernet are listed below. Transceivers: • Broadcom BCM5341 • Microchip LAN8710A • NXP TJA1100 • Texas Instruments DP83848C • Texas Instruments DP83TC811R-Q1

Controllers (w. integrated PHY):

• Microchip ENC624J600-I/PT • Microchip KSZ8441HL/FHL • Microchip LAN9218

• Texas Instruments DP83816-EX • WIZnet W5500

(30)

4.2.3 EEE Power Values

When using EEE, the transmitting node will transition to a low-power mode as soon as there are no packets waiting to be sent. Once in LPI, the node only consumes 10 % of the power required in active transmission. For simplicity, the transitional sleep and wake up states are assumed to require similar amounts of power as when active, and the short refresh phases of LPI are presumed to not affect the power consumption. Given these premises, the energy levels of an EEE networking interface can be expressed as a percentage of peak consumption, where peak is when the node is in active transmission.

PEEE_idle =10 % of peak

PEEE_active=100 % of peak

For comparison, the peak power consumption can be assumed to be equal to the amount of power required by Ethernet (PEthernet = 436 mW). In this case, the resulting power values,

expressed in milliwatts, are as follows:

PEEE_idle=43.6 mW

(31)

5 Physical Implementation

In this chapter, the physical setup of bus networks for CAN and Ethernet are described. Test cases used to evaluate the networks are introduced: one with alternating load, to assess how power consumption is affected by utilisation; the other using real data, collected from a vehi-cle. Lastly, results from performing tests are presented, using graphs over measured currents as well as mean values of current levels and power consumption for each protocol.

5.1 Setup of Bus Networks

This section presents the components used to construct a simple bus network with two nodes, as well as describe how the components have been assembled. Some implementation details regarding the setup are revealed, including specific cable requirements and how the resulting power is calculated by means of measuring the current utilisation.

5.1.1 Component Specification

The physical bus is composed of two nodes and a laptop. Each node consists of an Arduino Uno1microcontroller and a Click Board2networking interface (NI) component. For commu-nication between the nodes, appropriate wire pertaining to the protocol’s standard is used. Details on components, their active modules and cable requirements can be found in Table 5.1, which is clarified below.

The first two columns of Table 5.1 specify the standards used in each implementation. The third column specifies the names of the NI components, whereas the fourth column highlights the specific controller and transceiver used for each NI component. The last column expresses any distinct cable requirements, specified by the standards.

In order to determine the power consumption of a NI, a current sensor is integrated into the circuit. The SparkFun Current Sensor Breakout3 carries an ACS723 sensor which can

1_{https://store.arduino.cc/arduino-uno-rev3} 2_{https://www.mikroe.com/click}

(32)

5.1. Setup of Bus Networks

measure low currents down to 20 mA. Samples are collected via an additional Arduino Uno where they are interpreted and averaged over a user defined number of samples before being passed on to the laptop.

Table 5.1: Component specifications for physical bus assembly.

Protocol Standard NI Component Modules Cable req.

CAN CAN V2.0B

ISO 11898-2 CAN SPI click

Controller: MCP2515 Transceiver: MCP2551

Single UTP wire, max 40 m Ethernet UDP/IP

100BASE-TX ETH WIZ click

Controller: W5500 (integrated transceiver)

Two UTP wires, max 15 m

5.1.2 Physical Assembly

Figures 5.1 and 5.2 illustrate the physical set up for CAN and Ethernet bus networks. In this set up, one node will act as a transmitter, collecting data from the laptop and passing it over to the receiver, which in turn will report any obtained messages back to the laptop. With such an arrangement, it is easy to determine the success rate of the communication by comparing the transmitted with the received data.

As illustrated, a current sensor measures the current passing through the transmitting NI component by connecting it in serial with the power supply between the transmitting mi-crocontroller and the Click Board. Current samples are collected with a 1 ms interval and averaged over 100 readings on the microcontroller before the result is passed over to the computer, i.e. logging of current measurements occurs every 100 ms.

The CAN bus communicates over a pair of twisted wires, as required by the standard. The Ethernet NI uses a regular RJ45 jack with an Ethernet cable containing four twisted-pair wires. However, in order to avoid introducing a switch to this simple network, a crossover cable must be used. This means the wires connected to the TX pins at one end must be connected to the RX pins at the other end, and vice versa. In this implementation, the crossover cable has been created by hand by cutting through the RX and TX wires and reconnecting them with their counterparts.

5.1.3 Method for Calculating Power Consumption

The NI components are assumed to operate under constant voltage levels. This can be used to calculate the resulting power consumption with Ohms law (P=U ˆ I), by multiplication with the measured current. The following voltages are used for calculations, in accordance with the NI component specification:

VCAN_Click=5.0 V

VEth_Click=3.3 V

The readings from the current sensor are used to calculate an average (µ) and standard de-viation (σ). Denoting the test case name as X and the protocol used as prot, the current and power consumption of CAN and Ethernet can be expressed using Equations (5.1)–(5.2).

Iprot_X=µprot_X˘ σprot_X (5.1)

(33)

5.1. Setup of Bus Networks

Figure 5.1: Physical setup of CAN bus

(34)

5.2. Description of Test Cases

5.2 Description of Test Cases

For all test cases described below, current sensor samples are collected and saved to a log file every 100 ms from the time the transmitting node starts sending until the end of the test case. Every test case is run three times per protocol, so that potential trends can be identified and an average determined. For CAN, the ID of each message is set in the identifier field and each frame will always contain eight bytes of data. For Ethernet, the IP address remains constant and the ID is instead added as two or more initial bytes of data in the data field. This means the message consists of at least ten data bytes when using Ethernet. However, as explained in Section 2.3.2, the data field will always be at least 46 bytes, so adding the ID to the data field will not impact the packet size. Figure 5.3 provides an overview of the amount of messages sent each second for the two test cases.

Figure 5.3: Illustration of the amount of messages sent every second in test case A (upper) and B (lower).

5.2.1 Test Case A: Alternating Load

In test case A, the bus will alternate between high and no utilisation, in an attempt to find patterns in energy consumption and usage, if any. This means leaving the bus in idle for 1 second, then repeatedly sending messages during 1 second. During the active phases, there is a short delay of 1 ms between each transmission, to avoid overflows in sending and receiving buffer and ensuring error-free transmission. Each iteration, the number of sent messages may vary somewhat depending on the processing speed of the computer, causing the short pause between messages to exceed 1 ms. However, it can be expected to send between 800 and 820 messages during each active phase, and none during the idle phase. This message frequency during the active phase is chosen to ensure high but error-free utilisation of the two networks. An example of the alternating load, captured during a test run, is illustrated in Figure 5.3 (upper). The repeated message contains the data {0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF}. Using CAN, the ID is set to 0x0555, while with Ethernet, the two corresponding identifyer bytes are instead added to the data field.

Energy Consumption of In-Vehicle Communication in Electric Vehicles : A comparison between CAN, Ethernet and EEE

Linköping University | Department of Computer and Information Science

Master thesis, 30 ECTS | Computer Science

2019 | LIU-IDA/LITH-EX-A--19/051--SE

Energy Consumption of

In-Vehicle Communication in

Electric Vehicles

A comparison between CAN, Ethernet and EEE

Energikonsumtion vid intern kommunikation i elbilar – En

jäm-förelse mellan CAN, Ethernet och EEE

Kimberley French

Upphovsrätt

Copyright

Acknowledgments

Contents

List of Figures

List of Tables

1

Introduction

1.1

Problem Description

1.2

Aim

1.3

Delimitations

1.4

Approach

1.4.1

Theoretical Analysis

1.4.2

Physical Implementation

1.4.3

Simulation

1.5

Thesis Structure

2

Theory

2.1

The OSI Model

2.2

Controller Area Network

2.2.1

CAN Characteristics

2.2.2

Frame Format of CAN

2.3

Automotive Ethernet

2.3.1

Ethernet Characteristics

2.3.2

Frame Format of Ethernet

2.3.3

Time-Sensitive Networking

2.4

Energy-Efficient Ethernet

3

In-Vehicle Communication

Model

3.1

Current Architecture

3.2

Architectural Limitations

3.3

Next Generation In-Vehicle Networking

3.3.1

Energy Implications of an Ethernet-Based Architecture

4

Theoretical Analysis

4.1

Transmission Efficiency

4.2

Theoretical Power Consumption

4.2.1

Expected CAN Power Values

4.2.2

Expected Ethernet Power Values

4.2.3

EEE Power Values

5

Physical Implementation