2.1.5. Automated Configuration enabler

2.1.5.1. Automated configuration enabler

2.1.5.1.1. Introduction

Automated Configuration Enabler keeps heterogenous devices and services synchronised with their configurations. User can update configuration and define fallback configurations in case of errors. Self-* component will be responsible for reacting to changing environment and updating configuration as necessary

2.1.5.1.2. Features

2.1.5.1.2.1. Automated configuration

  • Enabler keeps heterogenous devices and services synchronised with their configurations.

  • User can update configuration and define its fallback versions in case of errors. Self-* component will detect if fallback configuration should be used.

  • Self-* component will be responsible for reacting to changes in the environment and updating configuration as necessary/required.

2.1.5.1.2.2. Connection of heterogenous devices

  • Various devices, groups of devices, services and other enablers will have uniform API to communicate with the Enabler.

2.1.5.1.2.3. What this Enabler is all about?

Detailed explanation of the Enabler is available within this document - self_config.pdf

2.1.5.1.2.3.1. Requirements

This interface consists of two endpoints for creating and deleting requirements:

DELETE {root}/requirements-model/{requirement_id}

POST {root}/requirements-model

{
  "id" : String,
  "labels" : LabelMap,
  "requirements" : [FunctionalityRequirement],
  "weight" : Number
}

Sample:

{
  "id" : "test1",
  "labels" : {
    "key1" : "value1"
  },
  "requirements" : [
    {
      "id" : "test2",
      "exclusive" : false
    },
    {
      "labelKey" : "key2",
      "labelValue" : "value2",
      "count" : 3,
      "exclusive" : true
    }
  ],
  "weight" : 3.0
}
2.1.5.1.2.3.1.1. Requirements JSON entities

LabelMap

A LabelMap is a mapping of label names to their values, used to verify requirements. It has the following format:

{
  "label_name" : "label_value"
}

FunctionalityRequirement

This entity describes a requirement for specific functionality, represented by a requirements model. There are two types of requirements: id-based and label-based.

  • Id-based: Requires a resource with a specified id to be available.

{
  "id" : "test2",
  "exclusive" : false
}

  • Label-based: Requires a resource with a specific label key and value to be available. The count parameter specifies how many entities are needed.

{
  "labelKey" : "key2",
  "labelValue" : "value2",
  "count" : 3,
  "exclusive" : true
}

Both types include an exclusive parameter, which determines if the resource or functionality can be shared with other requirements.

RequirementsModel

{
  "id" : String,
  "labels" : LabelMap,
  "requirements" : [FunctionalityRequirement],
  "weight" : Number
}

  • id (String): A unique identifier for the requirements model. Needs to be unique across requirements and resources.

  • labels (LabelMap): A mapping of label names to their values, used for verifying the requirements. The format of a LabelMap is a JSON object with key-value pairs, where the key is the label name and the value is the label value.

  • requirements (Array of FunctionalityRequirement): An array of FunctionalityRequirement objects, which describe specific functionality requirements needed in the requirements model. Each FunctionalityRequirement can either be id-based or label-based, and includes an exclusive parameter to indicate if the resource or functionality can be shared with other requirements.

  • weight (Number): A numeric value representing the weight or priority of the requirements model.

2.1.5.1.2.3.2. Reactions

This interface consists of two endpoints for creating and deleting reactions:

DELETE {root}/reaction-model/{reaction_id}

POST {root}/reaction-model

{
  "reactionId": String,
  "filterExpression": FilterExpression,
  "action": ReactionAction
}
2.1.5.1.2.3.2.1. Reaction JSON entities

FilterExpression

Please note that filtering happens with messages that are incoming via Kafka.

FilterExpression dictates when (or under what conditions) reaction should be triggered. There are six types in total: - ResourceIsAvailable reaction will be triggered when resource with a specific id will be available.

"filterExpression": {
  "messageType": "ResourceIsAvailable",
  "id": "element-id-1",
}

  • ResourceIsNoLongerAvailable reaction will be triggered when resources with a specific id is no longer available.

"filterExpression": {
  "messageType": "ResourceIsNoLongerAvailable",
  "id": "element-id-1",
}

  • ResourceWithLabelIsAvailable reaction will be triggered when resource with specific label is available.

{
  "messageType": "ResourceWithLabelIsAvailable",
  "labelKey": "configuration_step",
  "labelValue": "not_configured"
}

  • ResourceWithLabelIsNoLongerAvailable reaction will be triggered when resource with specific label is no longer available.

{
  "messageType": "ResourceWithLabelIsNoLongerAvailable",
  "labelKey": "configuration_step",
  "labelValue": "not_configured"
}

  • AnyEvent any event will trigger a reaction

{
  "messageType": "AnyEvent"
}

  • CustomMessageContent only message with specific, predetermined content will be triggered.

{
  "messageType": "CustomMessageContent",
  "content": "fire"
}

Reaction will be triggered when following message will be sent via Kafka topic:

{
  "messageType": "RegisterResource",
  "content": "fire"
}

ReactionAction

This entity defines what action should be taken after an event was positively filtered by FilterExpression. There are six reactions available: - SendSimpleKafkaMessage sends a message on specified kafka topic:

{
  "message": "message",
  "topic": "topic"
}

Kafka message will have following format:

{
  "trigger": String,
  "content": String
}

  • ReplaceConfiguration completely replaces current set of RequirementsModel.

{
  "requirements": [RequirementsModel]
}

  • UpsertConfiguration either updates and/or inserts non-existing requirements. If removeDangling is set to true, then it removes RequirementsModel that are not directly mentioned in the request (as requirement or dependency).

{
  "requirements": [RequirementsModel],
  "removeDangling": Boolean
}

  • ConditionalAction will either execute action if conditionalCheck is met, fallback otherwise.

{
  "conditionalCheck": Condition,
  "action": ReactionAction,
  "fallback": ReactionAction
}

  • KeepHighestWeightFunctionalities ensures that requirements with highest weight are met given available resources.

"KeepHighestWeightFunctionalities"

  • NoAction self explanatory.

"NoAction"

ReactionModel

{
  "reactionId": String,
  "filterExpression": FilterExpression,
  "action": ReactionAction
}

2.1.5.1.2.4. Kafka interface - interaction

Kafka interface is able to consumes three types of message.

2.1.5.1.2.4.1. RegisterResource
{
    "messageType": "RegisterResource",
    "resource": {
        "id": String,
        "labels": LabelMap
    }
}
2.1.5.1.2.4.2. RegisterResource
{
    "messageType": "RegisterResource",
    "resource": {
        "id": String,
        "labels": LabelMap
    }
}
2.1.5.1.2.4.3. DeregisterResource
{
  "messageType": "DeregisterResource",
  "resource": {
    "id": String,
    "labels": LabelMap
  }
}
2.1.5.1.2.4.4. CustomMessage
{
  "messageType": "CustomMessage",
  "content": String
}

2.1.5.1.3. Prerequisites

2.1.5.1.3.1. Scala

Scala is a language of preference for the SRIPAS group. Scala provides support for functional idioms and static typing. Those two features and familiarity with the language are arguments for Scala in the IoT environment, to support high reliability demand of the business.

2.1.5.1.3.2. Akka

Akka is a Scala library supporting Actor concurrency model. This library is a de facto standard for creating concurrent and/or distributed systems in Scala. Among others, Akka provides connectors for REST, MQTT, Kafka, gRPC. Akka seems like a natural fit for heterogenous and distributed environment of IoT.

2.1.5.1.3.3. Kafka

Kafka is an open-source, distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. Kafka’s high reliability seems like a good fit for internal component communication. Its large number of available connectors will also help with various analytical needs we might have.

2.1.5.1.3.4. MQTT

MQTT is an OASIS standard messaging protocol for the IoT. It is designed as an extremely lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth. Today, MQTT is used in a wide variety of industries, such as automotive, manufacturing, telecommunications, oil and gas, etc.

MQTT provides IoT specific features like Last Will and Testament. PAHO provides a broad range of MQTT clients.

2.1.5.1.4. Version control and release

The latest version is 1.0.0.

2.1.5.1.5. License

The enabler is licensed under the Apache License, Version 2.0 (the “License”).

One may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0