Commissioning API

This API is a CRUD API that allows Control Loop Type definitions created in a design environment to be commissioned on the CLAMP runtime. It has endpoints that allow Control Loop Types to be created, read, updated, and deleted.

The body of the create and update end points is a TOSCA Service/Topology template that defines the new or changed Control Loop Type. The update and delete endpoints take a reference to the Control Loop Type. The incoming TOSCA is verified and checked for referential integrity. On delete requests, a check is made to ensure that no Control Loop Instances exist for the Control Loop Type to be deleted.

Instantiation API

The instantiation API has two functions:

1. Creation, Reading, Update, and Deletion of Control Loop Instances.
2. Instantiation and lifecycle management of Control Loop Instances on participants

The Instantiation API is used by the CLAMP GUI.

Instantiation Control Loop Instance CRUD

This sub API allows for the creation, read, update, and deletion of Control Loop Instances. The endpoints for create and update take a JSON body that describes the Control Loop Instance. The endpoints for read and delete take a Control Loop Instance ID to determine which Control Loop Instance to act on. For the delete endpoint, a check is made to ensure that the Control Loop Instance is not instantiated on participants.

A call to the update endpoint for a Control Loop Instance follow the semantics described here: TOSCA Defined Control Loop: Architecture and Design.

Instantiation Control Loop Instance Lifecycle Management

This sub API is used to manage the life cycle of Control Loop Instances. A Control Loop Instance can be in the states described here: TOSCA Defined Control Loop: Architecture and Design. Managing the life cycle of a Control Loop Instance amounts to steering the Control Loop through its states.

The sub API allows upgrades and downgrades of Control Loop Instances to be pushed to participants following the semantics described here: TOSCA Defined Control Loop: Architecture and Design. When the API is used to update the participants on a Control Loop Instance, the new/upgraded/downgraded definition of the Control Loop is pushed to the participants. Note that the API asks the participants in a Control Loop Instance to perform the update, it is the responsibility of the participants to execute the update and report the result using the protocols described here: CLAMP Participants. The progress and result of an update can be monitored using the REST APIs for CLAMP Control Loops.

The sub API also allows a state change of a Control Loop Instance to be ordered. The required state of the Control Loop Instance is pushed to participants in a Control Loop Instance using the API. Note that the API asks the participants in a Control Loop Instance to perform the state change, it is the responsibility of the participants to execute the state change and report the result using the protocols described here: CLAMP Participants. The progress and result of a state change can be monitored using the REST APIs for CLAMP Control Loops.

Monitoring API

In this case it refers to monitoring the data that the participants will provide to DMaaP. Participants will send events to DMaaP which will be pulled by the CL_Supervision_Service in to the runtime database. Monitoring service provides APIs to display the statistics data from runtime database to the Monitoring GUI. The data provided should include a reference id to the control loops that are instantiated on the participant, as well as the applications that have been instantiated as a part of that control loop for that participant. Data should also include the time that the application has started, state of it (running/terminated) and any other critical information which would help to determine the health of an instantiated control loop and its components. Idea is for the participant to provide events every certain period of time, similar to a health-check, in order to provide consistent monitoring.

Pass Through API

Participant Standalone API

Participant Simulator API

3.4: Supervision

Supervision is responsible for ensuring that

1. control loops are established once their initiation has been ordered
2. control loops are running correctly once their initiation is completed
3. control loops are correctly removed once their removal has been ordered

3.4.1: Supervision Sequence Diagrams

3.4.2: Supervision APIs to other components