LiveView

LiveView is the runtime an operator sees: published views, live data, no design tooling.

https://qubiq.example.com/line1-hmi           the project's LiveView
https://qubiq.example.com/line1-hmi/login     runtime login, when identity is bound

What LiveView loads

On entry, LiveView fetches only what it needs:

Resource	Contents
Manifest	The project's structure — views, routes, settings
View resources	Each screen, by slug, on demand
Client scripts	Browser-side scripts the project defines
Gateway exports	The server-side entry points views may call

Views load lazily. A project with two hundred screens costs the same to open as one with two.

Live data

Telemetry arrives over a live connection from the realtime gateway. Sessions subscribe to the tags actually on screen, so fan-out cost tracks visible tags rather than namespace size.

Query bindings run against the project's query endpoint, which streams large result sets rather than assembling them in one piece — a table of a hundred thousand rows stays workable on a screen.

Authentication

Two modes, chosen per project:

Mode	Behaviour
Public (default)	No login. Anyone who can reach the URL sees the screens.
Bound to a User Database	/{project}/login is required; runtime roles govern access and writes.

The binding is authoritative and set only through its dedicated endpoint — never through the project manifest, so an author cannot grant access by editing a resource.

Operator identity is entirely separate from engineer identity: a different user store, and a sign-in the Platform does not accept. An operator cannot reach the Designer even if their account is given every runtime role there is.

→ LiveView authentication

Writing tags from LiveView

Two independent server-side gates:

1. The tag must be writable.
2. The operator's level must meet the tag's write level (0–3).

Both are enforced in the server's write gate. Hiding a button is a usability choice, not a security control.

Revocation is prompt: suspending an operator or changing their roles takes effect within a short cache window, without waiting for their token to expire.

Session behaviour

Situation	Behaviour
Network drops	The WebSocket reconnects and resubscribes; the screen shows the connection state.
Gateway restarts	Sessions reconnect automatically once it is back.
The sign-in expires	The operator is asked to sign in again; screen state is preserved where possible.
Operator suspended	Access is revoked within the revocation cache window.

While disconnected, values are marked stale rather than frozen — an operator must never be able to mistake a dead screen for a healthy one.

Kiosk deployment

For a permanent panel:

• Run the browser in kiosk mode at the project URL.
• Disable browser navigation UI and context menus.
• Where the panel is physically secured, a long-lived runtime session is reasonable; where it is not, keep sessions short.
• Point the panel at the local gateway address so it does not depend on plant WAN routing.
• Include a diagnostics view reachable from the home screen — connection health, service status — so a first-line question has an answer without a laptop.

Media and assets

Video streams and library images are served through QUBIQ, not fetched directly by the browser. The operator's device needs reach to the gateway only — not to the camera network or a file server.

→ Media servers

Performance on panel hardware

Symptom	Fix
Slow first load	Split large screens into embedded views; let them load on demand
Sluggish updates	Raise tag deadbands — most values do not need sub-second updates
Charts stutter	Fewer series, or a shorter window; let the historian aggregate
Video stutters	Use sub-streams for multi-camera tiles
Memory grows over a shift	Usually an unbounded table binding; page or limit the query

Differences from the Designer canvas

	Designer	LiveView
Editing	Yes	No
Data	Live	Live
Authentication	Platform user	Runtime user (or public)
Screens shown	Any view in the project	Those the runtime role permits
Chrome	Full Platform	The view only

Because both run the same components against the same data, "works in the Designer, not in LiveView" is nearly always a permission or access-policy difference, not a rendering one.

Next

→ Components · LiveView authentication