Von Sensoren bis CAD: Datenmodellierung zur Vereinheitlichung von Engineering-Daten in Directus

Moderne Ingenieursunternehmen arbeiten in einer datenreichen, aber fragmentierten Landschaft. Sensorströme von IoT-Geräten, parametrischen CAD-Modellen, Enterprise Resource Planning (ERP)-Systemen und Labortestdatenbanken erzeugen jeweils Daten in verschiedenen Formaten, in verschiedenen Kadenzen und mit unterschiedlichen semantischen Bedeutungen. Die Integration dieser Quellen in ein einziges, abfragbares Ganzes ist die Grundlage für vorausschauende Wartung, digitale Zwillinge und Verbesserungen des geschlossenen Entwurfs. Datenmodellierung bietet den Entwurf für diese Integration, und mit einer flexiblen Plattform wie Directus können Ingenieure diesen Entwurf in einen funktionierenden, API-gesteuerten Datenknoten ohne schwere benutzerdefinierte Kodierung übersetzen.

In diesem Leitfaden wird erläutert, wie Sie Datenmodellierung speziell auf die technische Datenintegration anwenden können, wobei Directus als zentrale Datenschicht verwendet wird. Wir werden die Arten von Modellen, die Sie benötigen, einen schrittweisen Implementierungsworkflow und praktische Beispiele behandeln, die über die Theorie hinaus in produktionsfähige Muster gehen.

Was ist Datenmodellierung (und warum es für Engineering-Daten wichtig ist)

Datenmodellierung ist der Prozess der Definition eines Schemas, das die Struktur, Beziehungen, Einschränkungen und Semantik der Daten beschreibt, auf die sich Ihr Unternehmen stützt. Es beantwortet Fragen wie: Wie hängt die Sensorlesung einer Windkraftanlage mit der Seriennummer der Turbine zusammen? Welche Attribute einer CAD-Baugruppe müssen vorhanden sein, bevor eine Bestellung generiert werden kann? Ohne ein Modell wird die Integration zu Punkt-zu-Punkt-Spaghetti — ein Python-Skript für ERP, ein anderes für SCADA und keine einzige Quelle der Wahrheit.

Drei Abstraktionsebenen sind Standard in der technischen Datenmodellierung:

Konzeptdatenmodell

Auf dieser hohen Ebene identifizieren Sie die wichtigsten Geschäftseinheiten (z. B. „Asset“, „Measurement“, „Maintenance Log“, „Component“) und deren Kernbeziehungen – aber Sie geben keine Attribute oder Schlüssel an. Ein Ingenieurmanager und ein Datenarchitekt können besprechen, ob eine „Measurement“ mit einem „Asset“ oder mit einem „Asset“ und einem „Sensor“ verknüpft ist. Dieses Modell wird oft als Entity-Relationship-Diagramm (ERD) mit einfachen Boxen und Zeilen gezeichnet.

Logisches Datenmodell

Hier wird jedes Attribut, jeder Datentyp und jede Beziehung angegeben. Das logische Modell für "Measurement" würde beispielsweise einen Zeitstempel (DATETIME), einen Wert (FLOAT), eine Einheit (TEXT) und einen Fremdschlüssel für "Sensor" enthalten. Einschränkungen wie "value cannot be negative" oder "timestamp must be in UTC" werden in diese Schicht geschrieben. Das logische Modell ist unabhängig von einer bestimmten Datenbank-Engine.

Physikalisches Datenmodell

Schließlich bildet das physikalische Modell die logischen Definitionen den tatsächlichen Datenbankobjekten zu: Tabellen, Spalten, Indizes, Partitionen. In Directus übersetzt dies Collections (Tabellen), Fields (Spalten) und Relationships (Fremdschlüssel). Das physikalische Modell berücksichtigt auch die Leistung, beispielsweise das Hinzufügen eines zusammengesetzten Index auf (sensor id, timestamp), um Zeitreihenabfragen zu beschleunigen.

Die Stärke von Directus liegt darin, dass es die Lücke zwischen logischer und physischer Modellierung schließt: Sie können ein logisches Modell direkt im Data Studio der App definieren, und Directus erstellt automatisch das physische Datenbankschema (PostgreSQL, MySQL, SQLite usw.).

Vorteile der Datenmodellierung in der Engineering Integration

Wenn Sie vor der Integration modellieren, erhalten Sie konkrete Vorteile, die die häufigsten Schwachstellen in Multi-Source-Engineering-Projekten beseitigen.

Semantische Konsistenz über Disziplinen hinweg

Maschinenbauer könnten ein Teil als „Bracket“ bezeichnen, während die Beschaffung es als „Inventarelement #447“ bezeichnet. Ein logisches Modell definiert Aliase, zulässige Werte und einen kanonischen Namen, so dass jedes System die gleiche Sprache spricht. Directus unterstützt Validierungsregeln und Dropdowns auf Feldebene aus verwandten Sammlungen, um diese Konsistenz zu erzwingen.

Datenqualität am Point of Entry

Durch Modellierung von Einschränkungen – wie etwa erforderliche Felder, eindeutige Schlüssel oder Reichweitenüberprüfungen – stoppen Sie fehlerhafte Daten, bevor sie in das integrierte System gelangen. Beispielsweise kann ein Sensortelemetrie-Endpunkt eine Lesung ohne gültige Geräte-Seriennummer ablehnen, bevor sie gespeichert werden. Directus bietet rollenbasierte Berechtigungen und Feldvalidierungsregeln, die über alle eingehenden Datenpipelines hinweg geteilt werden können.

Vereinfachtes Change Management

Engineering-Umgebungen sind nicht statisch. Neue Sensortypen werden hinzugefügt, Produkte werden aktualisiert und Vorschriften verschieben. Ein gut modelliertes Schema isoliert Änderungen in einem begrenzten Bereich. Durch das Hinzufügen eines neuen Attributs ("Umgebungstemperatur") zur "Measurement"-Sammlung werden bestehende Dashboards oder APIs nicht beschädigt - solange das Modell versioniert ist. Directus speichert eine vollständige Schemahistorie und ermöglicht es Ihnen, Änderungen vor der Veröffentlichung in der Vorschau anzuzeigen.

Automatisiertes Data Mapping und ETL

Wenn Sie ein klares logisches Modell haben, wird die Zuordnung von Quellfeldern zu Zielfeldern zu einer mechanischen Aufgabe, die oft mit ETL-Tools oder Directus Flows automatisiert werden kann. So kann beispielsweise ein CSV aus einem ERP-System mit feldweisen Regeln in die „Part-Sammlung abgebildet werden, und es werden wiederholte Fehlanpassungen (z. B. Inkonsistenzen im Datumsformat) während der Transformation festgestellt.

Schritt-für-Schritt: Aufbau eines Engineering Integrationsmodells in Directus

Gehen wir durch ein konkretes Szenario: Integration von Echtzeit-Vibrationsdaten von drei Windkraftanlagensensoren mit den CAD-Modellmetadaten und der Wartungshistorie der Turbine. Jede Quelle hat ihr eigenes Schema - die Sensor-API gibt JSON wie FLT:0 zurück, während das CAD-System eine XML-Datei mit verschachtelten Komponentenstrukturen exportiert.

1. Datenquellen identifizieren und dokumentieren

Liste jedes System, das den integrierten Datensatz speist oder verbraucht.

  • Sensor API – gibt JSON-Nutzlasten alle 5 Minuten für jede Turbine zurück.
  • PLM (Product Lifecycle Management) – exportiert XML BOM (Materialienbrief) und CAD-Geometrie-Metadaten.
  • CMMS (Computerized Maintenance Management System) – stellt Arbeitsaufträge und Reparaturprotokolle als SQL-Datenbank bereit.

Dokumentieren Sie die Felder, die jede Quelle sendet, die Datentypen und die Aktualisierungshäufigkeit.

2. Konzeption eines konzeptionellen Modells

Definieren Sie die Kerneinheiten und ihre Beziehungen, ohne sich noch um bestimmte Bereiche zu kümmern.

  • TurbineAsset – die physische Turbineneinheit (Seriennummer, Standort, Modell).
  • Komponente – ein Teil (Blade, Getriebe, Generator), der mit einem TurbineAsset verbunden ist.
  • VibrationMeasurement – eine Zeitreihenlesung von einem Sensor, verbunden mit einer Komponente.
  • MaintenanceEvent – eine Reparatur oder Inspektion, die mit einem TurbineAsset und optional mit einer Komponente verbunden ist.

Zeigen Sie, dass ein TurbineAsset viele Komponenten hat und eine Komponente viele Vibrationsmessungen haben kann. Teilen Sie dieses Diagramm mit Domänenexperten - sie erkennen fehlende Entitäten (z. B. "Sensor" selbst als Asset).

3. Erstellen Sie das logische Modell in Directus

Öffnen Sie das Directus Data Studio und erstellen Sie eine Sammlung für jede Entität.

  • timestamp (DateTime Feld, erforderlich)
  • rms velocity (Float-Feld, erforderlich, mit einer Validierungsregel: Wert > 0)
  • component id (Viele-zu-Eins-Beziehung zur Komponente-Sammlung)
  • source sensor (Textfeld, aber betrachten Sie eine Sammlung von vielen zu eins zu Sensor, wenn Sie Sensor-Metadaten verfolgen müssen)

Für Komponente:

  • name (String-Feld)
  • part number (String-Feld, eindeutig)
  • turbine id (Many‐to‐One to TurbineAsset)

Directus erstellt automatisch den vielen-zu-eins-Fremdschlüssel und generiert für jede Sammlung einen REST/GraphQL API-Endpunkt, in diesem Stadium bauen Sie das logische Modell direkt auf der zugrunde liegenden Datenbank (z.B. PostgreSQL) auf.

4. Bauen Sie das physische Modell (Leistungsoptimierungen)

Fügen Sie nun Indizes und Feldeinstellungen hinzu, die die Abfrageleistung beeinflussen. In Directus können Sie ein Feld als „primären Schlüssel (Auto-Increment-Integer oder UUID) festlegen und benutzerdefinierte Indizes über die Datenbankschnittstelle oder durch Ausführen von Roh-SQL im Directus-Kontext hinzufügen.

  • Fügen Sie einen zusammengesetzten Index auf (component id, timestamp) hinzu - dies beschleunigt die häufigste Abfrage: "Alle Messwerte für Getriebe # 3 in den letzten 24 Stunden abrufen."
  • Wenn Sie Millionen von Zeilen erwarten, sollten Sie die Tabelle nach Datum partitionieren. Directus verwaltet die Partitionierung nicht nativ, aber Sie können sie in der zugrunde liegenden Datenbank einrichten, und Directus funktioniert weiterhin mit jeder Partition.

Das physische Modell enthält auch Regeln zur Datenaufbewahrung.Sie können Directus Flows oder ein geplantes Skript verwenden, um Messwerte, die älter als 90 Tage sind, zu bereinigen oder sie auf eine billigere Speicherebene zu archivieren, während das Modell intakt bleibt.

5. Integrieren Sie die Quellen in Directus

Es gibt mehrere Möglichkeiten, Daten von externen Systemen in die von Ihnen definierten Directus-Sammlungen zu laden:

  • Directus Flow — eine No-Code-Automatisierung, die eine externe API aufrufen, JSON transformieren und in Sammlungen schreiben kann. Ein Webhook-Trigger kann Sensor-POST-Anfragen abhören und die Nutzlastfelder abbilden.
  • Directus SDK — schreiben Sie ein Node.js- oder Python-Skript, das sich gegenüber der Directus-API authentifiziert und Datensätze einfügt. Für den PLM XML-Import kann ein Python-Skript das XML analysieren und aufrufen.
  • ETL-Tool — Verbinden Sie ein Tool wie n8n oder Talend mit Directus über seine REST-API. Dies ist nützlich, wenn Sie komplexe Transformationen oder Fehlerbehandlung benötigen.
  • Direkte Datenbank-Synchronisation — Wenn das CMMS auf einer SQL Server-Datenbank läuft, können Sie eine Directus-„Sammlung erstellen, die eigentlich eine Datenbankansicht ist, die die Remote-Tabelle widerspiegelt (mit PostgreSQL Foreign Data Wrappers oder MySQL Federated Engine).

Während der Integrationsphase protokollieren Sie jeden Zuordnungsfehler und überprüfen Sie den Directus Activity Feed, um zu verstehen, warum ein Datensatz abgelehnt wurde (fehlendes Feld, Typabweichung usw.).

6. Validierung und Entwicklung des Modells

Nachdem die Daten fließen, überprüfen Sie, ob Abfragen korrekte Ergebnisse liefern. Führen Sie beispielsweise den integrierten Filter von Directus aus, um alle "VibrationMeasurement"-Datensätze mit zu finden, und verbinden Sie sie mit den - und -Sammlungen. Machen die Ergebnisse technische Sinn? Wenn nicht, passen Sie das logische Modell an - vielleicht sollte ein "Measurement" sowohl mit "Component" als auch mit "Sensor" verknüpft werden, um die Herkunft der Daten zu unterscheiden.

Im Laufe der Zeit werden Sie neue Quellen hinzufügen (z. B. Ölanalyseergebnisse) oder alte Quellen veralten. In Directus können Sie neue Felder zu bestehenden Sammlungen hinzufügen oder neue Sammlungen erstellen, ohne die vorhandenen APIs zu beeinträchtigen - einfach das SDK regenerieren oder die Änderungen in einer OpenAPI-Spezifikation dokumentieren.

Tools und Techniken für Engineering Data Modeling

Während Directus die Ausführungsumgebung ist, profitiert der Datenmodellierungsprozess von spezialisierten Tools.Verwenden Sie die Kombination, die zum Workflow Ihres Teams passt.

Schemaentwurf und Dokumentation

  • dbdiagram.io — exportiere dein logisches Modell als DSL und übersetze es dann manuell in Directus-Sammlungen.
  • Lucidchart oder Draw.io — erstellen Sie konzeptionelle ERDs und teilen Sie sie mit nicht-technischen Stakeholdern, bevor Sie mit dem Directus-Build beginnen.
  • Directus Data Studio kann selbst als lebendes Dokumentationswerkzeug dienen. Aktivieren Sie die Funktion “Display Template”, um verknüpfte Datensätze in einem vom Menschen lesbaren Format anzuzeigen (z. B. “Turbine T-07 – Gearbox”).

ETL und Datenpipelines

  • Directus Flows — integrierte Automatisierung, die Daten ohne zusätzliche Infrastruktur transformieren und laden kann. Unterstützt Webhooks, Zeitplanauslöser und eine Bibliothek von Transformationsoperationen (JSONata, Mathe, String-Operationen).
  • Apache NiFi — ein leistungsfähiges, flussbasiertes Programmierwerkzeug für den Umgang mit komplexen Integrationen mit Retry-Logik und Provenienz-Tracking. Directus’ REST API macht NiFi zu einem hervorragenden Orchestrator.
  • Benutzerdefinierte Skripte (Python, Node.js) – sehr flexibel für Aufgaben wie das Parsen von CAD STEP-Dateien oder die Kommunikation mit industriellen Protokollen (OPC UA, MQTT).

Data Governance und Metadaten

Betrachten Sie die Behandlung des Directus-Schemas selbst als reguliertes Asset. Verwenden Sie Directus’ „Kommentar“ und „Note“ Felder in jeder Sammlung, um Geschäftsdefinitionen, verantwortlichen Eigentümer und Aufbewahrungsrichtlinien zu speichern. Für größere Organisationen kann ein externer Datenkatalog wie Alation oder DataHub verwendet werden, um das Directus-Schema zu indizieren und die Abstammung zu verfolgen.

Best Practices und häufige Fallstricke

Durch die Erfahrung mit Projekten zur technischen Integration entstehen immer wieder mehrere Muster, deren Übernahme erhebliche Nacharbeit erspart.

Best Practices

  • Beginnen Sie mit einem konzeptionellen Modell, nicht mit Feldern. Bestätigen Sie mit Domänenexperten, dass die Entitäten und Beziehungen korrekt sind, bevor Sie in Attributdetails eintauchen.
  • Verwenden Sie UUIDs als Primärschlüssel für Sammlungen, die zusammengeführt oder verschoben werden. Auto-Inkrement-Integer sind fragil, wenn Sie später eine zweite Turbinenfarm integrieren, die bereits eine eigene ID-Sequenz hat.
  • Leverage Directus Revisionen. Ermöglichen Sie Revisionen von Sammlungen, bei denen der Datenverlauf von Bedeutung ist, z. B. das Nachverfolgen von Änderungen der Konfiguration einer Turbine im Laufe der Zeit. Dies ist im Grunde ein in das Modell integrierter Audit-Trail.
  • Modell-Zeitreihendaten explizit. Betten Sie ein JSON-Array von Messwerten nicht in die Component-Sammlung ein. Erstellen Sie eine separate Messsammlung mit einem Fremdschlüssel und einem Zeitstempel.
  • Design für leselastische und schreiblastige Muster separat. Engineering-Dashboards fragen oft die letzten 24 Stunden Sensordaten ab, während der Aufnahmeprozess Tausende von Punkten pro Minute schreibt. Für große Mengen sollten Sie den Directus-Modus "Database" verwenden, um die Anwendungsschicht zu umgehen und direkt in die darunter liegende Tabelle mit gut optimiertem SQL einzufügen.

Häufige Fallstricke

  • Übernormalisierung. Durch die Aufteilung jedes möglichen Attributs in eine separate Sammlung können Abfragen langsam und komplex werden. So ist das Speichern von “MeasurementUnit” als separate Sammlung mit einem einzigen Feld “unit name” in der Regel ein Overkill – ein Textfeld mit Validierungsregeln genügt.
  • Das Ignorieren der Schemaentwicklung. Wenn ein neues Sensormodell ein “peak acceleration”-Feld sendet, das Sie nicht modelliert haben, können die Daten abgelehnt werden oder verloren gehen. Entwerfen Sie Ihre Ingestion-Pipeline so, dass sie entweder unbekannte Felder akzeptiert (und in einem JSON-Feld mit allen Daten gespeichert wird) oder eine Warnung auslösen, wenn sich das Schema ändert.
  • Wenn Felder nicht konsistent benannt werden. Wenn camelCase () mit snake case () über verschiedene Sammlungen hinweg gemischt wird, führt dies zu Verwirrung.
  • Rohdaten von Sensoren enthalten oft Duplikate oder falsch beschriftete Zeitstempel. Legen Sie sie zuerst in eine "Staging" -Sammlung (ohne viele Einschränkungen), führen Sie die Bereinigungs- und Dedup-Logik aus und verschieben Sie die gereinigten Daten dann in die Produktionssammlungen. Directus Flows kann dieses zweistufige Muster orchestrieren.

Realisierung der Integrated Engineering Data Platform

Datenmodellierung ist keine einmalige Designübung – es ist eine fortlaufende Disziplin, die sich an Ihre Engineering-Umgebung anpasst. Durch die Verwendung von Directus als zentraler Datenplattform erhalten Sie die Möglichkeit, das Modell ohne Ausfallzeiten zu iterieren, die integrierten Daten über konsistente REST- und GraphQL-APIs zu entlarven und Ihre Engineering-Teams zu befähigen, Dashboards, digitale Zwillinge und Machine-Learning-Modelle auf einer vertrauenswürdigen Datenbasis zu erstellen.

Das Beispiel der Windkraftanlagenintegration zeigt das universelle Muster: Entitäten identifizieren, Beziehungen definieren, Directus-Sammlungen implementieren, Quellen verbinden und validieren. Wenn Sie diesen Prozess für andere technische Bereiche wiederholen - Automobil, Luft- und Raumfahrt, industrielle Automatisierung - wird das Modell zu einem wiederverwendbaren Asset, das die Integrationszeit von Monaten auf Tage verkürzt.

Beginnen Sie mit der Dokumentation der zehn wichtigsten Entitäten in Ihrem aktuellen Integrationsprojekt. Karte sie in einem konzeptionellen Modell ab, und erstellen Sie diese Sammlungen in Directus. Die API ist in wenigen Minuten fertig und Ihre Daten sprechen schließlich die gleiche Sprache.