Contrairement aux microprocesseurs qui coordonnent un système en communiquant avec des puces mémoires et des périphériques d'entrées sorties externes, les microcontrôleurs sont des circuits intégrés qui rassemblent sur une même puce : le processeur, la mémoire (la ROM pour les programmes et la RAM pour les données des programmes) ainsi que divers périphériques et interfaces d'entrées sorties (broches GPIO, capteurs divers, diodes électroluminescentes, etc).

Il est à noter que la distinction entre microcontrôleur et system-on-chip (SoC) est avant tout une question de degré d'intégration. Les microcontrôleurs intègrent des processeurs fonctionnant à des fréquences réduites, avec quelques kilo ou méga-octets de mémoire, comparativement aux SoC qui eux possèdent plus de mémoire et des processeurs capables d'exécuter une distribution Linux complète, par exemple.

Nous allons aborder l'utilisation d'un microcontrôleur en environnement critique, en prenant un exemple d'application dans l'aéronautique : la gestion des interfaces d'entrées-sorties d'un IFE et de la communication de cet équipement avec le reste de l'avion.

L'IFE, équipement de loisir en environnement contraint

Le terme IFE (In-Flight Entertainment) désigne les écrans multimédia dédiés au loisir des passagers à bord des avions de ligne. Ce type d'appareil, déjà présenté dans un précédent article, est soumis à certaines contraintes issues de l'aéronautique.

En effet, bien que dédié au loisir, l'IFE doit être conforme à la norme DO-178 qui fixe les conditions de sécurité applicables aux logiciels critiques dans le domaine de l'aéronautique. Cette norme définit 5 niveaux de criticité allant de A à E. Plus le niveau est proche de A, et plus le nombre de critères à respecter est élevé.

De plus, le fait que cet équipement soit amené à communiquer avec d'autres systèmes à bord tel que le système d'annonces à destination des passagers (pour annoncer le décollage, l'atterrissage, les consignes de sécurité ou autres messages), entraîne des contraintes de compatibilité vis à vis des ces autres systèmes.

Toutes ces contraintes se traduisent par des certifications nécessaires à l'utilisation de l'IFE.

Certifier en DO-178 un environnement Linux embarqué complet (distribution et applicatifs) n'a aucun sens. Une solution retenue régulièrement consiste donc à déporter les fonctions critiques dans un sous-système (logiciel + processeur) dédié, de façon à pouvoir certifier ce sous-système indépendamment du reste de l'IFE. C'est au sein d'un tel sous-système qu'intervient le microcontrôleur.

Le microcontrôleur, un copilote à bord de l'IFE

Dans le cadre d'un système critique visant a être certifié, on peut donc concevoir notre microcontrôleur comme un processeur complémentaire au microprocesseur principal. Il est alors possible de faire exécuter au microcontrôleur un ensemble de tâches répondant aux contraintes de criticité au travers d'un programme enregistré dans sa mémoire interne.

Ce programme, désigné par le terme firmware, adresse les problématiques suivantes.

Quels sont les éléments de l'IFE que l'on peut piloter grâce au microcontrôleur et son firmware ?

Tout dépend du microcontrôleur en question. De manière générale, ils intègrent divers bus de données : I2C, SPI, I2S, USB, etc. Ces bus de données permettent de piloter des périphériques variés : diodes électroluminescentes, boutons, écrans (tactiles ou non), capteurs infrarouges, capteurs de températures, etc.

Sur un IFE, il n'est pas rare de retrouver une combinaison de plusieurs des bus et périphériques cités précédemment. Si l'on tient compte des contraintes liées au domaine de l'aéronautique, il devient particulièrement intéressant d'utiliser le microcontrôleur pour piloter les entrées-sorties de l'IFE.

Pourquoi déporter spécifiquement le contrôle  des entrées-sorties ?

Une des principales raisons pour utiliser le microcontrôleur comme processeur de contrôle des entrées-sorties est la criticité de l'environnement de l'IFE.

A bord de l'avion, compte tenu de la norme DO-178, il est primordial de maintenir un niveau de fonctionnement minimum pour certains services et équipements. Par exemple, le service d'annonce aux passagers qui permet à l'équipage de communiquer les consignes de sécurité et autres messages doit être fonctionnel à tout moment. Lors de la diffusion d'un message par le biais du service d'annonce, il faut donc que l'activité en cours sur un IFE puisse être préemptée de manière à communiquer le message au passager : étant donné la complexité de l'opération, le fait d'avoir un processeur dédié au contrôle des entrées-sorties permet plus facilement de certifier son bon fonctionnement.

Pour respecter les contraintes de criticité, lorsqu'il en reçoit l'ordre, le microcontrôleur prend donc le contrôle de l'écran pour avertir le passager du message en cours de diffusion et bloque le traitement des appuis sur les boutons.

A cela s'ajoute la possibilité, si le contrôle des entrées-sorties est déporté sur le microcontrôleur, de réaliser certaines opérations via ces entrées-sorties lorsque l'IFE présente une anomalie. En cas de dysfonctionnement, des boutons sont utilisés pour réinitialiser l'IFE et le remettre dans un état fonctionnel alors qu'un autre permet de faire appel à l'équipage pour demander assistance.

Comment se traduisent les contraintes de criticité au niveau du firmware ?

Le but premier de l'utilisation d'un microcontrôleur comme processeur dédié est de faciliter la certification du firmware embarqué en mémoire. Des contraintes s'imposent donc, conformément à la norme DO-178.

Comme évoqué précédemment, le nombre de critères à respecter dépend du niveau de criticité qui s'applique. D'une manière générale, on retrouve ces contraintes tout au long de la programmation du microcontrôleur, par exemple :

• lorsque la certification impose que le firmware soit le plus déterministe possible.

L'intérêt ici est de pouvoir garantir qu'une requête donnée sera toujours exécutée, quel que soit l'état courant de l'IFE. On peut alors faire appel à des techniques de programmation événementielle ou programmation par polling pour éviter l'utilisation des interruptions.

• lorsque la certification impose que certaines données soient persistantes tout au long du cycle de vie de l'IFE.

On peut alors programmer une partie de la mémoire interne du microcontrôleur pour être utilisée comme un support de stockage critique géré par ce dernier.

• lorsque les ressources mémoires sont limitées.

Cette limitation peut non seulement venir de la quantité de mémoire disponible au départ sur le microcontrôleur, mais aussi d'une contrainte de partage de cette mémoire comme cité dans le cas précédent. En général, on se limite alors à faire de l'allocation statique, et très peu voir pas du tout d'allocation dynamique.

Communiquer avec l'extérieur : USB versus GPIO

Il nous reste à aborder la question de la communication entre le microcontrôleur et, à la fois, l'IFE et les autres équipement à bord de l'avion. Pour la communication avec le processeur principal de l'IFE, le bus USB présente certains avantages par rapport à d'autres technologies :

• échange de données à des débits plus importants que d'autres types de bus
• source d'alimentation électrique disponible pour alimenter certains composants périphériques au microcontrôleur
• mise en œuvre coté processeur principal relativement simple, l'USB étant un standard bien établi

Le choix de cette interface impose cependant qu'un protocole de communication adapté soit programmé au sein du firmware.

En ce qui concerne la communication avec les autres équipements de bord, le recours aux broches GPIO permet de combler les besoins suivant :

• notifier l'IFE du changement de l'état d'un équipement de bord, par exemple pour signaler le début ou la fin d'une annonce à destination des passagers
• envoyer une notification à un équipement de bord, par exemple pour signaler au personnel de bord qu'un passager demande assistance

Les broches GPIO ont l'avantage d'être des interfaces simples qui ne nécessitent pas la mise en place d'un protocole spécifique pour être prises en charge.

Micro, seulement par le nom...

Du fait de leur conception relativement simple et de leur puissance de calcul faible, les microcontrôleurs sont souvent vus comme des processeurs limités.
Cette  conception simple facilite cependant la mise en place d'un système déterministe comme nous l'avons vu tout au long de l'article, et permet d'en faire un processeur spécialisé capable de couvrir des besoins et respecter des contraintes clairement identifiées, opération délicate à réaliser sur un processeur plus généraliste.