Skip to content

Automation Scheduled Action Tutorial#

This tutorial walks through five maintenance scenarios using the Connect IoT Automation Scheduled Action feature. All scenarios use a cookie factory as a practical example, but the patterns apply to any Connect IoT deployment.

What Is Automation Scheduled Action?#

Automation Scheduled Action (ASA) is a task-driven maintenance capability that monitors each target runtime and executes the configured maintenance action only when the target is genuinely ready. It allows you to schedule updates, migrations, and custom operations that wait for safe conditions to avoid production interruptions.

Read What is Automation Scheduled Action? for the full definition structure, processing model, and task state reference before working through a scenario.

All scenarios in this tutorial use the same cookie factory. The factory has two production areas - Cookie Manufacturing and Cookie Packing. Manufacturing runs through four sequential steps (Mixing, Molding, Baking, and Cooling) before moving to Packing. Each step contains the physical resources controlled by Connect IoT.

Note

The sample master data in this tutorial prefixes object names with ASA (for example, ASA Mixer-01 and ASA Packer-01). Scenario setup and simulation steps use those exact MES names whenever you need to look them up.

graph LR
    subgraph mfg["Cookie Manufacturing"]
        subgraph step_mix["Mixing - Scenarios 1, 3"]
            subgraph mgr_mix["mixing-manager-nextgen"]
                MX1[Mixer-01]
                MX2[Mixer-02]
                MX3[Mixer-03]
            end
        end
        subgraph step_mol["Molding - Scenario 2"]
            subgraph mgr_mol["molding-manager"]
                MD1[Molder-01]
                MD2[Molder-02]
            end
        end
        subgraph step_bak["Baking - Scenario 5"]
            subgraph mgr_bak["baking-manager"]
                BK1[Baker-01]
                BK2[Baker-02]
            end
        end
        subgraph step_cool["Cooling"]
            CL1[Cooler-01]
            CL2[Cooler-02]
        end
        step_mix --> step_mol --> step_bak --> step_cool
    end
    subgraph pack_area["Cookie Packing"]
        subgraph step_pack["Packing - Scenario 4"]
            subgraph mgr_pack["packing-manager"]
                PK1[Packer-01]
                PK2[Packer-02]
            end
        end
    end
    step_cool --> step_pack

Each Resource has an Automation Controller Instance hosted on a dedicated Automation Manager per Step. However, in Scenario 1, the mixing instances start on mixing-manager-legacy and are migrated to mixing-manager-nextgen as part of the year-end platform refresh.

All five scenarios in this tutorial are episodes from the same year-end platform refresh at the Cookie Company. The refresh spans three months and involves five separate Automation Scheduled Action definitions, each targeting a different Step in the factory with a different maintenance pattern:

  • Dec 28 - Holiday shutdown begins. Two operations run in parallel on separate resources, but both must complete before production resumes:
    • the mixing manager migration (Scenario 1)
    • the molding controller update (Scenario 2).
  • January onwards - Three ongoing operations roll out at their own pace:
    • the mixing controller update triggers on the weekly sanitation cycle (Scenario 3)
    • the packing controller upgrade rolls out as each packer completes its production run naturally (Scenario 4)
    • the baking oven recalibration proceeds whenever the QMS opens a maintenance window (Scenario 5).

Scenarios#

Scenario Objective
1. Change Automation Manager Move all instances hosted by one manager to another without interrupting production
2. Controller Version Update - Fixed Validity Window Update controller version within a bounded window; tasks expire cleanly if the window closes before all instances are processed
3. Controller Version Update - No Materials on Resource Update controller version only after a resource has been continuously empty for a sustained period, with external record confirmation
4. Controller Version Update - Workflow Ready Signal Update controller version when the workflow signals each instance is safe - no fixed maintenance window
5. Custom DEE Action at Every Stage Use DEE actions at every pipeline stage when built-in types cannot express the required logic or an external system owns each decision

Table 1: Automation Scheduled Action Tutorial Scenarios

Before Creating a Definition#

Make sure the following are in place before creating a Definition:

Create the Definition in a disabled state

Create every Automation Scheduled Action Definition with IsEnabled set to false. Before enabling it, open the generated Tasks and confirm they target only the expected entities. Enable the Definition only after verifying the task list is correct.