Page History

...

Participant: A system or framework that takes part in control loops by executing Control Loop Elements in cooperation with the CLAMP Control Loop Runtime. A participant chooses to partake in control loops, to manage Control Loop Elements for CLAMP, and to receive, send and act on LCM messages for the CLAMP runtime.

Common Properties: Properties that apply to all Control Loop Instances of a certain Control Loop Type and are specified when a Control Loop Type is commissioned.

Instance Specific Properties: Properties that must be specified for each Control Loop Instance and are specified when a Control Loop Instance is Initialized.

...

1. Control Loop Element Definition. This capability allows external users and systems (such as SDC or DCAE-MOD) to define the metadata that can be used on and configured on a Control Loop Element Type and to define the Participant Type that will run the Control Loop Element when it is taking part in in a control loop. The post condition of an execution of this capability is that metadata for a Control Loop Element Type is defined in the Control Loop Design Time Catalogue.
2. Control Loop Type Definition. This capability allows users and other systems to create Control Loop Type definitions by connecting specifying a chain of participants together from the participants set of Control Loop Element Definitions from those that are available in the Control Loop Design Time Catalogue. These Control Loop Elements will work together to form Control Loops. In an execution of this capability, a user defines specifies the control loop chain metadata for the Control Loop Type and defines the connections between participantsspecifies the set of Control Loop Elements and their Participant Types. 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 Property Types that apply to all instances of a control loop type and the Instance Specific Property Types that apply to individual instances of a 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 supported:

1. Participant RegistrationSystem Pre-Configuration. 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 respond to a control loop initiation requestfor participation in a control loop. Participants explicitly register with CLAMPwhen they start.
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 the values of Common Property Types that apply to all instances of a Control Loop Type to be set. The post condition for an execution of this capability is that the Control Loop definition is in the Control Loop Run Time Inventory.
3. Control Loop Priming on Participants. A participant is primed to support a Control Loop Type. The definition of a control loop and the values of Common Property Types that apply 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. Control Loop Priming can take place explicitly as a separate operation on participants or can be done implicitly in the instantiation message for the first instance of a Control Loop Typetakes place at participant registration and at Control Loop Commissioning. The post condition for an execution of this capability is that all participants in this control loop type are commissioned, that is they are prepared to run instances of this control loop typetheir Control Loop Element types.
4. Control Loop Life Cycle Management. This capability allows a Control Loop Instance to be created. The Control Loop Type definition is read from the Control Loop Run Time Inventory and values are assigned to the Instance Specific Property Types defined for instances of the Control Loop Type in the same manner as the existing CLAMP client does. A Control Loop Instance that has been created but has not yet been instantiated on participants is in state UNINITIALIZED. In this state, the Instance Specific Property Type values can be revised and updated as often as the user requires. Once the user is happy with the property values, the Control Loop Instance is instantiated on participants and the Control Loop Elements for this Control Loop Instance are started by participants using the control loop metadata. Once the Control Loop Instance 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 Instance to state RUNNING. Each participant begins accepting and processing control loop events and the Control Loop Instance 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.
5. Control Loop Monitoring. This capability allows Control Loop Instances to be monitored. Users can check the status of Participants, Control Loop Instances, and Control Loop Elements. Participants report their overall status and the status of Control Loop Elements they are running 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.

...