Skip to main content
Version: Next

What is QUBIQ?

QUBIQ is a single-stack industrial automation platform. One installation gives you:

  • Device connectivity — OPC-UA, MQTT (classic and Sparkplug B), Modbus, SNMP, raw TCP/UDP, SQL databases, MongoDB, QuestDB and IP camera media servers.
  • A tag namespace — an ISA-95-style hierarchy that models your plant, decoupled from the protocols underneath it.
  • Pipelines — a node-based dataflow editor for moving, transforming, enriching and routing data, with Python scripting where the built-in nodes stop.
  • Visualization — a browser-based screen designer with 53 widgets, 1048 P&ID and electrical symbols, vector drawing tools and a runtime (LiveView) with its own operator login.
  • A historian — time-series storage of tag values with rollups, retention and trend queries.
  • Alarming — ISA-18.2 / IEC-62682 tag alarms with acknowledgement, shelving and a journal.
  • Security — role-based access control over every action, a tamper-evident audit journal, and a separate sign-in for plant operators.

Everything runs from one installation. There is no separate database server, message broker, web server — or Python — to install alongside it.

The five things you configure

Almost all QUBIQ work is one of five activities. They stack in this order:

Five numbered steps: a connection feeds a tag, and the tag feeds a pipeline, a view, and alarms and history.Five numbered steps: a connection feeds a tag, and the tag feeds a pipeline, a view, and alarms and history.
Everything downstream refers to the tag, never to the connection.

1. Connections — where data lives

A connection is a configured endpoint: an OPC-UA server, an MQTT broker, a Postgres database, a Modbus TCP device. You create it once, QUBIQ pools and monitors it, and everything else refers to it by name. Credentials are encrypted at rest and never returned to the browser.

Connections

2. Tags — what a value means

A tag is a named point in the namespace, the folder tree that models your plant (Plant/Line1/Motor1/Speed). A tag carries engineering metadata — data type, unit, scaling, deadband, quality, format — that has nothing to do with how the value is fetched.

A protocol binding attaches the tag to a connection and an address (ns=2;s=Motor1.Speed, an MQTT topic, a Modbus register). One tag can carry more than one binding. Swap the PLC and you change the binding; every screen, alarm and history query keeps working.

Namespace & Tags

3. Pipelines — what happens to data

A pipeline is a directed graph of nodes: read a tag, transform it in Python, write it to SQL, publish it to a REST endpoint. Pipelines cover the work that is not "show a value on a screen" — batch jobs, integrations, ETL, protocol bridging, scheduled reports.

Pipelines

4. Views — how data is shown

A view is an operator screen built in the Designer: widgets on a canvas, each property optionally bound to a tag, an expression, another component's property, or a database query. Views are published inside a project and served to operators as LiveView.

Designer

5. Alarms and history — when to react, what to keep

Turning on history for a tag streams its values into the historian. Adding an alarm to a tag makes QUBIQ evaluate a condition continuously and annunciate it to operators with the full ISA-18.2 lifecycle. Both are per-tag switches — no separate alarm database to model.

Alarms · Historian

Two audiences, two identities

QUBIQ deliberately separates the people who build the system from the people who run the plant.

Platform usersRuntime users
WhoEngineers, integrators, administratorsOperators on the plant floor
Where they log inThe Platform (/login)LiveView (/{project}/login)
What they seeDesigner, pipelines, connections, settingsOnly published views for their project
Identity storeThe QUBIQ configuration databaseA User Database you point at, per project
Governed byPermissionsRuntime roles

The two are separate systems, not two roles in one system. An operator can never reach the Platform, even if someone copies their sign-in.

What runs where

QUBIQ ships as a single executable that behaves like a small fleet. Starting it launches a supervisor which spawns one OS process per service — the HTTP gateway, the pipeline engine, the historian, the alarm engine, one worker per protocol family — all talking over an embedded message bus bound to loopback on a random port. Nothing but the gateway opens a network port.

That gives you process isolation (a misbehaving Modbus driver cannot take down the web server) without asking you to install and orchestrate a dozen containers.

Architecture · The gateway and its services

What QUBIQ is not

  • Not a PLC replacement. QUBIQ supervises and integrates; it does not run deterministic real-time control loops.
  • Not a general-purpose BI tool. The historian is tuned for tag time-series, not for ad-hoc analytics over arbitrary warehouses — although named queries can read any SQL source you connect.
  • Not multi-tenant SaaS. One installation serves one site (with multiple projects inside it).

Next steps

  1. System requirements
  2. Installation
  3. First-run setup
  4. Quick start: from nothing to a live value