Les systèmes embarqués sont présents partout dans notre vie quotidienne. Beaucoup d’objets d’utilisation courante sont contrôlés par des systèmes embarqués, plus ou moins dissimulés dans ces derniers : par exemple, le régulateur de vitesse de notre voiture.

Certains de ces systèmes sont particulièrement critiques, comme le système de guidage d’un avion, et nécessitent des procédés de conception et de validation plus poussés. Le logiciel et le matériel doivent passer par des phases de certification qui seront une garantie sur leur bon fonctionnement. Pour réaliser cette certification, différentes méthodologies et standards sont proposés, notamment : DO-178B, ARINC653. DO-178B traite des problématiques de criticité et de sûreté de systèmes avioniques en fixant des contraintes de développement. Le standard avionique ARINC653 concerne la problématique de sûreté en isolant les composants logiciels les uns des autres lors de leur exécution (isolation spatiale et temporelle).

La généralisation des systèmes embarqués a pour conséquence une complexité accrue dans leur conception et leur validation. A cela s’ajoute des contraintes commerciales qui demandent une production dans des délais de plus en plus courts. Les concepteurs ont alors recours à des processus de génération de code qui facilitent la conception, la validation et l’implantation du système. Le concepteur fournit une abstraction du système à partir de laquelle il valide les exigences et traduit automatiquement cette abstraction en code exécutable. L’utilisation d’un tel procédé a donc pour objectif de faciliter les différentes étapes qui interviennent dans la production du système.

Cependant, cela suppose une certaine fiabilité du processus de génération. En effet, pour garantir une validation cohérente, le code exécutable généré doit être équivalent à l’abstraction du système en terme de propriétés et de performances : en particulier, il faut s’assurer que le temps d’exécution et l’occupation mémoire réels correspondent à ceux spécifiés. La difficulté initiale de mettre en place un système valide repose donc en grande partie sur la capacité à assurer la fiabilité du processus de génération. L’objectif initial d’un tel processus est de faciliter le travail de l’ingénieur en lui évitant de spécifier les détails d’implémentation. Ce processus a un impact sur la capacité à préserver les propriétés initialement indiquées dans la spécification : plus le modèle est de hautniveau d’abstraction, plus sa spécification est simple, mais plus le travail du générateur de code est important. Ainsi, faciliter la conception et obtenir une validation fiable sont des objectifs qui semblent incompatibles.

Les approches de l’Ingénierie Dirigée par les Modèles (IDM) proposent des techniques intéressantes qui peuvent répondre en partie à cette problématique. La notion de transformation de modèle-à-modèle définit un processus automatisé traduisant un modèle initial en un second modèle. Dans le contexte de la génération de code, l’utilisation d’une transformation aurait pour objectif de transformer un modèle de haut-niveau d’abstraction en un second modèle de plus basniveau d’abstraction (proche du code exécuté). De cette manière, on facilite la conception en épargnant à l’utilisateur les détails d’implémentation, en traduisant automatiquement ce modèle en un modèle plus précis afin d’aboutir à une validation plus fiable. Cependant, dans le cadre des systèmes embarqués, ce type d’approche n’a été expérimenté que dans des contextes bien spécifiques (e.g. systèmes synchrones). Aucune méthodologie n’est proposée pour adapter le générateur à différentes plates-formes d’exécution. De plus, les phases d’analyse et de génération s’enchaînent le plus souvent manuellement. Par conséquent, le modèle validé peut éventuellement aboutir à un code final n’assurant plus les propriétés vérifiées par le modèle. L’utilisateur doit alors avoir un niveau d’expertise élevé sur l’ensemble du processus pour assurer la validité du code généré.

Les systèmes embarqués temps-réel critiques (SETRC) correspondent à une famille de systèmes qui regroupe plusieurs catégories : le critique, l’embarqué et le temps-réel. Chacune implique un processus d’ingénierie bien spécifique :
– Un système est considéré critique si une défaillance particulière est capable d’engendrer des conséquences grâves comme des dégâts sur l’homme (cas du domaine des transports ou du médical), économiques, ou environnementales (cas des centrales nucléaires). Ces systèmes doivent ainsi être rigoureusement conçus et validés avant d’être implantés et mis en œuvre.
– Un système embarqué est défini comme un système autonome piloté par un logiciel intégré. Ces systèmes sont constitués d’un ensemble de capteurs et d’actionneurs qui détectent des phénomènes de l’environnement pour les uns (e.g. température, lumière, contact), et produisent des phénomènes physiques pour les autres (e.g. mouvement, son, lumière). Ils disposent de ressources limitées par rapport aux systèmes non-embarqués : mémoire, énergie… Par conséquent, ils doivent être conçus en tenant compte de ces différentes contraintes (e.g. choix des algorithmes, représentation en mémoire des informations).
– Un système temps-réel réalise un ensemble d’activités qui doivent respecter des délais imposés. Pour garantir le respect des contraintes temporelles, chaque activité doit s’exécuter dans un temps borné. De plus, l’entrelacement des exécutions des différentes activités doit aussi garantir le respect de ces délais. L’ordonnançabilité doit être assurée à la conception.

Un système temps-réel embarqué critique (SETRC) intègre ces trois aspects et présente ainsi des sources de défaillance telles que le sous-dimensionnement mémoire et le dépassement des échéances temporelles.

Évaluation de l’empreinte mémoire Le caractère embarqué du système implique des ressources limitées comme la mémoire. Le système déployé sur un OS embarqué doit tenir compte de la capacité de stockage de ce dernier. La mémoire doit être suffisante pour stocker d’une part, les données spécifiées à la conception, les données propres à l’OS mais également celles introduites lors de la génération de code. La difficulté est alors d’estimer précisément l’empreinte mémoire liée à la génération de code.

Évaluation de l’ordonnançabilité Cette contrainte est liée au caractère temps-réel du système. Celui-ci est modélisé par un ensemble de tâches ayant leurs propres contraintes temporelles. Chaque tâche réalise l’une des activités du système dans un délai borné et selon un schéma d’activation spécifique. Par exemple, une tâche va s’activer périodiquement toutes les 10 ms pour traiter les données reçues par un capteur dans un délai borné à 3 ms. Pour assurer le bon fonctionnement du système, il faut garantir que la tâche ait le temps de traiter les données avant sa prochaine activation en tenant compte du délai dû à l’exécution des autres tâches.