Measurement Routing

Measurement routing is defined in the tag configuration, that is read and cached upon module startup and every time the tag configuration changes (see ConfigModule documentation). The tag configuration is generated from the Asset Hierarchy automatically, by the Nexus platform, to ensure the desired functionality.

The possible routings are:

• Hot Path: Streams measurements directly to cloud storage, with minimal delay but also a higher cost. Applications are real-time services like dashboards, alerts, and low-latency analytics. Measurements are also stored for long-term retention with this option.

• Cold Path: Routes measurements to cloud in cost-efficient file batches, for long-term retention. The batching introduces a configurable delay, but also minimizes costs.

• Local Historian: Stores measurements in a historian database running on the edge device as a module, or alternatively within the on-premises network, for onsite trending and offline access.

• Internal: Routes the measurements to another edge module—for example, for enrichment, local calculations, or write-back.

Depending on the use case, you can send the same measurement to multiple targets—hot path for low-latency dashboards and alarms, cold path for low-cost storage, local historian for on-site trending, or other specific edge modules.

Routing can be:

• Scheduled (e.g., latest measurement routes at fixed intervals) or

• On change, where the module forwards only when a value updates.

In the figure below we have two data collector modules that read from PLCs and produce measurements. The measurements are sent to cloud and to a local historian running on the edge device, as a separate module. One of the data collectors also writing (calculated) measurements back to the PLC.

To support these scenarios, the DataDistributionModule uses different kinds of routing types.

Example of measurement routing for edge application that uses hot-, cold-, internal- and local historian routing.