Capabilities

Protocol Support

Industrial connectivity: bridging field protocols into a consistent model of I/O points used by control logic.

Design intent

Use this lens when adopting Protocol Support: define success criteria, start narrow, and scale with safe rollouts and observability.

Adapters keep protocol complexity out of control logic
Scaling/encoding mistakes cause “plausible but wrong” values
Backpressure protects devices and stabilizes fleets

What it is

The edge-agent bridges industrial protocols and maps physical signals (I/O points) into and out of IEC 61499 applications.

Design constraints

Adapters keep protocol complexity out of control logic
Scaling/encoding mistakes cause “plausible but wrong” values
Backpressure protects devices and stabilizes fleets

Architecture at a glance

Endpoints (protocol sessions) → points (signals) → mappings (typed bindings) → control app ports
Adapters isolate variable-latency protocol work from deterministic control execution paths
Validation and data-quality checks sit between “connected” and “correct”
This is a capability surface concern: changes affect real-world actuation

Typical workflow

Define endpoints and point templates (units, scaling, ownership)
Bind points to app ports and validate types/limits
Commission using a canary device and verify data quality (staleness/range)
Roll out with rate limits and monitoring for flaps and errors

System boundary

Treat Protocol Support as a capability boundary: define what success means, what is configurable per site, and how you will validate behavior under rollout.

Example artifact

Implementation notes (conceptual)

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

What it enables

Vendor-neutral integrations (keep existing equipment)
Portable logic via stable I/O abstractions
Safer upgrades by isolating protocol details

Engineering outcomes

Adapters keep protocol complexity out of control logic
Scaling/encoding mistakes cause “plausible but wrong” values
Backpressure protects devices and stabilizes fleets

Quick acceptance checks

Define stable point identifiers and keep protocol details in adapters
Make scaling/units explicit and test data quality under load

Common failure modes

Session flapping from aggressive polling or device session limits
Timeout/backoff misconfiguration creating retry storms
Backpressure issues: buffers fill, telemetry drops, or adapters stall
Partial outages that create inconsistent, stale, or delayed signals

Acceptance tests

Simulate network loss and verify reconnect/backoff behavior
Load test polling rates and confirm devices are not overloaded
Confirm store-and-forward covers expected outage windows
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

Deep dive

Practical next steps

How teams typically turn this capability into outcomes.

Key takeaways

Adapters keep protocol complexity out of control logic
Scaling/encoding mistakes cause “plausible but wrong” values
Backpressure protects devices and stabilizes fleets

Checklist

Define stable point identifiers and keep protocol details in adapters
Make scaling/units explicit and test data quality under load
Set timeouts/retries/backoff to avoid device overload
Monitor connection flaps and read/write error distributions

Next steps

Common questions

Quick answers that help align engineering and operations.

How do we keep protocols from leaking into logic?

Expose a stable I/O model (points/signals) to the app and keep device addressing, retries, and encoding in adapters/configuration.

What’s the most common “it works but wrong” cause?

Scaling/units or encoding mismatches (endian/format). Add validation and out-of-range/staleness detection for critical points.

How do we avoid write conflicts?

Enforce single-writer ownership per output and document it operationally. Conflicts are hard to debug and can be unsafe.