Solutions libres pour les systèmes embarqués Pierre FICHEUX (pierre.ficheux@openwide.fr) Mars 2015 1
Programme Présentation Rappels sur les systèmes embarqués et temps réel Le logiciel libre Linux comme système embarqué Extensions temps réel de Linux Android «embarqué» ecos et RTEMS Les outils libres pour l'embarqué Open hardware Co-design 2
Présentation Open Wide Société d'ingénierie créée en septembre 2001 avec le concours de THALES et Schneider Electric Rachat d'esg-france (automotive) en 2014 Environ 160 salariés sur Paris, Lyon, Toulouse et bientôt Grenoble Industrialisation de composants open source Développement Conseil / Formation Trois activités : OW Système d'information (Java/PHP) OW Outsourcing: hébergement OW Ingénierie: informatique industrielle 3
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 4 éditions de l'ouvrage «Linux embarqué» (Eyrolles), 4ème édition parue en juin 2012 avec E. Bénard Auteur GNU Linux Magazine et Open Silicium CTO Open Wide Ingénierie, enseignant EPITA, ENSEIRB 4
Rappels sur les systèmes embarqué 5
Système / logiciel embarqué Un système est l'association matériel + logiciel Logiciel utilisé dans un équipement industriel ou un bien de consommation On dit aussi logiciel dédié ou intégré embedded software L'équipement est valorisé pour son coté fonctionnel et non pas pour le logiciel! Un bon logiciel embarqué doit savoir se faire oublier! On parle parfois de logiciel enfoui ou profondément enfoui «deeply embedded» 6
Domaines d'application 1960-70 : remplacer / compléter des systèmes analogiques (spatial) 1980 : RTOS (Real Time OS) génériques 2000 : OS libres, grand public Domaines historiques/industriels Militaire, spatial (RTOS/360, VRTX sur Hubble) Contrôle de processus industriel Transport : AUTOSAR/OSEK, ARINC 653 certification (DO-178) Internet/Telecom : routeurs, PABX «Nouveaux» domaines Multimédia automobile (IVI), objets connectés médical 7
Les nouveaux domaines Équipement grand public (multimédia, domotique, ) Téléphonie 1+ milliards de téléphones Android! Infotainment transport: automobile, aéronautique Ajout de fonctions communicantes utilisation de protocoles standards de type IP et dérivés (HTTP, DHCP, etc.) Difficile d'intégrer ces couches dans des logiciels embarqués propriétaires utilisation d'un OS «Boite noire» dédiée à un ensemble de fonctions (passerelle médicale, set-top box avec services étendus) Internet des objets #iot :-) 8
Avantages d'un OS Affranchit le développeur d'un travail d'adaptation au matériel pour les interfaces de base (PCI, USB, Ethernet...) Permet de bénéficier des dernières avancées technologiques et de faire évoluer le système: protocoles réseau, multimédia, etc. Recrutement aisé de développeurs (Linux, Android)! Utilisation de matériel «standard» Focalisation sur le métier de l'entreprise 9
Inconvénients d'un OS Empreinte mémoire Performances Consommation d'énergie (nombreux travaux en cours) Criticité (sauf OS spécialisés) Perte de maîtrise du système 10
Les systèmes temps réel Les applications embarquées historiques étaient temps réel Les systèmes d'exploitation embarqués propriétaires sont TR (VxWorks, LynxOS, VRTX,...) RTOS La progression des OS libres dans l'industrie et dans l'embarqué en général modifie la donne! Linux est utilisable dans l'industrie Linux n'est pas TR Linux peut être modifié pour être TR (PREEMPT-RT, Xenomai) Il existe des RTOS libres (RTEMS, FreeRTOS,...) 11
Le logiciel libre dans l'embarqué 12
Historique Modèle économique du marché informatique du matériel vers le logiciel Projets logiciels libres majeurs (chronologie) UNIX BSD X Window System (X11) GNU (tout d'abord sur UNIX propriétaire) Linux GNU/Linux Apache Apparition de licences libres (vs «freeware») BSD GPL (dérivation et «contamination») ASL 13
Quelques éléments sur le LL A peu près équivalent à la notion d'open source, voir http://www.opensource.org Libre ne veut pas dire gratuit La confusion vient de la signification anglaise free = libre / gratuit Différents types de logiciels Le freeware : gratuit mais sources non disponibles, pas forcément de licence (abandon de la «paternité» du code) Le shareware : sources non disponibles, coût modique, licence souvent propriétaire Le logiciel libre: sources disponibles, licence open source, non liée à la notion de gratuité (on peut vendre un logiciel libre) 14
Importance du logiciel libre Le logiciel libre est important dans le SI (serveurs) Le logiciel libre a pris un part importante dans les systèmes embarqués OS (Linux, Android) Outils de base (compilateur, éditeur, débogueur,...) «build systems» (Buildroot, Yocto/OE) IDE (Eclipse) La plupart des éditeurs ont au catalogue des composants basés sur du logiciel libre (Wind River, Adacore, LynuxWorks,...) 15
Avantages/inconvénients du LL Avantages Disponibilité du code source maîtrise et maintenabilité dans le temps Redistribution sans «royalties» Outils de développement souvent «gratuits»! Support de la communauté Inconvénients Méfiance vis à vis d'un modèle décentralisé (support) Contraintes de certaines licences (GPL, LGPL) Support de certains matériels (?) Outils moins «ciblés» Documentation (?) 16
Les OS libres pour l'embarqué 17
Linux comme (RT)OS Réservé aux systèmes complexes 32 bits minimum Gestion complexe de la mémoire (MMU, pagination + segmentation) Empreinte mémoire importante: 2 Mo pour µclinux (sans MMU), 4 Mo pour Linux Consommation mémoire vive : 16 Mo minimum Problème de migration de anciens RTOS car Linux n est pas TR évolution avec les extensions PREEMPT-RT et Xenomai Incompatible avec les systèmes critiques/certifiés Souvent utilisé pour les outils, les simulateurs et architectures «mixtes» (banc de test) 18
Linux et le TR, ooops :( 19
Extensions TR pour Linux L'utilisation de Linux comme RTOS est souvent intéressante POSIX Approche hybride avec quelques tâches TR On conserve le confort d'un système classique Deux approches possibles : Modifier le noyau Linux afin d'améliorer ses performances TR (PREEMPT-RT) Ajouter un «co-noyau» TR qui partage le matériel avec le noyau Linux (RTLinux, RTAI, Xenomai) approche «virtualisation» 20
PREEMPT-RT Branche expérimentale pour le noyau 2.6, voir https://rt.wiki.kernel.org Initié par Ingo Molnar, contributeur majeur du noyau Maintenu par Thomas Gleixner Surtout utilisé sur x86 et des processeurs performants (TSC = Time Stamp Counter) Fonctionne également sur ARM (11 ou plus), Nios II, Microblaze,... Nécessite un noyau «mainline» (ou proche) mais ne sera probablement jamais intégré à la branche officielle Mise en place très simple (application d'un patch) Mêmes API de programmation que Linux standard 21
PREEMPT-RT, caractéristiques Utilisation d'un thread noyau (interruptible) pour le traitement de chaque interruption 4 2 root SW< 0 0% 0% [sirq-high/0] 5 2 root SW< 0 0% 0% [sirq-timer/0] 6 2 root SW< 0 0% 0% [sirq-net-tx/0] Prévention des inversions de priorité (par héritage) Timers noyau haute précision (HRTIMER) Amélioration des mécanismes de synchronisation Le résultat est un noyau (presque) «préemptif», mais reste un noyau Linux 22
PREEMPT-RT, résumé Changements significatifs du code noyau Verrouillage des sections critiques Volume du patch important Utilisation de mlockall() verrouillage des pages mémoire en RAM Le coût de la préemption peut être important si le nombre de tâches TR augmente Temps de latence maximum nettement amélioré dépend largement de la plate-forme matérielle (TSC) dépend de la configuration logicielle Bons résultats sur x86 depuis de nombreuses années Permet de garantir moins de 50 µs de jitter (x86) Risque sur la maintenance (financement)? 23
Linux avec co-noyau Ajout d'un «co-noyau» pour la gestion du temps-réel Sous-système temps-réel intégré à un module noyau Patch de «virtualisation» des interruptions Différents modèles de programmation Noyau uniquement (RTLinux, version libre) Noyau et espace utilisateur, semi-intégration Linux (RTAI, www.rtai.org) Noyau & espace utilisateur, intégration Linux complète (Xenomai, www.xenomai.org) 24
Linux avec 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 IRQs vers le co-noyau Linux comme tâche idle du co-noyau Volume du patch noyau plus faible qu'avec PREEMPTRT Se rapproche de la technique de «para-virtualisation» des hyperviseurs (adaptation de l'os) 25
Linux + co-noyau, suite Peu de modifications sur le noyau Linux patch de virtualisation (très bas niveau) notion de domaine d'exécution (temps-réel / normal) Pas d'impact sur l'écriture de code noyau classique Impact sur l'écriture de code temps-réel! utilisation des API fournies par le co-noyau Excellentes performances TR ordonnanceur spécifique indépendant sous-système temps-réel bien délimité jitter maximal de l ordre de 10 µs sur Atom/x86! 26
RTLinux Projet universitaire (NMT) développé par Victor Yodaiken et Michael Barabanov en 1999 Produit commercial développé par FSMLabs Dépôt d un brevet logiciel conflit avec la FSF Vendu à WIND RIVER en 2007 Développement en espace noyau (?) Version GPL obsolète (2.6.9) retirée par WIND RIVER 27
Architecture initiale RTLinux 28
RTLinux en 2002 29
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 Quelques utilisations industrielles Position douteuse / brevet logiciel FSMLabs Toujours actif mais peu d évolution version 3.8 en février 2010, 3.9 en août 2012 30
Xenomai Xenomai est un sous-système temps-réel de Linux Programmation de tâches en espace utilisateur API d'application et de pilotes temps réel (RTDM) dédiées Intégré au noyau Linux «Real-time sub-system» Supporte de nombreuses architectures Dispose de «skins» permettant d'émuler des API temps réel (POSIX, VxWorks, VRTX, uitron,...) Plus complexe à mettre en œuvre que PREEMPT-RT mais performances 5 à 10 fois supérieures Licence GPL (cœur), LGPL (interfaces, espace utilisateur) 31
Architecture générale Xenomai utilise un micro-noyau (ADEOS) pour partager le matériel avec le noyau Linux Un processus contient des threads TR et TP (Linux) Processus Linux pilote TR API TR noyau TR micro-noyau 32
Répartition sur les deux domaines libpthread_rt Code applicatif VxWorks glibc Code applicatif POSIX Xenomai libvxworks glibc Xenomai libpthread Appels système Noyau Linux Pile réseau VFS/FS Xenomai RTOS... Noyau Adeos I-Pipe Hardware 33
Linux/Xenomai et le TR :) 34
Android Android = un système d'exploitation basé sur un noyau Linux Un «framework» fournissant des applications et permettant d'en ajouter facilement Basé sur Dalvik (puis ART), une machine virtuelle Java (très) optimisée pour le mobile Navigateur web basé sur Webkit puis Chrome Graphique optimisé en 2D ou 3D basé sur OpenGL/ES Nouvel environnement de développement «Android Studio» compatible avec Android «wear» (#IoT) Partiellement open source mais pas réellement du logiciel libre... 35
Android et l'industrie Linux fournit des API graphiques (Qt, EFL) mais «difficiles» à programmer Android est avantageux si le projet utilise une IHM Base importante d'applications Android! Android est conçu pour la téléphonie et les tablettes mais des BSP Android sont fournis pour les cartes (ARM) récentes (BB Black, i.mx6,...) Android utilise un noyau Linux :-) Assez peu de projets pour l'instant Concurrence de Yocto! 36
Avantages/inconvénients Avantages Programmation Java (simple et répandue) + IHM Communauté importante Fait rêver les managers (tablette = grand public bon marché) Inconvénients Compatibilité POSIX partielle Système de «build» statique assez rudimentaire par rapport à ceux de Linux (Buildroot, OE) Qualité des BSP variable mais portage «simple» Pas réellement un projet libre ni communautaire :-( Google fait peur! Interfaces matérielles industrielles non supportées (CAN, I2C, SPI, ) 37
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 «paquets» Version «pro» par Utilisé dans le multimédia : http://www.ecoscentric.com/ecos/examples.shtml 38
RTEMS RTEMS = Real Time Executive for Multiprocessor Systems Initialement «Missile Systems» puis «Military Systems» Exécutif temps réel embarqué diffusé sous licence libre (GPL avec exception) Ce n'est pas exactement un système d'exploitation car l'application est «liée» au noyau un seul processus mais plusieurs «threads» Programmation C, C++, Ada Plus de 100 BSP disponibles pour 20 architectures API RTEMS «classique» ou POSIX Utilisé par EADS Astrium, ESA, NASA, etc. 39
RTEMS, suite RTEMS est un exécutif TR : Un seul processus Beaucoup plus petit qu'un OS en sélectionnant les composants on peut arriver à une taille de quelques dizaines de Ko :-) Pas (peu) de support MMU De nombreuses fonctionnalités sont optionnelles : réseau, système de fichiers, etc. Configuration statique de l'application Permet d'ajouter «facilement» API, ordonnanceur Léger, environ 600K lignes pour la version 4.11 (15 M pour le noyau Linux) 40
Les outils libres 41
Typologie des outils Outils de base «toolchain» + mise au point GCC, GDB, LLVM IDE Eclipse (?) Construction de distribution Buildroot, Yocto/OE Émulation / simulation QEMU Gestion de version (Git, SVN) Les meilleurs de ces outils existent dans le monde du logiciel libre :-) 42
Production de distribution (Linux) Un outil crée la distribution à partir des sources des composants adaptés en appliquant des «patch» Il ne s'agit pas de distribution mais d'outil de création de distribution L'outil ne fournit pas les sources mais les règles de production et prend en compte les dépendances L'outil peut produire la chaîne de compilation croisée L'outil produit les différents éléments de la distribution Image du bootloader Noyau Linux Images du root-filesystem Meilleure solution qu'une distribution «générique» sécurité traçabilité 43
Les principaux outils disponibles Yocto/OpenEmbedded Moteur écrit en Python Très puissant mais lourd Basé sur des fichiers de configuration Buildroot Basé sur la commande «make» Au départ un démonstrateur pour uclibc Désormais un véritable outil, bien maintenu! Approche statique (pas de paquets) OpenWrt Dérivé de BR Orienté vers les IAD (Internet Access Device) Gère les paquets binaires 44
Buildroot 45
Buildroot Lié au projet uclibc (micro-c-libc) = libc plus légère que la Glibc But initial: produire des root-filesystem simples pour tester uclibc Moteur uniquement basé sur des fichiers Makefile et quelques scripts-shell utilisation de GNU-Make Outil de configuration utilise le langage Kconfig Peut produire la chaîne de compilation (uclibc, Glibc, Eglibc,...) ou importer une chaîne existante Approche statique Pas de version «officielle» avant 2009 (2009.02) 46
Buildroot aujourd hui Repris en 2009 par Peter Korsgaard et Thomas Petazzoni Une version officielle tous les 3 mois: 2009.02,... 2012.11,..., 2015.02 Projet géré sous Git : http://git.buildroot.net/buildroot Bonne documentation : http://buildroot.uclibc.org/docs.html Plus de 1200 composants adaptés (2015.02) Support CPU x86, ARM, PowerPC, SH4,... Il est désormais simple d ajouter un support de carte par des fichiers de configuration Projets très dynamique! 47
Yocto / OE Similaire à BR mais plus évolué et modulaire Utilisé par les éditeurs pour leurs produits commerciaux Wind River Utilisé par les fabricants de matériel pour les BSP (Board Support Package) Freescale, Gumstix, TI,... Yocto n'est pas une distribution mais fournit des «templates» et outils pour créer des distributions «méta données» organisées en couches (layers) Support matériel (meta-intel, meta-raspberrypi) Distributions (meta-yocto, meta-angstrom) Composants «métier» (meta-ivi) GENIVI http://layers.openembedded.org/layerindex It's not an embedded Linux distribution it creates a custom one for you 48
Principe des «layers» 49
«Workflow» OE 50
Émulateur QEMU Émulateur de matériel initialement développé par Fabrice Bellard, diffusé sous GPL v2 Exécuté dans l'espace utilisateur de Linux Permet d'émuler diverses architectures: x86, PowerPC, ARM, etc. Émulation de carte complète outil de développement, mise au point, test automatique Outil de certification DO-178 (Adacore/Couverture) http://www.open-do.org/projects/couverture Désormais, large communauté avec dépôt Git sur http://git.savannah.gnu.org/cgit/qemu.git 51
Open Hardware 52
(R)évolution du matériel Évolution du x86 vers ARM Création d'un marché autour des «hobbyistes» en électronique Arduino, Raspberry Pi & friends Adafruit, Snootlab & friends Les professionnels utilisent parfois ces plate-formes ou du moins profitent de la baisse des coûts attention au choix! Développement et conception simplifiés généralisation d'un open-hardware pragmatique utilisation de modules CPU nouveaux langages (HTML5, Python) Nouveaux canaux de distribution et plate-formes de financement (kickstarter,...) 53
Versatile PB and sons! < 20 < 15 < 30! < 25 54
Cependant... Certaines plate-formes génériques permettent de créer une «maquette» mais difficilement la version définitive qualité insuffisante La connectivité nécessaire n'est pas toujours disponible Wi-Fi BT Capteurs divers Un créateur n'est PAS un développeur logiciel et encore moins un intégrateur système «fusion» art / design / technologie Quelques plates-forme dédiées sont désormais disponibles WeIO (démo!) Pour l'industrie ne pas oublier la durée de maintenance! 55
Module WeIO 56
Co-design 57
Situation actuelle Les systèmes embarqués deviennent de plus en plus complexes Hier RTOS mono-tâche (1 seule application) Aujourd'hui système multitâche proche d'un OS classique (Linux, Android, ) Exemples de systèmes : Encodeur / décodeur vidéo HD Système «mixte» temps réel et traitement des données (banc de test) Le CPU n'est pas forcément capable de répondre aux exigences fonctionnelles du système L'utilisation du multi-cœur améliore les choses mais décale le problème (et augmente prix + consommation) 58
Évolution de la conception On travaille maintenant au niveau système (ou fonctionnalité) et non au niveau porte logique Les fonctionnalités peuvent être implantées dans des composants spécifiques de type ASIC (Application Specific Integrated Circuit). On parle alors de Système sur Silicium «SoC» (System on Chip). Les fonctionnalités peuvent être implantées dans des composants logiques programmables de type FPGA (Field Programmable Gate Array). On parle alors de système «SoPC» (System on Programmable Chip). Le plus souvent le système dispose d'un CPU (avec OS) + d'un accélérateur matériel pour des tâches dédiés (compression, génération de signal, ) L'association des deux parties correspond au «codesign» 59
Exemple de système Le processeur est en général externe SoC associé à un FPGA Exemple de SoC : i.mx (Freescale), AM335x (TI) Exemple de FPGA : Altera Cyclone, Xilinx Spartan/Virtex Système hybride : Armadeus, Zynq 60
Avantages du co-design L'OS et donc le CPU - est déchargé de tâches très coûteuses (voire inaccessibles) en calcul logiciel L'approche FPGA permet de garantir la souplesse utilisation d'un langage de programmation (Verilog ou VHDL) portabilité sur plusieurs modèles de FPGA Cette même approche garantit la propriété intellectuelle dans le cas de licences parfois contraignantes La fonctionnalité «métier» dans le FPGA Le pilote (GPL si Linux) est une simple interface On trouve des bibliothèques fonctionnelles (des «IP») comme avec le logiciel classique! Le co-design peut également concerner l'association µp (CPU) / micro-contrôleur reliés par exemple - par un bus de type SPI 61
Association µc / Linux Cette approche «hybride» assure un faible coût en garantissant les performances 62
Système Linux «pur» Cette approche nécessite souvent un adaptation coté noyau temps réel (Xenomai, PREEMPT-RT, ) 63
Choix du matériel Solution 1 : Module type SoC FPGA ajouté à la carte finale Nécessite un design matériel Solution 2 : Module SoC intégrant directement un FPGA Xilinx (Zynq), Altera, Armadeus APF27/APF51 Pas (ou peu) de design matériel La demande du marché pousse ce type de solution 64
Cas d'exemple Un système nécessite une horloge de synchronisation (période = 1 ms) Réalisable sur certains systèmes (tâche périodique sur un GPIO) Raspberry Pi/ARM + Linux-TR Impossible à réaliser sur d'autres architectures (x86) sans 1 carte PCI dédiée ( ) Une solution hybride utilise : Un système sous Linux (architecture x86, ARM, ) non TR Un contrôleur matériel FPGA sur bus USB Simple à mettre en place en langage HDL Le calculateur Linux pilote le contrôleur par message USB mais ne gère pas le TR insensible aux variations de charge 65
Raspberry Pi + FPGA USB KNJN DragonPCI-E Bugblat sur bus local 66
Questions? 67