Modelldatensätze und ‑metadaten

In diesem Leitfaden wird beschrieben, wie Sie Datensätze und Metadaten in Manufacturing Data Engine (MDE) modellieren.

In Datensätzen werden Fakten zum Herstellungsprozess erfasst, z. B. Sensormesswerte und Ereignisse. Metadaten helfen, diese Fakten in den Kontext zu setzen und nach Metadatenattributen zu segmentieren. Metadaten dienen auch als Quelle für Originaldaten von Fertigungsunternehmen.

Wenn Sie die vollständige MDE-Suite (MDE in Kombination mit Manufacturing Connect (MC)) verwenden, können Sie diesen Abschnitt zur Datenmodellierung überspringen, da MDE ein Paket für den schnellen Einstieg bietet. Wenn Sie jedoch andere Datenquellen einbinden, sollten Sie sich die Dokumentation ansehen.

Allgemeine Empfehlungen

Bevor Sie mit der Metadatenmodellierung beginnen, sollten Sie Folgendes wissen:

• Die Anforderungen nachgelagerter Nutzer an die Datennutzung. Dazu gehört, dass Sie wissen, welche Daten sie benötigen und wie sie diese verwenden möchten. Dazu können Sie sich mit den Downstream-Nutzern treffen und sie nach ihren Zielen, Leistungskennzahlen (KPIs), Anwendungsfällen, Analyseanforderungen und Datenqualitätsstandards fragen.
• Die Realität der zugrunde liegenden Quelldaten: Dazu gehört, die Qualität der Daten, die Datenstruktur und die Datenherkunft zu verstehen. Dazu können Sie sich mit Experten für das Quellsystem treffen und eine allgemeine Datenprofilerstellung durchführen.
• Anforderungen an die technische Datenintegration Dazu gehört, dass Sie wissen, welche Datenintegrationsschnittstellen MDE unterstützen muss und welche technischen Anforderungen eingehalten werden müssen, einschließlich der Namenskonventionen.

Im Folgenden finden Sie einige konkrete Maßnahmen, die Sie ergreifen können, um die Anforderungen von Downstream-Nutzern zu verstehen:

• Mit Downstream-Nutzern sprechen, um ihre Ziele zu verstehen:
  • Was möchten sie mit den Daten erreichen?
  • Welche KPIs werden verwendet?
• Nachgeschaltete Nutzer nach ihren Anwendungsfällen fragen:
  • Wie möchten sie die Daten verwenden?
  • Welche Berichte möchten sie erstellen?
  • Welche Analysen möchten sie durchführen?
• Analyseanforderungen von Downstream-Nutzern verstehen:
  • Welche Art von Daten müssen sie analysieren?
  • Wie oft müssen sie die Daten analysieren?
• Nachgeschaltete Nutzer nach ihren Datenqualitätsstandards fragen:
  • Welche Datenqualität ist für sie akzeptabel?
  • Welche Schritte müssen unternommen werden, damit die Daten den Standards entsprechen?

Hier sind einige konkrete Maßnahmen, die Sie ergreifen können, um die Realität der zugrunde liegenden Quelldaten zu verstehen:

• Experten für Quellsysteme treffen:
  • Wie ist die Qualität der Daten in den Quellsystemen?
  • Was ist die Datenstruktur?
  • Was ist die Datenherkunft?
• Übersichtliches Datenprofiling durchführen:
  • So können Sie potenzielle Probleme mit den Daten erkennen, z. B. fehlende Werte, doppelte Datensätze oder ungültige Datentypen.

Metadatenmodellierung

Bei der Modellierung von Metadaten müssen Sie drei wichtige Fragen beantworten:

1. Welche Metadaten sollten als eingebettete Metadaten und welche als Cloud-Metadaten behandelt werden?
2. Welche Buckets müssen für Cloud-Metadaten erstellt werden?
3. Wie sollte das Schema für Cloud-Metadaten-Buckets aussehen?

Entscheidung zwischen eingebetteten und Cloud-Metadaten

Das wichtigste Entscheidungskriterium dafür, ob Kontextinformationen als eingebettete Metadaten oder Cloud-Metadaten modelliert werden sollten, ist die Änderungsgeschwindigkeit.

Eingebettete Metadaten eignen sich am besten für Metadaten, die sich schnell ändern. Dazu gehören Metadaten wie Transaktions-IDs oder automatisch inkrementierte Zähler.

Cloud-Metadaten eignen sich dagegen am besten für Metadaten, die sich langsamer ändern, z. B. Asset-Metadaten. MDE verfolgt den Verlauf von Metadateninstanzen pro Bucket und schreibt diese Metadaten in Senken, die sie unterstützen, z. B. BigQuery. So können Sie den Verlauf von Metadateninstanzen pro natürlichen Schlüssel untersuchen. Außerdem können Business Intelligence-Tools (BI) wie Looker eine eindeutige Liste von Attributwerten abrufen, ohne die gesamte Datensatz-Tabelle durchlaufen zu müssen.

Cloud-Metadaten-Buckets modellieren

Buckets bilden einen Kontextbereich ab. Eine Implementierung von ISA-95-Asset-Hierarchien bildet beispielsweise die physische Asset-Hierarchie eines Produktionsunternehmens ab. Sie sollten Metadaten-Buckets entlang der Grenzen der kontextbezogenen Domains modellieren. Sie können beispielsweise den Asset-Kontext (wie er durch eine ISA-95-Implementierung ausgedrückt wird) in einem asset-Bucket und den Maschinenstatus in einem machine-status-Bucket modellieren.

Sie sollten auch überlegen, ob Sie ein Tag oder eine beliebige Gruppe von Datensätzen in einen Kontext setzen müssen.

Tag-Buckets sollten für tagbezogene Metadaten und Datensatz-Buckets für alle anderen Arten von Metadaten ausgewählt werden.

Es ist im Allgemeinen ratsam, hierarchische Domänenmetadaten im selben Bucket zu modellieren. Beispiel: Attribute der Maschine, zu der das Tag gehört (z. B. der Hersteller eines in der Maschine verbauten Sensors), könnten in zwei separaten Buckets (Tag-Bucket und Maschinen-Bucket) modelliert werden. Es ist jedoch in der Regel besser, solche hierarchischen Beziehungen in einem einzelnen Bucket zu modellieren.

Ein guter Grund, eine Hierarchie in mehrere separate Dimensionen aufzuteilen, ist, Datensätze mit Metadaten auf verschiedenen Detaillierungsgraden zu verknüpfen. Wenn Sie beispielsweise zwei verschiedene Datenquellen einbinden, von denen eine Daten auf Sensorebene und die andere auf Maschinenebene sendet, sollten Sie die maschinenspezifischen Daten in einem eigenen Bucket speichern.

Schema für Cloud-Metadaten-Bucket konfigurieren

Das Schema eines Buckets bestimmt die zulässige Struktur von Metadateninstanzen in einem Bucket. Schemas sind wichtig für die Datenqualität. Außerdem können Sie damit definieren, welche Felder verwendet werden können oder müssen, um eine Einheit zu beschreiben, die von einem bestimmten Bucket modelliert wird. Welche Felder Sie in einem Bucket zulassen oder benötigen, hängt weitgehend von den Daten ab, die von Ihren Quellen bereitgestellt werden, und von der Strategie, die Sie für die Bucket-Bevölkerung und die Verknüpfung von Datensätzen auswählen.

Wenn Sie Metadaten-Buckets dynamisch am Edge ausfüllen möchten, sollten Sie beim Definieren eines Schemas vor allem die Verfügbarkeit von Metadaten in den Quellnachrichten berücksichtigen. Außerdem sollten Sie die Datenkonformität und die einfache Aufnahme berücksichtigen. Je spezifischer Ihre Metadaten-Bucket-Schemas sind und je mehr Felder als erforderlich gekennzeichnet sind, desto einheitlicher sind die resultierenden Metadateninstanzen. Dadurch steigen jedoch auch die Anforderungen an den Parser, um strukturelle Unterschiede zwischen Nachrichten zu beheben.

Je allgemeiner Ihre Bucket-Schemas sind (z. B. wenn Sie angeben, dass eine Metadateneigenschaft ein beliebiges „Objekt“ sein kann, anstatt bestimmte Objekteigenschaften zu definieren), desto geringer sind die Anforderungen an die Metadatentransformation und -harmonisierung im Parser. Dies kann jedoch auf Kosten der Konsistenz und Konformität der Metadaten gehen.

Ein weiterer wichtiger Aspekt beim Entwerfen eines Bucket-Schemas ist die Granularität des Buckets. Wenn Sie Metadateninstanzen über die API erstellen, achten Sie darauf, dass der natürliche Schlüssel nicht detaillierter oder gröber ist als die Daten, die Sie vom Edge erwarten. Wenn Sie beispielsweise Statusereignisse vom Edge auf Maschinenebene empfangen, Ihr Asset-Bucket jedoch Instanzen auf Sensorebene enthält, können Sie keine Datensätze mit Metadateninstanzen in diesem Bucket verknüpfen. Stattdessen benötigen Sie einen Bucket, der Instanzen auf Maschinenebene enthält.

Modellierung von Datensätzen

Bei der Modellierung von Metadaten müssen Sie zwei wichtige Fragen beantworten:

1. Welche Typen sollen erstellt werden?
2. Wie sollten die Typen konfiguriert werden?

Modellierungstypen

Typen beschreiben semantisch und strukturell ähnliche Datensätze, die Sie zusammen speichern und mit einem gemeinsamen Satz von Metadaten beschreiben möchten und für die Sie eine gemeinsame Einschränkung für das Datenfeld festlegen möchten.

Daher sollten Typen Datensätze mit demselben Detaillierungsgrad erfassen. In der Regel bedeutet das, dass Typen um einen Fertigungsprozess, einen Vorgang oder eine Reihe von Aktionen herum strukturiert werden. Sie können beispielsweise einen Typ für „machine-state“-Datensätze und einen anderen für „sensor-readings“ erstellen.

Wir empfehlen außerdem, Daten auf der atomarsten Ebene beizubehalten und darauf zu verzichten, Daten vor dem Senden an MDE vorab zu aggregieren. So profitieren Sie von der größten Flexibilität bei Abfragen, da Sie jedes Aggregat aus atomaren Daten erstellen können.

Konfigurationen für Typen

Bei der Konfiguration von Typen sind folgende wichtige Aspekte zu berücksichtigen:

1. Welche Metadaten-Buckets sollten Datensätze eines Typs beschreiben? Sind sie erforderlich oder optional?
2. Welches Schema sollte das Datenfeld haben?

Metadatenkonfiguration für Typen

Sie können Metadaten-Bucket-Versionen Typen zuordnen. Wenn eine Bucket-Version einem Typ zugeordnet wird, bedeutet das, dass Datensätze dieses Typs zur Laufzeit mit Metadateninstanzen aus der angegebenen Bucket-Version verknüpft werden können oder müssen (abhängig vom Wert des Felds required in der Zuordnung).

Die Entscheidung, welche Buckets einem Typ zugeordnet werden sollen und ob die Zuordnung als required klassifiziert werden soll, hängt von mehreren Faktoren ab. Berücksichtigen Sie die Anforderungen an die Kontextualisierung Ihrer Datennutzer, den Kontext, den Sie vom Edge erhalten, die Datenqualität sowie den Zugriff auf Originaldaten, wenn Edge-Datenquellen nicht den erforderlichen Kontext liefern.

Wenn Sie das Flag required für eine Metadaten-Bucket-Verknüpfung festlegen, wird die Konsistenz Ihrer Daten verbessert. Sie müssen jedoch auch überlegen, wie Sie Fälle behandeln, in denen der Edge keine Metadaten liefert oder noch keine Metadateninstanz für einen natürlichen Schlüssel erstellt wurde. In solchen Fällen können Sie die Nachricht von MDE ablehnen und in eine Warteschlange für unzustellbare Nachrichten verschieben lassen. Alternativ können Sie in Ihrem Bucket eine generische Not Available-Metadateninstanz erstellen, um Datensätze damit zu verknüpfen, wenn kein Link zu einer vollständig kontextualisierten Instanz erstellt werden kann.

Konfiguration von Datenfeldern für Typen

Wenn Sie das Datenfeld in DISCRETE_DATA_SERIES und CONTINUOUS_DATA_SERIES konfigurieren, erhalten Sie eine einheitliche Objektstruktur im Datenfeld. Beim Definieren des Datenfelds sollten Sie Ihre Quelldaten analysieren und darauf achten, dass Parser Proto-Datensätze generieren können, die anhand des definierten Schemas validiert werden.