Téléchargé 184 fois
![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](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-27-320.jpg)
![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 ;](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-38-320.jpg)
![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](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-44-320.jpg)
![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).](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-47-320.jpg)
![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.](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-50-320.jpg)
![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](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-59-320.jpg)
![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. . . ).](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-69-320.jpg)
![CONCLUSION ET PERSPECTIVES 85
Ce stage fut une v´eritable exp´erience professionnelle. Nous nous sommes adapt´es fa-
cilement au milieu de l’entreprise, grˆace aux diff´erentes experiences que nous avons eues
durant notre formation, nous avons d´ecouvert la d´emarche `a suivre pour d´evelopper les
logiciels embarqu´es qui seront impl´ement´es dans les calculateurs des avions. Lors de ce
stage nous avons pu constater qu’on est capable de mener `a bien un projet du d´ebut `a
la fin, en effet nous avons effectu´e la totalit´e des ´etapes d’analyse, de conception et de
r´ealisation.
Grˆace `a ce stage nous nous sommes am´elior´es en m´ethodes d’analyses, en r´eflexion
et en prise de d´ecisions. Nous avons ´egalement compris l’approche `a suivre pour le
d´eveloppement des logiciels `a haute criticit´e [Selon la norme DO-178B]. Nous avons
approfondi aussi nos connaissances sur le fonctionnement du noyau temps r´eel uC/OS
II qui est utilis´e dans plusieurs domaines, notament l’occcasion que nous avons eue de
travailler sur une version certifi´ee.
Ce stage ´etait parfaitement adapt´e `a notre formation `a l’ENSA de F`es, en effet les
parties gestion, analyse et programmation, points centrales de la formation, ´etaient les
principaux objectifs de notre mission `a Zodiac Aerospace Maroc. Il nous a confort´e dans
l’id´ee de poursuivre dans cette voie et de faire des syst`emes embarqu´es le point central
de notre carri`ere professionnelle.
Ce stage conclus notre troisi`eme ann´ee de cycle d’ing´enieur, et en partie grˆace `a lui
nous avons la conviction d’avoir acquis un bon niveau dans les syst`emes embarqu´es en
g´en´erale qui nous permettra de r´eussir dans le domaine professionnel.](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-85-320.jpg)
![ANNEXE
A
OUTILS UTILIS ´ES
1.1 Trace32 Lauterbach
Lauterbach GmbH est une soci´et´e Allemande d’automatisation de la conception
´electronique sp´ecialis´ee dans les ´emulateurs in-circuit et dans les analyseurs logiques
utilis´es pour le d´ebogage des syst`emes embarqu´es .
L’entreprise a ´et´e fond´ee en 1979 par Lothar Lauterbach. En 2009, l’entreprise a ´et´e
rebaptis´ee de Lauterbach Datentechnik GmbH `a Lauterbach GmbH.
La soci´et´e sert une niche de march´e des ´emulateurs in-circuit, en particulier sur les
syst`emes utilisant JTAG, qu’elle vend sous la marque TRACE32 [9]. Il est le leader du
march´e mondial dans le domaine des outils de d´ebogage assist´e par le mat´eriel pour
les syst`emes embarqu´es, avec plus de 80 000 ´emulateurs vendus. Ils ont livr´e 65 000
licences de d´ebogage pour le populaire microprocesseur ARM seul, et ils supportent tous
les cœurs ARM disponibles. Cette exclusivit´e leur a permis de se d´evelopper fortement
dans les ventes au cours des derni`eres ann´ees (plus de 90 millions USD en 2011, 83
millions d’USD en 2007 avant la crise financi`ere).
Beaucoup de d´eveloppeurs de syst`emes embarqu´es aimeraient voir un niveau plus
´elev´e de la normalisation de la mise au point sur puce et la logique de trace ainsi
que d’une r´eduction du nombre de broches sans aucune perte de performance. Afin de
jouer un rˆole actif dans le d´eveloppement des technologies de tra¸cage et de d´ebogage
innovantes, Lauterbach a particip´e aux comit´es internationaux suivants au cours des
derni`eres ann´ees : Nexus (standard), Groupe de travail de d´ebogage MIPI, SPRINT Fo-
rum et Power.org.
87](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-87-320.jpg)
![88 1.2. UC/OS II
Lauterbach a des filiales locales en Royaume-Uni, Etats-Unis, Japon, France, Italie
et Chine . La soci´et´e est une soci´et´e priv´ee d´etenue par la famille fondatrice, les deux
fr`eres Lothar et Stephan Lauterbach ainsi que ses administrateurs.
F 1.1: Emulateur de MPC5566, Lauterbach
1.2 uC/OS II
MicroC/OS-II [10] (commun´ement appel´e comme uC/OS-II), est l’acronyme pour
Syst`eme d’Exploitation pour Micro-contrˆoleur Version 2. C’est un noyau de syst`eme
d’exploitation temps r´eel d´edi´e pour micro-processeurs, multi-tˆaches et bas´e sur le prin-
cipe de priorit´es avec un ordonnanceur pr´eemptif. Il est ´ecrit principalement en C. Il est
destin´e `a une utilisation dans des syst`emes embarqu´es. Ses caract´eristiques sont :
| Il s’agit d’un tr`es petit noyau temps r´eel.
| L’empreinte m´emoire est d’environ 20 Ko pour un noyau enti`erement fonctionnel.
| Le code source est ´ecrit en C ANSI
| Tr`es portable, ROMable, tr`es ´evolutive, pr´eventive en temps r´eel, d´eterministe,
noyau multi-tˆache.
| Il peut g´erer jusqu’ `a 64 tˆaches (56 tˆaches de l’utilisateur disponibles).
| Il dispose d’une connectivit´e avec uC/GUI et uC/FS (GUI et des syst`emes de fichiers
pour uC/OS II).
| Il est port´e `a plus de 100 microprocesseurs et micro-contrˆoleurs.
| Il est simple `a utiliser et simple `a mettre en œuvre mais tr`es efficace par rapport
au ratio prix/performance.
| Il supporte tous les types de processeurs de 8 bits `a 64 bits.](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-88-320.jpg)
![ANNEXE
BBUS DE COMMUNICATION
2.1 Bus CAN
Le bus CAN [11] (Controller Area Network) est un bus syst`eme s´erie tr`es r´epandu
dans beaucoup d’industries, notamment l’automobile. Il a ´et´e normalis´e avec la norme
ISO 11898. Il met en application une approche connue sous le nom de multiplexage, et
qui consiste `a raccorder `a un mˆeme cˆable (un bus) un grand nombre de calculateurs
qui communiqueront donc `a tour de rˆole. Cette technique ´elimine le besoin de cˆabler
des lignes d´edi´ees pour chaque information `a faire transiter (connexion point- `a-point).
D`es qu’un syst`eme (voiture, avion, r´eseau t´el´ephonique. . .) atteint un certain niveau de
complexit´e, l’approche point- `a-point devient impossible du fait de l’immense quantit´e de
cˆablage `a installer et de son coˆut (en masse, mat´eriaux, main d’œuvre, maintenance).
L’introduction des bus multiplex´es (principalement le CAN) dans l’automobile avait
pour objectif de r´eduire la quantit´e de cˆables dans les v´ehicules (il y a jusqu’ `a 2 km
de cˆables par voiture), mais elle a surtout permis l’explosion du nombre de calculateurs
et capteurs distribu´es dans tout le v´ehicule, et des prestations correspondantes (baisse
de consommation, d´epollution, s´ecurit´e active/passive, confort, d´etection des pannes. . . ),
tout en n’augmentant pas trop les longueurs cˆabl´ees.
2.1.1 Topologie
CAN est un bus de donn´ees s´erie bidirectionnel half-duplex. Chaque ´equipement
connect´e, appel´e nœud , peut communiquer avec tous les autres.
92](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-92-320.jpg)
![94 2.2. BUS ARINC 429
2.1.4 Trames
Il existe 2 standards pour la couche de liaison de donn´ees : ISO 11898 part A : CAN
2.0A standard frame format (identification sur 11bits), ISO 11898 part B : CAN 2.0B
extended frame format (identification sur 29bits). Il existe plusieurs types de trame :
| Trame de donn´ees,
| Trame de requˆete,
| Trame d’erreur,
| Trame de surcharge.
Entre 2 trames, les ´emetteurs doivent respecter une pause (p´eriode d’inter-trame) ´equivalente
`a la dur´ee de 3 bits pendant laquelle le bus est maintenu `a l’´etat r´ecessif.
2.1.5 Trame de donn´ees
La trame de donn´ees sert `a envoyer des informations aux autres nœuds. Une trame
de donn´ees se compose de 7 champs diff´erents :
| Le d´ebut de trame ou SOF (Start Of Frame) mat´erialis´e par 1 bit dominant,
| Le champ d’arbitrage (identificateur) compos´e de 12 ou 30 bits,
| Le champ de commande (ou de contrˆole) compos´e de 6 bits,
| Le champ de donn´ees compos´e de 0 `a 64 bits (de 0 `a 8 octets),
| Le champ de CRC compos´e de 16 bits,
| Le champ d’acquittement compos´e de 2 bits,
| La fin de trame ou EOF (End of Frame) mat´erialis´ee par 7 bits r´ecessifs.
F 2.4: Trame de donn´ees
2.2 Bus ARINC 429
ARINC 429 [12] est une norme pour l’a´eronautique qui d´ecrit `a la fois une architec-
ture, une interface ´electrique et un protocole pour v´ehiculer des donn´ees num´eriques.
Au d´ebut du XXIe si`ecle, ARINC 429 est le bus informatique le plus r´epandu sur les
syst`emes avioniques complexes.
2.2.1 Historique
La norme ARINC 429 a ´et´e d´evelopp´ee et est maintenue par l’Airlines Electronic
Engineering Committee (AEEC), comit´e de la soci´et´e ARINC. ARINC 429 est issue de
la norme ARINC 419 qui fut la premi`ere `a d´ecrire 4 topologies de bus num´eriques pour
l’aviation commerciale, dont la premi`ere version a ´et´e publi´ee en 1966, et la derni`ere
mise `a jour faite en 19831,2. La premi`ere norme ARINC 429 (429-1) a ´et´e publi´ee en
avril 1978, et la version actuelle est la version 429-18 adopt´ee par l’AEEC en 20121.
Elle est compos´ee de 3 parties : Partie 1 : Description fonctionnelle, interface ´electrique,](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-94-320.jpg)
![BIBLIOGRAPHIE
[1] Zodiac Aerospace. Pr´esentation du groupe powerpoint sliders. 2013.
[2] EUROCAE. SOFTWARE CONSIDERATIONS IN AIRBORNE, SYSTEMS AND
EQUIPMENT CERTIFICATION. EUROCAE, 1999.
[3] Roy Langton, Chuck Clark, Martin Hewitt, and Lonnie Richards. Aircraft Fuel
Systems. John Wiley and Sons, 2009.
[4] Airbus. A320 Flight Crew Operating Manual. Airbus, 2003.
[5] FEDERAL AVIATION ADMINISTRATION. Pilot’s Handbook of Aeronautical
Knowledg. U.S. Department of Transportation, 2008.
[6] Airbus. A320 Flight Crew Operating Manual. Airbus, 2003.
[7] Boeing. Boeing B737 NG - Systems Summary [Fuel]. SmartCockpit.com, 2005.
[8] Coordinateur Technique des Architectures Zodiac Aerospace. Architecture functio-
nal unit architecture guide. 2013.
[9] Lauterbach. Training Simulator and Demo Software.
[10] Jean Labrosse. microC OS II The real time kernel second edition. 2002.
[11] Wikipedia. Control area network.
[12] Wikipedia. Arinc 429.
97](https://image.slidesharecdn.com/71307456-3f85-4149-b324-0c6f9c25cb6e-160220232206/85/Rapport-97-320.jpg)
Téléchargé parEl Mehdi II
Rapport
Ce mémoire de projet de fin d'études présente la conception et la réalisation d'un logiciel embarqué pour la gestion et l'inertage du système carburant d'un aéronef, développé selon la norme DO-178B. Le projet a été réalisé au sein de Zodiac Aerospace Maroc et s'appuie sur le noyau temps réel µC/OS II pour l'architecture microcontrôleur MPC5566. L'objectif principal est de garantir la fiabilité et la sécurité des systèmes critiques dans l'avionique.
Rapport
- 1. MÉMOIRE DE PROJETDE 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 stagePFE El Mehdi El Fakir elmehdi@elfakir.me Saad Motahhir saad.motahhir@gmail.com 30 juin 2014
- 7. D´edicace A nos tr`esch`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 toutesnos 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 lessyst`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 systemsare 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 duprojet . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Outilsutilis´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 FIGURES21 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.1Niveaux logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.2 Activit´es logicielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 22
- 23. LISTE DES SYMBOLES ACCourant 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 DESSYMBOLES 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. CONTEXTEG ´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. CONTEXTEG ´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. CONTEXTEG ´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.
- 38. 38 2.1. DO-178B 2.1DO-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. ´ETATDES 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 T2.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. ´ETATDES 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. LECYCLE 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.
- 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. ´ETUDETECHNIQUE 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. ´ETUDETECHNIQUE 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. ´ETUDETECHNIQUE 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. ´ETUDETECHNIQUE 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. ´ETUDETECHNIQUE 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. ´ETUDETECHNIQUE 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. ´ETUDETECHNIQUE 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. ´ETUDETECHNIQUE 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. ´ETUDETECHNIQUE 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.
- 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. TRAVAUXR ´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. CONCEPTIONLOGICIELLE 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. TRAVAUXR ´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. CONCEPTIONLOGICIELLE 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. TRAVAUXR ´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. TRAVAUXR ´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. TRAVAUXR ´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. TRAVAUXR ´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. CODAGEET 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. TRAVAUXR ´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. CODAGEET 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. TRAVAUXR ´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. INTERFACESGRAPHIQUES 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. TRAVAUXR ´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
- 82. 82 4.9. INTERFACESGRAPHIQUES Cette interface fonctionne en collaboration avec le simulateur Trace32 (voir page 87), les commandes et les quantit´es entr´ees sur les fenˆetres 2 et 3 sont appliqu´ees aux registres du MPC5566 (CAN, ARINC429 et GPIOs) utilis´es par le logiciel, en fonction de ces entr´ees le logiciel ex´ecute l’algorithme que nous avons cod´e et qui r´epond aux besoins de la sp´ecification syst`eme, ensuite il agit sur les sorties (registres du MPC5566) et finalement les fenˆetres 1 et 3 affichent les ´etats des pompes et des valves ainsi que le mode d’ex´ecution du logiciel (AUTO, MAN ou FAULT). la figure 4.20 montre un exemple de fonctionnement, on remarque que pour les quantit´es entr´ees dans la fenˆetre 2, il s’ex´ecute en mode automatique (fenˆetre 3) et choisi d’alimenter les moteurs depuis le r´eservoir central en utilisant les 2 pompes centrales. 4.9.3 Syst `eme d’inertage F 4.21: L’interface graphique de l’inertage 1. pour d´emarrer le simulateur Trace32. 2. pour se connecter au simulateur Trace32. 3. pour lancer l’ex´ecution du programme. 4. pour arrˆeter l’ex´ecution du programme. 5. pour fermer le simulateur Trace32. 6. pour charger l’ex´ecutable. 7. pour donner les entr´ees des syst`emes. 8. donner l’´etat de l’avion s’elle est en vol ou en sol. 9. pour activer mode diagnostique. 10. pour afficher r´esultat. 11. pour afficher le mode de fonctionnement active. 12. afficher les ´etats des vannes.
- 83. CHAPITRE 4. TRAVAUXR ´EALIS ´ES 83 Conclusion Ce chapitre a ´et´e consacr´e pour pr´esenter les travaux que nous avons r´ealis´es durant la p´eriode de stage, nous avons r´edig´e plusieurs documents de sp´ecification, de conception haut niveau et de conception bas niveau ainsi que pour chaque unit´e fonc- tionnelle, ensuite nous avons d´evelopp´e des interfaces graphiques pour simuler et tester le bon fonctionnement de ce logiciel. L’objectif de ces documents est de pr´eparer une pla- teforme didactique qui englobe toutes les ´etapes de la partie conception et d´eveloppement du cycle en V, vu que ces ´etapes ne sont pas toute effectu´ees au sein de Zodiac Aerospace Maroc.
- 84. CONCLUSION ET PERSPECTIVES Au coursde ce stage de fin d’´etude effectu´e au sein de Zodiac Aerospace Maroc, nous avons travaill´e sur le sujet intitul´e ´etude et d´eveloppement de logiciel embarqu´e de gestion du carburant pour un avion sous la plateforme MPC5566 et du noyau temps r´eel uc/OS II . Durant la r´ealisation de notre projet nous avons suivi la norme DO-178B ainsi que le cycle de d´eveloppement en V, en effet, nous avons commenc´e par une sp´ecification du syst`eme dans laquelle nous avons r´ealis´e une ´etude technique sur le syst`eme de gestion du carburant, ensuite, nous sommes pass´es `a une sp´ecification logicielle, cette sp´ecification est divis´ee en deux parties une sp´ecification haut niveau dans laquelle nous avons extrait les exigences logicielles qui r´epondent aux besoins du syst`eme, et une sp´ecification bas niveau qui d´efinit les architectures statique et dynamique. Apr`es, nous avons divis´e le logicielle le logiciel en plusieurs unit´es fonctionnelle, et ce, pour faciliter la tˆache de programmation des modules en respectant les r`egles de codage en C pour l’embarqu´e. Pour des raisons de robustesse et de fiabilit´e, nous avons d´evelopp´e ce logiciel au- tour du noyau temps r´eel uC/OS II sur un micro-contrˆoleur de la famille MPC5566 de Freescale, et finalement, pour v´erifier le bon fonctionnement de notre syst`eme nous avons simul´e le logiciel sur des interfaces que nous avons d´evelopp´ees en C++ et en Qt, et qui communiquent avec le simulateur trace32 de Lauterbach afin de faciliter la tˆache de d´ebogage et de simulation. L’am´elioration de ce logiciel reste un point important dans les perspectives du projet, ainsi, de transformer ce mod`ele en un mod`ele g´en´erique applicable sur n’importe quel nouveau projet. 84
- 85. CONCLUSION ET PERSPECTIVES85 Ce stage fut une v´eritable exp´erience professionnelle. Nous nous sommes adapt´es fa- cilement au milieu de l’entreprise, grˆace aux diff´erentes experiences que nous avons eues durant notre formation, nous avons d´ecouvert la d´emarche `a suivre pour d´evelopper les logiciels embarqu´es qui seront impl´ement´es dans les calculateurs des avions. Lors de ce stage nous avons pu constater qu’on est capable de mener `a bien un projet du d´ebut `a la fin, en effet nous avons effectu´e la totalit´e des ´etapes d’analyse, de conception et de r´ealisation. Grˆace `a ce stage nous nous sommes am´elior´es en m´ethodes d’analyses, en r´eflexion et en prise de d´ecisions. Nous avons ´egalement compris l’approche `a suivre pour le d´eveloppement des logiciels `a haute criticit´e [Selon la norme DO-178B]. Nous avons approfondi aussi nos connaissances sur le fonctionnement du noyau temps r´eel uC/OS II qui est utilis´e dans plusieurs domaines, notament l’occcasion que nous avons eue de travailler sur une version certifi´ee. Ce stage ´etait parfaitement adapt´e `a notre formation `a l’ENSA de F`es, en effet les parties gestion, analyse et programmation, points centrales de la formation, ´etaient les principaux objectifs de notre mission `a Zodiac Aerospace Maroc. Il nous a confort´e dans l’id´ee de poursuivre dans cette voie et de faire des syst`emes embarqu´es le point central de notre carri`ere professionnelle. Ce stage conclus notre troisi`eme ann´ee de cycle d’ing´enieur, et en partie grˆace `a lui nous avons la conviction d’avoir acquis un bon niveau dans les syst`emes embarqu´es en g´en´erale qui nous permettra de r´eussir dans le domaine professionnel.
- 87. ANNEXE A OUTILS UTILIS ´ES 1.1Trace32 Lauterbach Lauterbach GmbH est une soci´et´e Allemande d’automatisation de la conception ´electronique sp´ecialis´ee dans les ´emulateurs in-circuit et dans les analyseurs logiques utilis´es pour le d´ebogage des syst`emes embarqu´es . L’entreprise a ´et´e fond´ee en 1979 par Lothar Lauterbach. En 2009, l’entreprise a ´et´e rebaptis´ee de Lauterbach Datentechnik GmbH `a Lauterbach GmbH. La soci´et´e sert une niche de march´e des ´emulateurs in-circuit, en particulier sur les syst`emes utilisant JTAG, qu’elle vend sous la marque TRACE32 [9]. Il est le leader du march´e mondial dans le domaine des outils de d´ebogage assist´e par le mat´eriel pour les syst`emes embarqu´es, avec plus de 80 000 ´emulateurs vendus. Ils ont livr´e 65 000 licences de d´ebogage pour le populaire microprocesseur ARM seul, et ils supportent tous les cœurs ARM disponibles. Cette exclusivit´e leur a permis de se d´evelopper fortement dans les ventes au cours des derni`eres ann´ees (plus de 90 millions USD en 2011, 83 millions d’USD en 2007 avant la crise financi`ere). Beaucoup de d´eveloppeurs de syst`emes embarqu´es aimeraient voir un niveau plus ´elev´e de la normalisation de la mise au point sur puce et la logique de trace ainsi que d’une r´eduction du nombre de broches sans aucune perte de performance. Afin de jouer un rˆole actif dans le d´eveloppement des technologies de tra¸cage et de d´ebogage innovantes, Lauterbach a particip´e aux comit´es internationaux suivants au cours des derni`eres ann´ees : Nexus (standard), Groupe de travail de d´ebogage MIPI, SPRINT Fo- rum et Power.org. 87
- 88. 88 1.2. UC/OSII Lauterbach a des filiales locales en Royaume-Uni, Etats-Unis, Japon, France, Italie et Chine . La soci´et´e est une soci´et´e priv´ee d´etenue par la famille fondatrice, les deux fr`eres Lothar et Stephan Lauterbach ainsi que ses administrateurs. F 1.1: Emulateur de MPC5566, Lauterbach 1.2 uC/OS II MicroC/OS-II [10] (commun´ement appel´e comme uC/OS-II), est l’acronyme pour Syst`eme d’Exploitation pour Micro-contrˆoleur Version 2. C’est un noyau de syst`eme d’exploitation temps r´eel d´edi´e pour micro-processeurs, multi-tˆaches et bas´e sur le prin- cipe de priorit´es avec un ordonnanceur pr´eemptif. Il est ´ecrit principalement en C. Il est destin´e `a une utilisation dans des syst`emes embarqu´es. Ses caract´eristiques sont : | Il s’agit d’un tr`es petit noyau temps r´eel. | L’empreinte m´emoire est d’environ 20 Ko pour un noyau enti`erement fonctionnel. | Le code source est ´ecrit en C ANSI | Tr`es portable, ROMable, tr`es ´evolutive, pr´eventive en temps r´eel, d´eterministe, noyau multi-tˆache. | Il peut g´erer jusqu’ `a 64 tˆaches (56 tˆaches de l’utilisateur disponibles). | Il dispose d’une connectivit´e avec uC/GUI et uC/FS (GUI et des syst`emes de fichiers pour uC/OS II). | Il est port´e `a plus de 100 microprocesseurs et micro-contrˆoleurs. | Il est simple `a utiliser et simple `a mettre en œuvre mais tr`es efficace par rapport au ratio prix/performance. | Il supporte tous les types de processeurs de 8 bits `a 64 bits.
- 89. ANNEXE A. OUTILSUTILIS ´ES 89 F 1.2: Le noyau uC/OS II de Micrium MicroC/OS-II est la deuxi`eme g´en´eration d’un noyau `a l’origine publi´e (avec code source ) dans un article en 1992 dans la magazine ’Programmation des syst`emes em- barqu´es’ et le livre uC/OS Le Real-Time Kernel par Jean J. Labrosse (ISBN 0 -87930- 444-8 ). L’auteur vise d’abord `a d´ecrire simplement le fonctionnement interne d’un syst`eme d’exploitation portable qu’il avait d´evelopp´e pour son propre usage, mais plus tard a d´evelopp´e le syst`eme d’exploitation comme un produit commercial. uC/OS-II est actuellement maintenu par Micrium Inc. et peut ˆetre autoris´e par produit ou par gamme de produits. L’utilisation du syst`eme d’exploitation est gratuit pour une utilisation non commerciale ´educatif. En outre, Micrium fournit d’autres produits logiciels de middleware tels que uC/CAN, uC/FL, uC/FS, uC/GUI, uC/Modbus, uC/TCP-IP, uC/USB et un large assorti- ment d’applications uC/TCP-IP tels que les logiciels client DHCP, POP3, SNTP, FTP, TFTP, DNS, SMTP, et TTCP. logiciel serveur comprend HTTP, FTP et TFTP. PPP est ´egalement disponible. Le 24 Mars 2009, Micrium publi´e un produit am´elior´e, uC/OS-III , avec le code source sous licence disponible pour 9995 dollar (US) par produit final. uC/OS-III dispose d’un nombre illimit´e de tˆaches et des priorit´es, et un ordonnancement de type Round-Robin. 1.3 MPC5566 Con¸cu pour la gestion du moteur, le contrˆoleur int´egr´e 32 bits Qorivva MPC5566 est le premier appareil de la famille Qorivva MPC55xx de Freescale `a int´egrer 3 Mo de m´emoire flash int´egr´ee, qualifi´e pour les environnements automobiles les plus s´ev`eres et offre l’option de lecture durant l’´ecriture (RWW). Ceci offre aux d´eveloppeurs un moyen rentable de construire, des fonctionnalit´es gourmandes en m´emoire. Contenant la tech- nologie Power Architecture®, la Qorivva MPC5566 est id´eal pour toute application qui n´ecessite le contrˆole en temps r´eel des algorithmes complexes, il offre des performances de syst`eme de jusqu’ `a cinq fois sup´erieure `a celle de ses pr´ed´ecesseurs MPC500, avec la fiabilit´e et la connaissance de la technologie ´eprouv´ee de Power Architecture.
- 90. 90 1.3. MPC5566 F1.3: Qorivva MPC5566 Le contrˆoleur embarqu´e Qorivva MPC5566 est compatible par broche et par code avec les autres membres de la famille de contrˆoleurs Qorivva MPC5500, permettant aux d´eveloppeurs de migrer facilement au premier micro-contrˆoleur de l’industrie offrant 3 Mo de flash int´egr´e. Les constructeurs automobiles et a´eronautiques, ainsi que leurs fournisseurs se tournent de plus en plus sur une plus vers les semi-conducteurs de grandes fonctionnalit´es pour permettre aux syst`emes de commande les plus avanc´ees d’ˆetre d´eploy´es. 1.3.0.1 Caract´eristiques F 1.4: Architecture du MPC5566 | Coeur PPC avec une technologie de haute performance, 132 MHz avec 32 bits, avec un codage `a longueur variable (VLE).
- 91. ANNEXE B. BUSDE COMMUNICATIONS 91 | Unit´e de gestion m´emoire (MMU) avec 32 tampon d’entr´ee enti`erement associative de traduction d’adresses (TLB). | SPE (extension de traitement de signal) : capacit´es DSP, SIMD et virgule flottante | 3 Mo de m´emoire flash int´egr´ee avec correction d’erreur de codage (ECC) et RWW | 128 Ko sur puce RAM statique avec ECC | 32 Ko de cache (avec la ligne-blocage) qui peut ˆetre configur´e comme m´emoire RAM suppl´ementaire | Deux unit´es de temps de processeur am´elior´ees (eTPUs), chacune avec 32 canaux E/S et de 24 Ko de m´emoire SRAM d´esign´e | 64-canal contrˆoleur EDMA (am´elioration de l’acc`es direct `a la m´emoire) | Contrˆoleur d’interruption (INTC) capable de traiter 339 s´electionnables sources d’interruption prioritaires | Boucle modul´ee de fr´equence `a verrouillage de phase (FMPLL) pour aider `a la gestion de l’interf´erence ´electromagn´etique (EMI) | Une interface de bus externe compatible MPC500 | Paquet de PBGA 416 broches | Plage de temp´erature : -40 `a 125 ˚C | Quatre interfaces s´erie (DSPI) | Quatre r´eseau de contrˆoleur (CAN) avec 64 tampons chacun | Deux interfaces am´elior´ees de communication s´erie (ESCI) | 24 syst`emes am´elior´es de canaux multiples d’E/S (EMIOS) avec des canaux unifi´ees
- 92. ANNEXE BBUS DE COMMUNICATION 2.1Bus CAN Le bus CAN [11] (Controller Area Network) est un bus syst`eme s´erie tr`es r´epandu dans beaucoup d’industries, notamment l’automobile. Il a ´et´e normalis´e avec la norme ISO 11898. Il met en application une approche connue sous le nom de multiplexage, et qui consiste `a raccorder `a un mˆeme cˆable (un bus) un grand nombre de calculateurs qui communiqueront donc `a tour de rˆole. Cette technique ´elimine le besoin de cˆabler des lignes d´edi´ees pour chaque information `a faire transiter (connexion point- `a-point). D`es qu’un syst`eme (voiture, avion, r´eseau t´el´ephonique. . .) atteint un certain niveau de complexit´e, l’approche point- `a-point devient impossible du fait de l’immense quantit´e de cˆablage `a installer et de son coˆut (en masse, mat´eriaux, main d’œuvre, maintenance). L’introduction des bus multiplex´es (principalement le CAN) dans l’automobile avait pour objectif de r´eduire la quantit´e de cˆables dans les v´ehicules (il y a jusqu’ `a 2 km de cˆables par voiture), mais elle a surtout permis l’explosion du nombre de calculateurs et capteurs distribu´es dans tout le v´ehicule, et des prestations correspondantes (baisse de consommation, d´epollution, s´ecurit´e active/passive, confort, d´etection des pannes. . . ), tout en n’augmentant pas trop les longueurs cˆabl´ees. 2.1.1 Topologie CAN est un bus de donn´ees s´erie bidirectionnel half-duplex. Chaque ´equipement connect´e, appel´e nœud , peut communiquer avec tous les autres. 92
- 93. ANNEXE B. BUSDE COMMUNICATIONS 93 F 2.1: Topologie du CAN 2.1.2 Support Chaque nœud est connect´e au bus par l’interm´ediaire d’une paire torsad´ee (blind´ee ou non). Les deux extr´emit´es du bus doivent ˆetre reboucl´ees par des r´esistances de 120 ohm (tol´erance entre 108 ohm et 132 ohm). F 2.2: Connexion des nœuds 2.1.3 Encodage des bits L’encodage utilis´e est de type NRZ (non retour `a 0) : F 2.3: Encodage en NRZ
- 94. 94 2.2. BUSARINC 429 2.1.4 Trames Il existe 2 standards pour la couche de liaison de donn´ees : ISO 11898 part A : CAN 2.0A standard frame format (identification sur 11bits), ISO 11898 part B : CAN 2.0B extended frame format (identification sur 29bits). Il existe plusieurs types de trame : | Trame de donn´ees, | Trame de requˆete, | Trame d’erreur, | Trame de surcharge. Entre 2 trames, les ´emetteurs doivent respecter une pause (p´eriode d’inter-trame) ´equivalente `a la dur´ee de 3 bits pendant laquelle le bus est maintenu `a l’´etat r´ecessif. 2.1.5 Trame de donn´ees La trame de donn´ees sert `a envoyer des informations aux autres nœuds. Une trame de donn´ees se compose de 7 champs diff´erents : | Le d´ebut de trame ou SOF (Start Of Frame) mat´erialis´e par 1 bit dominant, | Le champ d’arbitrage (identificateur) compos´e de 12 ou 30 bits, | Le champ de commande (ou de contrˆole) compos´e de 6 bits, | Le champ de donn´ees compos´e de 0 `a 64 bits (de 0 `a 8 octets), | Le champ de CRC compos´e de 16 bits, | Le champ d’acquittement compos´e de 2 bits, | La fin de trame ou EOF (End of Frame) mat´erialis´ee par 7 bits r´ecessifs. F 2.4: Trame de donn´ees 2.2 Bus ARINC 429 ARINC 429 [12] est une norme pour l’a´eronautique qui d´ecrit `a la fois une architec- ture, une interface ´electrique et un protocole pour v´ehiculer des donn´ees num´eriques. Au d´ebut du XXIe si`ecle, ARINC 429 est le bus informatique le plus r´epandu sur les syst`emes avioniques complexes. 2.2.1 Historique La norme ARINC 429 a ´et´e d´evelopp´ee et est maintenue par l’Airlines Electronic Engineering Committee (AEEC), comit´e de la soci´et´e ARINC. ARINC 429 est issue de la norme ARINC 419 qui fut la premi`ere `a d´ecrire 4 topologies de bus num´eriques pour l’aviation commerciale, dont la premi`ere version a ´et´e publi´ee en 1966, et la derni`ere mise `a jour faite en 19831,2. La premi`ere norme ARINC 429 (429-1) a ´et´e publi´ee en avril 1978, et la version actuelle est la version 429-18 adopt´ee par l’AEEC en 20121. Elle est compos´ee de 3 parties : Partie 1 : Description fonctionnelle, interface ´electrique,
- 95. ANNEXE B. BUSDE COMMUNICATIONS 95 ´etiquettes, formats des mots (Mise `a jour n 18 du 29/11/2012), Partie 2 : Standard pour les mots discrets (Mise `a jour n 16 du 01/12/2004), Partie 3 : Techniques de transfert de fichiers (Mise `a jour n 19 du 01/06/2009). L’article traite principalement de la 1repartie de la norme. 2.2.2 Topologie ARINC 429 d´ecrit un bus de donn´ees s´erie unidirectionnel standard (simplex). La norme impose ´egalement qu’il n’y ait qu’un seul ´emetteur par bus. Le nombre de r´ecepteurs peut lui aller jusqu’ `a 20. F 2.5: Topologie de l’ARINC 429 La connexion est r´ealis´ee par l’interm´ediaire d’une paire torsad´ee blind´ee compos´ee de 2 brins (ou lignes) A et B 3. Le transfert des donn´ees est r´ealis´e en diff´erentiel entre les 2 lignes de la paire. L’imp´edance de l’´emetteur doit ˆetre maintenue en perma- nence `a 75±5 ohm quel que soit le niveau HIGH, LOW ou NULL, divis´ee de mani`ere ´egale entre les 2 lignes de la paire. Cette valeur a ´et´e choisie pour ˆetre approximative- ment ´egale `a l’imp´edance caract´eristique de la paire blind´ee. La r´esistance de chaque r´ecepteur, entre les 2 lignes ( A et B ) et mais aussi entre chacune des lignes et la masse, doit ˆetre maintenue sup´erieure `a 12kohm. Idem pour la capacitance, qui doit ˆetre inf´erieure `a 50pF entre les 2 lignes, mais aussi entre chacune des lignes et la masse. La r´esistance totale des r´ecepteurs (jusqu’ `a 20) mis en parall`ele doit rester sup´erieure `a 8kohm. 2.2.3 Encodage des bits L’encodage utilis´e est de type bipolaire avec retour `a 0 r´epondant `a la forme sui- vante :
- 96. 96 2.2. BUSARINC 429 F 2.6: Encodage des bits de l’ARINC 429 2.2.4 Trame Les donn´ees sont cod´ees sous forme de mots de 32 bits qui peuvent ˆetre d´ecoup´es en 5 champs distincts : F 2.7: Trame de l’ARINC 429 | Le bit 32 est un bit de parit´e, | Les bits 30 et 31 constituent le Sign/Status | Matrix (SSM) et peut avoir plusieurs | significations en fonction du type de la donn´ee, | Les bits 11 `a 29 contiennent la donn´ee, | Les bits 9 `a 10 constituent le Source | Destination Identifier (SDI) et peut avoir plusieurs utilisations, | Les bits 1 `a 8 contiennent le label.
- 97. BIBLIOGRAPHIE [1] Zodiac Aerospace.Pr´esentation du groupe powerpoint sliders. 2013. [2] EUROCAE. SOFTWARE CONSIDERATIONS IN AIRBORNE, SYSTEMS AND EQUIPMENT CERTIFICATION. EUROCAE, 1999. [3] Roy Langton, Chuck Clark, Martin Hewitt, and Lonnie Richards. Aircraft Fuel Systems. John Wiley and Sons, 2009. [4] Airbus. A320 Flight Crew Operating Manual. Airbus, 2003. [5] FEDERAL AVIATION ADMINISTRATION. Pilot’s Handbook of Aeronautical Knowledg. U.S. Department of Transportation, 2008. [6] Airbus. A320 Flight Crew Operating Manual. Airbus, 2003. [7] Boeing. Boeing B737 NG - Systems Summary [Fuel]. SmartCockpit.com, 2005. [8] Coordinateur Technique des Architectures Zodiac Aerospace. Architecture functio- nal unit architecture guide. 2013. [9] Lauterbach. Training Simulator and Demo Software. [10] Jean Labrosse. microC OS II The real time kernel second edition. 2002. [11] Wikipedia. Control area network. [12] Wikipedia. Arinc 429. 97