Content Comparison

...

When a control loop definition has been commissioned, instances of the control loop can be created, updated, and deleted. The system manages the lifecycle of control loops and control loop elements following the state transition diagram below.

Zu Qiang Let's update the state diagram below.

Image Removed

...

• Upgrade and changes of the configuration data of participants
• Addition of or removal of participants in an Control Loop
• Upgrade of software in one or more participants in an Control Loop
• Maintenance of compatibility between participants when an update of more than one participant must be done  together to ensure compatibility, for example, when a protocol being used by two participants to communicate is upgraded

In order to keep the upgrading process straightforward and easy to implement, the following upgrade scheme using semantic versioning is implemented. Each Control Loop Instance and Control Loop Element has a semantic version with 3 digits indicating the major.minor.patch number of the version.

Upgrade/Downgrade constraints:

1. A Control Loop or Control Loop Element in state RUNNING can be upgraded/downgraded to a different patch level. This means that hot changes that do not impact the structure of a Control Loop or its elements can be executed.
2. A Control Loop or Control Loop Element in state PASSIVE can be upgraded/downgraded to a different minor or patch level. This means that structural changes to Control Loop Elements that do not impact the Control Loop as a whole can be executed by taking the control loop to state PASSIVE.
3. A Control Loop or Control Loop Element in state UNINITIALIZED can be upgraded/downgraded to a different major/minor/patch level. This means that where the structure of the entire control loop is changed, the control loop must be uninitialized and reinitialized.
4. If a Control Loop Element has a minor version change, then its Control Loop Instance must have at least a minor version change.
5. If a Control Loop Element has a major version change, then its Control Loop Instance must have a major version change.

5.2 Scalability

The system is designed to be inherently scalable. The CLAMP runtime is stateless, all state is preserved in the run time inventory in the database. When the user requests an operation such as an instantiation, activation, passivation, or an uninitialization on a Control Loop Instance, the CLAMP runtime broadcasts the request to participants over DMaaP and saves details of the request to the database. The CLAMP runtime does not directly wait for responses to requests.

...