All three features are realised as Automation Compositions, as shown in the diagram below.
draw.io Diagram border true diagramName Automation Compositions for Features simpleViewer false links auto tbstyle top lbox true diagramWidth 1037 revision 4
The ability to deploy features in a scalable, flexible and loosely coupled microservice architecture is of course a major step forward from layered architectures of the past. However, managing at "Feature" level in such architectures does present challenges. For example, to manage the three running instances of Features A to C above, 9 separate elements must be kept track of. There is nothing in the deployed system to sat what element is related to what other element, and what element are working together to realise a feature.
Automation Composition Management (ACM) is a framework that supports Life Cycle Management of Automation Compositions. It supports deployment, monitoring, update and removal of Automation Compositions en-bloc, allowing users to manage their features, services, and capabilities as single logical units.
The Automation Composition Definition concepts describe the types of things that are in the system. These concepts are defined at design time and are passed to the runtime in a TOSCA document. The concepts in the Automation Composition Runtime are created by the runtime part of the system using the definitions created at design time.
In the figure above, five participants are shown. A Configuration Persistence Participant manages Automation Composition Elements that interact with the ONAP Configuration Persistence Service to store common data. The DCAE Participant runs Automation Composition Elements that manage DCAE microservices. The Kubernetes Participant hosts the Automation Composition Elements that are managing the life cycle of microservices in Automation Compositions that are in a Kubernetes ecosystem. The Policy Participant handles the Automation Composition Elements that interact with the Policy Framework to manage policies for Automation Compositions. A Controller Participant such as the CDS Participant runs Automation Composition Elements that load metadatan And configure controllers so that they can partake in Automation Compositions. Any third party Existing System Participant can be developed to run Automation Composition Elements that interact with any existing system (such as an operator's analytic, machine learning, or artificial intelligence system) so that those systems can partake in Automation Compositions.
Using Automation Composition Management for Managing Control Loops
A Control Loop is a special case of a an Automation Composition, it is an Automation Composition in which specific Automation Composition elements must be present. Typically, there is a Monitoring (or Collection), an Analysis, a Plan, and an Execution (Controller) element. The flow of the Control Loop moves from one element to the next, iterating over time. The MAPE reference pattern for Control Loops defined by IBM in the 1990s is shown on the left hand side of the diagram below. The architectural pattern for control loops in ONAP is shown on the right hand side of the diagram.
ONAP control loops are supported as Automation Compositions by ACM. When a user assembles a Automation Composition using the Automation Composition Elements from the ONAP Control Loop architectural pattern, ACM-R can commission, instantiate and manage the life cycle of an ONAP Control Loop just like any other composition.
Management of Automation Composition Instance Configurations