Priming The CLAMP Automation Composition Runtime Lifecycle Management uses the following system-level dialogues. These dialogues enable the CLAMP runtime capabilities described in Section 2 of TOSCA Defined Automation Compositions: Architecture and Design. Design Time dialogues will be described in future releases of the system.

1 Dialogues on Participants

1.1 Participant Registration

Participant Registration is performed by a Participant when it starts up. It registers its ID and the ACM Element Types it supports with the ACM runtime.

1.2 Participant Deregistration

Participant Deregistration is performed by a Participant when it shuts down. It deregisters its ID and type with the ACM runtime.

The participant should already have cleared down all its ACM Element instances and set their states to UNINITIALIZED.

1.3 Participant Supervision

Participant Supervision is performed periodically between participants and the ACM runtime server to ensure that registered participants are available over time. Participants send a heartbeat message to the ACM runtime at a configured interval.

The ACM runtime regularly checks the heartbeat reports from participants and takes action of participants time out. If a heartbeat message is not received for a participant in the Timeout Interval, the participant is marked as timed out and its ACM element instances are informed.

1.4 Participant Information

The information on participants is available over a REST endpoint.

2 Dialogues on Automation Composition Types

Commissioning dialogues are used to commission and decommission Automation Composition Types and to set the values of Common Parameters. The values of common parameters are included in the TOSCA YAML file that defines the full Automation Composition Type.

2.1 Commissioning an Automation Composition Type

Create on a POST and update on a PUT.

2.2 Commissioning an Automation Composition Type using SDC

2.3 Decommissioning an Automation Composition Type Definition

2.4 Prime an Automation Composition Type Definition on Participants

The Priming operation sends Automation Composition Types and common property values to participants for each Automation Composition Element Type in the Automation Composition Type. A participant should respond for each Automation Composition Element Type, thus causing the full Automation Composition Type to become primed. Note that if more than one participant can support an Automation Composition Element Type the ACM Runtime uses the participant in the first response it receives for that Automation Composition Element Type.

2.5 Get Automation Composition Types

This dialogue allows an Automation Composition Type  to be read.

3. Instantiation Dialogues

Instantiation dialogues are used to create, set parameters on, instantiate, update, and remove Automation Composition instances.

3.1 Creating an Automation Composition Instance

Note that this dialogue creates the Automation Composition Instance in the Instantiated Automation Composition Inventory. The instance is sent to the participants using the process described in the dialogue in Section 2.3.

3.2 Updating Instance Specific Parameters on an Automation Composition Instance

3.3 Updating an Automation Composition Instance with a Configuration on Participants

3.4 Changing the state of an Automation Composition Instance on Participants

3.5 De-instantiating an Automation Composition Instance from Participants

3.6 Deleting an Automation Composition Instance

3.7 Reading Automation Composition Instances

3. Monitoring Dialogues

Monitoring dialogues are used to monitor and read statistics on Automation Composition Instances.

3.1 Reporting of Monitoring Information and Statistics by Participants

3.2 Viewing of Monitoring Information

3.2 Viewing of Statistics

3.3 Statistics Housekeeping

4. Supervision Dialogues

Supervision dialogues are used to check the state of Automation Composition Instances and Participants.

4.1 Supervise Participants

4.2 Supervise Automation Compositions