FR2902205A1

FR2902205A1 - DEVICE AND METHOD FOR VERIFYING FUNCTIONAL EQUIVALENCE BETWEEN AN ENTITY OF AUTOMATES AND A PRODUCTION CODE

Info

Publication number: FR2902205A1
Application number: FR0652106A
Authority: FR
Inventors: Philippe Baufreton
Original assignee: Societe dExplotation des Materiels Hispano Suiza; Hispano Suiza SA
Current assignee: Safran Transmission Systems SAS; Societe dExplotation des Materiels Hispano Suiza
Priority date: 2006-06-13
Filing date: 2006-06-13
Publication date: 2007-12-14
Anticipated expiration: 2026-06-13
Also published as: WO2007144537A3; WO2007144537A2; FR2902205B1

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.The invention relates to a device and a method for verifying the functional equivalence between an entity of automata (11) defining a set of finite state machines (13) and a production code (15) representing said entity of controllers (11) and generated from said automaton entity (11) by a generator (17) of production code, the method comprising the following steps: -generate a reference code from said automaton entity ( 11) and representing said entity by a reference code generator (21) different from said production code generator (17) (15), - creating in a formal language a common code (35) comprising said production and reference, a producer (37) of input variables (e1, e2) for supplying said production and reference codes with identical input variables, and an output interface (39) for providing output variables (S1, S2) corresponding, -define in another formal language at least one property (P) determined that said common code must satisfy to prove the functional equivalence between said automaton entity (11) and said production code (15), - search by formal proof means (29) of the values taken by the output variables (S1, S2) which defect said at least one determined property (P), and validate the functional equivalence between said automaton entity (11). ) and the production code (15) when said at least one determined property (P) is satisfied.

Description

Titre de l'invention Dispositif et méthode de vérification deTitle of the invention Device and method for verifying

l'équivalence fonctionnelle entre une entité d'automates et un code de production. the functional equivalence between a PLC entity and a production code.

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. FIELD OF THE INVENTION The present invention relates to the field of regulation or control equipment specified by finite state machines and in particular to equipment embedded in a vehicle or aircraft. More particularly, the invention relates to the verification of the functional equivalence between an entity of automata defining a set of finite state machines and a production code representing said entity of automata and generated from this entity by a generator of production code.

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. PRIOR ART In many industries, such as automotive, aeronautics or space, on-board control equipment is used. Some of the control steps of an on-board equipment may be specified by an entity defining a set of finite state machines (also called stateflow). This set of finite state machines can be implemented in a production code, for example in C language. Currently, there is no qualifiable code generator 25 that can directly produce production code with sufficient confidence for equipment. criticism. Thus, for the development of a system governed by a set of finite state machines, intermediate and different manual translation steps are introduced according to the systems. These manual translations are tedious, time consuming and have potential sources of error, especially since finite state machines can be very complex. Indeed, it is necessary for a human operator to carry out technical checks at the end of each stage of system development. It is very likely that the human operator is mistaken in his interpretation of states and may even omit some very real errors. Thus, the risk of error of these technical controls is quite high and depends on several parameters such as the complexity, the understanding by the operator responsible for these controls and the time spent on these checks.

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. OBJECT AND SUMMARY OF THE INVENTION The object of the present invention is therefore to solve the aforementioned problems by proposing a method for verifying the functional equivalence between an entity of automata defining a set of finite state machines and a production code. representing said automaton entity and generated from said automaton entity by a production code generator, the method comprises the following steps: generating a reference code from said automaton entity and representing said entity by a reference code generator different from said production code generator, - creating in a formal language a common code comprising said production and reference codes, an input variable producer for supplying said production and reference codes with identical input variables, and an output interface intended to provide corresponding outputs, - define in another formal language at least one determined property that said common code must satisfy to prove the functional equivalence between said automaton entity and said production code, - search by a formal means of proof of the values taken by the output variables which defeat said at least one determined property, and - validating the functional equivalence between said automaton entity and the production code when said at least one determined property is satisfied.

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. Thus, one can reliably, economically and reproducibly ensure that any production code implementation of a set of state-state machines is a correct translation (in the mathematical sense of the term). based on an automated verification) in all circumstances of it. Thus, in the case of validation, it is ensured that no error has been introduced during the transcription of the set of finite state machines in production code. Advantageously, the formal proof means generates a trace representative of a difference in behavior between the production code and the reference code when the said at least one determined property is not satisfied. Thus, it can be concluded that the production code does not comply with said automaton entity, since it is extremely unlikely that two different or independent code generators will reproduce the same error at the same location. In addition, the trace makes it possible to precisely locate the difference in behavior between the production code and said automaton entity and to help the subsequent recovery to find the source of divergence. Advantageously, said reference code generators and production code generators are independent synchronous generators.

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. Thus, the coherence between said codes confirms with almost complete certainty the functional equivalence between said automaton entity and the production code that is supposed to represent it. According to one embodiment, the formal proof means compares values taken by the corresponding output variables with said production and reference codes to verify a property of inequality between said output values so that the functional equivalence between said entity of automata and the production code is validated when said property of inequality is never satisfied.

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. According to another embodiment, the formal proof means compares values taken by the corresponding output variables with said production and reference codes to verify an equality property between said output values so that the functional equivalence between said automaton entity and the production code is validated when said equality property is satisfied. According to one variant, said equality property checks the equality between each pair of said output variables. According to another variant, said equality property checks the equality of the output variables sequentially.

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. Said production and reference codes may be codes in C language of production and reference respectively. According to a particular feature, the generation of said production code is performed according to the following steps: -editing an intermediate model representing said automaton entity, and -transforming said intermediate model into said production code by said production code generator. Advantageously, the validation of the functional equivalence between said automaton entity and the production code is a means for confirming an equivalence between the intermediate model and the production code.

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. Advantageously, the validation of the functional equivalence between said automaton entity and the production code is a means for confirming an equivalence between the production code and the reference code.

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. The said formal means of proof may be a model-checker or a program proofing tool (prover theorem prover). The invention also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the performing the steps of the verification method according to at least one of the above features, when executed on a computer or a microprocessor.

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. The invention also provides a device for verifying the functional equivalence between an entity of automata defining a set of finite state machines and a production code representing said automaton entity and generated from said entity by a generator. production code device, the device comprising: a reference code generator for generating a reference code from said automaton entity and representing said entity, said reference code generator being different from said production code generator, a creation means for creating in a formal language a common code comprising said production and reference codes, an input variable producer for supplying said production and reference codes with identical input variables, and a output interface for providing corresponding output variables, - a definition means for ur define in another formal language at least one determined property that said common code must satisfy to prove the functional equivalence between said automaton entity and said production code, -a formal means of proof to search for values taken by the variables outputs that fail said at least one determined property, and - a validation means for validating the functional equivalence between said automaton entity and the production code when said at least one particular property is satisfied.

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. BRIEF DESCRIPTION OF THE DRAWINGS Other features and advantages of the device and of the method according to the invention will emerge more clearly on reading the following description, given by way of non-limiting indication, with reference to the appended drawings in which: Figure 1 is a perspective view of the hardware means implemented in the device or method of the invention; FIG. 2 diagrammatically illustrates the principle of verifying the functional equivalence between an entity of automata and a production code intended to represent this entity of automata, according to the invention; FIG. 3 schematically illustrates a device for verifying the functional equivalence according to the principle of FIG. 2; FIG. 4 schematically illustrates a trace in the form of a chronogram representative of an inconsistency between the automaton entity and the production code, according to the invention; FIG. 5 schematically illustrates an embodiment of the verification of the functional equivalence between the automaton entity and the production code according to the invention; FIG. 6 schematically illustrates an example of the generation of the production code according to the invention; and FIG. 7 illustrates a file of a common code according to the 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). DETAILED DESCRIPTION OF EMBODIMENTS FIG. 1 represents a computer system that can be used to verify the functional equivalence between a set of finite state machines and a production code representing this set. This computer system comprises a work station or computer 1, used for the execution of a computer program or computer designed to implement the method according to the invention. The computer program may be downloadable from a communication network and / or stored on a computer readable and / or executable medium by a microprocessor and includes program code instructions for performing the steps of the verification method according to the invention, when executed on the computer or a microprocessor. The computer 1 comprises the material means that are usually found with this type of device. More particularly, the computer comprises a central unit 2 which executes the instruction sequences of the program according to the method of the invention, a central memory 3 which stores the data and programs running, data storage media digital (hard disk, CD 4, floppy disk, ...) sustainably preserve the data and programs handled, input devices (keyboard 5, mouse 6, ...) as well as output devices (screen 7, printer , ...) to be able to visualize the result of the check of the functional equivalence according to the invention. According to the invention, FIG. 2 diagrammatically illustrates the principle of verifying the functional equivalence between a specification or an entity of automata 11 defining a set of finite state machines 13 and a production code 15 (called code A The output code is generated from the controller entity 11 by a generator 17 of production code. In general, the automaton entity 11 comprises variables of Boolean or integer type for modeling a physical system which may for example be an electronic system responsible for supporting, after its implementation, a given application which may be the control or the control of the control equipment of an engine or any machine (not shown). The present invention proposes to check the functional equivalence (relation E1) between the automaton entity 11 and the production code 15 whatever the transformation used to produce the production code 15 from the automaton entity 11 According to the invention, the specification or entity of automata 11 is translated into another code (called code B) which serves as a reference (hereinafter referred to as reference code 19). Indeed, this reference code 19 is generated by a reference code generator 21 which is different from the generator 17 of production code. In addition, the two codes A and B from these two different generators 17 and 21 are compared (relation E2) to verify the functional equivalence E1 or the functional non-equivalence between the automaton entity 11 and the production code. (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. Advantageously, the reference code generator 21 and the production code generator 17 are completely independent synchronous generators. Note that it is highly unlikely that two independent code generators will reproduce the same error in exactly the same place.

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). By way of example, the production code generator 17 may be an automatic generator of the SCADE (TM) type, whereas the reference code generator 21 may be an automatic generator of the SILDEX (TM) type.

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. FIG. 3 schematically illustrates an example of a device 23 for verifying the functional equivalence between the entity of automata 11 and the production code 15. It will be noted that FIG. 3 is also an illustration of the main steps of FIG. the verification method according to the 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. The device 23 comprises a reference code generator 21, a creation means 25, a definition means 27, a formal proof means 29, a validation means 31, and an invalidation means 32. reference code generates the reference code 19 (code B) from the controller entity 11. Thus, the reference code 19 is also supposed to represent the controller entity 11. By way of example, the production and reference codes 19 are C language codes of production and reference respectively. Of course, these production and reference codes 19 can be expressed in a completely different computer language. The authoring means 25 is intended to create in a formal language a harness 33 having a common code 35, an input variable producer 37 and an output interface 39. It should be noted that the common code 35 is a file which comprises the production and reference codes 19 or codes A and B (shown in dashed lines within common code 35). Thus, the harness 33 makes it possible to feed the two codes A and B included in the common code 35 with the same inputs in order to compare their respective outputs.

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. Indeed, the producer of input variables 37 feeds the production and reference codes 19 with identical input variables e1 and e2. Note that the number of identical input variables can be any number. In addition, the output interface 39 is intended to provide output variables S1 and S2 corresponding to the input variables e1 and e2, the number of these variables being arbitrary. Moreover, the definition means 27 is intended to define in another formal language at least one determined property P that the common code must satisfy to prove the functional equivalence between the automaton entity 11 and the production code. Indeed, the formal proof means 29 uses mathematical or formal logic techniques to search for values taken by the output variables S1 and S2 which defect the determined property P. Note that to verify this property P determined, the values taken by the output variables S1 and S2 can be grouped in pairs or used sequentially. Generally, a formal proof is a proof by formal deduction from initial sentences or premises (assumptions or hypotheses) which shows that a given property (for example a given sentence or theorem) is valid. It will be noted that the formal deduction concerns the derivation of a sentence expressed in a formal logic from one or more other sentences by the application of one or more rules of inference.

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. For example, the formal means of proof may be a model-checker or a proof of theorem prover tool. In particular, the model-checker can be used when the production and reference codes are C-language codes and a theorem prover can be used when the production and reference codes are codes in Ada type language. In addition, the validation means 31 which is connected to the formal proof means 29 is intended to validate the functional equivalence between the automaton entity 11 and the production code when the determined property P is satisfied. Of course, in order to affirm that the two codes are equivalent in all circumstances, it is advantageous not to ignore the domains of variation of the input variables and then take into account the actual ranges of variation of these variables. entries. On the other hand, when the determined property P is not satisfied, an invalidating means 32 also connected to the formal proof means 29 invalidates NV the functional equivalence between the automaton entity 11 and the production code 15. Advantageously the invalidation means 32 generates a trace 41 representative of a difference in behavior between the production code 15 and the reference code 19. It will be noted that the validation means 31 and the invalidation means 32 can form a single means that generates a behavioral signature of the production and reference codes 19. By way of example, FIG. 4 shows a trace 41 in the form of a timing diagram. This timing diagram precisely indicates the output variables S1 and S2 (or signals) involved and the value taken at each moment by each of them.

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. This example shows that the output variable S1 takes the following consecutive values 2, 8, 9, 10 and 11 while the output variable S2 takes the following consecutive values 2, 8, 9, 10 and 12. At the fourth instant, the The timing diagram indicates a difference in value between the two output variables that is representative of a difference in behavior between the production and reference codes 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. Thus, in case of detection of such an inconsistency, the trace generated by the formal proof means 29 makes it possible to locate quickly and accurately the behavioral difference between the production code 15 and the reference code 19 which is representative of a difference in behavior between the production code 15 and the automaton entity 11. In addition, the trace is particularly useful for finding a source of divergence and thus facilitating the subsequent recovery of verification. Figure 5 schematically illustrates one embodiment of the verification of the functional equivalence between the automaton entity and the production code. The same entries are applied to the production and reference codes 19 included in the common code 35. According to this example, the input variable el when applied to the production code 15 (code A) is designated by el (A) and when applied to the reference code 19 (code B) is designated el (B). Of course, the input value el (A) is equal to the input value el (B). Likewise, the input variables e2 (A) and e2 (B) designate the application of the input variable e2 to the codes A and B respectively. Next, the outputs corresponding to the identical inputs are compared. Thus, the values taken by the output variables S1 (A) and S1 (B) (respectively S2 (A) and S2 (B)) corresponding to the input variables el (A) and el (B) (respectively e2 ( A) and e2 (B)) are compared with each other according to a given property. According to this example, the determined property is denoted P1 for the output variables S1 (A) and S1 (B) and P2 for the output variables S2 (A) and S2 (B). The result S (P1) of the comparison between the values taken by the output variables S1 (A) and S1 (B) is combined with the result S (P2) of the comparison between the values taken by the output variables 30 S2. (A) and S2 (B) according to a logical operator 43 (for example the AND operator) to check whether there is at least one pair of values taken by the output variables S1 (A), S1 (B) or S2 (A), S2 (B) which does not check the determined property P1 or P2. According to a first variant, the determined property P1 or P2 can be a sentence in formal language of the type an inequality never satisfied. According to a second variant, the determined property P1 or P2 may be a sentence in formal language of the equality type always satisfied. Of course, the determined property can be a completely different sentence in formal language.

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. Thus, according to the first variant, the formal proof means 29 compares the values taken by the output variables S1 and S2 (see FIG. 3) corresponding to the production and reference codes 19 to verify a property of inequality between the values of outputs so that the functional equivalence between the automaton entity 11 and the production code 15 is validated when the inequality property is never satisfied. More particularly, according to the example of FIG. 5, the result S (P1) of the inequality between the values taken by the pair of output variables S1 (A) and S1 (B) as well as the result S (P2). the inequality between the values taken by the pair of output variables S2 (A) and S2 (B) are combined by the AND-type logic operator 43. The output state 45 of the logic operator 43, makes it possible to determine whether the inequality is satisfied or never satisfied. If the property is not faulty, that is to say if the inequality is never satisfied, then the functional equivalence between the automaton entity 11 and the production code 15 is validated V 31. On the other hand, if the property is in default, that is, if the inequality is satisfied for at least one pair of output variables, then the functional equivalence between and the production code is invalidated NV by the invalidation means 32. In addition, the trace 41 of the values defaulling the property is generated by the invalidation means 32. According to the second variant, the means of proof formal 29 compares values taken by the output variables S1 and S2 corresponding to the production and reference codes 19 to verify an equality property between these output values so that the functional equivalence between the automaton entity 11 and the production code 1 5 is validated when the equality property is satisfied.

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). Thus, according to the example of FIG. 5, it is possible to check the equality between the values taken by each pair of output variables S1 (A), S1 (B) or S2 (A), S2 (B). It should be noted that it is also possible to check the inequality or the equality of the values taken by the output variables in a sequential manner. FIG. 6 schematically illustrates an example of the generation of the production code 15. According to this example, an intermediate model 51 representing the automaton entity 11 is edited. In fact, the automaton entity 20 can be converted. 11 in an SSM representation (TM) Then, the intermediate model (SSM (TM)) 51 is converted into a production code 15 by the production code generator (for example a SCADE (TM) generator. transforms the controller entity 11 into a reference code 19 by the reference code generator (for example, a SILDEX generator (TM) Then the two codes are compared to check the functional equivalence between the reference entity 11 and the production code 15. Advantageously, the validation V of the functional equivalence 30 between the automaton entity 11 and the production code 15 makes it possible to confirm the equivalence E3 between the intermediate model 51 and the code of producti 15. Similarly, the validation of the functional equivalence between the automaton entity 11 and the production code 15 confirms the equivalence E4 between the production code 15 and the reference code 19. In the following An example of a form of proof or formal check of the model-checker type used to compare a production code (code A) and a reference code (code B) is given.

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. More particularly, it uses a tool or formal verification software called Hybrid (TM) for example that developed by the German company OFFIS whose analyzer is built on the principle of Model-Checking. This software includes an interface allowing the expression and the management of properties and adjustment parameters. In addition, the software includes a model-checker called Vis (TM) The Hybrid (TM) software first creates a common code (called common C file), from the production and reference C codes that the it is supplied and compiled beforehand to check that it contains no errors. The model-checker Vis (TM) will then work from this common C file. Furthermore, the user is required to specify two types of properties: on the one hand, the invariants that complete the C code and that express properties that the code must always check, and on the other hand, the properties that the we want to check on this code C. Once these properties have been defined, the modelùchecker runs exhaustively a control graph corresponding to the semantics of the program C, seeking to fault the property tested by calculating whether the states that satisfy the property are reachable or no.

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é. The analysis stops either because the software has managed to find a counterexample, or because the semantics have been fully traversed and that one can conclude to the accuracy of the verified property. Note that the software provides the counterexample that it found.

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). The computation time for a property obviously depends on both the complexity of the PLC entity and the number of input variables needed. However, it is possible to reduce the calculation time significantly by reducing the field to be explored for the input variables but nevertheless paying attention to the fact that the specified range of variation never becomes less than that actually scanned in the real case because otherwise the properties would no longer be analyzed on all actual conditions in execution. By way of example, FIG. 7 illustrates a common code or common C file (called a Cc file) defining the code c of the global program, which comprises the programs A and B (corresponding to the codes A and B) to be checked and the connections input and output variables (assignments). In addition, this file contains the interface description for a C node (inputs, outputs, and so on) required by the Hybrid (TM) tool.

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 The structure of this file (global list of inputs, outputs with external specification, cO and C O functions) is important for Hybrid, while the functions inside are entirely the responsibility of the user. This file simply provides identical entries to the two programs A and B, then calls the function corresponding to the code to check. Finally, we copy the outputs of A and B to the outputs of node C to facilitate access to these variables in Hybrid (Tm) 30

Claims

A method of verifying the functional equivalence between a controller entity (11) defining a set of finite state machines (13) and a production code (15) representing said controller entity (11) and generated from said automaton entity (11) by a generator (17) of production code, characterized in that it comprises the following steps: -generate a reference code from said automaton entity (11) and representing said entity by a reference code generator (21) different from said production code generator (17) (15), - creating in a formal language a common code (35) comprising said production and reference codes, a producer (37) of input variables (el, e2) for supplying said production and reference codes with identical input variables, and an output interface (39) for output variables (S1 , S2) corresponding, - d define in another formal language at least one determined property (P) that said common code must satisfy to prove the functional equivalence between said automaton entity (11) and said production code (15), - search by means of formal proof (29) of the values taken by the output variables (S1, S2) which defect said at least one property (P) determined, and - validate the functional equivalence between said automaton entity (11) and the production code (15) when said at least one determined property (P) is satisfied.

2. Method according to claim 1, characterized in that the formal proof means (29) generates a trace (41) representative of a difference in behavior between the production code (15) and the reference code (17) when said at least one determined property is not satisfied.

3. Method according to any one of claims 1 and 2, characterized in that said generators (17, 21) of reference code and production code are independent synchronous generators.

4. Method according to any one of claims 1 to 3, characterized in that the formal proof means (29) compares values taken by the output variables (Si, S2) corresponding to said production codes (15) and of reference (19) for checking a property of inequality between said output values so that the functional equivalence between said automaton entity (11) and the production code (15) is validated when said inequality property n ' is never satisfied

5. Method according to any one of claims 1 to 3, characterized in that the formal proof means (29) compares values taken by the output variables (S1, S2) corresponding to said production codes (15) and reference (19) for checking an equality property between said output values so that the functional equivalence between said automaton entity (11) and the production code (15) is validated when said equality property is satisfied .

6. Method according to claim 5, characterized in that said equality property checks the equality between each pair of said output variables.

7. Method according to claim 5, characterized in that said equality property satisfies the equality of the output variables sequentially.

8. Method according to any one of claims 1 to 7, characterized in that said production codes (15) and reference (19) are C language codes for production and reference respectively.

9. Method according to any one of claims 1 to 8, characterized in that the generation of said production code (15) is performed according to the following steps: - edit an intermediate model (51) representing said automata entity ( 11), and - transforming said intermediate model (51) into said production code (15) by said production code generator (17).

10. Method according to claim 9, characterized in that the validation of the functional equivalence between said automaton entity (11) and the production code (15) is a means for confirming an equivalence ([3] between the intermediate model (51) and the production code (15).

11. Method according to any one of claims 1 to 10, characterized in that the validation of the functional equivalence between said automaton entity (11) and the production code (15) is a means for confirming a equivalence ([4] between the production code (15) and the reference code (19).

Method according to any one of claims 1 to 11, characterized in that said formal proof means (29) is a model-checker or a program proof tool theorem prover theorem .

13. Computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of the steps of the verification method according to at least one of claims 1 to 12, when executed on a computer or a microprocessor.

A device for verifying the functional equivalence between a controller entity (11) defining a set of finite state machines (13) and a production code (15) representing said controller entity (11) and generated from said entity (11) by a generator (17) of production code, characterized in that it comprises: - a generator (21) of reference code for generating a reference code (19) from said automaton entity (11) and representing said entity (11), said reference code generator (21) being different from said generation code generator (17) (15), -making means (25) for creating in a formal language a common code (35) comprising said production and reference codes, a producer (37) of input variables (el, e2) for supplying said production and reference codes with variables of input identical inputs, and an output interface (39) for e to provide corresponding output variables (S 1, S 2), - defining means (27) for defining in another formal language at least one property (P) determined that said common code (35) must satisfy to prove the functional equivalence between said automaton entity (11) and said production code (15), - formal proof means (29) for searching for values taken by the output variables which defect said at least one determined property, and - a validation means (31) for validating the functional equivalence between said automaton entity (11) and the production code (15) when said at least one determined property (P) is satisfied.