Flood를 정의하는 숫자
IEC 62682(그 이전의 ISA-18.2)는 선을 분명히 긋는다. 운전원 한 자리 기준 10분에 10건을 넘으면 flood다. EEMUA 191도 같은 기준을 쓰면서, flood가 사실상 불가능하게 만드는 목표치를 하나 더 둔다. 장기 평균 10분에 약 1건. 10분에 10건을 넘기는 순간 운전원은 읽기를 멈추고 acknowledge만 누르기 시작한다.
하지만 건수는 증상이지 문제 자체가 아니다. 진짜 피해는, flood 중에는 어떤 알람이 사건을 시작했는지, 어떤 게 결과인지, 지금 어떤 조작이 안전한지 아무도 판단할 수 없다는 데 있다. Active 알람 400건이 깔끔하게 정렬돼 떠 있어도, 정작 필요한 그 순간에는 쓸모가 없다.
사람을 압도하는 flood는 nuisance 알람이 서서히 쌓인 게 아니다 — 그건 rationalization으로 잡는다. 위험한 건 한꺼번에 몰려오는 쪽이다.
- 순간 정전이나 전원 복구 시퀀스. 설비 절반이 동시에 다시 알람을 낸다.
- Compressor trip, pump trip, 공통 utility 정지가 하위로 연쇄된다.
- PLC, remote I/O rack, package skid 통신 끊김 — 가장 지독한 원인이고, 이 글에서 가장 많이 다루는 항목이다.
- 계장 공기, 냉각수, vacuum 같은 공통 계통 이상이 여러 unit을 동시에 친다.
- 여러 장치 상태가 이미 바뀐 뒤에 정비 bypass를 해제한 경우.
목표는 조용한 알람 목록이 아니다. Upset 중에 알람 목록이 조용하다면 보통 누군가 과하게 suppress해서 원인까지 묻은 것이다. 목표는 시작 조건을 지키고, 설비 상태를 분명히 보여 주고, 운전원이 정작 중요한 알람 하나에 닿으려고 후속 알람 수백 개를 acknowledge하게 만들지 않는 것이다.
화면 첫 줄은 first-out이 아니다
First-out 알람은 정해진 그룹 안에서 trip이나 shutdown을 처음 만든 조건이다. 알람 summary 맨 위 줄과 자동으로 같아지는 일은 거의 없다. 통신 지연, PLC scan time, priority 정렬, server receive timestamp 처리가 모두 화면 순서를 바꾼다.
Trip과 관련된 그룹은 먼저 경계를 정해야 한다.
| 그룹 | 예 | first-out 의미 |
|---|---|---|
| Motor protection | Pump trip permissive | 운전 회로를 처음 끊은 보호 입력 |
| Package skid | Compressor shutdown | Skid controller가 latch한 최초 shutdown cause |
| Process unit | Interlock chain | Interlock을 실제로 건 최초 공정 조건 |
| Utility area | Header failure | 하위 장치 알람보다 먼저 발생한 공통 utility 이상 |
가능하면 PLC나 safety controller에서 first-out을 latch한다. 나는 원인 분석에 HMI 정렬 순서를 믿지 않는다. 몇 번 데어 본 뒤로는 분명히 말한다. 알람 화면은 운전원의 실시간 부담용이지 사후 분석용이 아니다. Latch는 trip logic이 사는 곳에 둔다.
Timestamp를 못 믿으면 sequence도 없는 것이다
Sequence of events는 뒤에 있는 clock만큼만 정확하다. 1초 단위 HMI timestamp는 느린 level이나 온도 알람에는 충분하다. 하지만 breaker trip, E-stop, 수 밀리초 안에 끝나는 빠른 interlock chain에는 무의미하다. 거기서는 HMI가 한 번 tick하기도 전에 사건이 끝나 있다.
Clock 분해능을 알람 class에 맞추고, 각 timestamp가 어디서 찍히는지 알아야 한다.
- PLC scan timestamp — 분해능은 scan time, 보통 10~50 ms.
- Safety controller / SER event timestamp — 보통 1 ms. Breaker와 trip 분석에 필요한 값이다.
- Remote I/O module timestamp.
- SCADA server receive timestamp — 사건이 아니라 네트워크 경로를 반영한다.
- HMI client display timestamp — 순서 판단에는 가장 못 믿을 값.
- Historian event timestamp.
장치 간 millisecond 순서를 믿기 전에 clock을 어떻게 동기화하는지부터 확인한다. NTP는 괜찮은 LAN에서 대략 1~10 ms — 공정 알람 순서에는 충분해도 1 ms SER stream을 가르기에는 부족하다. 밀리초 이하 순서가 필요하면 NTP가 아니라 하드웨어 timestamping을 쓰는 IEEE 1588 PTP가 답이다. Clock이 조용히 틀어지는데 깔끔해 보이는 event list는 없는 것보다 위험하다. 틀린 시작 원인에 그럴듯한 timestamp를 붙여서 건네기 때문이다.
정상 알람 화면과 flood 분석 화면은 달라야 한다
일반 alarm summary는 운전 중 현재 부담을 줄이는 데 맞춰져 있다. Flood 분석에는 다른 화면이 필요하다.
Flood review 화면에는 이런 필드가 도움이 된다.
- 가능한 경우 millisecond가 포함된 event time.
- Active, returned, acknowledged, suppressed, shelved 상태.
- Source controller 또는 package skid 이름.
- Area와 equipment.
- Alarm group 또는 interlock group.
- Priority와 alarm class.
- First-out flag 또는 trip cause latch.
- Event 시점의 quality 또는 communication 상태.
Flood review 화면에서 return된 알람을 숨기면 안 된다. Trip 순간에 짧게 들어왔다 사라진 알람이 원인 단서인 경우가 많다.
대부분의 flood는 통신 끊김에서 태어난다
한 번의 장애로 수천 개 알람을 만드는 게 바로 이 경우다. PLC 통신이 끊겼을 때 그 장치의 모든 tag가 각각 독립 공정 알람으로 걸려 있으면 전부 한꺼번에 뜬다. 게다가 analog 값이 0으로 무너지면서 내려가는 길에 low-low 한계까지 건드리는 경우가 많다. 겉보기에는 설비 전체 비상이지만 실제로는 Ethernet 하나가 빠진 것뿐이다.
해법은 나중에 덧붙이는 suppression rule이 아니라 계층 구조다.
- PLC, RTU, gateway, skid 단위로 명확한 통신 알람 하나를 올린다.
- 그 아래 공정값은 전부 bad 또는 stale quality로 강제한다. 얼어붙은 last-good 값이 계속 한계를 판단하게 두면 안 된다.
- 통신이 나쁠 때 판단할 수 없는 파생 공정 알람은 suppress한다. IEC 62682는 이 메커니즘을 정확히 state-based suppression이라고 부른다. 임시방편이 아니라 의도적으로 쓰는 것이다.
- 데이터 소스가 정상이고 값이 실제로 refresh된 뒤에만 알람 판단을 다시 켠다.
두 번째로 데는 곳이 4번이다. Socket이 연결되자마자 켜면 오래된 buffered value를 상대로 판단해서 복구 시점에 두 번째 flood가 생긴다. 짧은 안정화 구간 — 보통 몇 초면 충분하다 — 을 둬서 driver가 중요 값을 모두 refresh한 뒤 알람이 살아나게 한다.
Suppression rule에는 주인이 있어야 한다
Flood를 줄인다고 suppression logic만 계속 추가하면 나중에 누가 왜 숨겼는지 알 수 없게 된다. 각 suppression rule에는 이유와 담당 discipline이 있어야 한다.
Rule마다 최소한 다음을 남긴다.
- Suppression을 켜는 parent condition.
- 영향을 받는 child alarm 목록.
- 자동 suppression인지, 운전원 조작인지, 정비 모드인지.
- Suppressed alarm을 event journal에 남기는지.
- 운전원이 suppression active 상태를 어디서 보는지.
- 시운전 때 어떤 방식으로 시험했는지.
다른 알람이 왜 숨겨졌는지 설명하는 parent alarm은 숨기면 안 된다. Pump trip이 low flow와 low pressure를 suppress한다면 pump trip 자체는 반드시 보여야 한다.
시운전 때 자주 잡히는 문제
다음 항목은 화면 모양보다 운전 대응에 직접 영향을 준다.
- Alarm summary가 source timestamp가 아니라 receive time으로만 정렬된다.
- First-out bit가 trip reset이 아니라 acknowledge 동작에서 지워진다.
- 같은 scan 안에서 나중 조건이 trip cause latch를 덮어쓴다.
- 통신 끊김 때 analog 값이 0으로 떨어지면서 low alarm이 대량 발생한다.
- Suppressed alarm이 모든 기록에서 사라져 사후 분석을 못 한다.
- PLC, SCADA, package HMI가 같은 조건을 각각 알람으로 만든다.
- Cause-and-effect 정리 없이 priority만 높여서 원인 알람처럼 보이게 한다.
이 문제들은 단순한 알람 정리 항목이 아니다. 운전원이 설비를 안정시키는 시간과 엔지니어가 원인을 찾는 정확도에 영향을 준다.
Flood 시험은 실제로 한 번 만들어 봐야 한다
중요 unit이나 skid마다 안전한 조건에서 controlled flood test를 한 번은 해 보는 것이 좋다.
시험 순서는 이렇게 잡을 수 있다.
- PLC, server, historian, package system의 시간이 동기화되어 있는지 확인한다.
- Safe test mode에서 알고 있는 shutdown cause를 넣는다.
- First-out 표시가 넣은 원인과 맞는지 본다.
- 후속 알람이 별도 trip cause처럼 보이지 않고 결과 알람으로 보이는지 확인한다.
- 통신 quality 알람이 공정 알람 flood로 번지지 않는지 본다.
- Event list를 export해서 timestamp, equipment name, group이 오프라인에서도 쓸 만한지 확인한다.
- Trip reset 뒤 first-out latch가 의도한 reset 동작에서만 지워지는지 본다.
- Remote I/O나 gateway가 있는 설비라면 통신 끊김 조건도 한 번 포함한다.
Export한 event file은 시운전 기록과 같이 보관한다. 나중에 실제 upset 때 알람 화면이 쓸 수 없었다는 이야기가 나오면 비교 기준이 된다.
운전 절차서에 남길 내용
Trip 중인 운전원에게 긴 control narrative를 읽으라고 할 수는 없다. 필요한 내용은 짧게 남겨야 한다.
절차서나 HMI help에는 다음을 넣는다.
- First-out 정보를 보는 화면 위치.
- 실시간 대응용 알람 화면과 event review 화면의 차이.
- Suppressed 또는 inhibited 표시의 의미.
- First-out이 trip reset, alarm reset, 별도 cause reset 중 무엇으로 지워지는지.
- 복구 중 누가 alarm shelving을 할 수 있는지.
- 어떤 통신 알람이 공정값 신뢰도를 떨어뜨리는지.
반복되는 flood가 있다면 실제 event data를 운전팀과 같이 재생해 보는 것이 가장 빠르다. 일반적인 알람 개수 목표보다, 실제 한 번의 upset을 제대로 뜯어보는 쪽이 개선 효과가 크다.