FI SPECIAL ETE 96

La décadence d'une société commence quand l'homme se demande: Que va-t-il arriver? au lieu de se demander: Que puis-je faire?
(Denis de Rougemont)

de Genève - Suisse
Par Paul Skarek et Laszlo Zsolt Varga
CERN, Genève et Institut de Recherche en Techniques de Mesure et de Calcul, Budapest

Système à agents multiples pour le contrôle de l'accélérateur du CERN

Table des matières


Environnement et données du problème

Le CERN est un institut de recherche européen financé par 19 états membres, riche d'environ 3000 employés permanents. De plus, 5000 autres physiciens, ingénieurs et experts en informatique provenant de quelque 400 centres de recherche et universités distribués dans 40 pays ont la possibilité d'utiliser ses installations: les accélérateurs produisant des faisceaux de particules et les zones d'expérimentation. Le complexe d'accélérateurs du CERN est l'un des outils les plus sophistiqués au monde pour la recherche dans le domaine des hautes énergies. Son coeur est le Synchrotron à Protons (PS) qui joue le rôle d'injecteur pour les plus grands accélérateurs. L'exploitation de l'accélérateur et la maintenance du système de contrôle sous-jacent représentent des tâches extrêmement complexes. Les connaissances que cela suppose sont évidemment réparties, ainsi que le système de contrôle lui-même qui est composé de nombreux sous-systèmes différents. D'où l'idée d'appliquer à ce problème les méthodes et les solutions de type DAI (Intelligence Artificielle Distribuée) résultant de la coopération d'agents multiples [1] .
L'utilisation de systèmes experts, de la logique floue et de réseaux de neurones n'est pas neuve au CERN, où de telles applications ont souvent été développées dans diverses divisions et groupes. Les activités dans le domaine de l'Intelligence Artificielle ont débuté dans le groupe de Contrôle du PS dès 1985, avec la modélisation des procédures de contrôle et d'opération de l'accélérateur à l'aide d'une machine LISP.

retour à la table des matières

Recherches sur la coopération d'agents et ARCHON

Ce document décrit les expériences pratiques que nous avons menées dans le but de tester les résultats théoriques de la DAI dans un environnement industriel réel. Nous y discutons les aspects théoriques et les résultats pratiques obtenus dans le cas du contrôle et de l'exploitation de l'accélérateur [2] . Le CERN a participé au projet ARCHON(tm) [3] [4] [5] , qui fait partie du programme ESPRIT-II. Sa contribution fut la mise à disposition de son système de contrôle d'accélérateur et de deux systèmes experts comme environnement de développement et d'évaluation pour les méthodologies et les logiciels issus de cette collaboration.

Le logiciel ARCHON est une couche coopérative permettant la combinaison de systèmes semi-autonomes partageant un but commun défini implicitement, qui dans notre cas est le contrôle fiable de l'accélérateur. Les divers agents peuvent être des systèmes pré-existants, car dans l'architecture d'ARCHON un agent est défini comme un Système Intelligent indépendant auquel on a ajouté la couche ARCHON. Les Systèmes Intelligents (bases de données, systèmes experts, systèmes de contrôle) sont des systèmes génériques industriels ayant chacun leur champ d'application propre. La couche ARCHON fournit les fonctionnalités nécessaires pour assurer l'aspect coopératif, de sorte que les agents peuvent communiquer entre eux pour coordonner leurs tâches de la même façon que les opérateurs humains qui, dans la chambre de contrôle, décident quand et comment coopérer.
Les problèmes, les éléments de compréhension et les expériences faites lors du déploiement de la technologie ARCHON pour cette application réelle, ainsi que pour une autre application en Espagne (un système de distribution d'électricité) sont également décrits dans la référence [6].

retour à la table des matières


Systèmes experts coopératifs au CERN

Une méthode générale a été développée au CERN pour la coopération de systèmes experts ayant la particularité de créer des arbres d'hypothèses pour leurs diagnostics [1] . Cette méthode utilise essentiellement un type de coopération où les résultats sont partagés, ce qui permet d'accélérer le processus de diagnostic et de produire des résultats plus détaillés.

La coopération est basée sur l'échange d'hypothèses, ce qui s'adapte de façon naturelle dans la structure de diagnostic des systèmes experts et peut donc être appliquée aux systèmes experts déjà existants au prix seulement de légères modifications. En fait, l'échange d'hypothèses en tant que moyen de coopérer s'est avéré une méthode ayant un champ d'application plus général que simplement celui des diagnostics de systèmes experts.

Nous définissons une hypothèse généralisée comme un triplet constitué d'un objet, d'un élément susceptible d'être entaché d'une erreur et d'une méthode de vérification (comment procéder pour établir un diagnostic). Ce triplet constitue un paquet de connaissance dans un sens plus large. Les tâches impliquées par les méthodes de vérification peuvent être distribuées dans la communauté des agents. L'unité conceptuelle constituée par une hypothèse généralisée représente l'élément de connaissance de base, et l'échange d'hypothèses lors d'actions coopératives doit être formalisé en tant qu'échange de tels éléments. Cela revient à établir une stratégie d'Hypothèse-et-Test dans une forme distribuée mais néanmoins très compacte. Nous avons montré [2] que les concepts de diagnostic (tels que les symptômes ou les hypothèses d'erreur) et les concepts de tâche (tels que la surveillance, l'établissement d'un diagnostic, le contrôle et les actions correctives) peuvent aisément s'exprimer à l'aide de nos hypothèses généralisées.

La généralisation du concept d'hypothèse d'erreur a deux avantages majeurs: premièrement, elle donne une vue unifiée du contrôle, du diagnostic et de la correction, ce qui permet d'associer aisément les différentes tâches impliquées par le contrôle de l'accélérateur aux divers agents coopératifs; deuxièmement, elle offre une méthode évidente pour la transformation de systèmes intelligents autonomes en un système multi-agent coopérant par l'échange d'hypothèses.

retour à la table des matières

Le "SETUP" de l'accélérateur

Le SETUP est une collection de programmes permettant d'amener un équipement, un module d'interface ou une combinaison de ces deux types d'objets dans un état opérationnel. Il est naturel d'imaginer le SETUP comme une partie intégrante d'un système général de recherche d'erreurs. Il est le complément du module de diagnostic non seulement par le potentiel de correction qu'il apporte, mais également plus directement par ses capacités de diagnostic propres. L'établissement d'un diagnostic suppose que l'on effectue certains tests décrits par la méthode de vérification.
Dans un cas simple, il s'agit de lire un code d'alarme émis par l'équipement, mais en appelant le SETUP à la rescousse, le module de diagnostic peut exécuter des tests plus complexes et recevoir de l'information de plus haut niveau. Ces scénarios ont été proposés comme améliorations de l'actuel système de SETUP [7] .

Dans certains scénarios, des appels mutuels répétitifs entre agents sont possibles et peuvent conduire à des boucles infinies, voire à des appels récursifs de profondeur infinie. La détection d'une boucle infinie ou d'appels récursifs est difficile, parce qu'un agent ne peut pas établir de façon fiable à partir de l'information locale dont il dispose si l'action de l'autre agent impliqué est une réponse ou non à un message qui lui a été envoyé. Nous avons développé un algorithme de détection de boucles infinies [2] et nous l'avons également intégré dans le concept d'hypothèse généralisée.

retour à la table des matières

Système de synchronisation de l'accélérateur

La coopération entre divers aspects du diagnostic de synchronisation fournit un autre exemple d'agents coopératifs. Le système de synchronisation de l'accélérateur a deux fonctions principales: la première est de fournir un contrôle en temps réel indépendant de l'opérateur; la seconde, d'établir la séquence des différents modes opérationnels et de leur attribuer des plages de temps partagé. En pratique, il s'agit de répartir les différents faisceaux de particules à travers les accélérateurs chaînés. Il y a dans ce cas trois types de diagnostic associés aux trois niveaux du système de synchronisation:
  1. la programmation des modes opérationnels mentionnés ci-dessus,
  2. la génération de la base de temps principale,
  3. les bases de temps secondaires dérivées de cette base de temps principale et dépendant des changements de mode opérationnels.

Au niveau de la programmation des modes opérationnels, le système de diagnostic et de vérification [8] , qui est appelé le Vérificateur du Diagramme de Coordination de Faisceau (DCF), doit détecter l'éventuelle impossibilité de réalisation du programme par les accélérateurs. Au niveau de la base de temps principale, le système de diagnostic doit aider à la compréhension du comportement du générateur de temps. Au niveau des bases de temps secondaires, le système de diagnostic doit détecter d'éventuelles erreurs dans la génération de signaux.

Ces différents aspects ont de fortes corrélations. Certaines restrictions exprimées dans les règles constituant la programmation des modes opérationnels sont partiellement basées sur le résultats de l'analyse effectuée au niveau des bases de temps. Par exemple, si le générateur de base de temps principal ne peut jamais sélectionner une certaine combinaison lors de l'établissement d'une séquence de fonctionnement, cette combinaison peut être exclue déjà au niveau de la programmation. Automatiser la rétroaction entre les agents de diagnostic de niveaux inférieurs et la programmation des modes opérationnels de haut niveau revient à établir un mécanisme d'apprentissage automatique.

retour à la table des matières

Le Vérificateur DCF en tant que mini-système expert

Lorsqu'on doit résoudre un problème pratique à l'aide d'un système expert, la première chose à faire après l'analyse du problème est de sélectionner l'approche et les outils les mieux adaptés à ce problème. Souvent, une approche basée sur le concept de règles peut satisfaire les besoins. Le choix se porte alors généralement sur un système qui peut être coûteux et qui de plus n'est pas disponible en standard dans l'environnement logiciel en place. Très fréquemment, ce système expert offre beaucoup plus de possibilités que nécessaire pour résoudre le problème donné, et une fois acheté il doit encore faire l'objet de maintenance et de mises à jour qui augmentent encore les coûts. Nous préconisons donc d'utiliser plutôt un logiciel de bases de données quelconque déjà disponible, offrant un moteur de recherche généraliste. Les moteurs de recherche des bases de données utilisent en effet des algorithmes très proches de ceux utilisés par les moteurs d'inférence des systèmes expert.
C'est cette dernière approche qui a été utilisée pour développer l'outil de diagnostic correspondant au niveau 1) du processus de synchronisation (programmation des modes opérationnels). Nous avons développé un langage orienté-règles semblable au SQL, mais comprenant des expressions spéciales correspondant aux concepts DCF. De cette façon, la syntaxe des règles est facile à apprendre, et de plus elles sont facilement traduisibles en requêtes SQL. Les descriptions DCF, qui sont stockées dans un base Oracle, sont transformées sous forme de tables auxquelles les règles peuvent plus facilement être appliquées. L'utilisateur crée les règles à l'aide de l'Editeur de Règles DCF et l'Editeur les transcrit en expressions SQL. Le Vérificateur DCF applique ces expressions SQL aux DCF. En fait, avec l'aide de l'interprèteur SQL, il joue le même rôle que le moteur d'inférence d'un système expert. Nous avons maintenant un an d'expérience avec cet outil et les opérateurs de l'accélérateur le trouvent hautement utile.

retour à la table des matières

Se préparer pour le futur

Si l'on considère ce qui tourne et est utilisé réellement aujourd'hui dans la salle de contrôle du PS, on pourrait être déçu. Mais on ne doit pas perdre de vue que toutes les études mentionnées ici ont été réalisées avec des ressources humaines minimes en comparaison de ces ambitieux projets; et la Division Accélérateurs du CERN a toujours été considérée comme un service institutionnel dédié aux physiciens et à leurs expériences, ce qui laisse peu de place pour la recherche dans ce groupe.

Laissez-nous conclure avec une anecdote: lorsqu'un des auteurs (P.S.) commença son travail au CERN en 1962, il dépensa beaucoup d'énergie pour convaincre son patron de passer de l'assembleur au FORTRAN comme langage de programmation. En vain! Quelques années plus tard, FORTRAN était devenu le principal langage utilisé au CERN. Le même auteur, à nouveau en avance sur son temps, se heurta à un refus lorsqu'il demanda au Centre de Calcul à pouvoir utiliser un compilateur C++. "Trop cher et aucun besoin pour un langage aussi excentrique" fut la réponse! De nos jours, C++ est considéré au CERN comme un langage orienté-objets rendant de grands services. C'est pourquoi nous ne sommes ni déçus, ni découragés. Du moment que nous sommes nous-mêmes convaincus par nos études, nous continuons à préparer le futur, et en particulier celui du CERN!

retour à la table des matières

References

  1. F. Perriollat, P. Skarek, "Applications of Distributed AI for Accelerator Control", Proc.11th IASTED Intern.Conf. on APPLIED INFORMATICS, Annecy, France, May 19-21, 1993, ISBN:0-88986-175-7, ed. M.H. Hamza, pp.129-130.

  2. P. Skarek, L. Varga, "Multi-agent Cooperation for Particle Accelerator Control", in CRITICAL TECHNOLOGY, (eds.) J.K.Lee, J.Liebowitz, Y.M.Chae, Proceedings of the 3nd World Congress on Expert Systems, Febr.5-9, 1996, Cognizant Communication Corp., New York, Sydney, Tokyo, pp. 798-806.

  3. Th. Wittig (ed.), (1992). ARCHON: An Architecture for Multi-Agent Systems. Ellis Horwood, ISBN 0-13-044462- 6.

  4. F. Perriollat, P. Skarek, L.Z. Varga, "Report on the CERN Application Study", ESPRIT P-2256 Techn.Note CERN/ARCHON/TN 07/ 11-93.

  5. F. Perriollat, P. Skarek, L. Varga, "Cooperating Expert Systems in Accelerator Control - Results and CERN's Contributions to the ESPRIT-II ARCHON Project", CERN/PS Internal Report 94-39 (CO).

  6. N.R. Jennings, J. Corera, I. Laresgoiti, E.H. Mamdani, F. Perriollat, P. Skarek, L.Z. Varga, (1996). "Using ARCHONTM to develop real-world DAI applications for electricity transportation management and particle accelerator control. To appear in IEEE Expert - Special Issue on Real World Applications of DAI; 1996.

  7. G. Daems, V. Filimonov, V. Homutnikov, F. Perriollat, Yu. Riabov, P. Skarek, "A Knowledge Based Control Method: Application to Accelerator Equipment Setup", presented at the Intern. Conf. on Accelerator and Large Experimental Physics Control Systems, ICALEPCS-93, Berlin, Germany, Oct. 18-22, 1993.

  8. J. Lewis, P. Skarek, L. Varga, "A Rule-Based Consultant for Accelerator Beam Scheduling Used in the CERN PS Complex", ICALEPCS-95, Chicago, USA, Oct.29-Nov.3, 1995.

TERRA INFORMATICA


retour à la table des matières
retour au sommaire des FI 96
Vos commentaires
© FI-SP96-3 septembre 1996