Register structure is defined in DXM Configuration Software. Names, data types, scaling, grouping, update behavior, and publishing are set there and then carried forward into MQTT as named, typed values on defined topic paths with defined payload structure.
Values from connected equipment are read into internal local registers. For example, a vibration sensor monitoring a pump or motor reports vibration and temperature values over IO-Link or Modbus. Those values are mapped into local registers, associated with register names, data types, scaling, and update behavior, and selected registers are published to an MQTT broker either within a Sparkplug topic structure or as flat MQTT topics defined in configuration.
This means signal normalization, naming, and publish intent are handled once, at the edge, rather than being recreated or reconciled downstream.
Publishing in the DXM is driven by register definition. Register definitions specify the register name, data type, scaling, update behavior, and whether a register is published. Those definitions determine exactly what MQTT subscribers receive. Registers marked for publishing are mapped either into the Sparkplug namespace as metrics grouped under a Device ID beneath the DXM’s Edge Node, or into flat MQTT as values published to explicit topic paths and payload fields.
In Sparkplug B terms, the DXM publishes as an Edge Node within a Group ID. Registers are grouped under Device IDs and published as metrics under those devices. That results in topic structures such as spBv1.0/<Group ID>/<Edge Node>/DBIRTH/<Device ID> and spBv1.0/<Group ID>/<Edge Node>/DDATA/<Device ID>, with each metric corresponding directly to a DXM register. The DXM publishes a birth message that declares the Device ID and its available metrics using the defined names, data types, and initial values, and publishes update messages as register values change.
When flat MQTT is used, each register is mapped directly to a topic path and payload field. Topic hierarchy and payload shape are defined in configuration, and values are published accordingly. In both modes, structure is defined once at the register level and then applied consistently at publish time, so consuming systems receive data that already conforms to the intended model.
With the DXM in place, register structure is defined once and enforced at the edge. Register names, data types, scaling, grouping, update behavior, and publish selection are configured in one place and then applied consistently across published outputs. Device normalization, publish structure, and topic mapping are resolved together in the DXM, so bringing new devices into an MQTT deployment becomes a configuration task instead of an integration project. The result is a simplified way to bring new devices and signals into the architecture already in use.
- Transform an entire operation's device signals into live, actionable MQTT data
- Built-in MQTT edge publishing sends data to the broker without additional publishing components
- Sparkplug B data is generated and published by the DXM, eliminating downstream republish or translation layers
- MQTT payload structure is defined at the gateway using Local Registers, not reshaped downstream
- Store-and-forward buffering maintains continuity during broker or network interruptions
- Secure outbound MQTT communication is handled by the DXM using built-in TLS and authentication options
- Free DXM Configuration Software reduces setup and change effort by consolidating configuration in one place
