Rapport Hadine Chaimae VFF

Rapport de Projet de Fin d’Études
En vue de l’obtention d’un diplôme d’ingénieur d’état en Génie électrique
Filière : Génie électrique systèmes embarqués et télécommunications
Réalisé au sein de "Emitech Engineering Africa"
Sous le thème :
Développement d’un outil de vérification des

spécifications CAN des calculateurs CMM et
EVCU
Réalisé par : Encadré par :

Chaimae HADINE Mr .Youssef MOUZOUNA
Mr . Abdelkrim MOUBTAKIR
Soutenu le :/06/2022
Membres de jury :
Pr. Abdelhadi ENNAJIH : Président
Pr . Mohammed KHALDOUN : Rapporteur
Pr .Youssef MOUZOUNA : Encadrant pédagogique
Mr. Abdelkrim MOUBTAKIR : Encadrante industriel
Promotion 2023
Dédicace
Je dédie ce modeste travail avec tous mes sentiments de

respect, d’amour et de reconnaissance à :
• Ma mère , pour lui exprimer mon amour sincère et
ma profonde gratitude pour l’éducation et
l’instruction qu’elle m’a donnée, son
dévouement et son soutien précieux.
• Mon père, qui a œuvré pour ma réussite, par son
amour, son soutien, et ses précieux conseils pour me
guider et me faire part de ses expériences.
• Mes deux sœurs et mon frère , ma plus grande
source de bonheur, par toute leur tendresse,
affection et encouragements.
• A ma grande famille : Je cite : Mes grands-parents,
mes tantes, mes oncles ainsi que mes cousins, mes
cousines, et toute personne ayant participé de
loin ou de près à la réalisation de ce travail.
I
Remerciements
Je remercie en premier lieu Allah le tout puissant de m’avoir donné la
patience, le courage et la force de mener fin ce projet de fin d’étude.
Je tiens à remercier la direction générale de Emitech Engineering Africa
d’avoir accordé la possibilité d’effectuer ce stage durant lequel j’ai pu vivre une
expérience sociale et professionnelle.
Mes remerciements à Mr Abdelilah LAKHAL directeur d’exploitation
pour son accueil, ses conseils et ses remarques pertinentes.
Mes remerciements les plus sincères et mon estime s’adresse à mon
encadrant au sein de la société Mr Abdelkrim MOUBTAKIR ingénieure
chargé de conception des calculateurs moteur pour son temps passé avec moi et
le partage de son expertise au quotidien.
Merci à Mr Anas EL GHOUATE , responsable technique de l’équipe Ecu
Designer boite blanche , qui a porté pour m’accompagner et qui a été tout le temps
à l’écoute et disponible pour me parrainer.
II
Je tiens également à rendre hommage à mon encadrant académique Mr
Youssef MOUZOUNA pour ses remarques et conseils, le corps professoral de
l’ENSEM et à tous les cadres, les employés et les stagiaires des différents services
de Emitech Engineering Africa pour leurs gentillesses et leurs accueils chaleureux
durant toute la période de mon stage.
HADINE CHAIMAE
III
Résumé
Le présent rapport constitue la synthèse du travail réalisé dans le cadre de mon
stage de fin d’étude au sein de la société Emitech Engineering Africa , particulièrement
dans l’équipe Ecu Designer qui travaille sur la conception de la messagerie CAN et la
modélisation de modèles VarDivMgt le VarDivMgtSCAN des calculateurs moteurs
CMM et EVCU dans les véhicules conventionnelles(essence, diesel) ,hybrides et
électrique.
En bref, mon sujet de stage consiste à développer un outil pour l’automatisation
de vérification des spécifications CAN des calculateurs CMM et EVCU .Cet outil sera
capable :
De vérifier la cohérence entre le modèle VarDivMgt , le VarDivMgtSCAN et la
messagerie CAN au niveau des flux d’activations des trames et des signaux en termes
de présence des flux d’activation dans toutes les fichiers puis généré les incohérences
trouvés .
Ainsi que détecter les noms des flux d’activations modélisés d’une manière non
conformes aux normes .
Mots-clés: Messagerie CAN ,VarDivMgt,CMM,EVCU,Flux d’activation,Trame,Signal.
IV
Abstract
This report is a summary of the work carried out as part of my end-of-study internship
at Emitech Engineering Africa, working in the Ecu Designer team on CAN messaging design
and VarDivMgt and VarDivMgtSCAN model modeling for CMM and EVCU engine ECUs
in conventional (gasoline, diesel), hybrid and electric vehicles.
In short, my internship involves developing a tool to automate the verification of
CAN specifications for CMM and EVCU ECUs:
Verify consistency between the VarDivMgt model, the VarDivMgtSCAN and CAN
messaging at the level of frame and signal activation flows, in terms of the presence of
activation flows in all files, and then generate any inconsistencies found.
As well as detecting activation flow names modeled in a non-standard way.
Keywords: CAN Messaging,VarDivMgt,CMM,EVCU,Activation

Flow,Frame,Signal.
V
Sommaire
Dédicace .......................................................................................................................................................... I
Remerciements ............................................................................................................................................... II
Résumé .......................................................................................................................................................... IV
Abstract .......................................................................................................................................................... V
Sommaire....................................................................................................................................................... VI
LISTES DES FIGURES......................................................................................................................................... X
LISTES DES TABLEAUX ................................................................................................................................... XII
Table des abréviations ................................................................................................................................. XIII
Cahier de charges ......................................................................................................................................... XIV
Introduction générale ......................................................................................................................................1
Chapitre I : Contexte générale du projet. .........................................................................................................4
Introduction : ...................................................................................................................................................2
1 Présentation de l’organisme d’accueil ...................................................................................2
1.1 Groupe EMITECH....................................................................................................................2
1.2 Filiale du groupe EMITECH......................................................................................................2
1.3 EMC .......................................................................................................................................2
1.4 Présentation de l’organisme d’accueil « Emitech Engineering Africa » .....................................2

1.4.1 Fiche représentative ..............................................................................................................3
1.4.2 Organigramme : .....................................................................................................................3
1.4.3 Service d’affectation : ............................................................................................................3
1.4.4 Le client principal : .................................................................................................................4
2 Problématique et cahier des charges.....................................................................................4
VI
3 Les outils utilisées .................................................................................................................6
3.1 Matlab ...................................................................................................................................6
3.2 Simulink .................................................................................................................................6
3.3 App Designer .........................................................................................................................6
4 Méthodologie du travail : ......................................................................................................7
4.1 Techniques de gestion du projet .............................................................................................7
4.2 Charte du projet : ...................................................................................................................7
5 Planification du travail :.........................................................................................................8
Conclusion :......................................................................................................................................................9
Chapitre2 :Etat de l’art .....................................................................................................................................9
Introduction : .................................................................................................................................................10
1 Contexte technique du projet..............................................................................................10
1.1 Généralités :......................................................................................................................... 10
1.1 Les calculateurs automobiles (ECUs) ..................................................................................... 10

1.1.1 Présentation ........................................................................................................................ 10
1.1.2 Fonctionnement .................................................................................................................. 11
1.1.3 Composition d’un ECU ......................................................................................................... 12
1.2 Calculateur moteur (Engine Control Unit): ............................................................................ 12

1.2.1 Fonctionnement de calculateur moteur :.............................................................................. 12
1.2.2 Les capteurs liées au calculateur moteur .............................................................................. 13
1.2.3 Les types du calculateur moteur : ......................................................................................... 14
1.2.4 Les défauts de calculateur moteur :...................................................................................... 15
1.3 Multiplexage ........................................................................................................................ 15

1.3.1 La nécessité du multiplexage ................................................................................................ 15
1.3.2 Principe du multiplexage automobile ................................................................................... 16
1.3.3 Avantage de multiplexage : .................................................................................................. 17
1.3.4 Eléments d’un réseau multiplexé :........................................................................................ 17
1.4 Le protocole de communication CAN .................................................................................... 18

1.4.1 Présentation ........................................................................................................................ 18
1.4.2 Domaine d’utilisation de bus CAN : ...................................................................................... 18
1.4.3 Avantage du CAN : ............................................................................................................... 19
VII
1.4.4 Variantes de protocole CAN ................................................................................................. 19
1.4.5 CAN dans le modèle ISO/OSI ................................................................................................ 20
1.4.5.1 La couche physique : ........................................................................................................... 20
1.4.5.2 La couche liaison :................................................................................................................ 23
1.4.5.3 La couche application : ........................................................................................................ 23
1.4.6 Test de fonctionnement du Bus CAN : .................................................................................. 24
1.4.7 Les types des trames CAN :................................................................................................... 24
1.4.8 Les champs de la trame de donnée :.................................................................................... 24
Conclusion :....................................................................................................................................................27
Chapitre III : Conception et Réalisation de l’outil...........................................................................................29
Introduction : .................................................................................................................................................30
1 Analyse du projet ................................................................................................................30
1.1 Analyse globale de l’application ........................................................................................... 30
1.2 Identification des acteurs ..................................................................................................... 30
1.3 Spécifications de besoins ...................................................................................................... 31
1.4 Identification des données traitées ....................................................................................... 31

1.4.1 Messagerie CAN : ................................................................................................................. 31
1.4.1.1 Les types de messagerie CAN : ............................................................................................. 31
1.4.1.2 Exemple de messagerie ...................................................................................................... 32
1.4.2 Modèle VarDivMgt : ............................................................................................................. 36
1.4.2.1 Principe du VarDivMgt : ....................................................................................................... 36
1.4.2.2 Calibration et flux de configuration : .................................................................................... 39
1.4.3 VarDivMgtSCAN : ................................................................................................................. 40
2 Architecture globale ............................................................................................................40
3 Réalisation et test ...............................................................................................................40
3.1 Développement des scripts ................................................................................................... 40

3.1.1 Organigrammes d’exécution du code ................................................................................... 41
3.2 Développement d’ IHM......................................................................................................... 53

3.2.1 Fenêtre de traitement nommé Tool ..................................................................................... 53
3.2.2 La deuxième fenêtre de l’outil nommée Help ....................................................................... 57
3.3 Document généré par l’outil . ............................................................................................... 58

3.3.1 Colonne commentaire.......................................................................................................... 58
VIII
3.3.1.1 Commentaire pour un flux d’activation détecté d’une trame............................................... 59
3.3.1.2 Commentaire pour un flux d’activation d’un signal .............................................................. 59
3.3.2 Colonne code d’erreur ........................................................................................................ 59
3.3.2.1 Code d’erreur pour un projet traité sans classification des flux ............................................. 59
3.3.2.2 Les codes d’erreur pour un projet si le traitement fait avec classification : ........................... 61
3.4 Validation de l’outil .............................................................................................................. 63
3.5 Mise à jour et documentation de la solution ......................................................................... 64

3.5.1 Documentation .................................................................................................................... 64
Conclusion :....................................................................................................................................................65
CONCLUSION ET PERSEPCTIVE........................................................................................................................68
Bibliographies et Webographie ......................................................................................................................69
IX
LISTES DES FIGURES
Figure 1 : Fiche représentative d' Emitech Engineering Africa.......................................................... 3
Figure 2:Les marques de groupe de Stellantis .................................................................................... 4
Figure 3:Logo du Matlab ................................................................................................................... 6
Figure 4:Logo du Simulink ................................................................................................................ 6
Figure 5:L’interface d'App Designer ................................................................................................. 7
Figure 6:Diagramme Gantt ................................................................................................................ 9
Figure 7:Calculateur automobile. ......................................................................................................11
Figure 8:Calculateur moteur .............................................................................................................12
Figure 9:Exemple d'un câblage classique ..........................................................................................16
Figure 10:Exemple d'un câblage après multiplexage .........................................................................17
Figure 11:Eléments d'un réseau multiplexé .......................................................................................18
Figure 12:Utilisation du Bus CAN dans l'automobile. .......................................................................19
Figure 13:Annulation du bruit électromagnétique .............................................................................21
Figure 14:Les types de bus CAN ......................................................................................................22
Figure 15:Les composants du bus CAN . ..........................................................................................22
Figure 16:Les champs de la trame de donnée ....................................................................................24
Figure 17:Exemple de principe d'arbitrage ........................................................................................25
Figure 18:Champ de commande .......................................................................................................26
Figure 19:Champ de données............................................................................................................26
Figure 20:Champ de CRC ................................................................................................................27
Figure 21:Les types de messageries ..................................................................................................32
Figure 22:Colonnes depuis la feuille FRAMES de la messagerie CAN .............................................33
Figure 23:Colonnes depuis la feuille SIGNALS de la messagerie CAN .............................................35
Figure 24:Les entrées et les sorties du VarDivMgt ............................................................................36
Figure 25:Principe du VarDivMgt ....................................................................................................37
Figure 26:Exemple d’activation et désactivation de la fonction CAN ................................................37
Figure 27 :Modèle VarDivMgt dans un projet avec classification . ....................................................38
Figure 28 :Le modèle VarDivMgt dans un projet sans classification..................................................39
Figure 29:Architecture global de l’outil ............................................................................................40
Figure 30:Organigramme du script Classification Signal ...................................................................42
Figure 31:Organigramme de script Classification Trame ...................................................................45
X
Figure 32:Organigramme du programme extraction_flux_avec_Classification ..................................46
Figure 33:Organigramme du programme ‘Extraction_flux_sans_classification' ................................48
Figure 34:Organigramme du programme 'Comparaison'....................................................................51
Figure 35:Organigramme du script 'Traitement final ' .......................................................................52
Figure 36:Fenêtre 'Tool' de l'outil CHECK FLOW' ...........................................................................54
Figure 37:La case a coché 'Scan file' .................................................................................................55
Figure 38:Scénario d'un traitement bien fait ......................................................................................55
Figure 39:Scénario des données manquants ......................................................................................56
Figure 40:Fonctionnalité d'initialisation des entrantes .......................................................................57
Figure 41: Fenêtre 'Help' ..................................................................................................................58
Figure 42:Colonne commentaire dans le rapport des incohérences ....................................................58
Figure 43:Colonne code d'erreur depuis le rapport généré .................................................................60
Figure 44:Composition du code d'erreur pour un projet sans classification ........................................61
Figure 45:Extrait du rapport généré d’un projet avec classification....................................................61
Figure 46:Filtrage des commentaires selon la nature du code d'erreur . ..............................................62
Figure 47:Composition du code d'erreur d'un projet avec classification .............................................63
XI
LISTES DES TABLEAUX
Tableau 1 :Fiche représentative d’ Emitech Engineering Africa .................................................... 3
Tableau 2:Charte du projet ............................................................................................................ 8
Tableau 3:Les capteurs liées au calculateur moteur .....................................................................13
Tableau 4:Actionneur liée au calculateur moteur .........................................................................14
Tableau 5 :Différence entre CAN FD et CAN HS .........................................................................20
Tableau 6:Bus CAN et modèle OSI ...............................................................................................20
XII
Table des abréviations
Abréviation Désignation
VarDivMgt Variant Diversity Management
CAN Controller Area Network
CMM Control Multifunction Moteur
EVCU Electrical vehicule control unit
VarDivMgtSCAN Variant Diversity Management CAN
ISO International Organization for Standards
ECU Electronic Control Unit
ABS module de commande du moteur
MCF Module de commande de frein
MCT Module de commande de transmission
MCS Module contrôle de suspension
ECM Engine Control Module
VA N Véhicule Area Network
LIN Local Interconnect Network
MOST Media Oriented Systems Transport
OSI Open Systems Interconnection
XIII
Cahier de charges
Le travail demandé par Emitech Engineering Africa est de :
1.Développer un script Matlab pour :
• L’extraction des flux d'activation des trames et signaux
embarqués dans la messagerie CAN.
• L’extraction des flux d'activation des trames signaux générés
par le modèle VarDivMgt .
• L’extraction des flux d'activation des trames signaux embarqués
dans le fichier VarDivMgtSCAN.
• Identification de l'écart entre le modèle VarDivMgt
,VarDivMgtSCAN et la messagerie CAN au niveau des flux
d’activations en termes de présence .
• Génération d’un rapport Excel incluant les écart trouvé .
• Validation de modélisation des flux d’activation dans le
VarDivMgt en lançant des scenarios de test .
• Génération d’un rapport Excel incluant les noms des flux
d’activations non conformes aux exigences .
2.Réalisation de l'interface graphique utilisant App Designer Matlab .
3. Test et validation de l’outil
XIV
Introduction générale
Le secteur automobile au Maroc a connu une évolution significative ces dernières
années. Il s'agit d'un secteur clé de l'économie marocaine. L'industrie automobile
marocaine s'est développée grâce à des politiques gouvernementales incitatives visant à
attirer les investissements étrangers, ainsi qu'à la proximité géographique de l'Europe,
qui est le principal marché de destination des voitures produites au Maroc.
Aujourd'hui, le Maroc compte plusieurs constructeurs automobiles étrangers
implantés sur son territoire, tels que Renault, PSA, Ford et Mitsubishi, qui produisent
des véhicules pour l'exportation vers l'Europe, l'Afrique et le Moyen-Orient.
Le Maroc a mis en place une stratégie ambitieuse visant à développer la filière de
la sous-traitance automobile, en encourageant l'installation de fournisseurs locaux pour
les constructeurs automobiles. Cette stratégie a permis de développer un réseau solide
de fournisseurs locaux, qui contribue à la compétitivité de l'industrie automobile
marocaine.
Dans le domaine de l'automobile, les systèmes embarqués sont de plus en plus
sophistiqués et jouent un rôle crucial dans la sécurité, le confort et les performances des
véhicules. Par conséquent, la qualité de ces systèmes est essentielle pour garantir la
sécurité des utilisateurs et pour maintenir la confiance des clients dans la marque.
1
Les erreurs dans ces systèmes embarqués peuvent entraîner des conséquences
graves, telles que des accidents de la route, des pannes de véhicules ou des défaillances
de sécurité. Ces incidents peuvent non seulement affecter la réputation de la marque,
mais également entraîner des coûts élevés liés aux rappels de véhicules, aux réparations
et aux éventuelles poursuites judiciaires.
Afin de garantir la qualité des systèmes embarqués, les constructeurs automobiles
doivent mettre en place des processus de développement et de test rigoureux. Cela
implique une collaboration étroite entre les équipes de conception matérielle et
logicielle, ainsi qu'un investissement dans des outils de test et de vérification avancés.
De plus, les constructeurs doivent être en mesure de détecter et de corriger rapidement
les erreurs identifiées lors des tests afin de minimiser les risques pour les clients.
En somme, la qualité des systèmes embarqués est un enjeu crucial pour l'industrie
automobile, et les constructeurs doivent faire preuve d'une grande rigueur dans leur
processus de développement et de test afin de garantir la sécurité et la satisfaction des
clients.
En tant que stagiaire pfe au sein de l'équipe Ecu Designer chez EMITECH, mon
objectif principal était de résoudre les problèmes d'erreurs de codage causés par des
incohérences entre trois fichiers conçus par l'équipe. Ces fichiers sont un fichier Excel
appelé "messagerie CAN" et un fichier Simulink appelé "VarDivMgt", le dernier est un
2
fichier Excel appelé "VarDivMgtSCAN" . De plus, je devais m'assurer que le modèle
"VarDivMgt" était correctement modélisé et respectait les exigences de modélisation.
Pour résoudre ces deux problématiques, j'ai entrepris le développement d'un outil
automatisé qui permet de vérifier la cohérence entre ces fichiers et de valider le modèle
"VarDivMgt". Grâce à cet outil, il est possible de détecter les incohérences avant la
phase de codage et de garantir que le modèle est conforme aux exigences de
modélisation de manière plus efficace et précise.
Ce rapport présente l’ensemble des différents acquis et tâches effectuées au sein
d’Emitech Engineering Africa, il est scindé en trois chapitres détaillés qui résument le
travail que j’ai fourni au cours de mon projet :
• Le premier chapitre présente Emitech Engineering Africa et Stellantis en tant que
organismes d’accueil, puis la problématique du projet et son cahier des charges,
ainsi que l’environnement logiciel de travail.
• Le deuxième chapitre présente et contextualise l’aspect technique de notre
projet .
• Le troisième chapitre traite la partie d’analyse et de conception de la solution et
les résultat du développement de l’outil ainsi que la phase de validation .
• Le rapport sera conclu par une conclusion générale qui synthétisera les principaux
résultats obtenus et suggérera des perspectives d'amélioration de l'outil en
proposant l'intégration de fonctionnalités supplémentaires.
3
Chapitre I
Contexte générale du projet
4
Chapitre I :Contexte générale du projet
Introduction :
Dans ce chapitre nous présentons l’organisme d’accueil : son rôle, son organigramme, ses services
et ses missions et nous précisons le cadre dans lequel le projet va évoluer : les objectifs, la démarche
suivie et la planification globale ainsi que l’environnement logiciel de travail.
1 Présentation de l’organisme d’accueil

1.1 Groupe EMITECH
EMITECH SAS et ses 8 filiales forment le groupe EMITECH .Un groupe indépendant compte
plus de 600 collaborateurs spécialisés dans les tests applicables aux équipements lors de leur
qualification ou leur homologation avant leur commercialisation mais aussi dans leur mobilité durable
avec son accompagnement dans la conception et la validation de groupes motopropulseurs . [1]
1.2 Filiale du groupe EMITECH

Les 8 filiales du groupe EMITECH sont :
• Eurosem
• Adetests
• Environne'Tech
• Pieme
• Lefae
• EMC
• EMC2
• EEA
• R&D Moteurs
1.3 EMC
Devenue filiale du Groupe EMITECH en 2019, les compétences de la filiale se sont élargies
et mutualisées avec l'ensemble des acteurs du Groupe .
Créé autour des Essais Moteur à Combustion, EMC est un acteur majeur dans les essais de
caractérisations et de mise au point des Groupes Motopropulseurs à combustible, hybride et électrique .
1.4 Présentation de l’organisme d’accueil « Emitech Engineering Africa »
Appartient au groupe EMITECH, crée récemment en 22 septembre 2021 c’est une filiale de
EMC France, opérant dans le secteur automobile précisément la fabrication des véhicules à moteur
ainsi que le secteur aéronautique.
2
Les valeurs de la société correspondent au savoir-faire, compétences, l’écoute du client,

l’innovation, le professionnalisme, la responsabilité, la confidentialité, la réactivité et la souplesse.
1.4.1 Fiche représentative
Tableau 1 :Fiche représentative d’ Emitech Engineering Africa
Entreprise Emitech Engineering Africa

Type Prestataire d’ingénierie
Création 2021
Secteur Secteur d’ingénierie
Directeur générale Abdelilah LAKHAL
Effectif global 70
Adresse 1100, Bd El Qods, Quartier Sidi Maârouf,
Casablanca, 20270, MA
1.4.2 Organigramme :
Figure 1 : Fiche représentative d' Emitech Engineering Africa
1.4.3 Service d’affectation :

Le service dont j’effectue mon stage est le pôle système EE boite blanche qui se trouve dans le
périmètre ECU DESIGNER (conception des calculateurs ) encadré par Mr .MOUBTAKIR Abdelkrim.
Les activités principales du périmètre Pole Système EE boite blanche :
• Le poste d’archi applicative qui fait la conception des messageries CAN applicative qui
contient les trames et les signaux d'un seul calculateur dans un projet spécifique .
• Le poste d’archi software qui fait la conception des architectures du projet .
• Le poste d’ODX qui assure le diagnostic des défauts .
• Le poste archi générique qui fait la conception des messagerie CAN générique .Cette
messagerie inclut les trames et les signaux de tous les projets et toutes les calculateurs .
3
1.4.4 Le client principal :

Le client majeur, auquel la société a rendu service durant ma période de PFE au sein d’ Emitech
Engineering Africa est Groupe Stellantis .
Le groupe Stellantis est parmi les grands groupes mondiaux de construction de véhicules
automobiles. L'entreprise produit de nombreux types de véhicules, différenciées selon la technologie,
le design et le prix de vente, on trouve par exemple Voitures « mini » citadines, les voitures citadines,
les compactes, les familiales, les routières et berlines de luxe comme l'illustre la figure 9. Ayant comme
vision d’être toujours sur la pointe de la technologie automobile, le groupe Stellantis a été parmi les
premiers constructeurs européens à proposer en France des véhicules électriques.
Figure 2:Les marques de groupe de Stellantis
2 Problématique et cahier des charges

La conception des calculateurs est une étape essentielle dans le développement d'un véhicule.
C'est l'activité de l'équipe ECU Designer chez Emitech Engineering Africa parmi leurs activités, ils
se chargent de la conception de la messagerie CAN (fichier Excel) et de la modélisation d'un modèle
Simulink appelé VarDivMgt et un fichier Exel appelé VarDivMgtSCAN.
Le premier fichier contient les spécifications des trames et des signaux d'un calculateur. Un signal
désigne l'information contenue dans une trame de données. Parmi ces spécifications, on trouve les
flux d'activations. Le terme "flux d'activation" fait référence à l'événement qui déclenche la
transmission de la trame ou du signal.
Le deuxième fichier est un modèle Simulink qui comprend un sous-système. Les sorties de ce
sous-système sont les flux d'activations des trames et des signaux. Ces flux d'activations sont le résultat
4
d'équations bien définies, modélisées à l'aide des composants de la bibliothèque PSA. Ce fichier
possède également un autre fichier Excel complémentaire appelé VarDivMgtSCAN, qui contient
uniquement les flux d'activations ayant toujours la valeur logique 1.
Les différents flux d'activations issus du VarDivMgt sont les entrées de la fonction CAN. En
effet, le rôle du VarDivMgt est de déterminer l'état logique de chaque flux. Ainsi, la cohérence entre
les flux de la messagerie CAN, du modèle VarDivMgt et du modèle VarDivMgtSCAN est essentielle,
car toute incohérence générerait des erreurs. Ces erreurs ne seront détectées qu'à la phase de codage,
qui suit la conception. L'équipe de codage devra alors informer l'équipe ECU Designer des erreurs
identifiées et demander la correction des incohérences à l'origine de ces erreurs. Cette situation risque
de retarder le travail de l'équipe et de diminuer sa productivité.
En conclusion de cette analyse, il apparaît que la vérification de la cohérence des flux
d'activations présents dans le VarDivMgt et le VarDivMgtSCAN et ceux de la messagerie CAN est
nécessaire. Cependant, cette procédure est difficile à réaliser manuellement en raison de la taille des
deux fichiers, qui peuvent contenir jusqu'à 2000 flux d'activations.
D'autre part, il est nécessaire de modéliser les flux d’activations du modèle VarDivMgt sous
Simulink de manière conforme aux exigences afin d'améliorer la qualité des livrables.
Dans le cadre de l'amélioration continue adoptée par l'équipe ECU Designer chez Emitech
Engineering Africa, visant à améliorer la qualité des livrables et augmenter la productivité de l'équipe,
mon sujet de fin d'études consiste à répondre au cahier des charges suivant :
1. Développer Des scripts Matlab pour :
• L’extraction des flux d'activation des trames et signaux embarqués dans la messagerie
CAN.
• L’extraction des flux d'activation des trames signaux générés par le modèle VarDivMgt .
• L’extraction des flux d'activation des trames signaux générés par le fichier
VarDivMgtSCAN .
• Identification de l'écart entre ces trois fichiers au niveau de flux d’activation en termes de
présence .
• Génération d’un rapport Excel incluant les écart trouvé.
• Valider le modèle VarDivMgt en extractant les flux d’activations modélisé dans ce modèle
d’une manière non conformes aux exigences .
• Génération d’un autre rapport Excel qui inclus les noms de flux d’activations des modélisés
d’une manière non conformes aux exigences .
2. Réalisation de l'interface graphique utilisant App Designer Matlab incluant les scripts
développés .
3. Test et validation de l'outil .
Afin de développer cet outil , j’ai utilisé la plateforme Matlab/Simulink ainsi que l’outil App
5
Designer .
3 Les outils utilisées

3.1 Matlab
MATLAB est une plateforme de calcul numérique et de programmation utilisée par des
millions d'ingénieurs et de scientifiques pour analyser des données, développer des algorithmes et
créer des modèles. [4]
Figure 3:Logo du Matlab
3.2 Simulink
Simulink est une plate-forme de simulation multi-domaine et de modélisation de systèmes
dynamiques. Il fournit un environnement graphique et un ensemble de bibliothèques contenant des
blocs de modélisation qui permettent le design précis, la simulation, l’implémentation et le contrôle
de systèmes de communications et de traitement du signal. [4]
Figure 4:Logo du Simulink
3.3 App Designer

App Designer est un environnement dans Matlab permet la création des applications web
et desktop .Il intègre les deux principaux tâches pour la création d’une application : le
positionnement des composants visuels d'une interface graphique utilisateur et la programmation
du comportement de l'application. [4]
6
Figure 5:L’interface d'App Designer
4 Méthodologie du travail :
4.1 Techniques de gestion du projet
Afin de réaliser notre projet, nous avons adopté une méthodologie de travail qui nous a permis
de mener à bien nos tâches et qui se présente comme suit :
• Planification du projet : j’ai organisé des réunions avec l’encadrant industriel au début du
stage afin de mettre en place le plan à suivre et aussi pour définir en détail les principales
tâches à réaliser avec les délais à respecter. Plus de détails seront présentés dans la partie
suivante concernant la planification du projet.
• Avancement et suivi du projet : Le suivi de l’état d’avancement du projet a été assuré par
des réunions planifiées avec l’encadrant industriel ainsi que par des réunions non planifiées
en cas de besoin.
• Suivi du projet de la part de l’encadrant académique : Le suivi pédagogique et technique
de la part de l’encadrant de l’école a été assuré par des rencontres et des échanges de mail.
• Rédaction du rapport de stage : Le rapport de stage qui est le résumé de l’expérience acquise
lors du stage, permet de décrire et de mettre en valeur le travail effectué, la contribution du
stagiaire ainsi que sa valeur ajoutée. Afin de délivrer un travail de qualité malgré les
contraintes de temps, nous avons établi une stratégie qui consiste à rendre compte au fur et
à mesure de l’avancement du projet.
4.2 Charte du projet :
7
Tableau 2:Charte du projet
Charte du projet
Thème Amélioration continue de l’équipe

ECU DESIGNER en augmentant la
productivité de l’équipe et la maturité de ces
livrables .
Objective Mise en place d’un outil pour assurer
une vérification automatique de la cohérence
entre le modèle VarDivMgt,le
VarDivMgtSCAN et la messagerie CAN au
niveau des flux d’activations pour les
calculateurs CMM et EVCU ainsi que la
validation du modèle VarDivMgt .
Etat souhaité
Un outil robuste qui :
• Prend en entré la messagerie CAN , le
modèle VarDivMgt et le modèle
VarDivMgtSCAN.
• Génère comme sortie un rapport
Excel qui contient :
 les incohérences trouvées au
niveau des flux d’activations entre
le modèle VarDivMgt , le
VarDivMgtSCAN et la
messagerie CAN en termes de
présence .
 Les noms des flux d’activations
qui sont modélisés d’une manière
non conformes aux exigences .
5 Planification du travail :
La planification fait partie des phases préparatoires les plus importantes, il consiste à définir et à
planifier les tâches du projet et à estimer leurs charges respectives. J'ai utilisé le diagramme de
GANTT comme outil de planification de projet. Il s'agit d'un outil qui permet de planifier un projet et
8
de faciliter le suivi de progression. Ce diagramme illustre également l'enchaînement et la durée des

différentes tâches. .
Figure 6:Diagramme Gantt
Conclusion :
Ce chapitre introductif a été consacré essentiellement à la présentation de l’environnement dans
lequel mon projet de fin d’études a été effectué. Il a aussi mis l’accent sur la présentation du contexte
général de mon projet, ses objectifs ,les outils utilisés et sa planification.
9
Chapitre II
Généralités sur la conception des
calculateurs moteur
9
Chapitre II :Etat de l’art des calculateurs moteurs
Introduction :
Ce chapitre introduit les concepts clés de l'automobile. Nous abordons les unités de commande
électronique et prenons l'exemple du calculateur moteur, qui est le sujet principal de mon projet de fin
d'études. Nous expliquons son principe de fonctionnement, ses caractéristiques et ses différents types.
Ensuite, nous présentons le principe du multiplexage et ses composants, ainsi que des informations sur
le protocole de communication CAN.
1 Contexte technique du projet

1.1 Généralités :
La plupart des constructeurs automobiles s’orientent vers l’extension de technologies plus
innovantes afin d’offrir de meilleures solutions en termes de connectivité. Parmi ces technologies ,les
systèmes embarqué et la notion du temps réel.
On désigne par système embarqué un système électronique et informatique autonome qui réalise
une tâche précise .Les systèmes embarqués dans les véhicules jouent un rôle central dans le
fonctionnement global des systèmes automobiles. Ils sont conçus pour intégrer, contrôler et surveiller
les différentes fonctions du véhicule à partir d'une unité centrale appelée l'ECU (Electronic Control
Unit).
Le temps réel consiste à ajouter une notion de temps d’exécution à une tâche .Dans les véhicules
certains tâches doivent avoir une durée limitée à ne pas dépasser sinon la vie du conducteur et des
passagers sera affecter. Par exemple le temps de réaction entre le moment ou le conducteur appuie sur
le frein et celui où les roues sont ralenties .
1.1 Les calculateurs automobiles (ECUs)

1.1.1 Présentation
Electronic Control Unit (ECU) ou Unité de Commande Electronique (UCE) dans l’automobile,
désigne un calculateur embarqué ou système embarqué qui commande plusieurs dispositifs physiques
au sein d’un véhicule.
10
Figure 7:Calculateur automobile.
Les nouveaux véhicules peuvent avoir jusqu'à 80 ECU ,en fait il existe différents types de
calculateurs :
➔ Module de commande du calculateur :
MCM assure la quantité de carburant et le calage de l’allumage nécessaires pour tirer le
meilleur parti de la puissance et de l’économie du moteur.
➔ Module de commande de frein :
Utilisé dans les véhicules équipés de l’ABS ,le MCF s’assure que les roues ne dérapent pas et
détermine quand déclencher le freinage et lâcher le frein pour s’assurer que les roues ne se bloquent
pas .
➔ Module de commande de transmission :
Utilisé dans les véhicules automatique ,le MCT assure d’obtenir les changements de vitesse les
plus fluides possibles en évaluant le régime moteur et l’accélération de la voiture .
➔ Module de commande télématique :
Le MCT garantit que les services embarqués de la voiture sont opérationnels .Ils contrôlent la
navigation par satellite et la connectivité internet et téléphonique du véhicule .
➔ Module contrôle de suspension :
Présent dans les voitures équipes de systèmes de suspensions actifs , le MCS garantit la hauteur
de caisse correcte et des changements optimaux de suspension en fonction des conditions de conduite
.
1.1.2 Fonctionnement
Quel que soit le système ,le fonctionnement du calculateur est toujours le même est la gestion
d’une fonction par l’intermédiaire des actionneurs après avoir reçu des informations par les capteurs.
11
1.1.3 Composition d’un ECU

L’ECU est composé d’un calculateur électronique et d’un logiciel embarqué qui réalise un
asservissement. Les principaux composants d’un calculateur électronique sont :
❖ Le cœur (Microcontrôleur) .
❖ La mémoire (SRAM, EEPROM, Flash).
❖ Les entrées (Tension d’alimentation, entrées numériques, entrées analogique) .
❖ Les sorties (Relais, driver pont H, sorties logique) .
❖ Convertisseur analogique numérique.
1.2 Calculateur moteur (Engine Control Unit):

Le calculateur moteur, tout comme les autres calculateurs embarqués, est apparu suite à
l'utilisation croissante de l'électronique dans l'industrie automobile. Les constructeurs ont poursuivi
deux objectifs principaux lors de son développement : optimiser la consommation de carburant et
respecter les normes de pollution ,d’un autre coté d’ assurer le pilotage et le contrôle des fonctions
électroniques du moteur .
Le calculateur moteur est composé de l’ECU , un boitier en métal étanche conçu pour résister
aux différents conditions météorologiques. [2]
Figure 8:Calculateur moteur
1.2.1 Fonctionnement de calculateur moteur :

Le module de commande du moteur (ECM), également appelé unité de commande du moteur
(ECU), garantit que le véhicule fonctionne à des performances optimales. L’ECM surveille la plupart
des capteurs dans le compartiment moteur afin de gérer le mélange air-carburant du véhicule et de
réguler les systèmes de contrôle des émissions.
L’ECM régule quatre parties principales du véhicule : le rapport air-carburant, le régime de
ralenti, le calage variable des soupapes et le calage de l’allumage.
➔ Rapport air-carburant :
12
l’ECM utilise des capteurs pour réguler le rapport oxygène / carburant détecté dans
l’échappement du voiture afin de détecter une lecture riche / pauvre en moteur. Certains de ces capteurs
comprennent le(s) capteur(s) de débit d’air massique, le(s) capteur(s) d’oxygène, le(s) capteur(s) air-
carburant.
➔ Régime de ralenti :
l’ECM s’appuie sur des capteurs situés près du vilebrequin et du ou des arbres à cames qui
suivent le régime et la charge du moteur du véhicule en surveillant la vitesse de rotation du moteur.
➔ Système de calage variable des soupapes :
Contrôle le moment où les soupapes sont ouvertes dans le moteur pour augmenter la puissance
ou l’économie de carburant.
➔ Calage de l’allumage :
C’est-à-dire la position à laquelle la bougie d’allumage est allumée dans le cycle de
combustion. Un contrôle précis de cette synchronisation permet d’obtenir plus de puissance et/ou une
meilleure économie de carburant.
L’ECM contrôle également plusieurs autres systèmes en plus de ces tâches principales. On
l’appelle souvent le cerveau de la voiture, et à juste titre, car presque tout ce qui est nécessaire pour
faire fonctionner les voitures modernes passe par l’ECM, sinon directement contrôlé par celui-ci.
1.2.2 Les capteurs liées au calculateur moteur
Voici quelques capteurs et actionneurs souvent reliés aux calculateur moteur .
Tableau 3:Les capteurs liées au calculateur moteur
Capteur Rôle
Permet au moteur de varier la vitesse
Le capteur de la pédale du véhicule en fonction de la position de la
d’accélérateur. pédale
Indiquent la température des éléments
Les capteurs de température. constituants le moteur .
Le capteur de cliquetis. Signale une combustion anormale

dans le moteur .
Les sondes lambda. mesurent la quantité des gaz
d’échappement du véhicule .
Envoie des signaux relatifs au cycle de
Le capteur d’arbres à cames. combustion du moteur .
Le tableau ci-dessous contient les actionneurs souvent liés au calculateur moteur :
13
Tableau 4:Actionneur lié au calculateur moteur
Actionneur Rôle
Sont présentes dans la chambre de
Les bougies combustion enflamment le mélange air et
carburant pour les moteurs à essence .
Envoient le carburant soit au sein

Les injecteurs conduite d’admission d’air du moteur soit
dans le cylindre .
Réduit les émissions de gaz toxiques

La vanne EGR en réinjectant des gaz d’échappement recyclés
dans le moteur .
Moduler la quantité d’air nécessaire au
Le boitier papillon moteur en fonction de la puissance demandée
.
1.2.3 Les types du calculateur moteur :
Les calculateurs moteurs peuvent être classé en distinguant la nature de véhicule dont ils seront
embarqués et celles-ci peuvent être classées selon la source d’énergies utilisées .Jusqu’à présent il y a
trois types de véhicules qui sont commercialisé , on peut les définir comme suit :
➔ Voiture thermique :
Voiture qui possède un moteur à combustion et explosion ou moteur thermique .Le
fonctionnement de ce moteur repose sur l’utilisation d’un carburant composé le plus souvent de
produits pétroliers .Le carburant de la voiture thermique permet une combustion à l’intérieur du moteur
suite au mélange avec de l’air .Ainsi , l’énergie chimique du carburant est transformée en énergie
mécanique pour faire avancer le véhicule.
➔ Voiture électrique :
Voiture qui présente la particularité d’être partiellement ou totalement mue par un ou plusieurs
moteurs électriques .les BEV (Battery electric vehicle) sont des voitures mues en tout temps par la
force électromotrice d’un moteur électrique .Elle embarque donc des batteries à grande capacité qui
doivent être rechargées à un borne fixe .Mais l’engin est alors immobilisé durant plusieurs heures.
➔ Voiture hybride :
Voiture est une voiture qui mélange deux types de motorisation :un moteur thermique
(essence)et au moins un moteur électrique ,alimenté par une batterie .C’est un véhicule qui avance
grâce à deux sources d’énergies distinctes : le carburant d’un côté et l’électricité de l’autre .
14
A partir des types de véhicules cités ci-dessus on peut dire qu’il y a deux types de calculateur
moteur ,ces types sur lesquelles je vais travailler dans mon sujet PFE .
• CMM (Calculateur Multifonction Moteur) : Un calculateur moteur pour les véhicules
conventionnelles (essence , diesel).
• EVCU (Unité de contrôle des véhicules électriques) : Un Calculateur moteur pour les
véhicules électriques.
1.2.4 Les défauts de calculateur moteur :
Le calculateur moteur est une pièce maitresse de tous les véhicules et comme tout autre composants
électroniques il se peut qu’il tombe en panne .
Parmi les symptômes de la panne d’un calculateur moteur :
• Ralentissement instable.
• Trous à l’accélération .
• Manque de puissance moteur .
• Une lenteur dans le fonctionnement du régime moteur .
• Une augmentation anormale du consommation de carburant .
• Plusieurs voyants allumés en même temps sur le tableau de bord .
Ces signes peuvent être résultat d’un calculateur voiture défectueux , comme ils peuvent être
causée par le dysfonctionnement d’autres composants électroniques. La source des défauts pourraient
être divers et varié .Pour cela ,il faut faire un diagnostic automobile afin d’identifier la panne .
1.3 Multiplexage
1.3.1 La nécessité du multiplexage
Pour satisfaire aux exigences qui sont de plus en plus sévères en matière de pollution ainsi
que les améliorations en matière de sécurité et de confort . L’industrie automobile a développé de
nombreux systèmes électroniques : systèmes anti-patinage, contrôle électronique du moteur et de l’air
climatisé, fermeture centralisée des portes, gestion moteur ,Airbag ..etc.
Ce renforcement de l’électronique se traduit par une augmentation du nombre de calculateur
ainsi que le nombre des capteurs. Sans oublier le nombre élevé de faisceaux de câbles électriques dans
les véhicules qui présente plusieurs inconvénients majeurs.
Tout d'abord, cela engendre des problèmes d'encombrement, ce qui affecte sérieusement la
fiabilité et la facilité de réparation des véhicules. De plus, cette complexité de câblage accroît les coûts
de fabrication et entraîne une augmentation du poids du véhicule.
Dans ce cadre , afin de limiter l’inflation des composants et du volume des câblages on a
besoin à une solution technique qui propice à l’échange des informations.
15
1.3.2 Principe du multiplexage automobile

Le multiplexage en automobile consiste à faire circuler dans peu de fils (un ou deux) une
multitude d’informations entre les différents calculateurs du véhicule. On appelle « bus » ou « réseau
de communication » le circuit électrique qui véhicule les informations « multiplexées ». Il permet le «
dialogue » entre les calculateurs. [3]
Ci-dessous dans les deux figures 9 et 10 on trouve deux schémas qui montre la différence
entre le câblage classique entre les équipements et le nouveau câblage lors de l’utilisation du
multiplexage .
Figure 9:Exemple d'un câblage classique
16
Figure 10:Exemple d'un câblage après multiplexage
1.3.3 Avantage de multiplexage :

Le multiplexage présente une gamme d'avantages significatifs, on peut citer :
• Moins de capteurs et/ou de nombres de liaisons avec les boîtiers .
• Le poids et les coûts diminuent.
• Augmentation de la qualité de transmission .
• Meilleure évolutivité.
• Enrichissement de fonctions sans surcoût important .
• Il informatise le diagnostic du système plus efficacement (échanges d’informations plus
rapides).
• Possibilité de désactiver et activer des fonctions .
1.3.4 Eléments d’un réseau multiplexé :
Un réseau multiplexé en automobile se compose de trois éléments comme l'illustre la figure 11 :
• Bus :Il s’agit d’un fil , son rôle est de transmettre les informations entre les différents
calculateur .
• Calculateur : Ils reçoivent et transmettent les informations en les décodant.
• Le protocole : la manière dont sont encodés et codés les informations .Il y a plusieurs
protocolesq , on trouve :
▪ CAN :Control Area Network.
▪ VAN :Véhicule Area Network.
▪ LIN :Local Interconnect Network
▪ MOST :Media Oriented Systems Transport.
17
Figure 11:Eléments d'un réseau multiplexé
1.4 Le protocole de communication CAN

1.4.1 Présentation
Le CAN signifie Controller Area Network est un bus de communication son rôle est d’établir
la communication entre les différents systèmes embarqués temps réel avec un haut niveau de fiabilité.
Il est avant tout à classer dans la catégorie des réseaux de terrain utilisé dans l'industrie.
La ligne principale qui constitue la base d’un système de bus CAN s’appelle ‘backbone’, celle-
ci sert à relier toutes les calculateurs du véhicule et toutes les informations sont envoyées à un
calculateur centrale appelée BCM ‘Body Control Unit’ qui est responsable de la surveillance de toutes
les autres calculateurs .
1.4.2 Domaine d’utilisation de bus CAN :
Le bus CAN est un bus de terrain temps réel et dans des environnements difficiles tel que :
l’automobile, le bâtiment, l’agriculture, la marine, le matériel médical, les machines textiles, etc.
Dans le domaine automobile le CAN est utilisé surtout pour la mise en réseau
• des organes de commande du moteur.
• de la boîte à vitesse.
• de la suspension et des freins .
• de carrosserie et de confort (commande des feux, des lève-vitres, de la climatisation, du
verrouillage central, réglage de sièges et de rétroviseur).
18
Figure 12:Utilisation du Bus CAN dans l'automobile.
1.4.3 Avantage du CAN :

Le bus CAN a plusieurs avantages par rapport aux autres bus de communications , tel que :
• Fiabilité : le CAN utilise un signal différentiel et une paire torsadé .
• Faible cout :le CAN utilise peu de câble pour connecter les différents composants
électroniques ,ce qui réduit le cout de fabrication .
• Faible consommation d’énergie : le CAN utilise peut de courant pour fonctionner , ce
qui réduit la consommation d’énergie et augmente l’autonomie des véhicules
électriques.
• Haute vitesse de transmission : jusqu’au 1Mbit/s.
• Flexibilité : Le CAN peut être utilisé pour connecter une très grande variété de
composants électroniques.
1.4.4 Variantes de protocole CAN
CAN (Controller Area Network) HS (High-Speed) et CAN FD (Flexible Data Rate) sont deux
variantes du protocole CAN utilisées dans les systèmes de communication automobile.
Le CAN FD (flexible Data Rate ) est une extension du protocole CAN classique est inventé
pour résoudre le problème de l imitation de la bande passante et aussi caractérisé par la flexibilité de
débit et la rapidité .
Voici les différences principales entre CAN HS et CAN FD :
19
Tableau 5 :Différence entre CAN FD et CAN HS
Critères CAN HS CAN FD
Vitesse de transmission des 1 Mbit/s. 5 Mbit/s, mais peut aller jusqu'à

données maximale 8 Mbit/s.
Capacité de la charge utile 8 octets. 64 octets.
Rétro compatible avec les N'est pas rétro compatible avec

Support de la anciens systèmes utilisant le les systèmes utilisant
rétrocompatibilité protocole CAN. uniquement le protocole CAN
classique.
Format de trame étendu qui
Format de Trame fixe avec une permet une longueur de charge
Mécanisme de transmission longueur de charge utile de 8 utile variable. La trame FD
octets. comprend une section de
données supplémentaire pour
une charge utile supérieure à 8
octets.
1.4.5 CAN dans le modèle ISO/OSI

CAN est un réseau compatible au modèle de référence ISO/OSI (ISO : International
Organization for Standards, OSI : Open Systems Interconnection). CAN a été normalisé par l’ISO dans
les normes 11898 pour les applications à haute vitesse (jusqu’à 1 Mb/s) et ISO 11519 pour les
applications à basse vitesse (jusqu’à 125 kb/s).
Les spécifications s’intéressent essentiellement aux couches physiques et liaison de données
uniquement.
Tableau 6 : Bus CAN et modèle OSI
Modèle ISO/OSI Protocole CAN

Application Spécifié par l’utilisateur(son application)
Présentation Vide
Session Vide
Transport Vide
Réseau Vide
Liaison Protocole CAN
1.4.5.1 La couche physique :
La première couche du modèle a pour but de conduire les éléments binaires jusqu'à leur
destination sur le support physique. Elle fournit les moyens matériels nécessaires à l'activation, au
maintien et à la désactivation de ces connections physiques.
20
Cette couche gère la représentation du bit (codage, timing, synchronisation), et définit les
niveaux électriques, optiques,... des signaux ainsi que le support de transmission.
a. Etude de la couche physique CAN :
Un bus de communication a donc souvent pour support physique deux fils trosadés.Ces fils sont
nommées CAN high et CAN low.
Pour diminuer le risque de défaut de transmission, des dispositions ont été prises au niveau la couche
physique :
• la transmission est réalisée sur deux fils (nommés CAN high et CAN low) .
• La ligne de bus CAN est fabriquée à base d’une paire torsadés et à chaque extrémité on trouve
une résistance de 120ohms comme l'illustre la figure 13 .
Figure 13:Annulation du bruit électromagnétique
• la somme des tensions est toujours constante quel que soit le niveau logique (le bit)
transmis.
En pratique, il y a trois bus CAN différents dans une voiture, à des débits différents :
• Un bus très rapide pour gérer la sécurité (freinage, ABS, détection chocs, airbags...)
• Un bus à vitesse moyenne pour gérer le moteur (commandes et capteurs)
• Un bus lent pour gérer tous les accessoires (lampes, moteurs d’asservissements, boutons...)
Il existe sous deux versions :
• CAN2.0A : trame standard identificateur de 11 bits (CAN standard)
• CAN2.0B : trame plus longue avec identificateur sur 29 bits (CAN étendu)
Il existe deux types de protocole CAN :
• CAN Low Speed : pour des vitesses de 40kbits/s à 125kbits/s.
• CAN High Speed : pour des vitesses allant jusqu’à 1Mbits/s .
21
Figure 14:Les types de bus CAN
NB : c’est le type de transceiver utilisé qui va différencier le type de protocole CAN low
speed où high speed .
b. Les composants de bus CAN
Tous les calculateurs présents sur un réseau sont reliés par les modules émetteur/récepteur
intégrés dans les calculateurs comme l'illustre la figure 15. Chaque calculateur connecté est appelé un
nœud.
Dans la figure 15 , on trouve le schéma de principe d’un module
émetteur/récepteur :(Le module émetteur/récepteur est appelé transceiver en anglais).
Figure 15:Les composants du bus CAN .
Le bus de donnée CAN se compose de trois éléments le contrôleur ,d’un émetteur-récepteur, de

deux terminaisons et deux lignes de bus de données .A part les lignes de données ,les composants se
trouvent dans les appareils de commande .
22
➔ Le contrôleur CAN :
Reçoit du micro-ordinateur intégré à l’appareil de commande les données .Il les traite et les
transmette à l’émetteur-récepteur CAN .De la même manière recevra de l’émetteur-récepteur des
données ,les traitera puis les transmettra aux micro-ordinateurs intégré à l’appareil de commande .
➔ L’émetteur récepteur CAN :
Il s’agit d’ un émetteur et un récepteur à la fois .Il convertit les données venant du contrôleur
CAN en signaux électriques ,puis les transmettent sur les lignes du réseau en bus .De la même manière
,il reçoit les données et les convertit pour le contrôleur du bus de donnée CAN .
➔ La terminaison du bus données :
Il s’agit d’une résistance .Elle empêche que les données ne soient renvoyées par les extrémités
sous forme d’écho et que les données soient ainsi falsifiées .
➔ Les lignes de bus de données :
Ils sont bidirectionnels et servent au transfert des données .Elles sont désignés par CAN-high
et CAN-low .
1.4.5.2 La couche liaison :
Elle fournit les moyens fonctionnels nécessaires à l'établissement, au maintien et à la libération
des connexions entres les entités du réseau. Cette couche (aussi appelée couche de communication de
données, Data Link Layer) devra notamment corriger les erreurs qui ont pu se produire au premier
niveau (même s'il est impossible de corriger toutes les erreurs).
Le protocole CAN décrit entièrement cette couche. La couche liaison est subdivisée en deux
sous-couches :
• La sous-couche LLC (Logical Link Control) effectue :
o le filtrage des messages,
o la notification des surcharges (overload),
o la procédure de recouvrement des erreurs.
• La sous-couche MAC (Medium Access Control), qui est le coeur du protocole
CAN, effectue :
o la mise en trame du message,
o l'arbitrage,
o l'acquittement,
o la détection des erreurs,
o la signalisation des erreurs.
1.4.5.3 La couche application :
C'est la dernière couche du modèle OSI. Elle donne aux applications le moyen d'accéder
aux couches inférieures.
23
Cette couche n'est bien sûr pas vide pour le protocole CAN, mais sa spécification est
laissée à l'utilisateur.
1.4.6 Test de fonctionnement du Bus CAN :
➔ Par mesure des résistance de terminaisons :
Un contrôle rapide pour tester la continuité du réseau CAN peut se faire en mesurant la
résistance entre CAN H et CAN L (hors tension et toutes les calculateurs branchées ).
Le test consiste a mesuré deux résistances de 120Ohms les deux résistances en parallèles
normalement doivent données par mesure 60Ohms et toutes autres valeurs signifie qu’il y a un
problème .En comparant la valeurs mesurées avec la valeur 60Ohms on peut identifier la nature du
problème .
•
Si R inférieur à 60Ohms signifie qu’il y a un court-circuit dans la ligne ou il y a plus de
deux résistances dans la ligne .
• Si R est supérieur à 60Ohms signifie qu’il y a une coupure dans la ligne et si la valeur
est supérieure à 120Ohms donc cela signifie l’absence de l’un des résistances de
terminaisons .
➔ Autre procédure de contrôle :
Prise de mesure de la tension sur le réseau , la somme des deux CAN H et CAN L doit être
égale à 5V.
1.4.7 Les types des trames CAN :
Il existe quatre types de trames CAN :
• Trame de données : la seule trame pour la transmission effective des données.

• Trame d'erreur : contient des nœuds pour détecter les erreurs.
• Trame de surcharge : injecte lorsqu'il y a un délai entre les données et la trame de requête
• Trame de requête : une trame qui demande des informations à un identifiant spécifique
1.4.8 Les champs de la trame de donnée :
Figure 16:Les champs de la trame de donnée
24
Champ initial :
Le bit SOF (début de trame de données) : marque le début d’un protocole de données. Sur la
ligne High du bus CAN, on émet un bit d’environ 5 volts (en fonction du système) et un bit d’environ
0 volt sur la ligne Low du bus CAN.
Toutes les stations doivent se synchroniser sur le front avant la transition du bit de départ.
Champ d’arbitrage :
Afin de minimiser les collisions , chaque nœuds écoute le bus CAN avant de transmettre
l’information sur le bus .Dans le cas ou deux ou plusieurs nœuds envoient les informations en même
temps , une collision est détectée et le bus qui envoie un dernier bit d’identificateur avec un état zéro
(dominant) tandis que les autres nœuds envoient un bit 1 (récessif ) le nœud conserve le contrôle de
bus et termine l’envoie de ces informations .
Figure 17:Exemple de principe d'arbitrage
Identificateur :La longueur de l'identificateur est de 11 bits, les bits sont transmis dans l'ordre
de ID_10 à ID_0 (le moins significatif est ID_0). Par ailleurs les 7 bits les plus significatifs (de ID_10
à ID_4) ne doivent pas être tous récessifs.
ID = 1111111XXXX (X valeur indéterminée), c'est-à-dire un nombre maximal
d'identificateurs de : (211 - 24) = 2048 - 16 = 2032 combinaisons.
Le bit RTR :Lors d'une dataframe, le bit de remote transmission request (RTR) doit être
dominant.
Champ de commande :
Dans ce champ se trouve le nombre d’informations contenues dans le champ des données.
Chaque récepteur peut alors vériﬁer s’il a bien reçu toutes les informations.
25
Il est constitué de 6 bits.
Figure 18:Champ de commande
Il y a deux Bits de réserves R0 et R1 : Les deux premiers bits (émis dominants en trame 2.0A)
sont en réserve d'usages ultérieurs et permettent d'assurer des compatibilités futures ascendantes
(notamment celles de la trame dite étendue CAN 2.0B). Les contrôleurs CAN doivent être aptes à
traiter toutes combinaisons de tous les bits du champ de commande.
4 bits DLC : Les 4 derniers bits du champ de commande (champ DLC - Data Length Code)
indiquent le nombre d'octets qui seront contenus dans le champ de données.
Champ de données :
Le champ de données est l'endroit où se trouvent les données utiles transmises c’est-à-dire les
signaux à transmettre d’un calculateur à un autre . Il peut être composé de 0 octet minimum à 8
octets maximum transmis avec le MSB (Most Significant Bit) en tête.
Remarque : De 0 à 8 inclus, cela fait neuf valeurs donc 4 bits du DLC pour définir le nombre de
données contenues.
Figure 19:Champ de données
Le champ de CRC :
La séquence de CRC (Cyclic Redundancy Code) permet de vérifier l'intégrité des données
transmises.
26
Il est composé de la séquence de CRC sur 15 bits suivi du CRC Delimiter (1 bit récessif).
Les bits utilisés dans le calcul du CRC sont ceux du SOF, du champs d'Arbitration, du champ de
Control et du champ Data Field.
Figure 20:Champ de CRC
Le champ ACK :
les récepteurs signalisent à l’émetteur qu’ils ont correctement reçu le protocole de données. Si
le défaut est détecté, ils en informent immédiatement l’émetteur. L’émetteur répétera la transmission.
Il est composé de 2 bits, l'ACK Slot et le ACK Delimiter (1 bit récessif).
• un nœud en train de transmettre envoie un bit récessif pour le ACK Slot.
• un nœud ayant reçu correctement un message en informe le transmetteur en envoyant un bit
dominant pendant le ACK Slot : il acquitte le message.
Fin de trame de donnée :
Termine le protocole de données. C’est la dernière possibilité de signaler des erreurs, qui
déclenchera une répétition du processus.
Conclusion :
Dans ce chapitre, nous avons vu un aperçu sur l’industrie automobile, ainsi que les calculateurs
CMM et l’EVCU sur lesquelles je vais travailler dans mon sujet de stage. Dans le chapitre qui suit
nous présenterons la phase de conception et réalisation de notre solution ainsi que la phase validation.
.
27
Chapitre III
Conception et Réalisation de
l’outil
29
Chapitre III :Conception et réalisation de l’outil
Introduction :
Dans ce chapitre, nous allons examiner en détail la phase de développement d'une Toolbox
desktop visant à automatiser et faciliter une tâche spécifique pour les ingénieurs de l'équipe Ecu
Designer. Nous mettrons ensuite l'accent sur les fonctionnalités clés qui la rendent efficace et utile
pour l'équipe.
Ensuite, nous passerons en revue les résultats du développement de la Toolbox et présenterons les
fonctionnalités implémentées .Enfin, nous allons aborder la méthode de validation adoptée.
1 Analyse du projet
La phase d'analyse et de spécification des besoins revêt une importance fondamentale dans le
cycle de développement d'un projet, car elle permet une compréhension approfondie du travail requis
en identifiant les besoins spécifiques des acteurs impliqués que le système doit satisfaire. Cette étape
clé aide à déterminer précisément ce que le projet doit accomplir.
1.1 Analyse globale de l’application

L'objectif de cette partie du projet est de développer une application de bureau qui automatise
l’exécution d’un ensemble de tâche sur différents fichiers de conception des calculateurs.
La réalisation de ce projet demande une approche de développement complexe qui implique la
mise en place de multiples solutions. Les solutions individuelles doivent être reliées pour former un
outil complet, robuste et fiable.
Pour répondre à cette exigence, nous avons suivi une approche méthodique en procédant d'abord
à l'analyse, puis à la conception de la solution, avant de passer à la phase de réalisation. Cette séquence
nous permet de simplifier les tâches et d'avoir une vision claire du résultat final attendu.
1.2 Identification des acteurs

Les principaux acteurs du programme sont les ingénieurs de l'équipe Ecu Designer, en particulier
la personne en charge du développement du modèle VarDivMgt, ainsi que les ingénieurs responsables
de la conception de la messagerie CAN .Ces acteurs vont bénéficier de l’outil lors de la vérification
de la cohérence entre le modèle VarDivMgt et la messagerie CAN ainsi que le fichier
VarDivMgtSCAN niveau des flux d’activations en termes de présence dans fichiers.
Cela facilitera la tâche de l'équipe, car il suffira d'ajouter les flux manquants lors de la procédure
de vérification. Cela permettra d'éviter les erreurs lors de la phase de codage pouvant résulter d'un
flux manquant, ce qui améliorera la productivité de l'équipe.
30
1.3 Spécifications de besoins

Les ingénieurs de l'équipe Ecu Designer utilisent principalement l’outil pour effectuer la tâche
suivante :
Préparer un fichier Excel qui répertorie les incohérences détectées entre le modèle VarDivMgt ,
la messagerie CAN et le fichier VarDivMgtSCAN en termes de présence de flux d'activations dans
l’un de ces fichiers.
1.4 Identification des données traitées

L'objectif de la Toolbox est de traiter les données de plusieurs fichiers en extrayant des
informations pertinentes, puis de réaliser une analyse basée sur ces informations. Parmi ces fichiers
VarDivMgtSCAN ,VarDivMgt,Messagerie CAN .
1.4.1 Messagerie CAN :

La messagerie CAN est un fichier Excel qui regroupe les spécifications des trames et des
signaux. Ce fichier est composé de deux feuilles, l'une pour les trames et l'autre pour les signaux. Il est
important de noter que chaque trame de données contient au moins un signal dans son champ de
données.
1.4.1.1 Les types de messagerie CAN :
Il existe trois types de messageries CAN comme illustre la figure 21 .
• Messagerie générique :
La messagerie en question est la messagerie de base qui englobe toutes les trames et signaux
de l'ensemble du réseau du véhicule provenant de divers calculateurs.
• Messagerie enveloppe :
Au sein de cette messagerie, on trouve l'ensemble des trames et signaux relatifs à un calculateur
spécifique du véhicule.
• Messagerie applicative
Messagerie précis qui contient les trames d'un seul calculateur et un seul projet .
31
Figure 21:Les types de messageries
1.4.1.2 Exemple de messagerie

Prenons l'exemple de la messagerie enveloppe du calculateur CMM, en effet c’est l'un des
entrées de l'outil que nous allons développer. Le traitement de cette messagerie se fait en se basant sur
la deuxième ligne des deux feuilles ‘FRAMES’ et ‘SIGNALS’, car cette ligne respecte la norme en
ce qui concerne la nomination de toutes les colonnes.
La messagerie CAN est composée de 63 colonnes qui décrivent les spécifications des trames
et signaux. Dans notre cas, nous ne nous intéresserons qu'aux colonnes qui sont pertinentes pour notre
besoin, en fournissant uniquement les significations associées à ces colonnes spécifiques.
A. Feuille1 : FRAMES
La première feuille dans la messagerie CAN est nommée ‘FRAMES’ , et les colonnes de
cette feuille contiennent les spécifications des trames comme l'illustre la figure 22 .
a. Des colonnes dans la feuille 'Frames’
32
Figure 22:Colonnes depuis la feuille FRAMES de la messagerie CAN
b. Description des colonnes dans la feuille 'Frames’

Dans ce qui suit on présente la signification de quelques colonnes de la feuille ‘FRAMES’ dans
le fichier Excel la messagerie CAN. [5]
− Appl_FrameObjRequirement : Référence de l’exigence applicative associée à une
trame et une seule spécifiée sur la totalité d’une ligne dans l’onglet « FRAMES ».
− Frame_Radical : Nom de substitution associé à chacune des trames. A pour vocation
de remplacer le nom de la trame.
− Frame_Enabiling_flag : le flux d’activation d’une trame c’est l’évènement qui
déclenche la transmission d’une trame. Il doit que ce flux prend l’état logique 1 pour
que la trame se transmette.
− Net_Protocol : cette colonne indique le protocole de communication utilisée dans la
transmission et la réception d’une trame.
− Frame_TransmitterECU : cette colonne indique l’émetteur de la trame.
− Frame_ReceiverECU : cette colonne indique le récepteur de la trame.
− Gateway_Frame : Les cases de ces colonnes peuvent prendre 3 valeurs :
− Gateway : le cas où le calculateur représente une passerelle pour la trame en envoyant
la trame a un autre calculateur et ne consomme pas l’information.
33
− Gateway+Consumed : le cas où le calculateur représente une passerelle de la trame en

envoyant la trame a un autre calculateur et en même temps consomme une partie de
l’information.
− No Gateway : le cas où le calculateur consomme l’information tout entier et n’est pas
une passerelle pour un autre calculateur.
B. Feuille2 : SIGNALS
La deuxième feuille de la messagerie CAN est nommée ‘SIGNALS’ ,en fait les colonnes de cette
feuille contiennent t les spécifications des signaux comme l'illustre la figure 23.
a. Des colonnes dans la feuille ‘SIGNALS’
34
Figure 23:Colonnes depuis la feuille SIGNALS de la messagerie CAN
b. Description des colonnes dans la feuille ‘SIGNALS’

Dans ce qui suit ,on va présenter la signification des spécifications des signaux .[5]
− Appl_SignalObj_Requirement : Référence de l’exigence applicative associée à un
paramètre et un seul spécifié sur la totalité d’une ligne dans l’onglet « SIGNALS » de
la messagerie CAN.
− Frame_Radical : Nom de substitution associé à chacune des trames. A pour vocation
de remplacer le mnémonique trame associée à ce signal.
− Signal_Mnemonique : Acronyme associé à chacun des paramètres.
− Signal_Transmitter_ECU : Cette colonne indique le transmetteur du signal.
− Signal_Receiver_ECU : Cette colonne indique le récepteur du signal.
− Gateway :Les cases de cette colonne peuvent prendre 3 valeurs.
• Gatewalpoy : le cas où le calculateur représente une passerelle pour le signal en
envoyant ce signal à un autre calculateur et ne consomme pas l’information.
• Gateway+Consumed : le cas où le calculateur représente une passerelle du
signal en envoyant ce signal à un autre calculateur et en même temps
consomme une partie de l’information.
• No Gateway : le cas où le calculateur consomme l’information tout entier et
n’est pas une passerelle pour un autre calculateur.
35
− Signal_Enabiling_flag : Flux d’activation d’un signal, l’évènement qui déclenche la

transmission d’un signal. Ce flux d’activations doit prendre le 1 logique pour que le
signal se transmette .
− Signal_Stubbed_Mnémonique : Cette colonne prend une valeur soit 0,1,2 ou
n’importe quelle valeur fixe pour les signaux qui ont une valeur figée et une valeur ‘Not
Applicable ‘pour les autres signaux .
1.4.2 Modèle VarDivMgt :
Le VarDivMgt (Management Variant Diversity) est un modèle Simulink qui vise à gérer la
diversité des options dans les véhicules en déterminant l'état des flux d'activations des fonctions dans
les véhicules .
1.4.2.1 Principe du VarDivMgt :
Le modèle VarDivMgt prend en entrée les flux de configurations et les calibrations fournis
par l'équipe calibration, puis génère en sortie les flux d'activation correspondants pour chaque fonction
dans le véhicule. Les flux de configurations et les calibrations permettent de déterminer les états
logiques des différents flux d'activation, et le modèle VarDivMgt effectue les calculs nécessaires pour
produire les flux d'activation finaux comme l'illustre la figure 24.
Figure 24:Les entrées et les sorties du VarDivMgt
En utilisant le VarDivMgt, un seul software peut être applicable à différents types de

véhicules, tels qu'une voiture essence ou diesel, quelle que soit la boîte de vitesses utilisée (manuelle
ou automatique), et d'autres variations possibles, la différence résidant dans l'état logique des flux
d'activation fonctionnels qui détermine l'activation ou la désactivation d'une fonction spécifique pour
chaque véhicule comme l'illustre la figure 25. L'état logique de chaque flux d'activation est défini dans
le VarDivMgt.
36
Figure 25:Principe du VarDivMgt
Effectivement, si le flux d'activation d'une fonction, par exemple CAN, est défini comme 1
logique, cela signifie que ce véhicule bénéficiera de cette option. En revanche, si le flux d'activation
est désactivé (0 logique), toutes les trames de la fonction CAN ne seront ni envoyées ni reçues.
Figure 26:Exemple d’activation et désactivation de la fonction CAN
La flexibilité du VarDivMgt réside dans sa capacité à gérer la diversité des options et des
fonctionnalités en ajustant simplement les états des flux d'activation, permettant ainsi de couvrir
différents scénarios et configurations de véhicules sans avoir à développer des logiciels distincts pour
chaque cas. Cela permet de réduire les coûts et les efforts de développement, tout en simplifiant la
gestion et la maintenance des logiciels pour l'entreprise.
Il est important de noter que notre outil intègre le modèle VarDivMgt. Dans les anciens projets
,ce modèle permet de présenter les flux d'activations avec une classification, en distinguant les trames
et signaux émis ou reçus, ainsi que le protocole de communication utilisé, tels que le CAN HS ou le
CAN FD. Cependant, dans les nouveaux projets, il peut également être possible que le modèle présente
les flux sans aucune classification spécifique.
37
A titre de l’illustration , nous allons présenter deux projets distincts. Le premier est parmi les
nouveaux projets indiqués dans la figures 27 et le deuxième est un exemple des anciens projets figure
28 .
Figure 27 :Modèle VarDivMgt dans un projet avec classification .
38
Figure 28 :Le modèle VarDivMgt dans un projet sans classification.
1.4.2.2 Calibration et flux de configuration :

La calibration fait référence au processus d’ajustement et de réglage des paramètres
électroniques d’un système embarqué dans un véhicule. Cela concerne principalement les calculateurs
et les modules de contrôle qui régulent et contrôlent différentes fonctions du véhicule, telles que le
moteur, la transmission, le système de freinage, l’ABS, l’ESP, etc.
La calibration vise à optimiser les performances et les caractéristiques de ces systèmes en
ajustant les paramètres tels que le temps d’injection du carburant, les courbes d’allumage, les seuils de
détection des capteurs, les limites de fonctionnement, etc. Ces ajustements sont effectués pour
répondre aux spécifications et aux exigences particulières du constructeur automobile, en tenant
compte des conditions de conduite, des normes d’émissions, de la durabilité et des performances du
véhicule.
La différence entre les flux de configuration et les calibrations que celle-ci est un fichier qui
se prépare en interne de l’entreprise précisément dans l’équipe synthèse calibration par contre les flux
39
de configuration peuvent être mises par n’importe quelle personne en utilisant un logiciel après-vente
et en reliant le pc a un port de calculateur dont on a besoin de modifier les flux d’activation.
1.4.3 VarDivMgtSCAN :
Un fichier Excel est utilisé pour stocker les flux d'activation, qui ont tous une valeur fixe de 1.
Ces flux ne sont pas intégrés dans le modèle VarDivMgt afin de prévenir tout ralentissement lors de
l'étape de codage. En séparant ces flux d'activation dans un fichier externe, le processus de
développement reste fluide et le modèle VarDivMgt conserve sa performance optimale.
2 Architecture globale
Avant de commencer la réalisation de cet outil , il est nécessaire de concevoir une architecture
globale qui englobe les différents composants qui interagiront entre eux pour atteindre l'objectif du
projet. Cette architecture permet d'avoir une vue d'ensemble de l'outil que nous souhaitons créer en
résumant la logique du programme.
Dans la figure 29 s’illustre l’architecture globale de notre programme :
Figure 29:Architecture global de l’outil
La Toolbox est basée sur un programme appelé "Extraction des incohérences des flux
d'activations", qui est chargé de générer un rapport contenant les incohérences des flux d'activations
entre la messagerie CAN et le modèle VarDivMgt, ainsi que le fichier Excel VarDivMgtSCAN.
3 Réalisation et test
3.1 Développement des scripts
La réalisation du projet a commencé par le développement du code .On a opté pour une
programmation modulaire qui consiste à subdiviser un programme informatique en sous-programmes
séparés. Cette programmation assure que le code soit court, simple et facile à comprendre ainsi que
40
les erreurs peuvent être facilement identifiées, car elles sont localisées dans un sous-programme ou
une fonction.
Le code se décompose de plusieurs scripts Matlab, ce script destinés d’exécuter les tâches
définies dans le cahier de charges, sans oublier qu’il y’a des scripts pour réunir le tout et qui
contiennent aussi l’ interfaces graphique.
Lors de développement de notre outil, nous avons cherché à le rendre adaptable en fonction
des besoins spécifiques de chaque projet. L'objectif est de pouvoir extraire les flux d'activation à partir
du modèle VarDivMgt, indépendamment de la nature de ce modèle.
Ainsi, notre outil offre la flexibilité de présenter les flux d'activation avec une classification si
cela est nécessaire, en identifiant les trames et signaux émis ou reçus et en les classant selon le
protocole de communication utilisé, comme le CAN HS ou le CAN FD. D'autre part, si une
classification n'est pas requise, notre outil est également capable de présenter les flux d'activation sans
classification spécifique, fournissant ainsi une vue plus générale des activités.
D'autre part, l'outil sera capable d'effectuer le traitement demandé sur les projets qui possèdent
le fichier VarDivMgtSCAN, ainsi que sur ceux qui ne le possèdent pas.
L'objectif est de répondre aux besoins particuliers de chaque projet et d'offrir une utilisation
personnalisée de l'outil.
3.1.1 Organigrammes d’exécution du code
Pour bien comprendre comment fonctionne les scripts de notre application, on a conçu des
organigrammes pour chaque partie du code qui schématisent les étapes principales de ces scripts.
➔ Organigramme du script Classification Signal :
41
Figure 30:Organigramme du script Classification Signal
Le script "Classification Signal" utilise une fonction Matlab pour lire la feuille "SIGNALS"
d'un fichier Excel contenant des données de messagerie CAN. Cette fonction convertit la feuille en
une table, ce qui facilite le traitement ultérieur.
À partir de cette table, le script extrait quatre sous-tableaux distincts :
− Une table contenant les signaux émis par notre calculateur utilisant le protocole CAN HS.
− Une table contenant les signaux émis par notre calculateur utilisant le protocole CAN FD.
− Une table contenant les signaux reçus par notre calculateur utilisant le protocole CAN FD.
− Une table contenant les signaux reçus par notre calculateur utilisant le protocole CAN HS.
42
Cela permet de classifier les signaux en fonction de leur émetteur (notre calculateur) et du
protocole de communication utilisé (CAN HS ou CAN FD).
Ensuite ,à partir de chaque table , on extrait les colonnes relatives au radicaux des trames, les
mnémoniques des signaux ainsi que les flux d’activations des signaux . A partir de ces colonnes
extraites on crée quatre feuilles Excel nommées comme suit :TX_FD,TX_HS,RX_FD,RX_HS.
➔ Organigramme de script Classification Trame :
43
44
Figure 31:Organigramme de script Classification Trame
Le script "Classification Trame" utilise une fonction Matlab pour lire la feuille "FRAMES"
d'un fichier Excel (messagerie CAN). Cette fonction convertit la feuille en une table, ce qui facilite
le traitement ultérieur.
À partir de cette table, le script extrait quatre sous-tableaux distincts :
− Une table contenant les trames émis par notre calculateur utilisant le protocole CAN HS.
− Une table contenant les trames émis par notre calculateur utilisant le protocole CAN FD.
− Une table contenant les trames reçus par notre calculateur utilisant le protocole CAN FD.
− Une table contenant les trames reçus par notre calculateur utilisant le protocole CAN HS.
Cela permet de classifier les trames en fonction de leur émetteur (notre calculateur) et du
protocole de communication utilisé (CAN HS ou CAN FD).
Ensuite ,à partir de chaque table , on extrait les colonnes relatives au radicaux des trames ainsi
que les flux d’activations des trames . A partir de ces colonnes extraite on crée 4 feuilles Excel nommé
comme suit :TX_FD,TX_HS,RX_FD,RX_HS.
Organigramme Extraction_flux_avec_Classification :
45
Figure 32:Organigramme du programme extraction_flux_avec_Classification
Le script " Extraction_flux_avec_Classification " commence par lire la feuille "FRAMES"

du fichier Excel (messagerie CAN ). Ensuite, il extrait les colonnes relatives aux protocole de
46
communication, radical de la trame, l'émetteur de la trame ainsi que la colonne des flux d’activations
des trames et la colonne "Gateway frame".
Ensuite il extrait les trames dont le calculateur n’est pas Gateway de la trame ,enfin le script
fait l’appel au processus « Classification Trame ».
Le script " Extraction_flux_avec_Classification " effectue un traitement similaire pour la
feuille "SIGNALS" du fichier. La principale différence réside dans les colonnes extraites, qui sont
spécifiques aux signaux.
Ensuite, le script lit la feuille "SIGNALS" et extrait les colonnes relatives aux protocole de
communication ,l'émetteur du signal ,le radical de trame associe à chaque signal et le mnémonique
signal ,ainsi que la colonne « stubbed signal value », enfin la colonne liée aux flux d’activations des
signaux .
Enfin il extrait les signaux dont le calculateur n’est pas Gateway du signal et qui n’ont pas une
valeur figée ,enfin il fait l’appel au processus « Classification Signal ». et rejoint les feuilles qui
résultes depuis les deux processus " Extraction_flux_avec_Classification "et « Classification
Signal » , respectivement dans des fichiers Excel sous le noms ‘Trames’ et ‘Signals’.
➔ Organigramme Extraction_flux_sans_classification :
47
Figure 33:Organigramme du programme ‘Extraction_flux_sans_classification'
Le script "Extraction_flux_sans_classification" effectue les opérations suivantes :
48
I. Traitement sur la feuille ‘FRAMES’ :

− Lecture de la feuille "FRAMES" du fichier Excel messagerie CAN .
− Extraction des trames qui ne sont pas des trames Gateway.

− Stockage de ces trame dans une nouvelle table.
À partir de cette table contenant ces trames, le script effectue les étapes suivantes :
− Extraction de la colonne des flux d'activation.
− Extraction du radical de chaque trame.
− Création d'un fichier Excel nommé "trames" à partir de cette table.
II. Traitement sur la feuille ‘SIGNALS’.
− Lecture de la feuille "SIGNALS" du fichier messagerie CAN .
− Extraction des signaux dont le calculateur n’est pas Gateway.
− Extraction des signaux qui n’ont pas une valeur figée .
− L’intersection entre les signaux qui ne sont pas Gateway et les signaux qui n’ont pas une
valeur figée.
− Stockage de ces signaux dans une nouvelle table.
À partir de cette table contenant les trames sélectionnées, le script effectue les étapes
suivantes :
− Extraction de la colonne des flux d'activation.
− Extraction de la colonne qui indique le mnémonique de chaque signal .
− Extraction de la colonne qui indique radical de chaque trame.
− Création d'un fichier Excel nommé "Signals" à partir de cette table.
➔ Organigramme Comparaison :
49
50
Figure 34:Organigramme du programme 'Comparaison'
Le script "Comparaison" effectue une classification des flux d'activation en deux groupes
distincts : ceux qui contiennent le mot "bAcv" sont considérés comme des flux d'activation pour des
signaux, tandis que ceux qui ne contiennent pas ce mot sont considérés comme des flux d'activation
pour des trames.
Dans la première partie du script, les flux d'activation pour des signaux sont comparés avec les
flux d'activation présents dans le fichier Excel "Signals" et ceux du fichier VarDivMgtSCAN. Cette
comparaison permet de détecter les incohérences entre les flux d'activation des signaux et ceux du
VarDivMgt et VarDivMgtSCAN. En cas d'incohérence, des codes d'erreur significatifs sont attribués
pour faciliter la correction ultérieure de ces incohérences.
Dans la deuxième partie du script, les flux d'activation pour des trames sont comparés avec les
flux d'activation présents dans le fichier Excel "trames" et ceux du fichier VarDivMgtSCAN. Cette
comparaison vise à détecter les incohérences entre les flux d'activation des trames et ceux du
VarDivMgt et VarDivMgtSCAN. De manière similaire, des codes d'erreur significatifs sont utilisés
pour identifier et faciliter la correction de ces incohérences.
➔ Organigramme du programme Extraction des incohérences des flux d'activations:
51
Figure 35:Organigramme du script 'Traitement final '
52
Ce script du ‘Extraction des incohérences des flux d'activations’ vérifie si le modèle

VarDivMgt présente les flux d’activation des signaux et de trames d’une manière classifié ou non.
Dans le cas d’un VarDivMgt présente les flux d’activation des signaux et de trames d’une
manière classifiée , il fait l’appel au processus Classification Trame et Classification Signal. Puis il
extrait les flux d’activation depuis les deux fichiers ‘Trames’ et ‘Signals’ qui sont générés par le
processus appelé , puis il extrait les flux d’activations depuis le VarDivMgtSCAN .Ensuite il ouvre
le modèle VarDivMgt et extrait les flux d’activations ,ensuite chaque classe de ces flux sera comparés
aux flux déjà extrait de la feuille associé dans les deux fichiers Trames et Signals.Enfin ,il associe les
tables générés par le processus Comparaison et les mets dans un fichier Excel nommé Rapport_check.
Dans le cas d’un VarDivMgt présente les flux d’activation des signaux et de trames d’une
manière non classifié , il fait l’appel au processus Extraction flux sans classification . Puis il extrait
les flux d’activation depuis les deux fichiers ‘Trames’ et ‘Signal’ qui sont générés par le processus
appelé, puis il extrait les flux d’activations depuis le VarDivMgtSCAN .Ensuite il ouvre le modèle
VarDivMgt et extrait les flux ,ces flux seront comparés aux flux déjà extrait des deux fichiers
‘Trames’ et ‘Signals’.Enfin ,il associe les tables générées par le processus comparaison et les mets
dans un fichier Excel nommé Rapport_check.
3.2 Développement d’ IHM

La dernière étape de la réalisation de cette partie du projet consiste à développer l'interface
homme-machine (IHM) en appelant les fonctions déjà développées dans un ordre spécifique afin
d'assurer le traitement souhaité. Les attentes des ingénieurs vis-à-vis de cette interface graphique sont
qu'elle soit claire, significative, concise et facilement compréhensible.
Nous allons maintenant explorer les différentes fenêtres de l'interface graphique réalisée, en
commençant par l'écran d'accueil.
3.2.1 Fenêtre de traitement nommé Tool
L'interface graphique figure 37, prend en entrée le fichier Simulink (modèle VarDivMgt), le
fichier Excel (Messagerie CAN) ainsi que le fichier Excel (VarDivMgtSCAN). Elle demande
ensuite à l'utilisateur de sélectionner l'emplacement où il souhaite enregistrer le rapport qui sera généré.
53
Figure 36:Fenêtre 'Tool' de l'outil CHECK FLOW'
Dans la fenêtre nommée "Tool", on trouve des boutons de type "check box". Le check box
nommé ‘classification’ permet d'indiquer si le modèle VarDivMgt du projet fournit les flux
d'activation en fonction d'une classification, indiquant s'il s'agit d'un flux d'émission ou de réception,
ainsi que le protocole de communication utilisé (CAN HS ou CAN FD).
Dans la fenêtre, il y a également trois boutons qui sont toujours visibles. Ces boutons permettent
de sélectionner les chemins d'accès respectifs pour les fichiers .slx et .xlsx, ainsi que l'emplacement
où le rapport généré sera enregistré et son nom.
Le check box nommé ‘Scan’ permet d'indiquer si le projet sur lequel nous souhaitons effectuer
le traitement dispose du fichier VarDivMgtSCAN. Si tel est le cas, cette case sera cochée, comme
illustre figure 37 sinon elle restera décochée. Si la case à cocher ‘Scan’ est activée, un autre bouton
sera affiché pour permettre à l'utilisateur de sélectionner le chemin d'accès pour le fichier
VarDivMgtSCAN comme illustre la figure 37.
54
Figure 37:La case a coché 'Scan file'
On lance le processus en cliquant sur le bouton ‘Check’ comme illustre la figure 39 , une fois
le traitement est terminé on peut trouver le rapport généré dans le chemin choisi .
Figure 38:Scénario d'un traitement bien fait
55
Si l'un des documents requis n'est pas renseigné et que le bouton ‘Check’ est appuyé, un
message d'erreur s'affiche pour indiquer qu'il est nécessaire de fournir les documents manquants. Cela
permet de rappeler à l'utilisateur l'importance de saisir tous les documents requis pour le bon
fonctionnement de l'outil comme Figure 40.
Figure 39:Scénario des données manquants
Si l'utilisateur souhaite interrompre le traitement en cours afin de saisir de nouvelles entrées, il

peut appuyer sur le bouton "Reset". Cela permettra de réinitialiser les paramètres et les données saisies,
offrant ainsi à l'utilisateur la possibilité de recommencer le processus avec de nouvelles entrées comme
illustre la figure 40.
56
Figure 40:Fonctionnalité d'initialisation des entrantes
3.2.2 La deuxième fenêtre de l’outil nommée Help

Cette interface graphique est conçue comme un guide d'utilisation pour les ingénieurs, leur
permettant de comprendre le fonctionnement de l'outil et la signification des différentes couleurs des
boutons, en cas de modification. Elle fournit également des consignes pour garantir le bon
fonctionnement de l'outil comme illustre la figure 41.
Cela aide les utilisateurs à naviguer facilement dans l'interface, à prendre connaissance des
fonctionnalités et à suivre les étapes nécessaires pour obtenir les résultats souhaités.
Au cas où , les ingénieurs envisagent des problèmes au cours de traitement des projets ,ils
peuvent consulter un document PDF mis dans le réseau de partage des documents de l’équipe Ecu
Designer .
Le lien pour accéder à ce fichier est mis dans la première ligne de la fenêtre ‘Help’.
57
Figure 41: Fenêtre 'Help'
3.3 Document généré par l’outil .

Le rapport généré est un fichier Excel qui se compose de deux colonnes nommée ‘code erreur’
et ‘Commentaire’.
3.3.1 Colonne commentaire
Figure 42:Colonne commentaire dans le rapport des incohérences
58
(1) La colonne commentaire pour indiquer le nom de flux non trouvé dans l’un des deux fichiers
que ce soit le modele VarDivMgt ou la Messagerie CAN .
3.3.1.1 Commentaire pour un flux d’activation détecté d’une trame
Dans le cas d'un flux d'activation d'une trame, le nom du flux sera associé au nom de la trame,
ainsi qu'à une description indiquant dans quel fichier l'incohérence se produit, c'est-à-dire si le flux est
absent dans le modèle VarDivMgt ou dans la Messagerie CAN. Cela permet d'identifier clairement
les incohérences et de localiser rapidement les flux manquants dans les différents fichiers.
La syntaxe du commentaire :
• Le flux d’activation ‘nom de flux’ de la trame ‘nom de la trame ‘est dans la
messagerie CAN et n’ont pas dans le VarDivMgt .
• Le flux d’activation ‘nom de flux’ est dans le modèle VarDivMgt est non pas dans
la messagerie CAN .
3.3.1.2 Commentaire pour un flux d’activation d’un signal
Dans le cas d'un flux d'activation d'un signal, le nom du flux sera associé au nom du signal et
le nom de la trame qui transmis ce signal , ainsi qu' une description indiquant dans quel fichier
l'incohérence se produit, c'est-à-dire si le flux est absent dans le modèle VarDivMgt ou dans la
messagerie CAN. Cela permet d'identifier clairement les incohérences et de localiser rapidement les
flux manquants dans les différents fichiers.
La syntaxe de commentaire :
• Le flux ‘nom de flux ‘ du signal ‘nom du signal’ de la trame ‘nom de la trame ‘ est
dans la messagerie CAN est n’ont pas dans le VarDivMgt .
• Le flux ‘nom de flux ‘ est dans le VarDivMgt est non pas dans la messagerie CAN
.
3.3.2 Colonne code d’erreur
Chaque code d'erreur est associé à un commentaire afin de permettre à l'utilisateur de filtrer les
incohérences identifiées en fonction de leur nature. Cela lui permettra de traiter chaque type
d'incohérence individuellement.
3.3.2.1 Code d’erreur pour un projet traité sans classification des flux
59
Figure 43:Colonne code d'erreur depuis le rapport généré
(1)La colonne "Code erreur" est dédiée à l'attribution d'un code spécifique à chaque
commentaire, permettant ainsi à l'ingénieur de traiter chaque type d'incohérence de manière
appropriée. Cette codification offre la possibilité d'identifier et de classer les différents problèmes ou
anomalies mentionnés dans les commentaires, facilitant ainsi le processus de résolution des problèmes.
On va prendre un exemple de code d’erreur afin de comprendre la logique de la composition
des codes d’erreur .On suppose que le code est AB.
La composition du code d’erreur est faite selon la réponse à ces questions :
• Le flux d’activation pour une trame ?
• Le flux d’activation pour un signal ?
• Le flux d’activation est présent dans le VarDivMgt et absent dans la messagerie CAN ?
• Le flux d’activation est présent dans la messagerie CAN et absent dans le VarDivMgt ?
Par contre les ingénieurs vont lire le code d'erreur dans le sens inverse , en utilisant le tableau
46 pour comprendre la signification du code .
60
Figure 44:Composition du code d'erreur pour un projet sans classification
On prend l’ exemple du code 22 :

Le code d’erreur 22 c’est pour les flux d’activation des signaux qui sont présents dans le
modèle VarDivMgt et absent dans la messagerie CAN .
3.3.2.2 Les codes d’erreur pour un projet si le traitement fait avec classification :
Dans la figure 46 se présente un extrait du rapport généré par l’outil ‘CHECK FLOW’ pour un projet
avec classification.
Figure 45:Extrait du rapport généré d’un projet avec classification
On peut filtrer les commentaires selon la natures de l’incohérence trouvée comme indiquée
dans la figure 47 .
61
Figure 46:Filtrage des commentaires selon la nature du code d'erreur .
On va prendre un exemple de composition d’un code d’erreur afin de comprendre la logique

de la composition des codes d’erreur .On suppose que le code est ABCD.
La composition du code d’erreur est faite selon la réponse de ces questions :
• Le flux d’action pour une trame ?
• Le flux d’activation pour un signal ?
• Le flux d’activation est présent dans le VarDivMgt et absent dans la messagerie CAN ?
• Le flux d’activation est présent dans la messagerie CAN et absent dans le VarDivMgt ?
• Le flux d’activation est pour une communication en émission ?
• Le flux d’activation est pour une communication en réception ?
• Le protocole de communication utilisé dans la communication est le CAN HS ?
• Le protocole de communication utilisé est le CAN FD ? Exemple de calibration
L’action fait selon les résultats de ces questions s’illustre dans les organigrammes dans l’annexe
2.
Par contre les ingénieurs vont lire le code d'erreur dans le sens inverse, en utilisant le tableau
ci-dessous :
62
Figure 47:Composition du code d'erreur d'un projet avec classification
On prend l’ exemple du code 1121 :

Il s’agit d’un flux d’activation d’une trame en émission , dans cette communication le protocole
de communication CAN HS est utilisé. Le flux d’activation est présent dans la messagerie CAN et
absent dans le VarDivMgt .
3.4 Validation de l’outil

La phase de validation d'un outil consiste à vérifier et confirmer que celui-ci répond aux
exigences et aux spécifications établies. Cette phase comprend plusieurs étapes, telles que :
➔ Planification de la validation :
On a déterminer des objectifs de validation spécifiques pour l'outil, tels que :
• La précision de la détection des incohérences,
• La vitesse de traitement.
➔ Préparation des données de test :
Nous avons regroupé des exemples de fichiers Simulink et Excel représentatifs, qui comprennent
différents cas de figures, afin de couvrir un large éventail de situations potentielles. En réalité, nous
avons testé sept projets, chacun d'eux comprenant un dossier composé d'une messagerie CAN et du
modèle VarDivMgt.
Parmi ces sept projets, quatre sont destinés au calculateur CMM et trois au calculateur EVCU.
Un projet en particulier contient le modèle VarDivMgt, qui présente les flux d'activations des trames
63
et des signaux avec classification. De plus, parmi ces sept projets, trois d'entre eux incluent le fichier
VarDivMgtSCAN.
➔ Conception des scénarios de test :

On a pensé à des scénarios de test qui simulent les interactions typiques entre le fichier Simulink
et le fichier Excel. Ces scénarios ont inclues des cas où des incohérences sont attendues, ainsi que des
cas où les deux fichiers sont cohérents.
➔ Exécution des tests :
On a appliqué les scénarios de test à l'outil développé , en fournissant le fichier Simulink et les
deux fichiers Excel en entrée. Ensuite on a enregistrer les résultats obtenus, y compris les incohérences
détectées et leur localisation dans le fichier Excel de sortie.
➔ Analyse des résultats :
Dans cette phase on a examiné les résultats des tests pour évaluer la précision de l'outil dans la
détection des incohérences entre les deux fichiers. Ensuite on a comparé les incohérences détectées
avec les attentes et on a vérifié si toutes les incohérences connues ont été identifiées.
➔ Correction des anomalies :
En cas ou des erreurs sont détectées dans l'outil on a d’essayé à effectuer les corrections
nécessaires au niveau du partie code qui semble l’origine de l’erreur. Ensuite on a répété les tests de
validation pour vérifier que les anomalies ont été résolues avec succès.
➔ Validation finale :
Une fois que l'outil a passé les tests de validation et que toutes les incohérences connues ont été
détectées avec précision on a effectué une validation finale pour s'assurer que l'outil est prêt à être
utilisé en production.
3.5 Mise à jour et documentation de la solution

3.5.1 Documentation
Afin de garantir le succès et la pérennité de la solution que nous avons développée, et dans le
but constant d'améliorer l'autonomie de l'équipe Ecu Designer ,nous avons préparé une documentation
qui se constitue d’un document format PDF . Cette documentation présente les différentes fenêtres de
l'interface graphique ainsi que les fonctionnalités disponibles. De plus, elle met en évidence les bonnes
pratiques à suivre pour garantir le bon traitement des projets, tout en soulignant les erreurs à éviter.
64
Conclusion :
Dans ce chapitre, on a passé sur les phases de réalisation de la Toolbox ‘CHECK FLOW ’,
en donnant les détails de chaque phase de cette Toolbox qui sera très utile pour les ingénieurs de
l’équipe Ecu Designer . Enfin, nous avons présenté la procédure adoptée pour la validation de l'outil
65
CONCLUSION ET PERSEPCTIVE
Pour limiter au maximum les erreurs au niveau de codage causés par les incohérences
entre les livrables de l’équipe ECU Designer , nous avons présenté dans ce rapport notre projet
de fin d’études, (effectué au sein de la société Emitech Engineering Africa ), les étapes
nécessaires pour réaliser un outil automatisé . Il s’agit d’une interface graphique dédiés aux
ingénieurs de l’équipe Ecu Designer qui prend en entrée trois fichiers :la messagerie CAN , le
modèle VarDivMgt et le VarDivMgtSCAN par la suite il extrait les flux d’activations depuis
ces fichiers et détecte les incohérences entre eux au niveau de flux d’activation en terme de
présence et génère en sortie un rapport Excel qui incluent des commentaires incluant les flux
non trouvées dans l’un des fichiers liés à un code d’erreur significative qui facilite la tâche aux
ingénieurs dans la phase du traitement des incohérences .
Notre travail est devisé en deux parties , une pour le développement des scripts Matlab
pour l’extraction des flux d’activations depuis les différents fichiers et pour la détection des
incohérences ainsi que la génération du rapport Excel qui inclut ces incohérences .L’autre est
consacré au développement de l’interface graphique .
Ce projet nous a permis également de découvrir et d’utiliser plusieurs outils
informatiques tels que : La programmation Matlab, le développement des interfaces
graphiques ainsi que d’acquérir des connaissances dans le domaine automobile et précisément
le métier de conception des calculateurs ,
Cependant, pour que cet outil soit plus utile , on va ajouter une autre fonctionnalité
telle que : La validation du modèle VarDivMgt sous Simulink d’une manière automatique en
développant un script pour lancer des scenarios de test .
Cette expérience vécue pendant ce stage au sein d’Emitech Engineering Africa était une
opportunité incontournable, elle m’a permis, d’une part, d’améliorer mes capacités techniques
et mes capacités d’analyse afin de résoudre les différents problèmes rencontrés. D’autre part,
cette expérience était très enrichissante et passionnante aussi bien sur le plan professionnel que
sur le plan personnel.
68
Bibliographies et Webographie
[1]About Emitech Engineering Africa (Document interne d’Emitech Engineering Africa).
[2]Calculateur moteur : fonctionnement, entretien et prix | Vroomly.
[3]Le multiplexage en automobile qu'est-ce c'est? (panne-automobile.com).
[4]MathWorks - Makers of MATLAB and Simulink - MATLAB & Simulink.
[5]Guide de lecture de la messagerie CAN (Document interne d’Emitech Engineering
Africa).
69
Annexes
Annexes de composition des codes d’erreurs .
Nous présentons dans ces organigrammes la compositions des différents codes d’erreur des
incohérences trouvés au niveau de flux d’activation en termes de présence .
➔ Annexe 1 : La composition des codes d’erreurs pour des projets sans classification :
70
➔ Annexe 2 : La composition des codes d’erreurs pour des projets avec classification :
71

Rapport Hadine Chaimae VFF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Hadine Chaimae VFF

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de Projet de Fin d’Études

En vue de l’obtention d’un diplôme d’ingénieur d’état en Génie électrique

Filière : Génie électrique systèmes embarqués et télécommunications

Réalisé au sein de "Emitech Engineering Africa"

Développement d’un outil de vérification des

Réalisé par : Encadré par :

Pr. Abdelhadi ENNAJIH : Président

Pr . Mohammed KHALDOUN : Rapporteur

Pr .Youssef MOUZOUNA : Encadrant pédagogique

Mr. Abdelkrim MOUBTAKIR : Encadrante industriel

Je dédie ce modeste travail avec tous mes sentiments de

patience, le courage et la force de mener fin ce projet de fin d’étude.

Je tiens à remercier la direction générale de Emitech Engineering Africa

expérience sociale et professionnelle.

Mes remerciements à Mr Abdelilah LAKHAL directeur d’exploitation

pour son accueil, ses conseils et ses remarques pertinentes.

Mes remerciements les plus sincères et mon estime s’adresse à mon

encadrant au sein de la société Mr Abdelkrim MOUBTAKIR ingénieure

le partage de son expertise au quotidien.

Merci à Mr Anas EL GHOUATE , responsable technique de l’équipe Ecu

à l’écoute et disponible pour me parrainer.

Youssef MOUZOUNA pour ses remarques et conseils, le corps professoral de

de Emitech Engineering Africa pour leurs gentillesses et leurs accueils chaleureux

durant toute la période de mon stage.

stage de fin d’étude au sein de la société Emitech Engineering Africa , particulièrement

modélisation de modèles VarDivMgt le VarDivMgtSCAN des calculateurs moteurs

CMM et EVCU dans les véhicules conventionnelles(essence, diesel) ,hybrides et

En bref, mon sujet de stage consiste à développer un outil pour l’automatisation

De vérifier la cohérence entre le modèle VarDivMgt , le VarDivMgtSCAN et la

conformes aux normes .

Mots-clés: Messagerie CAN ,VarDivMgt,CMM,EVCU,Flux d’activation,Trame,Signal.

in conventional (gasoline, diesel), hybrid and electric vehicles.

In short, my internship involves developing a tool to automate the verification of

CAN specifications for CMM and EVCU ECUs:

As well as detecting activation flow names modeled in a non-standard way.

Keywords: CAN Messaging,VarDivMgt,CMM,EVCU,Activation

LISTES DES FIGURES......................................................................................................................................... X

LISTES DES TABLEAUX ................................................................................................................................... XII

Table des abréviations ................................................................................................................................. XIII

Cahier de charges ......................................................................................................................................... XIV

Introduction générale ......................................................................................................................................1

Chapitre I : Contexte générale du projet. .........................................................................................................4

1 Présentation de l’organisme d’accueil ...................................................................................2

1.1 Groupe EMITECH....................................................................................................................2

1.2 Filiale du groupe EMITECH......................................................................................................2

1.3 EMC .......................................................................................................................................2

1.4 Présentation de l’organisme d’accueil « Emitech Engineering Africa » .....................................2

2 Problématique et cahier des charges.....................................................................................4

3.1 Matlab ...................................................................................................................................6

3.2 Simulink .................................................................................................................................6

3.3 App Designer .........................................................................................................................6

4 Méthodologie du travail : ......................................................................................................7

4.1 Techniques de gestion du projet .............................................................................................7

4.2 Charte du projet : ...................................................................................................................7

5 Planification du travail :.........................................................................................................8

Chapitre2 :Etat de l’art .....................................................................................................................................9

1 Contexte technique du projet..............................................................................................10

1.1 Généralités :......................................................................................................................... 10

1.1 Les calculateurs automobiles (ECUs) ..................................................................................... 10

1.2 Calculateur moteur (Engine Control Unit): ............................................................................ 12

1.3 Multiplexage ........................................................................................................................ 15

1.4 Le protocole de communication CAN .................................................................................... 18

Chapitre III : Conception et Réalisation de l’outil...........................................................................................29