Eclipse 4diac 3.3: EtherCAT, Event Sequence View, and Headless Validation for IEC 61499

An IEC 61499 application has always been easy to draw and hard to audit. You can see the function blocks on the canvas. You cannot easily see the order in which their events fire, and until now you could not make a build server check any of it. Eclipse 4diac 3.3, released on 9 September 2026, moves on both fronts in the same drop: a new Event Sequence view makes event chains legible and directly reorderable, and headless project validation with machine-readable JSON reports makes modelling rules enforceable in continuous integration. The same release adds the first core EtherCAT integration to the 4diac FORTE runtime, which is the project’s opening move toward hard real-time fieldbus I/O rather than the soft-real-time Ethernet and OPC UA layers it has leaned on for a decade.

What this covers: what actually shipped, how an EtherCAT cycle and a 61499 event chain fit together, how to wire OCL validation into a pipeline, where determinism breaks, and what is still unfinished.

Context and Background

IEC 61499 is the event-driven successor architecture to the scan-based world of IEC 61131-3. Part 1 of the standard, IEC 61499-1:2012, defines the architecture in terms of implementable reference models, textual syntax and graphical representations; it is a second edition that cancelled and replaced the 2005 original. Part 2 covers software tool requirements. Part 4, published as IEC 61499-4:2013, defines rules for writing compliance profiles so that devices, tools and applications from different suppliers can interoperate, be portable, and be configurable across vendors.

The practical difference from 61131-3 is that behaviour is driven by events, not by a cyclic scan. A function block only executes when an input event arrives. Data inputs are sampled at that moment. That model maps beautifully onto distributed systems, because an event can cross a device boundary as easily as it crosses a wire on a canvas, and it maps awkwardly onto the mental model of every control engineer who grew up counting scan cycles.

Eclipse 4diac is the reference open-source implementation of that architecture. It ships as five components: the 4diac IDE engineering tool, the 4diac FORTE runtime, 4diac FBE as the build environment for FORTE, 4diac LIB as the function block library, and 4diac SYS as a set of example systems. FORTE itself is a compact C++ runtime aimed at 16- and 32-bit embedded targets, supporting basic, composite and service interface function blocks, adapters and subapplications, plus online reconfiguration of a running application.

The commercial incumbents sit on either side of it. Codesys, TwinCAT and the classic vendor toolchains still own the 61131-3 install base. Schneider’s EcoStruxure Automation Expert is the best-known commercial 61499 product. 4diac occupies the space between research and production: genuinely deployable, genuinely open, and historically weaker than commercial tools on exactly the two axes this release attacks — deterministic fieldbus I/O and engineering-process automation.

The release cadence matters here. Eclipse 4diac 3.3 is the fourth release under the project’s three-month cadence, which means features now arrive in predictable, digestible increments rather than annual megadrops. For teams tracking an open-source runtime in a regulated product, a quarterly train with published New and Noteworthy pages is worth more than any single feature. It also means this release should be read as one step in a sequence, not as a finished platform — a distinction that matters a great deal for the EtherCAT story below. For broader protocol context, our comparison of EtherCAT, PROFINET and SERCOS for motion control sets out what each bus actually guarantees.

What Eclipse 4diac 3.3 Actually Changes for IEC 61499 Teams

Eclipse 4diac 3.3 changes three things that matter in production: 4diac FORTE gains core EtherCAT integration with an initial set of I/O function blocks, the 4diac IDE gains an Event Sequence view that visualises and reorders event chains, and headless project validation now emits JSON reports alongside project-level OCL rule enforcement.

Everything else in the release — and there is a lot of it — orbits those three. The pattern is consistent: the project is moving 4diac from a tool you drive interactively to a toolchain you can automate, and moving FORTE from a runtime that talks to devices over sockets to one that talks to them over a fieldbus.

Figure 1: How the 4diac 3.3 feature set distributes across the IDE and the FORTE runtime.

The diagram separates engineering-time concerns from runtime concerns. On the IDE side, the Event Sequence view, the reworked Bulk Editor and the project-level OCL validation builder all operate on the model. Headless validation is the bridge: it runs the same checks without a GUI and emits a report a pipeline can act on. On the FORTE side, the new EtherCAT core sits alongside the existing I/O infrastructure for WAGO and Revolution Pi hardware, the OPC UA layer, and a management command subsystem that was substantially rewritten this cycle.

EtherCAT in FORTE is a foundation, not a finished fieldbus stack

The release note is precise about scope, and it pays to read it literally. FORTE 3.3 adds “core EtherCAT integration and initial I/O function blocks” with, in the New and Noteworthy phrasing, a “foundation for further EtherCAT expansion in upcoming releases.” That is three things: the core integration, a first set of I/O blocks, and an explicit statement that more is coming.

Why this is a bigger deal than one more protocol in a list: every communication layer FORTE supported before was, at bottom, a message-passing layer. Ethernet TCP and UDP, MQTT via Eclipse Paho, OPC UA via open62541, Modbus TCP via libmodbus, POWERLINK via openPOWERLINK — these carry data between applications. EtherCAT is a different animal. It is a cyclic process-data bus standardised as Type 12 in the IEC 61158 series and as communication profile family CPF 12 in IEC 61784-2, with an installation profile in IEC 61784-5-12 and a functional-safety layer in IEC 61784-3-12. Its defining feature is processing-on-the-fly: a single frame passes through every slave, which reads its output data and inserts its input data as the frame moves past, at wire speed.

That gives EtherCAT two properties FORTE has never had access to. First, a deterministic process image with a bus cycle that can be driven well below a millisecond — a 1 ms master cycle is typical, and cycles at or under 100 µs are achievable on suitable hardware. Second, Distributed Clocks: the first DC-capable slave becomes the reference clock, the master distributes that time base, and each EtherCAT Slave Controller generates local SYNC0 and SYNC1 interrupts from it. Synchronisation on the order of tens of nanoseconds between nodes is the normal published figure. Neither property exists in any socket-based layer, no matter how fast the network.

There is one caveat worth stating plainly, because it shapes how you should plan adoption. As of 20 September 2026, the IDE-side type library entries for EtherCAT — the adapter and configuration types that would let you model an EtherCAT bus graphically — are still in review. Pull request #2896 against 4diac-ide, opened on 18 September 2026, proposes ECController, ECBusAdapter, ECDeviceConfig, ECModuleConfig and a RevisionNo attribute under the package eclipse4diac::io::ethercat. It is part two of a three-way split of an earlier pull request, it has had changes requested, and the ESI device-description import wizard is explicitly deferred to part three. The runtime side landed in 3.3; the engineering-side ergonomics are arriving behind it.

The Event Sequence view addresses IEC 61499’s oldest usability complaint

The single most common criticism of IEC 61499 in practice is not about the execution semantics. It is that a function block network shows you the topology of event connections but not their order. In a scan-based PLC you read the program top to bottom and you know the order. In 61499 you have to trace every connection by hand, and in a network with fifty blocks and several nested subapplications that tracing is where review time goes.

The new Event Sequence view in 4diac IDE 3.3 provides a structural outline of the event connections in a function block network. It shows sequence ordering and event relationships at a glance, supports nested untyped subapplications, and lets you double-click an entry to navigate back to the network editor. Crucially, it is not read-only: drag-and-drop reordering in the view directly reorders function blocks and automatically updates the affected event connections.

That last capability is the one to think hard about. Reordering event connections is a semantic change to the application, not a cosmetic one, because in IEC 61499 the order in which a block emits its output events determines the order in which downstream chains run. Making that operation a drag gesture is enormously convenient and also a new way to break a working application quickly. Treat reordering in the Event Sequence view as a code change: it belongs in a commit, in a review, and ideally under a validation rule.

Headless validation turns a 61499 project into a CI artifact

The third pillar is the least visually exciting and probably the most consequential. Two capabilities combine. First, a project-level OCL validation builder: projects can define custom Object Constraint Language constraints that are evaluated automatically during builds, with violations reported as standard Eclipse markers in the Problems view. Constraints can be loaded from the project and from its build path, validation can be enabled or disabled per project, and obsolete OCL markers are removed when it is disabled.

Second, headless validation was improved so complete projects can be checked in automated builds, with optional machine-readable JSON output containing errors, warnings, resources and line numbers, and with the ability to fail the build automatically when validation errors occur.

Put them together and an IEC 61499 project stops being a thing you inspect by opening it. A team can encode its own modelling rules — naming conventions, forbidden block types on safety-related resources, mandatory adapter usage, limits on cross-device event connections — as OCL constraints, and have every merge request checked against them. The JSON output with line numbers is what makes this usable rather than decorative, because it lets a pipeline annotate the diff instead of dumping a log.

Alongside this, the release adds validation for unused interface pins in composite FB types and subapplications, with quick fixes to delete them, plus better cleanup of obsolete validation markers. Unused pins are the classic residue of iterative modelling; having them surfaced as markers rather than discovered during commissioning is a real saving.

Mechanics: Where an EtherCAT Cycle Meets an Event Chain

The interesting engineering question in this release is not “does FORTE speak EtherCAT” but “what happens when a cyclic, clock-driven bus meets an event-driven execution model.” These are two different notions of time, and the join between them is where your timing budget lives.

Figure 2: One bus cycle expressed as an IEC 61499 event chain inside FORTE.

The sequence runs as follows. The Distributed Clocks SYNC0 pulse marks the start of the cycle in the slave controller. The controller presents a latched input process image. FORTE’s I/O layer notices new input values and fires an indication event into a service interface function block. That block emits an IND event carrying the data into the application. A basic function block evaluates its Execution Control Chart, a transition fires, an algorithm runs, and a confirmation event propagates onward. Eventually an output service block writes values back through the I/O layer, which stages them for the next frame. If the whole chain does not complete before the next SYNC0, you have missed a cycle.

The cycle and the chain have different clocks

Here is the crux. EtherCAT’s determinism is a property of the bus, not of your application. The bus will deliver the process image on time. Whether your event chain consumes it on time is a function of FORTE’s scheduling, the operating system underneath, and the shape of the chain you drew.

Work the numbers for a plausible case. Take a 1 ms bus cycle. Reserve, conservatively, 20% of it as headroom for the I/O layer, the stack, and jitter you do not control. That leaves roughly 800 µs of application budget. A chain of twelve basic function blocks, each executing a short algorithm, might consume 5–15 µs per block including event dispatch on a modern ARM Cortex-A class target — call it 60–180 µs. You have room. Now add one block that performs a floating-point filter over a 256-element array, or one that formats a diagnostic string, and you can consume the entire remaining budget in a single block. These figures are illustrative, not measured; the point is the shape of the arithmetic, and the shape says the risk concentrates in a small number of blocks, not in the length of the chain.

Drop the bus cycle to 250 µs and the picture inverts. Your application budget falls to roughly 200 µs, event dispatch overhead stops being negligible relative to the algorithms, and any chain that crosses a device boundary is out of the question. This is the practical reason our analysis of deterministic IIoT architectures on OPC UA and TSN keeps returning to the same rule: decide your cycle time first, then decide what is allowed to run inside it.

Reading the Event Sequence view against a real cycle budget

The Event Sequence view becomes considerably more useful once you read it as a timing artifact rather than a documentation artifact. The view gives you the ordered outline of event connections. That outline is, structurally, the worst-case path through the application for one triggering event.

So the review question changes. Instead of “is this network correct,” you can ask “how many blocks sit between the I/O indication and the output write, and does any of them do unbounded work.” The view answers the first half directly. The second half still needs you to open the algorithms, but you now know which ones to open, and in what order they execute.

Two supporting features in this release make that workflow stick. The ECC editor now supports breakpoints placed directly on Execution Control Chart states, which lets you stop a basic function block at a specific state rather than at an arbitrary line of algorithm code. And Replay Debugging now spans multiple devices in one session, with per-device resource selection and independently configured replay options. For a distributed application where a chain crosses three controllers, a single multi-device replay is the difference between reconstructing a fault and guessing at it.

A CI shape for IEC 61499 projects

The headless validation work invites a pipeline that most 61499 teams have never had. The shape below is a design, not a product feature — it composes capabilities the release documents individually.

Figure 3: A merge-request pipeline built on 4diac 3.3 headless validation.

A push triggers a headless build. The build resolves library dependencies from the project manifest and build path — an area that was itself reworked this cycle, with a redesigned dependency page, improved refresh after library builds, and an Ant task for configuring GitLab endpoints so that remote library access can be automated rather than clicked. Model validation then runs together with the project’s OCL constraints. The JSON report is produced with errors, warnings, resources and line numbers. A gate reads it: errors fail the build and annotate the merge request; a clean run proceeds to FORTE NG export and a cross-compile of the runtime for the target board.

Two details make this more robust than it sounds. Remote library handling now skips invalid remote versions instead of letting one bad version block valid downloads, which removes a common cause of red builds that have nothing to do with the change under review. And FORTE NG export now handles adapter initial values and the related composite function block configuration more accurately, which reduces the class of defect where the model validates but the exported runtime code diverges from it.

The rule of thumb: put anything you would reject in review into an OCL constraint. Cross-device event connections on a resource marked safety-related. Basic function blocks with more than N states. Subapplications nested deeper than two levels. Direct use of a deprecated library block. None of these are checkable by the standard; all of them are checkable by your project.

The Rest of the Release That Matters in Production

Beyond the three headline items, several changes in Eclipse 4diac 3.3 quietly reduce production risk, and they are worth naming because they are the kind of thing that never makes a launch summary.

The management command subsystem in FORTE was reworked to handle wrong or malicious commands better. Command parsing was restructured, and command execution was separated from parsing. That separation is a security property, not a tidiness one. FORTE’s management interface is how the IDE deploys applications, creates resources and performs online reconfiguration on a running device. A parser that executes as it parses is a parser where a malformed command can leave the runtime in a half-applied state. Splitting parse from execute means a command is fully understood before anything is changed. On an OT network, where the management port is often reachable by anything on the same VLAN, that matters — and it is one more argument for the segmentation approach in our guide to zero trust architecture for industrial OT and IoT.

The OPC UA layer, built on open62541, received a cluster of fixes with a similar flavour. SecureChannel state is now reported correctly in client callbacks, which is the difference between an application that knows its secure channel has dropped and one that discovers it through silent staleness. Query-type command handling in deployment was fixed. Monitoring now supports struct members, so a client can subscribe to a field inside a structured variable rather than the whole structure — meaningful for bandwidth on constrained links and for change detection granularity. OPC UA was also enabled on the project’s Linux CI workflows, which means these paths are now regression-tested rather than hand-checked.

On the runtime, adapter instances now receive unique IDs to prevent event overlap. That is a subtle and nasty class of bug: two adapter instances sharing an identity means events intended for one can be observed by the other, producing behaviour that looks like a race condition in application logic when it is actually an identity collision in the runtime. Timer-related fixes and a regenerated RampLimitFS implementation with corrected initialisation behaviour round out the runtime work.

Industrial I/O support was extended in step with the EtherCAT work. WAGO and Revolution Pi I/O were updated to the latest I/O infrastructure, and register communication for the WAGO 750-636 module — a drive controller — was added, with corresponding library expansion on the IDE side. Device types can now restrict which communication profiles are presented to users, so an engineer configuring a device sees only the profiles it actually supports. That is a small change that eliminates a whole category of commissioning error.

The editing and refactoring improvements deserve a paragraph because IEC 61499 projects age badly without them. Renaming a structured member now propagates correctly. Copy and rename refactorings preserve dependent references, values and connections more reliably. Editing large structured and array initial values no longer requires expanding and storing complete values — 4diac can preserve only the differences from the defaults, which keeps model files smaller and, incidentally, keeps diffs readable. Simple function block types gained a dedicated Event Actions tab for assigning algorithms and output events to input events in a table, with multiple actions per input event, reorderable and deletable in the property tab.

Finally, robustness. If a type cannot be loaded, 4diac can now represent the failure as an error library element and keep the project usable, rather than failing the load. Open editors can be reloaded from disk after external file changes — essential if you are editing model files from git or a script. The Search References view now shows the relevant source line in the results. Connection editing supports more aggressive deletion and automatically merges compatible connection paths during reconnect. And, in a small piece of deliberate whimsy, deleting function blocks and connections can trigger an optional visual explosion effect.

Looking forward, the 3.4 development cycle moves to Java 25, reported in the project’s weekly update of 4 September 2026. For anyone embedding the IDE in a build container, that is a dependency change to plan for now rather than discover later.

Trade-offs, Gotchas, and What Goes Wrong

The honest summary of Eclipse 4diac 3.3 is that it raises the ceiling without removing the floor. Several things can still go wrong, and most of them are structural rather than defects.

Figure 4: Where determinism leaks in a distributed IEC 61499 application.

The first and largest trap is assuming EtherCAT makes your application deterministic. It does not. It makes the bus deterministic. If your event chain crosses a device boundary, the crossing goes over a publish-subscribe or client-server communication layer whose timing has nothing to do with the EtherCAT cycle. A chain that looks tight on the canvas can span three network hops. The Event Sequence view will show you the chain; it will not tell you which edges leave the box.

The second trap is scope. Core integration and initial I/O function blocks are exactly that. If your bus has servo drives expecting CoE with a specific PDO mapping, or you need SoE, FoE or EoE, or you need Safety over EtherCAT for a SIL-rated function, verify block by block that what you need exists in this release. The absence of the ESI import wizard — deferred to a later pull request as noted above — means device description handling is manual for now. Budget for that.

The third is the Event Sequence view’s power. Drag-and-drop reordering updates event connections automatically. It is genuinely fast, and it will happily produce a semantically different application from an accidental drag. The mitigating control is a project-level OCL constraint plus a review of the model diff, not carefulness.

The fourth is OCL itself. Object Constraint Language is expressive and unfamiliar to most controls engineers. A team that writes twenty constraints in a burst and never revisits them ends up with a build that fails for reasons nobody remembers. Start with three or four rules that encode things you already reject in review, and add a rule only when a defect escapes.

Fifth, the online reconfiguration story cuts both ways. FORTE’s ability to reconfigure a running application is one of its best features and a genuine hazard: management commands arriving during a cycle compete with the cycle. The parse-then-execute rework reduces the chance of a half-applied state; it does not make deployment free. Deploy during a maintenance window on anything that moves.

Sixth, there is no substitute for measuring. Nothing in this release gives you a worst-case execution time for an event chain. The ECC breakpoints and multi-device replay help you understand behaviour; they do not bound it. If you need a number, instrument the runtime and measure on the target, at the target’s clock rate, with the target’s load.

Practical Recommendations

If you are already running 4diac in production, the upgrade case for Eclipse 4diac 3.3 is strongest for the validation work, not the EtherCAT work. Headless validation with JSON reports pays back immediately on any project with more than one engineer. The EtherCAT integration is worth a pilot on a bench rig and worth watching across the next two quarterly releases, but it is not yet a reason to move a motion-control application off a proven stack.

If you are evaluating IEC 61499 for the first time, the sequence that works is: model a small system in the IDE, stand up FORTE on a Linux target, prove the event chain with Replay Debugging, and only then introduce fieldbus I/O. Prove the execution model before you introduce a second notion of time.

A short checklist for adopting this release:

• Pin your toolchain. Record the exact 4diac IDE and FORTE versions in the repository, and plan for the Java 25 move in the 3.4 cycle.
• Add headless validation to CI before you add anything else, and fail the build on validation errors from day one.
• Write three OCL constraints that encode rules you already enforce by review. Add more only in response to escaped defects.
• Run the unused-interface-pin validation across existing projects and clean up the results in a dedicated commit, not mixed with functional changes.
• Use the Event Sequence view in review. Count the blocks between I/O indication and output write, and open the algorithms on that path.
• Treat any drag-reorder in the Event Sequence view as a behavioural change requiring the same review as an algorithm edit.
• Restrict the FORTE management port by network policy. The parser rework hardens it; it does not authenticate callers for you.
• Measure worst-case chain execution on the target hardware before committing to a bus cycle time.

Frequently Asked Questions

What is Eclipse 4diac 3.3 and when was it released?

Eclipse 4diac 3.3 is the September 2026 release of the open-source IEC 61499 toolchain, published on 9 September 2026 and the fourth release under the project’s three-month cadence. It spans the 4diac IDE engineering tool and the 4diac FORTE runtime. Its headline additions are core EtherCAT support in FORTE, an Event Sequence view in the IDE for visualising and reordering event chains, and headless project validation with JSON reports plus project-level OCL rule enforcement.

Does 4diac FORTE now fully support EtherCAT?

Not fully. The release adds core EtherCAT integration and an initial set of EtherCAT I/O function blocks, described by the project as a foundation for further expansion in upcoming releases. That is a first-class starting point, not a complete stack. Verify the specific application-layer protocols and device profiles your hardware needs before planning a migration, and note that the IDE-side EtherCAT type library and ESI import tooling were still in review as of late September 2026.

What does the Event Sequence view do that the network editor does not?

The network editor shows event connections as topology. The Event Sequence view shows them as an ordered structural outline, including nested untyped subapplications, so you can read the sequence in which chains execute without tracing every connection by hand. Double-clicking an entry navigates back to the network editor. It also allows drag-and-drop reordering of function blocks, which automatically updates the affected event connections — a behavioural change, so review it accordingly.

How do I run 4diac project validation in CI?

Use headless validation. 4diac 3.3 improved it so complete projects can be checked in automated builds, with optional machine-readable JSON output listing errors, warnings, resources and line numbers, and with automatic build failure when validation errors occur. Combine it with the project-level OCL validation builder so your own modelling constraints are evaluated in the same pass. The line numbers in the JSON are what let a pipeline annotate a merge request rather than dump a log.

Is IEC 61499 a replacement for IEC 61131-3?

They solve different problems and coexist in practice. IEC 61131-3 defines the programming languages for a scan-based controller. IEC 61499 defines an event-driven architecture for distributed systems, with IEC 61499-1:2012 covering the architecture and IEC 61499-4:2013 covering compliance profiles. FORTE itself supports IEC 61131-3 edition 2 elementary data types, structures and arrays inside 61499 function blocks, so algorithm-level knowledge transfers even though the execution model does not.

What should I watch for in the 3.4 release cycle?

Two things. The 3.4 development cycle moves to Java 25, which is a concrete dependency change for anyone building the IDE in a container or pinning a JDK. And the EtherCAT work continues: the IDE-side type library entries and the ESI device-description import wizard were still open pull requests in September 2026, so graphical EtherCAT bus configuration is the capability most likely to land next.

Further Reading

• EtherCAT vs PROFINET vs SERCOS for motion control — what each bus actually guarantees on cycle time and synchronisation.
• PROFINET vs EtherCAT vs OPC UA FX over TSN — how the classic fieldbuses relate to the converged TSN stack.
• A deterministic IIoT reference architecture on OPC UA and TSN — budgeting latency across an industrial network.
• Zero trust architecture for industrial OT and IoT — segmenting management interfaces like FORTE’s.
• Eclipse 4diac 3.3 New and Noteworthy — the project’s own feature-by-feature release page.
• EtherCAT Technology Group: technology overview — processing-on-the-fly, Distributed Clocks and the IEC standardisation path.

By Riju — about