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 :mod:`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: .. code-block:: python 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 :mod:`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. :func:`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 :doc:`EUT-Monitoring-Anleitung <../framework/eut-monitoring>` 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 ----------------------------- :func:`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 ---------------------- .. code-block:: python 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 :doc:`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. * :doc:`../framework/ui-workers` beschreibt manuelle Intervention und Threading automatischer Monitore. * :doc:`history-files` erklärt die vollständige Messhistorie. * :doc:`../../api/measurement` dokumentiert die kuratierte Python-API.