1 / 17

Proposition du lancement conjoint SECC/SR d’une nouvelle action spécifique CNRS/STIC

Proposition du lancement conjoint SECC/SR d’une nouvelle action spécifique CNRS/STIC. Observation et supervision de systèmes complexes, répartis et dynamiques. Claude Jard, IRISA/ENS Cachan-Bretagne, Rennes Jean-Bernard Stéfani, INRIA/Rhône-Alpes, Grenoble. Réunion du RTP/SECC,

cade-newman
Download Presentation

Proposition du lancement conjoint SECC/SR d’une nouvelle action spécifique CNRS/STIC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Proposition du lancement conjoint SECC/SR d’une nouvelle action spécifique CNRS/STIC Observation et supervision de systèmes complexes, répartis et dynamiques Claude Jard, IRISA/ENS Cachan-Bretagne, Rennes Jean-Bernard Stéfani, INRIA/Rhône-Alpes, Grenoble Réunion du RTP/SECC, Paris, le 16 juin 2003

  2. Les enjeux : “self-management” • Avec l'avènement d'une informatique ubiquitaire, commande et administration de systèmes prennent une importance cruciale. • En effet, compte tenu des niveaux de complexité, des temps et des échelles de réaction impliqués, ces fonctions ne pourront être mises en oeuvre avec le seul moyen de « l’humain dans la boucle ». • D'où l’enjeu que constitue la mise en place d'infrastructures auto-administrables, auto-reconfigurables, et, dans la mesure du posible, auto-réparables, tout en offrant des garanties de sûreté et de qualité dans leur comportement et les services offerts. Comment concevoir un observateur (outil capable d'inférer l'état d'un système à partir des observations disponibles) pour un système distribué, asynchrone, ouvert, reconfiguré dynamiquement, et de taille gigantesque ?

  3. Des verrous scientifiques • Dynamicité : les caractéristiques, la configuration et la charge des systèmes concernés ne sont pas fixées à l'avance et peuvent évoluer au cours du temps (nouveaux éléments ajoutés ou enlevés dynamiquement, mobilité physique et logique, occurrences de pannes). • Répartition: les systèmes visés impliquent plusieurs éléments interconnectés, géographiquement dispersés, et doivent être conçus comme des collections de domaines de ressources et d'administration autonomes. • Multi-échelle : les systèmes visés comportent des éléments de traitement, de stockage et de communication de l'information caractérisés par des capacités très variables et mobilisables à des échelles différentes (hiérarchies de réseaux de processeurs et de noeuds de stockage). • Extrême irrégularité : les systèmes visés se caractérisent par une très forte hétérogénéité de leurs éléments et de leurs modes d'organisation; ils comportent des éléments aux capacités et aux fonctions très diverses, accessibles à des conditions et en fonction de politiques d'accès multiples et en constante évolution.

  4. Le travail de prospective de l’action : le traitement conjoint des aspects « observation » (système) et « supervision/diagnostic » (algorithme) • Les fonctions d'observation et de supervision sont des fonctions de base de la commande et de l'administration, intervenant dans toutes les fonctions de gestion standards (configurations, performances, fautes, sécurité, et coûts). • En présence de systèmes aussi complexes que de grands systèmes répartis, l'observation ne saurait être découplée de fonctions de diagnostic et d'analyse permettant de caractériser l'état d'un système. L’action devra émettre des propositions pour essayer de combler le fossé actuel entre les recherches sur le “contenant” (architecture système, composants logiciels) et celles sur le “contenu” (algorithmes de diagnostic et supervision, généralement fondés sur des modèles formels).

  5. Quelques sujets de réflexion (I) • Instrumentation dynamique : l'observation d'un système repose à la base sur la pose de sondes (matérielles ou logicielles) permettant de détecter événements et changements d'états pertinents. Dans des systèmes hautement dynamiques, combinant différentes couches et niveaux de composants, il devient nécessaire de pouvoir poser des sondes d'observation à différents niveaux, non prédéterminés, et de pouvoir établir des corrélations entre les observations effectuées à ces différents niveaux (exemple du suivi de la consommation de ressources). • Gestion d'événements : l'observation suppose la capture d'événements pertinents au cours de l'exécution d'un système. Dans le cas d'un grand système réparti hautement dynamique, la capture d'événements pose des problèmes de détection et des problèmes de passage à l'échelle.

  6. Quelques sujets de réflexion (II) • Modèles de systèmes et modèles de programmation : les constructions systèmes envisagées devraient idéalement être spécifier de manière formelle. Cela s'avère ici crucial pour connecter les outils d'observation à des outils spécialisés qui dépendent d'une modélisation précise du système, comme les outils de diagnostic pour la détection et le traitement d'événements. • Algorithmique répartie de diagnostic : fondée sur un modèle de production et propagation des événements (par ex. alarmes), elle doit non seulement être modulaire, mais aussi permettre de prendre en compte l’évolution dynamique du système, éventuellement même par une modification en ligne du modèle. La robustesse de cette algorithmique demande à être particulièrement soignée vis-à-vis de l’incomplétude inévitable du modèle et des observations.

  7. Les équipes pilotantes Il s ’agit d ’une nouvelle coopération • Nouvelle équipe « télécom » en cours de construction à l’Irisa (A. Benveniste, C. Jard) : équipe pluridisciplinaire mixte Irisa/ENS Cachan-Bretagne, capitalisant plusieurs années de collaboration sur le thème du diagnostic des réseaux de télécommunications (projets RNRT Magda) • Equipe SARDES (JB. Stéfani) : équipe mixte Inria/LSR, développant une approche formalisée de la construction des systèmes répartis. La pluridisciplinarité de l’action se reflète par cette proposition de double reconnaissance RTP/SECC (pour l’aspect modèles formels et systèmes complexes) et RTP/SR (pour l’aspect systèmes répartis et composants logiciels). C. Jard et JB. Stéfani sont respectivement dans les comités de pilotage de ces RTP.

  8. Des équipes partenaires • LIP6, Paris : L. Seinturier, P. Sens) - tissage dynamique d'aspects, détection de fautes, journalisation • LAAS, Toulouse (J.C. Fabre) - détection de fautes • LORIA, Nancy (O. Festor) - gestion de réseaux Partenaires étrangers intéressés par ce travail de prospective : • ETH, Zurich (G. Alonso) - instrumentation dynamique, tissage dynamique d'aspects • EPFL, Lausanne (R. Guerraoui) - canaux de notification (architecture, filtrage, routage), détection de fautes • Univ. Michigan, US, (S. Lafortune) - diagnostic SED + contacts industriels des équipes : France-Telecom, Alcatel, ...

  9. Mode de travail Des réunions de travail régulières et ouvertes dans l’objectif : • de partager les avancées et réflexions des équipes sur les sujets de l’action, • de rédiger un document de prospective avec des propositions de développement de ce nouveau sujet scientifique. • Si possible, développer un support à la réflexion en installant une plate-forme d ’expérimentation liant les partenaires du projet (chercher un autre appui logistique et financier)

  10. diagnoser diagnoser supervision telecommunications network The diagnosis problem : definition • Fault propagation – causality • Alarm interleaving – concurrence • Distributed processing

  11. The diagnosis problem : SDH example alarm LOS notification State_Change() + vertical propagation alarm TF notification State_Change() ADM ALS ADM alarm LOS + vertical propagation alarm TF OpticalSPITTPBdir OpticalSPITTPBdir

  12. Topology / Connections Device (NE) specificities Managed Objects (MIB) Experts knowledge Fault Model Can be automated Diagnosis process diagnosed fault scenario(s) alarms Fault model-based approach

  13. Fault model generated alarms fault scenario Diagnosis process diagnosed fault scenario(s) observed alarms Fault model-based approach: model inversion • Fault model replicates the fault behaviour of the network • initial faults, their propagation, and the observed alarms • Diagnosis algorithms inverse the model! • distributed dynamic programming methods • Uncertainties in the behaviour • probabilities can be introduced in the model

  14. Montrouge Fault model-based approach : methodology • physical network topology • Structural model • network elements • connections model • Behavioural model SDH Ring

  15. Managed Object Fault model-based approach : behavioural model • Elementary Sequence Diagram (UML extension) • pre-condition: attributes, received messages • action: sending messages, changing attribute values • post-condition: attributes, sent messages

  16. detection of the emission interruption and respective actions detection of the absence of signal caused by the distant device actions in case of the absence of signal automatic laser switch mechanism Fault model-based approach : behavioural model

  17. Aubervilliers Montrouge St Ouen Gentilly Fault model-based approach : correlation tree AU-AIS AU-AIS disabled AU-AIS AU-AIS AU-AIS disabled AU-AIS MS-AIS MS-AIS TF disabled LOS disabled LOS TF

More Related