FSOE Written Test cheat sheet

Functional safety management (FSM) covers all planned activities needed to achieve and maintain functional safety: planning, competence, verification, assessment, and configuration management.

Safety lifecycle planning must define activities, responsibilities, and outputs for every phase; the plan is a controlled document reviewed at phase transitions.

Competence management requires documented evidence of training, experience, and role-specific skills for each person performing safety activities.

Independence levels for assessment: IEC 61508-1 Table 5 links assessor independence (I1-I3) to SIL and to whether the design is novel or previously proven.

Functional safety assessment (FSA) is a planned, independent review; its scope and independence must be defined during the safety planning phase.

Configuration management must identify the safety-related system version, its components, and the associated documentation at every lifecycle phase.

Functional safety audit checks that the FSM procedures are being followed; functional safety assessment judges whether functional safety objectives are met.

Safety culture indicators include documented accountability, a no-blame reporting route for safety anomalies, and traceable management-of-change decisions.

HAZOP uses guide words (no, more, less, as well as, part of, reverse, other than) applied to process parameters at defined nodes.

Risk graph (IEC 61508-5) parameters: consequence C, frequency/exposure F, avoidance probability P, demand rate W; output gives the required SIL target.

LOPA quantifies an initiating event frequency and multiplies by independent protection layer probabilities; the gap to the tolerable frequency sets the SIL.

Hazard analysis must cover reasonably foreseeable misuse, systematic failure modes, and failures caused by the EUC or its environment.

ALARP demonstration requires that risk be reduced until further reduction cost is grossly disproportionate to the benefit.

Risk is normally defined as a combination of the severity of harm and the probability of that harm occurring.

FMEA is bottom-up component-level analysis; FTA is top-down and derives cut sets that show how a top event can occur.

Hazard log entries must record the hazard, causes, consequences, risk estimate, risk reduction measures, and closure evidence.

Risk reduction follows the hierarchy: inherently safe design, engineered safeguards (including safety functions), then information for use.

Required risk reduction: RRR = initial risk / tolerable risk; the safety function must reduce risk by at least this factor.

IEC 61508-5 allocation: RRF = 1 / (1 - PFDavg) for low demand, and PFH for high demand or continuous mode.

SIL 1 to SIL 4 correspond to PFDavg bands: 1e-2 to 1e-1, 1e-3 to 1e-2, 1e-4 to 1e-3, 1e-5 to 1e-4 (IEC 61508-1 Table 2).

High-demand PFH bands per hour: SIL 1 1e-6 to 1e-5, SIL 2 1e-7 to 1e-6, SIL 3 1e-8 to 1e-7, SIL 4 1e-9 to 1e-8.

External risk reduction facilities (non-safety-related) may be credited only if their independence and reliability are demonstrated.

Residual risk after all protection layers must be documented and communicated to the user in information for use.

Safety functions must be credited only once per hazard cause unless independence between credited layers is demonstrated.

The functional safety concept derives safety functions and their SIL targets from the hazard and risk analysis, before the technical safety concept.

The safety requirements specification (SRS) must be precise, unambiguous, testable, and traceable to the hazard log and to verification results.

SRS content includes safety function behaviour, safe state, response time, SIL, operating modes, and demand rate (low or high).

The safe state definition must state what happens on detected fault, on loss of power, and on demand, including hold-last-value or trip decisions.

Process safety time is the interval within which the safety function must act to prevent the hazard; the SRS response time must be shorter than it.

Allocation to subsystems must preserve the safety integrity of the parent function; a subsystem may be allocated a higher SIL than the parent.

Requirements must specify demand mode, proof test interval assumptions, and constraints on the EUC that the safety function depends on.

Traceability must link hazard to safety requirement to design element to verification evidence in both directions.

SIL is a target measure of safety integrity, not a property of a single component; it applies to the safety function allocated to a system.

Low demand mode: demand rate no more than once per year and no more than twice the proof test frequency.

High demand or continuous mode applies when demand frequency exceeds once per year or twice the proof test frequency.

SIL 4 is normally only claimed for continuous-mode functions; low-demand SIL 4 is rarely justifiable in process applications.

Systematic capability (SC 1-4) per IEC 61508-4 limits the maximum SIL a subsystem can claim, independent of its random failure rate.

Route 1H uses hardware fault tolerance and safe failure fraction; Route 2H uses component reliability data and proof tests.

Architectural constraints: HFT and SFF give maximum SIL per IEC 61508-2 Table 2 and Table 3.

PFDavg for a 1oo1 element under proof test T: approximately λDU × T / 2 for the dangerous undetected failure rate.

λDU = λD × (1 - DC); λDD = λD × DC, where DC is diagnostic coverage for dangerous failures.

PFDavg 1oo1 = λDU × T1 / 2; 1oo2 ≈ (λDU × T1)^2 / 3 plus common cause contribution.

Common cause failure is modelled with beta factor: PFD_CCF ≈ β × λDU × T1 / 2 for a redundant group.

Safe failure fraction SFF = (λS + λDD) / λtotal; it drives the architectural constraint tables.

Proof test coverage is the fraction of dangerous undetected failures revealed by the proof test; partial proof tests may be used with care.

MTTFd = 1 / λtotal; MTTR affects availability but not PFDavg directly in low-demand calculations.

Diagnostic coverage must be justified by a diagnostic coverage analysis, not assumed from a vendor claim.

Hardware fault tolerance of N means N+1 failures are needed before the safety function is lost.

IEC 61508-3 defines software safety lifecycle phases: SR specification, architecture design, unit design, coding, integration, verification, and validation.

Software is treated as systematic; SIL claims rely on techniques and measures (Table A.1-A.18), not on failure rate calculations.

Software SIL 3 and 4 typically require formal or semi-formal methods, structured methods, and strong verification independence.

Techniques per SIL are specified as highly recommended (HR), recommended (R), or not recommended (NR) in IEC 61508-3 Annex A and B.

Coding standards must be defined and enforced; static analysis and code review evidence must be recorded.

Software configuration management must cover source, object code, tools, and test data with unique version identification.

Pre-existing software may be used only if its suitability is assessed and it is verified for the target SIL.

Software safety validation must demonstrate that the integrated system meets the SRS in its intended application.

Architecture must be defined before detailed design; it must show subsystems, interfaces, redundancy, and diagnostics.

Verification confirms each phase output meets its input requirements; validation confirms the finished system meets the user's needs.

Independence of verification increases with SIL: IEC 61508-1 Table 5 gives the required independence for each SIL.

Fault reaction time must be less than the process safety time minus the actuator and sensor response times.

Interface analysis must cover all safety-related interfaces, including human-machine interfaces and communication links.

Communication between safety functions must have a defined integrity; black channel assumptions must be justified.

System integration testing must exercise the safety functions, including detected fault reactions and safe-state transitions.

Verification evidence must be traceable to the SRS requirement it verifies.

Operation and maintenance planning must define proof test procedures, intervals, and acceptance criteria.

Proof test intervals must be consistent with the PFDavg calculation; changing the interval changes the achieved SIL.

Any modification must be assessed for impact on functional safety; the safety lifecycle phases are re-entered as needed.

Decommissioning must include a plan for safe removal, disposal, and communication of residual risks.

Operational procedures must define response to detected faults, including bypass management and compensating measures.

Bypass and override management must be controlled, time-limited, and recorded with authorisation.

Periodic functional safety audits during operation confirm that the FSM remains effective.

Maintenance records must be retained and used to update reliability data and proof test effectiveness.

IEC 61508 is the generic functional safety standard; sector standards include IEC 61511 (process), ISO 26262 (automotive), and EN 50128/50129 (rail).

IEC 61511 applies to process industry safety instrumented systems; it uses SIL 1-4 and the safety lifecycle model.

Certification of a device to IEC 61508 typically covers the hardware and software safety lifecycle and states the achieved SIL and SC.

A certificate is valid only within its stated scope, environment, and configuration; deviations require reassessment.

IEC 61511 requires the SIL verification to be based on the actual architecture, proof test interval, and site-specific data.

Prior use justification under IEC 61511 requires documented operating history and a defined set of operating conditions.

The safety manual supplied with a certified device contains the assumptions and constraints needed for its correct use.

Functional safety assessment independence requirements differ by standard; IEC 61511 Annex A defines the assessment levels.