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 into SupervisionHandler class to intercept "handleParticipantMessage" method calls using spring aspect oriented programming
  • GUI: graphical user interface, could be Postman or an Front-End Application

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
  • CL-runtime receives the call by Rest-Api (CommissioningController)
  • It 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)

...

  • GUI calls DELETE "/commission" endpoint
  • CL-runtime receives the call by Rest-Api (CommissioningController)
  • if there are participants registered, it CL-runtime triggers the execution to send a broadcast PARTICIPANT_UPDATE message
  • the message is built by ParticipantUpdatePublisher with a an empty list of ParticipantDefinition
  • deletes the Control Loop Type from DB

...

  • GUI calls POST "/instantiation" endpoint with a Control Loop as body
  • CL-runtime receives the call by Rest-Api (InstantiationController)
  • It validates the Control Loop
  • It saves the Control Loop to DB

...

  • GUI calls PUT "/instantiation" endpoint with a Control Loop as body
  • CL-runtime receives the call by Rest-Api (InstantiationController)
  • It validates the Control Loop
  • It saves the Control Loop to DB

...

  • GUI calls DELETE "/instantiation" endpoint
  • CL-runtime receives the call by Rest-Api (InstantiationController)
  • It checks that Control Loop is in UNINITIALISED status
  • It deletes the Control Loop from DB

...

  • GUI calls "/instantiation/command" endpoint with PASSIVE as orderedState
  • CL-runtime checks if participants registered are matching with the list of control Loop Element
  • It updates control loop and control loop elements to DB (orderedState = PASSIVE)
  • It validates the status order issued
  • It 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)
  • It updates control loop and control loop elements to DB (state = UNINITIALISED2PASSIVE)

...

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

...

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

...

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

...

  • 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)
  • It 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

...

  • 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
  • It updates the status of the participant to DB

...

  • 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 ordered state as indicated by the CONTROLLOOP_UPDATE
  • ControlLoopUpdateAckListener collects the message from DMaap
  • It checks the status of all control loop elements and checks if the control loop is primed
  • It updates the CL to DB if it is changed
  • MessageIntercept intercepts that event and adds a task to handle a monitoring execution in SupervisionScanner

...