Bulk Import & Export

Building a plant model one tag at a time does not scale past a demo. QUBIQ imports and exports the whole namespace — folders, tags, bindings and alarm definitions — as a portable document.

The document is portable by design

The import/export document contains no database identifiers:

• A tag is identified by its path and name, not a UUID.
• Connections are referenced by name (connection_name, storage_connection_name), resolved to the target system's connections on import.
• If a connection of that name does not exist on the target, the binding is imported unbound rather than being silently dropped.

The consequence: a namespace exported from a development gateway imports cleanly into production, where the same logical connections have different internal identifiers.

What an item carries

Each item is a folder or a fully-specified tag:

Group	Fields
Identity	name, path (breadcrumbs), is_folder
General	data_type, description, unit, enabled, writable, write_level, source
Scaling	raw_low, raw_high, eng_low, eng_high, invert_scaling, clamp_scaled
Quality	quality_default, deadband, deadband_mode, stale_after_ms
History	enable_history, store_interval_ms, min_store_interval_ms, interpolation, storage_connection_name
Display	format_string
Binding	connection name, protocol type, address, polling mode, sampling rate, protocol config
Alarms	alarm_enabled, and full alarm definitions — mode, setpoints, priority, message, deadband, delays, latch, ack
Expression 1.0.8	The formula, evaluation mode and intervals, quality policy and dependencies of an expression tag
UDT instance 1.0.8	On an instance's root folder: its type by name, parameters and overrides. See below.

An export is therefore a complete, faithful backup of the model — not just a list of names.

Importing

Import & Export → Import Namespace in the namespace panel imports into the root; Import Into This Folder on a folder's context menu imports under that folder. Both need Import Namespace and open Restore tags from file. Each item's path is interpreted relative to the target, so the same document can be imported into Site1 or Site2 without editing.

If a tag already exists decides what happens to a collision:

Policy	Effect
Overwrite existing (default)	Replace the configuration, binding and alarms of tags that already exist.
Skip existing	Import only tags that do not exist yet; leave the rest untouched.
Rename duplicates	Import a colliding tag under a new name, e.g. Tag (1).
Abort on conflict	Refuse the whole import if any tag already exists.

Import is handled by a dedicated service so a large import does not block the interface.

A large import goes live in bulk. 1.0.8 The imported bindings are subscribed in batches, with a handful of database queries for the whole import. Each binding not yet live used to be reloaded on its own — about 150,000 queries before the first value of a 50,000-tag import — and a second namespace change during a long import queued the same bindings again.

UDT instances New in 1.0.8

An export carries the UDT types its instances need, so an instance arrives as an instance — linked to its type, with its parameters and overrides — rather than as loose folders and tags. Expression tags carry their formula; before 1.0.8 a computed tag exported as an empty shell. Formulas that read other imported tags are rewritten to follow the import's target path.

The types are dealt with before any tag is written, so a type that would be refused stops the import while you are still looking at it:

The file's type…	Result
Is new here	Created.
Matches one here exactly	Reused — a second import of the same type never duplicates it.
Differs, Overwrite existing	Replaced by the file's version. Instances here keep their tags and go out of date until synced.
Differs, Skip existing	The local type is kept; imported instances link to it, out of date.
Differs, Rename duplicates	Imported as Name (1); the local type is untouched.
Differs, Abort on conflict	The import is refused.

An instance whose folder already exists collides as one unit: skipped whole, renamed whole, or overwritten and linked to the type. An instance is marked out of date when its tags cannot be trusted to match its type — it was out of date at export, the local type was kept, or the type reads {InstancePath} and the instance landed somewhere else.

The preview. Once a file is chosen, the dialog shows what the import would do, from the same planner the import uses, and updates it when you change the policy: each type as New, Identical or Differs with a member-by-member difference, where each instance lands and whether it will be out of date, and any formula that will not compile here. It warns when a later sync would remove members — overwriting with an older type, or skipping in favour of a newer one — and disables Import when the import would be refused.

Creating or overwriting types needs Manage Namespace. Without it the tags still import, and instances link only to types that already exist here.

A build older than 1.0.8 ignores the type information and imports the instances as plain folders and tags, as before.

Typical sources

Source	How
A previous QUBIQ export	Direct — this is the round-trip case.
A spreadsheet of instrument tags	Transform into the item shape. One row per tag, with the path split into breadcrumbs.
A PLC symbol table	Export from the PLC vendor's tool, map columns to properties.
An OPC-UA server	Browse the address space and import the discovered nodes.
A Sparkplug plant	Sparkplug birth certificates already carry names, types and units — import them directly.

Before importing

1. Create the connections first, with the same names the document references.
2. Import into a scratch folder on the first attempt and inspect the result.
3. Check data types — a spreadsheet with everything as float will produce booleans that never quite work.
4. Import in stages for very large models: one area at a time is easier to verify and easier to undo.

After importing

• Look for unbound tags in the binding statistics — usually a connection-name mismatch.
• Spot-check quality on a handful of tags per connection.
• Confirm alarm definitions came across, and that they are enabled on their tags.

Exporting

Import & Export → Export Namespace in the namespace panel exports the whole tree, and Export This Folder on a folder's context menu exports that subtree, as the same document. Both need Export Namespace.

Export This Folder failed outright on every installation whose database was created recently enough. 1.0.8 The same fault made every folder report that it held no bound tags. Both are fixed.

Use it for:

Purpose	Notes
Promoting a model from development to production	Combined with matching connection names
Version control	The document is text; commit it and diff releases
Templating a standard line	Export one line, edit the paths, import as the next
Review	Reading 2,000 tags as a document beats clicking through a tree

For a full-system backup including users, connections and projects, use Backup & restore instead.

Which builds can read an export New in 1.0.4

An export carries a compatibility floor, and a build older than that floor refuses the document rather than importing it with the wrong understanding. The floor belongs to the export format itself and moves only when the shape of an exported item changes — not every time the product releases — so an export from a newer build normally still imports into an older one.

The same rule, measured per artifact, governs backup archives and view packs.

Other bulk operations

Operation	Permission
Bulk delete nodes	Delete Namespace Node
Bulk update nodes	Edit Namespace Node
Bulk delete tags	Manage Namespace
Copy a subtree	Create Namespace Node
Move a node	Edit Namespace Node
Rename a node	Edit Namespace Node

Copy takes flags for what to bring along: children, the tag configuration, the binding. Copying a folder with children and tags but without bindings is the fast way to template a second identical line and then point it at a different PLC.

Bulk delete is immediate

There is no namespace trash. Export first — an export is a one-request insurance policy against a mis-selected subtree.

Import or UDT?

Use bulk import	Use a UDT
A one-time migration from an existing system	Equipment repeated across the plant
Tags from a spreadsheet with no repeating structure	Anything you would copy and edit
Bringing in a vendor's supplied tag list	A standard you will change and re-apply later

They compose well: import the one-off instrumentation, model the repeated equipment as UDTs.

Next

→ Pipelines