Brevet FR2693010A1 — publié le 19931231

La présente invention concerne un système informatique de gestion de processus comprenant un ordinateur de contrôle d[epsilon] processus qui envoie des commandes destinées à modifier le déroulement du processus en réponse à des valeurs de c paramètres en provenance du processus? un système expert dont la base de connaissances comprend les lois devant s'appliquer au processus et un programme extérieur commandant le fonctionnement de l'ordinateur de contrôle de processus. Les systèmes experts ont été créés dans le faut de remplacer le raisonnement humain dans ce qu'il y a de plus caractéristique, c'est a dire la faculté que possède l'homme d'élaborer? en fonction d'éléments parfois insuffisants?un résultat probable qui s'appuie non seulement sur un raisonnement logique mais aussi sur des connaissances en 15 perpétuelle évolution, A côté du domaine de l'aide au diagnostic dans lequel les systèmes experts fournissent à partir d'une certaine quantité de faits plus ou moins certains? une interprétation en suivant un raisonnement que l'on peut assimiler a un diagnostic? la 20 tendance actuelle est plutôt à la diversification des domaines d'application. ainsi?dans le domaine de la gestion des processus? le système expert peut être très efficace en effectuant d'une part le contrôle du processus en prenant en compte l'évolution de 1 'environnemen , et d'autre part la 25 décision d'intervention sur le déroulement du processus en cours. Pour la gestion d'un processus tel que la régulation du trafic urbain?un ordinateur de contrôle de processus commande les différentes variables du système à gérer en fonction des 30 valeurs de paramètres qu'il reçoit de détecteurs ou de points de mesure des paramètres. il détermine les commandes à transmettre gr ce à des stratégies prédéterminées qui lui ont été fournies préalablement. Le système expert amène une dimension supplémentaire à un xc tel système dans la mesure où il est capable d'analyser les situations en temps réel de façon à anticiper sur l'évolution probable du processus et d'en tirer des stratégies nouvelles. En outre? le système expert s'enrichit de nouvelles règles d'anticipation au fur et à mesure +que la connaissance des phénomènes spécifiques s'affine. Un programme d'adaptation est nécessaire entre le système expert et l'ordinateur de contrôle de processus, ce programme d'adaptation a pour fonction d'appeler le système expert chaque fois que l'ordinateur de contrôle de processus en a besoin? et de retransmettre sous forme adéquate les commandes en provenance du système expert. Un tel programme d'adaptation est relativement complexe à élaborer. En plus?il doit être réécrit lorsque pour des raisons d'amélioration du système?le programme de commande de l'ordinateur de contrôle doit "être modifié. C'est pourquoi le but principal de l'invention est de réaliser un système de gestion de processus incorporant un système expert? et disposant d'un programme d'adaptation ou module de dialogue entre le système expert et le programme de contrôle de processus qui est géré automa iquement et rapidement a partir de données communes au système expert et programme de contrôle de processus, Un autre but de l'invention est de réaliser un système de régulation de trafic urbain qui? grâce à un système expert? est capable de répondre immédiatement à un problème ponctuel de circulation?mais surtout de prévenir les embouteillages en ayant par avance envisagé les différentes stratégies possibles et retenu la meilleure en tenant compte de sa propre expérience. L'objet principal de l'invention est donc un système informatique de contrôle de processus du type comprenant un système expert et un ordinateur de contrôle de processus commandé par un programme extérieur?dans lequel? lors de l'exécution du programme extérieur? ce dernier fait appel au système expert au moyen d'un module de dialogue généré par un générateur d'applications en utilisant conjointement le système expert après compilation et le programme extérieur avant compilation. Les buts?objets et caractéristiques de l'invention apparaîtront mieux à la lecture de la description qui suit d'un mode de réalisation préféré de l'invention faite en référence aux dessins dans lesquels: la figure 1 représente un schéma d'ensemble d'un mode de réalisation préféré de l'invention appliqué a un système de régulation de trafic urbain; la figure S représente un schéma synoptique montrant la génération? par un générateur d'applications?du module de dialogue entre le système expert et le programme extérieur de commande de l'ordinateur de contrôle; la figure 3 représente un schéma synoptique illustrant le fonctionnement du programme de- commande de l'ordinateur de contrôle et du système expert par l'intermédiaire du module de dialogue; la figure A- représente un schéma synoptique montrant la génération des modules de liaison entre le système expert et le système graphique et entre la base de données relationnelle et le système graphique; la figure 5 représente un schéma synoptique illustrant les interactions entre le système expert?le système graphique ^ ^ base de données relationnelle; et la figure 6 représente un schéma d'ensemble montrant les divers éléments du système de régulation de trafic dans lequel l'invention est mise en oeuvre. Comme illustré sur la figure 1?un mode de réalisation préféré de l'invention concerne un système de régulation du trafic urbain. Ce système dispose d'un système expert ÎO avec son moteur d'inférence et sa base de connaissances?d'un ordinateur de contrôle de processus 1^- (disposant d'un programme de commande) chargé du contrôle de la régulation du trafic. Un module de dialogue IS assure la liaison entre le système expert et le programme de commande de l'ordinateur de contrôle de processus. Le module de dialogue IS est généré d'une façon spécifique comme on le verra dans la suite de la description. Un système graphique 16 permet à l'opérateur de visualiser sur écran n'importe quelle information graphique en relation a.ve Le fonctionnement de chacun des éléments du système?la J5 génération du module de dialogue entre le système expert et le programme de commande de l'ordinateur de contrôle ainsi que les autres modules effectuant la liaison entre divers éléments vont maintenant être décrits. LE SYSTEME EXPERT 0 Les lois de la base de connaissances sont des assertions logiques dites "règles de production" articulées sur le formalisme de la logique formelle du type: SI / CONDITION / ALORS?SINON / CONCLUSION Le nombre de conditions (ou prémisses) possibles est de 2ç dix?au maximum? liées par un ET logique. Chacune de ces prémisses peut elle-mê e résulter de la combinaison par le OU logique de dix conditions élémentaires. Le nombre de conclusions possibles est également de dix? liées par le ET logique?pour la partie conclusion directe (en 30 ALORS) et également de dix pour la partie indirecte (en SINON) . Les prémisses sont constituées par des couples objet/valeur ou objet/objet. la formation des objets est libre?ceux- i pouvant décrire des éléments simples ou encore xc des éléments indicés. Ces objets sont de type numérique ou bien chaîne de caractères. Les prémisses portant sur des objets de type numérique peuvent faire intervenir les opérateurs = ; > ; 5 VARE = BONJOUR TAB([eta]-) Les prémisses du "type objet/objet permettent la comparaison de deux objets de même nature. La comparaison de deux variables numériques s'effectue à l'aide des opérateurs = : > ou Les conclusions directes - ou indirectes portent sur l'affectation d'objets à des valeurs particulières à l'aide de l'opérateur = . Deux types d'af ectation sont possibles: objet = valeur objet = valeur prise par un autre objet de même type Lorsqu'une conclusion n'est pas formulée sur le schéma "objet = valeur" ou bien "objet = objet", celle-ci est considérée comme une action particulière a effectuer. En cours de fonctionnement?le dé lenchement d'une telle conclusion entraîne l'analyse de sa formulation par un interpréteur dont le rôle est de répartir sur des modules dédiés les tâches à effectuer. exemple: Message ATTENTION PROBLEME DE DYSFONCTIONNEMENT déclenche MOD1 (MOD1 est un module de traitement) La saisie des règles s'effectue a l'aide d'un éditeur de fichier de texte. Chaque règle est détachée de la suivante à l'aide d'une ligne de séparation spécifique. L'ordre dans lequel les règles sont saisies n'influe pas sur l'utilisation ultérieure qui en est faite par le moteur d'inférence en cours d'exécution: la base de lois est dite modulaire. Le moteur d'inférence est chargé de construire un plan de résolution de façon dynamique à partir des règles de la base de connaissances et des informations qui lui sont fournies en entrée. Le mécanisme de déduction proprement dit est de type chaînage avant: à partir des couples objet/valeur qui lui sont fournis ou qu'il parvient à construire par déclenchement des règles?le système parcourt la base de règles pour y trouver celles qui sont applicables et celles qui ne le sont plus. Une règle n'est plus applicable lorsqu'une au moins des conditions à son déclenchement n'a pu être vérifiée?ou bien lorsque l'ensemble de ses conclusions porte sur des objets déjà 5 values. Dans le cas où la contraposée logique de la partie CONDITION a pu être vérifiée?le système déclenche la partie CONCLUSION indirecte (en SINON) lorsqu'elle existe. A chaque itération (cycle de déduction)?le système met à 10 jour son CONTEXTE qui est un fichier regroupant les couples objet/valeur fournis en entrée ainsi que ceux déduits en sortie par déclenchement des règles instanciées. Pour chaque règle encore applicable est conservée la liste des conditions déjà vérifiées (ou non dans le cas des OU[tau]_ logi[alpha]ues) . Le moteur d'inférence travaille ainsi par transition d'état du CONTEXTE et conserve la trace des décisions qu'il a prises et les éléments (objets et règles) qui lui ont permis de prendre des décisions. _ A chaque cycle?les règles candidates au déclenchement en fonction du CONTEXTE?sont rangées par ordre d'intérêt au sens de la résolution entreprise. La pondération des règles candidates est effectuée en énumérant les objets non encore values qui peuvent être affectés dans leur partie CONCLUSION ,c et la liste des règles que ces objets intéressent en partie CONDITION?de façon à évaluer l'influence qu'aura le déclenchement d'une règle sur la poursuite- des déductions ultérieures. Cette façon de pratiquer vise en particulier à l'élimination "au plus tôt" des règles non applicables et par 30 voie de conséquence?à l'abandon des objets à évaluer qui ne figurent pas dans des règles encore déclenchables. Le déclenchement de la règle candidate de poids supérieur entraîne une modification du CONTEXTE et un nouveau cycle de déduction entraînant le re-arrangement de règles candidates zc suivant le principe énoncé plus haut. L'enchaînement des cycles de déduction s'interrompt lorsque plus aucune règle n'est applicable ou bien lorsqu'en l'absence d'introduction de données extérieures? le moteur d'inférence épuise sa liste de règles candidates sans pour autant obtenir de nouvelles déductions (pas de modification du CONTEXTE) . MODULE DE DIALOGUE (Figure S) 5 La base de connaissances du système expert 10 est d'abord compilée par le compilateur de règles de façon à obtenir un fichier compilât ES composé des structures de règles et de la liste et nature des objets. Lorsque le système expert doit être alimenté en donnéesj^ par un autre programme effectuant une tâche particulière et lorsque les valeurs de sortie sont attendues par le programme extérieur (ici le programme de commande de l'ordinateur de contrôle de processus) afin que ce dernier puisse modifier son comportement en fonction des réactions du système expert?unjmodule de dialogue doit être développé afin de permettre l'échange de ces valeurs entre les deux logiciels. Le module de dialogue S[eta]- doit être adapté au nombre de variables de transit?à leur type (variable numérique entière ou réelle?élément de tableau de variables numériques?chaînes ~ de caractères) ainsi qu'aux noms donnés à ces variables dans le programme extérieur écrit en langage C et dans la base de lois du système expert dont le formalisme a déjà été décrit. Lorsqu'une modification doit être effectuée sur les variables d'échange?l'adaptation du. module de dialogue doit "t- être p og ammé. C'est une des caractéris iques essentielles de l'invention d'utiliser un générateur d'applications EA- du type générateur de code C?qui relit le codage du programme extérieur (non encore compilé) et analyse une partie du code 0 spécifique situé entre les deux lignes de commentaire réservées suivantes: * Variables de transfert début * Variables de transfert fin Entre ces deux lignes?le générateur d'applications 5 reconnaît la liste des variables destinées aux échanges avec le système expert? par exemple: int VAR1?VARE, VAR3 int TAB(IOO) Le générateur d'applications opère donc de la façon suivante: 1. il reconnaît les variables par leur nom et en identifie le type?' 2. il compare la liste obtenue au résultat de la compilation de la base de connaissances (fichier compilât)? 3. puis il écrit un module de dialogue [pound]6 comprenant une partie de code C permettant d'une part le passage de la valeur de chaque variable vers le générateur d'applications en construisant le couple objet/valeur attendu?et d'autre part le retour des valeurs modifiées de ces variables vers le programme extérieur. Lorsqu'une incohérence de ^ype est reconnue?le générateur d'applications s'interrompt et détruit le code déjà généré. exemple: la variable VAR1 est manipulée comme une variable numérique réelle dans le programme extérieur et a été reconnue comme une chaîne de caractères lors de la compilation de la base de lois. Le générateur d'applications teste également la présence dans la base de lois des variables déclarées partageables? et dans le cas contraire il signale l'erreur puis s'interrompt. Il teste également le dimensionn[epsilon]me[pi]t des tableaux partagés en le comparant à la liste des variables indicées reconnues par la compilation de la base de lois. APPEL DU SYSTEME EXPERT (Figure 3) Comme on l'a vu précédemment? en fonctionnement? le système expert lO travaille par l'intermédiaire du fichier CONTEXTE 30 dans lequel figure l'ensemble des couples objet/valeur ainsi que l'état des régies. Le fichier CONTEXTE 30 est mis à jour par le système expert à chaque itération (cycle de déduction). Le moteur d'inférence travaille par transition d'état du fichier CONTEXTE 30 et conserve la trace des décisions qu'il a prises et les éléments? objets et règles?qui lui ont permis de prendre ces décisions. Lorsqu'un appel au système expert doit être effectué par le programme extérieur SS?on positionne simplement une commande EXSYS (0) ou EXSYS (1) EXSYS (O) appelle le système expert en lui passant les valeurs courantes des variables partagées et met en attente le programme extérieur jusqu'à ce que le système 5 expert ait terminé ses déductions et renvoyé les variables d'échange mises à jour. EXSYS (1) appelle le système expert mais n'attend pas de retour? dans le cas où? par exemple? les déductions du système expert ne modifient pas des variables attendues X0 par l'extérieur (message opérateur ou action du système expert sur un autre module) - Lors de l'exécution proprement dite? la commande EXSYS déclenche l'exécution du module de dialogue qui a été généré par le générateur d'applications. 15 Le module de dialogue E6 à chaque exécution? teste la modification d'une au moins des variables partagées par rapport à son exécution précédente? sinon? il rend la main au programme extérieur ES sans que le système expert n'ait été appelé. 20 Cette méthode permet le couplage simple et sans étape de programmation? entre un programme algorithmique quelconque et le système expert?de manière à tirer partie des avantages respectifs de ces deux entités bien distinctes. SYSTEME SRAPHIQUE ET BASE DE DONNEES RELATIONNELLE 25 Comme décrit précédemment?parmi les conclusions qui peuvent être obtenues à l'aide du système expert? certaines ne portent pas sur l'affectation des variables. Des conclusions particulières permettent le déclenchement d'une liste d'actions spécifiques sur d'autres entités que le programme XQ extérieur. Lorsqu'une conclusion de type ACTION est obtenue en cours d'exécution?elle est traitée par un interpréteur qui répartit l'action à effectuer. L'interprétation de la commande permet d'isoler la nature de l'action? l'objet sur lequel elle 5 s'applique?et les paramètres du déclenchement proprement dit. Une des actions possibles effectuée par le système expert est de commander la représentation graphique d'un objet donné sur l'écran d'un système graphique 16 (voir figure 1) en utilisant les informations contenues dans une base de données relationnelle 18. Le logiciel de représentation graphique proprement dit est un programme qui n'est pas spécifique à l'invention et dont les caracté istiques principales sont les suivantes: - manipulation de fonds de plans de type bit-map? - manipulation d'objets vectoriels (de forme quelconque sur [pound]56 couleurs et 1[pound] fonds différents) répartis sur des plans superposés et associés à une fiche signalétique IQ stockée dans la base de données relationnelle répondant aux critères imposés par la -norme SQL? - obtention de la fich d'un objet vectoriel par "cliquer souris sur représentation graphique"? - possibilité de zoom de 1 à 3E?e manipulation d'icônes (pouvant elles mêmes être associées à une fiche dans la base de données) . L'outil pour la mise en oeuvre du système graphique est composé de deux modules distincts. Ces modules permettent l'accès à la base de données relationnelle depuis le système 20 expert ou encore depuis le logiciel de représentation graphique dans la limite de fonctionnalités prévues dans l'application finale et ce?quelle que soit la structure de la base de données 18. En référence à la figure -?le premier module SRAPH-BASE 25 3[pound] permet des représentations et donc le dessin de chaque objet et son raccordement à une fiche dans une des tables de la base de données 13. Le deuxième module SE-BASE 3 est destiné en cours d'utilisation à l'assignation par le système expert. Les deux modules sont spécifiques à la structure de la 0 base employée (nombre de tables?nombre et type des attributs de chaque table). Une explication détaillée des modules est donnée ci-aprè . Un générateur d'applications 36 tel qu'un générateur de code C permet la rédaction automatique des modules 3[pound] et 34 à [Upsilon]5 partir de la liste des tables se trouvant dans la base de données et pour chacune des tables de la liste des attributs et leur type. Ces modules sont rédigés en langage Pro*C? c'est à dire qu'ils utilisent des commandes de type requête SQL [Upsilon]5 depuis des procédures en langage C. MODULE GRAPH-BASE Le module est utilisé en saisie lors du dessin des représentations graphiques des objets qui pourront être manipulés par le système expert, puis en affichage lors de l'exécution de l'application finale, ceci afin de présenter à l'utilisateur la fiche d'un objet sur lequel il vient de cliquer. Dans les deux cas?il s'agit de faire correspondre des coordonnées écran à une fiche dans la base de données. Lorsqu'un objet graphique est dessiné, le module GRAPHBASE affiche la liste des tables- de la base. Après qu'une des t-ables a été sélectionnée le module GRAPH-BASE affiche la liste des attributs de cette table et demande la saisie des valeurs d'un ou plusieurs attributs. En fonction des valeurs saisies? une requête SQL est effectuée de façon à présenter la liste des objets (leur fiche complète est affichée) qui la satisfait. L'opérateur crée alors le lien sur la fiche désirée. Après qu'une modification de la base de données a été effectuée? le module GRAPH-BASE doit être régénéré par le générateur d'applications afin d'être adapté à la nouvelle version MODULE SE-BASE Ce module permet la sélection sur requête? d'objets de la base de données de façon à en manipuler la représentation graphique. exemple: CACHER AXE Le module va chercher dans la base de données tous les objets de type AXE?modifie leur attribut "visible" pour les mettre à FAUX. exemple: VOIR AXE NUMERO 10 Le module va chercher dans la base de données le(s) ob et(s) de la table AXE ayant l'attribut NUMERO à la valeur 10 et met l'attribut visible à VRAI. La liste des actions possibles depuis le système expert est la suivante: VOIR/objet/attribut/valeur CACHER/objet/attribut/valeur ZOOM/valeur du zoom/objet/attribut/valeur MODIFIER COULEUR/ob jet/attribut/valeur REMETTRE COULEUR DORIGINE/ob et/att ibut/valeur FAIRE CLIGNOTER/ob et/attribut/valeur ' Une action précédée d'un"-" équivaut à la commande inverse ou à l'interruption de la commande en cours. La formulation de la commande depuis le système expert n'impose pas l'attribut utilisé dans la requête sur une table donnée? la requête s'effectue quel que soit cet attribut. Le module SE-BASE est rédigé de façon à prévoir les différents axes possibles. Une modification de la structure de la base de données (rajout/élimination d'une table ou rajout/élimination d'un attribut dans une table) implique de régénérer un module SE- BASE adapté à la nouvelle structure. ANALYSEUR SYNTAXIQUE Comme illustré sur la figure 5 un module de traitement du langage naturel ou analyseur syntaxique 40 est employé dans l'application finale afin de faciliter les accès à la base de données relationnelle 18 via le module généré SE-BASE 34. Cet analyseur syntaxique 40 est employé au traitement de commandes données par l'opérateur en langage naturel? au système graphique 16?telles que par exemple : " Je veux voir tous les axes" ou " Fais un zoom 4 sur le tronçon numéro E" . II est également employé au traitement des conclusions obtenues par le système expert lO lorsque les conclusions impliquent des accès à la base de données 18. L'analyseur syntaxique 40 décompose une phrase en mots? chaque mot étant ensuite traité avec l'aide d'un fichier 4[Xi] contenant une liste des synonymes de façon à : 1: Conserver les seuls mots utiles (élimination des con onctions? des pronoms? des articles? etc.. [pound]: Traiter les accords de la langue française (pluriels? verbes accordés?participe passé?participe présent) afin de ne conserver que les radicaux. 3: Comparer par convolution les radicaux retenus dans la liste des synonymes définis en fonction de l'application finale envisagée. 4: Comparer suivant les différentes combinaisons possibles?la liste des mots retenus et leur synonymes respectifs à un ensemble de scripts pré-établis correspondant aux différentes actions possibles sur la base de données relationnelles. exemple : " Je ne veux plus voir le tronçon numéro 4" sera traduit : CACHER AXE NUMERO 4 L'utilisation d'un tel analyseur syntaxique donnant les commandes en langage naturel pour une application telle que la régulation du trafic urbain évite d'avoir à utiliser un opérateur qui soit spécialiste en in ormatique. APPLICATION A LA REGULATION DU TRAFIC URBAIN Comme illustré sur la figure 6? le système de régulation de trafic repose sur une architecture muiti- ouche à répartition de fonc ionnalités. Il comporte en effet au niveau "contrôleurs de carrefours" 50, un niveau "modules locaux" 5[pound] et un niveau "poste central informatique" &vsc l'ordinate r de contrôle 14 et le poste opérateur 54. L'ordinateur de contrôle 14 est connecté aux modules locaux au moyen de frontaux de communication 56 qui sont reliés à l'ordinateur de contrôle par des liaisons séries et aux modules locaux 52 par des liaisons à modems. A tout instant l'opérateur du Poste Central informatique 50 a à sa disposition un ensemble de fonctionnalités lui donnant accès à l'état de l'infrastructure sous contrôle. Les informations lui sont présentées sous forme de tableaux regroupant les différents états courants des quatre niveaux logiques: Zones (regroupement de carrefours)?[pound] , Axes (tronçon du réseau, de même sens de circulation sur une ou plusieurs voies)? Carrefours (sous le terme carrefour sont regroupés les niveaux physiques module local et contrôleur) ? Détecteurs (boucles magnétiques de comptage enfouies sous 5 la chaussée et utilisées aux mesures de débit en véhicules/temps et de taux d'occupation en occupation de la voie/temps) . Les actions de commande sont de deux types: celles imposées par l'opérateur à la lumière des informations qui lui sont présentées? et celles qui sont prises en automatique par le système à partir des valeurs de comptage fournies par les détecteurs. Le couplage réalisé par le système expert a pour but d'affiner- les décisions prises en automatique par l'ordinateur de contrôle 14? ces dernières étant de deux types : 1. En mode normal : - Cas du régime fluide : A partir d'un ensemble de valeurs de débits caractéristiques de chacun des détecteurs d'une zone et reflétant des conditions spécifiques du trafic, l'ordinateur de contrôle 14 choisit?par calcul de distance aux valeurs effectivement mesurées, la réponse la plus adaptée. F'3. réponse? il faut entendre ici, un plan de feux appliqué à l'ensemble des carrefours de la zone et défini par paramétrage de manière à maintenir la fluidité des écoulements de véhicules par le jeux de retenue/libérâtion sur des carrefours choisis à bon escient. - Cas du régime saturé : l'ordinateur de contrôle 14 effectue en permanence la moyenne pondérée des valeurs de taux d'occupation fournies par les détecteurs disposés sur un même axe. Lorsque cette valeur dépasse un seuil paramétré? l'ordinateur de contrôle 14 applique sur une ou plusieurs zones des plans de feux visant à la désaturation de l'axe considéré. 2 En mode dégradé : Lorsqu'un problème de dysfonctionnement touche l'une des couches de l'infrastructure?les tests d'intégrité pratiqués par chaque niveau sur les valeurs mesurées impose le basculement de l'ordinateur de contrôle 14 en mode dégradé. Dans ce cas précis?l'ordinateur de contrôle 14 choisit le plan de feux à appliquer sur une zone à partir d'un chronogramme. Dans tous les cas de figure? les actions automatiques de l'ordinateur de contrôle 14 portent sur l'ensemble des carrefours d 'une même zone. Dans ce contexte?l'application a été définie de façon à affiner les décisions globales déjà appliquées par l'ordinateur de contrôle 14 et ce? par une série d'actions ponctuelles au niveau des carrefours. Pour ce faire? il a été décidé de partager les variables taux d'occupation par axe? calculées par l'ordinateur de contrôle 14? avec la partie système expert. Ces variables ont donc été disposées dans le programme extérieur dans la partie "variables de transfert". Une base de connaissances spécifiques a ensuite été définie. Elle traite axe par axe le problème de variation du taux d'occupation en considérant non seulement sa valeur brute mais également son gradient de manière à caractériser les différentes tendances possibles d'évolution. Une gradation affinée par rapport à la notion NON SATURE/SATURE a ainsi été traduite sous forme de règle de production : Circulation fluide; Circulation dense; Pré- aturation; Anticipation; Saturâtion. Pour chaque état de chacun des axes a été ensuite défini?en tenant compte de la topologie du réseau? un ensemble de carrefours spécifiques sur lesquels des actions de modi ication de durée de vert devraient être pratiquées afin de réduire l'alimentation de l'axe en véhicules. De façon pratique sur le terrain?la diminution de la durée de vert d'un carrefour conditionne le remplissage plus ou moins important de la voie de communication qui y débouche. On parle alors de "sas de stockage" servant de zone de retenue de véhicules en amont de l'axe traité. Une autre série de variables de transfert provenant de l'ordinateur de contrôle 14 est alors utilisé de façon à ce que le système expert puisse savoir si un sas de stockage est rempli ou non. Ces variables partagées sont les taux d'occupation donnés par les détecteurs placés en" fond de sas" par rapport au sens de circulation. Lorsqu'une information concernant le remplissage d'un sas parvient au système expert celui-ci déclenche des règles visant à la fermeture des carrefours placés en amont du sas rempli A chaque minute?le système expert reçoit de l'ordinateur de contrôle 14 ces informations? déclenche un cycle de déduction puis lui renvoie des ordres de fermeture en pourcentage de diminution par rapport à la valeur qu'aurait appliquée l'ordinateur de contrôle 14 sans cela. Dans ce cas?ce sont les variables de partage de type pourcentage qui sont utilisées dans la liste des variables de transfert. Les actions du système expert sont particulièrement intéressantes dans ces états de pré- aturation ou d'anticipation? où par le jeu de modifications de type microrégulation? Il parvient à prévenir la saturation proprement dite et empêche de ce fait l'application par l'ordinateur de contrôle 14 de plans de feux de désaturation. Les pourcentages de diminution de phases sont appliqués par l'ordinateur de contrôle qui modifie les valeurs de vert sur le terrain. On a donc bien une modification du comportement du programme par action du système expert sur les variables qu'il manipule. En marge des actions de type "affectation de variables" permettant la modification du comportement de l'ordinateur de contrôle 14?il a été confié au système expert la tâche d'avertir l'opérateur des modifications d'environnement. Des règles portant sur les changements d'états des axes ont été dé inies de façon à envoyer des messages sur un écran de contrôle et d'autre part à assigner une carte de synthèse vocale. exemple: ATTENTION SATURATION DE L'AXE NUMERO 12. LE SAS NUMERO 32 EST PLEIN. En ce qui concerne les fonctionnalités graphiques du système? celles- i ont été employées à la représentation du réseau et des différentes composantes de l'infrastructure. Ces représentations permettent à l'opérateur de se renseigner à tout moment sur l'état et la disposition de ces composants en cliquant sur l'objet à l'aide de la souris afin d'obtenir sa fiche dans la base de données relationnelle. Par exemple en zoom 4?l'opérateur voit apparaître sur le dessin de la ville la représentation des contrôleurs de carrefour, les fiches "contrôleur" de la base contiennent le numéro?le nom et le type de l'armoire? la date de mise en service? la date de dernière intervention. A l'heure actuelle? la base de données contient les tables: axes? sas, carrefour, contrôleurs et détecteurs. A terme, cette base se sera enrichie d'autres informations telles que les éclairages publics ou monuments répertoriés, n'intéressant pas la circulation. Toujours en ce qui concerne les possibilités d'infographie du système, l'opérateur peut passer un ordre en français (utilisation de l'analyseur syntaxique) afin d'obtenir un renseignement ou retrouver un objet dont il ignore la position, exemple: FAIS UN ZOOM SUR LE CONTROLEUR NUMERO 32. Dans la base de connaissances du système expert des règles de manipulation ont été disposées de façon à montrer à l'opérateur les seuls éléments nécessaires à la compréhension des phénomènes en évitant les surcharges superflues. En particulier? les sas de stockage n'apparaissent sur la représentation graphique que s'ils sont réellement utilisés entant que tels. D'autre part? les sas clignotent à l'écran lorsqu'ils sont remplis grâce à la règle: Si REMP(x) = OUI alors CLIGNOTER SAS NUMERO x Message SAS x PLEIN où REMP est un tableau manipulé dans les règles et donnant pour chaque sas leur état de remplissage. On peut remarquer que la règle donnée ici en exemple est une règle générique susceptible d'être déclenchée quelle que soit la valeur de x et qu'il n'est donc pas nécessaire de la rédiger pour tous les sas. Deux fonctions supplémentaires du système de régulation méritent également d'être présentées. Elles sont toutes deux issues de la génération automatique de code et concernent les variables numériques partagées. La première permet d'obtenir la courbe d'évolution de toute variable numérique partagée. Cette représentation de courbe présente les cinq dernières heures de mesures et est adaptée au maxima et minima rencontrés. La seconde permet à l'opérateur de positionner une alarme sur n'importe laquelle de ces variables numériques. Exemple: je veux être averti lorsque la variable VAR1 sera supérieure à 100. Lorsque l'alarme est déclenchée?un message spécifique est envoyé dans la fenêtre opérateur et dupliqué sur le carte de synthèse vocale. Bien que le mode de réalisation préféré de l'invention qui vient d'être décrit soit un système de régulation du trafic urbain? Il est évident que l'invention pourrait être appliquée à tout système de gestion de processus. Ainsi, elle pourrait être appliquée à la gestion des horaires et des trajets d'un réseau de transport ferroviaire? aérien ou par autobus. Ceci est rendu possible grâce à la génération automatique par un générateur d'applications? du module de dialogue entre le système expert et le programme extérieur commandant l'ordinateur de contrôle de processus. Pour toute modification ou changement du programme extérieur? Il suffit en effet de générer automatiquement un nouveau module de dialogue. En outre? grâce à la génération automatique des modules spécifiques assurant le transfert des données entre le système expert et une base de données relationnelle ou un système graphique? et en utilisant un analyseur syntaxique convertissant automatiquement les commandes en langage naturel? la possibilité est offerte à des non spécialistes en informatique de construire leur propre application. Dans le mode de réalisation préféré? les générateurs d'applications peuvent -être différents ou être un seul générateur d'applications. En outre?au lieu de générer un code en langage C, il sera évident pour l'homme du métier que tout autre langage de type algorithmique pourrait être utilisé à la place du langage C sans sortir du cadre de l'invention. REVENDICATIONS 1. Système Informatique de gestion de processus comprenant un ordinateur de contrôle de processus (14) qui fournit des commandes destinées à modifier le déroulement du processus en réponse à des valeurs de paramètres en provenance du processus, comprenant un système expert (10) dont la base de connaissances comprend les lois devant s'appliquer au processus et un programme - extérieur commandant le f nctionnement de l'ordinateur de contrôle de processus; ledit système informatique étant caractérisé en ce que, lors de l'exécution dudit programme extérieur?ce dernier fait appel audit système expert au moyen d'un module de dialogue (1E> généré automatiquement et préalablement par un premier générateur d'applica ions ([pound]4) en utilisant conjointement ledit système expert après compilation et ledit programme extérieur avant com ilation. 2. Système informatique selon la revendication 1 dans lequel ledit premier générateur d'applications (24) génère préalablement ledit module de dialogue (12) à partir du programme extérieur commandant ledit ordinateur de contrôle 14 et du système expert (lO) en effectuant la reconnaissance dans ledit programme extérieur?des variables par leur nom et l'identifica ion de leur type?la comparaison de la liste de variables ainsi obtenue au résultat de la compilation de la base de connaissances dudit système expert et l'écriture d'un logiciel permettant le passage de la valeur de chaque variable vers ledit système expert en construisant le couple objet/valeur attendu et le retour des valeurs modifiées des variables vers ledit programme extérieur. 3. Système informatique selon la revendication 2 dans lequel le programme extérieur de commande dudit ordinateur de contrôle (14) comporte une liste des variables destinées aux échanges entre ledit programme extérieur et ledit système expert (10)? ladite liste se trouvant entre une ligne spécifique de début et une ligne spécifique de fin de façon à faciliter la reconnaissance desdites variables par ledit premier générateur d'applications ([pound]4) lors de la génération préalable dudit module de dialogue (12) . 4. Système informatique selon la revendication 3 dans lequel ledit premier générateur d'applications (24) est un générateur de code C. 5. Système informatique - selon l'une quelconque des revendica ions 1 à 3 comprenant en outre un système graphique (16) muni d'un logiciel de représentation graphique permettant la représentation graphique d'un objet quelconque du processus en utilisant les informations contenues dans une base de données relationnelle (18). 6. Système informatique selon la revendi a ion 5 dans lequel l'accès dudit système expert (10) et dudit logiciel de représentation graphique à ladite base de données relationnelle (18) se fait respectivement au moyen d'un module SE-BASE (34) et d'un module GRAPH-BASE (32) générés automatiquement et préalablement par un second générateur d'applications (36)?la génération des deux modules se faisant simultanément en utilisant la liste des tables se trouvant dans ladite base de données et pour chacune d'elles la liste des attributs et leur type. 7. Système informatique selon la revendication 6 dans lequel ledit second générateur d'applications (36) est un générateur de code en langage du type PR0*C c'est-à-dire utilisant des commandes de type requête SQL depuis des procédures en langage C. 3. Système informatique selon la revendication 6 ou 7 dans lequel un analyseur syntaxique (40) connecté entre ledit système expert (lO) et ledit module SE-BASE (34) convertit les accès à ladite base de données relationnelle (18) en Commandes entrées en langage naturel par l'opérateur. *?. Application du système informatique selon l'une quelconque des revendications 1 à 8 à la régulation du trafic urbain. c IO. Application selon la revendication 9 dans laquelle le programme de commande dudit ordinateur de contrôle de processus (14) appelle ledit système expert (10) au moyen soit d'une première commande (EXSYS(O) ) qui transmet audit système expert les valeurs courantes des variables partagées?ledit 0 programme extérieur étant en attente jusqu'à ce que ledit système expert ait terminé ses déductions et renvoyé les variables mises à jour, soi d'une deuxième commande (EXSYS(l)) pour laquelle ledit programme extérieur continue son exécution du fait que les déductions du système expert ne 5 modifient pas de variables; 11. Procédé de génération d'un module de dialogue (12) entre un système expert (lO) et un programme de commande d'un ordinateur de contrôle de processus (14) fournissant des commandes destinées à modifier le déroulement d'un processus 0 en réponse à des valeurs de paramètres en provenance du processus; Ledit procédé étant caractérisé en ce qu' il est effectué automatiquement et préalablement par un générateur d'applications (24) effectuant les étapes suivantes: -reconnaissance dans le programme de commande dudit ^ ordinateur de contrôle de processus (14) ? des variables utilisées dans le processus par leur nom et l'identification de leur type? -comparaison de la liste de variables ainsi obtenue au résultat de la compilation de la base de connaissances dudit système expert? et -écriture d'un logiciel permettant le passage de la valeur de chaque variable vers ledit système expert en construisant le couple objet/valeur attendu et le retour des valeurs modifiées des variables vers ledit programme extérieur.