이중화 PLC가 실제로 지켜주는 것 — Hot Standby 전환 시운전 가이드

이중화 PLC가 실제로 약속하는 것

Hot-standby PLC 쌍은 같은 프로그램을 돌리는 두 대의 CPU다. 하나는 primary(주), 하나는 **standby(대기)**이며, 전용 동기화(sync) 링크로 연결된다. Primary가 공정을 제어한다. Standby는 출력에 아무 것도 하지 않지만 프로그램 로직과 데이터의 실시간 사본을 유지해, primary가 고장 나면 한두 스캔 안에 제어를 넘겨받을 수 있다.

약속은 좁고, 분명히 말할 가치가 있다. primary CPU가 죽으면 공정에 충격(bump) 없이, 운전원 개입 없이 제어가 이어진다. 그게 전부다. CPU 이중화는 I/O 모듈 고장, 끊긴 네트워크 구간, 로직 버그, 잘못된 setpoint, 현장 기기 고장을 막아 주지 않는다. 이런 고장은 두 CPU에 똑같이 닥치거나, 이중화 쌍 바깥에 있는 공유 부품을 때린다. 이중화 PLC 시운전은 대부분 그 한 가지 약속이 동작하는지 증명하고, 그것이 커버하지 못하는 여러 가지에 대해 솔직해지는 일이다.

현장에서 만나는 대표적 구현: Rockwell ControlLogix/GuardLogix 이중화는 1756-RM2 모듈 한 쌍을 1756-RMC1/RMC3/RMC10 광 케이블 한 가닥(1 m, 3 m, 10 m)으로 잇는다. Siemens S7-400H는 CPU마다 sync submodule을 두 개 달아 동기화 경로 자체를 이중화한다. 그 밖에 Siemens S7-1500R/H, Schneider Quantum Hot Standby와 M580 HSBY(두 CPU의 이중화 포트 사이 광 연결)가 있다. 시운전에서 신경 쓸 지점은 어느 쪽이나 같지만, 설계 검토로 가져가야 할 차이가 하나 있다. sync 링크를 이중화해 주는 플랫폼이 있고, 케이블 딱 한 가닥만 주는 플랫폼이 있다.

쌍의 세 가지 상태

모든 이중화 쌍은 한눈에 읽을 수 있어야 하는 세 가지 조건을 갖는다. 프로그래밍 소프트웨어뿐 아니라 HMI에서도 보여야 한다.

동기화됨(Synchronized, redundant): 두 CPU 모두 정상, standby가 완전히 크로스로드되어 primary를 추종 중. 전환이 무순단이 되는 유일한 상태다. 완전한 보호.
자격 상실(Disqualified, standby 준비 안 됨): primary가 혼자 돌고 있다. Standby는 전원이 들어와 있지만 동기화되지 않았다 — 크로스로드 중이거나, 펌웨어 불일치, sync 링크 고장, 아직 복구 못한 폴트 때문이다. 제어는 멀쩡하지만 백업이 없다. 이 상태가 위험한 이유는 정확히 공정이 정상으로 보이기 때문이다.
primary 없음 / 둘 다 폴트: 공정이 정지했거나 고정된 출력으로 돌고 있다. 드물지만, 알람 대응을 설계할 때 기준으로 삼는 고장 모드다.

SCADA에서 가장 쓸모 있는 이중화 태그는 "primary CPU = A/B"가 아니다. **"쌍 동기화됨: 예/아니오"**다. 조용히 자격 상실 상태로 떨어져 3주 동안 비동기 상태로 돌아간 쌍은, 돈 주고 산 이중화를 소리 없이 버린 것이다. 동기화 상실에 알람을 걸고, 그 알람은 운전원이 shelve해서 잊어버릴 수 없는 것으로 만들어라. ISA-18.2는 shelving을 운전원이 거는 시간 제한부 억제로 본다. 알람 시스템이 그것을 추적하고 스스로 해제해야 한다. 그렇게 구현된 시스템이면 shelve 한도를 한 교대로 두는 것으로 충분하다. shelve하면 누가 기억해 낼 때까지 그대로인 시스템이라면, 이 알람은 shelve 가능 목록에서 아예 빼라. 감당할 만하다. EEMUA 191이 말하는 관리 가능한 장기 평균은 운전원당 10분에 1건 수준이고, 건강한 쌍에서 동기화 상실 알람은 1년에 한두 번 뜬다.

동기화가 동작하는 방식, 그리고 스캔 타임이 늘어나는 이유

Standby는 primary의 데이터 테이블 사본을 sync 링크로 받아 최신 상태를 유지한다. 보통 매 스캔 끝(플랫폼에 따라 큰 데이터는 몇 스캔마다)에 이뤄진다. 이 크로스로드는 공짜가 아니다. primary가 상태를 묶어 보내려고 멈춰야 하므로, 이중화 프로그램은 같은 프로그램의 심플렉스 CPU보다 거의 항상 스캔 타임이 길고 더 변동적이다.

시운전 중 볼 것:

Standby를 끈 상태가 아니라, 쌍이 동기화된 상태에서 스캔 타임을 측정하라. 동기화된 값이 진짜 값이다.
큰 배열, 큰 UDT, 메시지 많은 로직은 크로스로드 시간을 부풀린다. 스캔 타임이 빠듯하면 rung 최적화보다 이중화 데이터 크기를 줄이는 게 더 효과적이다.
동기화됐을 때만 스캔 타임이 튄다면 크로스로드 부하를 정면으로 가리킨다. 일부 플랫폼은 특정 태그를 크로스로드에서 제외할 수 있다 — 전환 후 살아남을 필요 없는 데이터(진단, 스크래치 값)에 활용하라.
SCADA 폴 주기와 스캔 타임 워치독은 동기화된 스캔 타임에 여유를 더해 잡아라. 안 그러면 쌍이 부하 상태에서 처음 동기화될 때 워치독 폴트가 난다.

크로스로드 비용은 느낌이 아니라 숫자로 잡아라. standby를 뺀 상태에서 스캔 타임을 기록하고, 같은 부하에서 쌍을 동기화시킨 뒤 다시 기록한다. 그 차이가 스캔당 이중화 비용이다. 흔히 나오는 모양의 예: simplex 12 ms, 동기화 19 ms면 크로스로드가 7 ms, 원래 스캔의 58%가 얹힌 것이다. FAT 때 simplex 값으로 잡아 둔 워치독은 이 정도면 충분히 튄다. 워치독은 평균이 아니라 관측된 동기화 최악값 기준으로 잡고, 2배 여유를 둬라.

무엇이 전환을 유발하는가

무엇이 제어를 standby로 넘기고 무엇이 넘기지 않는지 정확히 알아라. 운전원이 물어볼 것이고, 전환 관련 놀라움의 절반은 여기서 모델이 틀려서 나온다.

primary CPU 하드웨어 폴트 또는 전원 상실 — 전형적인 경우이자 이중화가 만들어진 이유. 동기화됐을 때 무순단.
primary 메이저 폴트(프로그램 폴트) — primary를 멈추는 0으로 나누기나 배열 인덱스 폴트. 여기 함정이 있다. standby는 같은 프로그램을 돌리므로, 대개 한 스캔 뒤 같은 rung에서 똑같이 폴트난다. 이중화는 로직 버그를 막아 주지 않는다. 그걸 믿지 마라.
primary의 I/O 또는 네트워크 연결 상실 — 플랫폼에 따라 다르다. 어떤 시스템은 primary가 I/O 경로를 잃으면 전환하고, 어떤 시스템은 standby의 경로가 더 낫다는 보장이 없어 전환하지 않는다. 자기 플랫폼의 동작을 알고 시험하라.
수동 전환 명령 — 프로그래밍 소프트웨어나 HMI 제어에서. 계획된 정비에 필수다. standby로 넘기고, (이제 오프라인이 된) 이전 primary를 정비한 뒤 다시 넘긴다.
펌웨어/프로그램 다운로드 — 대부분의 플랫폼은 standby를 갱신하고, 그쪽으로 전환한 뒤, 이전 primary를 갱신하게 해 준다. 공정 정지 없이 펌웨어를 바꾸는 방법이다. 필요해지기 전에 리허설하라.

무순단은 공유 부품만큼만 좋다

"무순단(bumpless)"은 제어가 CPU 사이를 옮길 때 출력이 튀지 않는다는 뜻이다 — standby가 이미 현재 출력 이미지를 갖고 있어 primary가 몰던 값과 같은 값을 몬다. 하지만 이중화 CPU 쌍은 사슬의 한 고리일 뿐이다. 쌍이 공유하는 모든 것은 **어떤 CPU 이중화로도 구제되지 않는 단일 고장점(SPOF)**이다.

I/O. 두 CPU가 단일 remote I/O 어댑터를 통해 현장 I/O에 닿는다면, 그 어댑터가 단일 고장점이다. 진짜 이중화 설계는 이중 I/O 경로(듀얼 어댑터, 링 네트워크)가 필요하다. 아니면 싼 부품을 보호하고 비싼 부품을 노출한 셈이다. 링으로 갈 거면 복구 시간을 먼저 값으로 따져라. IEC 62439-2 MRP는 끊어진 링을 정해진 시간 안에 재구성한다. 기본 프로파일 500 ms, 50노드 이하 링에 흔히 쓰는 프로파일 200 ms다. 그러니 timeout이 100 ms인 I/O 연결은 케이블 사고 한 번에 끊겼다 다시 붙고, 운전원 눈에는 bad quality가 한 번 몰아치는 것으로 보인다. IEC 62439-3 PRP와 HSR은 접근이 다르다. 모든 프레임을 두 경로로 동시에 보내고 먼저 도착한 쪽을 쓴다. 복구 시간은 0 ms다. 복구할 게 없으니까. PRP는 네트워크를 통째로 하나 더 사는 값이고, MRP는 그 200 ms를 감수하는 값이다. 알고 고르면 된다.
sync 링크. CPU 사이 이중화 케이블 한 가닥은 이중화 기능 자체의 단일 고장점이다 — ControlLogix에서는 1756-RM2 쌍 사이의 광 케이블, M580 HSBY에서는 두 CPU의 이중화 포트 사이 광 케이블이다. 끊기면 쌍이 자격 상실 상태가 된다 — 알람을 걸지 않으면 모른 채 심플렉스로 돌고 있는 것이다.
전원. 같은 전원공급기나 같은 차단기에 물린 두 CPU는 함께 죽는다. 이중화 CPU는 별도로 급전되는 이중화 전원을 원한다.
SCADA로 가는 네트워크. 두 CPU가 활성 primary를 따라가는 하나의 IP로 응답한다면, 전환은 그 IP를 소유한 물리 CPU를 바꾼다. SCADA가 깨끗하게 재접속하는지, 어떤 드라이버도 오래된 MAC을 캐시하지 않는지 확인하라. CPU가 별도 IP를 갖는다면 SCADA 드라이버가 어느 쪽이 활성인지 아는지 확인하라. 그리고 진짜 지연이 어디 있는지 알아 둬라. CPU 전환은 한두 스캔이지만, 운전원이 보는 재접속 시간은 드라이버의 TCP timeout과 retry backoff가 정한다. PLC 설정이 아니라 SCADA 설정이다. SCADA 경로도 I/O 경로만큼 중요하다면 답은 PRP(IEC 62439-3)다. 독립된 네트워크 두 벌이 동시에 살아 있고, 0 ms다.

현장 단자에서 SCADA 태그까지 전체 경로를 따라가며 이중화되지 않은 모든 부품에 표시하라. 그것들이 진짜 고장 모드다. "PLC가 이중화됐다"가 플랜트도 이중화됐다는 뜻으로 새어 나가게 두지 말고, 시운전 기록에 그대로 적어라.

이중화는 가용성이지 안전이 아니다

HAZOP 문서에 잘못 적히는 일이 잦아서 분명히 해 둔다. CPU를 두 벌 두는 것은 가용성을 사는 일이다. 안전 무결성을 사는 게 아니다. 둘은 별개의 성질이고 근거 규격도 다르다. Hot-standby 제어 쌍은 두 벌이라는 이유만으로 SIL 등급을 갖지 않는다. SIL이 필요한 기능이라면 IEC 61511은 기본 공정 제어 시스템과 독립된 SIS를 요구한다. 자기 logic solver, 자기 센서와 최종 요소, 자기 proof test 주기를 갖는 시스템이다. 이유는 위의 메이저 폴트 함정을 일반화한 것이다. 같은 프로그램을 돌리는 두 CPU는 그 프로그램의 모든 결함을 공유하므로, 계통적 고장에는 이중화가 아무 일도 하지 않는다. 독립성이 한다. "PLC는 이중화돼 있다"가 방호 계층으로 계산되게 두지 마라.

시운전 중 전환 시험

한 번도 전환을 강제당해 본 적 없는 이중화 쌍은 시험되지 않은 쌍이다. 공정을 안전하고 관측 가능한 상태로 두고 의도적으로 시험하되, 양방향을 다 시험하라 — A→B와 B→A가 대칭이라는 보장은 없다.

각 시험마다 기록하라. 출력이 무순단으로 유지됐는가, 전환에 얼마나 걸렸는가, SCADA가 재접속했고 어느 CPU에 붙었는가, 알람이 올바로 떴는가, 이후 쌍이 동기화 상태로 돌아왔는가.

동기화 시작 확인. 아무 것도 건드리기 전에 HMI에서 쌍이 동기화로 읽히는지 확인하라. 자격 상실 상태에서 전환을 시험하고 그 결과를 합격이라 부르지 마라.
수동 전환, 양방향. primary→standby 스왑을 명령하고, 무순단 제어와 깨끗한 SCADA 재접속을 확인한 뒤, 재동기화를 기다렸다가 다시 스왑하라. 가장 안전한 첫 시험이자 운전원이 정비에 쓸 방법이다.
primary 전원 차단. 공정이 안전한 상태에서 primary CPU 전원을 제거하라. standby가 예상 시간 안에 제어를 잡는지, 출력이 유지됐는지, 고장 난 CPU가 명확히 통지되는지 확인하라.
sync 링크 뽑기. 쌍이 자격 상실이 되고 "비동기 / 백업 없음" 알람이 뜨는지, 그리고 primary가 혼자 계속 돌므로 제어는 튀지 않는지 확인하라. 링크를 복구하고 스스로 재동기화하는지 확인하라.
I/O 경로 상실 강제 — 플랫폼이 그것으로 전환한다면. 문서화된 동작이 매뉴얼이 아니라 이 시스템에서 실제로 일어나는지 확인하라.
운전원 자리에서 재접속 시간 측정. 전환 동안 HMI가 오래된 데이터나 상실을 보여 주는 시간을 재라. 두 스캔짜리 CPU 전환도 SCADA 재접속으로는 몇 초가 될 수 있다. 운전원 기대치를 CPU 스펙이 아니라 측정값에 맞춰라.
retentive/누적 데이터 생존 검증. 적산계(totalizer), 시퀀스 스텝 번호, 래치 상태, setpoint는 전환을 넘어 유지돼야 한다. 크로스로드에서 제외된 것은 리셋된다 — 이벤트 중이 아니라 벤치에서 안전하게 찾아내라.

시운전 체크리스트

두 CPU가 동일 펌웨어와, 올바로 크로스로드된 동일 프로그램 버전을 돌리는지 확인한다.
쌍이 동기화 상태에 도달·유지하는지 확인하고, 전체 크로스로드에 걸리는 시간을 측정한다.
현실적 부하에서 동기화 스캔 타임을 측정하고, SCADA 폴 주기와 스캔 워치독을 여유를 더해 잡는다.
"쌍 동기화됨: 예/아니오"와 "활성 CPU: A/B"를 SCADA 태그로 노출하고, 동기화 상실에 운전원이 몰래 무력화할 수 없는 알람을 건다.
I/O에서 SCADA까지 전체 경로를 따라가며 이중화되지 않은 모든 단일 고장점(I/O 어댑터, sync 케이블, 전원 급전, 네트워크)을 기록한다.
무순단 출력과 깨끗한 SCADA 재접속으로 양방향 수동 전환을 시험한다.
primary 전원 상실 전환을 시험하고 타이밍, 유지된 출력, 올바른 통지를 확인한다.
sync 링크 상실을 시험하고, 쌍이 자격 상실·알람·계속 제어·복구 시 재동기화하는지 확인한다.
retentive·누적·래치 데이터가 전환을 넘어 생존하는지 확인하고, 크로스로드에서 제외된 것을 문서화한다.
standby를 통한 펌웨어/프로그램 갱신을 리허설해, 향후 변경에 공정 정지가 필요 없게 한다.
활성 CPU, 동기화 상태, 스캔 타임, 전환 시간, 재접속 시간을 I/O·네트워크 도면과 함께 기록한다.

기록에 서명하기 전에 마지막으로 하나만 더 확인하라. 시운전 기간의 알람 이력을 열어 동기화 상실 알람을 찾아라. 한 번도 안 떴으면 아무도 링크를 안 뽑은 것이고, 체크리스트 8번은 뒤에 아무것도 없는 체크 표시다. 떴는데 운전원 대응 기록이 안 붙어 있으면 알람은 있고 절차는 없는 것이다. 후자가 흔하다. 인수인계 3주 뒤에 이중화 쌍을 조용히 심플렉스로 되돌리는 게 바로 그 경우다.