← 전체 글
알람/약 11분 읽기/ 조회

변화율 알람: High-High가 trip하기 전에 runaway를 잡는다

SCADA에서 rate-of-rise, rate-of-fall 알람 설계하기 — window 길이, 노이즈 필터링, 공학 단위, 그리고 comms 복구 때 알람이 비명 지르지 않게 하는 quality gating.

알람SCADAHMI운영문제 해결

Jacket이 달린 batch reactor가 스케줄대로 승온 중이었다 — 82°C, 분당 약 1.5°C로 올라가며 recipe curve에 정확히 붙어 있었다. 4분 뒤 148°C였고 high-high가 batch를 trip시켰다. 리뷰에서 운전자의 첫 질문. "왜 아무 경고도 안 떴죠?" 절대값 알람은 제대로 잡혀 있었다. High 130, high-high 150. Reactor가 그냥 다른 화면에 가 있던 사람이 반응할 수 있는 속도보다 빠르게 "정상"에서 "High 초과"를 거쳐 "trip"으로 가버린 것뿐이다. Threshold에는 아무 문제가 없었다. 공정은 level 알람이 볼 수 없는 걸 말하고 있었다. 온도가 어디에 있느냐가 아니라, 얼마나 빨리 움직이느냐.

바로 이게 변화율(rate-of-change) 알람이 하는 일이다. PV를 한계값과 비교하는 대신, 그 기울기 — dPV/dt — 를 한계값과 비교한다. 평소 분당 1.5°C로 승온하는 reactor가 갑자기 분당 4°C로 올라가고 있다면, 그게 90°C든 140°C든 exotherm이다. 기울기를 잡으면 절대 한계값보다 몇 분 먼저, 아직 cooling을 열거나 feed를 끊을 시간이 있을 때 경고를 받는다. ISA-18.2(IEC 62682)는 rate-of-change를 high/low, deviation과 나란히 정당한 알람 타입으로 올려놨다 — 특이한 게 아니라, 사람들이 잘못 잡아 놓고 꺼버리기 때문에 덜 쓰일 뿐이다.

어디서 값을 하나

변화율 알람은 특정한 모양의 문제에서 값을 한다. 절대 한계값은 실재하지만 느리고, 위험한 건 transient일 때.

  • Exotherm과 runaway 반응 — 온도 기울기가 가장 이른 정직한 신호다.
  • Tank 누설 — 출구 valve가 닫힘으로 지령된 상태에서 level이 분당 2%씩 떨어지는 건, "Low"가 뜨기 한참 전에 이미 누설이거나 passing valve다. 이건 어떤 level float보다 많은 spill을 막아줬다.
  • Cooling 상실 / flow 상실 — bearing 온도가 분당 3°C 오르거나 header 압력이 무너지는 건, 설비가 손상 한계에 닿기 전에 pump나 fan이 멎었다는 뜻이다.
  • 빠른 valve stroke의 압력 surge / water hammer — 다만 여기선 보통 사람이 반응할 시점을 이미 지났으므로, 변화율 알람은 기록용이고 조치는 interlock가 한다.

값을 하는 곳. 정상적으로 step하는 모든 것. Truck 배송을 받는 tank, 단계적으로 켜지는 heater, 하류 valve가 열리면 튀는 flow. 여기에 변화율 알람을 걸면 chatter만 하고, chatter하는 알람은 무시되고, 이제 운전자에게 알람 클래스 하나를 무시하도록 훈련시킨 셈이 된다. 철저해 보이려고 step 공정에 변화율 알람을 걸지 마라.

사람들이 데는 곳은 수학이다

미분은 노이즈를 증폭한다. 이건 튜닝의 불편함이 아니라 설계 제약 자체다. 온도 신호에 ±0.3°C 측정 노이즈가 있고 500 ms scan에서 scan-to-scan으로 기울기를 계산하면, 그 노이즈만으로 ±36°C/min처럼 보인다. 분당 4°C 알람이 아무것도 아닌 것에 뜬다.

그래서 절대 scan마다 rate를 계산하지 않는다. window 위에서 계산한다.

rate = (PV_now − PV_[n samples 이전]) / (window_seconds)   [분당 또는 초당 EU]

Window는 두 숫자에서 고른다. 하한은 노이즈다. 실제 움직임이 측정 노이즈 band를 넘길 만큼 window가 길어야 한다 — 괜찮은 규칙은 window ≥ sample jitter 주기의 10배, 또는 관심 있는 가장 작은 기울기가 노이즈보다 몇 배 큰 delta를 만들 만큼 길게. 상한은 응답 시간이다. 누군가 조치하기까지 excursion이 흐르도록 놔둘 수 있는 시간보다 window가 길 수 없다. 그 reactor에선 30초가 맞았다 — ±0.3°C 노이즈를 묻을 만큼 길고, 분당 4°C 상승이 30초 안에 명백해질 만큼 짧다.

평범한 windowed delta가 여전히 거칠면, 끝점 빼기 끝점 대신 window를 지나는 least-squares 직선의 기울기를 취해라. 모든 sample이 투표하므로 노이즈를 훨씬 잘 거르고, PLC 명령어 몇 개면 된다. 끝점 차이는 두 끝 사이의 모든 걸 버리고, 노이즈가 낄 수 있는 두 sample이 전체 기울기를 정하도록 믿는다. 미분-더하기-lag-필터 cascade부터 꺼내지 마라. Windowed least-squares 기울기가 노이즈 문제를 더 적은 튜닝 대상과 드리프트 없는 방식으로 푼다.

계산은 raw count가 아니라 공학 단위로 하고, 사람이 trend에서 읽어내는 단위로 알람을 서술해라 — °C/min, %/min, kPa/s. "Rate high, 320 counts/scan"은 유지보수가 안 된다. "Reactor 온도 상승 >3°C/min"은 운전자와 공정 엔지니어가 놓고 논쟁하고 합의할 수 있는 값이다.

SCADA 말고 PLC에서 계산해라

Rate 계산은 시간으로 나눈다. 그러니 나누는 그 시간만큼만 정확하다. SCADA polling에는 jitter가 있다 — 1초마다 오도록 되어 있는 poll이 실제로는 네트워크와 부하에 따라 0.9~1.4초 간격으로 도착한다. 그 흔들리는 dt를 나눗셈에 넣으면 순수 타이밍 노이즈에서 rate 스파이크를 만들어낸다. PLC에는 결정론적 scan과 진짜 clock이 있다. delta와 나눗셈을 거기서 하고, rate를 자체 analog tag로 publish하고, 그 tag를 다른 analog처럼 SCADA에서 알람 걸어라. Trend와 historian에 rate가 공짜로 들어오는 건 덤인데, threshold를 튜닝할 때 실제로 쓰게 될 게 바로 그거다.

변화율 알람이 비명 지르게 만드는 것 — 그리고 그걸 잠재우는 법

변화율 알람이 금지당하는 실패 모드는 가짜 step이다. 신호의 모든 불연속은 무한 기울기처럼 보인다.

  • Comms 복구. Link가 끊기면 tag가 마지막 값을 붙들고, comms가 돌아오면 PV가 지금-참값으로 튄다. 그 점프가 거대한 가짜 rate다. 계산을 quality로 gate해라. Window 안의 sample 중 하나라도 bad면 rate 출력을 freeze하고 알람을 off로 붙들어라. 그리고 quality가 good으로 돌아온 뒤에도 최소 window 길이 한 번만큼은 rate 알람을 억제해라. 그래야 stale-to-fresh 점프가 window에서 빠져나간 뒤에 기울기를 신뢰한다.
  • Range나 scaling 변경, 센서 교체, 수동 강제값 — 같은 문제, 같은 해법. 전환 시 억제해라.
  • Bad-quality freeze. PV가 상수에 얼어 있으면 rate가 0이고 알람은 조용하다 — 그건 괜찮지만, "rate 정상"을 "공정 정상"으로 읽지 마라. 얼어붙은 tag는 자체 stale/quality 알람이 필요하다. 변화율 알람은 comms watchdog가 아니다.

짧은 on-delay도 넣어라 — 깨끗하지만 짧은 스파이크 하나가 annunciate하지 않도록 몇 초의 persistence를. 그리고 rate-of-rise와 rate-of-fall을 각자의 threshold를 가진 별개의 알람 두 개로 돌려라. 너무 빨리 승온하는 reactor와 너무 빨리 냉각되는 reactor는 다른 대응이 필요한 다른 사건이고, 한계값을 공유하는 일은 거의 없다.

Runaway 없이 threshold 잡기

실제 exotherm을 연출해서 알람을 튜닝할 수 없고, 그러고 싶지도 않을 거다. 대신 historian을 당겨라. 최근 정상 batch 열몇 개를 trend해서 실제 승온 기울기와 그 산포를 읽고, 이론상 최대값이 아니라 최악의 정상 rate보다 명확한 여유를 두고 알람을 잡아라 — commissioning 이후 아무도 안 믿는 P&ID의 숫자 말고. 그다음 archive에서 과거 upset 하나를 찾아 겹쳐 보고, threshold가 의미 있는 lead time을 두고 그걸 잡았을지 확인해라. Plant에 그 upset이 한 번도 없었다면, 그 숫자는 추정치라고 정직하게 말하고 threshold를 운전자가 첫 실제 사건 뒤에 따질 수 있는 자리에 남겨둬라 — 그게 결국 유일하게 중요한 시험이다.