Domain 7: Diagnostics, fault tracing and conformance testing
Domain 7 tests diagnosis and evidence: how to trace FSoE faults and what conformance testing does and does not prove. Expect questions on error codes, EtherCAT versus FSoE diagnostics, and fault-injection tests.
Core rules
- Start at the physical and EtherCAT layers: link status, working counter, cycle jitter, AL status, and DC synchronization. A healthy FSoE state machine cannot compensate for a broken black channel.
- FSoE diagnostics include state, connection ID, watchdog/CRC/sequence errors, parameter errors, and slave error codes. Read both master and slave diagnostics; the master may report a timeout while the slave reports a CRC or sequence fault.
- Fault tracing: reproduce with logging, compare configured FSoE address and mapping, check watchdog margin, then inject the suspected fault (disconnect, duplicate frame, corrupt byte, delay) and observe the fail-safe reaction.
- Conformance testing: ETG/IEC 61784-3-12 conformance checks frame format, state machine, CRC, watchdog, and error handling. A certificate supports interoperability and profile compliance; it does not by itself prove the installed safety function's SIL/PL.
- Keep test evidence: configuration, firmware versions, error logs, and pass/fail results.
Worked example
A machine trips intermittently on one remote I/O. The FSoE master log shows watchdog errors; the slave log shows no CRC errors. EtherCAT working counters are clean, but cycle jitter peaks at 18 ms against a 20 ms watchdog. The reasoning: frames are not corrupt, they are late. Fix the jitter source or increase the watchdog only after confirming the process safety time still allows it. Then repeat a delay-injection test to prove the fail-safe response.
Traps
Reading only the master diagnostics. Treating a conformance certificate as validation of the machine's safety function. Increasing the watchdog without a safety assessment. Ignoring EtherCAT jitter and blaming FSoE CRC.