predictive-maintenance

German Version

Datenbankmodell für Maschinelles Lernen von Betriebsdaten bei Fahrzeugen

Ein Datenbankmodell für das maschinelle Lernen von Betriebsdaten bei Fahrzeugen sollte in der Lage sein, große Mengen an Sensordaten effizient zu speichern und zu verarbeiten. Es muss zudem eine flexible Struktur bieten, um Daten für unterschiedliche Analyse- und ML-Zwecke bereitzustellen. Hier ist ein Überblick darüber, wie ein solches Modell aufgebaut sein könnte:

1. Datenbanktyp

• Relationales Datenbanksystem (RDBMS): Für strukturierte Daten mit klar definierten Beziehungen, z. B. Fahrzeugdaten, Wartungshistorien oder Benutzerdaten.
• NoSQL-Datenbank: Für unstrukturierte oder semi-strukturierte Daten, wie Sensordaten, die in Echtzeit gesammelt werden. Beispiele sind dokumentenorientierte Datenbanken (z. B. MongoDB) oder Zeitreihendatenbanken (z. B. InfluxDB).

2. Tabellen und Strukturen für ein relationales Modell

Hier ist eine mögliche Struktur für ein relationales Datenbankmodell:

1. Fahrzeuge

• vehicle_id (Primary Key): Eindeutige Kennung des Fahrzeugs.
• vehicle_type: Typ des Fahrzeugs (z. B. LKW, PKW, Bus).
• model: Modellbezeichnung des Fahrzeugs.
• manufacturer: Hersteller des Fahrzeugs.
• year_of_manufacture: Baujahr.
• last_service_date: Datum der letzten Wartung.

2. Sensoren

• sensor_id (Primary Key): Eindeutige Kennung des Sensors.
• sensor_type: Typ des Sensors (z. B. Temperatur, Vibration, GPS).
• vehicle_id (Foreign Key): Verknüpfung mit einem Fahrzeug.
• installation_date: Installationsdatum des Sensors.

3. Sensordaten (Zeitreihendaten)

• data_id (Primary Key): Eindeutige ID für die Sensordaten.
• sensor_id (Foreign Key): Verknüpfung mit einem Sensor.
• timestamp: Zeitpunkt der Datenaufzeichnung.
• value: Erfasster Wert (numerisch).
• unit: Einheit des Werts (z. B. °C, RPM).

4. Wartungshistorie

• maintenance_id (Primary Key): Eindeutige ID für einen Wartungseintrag.
• vehicle_id (Foreign Key): Verknüpfung mit einem Fahrzeug.
• date: Datum der Wartung.
• maintenance_type: Art der Wartung (z. B. Inspektion, Reparatur).
• details: Beschreibung der durchgeführten Arbeiten.
• cost: Kosten der Wartung.

5. ML-Modelldaten (optional)

• model_id (Primary Key): Eindeutige ID für das ML-Modell.
• model_name: Name des Modells.
• training_data_start: Startdatum des Trainingsdatensatzes.
• training_data_end: Enddatum des Trainingsdatensatzes.
• model_accuracy: Genauigkeit des Modells.
• last_update: Datum der letzten Aktualisierung.

3. Beziehung zwischen Tabellen

• Fahrzeuge zu Sensoren: Eins-zu-Viele-Beziehung. Ein Fahrzeug kann mehrere Sensoren haben.
• Sensoren zu Sensordaten: Eins-zu-Viele-Beziehung. Ein Sensor kann viele Datenpunkte erfassen.
• Fahrzeuge zu Wartungshistorie: Eins-zu-Viele-Beziehung. Ein Fahrzeug kann mehrere Wartungseinträge haben.

4. NoSQL-Datenbankmodell (Dokumentenorientierte Struktur)

Ein dokumentenbasiertes Modell für Sensordaten könnte wie folgt aussehen:

Beispiel-Dokument für Sensordaten (in JSON):

{
  "vehicle_id": "12345",
  "sensor_id": "sensor_01",
  "timestamp": "2024-11-09T12:34:56Z",
  "sensor_type": "temperature",
  "value": 75.5,
  "unit": "Celsius"
}

Beispiel-Dokument für Fahrzeuge:

{
  "vehicle_id": "12345",
  "vehicle_type": "LKW",
  "model": "TruckModelX",
  "manufacturer": "TruckCo",
  "year_of_manufacture": 2018,
  "sensors": [
    {
      "sensor_id": "sensor_01",
      "sensor_type": "temperature",
      "installation_date": "2019-02-15"
    },
    {
      "sensor_id": "sensor_02",
      "sensor_type": "vibration",
      "installation_date": "2019-02-15"
    }
  ]
}

5. Erweiterungen und Optimierungen

• Indexierung: Für häufig abgefragte Felder, z. B. timestamp in der Sensordaten-Tabelle.
• Partitionierung: Für große Zeitreihendaten (nach Datum).
• Datenarchivierung: Ältere Daten können in separaten Archiven abgelegt werden, um die Performance der aktiven Datenbank zu verbessern.
• Echtzeit-Datenstromverarbeitung: Bei Bedarf können Streaming-Lösungen wie Apache Kafka oder InfluxDB zur Verarbeitung großer Datenmengen in Echtzeit eingesetzt werden.

Das Modell kann flexibel gestaltet werden, um die Anforderungen spezifischer Transportunternehmen zu erfüllen und gleichzeitig eine Grundlage für maschinelles Lernen durch Bereitstellung sauberer, konsistenter Daten zu schaffen.

Zur API Schnittstelle

API_INTERFACE_FLEET.md

Zum MongoDB NoSQL-Datenbankmodell

MONGODB_FLEET.md

Lizenz

Autor: Jörg Harzmann

Dieser Inhalt ist unter einer CC BY-NC Lizenz veröffentlicht.