EtherNet/IP (CIP) Adapter: CIP Sync/PTP, Diagnostics, Redundancy
← Back to: Industrial Ethernet & TSN
Build an EtherNet/IP CIP Adapter that is interoperable and deterministic by freezing the object dictionary + Assembly contract, engineering a robust connection lifecycle, and proving behavior with budgeted latency/jitter and evidence-grade diagnostics.
The page focuses on device-side hooks (CIP Sync timing points, DLR behavior, counters/logs) and ends with executable checklists and pass criteria, without expanding into PHY, TSN/PTP topology, or security-offload domains.
H2-1 · Definition & Page Boundary
One-sentence definition (Adapter vs Scanner)
An EtherNet/IP (CIP) Adapter is the device-side endpoint that implements the CIP object model and executes implicit I/O connections (cyclic data) while exposing diagnostics, time hooks, and robust lifecycle behavior. A Scanner (PLC/controller) orchestrates connections and configuration; scanner-side strategies are not expanded here.
In-scope vs Out-of-scope (hard boundary guard)
- Build a CIP object dictionary that maps Class/Instance/Attribute to firmware storage, with versioning and access rules.
- Define Assembly contracts (Input/Output/Config): sizes, alignment, byte order, update cadence, compatibility strategy.
- Execute implicit I/O connections: connection table, watchdog/timeouts, resource accounting, recovery behavior.
- Keep cyclic vs acyclic paths predictable: isolation, queueing rules, burst containment, and measurable budgets.
- Provide CIP Sync/PTP hooks from the device perspective: required timestamp points/interfaces and verification criteria (no topology tutorial).
- Expose diagnostics & observability: counters, events, and black-box logs aligned to field troubleshooting.
- Support redundancy options at the device behavior level: switchover expectations, storm guards, and pass/fail criteria.
- TSN switch internals and Qbv/Qci/Qav parameterization (link out to TSN pages).
- Deep PTP theory (E2E/P2P correction algorithms, topology calibration) and WR/SyncE details (link out to Timing pages).
- PHY/EMC/Protection (TVS/CMC/magnetics, surge return path, SI) (link out to Co-design pages).
- Cable diagnostics algorithms (TDR/return-loss/SNR implementations) (link out to Cable Diagnostics page).
- Security offload deep dives (MACsec/DTLS/TLS accelerators) (link out to Security pages).
Rule: out-of-scope items may appear only as one positioning sentence + an interface/constraint list + a link-out, with no additional theory sections.
Deliverables (what this page provides)
A closed-loop plan from object model → assemblies → connection lifecycle → data path scheduling, including resource tables and failure handling.
Design → Bring-up → Production gates with concrete checks (dictionary/versioning, isolation rules, watchdogs, counter coverage, regression matrix).
Measurable acceptance thresholds for RPI stability, timeout rates, jitter budget, counter consistency, and switchover behavior (thresholds shown as X/Y/Z placeholders for project-specific tuning).
H2-2 · Where EtherNet/IP Sits (stack & roles)
CIP semantics + EtherNet/IP transport split (control vs data plane)
Used for configuration, object services, diagnostics, and parameter reads/writes. Typically carried over TCP. Engineering focus: burst containment, queue isolation, and consistent object dictionary behavior.
Used for cyclic I/O data transfer with RPI-based expectations. Typically carried over UDP. Engineering focus: deterministic scheduling, watchdog definitions, buffer consistency, and measurable jitter budgets.
Cyclic performance collapses when explicit traffic shares the same CPU/driver queues without isolation. The stack view provides a debug coordinate system: identify whether the symptom is CIP semantics, connection lifecycle, queue contention, or link errors.
Roles & data flow (Scanner triggers; Adapter executes)
- Scanner initiates (e.g., connection open request) and supplies expected I/O contract (instances, sizes, RPI).
- Adapter validates object/assembly references, allocates resources, and creates a connection table entry.
- Run phase maintains cyclic I/O cadence while servicing explicit traffic under isolation rules.
- Watchdog/timeout transitions to safe behavior (data hold/clear per policy), logs cause, and controls recovery pace.
- Recovery avoids storms: bounded retries, backoff, and rate-limited diagnostics.
- CIP layer: object/instance/attribute mismatch, size mismatch, access control mismatch.
- EtherNet/IP layer: connection table overflow, watchdog definition mismatch, inconsistent state transitions.
- Transport/driver layer: queue contention, burst-induced jitter, buffer underrun/overrun.
- Ethernet link layer: link flaps, CRC/drops, duplex/autoneg mismatch (do not expand PHY theory here).
Channel classification table (no frame-level deep dive)
| Channel | Transport (typ.) | Used for | First symptom when broken |
|---|---|---|---|
| Explicit messaging (control plane) | TCP | Object services, configuration, parameter reads/writes, diagnostics | Bursty latency, backlog, or “cyclic gets worse when config tools run” |
| Implicit I/O (data plane) | UDP | Cyclic I/O data exchange under RPI/timeout expectations | RPI misses, occasional timeouts, jitter increase under load |
| Time-aware features (CIP Sync hooks) | Depends on platform | Local time exposure and timestamp points for synchronization features | Good link but drifting timestamps; inconsistent time in logs/counters |
Table intent: guide capture/measurement strategy without expanding into packet-level tutorials.
H2-3 · CIP Object Model for Adapter
Goal: build a maintainable CIP object dictionary that maps Class/Instance/Attribute to firmware storage with clear access rules, version gates, and consistent read/write behavior.
Minimal object set (a closed-loop, not an ODVA course)
- Identity: stable device identity + revision anchor for interoperability, logs, and upgrade traceability.
- TCP/IP: network parameter exposure with deterministic “apply rules” (immediate vs next-cycle vs reconnect).
- Ethernet Link: link state + lightweight counters for fast field triage (no PHY theory expansion).
- Assembly: the I/O data contract container (Input/Output/Config), versioned and testable.
Identity visible → TCP/IP configurable → Ethernet Link observable → Assembly reachable → implicit I/O contract validated. This loop defines the minimum engineering surface for early interoperability testing.
Object dictionary ↔ firmware tables (index, ACL, version gates)
Use a table-driven dictionary keyed by (Class, Instance, Attribute), each entry carrying: type, length, access, alignment, and version range.
- Static: constants (device identity, capability bits, fixed limits).
- Dynamic: runtime state (link state, counters, error flags, temperatures).
- Computed: derived values (windowed statistics, summaries, normalized metrics).
- Define read/write privileges per attribute (including “write requires connection closed” rules when needed).
- Make “write → takes effect” deterministic: immediate / next-cycle / reconnect (select one per field).
- Expose a minimal audit hook: last-write source + sequence + timestamp (for field forensics).
Common failure traps (fast checks that prevent field chaos)
Symptom: open requests fail or tooling reads “wrong object”. Quick check: class/instance references and assembly instance mapping in a single authoritative table. Fix: unify dictionary + EDS/config generation from the same schema.
Symptom: connection opens but values look shifted/garbled. Quick check: field sizes, packing/alignment policy, byte order per type. Fix: contract table drives serialization; add unit vectors that validate offsets and lengths.
Symptom: “random” counter disagreements, unstable diagnostics, intermittent I/O anomalies. Quick check: ensure snapshot or atomic swap at a defined boundary; avoid reading half-updated structures. Fix: double-buffering or snapshot copies with sequence stamping; log partial-read detections.
H2-4 · Assembly & I/O Data Contract
Goal: lock the cyclic I/O contract (size, alignment, cadence, and compatibility) while keeping configuration changes deterministic and observable.
Assembly responsibilities (separate I/O from Config, enforce versioning)
- Input: device → scanner (status, measurements, concise diagnostics).
- Output: scanner → device (commands, setpoints, mode requests).
- Config: behavior-shaping parameters with explicit “apply points”.
Cyclic I/O demands stable cadence and atomic snapshots, while configuration needs deterministic activation rules. Mixing config writes into cyclic payloads creates ambiguous behavior and unstable troubleshooting evidence.
Compatibility strategy (upgrade without breaking the plant)
- Prefer append-only changes; keep existing offsets stable.
- Use reserved slots for future fields; never reuse with new semantics.
- Fix a version header location (ver/len/seq) for fast validation.
- Do not change field meaning without version gates (since/until) and documented behavior.
- Expose capability bits so the scanner can choose safe modes.
- Define a clear default value policy for deprecated fields (stable, not “floating”).
Consistency model (producer/consumer timing + double buffer snapshots)
Producer writes only to shadow buffers; at the defined cycle boundary a single atomic swap publishes a consistent frame. Consumer reads only from the active buffer.
Config writes enter pending state and commit only at an explicit apply point (next-cycle boundary or reconnect). Record apply sequence and timestamp to keep diagnostics evidence consistent.
Assembly Contract Checklist (implementation-ready)
- Layout: fixed header (ver/len/seq), explicit offsets, defined alignment/packing policy.
- Byte order: per-field endianness rules documented and tested with vectors.
- Versioning: schema version + capability bits + since/until gates for semantic changes.
- Defaults: reserved fields fixed to stable defaults; deprecated fields keep deterministic values.
- Cadence: specify which fields update every cycle vs event-driven; avoid mixed timing without labels.
- Snapshot: double-buffer + atomic swap at a defined boundary; sequence stamp for consistency checks.
- Config apply: pending/commit rules defined; apply timestamp/sequence exposed for forensics.
- Test hooks: loopback/synthetic data modes + regression vectors for offsets and sizes.
H2-5 · Connection Lifecycle (Forward Open/Close + RPI + Watchdogs)
Goal: make the “open → run → drop → recover” behavior deterministic and diagnosable by defining explicit connection states, timeout accounting, and resource limits.
Connection types and traffic classes
- Purpose: cyclic process data with predictable cadence (RPI-driven).
- Engineering focus: snapshot consistency, jitter budget, and loss/timeout rules.
- Diagnostics focus: sequence gaps, late frames, watchdog expirations.
- Purpose: configuration, diagnostics, and non-cyclic services.
- Engineering focus: burst containment and isolation from cyclic tasks.
- Diagnostics focus: queue depth, latency spikes, and retry storms.
Keep cyclic (implicit) and acyclic (explicit) paths isolated at scheduling, buffering, and rate-limiting levels to avoid “same RPI, different field behavior”.
Lifecycle state machine (make drops explainable)
- Init: allocate a connection slot; validate parameters; prime buffers.
- Open: complete Forward Open; lock contract (sizes, cadence, endpoints).
- Run: cyclic updates with watchdog accounting; publish health counters.
- Timeout: declare loss using explicit rules (window, missed count, late criteria).
- Close/Recover: release resources; apply backoff; re-enter Open when safe.
Expose per-connection: state, last-rx timestamp, missed count, timeout reason code, last-close cause, and current backoff stage. This converts “random drops” into a traceable timeline.
RPI and watchdog accounting (avoid false-kill / false-accept)
- Choose one primary metric: missed-cycles or elapsed-time window.
- Define late-frame handling: accept-late with counter, or drop-late with reason code.
- Publish the exact accounting window (RPI × N) and the threshold (X placeholder).
- False-kill: aggressive watchdog triggers unnecessary shutdowns on bursty load.
- False-accept: loose watchdog hides real loss and increases process risk.
- Use backoff stages for recovery instead of oscillating open/close storms.
Concurrency and resource limits (keep behavior stable under load)
- Connection table: fixed maximum slots; deterministic allocation policy (no unbounded growth).
- Socket/buffer: per-connection RX/TX bounds; queue depth caps; drop policy with counters.
- CPU budget: cap explicit bursts; keep cyclic ISR/task priority protected.
- Memory pressure: avoid dynamic allocations in Run; pre-allocate and reuse.
When a resource limit is hit, fail fast with a clear reason code and stable counters, rather than degrading cyclic timing silently.
H2-6 · Determinism Budget (Latency/Jitter: scheduling + buffering)
Goal: turn “same RPI but jittery in the field” into a measurable budget across ISR, stack, application, buffer swaps, and transmit scheduling.
End-to-end path decomposition (budgetable segments)
- IRQ / RX entry: interrupt latency + DMA completion to first touch.
- Protocol stack: parsing + connection bookkeeping + queueing.
- Application: control loop compute + state updates.
- I/O snapshot: double-buffer swap + serialization.
- TX scheduling: egress queue, shaping, and actual send time.
Latency and jitter must be measured per segment, then summed against an end-to-end budget with threshold placeholders (X) for acceptance.
Jitter source taxonomy (what usually breaks RPI in practice)
Priority inversion, interrupt storms, and background tasks can shift ISR and cyclic task start times even when nominal RPI is unchanged.
Shared DMA channels, limited FIFO depth, and queue head-of-line blocking add bursty delays that present as “random network jitter”.
Diagnostic reads/writes and configuration services can starve cyclic processing unless rate-limited and isolated by queues and priorities.
Isolation strategies (make cyclic predictable under stress)
- Cyclic/Acyclic split: distinct queues, separate budgets, and independent counters.
- Priority protection: cyclic ISR/task protected; explicit tasks capped and deferred.
- Rate limiting: limit explicit QPS and payload size; apply backpressure with reason codes.
- Double-buffer snapshots: stable I/O publish point, independent of service bursts.
Isolation is verified by counters: cyclic deadline misses, queue depth peaks, explicit throttle events, and snapshot sequence stability.
RPI / Latency / Jitter Budget Sheet (template, thresholds as X)
Fill per segment: typical, worst-case, and jitter (peak-to-peak). Sum against end-to-end targets and record measurement method.
Pass criteria: end-to-end latency ≤ X and jitter ≤ X, while cyclic deadline-miss count stays within X per Y minutes under worst-case explicit load.
H2-7 · CIP Sync / PTP Hooks (device-side only)
Objective: define the minimum device-side time capabilities and verifiable evidence required for CIP Sync—without teaching full-network PTP.
In-scope: timestamp tap points, PHC/local clock quality, driver/stack hooks, device-side error budget and validation evidence. Out-of-scope: PTP topology calibration and E2E/P2P correction details → link to the Timing & Sync page.
CIP Sync goal translated into device requirements
- Expose a single, traceable time base for cyclic I/O updates, events, and diagnostics.
- Expose synchronization state: Locked / Holdover / Free-run with timestamps.
- Provide offset/jitter statistics over a defined window (threshold placeholder X).
- Clock read API with stable units (ns/us) and monotonic behavior.
- Clock adjustment capability (frequency/phase interface scope defined).
- Holdover behavior observable (drift trend and alarm thresholds as X).
Provide measurable outputs: sync state transitions (with timestamps), offset/jitter summaries, and a correlation key that binds timestamps to I/O and events.
Timestamp tap points (list + impact, no algorithm details)
- PHY: smallest path uncertainty (depends on silicon support).
- MAC: common compromise between precision and portability.
- Driver: easy access, but scheduling jitter may leak into timestamps.
- Stack: least desirable; queueing and context switches dominate error.
- Uncertainty: can queue/IRQ delay enter the timestamp path?
- TX mode: one-step or two-step support scope (definition only).
- Evidence: can a timestamp be linked to a frame/event ID reliably?
Timestamping is only “deployable” when the tap point is paired with a correlation method (sequence/conn-id) and bounded queueing behavior.
Error budget (timestamp latency, async paths, queue bias)
- Fixed latency: pipeline + bus traversal (constant term).
- Variable latency: IRQ jitter, queue depth, contention.
- Async path bias: cross-core, locks, cache coherency.
- Egress bias: shaping/QoS queues shifting send time.
- Run cyclic I/O together with explicit bursts and measure the delta.
- Report offset and jitter using a defined window and unit (threshold X).
- Declare pass criteria: offset ≤ X and jitter ≤ X while sync state remains Locked or documented Holdover.
A budget is only useful when each term has a measurement point, sampling window, and a threshold placeholder X for acceptance.
Time Hooks Checklist (interface list)
- PHC read (ns/us) + monotonic guarantee
- PHC adjust (frequency/phase interface scope defined)
- Sync state + holdover status with timestamps
- RX timestamp availability + tap point declared (PHY/MAC/driver/stack)
- TX timestamp scope: one-step or two-step (definition-only, no algorithm)
- Correlation key: sequence/conn-id binding timestamps to frames/events
- Timestamp ring buffer (depth X) + drop counter
- Callback context rule (ISR/thread) + bounded processing time
- Offset/jitter statistics export (window + units, threshold X)
Topology calibration and E2E/P2P correction details belong to the Timing & Sync page; this chapter only defines device-side hooks and evidence.
H2-8 · Diagnostics & Observability (counters → objects → logs → field report)
Objective: convert field failures into evidence by exposing actionable counters, diagnostic objects/events, black-box logs, and a minimal replayable report.
Must-have counters (first layer of evidence)
- Link up/down count and duration distribution
- CRC/error/drop counters by direction (RX/TX) and window
- Speed/duplex change events (with timestamps)
- Forward Open success/fail + reason codes
- Run → Timeout count + timeout definition (missed-cycles or time-window)
- Reconnect count + backoff stage histogram
- Buffer underrun/overrun + queue depth peaks
- Deadline-miss counters for cyclic processing (threshold X)
Counters must be reportable by port/connection/direction and by time window; a single global total is rarely actionable in the field.
Diagnostic objects/events organized by “actionability”
- Connection Health (open/run/close/timeout)
- Timing Health (late frames, jitter markers)
- Resource Health (buffer/queue/CPU pressure)
- Service Health (explicit QPS, service timeout)
- Restart & Recovery (boot cause, recovery stage)
- event_id + timestamp (same time base as I/O)
- scope: port / conn_id
- reason_code (aggregatable)
- snapshot: selected counters (N fields) at event time
Events become searchable and statistically meaningful when they carry a stable reason code and a small counter snapshot that explains “what was happening” at that moment.
Black-box logs (correlate system conditions to comm events)
- Temperature (range + transitions)
- Voltage / power state (brownout markers)
- Reset cause (watchdog/assert/panic)
- Exception summary (PC/hash) for clustering
- Config changes (object/assembly version markers)
- Correlation key: boot_id + uptime + conn_id (or equivalent)
- Ring buffer depth X + log_drop_count counter
- Snapshot window: freeze a small interval around critical events
A black-box log is successful when it can explain “why the same symptom happened” by grouping events with similar power/temperature/reset signatures.
Export & replay: minimal field report dataset
- Firmware ID + object dictionary version + assembly version
- Network summary: link speed/duplex + IP config digest
- Connection summary: conn_id, RPI, timeout definition, watchdog threshold X
- Load summary: explicit QPS and burst markers
- Event window: T0..T1 event list + counter snapshots
- Black-box summary: temperature/voltage/reset cause/exception hash
Recreate the same concurrency profile (explicit bursts + cyclic I/O) and compare reason-code distributions and counter time-series against the exported window.
H2-9 · Redundancy Options for Adapters (DLR: device-side behaviors)
Objective: treat redundancy as measurable switchover behavior and pass criteria, not a label. Device-side responsibilities only.
In-scope: adapter role awareness, switchover I/O behavior, storm suppression, and acceptance criteria. Out-of-scope: PRP/HSR and switch-side zero-loss mechanisms → link to the Ring Redundancy page.
DLR device roles (node / supervisor: naming only, behaviors defined)
- Node: maintain stable I/O behavior while reporting ring/port states.
- Supervisor: coordinate ring fault/recovery states (device-side exposure only).
- Expose ring state codes: Normal / Fault / Recovering with timestamps.
- port_state (A/B): link up/down + forward/block markers
- last_event + reason_code for clustering field failures
- event timestamps on a single time base for correlation
Ring redundancy becomes debuggable only when role/state is observable and tied to switchover windows and I/O behavior.
Switchover I/O behavior (define loss/jitter budgets and recovery rules)
- Keep connection: avoid rebuild; allow brief loss ≤ X packets in window X.
- Conditional rebuild: rebuild only after defined timeout/close conditions.
- Forced rebuild: permitted only in explicitly documented modes; higher storm risk.
- Use double-buffering or atomic swap for cyclic I/O payload updates.
- Freeze policy: hold last-good or safe value during switchover (definition only).
- Track late_update_count and partial_update_prevented_count for evidence.
Record switchover_window_start/end timestamps, lost_packets_count, jitter markers, and the selected behavior profile ID.
Storm suppression (reconnect/backoff, broadcast limits, flap damping)
- Reconnect storms caused by repeated open attempts under resource pressure.
- Broadcast/discovery storms triggered by frequent ring-state changes.
- State oscillation from link flaps (Normal ↔ Fault) without damping.
- Exponential backoff with cap (stage count + delay ≤ X).
- Broadcast rate limiting (≤ X events per second per window).
- Hold-down timer and hysteresis (X ms) to avoid flap-driven churn.
- Event deduplication: merge repeated reason_code within window X.
Expose reconnect_rate, broadcast_rate, state_flap_count, and backoff_stage distribution; these are required to prove stability under faults.
Switchover Pass Criteria (acceptance)
Threshold placeholders use X. Each item requires a defined measurement window and a stable time base for correlation.
PRP/HSR and switch-side zero-loss behavior belong to the Ring Redundancy page; this chapter defines adapter-side behavior and acceptance only.
H2-10 · Security Hooks (CIP Security-aware, adapter-side only)
Objective: provide a minimal, deployable set of adapter-side security hooks (boot, access control, audit, keys) without expanding into cipher suites or offload architecture.
In-scope: secure boot, role/permission gates, audit logging, key storage interfaces, safe defaults, and upgrade rollback. Out-of-scope: MACsec/DTLS/TLS algorithm and offload details → link to the Security Offload page.
Minimal threat model (maps directly to hooks)
Mitigation hook: role-based write permission + audit trail for sensitive object writes.
Mitigation hook: per-operation authorization gates + replay defenses expressed as policy checks (definition-only).
Mitigation hook: signed boot chain + anti-rollback version policy + verified update and rollback logging.
A threat model is useful only when each threat has a concrete gate and an audit event that proves the gate executed.
Adapter-side hooks checklist (minimal viable security loop)
- Signed image verification before execution
- Anti-rollback version policy (monotonic counter)
- Boot failure reason_code + timestamped record
- MUST: role-based permissions for object writes (deny-by-default for sensitive writes)
- MUST: audit event on critical config changes (who/what/when/result)
- SHOULD: rate limit repeated denied writes (≤ X per window)
- MUST: privilege gate for high-impact operations (definition-only)
- SHOULD: safe defaults for risky services (disabled until explicitly enabled)
- Expose policy_version for field correlation
- MUST: keys are non-exportable in plaintext; access is permission-gated
- MUST: key access attempts generate audit events
- SHOULD: key rotation events recorded with timestamps (no cipher details)
Provide audit_event records, boot attestation digest (summary), policy_version, and key-access reason codes to enable traceability and forensics.
Deployment posture (safe defaults, layered roles, upgrade rollback)
- Disable high-risk services until explicitly enabled by an authorized role.
- Separate maintenance operations from runtime cyclic I/O permissions.
- Audit all enable/disable actions with timestamps.
- Operator: observe and acknowledge
- Maintenance: limited config changes with audit
- Admin: policy/key management and upgrades
- Verify signed update before activation; record update_event with digest summary.
- Rollback on failure; record rollback_event and failure reason codes.
- Expose version markers: firmware_id + policy_version + object/assembly versions.
Cipher suites, handshake behavior, and hardware offload selection belong to the Security Offload page; this chapter defines adapter-side gates and evidence only.
H2-11 · Engineering Checklist (Design → Bring-up → Production/Certification)
Goal: converge the whole page into executable gates with measurable evidence and pass criteria (X placeholders). Device-side scope only.
Design Gate — contracts, sizing, observability, and safety hooks (10–15 checks)
The checklist is vendor-agnostic; the following are concrete, commonly used parts for adapter-class designs (choose per availability and requirements):
- Industrial comm SoC/ASIC (multi-protocol option): Hilscher netX 90, netX 52
- MCU/MPU with Ethernet MAC + IEEE1588 support (stack in software): ST STM32H743; NXP i.MX RT1170; Microchip SAME70Q21; TI AM2434
- 10/100 PHY: TI DP83822I; Microchip LAN8742A
- 1G PHY: TI DP83869HM; Microchip KSZ9031RNX
- 3-port switch (for 2-port device/ring-style topologies): Microchip KSZ8563
- Low-cap ESD/TVS arrays (Ethernet lines): TI TPD4E05U06; Littelfuse SP3012-04UTG; Semtech RClamp0524P
- Clock/oscillator examples: SiTime SiT1602; Abracon ASFL1
Bring-up Gate — minimal interop, sweeps, and fault injection (10–15 checks)
- 3-port switch for fault injection / ring-style benches: Microchip KSZ8563
- 10/100 PHY for simple adapters: TI DP83822I (strap options for loopback testing)
- 1G PHY for motion/gateway-class adapters: TI DP83869HM; Microchip KSZ9031RNX
- ESD arrays for repetitive ESD handling on benches: Littelfuse SP3012-04UTG; TI TPD4E05U06
Production Gate — regression, compatibility, certification readiness (10–15 checks)
- Multi-protocol comm ASIC (if using hardened stacks): Hilscher netX 90, netX 52
- MCU/MPU baseline options: ST STM32H743; NXP i.MX RT1170; Microchip SAME70Q21; TI AM2434
- PHY examples: TI DP83822I (10/100), TI DP83869HM (1G)
H2-12 · Applications & Integration Patterns (adapter-side only)
Goal: deliver “how to integrate” answers without expanding into topology or switch configuration theory. Each scenario is defined by adapter-side priorities, hooks, evidence, and pass criteria.
This chapter labels interfaces only (cyclic I/O, explicit, time hooks, diagnostics/audit). Topology design and switch-side parameters belong to the Topologies / Ring pages.
Scenario A · Remote I/O Adapter (high-density DI/DO)
- Freeze and validate Assembly contract; avoid partial updates (double-buffer swap).
- RPI stability and watchdog clarity; minimize false kills with evidence counters.
- Diagnostics-first: actionable counters and reason_code mapping for field service.
- Explicit for configuration; cyclic for I/O; enforce cyclic/explicit isolation.
- Export per-port/per-connection counters and a compact black-box log schema.
- MCU: ST STM32H743 or Microchip SAME70Q21
- PHY: TI DP83822I (10/100) or Microchip LAN8742A
- ESD: TI TPD4E05U06 / Littelfuse SP3012-04UTG
Scenario B · Drive / Motion Module (CIP Sync + jitter budget)
- Make jitter budget measurable (segment timestamps + queue depth markers).
- Keep explicit bursts from contaminating cyclic service (dual-queue + limits).
- Expose time hooks: sync_state, timestamp monotonicity, ts_jump_count.
- Time base and counters must share a single clock reference for correlation.
- Export worst-window jitter and “late update” counts during bursts and faults.
- MPU/MCU with Ethernet + timing hooks: TI AM2434; NXP i.MX RT1170
- 1G PHY: TI DP83869HM; Microchip KSZ9031RNX
- Clock: SiTime SiT1602
Scenario C · Robot cell / Safety island (redundancy + audit)
- DLR switchover behavior must be acceptance-driven (switchover window markers).
- Storm suppression is mandatory: backoff, broadcast limits, flap damping.
- Security hooks emphasize traceability: audit_event for sensitive writes and updates.
- Export switchover_time, lost_packets, reconnect_rate, state_flap_count.
- Export audit_event stream and policy_version for change management.
- 3-port switch (dual-port device topology helper): Microchip KSZ8563
- Comm ASIC option: Hilscher netX 52
- ESD: Semtech RClamp0524P
Scenario D · Gateway-adjacent device (explicit burst isolation)
- Explicit burst isolation is the priority: queue separation + rate limiting + evidence counters.
- Resource sizing must be hard-bounded: connection table + buffers + CPU margin.
- Black-box log must correlate bursts with underrun/late_update events.
- Export per-queue depth, underrun counters, and burst markers.
- Export reconnection backoff metrics to prevent storm cascades.
- MCU/MPU: TI AM2434 or NXP i.MX RT1170
- 1G PHY: TI DP83869HM
- ESD: TI TPD4E05U06
Request a Quote
H2-13 · FAQs (Field Troubleshooting, Adapter-side Only)
Forward Open fails intermittently — check Assembly size/instance mismatch or connection resources first?
Likely cause: Requested O→T/T→O Assembly instance or size does not match the implemented contract, or the device hits a connection/socket/buffer limit under load.
Quick check: Log the requested Assembly instances + expected byte sizes; compare with the device’s contract table; simultaneously read connection table occupancy + last allocation failure reason (socket/buffer/descriptor).
Fix: Freeze the Assembly contract (size/endianness/alignment) and keep backward-compatible mapping; enforce max concurrent connections and add deterministic cleanup on close/timeout to prevent leaks.
Pass criteria: Forward Open success ≥ X% over X attempts; at X concurrent connections, connection occupancy stays below X% and no allocation failures occur.
Same RPI setting, but field jitter is much worse — check cyclic/acyclic isolation or CPU preemption first?
Likely cause: Cyclic I/O shares queues/locks with explicit traffic bursts, or task scheduling/IRQ latency expands under CPU contention.
Quick check: Correlate cyclic late-update counter with explicit message rate; capture ISR-to-send timestamp histogram and the “max ready-to-run delay” for the cyclic task.
Fix: Separate cyclic and explicit paths (queues + threads + rate limits); raise cyclic priority and bound explicit CPU time; use double-buffered I/O updates to avoid lock hold in the send path.
Pass criteria: Cyclic jitter ≤ X (unit defined by system), late updates ≤ X/hour, while explicit traffic at X msg/s does not change cyclic jitter by more than X%.
I/O times out occasionally but the link stays up — watchdog definition or buffer underrun?
Likely cause: Watchdog is keyed to the wrong event (receive vs application update vs transmit completion), or cyclic path experiences queue underrun/missed schedule without physical link loss.
Quick check: Record the watchdog “last-kick source” and timestamp; compare with underrun/late counters and queue-depth minima around timeout events.
Fix: Define watchdog on a single, testable contract (e.g., valid cyclic packet accepted + applied); add minimum queue watermarks and a bounded recovery path (no stormy reopen loops).
Pass criteria: Timeout rate ≤ X per X hours; underrun/late counters remain ≤ X/hour; watchdog kicks show consistent source and cadence within ±X.
Explicit message bursts degrade cyclic I/O — shared queues or missing priority isolation?
Likely cause: Explicit and cyclic traffic share a lock/queue/buffer pool, or explicit processing runs at equal/higher priority, blocking cyclic deadlines.
Quick check: Compare per-queue depth and service latency during bursts; look for lock hold times that coincide with cyclic misses; verify explicit rate spikes in the same window.
Fix: Separate explicit/cyclic queues and memory pools; enforce explicit rate limiting and backpressure; pin cyclic processing to a deterministic budget and keep explicit work preemptible.
Pass criteria: Under explicit burst of X msg/s, cyclic deadline misses = 0 (or ≤ X per hour), and cyclic jitter stays ≤ X.
Works with one PLC but not another — align object dictionary version or EDS/instance mapping first?
Likely cause: The PLC expects a different Assembly instance/size or object attribute set, or the EDS/profile mapping does not match the shipped contract version.
Quick check: Diff the requested instances and sizes from both PLCs; verify Identity/TCPIP/EthernetLink basics and the exact Assembly contract version exposed by the device; confirm EDS matches those numbers.
Fix: Implement explicit versioning (major/minor) and backward-compatible Assembly evolution (add fields only at the end, preserve reserved bytes); ship correct EDS per version and reject incompatible opens with a clear diagnostic code.
Pass criteria: Interop smoke tests pass on X PLC families: identity read, explicit read/write of required attributes, and successful I/O open with correct Assembly sizes at RPI = X.
CIP Sync is stable in the lab but drifts in the field — timestamp tap point or queue-delay drift?
Likely cause: Timestamp is taken too far from hardware (adds variable software latency), or variable queueing under real traffic introduces delay drift that looks like time-domain drift.
Quick check: Report the active timestamp tap (MAC/driver/stack/app) and compare drift vs queue depth/CPU load; watch for step-like offset jumps aligned with bursts or task overruns.
Fix: Move the timestamp closer to hardware (or enable the hardware path), minimize variable queues on the time-critical path, and keep a single clock domain boundary with explicit state reporting (locked/holdover).
Pass criteria: Time offset stability within ±X over X minutes; offset step events ≤ X/hour; drift shows no correlation (|ρ| ≤ X) with queue depth in the field workload.
DLR switchover causes a brief I/O “twitch” — check reconnect backoff or switchover window behavior?
Likely cause: Device triggers aggressive reopen attempts (storm) during topology change, or cyclic I/O policy during switchover is undefined (freeze vs drop vs rebuild).
Quick check: Measure reconnect_rate, state_flap_count, and the time from link-path change to stable I/O; verify a single, deterministic switchover policy for I/O update and watchdog gating.
Fix: Add exponential backoff + hold-down to reopen; suppress broadcast storms; gate I/O enable until topology is stable and the connection state machine is in a defined “Run” state.
Pass criteria: Switchover time ≤ X ms; I/O drop ≤ X packets (or X ms gap); reconnect attempts ≤ X within X seconds; no state flapping after recovery.
Diagnostic counters don’t match packet captures — window definition mismatch or mixed-connection statistics?
Likely cause: Counters use a different time window/denominator than the capture, or statistics are aggregated across multiple connections/ports without a stable key.
Quick check: Print counter scope (per-connection vs global), window length, and reset behavior; export per-connection buckets keyed by connection_id plus interface, then align capture start/stop to the same window.
Fix: Standardize definitions (exact window + denominator) and expose per-connection counters; add “capture alignment markers” in logs to sync field reports with packet captures.
Pass criteria: With aligned windows, counter-to-capture delta ≤ X%; per-connection counters remain stable (no cross-talk) when X connections run concurrently.
After long uptime the connection becomes “fragile” — resource leak or reconnect storm trigger?
Likely cause: Connection lifecycle does not fully release resources on close/timeout, or a periodic disturbance triggers repeated reopen attempts that saturate CPU/buffers.
Quick check: Trend heap watermark, buffer pool free count, and connection occupancy over time; detect bursts in reconnect_rate and watchdog events clustered in short windows.
Fix: Make close/timeout idempotent and provably releasing resources; implement reopen backoff + cap attempts; add a “circuit breaker” state to avoid re-entering Open→Timeout loops indefinitely.
Pass criteria: Over X hours, free resources stay within ±X%; reconnect_rate ≤ X/minute; no monotonic growth in occupancy or heap watermark.
Packet loss increases at certain temperatures — CPU throttling/thermal protection or clock/time stability?
Likely cause: Thermal throttling reduces processing budget and expands scheduling latency, or the local time base/servo state degrades, amplifying timing-sensitive behavior.
Quick check: Log CPU frequency/throttle flags and cyclic task latency at the moment loss rises; compare loss vs queue depth and “clock locked/holdover” state (if exposed).
Fix: Restore deterministic budget (cooling, power limits, priority) and reduce work on the cyclic path; ensure time-domain hooks expose state and alarms so drift is not silent.
Pass criteria: Across temperature range X to X, drop/timeout ≤ X; cyclic jitter ≤ X; no throttle-induced latency excursions above X.
Unstable for the first 30 seconds after power-up — initialization ordering or enabling I/O before link/ready?
Likely cause: I/O is enabled before prerequisites are met (link stable, contract loaded, buffers ready), or startup tasks create contention that starves cyclic processing.
Quick check: Compare timestamps: link-up, contract ready, connection open, and “I/O enable”; track startup spikes in CPU load and queue depth that coincide with the unstable period.
Fix: Add a deterministic gate: enable I/O only after link is stable and all contract/resources are ready; defer non-critical initialization work; enforce a stable “Run” entry condition.
Pass criteria: From power-up, stable cyclic I/O within X seconds; no reopen loops; cyclic jitter ≤ X during the first X seconds.
“Low network utilization, but it feels jammed” — bursty explicit/multicast behavior or queue watermark?
Likely cause: Short, bursty traffic (explicit or multicast) causes queue spikes and deadline misses even if average bandwidth is low, or buffer watermarks are too small for worst-case bursts.
Quick check: Compare peak queue depth and service latency vs average utilization; look for burst markers (msg/s peaks) and multicast counters that coincide with cyclic late updates.
Fix: Enforce burst limits and isolate cyclic from explicit/multicast; raise buffer watermarks to match worst-case bursts; add admission control on explicit services that can starve cyclic.
Pass criteria: Peak queue depth ≤ X; drop ≤ X; cyclic late updates ≤ X/hour even when explicit peaks reach X msg/s.
