ConfigModule

Purpose

The ConfigModule is responsible for storing, maintaining and distributing the tag configuration on a device. This includes both tag definitions and routing rules, aligned with the asset hierarchy deployed to the device. When a new version of the asset hierarchy is deployed, the module is responsible for pulling the latest configuration from Cloud storage, store it locally, and make it available to all edge modules.

Tag configuration

The configuration managed by the ConfigModule consists of the following:

• Tag configuration: Information about tag definition, data collection, aggregation and compression.

• Tag routes: Information about how the tag should be distributed, after collection and aggregation.

Modules like data collectors need tag definitions to determine what to collect, how to name the measurements and what aggregations to apply.

Routes define the characteristics for the distribution. A route contains the following information, that identifies how the routing should occur:

• RoutingInterval: Determines how often the routing should happen. If the value is zero or null, the route is activated each time a measurement is received.

• UploadHistoryWindow: Determines the amount of data included on each routing. If the value is zero, only the most recent measurement is routes. If the value is null (not defined), all measurements arrived since last routing are routed.

There are 4 types of routes:

• Cold path routes: Routes measurements to a storage account, for a cost effective data collection of measurements, that are not time critical.

• Hot path routes: Routes measurements to an IoT Hub, for real-time applications.

• Internal routes: Routes measurements to another module.

• Local Historian routes: Ensures that measurements are stored in a local historian, eg. for trending or offline purposes.

Routing configuration is primarily used by the DataDistributionModule that is responsible for routing the measurements to the desired destinations.

Static vs Dynamic configuration

To avoid reloading all tag configuration and routes for small changes, for example if a new tag is temporarily being hot-path streamed to cloud, the configuration is split in two parts:

• Static: long-lived tag configuration that only changes when an asset hierarchy is deployed.

• Dynamic: short-lived or on-demand tag configuration (e.g., temporary tag streaming).

Dynamic configuration has a TTL (time-to-live), which means that they automatically expire.

On an edge device, the tag configuration becomes four files:

• staticconfig.json – static tag config

• staticroutes.json – static routing rules

• dynamicconfig.json – dynamic tag config

• dynamicroutes.json – dynamic routing rules

Deployment of static and dynamic configuration.

Available Tags

Collector modules that support browsing can report what tags are discoverable on the source system. Each such module writes:

Each data collection module that supports tag browsing can report what tags are discoverable on the source system. This is also called available tags. The available tags list will be stored in a file on the edge device, under a folder with the modules name, as this example: /modulename/availabletags.json. The file is uploaded to Cloud storage, using cold path.

Tag configuration Services

In order for other modules to access configuration data, there are four types services that can be used to access different types of configuration data:

• ConfigGlobalService Read static + dynamic tag configuration for all modules on the device.

• ConfigModuleService Read static + dynamic tag configuration for one specific module (identified by module name). Use this in data collector modules so they only load their own tags.

• RouteService Read static + dynamic routes for the all modules on the device. Used by DataDistributionModule (and any module that needs the full routing view).

• AvailableTagsService Write/report available tag inventories from a data collector that supports browsing.