Un système d'exploitation embarqué est un système d'exploitation pouvant être installé sur un système embarqué. Ce système d'exploitation est conçu avec des spécificités à gérer afin de répondre à des besoins spécifiques au type de système embarqué.

Un système d'exploitation est un programme qui gère le matériel. Il sert d'intermédiaire entre l'application logicielle et le matériel informatique (périphériques, capteurs, moteurs...)^[1]. La diversité des systèmes d'exploitation disponibles offre des constructions et propriétés particulières qui permettent de répondre à des objectifs très variés^[2]. À part pour les tâches très simples (l'ordonnancement, la commutation de tâches, entrées/sorties, ...), une application embarquée à besoin d'un système d'exploitation adapté répondant aux contraintes pour être installée sur le système embarqué (espace mémoire par exemple). Le système d'exploitation doit aussi disposer des fonctionnalités requises pour la tâche qu'il aura à exécuter^[3]. Les systèmes d'exploitation pour PC sont conçus avec une interface homme-machine particulière (écran-clavier-souris). Dans le cadre d'un système d'exploitation embarqué, l'interface homme-machine pour pouvoir interagir avec peut être spécifique (clavier à digicode, écrans de smartphones...), voire inexistante (cartes de crédit, cartes sim, ...), auquel cas on utilise une machine intermédiaire (bornes, téléphones^[4]). Étant la plupart du temps hors de portée humaine, un système d'exploitation embarqué doit avoir un niveau de robustesse bien au-dessus des exigences d'un système d'exploitation de bureau^[5]. Les systèmes d'exploitation embarqués nécessitent une très grande fiabilité, ainsi que de bonnes performances^[6].

Les systèmes embarqués sont utilisés dans des domaines très variés tels que la téléphonie mobile, l’électroménager, les équipements médicaux, l’aéronautique, l’automobile, les bornes automatiques, etc. Mise à part peut être l’horloge système, les fonctionnalités du système d’exploitation sur lesquels ils vont s'appuyer seront hétérogènes. Et avec un parc d'appareils qui est tout aussi hétérogène, ces dispositifs ne supportent pas toutes les variantes des systèmes d'exploitation existants^[7]. Étant dans un système contraint, le système d'exploitation doit répondre aux besoins de l'appareil. L'adaptation se fait donc en trouvant le bon compromis entre taille et performances pour optimiser le système d'exploitation. Les systèmes d'exploitation privilégiés sont donc ceux avec seulement les pilotes de périphériques requis^[8].

Des systèmes embarqués peuvent avoir des contraintes d'ordre temporel. Pour supporter ces contraintes, il existe des systèmes d'exploitation temps réel qui fournissent des services et des primitives qui peuvent garantir les délais d’exécution souhaités.

Pour qu'un OS soit un RTOS^{[note 1]} il doit répondre à 4 exigences^[9] :

Le comportement de synchronisation du système d'exploitation doit être prévisible.

Le système d'exploitation doit garantir de pouvoir terminer chaque service en cours d’exécution dans un temps maximal fixé. L’ordonnancement est donc déterministe pour une gestion optimale des tâches.

Le système d'exploitation doit gérer l'ordonnancement des tâches.

L'ordonnancement peut être événementiel (on parle aussi d'ordonnancement par priorité) : l'ordonnanceur ne change de tâche que lorsqu'un événement de plus haute priorité a besoin de service.

Il peut être aussi par partage de tâches : L'ordonnanceur change de tâche aux interruptions de l'horloge, ce qui le rend plus multi-tâches dans le sens où les tâches ne s’exécutent plus une à une aux yeux de l'utilisateur.

Le système d'exploitation doit gérer le temps afin d'ordonnancer au mieux les tâches en fonction de leur délai.

Cette gestion est obligatoire si le traitement interne est lié à un temps absolu dans l'environnement physique. La synchronisation d'horloge globale est effectuée (au choix) via 2 standards : UTC^{[note 2]} ou TAI^{[note 3]}. Si le système est utilisé dans un réseau, il est régulièrement synchronisé pour que tous les systèmes soient coordonnés.

Le système d'exploitation doit être rapide. Un système d'exploitation répondant à toutes les exigences mentionnées jusqu'ici serait inutile s'il était très lent.

Un système embarqué n'a pas systématiquement besoin d'un système de fichier. Un capteur en réseaux récupère des informations et les transmet aussitôt sur le réseau. La carte bancaire ou un badge d’accès sont des contre-exemples, car ils doivent avoir en mémoire des données utilisateur. Le système de fichiers peut être intégré au système d'exploitation, permettant aux applications de lire et d'écrire des fichiers sur un espace de mémoire non volatile du système physique^[10].

Ci-dessous, une liste d’exigences typiques de sécurité que l'on retrouve sur des systèmes embarqués qu'un OS peut fournir^[11] :

Identification de l'utilisateur

Processus de validation de l'utilisateur avant de lui donner accès au système. Le système en question peut être physique (ouverture de porte par badge d’accès) ou informatique (compte et mot de passe avant de pouvoir interagir avec le logiciel).

Connexion réseau sécurisé

Fournit une connexion réseau uniquement si l'appareil est autorisé. Permet en cas d'intrusion de limiter son impact sur le réseau et les systèmes reliés. Dans le cas des réseaux de capteurs sans-fil, cela réduit les chances qu'un faux capteur s'y introduise pour récupérer les données récoltées.

Communication sécurisée

Inclut l’authentification des entités communicantes, qui assure la confidentialité et l'intégrité des données transmises et protège l'identité des entités communicantes. Deux automates qui souhaitent se synchroniser s’authentifieront mutuellement puis échangeront leurs informations en assurant la confidentialité et l'intégrité par un moyen cryptographique.

Stockage sécurisé

Confidentialité et intégrité des données stockées sur le système.

Sécurité du contenu

Restriction d'utilisation du contenu numérique en lecture et écriture sur le système. En sécurisant le contenu, il assure un niveau de sécurité tout au long de l'utilisation de ce système.

Disponibilité

Le système doit pouvoir exécuter sa(ses) fonction(s) dans tous les cas. L'ABS^{[note 4]} d'une automobile en est un bon exemple, il doit pouvoir être disponible à chaque fois qu'on l’interroge afin d'assurer la sécurité de ses occupants.

Pour les développeurs, il est souhaitable que l'appareil dispose d'APIs pour faciliter le développement de l'application.

La machine virtuelle Java inclut des interfaces et d'autres bibliothèques natives qui lui permettent d'être facilement intégrée à un RTOS. Écrite en C, la machine virtuelle Java est compilée avec le RTOS et interprète les bytes-codes Java pour que l'application s'exécute^[12]. Grâce à cela, l’appareil peut interpréter du byte-code Java et profiter des APIs disponibles (exemple: java.net pour les fonctionnalités tcp/ip, java.io pour les entrées/sorties, ...).

Un système embarqué peut avoir à communiquer avec un ou plusieurs autres systèmes (lorsqu'il s'agit de systèmes embarqués travaillant de manière collaborative) ou périphériques. Pour ces cas là, le système d'exploitation peut fournir les primitives pour établir une communication en fonction du medium utilisé^[13] :

• Réseau: utilisé pour des communications sur un réseau Ethernet(TCP, UDP, SMTP, DataSocket)
• Mémoire partagée
• Communication sans-fil IrDA: pour des échanges de données via Infrarouge
• Communication par Bus: utilise des ports destinés à des bus de communication (Série, CAN)
• Fibre optique.

L'atout majeur de la virtualisation est la garantie que deux applications concurrentes sur un même système n’interfèrent pas entre elles. Utiliser la virtualisation permet d'imposer dans chaque machine virtuelle des limitations d’accès aux ressources et périphériques en fonction des besoins de l'application^[14].

L’intérêt de la virtualisation est aussi de faire cohabiter deux systèmes d'exploitation différents (temps-réel inclus) sur le même processeur et fournissant donc à chaque processus les spécifications requises à l’exécution de leur tâche^[14].

La virtualisation permet aussi d’apporter un niveau de sécurité pour éviter des dommages inter-processus. Chaque processus étant lancé par une machine virtuelle distincte, si l'un d'entre eux rencontre un problème, il n'aura aucun impact sur les autres processus en cours sur d'autres machines virtuelles^[14].

Pour des systèmes embarqués autonomes en énergie, il est judicieux de choisir un système d'exploitation permettant de limiter la consommation énergétique. Pour limiter la consommation, il y a des techniques matérielles (choix des composants, circuits reconfigurables), logicielles (optimisation du code, utilisation d'instructions spécifiques) et hybrides (mise en veille des périphériques non utilisés). Le système d'exploitation peut seulement agir sur les solutions hybrides et logicielles^[15].

Les contraintes de choix et d'utilisation d'un système d'exploitation pour un système embarqué dépendent du domaine d'application dans lequel se retrouvera le système. De nos objets du quotidien (Smartphone, Électroménager...) jusqu'aux systèmes de contrôle d'un avion ou Curiosity, sans oublier les équipements médicaux, de télécommunication (Satellite, antenne relais...) et militaire (drone, système de guidage de missiles...), les domaines d'application sont larges et étendus, et leurs objectifs divers^[2].

Les domaines d'application qui vont suivre vont mettre en situation les spécificités énoncées plus tôt.

Pour satisfaire de grandes contraintes temps-réel, les algorithmes de systèmes de contrôle d'avions sont exécutés sur des systèmes d'exploitation temps réel^[16]. Cette nécessité vient du grand nombre de capteurs présents sur l’appareil et d'élément contrôlable.

Dans le domaine de l'automobile, les systèmes embarqués ont commencé à prendre place depuis que des équipements d'aide à la conduite sont intégrés dans nos véhicules (ABS, ESP, ...), mais aussi pour commander les éléments du véhicule (phares, essuie-glaces, vitres, verrouillage des portes, outils de navigation, ...). Pour cela, les constructeurs automobiles se tournent vers des systèmes d'exploitation temps-réel afin de centraliser la gestion de tous les éléments électroniques et pouvoir gérer la priorité des tâches (pour pouvoir privilégier le traitement des éléments de sécurité avant ceux de confort). Le système d'exploitation choisi doit aussi pouvoir communiquer avec les éléments électroniques du véhicule par bus de données^[17].

Un exemple d'utilisation dans le domaine automobile, est Windows Embedded Automotive (en) sur lequel s’appuie la technologie Ford Sync (en)^[18].

Des partenariats entre les constructeurs automobiles et des sociétés privées sont en cours pour que des systèmes d'exploitation plus connus du grand public soient utilisés dans les voitures. C'est le cas d'Apple avec iOS in the Car (en). Et le projet Open Automotive Alliance^[19] de Google.

Des regroupements de constructeurs existent avec pour but d'avoir un RTOS commun comme AUTOSAR , OSEK/VDX.

Les contraintes liées au développement robotique sont les interactions avec les périphériques (capteurs, webcam, moteurs pas à pas...). Pour exemple, RoBIOS est un système d'exploitation destiné au développement robotique et a dans son code binaire une large bibliothèque de fonctions systèmes et des pilotes de périphériques pour contrôler et accéder à tous les types de matériel^[20].

Le travail du système d'exploitation est de gérer l'allocation des ressources de manière ordonnée et contrôlée. Le programmeur peut utiliser des appels systèmes pour accéder aux services que fournit le système d'exploitation^[21].

Les réseaux de capteurs ayant de plus en plus de données à collecter, traiter et transmettre, les contraintes font que le système d'exploitation doit être multi-threadé pour répondre aux besoins. En entrelaçant les tâches complexes et sensibles, le système peut atténuer le problème producteur-consommateur^[22].

Les systèmes d'exploitation pour carte à puce sont dépourvus d'interface utilisateur, du moins, ces interfaces sont limitées (borne, capteur...). La principale spécificité requise sur une carte à puce est la sécurité ; une autre contrainte est le faible espace de stockage mémoire offert pour accueillir le système d'exploitation et les données qui seront y sont mémorisées^[23].

Un système d'exploitation pour carte à puce est construit pour offrir un ensemble de services pour la gestion des données, le contrôle d'accès, et les services cryptographiques. Les fonctions de base d'un système d'exploitation qui sont communes à tous les types de cartes à puce sont^[24] :

1. Gestion des échanges entre la carte et le monde extérieur, principalement en termes de protocole d'échange.
2. Gestion des fichiers et des données stockées dans la mémoire.
3. Contrôle d'accès à l'information et aux fonctions.
4. Gestion de la sécurité de la carte et des procédures d'algorithmes cryptographiques.
5. Garantie de fiabilité, notamment en termes de cohérence des données.

Les smartphones sont des appareils ayant les capacités d'un micro-ordinateur. Avec un nombre de smartphones grandissant de jour en jour, la qualité du système d'exploitation doit être de mise afin de pouvoir exécuter un même programme sur différents modèles de smartphones. Le système d'exploitation détermine les caractéristiques, la performance, la sécurité et les add-ons des applications d'un smartphone^[25]. Le système d'exploitation doit gérer une interface homme-machine intuitive et réactive pour que l'utilisateur puisse exécuter ses applications^[1] ; il doit aussi contribuer à minimiser la consommation d'énergie du smartphone.

• Zephyr (système d'exploitation)

 : document utilisé comme source pour la rédaction de cet article.

• (en) Peter Marwedel, « Embedded System Design », Embedded Systems Foundations of Cyber-Physical Systems,‎ 2011, p. 178 - 191 (ISBN 978-94-007-0256-1, DOI 10.1007/978-94-007-0257-8)

• (en) Avi Silberschatz, Peter Galvin et Greg Gagne, Operating System Concepts, 2012, 944 p. (ISBN 978-1-118-06333-0), p. 1 - 1

• Pierre Ficheux et Eric Bénard, Linux embarqué : nouvelle étude de cas, traite d'OpenEmbedded, Paris, Eyrolles, 2012, 539 p. (ISBN 978-2-212-13482-7, lire en ligne), p. 1 - 17

• (en) Wolfgang Rankl et Wolfgang Effing, Smart Card Handbook, 2010, 4^e éd., 1088 p. (ISBN 978-0-470-85668-0 et 0-470-85668-8, lire en ligne)
• (en) Feida Lin et Weiguo Ye, Operating System Battle in the Ecosystem of Smartphone Industry, 2009 (ISBN 978-0-7695-3686-6, DOI 10.1109/IEEC.2009.136), p. 617 - 621
• (en) Thomas Bräunl, Embedded Robotics : Mobile Robot Design and Applications with Embedded Systems, Berlin, Springer, 2006, 458 p. (ISBN 978-3-540-34319-6, lire en ligne)
• (en) Dimitrios Hristu-Varsakelis et William S. Levine, Handbook of Networked and Embedded Control Systems, 2005, 749 p. (ISBN 978-0-8176-3239-7)
• (en) A. Lennon, « Embedding Linux », IEE Review, vol. 47, n^o 3,‎ août 2002, p. 33-37 (ISSN 0953-5683, DOI 10.1049/ir:20010305)
• (en) R. Comerford, « Pocket computers ignite OS battle », spectrum, IEEE, vol. 35, n^o 5,‎ août 2002, p. 43-48 (ISSN 0018-9235, DOI 10.1109/6.669976)
• (en) Muhammad Omer Farooq et Thomas Kunz, « Operating Systems for Wireless Sensor Networks: A Survey », Sensors,‎ mai 2011, p. 33-37 (ISSN 1424-8220, DOI 10.3390/s110605900)
• Frédéric Parain, Michel Banâtre, Gilbert Cabillic, Teresa Higuera, Valérie Issarny et Jean-Philippe Lesot, Techniques de réduction de la consommation dans les systèmes embarqués temps-réel, INRIA, rapport de recherche, 2000, 33 p. (lire en ligne)
• Gilles Grimaud, CAMILLE système d'exploitation Ouvert pour Carte à microprocesseur, Lille, PhD thèse, Laboratoire d'Informatique Fondamentale de Lille (LIFL), 2000, 217 p. (lire en ligne)
• Simon Duquennoy, Smews : un système d'exploitation dédié au support d'applications Web en environnement contraint, Lille, 2010, 146 p. (lire en ligne)
• (en) G. Selimis, A. Fournaris, G. Kostopoulos et O. Koufopavlou, « Software and Hardware Issues in Smart Card Technology », Communications Surveys & Tutorials, IEEE, vol. 11, n^o 3,‎ août 2009, p. 143-152 (ISSN 1553-877X, DOI 10.1109/SURV.2009.090310)
• (en) S. Bhatti, J. Carlson et H. Dai, « MANTIS OS: an embedded multithreaded operating system for wireless micro sensor platforms », Mobile Networks and Applications, vol. 10, n^o 4,‎ août 2005, p. 563-579
• (en) J. Changhee, W. Duk-Kyun, K. Kanghee et L. Sung-Soo, « Performance characterization of prelinking and preloadingfor embedded systems », 07 Proceedings of the 7th ACM & IEEE international conference on Embedded software,‎ 2007, p. 213-220 (ISBN 978-1-59593-825-1, DOI 10.1145/1289927.1289961)
• (en) K. Hisazumi, T. Nakanishi et T. Kitasuka, « Design and implementation of the Lambda μ-kernel based operating system for embedded systems », 10 Proceedings of the 10th workshop on ACM SIGOPS European workshop,‎ 2002, p. 178-181 (DOI 10.1145/1133373.1133408)
• (en) K. Elphinstone et G. Heiser, « From L3 to seL4 what have we learnt in 20 years of L4 microkernels? », Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles,‎ 2013, p. 133-150 (ISBN 978-1-4503-2388-8, DOI 10.1145/2517349.2522720)
• (en) R. G. Helps et S. J. Packs, « Cyber-physical system concepts for IT students », Proceedings of the 13th annual ACM SIGITE conference on Information technology education,‎ 2013, p. 7-12 (ISBN 978-1-4503-2239-3, DOI 10.1145/2512276.2512303)
• (en) P. Levis et S. Madden, « TinyOS: An Operating System for Sensor Networks », Ambient Intelligence,‎ 2005, p. 115-148 (ISBN 978-3-540-23867-6, DOI 10.1007/3-540-27139-2_7)
• (en) F. Schön et W. Schröder-Preikschat, « Design Rationale of the Pure Object-Oriented Embedded Operating System », Distributed and Parallel Embedded Systems,‎ 1999, p. 231-240 (ISBN 978-1-4757-5006-5, DOI 10.1007/978-0-387-35570-2_21)
• (en) A. Dunkels, B. Gronvall et T. Voigt, « Contiki - a lightweight and flexible operating system for tiny networked sensors », Local Computer Networks, 2004. 29th Annual IEEE International Conference on,‎ 2004, p. 455-462 (ISBN 0-7695-2260-2, ISSN 0742-1303)
• (en) D. Lohmann, W. Hofer et W. Schröder-Preikschat, « CiAO: an aspect-oriented operating-system family for resource-constrained embedded systems », USENIX'09 Proceedings of the 2009 conference on USENIX Annual technical conference,‎ 2009, p. 16-16
• (en) D. C. Toll, P. A. Karger et E. R. Palmer, « The Caernarvon secure embedded operating system », ACM SIGOPS Operating Systems Review, vol. 42,‎ 2008, p. 32-39
• (en) M. Aldea Rivas et M. González Harbour, « MaRTE OS: An Ada Kernel for Real-Time Embedded Applications », Reliable SoftwareTechnologies — Ada-Europe 2001,‎ 2001, p. 305-316 (ISBN 978-3-540-42123-8, DOI 10.1007/3-540-45136-6_24)
• (en) P. Levis et D. Gay, « T2: A Second Generation OS For Embedded Sensor Networks », Telecommunication Networks Group, Technische Universität Berlin, Berlin, Germany,‎ 2005
• (en) E. Akhmetshina, P. Gburzynski et F. Vizeacoumar, « PicOS: A Tiny Operating System for Extremely Small Embedded Platforms », Las Vegas,‎ 2003, p. 116-122
• (en) D. Mulchandani, « JAVA FOR EMBEDDED SYSTEMS », Internet Computing, IEEE,‎ 1998, p. 10 (ISSN 1089-7801, DOI 10.1109/4236.683797)
• (en) Gernot Heiser, « The Role of Virtualization in Embedded Systems », ACM New York,‎ 2008, p. 6 (ISBN 978-1-60558-126-2, DOI 10.1145/1435458.1435461)
• (en) Srivaths Ravi et Anand Raghunathan, « Security in Embedded Systems: Design Challenges », ACM Transactions on Embedded Computing Systems,‎ 2004, p. 31 (DOI 10.1145/1015047.1015049)
• (en) H. Jin Kim et David H. Shim, « A flight control system for aerial robots:algorithms and experiments », EECS Department,‎ 2003, p. 12 (DOI 10.1016/S0967-0661(03)00100-X)
• (en) Nicolas Navet, Yeqiong Song, Françoise Simonot-lion et Cédric Wilwert, « Trends in Automotive Communication Systems », IEEE,‎ juin 2005, p. 1204 - 1223 (ISSN 0018-9219, DOI 10.1109/JPROC.2005.849725)
• Mukund Ghangurde, Ford’s SYNC® and Microsoft Windows Embedded Automotive Make Digital Lifestyle a Reality on the Road, Paris, Eyrolles, 2011, 12 p. (ISBN 978-2-212-13482-7, lire en ligne)

• Portail des télécommunications
• Portail de l’informatique