Your First Real Project

The Quick Start proved the pipe works. This page is about the decisions that make the difference between a project you can hand over and one that has to be rebuilt.

Decide the namespace shape first

The tag path is the most permanent thing you will create. Screens, alarms, history, scripts and exports all reference it, and renaming a folder late means touching all of them.

Model the plant, not the network:

✅  Site1/Line1/Filler/Motor1/Speed
❌  PLC_192_168_1_10/DB12/Word4

A path organised around physical or process structure survives a PLC replacement, an IP change and a protocol migration. A path organised around addressing does not.

A workable convention, roughly ISA-95:

<Site>/<Area>/<Line or Cell>/<Equipment>/<Signal>

Rules that pay off later:

• Be consistent about case and separators. Pick PascalCase or snake_case and hold the line.
• No units in names. Speed, not Speed_RPM — the unit is a tag property.
• No source hints in names. Temperature, not OPC_Temperature.
• Keep depth even. Sibling equipment should sit at the same level, so wildcards and UDTs work.

Use user-defined types from the start

If you have twenty identical motors, do not build twenty motor folders. Define a UDT once — members, data types, units, scaling, alarm definitions, binding address templates — and stamp out instances with parameters.

UDT: Motor
  Speed        float   RPM     address: ns=2;s={Device}.Speed
  Current      float   A       address: ns=2;s={Device}.Current
  Running      bool            address: ns=2;s={Device}.Run
  Fault        bool            address: ns=2;s={Device}.Fault   alarm: on_boolean = true, priority high

Instance: Line1/Filler/Motor1   {Device} = "M101"
Instance: Line1/Filler/Motor2   {Device} = "M102"

Change the definition later and QUBIQ reconciles every instance. Instances with local overrides are reported as such rather than being silently overwritten.

→ User-defined types

Set engineering properties once, on the tag

Resist the temptation to scale, format and range-check in each widget. Put it on the tag:

Property	Why on the tag
Unit	Widgets, trends and exports all label from it
Raw/Eng scaling	Applied after the protocol read, before history — so history is in engineering units
Deadband	Keeps noise out of history and broker egress, once for every tag that uses it
Format string	Consistent display everywhere the tag appears

→ Tag properties

Separate design-time and runtime identity early

Decide before you build screens:

• Who logs into the Platform? Those are platform users with permissions.
• Who logs into LiveView? Those are runtime users in a User Database, with runtime roles.

Retro-fitting operator authentication after screens exist means revisiting every action that writes a tag. Deciding the write-security levels up front does not.

→ LiveView authentication

Structure views around navigation, not around drawing

A screen tree that mirrors the namespace is easy to navigate and easy to hand over:

Overview            plant-wide KPIs and alarm summary
Line1/Overview      line status
Line1/Filler        equipment detail
Line1/Capper        equipment detail
Diagnostics         connection health, service status

Use embedded views and flex repeaters so equipment detail is authored once and parameterised, exactly as UDTs do for tags. Twenty near-identical screens is the visualization version of twenty hand-built motors.

→ Views and layout

Write history deliberately

History is cheap to enable and expensive to store. For each tag ask:

• Does anyone trend this, or is live value enough?
• What deadband makes the trend honest without storing noise? (A 0.5–1% of span deadband typically removes 90%+ of the rows and changes no chart a human can read.)
• Does it need a store interval so a frozen signal still proves it was alive?

→ Historian configuration

Alarm rationalisation beats alarm volume

An operator who ignores the alarm banner has no alarm system. Before adding an alarm, answer:

1. Is it actionable? If nobody does anything differently, it is an event, not an alarm.
2. What priority? Reserve critical for safety and production-stopping conditions. If everything is critical, nothing is.
3. What delay and deadband? Nearly every chattering alarm is a missing on-delay or deadband.
4. What does the message tell the operator to do? Put the response in the message text.

→ Configuring alarms

Version and back up

• Take a configuration backup at each milestone, and always before an upgrade.
• Backups can be passphrase-encrypted, which is the only form that carries connection secrets.
• The audit journal records who changed what; turn it on before you have anyone else in the system, not after an incident.

A checklist before hand-over

• Namespace follows one documented convention, top to bottom
• Repeated equipment is UDT instances, not copies
• Every tag has a unit, a description and a sane data type
• History is on where it is needed, with deadbands
• Every alarm is actionable, prioritised and has an operator-facing message
• Screens reuse embedded views instead of duplicating layout
• Platform roles grant the minimum needed; nobody shares the super admin
• LiveView requires a login, and writable tags have write-security levels
• The audit journal points at an external database
• A restorable backup exists, and .env is stored separately
• Connection health and service status are visible on a diagnostics screen

Next

→ Platform architecture — how the pieces you just used fit together.