G.seii2020 Elattarsofi Zineb [PDF]

Zitiervorschau

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. BELKEBIR Taouk Pr. BELCAID Anass

Président du jury

Année Universitaire 2019 - 2020

ENSAF

REMERCIEMENTS

Ce travail est l'aboutissement de cinq années de formation en ingénierie des systèmes embarqué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édagogique, 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 consacré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 pourquoi 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 aboutissement 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. LAMRABET 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'industrie 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 automatique 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 conducteur, 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 diffé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 recognition 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 mounted 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 RÉSUMÉ ABSTRACT RÉSUMÉ(Arabe) TABLE DES MATIÈRES LISTE DES TABLEAUX TABLE DES FIGURES LISTE DES ACRONYMES INTRODUCTION GÉNÉRALE

2 3 4 5 6 8 9 12 13

1 CADRE GÉNÉRAL DU PROJET 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Organisme d'accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Présentation générale du groupe ALTEN . . . . . . . . . . . . . 1.2.2 Présentation d'Alten Delivery Center Maroc . . . . . . . . . . . 1.3 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Problématique et objectif . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Description du système DeinAuge . . . . . . . . . . . . . . . . . . 1.3.3 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.4 Planication du projet . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 MÉTHODOLOGIE DE TRAVAIL ET ENVIRONNEMENT TECHNIQUE DU PROJET 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Le cycle de développement en V . . . . . . . . . . . . . . . . . . . 2.2.2 La méthode Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Gestion de versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Environnement technique du projet . . . . . . . . . . . . . . . . . . . . . 2.3.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . .

14 14 15 15 15 16 16 17 18 19 21

2.3.1.1 2.3.1.2 2.3.1.3

Carte électronique . . . . . . . . . . . . . . . . . . . . . . . . Caméra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lidar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

22 22 23 23 25 27 29 29

29 30 31

2.3.1.4

Capteur ultrason

. . . . . . . . . . . . . 2.3.2 Environnement logiciel . . . . . . . . . . . . . 2.3.2.1 Langage de programmation . . . . . . . . 2.3.2.2 Environnement logiciel des tests unitaires 2.3.2.3 Environnement logiciel des tests système 2.3.3 Choix du niveau de criticité du projet . . . . 2.3.3.1 Norme ISO 26262 . . . . . . . . . . . . . 2.3.3.2 Les niveaux d'intégrité ASIL . . . . . . . 2.3.3.3 Niveau ASIL du projet . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.1 Élicitation des exigences . . . . . . . . . . 3.2.1.2 Spécication des exigences . . . . . . . . . 3.2.1.3 Vérication et validation des exigences . . 3.2.1.4 Gestion des exigences . . . . . . . . . . . . 3.2.2 Architecture matérielle du système . . . . . . . 3.2.3 Conception du système . . . . . . . . . . . . . . 3.2.3.1 Diagramme de cas d'utilisation du système 3.2.3.2 Diagramme d'activité . . . . . . . . . . . . 3.2.4 Développement . . . . . . . . . . . . . . . . . . . 3.2.4.1 Développement de la fonction LD . . . . . 3.2.4.2 Développement de la fonction OD : . . . . Flux ascendant du cycle en V . . . . . . . . . . . . . . 3.3.1 Test unitaire . . . . . . . . . . . . . . . . . . . . . 3.3.1.1 Création des spécications de test . . . . . 3.3.1.2 Développement des cas de tests . . . . . . . 3.3.1.3 Résultats des tests unitaires . . . . . . . . 3.3.2 Test système . . . . . . . . . . . . . . . . . . . . . 3.3.2.1 Création des spécications de test . . . . . 3.3.2.2 Création des scénarios des vidéos de test . 3.3.2.3 Génération des vidéos de test . . . . . . . . 3.3.2.4 Résultats du test système . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

2.4 3 RÉALISATION DU SYSTÈME DeinAuge 3.1 Introduction . . . . . . . . . . . . . . . . 3.2 Flux descendant du cycle en V . . . . 3.2.1 Ingénierie des exigences . . . .

3.3

3.4 CONCLUSION ET PERSPECTIVES RÉFÉRENCES A B C D E

DIFFÉRENCE ENTRE LIDAR 1D, 2D ET 3D LES CARACTÉRISTIQUES D'UNE BONNE EXIGENCE LA VISION PAR ORDINATEUR RÉSEAUX DE NEURONES CONVOLUTIONNELS RÉSULTATS DES TESTS DE LA FONCTION LD

7

32

33

33 33 34

35

35 36 37

38 39 39 40 40

40 40 43 43

43 45

45 46

48

48 50

56 56

57 59 60

63

64 64 65 66

68 69 71

72 73 74 75 77

LISTE DES TABLEAUX

1.1

Fiche technique d'ALTEN MAROC . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10

Comparaison des cartes électroniques . . . . . . . . . Comparaison des caméras . . . . . . . . . . . . . . . Comparaison des lidars . . . . . . . . . . . . . . . . . Caractéristiques des capteurs ultrasons proposés . . . Comparaison des ultrasons . . . . . . . . . . . . . . . Récapitulatif du benchmarking matériel . . . . . . . . Comparaison des langages de programmation . . . . . Allocation des niveaux ASIL . . . . . . . . . . . . . . Détermination du niveau ASIL du système DeinAuge Détermination du niveau ASIL de la fonction LD . .

. . . . . . . . . .

30 31 32 32 32 33 33 37 38 38

3.1 3.2 3.3

Comparaison entre les deux architectures entrainées . . . . . . . . . . . . . . . . Méthodes de dérivation des cas de test selon le niveau ASIL . . . . . . . . . . . Types de couverture de code selon le niveau ASIL . . . . . . . . . . . . . . . . .

54 56 57

8

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

TABLE DES FIGURES

1.1 1.2 1.3 1.4 1.5

Secteurs d'activités d'ALTEN . . . . . . . . . . . . . . . Les principaux clients potentiels d'ALTEN MAROC . . . Diagramme de GANTT préliminaire du projet DeinAuge Planication des tâches du projet DeinAuge . . . . . . . Diagramme de GANTT nal du projet DeinAuge . . . .

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13

Le cycle de développement en V . . . . . . . . . . . . . Le déroulement du projet - exemple des deux premières Répartition et organisation des équipes . . . . . . . . . Planning des réunions durant le sprint . . . . . . . . . Exemple de dépôt sur Bitbucket . . . . . . . . . . . . . Dossier partagé pour les livrables du projet . . . . . . . Les cartes électroniques proposées . . . . . . . . . . . . Les caméras proposées . . . . . . . . . . . . . . . . . . Les lidars proposés . . . . . . . . . . . . . . . . . . . . Les capteurs ultrasons proposés . . . . . . . . . . . . . CARLA Simulator - Simulateur de conduite . . . . . . Unity - Moteur de jeu . . . . . . . . . . . . . . . . . . Les parties de la norme 26262 . . . . . . . . . . . . . .

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

15 16 19 20 20

. . . . . . fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

23 25 26 27 28 29 30 31 31 32 34 35 36

Extrait des exigences système de la fonction LD . . . . . . . . . . . . . . . . . Extrait des exigences logicielles de la fonction LD . . . . . . . . . . . . . . . . Extrait du document des exigences de la fonction OD . . . . . . . . . . . . . . Architecture matérielle du système DeinAuge . . . . . . . . . . . . . . . . . . Diagramme de cas d'utilisation du système DeinAuge . . . . . . . . . . . . . . Diagramme d'activité de la fonction LD . . . . . . . . . . . . . . . . . . . . . . Diagramme d'activité de la fonction OD-OT . . . . . . . . . . . . . . . . . . . Schéma explicatif de la transformation de perspective en Vol d'oiseau . . . . . Le principe de fonctionnement de l'algorithme YOLO . . . . . . . . . . . . . L'architecture de la famille YOLO . . . . . . . . . . . . . . . . . . . . . . . . . Image pendant le jour utilisée lors de l'entrainement . . . . . . . . . . . . . . . Image pendant la nuit utilisée lors de l'entrainement. . . . . . . . . . . . . . . Annotation des images avec le logiciel LabelImg . . . . . . . . . . . . . . . . . Diérents résultats possibles de l'IOU . . . . . . . . . . . . . . . . . . . . . . . Résultat obtenu par YOLOv3-tiny . . . . . . . . . . . . . . . . . . . . . . . . . Résultat obtenu par YOLOv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . Extrait 1 du document des spécications de tests niveau logiciel de la fonction TSR . Extrait 2 du document des spécications de tests niveau logiciel de la fonction TSR .

. . . . . . . . . . . . . . . . . .

42 42 43 44 45 46 47 49 51 51 52 52 53 54 55 55 58 59

9

. . . . .

. . . . .

. . . . .

. . . . .

3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29 3.30 3.31 3.32 3.33

Commande d'exécution des tests unitaires . . . . . . . . . . . . . . . . Extrait du chier de détection des bugs des tests unitaires . . . . . . . Commande de génération du rapport de test unitaire . . . . . . . . . . Extrait 1 du rapport des tests unitaires . . . . . . . . . . . . . . . . . . Extrait 2 du rapport des tests unitaires . . . . . . . . . . . . . . . . . . Commande 1 de génération du chier de couverture du code . . . . . . Commande 2 de génération du chier de couverture du code . . . . . . Fichier de couverture du code de la fonction TSR . . . . . . . . . . . . Extrait du document des spécications de tests niveau système de la fonction Extrait du document des scénarios des vidéos de test de la fonction TSR . . Exemple de l'environnement d'une vidéo sous Unity . . . . . . . . . . . Exemple de l'environnement d'une vidéo sous CARLA . . . . . . . . . Rapport de test système de la fonction TSR . . . . . . . . . . . . . . . Résultat du test d'une vidéo sous Unity . . . . . . . . . . . . . . . . . . Résultat du test d'une vidéo sous CARLA . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

61 61 61 62 62 63 63 63 64 65 66 66 67 68 68

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

75

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

77 78

10

. . . . . . . . . . . . . . . . . . . . . . . . TSR . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

LISTE DES ACRONYMES

ADAS ADC AEB ANN ASIL

Adaptive Cruise Control (P 18). Advanced Driver Assistance Systems (P 3). Alten Delivery Center (P 2). Automatic Emergency Braking (P 18). Articial Neural Network (P 75). Automotive Safety Integrity Level (P 36).

CNN CV

Convolutional Neural Network (P 50). Computer Vision (P 74).

DL

Deep Learning (P 50).

E/E ECU

Électriques/Électroniques (P 35). Electronic Control Unit - Unité de Commande Électronique (P 13).

FPS

Frames Per Second (P 54).

GPU

Graphics Processing Unit (P 30).

HDMI HIL HSL

High Denition Multimedia Interface (P 44). Hardware In Loop (P 34). Hue Saturation Lightness (P 49).

IA IEEE IOU ISO

Intelligence Articielle (P 30). Institute of Electrical and Electronics Engineers (P 40). Intersection Over Union (P 54). International Organization for Standardization (P 35).

LCW

Lane Changing Warning (P 17).

ACC

11

LD LiDAR LKA LLD

Lane Detection (P 17).

mAP

Mean Average Precision (P 54).

OD OD-OT OpenCV

Object Detection (P 18).

PIB PO

Produit Intérieur Brut (P 13). Product Owner (P 26).

QM

Quality Management (P 36).

RADAR

RAdio Detection And Ranging (P 18).

SDLC SIL SISE

Software Development Life Cycle (P 23).

Light Detection And Ranging (P 31). Lane Keeping Assist (P 17). Low Level Design (P 24).

Object Detection - Object Tracking (P 18). Open Source Computer Vision Library (P 33).

Software In Loop (P 34). Systèmes d'Information et Systèmes Embarqués (P 2).

TOF TS TSR

Test Specication (P 57).

UML

Unied Modeling Language (P 45).

YOLO

You Only Look Once (P 50).

Time Of Flight (P 32). Trac Sign Recognition (P 17).

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. Aujourd'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 communication, 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 somnolence 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 proté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

1.2.1

Organisme d'accueil

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éveloppement international des clients, soit en support local de leurs équipes Recherche et Développement (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 Siège social Directeur Date de création Secteur d'activité Chire d'aaire Eectif Site Web

Société Anonyme de Droit Français Fès Shore Park, Fès Amine ZAROUK 2014 Société de services technologiques 86 025 400 MAD (2014) +800 collaborateurs dont 80% ingénieurs 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

1.3.1

Contexte du projet

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 marquage 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 considé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'accorder 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'informer 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 routiè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 automatiquement 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 travailler 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éveloppeur 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évisionnelle 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'organisme 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 diffé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 exploité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 processus 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ésentant 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 recueillies 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 comprennent 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 conception 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'accomplissement 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 satisfaction 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 systè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 owners/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 devient 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 disponible 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éveloppement 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 produit. 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

Jetson Nano Jetson TX2 4gb Jetson TX2 Jetson Xavier Rpi 4 + edge TPU Google Coral S22v234

Flexibilité

Coût

Documentation

d'énergie

Disponibilité

×4

×2

×-3

×1

×-1

×2

* *** **** ***** * *** ****

*** *** *** *** * * *

* ** *** ***** * * ****

*** *** *** *** ** ** *

* ** *** ** * * **

*** *** *** *** ** ** **

Total

15 19 19 18 8 16 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 systè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 Aptina Ml5100 Webcam OmniVision OV2710 DVR HD Vision OV5647

Interface ×1

×1

Qualité ×2

FPS ×1

Coût ×-1

Total

** * * **

** ** ** **

** * *** **

*** *** ** **

** ** * **

9 6 10 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'analyse 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 utilise 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

*** **

Lidar Lite v3 TFMini Lidar

×-3

Disponibilité

*** *

×1

Total

*** ***

6 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

Glove - Ultrasonic Distance Sensor

* *

* *

HC-SR04

Disponibilité

Table 2.5  Comparaison des ultrasons 32

*** ***

Total

5 5

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

Camera DVR HD Vision Ultrasonic HC-SR04 TFMini Lidar Jetson TX2 Ecran LCD HDMI USB Carte mémoire 32G Autre(connecteur,batterie,...)

Nombre

Nombre d'exemplaire

Prix utile

utile

souhaité

en DH

1 2 1 1 1 1 RAS

2 5 3 1 1 3 RAS

Total

228,98 76,21 348,29 4432,00 580,00 100,00 500,00 6265,48

TOTAL

547,96 190,52 1044,87 4432,00 580,00 300,00 1000,00 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

Python C/C++ Java

Popularité

*** ** *

Simplicité

*** ** **

Rapidité de

Disponibilité de

Gestion de

développement

bibs d'IA

mémoire

*** * *

*** ** *

* *** **

Performance

** *** **

Maitrise

*** * **

Total

18 14 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'automatisation 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 allons 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 documentations 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 devraient 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 électroniques (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 reconnus 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 fonctionnement. 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'inté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 dangereuse ou risquée qui peut causer des dommages aux personnes et aux biens. Cinq niveaux 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'impact 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 blessures 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 terminologie 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 fonctionnelles 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 exigences 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 systè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:

-

Business 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. 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



Testability: cet attribut indique l'état d'acceptation des exigences en ce qui concerne la



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. 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: revue.

cet attribut est dédié au commentaires des personnes qui font la

Je faisais partie de l'équipe Alpha qui s'est chargée de la rédaction du document des exigences 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 correctement 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 propageraient 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 priorisation 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 modier 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 plusieurs 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 environnement 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:



Le lidar: permet de calculer la distance longitudinale entre le véhicule ego et le véhicule

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. 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éveloppement, 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 fonctionnalité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 parallè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étection 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 donné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 fonction 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 transformation 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 apparentes 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 ordinateur 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:



Génération de l'alerte vocale:



Statut de l'angle mort: Cette fonction va utiliser le capteur ultrason pour vérier s'il

Cette fonction permet de rassembler toutes les informations précédentes sur la route, ensuite appliquer la transformation inverse de la perspective et projeter la vue sur l'écran pour le conducteur. 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.

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:



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

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.

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 objets 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 travailler 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éterminant 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'architecture 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 YOLOv3tiny:

Architecture

IoU

YOLOv4 Yolo-v3 tiny

70% 58%

[email protected] 82% 33%

FPS 21 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 correctement. 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 signalisation 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 fonctionnement 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 1a. Analyse des exigences 1b. Analyse des classes d'équivalences 1c. Analyse des valeurs limites 1d. Recherche d'erreurs

ASIL A ++ + + +

ASIL B ++ ++ ++ +

ASIL C ++ ++ ++ +

ASIL D ++ ++ ++ +

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 1a. Couverture des instructions 1b. Couverture des branches 1c. MC/DC

ASIL A ++ + +

ASIL B ++ ++ +

ASIL C + ++ +

ASIL D + ++ ++

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 couverture 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:

le test.    

les résultats attendus de la séquence de test an de valider ou non

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 sur les principes de fonctionnement suivants : -

-

unittest de python qui repose

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 ) : d e f setUp ( s e l f ) : s e l f . img_test1 = cv2 . imread ( " t e s t _ i m g s / test_with_30_speed_limit . j p g " ) s e l f . img_test2 = cv2 . imread ( " t e s t _ i m g s / test_without_TS . j p g " ) s e l f . img_test3 = cv2 . imread ( " t e s t _ i m g s / speed_limit_80_cropped . j p g " ) s e l f . img_test4 = cv2 . imread ( " t e s t _ i m g s / TS_2sens_cropped . j p g " ) s e l f . img_test5 = cv2 . imread ( " t e s t _ i m g s / pharmacie_panel_cropped . j p g " ) s e l f . img_test6 = cv2 . imread ( " t e s t _ i m g s /test_two_TS . j p g " ) 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 " ) s e l f . img_test8 = cv2 . imread ( " t e s t _ i m g s / test_with_mcdo_panel . j p g " ) s e l f . img_test9 = cv2 . imread ( " t e s t _ i m g s / test_with_danger_TS . j p g " ) s e l f . img_test10 = cv2 . imread ( " t e s t _ i m g s / test_with_stop_TS . j p g " ) 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 " ) s e l f . img_test13 = cv2 . imread ( " t e s t _ i m g s / class_mandatory . j p g " ) 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 ] ] ) s e l f . v i d e = np . a s a r r a y ( [ [ 0 , 0 , 0 , 0 ] ] )

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

d e f tearDown ( s e l f ) : pass

18 19 20

21#TSR_02_01:################################################################### 22

23#############################TS02_01 :

d e f test_TS_02_01 ( s e l f ) : cap = cv2 . VideoCapture ( 0 ) p r i n t ( cap . isOpened ( ) ) s e l f . a s s e r t T r u e ( cap . isOpened ( ) )

24 25 26 27 28

29############################################################################## 30

31#TSR_02_02:################################################################### 32

33#############################TS_02_02 :

d e f test_TS_02_02 ( s e l f ) : 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 ) #p r i n t ( r e s u l t ) 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 ) 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 )

34 35 36 37 38 39

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 ) 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 )

40 41

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 suivantes : 

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 unitaires, 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'environnement 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 captures 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 exigences 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 rapport, 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'approfondir 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 valorisante 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 approches 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-enregistrespar-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-lagestion-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 positions 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 multicouche.

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) :



Indépendante : pour comprendre l'exigence, il ne devrait pas être nécessaire de connaître

l'exigence devrait être réalisable dans les limites des contraintes tels que le temps, l'argent et les ressources disponibles. 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 articielle. 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 reconnaissance 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 automobile 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'apprentissage 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 profondeur 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 canal 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'architecture 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 premiè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