The Namespace

The namespace is QUBIQ's model of your plant: a hierarchy of folders and tags, addressed by path.

Site1/
  Line1/
    Filler/
      Motor1/
        Speed        float   RPM
        Current      float   A
        Running      bool
      Temperature    float   °C
    Capper/
      Motor1/
        Speed        float   RPM

Every other subsystem refers to tags by this path. A widget binds to Site1/Line1/Filler/Motor1/Speed. So does an alarm, a history query, a script and an export.

Why the namespace exists

The namespace is a deliberate layer of indirection between what a value means and where it comes from.

Repoint the binding and every consumer above follows. Nothing else changes.

Replace the PLC, change protocol, re-address the register — you change the binding. Screens, alarms, history and scripts do not notice, because they never referenced the device.

Systems without this layer bind screens to addresses. They work until the first equipment change.

What is in the namespace

Node kind	Purpose
Folder	Structure. Groups equipment, areas, lines. Carries no value.
Tag	A named value with engineering metadata.
UDT instance	A folder materialised from a user-defined type — its members are ordinary tags.

A tag carries only configuration: data type, unit, description, engineering range and scaling, deadband, freshness, history settings, alarm enablement. It never stores a value. Live values live in the runtime key-value store, history in the historian.

That separation is why configuration can be exported, diffed, backed up and restored without dragging runtime state along.

→ Tag properties

Tags with and without a device

Source	Behaviour
device (default)	The value comes from a protocol binding.
internal	The value is owned by QUBIQ — a setpoint, a counter, a mode flag, a scripted result. Persisted with no expiry, writable from scripts and screens.

Internal tags are how you keep state in the namespace instead of in a database table: a recipe target, an operator-entered limit, a computed KPI.

Working with the namespace

Task	Where
Create folders and tags	The Namespace panel
Bind a tag to a device	The tag's Binding tab → Protocol bindings
Create many tags at once	Bulk import, or discovery from OPC-UA, Sparkplug, SNMP and Allen-Bradley
Model repeated equipment	User-defined types
Search across the tree	The namespace search box
Export the model	Import & Export → Export Namespace in the namespace panel (needs Export Namespace) → Bulk import & export

Naming rules that pay off

The path is the most permanent identifier in the system. Before you create the first folder:

1. Model the plant, not the network. Line1/Filler/Motor1/Speed, never PLC10/DB4/Word12.
2. One convention, everywhere. Pick a case style and hold it for the whole tree.
3. No units in names. Temperature, not Temp_C. The unit is a property.
4. No source hints in names. Speed, not OPC_Speed.
5. Even depth for siblings. Equipment of the same kind at the same level makes UDTs, wildcards and repeaters work.
6. Nouns for folders, measured quantities for tags.

Renaming and moving are both supported — but every screen, alarm and script that referenced the old path must be revisited. Get it right early.

Permissions

Action	Permission
Browse the tree, read tags and bindings	View Namespace
Create folders/nodes	Create Namespace Node
Edit, move, rename nodes	Edit Namespace Node
Delete nodes	Delete Namespace Node
Create/edit/delete tags and UDT definitions	Manage Namespace
Create/edit/enable/disable protocol bindings	Bind Protocol
Bulk import	Import Namespace
Export	Export Namespace
Refresh from source	Refresh Namespace
Change optimization settings	Progressive Loading

Note the separation: View Namespace lets an engineer read the model; Bind Protocol is what lets them point it at live equipment. Those are different levels of trust.

→ Permissions reference

Scale

The namespace is designed to stay responsive at tens of thousands of tags:

• The tree loads lazily, one level at a time, as you open folders.
• Search is indexed, not a tree walk.
• Runtime cost tracks subscribed tags, not total tags. 50,000 configured tags with 2,000 on screen behaves like a 2,000-tag system.

Two things you will notice in a deep tree: 1.0.7

• A folder that is still loading shows a spinner in place of its chevron — in every tag picker, the Tag Browser widget and the device tree of an OPC UA import. It used to flip open at once and look empty until its children arrived; in the import, a folder whose browse fails now folds back up with a message instead of staying open over nothing.
• Tag pickers show full names and scroll sideways. Each level indents the row, and a tag ten folders down used to be squeezed to an ellipsis, readable only from a tooltip. A folder's tag count stays pinned to the right edge while the names scroll under it. The Tag Browser widget on existing dashboards is unchanged.

1.0.8 The same spinner now shows in the Allen-Bradley browser and tag import, beside the folder you opened rather than in a footer line. Programs and UDTs in those browsers had no expander at all, so only the controller's own tags could be reached; they can now be opened. The OPC UA browser also keeps the folders you opened while it loads more.

The full tree, which the namespace panel loads in full namespace mode and on a refresh, is built in time proportional to the number of nodes. 1.0.8 It compared every node with every other node: about 2.5 billion comparisons per request at 50,000 tags. At very large tag counts, lazy loading is still the way to browse.

Bulk operations exist for everything that would otherwise be a loop: deleting and editing many nodes, deleting many tags, and bulk import.

Finding things, and knowing what an edit breaks

The namespace panel filters tags by condition — is:disabled, no:binding, is:unused, has:history, is:published, source:expression — and a rename or a delete shows what depends on the node before you commit to it. → Search & impact New in 1.0.4

In this section

Page	Contents
Tags	Every tag property, what it does and when to set it
Protocol bindings	Attaching tags to connections and addresses
User-defined types	Reusable, parameterised tag templates
Bulk import	Creating thousands of tags from a file or a discovery
MQTT publishing	Mirroring namespace tags out to an external broker