...
4.1 Control Loop Version Management
Performing a hot upgrade change of a Control Loop Instance at run time as well as handling an upgrade of the software in one or more of the participants in an Control Loop is a particularly challenging issue because upgrading a change must handle the following cases without tearing down the Control Loop:
- Upgrade and changes Changes of the configuration data of participantsAddition of or removal of participants in an Control Loop
- Upgrade of software in one or more participants in an Control Loop
- Instances
- Coping with changes in Control Loop DefinitionsMaintenance 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 version management straightforward and easy to implement, the following upgrade version management 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.
| draw.io Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Upgrade/Downgrade Change constraints:
- A Control Loop or Control Loop Element in state RUNNING can be upgraded/downgraded changed to a higher patch level or rolled back to a different lower patch level. This means that hot changes that do not impact the structure of a Control Loop or its elements can be executed.
- A Control Loop or Control Loop Element in state PASSIVE can be upgraded/downgraded changed to a higher minor/patch level or rolled back to a different lower 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.
- A Control Loop or Control Loop Element in state UNINITIALIZED can be upgraded/downgraded changed to a higher major/minor/patch level or rolled back to a different lower 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.
- If a Control Loop Element has a minor version change, then its Control Loop Instance must have at least a minor version change.
- If a Control Loop Element has a major version change, then its Control Loop Instance must have a major version change.
...