Platform

IEC 61499

How BootCtrl packages Eclipse 4diac FORTE plus a local runtime adapter layer, providing consistent control execution across devices.

PLATFORMCONTACT ENGINEERING
Bootctrl architecture overview

Design intent

Use this lens when implementing IEC 61499 across a fleet: define clear boundaries, make change snapshot-based, and keep operational signals observable.

  • Supervision and lifecycle events turn runtime behavior into operations signals
  • Determinism depends on both scheduling and integration boundaries
  • Restart and recovery behavior should be tested, not assumed

What it is

BootCtrl centers on IEC 61499 runtimes (Eclipse 4diac FORTE). The control-runtime packages FORTE plus a local “runtime adapter” API layer.

Design constraints

  • Supervision and lifecycle events turn runtime behavior into operations signals
  • Determinism depends on both scheduling and integration boundaries
  • Restart and recovery behavior should be tested, not assumed

Architecture at a glance

  • IEC 61499 apps define behavior as explicit interfaces and event/data flows
  • Resources/runtimes execute artifacts; mappings connect real I/O to app ports
  • Validation prevents unsafe wiring and type mismatches from reaching sites
  • This is a UI + backend + edge concern: control design is a product surface

Typical workflow

  • Define scope and success criteria (what should change, what must stay stable)
  • Create or update a snapshot, then validate against a canary environment/site
  • Deploy progressively with health/telemetry gates and explicit rollback criteria
  • Confirm acceptance tests and operational dashboards before expanding

System boundary

Treat IEC 61499 as a repeatable interface between engineering intent (design) and runtime reality (deployments + signals). Keep site-specific details configurable so the same design scales across sites.

Example artifact

Implementation notes (conceptual)

topic: IEC 61499
plan: define -> snapshot -> canary -> expand
signals: health + telemetry + events tied to version
rollback: select known-good snapshot

Why it matters

  • Standardized execution semantics and deployment artifacts
  • Clear separation between control logic and platform integration
  • Operational visibility into the running application

Engineering outcomes

  • Supervision and lifecycle events turn runtime behavior into operations signals
  • Determinism depends on both scheduling and integration boundaries
  • Restart and recovery behavior should be tested, not assumed

Quick acceptance checks

  • Confirm the runtime is supervised and emits health/lifecycle events
  • Validate runtime configuration is generated from snapshots

Common failure modes

  • Drift between desired and actual running configuration
  • Changes without clear rollback criteria
  • Insufficient monitoring for acceptance after rollout

Acceptance tests

  • Verify the deployed snapshot/version matches intent (no drift)
  • Run a canary validation: behavior, health, and telemetry align with expectations
  • Verify rollback works and restores known-good behavior

In the platform

  • Generates runtime configuration from saved snapshots
  • Supervised by the edge agent
  • Exposes health/state for observability

Implementation checklist

  • Confirm the runtime is supervised and emits health/lifecycle events
  • Validate runtime configuration is generated from snapshots
  • Test restart behavior and state recovery expectations
  • Verify resource scheduling assumptions for determinism

Rollout guidance

  • Start with a canary site that matches real conditions
  • Use health + telemetry gates; stop expansion on regressions
  • Keep rollback to a known-good snapshot fast and rehearsed

Acceptance tests

  • Verify the deployed snapshot/version matches intent (no drift)
  • Run a canary validation: behavior, health, and telemetry align with expectations
  • Verify rollback works and restores known-good behavior

Related deep dives

Control designCanvas versioningI/O mappingLive observabilityExecutionOperationsConnectivityTelemetry + events

Deep dive

Practical next steps

How teams typically apply this in real deployments.

Key takeaways

  • Supervision and lifecycle events turn runtime behavior into operations signals
  • Determinism depends on both scheduling and integration boundaries
  • Restart and recovery behavior should be tested, not assumed

Checklist

  • Confirm the runtime is supervised and emits health/lifecycle events
  • Validate runtime configuration is generated from snapshots
  • Test restart behavior and state recovery expectations
  • Verify resource scheduling assumptions for determinism

Next steps

Related topics

Control designCanvas versioningI/O mapping

Deep dive

Common questions

Quick answers that help during commissioning and operations.

What is the runtime adapter boundary?

It is the integration boundary that keeps IEC 61499 logic portable while letting the platform handle I/O, telemetry, and operational concerns safely.

What breaks determinism in practice?

Blocking I/O and variable-latency work on the control path, resource contention, and inconsistent configs across sites.

How do we validate runtime behavior after a release?

Canary deploy, confirm event ordering/timing assumptions via traces, and compare against a known-good snapshot/site.