« Le but est d’avoir une proximité entre le matériel et le logiciel »

Techniques de l’Ingénieur : Comment définiriez-vous un système embarqué ?

Yvon Kermarrec : Un système embarqué consiste en  une association de logiciels destinés à fonctionner,  bien souvent en autonomie, sur un environnement matériel bien particulier. L’enseignement des systèmes embarqués est assez difficile. On a très vite besoin de contextes applicatifs très précis pour motiver les étudiants. La caractéristique première des systèmes embarqués est qu’ils ont une proximité avec le matériel qui est très fort. Les applications informatiques classiques, qui tournent sur PC, déroulent des instructions et produisent des résultats. Dans le cas des systèmes embarqués, on a cette notion de capteur, c’est-à-dire que pour pouvoir fonctionner, le programme va avoir besoin de lire des capteurs, d’acquérir des données, puis d’effectuer des actions sur son environnement. A la différence des entrée/sorties que l’on trouve dans les programmes classiques, on va se retrouver avec des entrées/sorties sur du matériel très précis, très pointu, que l’on va devoir acquérir, avec dans certains cas des contraintes temps réel.

Quels sont les autres caractéristiques propres aux systèmes embarqués ?

Un des points fondamentaux est la durée de vie de ces systèmes, qui est souvent très importante. Par exemple, les systèmes embarqués dans les avions ont une durée de vie d’environ 40 ans. Quand Airbus livre du software pour des applications, il va être livré en milliers d’exemplaires, et les mises à jour sont toujours très compliquées.

Parlez-nous des systèmes embarqués critiques.

Souvent, ce sont des systèmes de contrôle (automobiles, avionique, spacial). Ces systèmes, souvent critiques, engendrent des coûts monstrueux en termes de détection d’erreurs. Il faut bien imaginer que si un de ces systèmes est défaillant sur un avion de ligne en vol par exemple, les dégâts humains et matériels sont immenses, mais tous les avions équipés de ce systèmes doivent également être immobilisés durant une durée indéterminée pour vérifier la source du disfonctionnement.

Qu’en est-il de la consommation d’énergie de ces systèmes ?

Les problèmes de consommation de ressources sont partie prenante dans les recherches menées actuellement. Quand vous envoyez quelque chose sur un satellite, le poids a un coût. Tout ce qui est temps d’exécution, taille mémoire, doit alors être optimisé au maximum. Aussi, ce sont des applications qui sont dans de nombreux cas complexes (guidage d’un missile par exemple), et on a besoin de techniques en termes de génie logiciel.

Quels langages utilisez-vous pour la programmation de ces logiciels ?

La première version d’Ada a été standardisée en 1983. Il y a eu deux nouvelles versions depuis. Le langage Ada  a été conçu  pour les systèmes embarqués. Par exemple, il va permettre de coder la représentation des nombres, des structures de données, ou encore de récupérer des interruptions matérielles. Ada a été développé pour répondre aux besoins du ministère américain de la défense (US DoD). Mais son application à la problématique des systèmes embarqués était dans le cahier des charges, avec des avancés réelles en termes de temps réel et de génie logiciel.

Quel est l’avantage du langage ADA ?

J’ai travaillé auparavant sur un système de contrôle aérien pour le Canada et le compilateur Ada GNAT. J’ai donc pu à ces occasions expérimenter Ada des 2 côtés : de l’utilisateur pour les applications complexes et critiques comme le contrôle aérien et une équipe technique de 150 Personnes; et du côté compilateur, avec la mise en œuvre des différents traits du langage Ada  Pour moi, l’avantage principal du langage est sa très grande richesse et précision au niveau sémantique. Pour Ada, rien n’est implicite : tout doit être explicité par le programmeur et de ce fait, on ne laisse pas le compilateur choisir la meilleure solution pour une configuration donnée. Le programmeur doit donc être conscient des conséquences de tous ses choix et décisions. Et ceci est naturellement important pour les systèmes embarqués dans un contexte de contrôle.

Ensuite ?

Reprenons les problématiques de conversion : la plupart du temps, les programmeurs vont prendre des flottants ou des nombres réels, qui sont en fait des approximations. En Ada, il est possible de fixer la précision des calculs et de connaitre celle du résultat : il n’y a rien d’implicite et ceci assure la portabilité en particulier.

Quels sont les autres langages existant ?

Un autre langage de description de l’architecture, AADL, est très prometteur. C’est un standard proposé par la SAE (Society of Automotive Engineers) et qui propose un langage pour la description des  aspects architecture matérielle  et logicielle. Il y a de ce fait une proximité entre le logiciel et le matériel et la possibilité de procéder à des vérifications comme l’utilisation de la mémoire, le temps de calcul, le respect des échéances pour le temps réel (en utilisant des outils ad’hoc).  Leur site (http://www.aadl.info/) précise le contexte d’utilisations et d’applications d’AADL dans de nombreux domaines.

Pourquoi est-il important d’avoir le plus d’informations possibles sur l’architecture des systèmes ?

Le coût d’une erreur détectée en amont est très faible. Au niveau opérationnel, une erreur devient catastrophique. L’idée de ces langages est donc d’apporter le maximum d’informations sur l’architecture du système que l’on est en train de bâtir, et sur l’environnement hardware sur lequel il va tourner, pour mener à bien ensuite toute une phase d’analyses. … et de détecter ainsi au plus tôt toute erreur ou imprécision.