docs(galaxy): retire alias/SystemPlatform model — Galaxy tags are standard equipment tags

This commit is contained in:
Joseph Doherty
2026-06-12 21:17:30 -04:00
parent 499c9b9165
commit 47cb5725a9
2 changed files with 41 additions and 73 deletions
+26 -29
View File
@@ -4,17 +4,15 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
## Project Goal ## Project Goal
Build an OPC UA server (.NET 10) that exposes AVEVA System Platform Build an OPC UA server (.NET 10) that exposes industrial data sources —
(Wonderware) Galaxy tags. The server mirrors the Galaxy object including AVEVA System Platform (Wonderware) Galaxy — under a unified
hierarchy as an OPC UA address space, translating between Equipment-based address space. Galaxy access flows through the in-process
contained-name browse paths and tag-name runtime references. Galaxy `GalaxyDriver` (`src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Galaxy/`) talking gRPC
access flows through the in-process `GalaxyDriver` to a separately installed **mxaccessgw** gateway process. The gateway owns the
(`src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Galaxy/`) talking gRPC to a separately MXAccess COM bitness constraint (its worker is x86 net48); everything in this
installed **mxaccessgw** gateway process. The gateway owns the repo is .NET 10. PR 7.2 retired the legacy in-process `Galaxy.Host` /
MXAccess COM bitness constraint (its worker is x86 net48); everything `Galaxy.Proxy` / `Galaxy.Shared` projects + the `OtOpcUaGalaxyHost` Windows
in this repo is .NET 10. PR 7.2 retired the legacy in-process service.
`Galaxy.Host` / `Galaxy.Proxy` / `Galaxy.Shared` projects + the
`OtOpcUaGalaxyHost` Windows service.
See `docs/v2/Galaxy.Performance.md` for the runtime perf surface See `docs/v2/Galaxy.Performance.md` for the runtime perf surface
(tracing, metrics, soak harness). (tracing, metrics, soak harness).
@@ -32,27 +30,26 @@ See `docs/v2/Galaxy.Performance.md` for the runtime perf surface
gRPC session. The gateway owns the COM apartment + STA pump gRPC session. The gateway owns the COM apartment + STA pump
server-side; the driver speaks `MxCommand` / `MxEvent` protos server-side; the driver speaks `MxCommand` / `MxEvent` protos
exclusively. exclusively.
3. **OPC UA Server** — Exposes the hierarchy as browse nodes and 3. **OPC UA Server** — Exposes authored equipment tags as variable nodes.
attributes as variable nodes. Clients browse via contained names Galaxy tags are bound by `TagConfig.FullName` (`tag_name.AttributeName`);
but reads/writes are translated to `tag_name.AttributeName` format reads/writes/subscriptions are translated to that reference for MXAccess.
for MXAccess.
### Key Concept: Contained Name vs Tag Name ### Key Concept: Tag Name and FullName
Galaxy objects have two names: Galaxy objects have a **tag_name** — a globally unique system name used for
- **contained_name** — human-readable name scoped to parent (used for OPC UA browse tree) MXAccess read/write — and attributes are referenced as `tag_name.AttributeName`
- **tag_name** — globally unique system name (used for MXAccess read/write) (e.g. `DelmiaReceiver_001.DownloadPath`). This dot-separated reference is what
`TagConfig.FullName` stores for a Galaxy equipment tag. The Galaxy address
picker browses the live hierarchy using contained names for navigation, then
resolves the selection to the `tag_name.AttributeName` form.
Example: browsing `TestMachine_001/DelmiaReceiver/DownloadPath` translates to MXAccess reference `DelmiaReceiver_001.DownloadPath`. **Galaxy is a standard Equipment-kind driver.** Galaxy points are ordinary
equipment `Tag`s bound to `GalaxyMxGateway` via `TagConfig.FullName`
**Alias tags** (`GalaxyMxGateway`-backed equipment `Tag`s) are a lighter (`tag_name.AttributeName`), authored through the standard Tag modal + Galaxy
alternative to relay virtual tags: they store the Galaxy reference as address picker on the equipment page's Tags tab — the same flow as Modbus or
`TagConfig.FullName` (`tag_name.AttributeName`) and surface it under a UNS name S7. There is no alias machinery, no `SystemPlatform` namespace kind, and no
via a direct driver subscription, delivering native MX quality/timestamp with no relay→alias converter. See
Roslyn script. They are authored on the equipment page's **Tags** tab via the `docs/plans/2026-06-12-galaxy-standard-driver-design.md` for the full design.
"Add alias (browse Galaxy)" button. A relay→alias converter runs per-equipment
(Tags-tab toolbar) or fleet-wide at `/uns/convert-relays` (FleetAdmin-gated),
with a dry-run preview before applying.
### Data Type Mapping ### Data Type Mapping
+15 -44
View File
@@ -74,7 +74,7 @@ changed by editing the area's cluster in the Area modal, which moves the
whole branch. There is no separate "served-by" concept and no migration — whole branch. There is no separate "served-by" concept and no migration —
it is simply `UnsArea.ClusterId`. it is simply `UnsArea.ClusterId`.
### Tags vs. Galaxy / SystemPlatform tags ### Tags
Tags created on the equipment page are **equipment-bound** and require a driver Tags created on the equipment page are **equipment-bound** and require a driver
instance. The driver list on the Tags tab is scoped to the equipment's cluster instance. The driver list on the Tags tab is scoped to the equipment's cluster
@@ -82,11 +82,11 @@ and to drivers on an **Equipment-kind** namespace, so a driver-less equipment
shows no eligible drivers until you bind one (edit the equipment on the Details shows no eligible drivers until you bind one (edit the equipment on the Details
tab and pick a driver). tab and pick a driver).
**Galaxy / AVEVA System Platform tags are not shown in this tree.** They hang **Galaxy / AVEVA System Platform points are ordinary equipment tags** bound to
off the driver's folder path and are auto-materialised from the Galaxy a `GalaxyMxGateway` driver instance. Author them on the Tags tab using the
browse rather than being equipment-bound, so they stay on the **Drivers** tab standard Tag modal; the Galaxy address picker browses the live Galaxy hierarchy
of their cluster (`/clusters/{id}/drivers`), where the address picker browses so you can select the attribute and set `TagConfig.FullName`. There is no
the live Galaxy hierarchy. separate alias concept or `SystemPlatform`-kind namespace.
### Virtual tags ### Virtual tags
@@ -95,45 +95,16 @@ Add and edit virtual tags on the equipment page's **Virtual Tags** tab; the
data type is chosen from the standard OPC UA type list and the Monaco script data type is chosen from the standard OPC UA type list and the Monaco script
editor is available inline. editor is available inline.
### Alias tags ### Galaxy tags
An **alias tag** surfaces a Galaxy attribute under a friendly UNS name without `GalaxyMxGateway` is an **Equipment-kind driver** — Galaxy points are ordinary
requiring a Roslyn script. It is an ordinary equipment `Tag` bound to the equipment tags authored through the standard Tag modal, exactly like Modbus or
`GalaxyMxGateway` driver; the Galaxy reference is stored in `TagConfig` as S7 tags. The Galaxy reference is stored as `TagConfig.FullName`
`{"FullName":"tag_name.AttributeName"}`. Because the value comes from a direct (`tag_name.AttributeName`). The Galaxy address picker on the Tags tab lets you
driver subscription — not a script relay — quality and timestamp are native MX, browse the live Galaxy hierarchy to select an attribute; after selecting, set
and there is no Roslyn overhead. the tag **Name**, **DataType**, and **AccessLevel** (default: read-only). There
is no alias concept, no `SystemPlatform`-kind namespace, and no relay→alias
**Adding an alias:** on the equipment **Tags** tab, click **Add alias (browse converter.
Galaxy)**. A live Galaxy browse picker opens; navigate to the attribute you
want. After selecting it, set the tag **Name**, **DataType**, and **AccessLevel**
(default: read-only; opt in to write-through at your own discretion — writes go
through the Galaxy driver's security). The button is disabled when the
equipment's cluster has no `GalaxyMxGateway` driver instance.
In the Tags list, alias tags show an **alias** badge and their Source as
`galaxy:<tag_name.AttributeName>`. There is no new entity type or schema
migration — the alias is just a `Tag` row with `DriverType = GalaxyMxGateway`
and the `FullName` field in its JSON config.
**Relay → alias converter:** if you have existing "relay" virtual tags whose
scripts are nothing but `return ctx.GetTag("X").Value;`, a converter can
rewrite them as alias tags automatically:
- **Per-equipment** — a toolbar action on the Tags tab opens a dry-run preview
(lists what will be converted and what will be skipped), then a confirm-apply
step.
- **Fleet-wide** — `/uns/convert-relays` (FleetAdmin-gated) runs the same
dry-run + apply across all equipment in the fleet.
The converter skips and reports items it cannot safely migrate:
- virtual tags whose body is not a pure single-value relay
- virtual tags that are historized
- equipment whose cluster has no Galaxy gateway
- relay references containing `{{equip}}` tokens that cannot be resolved
The converter edits the **draft config only** — deploy normally afterward to
activate the changes.
## Bulk import ## Bulk import