SCADA 패키지인가 자체 개발인가｜상위 감시 소프트웨어의 기술 선정

선정에서 빠지기 쉬운 네 가지 제약

기술 비교는 기능 목록의 대결이 되기 쉽습니다. 알람, 트렌드, 리포트, 프로토콜. 이 기능은 패키지로도 자체 개발로도 구현할 수 있습니다. 차이는 엔지니어링 방식입니다. 이후 유지와 설비에 붙여 출하할 수 있는지를 가르는 것은, 계약서와 기술 협의서에서 애매해지기 쉬운 다음 네 가지입니다.

• 지식재산: SCADA 엔지니어링은 벤더 런타임 라이선스에 의존하며, 소스 프로젝트를 그 플랫폼에서 떼어 단독 공개하는 일은 보통 불가능합니다. 자체 개발 코드의 저작권과 납품 형태는 계약에 쓸 수 있습니다. 장치 메이커가 표준기에 소프트웨어를 붙여 출하할 때, 이 항목이 팔 수 있는지를 가릅니다
• 양산 복제: 같은 기종을 열 대, 쉰 대 낼 때 패키지는 태그 수 또는 런타임 라이선스로 프로젝트를 복제합니다. 자체 개발이면 핵심 로직을 설정으로 바꾸는 제품 패키지로 만들어, 화면을 다시 그리는 대신 기종 단위로 라이선스할 수 있습니다
• 라인 설비와의 깊은 결합: 감시 화면은 상태 읽기와 소량 설정 쓰기가 중심입니다. 공정 알고리즘, 레시피 전환, 인터록 판정을 PLC에서 상위기로 올리는 단계가 되면, 패키지 스크립트 능력은 곧 경계에 닿습니다
• 이후 스스로 고치기: 라인이 공정을 하나 바꾸고 계기를 한 대 더할 때, 현장은 화면을 스스로 고치고 싶어 합니다. 패키지의 강점이 바로 여기입니다. 핵심 로직이 암호화 프로젝트나 유지하기 어려운 스크립트에 있으면, 현장 엔지니어는 손댈 수 없어 다시 외주를 냅니다

이 네 가지에 맞고 틀림은 없습니다. 납품 형태와 맞는지만 있습니다. 반도체 전공정 설비나 디스플레이 라인의 감시실과, 표준기에 붙여 출하하는 상위 소프트웨어는 같은 종류의 소프트웨어라도 제약이 다릅니다.

SCADA 패키지가 맞는 조건

패키지의 강점은 감시 쪽 엔지니어링이 이미 끝나 있다는 점입니다. 드라이버, 알람, 트렌드, 권한, 이중화는 바로 쓸 수 있고, 현장에서 화면을 고치는 속도도 빠릅니다. 여러 브랜드 패키지를 깊게 다루는 것 자체가 납품 능력입니다. 현장이 이미 가진 플랫폼 위에서 이어 갈 수 있고, 스택 변경을 강요하지 않습니다.

• 요구의 중심이 감시·조작·알람·트렌드·리포트이고, 공정 판정은 PLC에 남긴다
• 현장이 이미 주류 패키지를 지정했거나, 중앙 감시실·유틸리티 감시가 그 플랫폼에서 돌아가고 있다
• 라인 개조마다 화면이 자주 바뀌고, 현장 엔지니어가 스스로 고치기를 원한다. 매번 개발팀으로 되돌리고 싶지 않다
• 안건이 단일 공장 또는 단일 라인의 감시 엔지니어링이며, 「설비에 붙여 양산 출하」가 납품 형태가 아니다
• 짧은 주기로 감시 화면과 태그표를 세우고 싶다. 검수는 화면과 알람이 쓰이는지를 본다

자체 개발 / .NET이 맞는 조건

자체 개발은 「한 단계 위의 패키지」가 아닙니다. 납품물이 바뀌는 것입니다. 소스, 설정, 설치 패키지를 계약에 따라 장치 메이커나 공장 소유로 둘 수 있고, 핵심 알고리즘을 제품으로 반복할 수 있습니다. C#/.NET, VB, LabVIEW를 장면마다 조합하는 이유는 시험대, 표준기, 라인 쪽 클라이언트가 요구하는 실시간성, 화면, 계측기 인터페이스가 같지 않기 때문입니다.

• 소프트웨어를 표준기에 붙여 출하하고, 지식재산은 장치 메이커에 남긴다. 특정 벤더 런타임에 묶이지 않는다
• 같은 기종을 복제 납품한다. 핵심 로직은 설정 변경으로 코드를 건드리지 않고, 프로젝트를 다시 만드는 대신 기종 단위 라이선스로 한다
• 공정 알고리즘, 레시피, 인터록, 시험 단계를 PLC에서 상위기로 올려 관리와 제어를 하나로 둔다
• MES, 이력 추적, 비전, 시험대 계측기와 깊게 연결해야 하며, 패키지 스크립트로는 받기 어렵다
• 공장 또는 장치 메이커에 소프트웨어 팀이 있어, 이후 로직과 모듈을 더할 때 플랫폼 라이선스와 스크립트 능력에 묶이고 싶지 않다

대조표: 관점, SCADA 패키지, 자체 개발 상위기

「맞는지」를 표로 쓰면 선정 회의에서 인식이 맞추기 쉽습니다. 아래 표는 기능 점수가 아니라 제약 대조입니다. 같은 행의 두 경로는 둘 다 동작합니다. 차이는 라이선스 형태와, 이후에 누가 고칠 수 있는가입니다.

병용: 감시는 패키지, 핵심 알고리즘은 상위기로

현장에서 흔한 것은 둘 중 하나가 아니라 층 나눔입니다. 패키지가 감시 화면, 알람, 트렌드, 권한을 맡고, 검증된 드라이버와 이중화는 그대로 씁니다. 핵심 공정 알고리즘, 레시피 전환, 인터록 판정, MES나 비전과의 인터페이스는 .NET 상위기 또는 서비스에 둡니다. 양쪽은 OPC UA, 중간 데이터베이스, 메시지 채널로 태그 값과 이벤트를 주고받습니다.

이렇게 나누면 감시 쪽 화면 변경은 빠른 채로 두고, 제품 쪽 알고리즘과 지식재산은 스스로 통제할 수 있는 코드에 남깁니다. 단일 프로젝트가 수십 화면에서 수천 화면이 될 때, 감시 화면은 패키지로 펼치고, 판정을 맡는 소수 화면이나 백엔드 서비스는 자체 개발로 받습니다. 전제는 태그표, 이벤트 정의, 권한 모델을 양쪽이 공유하는 인터페이스 설명으로 먼저 적는 것입니다. 적지 않으면 두 소프트웨어는 따로 어긋납니다.