Topic · ADX, the data infrastructure
Plant floor to enterprise.The data layerGUS.ai sits on.
ADX is the Advanced Data Infrastructure APT ships under GUS.ai. An industrial-grade software ecosystem that brings digital transformation down to earth. Modular, lightweight, open.
Chapter 15
The
data layer.
ADX is what GUS.ai sits on. What it is, what it puts on a plant network, and how it feeds the conversation.
The components
Eight pieces. Modular by design.
ADX is not one monolithic appliance. It is eight well-scoped components, each replaceable, each deployable independently. Three at the edge, five at the server. The customer adopts what they need, in the order they need it.
Ignition Edge IIoT
Edge
Sits on the plant LAN next to the PLCs. Subscribes to tags from virtually any controller. Publishes via MQTT through the Sparkplug B specification using the Cirrus Link MQTT Transmission module. Active/standby redundancy with failover in seconds (most clustered HA products fail over in minutes). Store-and-forward when WAN connectivity drops.
EventGateway
Edge · APT-built
APT-developed microservice. Translates PLC data into JSON and publishes to MQTT using connectivity and topic metadata sent from the PLC itself. Configuration-less. Push-based (PLC sends via Allen-Bradley MSG instruction), not poll-based. Not licensed by tag count. Multi-instance via MQTT5 shared subscriptions for redundancy.
PLCTagWriter
Edge · APT-built · optional
APT-developed last-mile microservice. Receives JSON from MQTT, converts it into PLC tag structure, writes the values to the PLC. NOT installed by default. The standard ADX deployment is strictly read-only. PLCTagWriter is configurable per PLC and per tag and only deployed when the customer explicitly asks.
Node-RED
Both · prototyping
Open-source low-code platform. Installed at edge and at server for prototyping new ideas and troubleshooting. No production ADX functionality depends on Node-RED. The ADX User Guide explicitly does not recommend Node-RED for long-term production use cases.
HiveMQ
Server
MQTT broker. Selected for product maturity and Industry 4.0 visibility. ADX does not use any HiveMQ-specific functionality, only generic MQTT, so the customer can swap to an existing broker (EMQX, Mosquitto, RabbitMQ, ActiveMQ) via configuration if they prefer.
Chronicler
Server
ADX-built bridge service. Parses Sparkplug B payloads and republishes them to flat MQTT topics for non-Sparkplug subscribers. Writes both time-series and event data to Museum on the ISA-95 hierarchy. Provides stored procedures for SQL clients to write to Museum directly. Tag id caching for performance. Multi-instance via MQTT5 shared subscriptions.
Museum
Server · primary storage
TimescaleDB-backed primary store for both relational and time-series data, organized as Enterprise / Site / Area / Line / Workcell within the enterprise_model schema. Application developers create their own schemas alongside and link back to the ISA-95 entities. One source of truth for every reader on top.
Grafana
Server · visualization
Real-time dashboarding and reporting. Connects to the MQTT broker as a data source so when paired with Chronicler it gives users a fully-featured, scalable dashboard platform out of the box. Included with the standard ADX deployment.
ADX User Guide · ADX Sell Sheet · CYBERSECURITY_SUMMARY.pdf
On a plant network
What ADX puts on a plant LAN. And what it does not.
What ADX puts on a plant network. Designed against IEC 62443 from day one, not retrofitted. Six architectural facts.
One outbound port
Port 8883, TCP, TLS 1.2 plus. The only firewall rule the facility needs to allow. No inbound ports open. The plant network's existing security posture stays intact.
No VPN required
MQTT over TLS provides the secure conduit. No VPN client, no IPsec tunnel, no concentrator to manage. The connection is initiated by the facility, terminates at the cloud broker.
Store-and-forward
If the WAN drops, Ignition Edge buffers data locally per the Sparkplug B specification. On reconnect, the buffer flushes in order. No gaps in the historical record.
Active/standby redundancy
Two edge gateways in active/standby pair. Automatic failover in seconds when the primary goes down. The plant keeps streaming through hardware faults without operator intervention.
Report-by-exception
Only changed values cross the wire. A 5,000-tag plant moving at typical change rates sends a fraction of the bandwidth a polling architecture would. Bandwidth is small. Exposure is small.
IEC 62443 zone and conduit
Zone: OT network (PLCs, SCADA, edge). Conduit: outbound MQTT on port 8883, encrypted, authenticated, single direction. No cross-zone inbound traffic. The standard the plant security team already uses.
CYBERSECURITY_SUMMARY.pdf · IEC 62443 alignment · Sparkplug B specification
What ADX captures
The substrate. Time-series, events, ISA-95.
Two streams of data, one storage layer, one hierarchy. ADX was designed enterprise-wide from day one. Every site connects to the same infrastructure, and any capability deployed for one machine at one site is immediately available to similar machines at every other site.
Time-series tags
ISA-95 hierarchy via Sparkplug B
Every Ignition tag flows through MQTT/Sparkplug B and lands in Museum. Tag structure parses into Enterprise / Site / Area / Line / Workcell automatically. Plant tag-name conventions stay; ADX does not impose a renaming pass. Sub-second resolution available where it matters. Chronicler also republishes onto flat MQTT topics so non-Sparkplug subscribers can consume the same stream.
Discrete events
Alarms, batches, CIPs, acknowledges
EventGateway captures events the historian alone cannot reconstruct. Alarm fire and clear, batch step transitions, CIP cycle starts and stops, operator acknowledges, recipe selections. Each event is timestamped, scoped to its ISA-95 entity, and stored in Museum so a query can pull a coherent timeline for any machine on any shift.
Museum: the primary store
TimescaleDB, ISA-95 native, SQL-compliant
Both relational and time-series data live in Museum, organized via the enterprise_model schema (Enterprises, Sites, Areas, Lines, Workcells). Application developers create their own schemas next to it and link back. A SQL-compliant database means nearly every BI tool ever written can read from it. Stored procedures let SQL clients write to it through Chronicler's tag-id cache.
ADX User Guide § Ignition Edge, EventGateway, Museum, Chronicler
The visualization layer
One data layer. Many readers.
ADX is data infrastructure, not a closed application. The operator-facing UI is Grafana out of the box, plus whatever BI tool the customer already trusts. Custom apps and microservices plug into the same MQTT bus and the same Museum schema. GUS.ai is one of those readers.
Grafana, included by default
Real-time dashboarding and reporting included with the standard ADX deployment. Grafana subscribes to the MQTT broker as a data source, so when paired with Chronicler it gives users a fully-featured, scalable dashboard platform out of the box. Tag-based real-time charts, historical trends, alarms, drilldown.
SQL access for any BI tool
Museum exposes the full ISA-95 hierarchy through standard SQL. Any business-intelligence tool that speaks SQL connects directly: Tableau, Power BI, Excel via the SQL connector, Looker. Procedures and a tag_hierarchy view ship with Chronicler so SQL clients can write back too.
Bring existing tools
MQTT is open. The data layer is open. If the customer already runs Trends, FTView SE, Tableau, or a homegrown reporting service, those tools subscribe to the same broker or query the same database. ADX does not force a migration to a single APT-only viz layer.
Custom microservices on the bus
ADX is infrastructure, so developers can write new microservices that subscribe to MQTT topics or query Museum and add capability without modifying ADX. The User Guide walks through one example (RESTer) where a PLC calls a web service through EventGateway, a custom RESTer microservice, and PLCTagWriter, end to end.
ADX User Guide · Grafana · BYO viz Trends FTView SE Tableau Excel · RESTer example
The relationship
ADX is the foundation. GUS.ai is one of its readers.
GUS.ai is not a chatbot bolted onto a vendor cloud. It reads the same Museum that Grafana dashboards read, on infrastructure built to industrial security standards, alongside any other BI tool on the stack.
One Museum, many readers
ADX writes to Museum (TimescaleDB). Grafana reads from it. SQL-compliant BI tools (Tableau, Power BI, Excel) read from it. Custom microservices read from it. GUS.ai reads from it. They all hit the same source of truth. A trend on the operator's Grafana dashboard is the same trend GUS.ai cites in an answer.
GUS.ai is one reader of fourteen
GUS.ai's 14 read-only tools (search_documents, get_trend, get_alarms, detect_anomalies, analyze_dependencies, and the rest) all hit Museum through the Operational Data Adapter. The adapter is parameterized, allowlisted, read-only. No raw SQL crosses to the cloud agent. Every query is logged with hash-chain audit.
Enterprise-wide by design
Per the ADX User Guide: individual sites all connect to the same infrastructure, so all capabilities are immediately available to all sites. A capability deployed on one machine at Site A is immediately available to similar machines at Sites B and C. As Lactalis adds plants or as APT adds reference deployments, the data layer scales without re-architecting.
Read-only by default, write-back is opt-in
PLCTagWriter exists, is documented, is APT-built, and is not installed unless the customer explicitly asks. The default ADX deployment cannot write to the PLC. GUS.ai cannot write either, by architecture. The plant control loop runs unchanged.
ADX User Guide · CYBERSECURITY_SUMMARY.pdf
End of topic · ADX, the data layer