Brevet FR2728748A1 — publié le 19960628

La présente invention concerne un appareil et un procédé de gestion et d'exploitation en duplex pour un système d'échange de messages de signalisation nO 1 (SMX-1) et, plus particulièrement, un appareil et un procédé de gestion et d'exploitation en duplex pour un système SMX-1, capable de minimiser une panne du système et de garantir la cohérence des données entre le contenu des bases de données et les données couramment mises en oeuvre par deux sous-systèmes de gestion et d'exploitation qui sont prévus dans le système et mis en oeuvre d'une façon telle que, quand un défaut est engendré dans un des sous-systèmes, l'autre sous-système exécute la fonction à exécuter par le sous-système défaillant. Comme les systèmes SMX-1 incluent généralement un soussystème de gestion et d'exploitation unique, ils sont difficilement applicables dans des environnements variés, compliqués, nécessitant des fonctions d'établissement, d'expansion, de réduction, de contrôle du système, de détection d'erreurs, et de correction d'erreurs. Par ailleurs, un défaut engendré dans le sous-système de gestion et d'exploitation se répand dans tout le système SMX-1. En conséquence, il est difficile de satisfaire les exigences de l'échange de messages de signalisation, par exemple le rendement, la fonctionnalité, et la fiabilité. En conséquence, la présente invention a été réalisée au vu des problèmes ci-dessus mentionnés et un objet de l'invention est de fournir un appareil et un procédé de gestion et d'exploitation en duplex pour un système SMX-1, capable de minimiser une panne du système et de garantir la cohérence des données entre le contenu des bases de données et les données couramment mises en oeuvre par deux sous-systèmes de gestion et d'exploitation qui sont prévus dans le système et mis en oeuvre d'une façon telle que, quand un défaut est engendré dans un des sous-systèmes, l'autre sous-système exécute la fonction à exécuter par le sous-système défaillant. Conformément à un aspect, la présente invention fournit un appareil de gestion et d'exploitation en duplex pour un système d'échange de messages de signalisation nO 1 comprenant : une paire de moyens de gestion d'exploitation dupliqués, les deux reliés au système cible SXX-1 par des moyens d'unité d'interface à bus et reliés à un système d'exploitation à réseau de signalisation séparé par des moyens de transmission et de réception, un des moyens de gestion d'exploitation étant en service pour exécuter une gestion des ressources en réseau et une gestion d'états de réseaux de signalisation, tandis que l'autre moyen de gestion d'exploitation est en attente. Conformément à un autre aspect, la présente invention fournit un procédé pour commander un sous-système de gestion et d'exploitation en duplex dans un système d'échange de messages de signalisation nO 1. Le sous-système inclut une paire de moyens de gestion d'exploitation dupliqués, les deux reliés au système cible par des moyens d'unité d'interface à bus et reliés à un système d'exploitation à réseau de signalisation séparé par des moyens de transmission et de réception, un premier des moyens de gestion d'exploitation étant en service pour effectuer une gestion des ressources en réseau et une gestion d'états de réseaux de signalisation, tandis que le second moyen de gestion d'exploitation est en attente, comprenant les étapes consistant à (a) démarrer le sous-système de gestion et d'exploitation étant dans un état inactif quand un message pour démarrer et redémarrer le sous-système est sorti d'un site de travail et, ensuite, déterminer si, ou non, le sous-système a démarré ; (b) faire passer le sous-système vers un état de panne quand le démarrage du sous-système a échoue à l'étape (a), tandis que l'on fait passer le premier moyen de gestion d'exploitation étant couramment dans un état normal dans un état disponible et que l'on fait passer le second moyen de gestion d'exploitation dans un état en attente quand le démarrage du sous-système a été couronné de succès ;; (c) mettre en oeuvre le premier moyen de gestion et d'exploitation étant dans l'état disponible à l'étape (b) pour démarrer le système cible et, ensuite, faire passer le premier moyen de gestion et d'exploitation dans un état en service quand le démarrage du système cible a été couronné de succès, tandis que l'on fait passer le premier moyen de gestion et d'exploitation à nouveau dans l'état disponible quand le démarrage du système cible a échoué ;; (d) faire passer le premier moyen de gestion et d'exploitation étant dans l'état en service à l'étape (c) dans un état de panne quand le premier moyen de gestion et d'exploitation reçoit un message de panne d'une unité de maintenance et de test globale du système cible, tandis que l'on fait passer le premier moyen de gestion et d'exploitation dans un état en attente quand le premier moyen de gestion et d'exploitation reçoit un message de commutation d'état du site de travail (d) faire passer le second moyen de gestion et d'exploitation étant dans l'état en attente à l'étape (b) dans un état en service quand le second moyen de gestion et d'exploitation reçoit un message de commutation d'état à partir de l'unité de maintenance et de test globale du système cible, faire passer le second moyen de gestion et d'exploitation dans un état de panne quand une panne est détectée par le second moyen de gestion et d'exploitation, et faire passer le second moyen de gestion et d'exploitation dans l'état de panne quand une panne de commutation, provoquée par le second moyen de gestion et d'exploitation, se produit, tandis que l'on fait passer le second moyen de gestion et d'exploitation dans l'état en attente quand une panne de commutation provoquée par le système cible se produit ; et (f) faire passer le sous-système dans l'état de panne à l'étape (b) dans un état en attente quand le sous-système reçoit un message de correction de panne du site de travail. Les figures du dessin annexé feront bien comprendre comment l'invention peut être réalisée. La figure 1 est un diagramme bloc illustrant la configuration du matériel d'un système auquel la présente invention est appliquée. La figure 2 est un diagramme bloc illustrant la configuration détaillée d'un sous-système de gestion et d'exploitation (OMS) montré sur la figure 1. La figure 3 illustre la configuration d'un OMS duplex conformément à la présente invention. La figure 4 est un diagramme bloc illustrant des blocs fonctionnels de chaque module OMS (OMM) montré sur la figure 3. Les figures 5A et 5B sont des organigrammes illustrant respectivement toute la procédure de passage d'état exécutée par chaque OMM de la figure 3. Les figures 6 à 9 sont des organigrammes illustrant respectivement différentes procédures de passage d'état exécutées dans 1'OMM en liaison avec toute la procédure du passage d'état des figures SA et 5B. La figure 10 est un organigramme illustrant une partie de la procédure de commutation d'état qui est automatiquement exécutée dans 1'OMM. La figure il est un organigramme illustrant une partie de la procédure de commutation d'état qui est manuellement exé cutée dans l'OMM. La figure 12 est un organigramme illustrant une procédure pour commander à nouveau l'environnement des bases de données associées à l'OMM. La figure 13 est un organigramme illustrant une procédure pour des procédés de contrôle garantissant la fonction duplex de l'OMM. La figure 1 illustre la configuration du matériel d'un système auquel la présente invention est appliquée. En se référant à la figure 1, un sous-système de gestion et d'exploitation (OMS) 101 est montré comme étant relié à un système cible SMX-1 102 via un sous-système d'interconnexion 103 référencé en tant que "bus". Le système cible SMX-1 102 comprend un module de traitement de messages de signalisation (SMHM) 104 et un module de maintenance de test global et de réseau de signalisation (SNGTMM) 105. L'OMS 101 comprend un système HP9000/375 qui est un super-microordinateur. A ce système, plusieurs moniteurs (dans le cas illustré, seulement quatre moniteurs 107, 108, 109 et 110 sont représentés) sont reliés par l'intermédiaire de bornes fictives. Egalement, une imprimante 111 est reliée au super-microordinateur afin de sortir des messages reçus du système cible 102. Pour une maintenance de réseaux de signalisation, le super-microordinateur est relié à un système d'exploitation de réseaux de signalisation via un modem 106. L'OMS 101 utilise une base de données 112 appelée "Allbase" pour stocker et extraire des messages. La figure 2 illustre une configuration détaillée de l'OMS 101 montré sur la figure 1. L'OMS 101, qui est relié au système cible SMX-1 via le bus 103, comprend six sous-systèmes, un système d'interface d'utilisateur 203, un sous-système d'interface de cible 204, un sous-système de commande d'exploitation 205, un système d'exploitation de réseaux de signalisation (SIGNOS), un sous-système d"dchange 206, un sous-système de gestion OMS 207 et un sous-système de gestion de données 208. Le sous-système d'interface d'utilisateur 203 exécute des fonctions pour rendre disponible l'équipement aux utilisateurs. C'est-à-dire, le sous-système d'interface d'utilisateur 203 fournit des fonctions associées à des sites de travail de gestion et d'exploitation, des sites de travail de réparation et de maintenance, une imprimante, un moniteur d'alarme graphique et une console de système. Toutes les commandes d'entrée et de sortie associées au sous-système d'interface d'utilisateur 203 sont traitées par un fichier de commande 210. Le sous-système d'interface de cible 204 est relié au bus 103 par une unité d'interface de bus (HIFU) incluant des cartes HIFU[P] et HIFU[S]. Ces deux groupes de cartes HIFU, HIFU[P] et HIFU[S], sont reliés à deux lignes bus respectivement. Pendant que le système est en service, la liaison du sous-système d'interface de cible 204 au bus 103 est réalisée usuellement par les cartes HIFU[P]. A ce moment, les autres cartes HIFU[S] sont dans un état en attente. En fait, la liaison au bus 103 à un moment est réalisée seulement par l'une des cartes HIFU[P]. Au moment où un défaut est engendré dans le système, la liaison est commutée de sorte qu'elle est réalisée par l'une des cartes HIFU[S] en attente. Le sous-système de commande d'exploitation 205 présente une fonction de mettre en oeuvre, stocker et traiter, sous la forme de messages compatibles avec l'OMS 101, toutes les commandes et les messages reçus des sites de travail de gestion et d'exploitation et du sous-système d'interface de cible 204. Le sous-système d'échange SIGNOS 206 sert à supporter une liaison opératoire de l'OMS 101 vers un système d'exploitation de réseaux de signalisation (SIGNOS). A cette fin, le sous-système d'échange SIGNOS 206 présente une fonction de réception et de mise en oeuvre des commandes du SIGNOS ou, périodiquement, de rapports de résultats de l'exploitation du système au SIGNOS. Le sous-système de gestion OMS 207 présente une fonction de gestion et d'administration de tous les processus, c'est-àdire, des processus inhabituels et des processus transitoires qui existent dans l'OMS 101. Pour garantir une gestion de processus efficace, le sous-système de gestion OMS 207 utilise un mécanisme de communication interprocessus (IPC), le système de fin de message. Finalement, le sous-système de gestion de données 208 présente une fonction de stockage et de gestion de toutes le données associées au SMX-1 sous la forme permettant le changement, l'extraction, l'entrée, la sortie et la mise en oeuvre de celles-ci pour obtenir des données requises pour les utilisateurs de l'OMS 101 et du SIGNOS. Le sous-système de gestion de données 208 utilise une base de données 209 stockant une variété de données sur la configuration du système, la spécification des réseaux de signalisation, des statistiques/mesures, et l'interface de l'utilisateur. La figure 3 illustre la configuration d'un OMS duplex selon la présente invention. En se référant à la figure 3, deux modules OMS (OMM) 301 et 302 sont montrés, qui sont reliés à un système cible, c'est-à-dire un système SMX-1. Pendant une exploitation du système, seul un des OMM, c'est-à-dire l'OMM 301, est en service (OMM[P]), tandis que l'autre OMM 302 est dans un état en attente (OMM[S]). Une paire de cartes HIFU 303 et 307 sont reliées à l'OMM[P] 301 pour la liaison au système cible. Pendant que l'OMMP 301 est en service, seule une des cartes HIFU, c'est-à-dire la carte HIFU 307, est en service (HIFU[P]), tandis que l'autre carte HIFU 303 est dans un état en attente (HIFU[S]). De façon semblable, une paire de cartes HIFU 304 et 308 sont reliées à l'OMM[S] 302. Dans le cas de l'OMM[S] 302, la carte 308 sert comme carte HIFU[P], tandis que la carte 304 sert comme carte HIFU[S]. Avec une telle liaison, l'OMS duplex de la présente invention a la capacité de traiter rapidement tout défaut du système. Les cartes HIFU[P] et les cartes HIFU[S] se branchant à partir des OMM 301 et 302 sont reliées aux lignes d'interface 305 et 306 se branchant à partir du système cible, respectivement. L'OMM[P] 301 et l'OMM[S] 302 sont reliés en commun à un moniteur d'alarme graphique 307 via un LAN, tel que RS-232C, pour obtenir toujours la transmission et la réception de messages relativement au moniteur d'alarme graphique 307. A la fois les OMM 301 et 302 sont également reliés à un système SIGNOS séparé 308 par un réseau X.25 utilisant un modem. En conséquence, il est possible de gérer efficacement les ressources des réseaux et d'établir des réseaux de signalisation. La figure 4 est un diagramme bloc illustrant des blocs fonctionnels de chaque OMM montré sur la figure 3. Comme montré sur la figure 4, chaque OMM 301 ou 302 inclut un bloc fonctionnel de duplication d'OMM 402 et un bloc fonctionnel de réparation et de maintenance d'OMM 403. Le bloc fonctionnel de duplication d'O1MM 402 inclut un bloc fonctionnel de gestion de l'état d'OMM 404, un bloc fonctionnel de mise en oeuvre de commutation d'OMM 405, un bloc fonctionnel de mise en oeuvre de cohérence de bases de données 406, et un bloc fonctionnel de mise en oeuvre de reproduction de données 407. Par ailleurs, le bloc fonctionnel de réparation et de maintenance d'OMM 403 inclut un bloc fonctionnel de rapport d'état 408, un bloc fonctionnel de détection et de rapport de panne 409, et un bloc fonctionnel de réparation de panne 410. Maintenant, les blocs fonctionnels mentionnés ci-dessus seront décrits en détail. *Bloc fonctionnel de gestion d'état d'OMM 404 Ce bloc 404 exécute le gestion pour l'état d'exploitation de l'OMM associé. Il détermine les flux d'entrées reçus du système cible et des sites de travail de l'utilisateur conformément à cinq états de transit ou de passage définis sur les figures 5A et 5B. *Bloc fonctionnel de mise en oeuvre de commutation d'OMM 405 Ce bloc 405 exécute une procédure pour rétablir les fonctions de l'OMM quand une commutation d'OMM se produit. I1 réalise une opération pour commuter l'OMM en attente d'un état en attente dans un état en service. En d'autres termes, le bloc 405 exécute l'opération pour atteindre la cohérence des bases de données en mettant en attente des messages présents (OOM) engendrés pendant une période de correction de panne, la commande des sites de travail, la réinitialisation de l'écran d'alarme, le redémarrage de la fonction de statistiques et de mesures, et le réglage de la liaison opératoire au SIGNOS. *Bloc fonctionnel de mise en oeuvre de cohérence des bases de données 406 Ce bloc 406 fonctionne pour établir la cohérence des bases de données entre deux OMM. Cette cohérence des bases de données est fournie pour les bases de données associées à la catégorie basique de structure de duplication d'OMM. En principe, ce bloc 406 est appliqué seulement à l'addition et au retrait de tables associées à des fonctions du SIGNOS et au contenu de bases de données existantes. *Bloc fonctionnel de mise en oeuvre de reproduction de données 407 Ce bloc 407 extrait des données de statuts du système et des données de gestion de module à partir d'un module de gestion de réseaux de signalisation (SNGTMM) de façon à fournir la cohérence de différentes données de statuts quand la commutation d'OMM se produit. *Bloc fonctionnel de rapport de statuts 408 Ce bloc 408 exécute une fonction pour rapporter l'état de 1'OMM à la demande d'une unité de maintenance et de test globale (GTMU) du système cible. *Bloc fonctionnel de rapport et de détection de panne 409 Ce bloc 409 détecte des pannes de modules essentiels de 1'OMM et les rapporte à la GTMU du système cible. Des modules à contrôler par le bloc 409 incluent des processus inhabituels, IPC, des bases de données, une fonction de liaison de cible et une fonction de liaison opératoire au SIGNOS. *Bloc fonctionnel de réparation de panne 410 Ce bloc 410 exécute une fonction nécessaire pour commuter 1'OMM en panne de l'état de panne à l'état en attente. Cette fonction signifie une fonction de réparation réalisée par l'utilisateur. La figure 5A illustre une procédure de passage d'état exécutée par les OMM de la figure 3. De façon à gerer efficacement les fonctions dupliquées des OMM, chaque OMM présente cinq états de passage. Ces états de l'OMM sont définis différemment de ceux utilisés dans la GTMU du système SMX-1 à cause de particularités fonctionnelles et matérielles de l'OMM. Les cinq états de passage, comme mentionné ci-dessus, sont les suivants *Etat inactif (501) Cet état 501 est l'état dans lequel un travail opératoire LOGO (écran initial) du système SMX-1 est affiché dans une condition dans laquelle un ordinateur de gestion d'exploitation est lancé seulement pour exécuter une fonction de calcul générale. *Etat disponible (502) Cet état 502 est l'état dans lequel l'exécution d'une fonction d'OMM est démarrée par l'utilisateur dans l'état inactif 501. Dans cet état 502, l'exécution des processus inhabituels de 1'OMM commence. L'initialisation des bases de données est également réalisée. Dans l'état 502, en conséquence, l'OMM est dans un état dans lequel il peut être relié au système cible. état en attente (503) Cet état 503 est l'état dans lequel l'initialisation de l'OMM a été réalisée, c est-à-dire l'état dans lequel le démarrage des processus inhabituels et l'initialisation des bases de données ont été réalisés. Dans cet état 503, une commutation dans un état en service est possible pour fournir des services souhaités. En réponse à une commande de commutation, cette commutation est exécutée après rétablissement des bases de données et redémarrage des opérations d'environnement, telles qu'un affichage sur écran d'alarme graphique, une liaison opératoire au SIGNOS, une mise en oeuvre de mesures, un traitement aux sites de travail, et analogues. *Etat en service (504) Cet état 504 est l'état dans lequel la fonction globale du système SMX-1 est en train d'être exécutée sans aucun problème dans une condition dans laquelle le transfert des programmes du système cible et le démarrage du système cible (par exemple, des commandes pour bloquer la libération et un démarrage nO 7) ont été exécutés. Dans l'état en service 504, l'OMM exécute la collecte et le traitement de messages d'état à partir du système cible, le traitement de commandes des sites de travail et le traitement de commandes du SIGNOS d'une façon souhaitée. *Etat de panne (505) Cet état 505 est l'état dans lequel une anormalité fonctionnelle ou une panne se produit dans l'OMM, en empêchant ainsi l'OMM d'exécuter normalement ses fonctions. La figure 5B illustre une procédure de commande de l'OMS dépendant d'un passage d'état. Cette procédure sera décrite en détail en liaison avec les figures 6 à 9. La figure 6 est un organigramme illustrant une procédure de passage d'état de l'OMS de l'état inactif à l'état disponible ou à l'état en attente. Une fois que de la puissance a été fournie par l'utilisateur à l'OMS étant dans l'état inactif (étape 601) à l'étape 602, une initialisation des bases de données est exécutée à l'étape 605 sur la base de savoir si oui ou non l'OMS a démarré (étape 603). Après que l'initialisation des bases de données a été achevée (étape 606), on réalise une détermination concernant les conditions des OMM prévus dans 1'OMS duplex (étape 607). Un des OMM, étant couramment dans une condition normale, est établi comme un système disponible pouvant fonctionner couramment (étape 608). L'autre OMM est établi comme un système en attente (étape 609). La figure 7 est un organigramme illustrant une procédure de passage d'état de 1'OMM de l'état disponible à l'état en service. L'OMM étant dans un état disponible (étape 701) exécute le transfert des données initiales à utiliser dans le système cible (étape 702). Sur la base de savoir si le transfert des données a été réalisé avec succès ou a échoué (étape 703), le démarrage du système cible est exécuté à l'étape 704. Après que le démarrage du système cible a été achevé (étape 705), 1'OMM est commuté vers l'état en service (étape 706). La figure 8 est un organigramme illustrant une procédure de passage d'état de 1'OMM de l'état en service vers l'état de panne ou vers l'état en attente. Quand 1'OMM étant dans un état en service (étape 801) fonctionne normalement, il exécute en douceur des opérations associées à des communications d'échange (IPC) de commandes des sites de travail et de messages du système cible et une liaison opératoire au SIGNOS (étape 802). Quand une panne est trouvée ou détectée, toutefois, une action pour traiter la panne doit être réalisée. La détection de la panne est réalisée de différentes façons, principalement pour trois cas. Quand la panne a été détectée par 1'OMM lui-même (étape 803), elle est immédiatement rapportée à la GTMU du système cible (étape 807) de sorte que le message associé à celle-ci est sorti (étape 811). Dans ce cas, l'état du système est commuté vers l'état de panne (étape 814). Quand 1'OMM reçoit une commande associée à une panne à partir d'un site de travail tel qu'un bloc de traitement de commande d'un poste de travail (WCHB), l'OMM exécute la même procédure que celle dans le cas où 1'OMM détecte la panne par lui-même (étapes 808 et 812). Dans ce cas, l'état du système passe à l'état en attente (étape 815). Même si l'OMM fonctionne normalement, un phénomène anormal peut apparaître dans le système cible, c'est-à-dire le système SMX-l. Dans ce cas, la GTMU du systeme cible sort automatiquement un message associé à l'anormalité (étape 805 et 809). L'état du système passe ensuite vers l'état de panne (étape 813). La figure 9 est un organigramme illustrant une procédure de passage d'état de 1'OMM à partir de l'état en attente vers l'état en service. Quand l'OMM étant dans un état en attente (étape 901) reçoit une commande de commutation de la GTMU du système cible (étape 902), il est nécessaire que le système cible exécute une reproduction des données du système associées à sa GTMU, l'unité de maintenance des réseaux de signalisation (SNMU), et l'unité de commande de liaison de signalisation (SCCU) (étape 903), et ensuite attende jusqu'à ce que la reproduction soit achevée (étape 904). Si un message concernant une variation dans l'état est reçu dans 1'OMM durant l'attente (étape 911), il est stocké dans une mémoire temporaire ou tampon (étape 912). Généralement, cependant, l'OMM substitue, c'est-à-dire met à jour les contenus de toutes les bases de données de celui-ci, par des données juste préalablement utilisées sur la base du message de reproduction engendré à l'étape 905 (étape 906). Après que les contenus de toutes les bases de données ont été mis à jour (étape 907), les données stockées temporairement, c'est-à-dire les données à finalement mettre à jour, sont stockées dans les bases de données associées (étape 908). Ensuite, l'OMM exécute le redémarrage de la liaison opératoire au SIGNOS, libère les états verrouillés des sites de travail, réinitialise l'écran d'alarme graphique et redémarre les statistiques/mesures (étape 909). Après avoir achevé la procédure ci-dessus, l'OMM passe vers l'état en service (étape 910). La figure 10 est un organigramme illustrant une partie de la procédure de commutation d'état qui est exécutée automatiquement dans l'OMM à la demande du système. Quand l'OMM étant dans l'état en attente (étape 1001) reçoit une demande pour sa commutation d'état de la GTMU du système cible (étape 1002), il exécute la reconstruction des bases de données tout en reflétant les OOM tamponnés et les contenus des bases de données dans ceux-ci (étapes 1003 et 1004). Ensuite, on exécute la libération des états verrouillés des sites de travail (étape 1005) et la réinitialisation de l'écran d'alarme graphique (étape 1006). Après achèvement de la réinitialisation de l'écran d'alarme graphique, le redémarrage du SIGNOS (étape 1007) et le redémarrage des statistiques/mesures (étape 1008) sont exécutés. Après achèvement de la procédure ci-dessus, 1'OMM est automatiquement passé dans l'état en service (étape 1009) La figure 11 est un organigramme illustrant une partie de la procédure de commutation d'état qui est exécutée manuellement dans l'OMM à la demande de l'utilisateur. Quand l'utilisateur code un langage de commande pour une demande de commutation dans 1'OMM étant dans l'état inactif (étape 1101) à l'étape 1102, le langage de commande est envoyé à la GTMU du système cible selon l'état courant de l'OMM déterminé à l'étape 1103 (étape 1104) de sorte que la procédure de commutation d'état de l'OMM est immédiatement exécutée (étape 1105). En conséquence, l'OMM passe de l'état en service à l'état en attente (étape 1106). Ensuite, on exécute un aiguillage du bloc de duplication (DUPB) de l'OMM (étape 1107). Après achèvement de l'aiguillage du DUPB, la procédure retourne à l'étape initiale. Dans le cas où la demande de l'utilisateur pour la commutation d'état ne peut pas être admise du fait de l'état courant de l'OMM (étape 1103), cependant, elle est rejetée pour la maintenance et le test global du système (étape 1108). En conséquence, la procédure est renvoyée à l'étape initiale sans exécuter la commutation d'état (étape 1109). La figure 12 est un organigramme illustrant une procédure pour commander à nouveau l'environnement des bases de données associées à 1'OMM. La fonction la plus importante des bases de données de 1'OMM est d'éviter la perte des données qui sont couramment utilisées dans le système cible, c'est-à-dire le système SMX-1 désigné par la référence numérique 1205 sur la figure 12. A cet égard, toutes les données existant dans 1'OMM peuvent être le jeu de données le plus récemment utilisé. A cette fin, une procédure 1204 de message I/O de protocole à bas niveau (LMIO) reçoit des messages de reproduction et des messages OMM du système SMX-1 et les distribue alors comme suit. Les messages OMM sont transférés à une procédure 1202 à bloc de distribution et de collecte de messages (MCDB), tandis que les messages de reproduction sont transférés à une procédure DUPB 1203. En se basant sur le message reçu, la procédure DUPB 1203 met à jour immédiatement le contenu des bases de données. Par ailleurs, la procédure MCDB 1202 exécute la mémorisation des messages OMM dans une mémoire temporaire 1201. La figure 13 est un organigramme illustrant une procédure pour contrôler le statut courant de l'OMM. L'OMS doit toujours contrôler le statut courant de chaque processus de celui-ci pour garantir sa fonction duplex. De façon à contrôler le statut de l'OMM, l'OMS utilise deux procédés de contrôle. L'un des procédés de contrôle est de contrôler toujours les statuts des processus d'application couramment utilisés tandis que l'autre procédé de contrôle est de détecter positivement les statuts courants des processus par des horloges de contrôle. Tout d'abord, le procédé de contrôle du statut des processus d'application dans l'OMS sera décrit. Chaque processus, en service, dans l'OMM étant dans l'état inactif (étape 1301) laisse un message sous la forme d'un identificateur de processus quand il passe dans un état anormal ou est en panne pendant son exécution (étape 1302). En réponse à ce message, l'OMS vérifie le moment d'aiguillage le plus récent (étape 1303) et vérifie ensuite l'intervalle de contrôle courant (étape 1304). Quand l'intervalle de contrôle courant est achevé, c'est-à-dire quand le temps de contrôle au niveau de l'intervalle de contrôle courant s'est écoulé, l'aiguillage des processus d'application associés au processus ci-dessus est exécuté à nouveau (étape 1306). Ensuite, les tables de contrôle de tous les processus associés aux processus d'application aiguillés sont mises à jour (étapes 1309 et 1311). Quand l'intervalle de contrôle courant n'est pas encore achevé, c'est-à-dire quand le temps de contrôle au niveau de l'intervalle de contrôle courant ne s'est pas encore écoulé, une vérification est réalisée concernant le comptage de fuite (étape 1305) de sorte que le comptage des adresses de fuite est ajusté pour ne pas être inférieur à une valeur de référence (étape 1307). Ensuite, la panne est rapportée à la GTMU du système cible (étape 1308). L'utilisateur est également informé de la panne du système (étape 1310). Maintenant, le procédé de contrôle du statut de chaque état utilisant des horloges de contrôle sera décrit. Une vérification est réalisée concernant le fait de savoir si la ressource est utile ou non, en prévoyant une horloge de contrôle pour chacun des processus en service (étape 1313). Dans le cas où l'horloge de contrôle existe dans le processus (étape 1314), une vérification est réalisée concernant le fait que le processus est un processus stoppé ou non (étape 1315). Si le processus est normal (étape 1317), l'OMM fonctionne normalement (étape 1318). Sinon, l'OMM passe dans l'état de panne (étape 1312). Dans le cas où l'existence de l'horloge de contrôle n'est pas claire, cependant, on suppose qu'une erreur du système s'est produite (étape 1314). Ensuite, une vérification est réalisée concernant le fait que l'horloge de contrôle existe de façon duplicative dans un autre processus ou qu'aucune erreur du système ne s'est produite (étape 1320). Dans le cas où aucune erreur du système ne s'est produite (étape 1320), une vérification est faite concernant le comptage d'adresses de fuite (étape 1326). Ensuite, on réalise une détermination pour savoir si le comptage d'adresses de fuite n'est pas inférieur à la valeur de référence (étape 1327). Quand le comptage d'adresses de fuite n'est pas inférieur à la valeur de référence, la panne est rapportée à la GTMU du système cible (étape 1324). L'utilisateur est également informé de la panne du système (étape 1325). Quand le comptage d'adresses de fuite est inférieur à la valeur de référence, l'aiguillage des processus d'application associés au processus ci-dessus est exécute à nouveau (étape 1328). Ensuite, les tables de contrôle de tous les processus associés au processus d'application aiguillé sont mises à jour (étape 1329 et 1330). Par ailleurs, quand l'horloge de contrôle existe de façon duplicative dans un autre processus (étape 1319), une détermination est réalisée concernant les processus a éliminer (étape 1321). A l'étape 1321, les processus deter- minés sont éliminés. Ensuite, l'OMM revient dans son état précédent (étape 1321) de sorte qu'il fonctionne normalement (étape 1323). Comme cela est évident à partir de la description ci-dessus, la présente invention fournit un appareil et un procédé de gestion et d'exploitation en duplex pour un système SMX-1, capables de minimiser une panne du système et de garantir la cohérence des données entre le contenu des bases de données et les données couramment en service par deux OMM opérant d'une façon telle que, quand une panne se produit dans un des OMM, l'autre OMM exécute la fonction à exécuter par le premier OMM. REVENDICATIONS 1. Appareil de gestion et d'exploitation en duplex pour un système d'échange de messages de signalisation nO 1, caractérisé en ce qu'il comprend une paire de moyens de gestion d'exploitation dupliqués à la fois reliés au système cible par des moyens d'unité d'interface à bus et reliés à un système d'exploitation de réseaux de signalisation séparé par des moyens de réception et de transmission, l'un des moyens de gestion d'exploitation étant en service pour exécuter une gestion de ressources de réseaux et une gestion d'états de réseaux de signalisation, tandis que l'autre moyen de gestion d'exploitation est en attente. 2. Appareil selon la revendication 1, caractérisé en ce que chacun des moyens de gestion et d'exploitation comprend - une unite fonctionnelle de gestion d'état pour gérer un état fonctionnel des moyens de gestion d'exploitation - une unité fonctionnelle de mise en oeuvre de commutation pour exécuter une opération pour rétablir des fonctions des moyens de gestion d'exploitation quand une commutation d'état survient dans les moyens de gestion d'exploitation - une unité fonctionnelle de mise en oeuvre de cohérence des bases de données pour exécuter une opération pour établir une cohérence des bases de données entre les deux moyens de gestion d'exploitation - une unité fonctionnelle de mise en oeuvre de reproduction de données pour extraire des données d'état du système et des données de gestion de modules à partir d'un module de gestion de réseaux de signalisation, en fournissant la cohérence des différentes données d'état quand la commu tation d'état se produit - une unité fonctionnelle de rapport d'état pour rapporter un état courant des moyens de gestion d'exploitation à la demande d'une unité de maintenance et de test globale du système cible - une unité fonctionnelle de rapport et de détection de panne pour détecter des pannes de modules essentiels des moyens de maintenance d'exploitation et les rapporter à l'unité de maintenance et de test globale du système cible ; et - une unité fonctionnelle de réparation de panne pour exécuter l'opération requise pour faire passer les moyens de maintenance d'exploitation d'un état de panne à un état en attente. 3. Procédé pour commander un sous-système de gestion et d'exploitation en duplex dans un système d'échange de messages de signalisation nO 1 (S.MX-1), le sous-système incluant une paire de moyens de gestion d'exploitation dupliqués reliés à la fois au système cible par des moyens d'unité d'interface à bus et relies à un système d'exploitation de réseaux de signalisation séparé par des moyens de réception et de transmission, un premier des moyens de gestion d'exploitation étant en service pour exécuter la gestion de ressources de réseaux et la gestion d'états de réseaux de signalisation, tandis que le second moyen de gestion d'exploitation est en attente, caractérisé en ce qu'il comprend les étapes consistant à (a) démarrer le sous-système de gestion et d'exploitation étant dans un état inactif, quand un message pour démarrer et redémarrer le sous-système est sorti d'un site de travail, et ensuite déterminer si oui ou non le sous-système a démarre ; (b) faire passer le sous-système vers un état de panne quand le démarrage du sous-système a échoué à l'étape (a), tout en faisant passer le premier moyen de gestion d'exploitation couramment à l'état normal vers un état disponible, et faire passer le second moyen de gestion d'exploitation vers un état d'attente quand le démarrage du sous-système a été réussi (c) exploiter le premier moyen de gestion et d'exploitation étant à l'état disponible à l'étape (b) pour démarrer le système cible et ensuite faire passer le premier moyen de gestion et d'exploitation vers un état en service quand le démarrage du système cible a été réussi, tout en faisant passer le premier moyen de gestion et d'exploitation vers un état disponible de nouveau quand le démarrage du système cible a échoué (d) faire passer le premier moyen de gestion et d'exploitation étant à l'état en service à l'étape (c) vers un état de panne quand le premier moyen de gestion et d'exploitation reçoit un message de panne d'une unité de maintenance et de test globale du système cible, tout en faisant passer le premier moyen de gestion et d'exploitation vers un état en attente quand le premier moyen de gestion et d'exploitation reçoit un message de commutation d'état du site de travail (e) faire passer le second moyen de gestion et d'exploitation étant à l'état en attente à l'étape (b) vers un état en service quand le second moyen de gestion et d'exploitation reçoit un message de commutation d'état de l'unité de maintenance et de test globale du système cible, faire passer le second moyen de gestion et d'exploitation vers un état de panne quand une panne est détectée par le second moyen de gestion et d'exploitation et faire passer le second moyen de gestion et d'exploitation vers l'état de panne quand une panne de commutation, provoquée par le second moyen de gestion et d'exploitation, se produit, tout en faisant passer le second moyen de gestion et d'exploitation vers l'état en attente quand une panne de commutation provoquée par le système cible se produit ; et (f) faire passer le sous-système étant à l'état de panne à l'étape (b) vers un état en attente quand le sous-système reçoit un message de correction de panne du site de travail.