CA2073903A1 - Procede d'aide au developpement d'un ensemble d'automates communicants - Google Patents
Procede d'aide au developpement d'un ensemble d'automates communicantsInfo
- Publication number
- CA2073903A1 CA2073903A1 CA002073903A CA2073903A CA2073903A1 CA 2073903 A1 CA2073903 A1 CA 2073903A1 CA 002073903 A CA002073903 A CA 002073903A CA 2073903 A CA2073903 A CA 2073903A CA 2073903 A1 CA2073903 A1 CA 2073903A1
- Authority
- CA
- Canada
- Prior art keywords
- networks
- network
- initial
- external
- petri
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/05—Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
- G05B19/052—Linking several PLC's
Abstract
PROCEDE D'AIDE AU DEVELOPPEMENT D'UN ENSEMBLE D'AUTOMATES COMMUNICANTS. Ce procédé consiste à : - fournir (1) à une machine de développement une description de réseaux de Petri élémentaires dits initiaux, modélisant respectivement des comportements partiels de chaque fonction; - vérifier (9), au moyen de cette machine de développement, que chaque réseau initial possède les propriétés souhaitées; - désigner (2) à cette machine de développement, une pluralité de réseaux à composer (7) et un mode de communication; - puis vérifier (9), au moyen de la machine de développement, que le réseau résultant de cette composition a des propriétés souhaitées; - modifier les réseaux de Petri initiaux si le réseau obtenu n'a pas les propriétés souhaitées; - puis désigner (1) de nouveau à la machine de développement une pluralité de réseaux à composer et un mode de communication pour lui faire réaliser une suite de compositions et de vérifications, jusqu'à l'obtention de réseaux de Petri ayant les propriétés souhaitées et modélisant respectivement : chaque automate de l'ensemble, et chaque communication entre deux interfaces inter-automates ou entre une interface externe et l'extérieur à l'ensemble d'automates. FIGURE A PUBLIER : Figure 1.
Description
2~3~
Procedé _ d'aide au developpe_ nt d'un ensemble d'automates communicants.
L'invention concerne un procéde d'aide au développement d'un ensemble d'automates communicants, ces automates communicants pouvant être concrétisés par un logiciel implanté dans une machine informatique ou bien par un circuit logique cablé. Ce prooédé vise plus particulièrement la conception de systèmes de télécommunications, ceux-ci comportant notamment des applications de traitement d'appels pour un centre de commutation. Une application de traitement d'appels fonctionne en temps réel et 10 comporte de nombreux automates communicants, c'est-à-dire traitant une pluralité de mes~ages qui sont entrelacés.
Le développement d'un tel ensemble d'automates nécessite trois intervenants : un concepteur humain; une machine de développement qui est un ordinateur à usage général, dans lequel est implanté
5 notamment un logiciel d'aide au développement d'un ensemble d'automates communicants; et une machine cible æur laquelle sera implanté un logiciel qui concrétisera l'ensemble d'automates communicents. Dans le cas d'un systame de télécommunications, la machine cible est, par exemple, l'unité de commande 20 multi-processeurs d'un centre do commutation. Dans ce cas, chaque automate est implanté entièrement dans un processeur, mais un meme processeur peut supporter plusieurs automates.
Le concepteur d'un ensemble d'automates communicants constituant une application de traitement d'appel, par exemple, 25 conna~t au d~part un ensemble de fonctions qu'il souhaite que cette application remplisse. Le comportement de chaque fonction sera décr~t par un automate. Le concepteur connait les interfaces externes et les interfaces internes de cet ensemble d'automates. Le developpem~nt d'un ensemble d'automates communicants comporte 30 quatre étapes :
- une spécification d'un ensemble d'automates communicants, à
partir de~ fonctions souhaitées, ces automates communicants étant destinés à etre implantés sous la forme de logiciels dans la machine cible, mais étant d~veloppés sur la machine de c~
développement, sous la forme d0 modèles;
- une analyse des automates et de leurs communications par leurs interfaces, sur c0tte machine de développement, sous la forme de modèles;
- une implémentation des automates communicants dans la machine cible, sous la forme de logiciels;
- une validation de ces logiciels dans la machine cible.
Il est connu d'utiliser des techniques de descriptions ~ormelles, lesquelles of~rent des moyens puissants, pour concevoir un ensemble d'automates communicants. En particulier, on utilise 10 certains langages spécialisés dont la sémantique est basée sur des mod~les mathématiques. Ces langage permettent aussi de faire certaines vérifications, mais les procédés d'utilisation de ces langages conviennent mal pour des systames de grande complexité
tels que les systëmas de télécommunications.
Par ailleurs, on conna~t la technique de modélisation par les réseaux de Petri, notamment par l'article : "Modelling and Analysis of Communication and Cooperation Protocols Using Petri Nets Based Models" North Holland Publishing Compagny Computer Networks 6 (1982) pages 419-441.
La technique deæ réseaux de Petri est une extension de la technique des automates séquentiel~ à nombre d'états fini, cette derniare utilisant les notions d'état et de transition. Une transition modèlise le passage du syst~me d'un etat stable à un autre état stabl~. L'originalité des réseau~ de Petri tient essentiellement au fait que les transitions ne relient plus des états globau~ d'un système, mais des états partiels appelés places, ce qui permet d'exprimer la synchronisation. Un certain nombre de marque~ appelées jetons, peuvent exister dans les places. Chaque configuration des jetons correspond à un état global différent. La 30 technique des r~seaux de Petri permet de repr~senter un ensemble de nombreux état6 et de nombreuse6 transitions d'un automate, et notamment la synchronisation entre auto~ates.
Lorsque la technique des réseaux de Petri est utilisée pour développer une application, la spéciflcation de c0tte application 2 ~
consiste à décrire, sous la forme d'un réseau de Petri :
- des places et une configuration initiale des jetons, pour l'état global initial;
- des transitions reliées aux places, et associées à des évènements, chaque évanement étant déclencheur ou conséquence d'une transition, ces évanements concrétisant l'interface entre l'application et l'extérieur à l'application.
L'analyse consiste ~ vérifier des propriétés souhaitées par le concepteur, notamment la consistance globale du réseau de Petri obtenu , c'est-à-dire qu'il possède des propriétés minimales d'un réseau de Petri; et consiste à rechercher des propriétés constamment vraies appelées invariants. Une analyse est exhaustive si elle consiste en une recherche de tous les états, notamment pour véri~ier l'accessibilité de chaque état et la vivacité de chaque transition. La recherche des invariants consiste en une 5 véri~ication sur la structure du réseau de Petri; et ainsi la détermination de certaines propriétés spéci~iques ~ l'application qui est modélisée.
L'ensemble des états accessibles est appelé graphe d'accessibilité, et constitue un automate qui concrétise 20 l'application à développer.
L'impl~mentation sur la machine cible découle directement de la modélisation réalisée sous la forme d'un réseau de Petri pendant l'étape de sp~cification, en ce qui concerne la synchronisation. Il reste à écrire des suites d'instructions correspondant à des actions associées aux transitions du modale réseau de Petri.
La validation du logiciel consiste ~ dé~inir des jeux de test et ~ ~aire ex~cuter ces jeux de test. Classiquement ceux-ci sont dé~inis par le concepteur.
Pour développer une applicatlon complexe, comportant de 30 nGmbreuses places et de nombreuses transitions, ce procédé connu pré~ente les di~icultés suivantes :
- le concepteur a beaucoup de di~ficulté à décrire le comportement global de cette application par un réseau de Petri unique;
- l'analyse exhaustive de ce réseau nécessite un temps de calcul et une capacité de mémoire atteignant rapidement des valeurs prohibitives sur la machine de développement;
- la mise au point est difficile et nécessite de refaire l'analyse de nombreuses fois.
Le but de l'invention est de proposer un procédé d'aide au développement d'un ensemble d'automates communicants, qui ne présente pas ces inconvénients.
L'objet de l'invention est un procédé d'aide au développement d'un ensemble d'automates communicants, ces automates comportant 0 une pluralité d'interfaces qui traitent une pluralité de messages entrelacés; cet ensemble d'automates étant développé à partir d'interface~ externes ~ l'ensemble, d'interfaces inter-automates, et de la fonction que doit remplir chaque automate de cet ensemble, et de la fonction que remplit l'environnement extérieur à chaque - 15 interfacP externe a l~en5emble;
caractéri~é en ce qu'll consiste ~ :
- fournir à une machine de développement une description de réseaux de Petri élémentaires dits initiaux, modélisant respectivement les comportements partiels de chaque fonction, en 20 décrivant notamment d~s évènements déclencheurs ou conséquences de transitions dans chaque réseau de Petri initial en attribuant une étiquette à chaque transition, cette étiquette étant fonction d'au moins un évènement, chaquc évènement étant un déclencheur ou étant une cons~quence de cette transition, ces évènements concretisant :
des interfaces externes à l'ensemble d'automates, des interfaces inter-automates, et des interfaces inter-réseaux initiaux;
- v~rifier, au moyen de cette macAine de développement~ que chaque réseau initial poss~de des propriét~s souhaitées;
- .~ournir ~ cette machine de développement une d~scription des 30 contraintes inter-ré~eaux initiaux, correspondant au comportement de l'environnement extérieur ~ l'ensemble d'auto~ates;
- désigner là cette machine de développement, une pluralité de réseaux à composer et un mode d0 communication, pour lui faire composer des réseaux de Petri initiaux, 0ntre eux ou avec des -5- 2~39~3 réseaux de Petri remplasant des réseaux initiaux ayant été composés précédemment, ou bien composer des réseaux remplaçant des réseaux initiaux ayant été composés précédemment; chaque composition étant réalisée en faisant communiquer au moins deux réseaux, par l'intermédiaire des étiquettes de leurs transitions, selon le mode S de communication désigné, ce dernier étant choisi parmi :
-- un mode synchrone;
~- un mode asynchrone;
-- un mode dit pseudo-synchrone, selon lequel les évènements constituant une communication avec l'extérieur au réseau 10 résultant de la composition, sont synchrones vis-~-vis de l'extérieur des réseaux à composer et sont asynchrones vis-à-vis des r~seaux ~ composer; chaque composition par le mode pæeudo-synchrone tenant compte des contraintes inter-réseaux;
puis véri~ier, au moyen de la machine de développement, que 5 le réseau obtenu par cette composition a des propriétés souhaitées;
- fournir à la machine de développement une description de réseaux initiaux modifiés, en remplacement de résea~ initiaux à
composer, si le réseau obtenu en composant ces derniers n'a pas les propriétés souhaitées;
- puis désigner de nouveau à la machin0 de développement une pluralité de réseaux à composer et un mode de communication pour lui faire réaliser une suite de compo6itions et de vérifications, jusqu'à l'obtention de réseaux de Petri ayant des propriétés souhaitées et modélisant respectivement : chaque communication entre deux au~omates ou entre une interface externe d'un automate et l'environnement di~ l'ansemble d'automates, et chaque automate de l'ensemble.
Le procédé ainsi caract~ris~ a pour avantage que le concepteur humain d'un ensemble d'automates communicants très complexe, nia à
30 concevoir, et ~ manipuler, que des réseaux de Petri élémentaires, c'est-à-dire ne comportant que quelques places et transitions. La composition de réseaux de Petri élémentaires, puis la composition de réseaux de Petri remplaçant des réseaux initia~x ayant été
précédemment composés, permet de modéliser finalement un ensemble -6- 2~73~3 d'automates bsaucoup plus complexe que celui qui pourrait être modélisé par un réseau de Petri global, ou par un langage de description formelle reposant sur la modélisation par automates.
Le procédé ainsi caractérisé permet de concevoir un ensemble d'automates communicants en réalisant une analyse exhaustive des réseaux de Petri modélisant ces automates, sans nécessiter un temps de calcul et une capacité de mémoire ayant des valeurs prohibitives, parce que la vérification des propriétés souhaitées est faite par étapes, au fur et à mesure de la composition des 10 réseaux de Petri initiaux, et sans aller Jusqu'à un réseau de Petri modélisant l'ensemble des automates.
L'implémentation d'un automate obtenu par le procédé selon l'invention consiste à écrire une suite d'instructions pour chaque transition de réseau de Petri élémentaire. Le nombre de transitions 15 est plus élevé que celui obtenu par une modélisation par un réseau de Petri unique, à cause des compositions de réseau. Ce nombre élevé de transitions facilite l'écriture des suites d'instructions correspondant à des actions associée~ aux transitions, puisque l'augmentation du nombre des transitions corre6pond à une 20 6implification des actions associées aux transitions. Autrement dit, chaque action est réalisée au mo;yen d'un plus petit nombre d'instructions. Ces suites d'instructions ont en plus l'avantage d'avoir un déroulement linéaire, c'est-~-dire sans branchement.
Elles sont donc faciles ~ mettre au point.
La validation du logiciel implémentant cet ensemble d'automates est simple car, la cohérence des états et des transitionc ayant ét~ vérifiée avant l'implantation sur la machine cible, il ne reste qu'à vérifier les suites d'instructions correspondant à des actions associées aux transition~.
Le test est simple puisqu'il peut, lui aussi, être fait par étape. Il consiste à produire des suites de ~ranchissements de transitions en par~ourant de façon co~plète l'ensemble de transitions de l'automate derivé du réseau de Petri obtenu pour chaque automate et pour chaque communication. Ces suites de franchissements de transitions peuvent être éventuellement réduite~
-7- ~ Q ~
ensuite, selon des critères de sélection, afin de réduire le nombre de tests.
Le procédé ainsi caractérisé a enfin pour avantage de faciliter la maintenance d'un ensemble d'automates ayant été consus ~ l'aide de ce procédé. Toute modification ou extension de cet ensem~le d'automates ne doit pas dé8rader la cohérence de l'ensemble. Pour que cette condition soit remplie, il est nécessaire de reprendre la mise en oeuvre du procédé selon l'invention, dès son point de départ, c'est-~-dire dès la description des réseaux de Petri élémentaires initiaux. Ceci peut sembler être une contrainte, à première vue, mais en fait ceci garantit la qualité du logiciel o~tenu finalement après ces opérations de maintenance.
Selon une autre caractéristique, pour réaliser des 15 compositions par le mode de communication synchrone, le procédé
selon l'invention consi6te à fusionner toutes les transitions appartenant à deu~ réseaux à composer et dont les étiquettes comportent un même événement qui est :
- soit con~équence de l'une des transitions et déclencheur d'une autre transition;
- soit conséquence commune des transitions;
- soit déclencheur commun des transitions.
Selon une autre caractéristique, pour réaliser des compositions par le mode de communication asynchrone, le procédé
selon l'invention consiste à :
- relier un premier et un deuxième réseau à composer, par une file dans chaqua sens de communication;
- imposer des contraintes temporaires sur le protocole de communication utilisant ces deux files, pendant la durée de la vérification des propriétés souhaitées du réseau ré ultant de la composition des deux réseaux à composer et des deux files.
Selon une autre caractéristique, pour réaliser des compositions selon le mode de communication pseudo-synchrone, le procédé selon l'invention consiste à :
2 ~ 3 - relier ces réseaux par une file unique possédant une pluralité d'entrées reliées respectivement à une sortie de chacun des réseaux à composer, et une pluralité de sorties reliées respectivement ~ une entrée de chacun des réseaux à composer;
imposer une contrainte permanente consistant à donner la priorité aux évènements en provenance de cette file, par rapport aux évènements en provenance des interfaces extérieures au réseau obtenu, pour le déclenchement de transitions dans les réseaux à
composer;
- imposer des contraintes temporaires inter-réseaux, uniquement pendant la durée de la vérification des propriétés souhait~es du réæeau de Petri modélisant le comporte~ent d'un automate, et consistant à ajouter des conditions pour le déclenchement de transitions d'un réseau à composer, ces conditions 15 portant sur 1'état des autres réseaux ~ composer, et correspondant au comportement de l'environnement du ré6eau ré3ultant.
Selon un mode de mise en oeuvre préférentiel, et si tous les réseaux de Petrl initiaux comportent chacun au plus une interface externe à un automate, la composition des réseaux élémentaires initiaux est réalisée en trois étapes successives, dans cet ordre :
- une première étape consistant à : composer des réseaux deux à deux par 1P mode de communical;ion synchrone, pour obtenir des réseaux de Petri remplaçant des réseaux initiaux et comportant au plu9 une interface externe ~ un automate;
vérifier que les réseaux obtenus ont des propriétés souhait~es; et recommencer la première étape pour les réseaux qui ont été composés et dont le r~seau réæultant n'a pas les propri~tés souhaitées;
- une deuxième étape consistant, pour chaque interface externe ~ un automate, a : composer deux à deux par le mode de communication asynchrone des réseaux de Petri issus de la première étape et ayant en commun une interface inter-automates ou externe à l'ensemble d'automates, pour obtenir lors de chaque composition un réseau de Petri modélisant une communication entre deux interfaces inter-automates ou entre une interfa~e externe à un automate et l'environnement de l'automate; vérifier que les réseaux obtenu~ ont des propri~té souhaitées; et recommencer la première etape pour les réseaux qui ont été composés et dont le réseau résultant n'a pas les propri~tés ~ouhaitée~;
une troisième étape consistant ~ : réaliser, pour chaque automate, une eomposition par le mode de communication pseudo-syn~hrona, pour composer des réseaux de Petri issus de la premi~re étape et validés par la deuxième étape, en tenant compte des contraintes inter-réseaux initiaux correspondant au comportement de l'extérieur ~ l'ensemble, pour obtenir un réseau de Petri modélisant le comportement de eet automate, notamment les communications entre les réseaux i8~UB de la premiare ~tape; ~érifier que les ré~eaux obtenus ont de~ propriétés souhaitées; et recommencer la premi~re et la deu~ième ~tape pour les réseaux qui ont été
composés et dont le réseau r~sultant n'a pas les propriét~s souhaitées ;
Ce mode de mise en oeu~re du procédé selon l'invention réduit les probl~mes de mise au polnt d'~m ens~!mble d'automates parce-que 20 la première étape permet de composer tous les ré~eaux initiaux qui sont rattaché~ ~ une même inter~ace inter-automates ou à une m~me intarface externe d'un automate, ou qui ont en commun de n'être rattachés à aucune lnterface, ce qui permet de rendre ind~pendants les problames de mise au point de chaque communicatlon entre un 25 automate et son environnement. La deuxième étape permet de résoudre ces probl~me~ ind~pendamment pour chaque communication. La troisiame ~tape perMet d~ mettre au polnt les commuDications internes à un aut~mate lnd~pendamment des autres aut~mates.
D'autre détails de la mise en oeuvre du procéd~ selon 30 l'invention appara~tront dan~ la description ci dessous et ~ l'alde des ~igures l'accompagnant :
- la figure 1 représente un organigramme d'un exemple de mi~e en oeuvre du proc~d~ selon l'invention;
- la figure 2 repr~sente sch~matiquement un exemple de -lo- ~ 3 transition et l'étiquette qui lui est attribuée;
- les figures 3 à 6 illustrent le mode de communication synchrone qui est utilisé pour composer des réseaux de Petri;
- la figure 7 illustre la composition de deux réseaux de Petri par le mode de communication asynchrone;
- la figure 8 illustre la composition de trois réseaux de Petri par le mode de communication dit pseudo-synchrone;
- les figures 9~ lOa, et lOb illustrent le mode de mise en 10 oeuvre préférentiel comportant trois étapes successives au cours desquelles sont utilisés successivement les modes de communication : synchrone, asynchrone, pseudo-synchrone.
La figure 1 représente un organigramme d'un exemple de mise en oeuvre du procédé selon l'invention, sous la forme d'un logiciel 15 implanté dans une machine de dé~eloppement constituée d'un ordinateur classique à usage général. L'écriture de ce logiciel ~
partir de la description ci-dessous est ~ la portée de l'Homme de l'Art. Cet exemple de mise en oeuvre est utilisé, par exemple, pour développer un ensemble d'automates communicants constituant une application de traitement d'appels d'un centre de commutationO
Chaque fonction sera décrite par un autornateO
Une premiare étape 1 de l'organLgramma consiste ~ ~aire décrire, par le concept~ur, chaque fonction de l'application sous la forme de comportements partiels modé.Lisés chacun par un r~seau de Petri él~mentaire initial 3, sous la forme d'interfaces 4, inter-automates ou externes à 1'ensemble d'automates, sous la forme de contraintes inter-r~seaux initi~ux et sou~ la forme de propriétés souhaitées, spécifiques pour chaque automate. Pour appliquer le mode de mise en oeu~re préférentiel du procéd~ ~elon l'invention, le concepteur prend soin de modéliser chaque comportement partiel par un réseau de Petri élémentaire initial n'ayant qu'une seule interface, ou aucune interface externe ~ un automate. Chaque r~seau de Petri initial ayant une interface externe respecte des contraintes imposées par des interfaces externes à l'ensemble d'automates ou par des interfaces 2 ~ 3 inter-automates. La définition de chaque réseau initial correspond généralement à une phase d'une communication. Les contraintes inter-réseaux initiaux corespondent, pour chaque automate, au comportement de l'environnement ext~rieur à 1'ensemble.
Au moment de faire réaliser, par la machine de développement, chaque composition de réseaux de Petri, le concepteur indique à la machine de développement quels réseaux il souhaite composer et selon quel mode de communication, 2.
Au cours de la description initiale le concepteur décrit aussi des données complémentaires 5 concernant les actions associées aux transitions et qui seront nécessaires au moment au moment de l'implémentation du logiciel concrétisant l'ensemble d'automates qui va être développé.
L'étape suivante consiste en une première analyse 9 pour 15 vérifier la consistance des réseaux de Petri initiaux. Elle vérifie les propriétés minimales et clasBique6 d'un réseau de Petri : Il doit être borné, vivant, propre, et sans blocage. Si l'un des réseaux initiaux n'a pas toutes ces propriétés, la machine de développement le signale au concepteur pour qu'il rectifie la description initiale de~ comportements partiels.
La description initiale 1 de chaque réseau de Petri consiste aussi à décrire pour chaque transition de ce réseau, les évènements déclencheurs de cette tran~ition et les évènements conséquences de cette transition. Cette description est réalisée de manière tr~s concise, 80U8 la forme d'une ét~quette attribuée à chaque tranRition, en inscrivant ces évènements les uns à la suite des autres et en faisant précéder chacun d'un symbole, ? ou !, indiquant respectivement si c'est un évènement déclencheur ou si c'est un év~nement conséquence de la transitlon.
La ~igure 2 représente ~ titre d'exemple une transition et son étiquette ?M1 IM2 !M3 IM4. Cette étiquette signifie que la transition est déclenchée par l'évènement M1 et qu'elle a pour conséquences des évènements M2, M3, M4. Comme il appara~tra plus loin, la comparaison entre les étiquettes respectives de deux transitions de deux réseaux différents permet de savoir quels sont 7 3 ~ ~ 3 leurs interactlons. Ces étiquettes sont donc une représentation de la communication entre des transitions n'appartenant pas à un mam0 réseau de Petri. Elles sont utilisées par la machine de développement, pour composer des réseaux de Petri, désignés par le concepteur, lorsque le concepteur veut établir une communication entre des réseaux ~ composer.
Sur la figure l, la mise en oeuvre du procédé selon l'invention consiste ensuite à faire réaliser par la machine de développement une série de compositions 7 et d'analyses 9. Chaque composition 7 étant suivie d'une analyse 9 du réseau résultant 8, qui fournit un graphe d'acce~sibilité ll et vérifie les propriétés lO du réseau résultant, et les confronte aux propriétés souhaitées 4.
Pour faciliter la véri~ication de propriétés spécifiques de 15 réseaux r~sultant de la composition de réseaux, le procédé
consiste, en outre, ~ repérer certains évènements au moment où le concepteur décrit les reseaux de Petri initiaux. Les évènements ainsi rep~rés, 80nt éliminés du graphe d'accessibilité ll, ce qui permet d'en réduire la taille9 et facilite son interprétation par le concepteur.
Lorsque les trois étapes du procédé ont été réalisés avec succès, le procédé d'aide à la conception peut être suivi d'une implémentation 12 de l'ensemble des automates ayant été ainsi conçu~ et analysés. Cette impl~mentation consiste ~ faire correspondre des tâches logicielles a~x transitions d'un graphe d'accessibilité. La machine de développement décrit les transitions SOU8 la form~ de tableaux de données structurées 13. Ces transitions pouvent être activées par un logiciel clas~ique interprate d'automate ou interpr~te multi-automates, implanté sur la machine cible. La taille des table~ de descriptions du graphe d'accesæibilité e~t genéralement prohibitive lorsqu'on considère le graphe d'accessibilit~ du ré~eau de Petri modélisant chaque automate de l'ensemble d'automates E. Il est donc préf~rable de décrire plut8t les graphes d'accessibilit~ de plusieurs sous-automates constituant un automate pour obtenir des tables de -13- 2~ 9~3 descriptions ayant des tailles raisonnables. Les contraintes inter-réseaux initiaux, lesquelles sont représentées par des contraintes entre sous-automates, ne sont pas implémentées car elles existent déjà dans l'environnement extérieur à l'ensemble.
Dans le cas de l'implémentation de plusieurs sous-automates~ il est nécessaire de prévoir un mécanisme de synchronisation entre les di~férents sous-automatss, en utilisant une file interne spéci~ique pour cette sy~chronisation. Cette ~ile est celle utilisée pour la composition des sous-automates et décrite plus loin en réf~rence à
la figure 8.
Par ailleurs, le concepteur implémente chaque action 5 par une suite d'instructions, la machine de développem~nt identifie cette suite d'instructions 14, en mettant en commentaire le nom de la transition qui correspond à cette action.
Lorsque le logiciel a été codé et compilé, il est validé de manière classique au moyen de jeux de t0st 16 qui sont des séquences d'évènements déterminés à partir des graphes d'accessibilité :
- soit des modèles représentant les différents automates 20 constituant l'ensemble E;
- soit des mod~les repr~sentant les di~férents sous-automates constituant chaque automate.
Acces~oirement l'implémentation 12 produit aussi une documentation 15 en vue de l'utilisation des logic1els implémentant l'ensemble d'automates ayant été consu.
ConBid~ron8 plu8 en détails les compocitions 7. Chaque composition con~iste ~ composer plusieurs réseaux de Petri. Mais selon le mode de mise en oeuvre pré~érentiel, dans une première étape, toutes les opérations de composition sont réalisées par le ~o mode de communication synchrone et composent exclusivement :
- soit deux r~seaux initiaux;
- soit un réseau initial et un réseau remplaçant des ré~eaux initiaux ayant été composés précédemment;
- soit deux réseaux remplaçants.
En outre, au cours de cette première étape, les r6seaux de -14- 2~3~}~J~-~
Petri resultant de ces compositions doivent comporter au plus une interface externe ~ un automate.
Le mode de communication synchrone consiste ~ fusionner au moins deux transitions appartenant aux deux reseaux de Petri à
compoæer et ayant un m8me evènement en commun dans leurs étiquettes. Les figures 3 à 5 illustrent ces trois types possibles de fusion de transitions. Le concepteur choisit l'un de ces trois types pour chaque fusion.
La figure 3 illustre un premier ~ype de fusion F1. Si un réseau de Petri R1 poss~de une transition qui a pour conséquence l'évènement M et si le r~seau R2 possade une transition qui a pour déclencheur l'evènement M, ces deux ré~eaux peuvent être fusionnés par le type de fusion F1 pour constituer un réseau R3 possédant une transition résultant de la fusion des deux transitions considérées.
La figure 4 illustre un second type de fusion F2. Si un réseau R4 possède une transition déclenchée par un évènement M et si un réseau R5 possede une transition déclenchée, elle aussi, par l'évènement M, ces deux réseaux peuvent être fusionnés en un réseau R6 poss~dant une transltion résultant de la fusion des deux transitions considérées et qui est déclenchée par l'évènement M.
La figure 5 illustre un troisième type de fusion F3. Si un ré~eau R7 possède une transition ayant pour conséquence un évènement M et si un r~seau R8 possède une transition qui a, elle aus~i, pour conséquence l'évènement M, alors ces deux réseaux peuvent être fusionnés pour constituer un réseau de Petri R9 pos~édant une transition qui a pour cons8quence l'év~nement M.
Lorsque chacun des réseaux ~ composer possède plus d'une tran~ition qui est 1R conséquence ou le déclencheur d'un même évènement, le réseau remplasant les réseaux composés possade des 30 transitions ré~ultantes qui sont répliqu~es à cause de la composition deux R deux des transitions des réseaux R composer.
La figure 6 illu~tre ce cas. Sl un réseau RlO poss~de deux transitions tl, t2 qui ont pour déclencheur un m8me évanement M et si un réseau R11 possède deux tran6itions ta, tb qui ont pour cons~quence le même ~v~nement ~, alors il e~t possible de fusionner -15- 2 ~ 3 ces transitions deux à deux par le type de fusion Fl et d'obtenir un réseau résultant R12 comportant quatre transitions tla, tlb, t2a, t2b.
Comme représenté sur la figure 1~ apres chaque composition 7, un réseau résultant 8 subit une analyse 9 qui consiste à vérifier, lO, que les propriétés obtenues correspondent aux propriétés 4 souhaitées par le concepteur, et à déterminer un graphe d'accessibilité 11. La détermination 11 du graphe d'accessibilité
et la vérification lO des propriétés sont réalisées simultanément par ia machine de développement, selon des procédés de calcul classiques po~ des réseaux de Petri. Cette analyse est dynamique et exhaustive, c'est-~-dire recherche tous les états et touteæ les transitions possibles dans le réseau résultant de la composition.
Elle déduit de ce graphe les propriétés générales de ce réseau et notamment vérifie s'il est : borné, sauf, vivant, propre, et sans blocage.
Elle détermine en outre si le réseau a les propriétés spécifiqueY ~ouhait~es recherchées par le concepteur. Si le réseau a toutes les propri~tés spécifiques souhait~es, la mise en oeuvre du procédé peut être poursuivie. Dans le cas contraire, la machine de développement indique au concepteur quelles sont les propriét~s qui ne sont pas vérifiées. Le concepteur modifie la description des réseaux initiaux pour y remédier. D'autre part, le graphe d'accesibilit~ 11 peut être r~utilisé pour des compositions ultérieures avec d'autres r~seaux de Petri, soit initiaux, soit résultant de composition précédemment réalis~es.
Selon le mode de mise en oeuvre préférentiel, une deuxième étape, pour les compositions 7 de réseaux de Petri, consiste pour chaque interface externe à l'ensemble d'automRtes et pour chaque 30 interface inter-automates, à réaliser des compositions par le mode de communication asynchrone pour composer de~ réseaux de Petri remplasant des réseaux initiaux, entre eux ou a~ec un réseau initial éventuellement subRistant, pour obtenir lors de chaque composition un réseau de Petri modélisant une communication entre deux automates ou entre une interfac~ externe à un automate et ~16- 2~3~
l'environnement de cet automate.
Chacun des réseaux de Petri obtenus à la fin de la première étape représente le comportement d'un sous-automate constituant une partie de l'un des automates ~ concevoirl même s'il s'agit d'un réseau initial subsistant.
Toutes les opérations de composition réalisées au cours de la deuxième étape sont réalisées au moyen de deux files, une dans chaque sens de communication. Ces deux files sont du type "pr~mier entré, premier sorti", et sont incorporées au réseau résultant. Ce 10 mode de communication est utilisé pour pouvoir analyser des dialogues asynchrones entre réseaux de Petri, et plus particulièrement pour analyser des protocoles de communication.
La figure 7 illustre le mode de communication asynchrone, dans un exemple où deux réseaux R13 et R14 sont mis en communication au 15 moyen de deux ~iles référencées FIF01 et FIF02, une pour chaque sens, pour constituer un réseau résultant RR. Pour mieux analyser la communication asynchrone entre les deux ré~eaux, des contraintes sur la communication peuvent consister ~ impo~er : des pertes de signaux ou des débordements de temporisation; ou une certaine 2G synchronisation temporaire, selon une transmission en alternat entre le~ deux réseaux; ou bien une limitation temporaire du nombre d'évanements ~tockés en attente dans chacune des deux files. Ces contraintes ~ont int~grées automatiquement aux réseaux de Petri, par la machine d'aide au développemement, sous la commande du concepteur. Il est à la port~e d0 l'hom~e de l'art de réaliser un programme, pour cette machine de développement, mettant en oeuvre cette caractéristique du procéd~ selon l'invention.
Selon le mode de mise en oeuvre préférentiel du procédé selon l'invention, les compositions de réseaux comportent une troisiame étape consistant à r~aliser des compositions uniquement par le mode de communication pseudo-synchrone, pour composer les réseaux de Petri ~ournis par la premiètre étape. Le mode de communication p~eudo-synchrone est obtenu au moyen d'une seule flle du type "premier entré premier sorti", et en donnant une priorité aux transitions déclenchées par des évènements conséquences de transi--17- 2 ~ 7 ~
tion~ internes aux réseaux à composer, par rapport aux transltions déclenchée6 par des évènements externes à ces réseaux.
Cette priorité ainsi que la file garantissent une co~munication synchrone ~ l'extérieur du réæeau résultant mais 5 maintlennent une communication asynchrone à l'intérieur du réseau résultantO
La figure 8 illust~e la communication pæeudo-synchrone. Elle représente un réseau de Petri R18 résultant de la composition de troi~ réseaux de Petri Rl5, R16, R17 au moyen d'une file de type 10 "premier entré premier sorti" référencée FIF05 et qui est incorporée au réseau résultant R18. Ce r~eau résultant possède une interface le rellant au reste de l'ensemble d'automate6 et le reliant ~ l'ext~rieur de l'ensemble, constituée par exemple d'une - file d'entrée référencée FIF03 et d'une file de sortie référencée 15 FIF04. La file FIF05 comporte trois entrées reli~es re~pectivement ~ trois sortie6 de6 r~seaux R15 à Rl7 et troi6 sortie~ reli~es respectivement à trois entrées des r~eaux R15 à Rl7. Chaque évanement qui est la conséquence d'une transition dans l'un des ré~eaux Rl5, R16, R17 et qui e~t le déclencheur d'une autre 20 transition dans l'un de ces réseaux transite par la file d'attente FIF05. Ces év~nements vont donc réagir sur les réseaux R15, R16, R17 dans l'ordre où ils sont inscrits dans la fil0 d'attente FIF05.
Cette file, et la priorit~ selon laquelle elle est ~erée, maintiennent 8ynchrcne la co~munication vis ~-vis des év~ne~ents 25 externes au r~seau r6sultAnt R18.
Dan~ cet exemple, le réseau Rl5 co~porte une transition d~clench~e par l'~vènement Il et ayant pour con6~quence l'évanement I2. Le r~seau R16 possède una première transition déclench~e par un év~nement qui est un mes~age MES1 reçu par l'interface et cette 30 transition a pour conséquence un évanement I1. Le r~seau R1~
po~sède une 6econde transition déclenchée par un évènement qui est un message ~ES2, et qui est sans conséquence. Le réseau R17 possède une transition qui est d~clenchée par l'évènement I2 et qui a pour conséquence un év~nement constitué par un mes6age MES30 Sur la figure ~, les chif~res entre parenthè~es indlquent -18- 2 ~ 3 l'ordre de déclenchement des transitions conformément à la règle de priorité. A l'instant considéré, les messages MESl et MES2 viennent d'8tre inscrits dans la file d'entrée FIF03 de l'interface du réseau résultant R18. La première transition du réseau R16 est déclenchée par le message MESl qui est lu en premier dans la file d'entrés FIF03. Cette transition a pour conséquence l'évanement I1. Ce dernier déclenche 1mmédiatement la transition du réseau R15 car il est prioritaire par rapport à la lecture du message M~S2. Cette transition, qui est la deuxième transition depuis 1'arrivée des messages, a pour conséquence l'évènement I2.
L'évènement I2 est lui aussi prioritaire par rapport à la lecture du message MES2. Il déclenche la transition du réseau ~17, qui a pour cons~quence un évène~ent qui est 1'émission d'un message MES3 qui est inscrit dans la file de sortie FIF04. Il n'y a plu8 15 d'interaction interne possible pour le moment, la règle de priorité
autorise à lire le prochain message MES2, qui est stocké dans la file d'entrée FIF03. Ce message MES2 est un évènement qui déclenche la seconde transition du réseau R16. L'ordre de prise en compte des messages externe~ est donc finalement : MES1, MES3, MES2. Le 20 message MES2 ne déclenche la seconde transition du réseau R16 qu'après que le message MESl ait ~ité complètement traité, c'est-à-dire apr~ avoir déclench~ la première transition de R16 puis la transition da R15 puis la transition de R17. La communication entre les réseaux R15, R16, R17 est donc globalement asynchrone a l'int~rieur du réseau résultant R18, mais la communication est synchrone avec 1'extérieur.
Les figures 9, lOa, et lOb illustrent un exemple de mise en oeuvre du proc~d~ s~lon l'invention, selon le mode pr~férentiel, pour aider au développement d'un ensemble d'automates communicants
Procedé _ d'aide au developpe_ nt d'un ensemble d'automates communicants.
L'invention concerne un procéde d'aide au développement d'un ensemble d'automates communicants, ces automates communicants pouvant être concrétisés par un logiciel implanté dans une machine informatique ou bien par un circuit logique cablé. Ce prooédé vise plus particulièrement la conception de systèmes de télécommunications, ceux-ci comportant notamment des applications de traitement d'appels pour un centre de commutation. Une application de traitement d'appels fonctionne en temps réel et 10 comporte de nombreux automates communicants, c'est-à-dire traitant une pluralité de mes~ages qui sont entrelacés.
Le développement d'un tel ensemble d'automates nécessite trois intervenants : un concepteur humain; une machine de développement qui est un ordinateur à usage général, dans lequel est implanté
5 notamment un logiciel d'aide au développement d'un ensemble d'automates communicants; et une machine cible æur laquelle sera implanté un logiciel qui concrétisera l'ensemble d'automates communicents. Dans le cas d'un systame de télécommunications, la machine cible est, par exemple, l'unité de commande 20 multi-processeurs d'un centre do commutation. Dans ce cas, chaque automate est implanté entièrement dans un processeur, mais un meme processeur peut supporter plusieurs automates.
Le concepteur d'un ensemble d'automates communicants constituant une application de traitement d'appel, par exemple, 25 conna~t au d~part un ensemble de fonctions qu'il souhaite que cette application remplisse. Le comportement de chaque fonction sera décr~t par un automate. Le concepteur connait les interfaces externes et les interfaces internes de cet ensemble d'automates. Le developpem~nt d'un ensemble d'automates communicants comporte 30 quatre étapes :
- une spécification d'un ensemble d'automates communicants, à
partir de~ fonctions souhaitées, ces automates communicants étant destinés à etre implantés sous la forme de logiciels dans la machine cible, mais étant d~veloppés sur la machine de c~
développement, sous la forme d0 modèles;
- une analyse des automates et de leurs communications par leurs interfaces, sur c0tte machine de développement, sous la forme de modèles;
- une implémentation des automates communicants dans la machine cible, sous la forme de logiciels;
- une validation de ces logiciels dans la machine cible.
Il est connu d'utiliser des techniques de descriptions ~ormelles, lesquelles of~rent des moyens puissants, pour concevoir un ensemble d'automates communicants. En particulier, on utilise 10 certains langages spécialisés dont la sémantique est basée sur des mod~les mathématiques. Ces langage permettent aussi de faire certaines vérifications, mais les procédés d'utilisation de ces langages conviennent mal pour des systames de grande complexité
tels que les systëmas de télécommunications.
Par ailleurs, on conna~t la technique de modélisation par les réseaux de Petri, notamment par l'article : "Modelling and Analysis of Communication and Cooperation Protocols Using Petri Nets Based Models" North Holland Publishing Compagny Computer Networks 6 (1982) pages 419-441.
La technique deæ réseaux de Petri est une extension de la technique des automates séquentiel~ à nombre d'états fini, cette derniare utilisant les notions d'état et de transition. Une transition modèlise le passage du syst~me d'un etat stable à un autre état stabl~. L'originalité des réseau~ de Petri tient essentiellement au fait que les transitions ne relient plus des états globau~ d'un système, mais des états partiels appelés places, ce qui permet d'exprimer la synchronisation. Un certain nombre de marque~ appelées jetons, peuvent exister dans les places. Chaque configuration des jetons correspond à un état global différent. La 30 technique des r~seaux de Petri permet de repr~senter un ensemble de nombreux état6 et de nombreuse6 transitions d'un automate, et notamment la synchronisation entre auto~ates.
Lorsque la technique des réseaux de Petri est utilisée pour développer une application, la spéciflcation de c0tte application 2 ~
consiste à décrire, sous la forme d'un réseau de Petri :
- des places et une configuration initiale des jetons, pour l'état global initial;
- des transitions reliées aux places, et associées à des évènements, chaque évanement étant déclencheur ou conséquence d'une transition, ces évanements concrétisant l'interface entre l'application et l'extérieur à l'application.
L'analyse consiste ~ vérifier des propriétés souhaitées par le concepteur, notamment la consistance globale du réseau de Petri obtenu , c'est-à-dire qu'il possède des propriétés minimales d'un réseau de Petri; et consiste à rechercher des propriétés constamment vraies appelées invariants. Une analyse est exhaustive si elle consiste en une recherche de tous les états, notamment pour véri~ier l'accessibilité de chaque état et la vivacité de chaque transition. La recherche des invariants consiste en une 5 véri~ication sur la structure du réseau de Petri; et ainsi la détermination de certaines propriétés spéci~iques ~ l'application qui est modélisée.
L'ensemble des états accessibles est appelé graphe d'accessibilité, et constitue un automate qui concrétise 20 l'application à développer.
L'impl~mentation sur la machine cible découle directement de la modélisation réalisée sous la forme d'un réseau de Petri pendant l'étape de sp~cification, en ce qui concerne la synchronisation. Il reste à écrire des suites d'instructions correspondant à des actions associées aux transitions du modale réseau de Petri.
La validation du logiciel consiste ~ dé~inir des jeux de test et ~ ~aire ex~cuter ces jeux de test. Classiquement ceux-ci sont dé~inis par le concepteur.
Pour développer une applicatlon complexe, comportant de 30 nGmbreuses places et de nombreuses transitions, ce procédé connu pré~ente les di~icultés suivantes :
- le concepteur a beaucoup de di~ficulté à décrire le comportement global de cette application par un réseau de Petri unique;
- l'analyse exhaustive de ce réseau nécessite un temps de calcul et une capacité de mémoire atteignant rapidement des valeurs prohibitives sur la machine de développement;
- la mise au point est difficile et nécessite de refaire l'analyse de nombreuses fois.
Le but de l'invention est de proposer un procédé d'aide au développement d'un ensemble d'automates communicants, qui ne présente pas ces inconvénients.
L'objet de l'invention est un procédé d'aide au développement d'un ensemble d'automates communicants, ces automates comportant 0 une pluralité d'interfaces qui traitent une pluralité de messages entrelacés; cet ensemble d'automates étant développé à partir d'interface~ externes ~ l'ensemble, d'interfaces inter-automates, et de la fonction que doit remplir chaque automate de cet ensemble, et de la fonction que remplit l'environnement extérieur à chaque - 15 interfacP externe a l~en5emble;
caractéri~é en ce qu'll consiste ~ :
- fournir à une machine de développement une description de réseaux de Petri élémentaires dits initiaux, modélisant respectivement les comportements partiels de chaque fonction, en 20 décrivant notamment d~s évènements déclencheurs ou conséquences de transitions dans chaque réseau de Petri initial en attribuant une étiquette à chaque transition, cette étiquette étant fonction d'au moins un évènement, chaquc évènement étant un déclencheur ou étant une cons~quence de cette transition, ces évènements concretisant :
des interfaces externes à l'ensemble d'automates, des interfaces inter-automates, et des interfaces inter-réseaux initiaux;
- v~rifier, au moyen de cette macAine de développement~ que chaque réseau initial poss~de des propriét~s souhaitées;
- .~ournir ~ cette machine de développement une d~scription des 30 contraintes inter-ré~eaux initiaux, correspondant au comportement de l'environnement extérieur ~ l'ensemble d'auto~ates;
- désigner là cette machine de développement, une pluralité de réseaux à composer et un mode d0 communication, pour lui faire composer des réseaux de Petri initiaux, 0ntre eux ou avec des -5- 2~39~3 réseaux de Petri remplasant des réseaux initiaux ayant été composés précédemment, ou bien composer des réseaux remplaçant des réseaux initiaux ayant été composés précédemment; chaque composition étant réalisée en faisant communiquer au moins deux réseaux, par l'intermédiaire des étiquettes de leurs transitions, selon le mode S de communication désigné, ce dernier étant choisi parmi :
-- un mode synchrone;
~- un mode asynchrone;
-- un mode dit pseudo-synchrone, selon lequel les évènements constituant une communication avec l'extérieur au réseau 10 résultant de la composition, sont synchrones vis-~-vis de l'extérieur des réseaux à composer et sont asynchrones vis-à-vis des r~seaux ~ composer; chaque composition par le mode pæeudo-synchrone tenant compte des contraintes inter-réseaux;
puis véri~ier, au moyen de la machine de développement, que 5 le réseau obtenu par cette composition a des propriétés souhaitées;
- fournir à la machine de développement une description de réseaux initiaux modifiés, en remplacement de résea~ initiaux à
composer, si le réseau obtenu en composant ces derniers n'a pas les propriétés souhaitées;
- puis désigner de nouveau à la machin0 de développement une pluralité de réseaux à composer et un mode de communication pour lui faire réaliser une suite de compo6itions et de vérifications, jusqu'à l'obtention de réseaux de Petri ayant des propriétés souhaitées et modélisant respectivement : chaque communication entre deux au~omates ou entre une interface externe d'un automate et l'environnement di~ l'ansemble d'automates, et chaque automate de l'ensemble.
Le procédé ainsi caract~ris~ a pour avantage que le concepteur humain d'un ensemble d'automates communicants très complexe, nia à
30 concevoir, et ~ manipuler, que des réseaux de Petri élémentaires, c'est-à-dire ne comportant que quelques places et transitions. La composition de réseaux de Petri élémentaires, puis la composition de réseaux de Petri remplaçant des réseaux initia~x ayant été
précédemment composés, permet de modéliser finalement un ensemble -6- 2~73~3 d'automates bsaucoup plus complexe que celui qui pourrait être modélisé par un réseau de Petri global, ou par un langage de description formelle reposant sur la modélisation par automates.
Le procédé ainsi caractérisé permet de concevoir un ensemble d'automates communicants en réalisant une analyse exhaustive des réseaux de Petri modélisant ces automates, sans nécessiter un temps de calcul et une capacité de mémoire ayant des valeurs prohibitives, parce que la vérification des propriétés souhaitées est faite par étapes, au fur et à mesure de la composition des 10 réseaux de Petri initiaux, et sans aller Jusqu'à un réseau de Petri modélisant l'ensemble des automates.
L'implémentation d'un automate obtenu par le procédé selon l'invention consiste à écrire une suite d'instructions pour chaque transition de réseau de Petri élémentaire. Le nombre de transitions 15 est plus élevé que celui obtenu par une modélisation par un réseau de Petri unique, à cause des compositions de réseau. Ce nombre élevé de transitions facilite l'écriture des suites d'instructions correspondant à des actions associée~ aux transitions, puisque l'augmentation du nombre des transitions corre6pond à une 20 6implification des actions associées aux transitions. Autrement dit, chaque action est réalisée au mo;yen d'un plus petit nombre d'instructions. Ces suites d'instructions ont en plus l'avantage d'avoir un déroulement linéaire, c'est-~-dire sans branchement.
Elles sont donc faciles ~ mettre au point.
La validation du logiciel implémentant cet ensemble d'automates est simple car, la cohérence des états et des transitionc ayant ét~ vérifiée avant l'implantation sur la machine cible, il ne reste qu'à vérifier les suites d'instructions correspondant à des actions associées aux transition~.
Le test est simple puisqu'il peut, lui aussi, être fait par étape. Il consiste à produire des suites de ~ranchissements de transitions en par~ourant de façon co~plète l'ensemble de transitions de l'automate derivé du réseau de Petri obtenu pour chaque automate et pour chaque communication. Ces suites de franchissements de transitions peuvent être éventuellement réduite~
-7- ~ Q ~
ensuite, selon des critères de sélection, afin de réduire le nombre de tests.
Le procédé ainsi caractérisé a enfin pour avantage de faciliter la maintenance d'un ensemble d'automates ayant été consus ~ l'aide de ce procédé. Toute modification ou extension de cet ensem~le d'automates ne doit pas dé8rader la cohérence de l'ensemble. Pour que cette condition soit remplie, il est nécessaire de reprendre la mise en oeuvre du procédé selon l'invention, dès son point de départ, c'est-~-dire dès la description des réseaux de Petri élémentaires initiaux. Ceci peut sembler être une contrainte, à première vue, mais en fait ceci garantit la qualité du logiciel o~tenu finalement après ces opérations de maintenance.
Selon une autre caractéristique, pour réaliser des 15 compositions par le mode de communication synchrone, le procédé
selon l'invention consi6te à fusionner toutes les transitions appartenant à deu~ réseaux à composer et dont les étiquettes comportent un même événement qui est :
- soit con~équence de l'une des transitions et déclencheur d'une autre transition;
- soit conséquence commune des transitions;
- soit déclencheur commun des transitions.
Selon une autre caractéristique, pour réaliser des compositions par le mode de communication asynchrone, le procédé
selon l'invention consiste à :
- relier un premier et un deuxième réseau à composer, par une file dans chaqua sens de communication;
- imposer des contraintes temporaires sur le protocole de communication utilisant ces deux files, pendant la durée de la vérification des propriétés souhaitées du réseau ré ultant de la composition des deux réseaux à composer et des deux files.
Selon une autre caractéristique, pour réaliser des compositions selon le mode de communication pseudo-synchrone, le procédé selon l'invention consiste à :
2 ~ 3 - relier ces réseaux par une file unique possédant une pluralité d'entrées reliées respectivement à une sortie de chacun des réseaux à composer, et une pluralité de sorties reliées respectivement ~ une entrée de chacun des réseaux à composer;
imposer une contrainte permanente consistant à donner la priorité aux évènements en provenance de cette file, par rapport aux évènements en provenance des interfaces extérieures au réseau obtenu, pour le déclenchement de transitions dans les réseaux à
composer;
- imposer des contraintes temporaires inter-réseaux, uniquement pendant la durée de la vérification des propriétés souhait~es du réæeau de Petri modélisant le comporte~ent d'un automate, et consistant à ajouter des conditions pour le déclenchement de transitions d'un réseau à composer, ces conditions 15 portant sur 1'état des autres réseaux ~ composer, et correspondant au comportement de l'environnement du ré6eau ré3ultant.
Selon un mode de mise en oeuvre préférentiel, et si tous les réseaux de Petrl initiaux comportent chacun au plus une interface externe à un automate, la composition des réseaux élémentaires initiaux est réalisée en trois étapes successives, dans cet ordre :
- une première étape consistant à : composer des réseaux deux à deux par 1P mode de communical;ion synchrone, pour obtenir des réseaux de Petri remplaçant des réseaux initiaux et comportant au plu9 une interface externe ~ un automate;
vérifier que les réseaux obtenus ont des propriétés souhait~es; et recommencer la première étape pour les réseaux qui ont été composés et dont le r~seau réæultant n'a pas les propri~tés souhaitées;
- une deuxième étape consistant, pour chaque interface externe ~ un automate, a : composer deux à deux par le mode de communication asynchrone des réseaux de Petri issus de la première étape et ayant en commun une interface inter-automates ou externe à l'ensemble d'automates, pour obtenir lors de chaque composition un réseau de Petri modélisant une communication entre deux interfaces inter-automates ou entre une interfa~e externe à un automate et l'environnement de l'automate; vérifier que les réseaux obtenu~ ont des propri~té souhaitées; et recommencer la première etape pour les réseaux qui ont été composés et dont le réseau résultant n'a pas les propri~tés ~ouhaitée~;
une troisième étape consistant ~ : réaliser, pour chaque automate, une eomposition par le mode de communication pseudo-syn~hrona, pour composer des réseaux de Petri issus de la premi~re étape et validés par la deuxième étape, en tenant compte des contraintes inter-réseaux initiaux correspondant au comportement de l'extérieur ~ l'ensemble, pour obtenir un réseau de Petri modélisant le comportement de eet automate, notamment les communications entre les réseaux i8~UB de la premiare ~tape; ~érifier que les ré~eaux obtenus ont de~ propriétés souhaitées; et recommencer la premi~re et la deu~ième ~tape pour les réseaux qui ont été
composés et dont le réseau r~sultant n'a pas les propriét~s souhaitées ;
Ce mode de mise en oeu~re du procédé selon l'invention réduit les probl~mes de mise au polnt d'~m ens~!mble d'automates parce-que 20 la première étape permet de composer tous les ré~eaux initiaux qui sont rattaché~ ~ une même inter~ace inter-automates ou à une m~me intarface externe d'un automate, ou qui ont en commun de n'être rattachés à aucune lnterface, ce qui permet de rendre ind~pendants les problames de mise au point de chaque communicatlon entre un 25 automate et son environnement. La deuxième étape permet de résoudre ces probl~me~ ind~pendamment pour chaque communication. La troisiame ~tape perMet d~ mettre au polnt les commuDications internes à un aut~mate lnd~pendamment des autres aut~mates.
D'autre détails de la mise en oeuvre du procéd~ selon 30 l'invention appara~tront dan~ la description ci dessous et ~ l'alde des ~igures l'accompagnant :
- la figure 1 représente un organigramme d'un exemple de mi~e en oeuvre du proc~d~ selon l'invention;
- la figure 2 repr~sente sch~matiquement un exemple de -lo- ~ 3 transition et l'étiquette qui lui est attribuée;
- les figures 3 à 6 illustrent le mode de communication synchrone qui est utilisé pour composer des réseaux de Petri;
- la figure 7 illustre la composition de deux réseaux de Petri par le mode de communication asynchrone;
- la figure 8 illustre la composition de trois réseaux de Petri par le mode de communication dit pseudo-synchrone;
- les figures 9~ lOa, et lOb illustrent le mode de mise en 10 oeuvre préférentiel comportant trois étapes successives au cours desquelles sont utilisés successivement les modes de communication : synchrone, asynchrone, pseudo-synchrone.
La figure 1 représente un organigramme d'un exemple de mise en oeuvre du procédé selon l'invention, sous la forme d'un logiciel 15 implanté dans une machine de dé~eloppement constituée d'un ordinateur classique à usage général. L'écriture de ce logiciel ~
partir de la description ci-dessous est ~ la portée de l'Homme de l'Art. Cet exemple de mise en oeuvre est utilisé, par exemple, pour développer un ensemble d'automates communicants constituant une application de traitement d'appels d'un centre de commutationO
Chaque fonction sera décrite par un autornateO
Une premiare étape 1 de l'organLgramma consiste ~ ~aire décrire, par le concept~ur, chaque fonction de l'application sous la forme de comportements partiels modé.Lisés chacun par un r~seau de Petri él~mentaire initial 3, sous la forme d'interfaces 4, inter-automates ou externes à 1'ensemble d'automates, sous la forme de contraintes inter-r~seaux initi~ux et sou~ la forme de propriétés souhaitées, spécifiques pour chaque automate. Pour appliquer le mode de mise en oeu~re préférentiel du procéd~ ~elon l'invention, le concepteur prend soin de modéliser chaque comportement partiel par un réseau de Petri élémentaire initial n'ayant qu'une seule interface, ou aucune interface externe ~ un automate. Chaque r~seau de Petri initial ayant une interface externe respecte des contraintes imposées par des interfaces externes à l'ensemble d'automates ou par des interfaces 2 ~ 3 inter-automates. La définition de chaque réseau initial correspond généralement à une phase d'une communication. Les contraintes inter-réseaux initiaux corespondent, pour chaque automate, au comportement de l'environnement ext~rieur à 1'ensemble.
Au moment de faire réaliser, par la machine de développement, chaque composition de réseaux de Petri, le concepteur indique à la machine de développement quels réseaux il souhaite composer et selon quel mode de communication, 2.
Au cours de la description initiale le concepteur décrit aussi des données complémentaires 5 concernant les actions associées aux transitions et qui seront nécessaires au moment au moment de l'implémentation du logiciel concrétisant l'ensemble d'automates qui va être développé.
L'étape suivante consiste en une première analyse 9 pour 15 vérifier la consistance des réseaux de Petri initiaux. Elle vérifie les propriétés minimales et clasBique6 d'un réseau de Petri : Il doit être borné, vivant, propre, et sans blocage. Si l'un des réseaux initiaux n'a pas toutes ces propriétés, la machine de développement le signale au concepteur pour qu'il rectifie la description initiale de~ comportements partiels.
La description initiale 1 de chaque réseau de Petri consiste aussi à décrire pour chaque transition de ce réseau, les évènements déclencheurs de cette tran~ition et les évènements conséquences de cette transition. Cette description est réalisée de manière tr~s concise, 80U8 la forme d'une ét~quette attribuée à chaque tranRition, en inscrivant ces évènements les uns à la suite des autres et en faisant précéder chacun d'un symbole, ? ou !, indiquant respectivement si c'est un évènement déclencheur ou si c'est un év~nement conséquence de la transitlon.
La ~igure 2 représente ~ titre d'exemple une transition et son étiquette ?M1 IM2 !M3 IM4. Cette étiquette signifie que la transition est déclenchée par l'évènement M1 et qu'elle a pour conséquences des évènements M2, M3, M4. Comme il appara~tra plus loin, la comparaison entre les étiquettes respectives de deux transitions de deux réseaux différents permet de savoir quels sont 7 3 ~ ~ 3 leurs interactlons. Ces étiquettes sont donc une représentation de la communication entre des transitions n'appartenant pas à un mam0 réseau de Petri. Elles sont utilisées par la machine de développement, pour composer des réseaux de Petri, désignés par le concepteur, lorsque le concepteur veut établir une communication entre des réseaux ~ composer.
Sur la figure l, la mise en oeuvre du procédé selon l'invention consiste ensuite à faire réaliser par la machine de développement une série de compositions 7 et d'analyses 9. Chaque composition 7 étant suivie d'une analyse 9 du réseau résultant 8, qui fournit un graphe d'acce~sibilité ll et vérifie les propriétés lO du réseau résultant, et les confronte aux propriétés souhaitées 4.
Pour faciliter la véri~ication de propriétés spécifiques de 15 réseaux r~sultant de la composition de réseaux, le procédé
consiste, en outre, ~ repérer certains évènements au moment où le concepteur décrit les reseaux de Petri initiaux. Les évènements ainsi rep~rés, 80nt éliminés du graphe d'accessibilité ll, ce qui permet d'en réduire la taille9 et facilite son interprétation par le concepteur.
Lorsque les trois étapes du procédé ont été réalisés avec succès, le procédé d'aide à la conception peut être suivi d'une implémentation 12 de l'ensemble des automates ayant été ainsi conçu~ et analysés. Cette impl~mentation consiste ~ faire correspondre des tâches logicielles a~x transitions d'un graphe d'accessibilité. La machine de développement décrit les transitions SOU8 la form~ de tableaux de données structurées 13. Ces transitions pouvent être activées par un logiciel clas~ique interprate d'automate ou interpr~te multi-automates, implanté sur la machine cible. La taille des table~ de descriptions du graphe d'accesæibilité e~t genéralement prohibitive lorsqu'on considère le graphe d'accessibilit~ du ré~eau de Petri modélisant chaque automate de l'ensemble d'automates E. Il est donc préf~rable de décrire plut8t les graphes d'accessibilit~ de plusieurs sous-automates constituant un automate pour obtenir des tables de -13- 2~ 9~3 descriptions ayant des tailles raisonnables. Les contraintes inter-réseaux initiaux, lesquelles sont représentées par des contraintes entre sous-automates, ne sont pas implémentées car elles existent déjà dans l'environnement extérieur à l'ensemble.
Dans le cas de l'implémentation de plusieurs sous-automates~ il est nécessaire de prévoir un mécanisme de synchronisation entre les di~férents sous-automatss, en utilisant une file interne spéci~ique pour cette sy~chronisation. Cette ~ile est celle utilisée pour la composition des sous-automates et décrite plus loin en réf~rence à
la figure 8.
Par ailleurs, le concepteur implémente chaque action 5 par une suite d'instructions, la machine de développem~nt identifie cette suite d'instructions 14, en mettant en commentaire le nom de la transition qui correspond à cette action.
Lorsque le logiciel a été codé et compilé, il est validé de manière classique au moyen de jeux de t0st 16 qui sont des séquences d'évènements déterminés à partir des graphes d'accessibilité :
- soit des modèles représentant les différents automates 20 constituant l'ensemble E;
- soit des mod~les repr~sentant les di~férents sous-automates constituant chaque automate.
Acces~oirement l'implémentation 12 produit aussi une documentation 15 en vue de l'utilisation des logic1els implémentant l'ensemble d'automates ayant été consu.
ConBid~ron8 plu8 en détails les compocitions 7. Chaque composition con~iste ~ composer plusieurs réseaux de Petri. Mais selon le mode de mise en oeuvre pré~érentiel, dans une première étape, toutes les opérations de composition sont réalisées par le ~o mode de communication synchrone et composent exclusivement :
- soit deux r~seaux initiaux;
- soit un réseau initial et un réseau remplaçant des ré~eaux initiaux ayant été composés précédemment;
- soit deux réseaux remplaçants.
En outre, au cours de cette première étape, les r6seaux de -14- 2~3~}~J~-~
Petri resultant de ces compositions doivent comporter au plus une interface externe ~ un automate.
Le mode de communication synchrone consiste ~ fusionner au moins deux transitions appartenant aux deux reseaux de Petri à
compoæer et ayant un m8me evènement en commun dans leurs étiquettes. Les figures 3 à 5 illustrent ces trois types possibles de fusion de transitions. Le concepteur choisit l'un de ces trois types pour chaque fusion.
La figure 3 illustre un premier ~ype de fusion F1. Si un réseau de Petri R1 poss~de une transition qui a pour conséquence l'évènement M et si le r~seau R2 possade une transition qui a pour déclencheur l'evènement M, ces deux ré~eaux peuvent être fusionnés par le type de fusion F1 pour constituer un réseau R3 possédant une transition résultant de la fusion des deux transitions considérées.
La figure 4 illustre un second type de fusion F2. Si un réseau R4 possède une transition déclenchée par un évènement M et si un réseau R5 possede une transition déclenchée, elle aussi, par l'évènement M, ces deux réseaux peuvent être fusionnés en un réseau R6 poss~dant une transltion résultant de la fusion des deux transitions considérées et qui est déclenchée par l'évènement M.
La figure 5 illustre un troisième type de fusion F3. Si un ré~eau R7 possède une transition ayant pour conséquence un évènement M et si un r~seau R8 possède une transition qui a, elle aus~i, pour conséquence l'évènement M, alors ces deux réseaux peuvent être fusionnés pour constituer un réseau de Petri R9 pos~édant une transition qui a pour cons8quence l'év~nement M.
Lorsque chacun des réseaux ~ composer possède plus d'une tran~ition qui est 1R conséquence ou le déclencheur d'un même évènement, le réseau remplasant les réseaux composés possade des 30 transitions ré~ultantes qui sont répliqu~es à cause de la composition deux R deux des transitions des réseaux R composer.
La figure 6 illu~tre ce cas. Sl un réseau RlO poss~de deux transitions tl, t2 qui ont pour déclencheur un m8me évanement M et si un réseau R11 possède deux tran6itions ta, tb qui ont pour cons~quence le même ~v~nement ~, alors il e~t possible de fusionner -15- 2 ~ 3 ces transitions deux à deux par le type de fusion Fl et d'obtenir un réseau résultant R12 comportant quatre transitions tla, tlb, t2a, t2b.
Comme représenté sur la figure 1~ apres chaque composition 7, un réseau résultant 8 subit une analyse 9 qui consiste à vérifier, lO, que les propriétés obtenues correspondent aux propriétés 4 souhaitées par le concepteur, et à déterminer un graphe d'accessibilité 11. La détermination 11 du graphe d'accessibilité
et la vérification lO des propriétés sont réalisées simultanément par ia machine de développement, selon des procédés de calcul classiques po~ des réseaux de Petri. Cette analyse est dynamique et exhaustive, c'est-~-dire recherche tous les états et touteæ les transitions possibles dans le réseau résultant de la composition.
Elle déduit de ce graphe les propriétés générales de ce réseau et notamment vérifie s'il est : borné, sauf, vivant, propre, et sans blocage.
Elle détermine en outre si le réseau a les propriétés spécifiqueY ~ouhait~es recherchées par le concepteur. Si le réseau a toutes les propri~tés spécifiques souhait~es, la mise en oeuvre du procédé peut être poursuivie. Dans le cas contraire, la machine de développement indique au concepteur quelles sont les propriét~s qui ne sont pas vérifiées. Le concepteur modifie la description des réseaux initiaux pour y remédier. D'autre part, le graphe d'accesibilit~ 11 peut être r~utilisé pour des compositions ultérieures avec d'autres r~seaux de Petri, soit initiaux, soit résultant de composition précédemment réalis~es.
Selon le mode de mise en oeuvre préférentiel, une deuxième étape, pour les compositions 7 de réseaux de Petri, consiste pour chaque interface externe à l'ensemble d'automRtes et pour chaque 30 interface inter-automates, à réaliser des compositions par le mode de communication asynchrone pour composer de~ réseaux de Petri remplasant des réseaux initiaux, entre eux ou a~ec un réseau initial éventuellement subRistant, pour obtenir lors de chaque composition un réseau de Petri modélisant une communication entre deux automates ou entre une interfac~ externe à un automate et ~16- 2~3~
l'environnement de cet automate.
Chacun des réseaux de Petri obtenus à la fin de la première étape représente le comportement d'un sous-automate constituant une partie de l'un des automates ~ concevoirl même s'il s'agit d'un réseau initial subsistant.
Toutes les opérations de composition réalisées au cours de la deuxième étape sont réalisées au moyen de deux files, une dans chaque sens de communication. Ces deux files sont du type "pr~mier entré, premier sorti", et sont incorporées au réseau résultant. Ce 10 mode de communication est utilisé pour pouvoir analyser des dialogues asynchrones entre réseaux de Petri, et plus particulièrement pour analyser des protocoles de communication.
La figure 7 illustre le mode de communication asynchrone, dans un exemple où deux réseaux R13 et R14 sont mis en communication au 15 moyen de deux ~iles référencées FIF01 et FIF02, une pour chaque sens, pour constituer un réseau résultant RR. Pour mieux analyser la communication asynchrone entre les deux ré~eaux, des contraintes sur la communication peuvent consister ~ impo~er : des pertes de signaux ou des débordements de temporisation; ou une certaine 2G synchronisation temporaire, selon une transmission en alternat entre le~ deux réseaux; ou bien une limitation temporaire du nombre d'évanements ~tockés en attente dans chacune des deux files. Ces contraintes ~ont int~grées automatiquement aux réseaux de Petri, par la machine d'aide au développemement, sous la commande du concepteur. Il est à la port~e d0 l'hom~e de l'art de réaliser un programme, pour cette machine de développement, mettant en oeuvre cette caractéristique du procéd~ selon l'invention.
Selon le mode de mise en oeuvre préférentiel du procédé selon l'invention, les compositions de réseaux comportent une troisiame étape consistant à r~aliser des compositions uniquement par le mode de communication pseudo-synchrone, pour composer les réseaux de Petri ~ournis par la premiètre étape. Le mode de communication p~eudo-synchrone est obtenu au moyen d'une seule flle du type "premier entré premier sorti", et en donnant une priorité aux transitions déclenchées par des évènements conséquences de transi--17- 2 ~ 7 ~
tion~ internes aux réseaux à composer, par rapport aux transltions déclenchée6 par des évènements externes à ces réseaux.
Cette priorité ainsi que la file garantissent une co~munication synchrone ~ l'extérieur du réæeau résultant mais 5 maintlennent une communication asynchrone à l'intérieur du réseau résultantO
La figure 8 illust~e la communication pæeudo-synchrone. Elle représente un réseau de Petri R18 résultant de la composition de troi~ réseaux de Petri Rl5, R16, R17 au moyen d'une file de type 10 "premier entré premier sorti" référencée FIF05 et qui est incorporée au réseau résultant R18. Ce r~eau résultant possède une interface le rellant au reste de l'ensemble d'automate6 et le reliant ~ l'ext~rieur de l'ensemble, constituée par exemple d'une - file d'entrée référencée FIF03 et d'une file de sortie référencée 15 FIF04. La file FIF05 comporte trois entrées reli~es re~pectivement ~ trois sortie6 de6 r~seaux R15 à Rl7 et troi6 sortie~ reli~es respectivement à trois entrées des r~eaux R15 à Rl7. Chaque évanement qui est la conséquence d'une transition dans l'un des ré~eaux Rl5, R16, R17 et qui e~t le déclencheur d'une autre 20 transition dans l'un de ces réseaux transite par la file d'attente FIF05. Ces év~nements vont donc réagir sur les réseaux R15, R16, R17 dans l'ordre où ils sont inscrits dans la fil0 d'attente FIF05.
Cette file, et la priorit~ selon laquelle elle est ~erée, maintiennent 8ynchrcne la co~munication vis ~-vis des év~ne~ents 25 externes au r~seau r6sultAnt R18.
Dan~ cet exemple, le réseau Rl5 co~porte une transition d~clench~e par l'~vènement Il et ayant pour con6~quence l'évanement I2. Le r~seau R16 possède una première transition déclench~e par un év~nement qui est un mes~age MES1 reçu par l'interface et cette 30 transition a pour conséquence un évanement I1. Le r~seau R1~
po~sède une 6econde transition déclenchée par un évènement qui est un message ~ES2, et qui est sans conséquence. Le réseau R17 possède une transition qui est d~clenchée par l'évènement I2 et qui a pour conséquence un év~nement constitué par un mes6age MES30 Sur la figure ~, les chif~res entre parenthè~es indlquent -18- 2 ~ 3 l'ordre de déclenchement des transitions conformément à la règle de priorité. A l'instant considéré, les messages MESl et MES2 viennent d'8tre inscrits dans la file d'entrée FIF03 de l'interface du réseau résultant R18. La première transition du réseau R16 est déclenchée par le message MESl qui est lu en premier dans la file d'entrés FIF03. Cette transition a pour conséquence l'évanement I1. Ce dernier déclenche 1mmédiatement la transition du réseau R15 car il est prioritaire par rapport à la lecture du message M~S2. Cette transition, qui est la deuxième transition depuis 1'arrivée des messages, a pour conséquence l'évènement I2.
L'évènement I2 est lui aussi prioritaire par rapport à la lecture du message MES2. Il déclenche la transition du réseau ~17, qui a pour cons~quence un évène~ent qui est 1'émission d'un message MES3 qui est inscrit dans la file de sortie FIF04. Il n'y a plu8 15 d'interaction interne possible pour le moment, la règle de priorité
autorise à lire le prochain message MES2, qui est stocké dans la file d'entrée FIF03. Ce message MES2 est un évènement qui déclenche la seconde transition du réseau R16. L'ordre de prise en compte des messages externe~ est donc finalement : MES1, MES3, MES2. Le 20 message MES2 ne déclenche la seconde transition du réseau R16 qu'après que le message MESl ait ~ité complètement traité, c'est-à-dire apr~ avoir déclench~ la première transition de R16 puis la transition da R15 puis la transition de R17. La communication entre les réseaux R15, R16, R17 est donc globalement asynchrone a l'int~rieur du réseau résultant R18, mais la communication est synchrone avec 1'extérieur.
Les figures 9, lOa, et lOb illustrent un exemple de mise en oeuvre du proc~d~ s~lon l'invention, selon le mode pr~férentiel, pour aider au développement d'un ensemble d'automates communicants
3 o E, cet ensemble comportant deæ interfaces externes I1, I2, I3 et des interfaces internes inter-automates I4 à I7. Les interfaces I1, I2, I3 sont respectivement des interfaces externes aux automates A1, A3, A2. Les automates Al et A3 sont reliés par llinterface inter-automates I7. Les automates A2 et A4 sont reli~s par 3 5 1 ' interface inter-automates I4. Les automates A3 et A4 sont reliés par 1'interface inter-automates I5. Les automates A2 et A1 sont reliés par l'interface inter-automates I6.
Au départf le concepteur connaît les fonctions réalisées par les environnements de ces interfaces externes Il, I2, I3; et il conna~t la fonction que doit remplir chacun des automates de l'ensemble : Al, A2, A3, A4. La fonction de chacun de ces environnements et de ces automates est décomposable en comportements partiels. Le concepteur décrit chacun de ces comportements partiels au moyen d'un réseau de Petri élémentaire, 10 c'e6t-à-dire, ne comportant que quelques transitions et quelques places.
Cette description consiste à fournir à la machine de développement une étiquette pour chaque transition, cette étiquette contenant un évènement déclencheur et la liste des évènements lS conséquences de ~ette transition, notés de la façon décrite pr~cedemment en r~ference à la figure 2. En principe, il n'y a pas, dans un même réseau de Petri initial, deux transitions déclenchées au m8me instant par un m8me év~nement. Cependant la technique des réseaux de Petri et le procéd~ selon l'invention n'interdisent pas 20 de concevoir et d'utiliser un réseau de Patri initial comportant plusieurs transitions d~clenchables au même instant par un meme év~nement. Ces transitions sont dites ind~terministes. Il est cependant néces6aire que des conditions 6upplémentaires permettent de lever l'ind~termination du choix de déclenchement de ces transitions, au moment de l'impl~mentation de l'ensemble d'automates.
Le~ évanements qui constituent les étiquettes des réseaux de Pétri élémentaires initiaux ~ont : des évênements concrétisant les interfaces externes I1, I2, I3; des évènements concrétisant les 30 interfaces inter-automate~ I4 ~ I7; des évanements concrétisant des interfaces inter-réseaux initiaux; et des év~nements internes A un automate, réalisant un choix entre des transitions indéterministes.
Le concepteur fournit en sutre à la machine de développement une description de contraintes lnter-réseaux initiaux correspondant au comportement de l'environnement extérieur ~ l'ensemble ~20~ 3 3 d'automates E, et une description de propriétés souhaitées pour les réseaux de Petri élémentaires initiaux, mais aussi pour leæ réseaux de Petri résultant des compositions réalisées ultérieurem~nt. Ces propriétés souhaitees sont d'une part la consistance de chaque réseau de Petri, et d'autre part des proprités spécifiques à chacun de ces réseaux~
Le concepteur fournit aussi à la machine de développement une description de réseaux de Petri initiaux, modélisant respectivement les comportements de l'environnement extérieur à chacune des interfaces externes Il, I2, I3 de l'ensemble d'automates E.
Conformément au mode de mise en oeuvre préférentiel du procédé
selon l'inventlon, le concepteur conçoit les réseaux de Petri initiaux de telle ~orte que chacun comporte au plus une interface externe A un automate, et il commande la composition des réseaux initiaux selon la premi~re et la deuxième étapes décrites précédemment.
La figure 10, constitu~e de la réunion des figures lOa et lOb, représente schématiquement les réseaux de Petri initiaux et les opérations de compositlon réalisées pour concevoir l'ensemble 20 d'automates E représenté sur la figure 9. Les opérations de composition de la première étape sont toutes repérées par le chiffre 1', les operations de composition de la deuxième étape sont toutes rep~rées par le chiffre 2', et les op~rations de composition de la troisième étap~ sont toutes repéréeæ par le chiffre 3'.
~5 La premiare étape consiste à composer des r~seaux de Petri initiaux deux à deux par le mode de communication synchrone, et à
vérifier que les réseaux résultants ont les propriétes souhaitées, pour obtenir des ré~eaux de Petri comportant au plu8 une interface externe à un automate. Par exemple, dans 1'automate Al, dont les 30 comportements partiels sont modélisés par des réseaux de Petri élémentaires Bl ~ B13, la premiare étape consiste à :
- composer les réseaux initiaux Bl et B2, pour obtenir un réseau résultant Pl;
- compo~er le r~seau r~sultant Pl avec le réseau initial B3, pour obtenir un réseau r6sultant S2 qui a une interface unique, Il 7 avec l'extérieur à l'automate Al.
Tous les réseaux Bl, B2, B3 qui ont Il pour interface externe -21- 2~9~`~
ont été composés. Le réseau résultant S2 représente un sous-automate qui sera utilisé au cours de la deuxième étape du proc0dé .
La mise en oeuvre consiste ensuite à composer d'autres réseaux initiaux :
composer les ré eaux initiaux B4 et B5, pour obtenir un réseau résultant P2;
- composer les réseaux initiaux B6 et B7 pour obtenir un réseau résultant P3;
~o - composer les deux ré6eaux résultants P2 et P3, pour obtenir un r~seau résultant S3.
Tous les réseaux B4, B5, B6, B7 qui ont I6 pour interface externe à l'automate Al ont été composés. Le réseau résultant S3 représente donc un sous-automate.
La mise en oçuvre du procédé selon l'invention consiste ensuite à :
- composer les réseaux initiaux B8 et B9, pour obtenir un r~seau résultant P4;
- composer le réseau résultant P4 avec le réseau initial B6 20 pour obtenir un réseau résultant S5.
Tous leæ réseaux B8, B9, B10 qui ont I7 pour interface externe ont été composés. Le réseau résultant S5 représente donc un sous-automate.
La mise en ocuvre consiste ensuit;e à composer les réseaux initiaux B12 et B13, pour obtenir un ré~eau ré~ultant 54 qui n'a pas d'interface externe à l'automate Al. Il reste un réseau initial 811 qui n'a pas ~t~ compos~ mais, dan~ cet exemple, le concepteur choisit délib~rement de ne pas le compo~er. Le réseau résultant S4 et le réseau initial sub~istant Bll représentent eux aussi des 30 sous-automates, car ils font partie des réseaux issus de la première étape de la mise en oeuvre.
De manière analogue~ la première étape de mise en oeuvre consiste, pour l'automate A2, à :
- composer en deux étapes des réseaux de Petri élémentaires initiaux BZ5, B26, B27 pour obtenir un sous-automate S14 ayant une inter~ace IS externe à l'automate A2;
-22~ 3~
- composer deux réseaux de Petri élémentaires initiaux B28 et B29 pour obtenir un sous-automate S13 qui n'a aucune interface externe à l'automate A2;
- composer deux réseaux de Petri initiaux B30 et B31 pour obtenir un sous automate S12 qui a une interface I5 externe l'automate A2;
- composer en trois étapes les réseaux de Petri B32, B33, B34, B35 pour obtenir un sous-automate S15 possédant une interface I3 externe à l'automate A2, et externe à l'ensemble E;
Pour l'automate A3, la premi~re étape de la mise en oeuvre consiste à :
- compo~er les réseaux de Petri élémentaires initiaux B14 et B15 pour obtenir un sous-automate S7 possédant une interface I2 externe à l'automate A3, et externe à l'ensemble E;
- composer en deux ~tapes les réseaux de Petri élémentaires B16, B17, Bla pour obtenir un sou6-automate S8 possédant une interface I7 externe ~ l'automate A3;
~ composer les réseaux de Petri élémentaires initiaux Bl9 et B20 pour obtenir un sous-automate S9 possédant une interface I4 externe à l'automate A3.
Pour l'automate A4, la première étape consiste ~ :
- composer deu~ réseaux de Petri initiaux B21 et B22 pour obtenir un sous-automate S10 possédant une interface I4 externe à
l'automate A4;
~ composer deux réseaux de Petri elémentaires initiaux B23 et B24 pour obtenir un sous-automate Sll possédant une interface I5 externe à l'automate A40 Pour les environnements respectifs des interfaces Il, I2, I3 externes à l'ensemble d'automates E, la première étape consiste ~ :
- composer deux réseaux de Petri élémentaires B36 et B37, modéllsant respectivement de~ comportement~ partiels de 1'environnement extérieur ~ l'interface Il, pour obtenir un sous-automate Sl ayant une seule interface qui est cette interface Il;
- composer deux réseaux de Petri initiaux B38 et B39 qui -23- 2 ~ 3 ~
représentent re~pectivement des comportements partiels de l'environnement extérieur à l'interface I2 externe à l'ensemble E, pour obtenir un sous-automate S6 ayant une seule interface qui est cette interface l'interface I2;
- composer deux réseaux de Petri élémentaires B40 et B41 modélisant respectivement des comportements partiels de l'environnement extérieur à l'interface I3 externe ~ l'ensemble E, pour obtenir un sous-automate S16 ayant une ~eule interface constituée par l'interface I3.
La deuxième étape de la mise en oeuvre du procédé consiste, pour chaque interface externe à un automate, c'est-à-dire aussi bien les interfaces inter-automates que les interfaces externes à
l'ensemble E9 à : composer deux à deux par le mode de communication aæynchrone des réseaux S1 à S16 la premi~re étape, et ayant en 1S commun une interface inter-automates ou externe à l'ensemble d'automates; et à vérifier que le réseau obtenu a les propriétés souhaitées par le concepteur. Le concepteur indique à la machine les deux réseaux à composer et indiqua qu'ils doivent être composés par le mode de communication asynohrone. Chaque composition ~ournit 20 un réseau de Petri r~sultant qui modélise la communication entre deux interfaces inter-automates ou entre une interface externe à un automate et l'environnement de cet automate. Si la machine de développement constate que le r~s0au résultant d'une composition n'a pas les propri~tés souhait~es pour ce réseau, ell0 le signale au concepteur et celui-ci doit modifier certains réseaux de Petri initiaux et relancer la première étape, pour les réseaux qui ont ét~ composés et dont le réseau résultant n'a pas les propriété6 souhaitees.
Dans cet exemple, la deuxième étape consiste donc a :
compo~er le sous-automate S1 qui modélise l'environnement extérieur à l'inter~ace I1 externe ~ l'ensemble E, et le sous-automate S2 de l'automate A1, pour obtenir un réseau résultant RC1 modélisant une communication entre A1 et l'ext~rieur l'ensemble E~ par l'interface externe I1;
3S - composer le sous-automate S6 modélisant l'environnement extérieur à l'interface I2, avec le sous-automate S7 de l'automate A3, pour obtenir un réseau résultant RC2 modélisant la communication entre A2 et l'extérieur à l'ensemble E, par l'interface I~;
- composer le sous-automate S16 modélisant l'environnement extérieur ~ l'interface I3, avec le sous-automate S15 de l'automate A2, pour obtenir un réseau résultant RC6 modélisant la communication de A2 avec l'extérieur à l'ensemble E, par l'interface I3;
- composer le sous-automate S5 de 1'automate A1 avec le sous-automate S8 de l'automate A3 pour obtenir un réseau résultant RC3 modelisant la communication par l'interface I7 entre les automates A1 et A3;
- composer le sous-automate S9 de l'automate A3 avec le 15 sous-automate SlO de l'automate A4 pour obtenir un réseau résultant RC4 modélisant la communication par l'interface I4 entre les : automates A3 et A4;
- composer le sous-automate S11 de l'automate A4 avec le sous-automate S12 de l'automate A2, pour obtenir un réseau 20 résultant RC5 modélisant la communicatlon par l'interface I5 entre les automates A2 et A4;
- composar le sous-automate S14 de l'automate A2 avec le sous-automate S3 de l'automate A1, pour obtenir un réseau r~sultant RC7 modélisant la communication par l'interface I6 entre les automates A1 et A2.
Lorsque tous les réseaux résultants iS~U8 de la deuxième étape pos~èdent les propriétés souhaitées par le concepteur, la communication inter-automate~ et la communication avec l'environnement ext~rieur ~ l'ensemble E peuvent être consid~rées 30 comme validées. Le concepteur passe alors ~ la mise en oeuvre de la troisième ~tape~ Celle-ci consiste à réaliser des compositions par le mode de communication pæeudo-synchrone, pour composer des réseaux de Petri modélisant des sous-automates i8SUB de la premiere étape et validés par la deuxième étape, 3usqu'à obtenir pour chaque automate, un réseau de Petri modelisant la fonction de cet -25- 2 0 7 ~ n~t~
automate, notamment les communications entre les sous-automates qui constituent cet automate. Les réseaux de Petri Sl, S6, Sl6 ont été
utilisés pour modeliser les communications avec l'extérieur à
l'ensemble, mais ils ne font pas partie de l'ensemble d'automates Al,...,A4. Ils ne sont donc pas considérés au cours de cette troisième étape.
Dans cet exemple, la troisième étape consiste ~ :
~ composer les sous-automates S2, S3, S4, S5, et Bll pour obtenir un réseau de Petri résultant modélisant l'ensemble de l'automate Al;
- composer les sous-automates S7, S8, S9, pour obtenir un réseau résultant modélisant l'automate A3;
- composer les sou~-automates SlO et Sll pour obtenir un réseau r~sultant modélisant 1'automate A4;
- composer les ous-automates Sl2, Sl3, Sl4, Sl5, pour obtenir un réseau ré~ultant modélisant 1'automate A2.
Lorsque tous les réseaux rssultant de cette troisième étape ont ef~ectivement les propriétés souhaitées par le concepteur, la mlse au point des automates peut être considérée comme terminée. Il 20 ne reste plu8 qu'à implémenter C08 automates. Cette implémentation est réalisée de pré~érence en lmplémentant les sous~automates, plutôt que les automates, sous la forme de tables de données structurées décrivant les transitions de ces sous-automates. Ces tables de donn~es sont d~duites, de manière classique, du graphe d'accessibilité déterminé au cours de l'analyse de chacun des r~seaux de Petri issus de la première ~tape et validés, pendant la deuxième étape de la mise en oeuvre du procédé selon l'invention.
L'implémentation consiste en outre ~ : implémenter les communications asynchrones et pseudo-synchrones, qui ont permis de 30 composer les réseaux au cours de la deuxième et de la troi~ième étape, sous la forme de suite d'instructions; et implémenter un moteur d'automate pour chaque automate, ce moteur utilisant ces tables de données et ces suites d'instructions pour concrétiser cet automate. La réalisat~on d'un logiciel implémentant ces moteurs d'automate est à la portée d'un Homme de l'Art.
~26- 2 ~ 3 La portée de l'inv0ntion n'est pas limitée ~ un ensemble d'automates concretisé par un logiciel. Un en~emble d'autom~tes développe à l'aide du procédé selon l'invention peut aussi 8tre concrétisé par un circuit logique c~blé ou microprogrammé.
s
Au départf le concepteur connaît les fonctions réalisées par les environnements de ces interfaces externes Il, I2, I3; et il conna~t la fonction que doit remplir chacun des automates de l'ensemble : Al, A2, A3, A4. La fonction de chacun de ces environnements et de ces automates est décomposable en comportements partiels. Le concepteur décrit chacun de ces comportements partiels au moyen d'un réseau de Petri élémentaire, 10 c'e6t-à-dire, ne comportant que quelques transitions et quelques places.
Cette description consiste à fournir à la machine de développement une étiquette pour chaque transition, cette étiquette contenant un évènement déclencheur et la liste des évènements lS conséquences de ~ette transition, notés de la façon décrite pr~cedemment en r~ference à la figure 2. En principe, il n'y a pas, dans un même réseau de Petri initial, deux transitions déclenchées au m8me instant par un m8me év~nement. Cependant la technique des réseaux de Petri et le procéd~ selon l'invention n'interdisent pas 20 de concevoir et d'utiliser un réseau de Patri initial comportant plusieurs transitions d~clenchables au même instant par un meme év~nement. Ces transitions sont dites ind~terministes. Il est cependant néces6aire que des conditions 6upplémentaires permettent de lever l'ind~termination du choix de déclenchement de ces transitions, au moment de l'impl~mentation de l'ensemble d'automates.
Le~ évanements qui constituent les étiquettes des réseaux de Pétri élémentaires initiaux ~ont : des évênements concrétisant les interfaces externes I1, I2, I3; des évènements concrétisant les 30 interfaces inter-automate~ I4 ~ I7; des évanements concrétisant des interfaces inter-réseaux initiaux; et des év~nements internes A un automate, réalisant un choix entre des transitions indéterministes.
Le concepteur fournit en sutre à la machine de développement une description de contraintes lnter-réseaux initiaux correspondant au comportement de l'environnement extérieur ~ l'ensemble ~20~ 3 3 d'automates E, et une description de propriétés souhaitées pour les réseaux de Petri élémentaires initiaux, mais aussi pour leæ réseaux de Petri résultant des compositions réalisées ultérieurem~nt. Ces propriétés souhaitees sont d'une part la consistance de chaque réseau de Petri, et d'autre part des proprités spécifiques à chacun de ces réseaux~
Le concepteur fournit aussi à la machine de développement une description de réseaux de Petri initiaux, modélisant respectivement les comportements de l'environnement extérieur à chacune des interfaces externes Il, I2, I3 de l'ensemble d'automates E.
Conformément au mode de mise en oeuvre préférentiel du procédé
selon l'inventlon, le concepteur conçoit les réseaux de Petri initiaux de telle ~orte que chacun comporte au plus une interface externe A un automate, et il commande la composition des réseaux initiaux selon la premi~re et la deuxième étapes décrites précédemment.
La figure 10, constitu~e de la réunion des figures lOa et lOb, représente schématiquement les réseaux de Petri initiaux et les opérations de compositlon réalisées pour concevoir l'ensemble 20 d'automates E représenté sur la figure 9. Les opérations de composition de la première étape sont toutes repérées par le chiffre 1', les operations de composition de la deuxième étape sont toutes rep~rées par le chiffre 2', et les op~rations de composition de la troisième étap~ sont toutes repéréeæ par le chiffre 3'.
~5 La premiare étape consiste à composer des r~seaux de Petri initiaux deux à deux par le mode de communication synchrone, et à
vérifier que les réseaux résultants ont les propriétes souhaitées, pour obtenir des ré~eaux de Petri comportant au plu8 une interface externe à un automate. Par exemple, dans 1'automate Al, dont les 30 comportements partiels sont modélisés par des réseaux de Petri élémentaires Bl ~ B13, la premiare étape consiste à :
- composer les réseaux initiaux Bl et B2, pour obtenir un réseau résultant Pl;
- compo~er le r~seau r~sultant Pl avec le réseau initial B3, pour obtenir un réseau r6sultant S2 qui a une interface unique, Il 7 avec l'extérieur à l'automate Al.
Tous les réseaux Bl, B2, B3 qui ont Il pour interface externe -21- 2~9~`~
ont été composés. Le réseau résultant S2 représente un sous-automate qui sera utilisé au cours de la deuxième étape du proc0dé .
La mise en oeuvre consiste ensuite à composer d'autres réseaux initiaux :
composer les ré eaux initiaux B4 et B5, pour obtenir un réseau résultant P2;
- composer les réseaux initiaux B6 et B7 pour obtenir un réseau résultant P3;
~o - composer les deux ré6eaux résultants P2 et P3, pour obtenir un r~seau résultant S3.
Tous les réseaux B4, B5, B6, B7 qui ont I6 pour interface externe à l'automate Al ont été composés. Le réseau résultant S3 représente donc un sous-automate.
La mise en oçuvre du procédé selon l'invention consiste ensuite à :
- composer les réseaux initiaux B8 et B9, pour obtenir un r~seau résultant P4;
- composer le réseau résultant P4 avec le réseau initial B6 20 pour obtenir un réseau résultant S5.
Tous leæ réseaux B8, B9, B10 qui ont I7 pour interface externe ont été composés. Le réseau résultant S5 représente donc un sous-automate.
La mise en ocuvre consiste ensuit;e à composer les réseaux initiaux B12 et B13, pour obtenir un ré~eau ré~ultant 54 qui n'a pas d'interface externe à l'automate Al. Il reste un réseau initial 811 qui n'a pas ~t~ compos~ mais, dan~ cet exemple, le concepteur choisit délib~rement de ne pas le compo~er. Le réseau résultant S4 et le réseau initial sub~istant Bll représentent eux aussi des 30 sous-automates, car ils font partie des réseaux issus de la première étape de la mise en oeuvre.
De manière analogue~ la première étape de mise en oeuvre consiste, pour l'automate A2, à :
- composer en deux étapes des réseaux de Petri élémentaires initiaux BZ5, B26, B27 pour obtenir un sous-automate S14 ayant une inter~ace IS externe à l'automate A2;
-22~ 3~
- composer deux réseaux de Petri élémentaires initiaux B28 et B29 pour obtenir un sous-automate S13 qui n'a aucune interface externe à l'automate A2;
- composer deux réseaux de Petri initiaux B30 et B31 pour obtenir un sous automate S12 qui a une interface I5 externe l'automate A2;
- composer en trois étapes les réseaux de Petri B32, B33, B34, B35 pour obtenir un sous-automate S15 possédant une interface I3 externe à l'automate A2, et externe à l'ensemble E;
Pour l'automate A3, la premi~re étape de la mise en oeuvre consiste à :
- compo~er les réseaux de Petri élémentaires initiaux B14 et B15 pour obtenir un sous-automate S7 possédant une interface I2 externe à l'automate A3, et externe à l'ensemble E;
- composer en deux ~tapes les réseaux de Petri élémentaires B16, B17, Bla pour obtenir un sou6-automate S8 possédant une interface I7 externe ~ l'automate A3;
~ composer les réseaux de Petri élémentaires initiaux Bl9 et B20 pour obtenir un sous-automate S9 possédant une interface I4 externe à l'automate A3.
Pour l'automate A4, la première étape consiste ~ :
- composer deu~ réseaux de Petri initiaux B21 et B22 pour obtenir un sous-automate S10 possédant une interface I4 externe à
l'automate A4;
~ composer deux réseaux de Petri elémentaires initiaux B23 et B24 pour obtenir un sous-automate Sll possédant une interface I5 externe à l'automate A40 Pour les environnements respectifs des interfaces Il, I2, I3 externes à l'ensemble d'automates E, la première étape consiste ~ :
- composer deux réseaux de Petri élémentaires B36 et B37, modéllsant respectivement de~ comportement~ partiels de 1'environnement extérieur ~ l'interface Il, pour obtenir un sous-automate Sl ayant une seule interface qui est cette interface Il;
- composer deux réseaux de Petri initiaux B38 et B39 qui -23- 2 ~ 3 ~
représentent re~pectivement des comportements partiels de l'environnement extérieur à l'interface I2 externe à l'ensemble E, pour obtenir un sous-automate S6 ayant une seule interface qui est cette interface l'interface I2;
- composer deux réseaux de Petri élémentaires B40 et B41 modélisant respectivement des comportements partiels de l'environnement extérieur à l'interface I3 externe ~ l'ensemble E, pour obtenir un sous-automate S16 ayant une ~eule interface constituée par l'interface I3.
La deuxième étape de la mise en oeuvre du procédé consiste, pour chaque interface externe à un automate, c'est-à-dire aussi bien les interfaces inter-automates que les interfaces externes à
l'ensemble E9 à : composer deux à deux par le mode de communication aæynchrone des réseaux S1 à S16 la premi~re étape, et ayant en 1S commun une interface inter-automates ou externe à l'ensemble d'automates; et à vérifier que le réseau obtenu a les propriétés souhaitées par le concepteur. Le concepteur indique à la machine les deux réseaux à composer et indiqua qu'ils doivent être composés par le mode de communication asynohrone. Chaque composition ~ournit 20 un réseau de Petri r~sultant qui modélise la communication entre deux interfaces inter-automates ou entre une interface externe à un automate et l'environnement de cet automate. Si la machine de développement constate que le r~s0au résultant d'une composition n'a pas les propri~tés souhait~es pour ce réseau, ell0 le signale au concepteur et celui-ci doit modifier certains réseaux de Petri initiaux et relancer la première étape, pour les réseaux qui ont ét~ composés et dont le réseau résultant n'a pas les propriété6 souhaitees.
Dans cet exemple, la deuxième étape consiste donc a :
compo~er le sous-automate S1 qui modélise l'environnement extérieur à l'inter~ace I1 externe ~ l'ensemble E, et le sous-automate S2 de l'automate A1, pour obtenir un réseau résultant RC1 modélisant une communication entre A1 et l'ext~rieur l'ensemble E~ par l'interface externe I1;
3S - composer le sous-automate S6 modélisant l'environnement extérieur à l'interface I2, avec le sous-automate S7 de l'automate A3, pour obtenir un réseau résultant RC2 modélisant la communication entre A2 et l'extérieur à l'ensemble E, par l'interface I~;
- composer le sous-automate S16 modélisant l'environnement extérieur ~ l'interface I3, avec le sous-automate S15 de l'automate A2, pour obtenir un réseau résultant RC6 modélisant la communication de A2 avec l'extérieur à l'ensemble E, par l'interface I3;
- composer le sous-automate S5 de 1'automate A1 avec le sous-automate S8 de l'automate A3 pour obtenir un réseau résultant RC3 modelisant la communication par l'interface I7 entre les automates A1 et A3;
- composer le sous-automate S9 de l'automate A3 avec le 15 sous-automate SlO de l'automate A4 pour obtenir un réseau résultant RC4 modélisant la communication par l'interface I4 entre les : automates A3 et A4;
- composer le sous-automate S11 de l'automate A4 avec le sous-automate S12 de l'automate A2, pour obtenir un réseau 20 résultant RC5 modélisant la communicatlon par l'interface I5 entre les automates A2 et A4;
- composar le sous-automate S14 de l'automate A2 avec le sous-automate S3 de l'automate A1, pour obtenir un réseau r~sultant RC7 modélisant la communication par l'interface I6 entre les automates A1 et A2.
Lorsque tous les réseaux résultants iS~U8 de la deuxième étape pos~èdent les propriétés souhaitées par le concepteur, la communication inter-automate~ et la communication avec l'environnement ext~rieur ~ l'ensemble E peuvent être consid~rées 30 comme validées. Le concepteur passe alors ~ la mise en oeuvre de la troisième ~tape~ Celle-ci consiste à réaliser des compositions par le mode de communication pæeudo-synchrone, pour composer des réseaux de Petri modélisant des sous-automates i8SUB de la premiere étape et validés par la deuxième étape, 3usqu'à obtenir pour chaque automate, un réseau de Petri modelisant la fonction de cet -25- 2 0 7 ~ n~t~
automate, notamment les communications entre les sous-automates qui constituent cet automate. Les réseaux de Petri Sl, S6, Sl6 ont été
utilisés pour modeliser les communications avec l'extérieur à
l'ensemble, mais ils ne font pas partie de l'ensemble d'automates Al,...,A4. Ils ne sont donc pas considérés au cours de cette troisième étape.
Dans cet exemple, la troisième étape consiste ~ :
~ composer les sous-automates S2, S3, S4, S5, et Bll pour obtenir un réseau de Petri résultant modélisant l'ensemble de l'automate Al;
- composer les sous-automates S7, S8, S9, pour obtenir un réseau résultant modélisant l'automate A3;
- composer les sou~-automates SlO et Sll pour obtenir un réseau r~sultant modélisant 1'automate A4;
- composer les ous-automates Sl2, Sl3, Sl4, Sl5, pour obtenir un réseau ré~ultant modélisant 1'automate A2.
Lorsque tous les réseaux rssultant de cette troisième étape ont ef~ectivement les propriétés souhaitées par le concepteur, la mlse au point des automates peut être considérée comme terminée. Il 20 ne reste plu8 qu'à implémenter C08 automates. Cette implémentation est réalisée de pré~érence en lmplémentant les sous~automates, plutôt que les automates, sous la forme de tables de données structurées décrivant les transitions de ces sous-automates. Ces tables de donn~es sont d~duites, de manière classique, du graphe d'accessibilité déterminé au cours de l'analyse de chacun des r~seaux de Petri issus de la première ~tape et validés, pendant la deuxième étape de la mise en oeuvre du procédé selon l'invention.
L'implémentation consiste en outre ~ : implémenter les communications asynchrones et pseudo-synchrones, qui ont permis de 30 composer les réseaux au cours de la deuxième et de la troi~ième étape, sous la forme de suite d'instructions; et implémenter un moteur d'automate pour chaque automate, ce moteur utilisant ces tables de données et ces suites d'instructions pour concrétiser cet automate. La réalisat~on d'un logiciel implémentant ces moteurs d'automate est à la portée d'un Homme de l'Art.
~26- 2 ~ 3 La portée de l'inv0ntion n'est pas limitée ~ un ensemble d'automates concretisé par un logiciel. Un en~emble d'autom~tes développe à l'aide du procédé selon l'invention peut aussi 8tre concrétisé par un circuit logique c~blé ou microprogrammé.
s
Claims (7)
1) Procédé d'aide au développement d'un ensemble (E) d'automates communicants (A1 à A4), ces automates comportant une pluralité d'interfaces qui traitent une pluralité de messages entrelacés; cet ensemble d'automates étant développé à partir d'interfaces externes à l'ensemble, d'interfaces (I1 à I3) inter-automates (I4 à I7), de la fonction que doit remplir chaque automate de cet ensemble, et de la fonction que remplit l'environnement extérieur à chaque interface externe à l'ensemble;
caractérisé en ce qu'il consiste à :
- fournir (1) à une machine de développement une description (3) de réseaux de Petri élémentaires dits initiaux, modélisant respectivement des comportements partiels de chaque fonction, en décrivant notamment des évènements déclencheurs ou conséquences de transitions dans chaque réseau de Petri initial en attribuant une étiquette à chaque transition, cette étiquette étant fonction d'au moins un évènement, chaque évènement étant un déclencheur ou étant une conséquence de cette transition; ces évènements concrétisant :
des interfaces externes à l'ensemble d'automates, des interfaces inter-automates, et des interfaces inter-réseaux initiaux;
- vérifier (9), au moyen de cette machine de développement, que chaque réseau initial possède des propriétés souhaitées (4);
- fournir (1) à cette machine de développement une description (4) de contraintes inter-réseaux initiaux, correspondant au comportement de l'environnement extérieur à l'ensemble d'automates;
- désigner (1) à cette machine de développement, une pluralité
de réseaux à composer et un mode de communication (2), pour lui faire composer (7) des réseaux de Petri initiaux, entre eux ou avec des réseaux de Pétri (8) remplaçant des réseaux initiaux ayant été
composés précédemment, ou bien composer des réseaux remplaçant des réseaux initiaux ayant été composés précédemment; chaque composition étant réalisée en faisant communiquer au moins deux réseaux, par l'intermédiaire des étiquettes de leurs transitions, selon le mode de communication (2) désigné, ce dernier étant choisi parmi :
- un mode synchrone;
- un mode asynchrone;
- un mode dit pseudo-synchrone, selon lequel les évènements constituant une communication avec l'extérieur au réseau résultant de la composition sont synchrones vis-à-vis de l'extérieur des réseaux à composer et sont asynchrones vis-à-vis de l'intérieur des réseaux à composer, chaque composition par le mode pseudo-synchrone tenant compte des contraintes inter-réseaux (4);
- puis vérifier (9, 10), au moyen de la machine de développement, que le réseau résultant de cette composition a des propriétés souhaitées (4);
- fournir (1) à la machine de développement une description (3) de réseaux initiaux modifiés, en remplacement de réseaux initiaux à composer, si le réseau (8) obtenu en composant ces dernier n'a pas les propriétés souhaitées (4) ;
- puis désigner (1) de nouveau à la machine de développement une pluralité de réseaux à composer (2) et un mode de communication (2) pour lui faire réaliser une suite de compositions (7) et de vérifications (9, 10), jusqu'à l'obtention de réseaux de Pétri, ayant des propriétés souhaitées (4), et modélisant respectivement :
chaque communication entre deux interfaces inter-automates (I4 à
I6) ou entre une interface externe (I1 à I3) et l'extérieur à
l'ensemble d'automates (E), et chaque automate (A1 à A4) de l'ensemble.
caractérisé en ce qu'il consiste à :
- fournir (1) à une machine de développement une description (3) de réseaux de Petri élémentaires dits initiaux, modélisant respectivement des comportements partiels de chaque fonction, en décrivant notamment des évènements déclencheurs ou conséquences de transitions dans chaque réseau de Petri initial en attribuant une étiquette à chaque transition, cette étiquette étant fonction d'au moins un évènement, chaque évènement étant un déclencheur ou étant une conséquence de cette transition; ces évènements concrétisant :
des interfaces externes à l'ensemble d'automates, des interfaces inter-automates, et des interfaces inter-réseaux initiaux;
- vérifier (9), au moyen de cette machine de développement, que chaque réseau initial possède des propriétés souhaitées (4);
- fournir (1) à cette machine de développement une description (4) de contraintes inter-réseaux initiaux, correspondant au comportement de l'environnement extérieur à l'ensemble d'automates;
- désigner (1) à cette machine de développement, une pluralité
de réseaux à composer et un mode de communication (2), pour lui faire composer (7) des réseaux de Petri initiaux, entre eux ou avec des réseaux de Pétri (8) remplaçant des réseaux initiaux ayant été
composés précédemment, ou bien composer des réseaux remplaçant des réseaux initiaux ayant été composés précédemment; chaque composition étant réalisée en faisant communiquer au moins deux réseaux, par l'intermédiaire des étiquettes de leurs transitions, selon le mode de communication (2) désigné, ce dernier étant choisi parmi :
- un mode synchrone;
- un mode asynchrone;
- un mode dit pseudo-synchrone, selon lequel les évènements constituant une communication avec l'extérieur au réseau résultant de la composition sont synchrones vis-à-vis de l'extérieur des réseaux à composer et sont asynchrones vis-à-vis de l'intérieur des réseaux à composer, chaque composition par le mode pseudo-synchrone tenant compte des contraintes inter-réseaux (4);
- puis vérifier (9, 10), au moyen de la machine de développement, que le réseau résultant de cette composition a des propriétés souhaitées (4);
- fournir (1) à la machine de développement une description (3) de réseaux initiaux modifiés, en remplacement de réseaux initiaux à composer, si le réseau (8) obtenu en composant ces dernier n'a pas les propriétés souhaitées (4) ;
- puis désigner (1) de nouveau à la machine de développement une pluralité de réseaux à composer (2) et un mode de communication (2) pour lui faire réaliser une suite de compositions (7) et de vérifications (9, 10), jusqu'à l'obtention de réseaux de Pétri, ayant des propriétés souhaitées (4), et modélisant respectivement :
chaque communication entre deux interfaces inter-automates (I4 à
I6) ou entre une interface externe (I1 à I3) et l'extérieur à
l'ensemble d'automates (E), et chaque automate (A1 à A4) de l'ensemble.
2) Procédé selon la revendication 1, caractérisé en ce que pour réaliser des compositions par le mode de communication synchrone , il consiste à fusionner toutes les transitions appartenant à deux réseaux à composer et dont les étiquettes comportent un même évènement (M) qui est :
- soit conséquence (!M) de l'une des transitions et déclencheur (?M) d'une autre transition;
- soit conséquence commune (!M) des transitions;
- soit déclencheur commun (?M) des transitions.
- soit conséquence (!M) de l'une des transitions et déclencheur (?M) d'une autre transition;
- soit conséquence commune (!M) des transitions;
- soit déclencheur commun (?M) des transitions.
3) Procédé selon la revendication 1, caractérisé en ce que pour réaliser des compositions par le mode de communication asynchrone, il consiste à :
- relier un premier et un deuxième réseau à composer (R13, R14), par une file (FIFO1, FIFO2) dans chaque sens de communication;
- imposer des contraintes temporaires sur le protocole de communication utilisant ces deux files, pendant la durée de la vérification des propriétés souhaitées du réseau résultant (RR) de la composition des deux réseaux à composer et des deux files.
- relier un premier et un deuxième réseau à composer (R13, R14), par une file (FIFO1, FIFO2) dans chaque sens de communication;
- imposer des contraintes temporaires sur le protocole de communication utilisant ces deux files, pendant la durée de la vérification des propriétés souhaitées du réseau résultant (RR) de la composition des deux réseaux à composer et des deux files.
4) Procédé selon la revendication 1, caractérisé en ce que pour composer une pluralité de réseaux (R15, R16, R17) par le mode de communication pseudo-synchrone, il consiste à
- relier ces réseaux par une file (FIFO5) unique possédant une pluralité d'entrées reliées respectivement à une sortie de chacun des réseaux à composer, et une pluralité de sorties reliées respectivement à une entrée de chacun des réseaux à composer;
- imposer une contrainte permanente consistant à donner la priorité aux évèneménts en provenance de cette file, par rapport aux évènements en provenance des interfaces (FIFO3, FIFO4) extérieures au réseau obtenu, pour le déclenchement de transitions dans les réseaux à composer;
- imposer des contraintes temporaires inter-réseaux, uniquement pendant la durée de la vérification des propriétés souhaitées du réseau de Petri modélisant le comportement d'un automate, et consistant à ajouter des conditions pour le déclenchement de transitions de l'un des réseaux à composer, ces conditions portant sur l'état des autres réseaux à composer, et correspondant au comportement de l'environnement du réseau résultant.
- relier ces réseaux par une file (FIFO5) unique possédant une pluralité d'entrées reliées respectivement à une sortie de chacun des réseaux à composer, et une pluralité de sorties reliées respectivement à une entrée de chacun des réseaux à composer;
- imposer une contrainte permanente consistant à donner la priorité aux évèneménts en provenance de cette file, par rapport aux évènements en provenance des interfaces (FIFO3, FIFO4) extérieures au réseau obtenu, pour le déclenchement de transitions dans les réseaux à composer;
- imposer des contraintes temporaires inter-réseaux, uniquement pendant la durée de la vérification des propriétés souhaitées du réseau de Petri modélisant le comportement d'un automate, et consistant à ajouter des conditions pour le déclenchement de transitions de l'un des réseaux à composer, ces conditions portant sur l'état des autres réseaux à composer, et correspondant au comportement de l'environnement du réseau résultant.
5) Procédé selon la revendication 1, caractérisé en ce que les réseaux de Pétri initiaux comportent chacun au plus une interface (I1 à I7) externe à un automate (A1 A4), et en ce que la composition des réseaux de Pétri élémentaires initiaux comporte trois étapes successives, dans cet ordre :
- une première étape consistant à : composer (1') des réseaux deux à deux (B1 à B41) par le mode de communication synchrone pour obtenir des réseaux de Pétri (S1 à S16) remplaçant des réseaux initiaux et comportant au plus une interface externe à un automate;
vérifier que les réseaux obtenus ont des propriétés souhaitée; et recommencer la première étape pour les réseaux qui ont été composés et dont le réseau résultant n'a pas les propriétés souhaitées;
- une deuxième étape consistant, pour chaque interface externe à un automate, à : composer (2') deux à deux par le mode de communication asynchrone, des réseaux de Pétri (S1 à S16, B11) issus de la première étape et ayant en commun une interface inter-automates ou externe à l'ensemble d'automates, pour obtenir lors de chaque composition un réseau de Pétri (RC1 à RC7) modélisant une communication entre deux interfaces inter-automates (I4 à I7), ou entre une interface (I1 à I3) externe à un automate et l'environnement de l'ensemble d'automates; vérifier que les réseaux obtenus ont des propriétés souhaitées (4); et recommencer la première étape pour les réseaux qui ont été composés et dont le réseau résultant n'a pas les propriétés souhaitées;
- une troisième étape consistant à : réaliser des compositions (3') par le mode de communication pseudo-synchrone, pour composer des réseaux de Pétri (S2 à S5 et B11, S7 à S9, S10 et S11, S12 à
S15) issus de la première étape et validés par la deuxiame étape, en tenant compte des contraintes inter-réseaux initiaux (4) correspondant au comportement de l'environnement extérieur à
l'ensemble, pour obtenir pour chaque automate (A1,...,A4) un réseau de Pétri modélisant la fonction de cet automate, notamment les communications entre les réseaux issus de la première étape;
vérifier que les réseaux obtenus ont des propriétés souhaitées; et recommencer la première et la deuxième étape pour les réseaux qui ont été composés et dont le réseau résultant n'a pas les propriétés souhaitées.
- une première étape consistant à : composer (1') des réseaux deux à deux (B1 à B41) par le mode de communication synchrone pour obtenir des réseaux de Pétri (S1 à S16) remplaçant des réseaux initiaux et comportant au plus une interface externe à un automate;
vérifier que les réseaux obtenus ont des propriétés souhaitée; et recommencer la première étape pour les réseaux qui ont été composés et dont le réseau résultant n'a pas les propriétés souhaitées;
- une deuxième étape consistant, pour chaque interface externe à un automate, à : composer (2') deux à deux par le mode de communication asynchrone, des réseaux de Pétri (S1 à S16, B11) issus de la première étape et ayant en commun une interface inter-automates ou externe à l'ensemble d'automates, pour obtenir lors de chaque composition un réseau de Pétri (RC1 à RC7) modélisant une communication entre deux interfaces inter-automates (I4 à I7), ou entre une interface (I1 à I3) externe à un automate et l'environnement de l'ensemble d'automates; vérifier que les réseaux obtenus ont des propriétés souhaitées (4); et recommencer la première étape pour les réseaux qui ont été composés et dont le réseau résultant n'a pas les propriétés souhaitées;
- une troisième étape consistant à : réaliser des compositions (3') par le mode de communication pseudo-synchrone, pour composer des réseaux de Pétri (S2 à S5 et B11, S7 à S9, S10 et S11, S12 à
S15) issus de la première étape et validés par la deuxiame étape, en tenant compte des contraintes inter-réseaux initiaux (4) correspondant au comportement de l'environnement extérieur à
l'ensemble, pour obtenir pour chaque automate (A1,...,A4) un réseau de Pétri modélisant la fonction de cet automate, notamment les communications entre les réseaux issus de la première étape;
vérifier que les réseaux obtenus ont des propriétés souhaitées; et recommencer la première et la deuxième étape pour les réseaux qui ont été composés et dont le réseau résultant n'a pas les propriétés souhaitées.
6) Procédé selon la revendication 5, caractérisé en ce que pour implémenter les automates, il consiste en outre à :
- implémenter (12) les réseaux issus de la première étape (S2 à S5 et B11 pour A1; S12 à S15 pour A2; S7 à S9 pour A3; S10, S11 pour A4) sous la forme de tables de données décrivant les transitions des automates (A1 à A4) constitués des sous-automates respectivement modélisés par chacun de ces réseaux;
- implémenter (12) les communications asynchrones et pseudo-synchrones qui ont permis de composer ces réseaux, par des suites d'instructions;
- implémenter (12) un moteur d'automate pour chaque automate, ce moteur utilisant ce tables de données et ces suites d'instructions pour concrétiser cet automate.
- implémenter (12) les réseaux issus de la première étape (S2 à S5 et B11 pour A1; S12 à S15 pour A2; S7 à S9 pour A3; S10, S11 pour A4) sous la forme de tables de données décrivant les transitions des automates (A1 à A4) constitués des sous-automates respectivement modélisés par chacun de ces réseaux;
- implémenter (12) les communications asynchrones et pseudo-synchrones qui ont permis de composer ces réseaux, par des suites d'instructions;
- implémenter (12) un moteur d'automate pour chaque automate, ce moteur utilisant ce tables de données et ces suites d'instructions pour concrétiser cet automate.
7) Procédé selon la revendication 1, caractérisé en ce que pour faciliter la vérification (9, 10) de propriétés spécifiques de réseaux (8) résultant de la composition de réseaux, il consiste en outre à repérer (1) certains évènements au moment où le concepteur décrit les réseaux de Pétri initiaux (3); et à éliminer les évènements ainsi repérés, dans le graphe d'accessibilité (11) de chaque réseau résultant d'une composition, déterminé lors de la vérification (9, 10) que ce réseau a des propriétés souhaitées.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9108985 | 1991-07-16 | ||
| FR9108985A FR2679398B1 (fr) | 1991-07-16 | 1991-07-16 | Procede d'aide au developpement d'un ensemble d'automates communicants. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2073903A1 true CA2073903A1 (fr) | 1993-01-17 |
Family
ID=9415182
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002073903A Abandoned CA2073903A1 (fr) | 1991-07-16 | 1992-07-15 | Procede d'aide au developpement d'un ensemble d'automates communicants |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US5291427A (fr) |
| EP (1) | EP0527664B1 (fr) |
| JP (1) | JP2710896B2 (fr) |
| AT (1) | ATE131946T1 (fr) |
| CA (1) | CA2073903A1 (fr) |
| DE (1) | DE69206917T2 (fr) |
| ES (1) | ES2081068T3 (fr) |
| FR (1) | FR2679398B1 (fr) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5930522A (en) * | 1992-02-14 | 1999-07-27 | Theseus Research, Inc. | Invocation architecture for generally concurrent process resolution |
| US5446652A (en) * | 1993-04-27 | 1995-08-29 | Ventana Systems, Inc. | Constraint knowledge in simulation modeling |
| US5394347A (en) * | 1993-07-29 | 1995-02-28 | Digital Equipment Corporation | Method and apparatus for generating tests for structures expressed as extended finite state machines |
| JPH08147345A (ja) * | 1994-11-18 | 1996-06-07 | Nec Corp | オブジェクト指向設計再利用支援システム |
| US5754760A (en) * | 1996-05-30 | 1998-05-19 | Integrity Qa Software, Inc. | Automatic software testing tool |
| DE19651334A1 (de) * | 1996-12-10 | 1998-06-25 | Ericsson Telefon Ab L M | Betriebstestvorrichtung und Verfahren zur Ausführung eines Betriebstests für ein zu testendes System |
| US6049662A (en) * | 1997-01-27 | 2000-04-11 | International Business Machines Corporation | System and method for model size reduction of an integrated circuit utilizing net invariants |
| EP0974112A1 (fr) * | 1997-04-10 | 2000-01-26 | Andreas Frank Böthel | Procede pour la conception de circuits numeriques et integres complexes et structure de circuit pour la mise en oeuvre de ce procede |
| US6059837A (en) * | 1997-12-30 | 2000-05-09 | Synopsys, Inc. | Method and system for automata-based approach to state reachability of interacting extended finite state machines |
| US6067357A (en) * | 1998-03-04 | 2000-05-23 | Genesys Telecommunications Laboratories Inc. | Telephony call-center scripting by Petri Net principles and techniques |
| US6324496B1 (en) * | 1998-06-18 | 2001-11-27 | Lucent Technologies Inc. | Model checking of hierarchical state machines |
| US6256598B1 (en) | 1998-07-10 | 2001-07-03 | The Regents Of The University Of Michigan | Method and system for creating a control-flow structure which represents control logic, reconfigurable logic controller having the control logic, method for designing the controller and method for changing its control logic |
| US6499136B1 (en) * | 1999-11-10 | 2002-12-24 | Lucent Technologies Inc. | Single-shot entry code for software state transition |
| SG102555A1 (en) | 1999-11-25 | 2004-03-26 | Kim Seng Holdings Pte Ltd | Method for using a data flow net to specify and assemble computer software |
| KR100327902B1 (ko) * | 2000-01-27 | 2002-03-09 | 오길록 | 지역모형검사를 이용하여 프로토콜을 실시간적으로검증하는 방법 |
| DE10026387B4 (de) * | 2000-05-27 | 2007-04-19 | Aspern, Jens von, Dipl.-Ing. | Verfahren zur Ausführungszeitoptimierung für Umsetzungen von zustands- bzw. ablauforientierten Modellen, wie Petrinetze oder Automaten |
| US7120699B2 (en) * | 2001-09-20 | 2006-10-10 | Ricoh Company, Ltd. | Document controlled workflow systems and methods |
| US6957178B2 (en) * | 2001-10-29 | 2005-10-18 | Honeywell International Inc. | Incremental automata verification |
| DE102006056019B4 (de) * | 2006-11-28 | 2017-10-19 | Volkswagen Ag | Analyseverfahren und Analysemodul für ein Entscheidersystem |
| DE102006056021B4 (de) * | 2006-11-28 | 2014-07-31 | Volkswagen Ag | Entscheidersystem und Entscheidungsverfahren mit Analysefähigkeiten zum Steuern der Wechselwirkung von Komponenten mittels einer Vorrichtungslogik sowie Entwicklungssystem und Entwicklungsverfahren dafür |
| US8751284B2 (en) * | 2009-04-30 | 2014-06-10 | United Parcel Service Of America, Inc. | Systems and methods for a real-time workflow platform using Petri net model mappings |
| US20120041794A1 (en) * | 2010-08-10 | 2012-02-16 | Sap Ag | Method and system to validate component-based implementations of business processes |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4354226A (en) * | 1978-11-14 | 1982-10-12 | Cutler-Hammer, Inc. | Communication terminal for interconnecting programmable controllers in a loop |
| JPS6232557A (ja) * | 1985-08-06 | 1987-02-12 | Mitsubishi Electric Corp | 通信プロトコ−ル変換装置 |
| JPS63286947A (ja) * | 1987-05-20 | 1988-11-24 | Hitachi Ltd | プロトコルの自動検証方式 |
| US4876664A (en) * | 1987-08-26 | 1989-10-24 | Allen-Bradley Company, Inc. | Programmable controller with a dual intermodule message system |
| JPH01245335A (ja) * | 1988-03-28 | 1989-09-29 | Hitachi Ltd | プログラマブルコントローラの多重化システム |
| US5163016A (en) * | 1990-03-06 | 1992-11-10 | At&T Bell Laboratories | Analytical development and verification of control-intensive systems |
-
1991
- 1991-07-16 FR FR9108985A patent/FR2679398B1/fr not_active Expired - Fee Related
-
1992
- 1992-07-10 EP EP92402016A patent/EP0527664B1/fr not_active Expired - Lifetime
- 1992-07-10 AT AT92402016T patent/ATE131946T1/de not_active IP Right Cessation
- 1992-07-10 ES ES92402016T patent/ES2081068T3/es not_active Expired - Lifetime
- 1992-07-10 DE DE69206917T patent/DE69206917T2/de not_active Expired - Fee Related
- 1992-07-15 CA CA002073903A patent/CA2073903A1/fr not_active Abandoned
- 1992-07-15 US US07/914,115 patent/US5291427A/en not_active Expired - Fee Related
- 1992-07-16 JP JP4189752A patent/JP2710896B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE69206917T2 (de) | 1996-05-23 |
| US5291427A (en) | 1994-03-01 |
| JP2710896B2 (ja) | 1998-02-10 |
| EP0527664A1 (fr) | 1993-02-17 |
| FR2679398B1 (fr) | 1993-10-08 |
| EP0527664B1 (fr) | 1995-12-20 |
| ES2081068T3 (es) | 1996-02-16 |
| JPH05210491A (ja) | 1993-08-20 |
| ATE131946T1 (de) | 1996-01-15 |
| DE69206917D1 (de) | 1996-02-01 |
| FR2679398A1 (fr) | 1993-01-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2073903A1 (fr) | Procede d'aide au developpement d'un ensemble d'automates communicants | |
| FR2821193A1 (fr) | Dispositif de conception d'interface d'utilisateur | |
| EP0560689A1 (fr) | Utilisation d'un langage de programmation, dont le typage porte sur le contenu des variables, dans un système de gestion d'un réseau | |
| WO2006123040A2 (fr) | Procede et dispositif de generation d’un modele parametrique lie a une geometrie 3 d | |
| EP1387305A1 (fr) | Procédé et systeme d'établissement automatique d'un modèle global de simulation d'une architecture | |
| FR2768878A1 (fr) | Edition de donnees audio/video numerisees sur un reseau | |
| FR3072197B1 (fr) | Procede d'execution de plans de sequencement assurant une communication a faible latence entre taches temps-reel | |
| FR3021769A1 (fr) | Dispositif et procede de generation d'au moins un fichier informatique pour la realisation d'une interface graphique d'un equipement electronique, et produit programme d'ordinateur associe | |
| FR3045870A1 (fr) | Procede hors ligne d'allocation d'un logiciel embarque temps reel sur une architecture multicontroleur multicoeur, et son utilisation pour des applications embarquees dans un vehicule automobile | |
| WO2012013503A1 (fr) | Procédé d'exécution parallèle d'un processus informatique par un bus applicatif | |
| EP3881515B1 (fr) | Système de supervision formelle de communications | |
| CA2073915A1 (fr) | Structure d'un ensemble d'automates communicants | |
| EP3230857A1 (fr) | Systeme et methode de transformation de code octal java en code octal java temps reel | |
| FR2963126A1 (fr) | Procede d'execution parallele d'une pluralite de taches ordonnees selon une table d'ordonnancement | |
| EP1764684A1 (fr) | Structure de données et procedé de création d'une documentation de logiciel | |
| EP0631675B1 (fr) | Utilisation d'un langage ayant une representation similaire pour les programmes et les donnees en informatique distribuee | |
| EP1326148A2 (fr) | Paramétrage et compilation automatique de structures utilisant des réseaux de représentation standard | |
| WO2022207424A1 (fr) | Procede d'implementation d'un module logiciel defini par un graphe oriente non cyclique non imbrique en environnement multi-cœur | |
| Kirk | Software Development Process: An Action Grammars Perspective. | |
| FR2835948A1 (fr) | Parametrage et compilation automatique de structures utilisant des reseaux de representation standard | |
| Adrian et al. | LITERATURE REVIEW OF PRODUCT DEVELOPMENT IN MASS PERSONALIZATION AND MASS INDIVIDUALIZATION | |
| WO2022235384A1 (fr) | Détermination de chemin critique de programme d'ordinateur en utilisant une traversée vers l'arrière | |
| FR2810130A1 (fr) | Procede de structuration, de transfert et d'interpretation d'un ensemble d'informations destinees a la conception d'interfaces graphiques | |
| WO2020193351A1 (fr) | Traitement informatisé d'un enchaînement d'agents de calcul mis en œuvre par un ensemble de technologies distinctes | |
| FR2636753A1 (fr) | Procede permettant d'annuler une operation a l'aide d'une relation de dependance entre des relations |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |