Scenario 2 - Controller Version Update - Fixed Validity Window#

Overview#

This scenario shows how to use the Validity field as the primary design constraint for an Automation Controller version update that must complete within a fixed maintenance window and must not execute outside it. When the window closes, tasks expire cleanly rather than silently retrying in the next production period. A DEE Action Post-Action Validation registers each completed update as a traceable record in the ERP system.

In this example, the cookie factory's molding Controller is updated during a year-end holiday shutdown, running in parallel with Scenario 1 on separate Resources. Both operations are independent and can proceed simultaneously.

When to Use#

• Holiday or shutdown windows - maintenance that must complete within a fixed production pause and must not spill over into the next production period under any circumstances.
• Compliance deadlines - regulatory or certification updates with a hard expiry date; if the update does not complete before the deadline, the Definition expires cleanly and a new process must begin rather than silently retrying.
• Annual equipment overhauls - one-time updates aligned to a scheduled annual or seasonal maintenance event where the window is fixed, known in advance, and will not recur for months.
• Event-driven one-shot maintenance - updates tied to a specific operational event (end of season, major product changeover, facility audit) that will not repeat on a predictable schedule.
• Risk-bounded rollouts - when you want automatic expiry as a safety net: if the update did not happen within the intended window, the system stops trying rather than executing at an unintended time in the next production period.

Example#

The cookie factory's molding lines are due for a Controller update during the same year-end holiday shutdown as Scenario 1. The two operations run in parallel on separate resources. The molding update must complete within the 3-day window. Any molder that does not reach a ready state before the window closes will have its task expire cleanly rather than silently retry in the next production period.

• Resources: ASA Molder-01, ASA Molder-02.
• Controller: MoldingController.
• Current version: revision B, version 4.
• Target version: revision B, version 5.

graph LR
    subgraph current["MoldingController B/4 (current)"]
        M1[Molder-01]
        M2[Molder-02]
    end
    M1 -->|UpdateControllerVersion| M1T[Molder-01]
    M2 -->|UpdateControllerVersion| M2T[Molder-02]
    subgraph target["MoldingController B/5 (target)"]
        M1T
        M2T
    end

Understanding Validity#

Validity is the number of days a task remains active before it expires. A task that reaches its ValidUntil timestamp without being processed transitions to State = Expired and stops being evaluated.

Choosing the right Validity value is a deliberate design decision:

Table 1: Validity Design Choices

For this scenario, the year-end holiday shutdown lasts 3 days (Saturday through Monday). Setting Validity = 3 means each task is active for exactly 72 hours from the moment the Definition is enabled, then expires if not processed.

gantt
    title Holiday Window - Validity = 3 days
    dateFormat YYYY-MM-DD
    section Factory
        Holiday pause        :done, hp, 2024-12-28, 3d
        Production resumes   :milestone, m1, 2024-12-31, 0d
    section Tasks
        Enable Definition    :milestone, m0, 2024-12-28, 0d
        Tasks active         :active, v1, 2024-12-28, 3d
        Tasks expire         :crit, exp, 2024-12-31, 1d

Prerequisites#

Before creating the Definition, confirm the following:

• Load the Scenario 2 automation master data into MES. It creates the MoldingController [B.4] and MoldingController [B.5] Controller definitions, molding-manager record, and both molder instances (master data package: 01-automation-masterdata.json).
• All target instances are currently running MoldingController revision B, version 4.
• Version B/5 is available on the Controller definition.
• Each molder Resource has a valid MES state model that includes Standby or Scheduled Down.
• The maintenance window start and end times in UTC are confirmed with the operations team.
• MES Configuration Entry /Cmf/Tutorials/AutomationScheduleAction/Scenario2/ErpRegistrationEnabled is set to true if you want the sample Post-Action Validation DEE to end in ProcessedSuccess. Set it to false to demonstrate ValidationFailed.
• Notification templates ASA PreAction Template, ASA Success Template, ASA Failure Template, and ASA Ignored Template exist in MES if you intend to use notifications.
• DEE action ASA_Scenario2_RegisterMolderUpdateInERP is created and deployed in MES before enabling the Definition (see How To: Create or Import a DEE Action).

Configuration#

Why This Pattern#

This Definition uses the following combination of components:

Table 2: Scenario 2 Component Design

The time-window preconditions and the Validity field serve different purposes and complement each other: Validity defines the task lifetime, while AllowedTimeWindow restricts within which hours of each day the action can run.

Create the Definition#

Open Automation Scheduled Action and select Create (see Create Definition). The wizard has four tabs.

Tab 1 - General Data#

Start by filling in the general definition fields.

• Give it a name like CF_Molding_HolidayUpdate_B5 and a description that captures its purpose (for example, "Update molding controllers from B4 to B5 during the year-end holiday shutdown.").
• Set Is Enabled to Disabled for now.
• Set Validity to 3 days.

Setting the validity to 3 aligns the task lifetime exactly with the 3-day holiday pause (Saturday–Monday), so tasks expire cleanly when the window closes without retrying in the next production period.

For Context, select Automation Controller, enter MoldingController as the controller.

• Set Revision to B and Version to 4.

This targets all instances currently running MoldingController B/4 (one task per instance).

For the Detector, select Entity State In List and add Standby and Scheduled Down to the state list.

For the Action, select Update Controller Version and set Revision to B and Version to 5.

Optionally, configure notification templates to be alerted at key moments:

Table 3: Scenario 2 Notification Templates

Tab 2 - Pre-Conditions#

Select twice to add the following pre-conditions in this order:

1. Allowed Weekdays - Set the weekdays to Saturday, Sunday, and Monday to match the three days of the holiday pause. Adjust to your actual calendar if needed.

2. Allowed Time Window - Set the window to 00:00–23:59 to allow processing at any time of day during the holiday pause. Use a narrower range if you want to avoid overnight processing.

Tab 3 - Acceptance Gates#

Select and select Ready Delay. Set the delay to 120 seconds. A 2-minute stability check is sufficient here because the holiday shutdown is a known, sustained pause rather than a brief operational transition.

Tab 4 - Post-Action Validations#

Select twice to add the following validations in this order:

1. Max Startup Time - Set the timeout to 300 seconds. This waits up to 5 minutes for the updated runtime to start.

2. DEE Action - Enter ASA_Scenario2_RegisterMolderUpdateInERP as the action. This registers the completed update as a maintenance record in the ERP. If the ERP is unreachable or rejects the record, the task is marked ValidationFailed.

How It Works at Runtime#

After you enable the Definition at the start of the holiday window, the system processes each task as follows:

1. Context discovers all instances running MoldingController B/4 and creates one task per instance. ValidUntil is set for each task from this moment.
2. On every polling pass, the task checks whether ValidUntil has passed. If it has, the task transitions to State = Expired and stops being evaluated.
3. Weekday and time-window Pre-Conditions are checked. Tasks are skipped if outside the allowed days or hours.
4. EntityStateInList checks whether the molder is in Standby or Scheduled Down.
5. ReadyDelay confirms the molder has been in that state for at least 2 minutes.
6. The Action updates the controller from B/4 to B/5.
7. MaxStartupTime waits up to 5 minutes for the updated runtime to start.
8. ASA_Scenario2_RegisterMolderUpdateInERP registers the completed update as a maintenance record in the ERP. If it fails, the task is marked ValidationFailed.
9. The task is finalized and notifications are sent.

flowchart TD
    A(["Task created<br/>ValidUntil set"]) --> EXP{"ValidUntil<br/>reached?"}
    EXP -- Yes --> T_EXP(["Expired<br/>(no retry)"])
    EXP -- No --> B{"Sat-Mon<br/>any time?"}
    B -- No --> S1([SkippedPreConditionFailed])
    B -- Yes --> C{"Molder state =<br/>Standby or<br/>Scheduled Down?"}
    C -- No --> S2([SkippedNotReady])
    C -- Yes --> D{"Stable 2+ min?"}
    D -- No --> S3([SkippedGateFailed])
    D -- Yes --> E["UpdateControllerVersion B/4 to B/5"]
    E --> F{"Running within<br/>300 s?"}
    F -- No --> FAIL([ValidationFailed])
    F -- Yes --> H{"ASA_Scenario2_Register<br/>MolderUpdateInERP passes?"}
    H -- No --> FAIL
    H -- Yes --> OK([ProcessedSuccess])
    style T_EXP fill:#ffebee,stroke:#c62828,stroke-width:2px
    style EXP fill:#ffebee,stroke:#c62828,stroke-width:1px
    style T_EXP fill:#ffebee,stroke:#c62828,stroke-width:2px
    style EXP fill:#ffebee,stroke:#c62828,stroke-width:1px

Monitoring Progress During the Window#

Check Automation Scheduled Action tasks regularly while the window is open:

• Tasks showing SkippedNotReady are waiting for their molder to enter a ready state. This is normal at the start of the window.
• Tasks showing ProcessedSuccess have completed. Confirm these in the runtime inventory.
• Tasks approaching ValidUntil without a terminal state need attention (the molder may be stuck in a non-ready state).

Expected Task Outcomes#

Table 4: Scenario 2 Task Outcomes

Simulating This Scenario#

Confirm the Scenario 2 master data is loaded and all molder instances are running on molding-manager before starting. This scenario uses EntityStateInList for readiness as no file operations are needed. The focus is on enabling the Definition at the right moment and observing the Validity lifecycle.

To Run the Scenario with a Compressed Window#

For a demo, set Validity = 0.042 (approximately 1 hour) and AllowedWeekdays to all days with AllowedTimeWindow = ["00:00-23:59"]. This compresses the 3-day holiday window into a 1-hour demo window, making expiry observable within a single session.

Standard Simulation Steps#

1. Enable the Definition at the agreed window start time. Tasks are created immediately and ValidUntil is set for each.
2. Note the ValidUntil value on one or two tasks. This is the hard deadline for those tasks.
3. Navigate to ASA Molder-01 and transition its state to Standby or Scheduled Down.
4. After 2 minutes (ReadyDelay Acceptance Gate), the task processes and transitions to ProcessedSuccess.

To Simulate an Expiry#

1. Leave ASA Molder-02 in Running state throughout the simulated window.
2. Watch LastEvaluatedAt update on each polling pass while LastOutcome remains SkippedNotReady.
3. When ValidUntil is reached, the task transitions to State = Expired. LastEvaluatedAt stops updating.
4. Transition ASA Molder-02 to Standby after expiry and confirm that the task does not react. It is permanently terminal.

To Demonstrate the Validity Misalignment Risk#

1. Create a second identical Definition with Validity = 10 (or 10 hours for the compressed demo).
2. Enable both at the same time.
3. After the compressed window closes, confirm the 3-day/10-hour Definition still has active tasks.
4. If any molder enters a ready state (Standby or Scheduled Down) after the intended window, the long-validity Definition will still process it.

To Observe the Ignored Outcome#

Before enabling the Definition, manually update one instance to MoldingController B/5 directly from the Automation Controller Instance record. Enable the Definition and the task for that instance transitions immediately to IgnoredNoOp because the target instance is already in the desired state.

To Reset and Repeat#

1. Revert the instance back to MoldingController B/4 from the Automation Controller Instance record.
2. Create a new Definition (the original tasks are in a terminal state and will not re-evaluate). Set a new Validity aligned to the next available maintenance slot.

Handling Expired Tasks#

If any tasks reach State = Expired, the update did not happen for those molders during the holiday window. The Definition is no longer active for those targets.

Immediate Steps#

1. Open each expired task and note the molder name and LastEvaluatedAt timestamp.
2. Check the molder state history to understand why it never reached a ready state during the window.
3. Document the expired molders for your maintenance log and escalation process.

To Re-Run the Update#

1. Create a new Automation Scheduled Action Definition targeting only the missed molders, using a new validity window aligned to the next available maintenance slot.
2. Confirm with the operations team that the next window is appropriate before enabling.