Störfestigkeitsergebnisse und EUT-Bewertung

Störfestigkeitsergebnisse bestehen aus mehr als einem abschließenden Bestanden/Nicht-bestanden-Wert. mpylab hält die eingeprägte Störgröße, Beobachtungen am EUT, Bedienereingriffe, Wiederholungen und die Bewertung nach dem gewählten Leistungskriterium getrennt und nachvollziehbar fest.

Primäre Daten und Austauschformat

Das finale Pickle der Messklasse bleibt die vollständige Messhistorie. Es enthält Rohdaten, Messkonfiguration, Referenzdaten, Autosave-Informationen und Auswertung. Der strukturierte JSON-Export aus mpylab.env.immunity_result ist dagegen ein portabler Ausschnitt für Datenaustausch und externe Werkzeuge. Er ersetzt weder das Pickle noch den modularen Report.

Die drei Ebenen sind:

EUT-Ereignis

Eine einzelne manuelle oder automatische Beobachtung während einer Expositionsphase.

Leistungskriterium

Bewertung einer Folge von Ereignissen nach Kriterium A, B oder C.

Störfestigkeitsdokument

Optionaler JSON-kompatibler Export von Messpunkten, Störgrößen und Bewertungen.

Störgrößenneutrale Messpunkte

Ein Datensatz darf die Prüfgröße nicht fest als elektrische Feldstärke benennen. Das disturbance-Mapping verwendet deshalb einen beschreibenden quantity_kind sowie frei benannte Messkomponenten:

field_record = {
    "frequency_hz": 80e6,
    "disturbance": {
        "quantity_kind": "electric_field_strength",
        "target": target_field,
        "measured_components": {"cell_y": measured_field},
    },
    "eut_events": events,
    "assessment": assessment,
}

conducted_record = {
    "frequency_hz": 10e6,
    "disturbance": {
        "quantity_kind": "injected_current",
        "target": target_current,
        "measured_components": {"monitor": measured_current},
    },
}

Weitere sinnvolle Bezeichner sind beispielsweise applied_voltage oder bulk_current. quantity_kind ist bewusst keine abgeschlossene Aufzählung. Anwendungen sollten dennoch stabile, eindeutige Namen verwenden, damit Auswertung und Reports kompatible Datensätze erkennen können.

SCUQ-Quantities bleiben innerhalb der Messhistorie erhalten. Beim JSON-Export werden sie als value, uncertainty und unit dargestellt. Komplexe Zahlen werden in real und imag zerlegt; NumPy-Skalare und Arrays werden in normale JSON-Werte und Listen überführt.

EUT-Ereignisstruktur

Die gemeinsame Monitoring-API liegt unter mpylab.env.eut. Neue Anwendungen importieren Ereignisse, Monitore und virtuelle Testhelfer aus diesem Paket. Die früheren Module mpylab.env.eut_monitor und mpylab.env.random_eut_monitor bleiben als Kompatibilitätsschicht für bestehende Skripte und Pickle-Dateien verfügbar.

mpylab.env.eut.make_eut_event() erzeugt ein validiertes, pickle-freundliches Ereignis. Wichtige Felder sind:

status

passed, degraded, failed oder not_evaluated.

event_type

status für eine EUT-Beobachtung oder monitor_diagnostic für einen Fehler der Überwachung selbst.

phase

pre_exposure, during_exposure, post_exposure oder recovery.

functional_state

normal, degraded, failed oder not_evaluated während der betrachteten Phase.

after_exposure_state und recovery

Zustand nach Abschalten der Störgröße und Art der Wiederherstellung. recovery kann not_required, automatic, operator, reset, failed oder not_evaluated sein.

operating_mode_changed und stored_data_lost

Optionale boolesche Beobachtungen, die für die Bewertung relevant sind.

action

Empfehlung continue, retry oder stop an den Messkernel.

safety_action

none oder rf_off. Das Feld beschreibt eine Sicherheitsanforderung, führt aber selbst keinen Hardwarebefehl aus.

reason, details, timestamp und source

Begründung, Zusatzdaten, Zeitstempel und Herkunft der Beobachtung.

Die Messklasse bleibt für RF-Off und die tatsächlich angewandte Ablaufaktion verantwortlich. Ein Monitor greift nicht direkt auf den MGraph zu. Die aufgabenorientierte EUT-Monitoring-Anleitung zeigt die Verwendung vorhandener Messklassen und die Entwicklung eigener Monitore.

Manuelle und automatische Überwachung

Manuelle Intervention ist immer vorhanden. ManualEUTMonitor nimmt Tastatur- oder GUI-Ereignisse entgegen. CompositeEUTMonitor ergänzt diese Pflichtkomponente um beliebig viele automatische Monitore, etwa Kamera-, Kommunikations- oder Prozessdatenüberwachung.

EUTMonitoringSession stellt den gemeinsamen, HF-neutralen Lebenszyklus dieses Monitorverbunds bereit. Sie startet und beendet Expositionen, leitet Phasenwechsel weiter, validiert Ereignisse und trennt Monitordiagnosen von EUT-Zustandsereignissen. HF-Abschaltung, Wiederholungen und Entscheidungen über den Messablauf verbleiben bewusst im Messkernel oder Worker.

EUTMonitor.poll_event soll nicht blockieren. Eine Überwachung mit begrenztem blockierendem Aufruf wird in ThreadedEUTMonitor gekapselt. Ein Fehler eines automatischen Monitors wird als monitor_diagnostic gemeldet; die manuelle Rückfallebene bleibt verfügbar.

VirtualEUTMonitor und RandomEUTMonitor ermöglichen reproduzierbare hardwareunabhängige Tests. Zufallsereignisse sind ausschließlich Testdaten und kein Nachweis realer EUT-Eigenschaften.

Leistungskriterien A, B und C

mpylab.env.eut.evaluate_performance_criterion() bewertet die strukturierten Ereignisse:

Kriterium A

Während und nach der Exposition darf keine Beeinträchtigung vorliegen. Ein diagnostischer Retry löscht eine bereits beobachtete Beeinträchtigung nicht.

Kriterium B

Eine vorübergehende Beeinträchtigung ist zulässig, ein Funktionsausfall jedoch nicht. Nach der Exposition muss der Zustand normal sein und die Erholung automatisch erfolgen.

Kriterium C

Ein vorübergehender Funktionsausfall ist zulässig. Danach muss der Zustand normal sein; automatische Erholung, Bedienereingriff oder Reset sind zulässig.

Eine beobachtete Betriebsartänderung oder ein Verlust gespeicherter Daten führt in der aktuellen gemeinsamen Bewertung zum Nichtbestehen. Fehlen für B oder C die nötigen Angaben zum Zustand nach der Exposition oder zur Erholung, bleibt die Bewertung not_evaluated statt eine Annahme zu treffen.

Ein früheres not_evaluated kann durch einen späteren vollständig bewerteten Versuch ersetzt werden. Eine tatsächlich beobachtete Beeinträchtigung wird für Kriterium A durch eine Wiederholung nicht nachträglich unsichtbar.

JSON-Dokument erzeugen

from mpylab.env.immunity_result import (
    build_immunity_document,
    write_immunity_document,
)

document = build_immunity_document(
    application="my-immunity-application",
    eut_description="Example EUT",
    performance_criterion="A",
    created_at="2026-07-16T12:00:00+02:00",
    records=records,
)
output = write_immunity_document("result.json", document)

Das Dokument enthält:

  • schema = "mpylab-immunity-result" und schema_version;

  • measurement_type = "immunity";

  • Anwendung, Erstellungszeit und EUT-Beschreibung;

  • das gewählte Leistungskriterium;

  • die anwendungsspezifische Liste records.

load_immunity_document prüft Schema-Name, Version und die Existenz einer Record-Liste. Die fachliche Vollständigkeit eines konkreten Messverfahrens muss weiterhin dessen Messklasse oder Auswertung prüfen. JSON wird mit allow_nan=False geschrieben; nichtendliche Zahlen werden daher nicht still serialisiert.

Reports und API

Der modulare TEM-Report liest die EUT-Bewertung aus der vollständigen Pickle-Historie und erzeugt daraus Tabellen und Zusammenfassungen. Er bewertet die Messung nicht erneut.