Versions Compared

Key

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

...

We consider Control Loops at Design Time and Run Time.

At Design Time, there are two capabilities to be are supported:

  1. Participant Metadata Definition. This capability allows external users and systems (such as SDC or DCAE-MOD) to define participants that can take part in a control loop and to define the metadata that can be used on and configured on a participant when it is taking part in in a control loop. The post condition of an execution of this capability is that a participant is defined in the Control Loop Design Time Catalogue together with sets of metadata that can be used with this participant in control loops.
  2. Control Loop Composition. This capability allows users and other systems to create Control Loop Type definitions by connecting a chain of participants together from the participants that are available in the Control Loop Design Time Catalogue. In an execution of this capability, a user defines the control loop chain for the Control Loop Type and defines the connections between participants. The user also selects the correct metadata sets for each participant in the Control Loop Type and defines the overall Control Loop Type metadata. The user also specifies the Common Parameter Types and the Instance Specific Parameter Types for instances of this Control Loop Type. The post condition for an execution of this capability is a Control Loop definition in TOSCA stored in the Control Loop Design Time Catalogue.

At Run Time, the following capabilities are to be supported:

  1. Participant Registration. This capability allows participants to register and deregister with CLAMP. The post condition for an execution of this capability is that a participant is available for participation in a control loop. Participants can explicitly register with CLAMP at any point after they start, or they can implicitly register when they repond to a control loop initiation request.
  2. Control Loop Commissioning. This capability allows version controlled Control Loop Type definitions to be taken from the Control Loop Design Time Catalogue and be placed in the Control Loop Run Time Inventory. It also allows configuratio that apply to the Control Loop Type, that is parameters that will apply to all control loop instances. Further, it allows control loop types to be commissioned on participants. Data that applies to all instances of a control loop type on a participant is sent to a participant. The participant can then take whatever actions it need to do to support the control loop type in question. The post condition for an execution of this capability is that the Control Loop definition is in the Control Loop Run Time Inventory and all participants in this control loop type are commissioned, that is they are prepared to run instances of this control loop type.
  3. Control Instantiation. This capability allows an instance of a control loop to be created. The control loop definition is read from the Control Loop Run Time Inventory and values are assigned to the parameters defined for the control loop in the same manner as the existing CLAMP client does. A control loop that has been created but has not yet been sent to participants is in state UNINITIALIZED. The control loop instance parameters can be revised and updated as often as the user requires. Once the user is happy with the parameters, the control loop instance is sent to participants and the control loop instance elements on each participant are started by participants using the control loop metadata. Once the control loop is instantiated on each participant, the Control Loop instance is set as being in state PASSIVE in the Control Loop Run Time Inventory. The user can now order the participants to change the state of the control loop to state RUNNING. Each participant begins accepting and processing control loop events and the control loop is set to state RUNNING in the control loop inventory. The post condition for an execution of this capability is that the Control Loop instance is running on participants and is processing events.
  4. Control Loop Monitoring. This capability allows control loops to be monitored. Users can check the status of a control loop instances and the status of each participant in a control loop instance. Control loop participants report their overall status and domain status periodically to CLAMP. Clamp aggregates these status reports into an aggregated control loop instance status record, which is available for monitoring. The post condition for an execution of this capability is that control loop instances are being monitored.

...