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

Transcription

1 Fast Firmware Updates Over-the-Air Mechanisms to speed up ECU updates in the vehicle ETAS Contact Addresses Dr. Alexander Leonhardi Phone Mobile etas.com Dr. Ibrahim Armac Phone Mobile etas.com

2 2 CONTENT Content List of Abbreviations 3 1 Introduction 4 2 Assumed Network Architecture & FOTA Components 5 3 Fast Update Mode Improvement Potential 3.2 Requirements 4 Parallel Updating of ECUs in Different Domains Improvement Potential Requirements 9 5 Parallel updating of ECUs in the same domain utilizing internal processing time Improvement Potential Requirements 10 6 Parallel Updating of ECUs in the same using parallel connections Improvement Potential Requirements 11 7 Improvement Potential by Sorting the Updates Requirements 12 8 Summary ETAS and ESCRYPT offer 13 9 References ETAS Contact Adresses 14

3 List of Abbreviations 3 List of Abbreviations BL CS DLC DLS Bootloader Handling the flashing of the embedded ECU Content Storage After downloading, update packages are stored in it. Domain Controller A powerful ECU is available for each domain. Download Client Received update packages on the vehicle side. Download Server Update packages are provi - ded for download. TCU UDM UMM VUM Telematics Communication Unit The Download Client running on it. Update Distribution Manager Handles the distribution of the update packages Update Mode Manager Component as a management intance to handle the fast update. vehicle Update Manager It gets the update packages from DLC. ECU Electronic Controll Unit Controls electronic systems in the vehicle. FUM Firmware Update Manager Transmits flashing and verification of the update.

4 4 1 Introduction 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 updates efficient. Such software updates have become necessary because software complexity in vehicles is vastly increasing and it is necessary to react to security issues that are likely be caused by the proliferation 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 experienced personnel. Soon, various stakeholders (e.g., fleet managers, vehicle owners, or drivers) will be able to perform software updates over the air nearly anywhere without additional assistance. Especially when installing updates, it is important to keep update time as short as possible. In most cases during the update, the vehicle or at least parts of its functionality are not available to the driver. While the download phase may be perfor- med while the vehicle is in motion, the installation 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 process with the goal of utilizing the network bandwidth for transmitting updates in the vehicle as much as possible. These concepts 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 standalone solutions or in different combinations. The final concept is a further optimization 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 pipelining 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 investigated carefully in this context. In the best case, the performance for updating a larger number of vehicle ECUs will be increased multiple times. We therefore see these mechanisms as an essential element for a concept that performs overthe-air software updates. Without these mechanisms, it is not possible to achieve an acceptable time for performing larger updates.

5 2 Assumed network architecture and FOTA components 5 2 Assumed network architecture and FOTA components For firmware over-the-air (FOTA), we consider the following network architecture and mechanism (see Fig. 1). As these will vary quite significantly between different 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 different domains. In this architecture, a powerful ECU called a domain controller () is available for each domain. All s are connected via a high-speed backbone network, such as automotive Ethernet. Other domain ECUs are connected to the respective with a domain-specific network (such as CAN or FlexRay). Although the E/E architectures of different vehicle manufactures vary considerably, 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 software 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 compatible operation. On a technical level, the release includes the validity for specified vehicle configurations, such as hardware, software, sensors, and actuators, and validity between the firmware versions for the different ECUs themselves. This is typically specified and released by the OEM. We assume that the update package contains the information and firmware Drahtlose Verbindung Figure 1: FOTA network archtitecture Backend DLS DLC Download-Phase Installationsphase High-Speed-Backbone VUC BL BL FUM UDM UMM BL CS BL Domänennetzwerk ECU ECU... BL BL Domänennetzwerk ECU ECU ECU BL BL BL Domänennetzwerk Domänennetzwerk ECU ECU ECU BL BL BL Legende BL Bootloader CS Content-Storage UDM Update-Distribution-Manager Domain-Controller ECU Steuergerät UMM Update-Mode-Manager DLC Download-Client FUM Firmware-Update-Manager VUM Vehicle-Update-Manager DLS Download-Server TCU Telematik-Communication-Unit

6 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 received by the download client (DLC) running on a connectivity unit or Telematics Communication 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 (), e.g. the head unit. After an update package is completely downloaded and includes the correct dependencies and has been checked for security 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 distributing 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 installation. 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 distribution manager (UDM) within the VUM. It is assumed that there is one instance of UDM within the vehicle. Downloading and installing update packages 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 includes transmitting, flashing, and verifying the update. A further important assumption is that the bootloader handles the flashing of the embedded ECU itself; the ECU is set in bootloader mode. After successful flashing, and verification, the ECU will switch back to the application 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 occurs during installation of the new application software, the BL mode is reactivated 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-phases. 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 distribution will be performed block-wise; the update data to be distributed is separated into different blocks of a fixed size. Depending 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 memory 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 projects, 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 example (ECU1), the processing time is longer 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 Time to transfer one block ms ms Time to process one block 110 ms 6.7 ms

7 3 Fast update mode 7 3 Fast update mode When transmitting larger amounts of data in parallel to regular application communication on a vehicle network, it has to be ensured that this transmission does not affect the regular application communication. 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 maximum of 50 percent of the bus speed, in most cases much less, for example 20 percent. Today, when a software update is performed during a diagnostic session in the workshop, the regular application communication 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 installation should be performed. The corresponding update package may already have been downloaded while the vehicle was in use. In this case, the full bus bandwidth 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 deactivate ECUs and domains that are not involved in the update by using partial networking concepts. However, to avoid invalid states or lockups, the realization of such a mode has to be considered carefully against the general mode management of a vehicle, which is usually a differentiating factor of the vehicle manufacturer.additionally, safety aspects have to be considered, for example, monitoring changes in the vehicle's operational 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 improvement is greater if the transfer time is longer than the processing time. The transmission speed of the CAN transport protocol (CAN TP), which is used to transmit diagnostic messages that are also used for software updates, is generally defined 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 sending 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 STmin 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 conservative 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 control messages.. ECUs w/o optimizations (STmin = 300 µs) Fast update mode (STmin = 0) ECU min 3.94 min (21 %) ECU min 1.89 min (36 %)

8 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 4 Parallel updating of ECUs in different domains If either a high-performance central gateway or a high-speed backbone is used, as described in Section 2, it is possible to update ECUs in different domains in parallel. In Figure 2, this is shown based on the model of the domain controller architecture discussed in Chapter 2. An on-board tester with a respective functionality can perform the installation process in parallel for ECUs in the different 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 possible to achieve a speed increase of 300 Figure 2: Parallel updating in domain controller archtitecture High speed backbone On-board Tester ECU ECU ECU ECU Domain network... ECU Domain network Domain network Domain network ECU ECU ECU

9 5 PARALLEL UPDATING OF ECUS IN THE SAME DOAMIN UTLIZING INTERNAL PROCESSING TIME 9 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 recommended 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 While the bus required transmit the update data to the ECUs is a shared resource, processing will be performed independently by the ECUs. This can be utilized in order to parallelize the update of the ECUs withiin one domain (see Figure 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- gorithms. First, a simple round-robin algorithm that transmits the next block of data to the ECUs based on a fixed order. Second, if the next ECU in the round robin 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 investigation below, we have assumed a network with two each of these ECUs in order 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 Figure 3: Parallel updating of ECUs in the same domain Bus transmission ECU1 Bus transmission ECU2 Processing ECU1 Processing ECU2 On-board Tester Sequential flashing t ECU1 Domain network ECU2 ECU3 Bus transmission Processing ECU1 Parallel flashing t... Processing ECU2 Speed increase

10 10 6 Parallel updating of ECUs in the same domain using transmission time (four ECUs with profile ECU1) or the other way around (four ECUs with profile ECU2). The results for the different 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 because the gaps in the bus transmission can be further utilized. As with the current introduction of faster bus systems the processing time will increasingly become the limiting factor (see [2]) parallelization becomes even more important. 5.2 Requirements A VUM component that has the functionality to coordinate the execution of the flashing process for different BLs in parallel. Parallel communication streams need to be considered in the communication 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). Parallel updating of ECUs in one domain No optimization Round robin Optimized Four ECUs with mixed profile (two of each min (64 %) 5.11 min (68 %) ECUs Four ECUs with processing time longer than min (74 %) 4.38 min (78 %) transfer time Four ECUs with transfer time longer than min (68 %) 3.82 min (68 %) processing time 6 Parallel updating of ECUs in the same domain using parallel connections Figure 4: Parallel updating of ECUs in the same domain using parallel connections Bus transmission ECU1 Processing ECU1 Bus transmission ECU2 Processing ECU2 On-board Tester Sequential flashing t ECU1 Domain network ECU2 ECU3 Bus transmission Processing ECU1 Parallel flashing t... Processing ECU2 Speed increase

11 7 IMRPOVEMENT POTENTIAL BY SORTING THE UPDATES 11 In the previous two scenarios, we have assumed that only one transmission in a domain s bus system can be performed at a In the previous two scenarios, we have assumed that only one transmission in a domain 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 potential for parallelization by also transmitting 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 example throughout this section. 6.1 Improvement potential 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 implemented (see Section 3). The results are shown below for the same scenarios used in the previous chapter. We see that the improvements are further increased, especially when transfer time is longer than processing time (from 68 to 72 percent). 6.2 Requirements A VUM component that has the functionality to coordinate the execution of the flashing process for different ECUs in parallel. 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 recommended 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). The improvement potential for the different scenarios through parallel connections A gateway architecture in the domain controllers that has the possibility to Parallel updating of ECUs in one domain No optimization Round robin Optimized Four ECUs with mixed profile (two of each ECUs) Four ECUs with processing time longer than transfer time Four ECUs with transfer time longer than processing time min (66 %) 4.52 min (72 %) min (78 %) 4.40 min (78 %) min (71 %) 3.33 min (72 %) 7 Improvement Potential by Sorting the Updates Obviously, there is an upper limit to the number of updates that can be performed in parallel. In the best case, this limit is reached when the whole bandwidth 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 optimum threshold of parallel updates. It is expected that adding another update to be processed in parallel will require additional 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, alternating with the ECU profiles ECU1 and ECU2 described in Section 2 (starting with ECU1). With this simulation we achieve a threshold level for parallel updates as follows (assuming a 500 kbd CAN:) Round-robin algorithm noninterleaved: five ECUs Optimized algorithm non-interleaved: three ECUs Round robin algorithm interleaved: five ECUs

12 12 8 Summary # of ECU1 # of ECU2 Threshold Max. update time Min. update time Difference min 5.00 min 10 % min 6.40 min 27 % min 5.91 min 20 % min 6.38 min 19 % 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 the optimized non-interleaved algorithm to simplify the evaluation. These results show that the update order has an influence on the possible performance 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 roundrobin 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 functionality to coordinate the execution of the flashing process for different ECUs in parallel. The BL of the ECUs does not need to be changed 8 Summary In this white paper, we have described different mechanisms for speeding up the update time for an over-the-air vehicle update. These mechanisms are most effective when multiple ECUs have to be updated at the same time. We have summarized the results for different numbers 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 than the transfer time. Here, the potential for fast update mode is not as big (21 percent). However, the potential for parallelization is greater, and is already at 86 percent with eight ECUs in two domains. In other words, we can update eight ECUs using parallelization within almost the same amount of time as only one ECU

13 8 SUMMARY 13 No of ECU No of domains w/o optimizations (STmin = 300µs) Fast update mode (STmin = 0) Fast update mode & parallel updating min 3.94 min (21 %) 3.94 min (21 %) min 7.78 min (21 %) 3.94 min (61 %) min min (21 %) 4.7 min (77 %) min 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. Furthermore, the potential for mechanisms for parallel updating are increasing with the number of ECUs. Therefore, we are convinced 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 mechanisms like compression or delta updates. However, unlike those the mechanisms we described in this paper only require changes in the s 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 min 1.89 min (36 %) 1.89 min (36 %) min 3.78 min (36 %) 1.89 min (68 %) min 7.57 min (36 %) 4.7 min (77 %) min 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 different 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 standalone or integrated into FOTA backend solution from Bosch

14 ETAS Locations Worldwide Germany Stuttgart (Headquarter) Brazil São Bernardo do Campo Canada Kitchener France Saint-Ouen United Kingdom Derby York USA Ann Arbor India Bangalore Pune Italy Turin Japan Utsunomiya Yokohama Korea Seongnam-si ETAS-PGA/MKC2_LRN/01_2017 ETAS GmbH Borsigstraße Stuttgart, Germany Phone P.R. China Beijing Changchun Chongqing Guangzhou Shanghai Wuhan Sweden Gothenburg