여섯 시간 동안 완전히 평평하던 트렌드가 한 sample 만에 40% 튄다면, 그건 거의 공정이 아니다. 이벤트 하나를 놓쳤거나, buffer 처리가 틀렸거나, source time이 아니라 receive time으로 찍힌 report-by-exception 경로다. 운전자가 "왜 탱크가 갑자기 찼냐"고 물을 때쯤이면 증거는 이미 queue 세 개 뒤로 넘어가 사라진 상태다.
Report-by-exception(RBE)은 값이 의미 있게 변했을 때만 장치, 게이트웨이, 드라이버가 SCADA로 갱신을 보내는 방식이다. Digital point에서는 change-of-state(COS)라고 부른다. Bit가 0↔1로 바뀌는 순간을 이벤트로 보낸다. DNP3(IEEE 1815)에서는 Class 1/2/3 event data와 unsolicited response가 바로 이걸 위한 구조이고, Modbus에는 이런 게 없다. 그래서 poll 드라이버에 deadband를 억지로 붙여 놓고 왜 동작이 다르냐고 되묻게 된다.
실제로 다르다. 가장 흔한 착각이 RBE를 "메시지 적은 polling"으로 보는 것이다. Polling은 stateless라서 한 번 놓쳐도 다음 scan이 바로잡는다. RBE는 stateful이다. 이벤트 하나를 놓치면 다음 실제 변화가 올 때까지 틀린 값이 HMI에 그대로 남는데, 차단기 상태라면 그게 다음 달일 수도 있다. 모든 transition을 보존하고, timestamp를 제대로 찍고, 네 시간 동안 말이 없는 point가 죽은 게 아니라 살아 있다는 것까지 증명해야 한다.
어떤 태그에 쓸지 먼저 나눈다
RBE를 모든 태그에 한꺼번에 켜면 나중에 원인 분석이 어려워진다. 운전자가 반드시 봐야 하는 변화인지, 생산 기록에 남아야 하는 변화인지 먼저 구분한다.
| 태그 종류 | RBE 적용이 잘 맞는 경우 | 조심할 부분 |
|---|---|---|
| 설비 digital 상태 | Run, stop, open, closed, fault bit | 짧은 pulse, 접점 chatter, interlock bit |
| Analog 공정값 | 천천히 변하는 level, temperature, pressure | 빠른 loop, 순간 excursion, vibration |
| Counter와 total | Batch count, energy total, runtime | Rollover, reset, 누락된 increment |
| Alarm | Alarm set, clear event | 순서, 중복 clear, shelving 상태 |
| 통신 상태 | Link up/down, device online | 값 변화가 없어도 heartbeat 필요 |
짧게 말하면, 한 번 놓쳤을 때 운전 판단이나 생산 이력이 달라지는 변화는 반드시 실제 시험을 해야 한다.
조용한 값과 정상 통신은 다르다
값이 안 변한다고 통신이 정상이라는 뜻은 아니다. 원격 탱크 레벨이 네 시간 동안 그대로일 수 있다. 동시에 무선 링크가 네 시간 전에 끊겼을 수도 있다.
그래서 값 변화와 별개로 heartbeat나 통신 품질 태그를 둔다.
- 장치 sequence number가 일정 주기로 증가한다.
- Gateway가 link status와 last-good timestamp를 올린다.
- SCADA driver가 장치별 last update time을 기록한다.
- RTU가 값 변화가 없어도 주기적으로 integrity scan에 응답한다.
- 기대 시간 안에 update가 없으면 stale alarm을 낸다.
운전자가 flat한 process value를 보고 통신 상태까지 추측하게 만들면 안 된다. Last-good value와 현재 품질을 화면에서 분리해 보여줘야 한다.
Deadband는 공정 기준으로 잡는다
Analog RBE는 deadband로 동작한다. 값이 설정 폭보다 더 움직이면 보낸다. 숫자를 논하기 전에 어떤 종류의 deadband인지부터 알아야 한다. OPC UA(part 4, DataChangeFilter)의 DeadbandType은 Absolute와 Percent가 있는데, 여기서 Percent는 현재 값이 아니라 그 항목의 EU range에 대한 퍼센트다. 이걸 자주 헷갈린다. DNP3 analog change event(Group 32)는 outstation에 설정한 point별 deadband register로 동작한다. 이 폭은 네트워크 불안이 아니라 공정 의미로 정한다.
- 저장 탱크 레벨은 0.5% deadband로 충분하다. 슬러지 2 mm에 반응하는 사람은 없다.
- Alarm setpoint 근처의 반응기 온도는 0.1 °C가 필요할 수 있고, last-good 값이 조용히 늙지 않도록 주기 확인도 둔다.
- 압축공기 header는 low pressure trip 근처에서 촘촘히 보고, 그보다 한참 위에서는 느슨해도 된다.
- 노이즈가 많은 4–20 mA 신호는 deadband 앞에서 필터링한다. 노이즈를 덮으려고 deadband를 키우면 잡으려던 3% excursion도 같이 삼킨다.
Deadband를 넓게 잡는 유일한 근거가 "네트워크가 바쁘다"라면, 그건 deadband로 위장한 scan 설계·data grouping 문제다. 용량을 고쳐라. 필요한 움직임을 숨기는 deadband는 대역폭을 아끼는 게 아니라, 여섯 달 뒤 평평한 트렌드를 분석할 사람에게 비용을 떠넘길 뿐이다.
순서와 시간을 같이 남긴다
RBE 데이터는 여러 queue를 지난다. Field device buffer, radio master, protocol gateway, SCADA driver, historian interface, alarm service를 차례로 통과할 수 있다. 도착 순서가 실제 발생 순서와 다를 수 있다.
유용한 기록을 만들려면 최소한 다음 항목이 필요하다.
- 현장 장치가 변화를 감지한 source timestamp.
- SCADA나 gateway가 받은 receive timestamp.
- 값과 품질.
- 가능하면 sequence number 또는 event number.
- 이벤트를 만든 장치와 통신 채널.
Source timestamp를 믿을 수 있다면 히스토리언에는 그 시간을 저장하는 편이 좋다. Receive time만 저장하는 구조라면 그 한계를 문서에 남겨야 한다. 통신이 끊겼다가 복구되면 buffer에 있던 이벤트가 한꺼번에 들어오는데, source time이 없으면 공정이 갑자기 튄 것처럼 보인다.
짧은 pulse와 chatter를 꼭 시험한다
RBE에서 가장 자주 놓치는 것은 짧은 digital 변화다. Motor overload bit가 300 ms 켜졌다 꺼질 수 있다. Limit switch가 튈 수 있다. PLC one-shot은 한 scan만 존재할 수 있다. 무선 gateway는 여러 변화를 묶어서 나중에 보낼 수 있다.
시운전 때는 다음 상황을 실제로 만들어 본다.
- 정상 상태 변화가 충분히 오래 유지되는 경우.
- 일반 polling 주기보다 짧은 pulse.
- 정해진 횟수만큼 빠르게 on/off 되는 chatter.
- 네트워크 단절 중 발생한 변화.
- Gateway queue가 거의 찬 상태에서 발생한 변화.
- Point가 active인 상태에서 장치가 restart되는 경우.
각 시험마다 PLC 또는 RTU 기록, SCADA alarm/event list, 히스토리언 sample, HMI 화면을 맞춰 본다. 같은 사건을 네 군데에서 설명할 수 있어야 한다.
복구용 integrity scan을 둔다
Event-driven 방식이라도 전체 상태를 다시 읽어야 한다. DNP3에서는 이게 integrity poll, 즉 현재 static 값을 돌려주는 Class 0 read다. Master는 이걸 startup 때, 그리고 outstation의 restart IIN bit(IIN1.7, "device restart")나 event buffer overflow 표시를 볼 때마다 던져야 한다. 이 과정이 없으면 SCADA는 오래된 값을 계속 들고 있는다. 바로잡을 새 변화가 영영 안 오기 때문이다.
탱크 레벨에서는 성가신 정도지만 alarm과 permissive에서는 위험하다. 링크가 끊긴 동안 set됐다 clear된 fault bit는 화면에 아예 안 나타나고, 더 나쁘게는 outage 중에 clear된 fault가 HMI에 active로 latch된 채 남아서, 운전자가 멀쩡한 설비를 못 돌리거나 반대로 안 멀쩡한 설비를 믿게 된다.
현장에서 쓰기 좋은 복구 흐름은 다음과 같다.
- 통신이 끊기면 관련 point를 uncertain 또는 stale로 표시한다.
- 프로토콜이 지원하면 이벤트를 buffer에 저장한다.
- 재접속 후 현재 상태를 다시 읽는다.
- Buffer 이벤트와 현재 상태를 맞춰 본다.
- 데이터가 불완전할 수 있으면 운전자에게 통신 이벤트로 알린다.
자주 보이는 고장 형태
| 증상 | 가능성 높은 원인 | 확인 방법 |
|---|---|---|
| 정전 구간 트렌드가 평평하다가 한 번에 튄다 | Source time이 아니라 receive time으로 저장됨 | Source timestamp와 archive timestamp 비교 |
| Alarm set은 없고 clear만 남는다 | 짧은 pulse 또는 queue 손실 | PLC event counter와 driver diagnostic 비교 |
| RTU restart 후 HMI 상태가 예전 값이다 | Integrity scan 없음, stale 품질 처리 부족 | Restart 시험 중 quality 변화를 본다 |
| 생산 count보다 SCADA counter가 낮다 | Increment 누락 또는 rollover 처리 오류 | Local counter와 rollover 시험 비교 |
| 네트워크는 안정됐는데 이벤트가 계속 빠진다 | Gateway queue 또는 SCADA event thread 과부하 | Queue depth, discard counter, CPU, log 확인 |
인수인계에 남길 내용
RBE 채널마다 짧게라도 다음 내용을 남긴다.
- RBE 또는 COS를 쓰는 point 목록.
- Deadband와 최소 reporting interval.
- Heartbeat 또는 integrity scan 주기.
- Timestamp 기준과 time zone 규칙.
- Buffer 용량과 overflow 동작.
- SCADA로 올린 diagnostic tag.
- 짧은 pulse, disconnect, reconnect, restart 시험 결과.
"RBE 사용"이라는 한 줄보다 이런 기록이 훨씬 쓸모 있다. 다음 엔지니어는 이 시스템에서 실제로 검증된 동작이 무엇인지 바로 알 수 있다.