FR2902205A1 - Dispositif et methode de verification de l'equivalence fonctionnelle entre une entite d'automates et un code de production - Google Patents

Abstract

L'invention concerne un dispositif et une méthode de vérification de l'équivalence fonctionnelle entre une entité d'automates (11) définissant un ensemble d'automates à états finis (13) et un code de production (15) représentant ladite entité d'automates (11) et généré à partir de ladite entité d'automates (11) par un générateur (17) de code de production, la méthode comportant les étapes suivantes :-générer un code de référence à partir de ladite entité d'automates (11) et représentant ladite entité par un générateur (21) de code référence différent dudit générateur (17) de code de production (15),-création dans un langage formel d'un code commun (35) comprenant lesdits codes de production et de référence, un producteur (37) de variables d'entrée (e1, e2) destiné à alimenter lesdits codes de production et de référence avec des variables d'entrées identiques, et une interface de sortie (39) destinée à fournir des variables de sorties (S1, S2) correspondantes,-définir dans un autre langage formel au moins une propriété (P) déterminée que ledit code commun doit satisfaire pour prouver l'équivalence fonctionnelle entre ladite entité d'automates (11) et ledit code de production (15),-rechercher par un moyen de preuve formelle (29) des valeurs prises par les variables de sorties (S1, S2) qui mettent en défaut ladite au moins une propriété (P) déterminée, et-valider l'équivalence fonctionnelle entre ladite entité d'automates (11) et le code de production (15) lorsque ladite au moins une propriété (P) déterminée est satisfaite.

Description

Titre de l'invention Dispositif et méthode de vérification de

l'équivalence fonctionnelle entre une entité d'automates et un code de production.

Domaine de l'invention La présente invention se rapporte au domaine des équipements de régulation ou de contrôle spécifiés par des automates à états finis et notamment aux équipements embarqués dans un véhicule ou aéronef. Plus particulièrement, l'invention concerne la vérification de l'équivalence fonctionnelle entre une entité d'automates définissant un ensemble d'automates à états finis et un code de production représentant ladite entité d'automates et généré à partir de cette entité par un générateur de code de production.

Art antérieur Dans de nombreuses industries, telles que l'automobile, l'aéronautique ou le spatial, on fait appel à des équipements de régulation embarqués. Une partie des étapes de régulation d'un équipement embarqué peut être spécifiée par une entité définissant un ensemble d'automates à états finis (appelés aussi Stateflow). Cet ensemble d'automates à états finis peut être implémentés en un code de production, par exemple en langage C. Actuellement, il n'existe pas de générateur de code qualifiable 25 pouvant produire directement du code de production avec une confiance suffisante pour des équipements critiques. Ainsi, pour le développement d'un système régi par un ensemble d'automates à états finis, on introduit des étapes de traduction manuelles intermédiaires et différentes selon les systèmes. Ces 30 traductions manuelles sont fastidieuses, longues et présentent des sources potentielles d'erreurs et ceci d'autant plus que les automates à états finis peuvent être très complexes. En effet, il est nécessaire qu'un opérateur humain réalise des contrôles techniques à l'issu de chacune des étapes de développement du système. Il est très probable que l'opérateur humain se trompe dans son interprétation des états et peut même omettre certaines erreurs bien réelles. Ainsi, le risque d'erreur de ces contrôles techniques est assez élevé et dépend de plusieurs paramètres tels que la complexité, la compréhension par l'opérateur chargé de ces contrôles et du temps passé à ces vérifications.

Objet et résumé de l'invention La présente invention a donc pour objet de résoudre les problèmes précités en proposant une méthode de vérification de l'équivalence fonctionnelle entre une entité d'automates définissant un ensemble d'automates à états finis et un code de production représentant ladite entité d'automates et généré à partir de ladite entité d'automates par un générateur de code de production, la méthode comporte les étapes suivantes : - générer un code de référence à partir de ladite entité d'automates et représentant ladite entité par un générateur de code référence différent dudit générateur de code de production, - création dans un langage formel d'un code commun comprenant lesdits codes de production et de référence, un producteur de variables d'entrée destiné à alimenter lesdits codes de production et de référence avec des variables d'entrées identiques, et une interface de sortie destinée à fournir des variables de sorties correspondantes, - définir dans un autre langage formel au moins une propriété déterminée que ledit code commun doit satisfaire pour prouver l'équivalence fonctionnelle entre ladite entité d'automates et ledit code de production, - rechercher par un moyen de preuve formelle des valeurs prises par les variables de sorties qui mettent en défaut ladite au moins une propriété déterminée, et - valider l'équivalence fonctionnelle entre ladite entité d'automates et le code de production lorsque ladite au moins une propriété déterminée est satisfaite.

Ainsi, on peut s'assurer de manière fiable, économique et reproductible à l'identique, que toute implémentation en code de production d'un ensemble d'automates à états finis (stateflow) est une traduction correcte (au sens mathématique du terme en s'appuyant sur une vérification automatisée) en toutes circonstances de celui-ci. Ainsi, en cas de validation, on s'assure qu'aucune erreur n'a été introduite lors de la transcription de l'ensemble d'automates à états finis en code de production. Avantageusement, le moyen de preuve formelle génère une trace représentative d'une différence de comportement entre le code de production et le code de référence lorsque ladite au moins une propriété déterminée n'est pas satisfaite. Ainsi, on peut conclure à la non-conformité du code de production avec ladite entité d'automates sachant qu'il est extrêmement improbable que deux générateurs de code différents ou indépendants reproduisent une même erreur au même endroit. En outre, la trace permet de localiser précisément l'écart de comportement entre le code de production et ladite entité d'automates et d'aider à la reprise ultérieure pour trouver la source de divergence. Avantageusement, lesdits générateurs de code de référence et 30 de code de production sont des générateurs synchrones indépendants.

Ainsi, la cohérence entre lesdits codes confirme avec un quasi certitude l'équivalence fonctionnelle entre ladite entité d'automates et le code de production censé le représenter. Selon un mode de réalisation, le moyen de preuve formelle compare des valeurs prises par les variables de sorties correspondantes auxdits codes de production et de référence pour vérifier une propriété d'inégalité entre lesdites valeurs de sorties de sorte que l'équivalence fonctionnelle entre ladite entité d'automates et le code de production est validée lorsque ladite propriété d'inégalité n'est jamais satisfaite.

Selon un autre mode de réalisation, le moyen de preuve formelle compare des valeurs prises par les variables de sorties correspondantes auxdits codes de production et de référence pour vérifier une propriété d'égalité entre lesdites valeurs de sorties de sorte que l'équivalence fonctionnelle entre ladite entité d'automates et le code de production est validée lorsque ladite propriété d'égalité est satisfaite. Selon une variante, ladite propriété d'égalité vérifie l'égalité entre chaque paire desdites variables de sorties. Selon une autre variante, ladite propriété d'égalité vérifie l'égalité des variables de sorties de manière séquentielle.

Lesdits codes de production et de référence peuvent être des codes en langage C de production et de référence respectivement. Selon une particularité, la génération dudit code de production est réalisée selon les étapes suivantes : -éditer un modèle intermédiaire représentant ladite entité d'automates, et 25 -transformer ledit modèle intermédiaire en ledit code de production par ledit générateur de code de production. Avantageusement, la validation de l'équivalence fonctionnelle entre ladite entité d'automates et le code de production est un moyen permettant de confirmer une équivalence entre le modèle intermédiaire et 30 le code de production.

Avantageusement, la validation de l'équivalence fonctionnelle entre ladite entité d'automates et le code de production est un moyen permettant de confirmer une équivalence entre le code de production et le code de référence.

Ledit moyen de preuve formelle peut être un vérificateur de modèle ( model-checker ) ou un outil de preuve de programme (prouveur de théorèmes theorem prover ). L'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de codes de programme pour l'exécution des étapes de la méthode de vérification selon au moins l'une des caractéristiques ci-dessus, lorsqu'il est exécuté sur un ordinateur ou un microprocesseur.

L'invention vise également un dispositif de vérification de l'équivalence fonctionnelle entre une entité d'automates définissant un ensemble d'automates à états finis et un code de production représentant ladite entité d'automates et généré à partir de ladite entité par un générateur de code de production, le dispositif comportant : -un générateur de code de référence pour générer un code de référence à partir de ladite entité d'automates et représentant ladite entité, ledit générateur de code de référence étant différent dudit générateur de code de production, -un moyen de création pour créer dans un langage formel un code commun comprenant lesdits codes de production et de référence, un producteur de variables d'entrée destiné à alimenter lesdits codes de production et de référence avec des variables d'entrées identiques, et une interface de sortie destinée à fournir des variables de sorties correspondantes, - un moyen de définition pour définir dans un autre langage formel au moins une propriété déterminée que ledit code commun doit satisfaire pour prouver l'équivalence fonctionnelle entre ladite entité d'automates et ledit code de production, -un moyen de preuve formelle pour rechercher des valeurs prises par les variables de sorties qui mettent en défaut ladite au moins une propriété déterminée, et - un moyen de validation pour valider l'équivalence fonctionnelle entre ladite entité d'automates et le code de production lorsque ladite au moins 10 une propriété déterminée est satisfaite.

Brève description des dessins D'autres particularités et avantages du dispositif et du procédé selon l'invention ressortiront mieux à la lecture de la description faite ci- 15 après, à titre indicatif mais non limitatif, en référence aux dessins annexés sur lesquels : - la figure 1 est une vue en perspective des moyens matériels mis en oeuvre dans le dispositif ou procédé de l'invention ; - la figure 2 illustre schématiquement le principe de vérification 20 de l'équivalence fonctionnelle entre une entité d'automates et un code de production censé représenter cette entité d'automates, selon l'invention ; - la figure 3 illustre schématiquement un dispositif de vérification de l'équivalence fonctionnelle selon le principe de la figure 2 ; - la figure 4 illustre schématiquement une trace sous forme de 25 chronogramme représentative d'une incohérence entre l'entité d'automates et le code de production, selon l'invention ; - la figure 5 illustre de manière schématique un mode de réalisation de la vérification de l'équivalence fonctionnelle entre l'entité d'automates et le code de production selon l'invention ; - la figure 6 illustre schématiquement un exemple de la génération du code de production selon l'invention ; et - la figure 7 illustre un fichier d'un code commun selon l'invention.

Description détaillée de modes de réalisation La figure 1 représente un système informatique qui peut être utilisé pour la vérification de l'équivalence fonctionnelle entre un ensemble d'automates à états finis et un code de production représentant cet ensemble. Ce système informatique comprend une station de travail ou ordinateur 1, utilisé pour l'exécution d'un programme informatique ou d'ordinateur conçu pour mettre en oeuvre le procédé selon l'invention. Le programme d'ordinateur peut être téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur et comprend des instructions de codes de programme pour l'exécution des étapes de la méthode de vérification selon l'invention, lorsqu'il est exécuté sur l'ordinateur ou un microprocesseur. L'ordinateur 1 comprend les moyens matériels que l'on trouve habituellement avec ce type d'appareil. Plus particulièrement, l'ordinateur comprend une unité centrale 2 qui exécute les séquences d'instructions du programme selon la méthode de l'invention, une mémoire centrale 3 qui stocke les données et programmes en cours d'exécution, des supports de stockages de données numériques (disque dur, CD 4, disquette,...) conservant durablement les données et les programmes manipulés, des périphériques d'entrée (clavier 5, souris 6, ...) ainsi que des périphériques de sortie (écran 7, imprimante,...) pour pouvoir visualiser le résultat de la vérification de l'équivalence fonctionnelle selon l'invention. Conformément à l'invention, la figure 2 illustre schématiquement le principe de vérification de l'équivalence fonctionnelle entre une spécification ou une entité d'automates 11 définissant un ensemble d'automates 13 à états finis et un code de production 15 (nommé code A) censé représenter cette entité d'automates 11. Le code de production 15 est généré à partir de l'entité d'automates 11 par un générateur 17 de code de production. De manière générale, l'entité d'automates 11 comporte des variables de type Booléen ou entiers pour modéliser un système physique qui peut par exemple être un système électronique chargé de supporter, après sa réalisation, une application donnée qui peut être le contrôle ou la commande des équipements de régulation d'un moteur ou d'une machine quelconque (non représentés). La présente invention propose de vérifier l'équivalence fonctionnelle (relation E1) entre l'entité d'automates 11 et le code de production 15 quelque soit la transformation utilisée pour produire le code de production 15 à partir de l'entité d'automates 11. Conformément à l'invention, on traduit la spécification ou entité d'automates 11 en un autre code (nommé code B) qui sert de référence (appelé dans la suite code de référence 19). En effet, ce code de référence 19 est généré par un générateur 21 de code de référence qui est différent du générateur 17 de code de production. En outre, on compare (relation E2) les deux codes A et B issus de ces deux générateurs 17 et 21 différents pour vérifier l'équivalence fonctionnelle E1 ou la non équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15 (code A).

Avantageusement, le générateur 21 de code de référence et le générateur 17 de code de production sont des générateurs synchrones complètement indépendants. On notera qu'il est extrêmement improbable que deux générateurs de code indépendants reproduisent une même erreur exactement au même endroit.

A titre d'exemple, le générateur 17 de code de production peut être un générateur automatique du type SCADE(TM), tandis que le générateur 21 de code de référence peut être un générateur automatique du type SILDEX(TM).

La figure 3 illustre de manière schématique un exemple d'un dispositif 23 de vérification de l'équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15. On notera que la figure 3 est également une illustration des principales étapes de la méthode de vérification selon l'invention.

Le dispositif 23 comprend un générateur 21 de code de référence, un moyen de création 25, un moyen de définition 27, un moyen de preuve formelle 29, un moyen de validation 31, et un moyen de d'invalidation 32. Le générateur 21 de code de référence génère le code de référence 19 (code B) à partir de l'entité d'automates 11. Ainsi, le code de référence 19 est également censé représenter l'entité d'automates 11. A titre d'exemple, les codes de production 15 et de référence 19 sont des codes en langage C de production et de référence respectivement. Bien entendu, ces codes de production 15 et de référence 19 peuvent être exprimés en un tout autre langage informatique. Le moyen de création 25 est destiné à créer dans un langage formel un harnais 33 comportant un code commun 35, un producteur de variables d'entrée 37 et une interface de sortie 39. On notera que le code commun 35 est un fichier qui comprend les codes de production 15 et de référence 19 ou codes A et B (représentés en pointillés à l'intérieur du code commun 35). Ainsi, l'harnais 33 permet d'alimenter les deux codes A et B compris dans le code commun 35 avec les mêmes entrées afin de comparer leurs sorties respectives.

En effet, le producteur de variables d'entrée 37 alimente les codes de production 15 et de référence 19 avec des variables d'entrées el et e2 identiques. On notera que le nombre de variable d'entrées identiques peut être un nombre quelconque. En outre, l'interface de sortie 39 est destinée à fournir des variables de sorties S1 et S2 correspondant aux variables d'entrées el et e2, le nombre de ces variables pouvant être quelconque. Par ailleurs, le moyen de définition 27 est destiné à définir dans un autre langage formel au moins une propriété P déterminée que le code commun 35 doit satisfaire pour prouver l'équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15. En effet, le moyen de preuve formelle 29 utilise des techniques mathématiques ou de logique formelle pour rechercher des valeurs prises par les variables de sorties S1 et S2 qui mettent en défaut la propriété P déterminée. On notera que pour vérifier cette propriété P déterminée, les valeurs prises par les variables de sorties S1 et S2 peuvent être regroupées par paires ou utilisées de manière séquentielle. De manière générale, une preuve formelle est une preuve par déduction formelle depuis des phrases initiales ou prémisses (supposées ou hypothèses) qui montre qu'une propriété déterminée (par exemple une phrase ou théorème donné) est valide. On notera que la déduction formelle concerne la dérivation d'une phrase exprimée dans une logique formelle à partir d'une ou de plusieurs autres phrases par l'application d'une ou de plusieurs règles d'inférence.

A titre d'exemple, le moyen de preuve formelle peut être un vérificateur de modèle ( model-checker ) ou un outil de preuve de programme (prouveur de théorèmes ou theorem prover en anglais). En particulier, on peut utiliser le model-checker lorsque les codes de production et de référence sont des codes en langage C et on peut utiliser un prouveur de théorèmes lorsque les codes de production et de référence sont des codes en langage du type Ada. En outre, le moyen de validation 31 qui est relié au moyen de preuve formelle 29 est destiné à valider V l'équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15 lorsque la propriété P déterminée est satisfaite. Bien entendu, afin d'affirmer que les deux codes sont équivalents en toutes circonstances, il est avantageux de ne pas faire abstraction sur les domaines de variation des variables d'entrées et de prendre alors en compte les plages de variation réelles de ces variables d'entrées. En revanche, lorsque la propriété P déterminée n'est pas satisfaite, un moyen d'invalidation 32 relié aussi au moyen de preuve formelle 29 invalide NV l'équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15. Avantageusement, le moyen d'invalidation 32 génère une trace 41 représentative d'une différence de comportement entre le code de production 15 et le code de référence 19. On notera que le moyen de validation 31 et le moyen d'invalidation 32 peuvent former un seul moyen qui génère une signature de comportement des codes de production 15 et de référence 19. A titre d'exemple, la figure 4 montre une trace 41 sous forme de chronogramme. Ce chronogramme indique précisément les variables de sortie S1 et S2 (ou signaux) impliquées et la valeur prise à chaque instant par chacune d'elle.

Cet exemple montre que la variable de sortie S1 prend les valeurs consécutives suivantes 2, 8, 9, 10 et 11 tandis que la variable de sortie S2 prend les valeurs consécutives suivantes 2, 8, 9, 10 et 12. Au quatrième instant, le chronogramme indique une différence de valeur entre les deux variables de sortie qui est représentative d'une différence de comportement entre les codes de production 15 et de référence 19.

Ainsi, en cas de détection d'une telle incohérence, la trace générée par le moyen de preuve formelle 29 permet de localiser rapidement et précisément l'écart de comportement entre le code de production 15 et le code de référence 19 qui est représentative d'une différence de comportement entre le code de production 15 et l'entité d'automates 11. De plus, la trace est particulièrement utile pour trouver une source de divergence et faciliter ainsi la reprise ultérieure de vérification. La figure 5 illustre de manière schématique un mode de 10 réalisation de la vérification de l'équivalence fonctionnelle entre l'entité d'automates et le code de production. Les mêmes entrées sont appliquées aux codes de production 15 et de référence 19 compris dans le code commun 35. Selon cet exemple, la variable d'entrée el lorsqu'elle est appliquée au code de production 15 15 (code A) est désignée par el(A) et lorsqu'elle est appliquée au code de référence 19 (code B) est désignée par el(B). Bien entendu, la valeur d'entrée el(A) est égale à la valeur d'entrée el(B). De même, les variables d'entrées e2(A) et e2(B) désignent l'application de la variable d'entrée e2 aux codes A et B respectivement. 20 Ensuite, les sorties correspondant aux entrées identiques sont comparées. Ainsi, les valeurs prises par les variables de sorties S1(A) et S1(B) (respectivement S2(A) et S2(B)) correspondant aux variables d'entrées el(A) et el(B) (respectivement e2(A) et e2(B)) sont comparées entre elles selon une propriété déterminée. Selon cet exemple, la propriété 25 déterminée est noté P1 pour les variables de sorties S1(A) et S1(B) et P2 pour les variables de sorties S2(A) et S2(B). Le résultat S(P1) de la comparaison entre les valeurs prises par les variables de sorties S1(A) et S1(B) est combiné avec le résultat S(P2) de la comparaison entre les valeurs prises par les variables de sorties 30 S2(A) et S2(B) selon un opérateur logique 43 (par exemple l'opérateur ET) afin de vérifier s'il existe au moins une paire de valeurs prises par les variables de sortie S1(A), S1(B) ou S2(A), S2(B) qui ne vérifie pas la propriété déterminée P1 ou P2. Selon une première variante, la propriété déterminée P1 ou P2 peut être une phrase en langage formel du type une inégalité jamais satisfaite . Selon une deuxième variante, la propriété déterminée P1 ou P2 peut être une phrase en langage formel du type égalité toujours satisfaite . Bien entendu, la propriété déterminée peut être une toute autre phrase en langage formel.

Ainsi, selon la première variante, le moyen de preuve formelle 29 compare les valeurs prises par les variables de sorties S1 et S2 (voir figure 3) correspondantes aux codes de production 15 et de référence 19 pour vérifier une propriété d'inégalité entre les valeurs de sorties de sorte que l'équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15 est validée lorsque la propriété d'inégalité n'est jamais satisfaite. Plus particulièrement, selon l'exemple de la figure 5, le résultat S(P1) de l'inégalité entre les valeurs prises par la paire de variables de sorties S1(A) et S1(B) ainsi que le résultat S(P2) de l'inégalité entre les valeurs prises par le paire de variables de sorties S2(A) et S2(B) sont combinés par l'opérateur logique 43 de type ET . L'état de sortie 45 de l'opérateur logique 43, permet de déterminer si l'inégalité est satisfaite ou n'est jamais satisfaite. Si la propriété n'est pas mise en défaut, c'est-à-dire si l'inégalité n'est jamais satisfaite, alors l'équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15 est validé V par le moyen de validation 31. En revanche, si la propriété est mise en défaut, c'est-à-dire si l'inégalité est satisfaite pour au moins une paire de variables de sorties, alors l'équivalence fonctionnelle entre le système d'automates et le code de production est invalidé NV par le moyen d'invalidation 32. De plus, la trace 41 des valeurs mettant en défaut la propriété est générée par le moyen d'invalidation 32. Selon la deuxième variante, le moyen de preuve formelle 29 compare des valeurs prises par les variables de sorties S1 et S2 correspondantes aux codes de production 15 et de référence 19 pour vérifier une propriété d'égalité entre ces valeurs de sorties de sorte que l'équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15 est validée lorsque la propriété d'égalité est satisfaite.

Ainsi, selon l'exemple de la figure 5, on peut vérifier l'égalité entre les valeurs prises par chaque paire de variables de sorties S1(A), S1(B) ou S2(A), S2(B). On notera qu'il est aussi envisageable de vérifier l'inégalité ou l'égalité des valeurs prises par les variables de sorties de manière 15 séquentielle. La figure 6 illustre de manière schématique un exemple de la génération du code de production 15. Selon cet exemple, on édite un modèle intermédiaire 51 représentant l'entité d'automates 11. En effet, on peut convertir l'entité 20 d'automates 11 en une représentation de type SSM(TM) Ensuite, on transforme le modèle intermédiaire (SSM(TM)) 51 en un code de production 15 par le générateur de code de production (par exemple un générateur SCADE(TM ) Par ailleurs, on transforme l'entité d'automates 11 en un code 25 de référence 19 par le générateur de code de référence (par exemple un générateur SILDEX(TM . Ensuite, on compare 53 les deux codes pour vérifier l'équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15. Avantageusement, la validation V de l'équivalence fonctionnelle 30 entre l'entité d'automates 11 et le code de production 15 permet de confirmer l'équivalence E3 entre le modèle intermédiaire 51 et le code de production 15. De même, la validation de l'équivalence fonctionnelle entre l'entité d'automates 11 et le code de production 15 permet de confirmer l'équivalence E4 entre le code de production 15 et le code de référence 19. Dans la suite, on donne un exemple d'un moyen de preuve ou vérification formelle du type model-checker utilisé pour comparer un code de production (code A) et un code de référence (code B).

Plus particulièrement, on utilise un outil ou logiciel de vérification formelle appelé Hybrid(TM) par exemple celui développé par la société allemande OFFIS dont l'analyseur est construit sur le principe du Model-Checking . Ce logiciel comporte une interface permettant l'expression et la 15 gestion des propriétés et paramètres de réglage. En outre, le logiciel comprend un model-checker appelé Vis(TM) Le logiciel Hybrid(TM) crée tout d'abord un code commun 35 (appelé fichier C commun), à partir des codes C de production et de référence que l'on lui fourni et le compile préalablement pour vérifier qu'il 20 ne contient pas d'erreurs. Le model-checker Vis(TM) va ensuite travailler à partir de ce fichier C commun. Par ailleurs, l'utilisateur est amené à spécifier deux types de propriétés : d'une part, les invariants qui complètent le code C et qui expriment des propriétés que le code doit toujours vérifier et d'autre part, 25 les propriétés que l'on souhaite vérifier sur ce code C. Une fois ces propriétés définies, le modelùchecker parcours exhaustivement un graphe de contrôle correspondant à la sémantique du programme C, cherchant à mettre en défaut la propriété testée en calculant si les états qui satisfont la propriété sont atteignables ou non.

L'analyse s'arrête soit parce que le logiciel a réussi à trouver un contre-exemple, soit parce que la sémantique a été entièrement parcourue et que l'on peut conclure à l'exactitude de la propriété vérifiée. On notera que le logiciel fournit le contre-exemple qu'il a trouvé.

Le temps de calcul pour une propriété dépend évidemment à la fois de la complexité de l'entité d'automates et du nombre de variables d'entrées nécessaires. On peut toutefois réduire le temps de calcul de manièresignificative en réduisant le champ à explorer pour les variables d'entrée mais en faisant néanmoins attention à ce que le domaine de variation spécifié ne devienne jamais inférieur à celui effectivement balayé dans le cas réel car sinon les propriétés ne seraient plus analysées sur l'ensemble des conditions réelles en exécution. A titre d'exemple, la figure 7 illustre un code commun ou fichier C commun (appelé fichier C.c) définissant le code c du programme global, qui comprend les programmes A et B (correspondant aux codes A et B) à vérifier et les connexions des variables d'entrée et de sortie (assignations). De plus ce fichier contient la description d'interface pour un noeud C (les entrées, les sorties et ainsi de suite) exigé par l'outil Hybrid(TM).

La structure de ce fichier (liste globale des entrées, sorties avec spécification externe, fonctions cO et C O) est importante pour Hybrid, tandis que les fonctions à l'intérieur sont totalement à la charge de l'utilisateur. Ce fichier fournit simplement des entrées identiques aux deux programmes A et B, puis on appelle la fonction correspondant au code à vérifier. Finalement, on copie les sorties de A et de B vers les sorties du noeud C pour faciliter l'accès à ces variables dans Hybrid(Tm)30

Claims (14)

REVENDICATIONS

1. Méthode de vérification de l'équivalence fonctionnelle entre une entité d'automates (11) définissant un ensemble d'automates à états finis (13) et un code de production (15) représentant ladite entité d'automates (11) et généré à partir de ladite entité d'automates (11) par un générateur (17) de code de production, caractérisée en ce qu'elle comporte les étapes suivantes : -générer un code de référence à partir de ladite entité d'automates (11) et représentant ladite entité par un générateur (21) de code référence différent dudit générateur (17) de code de production (15), - création dans un langage formel d'un code commun (35) comprenant lesdits codes de production et de référence, un producteur (37) de variables d'entrée (el, e2) destiné à alimenter lesdits codes de production et de référence avec des variables d'entrées identiques, et une interface de sortie (39) destinée à fournir des variables de sorties (S1, S2) correspondantes, - définir dans un autre langage formel au moins une propriété (P) déterminée que ledit code commun doit satisfaire pour prouver l'équivalence fonctionnelle entre ladite entité d'automates (11) et ledit code de production (15), - rechercher par un moyen de preuve formelle (29) des valeurs prises par les variables de sorties (S1, S2) qui mettent en défaut ladite au moins une 25 propriété (P) déterminée, et -valider l'équivalence fonctionnelle entre ladite entité d'automates (11) et le code de production (15) lorsque ladite au moins une propriété (P) déterminée est satisfaite.

2. Méthode selon la revendication 1, caractérisée en ce que le moyen de preuve formelle (29) génère une trace (41) représentative d'une différence de comportement entre le code de production (15) et le code de référence (17) lorsque ladite au moins une propriété déterminée n'est pas satisfaite.

3. Méthode selon l'une quelconque des revendications 1 et 2, caractérisée en ce que lesdits générateurs (17, 21) de code de référence et de code de production sont des générateurs synchrones indépendants.

4. Méthode selon l'une quelconque des revendications 1 à 3, caractérisée en ce que le moyen de preuve formelle (29) compare des valeurs prises par les variables de sorties (Si, S2) correspondantes auxdits codes de production (15) et de référence (19) pour vérifier une propriété d'inégalité entre lesdites valeurs de sorties de sorte que l'équivalence fonctionnelle entre ladite entité d'automates (11) et le code de production (15) est validée lorsque ladite propriété d'inégalité n'est jamais satisfaite.

5. Méthode selon l'une quelconque des revendications 1 à 3, caractérisée en ce que le moyen de preuve formelle (29) compare des valeurs prises par les variables de sorties (S1, S2) correspondantes auxdits codes de production (15) et de référence (19) pour vérifier une propriété d'égalité entre lesdites valeurs de sorties de sorte que l'équivalence fonctionnelle entre ladite entité d'automates (11) et le code de production (15) est validée lorsque ladite propriété d'égalité est satisfaite.

6. Méthode selon la revendication 5, caractérisée en ce que ladite propriété d'égalité vérifie l'égalité entre chaque paire desdites variables de sorties.30

7. Méthode selon la revendication 5, caractérisée en ce que ladite propriété d'égalité vérifie l'égalité des variables de sorties de manière séquentielle.

8. Méthode selon l'une quelconque des revendications 1 à 7, caractérisée en ce que lesdits codes de production (15) et de référence (19) sont des codes en langage C de production et de référence respectivement.

9. Méthode selon l'une quelconque des revendications 1 à 8, caractérisée 10 en ce que la génération dudit code de production (15) est réalisée selon les étapes suivantes : - éditer un modèle intermédiaire (51) représentant ladite entité d'automates (11), et - transformer ledit modèle intermédiaire (51) en ledit code de production 15 (15) par ledit générateur (17) de code de production.

10. Méthode selon la revendication 9, caractérisé en ce que la validation de l'équivalence fonctionnelle entre ladite entité d'automates (11) et le code de production (15) est un moyen permettant de confirmer une 20 équivalence ([3) entre le modèle intermédiaire (51) et le code de production (15).

11. Méthode selon l'une quelconque des revendications 1 à 10, caractérisé en ce que la validation de l'équivalence fonctionnelle entre ladite entité 25 d'automates (11) et le code de production (15) est un moyen permettant de confirmer une équivalence ([4) entre le code de production (15) et le code de référence (19).

12. Méthode selon l'une quelconque des revendications 1 à 11, caractérisé 30 en ce que ledit moyen de preuve formelle (29) est un vérificateur demodèle ( model-checker ) ou un outil de preuve de programme (prouveur de théorèmes theorem prouver ).

13. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de codes de programme pour l'exécution des étapes de la méthode de vérification selon au moins l'une des revendications 1 à 12, lorsqu'il est exécuté sur un ordinateur ou un microprocesseur.

14. Dispositif de vérification de l'équivalence fonctionnelle entre une entité d'automates (11) définissant un ensemble d'automates à états finis (13) et un code de production (15) représentant ladite entité d'automates (11) et généré à partir de ladite entité (11) par un générateur (17) de code de production, caractérisée en ce qu'il comporte : -un générateur (21) de code de référence pour générer un code de référence (19) à partir de ladite entité d'automates (11) et représentant ladite entité (11), ledit générateur (21) de code de référence (19) étant différent dudit générateur (17) de code de production (15), -un moyen de création (25) pour créer dans un langage formel un code commun (35) comprenant lesdits codes de production et de référence, un producteur (37) de variables d'entrée (el, e2) destiné à alimenter lesdits codes de production et de référence avec des variables d'entrées identiques, et une interface de sortie (39) destinée à fournir des variables de sorties (Si, S2) correspondantes, -un moyen de définition (27) pour définir dans un autre langage formel au moins une propriété (P) déterminée que ledit code commun (35) doit satisfaire pour prouver l'équivalence fonctionnelle entre ladite entité d'automates (11) et ledit code de production (15),- un moyen de preuve formelle (29) pour rechercher des valeurs prises par les variables de sorties qui mettent en défaut ladite au moins une propriété déterminée, et - un moyen de validation (31) pour valider l'équivalence fonctionnelle entre 5 ladite entité d'automates (11) et le code de production (15) lorsque ladite au moins une propriété (P) déterminée est satisfaite.