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.
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
...