capstone project diagnostic tool solution for automotive ecus

THE UNIVERSITY OF DANANG UNIVERSITY OF SCIENCE AND TECHNOLOGY FACULTY OF ADVANCED SCIENCE AND TECHNOLOGY CAPSTONE PROJECT DIAGNOSTIC TOOL SOLUTION FOR AUTOMOTIVE ECUs LE QUANG KHAI T

F5 BACH KHOA

Supervisor: PhD LE QUOC HUY Co-supervisors: HUYNH VU TIEN

Submitted to the Faculty of Advanced Science and Technology, Advanced Undergraduate Program in Electronics and Communication Engineering in

Partial Fulfillment of the Requirements for the Degree of Engineer

Da Nang, 12/2023

THE UNIVERSITY OF DANANG UNIVERSITY OF SCIENCE AND TECHNOLOGY FACULTY OF ADVANCED SCIENCE AND TECHNOLOGY

CAPSTONE PROJECT

DIAGNOSTIC TOOL SOLUTION FOR

AUTOMOTIVE ECUs

LE QUANG KHAI TRINH CONG DUY NGUYEN Supervisor: Phd LE QUOC HUY Co-supervisors: HUYNH VU TIEN

Da Nang, 12/2023

ĐẠI HỌC ĐÀ NẴNG CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

QUYẾT ĐỊNH

Về việc giao đề tài và thành lập Hội đồng hướng dẫn Capstone project

cho sinh viên Khoa Khoa học công nghệ tiên

HIỆU TRƯỞNG TRƯỜNG ĐẠI HỌC BÁCH KHOA

Căn cứ Nghị định số 32/CP ngày 04/4/1994 của Chính phú về việc thành lập Đại học Đà Nẵng và các trường trực thuộc;

Căn cứ Thông tư số 10/2020/TT-BGDĐT ngày 14/5/2020 của Bộ trưởng Bộ Giáo dục

và Đào tạo về Ban hành Quy chế tổ chức và hoạt động của đại học vùng và các cơ sở giáo

dục đại học thành viên; Căn cứ Nghị quyết số 08/NQ-HĐĐH ngày 14/7/2021 của Hội đằng Đại học Đà Nẵng về việc ban hành Quy chế tỏ chức và hoạt động của Đại học Đà Nẵng và được sửa đôi, bô

sung một số điều tại Nghị quyết số ¡3⁄NQ-HĐĐH ngày 07/9/2021;

Căn cứ Nghị quyết số 05⁄/NQ-HĐT ngày 12/01/2021 của Hội đẳng trường Trường Đại học Bách khoa về việc ban hành Quy chế tô chức và hoạt động của Trường Đợi học Bách khoa, Đại học Đà Nẵng và được sửa đổi, bồ sung một số điều tại Nghị quyết số 22/NO-HĐT

ngày 08/10/2021; Căn cứ Quyết định số 38/ĐHBK-ĐT ngày 12/01/2016 của Hiệu trưởng Trường Đại

học Bách khoa về việc ban hành Quy định tô chức và triển khai thực hiện Đỏ án tắt nghiệp kết hợp giữa Nhà trường và Doanh nghiệp - Capstone project;

Căn cứ đề nghị ngày 10/11/2021 của Trưởng khoa Khoa Khoa học công nghệ tiên tiển

về việc thành lập Hội đông lurớng dân Capstone project;

Theo dé nghị của Trưởng phòng Phòng Đào tạo

QUYẾT ĐỊNH:

Điều 1 Triển khai Capstone project cho 49 sinh viên năm cuối của Khoa Khoa học

công nghệ tiên tiến Tên để tài, nhóm sinh viên thực hiện, thời gian thực hiện và danh sách Hội đồng hướng dẫn được đính kèm theo quyết định

Điều 2 Hội đồng hướng dẫn tổ chức cho sinh viên thực hiện Capstone project theo

quy định hiện hành Sau khi hoàn thành nhiệm vụ, Hội đồng tự giải thẻ Điều 3 Trưởng phòng Phòng Tổ chức - Hành chính, Trưởng phòng Phòng Đào tạo, Trưởng phòng Phòng Kế hoạch - Tài chính, Trưởng khoa Khoa Khoa học công nghệ tiên tiền

và các cán bộ, sinh viên có tên ở Điều 1 căn cứ Quyết định thi hành /_ ke#ˆ

-KT, HIỆU TRƯỜNG

Z5'PHÔ']IEU TRUONG

Nơi nhận:

~ Như Điều 3;

~ Lưu: VT, DT

1 Tén dé tai: Diagnostic Tool Solution for Automotive ECUs

viên thực Trình Công Duy Nguyên Lớp 19ES hiện

TS Lê Quốc Huy Khoa Khoa học Công nghệ Chủ tịch -

tương TS Đào Duy Tuấn Khoa Điện tử Viễn thông, Ủy viên —

Truong DHBK Phan bién

ĐẠI HỌC ĐÀ NẴNG CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM TRƯỜNG ĐẠI HỌC BÁCH KHOA Độc lập - Tự do - Hạnh phúc

QUYẾT ĐỊNH

Về việc thành lập Hội đồng bảo vé Capstone project cho sinh viên khoa Khoa học Công nghệ Tiên tiến

HIỆU TRƯỞNG TRƯỜNG ĐẠI HỌC BÁCH KHOA

Căn cứ Nghị định số 32/CP ngày 04/4/1994 của Chính phù về việc thành lập Đại học Đà Nẵng và các trường trực thuộc;

_ Căn cứ Nghị quyết số 08/NQ-HĐĐH ngày 14/7/2021 của Hội đẳng Đại học Đà Nẵng về việc ban hành Quy chế tô chức và hoạt động của Đại học Đà Nẵng và được sửa đổi, bỗ sung một số điều tại Nghị quyết số 13⁄/NO-HĐĐH ngày 07/9/2021;

Căn cứ Nghị quyết số 03/NQ-HĐT ney 12/01/2021 của Hội đẳng trường Trường Đại

khoa, Đại học Đà Nẵng và được sửa đổi, bỗ sung một số điều tại Nghị quyết số 22/NQ-HĐT

ngày 08/10/2021:

Căn cứ Quyết định sé 39/DHBK-DT ngày 12 tháng 01 năm 2016 của Hiệu trưởng

Trường Đại học Bách Khoa về việc Ban hành quy định tô chức và triển khai thực hiện

Thực tập tốt nghiệp và làm Đỗ án tốt nghiệp cho sinh viên Chương trình tiên tiển; Căn cứ Tờ trình ngày 25/3/2022 của Trưởng khoa Khoa Khoa học Công nghệ Tiên

tiễn về việc thành lập Hội đẳng bảo vệ Capstone project;

Theo đề nghị của Phó trưởng phòng phụ trách Phòng Đào tạo

QUYẾT ĐỊNH:

Điều 1 Thành lập các hội đồng bảo vệ tốt nghiép Capstone project cho sinh viên nam

cuối của khoa Khoa học Công nghệ Tiên tiến Tên để tài, nhóm sinh viên thực hiện vả danh sách thành viên Hội đồng bảo vệ được đính kèm theo quyết định

Điều 2 Hội đồng tổ chức cho sinh viên bảo vệ Capstone project theo quy định hiện

hành Sau khi hoàn thành nhiệm vụ, Hội đồng tự giải thể,

Điều 3 Trưởng phòng Phòng Tổ chức - Hành chính, Phó Trưởng phòng phụ trách Phòng Đảo tạo, Trưởng phòng Phòng Kế hoạch - Tài chính, Trưởng khoa Khoa Khoa học Công nghệ Tiên tiến và các cán bộ, sinh viên có tên trong đanh sách ở Điểu | chịu trách nhiệm thi hành Quyết định nay, gh Nơi nhận: KT HIỆU TRƯỜNG

~ Lưu: VT, ĐT 5

hiện

ThS Nguyễn Thể XuânLy | Khoa Công nghệ Thông tin, | Thư ký

Hội đông bảo Tiên tiến, Trường ĐHBK Hướng dẫn

TS Đào Duy Tuân Khoa Điện tử Viễn thông, Ủy viên -

Bản nhận xét của cán bộ phản biện (có chữ ký)

ABSTRACT

In the contemporary automotive landscape, the integration of sophisticated computerized systems into vehicles, particularly the emergence of smart electric vehicles, has led to an increasing array of functionalities Consequently, there is a pressing need for more precise and comprehensive automobile diagnostic methods to facilitate effective repair procedures The existing diagnostic systems are categorized as on-board and off- board, both employing distinct approaches while sharing a common principle—utilizing diagnostic trouble codes to pinpoint faults or system errors in the vehicle This thesis focuses on implementing an off-board system using the unified diagnostic services defined in ISO-14229-1 and the CAN communication protocol defined by ISO-15765

Adhering to our instructor's directives, our plan involves constructing a send-and- receive model comprised of three primary components Two of these components will simulate client operations, featuring user interfaces for simplified interaction with the provided services The third component will function as either a server or the control unit within the automobile The envisioned scenario involves clients interacting with the provided services via a user-friendly interface, with a separate controller processing the data received from the server Meanwhile, the server 1s programmed to analyze sensor data, generate corresponding diagnostic trouble codes upon detecting faults or errors, and handle specific service requests from clients

Due to resource constraints, the system will employ a single microcontroller on the server side However, through simulation mirroring the functionality of an electronic control unit within an automobile, the tool is expected to operate seamlessly on actual vehicles equipped with a more extensive array of control units The primary objective is to explore the potential of leveraging the unified diagnostic services outlined in ISO- 14229-1 to construct a functional diagnostic tool This tool will utilize a laptop as the interface and a microcontroller as the processor, offering a promising avenue for advanced diagnostic capabilities in the realm of automotive repair

ACKNOWLEDGMENT

This diploma thesis was written in the year 2023 at Danang University of Science and Technology under the supervision of Phd Le Quoc Huy and Mr.Dao Duy Tuan, and Mr Huynh Vu Tien, software engineer at FPT Software

First and foremost, we would like to express our sincere appreciation to the main supervisor, Huynh Vu Tien, whose guidance, expertise, and encouragement have been invaluable throughout this research His dedication to fostering academic excellence and his insightful feedback have significantly enriched the quality of this work We are also grateful for the support provided by Le Quoc Huy and Dao Duy Tuan, whose support has played a vital role in shaping the trajectory of this thesis

We extend our heartfelt thanks to FPT Software, our internship partner, for their collaboration and for providing essential resources and insights that have contributed significantly to the practical relevance of this thesis The partnership with FPT Software has been a key catalyst in bridging the gap between academic theory and real-world applications

To our university, Danang University of Science and Technology, we extend our gratitude for providing a conducive academic environment and the necessary resources for the pursuit of knowledge and research

Lastly, to our friends and family, whose unwavering support and understanding have been a constant source of motivation and encouragement, we express our deepest thanks Your belief in our capabilities has been the driving force behind this academic achievement This thesis represents a collaborative effort and a journey of growth, and we are truly grateful for the support and mentorship that have shaped its outcome

Danang, December 2023 Danang University of Science and Technology Le Quang Khai and Trinh Cong Duy Nguyen

Contents

II 8o TP ẳỲỶ-ẼÝỶÝẼỶŸÝÝŸẼỶÝ II

List of tables 13 lYuUiv 00 0 14 Wntroduction 0000 L7

1 acc on aậ 17 2 Contribution of the theS15: ch TH HH HH HH HH HH HH HH Hiện 18 E9 on nn e.< ẽ.ẽẽẽãẽẽ66ã :lIYơ 18 N01 coi nh 4 ằa 19

1.1 The current diagnostie procedure and theIr problem: - - 2: 2: 2212212211511 21 1351551151111 te 19 1.1.1 Common types of diagnosIs approach: - c cc 2t 212 1211011121111 1111111111111 2111111011 1x kg 19 1.1.2 The need for off-board diànoSfIC: - 000100211211 111 1111111101101 0110111111151 1211111111111 ke 20 lý» co a8 9 na 21 1.2.1 Technical anaÌyzInng: - c1 12121 11111111111111 1111111111101 01111111151 TH HH HH TH HH HH kiện 21 In e ăằ ẽằ 25

Chapter 289 -):;ï].-:c0¡:'-a sểaaaaaaadiiiiiiiẢẢẢ 25

Pro an 25 2.1.1 Hardware €OnITAIHI: Sàn HH HH ng HH HH HH HH TH HH HH 25 2.1.2 Detailed model desIg1n: G1111 11111111111 1111 111101101101 1121 1511111111111 11 111015111 ke 26 2.2 Soffwar€ €SIET: L0 L1 2 HH HH1 011115151111 11 11 11111 nh Hà Hàn HT Hà Hy 28 2.2.1 Software COnTAHHI:, Sàn TH HH HH HH HH HH HH 1g th Ho 28 2.2.2 CAN-TP prOfO€Ọ: c1 12101 1111111111 1111111011 01 01111 H1 111115 1E HH HH TH HH TH TH Hvkt 28 2.2.3 UDS protocols Ặ 33 PA 090 ad .ằảằốaa 39 2.2.5 Bootloader mpÌeinenftafIOII: - - L0 21221121 12212121911111111111111 1111111011 111011111 11 1911 ky 42

3.1 Hardware mplemenfatIOI: - 11c 0211211211 251211211 1911111 1101111101111 51151111 t1 11111811 k kh rkg 45 3.2 Software ImpÏeimennf†AfIOT): - - 1 1 1121121321 311311 10111112111 11 11 11 11 H1 111115151515 1 11 1x 1kg HH 47 3.2.1 DTC IimplementatIon: - - c2 2212211211 251211251 1911911 11111111111 211511 215011 11 11 H1 H1 HH HH kg 47 3.2.2 Bootloader mpÌeinenfafIOII: - - L2 21221121 1221211911111111111111 1112111011 11 01 111 11 T9 ky 49 KP Si 2 on ae daA⁄5%5%⁄5ẼÊO035sss số 50 3.2.4 User 1nterface ImplemenfafIOT: c2 21121 121211211111111111111 1111111011 11 51H H1 1x 1 Hy Hà nà 51

Chapter 4: Experimentation and Evaluation result 0000.00cccccccccccccsccesceteeensstensaeeeeenes 52

4.1 Up-to-date obtainec reSuÏf: - c1 122112 1211111111111121111 1111111011 11 11 11111112111 Ht Hà nhàn Hết 52

10

List of figures

Figure 2: Diagnostic work flow based on DTC gøenerated by ECU

Figure 3: Implementation of UDS and CAN-TP according to OSI model

Figure 4: Block diagram for the system in general

Figure 5: Client and server model for ECUs and diagnostic tool interaction

Figure 6: Standard CAN message format c cóc Figure 7: CAN-TP transmission process with Single Frame and Multiple Frame

Figure §: General request and response protocol sunplified

Figure 9: Message flow for firmware update process using service 0x35,0x36,0x37

Figure 10: Security access service sunplified diasram

Figure 11: Example of a two operation cycle emissions-related OBD DTC

Figure 12: Bootloader firmware layers 0 6.0.60 cece cee cee ce cee cee cee tee eee ten een ee Figure 13: SS32K1xx memory S1Z©§ cc cà cà cà nàn nh ke se Figure 14: S32K144 Memory map - - -.ccc c2 cà cà cà: Figure 15: S32K144EVB board with some of the main features

Figure 16: Communication wiring between each part of the the system for the project

Figure 17: DTC diagnostic flow Iimplementatlon

Figure 18: DTC diagnostic flow Implementation (continue)

Figure I9: Bootloader folow control alsorithm cà Figure 20: UI design environment in Ột c.Ặ c2 c2 cà: Figure 21: CAN bus communication between 2 S532K144EVB

18 19 20 21 23 25 26 30

34 36 38 39 40 4I 43

44

.45 46 48 49 50 HH

Figure 23: DTC reading test on ECU with no error (left) and with error (right) EIgure 24: User interface build im Qt environment

12

List of tables Table 1.1 Comparison between manual diagnostic and computerized diagnostic Table 1.2 Comparison between CAN and LIN communication Table 1.3: CAN-TP format for different type of frames

22 27 27 28 28 29 31 47

13

Abbreviation ACK: Acknowledge AES-18 CBC: Advanced Encryption Standard with a 128-bit key in Cipher Block Chaining mode

BS: Block size CAN: Controller Area Network CAN HI: CAN High

CAN LOW: CAN Low CAN-TP: CAN Transport Protocol CANFD: Controller Area Network Flexible Data-rate CMAC: Cipher-based Message Authentication Code CRC: Cyclic Redundancy Check

CSEc: Cryptographic Service Engine compressed CTS: Clear To Send

DLC: Data Length Code DTC: Diagnostic Trouble Code EOF: End of Frame

ECU: Electronic Control Unit FC: Flow Control

FF: First Frame FCS: Frame Check Sequence FW: Firmware

GUI: Graphical User Interface

14

IDE: Integrated Development Environment IDR: Identifier

ISO: International Organization for Standardization LSB: Least Significant Bit

MCU: Microcontroller Unit MSB: Most Significant Bit NVM: Non- Volatile Memory OBD: On-Board Diagnostics OSI model: Open Systems Interconnection Reference Model OpenSDA: Open Source Serial and Debug Adapter PC: Personal Computer

PCI: Protocol Control Information PRNG: Pseudorandom Number Generator RND: Random

RGB LED: Red Green Blue Light Emitting Diode RTR: Remote Transmission Request

SF: Single Frame SBC: System Basis Chip SID: Service Identifier 532K 144EVB: 832K 144 Evaluation Board SOF: Start of Frame

SP: Service Primitive

15

TPDU: Transport Protocol Data Unit TTL: Transistor-Transistor Logic TRNG: True Random Number Generator UDS: Unified Diagnostic Services UART: Universal Asynchronous Receiver/Transmitter USB: Universal Serial Bus

VBAT: Voltage Battery

16

Introduction 1 Motivation and scenerio:

In the early days of automotive history, vehicles were mechanical marvels, relatively simple and easily diagnosed and repaired by traditional mechanics However, the contemporary automotive landscape presents an entirely different scenario In our industrialized world, the infusion of information and electronic technologies into modern vehicles has given rise to smart computerized systems These systems, governed by various control devices interconnected through the ECU, encompass both hardware and firmware implementations Ranging from fundamental features such as airbag deployment and Idle Speed Control to intricate functionalities like the Anti-lock Breaking System and Electronic Stability Control, today's vehicles are intricate ecosystems of technology

The complexity of implementing numerous controls in contemporary vehicles, which can involve 80 to over 100 ECUs dedicated to specific functions, renders traditional diagnostics using manufacturer manuals obsolete, which lead to the current diagnostic procedures rely heavily on computer diagnostics, utilizing sophisticated tools to interpret data collected by sensors and furnish technicians with detailed reports on the vehicle's condition This approach, while cost-effective and efficient for most vehicles, faces a substantial challenge with the escalating complexity of automotive software This complexity hinders effective testing of various feature combinations in a car, necessitating the development of sophisticated diagnostic tools to keep pace with the dynamic and competitive automotive industry

Current existing techniques in automotive diagnostics include On-board Diagnostics (OBD) and Off-board Diagnostics systems The OBD system conducts tests while the vehicle is in operation, displaying results on the dashboard or through an OBD tester tool Although widely used, OBD has limitations, offering access to a standardized set of diagnostic parameters primarily related to the Emission Control System and Engine and Transmission ECUs This standardization may not cover all aspects of an ECU's capabilities, posing challenges for advanced diagnostic needs

In contrast, the Off-board Diagnostics system, specifically Unified Diagnostics Services (UDS) defined in ISO 14229, takes a comprehensive approach to diagnostics beyond emissions UDS enables diagnostic tools to perform advanced functions, access various services, read and write data, control ECU functions, and execute tasks like

17

firmware flashing Not only that, it also offers enhanced security features, customization, and a protocol suite combined with the ISO-TP protocol standard on the CAN-Bus Our focus is on leveraging UDS to construct an efficient and versatile diagnostic tool for modern vehicles

2 Contribution of the thesis: - Acquisition of skills and knowledge in implementing UDS on a typical off-board diagnostic system with automotive industry standard

- Understanding the software implementation on ECU for diagnostic purpose - Insight of diagnostic procedure using DTC

- Comprehensive knowledge of CAN-TP operation within the automotive industry 3 Outline of the thesis:

- Chapter 1 - Literature preview: Introduce the common diagnosis procedure on automobile and explore the based design for the system

- Chapter 2 - Detailed theory: explaination of UDS, CAN-TP usage - Chapter 3 - System Implementation: Detailed description of the diagnostic tool implementation

- Chapter 4 - Experimentation and Evaluation result: Presentation of results from testing and evaluation on performance

18

4 Miles stone of the project:

Documentation research Khai, Nguyen Mt report Khai, Nguyen

MCU programming practice Khai, Nguyen Bootloader implementation Khai Application implementation Nguyen

Diagnostic device implementation Khai Evaluation on separate module Khai, Nguyen

Report M2-M3 Khai, Nguyen

Combining software in ECU Khai System preliminary evaluation Khai, Nguyen

§ystem optimization Khai, Nguyen Final product evaluation Khai, Nguyen

Final report Khai, Nguyen

- Manual diagnostic: This group involve traditional, hands-on methods that rely on visual inspection, manual testing, and the experience of the technician These methods are often fundamental and form the basis of automotive diagnostics

- Computerized diagnostic: This group involve the use of electronic tools, software, and technologies to analyze and interpret data from the vehicle's onboard systems These methods leverage advanced technology to enhance precision and efficiency

Since the thesis is based on off-board diagnostic, which is the second group, we will focus on the procedure used for computerized diagnostic to visualize the procedure Tyically, a vehicle’s diagnostic test will involve 5 steps:

-Step 1: The examination initiates with a diagnostic scanner analyzing the "check engine" light code This code, generated by the car's computer, offers insights into potential issues

19

-Step 2: Mechanics conducting the test connect a diagnostic scanner to the car, deciphering the trouble codes and converting them into actionable information

-Step 3: Subsequently, mechanics engage in investigative work to pinpoint potential problems They utilize the error codes to narrow down the problem area For example, if the check engine light code suggests an exhaust issue, the exhaust system becomes the initial focus of inspection

-Step 4: Upon identifying any problems, mechanics may opt for repairs, such as replacing faulty components or cleaning dirty areas

-Step 5: The test might be reiterated after repairs to validate the effectiveness of the fixes for the initial error

1.1.2 The need for off-board diagnostic: Regarding the common type of method in each group, we have explained the reason why off-board diagnostic is more flexible and useful than on-board diagnostic with its advanced function capable of monitoring more component than it counterpart Therefore, the following section will investigate the advantages and disadvantages between manual and computersized diagnostic:

affordable initially

points

Depth of Limited in-depth analysis of diagnostics, including electronic cố

and software components

20

data

Allows for regular software

capabilities over time

dependency on individual skills

1.2 Prelimary solution: 1.2.1 Technical analyzing: In a normal automobile, the system should include mutiple different ECUs, each monitors one or more modules inside the vehicle

21

Josuas Josuas

Josues

Sensor J t

22

ECU Mechanic | Analyze

and resolve problem

Record sensor changes

Normal changes

Figure 2: Diagnostic work flow based on DTC generated by ECU For protocol, as mentioned before, the main purpose of this thesis is to explore an efficient and effective automotive diagnostic tool for ECUs ultilising off-board diagnostic approach, which in this case is based off the idea of using UDS protocol (ISO 14229-1) for suite implementation, in conjunction with the CAN-TP protocol (ISO-15765-2) for BUS communication The OSI model, a representation of the overall system’s protocol, defined by the ISO-14229-1 suggests that UDS will be implemented in the application and session layer On the other hand, the ISO-15765-2 will be implemented in the transport and network layer

23

Unified Diagnostic Services (UDS)

¬—_—

Diagnostic communication over any protocol

: CoFR DolP DoK-Line LIN Do '

' |

| | OS! Layer 4 ISO 15765-2 ¥ | ISO 10681-2 ISO 13400-2 ISO 17987-2 i HỆ Go mơ DoCAN CoFR DolP LIN I

\ transport transport transport Not transport '

\ and and and applicable and !

1 network network network network !

| [ ositayer 3 services | layer services layer services layer services 7

oo

I

i ISO 17458-2 ISO 14230-2 ISO 17987-3 !

! TA + onmnt a don tek lay protocol

\ ISO 13400-3 ng) specification ;

\ a 4a DolP Qa Ss Ị IEEE 802.3 \

wired vehicle

\ Iso 11898-2 || ISO 17458-4 ee iso 142301 | | !9O 179874 :

UE eae 3 FlexRay Deal LIN \

' P' _ ISO 11898-3 electrical ayer electrical I

.| CAN physical layer —— physical layer \

' |

1 Nee ee Ne ee eet

Figure 3: Implementation of UDS and CAN-TP according to OSI model While ISO-14229-1 delineates diagnostic services, encompassing session control, data transmission, and security mechanisms for automotive diagnostics, the complementary protocol, ISO 15765-2-ISO-TP, serves as a transport layer protocol governing message fragmentation and reassembly in CAN communication for automotive diagnostics It oversees the segmentation and reassembly of diagnostic messages Although the network layer is integral to this protocol, responsible for structuring and managing a multi-node network involving addressing, routing, and traffic control, project constraints lead us to adopt an alternative configuration for this layer rather than using CAN-TP Other layers within the structure, not previously mentioned, will also be user-configurable

24

In summary, to develop an effective tool for the project, we must ensure a system that fulfills all functionalities while incorporating both protocols

1.2.2 System design: Regarding the concept design for the system, we have previously mention our limitation of equipment and resource, so the main focus will be implementing and testing the diagnostic device using UDS protocol for one ECU only The system should include one MCU to simulate ECU, one MCU to connect between the ECU and the client’s communication interface, which when combined, create the diagnostic device of the system The communication between each module is described using arrows in figure 4, which use CAN-TP as the main communication method between the ECU and MCU whereas the communication between MCU and the client interface will use a different communication method depending on the type of MCU being used

Server side Client side

>» >

ECU CAN Bus MCU client interface

The S32K144EVB is a low-cost evaluation and development board for general- purpose industrial and automotive applications Based on the 32-bit Arm® Cortex®-M4F S32K14 MCU, the S32K144EVB offers a standard-based form factor compatible with the Arduino® UNO pin layout, providing a broad range of expansion board options for quick application prototyping and demonstration[8]

25

The board can utilize both the CAN and LIN communication bus However, the reason why CAN was chosen is because of some of its superiority over LIN communication

Table 1.2 Comparison between CAN and LIN communication [11] As we can see, even though LIN communication is simpler and more money-saving than CAN communication, its low speed is not ideal for safety or other important application systems in the vehicle

2.1.2 Detailed model design: Based on the general design of the system, we will have 3 main parts: an ECU, an intermediate bridge MCU, and a computer interface application The project can be torn down into more complex designs as below: The project can be torn down into more complex designs as below:

26

- The server has 3 main parts, including a bootloader block, an application block, and a CAN Transceiver block, each of these blocks will be responsible for a specific task: + The bootloader is in charge of checking for updates as well as updating the firmware of the application block in the ECU

+ The application block is responsible for detecting error codes and reporting back to the user

+ The CAN Transceiver is the physical CAN layer in charge of converting any digital signal into a CAN bus signal and vice versa

+ Inside of both the bootloader and application block have the UDS block in charge of the protocol and the CAN controller block in charge of the segmentation of the received message (This block is basically CAN-TP in the system)

- The client will be in charge of sending request messages to the ECU side as well as storing and processing response messages from the ECU side by utilizing the 3 following blocks:

+ The PC tool: This is where the user can interact with the system, where request messages can be sent and reports of errors can be observed

+ Controller Host Interface: This block has a similar task to the CAN controller block in the ECU side

27

+ The CAN transceiver: This block in the client has the same task as the one in the server

+ The RAM: It is in charge of storing all of the messages received from the ECU during operation, which will be deleted when the system is reset

2.2 Software design: 2.2.1 Software contraint: The project does not have any limit on what kind of program can be used as long as it can work with the S32K144EVB However, as suggested by the manufacturer’s website, S32 studio is the most suitable software as it was developed specifically for this board

In addition, for a better experience with the PC tool, we will use Qt to build the application interface However, at the beginning of the research, before the user interface 1s fully functional, HERCULUS TERMINCAL will be used instead to observe statistics throughout the process as well as measure data inputs and outputs

2.2.2 CAN-TP protocol: We chose CAN as the main communication protocol over other available ones that were also integrated in the S32K144EVB We have also mentioned using CAN-TP protocol specifically for this project thanks to the ability to send more than 8 bytes of data through consecutive frames of CAN In this section, we will give a more details explanation of the importance of this approach

CAN is a multi-master, message-oriented protocol that enables microcontrollers and devices to communicate with each other without a host computer This is done by using a two-wire system: CAN High (CAN _H) and CAN Low (CAN L) These wires form a differential pair, which helps in noise immunity

Typical CAN messages are sent in frames, which has the following format [3] (*Note that in the context of the CAN protocol, a "frame" refers to the basic unit of data that is transmitted over the network):

28

Extension Bits Frame

Space Figure 6: Standard CAN message format

| Start-of-Frame (SOF): A single dominant bit (logical zero) indicating the commencement of a new frame

11 Identifier: Determines the message priority and content 11 Remote Transmission Request (RTR): Requests data from another node on the

bus O Identifier Extension (IDR): If the IDE bit is set to 0, the standard 11-bit identifier

is used; otherwise, the extended 29-bit identifier is employed 1 Data Length Code (DLC): A 4-bit field specifying the length of the data field

| Data: The actual data being transmitted between nodes on the bus (ranging from 0 to 8 bytes)

Cyclic Redundancy Check (CRC): Verifies the integrity of the transmitted data Acknowledge (ACK): Confirms the receipt of a message by the receiving node End-of-Frame (EOF): Comprises seven recessive bits (logical one)

| Error Detection: In-built error detection mechanisms safeguard data integrity within CAN networks These mechanisms include cyclic redundancy checks (CRC), frame check sequences (FCS), and acknowledgment bits from receiving nodes These features collectively contribute to the robustness of the communication system

29