Schutzgrenzen und Journal

Die Kanäle, die Prüfungen und die Sperren, die jeder Schreibzugriff eines Agenten teilt, und die Spur, die jede Handlung hinterlässt.

Ein Agent ist kein zweiter Weg in die Station. Jeder Aufruf landet in demselben Code, den auch die Seiten aufrufen, unter denselben Sperren, und hinterlässt dieselbe Spur wie die Handlung eines Bedieners.

Schutzgrenzen, die jeder Schreibzugriff teilt

• Dieselben Kanäle wie die Oberfläche. Änderungen an der Konfiguration laufen über dieselben Bereitstellungs- und Anwendungsfalldienste wie die Seiten, Schreibzugriffe auf die laufende Anlage laufen über die eine Warteschlange der Logik, und die Steuerung eines Laufs läuft über den Lebenszyklus von Process. Es gibt keinen zweiten Weg, über den ein Agent Prüfung, Sperren oder Journal umgehen könnte.
• Prüfung wie im Editor. Ein Upsert legt die übergebenen Parameter über die bestehende Deklaration und prüft den zusammengeführten Entwurf mit denselben Regeln, die auch die Editoren anwenden. Ein abgelehnter Upsert lässt nichts halb angewendet zurück.
• Die Projektierungssperre gilt. Solange eine Einheit von Process läuft, werden Änderungen an der Konfiguration mit einem strukturierten Ergebnis abgelehnt ("Configuration is locked while a Unit is running"), das benennt, was zuerst beendet werden muss, genau wie die Seiten sie ablehnen.
• Eine gestoppte Runtime ist schreibgeschützt. Bei gestoppter Runtime der Station arbeiten nur noch Ansehen, Status, Auflisten, Berichtsexport, die Momentaufnahme für die Sicherung und das Zurechtfinden in der Oberfläche (ui_state, ui_navigate, ui_screenshot, ui_scroll); jeder verändernde Aufruf antwortet Runtime stopped, auch wenn der Schalter seines Bereichs ein ist. Später hinzukommende Werkzeuge bleiben gesperrt, bis sie bewusst als nur lesend eingestuft werden.
• Zerstörende Werkzeuge sind gekennzeichnet. Werkzeuge, die Anlagen ansteuern oder Daten vernichten (tag_write, action_run, process_recipe_apply, process_start, process_resume, die Löschbefehle, server_stop, …), tragen die Kennzeichnung von MCP für zerstörende Werkzeuge, sodass Clients, die harmlose Werkzeuge automatisch freigeben, hier trotzdem nachfragen.

Wie Handlungen eines Agenten ins Journal kommen

Alles, was ein Agent tut, hinterlässt dieselbe Spur wie die Handlungen eines Bedieners, und zwar dort, wo Sie ohnehin nachsehen:

• Der Lebenszyklus des Endpunkts, jede Änderung an der Konfiguration von Agentenseite und jede abgewiesene Abtastung aus einem Browser werden im Bereich Agent der Konsole von Ereignisse protokolliert (logs_read filtert direkt darauf).
• Eingriffe in die laufende Anlage über die Warteschlange der Logik (Schreiben auf Variablen, Schreiben auf Tags, Ausführen von Aktionen, Quittieren von Alarmen) werden mit dem Ursprung MCP protokolliert, neben denselben Eingriffen aus der Oberfläche.
• Läufe, die ein Agent startet, stoppt, abbricht oder kommentiert, tragen Agent als handelnde Instanz in der Laufdatei und in Historien ein, damit nie der Name einer Person unter etwas steht, das sie nicht getan hat.
• Die dauerhafte Ereignishistorie ist für Agenten nur anfügend: event_history_read kann nichts leeren und nichts löschen.