Systèmes embarqués : gérer la criticité

Le développement des systèmes embarqués, dont les domaines d'applications, d'abord limités à l'aérospatiale et à l'aviation, se sont étendus à des domaines grand public (téléphonie, jeux vidéos), implique la prise en compte de contraintes diverses et hétérogènes.

Un système critique est un système dont une panne peut avoir des conséquences dramatiques, tels des morts ou des blessés graves, des dommages matériels importants, ou des conséquences graves pour l’environnement. Par opposé, un système non critique va correspondre aux applications dédiées aux loisirs (les jeux vidéos par exemple). Ainsi, sont par exemple critiques les logiciels intervenant dans :

les systèmes de transport : pilotage des avions, des trains, logiciels embarqués automobiles ;
la production d’énergie : contrôle des centrales nucléaires ;
la santé : chaînes de production de médicaments, appareil médicaux (à rayonnement ou contrôle de dosages) ;
le système financier : paiement électronique ;
les applications militaires.

En fait, de part la diffusion inexorable et généralisée des technologies logicielles et donc de l’impact plus massif d’un défaut quelconque, la notion de criticité tend à se diffuser même s’il s’agit plus souvent d’un risque de désorganisation sur le plan économique, social ou financier.

Bien évaluer le niveau de criticité

Il existe différents niveaux de criticité d’un système, suivant l’impact possible des dysfonctionnements. On apprécie ainsi différemment, par exemple, un dysfonctionnement provoquant des pertes coûteuses, mais sans mort d’homme (cas des missions spatiales non habitées) et un dysfonctionnement provoquant des morts dans le grand public (cas des vols commerciaux). De même, on apprécie différemment des dysfonctionnements faisant courir un danger de mort ou de blessure à des humains, ou des dysfonctionnement augmentant la charge de travail et les risques d’erreur de pilotage des opérateurs humains.

Prenons l’exemple de l’aviation. En aviation, la norme DO-178B sépare les logiciels avioniques en 5 catégories :

niveau A : un dysfonctionnement du logiciel provoquerait ou contribuerait à une condition de perte catastrophique de l’appareil ;
niveau B : un dysfonctionnement du logiciel provoquerait ou contribuerait à une condition dangereuse ou un dysfonctionnement sévère et majeur de l’appareil ;
niveau C : un dysfonctionnement du logiciel provoquerait ou contribuerait à un dysfonctionnement majeur de l’appareil ;
niveau D : un dysfonctionnement du logiciel provoquerait ou contribuerait à un dysfonctionnement mineur de l’appareil ;
niveau E : aucun impact sur le fonctionnement de l’appareil ou la charge de travail du pilote.

La criticité du système définit un niveau d’exigence par rapport à la tolérance aux pannes. Elle aura des conséquences sur l’évaluation des niveaux d’assurance pour la sécurité.

Un autre aspect de la criticité s’applique aux logiciels : un logiciel critique est un logiciel dont le mauvais fonctionnement aurait un impact important sur la sécurité ou la vie des personnes, des entreprises ou des biens. L’ingénierie logicielle pour les systèmes critiques est particulièrement difficile, dès lors que les systèmes sont complexes, mais l’industrie aéronautique, ou plus généralement l’industrie du transport de passagers, a réussi à définir des méthodes pour réaliser des logiciels critiques. Des méthodes formelles peuvent servir à améliorer la qualité du logiciel des systèmes critiques. Le coût de réalisation d’un logiciel de « système critique » est beaucoup plus élevé que celui d’un logiciel ordinaire.

Des contraintes particulières de développement

Les précautions à prendre dans le développement d’un logiciel critique sont généralement fixées par une norme, et dépendent du domaine d’application et surtout de la criticité du logiciel. Généralement, on trouve des impératifs :

de documentation : tous les composants doivent être documentés, notamment dans l’interface qu’ils présentent aux autres composants ;
de traçabilité : le système doit répondre à chaque spécification, soit dans sa mise en œuvre, soit dans des spécifications intermédiaires (auquel il faudra aussi répondre) ; on doit donc avoir une chaîne complète de traçabilité entre les spécifications fonctionnelles et la mise en œuvre du système ;
de limitation des pratiques dangereuses : certaines techniques de programmations, sources possibles de problèmes, sont interdites, ou du moins leur usage doit être justifié par des raisons impératives (ex: allocation dynamique de mémoire, procédures récursives) ;
de test : on devra essayer le logiciel dans un grand nombre de configurations, qui couvrent tous les points et un maximum des chemins de fonctionnement du programme ;
d’utilisation d’outils de développement et de vérification eux-mêmes sûrs.

Les systèmes les plus critiques sont généralement soumis à des autorités de certification, qui vérifient que les impératifs prévus par la norme ont été remplis.
L’usage de méthodes formelles pourra, à l’avenir, être encouragé, voire imposé.