HAZOP 결과와 Alarm Management의 연계 방법

HAZOP을 수행하면 다양한 Deviation과 Cause, Consequence, Safeguard가 도출됩니다. 이 과정에서 Alarm은 자주 Safeguard로 기록됩니다.

예를 들어 High Pressure, High Temperature, High Level 같은 Deviation에 대해 High Alarm 또는 High-High Alarm이 보호수단으로 제시될 수 있습니다. 하지만 HAZOP Worksheet에 Alarm이 존재한다고 기록하는 것만으로는 충분하지 않습니다.

실제 공정에서 해당 Alarm이 위험상황을 적절한 시점에 감지하고, 운전원이 올바른 조치를 수행할 수 있으며, 불필요한 Alarm Flood 속에서도 식별 가능한지까지 확인해야 합니다.

이 때문에 HAZOP 결과는 Alarm Management 체계와 연계하여 관리하는 것이 중요합니다.

1. HAZOP과 Alarm Management는 어떻게 연결되는가?

HAZOP은 특정 공정위험을 식별합니다.

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

Deviation: High Temperature
Cause: Cooling Water Flow 감소
Consequence: Reaction Rate 증가 → Reactor Overpressure 가능
Safeguard: High Temperature Alarm

이 경우 HAZOP에서는 Alarm이 보호수단으로 기록됩니다.

하지만 Alarm Management에서는 다음 질문을 추가로 검토해야 합니다.

• Alarm Set Point가 적절한가?
• 운전원이 조치할 시간이 충분한가?
• Alarm 우선순위는 적절한가?
• 운전원에게 명확한 대응절차가 있는가?
• 동일 상황에서 너무 많은 Alarm이 동시에 발생하지 않는가?
• Alarm이 장기간 Suppress 또는 Shelve되어 있지는 않은가?

즉 HAZOP이 Alarm 필요성을 발견하는 과정이라면 Alarm Management는 그 Alarm이 실제로 효과적으로 작동하도록 관리하는 과정이라고 볼 수 있습니다.

2. HAZOP에서 모든 Alarm을 Safeguard로 인정하면 안 된다

HAZOP 실무에서 흔히 발생하는 오류 중 하나가 해당 공정에 Alarm이 존재한다는 이유만으로 모두 Safeguard로 기록하는 것입니다.

예를 들어 High Pressure Scenario에서 Pressure Alarm이 있다고 하더라도 다음 조건을 만족하지 못하면 보호효과가 제한적일 수 있습니다.

• 운전원이 Alarm을 인지할 수 있어야 함
• 사고 진행 전에 충분한 대응시간이 있어야 함
• 대응조치가 명확해야 함
• 운전원이 실제로 수행 가능한 Action이어야 함

예를 들어 Reactor Runaway가 수십 초 안에 진행되는 공정이라면 단순 High Temperature Alarm과 운전원 대응만으로 사고를 막기 어려울 수 있습니다.

이 경우 자동 Trip이나 SIS가 필요할 수 있습니다.

따라서 HAZOP에서는 단순히

Safeguard: High Temperature Alarm

이라고 기록하기보다 Alarm + Operator Action까지 하나의 보호기능으로 보는 것이 중요합니다.

3. Alarm Set Point는 HAZOP 결과와 일치해야 한다

HAZOP과 Alarm Management를 연결할 때 가장 중요한 항목 중 하나가 Set Point입니다.

예를 들어 Reactor의 정상 운전온도가 100℃이고 High Temperature Alarm이 120℃, High-High Trip이 140℃라고 가정해보겠습니다.

그런데 설비의 안전운전 한계가 125℃라면 High-High Trip이 너무 늦게 작동할 가능성이 있습니다.

따라서 Set Point는 다음 순서와 관계를 검토해야 합니다.

Normal Operating Range

→ Alarm Set Point

→ Trip Set Point

→ Design Limit

→ Equipment Failure Point

각 Set Point 사이에는 운전원이 대응할 수 있는 충분한 시간과 공정 Margin이 있어야 합니다.

4. Alarm Priority는 Consequence Severity와 연계해야 한다

Alarm Management에서는 일반적으로 Alarm에 Priority를 부여합니다.

예를 들어

• Low
• Medium
• High

등으로 구분할 수 있습니다.

이때 HAZOP 결과의 Consequence Severity를 Alarm Priority 선정에 활용할 수 있습니다.

예를 들어 단순 생산품질 문제를 유발하는 Alarm과 Reactor Overpressure로 이어질 수 있는 Alarm을 같은 Priority로 관리하는 것은 적절하지 않습니다.

HAZOP에서 Consequence가

Vessel Rupture → Toxic Release

처럼 중대한 사고로 이어질 수 있다면 해당 Alarm은 높은 중요도를 가질 가능성이 있습니다.

즉 HAZOP의 Severity 정보는 Alarm Rationalization에서 Priority 결정의 중요한 자료가 됩니다.

5. Alarm Rationalization에 HAZOP 결과를 활용한다

Alarm Rationalization은 각각의 Alarm이 왜 필요한지, 언제 발생해야 하는지, 운전원이 어떤 조치를 해야 하는지를 검토하는 과정입니다.

일반적으로 다음 정보를 정리합니다.

• Alarm Tag
• Alarm Description
• Alarm Cause
• Consequence
• Operator Action
• Priority
• Set Point
• Response Time

이 구조는 HAZOP Worksheet와 매우 유사합니다.

예를 들어 HAZOP에서 다음 Scenario가 있다면

Cause: Cooling Water Failure
Deviation: High Temperature
Consequence: Reactor Overpressure
Safeguard: High Temperature Alarm

Alarm Rationalization에서는 이를 다음처럼 구체화할 수 있습니다.

Alarm: TAH-101
Cause: Cooling Water Flow 감소
Consequence: Reactor Temperature 상승 및 Runaway 가능
Operator Action: Feed 감소 및 Emergency Cooling 확인
Priority: High
Response Time: 5분 이내

이렇게 HAZOP 결과를 Alarm 관리자료로 연결할 수 있습니다.

6. Alarm Flood를 고려해야 한다

실제 사고에서는 하나의 Alarm만 발생하는 경우보다 여러 Alarm이 동시에 발생하는 경우가 많습니다.

예를 들어 Cooling Water Failure가 발생하면

• Low Cooling Water Flow Alarm
• High Reactor Temperature Alarm
• High Reactor Pressure Alarm
• High Level Alarm
• Pump Trip Alarm

등이 연속적으로 발생할 수 있습니다.

이때 수십 개 또는 수백 개의 Alarm이 동시에 발생하면 운전원이 가장 중요한 Alarm을 놓칠 수 있습니다.

이를 Alarm Flood라고 합니다.

따라서 HAZOP에서는 개별 Alarm 존재 여부만 확인할 것이 아니라 공통 Cause로 여러 Alarm이 동시에 발생하는 Scenario도 고려해야 합니다.

7. First-Out Alarm을 활용할 수 있다

Alarm Flood 상황에서는 사고의 최초 원인을 보여주는 First-Out Alarm이 매우 중요할 수 있습니다.

예를 들어

Cooling Water Failure

→ Reactor High Temperature

→ Reactor High Pressure

→ ESD Trip

순서로 진행된다면 운전원에게 최초 이상상태인 Cooling Water Failure를 명확하게 보여주는 것이 사고 대응에 도움이 됩니다.

따라서 HAZOP에서 사고 Sequence를 분석한 결과는 First-Out Logic 설계에도 활용할 수 있습니다.

8. Alarm과 Interlock의 역할을 구분해야 한다

Alarm과 Interlock은 동일하지 않습니다.

Alarm은 일반적으로

감지 → 운전원 판단 → 운전원 조치

과정을 거칩니다.

반면 Interlock은

감지 → 자동 Logic → 자동 Action

으로 작동합니다.

따라서 사고가 빠르게 진행되는 Scenario에서는 Alarm보다 자동 Interlock이 더 적절할 수 있습니다.

HAZOP에서는 다음 질문을 해야 합니다.

“운전원이 실제로 대응할 시간이 있는가?”

충분하다면 Alarm + Operator Action이 Safeguard가 될 수 있습니다.

시간이 부족하다면 Recommendation으로 자동 Trip이나 SIS를 검토해야 할 수 있습니다.

9. Nuisance Alarm은 Safeguard 신뢰성을 떨어뜨린다

Alarm이 너무 자주 발생하면 운전원이 Alarm을 무시하거나 Suppress할 가능성이 높아집니다.

이를 Nuisance Alarm 또는 Chattering Alarm 문제라고 볼 수 있습니다.

예를 들어 High Level Alarm이 하루에 수십 번 반복된다면 운전원은 이를 정상운전의 일부처럼 인식할 수 있습니다.

이 상태에서 실제 Overfill Scenario가 발생하면 Alarm의 보호효과가 크게 낮아질 수 있습니다.

따라서 HAZOP에서 중요한 Safeguard로 인정된 Alarm은 Alarm Performance Monitoring에서도 특별히 관리해야 합니다.

10. Alarm Suppression과 Shelving을 확인해야 한다

Alarm Management에서는 특정 Alarm을 일시적으로 Suppress 또는 Shelve할 수 있습니다.

정비나 비정상 운전 시 필요한 기능일 수 있지만, HAZOP에서는 해당 Alarm이 Safeguard로 가정되어 있을 수 있습니다.

예를 들어

Safeguard: High-High Level Alarm

인데 실제 현장에서는 해당 Alarm이 장기간 Shelved 상태라면 보호기능이 사실상 없는 것과 같습니다.

따라서 HAZOP Revalidation이나 자체감사에서는 중요한 Alarm의

• Suppression 상태
• Shelving 이력
• Override 상태
• Alarm Disable 상태

를 확인하는 것이 좋습니다.

11. Alarm과 Operator Response Time을 연계해야 한다

Alarm이 Safeguard가 되려면 운전원이 조치할 시간이 충분해야 합니다.

예를 들어 Tank Overfill Scenario에서 High Level Alarm 발생 후 Overfill까지 30분이 남아 있다면 운전원 대응이 현실적으로 가능할 수 있습니다.

반대로 20초밖에 없다면 Alarm은 충분한 보호수단이 아닐 수 있습니다.

따라서 Alarm Rationalization에서는 Maximum Allowable Response Time을 검토하는 것이 중요합니다.

HAZOP Consequence 분석에서 사고 진행시간을 추정할 수 있다면 이를 Alarm Response Time 설정에 활용할 수 있습니다.

12. Human Factors도 함께 검토해야 한다

Alarm은 기술적인 장치이지만 최종적으로 운전원이 대응해야 하는 경우가 많습니다.

따라서 다음 사항도 중요합니다.

• Alarm Message가 이해하기 쉬운가?
• 운전원이 어떤 조치를 해야 하는지 알고 있는가?
• 여러 Alarm이 동시에 발생해도 우선순위를 판단할 수 있는가?
• 운전절차서에 대응방법이 명확한가?
• 교대조 간 Alarm 정보가 인계되는가?

예를 들어 화면에

ALM-101

만 표시되는 것보다

REACTOR HIGH PRESSURE – REDUCE FEED

처럼 의미 있는 메시지가 운전원 대응에 도움이 될 수 있습니다.

13. MOC 발생 시 Alarm도 함께 재검토해야 한다

공정변경이 발생하면 Alarm Management도 변경되어야 할 수 있습니다.

예를 들어 생산량이 증가하여 정상 Level이 상승했는데 기존 High Level Alarm Set Point를 그대로 사용하면 Alarm이 너무 자주 발생할 수 있습니다.

반대로 설비의 허용한계가 낮아졌는데 Set Point를 그대로 두면 Alarm이 너무 늦게 발생할 수 있습니다.

따라서 MOC에서는 다음 사항을 검토하는 것이 좋습니다.

• Alarm 추가 필요 여부
• Alarm 삭제 가능 여부
• Set Point 변경
• Priority 변경
• Operator Action 변경
• Interlock과의 관계

14. HAZOP Revalidation에서는 Alarm 유효성을 다시 확인해야 한다

과거 HAZOP에서 Alarm이 Safeguard로 인정되었다고 해서 현재도 동일한 효과가 있다고 볼 수는 없습니다.

Revalidation에서는 다음을 확인해야 합니다.

① Alarm Tag가 실제 존재하는가?

② Set Point가 변경되었는가?

③ Priority가 적절한가?

④ 운전원이 대응방법을 알고 있는가?

⑤ Alarm이 자주 발생해 무시되고 있지는 않은가?

⑥ Suppress 또는 Shelve 상태는 아닌가?

⑦ 사고 진행시간보다 Operator Response Time이 짧은가?

이런 확인이 필요합니다.

15. 실무 예제로 보는 연계 방법

다음 Scenario를 가정해보겠습니다.

Deviation: Tank High Level
Cause: Inlet Control Valve Fail Open
Consequence: Tank Overfill → Flammable Liquid Release

HAZOP Safeguard는

High Level Alarm

이라고 가정합니다.

Alarm Management에서는 다음과 같이 구체화합니다.

Alarm: LAH-101
Set Point: 80%
Priority: High
Cause: Inlet Valve Fail Open
Consequence: Tank Overfill
Operator Action: Feed Pump Stop 및 Inlet Valve Close
Response Time: Overfill 발생 전 조치 완료

그리고 추가로

High-High Level Trip : 90%

에서 자동 Feed Isolation이 작동하도록 설계할 수 있습니다.

이렇게 HAZOP과 Alarm Management를 연결하면 보호기능이 훨씬 명확해집니다.

16. HAZOP-Alarm Management 연계 체크리스트

실무에서는 다음 순서로 확인하면 좋습니다.

① HAZOP에서 Alarm으로 기록된 Safeguard 목록을 추출한다.

② 실제 DCS/SIS Alarm List와 비교한다.

③ Tag와 Set Point를 확인한다.

④ Alarm Priority를 확인한다.

⑤ Operator Action을 확인한다.

⑥ 사고 진행시간과 Response Time을 비교한다.

⑦ Alarm Flood 가능성을 검토한다.

⑧ Suppression 및 Shelving 상태를 확인한다.

⑨ MOC 변경사항이 반영되었는지 확인한다.

⑩ HAZOP Revalidation 시 다시 유효성을 평가한다.

마무리

HAZOP에서 Alarm은 매우 자주 Safeguard로 등장하지만, Alarm이 존재한다는 사실만으로 충분한 보호수단이 되는 것은 아닙니다.

Alarm이 실제 Safeguard로 기능하려면

적절한 Set Point

명확한 Priority

충분한 Operator Response Time

구체적인 대응절차

Alarm Flood에서도 식별 가능한 관리상태

가 함께 확보되어야 합니다.

따라서 HAZOP과 Alarm Management의 관계는 다음과 같이 볼 수 있습니다.

HAZOP → Hazard Scenario 식별

Alarm Rationalization → Alarm의 필요성과 기능 정의

Alarm Management → Alarm의 지속적인 성능 유지

그리고 다시

HAZOP Revalidation → Alarm의 실제 유효성 재확인

으로 연결됩니다.

결국 좋은 Alarm Management는 Alarm 개수를 많이 만드는 것이 아니라 HAZOP에서 확인된 위험을 운전원이 적절한 시간 안에 인지하고 대응할 수 있도록 필요한 Alarm만 명확하게 관리하는 체계라고 할 수 있습니다.