FR2817983A1

FR2817983A1 - Procede et systeme pour la gestion d'alarmes

Info

Publication number: FR2817983A1
Application number: FR0015991A
Authority: FR
Inventors: Olivier Louer
Original assignee: Matra Nortel Communications SAS
Current assignee: Nortel Networks France SAS
Priority date: 2000-12-08
Filing date: 2000-12-08
Publication date: 2002-06-14
Anticipated expiration: 2020-12-08
Also published as: AU2002222021A8; WO2002046940A2; WO2002046940A3; AU2002222021A1; FR2817983B1

Abstract

Le procédé permet un maintien en cohérence de valeurs d'attributs d'alarmes enregistrées dans plus d'un registre de consignation d'un système. Un discriminant d'alarme prélevé dans un enregistrement dont un changement est notifié, permet d'identifier un enregistrement de même alarme dans un autre registre de consignation.Dans le système, un sous-système local (58, 59) comprend un discriminateur de retransmission d'événements (43, 46) pour envoyer les notifications de changement qui circulent sur son infrastructure de communication (32, 33), vers l'infrastructure de communication (34) d'un sous-système général (27). Le sous-système général comprend un gestionnaire de registre de consignation (40) pour prélever un discriminant d'alarme dans un enregistrement signalé par une notification de changement d'attribut circulant sur son infrastructure de communication (34), pour identifier un enregistrement correspondant dans celui des registres de consignation qui ne comprend pas l'enregistrement signalé, et pour remplacer ledit enregistrement correspondant par ledit enregistrement signalé.

Description

PROCEDE ET SYSTEME POUR LA GESTION D'ALARMES

Le domaine de l'invention est celui de la gestion des alarmes dans les systèmes informatiques répartis et dans les réseaux qui interconnectent plusieurs équipements informatiques et ou de télécommunications.

De façon à pouvoir regrouper et traiter les alarmes générées par des équipements informatiques qui proviennent de différents constructeurs, il est nécessaire de respecter une norme. Un exemple d'ensemble de standards relatifs au transfert de l'information de gestion est donné par les recommandations de l'organisation ITU (International Telecommunication Union), parmi lesquelles on trouve les recommandations CMIS/CMIP ("Common Management Information Services" : Recommandation UIT-T X. 710 (1997)) tSO/CEi 9595 : 1998,"Technologies de l'informationInterconnexion des systèmes ouverts-Service commun de transfert d'informations de gestion" ;"Common Management Information Protocol" : Recommandation UIT-T X. 711 (1997) IISO/CEI 9596-1 : 1998,"Technologies de l'information-Interconnexion des systèmes ouverts-Spécification du protocole commun de transfert d'informations de gestion"), complétées par la

recommandation X. 733 ("Technologies de l'information-Interconnexion de systèmes ouverts-Gestion des systèmes : Fonction de signalisation des alarmes", CCITT, UIT, Genève, 1992) qui décrit la fonction de compte-rendu d'alarme, la recommandation X. 734 ("Technologies de l'informationInterconnexion de systèmes ouverts-Gestion des systèmes : Fonction de gestion des rapports d'événement", CCITT, UIT, 09/92) qui décrit la fonction de gestion de compte-rendu d'événement et la recommandation X. 735 ("Technologies de l'information-Interconnexion de systèmes ouvertsGestion des systèmes : Fonction de commande des registres de consignation", CCITT, UIT, 09/92) qui décrit la fonction de contrôle de registre de consignation ("Log Control Function"). Le standard industriel SNMP ("A

Simple Network Management Protocol-SNMP", RFC 1157, IETF, Mai 1990) constitue une norme simplifiée souvent utilisée dans l'environnement des réseaux de transmission de paquets selon le protocole IP ("Internet Protocol", RFC 791, IETF, Septembre 1981).

Un agent génère une alarme avec, comme attributs les plus couramment usités, le type d'alarme, la classe et l'instance de l'objet émetteur de l'alarme, la cause probable de l'alarme, la sévérité, le problème spécifique, des valeurs d'attributs supervisés et du texte libre.

Le type d'événement ("Event type") indique si l'événement dont résulte l'alarme, concerne un équipement, des communications, un traitement, une qualité de service ou l'environnement d'un équipement.

Chaque entité du réseau représente une instance d'objet géré ("Managed Object Instance"-MOI) au sein d'une classe d'objet géré ("Managed Object Class"-MOC). La gravité accordée à l'alarme est de niveau indéterminé, critique, majeur, mineur, avertissement ou effacée. Le problème spécifique ("Specific problem"), autre paramètre défini dans la norme X. 733, est un raffinement de la cause probable ("Probable cause") fournie par le constructeur. Les attributs supervisés ("Monitored attributes") prennent des valeurs remontées dans l'alarme qui concernent l'objet émetteur, telles qu'une température, une intensité électrique ou une quantité de données.

L'alarme est enregistrée dans un registre de consignation ("Log"), dont la norme X. 735 fournit une définition, avec des attributs supplémentaires qui permettent la gestion des alarmes. L'identifiant est un attribut de nommage de l'enregistrement, représenté par exemple par un nombre entier naturel incrémenté à chaque présentation d'une nouvelle alarme. Le compteur indique le nombre d'alarmes identiques à celle de l'enregistrement dans le registre de consignation. Il est usuel de considérer que deux alarmes sont identiques si les attributs de type d'événement, d'instance d'objet géré, de cause probable et de problème spécifique ont les mêmes valeurs. L'état d'une alarme indique par ailleurs si un opérateur a pris en compte l'alarme (acquitté, ignoré) ou non (signalé). Dans le cas où l'opérateur a pris en compte l'alarme, l'état

acquitté ("acknowledged") indique qu'il souhaite voir s'afficher les nouvelles occurrences de l'alarme à travers le compteur. L'état ignoré ("ignored") indique que l'opérateur souhaite ignorer les occurrences suivantes de l'alarme. L'identifiant de ticket d'incident ("trouble ticket"), éventuellement associé à l'alarme par l'opérateur, permet d'établir un lien de couplage avec un logiciel de gestion d'incidents. Un ticket d'incident est une structure de données comprenant différents champs renseignés par l'opérateur, de façon à pouvoir être exploités par du personnel de maintenance. Le personnel de maintenance peut ensuite compléter d'autres champs du ticket d'incident avec des solutions employées pour réparer l'incident. Une conservation des tickets d'incidents dans une base de données facilite ensuite des réparations d'incidents produits ultérieurement dans des conditions comparables. La cause de terminaison de l'alarme indique si la disparition de l'alarme résulte d'un effacement en provenance du réseau, d'une terminaison manuelle ou d'une clôture de ticket d'incident associé.

Un logiciel de gestion d'alarmes accède à la structure de données du registre de consignation au moyen d'un pointeur pour afficher les alarmes avec leurs attributs sur un écran et pour permettre à l'opérateur de modifier certaines valeurs d'attributs autorisées. C'est par exemple le cas de l'attribut d'état (signalé, acquitté, ignoré), de l'identifiant de ticket d'incident et de la cause de terminaison d'alarme.

L'invention concerne plus particulièrement une gestion des alarmes organisée de façon délocalisée. Dans le cas où différents équipements d'un réseau de communication sont regroupés par zones, un registre de consignation et son logiciel de gestion sont alloués à chaque zone et résident généralement dans un équipement de la zone à laquelle ils sont alloués. Un opérateur surveille les alarmes de la zone dont il est responsable au moyen d'interfaces homme-machine sur lesquels le logiciel de gestion de la zone affiche les alarmes avec leurs attributs et modifie les attributs sous commande de l'opérateur, au moyen d'un pointeur sur les enregistrements du registre de consignation.

Pour permettre à un opérateur de surveiller les alarmes de plusieurs zones, il convient de mettre à sa disposition un registre de consignation où sont enregistrées les alarmes des zones à surveiller.

Une solution consistant à mettre en oeuvre un seul registre de consignation pour enregistrer les alarmes de toutes les zones du réseau n'est pas satisfaisante. Cette solution nécessite un mécanisme de filtrage complexe pour n'afficher et ne permettre à un opérateur en charge de surveiller une seule zone, d'intervenir que sur les seules alarmes de sa zone. Si un logiciel de gestion d'alarme pour chaque zone accède au registre de consignation, il est nécessaire de maintenir une cohérence de données sur le registre de consignation partagé. D'autre part, un registre de consignation unique peut poser problème en cas de rupture de communication avec l'équipement qui l'héberge.

Il est préférable d'avoir un registre de consignation local affecté à chaque zone du réseau. Dans le cas d'une gestion d'alarme organisée de façon hiérarchique, un registre de consignation général regroupe les alarmes des registres de consignation qu'il supervise. De façon plus générale, dans le cas d'une gestion d'alarme partagée d'une première zone avec une autre zone, le registre de consignation de l'autre zone regroupe les alarmes de la première zone avec les siennes.

Cependant, l'existence de plusieurs registres de consignation avec des enregistrements communs d'une même alarme pose le problème du maintien en cohérence des valeurs d'attributs des alarmes enregistrées conjointement dans plusieurs registres de consignation.

L'enregistrement d'une alarme dans plusieurs registres de consignation, est réalisé d'une manière connue en soi. Lorsqu'un agent génère une alarme, celle-ci est enregistrée dans le registre de consignation affecté à la zone dont elle est originaire avec un premier identifiant. L'alarme est enregistrée dans le registre de consignation qui regroupe les alarmes de ladite zone et celles d'une autre zone, avec un deuxième identifiant généralement différent du premier identifiant du fait que les identifiants des deux registres de

consignation ne dénombrent pas les mêmes ensembles d'alarmes.

Pour afficher chaque alarme, le logiciel de gestion affecté à ladite zone, pointe sur le premier identifiant dans le registre de consignation de ladite zone, le logiciel de gestion affecté à plusieurs zones pointe sur le deuxième identifiant dans l'autre registre de consignation.

Cependant, un opérateur pourra être amené à modifier une valeur d'attribut au moyen du logiciel de gestion dont il dispose, lequel pointe uniquement sur l'identifiant de l'alarme dans le registre de consignation auquel il est lié. La difficulté est de répercuter le changement d'attribut dans l'autre registre de consignation.

Pour résoudre cette difficulté, l'invention a pour objet un procédé qui prélève un discriminant d'alarme dans un enregistrement notifié.

Ainsi, en configurant le logiciel de gestion au moyen duquel un opérateur modifie une valeur d'attribut dans un enregistrement de premier registre de consignation, de façon à notifier l'enregistrement par une notification de changement d'attribut, un discriminant d'alarme prélevé dans l'enregistrement notifié permet d'identifier un enregistrement de la même alarme dans un autre registre de consignation, de façon à maintenir cohérente la valeur d'attribut modifiée, pour chacun des enregistrements dans le premier et le deuxième registre de consignation.

Plusieurs détails et avantages sont illustrés dans l'exemple de mise en oeuvre de l'invention dont la description suit en référence aux figures où : * La figure 1 présente une plate-forme d'administration de réseau ; * La figure 2 présente plusieurs plates-formes d'administrations dans un cas de répartition par zone ;

'La figure 3 présente différentes étapes d'un procédé conforme à l'invention.

En référence à la figure 1, différents sites comprennent des équipements 17 à 19,14 à 16,11 à 13, raccordés en réseau. Une plate-forme d'administration 7 comprend une infrastructure de communication, par

exemple un bus 8 auquel accèdent des agents 9, 10 qui gèrent une base de gestion d'information ("Management Information Base", MIB) 25, 26 des équipements de réseau 11-19 dont ils ont la charge. Les équipements 11 à 13 génèrent par exemple des notifications d'événements tels que des alarmes au format SNMP. L'agent 9 convertit alors ces notifications au format X. 733 pour les mettre à disposition sur le bus 8. Les équipements 14,15, 16 et 17,18, 19 sont par exemple des équipements de télécommunication qui génèrent des notifications d'événements tels que des alarmes dans un format qui leur est propre. L'agent 10 convertit alors ces notifications au format X. 733 pour les mettre à disposition sur le bus 8. La génération de notification d'événement peut se faire à l'initiative des équipements 11-19 ou en réponse à une requête périodique d'interrogation de changement d'état en provenance d'un agent 9- 10. Un gestionnaire d'alarme 21 capte les alarmes X. 733 émises sur le bus 8, par exemple au moyen d'un mécanisme d'abonnement interne, et les mémorise, via le bus 8, dans la base de données 20 qui contient une structure de données de registres de consignation pour enregistrer les alarmes et leurs attributs. Bien entendu, l'agent 9,10 et sa MIB associée 25,26 pourrait, d'une manière connue en soi, être embarqué au sein d'un des équipements qu'il supervise 11-19, auquel cas les notifications d'événements transmises à la plate-forme d'administration 7 seraient directement au format X. 733. Un module de commande et d'interface homme-machine (C-IHM) 22 vient régulièrement lire le contenu de la base 20 pour le présenter sur un organe d'affichage 23 à un opérateur. Celui-ci peut alors, par l'intermédiaire d'un organe de saisie 24, modifier les valeurs de certains au moins des attributs des enregistrements d'alarmes, modifications qui sont répercutées dans la base 20 par le module 22. Ainsi, le module de commande et d'interface IHM 22 affiche chaque nouvelle alarme présentée sur le bus 8 avec comme valeur initiale d'attribut d'état signalé ("unspecified"). Si l'opérateur effectue au moyen de l'organe de saisie 24, une action pour ignorer l'alarme, l'attribut d'état passe de la valeur signalé à la valeur ignoré . Si l'opérateur effectue au moyen de l'organe de saisie 24, une action pour acquitter l'alarme,

le module 22 fait passer l'attribut d'état de la valeur signalé à la valeur acquitté . Si l'opérateur effectue au moyen de l'organe 24, une action de restauration, le module 22 fait repasser l'attribut d'état à la valeur signalé . Dans le cas où une nouvelle occurrence de l'alarme se produit, le module 22 réinitialise systématiquement l'attribut d'état à la valeur signalé si la valeur est acquitté .

L'opérateur peut aussi modifier au moyen de l'organe de saisie 24, les valeurs de l'attribut identifiant un ticket d'incident et de l'attribut indiquant la cause de terminaison d'une alarme.

La figure 2 présente un système informatique comprenant des soussystèmes informatiques 58,59, 27 reliés par un réseau de communication 28. Les sous-systèmes informatiques 58,59, 27 sont du type de la plate-forme d'administration 7 précédemment décrite. De façon à ne pas surcharger inutilement la figure, ne sont représentés ici que les éléments essentiels à la compréhension de l'invention. Chacun des sous-systèmes 58,59, 27 comprend respectivement une infrastructure de communication 32,33, 34, par exemple du type du bus 8.

Les sous-systèmes informatiques 58,59 constituent des soussystèmes informatiques locaux pour administrer chacun une première zone de sites sur le modèle de la plate-forme d'administration 7, et comprennent chacun respectivement un ou plusieurs agents 35,36 pour remplir les fonctions des agents 9,10.

Le sous-système informatique 27 constitue un sous-système informatique général pour administrer hiérarchiquement plusieurs premières zones, administrées chacune par un sous-système informatique local. L'une de ces premières zones peut aussi être administrée directement par le sous système informatique 27, auquel cas le sous-système 27 comprend un agent 57 pour remplir les fonctions des agents 9,10. L'ensemble des zones administrées par le sous-système informatique 27, constitue une deuxième zone qui inclut au moins une dite première zone. Le sous-système 27 comprend un module d'interconnexion d'infrastructures distribuées (lid) 37

pour mettre à disposition sur le bus 34 des notifications d'événements en provenance des sous-systèmes informatiques locaux 58, 59.

Dans le sous-système 27, une structure de données de registre de consignation 31, est prévue pour enregistrer des alarmes de l'ensemble des zones administrées. Chaque alarme y est par exemple repérée par un identifiant numérique 1,2, 3,4, 5,6 dont la valeur suit l'ordre de présentation des alarmes sur le bus 34.

Dans le sous-système local 58, une structure de données de registre de consignation 29 est prévue pour enregistrer les alarmes de la zone administrée, repérées chacune par exemple par identifiant 1', 2', 3'dont la valeur suit l'ordre de présentation des alarmes sur le bus 32. Un module d'interconnexion des infrastructures distribuées 38, dont les fonctions correspondent à celle du module 37 précédemment décrit, gère en outre des discriminateurs de retransmission d'événement ("Event forwarding discriminator"-EFD, CCITT Recommandation X. 734, UIT, Sept. 92).

La suite du présent exposé fait référence à la description des discriminateurs de retransmission d'événement de la recommandation X. 734 du CCITT (ITU). Un tel discriminateur permet d'envoyer à un service abonné à ce discriminateur, notification de tout événement qui répond à certains critères déterminés par un filtre du discriminateur.

Le registre de consignation 31 est abonné à au moins un discriminateur 41 géré par le module d'interconnexion 38. Le filtre du discriminateur 41 retient les événements de type alarme de communication, alarme d'environnement, alarme d'équipement, alarme de qualité de service, alarme de traitement. De façon à faciliter la gestion de la transmission des alarmes au registre de consignation 31, il est avantageux de dédier le discriminateur 41 à une seule classe d'objets MOC dont chaque instance décrit un équipement administré par le sous-système 58. Le filtre du discriminateur 41 est alors complété pour ne retenir que les événements dont l'attribut MOC a pour valeur la classe à laquelle le discriminateur 41 est dédié.

Le registre de consignation 31 est alors abonné à un ou plusieurs

autres discriminateurs 42, dédiés chacun à une classe d'objets MOC particulière.

Dans le sous-système 59, une structure de données de registre de consignation 30 est prévue pour enregistrer les alarmes de la zone administrée au moyen du sous-système 59. Chaque alarme y est repérée avec un identifiant numérique 1", 2", 3", dont la valeur suit l'ordre de présentation des alarmes sur le bus 33. Un module d'interconnexion 39, semblable au module 38, gère des discriminateurs de retransmission d'événement 44,45.

Pour le sous-système 59 comme pour le sous-système 58, le registre de consignation 31 est abonné aux discriminateurs 44,45, dédiés de façon avantageuse chacun à une classe d'objets MOC déterminée.

Le système informatique de la figure 2 fonctionne de la façon suivante.

Lorsque par exemple l'agent 36 met à la disposition sur le bus 33 une première alarme, cette première alarme est enregistrée dans la structure de registre de consignation 30 avec l'attribut d'identification 1". La valeur d'attribut MOC de la première alarme étant telle qu'elle est retenue par le discriminateur 44, le module d'interconnexion 39 envoie la notification d'alarme sur le réseau 28 à destination du sous-système 27 où le module.. d'interconnexion 37 met la notification de la première alarme, à disposition sur le bus 34. Le registre de consignation 31 étant abonné au discriminateur 44, la première alarme est enregistrée dans la structure de données de registre de consignation 31 avec l'attribut d'identification 1. Lorsque l'agent 35 met à disposition sur le bus 32 une deuxième alarme, cette deuxième alarme est enregistrée dans la structure de données de registre de consignation 29 avec l'attribut d'identification 1'. La valeur d'attribut MOC de la deuxième alarme étant telle qu'elle est retenue par le discriminateur 41, le module 38 envoie la notification d'alarme sur le réseau 28 à destination du sous-système 27 où le module d'interconnexion 37 met la notification de la deuxième alarme, à disposition sur le bus 34. Le registre de consignation 31 étant abonné au discriminateur 41, la deuxième alarme est enregistrée dans la structure de données du registre de consignation 31 avec l'attribut d'identification 2. Lorsque l'agent 35 met à disposition sur le bus 32

une troisième alarme, cette troisième alarme est enregistrée dans la structure de données de registre de consignation 29 avec l'attribut d'identification 2'. La valeur d'attribut MOC de la troisième alarme étant telle qu'elle est retenue par le discriminateur 42, le module 38 envoie la notification d'alarme sur le réseau 28 à destination du sous-système 27 où le module d'interconnexion 37 met la notification de la troisième alarme, à disposition sur le bus 34. Le registre de consignation 31 étant abonné au discriminateur 42, la troisième alarme est enregistrée dans la structure de données du registre de consignation 31 avec l'attribut d'identification 3. Lorsque l'agent 36 met à disposition sur le bus 33 une quatrième alarme, cette quatrième alarme est enregistrée dans la structure de données de registre de consignation 30 avec l'attribut d'identification 2". La valeur d'attribut MOC de la quatrième alarme étant telle qu'elle est retenue par le discriminateur 45, le module 39 envoie la notification d'alarme sur le réseau 28 à destination du sous-système 27 où le module d'interconnexion 37 met la notification de la quatrième alarme, à disposition sur le bus 34. Le registre de consignation 31 étant abonné au discriminateur 45, la quatrième alarme est enregistrée dans la structure de données du registre de consignation 31 avec l'attribut d'identification 4. Lorsque l'agent 36 met à disposition sur le bus 33 une cinquième alarme, cette cinquième alarme est enregistrée dans la structure de données de registre de consignation 30 avec l'attribut d'identification 3". La valeur d'attribut MOC de la cinquième alarme étant telle qu'elle est retenue par le discriminateur 45, le module 39 envoie la notification d'alarme sur le réseau 28 à destination du sous-système 27 où le module d'interconnexion 37 met la notification de la cinquième alarme, à disposition sur le bus 34. Le registre de consignation 31 étant abonné au discriminateur 45, la cinquième alarme est enregistrée dans la structure de données du registre de consignation 31 avec l'attribut d'identification 5. Lorsque l'agent 35 met à disposition sur le bus 32 une sixième alarme, cette sixième alarme est enregistrée dans la structure de données de registre de consignation 29 avec l'attribut d'identification 3'. La valeur d'attribut MOC de la sixième alarme étant telle qu'elle est retenue par le

discriminateur 42, le module 38 envoie la notification d'alarme sur le réseau 28 à destination du sous-système 27 où le module d'interconnexion 37 met la notification de la sixième alarme, à disposition sur le bus 34. Le registre de consignation 31 étant abonné au discriminateur 42, la sixième alarme est enregistrée dans la structure de données du registre de consignation 31 avec l'attribut d'identification 6.

Il convient de remarquer qu'il n'existe aucune corrélation entre les valeurs d'attributs d'identification dans les structures de données des registres de consignation 29,30, 31.

Chacun des sous-systèmes 58,59, 27 comprend respectivement un module de commande et d'interface homme machine (C-IHM) 47,48, 49 sur le modèle du module 22, pour permettre à plusieurs opérateurs, localisés chacun à proximité de l'un des sous-système 58,59, 27, de modifier des valeurs d'attributs d'alarmes dans le registre de consignation dont il dispose.

De façon à maintenir en cohérence les valeurs d'attributs dans les registres de consignation où sont enregistrées les mêmes alarmes, le système informatique de la figure 2 est agencé de la façon suivante.

Chacun des modules 47,48, 49 est configuré de façon à émettre sur le bus respectif 32,33, 34 auquel il est relié, une notification de changement de valeur d'attribut ("Attribut Value Change"-AVC ; voir Recommandation X. 721,"Technologie de l'information-Interconnexion de systèmes ouvertsstructure des information de gestion : Définition des informations de gestion", p.

36, CCITT, 1992) à chaque fois qu'il modifie une valeur d'attribut dans les registres de consignation 29,30, 31 qu'il contrôle. Dans le sous-système informatique général 27, un gestionnaire 40 de registres de consignation (GRC), est abonné à un discriminateur de retransmission d'événements 43,46 géré par le module 38,39 de chaque sous-système informatique local 58,59.

Chaque discriminateur de retransmission 43,46 comprend un filtre pour retenir les événements de type AVC et de classe d'objet géré MOC égale à un enregistrement d'alarme.

Ainsi, lorsqu'une valeur d'attribut est modifiée dans un enregistrement

d'alarme du registre de consignation 29, 30 par le module de contrôle 47, 48, le module 38, 39 envoie la notification de changement de valeur d'attribut AVC sur le réseau 28 à destination du sous-système 27 où le module d'interconnexion 37 met la notification AVC à disposition sur le bus 34. Le gestionnaire 40 étant abonné au discriminateur 43,46, reçoit alors la notification AVC.

Le gestionnaire 40 met en oeuvre un procédé pour maintenir cohérentes les valeurs d'attributs d'alarmes dans les registres de consignation 29,30, 31. Ce procédé active un processus pour chaque modification d'attribut d'alarme, tel qu'expliqué maintenant en référence à la figure 3.

Dans une étape initiale 50, le processus est à l'écoute des notifications de changement de valeurs d'attributs AVC mises à disposition sur le bus 34.

Une détection de notification de changement de valeur d'attribut AVC sur le bus 34 constitue une transition 51 qui fait passer le processus de l'étape 50 à une étape 52. Conformément à la recommandation X. 721, la notification de changement de valeur d'attribut AVC comprend un identifiant de l'instance d'objet géré MOI pour laquelle la notification s'est produite. En particulier, cet identifiant permet de reconnaître un premier registre de consignation comprenant l'enregistrement de l'alarme modifiée et l'attribut d'identification de l'alarme dans ce premier registre de consignation.

En étape 52, l'identifiant d'instance d'objet géré MOI de la notification AVC permet au gestionnaire 40 d'accéder en lecture à l'enregistrement notifié au moyen d'une procédure d'obtention, par exemple par le biais du service correspondant"GET"tel que spécifié dans la recommandation X. 710. Le gestionnaire 40 appelle la procédure d'obtention pour prélever un discriminant d'alarme dans l'enregistrement notifié. Le discriminant d'alarme comprend les valeurs d'attributs suivantes : le type d'événement ("event type"), l'instance d'objet géré ("Managed Object Instance"-MOI) qui décrit l'entité à l'origine de l'alarme, la cause probable et le problème spécifique. Bien entendu, le choix de ces valeurs n'est pas limitatif et peut notamment évoluer en fonction d'autres critères d'identité entre deux alarmes, par exemple pour se conformer

à l'usage ayant cours dans le domaine de l'invention.

Lorsque l'identifiant d'instance d'objet géré MOI, communiqué par la, notification AVC, indique que le premier registre de consignation est le registre 29 ou 30, géré respectivement par le sous-système local 58 ou 59, le gestionnaire 40 dans le sous-système général 27 commande l'étape de lecture 52 respectivement dans le sous-système local 58 ou 59. Pour ce faire, le service "GET" est sollicité à destination du registre de consignation 29 ou respectivement 30, via le bus 34, le module d'interconnexion 37, le réseau 28, le module 38 ou respectivement 39 et le bus 32 ou respectivement 33.

Les valeurs d'attribut requises sont retournées du registre de consignation 29 ou respectivement 30 au gestionnaire 40 par le chemin inverse.

Lorsque l'identifiant d'instance d'objet géré MOI, communiqué par la notification AVC, indique que le premier registre de consignation est le registre 31 géré par le sous-système général 27, le sous-système général exécute directement l'étape de lecture 52. Le service "GET" est sollicité à destination du registre de consignation 31 via le bus 34. Les valeurs d'attribut requises sont retournées du registre de consignation 31 au gestionnaire 40 par le bus 34.

L'obtention du discriminant d'alarme constitue une transition 53 qui fait passer le processus de l'étape 52 à une étape 54.

Dans l'étape 54, le gestionnaire 40 recherche dans un deuxième registre de consignation, un enregistrement correspondant à l'enregistrement du premier registre de consignation.

Dans le cas où le registre de consignation sur lequel porte la notification AVC est le registre 31, des mécanismes de routage connus en soi permettent d'identifier le sous-système informatique 25,26 qui gère une instance d'objet géré MOI donnée, et par conséquent le registre de consignation 29,30 correspondant où sont enregistrées les alarmes de cette instance d'objet.

Dans le cas où le registre de consignation sur lequel porte la

notification AVC est le registre 29, 30, le registre de consignation correspondant à mettre à jour est le registre 31.

Le premier registre de consignation étant celui sur lequel porte la notification AVC et le deuxième registre de consignation étant celui à mettre à jour, l'étape 54 du processus parcourt les enregistrements du deuxième registre de consignation au moyen d'une procédure d'obtention, par exemple par le biais du service correspondant"GET"tel que spécifié dans la recommandation X. 710. La procédure d'obtention permet aussi l'extraction d'enregistrements du registre selon une information de filtre facultative, qui pourra être avantageusement utilisée pour la mise en oeuvre de la présente invention. Dans ce cas, le service"GET"lit chaque enregistrement du deuxième registre de consignation et retourne le contenu de l'enregistrement dont les valeurs correspondent à celles de l'information de filtre déterminée en fonction des valeurs d'attributs définies par le discriminant d'alarme élaboré à l'étape 52. L'enregistrement retourné correspond donc à un enregistrement de la même alarme que celle sur laquelle porte la notification AVC. Cet enregistrement contient la valeur de l'attribut de nommage qui identifie l'enregistrement correspondant dans le deuxième registre de consignation.

Lorsque l'identifiant d'instance d'objet géré MOI communiqué par la notification AVC, indique que le premier registre de consignation est le registre 29 ou 30, géré respectivement par le sous-système local 58 ou 59, le deuxième registre de consignation est le registre 31 géré par le sous-système général 27. Le gestionnaire 40 dans le sous-système informatique général 27, exécute l'étape 54 au moyen d'une procédure d'obtention, par exemple en sollicitant le service"GET"par le biais du bus 34 à destination du registre de consignation 31. L'enregistrement correspondant est retourné du registre de consignation 31 au gestionnaire 40 par le bus 34.

Lorsque l'identifiant d'instance d'objet géré MOI communiqué par la notification AVC indique que le premier registre de consignation est le registre 31 géré par le sous-système informatique général 27, le deuxième registre de consignation est le registre 29 ou 30, géré respectivement par le sous-système

local 58 ou 59. Le gestionnaire 40 dans le sous-système informatique général 27, commande l'étape 54 en déclenchant une procédure d'obtention par appel du service"GET"sur le bus 34 à destination du registre de consignation 29, respectivement 30 via le module d'interconnexion 37, le réseau 28, le module 38 et le bus 32, respectivement le module 39 et le bus 33. L'enregistrement correspondant est retourné des registres de consignation 29,30 au gestionnaire 40 par le chemin inverse.

L'obtention d'identification de l'enregistrement correspondant, constitue une transition 55 qui fait passer le processus de l'étape 54 à une étape 56.

Dans l'étape 56, le gestionnaire 40 met à jour l'enregistrement correspondant dans le deuxième registre de consignation.

Outre la classe d'objet gérée MOC avec la valeur enregistrement d'alarme ("alarm record") et l'instance d'objet modifié MOI avec pour valeurs l'identifiant du premier registre de consignation et l'identifiant du rang d'enregistrement dans le premier registre de consignation, informations utilisées dans l'étape 52, la notification AVC véhicule les informations suivantes : attribut modifié, nouvelle valeur de l'attribut modifié, ancienne valeur de l'attribut modifié. Par exemple, si l'attribut modifié est l'attribut d'état, la nouvelle valeur peut être acquitté et l'ancienne valeur signalé .

Dans l'étape 56, l'enregistrement correspondant est mis à jour au moyen d'une procédure d'affectation, par exemple par le biais du service correspondant"SET"tel que spécifié dans la recommandation X. 710 qui porte sur l'attribut modifié et qui positionne l'attribut modifié sur la nouvelle valeur notifiée.

Si le deuxième registre de consignation est le registre de consignation 31 géré par le sous-système informatique général 27, le gestionnaire 40 déclenche la procédure d'affectation, par le biais d'un appel au service"SET", sur le bus 34 à destination directe du registre de consignation 31.

Si le deuxième registre de consignation est le registre de consignation 29 ou 30 géré par le sous-système informatique local 58 ou 59, le gestionnaire

40 dans le sous-système général 27, commande la mise à jour en déclenchant la procédure d'affectation, par le biais d'un appel au service"SET", sur le bus 34, à destination du registre de consignation 29 ou 30 via le module d'interconnexion 37, le bus 28, le module 38 ou 39 et le bus 32 ou 33.

De façon à assurer la cohérence des enregistrements d'alarmes dans les différents registres de consignation en cas de rupture de communication entre les sous-systèmes informatiques locaux et général, chacun des discriminateurs de retransmission (41-43,44-46) précédemment décrit est équipé d'une mémoire tampon dans laquel les notifications d'événements sont mémorisées jusqu'à être effectivement reçues chacune par le sous-système informatique destinataire. Pour éviter de perdre une notification d'événement, il n'est pas mis en oeuvre de gestion circulaire du tampon, c'est à dire que le tampon est de dimension virtuellement infinie. Une notification d'événement est éliminée du tampon uniquement lorsqu'elle est effectivement reçue du sous-système informatique destinataire.

Claims

REVENDICATIONS 1. Procédé de maintien en cohérence de valeurs d'attributs d'alarmes enregistrées dans un premier et dans un deuxième registre de consignation d'un système informatique, caractérisé en ce que : - à détection d'une notification de changement de valeur d'attribut pour un enregistrement d'alarme dans le premier registre, une étape de lecture (52) prélève un discriminant d'alarme dans l'enregistrement notifié, - au moyen du discriminant d'alarme, une étape de recherche (54) parcourt les enregistrements du deuxième registre jusqu'à y identifier un enregistrement correspondant, - à réception d'une identification d'enregistrement correspondant, une étape de mise à jour (56) remplace dans l'enregistrement correspondant, une valeur de l'attribut dont le changement est notifié, par une valeur du même attribut dans l'enregistrement notifié.
2. Procédé de maintien en cohérence de valeurs d'attributs d'alarmes selon la revendication 1, caractérisé en ce que le premier registre de consignation est géré par un sous-système informatique (58,59) d'une première zone, le deuxième registre de consignation est géré par un soussystème informatique (27) d'une deuxième zone qui inclut ladite première zone, la notification de changement de valeur d'attribut est envoyée du soussystème informatique de première zone vers le sous-système informatique de deuxième zone qui commande l'étape de lecture (52) dans le sous-système informatique de première zone, et le sous-système informatique de deuxième zone exécute l'étape de recherche (54) et l'étape de mise à jour (56).
3. Procédé de maintien en cohérence de valeurs d'attributs d'alarmes selon la revendication 1, caractérisé en ce que le deuxième registre de consignation est géré par un sous-système informatique (58,59) d'une

<Desc/Clms Page number 18>

première zone, le premier registre de consignation est géré par un soussystème informatique (27) d'une deuxième zone qui inclut ladite première zone, la notification de changement de valeur d'attribut est générée dans le sous-système informatique de deuxième zone qui exécute l'étape de lecture (52), et le sous-système informatique de deuxième zone commande l'étape de recherche (54) et l'étape de mise à jour (56) dans le sous-système informatique de première zone.
4. Procédé de maintien en cohérence de valeurs d'attributs d'alarmes selon l'une des revendications précédentes, caractérisé en ce que le discriminant d'alarme est un n-uplet de valeurs d'attributs d'alarme, comprenant un attribut de type d'événement et un attribut d'instance d'objet géré.
5. Procédé de maintien en cohérence de valeurs d'attributs d'alarmes selon la revendication 4, caractérisé en ce que le discriminant d'alarme comprend de plus un attribut de cause probable.
6. Procédé de maintien en cohérence de valeurs d'attributs d'alarmes selon la revendication 4 ou 5, caractérisé en ce que le discriminant d'alarme comprend de plus un attribut de problème spécifique.
7. Procédé de maintien en cohérence de valeurs d'attributs d'alarmes selon la revendication 2, caractérisé en ce que toute notification de changement de valeur d'attribut est conservée dans le sous-système informatique (58,59) de première zone jusqu'à ce que le sous-système informatique de deuxième zone ait reçu ladite notification.
8. Système informatique comprenant au moins un sous-système informatique (58,59) d'une première zone qui enregistre des valeurs d'attributs d'alarme dans un registre de consignation (29,30) de première zone, et un sous-système informatique (27) d'une deuxième zone qui enregistre les dites valeurs d'attributs d'alarme dans un registre de consignation (31) de deuxième

<Desc/Clms Page number 19>

zone qui inclut la première zone, chaque sous-système informatique comprenant une infrastructure de communication pour faire circuler des notifications de changement d'attribut, caractérisé en ce que le sous-système informatique (58,59) de première zone comprend un discriminateur de retransmission d'événements (43,46) pour envoyer les notifications de changement d'attribut qui circulent sur son infrastructure de communication (32,33), vers l'infrastructure de communication (34) du sous-système informatique (27) de deuxième zone, le sous-système informatique de deuxième zone comprend un gestionnaire de registre de consignation (40) pour prélever un discriminant d'alarme dans un enregistrement signalé par une notification de changement d'attribut circulant sur son infrastructure de communication (34), pour identifier un enregistrement correspondant dans celui des registres de consignation qui ne comprend pas l'enregistrement signalé, et pour remplacer ledit enregistrement correspondant par ledit enregistrement signalé.
9. Système informatique selon la revendication 8, caractérisé en ce que le discriminateur de retransmission d'événements (43,46) du soussystème informatique (58,59) de première zone comprend une mémoire dans laquelle sont mémorisées les notifications de changement d'attribut avant d'être envoyées au sous-système informatique (27) de deuxième zone.