HAL Id: hal-03483438
https://hal.archives-ouvertes.fr/hal-03483438
Submitted on 16 Dec 2021
HAL
is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire
HAL, estdestinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Outil évolutif d’aide à la maintenance
Charly Barré, Ali Saiche, Thibaut Gautier
To cite this version:
Charly Barré, Ali Saiche, Thibaut Gautier. Outil évolutif d’aide à la maintenance. Congrès Lambda
Mu 22 “ Les risques au cœur des transitions ” (e-congrès) - 22e Congrès de Maîtrise des Risques et
de Sûreté de Fonctionnement, Institut pour la Maîtrise des Risques, Oct 2020, Le Havre (e-congrès),
France. �hal-03483438�
Outil évolutif d’aide à la maintenance Evolving maintenance tool
Charly Barré Thales SIX GTS France
Gennevilliers, France charly.barre@thalesgroup.com
Ali Saiche Thales SIX GTS France
Gennevilliers, France ali.saiche@thalesgroup.com
Thibaut Gautier Thales SIX GTS France
Gennevilliers, France thibaut.gautier@thalesgroup.com
Abstract—this communication is a presentation of an innovative solution that aims to provide new diagnosis capabilities. This solution is based at first on RAMT (Reliability, Availability, Maintainability, and Testability) studies and it continuously evolves over time and learns from its past experience.
Résumé—Cette communication présente une solution innovante ayant pour but de fournir des nouvelles capacités de diagnostics. Cette solution est basée sur les études FMDT (Fiabilité, Maintenabilité, Disponibilité, Testabilité) et évolue en continue en apprenant de son expérience passée.
I. INTRODUCTION
Dans un monde où les systèmes sont de plus en plus complexes et interconnectés, les industriels doivent proposer à leurs clients des solutions de soutien performantes pour les aider à mieux opérer et maintenir leurs systèmes afin d’en garantir la disponibilité.
Thales se positionne comme un acteur clé des systèmes critiques, la disponibilité opérationnelle de tels systèmes est cruciale. Cette disponibilité correspond à la capacité du système à fournir le service attendu. C’est dans ce cadre que des architectures redondantes sont privilégiées. Mais lorsqu’une défaillance impliquant la perte d’un service a lieu, les opérationnels doivent avoir la capacité de réagir le plus rapidement possible afin de déterminer l’origine de la défaillance puis de réparer pour remettre en état de bon fonctionnement.
Or ces défaillances n’arrivent pas si fréquemment que cela. Mais leurs conséquences peuvent rapidement avoir un impact très fort. C’est pourquoi les maintenanciers doivent agir vite. Malheureusement, quel que soit le domaine (militaire ou civil), le turn-over important au sein des équipes implique une perte de connaissances. Les maintenanciers rencontrent alors des difficultés à acquérir une connaissance suffisamment fine des systèmes pour pouvoir effectuer le diagnostic et la maintenance rapidement.
La plupart du temps ce n’est pas l’opération de maintenance en tant que telle qui pose problème. Les maintenanciers ont généralement une formation qui leur permet d’effectuer les tâches de maintenance à partir de leur propre expérience. Une fois la bonne procédure trouvée dans l’ensemble de la documentation technique, l’opération se passe souvent pour le mieux.
La réelle difficulté rencontrée par ces opérateurs, réside davantage dans leur capacité à déterminer efficacement et rapidement l’origine de la défaillance. La plupart du temps il ne suffit pas d’identifier une unique diode rouge sur un équipement physique. En tout cas ce ne sont pas ces cas de pannes qui nous intéressent puisqu’ils sont résolus assez facilement.
Mais pour tous les autres cas, Thales a décidé de développer une solution d’aide au diagnostic de panne qui s’appuie sur :
1) Les résultats des études de sûreté de fonctionnement (et plus particulièrement les analyses de testabilité) réalisées durant la phase de conception et de développement du système ;
2) La prise en compte du retour d’expérience (RETEX) lors des phases IVQ (Intégration, Validation, Qualification) directement chez l’industriel et en opération chez le client afin de proposer un diagnostic toujours plus pertinent tout au long de la vie du système.
Il s’agit donc d’une solution évolutive qui apprend, s’améliore avec le temps et vit tout autant que le système opérationnel.
Cette solution a été décomposée en trois modules distincts. L’objet de cette communication est de présenter chacun des modules ainsi que les résultats obtenus et les perspectives futures.
La Erreur ! Source du renvoi introuvable. ci-dessous présente les trois modules de la solution proposée :
A - Modélisation de testabilité
B - Algorithme de diagnostic
C - Interface Homme Machine (IHM) Fig. 1. Modules de la solution
II. TRAVAUX DEVELOPPES ET PRINCIPAUX RESULTATS A. Premier module : la modélisation de testabilité
Le premier module s’appuie sur la création d’une base de connaissances servant de socle initial à la réalisation du diagnostic.
Cette base de connaissances pourrait être réalisée sous différentes formes. Nous avons choisi d’utiliser un outil qui permet de modéliser de manière graphique un système.
L’outil de modélisation permet en phase de conception d’un système d’évaluer sa capacité à être testé et cette représentation graphique facilite les discussions avec les concepteurs.
L’analyse de testabilité s’inscrit dans le cadre des activités de sûreté de fonctionnement menées dès la phase de conception d’un système (voir figure 2 ci-après).
Elle nécessite de mener au préalable l’analyse de fiabilité (taux de défaillance des équipements) ainsi que l’AMDEC (Analyse des Modes de Défaillance, de leurs Effets et Criticités). Elle deviendra ensuite une entrée de l’algorithme de détection au même titre que l’analyse de maintenabilité permettant de définir les temps de remplacement des équipements en défaut. La figure 2 ci-dessous présente les interactions entre les différentes activités de sûreté de fonctionnement et notamment avec l’analyse de testabilité représentée en jaune.
Fiabilité
Testabilité Tests et autotests Taux de couverture
AMDEC Taux de défaillance (λ)
Détection quantitative
qualitative
Analyse Fonctionnelle
Sélection
& extraction
Mode de défaillances et
effets Ø Design
Ø Exigences Ø Mission Ø Organisations
Algorithme
Analyse Maintenabilité
MTTR
Tâche de Maintenance
Taux de Localisation
Fig. 2. Place de la testablité dans les études de SdF
L’étude de testabilité qui est menée pour construire ce premier module est composée de 3 étapes :
- La modélisation du système ; - La définition des tests ;
- La génération des Arbres de Localisation de Pannes (ALP).
Première étape : La modélisation du système
La première étape consiste à modéliser le système en s’appuyant sur l’analyse fonctionnelle réalisée par les équipes d’ingénierie système. Par exemple, la figure ci- dessous représente l’analyse fonctionnelle d’un sous-système de communication UHF/VUHF (Ultra High Frequency/ Very Ultra High Frequency).
Radio VUHF Antenne VUHF
Câble VUHF
Radio UHF2 Antenne UHF2
Câble UHF2
Brassage
Terminal de communication
Modem UHF Switch 1 Switch 2
Radio UHF1 Antenne UHF1 Antenne VHF
Câble garde Câble UHF1
Fig. 3. Analyse fonctionnelle sous-système UHF/VUHF
A partir de ce découpage fonctionnel, la modélisation du sous-système est créée dans l’outil. Le modèle de testabilité ci-après est ainsi obtenu :
Fig. 4. Modèle de testabilité
Le modèle est ensuite enrichi des taux de défaillance des équipements. Ceux-ci permettent de pondérer l’évaluation des taux de détection et d’isolation, qui sont deux critères caractéristiques de l’étude de testabilité. Les taux de défaillance peuvent être issus des analyses prévisionnelles ou de retours d’expérience des fournisseurs, de Thales. Il est important de préciser que les travaux présentés dans cette communication sont réalisés sur des équipements purement électroniques. Il est donc pris pour hypothèse qu’ils suivent la même loi de probabilité exponentielle avec un MTBF constant.
Les dépendances entre les entrées et les sorties des équipements doivent également être identifiées à cette étape afin d’améliorer la précision de la détection.
Deuxième étape : La définition des tests
La définition des tests consiste à intégrer dans le modèle précédent les tests implémentés sur le système ainsi que les tests intégrés aux équipements ou BIT (Built In Test) qui seront remontés à un système de supervision global ou à l’utilisateur directement.
Elle est réalisée en coopération avec les équipes de développement. La modélisation graphique permet d’identifier plus facilement les éléments couverts par des tests. La figure ci-après présente un exemple de définition des tests dans l’outil.
Fig. 5. Définition des tests
Troisième étape : La génération des Arbres de Localisation de Pannes (ALP).
La troisième étape consiste à générer les arbres de localisations de panne en fonction de la modélisation, des liens entre les équipements et des tests définis dans les étapes précédentes. La figure 6 ci-dessous présente un exemple d’ALP issu de l’outil de modélisation. Les liens en vert qui sont verticaux représentent les tests « ok » et les liens en rouge horizontaux les tests « ko.
Fig. 6. Arbre de localisation de pannes
Cet arbre, issu des études de testabilité, permet en fonction d’une combinaison d’états de test, d’identifier un groupe d’éléments pouvant être la cause de la défaillance.
Cependant, il représente uniquement l’état du système à l’instant où l’on a réalisé les études, en l’occurrence durant la phase amont du projet.
C’est à ce stade que le deuxième module qui correspond à l’algorithme de diagnostic de « l’outil d’aide à la maintenance évolutif » trouve son intérêt, puisqu’il va, en fonction du RETEX, ajuster les probabilités de défaillance des équipements.
B. Deuxième module : l’algorithme de diagnostic
Ce deuxième module s’appuie sur celui présenté précédemment pour constituer sa base de connaissance. En effet, le premier module permet de constituer un niveau de connaissance correspondant à ce qui été mis en place durant la phase de développement du projet. Mais le système va continuer à vivre et à évoluer, dans un premier temps durant la phase d’IVQ (Intégration, Vérification, Qualification) du projet puis en exploitation directement chez le client.
Une fois la phase de développement du projet achevée, le premier module n’est plus mis à jour. Il a permis d’initialiser la base de connaissance mais il ne sera pas utile de continuer à le mettre à jour. C’est directement avec ce second module que les évolutions vont être prises en compte. Le premier module ayant permis de générer des ALP, un moyen est ensuite nécessaire pour permettre de déterminer l’origine de la défaillance à partir d’un ensemble d’états de tests, combiné à cet ALP.
Il s’agit alors de traduire cet ALP en équation. Ces équations correspondent à des états de tests (vrai pour les liens verts qui vont vers le bas sur la figure 6 et faux pour les liens rouges qui vont vers la droite).
En reprenant l’exemple présenté précédemment, on aurait alors ce type d’équations :
SW1 = LDT L11 ERUH9_Faux ET SW1_Faux ;
Brassage BF/DATA noir = LDT L11 ERUHF9_Faux ET SW1_Vrai ET Brassage_Faux.
Ces équations reviennent à définir des chemins menant à un groupe d’ambiguïtés (GA) donné (éléments en bout de chaine sur la figure 6). Ces chemins sont définis par des états
de tests. Des algorithmes booléens permettent ensuite de déduire les GA en fonction des états de tests.
Un GA correspond à un ensemble d’équipements (URL : Unité Remplaçable en Ligne ou URA : Unité Remplaçable en atelier) pouvant être à l’origine de la défaillance. Ce sont ces cas de pannes qui sont particulièrement traités avec cette solution car ce sont les plus complexes à résoudre.
Ce GA doit être cohérent du concept de soutien défini en phase de développement dans le cadre des analyses de Soutien Logistique Intégré et de la qualité de tests intégrés dans le modèle. Plus les tests seront nombreux, précis et adaptés, moins il y aura de GA dans l’ALP.
Le classement des équipements au sein d’un GA se base initialement sur les valeurs de MTBF (Mean Time Between Failure) intégrées dans la modélisation du premier module.
C’est-à-dire, plus le MTBF d’un équipement est élevé, plus sa probabilité d’être à l’origine de la panne (exprimée sous forme de pourcentage) est faible. Les équipements au sein d’un GA sont donc classés par ordre décroissant de ces pourcentages, (voir l’illustration ci-après).
Fig. 7. Classement au sein d’un GA
Dans l’exemple pris en Figure 7, dans le Fault Group #5, le TRN4000 a le taux de défaillance le plus élevé suivi par le modem UHF et le câble. Les valeurs de MTBF (théoriques ou issues du RETEX) des équipements sont les suivantes :
- TRN 4000 : 40000 heures ; - Modem : 150000 heures ; - Câble : 600000 heures.
Pour établir le pourcentage associé, il est alors nécessaire de passer par le taux de défaillance qui correspond à l’inverse du MTBF. Ensuite, en faisant le ratio de chacun des taux de défaillance sur le taux de défaillance global du GA on obtient alors le pourcentage associé à chaque équipement (voir Tableau II-1 ci-dessous).
Désignation Taux de
défaillance Pourcentage
TRN 4000 2,50E-05 75%
Modem 6,67E-06 20%
Câble 1,67E-06 5%
TOTAL 3,33E-05 100%
Tableau II-1 : Calcul du pourcentage
Ces pourcentages, basés sur les MTBF intégrés initialement au modèle, évolueront au fur et à mesure de l’utilisation de l’application. Rien ne vaut l’expérience du terrain pour attribuer l’origine d’une panne à un équipement plutôt qu’un autre. C’est pour cela que ce deuxième module
a été développé ; pour prendre en compte le retour d’expérience en exploitant les données statistiques (nombre de réparations) enregistrées par l’application.
A chaque fois que la solution va être utilisée pour réaliser un diagnostic, elle va mémoriser l’état de chacun des tests et si nécessaire faire évoluer le classement au sein d’un GA ou même le GA en lui-même en permettant à l’utilisateur d’ajouter un nouvel élément dans ce GA.
Reprenons l’exemple du Fault Group #5 (voir Fig. 7).
Les données de MTBF indiquent que c’est le TRN4000 qui est en première position dans le GA. Or si une opération de maintenance avec ces états de tests indique finalement que c’est le modem qui est en défaut, il semble judicieux de faire évoluer le pourcentage. L’objectif étant de se rapprocher de la réalité du terrain et de faire évoluer le classement de manière raisonnable.
La stratégie proposée est d’ajouter un coefficient représentatif de l’occurrence d’apparition des pannes pour permettre de faire évoluer le pourcentage. Un exemple est illustré dans le tableau ci-après :
Désignation Pourcentage initial
Occurrence réelle
Pourcentage évolué
TRN 4000 75% 1 67%
Modem 20% 3 27%
Câble 5% 2 6%
TOTAL 100% 6 100%
Tableau II-2: Evolution du pourcentage
Plus l’occurrence réelle est grande et plus le pourcentage va augmenter. Cependant, nous n’avons actuellement pas le recul suffisant pour juger de la pertinence du coefficient permettant d’allouer plus ou moins d’importance à l’occurrence réelle par rapport au pourcentage initial issu d’une valeur de MTBF théorique. En effet, une seule occurrence de panne du modem durant l’exploitation combinée à aucune autre panne de ce GA ne doit pas impliquer un pourcentage évolué à 100% pour le modem. Il doit être éprouvé sur différents projets et sur le long terme pour permettre de valider sa pertinence ou le modifier le cas échéant.
L’ordre des équipements au sein d’un GA n’est pas la seule évolution possible. En effet, la constitution d’un GA peut elle aussi évoluer. Même si la base de connaissances établie lors de la phase de développement du projet se veut aussi précise et réaliste que possible, il semble judicieux de pouvoir laisser l’opportunité d’intégrer des cas non prévus initialement dans l’outil. Pour cela, il est proposé à l’utilisateur d’ajouter un élément manuellement dans le GA lorsque la panne a été réparée avec un élément qui n’était pas présent dans le GA initialement. Cela permet d’avoir une solution complètement évolutive.
Ces fonctionnalités ont été développées pour permettre d’agir directement sur la disponibilité du système et permettre un diagnostic plus rapide. Mais elles n’apporteront rien aux utilisateurs si cela leur génère de la complexité supplémentaire. C’est pourquoi des experts en ingénierie des facteurs humains ont travaillé sur la solution pour proposer une interface homme-machine (IHM) simple et
ergonomique. Cette IHM correspond au prochain module présenté.
C. Troisième module : l’Interface Homme-Machine (IHM) Le fonctionnement retenu se base sur une architecture
« client/serveur » avec des requêtes entre l’IHM et le module de diagnostic. L’IHM est plutôt hébergée sur un support mobile (Tablette, Laptop, …) alors que le module de diagnostic, qui nécessite des performances intrinsèques plus importantes, sera plutôt positionné sur un serveur. L’IHM (Interface Homme Machine) permet à l’utilisateur de mener d’une façon autonome un diagnostic de panne d’un système et sa remise en service. Elle est conçue pour que l’utilisateur, souvent un maintenancier, puisse mettre en œuvre les fonctionnalités de l’outil d’aide à la maintenance de façon intuitive et efficace lors des opérations de dépannage ou de maintenance. Pour se faire, les IHM ont été réfléchies et développées en collaboration avec des spécialistes UI/UX*.Le prototype de l’application présenté ci-après est applicable à un système de communication. Les IHM sont développées de façon à reproduire la configuration géographique, matérielle et fonctionnelle du système.
L’utilisateur est guidé à travers un séquencement logique et chronologique des IHM lui permettant de mener le diagnostic et la remise en service du système. Les étapes à suivre sont listées ci-dessous :
1. L’utilisateur renseigne par sélection le service indisponible ou présentant des dysfonctionnements. Par exemple, dans le cadre de moyens de communications : Liaison de données, Phonie, Visio-conférence, etc. L’objectif de cette première étape est de déterminer le sous-système à analyser et ainsi limiter le nombre d’actions à réaliser sur la prochaine étape.
2. L’application met en surbrillance tous les équipements potentiellement impliqués ;
3. Pour chaque équipement mis en évidence par l’application, l’utilisateur sélectionne, parmi la liste prédéfinie, les alarmes et les statuts de fonctionnement observés sur l’équipement (Fig. 8). La connaissance de l’état de fonctionnement de chaque équipement impliqué est nécessaire pour réaliser un diagnostic précis. De ce fait, cette étape ne sera pas validée et franchie tant que le relevé des informations n’est pas réalisé pour tous les équipements. Les ALP présentés dans le deuxième module de l’outil nécessitent de connaitre l’état de l’ensemble des tests.
4. L’algorithme s’appuie sur les informations relevées par l’utilisateur pour réaliser le diagnostic et propose un groupe d’ambiguïté (GA) des équipements potentiels qui sont à l’origine du dysfonctionnement ou de la perte du service.
*: « UI » User Interface, « UX » User eXperience
Fig. 8. Relevé des informations
L’IHM d’affichage des résultats du diagnostic (Fig. 9) propose un GA dont elle suggère un ordre d’échange basé sur un pourcentage. Pour cela, comme indiqué dans la présentation du deuxième module dans le chapitre précédent (B), l’application s’appuie sur les données de fiabilité introduites par défaut dans l’application puis sur la capacité d’apprentissage de l’algorithme qui permet d’affiner ces pourcentages au fur et à mesure de son l’utilisation.
En parallèle, d’autres informations telles que le temps d’accessibilité et d’échange et l’historique des interventions sont proposées à l’utilisateur pour lui permettre de faire le meilleur choix parmi le groupe d’ambiguïté. Par exemple, il peut décider grâce à ces informations d’échanger en premier lieu un câble ayant une probabilité de 5% mais un temps d’échange de 5 minutes au lieu du TRN 4000 qui a la probabilité de 75% mais un temps d’échange de 2 heures.
5. Depuis cette même IHM l’utilisateur peut accéder directement à la procédure de maintenance de l’élément et procéder à l’échange.
Fig. 9. Résultats du diagnostic
6. Pour enrichir la base de capitalisation de l’outil d’aide à la maintenance, une évaluation de l’intervention est demandée à la fin de chaque échange. En outre, des suggestions d’amélioration de la procédure de maintenance peuvent être mentionnées.
Fig. 10. Prise en compte du RETEX
III. CONCLUSION
Toutes les fonctionnalités présentées dans cette communication ont d’ores et déjà pu être testées sur un sous- système de communication développé par Thales dans le domaine naval. Les modélisations dysfonctionnelles ont été réalisées afin de déterminer les Arbres Logique de Panne.
L’algorithme de diagnostic a ensuite permis d’identifier le groupe d’ambiguïtés correspondant à un état global de tests.
Et le fonctionnement client/serveur a été vérifié sur la plateforme de test du sous-système.
La solution proposée permet de prendre en compte la vie réelle du système grâce au RETEX. Le diagnostic n’est pas figé à l’issue de la conception du système mais continue à évoluer au cours du temps. Ainsi, en accélérant le temps de remise en service, la disponibilité est améliorée.
La modularité de cette solution peut permettre de l’appliquer à plus grande échelle et sur d’autres domaines (aéronautique, terrestre …). Ce passage à l’échelle doit être mis en place par la suite afin d’envisager une mise en réseau de plusieurs systèmes / sous-systèmes afin d’élargir le périmètre du RETEX et continuer à faire évoluer cet outil de d’aide à la maintenance évolutif.
Cet outil se focalise sur le besoin des opérationnels et sur la volonté de fournir un moyen d’améliorer le taux de disponibilité d’un système.
La problématique de diagnostic peut également se retrouver directement chez l’industriel qui conçoit un équipement. En effet, dans le monde de l’industrie, la mise au point d’un nouvel équipement est freinée par des défauts de jeunesse et des résultats de diagnostics immatures, sur des cycles de développement de plus en plus courts. Dans ce contexte Thales a développé DIANA (DIagnostic et ANAlyse). L’objectif de DIANA est de proposer une solution innovante de diagnostic pour confronter valeurs théoriques et opérationnelles, pour apporter une valeur ajoutée en maintenance et pour accélérer la maturité des équipements par des retours d’expérience. Une présentation de cet outil est proposée dans une autre communication du Lambda-mu 22 intitulée « Exploitation et analyse des journaux d’évènements des équipements » [1].
REFERENCES
[1] F. Borgat, E. Amil, and F. Raux, “Exploitation et analyse des journaux d’évènements des équipements,” Lambda-Mu 22, October 2020
