IOT et industrie : Relever les défis de la préparation des données pour la maintenance prédictive

Points clés à retenir

L'apprentissage automatique (ML) joue un rôle important dans le domaine de l'IoT industriel (IIoT) pour la gestion des données et l'analyse prédictive.
Les applications de maintenance prédictive (PdM) visent à appliquer le ML sur les ensembles de données IIoT afin de réduire les risques professionnels, les temps d'arrêt des machines et autres coûts.
Découvrez les défis de préparation des données auxquels sont confrontés les praticiens industriels du ML et les solutions d'ingestion de données et d'ingénierie des fonctionnalités liées au PdM.
Les processus d'ingestion de données peuvent être plus faciles à développer et à gérer à l'aide d'un outil de gestion de flux de données tel que StreamSets ou Apache Nifi.
Les algorithmes de mémoire à court terme (LSTM) sont couramment utilisés pour prévoir les événements rares dans les données de séries chronologiques. Les défaillances étant généralement très rares dans les applications PdM, les algorithmes LSTM conviennent à la modélisation.

L'apprentissage automatique (ML) a permis aux technologues de faire des choses incroyables avec les données. Son arrivée coïncide avec l'évolution des systèmes de fabrication en réseau pilotés par l'IoT, également connu sous le nom d'IoT industriel (IIoT), qui a conduit à une croissance exponentielle des données disponibles pour la modélisation statistique.

Les applications de maintenance prédictive (PdM) visent à appliquer le ML sur les ensembles de données IIoT afin de réduire les risques professionnels, les temps d'arrêt des machines et autres coûts en détectant lorsque les machines présentent des caractéristiques associées aux défaillances passées. Ce faisant, PdM fournit aux opérateurs d'usine des informations qui peuvent les aider à effectuer des actions préventives ou correctives, telles que:

faire fonctionner les machines à une vitesse ou à une pression plus faibles pour retarder la panne totale,
faire apporter du matériel de rechange sur place, et
planifier l'entretien à des moments opportuns.

L'implémentation de PdM implique un processus qui commence par la préparation des données et se termine par le ML appliqué. Les praticiens savent bien que la majeure partie de l'effort requis pour une LM efficace porte sur la préparation des données, et pourtant, ces défis continuent d'être sous-représentés dans la littérature sur la ML, où les auteurs ont tendance à démontrer des concepts avec des ensembles de données artificiels.

Dans cet article, j'espère aborder certains des défis de préparation des données les plus difficiles rencontrés par les praticiens industriels du ML en discutant des solutions pour l'ingestion de données et l'ingénierie des fonctionnalités liées à PdM.

Ingestion de données

La première étape requise pour PdM implique l'acquisition de données. L'instrumentation industrielle est le plus souvent associée à des mesures de quantités physiques telles que les vibrations, la chaleur infrarouge, le courant électrique, les particules métalliques dans la graisse, etc. Ces données proviennent généralement de capteurs connectés à des contrôleurs logiques programmables au sein d'un réseau de contrôle industriel. Les passerelles de données qui relient le contrôle et les réseaux d'entreprise facilitent l'accès à ces données via des protocoles conviviaux pour les développeurs, tels que REST et MQTT. Il est également important de prendre en compte les sources de données hors bande, telles que les journaux des opérateurs ou les données météorologiques, car elles peuvent également contenir des signaux en corrélation avec les événements de défaillance. La figure 1 ci-dessous illustre les interconnexions entre ces types de ressources de données.

Figure 1. Interconnexions entre les ressources de données IIoT

Conception du pipeline de données

L'ingestion de données est réalisée par des processus qui collectent et stockent en continu des données. Ces processus peuvent être implémentés en tant qu'applications personnalisées mais sont généralement beaucoup plus faciles à développer et à gérer à l'aide d'un outil de gestion de flux de données, tel que StreamSets ou Apache Nifi. Ces outils offrent un certain nombre d'avantages pour la création et la gestion de pipelines de données, tels que:

Simplification du développement et du déploiement de pipelines. Les environnements de développement intégrés (IDE) tels que ceux fournis par StreamSets et Nifi aident à minimiser le code requis pour créer des pipelines. Ils intègrent également des utilitaires utiles pour la surveillance et le débogage du flux de données. En outre, ces outils prennent en charge les processus DevOps avec des fonctionnalités telles que la gestion des versions de flux et la livraison continue.

Prévention des défaillances dues à la migration d'échelle, de dérive de schéma et de topologie. Les outils de gestion des flux de données peuvent agir comme un agent important de changement au sein d'un système distribué. Ils offrent des moyens raisonnables de mise à l'échelle pour gérer une charge accrue. Par exemple, StreamSets exploite Kubernetes pour une évolutivité élastique et Nifi devrait faire de même dans un avenir proche. Les sources de données peuvent également introduire des changements de rupture lors de l'évolution des schémas de base. StreamSets et Nifi vous permettent de gérer la dérive du schéma avec des étapes de validation des données qui redirigent ou reformatent les messages à la volée. Les topologies d'infrastructure peuvent également changer au cours de la vie d'une application. StreamSets et Nifi vous permettent de définir des flux de données agnostiques de topologie qui peuvent s'exécuter à travers une infrastructure de périphérie, sur site, cloud et hybride-cloud sans sacrifier la résilience ou la confidentialité des données.

Pour vous donner une idée de ce que font les outils de gestion des flux de données, j'ai préparé un projet StreamSets simple que vous pouvez exécuter sur un ordinateur portable avec Docker. Ce projet démontre un pipeline qui diffuse des données de séries chronologiques enregistrées à partir d'un système de chauffage, de ventilation et de climatisation (HVAC) industriel vers OpenTSDB pour la visualisation à Grafana.

Créez un réseau docker pour relier les conteneurs:
réseau docker créer mynetwork

Démarrez StreamSets, OpenTSDB et Grafana:
docker run -it -p 18630: 18630 ​​-d –name sdc –network mynetwork
streamsets / datacollector
docker run -dp 4242: 4242 –name hbase –network mynetwork
petergrace / opentsdb-docker
docker run -d -p 3000: 3000 –name grafana –network mynetwork
grafana / grafana

Ouvrez Grafana sur http: // localhost: 3000 et connectez-vous avec admin / admin

Ajoutez http: // hbase: 4242 en tant que source de données OpenTSDB à Grafana. Si vous ne savez pas comment ajouter une source de données, reportez-vous à la documentation Grafana. Votre définition de source de données doit ressembler à la capture d'écran illustrée à la figure 2 ci-dessous.

Figure 2. Définition de la source de données OpenTSDB dans Grafana

Téléchargez ce fichier de tableau de bord Grafana.

Importez ce fichier dans Grafana. Si vous ne savez pas comment importer un tableau de bord, consultez la documentation de Grafana. Votre boîte de dialogue d'importation devrait ressembler à une capture d'écran ci-dessous.

Figure 3. Boîte de dialogue d'importation de tableau de bord dans Grafana

Téléchargez, décompressez et copiez ces données HVAC dans le conteneur StreamSets:
décompressez mqtt.json.gz
docker cp mqtt.json sdc: /tmp/mqtt.json

Ouvrez StreamSets sur http: // localhost: 18630 ​​et connectez-vous avec admin / admin

Téléchargez et importez le pipeline suivant dans StreamSets. Si vous ne savez pas comment importer un pipeline, reportez-vous à la documentation StreamSets.

Vous verrez un avertissement concernant une bibliothèque manquante à l'étape «Parse MQTT JSON». Cliquez sur cette étape et suivez les instructions pour installer la bibliothèque Jython.

Figure 4. L'avertissement présenté ici indique qu'une bibliothèque manquante doit être installée.

Exécutez le pipeline StreamSets. Après quelques minutes, le tableau de bord StreamSets devrait ressembler à la capture d'écran de la figure 5 ci-dessous.

Figure 5. Tableau de bord de flux de données StreamSets

Après avoir laissé le pipeline fonctionner pendant plusieurs minutes, le tableau de bord Grafana devrait ressembler à la capture d'écran, comme illustré à la figure 6.

Figure 6. Tableau de bord Grafana avec exécution du pipeline de données

Nous espérons qu'en configurant ce pipeline et en explorant StreamSets, vous obtiendrez l'essentiel de ce que les outils de gestion de flux de données peuvent faire.

Destinations de pipeline – Fichier, table ou flux?

Les pipelines de données ont un début et une fin (c'est-à-dire une source et un puits). Comme mentionné précédemment, les API MQTT et REST sont couramment utilisées pour lire les données, mais où les pipelines se terminent varie considérablement, selon le cas d'utilisation. Par exemple, si vous souhaitez simplement archiver des données pour la conformité réglementaire, vous pouvez terminer les pipelines vers un fichier car les fichiers sont faciles à créer et à compresser afin de minimiser les coûts de stockage. Si votre objectif est de développer des tableaux de bord et des alertes dans un outil de surveillance comme Grafana pour les métriques clés d'une chaîne de montage, vous pouvez envoyer des pipelines vers une base de données chronologiques comme OpenTSDB. Dans le cas de PdM, il existe d'autres exigences qui entrent en jeu lors de la détermination de la persistance des données. Examinons les avantages relatifs des fichiers, des tables et des flux pour déterminer la meilleure façon de concevoir des pipelines de données pour PdM:

Fichiers: les fichiers peuvent être utilisés pour lire et écrire efficacement des données. Ils peuvent également être facilement compressés et déplacés s'ils ne sont pas trop grands. Cependant, des problèmes surviennent lorsque les fichiers deviennent volumineux (pensez gigaoctets) ou qu'ils deviennent si nombreux (pensez milliers) qu'ils deviennent difficiles à gérer. En plus d'être difficile à déplacer, la recherche et la mise à jour des données dans des fichiers volumineux peuvent être extrêmement lentes car leur contenu n'est pas indexé. De plus, bien que les fichiers offrent une flexibilité maximale pour enregistrer les données dans n'importe quel format, ils ne disposent d'aucune fonction intégrée pour la validation du schéma. Donc, si vous négligez de valider et de supprimer les enregistrements corrompus avant qu'ils ne soient enregistrés, vous serez alors obligé de vous attaquer à la tâche difficile du nettoyage des données plus tard.

Flux: Comme Apache Kafka, les flux ont été conçus pour distribuer des données à n'importe quel nombre de consommateurs via une interface de publication / abonnement. Ceci est utile lors de l'exécution de plusieurs processeurs de données (tels que les travaux d'inférence ML), afin qu'ils n'aient pas tous à se connecter à des sources de données brutes, ce qui serait redondant et ne serait pas évolutif. Comme les fichiers, les flux peuvent ingérer des données très rapidement. Contrairement aux fichiers, les flux permettent de valider les données entrantes par rapport aux schémas (par exemple, en utilisant des classes de cas avec Apache Spark – que je montrerai plus tard). L'inconvénient de terminer des pipelines en flux est qu'ils sont immuables. Une fois que les données sont dans un flux, elles ne peuvent pas être modifiées. La seule façon de mettre à jour des données dans un flux est de les copier dans un nouveau flux. L'immuabilité dans les données d'apprentissage n'est pas souhaitable pour PdM car elle empêche les fonctionnalités, telles que la durée de vie utile restante (RUL), d'être mises à jour rétroactivement après que des événements importants, tels que des pannes de machine, se soient produits.

Tables de base de données: validation du schéma? Oui. Peut être mis à jour? Oui. Indexable? Oui! Les index de table sont particulièrement utiles si la base de données fournit des index secondaires car ils peuvent accélérer les requêtes qui interrogent plusieurs variables. J'ai mentionné les avantages des interfaces pub / sub pour les flux; les bases de données peuvent-elles également les proposer? La réponse est, encore une fois, oui, en supposant que la base de données fournit des flux de capture de données modifiées (CDC). Le seul inconvénient des bases de données est que les données ne peuvent pas être écrites aussi rapidement qu'elles le peuvent avec des fichiers ou des flux. Cependant, il existe de nombreuses façons d'accélérer les écritures. Une façon consiste à terminer un pipeline sur un flux. Les flux peuvent avoir deux objectifs dans ce cas. Premièrement, ils peuvent mettre en mémoire tampon des rafales à grande vitesse et deuxièmement, ils peuvent distribuer des pipelines à grande vitesse à plusieurs consommateurs, qui peuvent évoluer pour atteindre collectivement le débit d'écriture nécessaire dans une base de données. Cela est particulièrement efficace lorsque les flux et les bases de données s'exécutent sur la même plate-forme de données sous-jacente, comme c'est le cas avec MapR. Il convient également de noter que MapR-DB fournit des index secondaires et des flux CDC.

MapR comme plate-forme de données pour PdM

IIoT nécessite une plateforme de données évolutive en termes de vitesse et de capacité. De plus, le développement de modèles nécessite que les ingénieurs ML puissent rapidement itérer sur les concepts. MapR accomplit cela en faisant converger les flux, les bases de données et le stockage de fichiers sur une plate-forme de données hautes performances qui évolue de manière linéaire et fournit des fonctionnalités qui permettent aux scientifiques des données d'explorer les données, de développer des modèles et de les rendre opérationnels sans friction.

Ingénierie des fonctionnalités

Le potentiel de ML réside dans sa capacité à trouver des modèles généralisables dans les données. Alors que les statistiques traditionnelles utilisent souvent des techniques de réduction des données pour consolider les échantillons de données, ML prospère sur des ensembles de données épais de fidélité (pensez lignes) et de dimensionnalité (pensez colonnes). Pour vous donner une idée de la quantité de données que les modèles d'inférence PdM doivent digérer, considérez ceci:

Les processus de fabrication peuvent être instrumentés par des appareils qui mesurent des centaines de mesures à des vitesses qui dépassent parfois des milliers d'échantillons par seconde (par exemple, des capteurs de vibrations).
Les échecs sont généralement peu fréquents (par exemple, une fois par mois).
ML ne peut prédire que les événements qui peuvent être généralisés à partir des données d'entraînement. Si les événements sont rares, la collecte de données doit être beaucoup plus longue. Une bonne règle de base consiste à former des modèles avec des ensembles de données qui s'étendent sur plusieurs centaines d'événements.

Donc, étant donné la nature des données IIoT pour être épaisse avec fidélité et dimensionnalité, et étant donné que PdM dépend de voir des centaines d'exemples de défaillances peu fréquentes, la plate-forme de données utilisée pour stocker les données de formation doit évoluer non seulement en termes de vitesse d'acquisition et de stockage extensible , mais aussi en termes d'opérations utilisées pour trouver et dériver des caractéristiques pertinentes dans les données d'entraînement. Ce processus, connu sous le nom d'ingénierie des fonctionnalités, est essentiel au succès de ML, car c'est le moment où les connaissances spécifiques au domaine entrent en jeu.

Création de fonctionnalités

L'ingénierie des fonctionnalités implique souvent l'ajout de nouvelles colonnes aux données de formation pour faciliter l'analyse manuelle ou automatisée. Ces fonctionnalités peuvent aider les gens à explorer les données avec des outils analytiques et sont souvent essentielles pour que les algorithmes ML détectent les modèles souhaitables. La création de fonctionnalités peut se produire soit en augmentant les données brutes pendant l'ingestion, soit en mettant à jour les données d'entraînement rétroactivement. Pour voir comment cela fonctionne, regardons un exemple.

Un simple ensemble de données IIoT pour un processus de fabrication est représenté ci-dessous:

Figure 7. Ensemble de données du capteur IIoT

Les horodatages, l'ID d'appareil et les trois mesures nommées x, y et z représentent les mesures de performances du réseau de contrôle. Lorsque nous développons le tableau pour inclure les journaux des opérateurs et d'autres sources de données hors bande, cela ressemble à ceci:

Figure 8. Ensemble de données IIoT avec opérateur et détails météorologiques

Que doit-il se passer pour ajouter les colonnes opérateur et météo dans ce tableau? Parlons-en une seconde.

Les sources de données dans les réseaux de contrôle et d'entreprise ne sont généralement pas synchronisées. Ainsi, les horodatages des journaux de l'opérateur et de la météo seront différents des horodatages des données IIoT. L'unification de ces horodatages préserve un niveau de densité qui est avantageux pour poser des questions, comme «montrez-moi toutes les valeurs IoT pour les machines exploitées par Joe». Ce type d'intégration de données est bien adapté pour un travail par lots de nuit, car la mise à jour des enregistrements IIoT peut prendre un certain temps. Il est également plus pratique de payer la pénalité de l'intégration des données une seule fois (par exemple, tous les soirs) que de répéter cette tâche chaque fois que quelqu'un souhaite accéder à l'IoT et consigner les champs ensemble sur une requête temporelle. Ainsi, en examinant le tableau ci-dessus, reconnaissez qu'en arrière-plan, un travail Spark ou une autre tâche d'intégration de données doit avoir joint les journaux d'opérateur / météo aux journaux IIoT et les unifier par horodatage.

Il existe de nombreuses façons de mettre en œuvre cette tâche, mais lorsque ces journaux vivent dans différents silos de données, leur combinaison dans une table de fonctionnalités unifiée sera lente. C’est pourquoi il est important que les pipelines de données transfèrent les données vers une plate-forme où l’intégration des données peut fonctionner avec un mouvement de données minimal.

Extraction de caractéristiques

L'extraction d'entités implique la combinaison de variables pour produire des champs plus utiles. Par exemple, il peut être utile de diviser un champ de date et d'heure en ses composants, afin que vous puissiez facilement sous-définir les données d'entraînement par heures du jour, jours de la semaine, phases de la lune (qui sait, non?), etc. Ce type d'extraction de fonctionnalités est facile à implémenter dans un travail par lots ou un travail de streaming car ils peuvent être implémentés dans des langages tels que Java, Python et Scala, qui incluent des bibliothèques conçues pour faciliter la manipulation de la date et de l'heure. L'implémentation d'une fonction SQL pour déterminer si une valeur de date / heure tombe un week-end est beaucoup plus difficile. L'ajout d'un _weekendattribute tout en augmentant une table de fonctionnalités dans des tâches de streaming ou de traitement par lots pourrait faciliter l'analyse manuelle et aider les algorithmes ML à généraliser les modèles au cours de la semaine de travail.

Caractéristiques retardées

PdM est un type d'apprentissage automatique appelé apprentissage machine supervisé car il consiste à créer un modèle pour prédire les étiquettes, en fonction de la façon dont ces étiquettes sont mappées aux fonctionnalités des données de formation. Les deux étiquettes les plus couramment utilisées pour PdM sont:

La possibilité d'échec dans les n étapes suivantes (par exemple, «About To Fail»)
Le temps (ou cycles machine) restant avant la prochaine panne (par exemple, "Durée de vie utile restante")

La première caractéristique peut être prédite à l'aide d'un modèle de classification binaire qui génère les probabilités de défaillance dans une fenêtre de temps prescrite (par exemple, "je suis sûr à 90% qu'une défaillance se produira dans les 50 prochaines heures"). La deuxième caractéristique peut être prédite à l'aide d'un modèle de régression qui génère une valeur pour la durée de vie utile restante (RUL). Ces variables sont à la traîne, ce qui signifie qu'elles ne peuvent pas être affectées d'une étiquette jusqu'à ce qu'un événement de défaillance se produise.

Figure 9. Ensemble de données IIoT avant l'événement de défaillance

Lorsqu'une défaillance se produit, les valeurs peuvent être calculées pour ces variables en retard et appliquées rétroactivement à la table d'entités.

Figure 10. Ensemble de données avec durée de vie utile restante

Si les événements de défaillance sont rares, mais que les données IIoT sont fréquentes, l'étiquetage rétroactif des fonctionnalités en retard peut conduire à une mise à jour de table massivement volumineuse. Dans la section suivante, je parlerai de la façon dont deux technologies, Apache Spark et MapR-DB, peuvent travailler ensemble pour résoudre ce défi.

Ingénierie de fonctionnalités évolutive avec MapR-DB + Spark

Les tableaux de fonctionnalités pour PdM peuvent facilement dépasser la capacité de ce qui peut être stocké et traité sur un seul ordinateur. La distribution de ces données sur un cluster de machines peut augmenter la capacité, mais vous ne voulez pas le faire si vous avez finalement besoin de replacer les données sur une seule machine pour l'analyse et la formation des modèles. Afin d'éviter le mouvement des données et les points de défaillance uniques, le stockage et le calcul doivent être distribués. Apache Spark et MapR-DB offrent une solution pratique pour cette tâche.

Mapr-DB est une base de données NoSQL distribuée qui fournit la flexibilité d'échelle et de schéma nécessaire pour créer de grandes tables de fonctionnalités. Apache Spark fournit une fonctionnalité de calcul distribué qui permet d'analyser les tables de fonctionnalités au-delà des limites de ce qui peut tenir en mémoire sur une seule machine. Le connecteur MapR-DB pour Spark élimine le besoin de copier des tables d'entités entières dans des processus Spark. Au lieu de cela, MapR-DB exécute localement les filtres et les tris soumis à partir de Spark SQL et renvoie uniquement les données résultantes à Spark.

Figure 11. Intégration de MapR-DB et Apache Spark

Exemple d'ingénierie des fonctionnalités PdM

J'ai construit une application PdM théorique pour un système HVAC industriel qui montre plusieurs exemples d'ingénierie de fonctionnalités utilisant MapR-DB et Spark. Le code et la documentation de cette démo se trouvent sur ce projet Github. Des extraits ont été inclus ci-dessous pour illustrer les concepts d'ingénierie des fonctionnalités discutés précédemment.

Le pipeline de données pour cette application se compose d'un client MQTT, qui publie les données HVAC dans un flux à l'aide de l'API Kafka. Le flux d'ingestion met ces enregistrements en mémoire tampon pendant qu'un processus Spark les consomme et les conserve avec des fonctionnalités dérivées dans une table dans MapR-DB. Le pipeline ressemble à ceci:

Figure 12. Pipeline de données IIoT

Le code Scala suivant montre comment les enregistrements de flux sont lus avec Spark:

Le code ci-dessus crée un objet Dataset contenant des enregistrements MQTT bruts. Ce jeu de données peut être enrichi avec des fonctionnalités dérivées, comme ceci:

(Remarque: les traits de soulignement sont utilisés au début des noms de champ pour désigner les fonctions dérivées.)

Cet ensemble de données enrichi est ensuite enregistré dans MapR-DB à l'aide de l'API OJAI, comme ceci:

Jusqu'à présent, la table d'entités dans MapR-DB contient des valeurs de capteur HVAC et quelques fonctions dérivées, telles que _weekend, mais les valeurs des variables en retard AboutToFail et RemainingUsefulLife ne sont toujours pas affectées. Le travail Spark pour recevoir des notifications d'échec sur un flux et mettre à jour des variables en retard ressemble à ceci:

Lorsque ce travail Spark reçoit une notification d'échec, il calcule les valeurs des variables en retard, puis les applique rétroactivement à la table d'entités dans MapR-DB. La sortie de ce processus dans l'application de démonstration ressemble à la capture d'écran de la figure 13 ci-dessous.

Figure 13. Sortie du processus d'application de démonstration IIoT

Exemple d'algorithme PdM

Dans les sections précédentes, j'ai décrit les techniques d'enregistrement des données sur les conditions menant aux événements de défaillance, afin que les modèles PdM puissent être formés à l'apprentissage automatique supervisé. Dans cette section, je vais vous expliquer quoi faire de ces données et comment réellement former un modèle qui prédit les défaillances.

Les algorithmes de mémoire à court terme (LSTM) sont couramment utilisés pour prévoir les événements rares dans les données de séries chronologiques. Les défaillances étant généralement très rares dans les applications PdM, les algorithmes LSTM conviennent à la modélisation. Il existe des exemples LSTM facilement disponibles pour les cadres d'apprentissage machine les plus populaires. J'ai choisi Keras pour implémenter un algorithme LSTM pour la métrique «About To Fail» discutée ci-dessus. Si vous souhaitez voir les détails, lisez le cahier Jupyter que j'ai publié sur GitHub.

Mon implémentation LSTM utilise une table de fonctionnalités, comme ce qui a été décrit ci-dessus, pour former un modèle qui prédit si une machine est susceptible de tomber en panne dans les 50 cycles. Un bon résultat ressemble à ceci:

Figure 14. Résultats de la mise en œuvre du LSTM

C'est un bon résultat car il prédit l'échec avant qu'il ne se produise réellement, et il le prédit avec une confiance élevée (> 90%). Voici un exemple où le modèle fait une prédiction qui n'est pas utile, car il ne prédit l'échec qu'après l'échec déjà survenu:

Figure 15. Résultat d'implémentation LSM – deuxième exemple

C'est assez amusant de jouer avec différents jeux de données d'entraînement pour mieux comprendre les sensibilités de LSTM. Dans mon cahier Jupyter, j'explique comment synthétiser un ensemble de données et entraîner le modèle, afin que vous puissiez expérimenter avec LSTM sur votre ordinateur portable. J'ai intentionnellement utilisé seulement quelques fonctionnalités dans cet exercice afin de faciliter la compréhension des étapes de préparation des données et de mise en œuvre de LSTM. Je vous laisse le soin de trouver ces détails dans le cahier que j'ai posté sur GitHub, plutôt que de les répéter ici.

Conclusion

L'apprentissage automatique a le potentiel de rendre les stratégies de maintenance prédictive beaucoup plus efficaces que les méthodes conventionnelles utilisées ces dernières années. Cependant, la maintenance prédictive pose des défis importants en matière d'ingénierie des données, en raison de la bande passante élevée des sources de données IoT industrielles, de la rareté des défaillances mécaniques dans la vie réelle et de la nécessité de données à haute résolution pour les modèles de formation. L'efficacité de toute entreprise de développement et de déploiement du machine learning pour les applications de maintenance prédictive dépendra également d'une plate-forme de données sous-jacente capable de gérer les exigences uniques non seulement du stockage de données mais également d'un accès aux données non encombré, car les scientifiques des données itèrent sur les concepts d'ingénierie des fonctionnalités et développement d'un modèle.

A propos de l'auteur

Ian Downard est ingénieur de données et développeur évangéliste chez MapR. Il aime apprendre et partager ses connaissances sur les outils et les processus qui permettent aux équipes DataOps de mettre l'apprentissage machine en production. Ian coordonne le Java User Group à Portland, Oregon et écrit sur le Big Data ici et ici.

Laisser un commentaire