NISSRI-MLL
Télécharger le fichier pdf d’un mémoire de fin d’études
Les moyens matériels de maintenance :
-Les détecteurs intégrés aux équipements :
Un des moyens utilisés pour détecter les défauts de fonctionnement des équipements est d’intégrer aux organes des dispositifs de contrôle de bonne exécution pouvant renvoyer un signal vers l’organe d’ordre hiérarchique supérieur. Les dispositifs généralement utilisés sont :
%& Des circuits de contrôle d’adressage entre unité centrale et périphériques qui vérifient qu’un organe s’est reconnu ;
%& Des circuits de contrôle de parité qui vérifient que les données transmises n’ont pas été perturbés ;
%& Des circuits de contrôle de décodage d’adresse qui vérifient qu’une seule adresse parmi n a été décodée, pour l’établissement d’un chemin ou la sélection d’un circuit terminal par exemple ;
%& Des circuits « chiens de garde » qui alarment s’ils ne sont pas activés périodiquement ;
%& Des détecteurs de présence de signaux d’horloge dans les organes des systèmes temporels….
-Les équipements de test programmés :
Les équipements de test programmés sont des équipements pilotés par le calculateur de commande. Ils sont connectés temporairement aux organes dont ils testent le fonctionnement en simulant leur environnement. Par exemple, un joncteur arrivée est connecté à un équipement qui simule le décrochage d’un poste téléphonique. Le programme de test vérifie que l’information de décrochage est détectée par le joncteur. Il commande l’envoi de sonnerie et vérifie que le signal de sonnerie est détecté par le dispositif de test.
Les moyens logiciels de maintenance
-Les programmes de test
Les programmes de test sont des séquences ordonnées d’ordres à un organe, mettant successivement en action toutes les fonctions de l’organe pour déterminer son état, bon ou mauvais. Ils consistent à faire des vérifications d’accès (adresse et données) par écriture lecture, des détections d’erreur de parité…Ces programmes peuvent être déroulés successivement sur tous les équipements, ou même être lancés par l’opérateur en cas de doute.
-Les programmes de localisation ou « diagnostic des pannes »
Ils sont destinés à déceler l’élément enfichable contenant la panne dans un organe trouvé en faute par un programme de test. Programme de test et diagnostic des pannes sont souvent confus. Toutefois, les programmes de test sont limités à un test bon/mauvais de l’organe ; tandis que le diagnostic, en fonction des données reçues, permet d’isoler l’élément physique en faute.
Exemple2 : Maintenance des réseaux téléinformatiques
Un réseau téléinformatique (en général, nous parlons ici de réseau étendu de type WAN : Wide Area Network, pour lequel le nombre de composants est très important) est un système complexe qu’on doit organiser et maintenir. La multiplicité, l’hétérogénéité de ses éléments constitutifs, de ses modes de fonctionnement et de ses applications, rendent sa gestion et sa maîtrise difficile. Les outils et les méthodes de maintenance de réseau doivent être conçus et mis en place, si possible lors de la conception du réseau, pour garantir un service de réseau harmonieux et efficace. Le réseau est sujet à des modifications fréquentes. De plus, il est vulnérable, menacé de pannes, de dysfonctionnements et d’utilisation anarchique ou intempestive de ses ressources. La vulnérabilité et la complexité d’un réseau s’accroissent avec sa taille et les niveaux d’hétérogénéité qu’il sous-tend.
Le gestionnaire de réseaux, aussi appelé « Opérateur », doit gérer l’urgence et anticiper l’avenir. Il doit être réactif et préventif.
Voici comment s’effectue la gestion des pannes dans les réseaux, selon [4] :
Lors d’un fonctionnement anormal d’un système, deux types de défauts peuvent être mis en cause:
%& Les défauts internes, qui résultent d’un composant en panne. A chaque utilisation du composant, le défaut se manifeste. Ainsi, ce type de problème présente un caractère répétitif.
%& Les défauts externes, qui dépendent de l’environnement du système. Ils se produisent de façon intermittente, leur résolution est plus difficile que ceux du premier type.
Le passage d’un état de fonctionnement correct à celui de panne n’est pas instantané. Un composant commence à fournir un service dégradé avant de tomber franchement en panne. La durée du mode dégradé est plus ou moins longue.
Le traitement d’une panne se décompose en quatre étapes : la signalisation du fonctionnement anormal, la localisation, la réparation et la confirmation du retour au fonctionnement normal.
%& Signalisation du fonctionnement anormal :
Trois outils permettent de détecter les défauts : les messages d’erreur, les tests et les seuils. Un composant s’apercevant d’une anomalie génère automatiquement un message d’erreur vers un fichier erreur (signalisation). Trois attributs caractérisent cette erreur : l’identificateur du composant, le type d’erreur et sa date.
Ensuite, les tests représentent le deuxième outil permettant de détecter les problèmes dans le réseau. On distingue deux types de tests : les tests de sécurité et les tests de diagnostic. Les premiers ont pour but de tester un maximum d’élément en un minimum de temps. Plusieurs composants sont éprouvés en parallèle. Au contraire, les composants sont mis à l’épreuve en séquence lors du test de diagnostic.
Enfin, les seuils représentent le troisième outil capable de détecter les défauts. En fixant les seuils, il n’est possible d’émettre des alarmes que lors de leur franchissement. La valeur du seuil est déterminée de façon empirique.
%& La localisation des défauts et la réparation :
L’établissement d’un diagnostic comporte deux étapes. La première se présente comme une analyse du passé. Elle se résume à un examen des messages d’erreur et des résultats des tests de sécurité. Si la panne n’est pas localisée au terme de cette étape, il convient de déclencher des tests de diagnostic. Si, et c’est le cas le plus fréquent, le diagnostic se fait manuellement par un opérateur, il peut avoir une durée assez longue. Il est donc possible de les suspendre et de les reprendre ultérieurement.
C’est pour résoudre à cette perte de temps que l’on envisageait d’utiliser les techniques de l’Intelligence Artificielle pour automatiser les diagnostics. C’est en effet l’objectif du présent mémoire.
Les alarmes pour la maintenance en télécommunication
Nous avons vu, par ces deux exemples, que la maintenance d’un système impose la mise en place de systèmes d’alarmes lors de sa conception (« chiens de garde », message d’erreurs …).
Pour définir le terme « alarme », nous allons nous inspirer de [5]. Ainsi le définit-on comme : « l’indication de modification d’une condition qui peut avoir un impact négatif immédiat ou potentiel sur l’état du système surveillé ». Par là, mais à notre manière, nous dirions que l’alarme constitue l’information élémentaire pour la détection des anomalies Elémentaire, puisqu’elle sert uniquement de base pour la localisation des fautes. Mais elle ne se porte pas sur des informations sûres et précises (les raisons sont citées plus bas).
Une signalisation d’alarmes, quelque soit le système qui la contient, est caractérisée par quatre attributs :
%& Le type d’alarme,
%& L’identificateur du composant émetteur,
%& La cause probable,
%& La date.
Le premier attribut indique le type d’alarmes (voir Tableau I-1). Le second attribut indique la ressource où la panne a été détectée. La cause probable sert à la description du dysfonctionnement découvert. C’est une traduction en texte du code d’erreur, et malgré son titre, souvent elle n’indique pas vraiment la cause du problème. Par exemple, la cause probable d’une alarme de communication générée sur une entité x indique la perte de signal provenant de l’entité y, sans rien dire sur le pourquoi de cette perte. Le troisième attribut est la date d’occurrence de la détection.
Compte tenu de l’existence de ce système de défense intégré, nous nous demandons où se trouve le problème de la maintenance. En effet, lorsqu’un composant tombe en panne, il émet une alarme et lorsqu’il repasse en état de fonctionnement, il re-émet une alarme : suivre son évolution semble donc relativement simple. Néanmoins, la maintenance est sujette à certaines difficultés :
%& Les alarmes parasites ; les alarmes significatives sont noyées dans un flot d’alarmes qui ne traduisent qu’un fonctionnement normal du système. La première difficulté de la maintenance est donc de retrouver parmi ce flot les alarmes qui sont les conséquences de dysfonctionnements.
%& Le masquage d’alarme ; le phénomène de masquage est la difficulté principale du problème de maintenance. Lorsqu’un composant tombe en panne ou revient en état de fonctionnement, il émet une alarme. Mais ceci ne signifie pas qu’elle arrivera nécessairement à l’opérateur. En effet, pour y arriver, une alarme doit transiter par un certain nombre de composants. Il est possible que l’un des composants par lequel doit-elle transiter ne soit pas en état pour la retransmission. L’alarme est dite « masquée ». Ce phénomène de masquage rend incomplet l’ensemble des alarmes reçues par l’opérateur.
%& La perte d’alarme ; si plusieurs alarmes arrivent en même temps sur un même composant, elles sont stockées dans des tampons. La taille de ceux-ci est limitée et au-dessus d’un certain seuil, les alarmes arrivant sont perdues. Ces phénomènes de masquage et de perte peuvent se produire pour plusieurs raisons, liées à l’occurrence de certaines pannes.
%& Les pannes multiples ; nous parlons de pannes multiples lorsque plusieurs pannes ont des effets qui se chevauchent dans le temps. Une occurrence de panne est associée à un début et à une fin d’occurrence. Nous dirions alors qu’il y a phénomène de pannes multiples lorsque les intervalles de début et de fin de pannes se chevauchent dans le temps. Le fait que des pannes peuvent se produire en même temps peut conduire à un phénomène de masquage. Par exemple, si une panne de rupture de lien a lieu, si une deuxième panne apparaît devant produire une alarme sur le lien rompu, cette alarme sera masquée à cause de la première panne.
%& Les pannes corrélées ; les pannes corrélées ont lieu à cause du phénomène de propagation des pannes. Les pannes corrélées peuvent produire des cascades d’alarmes pouvant être sujettes à des pertes.
Conclusion
Nous venons d’élaborer la fonction maintenance dans les télécommunications en se basant sur deux exemples (autocommutateur et réseaux téléinformatiques). Ainsi, nous pouvons déduire deux problèmes fondamentaux :
Premièrement, un système de télécommunication est souvent un système très complexe ; ceci d’un point de vue logicielle que matérielle. En effet, ce système a pour finalité de desservir un grand nombre d’abonnés. Sa maintenance est donc cruciale, et son concept en est très difficile. Lorsque des anomalies surviennent, il est impossible souvent en pratique qu’un opérateur humain les localise avec précision et certitude.
Deuxièmement, le système d’alarmes, même s’il représente un remède pour la localisation des pannes, est loin d’être suffisant. En effet, pour plusieurs raisons (que nous avons cité plus haut), les alarmes peuvent conduire à des erreurs de détection des pannes.
Il importe alors d’ajouter de nouvelles techniques afin d’assurer une maintenance meilleure de ces systèmes.
C’est donc dans le but de solutionner à ces difficultés que serait concentré le présent mémoire. Nous établirons plus loin les approches existantes. Mais avant, il est utile de présenter certaines notions générales sur ledit diagnostic des pannes.
Généralités sur le diagnostic des pannes dans les télécommunications
Que signifie le terme : diagnostic ?
L’origine étymologique de ce mot signifie : «apprendre à séparer les connaissances : séparer le faux du vrai, le bien du mal, ce qui est sain de ce qui est malade, ce qui est normal de ce qui est en panne». Autrement dit : diagnostiquer c’est savoir discerner.
Le diagnostic des pannes dans les systèmes se fait évidement en trois étapes :
%& Constater que le système n’est plus en fonctionnement normal, donc aux moins une panne s’est produite.
%& Localiser un composant en faute (le composant Ci est en panne).
%& Reconnaître les caractéristiques de la panne trouvée (le composant Ci a subi la panne Pk ).
Qu’est-ce qu’une panne ?
Dans les normes et dans la littérature scientifique, on trouve une grande diversité de termes pour signifier les pannes en général, vues sous des angles différents : défaillance, incident, faute, dysfonctionnement, anomalie, etc. Dans [5] par exemple, on définit les termes suivants :
– erreur : une déviation du système par rapport à l’opération normale ;
– faute : une condition qui provoque un dysfonctionnement (et se manifeste par des erreurs). Pour simplifier et pour bien comprendre le problème de la gestion des pannes dans les télécommunications, nous pouvons proposer une définition de la panne adaptée à ce problème: une panne est un état de non fonctionnement ou de dysfonctionnement, matériel ou logiciel ; pouvant être constaté ou non par un opérateur.
Les pannes peuvent être classifiées comme permanentes ou intermittentes. Une fois produites, les pannes permanentes exigent une action de réparation. Par exemple, un câble sectionné entre deux équipements est une panne permanente. Les pannes intermittentes se manifestent de façon discontinue mais peuvent se répéter au cours du temps. Par exemple, la réinitialisation d’un équipement réseau est une panne intermittente. Elle peut se produire plusieurs fois au cours du fonctionnement du réseau. Le diagnostic des pannes intermittentes est une tâche plus complexe car les conséquences d’une panne de ce type peuvent disparaître.
On distingue aussi les pannes primaires des pannes secondaires. Les premières constituent un ensemble de pannes indépendantes. Du point de vue du système, ces pannes sont spontanées. Par exemple, le fait qu’un câble soit sectionné est une panne primaire. Une telle panne peut être transmise aux autres entités par des liens matériels ou des liens logiciels. Les pannes secondaires apparaissent comme une conséquence d’une ou de plusieurs autres pannes (primaires ou secondaires). Les pannes primaires peuvent donc enchaîner une propagation de pannes dans les systèmes.
Par exemple, la panne primaire « section de câble » peut provoquer les pannes secondaires « réinitialisation d’équipement » sur les équipements physiquement reliés par le câble.
En raison de la complexité et de l’hétérogénéité des systèmes en télécommunication, ces relations de cause à effet ne sont pas toujours déterministes. Ainsi, la propagation des pannes contient un degré d’incertitude vis-à-vis des connaissances de l’opérateur et des informations utilisées par le système de maintenance.
|
Table des matières
INTRODUCTION GENERALE
CHAPITRE I. : DIAGNOSTIC DES PANNES : PROBLEMATIQUE, CONCEPT ET APPROCHES
I.1. La fonction maintenance dans les télécommunications
I.1.1. Qu’est-ce que la maintenance ?
I.1.2. Quels sont ses objectifs ?
I.1.3. Exemples
I.1.3.1. Exemple1 : Maintenance d’un autocommutateur
I.1.3.2. Exemple2 : Maintenance des réseaux téléinformatiques
I.1.4. Les alarmes pour la maintenance en télécommunication
I.1.5. Conclusion
I.2. Généralités sur le diagnostic des pannes dans les télécommunications
I.2.1. Que signifie le terme : diagnostic ?
I.2.2. Qu’est-ce qu’une panne ?
I.2.3. Comment diagnostiquer une panne ?
I.3. Les approches existantes sur le diagnostic des pannes
I.3.1. Approche à base de systèmes experts
I.3.1.1. Principe des systèmes experts
I.3.1.2. Avantages des systèmes experts
I.3.1.3. Inconvénients des systèmes experts:
I.3.1.4. Conclusion
I.3.2. Approche par la reconnaissance des formes
I.4. Conclusion du premier chapitre
CHAPITRE II. THEORIE DE LA RECONNAISSANCE DES FORMES ET APPLICATION POUR LE DIAGNOSTIC DES PANNES
II.1. Généralités sur la reconnaissance des formes
II.2. Les phases de la reconnaissance des formes
II.2.1. La phase d’analyse
II.2.1.1. Détermination de l’espace de représentation
II.2.1.2. Réduction de l’espace de représentation
II.2.1.3. Détermination de l’espace de décision
II.2.2. La phase de choix d’une méthode de décision
II.2.3. La phase d’exploitation
II.3. L’Analyse en Composantes Principales ou ACP
II.3.1. Fondement mathématique de l’ACP normalisée
II.3.2. Algorithme de l’ACP
II.3.3. Lien entre l’ACP et le diagnostic des pannes
II.4. Les méthodes de décision stochastiques en RdF
II.4.1. Introduction à la théorie de la décision Bayesienne
II.4.1.1. Présentation à l’aide d’un exemple
II.4.1.2. Formalisation de la décision Bayesienne dans le cas général
II.4.1.3. Fonctions discriminantes et classifieurs Bayesiens
II.4.1.4. Séparation de l’espace des paramètres en régions
II.4.2. Loi normale et décision Bayesienne
II.4.2.1. Introduction
II.4.2.2. Définition d’une loi normale
II.4.2.3. Fonctions discriminantes pour la loi normale
II.4.2.4. Quelques hypothèses pouvant simplifier la fonction discriminante
II.4.2.5. Remarque
II.4.3. Apprentissage ou évaluation de la loi de probabilité des classes
II.4.4. Méthode de décision des k plus proches voisins (k-ppv)
II.4.4.1. Estimation de la probabilité à posteriori des classes
II.4.4.2. Règle de décision des k plus proches voisins (k-ppv)
II.4.4.3. Problèmes pratiques de la méthode des k-ppv
II.5. Notions sur les autres méthodes et techniques appliquées en RdF
II.5.1. Notions sur les méthodes structurelles ou syntaxiques
II.5.2. Introduction aux méthodes basées sur les neurones artificiels
II.5.2.1. Les neurones biologiques
II.5.2.2. Vers les neurones artificiels
II.5.2.3. Exemple d’application des réseaux de neurones pour le diagnostic des pannes
II.5.3. Notions sur la reconnaissance floue des formes
II.5.3.1. Règle floue avec rejet en ambiguïté
II.5.3.2. Règle floue avec rejet en appartenance
II.6. Application de la reconnaissance des formes pour l’automatisation du diagnostic des
II.7. Conclusion du second chapitre
CHAPITRE III. SIMULATION DE LA REGLE DES K PLUS PROCHES VOISINS, APPLIQUEE AU DIAGNOSTIC D’UN FILTRE A SELECTION DE BANDE PASSANTE 52
III.1. Présentation du circuit de la simulation et notions sur Workbench
III.1.1. Présentation du filtre à sélection de bande passante
III.1.1.1. Schéma et utilité pratique
III.1.1.2. Les blocs du circuit
III.1.2. Notions supplémentaires sur Workbench
III.1.2.1. Utilisation du traceur de Bode
III.1.2.2. Sauvegarde des données apparues sur le traceur
III.2. La programmation orientée objets
III.2.1. Les fondements du modèle à objets
III.2.2. Définition de la programmation orientée objets
III.3. Conception et implémentation de la simulation
III.3.1. Schéma de fonctionnement de l’application
III.3.2. La classe Chargeur
III.3.2.1. Les données membres
III.3.2.2. Le Constructeur Chargeur ( File f )
III.3.2.3. La méthode fichierToStr ( )
III.3.3. La classe OteTete
III.3.4. La classe Lecteur
III.3.4.1. Les variables membres
III.3.4.2. Le constructeur Lecteur(String str)
III.3.4.3. La méthode getTailleForme ( )
III.3.5. La classe Distance
III.3.5.1. La méthode statique euclide (double t1 [] ,double t2 [] )
III.3.5.2. La méthode de classe trie (double listDist [])
III.3.5.3. La méthode kppd (double list [] , int k)
III.3.6. La classe Reconnaissance
III.3.7. Les cadres de l’application
III.3.7.1. Le cadre principal : Cadre1
III.3.7.2. La fenêtre CadreParametre
III.3.7.3. Le cadre de diagnostic : CadreDiagn
III.3.8. Remarques
III.4. Conclusion du dernier chapitre
CONCLUSION GENERALE
ANNEXE I. APERCU SUR LA MAINTENANCE DU SYSTEME OCB 283
ANNEXE II. QUELQUES NOTIONS SUR LA THEORIE DES PROBABILITES
ANNEXE III. INTRODUCTION A LA PROGRAMMATION JAVA
BIBLIOGRAPHIE
Télécharger le rapport complet
