Design and implementation of firmware over the air model for car lighting and collision avoidance systems

HO CHI MINH CITY UNIVERSITY OF TECHNOLOGY AND EDUCATIONGRADUATION THESIS MAJOR: COMPUTER ENGINEERING TECHNOLOGY INSTRUCTOR: DO DUY TAN STUDENT: CHAU THANH DAT DINH THE ANH DESIGN AND IMP

HO CHI MINH CITY UNIVERSITY OF TECHNOLOGY AND EDUCATION

GRADUATION THESIS MAJOR: COMPUTER ENGINEERING TECHNOLOGY

INSTRUCTOR: DO DUY TAN STUDENT: CHAU THANH DAT

DINH THE ANH

DESIGN AND IMPLEMENTATION OF FIRMWARE OVER THE AIR MODEL FOR CAR LIGHTING AND COLLISION

AVOIDANCE SYSTEMS

FACULTY OF ELECTRICAL AND ELECTRONICS ENGINEERING

DEPARTMENT OF COMPUTER AND COMMUNICATIONS ENGINEERING

-o0o -

GRADUATE THESIS

DESIGN AND IMPLEMENTATION OF FIRMWARE OVER THE AIR MODEL FOR CAR LIGHTING AND COLLISION AVOIDANCE SYSTEMS

Major: Computer Engineering Technology

Student: CHAU THANH DAT

Student ID: 20119332 DINH THE DANH Student ID: 20119327

Ho Chi Minh City , June 2024

FACULTY OF ELECTRICAL AND ELECTRONICS ENGINEERING

DEPARTMENT OF COMPUTER AND COMMUNICATIONS ENGINEERING

GRADUATE THESIS

DESIGN AND IMPLEMENTATION OF FIRMWARE OVER THE AIR MODEL FOR CAR LIGHTING AND COLLISION AVOIDANCE SYSTEMS

Major: Computer Engineering Technology

Student: CHAU THANH DAT

Student ID: 20119332 DINH THE DANH Student ID: 20119327

Advisor: DO DUY TAN, PhD

Ho Chi Minh City , June 2024

PROJECT ASSIGNMENT

Student name: Chau Thanh Dat Student ID: 20119332

Student name: Dinh The Danh Student ID: 20119327

Major: Computer Engineering technology Class: 201192A

Advisor: PhD Do Duy Tan Phone number: 0369393615 Date of assignment: 20/2/2024 Date of submission: 3/6/2024 Project title: Design and Implementation firmware over the air for car lighting and colision avoidance system

Initial material provided by the advisor:

- Books and reports related to Firmware-over-the-air models in the automotive industry

Content of the project:

- Design and implementation of Firmware-over-the-air system for vehicle lighting and collision avoidance systems

Final product:

- Report documents explaining the project

- Full demo product FOTA system

ADVISOR’S EVALUATION SHEET

KHOA ĐIỆN – ĐIỆN TỬ

2 Tên sinh viên: Châu Thành Đạt MSSV: 20119332

Tên sinh viên: Đinh Thế Danh MSSV: 20119327

3 GVHD: TS Đỗ Duy Tân

4 Hội đồng bảo vệ 5, phòng A3-308, ngày 25 tháng 6 năm 2024

5 Giải trình chỉnh sửa báo cáo đồ án tốt nghiệp:

TT Nội dung góp ý của Hội

đồng Kết quả chỉnh sửa, bổ sung Ghi chú

1 Sửa trích dẫn tài liệu tham

khảo

Đã thực hiện trích dẫn tài liệu tham khảo

2 Chỉnh sửa chinh tả, lưu đồ

giải thuật, sửa công thức

Đã thực hiện chỉnh sửa các lỗi chính tả ở tất cả các chương

Đã thực hiện chỉnh sửa các lưu

đồ giải thuật ở chương 3, Hình 3.15, 3.16, 3.20, 3.24, 3.25

Đã sửa công thức 3.1, trang 60

Xác nhận của GVHD

(Ký họ và tên)

Nhóm thực hiện báo cáo

(Ký họ và tên)

ACKNOWLEDGEMENTS

We, the project team, want to express our deepest gratitude to our guiding lecturer, Do Duy Tan, PhD from the Department of Computer Engineering and Telecommunications His commitment, unwavering support, and insightful guidance on crucial knowledge provided an ideal environment for our project's success With his invaluable assistance, we were able to see the project through to completion

We also thank our families and friends who stood by our side and offered their unwavering support throughout this journey Their genuine advice and constant encouragement proved instrumental in helping us overcome challenges and achieve the best possible outcome for this project We couldn't have done it without them

We express our sincere appreciation to Dr Tan and wish him continued success and good health

The project team

Chau Thanh Dat

Dinh The Danh

DECLARATION OF AUTHORSHIP

We now declare that this thesis is our work and has been conducted under the guidance and supervision of Do Duy Tan, PhD We affirm that the content and findings presented in this thesis are our own and do not violate any research ethics The data and figures presented in this thesis are for analysis, comments, and evaluations from various sources All sources have been duly acknowledged and cited in the references section

We take full responsibility for any plagiarism or misrepresentation detected in this thesis

ABSTRACT

Modern car lighting systems and collision avoidance systems play a critical role

in ensuring road safety and visibility However, updating firmware using traditional diagnostic methods can be inconvenient and time-consuming for both users and the company's workforce To address this issue, a Firmware Over-the-Air (FOTA) system has been developed This system allows for remote updates and enhances safety, functionality, and user experience

The FOTA system comprises a Telematics Unit responsible for identifying new firmware updates on the Cloud, downloading them, and sending them to the Gateway The Gateway, in turn, receives the data and sends the firmware to the node's bootloader, which requires updating and allows the firmware to be reprogrammed This comprehensive FOTA system offers a reliable, cost-effective, and convenient solution for users, long-term support for customers, ease of maintenance, and future improvements

TABLE OF CONTENTS

ACKNOWLEDGEMENTS iii

DECLARATION OF AUTHORSHIP iv

ABSTRACT v

TABLE OF CONTENTS vi

LIST OF FIGURE x

LIST OF TABLES xii

ABBREVIATIONS xiii

CHAPTER 1 : OVERVIEW 1

1.1 PROBLEM STATEMENT 1

1.2 RESEARCH OBJECTIVES 2

1.3 RESEARCH SCOPE 2

1.4 RESEARCH METHODS 2

1.5 RESEARCH LIMITS 2

1.6 STRUCTURE OF THESIS 3

CHAPTER 2: LITERATURE REVIEW 5

2.1 STM32F103C8T6 5

2.2 ESP32 7

2.3 FOTA 10

2.3.1 Overview FOTA 10

2.3.2 FOTA Benefits 11

2.3.3 FOTA Requirements 12

2.4 BOOTING PROCESS OF ARM COTEX-M3 12

2.4.1 Vector table of ARM COTEX-M3 12

2.4.2 The startup process of the MCU 14

2.4.3 The startup process of the MCU with Bootloader 15

2.4.4 Reprogram MCU with Bootloader 16

2.5 UDS STANDARD FOR CAN BUS 17

2.6 AUTOSAR 18

2.6.1 Overview AUTOSAR 18

2.6.2 AUTOSAR Layer 19

2.7 CAN COMMUNICATIONS PROTOCOL 21

2.7.1 CAN Introduction 21

2.7.2 CAN Network Message Format 21

2.8 I2C COMMUNICATIONS PROTOCOL 23

2.8.1 I2C Introduction 23

2.8.2 I2C transfer operation 23

2.9 UART COMMUNICATIONS PROTOCOL 25

2.10 FIREBASE DATABASE 27

2.11 SECURITY WITH AES ALGORITHM 28

2.11.1 Encryption Algorithms 28

2.11.2 AES Algorithm 29

2.11.3 AES Encryption 29

2.11.4 AES Cipher block chaining (CBC) mode 31

2.11.5 AES Decryption 32

CHAPTER 3: SYSTEM DESIGN 33

3.1 SYSTEM REQUIREMENTS 33

3.2 SYSTEM BLOCK DIAGRAM AND SYSTEM FLOWCHART 34

3.3 HARDWARE DESIGN AND IMPLEMENT 36

3.3.1 Telecommunication Unit Hardware Design 36

3.3.2 Gateway Unit Hardware Design 38

3.3.3 Lighting System Hardware Design 43

3.3.4 Collision Avoidance System Hardware Design 46

3.4 SOFTWARE DESIGN AND IMPLEMENT 50

3.4.1 Telecommunication Unit Software Design 50

3.4.1.1 Telecommunication Unit Tasks 50

3.4.1.2 Telecommunication Unit Flowchart 50

3.4.1.3 Telecommunication Unit State Machine 52

3.4.1.4 Firebase Connection 53

3.4.2 Graphic User Interface (GUI) 53

3.4.3 Gateway Software Design 54

3.4.3.1 Gateway Tasks 54

3.4.3.2 Gateway Flowchart 55

3.4.3.3 RTE in Gateway 56

3.4.3.4 Gateway State Machine 56

3.4.3.5 Communication Sequence 57

3.4.3.6 Receive Module 59

3.4.3.7 Encrypt Module 61

3.4.3.8 Transmit Module 61

3.4.3.9 User Interface Module 63

3.4.4 Bootloader 65

3.4.4.1 Bootloader Requirement 65

3.4.4.2 Bootloader Flash Setup 65

3.4.4.3 Bootloader Behavior 68

3.4.4.4 Application Behavior 69

3.4.5 Lighting System Software Design 70

3.4.5.1 Lighting System Tasks 70

3.4.5.2 Lighting System Flowchart 71

3.4.6 Collision Avoidance System Software Design 71

3.4.6.1 Collision Avoidance System Tasks 71

3.4.6.2 Collision Avoidance System Flowchart 72

CHAPTER 4: RESULTS AND EVALUATIONS 74

4.1 REQUIREMENTS OF RESULT 74

4.2 GATEWAY UI SEQUENCE 75

4.3 COMMUNICATION SEQUENCE 77

4.3.1 UART 77

4.3.2 CAN 79

4.4 TEST CASE 80

4.4.1 Lighting System Test Case 81

4.4.2 Collision Avoidance System Test Case 83

4.4.3 Update Fail Handle Test Case 84

4.4.3.1 Firmware Invalid 84

4.4.3.2 FOTA process interruption 85

4.4.3.3 Main Firmware and Backup Firmware are corrupted 86

4.5 TEST CASE EVALUATIONS 86

CHAPTER 5: CONCLUSION 88

5.1 CONCLUSION 88

5.2 PROJECT IMPROVEMENT 89

APPENDIX 90

REFERENCES 91

LIST OF FIGURE

Figure 2-1 : ESP32 Functional Block Diagram 8

Figure 2-2 : Basic FOTA concept in automotive industry 10

Figure 2-3 : Example structure of vector table in MCU memory 13

Figure 2-4 : Structure of program in MCU memory 14

Figure 2-5 : Structure of multiple firmware in MCU memory 15

Figure 2-6 : General Bootloader Operation 16

Figure 2-7 : AUTOSAR layer 19

Figure 2-8 : RTE Example 20

Figure 2-9 : CAN Topology 21

Figure 2-10 : CAN Message Structure 22

Figure 2-11 : I2C Topology 23

Figure 2-12 : I2C Data Frame 24

Figure 2-13 : UART Topology 25

Figure 2-14 : UART Data Frame 26

Figure 2-15 : Firebase 27

Figure 2-16 : Symmetric Encryption 29

Figure 2-17 : AES Sub Bytes Step 30

Figure 2-18 : AES Shift Row Step 30

Figure 2-19 : AES Mixing Step 30

Figure 2-20 : AES Add Round Key Step 31

Figure 2-21 : AES Cipher Block Chaining Mode 31

Figure 2-22 : AES Decryption 32

Figure 3-1 : System Block Diagram 34

Figure 3-2 : FOTA process flowchart 35

Figure 3-3 : Telecommunication Unit Diagram 37

Figure 3-4 : Gateway Unit Diagram 38

Figure 3-5 : Button Image 40

Figure 3-6 : Oled SSD1306 41

Figure 3-7 : SN65HVD230 CAN Board 42

Figure 3-8 : Lighting System Diagram 43

Figure 3-9 : DIP Switch 44

Figure 3-10 : Led 5mm 45

Figure 3-11 : Collision Avoidance System Diagram 47

Figure 3-12 : HC-SR04 Image 48

Figure 3-13 : Mechanism of HC-SR04 48

Figure 3-14 : Buzzer Image 49

Figure 3-15 : Telecommunication Unit Flowchart 51

Figure 3-16 : Telecommunication Unit State Machine 52

Figure 3-17 : Firebase Realtime Database 53

Figure 3-18 : Firebase Storage 53

Figure 3-20 : Gateway Flowchart 55

Figure 3-21 : RTE in Gateway 56

Figure 3-22 : Gateway System States 57

Figure 3-23 : Gateway Communication Sequence 58

Figure 3-24 : Receive Module Flowchart 60

Figure 3-25 : Encrypt Module Flowchart 61

Figure 3-26 : Transmit Module Flowchart 62

Figure 3-27 : User Interface Module Flowchart 63

Figure 3-28 : Flash module organization of stm32f103c8t6 66

Figure 3-29 : Flash memory arrangment 66

Figure 3-30 : Flag page design example 67

Figure 3-31 : Bootloader Flowchart 68

Figure 3-32 : Bootloader Application Flowchart 70

Figure 3-33 : Lighting System Flowchart 71

Figure 3-34 : Collision Avoidance System Flowchart 72

Figure 3-35 : Time Diagram of HC_SR04 73

Figure 4-1 : Completed FOTA System 74

Figure 4-2 : UI Idle State 75

Figure 4-3 : UI NewUpdate State 75

Figure 4-4 : UI Download State 76

Figure 4-5 : UI Install State 76

Figure 4-6 : UI Finish State 76

Figure 4-7 : UART Send Header 77

Figure 4-8 : UART Send Data Packet 78

Figure 4-9 : UART Finish Transfer Process 78

Figure 4-10 : CAN Transmit Data 79

Figure 4-11 : CAN Finish Transmit 80

Figure 4-12 : Lighting System Estimate Update Time 82

Figure 4-13 : Lighting System 82

Figure 4-14 : Active Flag in Lighting System 82

Figure 4-15 : Collision Avoidance System Estimate Update Time 83

Figure 4-16 : Collision Avoidance System 83

Figure 4-17 : Active Flag in Collision Avoidance System 84

Figure 4-18 :The Manipulated Firmware 84

Figure 4-19 : Flag region in case MCU’s firmware was manipulated 85

Figure 4-20 : Flag region in case FOTA process interruption 85

Figure 4-21 : Flag region in case both firmware are invalid 86

LIST OF TABLES

Table 2-1 : Table Pinout of STM32 6

Table 2-2 : Vector table of ARM Cortex-M3 13

Table 2-3 : Boot mode table 14

Table 2-4 : UDS Code Table 18

Table 3-1 : The connection table Telecommunication Unit 38

Table 3-2 : Comparison table between STM32f103x and stm32f104x 39

Table 3-3 : Push button specifications 40

Table 3-4 : Oled SSD1306 specifications 41

Table 3-5 : SN65HVD230 CAN Board specifications 42

Table 3-6 : The connection table of Gateway 42

Table 3-7 : DIP Switch specifications 45

Table 3-8 : Led 5mm specifications 45

Table 3-9 : The connection table of Lighting System 46

Table 3-10 : HC-SR04 specifications 49

Table 3-11 : Buzzer Specification 50

Table 3-12 : The connection table of Collision Avoidance System 50

Table 4-1 : Test case summary table 81

Table 4-2 : The comparison and evaluation FOTA process 87

ABBREVIATIONS

AUTOSAR AUTomotive Open System Architecture

UART Universal asynchronous receiver transmitter

Therefore, we decided to choose the graduation thesis topic “DESIGN AND IMPLEMENTATION OF FIRMWARE OVER THE AIR MODEL FOR CAR LIGHTING AND COLLISION AVOIDANCE SYSTEM” because FOTA is a potential and valuable technology Moreover, implementing it safely and reliably in

a safety-critical system such as car lighting is a significant technical challenge This topic helps us understand more about the FOTA system in the automotive industry

1.2 RESEARCH OBJECTIVES

This thesis focuses on the design and development of a safe and effective FOTA system based on existing research concepts for updating automotive MCU software using ESP32 and STM32, learning related knowledge (UART, CAN, ), analyzing potential benefits and solving associated challenges, especially adding AES security mechanisms when transferring data Finally, different test cases will evaluate the system's performance in a realistic environment

1.3 RESEARCH SCOPE

This thesis focuses on addressing the following problems:

• Set up a real-time database linked to the FOTA system and design an interface so that developers can easily upload firmware to the database

• Designing a reliable data transfer sequence from the database to the MCU that needs to be reprogrammed

• Design and implement a Bootloader to reprogram the application of the Light System and handle errors when the reprogram fails

• Design of security communication between Gateway - MCU on CAN bus

• User interface for reprogramming progress

1.4 RESEARCH METHODS

This research will employ a multi-pronged approach, utilizing:

• Literature review: A crucial step, examining existing research on FOTA technologies, UART, CAN bus, …

• System design and development: Designing the FOTA protocol, communication framework, and update management system specifically for lighting and collision avoidance systems

• Performance evaluation: Evaluating the efficiency and reliability of the FOTA system in a real-time environment

1.5 RESEARCH LIMITS

There are some limitations of this project, including:

• The Telematic Unit needs to connect with the Cloud via Wi-Fi Therefore, the operation depends on a stable Wi-Fi connection; without it, the system would not work correctly Power supply will also not be considered because there will be many MCUs in use, so we decided to use a power supply directly to the MCU

• The security of firmware should be considered in real projects as it can involve human life if hackers manipulate that firmware Because of the scope of the thesis, we will not consider that aspect of the connection between the cloud and the telematic unit; we will assume that it is already securely protected

• The thesis will not delve into the business aspects of FOTA adoption, such

as cost analysis or market potential

• Power consumption will also not be considered; we focus on the application and feasibility of the project

Chapter 2: Literature Review

In this chapter, we discuss the existing research on FOTA and provide detailed information about the components that will be used in the project, including STM32 and ESP32 We also cover the theory of the booting process on MCU ARM CORTEX, UDS standard, AUTOSAR, communication protocols such as CAN, I2C, and UART, and security in embedded systems

Chapter 3: System Design and Implementation

This chapter, System Design and Implementation, is where the theoretical

knowledge is put into practice It presents system specifications and requirements, the design for both hardware and software like the System diagram, Bootloader design, Telematic Unit, Gateway system, Collision avoidance system, and Lighting system, and explains the software flowchart Then, we discuss the implementation

Chapter 4: Results

This chapter presents the results of the researched topic through test cases and evaluation

Chapter 5: Conclusion and Future Work

This chapter summarizes the main findings, concludes, and suggests directions for future improvement

2 CHAPTER 2: LITERATURE REVIEW

In this chapter, we discuss the existing research on FOTA and provide detailed information about the components that will be used in the project, including STM32 and ESP32 We also cover the theory of the booting process on MCU ARM CORTEX, UDS standard, AUTOSAR, communication protocols such as CAN, I2C, and UART, and security in embedded systems

2.1 STM32F103C8T6

The STM32 BluePill is a compact and powerful version of the STM32 series of boards, which is considered a popular choice in the DIY and small project development communities, or basically for those who want to learn about ST microchip, ARM Cortex 32bit [1]

• Microcontroller: STM32 BluePill uses a STM32F103C8T6 chip, an ARM Cortex-M3 microcontroller with a clock speed of 72MHz The chip comes with 64KB of Flash memory, 20KB of SRAM, and 64 or 128 KB of EEPROM

• Dimensions: With dimensions of approximately 53mm x 22mm, the STM32 BluePill features a compact design that saves space in applications with size requirements

• Operating voltage: The board supports operating voltage from 2V to 3.6V, which can operate stably at 5V with the help of a USB power supply pin or VBUS battery

• Connector: STM32 BluePill usually has a mini-USB connector for loading programs and communicating with computers

• Pins: The board comes with 37 GPIO connectors, supporting many functions such as GPIO, PWM, UART, SPI, and I2C, providing flexibility with peripheral components and modules

• Other features: STM32 BluePill supports protocols such as UART, SPI, and

I2C and can interact with computers via USB It can also perform various functions such as ADC measurement and PWM and support other features depending on the specific application

• The STM32 BluePill can be programmed using software development environments such as the STM32CubeIDE or Arduino IDE using circuit boards and support libraries from the community This is a popular choice for small projects, IoT projects, and applications that require flexibility and performance

We create Table 2-1 summarizing the function of STM32 pins

Table 2-1 : Table Pinout of STM32 [1]

Power 3.3V, 5V, GND

3.3V: The output voltage is stabilized from the on-board regulator (large current operation is not recommended), can also be used to supply power to the microcontroller 5V from USB or onboard regulator: Can be used to power the onboard 3.3V regulator GND: The ground pins

Analog Pins PA0 – PA7

A total of 37 pins can be used to connect and control various components

The number pins are likely to be used to create interrupts when an event occurs

PWM

PA0 – PA3 PA6 – PA10 PB0 - PB1 PB6 – PB9

Total of 15 Pulse Width Modulation (PWM) pins are available to control pulse width and dim signals

SPI

MISO0, MOSI0, SCK0, CS0 MISO1, MOSI1, SCK1, CS0

Support Serial Peripheral Interface (SPI) communication via 2 pins

communication for connection with other devices

As the successor to the widely popular NodeMCU ESP8266, the ESP32 microcontroller brings a significant performance boost and enhanced features Manufactured by Espressif Systems, it has found extensive use in IoT, robotics, and automation applications

The ESP32 microcontroller is designed with a robust power management system, enabling it to operate in sleep mode and wake up only when necessary This energy-saving feature is a boon for battery-powered applications, potentially extending their lifespan significantly [2].

• Low-power consumption: ESP32 is designed to be low-power, making it ideal for battery-powered applications It has a power management system allows

it to operate in sleep mode and wake up only when needed, which can significantly extend battery life

• Integrated Wi-Fi and Bluetooth: ESP32 integrates Wi-Fi and Bluetooth, making it a versatile platform for various applications Wi-Fi allows ESP32

to connect to the internet, while Bluetooth allows it to connect to other devices such as smartphones, sensors, and actuators

• Powerful CPU: ESP32 is powered by a 32-bit Tensilica Xtensa LX6 microprocessor, which provides the performance needed for demanding applications, as shown in the figure below

• Large memory: ESP32 has a large amount of memory, which allows it to store data and code This makes it ideal for applications that require a lot of data storage or complex code

• Wide range of peripherals: ESP32 has a wide range of peripherals, including GPIO pins, ADC, DAC, SPI, I2C, and UART This makes it a versatile platform for various applications

Figure 2-1 : ESP32 Functional Block Diagram [2, Fig 1]

Based on the functional blocks ESP32 specification as shown in Figure 2-1: [2]

• Wireless connectivityWiFi: 150.0 Mbps data rate with HT40

• Bluetooth: BLE (Bluetooth Low Energy) and Bluetooth Classic

• Processor: Tensilica Xtensa Dual-Core 32-bit LX6 microprocessor, running

at 160 or 240 MHz

• Memory:

o ROM: 448 KB (for booting and core functions)

o SRAM: 520 KB (for data and instructions)

o RTC fast SRAM: 8 KB (for data storage and main CPU during RTC Boot from the deep-sleep mode)

o RTC slow SRAM: 8KB (for co-processor accessing during deep-sleep mode)

o eFuse: 1 Kbit (of which 256 bits are used for the system (MAC address and chip configuration) and the remaining 768 bits are reserved for customer applications, including Flash-Encryption and Chip-ID)

• Low Power: ensures that you can still use ADC conversions, for example, during deep sleep

• Peripheral Input/Output:

o Peripheral interface with DMA that includes capacitive touch

o ADCs (Analog-to-Digital Converter)

o DACs (Digital-to-Analog Converter)

o I²C (Inter-Integrated Circuit)

o UART (Universal Asynchronous Receiver/Transmitter)

o SPI (Serial Peripheral Interface)

o I²S (Integrated Interchip Sound)

o PWM (Pulse-Width Modulation)

o Security: hardware accelerators for AES and SSL/TLS

In this thesis, we will use the ESP32 DEVKIT Development Board

2.3 FOTA

2.3.1 Overview FOTA

Firmware Over The Air (FOTA) is a highly efficient technology that enables the upgrading and updating of a device's operating firmware over a network, all without the need for a direct connection to the device

Devices that support FOTA may be able to download updates from the manufacturer shortly, depending on file size and connection speed This technology saves businesses the time and money to send a technician to upgrade or update their equipment [3]

Figure 2-2 : Basic FOTA concept in automotive industry [4]

FOTA technology is a game-changer in the realm of IoT systems with a multitude of connected devices that necessitate frequent updates, especially in the automotive industry, with a concept as Figure 2-2 FOTA technology enables the remote management and updating of firmware for ECU in vehicles, leading to streamlined maintenance and ensuring that they are always equipped with the latest software improvements and security patches, thereby bolstering their efficiency and performance

• FOTA Server: Responsible for managing vehicle firmware release

• FOTA Client: Application responsible for communicating with a backend

server and updating campaign management

• FOTA Agent: Application that performs final updating of firmware for ECUs

during run-time [4]

For example, if car manufacturers wanted to update the ECUs on thousands of cars being used by customers, it would be an almost impossible task to accomplish using traditional methods, in which each car would have to be taken to the manufacturer, connecting to a computer or specialized diagnostic equipment, reprogrammed with new updates and returned to the owner, creates unnecessary costs and disrupts the user experience However, with this FOTA technology, most

of the above problems have been solved

2.3.2 FOTA Benefits

• Cost- Efficient and better-managed firmware update:

Developing car software can be a complex process involving multiple parties across different regions In such a case, performing any firmware update can be challenging, requiring many modifications and revisions Therefore, Updating over the air eases the task while reducing additional costs and time spent on multiple software/firmware updates IHS Automotive has estimated that total OEM cost savings from FOTA updates will increase to more than $35 billion by 2022 from

$2.7 billion in 2015 [5]

• Upgrade the firmware safely, continuous improvements:

Many OEMs have used online patches to fix errors in their automotive computer programs With FOTA updates, most firmware errors can be fixed by installing the latest firmware or submitting a minor fix to improve the existing firmware For instance, when a Tesla caught fire in an accident, Tesla resolved the issue by sending out an upgrade that changed the system settings Since the update, no further fires have been reported [5]

2.3.3 FOTA Requirements

• Safety:

o The firmware after downloading the ECU must be verified as the correct image for the specific MCU by using CRC, checksums, and other version compatibility releases

o Therefore, we use CRC, a strong testing mechanism to ensure the new update

is correctly installed

• Security:

o The security of the firmware is a top priority To ensure this, data is sent via

a secure protocol and encrypted It will be encrypted at the Gateway and then will be decrypted MCU before flashing the update

o Protocols used in wireless communication must be secure However the limitation of the scope of the thesis, we assume that the wireless communication is already secure, we only handle the security from the gateway transmitted through the MCU with AES-CBC-128 standard The details of this standard will be discussed later

• Reliability:

o It is important to ensure that the data transmitted from the Gateway to another MCU is correct All data must be fully transmitted before processing Therefore, a reliable communication protocol must be used

• Scalability:

o Should be designed to support a large number of embedded devices

2.4 BOOTING PROCESS OF ARM COTEX-M3

2.4.1 Vector table of ARM COTEX-M3

A vector table where we can find a list of error handlers and usable interrupts for a given ARM CORTEX microcontroller This table is defined inside the boot file for our MCU, an assembly file ending in “.s” inside our project's Core/Startup directory

Table 2-2 : Vector table of ARM Cortex-M3 [6, Tab 7.1]

This vector table (Table 2-2) is important in starting the ARM Cortex MCU, looking up errors that occur, and programming the interrupt function to work Normally, one vector table for each MCU will be shown in Figure 2-3 However, having vector tables in memory is possible, especially if you have many programs in memory Moving to different programs in memory means moving vector tables to areas of that program's memory

Figure 2-3 : Example structure of vector table in MCU memory [6, Fig 7.2]

2.4.2 The startup process of the MCU ARM COTEX-M3

The STM32 microcontroller implements a special mechanism called physical remapping to boot from memory other than the flash, including dedicated two-pin MCU sampling, BOOT0 and BOOT1 The electrical state of these pins establishes the boot start address and the source memory

Table 2-3 : Boot mode table [6, Tab 22.1]

Boot mode selection pins

x 0 Main Flash Main Flash is selected as boot space

0 1 System Memory System Memory is selected as boot space

1 1 SRAM SRAM is selected as boot space

The first row in Table 2-3 corresponds to the most common boot mode: The MCU will alias flash memory (0x0800_0000) to address 0x0000_0000 The other two boot modes correspond to booting from internal SRAM and System Memory,

a ROM memory contains a bootloader in all STM32 MCUs and we did not discuss this in this thesis

Figure 2-4 : Structure of program in MCU memory [6, Fig 22.2]

Figure 2-4 depicts the operation of a basic program in the MCU When this boot time has passed, the CPU will fetch the Main Stack Pointer (MSP) from address

0x0000_0000 and execute code from boot memory starting from address 0x0000_0004 Reset_Handler has the function of performing some initialization: the data section (store static, global variables), the bss sections (store static, global variables but not initialized value), and from the Reset_Handler will then call the main() function of the program That's how the main() function is executed every time the processor is powered [6]

2.4.3 The startup process of the MCU with Bootloader

The Bootloader is just like a regular application What sets it apart is that it only runs once per operation and returns control to the main firmware after its task This is similar to “The startup process of the MCU,” but when it has already run the main() code of the Bootloader, it will return control to the main firmware To do this, move the vector table to the main firmware address, disable all interrupts and peripherals, and then call the reset handler of the main firmware

Figure 2-5 : Structure of multiple firmware in MCU memory [7, Fig 22.1]

For example, in Figure 2-5, firmware 1 is the Bootloader, and firmware 2 is the main firmware First, MCU entry to Bootloader at 0x0800_0000, after the task, it disables GPIO, timer, clocks, and interrupts … then relocates vector table and reset the main stack pointer (MSP) based on the main firmware at 0x08xx000 as shown Finally, it is called the Reset Handler of the main firmware

2.4.4 Reprogram MCU with Bootloader

Bootloaders can come in various sizes and with a variety of types, but in general, the operation of a system with a bootloader is relatively standard The main components of these systems can be seen in Figure 2-6 below: [7].

Figure 2-6 : General Bootloader Operation [7]

The branching code (green) decides whether the bootloader enters bootloader mode or application mode

The application code (blue) is executed only after the branching code has decided that there is no update requirement and the app code is safe to perform

It is essential that an application can accept commands to enter the bootloader while loading and performing its task When the application receives the requested

update command, it will restart the MCU (orange)

The bootloader code (red) performs all the bootloader's necessary functions Once the bootloader is started, it will begin setting up the basic peripherals needed for the bootloader to perform all its functions, such as timers, interrupt services, and communication peripherals This allows the bootloader to communicate with external devices and execute flashing commands When it receives a reprogramming command, it will begin backing up the main firmware memory to the backup memory used for recovery if needed Then, the bootloader clears the main firmware memory and receives firmware via a predefined protocol (such as UART, SPI, I2C, CAN, ) When reprogramming is finished, it will reset and enter the main firmware

2.5 UDS STANDARD FOR CAN BUS

Unified Diagnostic Service (UDS) is a diagnostic communication protocol used

in electronic control units (ECUs) in automotive electronics, specified in ISO 14229-3 "Unified" refers to an international standard rather than a standard specific

to a certain company or organization This makes the UDS standard extremely important in ECU development in the automotive industry, as it makes it easy to design diagnostic tools and communicate with the ECU to obtain information, maintain and update new firmware, … [8]

Overall, the UDS standard is essential for engineers developing ECUs and diagnostic tools in the automotive industry Its use ensures efficient and secure communication between ECUs and diagnostic tools, making vehicle maintenance and repair more accessible and safer

UDS uses bytes to define services, called Service Identifiers (SID) Tables 2-4 introduce a few UDS codes used in this thesis:

Table 2-4 : UDS Code Table

This service is used for both uploading and downloading

0x37 0x77 Request Transfer

Exit

Used to request finished download progress

2.6 AUTOSAR

2.6.1 Overview AUTOSAR

AUTOSAR, which stands for Automotive Open System Architecture, is a collaboration between vehicle manufacturers, suppliers, service providers, and companies from the global automotive, semiconductor, and software industries [9]

The main goal of AUTOSAR is to standardize the software architecture of ECUs (electronic control units), an essential component in modern vehicles By doing so, AUTOSAR enables the development of innovative electronic systems that improve vehicle performance, safety, and security

We will not discuss AUTOSAR in detail; instead, we will introduce its layers and discuss the RTE layer, which is extremely important in AUTOSAR

2.6.2 AUTOSAR Layer

Figure 2-7 : AUTOSAR layer [24]

The AUTOSAR software architecture in Figure 2-7 consists of 3 primary layers:

• AUTOSAR Basic Software Layer: Includes three sub-layers

o Microcontroller Abstraction Layer (MCAL): MCAL is the hardware

abstraction layer that implements the interface for specific microcontrollers It also has software layers that are integrated with microcontrollers through registers and provide peripheral drivers

o ECU abstraction layer: The main task of the ECU abstraction layer is to

provide services dedicated to ECUs, provide access to all peripherals, and support functions such as memory, I / O, etc

o Service Layer: The service Layer is mainly responsible for helping BSW

provide services on ASW thanks to API

• AUTOSAR Runtime Environment (RTE Layer): The middleware layer

between the Basic Software (BSW) and the Application Layer It provides communication services to application software

• Application layer: This level represents the highest layer in the AUTOSAR

architecture and is the most accessible to users It includes components that software developers can interact with and modify directly, such as indicators,

brakes, exhaust, air conditioning, fuel gauge, tachometer, or touch screen

• Complex Driver: Used for systems that respond quickly, such as airbag

systems, emergency braking systems

2.6.3 RTE Layer

The runtime environment (RTE) is the layer between the Application and Basic Software of the AUTOSAR architecture It is essential in operating and communicating the modules included through the Virtual Function Bus (VFB) mechanism RTE creates an environment where there are ports for modules to communicate and exchange data through ports

The modules can read and write data through RTE In addition, it also controls the scheduling of tasks in the ECU For example, the ECU has a task that the lights inside the car will turn on when the user presses the touch screen placed inside the car

Figure 2-8 : RTE Example For example, in Figure 2-8, when the software component reads the car door sensor data, if it detects that the door is open, it will send a signal to the RTE indicating that the car door is open The IVI (In-Vehicle Infotainment) system will receive this signal and display a message on the screen indicating that the car door

is open and turn on the light inside the car The Light module will read the signal from the RTE and then perform the necessary actions to turn on the car light Similarly, when the switch is turned on, the light will turn on, and when the switch

is turned off, the light will turn off

2.7 CAN COMMUNICATIONS PROTOCOL

2.7.1 CAN Introduction

Figure 2-9 : CAN Topology [23, Fig 222]

The CAN bus uses a two-wire interface consisting of a twisted pair of wires: CAN High (CANH) and CAN Low (CANL), as shown in Figure 2-9 It employs a differential signaling method, where the voltage difference between the two wires represents the transmitted data This differential signaling helps reduce the impact

of electromagnetic interference (EMI) and noise

CAN bus is known for its reliability, real-time capabilities, scalability, and effectiveness It is widely used in automotive systems, industrial automation, aerospace, medical devices, and other applications that require robust and efficient communication between devices

cost-2.7.2 CAN Network Message Format

CAN frames, or CAN messages, are the data transmission units in the Controller Area Network (CAN) protocol A CAN frame consisting of several components is presented in Figure 2-10 [10]:

Figure 2-10 : CAN Message Structure [10]

• Identifier (ID): The ID field (green) is a numeric value that identifies the

priority and content of the message It determines the message's position in arbitration and helps nodes filter relevant messages

• Data Length Code (DLC): The DLC field (yellow) specifies the number of

data bytes contained in the message It ranges from 0 to 8, indicating the size of the data payload

• Data Field: The data field (red) carries the actual information being

transmitted It can contain up to 8 bytes of data, depending on the DLC value

• Control Bits: The control bits (cyan) include various flags and control

information related to the frame, such as the Remote Transmission Request (RTR) flag The RTR flag distinguishes between data frames and remote frames used for requesting data

• Cyclic Redundancy Check (CRC): The CRC field contains a checksum that

helps detect errors during transmission It allows the receiving nodes to verify the integrity of the received data

• Acknowledge (ACK) Slot: The ACK slot, located after CRC, is used to

acknowledge successful message reception After transmitting a message, the receiving nodes send an ACK bit to indicate successful reception If no ACK bit is received, it indicates an error or a non-responsive node

CAN frames are transmitted serially over the CAN bus, with each node on the network receiving the frames However, only the nodes with matching IDs or relevant filtering criteria process the message, while others ignore it This filtering mechanism allows for efficient communication within the network

2.8 I2C COMMUNICATIONS PROTOCOL

2.8.1 I2C Introduction

The Inter-Integrated Circuit (I2C) protocol is a widely used serial communication protocol that enables communication between multiple devices using a two-wire interface Figure 2-11 illustrates this model It was developed by Philips (now NXP Semiconductors) and is commonly used in various electronic systems [11]

Figure 2-11 : I2C Topology [11, Fig 1]

I2C is a synchronous, multi-controller / multi-target (or master-slave) serial communication bus Each slave device has its unique address, allowing the master

to differentiate slaves from another

It uses only two bidirectional open-drain lines, SDA and SCL, which are pulled high for data communication

• Serial Data (SDA) – Data transfer takes place through this pin

• Serial Clock (SCL) – It carries the clock signal

2.8.2 I2C transfer operation

In I2C, data transfer occurs between a master device and one or more slave