Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Terminology

  • Broadcast message: a message for all participants (participantId=null and participantType=null)

...

  • Message to a participant: a message only for a participant (participantId and participantType properly filled).
  • ThreadPoolExecutor: ThreadPoolExecutor executes the given task, into SupervisionAspect class is configured to execute tasks in ordered manner, one by one.
  • Spring Scheduling: into SupervisionAspect class, the @Scheduled annotation invokes "schedule()" method every "runtime.

...

  • participantParameters.heartBeatMs" milliseconds with a fixed delay
  • MessageIntercept: "@MessageIntercept" annotation is used to intercept method calls using spring aspect oriented programming. In details is used to into SupervisionHandler class to intercept "handleParticipantMessage" methods.

Design of a creation of a Control Loop Type

  • GUI calls POST "/commission" endpoint with a Control Loop Type Definition (Tosca Service Template) as body
  • saves to DB the Tosca Service Template using PolicyModelsProvider
  • if there are participants registered, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message
  • the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition).

Design of a deletion of a Control Loop Type

  • GUI calls DELETE "/commission" endpoint
  • if there are participants registered, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message
  • the message is built by ParticipantUpdatePublisher with a empty list of ParticipantDefinition
  • deletes the Control Loop Type from DB

Design of a creation of a Control Loop

  • GUI calls POST "/instantiation" endpoint with a Control Loop as body
  • validates the Control Loop
  • saves the Control Loop to DB

Design of an update of a Control Loop

  • GUI calls PUT "/instantiation" endpoint with a Control Loop as body
  • validates the Control Loop
  • saves the Control Loop to DB

Design of a deletion of a Control Loop

  • GUI calls DELETE "/instantiation" endpoint
  • checks that Control Loop is in UNINITIALISED status
  • deletes the Control Loop from DB

Design of a issues control loop commands to control loops - case UNINITIALISED to PASSIVE

  • GUI calls "/instantiation/command" endpoint with PASSIVE as orderedState
  • checks if participants registered are matching with the list of control Loop Element
  • updates control loop and control loop elements to DB (orderedState = PASSIVE)
  • validates the status order issued
  • triggers the execution to send a broadcast CONTROL_LOOP_UPDATE message
  • the message is built by ControlLoopUpdatePublisher using Tosca Service Template data and ControlLoop data. (with startPhase = 0)
  • updates control loop and control loop elements to DB (state = UNINITIALISED2PASSIVE)

Design of a issues control loop commands to control loops - case PASSIVE to UNINITIALISED

  • GUI calls "/instantiation/command" endpoint with UNINITIALISED as orderedState
  • checks if participants registered are matching with the list of control Loop Element
  • updates control loop and control loop elements to DB (orderedState = UNINITIALISED)
  • validates the status order issued
  • triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message
  • the message is built by ControlLoopStateChangePublisher with controlLoopId
  • updates control loop and control loop elements to DB (state = PASSIVE2UNINITIALISED)

Design of a issues control loop commands to control loops - case PASSIVE to RUNNING

  • GUI calls "/instantiation/command" endpoint with RUNNING as orderedState
  • checks if participants registered are matching with the list of control Loop Element.
  • updates control loop and control loop elements to DB (orderedState = RUNNING)
  • validates the status order issued
  • triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message
  • the message is built by ControlLoopStateChangePublisher with controlLoopId
  • updates control loop and control loop elements to DB (state = PASSIVE2RUNNING)

Design of a issues control loop commands to control loops - case RUNNING to PASSIVE

  • GUI calls "/instantiation/command" endpoint with UNINITIALISED as orderedState
  • checks if participants registered are matching with the list of control Loop Element.
  • updates control loop and control loop elements to db (orderedState = RUNNING)
  • validates the status order issued
  • triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message
  • the message is built by ControlLoopStateChangePublisher with controlLoopId
  • updates control loop and control loop elements to db (state = RUNNING2PASSIVE)

StartPhase

The startPhase is particularly important in control loop update and control loop state changes because sometime the user wishes to control the order in which the state changes in Control Loop Elements in a control loop.

...

Example with Http_PMSHMicroserviceControlLoopElement with startPhase to 1 and PMSH_K8SMicroserviceControlLoopElement with startPhase to 0

  • CL-runtime sends a broadcast CONTROL_LOOP_UPDATEmessage to all participants with startPhase = 0
  • participant receives the CONTROL_LOOP_UPDATEmessage and runs to PASSIVE state (only CL elements defined as startPhase = 0)
  • CL-runtime receives CONTROL_LOOP_UPDATE_ACT messages from participants and set the state (from the CL element of the message) to PASSIVE
  • CL-runtime calculates that all CL elements with startPhase = 0 are set to proper state and sends a broadcast CONTROL_LOOP_UPDATE message to all participants message with startPhase = 1
  • participant receives the CONTROL_LOOP_UPDATEmessage and runs to PASSIVE state (only CL elements defined as startPhase = 1)
  • CL-runtime calculates that all CL elements are set to proper state and set CL to PASSIVE

In that scenario the message CONTROL_LOOP_UPDATE has been sent two times.

SupervisionAspect

...

.

...

Design of a PARTICIPANT_REGISTER message

  • A Participant starts and send a PARTICIPANT_REGISTER message
  • ParticipantRegisterListener collects the message from DMaap
  • if not present, saves participant reference with status UNKNOWN to DB
  • if is present a Control Loop Type, triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming).
  • the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition).
  • triggers the execution to send a PARTICIPANT_REGISTER_ACK message to the participant registered
  • MessageIntercept intercepts that event, if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner
  • SupervisionScanner starts the monitoring for participantUpdate

Design of a PARTICIPANT_UPDATE_ACK message

  • Participants sends PARTICIPANT_UPDATE_ACK messages in response to a PARTICIPANT_UPDATE message
  • ParticipantUpdateAckListener collects the message from DMaap
  • MessageIntercept intercepts that event and adds a task to handle PARTICIPANT_UPDATE_ACK in SupervisionScanner
  • SupervisionScanner removes the monitoring for participantUpdate
  • updates the status of the participant to DB

Design of a PARTICIPANT_STATUS message

  • A participant sends a scheduled PARTICIPANT_STATUS message
  • ParticipantStatusListener collects the message from DMaap
  • MessageIntercept intercepts that event and adds a task to handle PARTICIPANT_STATUS in SupervisionScanner
  • SupervisionScanner clears and starts the monitoring for participantStatus

Design of a CONTROLLOOP_UPDATE_ACK message

Participants sends CONTROLLOOP_UPDATE_ACK messages in response to a CONTROLLOOP_UPDATE  message. It will send a CONTROLLOOP_UPDATE_ACK for each CL-elements moved to the state as indicated by the CONTROLLOOP_UPDATE.

...

Design of a CONTROLLOOP_STATECHANGE_ACK is similar to the design for CONTROLLOOP_UPDATE_ACK

Design of monitoring execution in SupervisionScanner

Monitoring is designed to process the follow operations:

...

  • Spring Scheduling inserts the task to monitor retry execution any heartBeatMs milliseconds into ThreadPoolExecutor
  • ThreadPoolExecutor executes the task
  • a message will be retry if CL-runtime do no receive Act message before MaxWaitMs milliseconds

...