Skip to content

Introduction au Développement de logiciels critiques

A l’issue de la présentation technique de Jean-Pierre ROSEN, expert en langage Ada, les enseignements de base pour développer un logiciel critique ont été tirés :

Qu’est-ce qu’un logiciel critique ?

Un logiciel est qualifié de « critique » si une panne peut avoir des conséquences graves (mort, accident, dégâts matériels, humains, financiers  ou environnementaux graves).  Les logiciels critiques sont présents dans de nombreux domaines comme l’aviation, le ferroviaire, l’automobile, le nucléaire, le médical et bien d’autres secteurs encore.

Compte tenu des conséquences possibles d’un défaut, les méthodes utilisées dans d’autres domaines qui acceptent un certain taux d’erreur ne sont pas acceptables. C’est pourquoi des standards, des processus, et des méthodes spécifiques aux logiciels critiques ont été développés.

Attention : les contraintes portent sur la sécurité (safety en anglais), et ne doivent pas être confondues avec celles portant sur la sûreté, c’est-à-dire qui concernent la résistance à des attaques malveillantes (security en anglais).

Selon les cas, les exigences en matière de sécurité s’appuieront soit sur le seul risque, soit sur un risque pondéré par sa probabilité, selon ce que l’on appelle une matrice de criticité.

Les fondamentaux du développement d’un logiciel critique

Deux aspects sont fondamentaux pour s’assurer qu’un logiciel exécute correctement la fonctionnalité demandée : d’abord,  s’assurer que l’intention est correcte en définissant clairement les exigences et en les vérifiant selon un processus rigoureux. Ensuite, il faut s’assurer que le code corresponde bien avec l’intention. Ceci demande d’assurer la traçabilité entre le code et la conception, de s’assurer de la lisibilité et de la compréhensibilité du développement , de tester le logiciel par rapport aux exigences, et d’utiliser les outils (vérifications, preuves) fournis par le langage.

Comme pour des véhicules, les mesures de sécurité se répartissent en deux classes :

  • La sécurité active qui permet de prévenir l’accident (typage fort, vérifications et preuves du programme).
  • La sécurité passive qui permet de minimiser les conséquences de l’accident (programmation défensive, traitement d’exceptions, mode dégradé).

Standards et certification

Plusieurs normes portant sur les logiciels critiques ont été mises en place selon le domaine d’application. La plus ancienne concerne les logiciels « aviation », et a servi de base aux autres normes : la fameuse DO-178B/ ED-12B, DO-178C. Dans le domaine ferroviaire, c’est la norme EN-50128 qui s’applique. D’autres standards sont  applicables pour l’automobile, les systèmes militaires et spatiaux, le nucléaire et le médical. Les différentes normes imposent des contraintes différentes pour tenir compte des différences dans les domaines d’application, mais toutes concernent principalement les processus à mettre en œuvre.

Il ne suffit pas que le logiciel soit correct. Il faut être capable de prouver que le logiciel est correct. Tout logiciel critique doit se faire certifier (exigence légale) et le certificateur doit être une organisation indépendante. Le bon déroulement de la certification est la responsabilité de l’équipe de sécurité, qui est, elle, interne à la société conceptrice du logiciel.

L’indépendance doit être garantie entre la conception et le développement du logiciel critique. Elle est également requise entre la vérification et les tests afin de repérer toute faille pouvant porter atteinte à la sécurité du logiciel.

En outre, le certificateur doit avoir l’autorité d’arrêter le projet. Quant aux hauts degrés de criticité, le certificateur ne doit pas dépendre hiérarchiquement du chef de projet.

Tests, et au-delà

Bien entendu, les logiciels doivent être testés. Les tests sont fondés sur les exigences : toute exigence doit être testée, mais réciproquement tout test doit correspondre à une exigence. Selon le niveau de criticité, diverses formes de tests de couverture sont exigés : couverture d’instructions, couverture de décisions, couverture de conditions, MC/DC (Modified Condition/Decision Coverage). Plus la couverture est exigeante, plus le nombre de tests requis (et donc le coût) augmente.

Mais si les tests permettent de montrer que le logiciel fonctionne dans certains cas, ils ne peuvent garantir l’absence de défauts dans tous les cas. L’étape suivante qui se développe actuellement est l’utilisation de techniques de preuve de programme au moyen de langages formels.

Pour en savoir plus, rendez-vous sur :

Nous vous proposons des solutions autour du système d’information, système expert, embarqué et édition de logiciels,  nous permettant de répondre à la plupart des exigences du marché. 

Verified by MonsterInsights