master e marc favereau...présentation du sujet 1 - contexte d'emploi 1.a - le banc bedyra le...

2013-2014 Rapport de stage

DGA-Maîtrise deI'Information

CGN1/ERS/BEDYRA------

Route de Laillé35170 Bruz

MASTERINFORMATIQUE

(2e année)

SpécialitéGénie Logiciel Marc Favereau

Etude, choix, déploiement et validation d'un système temps-réel libre basé sur Linux

Linux, Temps-réel, Preempt-RT, Xenomai, LinuxRT, RTAI, ADEOS, Compilationkernel, Développement drivers Linux.

Stage effectué du 3 mars 2014 au 29 août 2014 à DGA-MI BruzSoutenance à Rennes, le 3 septembre 2014

[email protected]

[email protected]

ISTIC – UFR Informatique et ÉlectroniqueUniversité de Rennes 1, Campus de Beaulieu

263, avenue du Général LeclercCS 74205, 35042 Rennes CEDEX, France

02 23 23 39 00

Sous la responsabilité de

Gilles Le Saint, [email protected], DGA-MI

Noël Plouzeau, [email protected], Istic

mailto:[email protected]

mailto:[email protected]

Stage de MASTER 2 Génie Logiciel ISTIC 2013 / 2014

Table des matières

Remerciements.....................................................................................................................................3Résumé.................................................................................................................................................4Présentation de l'employeur..................................................................................................................5

1 - La Direction Générale de l'Armement........................................................................................5 1.a - Place au sein du ministère de la défense.........................................................................5 1.b - La direction technique....................................................................................................6

2 - L'établissement : DGA Maîtrise de l'Information.......................................................................63 - Le service....................................................................................................................................8

3.a - Pôle CGN........................................................................................................................8 3.b - Département ERS...........................................................................................................8

Présentation du sujet.............................................................................................................................81 - Contexte d'emploi.......................................................................................................................8

1.a - Le banc BEDYRA..........................................................................................................8 1.b - Solution logicielle actuelle............................................................................................10

2 - Sujet du stage............................................................................................................................103 - Bénéfices attendus....................................................................................................................11

Travail effectué...................................................................................................................................111 - Travail préparatoire..................................................................................................................122 - Etude des solutions possible.....................................................................................................13

2.a - Le temps réel.................................................................................................................13 2.b - Les OS temps réel.........................................................................................................14 2.c - Présélection...................................................................................................................18

3 - Ecriture de drivers spécifiques.................................................................................................19 3.a - Carte mémoire réfléchie PCIe-5565PIORC..................................................................20 3.b - Carte d'entrées/sorties DAQe-2010..............................................................................20

4 - Choix des solutions et mise en œuvre......................................................................................22 4.a - Présentation de BuildRoot............................................................................................23 4.b - Choix de l'environnement de travail.............................................................................23 4.c - Déploiement..................................................................................................................24

5 - Réalisation des tests..................................................................................................................24Reste à faire........................................................................................................................................27Conclusion..........................................................................................................................................27Bibliographie......................................................................................................................................28

Marc Favereau – DGA Maîtrise de l'Information / 28


Index des illustrationsIllustration 1: La DGA au sein du ministère de la défense...................................................................5Illustration 2: Organigramme de la DGA.............................................................................................6Illustration 3: Pôles techniques.............................................................................................................6Illustration 4: Pôles techniques de DGA-MI........................................................................................7Illustration 5: Principe du banc BEDYRA...........................................................................................9Illustration 6: Le panneau de génération de scènes de BEDYRA......................................................10Illustration 7: Principe de l'ordonnancement dans un noyau Linux classique....................................14Illustration 8: Ordonnancement RTAI avant ADEOS, identique à RTLinux.....................................15Illustration 9: Principe de fonctionnement d'ADEOS........................................................................16Illustration 10: Ordonnancement RTAI avec ADEOS et LXRT.........................................................16Illustration 11: Ordonnancement Xenomai........................................................................................18Illustration 12: Synoptique de fonctionnement de la carte VMIC PCIE-5565PIORC.......................20Illustration 13: Principe de fonctionnement du logiciel du banc avec le cadencement externe.........21Illustration 14: Mesure du temps de commutation entre tâches.........................................................25Illustration 15: Test de mise en oeuvre...............................................................................................26

RemerciementsJe tiens à remercier M. Olivier Lesbre, directeur de DGA-MI, pour m'avoir permis de suivre

la formation de Master 2 Génie Logiciel à l'ISTIC de Rennes et d'effectuer mon stage de fin d'étudeau sein de son établissement.

Je remercie également M. Benoît Delahaye, responsable du banc BEDYRA, et Gilles LeSaint, expert autodirecteur de missile, pour m'avoir encadré, aidé et soutenu.

Je remercie également M. Pierre Ficheux de la société Open Wide pour sa formation, seslivres, son assistance technique permanente et son humour.

Enfin je remercie M. Noël Plouzeau, responsable du Master 2 GL à l'ISTIC, ainsi que toutel'équipe enseignante pour ces 6 mois de cours intenses mais passionnants.



Résumé

Le but du stage était de choisir et déployer une solution informatique industrielle composéed'un calculateur scientifique, d'un système d'exploitation libre de droit, de différentes cartesd'entrées / sorties, et de cartes de communications. Le système choisi et déployé devra assurer, sansrégression par rapport au système actuel propriétaire, le bon fonctionnement d'un banc de testindustriel temps-réel.

Lors de la première partie du stage j'ai réalisé une étude de l'état de l'art des techniques et dudéveloppement industriel temps-réel afin de mieux comprendre les besoins du futur système. Ladeuxième partie a permis de mettre en œuvre différents systèmes d'exploitation temps-réel endéveloppant les drivers spécifiques des différentes cartes d'extension. Ensuite une étudecomparative des solutions a été effectuée sur le matériel réel afin de valider le fonctionnementgénéral et sélectionner la meilleure solution en termes de performances et coût.

Les premiers résultats de mesure orientent le choix du système vers Xenomai ou Preempt-RT.Les tests concernant ces deux solutions sont en grande partie réalisés et seront approfondis afin deréaliser le choix définitif et de l’implémenter sur le calculateur final. Cette prestation constitue lelivrable dû à la société THALES pour la réalisation du portage des logiciels actuels sur le nouveausystème. Le manuel d'utilisation et les différentes documentations techniques seront ensuite mis enforme.

SUMMARY

The purpose of this graduation internship was to choose and to install an IT industrialsolution formed of a scientific computer, a free operating system, various input / output cards, andcommunication cards. The chosen and deployed system will assume, without regression regardingthe present proprietary system, the correct behavior of the industrial bench in real-time.

The first part of the internship has been dedicated to a study of the state of the art oftechniques and industrial real-time development to better understand the needs for the futuresystem. The second part allowed to implement the various real-time operating systems and developthe specific drivers of the various extension cards. Then a comparative study of the solutions hasbeen be made on the real equipment to validate the general functioning and select the best solutionin terms of performance and cost.

The first results lead to a choice between the Xenomai and Preempt-RT systems. The tests forthese two solutions are almost over but they still need investigations in order to determine the finaldecision and to implement it on the final target computer. This task is a delivery due to the THALEScompany for the migration of their software towards the new system. The user manual and thevarious technical documents will then be formalized.



Présentation de l'employeur

1 - La Direction Générale de l'Armement

1.a - Place au sein du ministère de la défense

Le Délégué général pour l’armement (DGA) est l’un des trois grands subordonnés du ministreavec le Chef d’état-major des armées (CEMA) et le Secrétaire général pour l’administration (SGA).

Les trois missions de la DGA consistent à :

- Préparer le futur des systèmes de défense

- Equiper les forces de demain

- Promouvoir les exportations

Pour les mener à bien, elle dispose de compétences particulières :

- Une vision d’ensemble des systèmes d’armement pour assurer leur cohérence globale

- Une capacité à maîtriser les risques pour conduire des projets complexes et répondreaux menaces émergentes

- Des moyens d’expertise et d’essais, indépendants et uniques en Europe

- Une politique industrielle et technologique de dimension européenne

- Un partenaire actif pour le développement de l’innovation, des entreprises de défenseet des PME

- Des outils et des méthodes aux meilleurs standards industriels internationaux

La DGA contribue donc à la maîtrise d'ouvrage d'environ 80 programmes d'armement ens'appuyant sur différentes directions dont la Direction Technique (DT) à laquelle appartient DGA-MI.


Illustration 1: La DGA au sein du ministère dela défense.


1.b - La direction technique

Elle a en charge la maîtrise de lafonction technique au sein de la DGA etest composée de 9 centres et 15 sitesd'implantation. Les activités d'expertisetechnique sont réparties en 11 pôles decompétences techniques regroupant 5238personnels travaillant sur lesprogrammes d'armement en cours.

2 - L'établissement : DGA Maîtrise de l'Information

L’établissement, récemment restructuré, est l’héritier du CELAR (Centre d’Electronique del’Armement) et du LRBA (Laboratoire de Recherches Balistiques et Aérodynamiques). Il sepositionne sur l’expertise technique, qui va du composant au système de systèmes.


Illustration 2: Organigramme de la DGA.

Illustration 3: Pôles techniques.


Le centre affiche l’ambition de devenir le centre de référence des techniques de la maîtrise etde la protection de l’information, la guerre électronique et les missiles tactiques et stratégiques, dansun contexte d’interdépendance des systèmes. Ceci dans l’accomplissement des missions de la DGApar des actions concrètes :

•Contribution à la maîtrise des risques techniques des programmes :

◦Connaissance de la menace

◦Spécification technique des matériels

◦Analyse et plan d’actions de réduction de risques

◦Qualification et évaluation des performances et fonctionnalités des matériels

•Répondre de façon réactive aux besoins des opérationnels

◦Déploiement de matériels

◦Configuration de matériels

•Se positionner sur l’expertise dans un cadre Européen

◦Soutien à l’exportation

◦Externalisation

La sous-direction technique assurant la fonction technique au sein de DGA/MI est composéede 9 divisions, elles-mêmes scindées en départements, couvrant 8 des 11 pôles d’expertise de laDGA.


Illustration 4: Pôles techniques de DGA-MI.


3 - Le service

3.a - Pôle CGN

Le pôle assure les missions d'expertise technique des équipements ou systèmesélectromagnétiques et optroniques, des dispositifs de guerre électronique et des systèmes deguidage/navigation. Il regroupe les métiers: Guidage Navigation (GN), Optronique (OPT), GuerreElectronique (GE) et Détection Electromagnétique (DE). C'est au sein du métier DE que se situel'activité du département Expertise de Radars et Systèmes d'armes (ERS).

3.b - Département ERS

Le département Expertise de Radars et Systèmes d'armes (ERS) appartenant à la divisionCGN1 contribue à la maîtrise des risques techniques dans les domaines :

•des Radars et des Autodirecteurs électromagnétiques de missiles,

•des Contre-Contre-Mesures Electroniques radars (CCME),

•des Systèmes d’Armes.

Au travers de travaux d’expertises réalisés à l’aide de simulations numériques, simulationshybrides et d’essais réels, les personnels du département évaluent :

•les performances des capteurs dans leur environnement (hostile)

•l’impact de ce fonctionnement sur les performances des systèmes sur lesquels ils sontintégrés.

Le périmètre d'intervention comprend les systèmes terrestres, navals et aéronautiques encontexte de guerre électronique. Le département est organisé en quatre laboratoires regroupant lespersonnels et les moyens dédiés à l'expertise des différents systèmes. Les moyens sont constituéspar des outils de simulation numérique et des bancs de simulation hybride.

Présentation du sujet

1 - Contexte d'emploi

1.a - Le banc BEDYRA

Le banc d'essai BEDYRA, pour Banc d'Essai Dynamique pour Radar et Autodirecteur, est unbanc de simulation hybride permettant d'effectuer des essais de qualification de matériel militaire de



type radar de pointe avant d'avion de chasse (RDI, RDY, RBE2, etc... ) et autodirecteur de missiles,plus communément appelé "tête chercheuse". Le principe d'un banc hybride est de présenter unenvironnement et une scène simulés à un matériel réel. Dans le cas du banc BEDYRA, une scènemouvante électromagnétique, pouvant comporter plusieurs aéronefs et leurres, est définie via uneIHM qui transmet les données de configuration (jusqu'à 3000 paramètres) et les commande à unlogiciel nommé CAVIAR.

Le logiciel CAVIAR est déployé sur un calculateur temps-réel, et a pour mission de mettre enforme les données issues de l'IHM et d'effectuer à la fréquence de commande du banc :

- Le calcul des positions, attitudes et évolution cinématique des différents vecteurs composantla scène

- Le calcul des composantes électromagnétiques des vecteurs et des leurres mis en œuvre

- L'envoi des paramètres calculés aux différentes cartes de génération

- Le calcul des positions, attitudes et évolution cinématique du matériel en test

- L'envoi des paramètres calculés à la table de vol qui supporte le matériel en test et simule sesmouvements

- L'envoi des paramètres et commandes à la carte de pilotage du matériel en test

- La lecture des retours du banc et du matériel en test

- L'affichage en temps-réel de certains paramètres

- L'archivage de tous les paramètres du banc et du matériel

Le banc est constitué de différentes cartes de générations développées et maintenues par lasociété THALES. C'est le banc qui gère le cadencement de l'ensemble en distribuant une horloge


Illustration 5: Principe du banc BEDYRA


appelé "IT400" sur l'ensemble des cartes de générations et sur le calculateur, à une fréquence del'ordre de 400 Hz. Ces cartes de génération "fabriquent" les signaux représentant la scène à simuleret l'émettent, via un panneau de 500 cornets (antennes émettrices) environ, vers le matériel en testdans une chambre anéchoïde.

Les interfaces entre le calculateurs et son environnement sont constitués de réseaux GigabitEthernet pour la liaison avec les cartes de génération et de mémoires réfléchies par fibre optique detype VMIC 5565 pour la liaison avec le matériel et la table de vol.

1.b - Solution logicielle actuelle

Actuellement le calculateur de commande est un ALTIX 450 fourni et maintenu par la sociétéSGI. Ce calculateur possède 8 cœurs de la famille ITANIUM 2 en 64 bits et est géré par le systèmed'exploitation IRIX (basé sur UNIX System V). SGI fournit également tout l'environnement et lesbibliothèques permettant le développement temps réel. Le coût, les délais de maintenance etl'opacité de cette solution ont emmené le service à réorienter sa politique vis à vis de cette solution.

2 - Sujet du stage

Le but du service est de remplacer la solution actuelle (calculateur, système d'exploitation,bibliothèques temps-réel) par :

- Un calculateur scientifique basé sur des composants grand public, peu onéreux et évolutif

- Des cartes d'extension permettant la communication avec les autres composantes du banc et


Illustration 6: Le panneau de génération de scènes de BEDYRA


la synchronisation sur l'IT400

- Un système d'exploitation temps-réel libre de droit

Tout en ayant des performances équivalentes ou supérieures au système actuel.

Le sujet de mon stage de Master 2 sera donc de mener une étude afin de choisir unearchitecture (matérielle et logicielle) de développement et d’exécution d'application temps réel,basée sur des logiciels libres. La solution choisie sera déployée et fournie avec des logiciels de miseen œuvre, des logiciels de démonstration et une documentation utilisateur.

3 - Bénéfices attendus

Cette évolution permettra en premier lieu de réduire les coûts d'investissement et defonctionnement du banc en optant pour une utilisation de logiciels libres et pour l'achat decomposants "sur étagère".

Ce choix découle également de la volonté du service de reprendre la maîtrise totale de laproblématique du temps-réel, autant en terme de logiciel que de matériel, afin de pouvoir justifierdu bon fonctionnement du banc en cas de litige sur un essai relatif à un matériel. En effet, dans lecas où le fonctionnement d'un matériel en test ne correspond pas exactement à ce qui est attendu,nous devons justifier à l'industriel que le dysfonctionnement n'est pas du fait du banc mais bien dumatériel.

Travail effectué

Ce chapitre détaille le travail qui a été réalisé durant mon stage afin d'atteindre les buts fixésdans le sujet. La démarche initialement prévue se décompose en 6 parties :

- Travail préparatoire qui a eu lieu en amont du début du stage afin d'approvisionner lesressources nécessaires

- Etude documentaire des solutions possibles et de l'état de l'art du développement temps réelsous Linux et formation

- Développement au niveau noyau des drivers spécifique à chaque composant du système etformation

- Choix avec les utilisateurs finaux des solutions pertinentes et déploiement de celles-ci envue des tests

- Définition du plan de test et réalisation de celui-ci

- Rédaction de la documentation et développement des logiciels de mise en œuvre.



1 - Travail préparatoire

Avant d'effectuer les essais logiciels ilétait nécessaire de sélectionner et d'acheter lematériel, c'est pourquoi le choix du calculateuret de ses cartes d'extensions a été fait 1 anavant le début du stage. En effet, laréglementation des achats publics impose unemise en concurrence de différentes sociétésprestataires pour répondre à un cahier descharge qui définit le besoin technique en termed'exigences. La procédure d'achat passe par différentes commissions de validation et d'acceptation,ce qui génère un délai important avant la réception du matériel. Ce cahier des charges, appelé CCTPpour Cahier des Clauses Techniques Particulières, a nécessité environ 2 semaines de travail pourfaire un état des lieux des caractéristiques du calculateur actuel, faire un panorama des propositionsexistant sur le marché, établir au plus juste les besoins et rédiger le CCTP. Les principales exigencestechniques sont :

- Chaque processeur devra être compatible avec l’architecture x86_64, disposer du jeud’instruction SSE4 minimum et de type XEON E7, XEON 7000, XEON MP ou CORE i7.

- Le calculateur doit comporter au moins 8 cœurs de calculs répartis sur au moins 4microprocesseurs.

- Le calculateur doit disposer d’au moins 16 Go de mémoire vive.

- La fréquence de travail des microprocesseurs doit être supérieure à 2 GHz.

- Le calculateur doit comporter au moins 2 interfaces réseau de type Ethernet avec un débit de1 Gbit/s.

- Le calculateur doit comporter au moins 2 disques durs d’une capacité de 1 To chacun.

- Le calculateur doit avoir au minimum 3 slots PCI et 4 slots PCI express libre.

- Le calculateur doit posséder une carte permettant l’acquisition de 2 signaux analogiques de10 volts sur 14 bits minimum à la vitesse de 1800 kech/s minimum au format PCI express.

- Le calculateur doit posséder une carte permettant la génération de 2 signaux analogiques de10 volts sur 10 bits minimum à la vitesse de 800 kech/s minimum au format PCI express.

- Le calculateur doit posséder une carte de 20 entrées/sorties numérique TTL minimum.

- Le calculateur doit posséder 2 cartes de mémoires réfléchies compatible avec les cartesVMIC 5565 au format PCI.

L'intégralité du CCTP est fournie en annexe 1.

Afin de gagner du temps sur l'étude du temps réel sous Linux, j'ai proposé à ma hiérarchie depasser un contrat avec un prestataire spécialisé dans l'informatique industrielle et embarquée afin defournir une formation à toute l'équipe de développement sur les problématiques temps réel, leprincipe de fonctionnement de Linux (espace noyau et espace utilisateur), le développement dedrivers Linux, les solutions de développement pour l'embarqué et pour les applications temps réel.



Ce contrat prévoit également une assistance technique pour le déploiement d'une architecture tempsréel libre. Il a également été nécessaire de rédiger un CCTP pour cette prestation que vous trouverezen annexe 2.

Les sociétés retenues sont :

- La société Ecrin System avec sa solution basée sur l'Opale V2, les cartes VMIC PCIe-5565PIORC et DAQe-2010. (Présentation Ecrin, de l'Opale V2 et des cartes en annexe 3a à 3d)

- La société Open Wide pour l'assistance technique avec comme intervenant M. PierreFicheux, Linuxien de renom, directeur technique de la société et enseignant, reconnu pour cescompétences dans le domaine et auteur de plusieurs ouvrages de référence chez Eyrolles. Laréponse au CCTP est en annexe 4.

2 - Etude des solutions possible

2.a - Le temps réel

Il existe de nombreuses définitions desystèmes temps-réel, certaines considèrent enpriorité la prédictibilité du temps d'exécutiond'une tâche, d'autres le mécanismed'ordonnancement et la gestion des prioritésd'exécution, ou encore la précision descaractéristiques temporelles. En fait unsystème dit "temps réel" est un système dont la validité du résultat dépend du temps d'exécution del'opération. En clair le système doit non seulement effectuer une opération de manière correcte maiségalement le faire avant une date limite, et ce quelle que soit l'activité autre du système. Enpratique, une opération est déclenchée par un événement interne (timer, demande d'une autre tâche,changement de valeur d'un paramètre, etc.) ou externe (interruption matérielle ou IRQ, changementd'état d'un capteur, horloge externe, etc.) et on dispose d'un certain délai pour la réaliser. Ondistingue deux type sde temps réel :

Temps réel strict : Si la limite de temps pour effectuer l'opération est dépassée, lecomportement normal du système n'est plus assuré et peut avoir des conséquences critiques pour lematériel. Le concepteur de l'application a l'obligation de prouver que le délai ne sera jamais dépasséquelle que soit la charge du système.

Temps réel souple : Il n'y a pas de limite de temps critique pour le système, mais on s'attache àce que le système utilise toute son énergie à la réalisation de notre tâche. Le concepteur du logicieln'est pas obligé de prouver son bon fonctionnement, mais seulement de le vérifier par des essais.

Comme on peut le voir le temps réel n'est pas forcément une notion de vitesse de réalisationmais plutôt de prédictibilité de durée, même si pour la plupart des systèmes temps réel stricts ledélai de réalisation est relativement court (de l'ordre de quelques micro ou millisecondes).

Linux, qui est un système d'exploitation utilisant la notion de temps partagé, n'est clairementpas capable de répondre à toutes les exigences du temps réel strict, mais en assouplissant certaines



contraintes et en ajoutant quelques fonctionnalités au noyau, il devient une solution bien adaptée.

La première chose à faire est de définir le niveau d'exigences pour notre système. Dans le casdu banc BEDYRA il est évident que le non respect des limites de temps pour le calcul destrajectoire et la commande de la table de vol supportant le matériel en test peut avoir desconséquences critiques pour l'intégrité du matériel. Toutefois, le système est conçu avec des garde-fous qui autorise au cour d'un tir l'absence de quelques consignes de commandes sans qu'il y ait deconséquence sur l'essai.

2.b - Les OS temps réel

Linux-RT également appelé Linux PREEMPT-RT pour ne pas le confondre avec RTLinux estun patch qui permet d'ajouter au noyau standard des fonctionnalités qui le rendent utilisable dans lecadre d'applications temps réel dures. Son développement fut démarré par Ingo Molnar et ThomasGleixner pour le noyau 2.6 et quelques unes de ses fonctionnalités ont été ajoutées au noyaustandard. Les principales modifications du noyau Linux concernent :

- La prise en compte des interruptions par des threads dans l'espace noyau, ce qui autorise lapréemption par une tâche de plus grande priorité des routines de traitement.

- Un système de prévention des inversions de priorité en mettant en place un héritage depriorité basé sur l'utilisation des sémaphores (mutex), pour éviter les blocages.

- Remplacement des verrous tournants (spinlocks) par des mutex pour éviter les attentesactives.

- Mise en place de compteurs à haute précision permettant d'exprimer les délais et leséchéances en µs.


Illustration 7: Principe de l'ordonnancement dans un noyau Linux classique.


RTLinux fut développé à l'Université du Nouveau Mexique par Victor Yadaiken et MichaelBarabanov de 1996 à 1999. Initialement sous licence GPL il fut commercialisé ensuite par la sociétéFSMLabs, puis sa technologie fut rachetée à partir de 2007 par la société Wind River propriétaire deVxWorks. Le principe de RTLinux dépend d'une couche logicielle intercalée entre le contrôleurd'interruption et les gestionnaires du noyau Linux. En pratique, une interruption activera un petitordonnanceur simple et déterministe capable de déclencher des tâches temps réel dans l'espacenoyau, puis lorsque les traitements temps réel seront terminés l'ordonnanceur du noyau Linuxclassique effectuera ses traitements. Cette technique est dite du "co-noyau".

RTAI pour Real Time Application Interface fut développé sur la base de RTLinux à l'EcolePolytechnique de Milan, sur le même principe de co-noyau que RTLinux..

Pour contrer le brevet déposé par FSMLabs, l'équipe de développement de RTAI inventa unnouveau mécanisme de gestion des interruptions nommé ADEOS. L'idée consiste à disposer d'unecouche logicielle basse qui capture les interruptions matérielles et les envoie dans un pipeline quiles distribue de manière synchrone à des OS fonctionnant en parallèle. On peut donc distribuer lesinterruptions dans un premier temps à un OS temps réel, puis ensuite à un système comme Linux.On obtient le même fonctionnement que RTLinux mais sans enfreindre les droits du brevet.


Illustration 8: Ordonnancement RTAI avant ADEOS, identique à RTLinux.


Les premières versions de RTAI ne pouvaient faire fonctionner que des tâches se trouvantdans l'espace noyau de Linux, sous forme de modules insérés dynamiquement (par la commandeinsmod) et disposant donc de tous les privilèges nécessaires aux opérations avec les périphériques.Par la suite un module de RTAI nommé LXRT a été développé afin de permettre l'ordonnancementde tâches temps réel dans l'espace utilisateur.


Illustration 9: Principe de fonctionnement d'ADEOS.

Illustration 10: Ordonnancement RTAI avecADEOS et LXRT.


Xenomai a débuté en 2001 par le projet de Philippe Gerum qui visait non pas à créer unnouvel OS temps réel mais un outil facilitant la migration d'un OS temps réel propriétaire vers unenvironnement Linux. Ce projet s'associa au projet RTAI en 2003 en raisonj des similitudes debesoin avec ADEOS. Philippe Gerum réalisa l'implémentation d'ADEOS et l'amélioration de ladisponibilité du noyau 2.6 pour RTAI. En 2005 le projet Xenomai redevient indépendant et proposeune première version d'un véritable OS. Dans le premier domaine d'ADEOS est installé unordonnanceur déterministe (Nucleus) et dans le second domaine le noyau Linux classique. Unprocessus de l'espace utilisateur peut démarrer un thread reconnu par Nucleus, qui aura donc unepriorité plus grande que toutes les tâches du noyau classique. Le problème de ce fonctionnement estune arrivée probable d'un cas d'inversion de priorité. En effet, un thread temps réel peut faire unappel système Linux et rendre le contrôle au noyau qui pourrait préempter et commuter vers uneautre tâche alors qu'il ne reçoit plus d'interruptions (le premier thread temps réel n'étant pasterminé), ce qui aurait pour conséquence une impossibilité de fonctionner et un blocage du système.Pour éviter ce problème RTAI interdisait les appels système dans les portions de code temps réelalors que Xenomai a adopté une approche différente en autorisant les processus à faire ces appelssystème, durant lesquels ils seront temporairement ordonnancés par Linux. Pour cela, ADEOS faitcirculer dans son pipeline des événements autres que les interruptions, comme les invocationsd'appels système ou les déclenchements de l'ordonnanceur Linux. Les threads Xenomai peuvents’exécuter soit en mode primaire, contrôlé par Nucleus, soit en mode secondair, contrôlés par lenoyau Linux, et la migration entre ces deux modes est réalisée automatiquement par ADEOS.

Exemple : Un thread Xenomai est lancé par un processus Linux. Ce thread démarreautomatiquement en mode primaire et se retrouve donc uniquement en concurrence avec les autresthreads temps réel Xenomai et le noyau Linux sera suspendu. Si ce thread fait un appel systèmevers le noyau Linux (write() par exemple) un événement de type "invocation d'appel système"circulera dans le pipeline d'ADEOS et sera capté par Xenomai qui fera migrer le thread en modesecondaire. Le noyau Linux est alors réactivé pour répondre à l'appel système, avec le risque quecelui-ci préempte la tâche pour une autre plus prioritaire, donc il n'y a plus de risque de blocagemais il faut alors attention à la perte de déterminisme.

Après avoir développé Xenomai et son API dite native prenant en compte toutes lesfonctionnalités nécessaires pour un système temps réel (gestion des tâches, synchronisation,communication entre tâches, gestion du temps, traitement des interruptions, etc.) les concepteurs ontintroduit la notion de skins. Les skins sont des interfaces logicielles permettant d'adapter du codesource provenant d'un autre système temps réel (Xenomai était à l'origine un outil de migration) telque Posix, pSOS+, VRTX VxWorks.

Afin d'écrire dans le noyau des drivers bas niveau capables de communiquer entre le matérielet Xenomai quelque soit le skin utilisé, il existe une interface nommée RTDM (Real Time DriverModel).L'écriture de drivers RTDM permet d'éviter les appels systèmes Linux et donc lesmigrations de domaine Xenomai/Linux. Cette API est très proche de celle utilisés pour l'écriture depilotes Linux.



2.c - Présélection

Au cours de ces 6 semaines a eu lieu la première partie de la formation de M. Pierre Ficheuxsur les sujets suivants :

- Principes et problématiques du temps réel

- Mise en œuvre de Preempt-RT et Xenomai sur une carte Raspberry-Pi

A la suite de cette première phase de recherche il s'avère que les deux solutions susceptiblesde convenir à notre projet sont Xenomai et Preempt-RT. En effet, RTLinux n'a pas été retenu car ilest devenu une solution propriétaire payante et que sa dernière version libre est trop ancienne et plussoutenue par la communauté car très peu utilisée. RTAI n'a pas été retenu car il a également étédélaissé par la communauté et le projet ne connaît que de très rares évolution, de plus RTAI etXenomai utilisent la même technologie mais ce dernier a évolué plus rapidement.


Illustration 11: Ordonnancement Xenomai.


Les points forts et faibles de Xenomai et Preempt-rt sont :

XenomaiXenomai Preempt-RTPreempt-RT

Pointsforts

✔Capacité à faire du temps réel strict✔Performances théoriques✔Evolution Dynamique✔Support de la communauté✔Nombre croissant d'utilisateurs professionnels✔Principe de skin facilite le portage

✔Simplicité de mise en œuvre✔Ne nécessite que des drivers Linux,donc pas de ré-écriture de drivers.✔Maîtrise de l'ordonnanceur Linux etmeilleure précision des horloges.✔Diffère peu de environnement actuel.✔Limite le portage des applicationsexistantes.

Pointsfaibles

✗Demande un portage des applications existantes (relativement faible grâce auxskins mais présent)✗Développement des drivers matériel avec l'API RTDM.✗Ne pas faire d'appel système dans les routines temps réel.

✗Capacité à faire du temps réel souple : est-ce suffisant ?✗Ne "bloque" pas le noyau Linux standard : bien maîtriser le développement des applications et l’environnement d’exécution.

3 - Ecriture de drivers spécifiques

Afin de tester les différentesarchitectures il est nécessaire d'avoir lesdrivers des cartes d'extension compatibles auxOS temps réel en test. Les 2 cartes d'extensionprincipalement utilisée pendant les séquencestemps réel sont la carte de mémoire réfléchieet la carte d'entrées/sorties. Cette partie dustage sera donc consacrée à l'apprentissage dedrivers Linux et à l'utilisation de l'API RTDMpermettant le développement de drivers pour Xenomai. La finalité sera de produire les driverscapables de faire fonctionner les cartes en assurant des performances temps réel suffisantes.

Dans ce cadre, la deuxième partie de la formation de M. Pierre Ficheux a eu lieu concernantles principes et le développement de drivers Linux et RTDM pour Xenomai.



3.a - Carte mémoire réfléchie PCIe-5565PIORC

La carte de mémoire réfléchie permet de partager très rapidement des données entre lecalculateur de commande et différentes cartes du banc (Carte de commande de la table de vol, cartesde générations de signaux, etc...). Ces cartes à base de FPGA utilisent une fibre optique pourcommuniquer entre elles sur une topologie en anneau. Un système de conversion etd'émetteur/recepteur sur une pile FIFO alimente directement une zone de mémoire RAM définie surle système. Cette zone est également créée sur les autres systèmes désirant partager ces données, etchaque carte gère la lecture et l'écriture de sa zone de mémoire. Les données écrites dans une zonemémoire sont immédiatement répercutées via la fibre optique aux autres cartes, qui mettent à jourleur propre zone de données. La configuration de ces cartes s'effectue via le bus PCI-express.

Après l'étude du fonctionnement de cette carte on peut s'apercevoir que son drivern'intervient pas dans le fonctionnement temps réel. En effet, une fois configuré correctement etaprès avoir défini les zones de mémoire sur chaque système désirant échanger des données, il suffitde faire des accès directs à la mémoire pour lire ou envoyer des informations de manière très rapide.

Il n'est donc pas utile de ré-écrire un driver spécifique, on pourra utiliser le driver Linuxfourni.

3.b - Carte d'entrées/sorties DAQe-2010

La carte d'entrées/sorties achetée permet de récupérer le signal de synchronisation externe


Illustration 12: Synoptique de fonctionnement de la carte VMIC PCIE-5565PIORC


pour cadencer les traitements temps-réel, de faire de l’acquisition de données si nécessaire pour unmatériel particulier, ou de générer des signaux de commande ou de signalisation particuliers. Lesdeux dernières utilisations ne sont pas prépondérantes dans le fonctionnement du banc, en revanchela synchronisation sur un signal externe est le cœur du bon fonctionnement du système, c'estpourquoi nous n'étudierons que cette fonctionnalité.

La méthode la plus couramment utilisée en informatique industrielle pour ses performancesconsiste à avoir une carte d’acquisition qui génère une IRQ matérielle à chaque front montantdétecté sur un port d'entré de cette carte.

Lorsque le processus temps réel du banc est lancé, il entre dans une boucle où il se met en attente d'une interruption via un driver du noyau. Lorsqu'une interruption externe est détectée, le matériel lève une IRQ qui est immédiatement traitée par le driver et libère notre processus dans l'espace utilisateur. Le processus effectue un calcul des informations nécessaires pour un pas du scénario et envoie les commandes au banc, puis se met a nouveau en attente d'une interruption.

Lors de la rédaction du CCTP relatif à cette fourniture, cette spécification n'avait pas étéclairement exprimée et il s'avère que les cartes DAQe-2010 ne permettent pas de lever une IRQ.Afin de résoudre ce problème j'ai proposé 2 solutions :

- Utiliser la carte DAQe-2010 et développer une interfaces qui utilise la méthode du pollingpour détecter un changement d'état sur un port d'acquisition.

- Utiliser une autre carte de GPIO pour récupérer la synchronisation externe et garder la carteDAQe-2010 pour les fonctions annexes.


Illustration 13: Principe de fonctionnement du logiciel du banc avec le cadencement externe.


Méthode du polling : Afin de tester la faisabilité de la méthode du polling, j'ai développé unobjet codé en C++, qui s’exécute en espace utilisateur et qui fait appel au driver standard de la carteafin de faire une acquisition régulière (dans une boucle). Cet objet possède une méthode qui se meten attente sur un changement de valeur de cette acquisition. Cette méthode fonctionne de manièreacceptable mais n'est absolument pas déterministe de par l'appel à un driver Linux non temps réel etdonc facilement préemptible par d'autres activités du noyau Linux.

Après quelques jours d'investigation et au vu du temps nécessaire pour ré-développer undriver temps réel pour la carte DAQe-2010, j'ai proposé une solution un peu originale qui consiste àutiliser un port parallèle du PC pour récupérer l'IT externe. Le port parallèle, qui été utilisé autrefoispour les imprimantes, a une conception relativement simple et permet de générer une IRQ lorsqueun changement d'état est détecté sur certaines de ses broches. Le port parallèle fonctionne avec unbuffer de 3 octets :

AdresseBase + 0 => Data port (D0 à D7 connecté aux broches 2 à 9)

AdresseBase + 1 => Status port (S3 à S7 connecté aux broches 15, 13 à 10)

AdresseBase + 2 => Control port (C0 à C4 connecté aux broches 1, 14, 16, et 17)

Lorsque le bit C4 de l'octet de contrôle est à 1, chaque front montant sur la borne 10 (ou S6)provoque une IRQ associée au port parallèle. Cette borne est à l'état haut par défaut, il a donc fallufaire un petit montage à base de transistor pour adapter le signal de synchronisation externe qui luiest de forme TTL. Ensuite j'ai développé un driver en espace noyau qui traite cette IRQ. Ce driverutilise les IOCTL pour se mettre en attente d'une interruption et rend la main au processus appelantlorsqu'une interruption arrive.

Les PC récents et nos calculateurs ne sont pas pourvus de port parallèle, j'ai donc acheté descartes d’extension au format PCI express. Il a également fallu mettre en place une procédured'installation afin que le driver par défaut ne gère pas l'IRQ. Le code du driver, le scriptd’installation et les logiciels de mise en œuvre sont en annexe 5 pour Linux et preempt-RT et enannexe 6 pour Xenomai. Le logiciel de test consiste en une simple boucle qui se met en attente surl'IT externe et retourne le temps de l'horloge avec une précision temps réel (ns).

Au vu des premiers résultats cette solution permet de continuer la procédure de test desdifférents systèmes temps réel, toutefois elle nécessitera quelques validations supplémentaire,notamment sur les temps de réponse de l'ensemble.

4 - Choix des solutions et mise en œuvre

Les premières parties du stage ontpermis de mettre en évidence les difficultés dudéveloppement temps réel et d'avoir un aperçudes solutions envisageables. Il s'agitmaintenant de déployer ces solutions sur lescalculateurs et de réfléchir à l'environnementde travail. Afin d'avoir les meilleuresperformances possibles, il est conseillé d'avoir



une approche identique au développement pour les applications embarquées, c'est à dire de produiresa propre distribution Linux ne possédant que les outils nécessaires à l'exécution du programmetemps réel qui sera installé sur le calculateur. Une machine sera équipée d'un atelier dedéveloppement et d'une chaîne de compilation croisée.

4.a - Présentation de BuildRoot

Buidroot est un outil permettant de créer sa propre distribution Linux pour l'embarqué, baséesur la uClibc. Le but de uClibc est de fournir une solution alternative à la Glibc qui est labibliothèque de référence mais très complexe et volumineuse. La bibliothèque uClibc est 6 fois pluslégère que la Glibc et ses fonctionnalités sont largement suffisantes pour la plupart des projetsLinux embarqués. Buildroot est un ensemble de fichiers Makefile et de scripts shell permettant deconstruire les outils de production, puis la distribution cible à partir des données d'entrée :

- les archives des sources des composants obtenues directement dans leur version non-adaptéesur les sites des projets.

- la configuration fournie par l'utilisateur : l'architecture cible, les composants à intégrer, laversion du compilateur et d'uClibc.

- les différents patches fournis par Buildroot

En plus de la distribution, Buildroot est capable de produire la chaîne de compilation croisée.

4.b - Choix de l'environnement de travail

Actuellement les équipes de développement ont l'habitude de travailler sur le calculateur, maisen mode déporté via ssh depuis différents postes. Les outils de développement et debug sontinstallés sur le calculateur. Lorsqu'une campagne d'essais se déroule, il convient d'éviter d'utiliser lecalculateur pour exécuter des tâches demandant beaucoup de ressources car les processus temps réelauront la priorité. L'avantage de ce mode de travail est de pouvoir debugger sur la machine cibleavec l'environnement matériel courant.

Le choix définitif de l'environnement de travail sera effectué après avoir organisé une réunionavec les équipes de développement de DGA-MI et de la société THALES. C'est pourquoi j'ai décidéde mettre en place et tester les solutions suivantes :

- Un noyau Linux standard 3.8.13 d'une distribution classique, la FEDORA 20 avec un bureauallégé (Xfce).

- Un noyau Linux 3.8.13 patché avec Preempt-RT (3.8.13-rt16), sur une distribution classique,la FEDORA 20 avec un bureau allégé (Xfce).

- Un noyau Linux 3.8.13 patché avec Xenomai 2.6.3, sur une distribution classique, laFEDORA 20 avec un bureau allégé (Xfce).

- Un noyau Linux 3.8.13 patché avec Preempt-RT (3.8.13-rt16), compilé avec BuildRoot et



mise en place d'une chaîne de compilation croisée.

- Un noyau Linux 3.8.13 patché avec Xenomai 2.6.3, compilé avec BuildRoot et mise enplace d'une chaîne de compilation croisée.

4.c - Déploiement

Les 3 premières solutions n'ont pas posé de problème particulier pour leur compilation et leurdéploiement. Il convient de faire attention aux options de compilation du noyau spécifiques àXenomai. Les 3 solutions ont été déployées en parallèle sur un seul calculateur grâce au programmede multi amorçage GRUB 2.

La compilation et la configuration de Buildroot a posé beaucoup plus de problèmes, lesfichiers de configuration standard ne permettant pas de créer la chaîne de compilation pour unecible x86 en 64 bits. Le manque de connexion directe à internet pour des raison évidente deconfidentialité ne m'a pas permis de mettre en place ces solutions suffisamment rapidement, et celamalgré l'assistance technique dont nous avons bénéficié.

Quelques photos du matériel mis en œuvre sont présentées en annexe 7.

5 - Réalisation des tests

Les tests sur chaque architecturepermettent non seulement de valider lacapacité à faire du temps réel mais aussi decomparer les performances de chacune.

Voici la listes des tests effectués :

Précision de gettimeofday() : La fonction gettimeofday() permet de dater des événementsavec une granularité d'une microseconde, cependant certains systèmes n'ont qu'une précision del'ordre de plusieurs µs. Un petit programme simple effectuant une boucle dans laquelle il ne fait quedes appels à la fonction gettimeofday() dont le résultat est sauvegardé, puis affiché à l'issue del'exécution de la boucle, permet de mettre en évidence cette caractéristique.

Précision de clock_gettime() : La fonction clock_gettime() est une fonction Posix qui permetégalement de dater les événements mais avec une résolution d'une nanoseconde et une précisiontemps réel. Le même programme que précédemment permet de vérifier que la précision est bienmeilleure que la µs.

Vérification du jitter par interruptions logicielles : La plupart des systèmes temps réels'appuient sur des tâches périodiques qui doivent s'exécuter avec la meilleure efficacité et lamoindre variabilité possible. Il existe plusieurs appels système permettant de réaliser des actions



périodiques en utilisant des timers. Le logiciel servant à vérifier cette caractéristique configure etlance un timer Posix (timer_create()) qui à chaque déclenchement mesure le temps système avec lafonction clock_gettime(). A l'issue de la boucle de mesure, le logiciel affiche l'écart pour chaque pasde mesure entre la période théorique et la période réelle. Nous comparons les valeurs maximale etmoyenne de ce test réalisé avec différents niveaux de priorité temps réel.

Vérification de la préemption des tâches : L'utilisation du test précédent avec différentesvaleurs de priorité temps réel et l'utilisation de programmes perturbateurs permet de mettre enévidence la préemption plus ou moins fréquente de notre tâche.

Vérification du temps de commutation entre threads et processus : Un point important dans lessystèmes temps réel est de connaître le temps de commutation entre deux tâches synchronisées surune ressources partagée. Pour mesurer le temps de commutation entre deux threads, il suffit que lesdeux se synchronisent sur un mutex et partagent une variable globale et qu'ils effectuent la séquencesuivante :

Le principe de mesure du temps de commutation entre processus est le même mais nécessitela mise en place d'une zone de mémoire partagée pour stocker le temps système avant commutationet le tableau de résultats, et l'utilisation d'un sémaphore nommé (pour le partage explicite de l'espacemémoire).

Vérification du jitter par interruptions matérielles : Ce test est identique dans sa réalisation àla mesure du jitter par interruptions logicielles, mais le déclenchement de la mesure ne sera paseffectué par un timer logiciel mais par un signal externe, représentatif des IT400 qui synchronisentle banc réel. Ce test permet de vérifier le bon fonctionnement de la méthode basée sur le portparallèle et du driver développé. L'interruption externe est fournie par un générateur de fonctionclassique, au format TTL (0 / 5v) et à différentes périodes. Afin de faciliter le travail desdéveloppeurs, j'ai conçu une API sous forme d'objet C++ qui permet de se mettre en attente sur une


Illustration 14: Mesure du temps de commutation entre tâches.


IT externe, qui implémente quelques fonctions de sécurité et qui fait l'interface avec le driver.

Test représentatif de la mise en œuvre réelle : Le dernier test est représentatif de la mise enœuvre effective dans le banc. Un processus se met en boucle en attente sur une interruption externe.Lorsque le processus est libéré, il réalise une tâche de calcul simulant la réalité, il écrit des donnéesdans la zone de mémoire réfléchie, puis envoie des commandes via Ethernet à un PC distant. Lorsde ce test une mesure de temps permet de déterminer le nombre de dépassements du délai deréalisation.

En complément de ces tests, il existe d'autres outils de mesure de performances et notammentdans le projet rt-tests maintenu par Clark Williams :

- Cyclictest, qui permet de mesurer les fluctuations et latences de différents paramètres.

- Hwlatency, qui mesure les latences dues au matériel. Il effectue des mesures en boucle dansl'espace noyau pour vérifier si il n'est pas préempté par des interruptions non maîtrisées.

- Hackbench, qui effectue des mesures de commutation. Ce programme est très intensif et estégalement utilisé pour perturber le système.

- Pi_stress, qui permet de vérifier l'implémentation des héritages de priorités sur les mutex.

Bien évidemment, tous ces tests ont été réalisés sur un système peu et très chargé par d'autresprogrammes perturbateurs, et avec différentes priorités temps réel. Au vu des premiers résultats, j'aiégalement décidé de travailler depuis un poste distant en ssh afin de ne pas faire fonctionnerl'environnement graphique X11 qui pénalise fortement le temps réel.


Illustration 15: Test de mise en oeuvre.


Reste à faire

L'ensemble du plan de test n'a pas encoreété réalisé, notamment le test représentatif dela mise en œuvre réelle qui demande beaucoupde ressources. J'envisage également d'effectuerune partie de cette batterie de test sur lecalculateur actuel afin d'avoir non seulementdes valeurs comparatives, mais également desvaleurs de performances minimales absolues.Une fois le système sélectionné, je penseégalement refaire des séries de tests en modifiant certain paramètre de compilation du noyau afind'optimiser les performances attendues.

Etant en formation continue et affecté au banc BEDYRA, le projet devra être mené à sonterme après la fin du stage. Contractuellement je dois livrer le calculateur installé et validé à lasociété THALES pour le mois d'octobre.

Il reste également à formaliser les résultats des mesures dans un document officiel et rédigerun manuel d'utilisation du système temps réel.

Les équipes de développement n'ayant jamais travaillé avec Xenomai, j'ai également organiséavec Pierre Ficheux une session de formation au développement de projet Xenomai en espaceutilisateur qui se déroulera le 26 août.

La dernière partie du stage concernant le développement d'une application de commande de latable de vol n'a pas pu être menée à son terme, mais sera également effectuée à l'issue du stage.

Conclusion

Ce stage a été pour moi la première occasion de mener un projet d'envergure seul. Il a nonseulement fallu utiliser mes compétences techniques, mais également organiser le travail, gérer lecoté administratif des approvisionnements, dialoguer avec les utilisateurs du système pour trouverun consensus, et prendre et justifier des décisions ayant un impact très important sur le service.

Les difficultés rencontrées, notamment d'approvisionnement, on été un frein important au bondéroulement du stage, mais sont représentatives du fonctionnement normal d'un service techniquede cette taille.

Il était important pour le service de reprendre la maîtrise technique des aspects temps réel dubanc et je pense que ce stage va non seulement me permettre d'atteindre ce but, mais également departager cette compétence avec les équipes de développement. J'envisage de réaliser, à l'occasion dela rédaction du manuel d'utilisation, un tutoriel de déploiement, configuration, et développementd'application sous Xenomai (pourquoi pas sur la version 3) et peut être un cours sur le sujet.

Au final, l'achat des 3 calculateurs complets et des cartes d'extension a coûté environ 40 000€et l'assistance technique 10 000€, alors que le prix de l'ancien système était de l'ordre de 100 000€



pour un seul calculateur et une assistance de 4 ans. On peut donc dire que l'objectif de réduction descoût est également atteint.

Bibliographie

[1] "Solution temps réel sous Linux" de Christophe Blaess, édition Eyrolles

[2] "Linux embarqué (4e édition)" de Pierre Ficheux et Eric Bénard, édition Eyrolles

[3] "Linux embarqué – Comprendre, développer, réussir" de Gilles Blanc, édition Pearson

[4] "Real-Time Systems and Programming Languages – Ada, Real-Time Java, and C/Real Time POSIX (4e édition)" de Alan Burns et Andy Wellings, édition Addison Wesley

[5] "Développement système sous Linux (3e édition)" de Christophe Blaess, édition Eyrolles


master e marc favereau...présentation du sujet 1 - contexte d'emploi 1.a - le banc bedyra le...

Documents