시운전 아침에 EtherNet/IP remote I/O가 다 붙었다. 4분쯤 지나서 한 랙이 떨어졌다. PLC를 재부팅하면 또 몇 분 붙고 또 떨어진다. PLC도 I/O 카드도 정상이다.
범인은 스위치의 IGMP snooping이었다. querier가 없었다.
CIP Class 1 implicit I/O는 UDP 2222로 multicast를 쓴다. snooping을 켜 놓고 querier를 아무도 안 켜면, 스위치는 처음 join만 보고 그 뒤로 membership을 갱신할 방법이 없다. IGMPv2(RFC 2236) 기본값으로 query interval 125초, max response time 10초, robustness 2다. group membership interval은 2 × 125 + 10 = 260초다. 그래서 4분이다. 시간이 다 되면 스위치가 그 그룹을 지우고 multicast를 끊는다.
고치는 방법은 둘 중 하나다. VLAN마다 querier를 지정하거나, 그 VLAN에서 snooping을 끄고 flooding을 감수하는 것. ODVA는 EtherNet/IP 망에 snooping과 querier를 같이 쓰라고 권한다. 나는 PLC VLAN에 querier를 스위치 한 대로 고정하고, 그 스위치 이름을 도면에 적어 둔다. 다음 사람이 찾을 수 있는 유일한 방법이다. RFC 4541에 snooping 스위치가 지켜야 할 동작이 정리돼 있으니, 벤더 구현이 의심되면 거기부터 본다.
링크 업은 시험이 아니다
링크 LED가 초록색인 포트가 반이중으로 돌고 있을 수 있다. IEEE 802.3 Clause 28 auto-negotiation은 양쪽이 다 할 때만 동작한다. 한쪽을 100 Mbit/s full duplex로 고정해 두면, 반대쪽 auto 포트는 parallel detection으로 속도만 맞추고 duplex는 반이중으로 떨어진다. 링크는 올라온다. 트래픽이 조금 늘면 late collision과 FCS error가 쌓인다.
그래서 포트별로 세 개를 적는다.
- 협상된 speed와 duplex (설정값이 아니라 실제 결과)
- error counter: CRC/FCS error, late collision, 그리고 full duplex 포트에 collision이 하나라도 있으면 그건 mismatch다
- link uptime. 몇 시간짜리 uptime이면 재부팅 때 흔들리는 포트가 아니라는 뜻이다
옛 PLC, radio, media converter, serial gateway는 아직 고정 설정으로 출하되는 게 있다. 한쪽을 고정하면 양쪽 다 고정한다. 섞어 놓은 포트가 현장에서 제일 오래 사람을 괴롭힌다.
이중화는 "켰다"가 아니라 측정값으로 넘긴다
복구 시간을 재지 않은 링은 이중화가 아니다. 어떤 방식을 쓰는지부터 숫자가 다르다.
| 방식 | 근거 | 대략의 복구 시간 |
|---|---|---|
| 구형 STP | IEEE 802.1D | 30~50초. 제어망에서는 못 쓴다 |
| RSTP | IEEE 802.1D-2004 | point-to-point 링크면 1초 이하, 최악의 경우 수 초 |
| MRP | IEC 62439-2 | 복구 등급 500 ms와 200 ms, 더 빠른 프로파일도 있다 |
| PRP / HSR | IEC 62439-3 | 복구 시간 0. 프레임을 두 경로로 동시에 보낸다 |
RSTP 기본 타이머는 hello 2초, max age 20초, forward delay 15초다. 이 숫자를 알아야 하는 이유는, 링크가 물리적으로 안 끊기고 BPDU만 안 올 때(한쪽 fiber만 죽은 경우) 복구가 max age인 20초 뒤에 시작된다는 것이다. 1초를 기대한 사람이 20초를 보고 장비를 의심한다. 경로 비용도 확인한다. 802.1D-2004 권장값은 100 Mbit/s가 200000, 1 Gbit/s가 20000이다. 기가 uplink가 100 Mbit 경로로 돌고 있는 걸 이 숫자로 잡는다.
시험은 정해진 작업 창에서 세 번 한다. uplink 하나 빼기, 전원 한쪽 내리기, root 스위치 재부팅. 매번 PLC 통신 끊김 시간을 스톱워치가 아니라 historian의 빈 구간이나 PLC 진단 bit로 기록한다. 그 숫자가 인수 문서에 들어간다.
포트 번호까지 가 봐야 통신 시험이다
노트북 ping은 VLAN도 ACL도 증명하지 못한다. 실제 application이 쓰는 포트로 간다.
| 프로토콜 | 포트 | 근거 |
|---|---|---|
| Modbus TCP | TCP 502 | Modbus Messaging Implementation Guide |
| DNP3 | TCP 20000 | IEEE 1815 |
| OPC UA binary | TCP 4840 | OPC UA Part 6 |
| IEC 61850 MMS | TCP 102 | IEC 61850-8-1 |
| EtherNet/IP explicit | TCP 44818 | ODVA CIP |
| EtherNet/IP implicit I/O | UDP 2222 | ODVA CIP, multicast |
SCADA 서버에서 각 PLC로 해당 포트를 열어 보고, 그 결과를 포트 맵 옆에 적는다. UDP 2222는 열렸는지를 확인할 수가 없으니 I/O 연결 상태로 본다. 위의 260초 문제가 여기서 걸린다.
PROFINET이 섞여 있으면 스위치 등급을 확인한다. PROFINET Conformance Class B는 SNMP와 LLDP를 요구한다. LLDP 없이는 토폴로지 기반 장비 교체(이웃 이름으로 이름을 받는 기능)가 동작하지 않는다. 스위치를 "관리형"이라고만 보고 넘기면 여기서 걸린다.
시간이 틀린 스위치 로그는 쓸 수가 없다
로그 분석을 하려면 스위치 시간이 SCADA와 historian과 맞아야 한다. 일반 제어망은 NTP로 충분하다. 수십 ms 안에서 로그 순서를 가리는 데 문제가 없다.
IEEE 1588-2008 PTP가 필요한 경우는 따로다. 변전소 쪽은 IEC 61850-9-3 power profile이 1 µs 급을 요구하고, 그러면 경로의 모든 스위치가 transparent clock이거나 boundary clock이어야 한다. PTP를 모르는 스위치 한 대가 경로에 끼면 그 정확도는 못 나온다. 이건 시운전에 고칠 수 있는 문제가 아니라 자재 선정에서 끝나는 문제다. 설계가 PTP를 요구하는지 먼저 확인한다.
관리 접속: 표준이 요구하는 항목만
IEC 62443-3-3을 쓰는 사이트라면 스위치에서 걸리는 조항이 정해져 있다.
- SR 1.1 human user identification and authentication — 공용 계정 금지, 사람마다 계정
- SR 1.7 strength of password-based authentication — 기본 비밀번호 교체, 사이트 정책의 길이/복잡도 적용
- SR 7.7 least functionality — 안 쓰는 서비스와 포트 비활성화. Telnet과 HTTP 평문 관리를 끄고 SSH/HTTPS만 남기는 게 보통 여기 걸린다
안 쓰는 물리 포트는 비활성화하거나 최소한 "예비"로 문서에 남긴다. 캐비닛에 열린 포트는 반년 뒤 아무도 모르는 망 변경이 된다.
환경 등급도 인수 때 확인한다. 변전소면 IEC 61850-3 또는 IEEE 1613, 일반 공장이면 사이트 기준. 사무실용 스위치가 MCC 캐비닛에 들어간 걸 여름에 발견하는 건 늦다.
넘기기 전에 설정 파일을 뽑는다
running config를 export해서 프로젝트 백업에 넣는다. firmware 버전도 같이 적는다. running과 startup이 분리된 장비는 저장됐는지 확인한다. 저장 안 된 설정은 다음 정전까지만 유효하다.
파일 이름에 사이트, hostname, 날짜, firmware를 넣는다. WTP_SW-MCC1-01_2026-06-07_fw-x.y.z.cfg 정도면 충분하다.
다음에 볼 것
인수가 끝나고 한 달 뒤에 포트 error counter를 다시 읽어 본다. 시운전 때 0이던 CRC error가 늘어 있으면 케이블이 아니라 커넥터나 온도 문제일 때가 많다. 숫자를 한 번 적어 둬야 두 번째 숫자가 의미를 갖는다.