Change a Controller in Production#

The Automation Controller is a versioned entity. Each Automation Controller Instance runs one version of it: the version it was connected with, until you update the instance. Instances of one controller can run different versions at the same time.

Use this page to decide where to make a change, to move instances to a new version one at a time, to roll back, and to review what the Update Controller Versions wizard changes in your workflows.

What Reaches a Running Instance#

A running controller follows changes to the workflows of the version it runs, and only of that version.

Table: What a controller change reaches

Version States#

A new version starts in the Created state, where you can edit it. To release it, add it to a Change Set, request approval, and approve it: the version becomes Active. Set it Effective with Set Version as Effective, or enable Make Change Set Items Effective on Approval on the Change Set. For the full state model, see Universal State Model and Change Set.

Update on the Connect IoT page offers every version of the instance's controller, in any revision, that is in the Created, Active, or Effective state. A version waiting for approval (Frozen) or terminated is not offered. A revision marked obsolete cannot be assigned to an instance again; see Mark Revision as Obsolete and Reactivate Revision.

Put a New Version into Production#

1. On the Automation Controller page, open the version that runs in production and select New followed by Version. Select the Change Set. See Create Automation Controller.
2. Change the workflows of the new version in the designer. No running instance receives these changes.
3. Try the new version on one instance:
   1. On the Connect IoT page, select the instance and select Stop. Update is available only for an instance that is not running.
   2. Select Update. In the Controller step, select the new version and select Next. The wizard does not accept the version that the instance already runs.
   3. In the Automation Driver Instances step, check the driver instances. For a driver that the new version adds, select its entity and Automation Manager. Select Update. The instance must end with one driver instance for each driver of the new version and its parent controllers. Otherwise, the update fails.
   4. Select Start. The new controller logs one Adding workflow line for each workflow of the new version.
4. While the version is Created, every further edit reaches this instance at once. When it behaves as expected, request approval of the Change Set and approve it.
5. Move the remaining instances to the new version, either one at a time as in step 3, or with an Automation Scheduled Action (ASA) that waits until each entity is idle. See Move Many Instances with an ASA.

For the procedure on the Connect IoT page, see Connect IoT.

What an Update Costs#

Stopping and starting the instance costs what a restart costs: every workflow of the controller starts again, each Setup chain runs again from OnInitialize, values stored as Temporary are lost, and a file driver with ignoreInitial set to false reports every file still in its folder as new. See Connect IoT Runbook.

The instance keeps its name and ID. The data store of an instance belongs to its instance ID and is kept in the persistency location of its Automation Manager, so values stored as Persistent stay with the instance and the new version reads them.

A value that the new version stores under an identifier that the old version already used starts from the old value. Rename the identifier when its meaning changes. See Store Data.

Move Many Instances with an ASA#

The Update Controller Version action of an Automation Scheduled Action stops each instance, moves it to the revision and version you specify, and starts it again, when its Detector and Acceptance Gates report that the entity is ready. It does not require you to stop the instance first. See Actions and the controller update scenarios Scenario 2 - Controller Version Update - Fixed Validity Window, Scenario 3 - Controller Version Update - No Materials on Resource, and Scenario 4 - Controller Version Update - Workflow Ready Signal.

The action matches the drivers of the instance to the drivers of the target version by name. It fails when the target version has a different number of drivers, or when a driver cannot be matched. For a version that adds a driver, update each instance on the Connect IoT page, or replace it as described in Connect IoT Runbook.

Roll Back#

• Move the instance back to the earlier version: Stop, Update with the earlier version, and Start. The earlier version stays selectable while it is Active or Effective and its revision is not obsolete.
• For many instances, use an Update Controller Version action with the earlier revision and version.
• A rollback costs what an update costs. Values stored as Persistent by the newer version stay in the data store of the instance.

Update Controller Versions Wizard#

The wizard moves the tasks and converters of a controller's workflows to newer package versions, runs their migrations, and saves the result as a new version of the controller. Run it after you synchronize an Automation Tasks Library (Automation Tasks Library) and as part of the 12.0 upgrade.

Open the version to update from on the Automation Controller page and select Update in the Connect group of the top ribbon. The button is available while the revision of the controller is in the Active revision state. The wizard has the following steps:

Table: Steps of the Update Controller Versions wizard

When you select Update, the wizard does the following for each workflow:

• Sets the new package version on every listed task and converter.
• Runs the migrations that the task or converter declares up to its new version. A migration can change settings, replace a task, or rename its ports and links. For example, the 12.0.0 migrations replace the file tasks with Execute Equipment Command and On Equipment Event.
• Skips the tasks that show the FALLBACK label, from the task packages that 12.0 no longer bundles, and leaves them as they are.
• Skips the workflows inherited from a parent controller. Update those on the parent. See Extend a Controller.

The result is a new version in the Created state. Running instances keep their version until you update them.

Migration Log#

When the update completes, the wizard shows the messages of every migration it ran as feedback messages. Each message starts with the task it concerns: the task ID and name in Data Flow, the task name in Control Flow. A warning usually names a task that the migration could not convert and that you must change by hand. Keep the messages for the review.

Review the New Version#

1. Open each task that a migration message names, and complete the change it asks for.
2. Open every workflow of the new version. Check that no task shows the FALLBACK label, and that the links of migrated tasks still connect the ports you expect.
3. Try the new version on one instance, as described in Put a New Version into Production, before you approve it.