Joseph Doherty
32f26272ae
Five tools under one repo, all docs organized per DOCS-GUIDE.md: - aalogcli: .NET 4.8 / x86 CliFx CLI for reading System Platform binary logs (*.aaLGX) for LLM debugging, built on aaOpenSource/aaLog. Commands: last, tail, range, unread, fields. Stable JSON envelope under --llm-json. Build template under lib/build/ for rebuilding aaLogReader.dll. - aot: ArchestrA Object Toolkit 2014 v4.0 reference material. Dev guide (Markdown converted from CHM), API reference for the ArchestrA.Toolkit namespace, and the Monitor / Watchdog VS sample solutions. - graccesscli: .NET 4.8 / x86 CliFx CLI that automates Galaxy configuration via the ArchestrA GRAccess COM interop. Includes session daemon, IPC protocol, and llm-json envelope contract. - grdb: SQL/DDL exploration of the Galaxy Repository database. DDL captures, reusable queries, hierarchy / contained-name <-> tag-name translation notes. - histdb: LLM-oriented reference for AVEVA Historian retrieval. INSQL linked-server, extension tables, every wwXxx time-domain extension, every retrieval mode, alarm/event SQL recipes, REST API. Distilled from the 243-page Historian Retrieval Guide. Root contains: - CLAUDE.md: thin index pointing into each tool's README. - DOCS-GUIDE.md: doctrine for organizing docs for LLM consumption. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.6 KiB
2.6 KiB
ArchestrA Security Classifications
By default, new attributes are created with the “Free Access” security classification, which means that any user can write to them. You can restrict write access to an attribute by selecting a different security classification. For example, you can specify that the user must have a certain permission in order to write to the attribute, or that the write operation must be verified by a second user.
Important
Security classifications are only effective if security is enabled in the Galaxy.
The ArchestrA infrastructure supports the following security classifications:
| Security Classification | Description |
|---|---|
| FreeAccess | Any user can write to these attributes. Use this classification for attributes that trigger safety or time critical tasks that could be hampered by an untimely logon request. For example, halting a failing process. |
| Operate | Users need Operate permissions to write to these attributes. Use this classification for attributes that operators write to during normal day-to-day operations. |
| SecuredWrite | When writing to these attributes, users must re-enter their logon information. The new value is only written if the logon information is correct and the user has Operate permissions for the attribute. Use this classification for attributes that operators write to during normal day-to-day operations, but that require an extra level of security. |
| VerifiedWrite | When writing to these attributes, users must re-enter their logon information, and another user must confirm the write by entering his or her logon information as well. The new value is only written if the two users are different, the logon information for both users is correct, and both users have Operate permissions for the attribute. Use this classification for attributes that require very tight security and whose values should not be changed based on the decision of one person alone. |
| Tune | Users need Tune permissions to write to these attributes. Use this classification if an attribute is a configuration parameter that might be tuned by an engineer during normal system operations. For example, an alarm setpoint, PID sensitivity, etc. |
| Configure | Users need Configure permissions to write to these attributes, and the object must be OffScan for the write to succeed. Use this classification if a change to the attribute would be considered a significant configuration change. For example, the I/O addresses of an object. |
| ReadOnly | These attributes can not be written to at run time at all, regardless of the user’s permissions. |