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.
Table of Contents |
---|
Participant Registration and De-Registration
Registration when a participant comes up and update of participant with control loop type information for its control loop types.
PlantUML Macro |
---|
@startuml Participant -> CLAMP_Runtime: Participant Registration Participant <- CLAMP_Runtime: Participant Registration Ack Participant <- CLAMP_Runtime: Participant Update [Control Loop Types and Common Property Values for Participant Type of Participant] Participant -> CLAMP_Runtime: Participant Update Ack |
De-registration as a participant goes down.
PlantUML Macro |
---|
@startuml Participant -> CLAMP_Runtime: Participant Deregistration Participant <- CLAMP_Runtime: Participant Deregistration Ack |
Update of participant with new control loop type definitions for its types as they are commissioned
Deregistration when participants go offline.
Control Loop Update
Update of control loops on participants (create/upgrade/downgrade/delete) following semantic versioning approach following these semantics: TOSCA Defined Control Loop: Architecture and Design
Control Loop State Change
UNINITIALIZED<->PASSIVE<->ACTIVE
Control Loop Monitoring and Reporting
Monitoring and statistics reported regularly by participants for their control loops.
Warning |
---|
This page is updated for Istanbul to this point. |
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
Warning |
---|
The information in this section is speculative |
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.
draw.io Diagram | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|