FSOE Written Test common mistakes
FSOE Written Test · Understand the traps and how to avoid them.
Treating the SIL of a safety function as a property of the sensor or valve alone, quoting a single 'SIL 3 device' as if it satisfied the function's requirement.
Vendor datasheets advertise device capability (e.g. SIL 3 capable per IEC 61508-2 route 1H) and candidates carry that number straight into the safety function claim, forgetting that the achieved SIL is a property of the whole subsystem/function including architecture constraints.
What to do instead
Always state the SIL against a named safety function and its defined architecture boundary. Separate device capability (from the certificate and its stated conditions of use) from achieved SIL computed for the subsystem, and check the architectural constraints (HFT, SFF, Type A/B) before claiming the target.
Computing PFDavg by simply summing or averaging per-channel failure rates without applying the architecture-specific formula (1oo1, 1oo2, 2oo3) or the proof-test interval.
Candidates memorise 'lambda times TI over two' for a single channel and then apply it unchanged to redundant architectures, or use MTTFd where PFDavg is required, because the formulas look interchangeable under time pressure.
What to do instead
Write the correct architecture formula (e.g. 1oo2 includes the common-cause beta factor and a different exponent on TI), keep units consistent (per hour), and sanity-check the order of magnitude against the target band. Show the formula used, not just the number.
Confusing the safety lifecycle phases in IEC 61508, for example placing hazard and risk analysis after the safety requirements allocation, or putting SIL determination in the E/E/PE system design phase.
The lifecycle is a sequence of phases with specific inputs and outputs; candidates learn the phase names as a list without the deliverable of each phase, so they map activities to phases by feel.
What to do instead
Memorise each phase by its output document: hazard and risk analysis produces the overall safety requirements; allocation produces the safety requirements allocation; the safety requirements specification is the input to design and realisation. Anchor every activity to the document it produces.
Answering hazard analysis questions by listing generic hazards ('electric shock', 'fire') instead of deriving hazardous events from a defined system boundary and operating modes.
Candidates default to checklist thinking rather than structured techniques, and skip the step of defining the system under analysis and its modes (start-up, normal, maintenance, shutdown), so the hazard list is untethered.
What to do instead
State the system boundary and operating modes first, then use a named technique (HAZOP guide words, FMEA failure modes, LOPA for initiating events) and trace each hazardous event to a cause and a consequence. Generic hazards without a cause-consequence chain score poorly.
Treating the LOPA independent protection layer credit as available when the layer shares a sensor, logic solver, or utility with the initiating cause.
Candidates award credit for any listed safeguard without testing independence, and forget that shared instrument air, power, or a common control system breaks independence.
What to do instead
Before awarding IPL credit, check independence, specificity, dependability, and auditability. Explicitly name the common cause that would defeat both the initiator and the layer; if they share it, the layer earns no credit.
Writing a safety requirements specification that states only the safety function ('close the valve on high pressure') without the SIL, response time, proof-test interval, and safe state definition.
Functional descriptions read naturally and candidates stop there, not realising the SRS must be verifiable and complete enough to design and test against.
What to do instead
For every safety function include: function description, required SIL, process safety time and response time budget, safe state definition, operating modes covered, proof-test interval, and demand mode. If any of these is missing, the requirement is not verifiable.
Claiming a software SIL from coding practices alone, or assuming a language choice (e.g. 'we used C, so SIL 3') establishes the integrity level.
Software integrity is set by the specified techniques and measures for the SIL in the standard's tables, plus the development process, not by the language or by testing effort.
What to do instead
Map the software requirement to the SIL, then select the required techniques and measures from the relevant tables (e.g. structured methods, defensive programming, static analysis, diverse monitoring) and show evidence each was applied. Software has no random failure rate; do not assign one.
Ignoring systematic capability and common-cause failure when assessing redundant architectures, concluding that 1oo2 hardware automatically reaches a higher SIL.
Redundancy feels like it must improve integrity, so candidates skip the beta factor and the systematic capability limits, and miss that both channels may share a design fault or a common utility.
What to do instead
State the systematic capability of each element and the beta factor assumed. Show that redundancy reduces random hardware failure probability but does not raise systematic capability; add diversity or segregation where common cause dominates.
Treating proof testing and maintenance as an after-the-fact activity, omitting proof-test coverage, test interval justification, and the effect of undetected failures from the design and verification answers.
Candidates focus on design and treat operations as a separate topic, forgetting that PFDavg depends on proof-test interval and diagnostic coverage, and that bypass/override management is part of functional safety management.
What to do instead
In design answers, state the assumed proof-test interval and diagnostic coverage and show they match the PFDavg calculation. In operations answers, cover proof-test procedure and coverage, bypass and override control, and management of change for any modification.
Citing a standard clause or SIL table from memory with the wrong number, or asserting that certification by a third party transfers legal responsibility for the safety function.
Candidates recall that certification exists and assume it is a blanket guarantee, and they guess clause numbers rather than reasoning from the principle, which the exam penalises.
What to do instead
Reason from the principle (certification provides evidence of conformity to the standard's requirements under stated conditions; the duty holder retains responsibility for the safety function and its use). If unsure of a clause number, describe the requirement rather than inventing a citation.