Apprentissage automatique vs détection d'anomalies basée sur des règles : deux approches pour le même problème, des compromis différents

Principaux enseignements

• Détection d'anomalies basée sur des règles = seuils et règles de motifs écrits par les ingénieurs.
• Détection d'anomalies par ML = modèles apprenant les schémas normaux et signalant les écarts.
• Les règles détectent des modes de défaillance connus ; le ML détecte ce qui n'a pas été spécifié.
• Les règles sont auditables et faciles à expliquer ; le ML peut surpasser sur des signaux multivariés complexes.
• La plupart des usines bénéficient des deux : des règles pour les schémas connus, du ML pour le reste.

En bref: La détection d'anomalies basée sur des règles utilise des seuils et des motifs conçus pour signaler des modes de défaillance connus. La détection d'anomalies par ML apprend les schémas normaux à partir des données et signale des écarts que les ingénieurs n'ont pas spécifiés.

Les règles sont auditables et faciles à expliquer; le ML surpasse souvent sur des signaux multivariés complexes. La plupart des usines bénéficient des deux, des règles pour le connu, du ML pour l'inconnu. Voir aussi Utilisation machine vs chargement .

Ce que la méthode basée sur des règles fait bien

• Auditable. Chaque alerte est traçable à une règle spécifique.
• Explicable. Les opérateurs comprennent ce qui a déclenché l'alerte.
• Faible besoin en données. Fonctionne dès le premier jour.
• Ajustable. Les ingénieurs peuvent modifier les seuils.

Ce que la méthode basée sur des règles manque

• Des modes de défaillance que personne n'avait anticipés.
• Des schémas multivariés s'étendant sur de nombreux capteurs.
• Des dérives subtiles à l'intérieur des seuils individuels.
• Des changements corrélés sur plusieurs signaux.

Ce que le ML fait bien

• Détecte des schémas non anticipés.
• Analyse multivariée.
• S'adapte aux régimes de fonctionnement.
• S'améliore avec davantage de données.

Ce avec quoi le ML a du mal

• Explicabilité. « Pourquoi l'alerte ? » est plus difficile à expliquer.
• Besoins en données. Nécessite des mois à des années d'historique.
• Dérive. Un réentraînement du modèle est nécessaire.
• Taux de faux positifs. Le réglage est critique.

Quand les règles l'emportent

• Modes de défaillance bien connus.
• Environnements réglementés nécessitant une auditabilité.
• Nouveaux déploiements sans historique de données.
• Normes basées sur des seuils (ISO 10816 vibrations).

Quand le ML l'emporte

• Processus multivariés complexes.
• Usines disposant d'un riche historique de données.
• Modes de défaillance que les ingénieurs ne peuvent pas entièrement spécifier.
• Opérations où les détections manquées sont très coûteuses.

Le modèle hybride

La plupart des usines matures utilisent les deux :

• Les règles couvrent les modes de défaillance connus avec une grande confiance.
• Le ML détecte l'inconnu.
• Les désaccords entre les deux déclenchent une enquête.
• Les alertes ML confirmées par une vérification basée sur les règles deviennent souvent de nouvelles règles.

La combinaison surpasse chacune des approches prises isolément.

Erreurs courantes

1. ML sans historique. Les modèles entraînés sur des données insuffisantes échouent.

2. Règles sans couverture. Les ingénieurs ne spécifient pas tous les modes de défaillance.

3. Remplacer les règles par le ML. Perte d'auditabilité.

4. Pas de réglage. Un taux de faux positifs élevé compromet les deux approches s'il n'est pas maîtrisé.

Le problème de l'auditabilité

Le ML dans les environnements réglementés exige de l'explicabilité. Approches :

• Utiliser des modèles interprétables (arbres de décision, modèles linéaires généralisés).
• Utiliser le deep learning avec mécanismes d'attention ou visualisation de l'importance des caractéristiques.
• Utiliser le ML pour signaler des candidats, puis une vérification basée sur des règles avant toute action.
• Documenter les données d'entraînement et la validation du modèle.

L'acceptation réglementaire du ML augmente mais n'est pas universelle.

Le problème de la dérive

Les processus changent, les équipements vieillissent, les recettes évoluent. Les modèles entraînés sur l'ancien état normal se comportent différemment face au nouvel état normal.

Atténuation :

• Réentraînement périodique.
• Détection de la dérive.
• Fenêtre glissante ou apprentissage en ligne.

Erreurs courantes

1. Alertes ML que personne n'examine. Comme pour tout système de détection, les alertes doivent donner lieu à une action.

2. Absence de référence pour interpréter la précision du modèle. Sans comparaison, la performance du modèle est opaque.

3. Traiter le ML comme une solution plug-and-play. Les modèles nécessitent de l'ingénierie des données, de la validation et de la surveillance.

Intégration avec la GMAO

Les alertes issues des règles et du ML devraient générer automatiquement des bons de travail (WO) dans la GMAO. Les niveaux de confiance peuvent déterminer la priorité (confiance élevée → bon de travail immédiat ; confiance plus faible → file d'investigation).

Lien avec l'OEE

Les deux approches alimentent la surveillance d'état qui influence l'OEE. Les problèmes détectés deviennent de la maintenance planifiée ; les problèmes non détectés entraînent des arrêts non planifiés.

Les usines comparant la disponibilité OEE avant et après la mise en place d'un programme mature de détection d'anomalies observent généralement une amélioration de la disponibilité.

Comment une plateforme OEE moderne prend en charge les deux

Une plateforme OEE moderne prend en charge des seuils basés sur des règles pour les schémas connus et la détection d'anomalies par ML pour les schémas non anticipés, les deux alimentant le flux de travail de la GMAO.

Le module OEE de Fabrico prend en charge à la fois la détection d'anomalies basée sur des règles et celle par ML, les deux alimentant le flux de travail de la GMAO pour enquête et action.

Découvrez comment Fabrico capture cela automatiquement, découvrez l'OEE pour la fabrication ou réservez une démo.

Lectures associées

• Utilisation machine vs chargement
• Constructeurs de machines vs intégrateurs de systèmes

Questions fréquentes

Dois-je toujours utiliser le ML ?

Non. Les règles fonctionnent bien pour les schémas connus ; le ML apporte de la valeur pour ce qui n'est pas anticipé.

De combien de données le ML a-t-il besoin ?

Très variable. Règle courante : suffisamment pour couvrir la variation normale de fonctionnement (saisonnalité, mix, etc.).

La méthode basée sur des règles est-elle trop simple ?

Non. Les règles gèrent bien la plupart des modes de défaillance connus. Le ML s'occupe du résiduel.

Comment éviter les faux positifs ?

Ajuster les seuils de confiance ; exiger plusieurs signaux ; apprendre des retours des opérateurs.

Le ML peut-il prédire des modes de défaillance spécifiques ?

Si entraîné sur des données de défaillance étiquetées, oui. Sans étiquettes, il détecte seulement une anomalie sans en préciser le type.