1. MÉMOIRE DE PROJET DE FIN D’ÉTUDES
Présenté à
L’ÉCOLE NATIONALE DES SCIENCES APPLIQUÉES DE FES
En vue de l’obtention
Du Diplôme D’Ingénieur D’État
Spécialité : Génie des Systèmes Embarqués et Informatique Industrielle
Réalisé au sein de : Zodiac Aerospace Maroc
Logo de l
Réalisé par : Encadré par :
El Mehdi EL FAKIR M. Mohammed RAHMOUNI (ZAM)
Saad MOTAHHIR Pr. Mohammed OUDGHIRI (ENSAF)
Soutenu le : 23 Juin 2014
Devant le jury composé de :
Pr A. MECHAQRANE (Président)
Pr A. BEDOURI (Rapporteur)
Pr M. OUDGHIRI (Encadrant ENSAF)
M M. RAHMOUNI (Encadrant ZAM)
Année Universitaire : 2013 / 2014
Numérod`ordre:PFE-GSEII-014-0000datedesoutenance:23juin2014
Université Sidi Mohammed Ben Abdellah
École Nationale des Sciences Appliquées – Fès
Filière : Génie des Systèmes Embarqués et Informatique Industrielle
Titre du PFE
Conception et réalisation d’un logiciel embarqué pour la gestion et l’inertage du
système carburant de l’aéronef en utilisant le noyau temps réel µC/OS II. (Cible
MPC5566)

3. Rapport de stage PFE
El Mehdi El Fakir elmehdi@elfakir.me
Saad Motahhir saad.motahhir@gmail.com
30 juin 2014

7. D´edicace
A nos tr`es ch`eres m`eres,
sources de tendresse et d’amour, pour leur soutien tout au long de notre vie.
A nos tr`es chers p`eres,
Auxquels nous devons ce que nous sommes.
Que Dieu vous prot`ege.
A nos chers fr`eres et sœurs,
Pour leur amour et leur incontestable appui.
A toutes les personnes ch`eres `a nos cœurs. nous d´edions ce travail.
7

9. Remerciement
Nous exprimons toutes nos reconnaissances `a Monsieur Mohammed RAHMOUNI
Responsable de l’´equipe D´eveloppement Logiciel au sein de Zodiac Aerospace Maroc,
pour nous avoir accueilli au sein de son ´equipe pendant 4 mois et pour avoir cr´e´e les
conditions n´ecessaires `a l’adaptation et `a l’´evolution dans le cadre de nos travaux de
r´ealisation de notre projet de fin d’´etudes.
Nous remercions ´egalement tous les membres de l’´equipe d´eveloppement pour leur aide
permanente et le temps qu’ils nous ont consacr´e tout au long de la p´eriode de stage.
Nous tenons `a pr´esenter nos reconnaissances et nos remerciements `a notre professeur
encadrant M. Mohammed OUDGHIRI, pour ses conseils et ses orientations tout au
long de notre projet.
A l’issue de trois agr´eables ann´ees au sein de la fili`ere G´enie des Syst`emes Embarqu´es
et Informatique Industrielle `a l’ENSA de F`es, nous adressons des remerciements
particuliers `a M. Anass MANSOURI, responsable de la fili`ere, pour son dynamisme,
sa patience et pour la qualit´e de la formation consacr´ee `a cette fili`ere.
A nos famille et `a nos amis qui, de pr`es comme de loin nous ont aid´e et encourag´e
aux moments opportuns, Merci. . .
Enfin, nous avons une pens´ee ´emue `a nos parents pour leur soutien au cours de ces
longues ann´ees d’´etudes et sans lesquels nous ne serions pas l `a aujourd’hui.
9

11. R´esum´e
Mˆeme si les syst`emes de carburant ne sont pas les fonctionnalit´es les plus s´eduisantes
dans l’avion, mais ils restent les syst`emes les plus primordiaux et les plus critiques de
tout a´eronef.
La fiabilit´e, la robustesse, la performance et le niveau de sˆuret´e de ces syst`emes font
les caract´eristiques fondamentales pour le d´eveloppement des logiciels embarqu´es pour
l’a´eronautique.
La norme DO-178B fixe les conditions de s´ecurit´e applicables aux logiciels critiques de
l’avionique. Elle pr´ecise notamment les contraintes de d´eveloppement li´ees `a l’obtention
de la certification d’un logiciel d’avionique.
Le but de ce projet est de concevoir et de d´evelopper un logiciel embarqu´e pour le
contrˆole, la gestion et l’inertage du syst`eme carburant pour l’avion, en suivant le cycle
de d´eveloppement en V et en respectant les exigences de la norme DO-178B.
Ce logiciel est d´evelopp´e autour du noyau temps r´eel uC/OS II pour une architecture
micro-contrˆoleur de la famille MPC5566 de Freescale. La simulation du logiciel est
effectu´ee par une interface graphique d´evelopp´ee par C++ et Qt.
11

13. Abstract
Although fuel systems are not the most attractive features in the plane, but they
remain the most essential and critical systems of any aircraft.
Reliability, robustness, performance and safety level of these systems are the basic
features for the development of embedded software for aviation.
DO-178B sets out the conditions applicable safety for critical avionics software. It
specify particular development constraints associated with obtaining certification of
avionics software.
The purpose of this project is to design and develop embedded software for control,
management and fuel inerting system for aircraft, following the V model and meeting
the requirements of DO-178B.
This software is developed around the real time uC/OS II and for the microcontroller
MPC5566 from Freescale family. The simulation is performed by a graphical interface
developed with C++ and Qt.
13

15. .
.
. DO-178B
.
.DO-178B V
. MPC5566 uC/OS II
. Qt C++
15

17. TABLE DES MATI `ERES
D´edicace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Remerciement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
R´esum´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Table des mati `eres 17
Table des figures 20
Liste des tableaux 22
Liste des symboles 23
Introduction g´en´erale 25
1 Contexte g´en´eral du stage 27
1.1 Pr´esentation de Zodiac Aerospace . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.1.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.1.2 ´Equipements de cabine . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.1.3 Syst`emes embarqu´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.1.4 ´Equipements et syst`emes de s´ecurit´e . . . . . . . . . . . . . . . . . . . 29
1.1.5 Quelques chiffres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.1.6 Branches de Zodiac Aerospace . . . . . . . . . . . . . . . . . . . . . . 30
1.1.7 Pˆole Logiciel et FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.2 Pr´esentation de Zodiac Aerospace Maroc . . . . . . . . . . . . . . . . . . . . 31
1.2.1 Pˆole Logiciel & FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.3 Pr´esentation du cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . 33
1.3.1 Besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.3.2 Existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.3.3 Missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
17

18. 18
1.3.4 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.3.5 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2 ´Etat des connaissances 37
2.1 DO-178B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1.2 Application de la norme DO-178B . . . . . . . . . . . . . . . . . . . . 38
2.1.3 Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2 Le cycle de d´eveloppement en V . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 ´Etude technique du projet 43
3.1 Syst`eme de contrˆole du carburant . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.1 Le syst`eme et son concept . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.2 Exigences et contraintes techniques . . . . . . . . . . . . . . . . . . . 45
3.2 Syst`eme d’inertage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1 Le syst`eme et son concept . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2 Exigences et contraintes techniques . . . . . . . . . . . . . . . . . . . 53
4 Travaux r´ealis´es 63
4.1 Sp´ecification du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2 Conception logicielle haut niveau . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.1 Syst`eme de gestion et de contrˆole du carburant . . . . . . . . . . . . 65
4.2.2 Syst`eme d’inertage du carburant . . . . . . . . . . . . . . . . . . . . . 66
4.3 Conception logicielle bas niveau . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.1 Architecture statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.2 Architecture dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4 Unit´es fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.1 Nom et Pr´efixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.3 Niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.4 Les fichiers standards constituant une Unit´e Fonctionnelle . . . . . 70
4.4.5 Les ´etapes `a suivre pour r´ediger un Doc_FU . . . . . . . . . . . . . . 71
4.5 Exigences de bas niveau LLR . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.5.1 R´ediger un LLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.6 Pr´eparation de l’environnement du travail . . . . . . . . . . . . . . . . . . . . 74
4.6.1 Portage du uC/OS II sur MPC5566 . . . . . . . . . . . . . . . . . . . . 74
4.6.2 Composition d’un espace de d´eveloppement . . . . . . . . . . . . . . 75
4.6.3 D´efinition Unit´e Fonctionnelle (FU) . . . . . . . . . . . . . . . . . . . 76
4.7 Codage et g´en´eration d’elf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.7.1 Codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.7.2 G´en´eration de l’ex´ecutable ELF . . . . . . . . . . . . . . . . . . . . . . 77
4.8 Simulation sur Trace32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.9 Interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.9.1 Syst`eme de gestion et de contrˆole du carburant . . . . . . . . . . . . 80
4.9.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.9.3 Syst`eme d’inertage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Conclusion et Perspectives 84

19. 19
Annexes 87
A Outils utilis´es 87
1.1 Trace32 Lauterbach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
1.2 uC/OS II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
1.3 MPC5566 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B Bus de communication 92
2.1 Bus CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.1.1 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.1.2 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.1.3 Encodage des bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.1.4 Trames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2.1.5 Trame de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2.2 Bus ARINC 429 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2.2.2 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.2.3 Encodage des bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.2.4 Trame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

20. TABLE DES FIGURES
1.1 ´Equipements de cabine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.2 Syst`eme embarqu´e dans l’avion . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3 Implantation mondiale du group Zodiac . . . . . . . . . . . . . . . . . . . . . 29
1.4 ´Equipements con¸cus par Zodiac . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.5 Branches de groupe Zodiac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.6 Site de Technopolis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.7 Site de Tiflet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1 Phases du cycle de d´eveloppement en V . . . . . . . . . . . . . . . . . . . . . 42
3.1 Alimentation des moteurs et de l’APU . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Plan d’alimentation des moteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3 Diagramme du d´emarrage de l’APU . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4 Diagramme de s´equence d’alimentation . . . . . . . . . . . . . . . . . . . . . 48
3.5 Diagramme du Transfert de carburant de l’ext´erieur vers les r´eservoirs
internes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6 Diagramme d’all´egement de la charge d’aile . . . . . . . . . . . . . . . . . . . 49
3.7 Chargement et couplage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8 Diagramme du ravitaillement automatique des r´eservoirs . . . . . . . . . . 51
3.9 triangle du feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.10 sch´ema descriptif du syst`eme d’inertage . . . . . . . . . . . . . . . . . . . . . 53
3.11 Taux d’oxyg`ene sup´erieur `a 12% . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.14 s´eparateur d’air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.12 Taux d’oxyg`ene nul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.15 Construction du capteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.13 principe de fonctionnement en cas de sol et vol . . . . . . . . . . . . . . . . 56
3.16 Fonctionnement de la partie chauffage . . . . . . . . . . . . . . . . . . . . . . 57
3.17 Fonctionnement de partie refroidissement . . . . . . . . . . . . . . . . . . . . 57
3.18 Tension de Nernst en fonction de la pression d’oxyg`ene p2 dans la chambre 58
20

21. TABLE DES FIGURES 21
3.19 Fonctionnement de la pompe du courant . . . . . . . . . . . . . . . . . . . . 59
3.20 Sch´ema fonctionnel d’un traitement ´electronique . . . . . . . . . . . . . . . . 60
3.21 Sch´ema fonctionnel d’un traitement ´electronique . . . . . . . . . . . . . . . . 61
4.1 Page de garde du document SWRD . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2 Aper¸cu du syst`eme de contrˆole du carburant . . . . . . . . . . . . . . . . . . 65
4.3 Aper¸cu du syst`eme d’inertage . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4 Page de garde du document SWDD . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5 Architecture Statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.6 Architecture Dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.7 D´ependance et h´eritage des FU . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.8 Caract´eristique de la FU Probe . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.9 Cycle de fonctionnement de la FU Probe (capture du doc FU) . . . . . . . 72
4.10 Dictionnaire de donn´ees de la FU Probe . . . . . . . . . . . . . . . . . . . . . 73
4.11 Cycle de fonctionnement de la FU Probe . . . . . . . . . . . . . . . . . . . . 73
4.12 LLR de la foction probe_calcul_ppo2 . . . . . . . . . . . . . . . . . . . . . . . 74
4.13 Structure du uc/os ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.14 Espace de D´eveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.15 D´efinition Unit´e Fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.16 Concept de g´en´eration d’elf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.17 ´Etapes de g´en´eration de l’elf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.18 Simulation de la FU probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.19 L’interface graphique de contrˆole du carburant . . . . . . . . . . . . . . . . . 81
4.20 Fonctionnement de l’interface graphique de contrˆole du carburant . . . . . 81
4.21 L’interface graphique de l’inertage . . . . . . . . . . . . . . . . . . . . . . . . . 82
1.1 Emulateur de MPC5566, Lauterbach . . . . . . . . . . . . . . . . . . . . . . . 88
1.2 Le noyau uC/OS II de Micrium . . . . . . . . . . . . . . . . . . . . . . . . . . 89
1.3 Qorivva MPC5566 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
1.4 Architecture du MPC5566 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.1 Topologie du CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.2 Connexion des nœuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.3 Encodage en NRZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.4 Trame de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2.5 Topologie de l’ARINC 429 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.6 Encodage des bits de l’ARINC 429 . . . . . . . . . . . . . . . . . . . . . . . . 96
2.7 Trame de l’ARINC 429 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

22. LISTE DES TABLEAUX
2.1 Niveaux logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2 Activit´es logicielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
22

23. LISTE DES SYMBOLES
AC Courant Alternatif
APU Auxiliary Power Unit
ARINC Avionics Radio Incorporation
CAN Control Area Network
CG Centre de Gravit´e
DC Courant Continu
EASA European Aviation Safety Agency
ELF Executable and Linkable Format
ERD Equipment Requirement Document
FAA Federal Aviation Administration
FMCIS Fuel Management, Control and Inerting System
FPGA Field Programmable Gate Array
FU Functionnal Unit
GPIO General Propose Input Output
LLR Low Level Requirement
LP Low Pressure
MCLW Maximum Certified Landing Weight
SRD System Requirement Document
SWDD Software Design Document
SWRD Software Requirement Document
23

24. 24 LISTE DES SYMBOLES
uC/OS − II Micro-controller Operating System version II
ZAM Zodiac Aerospace Maroc

25. INTRODUCTION G ´EN ´ERALE
Les syst`emes embarqu´es suscitent un int´erˆet croissant dans l’industrie du fait des
enjeux consid´erables qu’ils repr´esentent par la capacit´e des progr`es technologiques,
par l’importance des march´es concern´es et par la n´ecessit´e d’expertises multi-m´etiers.
Ils traduisent un besoin de services ´elabor´es afin d’accroˆıtre l’efficacit´e des syst`emes
op´erationnels.
Dans l’a´eronautique, ces syst`emes embarqu´es font apparaˆıtre la n´ecessit´e d’une ana-
lyse sp´ecifique des syst`emes complexes critiques r´epondant `a des exigences de qualit´e et
de sˆuret´e de fonctionnement tr`es strictes, et propose des m´ethodes et outils de concep-
tion pour y parvenir.
L’accroissement rapide de l’utilisation des logiciels dans les syst`emes et ´equipements
de bord utilis´es sur les a´eronefs et les moteurs s’est traduit au d´ebut des ann´ees 1980
par un besoin de directives accept´ees par l’Industrie pour satisfaire les exigences de
navigabilit´e. Le document DO-178B "Etude et Homologation du Logiciel des Syst`emes
et Equipements de Bord" avait ´et´e r´edig´e pour r´epondre `a ce besoin.
Ce document, maintenant r´evis´e `a la lumi`ere de l’exp´erience, fournit `a la Com-
munaut´e A´eronautique des directives pour d´eterminer, de mani`ere coh´erente et avec
un degr´e acceptable de confiance, si les aspects relatifs aux logiciels des syst`emes et
´equipements de bord satisfont les exigences de navigabilit´e. La section DO-178B page
38 donne une pr´esentation de ce document.
Tous les logiciels temps r´eel embarqu´es dans les a´eronefs ont une caract´eristique
commune qui r´eside dans l’existence des contraintes temporelles dont il faut tenir
compte et pouvant entraˆıner des cons´equences graves si elles n’ont pas ´et´e respect´ees. Sur
ce point, l’informatique prend le dessus sur l’´electronique en rempla¸cant des syst`emes
mat´eriels par des solutions logicielles. Aujourd’hui, les syst`emes embarqu´es ont besoin
d’un composant logiciel essentiel permettant d’augmenter leur fiabilit´e et leur robustesse,
25

26. 26 INTRODUCTION G ´EN ´ERALE
ce composant est l’ordonnanceur temps r´eel.
Le noyau uC/OS II grˆace `a sa stabilit´e, malgr´e son jeune ˆage dans le monde em-
barqu´e, a montr´e sa puissance, et sa fiabilit´e pour le d´eveloppement des logiciels em-
barqu´es critiques. La section uC/OS II page 88 pr´esente les caract´eristiques de ce noyau.
Nous avons effectu´e notre stage au sein de la soci´et´e Zodiac Aerospace Maroc
`a Technopolis de Rabat, dans le cadre du projet de fin d’´etude pour l’obtention du
diplˆome d’ing´enieur d’´etat de l’ ´Ecole Nationale des Sciences Appliqu´ees de F`es, G´enie
des Syst`emes Embarqu´es et Informatique Industrielle.
Nous avons exerc´e la fonction stagiaire ing´enieur au sein de l’´equipe "D´evelop-
pement Logiciel Embarqu´e" durant quatre mois, nous avons travaill´e en ´equipe avec
deux autres stagiaires, et nous avions pour mission de concevoir et de d´evelopper un
logiciel embarqu´e autour du noyau temps r´eel uC/OS II et sur un microcontrˆoleur de la
famille MPC5566, pour la gestion, le contrˆole et l’inertage du carburant dans un avion,
en suivant le cycle de d´eveloppement en V et en respectant les exigences de la norme
DO-178B.
Le sujet de stage rentre dans nos perspectives `a venir, et il est la suite aux pr´ec´edentes
exp´eriences que nous avons eues dans le domaine des syst`emes embarqu´es. Il correspond
tout `a fait `a nos int´erˆets en termes de sp´ecialisation. En plus du sujet du stage, la di-
mension de Zodiac Aerospace qui est un leader mondial des ´equipements a´eronautiques
et des syst`emes avioniques sera sans doute un point marquant sur nos curriculum vitæ.
Ce rapport pr´esente la synth`ese du travail r´ealis´e durant notre stage, le but ´etant de
pr´esenter cette exp´erience de mani`ere `a ce que le lecteur ait une bonne compr´ehension
du sujet de stage et du travail r´ealis´e. Dans cette logique, ce rapport s’articule en quatre
chapitres. Dans une partie pr´eliminaire, le premier chapitre "Contexte g´en´eral du stage"
a pour but de pr´esenter l’organisme d’accueil, ainsi de pr´esenter le besoin auquel notre
cahier des charges r´epond, et ce pour la bonne compr´ehension de l’int´erˆet du projet.
Ensuite, dans le deuxi`eme chapitre " ´Etat des connaissances" nous pr´esentons les
diff´erents outils, technologies et m´ethodologies utilis´es pour la r´ealisation du projet.
Dans le troisi`eme chapitre " ´Etude technique du projet" nous expliquons en d´etail le
fonctionnement du syst`eme sur lequel nous avons travaill´e.
Dans le quatri`eme chapitre "Travaux r´ealis´es" qui est lui mˆeme fait en trois parties :
la premi`ere ´etant de pr´esenter la d´efinition et la conception du syst`eme de carburant, la
deuxi`eme partie consiste `a la conception du logiciel qui tourne dans le microcontrˆoleur
et qui r´epond aux exigences du syst`eme, et la troisi`eme partie qui pr´esente la phase du
codage et de la simulation en utilisant les outils de la soci´et´e.
Et `a la fin, nous faisons une conclusion g´en´erale sur le d´eroulement et les gains de
ce stage ainsi les perspectives du projet.

27. CHAPITRE
1
CONTEXTE G ´EN ´ERAL DU
STAGE
Ce chapitre est une description globale du Groupe Zodiac Aerospace [1], plus pr´ecis´ement
du d´epartement "Zodiac Security and Sensing Management" ; il donne une vue g´en´erale
de celle-ci en pr´esentant son historique, ses diff´erentes branches et ses activit´es princi-
pales ainsi le contexte g´en´erale du projet en citant les objectifs, la mission qui nous a
´et´e confi´ee pendant notre stage ainsi que la m´ethodologie du travail suivie.
27

28. 28 1.1. PR ´ESENTATION DE ZODIAC AEROSPACE
1.1 Pr´esentation de Zodiac Aerospace
Zodiac Aerospace est un acteur mondial principal dans l’industrie a´eronautique.
´Etant la plus ancienne entreprise a´eronautique (cr´e´ee en 1896), Zodiac Aerospace em-
ploie actuellement plus que 30.000 personnes et s’installe sur 98 sites `a travers le
monde.
1.1.1 Historique
Cr´e´ee en 1896 pour le d´eveloppement des ballons dirigeables et des a´eroplanes, Zo-
diac Aerospace est la plus ancienne soci´et´e a´eronautique au monde. Dans les ann´ees
1930, c’est l’invention du concept du bateau pneumatique qui permet `a la soci´et´e de
prendre son essor et qui impose l’image de marque du groupe apr`es la seconde guerre
mondiale.
Le groupe est aujourd’hui recentr´e sur l’a´eronautique, apr`es la cession de ses ac-
tivit´es marines en septembre 2007. Il est ´egalement aujourd’hui le leader mondial des
´equipements et syst`emes a´eronautiques. Avec une rigueur industrielle et de gestion, le
savoir-faire technologique de Zodiac est organis´e en trois m´etiers principaux :
1.1.2 ´Equipements de cabine
Con¸coit et commercialise des si`eges, des am´enagements de cabine et fournit des
´equipements sanitaires et alimentaires. Elle repr´esente la part la plus importante du
chiffre d’affaires de Zodiac Aerospace (1.829 Milliard d’euro sur l’exercice 2012/2013)
et compte parmi ses plus gros clients des acteurs du march´e commercial, r´egional et
des constructeurs d’avions d’affaires. Exemples : Si`eges, cabines compl`etes, syst`emes
sanitaires, chariots. . .
F 1.1: ´Equipements de cabine
1.1.3 Syst `emes embarqu´es
Couvre l’ensemble des ´equipements et syst`emes de haute technologie essentiels en
vol comme au sol. Ses innovations int´eressent les grands constructeurs internationaux
et militaires. Exemples : Distribution ´electrique, syst`eme carburant, contrˆoles, syst`eme
hydraulique. . .

29. CHAPITRE 1. CONTEXTE G ´EN ´ERAL DU STAGE 29
F 1.2: Syst`eme embarqu´e dans l’avion
1.1.4 ´Equipements et syst `emes de s´ecurit´e
Con¸coit et fabrique des produits et syst`emes complets d´edi´es au sauvetage et `a la
protection en vol. Ce segment intervient principalement sur le march´e militaire mais
´egalement sur les autres types de march´es : commercial, r´egional et les h´elicopt`eres.
Exemples : Toboggans, radeaux, syst`emes d’arrˆets d’urgence, protections de cˆablages,
parachutes, r´eservoirs, t´el´emesure, enregistreurs. . .
1.1.5 Quelques chiffres
F 1.3: Implantation mondiale du group Zodiac
Le groupe Zodiac est le 5e groupe a´eronautique fran¸cais et l’un des dix premiers
´equipementiers a´eronautiques mondiaux avec :
| Plus de 30000 employ´es dans le monde.
| 7000 en Europe dont 5500 en France.

30. 30 1.1. PR ´ESENTATION DE ZODIAC AEROSPACE
| 10000 en Am´erique du Nord.
| 9000 dans le reste du monde.
| 3.9 Milliard d’euros de chiffre d’affaires.
| 98 diff´erents sites dans le monde.
1.1.6 Branches de Zodiac Aerospace
Le groupe Zodiac Aerospace se compose de six branches dont on cite :
| Aerosafety and Technology : ´Equipements, produits et syst`emes d´edi´es au sauve-
tage et `a la protection.
| Aircraft System : ´Equipements et syst`emes de haute technologie au service des
fonctions essentielles tant en vol qu’au sol : Gestion de carburant, surveillance,
syst`emes oxyg`ene, syst`eme de gestion de puissance ´electrique.
| Seats : Fabrication et commercialisation des si`eges pour avions.
| Galleys : Production de cuisines embarqu´ees pour avions commerciaux.
| Cabin Interior : Am´enagement d’int´erieurs de cabine d’avions civiles.
| Zodiac Services : Maintenance et service apr`es vente.
F 1.4: ´Equipements con¸cus par Zodiac
1.1.6.1 Soci´et´es de la branche Aircraft Systems
La branche Aircraft System comporte plusieurs soci´et´es, comme la montre la figure
1.5. Parmi ces soci´et´es, on trouve l’entreprise ZAM (Zodiac Aerospace Maroc).
F 1.5: Branches de groupe Zodiac

31. CHAPITRE 1. CONTEXTE G ´EN ´ERAL DU STAGE 31
1.1.7 Pˆole Logiciel et FPGA
Le pˆole Logiciel & FPGA a d´evelopp´e une comp´etence dans le domaine des capteurs
de mesures et la gestion des syst`emes : jaugeage et syst`emes carburant, calculateurs de
surveillance et de contrˆole.
L’expertise de Zodiac Sensing & System Management s’applique `a des domaines vari´es :
| Syst`eme de jaugeage carburant, d´etection de niveau de carburant.
| Syst`eme de mesure de d´ebit carburant et syst`eme de carburant.
| Syst`eme de mesure de niveau d’huile.
| Syst`eme de conditionnement de l’air, r´egulation de temp´erature et r´egulation de
pression de l’air de la cabine.
| Gestion de Syst`emes (Calculateurs de Surveillance et de contrˆole).
| R´echauffage de pare brise.
| Chauffage de sondes an´emom´etriques.
| D´etection feu moteur et de fuite du pr´el`evement d’air.
| Syst`emes hydrauliques.
| Pr´el`evement d’air moteur.
| Distribution et r´eseaux ´electriques.
| D´etection de givre.
| Les interfaces homme-machine (indicateurs).
1.2 Pr´esentation de Zodiac Aerospace Maroc
Zodiac Aerospace Maroc regroupe deux sites :
F 1.6: Site de Technopolis
1. Site de Technopolis : C’est le site sp´ecialis´e en ing´enierie. Il comporte trois pla-
teaux :
| 2 plateaux r´eserv´es pour le Pˆole Logiciel et FPGA aux quels s’effectuent les
diff´erentes phases de test, v´erification, validation et de d´eveloppement.
| 1 plateau r´eserv´e pour le Pˆole Bureau d’´etudes sp´ecialis´e dans la conception
des pi`eces m´ecaniques ainsi que le routage des circuits imprim´es, qui sont

32. 32 1.2. PR ´ESENTATION DE ZODIAC AEROSPACE MAROC
de leur tour envoy´es pour la fabrication dans le site de production `a Tiflet.
2. Site de Tiflet : compos´e de deux ateliers :
| Firnas (Atelier ´electronique).
| Usinage (Production des pi`eces m´ecaniques).
F 1.7: Site de Tiflet
1.2.1 Pˆole Logiciel & FPGA
1.2.1.1 Activit´es
Les activit´es assur´ees par le pˆole logiciels et FPGA, se basent surtout sur les aspects
d´eveloppement, v´erification, validation et tests :
| D´eveloppement de logiciels embarqu´es : d´eveloppement en C sur micro-contrˆoleurs.
| D´eveloppement de logiciels outils : C# ,VB, C++, JAVA, PHP.
| V´erifications et tests de logiciels :
| V´erifications formelles.
| Tests unitaires.
| D´eveloppement de FPGA : conception, simulation, v´erification.
| Conception ´electronique : conception architecture, sch´emas. . .
1.2.1.2 ´Equipe Logiciel
Durant ce stage, nous avons ´et´e affect´es `a l’´equipe d´eveloppement logiciel dont ses
principales activit´es sont le d´eveloppement des logiciels embarqu´es pour les syst`emes
de gestion, de calcule et d’inertage du carburant, ainsi de d´evelopper des logiciels de
validation et de simulation pour le test des logiciels embarqu´es d´evelopp´es au sein de
cette ´equipe.

33. CHAPITRE 1. CONTEXTE G ´EN ´ERAL DU STAGE 33
1.3 Pr´esentation du cahier des charges
1.3.1 Besoin
Le travail d’un d´eveloppeur `a Zodiac Aerospace Maroc, commence `a partir des
sp´ecifications logicielles haut niveau et bas niveau, il a comme documents d’entr´ee
(la sp´ecification haut niveau "SWRD" et le document de conception "SWRD" - voir Le
cycle de d´eveloppement en V page 41) et les traduire par la suite en un ensemble de
programmes cod´es en langage C. Cependant, le d´eveloppeur reste toujours limit´e par les
parties du logiciel qui lui ont ´et´e attribu´e, sans avoir une vision globale sur le fonction-
nement du syst`eme sur lequel il travail, ce qui influence sur les d´elais de livraison vu
qu’il prend beaucoup de temps pour imaginer le syst`eme d’apr`es les exigences du logi-
ciel, ainsi, influence sur la correspondance entre le code d´evelopp´e et la fonctionnalit´e
demand´ee, puisque les exigences d´etaillent le fonctionnement du logiciel et non pas du
syst`eme.
1.3.2 Existant
Pour rem´edier `a ce probl`eme, le d´eveloppeur prend beaucoup du temps pour com-
prendre le principe de fonctionnement du syst`eme, en faisant des recherches sur d’autre
supports (Internet, des livres. . .) parce qu’il reste insuffisant de se baser seulement sur
les documents d’entr´ee fournis.
1.3.3 Missions
Pour r´esoudre ce probl`eme le travail demand´e pour notre stage est de r´ealiser un
logiciel embarqu´e g´en´erique pour les syst`emes du carburant, qui englobe presque tous
les syst`emes sur lesquels travail l’´equipe de d´eveloppement en fournissant une documen-
tation d´etaill´ee et compr´ehensible, `a partir de laquelle le d´eveloppeur pourra comprendre
facilement le principe de fonctionnement des syst`emes du carburant, en effet, notre pro-
jet englobe 3 syst`emes principaux :
| Syst`eme de contrˆole du carburant ;
| Mesure de quantit´e de carburant & Indication du niveau ;
| Syst`eme d’inertage.
Nous avons ´et´e amen´es `a travailler en ´equipe de quatre stagiaires sur ce projet, nous
avons travaill´e sur le Syst`eme de contrˆole du carburant et sur le Syst`eme d’inertage, le
syst`eme de Mesure de quantit´e de carburant & Indication du niveau a ´et´e affect´e pour
les autres stagiaires.
Le cahier des charges propos´e est de r´ealiser un syst`eme embarqu´e de gestion de
carburant en suivant la norme DO-178B et le cycle de d´eveloppement en V autour du
noyau uC/OS II et sur le micro-contrˆoleur powerPC MPC5566 .
Ce projet avait une dur´ee de quatre mois, `a compter du 3 f´evrier 2014, il de-
vait imp´erativement respecter les m´ethodologies de d´eveloppement adopt´ees au sein

34. 34 1.3. PR ´ESENTATION DU CAHIER DES CHARGES
de l’´equipe de d´eveloppement logiciel de Zodiac Aerospace.
1.3.4 Planification du projet
Comme indiqu´e sur l’intitul´e du projet, nous avons dˆu suivre le cycle de vie en V et
la norme DO-178B de ce fait la r´ealisation de ce projet devra suivre les phases suivantes :
| R´edaction de la Sp´ecification Syst`eme SRD (System Requirement Document).
| R´edaction des exigences logicielles haut niveau SWRD (SoftWare Requirment Do-
cument).
| R´edaction du document de conception logicielle SWDD (SoftWare Design Docu-
ment).
| R´edaction des Documents des Unit´es Fonctionnelles (FU Document).
| R´edaction des exigences logicielles bas niveau (Low Level Requiremnts).
| Codage et g´en´eration de l’ex´ecutable en utilisant le compilateur Diab.
| Simulation sur trace32 de Lauterbach.
| Simulation sur interface graphique r´ealis´ee par C++/Qt.
| ´Emulation sur le micro-contrˆoleur powerPC MPC5566.
1.3.5 Diagramme de GANTT

36. 36 1.3. PR ´ESENTATION DU CAHIER DES CHARGES
Conclusion Ce chapitre a pour objectif de donner une vision g´en´erale sur l’organi-
sation du groupe Zodiac Aerospace et plus pr´ecis´ement la branche Zodiac Aerospace
Maroc, ainsi, qu’un aper¸cu globale sur le cahier des charges de notre projet et la plani-
fication que nous avons ´etablie pour le d´eroulement de ce projet.

37. CHAPITRE
2´ETAT DES CONNAISSANCES
37

38. 38 2.1. DO-178B
2.1 DO-178B
La communaut´e a´eronautique a mis en place plusieurs documents de r´ef´erence, ces
documents sont utilis´es par les diff´erentes entit´es qui interviennent dans le d´eveloppement
d’un logiciel embarqu´e a´eronautique dont on cite :
| Autorit´es de certification et organisations gouvernementales (EASA, FAA,. . .) ;
| Avionneurs(le client) ;
| Syst´emiers et ´equipementiers (comme le cas de Zodiac Aerospace) ;
| Et aussi, industriels du logiciel, universitaires.
Le client fournit les sp´ecifications du syst`eme, suit le d´eveloppement chez l’´equipementier,
´eventuellement, m`ene des audits, et assure la communication avec les autorit´es de certi-
fication. Les autorit´es de certification m`enent des audits chez l’´equipementier et donnent
leur agr´ement pour l’utilisation du logiciel sur l’avion.
2.1.1 Historique
| 1980 : initiatives diverses en Europe et aux Etats-Unis ;
| 1982 : publication DO-178 / ED-12 : Certifications A310, A300/600, B757, B767. . .
| 1985 : publication DO-178A / ED-12A : Certifications A320, B737-300, B737-400,
et A340. . .
| 1993 : publication DO-178B / ED-12B ;
| 2012 : publication DO-178C / ED-12C
2.1.2 Application de la norme DO-178B
La DO-178B [2] est utilis´ee en a´eronautique civile et militaire, pour les logiciels
int´egr´es dans les syst`emes et ´equipements de bord. On peut cependant l’utiliser comme
r´ef´erence de certification pour des avions militaires.
2.1.3 Certification
D´efinition : C’est la reconnaissance l´egale, par l’autorit´e de certification, du fait qu’un
produit, un service, une organisation, ou une personne est conforme aux exigences. En
particulier, la certification d’un produit implique : le processus d’´evaluation de la concep-
tion d’un produit dans le but de garantir qu’il est conforme `a un ensemble de r`egles
applicables `a ce type de produit afin de d´emontrer un niveau acceptable de s´ecurit´e.
2.1.3.1 Conditions de d´efaillance
Sur l’´echelle de gravit´e, la norme DO-178B d´efinie les degr´es de d´efaillances suivants :
1. Catastrophique : Dans le cas o `u les conditions de panne sont susceptibles d’empˆecher
la poursuite en toute s´ecurit´e d’un vol et d’un atterrissage ;
2. Dangereuse : Les conditions de panne sont susceptibles de r´eduire les possibilit´es
de l’a´eronef ou la capacit´e de l’´equipage `a faire face `a des conditions hostiles
pouvant aller jusqu’ `a :
| une r´eduction importante des marges de s´ecurit´e ou des capacit´es fonction-
nelles ;

39. CHAPITRE 2. ´ETAT DES CONNAISSANCES 39
| des probl`emes physiques ou un accroissement de charge de travail tel que
l’´equipage ne soit plus en mesure d’accomplir sa tˆache de mani`ere pr´ecise ou
compl`ete ;
| des effets n´egatifs sur les occupants tels que des blessures graves ou poten-
tiellement mortelles pour un petit nombre d’entre eux.
3. Majeure : Conditions de panne d’une gravit´e se traduisant, par une r´eduction
significative des marges de s´ecurit´e, un accroissement significatif de la charge de
travail de l’´equipage ou des conditions affectant son efficacit´e, ou un inconfort
pour les occupants, comportant ´eventuellement des blessures ;
4. Mineure : Conditions de panne n’engendrant pas de r´eduction significative de
la s´ecurit´e de l’a´eronef, et susceptibles d’entraˆıner pour l’´equipage des actions se
situant tout `a fait dans le domaine de leurs capacit´es.
2.1.3.2 Niveaux logiciels
Les conditions de d´efaillance, et par cons´equent le niveau des logiciels, sont d´etermin´es
par l’analyse de s´ecurit´e syst`eme. Cette analyse est formalis´ee dans les documents sui-
vants :
| Preliminary System Safety Assessment (PSSA) ;
| System Safety Assessment (SSA).
Le niveau logiciel : est donc d´etermin´e en fonction de la contribution possible du
logiciel `a une condition de d´efaillance en cas de comportement erron´e :
T 2.1: Niveaux logiciels
Gravit´e Niveau logiciel
Catastrophique A
Dangereuse B
majeure C
Mineure D
Sans effet E
En fonction du niveau logiciel, les efforts portent sur la maˆıtrise du d´eveloppement,
la documentation et bien ´evidement la v´erification du produit. Et donc plus le niveau
du logiciel est ´elev´e, plus des pr´ecautions sont prises pour :
| ´Eviter les erreurs au cours du d´eveloppement (sp´ecification, design, codage) ;
| D´etecter et ´eliminer les erreurs au cours de tests (ex´ecution du code, totale ou
partielle) et de v´erifications (relectures, analyses,. . .).
2.1.3.3 Activit´es logicielles
La norme DO-178B d´efinit 9 processus ´el´ementaires qui sont :

40. 40 2.1. DO-178B
T 2.2: Activit´es logicielles
Planification P D´efinir les moyens de produire un logiciel sa-
tisfaisant les exigences syst`eme.
Fournir un niveau de confiance en rapport
avec le niveau de logiciel.
D´eveloppement R D´evelopper les exigences logicielles de haut
niveau.
D D´evelopper l’architecture du logiciel et ses
exigences bas niveau
C Coder le logiciel
I Int´egrer le code ex´ecutable dans son environ-
nement mat´eriel
Processus
int´egraux
V D´etecter les erreurs introduites pendant le
d´eveloppement du logiciel
Gdc Fournir une configuration contrˆol´ee du logi-
ciel pendant toute sa vie
AQ Evaluer les activit´es pour garantir que les
processus mis en place pour d´evelopper
v´erifier et g´erer le logiciel sont conformes
Coordination
pour la certifi-
cation
CC Entretenir les relations avec les autorit´es afin
de faciliter le processus de certification
L’objectif de la planification est de d´efinir les processus de d´eveloppement et les
processus int´egraux ainsi que le cycle de vie du logiciel, comprenant en particulier les
crit`eres de transition en plus de d´efinir les moyens et l’environnement de d´eveloppement
et ces r`egles afin d’´etablir les plans.
2.1.3.4 Cycle de vie
C’est l’ensemble ordonn´e des processus d´etermin´es par une organisation comme ´etant
suffisants et ad´equats pour r´ealiser un produit logiciel, d’autre part c’est la p´eriode de
temps qui commence avec la d´ecision de r´ealiser ou de modifier un produit logiciel et
qui s’ach`eve quand le produit est retir´e du service.
2.1.3.5 Crit `ere de transition
Ce sont les conditions minimales `a satisfaire, d´efinies lors de la planification du
logiciel, pour engager un processus. Des conditions qui portent sur les donn´ees d’entr´ee,
les activit´es des processus int´egraux n´ecessaires pour agir sur ces entr´ees, et les dispo-
nibilit´es des outils, m´ethodes, plans, proc´edures.
2.1.3.6 D´eveloppement
Le d´eveloppement logiciel peut ˆetre d´ecoup´e en plusieurs processus qui sont :
| Sp´ecification ;

41. CHAPITRE 2. ´ETAT DES CONNAISSANCES 41
| Conception ;
| Codage ;
| Int´egration.
Le logiciel est d´efini par des exigences. Ces exigences sont r´edig´ees sous forme
d’un fichier ERD (Equipment Requirement Document) ou d’un fichier SWRD (Software
Requirements Document) `a partir de la sp´ecification du syst`eme ou de la sp´ecification
client. Les exigences peuvent ˆetre :
| Des exigences de haut niveau obtenues `a partir de l’analyse de la sp´ecification
syst`eme.
| Des exigences de bas niveau obtenues `a partir des exigences de haut niveau, `a
partir desquelles le code source peut ˆetre d´evelopp´e.
Les exigences (haut niveau et bas niveau) peuvent ˆetre d´eriv´ees, autrement dit, des
exigences qui ne peuvent pas ˆetre trac´ees vers les exigences du niveau sup´erieur. Ces
exigences d´eriv´ees sont `a analyser au niveau syst`eme (s´ecurit´e).
2.1.3.7 Tra¸cabilit´e
C’est la preuve d’une association entre ´el´ements, entre produits de processus, entre un
produit et le processus dont il est issu, ou entre une exigence et sa mise en application.
La notion de tra¸cabilit´e couvre plusieurs aspects :
| Tra¸cabilit´e entre exigences ;
| Couverture de test ou de v´erification ;
| Tra¸cabilit´e entre exigence et code, et tra¸cabilit´e de modification.
2.1.3.8 Exigence d´eriv´ee
Exigences compl´ementaires r´esultant des processus de d´eveloppement du logiciel, qui
peuvent ne pas ˆetre directement tra¸cables vers des exigences de plus haut niveau.
| Une exigence est dite d´eriv´ee si elle correspond `a un ajout par le logiciel ;
| Tra¸cabilit´e des exigences : Une exigence est dite tra¸cable s’il est possible de la
rattacher directement `a une exigence issue du niveau sup´erieur ;
La tra¸cabilit´e des tests consiste `a ´etablir un lien entre une proc´edure de test et l’exigence
ou les exigences que ce test v´erifie.
Remarque: La tra¸cabilit´e est le point le plus examin´e lors des audits avec un client ou
avec les autorit´es de certification.
2.2 Le cycle de d´eveloppement en V
Le mod`ele du cycle en V ou Waterfall (en comparaison avec les m´ethodes dites
Agile) est un mod`ele conceptuel de gestion de projet imagin´e suite au probl`eme de
r´eactivit´e du mod`ele en cascade. Il permet, en cas d’anomalie, de limiter un retour aux
´etapes pr´ec´edentes. Les phases de la partie montante doivent renvoyer de l’information
sur les phases en vis- `a-vis lorsque des d´efauts sont d´etect´es, afin d’am´eliorer le logiciel.

42. 42 2.2. LE CYCLE DE D ´EVELOPPEMENT EN V
Le cycle en V est devenu un standard de l’industrie logicielle depuis les ann´ees 1980
et depuis l’apparition de l’ing´enierie des syst`emes est devenu un standard conceptuel
dans tous les domaines de l’industrie. Le monde du logiciel ayant de fait pris un peu
d’avance en termes de maturit´e, on trouvera dans la bibliographie courante souvent des
r´ef´erences au monde du logiciel qui pourront s’appliquer au syst`eme.
F 2.1: Phases du cycle de d´eveloppement en V
Les ´etapes de d´eveloppement en cycle en V sont :
| Analyse des besoins et faisabilit´e (cahier des charges)
| Sp´ecification fonctionnelle (SRD)
| Conception architecturale (SWRD + SWDD)
| Conception d´etaill´ee (FU + LLR)
| Codage
| Test unitaire
| Test d’int´egration
| Test Syst`eme : recette usine, validation usine
| Test d’acceptation : v´erification d’aptitude au bon fonctionnement
Une des diff´erences entre la recette usine et la recette finale est essentiellement
contractuelle. Aussi, il n’est pas rare que le maˆıtre d’ouvrage d´el`egue la validation aupr`es
d’un organisme de validation, cet organisme ´etant bien souvent constitu´e d’experts afin
de diminuer les erreurs de validation.

43. CHAPITRE
3´ETUDE TECHNIQUE DU
PROJET
43

44. 44 3.1. SYST `EME DE CONTR ˆOLE DU CARBURANT
3.1 Syst `eme de contrˆole du carburant
3.1.1 Le syst `eme et son concept
Le syst`eme contrˆole du carburant [3] a pour but de stocker la quantit´e n´ecessaire
de carburant dans les r´eservoirs afin de fournir une quantit´e constante de carburant
sous pression `a un ou plusieurs moteurs. Dans ce chapitre, on verra la description en
d´etail des sous-syst`emes principaux [4] (l’alimentation de l’APU et du moteur, S´equence
d’alimentation des moteurs, Transfert du carburant des r´eservoirs ext´erieurs vers les
r´eservoirs internes, All´egement de la charge d’aile, Transfert par gravit´e, Largage de
carburant, Un syst`eme de refroidissement Hydraulique, chargement et d´echargement du
carburant) du syst`eme contrˆole de carburant.
En g´en´eral, le syst`eme [5] de contrˆole du carburant comprend les sous-syst`emes sui-
vants :
| L’alimentation de l’APU et du moteur.
| S´equence d’alimentation des moteurs.
| Transfert du carburant des r´eservoirs ext´erieurs vers les r´eservoirs internes.
| All´egement de la charge d’aile.
| Transfert par gravit´e.
| Largage de carburant.
| Un syst`eme de refroidissement Hydraulique.
| Chargement et d´echarger du carburant.
F 3.1: Alimentation des moteurs et de l’APU

45. CHAPITRE 3. ´ETUDE TECHNIQUE DU PROJET 45
3.1.2 Exigences et contraintes techniques
3.1.2.1 Alimentation de l’APU et du moteur
Le syst`eme d’alimentation en carburant fournit du carburant sous pression pour les
moteurs et pour l’Unit´e de Puissance Auxiliaire (APU). La plupart des avions modernes
ont install´e les APU dont leur fonction principale est de fournir de l’´energie ´electrique
`a l’avion lorsque l’avion est au sol avec les moteurs principaux ferm´es.
F 3.2: Plan d’alimentation des moteurs
Dans certaines applications l’APU peut ˆetre n´ecessaire d’op´erer en vol pour fournir
une source de puissance ´electrique AC suppl´ementaire en cas d’un g´en´erateur entraˆın´e
par le moteur tombe en panne. L’APU est ´egalement une source d’air comprim´e qui
est utilis´e de fournir la climatisation de la cabine sur le terrain et pour entraˆıner une
turbine d’air (d´emarreur) qui lance le moteur pendant la s´equence de d´emarrage du
moteur.
En comparaison avec les moteurs de propulsion, l’APU est beaucoup plus petit et peut
ˆetre d´emarr´e par un d´emarreur de batterie. Pendant le d´emarrage de l’APU, le Syst`eme

46. 46 3.1. SYST `EME DE CONTR ˆOLE DU CARBURANT
d’alimentation en carburant utilise une pompe entraˆın´ee par un petit moteur DC au lieu
d’utiliser la batterie pour g´en´erer la pression de pompage.
F 3.3: Diagramme du d´emarrage de l’APU
Durant le vol, le syst`eme d’alimentation doit veiller `a ce que la pression du carbu-
rant circul´e aux moteurs est maintenue au-dessus de la pression de vapeur du carburant
(c’est `a dire au-dessus du point d’´ebullition du carburant) selon une marge pr´ed´efinie
pour toutes les combinaisons possibles de la temp´erature et des types du combustible
d’un avion.
Le syst`eme doit ´egalement s’assurer que la contamination du carburant avec l’air ou
l’eau ne d´epasse pas les limites fix´ees par le constructeur du moteur.
Le syst`eme de pompage du carburant principal fournit le carburant du r´eservoir central
ou du r´eservoir int´erieur de l’aile vers les moteurs. Le syst`eme dispose de six pompes
principales pour circuler le carburant aux moteurs, et une pompe pour alimenter l’APU.
En fonctionnement normal, chaque moteur est aliment´e par une pompe dans le r´eservoir
central ou deux pompes dans le r´eservoir d’aile de son propre cˆot´e.
Dans l’´eventualit´e d’une d´efaillance des pompes, chaque moteur est aliment´e automa-
tiquement par une pompe de secours. Toutes les pompes des r´eservoirs d’aile restent
allum´ees tout au long du vol.
Le robinet (vanne) d’intercommunication est contrˆol´e par un double moteur, permet-
tant aux deux engins d’ˆetre aliment´es `a partir d’un cˆot´e, ou `a l’un des engins d’ˆetre
aliment´e depuis les deux cˆot´es. La vanne d’intercommunication s’ouvre automatique-
ment dans la configuration d’urgence critique.
Le d´ebit du carburant pour un moteur peut ˆetre arrˆet´e par sa vanne de basse pression
(LP), la fermeture de la soupape (LP) de carburant est faite par :
| L’interrupteur principal du moteur.
| Le bouton ENG FIRE.
Ferm´e par pression des pompes en fonctionnement normal, les vannes d’aspiration

47. CHAPITRE 3. ´ETUDE TECHNIQUE DU PROJET 47
permettent aux moteurs d’ˆetre aliment´es par gravit´e si les pompes des r´eservoirs in-
ternes ´echouent. (NB : les pompes du r´eservoir central ne sont pas ´equip´ees de vannes
d’aspiration. En plus, l’alimentation par gravit´e n’est pas possible `a partir du r´eservoir
central).
Une pompe `a carburant op´erant par un moteur DC fournit le carburant du r´eservoir
central au d´emarrage de l’APU lorsque la pression d’alimentation en carburant est faible
(en raison de la perte des pompes de r´eservoir ou de la perte de l’alimentation ´electrique
AC normale). Cette pompe fonctionne normalement sur le bus AC ESS, mais change
vers le BUS AC STAT INV si le BUS AC ESS ´echoue.
3.1.2.2 S´equence d’alimentation en carburant
Un syst`eme de transfert de carburant est n´ecessaire dans les applications o `u plu-
sieurs r´eservoirs sont utilis´es pour le stockage de combustible pour faire en sorte que le
carburant est consomm´e `a partir de diff´erents r´eservoirs selon un plan pr´ed´etermin´e. Ce
plan (ou la s´equence de la consommation de carburant) prend en compte de nombreuses
consid´erations op´erationnelles, y compris :
| Variation CG d’a´eronef au cours de la consommation de carburant.
| All´egement de la charge d’aile.
| Les quantit´es minimales et maximales de l’alimentation du carburant.
| Maintenir l’´equilibre lat´eral de l’a´eronef automatiquement.
Le contrˆole du syst`eme de transfert du carburant peut ˆetre soit sous le contrˆole direct
de l’´equipage de conduite ou par un syst`eme de gestion de carburant automatis´e. Les
r´eservoirs vident dans la s´equence suivante [4] :
1. R´eservoir central (jusqu’ `a 550 kg).
2. R´eservoirs internes (jusqu’ `a 750 kg dans chaque r´eservoir interne).
3. R´eservoirs externes (carburant transf´er´e dans les r´eservoirs int´erieurs).
Lorsqu’un r´eservoir int´erieur est plein (retour du carburant du syst`eme de refroidis-
sement), la pompe du r´eservoir central associ´ee s’arrˆete, et laisse la main `a la pompe
int´erieure jusqu’ `a environ 500 kg de son carburant a ´et´e utilis´e, et puis continu l’ali-
mentation depuis le r´eservoir central.
3.1.2.3 Transfert de carburant de l’ext´erieur vers les r´eservoirs internes
| Les vannes de transfert s’ouvrent automatiquement lorsque le carburant int´erieur
du r´eservoir atteint le faible niveau (environ 750 kg), ce qui permet de vidanger le
carburant de l’ext´erieur vers r´eservoirs internes. Les vannes restent ouvertes tout
au long du vol. Elles se ferment automatiquement `a l’op´eration du ravitaillement
suivant (mode de s´election `a la position REFUEL).

48. 48 3.1. SYST `EME DE CONTR ˆOLE DU CARBURANT
F 3.4: Diagramme de s´equence d’alimentation
F 3.5: Diagramme du Transfert de carburant de l’ext´erieur vers les r´eservoirs in-
ternes
| Deux capteurs de niveau sont install´es dans chaque r´eservoir int´erieur. Chacun
contrˆole deux vannes de transfert, une dans chaque aile, assurant que le transfert
est simultan´e dans les deux ailes.

49. CHAPITRE 3. ´ETUDE TECHNIQUE DU PROJET 49
| La valeur de 750 kg est bas´ee sur le niveau moyen de l’avion sans acc´el´eration.
| Au cours de descentes raides ou acc´el´erations/d´ec´el´erations, les vannes de transfert
peuvent ouvrir avec plus de 750 kg de carburant dans chaque r´eservoir int´erieur
et l’avertissement de faible niveau peuvent ˆetre d´eclench´ees.
3.1.2.4 All´egement de la charge d’aile
Afin de minimiser les contraintes de flexion aile au cours du vol, le carburant est
transf´er´e des r´eservoirs int´erieurs aux r´eservoirs ext´erieurs imm´ediatement apr`es le
d´ecollage et les externe r´eservoirs restent g´en´eralement plein jusqu’ `a la fin de la phase
de croisi`ere.
F 3.6: Diagramme d’all´egement de la charge d’aile
3.1.2.5 Transfert par gravit´e
Le transfert de carburant depuis les r´eservoirs int´erieurs en pr´esence de panne d’une
pompe ou plus peut ˆetre effectu´e en utilisant la gravit´e. Ce transfert par gravit´e est
obtenu par l’ouverture de la vanne de transf´erer anti-retour situ´ee entre les fronti`eres
des r´eservoirs.
3.1.2.6 Largage de carburant
Les trains d’atterrissage et les structures de l’avion vont absorber l’impact de l’atter-
rissage jusqu’ `a un certain poids. Cet impact est appel´e la masse d’atterrissage maximale
certifi´e (MCLW). Un avion peut ˆetre trop lourd pour atterrir en toute s´ecurit´e sans ris-
quer un affaissement du train d’atterrissage ou autre d´efaillance structurale en pleine
charge alors Jeter du carburant (Largage du carburant) est un moyen sˆur de r´eduire le
poids n´ecessaire de l’avion afin d’assurer que l’avion peut faire un atterrissage d’urgence
juste apr`es son d´ecollage ou apr`es un court vol.

50. 50 3.1. SYST `EME DE CONTR ˆOLE DU CARBURANT
L’exigence de largage du carburant est obtenue par la diff´erence entre le maximum
du poids de d´epart et le maximum du poids d’atterrissage. Largage de carburant est
s´electionn´e par l’´equipage de conduite via des commutateurs de surveillance pour ar-
mer et s´electionner le syst`eme. L’´equipage peut s´electionner une charge de carburant
sp´ecifique `a laquelle la fonction largu´e est annul´ee. Sinon, le largage continue jusqu’ `a
ce que la masse `a l’atterrissage maximale soit atteinte. Les pompes de largage sont
situ´ees dans les r´eservoirs internes. Lorsque le largage du carburant est activ´e depuis
le cockpit, le syst`eme lib`ere des milliers de kilos de carburant par minute.
La plupart des syst`emes lib`erent le carburant `a un rythme suffisamment rapide que le
poids total de l’avion est r´eduit de masse maximale au d´ecollage de masse `a l’atterrissage
maximale certifi´ee (MCLW) en quinze minutes ou moins.
3.1.2.7 Ravitaillement - d´echargement du combustible
Deux points de ravitaillement (figure 3.7) sont install´es sous les ailes permettant le
ravitaillement soit du cˆot´e droit ou gauche de l’avion. Un panneau de ravitaillement
est situ´e sur le fuselage sous l’aile droite ou sous la droite ou la gauche `a cˆot´e de
l’accouplement de chargement.
Une galerie relie le raccord de ravitaillement en carburant `a la soupape de ravitaillement
en carburant de chaque r´eservoir. Le ravitaillement est normalement automatique, la
F 3.7: Chargement et couplage
charge de carburant n´ecessaire ´etant mise sur la pr´es´election. Le contrˆole manuel est
´egalement disponible.
| Ravitaillement automatique [6] commence par les cellules ext´erieures. Si la charge
de carburant s´electionn´e d´epasse la capacit´e du r´eservoir de l’aile, le r´eservoir
central est ravitaill´e en mˆeme temps. Quand une cellule ext´erieure est pleine, le
carburant d´eborde dans la cellule int´erieure par un tuyau de d´eversement. Lorsque
les r´eservoirs contiennent la quantit´e pr´es´electionn´ee `a charger ou lorsque les
capteurs d´etectent un niveau de carburant ´elev´e, les vannes de ravitaillement se
ferment automatiquement.
| L’avion peut ˆetre ravitaill´e seulement lorsque la puissance de la batterie est dis-
ponible.

51. CHAPITRE 3. ´ETUDE TECHNIQUE DU PROJET 51
F 3.8: Diagramme du ravitaillement automatique des r´eservoirs
| Les r´eservoirs d’aile peuvent ˆetre ravitaill´es en carburant par gravit´e `a travers les
points de ravitaillement sur le dessus des ailes. Une soupape de transfert entre le
syst`eme d’alimentation du moteur et la galerie de ravitaillement permet :
1. Aux pompes du r´eservoir de transf´erer le carburant d’un r´eservoir `a un autre.
2. d´echargement du combustible `a travers le couplage de ravitaillement.
| Temps de ravitaillement approximatif `a la pression nominale est :
1. 17 minutes pour les r´eservoirs d’aile.
2. 20 minutes pour tous les r´eservoirs.
3.2 Syst `eme d’inertage
3.2.1 Le syst `eme et son concept
L’inertage de mani`ere g´en´erale, c’est une technique utilis´ee dans l’industrie qui
consiste `a remplacer une atmosph`ere explosive ou chimiquement r´eactive, pr´esente par
exemple dans le ciel d’une citerne, par un gaz ou un m´elange gazeux non combustible

52. 52 3.2. SYST `EME D’INERTAGE
et non comburant.
Les conditions d’atmosph`ere explosive sont r´eunies si 3 ´el´ements du triangle du feu
sont en pr´esence : combustible, comburant (souvent l’oxyg`ene), et une source de chaleur
ou d’´energie (feu, ´etincelle ´electrique). L’inertage consiste `a r´eduire la pr´esence du com-
burant pour placer la concentration en gaz en dehors des limites d’explosivit´e (au-dessus
de la limite sup´erieure, ou en dessous de la limite inf´erieure). En effet le syst`eme que
F 3.9: triangle du feu
nous proposons est un syst`eme fiable et autonome pour prot´eger les r´eservoirs de car-
burant contre les risques d’incendie ou d’explosion, c’est un syst`eme autonome g´en´erant
de l’azote directement `a bord de l’avion pour prot´eger ses r´eservoirs de carburant contre
d’´eventuels risques d’explosion.
Bas´e sur un processus de s´eparation `a partir de fibres creuses en polym`ere, produit
pendant la mission le flux d’air enrichi en azote n´ecessaire `a la protection de l’avion.
Une partie de l’oxyg`ene contenu dans le r´eservoir est remplac´ee par de l’azote, rendant
ainsi les vapeurs ininflammables.
Ce syst`eme int`egre un processus de filtration, un contrˆoleur de pression et de temp´erature,
un capteur d’oxyg`ene et des modules de s´eparation de l’air.
L’air comprim´e est directement ponctionn´e sur un circuit d’air d’avion et transform´e en
NEA (air enrichi par l’azote) qui est distribu´e dans les r´eservoirs de carburant.

53. CHAPITRE 3. ´ETUDE TECHNIQUE DU PROJET 53
F 3.10: sch´ema descriptif du syst`eme d’inertage
3.2.2 Exigences et contraintes techniques
3.2.2.1 Exigences fonctionnelles
| Le gaz inerte le plus utilis´e est l’azote car chimiquement relativement neutre et
peu coˆuteux, qui pr´esente en outre l’avantage de pouvoir refroidir l’atmosph`ere ;
| Le syst`eme d’inertage sera appliqu´e sur le r´eservoir central ;
| Il faut assurer un taux d’oxyg`ene dans le r´eservoir de 12%.
| la concentration d’oxyg`ene `a la sortie de s´eparateur d’air doit ˆetre ´egale `a z´ero
sinon le s´eparateur d’air ne fonctionne pas correctement de ce fait on d´eclenche
une alarme.
| Le calculateur doit recevoir `a partir de syst`eme qui donne si l’avion en vol ou en
sol.
| si l’avion en vol les engins fournit l’air `a trait´e sinon (en sol) en d´eclenche le
ventilateur.
3.2.2.2 S´eparateur d’air
Utilis´e pour s´eparer l’azote (gaz inerte) parmi l’oxyg`ene, le dioxyde de carbone et la
vapeur d’eau (gaz rapides).
Pour les autres gaz (l’oxyg`ene, le dioxyde de carbone et la vapeur d’eau), on les
injecte dans un syst`eme de g´en´eration autonome produit de l’air enrichi en oxyg`ene.

54. 54 3.2. SYST `EME D’INERTAGE
F 3.11: Taux d’oxyg`ene sup´erieur `a 12%
F 3.14: s´eparateur d’air
3.2.2.3 Capteur d’oxyg `ene
Ce composant analyse le gaz dans les r´eservoirs et g´en`ere la "tension de Nernst" qui
est l’image de la pression partielle d’oxyg`ene PpO2.
Il y a deux capteurs d’oxyg`ene un pour r´ecup´erer la pression partielle d’oxyg`ene dans
le r´eservoir et l’autre pour la sortie de s´eparateur d’air.

55. CHAPITRE 3. ´ETUDE TECHNIQUE DU PROJET 55
F 3.12: Taux d’oxyg`ene nul
F 3.15: Construction du capteur

56. 56 3.2. SYST `EME D’INERTAGE
F 3.13: principe de fonctionnement en cas de sol et vol
Chaque capteur est constitu´e de 2 disques de dioxyde de zirconium : disque de
pompage et un disque de mesure. Deux concentrations diff´erentes d’ions de chaque
cˆot´e d’un ´electrolyte g´en`erent un potentiel ´electrique connu sous le nom de Tension de
Nernst. Cette tension est proportionnelle au logarithme n´ep´erien du rapport entre les
deux concentrations.
A une temp´erature sup´erieure `a 650˚C, le dioxyde de zirconium pr´esente les deux
comportements Suivants :
1. Le ZrO2 se dissocie partiellement pour produire des ions d’oxyg`ene qui peuvent
ˆetre v´ehicul´es `a l’int´erieur du mat´eriau lorsqu’une tension est appliqu´ee.
2. Le ZrO2 se comporte comme un ´electrolyte. Lorsque deux pressions d’oxyg`ene
diff´erentes existent de chaque cˆot´e d’un ´el´ement ZrO2, une tension (de Nernst)
peut ˆetre mesur´ee aux bornes de cet ´el´ement
3.2.2.4 R´egulation
| Syst`eme de chauffage : ce composant chauffe `a haute temp´erature (> 600 ˚), le cap-
teur d’oxyg`ene. Afin d’avoir la mˆeme temp´erature de chauffage pour chaque capteur
d’oxyg`ene, pour l’alimentation de l’´el´ement de chauffage, le capteur n´ecessite une
tension de 4.35 VDC pour atteindre la temp´erature de fonctionnement n´ecessaire
du dioxyde de zirconium. Il faut s’assurer que la mesure de la tension de chauffe
s’effectue au plus pr`es possible du capteur, car vu le courant important, les r´esistances
parasites dans les lignes de mesure g´en`erent des chutes de potentiels non n´egligeables.
L’alimentation en tension r´eglable devra ˆetre faiblement bruit´ee et fournir un cou-
rant de 2 A minimum.
| syst`eme de refroidissement : l’air propre ne doit pas d´epasser une temp´erature de
80˚, de ce fait on aura besoin d’un syst`eme de refroidissement d’air au niveau de
la sortie de s´eparateur d’air.
| Capteur de temp´erature
1. pour la sonde d’oxyg`ene : les donn´ee re¸cue `a partir de ce composant est
l’image de la temp´erature de la chambre pneumatique.

57. CHAPITRE 3. ´ETUDE TECHNIQUE DU PROJET 57
F 3.16: Fonctionnement de la partie chauffage
2. pour l’air propre : les donn´ee re¸cue `a partir de ce composant est l’image de
la temp´erature de l’air propre.
F 3.17: Fonctionnement de partie refroidissement

58. 58 3.2. SYST `EME D’INERTAGE
3.2.2.5 Pompe du courant
Cette composante fournit `a la sonde de l’oxyg`ene une source de courant afin de
r´ealiser l’´evacuation (courant positif) et le remplissage (courant n´egatif). La direction
de la source de courant constant est invers´e p´eriodiquement en fonction de deux seuils
V1 et V5.
F 3.18: Tension de Nernst en fonction de la pression d’oxyg`ene p2 dans la chambre
| Les donn´ees transmises `a cette composante est le contrˆole de la pompe (Activation
/D´esactivation).
| Les donn´ees re¸cues `a partir de cette composante est la tension de pompage.
| Chaque capteur d’oxyg`ene doit avoir une pompe de courant.
| Le premier disque ZrO2 (disque de pompage) travaille comme une pompe `a oxyg`ene,
´evacuant ou bien pressurisant la chambre scell´ee. En fonction du sens du courant
(source r´eversible), les ions d’oxyg`ene migrent d’une ´electrode `a l’autre et modifient
ainsi la concentration et ´egalement la pression p2 dans la chambre. Celle-ci est
alternativement ´evacu´ee ou bien remplie jusqu’ `a ce que la tension de mesure VN
(tension de Nernst) atteigne une certaine valeur de r´ef´erence pr´e-r´egl´ee.
| diff´erence de pression d’oxyg`ene aux bornes du second disque de ZrO2 (disque de
mesure) g´en`ere une tension de Nernst qui est proportionnelle au logarithme de la
diff´erence de concentration en oxyg`ene. Cette tension est mesur´ee et compar´ee `a
deux r´ef´erences de tension V1 et V5. Lorsque la tension atteint une de ces valeurs
de r´ef´erence, la polarit´e du flux de pompage est invers´ee pour atteindre l’autre
tension de r´ef´erence. V1 est la tension pour la pression d’oxyg`ene la plus ´elev´ee,

59. CHAPITRE 3. ´ETUDE TECHNIQUE DU PROJET 59
F 3.19: Fonctionnement de la pompe du courant
V5 celle pour la plus faible (pression atteinte dans la chambre par le proc´ed´e de
pompage). [7]
3.2.2.6 Calcul du pression partielle d’oxyg `ene
| Les moments o `u la tension de Nernst est ´egale `a V2, V3 et V4 se calculent par
les formules suivantes :
t1 = tv3 − tv2
t2 = tv4 − tv3
t4 = tv3 − tv4
t5 = tv2 − tv3
| La dur´ee de cycle td est calcul´ee comme suit :
| La dur´ee du cycle de pompage est fonction de la pression partielle de l’oxyg`ene
du m´elange de gaz `a mesurer. Plus la pression d’oxyg`ene ambiante est ´elev´ee, plus
long sera le temps mis par la pompe ionique pour ´evacuer et remplir la chambre
de mesure. Il en d´ecoule que le cycle de pompage est proportionnel `a la pression
partielle d’oxyg`ene en contact avec le capteur. La dur´ee du cycle correspond donc
`a la p´eriode de la tension de Nernst tp.
| En th´eorie, comme tensions de r´ef´erence V1 et V5 on peut choisir des valeurs
quelconques. Cependant, en pratique, les consid´erations suivantes doivent ˆetre
prises en compte :
1. Double couche ´electrique
2. Temps de r´eponse
3. Compensation en temp´erature

60. 60 3.2. SYST `EME D’INERTAGE
4. Sensibilit´e
| Tension de r´ef´erence et comparaison de tension : Le signal de mesure amplifi´e doit
ˆetre compar´e avec les tensions de r´ef´erence qui doivent elles-mˆemes ˆetre amplifi´ees
avec le mˆeme facteur que la tension de Nernst. Lorsqu’une des deux tensions de
r´ef´erence est atteinte, la source de courant constant inverse le sens du courant.
L’´el´ement de pompage doit ˆetre g´er´e de mani`ere telle que la chambre soit toujours
´evacu´ee en premier.
| Traitement du signal : Un micro-contrˆoleur est n´ecessaire pour surveiller la ten-
sion de Nernst amplifi´ee (SENSE) et pour calculer continuellement td ou tp. La
formation d’une valeur moyenne r´eduit le bruit naturel du capteur alors qu’une
valeur moyenne pond´er´ee mobile convient le mieux pour ne pas r´eduire le temps
de r´eponse du capteur. Le micro-contrˆoleur peut ´egalement surveiller le retard au
d´emarrage et l’inversion de la source de courant constant.
| Signal de sortie : La dur´ee de cycle calcul´ee par le micro-contrˆoleur doit ensuite
ˆetre transform´ee en signal de sortie souhait´e (p. ex. un signal de tension, de
courant ou une sortie digitale). Pour cela un DAC ou un programme de sortie
peut ˆetre n´ecessaire. De plus, le filtrage et la r´esolution du signal doivent ˆetre pris
en consid´eration.
F 3.20: Sch´ema fonctionnel d’un traitement ´electronique
| Si la tension de Nernst produite par le capteur repr´esente une sym´etrie comme
dans la figure, ceci est un signe clair d’un fonctionnement correct. Par contre une
asym´etrie de la tension de mesure peut avoir les causes suivantes :
1. La tension pour le filament de chauffage est trop faible.
2. Le capteur est souill´e et ne pompe plus correctement.
3. La chambre scell´ee pr´esente une fuite, c’est- `a-dire qu’il est plus difficile de
l’´evacuer et de la remplir.

61. CHAPITRE 3. ´ETUDE TECHNIQUE DU PROJET 61
4. L’´el´ement du capteur s’est charg´e de mani`ere fortement capacitive.
| L’asym´etrie peut ˆetre calcul´ee comme suit, en mˆeme temps que la mesure de td ou
tp.
| Le r´esultat devrait ˆetre id´ealement, lorsque le capteur fonctionne de mani`ere opti-
male. En production, l’asym´etrie du capteur a une tol´erance de 2,5 % (de 0,975 `a
1,025).
| Les donn´ees transmises `a cette composante est la commande de la vanne (choix
du gaz `a analyser).
| Les donn´ees re¸cues `a partir de cette composante est la valve sur l’´etat actuel.
F 3.21: Sch´ema fonctionnel d’un traitement ´electronique
3.2.2.7 Capteur de pression
Le capteur d’oxyg`ene ne mesure pas directement la concentration d’oxyg`ene (pour-
centage volum´etrique) mais la pression partielle de l’oxyg`ene. Selon la loi de Dalton le
pourcentage volum´etrique de l’oxyg`ene peut ˆetre calcul´e lorsque la pression totale est
connue.
| Loi de Dalton : la pression totale ptot du m´elange de gaz (consid´er´es comme
id´eaux) est ´egale `a la somme des pressions partielles pi de chaque gaz pr´esent
dans ce m´elange. Il en r´esulte que le rapport du nombre de particules (quantit´e
de substance) ni d’une composante i sur le nombre total de particules ntot du
m´elange est ´egal au rapport de la pression partielle pi de cette composante i sur
la pression totale ptot du m´elange.
ni
ntot
=
Pi
Ptot

62. 62 3.2. SYST `EME D’INERTAGE
| Capteur de pression : Les donn´ees re¸cues `a partir de cette composante est la
pression du chambre pneumatique.
| Il y a deux capteurs de pression un pour r´ecup´erer la pression totale sur le r´eservoir
et l’autre pour la sortie de s´eparateur d’air.
3.2.2.8 ´Electrovannes
| ´Electrovanne de calibration :s´election entre le mode "normal" et "calibration". Pour
mesurer une concentration d’oxyg`ene relative, les capteurs doivent ˆetre calibr´es aux
conditions ambiantes r´eelles et en pr´esence d’une concentration d’oxyg`ene connue.
En prenant l’air sec ambiant d’une humidit´e typique comme r´ef´erence, on peut
admettre que la concentration d’oxyg`ene est de 20,95 % du volume. Lorsqu’on
n’utilise pas un autre capteur de pression pour la surveillance des variations de la
pression d’air barom´etrique, une calibration quotidienne est recommand´ee.
| ´Electrovanne de contrˆole : contrˆoler le passage d’air enrichi par l’azote au r´eservoir.
| ´Electrovanne d’isolation : s´election entre la source de l’air "engin" et "ventilateur"
.
3.2.2.9 Interfaces de communication
| Le bus CAN (Voir Bus CAN page 92).
| GPIO (general-purpose input output).
| Le bus L’ARINC 429 (Voir Bus ARINC 429 page 94).
Conclusion Dans ce chapitre, nous avons pr´esent´e le cadre g´en´eral du projet. Il inclut
l’´enonc´e du sujet, le contexte, les objectifs ainsi que la planification du projet.
Dans le chapitre suivant, nous entamerons la partie consacr´ee aux travaux effectu´es.

63. CHAPITRE
4
TRAVAUX R ´EALIS ´ES
63

64. 64 4.1. SP ´ECIFICATION DU SYST `EME
4.1 Sp´ecification du syst `eme
La Sp´ecification syst`eme (SRD : System requirement document), c’est la premi`ere par-
tie du cycle de d´eveloppement en V, c’est le document qui regroupe les diff´erents aspects
fonctionnels du syst`eme, il d´ecrit ainsi l’environnement et l’entourage du syst`eme y com-
pris son positionnement dans l’avion, sa communication avec les autres ´equipements
et calculateurs... Le chapitre pr´ec´edant qui d´ecrit le fonctionnement du syst`eme fait
l’objectif de ce document.
4.2 Conception logicielle haut niveau
Cette ´etape de conception est la deuxi`eme ´etape (SWRD : Software Requirement Do-
cument) dans le cycle de d´eveloppement en V que nous avons suivi, elle a pour objectif
de donner une vision abstraite des fonctionnalit´es r´ealis´ees par notre syst`eme, cette
vision abstraite est traduite par un document qui regroupe un ensemble d’exigences,
chaque exigence d´efinit une fonctionnalit´e sp´ecifique qui va ˆetre d´evelopp´e dans les
´etapes suivantes du cycle.
Ce document repr´esente le cahier des charges pour le logiciel, c’est le point d’entr´ee
pour les d´eveloppeurs, il contient une description logicielle d´etaill´ee du comportement
du syst`eme `a d´evelopper.
F 4.1: Page de garde du document SWRD
Nous avons r´edig´e, dans le cadre de notre projet, ce document qui est nomm´e SWRD
(Software Requirements Document) ou Sp´ecification des exigences logicielles, afin de
d´efinir l’ensemble de cas d’utilisation qui d´ecrivent les interactions du syst`eme avec les
diff´erents ´equipement. Le travail que nous avons effectu´e est divis´e en deux parties :
une partie pour le syst`eme de contrˆole et de gestion du carburant, et une autre partie
pour l’inertage du carburant. Nous allons pr´esenter les deux syst`emes s´epar´ement.

65. CHAPITRE 4. TRAVAUX R ´EALIS ´ES 65
4.2.1 Syst `eme de gestion et de contrˆole du carburant
La figure 4.2 montre la d´efinition des entr´ees/sorties du syst`eme de contrˆole et de
gestion du carburant, et les bus de communications utilis´es pour communiquer avec les
autres calculateurs ou avec le syst`eme de commande et d’affichage (le cockpit).
F 4.2: Aper¸cu du syst`eme de contrˆole du carburant
Le logiciel embarqu´e que nous avons con¸cu pour r´ealiser les fonctionnalit´es du
syst`eme de contrˆole et de gestion de carburant communique avec 3 types d’´equipements :
les pompes et les valves, les panneaux de contrˆole et d’affichage (cockpit) et le syst`eme
de mesure des quantit´es de carburant (ce syst`eme est ind´ependant, il tourne sur une
autre plateforme mat´erielle (calculateur), et a ´et´e d´evelopp´e en parall`ele par d’autres
stagiaires).
Les pompes/valves : ce type d’´equipement est command´e par des entr´ees/sorties discr`etes,
pour chaque pompe et valve nous avons attribu´e une sortie discr`ete sur le micro-
contrˆoleur pour les commander soit en marche soit en arrˆet, et une entr´ee discr`ete
pour r´ecup´erer son ´etat (ouverte ou ferm´ee). Nous avons utilis´e 9 pompes et 23 valves
dans ce syst`eme.
Communication avec le cockpit : ce type de communication n´ecessite une installa-
tion cˆabl´ee de longue distance puisque notre syst`eme est situ´e au centre de l’avion et
le cockpit se trouve en avant, ainsi, les donn´ees `a recevoir et `a transmettre au cockpit
sont de petites tailles (un ensemble d’´etat logique), et peuvent ˆetre encapsul´ees dans une
trame de quelque bits, c’est pour cela nous avons choisi de travailler avec le bus ARINC
429 pour r´epondre `a ce besoin. (voir la section Bus ARINC 429 page 94 pour plus de
d´etails sur le bus ARINC 429)
Communication avec le syst `eme de mesure de quantit´es : cette communication
est assur´ee par le bus CAN, le choix de ce bus s’est bas´e sur la grande quantit´e de

66. 66 4.2. CONCEPTION LOGICIELLE HAUT NIVEAU
donn´ees `a transmettre et `a recevoir entre ces ´equipements, et sur la n´ecessit´e de mettre
ces donn´ees `a la disposition de plusieurs ´equipement (nœuds), ainsi, le bus CAN est le
bus le plus utilis´e dans les projets r´ealis´es par Zodiac Aerospace Maroc ce qui rend nˆotre
projet une r´ef´erence d’apprentissage pour les nouveaux entrants `a ZAM. (voir l’annexe
2.1 pour plus de d´etails sur le bus CAN)
4.2.2 Syst `eme d’inertage du carburant
La figure 4.3 pr´esente un aper¸cu sur les ´equipements :
F 4.3: Aper¸cu du syst`eme d’inertage
4.2.2.1 Les ´equipements
1. 2 capteurs d’oxyg`ene.
2. 2 capteurs de pression.
3. 2 capteurs de temp´erature.
4. Les vannes.
5. Le syst`eme de refroidissement.
6. Le syst`eme de chauffage.

67. CHAPITRE 4. TRAVAUX R ´EALIS ´ES 67
4.3 Conception logicielle bas niveau
La conception bas niveau est une ´etape tr`es importante dans le cycle de d´eveloppement
du logiciel, c’est l’´etape durant laquelle nous concevons les aspects relatifs au logiciel
(architecture et dimensionnement du logiciel, attribution des priorit´es pour les tˆaches
`a ex´ecuter dans le noyau du uC/OS II. . .). Nous avons d´efini, dans cette ´etape, et en
respectant les m´ethodologies de d´eveloppement logiciel au sein de Zodiac Aerospace
Maroc, deux architectures diff´erentes, une architecture statique et une autre dynamique.
F 4.4: Page de garde du document SWDD
4.3.1 Architecture statique
L’architecture statique d´efini les niveaux du logiciel, ces niveau doivent ˆetre respect´es
dans le reste des ´etapes du cycle en V. Cette architecture, comme montr´e sur la figure
4.5, contient 5 niveaux, chaque niveau est constitu´e de plusieurs unit´es fonctionnelles
(FU) qui sont regroup´ees par leurs types, il existe deux types d’unit´es fonctionnelles, une
FU active (en jaune) qui sert `a sp´ecifier les tˆaches `a ex´ecuter p´eriodiquement avec des

68. 68 4.3. CONCEPTION LOGICIELLE BAS NIVEAU
priorit´es (autrement dit, des tˆaches du noyau uC/OS II), et une FU passive (bleu) qui
sert comme une biblioth`eque de fonctions utilisables ind´ependamment du temps (des
fonctions de copie de m´emoire, des handlers. . .). La FU ’main’ est une FU Active, mais
ex´ecut´ee une seule fois, elle sert `a cr´eer et lancer les autres tˆaches et d’initialiser le
mat´eriel.
F 4.5: Architecture Statique
Nous avons con¸cu notre logiciel avec 4 FU Actives principales qui ex´ecutent l’algo-
rithme de chaque fonctionnalit´e d’une mani`ere p´eriodique (Alimentation des moteurs,
Transfer du carburant, Ravitaillement et inertage), chaque FU active est identifi´ee par
une priorit´e et une p´eriode, ces param`etres sont d´efinis dans l’architecture dynamique.
Nous avons ´egalement deux FU actives, qui servent `a pr´eparer les trames re¸cus et
les trames `a transmettre via les bus CAN et ARINC, ces FU existent dans un niveau
inf´erieur `a celui des autres FU actives pour la simple raison que dans cette architec-
ture, seuls les appels de fonctions de niveau sup´erieur sont autoris´es, par des fonction
(FU_Set() et FU_Get()), dans le but de limiter l’acc`es aux variables globales par toutes les
FU, seules les qui sont autoris´ees peuvent acc´eder aux variables.
Les autres FU passives offre des fonctions utilisables par toutes les FU actives telles
que la gestion de m´emoire, les entr´ees/sorties et le Watchdog.
4.3.2 Architecture dynamique
L’architecture dynamique (figure 4.6) sert `a sp´ecifier l’ordre d’ex´ecution du logiciel,
en attribuant `a chaque tˆache sa priorit´e, sans temps d´emarrage et sa p´eriode. Seules les
FU actives qui sont repr´esent´ees dans cette architecture.

69. CHAPITRE 4. TRAVAUX R ´EALIS ´ES 69
F 4.6: Architecture Dynamique
Ces architectures avec la description de chaque Unit´e Fonctionnelles sont regroup´es
dans le document nomm´e "FMCIS Software Design Document", la figure 4.4 montre la
page de garde de ce document.
4.4 Unit´es fonctionnelles
Unit´e fonctionnelle [8] : Sous-ensemble d’un logiciel complexe r´ealisant une fonc-
tionnalit´e particuli`ere ou fournissant des services g´en´eraux. Une FU est caract´eris´ee par
les propri´et´es suivantes :
4.4.1 Nom et Pr´efixe
Une FU est identifi´ee de fa¸con unique par un Nom (ex : Watchdog) ainsi qu’un
Pr´efixe associ´e (ex : wd_...). Ce pr´efixe (un seul mot court en minuscule) d´ebutera le nom
de chacun de ses constituant.
4.4.2 Type
Il identifie son comportement principal :
| Librairie : La FU est constitu´ee de fonctions utilitaires ind´ependantes regroup´ees
sur un th`eme (ex : Math, String . . . ). Ces FU sont d´etermin´es le plus souvent
au moment du design pour factoriser des ´el´ements de traitement. Les fonctions
fournies n’assurent pas `a elle seule la r´ealisation d’une exigence mais y contribue.
| Passive : La FU assure un service d´efini par des exigences mais doit ˆetre sollicit´ee
par une autre FU pour assurer sa fonction.
| Active :La FU assure un service d´efini par des exigences et fonctionne de fa¸con
autonome (Tˆache, S´equenceur, Interruption. . . ).

70. 70 4.4. UNIT ´ES FONCTIONNELLES
4.4.3 Niveau
Il identifie son niveau hi´erarchique. Celui-ci lui est attribu´e lors de la d´efinition
de l’architecture statique du projet logiciel. Cette FU ne pourra ˆetre sollicit´ee que
par des FU de niveau sup´erieur et ne pourra utiliser que des FU de niveau inf´erieur.
En cons´equence, des FU de mˆeme niveau ne peuvent pas avoir d’interaction directe.
Sauf exception, toutes les donn´ees utilis´ees par une FU sont priv´ees et ne peuvent ˆetre
acc´ed´ees par d’autres FU quel que soit leur niveau hi´erarchiques.
Les ´echanges d’information entre FU s’effectuent par l’interm´ediaire de fonctions d’acc`es
d´efinies dans un fichier d’interface publique (fu_public.h) En cas de donn´ees publiques
(constantes, variables, define...), la r`egle de visibilit´e en fonction du niveau hi´erarchique
est applicable. Le niveau de chaque FU constituant le projet sera d´efini dans le fichier
architecture.h Ce fichier sera inclus dans chaque fichier fu_public.h afin d’effectuer un
control d’acc`es des FU. En cas de non-respect des niveaux hi´erarchiques, la compilation
sera rejet´ee.
4.4.4 Les fichiers standards constituant une Unit´e Fonctionnelle
4.4.4.1 Interfaces
1. fu_config.h : D´efini les param`etres utilis´es pour configurer la FU.
2. fu_public.h : D´efini les interfaces publiques de la FU.
3. fu_private.h : D´efini les interfaces priv´ees de la FU.
4.4.4.2 Donn´ees
1. fu_config.c : Alloue les donn´ees de configuration constantes et variables de la FU.
2. fu_data.c : Alloue les donn´ees de travail constantes et variables de la FU.
3. fu_config_<section>.c : Alloue des donn´ees de configuration de la FU dans une
section sp´ecifique.
4. fu_data_<section>.c : Alloue des donn´ees de travail de la FU dans une section
sp´ecifique.
4.4.4.3 Fonctions publiques
1. fu_Startup : D´emarre la FU en fonction du type de d´emarrage demand´e.
2. fu_Shutdown : Arrˆete la FU.
3. fu_Get : Permet de d’obtenir un flow de donn´ee et/ou de contrˆole de la FU.
4. fu_Set : Permet de donner un flow de donn´ee et/ou de contrˆole `a la FU.
5. fu_Refresh : Permet d’effectuer le traitement principal de la FU.
6. fu_<public_function> : Permet d’effectuer une action sp´ecifique `a la FU.

71. CHAPITRE 4. TRAVAUX R ´EALIS ´ES 71
4.4.4.4 Fonction priv´ee
1. fu_Init : Initialise les donn´ees utilis´ees par la FU en fonction du type de d´emarrage
demand´e.
2. fu_Task : Contrˆole l’activit´e de la FU.
3. fu_Read : Collecte des flow de donn´ee et/ou de contrˆole provenant de FU de niveau
inf´erieur.
4. fu_Write : Distribue des flow de donn´ee et/ou de contrˆole vers des FU de niveau
inf´erieur.
5. fu_Update : Effectue le traitement principal de la FU.
6. fu_<private_function> : Effectue une action sp´ecifique `a la FU.
4.4.4.5 D´ependance et h´eritage des FU
F 4.7: D´ependance et h´eritage des FU
4.4.5 Les ´etapes `a suivre pour r´ediger un Doc_FU
Apr`es avoir une id´ee claire sur les constituants d’une unit´e fonctionnelle, maintenant
nous allons pr´esenter les ´etapes qu’on a suivi pour r´ediger un Doc_FU en traitant l’unit´e
fonctionnelle probe de notre projet qui permet de faire le calcul de la concentration
d’oxyg`ene.
4.4.5.1 Premi `ere ´etape
Cette ´etape consiste `a d´efinir l’objectif de cette FU ainsi que ses caract´eristiques.
La figure suivante illustre un exemple de l’unit´e fonctionnelle Probe :

72. 72 4.4. UNIT ´ES FONCTIONNELLES
F 4.8: Caract´eristique de la FU Probe
4.4.5.2 Deuxi `eme ´etape
Cette ´etape consiste `a d´efinir le cycle de d´emarrage de cette FU, ainsi que son cycle
de fonctionnement.
La figure suivante illustre un exemple de l’unit´e fonctionnelle Probe :
F 4.9: Cycle de fonctionnement de la FU Probe (capture du doc FU)
4.4.5.3 Troisi `eme ´etape
Cette ´etape consiste `a d´efinir les donn´ee `a setter et `a getter.
La figure suivante illustre un exemple de l’unit´e fonctionnelle Probe :

73. CHAPITRE 4. TRAVAUX R ´EALIS ´ES 73
F 4.10: Dictionnaire de donn´ees de la FU Probe
4.4.5.4 Quatri `eme ´etape
Cette ´etape consiste `a ´etablir un diagramme qui d´ecrit le fonctionnement de la FU.
La figure suivante illustre un exemple de l’unit´e fonctionnelle Probe :
F 4.11: Cycle de fonctionnement de la FU Probe
4.5 Exigences de bas niveau LLR
LLR : Low Level Requirment, c’est un document sp´ecifie pour chaque fonction
impl´ement´e dans une unit´e fonctionnelle, `a partir de lequel on peut coder cette fonction
facilement, et sans avoir r´ef´erence `a d’autre document.

74. 74 4.6. PR ´EPARATION DE L’ENVIRONNEMENT DU TRAVAIL
4.5.1 R´ediger un LLR
Dans un document LLR il faut ´etablir les points suivants :
| D´efinir le prototype de la fonction.
| D´efinir les donn´ees globales de cette fonction, ainsi que les constantes globales.
| D´efinir les fonctions appel´ees par cette fonction.
| ´Etablir une description de cette fonction.
La figure suivante pr´esent un LLR d’une fonction qui calcule la pression partielle
d’oxyg`ene de notre projet.
F 4.12: LLR de la foction probe_calcul_ppo2
4.6 Pr´eparation de l’environnement du travail
4.6.1 Portage du uC/OS II sur MPC5566
Avant de commencer la programmation et afin de pourvoir porter uc/os ii sur la
cible MPC5566, il faut tout d’abord s’assurer que :
| Le compilateur C g´en´erant du code r´eentrant.
| Il doit ˆetre possible de masquer/remettre les interruptions `a partir du code C.
| Le processeur doit ˆetre capable de fournir une interruption hardware avec une
fr´equence d´etermin´ee entre 10 et 100Hz.
| Le processeur doit ˆetre capable de fournir une interruption hardware avec une
fr´equence d´etermin´ee entre 10 et 100Hz .
| Le processeur doit pouvoir sauver le pointeur de pile et d’autres registres en
m´emoire .
| Le processeur doit pouvoir manipuler une pile hardware susceptible de g´erer plu-
sieurs Koctets.
Il est ´evident que toutes les contraintes sont respect´ees par les outils et le hardware du
syst`eme envisag´e.

75. CHAPITRE 4. TRAVAUX R ´EALIS ´ES 75
F 4.13: Structure du uc/os ii
4.6.1.0.1 Fichiers `a modifier La figure 4.13 montre l’architecture du uC/OS II ainsi
que sa relation avec le mat´eriel. Afin d’utiliser uC/OS II dans notre application, nous
avons adapt´e les deux fichiers d’entˆete OS_CFG.H et INCLUDES.H qui sont sp´ecifiques
`a l’application ainsi que les fichiers OS_CPU.H, OS_CPU_C.C et OS_CPU_A.ASM qui
contiennent le code sp´ecifique au processeur (portage).
Les autres fichiers contiennent le code propre `a l’ordonnanceur, il ne d´epend pas de
notre architecture MPC5566, par cons´equent ils ne seront pas modifi´es.
4.6.2 Composition d’un espace de d´eveloppement
F 4.14: Espace de D´eveloppement

76. 76 4.7. CODAGE ET G ´EN ´ERATION D’ELF
4.6.3 D´efinition Unit´e Fonctionnelle (FU)
F 4.15: D´efinition Unit´e Fonctionnelle
4.7 Codage et g´en´eration d’elf
4.7.1 Codage
Dans la partie codage nous avons cod´e chaque unit´e fonctionnelle `a part et chaque
fonction dans un fichier, en suivant la programmation modulaire ; alors dans cette partie
on va voir les ´etapes `a suivre pour coder une unit´e fonctionnelle en se basant sur les
documents pr´ec´edemment ´etablis (Doc_fu et llr) ainsi en respectant les r`egles de codage
impos´es par la norme DO178-B. Comme nous avons d´ej `a vu dans la partie r´edaction de
Doc_fu que chaque unit´e fonctionnelle contient plusieurs fichiers .h et .c, ainsi qu’il y a
4 types des fichiers :
| Interfaces
| Donn´ees
| Fonctions publiques
| Fonctions priv´ees
4.7.1.1 Premi `ere partie
Cette partie se focalise sur le codage des interfaces
4.7.1.1.1 fu_config.h Ce module permet de configurer et dimensionner une FU. Il ne
contiendra que des d´efinitions ´elabor´es sous forme de #define.
Voil `a un exemple de l’unit´e probe.
#ifndef probe_CONFIG_H
#define probe_CONFIG_H
#include "probe_private.h"
#define probe_TASK_IDENTIFIER fu_IDENTIFIER

77. CHAPITRE 4. TRAVAUX R ´EALIS ´ES 77
#define probe_TASK_PRIORITY fu_PRIORITY
#define probe_TASK_OPTION OS_TASK_OPT_STK_CHK
+ OS_TASK_OPT_STK_CLR
#define probe_TASK_NAME fu_NAME
#define probe_TASK_STACK_SIZE fu_STACK_SIZE
#define probe_TASK_START_TIME time_MILLISECOND_M(0)
#define probe_TASK_PERIOD time_MILLISECOND_M(100)
#define probe_CONFIG_TBD_1 fu_TBD
#endif
4.7.1.1.2 fu_public.h Ce module, ´elabor´e lors de l’´etape de design haut niveau, d´efini
tous les ´el´ements publiques n´ecessaire pour l’utilisation d’une FU ; c’est le seul visible de
l’ext´erieur ( #define, macro, constante, type, variable, fonction. . . ). Les d´efinitions pu-
bliques devront ˆetre r´eduites au strict n´ecessaire. Sauf cas particulier, aucune constante
ou variable publique ne doit exister.
4.7.1.1.3 fu_private.h Ce module, ´elabor´e lors de l’´etape de design d´etaill´e de la FU,
d´efini tous ses ´el´ements priv´es ( #define, macro, constante, type, variable, fonction. . . )
4.7.1.2 Deuxi `eme partie
Apr`es avoir coder les interfaces, on est pass´e au codage des fichiers des donn´ees sur
lesquelles on affecte des donn´ees aux variables que ce soit publiques ou priv´ees.
Et par la suite nous sommes pass´es au codage des fonctions publiques qui seront ac-
cessible ainsi que les fonctions priv´ees qui sont accessibles qu’ `a l’int´erieur de l’unit´e
fonctionnelle, en se basant sur l’algorithme impl´ement´e dans le LLR(low level require-
ment) propre `a chaque fonction.
4.7.2 G´en´eration de l’ex´ecutable ELF
Jusqu’ `a maintenant, nous avons ´ecrit des codes en langage C. Par contre le proces-
seur MPC5566 est incapable de comprendre ce langage : il lui faut un code binaire qui
va manipuler les registres, faire fonctionner des portes logiques, pointer des adresses en
m´emoire. . .
D’o `u la n´ecessit´e de g´en´erer l’ex´ecutable ELF.
4.7.2.1 Format ELF
ELF (Executable and Linkable Format, Format Ex´ecutable et liable) est un format
de fichier binaire pour des biblioth`eques de fonctions et ex´ecutables utilis´es `a tra-
vers diff´erentes architectures (PowerPC, SPARC, Intel 80386, Motorola 68000, Intel
i860, MIPS I, Intel i960, ARM, Intel IA64, x64) et syst`emes d’exploitation. Le support
ELF remplace le format a.out traditionnel parce qu’il est portable et rend tr`es facile la
construction des biblioth`eques d’ex´ecution . Afin de g´en´erer cet ex´ecutable, les fichiers
d’entr´ees passent par plusieurs ´etapes. Ces ´etapes sont repr´esent´ees dans le sch´ema
suivant :

78. 78 4.7. CODAGE ET G ´EN ´ERATION D’ELF
F 4.16: Concept de g´en´eration d’elf
Dans les sous sections suivantes, vous trouverez des explications sur les diff´erents
outils utilis´es :
4.7.2.2 Gmake
Gmake est un logiciel qui permet, sur la base d’un fichier de description Makefile,
de construire un projet tout en optimisant les ´etapes n´ecessaires pour parvenir au but
recherch´e, sans refaire toutes les ´etapes.
4.7.2.3 Makefile
Le Makefile est un fichier interm´ediaire entre le compilateur et le d´eveloppeur. nous
l’avons utilis´e pour automatiser la chaˆıne de compilation . En effet, au lieu de taper
`a chaque fois les commandes `a partir de l’invite de commande, on regroupe, dans le
Makefile, toutes les commandes que le compilateur Diab devra ex´ecuter ainsi que le
chemin de toutes les librairies. . .
Dans le fichier Makefile, il faut sp´ecifier le chemin du compilateur Diab, car il contient
des applications qui permettent de g´en´erer tous les fichiers appartenant `a la chaˆıne de
compilation.
On trouve les commandes de compilation : dar, das, dcc. . .Il est `a noter que :
| Le nom Makefile est une convention pour que le programme gmake puisse connaitre
facilement le nom du fichier (qui regroupe les commandes) qu’il doit ex´ecuter sans
sp´ecifier son nom .
| Makefile n’a pas une structure unique. Il n’y a pas un mod`ele standard `a suivre
car chaque d´eveloppeur a sa propre mani`ere de d´evelopper un script.

79. CHAPITRE 4. TRAVAUX R ´EALIS ´ES 79
4.7.2.4 Chaˆıne de compilation sous le compilateur Diab
Afin de g´en´erer l’ex´ecutable, les fichiers d’entr´ees passent par plusieurs ´etapes. Ces
´etapes sont repr´esent´ees dans la figure suivante :
F 4.17: ´Etapes de g´en´eration de l’elf
4.8 Simulation sur Trace32
Pour tester le fonctionnement de notre projet, nous avons d´evelopp´e des sc´enarios
de tests, puis on compare les r´esultats obtenus avec ceux attendus, ce processus nous a
permis de rectifier notre code source, en ´eliminant les erreurs fonctionnelles commises
pendant la phase de codage, dont la simulation finale de la FU probe est la suivante :
F 4.18: Simulation de la FU probe

80. 80 4.9. INTERFACES GRAPHIQUES
4.9 Interfaces graphiques
La simulation et le d´ebogage du projet que nous avons d´evelopp´e a ´et´e effectu´ee sur
le simulateur Trace32 de Lauterbach (voir Trace32 Lauterbach page 87), mais cette
m´ethode reste d´elicate et relativement complexe, d´ependant des algorithmes impl´ement´es
et le nombre de tests `a effectuer pour chaque cas, ce probl`eme est dˆu au fait que pour
effectuer un test sur le logiciel avec un sc´enario d´efinit, il faut coder le sc´enario de test
avec le logiciel, recompiler tout le projet et r´e-ex´ecuter le logiciel dans le simulateur, et
ce processus est r´ep´et´e pour chaque test jusqu’ `a l’accomplissement de tous les sc´enarios,
sinon il faut manipuler directement les entr´ees/sorties du syst`eme (tel que les GPIO, les
bus CAN et ARINC. . .) pour passer tous les cas de test possibles, mais ¸ca reste encore
plus difficile parce qu’il faut `a chaque fois r´ecup´erer les registres sur les quels il faut
travailler, chercher les bits qu’on doit changer et regarder les bits de sortie s’il avait eu
un changement et refaire cette manipulation pour chaque cas de test. Alors il faut avoir
une interface graphique plus compr´ehensible et plus accessible, et manipuler directe-
ment les entr´ees de l’interface et visualiser les changement sur la mˆeme interface sans
avoir recours `a chaque fois aux registres et au datasheet du micro-contrˆoleur. C’est ¸ca
l’objectif de nos interface.
puisque nous avons travaill´e sur deux syst`eme, et puisque chaque syst`eme a une
manipulation diff´erente de ses entr´ees, nous avons d´evelopp´e deux interfaces graphiques
afin de r´epondre `a ce besoin, ces interfaces ont ´et´e d´evelopp´ee par le langage C++ en
utilisant les biblioth`eque Qt, le choix ce langage de programmation est dˆu `a plusieurs
raisons, parmi ces raisons :
| Le langage C++ offre un niveau d’abstraction inf´erieur aux autres langages, ce qui
lui rend un langage de programmation efficace pour le d´eveloppement des syst`emes
embarqu´es.
| Les biblioth`eques de Qt sont riches de fonctionnalit´es avec une documentation
tr`es compl`ete pour chaque classe et pou
| Les ing´enieurs de Zodiac Aerospace d´eveloppent leurs logiciels avec les langages
C et C++, ce qui rend ces interfaces accessibles pour la maintenance et pour les
mises `a jour.
Nous pr´esentons dans ce qui suit, les interfaces que nous avons d´evelopp´e, avec des
captures sur leur fonctionnement.
4.9.1 Syst `eme de gestion et de contrˆole du carburant
L’interface graphique d´evelopp´ee pour ce syst`eme contient trois fenˆetres, comme
indiqu´e sur la figure 4.19, la 1re fenˆetre donne une vue sur l’architecture des r´eservoirs
et l’emplacement des pompes et des valves de chaque r´eservoir.

81. CHAPITRE 4. TRAVAUX R ´EALIS ´ES 81
F 4.19: L’interface graphique de contrˆole du carburant
La 2e fenˆetre simule la partie d’acquisition des quantit´es du carburant dans chaque
r´eservoir depuis le bus CAN, les valeurs `a entrer dans les champs sont des valeurs
enti`eres, et doivent respecter les marges d´efinies dans la sp´ecification du syst`eme. La
3e fenˆetre simule la partie de commande et d’affichage sur le cockpit qui communique
avec le syst`eme `a travers le bus ARINC 429, cette fenˆetre contient les boutons et les
interrupteurs qui sont d´efinis dans la sp´ecification syst`eme.
4.9.2 Fonctionnement
F 4.20: Fonctionnement de l’interface graphique de contrˆole du carburant