Warum ScryLab intern auf HDF5 setzt – und MDF nur liest

Eines der ersten Dinge, die ich bei der Entwicklung von ScryLab klären musste, war die Frage nach dem internen Dateiformat. Die Entscheidung klingt erstmal technisch und trocken, hat aber massive Auswirkungen darauf, wie sich das Programm im Alltag anfühlt – beim Laden großer Dateien, beim Hinzufügen von Signalen, beim Navigieren durch lange Messungen.

Hier erkläre ich, wie ich zu dieser Entscheidung gekommen bin.

Das MDF-Problem

MDF – genauer MF4 – ist der Standard in der Fahrzeugmesstechnik. INCA, CANape, fast alle Datenlogger schreiben es. Es liegt also nahe, das auch intern zu verwenden.

Dabei stößt man aber ziemlich schnell auf ein grundlegendes Problem.

MF4 ist ein sequentielles Format. Es ist darauf ausgelegt, während der Messung kontinuierlich beschrieben zu werden – Kanal für Kanal, Block für Block, von vorne nach hinten. Das funktioniert hervorragend für Datenlogger. Für ein Analyse-Tool, das Dateien interaktiv bearbeitet, ist es aber ein ernstes Problem.

So muss man beispielsweise wenn man nachträglich Signale zu einer bestehenden MF4-Datei hinzufügen will, die gesamte Datei neu schreiben. Und um sie neu zu schreiben, muss man sie erst komplett laden. Das klingt vielleicht nach einem Implementierungsdetail, aber es zerstört einen Ansatz, der mir für ScryLab sehr wichtig war: Lazy Loading der Signalliste.

Lazy Loading bedeutet hier, dass beim Öffnen einer Datei zunächst nur die Metadaten gelesen werden – Kanalnamen, Einheiten, Struktur. Die eigentlichen Messwerte bleiben unangetastet, bis ein Signal tatsächlich angezeigt werden soll. Wenn man eine Datei mit 200 Kanälen öffnet, aber nur drei davon anschaut, werden auch nur diese drei geladen.

Mit MDF als Schreibformat ist das nicht umsetzbar. Also habe ich MDF auf rein lesende Unterstützung reduziert – was für die Kompatibilität mit bestehenden Messketten vollkommen ausreicht – und nach einer besseren Alternative gesucht.

Warum HDF5

HDF5 ist kein spezialisiertes Messformat, sondern ein allgemeines wissenschaftlich-technisches Dateiformat. Es wird unter anderem in der Klimaforschung, der Teilchenphysik und maschinellem Lernen eingesetzt. Das klingt weit weg von Fahrzeugtests und klassischen Ingenieurstätigkeiten, hat aber einen entscheidenden Vorteil: Das Format ist auf genau die Operationen hin optimiert, die für ScryLab relevant sind.

HDF5-Dateien bestehen intern aus Datasets, die in Chunks aufgeteilt gespeichert werden. Das erlaubt wahlfreien Zugriff: Ich kann einen einzelnen Kanal lesen, ohne die restliche Datei auch nur anzufassen – die Grundlage dafür, dass ScryLab Signale nur bei Bedarf lädt. Datasets lassen sich außerdem nachträglich vergrößern, ohne die Datei komplett neu zu schreiben, was HDF5 zum echten Schreibformat macht. Die hierarchische Struktur – Daten organisiert wie in einem Verzeichnisbaum – passt dabei gut zu Messungen mit vielen Kanälen und unterschiedlichen Abtastraten. Chunkweise Kompression unterstützt das Format ebenfalls; ich verzichte aktuell darauf zugunsten maximaler I/O-Geschwindigkeit, aber die Option bleibt offen.

Was das für die Anwendung bedeutet

Wenn man in ScryLab eine Datei öffnet, wird nichts vorgeladen. Die Signalliste erscheint sofort, weil nur die Metadaten gelesen werden. Erst wenn ein Signal in den Plot gezogen wird, lädt ScryLab die tatsächlichen Werte dieses Kanals.

Der entscheidende Unterschied zu MDF liegt nicht im Lesen, sondern im Schreiben: Neue Signale lassen sich in HDF5 direkt anhängen. Bei MDF würde jede Änderung bedeuten, die komplette Datei neu zu schreiben – mit allem, was darin steckt.

Die meisten Daten, die ich in der Praxis sehe, liegen als MDF vor – das bleibt die Realität im Automotive-Bereich. Deshalb kann ScryLab MF4 und MF3 lesen. MDF-Dateien bleiben dabei als read-only Source bestehen; wer Signale hinzufügen oder bearbeiten möchte, legt eine neue HDF5-Datei an.

CSV-Import ist ebenfalls geplant, nach dem gleichen Prinzip.