민원은 보통 이렇게 온다. "HMI가 설비 fault를 놓쳤으니 tag를 더 빠르게 만들어라." 누군가 poll rate를 500 ms에서 250 ms로 내리면 화면 숫자가 조금 더 자주 깜빡이고 다들 안심한다. 그러다 또 fault를 놓친다. 그 fault가 한 scan짜리 pulse였기 때문이다. 20 ms 정도 켜졌다 꺼지는 신호를 250 ms로 폴링하면 여전히 12배 느리다. PLC가 잡아 두지 않은 pulse는 폴링 속도로 이길 수 없다.
빠르게 만드는 건 잘못된 손잡이다. 진짜 질문은 세 가지 시간 중 무엇과 싸우고 있느냐다.
- 값을 만드는 PLC scan 또는 task 주기.
- 그 값을 SCADA로 읽는 driver poll 주기.
- 그 값을 쓰는 HMI / alarm / historian 주기.
세 시간이 우연히 같은 나쁜 시점만 sample하면 tag가 멀쩡하게 보인다. 세 개를 다 알기 전까지는 눈 감고 튜닝하는 셈이다.
Pulse 문제는 poll rate 문제가 아니라 PLC 문제다
Reject kick, 불량 flag, 순간 interlock처럼 한 scan만 true인 bit는 어떤 SCADA poll rate로도 못 잡는다. Scan time이 10 ms면 그 bit는 10 ms 동안만 존재하고, 250 ms poll은 대략 25 scan에 한 번 그 자리를 본다. SCADA는 pulse를 감시하는 게 아니라 pulse가 지나간 자리를 가끔 훔쳐보는 것이다.
해결은 PLC 쪽이고, 방법은 넷 중 하나다.
- Latch — SCADA가 읽고 clear할 때까지 잡아 둔다(handshake bit). 놓치면 안 되는 신호에 가장 안전하다.
- Count — totalizer로 세서, edge를 쫓는 대신 누적값을 읽는다.
- Stretch — TON/TOF one-shot으로 flag를 500 ms쯤 붙잡아 일반 poll이 잡게 한다.
- Timestamp — PLC에서 시간을 찍어 sequence-of-events 기록으로 올린다. Poll이 늦어도 event 시간은 살아남는다.
SCADA 주기를 건드리기 전에 값이 어디서 태어나는지 확인한다. Continuous task, periodic task(주기는?), comms task 중 어디인가? 별도 통신 buffer로 자기 주기에 복사되는가? 중간에 produced/consumed tag, gateway, protocol 변환이 있는가? 이중화 hot-standby 쌍이라면 쌍이 동기화된 상태에서 최악 scan time을 재라 — 크로스로드가 이를 부풀리고, poll이 경쟁하는 값이 바로 그 숫자다.
전체 하나의 rate는 냄새가 난다
Project 전체를 한 poll rate로 맞췄다면 아무도 group을 나누지 않았다는 신호다. Overview 화면의 pump running bit와 한 scan짜리 reject pulse는 다른 짐승이고, 같은 대접을 원하지 않는다. 내가 쓰는 대략적인 출발점이고, 이후엔 측정으로 튜닝한다.
| Tag 종류 | 출발 rate | 함정 |
|---|---|---|
| Operator status / feedback | 500 ms ~ 2 s | 살아 있는 느낌엔 충분, sequence 증명엔 절대 부족 |
| Analog process value | 1 s ~ 5 s | 화면 frame rate가 아니라 loop 변화 속도에 맞춘다 |
| Alarm | protocol이 되면 event 기반 | rate를 믿기 전에 delay/latch logic부터 확인 |
| Total / counter | 1 s ~ 10 s 또는 event 기반 | 짧은 pulse 말고 totalizer를 믿는다 |
| Maintenance diagnostic | 5 s ~ 60 s | 아무도 안 여는 값에 bandwidth 쓰지 않는다 |
| Historian 전용 | 분석 목적에 맞춰 | HMI refresh와 완전히 분리 |
설정 rate는 약속이 아니라 요청이다
입력한 poll interval은 SCADA가 요청하는 값이다. 실제로 받는 값은 driver scheduling, packet 크기, route latency, retry, group 안 tag 수에 달렸다. Modbus TCP device의 tag 40개가 비연속 register에 흩어져 있으면 gigabit switch에서도 느리다. Gap마다 별도 read transaction이 생기기 때문이다. 연속 block으로 묶는 것이 interval을 줄이는 것보다 대부분 더 효과가 크다.
그래서 시운전 때는 설정 화면을 믿지 말고 driver 자체 숫자를 본다.
- Actual group scan time — engineering laptop 하나가 아니라 실제 HMI client가 모두 붙은 정상·peak 부하에서.
- Missed poll, timeout count, reconnect count.
- PLC 통신 CPU 부하(보여 주는 platform이 많다).
- 경로 전체 — remote I/O, serial gateway, radio link, VPN 구간 모두 timing 예산 안에 있다.
모든 tag를 "fast" group으로 옮긴 날 gateway가 불안정해지는 걸 여러 번 봤다. Tag가 빨라진 게 아니라 gateway가 모두에게 느려진 것이다.
화면 refresh와 데이터 수집은 다른 일이다
Operator는 화면이 현재처럼 느껴지길 원한다. 그렇다고 모든 값을 display frame rate로 PLC에서 읽어야 하는 건 아니다. HMI는 마지막 값을 그리고, 수집은 자기 일정으로 돌리면 된다. 그래서 나눈다.
- Fast group — command feedback, permissive, 지금 직접 몰고 있는 sequence state.
- Normal group — overview indicator, 일반 analog.
- Slow group — maintenance counter, nameplate, config echo.
- On-demand / screen-active — 열려 있을 때만 poll하는 상세 진단 화면.
Screen-active polling의 함정 하나: alarm이나 interlock이 그 tag에 의존한다면, 진단 화면을 닫았다고 수집에서 빠지면 안 된다. 아무도 안 본다고 alarm 감시가 멈춰도 되는 건 아니다.
Historian은 따로 결정한다 — polling과 뭉뚱그리지 마라
Historian collection과 SCADA polling을 한 설정으로 취급하는 경우가 정말 많은데, 둘은 다르다. Historian은 들어온 값만 저장하지만, polling된 모든 sample을 저장하는 게 좋은 경우는 드물다. 따로 정한다. Connector가 source를 읽는 주기, 그리고 저장 방식 — exception, deadband, swinging-door 압축, fixed interval 중 무엇인가.
Energy, flow, production total은 빠른 순간값보다 신뢰할 수 있는 누적값이 항상 낫다. 나중에 적분해서 서로 다투느니 counter를 원한다. State timeline은 주기 sample이 모든 변화에 걸리길 비는 대신 전환 시점과 timestamp를 깨끗이 남긴다. Report가 shift/일 경계에서 경계 계산을 한다면 interpolation 여부를 미리 정해라 — 이 불일치가 historian total과 MES total이 안 맞는 이유다.
잘못되면 다른 문제처럼 보인다
Polling 문제는 거의 polling 문제 얼굴로 오지 않는다.
- HMI가 짧은 fault를 놓친다 → PLC가 latch를 안 했다.
- Trend가 계단으로 그려진다 → 값이 chart period보다 느리게 갱신된다.
- 조작이 지연으로 느껴진다 → feedback이 slow group에 있다.
- Alarm timestamp가 PLC SOE 기록과 다르다 → SCADA가 event가 아니라 poll 시간을 찍었다.
- Historian과 MES total이 다르다 → reset 시점과 sample 시점이 섞였다.
유일한 방법은 각 layer의 timestamp를 나란히 잡는 것이다. PLC event time, driver update time, alarm time, historian time, report time. 다 맞으면 아무것도 못 찾은 것이고, 하나가 어긋나면 그게 문제의 layer다.
어떤 신호든 "이건 sampled인가, event 기반인가, PLC가 latch하는가?"에 설계가 답하지 못하면 그 구멍부터 메워라. Tag마다 답이 정해지면, 다음 성능 민원이 모든 걸 빠르게 만드는 핑계가 되는 일이 멈춘다.