다중 펌프장 통합 SCADA｜다음 펌프장으로 복제되는 표준 템플릿 설계법

수평 전개할 때마다 되풀이되는 다섯 가지 재작업

단일 펌프장 프로젝트가 끝나면 방법은 이미 검증되었고 이후는 반복일 뿐이라고 보기 쉽습니다. 그러나 두 번째 펌프장부터 반복은 다른 형태로 나타납니다. 되풀이되는 것은 설치 작업이 아니라 엔지니어링과 설정 작업입니다.

재작업 지점을 하나씩 적어보면 원인이 한곳으로 모입니다. 1차 펌프장의 산출물이 다음 현장에서 그대로 꺼내 쓸 수 있는 자산의 형태로 정리되지 않은 것입니다.

• 펌프장마다 화면을 다시 그림: 시설 유형은 비슷한데 공정 화면을 개별로 만들어, 표현 방식을 나중에 통일하려면 모든 펌프장을 하나씩 손봐야 함
• 태그 명명이 통일되지 않음: 같은 펌프의 운전 상태가 현장마다 다른 이름으로 등록되어, 사이트 간 집계는 수작업 매핑표에 의존하게 됨
• 경보가 현장별 정의로 남음: 같은 수위 이탈이라도 등급, 지연 시간, 복귀 처리 방식이 달라 통합운영센터에 올라온 경보를 사이트 간 비교할 수 없음
• 권한과 계정이 흩어짐: 펌프장마다 로컬 사용자 목록을 따로 두고 인사 이동 후에도 정리되지 않아, 사고 조사 시 조작자를 추적할 수 없음
• 신규 펌프장 연동을 매번 처음부터 진행: 설비 목록, 레지스터 주소, 통신 파라미터를 매번 새로 정리하고 게이트웨이 설정도 현장에서 수동 입력에 의존함

다섯 항목 모두 기술적 난제가 아니라 엔지니어링을 어떻게 조직하느냐의 문제입니다. 해결 방향도 분명합니다. 1차 펌프장의 산출물을 상속 가능한 부품으로 분해해, N번째 현장이 설계가 아니라 복제에서 시작되도록 만드는 것입니다.

템플릿 복제 파이프라인: 표준 템플릿 → 주소 테이블 내보내기 → 게이트웨이 연동 → 플랫폼 통합 → 경보·권한 상속

복제 가능한 방식이란 단일 펌프장의 납품물을 다섯 단계로 나누고, 각 단계가 다음 현장에서 바로 쓸 수 있는 산출물을 내놓게 하는 것입니다. 앞 단계의 출력이 다음 단계의 입력이 되므로 중간에서 손으로 옮겨 적는 일이 사라집니다.

이 흐름 위에 축적한 엔지니어링 자산은 다음과 같습니다. 단일 펌프장 표준 펌프군 감시 템플릿(공정 화면, 경보 정비, 리포트), 게이트웨이 내장 웹 설정 페이지와 설비 주소 테이블 원클릭 내보내기, ModbusTCP 수집과 MQTT/REST 이중 채널 클라우드 전송, 그리고 게이트웨이 인증서와 클라이언트 인증서, 자체 서명 인증서로 구성한 보안 체계입니다.

• 표준 템플릿: 시설 유형별(중계 펌프장, 하수 펌프장, 가압장)로 공정 화면·경보 정의·리포트 양식을 한 세트씩 준비하고, 같은 유형 안의 차이는 화면 수정이 아니라 파라미터로 흡수함
• 주소 테이블 내보내기: 게이트웨이 내장 웹 설정 페이지에서 설비 목록과 레지스터 주소를 정리해 한 번의 조작으로 내보내고, 이 표를 SCADA 측과 플랫폼 측이 공유하는 단일 입력으로 삼음
• 게이트웨이 연동: 현장 설비를 ModbusTCP로 수집하고 MQTT/REST 이중 채널로 클라우드에 전송하며 인증서 체계로 경로를 보호함. 통신 두절 구간은 로컬에 보관했다가 회선 복구 후 자동으로 채움
• 플랫폼 통합: 각 펌프장 데이터가 통일된 명명 규칙으로 플랫폼에 들어와, 사이트 통합 화면과 이력 데이터베이스가 같은 태그 구조를 재사용하므로 펌프장을 추가해도 데이터 모델은 그대로 유지됨
• 경보·권한 상속: 경보 등급 구분, 억제, 복귀 아카이브 규칙과 역할 권한 매트릭스를 템플릿에서 상속받아, 신규 펌프장이 가동 시점부터 정비된 경보 정의를 갖춘 상태로 시작함

표준화할 가치가 있는 단계와, 표준화하지 않을 때의 대가

어떤 단계를 표준화할지는 한 가지 질문으로 판단할 수 있습니다. N번째 펌프장에서 이 작업을 처음부터 다시 해야 하는가. 답이 '그렇다'라면 템플릿으로 정리할 대상입니다.

3차원 공정 렌더링도 시설 유형별로 축적할 수 있습니다. 조감·공정·보안 세 가지 시점별로 템플릿을 갖춰두면 신규 펌프장에서는 모델과 태그 연결만 교체하면 되고 장면을 처음부터 구성할 필요가 없습니다.

통합운영센터가 먼저 설계해야 할 네 가지

다중 사이트의 난이도는 절반이 통합운영센터 쪽에 있습니다. 다음 네 가지를 모든 펌프장을 연동한 뒤로 미루면 변경 비용이 뚜렷하게 올라갑니다. 각 항목이 거꾸로 현장 측 설정 변경을 요구하기 때문입니다.

• 사이트 통합 화면: 먼저 운영자가 한 화면에서 무엇을 보는지 정의합니다. 펌프장별 운전·정지 상태, 주요 수위와 유량, 통신 연결 상태. 그다음에 통합 화면에서 개별 펌프장 공정 화면으로 어떻게 내려갈지를 정합니다
• 경보 병합과 당직 인수인계: 여러 펌프장에서 동시에 올라올 때는 사이트·등급·유형으로 묶어 목록이 밀려 사라지지 않게 합니다. 미복귀 경보와 조치 기록은 교대와 함께 인계되어야 하고, 문자와 메신저 등 다중 채널 발송은 등급과 시간대로 나눕니다
• 이력 데이터 보존 정책: 어떤 태그를 초 단위로 남기고 어떤 태그를 분 단위로 아카이브할지, 얼마나 보관하고 기한이 지나면 어디로 옮길지를 데이터베이스 구축 전에 정합니다. 사이트 수가 늘어난 뒤의 변경은 대가가 큽니다
• 통신 두절 펌프장의 데이터 보완: 게이트웨이가 로컬에 버퍼링했다가 회선 복구 후 다시 보내고, 플랫폼은 순서가 뒤바뀐 기록을 받아들이면서 이력 추세에 끊김을 남기지 않아야 합니다. 리포트 집계는 보완된 데이터로 다시 계산합니다

이 네 가지가 확정되면 펌프장 추가는 대체로 설정 작업이지 통합운영센터를 다시 설계하는 일이 아닙니다. 반대로 사이트가 늘어날 때마다 센터의 화면과 경보 규칙이 계속 바뀐다면 앞단 설계가 아직 수렴하지 않은 상태입니다.

템플릿이 줄여주는 것과, 템플릿이 대신할 수 없는 것

먼저 역량 범위를 분명히 해둡니다. 현재 확인된 현장 범위는 단일 펌프장의 IoT 게이트웨이 연동, ModbusTCP 데이터 수집, MQTT 클라우드 전송, 주소 테이블 정비입니다. 다중 사이트 표준 템플릿, 통합 감시 화면, 사이트 간 통합은 엔지니어링 자산이자 솔루션 역량에 해당하며, 여러 도시에 이미 구축을 마쳤다는 뜻은 아닙니다. 이 둘은 구분해서 다루어야 합니다.

템플릿이 줄여주는 것은 반복 설계입니다. 화면, 경보 정의, 리포트 구조, 태그 명명처럼 같은 시설 유형 안에서 거의 동일한 부분이 여기에 해당합니다. 템플릿이 대신할 수 없는 것은 현장별 인터페이스 확인입니다. 노후 설비에 통신 포트가 남아 있는지, 실제 프로토콜과 레지스터 맵이 도면과 일치하는지, 전원과 회선 조건이 충분한지는 펌프장마다 하나씩 확인할 수밖에 없습니다.

따라서 개별 펌프장의 납기와 비용은 인터페이스 조건, 현장 조건, 검수 범위에 따라 평가해야 하며 '1차 펌프장 공기 ÷ 사이트 수'로 추정할 수 없습니다. 경보 작업량도 마찬가지입니다. 저희는 약 30000점 규모의 경보를 다루는 대형 프로젝트에서 등급 구분, 복귀 아카이브, 이벤트 관리를 수행했고 그 방법은 다중 사이트에도 가져갈 수 있지만, 각 펌프장의 경보 항목은 실제 공정에 맞추어 다시 대조해야 합니다.