공작기계 데이터 흐름을 OPC UA와 MQTT로 비교하는 기준

먼저 데이터가 필요한 이유부터 볼게요

공작기계의 상태값은 화면에 한 번 나타나는 것보다 같은 기준으로 이어서 비교될 때 운영 판단에 도움이 돼요. 가동 상태, 작업 단계, 알람 상태처럼 시간이 지나며 바뀌는 값은 수집 시각과 원래 노드의 의미가 함께 남아야 해요. 그래야 멈춤처럼 보이는 구간이 실제 설비 상태인지, 수집 경로의 공백인지 나눠 볼 수 있어요.

현장에서 먼저 정할 질문은 ‘무엇을 연결할까’보다 ‘어떤 결정을 빠르게 할까’예요. 한 대의 공작기계가 작업을 시작했는지, 여러 장비의 상태가 같은 시간대에 바뀌었는지, 상위 시스템에 어떤 기록을 넘길지 정하면 필요한 값과 확인 화면이 좁혀져요. 처음부터 모든 태그를 가져오기보다 운영 질문에 필요한 상태값부터 고르는 편이 좋아요.

국내 연구에서도 이기종 CNC 장비의 생산 데이터를 일관된 방식으로 해석하고 상위 애플리케이션과 연계하려는 OPC UA 기반 구조가 다뤄졌어요. 이 근거는 특정 장비의 실제 설정값을 뜻하지 않으므로, 현장에서는 제조사 주소 공간과 데이터 타입을 별도로 대조해야 해요.

연결 계층과 운영 계층을 나눠요

EASY-LINK는 공작기계와 PLC의 신호를 수집해 정해진 전달 대상으로 보내는 게이트웨이 역할을 맡을 수 있어요. 현장 연결과 전달 경로를 단순하게 확인하는 데 충분한지 먼저 살펴보고, 제품이 공작기계의 모든 의미를 자동으로 해석한다고 전제하지는 않아요. 실제 노드와 필드의 대응은 제조사 문서와 현장 주소 맵으로 확인해야 해요.

EASY LOGGER는 수집 주기, 저장 이력, 전달 상태, 대시보드를 묶어 보는 데이터 로거이자 운영 계층으로 검토할 수 있어요. 여러 장비의 작업 상태를 비교하거나 누락 시각을 담당자가 화면에서 확인해야 한다면 도움이 돼요. 한 대의 값을 외부 목적지로 전달하고 외부 시스템이 이력을 관리한다면 EASY-LINK만으로 충분할 수 있고, 운영 이력을 한 화면에서 관리하려면 EASY LOGGER를 더하는 식으로 범위를 나눠요.

제품 소개의 연결 범위는 산업용 데이터 수집 제품 안내에서 살펴볼 수 있고, 주소와 설정을 확인할 때는 제품 매뉴얼 자료실을 함께 봐요.

목적지별 선택 기준

OPC UA는 서버의 주소 공간에서 변수와 메서드의 의미를 구조적으로 확인하며 읽고 쓸 때 기준을 세우기 좋아요. MQTT는 발행·구독으로 여러 소비자에게 같은 이벤트를 전달할 때 편하고, HTTP API는 외부 애플리케이션이 정한 요청 형식과 응답을 확인하기 좋아요. MySQL은 외부 스키마의 테이블과 기록을 조회해 기간별 비교를 만들 때 적합하고, Firebase는 정한 경로의 최신값과 이력을 화면에 연결할 때 검토할 수 있어요.

비교 기준은 ‘가장 빠른 방식’ 하나가 아니라 확인 지점이에요. OPC UA는 Automatic Node Preview와 Runtime Status에서 노드와 연결 상태를 보고, MQTT는 Topic과 Payload Log를 봐요. HTTP API는 요청·응답과 Payload Log를, MySQL은 외부 DB의 테이블·쿼리 결과를 확인해요. MES나 CIM 같은 상위 시스템은 MQTT, HTTP API 또는 DB 인터페이스로 연계한다고 설명하며 확인되지 않은 전용 커넥터를 전제로 삼지 않아요.

공작기계 상태값을 노드에서 읽어 목적지별 확인 화면으로 나누는 흐름이에요.

판단을 더 구체화하려면 진동 데이터의 MQTT·MariaDB 설계 관점처럼 원시값과 저장 목적을 분리해 보는 글도 참고할 수 있어요. 다만 이 글의 공작기계 상태값과 OPC UA 노드는 해당 글의 진동 측정군을 그대로 반복하는 내용이 아니에요.

운영 화면에서 확인할 순서

수집 주기와 노드 이름만 정해 두면 운영이 끝나는 것은 아니에요. 먼저 노드의 현재값과 데이터 타입이 주소 맵과 맞는지 보고, 다음으로 Runtime Status에서 연결 상태와 마지막 수신 시각을 확인해요. 그 뒤 Payload Log나 외부 DB 기록에서 같은 시각의 값이 전달됐는지 비교하면 누락 위치를 좁힐 수 있어요.

작업 상태를 대시보드에 보여줄 때는 현재 상태와 이력을 한 카드에 섞지 않는 편이 좋아요. 현재값은 지금 판단에 쓰고, 저장 이력은 작업 구간을 비교하는 데 써요. EASY LOGGER 대시보드에서는 이 두 확인 목적을 나눠 구성하는 운영 흐름을 검토할 수 있고, 상위 시스템에는 필요한 필드만 MQTT·HTTP API·DB 인터페이스로 넘겨요.

한 대에서 시작해 작업 구간과 운영 범위를 넓혀 가는 확인 순서예요.

처음에는 한 대, 한 공정, 몇 개의 노드로 시작해요. 값의 의미와 연결 상태가 맞는지 확인한 뒤 작게 범위를 넓히면, 데이터 연동 변경이 작업 상태 변화인지 설정 변경인지 구분하기 쉬워요. 이 과정에서 EASY-LINK는 현장 신호를 모아 보내는 역할에 집중하고, EASY LOGGER는 저장 이력과 전달 상태를 관리하는 역할로 나눠 보는 게 안전해요.

EASY LOGGER OPC UA 예제

아래의 EDGE_SERVER_HOST, Greenhouse/Zone01/Pressure, Float은 설명을 위한 예시 이름이에요. 공작기계의 작업 상태 필드는 실제 OPC UA 주소 공간에서 확인한 Node ID와 대응해야 하며, 샘플 PLC·설정·주소 이름은 현장 필드 주소 맵과 대조해야 해요. Automatic Node Preview에서 endpoint와 Node ID를 확인한 뒤 Runtime Status에서 읽기·쓰기 연결 상태를 확인해요.

endpoint: opc.tcp://EDGE_SERVER_HOST:4840
nodeId: ns=2;s=MachineTool/Line01/WorkState
dataType: String
read: enabled
write: enabled

위 블록의 작업 상태 필드는 실제 서버가 제공하는 노드의 의미와 데이터 타입을 확인한 뒤 읽기 대상으로 정해요. 쓰기 항목을 검토할 때도 같은 노드의 권한과 PLC 인터록을 먼저 대조하고, Runtime Status의 상태 기록으로 연결 결과를 확인해요.

• 테스트 노드만 사용합니다.
• 최소 권한만 부여합니다.
• 허용 노드 범위를 제한합니다.
• PLC 인터록을 확인합니다.
• 수동 복구 절차를 준비합니다.

OPC UA 예제는 실제 장비에 그대로 복사하는 설정이 아니라 주소 맵과 서버 정책을 맞추는 확인 순서예요. OPC UA의 구조화된 노드가 필요한 경우와, 여러 소비자가 같은 이벤트를 받아야 하는 경우의 MQTT를 비교하면 목적지가 더 분명해져요.

현장 연결 가능 여부를 확인하고 싶다면 현재 공작기계의 서버 endpoint, Node ID, 데이터 타입, 필요한 목적지와 확인할 화면을 정리해 상담해 보세요. 한 대에서 읽기 흐름을 확인한 뒤 운영 범위를 넓히는 방식이면 도입 판단도 가볍게 시작할 수 있어요.