République Tunisienne

Ministère de l’Enseignement Supérieur Code : GSP-RS-03-00

et de la Recherche Scientifique
Université de Tunis END-OF-STUDIES PROJECT REPORT Creation Date:
30-09-2023

GE3AII_13-2023

Electrical Engineering Department

Submitted for Obtaining the

National Diploma in Electrical Engineering

Speciality : AII

By : Rania Ali

Development of low layer and diagnostic test scripts for

USB and UDS protocols for automotive control units

Realized within: New Global Electronics

Presented the 30 September2023, In front of the jury members :

Président: Mr. Hassen SEDDIK

Examiner: Mr. Saber ABID

Academic supervisor: Mr. Jalel ZRIDA

Industrial supervisor: Mr. Brahim LAMINE

Academic Year : 2022 - 2023

ENSIT 5, avenue Taha Hussein Montfleury, 1008 Tunis Site Web : http://www.ensit.tn E-mail : direction.stage@ensit.rnu.tn
Tél (+216) 71 49 68 96/71 4968 80/7139 25 91 Fax : (+216) 71 39 11 66
 Dedication

I dedicate this project,

To my dearest father, whose unwavering support, wisdom, and dedication to my education

have been a constant source of inspiration. His sacrifices and belief in me have fueled my
determination to succeed.

To my loving mother, whose endless love, encouragement, and sacrifices have been the
cornerstone of my journey. Her nurturing presence has given me the strength to face
challenges with resilience.

To my amazing brothers and sister, my confidant in countless adventures, their presence has
made this journey unforgettable.

To my friends and classmates, for the camaraderie, late-night study sessions, and shared
moments of both challenges and triumphs. their friendship has enriched my experience in
countless ways.

I am also deeply grateful to my professors and mentors for their guidance, expertise, and
patience. Their wisdom and insights have shaped my academic and personal growth.

Rania Ali
 Acknowledgments

I would like to extend my sincere gratitude to NGE Company for providing me with the
invaluable opportunity to undertake my end-of-studies project within this esteemed
organization. This experience has been instrumental in shaping my academic and professional
journey, and I am truly appreciative of the support and guidance I have received during my
time there.

I am deeply thankful to to my project supervisor, Mr.Brahim Lamine, for their

guidance,constructive feedback, and encouragement which were instrumental in shaping the
success of this project.

I would also like to express my appreciation to the entire team at NGE Company for their
warm welcome, mentorship, and willingness to share their expertise. their patience,
encouragement, and insights have been crucial in helping me develop new skills and gain
practical knowledge.

I extend my heartfelt thanks to Mr.Jalel Zrida, my academic supervisor, for their guidance,
and unwavering support throughout the project.

I would like to express the honor bestowed upon me by the members of the jury for agreeing to
evaluate this project.

Rania Ali
 TABLE OF CONTENTS

LIST OF FIGURES v

ABBREVIATIONS LIST vii

GENERAL INTRODUCTION 1

1 General presentation 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Academic context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Hosting organism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 General presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Domains of activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 partners and customers . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.4 Activity concept and stakeholders . . . . . . . . . . . . . . . . . . . . 5
1.4 Project context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Project objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 General Concepts 8
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Test and validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Test and validation in automotive field . . . . . . . . . . . . . . . . . . 9
2.2.3 Test and validation process at NGE . . . . . . . . . . . . . . . . . . . 11
2.3 USB protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Introduction to USB . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1.1 USB definition . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1.2 USB speeds . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Page i
TABLE OF CONTENTS

2.3.1.3 USB System . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.2 USB communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2.1 Data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2.2 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2.3 Transfer types . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3 USB Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3.1 Device Enumeration States . . . . . . . . . . . . . . . . . . 18
2.3.3.2 USB Descriptors . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3.3 Control Commands . . . . . . . . . . . . . . . . . . . . . . 23
2.4 UDS protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1 Definition of UDS protocol . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.2 The use of UDS protocol . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.3 UDS frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.3.1 UDS Request frame format . . . . . . . . . . . . . . . . . . 24
2.4.3.2 Positive Response frame format . . . . . . . . . . . . . . . 26
2.4.3.3 Negative Response Frame Format . . . . . . . . . . . . . . . 27
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Test and validation of ECU using USB protocol 28

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Project description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Update of the test procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Script development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Test execution and analyzing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.1 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.2 The software used . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.3 Test execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5.4 Execution of Electrical test . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.5 Test analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.6 Electrical test analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Test report preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Test and validation of ECU using UDS protocol 41

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Project description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Page ii
TABLE OF CONTENTS

4.3 Test procedure development . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.1 Test purpose development . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1.1 Requirement description . . . . . . . . . . . . . . . . . . . . 43
4.3.1.2 Description analyze . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1.3 Test purpose creation . . . . . . . . . . . . . . . . . . . . . 44
4.3.2 Test case creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Script development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 Test execution and Automation . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.1 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.2 Execute one script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5.3 Batch execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 Test analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

GENERAL CONCLUSION 53

BIBLIOGRAPHIE 53

Page iii
 LIST OF FIGURES

1.1 New Global Electronics LOGO [1] . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 NGE Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 NGE Partners [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 NGE Customers [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 NGE, OEM and Clients collaboration. . . . . . . . . . . . . . . . . . . . . . . 6

2.1 The V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Validation process in NGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 USB Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 USB frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Writing to a USB Device [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Sending Data to the Host [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 USB transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8 OUT transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 IN transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.10 Enumeration steps [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.11 High speed detection process [6] . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.12 Sample descriptor table [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.13 Request frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.14 SIDs examples [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.15 Sub-Function ID examples [9] . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.16 Positive response frame format . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.17 Negative response frame format . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 ATB4S ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 USB test procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Example of test script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Putting ECU in Normal mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Page iv
LIST OF FIGURES

3.6 Record of USB traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.7 generator script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 Traffic log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9 USB test fixture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.10 Traffic analyze with OK test result . . . . . . . . . . . . . . . . . . . . . . . . 37
3.11 Traffic analyze with Not OK test result . . . . . . . . . . . . . . . . . . . . . . 38
3.12 Electrical test analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 HLKlemove ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Test case steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 UDS script example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 Script compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Test setup UDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6 NGE framinator [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.7 Exxotest USB-Mux-4C4L [15] . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.8 PIC 24 Bully Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.9 EXXOTEST USB-MUX-4C4L software and log capture . . . . . . . . . . . . 49
4.10 Batch running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.11 Generic mechanisms test analyze example with result OK . . . . . . . . . . . . 50
4.12 Generic mechanisms test analyze example with result Not OK . . . . . . . . . 51
4.13 Electronic integration test analyze example with result Not OK . . . . . . . . . 51
14 OSI model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Page v
LIST OF TABLES

LIST OF TABLES

2.1 USB Speeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Token Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Handshake Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Key Elements of a Device Descriptor . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Key Elements of a Configuration Descriptor . . . . . . . . . . . . . . . . . . . 21
2.6 Key Elements of a Interface Descriptor . . . . . . . . . . . . . . . . . . . . . . 22
2.7 Key Elements of Endpoint Descriptor . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Key Elements of String Descriptor . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Examples of NRCs [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Test equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Page vi
 ABBREVIATIONS LIST

NGE New Global Electronics

ECU Electronic Control Unit

CAN Control Area Network

LIN Local Interconnect Network

USB Universal Serial Bus

USB Unified Diagnostic Services

OEM Original Equipment Manufacturer

PSA Peugeot Citroën

SOF Start Of Frame

EP Endpoint

ACK Acknowledge

NAK Negative Acknowledge

NYET Not Yet

CRC Cyclic Redundancy Checksum

HID Human Interface Device

ISO International Organization for Standardization

DTC Diagnostic Trouble Code

Page vii
ABBREVIATIONS LIST

SID Service Identifier

NRC Negative Response Code

CEN Centralised

AUT Autonomous

ST Technical Specification

OSI Open System Interconnection

Page viii
 GENERAL INTRODUCTION

The automotive industry is a vast sector encompassing the development, manufacturing, and
sale of vehicles. With advancing technology, Electronic Control Units (ECUs) have become
integral components in vehicles, responsible for managing various functions such as engine
management, safety systems, and infotainment.

Communication and diagnostic protocols such as Controller Area Network (CAN), Local
Interconnect Network (LIN), UDS (Unified Diagnostic services), USB (Universal Serial Bus)
play a crucial role in enabling seamless data exchange and interoperability between ECUs and
other vehicle systems. These protocols define the rules and procedures for transmitting and
receiving data.

Effective test and validation processes in the automotive industry are crucial to ensure
the safety, performance, and functionality of vehicles. By conducting comprehensive tests,
manufacturers can identify and rectify any issues, enhance system reliability, and deliver high-
quality products to customers.

Throughout this work, we go through the steps of the Test and Validation of ECUs using the
USB and UDS protocols in NGE( New Global Electronics).

This report outlines the different steps that brought our work to fruition in four chapters
organized as follows: The first chapter presents the general context of the project.The second
chapter defines the main technical concepts related to the Test and validation field, also explain
the USB and UDS protocols used during this project and how they works and the Third chapter
explain the test procedure preparation, the scripts creation and test execution and the analyzes
for USB protocol and finally the fourth chapter contains the same process of the test and
validation in the 3rd chapter applied for the UDS protocol.

Page 1
Chapter

1
General presentation

Contents
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Academic context . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Hosting organism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 General presentation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Domains of activity . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 partners and customers . . . . . . . . . . . . . . . . . . . . . . 4
1.3.4 Activity concept and stakeholders . . . . . . . . . . . . . . . . . 5
1.4 Project context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Project objective . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Page 2
GENERAL PRESENTATION

1.1 Introduction

This chapter provides a general description of the project and an overview of the context in
which our project takes place. Within this chapter, we will highlight the project’s circumstances,
such as introducing the hosting company and its general framework. We conclude with a
description of the project specifications, explaining the problem statement, objectives, and
project timeline.

1.2 Academic context

This project is carried out as part of the end-of-studies project to obtain the diploma of electrical
engineering from the National Higher School of Engineering of Tunis. It takes place within the
company New Global Electronics, known as NGE Tunisia.

The main objective is to execute a series of testing and validation phases utilizing the USB
and UDS protocols on clients ECUs.

1.3 Hosting organism

1.3.1 General presentation

NGE is a company specialized in software and hardware testing and validation for automotive
applications.

Its first site was established in Paris in 2008. Later, it expanded its presence by setting up
a second site in China. In 2013, NGE established a new site in Tunisia, and then in 2016, they
launched the site in India, and recently, in 2023,it has the site of Morocco.

The following figure is the company’s LOGO.

Page 3
GENERAL PRESENTATION

Figure 1.1: New Global Electronics LOGO [1]

1.3.2 Domains of activity

New Global Electronics is a multidisciplinary company, as shown in Figure 1.2. His main
activities focus on the testing and validation of automotive computer systems based on CAN,
LIN, USB,UDS and LVDS. In addition, the company plays an active role as a consulting service
provider to automakers involved in the development of these computer systems.

Figure 1.2: NGE Activities

1.3.3 partners and customers

During its activities, NGE collaborates with several automobile manufacturers, as shown in
Figure 1.3, to carry out projects for their clients, as shown in Figure 1.4.

Page 4
GENERAL PRESENTATION

Figure 1.3: NGE Partners [2]

Figure 1.4: NGE Customers [2]

1.3.4 Activity concept and stakeholders

The automotive manufacturer, also known as the Original Equipment Manufacturer (OEM),
requests the suppliers, also known as Tier 1, to design and develop the software and hardware
components of the ECUs.

As illustrated in the following figure. The OEM provides the software and hardware technical
specifications of the ECU to Tier 1, which is responsible for its development and must closely
adhere to the provided specifications during the implementation process.

Page 5
GENERAL PRESENTATION

Throughout the development phase and before delivering the final version of the ECU to
the OEM, the ECU must undergo validation to ensure that its development complies with the
specifications. This is where the role of NGE, working closely with the Tier 1 in the validation
process. In case of any non-conformities, NGE supports these suppliers in debugging the issues.

Figure 1.5: NGE, OEM and Clients collaboration.

1.4 Project context

1.4.1 Problem statement

Before validating the developed control unit for the client, NGE receives the technical specification
and writes the test procedure for the specific protocol. If the test procedure is approved by the
OEM, NGE initiates the test. The process starts by converting test cases (test scenarios) into
code called test scripts. These scripts are then implemented in the test tool, executed and the
recorded communication between the test tool and the control unit are analyzed.

1.4.2 Project objective

During this project about Test and validation of ECUs using USB and UDS protocols, the main
object is:

Page 6
GENERAL PRESENTATION

• devoloppe the test procedure of USB and UDS protocols using the technical specification
from the PSA.

• Convert the test cases in the test procedure to scripts.

• Execute the tests of the low layer USB protocol for the 2nd round of Valeo project.

• Execute the tests of the Electronic integration mode and generic mechanisms for the
project HLKlemove.

• Analyze the Test results and write the test reports.

1.5 Planning

the project is realized according 3 main steps:

• The first step is about to understand and study about the USB and UDS protocols to better
understand the required work.

• The second step is to write the test procedure, create the test scripts, execute them and
analyze the results for Valeo USB 2nd Round project.

• the third step is to write the test procedure, create the test scripts, execute them and
analyze the results for the Electronic integration mode and generic mechanisms in UDS
HLKlemove 1st Round project.

1.6 Conclusion

In this project we have the general presentation of the project by starting with presenting the
hosting company then the project objective and finally the tasks to be completed during the
period of the internship.

Page 7
Chapter

2
General Concepts

Contents
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Test and validation . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Test and validation in automotive field . . . . . . . . . . . . . . 9
2.2.3 Test and validation process at NGE . . . . . . . . . . . . . . . 11
2.3 USB protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Introduction to USB . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 USB communication . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 USB Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 UDS protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1 Definition of UDS protocol . . . . . . . . . . . . . . . . . . . . 23
2.4.2 The use of UDS protocol . . . . . . . . . . . . . . . . . . . . . . 24
2.4.3 UDS frame format . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Page 8
GENERAL CONCEPTS

2.1 Introduction

The objective of this chapter is to clarify the theoretical concepts needed to realize the project

We start with the presentation of the test and validation process then we explain the USB
and UDS protocols,and also we are going to present the ECUs that we worked on during our
project.

2.2 Test and validation

2.2.1 Overview

* Test

Testing is a procedure to detect as many problematic behaviors as possible in a system, its

purpose is to improve quality by rectifying the identified issues, the test is based on three
elements: The input information, the object to be tested, the expected observations.

* Validation

Validation is done by the tester after the test. It is like examining, measuring and comparing the
results with specified requirements to determine whether compliance is achieved for each of the
characteristics.

2.2.2 Test and validation in automotive field

Due to the complexity of electronic architecture of vehicles, the development of ECUs has
shifted towards utilizing the V-model cycle.

The V-model has 3 essential parts: The verification phases, implementation, and validation
phases.

Page 9
GENERAL CONCEPTS

Figure 2.1: The V-model

From the V-model we are going to concentrate with the Validation phase exactly the three
types of testing:

* Unit testing

It is a method to check the proper functioning of every unit from the system independently,
this check is based on certain input data that the resulting actions are in accordance with the
module’s specifications.

* Integration testing

Integration testing represents the stage where individual units (ECUs) are brought together and
tested as nodes on the same network. This level of testing is used to find interface errors between
ECUs. This is particularly beneficial as it determines the level of efficiency of ECUs operating
on the same network.

* Validation testing

This phase involves verifying performance, robustness, and security parameters that can only
be exposed through testing the entire integrated system.

Page 10
GENERAL CONCEPTS

2.2.3 Test and validation process at NGE

Figure 2.2: Validation process in NGE

First of all NGE receive the test specifications from the OEM, which is PSA in our case, in
these specification there are the requirements needed to be tested in every ECU, then they start
preparing the test procedure including the test purposes and test cases of every requirement in
the specification, using these test purposes, NGE engineers develop the codes of the tests named
scripts.The third step in the validation process is to do the setup of the test with the ECU and the
other test tools.After doing the setup the next step is to execute the test using the written scripts
to extract the logs that is going to be analyzed in the final step and save the results with their
analyze in the "Raw file" and finally creating the test report, these tow files are to be uploaded
in a platform named Redmine.

Page 11
GENERAL CONCEPTS

2.3 USB protocol

2.3.1 Introduction to USB

2.3.1.1 USB definition

The Universal Serial Bus (USB) was developed in the 1990s to replace countless ports on
personal computers (PCs). The main motivation is to allow automatic configuration of peripherals
when connected to a PC. Soon after the USB port was introduced, it quickly replaced traditional
ports on most PCs. Today, USB is no longer just for PCs, but has become a mainstream interface
for many embedded industrial and consumer applications.

2.3.1.2 USB speeds

USB has three supported speeds as shown in the table bellow.

Maximum
Speed Utilization
Bandwidth

This approach was originally targeted at economical,

Low Speed 1.5 Mbit/s
low-data-rate devices such as computer mice and key board.

Full Speed 12 Mbit/s This was specified for all other devices

The high speed additions to the specification were

High Speed 480 Mbit/s introduced in USB 2.0 as a response to the higher speed
of Firewire.

Table 2.1: USB Speeds

2.3.1.3 USB System

The USB system is a unidirectional communication hierarchy consisting of a single USB HOST
and 1 to 127 USB devices. If you have more than one device, you must use one or more USB

Page 12
GENERAL CONCEPTS

hubs. When in use, the hub is considered one of 127 devices. All components of a USB system
are interconnected using one of the USB-specified cables and connectors.

Figure 2.3: USB Architecture

Low-speed, full-speed, and high-speed USB signals are transmitted over twisted-pair (D+
and D-) data cables using differential signaling. In addition to the twisted pair, the USB cable
provides a 5V reference voltage (VBUS) and a ground reference voltage from the host.

Communication on high-speed, full-speed, and low-speed USB systems occurs in half-duplex

mode only, with the host controlling the direction of data transfer.

2.3.2 USB communication

2.3.2.1 Data transfer

The data transfer is initiated by the Host. The Host regulate the communication timing through
the maintenance of designated time intervals called frames.At the onset of each frame, the Host
initiate a Start Of Frame (SOF) sequence on the USB data lines.Communication transactions
between USB Hosts and devices take place throughout the duration of a Frame.

Page 13
GENERAL CONCEPTS

Figure 2.4: USB frame

The data transfer mechanism involves the host reading and writing to multiple storage
locations located on each device called endpoints. Endpoints are essentially in and out of
baskets. The size of an endpoint can vary between different devices.

Device endpoints exist as numbered pairs start at 0 and go up to 32, each number has an
IN and an OUT endpoint. OUT endpoints carry data from the host, while IN endpoints carry
data destined for the host. For example, Endpoint 1 consists of two endpoints; Endpoint 1 Input
(EP1IN) and Endpoint 1 Output (EP1OUT).

Every USB Device designates Endpoint 0 as a distinct endpoint referred to as the Control
Endpoint. EP0 IN holds a description of the USB Device, which the Host reads during the
enumeration process. Concurrently, EP0 OUT grants the Host the capability to transmit configuration
commands to the Device.

* Writing to a USB Device

When the Host sends a message to a Device it sends a WRITE transaction which is going to
place the message in an OUT endpoint on the Device. After detecting the presence of a message
from the Host through the monitoring of the OUT endpoints by the Device’s application code ,
the Device will copy the message from the OUT endpoint.

Page 14
GENERAL CONCEPTS

Figure 2.5: Writing to a USB Device [3]

* Sending Data to the Host

If a device’s application wants to communicate with the Host, a message is placed in an IN

endpoint until the Host sends a READ transaction which caused the sent of the contents to the
host.

Figure 2.6: Sending Data to the Host [4]

Page 15
GENERAL CONCEPTS

2.3.2.2 Transactions

The Host initiate transactions with the purpose of accomplishing a communication event. These
transactions have the potential to consist of up to three packets.

. Token: Sent by the Host and describe the transaction type.

. Data: It is optional, depending on the transaction type, it is the payload of data sent in
the OUT and IN transactions.

. Handshake: The communications request status.

Figure 2.7: USB transaction

Type Meaning

IN Beginning of IN transaction.

OUT Start of OUT transaction.

SETUP Beginning of control request.

SOF Start Of Frame.

Table 2.2: Token Packets

Type Meaning

the transaction was successful and the data was received

ACK (Acknowledge)
without errors.

NAK (Negative the device is not ready to continue the transaction or that no
Acknowledge) data is available.

The endpoint is temporarily unable to proceed with the

STALL
requested operation.

Used in high-speed transactions to indicate that the device

NYET (Not Yet)
is not yet ready to send data.

Table 2.3: Handshake Packets

Page 16
GENERAL CONCEPTS

Successful USB transactions with accurate CRC values are completed in one go. However,
if the device responds negatively or with a STALL, the host retries the transaction in the
following scheduled frame. After repeated unsuccessful attempts, the host might utilize a
control command to temporarily suspend the device as a measure to manage communication
problems.

Figure 2.8: OUT transactions

Figure 2.9: IN transactions

Page 17
GENERAL CONCEPTS

2.3.2.3 Transfer types

USB transfer types govern communication between a host and device endpoints. They determine
data exchange methods, frequency, and structure. Transfer types may include CRC for packet
integrity. Devices configure these types, shared during enumeration.

There are three transfer types:

* Interrupt Transfers
Packets of limited length accompanied by CRC (Cyclic Redundancy Check) are sent at
regular intervals. Interrupt transfers can be scheduled, even if no data is present, like
every 10 frames.

* Isochronous Transfers
Longer packets without CRC scheduled at fixed periods. If no Host-endpoint communication
is needed, Host frees up frame bandwidth.

* Bulk Transfers
Short packets with CRC; Bulk transfers aren’t timed. They start when frame has free
space. Multiple Bulk transfers can occur within a frame if enough bandwidth is left.

2.3.3 USB Enumeration

2.3.3.1 Device Enumeration States

Enumeration is the procedure in which the host identifies the existence of a connected device
and undertakes the required steps to incorporate the device’s endpoints into the roster of endpoints
managed by the host.

Page 18
GENERAL CONCEPTS

Figure 2.10: Enumeration steps [5]

* Device Detection
Signal changes in D- or D+ indicate newly added devices operating at different speeds
(Low, Full, or High). Low-Speed devices use 5V on D-, while Full/High-Speed use 5V
on D+. Hubs detect these changes, informing the Host. Upon detection, the Host issues a
RESET command to establish communication with the Device.

Detecting a High-Speed USB Device: High-speed devices start enumeration like full-speed
ones. In reset, they negotiate with high-speed capable hubs to ensure smooth transition.
Voltage changes on D+ and D- occur. See figure below for detection process.

Figure 2.11: High speed detection process [6]

* Default State
When the device gets a RESET signal, it follows specs to start enumeration. High-Speed

Page 19
GENERAL CONCEPTS

devices emit a chirp if detected. After successful speed negotiation, the Host reads the
Device descriptor and assigns an address.

* Addressed State
After setting the address, the Host accesses remaining descriptors. If capable, it sends a
command to activate a configuration based on endpoints and power.

* Configured State
After Host’s instruction, Device is ready to operate as per the chosen configuration.

2.3.3.2 USB Descriptors

Each USB device has a set of descriptors read by the host during enumeration and there are
several types arranged in a logical hierarchy. In the following diagram we have the hierarchy of
a single device.

Figure 2.12: Sample descriptor table [7]

Every USB device must have one Device Descriptor and at least one each of the Configuration,
Interface, and Endpoint Descriptors.

Page 20
GENERAL CONCEPTS

* Device Descriptor: During enumeration, is the first descriptor read by the Host, its
purpose is to inform the Host about the USB version supported by the device and how
many possible configurations are available on the device.

Element Description

bcdUSB Inform the Host what version supported by the USB device.

bDeviceClass Inform about the class of the device.

A unique identifier assigned by the USB Implementers

idVendor
Forum to the device manufacturer.

A unique identifier assigned by the manufacturer to

idProduct
distinguish different product models.

Indicates the total number of configurations available for the

bNumConfigurations
device.

Table 2.4: Key Elements of a Device Descriptor

* Configuration Descriptor: The device can have more than one device configuration,
each one is assigned a number, its role is to inform the host about the numbers of interfaces
that the configuration has and the power consumption if the host activate this configuration.

Element Description

Specifies the count of interfaces present in this

bNuminterfaces
configuration.

Indicates the maximum power the device draws from the

MaxPower
bus when it’s active.

Table 2.5: Key Elements of a Configuration Descriptor

* Interface Descriptor: Provides essential information about a specific interface within a

configuration of a device such as endpoint number and device class.

Page 21
GENERAL CONCEPTS

Element Description

bNumEndpoints Interface’s endpoints number.

Defines the general class of the interface’s function (e.g.,

bInterfaceClass
audio, communication, HID).

Table 2.6: Key Elements of a Interface Descriptor

* Endpoint Descriptor: Every endpoint present on a device is associated with its own
individual descriptor. This descriptor serves to furnish crucial details such as the endpoint’s
address (represented by an endpoint number), its size, and the specific data transfer type
used to interact with this endpoint.

Element Description

Comprises the endpoint number and the direction (in or

bEndpointAddress
out).

wMaxPacketSize The endpoint length.

bInterval Indicates the interval between data transfers.

Table 2.7: Key Elements of Endpoint Descriptor

* String Descriptor: Contains textual information used for user-friendly identification and
description of various aspects of the device, such as its manufacturer, product, or serial
number.

Element Description

bLength Specifies the total length of the descriptor.

Identifies the type of descriptor, unique to String

bDescriptorTypes
Descriptors(=3).

Consists of Unicode-encoded text that provides

bString human-readable information, such as device manufacturer,
product name, or serial number.

Table 2.8: Key Elements of String Descriptor

Page 22
GENERAL CONCEPTS

2.3.3.3 Control Commands

The USB control commands are standardized requests that enable communication and configuration
between a host and a USB device. They are categorized into four types:

1. Standard Requests:
* Get Descriptor:Return a specific descriptor (e.g., device, configuration, interface).
* Set Address: Assigns an address to the device during enumeration.
* Set Configuration: Selects a configuration for the device to use.
* Get Configuration: Get the current configuration value.
* Get Status: Get the status of a device or endpoint.
* Clear Feature: Clears specific features of the device, like endpoint halt.

2. Class Requests: These requests are specific to device classes like HID, audio, etc., and
they are used for class-specific functionality.

3. Vendor Requests: Vendor-specific requests designed for device-specific operations and

features.

4. Reserved Requests: Reserved for future use and should not be implemented.

2.4 UDS protocol

2.4.1 Definition of UDS protocol

The UDS Protocol is a modern method for checking and fixing problems in cars. The ISO-14229
standard defines the UDS Protocol to make sure that all car manufacturers use the same rules.
This ensures they create a universal computer system for diagnosing any vehicle.

Similar to how people visit a doctor to identify and solve health issues, vehicles also need
to identify their problems. They do this using something called a "fault code" or "Diagnostics
Trouble Code (DTC)," which tells us what’s wrong with the vehicle.

Page 23
GENERAL CONCEPTS

UDS protocol is used to communicate with the car’s ECUs, it is like asking, "What’s
wrong??" The control unit responds with information that helps us understand the problem, we
employ a special tool that acts like a translator between us and the vehicle to retrieve the fault
code. This communication can occur using different methods, such as CAN, LIN, or K-line.

So, just as people need to consult with doctors to diagnose issues, vehicles rely on the UDS
protocol and these tools to communicate with their control units and identify problems when
something isn’t right.

2.4.2 The use of UDS protocol

The UDS protocol in the vehicle is used for:

. Read/clear diagnostic trouble codes (DTC) to troubleshoot and fix vehicle problems.

. Extract information like temperature, battery status, and vehicle identification number
(VIN) from parameter data values.

. Start diagnostic sessions to assess vital safety features, for example, for testing purposes.

. Change the ECU’s actions by performing resets, updating firmware, and adjusting settings.

2.4.3 UDS frame format

Because the UDS protocol operates on the CAN protocol, it allows you to request and receive
a maximum of 8 bytes of data in a single message. Similar to the CAN protocol, the UDS
protocol also offers two types of frames: Request and response frames and the response frame
itself is divided into two types: positive and negative responses.

2.4.3.1 UDS Request frame format

When the client needs to make a request for data, the tester will transmit this request as a frame
in order to receive a response from the server through the CAN data field. This frame had
consisted of 3 fields:

Page 24
GENERAL CONCEPTS

Figure 2.13: Request frame format

* UDS Service ID (SID)

To utilize a particular UDS service, the UDS request message must include the UDS
Service Identifier (SID) within its data payload. In the figure bellow we have examples of
SIDs.Note that the identifiers are split between request SIDs Note that the identifiers are
split between request SIDs (e.g. 0x22) and response SIDs (e.g. 0x62).

Figure 2.14: SIDs examples [8]

* Sub-Function ID
The sub function byte plays a role in UDS request frames in certain cases. However , in
certain UDS services, such as 0x22, the sub function byte remains inactive or unused.For
example, when reading DTC information via SID 0x19 (Read Diagnostic Information),
the sub function can be used to control the report type as shown in the figure bellow.

Page 25
GENERAL CONCEPTS

Figure 2.15: Sub-Function ID examples [9]

* Data Parameters
In many UDS request services, additional configuration beyond the SID and sub function
byte is achieved through various request data parameters.

2.4.3.2 Positive Response frame format

When the tester asks the server for confirmation and the server successfully executes the request,
it responds by appending 0x40 to the original service ID for reference. The first byte of the
positive response will be the Request Service ID + 0x40.

Figure 2.16: Positive response frame format

Page 26
GENERAL CONCEPTS

2.4.3.3 Negative Response Frame Format

When the client’s request is improperly formatted or the server encounters internal issues preventing
request execution, a negative response is sent to the client with first byte =0x7F and a specific
Negative Response Code (NRC).

Figure 2.17: Negative response frame format

* The Negative Response Code (NRC)

The negative response code is a byte in the negative response frame to indicate the main reason
why the message is not completed or rejected. in the table bellow we have some NRC codes.

NRC value NRC name

0x11 Service Not Supported

0x12 Sub-function Not Supported

0x13 Incorrect Message Length Or Invalid Format

0x22 Conditions Not Correct

0x33 Security Access Denied

Table 2.9: Examples of NRCs [10]

2.5 Conclusion

In this chapter, we initiated by explaining different concepts related to testing and validation,
followed by outlining NGE’s testing process. Additionally, we provided an overview of the
protocols we’ll be focusing on. With this foundational knowledge from the chapter, we will
be actively involved in developing the test plan procedure, creating scripts, and ultimately
conducting tests on the ECUs.

Page 27
Chapter

3
Test and validation of ECU using USB
protocol

Contents
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Project description . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Update of the test procedure . . . . . . . . . . . . . . . . . . . 30
3.4 Script development . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Test execution and analyzing . . . . . . . . . . . . . . . . . . . 32
3.5.1 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.2 The software used . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.3 Test execution . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5.4 Execution of Electrical test . . . . . . . . . . . . . . . . . . . . 36
3.5.5 Test analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.6 Electrical test analysis . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Test report preparation . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Page 28
TEST AND VALIDATION OF ECU USING USB PROTOCOL

3.1 Introduction

Following the definition of the validation process, this chapter will explore the tasks carried
out during the first part of the internship. We will begin by providing an overview of the
project, followed by a detailed realisation of the validation process for the low layers of the
USB protocol.

3.2 Project description

During this project we are going to test an ECU named "ATB4S" developed by Valeo company
it is a Device USB its position in the car is inside the dashboard, its role is the detection of crash
signal via CAN communication or airbag signal,Data transfer via LTE, USB/ETH and WIFI,
Audio communication with operator (via speakers and microphone), and others.

Figure 3.1: ATB4S ECU

Page 29
TEST AND VALIDATION OF ECU USING USB PROTOCOL

3.3 Update of the test procedure

The first step of our project, after understanding the USB protocol, is to develop the test
procedure of the project using the technical specification provided by PSA.

In this USB project we did the tests of the second Round applied to the ATB4S ECU which
means that we already have the test procedure and we did some updates in it.

Figure 3.2: USB test procedure

The test procedure is an Excel file named "Raw File" and all the results are saved in this
file. the main sheet is the SUM_UP sheet it contains all the requirements, the test purposes
and the results of the test cases and other details. We can mention also the "Test Matrix" file
which is sent by tier1 containing all the requirements with its applicability in order to know
what requirements are going to be tested. We have also in this Raw file the Patterns sheets with
the test steps of each test case in the file. The Test setup sheet contain the electrical diagram of
the tests.In addition to the sheets mentioned before there is a sheet for every single test case in
the file in order to put the test analyze, the result with some ECU details , the name of who did
the test and its date.

Page 30
TEST AND VALIDATION OF ECU USING USB PROTOCOL

3.4 Script development

Based on the test purposes and tests steps that was developed in the test procedure, now we are
going to write scripts for every test case using the "Ellisys USB Generator" software.

The USB generator acts as the host, facilitating the transmission or reception of packets on
the USB bus and the ability to establish particular states on the bus as well. In the following
figure we have an example of a script to check the Clear_Feature and Set_Feature Interface
requests, After running the enumeration.

Figure 3.3: Example of test script

Page 31
TEST AND VALIDATION OF ECU USING USB PROTOCOL

3.5 Test execution and analyzing

3.5.1 Test setup

Figure 3.4: Test setup

The equipment used to do the setup and execute the tests are as illustrated in the table bellow

Page 32
TEST AND VALIDATION OF ECU USING USB PROTOCOL

Equipment Usage

12V for supplying the ECU.

Power supply

For sending the BSI_COMMAND(NORMAL) frame to put

the ECU in the Normal mode.
Peak CAN [11]

Controlling and generating USB traffic with the scripts .

Ellisys Generator [12]

Visualize the USB frame traffic.

Ellisys Analyzer [13]

Visualize the USB frames signal.

Oscilloscope

Table 3.1: Test equipment

3.5.2 The software used

1.PCANView: This is a testing software used to configure the CAN simulator by adjusting the
communication parameters (bus speed, etc.) and also to configure the frames sent or received
by the ECU.
2.Ellisys USB Generator Software: This software is used to write, compile and execute USB
scripts.

Page 33
TEST AND VALIDATION OF ECU USING USB PROTOCOL

3.Ellisys USB Analysis Software:This software is used to record and capture frame traffic in
the USB bus.

3.5.3 Test execution

After doing the test setup with the ECU to be tested, we are going to follow the Actions detailed
in the test cases.

In general the steps of the test execution with USB protocol are:
1. Supplying the ECU with 12V.
2. Run the CAN simulator to put the ECU in the life phase we need, in our case it is the Normal
mode and to put the ECU in Normal mode we send the BSI_COMMAND with the ID =0x36
and the value 21 in the byte 5, then the ECU starts sending its functional frames.

Figure 3.5: Putting ECU in Normal mode

3. Start the record of the USB traffic using the USB analyzer.

Page 34
TEST AND VALIDATION OF ECU USING USB PROTOCOL

Figure 3.6: Record of USB traffic

4. Run the script in the USB generator which is going to communicate with the ECU as a
Host.

Figure 3.7: generator script

Page 35
TEST AND VALIDATION OF ECU USING USB PROTOCOL

5.Save the log recorded by the USB analyzer.

Figure 3.8: Traffic log

3.5.4 Execution of Electrical test

To do the Electrical test we use the test fixture which is a component with USB port in the two
side in order to give us the access to each pins in the USB connector specially the D+ and D- to
get the traffic signal using the oscilloscope.

Figure 3.9: USB test fixture

Page 36
TEST AND VALIDATION OF ECU USING USB PROTOCOL

3.5.5 Test analysis

The test analysis is to analyze and compare the results get by the test and the wanted results
mentioned in the test purposes.
In the figure bellow we have the analyze of the test purpose: "Check that every Peripheral’s
endpoint is capable of handling zero-length data packets in its assigned directions."

To do this test we sent two interface request the first is SetInterface to activate an interface
in the device that’s why we have no data returned by the device in the IN transaction, the second
is GetInterface to get the index of the active device and we have no data sent by the Host in the
OUT transaction. After this all we say that this test is OK.

Figure 3.10: Traffic analyze with OK test result

The following figure with an analyze of a test ends with Not OK result, it is the log of
the test purpose:"Using Standard Endpoint Requests Clear Feature and Set Feature to set an
ENDPOINT_HALT which allows the host to stall and reset to 0 the halt feature for a Bulk or
Interrupt endpoint."

In this test we sent first SetFeature (halt) to different endpoint IN and OUT so the Device
STALL the transactions sent then we send ClearFeature(halt) to disable the halt and the Device

Page 37
TEST AND VALIDATION OF ECU USING USB PROTOCOL

(ECU) must ACK the transactions but in this case the ECU NAK the transactions that’s why the
result is Not OK.

Figure 3.11: Traffic analyze with Not OK test result

3.5.6 Electrical test analysis

The electrical test shown in the figure bellow is a Device Hi-Speed Signal Quality test, in this
test we visualize the data packets with the oscilloscope and measure the data rate and it must be
480 Mb/s ± 0.05% and as we see the frequency is near 245 MHz and the frame is in 2 bit so we
have the data rate equal to 491.266 Mb/s and the test result is OK

Page 38
TEST AND VALIDATION OF ECU USING USB PROTOCOL

Figure 3.12: Electrical test analyze

3.6 Test report preparation

After we finished testing all the applicable test cases, we upload the Raw File and prepare
the test report that contain information about the ECU (software and hardware version, etc),
information about the setup,the documents used to finish the test and all the results of the test
cases (OK, Not OK, Not Tested, Not Testable). A score of 5 to identify the severity of a default
for the ECU is mentioned.

All the documents of the test ( the Raw file and the Test report) are delivered to both PSA and
Tier1 (The ECU developer) in order to more understand the ECU defects if there are Not OK
tests, also they can give their comment concerning the test and the analyse if there is something
not clear.

Page 39
TEST AND VALIDATION OF ECU USING USB PROTOCOL

3.7 Conclusion

Throughout this chapter we detailed the steps of realisation of the test and validation process
with USB protocol applied to ATB ECU from test procedure, scripts creation and execution to
the analyze of the result and report creation.

Page 40
Chapter

4
Test and validation of ECU using UDS
protocol

Contents
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Project description . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Test procedure development . . . . . . . . . . . . . . . . . . . . 43
4.3.1 Test purpose development . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Test case creation . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Script development . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 Test execution and Automation . . . . . . . . . . . . . . . . . . 47
4.5.1 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.2 Execute one script . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5.3 Batch execution . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 Test analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Page 41
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

4.1 Introduction

The previous chapter was the first part of our project in NGE, in this chapter we are going to
detail the realization of the test and validation process steps with UDS protocol for the ECU of
NGE client.

4.2 Project description

The ECU that we are going to test in this project is from HLKlemove company, in fact it has
two types the first is Var1 which is AUT (autonomous) means that at the moment we powered
it ON it start communicating without sending Normal command and it doesn’t react to the
BSI_COMMAND (responsible for life phase), and the other is CEN (centralized), it doesn’t
send its functional frames without periodically receiving the BSI_COMMAND (Normal) and
officially react with the other BSI_COMMAND.

During this project we are going to test the Electronic Integration Mode that is like putting
the ECU in a COM-OFF mode and it is a way to stop the ECU from having functional frames.
And also we tested the Generic mechanisms of the ECU ( the interaction of ECU with the
diagnostic services).these tests are going to be executed for both Var1 and Var2.

Figure 4.1: HLKlemove ECU

Page 42
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

4.3 Test procedure development

The test procedure is like a template for the test analyze and result, its general format is like we
mentioned in paragraph 3.3 of the previous chapter.

4.3.1 Test purpose development

The first step of developing the procedure is to create a name for the test cases of each requirement,
it is possible for the requirement to have more than one test case depends on the test needs, for
example for the requirement "GEN-UDS-ST-58 (2.0)" it has two test cases "NGE_UDS_ST_58_1_A"
and "NGE_UDS_ST_58_1_B". After finishing with all the requirement we move to writing the
test purposes to every one of them which is the objective of this test and what we are going to
test, this needs a well understanding of the requirements.

4.3.1.1 Requirement description

The requirement description is found in the technical specification provided by PSA and each
requirement has a specific description, based on them we can write the test purposes. For
example we have this description:"The anti-scanning time delay function is still active after
power up/reset. All unlocking request will be rejected during this time."

4.3.1.2 Description analyze

The anti-scanning time delay is a mechanism that introduces a delay or waiting period between
security access attempts. When an access attempt fails or is unauthorized, the attempt may be
subjected to a time delay before it can make another attempt. This requirement test that the
anti-scanning time delay is still active and the ECU reject the access requests within this time
even after the power off then on the ECU or apply a reset ( by sending reset diagnostic service).

Page 43
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

4.3.1.3 Test purpose creation

In the test purpose we write what we do to test the requirement and what we are going to check
in this test.
For the requirement we mentioned before to test it we need to get over the steps of the security
access, first send the request seed which is a parameter used to calculate the key to unlock the
ECU then we send request with the calculated key ( here tier1 provide us with the needed key),
but in our case we need to send an incorrect key to enter the The anti-scanning delay,do a reset
then resend request seed to check that the ECU reject it.
The test purpose of the requirement is:"Having the ECU in extended session,send Security
Access(0x27) service with subfunction "Request Seed" (0x03),then send Security Access(0x27)
service with subfunction "Send KEY" (0x04) with an incorrect key value. Check that the ECU
sends a negative response. Send an ECU Reset(0x11)request with subfunction "Key off On
reset"(0x02), then Send Security Access(0x27) service with subfunction "Request Seed" (0x03)
and Check that the ECU sends a negative response."

4.3.2 Test case creation

The step after developing the test purposes is creating the test cases.
A test case defines the detailed steps to perform the objective described by the test purpose: it
consists of four parts, as illustrated in the figure bellow, Step, Initial State, Action, Verification
of the Final State.

Page 44
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

Figure 4.2: Test case steps

* Step: Define the step number.

* Initial state: Define the state of the systems, as well as the different actors that have an
impact before test execution, for example: the state of the ECU (Power off, power on,
Normal Wake up, etc.), the test tool (sending frames or not).

* Action: The actions define what the test engineer must do after verifying that the ECU is
in the correct initial state. The actions should be precise and clear.

* Verification of the Final State:The final state is the value of the validation criteria. This
defines the expected behavior that the test engineer must verify to confirm the test result
(OK or Not OK). The final state can be a voltage measurement, current consumption,
a specific frame sent by the ECU, transition from one state to another, or functional
behavior.

4.4 Script development

Each test case has a script, which is a direct translation of the test objective. The scripts
developed at NGE are in a proprietary language called C-Flex, which is based on the C language.

Page 45
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

The scripts development is divided to two parts, the first is to create the script of each
test case then we develop another script named batch script and put in it the call of all the
scripts in order to execute them collectively, preventing individual execution and this called test
automation which is a new concept to more facilitate, organize and faster the test and validation
process. In the figure bellow we find a script example for UDS test.

Figure 4.3: UDS script example

After writing the tests we should place them in the gateway where all the file needed to
run the test exist then move to the compilation phase and compile them one by one using the
Command Prompt as shown in the figure bellow.

Figure 4.4: Script compilation

Page 46
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

4.5 Test execution and Automation

4.5.1 Test setup

Figure 4.5: Test setup UDS

The essential equipment that are used to run the code and get the log files are:

* NGE framinator

Figure 4.6: NGE framinator [14]

Page 47
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

NGE Tool is a calculator based on a PIC24 micro-controller designed by NGE for the
purpose of performing low-level tests for CAN, LIN and UDS protocols, also it is a
simulator that generates CAN frames and it is where The scripts developed before executed.

* The Exxotest USB-Mux-4C4L tool

Figure 4.7: Exxotest USB-Mux-4C4L [15]

EXXOTEST USB-MUX-4C4L we called muxtrace is a tool that allows the computer

to interface with communication networks such as CAN and LIN, via a USB or Ethernet
connection.Via this tool software we can communicate and visualize the frame transmission
with the ECU and then extarct the logs.

4.5.2 Execute one script

To execute one script individually we need to run the make line as we mentioned before then
open the software "PIC 24 Bully Bootloader" , make the configuration and press "Program"
then the script start running.

Figure 4.8: PIC 24 Bully Bootloader

Page 48
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

At the moment when the script execution is finished we open the EXXOTEST USB-MUX-4C4L
software to visualize the log.

Figure 4.9: EXXOTEST USB-MUX-4C4L software and log capture

4.5.3 Batch execution

After compiling the batch script and without opening any software we type another line in
the Command Prompt as in the figure 4.10 then the batch starts running and the logs are
automatically saved in a folder in the gateway.

Figure 4.10: Batch running

Page 49
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

4.6 Test analysis

As we said in the previous chapter the Analyse is to compare the result we get in the log with
the result needed from the ECU which is written in the test purpose to be checked.
We have bellow some examples of test results for HLKlemove ECU.

Figure 4.11: Generic mechanisms test analyze example with result OK

In the figure 4.11 we check if the ECU returns to the default session after the key off on
reset and this test was OK.

Page 50
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

Figure 4.12: Generic mechanisms test analyze example with result Not OK

The figure 4.12 illustrate the analyse of a test when we check that the ECU should reject the
unlocking attempt if it is in the anti-scanning time delay and this test ends with Not OK result.

Figure 4.13: Electronic integration test analyze example with result Not OK

The test in the figure 4.13 is to check if the ECU enter the electronic integration mode when
we send to it 3 specific consecutive frames by stop sending its functional frames and the test is
Not OK.

Page 51
TEST AND VALIDATION OF ECU USING UDS PROTOCOL

4.7 Conclusion

In this chapter we presented first the development of the test procedure with details then we
explained the test realization with unitary tests then automation using batch and we end by test
analysis examples.

Page 52
 GENERAL CONCLUSION

The present report is authored as part of a final year project at the National Higher School
of Engineers of Tunis, with the aim of obtaining the national engineering degree in Electrical
Engineering with a specialization in Automation and Industrial Computing.

During our final-year project, we had the opportunity to participate in projects related to the
test and validation of various types of CAN and USB ECUs. Our project provided a valuable
learning experience that contributed to our education. It was an opportunity to enhance our
knowledge and become familiar with testing and validation tools for low-level and diagnostic
automotive calculator.

The core objective of our project was to develop a comprehensive test procedure and subsequ-
ently execute an full round test based on USB and UDS as communication and diagnostic
protocols.To achieve this, we began with a theoretical study of these protocols. This preparation
allowed us to understand the working environment. Next, we move to the development of the
test procedure. Based on this procedure, we proceeded to the testing and validation phase,
where we put our acquired knowledge into practice.

during this project, we have implemented the automation test in UDS diagnostic protocol,
before was tested manually and that was a time and resource loss for NGE. Now our perspective
is implementing an automated testing process to the USB protocol to go further.

Page 53
 BIBLIOGRAPHIE

[1] https://nge-automotive.com/images/logo.png

[2] https://nge-automotive.com/customers.html

[3] https://microchipdeveloper.com/local–files/usb:how-it-works/writing-to-an-endpoint.svg

[4] https://microchipdeveloper.com/local–files/usb:how-it-works/reading-an-endpoint.svg

[5] https://microchipdeveloper.com/local–files/usb:enumeration/device-states.svg

[6] https://microchipdeveloper.com/local–files/usb:high-speed-detect/hs-speed-detect.svg

[7] https://microchipdeveloper.com/usb:descriptor

[8] https://www.csselectronics.com/pages/uds-protocol-tutorial-unified-diagnostic-services

[9] https://www.csselectronics.com/pages/uds-protocol-tutorial-unified-diagnostic-services

[10] https://piembsystech.com/negative-response-codes-nrc-uds-protocol/

[11] https://www.peak-system.com

[12] https://www.saelig.com/miva/graphics/00000001/ex260725.jpg

[13] https://moreneo.com/wp-content/uploads/2021/09/usbex200_32.png

[14] https://www.nge-automotive.com/images/svg/framinator_wow.jpg

[15] https://exxotest.com/wp-content/uploads/2018/01/fr_guide_utilisateur_USB-MUX-4C4L.pdf

Page 54
 ANNEXES

ANNEX A

Figure 14: OSI model

To describe the Low Layers of USB protocol, we will explain the concept of communication
layers within the OSI model.

The OSI (Open Systems Interconnection) model is the primary network communication
standard. This model is widely used by most providers because it is the best tool for describing
the sending and receiving of data over a network. The model divides communication into 7
layers.

Physical layer(1): The first layer of the model is responsible for carrying bits to their
destination on the physical medium. It provides the hardware means necessary for the establishment,
maintenance, and termination of these physical connections. This layer manages the representation

Page 55
ANNEXES

of bits (encoding, timing, synchronization) and defines the electrical, optical, and other signal
levels, as well as the transmission medium.

Data Link layer(2): It provides the functional means necessary for establishing, maintaining,
and releasing connections between network entities. This Layer is responsible for tasks such as
error correction that may have occurred at the first level, message filtering, framing of messages,
arbitration, acknowledgment, error detection, and error signaling.

Network layer(3): The network layer is responsible for correctly routing data packets to
the end user, passing through gateways that interconnect multiple networks. It handles packet
routing and addressing.

Transport layer(4): The transport layer is the final level that deals with the delivery of
information (Data Link Layer). It aims to optimize the quality of transmission, including error
detection tools and algorithms for re-transmitting lost messages.

Session layer(5): The session layer enables different network elements to organize and
synchronize their communication.

Presentation layer(6):This layer handles the syntax of the information exchanged between
network elements, ensuring that these elements use a common language for data transfer.

Application layer(7): This is the last layer of the OSI model. It provides applications with
the means to access the lower layers. It determines how different applications can coexist and
use common modules.

Annex B

USB Host: A USB host, often referred to simply as a "host," is a device in a USB (Universal
Serial Bus) system that initiates and controls communication with other devices connected to
the USB bus. It serves as the central point of control for managing the flow of data and power
between different devices.
USB Device: A USB device refers to any hardware component or gadget that can be connected
to a computer or other compatible devices via a Universal Serial Bus (USB) port for communication,

Page 56
ANNEXES

data transfer, power supply, or a combination of these functions. USB devices encompass a
wide range of products and peripherals that enhance the capabilities of computers and other
electronic devices.
USB hub: A USB hub is a hardware device that expands the number of available USB ports
on a computer or other compatible device. It allows multiple USB devices to be connected to a
single USB port, effectively multiplying the number of connections available. USB hubs come
in various sizes and configurations, offering different numbers of additional USB ports.

Page 57
 Abstract :
This project is part of my graduation project at the National Higher School of Engineering of
Tunis in order to obtain the title of Electrical Engineer. It was carried out within the company
NGE (New Global Electronics) for a period of 6 months, with the aim of developing the Law
layer and diagnostic test scripts for USB and UDS protocols, then the Execution and analysis of
tests for the customers Valeo and HLKlemove. This project involves automation tests in UDS
protocol to facilitate, organize, and faster the the test and validation process.

Key-words: Test and validation, communication protocol, Diagnostic protocol, USB, UDS.

Résumé:
Ce projet fait partie de mon projet de fin d’études à l’École Nationale supérieur d’Ingénieurs de
Tunis en vue d’obtenir le titre d’Ingénieur en Électrique. Il a été réalisé au sein de l’entreprise
NGE (New Global Electronics) sur une période de 6 mois, dans le but de développer les scripts
de test couche basse et diagnostic pour les protocoles USB et UDS, puis d’exécuter et d’analyser
des tests pour les clients Valeo et HLKlemove. Ce projet implique des tests automatisés dans le
protocole UDS pour faciliter, organiser et accélérer le processus de test et de validation.

Mots clés:Test et validation, Protocole de communication, Protocole de diagnostic, USB,

UDS.