WO2002046940A2 - Procede et systeme pour la gestion d'alarmes - Google Patents

Procede et systeme pour la gestion d'alarmes Download PDF

Info

Publication number
WO2002046940A2
WO2002046940A2 PCT/FR2001/003688 FR0103688W WO0246940A2 WO 2002046940 A2 WO2002046940 A2 WO 2002046940A2 FR 0103688 W FR0103688 W FR 0103688W WO 0246940 A2 WO0246940 A2 WO 0246940A2
Authority
WO
WIPO (PCT)
Prior art keywords
alarm
attribute
zone
register
computer subsystem
Prior art date
Application number
PCT/FR2001/003688
Other languages
English (en)
Other versions
WO2002046940A3 (fr
Inventor
Olivier Louer
Original Assignee
Eads Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Eads Telecom filed Critical Eads Telecom
Priority to AU2002222021A priority Critical patent/AU2002222021A1/en
Priority to AU2002222021A priority patent/AU2002222021A8/xx
Publication of WO2002046940A2 publication Critical patent/WO2002046940A2/fr
Publication of WO2002046940A3 publication Critical patent/WO2002046940A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks

Definitions

  • the field of the invention is that of alarm management in distributed computer systems and in networks which interconnect several computer and or telecommunications equipment.
  • the SNMP industrial standard ("A Simple Network Management Protocol - SNMP ", RFC 1157, IETF, May 1990) constitutes a simplified standard often used in the environment of packet transmission networks according to the IP protocol (" Internet Protocol ", RFC 791, IETF, September 1981)
  • An agent generates an alarm with, as the most commonly used attributes, the type of alarm, the class and the instance of the object emitting the alarm, the probable cause of the alarm, the severity, the problem. specific, supervised attribute values and free text.
  • the event type indicates whether the event from which the alarm results, concerns equipment, communications, processing, quality of service or the environment of an equipment.
  • Each entity in the network represents a managed object instance ("Managed Object Instance” - MOI) within a managed object class (“Managed Object Class” - MOC).
  • the severity given to the alarm is of undetermined, critical, major, minor, warning or cleared level.
  • the specific problem (“Specifies problem”), another parameter defined in the X. 733 standard, is a refinement of the probable cause ("Probable cause") supplied by the manufacturer.
  • the monitored attributes (“Monitored attributes”) take values raised in the alarm which relate to the transmitting object, such as a temperature, an electrical intensity or a quantity of data.
  • the alarm is recorded in a logbook, of which the X. 735 standard provides a definition, with additional attributes which allow the management of alarms.
  • the identifier is a name attribute for the record, represented for example by a natural whole number incremented with each presentation of a new alarm.
  • the counter indicates the number of alarms identical to that of the recording in the logbook. It is usual to consider that two alarms are identical if the attributes of event type, instance of managed object, probable cause and specific problem have the same values.
  • the status of an alarm also indicates whether an operator has taken into account the alarm (acknowledged, ignored) or not (reported). If the operator has taken the alarm into account, the status "Acknowledged" indicates that he wishes to see the new occurrences of the alarm displayed on the counter.
  • the "ignored" state indicates that the operator wishes to ignore the next occurrences of the alarm.
  • the trouble ticket identifier possibly associated with the alarm by the operator, makes it possible to establish a coupling link with incident management software.
  • An incident ticket is a data structure comprising different fields filled in by the operator, so that they can be used by maintenance personnel. Maintenance personnel can then complete other fields on the incident ticket with solutions used to repair the incident. Keeping incident tickets in a database then facilitates repairs of incidents produced later under comparable conditions.
  • the cause for the alarm termination indicates whether the disappearance of the alarm results from an erasure from the network, from manual termination or from the closure of an associated incident ticket.
  • Alarm management software accesses the data structure of the logbook by means of a pointer to display the alarms with their attributes on a screen and to allow the operator to modify certain values of authorized attributes. This is for example the case of the status attribute (signaled, acknowledged, ignored), the incident ticket identifier and the cause of the alarm termination.
  • the invention relates more particularly to alarm management organized in a delocalized manner.
  • a consignment register and its management software are allocated to each zone and generally reside in an equipment of the zone to which they are allocated.
  • An operator monitors the zone alarms for which he is responsible by means of man-machine interfaces on which the zone management software displays the alarms with their attributes and modifies the attributes under operator command, using a pointer to the records in the consignment register.
  • a solution consisting in implementing a single logging register to record the alarms of all the zones of the network is not satisfactory.
  • This solution requires a complex filtering mechanism to display and only allow an operator in charge of monitoring a single zone, to intervene only on the alarms in his zone. If an alarm management software for each zone accesses the logbook, it is necessary to maintain data consistency on the shared logbook.
  • a single consignment register can be problematic in the event of communication breakdown with the equipment that hosts it.
  • a local log register assigned to each zone of the network.
  • a general log register groups the alarms from the log registers that it supervises. More generally, in the case of shared alarm management of a first zone with another zone, the log register of the other zone groups the alarms of the first zone with its own.
  • the recording of an alarm in several recording registers is carried out in a manner known per se.
  • an agent When an agent generates an alarm, it is recorded in the consignment register assigned to the zone from which it originates with a first identifier.
  • the alarm is recorded in the log register which groups together the alarms of said zone and those of another zone, with a second identifier generally different from the first identifier because the identifiers of the two registers of do not count the same sets of alarms.
  • the management software assigned to said zone points to the first identifier in the recording register of said zone, the management software assigned to several zones points to the second identifier in the other recording register.
  • an operator may have to modify an attribute value using the management software at his disposal, which points only to the alarm identifier in the logbook to which he is linked.
  • the difficulty is to pass on the change of attribute in the other consignment register.
  • the invention firstly relates to a method for maintaining coherence of alarm attribute values recorded in a first and in a second recording register of a computer system.
  • the method is remarkable in that: upon detection of a notification of change of attribute value for an alarm recording in the first register, a reading step takes an alarm discriminant from the notified recording,
  • a search step traverses the records of the second register until identifying a corresponding record
  • an update step replaces in the corresponding record, a value of the attribute whose change is notified, by a value of the same attribute in the notified record.
  • the first consignment register is managed by a computer subsystem of a first zone
  • the second consignment register is managed by a computer subsystem of a second zone which includes said first zone
  • the notification of change of attribute value is sent from the first zone computer subsystem to the second zone computer subsystem which controls the reading step in the first zone computer subsystem
  • the second zone computer subsystem executes the research stage and the update stage.
  • the second consignment register is managed by a computer subsystem of a first zone
  • the first consignment register is managed by a computer subsystem of a second zone which includes said first zone
  • the notification of change of attribute value is generated in the second area computer subsystem that performs the read step and the second area computer subsystem controls the search step and the update step in the subsystem first zone computer system.
  • the alarm discriminant is a n-tuple of alarm attribute values, comprising an event type attribute and a managed object instance attribute.
  • the alarm discriminant further includes a probable cause attribute.
  • the alarm discriminant further comprises a specific problem attribute.
  • a second object of the invention is a computer system comprising at least one computer subsystem of a first zone which records values of alarm attributes in a log register of the first zone, and a computer subsystem of a second zone which records said values of alarm attributes in a second zone logging register which includes the first zone, each computer subsystem comprising a communication infrastructure for circulating attribute change notifications.
  • the computer system is remarkable in that the first zone computer subsystem includes an event retransmission discriminator to send the attribute change notifications which circulate on its communication infrastructure, to the communication infrastructure of the sub- second zone computer system, the second zone computer subsystem comprises a log register manager for picking up an alarm discriminant in a recording signaled by an attribute change notification circulating on its communication infrastructure, for identifying a corresponding record in that of the consignment registers which does not include the reported record, and to replace said corresponding record by said reported record.
  • the event retransmission discriminator of the first zone computer subsystem comprises a memory in which are stored the notifications of change of attribute before being sent to the second zone computer subsystem.
  • Figure 1 shows a network administration platform
  • FIG. 1 shows several administrative platforms in a case of distribution by area; • Figure 3 shows different stages of a process according to the invention.
  • different sites include equipment 17 to 19, 14 to 16, 11 to 13, connected in a network.
  • An administration platform 7 comprises a communication infrastructure, for example a bus 8 which is accessed by agents 9, 10 who manage a Management Information Base (MIB) 25, 26 of 11-19 network for which they are responsible.
  • the devices 11 to 13 generate, for example, event notifications such as alarms in SNMP format.
  • Agent 9 then converts these notifications to X.733 format to make them available on bus 8.
  • Equipment 14, 15, 16 and 17, 18, 19 are, for example, telecommunications equipment which generates event notifications such as alarms in their own format.
  • the agent 10 then converts these notifications to X.733 format to make them available on the bus 8.
  • the generation of event notifications can be done on the initiative of the devices 11-19 or in response to a periodic request d interrogation of change of state from an agent 9-10.
  • An alarm manager 21 receives the X.733 alarms sent on the bus 8, for example by means of an internal subscription mechanism, and the stores, via the bus 8, in the database 20 which contains a data structure of recording registers for recording the alarms and their attributes.
  • the agent 9, 10 and its associated MIB 25, 26 could, in a manner known per se, be embedded in one of the devices which it supervises 11-19, in which case the event notifications transmitted to the administration platform 7 would be directly in X.733 format.
  • a man-machine interface and control module (C-HMI) 22 regularly reads the content of the base 20 to present it on a display member 23 to an operator. The latter can then, via an input device 24, modify the values of at least some of the attributes of the alarm records, modifications which are reflected in the base 20 by the module 22.
  • the module HMI command and interface 22 displays each new alarm presented on bus 8 with the value initial of "unspecified” status attribute. If the operator performs an action to ignore the alarm by means of the input device 24, the status attribute changes from the “signaled” value to the “ignored” value. If the operator performs an action to acknowledge the alarm by means of the input device 24, the module 22 changes the status attribute from the value "signaled” to the value "acknowledged".
  • the module 22 If the operator performs by means of the member 24, a restoration action, the module 22 returns the status attribute to the value "signaled". In the event that a new occurrence of the alarm occurs, the module 22 systematically resets the status attribute to the value "signaled” if the value is "acknowledged".
  • the operator can also modify, by means of the input device 24, the values of the attribute identifying an incident ticket and of the attribute indicating the cause of termination of an alarm.
  • FIG. 2 shows a computer system comprising computer subsystems 58, 59, 27 connected by a communication network 28.
  • the computer subsystems 58, 59, 27 are of the type of the administration platform 7 previously described . In order not to unnecessarily overload the figure, only the essential elements for understanding the invention are shown here.
  • Each of the subsystems 58, 59, 27 respectively comprises a communication infrastructure 32, 33, 34, for example of the type of bus 8.
  • the computer subsystems 58, 59 constitute local computer subsystems for each administering a first area of sites on the model of the administration platform 7, and each each comprises one or more agents 35, 36 for fulfilling the duties of officers 9, 10.
  • the computer subsystem 27 constitutes a general computer subsystem for hierarchically administering several first zones, each administered by a local computer subsystem. One of these first zones can also be administered directly by the computer subsystem 27, in which case the subsystem 27 comprises an agent 57 to fulfill the functions of agents 9, 10.
  • the set of areas administered by the computer subsystem 27 constitutes a second area which includes at least one said first area.
  • the subsystem 27 includes a distributed infrastructure interconnection module (IID) 37 to make available on the bus 34 event notifications from the local computer subsystems 58, 59.
  • IID distributed infrastructure interconnection module
  • a log register data structure 31 is provided for recording alarms from all of the administered zones.
  • Each alarm is there for example identified by a digital identifier 1, 2, 3, 4, 5, 6 whose value follows the order of presentation of the alarms on bus 34.
  • a log register data structure 29 is provided for recording the alarms of the administered zone, each identified for example by identifying the, 2 ′, 3 ′ whose value follows the order of presentation of the alarms on the bus 32.
  • An interconnection module of the distributed infrastructures 38 whose functions correspond to that of the module 37 described above, also manages event forwarding discriminator (EFD, CCITT) Recommendation X.734, ITU, Sept. 92). The remainder of this presentation refers to the description of event retransmission discriminators in CCITT Recommendation X.734 (ITU).
  • Such a discriminator makes it possible to send to a service subscribed to this discriminator, notification of any event which meets certain criteria determined by a filter of the discriminator.
  • the recording register 31 is subscribed to at least one discriminator 41 managed by the interconnection module 38.
  • the discriminator filter 41 retains events of the communication alarm, environmental alarm, equipment alarm, quality alarm type. service, processing alarm.
  • the discriminator 41 filter is then completed in order to retain only the events whose attribute MOC has for value the class to which the discriminator 41 is dedicated.
  • the recording register 31 is then subscribed to one or more other discriminators 42, each dedicated to a particular class of MOC objects.
  • a logbook data structure 30 is provided for recording the alarms of the zone administered by means of the subsystem 59.
  • Each alarm is identified therein with a digital identifier 1 ", 2", 3 ", whose value follows the order of presentation of the alarms on the bus 33.
  • An interconnection module 39 similar to the module 38, manages event retransmission discriminators 44, 45.
  • the recording register 31 is subscribed to the discriminators 44, 45, each advantageously dedicated to a given class of MOC objects.
  • the computer system of Figure 2 operates as follows.
  • the agent 36 makes a first alarm available on the bus 33
  • this first alarm is recorded in the log register structure 30 with the identification attribute 1 ".
  • the attribute value MOC of the first alarm being as it is retained by the discriminator 44
  • the interconnection module 39 sends the alarm notification on the network 28 to the subsystem 27 where the interconnection module 37 puts the notification of the first alarm, available on the bus 34.
  • the log register 31 being subscribed to the discriminator 44, the first alarm is recorded in the log register data structure 31 with the identification attribute 1.
  • the attribute value MOC of the third alarm being such that it is retained by the discriminator 42, the module 38 sends the alarm notification on the network 28 to the subsystem 27 where the interconnection module 37 puts the notification of the third alarm, available on the bus 34.
  • the log register 31 being subscribed to the discriminator 42, the third alarm is recorded in the data structure of the log register 31 with the identification attribute 3.
  • agent 36 makes a fourth alarm available on bus 33, this fourth alarm is recorded in the log register data structure 30 with the identification attribute 2 ".
  • the attribute value MOC of the fourth alarm being as it is retained by the discriminator 45, the module 39 sends the alarm notification on the network 28 to the subsystem 27 where the interconnection module 37 puts the notification of the qu third alarm, available on the bus 34.
  • the log register 31 being subscribed to the discriminator 45 the fourth alarm is recorded in the data structure of the log register 31 with the identification attribute 4.
  • this fifth alarm is recorded in the log register data structure 30 with the identification attribute 3 ".
  • the attribute value MOC of the fifth alarm being such that it is retained by the discriminator 45, the module 39 sends the alarm notification on the network 28 to the subsystem 27 where the interconnection module 37 puts notification of the fifth alarm, available on the bus 34.
  • the log register 31 being subscribed to the discriminator 45 the fifth alarm is recorded in the data structure of the log register 31 with the attribute identification 5.
  • the agent 35 makes a sixth alarm available on the bus 32, this sixth alarm is recorded in the recording register data structure 29 with the identification attribute 3 ′.
  • the attribute value MOC of the sixth alarm being such that it is retained by the discriminator 42, the module 38 sends the alarm notification on the network 28 to the subsystem 27 where the interconnection module 37 puts the notification of the sixth alarm, available on the bus 34.
  • the log register 31 being subscribed to the discriminator 42, the sixth alarm is recorded in the data structure of the log register 31 with the identification attribute 6.
  • Each of the subsystems 58, 59, 27 respectively comprises a control and man-machine interface module (C-HMI) 47, 48, 49 on the model of the module 22, to allow several operators, each located near one of the subsystems 58, 59, 27, to modify alarm attribute values in the logbook which it has.
  • C-HMI control and man-machine interface module
  • the computer system of FIG. 2 is arranged as follows.
  • Each of the modules 47, 48, 49 is configured so as to transmit on the respective bus 32, 33, 34 to which it is connected, a notification of change of attribute value ("Attribute Value Change" - AVC; see Recommendation X. 721, "Information Technology - Open Systems Interconnection - Structure of, Management Information: Definition of Management Information", p. 36, CCITT, 1992) each time it changes an attribute value in the consignment registers 29, 30, 31 which he controls.
  • a logger manager 40 GRC
  • Each retransmission discriminator 43, 46 includes a filter for retaining events of the AVC type and of the managed object class MOC equal to an alarm record.
  • the module 38, 39 sends the notification of change of attribute value AVC to the network 28 intended for the subsystem 27 where the interconnection module 37 makes the AVC notification available on the bus 34.
  • the manager 40 being subscribed to the discriminator 43, 46, then receives the AVC notification.
  • the manager 40 implements a method for keeping the values of alarm attributes consistent in the recording registers 29, 30, 31. This method activates a process for each modification of alarm attribute, as explained now. with reference to FIG. 3.
  • the process listens to the notifications of change of values of AVC attributes made available on the bus 34.
  • a detection of notification of change of value of AVC attributes on the bus 34 constitutes a transition 51 which passes the process from step 50 to a step 52.
  • the notification of change of attribute value AVC includes an identifier of the instance of MOI managed object for which the notification occurred. In particular, this identifier makes it possible to recognize a first recording register comprising the recording of the modified alarm and the identification attribute of the alarm in this first recording register.
  • the MOI managed object instance identifier of the notification includes an identifier of the instance of MOI managed object for which the notification occurred. In particular, this identifier makes it possible to recognize a first recording register comprising the recording of the modified alarm and the identification attribute of the alarm in this first recording register.
  • AVC allows the manager 40 to read the notified record by means of a obtaining procedure, for example by means of the corresponding service "GET" as specified in the recommendation X.710.
  • the manager 40 calls the obtaining procedure to collect an alarm discriminant from the notified record.
  • the alarm discriminant includes the following attribute values: the event type (instance), the instance Managed Object Instance (MOI) which describes the entity causing the alarm, the probable cause and the specific problem.
  • the choice of these values is not limiting and can in particular evolve as a function of other identity criteria between two alarms, for example to comply with the practice prevailing in the field of the invention.
  • the manager 40 in the general subsystem 27 controls the reading step 52 respectively in the local subsystem 58 or 59.
  • the "GET" service is requested to the consignment register 29 or respectively 30, via the bus 34, the interconnection module 37, the network 28, the module 38 or respectively 39 and the bus 32 or respectively 33.
  • the required attribute values are returned from the log register 29 or respectively 30 to the manager 40 by the reverse path.
  • the MOI managed object instance identifier When the MOI managed object instance identifier, communicated by the AVC notification, indicates that the first logging register is the register 31 managed by the general subsystem 27, the general subsystem directly performs the step of reading 52.
  • the "GET" service is requested from the consignment register 31 via the bus 34.
  • the required attribute values are returned from the consignment register 31 to the manager 40 by the bus 34.
  • Obtaining the alarm discriminant constitutes a transition 53 which takes the process from step 52 to a step 54.
  • step 54 the manager 40 searches a second recording register for a record corresponding to the recording of the first recording register.
  • routing mechanisms known per se make it possible to identify the computer subsystem 25, 26 which manages a given MOI managed object instance, and consequently the corresponding logging register 29, 30 where the alarms of this object instance are recorded.
  • the corresponding consignment register to be updated is the register 31.
  • step 54 of the process traverses the records of the second consignment register by means of a obtaining procedure, for example through the corresponding "GET" service as specified in Recommendation X.710.
  • the obtaining procedure also allows the extraction of records from the register according to optional filter information, which can be advantageously used for the implementation of the present invention.
  • the "GET" service reads each record from the second logging register and returns the content of the record whose values correspond to those of the filter information determined as a function of the attribute values defined by the discriminant d alarm developed in step 52.
  • the returned recording therefore corresponds to a recording of the same alarm as that on which the AVC notification relates.
  • This record contains the value of the naming attribute which identifies the corresponding record in the second log.
  • the second log register is the register 31 managed by the general subsystem 27.
  • the manager 40 in the general computer subsystem 27 executes step 54 by means of a obtaining procedure, for example by requesting the "GET" service by the through bus 34 to the recording register 31.
  • the corresponding record is returned from the recording register 31 to the manager 40 by the bus 34.
  • the MOI managed object instance identifier communicated by the AVC notification indicates that the first recording register is the register 31 managed by the general computer subsystem 27, the second recording register is the register 29 or 30, managed respectively by the local subsystem 58 or 59.
  • the manager 40 in the general computer subsystem 27 controls step 54 by triggering a procedure for obtaining by calling the "GET" service on the bus 34 bound for the log register 29, respectively 30 via the interconnection module 37, the network 28, the module 38 and the bus 32, respectively the module 39 and the bus 33.
  • the corresponding record is returned from the log registers 29, 30 to the manager 40 by the reverse path.
  • Obtaining identification of the corresponding record constitutes a transition 55 which passes the process from step 54 to a step 56.
  • the manager 40 updates the corresponding record in the second consignment register.
  • the AVC notification conveys the following information: modified attribute, new value of the modified attribute, old value of the modified attribute.
  • the modified attribute is the status attribute
  • the new value can be "acknowledged” and the old value "reported”.
  • the corresponding record is updated by means of an assignment procedure, for example by means of the corresponding service "SET" as specified in the recommendation X.710 which relates to the attribute modified and which positions the modified attribute on the new notified value. If the second consignment register is the consignment register
  • the manager 40 triggers the assignment procedure, by means of a call to the "SET" service, on bus 34 direct to the consignment register 31.
  • the manager 40 in the general subsystem 27 commands the update by triggering the assignment procedure, by means of a call to the "SET" service, on bus 34, to the consignment register 29 or 30 via interconnection module 37, bus 28, module 38 or 39 and bus 32 or 33 .
  • each of the retransmission discriminators (41-43, 44-46) previously described is equipped with a buffer memory in which the event notifications are stored until each of them is actually received by the recipient computer subsystem.
  • a buffer memory in which the event notifications are stored until each of them is actually received by the recipient computer subsystem.
  • circular buffer management is not implemented, that is to say that the buffer is of virtually infinite dimension. An event notification is cleared from the buffer only when it is actually received from the recipient computer subsystem.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)
  • Computer And Data Communications (AREA)
  • Alarm Systems (AREA)

Abstract

Le procédé permet un maintien en cohérence de valeurs d'attributs d'alarmes enregistrés 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 Télécommunication Union), parmi lesquelles on trouve les recommandations CMIS/CMIP ("Common Management Information Services" : Recommandation UIT-T X.710 (1997) | ISO/CEI 9595:1998, "Technologies de l'information - Interconnexion des systèmes ouverts - Service commun de transfert d'informations de gestion"; "Common Management Information Protocol" : Recommandation UIT-T X.711 (1997) | ISO/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'information - Interconnexion 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 ouverts - Gestion 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 ("Spécifie 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émente à 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 œuvre 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 premier objet un 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. Le procédé est remarquable 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 prélève un discriminant d'alarme dans l'enregistrement notifié,
- au moyen du discriminant d'alarme, une étape de recherche 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 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é. 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.
Particulièrement, le premier registre de consignation est géré par un sous-système informatique d'une première zone, le deuxième registre de consignation est géré par un sous-système informatique d'une deuxième zone qui inclut ladite première zone, la notification de changement de valeur d'attribut est envoyée du sous-système informatique de première zone vers le sous-système informatique de deuxième zone qui commande l'étape de lecture 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 et l'étape de mise à jour.
Particulièrement encore, le deuxième registre de consignation est géré par un sous-système informatique d'une première zone, le premier registre de consignation est géré par un sous-système informatique 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 et le sous-système informatique de deuxième zone commande l'étape de recherche et l'étape de mise à jour dans le sous-système informatique de première zone.
Plus particulièrement, 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é.
Avantageusement, le discriminant d'alarme comprend de plus un attribut de cause probable.
Avantageusement encore, le discriminant d'alarme comprend de plus un attribut de problème spécifique.
Plus particulièrement lorsque le premier registre de consignation est géré par le sous-système informatique de première zone, toute notification de changement de valeur d'attribut est conservée dans le sous-système informatique de première zone jusqu'à ce que le sous-système informatique de deuxième zone ait reçu ladite notification. Un deuxième objet de l'invention est un système informatique comprenant au moins un sous-système informatique d'une première zone qui enregistre des valeurs d'attributs d'alarme dans un registre de consignation de première zone, et un sous-système informatique d'une deuxième zone qui enregistre les dites valeurs d'attributs d'alarme dans un registre de consignation de deuxième 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.
Le système informatique est remarquable en ce que le sous-système informatique de première zone comprend un discriminateur de retransmission d'événements pour envoyer les notifications de changement d'attribut qui circulent sur son infrastructure de communication, vers l'infrastructure de communication du sous-système informatique de deuxième zone, le sous- système informatique de deuxième zone comprend un gestionnaire de registre de consignation pour prélever un discriminant d'alarme dans un enregistrement signalé par une notification de changement d'attribut circulant sur son infrastructure de communication, 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é.
Particulièrement le discriminateur de retransmission d'événements du sous-système informatique 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 de deuxième zone. Plusieurs détails et avantages sont illustrés dans l'exemple de mise en œuvre 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 sous- systè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 sous- systè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 (IID) 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 l', 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 l'. 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 ouverts - structure 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 œuvre 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 œuvre 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 œuvre 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 sous- systè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 sous- systè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 première zone, le premier registre de consignation est géré par un sous- systè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 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 sous- systè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.
PCT/FR2001/003688 2000-12-08 2001-11-22 Procede et systeme pour la gestion d'alarmes WO2002046940A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2002222021A AU2002222021A1 (en) 2000-12-08 2001-11-22 Alarm management method and device
AU2002222021A AU2002222021A8 (en) 2000-12-08 2001-11-22 Alarm management method and device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR00/15991 2000-12-08
FR0015991A FR2817983B1 (fr) 2000-12-08 2000-12-08 Procede et systeme pour la gestion d'alarmes

Publications (2)

Publication Number Publication Date
WO2002046940A2 true WO2002046940A2 (fr) 2002-06-13
WO2002046940A3 WO2002046940A3 (fr) 2007-10-18

Family

ID=8857416

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/003688 WO2002046940A2 (fr) 2000-12-08 2001-11-22 Procede et systeme pour la gestion d'alarmes

Country Status (3)

Country Link
AU (2) AU2002222021A1 (fr)
FR (1) FR2817983B1 (fr)
WO (1) WO2002046940A2 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5204955A (en) * 1989-12-18 1993-04-20 Hitachi, Ltd. Network management method and system
WO1996020547A1 (fr) * 1994-12-23 1996-07-04 Italtel Spa Procede de realignement automatique des rapports d'evenements dans un systeme de gestion et dans un systeme connexe
EP0898398A2 (fr) * 1997-08-12 1999-02-24 Lucent Technologies Network Systems UK Limited Méthode et appareil pour re-synchroniser un gestionnaire de réseau à ses agents de réseau
EP0973342A2 (fr) * 1998-07-15 2000-01-19 Siemens Aktiengesellschaft Procédé et système de communication pour le traitement d'alarmes par un réseau de gestion comportant plusieurs niveaux de gestion

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5204955A (en) * 1989-12-18 1993-04-20 Hitachi, Ltd. Network management method and system
WO1996020547A1 (fr) * 1994-12-23 1996-07-04 Italtel Spa Procede de realignement automatique des rapports d'evenements dans un systeme de gestion et dans un systeme connexe
EP0898398A2 (fr) * 1997-08-12 1999-02-24 Lucent Technologies Network Systems UK Limited Méthode et appareil pour re-synchroniser un gestionnaire de réseau à ses agents de réseau
EP0973342A2 (fr) * 1998-07-15 2000-01-19 Siemens Aktiengesellschaft Procédé et système de communication pour le traitement d'alarmes par un réseau de gestion comportant plusieurs niveaux de gestion

Also Published As

Publication number Publication date
AU2002222021A1 (en) 2002-06-18
AU2002222021A8 (en) 2007-12-20
FR2817983A1 (fr) 2002-06-14
WO2002046940A3 (fr) 2007-10-18
FR2817983B1 (fr) 2003-03-28

Similar Documents

Publication Publication Date Title
CN107196804B (zh) 电力系统终端通信接入网告警集中监控系统及方法
US5761502A (en) System and method for managing a telecommunications network by associating and correlating network events
CA2287769C (fr) Systeme de gestion de reseau de communication multiniveaux
CA2385939C (fr) Methode et systeme de gestion de reseau permettant de gerer un reseau a large bande assurant de multiples services
WO1997024838A9 (fr) Systeme et procede de gestion d'un reseau de telecommunications
US8130924B2 (en) Methods and apparatus for processing and display of voice data
US20050102382A1 (en) System and method for network management using instant messaging
FR2662879A1 (fr) Procede de maintenance centralisee, pour un reseau de telephone sans fil.
CA2272609A1 (fr) Systeme de gestion des pannes de logiciels
US7543328B2 (en) Method and system for providing an efficient use of broadband network resources
EP1622310B1 (fr) Procédé et système de gestion pour des systèmes de gestion de réseau
EP0840969B1 (fr) Agent universel de translation d'objets
CN104778825A (zh) 一种智能小区的设备与告警事件处理方法及其系统
WO2002046940A2 (fr) Procede et systeme pour la gestion d'alarmes
WO2002097651A1 (fr) Systeme et procede de gestion de reseau
CA2385208A1 (fr) Methode et systeme permettant d'offrir des ressources de reseau a large bande
US8015278B1 (en) Automating alarm handling in a communications network using network-generated tickets and customer-generated tickets
Ellsworth et al. A non-proprietary network operations platform for openroadm environment
EP1443702A1 (fr) Dispositif perfectionné de gestion d'équipements hétérogènes de réseau de communications
FR2802663A1 (fr) Procede de correlation d'alarmes dans un systeme d'administration hierarchisee
CN114666197B (zh) 基于工业互联网标识解析的网络管理系统及方法
US11444857B2 (en) Network information collection device and method therefor
EP1047222A1 (fr) Procédé de gestion des états de fonctionnement dans un système informatique
KR100275505B1 (ko) 웹기술을 이용한 통합 액세스망 운용관리방법
KR100263386B1 (ko) 망관리 지역센터에서 트랜잭션 랭귀지 1 파싱 처리방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP