Fast Firmware Updates Over-the-AirMechanisms to speed up ECU updates in the vehicle

ETAS Contact Addresses

Dr. Alexander Leonhardi

Phone +49 711 3423-2843

Mobile +49 173 6819049

E-Mail alexander.leonhardi@ etas.com

Dr. Ibrahim Armac

Phone +49 711 3423-2581

Mobile +49 172 6857231

E-Mail ibrahim.armac@etas.com

2 CONTENT

Content List of Abbreviations 3

1 | Introduction 4

2 | Assumed Network Architecture & FOTA Components 5

3 | Fast Update Mode 7 3.1 Improvement Potential 3.2 Requirements

4 | Parallel Updating of ECUs in Different Domains 8 4.1 Improvement Potential 8

4.2 Requirements 9

5 | Parallel updating of ECUs in the same domain utilizing internal processing time 9

5.1 Improvement Potential 95.2 Requirements 10

6 | Parallel Updating of ECUs in the same using parallel connections 10 6.1 Improvement Potential 11 6.2 Requirements 11

7 | Improvement Potential by Sorting the Updates 11 7.1 Requirements 12

8 | Summary 12 8.1 ETAS and ESCRYPT offer 13

9 | References 13

10 | ETAS Contact Adresses 14

3L IST Of AbbREvIATIONS

List of Abbreviations

bL bootloader Handling the flashing of the embedded ECU

CS Content Storage After downloading, update packages are stored in it.

DC Domain Controller A powerful ECU is available for each domain. DLC Download Client Received update packages on the vehicle side.

DLS Download Server Update packages are provi - ded for download.

ECU Electronic Controll Unit Controls electronic systems in the vehicle.

fUM firmware Update Manager Transmits flashing and verifi- cation of the update.

TCU Telematics Communication Unit The Download Client running on it.

UDM Update Distribution Manager Handles the distribution of the update packages

UMM Update Mode Manager Component as a manage- ment intance to handle the fast update.

vUM vehicle Update Manager It gets the update packages from DLC.

4 1 | INTRODUCTION

The ability to update software in vehicles via a wireless connection over-the-air (OTA) is becoming increasingly important. The reasons are multifaceted: first, it makes the distribution of software up-dates efficient. Such software updates have become necessary because software complexity in vehicles is vastly increasing and it is necessary to react to securityissues that are likely be caused by the pro-liferation of connectivity via different channels. Second, software updates are the basis for feature updates that allow the vehicle manufacturer to stay in touch with customers throughout the vehicle’s lifetime and to meet consumer electronic device expectations based on customer experience.

Today, software updates in vehicles are mostly processed in the workshop under defined conditions and supervised by ex-perienced personnel. Soon, various stake-holders (e.g., fleet managers, vehicle own-ers, or drivers) will be able to perform software updates over the air nearly any-where without additional assistance.

Especially when installing updates, it is im-portant to keep update time as short as possible. In most cases during the update, the vehicle – or at least parts of its func-tionality – are not available to the driver. While the download phase may be perfor-

1 | Introduction

med while the vehicle is in motion, the in-stallation phase itself normally takes place while the vehicle is parked and the engine is not running. As a result, low energy consumption is an important restriction during updating in case the vehicle is not connected to a power supply.

In this white paper, we discuss different concepts for speeding up the update pro-cess with the goal of utilizing the network bandwidth for transmitting updates in the vehicle as much as possible. These con-cepts are:

— fast update mode— Updating ECUs in different domains in parallel— Updating ECUs on the same bus system in parallel utilizing ECUs internal processing time— Transmitting data to different ECUs on the same bus system, using parallel connections— Putting updates in a certain order to achieve and optimum parallelization

We will discuss these concepts in more detail in the remainder of this white paper. The first four can either be used as stand-alone solutions or in different combina-tions. The final concept is a further optimi-zation step for parallel updating. Depending on the concept, different

components or prerequisites are required to realize it. These will be described in more detail below.

All concepts, except the first one, work on the principle that multiple ECUs need to be updated simultaneously. Not included in the focus of this white paper are further optimizations that can be realized on the level of a single ECU, such as a double buffering concept (also known as pipe-lining or queuing), compression, or delta updates.

The realized performance increase for each of these concepts relies on different assumptions regarding the network architecture of the vehicle manufacturer, which we will discuss in the more detailed introduction of these mechanisms below. In general, however, realized performance varies depending on the vehicle’s network architecture and will have to be investi-gated carefully in this context.

In the best case, the performance for updating a larger number of vehicle ECUs will be increased multiple times. We there-fore see these mechanisms as an essential element for a concept that performs over-the-air software updates. Without these mechanisms, it is not possible to achieve an acceptable time for performing larger updates.

52 | ASSUMED NETWORk ARCHITECTURE AND fOTA COMPONENTS

2 | Assumed network architecture and FOTA components

for firmware over-the-air (fOTA), we consider the following network architec-ture and mechanism (see fig. 1). As these will vary quite significantly between diffe-rent vehicle manufacturers, this shall be only used as a reference architecture.

We assume that the E/E architecture of a high-end vehicle is structured into diffe-rent domains. In this architecture, a powerful ECU – called a domain controller (DC) – is available for each domain. All DCs are connected via a high-speed back-bone network, such as automotive Ethernet. Other domain ECUs are connected to the respective DC with a domain-specific network (such as CAN or flexRay). Although the E/E architectures of

different vehicle manufactures vary consi-derably, this model is a good basis for conceptual discussions.

for the fOTA mechanisms, we assume that a software update will be defined, maintained, and initiated on a backend infrastructure. On the backend, among others, the definition of the software update packages are managed for a complete fleet of vehicles, for given vehicle platforms, and for vehicles at an individual level considering functionality and vehicle configurations. These are needed to run the campaign management for rolling out the update. The update packages are protected with security signatures and CRCs and made available

for download on the download server (DLS).

In our consideration, update packages on the backend are available based on “soft-ware baselines” for the complete vehicle. This is understood as a released set of firmware software versions for all ECUs in a vehicle that allows for safe and compa-tible operation. On a technical level, the release includes the validity for specified vehicle configurations, such as hardware, software, sensors, and actuators, and vali-dity between the firmware versions for the different ECUs themselves. This is typi-cally specified and released by the OEM. We assume that the update package contains the information and firmware

Figure 1: FOTA network archtitectureDLS DLC

DC DC DC DC

BL BL FUM UDM UMM

VUC

BL CS BL

BL

BL

BL BL BL

BL BL BL

ECU

ECU

ECU ECU ECU

ECU ECU ECU

Do

män

enn

etzw

erk

Do

män

enn

etzw

erk

Do

män

enn

etzw

erk

Do

män

enn

etzw

erk

BackendDC

...

High-Speed-Backbone

... ... ...

Download-Phase

Installationsphase

Drahtlose Verbindung

Legende

BL Bootloader CS Content-Storage UDM Update-Distribution-ManagerDC Domain-Controller ECU Steuergerät UMM Update-Mode-ManagerDLC Download-Client FUM Firmware-Update-Manager VUM Vehicle-Update-ManagerDLS Download-Server TCU Telematik-Communication-Unit

6 2 | ASSUMED NETWORk ARCHITECTURE AND fOTA COMPONENTS

2 | Assumed Network Architecture and FOTA Components

necessary for updating all affected ECUs in order to reach the state from one valid baseline to another valid baseline.

On the vehicle side, update packages are re-ceived by the download client (DLC) running on a connectivity unit or Telematics Com-munication Unit (TCU) that can interact with the backend via a wireless connection. After downloading, update packages are stored in a content storage unit (CS), which might be located on one of the domain controllers (DC), e.g. the head unit.

After an update package is completely downloaded and includes the correct de-pendencies and has been checked for se-curity signatures and CRC, the DLC hands over the update package to the vehicle update manager (vUM). With that, the “download phase” is complete. The download phase from the backend to the CS is depicted in a dark color in fig. 1.

In the subsequent “installation phase,” the vUM is responsible for organizing the preparation at vehicle level, and also dis-tributing and installing the download to the affected ECUs in multiple domains. Preparation is defined as checking, achieving, and maintaining the necessary preconditions for distribution and instal-lation. Distribution refers to either normal

or fast distribution within the vehicle and across different domains, such as the power train or chassis, and over different busses. The distribution of the update packages is handled by an update distri-bution manager (UDM) within the vUM. It is assumed that there is one instance of UDM within the vehicle.

Downloading and installing update pack-ages are only possible in dedicated modes known as “update modes” and are dependent on certain conditions, such as power supply and the vehicle’s operational state.

The firmware update manager (fUM) performs the installation sequence for the embedded ECUs themselves. This in-cludes transmitting, flashing, and verify-ing the update. A further important as-sumption is that the bootloader handles the flashing of the embedded ECU itself; the ECU is set in “bootloader mode”. Af-ter successful flashing, and verification, the ECU will switch back to the applica-tion mode with the (new) application. The memory area of the bL code at the target ECU is assumed to be protected against modification. Even if failure oc-curs during installation of the new appli-cation software, the bL mode is reactivat-ed after reset because no application

software is available. Programming the new application software can then be tried again.

In most cases, the installation phase of an ECU can be subdivided into three sub-pha-ses. These are 1) distributing the data to the ECU, 2) writing the data to memory, and 3) verifying that the data has been written correctly. furthermore, data distri-bution will be performed block-wise; the update data to be distributed is separated into different blocks of a fixed size. Depen-ding on the type of ECU, the sub-phases are either executed sequentially (i.e., the whole update data is first distributed, then it is written to memory, and finally the me-mory is verified) or it is executed for each transferred block. To simplify our discussion here, we shall assume block-wise updating and collapse the latter two phases into one phase that we will call processing.

Throughout this white paper, we used the following values from two real ECU pro-jects, each with firmware of roughly 1.5 Mb. The transfer time for a block assumes a CAN bus of 500 kbd. In the first ECU ex-ample (ECU1), the processing time is lon-ger than the transfer time. This is reversed in the second example (ECU2).

ECU1 ECU2

firmware size 1.5 Mb 1.5 Mb

Number of blocks 1698 6005

Time to transfer one block 29.08 ms 12.21 ms

Time to process one block 110 ms 6.7 ms

73 | fAST UPDATE MODE

3 | Fast update mode

When transmitting larger amounts of data in parallel to regular application communi-cation on a vehicle network, it has to be ensured that this transmission does not af-fect the regular application communica-tion. Otherwise, the timing analysis that is the basis for ensuring safe reception of critical vehicle signals will become invalid. Therefore, for a CAN network diagnostic communication in regular application mode will be allowed only up to a maxi-mum of 50 percent of the bus speed, in most cases much less, for example 20 per-cent.

Today, when a software update is per-formed during a diagnostic session in the workshop, the regular application com-munication will be disabled. This means it is possible to utilize nearly the maximum bus speed when the sending and receiving ECUs can handle the data transmission. However, this implicitly assumes that the vehicle is in a safe operational state (e.g., parked) and that the process is supervised by trained personnel.

We propose to implement a fast update mode that can be enabled independently of a diagnostic session. This update mode could, for example, be enabled when the driver has turned off the vehicle and has ackknowledged that a software installa-

tion should be performed. The corre-sponding update package may already have been downloaded while the vehicle was in use. In this case, the full bus band-width could be utilized to distribute the update to the respective ECUs. If only ECUs in one domain need to be updated, fast update mode should be activated only for this domain. finally, respective energy management mechanism should also be coordinated with fast update mode to de-activate ECUs and domains that are not in-volved in the update by using partial net-working concepts.

However, to avoid invalid states or lock-ups, the realization of such a mode has to be considered carefully against the gener-al mode management of a vehicle, which is usually a differentiating factor of the ve-hicle manufacturer.Additionally, safety as-pects have to be considered, for example, monitoring changes in the vehicle's opera-tional state that make it necessary to leave fast update mode.

3.1 Improvement potential

The improvement potential for fast update mode is shown below and depends on the time the ECU needs to transmit one block as opposed to the time necessary for the internal processing. Obviously, the im-

provement is greater if the transfer time is longer than the processing time.

The transmission speed of the CAN trans-port protocol (CAN TP), which is used to transmit diagnostic messages that are also used for software updates, is generally de-fined by two parameters, STmin (minimum separation time) and bS (block size). STmin describes the minimum time between frames that an ECU is able to process. This means the sender has to wait before send-ing out the next message. bS describes the number of CAN frames that can be sent before the sender has to wait for a flow control message from the receiver.

for normal transmission we assume an ST-min time of 300 µs, which is calculated in order to use a maximum of 50 percent of the bandwidth of a 500 kbit/s CAN bus. In our experience this is a rather conserva-tive estimation because in most cases the STmin time will be longer. for fast update mode, we have set STmin to 0, which means that the sender is allowed to send quickly as possible. In both cases we use a bS parameter of 0. This means that the sender does not have to wait for flow con-trol messages.

.

ECUs w/o optimizations (STmin = 300 µs) Fast update mode (STmin = 0)

ECU1 5.01 min 3.94 min (21 %)

ECU2 2.94 min 1.89 min (36 %)

8 4| PARALLEL UPDATING Of ECUS IN DIffERENT DOMAINS

3.2 Requirements

— An pdate mode manager (UMM) component as a management instance to handle the fast update mode. This component is responsible for interac ting with the global vehicle mode management in order to check pre-

conditions, monitor conditions, and set inhibitions.

— All ECUs must support the functiona lity to disable normal application messages during fast update mode. This functionality has to be supported in application mode and in

most cases is already provided for regular updating during a diagnostic session.

— The bootloader (bL) of the ECUs does not need to be changed

DC DC DC DC

ECU

ECU

ECU ECU ECU

ECU ECU ECU

Do

mai

n n

etw

ork

Do

mai

n n

etw

ork

Do

mai

n n

etw

ork

Do

mai

n n

etw

ork

DC

...

High speed backbone

... ... ...

On-boardTester

4 | Parallel updating of ECUs in different domains If either a high-performance central gate-way or a high-speed backbone is used, as described in Section 2, it is possible to update ECUs in different domains in par-allel. In figure 2, this is shown based on the model of the domain controller archi-tecture discussed in Chapter 2. An on-board tester with a respective functionality can perform the installation process in parallel for ECUs in the differ-ent domains of the vehicle provided that

the central gateway or the high-speed backbone have enough performance to handle the increased requirements for data transmission. for example, in the discussed domain controller architecture a backbone with automotive Ethernet (100 Mbit/s) should have no problem with updating of different CAN networks (≤ 1 Mbit/s). These, are still the most common bus systems.

4.1 Improvement potential

The performance increase gained through parallel flashing depends heavily on the number of domains, the speed of the respective networks, and the flash size of the ECUs in the domains. Ideally, if we assume four domains in a vehicle and the speed and size is equally balanced between these ECUs, it should be possi-ble to achieve a speed increase of 300

Figure 2: Parallel updating in domain

controller archtitecture

95 | PARALLEL UPDATING Of ECUS IN THE SAME DOAMIN UTLIZ ING INTERNAL PROCESSING TIME

gorithms. first, a simple round-robin al-gorithm that transmits the next block of data to the ECUs based on a fixed order. Second, if the next ECU in the round rob-in order is still busy with processing, we can use an optimized algorithm that sends data to another ECU.

5.1 Improvement potential

The improvement potential for different

scenarios is shown below. first we use the values of our example ECUs that have been introduced in Section 2. In the inves-tigation below, we have assumed a net-work with two each of these ECUs in or-der to have a total number of four ECUs. To compare the two algorithms, we have looked at other scenarios with typical transfer and processing times. In this way, we have developed a scenario in which the processing time is longer than the

While the bus required transmit the up-date data to the ECUs is a shared re-source, processing will be performed in-dependently by the ECUs. This can be utilized in order to parallelize the update of the ECUs withiin one domain (see fig-ure 3). A a high-end vehicle may contain a large numbers of ECUs.

In order to schedule the next block to be sent we have looked at two different al-

DC DC

ECU1

ECU2

Do

mai

n n

etw

ork

...

On-boardTester

Bus transmission ECU1 Bus transmission ECU2

Processing ECU1 Processing ECU2

Sequential flashing

Parallel flashing

Bus transmission

Processing ECU1

Processing ECU2

t

t

Speedincrease

ECU3

percent compared to flashing all domains sequentially. However, ECU size can vary significantly and the flash image size of some domains, such as infotainment, will be much larger than others (e.g., the power train domain's flash image size).

4.2 Requirements

— A vehicle update manager (vUM) component that has the functionality to coordinate the execution of the flashing process for different bLs in parallel.

— Implementation of fast update mode (see previous chapter) is recom- mended because the parallel flashing introduces a high load on the vehicle network.

— The bL of the ECUs does not to be changed.

Parallel updating of ECUs in different domains

Performance increase: ~ 100 % to max. 300 %

5 | Parallel updating of ECUs in the same domain utilizing internal processing time

Figure 3: Parallel updating of ECUs in the

same domain

10 6 | PARALLEL UPDATING Of ECUS IN THE SAME DOMAIN USING

6 | Parallel updating of ECUs in the same domain usingparallel connections

transmission time (four ECUs with profile ECU1) or the other way around (four ECUs with profile ECU2). The results for the dif-ferent scenarios and the two algorithm variants are shown below.

from these results, we see a performance increase of up to 78 percent with four ECUs. The results also show that when the processing time of the ECU is longer than the transfer time, we achieve better performance. Especially in this case, the value is also expected to increase be-cause the gaps in the bus transmission can be further utilized.

-

As with the current introduction of faster bus systems the processing time will in-creasingly become the limiting factor (see [2]) parallelization becomes even more important.

5.2 Requirements

— A vUM component that has the func- tionality to coordinate the execution of the flashing process for different bLs in parallel.

— Parallel communication streams need to be considered in the communica- tion architecture, for example in the

implementation of respective gateways.

— The implementation of a fast update mode (see previous chapter) is recom mended as the parallel flashing intro duces a significant load on the vehicle network.

— The bLs of the ECUs does not need to be changed (provided that the ECUs can handle the resulting waiting times).

DC DC

ECU1

ECU2

Do

mai

n n

etw

ork

DC

...

On-boardTester

Bus transmission ECU1 Bus transmission ECU2

Processing ECU1 Processing ECU2

Sequential flashing

Parallel flashing

Bus transmission

Processing ECU1

Processing ECU2

t

t

Speedincrease

ECU3

Figure 4: Parallel updating of ECUs in the

same domain using parallel

connections

Parallel updating of ECUs in one domain No optimization Round robin Optimized

four ECUs with mixed profile (two of each

ECUs

15.9 5.69 min (64 %) 5.11 min (68 %)

four ECUs with processing time longer than

transfer time

20.06 5.19 min (74 %) 4.38 min (78 %)

four ECUs with transfer time longer than

processing time

11.77 3.82 min (68 %) 3.82 min (68 %)

117 | IMRPOvEMENT POTENTIAL bY SORTING THE UPDATES

7 | Improvement Potential by Sorting the Updates

Obviously, there is an upper limit to the number of updates that can be per-formed in parallel. In the best case, this limit is reached when the whole band-width of the bus system is utilized. for this reason, we have performed further investigations to determine the maximum number of parallel updates in different scenarios, referred to here as the opti-mum threshold of parallel updates. It is expected that adding another update to

be processed in parallel will require addi-tional resources and the performance will decrease even more than shown in our simulations.

To test this, we simulated the parallel transmission from one to eight ECUs, al-ternating with the ECU profiles ECU1 and ECU2 described in Section 2 (starting with ECU1). With this simulation we achieve a threshold level for parallel up-

dates as follows (assuming a 500 kbd CAN:)

— Round-robin algorithm non- interleaved: five ECUs

— Optimized algorithm non-interleaved: three ECUs

— Round robin algorithm interleaved: five ECUs

-

In the previous two scenarios, we have as-sumed that only one transmission in a do-main’s bus system can be performed at a In the previous two scenarios, we have as-sumed that only one transmission in a do-main’s bus system can be performed at a time. However, usually the data rate at which ECUs can receive data is slower than the bandwidth available on the bus system. Therefore, there is additional po-tential for parallelization by also transmit-ting the block data to multiple ECUs in parallel rather than sequentially, as in the last section (see figure). This is especially true for a CAN network with very small packets. As CAN is still the most common domain network, we will use it as an ex-ample throughout this section.

6.1 Improvement potential

The improvement potential for the differ-ent scenarios through parallel connections

is shown below. In our investigation we have set the parameter values for STMin and bS of the CAN TP both to 0. This can be done only if fast update mode is imple-mented (see Section 3).

The results are shown below for the same scenarios used in the previous chapter. We see that the improvements are further in-creased, especially when transfer time is longer than processing time (from 68 to 72 percent).

6.2 Requirements

— A vUM component that has the func- tionality to coordinate the execution of the flashing process for different ECUs in parallel.

— A gateway architecture in the domain controllers that has the possibility to

transmit different streams to ECUs in parallel as the timing of the transport protocols will have to be observed.

— The implementation of a fast update mode (see previous chapters) is re- commended as the parallel flashing introduces a high load on the vehicle network.

— The bLs of the ECUs does not need to be changed (provided that the ECUs can handle the resulting waiting times).

Parallel updating of ECUs in one domain No optimization Round robin Optimized

four ECUs with mixed profile (two of each

ECUs)

15.9 5.45 min (66 %) 4.52 min (72 %)

four ECUs with processing time longer than

transfer time

20.06 4.46 min (78 %) 4.40 min (78 %)

four ECUs with transfer time longer than

processing time

11.77 3.39 min (71 %) 3.33 min (72 %)

12 8 | SUMMARY

8 | Summary

In this white paper, we have described dif-ferent mechanisms for speeding up the update time for an over-the-air vehicle up-date. These mechanisms are most effec-tive when multiple ECUs have to be up-dated at the same time. We have summarized the results for different num-bers of ECUs below to show this effect. for these results we have assumed that

there is a high-speed backbone (which is not considered in the investigation below) that connects two domains with a 500 kbd CAN each. We have assumed that all ECUs have the same characteristics for the sake of simplification.

The first table below shows the results for ECU1, where the processing time is longer

— Optimized algorithm interleaved: all eight ECUs lead to an improvement

furthermore, in our investigations of the improvement potential described in the previous sections, we have found that the improvement potential for parallel updating depends on the profile of the ECUs. The results indicate that updating ECUs with suitable profiles together leads to a better result. In this section, we will investigate whether sorting the list of ECUs to be updated leads to a measurable performance improvement or not. for this investigation we have used a list of five ECUs to be updated, consisting of different combinations of ECUs with the profile of ECU1 (processing time longer than transmission time) and of ECU2 (transmission time longer than processing time). Additionally, we have used different threshold levels for the number of ECUs to be updated in parallel. We have only used

# of ECU1 # of ECU2 Threshold Max. update time Min. update time Difference

1 4 5 5.53 min 5.00 min 10 %

2 4 4 8.82 min 6.40 min 27 %

3 3 4 7.42 min 5.91 min 20 %

4 3 3 7.87 min 6.38 min 19 %

the optimized non-interleaved algorithm to simplify the evaluation.These results show that the update order has an influence on the possible perfor-mance increase even when all ECUs are updated in parallel. The difference is between 10 percent and 27 percent. further simulation results show that the improvement is even higher for the round-robin algorithm (up to 90 percent). Our experiments showed that in almost all cases, the best results were achieved when the ECUs with the higher ratio of processing time versus transmission time (profile of ECU1) were updated first.

We therefore propose to determine the optimum order of updates for achieving the best performance. There are two ways to achieve this:

— On the backend, perform a simulation similar to the one we have used for this investigation to determine the

optimum order when assembling the update package.— Incorporate a simple mechanism for sorting the list of ECUs so that ECUs with a longer update time and a higher ratio of processing time versus transmission time appear at the top of the list.

7.1 Requirements

— A vUM component that has the func- tionality to coordinate the execution of the flashing process for different ECUs in parallel.

— The bL of the ECUs does not need to be changed

than the transfer time. Here, the potential for fast update mode is not as big (21 per-cent). However, the potential for paralleli-zation is greater, and is already at 86 per-cent with eight ECUs in two domains. In other words, we can update eight ECUs using parallelization within almost the sa-me amount of time as only one ECU

138 | SUMMARY

No of ECU No of domains w/o optimizations

(STmin = 300µs)

Fast update mode

(STmin = 0)

Fast update mode &

parallel updating

1 1 5.01 min 3.94 min (21 %) 3.94 min (21 %)

2 2 10.03 min 7.78 min (21 %) 3.94 min (61 %)

4 2 20.06 min 15.74 min (21 %) 4.7 min (77 %)

8 2 40.11min 31.49 min (21 %) 5.54 min (86 %)

would have been updated without any optimizations.

for ECU2, we see that the implementation of a fast update mode already brings an improvement of over 36 %. The potential for parallel updating increases with the number of ECUs and is at 85 % with eight ECUs in two domains (i.e., four in each domain).

We see, that using these mechanisms we can achieve a speed increase of a factor greater than six in case of 8 ECUs. further-more, the potential for mechanisms for parallel updating are increasing with the number of ECUs. Therefore, we are con-vinced that they are essential in order to implement a whole vehicle update within an acceptable time.

Additionally, these mechanisms can be combined with further optimization me-chanisms like compression or delta up-dates. However, unlike those the mecha-nisms we described in this paper only require changes in the DCs and gateways. The bLs of the updated ECUs themselves do not have to be changed, provided that they support the respective waiting times introduced by parallelization

No of ECU No of domains w/o optimizations

(STmin = 300µs)

Fast update mode

(STmin = 0)

Fast update mode &

parallel updating

1 1 2.94 min 1.89 min (36 %) 1.89 min (36 %)

2 2 5.89 min 3.78 min (36 %) 1.89 min (68 %)

4 2 11.77 min 7.57 min (36 %) 4.7 min (77 %)

8 2 23.55 min 15.14 min (36 %) 5.54 min (85 %)

What ETAS and ESCRYPT offer

The following components and services are currently available:

FOTA-relevant Services

— Define overall fOTA concept and architecture

— Create specifications for respective components (SW and HW)

— Project coordination for the involved partners

— Perform safety analysis and create safety concept

— Perform security analysis, security reviews, code reviews

— Take on role as safety and security manager in fOTA project

FOTA-relevant Products

— Embedded SW components for providing the fOTA functionality in the vehicle to be integrated into the diffe- rent types of ECUs

— Provide embedded security libraries, middleware for security hardware and vehicle key management for in-vehicle use either stand-alone or included in the fOTA components

— Provide suitable key management solution for back-end either stand- alone or integrated into fOTA back- end solution from bosch

ETAS GmbHborsigstraße 1470469 Stuttgart, GermanyPhone +49 711 34 23-0sales.de@etas.com

www.etas.comETA

S-PG

A/M

kC2_

LRN

/01_

2017

ETAS Locations Worldwide

Germany

Stuttgart (Headquarter)

Brazil

São bernardo do Campo

Canada

kitchener

France

Saint-Ouen

India

bangalore

Pune

Italy

Turin

Japan

Utsunomiya

Yokohama

Korea

Seongnam-si

P.R. China

beijing

Changchun

Chongqing

Guangzhou

Shanghai

Wuhan

Sweden

Gothenburg

United Kingdom

Derby

York

USA

Ann Arbor

www.etas.com