Virtuelle GTEM-Abläufe¶

Die modernen GTEM-Skripte im Verzeichnis script können mit virtuellen Gerätekonfigurationen ohne Laborhardware ausgeführt werden. Der aktuelle Ausbaustand konzentriert sich auf Eintor-GTEM-Zellen. Zweitor-Zellen werden separat betrachtet.

Normative Referenz¶

Messablauf und Auswertung orientieren sich an der neueren FDIS-Fassung von IEC 61000-4-20. Für die aktuell implementierten GTEM-Abläufe sind insbesondere diese Abschnitte relevant:

Abschnitt	Bedeutung im Code
Anhang A.3.2.3	Eintor-Wellenleiter-Korrelationsalgorithmus für Emissionsmessungen.
Anhang A.3.2.3.2	Spannungsmessungen in drei orthogonalen EUT-Positionen.
Anhang A.3.2.3.3	Bestimmung des Feldfaktors `e0y`.
Anhang A.3.2.4	Korrelation der abgestrahlten Leistung zur maximalen Freifeldstärke `Emax`.
Anhang B	TEM-Mode-Verifikation und Einstellung des Störfestigkeitsprüfpegels. Die Implementierung nutzt die gemessene Feldverteilung, um eine Referenzfeldstärke und die zugehörige Vorwärtsleistung für spätere Störfestigkeitsmessungen zu bestimmen.

Die Dokumentation verweist nur auf Abschnittsnummern der Norm. Die Formeln und Auswerteparameter bleiben in der Norm maßgeblich.

Verfügbare Skripte und Konfigurationen¶

Skript	Zweck	Virtuelle Konfiguration
`tem-e0y.py`	Experimentelle Bestimmung des GTEM-Feldfaktors `e0y`.	`conf/tem-gtem-e0y-virtual/conf.py`
`tem-emission.py`	Emissionsmessung und Auswertung gegen eine vorhandene `e0y`-Historie.	`conf/tem-gtem-emission-virtual/conf.py`
`tem-emission.py`	Emissionsmessung und Auswertung gegen eine vorhandene Verifikationsreferenz-Historie. Die `e0y`-Quelle wird aus `reference_field / sqrt(forward_power)` abgeleitet.	`conf/tem-gtem-emission-virtual-from-verification/conf.py`
`tem-verification.py`	TEM-Mode-Verifikation mit daraus abgeleiteter Verifikationsreferenz. Die Messung speichert Rohdaten von Feldsonde und Leistungsmessern und wertet daraus Tabellen für Referenzfeldstärke und Vorwärtsleistung aus.	`conf/tem-gtem-verification-virtual/conf.py`
`tem-immunity.py`	Störfestigkeitsmessung gegen eine vorhandene Verifikationsreferenz-Historie. Die aktuelle GTEM-Strategie regelt auf die aus den Referenzdaten bestimmte Vorwärtsleistung.	`conf/tem-gtem-immunity-virtual/conf.py`

Zu jedem Textskript gibt es außerdem einen Qt-Starter mit gleichem Namen und -qt vor der Dateiendung, zum Beispiel tem-immunity-qt.py. Die Qt-Starter verwenden dieselben Konfigurationsdateien und führen die Messung in einem Worker-Thread aus, während die Oberfläche bedienbar bleibt.

Historien-Pickles¶

Auch die TEM/GTEM-Pickles sind Historien-Container. Eine Folgemessung lädt normalerweise das Ausgabe-Pickle des vorherigen Schritts über pickle_input_filename, ergänzt ihre eigenen Rohdaten und Auswertung und schreibt danach ein neues vollständiges TEMCell-Pickle.

Die typische Reihenfolge für eine GTEM-Emissionsmessung ist:

e0y -> emission

Das Emissions-Pickle enthält damit sowohl die e0y-Kalibrierhistorie als auch die neu hinzugefügte Emissionsmessung. Diese Eigenschaft ist für die Rückführbarkeit wichtig.

GTEM-Geometrie¶

Alle GTEM-Messungen in einer Historie verwenden eine feste Geometrie. Die Skriptkonfiguration beschreibt diese Geometrie mit der Typenbezeichnung der Zelle, einer Höhenreihe und dem zugehörigen Abstand delta_z. Die Einträge in heights sind dabei Höhen h_i in der Zelle; sie definieren zunächst die Zellgeometrie und müssen nicht mit späteren Verifikations- oder Kalibrierhöhen identisch sein. delta_z ist der Abstand zwischen benachbarten Höhenpunkten. Die absolute z-Position des ersten Höhenpunkts wird nicht vorausgesetzt.

Für GTEM-Zellen wird das lineare Modell h = k*z verwendet. Der Faktor height_per_z wird aus den Differenzen benachbarter Höhen bestimmt, also näherungsweise aus (h[i+1] - h[i]) / delta_z. Erst danach werden rechnerische z-Positionen aus z = h / height_per_z abgeleitet. Für Abläufe, die die analytische GTEM-Formel für e0y benötigen, enthält die Geometrie zusätzlich width_per_z und gap_per_z. Die charakteristische Impedanz ist mit 50 Ohm vorbelegt und muss normalerweise nicht explizit konfiguriert werden.

Die Geometrie wird in der Messhistorie gespeichert. Neu gemessene e0y-Daten übernehmen die Geometrie bis nach processedData_e0y; eine spätere Emissionsauswertung prüft, ob diese gemessenen e0y-Daten zur aktuellen GTEM-Geometrie passen. Ältere Pickles ohne Geometrie-Metadaten bleiben als Legacy-Daten akzeptiert, können aber diese Konsistenzprüfung nicht liefern.

e0y-Daten bei Emission¶

Die Emissionsauswertung kann gemessene e0y-Daten aus einem vorherigen tem-e0y.py-Lauf oder die analytische GTEM-Formel verwenden. Die virtuelle Emissionskonfiguration nutzt standardmäßig gemessene e0y-Daten. Wenn use_e0y_GTEManalytical auf True gesetzt wird, muss die EUT-Position über eut_h oder eut_z sowie eut_x und eut_y bekannt sein. Der analytische Pfad bestimmt lokale GTEM-Breite, Höhe und Spaltweite dann aus der gespeicherten Geometrie statt aus einem separaten EUTpos-Dictionary. Legacy-EUTpos-Dictionaries mit expliziten Zellabmessungen bleiben aus Kompatibilitätsgründen akzeptiert.

e0y-Quellen-Metadaten¶

Ausgewertete e0y-artige Daten enthalten einen Eintrag source, der beschreibt, woher der Feldfaktor stammt. Isolierte Messungen mit tem-e0y.py speichern method = "measured_e0y" und die zugehörige GTEM-Geometrie. Wenn e0y_h oder e0y_z zusammen mit e0y_y konfiguriert ist, ist die Quelle eine Punktquelle mit source_type = "point" und der abgeleiteten Position h, z, x und y. Ohne explizite Positionsmetadaten bleibt die Quelle source_type = "unknown". Für Punktquellen mit Geometriemetadaten speichert Evaluate_e0y zusätzlich point_summary, frequency_summary und einen informativen e0y_comparison. Dabei wird das gemessene e0y der cell_y-Komponente, also abs(E_y) / sqrt(P_fwd), mit dem analytischen GTEM-Wert am selben Punkt verglichen. Wenn Position oder Geometrie fehlen, hält e0y_comparison_status fest, warum die analytische Kontrolle übersprungen wurde.

Verifikationsergebnisse, die auf einer konfigurierten Uniform Area beruhen, speichern source_type = "uniform_area" mit method = "verification", uniform_area, uniform_area_plane und uniform_area_points. Diese Struktur dient der Rückführbarkeit und bereitet eine spätere Quellenauswahl oder Interpolation vor. Sie trifft noch keine automatische Entscheidung darüber, welche e0y-Quelle für eine Emissionsauswertung verwendet werden soll.

Die Uniform Area beschreibt die x-y-Fläche, in der die Feldverteilung geprüft oder kalibriert wird. Sie besitzt eine feste Lage in der GTEM-Zelle, meist über eine Höhe h oder die äquivalente z-Position aus der gespeicherten Geometrie. Diese Lage wird als Verifikationsebene in uniform_area_plane abgelegt. Die einzelnen Messpunkte in dieser Ebene werden in uniform_area_points gespeichert. Dadurch kann eine spätere Messung dem Nutzer anzeigen, für welche Ebenen Daten vorhanden sind, ob die EUT-Position in der geprüften Fläche liegt und ob eine Interpolation zwischen zwei benachbarten Ebenen möglich ist.

Die Hilfsmethode TEMCell.summarize_e0y_sources() listet die verfügbaren Quellen aus processedData_e0y und processedData_Verification auf. Jede Zusammenfassung enthält die Quellenfamilie, den Frequenzbereich und geometry_matches. geometry_matches ist True oder False, wenn beide Geometrien bekannt sind, und None, wenn der Vergleich nicht möglich ist. Die Methode ist bewusst rein lesend; sie zeigt verfügbare Quellen an, wählt aber keine Quelle aus und interpoliert nicht zwischen Quellen.

Bei datenbasierten e0y-Quellen vergleicht die Zusammenfassung außerdem die angeforderten Emissionsfrequenzen mit dem gemessenen Quellenbereich. Frequenzen innerhalb dieses Bereichs können interpoliert werden. Frequenzen unterhalb oder oberhalb des gemessenen Bereichs würden eine Extrapolation erfordern und lösen daher eine Nutzerentscheidung aus, bevor die ausgewählte Quelle verwendet wird. Diese Prüfung wird bewusst nicht auf die analytische GTEM-e0y-Formel angewendet, weil dieses Modell frequenzunabhängig ist; Effekte höherer Moden liegen außerhalb dieses analytischen Modells und sind kein begrenzter Frequenzdatensatz.

Bei punktförmig gemessenen e0y-Quellen kann die Emissionsauswertung zusätzlich die gespeicherte Quellenposition mit der gespeicherten EUT-Position vergleichen. Die zulässige Entfernung ist delta_r_max = q * c0 / f_max. Dabei ist q der Parameter e0y_position_wavelength_factor; der Standardwert ist 0.5. Bei einer höchsten angeforderten Emissionsfrequenz von 1 GHz ergibt sich damit standardmäßig eine Grenze von ungefähr 0,15 m. Größere Abweichungen lösen eine Nutzerentscheidung aus, bevor die ausgewählte Punktquelle verwendet wird, weil der gemessene e0y-Punkt die EUT-Position dann möglicherweise nicht mehr hinreichend gut beschreibt.

Bei Verifikationsreferenzquellen mit source_type = "uniform_area" meldet dieselbe Quellenzusammenfassung, ob die gespeicherte EUT-Position x/y innerhalb der verifizierten Uniform Area liegt und ob die EUT-Höhe bzw. z-Position zur Verifikationsebene passt. Liegt das EUT außerhalb der Fläche oder in einer anderen Ebene, wird die Quelle als nutzerpflichtige Entscheidung markiert, bevor sie verwendet werden sollte.

Verifikationsreferenzquellen können außerdem direkt als e0y-Quellen für die Emissionsauswertung ausgewählt werden. In diesem Fall wird e0y aus den ausgewerteten Referenzdaten als reference_field / sqrt(forward_power) abgeleitet. Zum nutzbaren Quellenbereich gehören nur Frequenzen, bei denen beide ausgewerteten Größen vorhanden sind.

Der Emissions-Konfigurationsparameter e0y_description muss eine der gelisteten datenbasierten Quellen explizit benennen. Er kann entweder auf einen isoliert gemessenen e0y-Datensatz aus processedData_e0y oder auf einen Verifikationsreferenzdatensatz aus processedData_Verification zeigen. Eine automatische Quellenauswahl ist bewusst noch nicht aktiviert; None oder "auto" melden die verfügbaren Quellennamen und fordern eine explizite Auswahl an.

Emission-Prescreening für Quasi-Peak-Nachmessungen¶

Die GTEM-Emissionsmessung kann optional eine Peak-Prescreening-Auswertung für spätere Nachmessungen mit dem zum Grenzwert gehörenden Detektor speichern. Dazu wird in den measure_parameters ein emission_limit angegeben. Fehlt dieser Eintrag oder ist er None, wird kein Detektor-Prescreening durchgeführt.

Ein typischer Grenzwert wird über mpylab.limits konfiguriert, zum Beispiel:

"emission_limit": {
    "module": "radiated_emission.en_55011",
    "group": "1",
    "classification": "B",
    "detector": "QP",
    "port": "AC (<= 20 kVA)",
    "distance": "10 m",
},
"prescreen_margin_db": 6.0,
"prescreen_position_count": 3,
"prescan_detector": "PK",

Die Limit-Kurve liefert Feldstärkegrenzen in dBµV/m. Für jede Frequenz wird daraus unter der Annahme gleicher Spannungen an allen EUT-Positionen eine äquivalente Einzelpositions-Spannungsgrenze berechnet. Die größte gemessene Peak-Spannung wird mit dieser Grenze verglichen. Liegt sie innerhalb des konfigurierten prescreen_margin_db unterhalb der Grenze oder darüber, wird die Frequenz als Kandidat für eine Nachmessung mit dem im Limit definierten Detektor markiert. Dieser Detektor ist häufig QP, kann aber je nach Grenzwert auch AV oder PK sein.

Die Entscheidung wird unmittelbar während Measure_Emission nach der Peak-Messung getroffen und im Rohdaten-Pickle gespeichert. Nach Abschluss des Peak-Prescans für die aktuelle EUT-Position werden die markierten Frequenzen direkt mit dem im Limit definierten Detektor nachgemessen, bevor die nächste EUT-Position angefahren wird. Die Ergebnisse liegen unter rawData_Emission[description]["Prescreen"]. Wichtige Einträge sind field_limit, voltage_limit, measured_peak_voltage, margin_db, remeasure_required, prescan_detector, remeasure_detector und position_count_assumption. Zusätzlich enthält rawData_Emission[description]["RemeasureRequiredFrequencies"] die frequenzsortierte Liste der Kandidaten. Die gemessenen Spannungen sind nach Detektor abgelegt, zum Beispiel unter rawData_Emission[description]["voltage"]["PK"] für den schnellen Peak-Prescan und später unter ...["voltage"]["QP"] oder ...["voltage"]["AV"] für Nachmessungen. Evaluate_Emission bleibt für die finale Korrelation zuständig; es verwendet bevorzugt Werte mit dem zum Limit gehörenden Detektor und fällt auf den Prescan-Detektor zurück, wenn noch keine Nachmessung vorhanden ist.

Für den finalen Grenzwertvergleich muss derselbe Grenzwert auch in den evaluation_parameters angegeben werden. Die Auswertung speichert dann unter processedData_Emission[description]["LimitComparison"] pro Frequenz und Port die berechnete Feldstärke Emax, den Grenzwert, den Abstand margin_db, passed sowie detector_required, detector_used und detector_fallback. detector_fallback ist True, wenn noch keine Nachmessung mit dem zum Limit gehörenden Detektor vorliegt und deshalb der Prescan-Detektor verwendet wurde.

Die Standardausgabe von OutputProcessedData_Emission schreibt diese Ergebnisse als tabulatorgetrennte Tabelle. Wichtige Spalten sind freq_Hz, Emax_value, limit_value, margin_dB, passed, detector_required, detector_used und detector_fallback. Dadurch kann die Datei direkt im pexplorer oder in Tabellenwerkzeugen weiterverwendet werden.

Wird ein Ausgabedateiname verwendet, werden zusätzlich zwei tabulatorgetrennte Detaildateien neben der kompakten Tabelle geschrieben. prescreen-...dat enthält den invertierten Spannungsgrenzwert, die gemessene Peak-Spannung, den Abstand zum Grenzwert und die Nachmessentscheidung pro Frequenz, Port und EUT-Position. e0y-source-...dat dokumentiert die e0y-Quelle, die für die finale Korrelation und, falls vorhanden, für den Prescreening-Schritt verwendet wurde. Damit ist die Auswahl einer analytischen, gemessenen oder aus der Verifikation abgeleiteten e0y-Quelle nachvollziehbar, ohne das Pickle öffnen zu müssen.

Die EUT-Position muss für analytisches e0y über eut_h oder eut_z sowie eut_x und eut_y bekannt sein. Wird eine gemessene oder aus der Verifikation abgeleitete e0y-Quelle verwendet, gelten dieselben Positions- und Frequenzprüfungen wie für die normale Emissionsauswertung.

Die typische Reihenfolge für eine GTEM-Störfestigkeitsmessung ist:

verification -> immunity

Das Verifikationsreferenz-Pickle enthält die Rohdaten der TEM-Mode-Verifikation und die ausgewerteten Tabellen reference_field und forward_power. Da die Interpretation der Statistikformeln für die Feldhomogenität noch fachlich diskutiert wird, kann die Constant-Forward-Power-Auswertung die primäre Feldkomponente dreigleisig bewerten: mit Mittelwert und Standardabweichung in dB, mit Mittelwert und Standardabweichung in linearen V/m sowie mit der alten 75-%-Punktabdeckungs- Methode aus der bisherigen Norm. Die Konfiguration field_uniformity_scale = "all" speichert alle Varianten unter field_uniformity_by_scale und reference_field_by_scale; der aktive Modus selected_field_uniformity_scale befüllt reference_field für das spätere Leveling. Damit kann die aktuelle Draft-Interpretation im selben Pickle mit der alten Methode verglichen werden. Die flache Tabelle reference_field_comparison wird von der Processed-Data-Ausgabe geschrieben und enthält pro Frequenz den ausgewählten Wert sowie die Alternativen db, linear und coverage. Zusätzlich werden die Dominanz des TEM-Modes über das 75-%-Quantil des Verhältnisses sekundärer zu primärer Feldkomponente, primary_field_sigma_db, primary_field_sigma_linear und tem_mode_q75 gespeichert. Für GTEM-Daten, die auf der Zellkomponente cell_y ausgewertet werden, speichert die Auswertung zusätzlich einen rein informativen analytischen Vergleich unter e0y_comparison. Pro Verifikationspunkt wird das gemessene normierte Feld abs(E_y) / sqrt(P_fwd) mit dem analytischen GTEM-e0y aus der konfigurierten Geometrie an derselben x-y-Position und derselben Verifikationsebenen-Position z / h verglichen. Gespeichert werden Messwert, analytischer Wert, Verhältnis, relative Abweichung und Abweichung in dB. Dieser Vergleich dient nur der Kontrolle und verändert weder reference_field noch forward_power oder die Pass/Fail-Entscheidung. Die Störfestigkeitsmessung lädt dieses Pickle, nutzt die Referenzdaten für das Leveling auf Vorwärtsleistung, ergänzt die EUT-Daten und schreibt ein neues vollständiges Historien-Pickle.

Bei feldsondenbasierten Verifikationsdaten enthält das Rohdaten-Pickle beide Koordinatensysteme. value wird nach Anwendung des aktiven probe_axis_map in Zellachsenreihenfolge gespeichert; value_probe enthält die ursprüngliche Messung in Sondenachsen. Zusätzlich enthalten die Rohdaten probe_axis_maps und field_probe_values_are_cell_mapped, damit bei der späteren Prüfung nachvollziehbar ist, welche Orientierung angewendet wurde. Die Textdateien *.dat dienen der schnellen Kontrolle und einfachen frequenzbasierten Prüfung. Das Pickle bleibt der maßgebliche strukturierte Historien-Container.

Datenstruktur der Verifikations-Pickles¶

Das TEM-Mode-Verifikations-Pickle enthält die vollständige Messhistorie: aktive Geometrie, Rohmessdaten, ausgewertete Verifikationsdaten und Referenz-Metadaten für spätere Störfestigkeitsmessungen. Feld- und Leistungsgrößen werden als scuq-Quantity-Objekte gespeichert.

Wichtige Keys sind:

tem.geometry: Aktive GTEM-Geometrie der TEMCell-Instanz. Enthalten sind zum Beispiel height_per_z, width_per_z, gap_per_z und characteristic_impedance.
tem.rawData_Verification["cal"]: Rohdaten der TEM-Mode-Verifikation für die Description "cal".
tem.rawData_Verification["cal"]["geometry"]: Geometrie, die mit der Rohmessung gespeichert wurde.
tem.rawData_Verification["cal"]["efield"]: Frequenzindizierte Rohmessdaten. Die Struktur ist efield[freq][port][point_index] -> list[entry]. Die Einträge enthalten Feldsondenwerte, Vorwärts- und Rückwärtsleistung, Punkt-Metadaten und Leveling-Metadaten.
tem.rawData_Verification["cal"]["uniform_area"]: Name der Verifikationsebene.
tem.rawData_Verification["cal"]["uniform_area_plane"]: Vollständige Verifikationsebene mit h-/z-Position und allen Verifikationspunkten.
tem.rawData_Verification["cal"]["probe_axis_maps"]: Metadaten zur während der Messung verwendeten Feldsondenorientierung.
tem.rawData_Verification["cal"]["target_efield"]: Konfigurierte Ziel-Feldstärke der Verifikationsmessung, falls auf konstante Feldstärke geregelt wurde. Dieser Wert ist eine Sollgröße des Messablaufs und nicht automatisch identisch mit dem später ausgewerteten reference_field.
tem.rawData_Verification["cal"]["target_fwd_power"]: Konfigurierte Ziel-Vorwärtsleistung der Verifikationsmessung, falls auf konstante Vorwärtsleistung geregelt wurde.
tem.rawData_Verification["cal"]["verification_target_kind"]: Kompakte, maschinenlesbare Beschreibung der Mess-Zielgröße: "field", "forward_power" oder "sg_level". Mehrere Verifikationsmessungen derselben Ebene können dadurch über unterschiedliche Descriptions nebeneinander im Pickle liegen und trotzdem nach Zielgröße gefiltert werden.
tem.rawData_Verification["cal"]["verification_target_value"]: Zielwert passend zu verification_target_kind. Für Feldstärke und Vorwärtsleistung ist dies ein Quantity-Objekt; für "sg_level" ist es der Startpegel des Signalgenerators in dBm.
tem.rawData_Verification["cal"]["verification_target_label"]: Menschenlesbare Kurzbeschreibung der Zielgröße, zum Beispiel "5 V/m" oder "5 W".
tem.rawData_Verification["cal"]["verification_drive_mode"]: Messmodus, mit dem die Zielgröße angefahren wurde, zum Beispiel "constant_field_strength", "constant_forward_power" oder "constant_sg_level".
tem.processedData_Verification["cal"]: Ausgewertete Verifikationsdaten. Die kompakten verification_target_*-Metadaten aus den Rohdaten werden auch hier gespeichert, damit Auswerte- und Auswahlroutinen direkt auf den verarbeiteten Datensätzen arbeiten können.
tem.processedData_Verification["cal"]["reference_field"]: Frequenzindizierte Referenzfeldstärke für späteres Leveling: reference_field[freq] -> Quantity(V/m).
tem.processedData_Verification["cal"]["forward_power"]: Kompatibilitäts-Key für die frequenzindizierte Vorwärtsleistung, die zur Referenzfeldstärke gehört: forward_power[freq] -> Quantity(W). Für neue Auswertungen ist effective_reference_forward_power der eindeutigere Name.
tem.processedData_Verification["cal"]["measured_forward_power_samples"]: Gemessene Vorwärtsleistungswerte pro Frequenz und Verifikationspunkt. Im constant_forward_power-Verfahren sollten diese Werte im Idealfall gleich sein; Abweichungen beschreiben die praktische Stabilität der eingestellten Vorwärtsleistung.
tem.processedData_Verification["cal"]["measured_forward_power_mean"]: Arithmetischer Mittelwert der gemessenen Vorwärtsleistungswerte. Dieser Mittelwert ist eine Implementierungs-Schätzung der im constant_forward_power-Verfahren geforderten einen Vorwärtsleistung Pfwd.
tem.processedData_Verification["cal"]["measured_forward_power_sigma_db"]: Standardabweichung der gemessenen Vorwärtsleistungswerte in dB. Dieser Wert ist eine Diagnosegröße für die Stabilität der Vorwärtsleistung.
tem.processedData_Verification["cal"]["effective_reference_forward_power"]: Vorwärtsleistung, auf die sich reference_field tatsächlich bezieht. Im aktuellen constant_forward_power-Verfahren ist dies der arithmetische Mittelwert der gemessenen Vorwärtsleistungswerte.
tem.processedData_Verification["cal"]["field_per_sqrt_power"]: Frequenzindizierter Feldfaktor reference_field / sqrt(effective_reference_forward_power). Diese Größe ist die bevorzugte e0y-Quelle für Emissionsauswertungen aus Verifikationsdaten.
tem.processedData_Verification["cal"]["target_field"]: Ziel-Feldstärke aus der Messkonfiguration, falls bekannt.
tem.processedData_Verification["cal"]["target_forward_power"]: Auf target_field umgerechnete Vorwärtsleistung: effective_reference_forward_power * (target_field / reference_field)^2. Dieser Wert ist besonders für spätere Störfestigkeitsmessungen hilfreich, wenn die Verifikation bei einem Sollfeld, zum Beispiel 5 V/m, durchgeführt wurde, das ausgewertete reference_field aber frequenzabhängig leicht davon abweicht.
tem.processedData_Verification["cal"]["reference_field_by_scale"]: Alternative Referenzfeld-Auswertungen pro Frequenz. Die Unterkeys sind "db", "linear" und "coverage".
tem.processedData_Verification["cal"]["point_summary"]: Punktindizierte ausgewertete Werte: point_summary[point_label][freq]. Jeder Eintrag enthält den Punkt, primary_field, secondary_fields, pfwd und pbwd.
tem.processedData_Verification["cal"]["points"]: Frequenzindizierte Punktdaten: points[freq][point_label] -> list[entry].
tem.processedData_Verification["cal"]["verification"]: Vollständige Verifikationsauswertung pro Frequenz, inklusive Feldhomogenität, TEM-Mode-Kriterien und Referenzfeldvergleich.
tem.processedData_Verification["cal"]["field_uniformity_passed"]: Pass/Fail-Ergebnis der Feldhomogenität pro Frequenz.
tem.processedData_Verification["cal"]["tem_mode_passed"]: Pass/Fail-Ergebnis des TEM-Mode-Kriteriums pro Frequenz.
tem.processedData_Verification["cal"]["tem_mode_in_exception_band"]: Kennzeichnung pro Frequenz für Frequenzen, die das normale TEM-Mode-Limit nicht erfüllen, aber noch im normativen Ausnahmeband liegen. Die Gesamtzusammenfassung prüft weiterhin, ob die Anzahl dieser Frequenzen innerhalb des erlaubten Anteils bleibt.
tem.processedData_Verification["cal"]["summary"]: Gesamtzusammenfassung, unter anderem mit overall_passed, field_uniformity_passed, tem_mode_passed, tem_mode_in_exception_band_count und Exception-Zählern.
tem.processedData_Verification["cal"]["e0y_comparison"]: Informativer Vergleich zwischen gemessenem und analytischem e0y: e0y_comparison[freq][point_label].
tem.processedData_Verification["cal"]["e0y_comparison_summary"]: Frequenzweise Zusammenfassung des e0y-Vergleichs, unter anderem mit ratio_min, ratio_max, ratio_mean und delta_db_mean.
tem.processedData_Verification["cal"]["reference_dataset"]: Metadaten des aus dieser Verifikation erzeugten Referenzdatensatzes. Spätere Störfestigkeitsmessungen nutzen diese Metadaten zusammen mit reference_field und forward_power.
tem.verification_datasets["cal"]: Metadaten zur Roh-Verifikationsmessung.
tem.reference_datasets["cal"]: Metadaten zum ausgewerteten Referenzdatensatz für späteres Leveling und Störfestigkeitsmessungen.

Verifikationsberichte¶

Aus einem ausgewerteten Verifikations-Pickle kann ohne Hardwarezugriff ein vollständiges Report-Paket erzeugt werden:

python tem-verification-report.py path/to/tem-verification.p --description cal --output verification-report-cal --formats pdf html svg png

Das Kommando lädt das Pickle mit dem Kompatibilitäts-Layer und liest processedData_Verification[description]. Das Report-Verzeichnis enthält:

verification-report-cal.pdf: Mehrseitiger PDF-Bericht mit Zusammenfassung und Plots.
index.html: Statischer HTML-Bericht mit Links auf die erzeugten Grafiken und Tabellen.
figures/*.svg: Vektorplots für Referenzfeld, Vorwärtsleistung, Feldhomogenität, TEM-Mode-Kriterium, Anteil der TEM-Mode-Punktverletzungen, analytischen e0y-Vergleich und ausgewählte Punktkarten. Wenn dasselbe Pickle auch ausgewertete processedData_e0y-Daten enthält, erzeugt der Report zusätzlich measured-e0y-comparison mit dem Vergleich der gemessenen Punkt-e0y-Datensätze gegen den analytischen GTEM-Wert. Der tem-mode-q75-Plot zeigt den 75-%-Kennwert von max(E_secondary) / E_primary. Der tem-mode-failed-points-Plot zeigt den prozentualen Anteil der gültigen Punkte, bei denen max(E_secondary) / E_primary > 0.5 ist; blaue und rote Hilfslinien markieren 5 % und 25 %. Die Punktkarten zeigen die niedrigste Frequenz, die höchste Frequenz und die Frequenz mit dem größten tem_mode_q75. PNG-Kopien werden geschrieben, wenn png in --formats enthalten ist.
tables/*.tsv: Maschinenlesbare Tabellen für Summary, Referenzdaten, Exceptions, e0y-Vergleich, gemessene e0y-Datensätze und Punktwerte. summary.tsv enthält auch die kompakten verification_target_*-Metadaten. reference-data.tsv enthält unter anderem effective_reference_forward_power, field_per_sqrt_power, target_field, target_forward_power sowie tem_mode_failed_point_percent und die zugehörigen Punktzähler. measured-e0y.tsv wird gefüllt, wenn im selben Pickle ausgewertete processedData_e0y-Einträge mit analytischem Vergleich vorhanden sind.

PDF und HTML sind für schnelle Kontrolle und Archivierung gedacht. Die TSV-Dateien eignen sich besser für zusätzliche Scripts, Notebooks oder tabellenbasierte Prüfungen.

Wenn das Kommando erneut mit demselben --output-Verzeichnis ausgeführt wird, werden Dateien mit denselben generierten Namen überschrieben. Das Verzeichnis wird vorher nicht bereinigt; für einen exakt sauberen Dateibestand sollte das alte Report-Verzeichnis vorher entfernt werden.

Die fachlich bevorzugten API-Namen sind Evaluate_Verification, OutputRawData_Verification und OutputProcessedData_Verification. Sie beschreiben den Ablauf als TEM-Mode-Verifikation, deren Ergebnis als Verifikationsreferenzdaten für spätere Leveling-Schritte gespeichert wird.

Hardware-Vorlage für e0y-Messungen¶

Für den ersten realen Lauf von tem-e0y.py gibt es eine Vorlage unter conf/tem-gtem-e0y-template/conf.py. Sie schreibt alle Ausgaben in ein eigenes output-Verzeichnis, ist auf preflight_only = True gesetzt und verwendet zunächst nur eine Frequenz mit konservativem initial_sg_power_dbm. Der Preflight initialisiert Messgraph und Geräte, setzt den Startpegel bei ausgeschaltetem RF, führt RF-Off/Quit aus und überspringt Messschleife, Auswertung und Pickle-Ausgabe.

Vor dem Hardwaretest müssen die TODO-Einträge in den *-real-template.ini-Dateien, die GTEM-Geometrie, der e0y-Punkt (e0y_h oder e0y_z sowie e0y_x und e0y_y) und die Feldsondenliste names["fp"] angepasst werden. Das ergänzende Runbook conf/tem-gtem-e0y-template/HARDWARE_TEST.md beschreibt den Preflight, den ersten RF-on-Lauf mit kleinem Umfang und die anschließende Prüfung von processedData_e0y["e0y"].

Ein Block evaluation_parameters wird für dieses Script nicht benötigt. tem-e0y.py ruft Evaluate_e0y(description=...) direkt auf. Wenn ein Processed-Ausgabedateiname konfiguriert ist, schreibt das Script eine kompakte Processed-Datei, eine Punkttabelle und eine Tabelle mit dem analytischen e0y-Vergleich.

Hardware-Vorlage für Emissionsmessungen¶

Für den ersten realen Lauf von tem-emission.py gibt es eine Vorlage unter conf/tem-gtem-emission-template/conf.py. Sie schreibt alle Ausgaben in ein eigenes output-Verzeichnis, ist auf preflight_only = True gesetzt und verwendet zunächst nur eine Frequenz. Der Preflight initialisiert Messgraph und Receiver, prüft die konfigurierte e0y-/Grenzwert-Einstellung, führt RF-Off/Quit aus und überspringt Messschleife, Auswertung und Pickle-Ausgabe.

Vor dem Hardwaretest müssen die TODO-Einträge in receiver-real-template.ini, die GTEM-Geometrie, die EUT-Position, die Pfaddämpfung vom GTEM-Port zum Receiver und EMISSION_LIMIT angepasst werden. Für den ersten Preflight nutzt die Vorlage analytisches GTEM-e0y. Für rückführbare Endergebnisse sollte danach REFERENCE_PICKLE auf ein e0y- oder Verifikationspickle gesetzt und use_e0y_GTEManalytical in Mess- und Auswerteparametern auf None gestellt werden.

Das ergänzende Runbook conf/tem-gtem-emission-template/HARDWARE_TEST.md beschreibt den Preflight, den ersten kurzen Emissionslauf und die anschließende Prüfung von rawData_Emission, RemeasureRequiredFrequencies und processedData_Emission[description]["LimitComparison"].

Hardware-Vorlage für die TEM-Mode-Verifikation¶

Für den ersten realen Lauf von tem-verification.py gibt es eine Vorlage unter conf/tem-gtem-verification-template/conf.py. Sie schreibt alle Ausgaben in ein eigenes output-Verzeichnis, ist auf preflight_only = True gesetzt und verwendet zunächst nur eine Frequenz mit konservativem initial_sg_power_dbm. Der Preflight initialisiert Messgraph und Geräte, setzt den Startpegel bei ausgeschaltetem RF, führt RF-Off/Quit aus und überspringt Messschleife, Auswertung und Pickle-Ausgabe.

Vor dem Hardwaretest müssen die TODO-Einträge in den *-real-template.ini-Dateien, die GTEM-Geometrie, die Uniform Area und die Feldsondenliste names["fp"] angepasst werden. Das ergänzende Runbook conf/tem-gtem-verification-template/HARDWARE_TEST.md beschreibt den Preflight, den ersten RF-on-Lauf mit kleinem Umfang und die anschließende Prüfung von processedData_Verification["verification"].

Die Orientierung der Feldsonde sollte am Feldsondenknoten im Messgraphen konfiguriert werden. Für einfache signierte Achspermutationen wird probe_axis_map verwendet. Zum Beispiel bedeutet probe_axis_map="cell_x:-probe_y,cell_y:+probe_x,cell_z:+probe_z", dass die primäre Zell-y-Komponente aus dem probe-x-Kanal gelesen wird. Nach dem Lauf sollte ein Rohdaten-Feldsondeneintrag geprüft werden: value enthält den auf Zellachsen abgebildeten Vektor, während value_probe den ursprünglichen Sondenachsenvektor enthält.

Für beliebige Verdrehungen der Sonde kann stattdessen probe_rotation_matrix verwendet werden. Die Matrix transformiert Messwerte in Sondenachsen auf Zellachsen:

E_cell = R_cell_from_probe * E_probe

Eine 90-Grad-Drehung um die Zell-/Sonden-z-Achse kann zum Beispiel als probe_rotation_matrix="0,-1,0;1,0,0;0,0,1" angegeben werden. Die Matrix muss eine eigentliche orthonormale Rotationsmatrix mit Determinante +1 sein. Die ältere Syntax probe_axis_map bleibt für exakte Achsvertauschungen und Vorzeichenwechsel sinnvoll; intern wird sie als Spezialfall einer Rotationsmatrix behandelt.

Als besser lesbare Alternative kann dieselbe Rotation über Winkel um feste Zellachsen konfiguriert werden:

probe_rotation_angles_deg = {
    "about_cell_z": 90.0,
    "about_cell_x": 0.0,
    "about_cell_y": 0.0,
}

Die Konvention startet mit parallel ausgerichteten Sonden- und Zellachsen. Die Sonde wird dann zuerst um die feste Zell-z-Achse, anschließend um die feste Zell-x-Achse und zuletzt um die feste Zell-y-Achse gedreht. Intern werden diese Winkel in dieselbe R_cell_from_probe-Matrix umgerechnet, die auch bei probe_rotation_matrix verwendet wird.

Wichtig: In diesem Pfad ist initial_sg_power_dbm der sicherheitsrelevante konservative Startwert. target_efield ist im Messpfad mit konstanter Vorwärtsleistung kein Sicherheitslimit.

Leveling-Strategien¶

Die implementierte GTEM-Störfestigkeitsstrategie ist forward_power_from_reference. Sie bestimmt die notwendige Vorwärtsleistung am GTEM-Eingang aus reference_field und forward_power der Verifikationsreferenz und verwendet anschließend mpylab.tools.mgraph.Leveler, um den Signalgenerator so einzustellen, dass der Vorwärtsleistungsmesser diesen Zielwert sieht.

Die alternative Strategie field_probe_monitor regelt direkt auf eine Feldsonde an einer Monitorposition. Aus dem gewünschten Feld am EUT-Ort und den e0y-Werten am EUT- und Monitorort wird zuerst das Sollfeld am Monitor berechnet. Der Signalgenerator wird anschließend iterativ so eingestellt, dass die Feldsonde dieses Monitorfeld misst. e0y_source = "analytical_geometry" verwendet die analytische GTEM-Geometrie; e0y_source = "verification_reference" verwendet die gespeicherten Verifikationsreferenzdaten. Mit probe_axis_map werden einfache signierte Achspermutationen der Sonde auf Zellachsen abgebildet, zum Beispiel "cell_y": "+probe_y". Für beliebige Verdrehungen kann probe_rotation_matrix oder probe_rotation_angles_deg mit derselben Sonden-nach-Zelle-Konvention verwendet werden. Das Vorzeichen kann angegeben werden, ist bei betragsbildenden Sonden aber oft praktisch ohne Wirkung. Bei mehreren Monitor-Sonden, die im DOT-File zum Beispiel über condition frequenzabhängig aktiviert werden, muss die Orientierung zur jeweils aktiven Sonde passen. Die Orientierung kann aus der Leveling-Konfiguration, dem DOT-Knoten oder der Fieldprobe-INI gelesen werden. Widersprüchliche Angaben werden abgelehnt, damit nicht unbemerkt mit einer falschen Achsorientierung ausgewertet oder geregelt wird.

Für reale Hardwaretests sollte start_level in der Leveling-Konfiguration bewusst gesetzt werden. Der Wert ist der erste Signalgeneratorpegel der Regelung und sollte konservativ gewählt werden. Wenn start_level fehlt, kann der aktuelle Pegel des Signalgenerators über actor.GetLevel() als Komfortpfad verwendet werden, ist aber weniger eindeutig rückführbar.

Vor einem Hardwaretest kann tem-immunity.py mit preflight_only = True in der Konfiguration gestartet werden. In diesem Modus werden Messgraph und Geräte initialisiert, die Leveling-Konfiguration einschließlich field_probe_monitor geprüft und anschließend RF-Off/Quit ausgeführt. Die eigentliche Messsequenz, Auswertung und Pickle-Ausgabe werden übersprungen. Für feldsondenbasierte Pfade gibt der Preflight zusätzlich die Quelle der effektiven Sondenorientierung, die Matrix R_cell_from_probe und den daraus folgenden Ausdruck für cell_y aus, zum Beispiel cell_y = +0.707*probe_x +0.707*probe_y. Damit lässt sich direkt prüfen, ob die für Auswertung oder Regelung verwendete Zell-y-Komponente aus den gewünschten Sondenkanälen gebildet wird.

Die Leveling-Ergebnisse werden im Rohdatensatz der Störfestigkeitsmessung gespeichert, unter anderem leveling_strategy, leveling_target_monitor_field, leveling_actual_monitor_field, leveling_actor_level und leveling_samples. Damit bleibt der konkrete Regelvorgang im Pickle nachvollziehbar.

Erster Hardwaretest mit Feldsonden-Monitor¶

Für den ersten realen Lauf mit field_probe_monitor empfiehlt sich ein stufenweises Vorgehen:

Als Ausgangspunkt gibt es eine Vorlage unter conf/tem-gtem-immunity-field-probe-template/conf.py. Sie schreibt alle Ausgaben in ein eigenes output-Verzeichnis, ist auf preflight_only = True gesetzt und enthält konservative Startwerte. Vor dem Hardwaretest müssen die TODO-Einträge in den *-real-template.ini-Dateien, die GTEM-Geometrie, die Positionen und der Pfad zum Kalibrier-Pickle angepasst werden.

preflight_only = True setzen und das Script starten. Der Lauf darf nur Geräte initialisieren, die Konfiguration prüfen und anschließend RF-Off/Quit ausführen.
preflight_only = False setzen, aber start_level bewusst klein wählen. Der Startpegel sollte deutlich unterhalb des erwarteten Arbeitspegels liegen.
Für den ersten Regeltest ein kleines Prüffeld verwenden, zum Beispiel field = 0.1 oder einen anderen für den Aufbau ungefährlichen Wert.
Nach dem Lauf Log und Pickle prüfen. Besonders wichtig sind leveling_target_monitor_field, leveling_actual_monitor_field, leveling_actor_level und leveling_samples.
Erst wenn Ziel- und Ist-Monitorfeld plausibel zusammenpassen, sollte der Prüfpegel schrittweise erhöht werden.

EUT-Position bei Störfestigkeitsmessungen¶

Für tem-immunity.py kann die Position des Prüflings in den measure_parameters mit eut_h oder alternativ mit eut_z angegeben werden. eut_h ist die in der Praxis besser messbare Höhe in der GTEM-Zelle; eut_z ist die daraus über die festgelegte Geometrie berechnete Längskoordinate. Es darf nur eine der beiden Größen gesetzt werden. Positionsangaben x und y beziehen sich auf das Koordinatensystem der Zelle. Dabei ist y die absolute Höhe über der unteren GTEM-Platte bzw. dem Boden der Zelle; y = 0.25 bedeutet also 25 cm über dem Boden.

Vor der Messung zeigt die Störfestigkeitsroutine die vorhandenen Verifikationsebenen an. Wenn eine EUT-Position konfiguriert ist, werden zusätzlich die Zielposition und der Höhenabstand delta_h zur jeweiligen Ebene ausgegeben. Die Auswahl wird im Rohdatensatz unter reference_selection zusammen mit target_h, target_z und delta_h gespeichert. Die virtuelle Konfiguration setzt beispielhaft eut_h = 0.5.

Liegt die EUT-Höhe zwischen zwei vorhandenen Ebenen, bietet der Dialog zusätzlich eine Interpolation zwischen diesen Ebenen an. Dabei werden nicht die fertigen Werte für forward_power linear in der Höhe interpoliert. Stattdessen wird frequenzweise der gemessene Feldfaktor K = reference_field / sqrt(forward_power) gebildet. Für eine ideal skalierende GTEM-Zelle ist K*h näherungsweise höhenunabhängig; diese Größe wird zwischen den benachbarten Ebenen interpoliert und anschließend auf die Zielhöhe zurückgerechnet. Aus dem resultierenden Feldfaktor wird die Vorwärtsleistung für den gewünschten Prüfpegel bestimmt.

Die Interpolation wird nur angeboten, wenn für die angeforderten Messfrequenzen in beiden Ebenen gemeinsame reference_field- und forward_power-Werte vorhanden sind. Im Pickle werden bei interpolierter Auswahl zusätzlich mode = "interpolated", lower_reference, upper_reference und fraction in reference_selection abgelegt.

Immunity-Zielleistung und AM-Headroom¶

Verifikationsreferenzen können immunity_reference-Kurven enthalten, die aus required_immunity_efields erzeugt wurden. In tem-immunity.py wählt immunity_target_efield daraus die geforderte Störfestigkeits-Prüffeldstärke aus. Exakt vorhandene Zielpegel werden direkt verwendet. Zwischenwerte werden über E**2 interpoliert. Zielpegel oberhalb des größten verifizierten Pegels werden abgelehnt.

Für jede ausgewählte Frequenz speichern Roh- und Prozessdaten die gewählte immunity_reference_power_selection. Darin stehen zwei unterschiedliche Vorwärtsleistungen:

forward_power_for_required_immunity_efield: Die Vorwärtsleistung für das normale Störfestigkeits-Prüffeld.
forward_power_for_am_test_efield: Die Vorwärtsleistung für das AM-Headroom-Feld required_immunity_efield * am_headroom_factor. Mit dem Standardwert am_headroom_factor = 1.8 entspricht dies der Reserveprüfung für 80 % AM.

Der optionale Parameter headroom_check steuert, ob die Vorwärtsleistungsregelung zuerst forward_power_for_am_test_efield anfährt und anschließend für den eigentlichen Test auf forward_power_for_required_immunity_efield zurückkehrt. Der Check ist standardmäßig deaktiviert. Wenn er aktiv ist, werden die Felder leveling_headroom_check_* im Rohdatensatz gespeichert und in processedData_Immunity[description]["leveling_summary"] zusammengefasst.

Die Feldsonden-Monitor-Vorlage lässt immunity_target_efield und headroom_check bewusst deaktiviert, solange der erste Hardwaretest mit kleinem Live-Monitorfeld erfolgt. Beide Parameter sollten erst aktiviert werden, wenn das ausgewählte Verifikations-Pickle passende immunity_reference-Kurven enthält und der HF-Pfad zuvor konservativ getestet wurde.

Virtueller GTEM-Lauf¶

Aus dem Verzeichnis script kann der hardwareunabhängige Ablauf so gestartet werden:

python tem-e0y.py conf/tem-gtem-e0y-virtual/conf.py
python tem-emission.py conf/tem-gtem-emission-virtual/conf.py

Alternativ kann die Emissionsmessung nach einer virtuellen Verifikationsreferenz die Verifikationsreferenzdaten direkt als e0y-Quelle verwenden:

python tem-verification.py conf/tem-gtem-verification-virtual/conf.py
python tem-emission.py conf/tem-gtem-emission-virtual-from-verification/conf.py

Für einen virtuellen GTEM-Störfestigkeitslauf:

python tem-verification.py conf/tem-gtem-verification-virtual/conf.py
python tem-immunity.py conf/tem-gtem-immunity-virtual/conf.py

Die Live-Feldsondenstrategie kann ohne Hardware mit einer zweiten virtuellen Konfiguration getestet werden:

python tem-verification.py conf/tem-gtem-verification-virtual/conf.py
python tem-immunity.py conf/tem-gtem-immunity-virtual/conf-field-probe-monitor.py

Dieselben Abläufe können über die Qt-Oberfläche gestartet werden:

python tem-e0y-qt.py conf/tem-gtem-e0y-virtual/conf.py
python tem-emission-qt.py conf/tem-gtem-emission-virtual/conf.py
python tem-verification-qt.py conf/tem-gtem-verification-virtual/conf.py
python tem-immunity-qt.py conf/tem-gtem-immunity-virtual/conf.py

Der Stop-Button der Qt-Oberfläche verwendet denselben User-Interrupt-Pfad wie das Text-UI. Er ist damit für Entwicklung und Bedienerprobung geeignet, ersetzt aber nicht die RF-off-Behandlung in den Messroutinen.

Die erste Messung schreibt ihr Pickle nach conf/tem-gtem-e0y-virtual/output. Die virtuelle Emissionskonfiguration verwendet dieses Pickle als Eingang und schreibt ihre eigenen Ergebnisse nach conf/tem-gtem-emission-virtual/output. Bei e0y wird die Processed-Ausgabe in eine kompakte Datei und Detailtabellen aufgeteilt. out_points_tem-e0y-virtual-gtem.dat enthält eine Zeile pro Frequenz und Messpunkt mit Spalten für Feld, e0y, Vorwärtsleistung und Rückwärtsleistung. out_e0y-comparison_tem-e0y-virtual-gtem.dat enthält den Vergleich zwischen gemessenem und analytischem e0y, wenn e0y-Punkt und GTEM-Geometrie bekannt sind.

Die alternative virtuelle Emissionskonfiguration aus Referenzdaten verwendet das Pickle aus conf/tem-gtem-verification-virtual/output und schreibt ihre eigenen Ergebnisse nach conf/tem-gtem-emission-virtual-from-verification/output.

Die virtuelle Verifikationsreferenz schreibt ihr Pickle nach conf/tem-gtem-verification-virtual/output. Die virtuelle Störfestigkeitskonfiguration verwendet dieses Pickle als Eingang und schreibt ihre eigenen Ergebnisse nach conf/tem-gtem-immunity-virtual/output. Die Datei out_processed_tem-verification-verification.dat enthält dabei auch die Tabelle reference_field_comparison. Sie zeigt pro Frequenz den aktuell für das Leveling ausgewählten Referenzfeldwert sowie die Vergleichswerte db, linear und coverage. Für eine schnelle Kontrolle kann die Ausgabedatei direkt nach diesem Schlüssel durchsucht werden:

grep -n "reference_field_comparison" conf/tem-gtem-verification-virtual/output/out_processed_tem-verification-verification.dat

Die Begleitdatei out_e0y-comparison_tem-verification-verification.dat enthält den punktweisen analytischen e0y-Vergleich mit einer Zeile pro Frequenz und Verifikationspunkt. Sie ist hilfreich, um Geometrie-, Positions-, Orientierungs- oder höhere-Moden-Effekte zu erkennen, ohne das Verifikationsergebnis selbst zu verändern.

Die Processed-Textausgabe folgt der deterministischen Reihenfolge der Processed-Pickle-Schlüssel und ist für schnelle Reviews gedacht. Tiefer verschachtelte Daten wie punktweise Feldmesswerte lassen sich besser direkt aus dem Pickle untersuchen, zum Beispiel mit pexplorer.

Die virtuellen Konfigurationen verwenden ausschließlich virtuelle Gerätetreiber aus mpylab.device und synthetische Pfadkorrekturen. Sie sind daher für Entwicklung, Fehlersuche und Regressionstests ohne Laborhardware geeignet.

Tests¶

Der GTEM-Ablauf wird durch test/test_tem_scripts.py abgedeckt. Die Tests führen die virtuellen Ketten e0y -> emission und verification -> immunity mit temporären Ausgabedateien aus und prüfen, dass die resultierenden Pickles die vorherige TEMCell-Historie erhalten.

Die Tests können aus dem Repository-Wurzelverzeichnis gestartet werden:

PYTHONPATH=src:../scuq/src python -m pytest test/test_tem_scripts.py