Principaux points à retenir
Réponse courte : Un historien de données et une base de données relationnelle sont deux façons de stocker des données, optimisées pour des types différents.
Un historien de données (ou historien de procédé) est un logiciel conçu pour capturer, compresser et stocker des séries temporelles à haute fréquence issues de procédés industriels, des milliers de lectures par seconde provenant de capteurs et de systèmes de contrôle, avec une récupération rapide basée sur le temps.
Une base de données relationnelle est un logiciel à usage général optimisé pour des données structurées et transactionnelles organisées en tables, avec des requêtes SQL, des relations et des transactions ACID. Les historiens sont adaptés aux flux de capteurs horodatés ; les bases relationnelles conviennent aux enregistrements structurés comme les commandes, les ordres de travail et les stocks.
Ils sont complémentaires, et la plupart des usines utilisent les deux.
Un historien de données, également appelé historien de procédé ou historien opérationnel, est un logiciel conçu pour capturer, stocker et restituer des séries temporelles à haute fréquence issues de procédés industriels.
Sa tâche est d'enregistrer le flux continu de mesures horodatées provenant de capteurs, d'instruments et de systèmes de contrôle (PLC, SCADA, DCS), températures, pressions, débits, vitesses, états, souvent des milliers de points de mesure échantillonnés plusieurs fois par seconde, jour et nuit, pendant des années.
Pour gérer ce volume, les historiens utilisent un stockage spécialisé pour séries temporelles avec une compression agressive (comme des algorithmes de bande morte et de "swinging-door" qui n'enregistrent que les changements significatifs), et ils sont optimisés pour une récupération rapide par plage temporelle : « montre-moi les valeurs de ce point de mesure au cours du dernier poste » renvoie instantanément.
Les historiens sont conçus pour les réalités des données d'usine : un débit d'écriture extrême, une conservation longue, des requêtes basées sur le temps et la résilience. Ils s'intègrent généralement directement avec la couche de contrôle et fournissent du trending, des agrégations et des accès pour l'analyse.
La force déterminante d'un historien est de traiter efficacement des données capteurs massives et continues, horodatées, en capturant toute la fidélité du comportement d'un procédé dans le temps, de manière compacte et récupérable.
Il n'est pas conçu pour des requêtes relationnelles complexes ni pour la tenue de registres transactionnels ; il est pensé pour être la mémoire séries temporelles à haute vitesse du plancher de l'usine.
Une base de données relationnelle (SGBDR) est un logiciel à usage général pour stocker des données structurées dans des tables, optimisé pour les transactions, les relations et les requêtes complexes.
Les données sont organisées en tables de lignes et de colonnes avec des schémas définis, reliées entre elles par des clés, et interrogées avec SQL, ce qui permet un filtrage puissant, des jointures et des agrégations à travers des enregistrements structurés.
Les bases relationnelles fournissent des transactions ACID (atomicité, cohérence, isolation, durabilité), qui garantissent l'intégrité des données pour des opérations qui ne doivent pas être partiellement exécutées, essentiel pour des éléments comme les commandes, les paiements et les mouvements de stock.
Elles excellent avec les données structurées, transactionnelles et relationnelles : fiches clients, ordres de travail, inventaires, enregistrements de production, nomenclatures, tout ce qui s'insère naturellement dans des tables liées et nécessite des mises à jour fiables et cohérentes ainsi que des requêtes riches.
La force déterminante d'une base de données relationnelle est de gérer des données structurées avec intégrité et des possibilités de requêtes flexibles : elle impose la cohérence, modélise les relations et répond à des questions complexes à travers les données.
Ce pour quoi elle n'est pas optimisée, c'est le débit d'écriture extrême et la récupération temporelle des flux de capteurs à haute fréquence : stocker des millions de lectures rapides en séries temporelles dans une table relationnelle générale est inefficace comparé à un historien spécialement conçu pour cela.
La base de données relationnelle est le cheval de trait pour les enregistrements structurés et transactionnels de l'usine, pas pour le flux brut des capteurs.
La distinction fondamentale est le type de données pour lequel chacun est conçu : un historien est optimisé pour les séries temporelles à haute fréquence issues des capteurs, une base de données relationnelle pour des données transactionnelles structurées. Cette différence d'objectif conditionne tout le reste.
Les historiens utilisent un stockage orienté séries temporelles avec une forte compression et un indexage temporel, réglés pour des taux d'écriture énormes et des requêtes « valeur dans le temps » ; les bases relationnelles utilisent des tables, des schémas, des clés, SQL et des transactions ACID, réglées pour des enregistrements structurés, des relations et des mises à jour cohérentes.
Ils répondent à des questions différentes : un historien répond efficacement à « qu'a lu ce capteur chaque seconde la semaine dernière ? » ; une base relationnelle répond efficacement à « quels ordres de travail pour cet équipement sont en retard et quelles pièces nécessitent-ils ? »
Chacun est médiocre dans le rôle de l'autre : une base relationnelle s'enlise en stockant et en interrogeant des millions de lectures capteurs rapides, et un historien n'est pas conçu pour modéliser et transactionnaliser des enregistrements relationnels structurés avec intégrité.
C'est pourquoi ils sont complémentaires plutôt que concurrents : l'usine génère les deux types de données, un flux continu de mesures de procédé (historien) et des enregistrements opérationnels structurés comme les commandes et les stocks (base relationnelle), et chaque type doit être stocké dans l'outil prévu à cet effet.
Choisir entre eux revient à associer les données au bon outil. (Les bases de données de séries temporelles modernes estompent la frontière, offrant des performances proches des historiens avec des capacités de requête plus générales.)
Considérons les données générées par une seule ligne de production. Ses machines diffusent des données de procédé à haute fréquence : vibrations, températures, courant moteur, compteurs de cycles, états marche/arrêt, des centaines de points de mesure échantillonnés plusieurs fois par seconde, en continu.
Ce torrent appartient à un historien de données : il compresse et stocke l'intégralité des séries temporelles à moindre coût, et un ingénieur peut instantanément extraire la tendance de n'importe quel point de mesure sur n'importe quelle fenêtre temporelle pour investiguer un problème ou alimenter une analyse.
Parallèlement, la même exploitation produit des enregistrements structurés et transactionnels : ordres de production, ordres de travail émis pour la maintenance, pièces prélevées en stock, lots produits et leurs décisions qualité.
Ceux-ci appartiennent à une base de données relationnelle : ils s'insèrent dans des tables liées, nécessitent des mises à jour transactionnelles cohérentes (une sortie de stock doit s'achever complètement ou pas du tout), et sont interrogés de façon relationnelle (« afficher les ordres de travail ouverts pour cet équipement et les pièces qu'ils consomment »).
Tenter de stocker le flux massif des capteurs dans la base relationnelle l'empêcherait de fonctionner correctement ; tenter de gérer les ordres de travail transactionnels et les stocks dans l'historien serait impraticable.
La ligne a besoin des deux : l'historien comme mémoire à haute vitesse du comportement du procédé, la base de données relationnelle comme système de référence pour les données opérationnelles structurées.
Souvent, les deux sont liés, avec des données historisées résumées jointes aux enregistrements structurés pour le reporting.
Choisissez selon la nature des données.
Utilisez un historien de données pour des données de procédé et de capteurs horodatées à haute fréquence, les mesures continues des machines et des systèmes de contrôle lorsque vous devez capturer la pleine fidélité dans le temps, compresser des volumes massifs et récupérer par plage temporelle pour du trending et de l'analyse.
Utilisez une base de données relationnelle pour des données structurées, transactionnelles et relationnelles : commandes, ordres de travail, inventaire, enregistrements de production et de qualité, tout ce qui s'insère en tables liées et nécessite intégrité, mises à jour cohérentes et requêtes complexes.
Dans presque toutes les usines, la réponse est les deux, déployés là où chacun est le plus efficace : l'historien comme magasin séries temporelles pour le flux de procédé, la base relationnelle comme système de référence pour les données opérationnelles structurées, souvent intégrés pour permettre des analyses conjointes.
Une nouveauté moderne est la base de données de séries temporelles (et les services séries temporelles cloud), qui offre des performances semblables à celles des historiens pour les séries temporelles avec des possibilités de requête plus générales et peut chevaucher le rôle de l'historien ; à grande échelle, les données brutes de l'historien peuvent aussi alimenter un data lake pour des analyses avancées.
Le cadre décisionnel est simple : adaptez le stockage aux données, les flux de capteurs séries temporelles à un historien (ou à une base de données de séries temporelles), les enregistrements transactionnels structurés à une base de données relationnelle, et intégrez-les plutôt que de forcer l'un à faire le travail de l'autre.
Les deux magasins alimentent l'OEE, de manière complémentaire.
Les données machine haute fréquence qu'un historien capture, états marche/arrêt, compteurs de cycles, vitesses, signaux de défaut, sont la matière première à partir de laquelle sont calculées la Disponibilité et la Performance de l'OEE ; l'historien est souvent l'endroit où résident les données granulaires derrière les pertes, et l'endroit où l'on va pour enquêter sur la cause d'une perte.
Les enregistrements structurés qu'une base de données relationnelle contient, ordres de travail, enregistrements de production et de qualité, motifs d'arrêt, fournissent le contexte opérationnel et le volet transactionnel de l'OEE, comme les données de maintenance et de qualité qui expliquent et coûtent les pertes.
Une image complète de l'OEE combine généralement les deux : la preuve séries temporelles de ce que la machine a fait (historien) avec les enregistrements structurés des commandes, de la maintenance et des motifs (base relationnelle).
Cela se relie à l'endroit où résident les données brutes par rapport aux données modélisées dans la division data lake versus data warehouse, et aux systèmes de contrôle (SCADA et DCS) qui génèrent les signaux.
Mais comme pour ceux-ci, des données brutes stockées ne font pas de l'OEE : une couche doit transformer les balises de l'historien et les enregistrements de la base de données en le modèle pertes Disponibilité-Performance-Qualité qui permet d'améliorer.
Fabrico transforme les données machine, qu'elles soient diffusées depuis la couche de contrôle ou stockées dans un historien, en une vision structurée des pertes OEE, en les joignant aux enregistrements opérationnels (motifs d'arrêt, ordres de travail, qualité) qui expliquent et évaluent le coût des pertes.
Plutôt que de laisser les balises séries temporelles brutes dans l'historien et les enregistrements transactionnels dans une base séparée, il fournit la ventilation Disponibilité, Performance et Qualité au-dessus des deux, de sorte que les données deviennent une vue claire des moments où le temps productif est perdu.
Réservez une démo pour voir vos données de procédé et opérationnelles devenir une OEE actionnable.
Un historien de données est un logiciel optimisé pour capturer, compresser et stocker des séries temporelles capteurs à haute fréquence issues de procédés industriels, avec une récupération rapide par temps. Une base de données relationnelle est à usage général, optimisée pour des données transactionnelles structurées en tables avec SQL et des transactions ACID. Les historiens conviennent aux flux de capteurs ; les bases conviennent aux enregistrements structurés.
Parce que les données capteurs à haute fréquence (des milliers de lectures par seconde, sur des années) submergent les tables relationnelles à usage général et sont lentes à interroger par temps. Les historiens utilisent une compression spécialisée des séries temporelles et une récupération indexée dans le temps conçues pour ce volume et ce type d'accès, pour lesquels les bases relationnelles ne sont pas optimisées.
À capturer et stocker les lectures continues et horodatées des capteurs et des systèmes de contrôle (PLC, SCADA, DCS), températures, pressions, débits, vitesses, états, à haute fréquence, avec compression et récupération rapide des tendances. C'est la mémoire séries temporelles à haute vitesse de l'usine, utilisée pour le trending, le dépannage et l'analyse.
Oui, généralement. L'historien stocke le flux de procédé à haute fréquence ; la base de données relationnelle est le système de référence pour les données transactionnelles structurées comme les commandes, les ordres de travail et l'inventaire. Chacun est utilisé là où il est le plus efficace, et les deux sont souvent intégrés pour permettre des analyses conjointes.
Les données machine haute fréquence de l'historien (états de marche, compteurs, vitesses) sont la matière première pour la Disponibilité et la Performance de l'OEE, tandis que les enregistrements structurés de la base (ordres de travail, motifs d'arrêt, qualité) fournissent le contexte et le coût. Une vue complète de l'OEE combine les deux, et une couche transforme ces éléments en modèle pertes qui permet d'améliorer.
Connexion
Blog