Domain 4: FSoE state machine and communication phases
Domain 4 tests the FSoE connection lifecycle and the fail-safe reaction. You should know the order of phases, what is negotiated in each, and how a device leaves the Data phase when communication fails.
Core rules
- Session phase: the master starts communication with the slave and establishes the basic session context. The slave responds; it does not independently open a safety connection.
- Connection phase: the connection identifier is established or confirmed, binding the frame flow to the intended FSoE connection.
- Parameter phase: configuration is exchanged or validated, including watchdog time, mapping, and connection-specific parameters. Data phase must not begin until parameters are accepted.
- Data phase: cyclic safe data exchange with sequence monitoring and CRC checks. This is the only phase in which safety outputs are updated from process data.
- Fail-safe reaction: on watchdog expiry, CRC/sequence error, connection loss, or invalid state transition, the slave forces its safe outputs to the safe state and reports the error. Recovery normally requires a reset and re-establishment, not an automatic jump back to Data.
Worked example
A master sets a 20 ms watchdog. The slave enters Session, then Connection with ID 0x0102, then Parameter, where the mapping and 20 ms watchdog are accepted. In Data, frames arrive every 4 ms with sequence numbers 0,1,2... If frames stop at sequence 7, the slave waits 20 ms, sees no valid Data frame, declares a watchdog error, and de-energizes outputs. When the network returns, the master must re-run the connection and parameter phases; the slave does not resume outputs merely because a Data frame appears.
Traps
Thinking Data phase can start before parameters are validated. Treating a single valid Data frame after a fault as proof of recovery. Assuming the master alone handles fail-safe reaction. Forgetting that a state-machine error is itself a safe-relevant fault.