Comment les logiciels utilisés dans les systèmes critiques de vie ou de mort sont-ils testés?

Un avion, par exemple un site Web, est un système dans lequel toute défaillance de certains systèmes est totalement inacceptable, car des erreurs dans la surveillance du vol, par exemple, peuvent entraîner un dysfonctionnement du pilote automatique et une plongée. Évidemment, cela n’arrive pas, car les brillants ingénieurs de Boeing et d’Airbus vérifient le pilote automatique pour s’assurer qu’il ne décide pas soudainement qu’une plongée est une manœuvre parfaitement acceptable et sûre. Ou peut-être que l'ordinateur tombe en panne et que les pilotes du nouvel avion plus récent ne peuvent plus piloter l'avion. Bien entendu, diverses procédures de sécurité et redondances sont intégrées à ces systèmes pour éviter tout accident (du logiciel et de l'avion).

Cependant, d'un autre côté, il est tout à fait évident que les logiciels ne sont pas parfaits - les logiciels open source et les logiciels sources fermés plantent régulièrement, et seul le programme "Hello World" le plus simple n'échoue pas. Comment les ingénieurs qui conçoivent les systèmes logiciels dans les industries de l'aéronautique, de la médecine et dans d'autres industries décisives peuvent-ils tester leur logiciel pour qu'il échoue (et s'il échoue, au moins, échoue gracieusement)?

_{J'espère désespérément que vous n'allez pas tous y aller: "Oh, je travaille pour Boeing / Airbus / (une autre société) et ce n'est pas le cas! Amusez-vous lors de votre prochaine visite à l'hôpital / à l'aéroport."}

J'ai beaucoup travaillé dans les contrôles industriels. Il n'est pas nécessaire que ce soit dans une industrie aussi glorieuse que l'aérospatiale. Presque chaque machine industrielle a suffisamment d’énergie potentielle pour causer des blessures graves, voire mortelles. J'ai été autour quand les gens ont été blessés. Si vous passez le plus clair de votre temps à un bureau dans un bureau, vous seriez probablement surpris de voir à quel point la plupart des emplois en usine peuvent être dangereux (et l'ont certainement été jusqu'à récemment). Nous disposons maintenant de meilleures méthodes de sauvegarde des machines. Voici comment cela fonctionne dans la pratique (bien que cela varie d'une juridiction à l'autre):

Il existe des normes OSHA aux États-Unis et des directives similaires (généralement plus strictes) dans l'UE. Celles-ci commencent généralement par vous demander de faire une analyse du risque. Cela signifie que vous dressez une liste de tous les dangers et que vous les catégorisez ensuite, en tenant compte de la fréquence à laquelle une personne est exposée au risque, de la facilité avec laquelle vous évitez le risque (dépend de la vitesse, etc.) et est la sévérité du résultat (coupure, amputation, mort, etc.).

Une grande partie de l'analyse porte sur les risques de protection. Si vous installez une grande cage autour de votre machine et que vous la verrouillez, votre machine est considérée comme étant sûre si ses composants ne peuvent pas enfreindre le dispositif de protection. Si vous avez besoin d'un outil pour y accéder, il s'agit d'une tâche de maintenance, et les personnes chargées de la maintenance sont censées être formées pour travailler en toute sécurité sur une machine. Cependant, dans la réalité, la plupart des machines nécessitent une interaction régulière avec les opérateurs. Nous devons donc prévoir des portes d'accès dans le dispositif de protection, les barrières immatérielles, etc. Ces portes et barrières immatérielles doivent être surveillées et le risque de dangers auxquels l'opérateur est exposé est exposé. doit être désactivé de manière "fiable".

Sur la base de cette analyse, les risques sont classés dans différentes catégories. Une échelle de classification commune est celle des catégories 1 à 4 (basée sur la norme EN 954-1). En fonction de ces catégories, vous êtes légalement tenu de fournir un certain niveau de protection et de sécurité des machines.

La catégorie 4, par exemple, exige que:

Un seul défaut dans chacune de ces pièces ne provoque pas la perte de la fonction de sécurité.

Le seul défaut est détecté avec ou avant la demande suivante de la fonction de sécurité ou, si cela n’est pas possible, une accumulation de défauts peut ne pas entraîner la perte de la fonction de sécurité.

Cela peut être difficile à réaliser dans la pratique, mais est simplifié par la disponibilité de composants standard certifiés de la catégorie 4. Par exemple, un composant commun de ces systèmes est un relais de sécurité. Ce ne sont pas que des relais mécaniques:

• Ils sont conçus pour surveiller deux canaux d’entrée redondants. Ainsi, si vous avez un capteur qui détecte une défaillance (comme une porte de protection ouverte), il dispose généralement de deux contacts avec des circuits redondants. Le relais surveille les deux canaux et, si l'un des deux s'ouvre, il coupe l'alimentation de vos actionneurs, mais s'ils ne le font pas tous les deux en même temps, il entre en condition de panne et la machine ne peut pas être redémarrée tant qu'elle n'est pas réparée. .
• Le relais utilise également des impulsions électriques sur ces lignes et utilise ces signaux pour surveiller les fils croisés ou en court-circuit afin de détecter un défaut de câblage.
• Du côté de la sortie, il utilise un ensemble de circuits doubles pour piloter les bobines de sortie. Ainsi, si l’un passe à l'état "activé", l'autre doit empêcher la sortie d'être excitée. De plus, ceux-ci sont surveillés et si un défaut est détecté, cela empêche le fonctionnement. Les bobines elles-mêmes sont en fait des relais à double force, ce qui signifie des relais physiques redondants sur la sortie, tout en garantissant que les contacts de chaque relais sont physiquement reliés les uns aux autres, de sorte qu'un contact sur 4, par exemple, ne puisse pas être bloqué tout seul. Ceux-ci sont également surveillés.
• Il comprend également une entrée pour surveiller un contact auxiliaire normalement fermé de la charge que vous contrôlez. S'il désactive la sortie, il doit voir le contact normalement fermé engager ce qui signifie qu'il valide le fait que le contacteur du moteur a été désactivé, ou quoi que ce soit d'autre, avant qu'il ne soit autorisé à fonctionner à nouveau dans la condition d'activation.

Comme vous pouvez le constater, ce sont des appareils compliqués. Les coûts typiques sont compris entre 200 et 600 USD pour chaque relais de sécurité. De toute évidence, il y a un logiciel dans ces appareils. Pour que votre relais de sécurité soit certifié, vous devez généralement suivre un modèle comme celui-ci:

• Deux processeurs redondants, provenant généralement de fournisseurs différents, basés sur des conceptions différentes.
• Le code exécuté sur chaque processeur doit être développé par deux équipes travaillant dans des conditions isolées. Cela évite qu'un seul bogue logiciel ne soit un seul point d'échec.
• La sortie des deux processeurs doit concorder ou bien les défauts du relais de sécurité.

Une fois que vous avez conçu votre système de sécurité pour votre machine, en utilisant des composants de sécurité, vous devez faire réviser et estamper la conception par un ingénieur professionnel. Ensuite, vous construisez la machine. Puis le P.Eng. examinera la construction de la machine en s'assurant qu'elle a été construite à la conception. Ils le documenteront et effectueront des tests pour s’assurer que tout fonctionne comme prévu. Cela s'appelle un examen préalable au démarrage (RPP) et n'est pas effectué dans toutes les juridictions. Une fois le PSR passé, vous avez le droit de faire exécuter la machine par un opérateur.

Ces dernières années, les systèmes de sécurité ont connu des révolutions. Pendant un moment, personne n’ayant confiance en la transmission de données de sécurité sur un réseau, les systèmes d ’« E / S distribués »tels que DeviceNET et EtherCAT n’étaient pas autorisés dans la partie sécurité du système. Cependant, les protocoles récents permettent désormais aux dispositifs de sécurité de fonctionner sur ces réseaux industriels. Les protocoles utilisent des messages horodatés et un double traitement redondant aux deux extrémités de la connexion.

Les relais de sécurité empruntent lentement le chemin du dodo bird, remplacés par des automates de sécurité plus complexes, qui constituent un moyen de construire la logique de sécurité dans un langage de diagramme de blocs fonctionnels. Encore une fois, ces automates de sécurité utilisent tout ce qui est redondant. Lorsque le programme est approuvé, avant que la machine ne soit mise en service, le P.Eng. marque le programme et le programme / automate est verrouillé par un mot de passe. Il faut également un hachage du programme et ce hachage est enregistré dans la documentation (c’est ce que le P.Eng. Est en train de presser).

Maintenant, une fois que vous avez conçu votre système de sécurité, la logique que vous écrivez pour contrôler la machine elle-même peut s'avérer très compliquée. Les programmeurs plantent fréquemment des machines causant des milliers de dollars de dégâts, mais au moins, personne ne sera blessé.

Il y a un mouvement sérieux vers la vérification formelle plutôt que les tests fonctionnels aléatoires.

Des agences gouvernementales telles que la NASA et certaines organisations de défense dépensent de plus en plus pour ces technologies.

Ils sont toujours un PITA pour le programmeur moyen, mais ils sont souvent plus efficaces pour tester des systèmes critiques.

Il existe également une tendance à expérimenter davantage de techniques académiques, telles que la validation de code multithread.

Cela dépend de ce que le logiciel est. Par exemple, dans les avions, il existe généralement un traitement à double redondance pour les systèmes critiques; dans le cas extrême, 2 conceptions matérielles différentes peuvent être utilisées, ainsi que deux pièces de s / w développées indépendamment, une pour chacune. Ils se calculent et se recoupent. Ce n'est pas infaillible et coûte extrêmement cher.

Une série de tests est effectuée pour tester des systèmes d'aéronefs. Les tests relatifs aux systèmes de vol prennent des mois et, si vous apportez des modifications, vous devez effectuer toute une série de tests supplémentaires. Cela se fait généralement dans un simulateur, qui peut en fait être rempli de pièces d'aéronefs réelles (par exemple, un poste de pilotage) avec, par exemple, un moteur simulé ou similaire. Comme vous pouvez l’imaginer, c’est également extrêmement coûteux à construire. Les modifications sont évaluées par rapport à un programme de test formel, puis exécutées dans un avion réel en vol de test. Au fil du temps, des tests tels que "des tests de fonctionnalité perturbée" sont exécutés. C'est là que l'élément modifié est autorisé à fonctionner normalement et que tout est vérifié / testé pour vérifier qu'il n'y a pas d'effet délétère. Cela coûte aussi beaucoup d’argent et peut prendre des semaines.

Je connais un exemple où un changement très simple d'un système de vol était nécessaire - si simple que vous seriez abasourdi par la mineure. Cependant, le nouveau test aurait pris plus de 3 mois et aurait coûté environ un million de dollars.

Dans le domaine médical, toute une série d'obstacles réglementaires à franchir concernent non seulement les tests, mais également les processus de développement et la documentation.

Tous ces champs constituent une avancée considérable par rapport à un endroit qui contient un peu de code PHP pour un site Web. C'est lent, laborieux, difficile, ennuyeux, fastidieux, méticuleux et très coûteux. Prenez vos coûts de développement / test normaux et multipliez-les par environ 100 et vous vous rapprochez de la barre.

Pour le logiciel de navette spatiale de la NASA, lisez Ils écrivent les bonnes choses . Pour la FDA (US Food and Drug Administration), lisez ceci:

Puisque vous avez déjà suffisamment de réponses intéressantes et instructives, voici ce que je pense.

C'est simple: le premier test est toujours effectué sur les programmeurs eux-mêmes. Il a tendance à limiter le nombre de bogues et garantit que seuls les programmeurs de qualité restent sur la liste de paie.

Les logiciels critiques ne sont pas testés selon une norme autre que celle "cela semble fonctionner" , comme c'est le cas partout.

Tous les investissements sont consacrés soit à ce qui semblait fonctionner auparavant, soit à des projets permettant aux non-programmeurs de produire de meilleurs logiciels.

ps Pas de commentaires sur le premier -1, mais je serais heureux de prendre -1pour chaque référence qui contredit ma déclaration.

Puis-je prendre un +1 pour chaque référence que je trouve à des logiciels critiques mal conçus ou testés? Simson Garfinkel documente dix cas dans un article sur WIRED.

Il n'y a pas une seule réponse pour tous les cas. Il appartient au fabricant individuel de décider comment concevoir et tester son logiciel. Mais tout le processus de développement logiciel doit être conforme aux spécifications formelles.

Par exemple, lors de la création d'un logiciel pour les dispositifs médicaux, vous devez suivre la norme IEC 62304 pour les logiciels pour les dispositifs médicaux. (Malheureusement, je ne peux que créer un lien vers wikipedia car ce n’est pas gratuit). Presque tous les pays du monde exigent le respect de cette norme.

La sévérité de ces exigences dépend du risque de préjudice. Par exemple, un dispositif de réanimation aurait le plus grand risque de préjudice (certain décès en cas de défaillance du système), alors qu'un système fonctionnant avec des diagnostics de maladie aurait un risque plus faible (décès possible si une maladie terminale n'était pas diagnostiquée correctement en cas de défaillance du système).

Mais ce que cela dit fondamentalement, c'est qu'il doit y avoir une traçabilité des exigences au logiciel. Vous devez effectuer des vérifications de l’unité logicielle. Cela ne précise pas ce qu'est la vérification. Peut être des tests unitaires, peut être une révision de code. Pour les périphériques à risque plus élevé, vous devez examiner manuellement les interfaces entre les unités logicielles (pour autant que je comprenne et me souvienne). Et bien sûr beaucoup d'autres règles. Oh, et vous devez écrire beaucoup de documentation pour documenter votre travail.

La norme n'interdit pas le développement agile, bien que, lors de sa lecture, il semble avoir été écrit en pensant au développement en cascade.

Je ne connais pas d'autres domaines du développement de logiciels, tels que l'aviation, les trains, les voitures, etc. Mais je suppose qu'il existe d'autres directives officielles similaires.

De nombreuses techniques sont utilisées, notamment:

• conception formelle et / ou validation
• normes de codage strictes évitant une programmation sophistiquée telle que l'allocation dynamique de mémoire
• ingénieurs de qualité très exigeants
• Les techniques d'analyse statique manys telles que la révision de code, les arbres de pannes, FMECA, ...

Mais la technique numéro un est:

• ESSAI

Le logiciel d'un vaisseau spatial nécessite plus d'efforts pour tester que pour concevoir et coder en premier lieu.

Les avions subissent plusieurs années d’essais en vol et sont soumis à des situations extrêmes. Ceci teste non seulement la structure physique mais également les logiciels.

Il y a un article "Perfect software" de Jack Ganssle sur EETimes du 03/01/2009 12:00 HNE. Quelques points à partir de là:

• "Théoriquement, le logiciel est le seul composant qui peut être parfait, et cela devrait toujours être notre point de départ." - C'est ce que dit Jesse Poore. En suivant sa page Web, vous découvrirez comment un logiciel parfait peut être fabriqué à un coût comparable à celui d’un logiciel normal.
• Il existe des fournisseurs industriels de systèmes d'exploitation hautement fiables. L'article mentionnait Mircrium et Green Hills. Après la page Web de Micrium, il y a une liste de normes pour les certifications. Ceux-ci doivent être les processus et les règles suivis par l'industrie. Ceci est basé sur une validation formelle, mais détourne beaucoup de la théorie.

Il est intéressant de noter qu'en ce qui concerne le logiciel commercial, les données recueillies par Capers Jones suggèrent que "le logiciel en général a une efficacité de suppression des défauts (pourcentage de bogues supprimés avant expédition) de 87%. Le micrologiciel obtient un score nettement supérieur de 94%". Pour moi, aucun d'entre eux n'est proche de la perfection. L'article mentionné précédemment par un répondeur indique que l'équipe de la navette spatiale de la NASA avait atteint un taux de suppression des bogues de 99%, mais que le coût est d'environ 35 millions de dollars par an pour environ 400 000 lignes de code.

Un article plus intéressant, "Logiciel pour des systèmes fiables", du même auteur, le 11/01/2009, semble plus pertinent. Cela peut se résumer comme ceci:

• En ce qui concerne le processus de développement, l’industrie a suivi les normes DO-178B ou IEC61508. Il met l'accent sur les tests avec la plus grande couverture. Mais peu de preuves peuvent être trouvées sur l'efficacité de cela.
• Une autorité de certification, le comité sur les systèmes logiciels pouvant être déclarés fiables, a publié un livre intitulé "Logiciel pour systèmes fiables - preuves suffisantes". C'est une bonne référence.
• Le livre demande essentiellement trois choses: [1] Établissez des règles explicites pour les tests de fiabilité. [2] Effectuez des tests contre les règles, mais assurez-vous également que les tests sont compréhensibles par les clients normaux ou les régulateurs avec moins de temps que les développeurs. [3] Assurez-vous que ce sont les experts en génie logiciel et que le domaine à problèmes se charge du développement et des tests.
• Le fournisseur de logiciel doit souscrire à une garantie ou à un autre recours en cas de défaillance du logiciel.
• Utilisez un langage sûr, en particulier pas C. SPARK est suggéré.
• L’approche «conception à contrat» est l’un des points forts de SPARK. La conception à contrat est une technologie importante pour intégrer des tests à chaque appel de fonction / méthode et l'exécuter toujours au moment de l'exécution. Plus qu'un simple assert () dans l'ancien temps, le contrat peut également intégrer des tests contre l'intention structurelle et garantir qu'aucune violation ne peut être insérée à une étape ultérieure du cycle de maintenance lorsque les développeurs d'origine sont généralement passés à d'autres projets. Il est évident que la conception pour contrat a produit des produits logiciels très fiables. SPARK et ses outils peuvent être utilisés pour aider à générer des cas de test de certification afin de simplifier le processus de certification.

D'après mes souvenirs, HP a pratiqué la conception à contrat il y a presque dix ans. Avec une petite équipe, 500 000 lignes de code, seuls 2 bogues ont été signalés après la livraison. Très impressionnant.

À mon avis, un logiciel fiable ou parfait ne peut être réalisé que si le coût n'est pas prohibitif. Cadres ou automatisations est un must-have.

Ils ont généralement un interverrouillage matériel utilisé comme sécurité intégrée.

Par exemple, les conceptions de boîte de texte diabolique standard pour les robots tueurs sont toujours fournies avec un kill-switch: P

Chaque secteur a son propre ensemble d'organismes de réglementation qui ont des exigences de test et de documentation pour le matériel et les logiciels liés à la sécurité. Considérez ce PDF de Underwriters Laboratory (UL) qui introduit la norme UL 1998: http://www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

Ce document fait référence à de nombreux autres documents connexes de UL, CSA et IEC.

En règle générale, les logiciels liés à la sécurité auront des circuits matériels redondants ou devront posséder d’autres fonctions de contrôle redondantes pour assurer un fonctionnement et des modes de défaillance sûrs.