FR3039908A1 - Systeme et procede pour technologie a base de modeles et processus pour la mise au point d'un logiciel essentiel pour la surete - Google Patents

Abstract

Un procédé pour la conception, à partir de modèles, d'un logiciel essentiel pour la sûreté, est présenté. Le procédé comporte la réception (132) d'exigences de logiciel en langage naturel, l'élaboration (133) d'un modèle de spécifications en mettant en œuvre une modélisation sémantique (150) ou une modélisation graphique (152), l'application d'une analyse formelle d'exigences au modèle de spécifications, la création automatisée de cas de tests de robustesse et reposant sur des exigences et de procédures à partir du modèle de spécifications, l'application de cas de tests au modèle de conception, la création automatisée d'un code source à l'aide du modèle de conception, la vérification du code source à l'aide de cas de tests et d'une technologie d'analyse statique; et la compilation d'un code objet exécutable à partir du code source vérifié ; un résultat de l'analyse des modèles de spécification ou de conception de logiciel n'est pas satisfaisant, l'ajustement du modèle de spécification ou de conception de logiciel afin de corriger toute incohérence, et la répétition de l'application de l'analyse et des cas de tests. Un système pour mettre en œuvre la conception à base de modèles et un support non transitoire exploitable par ordinateur sont présentés.

Description

Système et procédé pour technologie à base de modèles et processus pour la mise au point d’un logiciel essentiel pour la sûreté

La généralisation des équipements commandés par des microprocesseurs a abouti à des dispositifs dotés de toujours plus de capacités, mais donne un rôle plus crucial à la fiabilité du logiciel qui commande ces systèmes embarqués. De nombreux équipements potentiellement dangereux sont commandés par un logiciel embarqué (p.ex. des automobiles, des trains, des aéronefs, des raffineries de pétrole, des installations de traitement chimique, des centrales nucléaires, des dispositifs médicaux, etc.). Les solutions classiques pour vérifier qu'un code d'application opérationnelle convient pour ces dispositifs et systèmes sont délicates et manquent d'efficacité.

La mise au point de systèmes logiciels essentiels pour la sûreté répond à l'augmentation des dimensions et à la complexité de ces systèmes et s'inscrit dans la nécessité de préserver des fonctionnements essentiels pour la sûreté. Il existe toutes sortes de procédés, d'outils et d'environnements d'ingénierie logicielle pour élaborer des systèmes complexes, critiques. Par exemple, un procédé consiste à appliquer des techniques d'ingénierie dirigées par les modèles pour mettre au point des systèmes essentiels pour la sûreté.

Les solutions selon la technique antérieure peuvent comporter l'emploi d'outils d'environnement de développement intégré (EDI) pour effectuer une modélisation de spécifications de logiciels, une validation/vérification et une création et exécution de cas de tests. Ordinairement, ces outils utilisent des procédés rigoureux pour automatiser ou semi-automatiser une partie des étapes de conception détaillées tout en réduisant les besoins de saisie de données pour gagner du temps avec les étapes restantes. L'invention sera mieux comprise à l'étude détaillée de quelques modes de réalisation pris à titre d'exemples non limitatifs et illustrés par les dessins annexés sur lesquels : -la Figure 1 représente un système pour conception, à base de modèles, d'un logiciel essentiel pour la sûreté selon des formes de réalisation ; -la Figure 2 représente un organigramme d'un processus pour conception, à base de modèles, d'un logiciel essentiel pour la sûreté selon des formes de réalisation ; et -la Figure 3 représente un organigramme pour un processus de mise au point à base de modèles selon des formes de réalisation.

Selon des formes de réalisation de l'invention, des systèmes et des procédés présentent un processus de conception automatisé à base de modèles pour la mise au point et la création de tests d'un logiciel essentiel pour la sûreté. La mise en œuvre des systèmes et des procédés emploie une ontologie spécifique du domaine et des procédés de vérification formels pour améliorer et étendre des exigences de haut niveau. Ces systèmes et procédés utilisent un modèle de spécifications vérifiable (d'où l'expression “à base de modèles”) comme base pour la création automatisée de tests reposant sur les exigences avant l'écriture du logiciel. Selon des formes de réalisation, les tests reposant sur les exigences sont créés à partir du modèle de spécifications. Un modèle de conception sert à mettre au point le logiciel. La rigueur et l'automatisation de ces étapes ont pour effets une amélioration de la conception du logiciel et une réduction du travail de test, un gain de temps et des économies sur les coûts pour un concepteur de logiciels essentiels pour la sûreté.

En incluant des procédés formels et des modèles logiques dans les processus de mise en œuvre, on peut repérer des erreurs dans les exigences des spécifications et vérifier la cohérence et l'exhaustivité des exigences. Au moment où des erreurs dans les spécifications sont détectées, on peut y remédier, d'une manière itérative si nécessaire, jusqu'à ce qu'elles soient complètes d'un point de vue logique et cohérentes lors de la répétition du test. Les ontologies, les réseaux sémantiques et l'analyse de couverture apportent tous des informations explicites pour étendre des exigences qui sont incomplètes.

La mise en œuvre des systèmes et des procédés peut inclure des “situations de sûreté” dans les exigences et les étapes de vérification correspondantes (p.ex. la conception à base de modèles). Des relations temporelles complexes (p.ex. des exigences de concurrence et/ou des capacités) peuvent elles aussi être représentées.

Une fois que les exigences des spécifications d'un logiciel sont complètes et cohérentes, des modèles de conception et des tests ultérieurs de vérification/validation peuvent être créés pour tester le code source. Le code source peut être perçu comme une représentation plus détaillée de la conception spécifiée, ce qui donne un code objet et/ou exécutable qui met en œuvre les mêmes exigences de conception.

La mise en œuvre des systèmes et des procédés a pour effet une réduction des erreurs détectées pendant les opérations de vérification/validation. La mise en œuvre des systèmes et des procédés automatise ces processus, ce qui aboutit à un processus de conception/vérification/validation plus rigoureux permettant de réduire les coûts de main-d'œuvre et de temps de mise au point associés en assurant une plus grande précision dans le respect des exigences de conception et une plus grande vitesse lors des corrections et des tests en comparaison de la création manuelle classique de codes assistée par des outils.

La mise en œuvre des systèmes et des procédés à base de modèles substitue des formulations logiques formelles, mathématiquement rigoureuses définissant des exigences de fonctionnement, de conception et de création de tests, à des formulations à base de langage naturel, ce qui offre une occasion, au début du processus de conception, d'améliorer la qualité, la rigueur, la cohérence et la portée des exigences.

La Figure 1 représente un système 100 pour la mise au point d'un logiciel informatique essentiel pour la sûreté selon une forme de réalisation. Le système 100 peut comporter un ordinateur (soit un ordinateur unique 110 fonctionnant localement, soit plusieurs ordinateurs 112, 114, 11N en lien les uns avec les autres via un réseau de communications électroniques 120 (p.ex. l'Internet), une base de données associée 130 qui peut contenir des particularités du logiciel essentiel pour la sûreté - p.ex. des exigences du système affectées au logiciel (SRATS) 132, un modèle de spécifications de logiciel 133, un modèle de conception 134, un code source créé automatiquement 136, un code objet exécutable 138. Le système 100 peut aussi comporter une base de données 140 pouvant contenir des réseaux sémantiques 142, des ontologies 144, des cas de tests 146 reposant sur des exigences et des cas de tests de couverture 148 de modèles créés automatiquement. Bien que la base de données 130 et la base de données 140 soient représentées sous la forme de deux bases de données, dans certaines mises en œuvre une seule base de données peut contenir toutes les informations stockées ; dans d'autres mises en œuvre, le système 100 peut comporter plus de deux bases de données.

Selon une mise en œuvre, l'ordinateur unique 110 peut comprendre des unités de structure conçues pour effectuer des actions qui mettent en œuvre la conception de logiciel à base de modèles essentiel pour la sûreté. Ces unités peuvent comprendre une unité de modélisation sémantique 150, une unité de modélisation graphique 152, une unité de démonstration automatisée de théorème (ATP) 154, une unité de création de cas de tests et de procédures (ATCPG) 156 et une unité de création automatisée de code 158. Dans d'autres mises en œuvre, ces unités peuvent être réparties entre les différents ordinateurs en lien les uns avec les autres via le réseau de communications électroniques.

La Figure 2 représente un organigramme du processus 200 de conception de logiciel à base de modèles essentiel pour la sûreté selon des formes de réalisation. Le processus 200 analyse des SRATS en langage naturel, élabore un modèle de spécifications qui, après vérification et acceptation, constitue la base pour un modèle de conception. L'expression “modèle de conception” (au sens de la présente description) désigne un modèle conceptuel tel qu'un modèle objet ou un modèle en langage de modélisation unifié (UML). Un modèle de conception peut décrire les entités et les transformations fonctionnelles à réaliser par le logiciel d'application. A partir du modèle de conception, un premier code source peut être créé automatiquement par le processus 200, puis un code objet exécutable (EOC) peut également être créé. Le processus 200 peut vérifier la conception, le code source et l'EOC. L'EOC résultant de ce processus reposant sur des exigences peut ensuite être soumis à des procédés de test reposant sur l'EOC, lesquels peuvent fournir des informations supplémentaires.

Le modèle de spécifications est saisi, étape 205. La saisie peut comprendre la validation des SRATS des exigences du système en langage naturel fournies au système. L'unité de modélisation sémantique 150 et/ou l'unité de modélisation graphique 152 met/mettent en œuvre des techniques de modélisation sémantique et graphique pour élaborer un modèle de spécifications à partir des SRATS. Le modèle de spécifications est mis en œuvre dans un langage naturel structuré qui comprend un modèle sémantique et peut être consulté ou modifié sous une forme graphique.

Une analyse des exigences formelles sur le modèle de spécifications est effectuée, étape 210. L'unité d'ATP 154 peut analyser le modèle de spécifications et vérifier qu'il est juste et cohérent en mettant en œuvre des techniques de démonstration automatisée de théorèmes. Des cas de tests issus du modèle de spécifications sont créés automatiquement, étape 215, par l'unité d'ATCPG 156. Selon les formes de réalisation, le système peut employer l'ATCPG pour créer automatiquement des cas de tests pour les exigences du modèle de conception lui-même. Dans d'autres mises en œuvre les cas de tests créés automatiquement peuvent être créés automatiquement par le système 100 à l'aide d'un contrôle de modèle ou d'une autre technologie d'analyse formelle. Le processus 200 peut revenir à l'étape 205 pour saisir encore le modèle de spécifications si l'analyse d'exigences et/ou les cas de tests créés automatiquement indique(nt) que le modèle n'est pas aussi robuste que nécessaire (c'est-à-dire que le modèle de spécifications de logiciel est dépourvu de la cohérence, de la justesse et/ou de l'exhaustivité requise(s)).

Après que l'analyse d'exigences a indiqué que les exigences sont complètes et cohérentes, le modèle de spécifications constitue la base pour l'élaboration d'un modèle de conception de logiciel, étape 220. Les cas de tests sont créés à partir du modèle de spécifications et sont appliqués au modèle de conception. Après l'application des cas de tests au modèle de conception, la couverture du modèle est analysée, étape 225, d'après ses performances. Les éventuels défauts et incohérences sont corrigés, puis le modèle de conception peut être vérifié, étape 230, en répétant les scenarii des cas de tests.

Le modèle de conception vérifié sert à l'unité de création automatisée de code 158 à créer automatiquement, étape 235, un code source pour le logiciel essentiel pour la sûreté. Le système 100 vérifie ensuite, étape 240, le code source à l'aide d'une technologie d'analyse statique. Un code objet exécutable est compilé, étape 245, à partir du code source vérifié.

La Figure 3 représente un organigramme pour un processus d'élaboration 300 à base de modèles selon des formes de réalisation. Le système 100 pour la mise au point d'un logiciel informatique essentiel pour la sûreté peut comporter des applications 315, 320, 335, 340, 350, 360, 370 à mise en œuvre informatique qui reçoivent des informations de conception issues de stades 305, 310, 325, 330, 350, 355, 365 du processus d'élaboration 300 à base de modèles. Dans certaines mises en œuvre, les informations de conception reçues peuvent être complétées par des ordres et des instructions supplémentaires émanant d'utilisateurs humains du système 100. A partir des informations de conception reçues, traitées par les applications à mise en œuvre informatique du système 100, le processus 300 peut produire de nouveaux résultats - par exemple : confirmation d'exhaustivité, modèles de conception, nouveaux tests du logiciel et/ou messages identifiant des défauts qui précisent un inconvénient ou un manque d'exhaustivité des données de conception pour un stade particulier du processus de conception.

Si un message d'identification de défaut est produit, le processus 300 revient alors aux données de l'étape précédente (indiqué par une flèche bidirectionnelle reliant diverses étapes au sein du processus 300). Le défaut peut être corrigé par un utilisateur humain suivant une recommandation fournie par le processus 300 à mise en œuvre informatique.

Les données initiales de SRATS fournies au processus 300, étape 305, comprennent des documents en langage naturel. Le système 100 pour la mise au point d'un logiciel informatique essentiel pour la sûreté crée automatiquement le logiciel et crée automatiquement des cas de tests, ainsi que d'autres informations diagnostiques ou documents produits à des stades antérieurs. Ce logiciel, les cas de tests, les autres informations diagnostiques ou documents reposent sur les SRATS fournies. Le processus 300 mis en œuvre par le système 100 améliore la conception du logiciel essentiel pour la sûreté avec une diminution des interactions manuelles dans le processus de conception. Pour réaliser la mise au point automatisée, selon des formes de réalisation, le processus 300 comporte une validation d'applications à mise en œuvre informatique d'après un modèle client (étape 315), une analyse formelle des exigences (étape 320), une vérification formelle de la conception (étape 335), une analyse de la couverture du modèle (étape 340), une vérification du modèle de conception reposant sur des tests (étape 350), une vérification formelle du code (étape 360), une vérification d'EOC reposant sur des tests (étape 370).

Le processus 300 commence par la réception, étape 305, des documents SRATS en langage naturel à format textuel, dérivés d'exigences de niveau supérieur du système qui incluent les moyens matériels et logiciels. A partir des SRATS, un Modèle de Spécifications est élaboré, étape 310, à l'aide d'une combinaison de technologies de modélisation sémantique et de modélisation graphique. Selon des formes de réalisation, le système 100 mettant en œuvre le processus 300 a éliminé la nécessité de prendre comme texte des Exigences de Haut Niveau (HLR). Selon des formes de réalisation, les HLR classiques sont remplacées par un Modèle de Spécifications exploitable par des humains et des machines.

Le Modèle de Spécifications est validé, étape 315. La validation peut se faire à l'aide de représentations analytiques (p.ex. des ontologies et des réseaux sémantiques) des exigences présentées à un utilisateur. La justesse et la cohérence du Modèle de Spécifications font l'objet d’une analyse et d'une vérification formelles à l'aide d'applications d'ATP, étape 320. Cette étape peut identifier des erreurs dans les exigences au début du processus et réduire fortement les remaniements en fin de cycle.

Il existe une boucle de rétroaction entre l'analyse d'exigences 320 et la saisie de modèle de spécifications 310. Cette boucle de rétroaction réagit en temps réel pour alerter un technicien en cas d'erreur.

Après validation et analyse formelle des exigences, le Modèle de Spécifications devient une entrée pour créer, étape 330, un Modèle de conception. Le Modèle de Conception subit une vérification formelle à l'aide d'un contrôle de modèle, étape 335. Le Modèle de Spécifications sert également d'entrée dans le Processus de Création Automatisée de Cas de Tests Reposant sur les Exigences, étape 325. Des cas de tests et des procédures sont créés automatiquement (p.ex. à l'aide d'une technologie de contrôle de modèles). Les cas de tests sont ensuite appliqués, étape 350, au

Modèle de conception et une analyse établit s'ils sont bien fonctionnels.

Il existe une autre boucle de rétroaction entre la fonction 325 de création de cas de tests reposant sur les exigences et le modèle de spécifications 310 pour indiquer une mesure de complexité de vérification qui est proportionnelle au nombre de cas de tests nécessaires pour vérifier le modèle de spécifications. Le technicien procédant à la saisie des exigences peut se servir de cette information pour simplifier le modèle de spécifications afin de réduire le coût/la complexité de la vérification. Selon des mises en œuvre, l'outil de saisie d'exigences peut aussi présenter des suggestions d'options pour saisir les mêmes informations dans une grammaire qui serait plus facile à vérifier (moins de cas de tests).

Si des erreurs sont détectées, le modèle de conception est corrigé. Des défauts et des incohérences peuvent être détectés dans des circonstances où une suite d'étapes sont exécutées, ou si l'ordre d'étapes parallèles n'est pas prévisible : dans ces circonstances, des corrections peut être apportées au modèle de conception en reprenant les suites en sens inverse ou en effectuant une mise en ordre chronologique d'étapes par ailleurs non ordonnées. Ensuite, les cas de tests sont appliqués au Modèle de Conception et font l'objet d'une analyse de couverture du modèle (étape 340). Cette étape peut identifier des lacunes de couverture d'après (a) des erreurs dans les cas de tests reposant sur les exigences, le modèle de spécifications et/ou le modèle de conception (p.ex. une fonctionnalité involontaire, un code mort, etc.) ; ou (b) des exigences dérivées. Dans le cas d'exigences dérivées, des cas de tests sont automatiquement créés, étape 345, pour satisfaire la couverture du modèle.

Un outil de création automatisée de tests peut être utilisé pour aider un technicien à identifier un code inaccessible et pour identifier un vecteur de test qui exécutera la section spécifique du modèle. Un outil qualifié pour la création automatisée de codes est utilisé pour créer, étape 355, un code source à partir du modèle de conception. Le code source subit une analyse formelle, étape 360, à l'aide d'une technologie d'analyse statique. Le code source est compilé, étape 365, pour être transformé en EOC. La vérification de l'EOC reposant sur des tests est effectuée, étape 370, en réappliquant dans le processus la suite de tests élaborée antérieurement. Au terme de la vérification, l'EOC compilé peut alors subir des essais classiques d'unité, de sous-système et de système.

Les systèmes et procédés selon les formes de réalisation appliquent des techniques rigoureuses de modélisation mathématique et logique au problème de vérification de cohérence, de justesse et/ou d'exhaustivité d'exigences de logiciels avant la création d'un code. Selon des mises en œuvre, une collection d'outils peut couvrir tous les stades de conception préliminaire, d'analyse et de création d'un logiciel. La vérification préalable rend possibles le recours à la création automatisée de codes et l'utilisation de la rétroaction dans le processus de conception. La mise en œuvre des processus et des systèmes peut détecter des erreurs pendant les opérations de conception et d'études préliminaires. La correction de ces erreurs détectées peut étendre, améliorer, corriger et/ou compléter les informations de conception avant la création d'un code.

Selon certaines formes de réalisation, une application de programme informatique stockée dans une mémoire rémanente ou sur un support exploitable par ordinateur (p.ex. une mémoire à registres, une mémoire cache de processeur, une mémoire vive, une mémoire morte, un disque compact à mémoire à lecture seule, un disque dur, une mémoire flash, des supports magnétiques, etc.) peut comprendre un code ou des instructions exécutables qui, lorsqu'elles sont exécutées, peuvent demander à un contrôleur ou un processeur, ou amener un contrôleur ou un processeur, de/à exécuter des procédés présentés ici, tels qu'un procédé décrit plus haut pour la conception, d'après des modèles, d'un logiciel essentiel pour la sûreté.

Le support exploitable par ordinateur peut consister en supports de stockage non transitoire exploitables par ordinateur comprenant la totalité des formes et types de mémoire et tous les supports exploitables par ordinateur, à l'exception d'un signal transitoire à propagation. Dans une mise en œuvre, la mémoire rémanente ou le support non transitoire exploitable par ordinateur peut être une mémoire externe.

Liste des repères

NUMERO DESIGNATION 100 Système d'élaboration de logiciel informatique essentiel pour la sûreté 110 Ordinateur 112 Ordinateur 114 Ordinateur 11N Ordinateur 120 Réseau de communications électroniques 130 Base de données 132 Exigences du système affectées au logiciel 133 Modèle de spécifications du logiciel 134 Modèle de conception 136 Code source créé automatiquement 138 Code objet exécutable 140 Base de données 142 Réseaux sémantiques 144 Ontologies 146 Cas de tests reposant sur des exigences 148 Cas de tests de couverture du modèle créés automatiquement 150 Unité de modélisation sémantique 152 Unité de modélisation graphique 154 Unité de démonstration automatisée de théorèmes 156 Unité de création automatisée de cas de tests et de procédures 158 Unité de création automatisée de codes

Claims (9)

1. REVENDICATIONS

   1. Procédé pour la conception, à partir de modèles, d'un logiciel essentiel pour la sûreté, le procédé comportant : la réception (132) d'exigences de logiciel en langage naturel ; l'élaboration (133) d'un modèle de spécifications de logiciel dans un langage naturel structuré en mettant en œuvre une modélisation sémantique (150) et/ou une modélisation graphique (152) des exigences de logiciel en langage naturel ; l'application d'une analyse formelle d'exigences au modèle de spécifications de logiciel ; l'élaboration d'un modèle de conception de logiciel reposant sur le modèle de spécifications ; l'application, au modèle de conception de logiciel, de cas de tests de robustesse et reposant sur les exigences créées automatiquement ; la réalisation d'une analyse formelle du modèle de conception de logiciel ; la création automatisée (136) d'un code source à l'aide du modèle de conception de logiciel ; la vérification de la couverture et du comportement du code source par l'application de cas de tests créés automatiquement (148) et d'une technologie d'analyse statique ; la compilation d'un code objet exécutable à partir du code source vérifié ; et la vérification de la couverture et du comportement du code objet exécutable par l'application des cas de tests créés automatiquement.
2. 2. Procédé selon la revendication 1, comportant une unité de création automatisée de cas de tests et de procédures créant automatiquement les cas de tests à partir du modèle de spécifications de logiciel.
3. 3. Procédé selon la revendication 1, comportant une unité de démonstration automatisée de théorèmes mettant en œuvre des techniques de démonstration automatisée de théorèmes pour analyser et vérifier une cohérence et/ou une justesse et/ou une exhaustivité du modèle de spécification de logiciel.
4. 4. Procédé selon la revendication 1, comportant, si un résultat de l'analyse du modèle de spécifications de logiciel n'est pas satisfaisant, l'ajustement du modèle de spécifications de logiciel afin de corriger toute incohérence avec les exigences de logiciel en langage naturel.
5. 5. Procédé selon la revendication 4, comportant l'application de l'analyse d'exigences au module de spécifications de logiciel ajusté.
6. 6. Procédé selon la revendication 1, comportant une unité de création automatisée de cas de tests de robustesse et reposant sur des exigences, et de procédures créant automatiquement les cas de tests appliqués au modèle de conception de logiciel.
7. 7. Procédé selon la revendication 1, comportant l'utilisation d'une technologie de contrôle de modèle afin de créer les cas de tests de robustesse et reposant sur des exigences appliqués au modèle de conception de logiciel.
8. 8. Procédé selon la revendication 1, comportant, si un résultat de l'analyse du modèle de conception de logiciel n'est pas satisfaisant, l'ajustement du modèle de conception de logiciel afin de corriger toute incohérence avec le modèle de spécifications de logiciel.
9. 9. Procédé selon la revendication 8, comportant l'application des cas de tests au modèle de conception de logiciel ajusté.