Messhistorie und Ausgabedateien

Historien-Pickle

Die Messskripte speichern die jeweilige Measure-Unterklasse, beispielsweise MSC oder TEMCell, als Pickle. Wird dieses Pickle als Eingang einer weiteren Messung verwendet, ergänzt die neue Messung dasselbe Objekt und schreibt eine neue Datei. Damit bleiben vorbereitende Messungen, Referenzdaten, EUT-Messungen und Auswertungen gemeinsam erhalten.

Die typische Kette ist:

vorherige Historie -> neue Messung -> neue Auswertung -> neues Historien-Pickle

Die Eingangsdatei wird nicht als bloßer Datenexport behandelt. Sie enthält auch die für die Interpretation notwendigen Strukturen. Zum Laden aktueller und unterstützter älterer mpylab-Pickles verwenden Anwendungen mpylab.env.Measure.load_pickle_compat.

Die unterstützten Messdatencontainer und ihre Detailreferenzen sind unter Messdatenmodelle zusammengefasst. Das Pickle enthält darüber hinaus Python-internen Zustand; dieser ist nicht automatisch eine stabile Leseschnittstelle.

Gemeinsamer Historienzustand

Alle von Measure abgeleiteten Historien können folgende persistierte Ablaufangaben enthalten:

Gemeinsame Ablaufangaben

Attribut	Typ	Bedeutung
ascmd	str oder None	Lesbare historische Beschreibung des fortzusetzenden Methodenaufrufs. Neue Programmlogik verwendet stattdessen autosave_resume.
autosave_resume	Mapping oder None	Strukturierte Fortsetzungsanweisung mit schema_version, measurement, method, description und parameter_source.
autosave_info	Mapping, falls vorhanden	Messablaufspezifischer Schleifenfortschritt, beispielsweise die zuletzt abgeschlossene Frequenz, Tunerstellung oder Position. Die konkrete Struktur gehört zur jeweiligen Messdatenreferenz.
graph_context_events	Liste von Mappings	Erkannte externe Änderungen am Messgraphen. Ein Ereignis enthält timestamp, requested_context, mismatches und action. action ist "abort" oder nach ausdrücklicher Bedienerfreigabe "reapply".

SearchPaths und Dateinamen können auf die Maschine verweisen, auf der die Messung lief. Sie sind Herkunftsinformation, aber kein portabler Datenpfad. Geöffnete Logdateien, Logger, UI-Adapter und Interaktions-Callbacks werden vor dem Pickeln entfernt und beim Laden neu aufgebaut. Anwendungen dürfen diese Laufzeitobjekte nicht als Teil der Messdatenschnittstelle behandeln.

Messdurchläufe und Messgraph-Snapshots

Eine Description darf mehrere Messdurchläufe enthalten. Das ist beabsichtigt: Der Austausch eines Kabels oder Geräts sowie eine geänderte Korrekturtabelle oder Schaltkonfiguration erzwingen keine neue Description, sofern die Änderung nachvollziehbar bleibt. Neu erfasste Daten verwenden deshalb in jedem betroffenen Rohdaten-Mapping auf Description-Ebene die folgenden gemeinsamen Herkunftsfelder:

Herkunft eines Messdurchlaufs innerhalb einer Description

Key	Typ	Bedeutung
mg	MGraph	Kompatibilitätssicht auf den zuletzt verwendeten Graphen. Er ist nicht der unveränderliche Nachweis früherer Messdurchläufe.
measurement_graph_snapshots	Mapping	Deduplizierte Snapshots, indiziert mit ihrem configuration_digest der Form sha256:....
measurement_acquisitions	Liste von Mappings	Zeitlich geordnete Messdurchläufe. Der Listenindex ist die kompakte Messdurchlauf-ID in den Rohdaten.
active_measurement_acquisition	int, optional	Messdurchlauf, den ein unvollständiges Autosave gerade abbildet. Beim Schließen des Durchlaufs wird dieser Key entfernt.

Ein Eintrag in measurement_acquisitions enthält index, measurement, started_at_utc, finished_at_utc, status, snapshot_id und run_configuration. Beim Fortsetzen können zusätzlich resumed_at_utc oder die Altfallmarkierung legacy_resume hinzukommen. Typische Endzustände sind complete, aborted, initialization_failed und configuration_changed.

Jedes bereits gebündelte Rohdaten-Sample erhält lediglich "acquisition": <int>. Dieser Integer verweist zunächst in measurement_acquisitions; dessen snapshot_id verweist weiter in measurement_graph_snapshots. Zeitstempel werden bewusst einmal je Messdurchlauf gespeichert und nicht für jeden skalaren Messwert wiederholt. Ein regulärer zweiter Aufruf beginnt auch bei identischem Snapshot einen neuen Messdurchlauf. Eine Fortsetzung aus dem Autosave verwendet den unvollständigen Messdurchlauf nur dann weiter, wenn der Konfigurations-Digest unverändert ist.

Ein Messgraph-Snapshot speichert den exakten DOT-Text, die aufgelösten Node-INI-Dateien, durch INI-Optionen namens FILE referenzierte externe Dateien, Inline-Datenblöcke und Quellen benutzerdefinierter Treiber. Zusätzlich enthält er logische Graph- und Condition-Mappings, Ressourcen-Hashes, Quellverweise und Mehrdeutigkeiten der Suchpfade. Absolute aufgelöste Pfade helfen bei der Diagnose der ursprünglichen Laufzeit, sind für die Prüfung der eingebetteten Bytes jedoch nicht erforderlich. Mit hoher Sicherheit erkannte Zugangsdaten und privates Schlüsselmaterial werden abgelehnt statt persistiert.

Nach MGraph.CreateDevices() können Anwendungen mit MGraph.capture_configuration_snapshot() einen Snapshot erfassen. Die Funktionen verify_measurement_graph_snapshot, compare_measurement_graph_snapshots und extract_measurement_graph_snapshot aus mpylab.tools.configuration_snapshot prüfen, vergleichen und rekonstruieren diesen Nachweis ohne Hardwareinitialisierung. Die Extraktion ist als Rekonstruktion der Quelldateien zu verstehen; sie stellt keinen physischen Gerätezustand wieder her.

Autosave und Fortsetzen

Während einer langen Messung schreibt mpylab in konfigurierbaren Abständen ein Autosave-Pickle. Darin werden neben den bereits erfassten Daten auch strukturierte Angaben zum Fortsetzungspunkt gespeichert. ascmd bleibt als lesbare Beschreibung des Aufrufs erhalten; für die Programmlogik wird die strukturierte Resume-Information bevorzugt. Die aktuelle gemeinsame Resume-Struktur verwendet schema_version = 1. Diese Version gilt nur für autosave_resume und ist keine globale Version des gesamten Pickles.

Beim nächsten Start erkennt das zugehörige Skript die Autosave-Datei und kann die Messung am gespeicherten Schleifenindex fortsetzen. Bereits abgeschlossene Frequenzen oder Positionen werden dabei nicht erneut gemessen. Nach erfolgreichem Abschluss und Schreiben des finalen Pickles wird das Autosave normalerweise entfernt. Bei einer unvollständigen Störfestigkeitsmessung kann es bewusst erhalten bleiben.

Ein Autosave ist ein vollständiges Historien-Pickle mit unvollständigem Datensatz. Fehlende spätere Frequenzen oder Positionen sind deshalb normal; bereits vorhandene Einträge müssen jedoch dieselbe Struktur wie im finalen Datensatz besitzen. Ein finales Pickle ist nicht allein deshalb vollständig, weil es geladen werden kann. Mess- und Auswertestatus sind zusätzlich zu prüfen.

Zwischenstand nach der Messung

Viele Skripte unterstützen zusätzlich after_measurement_pickle_file. Diese Datei wird nach der Datenerfassung, aber vor oder unabhängig von der abschließenden Auswertung geschrieben. Sie ist besonders nützlich, wenn:

• eine Auswertung ohne erneuten Hardwarezugriff wiederholt werden soll,

• Auswerteparameter korrigiert wurden,

• die Messung erfolgreich war, ein späterer Schritt aber abbrach.

Sie ersetzt nicht das finale Historien-Pickle, sondern dokumentiert einen bewussten Zwischenstand.

DAT- und TSV-Dateien

rawdata_output_filename und processeddata_output_filename erzeugen menschenlesbare DAT-Dateien. Rohdaten zeigen die erfassten Messgrößen, verarbeitete Dateien die daraus bestimmten Ergebnisse. Einheiten und Unsicherheiten bleiben entsprechend dem mpylab-Datenformat erhalten.

TSV-Dateien werden für tabellarische Nebenprodukte eingesetzt, etwa Preflight-Ergebnisse oder maschinenlesbare Report-Metadaten. DAT und TSV sind gut für Vergleich, Versionsverwaltung und Weiterverarbeitung geeignet. Das Historien-Pickle bleibt jedoch die vollständigere Quelle, weil nicht jede Objektbeziehung und Zusatzinformation in flache Tabellen passt.

Die unterstützten Lesepfade der TEM-Verifikation, einschließlich der später für Immunitätsmessungen verwendeten Vorwärtsleistung, beschreibt TEM-Verifikationsdaten.

Dateinamen

Beschreibungen können Bestandteil von Ausgabedateinamen sein. Skripte sollten dafür mpylab.tools.filenames.format_output_filename verwenden. Die Messskripte kapseln diesen Aufruf teilweise in einem lokalen format_filename-Helfer. Die Funktion setzt die konfigurierte Dateinamensvorlage mit bereinigten und längenbegrenzten Argumenten zusammen. Anwendungsprogramme sollten Beschreibungen nicht ungeprüft als vollständige Dateinamen verwenden.