Best practices for Management of Change (MoC)

Data that is sourced from AVEVA Measurement Advisor should not be configured for MoC.

MoC consists of some independent components (for example, Skelta, Orchestrator, and MoCAgent) that are not capable of using the full redundancy model. Redundancy is therefore limited to the ability of those independent components. In extreme cases, when network connectivity has been disrupted between the primary and backup system, this redundancy limitation will affect promotion of the MoC package. However, emergency change promotion will bypass this limitation and allow the package to be promoted.

Rollback to an invalid state is not supported. MoC is unable to restore invalid states in the following cases:

The flexExclusivity table will allow you to insert a record without valid FlexTagType1 or FlexTagType2 fields. These fields are a complex type with enumeration and can be updated with valid values. When these changes are promoted later and a failure occurs for any reason, rollback will not be able to set these fields from valid to either empty or invalid.
The almsuppression table will allow you to insert a record without configuring the Parent Point when the Suppression Method is either Parent Control or Parent Alarm in the Advanced Database Editor (ADE). If the Parent Point is subsequently updated and promoted, MoC will not be able to rollback the record to the previous invalid state, and the rollback will fail.
The Pipeline Monitor Volume Device (plmvoldevice) table will allow you to insert a plmvoldevice record without configuring the Device Path field in ADE. The recommended method for adding a plmvoldevice record is to create the new record and immediately edit it to add the valid Device Path field information. If the Device Path field is not specified but is subsequently updated and promoted, MoC will not be able to rollback the path to the previous invalid or blank path, and the rollback will not complete/succeed. Similarly, when the plmvoldevice record is deleted and the changeset is canceled, MoC will not be able to rollback the record to the previous invalid state, and the rollback will not complete/succeed.
Accumulator fields need to be classified as configuration data to allow proper promotion of the accumulator record with MoC. Changing the classification for these fields can impact the ability to promote accumulator records using MoC. Similarly, if an accumulator record is deleted and the changeset is canceled, MoC will not be able to rollback the record to the previous state, and the rollback will fail.

If you want to undo a specific change from an MoC zone or set of MoC zones without rolling back an entire package, consider creating a new changeset/package with just that specific change applied and then publishing that single change.

If MoC is enabled (EnableManagementOfChange), all RealTime applications (Microsoft SQL Engine, Business Logic Tier [BLT] Hosts, AVEVA Pipeline Operations for Liquids applications, ACEEngine) must be able to connect to RabbitMQ or the applications may fail.

MoC will only track fields in tables that have the classification attribute set to config in the schema definition. For example, no fields in the remconnjoin table are currently supported by MoC. This particular scenario impacts the promotion of connection, remote, and remconnjoin components as a package because an additional change to the join table (remconnjoin) is required after promoting the package(s) on the destination system.

MoC package deployment requires all datasets of records within the package to be both owned and controlled by the same system as the MoC dataset.

Before you deploy an MoC Package, ensure the Development zone computer is not connecting and polling data from the protocol simulator.

The strapping table assigned to each tank record is recorded using MoC; however, the creation or updating of strapping tables themselves, which are stored in the Historical Microsoft SQL Server, is not tracked using MoC. Changes to strapping tables need to be made on each individual zone or replicated using a method other than MoC, such as DataPump.

Create a directory outside the bin directory to organize and store your packages, as access to the bin directory will be limited and the files may be difficult to find.

Only one execution of the Batch Tracking Compiler (BTC) or LMSDel entries should be included per changeset.

To ensure executions of BTC can be rolled back successfully, an initial state of the files used must be recorded in the MoC database. Use BTC -r (where -r is replace) to record this initial state.

When inserting a tank record (through .l file loading or ADE cloning/inserting), the Creep Threshold Violation Limit value (on the Alarming tab in ADE or creepThreshViolationLimit in tank.l) should be set immediately to a valid range value (2 - 10), even if that value is not used. This will ensure MoC can rollback changes to the Creep Threshold Violation Limit field, delete the tank record at a later time, or reinsert the tank record to properly restore the value.

When creating or modifying a tank record through Interactive SQL (ISQL) with the source_type field set to SCADA, the tankin.iospec.external field must not be modified. When creating or modifying a tank record through ISQL with the source_type field set to DIRECT, the rt_path field must not be modified. There are VDB overrides that clear the values from tankin.iospec.external or rt_path when setting the source_type field to a specific value.

This issue is not present in ADE as ADE will prevent you from editing the cleared tankin.iospec.external or rt_path fields. To verify the values of these fields, navigate to the following locations in ADE:

For the tankin.iospec.external field, navigate to the tank record > Remote Input tab > Direct Field Source > Input Coordinates field.
For the rt_path field, navigate to the tank record > Remote Input tab > OASyS RealTime Source > RealTime Source field.

When restoring deleted records, consider the following:

Deletion of protocol records should not be done directly. When the associated remote is deleted, protocol records rely on the VDB layer to be deleted.
Deletion of records from the AVEVA Pipeline Operations for Liquids pipeline and section tables in ADE or ISQL should be executed through the LMSDel and BTC tools, which are tracked by MoC.

Note: The LMSDel tool cannot delete a non-owning pipeline or a pipeline that does not have an associated dataset. Use the BTC tool to assign a dataset to a pipeline first if one is not configured. For more information, refer to the AVEVA Pipeline Operations for Liquids Administrator documentation.
Deletion of a tank record with the Creep Threshold Violation Limit outside the supported range (2 - 10) will fail during rollback. The Creep Threshold Violation Limit value should be updated to a proper range value even if Creep Alarm Suppression is not used.
Rollback for the deletion operation of a message set record in the message table will be prevented by MoC. A new changeset should be created to insert the message set record again. This will guarantee that all messages in a set get created in a consecutive memory block.
Deletion of a fieldDrivenCondition record automatically causes the deletion of fieldDrivenConditionJoin records that may have been referenced by that fieldDrivenCondition record. Deletion of an analog, a rate, a status, or a multistate output point referenced by a fieldDrivenConditionJoin record will automatically delete the fieldDrivenConditionJoin records.
In order to provision for the successful rollback operation of a changeset containing delete operations for records that have an association to join records, such as fieldDrivenCondition and fieldDrivenConditionJoin records, AVEVA recommends to first manually delete the fieldDrivenConditionJoin records before deleting the fieldDrivenCondition record. This creates a relationship in your changeset that can be restored in the event there is a need to roll back a deleted fieldDrivenCondition record. The same recommendation applies to the deletion of output points associated with fieldDrivenConditionJoin records.
Deletion of a station or group record automatically sets the value of the station or group references in almSevOverriderecords to zeroes.
In order to provision for the successful rollback operation of a changeset containing delete operations for records that have an association to other record types, such as the almSevOverride, AVEVA recommends manually changing the record to another valid station or group, or deleting the almSevOverride records before deleting the station or group record. This creates a relationship in your changeset that can be restored in the event there is a need to roll back a deleted station or group record.

Updating the Product Type (prodtype) field for any records in the Product Compatibility (prodcompat) table is not supported for rollback or install. To change the prodtype field, the record must be deleted and re-created. VDB side effects will not allow a change to this field to occur correctly.

All interactions with the connectivity table should go through BTC directly, which will be tracked by the run of the BTC tool with the associated .bt file. The connectivity table is not tracked by MoC for any changes performed using direct access to the connectivity table (that is, via the Interactive SQL [ISQL] tool).

The following tables call Function puts (fnputs) that are not currently tracked by MoC and will require you to manually insert records for these tables into the destination system:

remconnjoin
regionSiteJoin
siteStationjoin

Records from the almdisturbance, systemEndpoint, and StoreAndForward tables should be excluded from MoC as they are limited by system names. If they need to be included, all MoC zones must contain the same system name configuration (as displayed in Active Directory Lightweight Directory Services [ADLDS]/Network Management Console [NMC]). This means the listed systems within the NMC should be the same across all MoC zones. This does not require the computer names to match in each system. If this recommendation is not followed, changes (inserts, updates, deletes) to records in the almdisturbance, systemEndpoint, and StoreAndForward tables may become invalid, irrelevant, or fail to promote due to a system name mismatch.

Note: Records from the StoreAndForward table will be exceptionally difficult to include as it will require a system restart for the changes to take effect.

If the installation of a changeset within a package exceeds the InstallerInstallationTimeout interval, the package status will be Timed Out in the MoC zone. The Timed Out package status does not indicate that the installation of the changeset has failed, only the configured time out has elapsed for the installation of the current changeset, and manual intervention may be required to determine whether the installation is blocked. If the package store audit log is being updated with subsequent events after the time out event, installation is progressing, and no action is required. If the package store audit log does not show progress after waiting for a reasonable period, consider contacting the AVEVA Enterprise SCADA Support Team to determine how to proceed.

There are a few scenarios to evaluate when the package status is Timed Out in the MoC zone:

A time out occurred without failure, and the process is still running. When this happens, an automatic rollback will not occur.
A time out occurred, a failure is reported, and the process has stopped running. When this happens, an automatic rollback will not occur.
A failure is reported before a time out occurs. When this happens, an automatic rollback will begin.

In all scenarios, you must verify if the timed out changeset has completed. In some instances, even if you have exceeded the allocated time, the process may still complete.

If a rollback does not occur automatically, you may attempt a rollback operation manually to restore the database to a previously known state. However, before attempting a rollback, we recommend resolving the reason for the timeout as subsequent rollback failures could cause the database to enter an unknown state, and it may be necessary to recover data from the savedata files.

For more information on time outs, contact AVEVA Customer Support.

The system generates a RealTime changeset database backup when you run the savedata command. If the RealTime service has been restarted, the system restores the changeset database to its state at the time of the last execution of the savedata command. Restoring the changeset database to the former state after restarting the RealTime service can have the following consequences:

The system will restore changesets published after the execution of the savedata command to the changeset database.
Changesets closed after execution of the savedata command will be open.
Changes recorded to the changeset database will no longer exist.

To preserve the changeset database state, it is recommended that you execute a savedata command prior to shutting down or restarting the RealTime service.

You can add changesets to multiple unpublished packages. Although this is generally not recommended, as it can result in a failure when installing changesets, it could be beneficial in cases where there are abandoned packages or packages that are not planned for further distribution (that is, orphaned packages).

Using alternative tools, such as dbll instead of BTC, could impact the ability of MoC to roll back subsequently deleted records, as there are no MoC tracked restore points to roll back to. This is evident with records that use auto-generated names or references, such as plmvoldevice and pipeline records.

Avoid classifying fields as configuration fields if they are changed by Controllers, as this can lead to prior state comparison failures when promoting changes. Configure these fields as operational instead. If the desired objective is to preserve Controller-modified data after point deletion, rather than deleting the point, consider removing the point from polling and using alternate groups or datasets to retire or decommission the point.

The Product Type (prodtype), Maximum Physical Level (max_phys.txtlev), Maximum Safe Level (max_safe.txtlev), and Minimum Safe Level (min_safe.txtlev) fields of tank records are currently classified as RealTime fields. Since these fields are not classified as configuration fields, configured values of these fields are not retained when a rollback of a deletion occurs. Controllers will need to configure these fields on production systems to appropriate values for any given tank record when a rollback of a deletion of a tank record is performed.

When you associate a telemetered point record with a watchdog record, the remote record associated with both the watchdog record and the telemetered point record must be the same. If a telemetered point is currently associated with one watchdog record, and you associate the former with a different watchdog record, ensure the new watchdog record is associated with the remote record currently associated with the telemetered point record.

Associating an existing telemetered point record with a new remote record and watchdog record is acceptable when the telemetered point record and the watchdog record both belong to the same remote record. However, rolling back to the watchdog record previously associated with the telemetered point record may have implications due to the remote record currently assigned to the telemetered point record. The check typically performed for watchdog record associations to ensure that the same remote record is assigned to both the telemetered point record and watchdog record could cause either MoC promotion or rollback to fail.
To work around this limitation, disassociate the telemetered point record from any watchdog record before moving the former over to the new remote record. Then, once the telemetered point is relocated, associate it with the desired watchdog record. This ensures that MoC promotion or rollback will succeed.

Both source and destination zones must be at the same Enterprise SCADA version and patch level to ensure that the MoC package is successfully promoted.

AVEVA Enterprise SCADA

Best practices for Management of Change (MoC)

Table of Contents

Best practices for Management of Change (MoC)

Related Links