Konfigurationen prüfen und migrieren

Installiertes mpylab stellt mehrere Wartungswerkzeuge bereit. Alle Migrationswerkzeuge arbeiten ohne --write zunächst als Dry-Run.

Vollständige Konfigurationspakete

mpylab-config-check prüft ein über TOML inventarisiertes Paket aus DOT-, INI- und DAT-Dateien ohne Geräte zu initialisieren oder Hardware zu öffnen:

mpylab-config-check config-checks.toml \
    --json-report config-check-report.json

Ein Befund verwendet das CI-taugliche Format Datei:Zeile:Spalte: Schweregrad[Code]: Meldung. Der Check umfasst DOT-, INI- und DAT-Syntax, Gerätetreiber und Dateiverweise, NPORT-Datenqualität, Namen sowie explizit deklarierte Context- und Frequenzpfade. Für jeden expliziten Frequenzpunkt prüft das Werkzeug außerdem, dass alle auf dem aktiven Pfad verwendeten Geräte und Korrekturglieder die Frequenz innerhalb ihres INI-Bereichs von FSTART bis FSTOP zulassen. Ein Verstoß wird als path-frequency-range-Fehler direkt an der betroffenen Grenzwertzeile gemeldet. Datenqualitätswarnungen können nach fachlicher Bewertung mit --warnings-as-errors zu einem fehlschlagenden Status führen.

Ein minimales Inventar sieht so aus:

format_version = 1

[policy]
lowercase_graph_names = true

[[graphs]]
dot = "immunity.dot"
condition_map = "tem"

[[graphs.scenarios]]
name = "gtem"
context = { mode = "GTEM" }

[[graphs.scenarios.paths]]
start = "sg"
end = "gtem"
mode = "exactly_one_path"
values = [80e6, 1e9, 1.000000001e9, 4.2e9]

Die Werte sollen Grenzen sowie mindestens je einen repräsentativen Punkt auf beiden Seiten einer Umschaltung enthalten. Ein lokaler Lauf und die Pipeline rufen denselben Befehl auf.

DOT-Dateien

mpylab-dot-migrate local-config.dot
mpylab-dot-migrate --check --recursive path/to/configurations

Das Werkzeug migriert historische Condition-Namen, validiert die Syntax und kann ausgewählte Signalpfade über einen Frequenzbereich prüfen:

mpylab-dot-migrate \
    --path Sg:TxAnt \
    --frequency-range 80e6 6e9 \
    --path-mode exactly_one_path \
    local-config.dot

Die vollständige Eingabe- und Condition-Semantik steht in der DOT-Referenz.

NPORT-Konfigurationen

mpylab-nport-migrate local-cable.ini
mpylab-nport-migrate --check --recursive path/to/configurations

Die Migration ersetzt historische, mehrdeutige Interpolationsangaben durch die getrennten Frequenz-, Wert- und Komplexoptionen.

Die Datenqualität wird separat geprüft:

mpylab-nport-check --recursive path/to/configurations \
    --json-report nport-quality.json

Der Check untersucht unter anderem Frequenzabdeckung, Stützstellenabstände, Interpolation und referenzierte DAT-Dateien. Syntax, Einheiten und Unsicherheitsangaben dieser Dateien sind in INI- und DAT-Referenz für Gerätedaten beschrieben.

CI-Strategie

Ein Konfigurations-Repository sollte produktive Graphen in einer versionskontrollierten TOML-Datei inventarisieren. Benannte Tabellen halten erwartete Gerätezahl, erlaubte Rückfallebenen und fachliche Pfadprüfungen fest. Ein generischer Test kann dann sicherstellen, dass:

  • jede produktive DOT-Datei genau einmal erfasst ist;

  • alle INI- und DAT-Referenzen auflösbar sind;

  • Conditions an Bereichsgrenzen eindeutige Pfade ergeben;

  • aktive Pfadgeräte jeden expliziten Prüffrequenzpunkt abdecken;

  • neue Konfigurationen nicht unbemerkt ohne Prüfung hinzukommen.

Der JSON-Bericht kann als Pipeline-Artefakt aufbewahrt werden. Weder ein grüner Paketcheck noch virtuelle Tests belegen, dass Adressen, Umschalter, Schutzgrenzen und reale HF-Pfade am Messplatz korrekt funktionieren.

Vor Hardwarezugriff

Ein grüner Syntaxcheck ersetzt keinen Preflight. Zusätzlich sind Gerätegrenzen, RF-Off, Verstärkerschutz, Frequenzabdeckung, Ausgabepfade und Autosave-Wiederanlauf mit der konkreten Messklasse zu prüfen.