Tableau de bord/Chapter 6/1.2 — Condition Monitoring
Chapter 6 · leçon 2 sur 7
CertaviaCondition Monitoring (Application) — Application Maximo permettant de définir des points de mesure, des seuils, et des actions automatiques basées sur l'état des actifs.Meters et Meter Readings — Les compteurs sont utilisés pour suivre l'utilisation ou l'état d'un actif, et leurs relevés sont des données de condition essentielles.KPI Manager, utilisant des requêtes SQL pour surveiller des métriques clés avec des seuils d'alerte.Start Center — Tableau de bord personnalisable où les KPI et les requêtes publiques peuvent être affichés pour une vue d'ensemble rapide de la santé des actifs.Maximo Application Suite (MAS) spécialisé dans la surveillance à l'échelle de l'entreprise avec détection d'anomalies basée sur l'IA et tableaux de bord configurables.La surveillance de condition dans Maximo s'appuie sur une architecture robuste qui intègre la collecte de données, l'analyse et la déclenchement d'actions de maintenance. Au cœur de cette architecture se trouve la capacité de Maximo à ingérer des données provenant de diverses sources, qu'elles soient manuelles ou automatisées, pour évaluer l'état de santé des actifs.
Cette approche permet une transition de la maintenance préventive basée sur le temps vers une maintenance prédictive et basée sur la condition, optimisant ainsi les opérations et réduisant les temps d'arrêt imprévus. L'intégration avec des systèmes externes comme les SCADA ou les capteurs IoT est fondamentale pour une surveillance en temps quasi réel.
Bien que Maximo Manage offre des capacités robustes de surveillance de condition, la Maximo Application Suite (MAS) introduit Maximo Monitor, une solution plus avancée pour la détection d'anomalies à l'échelle de l'entreprise. Comprendre leurs différences est crucial pour choisir la bonne approche de surveillance.
| Caractéristique | Maximo Manage (Classique) | Maximo Monitor (MAS) |
|---|---|---|
| Objectif Principal | Gestion des actifs, maintenance réactive/préventive, CBM de base. | Surveillance à l'échelle de l'entreprise, détection d'anomalies IA, maintenance prédictive. |
| Collecte de Données | Manuelle (Meter Readings), intégration limitée de capteurs via interfaces. | Intégration rapide et massive de données de capteurs IoT, SCADA, systèmes externes. |
| Analyse des Données | Seuils définis manuellement, KPI basés sur SQL, rapports ad-hoc. | Détection d'anomalies basée sur l'IA, apprentissage automatique, analyse de données en temps quasi réel. |
| Visualisation | Start Center avec portlets KPI, rapports standards. | Tableaux de bord configurables sans code (No-Code Widgets), vue d'ensemble de l'opération à l'échelle de l'entreprise. |
| Génération d'OT | Automatique via Condition Monitoring ou Escalations basées sur des seuils. | Génération automatique d'ordres de travail en réponse aux anomalies détectées, intégration fluide avec Manage. |
| Évolutivité | Adapté pour des besoins CBM spécifiques et gérables. | Conçu pour une surveillance massive de milliers d'actifs et de flux de données. |
| Complexité | Configuration des compteurs et points de mesure, règles simples. | Gestion de grands volumes de données, modèles d'IA, intégration de multiples sources. |
La mise en œuvre d'une stratégie de surveillance de condition dans Maximo Manage implique plusieurs étapes clés, de la définition des points de mesure à la configuration des actions automatiques. L'objectif est de transformer les données brutes en informations exploitables qui déclenchent des interventions de maintenance au moment opportun.
L'application Condition Monitoring est le pivot de cette fonctionnalité. Elle permet de lier des points de mesure à des actifs ou des emplacements, de définir des seuils d'alerte et de spécifier les actions à entreprendre lorsque ces seuils sont dépassés. Par exemple, un actif critique comme une pompe peut avoir un point de mesure pour la vibration, avec un seuil d'alerte élevé qui génère automatiquement un ordre de travail pour inspection.
Meters — Dans l'application Meters, créez des compteurs pour suivre des paramètres spécifiques (ex: température, pression, vibrations, heures de fonctionnement). Associez-les à des actifs ou des types d'actifs.Assets ou Locations, ajoutez des points de mesure (MEASUREMENT) aux actifs ou emplacements. Liez-les aux Meters définis.Condition Monitoring — Dans l'application Condition Monitoring, sélectionnez un actif ou un emplacement et un point de mesure. Définissez des seuils de lecture (ex: seuil d'avertissement, seuil d'action).WORKORDER), envoyer une notification (COMMUNICATION), ou modifier le statut de l'actif (ASSETSTATUS).Meter Readings — Les relevés de compteurs peuvent être saisis manuellement via l'application Meter Readings, ou importés automatiquement depuis des systèmes externes (SCADA, IoT) via des intégrations.KPI Manager pour créer des indicateurs qui surveillent l'état des actifs en fonction des relevés de compteurs et des seuils. Affichez ces KPI sur le Start Center pour une visibilité en temps réel.Un exemple concret pourrait être la surveillance de la température d'un moteur de production. Un Meter "Température Moteur" est créé et associé à l'actif "Moteur Principal 01". Dans Condition Monitoring, un seuil d'avertissement est fixé à 80°C et un seuil critique à 90°C. Si la température dépasse 80°C, une notification est envoyée au chef d'équipe. Si elle atteint 90°C, un ordre de travail de priorité élevée est automatiquement généré pour une inspection immédiate, avec un JOBPLAN pré-défini pour le diagnostic.
Le workflow de la maintenance basée sur la condition (CBM) est un processus dynamique qui commence par la collecte continue de données et culmine avec des actions de maintenance ciblées. Il vise à anticiper les défaillances et à optimiser les interventions, réduisant ainsi les coûts et les temps d'arrêt.
Ce cycle de vie implique une surveillance constante des indicateurs de performance des actifs, l'analyse des tendances, et la prise de décision éclairée. L'automatisation joue un rôle crucial pour garantir que les alertes sont traitées rapidement et que les ordres de travail sont générés sans délai.
Meters et Condition Monitoring
Les candidats peuvent confondre le rôle des Meters et de l'application Condition Monitoring. Les Meters (compteurs) sont des entités qui suivent une valeur numérique ou alphanumérique (ex: heures de fonctionnement, température). L'application Condition Monitoring utilise les relevés de ces Meters pour évaluer l'état de l'actif par rapport à des seuils définis et déclencher des actions. Un Meter seul ne déclenche pas d'action sans être configuré dans Condition Monitoring ou via une Escalation.
Une erreur courante est de penser que la surveillance de condition se limite à la saisie manuelle des relevés. En réalité, pour une CBM efficace, l'intégration de données provenant de systèmes SCADA, de capteurs IoT ou d'autres systèmes de contrôle est cruciale. Maximo est conçu pour ingérer ces données automatiquement, notamment via Maximo Monitor, pour une analyse en temps quasi réel et une détection proactive des anomalies. Ne pas considérer cette intégration limite fortement le potentiel de la CBM.
Start Center
Les KPI et le Start Center sont souvent vus comme de simples outils de reporting. Cependant, ils sont des composants essentiels de la surveillance de condition. Un KPI bien configuré peut alerter visuellement les utilisateurs sur des dégradations de condition sans qu'ils aient à naviguer dans plusieurs applications. Le Start Center offre une vue consolidée et personnalisable de la santé des actifs, permettant une prise de décision rapide. Ignorer leur potentiel de visualisation et d'alerte est un piège.
Condition Monitoring dans Maximo ?
L'application Condition Monitoring permet de définir des points de mesure pour les actifs ou les emplacements, de spécifier des seuils d'alerte pour ces points, et de configurer des actions automatiques (comme la génération d'un WORKORDER ou l'envoi d'une COMMUNICATION) lorsque ces seuils sont dépassés, facilitant ainsi la maintenance basée sur la condition.
Maximo Monitor améliore-t-il les capacités de surveillance de condition par rapport à Maximo Manage classique ?
Maximo Monitor, partie de la Maximo Application Suite, offre une surveillance à l'échelle de l'entreprise avec détection d'anomalies basée sur l'IA, des tableaux de bord configurables sans code, et une intégration rapide de données de capteurs IoT et SCADA. Il permet une analyse en temps quasi réel et une génération automatique d'ordres de travail plus sophistiquée que les fonctionnalités de base de Maximo Manage.
La CBM permet de réduire les temps d'arrêt imprévus, d'optimiser les calendriers de maintenance en intervenant uniquement lorsque nécessaire, de prolonger la durée de vie des actifs, de diminuer les coûts de maintenance en évitant les réparations coûteuses dues à des défaillances inattendues, et d'améliorer la sécurité opérationnelle.
Les KPI, définis via l'application KPI Manager, peuvent être configurés pour surveiller des métriques clés liées à la condition des actifs (ex: nombre d'alertes de température, moyenne des vibrations). Ils utilisent des requêtes SQL pour extraire des données et peuvent afficher des seuils d'alerte (vert/jaune/rouge) sur le Start Center, offrant une visibilité immédiate sur la santé des actifs.
Bonne réponse : A
Pourquoi cette question existe — STU §6.2 — la question vérifie la connaissance du mécanisme batch (Cron Task) qui scrute périodiquement les points de mesure pour générer des work orders lors d'un dépassement de limite, par opposition à des causes plausibles mais inopérantes (workflow, sécurité, templates). En pratique, un Cron Task inactif est la cause la plus fréquente de WO manquants malgré des limites correctement configurées.
Le contexte théorique d'abord — Le Measure Point Wogen Cron Task est la tâche planifiée qui évalue périodiquement les lectures de points de mesure (Condition Monitoring) par rapport aux action limits (haute/basse) et déclenche la génération automatique d'un work order en cas de dépassement. S'il est inactif, aucune évaluation n'a lieu, même si les limites sont correctement définies.
Ce que Maximo en fait — version opérationnelle — Dans System Configuration > Platform Configuration > Cron Task Setup > rechercher la cron task de type MEASUREPOINTWOGENCRON > vérifier que l'instance est Active > en cas d'inactivité, l'activer pour reprendre l'évaluation périodique des points de mesure.
Exemple chiffré — Sur 40 points de mesure configurés avec limites hautes/basses, un Cron Task inactif pendant 5 jours peut faire manquer 0 work order généré sur cette période, alors que jusqu'à 6 dépassements auraient dû déclencher autant de WO.
Analogie quotidienne — C'est comme un détecteur de fumée dont la pile est retirée : le seuil de déclenchement (la fumée) est bien dépassé, mais l'alarme (le WO) ne se déclenche jamais car le mécanisme de surveillance lui-même est à l'arrêt.
Pourquoi B est faux — Pattern D5 champ-frère : un workflow inactif empêcherait l'approbation/routage d'un WO déjà créé, pas sa génération initiale par dépassement de limite.
Pourquoi C est faux — Pattern D5 champ-frère : un défaut de sécurité bloquerait l'accès utilisateur à l'application, pas le déclenchement automatique batch du Cron Task.
Pourquoi D est faux — Pattern D5 champ-frère : les Communication Templates pilotent les notifications, pas la génération du work order lui-même.
Bonne réponse : A
Pourquoi cette question existe — STU §6.2 — la question vérifie que l'élément déclencheur direct dans Condition Monitoring est l'enregistrement de Measurement sur un point de mesure, et non d'autres données numériques de l'asset (compteurs de marche, downtime, score de santé) qui suivent leur propre logique. En pratique, confondre ces sources fait chercher le déclencheur au mauvais endroit lors d'un diagnostic.
Le contexte théorique d'abord — Une Measurement (mesure) enregistrée sur un point de mesure de Condition Monitoring est comparée aux action limits définies sur ce point. Lorsque la valeur mesurée dépasse la limite haute ou basse, le Cron Task associé déclenche la création automatique d'un work order.
Ce que Maximo en fait — version opérationnelle — Dans Condition Monitoring > saisir ou recevoir (via IoT/SCADA) une nouvelle Measurement sur un point > le Cron Task évalue cette mesure contre les limites > si dépassement, un WO est généré et lié au point de mesure et à l'asset concerné.
Exemple chiffré — Sur un point de mesure de vibration avec limite haute à 8 mm/s, une mesure enregistrée à 9,2 mm/s sur 1 seul équipement déclenche 1 work order, alors que 3 mesures précédentes restées sous 8 mm/s n'en avaient généré aucun.
Analogie quotidienne — C'est comme un thermostat qui ne réagit qu'à une nouvelle lecture de température : ce n'est pas l'historique des relevés ni l'état général de la pièce qui déclenche le chauffage, mais bien la mesure instantanée comparée au seuil.
Pourquoi B est faux — Pattern D9 quasi-synonyme : les relevés de compteur horaire alimentent les PM basées sur l'usage, pas directement le mécanisme de Condition Monitoring.
Pourquoi C est faux — Pattern D5 champ-frère : l'Asset Downtime enregistre des périodes d'arrêt, sans lien avec le déclenchement par mesure de Condition Monitoring.
Pourquoi D est faux — Pattern D5 champ-frère : l'Asset Health Score est un indicateur agrégé de fiabilité, distinct du mécanisme de mesure ponctuelle déclenchant un WO.