Automation Composition Management manages a number of states of various types to manage the lifecycle of compositions. Those states are described here. Please also see the ACM System Level Dialogues page to see the system dialogues that change states and how states interrelate in detail. Please also see ITU Recommendation X.731, which is reflected in the states of AC Element Instances.

Participant State

ACParticipant states are NOT managed by ACM but the state of a participant is recorded and supervised by ACM.

@startuml

[*] --> ONLINE: Register
ONLINE --> ONLINE: Heartbeat
ONLINE --> OFFLINE: Timeout
OFFLINE --> ONLINE: Heartbeat
ONLINE --> [*]: Deregister
OFFLINE --> [*]: Deregister

@enduml

Automation Composition Type State

The states that an Automation Composition Type can have are shown in the diagram below.

@startuml

[*] --> COMMISSIONED: Commission
COMMISSIONED --> [*]: Decommission
COMMISSIONED --> PRIMING: Prime
PRIMED --> PRIMING: Prime
PRIMING --> PRIMED: AC Element Types\nall PRIMED
PRIMING --> DEPRIMING: Deprime
PRIMED --> DEPRIMING: Deprime
DEPRIMING --> COMMISSIONED: AC Element Types\nall DEPRIMED

@enduml

Automation Composition Element Type State

The states that an Automation Composition Element Type can have on ACM Runtime are shown in the diagram below.

@startuml

[*] --> COMMISSIONED: Commission
COMMISSIONED --> [*]: Decommission
COMMISSIONED --> PRIMING: Prime
PRIMED --> PRIMING: Prime
PRIMING --> PRIMED: AC Element Type Primed\nresponse from Participant
PRIMING --> DEPRIMING: Deprime
PRIMED --> DEPRIMING: Deprime
DEPRIMING --> COMMISSIONED: AC Element Type Deprimed\nresponse from Participant

@enduml

The states that an Automation Composition Element Type can have on a Participant are shown in the diagram below.

The current ACM state machine works but it is incosistent in the way it handles error states or failed transitions. A composition and its elements can get "stuck" in transition states.

We need to

• Specify what the current state machine is for both compositions and elements and describe what the state machine for both should be
• Specify what the behaviour of the runtime and participants should be in each state
• Specify what the behaviour should be for the runtime and participants should be in transitions

Specifically we need to clarify:

• State of the composition elements
• State of the overall composition is derived from the composition element states
• Admin state/Running state
• When all the elements are fully up and configured, the go to state Passive, when all elements are in Passive, the full composition goes to Passive
• Error states: Are they parallel sates or part of the same state?
• There should “it didn’t work” states like “Passive-Error” or “Run_Error” (names to be decided later)
• Describe what the “Running” state means and what the participant should do in Passive->Running and Running->Passive transitions.
• Say a K8S service crashes, how do we feed that back? Running_Error. The state of the POD is only checked during startup. It is not periodically checked. There should be supervision.

Discuss priming and what the relationship is with this.

What does PASSIVE and RUNNING mean?

UNINITIALIZED: The participant knows about the AC Element and it's values and definition are in the participant but it hasn't started it yet. For example, in the K8S participant, the K8S participant knows the helm charts to use, the aprameter vales for config, but it hasn't called HELM yet to start the microservice

PASSIVE: The participant has started the AC Element. EG in the K8s PPNT, thelm has started the microservice, the micorservice is up and running but it is not doing anything yet.

ACTIVE: The participant has decided that the AC Element is working doing "Application" work. The state ACTIVE is controlled by the participant.

Indicate in each state, what is the expectation of the participants in each state.

ACM Element States in Participants

This section describes the state handling in ACM Elements in Participants

The following states are the only states in participants:

@startuml

[*] --> UNINITIALIZEDPRIMED: CreatedPrime byfrom\nACM Runtime
UNINITIALIZEDPRIMED --> PASSIVEPRIMED: Prime from InitializeACM (Success)Runtime
UNINITIALIZEDPRIMED --> UNINITIALIZED_ERROR: Initialize (Error)

PASSIVE[*]: Deprime from\nACM Runtime

@enduml

Automation Composition Instance State

The states that an Automation Composition Instance can have are shown in the diagram below.

@startuml

[*] --> UNDEPLOYED: Create
UNDEPLOYED --> UNINITIALIZED: Uninitialize (Success)
PASSIVE[*]: Delete
UNDEPLOYED --> DEPLOYING: Deploy
DEPLOYING --> PASSIVE_ERROR: Uninitialize (Error)

PASSIVE_ERRORDEPLOYED: AC Element Instances\nall DEPLOYED
DEPLOYING --> UNDEPLOYING: Undeploy
DEPLOYED --> UNINITIALIZEDUNDEPLOYING: Uninitialize (Success)
PASSIVE_ERRORUndeploy
UNDEPLOYING --> PASSIVE_ERROR: Uninitialize (Error)
  
UNINITIALIZED_ERRORUNDEPLOYED: AC Element Instances\nall UNDEPLOYED


state DEPLOYED {
 [*] --> UNINITIALIZED: UnitializeReset (Success)
UNINITIALIZED_ERRORLOCKED: Deploy
 LOCKED --> [*]: Undeploy
 LOCKED --> UNINITIALIZED_ERRORUNLOCKING: UnitializeReset (Error)

PASSIVEUnlock
 UNLOCKING --> RUNNINGUNLOCKED: Activate (Success)
PASSIVEAC Element Instances\nall UNLOCKED
 UNLOCKED --> PASSIVE_ERRORLOCKING: Activate (Failure)Lock
 
PASSIVE_ERRORUNLOCKING --> PASSIVELOCKING: PassiveReset (Success)
PASSIVE_ERRORLock
 LOCKING --> PASSIVE_ERROR: PassiveReset (Failure)

PASSIVE_ERRORLOCKED: AC Element Instances\nall LOCKED
}

@enduml

Automation Composition Element Instance State

The states that an Automation Composition Element Instance can have on ACM Runtime are shown in the diagram below.

@startuml

[*] --> UNINITIALIZED_ERRORUNDEPLOYED: ForceUninitialize

RUNNINGCreate
UNDEPLOYED --> [*]: Delete
UNDEPLOYED --> PASSIVEDEPLOYING: Passivate (Success)
RUNNINGDeploy
DEPLOYING --> RUNNING_ERRORDEPLOYED: Passivate (Error)
RUNNING_ERRORAC Element\nInstance DEPLOYED
DEPLOYING --> PASSIVEUNDEPLOYING: Passivate (Success)
RUNNING_ERROR Undeploy
DEPLOYED --> UNDEPLOYING: Undeploy
UNDEPLOYING --> RUNNING_ERRORUNDEPLOYED: Passivate (Error)

RUNNINGAC Element\nInstance UNDEPLOYED


state DEPLOYED {
 [*] --> RUNNING_ERRORLOCKED: RuntimeError

RUNNING_ERRORDeploy
 LOCKED --> [*]: Undeploy
 LOCKED --> RUNNINGUNLOCKING: ClearRuntimeError

RUNNING_ERRORUnlock
 UNLOCKING --> UNLOCKED: AC Element\nInstance UNLOCKED
 UNLOCKED --> RUNNINGLOCKING: RuntimeReset

RUNNING_ERRORLock
 UNLOCKING --> LOCKING: Lock
 LOCKING --> PASSIVE_ERRORLOCKED: ForcePassiveAC Element\nInstance LOCKED
}

@enduml

Then, a Control Loop Element can be running a number of operations, each of which has an operational state:

...

To
State

...

Triggered
By

...

UNINITIALIZED

UNINITIALIZED

...

PASSIVE

UNINITIALIZED_ERROR

...

Success

Fail

...

PASSIVE

PASSIVE

PASSIVE_ERROR

PASSIVE_ERROR

...

UNINITIALIZED

PASSIVE_ERROR

UNINITIALIZED

PASSIVE_ERROR

...

Success

Fail

Success

Fail

...

ACM Runtime

...

UNINITIALIZED_ERROR

UNINITIALIZED_ERROR

...

UNINITIALIZED

UNINITIALIZED_ERROR

...

Success

Fail

...

ACM Runtime

...

PASSIVE

PASSIVE

...

RUNNING

PASSIVE_ERROR

...

Success

Fail

...

PASSIVE_ERROR

PASSIVE_ERROR

...

PASSIVE

PASSIVE_ERROR

...

Success

Fail

...

ACM Runtime
Participant

...

RUNNING

RUNNING

RUNNING_ERROR

RUNNING_ERROR

...

PASSIVE

RUNNING_ERROR

PASSIVE

RUNNING_ERROR

...

Success

Fail

...

ACM Runtime

Participant

...

A Control Loop Element has a status indicator

...

The states that an Automation Composition Element Instance can have on a Participant are shown in the diagram below.

@startuml

[*] --> DEPLOYING: Deploy
DEPLOYING --> DEPLOYED: AC Element\nInstance DEPLOYED\nRespond with\nAC Element State Update
DEPLOYING --> UNDEPLOYING: Undeploy
DEPLOYING --> [*]: Deploy Failed\nRespond with\nAC Element State Update
DEPLOYED --> UNDEPLOYING: Undeploy
UNDEPLOYING --> [*]: Undeployed\nRespond with\nAC Element State Update

state DEPLOYED {
 [*] --> LOCKED
 LOCKED --> [*]
 LOCKED --> UNLOCKING: Unlock
 UNLOCKING --> UNLOCKED: AC Element\nInstance UNLOCKED
 UNLOCKED --> LOCKING: Lock
 UNLOCKING --> LOCKING: Lock
 LOCKING --> LOCKED: AC Element\nInstance LOCKED
}

@enduml

Each participant also records a log of all operations that occur, recording the information below:

...

To
State

...