3 files changed, 85 insertions, 85 deletions
diff --git a/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst b/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst
index 67005fa3..4ad03984 100644
--- a/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst
+++ b/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst
@@ -7,8 +7,8 @@ CLAMP Participant Protocol Smoke Tests
 1. Introduction
 ***************
 
-The CLAMP Control Loop Participant protocol is an asynchronous protocol that is used by the CLAMP runtime
-to coordinate life cycle management of Control Loop instances.
+The CLAMP Automation Composition Participant protocol is an asynchronous protocol that is used by the CLAMP runtime
+to coordinate life cycle management of Automation Composition instances.
 This document will serve as a guide to do smoke tests on the different usecases that are involved when
 working with the Participant protocol and outline how they operate.
 It will also show a developer how to set up their environment for carrying out smoke tests on the participants.
@@ -32,10 +32,10 @@ Linux user - although the majority of the steps show will be exactly the same in
 2.2 Setting up the components
 =============================
 
-- Controlloop runtime component docker image is started and running.
+- Automation Composition runtime component docker image is started and running.
 - Participant docker images policy-clamp-cl-pf-ppnt, policy-clamp-cl-http-ppnt, policy-clamp-cl-k8s-ppnt are started and running.
 - Dmaap simulator for communication between components.
-- mariadb docker container for policy and controlloop database.
+- mariadb docker container for policy and clampacm database.
 - policy-api for communication between policy participant and policy-framework
 
 In this setup guide, we will be setting up all the components technically required for a working convenient
@@ -47,7 +47,7 @@ example.
 
 We will be using Docker to run our mariadb instance. It will have a total of two databases running in it.
 
-- controlloop: the runtime-controlloop db
+- clampacm: the runtime-clampacm db
 - policyadmin: the policy-api db
 
 3. Running Tests of protocol dialogues
@@ -81,107 +81,107 @@ Test result:
 3.3 Participant Priming
 =======================
 
-When a control loop is primed, the portion of the Control Loop Type Definition and Common Property values for the participants
-of each participant type mentioned in the Control Loop Definition are sent to the participants.
-Action: Invoke a REST API to prime controlloop type definitions and set values of common properties
+When a automation composition is primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
+of each participant type mentioned in the Automation Composition Definition are sent to the participants.
+Action: Invoke a REST API to prime acm type definitions and set values of common properties
 
 Test result:
 
-- Observe PARTICIPANT_UPDATE going from runtime to participant with controlloop type definitions and common property values for participant types
-- Observe that the controlloop type definitions and common property values for participant types are stored on ParticipantHandler
+- Observe PARTICIPANT_UPDATE going from runtime to participant with acm type definitions and common property values for participant types
+- Observe that the acm type definitions and common property values for participant types are stored on ParticipantHandler
 - Observe PARTICIPANT_UPDATE_ACK going from runtime to participant
 
 3.4 Participant DePriming
 =========================
 
-When a control loop is de-primed, the portion of the Control Loop Type Definition and Common Property values for the participants
-of each participant type mentioned in the Control Loop Definition are deleted on participants.
-Action: Invoke a REST API to deprime controlloop type definitions
+When a automation composition is de-primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
+of each participant type mentioned in the Automation Composition Definition are deleted on participants.
+Action: Invoke a REST API to deprime acm type definitions
 
 Test result:
 
-- If controlloop instances exist in runtime database, return a response for the REST API with error response saying "Cannot decommission controlloop type definition"
-- If no controlloop instances exist in runtime database, Observe PARTICIPANT_UPDATE going from runtime to participant with definitions as null
-- Observe that the controlloop type definitions and common property values for participant types are removed on ParticipantHandler
+- If acm instances exist in runtime database, return a response for the REST API with error response saying "Cannot decommission acm type definition"
+- If no acm instances exist in runtime database, Observe PARTICIPANT_UPDATE going from runtime to participant with definitions as null
+- Observe that the acm type definitions and common property values for participant types are removed on ParticipantHandler
 - Observe PARTICIPANT_UPDATE_ACK going from runtime to participant
 
-3.5 Control Loop Update
-=======================
+3.5 Automation Composition Update
+=================================
 
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Trigger controlloop instantiation from GUI
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Trigger acm instantiation from GUI
 
 Test result:
 
-- Observe CONTROL_LOOP_UPDATE going from runtime to participant
-- Observe that the controlloop type instances and respective property values for participant types are stored on ControlLoopHandler
-- Observe that the controlloop state is UNINITIALISED
-- Observe CONTROL_LOOP_UPDATE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_UPDATE going from runtime to participant
+- Observe that the acm type instances and respective property values for participant types are stored on AutomationCompositionHandler
+- Observe that the acm state is UNINITIALISED
+- Observe AUTOMATION_COMPOSITION_UPDATE_ACK going from participant to runtime
 
-3.6 Control Loop state change to PASSIVE
-========================================
+3.6 Automation Composition state change to PASSIVE
+==================================================
 
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Change state of the controlloop to PASSIVE
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Change state of the acm to PASSIVE
 
 Test result:
 
-- Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
-- Observe that the ControlLoopElements state is PASSIVE
-- Observe that the controlloop state is PASSIVE
-- Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
+- Observe that the AutomationCompositionElements state is PASSIVE
+- Observe that the acm state is PASSIVE
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 
-3.7 Control Loop state change to RUNNING
-========================================
+3.7 Automation Composition state change to RUNNING
+==================================================
 
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Change state of the controlloop to RUNNING
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Change state of the acm to RUNNING
 
 Test result:
 
-- Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
-- Observe that the ControlLoopElements state is RUNNING
-- Observe that the controlloop state is RUNNING
-- Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
+- Observe that the AutomationCompositionElements state is RUNNING
+- Observe that the acm state is RUNNING
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 
-3.8 Control Loop state change to PASSIVE
-========================================
+3.8 Automation Composition state change to PASSIVE
+==================================================
 
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Change state of the controlloop to PASSIVE
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Change state of the acm to PASSIVE
 
 Test result:
 
-- Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
-- Observe that the ControlLoopElements state is PASSIVE
-- Observe that the controlloop state is PASSIVE
-- Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
+- Observe that the AutomationCompositionElements state is PASSIVE
+- Observe that the acm state is PASSIVE
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 
-3.9 Control Loop state change to UNINITIALISED
-==============================================
+3.9 Automation Composition state change to UNINITIALISED
+========================================================
 
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Change state of the controlloop to UNINITIALISED
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Change state of the acm to UNINITIALISED
 
 Test result:
 
-- Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
-- Observe that the ControlLoopElements state is UNINITIALISED
-- Observe that the controlloop state is UNINITIALISED
-- Observe that the ControlLoopElements undeploy the instances from respective frameworks
-- Observe that the control loop instances are removed from participants
-- Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
+- Observe that the AutomationCompositionElements state is UNINITIALISED
+- Observe that the acm state is UNINITIALISED
+- Observe that the AutomationCompositionElements undeploy the instances from respective frameworks
+- Observe that the automation composition instances are removed from participants
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
 
-3.10 Control Loop monitoring and reporting
-==========================================
+3.10 Automation Composition monitoring and reporting
+====================================================
 
-This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Control Loop Elements, and to gather statistics on control loops. The ParticipantStatus message is sent periodically by each participant. The reporting interval for sending the message is configurable
+This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Automation Composition Elements, and to gather statistics on automation compositions. The ParticipantStatus message is sent periodically by each participant. The reporting interval for sending the message is configurable
 Action: Bring up participant
 
 Test result:
 
 - Observe that PARTICIPANT_STATUS message is sent from participants to runtime in a regular interval
-- Trigger a PARTICIPANT_STATUS_REQ from runtime and observe a PARTICIPANT_STATUS message with tosca definitions of control loop type definitions sent
+- Trigger a PARTICIPANT_STATUS_REQ from runtime and observe a PARTICIPANT_STATUS message with tosca definitions of automation composition type definitions sent
   from all the participants to runtime
 
 This concluded the required smoke tests
diff --git a/docs/development/devtools/devtools.rst b/docs/development/devtools/devtools.rst
index e2ccb887..e7ad1a76 100644
--- a/docs/development/devtools/devtools.rst
+++ b/docs/development/devtools/devtools.rst
@@ -273,7 +273,7 @@ familiar with the Policy Framework components and test any local changes.
 .. toctree::
    :maxdepth: 1
 
-   policy-gui-controlloop-smoke.rst
+   policy-gui-acm-smoke.rst
    db-migrator-smoke.rst
    cl-participants-smoke.rst
    clamp-smoke.rst
diff --git a/docs/development/devtools/policy-gui-controlloop-smoke.rst b/docs/development/devtools/policy-gui-acm-smoke.rst
index aa319651..8070204c 100644
--- a/docs/development/devtools/policy-gui-controlloop-smoke.rst
+++ b/docs/development/devtools/policy-gui-acm-smoke.rst
@@ -1,20 +1,20 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 
-.. _clamp-gui-controlloop-smoke-tests:
+.. _clamp-gui-acm-smoke-tests:
 
 CLAMP GUI Smoke Tests
 ---------------------------
 1. Introduction
 ***************
-The CLAMP GUI for Control Loops is designed to provide a user the ability to interact
-with the Control Loop Runtime to perform several actions.
+The CLAMP GUI for Automation Compositions is designed to provide a user the ability to interact
+with the Automation Composition Runtime to perform several actions.
 
 - Commission new Tosca Service Templates.
 - Editing Common Properties.
 - Decommission existing Tosca Service Templates.
-- Create new instances of Control Loops.
-- Change the state of the Control Loops.
-- Delete Control Loops.
+- Create new instances of Automation Compositions.
+- Change the state of the Automation Compositions.
+- Delete Automation Compositions.
 
 This document will serve as a guide to do smoke tests on the different components that are involved when working with the GUI and outline how they operate. It will also show a developer how to set up their environment for carrying out smoke tests on the GUI.
 
@@ -56,7 +56,7 @@ In this setup guide, we will be setting up all the components technically requir
 ^^^^^^^^^^^^^^^^^^^
 We will be using Docker to run our mariadb instance. It will have a total of three databases running in it.
 
-- controlloop: the runtime-controlloop db
+- acm: the clampacm db
 - cldsdb4: the clamp backend db
 - policyadmin: the policy-api db
 
@@ -69,16 +69,16 @@ The easiest way to do this is to perform a small alteration on an SQL script pro
     DROP USER 'clds';
     CREATE USER 'clds';
     GRANT ALL on cldsdb4.* to 'clds' identified by 'sidnnd83K' with GRANT OPTION;
-    CREATE DATABASE `controlloop`;
-    USE `controlloop`;
+    CREATE DATABASE `clampacm`;
+    USE `clampacm`;
     DROP USER 'policy';
     CREATE USER 'policy';
-    GRANT ALL on controlloop.* to 'policy' identified by 'P01icY' with GRANT OPTION;
+    GRANT ALL on clampacm.* to 'policy' identified by 'P01icY' with GRANT OPTION;
     CREATE DATABASE `policyadmin`;
     USE `policyadmin`;
     DROP USER 'policy_user';
     CREATE USER 'policy_user';
-    GRANT ALL on controlloop.* to 'policy_user' identified by 'policy_user' with GRANT OPTION;
+    GRANT ALL on clampacm.* to 'policy_user' identified by 'policy_user' with GRANT OPTION;
     FLUSH PRIVILEGES;
 
 Once this has been done, we can run the bash script provided here: "runtime/extra/bin-for-dev/start-db.sh"
@@ -157,7 +157,7 @@ Next, navigate to the "/main" directory. You can then run the following command
 
 2.3.6 Clamp Backend
 ^^^^^^^^^^^^^^^^^^^
-The Clamp Backend can potentially make calls to policy pap, policy api, cds, sdc and others. For controlloop development purposes, we only need to connect with the controlloop runtime api. For convenience, there has been an emulator provided to respond to requests from Clamp to all those services that we do not care about. This emulator can be run by running the following bash script "runtime/extra/bin-for-dev/start-emulator.sh"
+The Clamp Backend can potentially make calls to policy pap, policy api, cds, sdc and others. For acm development purposes, we only need to connect with the acm runtime api. For convenience, there has been an emulator provided to respond to requests from Clamp to all those services that we do not care about. This emulator can be run by running the following bash script "runtime/extra/bin-for-dev/start-emulator.sh"
 
 .. code-block:: bash
 
@@ -169,19 +169,19 @@ Once the emulator is running, we can then run the clamp backend. Before doing th
 
     ./start-backend.sh
 
-Once the clamp backend is running, we can start the controlloop runtime.
+Once the clamp backend is running, we can start the acm runtime.
 
-2.3.7 Controlloop Runtime
-^^^^^^^^^^^^^^^^^^^^^^^^^
-To start the controlloop runtime we need to go the "runtime-controlloop" directory in the clamp repo. There is a config file that is used, by default, for the controlloop runtime. That config file is here: "src/main/resources/application.yaml". For development in your local environment, it shouldn't need any adjustment and we can just run the controlloop runtime with:
+2.3.7 Automation Composition Runtime
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+To start the acm runtime we need to go the "runtime-acm" directory in the clamp repo. There is a config file that is used, by default, for the acm runtime. That config file is here: "src/main/resources/application.yaml". For development in your local environment, it shouldn't need any adjustment and we can just run the acm runtime with:
 
 .. code-block:: bash
 
     mvn spring-boot:run
 
-2.3.8 Controlloop GUI
-^^^^^^^^^^^^^^^^^^^^^
-At this point, all of the components required to test out the controlloop gui are running.We can start to make changes, and have those changes reflected in the UI for immediate feedback on our changes. But first, we must run the GUI.
+2.3.8 Automation Composition GUI
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+At this point, all of the components required to test out the acm gui are running.We can start to make changes, and have those changes reflected in the UI for immediate feedback on our changes. But first, we must run the GUI.
 
 Firstly, go to the GUI repo and navigate to "gui-clamp/ui-react". To setup for development, we must install the dependencies of the GUI. We can do this using the npm package manager. In the directory, simply run:
 
@@ -224,7 +224,7 @@ This confirms that commissioning has been complete.
 
 3.2 Edit Common Properties
 ==========================
-At this stage we can edit the common properties. These properties will be common to all instances of the control loop definitions we uploaded with the tosca service template. Once an instance is created, we will not be able to alter these common properties again. We can simply click on "Edit Common Properties" in the dropdown menu and we will be taken to the modal shown below.
+At this stage we can edit the common properties. These properties will be common to all instances of the automation composition definitions we uploaded with the tosca service template. Once an instance is created, we will not be able to alter these common properties again. We can simply click on "Edit Common Properties" in the dropdown menu and we will be taken to the modal shown below.
 
 .. image:: images/gui/CommonPropertiesModal.png
 
@@ -232,8 +232,8 @@ The arrows to the left of the modal can be used to expand and contract the eleme
 
 .. image:: images/gui/ViewEditedCommonProperties.png
 
-3.3 Create New Instances of Control Loops
-=========================================
+3.3 Create New Instances of Automation Compositions
+===================================================
 Once the template is commissioned, we can start to create instances. In the dropdown, click on "Instantiation Management". In the modal, you will see an empty table, as shown.
 
 .. image:: images/gui/ManageInstancesModal.png