PubSub는 Client Session이 아니다 — 그렇게 디버깅하면 안 된다
Subscriber HMI에 모터가 47 degC로 부드럽게 갱신되며 돌아가고 있다. 그런데 Publisher Gateway는 6분 전에 꺼졌다. 아무도 알아채지 못한다. UDP PubSub로 채운 Last Value 화면에는 끊어질 Session이 없기 때문이다. 마지막으로 Decode한 Datagram을 계속 다시 그릴 뿐이다.
이게 OPC UA PubSub의 함정이다. 표준(OPC UA Part 14, UDP 위의 UADP Message)상 Publisher는 DataSetMessage를 네트워크로 뿌리고 어떤 Subscriber든 그것을 Decode한다. Session Keepalive도, Browse 단계도, Publisher 쪽 Subscriber별 상태도 없다. 여러 Consumer가 같은 Live Data를 받아야 할 때 이 낮은 오버헤드 때문에 PubSub을 고른다. 그리고 바로 그 이유로 익숙한 문제 해결 감각이 통하지 않는다.
값이 틀리거나 안 보여도 가리킬 Session 오류가 없다. 원인은 Publisher 설정, Dataset Field 순서, Multicast 차단, VLAN, Subscriber 방화벽, Clock 오차, Decode 불일치까지 넓어진다. OPC UA Client가 아니라 산업용 네트워크 인터페이스처럼 시운전한다. packet path, message schema, data meaning을 이 순서대로 세 단계로 나눠서 증명해야 한다.
Consumer를 붙이기 전에 Dataset 계약부터 고정한다
PubSub Subscriber는 보통 고정된 Dataset 정의에 의존한다. Publisher가 Field 순서, 이름, Data Type, Metadata Version을 바꾸면 UDP Packet은 계속 들어오는데 Tag Mapping만 조용히 틀어질 수 있다.
시운전 전에 아래 정도는 표로 남긴다.
| 항목 | 예 | 확인 이유 |
|---|---|---|
| PublisherId | Line3GatewayA | 같은 네트워크의 다른 Publisher와 구분한다. |
| WriterGroupId / DataSetWriterId | 10 / 2 | Subscriber가 받을 Stream을 고른다. |
| Dataset 이름 | Line3.PackML.Status | 현장 점검 때 사람이 찾기 쉽다. |
| Field 순서 | State, Mode, GoodCount, RejectCount | 한 칸 밀린 Mapping을 막는다. |
| Data Type과 단위 | UInt16, Int32, degC, bar | HMI 표시와 Historian 저장 오류를 줄인다. |
| Metadata Version | 2026-06-29.1 | 모르는 Layout을 Subscriber가 거부할 수 있다. |
Publisher 화면 캡처만 믿으면 부족하다. 가능하면 설정 Export 파일이나 형상관리 기록을 남긴다. 나중에 Gateway 교체나 Firmware Update 때 이 표가 기준이 된다.
PubSub 장애는 대개 OPC UA 옷을 입은 네트워크 장애다
현장에서 쫓아다닌 UDP PubSub 문제는 OPC UA 문제가 아니라 네트워크 문제인 경우가 많았다. Publisher는 정상 송신 중인데 Subscriber VLAN에서 Multicast가 막혀 있거나, IGMP Snooping은 켜져 있는데 Querier가 없어서 Group이 정리되고 Switch가 조용히 전달을 멈춘 경우다. UDP 위의 UADP는 보통 Multicast로 도는 만큼, 이건 마지막이 아니라 가장 먼저 의심할 장애 모드다.
Application을 보기 전에 다음을 확인한다.
- Multicast Group Address와 UDP Port
- Publisher가 사용하는 Network Interface
- Subscriber Interface와 Route Table
- Publisher, Switch, Subscriber의 VLAN Membership
- IGMP Snooping과 Querier 설정
- Subscriber 장비의 Inbound UDP 방화벽
- Capture 시 Mirror Port가 실제 Traffic을 보여주는지
- Storm Control이 Burst를 Drop하지 않는지
첫 시험은 Publisher Port와 Subscriber Port에서 동시에 Capture한다. Publisher에서는 Packet이 보이는데 Subscriber에서 안 보이면 Network Layer에 머문다. Subscriber까지 Packet이 오는데 값이 안 바뀌면 Dataset Decode를 본다.
Packet Capture는 Frame이 있다는 것이지, 받아들였다는 게 아니다
Packet Capture는 UDP Frame이 있다는 사실만 알려 준다. Subscriber가 그 Message를 받아들였는지는 별도 진단이 필요하다.
Subscriber 쪽에는 최소한 이런 값이 있어야 한다.
- 마지막 Message 수신 시각
- Sequence Number 또는 Message Counter
- Drop, Out-of-order Count
- Metadata Mismatch Count
- Field Decode Error
- 가능하면 Publisher State
- Dataset별 Last Good Timestamp
시운전 중에는 임시 진단 화면이나 Log를 켜 둔다. Packet이 아예 없는지, Packet은 있는데 거부하는지, 정상 Decode는 되지만 Quality가 Bad인지 구분되어야 한다.
가장 위험한 상태는 오래된 값을 Live처럼 보여주는 것이다. Dataset마다 Age Check가 있어야 한다. 정해진 시간 안에 Message가 안 오면 Quality를 Bad 또는 Stale로 바꾸고 HMI에서 보이게 해야 한다.
Timing은 Packet 주기가 아니라 공정 기준으로 정한다
PubSub는 빠른 분배 때문에 선택하는 일이 많다. 하지만 중요한 것은 Packet 주기만이 아니다. 공정에서 필요한 반응과 표시 기준을 숫자로 정해야 한다.
정할 값은 다음과 같다.
- Publishing Interval
- HMI에서 허용할 최대 Message Age
- 몇 개 Packet 손실까지 허용할지
- Subscriber Timeout
- Publisher와 Subscriber Clock 허용 오차
- Historian으로 넣을 경우 Sample 처리 방식
- Publisher Reboot 후 복구 시간
예를 들어 Publisher Interval이 100 ms라고 해서 운전자 화면이 100 ms 안에 의미 있게 바뀐다는 뜻은 아니다. HMI Scan, 화면 Refresh, Subscriber Queue, Bad Quality Timeout이 모두 붙는다. 설정값만 보지 말고 Timestamp를 찍어 실제 Chain을 측정한다.
Last Value 화면으로 UDP 손실을 숨기지 않는다
UDP는 Packet을 잃을 수 있다. 빠른 상태 표시에는 허용될 수 있지만, 손실을 안 보이게 만드는 것은 안 된다.
현장 기준을 명확히 둔다.
- 빠른 Analog 표시에서는 1~2개 Packet Drop을 허용할 수 있다.
- 정해진 Timeout을 넘긴 Dataset은 Quality를 Bad로 바꾼다.
- Command Feedback과 Permissive는 더 안전한 확인 경로 없이 일방향 UDP에만 의존하지 않는다.
- Alarm Source로 쓸 때는 transient event 누락 가능성을 따로 검토한다.
- Historian 적재에는 Source Timestamp와 Quality를 같이 넣어 Gap이 나중에 보이게 한다.
모든 Event를 반드시 받아야 하는 용도라면 UDP PubSub만으로는 맞지 않을 수 있다. Live Distribution에는 좋지만, 손실을 감지하고 처리하는 설계가 같이 있어야 한다.
Decode는 멀쩡한데 Mapping만 틀린 실수들
Dataset Mapping 오류는 Packet이 정상 Decode되기 때문에 늦게 발견된다.
자주 보는 증상은 이렇다.
| 증상 | 가능 원인 | 확인할 것 |
|---|---|---|
| Motor State가 불가능한 숫자로 보임 | Enum 정의 변경 | 정수 Type만 보지 말고 Enum 목록을 비교한다. |
| 온도가 10배 차이남 | Scaling이나 단위 변경 | Raw Value, Unit, HMI Scaling을 같이 본다. |
| Good Count가 Reject Count 위치에 표시됨 | Field 순서 밀림 | Metadata Version과 Field Order를 비교한다. |
| Update 후 모든 Message가 거부됨 | Metadata Version 또는 Namespace 불일치 | Subscriber Decode Log를 본다. |
| Switch 교체 후 값이 멈춤 | Multicast 또는 IGMP 동작 변경 | 양쪽 Switch Port에서 Capture한다. |
| 한 Subscriber만 안 됨 | 로컬 방화벽 또는 NIC Route | Inbound UDP와 Interface 선택을 본다. |
Bulk Tag Import 전에 Known Value 시험을 한다. Source에서 안전한 시험값 하나를 만들고 Subscriber의 정확한 Tag에 들어오는지 확인한다. 그 다음에 대량 Mapping을 넣는다.
Restart와 Network 복구는 일부러 시험한다
정상 기동은 당연히 되는 게 아니라 Interface 품질의 일부다. 일부러 따로 시험한다.
- Subscriber를 먼저 켜고 Publisher가 없을 때 Waiting 또는 Bad Quality로 보이는지 확인한다.
- Publisher를 켜고 First Good Dataset까지 걸리는 시간을 잰다.
- Subscriber는 유지한 채 Publisher를 Restart한다.
- Subscriber 쪽 Network를 짧게 끊었다가 복구한다.
- Sequence Counter, Stale Flag, HMI Quality가 정상 복구되는지 본다.
- Test 환경에서 Metadata를 바꿔 Subscriber가 모르는 Layout을 거부하거나 명확히 표시하는지 확인한다.
평온한 날 값이 바뀌는 것만 보고 합격 처리하면 부족하다. PubSub 문제는 Reboot, Switch 작업, VLAN 변경, Gateway 교체 때 주로 드러난다.
인수인계 자료
PubSub Stream마다 아래 자료를 남긴다.
- Publisher Host, Interface, Multicast Address, UDP Port
- WriterGroupId, DataSetWriterId, Dataset 이름, Metadata Version
- Field List, Data Type, Unit, Enum 정의
- Publishing Interval과 Subscriber Timeout
- VLAN, Switch, IGMP 설정 메모
- 정상 상태 Packet Capture
- Subscriber Diagnostic 화면 또는 Log
- Restart와 Network 복구 시험 결과
이 정도만 있어도 다음 담당자가 생산 장애 중에 Network 손실과 Schema 불일치를 빠르게 나눌 수 있다. PubSub는 문서가 없으면 단순한 UDP Packet 몇 개가 아니라 추적하기 어려운 공정 Data Path가 된다.