구형 SCADA 업그레이드 로드맵

구형 시스템은 어느 단계인가: 먼저 교체 신호를 확인한다

"업그레이드해야 하나"로 고민을 거듭하는 공장이 많지만, 노후 SCADA가 생산에 부닥치기 시작하는 신호는 꽤 분명합니다. 다음 네 가지 중 하나라도 해당되면 업그레이드를 일정표에 올릴 때입니다.

• 부품과 라이선스 조단: 보드, 네트워크 카드, 도글이 단종되어 구할 수 없고, 운영체제나 SCADA 소프트웨어 라이선스 갱신도 불가능하다;
• 실행 환경의 낙후: 지원이 오래전에 끝난 운영체제 위에서 상위 시스템이 계속 돌아간다. 예컨대 2014년 4월에 지원이 종료된 Windows XP, 2020년 1월에 종료된 Windows 7은 패치와 보안 업데이트 공급원 자체가 없다;
• 담당자의 단절: 파라미터, 스크립트, 연혁 로직에 밝은 엔지니어가 이동하거나 퇴직하여 신입이 인수인계를 받지 못한다;
• 변경의 곤란: 측정점 하나를 추가하고 화면 한 장을 고치는 일도 구형 코드를 건드리는 일이 되어 아무도 손대지 못하고, 수정 비용이 신규 구축 한 세트에 버금간다.

업그레이드 로드맵: 다섯 단계의 진행 방식

업그레이드를 결정했다면 손대기 전에 먼저 노선을 정합니다. 안정적으로 진행되는 순서는 다음과 같습니다.

• 평가와 착수: 태그 규모, 인터페이스 종류, 화면 수, 가동 연수를 세고 "업그레이드로 무엇을 해결할 것인가"를 명확히 한다. 부품 단종인지, 시스템 부하인지, MES·데이터 플랫폼 연계인지에 따라 노선이 달라진다;
• 자산 조사: 구형 시스템의 자산을 항목별로 목록화하여 신규 시스템의 요구사항 입력으로 삼는다. 이 단계는 생략할 수 없다;
• 병행 운전: 신구 양 시스템에 동일 신호를 입력해 일정 기간 가동하며 데이터·화면·경보 동작을 항목별로 대조한다;
• 단계별 전환: 공정(워크숍) 단위로 신규 시스템으로 전환한다. 영향이 적은 보조 공정부터 시작해 주 생산라인을 마지막에 전환하고, 각 회차마다 관찰 기간을 둔다;
• 인수와 문서 인계: 연속 가동 기준을 충족한 시점에 정식 인수를 진행하고, 운영 교육과 문서·소스프로그램 인계를 동시에 마친다.

자산 조사: 다섯 개의 목록

병행 운전 전 조사의 품질이 전환 당일의 리스크 크기를 결정합니다. 다섯 목록은 표로 만들어 진행하는 것이 좋습니다.

병행 운전 기간에 검증할 것

병행 운전은 "켜두고 보는 것"이 아니라 체크리스트에 따른 대조입니다. 이 기간에 검증할 네 가지는 다음과 같습니다.

• 데이터 일치: 동일 측정점의 표시값·이력 곡선·기록 주기가 신구에서 일치하는지. 특히 범위 환산과 불량점 처리를 대조한다;
• 화면과 조작 정합: 운영자가 기존 습관 그대로 신규 시스템에서 기동·정지와 설정 변경을 수행하며 버튼 위치와 확인 로직에 모호함이 없는지 확인한다;
• 경보 동작 비교: 동일한 외란에 대해 신구가 경보 발생·분류·기록을 동일하게 하는지. 전환 당일의 경보 누락이나 경보 폭풍을 피하기 위해서다;
• 경계와 이상 시나리오: 통신 두절, 정전, 재기동 복구를 항목별로 연습하여 신규 시스템의 복구 동작이 구형과 동등하거나 더 나은지 확인한다.

전환과 인수의 마무리

전환 당일의 질서는 사전에 작성된 절차에서 나옵니다. 마무리 단계에서 확실히 할 네 가지입니다.

• 전환 절차와 롤백 절차의 문서화: 언제, 어느 공정을, 누가 확인하여 전환하는지. 구형 시스템으로 되돌리는 조건과 절차도 함께 문서화하여 현장에서의 즉석 판단을 없앤다;
• 연속 가동 기준 충족 후 정식 인수: 연속 가동 기간과 판정 기준(예: 신규 시스템 원인의 정지 없이 한 차례의 생산 사이클 완주)을 사전에 정하고, 충족 전에는 완료로 보지 않는다;
• 이력 데이터의 이전과 조회성 확보: 구형 시스템에 약정 주기로 기록된 이력 데이터의 행선을 확보하고, 전환 후에도 종전 방식대로 곡선을 조회할 수 있게 한다. 생산 추적성의 최저선입니다;
• 문서·교육·소스의 동시 인계: 인수 서명 시점에 운영 매뉴얼, 화면 설명, 태그 목록, 프로젝트 소스 파일, 교육 기록을 한 세트로 인계한다. "시스템은 있는데 자료는 없다"는 상황을 남기지 않는다.

업그레이드에서 반복되는 네 가지 리스크

진행 방식이 올바르더라도 다음의 함정은 반복해서 나타납니다.

착수 전에 갖추어야 할 정보

이 정보를 갖추고 상담하면 로드맵이 곧바로 일정에 옮겨집니다: 구형 SCADA 소프트웨어의 이름과 버전, 상위기 운영체제, 태그와 화면 규모, PLC·계기와의 접속 방식, 이력 데이터의 축적량과 기록 주기, 수용 가능한 정지 전환 구간, 그리고 업그레이드로 먼저 해결할 과제. 상하이청쉬안인텔리전트(Shanghai Chengxuan Intelligent)는 2009년부터 산업용 소프트웨어와 설비 연계 분야의 엔지니어링을 수행해 왔으며 SCADA·상위 시스템의 개발과 업그레이드 개조를 지원합니다. 상기 목록에 기반한 현황 평가에서 단계별 업그레이드 노선과 병행 운전 방안 제시, 한국어 대응 창구를 통한 상담이 가능합니다.

역사적 배경: 구형 플랫폼은 왜 낡았는가

오늘날 "구형"이라 불리는 플랫폼도 만들어진 당시에는 주류 선택이었습니다. Modbus는 1979년에 발표되어 지금도 시리얼과 이더넷 경로에서 널리 쓰이는 통신 프로토콜입니다. OPC UA는 2008년에 발표되어 훗날 IEC 62541로 표준화된, 플랫폼 간 데이터 상호운용의 주류 표준입니다. 플랫폼이 낡은 것은 당시 선택이 틀렸기 때문이 아니라 삼십 년 사이에 실행 환경이 여러 세대 바뀌었기 때문입니다. 운영체제, 보안 요구, 데이터의 용도가 모두 변했습니다. 이렇게 보면 업그레이드는 과거의 부정이 아니라 자산을 계속 유지보수할 수 있는 환경으로 옮기는 작업입니다.