MINISTERE DE L’EDUCATION NATIONALE DE LA RECHERCHE ET DE LA TECHNOLOGIE

******Institut National des Sciences Appliquées

Département de Génie Electrique et Informatique

******

PROJET DE FIN D’ETUDES

Centre Spatial de Toulouse

18 avenue Edouard Belin31 401 TOULOUSE CEDEX 4

FRANCE

CHICHER Arnaud5ème année AEI-TRS 1Juin 2004

Contrôle-commande pour les nacelles pointéesà base de technologies standard

Contribution à la conception et au développement du logiciel de vol

MINISTERE DE L’EDUCATION NATIONALE DE LA RECHERCHE ET DE LA TECHNOLOGIE

******Institut National des Sciences Appliquées

Département de Génie Electrique et Informatique

******

PROJET DE FIN D’ETUDES

Centre Spatial de Toulouse

18 avenue Edouard Belin31 401 TOULOUSE CEDEX 4

FRANCE

CHICHER Arnaud5ème année AEI-TRS 1Juin 2004

Contrôle-commande pour les nacelles pointéesà base de technologies standard

Contribution à la conception et au développement du logiciel de

REMERCIEMENTS

Je remercie vivement Pierre-Yves TOURNEAU pour m’avoir accueilli au sein de son équipe et AndréLAURENS pour m’avoir permis d’effectuer ce stage, pour son soutien, sa disponibilité et ses conseils avisés.

Je tiens à remercier Jean EVRARD, Alain VECTEN ainsi que André PELISSIER pour ses conseils enélectronique.

Je remercie également les stagiaires précédents, Semra SARPDAG, Jean-Pierre SEUMA-VIDAL, FrédéricPORTES pour avoir posé les bases du travail, ainsi que Karim HALIOUI stagiaire à mes côtés.

Enfin merci à toute l’équipe nacelles pointées pour l’accueil qu’elle m’a réservé tout au longde mon stage.

SOMMAIRE

INTRODUCTION ..................................................................................................................................... 1LE CENTRE NATIONAL D’ETUDES SPATIALES................................................................................ 21. Domaine d’application et les objectifs de mon stage............................................................... 3

1.1. Les nacelles pointées ...................................................................................... 3

1.2. Les travaux de l’équipe « nacelles pointées » ................................................. 4

1.3. Les idées directrices et l’environnement de développement............................ 4

1.4. Les objectifs de mon stage .............................................................................. 52. Principes d’architecture............................................................................................................... 6

2.1 Le contexte général ......................................................................................... 6

2.2 Un système de vu en couches......................................................................... 6

2.3 Une architecture répartie ................................................................................. 83. Travaux préalables à la conception et au développement du logiciel de bord.................... 11

3.1 Le temps réel et Ada...................................................................................... 11

3.2 La méthode de conception « HOOD » ........................................................... 16

3.3 Le modèle de répartition du langage Ada95 .................................................. 204. Travail effectué............................................................................................................................ 27

4.1 Les fonctions d’un logiciel de vol.................................................................... 274.1.1 Les fonctions de servitudes et de gestion bord ............................................................... 27

4.1.2 Les fonctions de pointage pour les instruments .............................................................. 28

4.1.3 Un contrôleur nacelle pour orchestrer le tout .................................................................. 30

4.1.4 Les télémesures et les télécommandes .......................................................................... 31

4.2 La phase de conception générale HOOD ...................................................... 33

4.3 Tests et développement de drivers pour entrer dans le monde réel .............. 394.3.1 Le socket IP avec AdaSocket .......................................................................................... 40

4.3.2 La liaison série ................................................................................................................. 41

4.3.3 Des cartes entrées-sorties analogiques et logiques........................................................ 42

4.4 Intégration d’équipements ou comment réaliser une maquette représentative454.4.1 Le GPS ............................................................................................................................ 45

4.4.2 Le vérin d’élévation.......................................................................................................... 46

4.4.3 Simulation d’équipements................................................................................................ 47

4.5 Répartir l’application bord .............................................................................. 47

4.6 Savoir observer et commander la nacelle depuis le sol ................................. 494.6.1 Comment observer la nacelle ?....................................................................................... 50

4.6.2 Comment commander la nacelle ?.................................................................................. 51

4.6.3 Intégration avec le segment sol ....................................................................................... 52

5. Epilogue....................................................................................................................................... 55TABLE DES FIGURES ......................................................................................................................... 56BIBLIOGRAPHIE .................................................................................................................................. 57

DOCUMENTS INTERNES ........................................................................................................... 57

RAPPORTS ET MANUEL DE REFERENCE ............................................................................... 57

1

INTRODUCTION

Ce document s’inscrit dans le projet d’évolution des architectures informatiques desnacelles pointées initié par mon maître de stage André LAURENS responsable du contrôle -commande des nacelles pointées. Ce projet repose sur l’idée que les technologies standardindustrielles peuvent parfaitement être opérationnelles sur un système tel que les nacellespointées.

J’ai effectué mon stage de fin d’études d’une durée de cinq mois (février – juin 2004),au sein de l’équipe des nacelles pointées, du département Ballons du CNES. Ce documentprésente l’état d’avancement à la fin du mois de juin du démonstrateur de logiciel de vol mettanten œuvre les nouvelles architectures et les choix technologiques du futur logiciel de volopérationnel.

Il est important de dire que je me suis appuyé sur des travaux effectués par plusieursstagiaires qui m’ont précédé sur ce projet. Ces travaux avaient pour but d’effectuer des études defaisabilités, des travaux sur les méthodes de conception et la mise en œuvre de systèmesrépartis.

Ce document se veut aussi une base de connaissances afin de réaliser le logiciel de volfinal.

2

LE CENTRE NATIONAL D’ETUDES SPATIALES

Le Centre National d’Etudes Spatiales (CNES) est un établissement public placé sous latutelle conjointe des Ministères de la Recherche et de la Défense. Crée en 1961, il est chargéd’élaborer et de proposer au gouvernement la stratégie spatiale française, et de la mettre enœuvre.

Le CNES participe également aux programmes conduits par l’Agence SpatialeEuropéenne (ESA), dont la France est l’un des principaux participants. Il joue ainsi un rôle majeurde proposition et d’entraînement dans les activités et programmes de l’ESA.

Le siège du CNES se trouve à Parie et dispose du plusieurs centres techniques enFrance offrant différentes compétences :

- Evry pour la direction des lanceurs Ariane (Recherche etdéveloppement, société commerciale).

- Toulouse pour les satellites et l’instrumentation embarquée.- Kourou pour les opérations de lancement des lanceurs Ariane.

Le CNES propose divers domaines d’activité :

- L’accès à l’espace : L’accès à l’espace représente un enjeu stratégique pour toutepuissance qui veut assurer son indépendance. Les lanceurs et systèmes de lancement deviennentdès lors l’un des piliers fondamentaux de la politique spatiale française et européenne. Lespouvoirs publics engagent le programme ARIANE, mobilisant des moyens financiers,technologiques et humains conséquents. Depuis le début des années 1960, le CNES entretientune activité « ballons » qui occupe le 2ème rang mondial juste derrière les Etats-Unis. Plus de 50vols sont réalisés chaque année en France ou à l’étranger. Les domaines d’utilisation scientifiquesont multiples : astronomie, étude des plasmas spatiaux, physique du globe mais surtout étudede l’atmosphère.

- Les programmes scientifiques : Le CNES mène et participe à de nombreusesmissions scientifiques pour l’observation de la Terre, l’étude et exploration de l’Univers, les volshabités.

- Les applications opérationnelles et commerciales : Les télécommunicationsspatiales, la localisation et la navigation par satellite, optimisation et gestion des ressourcesnaturelles.

- Les activités de Défense : La mission du CNES est de préparer et de proposerau gouvernement les programmes d’intérêt national dans le domaine spatial. Cette responsabilitéinclut la conduite et la mise en œuvre du programme spatial militaire, en liaison avec l’Etat-majordes Armées et la Direction Générale pour l’Armement (DGA). Le CNES participe largement auxprogrammes d’observation de la Terre avec les programmes HELIOS, SPOT, PLEIADES et leprogramme de télécommunications spatiales SYRACUSE.

Le Centre Spatial de Toulouse :J’ai effectué mon stage dans l’établissement de Toulouse, pôle technique et

opérationnel. La création du CST en 1968 accompagne la décentralisation des industries de pointevers la province. Il remplace alors l’ancien centre spatial de Brétigny-sur-Orge.

Haut lieu de la recherche spatiale, le centre développe, en partenariat avec lacommunauté scientifique et industrielle, des systèmes spatiaux complets, jusqu’à leur mise enservice opérationnelle. Il est unique par son importance et la diversité de ses activités. Il participeà la réalisation de projets scientifiques ou instrumentaux et pilote des programmes de rechercheet d’application tels que SPOT, HELIOS, ARGOS, etc. Il conduit également toutes les opérationsde mise en orbite des satellites.

3

1. Domaine d’application et les objectifs de mon stage

1.1. Les nacelles pointées

Une nacelle pointée est un véhicule de transport d’expériences scientifiques supporté par unballon stratosphérique. La principale fonction de ces nacelles est d’assurer l’orientation desinstruments dans une direction très précise par un système de pointage.

La nacelle peut aller jusqu’à 45 000 mètres d’altitude et peut peser jusqu’à 500 kg pour unemission en France métropolitaine mais peut aller jusqu'à plusieurs tonnes sur d’autres territoiresselon les réglementations en vigueur.

La nacelle est reliée au ballon par une chaîne de vol constituée de câbles porteurs et équipéepar de nombreux dispositifs de conduite de vol (GPS, réflecteurs ou répondeurs radar,séparateurs ballon – parachute – nacelle, équipements de télécommunications).

Les nacelles pointées offrent l’accès aux hautes couches de l’atmosphère à de nombreuxdomaines d’expérimentations scientifiques :

• Les missions d’observation astronomique et astrophysique. La nacelle aura pourmission de diriger l’instrument dans la direction des objets astronomiques souhaitésavec une grande précision et un maximum de stabilité possible.

• Les expériences de chimie atmosphérique qui ont pour but de d’identifier lesespèces chimiques qui composent l’atmosphère et d’en déterminer lesconcentrations selon l’altitude. La méthode la plus courante est la spectrométrie paroccultation : en visant un astre (typiquement le Soleil qui traverse les différentescouches de l’atmosphère) du zénith à son coucher, on verra le spectre du soleil semodifier en fonction des couches d’atmosphère traversées par la lumière venant duSoleil. La mission de la nacelle dans ce type de mission sera de maintenirl’instrument dans la direction du soleil tout au long de la mission.

Quelle que soit la mission de la nacelle elle comporte :

• Des équipements de mesures scientifiques qui constituent la charge utile• Une source d’énergie : piles ou batteries• Des équipements d’acquisition pour la surveillance de la nacelle (capteurs de

température, capteurs de pression …)• Un système de localisation (GPS)• Un système de communication avec le sol (équipement de télécommandes /

télémesures (TM/TC)).• Les équipements du système de pointage (capteurs et actionneurs)• Un ou deux calculateurs : un module de commande (MC) qui réalise les fonctions

de pointage primaire en azimut (à l’aide de gyroscopes, magnétomètres,inclinomètres, actionneur pivot) et la gestion des servitudes : contrôle des busd’alimentation, acquisition des mesures de température, tensions courant,localisation … Et un autre calculateur présent ou non selon la mission réalise lafonction du pointage fin en azimut et en élévation (MPF).

Les nacelles doivent aller dans les plus hautes couches de l’atmosphère afin que lesinstruments aient le moins d’éléments parasites possibles pour les instruments quand ceux sidoivent pointer des étoiles.

Une nacelle pointée est une solution moins coûteuse que des expériences transportées parsatellite. De plus la nacelle est réutilisable et permet une configuration modulable et peut servir àplusieurs missions.

4

Actuellement les calculateurs sont des PC104 comparables à des PC industriels occupant unetrès petite surface (15 x 15 cm) offrant toutes les interfaces d’un PC standard (clavier, écran,souris, ports COM, réseau Ethernet, ports vers supports de stockages). Le volume de stockageest une carte Flash PCMCIA de 256 Mo. Le Bus PC104 permet d’empiler des cartes d’entréessorties analogiques, entrées sorties logiques, ports série supplémentaires, commande demoteurs.

A l’heure actuelle le logiciel de vol est développé en C++ sur un système d’exploitation tempsréel : VxWorks.

1.2. Les travaux de l’équipe « nacelles pointées »

Cette équipe a en charge la définition, la réalisation et la mise en œuvre des nacelles quinécessitent un pointage solaire ou stellaire pour les besoins des expérimentations scientifiquesembarquées. Elle analyse les besoins de chaque mission, évalue la faisabilité et met en place toutles dispositifs nécessaires pour intégrer les expériences scientifiques.

L’équipe réalise le système de pointage, la chaîne de contrôle – commande (qui comprend,entre autre, le système informatique de bord), l’intégration de l’expérience scientifique, le test etla validation de la nacelle, l’opération de la nacelle en vol.

1.3. Les idées directrices et l’environnement dedéveloppement

A l’heure actuelle, André LAURENS, ingénieur informatique de l’équipe, assure entièrement laconception, le développement, l’évolution et la maintenance des logiciels de vol et sol. Leslogiciels actuels sont développés en C++, mais tournent dans des environnements différents. Lelogiciel sol tourne sur le système d’exploitation Windows 98 et le logiciel de vol sur un Systèmed’exploitation temps réel VxWorks.

André LAURENS a choisi de faire évoluer l’architecture et les technologies des logiciels bord etsol afin d’obtenir des applications plus flexibles vis-à-vis des différentes missions et deséquipements, de réduire les temps de développement et de disposer d’un environnement dedéveloppement qui permet d’uniformiser les technologies utilisées entre bord et sol en s’appuyantsur des solutions standards, puissantes et peu coûteuses.

Les cartes PC104 sont de plus en plus puissantes et intégrées, ce qui permet de les fairefonctionner comme des calculateurs sol, avec des systèmes d’exploitation et des chaînes dedéveloppement standards accessibles à tous.

Mon responsable de stage a choisi le système d’exploitation Linux pour les logiciels sol etbord. On dispose donc du même environnement de développement pour les deux logiciels.

Les choix pour la conception et le développement ont été les suivants :

• Utilisation de la méthode de conception HOOD et de l’outil STOOD, afin de concevoirune architecture fiable et évolutive.

• Développement en Ada95, offrant des fonctionnalités de modularités, un service multi-tâches préemptif, ce qui permet de développer des applications temps-réel.

• Utilisation d’une application répartie sur réseau IP.

Les stagiaires précédents, Semra SARPDAG (UPS), Jean-Pierre SEUMA-VIDAL (INSATOULOUSE GII) et Frédéric PORTES (UPS), ont effectué de nombreux travaux d’études defaisabilité Linux-Ada95-répartition, d’une première conception HOOD du logiciel de vol, de

5

recherche de distributions LINUX adaptées et de développement de drivers de cartes etd’équipements.

Nous disposons d’un poste de développement avec une version de Linux Mandrake 9.1 avecun noyau 2.4 et deux maquettes de calculateurs embarqués à base de PC104 connectés auréseau local. Une version Linux Slackware 7.1 noyau 2.2 est installée sur les deux maquettes. Ona donc une technologie à bord tout à fait standard et on développe les logiciels de bord non plusen croisé mais en natif.

1.4. Les objectifs de mon stage

Pendant la première partie de mon stage je devais compléter et aller le plus loin possibledans la conception du logiciel de vol à l’aide de l’outil STOOD.

J’ai dû aussi étudier la mise en œuvre du modèle de répartition décrit dans l’annexe de lanorme du langage Ada95 par GNAT-Glade et intégrer cette technologie dans le logiciel de vol.

Puis je dois débuter et aller le plus loin possible dans le développement d’un démonstrateurdu logiciel de vol qui couvre toutes les facettes des choix technologiques : répartition, applicationde la méthode HOOD, comportement temps réel représentatif d’un vrai logiciel de vol. Lamaquette devra être la plus proche possible d’un vrai logiciel opérationnel : réception detélécommandes émises par la station sol, émission de télémesures, contrôleur général, interfaced’équipements (GPS, vérin d’élévation …) à l’aide de cartes d’entrées / sorties analogiques, cartesde contrôle moteur, d’interfaces liaisons séries.

Dans ce rapport, je décrierai tout d’abord le temps réel avec Ada95, les principes de laméthode de conception HOOD et le modèle de répartition GNAT-Glade.

Puis je présenterai le travail effectué jusqu’à ce jour dans l’avancement de la maquette dulogiciel de vol, la démarche adoptée, les différents problèmes rencontrés, leur solution, le travailrestant à effectuer.

6

2. Principes d’architecture

2.1 Le contexte général

Un dossier de spécification [LAURENS, 2004] m’a été fourni et écrit par André LAURENS quidéfini les axes d’évolution, la nouvelle architecture et les objectifs à atteindre pour les logiciels devol, sol et l’interface bord - sol.

Le premier axe d’évolution est une architecture flexible. Les fonctions d’un logiciel de vold’une mission à l’autre peuvent varier, des besoins nouveaux apparaissent et peuvent amenés àde nouvelles fonctions. La solution adoptée devra permettre d’ajouter facilement des modules.Cette vision modulaire correspond à ce qu’offre le langage Ada95 par l’intermédiaire de sespaquetages et les mécanismes de généricité.

Dans ce service des nacelles pointées, il faut rappeler qu’on ne dispose pas des mêmesmoyens financiers alloués aux satellites. De plus le temps de réaction de développement deslogiciels pour les ballons est très court de part la fréquence des vols. Les applications ballonsn’ont pas le même niveau « hautement critique » que les applications satellites du point de vudes contraintes temporelles. Mais c’est un aspect qu’il ne faut pas négliger dans la conception.

Compte tenu de ces contraintes financières, il faut adopter des choix technologiques fiables,qui ont fait leurs preuves et qui restent peu coûteuses.

Le choix du système d’exploitation Linux paraît comme une évidence : c’est un systèmemondialement utilisé en open – source donc gratuit, qui a fait ses preuves de fiabilité. On disposeaussi d’une large documentation en ligne sur internet et de mises à jour gratuites. Linux offretoutes les interfaces et les services requis : drivers, couches réseaux, liaisons séries …

On peut comparer ce système d’exploitation à d’autres systèmes spécialement dédiés auxapplications embarquées comme VxWorks, Lynx qui sont d’un confort relatif de développement,coûtent très chers à l’achat et en maintenance et les fabricants offrent des services de supportprécaires.

Linux possède une large communauté et des listes de discussion mondiale et on peut doncpartager les expériences de différents développeurs.

Mais Linux n’offre pas de services préemptifs, ce qui justifie encore l’utilisation du langageAda95 car il offre un service multi-tâches préemptif. De plus il existe une liste de discussion Adaqui permet d’obtenir de précieux conseils des utilisateurs du langage.

2.2 Un système de vu en couches

En première approche pour la conception du logiciel de vol on peut adopter une vue encouches à la manière de l’architecture de référence définie par l’ISO (International StandardOrganization), l’architecture en couches de modèles OSI (Open System Interconnection) pour lesréseaux.

7

La figure 1 ci-après présente cette vue en couches :

Figure-1 système de vue en couches

On peut lier le matériel du calculateur (les cartes d’entrée sorties analogiques, logiques, portsde liaison série) aux drivers de ces cartes, des différents ports.

Sur la couche supérieure se trouvent les équipements du système comme les capteurs, lesactionneurs, qui seront connectés physiquement aux cartes du calculateur et quiinformatiquement seront contrôlés à travers les drivers des cartes et feront l’objet de drivers decapteurs, d’actionneurs.

Si on monte encore sur la couche supérieure, on y trouve les lois de fonctionnement dusystème comme par exemple pointer en azimut auxquelles on peut associer les composantes dulogiciel qui réalisent les lois de contrôle et les asservissements.

Enfin, sur la couche la plus haute, on trouve les lois de fonctionnement du monde, quirégissent la position des objets célestes. On associe cette couche du monde réel aux calculsastronomiques implémentées dans le logiciel qui vont généré, à l’aide de différentes informations(localisation, altitude, date …), des consignes pour le pointage de la couche inférieure.

Monde logiciel Monde réel

Matériel du calculateur

Matériel du système

Lois de fonctionnementdu système

Lois de fonctionnementdu monde

Drivers de cartes

Drivers deséquipements

Algorithmes decontrôle

Algorithmes deguidage

8

2.3 Une architecture répartie

L’architecture actuelle de l’ensemble du système bord - sol fait apparaître une séparation dessegments bord et sol comme on le voit sur la figure 2 :

Figure-2 Architecture bord-sol actuelle

Les deux segments communiquent par le système de télécommunication opérationnel ETNA(Ensemble de Transmission Numérique pour Aérostat). Cette liaison se présente comme des voiessérie RS232 multiplexées dans un canal radiofréquence. La communication se fait dans les deuxsens, bord -> sol (télémesures), sol -> bord (télécommandes), chaque voie pouvant avoir savitesse de transmission. Le système ETNA ne propose qu’un transport d’octets indépendants, ilfaut implémenter pour chaque segment un protocole.

On observe aussi que les deux calculateurs (MC et MPF : Module de Commande et Module dePointage Fin) ne communiquent pas entre eux, il faut donc dupliquer certaines fonctions sur lesdeux calculateurs. Les deux calculateurs envoient leurs propres TM et reçoivent leurs propres TC.Et chacun doit posséder une réplique des programmes permettant de traiter les TM/TC. Lesliaisons RS232 entre les deux calculateurs et le système ETNA étant multiplexées pour laisserpasser les trames TM/TC, le port de liaison est limité par la voie dont le débit est le plus faible :les voies TM sont limitées à 38400 bauds et les voies TC à 9600 bauds. Dans ce cas, la vitesse detransmission sur la liaison Module de Contrôle – système Etna est donc limitée à 9600 bauds.

9

Il serait donc souhaitable d’optimiser les débits en exploitant au maximum le système ETNA.Il faudrait donc centraliser les fonctions de réception et d’émission des TM/TC sur un seulcalculateur, de façon à ne plus dupliquer ces programmes et bien d’autres.

Dans cette optique il faut que les deux calculateurs de bord puissent communiquer. Commenous utilisons Linux et les PC104, nous disposons de toutes les couches réseaux pourimplémenter un réseau IP (interface Ethernet sur PC104, couche applicative offerte par Linux). Aterme il est envisagé donc de faire communiquer les machines bord par liaison IP mais aussi defaire communiquer le segment sol et bord de la même manière.

Avec cette architecture matérielle, il est alors possible d’utiliser un logiciel de vol répartiutilisant GNAT-Glade 3.15p. Elément très important dans le logiciel de vol. Il offre une grandesouplesse de distribution des fonctions. L’idée est de développer une application comme si elledevait s’exécuter sur un seul calculateur, puis de répartir les fonctions sur les deux calculateursen prenant compte des contraintes applicatives et matérielles et ceci sans modifier une ligne decode. On décrira plus tard dans ce document l’annexe des systèmes distribués Ada95 et sonimplémentation par GNAT-Glade 3.15p. A terme, il est prévu de ne réaliser un seul logiciel répartientre les machines bords et les machines sols remplaçant les deux applications bord et sol :

Figure-3 Architecture bord-sol répartie

La répartition possède de nombreux avantages. Tout d’abord de répartir et de modifiersimplement la charge de calcul du CPU. Un module PC104 est constitué d’empilement de cartes :carte centrale (CPU, contrôle réseaux, mémoire …) et de carte périphériques (cartes d’entréessorties, cartes de contrôle moteurs …). Cet empilement est limité, on ne peut empiler que cinq

10

cartes sur la carte centrale. Avec la répartition, on peut résoudre ce problème de limitation enajoutant d’autres calculateurs reliés au réseau IP.

La répartition des éléments du logiciel de se fera pas au hasard, on peut répertorier plusieurscritères :

- Le couplage par les flux de données : il serait maladroit de localiser sur descalculateurs différents des entités qui échangent une grande quantité de données,ou qui ont des échanges de données fréquents

- Le couplage par les flux de contrôle : il serait maladroit de localiser sur desmachines différentes, des entités qui requièrent l’une de l’autre des services defaçon très fréquente

- Le couplage par le matériel : il serait maladroit (voire impossible) de localiser ledriver d’un équipement ou d’une carte d’entrées/sorties sur un autre calculateur quecelui où est connecté l’équipement ou la carte

- La charge CPU : la gestion des marges de ressources CPU peut être facilitée par unerépartition judicieuse des traitements sur les différents calculateurs.

11

3. Travaux préalables à la conception et au développementdu logiciel de bord

Avant de se plonger dans le cahier des charges du logiciel, dans la conception, dudéveloppement de l’application, il m’a fallu expérimenter les outils, les technologies et lesméthodes que j’allais utiliser tout au long de mon stage car ce sont des méthodes de conception,de développement et des technologies que je n’avais pas ou peu étudiées au cours de maformation. Je présenterais d’abord le temps-réel Ada qui permettra de répondre aux exigencestemps réel du logiciel, la méthode de conception HOOD qui servira de support à la conception dulogiciel et la technologie de répartition, offerte par GNAT-Glade.

3.1 Le temps réel et Ada

• Les tâches en Ada95 :

La section 9 de la norme Ada95 [Ada95 Reference Manual] offre la possibilité de créer destâches, offre des mécanismes de synchronisations et la préemption. Ada95 offre uneimplémentation de systèmes temps réel beaucoup plus agréable à développer, moins lourde àécrire qu’une implémentation par VxWorks.

Une tâche Ada se présente syntaxiquement comme un paquetage. Elle est constituée d’unespécification décrivant l’interface présentée aux objets externes et d’un corps décrivant soncomportement dynamique :

-- spécification :task La_tâche is …end La_tâche;

-- corps :task body La_tâche is …begin …end La_tâche;

La première fonction d’une tâche est le parallélisme, en effet il est avantageux de considérerl’application comme la mise en parallère de plusieurs activité,. comme par exemple des bouclesde régulation, des activités de surveillance de certains systèmes, un dialogue avec la station sol… etc.

L’activation d’une tâche est automatique. Une tâche locale devient active quand l’unitéparente atteint le begin de la tâche. La tâche se termine lorsqu’elle atteint le end. Lorsqu’unetâche est déclarée dans une unité déclarative (sous-programme, programme principal …), on nepeut quitter cette unité que lorsque la tâche est terminée. Par conséquent la terminaison d’unetâche comporte deux étapes : quand elle atteint son end puis quand toutes les unités dont elledépend sont terminées.

Les tâches peuvent interagir, principalement de deux façons : directement, en envoyant desmessages les unes vers les autres, et indirectement, en accédant à des données partagées. Lesmessages sont passés directement entre les tâches en Ada par un mécanisme appelé « rendez-vous ». Dans un rendez-vous entre deux tâches, les deux entités réalisent un échange etpoursuivent indépendamment leur activité. Un rendez-vous entre deux tâches arrive commeconséquence d’un appel de l’entrée d’une tâche par une autre. Une entrée est déclarée dans unespécification de tâche comme on déclare une procédure dans une spécification de paquetage :

12

task La_tâche is

entry E( … ); …end La_tâche;

Une entrée peut avoir des paramètres de mode in, out et in out. On appelle une entréecomme une procédure : La_tâche.E(…) ;

Les instructions à effectuer pendant le rendez-vous sont décrites dans le corps de l’instructionaccept correspondante à l’entrée activant la tâche :

accept E (…) do …end E;

La principale différence entre un appel d’entrée et un appel de procédure est la suivante :dans le cas d’une procédure, la tâche qui appel la procédure exécute aussi immédiatement lecorps de la procédure, alors que dans le cas d’une entrée, une tâche appelle l’entrée mais c’est latâche à laquelle appartient l’entrée qui exécute l’instruction accept correspondante. De plusl’instruction accept ne sera exécutée que lorsqu’une tâche appelle l’entrée et que la tâchepossédant l’entrée aura atteint l’instruction accept. Quand cela se produit, la suite d’instructionscontenue dans l’instruction accept est exécutée pendant que la tâche appelante reste suspendue.On appelle cette interaction un rendez-vous. Quand la fin de l’instruction accept est atteinte, lerendez-vous est fini et les deux tâches poursuivent leur exécution indépendamment.

Chaque entrée possède une file d’attente des tâches qui sont en attente d’un rendez-vouspour cette entrée : cette file est normalement traitée par une politique FIFO.

L’instruction select permet à une tâche de choisir un rendez-vous parmi plusieurs.L’instruction select commence par le mot réservé select et se termine par un end select; Ellecontient deux options ou plus, séparées par or. Une partie de code alternatif peut être insérée àl’instruction select, cette partie de code précédée du mot clé else est exécutée si les filesd’attentes liées aux entrées proposées par le select sont vides :

select accept E1 ( … ) do … end E2;or accept E2 ( … ) do .. end E2;else ..end select ;

Nous allons voir sur un exemple on comment peut implémenter une tâche cyclique qui aurapour rôle la régulation d’un système à une période fixe (période d’échantillonnage).

Quelles actions doit-on avoir sur la tâche ? Nous avons besoin d’un service « démarrer » pourdébuter la régulation, d’un service « arrêter » pour pouvoir stopper la régulation et d’un service« fournir une consigne » avec une valeur :

13

-- declaration de la tâche :task Regulation_Du_Systeme is

entry Demarrer;entry Arreter;entry Fournir_Une_Consigne (La_Consigne : in Unite_De_Consigne);

end Regulation_Du_Systeme;

-- corps de la tâche :task body Regulation_Du_Systeme is La_consigne_Du_Systeme : Unite_De_Consigne := 0.0;begin generale : loop select accept Demarrer; boucle_de_Regulation : loop select accept Arreter; exit boucle_de_regulation; or

accept Fournir_Une_Consigne (La_Consigne : in Unite_De_Consigne) do La_Consigne_Du_Systeme := La_Consigne; end Fournir_Une_Consigne; else declare Periode : constant duration := 0.1; Prochaine_Echeance : constant Time := clock + Periode; Valeur_Capteur : Unite_Du_Capteur; Valeur_actionneur : Unite_actionneur; Valeur_erreur : Unite_erreur; begin Valeur_Capteur := acquisition_capteur;

Valeur_erreur := Calcul_erreur(La_consigne_du_systeme, Valeur_Capteur);

Valeur_actionneur := Calcul_commande(Valeur_erreur, La_consigne_du_systeme);

Appliquer_la_commande_sur_actionneur (Valeur_actionneur);

delay until prochaine_echeance; end; end select; end loop boucle_de_regulation; or Terminate; end select; end loop : generale; end Regulation_Du_Systeme;

Quelques explications :Notre tâche possède une boucle générale. Cette boucle possède un premier select qui ne peut

recevoir qu’un signal « démarrer », tant qu’on a pas envoyé ce signal, la tâche reste bloquée surce select. L’alternative « Terminate » est pris en compte lorsqu’aucun processus n’est susceptiblede solliciter les entrées de la tâche (quand le programme principal est terminé).

Une fois l’appel d’entrée « démarrer » effectuée par un élément externe, on rentre dans laboucle de régulation et on rencontre un select. On peut alors solliciter l’entrée « arrêter » de latâche ou l’entrée « fournir_une_consigne ». Si personne ne fait appel à ces entrées (pas derendez-vous), la tâche exécute alors le code alternatif, indiqué par « else ». Pour implémenter lapériodicité, on utilise la date système du calculateur. On commence donc par calculer l’échéanceau bout de laquelle, un pas de régulation doit être effectué. Ce calcul est simple : la prochaineéchéance c’est l’instant présent + la période. Une fois les opérations effectuées sur le système,

14

on « attend » jusqu’à la prochaine échéance. On sort du « select » et on se retrouve au début dela boucle de régulation et la tâche attend un rendez-vous sur les entrées « arreter » et« fournir_une_consigne » ou exécute le code alternatif. On remarque qu’une fois la tâchedémarrée, on peut appeler n’importe quand l’entrée « arrêter » ou « fournir_une_consigne » même si la tâche exécute le code alternatif. Ceci est possible grâce au système de file FIFOplacée à chaque entrée de la tâche. Quand la tâche sera prête à accepter les rendez-vous« arrêter » ou « fournir_une_consigne », elle prendra en compte l’élément de la file.

Quand on fait appel à l’entrée « fournir_une_consigne », un élément externe peut venirmodifier la consigne du système en modifiant une variable interne de la tâche. Une fois le rendez-vous fini, elle retourne au select de la boucle_de_regulation.

Quand on fait appel à l’entrée « arrêter », on sort de la boucle de régulation, et la tâche peutsoit accepter l’entrée « démarrer » ou bien se terminer (Terminate) si le programme principal estlui-même terminé.

Remarque : si la tâche est dans la boucle de régulation à la terminaison du programmeprincipal, elle ne meurt pas ! Elle n’offre aucune instruction « terminate ». Donc le processus esttoujours actif. Donc il faut faire attention à arrêter la tâche avant de terminer le programmeprincipal.

Notons la simplicité avec laquelle on a abouti à la solution finale. Serait-il possible de réaliserune entité VxWorks similaire de façon aussi « simple » et portable ?

• Les objets protégés en Ada95 :

Un objet protégé possède, comme un paquetage ou une tâche, un corps et une spécificationdistincts. La spécification fournit le protocole d’accès et le corps fournit les détails d’implantation.

La spécification d’un objet protégé est elle aussi divisée en une partie visible et une partieprivée. La partie visible contient les spécifications des sous-programmes d’entrée du protocole. Lapartie privée contient les données partagées cachées et aussi les spécifications tous les autressous-programmes et entrées qui sont privés pour l’objet. Les sous-programmes et entréesdéclarés dans la spécification (aussi bien partie visible que partie privée), sont appelés desopérations protégées. Contrairement aux paquetages et tâches, le corps d’un objet protégé nepeut déclarer aucune donnée. Il ne peut contenir que les corps de ses opérations protégées ainsique des sous-programmes déclarés localement. Toutes les données doivent se trouver dans lapartie privée de la spécification.

Prenons un exemple simple d’une variable protégée :

-- spécificationprotected variable is procedure Lire (X : out Element) ; procedure Ecrire (X : in Element);private V : Element := valeur_initiale;end Variable;

15

-- corpsprotected body Variable is procedure Lire (X : out Element) is begin X := V; end Lire;

procedure Ecrire (X : in Element) is begin V := X; end Ecrire;end Variable;

L’objet protégé « Variable » fournit des accès contrôlés à la variable privée V. La procédure« Lire » nous permet de lire la valeur courante tandis que la procédure « Ecrire » nous permet demettre à jour la variable. Les appels s’écrivent de façon habituelle en utilisant la notationpointée :

Variable.Lire(Valeur_Courante);…Variable.Ecrire(Nouvelle_Valeur);

A l’intérieur d’un objet protégé, nous pouvons avoir plusieurs sous-programmes etl’implémentation est telle que les appels des sous-programmes se font en exclusion mutuelle etne peuvent donc interférer les uns avec les autres. On a donc un système à « jeton ».

Dans l’exemple ci-dessus, les sous-programmes peuvent toujours être exécutés dès que lejeton est libre. Parfois, cependant, certains appels ne peuvent pas êtres traités, mais doiventattendre une certaine condition. Pour cela on utilise des « entrées protégées » qui ont toujoursdes conditions d’accès. La syntaxe d’un corps d’entrée est semblable à celle d’un corps deprocédure à part qu’elle doit toujours avoir une barrière consistant en un when suivi d’unecondition. Quand une entrée est appelée, sa barrière est évaluée. Si sa barrière est fausse, alorsla tâche appelante est mise en file d’attente jusqu'à ce que des circonstances fassent que labarrière soit vraie. Le jeton est libéré pour permettre à d’autres tâches d’appeler pendant cetemps l’objet partagé.

16

Prenons l’exemple du sémaphore. Imaginons qu’une ressource ne puisse servir que Nutilisateurs à la fois, on implémente l’accès à cette ressource avec un objet protégé de type :

N : constant positive := 8;

protected Semaphore is entry obtenir ; entry liberer ;private Compteur : Natural := N;end Semaphore;

protected body Semaphore is

entry obtenir when compteur > 0 is begin Compteur := compteur – 1; end obtenir;

entry liberer when compteur < N is begin Compteur := compteur + 1; end liberer;

end semaphore ;

Ici la ressource possède 8 places, donc on ne peut pas implanter le système voulu à l’aide desous-programmes. En effet on ne peut pas indéfiniment incrémenter ou décrémenter lecompteur. Ainsi à l’aide des barrières, on limite le nombre de places à N. On ne pas obtenir laressource si les N places sont prises. La requête est placée en file d’attente et attend qu’une placese libère (compteur > 0). On met une garde sur l’entrée « libérer » afin de pas pouvoir créer deplaces. Car au démarrage rien ne nous empêcherai, sans la barrière, d’incrémenter la barrière etd’avoir N + 1 places libres. La barrière sur l’entrée « libérer » permet donc de limiter le nombrede places.

Le sémaphore par objet protégé est l’exemple type de ce qu’il ne faut pas faire, car l’objetprotégé inclut le concept de sémaphore.

• Précautions au développement en natif :

Le développement en natif n’est possible que si les deux environnements sont semblables, ilfaut que la machine de développement et la machine d’exécution aient la même implémentationdu multi – tâches.

Une mise à jour de la version Linux des PC104 s’est imposée, car la version installée était àbase d’un noyau Linux 2.2, qui n’implémentait donc pas le multi-tâches de la même manière quele PC de développement à base de noyau 2.4. Nous avons alors installé la distribution Slackware9.0 à base d’un noyau 2.4 sur les deux machines PC104. Les deux environnements sontmaintenant identiques et permettent le développement en natif.

3.2 La méthode de conception « HOOD »

La méthode HOOD a été développée à la demande de l'Agence Spatiale Européenne poursoutenir ses développements dans des langages de haut niveau tels que Ada, et plus récemmentC++. Après des années d'utilisation et d'améliorations successives, elle culmine aujourd'hui avecla version 4 qui intègre tous les concepts modernes de programmation orientée objet. Son cadre

17

d'utilisation s'est étendu à de nombreux domaines industriels, notamment dans les transports,l'énergie, le nucléaire, le spatial et militaire.

HOOD est une méthode complète, textuelle et graphique, qui guide les phases de conception,spécifie les documents associés, intègre les aspects dynamiques des applications, supporte ledéveloppement de systèmes répartis, et permet la liaison directe et réversible avec le codeproduit. Ses domaines de prédilection sont les gros projets industriels, à connotation temps-réelet à longue durée de vie. Grâce aux nombreux environnements de développementcommercialement disponibles, la méthode est maintenant utilisée dans tous les domaines del'industrie.

Les principaux objectifs de la méthode sont la conception de grands logiciels en Ada, depermettre un développement réparti et d’intégrer l’aspect temps-réel des applications par ladécomposition modulaire, la définition précise des interfaces et les relations fonctionnelles.

HOOD fait appel à différents concepts :

- L’abstraction : elle permet de ne représenter que certains aspects pertinents dusujet et permet de ne presque pas considérer les problèmes d’implantation.

- L’encapsulation : elle permet le regroupement dans un même ensemble deséléments les plus interdépendants. L’encapsulation permet de gérer un compromisentre une simplification par décomposition, et minimisation des couplages parregroupement.

- Le masquage d’information : il permet de représenter l’information seulement là oùelle est nécessaire. Le masquage d’information permet de contrôler la portée et lavisibilité de chaque entité et de minimiser les effets de bord.

- Le couplage : c’est la dépendance résiduelle entre sous-ensembles de l’application.Les couplages doivent être gérés par des choix de conception, et ne pas être larésultante de décisions d’implémentation.

- La réutilisation.

La méthode de conception HOOD 4 offre au concepteur la représentation des modèles àplusieurs niveaux d’abstractions. Pour un système complexe, la méthode permet de démarrer laconception à des niveaux très hauts d’abstraction puis de descendre dans les couches de notremodèle pour arriver au système opérationnel complet.

Cette méthode permet de faire des versions intermédiaires du logiciel qui implémenterasuccessivement les couches du système jusqu’aux drivers des équipements et ainsi de valider lesdifférents modèles.

Une première étape de conception consiste en l’abstraction en termes d’objets des couchesles plus hautes du modèle. Les éléments d’implémentation sont ignorés. Donc c’est uneconception indépendante de la cible, du langage de programmation et de la répartition. Cecipermet d’avoir une conception globale, claire dans l’esprit du concepteur / développeur. Cettepremière conception constituera les invariantes du logiciel et on se référera toujours à cetteabstraction logique et cohérente.

Puis on affinera la conception pour modéliser les couches les plus basses en prenant encompte les contraintes de la répartition, les contraintes des équipements ainsi que les possibilitésdu langage. La méthode HOOD permet réellement de maîtriser la complexité du système etconstitue un véritable outil d’aide à la conception.

18

L’organisation d’un projet HOOD se présente sous la forme d’un module général(System_Configuration) englobant tous les autres modules. Le System_Configuration permet dedéfinir une organisation opérationnelle du projet, de déterminer les contours du domaine devisibilité, d’exprimer précisément les ressources externes.

Le logiciel est décomposé en modules. Chaque module a des composants élémentaires :- composants fonctionnels (Operation, Exception)- composants structurels (Type, constant, Data)- composants comportementaux (Obcs).

Un module est une représentation de tout ou d’une partie de l’application, il est constitué soitd’autres modules (module non terminal), soit de composants logiciels élémentaires comme desdrivers d’équipements (module terminal).

Une application HOOD peut être représentée sous la forme d’un arbre de décomposition.Chaque niveau de décomposition correspond à un niveau d’abstraction pour la description del’application. Les niveaux intermédiaires sont des « coquilles vides ». Ce concept de coquillesvides permet de déléguer l’implantation des services fournis par un module parent vers sesenfants et assure la transmission des spécifications jusqu’à l’implantation.

Dans la suite de ce paragraphe je ne vais pas présenter de manière exhaustive tous lescomposants de la méthode mais je vais me contenter de présenter les caractéristiques généralesdes opérations, ce qui donne une bonne vision de la philosophie HOOD.

Les opérations sont les éléments fonctionnels des modules. Elles se traduisent en codage pardes procédures ou des fonctions. Le comportement externe d’un module se perçoit par laréactivité de ses opérations publiques. Les contraintes liées aux opérations d’un module décriventses caractéristiques comportementales. Les principales contraintes rencontrées dans le cadre demon stage étaient les contraintes liées au protocole entre l’appelant et l’appelé d’une opération liéà un module. Ce sont le plus souvent des contraintes de synchronisme. Ces contraintespermettent d’exprimer les aspects temps réel de l’application.

Le passage de paramètres dans les opérations est le seul moyen d’échanger des donnéesentre deux modules.

La manière dont un module répond aux différentes activations de ses opérations contraintes,est décrite dans un OBCS (OBject_Control_Structure). L’OBCS gère toutes les contraintes,qu’elles soient liées à l’état interne du module ou aux protocoles utilisés pas les appels. L’OBCSpermet de découpler les caractéristiques comportementales et les propriétés pûrementprocédurales traitées dans les OPCS (OPeration Control Structure).

Les contraintes par protocole traitent les différents cas suivants :- communication synchrone : HSER- communication faiblement synchrone : LSER- communication asynchrone : ASER

La contrainte HSER : L’appelant reprend son activité si l’appelé a terminé l’opérationdemandée :

19

Figure-4 communication HSERLa contrainte LSER : L’appelant reprend son activité si l’appelé a pris en compte la requête.

Puis l’appelant attend un compte rendu de fin d’exécution :

Figure-5 communication LSER

La contrainte ASER : L’appelant poursuit son activité indépendamment de celle de l’appelé,l’appelant attend un compte rendu de fin d’exécution :

Appelant Appelé

Inactif

Autre activité

Actif

Prise en compte

Requête

Prise enCompte

OK

Finexécution

Appelant Appelé

Inactif

Autre activité

Actif

Prise en compte

Requête

Finexécution

20

Figure-6 communication ASER

Au début de mon stage je n’étais pas vraiment familier des méthodes de conception, maisHOOD m’a réconcilié avec la conception de haut niveau, ce n’est plus pour moi du formalismecontraint mais un véritable outil de conception et une aide à la vision globale de l’applicationfuture.

J’utilise l’outil STOOD de TNI qui offre un environnement complet de conception graphique,textuel et de génération de code. Cependant l’outil STOOD présente quelques désavantages :

- l’outil ne gère pas les paquetages fils Ada95.- la génération de code des OBCS implémentant les communications de

synchronismes (ASER, HSER, LSER) n’est pas satisfaisante.- la génération de code de tâches à fortes contraintes temps-réel comme les tâches

cycliques (fonction HRT HOOD) est lourde et inefficace.

3.3 Le modèle de répartition du langage Ada95

Une application distribuée est un ensemble de processus communicants, chacun de cesprocessus peut s’exécuter sur des machines différentes. Les machines étant connectées à unréseau.

La norme Ada95 [ADA95RM] offre la technologie de répartition par son Annexe E. Mais tousles compilateurs Ada n’offrent pas l’implantation de cette Annexe. Cette annexe est implémentéepar le compilateur GNAT-GLADE 3.15.

Chaque processus est appelé « partition », cette entité exécute une partie de l’application.Chaque unité de bibliothèque (paquetage Ada95) est attribuée à une ou plusieurs partitions.

On peut attribuer à une partition les différents paquetages qu’elle va exécuter, mais cetteattribution ne se fait pas sans contraintes.

Un calculateur peut exécuter plusieurs partitions.

La répartition permet tout d’abord de distribuer la charge de calcul sur plusieurs calculateurs,de faire appel à des services offerts par des paquetages distants (sur une autre partition sur uneautre machine). Typiquement prenons l’exemple concret de deux unités (U1 et U2) de notrelogiciel qui ont besoin de produire des signaux analogiques via une seule carte de sortieanalogique. Ces deux unités ne peuvent pas s’exécuter sur la même machine pour des problèmesde temps de calculs trop importants et de ce fait ne satisfont pas les contraintes temps-réel. On

Appelant Appelé

Inactif

Autre activité

Actif

Prise en compte

Requête

Finexécution

21

décide donc d’exécuter ces deux unités sur deux calculateurs différents pour répondre auxexigences. Mais nous disposons que d’une seule carte de sortie donc présente physiquement quesur une seule machine ! Les services offerts par la carte seront implémentés par un paquetage« la_carte_de_sortie_analogique » et constituera l’accès à cette carte. On décide alors de fairedeux partitions :

- P1 (sur la machine 1 ou se trouve notre carte) constitué de U1 et du paquetage« la_carte_de_sortie_analogique ».

- P2 (sur la machine 2 sans carte) constitué de U2.

Quand l’unité U1 veut utiliser la carte il fait appel au paquetage local, et quand U2 situé surl’autre machine veut faire appel à la carte, les couches de communication de glade remplissentleur rôle et mettent tout en œuvre au niveau des communications réseaux pour que le servicesoit rendu. Ceci est tout à fait « transparent » pour les unités appelantes et appelées.

Seule une unité catégorisée offre les services de la répartition. Pour catégoriser un paquetageon utilise des « pragmas ». Quatre pragmas sont mis à notre disposition :

- pragma Pure : L’unité de bibliothèque à laquelle s’applique ce pragma est garantiesans effet de bord et ne conserve aucun état interne (pas de variables globales dansle corps). Elle contient typiquement des définitions de types simples et lesopérations primitives applicables sur ces types. Une telle unité de bibliothèque peutêtre répliquée sur toutes les partitions sur lesquelles elle est référencée. Ce type decatégorisation n’est pas propre à la répartition et se révèle utile dans d’autrescontextes.

- pragma Shared_Passive : L’unité de bibliothèque à laquelle s’applique ce pragmane contient que des objets partagés et aucun flot de contrôle. Les variables définiesdans la partie publique de sa déclaration sont accessibles depuis plusieurs partitionsà travers un support partagé éventuellement réparti. Une telle unité ne peut êtrerépliquée.

- pragma Remote_Types : L’unité de bibliothèque à laquelle s’applique ce pragmane contient, dans la partie publique de sa déclaration, que des types transportables.Elle peut définir des références sur entités distantes mais aussi dériver des typesétiquetés susceptibles d’être désignés par ces références. Une telle unité peut êtrerépliquée sur toutes les partitions sur lesquelles elle est référencée.

- pragma Remote_Call_Interface (RCI) : L’unité de bibliothèque à laquelles’applique ce pragma peut contenir dans la partie publique de sa déclaration destypes transportables comme des références sur entités distantes mais égalementdes sous-programmes distants. Dès lors, une telle unité ne peut être répliquée.Cette restriction s’explique par la présence éventuelle de sous-programmes distantsdont la localisation doit être statique.

Pour éviter toute incohérence, tout pragma de catégorisation doit respecter la hiérarchiesuivante : Remote_Call_Interface > Remote_Types > Shared_Passive > Pure, où la relationpragma 1 > pragma 2 signifie qu’une unité de bibliothèque catégorisée avec pragma 1 peut avoirune visibilité sur une unité de bibliothèque pragma 2. Ainsi une unité Remote_Types peut êtrevisible depuis une unité Remote_Call_Interface mais une unité Remote_call_interface ne peutêtre visible d’une unité Remote_Types. De plus une unité catégorisée ne peut avoir de visibilitésur des unités non catégorisées, ce qui entraîne des contraintes fortes pour catégorisercorrectement les bons paquetages avec la bonne catégorisation. Ces contraintes ne s’appliquentqu’aux fichiers de spécification Ada (fichiers .ads), nous avons les mains libres dans le fichier« corps » du paquetage (fichier .adb) sauf dans les paquetages catégorisés « Pure »(règle à ne jamais perdre de vue). Ainsi, la spécification d’un paquetage catégorisé n’a pas devisibilité sur un paquetage non-catégorisé, mais le corps du paquetage peut tout à fait avoir lavisibilité sur ce paquetage non-catégorisé. Il faut toujours se poser la question si on a réellement

22

besoin de la visibilité de chaque paquetage (utilisés dans l’ensemble du paquetage (spécification+ corps)) dans la spécification.

Pour catégoriser une unité de bibliothèque, il faut que la spécification du paquetage soitpréélaborable (un paquetage préelaborable est un paquetage dont toute l’élaboration peut avoirlieu à la compilation). Ceci nous interdit de déclarer dans la spécification du paquetage destâches, des types étiquetés ainsi que des pointeurs sur sous-programmes. En effet, ces objetsnécessitent qu’une partie de l’élaboration soit repoussée à l’exécution. Mais rappelons que nousavons les mains libres dans le corps du paquetage. Pour remédier au problème des tâches nousdevons donc déclarer notre tâche dans le corps du paquetage. Mais comment un paquetageexterne va-t-il pouvoir faire appel aux entrées de cette tâche ? Il suffit d’encapsuler les appelsd’entrées de cette tâche dans une procédure qui elle pourra être déclarée dans le fichier despécification. C’est cette procédure qui fera appel l’entrée de la tâche. Cette procédure n’estqu’une interface entre le monde externe du paquetage et la tâche. La procédure possède lesmêmes paramètres d’appel que l’entrée correspondante pour que l’ensemble soit cohérent.

La catégorisation présente une autre difficulté. Un paquetage a souvent besoin de la visibilitésur des paquetages élémentaires souvent très utiles comme par exemple le paquetageAda.Calendar qui fournit des services de manipulation des variables de temps (calculd’intervalles, datation d’événements …), mais ce paquetage n’est pas catégorisé, donc il ne peutêtre visible d’aucun paquetage catégorisé. Comment faire ? Il suffit de réécrire ce paquetage sousune forme catégorisée. Nous avons réécrit le paquetage Ada.Calendar sous la formeGrandeurs_physiques.temps_de_base. Ils ont exactement la même spécification à un détail prèset non des moindre : Grandeurs_physiques.temps_de_base est catégorisé par unpragma Remote_types. Dans le corps de ce paquetage, on fait appel au paquetage Ada.Calendar.

Prenons l’exemple

Fichier Grandeurs_physiques.temps_de_base.ads :

package Grandeurs_physiques.temps_de_base ispragma Remote_Type;

…

function Clock return time; -- Rmq : on aura précédemment défini un type Time… -- compatible avec le type Time Ada.Calendar.

end Grandeurs_physiques.temps_de_base;

fichiers Grandeurs_physiques.temps_de_base.adb

with Ada.Calendar;

package body Grandeurs_physiques.temps_de_base is

…

function Clock return time isbegin return Ada.Calendar.Clock;end Clock;…

end Grandeurs_physiques.temps_de_base;

23

Pour le développement de telles applications, rien ne différencie une application répartied’une application non répartie, à part la catégorisation. Les appels distants sont gérés par lacouche réseau de glade et ne nécessite aucune intervention du programmeur. Quel est le moyenpratique pour distribuer nos paquetages dans les différentes partitions ? Comment faire unepartition ? Ceci se fait grâce à un fichier de configuration de l’application qu’il faudra passer enparamètre au compilateur. On peut décomposer notre application en différentes partitions,décomposition qui peut être faite à la guise du programmeur.

Les principales fonctions du fichier de configuration sont de définir :

- les partitions.- de quels paquetages sont composés les partitions.- sur quelle machine sera exécuté chaque partition.- de localiser le programme principal.- Le protocole (tcp ou udp) et le port de communication réseau.- Le mode de démarrage des partitions.

Pour mieux comprendre comment se déroule la définition du fichier de configurationreprenons notre exemple précédent et écrivons le fichier de configuration. Pour que l’exemple soitplus représentatif, nous allons ajouter à notre application un paquetage définissant des typesgénéraux (par exemple de grandeurs_physiques : Volt, mètre …). Nos 3 paquetages (U1, U2 etla_carte_de_sortie_analogique) ont besoin de la visibilité du paquetage grandeurs_physiquesdans leur spécification. Donc il faut catégoriser ce paquetage ! On le catégorise Remote_types,car il déclare de simples types avec des opérations élémentaires. Nous avons aussi unprogramme principal appelé « Mon_application_répartie ». Voici le diagramme des dépendancesde notre application :

24

Figure-7 diagramme de dépendances d’exemple d’une application répartie

Nous disposons de deux machines : machine_1 et machine_2. On décide de faire 4partitions :

- partition main contenant seulement le programme principal.- partition p_U1 contenant U1.- partition p_U2 contenant U2.- partition p_carte contenant la_carte_de_sortie_analogique.

La carte se trouve sur la machine_2. On répartit nos partitions sur les deux machines :

- partition main sur machine_1.- paritition p_U1 sur machine_1.- partition p_U2 sur machine_2.- partition p_carte sur machine_2.

On décide pour la communication entre les partitions le protocole TCP et le port decommunication 5557.

Voici le fichier de configuration glade mon_application.cfg :

Configuration mon_application is

-- mode de démarrage des partitions (démarrage manuel): pragma Starter(None);

Mon_application_répartie(programme principal)

Paquetage U1Remote_call_interface

Paquetage U2Remote_call_interface

la_carte_de_sortie_analogiqueRemote_call_interface

Grandeurs_physiquesRemote_types

25

-- définition du protocole(tcp) et du port (5557)de communication pragma Boot_server ("tcp","machine_1:5557");

-- définition des composantes de la partition main main : Partition := (Mon_application_repartie);

-- définition des composantes de la partition p_U1 p_U1 : Partition := (U1);

-- définition des composantes de la partition p_U2 p_U2 : Partition := (U2);

-- définition des composantes de la partition p_carte p_carte : Partition := (la_carte_de_sortie_analogique);

-- localisation du programme principal Procedure lv_nacelle_bord is in p_main;

-- affectation des partitions aux machines (Nom DNS) for main'Host use "machine_1"; for p_U1'Host use "machine_1"; for p_U2'Host use "machine_2"; for p_carte'Host use "machine_2";

end mon_application;

On peut maintenant compiler notre application avec la commande :« gnatdist mon_application.cfg ». Le compilateur crée donc 4 exécutables correspondants aux

4 partitions que l’on doit exécuter sur les machines appropriés. Comme nous avons choisi undémarrage manuel nous devons lancer les 4 applications « à la main ». L’application commenceralorsque toutes les partitions sont démarrées et se seront connectées entre-elles.

Comment un paquetage fait appel à un paquetage distant ? Que fait génère le compilateur ?Je ne vais pas décrire la totalité du système de communication glade pour plus de détails voir[PAUTET, 2001] et [SEUMA-VIDAL, 2002].

Pour un paquetage catégorisé Remote_Call_interface, le compilateur gnatdist génère unpaquetage « Receiver » qui sera chargé de prendre en compte les requêtes des unités distantestransportées par le réseau. Ce paquetage est dans la même partition que le paquetage catégoriséRemote_Call_interface. Ce paquetage passera ainsi les requêtes au paquetageRemote_Call_Interface. Pour chaque paquetage ayant besoin des services d’un paquetageRemote_Call_interface, glade place dans la partition du paquetage « client » un paquetage ayantla même spécification que le paquetage Remote_call_interface distant mais un corps depaquetage différent qui lui, entrera en communication avec le paquetage « Receiver » distant.Pour le paquetage demandant le service c’est donc transparent !! Puisque pour lui tout se passecomme un appel local.

Reprenons notre exemple pour la communication entre le paquetage U1 sur la machine_1 etle paquetage la_carte_de_sortie_analogique sur la machine_2 :

26

Figure-8 schéma de principe d’appel de service d’une unité distante

Quand le paquetage U1 veut utiliser la carte de sortie analogique, elle utilise un service dupaquetage la_carte_de_sortie_analogique Remote_Call_interface. Quand dans le paquetage U1on écrit la_carte_de_sortie analogique.Sortir_un_signal(De => 2.0, Sur_la_voie => 1) (ce quiveut dire que l’on veut produire un signal d’une tension de 2 volts sur la voie 1 de la carte), lepaquetage U1 fait appel au paquetage la_carte_de_sortie_analogique « client » (appel_local). Lepaquetage client va émettre une requête au paquetage « serveur » via le réseau. Le paquetageserveur va transmettre cette requête au paquetage la_carte_de_sortie dit « normal » qui lui vafaire les opérations sur la carte. Ceci confirme le couplage par le matériel.

Ceci termine le chapitre sur les travaux préalables à la conception et au développement dulogiciel de vol. Le temps réel Ada95, la méthode Hood et la répartition sont les pilierstechnologiques et méthodologiques du futur logiciel de vol. Ces trois piliers permettent au logicielde bord de doter d’une fiabilité, d’une modularité, d’une souplesse de développement et d’unetechnologie informatique peu coûteuse.

Paquetage U1 Paquetagela_carte_de_sortie_analogique

2 - Application répartie

Paquetage U1

Paquetagela_carte_de_sortie_analogique

« client »

Paquetagela_carte_de_sortie_analogique

« normal »

Paquetagela_carte_de_sortie_analogique

« serveur »

Partition p_U1 sur machine_1 Partition p_carte sur machine_2

Interface réseau tcp

1 - Application non répartie

27

4. Travail effectué

Ce chapitre décrit comment, à partir des spécifications et des choix technologiquesprécédemment cités, je suis arrivé au démonstrateur final du logiciel de vol.

Une première partie évoquera les spécifications du logiciel de vol et analiser les types defonctions à implémenter dans le démonstrateur pour qu’il soit représentatif d’un logiciel de vol denacelle.

Puis je présenterai la phase de conception HOOD dans son ensemble qui aboutira à un logicielsans interfaces matérielles.

Je présenterais les différents tests et réalisation de drivers, d’équipements qui vont êtreintégrés au logiciel de vol.

Enfin je présenterai les fonctions de télémesures et de télécommandes qui ont été trèsprésentes tout au long de la réalisation de la maquette, et qui font l’interface entre la nacelle et lastation sol. La station sol, elle, utilise un logiciel sol que je présenterai rapidement.

4.1 Les fonctions d’un logiciel de vol

Le logiciel de vol a principalement trois catégories de fonctions :• les fonctions de servitudes et de gestion bord (contrôle thermique, contrôle

alimentation électrique, communication avec le sol, localisation et temps),• les fonctions de pointage de la charge utile,• des fonctions de contrôle général qui coordonnent les actions de la nacelle.

Le logiciel de bord doit avant tout être flexible vis-à-vis de la variété des missions desnacelles pointées.

Toutes les fonctions du logiciel de vol sont détaillées dans [LAURENS, 2004].

4.1.1 Les fonctions de servitudes et de gestion bord

Tout au long d’une mission, le logiciel doit acquérir des mesures sur des capteurs afin dedonner au sol l’observabilité de l’environnement (température, pression, altitude …) et lapossibilité de surveiller les organes vitaux de la nacelle (alimentation générale, des calculateurs,des instruments …).

• Surveillances thermiques :

Le logiciel de vol doit acquérir en permanence des mesures de températures via des capteursrépartis sur les organes nacelle. Il transforme les valeurs brutes d’acquisition en valeursphysiques (°C). Les valeurs de température doivent être acquises à la fréquence de 1/30 Hz etenvoyées au sol.

• Surveillances électriques :

Le logiciel de vol doit mesurer des tensions et des intensités sur le système d’alimentationélectrique qui distribue l’énergie aux équipements de la nacelle. Ces acquisitions sont effectuées àune fréquence de 1 Hz.

Le logiciel de vol effectue à la demande des commutations de bus en actionnant des relais,par l’intermédiaire de cartes d’entrées - sorties logiques. Il doit acquérir périodiquement (1 Hz)les états logiques des relais à l’aide de cartes d’entrées logiques. Cette fonction doit pouvoir

28

donner à la demande les états des différents relais. Ces surveillances électriques seront, ellesaussi, envoyées vers le sol.

• Base de temps et localisation :

Pour avoir des repères temporels et géographiques, les nacelles pointées utilisent unrécepteur GPS qui fournit ces information sous la forme d’un message par liaison série cadencé à1 Hz contenant la date et l’heure TU (exprimée dans une échelle de Temps Universel propre ausystème GPS), la position de la nacelle (latitude, longitude et altitude) et les vitesses associéesainsi que diverses informations sur la qualité de la réception des signaux satellites. La référencede temps est utilisée pour recaler la base de temps du logiciel. Toutes ces informations serontémises en télémesures. La base de temps et la localisation sont très importants pour que le solsache où est la nacelle, mais elles servent surtout à effectuer des calculs astronomiques pourcalculer les coordonnées d’objets célestes comme le soleil ou des étoiles.

4.1.2 Les fonctions de pointage pour les instruments

Le principal service offert par une Nacelle pointée est comme son nom l’indique de maintenirdans une position ou vers un astre, des instruments de mesures scientifiques. Les coordonnéesd’un astre est défini selon deux angles dans le repère terrestre : azimut et élévation :

Figure 9 – Angles d’azimut et d’élévation d’un astre

Comment orienter un instrument scientifique ? :

Nord

Azimut

Elévation

29

Figure-10 système de pointage d’un instrument

Le pivot contrôle l’angle d’azimut et le vérin l’angle d’élévation.

Selon les besoins en précision des différentes missions, le système de pointage aura un oudeux étages :

- un étage de pointage primaire qui a pour rôle d’orienter grossièrement l’instrumentvers la direction souhaitée. Deux axes sont pilotés (l’azimut et l’élévation ) ou unseul (l’azimut). La précision recherchée doit être d’environ 0.1 °.

- Un étage de pointage fin qui est destiné à pointer l’instrument avec une grandeprécision. Les précisions espérées dont de l’ordre de la seconde d’arc.

Pour mener à bien sa mission de pointage, le logiciel de vol a bien évidemment besoin decapteurs, d’actionneurs et de boucles de régulation.

Pour le pointage primaire, les capteurs principaux sont :

- le magnétomètre : mesurant l’angle d’azimut de la nacelle par rapport au nordmagnétique utilisé pour le pointage primaire,

- des gyromètres : mesurant la vitesse de rotation autour de l’axe sur lequel il estplacé,

Pivotd’azimut

Plancher de lanacelle

Vérind’élévation

Plateau desupport

Instrument

Nord

Angle d’élévation

Angle d’azimut

30

- des inclinomètres : mesurant l’angle par rapport à l’horizon locale de l’équipementsur lequel il est placé.

et les actionneurs principaux sont :

- un pivot motorisé : oriente la nacelle en azimut (utilisé pour le pointage primaire)- des roues à inertie : appliquent un couple sur l’axe nacelle ou la charge utile sur

laquelle elles sont placées,- vérins à vis : oriente en élévation la charge utile en s’appuyant sur la nacelle.

Un système de pointage est généralement composé de deux fonctions : le contrôle et leguidage.

Le contrôle est destiné à maintenir le système à une consigne donnée. C’est donc uneboucle fermée de régulation à une période d’échantillonnage donnée. Pendant cette période lecontrôle doit acquérir les différentes mesures sur les capteurs, si besoin est, de calculer desmesures (calcul de la vitesse par dérivation de la position), élaborer l’erreur (consigne – mesure),élaborer la commande sur le ou les actionneurs en fonction de l’erreur et enfin appliquer cettecommande sur le ou les actionneurs.

Le guidage a pour rôle d’élaborer des consignes de pointage à partir d’une consigneexterne, comme par exemple « Pointer le soleil ». Le guidage doit donc réactualiser les consignesqu’il transmet au contrôle. Le guidage inclut aussi les calculs astronomiques, car pour pointer lesoleil, il faut bien sûr sans cesse recalculer les coordonnées de l’astre qui « bouge » par rapport àla nacelle pour obtenir une bonne précision. La direction du soleil vu d’un point situé dans unrepère lié à la Terre peut être exprimée selon deux angles (azimut, élévation) dans le repèrelocal. Ces angles varient dans le temps et dans l’espace du fait de la rotation de la Terre. Pourêtre très précis, les consignes de position des astres doivent être actualisées toutes les 100 ms.

4.1.3 Un contrôleur nacelle pour orchestrer le tout

Le contrôleur nacelle est le module qui va coordonner les actions de la nacelle. Il vérifieque chaque commande envoyée par le sol est recevable dans l’état de fonctionnement de lanacelle. Pour le démonstrateur nous n’aurons seulement que quatre états de fonctionnement :

Le démonstrateur ne va pas posséder tous les modes de contrôles d’un logiciel de volopérationnel, mais va implémenter les modes principaux :

- un mode veille où aucun contrôle en azimut et élévation ne sera effectué. Lesmodules de contrôle en élévation et en azimut ne produiront que des mesuresenvoyées au sol et le guidage sera inactif.

- un mode de pointage en azimut où seul le contrôle en azimut sera actif. Le contrôlede pointage en élévation lui ne produira que des mesures et le guidage sera inactif.

- Un mode de pointage altazimutal où les deux contrôles sera actif. Les consignesd’élévation et d’azimut seront fournies par le sol (télécommande) et le guidage serainactif.

- Un mode de pointage du soleil où les deux contrôles seront actifs. De plus leguidage effectuera des calculs astronomiques pour générer des consignes vers lesmodules de contrôles correspondants aux coordonnées du Soleil.

Le démonstrateur ne va donc pas implémenter le pointages des autres objets célestes, nile mode de pointage azimut à 90° du cap.

On observe donc que les contrôles en azimut et élévation ont deux états : mode« mesures » et mode « pointage ».

31

Les passages entre les différents états répondent au graphe d’état suivant :

Figure-11 graphe d’état de des modes de fonctionnement

En plus de gérer ces quatre modes de fonctionnement de la nacelle, le contrôleur nacelledoit aussi démarrer tous les modules du logiciel de vol (Localisation, élément de servitudes …). Ildoit aussi communiquer avec le module de réception des télécommandes, car c’est le contrôleurnacelle qui enverra les ordres des actions à effectuer vers les modules concernés si latélécommande est compatible avec l’état de la nacelle.

4.1.4 Les télémesures et les télécommandes

• Le module de télémesures (TM) :

Chaque module du logiciel de vol peut constituer des paquets de télémesures que lemodule de TM se chargera d’envoyer vers le sol. Le premier rôle de ce module est d’emballer lespaquets dans des trames de télémesure, puis d’émettre les octets constituant ces trames sur lavoie de liaison série affectée à la télémesure, et ce sans protocole particulier. En effet, onn’implémentera pas de protocole particulier pour s’assurer que le sol a bien reçu les trames de TMcar la TM est extrêmement redondante donc ce n’est pas vital que tous les paquets arriventjusqu’à la station sol. Des coupures de transmissions sont tolérables.

Son deuxième rôle est de stocker les paquets TM dans des fichiers bord en vue d’unerécupération après le vol. Ces fichiers sont organisés par tranches horaires, par exemple unfichier représentera 1 heure de télémesure. Sachant que la télémesure est stockée au sol pour

Veille

Pointageen azimut

Pointagealtazimutal

Pointagesoleil

TTCC ppooiinntteerr aazziimmuutt((ccoonnssiiggnnee aazziimmuutt))

TTCC MMeettttrreeeenn vveeiillllee

TTCC ppooiinntteerr aazziimmuutt ((vvaalleeuurraazziimmuutt))

TTCC ppooiinntteerr aazziimmuutt eett éélléévvaattiioonn((ccoonnssiiggnnee aazziimmuutt,, ccoonnssiiggnnee

éélléévvaattiioonn))

TTCC MMeettttrreeeenn vveeiillllee TTCC ppooiinntteerr aazziimmuutt eett éélléévvaattiioonn

((ccoonnssiiggnnee aazziimmuutt,, ccoonnssiiggnneeéélléévvaattiioonn))

TTCC MMeettttrreeeenn vveeiillllee

TTCC ppooiinntteerrssoolleeiill

TTCC ppooiinntteerr aazziimmuutt((ccoonnssiiggnnee aazziimmuutt))

TTCC ppooiinntteerr aazziimmuutt eett éélléévvaattiioonn((ccoonnssiiggnnee aazziimmuutt,, ccoonnssiiggnnee

éélléévvaattiioonn))

32

dépouillement et rejeu, l’intérêt de ce stockage est d’avoir toute la télémesure au cas où descoupures de transmissions auraient été trop importantes.

Chaque fonction du logiciel de vol envoyant des données au sol doit constituer des paquetsd’information homogènes sur le plan sémantique et temporel. Le rôle du paquet TM est derassembler, pour le transport optimal, des paramètres ayant ces points communs. Les critères deregroupement à respecter sont :

- fonctionnels : les différentes mesures ont des points communs, même types degrandeurs physiques (ex : température) ou même provenance (ex : un mêmeéquipement)

- temporels : mesures acquises ou fabriquées en même temps et/ou à la mêmefréquence (ce qui permet de n’indiquer qu’une date pour toutes les mesures dupaquet).

- Organisationnels : séparer les mesures relatives à des équipements, systèmes oufonctions toujours présents quelle que soit la mission, de celles relatives à deséquipements optionnels ou spécifiques d’une mission.

Un paquet TM a donc une structure variable, constituée :

- d’un identificateur permettant de reconnaître le paquet et d’en discriminer lastructure

- d’une datation, toujours présente (jours, mois, année, heures, minutes, secondes,centièmes) en temps universel

- d’une structure de données contenant les mesures et formats variables.

Les paquets TM, vus alors comme une suite d’octets, sont emballés dans une trame ayantla structure suivante :

- 2 octets de synchronisation (0x0B, 0xFF)- 1 octet donnant la longueur du paquet en octets- les octets constituant le paquet- 2 octets de fin de trame (CR, LF)

Les octets constituant cette trame sont envoyés via une liaison série sur le système ETNA.C’est le logiciel sol qui devra reconnaître l’emballage de trame, traiter les cas d’erreur éventuels,extraire le paquet. Ceci est valable que si la liaison bord-sol est une interface série, ce qui est lecas actuellement. Mais dans un futur proche, un projet de liaison IP bord-sol est à l’étude. Dansce cas, le paquet sera directement émis sur la voie par un socket UDP (conservation d’unecommunication sans protocole particulier).

• Le module de télécommandes (TC)

Le module de télécommande reçoit les octets sur l’interface de liaison série affectée à latélécommande, reconnaît les trames TC et fournit le paquet TC au contrôleur nacelle.

D’une manière symétrique à la télémesure, chaque ordre de télécommande à transmettreà bord est encodé sous la forme d’une structure de données constituée :

- d’un identifiant d’ordre- des paramètres éventuels de l’ordre (en nombre et formats variables).

Un paquet TC, vu comme une suite d’octets est emballé dans une trame ayant unestructure analogue à celle des trames TM :

- 2 octets de synchronisation (0x07, 0xCC)- 1 octet constituant un compteur modulo 256

33

- 1 octet constituant la longueur du paquet TC en octets- les octets constituant le paquet- 2 octets de fin de trame.

Quand un paquet TC est envoyé depuis le sol, la fonction de réception de ces paquetsdevra opérer un certain nombre de contrôles pour assurer une transmission de bout en boututilisant un compteur de trame et un système d’acquittement en TM. Le module de TC entretientun compteur de trames bord, le logiciel émet un paquet TM d’acquittement indiquant :

1- si la trame reçue est correcte et que le compteur porté par la trame reçue est conformeau compteur de trame bord, le module TC émet un paquet TM d’acquittementindiquant :

- trame reçue OK- séquence compteur de trames OK- n° de la prochaine trame attendue

2- si la trame reçue est correcte mais que les compteurs de trames ne concordent pas,c’est qu’il y a eu perte de trames. Le module TC remet donc un paquet d’acquittementindiquant :

- trame reçue OK- rupture de séquence compteur de trames- n° de la prochaine trame attendue

3- si la trame reçue n’est pas correcte (par contrôle des mots de synchronisation début etfin) le module TC émet un paquet d’acquittement :

- trame reçue erronée- séquence compteur de trame indéfinie- n° de la prochaine trame attendue

La délivrance à l’automate du paquet TC contenu dans la trame et la progression ducompteur de trames bord ne se font que si l’acquittement est positif (1er cas).

Toujours dans l’optique de l’évolution future d’une liaison bord-sol IP, les paquets TCseront envoyés à travers un socket IP de protocole « TCP ». Les acquittements par la TM avec unsystème de compteur n’auront plus lieu d’être car le protocole TCP assure la liaison de bout enbout.

La Télémesure et la Télécommande sont des fonctions très importantes et primordialesdans les missions de nacelles pointées. Je parlerais dans le paragraphe 4.5 de l’importance de cesfonctions et du logiciel sol recevant les TM et envoyant les TC. La TM/TC est véritablement uneinterface entre les scientifiques, les opérateurs et la nacelle.

4.2 La phase de conception générale HOOD

Après m’être familiarisé avec les outils et les technologies, et avoir pris connaissance ducahier des charges et des exigences du logiciel de vol, j’ai pu commencer la phase de conceptionavec l’outil Stood de TNI.

Dans la conception, on peut considérer la répartition par les nœuds virtuels HOOD. Unobjet peut être alloué à un nœud virtuel. Chaque nœud virtuel peut être alloué à un nœudphysique correspondant à un calculateur. On peut faire la correspondance entre un nœud virtuelet une partition GNAT-GLADE 3.15.

La première étape de conception est de mettre le logiciel de vol dans son environnement.Dans la figure-1, nous nous positionnons sur la couche la plus haute : « loi de fonctionnement dumonde ». A cette couche du monde réel nous faisons correspondre dans le monde logiciel tous les

34

paquetages Ada95 déjà réalisés qui implémentent les calculs astronomiques, servant à calculerbon nombre de coordonnées d’objets célestes comme le soleil. Nous pouvons aussi inclure danscette couche les paquetages Ada95 qui implémentent toutes les unités de Grandeurs physiques(angles, température, distance, mécaniques …) ainsi que toutes les fonctions de conversionsentre les unités. Ainsi nous pouvons mettre en place le « SYSTEM_CONFIGURATION » modulegénéral englobant l’ensemble du logiciel de vol et son environnement en vue « opération » :

Figure-12 Environnement HOOD du logiciel de vol.

Les objets externe au logiciel de vol son appelés les objets d’environnementl’environnement.

Les flèches indiquent que le logiciel de vol utilise les opérations de l’objetgrandeurs_physiques et de l’objet Calculs astronomiques. On remarque aussi une flèche quiindique que les calculs astronomiques utilisent aussi les opérations de grandeurs physiques. Lelogiciel de vol possède deux opérations qui peuvent être sollicitées par l’extérieur : « démarrer »et « arrêter ». L’entrée « démarrer » sera utilisé en début de mission au démarrage ducalculateur. L’entrée arrêter sera elle utilisé en fin de vol.

Rentrons dans la structure détaillée du logiciel de vol. Nous devons donc inclure lesmodules généraux : l’automate principal (contrôleur nacelle), le système de pointage, le modulede contrôle TM/TC, le guidage et le module de localisation GPS – base de temps. Il faut aussidéfinir les interfaces entre les modules, comment vont-ils communiquer ? Quels types de donnéesvont-ils échanger ? Quelle est la dynamique de chaque module ?

35

Voici la structure générale de conception du logiciel de vol :

Figure-13 Structure générale du logiciel de vol

On observe sur le schéma que tous les modules élémentaires d’un logiciel de vol sontprésents. La méthode HOOD permet de décomposer et de synthétiser les fonctions du logiciel enmodules généraux. Ceci nous permet de concevoir les modules un à un avec différents niveauxd’abstractions, en ayant une vue hiérarchique.

36

• Le contrôleur nacelle :

Le contrôleur nacelle démarre tous les modules de la nacelle et les arrête tous. Donc lemodule lv_nacelle délègue l’implantation des procédures démarrer et arrêter au le contrôleurnacelle :

Figure-14 Les fonctions arrêter et démarrer du logiciel de vol.

Le contrôleur nacelle n’aura comme interfaces que les opérations « démarrer » et« arrêter ». Il interagit avec le module de contrôle TM/TC afin de collecter les TC. Il fait appel auservice « recevoir_TC » du module de TM/TC qui lui fournira le paquet de télécommande ou luienverra un message « Time_out » s’il n’a rien reçu. L’automate vérifiera si la TC est applicabledans l’état de la nacelle. Le contrôleur possède une tâche cyclique afin d’acquérir l’état de lanacelle (veille, pointage azimut, pointage altazimutal et pointage soleil) et l’enverra au sol via unpaquet de télémesure.

37

• Le contrôleur TM/TC :

Le contrôleur TM/TC sera démarré et arrêté par le contrôleur nacelle. Ce module contient 2modules fils : un module de voie de télémesures (Voie_TM) et un module de voie detélécommandes (Voie_TC). Ces modules élémentaires peuvent être aussi réutilisés dans le logicielsol ceci dans un souci d’homogénéité des deux logiciels. Donc les modules de voie_TM et voie_TCimplémentent la réception et la réception des TM et TC. Mais dans le logiciel de vol seulesl’émission de TM et la réception de TC seront utilisées. Quand le contrôleur nacelle démarre lecontrôleur TM/TC, ce module démarre le module de voie TM pour l’émission et démarre le modulede voie TC pour la réception :

Figure-15 Structure du module de contrôle TM/TC.

Il est à noter que le service envoyer_TM est un échange de message asynchrone, carchaque module qui enverra un paquet TM ne devra pas attendre que le module de Voie_TMtermine l’émission du paquet. Le module client du module contrôleur TM/TC enverra sa requête etne s’occupera pas du bon envoi de son paquet de télémesures. Les deux modules implémententaussi un système de « Time out » sur les deux voies de communication. Ces Time out sontréalisés à l’aide d’exceptions Ada95 récupérées par le contrôleur nacelle. Quand le contrôleurnacelle sollicite l’entrée « recevoir_TC », le contrôleur TM/TC renverra au contrôleur nacelle lestrois paramètres :

- si effectivement il y a eu une TC envoyée par le sol,- le paquet- si le compteur de trame bord correspond à la valeur du compteur dans la trame.

Chacun des deux modules possède deux tâches l’une pour l’émission l’autre pour laréception.

• Le guidage :

Le guidage, à la demande du contrôleur nacelle, sera démarré ou arrêté. Lorsque leguidage est démarré il envoie au module de pointage les consignes d’azimut et d’élévation del’astre pointée. Le contrôleur nacelle devra donc au démarrage indiquer au guidage de quel astre

38

faut il qu’il calcule les coordonnées. Une fois les calculs effectués, il enverra ses résultats vers lemodule de pointage. Le guidage fait appel aux modules externes de calculs astronomiques et degrandeurs physiques ainsi qu’au module de localisation GPS – base de temps.

Le guidage est composé d’une tâche cyclique d’une période de 100ms. A chaque période, ilfait appel au module de localisation GPS – base de temps afin d’acquérir la localisation (Latitude,longitude et altitude) et la date. Avec ces données il calculera les coordonnées (azimut, élévation)de l’astre que devra pointée l’instrument.

• Le pointage :

Avec ce module, on passe à la couche inférieure de notre modèle en couches :« algorithme de contrôle ».

Le pointage comprend deux modules fils : le module de pointage en azimut et le modulede pointage en élévation. Ils sont indépendants, mais très semblables. Chacun possède deuxmodes de fonctionnement : un mode mesure et un mode pointage. Quand on démarre chacundes deux modules, ils sont en mode mesure. On peut passer en mode pointage avec les servicesrallier_azimut (module pointage azimut en mode pointage) ou rallier_elevation (module pointageélévation en mode pointage). On peut repasser les modules indépendamment en mode mesurepar le service passer_en_mode_mesure_elevation et passer_en_mode_mesure_azimut.

Les entrées seront sollicitées par le contrôleur nacelle pour passer dans les différentsmodes de la nacelle (schéma paragraphe 4.1.3).

Les entrées pour fournir une consigne (rallier_élévation et rallier_azimut) seront aussisollicitées par le module de guidage pour pointer l’astre. Il appartient au contrôleur nacelle dedécider qui fourni les consignes (guidage ou contrôleur nacelle).

Les modules utiliseront bien sûr le module externe de grandeurs physiques et le module decontrôle de TM/TC ainsi que le module de base de temps – localisation GPS pour dater leurspaquets de télémesures.

Les deux modules de pointage interfacerons des équipements et on passera encore à unecouche inférieure de notre modèle.

Ici le module pointage est une coquille vide qui relègue tous ces services à ces deuxmodules fils.

Figure-16 Structure du module de pointage

39

Les deux modules de pointages possèdent une tâche cyclique d’une période de 100 ms quiferont un asservissement de position et de vitesse en azimut ou en élévation

• La localisation GPS – base de temps :

Le module de localisation GPS – base de temps est démarré et arrêté par le contrôleurnacelle. Il possède deux services :

- « fournir la localisation » utilisé par le guidage pour calculer les coordonnéesd’astres en fonction de la position courante de la nacelle.

- « fournir datation » utilisé par tous les modules générant des paquets detélémesures pour pouvoir dater précisément ces paquets.

Il utilise bien sûr le module de grandeurs physiques comme quasiment tous les modulesdu logiciel de vol.

Ce module est composée d’une tâche qui va acquérir les trames via une liaison sérieenvoyée par le GPS. Il recalera l’horloge système toutes les 4 trames afin d’avoir une bonneprécision de la datation des paquets de télémesures et des calculs astronomiques.

• Le contrôleur servitudes :

Le contrôleur servitudes sera démarré et arrêté par le contrôleur nacelle et offrira desservices « Lire_Etat_relais », « Mettre_le_relais_a_l_Etat », « Lire_tension_bus »,Lire_température » avec des paramètres de numéro de relais et numéro de bus. Il va acquérirpériodiquement les états des relais et des tensions bus et enverra des paquets de télémesurespour renseigner le sol sur l’état de la nacelle. Ce module est composé de 3 modules fils :

- Un module de contrôle thermique qui effectuera l’acquisition de températures surdifférents capteurs. Ce module est composé d’une tâche cyclique d’une période de30s et fournira à la demande la valeur d’un capteur de température voulu. Lalecture des capteurs se fera via une carte d’entrées analogiques.

- Un module de contrôle d’alimentation qui acquiert les tensions et courant desdifférents bus d’alimentation. Ce module possède une tâche cyclique d’une périoded’1s et fournira à la demande l’état des bus. La lecture des tensions se fera via unecarte d’entrées analogiques

- Un module de contrôle des relais qui effectuera l’acquisition de l’état des différentsrelais par une tâche cyclique d’une période d’1s. Il fournira à la demande l’état d’unrelais et peut mettre à la demande d’un autre module un relais à un état voulu. Lamodification et l’acquisition des états des relais se fait grâce à une carte d’entréesortie analogique.

Le module contrôleur nacelle est une « coquille vide » qui relègue tous ses services à sestrois modules fils.

On peut maintenant avoir une vue très claire de la structure du logiciel de vol à partir del’outil STOOD et entamer le développement en Ada95 des différents modules.

4.3 Tests et développement de drivers pour entrer dansle monde réel

Une fois le squelette de l’application réalisé intégrant tous les modules, on veut pouvoirinterfacer du matériel, communiquer avec un logiciel sol, acquérir des mesures réelles, contrôlerun moteur. Pour cela j’ai dû tester et développer des drivers pour différentes interfaces. FrédéricPORTES, stagiaire précédent, et mon maître de stage, André LAURENS, ont déjà développé bon

40

nombre de drivers (cartes entrées sorties logiques, analogiques, contrôle de moteur). Pourcommuniquer avec le logiciel sol deux interfaces doivent être développées liées au type demedium utilisé :

- interface réseau IP via un socket dans l’optique d’une future liaison bord-sol IP. Pourcette interface, on utilise AdaSocket, une bibliothèque Ada développée par SamuelTARDIEU membre de l’association Ada-France. Cette bibliothèque intègre la gestiondes protocoles TCP et UDP pour la transmission bord-sol.

- interface par liaison série actuellement utilisée. J’ai développé une interface en Adapour utiliser le driver Linux écrit en C. Cette interface série sera utilisée pourimplémenter le protocole de communication bord-sol décrit dans le paragraphe4.1.4.

4.3.1 Le socket IP avec AdaSocket

Dans l’optique d’une future liaison bord-sol IP, j’ai développé et testé une interfaced’échange de données par Socket IP. Un socket IP est un canal de communication entre deux ouplusieurs machines connectées à un réseau IP utilisant un protocole de communication. Pour cecij’ai utilisé la bibliothèque AdaSocket de Samuel TARDIEU dont la documentation est disponible[TARDIEU, 2004].

La bibliothèque propose les deux protocoles de communication IP les plus courantes UDP(User Datagram protocol) et TCP (Transmission Control Protocol).

TCP est un protocole dit « connecté », c’est à dire qu’à l’ouverture de la connexion lesdeux entités communicantes dialoguent pour établir la communication. Des paquets de donnéesenvoyés en TCP sont assurés d’arriver jusqu’à leur destinataire. Le protocole implémente unsystème d’acquittement entre les communicants, un système de retransmission des paquetsmanquants par l’émetteur. Ce protocole est particulièrement bien adapté pour l’envoi destélécommandes de la nacelle. TCP remplacera donc le protocole utilisant le systèmed’acquittement actuel utilisant les compteurs de trames.

UDP est un protocole dit « non connecté », c’est à dire que les deux entitéscommuniquantes ne dialoguent pas à l’ouverture de la communication. Un paquet de donnéesenvoyé en UDP n’est pas assuré d’arriver jusqu’à son destinataire. L’émetteur des données ne sesoucie pas de la bonne délivrance des paquets au récepteur. C’est un protocole très léger,beaucoup moins exigeant pour le système d’exploitation que le protocole TCP. UDP estparticulièrement adapté au transfert de la télémesure, en effet TCP serait trop contraignant car levolume d’envoi de télémesure obligerait au logiciel de vol d’envoyer des données dues auprotocole trop importantes.

Pour créer un socket pour un émetteur de données, il faut associer au socket un port decommunication et un nom de destinataire. Pour un récepteur il suffit de lui spécifier le port surlequel il va recevoir des données.

Les détails de la création de sockets sont disponibles dans l’annexe 2.

En Ada95, la création de sockets est prise en charge par la bibliothèque AdaSocket. Le fluxde donnée entrant ou sortant est représenté par un « stream ». La lecture sur le socket se faitgrâce à la fonction « Write » et l’écriture grâce à la fonction « Read ». L’avantage du « stream »est que la conversion entre un flux de bits en une valeur typée est automatique.

• Intégration au logiciel de vol :

J’ai réalisé quelques programmes de tests (émetteurs et récepteurs) échangeant plusieurstypes de données (chaînes de caractères, structures de données plus complexes (record Ada95)).

41

J’ai testé ces petits programmes entre plusieurs machines (machine de développement <->PC104) (PC104 <-> PC104). Je n’ai rencontré aucune difficulté particulière. Ces programmesétaient compilés avec GNAT 3.15.

J’ai donc intégré ce système de communication au logiciel de vol dans les modules de voiede télémesures et de télécommande. Les calculateurs PC104 intègrent une interface réseauEthernet et possèdent une adresse IP associée à un nom de machine et sont connectés au réseaulocal du CNES. Les couches basses réseaux (couche MAC et protocole IP) sont prises en chargepar le système d’exploitation Linux. Les couches UDP et TCP sont donc prises en charge par labibliothèque AdaSocket.

J’ai donc réalisé un logiciel sol très simplifié permettant de recevoir les paquets detélémesures par protocole UDP et d’émettre des paquets de télécommandes par protocole TCP.Ce logiciel sol est compilé avec GNAT - GLADE 3.15.

Pourquoi compiler le logiciel sol qui est une application non répartie avec GLADE ? Uneprécision importante est à apporter à la communication par socket entre une application répartieet une application non répartie. AdaSocket utilise les « streams » Ada95 pour gérer les flux dedonnées. Mais GLADE offre une implémentation évoluée de ce service car il implémente ladistribution d’applications sur des machines hétérogènes (machines Motorala et Pentium parexemple), donc les échanges de flux de données doivent s’adapter pour remédier àl’hétérogénéité des machines. Si les deux applications communiquent par socket, elle doiventdonc avoir la même implémentation des « streams » Ada95, donc les deux applications bord etsol sont compilées avec GLADE.

4.3.2 La liaison série

La liaison série est utilisée de plusieurs manières dans le logiciel de bord :- L’envoi de données sur le système ETNA.- Réception des données GPS.- Réception et émission de données sur des équipements.

Linux offre un driver de liaison série « termios » offrant tous les services nécessaires. Lesfonctions de ce driver sont écrites en langage C.

Il faut donc créer un paquetage Ada95 « interface » vers ce driver. La bibliothèque« termios » est destiné à l’utilisation de la liaison série en mode canonique, c’est à dire àl’utilisation des fonctionnalités « terminal UNIX» avec échange de données de contrôlenombreuses et variées. Dans notre cas nous n’avons besoin que d’échanges de données brutes(sous forme d’octets). Ce paquetage facilite l’utilisation de cette librairie, par le fort typage Adades registres de configuration. Par exemple un registre de N bits où chaque bit représente unparamètre de configuration, est représenté par un record de N booléens dont le nom de chaquechamp est évocateur du paramètre correspondant. Ce paquetage doit être flexible, on doitpouvoir paramétrer la vitesse de transmission, le nombre de bits de données, le nombre de bitsde stop, si l’on veut recevoir ou émettre des données, le contrôle de flux (Matériel, XON/XOFF aupas de contrôle de flux), le nom du port de communication (COM1, COM2 …). J’ai donc utilisé unpaquetage générique Ada95 offrant toutes ces possibilités. Le paquetage offre donc une meilleurefacilité d’utilisation de la liaison série que l’utilisation directe de « termios ».

Pour interfacer le driver « termios », il faut donc faire appel à des fonctions écrites enlangage C. Ada95 propose ce service par le pragma « Import » qui autorise l’appel de fonctionsdans un langage différent. On déclare une fonction Ada95 puis on lui applique ce pragma enspécifiant le langage et le nom de la fonction.

La seule fonction du driver « termios » que j’ai dû utiliser est la fonction « Setattr » quipermet de configurer le composant (physique) gérant le port série. Il faut passer en paramètre unpointeur sur une structure de données décrivant le mode de fonctionnement (vitesse de

42

transmission, contrôle de flux …). J’ai recréé cette structure de données avec un record Ada95modifié en fonction des paramètres d’instanciation du paquetage générique.

Une fois l’appel de la fonction « setattr », le composant est prêt à émettre ou à recevoirdes données en fonction des paramètres établis.

Le port série est accessible en lecture ou en écriture par un fichier « device » Linuxcorrespondant à chaque port COM (COM1 -> /dev/stty0, COM2 -> /dev/stty1 …).

L’accès à ces fichiers spéciaux de périphériques se fait de la même manière qu’un accèsvers un fichier dit « normal ». On utilise les fonctions « open », « close », « read » et « write » dela bibliothèque « stdio » écrite en C.

Ce paquetage générique (liaison_serie.une_liaison) ne permet que d’envoyer ou derecevoir un flux d’octets sur le port série.

Mais pour pouvoir envoyer des données typées Ada95 (record …), il faut transformer cesdonnées en octets à l’aide du paquetage générique « Unchecked_Conversion ». Ce paquetagepermet de convertir des données d’un type Ada95 vers un autre type, ces types occupant lamême taille mémoire. A l’aide de ce paquetage on crée une fonction de conversion d’unestructure de donnée en un champ d’octets prêt à être émis. Comme son nom l’indique lepaquetage « unchecked_conversion » n’effectue aucun contrôle sur la conversion. Il appartient àl’utilisateur de vérifier si la conversion est cohérente.

De même pour la réception, il faut convertir le flux d’octets reçu pour récupérer lastructure de données envoyée initialement. On crée alors une fonction réciproque de la fonctionde conversion émettrice à l’aide du paquetage « unchecked_conversion » qui convertit un fluxd’octets en données typées Ada95.

Il faut aussi pouvoir envoyer et recevoir des données par un protocole donné (mot desynchronisation de début, de fin, envoi de longueur des données utiles) comme par exemple lestrames de télémesures, de télécommandes (voir paragraphe 4.1.4). Ceci fait l’objet d’undeuxième paquetage générique ayant comme paramètres les mots de synchronisation, le type dedonnées échangées, si on envoie ou non la taille des données, si la trame possède un compteurou non … Ce paquetage va utiliser le paquetage « liaison_serie.une_liaison » implémentant lesfonctionnalités « bas niveau » et aura donc aussi en paramètres génériques les options de vitessede transmission, contrôle de flux … etc. Ce paquetage prend à son compte les conversions entredonnées typées et flux d’octets.

Une fois l’interface complète de liaison série réalisée, j’ai donc pu l’appliquer, comme pourle socket IP, à l’échange de paquets de télémesures et de télécommandes entre le logiciel sol etle logiciel bord avec le protocole de communication décris au paragraphe 4.1.4.

Les voies d’échanges entre bord et sol possèdent donc maintenant deux moyens decommunications : socket IP ou liaison série. Le type de medium utilisé par les voies de TM/TC estdonc maintenant paramétrable.

4.3.3 Des cartes entrées-sorties analogiques etlogiques

Pour pouvoir acquérir des signaux analogiques émanants de capteurs, acquérir destensions de bus pour les servitudes électriques, envoyer des signaux analogiques à desactionneurs, acquérir des état logiques de relais, mettre les relais dans des états logiques voulus,le logiciel de vol utilise différents modèles de cartes :

43

- Une carte d’entrées analogiques avec convertisseur analogique -> numérique 12bits PCM A/D 12.

- Une carte de sorties analogiques avec convertisseur numérique -> analogique12 bitsPCM D/A 12.

- Une carte d’entrée sortie logiques PCM 3724.- Une carte d’entrées sorties analogiques avec deux convertisseurs 12 bits PCM AIO.

André LAURENS a réalisé des drivers pour les différents types de cartes, mais ne les avaitpas testés.

J’ai donc du écrire des programmes de tests pour les différentes cartes pour vérifier le bonfonctionnement des cartes et des drivers.

• Test de la carte d’entrées analogiques PCM A/D 12:

La carte propose différents modes de conversions pour différents signaux (0/5V ou –10V/+10V)

Pour produire des signaux analogiques j’ai utilisé un générateur produisant une tensionentre –10V et +10 V directement connecté aux ports de la carte.

Le programme de test est une boucle infinie qui acquiert la tension sur un port donné àl’initialisation du programme. Différents modes d’acquisition sont proposés par le driver. On peutsoit acquérir directement la valeur en Volt ou bien acquérir une valeur « brute » 12 bits produitepar le convertisseur. En fait la carte ne délivre que la valeur 12 bits et c’est le driver qui calculela valeur en Volt. Le programme fait appel aux deux modes d’acquisition.

Pendant ces phases de tests, j’ai été confronté à des problèmes matériels. Leconvertisseur de la carte a besoin d’une alimentation +12V (pour la conversion 0 – 5V) nondélivrée par la carte PC104 ou d’une alimentation -15V / +15V (pour la conversion –10V / +10V)fournie par un convertisseur optionnel sur la carte dont nous ne disposions pas. Nous avonsdécidé de remplacer le convertisseur optionnel par un générateur –15V / +15 V en connectant legénérateur à l’emplacement du convertisseur absent.

• Test de la carte de sorties analogiques PCM D/A 12:

Le même problème s’est posé sur ce type de carte (convertisseur optionnel absent etbesoin d’une tension d’alimentation +12V et –15/+15V). La carte est fortement similaire à lacarte PCM A/D 12. Après avoir décortiqué le schéma électrique de la carte, nous avons conclu quela même méthode devait être utilisée pour résoudre le problème. Mais malgré tous nos efforts, lacarte ne délivrait aucun signal de sortie. Le driver me paraissait correct. J’ai même utilisé unprogramme fourni par le constructeur mais le problème est resté entier. A ce jour le problème n’apas été résolu.

• Test de la carte d’entrées - sorties analogiques PCM AIO:

Nous avons tout de suite étudié le schéma de la carte et nous nous sommes renduscompte que la carte exigeait une tension de +12V délivrée par le bus PC104 que nous nedisposions pas. Comme la carte ne proposait pas de convertisseur optionnel, nous ne pouvionspas alimenter la carte par un générateur externe. La carte est donc inutilisable avec laconfiguration actuelle de la carte PC104.

44

• Conclusions et décisions prises à la suite de ces tests :

Après ces tests de cartes analogiques, André LAURENS a décidé d’acheter les cartes PCMA/D 12 et PCM D/A 12 proposant un convertisseur 5V -> -15V/+15V. Et des cartes convertisseursproduisant une tension +12V sur le bus PC104.

• Test de la carte d’entrées - sorties logiques PCM 3724:

Pour pouvoir tester cette carte, j’ai réalisé un petit montage simple permettant d’utiliserles entrées et sorties logiques.

Pour tester les sorties, j’ai connecté une LED (Diode Electro-Luminéscente) afin de voirl’état de la sortie. L’état diode est aussi connecté à une entrée logique pour pouvoir acquérir sonétat (test des entrées). Ceci dans l’optique de similarité de surveillance des relais des nacellespointées : pouvoir agir sur le relais en connaissant son état logique. L’état de la LED ne peut êtremodifié qu’à la demande de l’utilisateur dans le programme test.

Puis j’ai connecté un interrupteur 2 positions à une entrée logique. Selon la position del’interrupteur, l’état de l’entrée logique est à 1 ou 0. Ceci pour simuler un changement d’état noncontrôlé par l’utilisateur.

Le programme n’a révélé aucun problème particulier.

• Intégration au logiciel de vol.

J’ai donc pu intégrer ces fonctionnalités dans le logiciel de vol au niveau du module desservitudes.

Le module de servitudes électriques acquiert périodiquement (1s) la tension sur un port dela carte d’entrées analogiques. Ce port étant connecté à un générateur simulant le busd’alimentation. Un paquet de télémesure est envoyé par socket IP ou par liaison série.

J’ai reproduit ce schéma pour acquérir une valeur de température. Un générateur simule lesignal analogique dont la tension est proportionnelle à la température mesurée. Cette acquisitions’effectue toutes les 30 secondes par le contrôleur de servitudes thermiques qui envoie ensuiteun paquet de télémesures.

L’accès à la carte se fait via un objet protégé pour éviter dans l’avenir qu’un conflit se créeentre deux entités voulant avoir accès à la carte. La carte peut délivrer une acquisition aprèsl’autre et ne peut faire des opérations simultanées. On peut envisager d’implémenter des driversà base d’objets protégés évitant les conflits sans que l’utilisateur du driver se soucie des conflitséventuels.

Le module de contrôle des relais acquiert les états de la LED et de l’interrupteur toutes lessecondes, produit un paquet de télémesure et l’envoie via le module de contrôle TM/TC. A l’envoid’une TC de type « changer l’état de la LED », la voie de TC reçoit ce paquet, le transmet aucontrôleur nacelle et fait appel au contrôleur de servitudes des relais qui effectue l’opération : sil’état de la LED est à 1, il fait passer son état à 0 et inversement.

De même que pour la carte d’entrées analogiques, l’accès à la carte d’entrées – sortieslogiques est contrôlé par un objet protégé.

45

4.4 Intégration d’équipements ou comment réaliser unemaquette représentative

Pour que la maquette du logiciel de vol soit représentative d’un logiciel opérationnel, il fautqu’un minimum d’équipements réels soient interfacés. J’ai pu disposer d’un récepteur GPSMotorola avec une antenne et d’un vérin à moteur électrique contrôlant l’angle d’élévation de lacharge utile. Par contre, il a été nécessaire de simuler certains équipements pour la boucle decontrôle en azimut : un capteur, le magnétomètre qui restitue l’angle d’azimut, et un actionneur,le pivot d’azimut.

4.4.1 Le GPS

Le GPS (Global Positioning System) permet d’avoir une information précise sur la positionde la nacelle servant pour les calculs astronomiques.

Un boîtier à base d’un microprocesseur Motorola acquiert les signaux reçus des satellitesafin de calculer la position précise, mais aussi des vitesses de déplacement (vitesse Nord – Sud,Est – ouest et vitesse verticale), le cap du mobile ainsi qu’une multitude d’informations (Nombrede satellites visibles, précision …). Le GPS délivre possède aussi une horloge précise qui servirade base de temps au logiciel de vol. Le microprocesseur envoie ces informations sur une liaisonsérie RS232 sous formes de trames commençant par les caractères « @@Ea » et finissant par« CR,LF ».

Pour acquérir ces informations, j’ai donc réutilisé mon paquetage générique implémentantun protocole de trames avec des mots de synchronisation de début et de fin de trame. Ladocumentation du module Motorola délivre la composition des trames. Un stagiaire précédent(Frédéric PORTES) avait déjà réalisé un programme d’acquisition de ces trames. J’ai modifié ceprogramme en remplaçant l’ancien driver de liaison série par le mien en y ajoutant monpaquetage de lecture de trames.

Cependant la base de temps délivrée à l’intérieur de la trame n’était pas totalement traitéepar ce programme. Le programme ne décodait pas les centièmes de seconde de l’horloge. Lechamp représentant les centièmes de seconde est un nombre entre 0 et 999 999 999représentant 0 à 99 centièmes de secondes. Et quand j’ai lu cette partie de la trame, le nombre lupouvait être supérieur à 999 999 999. D’où cela pouvait-il provenir ? Les processeurs Motorolautilise la convention « Big Endian » alors que les processeurs de type « Pentium » comme leprocesseur de la carte PC104 utilise la convention « Little Endian ». Cette convention indiquecomment les mots sont stockés en mémoire. En « Big Endian », le poids fort en tête suivi dupoids faible, alors qu’en « Little Endian », le poids faible précède le poids fort :

Figure-17 Conventions Big et Little Endian

Le processeur Motorola envoie donc d’abord le poids fort et ensuite le poids faible. Quandon fait la conversion d’un flux de bits en une valeur sur un processeur de type Pentium, il faut

Poids fort Poids faible

Adresse I Adresse I +1

Big Endian :

Poids fortPoids faible

Adresse I Adresse I +1

Little Endian :

46

donc renverser le poids fort et le poids faible. Les valeurs des centièmes sont tout de suite pluscohérentes.

Dans le logiciel de vol, l’acquisition des trames du GPS se fera dans une tâche (environ 1trame toute les secondes), et fournira à la demande la dernière localisation envoyé par GPS.Cette tâche recale la date de l’horloge système (toutes les 4 trames, donc environ toutes les 4secondes) à l’aide de la date précise délivrée par le GPS. Ce recalage se fait à l’aide de l’appelsystème « date » qui permet de régler la date et l’heure de l’horloge. La partition Glade quicontiendra ce module devra s’exécuter en tant que « root » sur la machine Linux, car seull’administrateur de la machine est autorisé à modifier l’horloge.

4.4.2 Le vérin d’élévation

Un vérin est utilisé pour contrôler l’axe d’élévation de l’instrument de mesure, c’est unvérin à moteur électrique muni d’un codeur incrémental. Le moteur est contrôlé par une carteANDI-Servo dont le driver a été développé par André LAURENS.

Le driver offre de commander la carte en position ou en vitesse. Pour contrôler le moteur,il faut tout d’abord programmer son PID et les trajectoires de vitesse et d’accélération.

Dans le cas du vérin d’élévation, on contrôle le moteur en position. A une position dumoteur donnée, correspond une position du vérin. On commande le moteur en position en luifournissant une consigne en nombre de tops homogène à la mesure fournie par le codeur. Endéfinissant une position d’origine, on peut fournir une position de consigne absolue.

Pour se situer dans le domaine de l’application, la fonction de transfert à mettre en placedans le logiciel, consiste à convertir des tops codeur en tours moteur, puis en longueur de vérin ;de là, en tenant compte de la géométrie du montage mécanique vérin + plateau porte –instrument, on peut convertir la longueur vérin en angle d’élévation. La fonction de transfertinverse est nécessaire à l’élaboration de la consigne.

Le vérin est muni de deux butées extrêmes pour limiter les déplacements de la tige.Chaque butée génère un signal logique (0-5V). Si la tige atteint une butée, le signalcorrespondant est à 0V sinon, le signal est à 5V :

Figure-18 Vérin d’élévation

Les signaux logiques générés par les deux butées sont connectés à deux entrées logiquesde carte PCM3724 en vue d’acquérir l’état des butées.

Pour tester le bon fonctionnement du vérin, de la carte ANDI-Servo, j’ai réalisé un petitprogramme afin de commander le vérin en position avec la gestion des butées. Seulement, lesdeux cartes utilisées (ANDI-Servo et PCM3724) ne sont pas sur la même machine. Plutôt que dedémonter les cartes, j’ai opté pour une application répartie. Le module devant acquérir l’état desbutées est un paquetage « remote_call_interface » pouvant être appelé depuis le programmeprincipal de contrôle du vérin depuis l’autre machine. Encore un exemple des avantages et de lafacilité de mise en œuvre de la répartition avec GLADE.

Butées àsignaux logiques

Moteur + codeur

47

J’ai dû ensuite intégrer l’ensemble de l’équipement (Carte ANDI-SERVO, vérin, butées)dans le logiciel de bord afin de contrôler l’angle d’élévation dans le module de pointage enélévation. Les consignes angulaires donné au module de pointage (par le guidage ou bien par unetélécommande) sont transformés en consigne de position du vérin en millimètres, puis en nombrede tours de moteurs, puis en nombre de tops passés à la carte ANDI-Servo.

Le contrôle des butées, se fait grâce à une tâche qui acquiert l’état des butées sur la cartePCM3724 pendant les mouvements du vérin. Si une butées est détectée, cette tâche arrêteimmédiatement le moteur.

La carte ANDI-Servo offre un certain nombre de services comme de lire la positioncourante du vérin en nombre de tops, lire la consigne courante. Donc à l’aide de la positioncourante en top transformée en angle, on connaît l’angle d’élévation de l’instrument.

Dans un logiciel de vol opérationnel, on ajoute à cette commande, une boucle derégulation utilisant un inclinomètre pouvant lire directement l’angle entre l’axe horizontale et leplan de l’instrument. Ceci nous délivrant l’angle d’élévation. Dans le démonstrateur, l’inclinomètren’est pas utilisé car je ne dispose pas du plateau support de l’instrument ni de toutes lesstructures de la nacelle.

4.4.3 Simulation d’équipements

Afin d’avoir un logiciel de vol représentatif des principales fonctionnalités d’un logiciel devol opérationnel, on peut simuler des éléments de la nacelle. Pour avoir une fonctionnalitécomplète de pointage, j’ai simulé le fonctionnement du contrôle de l’angle d’azimut.

C’est une simulation très simple mais qui permet de conserver la même dynamique del’objet « contrôle pointage azimut » qu’il soit réel ou simulé.

La simulation consiste à simuler un capteur et un actionneur. La régulation se fait avecune période de 100ms. On fournit à l’objet contrôle en azimut une consigne. A chaque pas derégulation, la tâche acquiert une mesure d’azimut (0° initialement) puis calcul l’erreur avec laconsigne, élabore une commande et l’applique à un objet pivot représentant le pivot d’azimut.L’objet pivot n’est pas actif, mais il intervient sur l’objet du capteur comme si en réalitél’actionneur avait un impact sur le monde réel et le capteur observe cet impact.

La simulation fait en sorte qu’à chaque pas de régulation, l’angle augmente ou diminue de0,1° selon le sens de la consigne. On aurait pu simuler des capteurs des actionneurs par descalculateurs externes, envoyant recevant des signaux analogiques, logiques ou par liaison sérievia les cartes d’entrées sorties. Cette solution n’a pas été retenue car trop lourde à développerdans le cadre du stage.

4.5 Répartir l’application bord

Pour répartir l’application sur les deux calculateurs, il faut considérer les contraintesdécrites au paragraphe 2.3.

Considérons tout d’abord les contraintes dues au matériel. Chaque driver de carte,d’interface de liaison série doit s’exécuter sur la machine où le matériel est physiquementconnecté, je vais donc distribuer tout d’abord la couche la plus profonde du modèle en couche.

Je dispose sur la machine pc-bana-daurat.cst.cnes.fr :

- De la carte ANDI-Servo pour contrôler le vérin.

48

- De deux ports séries (COM1 pour envoyer la TM et COM2 pour recevoir la TC).

Et sur la machine pc-bana-saintex.cst.cnes.fr :

- D’une carte d’entrées analogiques.- D’une carte d’entrées – sorties logiques.- D’un port série pour recevoir les trames du GPS.

Donc les modules associés aux drivers de ces matériels vont aussi être localisés sur lesmachines correspondantes.

On considère aussi la charge de calcul des calculateurs. Ainsi le guidage est le module quirequiert la plus grosse puissance de calcul. On considère aussi les périodes des tâches derégulation qui doivent être le plus précis possible (tâches de régulations en azimut et enélévation).

Ainsi on distribue les modules sur les deux machines :

Figure-19 Distribution du logiciel de vol

On remarque qu’il y a deux modules de drivers de liaison série. Comment ceci estpossible ? Le driver de liaison série est un paquetage générique et ne peut être catégorisé. Doncun module faisant appel à un driver générique instancie le paquetage générique. Le paquetagequi encapsule l’instance doit être catégorisé Remote_Call_Interface pour que le driver nes’exécute que sur 1 seule machine. Ainsi le module d’acquisition GPS utilise la liaison série :

Package acquisition_GPS is

Pragma Remote_Call_interface ;

Package Liaison_serie_GPS is new une_liaison_serie(…) ;

…

pc-bana-saintex

1 port série GPS1 carte entrées analogique

1 carte entrées sorties logiques

pc-bana-daurat

2 ports séries GPS1 Carte ANDI-Servo Matériels

Calculateurs

Modules logiciels

Driver carte ANDI-ServoContrôle pointage élévation

Contrôle vérinDriver de liaison série

Module de TM/TCContrôleur nacelle

GuidageProgramme principal

Driver de liaison sérieDriver de cartes e/s logiques

Driver de cartes entrées logiquesModule acquisition GPSContrôle pointage azimut

ServitudesContrôles butées

49

Il ne faut pas oublier de catégoriser Remote_Types tout les paquetages exportant destypes comme le paquetage Grandeurs_physiques, fichiers de description de la télémesure et destélécommandes.

Nous pouvons ensuite décomposer le logiciel en partitions. Cette décomposition esteffectuée selon une logique fonctionnelle.

- 1 partition contenant le programme principal qui ne fait appel qu’à l’entrée demarrerdu logiciel de vol.

- 1 partition pour le contrôleur nacelle.- 1 partition contenant le module de TM/TC.- 1 partition gérant les servitudes (électriques, thermiques, relais)- 1 partition d’acquisition du GPS.- 1 partition pour la régulation azimut- 1 partition pour la régulation en élévation.- 1 partition pour le guidage.

On multiplie les partitions pour un confort de visualisation du déroulement des opérations.En effet, comme il s’agît d’un démonstrateur, j’ai inclus de nombreux affichages à l’écran. Donc ilest plus aisé de voir les affichages décomposés par fonctionnalités.

Dans une application opérationnelle, on réduirait le nombre de partitions, le minimumétant deux, une pour chaque machine.

Le fichier de configuration des partitions GNAT-GLADE 3.15 et le fichier de compilation del’application sont disponibles en annexes 5 et 6.

• La répartition et l’IHM :

Avant de pouvoir implémenter les modules de TM/TC, je ne pouvais pas contrôler lanacelle par télécommandes. J’ai donc créé une application répartie avec une interface graphiqueGtkAda permettant d’aller solliciter les entrées de chaque modules. Comme le calculateur PC104ne dispose pas d’interface graphique, j’ai répartie la partie IHM sur mon PC de développement.Ce petit exemple anodin d’utilisation de la répartition ouvre de nombreuses perspectives commepar exemple le développement de systèmes d’acquisition de mesures. Sans la répartition, pourvisualiser des mesures acquises sur diverses cartes, il faut une machine, munie de toutes cescartes connectés à un système réel, suffisamment puissante et spécifique. Avec la répartition,une petite machine de type PC104 interface les cartes, et une autre machine tout à fait standardde type portable se chargera de l’interface graphique à distance. Car les deux machinescommuniquent par le réseau IP et n’ont pas besoin d’être à proximité l’une de l’autre. (Machineinstrument dans un laboratoire et la machine d’interface graphique dans un bureau).

4.6 Savoir observer et commander la nacelle depuis lesol

Les fonctions de télémesures et de télécommandes sont très importantes. Ils permettent àla station sol de pouvoir observer et de commander la nacelle. Pour ceci il faut que les deuxlogiciels (sol et bord) se soient mis d’accord sur les formats de télémesures et de télécommandeséchangés lors d’un vol. C’est à dire qu’il faut que les deux sachent au bit près comment sontenvoyées les données pour pouvoir bien les recevoir.

Il faut aussi bien définir les commandes à effectuer sur la nacelle depuis le sol. Et surtoutrendre la nacelle la plus observable possible. Un nombre important de données sont échangées et

50

il est important de bien les structurées, de les regroupées de façon logique pour le destinatairepuisse les recevoir dans les meilleures conditions possibles.

4.6.1 Comment observer la nacelle ?

L’observation de la nacelle depuis le sol se fait exclusivement par la télémesure, il est doncimportant de bien concevoir cette fonction.

Les télémesures sont groupées par modules, c’est à dire que chaque module produisant dela télémesure possède un identificateur de mesures. A chaque identificateur, corresponddifférentes mesures. Prenons l’exemple du pointage en élévation, qui a unidentificateur « pointage élévation ». Le module de pointage en élévation produit 4 mesures enmode « pointage » :

- mesure de l’angle d’élévation en radians- mesure de la position du vérin en millimètres- consigne courante en radians- erreur d’élévation en radians

De même que pour le pointage en azimut, qui produit aussi 3 autres mesures a unidentificateur « pointage azimut ».

La télémesure est décrite avec une structure donnée Ada95 (record) discriminée parl’identificateur de mesures. L’identificateur est un type énuméré Ada95 :

type identificateur_TM is (pointage_azimut, pointage_elevation) ;

Chaque groupe de télémesures fait elle même l’objet d’un record :

type donnees_pointage_elevation is record Mesure_elevation : Grandeurs_physiques.angles.radian ; Consigne_elevation : Grandeurs_physiques.angles.radian ; Erreur_elevation : Grandeurs_physiques.angles.radian ; Position_verin : Grandeurs_physiques.cartesiennes.millimetre ;end record ;

De même pour les données de pointage en azimut.

Chaque groupe de données est décrite au bit près à l’aide des clauses de représentation Ada95 :

for donnees_pointage_elevation’size use 256 ;

for donnes_pointage_elevation’size use record Mesure_elevation at 0 range 0 .. 63 ; Consigne_elevation at 0 range 64 .. 127 ; Erreur_elevation at 0 range 128 .. 191; Position_verin at 0 range 192 .. 255 ;end record ;

Pour chaque mesure, on indique quels sont les bits occupés dans la structure de données.Ici chaque mesure occupe 64 bits car ce sont des réels en double précision. On remarque

que le type des mesures est leur unité, ceci grâce aux paquetages de grandeurs physiques. Ceciest possible grâce au fort typage Ada95.

Enfin chaque groupe de données est incorporé dans la structure générale des paquets detélémesures (Paquet_TM) associé à leur discriminant respectif :

type paquet_TM (de_type : identificateur) is record

51

Heure : time_unix_code ; Centiemes : centimes_de_seconde ; case identificateur is

when pointage_elevation => Les_donnees_pointage_elevation : donnees_pointage_elevation ;

when pointage_azimut => Les_donnees_pointage_azimut : donnees_pointage_azimut ;

end case ;end record ;

La date est stockée sous la forme de deux champs :- « time_unix_code » qui représente le nombre de secondes écoulées depuis le 1er

janvier 1970 à 00 :00. Time_unix_code est une convention de représentation desdates.

- « Centièmes_de_seconde » qui comme sont nom l’indique représente les centièmesde secondes.

Un module voulant créer un paquet de télémesures déclare un objet de type paquet_TM enindiquant son discriminant. Par exemple le module de pointage en élévation déclare son paquetde télémesures de la manière suivante :

Paquet_TM_pointage : paquet_TM(pointage_elevation) ;

Et peut ensuite remplir la structure de données avec ses mesures :

Paquet_TM_pointage.les_donnees_pointage_elevation.mesure_elevation :=La_mesure_acquise ;

On date le paquet, puis le module de transmet au module de contrôle TM/TC qui l’envoieau sol dans une trame de télémesures.

Le sol reçoit alors la trame, identifie le type de mesures à l’aide de l’identificateur et saitdonc les mesures composant le paquet. Le logiciel sol doit donc posséder le fichier décrivant lastructure des paquets de télémesures.

Le fichier de description de télémesures est disponible en annexe 3.

On remarque que la description de la télémesure s’appuie uniquement sur le typageAda95.

4.6.2 Comment commander la nacelle ?

De la même manière on aura un fichier de description des télécommandes. Chaquetélécommande possède un identificateur et à chaque identificateur on associe des paramètrespour la télécommande. Par exemple pour ordonner à la nacelle de pointer une direction précise, ilfaut lui passer en paramètre l’angle d’azimut et l’angle d’élévation. Ou pour pointer l’instrumentseulement en azimut, on passe en paramètres l’angle d’azimut.

Comme pour la télémesure, l’identificateur de télécommande est un type énuméré :

type identificateur_tc is (pointer_azimut_elevation, pointer_azimut) ;

Puis chaque identificateur correspond une structure de données contenant les paramètres.

52

type parametres_pointer_azimut_elevation is record Azimut : grandeurs_physiques.angles.radian ; Elevation : grandeurs_physiques.angles.radian :end record ;

Enfin on décrit la structure de données d’un paquet de télécommande :

type paquet_TC (de_type : indentificateur_tc) is record

case de_type is

when pointer_azimut_elevation => Les_parametres_pointer_azimut_elevation :

parametres_pointer_azimut_elevation ;

when pointer_azumut => Les_parametres_pointer_azimut : parametres_pointer_azimut ; end case ;end record ;

De la même manière que pour la télémesure, les deux logiciels (bord et sol) ont besoin dece fichier de description. L’envoi et la réception se fait de la même manière que pour latélémesure. Le fait que les deux applications utilisent la même description de la télémesure et destélécommandes assure la cohérence de l’échange des données. A chaque paquet detélécommande reçu, le logiciel bord envoi un paquet d’acquittement vers le sol. Ce type depaquet d’acquittement fait l’objet d’un autre identificateur dans le fichier de télémesures dont lesdonnées sont décrites au paragraphe 4.1.4.

De même que pour la télémesure, la description des télécommandes s’appuie uniquementsur le typage Ada95.

4.6.3 Intégration avec le segment sol

Pendant la période de mon stage, un autre stagiaire, Karim HALIOUI, conçoit et développeun logiciel sol, permettant d’acquérir et traiter la télémesure. Il utilise la bibliothèque d’interfacegraphique GtkAda et la bibliothèque XMLAda. Ce logiciel sol permet une grande modularité. Ilpossède 3 composants :

- un éditeur de plan de mesures permettant de décrire toutes les caractéristiques desmesures envoyées par le bord pour la visualisation (format d’affichage unités …).Ces informations sont stockées sous forme d’un fichier XML.

- Un éditeur de pages de mesures permettant à l’utilisateur de créer des fenêtres oùfigurent les mesures de son choix (qu’il a précédemment décrite dans l’éditeur deplan de mesures) qu’il peut visualiser sous différentes formes : courbes, afficheursnumériques, jauges … Chaque page est décrite par un fichier XML.

- Un visualiseur de mesures, connecté aux voies de TM/TC, affichant les pages crééesà partir de l’éditeur et actualise en temps réel les différents afficheurs avec lesdonnées transmises par le logiciel de bord.

J’ai ajouté à ce logiciel l’envoi de télécommandes (avec interface graphique GtkAda)correspondantes au démonstrateur.

J’ai donc utilisé ces outils pour visualiser les mesures envoyées par le démonstrateur.Cette expérience fut un bon test du logiciel sol, de l’interface et du protocole de la liaison bord –sol. Les deux logiciels ont en commun les modules traitant l’envoi et le réception de la TM/TC. Lelogiciel sol implémente les deux mediums développés : Socket IP et liaison série.

53

L’éditeur de plan de mesures :

L’éditeur de pages, l’utilisateur crée un page pour visualiser les données de pointages(azimut, elevation) :

54

La visualisation des mesures de pointages :

Fenêtre de choix des télécommandes :

Fenêtre de la télécommande pointage altazimutal avec visualisation de l’acquittement :

55

5. Epilogue

Pour la première fois depuis que le projet d’évolution du contrôle – commande desnacelles pointées a débuté, les trois piliers technologiques et méthodologiques, conception HOOD,temps réel Ada + Linux et répartition sont mis en œuvres pour réaliser un logiciel, interfaçant deséquipements, représentatif d’un logiciel de bord opérationnel. Il a été donc démontré que lestechnologies standard industrielles peuvent parfaitement s’adapter au contrôle – commande desnacelles pointées.

Ce stage m’a permis de mettre en application mes connaissances acquises tout au longde ma formation (temps réel, réseaux IP, programmation haut et bas niveau, méthode deconception), mais aussi de découvrir des méthodes de conceptions telles que HOOD, lesapplications réparties et d’approfondir ma pratique des systèmes Linux. Ce projet m’aparticulièrement motivé et je regrette de ne pas pouvoir participer aux étapes futures et de nepas avoir pu assister au lancement d’un ballon.

De plus ce stage a conforté mes objectifs professionnels qui sont de développer et deconcevoir des applications temps réel embarquées.

J’espère que ces travaux permettront aux futurs développeurs du logiciel de bord desnacelles pointées de disposer d’un document synthétisant la mise en œuvre des différentestechnologiques.

56

TABLE DES FIGURES

Figure-1 système de vue en couches...................................................................................... 7Figure-2 Architecture bord-sol actuelle .................................................................................... 8Figure-3 Architecture bord-sol répartie .................................................................................... 9Figure-4 communication HSER ............................................................................................. 19Figure-5 communication LSER.............................................................................................. 19Figure-6 communication ASER ............................................................................................. 20Figure-7 diagramme de dépendances d’exemple d’une application répartie......................... 24Figure-8 schéma de principe d’appel de service d’une unité distante ................................... 26Figure 9 – Angles d’azimut et d’élévation d’un astre ............................................................. 28Figure-10 système de pointage d’un instrument.................................................................... 29Figure-11 graphe d’état de des modes de fonctionnement ................................................... 31Figure-12 Environnement HOOD du logiciel de vol. .............................................................. 34Figure-13 Structure générale du logiciel de vol ..................................................................... 35Figure-14 Les fonctions arrêter et démarrer du logiciel de vol............................................... 36Figure-15 Structure du module de contrôle TM/TC. .............................................................. 37Figure-16 Structure du module de pointage .......................................................................... 38Figure-17 Conventions Big et Little Endian............................................................................ 45Figure-18 Vérin d’élévation.................................................................................................... 46Figure-19 Distribution du logiciel de vol ................................................................................ 48

57

BIBLIOGRAPHIE

DOCUMENTS INTERNES

• Jean-Pierre SEUMA-VIDAL, prototypage d'applications réparties sur plusieurscalculateurs embarqués à bord de nacelles pointées, rapport de stage INSAToulouse, septembre 2002.

• André LAURENS, spécification du contrôle commande – commande desnacelles pointées, Tome 1, 2 & 3, mars 2004

RAPPORTS ET MANUEL DE REFERENCE

• Ada95 Référence Manual

• Ada95 Rationnale, Janvier 1995, intermetrics.

• Programmer en Ada95, John BARNES, 2000, aux éditions Vuilbert.

• GNAT - Glade 3.15p User’s Guide.

• Samuel TARDIEU, AdaSocket Reference Manual, 8 Janvier 2004.

• Manuel de la libraire termios,http://www.epita.fr/docs/man3/termios.3.html, Christophe BLAESS 1996 – 1997

• HOOD User's Group, HOOD Reference Manual, rev4, ref HRM4, 10.12.1995

• HOOD User's Group, HOOD User Manual, release 1.0, ref HUM-1.0 ,27.07.1994

• Laurent PAUTET, intergiciels schizophrènes : une solution à l’interopérabilitéentre modèle de répartition, Mémoire pour l’obtention de l’habilitation à dirigerdes recherches de l’université Pierre et Marie Curie Paris VI, 17.12.2001

I

ANNEXES

ANNEXE 1 : Abréviations...................................................................................................................... IIANNEXE 2 : Utilisation de AdaSocket ................................................................................................ IIIANNEXE 3 : Fichier de description des télémesures ........................................................................VANNEXE 4 : Fichier de description des télécommandes ................................................................. IXANNEXE 5 : Fichier de configuration GNATDIST...............................................................................XANNEXE 6 : Script de compilation du logiciel de vol .......................................................................XI

II

ANNEXE 1 : Abréviations

ASER : ASynchronous Execution Request

ETNA : Ensemble de Transmission Numérique pour Aérostat

HSER : Highly Synchronous Execution Request

IHM : Interface Homme - Machine

LSER: Lightly Synchronous Execution Request

MC : Module de Commande

MPF : Module de Pointage Fin

OPCS : OPeration Control Structure

OBCS : Object Control Structure

TC : Télécommande

TM : Télémesure

III

ANNEXE 2 : Utilisation de AdaSocket

• Créer un socket TCP recevant des données

Pour créer un socket TCP allant recevoir des données, plusieurs étapes sont nécessaires.Tout d’abord il faut créer deux objets de type « socket_FD » par simple déclaration. Un pourétablir la connexion, l’autre pour échanger les données utiles :

Socket_de_donnees : socket_FD ;Socket_de_connexion : socket_FD ;

Ensuite il faut créer un Stream associé au flux de données du socket défini dans labibliothèque AdaSocket que l’on peut référence par un pointeur :

Mon_Stream : aliased Socket_Stream_Type ;

Il faut définir les propriétés (protocole utilisé, domaine du socket) du socket à l’aide de lafonction « Socket » :

Socket(Socket_de_connexion, PF_INET, SOCK_STREAM) ;

Le paramètre « PF_INET » indique le domaine du socket et le paramètre« SOCK_STREAM » indique que le socket est en protocole TCP.

Il faut définir les options du socket selon les options du système d’exploitation :

Setsockopt (Socket_de_connexion, SOL_SOCKET, SO_REUSEADDR, 1);

On associe ensuite le socket à un port de communication (ici port 9000) :

Bind (Socket_de_connexion, 9000) ;

On établie une file d’écoute au socket de connexion par la procédure « Listen » enindiquant la taille de cette file (ici la taille est 1). Chaque élément de cette file peut établir uneconnexion. On est donc limité à une seule connexion.

Listen(Socket_de_connexion,1) ;

On se met ensuite en attente d’une connexion d’un socket émetteur de données et dèsque le socket émetteur aura envoyé une requête de connexion, on associe le socket de connexionau socket de données:

Accept_Socket (Socket_de_connexion, Socket_de_données);

Enfin on associe le socket de données au flux de données entrant c’est à dire au stream :

Initialize (Stream, Socket_de_données);

Nous sommes prêt à recevoir des données de l’émetteur.

• Créer un socket TCP émetteur de données

Pour un socket TCP émettant des données c’est un peu différent, il faut définir un seulsocket de données. Il faut toujours définir les propriétés du socket. Mais ensuite il faut envoyerune requête de connexion au socket destinataire en spécifiant le port de communication et le nom

IV

de la machine distante où se trouve le socket récepteur (chaîne de caractère, ici pc-bana-diderot.cst.cnes.fr et port 9000) :

Connect (socket_de_donnees,"pc-bana-diderot.cst.cnes.fr",9000);

Le socket receveur de données reçoit cette requête avec la procédure « Accept_Socket ».

De même que pour le socket receveur il faut associé le socket au stream.

Les deux sockets sont donc près à communiquer par protocole IP.

• Créer un socket UDP récepteur de données :

Pour créer un socket UDP, la procédure est un peu plus simple car c’est un protocole enmode « non connecté ». Mais ce n’est pas fondamentalement différent de la création d’un socketTCP.

Contrairement à la création d’un socket TCP récepteur, un objet socket est crée et il fauttoujours créer un Stream associé au flux de données :

Socket_de_donnees : socket_FD ;Mon_Stream : aliased Socket_Stream_Type ;

La première étape est la même, à part que l’on spécifie un protocole différent(SOCK_DGRAM : socket en mode datagram, socket en mode non connecté) :

Socket(Socket_de_donnees , PF_INET, SOCK_DGRAM) ;

La définition des options du socket est la même :

Setsockopt (Socket_de_connexion, SOL_SOCKET, SO_REUSEADDR, 1);

On associe, comme pour le socket IP, le socket à un port de communication (ici port9000) :

Bind (Socket_de_connexion, 9000) ;

On passe directement à l’association du socket au stream :

Initialize (Stream, Socket_de_données);

Le socket est près à envoyer des données.

• Créer un socket UDP émetteur de données :

On crée le socket de la même manière :

Socket(Socket_de_donnees , PF_INET, SOCK_DGRAM) ;

Puis on définie vers quelle machine et sur quelle port on veut envoyer les données :

Connect (socket_de_donnees,"pc-bana-diderot.cst.cnes.fr",9000);

Enfin on associe le socket au stream de la même façon que pour un socket récepteur :

Initialize (Stream, Socket_de_données);

V

ANNEXE 3 : Fichier de description des télémesures

package Mesures_bord is

pragma Remote_call_interface;

type Unix_time_code is range 0 .. 2**31-1; for Unix_time_code'size use 32;

type Centiemes_de_secondes is range 0 .. 99; for Centiemes_de_secondes'size use 8;

type Identificateur_Tm is (servitudes_Temperature, servitudes_batterie, servitudes_on_off, Controle_Azimut, Controle_elevation, Localisation_GPS, Etat_de_la_nacelle, acquitement_TC);

for identificateur_tm'size use 8;

type validite_trame is (OK,erronnee);

for validite_trame'size use 8;

type validite_sequenceur is (OK,rupture_sequence,indefinie);

for validite_sequenceur'size use 8;

type Donnees_Acquitement_TC is record la_validite_de_la_trame : validite_trame; la_validite_du_sequenceur : validite_sequenceur; numero_prochaine_trame_attendue : compteur_256; end record;

for Donnees_acquitement_TC'size use 24;

for donnees_acquitement_TC use record

la_validite_de_la_trame at 0 range 0 .. 7; la_validite_du_sequenceur at 0 range 8 .. 15; numero_prochaine_trame_attendue at 0 range 16 .. 23;

end record;

type Donnees_temperature is record Temperature_Air : Grandeurs_physiques.thermiques.degre_celsius; end record;

for Donnees_temperature'size use 32;

type Donnees_batteries is record tension_batterie : Grandeurs_physiques.Electriques.Volt; end record;

for Donnees_batteries'size use 32;

type Donnees_on_off is record etat_interrupteur : Grandeurs_physiques.Equipements.Marche_Arret; etat_LED : Grandeurs_physiques.Equipements.Marche_Arret;

VI

end record;

pragma pack(donnees_on_off);

for Donnees_on_off'size use 16;

type Donnees_controle_azimut_en_pointage is record Consigne_Azimut_finale : Grandeurs_physiques.angles.radian; Erreur_Azimut : Grandeurs_physiques.angles.radian_etendu; Mesure_Azimut : Grandeurs_physiques.angles.radian; end record;

for Donnees_controle_azimut_en_pointage'size use 192;

for Donnees_controle_azimut_en_pointage use record

Consigne_Azimut_finale at 0 range 0 .. 63; Erreur_Azimut at 0 range 64 .. 127; Mesure_Azimut at 0 range 128 .. 191; end record;

type Donnees_Controle_Azimut(le_mode :Grandeurs_physiques.equipements.Mode_de_pointage := veille) is record case le_mode is when veille => null;

when Pointage => Les_donnees_en_pointage : Donnees_controle_azimut_en_pointage;

when en_mesure => Mesure_Azimut : Grandeurs_physiques.angles.radian;

end case; end record;

type Donnees_controle_elevation_en_pointage is record Consigne_elevation_finale : Grandeurs_physiques.angles.radian; Erreur_Elevation : Grandeurs_physiques.angles.radian_etendu; Mesure_Elevation : Grandeurs_physiques.angles.radian; Position_verin : Grandeurs_physiques.cartesiennes.millimetre; end record;

for Donnees_controle_elevation_en_pointage'size use 224;

for Donnees_controle_elevation_en_pointage use record

Consigne_elevation_finale at 0 range 0 .. 63; Erreur_Elevation at 0 range 64 .. 127; Mesure_Elevation at 0 range 128 .. 191; Position_Verin at 0 range 192 .. 223;

end record;

type Donnees_controle_elevation_en_mesure is record Mesure_Elevation : Grandeurs_physiques.angles.radian; Position_verin : Grandeurs_physiques.cartesiennes.millimetre; end record;

for Donnees_controle_elevation_en_mesure'size use 96;

for Donnees_controle_elevation_en_mesure use record Mesure_elevation at 0 range 0 .. 63; Position_verin at 0 range 64 .. 95; end record;

VII

type Donnees_Controle_Elevation(le_mode : Mode_de_pointage := veille) is record case le_mode is when veille => null;

when Pointage => Les_donnees_en_pointage : Donnees_controle_elevation_en_pointage;

when en_mesure => les_Donnees_en_mesure : Donnees_controle_elevation_en_mesure;

end case;

end record;

type donnees_localisation_GPS is record Latitude : Grandeurs_physiques.angles.radian; Longitude : Grandeurs_physiques.angles.radian; altitude : Grandeurs_physiques.Cartesiennes.metre; Cap : Grandeurs_physiques.angles.radian; Vitesse_horizontale : Grandeurs_physiques.Cartesiennes.metre_par_seconde; Vitesse_verticale : Grandeurs_physiques.Cartesiennes.metre_par_seconde; Vitesse_Est_Ouest : Grandeurs_physiques.Cartesiennes.metre_par_seconde; Vitesse_Nord_Sud : Grandeurs_physiques.Cartesiennes.metre_par_seconde; Nombre_de_satellites_visibles : types_gps.Nombre_De_Satellites; Nombre_de_satellites_poursuivis : types_gps.Nombre_De_Satellites; La_Qualite_Gps : Grandeurs_physiques.equipements.Qualite_Gps; end record;

for donnees_localisation_GPS'size use 376;

for donnees_localisation_GPS use record Latitude at 0 range 0 .. 63; Longitude at 0 range 64 .. 127; altitude at 0 range 128 .. 159; Cap at 0 range 160.. 223; Vitesse_horizontale at 0 range 224 .. 255; Vitesse_verticale at 0 range 256 .. 287; Vitesse_Est_Ouest at 0 range 288 .. 319; Vitesse_Nord_Sud at 0 range 320 .. 351; Nombre_de_satellites_visibles at 0 range 352 .. 359; Nombre_de_satellites_poursuivis at 0 range 360 .. 367; La_Qualite_Gps at 0 range 368 .. 375; end record;

type Paquet_Tm (De_Type : Identificateur_Tm := servitudes_temperature) is record Heure : Unix_Time_code; centiemes : Centiemes_De_Secondes;

case De_Type is when servitudes_temperature => Les_Donnees_thermiques : donnees_temperature;

when servitudes_batterie => les_donnees_batterie : donnees_batteries;

when servitudes_ON_OFF => les_donnees_ON_OFF : donnees_ON_OFF;

when Controle_Azimut => Les_Donnees_Controle_Azimut : Donnees_Controle_Azimut;

when Controle_Elevation => Les_Donnees_Controle_Elevation : Donnees_Controle_Elevation;

when localisation_GPS => Les_donnees_localisation_GPS : donnees_localisation_GPS;

VIII

when Etat_de_la_nacelle => L_etat_nacelle : Etat_nacelle;

when acquitement_TC => Les_donnees_acquitement_TC : Donnees_acquitement_TC;

end case; end record;

end Mesures_bord;

IX

ANNEXE 4 : Fichier de description des télécommandes

package telecommande_sol is

pragma remote_types;

type Identificateur_Tc is (arret_pointage, pointer_azimut, pointer_azimut_elevation, pointer_soleil, changer_LED, degerber);

type Paquet_Tc (De_Type : Identificateur_Tc := arret_pointage) is

record

case De_Type is

when arret_pointage => null;

when pointer_azimut => l_azimut : grandeurs_physiques.angles.radian;

when pointer_azimut_elevation => la_consigne_ah : astro.coordonnees.coordonnees_horizontales;

when pointer_soleil => null;

when Changer_LED => null;

when Degerber => null;

end case;

end record;

end telecommande_sol;

X

ANNEXE 5 : Fichier de configuration GNATDIST

Configuration logiciel_bord is

pragma Starter(None); pragma Boot_server ("tcp","pc-bana-daurat.cst.cnes.fr:5557");

p_main : Partition := (lv_nacelle_bord);

p_controle_general : Partition := (lv_nacelle, controleur_nacelle);

p_controle_azimuth : Partition := (controle_pointage_azimuth_primaire, magnetometre, gyro_z, roue_z, pivot);

p_controle_elevation : Partition := (controle_pointage_elevation_primaire, verin, butees);

p_controle_servitudes : Partition := (controleur_servitudes, servitudes, controle_thermique, controle_batterie,

controle_on_off,acquisition_analogique,

entrees_sorties_logiques);

p_gps : Partition := (temps_loc,temps_loc.gps,temps_loc.base_de_temps,datation_tm);

p_tm_tc : Partition := (controle_tm_tc, voie_tm,

voie_tc, un_compteur, mesures_bord);

p_guidage : partition := (guidage);

Procedure lv_nacelle_bord is in p_main;

for p_main'Host use "pc-bana-daurat.cst.cnes.fr"; for p_controle_general'Host use "pc-bana-daurat.cst.cnes.fr"; for p_tm_tc'Host use "pc-bana-daurat.cst.cnes.fr"; for p_guidage'Host use "pc-bana-saintex.cst.cnes.fr"; for p_controle_azimuth'Host use "pc-bana-saintex.cst.cnes.fr"; for p_controle_elevation'Host use "pc-bana-daurat.cst.cnes.fr"; for p_controle_servitudes'Host use "pc-bana-saintex.cst.cnes.fr"; for p_gps'Host use "pc-bana-saintex.cst.cnes.fr";

for Partition'Storage_Dir use "bin";

end logiciel_bord;

XI

ANNEXE 6 : Script de compilation du logiciel de vol

#!/bin/sh

gnatdist -I/home/arnaud/lv_nacelle/_ada/ -I/home/arnaud/lv_nacelle/_ada/mesures/-I/home/arnaud/lv_nacelle/_ada/telecommande/ -I/usr/adasockets-1.8.4.3/lib/adasockets/ -I/home/arnaud/ada/naplib -I/home/arnaud/ada/astro -I/home/arnaud/ada/materiel logiciel_bord.cfg p_main -L/usr/adasockets-1.8.4.3/lib/adasockets -largs -L/usr/adasockets-1.8.4.3/lib -ladasockets

gnatdist -I/home/arnaud/lv_nacelle/_ada/ -I/home/arnaud/lv_nacelle/_ada/mesures/ -I/home/arnaud/lv_nacelle/_ada/telecommande/ -I/usr/adasockets-1.8.4.3/lib/adasockets/ -I/home/arnaud/ada/naplib -I/home/arnaud/ada/astro -I/home/arnaud/ada/materiel logiciel_bord.cfg p_controle_general -L/usr/adasockets-1.8.4.3/lib/adasockets -largs -L/usr/adasockets-1.8.4.3/lib -ladasockets -L/home/arnaud/lv_nacelle/_ada input_output_pc.c

gnatdist -I/home/arnaud/lv_nacelle/_ada/ -I/home/arnaud/lv_nacelle/_ada/mesures/ -I/home/arnaud/lv_nacelle/_ada/telecommande/ -I/usr/adasockets-1.8.4.3/lib/adasockets -I/home/arnaud/ada/naplib -I/home/arnaud/ada/astro -I/home/arnaud/ada/materiel logiciel_bord.cfg p_controle_azimuth -L/usr/adasockets-1.8.4.3/lib/adasockets -largs -L/usr/adasockets-1.8.4.3/lib -ladasockets

gnatdist -I/home/arnaud/lv_nacelle/_ada/ -I/home/arnaud/lv_nacelle/_ada/mesures/ -I/home/arnaud/lv_nacelle/_ada/telecommande/ -I/usr/adasockets-1.8.4.3/lib/adasockets -I/home/arnaud/ada/naplib -I/home/arnaud/ada/astro -I/home/arnaud/ada/materiel logiciel_bord.cfg p_controle_elevation -L/usr/adasockets-1.8.4.3/lib/adasockets -largs -L/usr/adasockets-1.8.4.3/lib -ladasockets -L/home/arnaud/lv_nacelle/_ada input_output_pc.c

gnatdist -I/home/arnaud/lv_nacelle/_ada/ -I/home/arnaud/lv_nacelle/_ada/mesures/ -I/home/arnaud/lv_nacelle/_ada/telecommande/ -I/usr/adasockets-1.8.4.3/lib/adasockets -I/home/arnaud/ada/naplib -I/home/arnaud/ada/astro -I/home/arnaud/ada/materiel logiciel_bord.cfg p_controle_servitudes -L/usr/adasockets-1.8.4.3/lib/adasockets -largs -L/usr/adasockets-1.8.4.3/lib -ladasockets -L/home/arnaud/lv_nacelle/_ada input_output_pc.c

gnatdist -I/home/arnaud/lv_nacelle/_ada/ -I/home/arnaud/lv_nacelle/_ada/mesures/ -I/home/arnaud/lv_nacelle/_ada/telecommande/ -I/usr/adasockets-1.8.4.3/lib/adasockets -I/home/arnaud/ada/naplib -I/home/arnaud/ada/astro -I/home/arnaud/ada/materiel logiciel_bord.cfg p_gps -L/usr/adasockets-1.8.4.3/lib/adasockets -largs -L/usr/adasockets-1.8.4.3/lib -ladasockets -L/home/arnaud/lv_nacelle/_ada liaison.c

gnatdist -I/home/arnaud/lv_nacelle/_ada/ -I/home/arnaud/lv_nacelle/_ada/mesures/ -I/home/arnaud/lv_nacelle/_ada/telecommande/ -I/usr/adasockets-1.8.4.3/lib/adasockets/ -I/home/arnaud/ada/naplib -I/home/arnaud/ada/astro -I/home/arnaud/ada/materiel logiciel_bord.cfg p_tm_tc -L/usr/adasockets-1.8.4.3/lib/adasockets -largs -L/usr/adasockets-1.8.4.3/lib -ladasockets -L/home/arnaud/lv_nacelle/_ada liaison.c

gnatdist -I/home/arnaud/lv_nacelle/_ada/ -I/home/arnaud/lv_nacelle/_ada/mesures/ -I/home/arnaud/lv_nacelle/_ada/telecommande/ -I/usr/adasockets-1.8.4.3/lib/adasockets/ -I/home/arnaud/ada/naplib -I/home/arnaud/ada/astro -I/home/arnaud/ada/materiel logiciel_bord.cfg p_guidage -L/usr/adasockets-1.8.4.3/lib/adasockets -largs -L/usr/adasockets-1.8.4.3/lib -ladasockets