Garde-fous et journalisation

Les canaux, la validation et les verrous que partage chaque écriture d'un agent, et la trace que laisse chaque action.

Un agent n'est pas une seconde porte d'entrée dans la station. Chaque appel aboutit dans le même code que celui qu'appellent les pages, sous les mêmes verrous, et laisse la même trace que l'action d'un opérateur.

Les garde-fous que partage chaque écriture

• Les mêmes canaux que l'interface. Les écritures de configuration passent par les mêmes services de mise à disposition et les mêmes cas d'utilisation que les pages, les écritures en direct empruntent l'unique file de la logique, et la conduite d'un essai emprunte le cycle de vie du Process. Il n'existe aucun chemin parallèle par lequel un agent contournerait la validation, les verrous ou la journalisation.
• Une validation d'éditeur. Un upsert fusionne les paramètres fournis avec la déclaration existante et valide le brouillon fusionné avec les règles qu'appliquent les éditeurs. Un upsert refusé ne laisse rien d'appliqué à moitié.
• Le verrou d'ingénierie s'applique. Pendant qu'une unité Process fonctionne, les changements de configuration sont refusés par un résultat structuré « Configuration is locked while a Unit is running » qui nomme ce qu'il faut terminer d'abord, exactement comme les pages les refusent.
• Un runtime arrêté est en lecture seule. Quand le runtime de la station est arrêté, seules l'inspection, l'état, les listes, l'export de rapport, la sauvegarde instantanée et l'orientation dans l'interface (ui_state, ui_navigate, ui_screenshot, ui_scroll) continuent de fonctionner; tout appel qui modifie quelque chose répond Runtime stopped, même si l'interrupteur de son domaine est actif. Un outil ajouté plus tard échoue de la même manière tant qu'il n'a pas été délibérément classé en lecture seule.
• Les outils destructeurs sont signalés. Les outils qui commandent l'équipement ou détruisent des données (tag_write, action_run, process_recipe_apply, process_start, process_resume, les suppressions, server_stop, etc.) portent l'indicateur destructif de MCP : les clients qui approuvent automatiquement les outils sans risque demandent quand même confirmation pour ceux-là.

Comment les actions d'un agent sont journalisées

Tout ce que fait un agent laisse la même trace que les actions d'un opérateur, aux endroits que vous consultez déjà :

• Le cycle de vie du point de terminaison, chaque changement de configuration venu d'un agent et chaque sondage de navigateur refusé sont journalisés dans le domaine Agent de la console de la page Événements (logs_read filtre directement dessus).
• Les opérations en direct sur la file de la logique (écritures de variables, écritures de tags, exécutions d'actions, acquittements d'alarmes) sont journalisées avec l'origine MCP, à côté des mêmes opérations faites depuis l'interface.
• Les essais qu'un agent démarre, arrête, interrompt ou commente inscrivent Agent comme auteur dans le fichier de l'essai et dans les Historiques : le nom d'une personne n'est jamais apposé sur ce qu'elle n'a pas fait.
• L'historique persistant des événements est en ajout seul pour les agents : event_history_read ne peut ni le vider ni en supprimer quoi que ce soit.