TEM- und GTEM-Zellen ==================== ``TEMCell`` bündelt Geometrie, Verifikation, den Feldfaktor ``e0y``, Emissionskorrelation und Störfestigkeitsprüfung. Der aktuelle produktive Schwerpunkt liegt auf einportigen GTEM-Zellen. Geometrie und Referenzdaten --------------------------- Die Geometrie gehört zur Messhistorie. Höhe und Längsposition werden über das für die konkrete Zelle festgelegte Modell miteinander verknüpft. Messungen und Referenzdaten müssen sich auf diese Geometrie beziehen. Für spätere Messungen stehen zwei vorbereitende Wege zur Verfügung: ``Verification`` Vermisst eine Ebene an mehreren Sondenpositionen. Sie bewertet Feldhomogenität, TEM-Moden-Dominanz, benötigte Vorwärtsleistung und AM-Headroom. ``e0y`` Vermisst den normierten Feldfaktor an einer Position. Für Emission kann alternativ das analytische ``e0y`` der GTEM-Geometrie verwendet werden. Die gewählte Quelle für ``e0y`` wird bei der Emissionsauswertung ausdrücklich gespeichert. Sind mehrere geeignete Quellen vorhanden, muss die Auswahl bewusst erfolgen. Mehrere Uniform Areas und Verifikationsebenen --------------------------------------------- Eine Konfiguration kann mehrere benannte Flächen unter ``uniform_areas`` bereitstellen. ``tem-verification.py`` und ``tem-immunity.py`` registrieren alle Definitionen in der ``TEMCell``-Historie. Der singuläre Schlüssel ``uniform_area`` bleibt als rückwärtskompatibler Standard erhalten: .. code-block:: python UNIFORM_AREAS = { "ua_h1p0": { "name": "ua_h1p0", "h": 1.0, "width": 0.5, "height": 0.5, "center": (0.0, 0.5), }, "ua_h1p5": { "name": "ua_h1p5", "h": 1.5, "width": 1.5, "height": 1.0, "center": (0.0, 0.75), }, } cdict = { "uniform_areas": UNIFORM_AREAS, # rückwärtskompatibler Standard "uniform_area": UNIFORM_AREAS["ua_h1p5"], } Eine einzelne ``Measure_Verification``-Ausführung vermisst weiterhin genau eine Fläche. ``measure_parameters[i]["uniform_area"]`` wählt ihren Namen; ``descriptions[i]`` benennt den zugehörigen Messdatensatz. Aufeinanderfolgende Verifikationen erweitern dasselbe History-Pickle und speichern Geometrie, Messpunkte, Rohdaten und Auswertung getrennt je ``description``. Die Flächendefinition selbst enthält keine Messwerte. Eine spätere Störfestigkeitsmessung lädt diese Historie und zeigt die vorhandenen Verifikationsdatensätze zur Auswahl an. Bei konfiguriertem ``eut_h`` oder ``eut_z`` werden sie nach dem Höhenabstand zur EUT-Position geordnet. Zwischen zwei benachbarten Ebenen kann eine Höheninterpolation angeboten werden, sofern beide Datensätze die benötigten gemeinsamen Frequenzen enthalten. Die automatische Interpolation ist nur für fachlich kompatible Flächenfamilien vorgesehen. Flächen mit unterschiedlichem Mittelpunkt, unterschiedlicher lateraler Ausdehnung oder anderer Punktabdeckung dürfen nicht allein aufgrund ihrer Höhe miteinander interpoliert werden. Die aktuelle Immunity-Auswahl trifft keine automatische Entscheidung anhand der lateralen EUT-Position; solche Datensätze müssen bewusst ausgewählt werden. Virtuelle Verifikation und e0y ------------------------------ .. code-block:: console python script/tem-verification.py \ script/conf/tem-gtem-verification-virtual/conf.py .. code-block:: console python script/tem-e0y.py \ script/conf/tem-gtem-e0y-virtual/conf.py Beide Abläufe unterstützen Preflight, Autosave und Fortsetzen. Die Hardware-Templates enthalten zusätzlich eine ``HARDWARE_TEST.md`` mit einem stufenweisen Inbetriebnahmeablauf. Logischer Graphmodus und externe Umschaltung --------------------------------------------- ``Measure_e0y``, ``Measure_Verification`` und ``Measure_Immunity`` erhalten den logischen Messgraphmodus über den Parameter ``mode``. Die regulären GTEM-Skripte setzen ihn ausdrücklich auf ``"GTEM"``; ``"TERM"`` ist der sichere Abschluss- beziehungsweise Diagnosepfad. Eine lokale Konfiguration kann den Wert in ``measure_parameters`` überschreiben: .. code-block:: python "measure_parameters": [{ "dotfile": "immunity.dot", "mode": "GTEM", # weitere Messparameter }] Das Messprogramm kennt dabei weder Relaisnummern noch die Verdrahtung des Umschalters. Diese Details gehören in den Messgraphen und den dort referenzierten Gerätetreiber. Ein Umschalter wird im DOT-Knoten als Context-Controller gekennzeichnet; Conditions wählen nur die logischen Pfade: .. code-block:: dot sw [ini="sw_gtem.ini" context_controller="mode"] gtem -> pmbwd [condition="MODE == 'GTEM'"] term -> pmbwd [condition="MODE == 'TERM'"] Bei jedem Context-Wechsel wird RF zuerst abgeschaltet. Der Controller plant den erwarteten vollständigen Hardwarezustand, wendet eine nötige Mode-Änderung an und liest den Zustand anschließend zurück. Ein reiner Frequenzwechsel darf den Mode nicht erneut setzen. Dadurch überschreibt er eine zwischenzeitlich extern gewählte sichere TERM-Stellung nicht. Der Zustand wird vor einem weiteren Context-Wechsel, vor ``RFOn`` und während Geräteleseoperationen kontrolliert. Die Kontrolle ist kein asynchroner Hintergrund-Watchdog; sie erfolgt an diesen sicheren Programmpunkten. Weicht der gelesene Zustand vom erwarteten Zustand ab oder ist die Rückleseantwort unvollständig, schaltet mpylab RF aus und hält die Messung an. Der Bediener kann abbrechen oder die geplante Stellung ausdrücklich erneut anwenden. Ein automatisches Zurückschalten auf GTEM findet nicht statt. Emission -------- Die Emissionsmessung nimmt Störspannungen für die vorgesehenen EUT-Orientierungen auf und korreliert sie auf eine äquivalente Freifeld- Feldstärke. Als Feldfaktor kann eine e0y-Messung, ein Verifikationsdatensatz oder die analytische GTEM-Formel dienen. Ein virtueller Ablauf auf Basis einer e0y-Messung lautet: .. code-block:: console python script/tem-e0y.py \ script/conf/tem-gtem-e0y-virtual/conf.py python script/tem-emission.py \ script/conf/tem-gtem-emission-virtual/conf.py Alternativ zeigt ``tem-gtem-emission-virtual-from-verification/conf.py`` die Verwendung einer vorherigen Verifikation. Ein konfiguriertes Limit aktiviert die Auswahl der Frequenzen, die mit dem zum Limit gehörenden Detektor nachzumessen sind. Fehlt ein geeignetes Limit, bleibt die Messung gültig; es findet lediglich keine detektorspezifische Nachmessung statt. Störfestigkeit -------------- Die Störfestigkeitsmessung verwendet die in der Verifikation ermittelten Referenzleistungen und AM-Headroom-Ergebnisse: .. code-block:: console python script/tem-immunity.py \ script/conf/tem-gtem-immunity-virtual/conf.py AM-Headroom-Entscheidungen -------------------------- Für 80 Prozent AM fährt die Verifikation das ``1,8``-Fache des Trägerfeldes an und reduziert den Generator um ``5,10545 dB``. Die korrigierte Vorwärtsleistung ist die normative Messgröße; ein Feldstärkeverhältnis ist ausdrücklich ein nicht normativer Proxy. Beide Methoden propagieren vor der Umrechnung in dB die Unsicherheit des gemessenen Verhältnisses einschließlich gemeinsamer SCUQ-Komponenten. Beide Methoden verwenden standardmäßig das nominale Intervall ``3,10545...7,1 dB``. Die obere Grenze folgt IEC 61000-4-3:2020 und wird bewusst auch als technische Interpretation für IEC 61000-4-20:2022 verwendet, deren ältere Formulierung Absenkungen oberhalb von ``5,1 dB`` nicht konsistent auflöst. Das zurückgezogene Interpretation Sheet zu IEC 61000-4-3:2006 stützt die technische Begründung, wird jedoch nicht als aktuelle normative Referenz dargestellt. ``am_headroom_maximum_drop_db`` konfiguriert die obere TEMCell-Grenze und ist auf ``7.1`` voreingestellt (der Parameter der allgemeinen Auswertefunktion heißt ``maximum_drop_db``). Die Messunsicherheit wird propagiert und protokolliert, ändert aber standardmäßig keine der beiden Grenzen. Mit ``am_headroom_allow_upper_uncertainty=True`` kann eine Überlappung ausschließlich an der oberen Grenze akzeptiert werden; die nominale untere Grenze wird niemals gelockert. ``am_headroom_coverage_factor`` legt dafür den Überdeckungsfaktor fest. Gemeinsame Kalibrierbeiträge können sich im Verhältnis der hohen zur reduzierten Messung aufheben, während unabhängige Typ-A-Streuung erhalten bleibt. Vor der Exposition prüft der Ablauf Geometrie, Frequenzabdeckung, verfügbare Feldstärken, Verstärkerschutz und die EUT-Überwachung. Manuelle Bedienerintervention bleibt auch bei zusätzlicher automatischer EUT-Überwachung verfügbar. Die gemeinsame :doc:`EUT-Ereignisstruktur und Bewertungsregeln <../results/immunity-results>` halten Störgröße, Beobachtungen und Leistungskriterium getrennt fest. Konfiguration und eigene Monitorimplementierungen beschreibt die :doc:`EUT-Monitoring-Anleitung <../framework/eut-monitoring>`. Reports ------- ``tem-report.py`` erzeugt aus der gesamten Pickle-Historie einen modularen HTML-/PDF-Report mit separaten Grafiken und Tabellen. Metadaten können über mehrere TOML-Dateien schrittweise ergänzt oder überschrieben werden. ``tem-verification-report.py`` bleibt für einen fokussierten Verifikationsreport verfügbar.