Système embarqué - Définition et principes fondamentaux PDF

[[https://www.ukonline.be/cours/embeddedsystems/programming/chapitre1-1]](https://www.ukonline.be/cours/embeddedsystems/programming/chapitre1-1) **Définition** Un *système embarqué* est un système électronique et informatique qui se trouve au sein d\'un produit plus large. Son but premier consiste...

[[https://www.ukonline.be/cours/embeddedsystems/programming/chapitre1-1]](https://www.ukonline.be/cours/embeddedsystems/programming/chapitre1-1) **Définition** Un *système embarqué* est un système électronique et informatique qui se trouve au sein d\'un produit plus large. Son but premier consiste à traiter de l\'information reçue depuis son environnement pour en faire profiter le produit hôte qui l\'héberge. Par exemple, les voitures modernes peuvent être équipées d\'un système de climatisation de l\'air complètement contrôlé par un système embarqué. Ce dernier collecte de l\'information sur la température et sur l\'humidité de l\'air au sein de la voiture et, sur base de cette dernière, active ou non le climatiseur, l\'humidificateur, le déshumidificateur, etc. Contrairement à un ordinateur *« traditionnel »*, un système embarqué n\'a pas de raison d\'être seul. Il s\'agit toujours d\'un composant faisant partie d\'un système plus large. On ne le voit donc pas forcément même si ce dernier est de plus en plus présent. Alors que l\'on comptait environ 2 400 millions d\'ordinateurs *« traditionnels »* dans les années 2015, plus de 15 milliards de microprocesseurs se trouvaient déployés dans des systèmes embarqués en 2018 et plus de [[80 milliard pour 2020]](https://www.usine-digitale.fr/article/les-systemes-embarques-au-c-ur-d-une-revolution-industrielle-et-societale.N671704)! Enfin, comme client, on n\'acquiert généralement pas un système embarqué seul pour traiter de l\'information. Ce que l\'on achète, c\'est un produit qui comporte un ou des systèmes embarqués, ceux-ci collectant de l\'information à destination du produit, permettant ainsi de rendre un meilleur service à son ou ses utilisateurs.  La figure 1 résume les éléments qui ont déjà été mis en avant. Le système embarqué se retrouve comme composant d\'un système plus large, interagissant avec des processus externes en récupérant de l\'information via des senseurs et en agissant dessus via des actuateurs. Il peut également être en liaison directe avec l\'utilisateur. Figure 1. Un système embarqué traite de l\'information sur des processus externes provenant de senseurs et d\'informations directes provenant de l\'utilisateur pour ensuite agir sur les processus externes via des actuateurs ou directement informer l\'utilisateur. Un *senseur*, ou capteur, joue le rôle d\'entrée pour le système embarqué, lui permettant de recevoir une information provenant de l\'extérieur. Il en existe de nombreux tels que des senseurs de température, d\'humidité, de proximité, de contact, des accéléromètres, des compte-tours, etc. Un *actuateur*, ou actionneur, joue le rôle de sortie pour le système embarqué, lui permettant de produire une action sur l\'environnement extérieur. Il en existe également de nombreux tels que des moteurs, des vérins, des baffles, des LEDs, des écrans d\'affichage, etc. De manière générale, on ne se limite pas à des senseurs et actuateurs comme éléments d\'entrée/sortie entre le système embarqué et son environnement. Outre cet aspect plus physique, des entrées peuvent provenir, par exemple, d\'une configuration externe ou d\'une communication avec un réseau externe qui se fera, évidemment, à travers un module de communication que l\'on peut identifier à un senseur. Concernant les sorties, on ne se limite de nouveau pas à des actions physiques sur un système, mais on considère également l\'impression de valeurs via un écran ou des LEDs, par exemple, qui se fera aussi grâce à des éléments identifiables à des actuateurs. La figure 2 montre une découpeuse laser commandée par au moins un système embarqué. Ce dernier reçoit une configuration de départ et une séquence d\'instructions à exécuter pour effectuer une découpe. Une série de senseurs permet au système embarqué de connaitre la position du laser, sa hauteur, sa température, etc. Grâce à ces informations, il contrôle une série d\'actuateurs pour placer la tête de découpe au bon endroit, ajuster la puissance du laser, etc. écoupeuse laser Figure 2. Une découpeuse laser est commandée par un système embarqué qui possède une batterie de senseurs lui permettant, par exemple, de connaitre la position de son laser et d\'actuateurs lui permettant d\'effectuer la découpe demandée, par exemple, en contrôlant la puissance du laser. La figure 3 présente une vue *orientée-produit* d\'un système embarqué. On peut le voir comme implémentant un *processus* qui produit des sorties sur base d\'entrées collectées. Une solution complexe est composée de plusieurs systèmes embarqués, typiquement coopératifs, dont les processus interagissent entre eux, les sorties des uns pouvant être les entrées des autres, afin de rendre un service global au niveau du système.  Figure 3. Un système embarqué est un processus qui produit des sorties à partir d\'entrées qu\'il collecte depuis son environnement. La définition proposée par l\'*Institution of Electrical Engineers* (IEE) est assez bien en accord avec la figure 1 et résume les différents points déjà présentés. Elle définit les systèmes embarqués comme étant : *"the devices used to control, monitor or assist the operation of equipment, machinery or plant. \`Embedded\' reflects the fact that they are an integral part of the system. In many cases their embeddedness may be such that their presence is far from obvious to the casual observer \[\...\]"* Un système embarqué est conçu pour *exécuter une tâche spécifique* bien définie, contrairement à un ordinateur *« traditionnel »* dont on dit qu\'ils sont à usage général. L\'une des raisons est qu\'ils possèdent généralement moins de ressources et sont moins performants que les ordinateurs *« traditionnels »*. Par conséquent, le software des systèmes embarqués est généralement aussi plus spécifique. Enfin, les systèmes embarqués sont très souvent destinés à fonctionner en autonomie, c\'est-à-dire qu\'ils ne devront que peu interagir directement avec l\'utilisateur, en général. Du coup, ils ne sont souvent pas équipés de clavier physique comme dispositif d\'entrée et l\'écran d\'affichage est souvent absent ou très réduit. **Exemple** On retrouve des systèmes embarqués dans de nombreux appareils et dispositifs. Ils peuvent être seuls ou à plusieurs, isolés du reste du monde et cloisonnés dans le système hôte ou collaborant avec d\'autres systèmes. Ils se retrouvent vraiment partout, en commençant par les appareils électroménagers tels que les machines à laver, fours à micro-ondes, toasters, etc. Dans ces appareils, on retrouve typiquement un seul système embarqué, peu évolué, dont le but est de gérer leurs différents états de fonctionnement. On retrouve également des systèmes embarqués dans tout ce qui est électronique grand public tels que les appareils photos et caméras numériques, consoles de jeu, téléviseurs, smartwatches, etc. On en retrouve également dans les systèmes d\'information et de communication, à commencer par les téléphones portables et smartphones. Ils sont aussi présents dans d\'autres dispositifs de communication tels que les modems-routeur, fax, mais également tout le long de la chaine de communication, notamment dans les antennes-relais et les satellites. xemples de systèmes embarqués Figure 4. De nombreux appareils ou dispositifs que nous côtoyons tous les jours sont équipés de un ou plusieurs systèmes embarqués. Les systèmes embarqués ne sont donc pas présents que chez le grand public, mais sont largement utilisés dans le monde industriel. On les retrouve aussi dans les chaines de production, dans des stations de contrôle ou comme senseurs (centrale nucléaire, trafic aérien, activité volcanique, balises d\'alerte tsunami, etc.). Il s\'agit souvent de systèmes embarqués devant être beaucoup plus robustes afin de supporter des conditions bien plus strictes que celles des applications destinées au grand public. Enfin, terminons avec la voiture comme dernier exemple. Il s\'agit, tout comme d\'autres moyens de transport tels que les avions, d\'un système constitué de nombreux systèmes embarqués, certains remplaçant par ailleurs des dispositifs qui relevaient auparavant de l\'électromécanique. Dans une voiture moderne d\'aujourd\'hui, près de 40%40% de sa valeur concerne les systèmes embarqués qui la peuplent. Sans être exhaustif, on en retrouve pour contrôler l\'ABS, la boite de vitesse, le moteur, la climatisation, les systèmes de divertissement, etc. Pour résumer, ce n\'est pas bien compliqué de trouver un système embarqué de nos jours. Levez-vous, faites un tour complet sur vous-même en regardant autour de vous et, à moins que vous ne soyez dans un désert perdu au milieu de nulle part, vous ferez face à plusieurs systèmes embarqués visibles ou invisibles ! **Type** On peut distinguer *quatre principaux types* de systèmes embarqués en fonction du type d\'application visé : - Les systèmes embarqués à *usage général* exécutent des applications similaires à celles exécutées sur des ordinateurs *« traditionnels »*, mais ils sont embarqués dans des packages de petite taille. On a, par exemple, les assistants personnels (PDA) et les guichets automatiques bancaires (ATM). - Les systèmes embarqués de *contrôle* sont utilisés pour effectuer un contrôle en boucle rétroactive fermée de systèmes temps réel. On les retrouve notamment dans les moteurs de voiture, les centrales nucléaires et pour le contrôle aérien. - On peut également utiliser des systèmes embarqués pour *traiter des signaux*, c\'est-à-dire réaliser des calculs sur des gros flux de données. Ces derniers se retrouvent typiquement dans le traitement audio et vidéo et dans les radars et sonars. - Enfin, des systèmes embarqués sont également utilisés dans le domaine des communications et réseaux, pour effectuer de la transmission de données et réaliser des communications. Ils sont notamment utilisés dans la téléphonie et pour l\'internet. Ce premier classement caractérise les systèmes embarqués en fonction du *type d\'application* pour lequel ils sont conçus et utilisés. Certains appareils peuvent, de prime abord, se retrouver dans plusieurs catégories. Par exemple, une console portable de jeu est à la fois un système embarqué à usage général puisqu\'elle peut exécuter des jeux comme un ordinateur *« traditionnel »*, mais elle peut également être spécialisée dans l\'audio et la vidéo. Il faut aussi garder à l\'esprit qu\'un appareil peut contenir plusieurs systèmes embarqués, comme l\'exemple de la voiture précédemment évoqué. On peut également classer les systèmes embarqués en fonction du *type de fonction* qu\'ils calculent : - Un système embarqué peut avoir pour but de s\'assurer qu\'une *loi de contrôle* soit respectée. Par exemple, un drone est normalement équipé d\'un contrôleur PID (un contrôleur PID, *Proportional-Integral-Derivative*, calcule une valeur d\'erreur entre un objectif et une valeur mesurée et produit des commandes à exécuter sur le système afin que celui-ci se rapproche de l\'objectif) qui permet d\'assurer sa stabilité en vol stationnaire. - Une autre fonction possible, par exemple présente dans une machine à laver, consiste à représenter une *logique séquentielle*, alternant entre différents modes de fonctionnement. - On retrouve également le *traitement de signaux* comme une fonction possible. Des systèmes embarqués sont spécialisés dans la compression et décompression de contenu multimédia, l\'application de filtres pour des sons, etc. - Des systèmes embarqués sont également utilisés pour jouer le rôle d\'*interface* pour des applications spécifiques. Ils vont ainsi gérer des boutons, lampes ou alarmes sonores ou être utilisés pour gérer des entrées-sorties rapides comme dans des contrôleurs de disques durs ou SSD, par exemple. - Enfin, il existe des systèmes embarqués dont le but est de *réagir à des fautes*. Leur fonction est simple tant que tout va bien, ils ne font juste rien. Mais lorsqu\'un comportement anormal est détecté, ils réalisent un diagnostic et tentent de corriger la faute. Ces deux classements montrent qu\'il existe une très grande variété de systèmes embarqués. Malgré cela, ils jouissent évidemment tous d\'un grand nombre de caractéristiques communes, les faisant appartenir au monde des systèmes embarqués. Si on se penche plutôt sur des considérations plus techniques, on peut également classer les systèmes embarqués selon leur *taille et complexité* : - Un système embarqué de *petite échelle* comporte typiquement un simple microcontrôleur sur 8 ou 16 bits, avec du hardware et software très simple. Le design de ces systèmes se retrouve au niveau d\'une carte et les ressources, notamment en terme de mémoire, sont très limitées pour limiter la dissipation de puissance. - Un système embarqué de *moyenne échelle* comporte un ou quelques microcontrôleurs sur 16 ou 32 bits, un *Digital Signal Processor* (processeur de signal numérique) (DSP) ou un processeur avec un jeu d\'instructions réduit (RISC). Le hardware et software de ces systèmes sont plus complexes. Côté hardware, on retrouve des *Application Specific Standard Product* (produit standard spécifique à une application, par exemple pour smartphones) (ASSP) ou *Instruction Processor* (IP) et ils peuvent être contrôlés par des *Real-Time Operating Systems* (systèmes d\'exploitation temps réel) (RTOS). - Enfin, on peut aussi concevoir des systèmes embarqués *sophistiqués* qui ont une complexité hardware et software très grande. Ils sont construits à partie de processeurs évolutifs et configurables ou de *Programmable Logic Array* (PLA). Pour ces systèmes, un co-design et une intégration hardware/software sont importants. On reviendra sur ce classement après avoir détaillé les aspects hardware et software des systèmes embarqués, plus loin dans ce chapitre. **Caractéristique** Voyons une série de *caractéristiques* communes à la majorité des systèmes embarqués, peu importe leur type. Tout d\'abord, un système embarqué doit être *fiable*, notamment car il doit généralement pouvoir fonctionner en autonomie. En particulier, on peut mesurer : - sa *robustesse*, c\'est-à-dire la probabilité qu\'il fonctionne correctement à un certain temps tt, sachant qu\'il fonctionnait en t=0t=0 ; - sa *maintenabilité*, c\'est-à-dire la probabilité qu\'il fonctionne correctement un certain temps dd après qu\'une erreur se soit produite ; - sa *disponibilité*, c\'est-à-dire la probabilité qu\'il fonctionne correctement à un temps tt ; - sa *sûreté*, c\'est-à-dire qu\'il ne cause pas de nuisances ; - et enfin sa *sécurité*, c\'est-à-dire que ses communications sont confidentielles et authentifiées. Il faut bien entendu maximiser tous ces critères. De plus, il est important de directement penser à ces aspects lors de la conception du système embarqué car il n\'est pas forcément évident d\'en modifier un existant après coup pour mieux les satisfaire. En effet, étant donné les contraintes du système embarqué, notamment en terme de puissance de calcul, il ne sera pas forcément possible de tous les maximiser. Un choix devra donc être posé selon l\'application visée. Un système embarqué doit également être *efficace*. Étant donné qu\'il est conçu dans un but spécifique et précis, il faut qu\'il soit plus efficace qu\'un ordinateur *« traditionnel »*, sans quoi son développement n\'est pas justifié. Les aspects suivants doivent être pris en compte : - la *consommation énergétique* ; - la *taille du code*, en particulier pour des systèmes embarqués de bas niveau déployés sur une petite puce ; - l\'*exécution* du programme tant au niveau du temps que de la mémoire consommé ; - le *poids et la taille* ; - et enfin le *cout* de fabrication, mais aussi de conception et design. La figure 5 reprend ces différents aspects et propose une ou plusieurs mesures permettant de les évaluer. Ainsi, on peut mesurer la taille d\'un code directement en octets, plutôt pour les petits systèmes embarqués de très bas niveau, ou en lignes de code pour ceux de haut niveau. Pour les performances de l\'exécution du programme, on peut mesurer le nombre de millions d\'instructions exécutées par seconde (MIPS) pour évaluer la vitesse de calcul « pure » ou le nombre d\'opérations de lecture/écriture par seconde dans la mémoire, si le système embarqué doit manipuler beaucoup d\'entrées/sorties. ------------------------------------------------------------- **Critère** **Mesure** -------------------------- ---------------------------------- Consommation énergétique Watt Taille du code Octets\ Lignes de code Exécution du programme MIPS\ Nombre de read/write par seconde Poids et taille Kilogramme, centimètre Cout de fabrication \$, € ------------------------------------------------------------- Figure 5. Les critères d\'efficacité d\'un système embarqué peuvent être mesurés à l\'aide de différentes métriques que l\'on peut combiner entre elles. Toutes ces caractéristiques, de fiabilité et d\'efficacité, doivent évidemment être considérées en lien avec l\'application pour laquelle le système embarqué est développé. En effet, certains critères ont sans doute moins de sens ou sont moins importants pour une application donnée. Par exemple, les considérations énergétiques sont sans doute moins cruciales pour le système embarqué qui gère votre machine à laver que pour celui qui est installé dans un volcan pour monitorer le niveau des émanations de dioxide de soufre (SO22). **Contrainte** Terminons de définir ce qu\'est un système embarqué en parcourant différentes *contraintes* auxquelles ils sont soumis, se rappelant qu\'il s\'agit de systèmes spécifiques et dédiés à une tâche bien déterminée. Lorsque l\'on va vouloir concevoir un système embarqué, il est dès lors très important de prendre en compte les connaissances par rapport aux conditions et à l\'environnement dans lesquels il sera utilisé. Cela va notamment permettre de décider quels sont les critères de fiabilité et d\'efficacité qui sont pertinents pour l\'application visée. On gardera donc à l\'esprit qu\'un système embarqué est *dédié* à une application spécifique. Un autre aspect important et très présent dans les systèmes embarqués concerne les contraintes de *temps réel* qu\'ils doivent satisfaire. En effet, ces derniers doivent pouvoir réagir aux stimuli provenant du système contrôlé dans un laps de temps raisonnable. Dans un système *temps réel strict*, si ce dernier n\'a pas répondu à un stimuli endéans un laps de temps fixé, une réaction même correcte sera considérée comme incorrecte. Le système embarqué en charge de contrôler une centrale nucléaire doit, par exemple, activer une série de mécanismes très rapidement en cas d\'incident ou d\'accident sans quoi les mesures déclenchées pourraient ne pas avoir l\'effet escompté. Comme le résume Kopetz (*Real-Time Systems: Design Principles for Distributed Embedded Applications*, par Hermann Kopetz, chez Springer (avril 2011), ISBN 978-1-4419-8237-7) : *"A real-time constraint is called hard, if not meeting that constraint could result in a catastrophe."* Les contraintes temporelles ne doivent pas toujours être fortes et peuvent parfois être assouplies, en fonction de l\'application visée. Une contrainte *temps réel souple* doit être satisfaite au mieux dans un certain laps de temps. Le système embarqué doit faire de son mieux, mais il n\'y aura pas de catastrophes s\'il ne sait pas toujours respecter le délai de réponse attendu. On peut prendre comme exemple une borne interactive qui vous affiche en temps réel les résultats d\'un match de foot. Ce n\'est pas grave si vous êtes averti d\'un but deux ou trois secondes en retard et on peut se contenter de temps réel souple. Une autre contrainte critique, dont on a déjà discuté, est l\'*énergie*. En effet, la plupart des systèmes embarqués sont alimentés par des batteries, et les technologies utilisées pour ces dernières n\'évoluent pas très vite. Cependant, les besoins en puissance de calcul augmentent très vite, notamment pour tout ce qui touche aux applications multimédias, et les clients ont des exigences de plus en plus grandes niveau autonomie. L\'énergie électrique disponible doit dès lors être utilisée très efficacement, devenant une contrainte pour les applications qu\'il sera possible de réaliser avec un système embarqué donné. **Système connecté** Aujourd\'hui, les systèmes embarqués ont largement dépassé, en nombre, les ordinateurs *« traditionnels »*, PC ou portable. Cette croissance a démarré avec l\'apparition de l\'*information ambiente* (on dira plutôt informatique ambiente en Europe, ubiquitaire aux USA et omniprésente au Japon), troisième ère de l\'informatique dans laquelle une très large gamme de petits appareils informatiques *« intelligents »* a été mise à disposition de l\'utilisateur. De plus, les systèmes embarqués ont également été dotés de moyens de communication, leur permettant d\'échanger de l\'information entre eux, au sein d\'un *réseau de senseurs*, par exemple, ou leur permettant de communiquer avec des applications via internet. Cette tendance, consistant à connecter, très souvent sans fil, une multitude d\'appareils à internet a conduit à l\'*internet des objets* (ou IoT, pour *Internet of Things*, en anglais). De nombreuses applications exploitent largement ces systèmes connectés sous la forme d\'*applications distribuées*. Le logiciel ne s\'exécute plus sur une seule machine cloisonnée, mais ses opérations sont largement réparties entre un grand nombre de systèmes embarqués, chacun étant responsable d\'un processus contribuant à la mission du système distribué complet. Autant les données que les calculs sont ainsi distribués. Ainsi, l\'information est disponible partout et à tout moment, et cette omniprésence permettant à tous les objets qui nous entourent de travailler de concert crée une *« intelligence ambiente »* permanente. Aspect hardware --------------- Comme précédemment annoncé, un système embarqué se compose de hardware et de software travaillant en étroite collaboration. Cette section brosse brièvement différents aspects hardware et choix qu\'il existe dans le domaine des systèmes embarqués, les principaux composants que l\'on peut retrouver ainsi que l\'architecture globale du système embarqué. ### Histoire Commençons cette section sur les aspects hardware avec un petit interlude historique. Si l\'on s\'en réfère aux documents publiquement disponibles, on peut considérer que deux composants sont à l\'origine des systèmes embarqués. Intel a produit le premier microcontrôleur commercial tandis que le premier microprocesseur a été créé pour la US Navy pour son avion de chasse Tomcat F-14. #### Intel 4004 Le premier système embarqué commercial, ou tout du moins l\'élément clé qui a permis son apparition, a été créé par Intel en 1971. Cette compagnie a introduit le premier microprocesseur sur une seule puce, l\'*Intel 4004*. La compagnie japonaise Busicom désirait une série de circuits intégrés pour différentes calculateurs qu\'elle proposait. La réponse d\'Intel fut un microprocesseur à usage général, qui pourrait être utilisé pour tous les produits de la gamme de Busicom. Ce dernier permettait d\'exécuter une séquence d\'instructions placées dans une puce mémoire externe. Le hardware offre donc la puissance de calcul et le software définit la fonction calculée. La figure 6 montre l\'Intel 4004 ainsi que le calculateur Unicom 141P, version OEM du 141-F, premier produit commercial à utiliser le premier microprocesseur d\'Intel.  Figure 6. La variante D4004 du microprocesseur Intel 4004 est en céramique et fonctionne sur 4 bits avec une fréquence CPU maximale de 740 kHz. Il est composé de 2300 transistors et est distribué sous forme de DIP à 16 pins. Sa première utilisation commerciale a été pour le calculateur 141-PF de la firme japonaise Busicom. #### Central Air Data Computer Un peu avant l\'Intel 4004, le premier microprocesseur a été développé pour l\'US Navy de 1968 à 1970 et décrit dans un article (*Architecture Of A Microprocessor*, par Ray M. Holt, dans Computer Design Magazine (janvier 1971), pages 1--26) qui n\'a été rendu public qu\'en 1998. Ce microprocesseur, le MOS-LSI, a été conçu comme unité de calcul du *Central Air Data Computer* (CADC) utilisé dans l\'avion de chasse Tomcat F-14. Son but consistait à évaluer des fonctions spécialisées en réponse à des stimuli fournis par des senseurs tels que la pression, la température, etc. afin de contrôler différents systèmes de l\'avion et de présenter des données au pilote. ### Boucle hardware Le hardware est souvent utilisé dans une boucle présentée sur la figure 7, qui est la même utilisée dans la méthode de test *"hardware in a loop"* (HIL). Des stimuli extérieurs en provenance de l\'environnement vont arriver sur le hardware qui réagira en produisant signaux en sortie. Le tout se répète dans une boucle *environnement *→→* senseur *→→* système embarqué *→→* actuateur *→→* environnement *→→* \...* On peut également voir sur la figure que l\'*unité de calcul centrale* (CPU) peut interagir, au sein du système embarqué, avec différents éléments tels que des convertisseurs A/D et D/A (convertisseur analogique vers numérique et inversement : A/D pour *Analog-to-Digital* et D/A pour *Digital-to-Analog*), de la mémoire et d\'autres unités de calcul de type FPGA ou ASIC (FPGA pour *Field-Programmable Gate Array* est un circuit intégré reprogrammable et un ASIC pour *Application-Specific Integrated Circuit* est au contraire spécifique à une fonction et non modifiable). Ces différents composants, périphériques à l\'unité de calcul, sont détaillés plus loin dans la section. oucle hardware Figure 7. Le hardware d\'un système embarqué (cadre gris) est souvent utilisé dans un mode *"hardware in a loop"*, c\'est-à-dire dans une boucle qui passe à travers le système embarqué et l\'environnement. #### #### Unité de calcul Après l\'apparition de l\'Intel 4004 et du MOS-LSI, de nombreux autres types d\'*unités de calcul* ont vu le jour, chacun ayant ses propres spécificités. Dans le monde des systèmes embarqués, il y a une pléthore de choix possibles pour déterminer l\'unité de calcul qui sera utilisée. Il y a tout d\'abord le *processeur*, notamment caractérisé par son *jeu d\'instructions*, c\'est-à-dire l\'ensemble des instructions qu\'il est capable d\'exécuter, par sa *fréquence d\'horloge* (Hz) et au nombre d\'instructions exécutables par secondes (MIPS). Ces deux dernières caractéristiques permettent d\'établir ses capacités et sa puissance de calcul. On retrouve également des *circuits spécifiques* qui implémentent des fonctions directement câblées en hardware. Ce deuxième type d\'unité de calcul est moins générique, mais plus rapide, performant et généralement plus compact que les processeurs. Plusieurs types d\'implémentations sont possibles pour les unités de calcul, allant de systèmes plus génériques comme l\'Intel 4004 vers des solutions beaucoup plus spécifiques. On distingue essentiellement quatre grandes catégories : - Le *General Purpose Processor* (processeur à usage général) (GPP) propose un jeu d\'instructions assez large et varié permettant de réaliser beaucoup de choses. C\'est le genre de processeur que l\'on retrouve notamment dans les ordinateurs *« traditionnels »*. - L\'*Application-Specific Instruction set Processor* (processeur dont le jeu d\'instructions est spécifique à l\'application) (ASIP) possède un jeu d\'instructions qui est spécifiquement conçu pour un certain ensemble d\'opérations. - Vient ensuite le *hardware reprogrammable* dont la fonction peut être modifiée après sa fabrication, une fois sorti d\'usine donc. Pour être précis, il s\'agit plus d\'une reconfiguration que d\'une reprogrammation étant donné que ce type d\'unité de calcul n\'exécute pas d\'instructions. - Enfin, l\'unité de calcul la plus spécifique est l\'*Application-Specific Integrated Circuit* (circuit intégré propre à une application et spécialisé pour cette dernière) (ASIC) qui est un circuit intégré réalisant les fonctions nécessaires pour une application donnée. Comme le résume la figure 8, on peut comparer ces différents types d\'unités de calcul sur base de deux critères. Au plus l\'unité de calcul sera générique, au plus grande sera la flexibilité qu\'elle offre pour l\'utiliser et la programmer mais par contre, au moins les performances et la consommation énergétique seront bonnes. Si ces deux derniers critères sont importants, il convient de se déplacer vers des unités de calcul plus spécifiques. Néanmoins, ces dernières ont un cout plus important, dû à la conception et au développement des circuits et dû au fait qu\'ils ne peuvent pas forcément être produits en masse comme les processeurs à usage général (microprocesseur et microcontrôleur). Les *Application Specific Standard Product* (ASSPs), cités précédemment, sont une version un peu plus générale que les ASICs. Il s\'agit de circuits intégrés implémentant une fonction spécifique visant un large marché, contrairement aux ASICs qui combinent plusieurs fonctions pour offrir une solution précise pour un client. Enfin, les FPGA sont souvent utilisés comme plateforme de prototypage pour des ASIC.  Figure 8. Une unité de calcul générique sera plus flexible, mais au détriment de moins bonnes performances et d\'une efficacité énergétique moindre, et inversement pour les unités de calcul spécifiques. ### Architecture matérielle L\'*architecture matérielle* d\'un système embarqué liste les composants le constituant ainsi que la manière avec laquelle ils sont agencés entre eux. Il existe plusieurs types de représentations possibles pour décrire une architecture matérielle, la plus courante et pratique étant un *diagramme blocs*, un peu comme celui de la figure 7. Ce type de diagramme comporte généralement : - Des blocs qui représentent les différents composants, unités ou sous-systèmes composant le système embarqué, selon le niveau d\'abstraction désiré pour la description de l\'architecture matérielle. - Des liens entre blocs qui représentent un contrôle, une commande, un échange d\'information, avec éventuellement le type de communication utilisé, de nouveau selon le niveau d\'abstraction désiré. Voyons un exemple d\'un système qui mesure la température d\'une pièce pour activer un ventilateur si cette dernière est trop élevée. Un écran LCD est également présent pour afficher la température courante. La figure 9 montre le diagramme blocs de ce système. On y voit, au centre, un microcontrôleur de type ARM7TDMI. Sur la gauche, un senseur de température LM35 est connecté comme entrée sur le microcontrôleur. En haut, on retrouve un écran LCD et sur la droite un driver moteur L293D. Ces deux composants sont connectés comme sorties du microcontrôleur. Enfin, tout à droite se trouve le moteur DC du ventilateur, contrôlé par le driver moteur. entilateur contrôlé par la température Figure 9. La température de la pièce est mesurée à l\'aide d\'un senseur LM35, est récupérée par un microcontrôleur LPC2378 qui décide d\'activer ou non un moteur à partir d\'un driver L293D, selon la température mesurée, affichée sur l\'écran LCD. Ce diagramme bloc de haut niveau permet de rapidement voir les composants qui constituent le système embarqué et les liens qui existent entre eux. On peut également voir le *flux d\'information*, c\'est-à-dire là où des données sont transférées entre composants. On peut aller plus loin, et rentrer dans les détails des connexions entre les composants. Par exemple, on peut montrer les pins des différents composants et comment elles sont reliées entre elles. On obtient ainsi un *schéma de montage* ou de câblage qui vous permettra, notamment, de réaliser le système embarqué sur une plaque de prototypage. On peut imaginer d\'autres niveaux d\'abstraction, où l\'on présentera également des composants de plus bas niveau tels que des résistances, condensateurs, transistors, etc. L\'important est de choisir le niveau adapté au public ciblé, et à ce que le diagramme doit communiquer. #### Architecture type La figure 10 montre l\'architecture type d\'un système embarqué. On y voit les principaux composants que l\'on retrouve dans la plupart des systèmes embarqués; ils sont décrits dans la section suivante. Deux ouvertures vers le monde extérieur sont présentes : le bus de périphériques et un port utilisé pour le debug des programmes. Pour le reste, outre le processeur, on peut voir qu\'il y a des horloges, des mémoires, des dispositifs généraux, spécifiques et de communication. Ces composants sont reliés au processeur à l\'aide de bus système pouvant être de différents types. Cette architecture type se retrouve, par exemple, sur des cartes telles que l\'Arduino, la Raspberry Pi ou la BeagleBone Black, présentées plus loin dans ce livre.  Figure 10. L\'architecture type d\'un système embarqué se compose d\'un processeur, d\'horloges, de mémoires, des dispositifs généraux, spécifiques et de communication. ### Principaux composants Un système embarqué étant destiné à une application spécifique, son hardware est spécialement conçu pour ce dernier. On élimine, par exemple, tout circuit superflu afin de réduire les couts engendrés par des ressources inutiles. De plus, plusieurs choix sont possibles pour l\'unité de calcul à prendre. Voyons ici une série de *composants* ou sous-systèmes de l\'architecture type d\'un système embarqué. #### Alimentation Plusieurs options sont possibles pour *alimenter en énergie* un système embarqué. S\'il ne doit pas être portable, on peut utiliser un adaptateur secteur AC/DC et sinon, il peut être alimenté par une batterie. Dans les deux cas, plusieurs plages de fonctionnement doivent être disponibles pour les éventuels besoins différents des composants d\'un même système embarqué. On retrouve typiquement les quatre plages suivantes : - 5.05.0 V ±0.25±0.25 V - 3.33.3 V ±0.3±0.3 V - 2.02.0 V ±0.2±0.2 V - 1.51.5 V ±0.2±0.2 V Un bon sous-système d\'alimentation est important pour un système embarqué. Il doit notamment posséder les caractéristiques suivantes : - Il doit fournir une tension la plus stable et lisse possible. Cela est important pour certains composants comme les ADCs qui nécessitent une tension constante pour que la conversion du signal analogique en numérique soit précise. Pour cela, il est intéressant de prévoir des régulateurs de tension. - Il doit fournir suffisamment de courant pour le fonctionnement du système embarqué et de ses composants. Cette contrainte peut notamment limiter le nombre de périphériques qui seront directement alimentés par le système embarqué. - L\'alimentation doit être efficace, offrir de bonnes performances et la plus stable possible, étant donnés des variations de température et le fait que la circulation d\'air peut être très limitée voire nulle. - Enfin, un découplage doit être mis en place entre certains composants qui doivent être alimentés séparément : l\'horloge et les circuits de reset, les ports d\'entrée/sortie externes et les timers. L\'horloge et les circuits de reset ne doivent pas subir d\'interférences radioélectriques. Les périphériques d\'E/S peuvent dissiper plus de puissance que les unités internes du processeur. Enfin, les timers dissipent une puissance constante, même lorsqu\'ils sont en mode attente. Les systèmes basse tension sont construits à partir de portes *Low Voltage CMOS* (LVCMOS) et de *Low Voltage Transistor-Transistor Logic* (LVTTL). Il y a une relation inversement proportionnelle entre la tension opérationnelle et les délais de propagation dans les portes CMOS, ce qui tend à favoriser le 55 V dans la plupart des systèmes embarqués, pour réduire ces délais. Néanmoins, passer la tension à 3.33.3 V réduit la dissipation de puissance par deux. De plus, pour des systèmes à petite géométrie, le processeur et les circuits d\'E/S génèrent moins de chaleur en 3.3 V, et peuvent dès lors être mis dans des plus petits packs. Notez qu\'il existe également des systèmes embarqués qui dépendent de leur hôte pour l\'alimentation. Prenez l\'exemple d\'une carte graphique d\'un ordinateur *« traditionnel »* qui sera alimentée, directement, par la carte mère à laquelle elle est branchée. Enfin, des plus petits systèmes nécessitant moins de puissance, comme les cartes à puce, peuvent être alimentés par une pompe de charge. #### Horloge L\'*horloge* est le second composant essentiel, avec l\'alimentation en énergie. En effet, elle est utilisée pour cadencer le fonctionnement du processeur et donc l\'exécution des instructions. C\'est à son rythme que le processeur répète inlassablement le cycle *fetch-decode-execute*, récupérant les instructions depuis la mémoire, les décodant et les exécutant. Le *circuit oscillateur d\'horloge* peut utiliser un crystal externe au processeur, un résonateur céramique associé de manière interne au processeur ou enfin un oscillateur externe sous la forme d\'un circuit intégré rattaché au processeur. Le crystal offre la solution la plus stable en fréquence, mais doit être placé le plus près possible du processeur. À l\'opposé, le résonateur céramique est interne au processeur, mais moins stable (dérive d\'une dizaine de minutes par mois, comparé à entre une et cinq minutes pour le crystal). Enfin, le circuit intégré externe est beaucoup plus contrôlable, ce qui est notamment utile lorsque différents composants du système embarqué sont pilotés de manière concurrente. Un système embarqué contient également des *Real-Time Clocks* (RTC), c\'est-à-dire des circuits de timer. Elles sont utilisées par divers composants, notamment l\'ordonnanceur de tâches dans le cadre d\'un microprocesseur ou pour des systèmes temps réel. #### Mémoire Un autre type de composant que l\'on retrouve dans tous les systèmes embarqués est la *mémoire*. Il existe de nombreux types de mémoire pouvant être permanentes ou volatiles, internes ou externes. Concernant les systèmes embarqués, on retrouve notamment les trois types suivants : - La *Read-Only Memory* (mémoire morte, ou mémoire à lecture seule) (ROM) est une mémoire permanente et en lecture seule utilisée pour stocker le programme exécuté par le système embarqué. Le processeur y récupère les instructions à exécuter. On y retrouve également d\'autres données comme le code de démarrage et d\'initialisation du système, des pointeurs vers une série de routines, etc. - La *Random-Access Memory* (mémoire vive, ou mémoire à accès aléatoire) (RAM) est une mémoire volatile utilisée comme mémoire de travail. Elle stocke les variables créées par le programme et est utilisée comme mémoire tampon d\'entrée/sortie pour le traitement de son ou d\'images, par exemple. - Enfin, l\'*Electrically Erasable Programmable ROM* (mémoire ROM effaçable électriquement) (EEPROM) est une mémoire permanente, mais dont le contenu peut être modifié en flashant la mémoire à l\'aide d\'un procédé électrique. On l\'utilise notamment comme mémoire cache, pour stocker une copie des instructions et données chargées à l\'avance depuis une mémoire externe ou des résultats temporaires de calculs pour du traitement rapide. #### Entrée/sortie Le système embarqué doit être capable de communiquer avec des *dispositifs externes*, comme des senseurs, boutons et circuits transducteurs, à travers des ports d\'entrée. Ces différents dispositifs sont identifiés par des ports possédant une adresse. Dans l\'autre sens, la communication d\'information vers le monde extérieur se fait via des ports de sortie. Des exemples de sorties sont les LEDs, écrans LCD, etc. Un port de sortie est également identifié par une adresse. Un premier exemple très simple de périphérique est le port *General Purpose Input/Output* (entrée/sortie à usage général) (GPIO), illustré à la figure 11. Il permet de connecter directement le processeur avec le monde extérieur et d\'autres dispositifs, produisant deux valeurs de tension pour chaque pin GPIO, c\'est-à-dire une valeur binaire. Chaque pin GPIO peut aussi bien servir comme entrée, par exemple pour renseigner l\'état d\'un bouton au processeur, que comme sortie, par exemple pour allumer une LED. ort GPIO Figure 11. Un port GPIO expose plusieurs pins dont les directions et les valeurs sont contrôlées par des registres accessibles au processeur. Plus précisément, un *port* est un dispositif capable recevoir des données provenant d\'un périphérique, d\'un processeur, d\'un contrôleur extérieur pouvant ensuite être lues par le processeur. Dans l\'autre sens, un port permet d\'envoyer des données vers l\'extérieur à partir d\'instructions exécutées par le processeur. La connexion du port vers le processeur se fait via un *bus*, sur lequel un échange d\'information se produit. On distingue deux méthodes de transmission de données sur un bus. Pour un *bus série*, l\'information circule bit à bit et pour un *bus parallèle*, plusieurs bits peuvent être transmis en même temps. Historiquement, les communications parallèles étaient plus rapides puisque l\'on transférait plus d\'information à la fois. Néanmoins, le cout et la complexité hardware additionnels (plus de fils, émetteurs et récepteurs plus complexes) ont rendu les communications séries plus populaires et plus efficaces avec l\'augmentation des fréquences d\'horloge. Aujourd\'hui, le parallèle est limité à des communications entre composants physiquement proches, et le série pour des communications à plus longues distances. Une autre caractéristique des bus est la manière avec laquelle le rythme de la communication se déroule. Dans un bus *synchrone*, la communication suit une horloge qui permet d\'indiquer si une donnée est disponible et valide ou non. Les deux extrémités du bus doivent suivre la même horloge. Un bus *asynchrone* quant à lui va transmettre des balises sur le canal de communication, délimitant ainsi les données valides ou non. Ce type de bus est plus simple et bon marché, adapté à des communications à intervalles irréguliers. Son principal désavantage est la surcharge causée par les bits de contrôle. Un bus synchrone aura donc un plus gros débit, n\'ayant pas cette surcharge. Il existe plusieurs types de bus, qui sont décrits plus loin dans ce livre. On retrouve notamment les bus I2C2C, SPI, CAN, USB et PCI qui diffèrent entre eux essentiellement de part le protocole de communication qu\'ils proposent et de par leurs caractéristiques. #### Support analogique Enfin, terminons le tour des principaux composants avec le *support du monde analogique*. En effet, un système embarqué peut devoir lire une entrée analogique comme un son provenant d\'un micro, par exemple, ou produire un signal analogique, par exemple pour contrôler un moteur. On parle alors de *système hybride* combinant les mondes discret numérique et continu analogique. Pour produire une sortie analogique, on prévoit typiquement une unité *Pulse Width Modulator* (PWM) qui permet de construire un signal continu à l\'aide d\'états discrets. Dans l\'autre sens, pour récupérer un signal analogique en entrée, on prévoit une unité *Analog-to-Digital Converter* (ADC) qui va discrétiser un signal continu pour en récupérer une séquence binaire. ### Choix technologique Que faut-il choisir comme technologie, au niveau hardware, pour un système embarqué ? Comme on l\'a déjà vu précédemment, on a une palette de choix allant d\'un système spécifique implémenté en ASIC à un système générique sous forme de processeur à usage général. Lorsque l\'on doit développer un système embarqué, il est moins couteux de démarrer avec un processeur général en implémentant les fonctions désirées en software. On se tournera donc vers un microprocesseur ou un microcontrôleur, que l\'on pourra programmer au niveau software. Cette solution est plus flexible et moins chère, mais peut souffrir au niveau des performances. Une fois le processeur choisi, toute l\'optimisation doit se faire au niveau logiciel et cela peut avoir un cout non négligeable. Pour améliorer les performances, une solution consiste à remplacer le duo processeur-software par un circuit intégré de type ASIC, avec les mêmes fonctions implémentées en hardware. Cette solution est évidemment plus onéreuse et prendra beaucoup plus de temps de développement. Elle n\'est pas flexible et il est très difficile, voire impossible, de modifier ou faire évoluer les fonctions implémentées. Comme le résume la figure 12, avoir plus de flexibilité se fait au prix d\'une plus grande consommation de puissance et d\'énergie. Il faut savoir que des observations tendent à montrer qu\'une fonction software consomme environ dix fois plus de puissance que la même fonction réaliser en hardware pur.  Figure 12. La flexibilité offerte par la technologie utilisée est inversement proportionnelle à la puissance et à l\'énergie consommée par le système embarqué, notamment à cause de la partie software (SW) à exécuter pour les processeurs. Dans un cycle de développement général, on aura tendance à commencer par concevoir un prototype du système embarqué à réaliser avec une technologie plus flexible, c\'est-à-dire basée sur un processeur. Cette flexibilité permet de tester et d\'expérimenter différentes variantes des fonctions désirées pour le système embarqué. Une fois le prototype ainsi validé, on décidera de migrer tout ou une partie des fonctions en hardware pur en codant ces fonctions directement en ASIC, avec éventuellement une nouvelle phase de prototypage à l\'aide de FPGAs. La figure 13 apporte un autre point de vue. On peut y voir l\'évolution du nombre d\'opérations réalisables par Watt en fonction de la taille de la technologie utilisée, pour les ASICs, le hardware reconfigurable et les processeurs. Ce nombre d\'opérations augmente bien évidemment lorsque les circuits intégrés diminuent en taille. Ce que l\'on voit également, c\'est qu\'en allant vers du hardware câblé pur, le gain obtenu est d\'un ordre de grandeur (échelle logarithmique sur l\'axe vertical). Enfin, on voit que les processeurs spécialisés comme les DSPs représentent le meilleur cas de la tranche processeurs, frôlant le hardware reprogrammable comme les FPGAs et que les microprocesseurs représentent le pire cas. aille par rapport au nombre d\'opérations par watt Figure 13. Diminuer la taille des circuits intégrés augmente le nombre d\'opérations qu\'il est possible de réaliser par watt consommé, peu importe le type d\'implémentation choisi. Mais se tourner vers l\'ASIC donnera toujours des meilleures performances que d\'utiliser un processeur à usage général. Aspect software --------------- Le software est la partie la plus importante d\'un système embarqué, du moins pour ceux basés sur un processeur. En effet, il représente la fonction réalisée par le système, son cerveau en quelque sorte. Cette section décrit quelles sont les différentes possibilités pour programmer un système embarqué et quelles sont les considérations particulières à prendre en compte. Il s\'agit essentiellement d\'une introduction des éléments de base puisque la suite du livre concerne essentiellement la programmation et les aspects software. Tout au long de la section, il faut garder en tête qu\'un software développé pour un système embarqué n\'est généralement pas portable directement sur un autre, le lien avec le hardware étant plutôt fort. Cela renforce notamment l\'utilisation de systèmes embarqués de plus haut niveau, exécutant un Linux embarqué. Dans ce cas, il est possible d\'écrire un seul programme qui pourra être directement exécuté sur tout hardware étant capable d\'exécuter un Linux embarqué. ### Système réactif Un système embarqué est un *système réactif*, c\'est-à-dire qu\'un comportement sera exécuté en réaction à des évènements provenant de son environnement. Si l\'on s\'en réfère à la définition proposée par *Bergé et coll.* (*High-Level System Modeling: Specification Languages*, par Jean-Michel Bergé, Oz Levia et Jacques Rouillard, chez Springer (1995), ISBN 978-1-4613-5973-9), un système embarqué est en interaction continuelle avec son environnement, rythmant son exécution : *"A reactive system is one that is in continual interaction with its environment and executes at a pace determined by that environment."* C\'est l\'environnement qui impose son rythme au système embarqué et pas l\'inverse. Par conséquent, il est important de bien connaitre cet environnement et les contraintes qu\'il impose avant de choisir le type de système embarqué qui sera utilisé et de le programmer. Il faut en effet pouvoir au minimum suivre le rythme imposé par l\'environnement. Un système embarqué réagit essentiellement à deux types d\'évènements en provenance de son environnement externe ou interne. Il y a des évènements *périodiques* comme on peut retrouver dans des machines tournantes ou des boucles de contrôle et des évènements *non périodiques* provoqués, par exemple, par la pression de boutons. Enfin, concernant le développement logiciel à proprement parler, la programmation orientée évènements pourrait être un paradigme adapté pour développer des programmes adaptés aux systèmes embarqués. #### Temps réel Certains systèmes embarqués doivent être hautement réactifs, en ce sens qu\'ils sont tenus de réagir à certains évènements endéans une deadline fixée; ils sont dits *systèmes temps réel*. Il y a essentiellement deux catégories de systèmes temps réel et on peut les différencier en examinant ce qui se passe si une deadline est manquée. Dans le cas du système de contrôle d\'un avion, si un système de sécurité n\'a pas réagi endéans une deadline, les conséquences peuvent être graves si cela mène l\'avion à un crash, par exemple. Dans le cas d\'un système embarqué qui gère l\'émetteur d\'une communication satellite, si un paquet de données a été transmis un peu plus tard que prévu, les conséquences ne sont pas si graves. La caractérisation temps réel d\'un système embarqué n\'est donc pas une question de vitesse de réaction, mais bien de *respect de deadlines*. Le temps restant avant la prochaine deadline peut être de quelques microsecondes, voire de quelques heures. La figure 14 montre plusieurs domaines et le type de contrainte temps réel (aucune, souple ou forte). Une simulation sur PC n\'a pas de contraintes temps réel, elle se déroule simplement au rythme de ce que permet la puissance de la machine. On monte ensuite doucement en exigence avec les interfaces utilisateur et la diffusion de vidéos sur internet pour arriver aux contraintes temps réel souples avec le cruise control. De là, on continue d\'augmenter les exigences avec la télécommunication, le contrôle aérien et enfin les moteurs contrôlés par de l\'électronique, où il est très important de réagir endéans des deadlines imposées.  Figure 14. Un système embarqué peut avoir des contraintes temps réel fortes, souples, ou alors n\'en avoir aucune. #### #### Polling et interruption Le software interagit avec le hardware pour réaliser la fonction du système embarqué. Pour cela, il va notamment devoir communiquer avec différents périphériques, pour acquérir des données en provenance de senseurs, par exemple. Cette acquisition peut se faire de différentes manières, typiquement par polling ou avec le mécanisme d\'interruption. Le *polling*, également appelé attente active, consiste à régulièrement inspecter la valeur de registres d\'état qui indiquent si les données attendues sont disponibles ou non. Une fois que c\'est le cas, elles peuvent être lues pour ensuite être traitées. Le *mécanisme d\'interruption* fonctionne dans l\'autre sens, c\'est-à-dire que c\'est le périphérique qui va prévenir le processeur une fois que les données sont disponibles, en l\'interrompant. Dans le premier cas, le processeur étant en attente active, il ne peut rien faire d\'autre en attendant que les données soient disponibles. Dans le second cas, il va pouvoir exécuter du code avant d\'être interrompu. Ces deux solutions ont chacune des avantages et inconvénients, chacune étant plus adaptée à certaines situations concrètes, décrites plus loin. Le choix sera d\'autant plus critique dans le cadre d\'un système temps réel, étant donné les contraintes fortes au niveau du respect des deadlines; on ne peut pas toujours se permettre d\'attendre un périphérique. ### Programmation Un système embarqué doté d\'un processeur a besoin de *code* pour faire quelque chose. Ce dernier est placé dans une mémoire accessible par le processeur afin de pouvoir être exécuté, instruction par instruction. Typiquement, le software d\'un système embarqué sera présenté sous la forme d\'une *image ROM*, définitive et non modifiable. Étant donné un système embarqué, on connait la taille de la ROM qu\'il possède et donc les adresses de tous les emplacements mémoire disponibles. Pour chacun de ces emplacements, il faut en définir le contenu binaire représentant des instructions à exécuter. Ces instructions sont écrites en respectant le jeu d\'instructions du processeur utilisé, ce qui peut évidemment prendre beaucoup de temps à comprendre avant de commencer à programmer. Pour éviter de mémoriser les codes machine de toutes les instructions d\'un processeur donné, on peut programmer à l\'aide d\'un *langage d\'assemblage*, représentation textuelle de plus haut niveau du code machine. Un programme écrit dans un langage d\'assemblage est traduit en code machine par l\'assembleur. Programmer à un tel niveau reste une tâche fortement consommatrice de temps, mais peut être plus efficace si l\'on s\'aide de librairies de code préexistant. Enfin, pour gagner du temps de développement, il est possible d\'utiliser un *langage de haut niveau* qui offre des constructions et abstractions plus pratiques et proches de la façon de penser du développeur et du problème qu\'il veut résoudre. Un exemple d\'un tel langage, adapté aux systèmes embarqués, et qui reste d\'assez bas niveau et proche du hardware est le *langage C*. Un programme écrit dans un langage de haut niveau est compilé en code machine par le compilateur. La figure 15 résume les trois principales possibilités de programmation d\'un système embarqué : directement en langage machine, via un langage d\'assemblage ou à l\'aide d\'un langage de haut niveau. La phase de traduction d\'un langage d\'assemblage est quasi immédiate et unique tandis que la phase de compilation d\'un langage de haut niveau peut être faite de plusieurs manières et donc optimisée. iveaux de programmation Figure 15. Un système embarqué peut être directement programmé en langage machine, à partir d\'un langage d\'assemblage qui sera traduit par un assembleur ou d\'un langage de haut niveau qui sera compilé par un compilateur. ### Développement Développer un logiciel pour un système embarqué ne se fait pas complètement de la même manière que pour un logiciel destiné à un ordinateur *« traditionnel »*. En effet, il ne sera pas toujours possible de directement développer sur le système embarqué, mais il faudra le faire sur un système hôte. La figure 16 résume le processus de développement type. Une fois que le développeur a compilé un code machine sur le système hôte, il l\'envoie sur le système cible ou il l\'exécute sur un émulateur ou simulateur sur le système hôte. Dans le cas où le code est envoyé sur le système cible, il est possible de le débugger en runtime, par exemple avec le standard JTAG présenté plus loin dans ce chapitre.  Figure 16. Le développement est typiquement réalisé sur une plateforme hôte avant envoi du code et exécution sur la plateforme cible. Le debugging peut se faire à différents niveaux, en émulation sur l\'hôte ou directement sur la cible. Concernant la procédure de développement, il n\'y en a évidemment pas une seule unique à suivre. Il est cependant important de coordonner le développement des aspects hardware avec celui des aspects software. La figure 17 reprend les grandes étapes de développement. La première phase consiste évidemment à établir les spécifications précises du système à développer. Il faut notamment caractériser l\'environnement d\'exécution et identifier les contraintes qu\'il impose. De plus, il faudra faire des choix par rapport aux niveaux de fiabilité et d\'efficacité désirés. À partir de ces spécifications, il faudra déterminer ce qui sera fait en hardware et en software, et décider des composants à utiliser. Plusieurs itérations peuvent être nécessaires à cette seconde étape, qui est par ailleurs très importante car c\'est un point de non retour. Vient ensuite le développement, en parallèle, des parties software et hardware qui seront ensuite intégrées, puis testées et validées. Une fois le système développé et déployé, on entre dans une phase importante de maintenance. Le système doit être monitoré, des bugs éventuels doivent être corrigés et des mises à jour peuvent être appliquées. rocessus de développement d\'un système embarqué Figure 17. Le processus de développement d\'un système embarqué se fait partiellement en parallèle pour les aspect hardware et software, mais avec plusieurs phases communes pour coordonner les deux aspects. #### #### Debug Débugger le software d\'un système embarqué est une tâche plus compliquée que pour un logiciel développé sur un ordinateur *« traditionnel »*. Une possibilité consiste à utiliser les *standards JTAG* (le *Joint Test Action Group* (JTAG) est une association d\'industries d\'électroniques qui développe des méthodes pour vérifier et tester des circuits imprimés) qui offrent notamment un protocole basé sur une communication série pour accéder au processeur et bus système. ### Système d\'exploitation Terminons ce tour des aspects software en introduisant la notion de *système d\'exploitation*. Il s\'agit d\'un programme qui est exécuté sur le hardware et qui joue le rôle d\'intermédiaire entre le hardware et les applications utilisateur. Sur un ordinateur *« traditionnel »*, les systèmes d\'exploitation les plus connus sont Windows, MacOS et Linux. Un système d\'exploitation offre des abstractions des composants hardwares pour faciliter la programmation. Par exemple, on peut manipuler des fichiers sur le disque dur, des fenêtres sur l\'écran, des processus sur le processeur, etc. Le développeur ne doit ainsi plus se soucier de savoir contrôler le hardware à très bas niveau, il exploite les services offerts par le système d\'exploitation. **Vues de l\'ingénieur et du client** Aujourd\'hui, on pourrait croire qu\'on en arrive à une situation où l\'ordinateur tel qu\'on le connait, c\'est-à-dire le *« traditionnel »*, est en train de disparaitre au profit d\'une multitude de nouvelles machines, plus petites, spécialisées, intelligentes\... Trois grandes tendances émergent actuellement, que l\'on pourrait toutes traduire par *« informatique omniprésente »* en français, mais que l\'on peut nuancer en anglais : - *Ubiquitous computing* se réfère à un but à long terme qui est d\'avoir l\'information présente à tout moment et disponible partout (*"Information anytime, everywhere"*). - *Pervasive computing* met l\'accent sur les aspects pratiques et l\'exploitation de technologies déjà existantes. - *Ambient intelligence* concerne les technologies de communication pour les maisons du futur et les smart cities. En pratique, l\'ordinateur *« traditionnel »* ne va évidemment pas disparaitre dans l\'absolu, mais plutôt de manière relative aux systèmes embarqués propulsés par l\'internet des objets. **Évolution hardware versus software** Aujourd\'hui, c\'est le software qui dirige principalement le design des systèmes embarqués. En effet, le cout hardware est essentiellement un cout récurrent qui est principalement proportionnel au nombre d\'unités fabriquées. Par contre, sur un même matériel, plusieurs applications très différentes peuvent être développées. Le software devient alors un cout non récurrent et une conception logicielle devra être faite pour chaque application. On n\'oubliera évidemment pas les couts de correction de bugs, de maintenance et de mise à jour des softwares. La figure 18 illustre ces deux tendances, et met bien en avant l\'écart grandissant entre couts hardware et software.  Figure 18. Les couts hardware et software de développement de systèmes embarqués augmentent avec le temps, plus rapidement pour le software que pour l\'hardware. Dans certains cas, le hardware reste néanmoins primordial, par exemple lorsqu\'il s\'agit de développer un système très spécifique, souvent de type ASIC. Il n\'y a en effet pas de production industrielle de masse visée, mais de la conception et du développement pour quelques unités. **Compétence** Quelles sont les compétences nécessaires pour tout qui souhaite pouvoir travailler dans le monde des systèmes embarqués ? Elles sont évidemment multiples étant donné la haute multi-disciplinarité de ce domaine. Les principales compétences, résumées par la figure 19, sont transversales et dépassent les frontières des disciplines traditionnelles. Plutôt côté informatique, on retrouve essentiellement le développement software et la conception d\'algorithmes et plutôt côté électronique on a évidemment le développement hardware et l\'électronique d\'interface. Au milieu de tout cela, il ne faut bien entendu pas oublier le domaine d\'application, qui dépendra du projet visé et qu\'il faut comprendre. ompétences des ingénieurs en systèmes embarqués Figure 19. Les compétences qu\'il est nécessaire de maitriser pour travailler dans les systèmes embarqués sont transversales et dépassent les frontières des disciplines traditionnelles. Toute la difficulté et les défis auxquels feront face l\'ingénieur spécialisé en systèmes embarqués consisteront à faire des choix et compromis pour satisfaire au mieux les contraintes des différents domaines desquels relèvent les compétences mentionnées. En pratique, en tant qu\'ingénieur, vous allez très certainement devoir : - concevoir et implémenter des algorithmes de contrôle, de traitement de signal\... qui seront exécutés sur des microprocesseurs ; - concevoir des microprocesseurs à utiliser pour des applications embarquées ; - concevoir des logiciels, comme par exemple des RTOS, pour le marché des systèmes embarqués ; - faire partie d\'équipes dans des domaines utilisant les applications embarquées ; - développer des senseurs/actuateurs, par exemple des *Microelectromechanical systems* (un microsystème électromécanique comporte des éléments mécaniques et utilise l\'électricité comme source d\'énergie pour réaliser une fonction de capteur ou actionneur) (MEMS). De plus, les compromis que vous devrez faire seront complexes étant donné qu\'ils se situent à différents niveaux. Tout d\'abord, il s\'agit d\'optimiser plusieurs critères et pas seulement la vitesse d\'exécution. Ensuite, il n\'y a pas que le processeur qu\'il faut considérer, mais également tout ce qui gravite autour comme les périphériques, les communications, les algorithmes, etc. Enfin, il n\'y a pas que la conception initiale du produit à gérer mais également tout le cycle de vie du système embarqué. En particulier, trois catégories d\'éléments sont à prendre en compte : - Multi-objectifs : fiabilité, abordabilité, sécurité, sûreté, évolutivité et mise à l\'échelle, ponctualité. - Multi-discipline : hardware et software, algorithme de contrôle, interface électronique, domaine d\'application. - Cycle de vie : exigence, conception, usinage, déploiement, logistique et retraite. L\'ingénieur spécialisé en systèmes embarqués ne doit évidemment pas être un expert dans tous les domaines techniques présentés à la figure 19. Par exemple, il ne développera certainement pas seul un nouveau kernel ou système d\'exploitation ni ne devra concevoir un microcontrôleur ou microprocesseur from scratch, tout seul. Il doit cependant comprendre ces domaines afin de pouvoir interagir avec les spécialistes qui joindront l\'équipe de développement du nouveau système embarqué. **Client** Et le client dans tout ça, que voit-il et que désire-t-il ? Pour lui, les systèmes embarqués sont un moyen de diminuer les couts, en achetant des systèmes plus petits et moins chers. Le client va pouvoir acheter un appareil spécialisé pour ce qu\'il désire au lieu d\'acheter une machine plus chère et qui fait pleins d\'autres choses pas nécessaires pour le client. Les systèmes embarqués permettent aussi d\'offrir de nouvelles fonctionnalités, de part leur intégration dans d\'autres objets, qui n\'étaient pas réalisables avec des appareils plus *« traditionnels »*. Ils vont également contribuer à améliorer les performances du système.