So verhindern Sie PLC-Race-Conditions bei der Synchronisierung von KI-Sollwerten

PLC-Race-Conditions (Wettlaufsituationen) treten auf, wenn asynchrone externe Systeme Steuerungswerte schneller aktualisieren, als ein deterministischer, scan-basierter Controller sie konsistent auswerten kann. Die praktische Lösung ist nicht „mehr KI“, sondern disziplinierte Entkopplung: Pufferregister, Handshake-Bits und Ratenbegrenzungen, die in einer Simulation validiert werden, bevor der reale Prozess mit diesen Daten beaufschlagt wird.

KI bringt SPSen nicht deshalb zum Absturz, weil sie intelligent ist. Sie bringt sie zum Absturz, weil sie asynchron ist.

Eine SPS führt die Steuerung weiterhin in einer deterministischen Scan-Sequenz aus: Eingänge lesen, Logik ausführen, Ausgänge schreiben. Externe Optimierer, agentenbasierte Orchestrierungsschichten, OPC-UA-Clients und MQTT-Publisher teilen dieses Zeitmodell nicht. Wenn sie ohne Pufferung direkt in aktive Steuerungs-Tags schreiben, ist das Ergebnis keine Raffinesse, sondern Timing-Schulden.

In einem aktuellen internen Stresstest von Ampergon Vallis unter Verwendung von OLLA Lab führten direkte asynchrone Schreibzugriffe auf aktive PID-Sollwert-Tags in 38 % der hochfrequenten Simulationsläufe zu beobachtbaren Zustandsdivergenzen. Methodik: 10.000 simulierte Scanzyklen in einem begrenzten Ventil- und Temperaturregelkreis-Szenario, verglichen mit einer gepufferten Handshake-Baseline, getestet im März 2026. Diese Kennzahl stützt eine eng gefasste Aussage: Ungepufferte externe Schreibzugriffe können das deterministische Steuerungsverhalten in einer simulierten Hochfrequenzschleife destabilisieren. Sie erhebt keinen Anspruch auf eine branchenweite Ausfallrate über alle SPSen, Netzwerke oder Prozesse hinweg.

Diese Unterscheidung ist wichtig. In der Steuerungstechnik sind Timing-Fehler oft klein, bis sie teuer werden.

Asynchrone KI-Sollwerte verursachen Race-Conditions, weil die SPS-Logik auf einem festen Scan-Modell basiert, während externe Software-Updates nach ihrem eigenen Zeitplan eintreffen.

Nach der Programmierpraxis gemäß IEC 61131-3 wertet der Controller die Logik zyklisch aus. Das exakte Scan-Timing hängt von der Plattform, der Aufgabenstruktur und der Last ab, aber das grundlegende Verhalten ist stabil: Die SPS tastet den Zustand ab, löst die Logik und aktualisiert dann die Ausgänge. Diese Architektur ist deterministisch genug, um eine wiederholbare Steuerung zu unterstützen. Sie ist nicht dafür ausgelegt, willkürliche Änderungen während eines laufenden Zyklus durch einen externen Optimierer zu empfangen.

Ein agentenbasierter Orchestrator bezeichnet in diesem Artikel ein externes Softwaresystem, das kontinuierlich empfohlene oder optimale Steuerungswerte berechnet und diese über eine Schnittstelle wie OPC UA oder MQTT in die SPS schreibt. Dies könnte eine modellprädiktive Steuerungsschicht, ein Planungsoptimierer oder ein KI-gestützter übergeordneter Dienst sein. Die Bezeichnung ist weniger wichtig als das Verhalten: Er schreibt von außerhalb des Scans.

Die Race-Condition tritt auf, wenn das externe System ein Tag aktualisiert, während die SPS gerade dabei ist, abhängige Logik zu lösen. In der Praxis bedeutet das:

• frühe Netzwerke werten den alten Wert aus,
• spätere Netzwerke werten den neuen Wert aus,
• der physikalische Ausgang wird basierend auf einem gemischten internen Zustand geschrieben,
• und der nächste Scan beginnt mit einer Bedingung, die die Logik nicht vollständig kontrolliert hat.

Das ist ein logisches „Split-Brain“-Problem. SPSen mögen keine gespaltenen Zustände.

Ein weit verbreitetes Missverständnis ist, dass schnellere Updates immer besser sind. Das stimmt nicht. Schnellere Updates sind nur dann besser, wenn die empfangende Steuerungsarchitektur sie kohärent verarbeiten kann und wenn das finale Steuerelement reagieren kann, ohne in Schwingung, Stiction-Zyklen oder unnötigen Verschleiß getrieben zu werden.

Zustandsdivergenz ist die Diskrepanz zwischen dem logischen Zustand im Steuerungsprogramm und dem tatsächlichen Zustand des simulierten oder physischen Prozesses.

Diese Diskrepanz kann an mindestens drei Stellen auftreten:

• zwischen einem Sollwert und dem Wert, der tatsächlich von der Logik verarbeitet wird,
• zwischen dem internen Zustand der SPS und der physischen Reaktion des Aktors,
• zwischen dem Zustand des Prozessmodells und den Annahmen, die in die nächste Steuerungsberechnung einfließen.

In einem Ventilregelkreis ist der Fehlermodus leicht vorstellbar. Ein externer Optimierer schreibt einen Ventilsollwert von 50 %, dann drei Millisekunden später 52 % und kurz darauf 49 %. Die SPS verarbeitet diese Werte möglicherweise auf eine Weise, die über die Scans hinweg intern inkonsistent ist. Währenddessen hat das Ventil eine Totzone, Laufzeit und Haftreibung (Stiction). Es hat sich kaum bewegt, bevor sich der Befehl schon wieder ändert.

Die Software glaubt, sie steuert. Die Hardware ist noch dabei, den vorherigen Befehl umzusetzen.

Dies ist Zustandsdivergenz in operativen Begriffen: Der Speicher des Steuerungssystems und die Prozessausrüstung repräsentieren nicht mehr zur gleichen Zeit dieselbe Realität. Bei der Inbetriebnahme zeigt sich diese Lücke als:

• Ventil-Hunting (Pendeln),
• instabiles PID-Verhalten,
• störende Alarme,
• falsche Freigabebedingungen,
• zu frühes Fortschreiten von Sequenzschritten,
• oder, in schlimmeren Fällen, mechanische Kollisionsrisiken.

Die Unterscheidung ist einfach: Syntax versus Einsatzfähigkeit. Ein Netzwerk kann syntaktisch korrekt sein und dennoch operativ falsch, wenn seine Timing-Annahmen falsch sind.

Der Scanzyklus erzeugt versteckte Timing-Fehler, weil er den Ingenieuren ein geordnetes Ausführungsmodell innerhalb des Controllers bietet, während externe Systeme außerhalb davon ungeordnet agieren.

Ein vereinfachter SPS-Scan sieht so aus:

1. Eingänge lesen Physische und gemappte Eingangszustände werden abgetastet.
2. Logik ausführen Kontaktplan, Funktionsbausteine, Timer, Zähler, Vergleiche und PID-Berechnungen werden gemäß Aufgaben- und Scan-Reihenfolge gelöst.
3. Ausgänge schreiben Ausgangszustände werden in das Prozessabbild oder die Hardwareschnittstelle geschrieben.

Wenn eine externe Anwendung während Schritt 2 direkt in ein aktives Speicherregister schreibt, kann der Controller einen Teil des Programms mit einem Zustandsabbild und einen anderen Teil mit einem anderen auswerten. Ob dies geschieht, hängt von der Plattformarchitektur, der Kommunikationsverarbeitung, den Aufgabenprioritäten und der Speicher-Mapping-Strategie ab. Der Punkt ist nicht, dass sich jede SPS identisch verhält. Der Punkt ist, dass unkontrollierte asynchrone Schreibzugriffe eine Timing-Mehrdeutigkeit erzeugen, die die Logik nicht explizit steuert.

Diese Mehrdeutigkeit reicht aus, um Fehler zu erzeugen, selbst wenn jedes einzelne Netzwerk isoliert betrachtet vernünftig aussieht.

Deshalb legt die deterministische Steuerungstechnik immer noch großen Wert auf „langweilige“ Dinge wie Scan-Reihenfolge, Eigentümerschaft von Tags und Ein-Scan-Transfer-Disziplin. „Langweilig“ ist oft das, was verhindert, dass Maschinenteile bei hoher Geschwindigkeit kollidieren.

OLLA Lab ist hier nützlich, da es Ingenieuren eine begrenzte Umgebung bietet, um E/A-Kausalität zu beobachten, Logikänderungen zu testen und Handshake-Muster zu proben, bevor ein realer Prozess involviert ist.

Die Rolle ist spezifisch. OLLA Lab ersetzt nicht das ingenieurtechnische Urteilsvermögen, die plattformspezifische Überprüfung oder die Disziplin bei der Inbetriebnahme. Es bietet jedoch eine webbasierte Umgebung für Kontaktplan-Logik und Digital-Twin-Simulation, in der Benutzer:

• Kontaktplan-Logik im Browser erstellen,
• Simulationen sicher starten und stoppen,
• Eingänge umschalten und Ausgänge inspizieren,
• Tags und Analogwerte im Variablen-Panel überwachen,
• Timer, Zähler, Komparatoren, Mathematik und PID-Verhalten testen,
• und den Logikzustand mit realistischem simuliertem Anlagenverhalten vergleichen können.

Das macht Timing-Fehler sichtbar.

In der Praxis unterstützt das Variablen-Panel die Beobachtung von:

• aktiven Sollwert-Tags,
• Halte- oder Puffer-Tags,
• Handshake-Bits wie `New_Data_Ready`,
• Analogwerten und PID-Variablen,
• Ausgangsbefehlen,
• und szenariospezifischen Prozessreaktionen.

Der technische Vorteil ist nicht die visuelle Darstellung, sondern die Beobachtbarkeit. Wenn ein Lernender oder Ingenieur sehen kann, wie sich ein Halteregister ändert, wann der aktive Sollwert aktualisiert wird und dies mit dem simulierten Aktorverhalten vergleichen kann, wird das versteckte Timing-Problem explizit.

Hier wird OLLA Lab operativ nützlich.

Ein „Simulation-Ready“-Ingenieur ist im Sinne von Ampergon Vallis nicht jemand, der nur Kontaktplan-Syntax zeichnen kann. Es ist jemand, der Steuerungslogik beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten härten kann, bevor sie ein reales System erreicht. Das bedeutet: Ursache-Wirkungs-Zusammenhänge nachverfolgen, Fehler injizieren, Logik überarbeiten und bestätigen, dass Logikzustand und Anlagenzustand unter anormalen Bedingungen übereinstimmen.

Das ist ein besserer Standard als „es wurde fehlerfrei kompiliert“.

Sie sollten auf Diskrepanzen zwischen Befehls-Timing, Steuerungslogikzustand und physischer Reaktion achten.

Ein nützlicher Trainingsfall ist ein PID-geregelter Temperaturkreis mit einem Stellventil, bei dem ein externer Optimierer Sollwertänderungen zu häufig schreibt. Achten Sie in diesem Szenario auf:

• schnelle Änderungen des angeforderten Sollwerts,
• PID-Ausgangsbewegungen, die nie zur Ruhe kommen,
• Ventilpositionsbefehle, die sich schneller ändern, als es die reale Laufzeit erlaubt,
• Verzögerungen der Prozessvariablen, die den Optimierer zu Überkorrekturen veranlassen,
• wiederholtes Annähern an Alarmgrenzwerte ohne stabile Erholung,
• und Diskrepanzen zwischen dem aktiven Befehl der Logik und dem simulierten Ist-Wert des Ventils.

Dies ist nicht nur eine Übung in Regelungstheorie. Übermäßige Befehlsänderungen können zu Aktorverschleiß, schlechter Prozessstabilität und irreführenden Schlussfolgerungen bei der Inbetriebnahme führen. Wenn die Simulation instabil ist, weil der Befehlspfad instabil ist, sagt Ihnen der Prozess etwas Nützliches.

Die drei Standardkontrollen sind Schattenpufferung, Semaphor-Handshakes und Ratenbegrenzung.

Diese Methoden machen einen externen Optimierer nicht von sich aus „sicher“. Sie schaffen eine disziplinierte Transfergrenze, sodass die SPS Eigentümer darüber bleibt, wann und wie ein neuer Wert aktiv wird.

1. Ein-Scan-Pufferung mit Schattenregistern

Die Ein-Scan-Pufferung isoliert eingehende Daten von aktiven Steuerungs-Tags.

Das Muster ist einfach:

• das externe System schreibt in ein Halteregister, nicht in den aktiven Sollwert;
• die SPS kopiert diesen Wert an einem definierten Punkt im Scan in den aktiven Sollwert;
• die gesamte nachgelagerte Logik verwendet das aktive Tag, nicht das extern geschriebene.

Dies verhindert, dass ein Wertwechsel mitten im Scan unvorhersehbar durch das Programm sickert.

Typische Verwendung:

• `AI_Holding_SP` empfängt den externen Schreibzugriff,
• `Active_PID_SP` wird einmal unter SPS-Kontrolle aktualisiert,
• der PID-Baustein liest nur `Active_PID_SP`.

2. Semaphor-Flags mit Data-Ready-Bits

Semaphor-Logik erzwingt Eigentümerschaft und Sequenz.

Das Muster ist:

• das externe System schreibt Daten,
• es setzt ein `Data_Ready`-Bit,
• die SPS erkennt das Bit,
• überträgt und validiert die Daten,
• löscht das Bit nach der Annahme,
• und das externe System wartet auf das Löschen, bevor es den nächsten Befehl sendet.

Dies erzeugt einen einfachen Handshake. Es ist nicht glamourös, aber das sind Vorfallberichte auch nicht.

Typische Vorteile:

• verhindert überlappende Schreibzugriffe,
• bietet nachvollziehbares Annahmeverhalten,
• reduziert Mehrdeutigkeit darüber, ob ein Wert konsumiert wurde,
• unterstützt die Diagnose bei burstartiger oder verzögerter Kommunikation.

3. Ratenbegrenzung mit Timern oder Annahmefenstern

Ratenbegrenzung schützt den Prozess und das finale Steuerelement vor Befehls-Churn (übermäßiger Unruhe).

Das Muster ist:

• akzeptiere externe Updates nur in einem definierten Intervall,
• oder nur, wenn sich der Prozess in einem gültigen Zustand befindet, um sie zu empfangen,
• oder nur, wenn die angeforderte Änderung innerhalb zulässiger Grenzen liegt.

Dies kann mit einem `TON`, zyklischer Aufgabenlogik, Totzonen-Akzeptanz oder übergeordneten Freigaben implementiert werden.

Ratenbegrenzung ist wichtig, weil Aktor und Prozess physikalischen Gesetzen unterliegen. Ein Ventil, eine Klappe, ein Pumpenstrang oder ein thermischer Kreis kümmert sich nicht darum, dass ein Cloud-Optimierer alle paar Millisekunden publizieren kann.

Ein minimales Handshake-Muster trennt eingehende Daten von der aktiven Steuerung und löscht das Ready-Flag erst nach dem Transfer.

[Sprache: Kontaktplan (Ladder Diagram)] KI-Handshake-Pufferlogik

|---[ AI_Data_Ready ]----------------[ MOVE ]-------------------| | Quelle: AI_Holding_SP | Ziel: Active_PID_SP | |---[ AI_Data_Ready ]---------------------------------( U )-----| | AI_Data_Ready

Dieses Beispiel ist bewusst einfach gehalten. Reale Implementierungen fügen oft hinzu:

• Bereichsvalidierung,
• Erkennung veralteter Daten,
• Watchdog-Timer,
• Quellqualitäts-Bits,
• Modusprüfungen wie Auto/Hand,
• und Freigaben, die den Transfer während Störungen, Anlaufzuständen oder Wartungsbedingungen blockieren.

Der Punkt ist nicht, das Netzwerk zu bewundern. Der Punkt ist, die Eigentümerschaft von Zustandsübergängen zu kontrollieren.

Bild-Alt-Text: Screenshot des Ampergon Vallis Simulators, der das Variablen-Panel von OLLA Lab zeigt, wie es einen asynchronen KI-Sollwert verfolgt. Der Kontaktplan verwendet einen MOVE-Baustein und eine Rücksetz-Anweisung (Unlatch) als Semaphor-Bit, um IT-Daten mit dem deterministischen SPS-Scanzyklus zu synchronisieren.

Ingenieure sollten die Synchronisierung validieren, indem sie die Transferlogik, die Prozessreaktion und das Fehlerverhalten gemeinsam testen – nicht nur, indem sie prüfen, ob der Wert angekommen ist.

Ein solider Validierungs-Workflow umfasst:

• Definition, welches System welches Tag besitzt,
• Trennung von Halte-Tags und aktiven Steuerungs-Tags,
• Testen der normalen Update-Frequenz,
• Testen von Burst-Updates,
• Testen verzögerter oder wiederholter Pakete,
• Testen veralteter Daten,
• Testen von Modusübergängen,
• und Bestätigung, dass Alarme, Freigaben und Verriegelungen weiterhin korrekt funktionieren.

Hier hat die Digital-Twin-Simulation ihren praktischen Wert. Die Literatur zu digitalen Zwillingen und virtueller Inbetriebnahme unterstützt deren Einsatz für eine frühere Fehlererkennung, sichereres Testen anormaler Fälle und verbesserte Integrationsvalidierung (Tao et al., 2019; Uhlemann et al., 2017). Dieselbe Vorsicht gilt hier: Ein digitaler Zwilling ist nur nützlich, wenn er die Verhaltensweisen bewahrt, die für die zu testende Entscheidung wichtig sind.

Für den Anwendungsfall von Ampergon Vallis unterstützt OLLA Lab diese begrenzte Form der Validierung, indem Benutzer das Verhalten der Kontaktplan-Logik mit dem simulierten Anlagenzustand unter realistischen Szenarien vergleichen können. Das ist eine Umgebung für Inbetriebnahmeproben, kein Anspruch auf formale Sicherheitszertifizierung oder Anlagenbereitschaft.

Ingenieure sollten einen kompakten Satz an Validierungsnachweisen erstellen, der Argumentation, Fehlerbehandlung und Revisionsdisziplin zeigt.

Verwenden Sie diese Struktur:

Geben Sie an, was korrektes Verhalten in beobachtbaren Begriffen bedeutet: akzeptierte Update-Rate, stabiles Ventilverhalten, kein unbeabsichtigtes Fortschreiten der Sequenz, Alarmverhalten und akzeptables Einschwingverhalten.

Dokumentieren Sie die eingeführte anormale Bedingung: Burst-Sollwert-Schreibzugriffe, veraltete Daten, verlorenes Handshake-Löschen, ungültiger Bereich oder Modus-Diskrepanz.

Protokollieren Sie die Logikänderung: Pufferung, Semaphor-Steuerung, Timer-Gating, Validierungsprüfungen oder Umstrukturierung der Freigaben.

1. Systembeschreibung Definieren Sie die Prozesseinheit, das Steuerungsziel, wichtige E/As, Betriebsmodi und die externe Sollwertquelle.
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die relevanten Netzwerke, aktive und Halte-Tags, Handshake-Bits und die entsprechende simulierte Anlagenreaktion.
4. Der injizierte Fehlerfall
5. Die vorgenommene Revision
6. Gelernte Lektionen Erklären Sie, was fehlgeschlagen ist, warum es fehlgeschlagen ist, was die Revision behoben hat und was noch eine Feldverifizierung erfordert.

Dieser Nachweis ist weitaus nützlicher als ein Ordner voller Screenshots mit Pfeilen und Optimismus.

Die relevanten Standards und Literatur sind diejenigen, die deterministisches Steuerungsverhalten, funktionale Sicherheitsdisziplin und simulationsbasierte Validierung klären.

Nützliche Ankerpunkte sind:

• IEC 61131-3 für das SPS-Programmiermodell und den Ausführungskontext,
• IEC 61508 für die Disziplin des funktionalen Sicherheitslebenszyklus und die Notwendigkeit einer systematischen Kontrolle softwarebezogener Risiken,
• ISA-TR88 / ISA-95-nahes Denken, wo anwendbar für die Trennung von übergeordneten und Steuerungsaufgaben,
• exida-Leitfäden und Literatur zum Sicherheitslebenszyklus für den praktischen Umgang mit systematischen Fehlern und Validierungsstrenge,
• Literatur zu digitalen Zwillingen und virtueller Inbetriebnahme für den Wert und die Grenzen der Simulation vor dem Einsatz.

Kein Standard rettet ein Design, das die Eigentümerschaft von Zuständen ignoriert. Standards helfen, Disziplin zu rahmen; sie ersetzen sie nicht.

OLLA Lab passt als Proben- und Validierungsumgebung für risikoreiche Steuerungsaufgaben, die an realen Anlagen schwierig, unsicher oder teuer zu üben sind.

Dazu gehören:

• Validierung von Kontaktplan-Logik gegen simuliertes Maschinenverhalten,
• Überwachung von E/A- und Tag-Kausalität,
• Testen anormaler Bedingungen,
• Vergleich von Logikzustand mit Digital-Twin-Zustand,
• Überarbeitung der Logik nach einem Fehler,
• und Üben der Fehlersuche im Stil einer Inbetriebnahme.

Es passt nicht als Anspruch auf automatische Beschäftigungsfähigkeit, Zertifizierung, SIL-Qualifikation oder nachgewiesene Standortkompetenz. Diese erfordern breitere Nachweise, betreute Erfahrung und kontextspezifische Validierung.

Der begrenzte Anspruch ist ohnehin stärker: OLLA Lab gibt Ingenieuren einen Ort, um genau das Timing, die Sequenzierung und die Fehlerbehandlung zu üben, die reale Anlagen Anfängern verständlicherweise nicht bieten wollen.

Diese Zurückhaltung ist kein Gatekeeping. Es ist Anlagenschutz.

Die Verhinderung von SPS-Race-Conditions durch KI-Sollwerte erfordert eine Kernentscheidung: Halten Sie asynchrone externe Intelligenz außerhalb des deterministischen Herzstücks des Steuerungs-Scans, bis die SPS die Daten explizit akzeptiert und bereitgestellt hat.

Die praktischen Kontrollen sind gut verstanden:

• schreiben Sie in Halte-Tags, nicht in aktive Tags,
• übertragen Sie einmal unter SPS-Eigentümerschaft,
• verwenden Sie Handshake-Bits,
• begrenzen Sie die Annahmerate,
• und validieren Sie das vollständige Verhalten gegen eine realistische simulierte Anlagenreaktion.

Wenn Sie sich nur eine Zeile merken, dann diese: Das Problem ist nicht die Qualität des KI-Outputs allein; das Problem ist die nicht synchronisierte Eigentümerschaft von Zuständen über die Zeit.

Deshalb ist Simulation wichtig. Nicht als Theater und nicht als Ersatz für die Arbeit vor Ort, sondern als Ort, um unsichtbare Timing-Fehler sichtbar zu machen, bevor Hardware, Prozessstabilität oder Inbetriebnahmekalender das Lehrgeld zahlen.

Link UP: Um den breiteren Kontext der IT/OT-Belegschaft und Inbetriebnahme zu verstehen, lesen Sie The Future of Automation: Surviving the 425,000 Worker Void.

Link ACROSS: Timing-Fehler überschneiden sich oft mit Fehlern in der Ausführungsreihenfolge. Siehe Double-Coil Syndrome: Why Your AI Assistant Doesn't Understand Scan Cycles.

Link ACROSS: Für das Problem der Anbieter- und Dialektvielfalt hinter vielen KI-generierten Steuerungsfehlern, lesen Sie Vendor-Aware Agents: Bridging the Gap Between LLMs and Real PLCs.

Link DOWN: Um den gepufferten Sollwerttransfer und das PID-Verhalten in einer sicheren Umgebung zu testen, Open the Advanced PID & Handshake Preset in OLLA Lab.

- UP: Erkunden Sie den vollständigen Hub für KI + Industrielle Automatisierung. - ACROSS: Verwandter Artikel 1. - ACROSS: Verwandter Artikel 2. - DOWN: Starten Sie die praktische Übung in OLLA Lab.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3: Programmiersprachen - IEC 61508 Familie der Normen zur funktionalen Sicherheit - NIST AI Risk Management Framework (AI RMF 1.0) - Hintergrund zur EU-Industrie-5.0-Politik - Überblick über digitale Zwillinge (NIST)

Das Team von Ampergon Vallis Lab entwickelt Werkzeuge und Methoden zur Validierung von Steuerungslogik in einer zunehmend vernetzten, KI-gesteuerten industriellen Umgebung.

Dieser Artikel wurde auf Basis der IEC 61131-3 Standards und der internen Validierungsdaten von Ampergon Vallis Lab (März 2026) auf technische Konsistenz geprüft.