Events¶

An event is a timed change. Everything that happens to a plant during a run is an event: a planned setpoint change, a fault, a production transition, a maintenance task.

What an event does¶

An event has a time, a target, an action and a profile:

• set to a value, shift by a value, scale by a factor, or reset an operator to its initial state;
• at once (step) or as a ramp over a duration.

A new event starts from the target's current value, even in the middle of a ramp. A ramp from an unset (NaN) value becomes a step.

Events never write signals directly. They drive:

• schedule sources: setpoints, modes, manual outputs, unbound template ports and custom schedules are schedules, piecewise profiles that events move;
• promoted parameters: parameters that events target (see below);
• operator states, with reset: maintenance returns fouling or drift to zero this way.

What an event may target¶

Events are checked when they are scheduled, and a refused event says what to target instead:

A set to a value outside a parameter's range is refused when it is scheduled; a shift or scale that would leave the range fails when it is applied.

Promoted parameters¶

A parameter becomes a signal, is promoted, only when an event targets it; all other parameters stay compiled constants. A promoted parameter is driven by a schedule, appears in run.truth and is a node of the causal graph, so the path from a fault to its effects can be traced.

A parameter can also follow other signals through a modulation: its effective value is its base value times every scale signal plus every shift signal, and events drive the base. Degradations use modulations: fouling scales a heating gain, drift shifts a transmitter's offset.

Where events come from¶

Faults, transitions and tasks are aliases: each expands into ordinary events on schedules, parameters and states. run.meta["events"] logs every applied event, per lane, with the value before and after it.