Tag Configuration

The tag configuration is set in the edge device, and defines how data is collected, interpreted, aggregated, compressed and routed from the factory floor to the cloud. Each tag has a unique name that follows a standard cloud naming standard.

A tag configuration defines the end-to-end flow for one signal. It has three parts that map to the steps the data-collector modules perform:

Input: Connects to the factory-floor data point and either polls at a fixed interval or subscribes if the source can push updates. Also supports write operations for setpoints/commands when the tag is a WriteOnly tag.
Output: Applies aggregation, resampling, and optional compression to produce the desired resolution.
Routing: Delivers measurements to the destinations that need them: other edge modules, local storage, or cloud services.

For additional information about the data collection process, see the documentation for data collector modules.

A tag configuration always has the following properties:

Id: Destination tag name according to the Cloud Platform naming standard. Must be unique.
AccessType: Determines the data direction, where the possible values are:
- ReadOnly: Data is read at the factory floor.
- WriteOnly: Data is written to the factory floor.

Input

The input configuration is used for data collection process where data is retrieved from the factory floor data source. The properties are:

MeasurementType: Declares the expected data type of the input data 1 = Analog 2 = Digital 3 = String
ModuleId: Name of the data collector module that must retrieve the data.
SourceId: An id that uniquely identifies the source.
Source: Module-specific connection details (e.g., OPC item id, Modbus address, emulator sequence, equation).
Endpoint: Used if the module supports multiple endpoints (e.g., multiple OPC UA servers or Modbus slaves). The endpoint refers to the client that is used to get the data.
SamplingRate: How often to sample the input. Format hh:mm:ss or hh:mm:ss.xxx for milliseconds.
Interpolation: How to infer values between samples, where 0=Linear (continuous values / linear interpolation), 1=StairStep (setpoints / discrete holds).

Output

The output configuration defines how the raw measurements are converted into time series with the desired resolution. It specifies whether measurements should be aggregated or compressed.

AggregationInterval: Defines the target time resolution of the output series, in the format "hh:mm:ss" or "hh:mm:ss.xxx". If no aggregation is selected, raw measurements are resampled to this resolution. A value of "00:00:00" (zero) means pass-through (no aggregation and resampling) which means that measurements are forwarded as they arrive.
Aggregation: Determines the aggregation logic applied to the raw measurements, within the time window defined by the AggregationInterval. The logic property only applies if the AggregationInterval is not zero.
- 0 = None
- 1 = TimeWeightedAverage
- 2 = ValueWeightedAverage
- 3 = Min
- 4 = Max
- 5 = Sum
- 6 = Count
- 7 = StdDev (Standard deviation)
Compression: Sets post-processing of the output time series data. Possible values are: 0 = Passthrough / no post processing 1 = SwingingDoor 2 = Deadband
CompressionDeadband: Sets the value change threshold for storing measurements, if the compression mode is set to either SwingingDoor or DeadBand.
CompressionMaxInterval: Sets the maximum time between when data should be stored, if the compression mode is set to either SwingingDoor or DeadBand.

Routes

Routes deliver measurements to the destinations that need them: other edge modules, local historians or cloud storage. The routes also define Routes define the destinations and how often measurements are forwarded.

Currently, the following route types are supported:

Internal

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

The example below shows an internal routing to 2 different modules.

{
    "type": "Internal",
    "routingInterval": "00:00:00",
    "uploadHistoryWindow": null,
    "recipientModules": [
        "MqttClientModule",
        "OrchestratorModule"   
    ]    
}

The properties are defined as this:

RoutingInterval: Defines the interval between routing measurements (using the time window defined in UploadHistoryWindow). If the interval is set to zero, measurements are routed as soon as they are generated.
UploadHistoryWindow: If set to a positive value, it defines a time window in relation to the current time. All measurements within this time windows are included when the route is triggered.
RecipientModules: Specifies the name of the modules that receives the measurements.

The Nexus platform automatically handles all routing settings, based on the Asset Hierarchy that is deployed.

If custom internal routes are used, the user is responsible for ensuring the following: * The receiving module must have an input queue with a handler that can receive a list of measurements. * The EdgeHub module must have a route for transferring measurements from the DataDistributionModule to a fictive module MyCustomModule, that should look like this:

"DataDistributionModuleRoutemycustommodule": {
            "route": "FROM /messages/modules/DataDistributionModule/outputs/routemycustommodule INTO BrokeredEndpoint(\"/modules/MyCustomModule/inputs/<queue name>\")",
            "timeToLiveSecs": 30
          }

Hot Path

Streams measurements directly to cloud storage, with minimal delay but also a higher cost. The below example shows a hot path routing.

{
    "timeToLive": "01:00:00",
    "streamToClient": true,
    "type": "HotPath",
    "routingInterval": "00:00:00",
    "uploadHistoryWindow": null
}

The properties are defined as this:

TimeToLive: If set to a non-zero value, it specifies how long time the hot path route is active, from the TimeCreated property. The format is "hh:mm:ss".
RoutingInterval: Defines the interval between routing measurements (using the time window defined in UploadHistoryWindow). If the interval is set to zero, measurements are routed as soon as they are generated.
UploadHistoryWindow: If set to a positive value, it defines a time window in relation to the current time. All measurements within this time windows are included when the route is triggered.
StreamToClient controls whether a HotPath route only streams data to clients or also writes to cloud storage.
HotPath can be used for real-time use cases such as ad-hoc trending and dashboards, and it can also forward data to the cloud. If a tag is already archived via a ColdPath, starting a HotPath that also writes to the cloud will create duplicate records.
Set StreamToClient = true when you need a temporary live stream without additional cloud storage. In this mode, the HotPath delivers data to clients only. Leave it as false if you want the HotPath to both stream and store data in the cloud.

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. The below example shows a cold path routing.

{
    "type": "ColdPath",
    "routingInterval": "00:00:00"
}

The example sets a routing interval to zero, which means that the default cold path routing interval of the device is used (set in the device configuration).

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.

The below example shows a local historian routing.

{
    "type": "LocalHistorian",
    "routingInterval": "00:01:00",
    "destination": "myHistorian"
}

The properties are defined as this:

Destination: The name of the historian to route to. The name corresponds with the name defined in the Data Connector in the Asset Hierarchy.
RoutingInterval: Defines the storage interval of the measurements, such that the storage operation is done as a bulk operation, by caching measurements within the interval. If the interval is set to zero, measurements are stored in the historian as soon as they arrive.

Refer to the Measurement Routing documentation for additional details about routes.

Example tag configurations

Below is a sample configuration of a tag named "EmualatorTag1", that is configured for the EmulatorModule. It has one static and one dynamic route.

{
    "staticConfig": {
        "version": "1.0.0",
        "configurations": [
            {
                "id": "EmulatorTag1",
                "input": {
                    "moduleId": "EmulatorModule",
                    "sourceId": "EmulatedTag1",
                    "source": "sequence;80;82;83;84;82",
                    "endpoint": null,
                    "measurementType": "Analog",
                    "interpolation": "Linear",
                    "samplingRate": "00:00:05"
                },
                "output": {
                    "aggregation": "TimeWeightedAverage",
                    "aggregationInterval": "00:01:00",
                    "compression": {
                        "outputCompression": "SwingingDoor",
                        "compressionDeadBand": 4,
                        "compressionMaxInterval": "00:01:00",
                     }
                },
                "accessType": "ReadOnly",
                "routes": [
                    {
                        "type": "ColdPath",
                        "uploadInterval": "00:00:01",
                        "routingInterval": "00:01:00"
                    }
                ]
            }
        ]
    },
    "dynamicConfig": {
        "configurations": [
            {
                "id": "EmulatorTag1",
                "routes": [
                    {
                        "timeToLive": "01:00:00",
                        "streamToClient": true,
                        "type": "HotPath",
                        "routingInterval": "00:01:00",
                        "uploadHistoryWindow": "00:01:00"
                   }
                ]
            }
        ]
    }
}

PreviousSyncConfig NextTwin Config

Last updated 10 days ago

Was this helpful?