Der Datenexport ist die Tür nach draußen

Der Knopf „Exportieren“ in der Menüleiste sieht nach einer beruhigenden Nachricht aus: Ein Klick, und die Daten lassen sich angeblich mitnehmen. Doch als Junior-Chefin Carolin und Instandhaltungsmeister Klaus die exportierte Datei auf einem Testrechner öffnen, folgt die Ernüchterung: Zehntausend Zeilen Zahlenkolonnen ohne Spaltenüberschriften, verknüpfte PDF-Wartungsprotokolle fehlen komplett, und die lebenswichtigen Werkzeugkorrekturtabellen sind als unlesbare binäre Blobs kodiert.

Ein Datenexport ist der Notausgang aus einem Softwaresystem. Wie breit und begehbar diese Tür wirklich ist, erfährt ein Betrieb erst, wenn er den Ernstfall vor Vertragsunterschrift probt. Wer den Export erst am Tag der Kündigung testet, erlebt das böse Erwachen oft zu spät: Der Anbieter verlangt fünfstellige Dienstleistungshonorare für eine lesbare Bereitstellung, oder historische Prozessdaten gehen unwiederbringlich verloren.

Der Testlauf vor der Unterschrift

In der Praxis eines mittelständischen Fertigungsbetriebs ging es um die Ablösung eines proprietären Wartungs- und Betriebsdatenerfassungssystems (BDE). Bevor Carolin den Vertrag mit einem neuen Anbieter unterzeichnete, verlangte sie einen vollständigen Datenexporttest:

„Ein Softwarehaus kann die Lizenzgebühren nach zwei Jahren beliebig anziehen, wenn es weiß, dass ein Wechsel den Betrieb lähmen würde“, erklärt Carolin. „Unser Know-how steckt in den Werkzeughistorien: Welcher Fräskopf hielt bei welcher Schnittgeschwindigkeit wie viele Stunden? Wann traten an welchem Spindellager Schwingungen auf? Wenn wir diese Zeitreihen nicht in einem offenen, relationalen Format besitzen, sind wir erpressbar.“

Klaus legte dafür einen definierten Testdatensatz an:

• Zehn Werkzeugmaschinen mit spezifischen Kenndaten (Baujahr, Steuerungstyp Heidenhain/Siemens, Seriennummer).
• Zwanzig Wartungsaufträge mit angehängten Prüfprotokollen und Störungsmeldungen.
• Zeitreihendaten über Spindellaufzeiten und Schaltzyklen mit Zeitstempeln im ISO-8601-Format.

Der Test prüfte, was der Export daraus macht. Das Ergebnis war aufschlussreich: Die tabellarischen Textdaten ließen sich als CSV exportieren, die PDF-Anhänge wurden jedoch in einem proprietären Cloud-Speicher belassen, zu dem nach Vertragsende der Zugriff erloschen wäre. Erst nach zähen Nachverhandlungen rüstete der Anbieter einen standardisierten ZIP-Export mit strukturierter JSON-Metadatei nach.

Tabellenwerte versus semantische Zusammenhänge

Ein Textformat wie CSV (Comma-Separated Values) nach RFC 4180 macht Tabellenwerte zwar prinzipiell systemunabhängig lesbar. Es garantiert jedoch nicht, dass die semantische Bedeutung der Daten erhalten bleibt.

Eine Zahl wie „14,2“ in Spalte 7 sagt ohne Kontext nichts aus: Handelt es sich um Minuten, Millimeter, Ampere oder ein Drehmoment? Fehlt eine maschinenlesbare Schemadefinition, muss ein neuer Softwareintegrator mühsam erraten, was die Felder bedeuten.

Deshalb gehört zu einem echten Datenexport:

1. Vollständige Feld- und Typdokumentation: Klare Definitionen von Einheiten, Zeitzonen und Status-Codes.
2. Erhalt der Relationen: Primär- und Fremdschlüssel müssen erhalten bleiben, damit Wartungseinsätze eindeutig der jeweiligen Maschine zugeordnet werden können.
3. Offene Datenbankstandards: Ein Dump in einer relationalen Standard-Syntax (z. B. PostgreSQL-SQL-Dump) oder strukturierte JSON-/Parquet-Dateien sind einem unstrukturierten Tabellenblatt vorzuziehen.

Lokale Persistenz mit PostgreSQL und TimescaleDB

Instandhaltungsmeister Klaus setzt für die langfristige Datenhaltung auf dem betriebseigenen Schaltschrank-Server auf bewährte Open-Source-Technologie:

„Wir lassen unsere Maschinentelemetrie nicht in einer fremden Cloud verrotten“, sagt Klaus. „Auf unserem Debian-Server läuft eine relationale PostgreSQL-Datenbank mit der TimescaleDB-Erweiterung für Zeitreihendaten. Die Daten gehören physisch uns, liegen auf einer gespiegelten SSD im Schaltschrank und werden täglich verschlüsselt auf unser internes Backup-Band gesichert. Wenn wir in fünf Jahren ein neues Visualisierungstool wollen, binden wir einfach Grafana oder eine andere Software an dieselbe SQL-Schnittstelle an. Wir müssen niemanden um Erlaubnis bitten, an unsere eigenen Daten heranzukommen.“

Datensouveränität erfordert Pflegekompetenz

Wahre Unabhängigkeit bedeutet allerdings auch eigene Verantwortung. Freie Software und offene Formate nehmen einem Betrieb die Wartungsarbeit nicht ab. Ein PostgreSQL-Server aktualisiert sich nicht magisch von selbst, und defekte Festplatten müssen überwacht werden.

Ein Betrieb muss daher ehrlich klären: Besitzen wir im eigenen Haus oder über einen verlässlichen regionalen IT-Partner die Kompetenz, Datenstrukturen zu pflegen, Backups zu testen und Schnittstellen zu warten? Kann bei Ausfall eines Administrators eine andere Fachkraft die Systeme bedienen?

Ein funktionierender Datenexport ist die wichtigste Versicherung gegen technologische Erpressbarkeit. Ein Betrieb muss nicht jedes Jahr seine Software wechseln. Aber die Gewissheit, dass die Tür nach draußen offensteht und die eigenen Produktionsdaten jederzeit auf eigener Hardware weiterverwendet werden können, verändert jede Verhandlung mit Softwareanbietern von Grund auf.

Quellen und Hinweise

IETF: RFC 4180, „Common Format and MIME Type for Comma-Separated Values (CSV) Files“, Oktober 2005. Standard für tabellarische Textdaten.

Free Software Foundation / GNU-Projekt: „Freie Software. Was ist das?“, Definition der vier wesentlichen Softwarefreiheiten (Verwenden, Verstehen, Verbreiten, Verbessern).

Fachbeitrag von Dr. Jan-Frederik Menzel zur Evaluierung industrieller Schnittstellen, Datenportabilität und relationalen Datenbankarchitekturen (PostgreSQL/TimescaleDB) im Maschinen- und Anlagenbau.

Rechtlicher Hinweis / Haftungsausschluss: Die Beiträge, Fallberichte, Interviews und Erläuterungen auf FreieTech dienen ausschließlich Informations-, Diskussions- und Bildungszwecken. Sie stellen keine individuelle Rechts-, Steuer-, Anlage-, Sicherheits- oder Unternehmensberatung dar und begründen kein vertragliches Beratungsverhältnis. FreieTech steht in keiner geschäftlichen oder gesellschaftsrechtlichen Verbindung zu den im Kontext genannten Unternehmen, Marken oder Behörden. Konkrete betriebliche Umsetzungen, Sicherheitsprüfungen und technische Nachrüstungen erfordern stets eine fachkundige Prüfung des jeweiligen Einzelfalls vor Ort.