Rolling Out an MES Change to Many Controllers#

A change in the MES process, such as a new state model, a new recipe rule, or a new parameter per machine, often concerns every instance of one or more Automation Controllers. Whether the change reaches the running instances by itself depends on where the workflows read the rule.

Use this page to choose where to keep a rule, to roll out what still needs a new controller version, and to confirm each instance. For what a single change does to one running instance, see Connect IoT Runbook.

Where the Rule Lives#

Where the workflow reads the rule	When a change in MES reaches the running instances	What to do
A configuration entry, read with Get Configurations when the rule applies	At the next read. The task asks MES on every activation.	Nothing.
A DEE action, run with Execute Action when the rule applies	At the next run. The task looks up the Rule and its DEE action on every activation.	Test the DEE action before you change it: every instance uses the change at once.
A table row, read with Resolve Table when the rule applies	At the next read only when Use cache is off, the Cache TTL has passed, or the key values differ from the previous read. With the defaults, Use cache on and Cache TTL `0`, the task keeps its first result for the same key values.	Turn Use cache off, or set a Cache TTL, for a rule that must apply soon after a change. Otherwise, restart the instances.
An entity attribute, read with Entity Instance	At the next read only when Reload in every change is on. Otherwise, the task loads the entity once.	Turn Reload in every change on, or restart the instances.
A value read once, by the Setup workflow or when the driver connects	At the next restart of each instance.	Restart every instance that it concerns. See Connect IoT Runbook.
Workflow logic of the controller, of its parent controller, or of a task library	Only with a new version of each controller that runs it.	Roll out a new controller version. See Roll Out a New Controller Version.

Table: Where a rule lives and when a change reaches the instances

A new state model of an entity is a special case. A workflow that sets the state with Adjust State keeps the entity that it loaded, together with its state model. After the change, give the task a reloaded entity or restart the instances. See Adjust State.

Choose Where to Keep a Rule#

Keep a value that differs per machine, such as a folder or an address, in MES per entity: a Smart Table row or an entity attribute. One controller then serves every machine, and another machine needs only its row and its instance. See Connect IoT Runbook.
Keep a value that changes while the line runs, such as a threshold, in a configuration entry or a table row that the workflow reads when the rule applies, not in the Setup workflow. Each read is one call to MES. When the value rarely changes and a restart is acceptable, read it once when the driver connects and keep it with Store.
Keep a decision that follows MES logic, such as whether a recipe is allowed on a Resource, in a DEE action that the workflow runs with Execute Action. A change to the DEE action reaches every instance at the next run.
Keep workflow logic that several controllers share in a parent controller, see Extend a Controller, or in an Automation Tasks Library, see Automation Tasks Library. A controller uses the task library versions that it lists, so a new library version reaches an instance only through a new version of its controller.

A child controller refers to one version of its parent, chosen when you create the child. A new version of the parent does not reach the existing children or their instances. Create a new version of each child that refers to the new parent version, and update the instances of the child to it.

Roll Out a New Controller Version#

Create a new version of each Automation Controller that the change concerns, make the change, and try it on one instance. For the procedure and for what an update costs, see Change a Controller in Production.
For a change in a task library, run the Update Controller Versions wizard instead. It moves the tasks to the new library version and saves the result as a new version of the controller. It skips the workflows that a child controller inherits from its parent, so update those on the parent.
Create an Automation Scheduled Action for each controller with the following settings. See Create Definition.
- Context Resolution - Automation Controller, with the revision and version that the instances run now. The Scheduled Action creates one task for each active instance of that version. See Context Resolution.
- Detector - No Materials on Resource, for instances of a Resource, so that each instance is updated only while its Resource has no Material. See Detectors.
- Action - Update Controller Version, with the new revision and version. An instance that already runs them ends as Ignored. See Actions.
Follow the tasks until each one reaches a terminal state: Processed, Ignored, Failed, or Expired. You can see the result of each task in the Instances section of the Automation Controller page. See Automation Scheduled Action.

For a worked example of each step, see Scenario 3 - Controller Version Update - No Materials on Resource.

Confirm Each Instance#

Change	What confirms it on each instance
A new controller version	The task of the Scheduled Action ends as `Processed`. The controller logs `Requesting package location. Package='<package>', Version='<version>'` for the packages of the new version, one `Adding workflow` line for each of its workflows, and `Controller process started with success`.
A restart	The controller logs `Controller process started with success`, and each driver logs `Communication state changed <old> -> <new>` until it reaches `Communicating`.
A changed workflow of the version that the instance runs	The controller logs `New workflow '<name>' created and running, draining the old one`.

Table: Log lines that confirm a change

For where the logs are and the other lines to look for, see Connect IoT Runbook.