Databus vs. Database: 6 Key Questions Every IIoT Developer Must Consider

The Industrial Internet of Things (IIoT) introduces many new concepts, often building on familiar computing principles but reshaping how systems operate. Among these, the “databus” stands out as a foundational element.

The forthcoming IIC reference architecture v2 introduces a new pattern called the “layered databus.” While details are still under review, the documentation process has clarified key definitions and best practices.

Definition: A databus is a data‑centric information‑sharing technology that implements a virtual, global data space. Software applications read and update entries in this space, and updates are propagated via a publish‑subscribe mechanism.

Key characteristics:

1. The applications interact directly with the data, without intermediate wrappers.
2. The infrastructure comprehends the data, enabling selective filtering and advanced tooling.
3. The infrastructure enforces Quality‑of‑Service (QoS) guarantees such as rate, reliability, and security.

These properties lead to a series of questions that arise when introducing databus concepts to an IIoT environment. The following six sections address the most common inquiries.

Question 1: How does a databus differ from a database?

Short answer: A database stores historical data for later retrieval, whereas a databus manages live, incoming data, filtering it by the properties of new information.

Long answer: Data centricity is expressed through three dimensions:

• Interface: The data itself is the primary interface; there are no artificial wrappers such as messages or files.
• Understanding: The infrastructure can interpret the data, enabling filtering, searching, and tool integration.
• Governance: The system enforces rules for data exchange, establishing a single source of truth and managing data lifetimes, schemas, and CRUD semantics.

A relational database, for example, provides a structured storage layer that enforces consistency and offers global search. It defines the “truth” of the system because stored data cannot be corrupted or lost. A databus, on the other hand, provides a virtual global data space that lets applications write and read data streams, while the middleware applies QoS rules and delivers only the information that matches the consumer’s criteria.

Question 2: Does a databus act like a database accessed through a pub‑sub interface?

Short answer: No. A database implies persistent storage; a databus offers a purely virtual, global data space that may or may not persist data.

Long answer: Consider an intersection controller subscribing to vehicle positions within 200 m. The controller receives updates that satisfy its QoS constraints (e.g., < 0.01 s latency, 100 updates/s). The databus may deliver data directly without storing it, though temporary caching may occur to meet reliability requirements.

Question 3: What does it mean that participants directly interface with the data?

In message‑centric middleware, applications must know details about the peer, such as schema and expected update rates, which adds coupling and hampers reuse. A databus abstracts these details; applications read from or write to the data space using a CRUD interface, specifying only the data and QoS needed. The infrastructure handles source discovery, filtering, transport, and guarantees.

Question 4: How does selective filtering work in a databus compared to traditional pub‑sub?

Traditional pub‑sub merely forwards messages to subscribers, often without inspecting payloads. Even content‑filtered pub‑sub relies on simple selectors that cannot express complex QoS. A databus, by contrast, allows a subscriber to specify detailed criteria (e.g., vehicle within 200 m, moving > 10 m/s toward the intersection, 200 Hz updates). The middleware enforces these constraints at the source, throttling, dropping, or buffering data to meet the contract, and guaranteeing liveliness.

Because filtering happens at the producer, the subscriber receives only the relevant samples (e.g., 600 updates per second), drastically reducing bandwidth and processing overhead while ensuring reliability.

Question 5: How does a databus differ from a CEP engine?

Short answer: A databus is a distributed middleware that forwards data based on simple filters, whereas a CEP engine is a centralized service that evaluates complex event patterns.

Long answer: CEP engines analyze streams to detect user‑defined patterns and can trigger actions, but they require all data to be routed to a single node. A databus performs local filtering at each data source, delivering only matching samples to interested consumers, thereby scaling to thousands of nodes without central bottlenecks.

Question 6: What drove the creation of the DDS standard and databus concepts?

Early adopters in robotics, defense, and large‑scale coordination systems demanded reliability, low latency, and selective discovery in the face of component failures. These requirements led to the DDS standard, which today finds application across healthcare, transportation, smart cities, and energy sectors.

To learn more about intelligent software shaping the IIoT, download our whitepaper, The Secret Sauce of Autonomous Cars.