FSOE Qualifying Test key terms

The part of overall safety that depends on a system reacting correctly to its inputs, so that hazards caused by failures of electrical, electronic or programmable electronic equipment do not lead to unreasonable risk.

A function that a machine or plant must perform to keep risk acceptable, for example stopping a drive safely when a guard is opened; it is defined by its input, logic and safe output reaction.

A discrete level, one to four, defined in IEC 61508 that expresses how much risk reduction a safety function must achieve; higher levels demand lower failure probability and stronger systematic measures.

A discrete level, a to e, defined in ISO 13849 for machine safety functions; it is derived from category, MTTFd and diagnostic coverage and expresses the same idea as SIL in a different way.

The average probability that a safety function fails dangerously within one hour of operation; it is the core reliability figure used to verify SIL for high-demand or continuous-demand operation.

The share of dangerous failures in a subsystem that is detected by diagnostic measures, expressed as a percentage; higher coverage allows a lower hardware fault tolerance for the same SIL or PL.

The standard that defines functional safety fieldbus communication profiles; it specifies the generic layer model, the black channel assumption and the measures used by protocols such as FSoE, PROFIsafe and CIP Safety.

A condition of the machine or process in which the risk is considered acceptable; for a drive this is usually a safely removed torque, and safety functions must bring the system there on demand or failure.

A periodic test performed on a safety system to reveal dangerous failures that diagnostic measures cannot detect, thereby restoring the assumed failure probability used in the SIL or PL calculation.

The principle that safety communication may run over standard, non-safety networks and devices; the safety layer itself provides fault detection, so the channel need not be certified, only its residual error rate must be bounded.

Safety over EtherCAT, the safety communication layer defined in IEC 61784-3 and ETG specifications; it carries safe process data in standard EtherCAT frames and lets a safety controller exchange safe inputs and outputs with safe slaves.

The safety controller role in FSoE: it opens and monitors the safe connection, sends safe outputs, validates received safe inputs, and forces the connection into the fail-safe state when errors are detected.

The field device role in FSoE: it receives safe outputs, returns safe inputs, checks command, connection identifier, sequence and CRC, and applies its configured safe reaction when communication fails.

The firmware or library implementation of the FSoE protocol inside a device; it sits between the application with its safe inputs and outputs and the standard EtherCAT communication interface.

The unit of safe data exchanged by FSoE: a command field, the safe data container and a sixteen-bit CRC, transported inside the process data of a standard EtherCAT telegram.

The part of the FSoE frame that carries the actual safe process values, such as safe inputs and safe outputs; its length and mapping are configured and known to both ends.

The leading field of the FSoE frame that carries the command code telling the receiver which communication phase is intended, for instance reset, session, connection, parameter, data or error.

A code carried in the FSoE frame that identifies the safe connection between master and slave; the receiver compares it with its configured FSoE address and rejects frames that do not match.

A checksum calculated over the FSoE command and safe data and appended to the frame; the receiver recalculates it and discards any frame whose value differs, catching corruption on the black channel.

The defined sequence of communication states that a safe connection passes through, from reset through session and parameter exchange to data exchange, plus an error path leading to the fail-safe reaction.

The FSoE phase in which master and slave establish which connection they belong to and check that the configured identification matches before moving on to parameter and data phases.

The FSoE phase in which safe process data is exchanged cyclically; the receiver monitors sequence numbers, CRC and timing, and leaves this state on any detected fault.

The predefined response of a device when FSoE communication fails or an error is detected: safe outputs are switched off, safe inputs are reported as invalid, and the application is informed through diagnostics.

A counter carried in each FSoE frame that increments per valid exchange; the receiver checks that consecutive frames carry consecutive values, so lost, repeated, reordered or inserted frames are detected.

Supervision that a valid FSoE frame arrives within an agreed time; if it does not, the connection is treated as failed and the device performs its fail-safe reaction.

Verification that a received FSoE frame belongs to the intended safe connection, done by comparing the connection identifier in the frame with the configured FSoE address of the device.

The probability that a corrupted or otherwise faulty FSoE frame is accepted as valid despite all safety measures; standards require it to be low enough for the targeted SIL.

A configured number, unique within the network, that names the safe connection of a slave; the master uses it to address the connection and the slave uses it to validate incoming frames.

The configured maximum interval within which a valid FSoE frame must arrive; the device's watchdog expires when communication stops and triggers the fail-safe reaction.

The FSoE capability for safe slaves to exchange safe data directly with each other, without routing the values through the safety master, used for fast local interlocks.

The configuration that assigns safe inputs and outputs of a device to specific bits or words inside the FSoE safe data container, so both ends interpret the same data consistently.

A code transmitted in the error command of FSoE when a device detects a fault, telling the peer and the engineering tool what kind of failure occurred for diagnosis.

A test performed by an accredited test lab against the FSoE specification and ETG test package, checking protocol behaviour, timing, error reactions and interoperability before a device may carry the conformance mark.

The log of FSoE errors and state transitions kept in a device or engineering tool, used to trace intermittent faults, identify the failing node and confirm that no fault was left unrepaired.

The systematic process that identifies hazards, estimates their severity and likelihood, and defines the required risk reduction; its output sets the safety functions and the target SIL or PL.

The document that states what each safety function must do, its target SIL or PL, its response time, its operating modes and the tests needed to prove it works.

Checking, by analysis or test, that the implementation meets the safety requirements specification at each stage; it asks whether the system was built right, not whether the right system was built.

Testing the finished safety function against the real machine or process to confirm it achieves the required risk reduction in all operating modes, including the expected fail-safe reactions.