Systèmes temps réel et logiciel libre Pierre FICHEUX (pierre.ficheux@openwide.fr) Avril 2012 1
Présentation Open Wide SSLL créée en septembre 2001 avec Thales et Schneider => 10 ans d'expérience! 120 collaborateurs sur Paris, Lyon et Toulouse Dont une dizaine de collaborateurs à Toulouse. Aujourd'hui => Leader en France des technologies Open Source Deux activités : Informatique Indutrielle Intégration SI 2
Présentation PF Ingénieur Arts et Métiers + Sup'Aéro Utilisateur de logiciels libres depuis 1989 Utilisateur de Linux depuis 1992 Auteur des trois éditions de l'ouvrage «Linux embarqué» (Eyrolles), la 4ème sortira en juin 2012 Auteur GNU Linux Magazine CTO Open Wide Ingénierie 3
Introduction au temps réel 4
Le temps en informatique Certains systèmes sont liés au temps à différents niveaux : un distributeur de billets ne doit pas mettre 5 minutes à délivrer les billets une balance ne doit pas peser en 30 secondes un radar ne doit pas mettre 2 secondes à réagir un système de freinage ne doit pas mettre plus de 150 ms pour acquérir l information et réagir D'autres systèmes ne le sont pas, si l'on reste dans les limites raisonnables du «temps de réponse» 5
Système temps-réel Caractéristiques : exactitude logique (comme tout système) : les sorties sont déterminées en fonction des entrées et de l état interne exactitude temporelle : réaction appropriée en un temps borné à un événement Exigences sur le l'échéance temporelle et non pas sur les performances ni le rendement Un micro-contrôleur 8 bits sous µc/os-ii peut être temps-réel alors qu'un PC sous Linux ne l'est pas! 6
Les types de temps-réel Temps-réel mou : un retard dans l obtention du résultat n est pas dramatique (distributeur de billets) Temps-réel dur : un retard dans l obtention du résultat le rend inutile (pilotage matériel) Temps-réel «ferme» : un retard, s il arrive très peu souvent, peut être toléré (téléphonie, multimédia) La plupart des systèmes temps-réel modernes sont «hybrides» (exemple : Linux/Xenomai) Certaines tâches sont temps-réel (dur) D'autres ne le sont pas ou peu (mou/ferme) Frontière mou/dur parfois difficile à définir! 7
Approches asynchrone / synchrone Asynchrone Synchrone Interaction avec l'environnement (interruption), dérive d'horloge entre calculateurs Modélisation complexe (nombreux cas de préemption) Modélisation statique du comportement Pas d'interruption ni d'allocation dynamique Convient aux systèmes critiques Langages dédiés, génération de code (ESTEREL, SIGNAL, SynDEx) 8
Cible matérielle Deux cas de figure : Pas de système d'exploitation (Bare Board) Système critique et/ou certifié (DO-178, CEI 61508,...) Éventuellement un simple «exécutif» temps réel Utilisation d'un RTOS Plus de souplesse et portabilité Certification possible sur certains OS : VxWorks 653 (Wind River), LynxOS-178 / LynxOS-SE (LynuxWorks), INTEGRITY- 178 (Green Hills) 9
GPOS (Windows, Linux,...) Lissage des priorités (dynamique) => complexe RTOS Grand nombre de tâches concurrentes (> 200 sur un PC Linux «inactif») 15M lignes de code pour le noyau Linux 3.x! RTOS Prévisible : évaluer le pire des cas Déterministe : faible influence de la charge Pas ou peu de notion de «performances moyennes» Peu de tâches concurrentes Simple, léger, faible consommation (< 100K lignes de code pour FreeRTOS) 10
Domaines d'application 1960-70 : remplacer la mécanique et la logique «câblée» lorsque c'est possible (souplesse) 1980 : RTOS génériques Historique Militaire, spatial (RTOS/360, VRTX sur Hubble) Contrôle de processus industriel Transport : AUTOSAR/OSEK, ARINC 653 Internet/Telecom : routeurs, PABX (Chorus) Assimilé / émergent (temps-réel mou, embarqué) Multimédia : audio, vidéo, TV, automobile (GENIVI), Téléphonie, médical L'équivalence embarqué Systèmes temps <=> réel et LL RTOS n'est plus 11
Architecture d'un RTOS Basé sur un noyau associé à un ensemble de services Deux types de noyau Monolithique : contient tout le code nécessaire à la gestion du matériel (ex : Linux) Micro-noyau : fournit uniquement la gestion de base => associé à un autre noyau (Linux/ADEOS) 12
Logiciel libre et temps réel (Linux) 13
Utilisation du logiciel libre Avantages Disponibilité du code source: maintenabilité dans le temps Redistribution sans royalties Développement dérivé de code source existant Inconvénients Contraintes de certaines licences (GPL, LGPL) Support technique Outils disponibles / RTOS propriétaires 14
Réservé aux systèmes complexes Linux pour le temps réel? Gestion complexe de la mémoire (MMU) Empreinte mémoire importante: 2 Mo pour µclinux, 4 Mo pour Linux Consommation mémoire vive : 16 Mo minimum Alternatives libres: ecos, RTEMS, FreeRTOS beaucoup plus légers Migration temps réel des anciens RTOS complexe évolution avec les extensions PREEMPT-RT et Xenomai Incompatible avec les systèmes critiques Souvent utilisé pour les outils, les simulateurs et architectures «mixtes Systèmes temps» (banc réel et LL de test) 15
Extensions TR pour Linux API POSIX (threads, ordonnancement) disponible Le noyau Linux n'est pas «préemptif» (10 ms) Traitement des IRQ SMP Deux approches Optimisation du noyau PREEMPT-RT (500 µs à 1 ms) Architecture à double noyau (10/20 µs) RTLinux RTAI Xenomai Les patch preempt-kernel et low-latency (pour noyau 2.4, intégrée au 2.6) sont OBSOLETES 16
PREEMPT-RT Patch expérimental sur base 2.6.x (-rt), à partir du 2.6.15 http://rt.wiki.kernel.org Disponible sur quelques architectures (utilisé surtout sur x86) ARM, Nios II, MicroBlaze Threaded interrupt model thread noyau pour la prise en compte des interruptions Prévention des inversions de priorité (par héritage) Réécriture complète des mécanismes de synchronisation Timers noyau haute précision (sous-système hrtimer) dépend du matériel Bons résultats sur CPU «puissants» (16 ms 70 µs) 17
Tâche périodique, noyau standard non chargé 18
Tâche périodique, noyau standard chargé 19
Tâche périodique, PREEMPT-RT chargé 20
Linux + co-noyau Séparation entre le composant temps-réel et Linux Ordonnanceur temps-réel spécifique Pas de dépendance sur les sections critiques Linux :-) Virtualisation de la gestion d'interruptions Linux Routage prioritaire des interruptions vers le conoyau Linux comme tâche idle du co-noyau Historique : RTLinux (1999) devenu un produit commercial de FSMLabs puis Wind River (2007) Brevet logiciel aux USA :-/ 21
Utilisation et performances Changement minimal sur le noyau Linux patch de virtualisation d'interruptions pas d'impact sur l'écriture de code noyau classique Impact sur l'écriture de code temps-réel! utilisation d'apis fournies par le co-noyau notion de domaine d'exécution (temps-réel / normal) Garanties temps-réel fortes ordonnanceur spécifique indépendant sous-système temps-réel bien délimité Gigue maximale de l ordre de 20 µs :-) 22
RTLinux Projet universitaire (New Mexico Tech) développé par Victor Yodaiken et Michael Barabanov en 1999 Développement en espace noyau Produit commercial développé par FSMLabs Dépôt d un brevet logiciel conflit avec la FSF Vendu à Wind River en 2007 Version GPL obsolète (2.6.9) mais toujours disponible 23
Architecture RTLinux 24
Test de RTLinux, noyau 2.4.17 (2002) 25
RTAI Real Time Application Interface Un «fork» de RTLinux développé au DIAPM de l école polytechnique de Milan Dipartimento di Ingegneria Aerospaziale (Paolo Montegazza) Utilisé au DIAPM pour des travaux d enseignement et de recherche Position douteuse / brevet logiciel FSMLabs Collaboration avec Xenomai entre 2003 et 2005 RTAI/Fusion Toujours actif mais peu d évolution version 3.8 en février 2010 26
Xenomai Xenomai est un sous-système temps-réel de Linux : Faible latence Programmation de tâches en espace utilisateur dualité d'ordonnancement Linux / Xenomai RTOS générique + interfaces (skins) émulation de RTOS traditionnels Pilotes spécifiques (RTDM) Supporte de nombreuses plate-formes (x86, ARM, PowerPC, Nios II, Blackfin) Licence GPL (cœur), LGPL (interfaces, espace utilisateur) Projet très actif! 27
Architecture Xenomai 28
Comparaison Linux / Xenomai 29
Autres exemples de RTOS libres 30
ecos Embeddable Configurable OS (CYGNUS 1997) Supporte de nombreux CPU 16, 32 et 64 bits Empreinte mémoire de 10 à 100 Ko Outils de configuration avancé, gestion de «packages» Version «pro» par Utilisé dans le multimédia : http://www.ecoscentric.com/ecos/examples.sht ml Voir la présentation de Jean-Jacques PITROLLE 31
RTEMS Real-Time Executive for Missile/Military Systems RTE for Multiprocessor Systems Développé depuis 1988, libre depuis 1994 32 bits CPU (8/16 bits avec TinyRTEMS) API POSIX, ARINC 653 (AIR/ESA) Programmation C/C++/Ada Empreinte minimale entre 64 et 128 Ko (256 à 400 Ko suivant le nombre de paquets) Utilisation industrielle (ESA, EADS,...) Large communauté de développeurs http://wiki.rtems.org/wiki/index.php 32
RTEMS, bibliographie http://air.di.fc.ul.pt/air/ http://neutrons.ornl.gov/workshops/epics2007/ presentations/epics071013-rtems-epics- Knoxville-2007.ppt https://moodle.dce.fel.cvut.cz/pluginfile.php/15 70/mod_resource/content/0/svs_rtems_intro.pd f http://www.ris.prd.fr/gt/ll/presentations/05- planche.pdf 33