Functional Safety Insights by Kamran Mojtehedi

HAZOP Preparation – Critical Technical Steps Often Missed:
Based on practical project experience, many issues attributed to “poor HAZOP quality” do not originate during the HAZOP sessions themselves.
They arise before the first workshop even begins, due to gaps in preparation and methodology.
The following critical steps are still frequently missed:
HAZOP Template Validation
The HAZOP worksheet or template must be proven and suitable for the specific application, considering process type, system complexity, and regulatory expectations.
Generic templates often introduce blind spots in hazard identification, safeguard recognition, and recommendation quality.
Parameters and Guidewords – Finalize Before the Sessions
Process parameters and guidewords must be clearly defined, discussed, and agreed prior to starting the HAZOP.
Late changes during workshops undermine consistency, traceability, and the validity of identified deviations and safeguards.
Node Definition
Nodes must be clearly defined with finalized and agreed boundaries, supported by up-to-date P&IDs.
Poor node definition frequently results in duplicated discussions, inefficient sessions, or missed hazards.
Inclusion of External Events
External events—such as utility failures, loss of instrument air, and total or partial power failures—must be explicitly included in the HAZOP scope, not assumed.
Omitting these scenarios can leave significant risk contributors unaddressed.
Operating Modes Are Not Optional
All relevant operating modes must be considered, including start-up, shutdown, maintenance, abnormal, and emergency conditions.
Many major incidents occur outside normal steady-state operation, yet these modes are still underestimated in many HAZOP studies.
A well-executed HAZOP is not defined by facilitation skills alone.
It depends on rigorous preparation, an agreed methodology, disciplined scope definition, and technical completeness.e your paragraph here.

Independence in Functional Safety Assessments (FSA) — What does it really mean?
In the IEC 61511 world, we often state that FSAs must be independent.
But in practice, this raises important questions:
What does independence mean to you?
• Independent of the project team?
• Not involved in project design/verification
• Not reporting to the same project manager, director, or company owner?
• Free from schedule, cost, or production pressures?
And what about the level of independence?
• Independent person
• Independent team within the same organization?
• Or a completely separate organization (third party)?
IEC 61511 requires independence—
From experience, independence is not just about organizational structure.
It is about:
• The ability to question and challenge without pressure
• The competence and confidence to identify gaps
• The authority to escalate findings, even if it impacts the schedule or cost
• And, of course, having fresh eyes that have not been involved in the project
Especially in FSA-3, where site verification and testing are involved,
True independence can directly impact whether a system is ready for safe operation—or not.
So the real question is:
Is your FSA truly independent in practice—or only on paper?
I would be interested to hear how others define and implement independence in FSAs.
#FunctionalSafety #IEC61511 #FSA #ProcessSafety #SIS #Engineering

Functional Safety Assessor Independence – Why It Matters (IEC 61511, Process Sector)
IEC 61511 requires competence and adequate independence for Functional Safety Assessments (FSA).
In my opinion, the key benefits of an independent assessor are:
Independence is not only technical — it is also organizational:
• Not involved in project design, verification, or implementation
• Not reporting to the same project manager, line manager, or director
• Free to challenge design decisions and prevent unsafe shortcuts
This independence adds real value by:
• Providing objective challenge to SIS design, IPL assumptions, and testing practices
• Increasing credibility with regulators, insurers, and auditors
• Offering stronger protection for the company’s Functional Safety department
In the process sector, where consequences are high,
independence directly supports real functional safety — not just compliance.

Should a HAZOP Facilitator Understand LOPA?

The answer is yes.
LOPA relies heavily on the information generated during the HAZOP study, including identified scenarios, causes, consequences, and existing safeguards.
Therefore, an effective HAZOP facilitator should understand how HAZOP results are used in subsequent risk analysis, such as LOPA.

A facilitator should also have a working understanding of:
• Risk assessment methodologies
• Protection layers and safeguards
• Human reliability considerations
• Key functional safety concepts

This broader understanding helps ensure that HAZOP discussions capture the correct scenarios and safeguards that may later be evaluated in LOPA.

We often talk about Proof Test Procedures, Proof Test Interval (PTI), and Proof Test Coverage (PTC) in Functional Safety.
But what about Inspection?
Inspection is not optional—it is required by IEC 61511.
Yet in practice, it is often overlooked or not formally defined.
Let’s be clear:
• Proof Testing → Detects dangerous undetected failures (DU)
• Inspection → Identifies degradation before failure occurs
Reality in the field:
• Corrosion, vibration, air supply issues
• Impulse line plugging, wiring degradation
• Control panel temperature, humidity, dust
I have personally seen steam leakage directly impinging on a DP transmitter capillary tube—this is not theoretical.
So key questions:
• Is inspection included in your proof test procedure?
• Or defined as a separate routine with clear frequency and scope?
• Or simply assumed to be “covered by operations”?
In my view, inspection should be:
• Risk-based
• As frequent as—or more frequent than—proof testing
• Focused on real failure mechanisms (not generic checklists)
• Clearly defined: what needs to be inspected, how, and how often
That is where the real gap exists.
#FunctionalSafety #IEC61511 #SIS #ProcessSafety #Maintenance #Reliability

Functional Safety Insights by Kamran Mojtehedi

There has been a lot of discussion lately about “Prior Use Justification” vs. “Certified Instruments” for Safety Instrumented Systems (SIS).
When I raise questions about how prior-use data is actually gathered, my intention is sometimes misunderstood as supporting only certified instruments. That is not the case.
In my view, the real issue is the quality and relevance of the data used for the justification.
For example, when we say an instrument has been “working successfully for many years in the same process application”, what exactly does that mean?
Some questions that are worth asking:
• How reliable is the failure recording system?
Are dangerous failures systematically captured and classified?
• Were the relevant failure modes actually observable?
If the device rarely experienced demands or shutdown conditions, how do we know dangerous failures would have been detected?

•Was the instrument operating under conditions that are truly comparable to SIS requirements?
Even if the operating profile and process conditions were similar, an important question remains: were real shutdown demands experienced and recorded?
We know that instruments used in control applications may sometimes be justified for prior use. However, an SIS is fundamentally different. It is typically a static protection layer, where demands may be rare, unlike control loops which operate continuously and dynamically.
From a measurement perspective, the instrument may appear suitable. But from a reliability and failure detection perspective, how do we ensure that dangerous failure modes would actually have been revealed?

This is an important consideration when evaluating prior-use justification.
• What was the proof-test strategy and coverage?
If proof tests were performed, did they have sufficient coverage to reveal dangerous undetected failures?
In some discussions, the statement “the instrument has been working for 10–15 years without issues” is used as evidence. But that raises an important question:
Does this mean the instrument successfully responded to many real demands?
Or does it simply mean no demand occurred and failures remained hidden?
Prior use can be a valid approach under IEC 61511 / IEC 61508(proven in use) but the justification must be supported by credible, traceable, and application-relevant failure data.
The debate should not be “certified vs prior use.”
The real focus should be data quality, failure detection, and evidence.
I would be interested to hear how others address these challenges when relying on prior-use justification.

hashtag#FunctionalSafety hashtag#IEC61511 hashtag#SIS hashtag#ProcessSafety hashtag#SafetyInstrumentedSystems hashtag#LOPA

Why Loop / Wiring Diagrams Are Critical for Functional Safety
One of the most important source documents for SIL calculation, SIF response time calculation, and proof-test procedures is the loop wiring diagram.
Why?
Because the loop wiring diagram is the place where most of the devices that form a SIF are represented and clearly identified.
It shows the wired and signal path portions of the loop, including instrumentation and associated components.
(Items such as impulse lines and final elements like valves and actuators are typically covered in other drawings.
The loop wiring diagram allows you to clearly identify most of component that contributes to the Safety Instrumented Function, including:
• Sensors and transmitters
• Signal conditioning, barriers, and isolators
• Logic solver
• Relays and solenoids
Any device whose dangerous failure can prevent the SIF from bringing the process to its defined safe state must be included.
Therefore, the loop wiring diagram is a key input for:
• SIL calculations
• Proof-test procedures
• SIF response time calculation
If a component is part of the loop but excluded from:
• SIL calculations
• Proof-test procedures
• Response time verification
— then the functional safety goal and integrity target is not achieved.
This is why Functional Safety Assessments shall include this type of detailed loop-level review.
Anything that contributes to the SIF belongs in the analysis, the calculations, and the proof test.

If you need to calculate Proof Test Coverage (PTC), one of the most reliable approaches is the FMEDA method.
FMEDA (Failure Modes, Effects, and Diagnostic Analysis) is a systematic technique used to evaluate how device failures impact safety—and how effectively those failures are detected.
In the context of PTC, FMEDA answers a critical question:
What percentage of dangerous failures can actually be detected during proof testing?
How FMEDA supports PTC calculation:
• Identifies all possible failure modes of a device
• Classifies failures into:
– Safe failures
– Dangerous detected (DD)
– Dangerous undetected (DU)
• Quantifies failure rates (λ) for each category
• Evaluates which dangerous undetected failures can be revealed by a proof test
PTC is then derived as:
PTC = (Dangerous failures detected by proof test) / (Total dangerous undetected failures)
Why FMEDA is powerful:
• Provides a data-driven, quantitative basis (not assumptions)
• Aligns with IEC 61508 / IEC 61511 expectations
• Ensures proof test procedures are realistic and effective—not just theoretical
Important reminder:
If your assumed PTC in SIL verification is not achievable in practice, your risk reduction claim is not valid.

Not all IPLs are equal—especially when it comes to SIF demand rate and SIF mode of operation.

In LOPA, multiple IPLs may be valid and credited for risk reduction. However, not every credited valid IPL should be used in calculating the SIF demand rate.

Why this matters: • Demand rate must reflect actual challenges to the SIF.

Only IPLs that complete the action before the SIF triggers and can prevent the demand should be considered in reducing demand frequency. • If IPL completes the action after the SIF demand is already initiated, then these IPLs should not be in the SIF demand rate calculation. • Mode of operation (low vs. high demand). Incorrectly including all IPLs in demand rate calculations can artificially lower the demand frequency, leading to incorrect classification of SIF mode. Be selective and technically justified when using IPLs in SIF demand rate calculations—not all valid IPLs belong in this step.

A Functional Safety Insight – ESP Explosion Scenario
Consider the following hazardous scenario in a process unit:
An Electrostatic Precipitator (ESP) is installed to remove particulate matter from a gas stream. The ESP operates with high-voltage charged plates that attract particles as the gas flows through the unit.
Now consider this deviation:
Due to a failure in an upstream unit, methane (CH₄) may enter the gas stream. Since methane is combustible, if a combustible mixture reaches the ESP, the presence of high voltage and electrostatic energy may create an explosion hazard.
A typical protection approach could be a Safety Instrumented Function (SIF):
Sensor: CH₄ analyzer
Logic solver: Safety PLC
Final element: De-energize and disconnect power to the ESP
However, this raises an important technical question:
Even if the high-voltage power supply is disconnected, do the ESP plates still retain sufficient stored electrical energy to remain a potential ignition source?
Since the ESP plates can behave like capacitive elements, simply removing power may not immediately eliminate the hazard. Residual charge and discharge energy must be considered carefully.
So the question becomes:
Is disconnecting the high-voltage supply alone sufficient to eliminate the ignition risk?
In such a case, the design may also need to consider additional protective measures, such as:
• Controlled plate discharge systems
• Purge or inerting
• Fast isolation or diversion of the combustible gas stream
• Verification of residual energy decay time before restart or continued operation
This is a good reminder that in Functional Safety, it is not enough to define a trip action. We must also confirm that the action truly removes the hazard within the required time and under realistic physical conditions.
I will share some interesting points regarding PST (Process Safety Time) and SIF response time for this scenario in future posts.
hashtag#FunctionalSafety hashtag#IEC61511 hashtag#SIS hashtag#ProcessSafety hashtag#HAZOP hashtag#LOPA hashtag#ESP hashtag#ExplosionHazard hashtag#Methane hashtag#ElectrostaticPrecipitator

Proof Test Procedure — What About the Logic , and Logic Solver?
Should logic be included and tested every time as part of a proof test procedure?
This is a question I often raise during discussions, and I prefer to frame it through a few practical considerations:
• Do you have a robust Management of Change (MOC) process in place—and are you confident it is consistently and properly implemented?
• If logic is not included in the proof test procedure, are you missing critical panel-level inspections such as:
– Cabinet temperature
– Humidity
– Fan failure alarms
- Dust
…
• If logic is not included in the proof test procedure, what about the logic solver itself?
Some systems require a power cycle to execute full diagnostics. If this is not part of your strategy, what failures remain undetected?
• If logic is excluded, how are you testing the system?
– Are sensors and final elements tested completely in isolation?
– Or do you ensure overlap testing (as recommended in good engineering practice)?
My view:
Proof testing is not just about checking individual components.
It is about to detect dangerous undetected failures in the SIF —end to end.
Excluding logic without a clear and justified strategy can leave gaps in detecting dangerous failures.
Curious to hear how others approach this—
Do you include logic solver testing in every proof test cycle, or do you manage it differently?
#Functionalsafety #IEC61511 #SIS #ProofTesting #ProcessSafety #LOPA #Engineering

Connect with Kamran Mojtehedi – Functional Safety Expert (LinkedIn)

Let’s begin with a fundamental point:
Proof testing is NOT FAT.
Proof testing is NOT SAT.
Proof testing is specifically intended to detect dangerous undetected failures in devices that are part of a SIF.
If this objective is not achieved, the claimed risk reduction (PFDavg) is simply not valid.
So, what are the key source documents for developing a proper Proof Test Procedure?
• SIL Verification / Calculation
Provides critical assumptions such as:
– Proof Test Interval (PTI)
– Proof Test Coverage (PTC)
These are not just numbers—they must be achievable in practice and aligned with the safety manual.
• Safety Requirements Specification (SRS)
Defines:
– Logic relationships between inputs and outputs
– Functional behavior of the SIF
…and more
• Manufacturer Safety Manuals
– Provide recommended proof test steps
– Must align with the assumed PTC used in SIL verification
Particularly important for: analyzers, safety relays, trip amplifiers (monitor switches), etc.
And one of the most critical—yet often missed:
• Loop Wiring Diagrams
This is where reality exists.
Loop diagrams identify the actual devices, components, and interfaces in the SIF—often beyond what is captured in the SRS.
Examples include:
– Intrinsically safe barriers
– Smart MCC components (from electrical drawings)
– Interposing relays
– Hidden interfaces and dependencies
Key principle:
Every device, component, or element that contributes to the SIF—and whose dangerous failure can prevent the SIF from operating—must be included in the proof test procedure.
Missing even one element can invalidate the assumed risk reduction.
This is where many designs fail—not on paper, but in execution.

Why must FSAs account for hazardous area classification, EMI/RFI, and operating environment?
Because Functional Safety does NOT exist in isolation from the operating environment.
A Safety Instrumented Function (SIF) is only as good as the real-world performance of its devices—sensors, logic solvers, and final elements.
If a device:
·      Cannot measure correctly, or
·      Cannot function reliably under actual site conditions,
then Functional safety , SIL, PFDavg, and calculations become meaningless.
That is exactly why IEC 61511 explicitly requires consideration of operating environment, including:
·      Hazardous area classification
·      Ambient temperature extremes
·      Pressure, vibration, corrosive or dusty atmospheres
·      EMI / RFI and electrical interference
·      Utilities quality (power, air, hydraulics),
.....
IEC 61511 (Ed.2) clearly states that operating environment conditions inherent to the installation can affect device functionality and safety integrity.
Bottom line:
✔ SIS and credited IPL devices must be correctly selected,
✔ properly rated for area classification,
✔ installed within manufacturer limits, and
✔ capable of reliable operation under actual process and environmental conditions.
Otherwise, functional safety and reliability are just assumptions—not protection.
This is exactly why FSA Stage 3 must go beyond documents and calculations and verify real installation, environment, and device suitability.
IEC61511 , clause 10.3.2,...

Hydrogen Electrolyzers: Functional Safety Must Be Engineered In — Not Added Later
Hydrogen electrolyzers operate with high energy density, high pressures, and wide flammability ranges.
That means functional safety is not optional — it is fundamental.
From my experience working on electrolyzer projects, real safety depends on more than documents and SIL numbers. It requires:
• Correct hazard identification (HAZOP / What-If)
• Clear SIF definition tied to specific hydrogen hazards
• Proper independence between BPCS and SIS
• Verified sensors, final elements, and logic suitable for hydrogen service
• FSA involvement early — not only at the end of the project
Finding gaps at FSA Stage 3 or later is often too late and too costly.
Hydrogen projects succeed when process design, controls, and functional safety are engineered together — not treated as checkboxes.
Real functional safety protects people, assets, and project credibility.

One recurring gap I still see during FSA Stages is a disconnect between process engineering and SIS engineering when calculating SIF response time.
In many projects, the SIF response time is calculated correctly from the SIS perspective:
• Sensor response time
• Logic solver scan time
• Configured delay time
• Final element, for example (valve) stroke time
However, process lag (if any)is often missing from the equation.
Process lag is not an SIS parameter—it belongs to process engineering—but it directly affects whether the SIF can bring the process to a safe state before the hazardous consequence occurs.
A SIF may meet its calculated response time , yet still fail to prevent the hazard if process dynamics are not considered.
There are other disconnects observed during FSA as well. I’ll try to share them here when time allows.

Deep Technical Insight – Solenoid Valve (SOV) on Control Valves as an Additional Protection Layer
Have you ever used a solenoid valve (SOV) on a control valve as an additional protection layer?
Let me be clear —
This is not a discussion about BPCS IPLs or SIS SIFs.
This is about a design practice that is sometimes implemented, but not always fully understood.
Let’s break it down:
1- Location Matters – Where is the SOV Installed?
The SOV is installed between the positioner output and the actuator.
The correct location for installing the SOV is:
Between the positioner output and the actuator
Why this is important:
In this configuration, the SOV can directly vent the actuator air through its vent port
This enables a fast and deterministic movement to the safe position (fail-close or fail-open)
It effectively bypasses the positioner, eliminating its influence during a trip condition
If it is not configured this way, then you must explicitly consider:
Failure of the positioner
Whether credible failure data exists for that configuration
Whether that failure mode is actually mitigated by your design
This is often overlooked.
2- Low-Power (Pilot-Operated) Solenoid Valves – A Hidden Concern
Nowadays, many solenoid valves used in on/off applications are:
Low wattage
Pilot-operated
These are attractive from an energy and design standpoint — but here is the key question:
Can we safely use pilot-operated (low-watt) SOVs on control valves?
Why this matters:
Pilot-operated SOVs (especially internal pilot types) require a minimum operating pressure in the line
Their operation depends on available line pressure, not just the electrical signal
Now consider this scenario:
The DCS output changes, and the pressure in the line drops below the minimum required pressure for the SOV…
Manufacturer recommendations for the minimum required pressure have not been followed.
What happens then?
Will the SOV still actuate?
Will it fail to move?
Will it go to a safe state… or remain stuck?

Integrated HAZOP–LOPA vs. Separate Studies — Which One Do You Prefer?
In some projects, I see HAZOP and LOPA performed in a single integrated workshop to save time and cost. While this approach may be efficient, it comes with important trade-offs.
From a Functional Safety (IEC 61511) lifecycle perspective, these are distinct phases, each with its own objectives and deliverables:
• HAZOP → Hazard identification
• LOPA → Risk evaluation and IPL/SIL determination
When performed separately:
Better focus and depth in each phase
Independent challenge and verification of assumptions
Clear, auditable reports for each stage
Stronger alignment with lifecycle requirements
When integrated:
Faster and more cost-effective
Risk of reduced quality due to time pressure and team fatigue
Limited independence in verification
Merged reporting can weaken traceability and auditability
In my experience, separating HAZOP and LOPA leads to a more robust and defensible outcome, especially for high-risk facilities.

One additional point to consider: In my view, when HAZOP and LOPA are performed in an integrated manner, one important intent of IEC 61511 can be compromised—specifically, the verification of phase outputs.
When executed separately, the HAZOP report can be properly reviewed and verified before moving into LOPA. This ensures the quality, completeness, and independence of the hazard identification phase before risk quantification begins.
Separating the phases also provides a valuable opportunity for cross-checking assumptions and improving overall study robustness.

Let’s talk about Process Safety Time (PST) and SIF Response Time (Following on ESP explosion due to CH₄ in the gas stream)
In simple terms:
PST = Time from the initiating failure to the hazardous event (e.g., explosion)
SIF Response Time = Time required for the Safety Instrumented Function to act
As SIS engineers, we typically calculate SIF response time as:
Analyzer/sensor response time
Logic solver scan time
Any configured delays
Final element action time
Straightforward… right?
Now let’s challenge that thinking:
Consider a methane (CH₄) analyzer protecting an Electrostatic Precipitator (ESP).
Case 1:
The analyzer is installed very close to the ESP inlet
Very short time for CH₄ to reach the hazard
Case 2:
The analyzer is installed far upstream
-Much longer time for CH₄ to reach the ESP
At first glance:
Same analyzer
Same logic solver
Same final element
- Same calculated SIF response time
But here is the problem:
In Case 1 → explosion occurs
In Case 2 → hazard is prevented
So where did we miss it?

Practical engineering lessons from Real projects and Functional Safety Assessments (FSA)

Client Feedback (LinkedIn)

LOPA Question for Functional Safety Professionals
What would you do if, in a quantitative LOPA, the required risk reduction factor (RRF) is 800 (within the SIL 2 range), but the designed SIF achieves SIL 2 with an RRF of only ~300?
Even though SIL 2 is nominally achieved, this is NOT acceptable.
If the LOPA documents a required RRF, the achieved RRF must be equal to or greater than the required RRF.
Meeting the SIL band alone is insufficient if the quantitative target is not met.
Otherwise, the residual risk remains higher than what was deemed tolerable in LOPA.

In my view, Functional Safety Assessments should carefully consider these details.
Area Classification vs Equipment Certification — A Critical Detail Often Missed
What happens when:
Area classification is based on US standards (Class/Division)
Equipment is certified under European standards (ATEX / IECEx – Zone system)
This situation is quite common—but there is a critical technical detail that must not be overlooked:
Gas Group Classification is NOT directly equivalent—and in fact, it is effectively “reversed” in philosophy between US and IEC systems.
For example:
• US Group A (most severe – e.g., hydrogen/acetylene-type hazards)
• IEC Group IIA → IIB → IIC (where IIC is the most severe)
This means:
If your area classification requires Group A (US), and your equipment is certified for IIA (IEC/ATEX):
This does NOT mean it is suitable
Because:
• IIA is the least severe in IEC system
• While Group A is the most severe in US system
This is where many engineers can unintentionally make incorrect assumptions.
It is not enough to match “group labels”—you must ensure true equivalency of protection level between standards.
The real question is:
Are we verifying technical equivalency, or just comparing names?

SIF Response Time — Is It Only an I&C / SIS Engineer Topic?
The short answer: No. Not in many real scenarios.
Too often, achieved SIF response time calculation is treated purely as an instrumentation exercise.
But in reality, it is a multi-discipline verification involving process engineering, control, and functional safety.
🔹 Instrumented Function Action Time Typically Includes:
• Sensor response time
• Logic solver time (scan time + configured delay)
• relay response (if applicable)
• Solenoid valve response time
• Final element action time (valve stroke time, motor contactor, etc.)
That part is clear.
But here is where engineering judgment becomes critical:
🔹 What About Process Lag?
In many scenarios, removing the cause does not immediately stop the consequence.
Residual heat
Stored pressure
Inertia
Compressibility
Chemical reaction continuation
All can continue driving the hazard even after the SIF has activated.
I always use a simple example in my classes:
Popcorn cooking.
When you turn off the oven, some kernels still pop. Why?
Because residual heat remains.
That is process lag.
The Real Engineering Check
We are not just proving that the SIS hardware reacts fast.
We are verifying that:
SIF action time + relevant process dynamics
is still less than
Time available before consequence becomes unacceptable.
This is where true functional safety competence shows — not in running a SIL tool, but in understanding how the process behaves after intervention.
This topic is discussed in depth in our TÜV Rheinland FS Engineer training programs, where practical project case studies are integrated with standard requirements.
hashtag#Functionalsafety hashtag#IEC61511 hashtag#SIS hashtag#ProcessSafety hashtag#SIF hashtag#LOPA hashtag#HAZOP hashtag#EngineeringJudgment hashtag#SCAIPRO