LOPA에서 Independent Protection Layer(IPL)를 인정하기 위한 조건

LOPA(Layer of Protection Analysis)를 수행할 때 가장 중요한 작업 중 하나는 어떤 Safeguard를 Independent Protection Layer(IPL)로 인정할 것인지 판단하는 것입니다.

HAZOP에서는 Alarm, Interlock, PSV, 운전절차, Operator Action 등 다양한 보호수단을 Safeguard로 기록할 수 있습니다. 그러나 HAZOP에서 Safeguard로 인정되었다고 해서 모두 LOPA에서 IPL로 인정되는 것은 아닙니다.

LOPA에서는 각 보호계층에 일정한 Risk Reduction Credit을 부여하기 때문에, 실제로 사고를 막을 수 있는지뿐만 아니라 Initiating Event 및 다른 보호계층과 독립적으로 작동할 수 있는지를 보다 엄격하게 확인해야 합니다.

핵심은 다음과 같습니다.

Safeguard ⊃ IPL

즉 모든 IPL은 Safeguard라고 할 수 있지만, 모든 Safeguard가 IPL은 아닙니다.

---

1. IPL의 기본 개념

IPL은 특정 사고 시나리오에서 Initiating Event가 발생한 이후 사고가 최종 Consequence까지 진행되는 것을 독립적으로 예방하거나 완화하는 보호계층을 의미합니다.

예를 들어 Reactor에서 다음과 같은 Scenario를 가정해보겠습니다.

Initiating Event: Feed Control Valve Fail Open

→ Excess Feed

→ Reactor High Temperature

→ Reactor Overpressure

→ Vessel Failure

이때 다음 보호수단이 있다고 가정하겠습니다.

• High Temperature Alarm
• Operator Action
• High-High Temperature Trip
• PSV

HAZOP에서는 네 항목 모두 Safeguard 후보가 될 수 있습니다.

하지만 LOPA에서는 각각이 IPL 인정조건을 만족하는지 하나씩 검토해야 합니다.

---

2. 가장 중요한 조건, Independence

IPL에서 가장 중요한 조건은 이름 그대로 Independence, 독립성입니다.

보호계층은 최소한 다음 두 가지로부터 독립적이어야 합니다.

① Initiating Event와 독립적이어야 합니다.

② 다른 IPL과도 충분히 독립적이어야 합니다.

예를 들어 Initiating Event가

DCS Control Loop Failure

인데 Safeguard인 High-High Trip도 같은 DCS Controller를 사용한다면 동일한 DCS Failure로 두 기능이 동시에 상실될 수 있습니다.

따라서 독립적인 IPL Credit을 부여하기 어렵습니다.

---

3. Initiating Event와 동일 원인에 의한 동시 실패 여부

다음 Scenario를 생각해보겠습니다.

Initiating Event: Total Power Failure

Safeguard:

Electric Emergency Cooling Pump

Emergency Cooling Pump가 일반 전원과 동일한 전원을 사용한다면 Power Failure가 발생했을 때 Safeguard도 함께 기능을 잃을 수 있습니다.

이 경우 해당 Emergency Pump를 이 Scenario의 독립적인 IPL로 인정하기 어렵습니다.

반대로 독립된 Emergency Generator 또는 별도 동력원을 사용하는 경우에는 독립성을 추가로 검토해볼 수 있습니다.

따라서 항상 다음 질문이 중요합니다.

“Initiating Event가 발생했을 때 이 보호수단도 동시에 무력화되는가?”

---

4. 다른 IPL과의 공통 요소 공유 여부

보호장치가 여러 개 있다고 해서 각각 하나의 IPL이 되는 것은 아닙니다.

예를 들어 다음 구조를 생각해보겠습니다.

PT-101 → High Pressure Alarm

PT-101 → High-High Pressure Trip

Alarm과 Trip은 두 개지만 동일한 PT-101을 사용합니다.

PT-101이 고장나면 두 보호기능이 동시에 영향을 받을 수 있습니다.

또한 두 기능이 동일한 DCS를 사용하고 동일한 Shutdown Valve까지 사용하는 경우에는 더 많은 공통요소를 가지고 있습니다.

따라서 IPL 독립성을 검토할 때는 다음 전체 경로를 확인해야 합니다.

Sensor → Logic Solver → Final Element → Power/Utility

---

5. Specificity 충족 여부

IPL은 해당 사고 Scenario에 구체적으로 대응할 수 있어야 합니다.

이를 Specificity라고 합니다.

예를 들어

Initiating Event: Reactor Cooling Water Failure

Consequence: Runaway Reaction → Overpressure

일 때

Safeguard: 작업자가 현장을 순찰함

이라고 되어 있다면 이것만으로 해당 Scenario를 구체적으로 감지하고 차단할 수 있다고 보기 어렵습니다.

반면

Reactor High-High Temperature 감지 → Feed Isolation Valve 자동 Close

와 같이 특정 위험을 감지하여 필요한 안전동작을 수행한다면 Specificity가 높습니다.

즉

“이 보호수단이 바로 이 Scenario를 막기 위해 명확하게 작동하는가?”

를 확인해야 합니다.

---

6. Effectiveness 검증

IPL은 실제로 사고 진행을 막거나 Consequence를 완화할 수 있어야 합니다.

장치가 설치되어 있다는 사실만으로 충분하지 않습니다.

예를 들어 PSV를 IPL 후보로 검토한다고 가정해보겠습니다.

다음 사항을 확인해야 합니다.

• 적절한 Set Pressure인지
• 해당 Overpressure Scenario가 설계에 반영되어 있는지
• Required Relief Capacity를 만족하는지
• Inlet Pressure Loss가 적정한지
• Built-up Back Pressure가 허용범위인지
• Outlet System이 충분한지
• Isolation Valve가 정상 위치인지

PSV가 존재하더라도 실제 Relief Load보다 Capacity가 부족하다면 해당 Scenario에 대해 충분히 효과적인 IPL이라고 보기 어렵습니다.

---

7. Dependability와 신뢰성

IPL은 요구될 때 일정 수준 이상의 확률로 정상 작동해야 합니다.

LOPA에서는 보호계층의 실패확률을 일반적으로 PFD(Probability of Failure on Demand) 등의 개념으로 반영합니다.

예를 들어

PFD = 1 × 10⁻²

라면 요구될 때 약 100회 중 1회 정도 실패하는 수준의 확률 개념으로 이해할 수 있습니다.

따라서 보호기능에 Risk Reduction Credit을 부여하려면 그 성능을 뒷받침할 수 있는 설계·운영·시험 체계가 필요합니다.

단순히

“지금까지 고장난 적이 없습니다.”

라는 이유만으로 높은 Risk Reduction Credit을 부여해서는 안 됩니다.

---

8. Auditability 확보

IPL은 보호기능이 지속적으로 유지되고 있는지를 확인할 수 있어야 합니다.

이를 Auditability라고 합니다.

예를 들어 다음 자료가 있어야 합니다.

• Inspection Record
• Functional Test Record
• Proof Test Record
• Calibration Record
• Maintenance History
• Bypass History

예를 들어 High-High Level Trip을 IPL로 사용한다고 가정하겠습니다.

설치는 되어 있지만 최근 몇 년 동안 Function Test를 한 기록이 없다면 실제로 정상 작동할지 확인하기 어렵습니다.

즉 설계 당시 존재하는 것뿐 아니라 운전기간 동안 기능이 유지되는 것을 확인할 수 있어야 합니다.

---

9. Alarm의 IPL 인정 조건

Alarm이 있다고 해서 자동으로 IPL이 되는 것은 아닙니다.

Alarm은 일반적으로

Sensor → Alarm → Operator 인지 → 판단 → 조치

의 과정을 거칩니다.

따라서 다음 조건을 검토해야 합니다.

• 독립적인 Alarm인지
• Alarm Set Point가 적절한지
• 운전원이 Alarm을 확실하게 인지할 수 있는지
• 대응방법이 명확한지
• 충분한 Response Time이 있는지
• 대응조치가 실제로 사고를 막을 수 있는지
• 정기적으로 교육·훈련되고 있는지

특히 사고가 수십 초 안에 진행되는데 운전원이 수동으로 Valve를 찾아가 닫아야 한다면 현실적인 IPL로 인정하기 어렵습니다.

---

10. Alarm과 Operator Action의 중복 Credit 방지

다음과 같은 보호기능을 생각해보겠습니다.

High Pressure Alarm

→ 운전원이 Alarm 확인

→ Feed Pump Stop

이 경우

Alarm = IPL 1

Operator Action = IPL 2

처럼 두 개로 계산해서는 안 됩니다.

Operator Action은 Alarm을 통해 위험을 인지하기 때문입니다.

따라서 일반적으로

Alarm + Operator Response

를 하나의 보호기능으로 평가해야 합니다.

---

11. BPCS의 IPL 인정 조건

Basic Process Control System(BPCS)은 경우에 따라 LOPA에서 보호계층으로 검토될 수 있지만 매우 신중하게 접근해야 합니다.

예를 들어

Initiating Event: Temperature Control Loop Failure

인데 동일한 BPCS의 High Temperature Alarm을 IPL로 사용하려고 한다면 공통 시스템 실패 문제가 발생할 수 있습니다.

즉 동일 BPCS Failure가 Initiating Event와 Safeguard 양쪽에 영향을 줄 수 있습니다.

따라서 BPCS 관련 Credit을 적용할 때는 다음을 확인해야 합니다.

• Initiating Event와의 독립성
• Sensor 독립성
• Logic 독립성
• Final Element 독립성

---

12. SIS/SIF의 IPL 인정 조건

Safety Instrumented Function(SIF)은 대표적인 IPL 후보입니다.

예를 들어

Reactor High-High Temperature

→ SIS

→ Feed Isolation Valve Close

와 같은 구조입니다.

하지만 SIS라는 이름만 붙어 있다고 자동으로 IPL Credit을 받을 수 있는 것은 아닙니다.

다음 사항을 확인해야 합니다.

• Initiating Event와 독립적인지
• 다른 IPL과 독립적인지
• Sensor가 적절한지
• Logic Solver가 적절한지
• Final Element가 적절한지
• Proof Test가 수행되는지
• 필요한 SIL 또는 PFD를 만족하는지

즉 설계와 검증을 통해 성능이 확인되어야 합니다.

---

13. PSV의 IPL 인정 조건

PSV는 기계적인 압력 보호장치이므로 DCS, PLC 등의 계측시스템과 다른 작동원리를 가지고 있습니다.

따라서 Overpressure Scenario에서는 독립성이 높은 IPL 후보가 될 수 있습니다.

예를 들어

Feed Valve Fail Open

→ Reactor High Pressure

Scenario에서 PSV가 적절하게 설계되어 있다면 Overpressure를 방지할 수 있습니다.

하지만 반드시 다음 사항을 확인해야 합니다.

PSV Capacity ≥ Required Relief Load

또한 Set Pressure, Back Pressure, Discharge System 및 Isolation 상태 등을 함께 검토해야 합니다.

---

14. 운전절차서와 Operator Action의 한계

HAZOP에서 다음과 같은 Safeguard를 자주 볼 수 있습니다.

“안전운전절차서가 있습니다.”

절차서 자체는 위험을 자동으로 감지하거나 사고를 차단하지 않습니다.

실제로는

운전원이 이상상태를 인지하고 → 절차에 따라 → 적절한 시간 안에 조치

해야 보호효과가 발생합니다.

따라서 SOP가 존재한다는 사실만으로 높은 Risk Reduction Credit을 부여하는 것은 적절하지 않습니다.

Operator Action을 IPL로 평가하려면 실제 대응과정 전체를 검토해야 합니다.

---

15. Common Cause Failure 검토

여러 IPL이 하나의 공통원인으로 동시에 실패할 가능성을 확인해야 합니다.

대표적인 Common Cause는 다음과 같습니다.

• Total Power Failure
• Instrument Air Failure
• Common Sensor Failure
• Common Logic Solver Failure
• Fire
• Flooding
• Common Utility Failure
• Shared Final Element

예를 들어 두 개의 독립 Pump가 있어도 같은 전원 MCC를 사용한다면 정전 시 동시에 정지할 수 있습니다.

따라서 단순히 설비가 두 대라는 사실만으로 두 개의 독립 IPL로 평가해서는 안 됩니다.

---

16. 실무 사례를 통한 IPL 판단

다음 Reactor Scenario를 가정하겠습니다.

Initiating Event: Feed Control Valve FCV-101 Fail Open

Consequence:

Excess Feed

→ Reactor High Temperature

→ Reactor High Pressure

→ Vessel Failure

현재 보호수단은 다음과 같습니다.

Safeguard ① High Temperature Alarm

TT-101이 Temperature를 측정하고 DCS에서 Alarm을 발생시킵니다.

운전원이 Feed를 수동으로 차단합니다.

Safeguard ② High-High Temperature Trip

동일한 TT-101 Signal을 이용해 동일 DCS에서 Feed Valve를 자동 Close합니다.

Safeguard ③ PSV

Reactor Pressure 상승 시 기계적으로 Open합니다.

겉으로 보면 Safeguard가 3개입니다.

그러나 Alarm과 HH Trip은 동일한 Sensor와 DCS를 공유하고 있습니다.

따라서 두 기능을 완전히 독립적인 IPL로 각각 Credit을 부여할 수 있는지 추가 검토가 필요합니다.

반면 PSV는 다른 원리로 작동하기 때문에 적절하게 설계·관리되고 있다면 별도의 IPL 후보가 될 수 있습니다.

---

17. Double Counting 방지

LOPA에서 가장 주의해야 할 오류 중 하나가 동일한 보호기능에 Risk Reduction Credit을 두 번 이상 부여하는 것입니다.

예를 들어 다음 구조가 있습니다.

LAHH-101 → SIS → XV-101 Close

이를

High-High Level Switch = IPL 1

SIS Logic = IPL 2

Shutdown Valve = IPL 3

으로 계산하면 안 됩니다.

이 세 장치는 각각 별도의 IPL이 아니라 하나의 SIF를 구성하는 요소입니다.

즉,

Sensor + Logic Solver + Final Element = 하나의 IPL

로 평가해야 합니다.

---

18. 과도한 Risk Reduction Credit 방지

보호장치의 명칭만 보고 임의로 높은 Risk Reduction Factor를 적용해서는 안 됩니다.

예를 들어

Interlock이 있으므로 100배 Risk Reduction

이라고 단순하게 가정해서는 안 됩니다.

Risk Reduction Credit은 다음과 같은 요소에 근거해야 합니다.

• 설계방식
• 독립성
• Failure Rate
• Proof Test Interval
• Architecture
• 유지보수 상태

특히 SIF의 경우 요구되는 위험저감 수준이 높다면 SIL Verification을 통해 실제 PFDavg를 확인해야 합니다.

---

19. MOC 발생 시 IPL 재검토

공정변경이 발생하면 기존 IPL의 유효성이 달라질 수 있습니다.

예를 들어 생산량 증가로 Tank Filling Rate가 증가하면 기존 High Level Alarm 이후 Operator가 대응할 수 있는 시간이 감소할 수 있습니다.

또 Pump Capacity 증가로 Relief Load가 증가하면 기존 PSV의 Capacity가 부족해질 수도 있습니다.

따라서 MOC에서는 다음 사항을 확인해야 합니다.

• IPL 기능 유지 여부
• Set Point 적정성
• Response Time 충분 여부
• PSV Capacity 충분 여부
• 신규 Common Cause 발생 여부
• 독립성 변화 여부

---

20. IPL 인정 여부 실무 체크리스트

LOPA Team에서는 각 보호수단에 대해 다음 질문을 적용하는 것이 좋습니다.

① Initiating Event와 독립되어 있습니까?

② 다른 IPL과 독립되어 있습니까?

③ 해당 Scenario를 구체적으로 예방하거나 완화합니까?

④ 실제 사고가 진행되기 전에 작동합니까?

⑤ 충분한 신뢰성이 확보되어 있습니까?

⑥ Sensor, Logic Solver, Final Element의 공통고장이 없습니까?

⑦ 동일한 Power 또는 Utility Failure에 동시에 영향을 받지 않습니까?

⑧ 정기적인 Inspection, Test 또는 Proof Test가 이루어집니까?

⑨ Bypass 또는 Override 상태가 관리됩니까?

⑩ Risk Reduction Credit의 근거를 문서로 확인할 수 있습니까?

이 조건을 만족하지 못한다면 HAZOP에서는 Safeguard로 기록하더라도 LOPA에서 독립적인 IPL Credit을 부여하는 것은 신중해야 합니다.

---

마무리

LOPA에서 IPL을 인정하는 핵심은 보호장치가 존재하는지 확인하는 것이 아니라 실제 사고 시나리오에서 독립적이고 신뢰성 있게 위험을 감소시킬 수 있는지를 검증하는 것입니다.

실무적으로는 다음 네 가지를 중심으로 판단할 수 있습니다.

Independence

→ Initiating Event 및 다른 보호계층과 독립적이어야 합니다.

Specificity

→ 분석 중인 특정 사고 Scenario에 직접 대응해야 합니다.

Effectiveness / Dependability

→ 사고를 실제로 방지하거나 완화할 수 있고 요구될 때 충분한 신뢰도로 작동해야 합니다.

Auditability

→ Inspection, Test, Proof Test 등을 통해 기능 유지 여부를 확인할 수 있어야 합니다.

그리고 반드시 기억해야 할 것은 다음과 같습니다.

HAZOP Safeguard ≠ LOPA IPL

Alarm + Operator Action = 일반적으로 하나의 보호기능

Sensor + Logic Solver + Final Element = 하나의 SIF/IPL

공통원인에 의해 동시에 실패할 수 있는 보호수단에는 독립적인 Credit을 중복 부여해서는 안 됩니다.

따라서 LOPA의 전체 흐름은 다음과 같이 연결됩니다.

Initiating Event → Consequence → Safeguard 후보 확인 → IPL 인정조건 검토 → 독립성 검증 → PFD/Risk Reduction Credit 적용 → Residual Risk 평가

결국 좋은 LOPA는 IPL의 개수를 많이 만드는 분석이 아니라, 실제로 독립적으로 작동할 수 있는 보호계층만 선별하고 그 성능에 근거하여 적절한 Risk Reduction Credit을 부여하는 분석이라고 할 수 있습니다.