This epic covers the work to continue to develop TOSCA Defined Control Loop from Gulin release to Honolulu release. The task is aim to provide Control Loop Service among different ONAP components with a model driven way and using a common catalog and a common artifact based on TOSCA. 

The PoC shall focus on: 

• Demonstrate Control loops defined and deployed using TOSCA
• Use a design time catalog for Control Loops for a complete storage of all the artifacts from different DT systems
• Show design time systems can populate the Design Time control loop catalog

               -DCAE-MOD interacting with the design time catalog

               -SDC interacting with the design time catalog

• Show TOSCA defined control loops being onboarded and deployed

Please see the ONAP TOSCA Control Loop documentation for the current status of this work. [TOSCA Defined Control Loops|https://docs.onap.org/projects/onap-policy-parent/en/latest/clamp/controlloop/controlloop-architecture.html]

The work will deliver the following capabilities

• Storage of Control Loop Element types in a design time catalogue
• Storage of Control Loop types in a design time catalogue
• Onboarding of Control Loop Element types from a zip file/CSAR/Yaml file containing a TOSCA service template that defines Control Loop Element types, see these examples of such TOSCA service templates here
• GUI support for composition of Control Loop Types, resulting in a Yaml file containing a TOSCA service template that defines a Control Loop type, see an example of such a TOSCA service template here.
• Composition of a Control Loop Type into a package/service that can be distributed by SDC over DMaaP, and parameterization of the common properties for the Control Loop type
• Reception of the distribution of a Control Loop Type package/service sent by SDC from DMaaP and commissioning of the Control Loop Type in the Control Loop Runtime

The work will have the following constraints

• The software should be integratable into SDC
• The software should be possible to run standalone
• The software will be developed as a new module in policy-gui
• Follow the ONAP style guide and new methodology for client development
• Use the policy-distribution component for commissioning from SDC