Glossary · Distributed automation and IEC 61499
Execution semantics (IEC 61499)
Also known as: IEC 61499 execution semantics, IEC 61499 execution model, Event scheduling (IEC 61499)
German: Ausführungssemantik (IEC 61499)
In IEC 61499, execution semantics are the rules that determine when and in which order function blocks execute in response to events; IEC 61499-1 fixes the behavior inside a function block, but leaves parts of the scheduling of events between blocks in a resource to the implementation, so different runtimes can execute the same application differently.
- IEC 61499
- Standards
In one sentence
IEC 61499 execution semantics define how events trigger function blocks; parts of the event scheduling are left to the runtime implementation.
Example
An E_SPLIT block sends EO1 to block A and EO2 to block B, and A itself fires an event to C; one runtime runs A, C, B (depth first), another A, B, C (in queue order), and C reads a value that B has or hasn't yet written.
How it applies
- What the standard fixes: Inside a Basic function block, the rules are precise. The second edition of IEC 61499-1 (2012) clarified them: the resource delivers no more than one input event to a function block at a time; the data inputs associated with that event by WITH are sampled when it is delivered; the event is only used in the first evaluation of the Execution control chart (ECC) transitions, after which only transitions without an event can fire; and the ECC keeps passing transitions until no condition is true.
- What it leaves open: How a resource schedules events between blocks is partly implementation dependent: whether output events are handled depth first or queued, whether an algorithm can be interrupted, whether blocks in one resource run in parallel, and what happens when events arrive faster than they are processed. The research literature describes several execution models that implementations follow, for example sequential (depth-first) execution, buffered sequential execution with an event queue, cyclic execution that scans the blocks in a fixed order, and multithreaded or parallel execution. The standard's resource model leaves room for all of them.
- Why it matters: An application that depends on a particular event order can behave differently after moving to another runtime, even though both are compliant. Typical symptoms are race conditions on shared data, lost events and different results for event fan-out. Designing applications so that the order of independent events doesn't matter, and making required orders explicit with E_SPLIT chains, is the portable way.
- Profiles: A Portability profile or compliance profile can fix the execution semantics that tools and runtimes must follow, so that applications behave the same across products. Where no profile does, the runtime's documentation is the only reference.
- Documentation: State which runtime and which execution model an application was designed and tested for. Where the event order matters, document it in the application description and in the function block's service sequences, and note it as a portability constraint.
IEC 61499 execution semantics vs. IEC 61131-3 task scheduling
IEC 61131-3 runs programs in cyclic or event tasks with a defined order of the program organization units inside a task, so the execution order is usually visible in the project. IEC 61499 has no scan cycle; the order follows the event connections and the runtime's scheduling. The gain is flexibility and distribution; the price is that the execution order must be designed and documented deliberately.