Enregistrements et métadonnées des modèles

Ce guide explique comment modéliser les enregistrements et les métadonnées dans Manufacturing Data Engine (MDE).

Les enregistrements capturent des informations sur le processus de fabrication, telles que les lectures de capteurs et les événements. Les métadonnées permettent de contextualiser ces informations et de les segmenter selon les attributs de métadonnées. Les métadonnées servent également de source de données d'origine pour les entités de fabrication.

Si vous utilisez la suite MDE complète (MDE en combinaison avec Manufacturing Connect (MC)), vous pouvez ignorer cette section sur la modélisation des données, car MDE fournit un package pour vous aider à démarrer rapidement. Toutefois, il peut être utile de le lire si vous intégrez d'autres sources de données.

Recommandations générales

Avant de commencer à modéliser les métadonnées, vous devez comprendre les points suivants :

• Besoins de consommation de données des utilisateurs en aval : Cela implique de comprendre les données dont ils ont besoin et la façon dont ils prévoient de les utiliser. Pour ce faire, rencontrez les utilisateurs en aval pour leur poser des questions sur leurs objectifs, leurs indicateurs clés de performance (KPI), leurs cas d'utilisation, leurs exigences en termes d'analyse et leurs normes de qualité des données.
• La réalité des données sources sous-jacentes : Cela inclut la compréhension de la qualité des données, de leur structure et de leur traçabilité. Pour ce faire, rencontrez des experts du système source et effectuez un profilage des données de haut niveau.
• Exigences techniques concernant l'intégration des données Cela inclut la compréhension des interfaces d'intégration de données que MDE doit prendre en charge et des exigences techniques à respecter, y compris les conventions de dénomination.

Voici quelques actions spécifiques que vous pouvez effectuer pour comprendre les besoins de consommation des utilisateurs en aval :

• Rencontrez les utilisateurs en aval pour comprendre leurs objectifs :
  • Quels sont leurs objectifs avec les données ?
  • Quels sont leurs KPI ?
• Demandez aux utilisateurs en aval quels sont leurs cas d'utilisation :
  • Comment compte-t-il utiliser les données ?
  • Quels rapports souhaitent-ils exécuter ?
  • Quelle analyse veulent-ils effectuer ?
• Comprendre les exigences des utilisateurs en aval concernant les données analytiques :
  • Quel type de données doit-il analyser ?
  • À quelle fréquence doivent-ils analyser les données ?
• Demandez aux utilisateurs en aval quelles sont leurs normes de qualité des données :
  • Quel niveau de qualité des données est acceptable pour eux ?
  • Quelles mesures doivent-ils prendre pour s'assurer que les données sont conformes à leurs normes ?

Voici quelques actions spécifiques que vous pouvez effectuer pour comprendre la réalité des données sources sous-jacentes :

• Rencontrez des experts du système source :
  • Quelle est la qualité des données dans les systèmes sources ?
  • Quelle est la structure des données ?
  • Qu'est-ce que la traçabilité des données ?
• Effectuez un profilage des données de haut niveau :
  • Cela vous aidera à identifier les problèmes potentiels liés aux données, tels que les valeurs manquantes, les enregistrements en double ou les types de données non valides.

Modélisation des métadonnées

Lorsque vous modélisez des métadonnées, vous devez vous poser trois questions clés :

1. Quelles métadonnées doivent être traitées comme des métadonnées intégrées et quelles métadonnées doivent être traitées comme des métadonnées cloud ?
2. Quels buckets créer pour les métadonnées cloud ?
3. Quel doit être le schéma des buckets de métadonnées cloud ?

Choisir entre les métadonnées intégrées et celles dans le cloud

Le principal critère de décision à appliquer pour déterminer si certaines informations contextuelles doivent être modélisées en tant que métadonnées intégrées ou métadonnées cloud est le rythme de changement.

Les métadonnées intégrées sont plus adaptées aux métadonnées qui changent rapidement. Cela inclut les métadonnées telles que les ID de transaction ou les compteurs à incrémentation automatique.

En revanche, les métadonnées cloud sont plus adaptées aux métadonnées qui changent plus lentement, par exemple les métadonnées d'assets. MDE suit l'historique des instances de métadonnées par bucket et écrit ces métadonnées dans des récepteurs compatibles, tels que BigQuery. Cela vous permet d'explorer l'historique des instances de métadonnées par clé naturelle, tout en permettant aux outils de informatique décisionnelle (BI) tels que Looker d'obtenir une liste unique de valeurs d'attributs sans parcourir l'intégralité de la table d'enregistrements.

Modéliser les buckets de métadonnées cloud

Les buckets modélisent un domaine contextuel. Par exemple, une implémentation des modèles de hiérarchie des ressources ISA-95 modélise la hiérarchie des ressources physiques d'une entreprise manufacturière. Vous devez modéliser les buckets de métadonnées en fonction des limites des domaines contextuels. Par exemple, vous pouvez modéliser le contexte des composants (tel qu'exprimé par une implémentation ISA-95) dans un bucket asset et l'état de la machine dans un bucket machine-status.

Vous devez également déterminer si vous devez contextualiser un tag ou un groupe arbitraire d'enregistrements.

Les buckets de balises doivent être choisis pour les métadonnées liées aux balises, tandis que les buckets d'enregistrements doivent être choisis pour tout autre type de métadonnées.

Il est généralement conseillé de modéliser les métadonnées de domaine hiérarchiques dans le même bucket. Par exemple, alors que les attributs de la machine à laquelle appartient la balise (par exemple, le fabricant d'un capteur installé dans la machine) pourraient être modélisés dans deux buckets distincts (bucket de balise et bucket de machine), il est généralement préférable de modéliser ces relations hiérarchiques dans un seul bucket.

Une bonne raison de diviser une hiérarchie en plusieurs dimensions distinctes est de permettre l'association d'enregistrements à des métadonnées à différents niveaux de précision. Par exemple, si vous intégrez deux sources de données différentes, dont l'une envoie des données avec une précision au niveau du capteur et l'autre avec une précision au niveau de la machine, vous devez séparer les données spécifiques à la machine dans leur propre bucket.

Configurer le schéma du bucket de métadonnées cloud

Le schéma d'un bucket détermine la structure autorisée des instances de métadonnées dans un bucket. Les schémas déterminent la qualité des données et vous permettent également de définir les champs qui peuvent ou doivent être utilisés pour décrire une entité qu'un bucket donné modélise. Les champs que vous devez autoriser ou exiger dans un bucket dépendent en grande partie des données fournies par vos sources, ainsi que de la stratégie de remplissage des buckets et d'association des enregistrements que vous choisissez.

Si vous choisissez de remplir les buckets de métadonnées de manière dynamique à partir du périphérique Edge, votre principale préoccupation lors de la définition d'un schéma doit être la disponibilité des métadonnées dans les messages sources. Vous devez également tenir compte de la conformité des données et de la facilité d'ingestion. Plus les schémas de bucket de métadonnées sont spécifiques et plus les champs sont marqués comme obligatoires, plus les instances de métadonnées résultantes sont cohérentes. Toutefois, cela augmente également les exigences du parseur pour résoudre les différences structurelles entre les messages.

En revanche, plus vos schémas de bucket sont génériques (par exemple, en spécifiant qu'une propriété de métadonnées peut être n'importe quel "objet" au lieu de définir des propriétés d'objet spécifiques), plus les exigences de transformation et d'harmonisation des métadonnées dans l'analyseur sont faibles. Toutefois, cela peut se faire au détriment de la cohérence et de la conformité des métadonnées.

Un autre élément important à prendre en compte lors de la conception d'un schéma de bucket est la granularité du bucket. Si vous créez des instances de métadonnées via l'API, assurez-vous que la clé naturelle n'est pas plus précise ni plus approximative que les données que vous prévoyez de recevoir du périphérique Edge. Par exemple, si vous recevez des événements d'état à partir du périphérique en périphérie au niveau de la machine, mais que votre bucket d'assets contient des instances au niveau de précision du capteur, vous ne pourrez pas associer les enregistrements aux instances de métadonnées de ce bucket. Vous avez plutôt besoin d'un bucket contenant des instances avec une précision au niveau de la machine.

Modélisation des enregistrements

Lorsque vous modélisez des métadonnées, vous devez vous poser deux questions clés :

1. Quels types de contenus créer ?
2. Comment les types doivent-ils être configurés ?

Types de modélisation

Les types décrivent des enregistrements sémantiquement et structurellement similaires que vous souhaitez stocker ensemble et décrire avec un ensemble commun de métadonnées, et pour lesquels vous souhaitez établir une contrainte commune sur le champ de données.

Dans cette optique, les types doivent capturer les enregistrements au même niveau de précision (niveau de détail). En général, cela signifie structurer les types autour d'un processus de fabrication, d'une opération ou d'un ensemble d'actions. Par exemple, vous pouvez créer un type pour les enregistrements "machine-state" et un autre pour les "sensor-readings".

Nous vous recommandons également de conserver les données au niveau le plus atomique et de ne pas les préagréger avant de les envoyer à MDE. Vous bénéficiez ainsi d'une flexibilité maximale pour vos requêtes, car vous pouvez créer n'importe quel agrégat à partir de données atomiques.

Types de configurations

Voici les principaux éléments à prendre en compte lors de la configuration des types :

1. Quels buckets de métadonnées doivent décrire les enregistrements d'un type ? Sont-ils obligatoires ou facultatifs ?
2. Quel doit être le schéma du champ de données ?

Configuration des métadonnées pour les types

Vous pouvez associer des versions de bucket de métadonnées à des types. Associer une version de bucket à un type implique que les enregistrements de ce type peuvent ou doivent (selon la valeur du champ required de l'association) être associés à des instances de métadonnées de la version de bucket donnée au moment de l'exécution.

Pour déterminer les buckets à associer à un type et si l'association doit être classée comme required, vous devez tenir compte de plusieurs éléments. Vous devez tenir compte des exigences de contextualisation de vos consommateurs de données, du contexte que vous recevez de la périphérie, de la qualité des données et de l'accès aux données d'origine si les sources de données périphériques ne fournissent pas le contexte requis.

Définir l'indicateur required sur une association de bucket de métadonnées améliorera la cohérence de vos données. Toutefois, vous devrez également réfléchir à la manière de gérer les cas où la périphérie ne parvient pas à fournir des métadonnées ou lorsqu'une instance de métadonnées pour une clé naturelle n'a pas encore été créée. Dans ce cas, vous pouvez laisser MDE rejeter le message et le déplacer vers une file d'attente de messages non distribués. Vous pouvez également créer une instance de métadonnées Not Available générique dans votre bucket pour y associer les enregistrements si un lien vers une instance contextualisée complète ne peut pas être créé.

Configuration des champs de données pour les types

La configuration du champ de données sur DISCRETE_DATA_SERIES et CONTINUOUS_DATA_SERIES vous permet d'obtenir une structure d'objet cohérente dans le champ de données. Lorsque vous définissez le champ de données, vous devez profiler vos données sources et vous assurer que les analyseurs sont en mesure de générer des enregistrements proto qui sont validés par rapport au schéma défini.