Design and Implementation of a Bootloader in the ... - IEEE Xplore

2017 IEEE Conference on Technologies for Sustainability (SusTech)

Design and Implementation of a Bootloader in the Context of Intelligent Vehicle Systems Daniel Bogdan Continental Automotive Romania Timisoara, Romania [email protected]

Razvan Bogdan, Mircea Popa Department of Computer and Information Technology University Politehnica of Timisoara Timisoara, Romania [email protected], [email protected]

Abstract— Due to the growth of electronic complexity inside an intelligent vehicle system, improved diagnosis and reprogramming methods are currently researched and tested. In this context, a flash bootloader is the core of such approaches because it verifies the software’s validity at each engine start and waits for an external reprogramming request. Further on, it offers the possibility of ECU reprograming inside the communication network of the car. This paper is presenting the steps needed to obtain a flash bootloader for an intelligent vehicle system and also offers insights into the performance of using such an application. Keywords— Renesas; bootloader; automotive industry; Unified Diagnostic Services

I.

PREMISE

As the current urban population is increasing, the number of cars present in the cities turns out to be the major factor which contributes to the problem of traffic congestion and carbon emissions. More than that, traffic induced air pollution is one of the key factors contributing to different illnesses in most of the cities. This comes with a demand on the automotive industry to design and later on manufacture lowimpact, environmentally responsible, fuel-efficient and sustainable vehicles [1], [2]. Intelligent Transportation Systems (ITS) has proven to be an effective sustainability tool due to the offered results in terms of reducing carbon emissions and lowering fuel consumption [3]. One of the strategies proposed to reduce vehicle emissions is by driving less [4]. Therefore different techniques are being researched in order to lower the driving time, but also carbon emissions. Interesting numbers related to this are presented in [5] where it can be noted that, only in the United States of America, 38 hours is the amount of extra hours the average commuter spent traveling during the peak periods in 2011, while in 1982 this value was only 16 hours.

978-1-5386-0452-6/17/$31.00 ©2017 IEEE

In order to decrease the driving time, one of the researched techniques is that of the software updating of the Electronic Control Units (ECUs). There are several approaches to this challenge [6], but two of them are most promising: over the air reprogramming (OTA) [7], [8] and delta flashing of the ECU. If the first solution is mostly adopted with care due to the security and safety issues that are being raised [9], the second one has been offered and implemented as an alternative to the existing OTA [6]. Such solutions rely on the flash bootloader concept. This is an application capable of updating the entire ECU by receiving standard reprogramming commands via the CAN bus by means of the Unified Diagnostic Services (UDS) protocol [10]. The growth of electronic circuits inside a car has transformed the maintenance process, now requiring improved diagnosis methods and reprogramming to exactly find any flaw. A flash bootloader verifies the validity of the applications software at every start and looks for external reprogramming requests. The purpose of this software is to reprogram the ECU, by downloading on the microcontrollers’ memory a new version of the application, replacing the older one. With the decrease of the number of cycles in the production of an automobile, the need to efficiently reprogram grows in the case of detecting a software with defects, after it has been sold. It can be corrected by replacing the respective software with an improved one. This process should be realized in a sustainable fashion, meaning requiring less driving time to the specialized stations. Thus the development of the reprogramability functionality and diagnosis inside of an ECU becomes an important part of the ensemble of the whole system development in the case of ITS. From the ECU’s network inside the car, the most important one regarding user’s interaction is the dashboard. The aim of this paper is to present the process of building a flash bootloader application that respects the ISO standards [10], [11], based on the UDS protocol. Different other approaches have been offered in the literature regarding the


construction of bootloaders. In this regard, it should be notice [12] where the design is targeting ARM microcontrollers by using S3C2440 development board and its starting mode. In [13] it is presented the bootloader and debugger architectures that are designed for an NoC-based Multiprocessor System OnChip (MPSoC), while in [14] the automated testing of Bootloader on the target DSP platform is detailed.

ŽŽƚDĂŶĂŐĞƌ

II.

ƉƉůŝĐĂƚŝŽŶ ^ŽĨƚǁĂƌĞ

&ůĂƐŚ>ŽĂĚĞƌ

Our approach is based on the JCP2011 development platform, while the used hardware is a dashboard instrument with a microcontroller produced by RENESAS (ȝPD70F3537). This comes equipped with an internal flash memory of 3 MB and a RAM of 256 KB and an external flash memory of 8 MB. The used EEPROM memory is not localized on an external memory chip, but it is emulated in the internal flash memory of the microcontroller. Different performance measurements have been conducted and offered in order to make it further clear what kind of reprogramming method should be adopted according to the intelligent vehicle project.

Z^d

Figure 2. Architecture of the flash bootloader

PROCESS

A. General Architecture The flash bootloader is an implementation of the diagnosis functionality that takes care of the software actualization of the dashboard instrument through a UDS protocol. The diagnosis part of the software is represented through a set of services that the software has to recognize, verify and execute. The diagnosis part of the flash bootloader supports a minimum set of commands from the entire protocol. These are related only to the reprogramming part, the rest being supported by the application. The software system that is located on a dashboard instrument is separated in flash bootloader and the application. From a software standpoint, the flash bootloader can be divided into two components: boot manager and flashloader. In Figure 1 is presented the system’s architecture. The RESET bloc is not a separate part of the system, but is being illustrated in this way due to the fact that the access to the Boot Manager (either in the application of flash bootloader) takes places through a reset. The Boot Manager is the flash bootloader’s component that takes care of the starting and activation of the appropriate software, being localized in a protected flash area. Therefore the boot manager is the one which starts first after a reset and it will decide if the application will be started (Figure 2). B. The flashloader There are two cases when the flashloader is active. First of all, the software application is invalid: at start-up sequence, boot manager check if the application is valid. Secondly, the reprogramming request appears: the board instrument runs normally the software application.

Figure 1. The Boot Manager concept

The module has direct access to the microcontroller pins connected at CAN transceiver. •

FTP (Flashloader Transport Protocol): It can be associated with the transport level from OSI model. This module receives the data from the CAN driver, wraps them after ISO standards [10], [11] and transmits them to the next level.

•

FDPI (Flash Diagnostic Protocol Interface): It can be associated with presentation level from OSI model.

•

FDBLIB (Flash Diagnostic Library): It can be considered as being the application level even if it contains elements of presentation level. In this module, the UDS protocol is implemented, but also the debug services. This module receives the data from FDPI and has direct access to FIOL module.

•

FIOL (Flash Input / Output Library): It builds an abstracting access to different memories.

The flashloader architecture is presented in Figure 3, being formed by the following components: •

FCAN (Flashloader CAN driver): It is the CAN driver that can be associated with the data link level from the Open System Interconnection (OSI) model. This model handle the data transport on CAN interface.


The UDS communication services are implemented according to the suggestions from [10] and [11]. The most used services of the UDS protocol, through which is accomplished the CAN communication, are presented in Table I and will be realized in the FDLIB module. The services mentioned in Table I are some of the services offered by the UDS protocol. But these services are used for reprogramming the board tool, so they are the only services used by the flash bootloader. The messages from CAN bus are divided into two categories from the point of view of the protocol: request and response. In the particular case of a flash bootloader, the request comes from the programming tool (client-side), and the response is given by the flash bootloader (server-side). D. The reprogramming part Reprogramming the board tool can be divided into 3 stages: pre-programming (preparing to program), execution of programming and post-programming.

Figure 3. Flashloader architecture

•

FSL, EEPROM, ESFLD: Are the drivers for flash memory and EEPROM. In this way, FIOL can directly access all of the drivers.

C. The UDS implementation The most widespread communication protocol in the automotive industry is the Unified Diagnostic Services (UDS) defined in [10]. TABLE I.

THE MOST USED SERVICES OF THE UDS PROTOCOL (ADAPTED FROM [10])

Name of the diagnosis service

Value of service ID (hex)

Supported subfunction

Supported subfunction

Session control

10

Yes

Yes

Reset

11

Yes

Yes

Security Access

27

Yes

Yes

Communication Control

28

Yes

Yes

Presence of Tester

3E

Yes

Yes

DTC Control

85

Yes

Yes

Data Read by Identifier

22

Yes

No

Data Write by Identifier

2E

Yes

No

Routine Control

31

Yes

Yes

At the beginning of the pre-programming cycle, the ECU is in the Default session. The client (the programming tool) sends a functional message (all the ECUs receive it) in order to get to the extended session. The client then sends a functional request to stop registering the errors and determines the ECU’s identification data. This step is optional, but it is recommended to be offered to the client. In the end, the client sends a functional request to stop the communication between the ECUs. These steps are presented in Figure 3.

Download Request

34

No

No

The programming part is formed by the following steps:

Data Transfer

36

No

No

Exit Transfer Request

37

No

No

Figure 4. Preprogramming steps

1) The client requires that the ECU enters the preprogramming session. In this moment, the application executes a reset, and the flash bootloader is on.


2) The client logs in. Without a correct validation of this authentication, neither the client, nor the ECU can continue the reprogramming session.

application and the new software will be turned on. The flash bootloader will turn on again, waiting for a new reprogramming trial.

3) This step helps in the storage of information about who and when has programmed the ECU.

For the post-programming sequence, the following steps are implemented:

4) This step is optional and it is executed only if the flash driver for deletion is not a component of the flash bootloader. In this case, the driver must be downloaded. This step is called software interlock 1 and it helps increase the security.

1) The client sends to the ECU the functional message to begin inter-ECU communication.

5) If the flash driver for deletion was downloaded, it must be verified.

3) The client sends a request to jump to default session.

2) The client sends to the ECU the functional message to begin error registration.

6) At this step, the deletion of the memory blocks about to be reprogrammed is executed. Right before the executing the deletion, the flash bootloader must invalidate the application so that if the deletion fails, turning on the application is not possible (it cannot be compromised). 7) Similar to step 4), the flash driver for writing must be downloaded. It is also possible that the driver is downloaded in a single step (the deletion and the writing). This step is called software interlock 2 and its purpose is to increase the security. 8) If the driver has been downloaded in the previous step, it must be verified. 9) In this step, the sequence of the 3 services (0x34, 0x36 and 0x37) is used to write data in the memory (internal flash, external flash, RAM, EEPROM, etc.). The following steps must be tackled: a)

The client sends the 0x34 service for the first segment.

b) The flash bootloader responds. c)

The client sends the data through the 0x36 service.

d) The flash bootloader responds. e)

The client repeats the 3rd step until the segment described by the 0x34 service will have been fully sent.

f)

The client sends the 0x37 service to terminate the current data transmission.

g) The flash bootloader responds. Steps 1-7 are repeated as long as there are segments to download. 10) At this step the integrity of the downloaded data is being checked. If the data is correct, then the downloaded block must be validated. Only at this point, a block can be set as valid again, being invalidated before the deletion. 11) After checking the integrity of the data, the client must send the reset service, no matter the result of the verification. If the reprogramming phase was a success, the flash bootloader will jump to turn on

Figure 5. Post-programming sequence

In the case the reprogramming failed for some reason (incorrectly transmitted data, power failure, communication failure etc.), the flash bootloader must be capable to respond and to treat the services described by the pre-programming sequence and the ones described by the post-programming sequence (normally addressed to the application). III.

OUTCOME

The performance of a programming procedure is given mostly by the speed of the data transmission on the CAN interface. The transmission speed is 500 Kbs, on a HighSpeed channel, which means that 1 bit is transmitted on the CAN in 2 ȝs. But a CAN message is at least 108 bits long. Therefore a CAN frame can be transmitted in 216 ȝs at best. Due to the transmission method and to the one of representing the bits on the CAN bus (Non Return to Zero), bits of stuffing are sent to the bus and they cause delays. Thus, an average number of 130 bits is transmitted in a CAN message, leading to the growth of the transmission duration to 230ȝs per frame. Out of those 130 bits, only 64 are actual data through which the client and the server communicate. We can approximate that 50% of the transmitted data is useful. Therefore, each useful bit of data requires 4 ȝs. It can be calculated that for 1 KB of data


transmitted on CAN, we need more than 4ms, and for one MB, we need approximately 4.2 s. The obtained value from above can be considered acceptable, but the problem appears at packing data in the UDS protocol. Out of the 8 bits of data entering a CAN message, maximum 7 can be data sent to be reprogrammed. The delays which appear as consequence of waiting for the flow control frames and also as consequence of sending multiple download request services for the segmented data are also added. At the same time, we need to take into account also the services which do not write data, which are used to obtain information and to set pre-conditions required by the data download services. Thus, a complete sequence for reprogramming 8 MB of data written in the external memory and 2 MB of data written in the internal flash memory of the microcontroller takes approximately 5 minutes. In those minutes there is included the necessary time for deleting the entire programmed memory (approximately 40 s). The minimum separation time was 0, and the block size was 48. The reception buffer size is 240 bytes. Programming the same data with a baud rate of 83.333 Kbs, using a Low Speed CAN channel takes up to 15 minutes. If we add a minimum separation time of 5ms, the reprogramming duration grows to 45 minutes. It can be concluded that in the duration of a reprogramming the priority is the CAN bus baud rate, but also the minimum separation time as well as the block size play important roles. An increase in the minimum separation time from 0 ms to 5 ms, lead in the second case to an increase of the overall programming time of 30 minute. Therefore, we need to find a solution which is optimal regarding the speed, the space and the costs. An increased block size implies an internal buffer of big size, and a separation time of 0 ms implies the nonexistence of a gateway between the client and the server, which sometimes is proven to be impossible. IV.

CONCLUSION

A flash bootloader is the core of those techniques meant to decrease the driving time (like OTA systems), hence being part of solutions designed to obtaining sustainability in ITS. As no way of testing can guarantee the absence of bugs from a system, the need for reprogramming grows at the same time as the growth of that system’s size. Thus, the necessity of an integrated flash bootloader embedded in the entire system, capable to reprogram the host ECU in an effective way, proves to be very important. The obtained timing values can be considered acceptable under the conditions of the presented hardware. The growth of the display which is attached to a board tool, but also of other attached hardware components leads to the necessity to increase the memory for the storage of the needed resources (pictures). It is possible to reach memories which exceed 2 GB in dimension. Even if developing a flash bootloader implies big costs of the project, as well as high complexity, having one might prove to be the solution of unpredictable problems (error of the application software, detected post-production). From the point of view of sustainability, this solution contributes by removing the need to travel to specialized

centers to do software updates and also by installing updates with removed software bugs. This causes more efficient driving with a decreased impact on environment and traffic.

ACKNOWLEDGMENT We would like to acknowledge the support received from Continental Automotive Romania, part of Continental AG. REFERENCES [1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

A. O. Kotb, Yao-chun Shen, Yi Huang, “Smart Parking Guidance, Monitoring and Reservations: A Review”, IEEE Intelligent Transportation Systems Magazine, vol. 9, no. 2, pp. 6 – 16, 2017. D. JasiĔski, J. Meredith and K. Kirwan, “A comprehensive framework for automotive sustainability assessment”, Journal of Cleaner Production, vol. 135, pp. 1034-1044, 2016. Lee L. Tupper , M. A. Chowdhury , L. Klotz and R. N. Fries, “Measuring Sustainability: How Traffic Incident Management through Intelligent Transportation Systems has Greater Energy and Environmental Benefits than Common Construction-Phase Strategies for Green Roadways”, International Journal of Sustainable Transportation, vol. 6, no. 5, pp. 282-297, DOI: 10.1080/15568318.2011.597910, 2012. V.S. Harilakshmi, P. Arockia Jansi Rani, “Intelligent vehicle counter - a road to sustainable development and pollution prevention (P2)”, Proceedings of the IEEE International Conference on Energy Efficient Technologies for Sustainability (ICEETS), 2016. Intelligent Car Coalition, “Intelligent Vehicles & Sustainability: By The Numbers”, http://intelligentcarcoalition.org/wpcontent/uploads/2014/05/Sustainability_By-The-Numbers_Final.pdf, accessed: 30.06.2017. D. Bogdan, R. Bogdan and M. Popa, “Delta flashing of an ECU in the automotive industry”, Proceedings of the IEEE 11th International Symposium on Applied Computational Intelligence and Informatics (SACI), 2016. N. Dennis, S. Lei and N. Tatsuo, "A Framework for Self-Verification of Firmware Updates over the Air in Vehicle ECUs," in Proceedings of the IEEE GLOBECOM Workshops, pp. 1 – 5, 2008. K. Ryozo, M. Satoshi, M. Mitsuhiro, N. Masayuki and K. Satoshi, "A New Method of Fast Compression of Program Code for OTA Updates in Consumer Devices," IEEE Transactions on Consumer Electronics, vol. 55, pp. 812 – 817, 2009. D. K. Nilsson and U. E. Larson, “Security OTA Secure Firmware Updates over the Air in Intelligent Vehicles,” Proceedings of IEEE International Conference on the Communications Workshops, 2008. ISO 14229-3, "Road vehicles - Unified diagnostic services," ISO, 2012. [Online]. Available: http://www.iso.org/iso/home/store/ catalogue_ics/catalogue_detail_ics.htm?csnumber=55284. [Accessed 10.04.2017]. ISO 15765-2, "Road vehicles - Diagnostic communication over Controller Area Network (DoCAN)," ISO, 2011. [Online]. Available: https://www.iso.org/obp/ui/#iso:std:iso:15765:-2:ed-2:v1:en. [Accessed 10.04.2017]. C. Sha and Z.-Y. Lin, “Design Optimization and Implementation of Bootloader in Embedded System Development,” Proceedings of the International Conference on Computer Science and Applications (CSA), 2015. D. Hartono, M. S. Ng and Z. N. Lim, “A scalable bootloader and debugger design for an NoC-based multi-processor SoC,”, Proceedings of the 3rd International Conference on New Media (CONMEDIA), 2015. J. Kriþkoviü, Ĉ. Miljkoviü and M. Ĉukiü, “Automation testing of Bootloader for target DSP platform,” Proceedings of the 23rd Telecommunications Forum (TELFOR), 2015.