To navigate our frequently asked questions page, please click on the main topic and further subtopics will open, or use the search function.
IEC61511-1:2016, § 3.2.24 defines FSA as: investigation, based on evidence, to judge the functional safety achieved by one or more SIS and/or other protection layers.
FSA should be led by a qualified independent assessor and shall result in a statement that functional safety is achieved for the corresponding SLC-stage. FSA focuses on technical aspects and achieved results in addition to procedures and paperwork (see FS-Audit). Five FSA-stages are defined in IEC 61511-1 Figure 7, of which FSA-3 and FSA-4 are compulsory.
IEC61511-1:2016, § 3.2.25 defines functional safety audit as: systematic and independent examination to determine whether the procedures specific to the functional safety requirements comply with the planned arrangements, are implemented effectively and are suitable to achieve the specified objectives. Note: A functional safety audit may be carried out as part of a FSA.
The purpose of FS-Audit is to determine if functional safety procedures are being properly applied during project execution (think of it as an ISO-9001 audit for functional safety). The audit aims to identify potential systematic failures in the implementation of FS tasks and activities. In contrast to FSA, audit does not give a statement as to whether the required level of functional safety has been achieved; it only confirms that the correct procedures are being implemented as a prerequisite.
IEC61511-1:2016, § 3.2.87 defines functional safety verification as: confirmation by examination and provision of objective evidence that the requirements have been fulfilled.
Verification activities take place throughout the SLC to ensure systematic integrity. They consist of checking, review, inspection or testing activities as part of the normal engineering/construction/O&M quality process, however, with focus on functional safety. Verification activities are defined in the Project Functional Safety Plan (PFSP), including inputs, outputs, verification responsibility and timing.
IEC61511-1:2016, § 3.2.86 defines functional safety validation as: confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled. …this means demonstrating that the SIF(s) and SIS after installation meet the SRS in all respects.
Validation takes place after commissioning and is often seen interchangeably with the Site Acceptance Test (SAT), i.e. it confirms that installed SIF/SIS are working correctly in line with the SRS. Note: FSA-3 goes a step further and confirms that the requirements themselves are complete, consistent and sufficient to achieve the intended level of safety.
IEC 61511 defines Random Failure as „occurring at a random time, which results from one or more … degradation mechanisms in the hardware.“ Such failures occur at predictable rates (see bathtub curve) but at unpredictable (i.e., random) times. Systematic Failures are those „related to a pre-existing fault … which can only be eliminated by … a modification of the design, manufacturing process, operating procedures, documentation or other relevant factors”. Random failures are often defined as ‚hardware-related‘, whereas systematic failures are ‚due to human error‘. A systematic failure can be eliminated after being detected, while random hardware failures cannot. Implementation of a Functional Safety Management System shall minimise systematic failures.
Examples of random failure are:
- Aging or stress failure of electronic components including:
- Contact failure, soldered joint failure
- PCB/semi-conductor failure
- Relay stiction
- Resistor/capacitor degradation
Examples of systematic failure are:
- Errors during the Analysis phase of the SLC (HAZOP, SIL-Analysis, SRS) – see UK HSE “Out of Control: Why control systems go wrong and how to prevent failure”
- Software „bugs“
- Overlooking common cause failure
- O&M mistakes (SIF bypass, incorrect calibration, etc)