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, scaling, deadband, quality defaults, 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
Model repeated equipment	User-defined types
Search across the tree	The namespace search box
Export the model	Export in the namespace panel (needs Export the namespace)

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 the namespace
Create folders/nodes	Create tags and folders
Edit, move, rename nodes	Edit tags and folders
Delete nodes	Delete tags and folders
Create/edit/delete tags and UDT definitions	Manage tags
Create/edit/enable/disable protocol bindings	Bind a tag to a protocol
Bulk import	Bulk import tags
Export	Export the namespace
Refresh from source	Refresh the namespace
Change optimization settings	Configure namespace optimisation

Note the separation: View the namespace lets an engineer read the model; Bind a tag to a 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 (/namespace/tree/roots, then /namespace/tree/node/{id}/children).
• 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.

Bulk operations exist for everything that would otherwise be a loop: nodes/bulk-delete, nodes/bulk-update, tags/bulk-delete, 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