FR2818401A1

FR2818401A1 - Procede de generation automatique d'applications embarquees et distribuees de controle-commande dans un reseau d'automates a partir de la modelisation de ce reseau

Info

Publication number: FR2818401A1
Application number: FR0016417A
Authority: FR
Inventors: Christophe Guibert; Thierry Immordino
Original assignee: Thomson CSF SA
Current assignee: Thales SA
Priority date: 2000-12-15
Filing date: 2000-12-15
Publication date: 2002-06-21
Anticipated expiration: 2020-12-15
Also published as: FR2818401B1

Abstract

L'invention se rapporte à un procédé de génération automatique de codes exécutables sur au moins un calculateur recevant de son environnement des paramètres extérieurs et produisant des signaux exploitables vers son environnement, et selon une caractéristique de l'invention, on établit une spécification détaillée du fonctionnement du calculateur et des échanges avec son environnement, que l'on modélise graphiquement par assemblage et spécialisation de comportements élémentaires l'ensemble des fonctions que doit assurer le calculateur et que l'on génère le code exécutable assurant cet ensemble de fonctions.

Description

La présente invention se rapporte à un procédé de génération automatique d'applications embarquées et distribuées de contrôle-commande dans un réseau d'automates à partir de la modélisation de ce réseau.

On connaît des réseaux d'automates comportant un ensemble de modules logiciels et matériels permettant de mettre en oeuvre des réseaux de mesures de données environnementales, de prise de décision, et de contrôle d'actionneurs. Ce sont par exemple des réseaux d'acquisition et de pilotage dans les domaines de la surveillance de l'eau, de l'air, ou du sol, tels que ceux décrits dans le brevet français 2784481.

L'un des besoins à satisfaire pour de tels systèmes est d'offrir un atelier logiciel permettant à la fois de modéliser un système physique de contrôlecommande, de définir et de répartir la logique des traitements à effectuer, et enfin, à partir de ce modèle, de générer automatiquement les applications embarquées prêtes à fonctionner dans les équipements en réseau.

Ceci s'inscrit dans une logique de services où, à partir du recueil des besoins d'un client (spécifications), un système réparti de calculateurs avec leurs capteurs/actionneurs est livré clés en main, accompagné des logiciels embarqués nécessaires pour configurer puis animer le réseau de contrôle-commande.

De façon générale, l'invention s'adresse à tous les systèmes de contrôlecommande, sur des topologies de réseaux quelconques, sans qu'un superviseur soit nécessaire, et de façon à pouvoir prouver par simulation le bon fonctionnement de l'application répartie avant l'enfouissement de ses codes exécutables dans les calculateurs.

Un objet de l'invention est de minimiser les coûts et les temps de développement logiciels, de capitaliser le savoir-faire par réutilisation de modèles ou parties de modèles, et d'obtenir un code testé et fiable.

Le procédé conforme à la présente invention est un procédé de génération automatique de codes exécutables sur au moins un calculateur recevant de son environnement des paramètres extérieurs et produisant des signaux exploitables vers son environnement, et il est caractérisé en ce que l'on établit une spécification

détaillée du fonctionnement du calculateur et des échanges avec son environnement, que l'on modélise graphiquement par assemblage et spécialisation de comportements élémentaires l'ensemble des fonctions que doit assurer le calculateur et que l'on génère le code exécutable assurant cet ensemble de fonctions.

La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de mise en oeuvre, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel : -la figure 1 est un diagramme explicitant les différentes étapes du procédé conforme à la présente invention, -la figure 2 est le bloc-diagramme d'un exemple de réseau applicatif distribué réalisé selon le procédé de l'invention, -la figure 3 est un diagramme simplifié de mise en oeuvre du procédé de l'invention, -la figure 4 est un diagramme explicitant les relations entre les divers éléments d'un méta-modèle établi selon le procédé de l'invention, -la figure 5 est un diagramme explicitant les règles méthodologiques du procédé de l'invention, -la figure 6 est un diagramme montrant les différents invariants d'un réseau de contrôle-commande conforme à l'invention, -la figure 7 est un diagramme explicitant le processus de création d'applications distribuées, conformément au procédé de l'invention, et -la figure 8 est un diagramme exposant le processus de modélisation et de génération d'applications distribuées, conformément au procédé de l'invention.

Le domaine de l'invention est celui de la modélisation objet et de la génération/compilation automatique de code (C++ par exemple) s'appuyant sur un canevas applicatif, généralement dénommé framework applicatif, matérialisant les invariants (invariants de comportement en général) identifiés dans une technique donnée, qui est, dans le cas présent, une application distribuée de contrôlecommande utilisée dans le domaine de l'environnement. Il est toutefois bien entendu que l'invention n'est pas limitée à cette seule application, et qu'elle peut être mise en

oeuvre dans de nombreux autres domaines comportant des calculateurs reliés en réseau applicatif.

De nombreux environnements de modélisation graphique orientée objet générant du code existent déjà, à l'instar de l'outil Rational Rose implémentant la notation UML et générant les squelettes des classes, méthodes et attributs décrits par le modèle. Par contre, dans le cas du mode de réalisation préféré décrit ici, la totalité du code est générée. Par ailleurs, le concept de systèmes d'acquisition répartis a déjà été exploré (cf. l'étude de J. Ehrlich"A generic Model for smart sensors based data acquistion system", Laboratoire Central des Pont et Chaussées. Cette étude traite d'un réseau de capteurs reliés à un superviseur mais n'est pas généralisable à la modélisation/génération de code pour un réseau de calculateurs disposant chacun de capteurs et d'actionneurs. Par contre, le méta-modèle générique, développé conformément à l'invention, permet la génération complète d'applications réparties de contrôle-commande ou d'acquisition et de pilotage.

Ces applications auxquelles s'adresse l'invention sont distribuées sur des réseaux de topologies quelconques : les rebouclages et rétroactions sont permis, le système logiciel étant par ailleurs muni d'un dispositif intégré permettant de détecter la fin de la phase transitoire dans l'établissement des calculs et de rendre alors actifs les appareils (tels que des actionneurs) pilotés par les automates. Le système final obtenu est décentralisé et ne nécessite pas la présence d'un superviseur. Ce dernier est optionnel.

Par ailleurs, grâce aux couches d'abstraction du framework applicatif, le procédé de génération d'application embarquées est indépendant de la plate-forme finale d'exécution (operating system) et du type de réseau utilisé. Ainsi, deux dispositifs différents ont pu être mis en place dans le cadre du mode de réalisation préféré :
Un réseau de contrôle-commande sur microprocesseur noyau temps réel Xinu (PCOS) utilisant un bus de terrain Lon Works,
Un réseau de contrôle commande sur PC sous Windows NT utilisant
TCP/IP et Internet

Dans le cadre de l'invention, et de façon générale, le code généré de la façon décrite ci-dessous s'exécute en environnement temps réel, c'est-à-dire en multi-thread (selon des tâches qui accèdent en commun à toutes les ressources du système), avec des ressources pouvant être limitées, et en respectant les synchronisations entre processeurs. Ce code est indépendant des plates-formes utilisées et des réseaux employés, puisque s'appuyant sur un framework applicatif qui encapsule les couches système et réseau.

L'invention met essentiellement en oeuvre une approche objet du réseau, et dans ce cadre, l'analyse de l'invariant des besoins pour réaliser ce réseau a conduit à l'établissement d'un modèle conceptuel (ou méta-modèle) définissant des métaclasses d'automates de calcul appelés composants, qui sont connectables en réseau.

Ce méta-modèle sert de base, d'une part à la conception d'un framework applicatif qui, à partir des méta-classes, définit les classes de base (abstraites) implémentant les invariants de comportement des automates et leur connectivité en réseau, et d'autre part, à un éditeur graphique permettant la modélisation finale de l'application distribuée. L'éditeur et le framework applicatif sont couplés par des règles et méthodes définies dans le méta-modèle.

La modélisation avec un éditeur graphique et par l'utilisateur est effectuée en créant graphiquement de nouvelles classes d'automates concrètes (par spécialisation des classes abstraites de base), puis en connectant les représentants concrets ( instances ) de ces classes en une topologie plane représentant le réseau final de calcul. Ce réseau peut être hiérarchisé pour créer des sous-réseaux réutilisables, et, au premier niveau de décomposition, pour répartir la charge dans les calculateurs.

L'éditeur génère ensuite pour chaque élément de niveau 1 (pour chaque calculateur) le code (en langage C++ ou Java par exemple) des classes implémentant de manière complète les classes définies graphiquement, puis crée les blocs concrets et leurs associations (relations de connectivité). Les classes dérivées héritent directement des classes abstraites du framework applicatif. Ce code est ensuite compilé avec celui du framework applicatif pour produire les programmes exécutables embarqués dans chaque calculateur.

On a représenté sur le diagramme de la figure 1 les différentes étapes du procédé de l'invention brièvement décrit ci-dessus. A l'étape 1, on établit le méta- modèle des automates du réseau. Ce méta-modèle est défini à partir des spécifications génériques des composants du réseau, de la conceptualisation des

invariants de contrôle-commande, de règles méthodologiques et du canevas des implémentations physiques des composants.

Dans l'éditeur graphique (étape 2), l'utilisateur crée (2. 1) les classes d'automates de base de l'éditeur (ou, le cas échéant, utilise celles provenant d'autres modèles et disponibles dans une bibliothèque de composants prêts à être connectés), qui sont des classes abstraites de modélisation, c'est-à-dire des blocs fonctionnels (source de signaux ou capteur, circuit de calcul, filtre, moteur,....), puis, à partir de ces classes de base, l'utilisateur établit des classes spécialisées (2.2) en adaptant graphiquement les classes de base choisies, c'est-à-dire en adjoignant à chaque bloc fonctionnel les paramètres qui lui sont propres (niveau de signal de sortie, précision, fonction de transfert,...). Enfin, l'utilisateur construit le réseau applicatif distribué (2.3) en reliant les différents blocs ainsi obtenus comme ils doivent l'être dans la réalité.

Parallèlement à l'édition graphique du réseau applicatif, l'éditeur établit les canevas ( framework ) applicatifs (étape 3), par exemple en langage C++ ou Java, ce qui est symbolisé par des flèches reliant les étapes 2 et 3 : d'une part un couplage dit IHM (Interface Homme-Machine), et d'autre part un couplage par règles et méthodes (définies dans le méta-modèle, comme précisé ci-dessus). Ces canevas comportent : le canevas (3.1) des classes abstraites (invariants de comportement et de connectivité des blocs fonctionnels précités), le canevas (3.2) des classes de base, le canevas (3.3) d'abstraction du système d'exploitation, le canevas (3.4) d'abstraction du réseau applicatif et le canevas (3.5) d'abstraction de l'IHM.

A partir de ces canevas, l'atelier logiciel génère des codes (étape 4) : un code pour les classes spécialisées (4.1) issues des modèles constitués par l'utilisateur (spécialisation des classes abstraites) et un code pour l'application distribuée (4.2).

Les codes ainsi générés sont ensuite compilés étape 5) avec celui du canevas

applicatif 3. Il en résulte un programme exécutable (5. 1 à 5. n) qui est embarqué dans chaque calculateur du réseau.

Par ailleurs, l'éditeur graphique 2 produit une documentation (documentation imprimée ou consultable sur écran) relative aux caractéristiques de tous les éléments du réseau distribué et à leur mode d'emploi (étape 6). Par ailleurs, l'éditeur graphique assure le contrôle et la génération du code de spécialisation et de connectivité des différents éléments du réseau applicatif (flèche 2A en figure 1).

On a représenté en figure 2 un exemple simplifié de réseau applicatif distribué 7, étant bien entendu que cet exemple est donné à titre purement illustratif de la mise en oeuvre du procédé de l'invention, et que l'invention s'applique à bien d'autres types de réseaux distribués dont le nombre de composants et dont les connexions entre ces composants et leur fonctionnement peuvent être très différents de l'exemple représenté ici. Ce réseau 7 comporte, dans le présent exemple, trois bornes-calculateurs 8,9 et 10. La borne 8 comporte : trois sources de signal (capteurs de paramètres d'environnement par exemple) référencées 8.1 à 8.3, un circuit de calcul 8.4 relié aux sources 8.1 et 8.2 et dont la fonction de transfert est de la forme Y=f (X), X représentant chacun des signaux issus des sources 8.1 et 8.2, un deuxième circuit de calcul 8.5, similaire au circuit 8.4 relié à la source 8.3 et à une sortie du circuit 8.4. La sortie du circuit 8.4 est reliée à un sous-réseau 8.6 (calculateur), à l'entrée du circuit 8.5 et à un premier puits de signal 8.7 (dispositif final exploitant le signal produit par un circuit de calcul, par exemple un moteur ou une électro-vanne). La sortie du circuit 8.5 est reliée à un circuit de calcul 9.2 (décrit ci-dessous), à un deuxième puits de signal 8.8 et à l'entrée du circuit 8.4.

Le calculateur 9 comprend une source de signal 9.1 reliée à l'entrée du circuit de calcul 9.2, entrée qui est également reliée, comme précisé ci-dessus, à la sortie du circuit 8.5. La sortie du circuit 9.2 est reliée à un puits de signal 9.3 ainsi qu'à l'entrée d'un circuit de calcul 10.1 faisant partie du calculateur 10. L'entrée de ce circuit 10.1 est également reliée à la sortie du circuit 8.6. La sortie du circuit 10. 1 est reliée, d'une part, à deux puits de signal 10.2 et 10.3 et d'autre part à l'entrée du circuit 8.6.

L'invention utilise le paradigme objet. Le méta-modèle est l'élément structurant de la réalisation d'une application distribuée de contrôle-commande suivant les cas d'utilisation définis dans le diagramme de la figure 3 décrite cidessous. Le méta-modèle est issu de l'analyse des invariants de métiers détectés en matière d'applications réparties de contrôle-commande dans le domaine de l'environnement, grâce à la collecte des besoins effectuée par des experts du domaine auprès d'opérationnels (clients). Il permet ensuite, à la fois, de définir les outils et logiciels supports à la production d'applications distribuées et de structurer et guider le concepteur d'applications dans l'utilisation de ces outils, comme décrit ci-dessous.

On a représenté sur la figure 3 un exemple simplifié de mise en oeuvre du procédé de l'invention. Le client désirant réaliser un réseau applicatif distribué formule ses exigences (II), par exemple en produisant un cahier des charges minimal (emplacement des divers capteurs et des divers actionneurs, valeurs limites des paramètres à surveiller, vitesse de réaction en cas de dépassement de ces limites,....).

Il se concerte avec un expert (12) qui avance des propositions, pour établir un recueil de tous les besoins du client (13). Il en résulte une liste de spécifications détaillées du réseau (14). A partir de ces spécifications détaillées, un concepteur effectue une modélisation (15), le méta-modèle (16) du système de contrôle-commande du réseau comportant les éléments suivants (dont les relations mutuelles sont illustrées en figure 4) :

Les spécifications génériques du domaine, Les règles méthodologiques de modélisation d'applications distribuées de contrôle-commande.

La conceptualisation générique des invariants du domaine,
Le canevas d'implémentations physiques.

L'étape suivante est la réalisation concrète de l'application distribuée, qui est mise en place par un installateur (17), avec l'aide de la documentation (18), puis son test et sa validation par un testeur (19). En dernier lieu, après validation favorable, l'exploitant prend en charge le réseau, qu'il contrôle et pilote (20).

Comme illustré de façon simplifiée en figure 4, dans le méta-modèle, le canevas des implémentations physiques (21) est lié à la conceptualisation générique

des invariants (22) et à l'élaboration des règles méthodologiques de modélisation d'applications distribuées (23), ces deux dernières entraînant l'élaboration des spécifications génériques du réseau applicatif (24).

Les spécifications génériques sont classifiées en exigences fonctionnelles et opérationnelles.

- Les spécifications fonctionnelles comportent les éléments suivants : * Traitement de mesures datées * Traitements statistiques complexes * Priorité des acquisitions sur les mesures * Calculateurs interfacés avec des capteurs et/ou des actionneurs locaux * Calculateurs reliés en réseau * Répartition de la charge de calcul sur les différents calculateurs du réseau * Echanges d'informations synthétiques entre calculateurs * Stockage local d'historiques de mesures ou de calculs * Stockage distant de mesures * Surveillance à distance de l'état du système
Pilotage à distance du système
Périodes d'acquisitions spécifiques aux capteurs - Les spécifications opérationnelles sont les suivantes : * Minimiser le trafic réseau * Automatiser la production de l'application à partir du recueil des besoins * Capitaliser et réutiliser tout ou partie d'une autre application * Etendre facilement le système par ajout de nouveaux composants de calcul : I : Etablir la preuve de bon fonctionnement du système.

Les règles méthodologiques formalisent l'ensemble des conventions de conception et de production adoptées dans le domaine étudié. Elles se traduisent par des documentations sur papier (règles de conception, principes de fabrication), par

des conceptualisations du problème (réseaux d'automates de calcul), et par des directives d'implémentations physiques des moyens de production : outils de modélisation (éditeur) et supports applicatifs pour les productions de l'éditeur (frameworks applicatifs), comme illustré sur le schéma de la figure 5.

Sur cette figure 5, on a indiqué que la conceptualisation du réseau (25), qui consiste en particulier à établir sa topologie et la hiérarchisation de ses différents sous-ensembles, s'appuie sur des règles (26) qui se rapportent à la programmation objet, et au respect des interfaces entre les différents éléments du réseau. A partir de cette conceptualisation, on établit des guides de conception et d'utilisation (27) par compilation avec un compilateur se servant d'une bibliothèque d'éléments graphiques ou fonctionnels (28), en collaboration avec l'IHM (29) qui permet de représenter des éléments d'aide tels que des boites de dialogue, des onglets et des graphiques divers, et ce, à partir de la conceptualisation des noeuds de calcul (30), qui englobe les automates de calcul et la propagation des messages. Cette conceptualisation s'appuie à la fois sur les rèles 26 et sur les spécifications du protocole d'échange de données entre les différents calculateurs du réseau (31). A partir de l'établissement des guides 27, on pratique l'expertise de la conceptualisation générique du réseau, qui consiste à traduire les exigences du client en modèle générique abstrait (32). On obtient alors le paradigme (modèle) du réseau, selon une approche objet (33).

Les invariants identifiés dans le domaine de l'application étudiée sont constitués de réseaux d'automates de calcul. Un réseau est un graphe orienté permettant des rebouclages. Les échanges d'informations entre les noeuds du réseau (les automates de calcul) s'effectuent par transmission de messages. Les messages circulent suivant l'orientation du graphe depuis les sources d'information (automates capteurs) vers les puits d'information (automates actionneurs) en passant par des fonctions de transfert (automates de calcul), comme on l'a vu ci-dessus en référence à l'exemple de la figure 2. Le réseau peut être hiérarchisé, le niveau 1 (le plus bas) définissant un calculateur (automate spécifique).

Les automates de calcul sont des entités indépendantes (des objets) capables de relayer des messages arrivant sur leurs entrées, de les traiter et de les

propager suivant leurs connexions vers d'autres automates. Plus généralement, ils ont un comportement générique décrit par le méta-modèle.

On a représenté en figure 6 les caractéristiques et relations entre les invariants du réseau que sont ces automates de calcul. Un calculateur automate (34) fait partie d'un réseau, et dans ce réseau, les invariants sont : la liste de ses noeuds fils et de ses connexions filles (35), pour un noeud, ce sont (36) : la connectivité de ses composants, sa topologie, et son activité (actif ou passif). Chaque feuille (37) rattachée à un noeud 36 comporte les invariants suivants : sa fonction de calcul, son automate de calcul, les spécifications de ses entrées et sorties, sa capacité de propagation des messages qui transitent par ce noeud et sa période de calcul. Pour ce qui est des messages (38) transitant par les noeuds (36), leurs invariants sont leur format, leur source et leur destination. Leur routage est assuré par les connexions (39) entre noeuds, les invariants de ces connexions étant le sens de navigation des messages, leur période d'activation et les grandeurs véhiculées. Il est à noter que pour un noeud, une sortie peut avoir N liens avec d'autres noeuds, mais qu'une entré ne peut avoir qu'un seul lien venant d'un autre noeud.

Pour définir les canevas d'implémentations physiques, en spécifiant un méta-modèle, on établit les règles et modalités d'implémentation des outils logiciels qui permettront : la modélisation d'applications distribuées de contrôle-commande, la réalisation du cadre et du support logiciel nécessaires à l'exécution de cette application.

Il s'agit respectivement des canevas de conception de l'éditeur graphique et de ceux des frameworks applicatifs.

L'éditeur graphique définit des classes abstraites (c'est-à-dire des modèles de comportement qui ne se traduisent pas directement par un objet concret) qui permettent à l'utilisateur (le concepteur) de modéliser son application distribuée : par conception de composants réutilisables : définition de classes dérivées des classes abstraites à l'aide d'outils graphiques et d'une interface homme-machine (IHM),

par création d'instances et par assemblage graphique de ces instances en un réseau de calcul hiérarchisé, par modélisation physique des calculateurs.

Après une phase de contrôles topologiques (connectivité, atteignabilité, preuve de convergence des calculs au sein des boucles), l'éditeur produit : la génération d'une documentation (notice d'installation et d'assemblage des calculateurs, la génération de code applicatif héritant des propriétés des frameworks applicatifs.

Les frameworks applicatifs réalisent l'implémentation physique de l'invariant des besoins, à savoir les réseaux physiques d'automates de calcul.

Ils s'appuient sur des abstractions (méta-classes) qui sont : le système, - l'interface utilisateur, le réseau.

Suivant les réalisations de ces abstractions, on peut construire des frameworks applicatifs basés par exemple sur les choix suivants : système : microprocesseur noyau temps réel ou Windows NT
Interface utilisateur : interface graphique XII, Windows ou mode commande textuelle,
Réseau : réseau de terrain LonWorks ou TCP/IP (protocole utilisé sur
Internet).

La conceptualisation générique et l'application des règles et méthodes permettent la réalisation physique des logiciels (à savoir les éditeurs et les canevas) à partir desquels l'utilisateur définit ses modèles réutilisables, c'est-à-dire des classes spécialisées, et en fin de compte ses applications distribuées de contrôle-commande.

On a représenté en figure 7 les dépendances et étapes de production d'une application distribuée. L'application d'utilisateur (52), est définie d'une part à partir des classes spécialisées (53) et d'autre part à partir du canevas générique (54).

L'éditeur graphique (55) permet de matérialiser les classes spécialisées 53 et sert, avec l'aide du canevas générique (54), à la conceptualisation générique des

invariants (56) provenant du méta-modèle. Les règles méthodologiques (57), provenant également du méta-modèle, sont obtenues en passant par la conceptualisation générique 56, par les classes spécialisées 53 et par le canevas générique 54.

L'assemblage final (modélisation et génération) de l'application distribuée, à partir des modélisations effectuées par le concepteur et à partir d'un canevas applicatif physique est réalisé de la façon illustrée en figure 9. Le concepteur opère à partir de l'éditeur graphique qui implémente la conceptualisation générique des invariants décrite par le méta-modèle : description d'un calculateur (66), du réseau (67) constitué de composants (68) dérivés de noeuds (69) et associés par des connexions (70). En appliquant les règles et méthodes induites par le métamodèle, l'éditeur offre des classes abstraites de calculateur (71), de réseau (72) et de composants (73) qui permettent au concepteur de réaliser par modélisation graphique ses propres classes concrètes réutilisables : modèles de bornes (58), de réseaux (59), de composants (60). L'assemblage de ces modèles élémentaires en une topologie réalise le modèle de l'application distribuée. Lors de la phase de génération de code, ces modèles réalisent concrètement les classes abstraites du framework applicatif ( (63), (64) et (65) ) qui, lui-même a été conçu et réalisé en appliquant les règles et méthodes du méta-modèle. Le résultat de la génération du code est donc une application distribuée composée d'instances de bornes (61) constituées de composants (62) communiquant suivant le paradigme issu du méta-modèle initial.

On notera d'autre part que l'éditeur graphique sert à établir, pour le métamodèle résultant, les classes abstraites de calculateur (71), de réseau (72) et de composants (73) qui permettent de générer le code de la classe correspondante et de construire les modèles (respectivement 58,59 et 60).

Claims

REVENDICATIONS

1. Procédé de génération automatique de codes exécutables sur au moins un calculateur recevant de son environnement des paramètres extérieurs et produisant des signaux exploitables vers son environnement, caractérisé en ce que l'on établit 1 une spécification détaillée du fonctionnement du calculateur et des échanges avec son environnement, que l'on modélise graphiquement par assemblage et spécialisation de comportements élémentaires l'ensemble des fonctions que doit assurer le calculateur et que l'on génère le code exécutable assurant cet ensemble de fonctions.

2. Procédé selon la revendication 1, caractérisé en ce que la modélisation est réalisée après analyse des invariants du réseau pour établir un modèle conceptuel définissant des méta-classes d'automates de calcul connectables en réseau.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la modélisation est effectuée par l'utilisateur à l'aide d'un éditeur graphique (2) en créant graphiquement de nouvelles classes d'automates concrètes (2.1) par spécialisation (2.2) des classes abstraites de base, puis en connectant les exemples concrets de ces classes (2.3) en une topologie plane représentant le réseau final de calcul.

4. Procédé selon la revendication 3, caractérisé en ce que les classes spécialisées sont établies en adjoignant à chaque bloc fonctionnel représentant une classe les paramètres qui lui sont propres.

5. Procédé selon la revendication 3 ou 4, caractérisé en ce que parallèlement à l'édition graphique du réseau applicatif, l'éditeur établit les canevas applicatifs correspondants (3).

6. Procédé selon la revendication 5, caractérisé en ce que les canevas comportent : le canevas (3.1) des classes abstraites (invariants de comportement et de connectivité des blocs fonctionnels précités), le canevas (3.2) des classes de base, le canevas (3.3) d'abstraction du système de calcul, le canevas (3.4) d'abstraction du réseau applicatif et le canevas (3.5) d'abstraction de l'interface homme-machine permettant de manipuler l'éditeur graphique.