Central broker deployment
In this architecture, a broker acts as the central message bus for production data exchange. Factry Historian subscribes to topics to collect time-series data instead of connecting to the datasources directly. Processed or enriched data is published back to the broker for use in other systems.
This deployment architecture is common in Unified Namespace (UNS) design patterns.
When it’s used
- Companies already deploying a centralized broker for IIoT/OT integration (Sparkplug B, lightweight sensors, edge gateways).
- When multiple IT and OT systems (CMMS, MES, ERP, analytics platforms, etc.) exchange data through a central broker.
- For decoupling: producers don’t need to know who consumes their data, and consumers don’t need to care who produces it.
- When standard interoperability with multiple data platforms is a requirement.
Architecture
Machines, PLCs, SCADA systems, and IoT devices publish process data into a central broker.
The Factry collector subscribes to specific broker topics and writes that data to Factry Historian.
The historian can also publish aggregated or processed data back to the broker, making it available to other consumers (dashboards, analytics, external systems).
Functions used
- Measurement discovery and auto-onboarding (in the case of MQTT Sparkplug B)
- Forwarders can be used to send enriched data from Factry Historian back to the broker
Benefits
- Loose coupling between producers and consumers of data.
- Highly scalable: many systems can subscribe to the same data without point-to-point integrations.
- Simplifies integration with third-party applications (cloud analytics, digital twins, AI/ML platforms).
- Promotes use of open standards (e.g. MQTT) for interoperability.
Considerations
- Requires strong governance of topic namespaces, payload formats, and quality of service levels to avoid chaos.
- Data ownership and versioning must be carefully managed.
- The broker itself becomes an additional piece of critical infrastructure that must be safeguarded against data loss. Downtime or overload will ripple across all connected systems.
- Data consumers that require both real-time and historical data now need to connect to two different systems.
Summary
A broker-centered deployment treats Factry Historian as one of many players in a publish/subscribe ecosystem. The historian collects from and contributes to a shared broker, enabling highly decoupled, scalable integration. This architecture is most powerful in environments that embrace IIoT and open interoperability standards, but it requires discipline in governance and robust broker infrastructure to succeed.