Overview

Currently, control loops are triggered by DCAE (Analytics) microservices, trigger a policy, which in turn triggers an action on a controller (actor). The trigger could be any component, not necessarily be a DCAE microservice.

Problem Statement

It is possible to envisage many more possible triggers for control loops, many more intermediate components as well as policy that could partake in an control loop and enrich the control loop as it proceeds, and the target of the control loop could also be metadata driven.

Business Requirement

We might wish to invoke AI, ML, or even an intermediate analytic module as part of the control loop. Therefore, the control loop could move beyond being a 3-stage control loop and become an n-stage control loop with the connections between the individual components and the algorithms, rules, or other data being used by the trigger, the intermediate components and the action component (the controller) being set using metadata passed to the control loop by CLAMP.

• The trigger could be any component, not necessarily be a DCAE microservice.

• In this PoC (Insert link from DDF when uploaded) , DCAE (DFC, PM Mapper and TCA) have been used but the intent is to generalize this approach.

• An external application collecting multiple data inputs (i.e. including external data inputs) should be able to trigger a control loop execution.

Participating Companies

Ericsson, ......

Goals

In Framkfurt, to evolve the definition of what metadata riven control loops are to a level that allows implementation to begin in the Guilin release.

To bring in direct support for:

• Mechanism for triggers, intermediate components, and controllers (actors?) to register control loop capabilities

• Mechanism for chaining an arbitrary chain of components into a control loop

• Mechanism for passing arbitrary metadata to a control loop

Contributions

Impacts

The following projects could be impacted.

SDC

A&AI

Modelling

Policy

CLAMP

Controllers

DCAE