The CLAMP Control Loop Participant protocol is an asynchronous protocol that is used by the CLAMP runtime to coordinate life cycle management of Control Loop instances. The protocol supports the functions described in the sections below.

Protocol Dialogues

The protocol supports the dialogues described below.

Participant Registration and De-Registration

Registration when a participant comes up and update of participant with control loop type information and common parameter values for its control loop types.

@startuml
activate Participant
Participant -> Participant: Start Participant
deactivate Participant
Participant -> CLAMP_Runtime: Participant Registration
Participant <- CLAMP_Runtime: Participant Registration Ack
activate CLAMP_Runtime
loop over Control Loop Type Definitions
	CLAMP_Runtime -> CLAMP_Runtime: Collect Control Loop Element Type Definitions and\nCommon Property Values for\nParticipant Type of this Participant
end
deactivate CLAMP_Runtime
Participant <- CLAMP_Runtime: Participant Update\n[Control Loop Element Type Definitions and\nCommon Property Values for\nParticipant Type of Participant]
activate Participant
Participant -> Participant: Store Control Loop Element Type Definitions and\nCommon Property Values
Participant -> CLAMP_Runtime: Participant Update Ack
deactivate Participant

De-registration is executed as a participant goes down.

@startuml
Participant -> CLAMP_Runtime: Participant Deregistration
Participant <- CLAMP_Runtime: Participant Deregistration Ack
Participant -> Participant: Shutdown Participant

Control Loop Commissioning and Decommissioning

When a control loop is commissioned, the portion of the Control Loop Type Definition and Common Property values for the participants of each participant type mentioned in the Control Loop Definition are sent to the participants.

@startuml
Commissioning_REST -> CLAMP_Runtime: Commission Control Loop Type Defintion and\nset values of Common Properties
activate CLAMP_Runtime
loop over Participant Types in Control Loop Type Definition
	CLAMP_Runtime -> CLAMP_Runtime: Collect Control Loop Element Type Definitions and\nCommon Property Values for Participant Type
end
Participant <- CLAMP_Runtime: Participant Update\n[Control Loop Element Type Definitions and\nCommon Property Values for Participant Types]
deactivate CLAMP_Runtime
activate Participant
Participant -> Participant: Store Control Loop Element Type Definitions and\nCommon Property Values
Participant -> CLAMP_Runtime: Participant Update Ack\n[from each Participant mentioned in Participant Update message]
deactivate Participant

When a control loop is de-commissioned, the portion of the Control Loop Type Definition and Common Property values for the participants of each participant type mentioned in the Control Loop Definition are deleted participants.

@startuml
Commissioning_REST -> CLAMP_Runtime: Decommission Control Loop Type Definition
alt Control Loop Instances exist for Control Loop Type
	Commissioning_REST <- CLAMP_Runtime: Cannot decommission Control Loop Type Definition
else No Control Loop Instances exist for Control Loop Type
	Participant <- CLAMP_Runtime: Participant Update\n[Remove Control Loop Element Definitions\nfrom Participants in Control Loop]
	activate Participant
	Participant -> Participant: Delete Control Loop Element\nType Definitions and\nCommon Property Values
	Participant -> CLAMP_Runtime: Participant Update Ack [from each Participant mentioned in Participant Update message]
	deactivate Participant
end

Control Loop Update

Control Loop Update handles creation, change, and deletion of control loops on participants. Change of control loops uses a semantic versioning approach and follow the semantics described on the page TOSCA Defined Control Loop: Architecture and Design.

@startuml
Participant <- CLAMP_Runtime: Control Loop Update\n[to all Participants in Control Loop]
Participant -> CLAMP_Runtime: Control Loop Update Ack [from each Participant in Control Loop]

The handling of a ControlLoopUpdate message in a participant is as shown below.

@startuml

(*) --> "Receive Update Message"

if "Message does not mention my Participant ID" then
  --> (*)
else
  --> "Process Message"
  --> (*)
endif

@enduml

Control Loop State Change

This dialogue is used to change the state of Control Loops and their Control Loop Elements. the CLAMP Runtime sends a Control Loop State Change message on the control loop to all participants. Participants that have Control Loop Elements in that Control Loop attempt an update on the state of the control loop elements they have for that control loop, and report the result back.

@startuml
Participant <- CLAMP_Runtime: Control Loop State Change\n[to all Participants in Control Loop]
Participant -> CLAMP_Runtime: Control Loop State Change Ack [from each Participant in Control Loop]

Control Loop Monitoring and Reporting

This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Control Loop Elements, and to gather statistics on control loops. The ParticipantStatus message is sent periodically by each participant. The reporting interval for sending the message is configurable.

@startuml
Participant -> CLAMP_Runtime: Participant Status [periodically from each Participant in all Control Loops]

Messages

Participant Registration

Participant Registration Ack

Participant Update

Participant Update Ack

Participant Deregistration

Participant Deregistration Ack

Control Loop Update

Control Loop Update Ack

Control Loop State Change

Control Loop State Change

Participant Status

Participant handles 4 types of messages

1. Participant State Change : This message handles states of a participant. Runtime can order participant for a state change.
    ParticipantState can be set to one of the following
        UNKNOWN : Control Loop execution is unknown.
        PASSIVE : Control Loop execution is always rejected.
        SAFE : Control Loop execution proceeds, but changes to domain state or context are not carried out.
                   The participant returns an indication that it is running in SAFE mode together with the action it would
                   have performed if it was operating in ACTIVE mode.
        TEST : Control Loop execution proceeds and changes to domain and state are carried out in a test environment.
                   The participant returns an indication that it is running in TEST mode together with the action it has performed
                   on the test environment
        ACTIVE : Control Loop execution is executed in the live environment by the participant.
        TERMINATED : Control Loop execution is terminated and not available.

2. Control Loop Update: This message creates the control loop elements and brings them from UNINITIALIZED to PASSIVE state.
    ControlLoopUpdate message contains full ToscaServiceTemplate describing all components participating in a control loop.
    This acts as a template for any control loop to be created according to the template.
    When participant-intermediary receives this message, it triggers creation of policy-types and policies in Policy-Framework by Policy-Participant,
    and deploys DCAE from DCAE-participant

3. Control Loop State change: This message is used to order a state change in control loop element.
    Runtime can order one of the following ordered states.
         UNINITIALIZED : The control loop or control loop element should become uninitialized on participants, it should not exist on participants.
         PASSIVE : The control loop or control loop element should initialized on the participants and be passive, that is,
                         it is not handling control loop messages yet.
         RUNNING : The control loop or control loop element should running and is executing control loops. Once any of above states are ordered, then control loop element transitions into
         UNINITIALIZED : The control loop or control loop element is not initialized on participants, it does not exist on participants.
         UNINITIALIZED2PASSIVE : The control loop or control loop element is changing from uninitialized to passive,
                         it is being initialized onto participants.
         PASSIVE : The control loop or control loop element is initialized on the participants but is passive, that is, it is not
                         handling control loop messages yet.
         PASSIVE2RUNNING : The control loop or control loop element is changing from passive to running,
                          the participants are preparing to execute control loops.
         RUNNING : The control loop or control loop element is running and is executing control loops.
         RUNNING2PASSIVE : The control loop or control loop element is completing execution of current control loops but
                          will not start running any more control loops and will become passive.
         PASSIVE2UNINITIALIZED : The control loop or control loop element is changing from passive to uninitialized,
                          the control loop is being removed from participants

4. Participant Healthcheck: This message is used to learn the health status of a participant.

As a response to any of the above message participant returns a Participant Status message, holding respective message response.
Runtime receives Participant Status message and stores relevant information in database, Or performs respective actions.

Participant Pass Through

For Control Loop Elements on certain participants, there may be a need to provide domain specific directives to a Control Loop Element or elements such as a microservice or a collection of microservices while a Control Loop Instance is running.