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>
3.9 KiB
Galaxy Repository Object Layout
Object Hierarchy
Galaxy objects are organized in a tree hierarchy. The root is the Galaxy itself (ZB), with objects nested under areas and other containers:
ZB (Galaxy)
├── UnassignedArea
├── DEV
│ ├── DevAppEngine
│ ├── DevPlatform
│ └── TestArea [TestArea]
│ └── DevTestObject
│ ├── TestChildObject [TestChildObject]
│ ├── TestMachine_001
│ ├── DelmiaReceiver_001 [DelmiaReceiver]
│ └── MESReceiver_001 [MESReceiver]
Objects have a tag_name (instance name, e.g. TestMachine_001) and optionally a contained_name shown in brackets (the template/type, e.g. [DelmiaReceiver]). Parent-child containment defines the deployment and organizational structure.
Contained Name vs Tag Name
Each child object has a contained_name (its local name within its parent) and a globally unique tag_name. When browsing the hierarchy, we want to see the contained name path; when referencing tags at runtime, the tag_name is used.
| Hierarchy Path (contained names) | Tag Reference (tag_name) |
|---|---|
TestMachine_001.DelmiaReceiver.DownloadPath |
DelmiaReceiver_001.DownloadPath |
TestMachine_001.MESReceiver.MoveInBatchID |
MESReceiver_001.MoveInBatchID |
The contained_name (DelmiaReceiver) is the human-readable name scoped to its parent, while the tag_name (DelmiaReceiver_001) is the system-assigned globally unique name. Translation between the two is needed when going from a hierarchy browse to tag-level data access.
Target OPC UA Server Structure
The OPC UA server should mirror the Galaxy hierarchy using contained names for folder/container structure. Attributes appear as tags within their object's container, and child objects appear as sub-containers. When an OPC UA client reads/writes a tag value, the contained name path is translated to the tag_name reference.
ZB/
└── DEV/
└── TestArea/
└── TestMachine_001/
├── MachineID → reads/writes TestMachine_001.MachineID
├── MachineCode → reads/writes TestMachine_001.MachineCode
├── DelmiaReceiver/
│ ├── DownloadPath → reads/writes DelmiaReceiver_001.DownloadPath
│ ├── JobStepNumber → reads/writes DelmiaReceiver_001.JobStepNumber
│ ├── PartNumber → reads/writes DelmiaReceiver_001.PartNumber
│ └── RecipeDownloadFlag → reads/writes DelmiaReceiver_001.RecipeDownloadFlag
└── MESReceiver/
├── MoveInBatchID → reads/writes MESReceiver_001.MoveInBatchID
├── MoveInCompleteFlag → reads/writes MESReceiver_001.MoveInCompleteFlag
├── MoveInFlag → reads/writes MESReceiver_001.MoveInFlag
└── ...
Folders (ZB, DEV, TestArea) are structural — they organize the browse tree but don't have tags. Containers (TestMachine_001, DelmiaReceiver, MESReceiver) hold both attributes (tags) and potentially child containers.
Tag (Attribute) View
Tags represent the data attributes exposed by objects. They are referenced in a flattened dot-notation format using the tag_name:
<tag_name>.<AttributeName>
Examples:
TestMachine_001.MachineIDTestMachine_001.MachineCodeMESReceiver_001.MoveInBatchIDMESReceiver_001.MoveInCompleteFlagMESReceiver_001.MoveInJobSequenceNumberDelmiaReceiver_001.DownloadPathDelmiaReceiver_001.JobStepNumberDelmiaReceiver_001.PartNumberDelmiaReceiver_001.RecipeDownloadFlag
This flat view collapses the hierarchy — all attributes across all objects appear as tag_name.AttributeName regardless of where the object sits in the containment tree.