Modbus 게이트웨이는 Ping이 되는데 SCADA 값은 왜 끊길까

Ping은 되는데 현장 절반이 stale이다

Ping도 되고, 게이트웨이 웹 화면도 열리고, 몇몇 레지스터는 계속 갱신된다. 그런데 같은 트렁크의 드라이브 세 대가 2분째 last-good 값만 붙잡고 있다. 이 조합에 속아서, 멀쩡한 PLC를 교체하고 아무 문제 없던 RS-485 실드를 다시 조이는 일이 벌어진다.

원인은 구조에 있다. TCP 쪽에서 Modbus는 다중화가 된다. MBAP 헤더의 모든 요청에는 2바이트 transaction identifier(0~65535)가 들어 있어서, 한 클라이언트가 여러 요청을 동시에 띄울 수 있다(Modbus Application Protocol Spec V1.1b3, §4.1). RS-485 쪽에는 그런 개념이 없다. Modbus over Serial Line은 철저히 한 번에 한 트랜잭션이다. 요청, 대기, 응답, 그리고 다음 프레임 전 3.5 캐릭터 침묵 구간(Modbus over Serial Line V1.02, §2.5.1.1). 게이트웨이가 하는 일은 이 TCP 요청 다발을 한 줄짜리 serial 파이프로 밀어 넣는 것뿐이다. 파이프가 못 따라가면 요청은 사라지지 않는다. 큐에 쌓이고, 재시도되고, 오래되어 stale 값으로 돌아온다.

그러니 시운전에서 정말 봐야 할 숫자는 ping 지연이 아니다. 가장 느린 슬레이브가 serial timeout에 걸려 있는 동안, 게이트웨이가 붙잡고 있는 다른 요청은 몇 개이고 그중에 내 요청이 있는가다.

실제 요청 경로를 먼저 적는다

Timeout 값을 만지기 전에 경로부터 정리한다.

이 표를 만들면 흔한 문제가 보인다. 운전 화면, 히스토리언, 대기 서버, 엔지니어링 노트북이 모두 같은 serial 병목을 쓴다. SCADA 클라이언트 하나를 더 붙였을 뿐인데 현장 버스에는 요청이 두 배로 들어갈 수 있다.

큐 포화 때 보이는 현상

큐가 포화되어도 항상 깔끔한 통신 알람으로 나오지는 않는다.

• 값이 일정 주기가 아니라 몰아서 갱신된다.
• 슬레이브 하나가 응답하지 않으면 같은 게이트웨이 뒤의 다른 장비까지 stale이 된다.
• HMI에서 명령을 눌렀는데 장비 반응이 몇 초 늦다.
• 게이트웨이 진단에서 pending request, dropped request, serial retry가 계속 증가한다.
• 평소에는 괜찮다가 대기 서버, 히스토리언, 엔지니어링 노트북을 붙이면 나빠진다.
• 정전 복구 뒤 모든 클라이언트가 동시에 접속하면서 증상이 심해진다.

게이트웨이가 포트별 진단을 제공하면 큐 깊이를 트렌드로 남겨 본다. 단순 timeout count보다 큐 깊이 변화가 원인을 더 잘 보여준다.

배선 탓을 하기 전에 클라이언트 부하를 줄인다

RS-485 배선 문제가 실제로 있을 수 있다. 그래도 먼저 불필요한 요청을 걷어내야 한다.

SCADA 드라이버에서 확인할 항목은 다음과 같다.

1. 게이트웨이별 또는 Unit ID별 동시 요청 수 제한이 있는지 본다.
2. 대기 서버가 같은 데이터를 독립적으로 폴링하는지 확인한다.
3. 진단값, nameplate 정보, 누적 전력량은 느린 scan class로 내린다.
4. 연속 레지스터는 묶어서 읽고, 작은 read를 여러 개 만들지 않는다.
5. 명령 write가 긴 진단 read에 밀리지 않도록 경로와 우선순위를 본다.
6. Timeout과 retry는 TCP 구간이 아니라 뒤쪽 serial 구간 기준으로 잡는다.

Serial timeout 기본값을 믿기 전에 계산부터 해 본다. 19200 baud, 8E1에서 한 캐릭터는 11비트, 즉 약 573 µs다. 짧은 holding register read와 응답은 실제로 몇 ms짜리 트래픽에 불과하다. 그런데 죽은 슬레이브는 아예 응답하지 않는다. 게이트웨이는 serial timeout을 끝까지 기다린 뒤 재시도한다. 벤더 기본값이 1000 ms에 retry 3회라면, Unit ID 하나가 빠졌을 때 폴 주기마다 트렁크가 3초씩 멈추고, 뒤쪽 장비가 다 같이 stale이 된다. 나는 serial timeout을 정상 응답 시간의 45배(대개 1000이 아니라 200300 ms) 정도로 잡고 retry는 1회로 둔다. 약한 장비 하나가 버스 전체를 붙잡지 못하게 하려는 것이다. 길고 느긋한 timeout은 정말 필요한 그 한 대의 불안정한 미터에만 쓰고, 24개 Unit ID 전부에 기본값으로 적용하지 않는다.

운전 상태와 정비 데이터를 나눈다

드라이브 게이트웨이에는 run, fault, speed뿐 아니라 온도, 누적 시간, firmware, 상세 진단, 파라미터가 같이 들어 있다. 모두 같은 속도로 읽을 필요는 없다.

이렇게 나누면 정비자가 상세 faceplate를 열어도 운전자 화면이 덜 흔들린다.

게이트웨이 변경 시 현장 시험

게이트웨이를 교체하거나 추가할 때 레지스터 하나 읽히는 것으로 끝내면 부족하다.

• 평소 운전에 포함되는 주 서버, 대기 서버, 히스토리언 수집기, 엔지니어링 도구를 모두 연결한다.
• 가장 큰 overview 화면과 가장 무거운 정비 화면을 열어 본다.
• 뒤쪽 Modbus 슬레이브 하나를 전원 차단하거나 통신선에서 분리한다.
• 다른 Unit ID 값이 계속 갱신되는지 확인한다.
• 허용된 시험 write를 보내고 HMI 명령부터 장비 확인까지 시간을 잰다.
• 큐 깊이, serial retry, exception count, TCP client count를 기록한다.
• 빠졌던 슬레이브를 복구한 뒤 게이트웨이 재시작 없이 큐가 빠지는지 본다.

이 시험은 생산 장애 때가 아니라 시운전 때 해 둬야 한다.

자주 나오는 실패 형태

계측기 하나를 빼면 전체 장비가 stale이 된다. Serial timeout과 retry가 너무 길거나, 요청 순서가 한 Unit ID 실패에 전체 라인을 묶는 구조일 수 있다.

히스토리언을 켜면 HMI가 느려진다. 히스토리언이 SCADA 캐시를 쓰지 않고 같은 레지스터를 별도로 빠르게 읽고 있을 수 있다.

알람 폭주 때 명령이 늦게 들어간다. Read retry가 큐를 채워 write가 뒤로 밀린다. 제품이 지원하면 명령 우선순위를 둔다. 아니면 해당 경로의 read 부하를 줄인다.

대기 서버에서만 품질 불량이 보인다. 두 서버가 서로 다른 timeout과 retry 설정으로 독립 폴링 중일 수 있다. 게이트웨이의 client count와 request rate를 같이 본다.

Firmware 업그레이드 뒤 증상이 생겼다. 기본 큐 깊이, TCP connection limit, serial turnaround 값이 바뀌었을 수 있다. 이전 설정 export를 프로젝트 기록에 남겨야 한다.

프로젝트 노트에 남길 것

다음 장애 대응자가 바로 볼 수 있게 남긴다.

• 게이트웨이 모델, firmware, IP, serial port 설정.
• 각 트렁크의 Unit ID 목록과 장비 순서.
• 게이트웨이를 폴링하는 SCADA 클라이언트 목록.
• 빠른 데이터, 일반 데이터, 느린 데이터의 scan class.
• Timeout, retry, 최대 동시 요청 수.
• 정상 운전 중 예상 큐 깊이.
• 뒤쪽 장비 하나가 빠졌을 때 복구 동작.

한 줄 더 남길 값이 있다. 게이트웨이가 허용하는 최대 동시 TCP 연결 수다. 저가형 장비는 이 값이 4나 8에 묶여 있는 경우가 많고, 9번째 클라이언트가 조용히 connection refused로 거절당하는 일은 누군가 히스토리언이나 OT 모니터링 장비를 하나 더 붙이는 날 그대로 터진다. 이 한계값은 아무도 다시 열지 않는 벤더 PDF가 아니라 도면에 적어 둬야 한다.