Rapport de Pro jet de Fin d'Études

Pour l'obtention du diplôme de

INGÉNIEUR D'ÉTAT

Génie des Systèmes Embarqués et Informatique Industrielle

Rédigé par:

Zineb EL ATTAR SOFI

Conception, Développement et Test d'un prototype d'un système

d'aide à la conduite automobile (ADAS)

Stage eectué à :

Encadré par :
M. BELKEBIR Hicham, Encadrant à l'ENSAF
M. LAMRABET Abdellah, Encadrant à ALTEN

Soutenu le 11 Juillet 2020

Devant le jury composé de :

Pr. BELKEBIR Hicham Président du jury ENSAF

Pr. BELKEBIR Taouk
Pr. BELCAID Anass

Année Universitaire 2019 - 2020

 REMERCIEMENTS

Ce travail est l'aboutissement de cinq années de formation en ingénierie des systèmes embar-
qués et informatique industrielle. C'est avec la gratitude la plus profonde que je trace ces lignes,
que j'exprime ma vive reconnaissance à tous ceux qui m'ont épaulé dans tous les moments de
mon projet. Son avènement vient pour couronner leurs eorts.

Les plus grandes leçons ne sont pas tirées d'un livre mais d'un enseignant. Je témoigne,
ainsi, ma sincère reconnaissance à mes professeurs et particulièrement mon encadrant pédago-
gique, Mr. BELKEBIR Hicham, pour avoir accepté de me superviser et de suivre les détails de
l'avancement de mon travail, ainsi que son aide et ses conseils durant les diérentes étapes du
projet. Je remercie particulièrement Mr. MANSOURI Anass, coordinateur de la lière systèmes
embarqués et informatique industrielle pour ses conseils précieux, son dynamisme, sa patience,
son soutien continu et ses eorts considérables an de garantir la qualité de la formation consa-
crée à cette lière. Merci aux membres du jury pour l'honneur qu'ils me font en acceptant
d'examiner et de juger ce travail.

Nul ne peut nier que trouver un stage de n d'études n'est pas une chose aisée, c'est pour-
quoi je remercie en premier lieu ALTEN Maroc qui ore d'innombrables opportunités de ce
genre, et qui m'a bien accueilli durant ce stage. Acquérir une expérience professionnelle dans
une entreprise telle qu'ALTEN est non seulement un plaisir, mais par-dessus tout un réel abou-
tissement dans mon cursus universitaire.

Mes remerciements les plus sincères vont aussi à M. BOUHADDA Mohamed, le Directeur du
département Systèmes d'Information et Systèmes Embarqués (SISE), qui a eu la bienveillance
de m'accueillir dans son équipe.

Il m'est aussi agréable d'exprimer ma gratitude envers mon tuteur industriel; Mr. LAMRA-
BET Abdellah, chef de projet au sein d'Alten Delivery Center (ADC), pour son encadrement,
son précieux suivi, ses remarques pertinentes, ses recommandations fortes enrichissantes et son
partage continu de son incontournable expérience dont j'ai bénécié tout au long de ce stage.
Puisse ce travail être à la hauteur de ses attentes.

Je souhaite remercier également la référente du projet, Mme. ALIMOUSSA Khawla, pour

l'orientation, la conance, la patience qui ont constitué un apport considérable sans lequel ce
travail n'aurait pas pu être mené au bon port.

Enn, mes remerciements les plus profonds vont vers mes parents, mes frères et soeurs qui
m'ont toujours soutenu et encouragé à donner le meilleur de moi-même. Je leur dédie le fruit
de ce travail comme preuve de respect, de gratitude et de reconnaissance.

2
 RÉSUMÉ

Les études montrent que l'une des causes fréquentes des traumatismes mortels lors d'un
accident de la circulation est le cas classique du conducteur distrait. Ce dernier ne réagit pas
au changement brusque du véhicule qui le précède, et le percute à l'arrière. De tels accidents
peuvent occasionner des blessures aux occupants des deux voitures.

Confort, sécurité et assistance au conducteur, constituent donc les points focaux de l'indus-
trie automobile actuelle. An d'honorer son engagement à enrichir l'industrie automobile par
des solutions innovantes y aérant, ADC Maroc met au point son laboratoire de développement
interne an de réaliser des projets dans le domaine automobile, dont le présent est le projet
DeinAuge qui est en liaison avec les systèmes d'aide à la conduite automobile (Advanced Driver
Assistance Systems (ADAS)).

DeinAuge est un boîtier électronique à plusieurs fonctionnalités tant sur le plan visuel :
Détection des lignes de la voie, Détection et reconnaissance des panneaux de signalisation,
personnes, animaux, obstacles, véhicules, etc. Ainsi que sur le plan mécanique : Freinage au-
tomatique d'urgence et régulateur de vitesse adaptatif. Pour assurer le bon fonctionnement du
système et le rendre le plus sûr possible, l'équipe de développement applique et implémente
quelques pratiques dictées par le cadre de la norme ISO 26262.

DeinAuge, doté d'une intelligence articielle et d'une capacité d'interaction avec le conduc-
teur, est monté sur une carte de développement Jetson TX2, lui orant une puissance de calcul
adaptée pour le travail en temps réel. Ainsi, faire une étude comparative de l'environnement
technique du système, choisir son niveau de sécurité et suivre tout le cycle en V pour ses dif-
férentes fonctionnalités, sont les tâches qui m'ont été désignées dans la réalisation de ce projet
et qui sont discutées plus en détails dans ce présent rapport.

Mots clés : DeinAuge, ADAS, Vision par ordinateur, ISO 26262, Intelligence Articielle,
Jetson, Python, Cycle en V.

3
 ABSTRACT

Studies show that one of the common causes of fatal injuries in trac accidents is the classic
case of the distracted driver. The driver does not react to the sudden change of the vehicle in
front of it, and hits it in the back. Such accidents can cause injuries to the occupants of both cars.

Comfort, safety and driver assistance are the focal points of the current automotive industry.
In order to honor its commitment to enrich the automotive industry with innovative solutions,
ADC Morocco is developing its internal development laboratory to carry out projects in the
automotive sector. The present project is DeinAuge which is linked to the Advanced Driver
Assistance Systems (ADAS).

DeinAuge oers several features both visually : Lane lines detection, Detection and recog-
nition of trac signs, persons, animals, obstacles, vehicles, etc, and mechanically : Automatic
Emergency Braking and Adaptive Cruise Control. In order to ensure the proper functioning of
the system and make it as safe as possible, the development team applies and implements some
practices dictated by the ISO 26262 standard.

DeinAuge, equipped with articial intelligence and a driver interaction capability, is moun-
ted on a Jetson TX2 development board, oering it computing power suitable for working in
real time. Thus, make a comparative study of the technical environment of the system, choose
its level of safety and follow the whole V-Model for its various functionalities, are the tasks that
have been assigned to me in this project and which are discussed in more details in this report.

Keywords : DeinAuge, ADAS, Computer vision, ISO 26262, Articial Intelligence, Jetson,
Python, V-Model.

4
5
 TABLE DES MATIÈRES

REMERCIEMENTS 2
RÉSUMÉ 3
ABSTRACT 4
RÉSUMÉ(Arabe) 5
TABLE DES MATIÈRES 6
LISTE DES TABLEAUX 8
TABLE DES FIGURES 9
LISTE DES ACRONYMES 12
INTRODUCTION GÉNÉRALE 13
1 CADRE GÉNÉRAL DU PROJET 14
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Organisme d'accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.1 Présentation générale du groupe ALTEN . . . . . . . . . . . . . 15
1.2.2 Présentation d'Alten Delivery Center Maroc . . . . . . . . . . . 15
1.3 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1 Problématique et objectif . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.2 Description du système DeinAuge . . . . . . . . . . . . . . . . . . 17
1.3.3 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.4 Planication du projet . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 MÉTHODOLOGIE DE TRAVAIL ET ENVIRONNEMENT TECHNIQUE
DU PROJET 22
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Le cycle de développement en V . . . . . . . . . . . . . . . . . . . 23
2.2.2 La méthode Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.3 Gestion de versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 Environnement technique du projet . . . . . . . . . . . . . . . . . . . . . 29
2.3.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1.1 Carte électronique . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1.2 Caméra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1.3 Lidar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6
 2.3.1.4 Capteur ultrason . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.2.1 Langage de programmation . . . . . . . . . . . . . . . . . . . . 33
2.3.2.2 Environnement logiciel des tests unitaires . . . . . . . . . . . . 33
2.3.2.3 Environnement logiciel des tests système . . . . . . . . . . . . 34
2.3.3 Choix du niveau de criticité du projet . . . . . . . . . . . . . . . . 35
2.3.3.1 Norme ISO 26262 . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.3.2 Les niveaux d'intégrité ASIL . . . . . . . . . . . . . . . . . . . 36
2.3.3.3 Niveau ASIL du projet . . . . . . . . . . . . . . . . . . . . . . 37
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3 RÉALISATION DU SYSTÈME DeinAuge 39
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Flux descendant du cycle en V . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Ingénierie des exigences . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1.1 Élicitation des exigences . . . . . . . . . . . . . . . . . . . . . 40
3.2.1.2 Spécication des exigences . . . . . . . . . . . . . . . . . . . . 40
3.2.1.3 Vérication et validation des exigences . . . . . . . . . . . . . 43
3.2.1.4 Gestion des exigences . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.2 Architecture matérielle du système . . . . . . . . . . . . . . . . . . 43
3.2.3 Conception du système . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.3.1 Diagramme de cas d'utilisation du système . . . . . . . . . . . 45
3.2.3.2 Diagramme d'activité . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.4 Développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.4.1 Développement de la fonction LD . . . . . . . . . . . . . . . . 48
3.2.4.2 Développement de la fonction OD : . . . . . . . . . . . . . . . 50
3.3 Flux ascendant du cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.1 Test unitaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.1.1 Création des spécications de test . . . . . . . . . . . . . . . . 57
3.3.1.2 Développement des cas de tests . . . . . . . . . . . . . . . . . . 59
3.3.1.3 Résultats des tests unitaires . . . . . . . . . . . . . . . . . . . 60
3.3.2 Test système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.2.1 Création des spécications de test . . . . . . . . . . . . . . . . 64
3.3.2.2 Création des scénarios des vidéos de test . . . . . . . . . . . . 64
3.3.2.3 Génération des vidéos de test . . . . . . . . . . . . . . . . . . . 65
3.3.2.4 Résultats du test système . . . . . . . . . . . . . . . . . . . . 66
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
CONCLUSION ET PERSPECTIVES 69
RÉFÉRENCES 71
A DIFFÉRENCE ENTRE LIDAR 1D, 2D ET 3D 72
B LES CARACTÉRISTIQUES D'UNE BONNE EXIGENCE 73
C LA VISION PAR ORDINATEUR 74
D RÉSEAUX DE NEURONES CONVOLUTIONNELS 75
E RÉSULTATS DES TESTS DE LA FONCTION LD 77

7
 LISTE DES TABLEAUX

1.1 Fiche technique d'ALTEN MAROC . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Comparaison des cartes électroniques . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2 Comparaison des caméras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Comparaison des lidars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Caractéristiques des capteurs ultrasons proposés . . . . . . . . . . . . . . . . . . 32
2.5 Comparaison des ultrasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 Récapitulatif du benchmarking matériel . . . . . . . . . . . . . . . . . . . . . . . 33
2.7 Comparaison des langages de programmation . . . . . . . . . . . . . . . . . . . . 33
2.8 Allocation des niveaux ASIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.9 Détermination du niveau ASIL du système DeinAuge . . . . . . . . . . . . . . . 38
2.10 Détermination du niveau ASIL de la fonction LD . . . . . . . . . . . . . . . . . 38

3.1 Comparaison entre les deux architectures entrainées . . . . . . . . . . . . . . . . 54

3.2 Méthodes de dérivation des cas de test selon le niveau ASIL . . . . . . . . . . . 56
3.3 Types de couverture de code selon le niveau ASIL . . . . . . . . . . . . . . . . . 57

8
 TABLE DES FIGURES

1.1 Secteurs d'activités d'ALTEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Les principaux clients potentiels d'ALTEN MAROC . . . . . . . . . . . . . . . . 16
1.3 Diagramme de GANTT préliminaire du projet DeinAuge . . . . . . . . . . . . . 19
1.4 Planication des tâches du projet DeinAuge . . . . . . . . . . . . . . . . . . . . 20
1.5 Diagramme de GANTT nal du projet DeinAuge . . . . . . . . . . . . . . . . . 20

2.1 Le cycle de développement en V . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Le déroulement du projet - exemple des deux premières fonctions . . . . . . . . 25
2.3 Répartition et organisation des équipes . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Planning des réunions durant le sprint . . . . . . . . . . . . . . . . . . . . . . . 27
2.5 Exemple de dépôt sur Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Dossier partagé pour les livrables du projet . . . . . . . . . . . . . . . . . . . . . 29
2.7 Les cartes électroniques proposées . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.8 Les caméras proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.9 Les lidars proposés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.10 Les capteurs ultrasons proposés . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.11 CARLA Simulator - Simulateur de conduite . . . . . . . . . . . . . . . . . . . . 34
2.12 Unity - Moteur de jeu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.13 Les parties de la norme 26262 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1 Extrait des exigences système de la fonction LD . . . . . . . . . . . . . . . . . . 42

3.2 Extrait des exigences logicielles de la fonction LD . . . . . . . . . . . . . . . . . 42
3.3 Extrait du document des exigences de la fonction OD . . . . . . . . . . . . . . . 43
3.4 Architecture matérielle du système DeinAuge . . . . . . . . . . . . . . . . . . . 44
3.5 Diagramme de cas d'utilisation du système DeinAuge . . . . . . . . . . . . . . . 45
3.6 Diagramme d'activité de la fonction LD . . . . . . . . . . . . . . . . . . . . . . . 46
3.7 Diagramme d'activité de la fonction OD-OT . . . . . . . . . . . . . . . . . . . . 47
3.8 Schéma explicatif de la transformation de perspective en Vol d'oiseau . . . . . . 49
3.9 Le principe de fonctionnement de l'algorithme YOLO . . . . . . . . . . . . . . 51
3.10 L'architecture de la famille YOLO . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.11 Image pendant le jour utilisée lors de l'entrainement . . . . . . . . . . . . . . . . 52
3.12 Image pendant la nuit utilisée lors de l'entrainement. . . . . . . . . . . . . . . . 52
3.13 Annotation des images avec le logiciel LabelImg . . . . . . . . . . . . . . . . . . 53
3.14 Diérents résultats possibles de l'IOU . . . . . . . . . . . . . . . . . . . . . . . . 54
3.15 Résultat obtenu par YOLOv3-tiny . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.16 Résultat obtenu par YOLOv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.17 Extrait 1 du document des spécications de tests niveau logiciel de la fonction TSR . . 58
3.18 Extrait 2 du document des spécications de tests niveau logiciel de la fonction TSR . . 59

9
3.19 Commande d'exécution des tests unitaires . . . . . . . . . . . . . . . . . . . . . 61
3.20 Extrait du chier de détection des bugs des tests unitaires . . . . . . . . . . . . 61
3.21 Commande de génération du rapport de test unitaire . . . . . . . . . . . . . . . 61
3.22 Extrait 1 du rapport des tests unitaires . . . . . . . . . . . . . . . . . . . . . . . 62
3.23 Extrait 2 du rapport des tests unitaires . . . . . . . . . . . . . . . . . . . . . . . 62
3.24 Commande 1 de génération du chier de couverture du code . . . . . . . . . . . 63
3.25 Commande 2 de génération du chier de couverture du code . . . . . . . . . . . 63
3.26 Fichier de couverture du code de la fonction TSR . . . . . . . . . . . . . . . . . 63
3.27 Extrait du document des spécications de tests niveau système de la fonction TSR . . 64
3.28 Extrait du document des scénarios des vidéos de test de la fonction TSR . . . . . . . 65
3.29 Exemple de l'environnement d'une vidéo sous Unity . . . . . . . . . . . . . . . . 66
3.30 Exemple de l'environnement d'une vidéo sous CARLA . . . . . . . . . . . . . . 66
3.31 Rapport de test système de la fonction TSR . . . . . . . . . . . . . . . . . . . . 67
3.32 Résultat du test d'une vidéo sous Unity . . . . . . . . . . . . . . . . . . . . . . . 68
3.33 Résultat du test d'une vidéo sous CARLA . . . . . . . . . . . . . . . . . . . . . 68

D.1 ANN à gauche, CNN à droite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

E.1 Résultat du test de la fonction LD - Position correcte . . . . . . . . . . . . . . . 77

E.2 Résultat du test de la fonction LD - Position déviée . . . . . . . . . . . . . . . . 78

10
 LISTE DES ACRONYMES

ACC Adaptive Cruise Control (P 18).

ADAS Advanced Driver Assistance Systems (P 3).
ADC Alten Delivery Center (P 2).
AEB Automatic Emergency Braking (P 18).
ANN Articial Neural Network (P 75).
ASIL Automotive Safety Integrity Level (P 36).
CNN Convolutional Neural Network (P 50).
CV Computer Vision (P 74).
DL Deep Learning (P 50).
E/E Électriques/Électroniques (P 35).
ECU Electronic Control Unit - Unité de Commande Électronique (P 13).
FPS Frames Per Second (P 54).
GPU Graphics Processing Unit (P 30).
HDMI High Denition Multimedia Interface (P 44).
HIL Hardware In Loop (P 34).
HSL Hue Saturation Lightness (P 49).
IA Intelligence Articielle (P 30).
IEEE Institute of Electrical and Electronics Engineers (P 40).
IOU Intersection Over Union (P 54).
ISO International Organization for Standardization (P 35).
LCW Lane Changing Warning (P 17).
11
LD Lane Detection (P 17).
LiDAR Light Detection And Ranging (P 31).
LKA Lane Keeping Assist (P 17).
LLD Low Level Design (P 24).
mAP Mean Average Precision (P 54).
OD Object Detection (P 18).
OD-OT Object Detection - Object Tracking (P 18).
OpenCV Open Source Computer Vision Library (P 33).
PIB Produit Intérieur Brut (P 13).
PO Product Owner (P 26).
QM Quality Management (P 36).
RADAR RAdio Detection And Ranging (P 18).
SDLC Software Development Life Cycle (P 23).
SIL Software In Loop (P 34).
SISE Systèmes d'Information et Systèmes Embarqués (P 2).
TOF Time Of Flight (P 32).
TS Test Specication (P 57).
TSR Trac Sign Recognition (P 17).
UML Unied Modeling Language (P 45).
YOLO You Only Look Once (P 50).

12
 INTRODUCTION GÉNÉRALE

Le secteur automobile est en pleine évolution et ne cesse de croître. Les systèmes mécaniques
dans l'automobile ont été largement remplacés par des systèmes électro-mécaniques. Aujour-
d'hui, l'industrie automobile intègre des systèmes embarqués partout, partant des essuie-glaces
jusqu'aux airbags et systèmes ADAS. Ces technologies s'articulent autour d'un réseau de com-
munication, sur lequel repose une architecture véhicule comportant une multitude d'unités de
commande électronique (Electronic Control Unit (ECU)) gérant les fonctions principales du
véhicule.

Selon les statistiques, 80% des accidents de la route sont à cause du facteur humain. En
eet, le non-respect de la limitation de vitesse, la fatigue, l'utilisation du téléphone, la somno-
lence et d'autres facteurs peuvent entrainer des dégâts matériels et humaines très graves. En
2017, les accidents ont coûté à la société marocaine près de 20 milliards de dirhams. Selon les
estimations de la Banque mondiale, les pertes liées aux accidents de la circulation représentent
près de 2% du PIB (Produit Intérieur Brut) marocain [1]. Sans oublier que le Maroc enregistre
chaque année presque 4000 morts sur les routes.

Dans ce contexte, les systèmes d'aide à la conduite ont pour objectif pas seulement de pro-
téger les passagers en cas d'accident, mais surtout de prévenir ces derniers et de les empêcher
de se produire. C'est pourquoi les systèmes d'aide à la conduite sont toujours en alerte et
contrôlent en permanence l'environnement dans lequel se trouve la voiture, grâce à des données
produites par diérents types de capteurs. Ces informations permettent à la voiture de réagir
lorsqu'un obstacle se présente sur la route ou lors d'un mouvement soudain des autres véhicules.
La voiture est alors capable de déclencher les assistances de conduite adéquates, d'alerter le
conducteur d'une situation dangereuse ou de minimiser le risque ou les conséquences en cas
d'accident.

Au sein de la société ADC Maroc, le but de ce présent projet est la réalisation d'un prototype
de système d'aide à la conduite pour le compte de la même société. Ce rapport de projet de n
d'études décrit l'essentiel du travail réalisé dans le cadre d'une expérience à la fois pédagogique
et professionnelle. En eet, il est structuré en quatre chapitres: Le premier chapitre présente
l'organisme d'accueil, ADC Maroc, discute le contexte du projet en présentant la problématique
traitée, les objectifs visés, ainsi que la planication du projet. Le deuxième chapitre présente la
méthodologie de travail adoptée tout au long du projet, ainsi son environnement technique. Et
nalement, le dernier chapitre s'intéresse à la mise en oeuvre du système et illustre les étapes
de sa réalisation.

13
 CHAPITRE 1
CADRE GÉNÉRAL DU PROJET

1.1 Introduction

Ce travail a été éectué au sein d'ALTEN Maroc dans le cadre d'un stage de n d'études.
Ce chapitre introductif met le point sur le cadre général du projet et son environnement. La
première partie introduit l'organisme d'accueil, ses domaines d'activités ainsi que sa structure
interne. La deuxième partie met l'accent sur le contexte du projet : Les enjeux et objectifs du
projet ainsi que le cahier des charges régulant l'accomplissement de ce travail.

14
1.2 Organisme d'accueil

1.2.1 Présentation générale du groupe ALTEN

La multinationale ALTEN est le partenaire technologique de référence des plus grandes
entreprises nationales et internationales. Ce groupe français créé en 1988 est devenu en 30 ans
le leader Européen de l'ingénierie de conseil en technologies et il a pu atteindre 1975 M euros
comme chire d'aaires en 2017. ALTEN emploie près de 28 000 salariés, dont 88% sont des
ingénieurs de haut niveau travaillant dans plusieurs secteurs d'activité qui sont présentées dans
la gure ci-dessous :

Figure 1.1  Secteurs d'activités d'ALTEN

La présence du groupe dans plus de 20 pays du monde permet d'accompagner le dévelop-
pement international des clients, soit en support local de leurs équipes Recherche et Dévelop-
pement (RD), soit en pilotage de projets transnationaux.

1.2.2 Présentation d'Alten Delivery Center Maroc

ALTEN Maroc est à la fois la plateforme pour développer des projets en mode Nearshore
et le représentant du groupe sur le continent Africain pour la clientèle Marocaine et Africaine.
Avec le site de Rabat à Technopolis et le Centre de Delivery situé à Fès Shore Park, la liale
Marocaine a pour vocation de déployer une stratégie globale permettant à ses clients de béné-
cier d'une présentation de qualité mais aussi de proximité à un coût très compétitif.

Le tableau ci-après représente la che technique d'ALTEN Maroc :

15
 Nom de la société ALTEN MAROC

Statut Juridique Société Anonyme de Droit Français

Siège social Fès Shore Park, Fès
Directeur Amine ZAROUK
Date de création 2014
Secteur d'activité Société de services technologiques
Chire d'aaire 86 025 400 MAD (2014)
Eectif +800 collaborateurs dont 80% ingénieurs
Site Web www.alten.ma

Table 1.1  Fiche technique d'ALTEN MAROC

Cette liale marocaine est décomposée en trois départements, Réseaux et Télécoms, Logiciels
et support outils, Systèmes d'information et systèmes embarqués. Le département Systèmes
d'Information et Systèmes Embarqués dans lequel, j'ai eectué mon stage est présent dans les
deux sites marocains et travaille avec des clients potentiels dont les principaux sont :

Figure 1.2  Les principaux clients potentiels d'ALTEN MAROC

1.3 Contexte du projet

1.3.1 Problématique et objectif

Les systèmes avancés d'aide à la conduite, ou ADAS, est le terme utilisé pour décrire le
nombre croissant de fonctions de sécurité conçues pour améliorer la sécurité des conducteurs,
des passagers et des piétons en réduisant à la fois la gravité et le nombre total d'accidents de
véhicules à moteur. ADAS peut avertir les conducteurs des dangers potentiels, intervenir pour
aider le conducteur à garder le contrôle an de prévenir un accident et, si nécessaire, réduire
la gravité d'un accident s'il ne peut être évité. En bref, ADAS compense nos erreurs, que ce
soit l'inattention, les entrées de contrôle erronées ou, jusqu'à un certain point, la stupidité pure
et simple. Admettons le, nous ne sommes pas parfaits, mais l'idée derrière ADAS est de nous
aider [2].

Tout système allégeant et facilitant la tâche du conducteur peut être considéré comme une
aide à la conduite automobile. Au stade ultime de l'évolution des aides à la conduite, nous
arrivons au véhicule autonome.

16
 ADC Maroc propose chaque année un projet interne lié à l'activité de l'automobile an de
donner des opportunités aux étudiants de pratiquer leurs acquis académiques dans un monde
professionnel en respectant des standards. Dans ce cadre, et vu l'importance des ADAS à l'heure
actuelle, vient ce projet de n d'études qui a pour but de développer un prototype de système
ADAS qui englobe plusieurs fonctionnalités diversiées. L'objectif de ce système est d'assister le
conducteur, assurer sa sécurité et rendre son véhicule intelligent. Le déroulement de ce projet a
été au sein du département SISE dans lequel j'ai eu le privilège d'exercer les diérentes activités
et les tâches professionnelles conées.

1.3.2 Description du système DeinAuge

DeinAuge, qui signie "Votre oeil" en Allemand, est le nom que les membres de l'équipe
projet ont choisi pour lui donner une identité unique. Ce nom vient du fait que ce système, une
fois implémenté dans le véhicule, il va être présent pour le conducteur an de le contrôler et le
guider dans toutes ses actions.

Les fonctionnalités qu'ore DeinAuge sont les suivantes :

Détection des lignes de voie (Lane Detection (LD)): Cette fonction est conçue en
utilisant une caméra qui est placée derrière le pare-brise du véhicule pour capturer les images
de la route, ainsi les lignes sur la route sont interprétées et les voies sont identiées. Elle permet
donc de guider le conducteur en lui fournissant des avertissements pour adapter sa position une
fois le véhicule quitte involontairement une voie. La détection des marqueurs de voie est l'étape
initiale des deux sous-systèmes suivants :
• L'aide au maintien de voie (Lane Keeping Assist (LKA)): L'objectif principal
de cette fonctionnalité est d'avertir le conducteur lorsque son véhicule franchit un mar-
quage de ligne de voie sans que cette action n'ait fait l'objet d'une communication visuelle
(activation des clignotants) de la part de l'usager. Les capteurs intégrés au véhicule consi-
déreront alors la modication de la direction suivie par le véhicule comme une inattention
ou un manque de vigilance. Le système envoie donc une alerte à l'intention de l'usager
an de corriger sa direction ce qui permet de garder toujours la voiture centrée dans sa
voie.
• Système d'avertissement de changement de voie (Lane Changing Warning
(LCW)): Ce système combine entre plusieurs paramètres qui sont pris en compte an
de décider de la possibilité de changement de voie. Il permet de créer des conditions de
conduite plus sûres en avertissant le conducteur qu'un changement de voie peut s'avérer
dangereux. L'avertissement laisse susamment de temps au conducteur pour pouvoir
interrompre le changement de voie.
Reconnaissance des panneaux de signalisation (Trac Sign Recognition (TSR)):
Les panneaux de signalisation contiennent des informations utiles qui pourraient être ignorées
par les conducteurs pour diérentes raisons. Ces conducteurs sont également susceptibles d'ac-
corder moins d'attention aux signes de circulation lors de la conduite dans certaines conditions
météorologiques. Par conséquent, un système de reconnaissance des panneaux de signalisation
devient indispensable pour aider à réduire le nombre de morts sur les routes.

L'objectif de cette fonction est donc de lire et de reconnaître les diérents panneaux sur la
route. Lorsque le panneau est reconnu par le système, celui-ci lance l'achage d'un symbole
le représentant sur un écran. Cette représentation graphique restera achée jusqu'à ce que
le conducteur entre dans une nouvelle zone. En plus de l'achage, cette fonction permet d'in-
former le conducteur en lui fournissant des alertes en cas des panneaux de signalisation critiques.

17
 Détection et suivi des objets (Object Detection - Object Tracking (OD - OT)):
Il s'agit de la tâche de détecter des instances d'objets d'une certaine classe dans une image
et prédire son mouvement. Elle représente la fonction la plus importante de notre système vu
son rôle important dans la surveillance du trac, ainsi elle regroupe plusieurs fonctionnalités
comme : la détection des véhicules, des piétons, des animaux, etc. Elle permet aussi d'estimer
la distance entre le véhicule ego et l'objet détecté, ainsi estimer la direction de cet objet.

Cette fonction représente un domaine de recherche actif dans de nombreux pays développés
pour améliorer la sécurité routière, vu qu'elle représente la base de nombreuses applications
importantes et essentielles dans les nouveaux véhicules. Le dé principal de la détection des
objets est le développement d'un système able qui répond à plusieurs contraintes par exemple :
les vêtements diérents des piétons, leurs changements de taille et de forme, les conditions rou-
tières et environnementales variables. C'est ce qui rend cette fonction primordiale permettant
d'augmenter la robustesse de notre système [3].

Régulateur de vitesse adaptatif (Adaptive Cruise Control (ACC)): est un régula-

teur de vitesse "intelligent", qui permet non seulement de proposer une régulation automatique
de la vitesse, comme un régulateur de vitesse classique, mais aussi d'adapter la vitesse aux
conditions de circulation [4].

Le régulateur de vitesse adaptatif est équipé d'un RADAR (RAdio Detection And Ranging)
ou d'un laser logé soit dans la calandre de la voiture, soit sur le haut du pare-brise. Lorsque
l'on enclenche le régulateur de vitesse, le radar détecte les autres véhicules dans la circulation
et permet d'adapter la vitesse de la voiture en permanence, de façon à rester à une distance
déterminée de la voiture précédente.

Cette fonction permet donc de réduire le stress du conducteur en contrôlant automatique-

ment la vitesse de son véhicule et en maintenant une distance minimale prédénie par rapport
au véhicule précédent. Aujourd'hui, le système de régulation de vitesse adaptatif est souvent
couplé au système de freinage automatique d'urgence.

Freinage automatique d'urgence (Automatic Emergency Braking (AEB)): est un

système de sécurité permettant la détection d'un obstacle faisant l'objet d'un danger imminent.
Il informe le conducteur du danger et peut intervenir sur le système de freinage en cas d'inaction
de la part du conducteur, notamment à faible vitesse. Le système peut ainsi ralentir le véhicule
jusqu'à l'arrêt complet an d'éviter ou de minimiser un choc avec un élément extérieur ou un
autre véhicule [5].

1.3.3 Cahier des charges

L'objectif de ce projet de n d'études est d'intégrer une équipe de cinq stagiaires an de tra-
vailler dans un cadre professionnel sur un projet depuis l'élaboration de son cahier des charges
jusqu'à sa réalisation. Nous étions à la fois le client exprimant les besoins de son projet, le déve-
loppeur ainsi que le testeur, tout ceci sous un encadrement et un suivi de la part des encadrants.

Après que nous avions choisi les fonctions que nous souhaitons intégrer dans notre système, la
tâche qui m'a été conée est de :
 Faire une étude comparative du matériel et logiciel que nous devrons utiliser pour choisir
ce qui répond le mieux à nos besoins.
 Choisir un niveau de sécurité de notre système.
 Suivre le ux descendant du cycle en V pour la fonction de "Détection des lignes de voie".

18
  Passer au ux ascendant du cycle en V pour la fonction de "Reconnaissance des panneaux
de signalisation".
 Suivre le cycle en V pour la fonction de "Détection et suivi des objets".
Toutes ces tâches ont été faites suivant une certaine partition, entre les membres du projet, qui
sera décrite dans le prochain chapitre.

1.3.4 Planication du projet

La planication est l'étape clé dans la gestion de projet. C'est le moment crucial où va se
décider le découpage et la répartition des tâches, les besoins en ressources et la date prévision-
nelle de n. Ce qui va permettre de surveiller la réalisation des objectifs et l'avancement du
projet, ainsi de gérer l'aectation des ressources aux diérentes tâches.

Planier est le meilleur moyen de gagner beaucoup de temps, contrôler l'avancement des dié-
rentes étapes lors de l'exécution, ainsi se focaliser sur les tâches les plus importantes. En eet,
le manque de préparation représente l'une des principales raisons qui fait que certains projets
échouent, prennent du retard et dépassent la date limite. Ainsi, le fait de planier ses tâches à
l'avance constitue un élément de maîtrise essentiel dans l'organisation du temps. Pour s'y faire,
nous avons adopté le diagramme de Gantt.

Nos encadrants de stage ont mis en place un diagramme de Gantt préliminaire qui trace
toutes les tâches qui nous sont conées et qui s'étale sur la période du stage. Il se présente
comme-suit :

Figure 1.3  Diagramme de GANTT préliminaire du projet DeinAuge

Malgré les conditions dues à la pandémie du Coronavirus qui a nécessité que tout l'orga-
nisme passe à un mode de télétravail dès le tout début du projet, ceci n'a pas beaucoup impacté
le travail et l'avancement continu. Grâce au suivi régulier des encadrants industriels, ainsi le
sens de responsabilité qu'a montré tous les membres de l'équipe projet, nous avons pu accomplir
l'objectif visé à part la partie d'implémentation de notre prototype dans le matériel.

De ce fait, nous avons établi un nouveau plan qui répond aux nouvelles conditions tout en

19
maximisant le rendu de l'équipe. La liste des tâches suivante représente la répartition des dif-
férentes tâches et les dates de début et de n respectives de leurs réalisations:

Figure 1.4  Planication des tâches du projet DeinAuge

Ainsi, le nouveau diagramme de Gantt se présente comme-suit :

Figure 1.5  Diagramme de GANTT nal du projet DeinAuge

20
1.4 Conclusion

Ce chapitre a été consacré tout d'abord à la présentation de l'organisme dans lequel le

stage de n d'études s'est déroulé. Ensuite, il décrit le projet qui vise à concevoir un prototype
d'un système ADAS englobant plusieurs fonctionnalités. Vers la n, un planning de travail est
présenté en utilisant le diagramme de Gantt pour bien ordonnancer et planier l'acheminement
et l'avancement vers les objectifs voulus.

21
 CHAPITRE 2
MÉTHODOLOGIE DE TRAVAIL ET

ENVIRONNEMENT TECHNIQUE DU

PROJET

2.1 Introduction

An d'assurer le bon suivi des diérentes étapes du projet, il est nécessaire d'adopter une
méthode de travail convenable. Ainsi, la première partie de ce chapitre vise à exposer l'ensemble
des méthodes et outils de gestion qui ont été mis en place an d'assurer le bon déroulement du
projet.

La deuxième partie de ce chapitre vise à présenter l'environnement matériel et logiciel ex-

ploités dans la réalisation de ce projet, ainsi le niveau de sécurité requis en se basant sur la
norme ISO 26262.

22
2.2 Méthodologie de travail

2.2.1 Le cycle de développement en V

Un cycle de vie de développement logiciel, appelé aussi processus de développement logiciel
(Software Development Life Cycle (SDLC)). Il consiste à concevoir un plan détaillé décrivant
les phases distinctes et contenant les diérentes activités dans le but d'une meilleure gestion
de la planication. Ainsi, il représente la vision à long terme du logiciel en tant que produit,
depuis la planication initiale jusqu'à la maintenance et la retraite éventuelle de la demande
dûment remplie [6]. Grâce à cette planication, les organisations ainsi que les sociétés opérantes
dans le domaine du logiciel et surtout logiciel embarqué cherchent à produire rapidement et
ecacement des logiciels de haute qualité.

Il existe diérents modèles de cycle de vie dénis et conçus qui sont suivis pendant le pro-
cessus de développement logiciel. Chaque modèle de processus suit une série d'étapes uniques
à son type pour assurer le succès dans le processus de développement logiciel. Voici les modèles
SDLC les plus populaires suivis dans l'industrie :
 Cycle en Cascade (Waterfall Model).
 Cycle itératif (Iterative Model).
 Cycle spiral (Spiral Model).
 Cycle en V (V-Model).

Issu du monde de l'industrie, le cycle en V est devenu un standard de l'industrie du logiciel

depuis les années 1980. Depuis, avec l'apparition de l'ingénierie des systèmes, c'est devenu
un standard conceptuel dans de nombreux domaines de l'Industrie [7]. Le cycle en V est une
illustration des relations entre chaque phase du cycle de vie du développement et la phase de
test qui lui est associée.

Figure 2.1  Le cycle de développement en V

23
Comme le montre la gure ci-dessus, le cycle en V se caractérise par un axe horizontal représen-
tant le temps et par un axe vertical représentant le niveau d'intégration du système. Le cycle
se décompose comme suit :
 La branche descendante du cycle en V, appelée la phase de dénition et construction
du système. Elle représente la macro-phase de conception et de codage où le système
est graduellement décomposé en ses divers sous-systèmes et modules jusqu'au niveau
composant.
 Le sommet du cycle en V représentant la phase de mise en oeuvre et implémentation du
code.
 La branche ascendante du cycle en V, appelée la phase de Vérication & Validation (V
V) du système, où les composants une fois réalisés sont intégrés dans des ensembles et des
sous-systèmes graduellement plus grands, jusqu'à ce que le système complet soit construit.
Cette branche vise à valider le produit jusqu'à son acceptation par le client. Elle comprend
principalement une série de tests jusqu'à pouvoir valider que le produit répond au besoin
et aux exigences.
Les phases du cycle en V, comme présentées sur la gure 2.1, sont les suivantes:
• Exigences de l'utilisateur (User requirements): il s'agit de la première étape qui
consiste à créer le cahier des charges, contenant les diérentes exigences demandées par
le client, qui dénit généralement le besoin et les attentes par rapport au projet.
• Exigences du système (System requirements): les exigences du système sont re-
cueillies en analysant les besoins de l'utilisateur. Cette phase détermine ce que le système
idéalement devrait accomplir, mais ne spécie pas comment le logiciel sera conçu et sera
maintenu.
• Conception d'architecture (Architecture design): c'est la phase dans laquelle les
ingénieurs systèmes étudient les besoins spéciques des utilisateurs, analysent et com-
prennent les tâches du système proposé. Si l'analyse montre que l'une des exigences n'est
pas réalisable, l'utilisateur est informé du problème, une solution est trouvée et partagée,
et le document d'exigences est modié en conséquence.
Dans cette phase, une architecture logicielle est conçue pour déterminer les composants
dans le logiciel et l'établissement des relations entre ces composants. La phase de concep-
tion matérielle et logicielle est souvent appelée conception ou architecture de haut niveau
(Top level design/architecture).
• Conception de module (Module design): appelée également conception ou architec-
ture de bas niveau (Low level design/architecture (LLD)). Le système conçu est divisé
en très petites unités, appelées modules, où l'implémentation détaillée de chacun d'eux
est spéciée. Elle peut être un début de code ou une documentation qui dénit chaque
module.
• Implémentation (Implementation): c'est dans cette phase que nous avons fait le
codage et l'implémentation des modules conçus.
• Tests unitaires (Unit Testing): c'est une méthode par laquelle des unités individuelles
de code source sont testés pour déterminer si elles sont utilisables. L'unité est la plus petite
partie testable, généralement une fonction ou une procédure. Les tests unitaires sont créés
par des programmeurs et sont généralement réalisés par des tests de type "white box"
an de tester la logique interne du code et chaque branche possible dans la fonction pour
assurer la qualité du logiciel développé. C'est une étape où l'on teste que chaque module
développé durant la phase du LLD respecte le cahier des charges.
• Intégration logicielle et test (Software integration and testing): cette étape vise
à tester le comportement de l'application en intégrant progressivement toutes les briques
du logiciel. Les modules sont testés ensemble pour détecter les erreurs dans les interfaces
et l'interaction entre les composants intégrés.

24
 • Tests système ou de validation (System Testing): sont des tests eectués sur un
système complet et intégré et sont conçus pour évaluer la conformité du système aux
exigences spéciées. Le test du système est un test de "black box" et ne nécessite aucune
connaissance de la conception interne du code ou de sa logique.
• Tests d'acceptation par l'utilisateur (User acceptance Testing): c'est la phase
utilisée par le client pour déterminer s'il accepte le système. Ces tests permettent de tester
le logiciel dans le monde réel des utilisateurs.
Dans ce projet, nous avons travaillé sur tout le ux descendant jusqu'à l'implémentation, ainsi
que les phases de test unitaire et test système dans le ux ascendant.

2.2.2 La méthode Agile

La méthode Agile se base sur ce principe simple : planier la totalité du projet dans les
moindres détails avant de le développer est contre-productif. En eet, organiser tous les aspects
du projet est une perte de temps car il est rare que tout se passe exactement comme prévu.
Souvent, des aléas surviennent et forcent l'équipe à revoir la planication [8].

La méthode Agile recommande de se xer des objectifs à court terme. Le projet est donc
divisé en plusieurs sous-projets. Une fois l'objectif atteint, nous passons au suivant jusqu'à l'ac-
complissement de l'objectif nal. Cette approche est plus exible et laisse la place aux imprévus
et aux changements puisqu'il est impossible de tout prévoir et de tout anticiper.

Cette méthode repose sur une relation privilégiée entre le client et l'équipe projet. La sa-
tisfaction du client étant la priorité, l'implication totale de l'équipe et sa réactivité face aux
changements du client comme aux imprévus sont nécessaires. Le dialogue avec le client est
privilégié, c'est lui qui valide chaque étape du projet. L'évolution de ses besoins est prise en
compte et les ajustements sont eectués en temps réel an de répondre à ses attentes.

Le principe de base consiste à proposer une version minimale du logiciel puis à intégrer
des fonctionnalités supplémentaires à cette base, par processus itératif qui consiste à découper
le projet en plusieurs étapes d'une durée d'une à quatre semaines (deux semaines dans notre
cas ce qui fait 10 jours); ce sont les itérations (Sprints). Au cours d'une itération, une version
minimale du produit attendu est développée puis soumise, dans sa version intermédiaire, au
client pour validation. Les fonctionnalités sont ainsi intégrées au fur et à mesure du cycle de vie
sur un mode incrémental, le système s'enrichissant progressivement pour atteindre les niveaux
de satisfaction et de qualité requis.

L'objectif est d'obtenir, au terme de chaque itération, un sous-ensemble opérationnel du sys-

tème cible et, au terme de la dernière itération, la version nale du produit. Ceci est schématisé
sur la gure 2.2 ci-dessous pour les deux premières fonctions du système:

Figure 2.2  Le déroulement du projet - exemple des deux premières fonctions

25
 Avec l'approche Agile, rien n'est gé. L'équipe projet doit être capable de se remettre sans
cesse en cause et de chercher continuellement à évoluer. Dans notre cas, le client est à la fois
les encadrants qui nous ont choisi le thème du projet, ainsi que l'équipe projet qui a déni elle
même les exigences.
Pour la bonne implémentation de la méthode agile, il s'est avéré nécessaire de répartir notre
équipe en deux groupes, comme illustré dans le gure ci-dessous:

Figure 2.3  Répartition et organisation des équipes

Chaque groupe représente l'équipe développement d'une fonction ainsi que l'équipe test de
l'autre fonction développée par l'autre équipe. Chaque équipe, au bout de chaque sprint, dé-
signe un parmi ses membres pour être le chargé de coordination entre son équipe et celle des
autres, de coordination entre son équipe et le client (les encadrants) et de veiller que les tâches
de son équipe sont menées à terme dans les délais déterminés.

Durant le projet, nous avons déterminé un certain nombre de réunions dans la perspective
d'organiser le travail, assurer une communication continue entre tous les membres, et faire le
point sur l'avancement du projet:
• Sprint Planning meeting: nous organisons au début de chaque sprint une réunion de
planication, une sorte de négociation entre les Product Owners(PO)/les encadrants et
l'équipe technique. Durant cette réunion, les objectifs, tâches et travaux du sprint actuel
sont dénis.
• Stand up meeting: cette réunion est réalisée tous les jours à horaire régulier. Lors
de ce bref point quotidien, les membres d'équipe relatent les faits précédents, partagent
les actions actuelles et expriment les obstacles et dicultés rencontrés. Les product ow-
ners/encadrants ne sont pas présents lors de ce point.
• Sprint Retrospective meeting: durant cette réunion, qui vient à la n du sprint,
l'équipe prend le recul sur le sprint terminé et le processus de travail. Elle s'autoévalue
sur ce qui a bien fonctionné, ce qui doit se faire autrement et les axes d'amélioration.
• Open issues meeting: souvent au cours du sprint, il est tout à fait probable que l'on
rencontre un problème lié à une ou plusieurs tâches liées aux objectifs du sprint. Pour
cela, une réunion est organisée avec les Product Owners pour discuter ces problèmes et
essayer de trouver une solution dans les plus brefs délais.

26
 • Alignment meeting: c'est une réunion qui se tient entre les function owners et les
product owners dans le but d'aligner les points de vue et de s'assurer que le travail
eectué par léquipe est en conformité avec les objectifs du sprint et qu'il n'y ait pas de
déviement ou divergence.

Figure 2.4  Planning des réunions durant le sprint

2.2.3 Gestion de versions

Un gestionnaire de versions est un système qui enregistre l'évolution d'un chier ou d'un
ensemble de chiers au cours du temps dans le but de rappeler une version antérieure d'un
chier à tout moment [9].

Lorsque l'on travaille seul sur un projet sans utiliser de système de gestion de versions,
le processus de travail (Workow) consiste généralement à créer un répertoire de travail, puis
modier graduellement les données dans ce répertoire en faisant des modications successives,
jusqu'à obtenir une version nale (Release).

Cependant, lorsque l'on travaille à plusieurs sur le même projet, comme est le cas pour notre
système DeinAuge, ce workow atteint ses limites, donc un logiciel de gestion de versions de-
vient obligatoire car il permet de stocker un ensemble de chiers en conservant la chronologie
de toutes les modications qui ont été eectuées dessus.

Chez Alten, nous avons eu une petite formation an d'utiliser SVN (ou Subversion), mais
vu les conditions du télétravail, nous étions obligés de chercher une alternative puisque SVN
nécessite la connexion avec un serveur commun central.

SVN est un logiciel de gestion de versions qui fonctionne sur le mode client-serveur avec [10] :
 Un serveur informatique centralisé et unique où se situent :
- Les chiers constituant la référence (le "dépôt" ou "référentiel", ou "repository" en
anglais).
- Un logiciel serveur Subversion tournant en arrière-plan.
 Des postes clients sur lesquels se trouvent :
- Les chiers recopiés depuis le serveur, éventuellement modiés localement.
- Un logiciel client permettant la synchronisation entre chaque client et le serveur de
référence.

27
Ainsi, l'équipe projet a choisi d'adopter GIT qui est aussi un système de contrôle et gestion de
versions mais qui est décentralisé. Cela veut dire qu'il fonctionne bien même pour les membres
du même projet qui ne sont pas toujours connectés à un serveur commun vu qu'il est dispo-
nible hors ligne; ce qui répond parfaitement à notre besoin. Nous avons également choisi [11]
Bitbucket qui est un service web d'hébergement et de gestion de développement logiciel qui
utilise le logiciel de gestion de versions GIT. Bitbucket nous permet de créer un nombre illimité
de dépôts privés mais qui sont accessibles par cinq utilisateurs au maximum, chaque équipe
(Alpha et Beta) devrait donc créer son propre dépôt avec les deux encadrants.

La méthode de travail que nous avons suivi consiste à créer un dépôt sur Bitbucket, et
chaque membre va le cloner sur son système local. À chaque modication en local, la personne
devrait tout d'abord faire un PULL qui permet de mettre à jour son dossier en local par les
contributions apportées par les autres membres. Ensuite, la personne devrait faire un COMMIT
et PUSH dans le but d'enregistrer les modications apportées et les publier dans le dépôt sur
Bitbucket, représenté sur la gure 2.5 ci-dessous:

Figure 2.5  Exemple de dépôt sur Bitbucket

Ceci nous a permis d'avoir une visibilité et traçabilité sur la contribution de chacun dans le
projet, ainsi ça permet de faciliter le travail en équipe sans que quelqu'un aecte le travail d'un
autre.

D'autre part, nous avons également créé un dossier partagé entre les encadrants et toute
l'équipe projet dans le OneDrive de l'Oce 365. Microsoft OneDrive est un ensemble de services
en ligne : stockage et applications Word, Excel, PowerPoint et OneNote, dont les fonctionnalités
sont toutefois réduites par rapport aux logiciels installés sur un ordinateur. Ce service est une
manifestation du concept de cloud computing qui permet l'accès à des services informatiques
via Internet (le cloud) à partir d'un fournisseur [12].

C'est dans ce dossier partagé où les encadrants mettaient toutes les livraisons (Releases) du
projet que nous livrons, il est présenté comme suit:

28
 Figure 2.6  Dossier partagé pour les livrables du projet

2.3 Environnement technique du pro jet

Après l'expression du besoin par le client d'un prototype de système ADAS, et après que
nous avons élaboré le cahier des charges en choisissant les fonctions que nous souhaitons intégrer
dans ce système. La première tâche qui nous a été conée est de faire une étude comparative
(benchmarking) des diérents matériels et logiciels dont nous aurons besoin pour le développe-
ment et l'implémentation de notre système.

Le terme anglais "benchmarking" (ou benchmarker) désigne le fait de dresser une liste de
produits ou de services, de dénir des critères d'évaluation de la performance et de réaliser
l'étude comparative.

Un benchmark peut servir à une société an de dresser un panorama de l'existant avant de
lancer un nouveau produit, an de lui déterminer une valeur ajoutée sur laquelle la société
pourra communiquer à son lancement.

Mais un benchmark est également utile pour le grand public, an d'aider au choix d'un pro-
duit. Ce point représente exactement le cas dans ce projet, le travail réalisé dans cette étude
comparative est représenté sous les deux volets matériel et logiciel.

2.3.1 Environnement matériel

La plupart des ADAS sont commandés par les informations captées par la ou les caméras
situées derrière le pare-brise mais aussi par des capteurs lasers, ultrasons et radars situés derrière
les pare-chocs, la calandre, les rétroviseurs ou en arrière du véhicule. La liste du matériel
comporte :

2.3.1.1 Carte électronique

Vu le thème de notre projet, la carte devrait supporter la complexité de calcul dans les
fonctionnalités du système. Nous avons donc choisi une liste de cartes avec des caractéristiques
variées qui pourront supporter nos fonctions. Ces cartes sont représentées sur la gure 2.7 qui
suit:

29
 Figure 2.7  Les cartes électroniques proposées
L'objectif est d'essayer de prendre la meilleure décision et la plus convenable pour nos
besoins. Ainsi, nous avons déni un ensemble de critères de choix avec des coecients qui
varient selon la priorité. Nous pouvons avoir des critères avec des coecients négatifs comme
le cas du coût par exemple; plus le coût est élevé plus la note du choix de la carte va diminuer.
Ensuite sur une échelle de cinq étoiles (de Low jusqu'à Extremely High), nous avons attribué
une note pour chaque carte selon chaque critère, et nalement le choix de la carte repose sur
la somme des notes pondérée selon les critères de choix.

Consommation

Performance Flexibilité Coût Documentation d'énergie Disponibilité Total

×4 ×2 ×-3 ×1 ×-1 ×2

Jetson Nano * *** * *** * *** 15

Jetson TX2 4gb *** *** ** *** ** *** 19
Jetson TX2 **** *** *** *** *** *** 19
Jetson Xavier ***** *** ***** *** ** *** 18
Rpi 4 + edge TPU * * * ** * ** 8
Google Coral *** * * ** * ** 16
S22v234 **** * **** * ** ** 9

Table 2.1  Comparaison des cartes électroniques

Vu les diérentes caractéristiques présentées sur le tableau ci-dessus, notre choix s'est porté
sur la JETSON TX2 parce qu'elle est disponible en kit de développement et nous pouvons la
livrer vers le Maroc, quant à la TX2 4gb, elle est disponible sans kit de développement et nous
ne pouvons pas la livrer vers le Maroc.

NVIDIA Jetson TX2 ore un maximum de vitesse et d'ecacité énergétique dans un module
embarqué de calcul d'Intelligence Articielle (IA). Ce supercalculateur intégré sur un module
fournit des capacités de calcul IA à hautes performances à la périphérie des réseaux. Équipé
d'un processur graphique (Graphics Processing Unit (GPU)) NVIDIA Pascal, de 8 Go de mé-
moire dédiée, d'une bande passante de 59,7 Gb/s et d'une gamme variée d'interfaces matérielles
standardisées, Jetson TX2 constitue la solution idéale pour une grande variété de produits et
de congurations [13].

2.3.1.2 Caméra
Une caméra est un appareil de prise de vues destiné à enregistrer ou à transmettre des
images photographiques successives. Le but est de restituer l'impression de mouvement pour
diérentes applications dans plusieurs domaines.

Dans notre cas, la caméra représente le point d'entrée de toutes les fonctions de notre sys-
tème. De la même manière, nous avons choisi une liste de caméras avec des caractéristiques

30
variées qui pourront supporter nos fonctions. Ces caméras sont représentées sur la gure 2.8
suivante:

Figure 2.8  Les caméras proposées

De la même manière, nous avons déni un autre ensemble de critères de choix spéciques aux
caméras avec des coecients qui varient selon la priorité de chacun. Ensuite sur une échelle de
trois étoiles (de Low jusqu'à High), nous avons attribué une note pour chaque caméra selon ses
performances, comme le montre le tableau suivant:

Résolution
Caméra Interface ×1 ×1 Qualité ×2 FPS ×1 Coût ×-1 Total

Aptina Ml5100 Webcam ** ** ** *** ** 9

OmniVision OV2710 * ** * *** ** 6
DVR HD Vision * ** *** ** * 10
OV5647 ** ** ** ** ** 8

Table 2.2  Comparaison des caméras

En comparant les performances des diérentes caméras, nous avons opté pour la DVR HD.

2.3.1.3 Lidar
Pour notre système, la fonction ACC nécessite soit un lidar (Light Detection And Ranging)
qui va permettre de calculer la distance entre le véhicule ego et la cible, soit un radar qui va
permettre de calculer sa vitesse. En cherchant les diérentes solutions, nous étions limités par le
budget vu que les diérents radars et lidars que nous avons trouvé étaient à un prix très élevé.
Heureusement, nous avons trouvé des lidars 2D (voir Annexe A) à des prix plus raisonnables
et qui sont convenables pour notre prototype. Les deux lidars proposés sont représentés sur la
gure 2.9 suivante:

Figure 2.9  Les lidars proposés

La télédétection par laser ou lidar, est une technique de mesure à distance fondée sur l'ana-
lyse des propriétés d'un faisceau de lumière renvoyé vers son émetteur. À la diérence du
RADAR qui emploie des ondes radio ou du sonar qui utilise des ondes acoustiques, le lidar uti-
lise de la lumière (du spectre visible, infrarouge ou ultraviolet). Celle-ci est quasiment toujours
issue d'un laser, et donc cohérente.

31
 De la même manière, nous avons déni un autre ensemble de critères de choix spéciques
aux lidars proposés avec des coecients qui varient selon la priorité de chacun. Ensuite sur une
échelle de trois étoiles (de Low jusqu'à High), nous avons attribué une note pour chaque lidar
selon ses performances, comme le montre le tableau suivant:

LIDAR 2D Range ×4 Coût ×-3 Disponibilité ×1 Total

Lidar Lite v3 *** *** *** 6

TFMini Lidar ** * *** 8

Table 2.3  Comparaison des lidars

En comparant entre les critères des deux lidars, nous avons opté pour le TFMini Lidar.
La mesure de distance est basée sur la méthode Time Of Flight (TOF), temps de vol, ce qui
permet de mesurer précisément les distances jusqu'à 12m.

2.3.1.4 Capteur ultrason

Pour notre système, la fonction de détection des lignes de voie (LD) implique la détection
de l'angle mort (Blind Spot) dont le but principal est de prévenir le conducteur lorsqu'un autre
usager de la route se trouve dans son angle mort lorsqu'il souhaite dépasser un véhicule, se
rabattre ou changer de voie, par exemple.

Donc, en prenant en compte le critère de coût, deux capteurs ultrasons sont susants pour
réaliser le prototype de la fonctionnalité de détection d'angle mort. Le système sonar comprend
deux émetteurs d'ondes sonores placés dans le pare-choc arrière du véhicule, un de chaque côté.
Ils émettent des ondes sonores à intervalles réguliers, qui se répercutent sur les objets présents
dans la zone à surveiller.
De la même manière, nous avons comparé entre les deux capteurs ultrasons sur la gure 2.10
et le tableau 2.4 suivants:

Figure 2.10  Les capteurs ultrasons proposés

Ultrasons Portée Coût Voltage

HC-SR04 2cm - 400cm 3.95 $ 5V

Glove - Ultrasonic Distance Sensor 3cm - 350cm 3.99 $ 3.3 / 5 V

Table 2.4  Caractéristiques des capteurs ultrasons proposés

Comme précédemment, sur une échelle de trois étoiles (de Low jusqu'à High), nous avons
attribué une note pour chaque ultrason selon ses performances, comme le montre le tableau
suivant:
Ultrasons Portée Coût Disponibilité Total

HC-SR04 * * *** 5
Glove - Ultrasonic Distance Sensor * * *** 5

Table 2.5  Comparaison des ultrasons

32
En se référant au tableau 2.5, nous constatons que les deux capteurs présentent les mêmes
critères. Nous avons donc choisi le HC-SR04 car il présente un mètre de plus de couverture.

Le tableau 2.6 suivant est un récapitulatif technique et nancier de la charge du projet. Nous
avons deux coûts, l'un représentant le montant de réalisation du produit et l'autre le montant
de la réalisation et du stock en cas de défaut d'un matériel.

Matériel Nombre Nombre d'exemplaire Prix utile Total

utile souhaité en DH

Camera DVR HD Vision 1 2 228,98 547,96

Ultrasonic HC-SR04 2 5 76,21 190,52
TFMini Lidar 1 3 348,29 1044,87
Jetson TX2 1 1 4432,00 4432,00
Ecran LCD HDMI USB 1 1 580,00 580,00
Carte mémoire 32G 1 3 100,00 300,00
Autre(connecteur,batterie,...) RAS RAS 500,00 1000,00
TOTAL 6265,48 8005,35

Table 2.6  Récapitulatif du benchmarking matériel

2.3.2 Environnement logiciel

2.3.2.1 Langage de programmation
Suite au benchmark eectué entre les diérents langages de programmation les plus utilisés
dans le monde de l'embarqué, et dans lequel plusieurs critères entrent en considération an de
pouvoir choisir le langage qui satisfait nos besoins, nous avons obtenu le tableau comparatif
suivant:
Langage Popularité Simplicité Rapidité de Disponibilité de Gestion de Performance Maitrise Total

développement bibs d'IA mémoire

Python *** *** *** *** * ** *** 18

C/C++ ** ** * ** *** *** * 14
Java * ** * * ** ** ** 11

Table 2.7  Comparaison des langages de programmation

Nous avons donc choisi le langage Python vu sa simplicité, rapidité et popularité. Il est le plus
convenable vu la disponibilité de plusieurs bibliothèques d'IA dont nous aurons besoin, comme
la bibliothèque de traitement d'images OpenCV (Open Source Computer Vision Library) qui est
une bibliothèque proposant un ensemble de plus de 2500 algorithmes de vision par ordinateur.
Elle est développée pour qu'elle soit la bibliothèque de référence pour la vision par ordinateur,
ainsi bien dans le monde de la recherche que celui de l'industrie.

2.3.2.2 Environnement logiciel des tests unitaires

Pour le test unitaire, vu que nous ne disposons pas d'un outil de test et d'une plateforme
d'exécution et de recensement des résultats obtenus, nous étions amenés à trouver une solution
opensource et qui convient à l'environnement de notre projet. Nous avons donc trouvé :

- Le module unittest de python qui est un framework des tests unitaires, il gère l'automati-
sation des tests, le partage de code pour la mise en place et la nalisation des tests, l'agrégation
de tests en collections, et l'indépendance des tests par rapport au framework utilisé. Il nous a

33
permis de rédiger et exécuter les tests unitaires, dont je présenterai les détails dans le prochain
chapitre.

- Le plugin pytest-html pour la génération du rapport des résultats des tests.

- Le module coverage de python pour mesurer la couverture de code des programmes
Python. Il surveille le programme, note quelles parties du code ont été exécutées, puis analyse
la source pour identier le code qui aurait pu être exécuté mais ne l'a pas été. La mesure de la
couverture est généralement utilisée pour évaluer l'ecacité des tests.

2.3.2.3 Environnement logiciel des tests système

Pour collecter les données et valider la partie logicielle des systèmes ADAS, il est nécessaire
que le véhicule roule sur de longues distances ce qui est dicile de le faire à l'aide des véhicules
disponibles chez les constructeurs automobiles.

Donc pour compléter ceci, nous étions amenés à faire des recherches concernant les outils de
simulation virtuels an de créer nos scénarios de tests et générer les videos de tests.
Après plusieurs recherches, vu la non disponibilité de plusieurs simulateurs open source, nous
avons trouvé les solutions suivantes:

- Carla Simulator : c'est un simulateur de conduite autonome open source qui a été
développé pour soutenir le développement, la formation et la validation des systèmes de conduite
autonomes.

Figure 2.11  CARLA Simulator - Simulateur de conduite

La plateforme de simulation prend en charge la spécication exible des suites de capteurs, les
conditions environnementales, le contrôle total de tous les acteurs statiques et dynamiques, la
génération des scénarios de tests et bien plus encore. Nous pouvons utiliser CARLA comme
un robuste Software In Loop (SIL) où nous pouvons valider le software des systèmes ADAS
et le software des véhicules autonomes à l'aide de sa modélisation des diérents actionneurs et
capteurs du véhicule.

En revanche, CARLA présente quelques inconvénients:

• Manque de documentation en ligne.
• Nécessité d'un PC performant : Pour travailler avec la plateforme il est nécessaire
d'avoir un pc performant qui contient une carte GPU d'un minimum 2gb de mémoire.
Ce qui rend l'utilisation de cette plateforme dicile. En plus, dans notre cas comme nous al-
lons obtenir par la suite l'ADAS Hardware In Loop (HIL), nous avons intérêt plus de créer des

34
scénarios de tests que de tester le software dans la plateforme CARLA, ce qui nous donne une
autre alternative pour créer les scénarios, c'est l'utilisation des moteurs des jeux vidéos.

- Unity : c'est un moteur de jeu multiplateforme open source développé par Unity Techno-
logies, c'est l'un des moteurs les plus faciles à manipuler ainsi que les diverses fonctionnalités
qui nous orent pour créer nos scénarios rapidement.

Figure 2.12  Unity - Moteur de jeu

Ce moteur de jeu est une bonne alternative pour créer les scénarios de tests, plusieurs docu-
mentations et tutoriels gratuits sont disponibles pour nous aider à créer les cartes routières
ainsi que la modélisation des diérentes situations de circulation.

Par contre, il présente quelques limitations par rapport à quelques cas de tests, donc nous
avons également utilisé CARLA mais juste pour la génération des vidéos de tests que nous ne
pouvons pas faire sous Unity (Plus de détails dans la partie du test dans le prochain chapitre).

2.3.3 Choix du niveau de criticité du projet

Aujourd'hui, les véhicules disposent de systèmes d'électronique embarqués de plus en plus
nombreux et de plus en plus complexes. Les défaillances de ces systèmes peuvent avoir des
conséquences dramatiques. C'est pourquoi, il est indispensable d'identier les risques potentiels
de défaillances de ces systèmes et de veiller à les évitér ou les réduire. Les constructeurs de-
vraient donc fort probablement utiliser la conformité à la norme ISO 26262 comme moyen de
qualier les composants et les fournisseurs potentiels de composants électriques et/ou électro-
niques (E/E).

Ainsi, et en prenant compte des diérentes exigences et limitations de notre prototype, il

convient en particulier de dénir un niveau d'intégrité de sécurité automobile (ASIL), c'est
à dire de classier les risques an de dénir les exigences de sécurité nécessaires pour être
conforme à la norme ISO 26262.

2.3.3.1 Norme ISO 26262

En terme de sécurité fonctionnelle des systèmes E/E, les constructeurs automobiles se sont
progressivement équipés avec des méthodes, outils et référentiels normatifs ecaces et recon-
nus dont le principal est la norme International Organization for Standardization 26262 (ISO
26262) [14].

Depuis sa sortie en 2011, la norme ISO 26262 est devenue le référentiel normatif utilisé par
la plupart des industriels de l'automobile dans le cadre de la sûreté de fonctionnement des
systèmes E/E incorporés au sein des véhicules routiers.
La norme se compose de 10 parties comme présenté sur la gure 2.13:
1. Vocabulaire.
2. Gestion de la sûreté de fonctionnement.
3. Phase de projet.

35
 4. Développement du produit au niveau du système.
5. Développement du produit au niveau du matèriel (électronique).
6. Développement du produit au niveau du logiciel.
7. Production et utilisation.
8. Processus d'appui.
9. Analyses liées aux niveaux d'intégrité de sûreté automobile et à la sûreté de fonctionne-
ment.
10. Lignes directives relatives à l'ISO 26262.

Figure 2.13  Les parties de la norme 26262

Nous nous intéressons dans cette étape de projet à la partie 9 qui dénit les niveaux d'in-
tégrité ASIL pour les composants des systèmes embarqués dans les véhicules.

2.3.3.2 Les niveaux d'intégrité ASIL

La norme ISO 26262 dénit une méthodologie de cotation des risques appelée cotation ASIL
(Automotive Safety Integrity Level). Il existe 4 niveaux libellés "ASIL A" (le moins critique)
à "ASIL D" (le plus critique) et plus la criticité est élevée, plus les tâches et les vérications
à eectuer seront nombreuses. De plus, la norme ajoute un cinquième niveau appelé "QM"
(Quality Management), parfois qualié de "ASIL 0" il s'agit d'un niveau où le risque associé
étant faible ou raisonnable, il ne nécessite pas de mesures de sûreté de fonctionnement.

La dénition des niveaux d'ASIL est qualitative et dénie par trois métriques devant être
appliquées à toute situation dangereuse détectée en phase d'analyse des risques :
• Sévérité: dénit la gravité ou l'intensité des dommages ou des conséquences pour la
vie des personnes (passagers et usagers de la route) et des biens causés par la violation
des objectifs de sécurité. L'ordre de sévérité est : S0 pour aucune blessure, S1 pour les
blessures légères, S2 pour les blessures graves et mettant la vie en danger, et S3 pour les
blessures mortelles avec survie incertaine ou décès.
• Exposition: c'est la fréquence à laquelle le véhicule se trouve dans une situation dan-
gereuse ou risquée qui peut causer des dommages aux personnes et aux biens. Cinq ni-
veaux d'exposition sont attribués au composant automobile évalué, couvrant : E0 pour

36
 une probabilité invraisemblable, E1 pour une très faible probabilité, E2 pour une faible
probabilité, E3 pour une probabilité moyenne, et E4 pour une probabilité élevée.
• Contrôlabilité: détermine dans quelle mesure le conducteur peut contrôler le véhicule
et agir de lui-même pour prévenir le danger ou la blessure. L'ordre de contrôlabilité est
déni comme suit : C0 pour contrôlable en général, C1 pour facile à contrôler, C2 pour
une contrôlabilité normale, et C3 pour dicilement contrôlable ou incontrôlable.
Les niveaux ASIL sont attribués sur la base du tableau d'allocation suivant déni par la norme :

Table 2.8  Allocation des niveaux ASIL

Ainsi, la détermination de l'ASIL est le résultat d'une analyse des dangers et d'une évaluation
des risques. Dans le contexte de la norme ISO 26262, un danger est évalué en fonction de l'im-
pact relatif des eets dangereux liés au système, et en fonction des probabilités relatives que le
danger manifeste ces eets.

C'est à dire que chaque événement dangereux est évalué en fonction de la gravité des bles-
sures possibles, ainsi que de la fréquence à laquelle le véhicule est exposé à ce danger, et enn
de la probabilité relative qu'un conducteur attentif puisse agir pour prévenir la blessure dûe au
danger. De cette manière, nous avons déni le niveau ASIL de notre système.

2.3.3.3 Niveau ASIL du projet

Pour le présent projet, nous avons donné un cas critique représentant un danger pour chaque
fonction an de déterminer le niveau ASIL de tout le système. Le choix des métriques pour
évaluer chaque danger est basé sur terrain et sur le retour des experts en Safety. Ainsi, nous
avons essayé de rassembler ces informations et les résumer sur le tableau suivant:

37
 Table 2.9  Détermination du niveau ASIL du système DeinAuge

Ainsi, le niveau d'intégrité ASIL du système DeinAuge est donc un ASIL B. Le tableau suivant
est un exemple de l'allocation des niveaux ASIL pour la fonction LD :

Table 2.10  Détermination du niveau ASIL de la fonction LD

2.4 Conclusion

Plusieurs méthodes et outils ont été adoptés an de bien avancer dans le projet. Ainsi, ce
chapitre décrit le cycle en V utile dans la gestion de projet et la méthode Agile qui organise les
réunions et échanges inter-équipes et avec les encadrants. Ensuite, une présentation de Git et
SVN qui sont chacun des systèmes de workow et de contrôle de version viables, mais pour des
raisons diérentes, ces raisons qui nous ont donné l'opportunité de découvrir les deux durant
ce stage.

Ce chapitre a fait aussi l'objet d'une présentation de l'environnement technique du projet

ainsi que la norme que nous avons suivi. Le chapitre suivant décrit la phase de réalisation de
notre système qui a suivi les diérentes étapes du cycle en V.

38
 CHAPITRE 3
RÉALISATION DU SYSTÈME DEINAUGE

3.1 Introduction

Ce dernier chapitre constitue le corps du rapport. Il met en évidence les diérentes étapes
suivis du cycle en V pour réaliser les fonctions du système. Il est divisé en deux parties.

La première partie décrit les tâches faites pour réaliser quelques étapes du ux descendant
du cycle en V de tout le système ainsi réaliser quelques étapes de ce même ux pour les deux
fonctions "Lane Detection" et "Object Detection".

La deuxième partie présente les tâches faites pour réaliser quelques étapes du ux ascendant
du cycle en V de la fonction "Trac Sign Recognition".

39
3.2 Flux descendant du cycle en V

3.2.1 Ingénierie des exigences

Le glossaire standard de l'IEEE (Institute of Electrical and Electronics Engineers) de ter-
minologie du génie logiciel dénit une exigence comme [15]:
1. Condition ou capacité requise par un utilisateur pour résoudre un problème ou atteindre
un objectif.
2. Une condition ou une capacité qui doit être remplie ou possédée par un système ou un
composant de système pour satisfaire un contrat, une norme, une spécication ou tout
autre document formellement imposé.
3. Une représentation documentée d'une condition ou d'une capacité comme en 1 ou 2.

Une exigence est donc un contrat entre un fournisseur et son client, qui doit être décrite sous la
forme d'une action qui précise ce que l'on veut faire. Ecrire une exigence, c'est collecter toutes
les caractéristiques des fonctions rendues par le système en terme de nalité.

L'ingénierie des exigences est le processus de dénition, de documentation et de maintien

des exigences. Il s'agit d'un processus de collecte et de dénition des services fournis par le
système. Le processus d'ingénierie des exigences comprend les activités principales suivantes
[16]:

3.2.1.1 Élicitation des exigences

L'élicitation des exigences est la pratique qui consiste à rechercher et découvrir les exigences
d'un système auprès des utilisateurs, des clients et d'autres parties prenantes. Cette pratique
est également appelée "Collecte des exigences".

Durant cette phase, nous avons organisé des réunions avec les encadrants, qui représentent
les premiers clients de notre système, an de bien comprendre leurs besoins et mettre en lumière
les diérentes contraintes que nous avons à savoir le temps de réalisation et le budget donné
pour le matériel, ce qui nous a permis de mieux comprendre le thème de notre projet. Ensuite,
les membres de toute l'équipe ont déni les diérentes fonctions que le système devrait intégrer.

À cette étape, nous avons collecté les diérentes exigences du système qui dénissent en gé-
néral les attentes des clients par rapport à ce projet. Ces exigences se résument par la réalisation
d'un prototype d'un système ADAS qui englobe les fonctions suivantes:
 Détection des lignes de voie (LD).
 Reconnaissance des panneaux de signalisation (TSR).
 Détection et suivi des objets (OD - OT).
 Régulation adaptative de la vitesse (ACC).
 Freinage automatique d'urgence (AEB).
Ces fonctions sont dénies avec plus de détails dans la description du système dans le premier
chapitre. En divisant le projet en plusieurs fonctions, ceci facilite la prochaine tâche qui est la
spécication des exigences de chaque fonction à part.

3.2.1.2 Spécication des exigences

La spécication des exigences est l'étape utilisée pour traduire les besoins du client en des
modèles formels d'exigences au niveau logiciel ou système, y compris les exigences fonction-
nelles et non fonctionnelles. Pendant la spécication, il peut être nécessaire de mieux connaître

40
le problème, ce qui peut à nouveau déclencher le processus d'élicitation.

Avant de passer au processus de spécication des exigences suivi dans notre projet, il
convient tout d'abord de diérencier entre une exigence client et une spécication des exi-
gences du système ou du logiciel. En fait, les exigences client sont rédigées en langage naturel
et ne comportent aucun détail technique, dans le but de leur permettre de vérier que le sys-
tème décrit exactement ce qu'ils ont déni. D'autre part, les exigences système ou logicielles
sont destinées aux développeurs, elle contiennent des détails fonctionnels et non-fonctionnels.
Elles sont clairement et rigoureusement spéciées, car leur but est d'informer le développeur
ce qu'il est censé construire. Ainsi, elles doivent contenir susamment de détails pour que le
développeur puisse les prendre et les utiliser pour concevoir et développer le système.

Pour rédiger le document des exigences, nous nous étions mis d'accord avec le client sur le
modèle des attributs suivant:
 Req_ID: il s'agit de l'identiant de l'exigence, celui-ci permet, comme son nom l'indique,
de pouvoir se référer à l'exigence de façon rapide et unique.
 Category: ce champ comporte:
- Heading: cette ligne est dédiée à un titre qui regroupe d'autres exigences.

- Comment: cette ligne est dédiée aux commentaires.

- Functional Requirement: une exigence fonctionnelle indique qu'elle décrit et spé-

cie quelque chose que le système livré doit être capable de faire.
- Non-Functional Requirement: une exigence non fonctionnelle indique qu'elle
décrit les détails techniques, les limites, le rendement et la qualité du système.
- Interface Requirement: une exigence relative à l'interface indique qu'elle décrit
les interfaces du système, comme les types et formats de données ou les protocoles
de communication.
- Business Requirement: une exigence opérationnelle vise la gestion générique du
projet, habituellement attribuée à la "gestion du programme".
 Text: permet de décrire l'exigence en texte.
 Discipline: cet attribut permet de décrire le domaine d'impact de l'exigence à savoir:
mécanique, électrique, optique, outils, ou logiciel. Pour nos fonctions, les exigences de
celles-ci couvraient généralement le domaine du software.
 Testability: cet attribut indique l'état d'acceptation des exigences en ce qui concerne la
testabilité et la vériabilité. Il peut être :
- No: une exigence n'est pas testable si elle a été supprimée, ou en présence de risques
élevés de dommages personnels ou matériels, ou si elle est non fonctionnelle, etc.
- Conditional : le test de certaines exigences peut être conditionné par l'accord du
client, ou par certaines conditions, etc.
-Yes: si l'exigence peut être acceptée sans aucun problème de testabilité.
 Feasability: ce champ indique l'état d'acceptation des exigences concernant la faisabilité
dans la portée du projet et comporte les valeurs suivantes :
- No: si l'exigence ne peut être acceptée en raison de coûts élevés, d'eorts élevés ou
de limites techniques.
- Conditional : par exemple si une exigence ne peut être développée par manque et
non disponibilité d'outils ou de librairies nécessaires pour son développement, etc.
- Yes: si l'exigence peut être acceptée sans aucun problème de faisabilité.

41
  Safety: ce champ permet de dénir le niveau de sécurité ou d'impact de la fonction sur
le système global, il peut être: QM, ASIL A, ASIL B, ASIL C ou ASIL D. Dans notre
cas, les trois premières fonctions que nous avons entamés avaient un niveau de sécurité
ASIL B.
 Required Test Type: indique le type de test requis pour cette exigence, il peut être:
test système, test unitaire, test sur véhicule, etc.
 Priority: décrit le niveau d'intégrité de chaque exigence. Dans le sens où le non-respect
d'une exigence peut créer un grand impact à l'intégrité total de la fonction voire du
système entier.
 Status_d: celle-ci passe par plusieurs étapes, an de valider l'exigence, avant d'avoir
le status d'exigence approuvée par le PO.
 Comments: cet attribut permet de clarier l'exigence et de réduire toute ambiguïté pour
la bonne mise en oeuvre de celle-ci.
 Review Comments: cet attribut est dédié au commentaires des personnes qui font la
revue.

Je faisais partie de l'équipe Alpha qui s'est chargée de la rédaction du document des exi-
gences pour les deux sous fonctions du système LD et OD. Nous avons donc entamé cette tâche
tout en respectant les diérentes caractéristiques d'une bonne exigence (voir Annexe B).

Le document des exigences est présenté comme suit :

• Les exigences logicielles et système de la fonction LD :
Les gures suivantes présentent des extraits du document des exigences de la fonction
"Détection des lignes de voie", nous avons rédigé 29 exigences système et logicielles an
de satisfaire les besoins du client exprimés lors de la phase de l'élicitation.

Figure 3.1  Extrait des exigences système de la fonction LD

Figure 3.2  Extrait des exigences logicielles de la fonction LD

• Les exigences logicielles et système de la fonction OD :
De la même manière, la gure suivante présente un extrait du document des exigences de
la fonction "Détection des objets", nous avons rédigé 20 exigences système et logicielles.

42
 Figure 3.3  Extrait du document des exigences de la fonction OD
3.2.1.3 Vérication et validation des exigences
Vérication : Il s'agit de l'ensemble de tâches qui garantit que le logiciel implémente cor-
rectement une fonction spécique.

Validation : Il s'agit d'un ensemble diérent de tâches qui garantit que le logiciel qui a été
construit est traçable aux exigences du client.

Si les exigences ne sont pas validées, les erreurs dans les dénitions des exigences se propage-
raient aux étapes successives, ce qui entraînerait beaucoup de modications et de remaniements.
Les principales étapes de ce processus sont les suivantes :
 Les exigences devraient être conformes à toutes les autres exigences (pas de conit).
 Les exigences devraient être complètes.
 Les exigences devraient être réalisables.
Le respect des caractéristiques d'une bonne exigence, les vérications entre collègues, la pré-
paration des cas de test, les tests unitaires et systèmes sont aussi parmi les méthodes utilisées
pour vérier et valider les exigences.

3.2.1.4 Gestion des exigences

La gestion des exigences est le processus d'analyse, de documentation, de suivi, de priorisa-
tion et d'acceptation des exigences. Elle permet aussi le contrôle de la communication avec les
intervenants concernés an d'intégrer les changements spéciés même à des étapes ultérieures.

De ce fait, cette étape tient compte de la nature changeante des exigences, il convient donc
de veiller à ce que le document des exigences soit modiable au fur et à mesure. Pouvoir modi-
er le logiciel conformément aux exigences de manière systématique et contrôlée est un élément
extrêmement important du processus d'ingénierie des exigences.

3.2.2 Architecture matérielle du système

Le système DeinAuge étant un produit automobile réel, il est logique qu'il comporte plu-
sieurs parties matérielles destinées à être embarquées. En analogie avec les systèmes embarqués
automobiles, dont le principe repose sur l'interaction entre un calculateur central et un environ-
nement composé de capteurs et d'éventuels actionneurs, le système DeinAuge repose, lui aussi,
sur une unité de traitement avec plusieurs capteurs nécessaires pour les diérentes fonctions du

43
système. Ci-dessous un récapitulatif de l'ensemble du matériel déjà présenté lors de la partie
des résultats du benchmarking, il s'agit entre autres de :
 La carte électronique Jetson TX2: c'est le coeur de notre système, c'est elle qui va
permettre le traitement de toutes les informations ainsi que l'élaboration des signaux.
 La caméra: utilisée dans les trois parties du projet que ce soit dans la détection des
objets ou des lignes de la voie ou dans la reconnaissance des panneaux de signalisation.
Cette caméra est en d'autres termes une entrée de notre système, elle va nous permettre
de capter des informations visuelles pour les transmettre au microcontrôleur.
 Le lidar: permet de calculer la distance longitudinale entre le véhicule ego et le véhicule
cible devant, cette information est très importante pour la fonction ACC.
 L'ultrasonique: permet de récupérer la distance latérale d'un véhicule aux alentours du
véhicule ego, il est utilisé pour donner les informations sur l'angle mort utile pour décider
la possibilité de changement de voie.
 L'écran tactile HD: c'est l'élément de commande c'est à dire l'intermédiaire entre le
système et l'utilisateur. Il va également permettre l'achage des messages, des statuts, de
la projection de sa route, etc. Cet écran communiquera avec la carte par l'intermédiaire
d'un câble HDMI (High Denition Multimedia Interface).
 La batterie: elle va servir d'alimentation pour le système ainsi que quelques capteurs.
Après ce bref récapitulatif du matériel, nous abordons maintenant les diérentes liaisons
qui constituent l'architecture de haut niveau du système. Comme le montre le schéma sur la
gure 3.4 ci-dessous, la carte Jetson TX2 est reliée par des câbles de connexions aux diérents
capteurs selon le type de communication exigée par chacun. Nous avons diérencié entre les
deux types de transfert, soit d'énergie ou d'information. L'architecture matérielle du projet est
donc présenté comme suit :

Figure 3.4  Architecture matérielle du système DeinAuge

44
3.2.3 Conception du système
La phase de conception est une phase indispensable qui se situe avant la phase de déve-
loppement, programmer sans conception c'est comme bâtir une maison sans plan. L'activité
de conception permet de traduire les besoins fonctionnels issues du cahier des charges et de la
spécication des exigences dans un langage plus professionnel et compréhensible par tous les
individus intervenants dans la réalisation et l'utilisation de l'application.

Après la présentation de l'architecture matérielle du système, la phase qui vient c'est la

conception des principales interactions, entre les diérentes fonctions constituant le système, à
l'aide du langage UML.

Le langage de Modélisation Unié (Unied Modeling Language (UML)) est un langage de

modélisation graphique à base de pictogrammes conçu pour fournir une méthode normalisée
pour visualiser la conception d'un système. Il est couramment utilisé en développement logiciel
et en conception orientée objet [17].

Nous avons réalisé un diagramme de cas d'utilisations de tout le système DeinAuge, et par
la suite un diagramme d'activité pour chaque fonction à part.

3.2.3.1 Diagramme de cas d'utilisation du système

Il s'agit d'un diagramme UML qui décrit le système du point de vue de l'utilisateur, et
permet de classer les acteurs et de structurer les objectifs du système. Le diagramme de cas
d'utilisation de notre système DeinAuge ci-dessous permet d'identier les diérentes fonction-
nalités que doit fournir notre système, ainsi que les dépendances entre elles.

Figure 3.5  Diagramme de cas d'utilisation du système DeinAuge

45
3.2.3.2 Diagramme d'activité
Le diagramme d'activité est un diagramme comportemental d'UML, permettant de repré-
senter le déclenchement des événements en fonction des états du système et de modéliser des
comportements en exécution synchronisée. C'est un diagramme qui permet de décrire le ux
de travail (workow) d'un cas d'utilisation ou d'une opération bien précise.
 Diagramme d'activité de la fonction LD :
Le diagramme d'activité de la fonction LD est représenté par la gure ci-dessous :

Figure 3.6  Diagramme d'activité de la fonction LD

D'après ce diagramme, nous pouvons voir que le point d'entrée à notre fonction de détection
des lignes de voie est de dépasser une vitesse de 80 Km/h. Ensuite, nous recevons un ux vidéo
depuis la caméra, sur lequel nous allons appliquer plusieurs étapes an d'atteindre la détection
des lignes de la voie. Une fois cette tâche est accomplie, la fonction devrait faire plusieurs tests
et conditions, représentés sur le diagramme par des losanges. Ces conditions vont permettre
d'assurer les deux sous fonctionnalités de LCW et LKA. Ces deux dernières avec la détection
du blind spot, qui vérie s'il y a un obstacle dans l'angle mort du véhicule, vont nous générer

46
des alertes audios appropriés à chaque cas. Ces alertes sont utiles pour notier le conducteur
de ce qu'il a fait an de le guider au maximum lors de sa conduite.
 Diagramme d'activité de la fonction OD-OT :
Le diagramme d'activité de la fonction OD-OT est représenté par la gure ci-dessous :

Figure 3.7  Diagramme d'activité de la fonction OD-OT

L'algorithme commence par capturer les séquences d'images à l'aide de la caméra, en pa-
rallèle avec une analyse de l'environnement à travers le lidar. Les séquences d'images capturées
seront ensuite prétraitées pour répondre à la taille de l'entrée du réseau de neurones de détec-
tion des objets qui va localiser et classier les diérents objets à savoir les véhicules à quatre
roues et deux roues, les piétons, les animaux et les panneaux de signalisation.

An de suivre et estimer le mouvement des objets dynamiques situés dans l'environnement
extérieur du véhicule, il faut assigner à chaque objet un ID spécique puis pour chaque objet
suivi, nous calculons diérents paramètres comme la distance à la collision en utilisant les don-
nées du lidar ainsi que la prédiction de sa prochaine position. Enn nous achons toutes ces
informations utiles sur l'écran.

En fait, nous avons ajouté les panneaux de signalisation comme une classe dans cette fonc-
tion car lors du développement de la fonction TSR, le groupe Beta utilisait aussi un réseau de
neurones de détection des objets. Ce qui nous fera optimiser dans la phase d'implémentation
sur le matériel par la suite, du fait que nous n'aurons qu'un seul modèle d'Object Detection qui

47
servira pour les deux fonctions. Ce modèle va faire la localisation et la classication de tous les
objets du système y compris les panneaux. Et par la suite le classicateur de la fonction TSR
va s'en occuper de classier entre les panneaux existants dans sa base de données.

3.2.4 Développement
L'ingénierie des exigences, l'architecture matérielle et la conception du système constituent
la base de la phase de développement, donc le code à développer doit respecter les exigences
auparavant spéciées en plus de respecter l'architecture du système conçu. Durant cette phase,
il m'est attribuée, avec mon équipe Alpha, le développement des deux fonctions du système
DeinAuge à savoir la détection des lignes de voie et par la suite la détection des objets.

3.2.4.1 Développement de la fonction LD

Le développement de la fonction LD est réalisé en appliquant des techniques de vision
par ordinateur (voir Annexe C) an de détecter les lignes de voie sur une route capturée à
l'aide d'une caméra montée à l'avant du véhicule. Le développement de cette fonction est divisé
en plusieurs fonctions clés décrivant les étapes pour parvenir à l'objectif nal de la fonction LD:

 Calibration de la caméra et correction de la distorsion: La sortie de la caméra

est une vidéo, qui est essentiellement une série chronologique d'images. En eet, la trans-
formation d'un objet 3D dans le monde réel en image 2D n'est pas parfaite. En raison
des propriétés physiques de l'objectif d'une caméra, l'image capturée n'est pas parfaite.
Il existe des distorsions relatives à chaque caméra, qui modient la taille et la forme ap-
parentes des objets dans l'image.

An de détecter correctement les lignes de voie dans l'image, nous devons tout d'abord
corriger cette distorsion. Ceci est fait en utilisant des bibliothèques de vision par ordina-
teur sous python, qui permettent de calculer les coecients de distorsion.

En absence de la caméra réelle que nous allons utiliser dans notre projet, nous avons
appliqué cette solution sur des images et des vidéos capturées par d'autres caméras. Une
fois nous aurons le matériel requis pour réaliser notre prototype, cette étape va se faire
au début une seule fois sur la caméra que nous aurons. Ceci va permettre d'éliminer la
distorsion radiale de toute image capturée par la suite à l'aide de cette caméra.

 Transformation de perspective: Bien que nous avons maintenant une image non
déformée, la tâche de déterminer la direction exacte de la voie est dicile en utilisant
la vue de caméra par défaut. En eet, dans la perspective par défaut de la caméra, les
objets plus éloignés paraissent plus petits et les lignes de voie plus elles sont éloignées de
la voiture plus elles semblent converger, ce qui n'est pas une véritable représentation du
monde réel.

Une façon de corriger cette distorsion de perspective est de transformer la perspective

de l'image de telle sorte que nous la regardions d'en haut, également connue sous le nom
de vue à vol d'oiseau (birds-eye view), comme schématisé sur la gure 3.8 qui suit:

48
 Figure 3.8  Schéma explicatif de la transformation de perspective en Vol d'oiseau
La méthode consiste à dénir quatre points qui délimitent notre région d'intérêt, ensuite
dénir leurs coordonnées dans l'image source et dans l'image destination. Ceci va nous
aider par la suite au niveau de l'achage pour le conducteur, à ce niveau nous aurons
besoin de faire la transformation inverse puisque le conducteur aura besoin juste de sa
vue en perspective véhicule et non pas celle de dessus.

 Filtrage des pixels de la voie: Maintenant que nous avons l'image non déformée et
de point de vue d'un oiseau, nous revenons à l'objectif principal qui est de détecter les
lignes de voie sur la route.

Pour estimer la courbure d'une route et la nature des lignes (continues ou discontinues),
nous n'avons pas besoin de toutes les informations de l'ensemble des pixels de l'image,
juste des lignes de la voie, qui sont généralement blanches ou jaunes. En utilisant le format
de couleurs Hue Saturation Lightness (HSL), nous pouvons masquer tout à part le jaune
et le blanc. Cependant, ceci ne garantit pas les résultats car nous pourrons par exemple
avoir des lignes en blanc ou en jaune mais qui ne représentent pas des lignes de la voie.

Nous avons donc utilisé le ltre Sobel qui indique la direction de la plus forte variation du
clair au sombre, ainsi que le taux de changement dans cette direction, ceci permet alors de
connaitre les points de changement soudain de luminosité, correspondant probablement
à des bords, ainsi que l'orientation de ces bords.

Cette fonction permet donc de ltrer l'image qui est non déformée et en vue d'oiseau, en
utilisant le ltre de Sobel appliqué sur la valeur de luminosité (canal L du format HSL)
de l'image.

 Calcul de la courbure de la route et la position du véhicule: Cette fonction

permet d'interpoler l'équation de chaque ligne à partir des pixels de l'image ltrée, an
de nous renvoyer les rayons de courbures de chacune.

Ainsi, en utilisant l'emplacement des deux lignes de voie détectées et l'hypothèse que
la caméra est située au centre de l'image, nous calculons ensuite la position de la voiture
par rapport à la voie. En utilisant la résolution de l'image, les mesures d'échelle pour

49
 convertir des pixels en mètres ont été calculées.

Cette étape est très utile pour la sous-fonction de l'aide au maintien de voie (LKA).

 Achage de la trajectoire: Cette fonction permet de rassembler toutes les informa-

tions précédentes sur la route, ensuite appliquer la transformation inverse de la perspective
et projeter la vue sur l'écran pour le conducteur.

 Génération de l'alerte vocale: Cette fonction est responsable de générer une alerte
vocale appropriée selon le cas an d'informer le conducteur des diérents problèmes qu'il
peut aronter.

 Statut de l'angle mort: Cette fonction va utiliser le capteur ultrason pour vérier s'il
y a un obstacle dans la zone de l'angle mort du véhicule, ce qui va être utile pour la
sous-fonction d'avertissement de changement de voie (LCW).

 Détermination du type des lignes de voie: Cette fonction va déterminer la nature

des lignes, si elles sont continues ou bien discontinues. Cette étape est également très utile
pour la sous-fonction LCW.

 Possibilité de changement de voie: À partir du statut de l'angle mort, l'information

du clignotant (que nous avons à ce stade désigné par une variable booléenne pour le
clignotant droite et gauche) et aussi le type de la ligne du côté où le clignotant est activé,
la combinaison entre ces trois informations permet de décider si le conducteur pourra
changer de voie ou non. Dans le cas échéant, une alerte vocale appropriée à chaque cas
sera généré, c'est á dire s'il ne peut pas changer de voie à cause d'un obstacle dans son
angle mort ou si par exemple la ligne est continue ou autre.

3.2.4.2 Développement de la fonction OD :

Les images capturées de l'environnement de la route sont généralement complexes contenant
plusieurs objets. La tâche de détecter plusieurs objets dans une image était un dé. Cependant,
en utilisant les modèles actuels de détection d'objets, c'est réalisable même avec une bonne pré-
cision en temps réel. La détection d'objets est l'un des sujets les plus étudiés dans le domaine
de la vision par ordinateur.

La détection d'objet commence généralement par l'extraction des caractéristiques de l'image

d'entrée à l'aide de diérentes transformations telles que Haar ou HOG, ces caractéristiques
sont transmises au classicateur pour identier l'objet. Avec l'avancement dans le domaine de
l'apprentissage profond (Deep Learning (DL)), il existe de nombreuses architectures de réseaux
de neurones convolutionnels (Convolutional Neural Network (CNN)) (voir Annexe D) qui ont
surpassé la détection d'objets utilisant un extracteur des caractéristiques des images. Ces CNN
tentent d'imiter le fonctionnement des neurones humains. Le CNN apprend les caractéristiques
des objets pendant le processus d'entrainement et peut généraliser les caractéristiques des ob-
jets an de détecter l'objet [18].

Les modèles R-CNN, Faster R-CNN, You Only Look Once (YOLO) sont tous basés sur des
CNN et fonctionnent très bien dans la détection d'objets multiples. Nous avons choisi de tra-
vailler avec la famille d'architecture YOLO car elle est considérée l'une des architectures les
plus rapides tout en conservant une grande précision.

50
 Figure 3.9  Le principe de fonctionnement de l'algorithme YOLO
Comme montré sur la gure ci-dessus, YOLO fonctionne en prenant l'image d'entrée et en
la divisant en une grille SxS. Pour chaque cellule de la grille, il prédit les boîtes englobantes
(bounding boxes), le score de conance et la probabilité de classe pour chaque objet. Pour
chaque objet détecté, YOLO classe l'objet, donne la conance et le cadre de délimitation de
cet objet.

Figure 3.10  L'architecture de la famille YOLO

L'architecture, sur la gure ci-dessus, se compose de trois parties : la couche d'entrées, les
couches cachées et la couche de sortie. La couche d'entrées (input image) dans notre cas est
une image de taille 448x448x3. Les couches cachées (DarkNet Architecture) c'est la partie qui
diérencie chaque architecture de la famille YOLO, c'est là où nous trouvons les réseaux de
neurones convolutionnels. Finalement la couche de sortie (fully connected layer) qui se compose
de deux fonctions d'activations, la première rend la localisation de l'objet en 2D en détermi-
nant les coordonnées en pixel du centre de l'objet détecté et sa taille, la deuxième partie rend
la probabilité de la classe de ce dernier.

An de choisir l'architecture de la famille YOLO avec laquelle nous allons travailler, nous avons
entrainé les deux modèles YOLOv3-tiny et YOLOv4, en poursuivant les étapes ci-dessous:

 Collection des données: c'est la phase la plus importante où il faut collecter les images
qui vont être utiles pour bien entrainer le modèle et le rendre robuste. Ces images doivent

51
 être prises de l'environnement où le modèle devrait fonctionner, c'est à dire l'objectif est
de collecter les images dans le contexte. Dans notre cas, elles doivent être issues d'un
véhicule dans diérents environnements et conditions de route.

Les gures ci-dessous présentent un exemple des images de la base de données utilisées
lors de l'entrainement:

Figure 3.11  Image pendant le jour utilisée lors de l'entrainement

Figure 3.12  Image pendant la nuit utilisée lors de l'entrainement.

 Prétraitement des données: Après la collection des images, nous passons à l'étape du
prétraitement où nous rendons ces images prêtes pour l'entrainement du modèle. Cette
phase se fait en deux parties :

52
 • Division des images en deux catégories: Après la collection des images, nous les
déposons dans un seul dossier puis nous créons deux chiers texte, un qui contient le
chemin vers les images que nous allons utiliser pour l'entrainement et l'autre chier
qui contient le chemin vers les images que nous allons utiliser pour le test. Pour notre
cas nous avons décidé de prendre 80% pour l'entrainement et 20% pour le test.

• Annoter les images: Pour chaque image, il est nécessaire de déterminer où se

trouve l'objet et indiquer ses coordonnées en 2D ainsi que sa classe, ceci est fait à
l'aide du logiciel LabelImg.

LabelImg est un outil d'annotation d'images graphiques, il est écrit en Python et

utilise Qt pour son interface graphique. En indiquant que le chier de sortie doit
être en format YOLO, nous obtenons un chier texte, à côté de l'image relative, qui
contient les coordonnées des objets détectés ainsi que les classes appropriées.

La gure ci-dessous présente un extrait du logiciel LabelImg :

Figure 3.13  Annotation des images avec le logiciel LabelImg

 Entrainement du modèle: Avant de commencer l'entrainement, il faut tout d'abord
créer des chiers de congurations, cette phase se compose de trois parties :
• Création des chiers .data et .names: Ces deux chiers sont indispensables lors
de l'entrainement d'un modèle YOLO.
- Le chier .names indique les noms des classes que le modèle doit prédire.
- Le chier .data indique les chemins du chier .names, ainsi que les chiers .txt qui
indiquent les images utilisées pour l'entrainement et le test et enn le dossier où les
poids du modèle vont être enregistré lors de l'entrainement.

• Modication du chier de conguration: Tout d'abord il faut créer un chier de

conguration .cfg similaire à celui d'une certaine architecture YOLO déjà entrainé,
puis nous modions quelques paramètres pour rendre le chier convenable à notre
cas.

53
 • Lancer l'entrainement: Avant de lancer l'entrainement, il est conseillé d'initialiser
le poids du réseau de neurones par un poids d'un YOLO déjà entrainé pour accélérer
un peu l'entrainement. En lançant l'entrainement, nous pouvons suivre l'évolution
de la fonction de perte pour déterminer si l'entrainement du modèle avance très
bien. Les poids du nouveau modèle s'enregistrent au fur et à mesure de chaque 1000
itérations.
 Test du modèle: Une fois l'entrainement est ni, nous prenons le dernier poids du réseau
de neurones et nous le testons soit en utilisant une image ou une vidéo contenant diérents
objets des classes. En testant le modèle sur de nouvelles données, nous pouvons évaluer
ses performances et valider notre réseau de neurones.
Maintenant que les étapes d'entrainement des deux modèles ont nies, il convient à faire une
comparaison:
 Comparaison entre le YOLOv4 et le YOLOv3-tiny: An de choisir le modèle le
plus performant, nous avons pris en compte plusieurs métriques:
• Intersection Over Union (IoU): c'est la zone de chevauchement entre le cadre
de l'objet annoté manuellement et le cadre prédit, divisée par l'union des deux cadres.

Figure 3.14  Diérents résultats possibles de l'IOU

• Mean Average precision (mAP): dénit la précision de la classication par classe en
xant l'IoU à 50% dans notre cas.

• Frames Per Second (FPS): cette valeur signie la rapidité du traitement de l'archi-
tecture en calculant combien de séquences d'images qui peuvent être traités pendant une
seconde.

Le tableau ci-dessous présente la diérence des métriques entre le YOLOv4 et le YOLOv3-

tiny:

Architecture IoU mAP@0.5 FPS

YOLOv4 70% 82% 21
Yolo-v3 tiny 58% 33% 64

Table 3.1  Comparaison entre les deux architectures entrainées

NB: le calcul des FPS est réalisé en lançant l'algorithme sans optimisations sur Google Colab
qui nous ore un GPU gratuit.

54
 Figure 3.15  Résultat obtenu par YOLOv3-tiny

Figure 3.16  Résultat obtenu par YOLOv4

Vu les résultats obtenus, nous avons choisi YOLOv4 puisqu'il a donné les meilleurs résultats
en terme de précision et performance de localisation avec une vitesse de traitement acceptable.

La détection d'objets c'est la base de tous les systèmes de perception automobiles, la détection
se fait image par image donc pour analyser le mouvement et la trajectoire des diérents objets
détectés et prédire leur prochain mouvement, il était nécessaire de développer aussi le concept
de suivi des objets (Object Tracking).

55
3.3 Flux ascendant du cycle en V

Une fois le développement des deux premières fonctions, LD par le groupe Alpha et TSR
par le groupe Beta, est ni, il était temps de passer à la phase de test pour naliser tout le
cycle en V de ces deux fonctions.

Le test n'est pas le processus de vérication du programme pour qu'il fonctionne correcte-
ment. Au contraire, le but du test est de trouver les problèmes (autant que possible) et de les
xer par la suite.

Il est vrai que les développeurs vérient les fonctions d'une application au fur et à mesure
de leur développement. Cependant, ils n'ont absolument pas le recul ni le temps nécessaire
pour vérier l'ensemble des fonctionnalités à chaque évolution du code. C'est donc là que réside
toute l'importance du test et toutes les compétences des testeurs.

Dans le cadre de notre projet, nous avions un souci autre que celui présenté dans l'idée
précédente. Ainsi, vu qu'un développeur ne doit pas tester son propre code car il va le voir du
même point de vue qu'il avait lors du développement. Donc la solution était que chaque équipe
va passer au test de la fonction développée par l'autre équipe.

Nous étions chargés de tester la fonction de reconnaissance des panneaux de signalisation.

Cette fonction, consiste à développer un système capable de localiser chaque panneau de signa-
lisation rencontré dans la route et le comparer avec une base de données interne. Une fois le
panneau reconnu, le système avertit le conducteur à l'aide d'un achage ou d'une alerte sonore
dans le cas de panneaux critiques.

La phase de test s'est divisée en deux grandes parties, le test unitaire qui teste le fonction-
nement de chaque unité développée dans la fonction TSR, ainsi que le test système qui vise à
tester le fonctionnement du système complet c'est à dire de la fonction TSR en entier. Chaque
partie est divisée à son tour en plusieurs étapes an de parvenir aux résultats des tests.

3.3.1 Test unitaire

An de répondre à la norme ISO 26262 dans la phase de test, il parvient à consulter la partie
6 de cette norme qui contient les recommandations pour les tests unitaires, ceci va permettre
de décider les méthodes pour dériver les cas de test ainsi le type de couverture requis pour le
niveau d'ASIL choisi pour la fonction TSR:
 Les méthodes pour dériver les cas de test: La norme ISO 26262 dénit les diérentes
méthodes pour dériver les cas de test des unités logicielles an de garantir que le logiciel
se voit attribuer le niveau ASIL requis, elles sont regroupées dans le tableau suivant, où
le symbole + signie recommandé et ++ fortement recommandé [19]:

Méthodes ASIL A ASIL B ASIL C ASIL D

1a. Analyse des exigences ++ ++ ++ ++
1b. Analyse des classes d'équivalences + ++ ++ ++
1c. Analyse des valeurs limites + ++ ++ ++
1d. Recherche d'erreurs + + + +

Table 3.2  Méthodes de dérivation des cas de test selon le niveau ASIL
Dans notre présent projet, vu que nous avons un niveau ASIL B, nous avons utilisé la
méthode "Analysis of requirements" et "Analysis of boundary values".

56
  Les types de couverture: La couverture du code est exigée par les normes de sécurité
car:
1. Avec la couverture de code, nous pouvons écrire des cas de test plus adaptés an de
tester les parties du code qui ne sont pas encore couvertes.
2. La couverture de code permet d'éviter les cas de test redondants et de gagner du
temps et de l'argent.
3. Nous savons quand nous pouvons arrêter les tests : l'objectif est atteint lorsque le
taux de couverture de test nécessaire a été atteint.
4. La couverture de code est également une preuve de qualité pour les clients.
5. Si le développement ou le test est sous-traité à une autre personne, le rapport de
couverture montre le nombre de tests eectués par cette personne.
6. Les outils de couverture de code aident aussi à trouver le code mort. Un code mort
est un code qui ne peut jamais être exécuté au moment de l'exécution, ou c'est une
section du code source d'un programme qui est exécutée mais dont le résultat n'est
jamais exploité par son programme.
An d'évaluer l'exhaustivité des cas de test, l'ISO 26262 exige la mesure de couverture du code.
Selon le point 9.4.5 de la partie 6 de la norme, si le taux de couverture obtenue est insusant,
alors des cas de test supplémentaires ou une justication doit être fournie.

Selon le niveau d'ASIL, diérents types de couverture sont exigés, ils sont regroupées dans
le tableau suivant, où le symbole + signie recommandé et ++ fortement recommandé [19]:

Méthodes ASIL A ASIL B ASIL C ASIL D

1a. Couverture des instructions ++ ++ + +
1b. Couverture des branches + ++ ++ ++
1c. MC/DC + + + ++

Table 3.3  Types de couverture de code selon le niveau ASIL

Dans notre présent projet, vu que nous avons un niveau ASIL B, nous avons utilisé la couver-
ture des instructions et des branches.

3.3.1.1 Création des spécications de test

La première étape du test unitaire était de rédiger un document de spécications des tests
pour les exigences du logiciel, ce document a pour objectif de décrire les cas de tests an de
vérier le respect d'une exigence spécique.

Avant d'entrer dans les détails, un scénario ou une spécication de test est une activité de
test du logiciel qui utilise des scénarios : des histoires hypothétiques pour aider le testeur à
résoudre un problème complexe ou un système de test. Le scénario de test idéal est une histoire
crédible, complexe, convaincante ou motivante; dont le résultat est facile à évaluer.

Nous avons choisi les attributs suivants pour le document de spécications des tests élaboré:
 Req_ID: l'identiant de l'exigence à tester.
 TS_ID: l'identiant de la spécication de test (Test Specication).
 Description: la description en texte du test spec.
 Test Seq: la séquence de test spéciant les préconditions, les actions et les postconditions
qui doivent être assurées pour exécuter ce test.

57
  Expected results: les résultats attendus de la séquence de test an de valider ou non
le test.
 Developed by: la personne ou l'équipe qui a développé la spécication de test.
 Missing information / Comments: commentaires et clarications.
 Review comments: champ dédié aux commentaires par l'équipe qui a fait la revue.
 Reviewed by: la personne ou l'équipe qui a fait la revue. Dans notre projet, chaque
équipe faisait la revue de l'autre. Cette étape est très importante an d'avoir des idées
globales de la part du développeur et du testeur dans le but de conrmer les descriptions
des tests. Ainsi ça permet d'avoir une traçabilité de qui a fait n'importe quelle modication
ou remarque.
 PO's Comments: les commentaires des encadrants.

Ainsi, nous avons déni 26 spécications de tests pour les 15 exigences de niveau logiciel,
dénis auparavant par le groupe Beta, de la fonction TSR. Le document des spécications de
tests est présenté comme suit :

Figure 3.17  Extrait 1 du document des spécications de tests niveau logiciel de la fonction TSR

58
Figure 3.18  Extrait 2 du document des spécications de tests niveau logiciel de la fonction TSR
Comme montré dans les gures ci-dessus, nous pouvons avoir une exigence avec un, deux ou
plusieurs spécications de tests, le nombre varie en fonction de chaque exigence dans le but de
la couvrir totalement. Une fois ce document a été bien élaboré et modié après les revues, la
deuxième étape consiste à passer au développement de ces tests.

3.3.1.2 Développement des cas de tests

Pour le test unitaire, nous avons utilisé le module de test unittest de python qui repose
sur les principes de fonctionnement suivants :
- On crée une classe qui dérive de unittest.TestCase et qui contient les méthodes de test,
chacune est relative à une spécication de test parmi le document des spécications.
Chaque méthode doit terminer par une assertion qui doit être exacte an de valider le
test.
- À chaque test lancé, la méthode setUp est appelée avant pour mettre en place des données
avant le test, et la méthode tearDown est exécutée à la n du chier de test, même s'il se
termine avec une erreur.
Donc, il faut implémenter les diérentes méthodes de test, la méthode setUp et la méthode
tearDown :

59
 1class TestDetectionTS ( u n i t t e s t . TestCase ) :
2 d e f setUp ( s e l f ) :
3 s e l f . img_test1 = cv2 . imread ( " t e s t _ i m g s / test_with_30_speed_limit . j p g " )
4 s e l f . img_test2 = cv2 . imread ( " t e s t _ i m g s / test_without_TS . j p g " )
5 s e l f . img_test3 = cv2 . imread ( " t e s t _ i m g s / speed_limit_80_cropped . j p g " )
6 s e l f . img_test4 = cv2 . imread ( " t e s t _ i m g s / TS_2sens_cropped . j p g " )
7 s e l f . img_test5 = cv2 . imread ( " t e s t _ i m g s / pharmacie_panel_cropped . j p g " )
8 s e l f . img_test6 = cv2 . imread ( " t e s t _ i m g s /test_two_TS . j p g " )
9 s e l f . img_test7 = cv2 . imread ( " t e s t _ i m g s / l o t _ o f _ s i g n s . j p g " )
10 s e l f . img_test8 = cv2 . imread ( " t e s t _ i m g s / test_with_mcdo_panel . j p g " )
11 s e l f . img_test9 = cv2 . imread ( " t e s t _ i m g s / test_with_danger_TS . j p g " )
12 s e l f . img_test10 = cv2 . imread ( " t e s t _ i m g s / test_with_stop_TS . j p g " )
13 s e l f . img_test12 = cv2 . imread ( " t e s t _ i m g s / c l a s s _ d a n g e r . j p g " )
14 s e l f . img_test13 = cv2 . imread ( " t e s t _ i m g s / class_mandatory . j p g " )
15 s e l f . d e s i r e e = np . a s a r r a y ( [ [ 1 2 1 0 , 2 2 5 , 1 4 3 0 , 4 5 0 ] ] )
16 s e l f . v i d e = np . a s a r r a y ( [ [ 0 , 0 , 0 , 0 ] ] )
17
18 d e f tearDown ( s e l f ) :
19 pass
20
21#TSR_02_01:###################################################################
22
23#############################TS02_01 :
24 d e f test_TS_02_01 ( s e l f ) :
25 cap = cv2 . VideoCapture ( 0 )
26 p r i n t ( cap . isOpened ( ) )
27 s e l f . a s s e r t T r u e ( cap . isOpened ( ) )
28
29##############################################################################
30
31#TSR_02_02:###################################################################
32
33#############################TS_02_02 :
34 d e f test_TS_02_02 ( s e l f ) :
35 r e s u l t , c l=f u n c s . d e t e c t _ t s ( s e l f . img_test1 , 4 1 6 )
36 #p r i n t ( r e s u l t )
37 s e l f . a s s e r t L e s s E q u a l ( np . abs ( r e s u l t [ 0 ] [ 0 ] s e l f . d e s i r e e [ 0 ] [ 0 ] ) , 3 0 )
38 s e l f . a s s e r t L e s s E q u a l ( np . abs ( r e s u l t [ 0 ] [ 1 ] s e l f . d e s i r e e [ 0 ] [ 1 ] ) , 3 0 )
39
40 s e l f . a s s e r t L e s s E q u a l ( np . abs ( r e s u l t [ 0 ] [ 2 ] s e l f . d e s i r e e [ 0 ] [ 2 ] ) , 3 0 )
41 s e l f . a s s e r t L e s s E q u a l ( np . abs ( r e s u l t [ 0 ] [ 3 ] s e l f . d e s i r e e [ 0 ] [ 3 ] ) , 3 0 )

Listing 3.1  Extrait du code de développement des tests unitaires

Ce module nous a oert plusieurs possibilités an de valider les tests, cependant nous avons
rencontré une limitation par rapport aux tests des fonctions qui retournent des images, donc
nous étions obligés de trouver une solution alternative puisque nous n'avons pas de logiciel
opensource qui se charge de cette tâche. La solution que nous avons adopté est que pour les
fonctions qui nécessitent ce type de test, l'image de sortie sera aché dans le test avec une
boîte de dialogue qui nous donne, en tant que testeur, la possibilité de valider ou non le test.

3.3.1.3 Résultats des tests unitaires

An de parvenir aux résultats des tests unitaires, nous sommes passés par les étapes sui-
vantes :
 Exécution des tests unitaires: l'exécution des tests se fait par la commande :

60
 Figure 3.19  Commande d'exécution des tests unitaires
 Création du chier de détection des bugs: au fur et à mesure que nous détectons un
bug dans l'exécution, il doit être mentionné dans un chier an de garantir la traçabilité
et renseigner le développeur sur le problème détecté:

Figure 3.20  Extrait du chier de détection des bugs des tests unitaires

 Génération du rapport de test unitaire: une fois le chier des bugs est créé et après
résolution par l'équipe beta de ces bugs détectés, le rapport de test doit être généré, en
utilisant le plugin pytest-html, par la commande :

Figure 3.21  Commande de génération du rapport de test unitaire

Le rapport de test, aussi connu sous le nom de rapport de clôture des tests, fournit aux
intervenants un compte rendu condensé et détaillé des résultats des tests. Il se présente
comme suit :

61
 Figure 3.22  Extrait 1 du rapport des tests unitaires

Figure 3.23  Extrait 2 du rapport des tests unitaires

 Génération des résultats de la couverture de code: la dernière étape est de générer

le taux de couverture du code. En utilisant le module coverage de python, et en utilisant
les deux types de couverture de code exigés par la norme ISO 26262, des instructions et
des branches, nous avons généreré le chier qui contient les détails de la couverture de
code par les deux commandes suivantes :

62
 Figure 3.24  Commande 1 de génération du chier de couverture du code

Figure 3.25  Commande 2 de génération du chier de couverture du code

Où le premier nom de chier représente celui contenant les fonctions de tests (test_TSR.py), et
le deuxième représente le chier contenant les fonctions que l'on teste (Trac_Sign_Image_Det
ection_2.py). Le chier de couverture de code se présente comme suit :

Figure 3.26  Fichier de couverture du code de la fonction TSR

La partie des tests unitaires est nalisée, grâce aux diérents cas de test couvrant toutes les
exigences, nous avons pu couvrir 97% pour LD testée par le groupe Beta, et 98% pour TSR.
Nous avons également un taux de 100% pour la couverture des exigences niveau logiciel pour
les deux fonctions, c'est à dire que la totalité des exigences logicielles est couverte par les tests.
L'étape qui suit est le test système de la fonction TSR.

3.3.2 Test système

Vu que notre projet est un prototype d'un systéme ADAS donc les tests des fonctions
constituant ce système nécessitent l'identication et l'analyse d'un grand nombre de scénarios
de tracs routiers.
L'ensemble de ces scénarios possibles est couvert par de nombreuses dimensions à savoir : la
géométrie et la nature de la route, le comportement du conducteur et des autres participants à
la circulation, les conditions météorologiques, les caractéristiques des véhicules, les défaillances
spontanées des composants, l'environnement extérieur au véhicule mais qui entre en contact
avec le conducteur, etc.

Cette multi-dimensionnalité peut dicilement être couverte de manière complète par de vé-
ritables tests de conduite. Donc nous étions obligés de compléter par des essais virtuels en
utilisant un outil de simulation de véhicules et de tracs étant donné que la simulation semble
être la seule option pour synthétiser et analyser l'énorme quantité de scénarios de tracs routiers
requis avec l'ensemble des conditions pour chaque cas à part.

63
3.3.2.1 Création des spécications de test
De la même manière que le test unitaire, la première étape du test système était de rédiger
un document de spécications des tests pour les exigences du système (dont le type de test
requis est système).

En utilisant les mêmes attributs présentés lors de la création des spécications des tests uni-
taires, nous avons déni 22 spécications de tests pour les 12 exigences de niveau système,
dénis auparavant par le groupe Beta, de la fonction TSR. La gure suivante représente un
exemple du document des spécications de test système de la fonction TSR :

Figure 3.27  Extrait du document des spécications de tests niveau système de la fonction TSR
Une fois ce document est bien élaboré et modié après les revues, la deuxième étape consiste
à créer les scénarios des vidéos de test que nous allons utiliser pour valider les exigences de niveau
système.

3.3.2.2 Création des scénarios des vidéos de test

Cette étape consiste à traduire chaque spécication de test en une description de l'environ-
nement et des conditions qui doivent être dans la vidéo de test an de voir le comportement du
système face à cette situation, et donc de valider ou non cette spécication de test. Le document
est élaboré en utilisant les diérents attributs sur l'image ci-dessous, nous trouvons entre autres
le champ Detailed Scenario qui est le plus important et qui permet de décrire en détails toutes
les caractéristiques de l'environnement dans chaque vidéo relative à une spécication de test
précise.

64
 Figure 3.28  Extrait du document des scénarios des vidéos de test de la fonction TSR
3.3.2.3 Génération des vidéos de test
Une fois un scénario de vidéo est décrit par un membre du groupe, un autre se charge de
faire sa revue (en se référant à l'exigence et à la spécication de test) et le créer par les outils
de création des vidéos, avant que le troisième membre passe à l'exécution du test système relatif.

Nous avons utilisé le moteur de jeu Unity pour réaliser la majorité de nos scénarios de tests
et générer les vidéos. Pourtant, cet outil a montré quelques limitations pour quelques scénarios
nécessitant le changement des conditions météorologiques, nous avons donc créé ces vidéos sur
CARLA simulator.

En utilisant les logiciels CARLA et Unity décrits dans le troisième chapitre, nous avons pu
créer les diérentes vidéos nécessaires pour passer à l'exécution des tests, ci-dessous des cap-
tures depuis les vidéos montrant l'environnement sous ces deux outils:

65
 Figure 3.29  Exemple de l'environnement d'une vidéo sous Unity

Figure 3.30  Exemple de l'environnement d'une vidéo sous CARLA

3.3.2.4 Résultats du test système
An de parvenir aux résultats du test système, nous sommes passés par les étapes suivantes :
 Exécution des tests: l'exécution de ces tests système, dans le cas de la fonction TSR,
nécessite un GPU puissant, ce qui n'est pas le cas pour nos ordinateurs. Donc nous avons
utilisé la solution du Google Colab, c'est une alternative an de compléter le processus
de test en absence du hardware puissant qui va permettre d'implémenter réellement tout
le système.
Colaboratory, souvent raccourci en Colab, permet d'écrire et d'exécuter du code Python
dans le navigateur, en utilisant la technologie du notebook avec un accès gratuit aux
GPU.
 Création du chier de détection des bugs: de la même manière que dans les tests
unitaires, au fur et à mesure que nous détectons un bug dans l'exécution, il doit être
mentionné dans un chier an de garantir la traçabilité et renseigner le développeur sur
le problème détecté.

66
  Création du rapport de test système: après tous le processus de test; création des
spécications de tests, description et génération des scénarios des vidéos, exécution des
tests avec les vidéos créées, détection des bugs, revue et xation des bugs dans la mesure
du possible, la dernière étape consiste à créer un rapport qui résume les résultats de cette
phase avant et après la revue:

Figure 3.31  Rapport de test système de la fonction TSR

Le pourcentage de la couverture du test système est calculé par le ratio du nombre des tests
qui ont été exécutés et réussis sur le nombre total des tests exécutés. Nous avons également sur
la gure ci-dessus, le nombre des tests qui n'ont pas encore été exécutés vu la non disponibilité
du matériel (GPU), même si Google Colab possède un GPU gratuit, mais le problème est que
nous ne pouvons pas acher dans cet environnement, ainsi nous ne pouvons pas tester les exi-
gences nécessitant les alertes.

Grâce aux diérents cas et vidéos de test couvrant toutes les exigences, et après la xation
des bugs détectés, nous avons pu atteindre 83% pour les deux fonctions TSR ainsi que LD
testée par le groupe Beta. Nous avons également un taux de 100% de couverture des exigences
niveau système pour les deux fonctions, c'est à dire que la totalité des exigences système est
couverte par les tests.

Ci-dessous les captures relatives aux gures 3.29 et 3.30 depuis les vidéos après le test (voir
Annexe E pour les captures d'une vidéo de LD):

67
 Figure 3.32  Résultat du test d'une vidéo sous Unity

Figure 3.33  Résultat du test d'une vidéo sous CARLA

3.4 Conclusion

Ce dernier chapitre détaille l'ensemble du travail eectué pour assurer les diérentes phases
du cycle en V pour les trois fonctions importantes du projet DeinAuge. La dernière livraison
concernant le test de la fonction OD-OT vient de se lancer, au temps de dépôt du présent rap-
port, par conséquent cette tâche n'est pas encore complète. Ainsi, la phase de l'implémentation
n'a pas pu avoir lieu en raison des dicultés d'avoir le matériel requis vu les conditions actuelles
de la pandémie du Coronavirus.

68
 CONCLUSION ET PERSPECTIVES

Le présent travail a été réalisé au sein du département Systèmes d'information et systèmes

embarqués à Alten Delivery Center Maroc. Lors de ce stage, j'ai fait partie d'une équipe, de cinq
stagiaires, qui s'est chargée de concevoir, développer et tester un système embarqué automobile
intitulé DeinAuge. Le système DeinAuge est un produit embarqué destiné à être utilisé dans
un véhicule pour orir au conducteur une multitude de services.

La réalisation de ce projet a commencé d'abord par la compréhension de la complexité d'un

projet dans les systèmes embarqués et plus précisément dans le domaine automobile, l'étude
comparative du matériel an de choisir le plus convenable aux besoins du système. Par la suite,
la rédaction des documents nécessaires à l'élaboration des exigences, au développement et test
des fonctions du système an de répondre aux attentes des clients.

En réalisant ce projet automobile d'actualité, j'ai pu acquérir un savoir-faire dans ce domaine

qui est en plein expansion au Maroc. Ces connaissances de base dans le domaine d'automobile,
de ses diérentes normes et son environnement matériel et logiciel, seraient certainement utiles
pour mon avenir professionnel.

En ce qui concerne les perspectives envisagées pour la continuité du projet, d'abord l'inté-
gration de toutes les fonctionnalités développées et leur implémentation sur le matériel une fois
disponible, et démarrer une phase de test et maintenance du système dans le monde réel an
de l'évoluer et l'adapter au mieux aux exigences et besoins du projet.

Le centre ADC et surtout le département SISE qui m'a accueilli pendant ce stage connait
actuellement une forte croissance, et je suis très ère d'avoir pu contribuer et participer à cette
évolution qui a pour objectif de rendre le département SISE Maroc un pilier incontournable du
groupe ALTEN.

Ce stage a été très enrichissant car il m'a permis de découvrir de plus près le secteur de
l'embarqué automobile, ses acteurs, contraintes. Ce stage m'a permis, non seulement d'appro-
fondir mes connaissances techniques dans le domaine de l'ingénierie des systèmes électroniques
embarqués mais également de développer le côté relationnel en travaillant au sein d'une équipe
jeune et dynamique, de proter des réunions hebdomadaires avec les clients et avoir la chance de
proposer des solutions pertinentes à leurs besoins. Ceci m'a permis d'avoir une vision globale de
l'environnement professionnel au sein d'une entreprise multinationale, ainsi que les obligations
et les contraintes auxquelles est confronté un ingénieur au cours de son travail quotidien.

Cette expérience m'a permis de cultiver mon esprit de synthèse en respectant la méthode
de travail adoptée tout au long du stage. Pour conclure, je peux dire que je garde de mon stage

69
de n d'études un excellent souvenir. Il constitue désormais une expérience professionnelle va-
lorisante et encourageante pour mon avenir. Cette expérience m'a oert une bonne préparation
à mon insertion professionnelle, elle constituait une opportunité de découvrir de nouvelles ap-
proches de développement dédiées au domaine de l'automobile.

Enn, je tiens à exprimer ma satisfaction d'avoir pu travailler dans un environnement

agréable, sous un encadrement à la hauteur, avec une équipe projet responsable, sérieuse et
motivante.

70
 RÉFÉRENCES

[1] https://www.leseco.ma/rapport-international-sur-la-securite-routiere-progres-enregistres-
par-le-maroc/
[2] https://www.oxts.com/what-is-adas/
[3] Zhao Guangzhe, Estimation of Pedestrian Walking Direction for Driver Assistance System
[4] https://www.capcar.fr/lexique-auto/regulateur-de-vitesse-adaptatif-acc
[5] https://www.capcar.fr/lexique-auto/freinage-automatique-urgence/
[6] https://fr.w3ki.com/software_engineering/software_development_life_cycle.html
[7] https://fr.wikipedia.org/wiki/Cycle_en_V
[8] https://www.planzone.fr/blog/quest-ce-que-la-methodologie-agile
[9] https://www.git-scm.com/book/fr/v2/D%C3%A9marrage-rapide-%C3%80-propos-de-la-
gestion-de-version
[10] https://fr.wikipedia.org/wiki/Apache_Subversion
[11] https://fr.wikipedia.org/wiki/Bitbucket
[12] https://fr.wikipedia.org/wiki/Microsoft_OneDrive
[13] https://www.nvidia.com/fr-fr/autonomous-machines/embedded-systems/jetson-tx2/
[14] https://documents.irevues.inist.fr/bitstream/handle/2042/61700/lm20_com_1B_1_053
_Barbat.pdf
[15] https://en.wikipedia.org/wiki/Software_requirements
[16] https://www.geeksforgeeks.org/software-engineering-requirements-engineering-process/
[17] https://fr.wikipedia.org/wiki/UML_(informatique)
[18] Object Detection, Classication, and Tracking for Autonomous Vehicle. Milan Arya.
[19] https://www.embitel.com/blog/embedded-blog/how-iso-26262-compliant-unit-testing

71
 ANNEXE A
DIFFÉRENCE ENTRE LIDAR 1D, 2D ET 3D

 Dans leur version la plus simple, les capteurs LiDAR se retrouvent dans des appareils de
mesure de la distance et dans des capteurs où ils font oce de systèmes de mesure de
la distance sous forme de points. Pour une mesure directe de la distance, ils sont dirigés
sur une cible naturelle ou sur un réecteur. Les capteurs qui travaillent ainsi dans une
dimension (distance) sont dits monodimensionnels, soit des capteurs 1D.

 En déplaçant le faisceau de mesure ou en le faisant tourner dans un plan, on obtient

des renseignements sur la distance et l'angle, et donc en deux dimensions. Pour une telle
mesure, les capteurs utilisés sont habituellement des capteurs 2D-LiDAR. Ils déterminent
les valeurs de mesure de manière séquentielle avec un intervalle de temps normalement
régulier entre les mesures.

 Pour la troisième dimension, des capteurs LiDAR employés sont pivotés. Cela permet
d'obtenir des informations aussi bien sur l'écart et la position sur l'axe x que sur les po-
sitions sur les axes y et z. Les mêmes informations sur les diérents paramètres spatiaux
sont acquises en déplaçant plusieurs systèmes émetteurs et récepteurs dans divers angles
horizontaux dans un capteur et ce avec balayage. Il est alors question de scanners multi-
couche.

72
 ANNEXE B
LES CARACTÉRISTIQUES D'UNE BONNE

EXIGENCE

Une bonne exigence devrait vérier les caractéristiques suivantes:

 Non ambigüe : il devrait y avoir une seule façon d'interpréter l'exigence.
 Testable : les testeurs devraient être en mesure de vérier si l'exigence est correctement
mise en oeuvre. Le test devrait réussir ou échouer.
 Claire : les exigences ne doivent pas contenir d'informations inutiles. Elles devraient être
énoncées clairement et simplement.
 Correcte : si une exigence contient des faits, ces faits devraient être vrais.
 Compréhensible : les exigences doivent être grammaticalement correctes et écrites dans
un style cohérent.
 Faisable (réaliste, possible) : l'exigence devrait être réalisable dans les limites des
contraintes tels que le temps, l'argent et les ressources disponibles.
 Indépendante : pour comprendre l'exigence, il ne devrait pas être nécessaire de connaître
d'autres exigences.
 Atomique : l'exigence doit contenir un seul élément traçable; elle doit être indivisible.
 Nécessaire : une exigence est inutile si sa suppression n'aecte pas le système.
 Abstraite (Implementation-free) : les exigences ne doivent pas contenir d'informa-
tions de conception et de mise en oeuvre inutiles.
 Cohérente : il ne devrait pas y avoir de conit entre les exigences. Les conits peuvent
être directs ou indirects:
- Les conits directs se produisent lorsque, dans la même situation, un comportement
diérent est attendu.
- Les conits indirects surviennent lorsque les exigences ne décrivent pas la même
fonctionnalité, mais il n'est pas possible de répondre aux deux exigences en même
temps.
 Non-redondante : chaque exigence devrait être exprimée une seule fois et ne devrait
pas chevaucher une autre exigence.
 Achevée : une exigence doit être spéciée pour toutes conditions pouvant survenir.

73
 ANNEXE C
LA VISION PAR ORDINATEUR

Le terme de "Computer Vision" ou "Vision par ordinateur" en français désigne les dié-
rentes techniques permettant aux ordinateurs de voir et de comprendre le contenu d'images.
Il s'agit d'une sous-catégorie d'intelligence articielle et de Machine Learning (apprentissage
automatique).

La Computer Vision (CV) est une sous-catégorie de l'informatique et de l'intelligence arti-

cielle. C'est un ensemble de méthodes et de technologies qui permettent d'automatiser une
tâche spécique à partir d'une image. En fait, une machine est capable de détecter, d'analyser
et d'interpréter un ou plusieurs éléments d'une image an de prendre une décision et d'eectuer
une action.

Il existe diérentes catégories de CV telles que le traitement d'images (y compris la recon-

naissance d'images), la reconnaissance faciale, la reconnaissance optique de caractères ou la
reconnaissance d'iris. Cette diversité signie que la CV peut être utile pour de nombreux types
diérents d'industries et de nombreux cas d'usage pratiques.

Nous pouvons citer entre autres, le domaine de la sécurité automobile, la vision par ordinateur
est utilisée pour la détection de dangers, la CV occupe une place centrale dans l'industrie au-
tomobile puisque c'est grâce à elle que les véhicules arrivent à voir sur la route.

Dans la majorité des cas, la CV se base sur le DL, un domaine du Machine Learning.

Le Deep Learning est un ensemble de techniques d'apprentissage automatique. Il s'appuie sur

un réseau de neurones articiels (aussi appelés réseaux neuronaux convolutionnels), semblables
à ceux du cerveau humain. C'est à dire qu'un réseau neuronal est constitué de plusieurs couches
successives de neurones.

74
 ANNEXE D
RÉSEAUX DE NEURONES

CONVOLUTIONNELS

Le réseau de neurones à convolution (CNN) est le plus répandu dans la communauté d'ap-
prentissage profond, il est un type de réseaux de neurones articiels (Articial Neural Network
(ANN)), qui est conçu pour être entrainé avec un ensemble d'images connue. Une image est
représentée par une matrice tridimensionnelle, avec hauteur, largeur et profondeur. La profon-
deur représente les trois canaux de couleur Rouge, Vert et Bleu. Si les réseaux de neurones
articiels réguliers (ANN) sont utilisés pour être entrainés avec un ensemble d'images, la taille
de la couche d'entrée serait un grand ensemble d'entrées individuelles représentant chaque ca-
nal de couleur individuel de chaque pixel. Par exemple, une image avec une résolution 50x50x3
aurait 7500 entrées, ce qui rend le réseau neuronal très grand. CNN est conçu pour proter de
la profondeur et modéliser l'image sous forme de volume et s'entraîner avec. Une représentation
de la diérence entre un réseau neuronal articiel régulier et le CNN est présentée dans la gure
ci-dessous:

Figure D.1  ANN à gauche, CNN à droite

Chaque couche de CNN transforme le volume d'entrée en un volume de sortie. Les CNN
ont des poids et des biais, puis des sorties par une fonction d'activation non linéaire. Alors que
les CNN sont entrainés avec des images d'entrée, ces paramètres changent au cours du temps,

75
résultant l'apprentissage des entrées. Les nouveaux paramètres peuvent ensuite être utilisés
pour détecter les caractéristiques et les points clés dans l'image. Plus la couche est profonde,
plus les caractéristiques peuvent être abstraites. Les premières couches d'un CNN pourraient
en apprendre davantage sur les bords et les lignes dans les images tandis qu'une couche plus
profonde dans le CNN pourrait en apprendre davantage sur les visages ou certaines formes
complexes. Les CNN sont utilisés pour détecter des objets dans les images.

Dans ce projet, la détection et la classication d'objets se font à l'aide d'une famille d'ar-
chitecture appelé YOLO, qui utilise une architecture CNN.

76
 ANNEXE E
RÉSULTATS DES TESTS DE LA FONCTION

LD

Ci-dessous les captures du test système depuis une vidéo de test de la fonction LD, la pre-
mière représente l'achage de la trajectoire lorsque le conducteur est en bonne position dans
sa route:

Figure E.1  Résultat du test de la fonction LD - Position correcte

La gure suivante représente l'achage de la trajectoire lorsque le conducteur dévie de

sa position, nous remarquons que le véhicule à peine il touche la ligne gauche, nous avons la
trajectoire qui change en rouge avec un message d'alerte lui indiquant qu'il doit tourner pour
corriger sa position:

77
Figure E.2  Résultat du test de la fonction LD - Position déviée

78