Le logiciel applicatif entretient un rapport confortable avec l'erreur. Quelque chose casse, un correctif s'écrit, il est déployé l'après-midi même.
Un tout autre jeu de règles
Le logiciel embarqué vit à l'intérieur d'un produit. Un contrôleur de moteur, une pompe à perfusion médicale, un véhicule, un thermostat, un satellite, un capteur d'usine. Les règles changent de quatre façons, et chacune façonne la manière dont le travail se fait.
Le matériel est figé. Si le processeur est trop lent, la mémoire trop petite ou le périphérique mal choisi, on ne peut pas mettre à niveau l'exemplaire. On ne peut changer que le logiciel — et à terme, on ne peut plus changer cela non plus.
Les ressources sont limitées et faibles. Des kilo-octets plutôt que des giga-octets, dans beaucoup de produits. L'allocation dynamique de mémoire est souvent purement et simplement interdite, car un échec d'allocation n'a pas de réponse acceptable, et la fragmentation sur des années de fonctionnement est imprévisible.
Les échéances sont réelles. En manquer une peut signifier qu'un moteur reçoit une commande erronée, qu'une boucle de régulation devient instable, ou qu'une fonction de sécurité ne se déclenche pas.
L'échec est physique. Quand un logiciel applicatif échoue, un message s'affiche. Quand un logiciel embarqué échoue, quelque chose bouge, chauffe ou s'arrête.
La discipline ne se définit pas par le langage. Elle se définit par l'impossibilité de changer d'avis plus tard.
Ce que couvre la filière
Le périmètre : microcontrôleurs, développement de firmware, systèmes d'exploitation temps réel, interfaces matériel-logiciel, pilotes de périphériques et sécurité embarquée.
Quatre domaines.
Interfaçage matériel. Registres, périphériques, interruptions, bus de communication, et la lecture de fiches techniques qui va avec.
Architecture du firmware. Boucles bare metal, systèmes d'exploitation temps réel, décomposition en tâches, et les décisions d'ordonnancement en dessous.
Programmation sous contrainte. Travailler dans des budgets de mémoire, de timing et de consommation — et le démontrer.
Cycle de vie. Mécanismes de mise à jour, sécurité, diagnostics et maintenance à long terme.
Le temps réel, c'est des échéances, pas de la vitesse
Le terme est constamment mal interprété. Le temps réel n'est pas un énoncé sur la performance. C'est un énoncé sur la prévisibilité.
Un système temps réel strict doit achever une action donnée avant une échéance donnée, absolument à chaque fois. La performance moyenne n'a aucune importance. Un système qui répond en cinquante microsecondes en moyenne et en cinq millisecondes une fois par heure n'a pas été rapide la plupart du temps. Il a échoué, une fois par heure.
Trois notions en découlent, et elles forment le cœur de la discipline.
Le temps d'exécution du pire cas. Pas le temps typique, pas celui mesuré sur une exécution normale. Le temps le plus long que le code puisse prendre, avec chaque branchement pris défavorablement, chaque cache manqué et chaque interruption arrivant au pire moment. C'est contre ce chiffre-là que l'on conçoit.
Latence et gigue des interruptions. Le temps avant que le système ne réponde à un événement externe, et l'ampleur de sa variation. La gigue compte autant que la latence dans les applications de régulation, car une boucle de contrôle suppose un intervalle d'échantillonnage fixe et se dégrade quand elle ne l'obtient pas.
Priorité et ordonnancement. Ce qui s'exécute quand plusieurs choses sont prêtes, et ce qui se passe quand une tâche de faible priorité retient une ressource dont une tâche de haute priorité a besoin. Cette situation, l'inversion de priorité, a causé de réelles pannes bien documentées sur des systèmes livrés, et les mécanismes qui l'empêchent existent précisément parce qu'elle n'a rien d'évident.
Les bugs qui n'existent que dans le travail embarqué
Une catégorie de panne que les développeurs applicatifs rencontrent rarement, et que les ingénieurs embarqués rencontrent constamment.
Conditions de course avec les interruptions. Le code principal et un gestionnaire d'interruption qui touchent la même variable, l'interruption arrivant entre la lecture et l'écriture. Cela apparaît une fois sur dix mille exécutions et disparaît dès qu'on ajoute une instruction d'affichage.
Débordement de pile. Pas de protection mémoire dans beaucoup de petits systèmes, si bien que la pile grandit silencieusement dans d'autres données, et le symptôme apparaît ailleurs, sans lien apparent, bien plus tard.
Corruption mémoire. Une erreur de pointeur ou un débordement de tampon qui endommage des données appartenant à un sous-système totalement différent, produisant une panne dont l'emplacement n'a rien à voir avec la cause.
Comportement dépendant du timing. Du code qui fonctionne à une vitesse d'horloge, un niveau d'optimisation du compilateur ou une température donnés, et échoue à un autre.
Heisenbugs. Des pannes qui disparaissent sous le débogueur, parce que le brancher change le timing qui les causait.
La conséquence pratique, c'est que le débogage embarqué repose sur des outils qui observent sans perturber : trace matérielle, analyseurs logiques, oscilloscopes, et instrumentation intégrée au produit dès la conception. Apprendre à lire un signal sur un oscilloscope n'est pas de la nostalgie. C'est souvent le seul moyen de voir la panne.
La place de cette filière dans le domaine
Les systèmes embarqués et le matériel informatique forment la cinquième des neuf filières du domaine semi-conducteurs, électronique et quantique d'Astra Trainer. Elle se marie avec l'ingénierie électronique, puisque presque toute carte embarque du firmware et que ces deux métiers partagent une frontière qu'ils disputent fréquemment, et avec la conception de puces, où les programmes de système sur puce exigent que les deux côtés soient à l'aise.
Elle se connecte aussi vers l'extérieur à la robotique, où la couche de contrôle est embarquée, à la fabrication avancée pour le contrôle industriel, et à la médecine et aux technologies de santé, où les appareils portent des obligations réglementaires. Vous pouvez voir les neuf filières ici.
L'expédition, c'est le début d'une obligation de dix ans
Un capteur industriel, un appareil médical, un véhicule ou un élément d'infrastructure de bâtiment restera en service pendant une décennie ou plus. S'il se connecte à un réseau, toute cette période constitue une exposition.
Trois problèmes séparent la sécurité embarquée de la sécurité des serveurs, et aucun n'a de réponse simple.
La mise à jour est difficile et risquée. Les appareils peuvent être injoignables, alimentés par batterie, limités en bande passante ou physiquement inaccessibles. Une mise à jour qui échoue en cours de route peut rendre un appareil inutilisable — ce qui pour certains produits signifie une visite sur site, et pour d'autres une perte pure et simple. Une mise à jour sécurisée, reprenable et vérifiée est un problème de conception qui doit être résolu avant l'expédition de la première unité, car on ne peut pas l'ajouter après coup à des appareils déjà déployés sur le terrain.
La cryptographie doit durer. Les clés et les algorithmes choisis aujourd'hui restent dans les appareils pendant toute leur durée de service. C'est ici que cette filière rejoint la communication, la détection et la sécurité quantiques, et la réponse s'appelle l'agilité cryptographique : concevoir pour que l'algorithme puisse être remplacé, plutôt que de supposer que le premier choix sera permanent.
L'obligation devient de plus en plus légale. Plusieurs juridictions ont introduit des exigences couvrant les produits connectés, dont l'interdiction des mots de passe universels par défaut, la divulgation de la durée pendant laquelle des mises à jour de sécurité seront fournies, et des processus de signalement des vulnérabilités. Les détails varient selon les marchés et évoluent, mais la direction est constante : le support de sécurité devient un engagement affiché, assorti d'une durée, plutôt qu'une question de bonne volonté.
Les métiers, nommément
Ingénieurs logiciel embarqué. Le poste généraliste.
Ingénieurs firmware. Les plus proches du matériel.
Développeurs de pilotes de périphériques.
Ingénieurs systèmes temps réel, pour les applications critiques en timing et en régulation.
Ingénieurs Linux embarqué, une spécialité distincte du travail sur microcontrôleur.
Ingénieurs d'intégration matériel-logiciel, qui font démarrer les nouvelles cartes.
Ingénieurs sécurité embarquée. Démarrage sécurisé, gestion des clés, infrastructure de mise à jour.
Ingénieurs sécurité fonctionnelle, pour les systèmes automobiles, industriels et médicaux.
Ingénieurs de test et de validation embarqués, y compris le hardware-in-the-loop.
Qui peut s'y former
Les ingénieurs logiciel applicatif. Le plus grand vivier. Ils apportent la structure, la rigueur d'outillage et les habitudes de contrôle de version qui manquent souvent aux équipes embarquées. Ce qui doit s'enseigner délibérément, c'est le modèle matériel : registres, interruptions, timing, et pourquoi l'allocation dynamique est vue avec méfiance.
Les techniciens et ingénieurs en électronique. Une reconversion depuis l'autre bord, qui détiennent déjà l'intuition matérielle et ont besoin de la structure logicielle.
Le personnel de contrôle et d'automatisation industriels. Les programmeurs d'automates programmables comprennent déjà le comportement temps réel, le scrutin déterministe et les contraintes industrielles.
Les ingénieurs de test. Vers la validation et le test hardware-in-the-loop.
Les ingénieurs informatiques et réseau. Vers le travail sur les appareils connectés et la sécurité embarquée, où la connaissance des protocoles se transpose, mais pas les contraintes de ressources.
Les ingénieurs de service terrain. Vers le diagnostic et l'ingénierie de support, détenant la connaissance des pannes de terrain que personne en développement ne possède.
Sécurité fonctionnelle et appareils réglementés. Le logiciel embarqué des appareils médicaux, des véhicules, de l'aviation, des machines industrielles et des systèmes instrumentés de sécurité est régi par des normes contraignantes et des régimes réglementaires imposant des exigences de processus de développement, de documentation, de vérification et de maîtrise des changements. Les niveaux d'intégrité de sécurité s'attribuent par une évaluation formelle, et la certification est accordée par des organismes compétents. La formation construit la capacité d'ingénierie et la conscience du périmètre de ces obligations. Elle ne confère ni certification, ni statut d'évaluateur de sécurité, ni autorité pour déployer du logiciel dans un produit réglementé.
Ce qu'il faut en retenir
Le travail embarqué se définit par des contraintes, pas par un langage. Matériel figé, mémoire réduite, échéances strictes et longue durée de vie.
Le temps réel signifie respecter une échéance à chaque fois. Le temps d'exécution du pire cas est le chiffre qui compte, pas la moyenne.
Les bugs caractéristiques sont des pannes de timing, de concurrence et de mémoire qui se cachent des débogueurs — c'est pourquoi les outils d'observation matérielle restent centraux.
La mise à jour et l'agilité cryptographique doivent être conçues avant l'expédition de la première unité, car on ne peut pas les ajouter après coup à des appareils déjà sur le terrain.
Et les deux meilleures sources de nouveaux ingénieurs embarqués arrivent de directions opposées : les développeurs applicatifs, à qui il manque le modèle matériel, et les techniciens, à qui il manque la structure logicielle.
Que signifie réellement le temps réel ?
Respecter une échéance spécifiée à chaque fois, pas aller vite. Un système qui répond rapidement en moyenne mais parfois en retard a échoué, car dans les applications de régulation et de sécurité, c'est la réponse en retard qui compte.
Pourquoi évite-t-on l'allocation dynamique de mémoire dans les systèmes embarqués ?
Parce que l'allocation peut échouer, et qu'il n'existe souvent aucune réponse acceptable à cet échec, et parce que la fragmentation sur des années de fonctionnement continu est difficile à prévoir. Beaucoup de projets allouent plutôt de façon statique au démarrage.
Pourquoi les bugs embarqués sont-ils si difficiles à reproduire ?
Parce que beaucoup dépendent du timing. Les courses d'interruption, les débordements de pile et les corruptions mémoire produisent des symptômes loin de leur cause, et brancher un débogueur change le timing qui les a créés.
Pourquoi la sécurité embarquée doit-elle se concevoir à l'avance ?
Parce qu'un appareil peut rester en service pendant une décennie, et que le mécanisme de mise à jour, la gestion des clés et la capacité à remplacer les algorithmes cryptographiques ne peuvent pas s'ajouter à des unités déjà déployées sur le terrain.
Les développeurs applicatifs peuvent-ils se reconvertir dans l'embarqué ?
Oui, et ils apportent une structure et une rigueur d'outillage utiles. L'écart qui doit s'enseigner explicitement, c'est le modèle matériel : registres, interruptions, comportement temporel et contraintes de ressources.