Internet Industriel des Objets IIOT : Algorithmes d'apprentissage IoT et maintenance prédictive – Partie II: Architecture IoT

Sommaire

L'article aborde le traitement intelligent des données de l'Internet des objets (IoT) dans un contexte de maintenance prédictive et le relie aux développements récents de l'apprentissage semi-supervisé. Bien qu'il soit écrit dans un souci d'un public non expert, l'article fait référence à des publications scientifiques récentes. Nous laissons le lecteur curieux et techniquement orienté développer ses connaissances sur les idées que nous avons esquissées (voir Les références). Nous visons à être informatifs et ouverts d'esprit pour stimuler les discussions sur l'analyse des données IoT.

Nous couvrons le sujet des algorithmes d'apprentissage IoT et de la maintenance prédictive dans une série de trois articles. Dans la PARTIE I, nous présentons une étude de cas simple et discutons de quelques algorithmes d'apprentissage qui s'y rapportent. Dans la PARTIE II (l'article actuel), nous nous concentrons sur l'analyse des données IoT et les applications à la conception IoT pour la maintenance prédictive. Dans la PARTIE III, nous passons en revue la littérature récente sur l'apprentissage semi-supervisé et comparons les fondements de différentes méthodes. Nous introduisons des cas réels dans lesquels l'apprentissage en quelques clics peut fournir une technique efficace pour l'analyse intelligente de l'IoT et le streaming de données. À la fin de cette série d'articles, vous trouverez un glossaire de termes et suggestions pour une lecture plus approfondie.

Nous ne prétendons pas être exhaustifs – l'IoT est un sujet vaste et florissant. N'hésitez pas à commenter et à entamer une discussion avec nous.

Prologue

Nous avons conclu la PARTIE I de cette série d'articles par plusieurs questions ouvertes concernant l'analyse des données IoT et les algorithmes d'apprentissage automatique correspondants:

Dans le présent article, nous aborderons les trois premières questions, laissant le reste à la PARTIE III.

L'IoT est le mot à la mode qui fait référence aux appareils interconnectés intégrés dans un réseau mondial. À savoir, l'IoT est un réseau de capteurs sans fil (WSN) d'appareils utilisant un ou plusieurs protocoles de communication (par exemple WAMP [[[[28], MQTT [[[[33]). En tant que tel, l'IoT peut exister dans divers contextes tels que la ville intelligente, l'urbanisme, l'agriculture, la production industrielle, la conduite autonome, l'entretien, etc. On dit que nous serons entourés d'environ 17 milliards d'appareils susceptibles de diffuser des données dans le cloud d'ici 2020, ce qui signifie environ 5 quintillions (5×10ˆ18) octets de données produites en moyenne chaque jour [[[[34]. Aussi excitant et prometteur que cela puisse paraître à ce stade précoce du développement, l'IoT comporte plusieurs défis. Cet article aborde certains de ces défis.

Dans la PARTIE I de cette série, nous avons présenté une expérience de pensée simple autour de la maintenance prédictive et de l'IoT. Nous avons suggéré que nous filtrions le streaming sur place (c'est-à-dire, par exemple, dans un atelier d'usine ou dans toute localité correspondante) via des modèles intelligents en bordure du réseau IoT. Cela a été présenté comme un paramètre de filtre sélectionné dynamiquement prenant en compte les changements locaux (par exemple aussi simple qu'une fenêtre ouverte ou fermée dans deux usines identiques). Aussi simple que cela puisse paraître, un tel processus nécessite tout d'abord des algorithmes d'apprentissage appropriés (PARTIE III) capables de gérer le déséquilibre des données et la multimodalité. De plus, le processus nécessite une architecture pour créer et diffuser des informations: messagerie sécurisée, stockage de données et infrastructure de déploiement d'applications. C'est pourquoi, tout d'abord, il convient de se pencher en profondeur sur l'infrastructure IoT et l'écosystème logiciel correspondants. Dans les sections suivantes, nous expliquerons ce que nous entendons par là. De plus, nous examinerons de près les aspects techniques pertinents et répondrons pourquoi les problèmes présentés dans la PARTIE I ont un sens.

Le cœur de notre argument est que pour traiter de gros flux de données, un réseau d'appareils locaux dans un cadre informatique distribué peut être formé. Imaginez plusieurs nœuds (tels que des caméras, des capteurs de température ou de pression, des compteurs) assis à des endroits pertinents pour le contexte ou atteignant simplement la mobilité dans une zone, par exemple dans un atelier d'usine. Ces appareils sont conçus pour mesurer les observables physiques et diffuser des données sur un serveur. Jusqu'à récemment, cela était mis en œuvre de manière simple (par exemple dans un modèle maître / esclave). Alternativement, les appareils peuvent potentiellement communiquer avec leurs pairs et évaluer les données. De plus, ils peuvent former des packages de flux de données (tampons locaux) et agir également comme des serveurs locaux. Le point crucial est que, idéalement, ces appareils devraient prétraiter les données qu'ils absorbent avant de les diffuser sur un serveur hôte.

En tant que produit final, le Big Data sera intégré dans un modèle d’IA (intelligence artificielle) utilisant d’immenses ressources de calcul (qui peuvent éventuellement vivre dans le Cloud ou dans un centre de calcul «à proximité»). C’est également un problème que nous n’aborderons pas à ce stade. Enfin, l'IA centrale sera héritée récursivement par des appareils locaux pour améliorer les solutions aux problèmes du monde réel. Comment aborder cette question dans un scénario ascendant alors? Commençons par les propriétés des données IoT.

Figure 1. La collecte et la diffusion de données IoT entraînent plusieurs défis [[[[13]

1.1. Caractéristiques des données IoT

Tout d'abord, nous devons comprendre les propriétés générales des données collectées et publiées par les capteurs dans un contexte IoT général. Les données IoT ne sont pas simplement un autre type de Big Data. Pour commencer, il faut être conscient des six problèmes suivants ou du soi-disant «challenging 6 Vs»De l'IoT [[[[8].

Les trois premiers V sont généraux:

Les trois V restants dépendent souvent du contexte:

Certaines de ces propriétés peuvent devenir plus importantes pour un problème donné. Par exemple, dans un environnement industriel, ce n'est pas toujours la taille des données qui importe le plus. Parfois, la sécurité du réseau et la valeur commerciale vont de l'avant. Pensez aux données des capteurs du compteur de produits avec un algorithme de reconnaissance d'image sophistiqué pour une période de production de 10 secondes. En général, il peut y avoir des processus beaucoup plus rapides (par exemple la production de polymères ou la presse à métaux; la bande passante est adaptable dans une large mesure. Nous supposons que l'on peut restreindre le volume de données de la croissance – au cas où cela serait inutile dans un contexte donné. Cette tâche sera exécuté de manière optimale si des filtres intelligents sont mis en œuvre. C'est probablement la préoccupation la plus simple d'un scientifique des données lors de la construction d'une plate-forme IoT.

Figure 2. Figure adaptée d'un article de synthèse [[[[13].

D'une part, toutes ces propriétés principales combinées, de nombreux problèmes découlent des paradigmes actuels de l'IoT, car "… les l'abstraction des données IoT est faible, c'est-à-dire que les données provenant de différentes ressources de l'IoT sont pour la plupart des données brutes et insuffisantes pour l'analyse » [[[[13]. par conséquent, simplement regrouper toutes les données brutes dans un serveur et espérer découvrir des informations dans ce soi-disant lac de données semble infructueux. Cela n'est pas seulement dû à des contraintes techniques telles que les ressources de calcul, mais aussi à des corrélations temporelles et spatiales ignorées par le streaming et le pooling constants (sans filtre).

Deuxièmement, certains petits changements non détectés dans un environnement IoT peuvent parfois prétendre être d'une immense importance. Par exemple, dans un contexte d'automatisation d'usine, les équipes de maintenance sont censées savoir d'abord quelle machine réparer quand et où. En outre, l'historique de machines particulières est également important, ce qui implique que différents types de données peuvent être collectés à partir d'une machine spécifique et que le modèle doit être légèrement adapté à celle-ci. Ainsi, l'héritage de l'intelligence en bordure du réseau est en effet crucial, ainsi que l'adaptation locale aux petits changements. D'une part, une extension locale du modèle est nécessaire pour une évaluation des données «sur place» similaire à ce que nous avons suggéré précédemment (devrait donner une importance ultime aux précurseurs d'une panne). D'un autre côté, la précision peut souffrir de sources de bruit locales non détectées (aussi simple qu'une porte d'usine ouverte alors qu'elle n'est pas détectée au début). Nous aborderons cette question et plusieurs techniques dans les sections suivantes, puis en détail dans la PARTIE III.

Troisièmement, avec ou sans les problèmes mentionnés ci-dessus, l'IoT nécessite une base de données et une énorme puissance de traitement pour former un modèle général (imaginez le succès d'un modèle de reconnaissance vocale de Google par rapport à une solution personnalisée). À la fin de la journée, nous aimerions atteindre les deux fonctionnalités. À savoir, la généralité d'un modèle d'IA central évoluant dans une échelle de temps lente et l'intelligence fonctionnant localement pour l'évaluation et le streaming de données. Le diable réside dans un subtil compromis entre les niveaux (vers le haut ou vers le bas sur la figure 2) ce qui signifie que nous devons mettre en œuvre l'IA à tous les niveaux. Une alternative vraiment désagréable se réveille un beau dimanche au milieu d'un immense lac de données, comprenant éventuellement des centaines de téraoctets de fichiers audio échantillonnés à 10 kHz, bien qu'ils ne contiennent aucune anomalie. Cela coûte déjà des ressources de stockage et de calcul – seulement pour découvrir qu'elles sont inutiles.

Pour résumer la discussion à ce stade, pour mettre en place un environnement IoT efficace, il faut traiter les problèmes techniques liés à l'IoT au-delà du Big Data statique (voir l'article [[[[8]):

Pour interférer à n'importe quel niveau / couche, il faut exécuter des algorithmes intelligents intégrés dans les applications IoT [[[[13]. C'est plus facile à dire qu'à faire. Pour accomplir cette tâche, des algorithmes d'apprentissage récemment semi-supervisés sont utilisés pour aider à équilibrer les échantillons manquants ou même à créer plus d'échantillons (avec les GAN) [[[[1]), si nécessaire. Ces techniques, d'une part, peuvent «modéliser la petite quantité de données étiquetées avec une grande quantité de données non étiquetées» [[[[13] (apprentissage transductif). D'autre part, ils peuvent incorporer une "Petite quantité de données non étiquetées avec une grande quantité de données étiquetées" [[[[13] (apprentissage inductif). Nous supposons, dans cette série d'articles, que nous traitons principalement d'un problème d'apprentissage inductif.

1.2. Analyse des données IoT et apprentissage automatique

Les données IoT ne sont pas seulement des Big Data, mais elles encapsulent des observations multimodales (par exemple audio, visuelles et numériques) et ses paramètres peuvent varier dans le temps dans un contexte donné. Ces propriétés rendent difficile l'adaptation de l'analyse de données / intelligence artificielle à l'IoT [[[[13]. L'IoT a simplement besoin d'algorithmes intelligents qui sont flexibles pour inclure diverses sources et modifier les propriétés ainsi qu'une infrastructure de mise à jour pour atteindre le modèle le plus intelligent disponible (par exemple à partir d'un registre Cloud). Surtout, dans la pratique, nous devons transférer des catégories et des relations apprises précédemment pour donner un sens à de nouvelles observations.

Le transfert de classes et de relations déjà apprises est crucial pour une stratégie d'apprentissage efficace. Les humains utilisent cette stratégie pour apprendre de nouveaux comportements basés sur des comportements appris similaires ou se souvenir des caractéristiques de nouveaux objets basés sur des classes d'objets connues. Bien sûr, nous ne sommes pas intéressés par les implémentations de apprentissage en quelques coups ou en termes généraux, transférer l'apprentissage uniquement pour imiter les humains via des appareils intelligents IoT. Cette technique est en soi important pour l'efficacité du vaste cadre IoT dans la présélection des données à la source.

Dans la PARTIE III de cette série d'articles, nous passons en revue un ensemble de modèles et de techniques d'apprentissage semi-supervisés qui abordent ces questions dans une certaine mesure. En particulier, une attention particulière est accordée aux développements actuels dans les réseaux de neurones profonds (DNN) et les machines à vecteurs de support (SVM). D'autres modèles d'apprentissage automatique sont également mentionnés par souci d'exhaustivité.

Figure 3. Maintenance prédictive avec IoT [[[[22]

L'apprentissage automatique est crucial pour l'IoT, mais nous prenons un peu de recul à ce stade pour écrire sur l'infrastructure industrielle de l'IoT.

1.3. Une note sur la messagerie et la sécurité

La création d'applications intelligentes distribuées sur différents appareils nécessite une architecture plus sophistiquée qu'un simple logiciel monolithique. Ainsi, nous entrons dans le domaine des microservices et de la version et de la messagerie gérées par l'infrastructure.

Micro-services: sécurité, stabilité et gestion des données

Dans cette section, nous traitons des technologies de messagerie et de déploiement d'applications. Celles-ci sont importantes dans le cadre de la collecte de données et de la distribution ultérieure de l'IA mise à jour aux limites du réseau. Ces deux sujets sont traités dans la même section car la technologie WAMP encapsule à la fois Pub / Sub (publication et abonnement) et RPC (appels de procédure à distance). Cela rend le déploiement et le streaming de données au sein du même protocole simultanément possibles. Les protocoles de télécommunications et les technologies de messagerie sont motivés, d'une part, par des problèmes de compatibilité entre les différents composants des chaînes de montage. D'un autre côté, nous avons des problèmes de sécurité et de stabilité liés à la prévention des intrusions et aux temps d'arrêt du réseau. Par ailleurs, la complexité des réseaux d'applications étendues dans l'espace et le temps nécessite des mécanismes de liaison de données optimisés. Un défi supplémentaire est que le réseau correspondant est dynamique, ce qui signifie qu'il est constitué de nœuds ou de connexions activés et désactivés dans le cadre d'un processus de production automatisé.

En limitant notre champ d'application aux applications industrielles, nous décrivons ci-dessous un aperçu des technologies de messagerie et des problèmes qui s'y posent:

OPC (serveur)

OPC (Open Platform Communications) a été introduit en 1996 en tant que protocole unificateur pour l'automatisation industrielle. L'idée principale derrière cela est qu'une chaîne de montage peut fonctionner avec de nombreux dispositifs de contrôle différents, par exemple PLC (contrôleurs logiques programmables) qui peuvent avoir des protocoles de messagerie incompatibles entre eux. Un serveur OPC collecte simplement les données de tous les API et IHM (interfaces homme-machine) dans un environnement d'usine en utilisant un modèle serveur-client. Traditionnellement, les API utilisaient différents protocoles Modbus et réseaux Ethernet. Compte tenu des problèmes de compatibilité, une alternative à OPC était un logiciel personnalisé conçu pour une ligne de production donnée, ce qui prend du temps, est coûteux et rigide. D'une part, cet inconvénient justifie un protocole unifié (OPC). D'un autre côté, l'inconvénient est qu'OPC dépend de la plate-forme (basée sur Windows) et n'est pas sécurisé (présentant des ports ouverts).

OPC UA (serveur)

Le protocole OPC susmentionné était la norme de télécommunication de référence dans l'automatisation d'usine jusqu'en 2006, lorsque sa nouvelle version OPC UA (Open Platform Communications Unified Architecture) a pris le relais. En tant que tel, OPC UA dépasse les capacités d'OPC. Pour commencer, OPC UA est indépendant de la plate-forme tandis que l'écosystème OPC réside dans le système d'exploitation Windows. En outre, il existe plusieurs packages OPC UA open source disponibles en C, Python, JavaScript, etc.

La structure d'un serveur OPC UA est simple. Il a un nœud racine qui ouvre un canal de communication (qui peut être sécurisé par des pare-feu) et un espace d'adressage, dans lequel chaque nœud est un objet (au sens de la programmation orientée objet) avec les fonctions et attributs correspondants (données statiques et dynamiques). Le nœud racine peut être connecté au monde extérieur avec un protocole sécurisé tel que MQTT et / ou WAMP.

Aujourd'hui, OPC UA est considéré comme une passerelle vers le soi-disant Industrie 4.0. Le plan mondial pour atteindre l'industrie entièrement automatisée consiste à intégrer la technologie OPC UA non seulement dans les nouvelles générations de dispositifs de contrôle (API, IHM, etc.), mais également dans tout appareil qui se connecte aux réseaux industriels IoT. Cela simplifie le travail manuel lié au logiciel qui doit être géré et payé. Cependant, OPC UA est un protocole de machine à machine tandis qu'un paramètre entièrement automatisé doit souvent interagir avec le monde extérieur, ce qui signifie un serveur hôte ou un registre d'applications.

Les écosystèmes d'application peuvent être dans le cloud ou vos installations locales à distance de l'atelier de l'usine. Par conséquent, les informations à transférer de / vers le réseau IoT local vers / depuis le monde «extérieur» ou les mises à jour des applications doivent être gérées. Pour accomplir un tel flux de données, il existe plusieurs technologies de messagerie sécurisée de l'industrie, dont nous ne couvrirons que MQTT et WAMP [[[[28, 33].

Messagerie sécurisée IoT: MQTT et WAMP

Des ponts OPC UA – MQTT et OPC UA – WAMP et MQTT – WAMP sont disponibles. L'architecture du réseau est flexible et peut répondre aux exigences des environnements IoT industriels hétérogènes.

La maintenance prédictive et l'IoT vont de pair. Citer [[[[21]:

L'IoT industriel rend la transition vers une surveillance continue basée sur les conditions et une maintenance prédictive facile et abordable. Quatre tendances clés sont à l'origine de ce changement:

Isolées, chacune de ces technologies apporte une certaine valeur. Combinés en une seule solution, ils ont le pouvoir de transformer le monde industriel. [[[[21]

Une architecture IoT se compose de quatre parties principales:

> A. Périphériques Edge

Le nom est explicite. Les périphériques Edge résident à l'extrémité distante d'un réseau IoT, près de la source de données. Ils sont simplement constitués d'une unité de traitement (une architecture ARM ou même un ordinateur plus petit) plus un ou plusieurs points finaux d'observation (capteurs, caméras, microphones, etc.).

Comme mentionné, il existe deux pyramides de base des tâches IoT: la pyramide de streaming de données en temps réel et la pyramide inversée de gestion et de calcul de données. Plus on se rapproche du bord, les ressources de calcul les plus petites seront en général. Les périphériques Edge ne peuvent implémenter qu'une quantité modeste de prétraitement. Ainsi, nous devons choisir judicieusement nos méthodes. Notre point de vue est que, bien que cette règle empirique soit valide, il se peut que nous devions la plier pour des raisons d'exactitude, d'efficacité ou d'interprétabilité.

> B. Le réseau

Un réseau se compose de connexions et de nœuds. Ces connexions et nœuds peuvent être trop hétérogènes car un réseau Internet est très dynamique. Cela signifie que de nouveaux appareils peuvent rejoindre ou quitter le réseau ou que de tels appareils peuvent exiger un nouveau protocole. Cette complexité doit être gérée par une architecture IoT flexible.

> C. Un service de gestion des appareils

Un réseau IoT contient des ressources et des tâches hétérogènes. La gestion des tâches dans un appareil signifie que nous y déployons et employons une application appropriée, allouons des ressources à ses fonctions et conservons les métadonnées de l'appareil pour maintenir l'état de l'appareil. Ceci sera discuté en détail ci-dessous.

> D. Un service de gestion des données

Lorsque les trois aspects sont réunis, un modèle de streaming et de stockage est toujours nécessaire. De plus, nous avons besoin d'un filtrage transparent des processus de données. Par exemple, les sources de données, à la suite de requêtes SQL ou de mécanismes de codage de données, doivent être transparentes. Ce sujet sera présenté en détail ci-dessous.

Dans les sous-sections suivantes, nous nous concentrons sur les détails des deux derniers aspects, car le matériel IoT (capteurs, processeurs, mémoires, etc.) est un vaste sujet et le traiter ne contribuera pas beaucoup à notre discussion à ce stade. Une autre raison concernant la topologie du réseau est qu'elle peut varier énormément en fonction des besoins de l'utilisateur. Par topologie, nous entendons quels appareils sont connectés à l'aide de divers protocoles et ponts entre les protocoles, etc.

2.3. Comment gérer vos appareils

Dans cette section, nous mentionnons les défis de la gestion des appareils. Commençons par l'hétérogénéité des environnements et des configurations (friche industrielle), le déploiement sans fil (sans fil), la gestion à distance des paramètres de connectivité, la qualité du réseau (mise en mémoire tampon des données), la sécurité, etc. sont des problèmes majeurs.

Décrivez les défis avec:

Dans un environnement industriel où l'IoT est intégré dans le processus de production, il faut traiter avec différentes sources de données. Ce processus est dynamique et automatisé, et en général, tout déploiement ou mise à jour IoT ne doit pas interrompre la production. Tout d'abord, les fonctionnalités des applications peuvent évoluer ou un mécanisme de déploiement doit être disponible au cas où une nouvelle fonctionnalité serait à construire. De plus, de nouveaux appareils peuvent être ajoutés au réseau. Cela devrait être géré de manière modulaire afin que les applications évolutives puissent répondre aux besoins de cet environnement dynamique complexe. La méthode de gestion doit être suffisamment flexible pour implémenter le registre d'applications localement ou dans le cloud. Elle devrait répondre à l'une des principales préoccupations d'une telle infrastructure, à savoir la sécurité: prévention des intrusions et des interventions.

2.4. Comment gérer les données IoT

Dans cette section, nous mentionnons certains défis majeurs de la gestion des données IoT. Pour enrôler: le volume de données, la sensibilité au temps en temps réel par rapport au traitement par lots, l'hétérogénéité (pas de normes de structures de données), les contrôles de flux de données, la gestion des métadonnées, la qualité des données, la transformation pour l'utilisabilité, la création de grands historiques de données, l'auditabilité, etc. sont des problèmes lorsque gérer les données IoT

Nous décrivons ci-dessous les principaux défis:

Tant que les applications d'acquisition de données sont déployées dans les appareils, nous pouvons commencer à collecter des données. Néanmoins, la question demeure de savoir comment gérer ces données avec un volume immense et une nature multimodale. Une partie de cela peut être gérée par le mécanisme de déploiement d'application via des RPC, par ex. encapsuler différentes structures de données, encodage et décodage. Encore une fois, par streaming RPC, les paramètres peuvent être adaptés à la main ou de manière automatisée. Cependant, nous devons stocker les données de manière cohérente, ce qui signifie que les sources doivent être respectées et les opérations de table (SQL) doivent être transparentes. De plus, les données d'échelle de temps posent encore plus de défis car souvent les données ont des corrélations en série et parallèles – comme souvent la proximité physique peut être un aspect crucial. C’est pourquoi il faut garder une trace des bains et des métadonnées des appareils dans un environnement dynamique. Comment gérer toute cette complexité? Répondons à cette question.

2.5. RÉCHAUFFER

Une fois que nous avons esquissé les principaux problèmes concernant la gestion des appareils et des données, nous sommes arrivés à présenter une solution. Notre solution est implémentée dans une nouvelle plateforme de gestion des appareils / applications IoT appelée RESWARM. RESWARM est un environnement de gestion des essaims basé sur WAMP. La complexité de l'architecture abordée par notre solution est présentée dans l'organigramme ci-dessous:

RESWARM traite les problèmes mentionnés ci-dessus en utilisant la technologie WAMP et l'écosystème d'applications pertinentes pour l'IoT

Les applications peuvent résider dans le cloud ou dans un registre local tandis que les déploiements d'applications peuvent être facilement mis en œuvre à l'aide des fonctionnalités RESWARM (basées sur RPC). La communication est sécurisée et cohérente (basée sur pub / sub). Il s'agit d'un instantané d'une instance en cours d'exécution du frontend RESWARM avec tous ses boutons impliquant la gestion des applications. En utilisant le studio de développement, votre application peut être modifiée:

Un aperçu de l'interface RESWARM

Entrer dans les détails techniques de RESWARM dépasse le cadre de cet article. En résumé, tant qu'un mécanisme d'héritage d'apprentissage récursif (appelé apprentissage en ligne) est disponible, on peut déployer de nouvelles versions de modèles intelligents sur divers appareils via la technologie de conteneur (par exemple Docker) et la messagerie WAMP (par exemple Crossbar).

2.6. Choix de l'architecture de stockage: C'est un gros sujet en soi. La première question est: quel modèle de données dois-je utiliser? La deuxième question est: quelle version de SQL / NoSQL dois-je choisir et quelle infrastructure de stockage dois-je choisir? Choisir une technologie de stockage appropriée pour une solution de gestion des données à long terme n'est pas une tâche facile car elle implique de nombreuses décisions techniques et conceptuelles. Si vous souhaitez créer la solution par vous-même à l'aide de composants open-source, vous pouvez consulter diverses bases de données chronologiques telles que influxDB ou PostgreSQL avec l'extension timescaleDB, ou vous pouvez choisir une solution de stockage en cluster telle que HDFS, GlusterFS ou Cassandra. Chacun a ses avantages et désavantages.

2.7. Comment gérer vos processus de données: Une fois les données stockées, vous avez besoin d'outils pour transformer et analyser les données pour en faire quelque chose d'utile. Il peut s'agir d'analyses classiques ou de modèles d'apprentissage automatique de formation en calcul intensif. Si vous avez des processus à saisir, transformer et extraire des informations, vous avez encore besoin de plus de logique pour contrôler ces processus. Vous avez besoin de la gouvernance des données, de la qualité des données et d'une logique d'automatisation. Les outils qui fournissent ce type de service doivent être hébergés et administrés sur site ou dans le cloud en plus de la technologie de stockage brute.

Pour simplifier ces tâches, nous proposons une solution appelée Repods. Pour une discussion sur le sujet et cette plateforme, nous vous renvoyons à l'article moyen suivant [36].

Connecteur IoT Repods basé sur WAMP

Nous sommes à la veille d'une industrie entièrement automatisée. Ni optimisation de processus ni maintenance prédictive ne peuvent être envisagées sans infrastructure IoT. Motivés par cela, nous avons présenté une infrastructure IoT et un écosystème logiciel axé sur les applications industrielles. En gardant à l'esprit notre objectif principal, la maintenance prédictive et l'optimisation des processus dans l'industrie, nous avons esquissé quelques sujets importants dans l'IoT industriel. De plus, l'article actuel a abordé certaines des questions posées dans la PARTIE I. Celles-ci comprennent:

L'IoT est l'avenir, mais les données IoT posent de nombreux défis techniques. À notre avis, la collecte et la diffusion d'énormes quantités de données générées par l'IA est l'un des problèmes les plus urgents. En théorie, l'IoT peut être constitué de nœuds interconnectés et collaborateurs au lieu d'un simple streaming constant ou d'un modèle maître / esclave. En pratique, cela nécessite une infrastructure de messagerie et de déploiement. Comme solution possible, nous proposons notre environnement de gestion et de développement basé sur WAMP RESWARM. Bien qu'il n'ait pas encore été testé à grande échelle, RESWARM est théoriquement évolutif et offre des fonctionnalités faciles à utiliser pour gérer les appareils et les applications dans les environnements d'usine.

IoT data properties and data storage infrastructures are also mentioned above. Major problems inherent here include keeping track of correlated data sources, collecting meta-data, and keeping time-stamps consistently. Moreover, a transparent data warehousing method helps us clean and prepare data for the training of large-scale network models. For these tasks, we propose our custom solution Repods. Repods is a cloud data platform that has IoT connectors and SQL functions presented as data pipelines. The platform provides users with an API function and custom reporting features (e.g. D3, HTML). Visit our channel Data Science with Repods for more information on the cloud data platform and stay tuned for more.

We are still in debt to the reader and we will atone for this in PART III by answering the following questions:

________o_______________o_______

Acknowledgments

Thanks to Dr. Marko Petzold and Dr. Sven Dorosz for discussions. Special thanks to Dr. Petzold for his contribution to data and device management sections.

________o_______________o_______

This article is part of a three-piece article series. See Part I and Part III here:

IoT Learning and Predictive Maintenance — Part I

IoT Learning and Predictive Maintenance — Part III

1. Article: Generative Adversarial Residual Pairwise Networks for One-shot Learning

2. Article: Efficient K-Shot Learning with Regularized Deep Networks

3. Article: Optimization as a Model for Few-shot Learning

4. Article: Low-shot Visual Recognition by Shrinking and Hallucinating Features

5. Article: Model-agnostic Meta-learning for Fast Adaptation of Deep Networks

6. Article: Prototypical Networks for Few-shot Learning

sept. Article: Meta-SGD: Learning to Learn Quickly for Few-shot Learning

8. Article: Deep Learning for IoT Big Data and Streaming Analytics: A Survey

9. Article: Meta-learning a Dynamical Language Model

dix. Article: Low-shot Learning with Large-scale Diffusion

11. Article: Meta-learning for Semi-supervised Few-shot Classification

12. Article: Machine Learning in Wireless Sensor Networks: Algorithms, Strategies, and Applications

13. Article: Machine Learning for the Internet of Things Data Analysis: A Survey

14. Article: Matching Networks for One-shot Learning

15. Article: One-shot Learning with a Hierarchical Nonparametric Bayesian Model

16. Article: Metric Learning with Adaptive Density Discrimination

17. Article: Siamese Neural Networks for One-shot Image Recognition

18. Article: A Survey on Metric Learning for Feature Vectors and Structured Data

19. Blog by Thomas Wolf: Meta-learning

20. Blog by Tassilo Klein: Deep Few-shot Learning

21. Blog by Abhinav Khushraj: IoT-based Predictive Maintenance

22. Blog: The Value That IoT Brings

23. Livre by Bishop: Pattern Recognition and Machine Learning

24. Article: A Comparative Evaluation of Unsupervised Anomaly Detection Algorithms for Multivariate Data

25. Article: Imitation Networks: Few-shot Learning of Neural Networks from Scratch

26. Article: Learning to Remeber Rare Events

27. Article: Make SVM Great Again With Siamese Kernel For Few-shot Learning (authors undisclosed)

28. Presentation: WAMP( Web Application Messaging Protocol)

29. Wiki: Anomalies in Statistics, the Definition Given by Wikipedia

30. Article: The Internet Of Things: New Interoperability, Management, and Security Challenges

31. Book: Foundations of Time-Frequency Analysis

32. Wiki: Intro to PID Controllers

33. la toile: https://mqtt.org/faq

34. la toile: http://customerthink.com/top-5-surprising-facts-everyone-should-read-about-iot/

35. Blog: https://blog.timescale.com/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a?gi=85a48c950887

36. Blog: Repods

Laisser un commentaire