Cooling pump의 low-flow 알람이 한 shift에 41번 떴다. 운전자의 수정 요청은 한 줄이었다. "delay 좀 넣어 주세요." 3초 on-delay를 넣으니 chatter가 멈췄다. 그런데 누가 그 delay를 같은 pump의 seal-fail 알람에도 복사해 넣었고, 이제 pump는 경고가 화면에 뜨기도 전에 trip한다. 알람 timer의 문제가 이 한 문장에 다 들어 있다 — 노이즈를 없애는 knob이 첫 실제 경고도 숨길 수 있고, 그게 같은 knob이다.
Alarm delay는 운전자가 언제 조치해야 하는지를 바꾼다. 그래서 이건 현장에서 그때그때 만지는 화면 설정이 아니라 알람 설계의 일부다. ISA-18.2(IEC 62682로 발행)는 delay-on, delay-off, deadband를 rationalization 단계에서 정하는 알람 속성으로 다룬다. 그날 짜증 난 사람이 즉석에서 돌리는 값이 아니다. Timer를 잡기 전에 다섯 가지 질문을 넘겨야 한다.
- 어떤 현장 조건을 걸러내려는 것인가.
- 그 조건이 몇 초 이상 지속돼야 누군가 조치해야 하는가.
- Timer 주체가 PLC인지, SCADA server인지, alarm 서브시스템인지.
- Alarm 발생에 적용되는지, 복귀에 적용되는지, 둘 다인지.
- 통신 끊김, mode 변경, PLC restart 때 timer가 어떻게 되는지.
여기에 답하지 못하면 그건 엔지니어링이 아니다. Switch, threshold, deadband에서 고쳤어야 할 nuisance alarm을 덮고 있는 것이다.
애초에 이게 왜 문제냐면, EEMUA 191은 정상 운전 중 장기 평균 알람률 목표를 운전자당 10분에 1건 미만으로 잡고, ISA-18.2의 metric도 비슷하다. 이 값을 한 자릿수 이상 넘기면 운전자는 알람 목록을 안 읽는다. 그래서 원인을 고치는 대신 delay로 알람률을 묻어 버리려는 유혹이 늘 생긴다. Delay는 첫 번째 도구가 아니라 두 번째 도구다.
Debounce, on-delay, off-delay를 구분한다
시운전 중에는 이 용어가 섞여 쓰이는 경우가 많다. 하지만 해결하는 문제가 다르다.
| Timer 종류 | 쓰는 곳 | 주의할 점 |
|---|---|---|
| Input debounce | 접점 bounce나 discrete input 흔들림 제거 | 가능하면 입력에 가까운 쪽에서 처리한다 |
| Alarm on-delay | 비정상 조건이 일정 시간 지속될 때 알람 발생 | 짧지만 중요한 event를 숨길 수 있다 |
| Alarm off-delay | 조건이 사라진 뒤 알람을 잠시 유지 | 간헐 fault를 보기 쉬워진다 |
| Return-to-normal delay | 알람 목록에서 정상 복귀를 늦춤 | 운전자가 이유를 모르면 혼란스럽다 |
| Command feedback timeout | 명령 후 field feedback이 따라오지 않음을 검출 | 알람 debounce와 같은 기능이 아니다 |
진동하는 level switch에는 input debounce가 필요하다. Pump start 중 low flow에는 on-delay가 필요하다. Valve travel fault에는 command feedback timeout이 필요하다. 이 세 가지에 같은 global delay를 넣으면 각각 다른 방식으로 잘못 동작한다.
Timer 논쟁에서 자주 빠지는 게 하나 있다. Analog 알람에서는 timer가 돌기 전에 deadband가 anti-chatter 작업의 대부분을 한다. High setpoint 바로 위에서 0.3% 노이즈로 흔들리는 level transmitter는 알람을 분당 수십 번 toggle하는데, delay는 그 toggle을 시간축으로 뭉갤 뿐이고 deadband는 아예 멈춘다. 시작값은 flow는 range의 5%, pressure는 2%, temperature는 1% 정도이고, 노이즈가 크다고 아는 신호는 거기서 넓힌다. Deadband를 먼저 잡고, 남는 흔들림을 재고, 그다음에 timer가 필요한지를 판단한다.
빠른 보호 로직은 PLC에 둔다
설비를 보호하거나 사람 안전과 관련된 조건은 HMI나 SCADA alarm delay에 맡기면 안 된다. Motor를 세우거나, heater를 차단하거나, valve를 닫아야 하는 판단은 PLC, safety PLC, drive, protection relay 쪽에 있어야 한다.
SCADA alarm timing은 운전자 통보와 event 정리에 유용하다. 보호 동작의 유일한 판단 지점이 되면 안 된다.
중요 신호는 두 층을 따로 문서화한다.
- Controller 안의 protective trip logic과 scan time.
- Alarm server의 운전자 알람 timing.
- 나중에 원인 분석할 historian sampling 또는 event 저장.
- Timing 중 HMI에 보이는 상태.
이걸 정리하지 않으면 인수인계 때 자주 문제가 생긴다. HMI warning alarm에는 10초 delay가 있는데 PLC trip은 delay가 없어서, 운전자는 warning을 보기 전에 설비 정지를 먼저 보게 된다.
Delay 값은 공정 동작에서 정한다
다른 프로젝트의 기본값을 복사하기 전에 설비가 실제로 어떻게 움직이는지 봐야 한다.
예를 들면 다음과 같다.
- Pump low discharge pressure는 startup 중 배관이 차는 동안 delay가 필요할 수 있다.
- Compressed air low pressure는 하위 장비 fault가 빨리 오므로 짧은 delay만 허용될 수 있다.
- Tank high level warning은 운전자 대응 시간보다 늦게 뜨면 의미가 없다.
- Conveyor jam photoeye는 제품 흔들림을 걸러야 하지만, 긴 delay는 제품 손상을 키울 수 있다.
- 느린 vessel temperature high는 process lag가 크고 노이즈가 작아서 긴 debounce가 필요 없을 수 있다.
각 알람에서 delay를 운전자 대응 시간과 consequence까지 남은 시간의 합과 비교한다. 내 기준은 이렇다. On-delay는 알람부터 consequence까지 시간의 약 3분의 1 아래로 두고, delay와 대응 시간을 더한 값이 그 시간을 넘지 않게 한다. High level 뜨고 90초 뒤에 tank가 넘치고 운전자 대응에 30초가 걸리는데 60초짜리 "debounce" delay를 넣으면, 그건 노이즈를 거르는 게 아니라 overflow를 보장하는 것이다. 신호가 그렇게 노이즈가 크면서 빠르면, 답은 delay를 더 넣는 게 아니라 deadband거나 sensor 위치를 바꾸는 것이다.
운전에 필요한 timer 상태는 화면에 보인다
모든 내부 counter를 HMI에 보여줄 필요는 없다. 하지만 왜 아직 알람이 안 떴는지, 왜 조건이 풀렸는데 알람이 남아 있는지는 운전자가 이해할 수 있어야 한다.
현장에서 도움이 되는 표시가 있다.
- Pump, fan, compressor faceplate의 "start delay active" 상태.
- Valve나 damper의 travel timeout 남은 시간.
- 접점 chattering 때문에 input debounce가 동작 중임을 보여주는 diagnostic bit.
- Alarm detail에 delay 값과 적용 조건 표시.
- Maintenance 화면에서 raw input, filtered input, alarm state를 나란히 표시.
운전자가 "알람이 랜덤으로 뜬다"고 말할 때 실제로는 랜덤이 아닌 경우가 많다. Timing rule이 화면에 안 보이는 것이다.
Delay stacking을 조심한다
Delay stacking은 여러 층에서 조금씩 delay를 더했는데 전체 시간을 아무도 보지 않는 상태다.
한 신호 경로가 이렇게 될 수 있다.
- Remote I/O module의 field switch debounce.
- PLC input filter.
- PLC alarm on-delay.
- OPC UA 또는 Modbus polling interval.
- SCADA alarm delay.
- Alarm notification 또는 paging delay.
각 항목은 따로 보면 합리적일 수 있다. 합치면 2초짜리 이상 상태가 20초 뒤 운전자 통보로 바뀐다. 시운전 때 raw input, PLC alarm bit, SCADA alarm, operator notification의 timestamp를 같이 찍어 본다. 설정값을 읽는 것보다 실제 chain을 재는 쪽이 정확하다.
통신 끊김은 별도 조건으로 본다
Communication loss는 process alarm과 같은 timer 가정으로 처리하면 안 된다. PLC link가 bad인데 마지막 level switch 값이 normal이었다고 해서 현재도 normal로 증명된 것은 아니다. Alarm server가 timeout 중 last value를 유지하면 delayed alarm 동작이 이상하게 보일 수 있다.
다음 경우를 따로 정의한다.
- Alarm 조건이 true 되기 전에 bad quality가 들어온 경우.
- Alarm delay가 진행 중일 때 bad quality가 된 경우.
- Alarm active 후 통신이 끊긴 경우.
- Timer가 0이 아닌 상태에서 PLC가 restart된 경우.
- Redundant server failover 중 delayed alarm이 있는 경우.
중요 알람은 실제로 통신을 끊어서 확인한다. Vendor default 설명만 믿고 넘기면 운영 중에 다른 결과가 나온다.
시운전에서 재야 할 항목
Timed alarm은 작은 시험표를 만들어 확인하는 것이 좋다. 정상 timing과 비정상 timing을 둘 다 본다.
- Field 조건에서 raw input이 기대대로 바뀌는지 확인한다.
- PLC tag에서 debounce 또는 filter 시간을 잰다.
- Delay보다 짧은 pulse를 넣고 operator alarm이 생기지 않는지 본다.
- 조건을 delay보다 오래 유지하고 timestamp, priority, message를 확인한다.
- 조건을 해제하고 off-delay 또는 return-to-normal 동작을 본다.
- PLC나 alarm service를 restart해 false alarm이 생기거나 기존 조건이 숨지 않는지 본다.
- 나중에 alarm review에서 설명할 수 있도록 historian event를 확인한다.
가능하면 화면을 보며 초를 세지 말고 log timestamp로 측정한다.
자주 보는 실패
- 모든 알람에 global 5초 delay를 넣어서 빠른 equipment fault까지 늦어진다.
- Loose switch, threshold 오류, deadband 오류를 고치지 않고 delay만 늘린다.
- SCADA에는 alarm delay가 있는데 PLC event와 historian sequence는 다른 순서로 남는다.
- Off-delay 때문에 복구 후에도 알람이 남아 있는데 HMI에 설명이 없다.
- Bad quality가 input을 freeze해서 진행 중인 delayed alarm이 끝나지 않는다.
- Restart가 timer를 지우면서 이미 비정상이던 조건을 숨긴다.
- Notification delay를 고려하지 않아 이미 사라진 알람이 한참 뒤 pager로 간다.
인수인계 때 남길 것
Timer가 있는 알람은 숫자만 남기면 부족하다. 왜 그 값인지, 누가 owner인지, 어떤 시험을 통과했는지, 나중에 어느 범위까지 바꿔도 되는지를 같이 남긴다. 작은 pump skid에서 맞던 timer가 더 큰 설비에서는 fill time, valve stroke time, trip consequence 차이 때문에 위험할 수 있다.
좋은 alarm timing은 알람 시스템을 조용하게 만들지만, 설비 상태를 덜 보이게 만들지는 않는다.