UNS — Global Unified-Namespace Management

The UNS page (/uns in the AdminUI) is the single surface for managing the Unified Namespace across the whole fleet. It replaces the old per-cluster UNS, Equipment, and Tags tabs and the standalone virtual-tags list — those have been removed; everything now lives in one global master tree.

The tree

The page shows every layer of the UNS as one expandable tree. Equipment is a leaf in the tree — tags, virtual tags, and alarms live on a dedicated equipment page, not inline:

Enterprise            (read-only grouping — ServerCluster.Enterprise)
└─ Site / Cluster     (read-only grouping — a ServerCluster row)
   └─ Area            (editable — UnsArea)
      └─ Line         (editable — UnsLine)
         └─ Equipment (leaf — Equipment; opens its own page)

Enterprise and Site/Cluster are read-only here. They are derived from columns on the cluster record, not entities of their own, so you create and configure clusters on the Clusters pages (/clusters). On a cluster row the ⚙ settings link jumps to that cluster. Editable UNS entities start at Area.

Count badges next to a node show how many direct children it has (for equipment, the combined tag + virtual-tag count).

Navigating

Expand all / Collapse all toggle the structural levels.
Filter by name does a case-insensitive substring match on the names of a node's direct children.

Creating and editing

Every editable row has inline actions:

Node	Actions
Cluster	+ Area
Area	+ Line, Edit, Delete
Line	+ Equipment, Edit, Delete
Equipment	Open, Delete

A + Child action pre-fills the parent for you (e.g. + Line on an area opens the Line modal with that area already selected). Build a branch top-down: Area → Line → Equipment. Tags, virtual tags, and scripted alarms are managed on the equipment page (see below).

Equipment page (`/uns/equipment/{id}`)

Clicking Open on an Equipment row (or + Equipment on a Line) navigates to the equipment page. The page is organised into four tabs:

Tab	Content
Details	Equipment identity — name, description, OPC-40010 namespace fields, driver binding, and served-by cluster. (This is the former EquipmentModal, now a full page.)
Tags	Equipment-bound driver tags. Each tag uses the driver-typed config editor (same editors as before — Modbus, S7, AB CIP, etc.) with the same client-side validation.
Virtual Tags	Virtual tags driven by C# scripts. The inline Monaco script editor with Roslyn IntelliSense, completions, and live diagnostics is available here per tag.
Alarms	Scripted-alarm definitions bound to this equipment. Create, edit, or delete predicates here; the Monaco editor is available for each predicate script.

"Add equipment" under a Line uses the URL /uns/equipment/new?lineId=..., pre-filling the parent line. Saving redirects to the new equipment's page.

Served-by cluster

An area's cluster assignment is its "served-by" cluster — the cluster node that runs it. It's set when you create the area (under a cluster) and 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 — it is simply UnsArea.ClusterId.

Tags vs. Galaxy / SystemPlatform tags

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 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 tab and pick a driver).

Galaxy / AVEVA System Platform tags are not shown in this tree. They hang off the driver's folder path and are auto-materialised from the Galaxy browse rather than being equipment-bound, so they stay on the Drivers tab of their cluster (/clusters/{id}/drivers), where the address picker browses the live Galaxy hierarchy.

Virtual tags

A virtual tag is bound to an equipment and driven by a script (no driver). 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 editor is available inline.

Alias tags

An alias tag surfaces a Galaxy attribute under a friendly UNS name without requiring a Roslyn script. It is an ordinary equipment Tag bound to the GalaxyMxGateway driver; the Galaxy reference is stored in TagConfig as {"FullName":"tag_name.AttributeName"}. Because the value comes from a direct driver subscription — not a script relay — quality and timestamp are native MX, and there is no Roslyn overhead.

Adding an alias: on the equipment Tags tab, click Add alias (browse 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

Import equipment CSV (toolbar) bulk-creates equipment across many lines and clusters in one pass. After an import the whole tree reloads.

Applying changes

Edits here change the configuration only. As the page header notes, changes apply on the next deployment — run a Deploy (Deployments page) to push them into the running address space.

7.1 KiB Raw Blame History