스마트팩토리 설비 진동 값을 OPC UA로 읽어 상위 시스템까지 잇는 구성

진동 값이 설비 앞에서 멈추는 구간

스마트팩토리 현장에서 진동센서는 대부분 설비 판넬 안에서만 값을 냅니다. 담당자가 휴대용 계측기로 확인하고 수첩에 적는 순간, 그 값은 공정 이력이 아니라 개인 기록으로 남습니다. 값을 재는 지점, 값을 모으는 지점, 값을 보관하고 내보내는 지점이 따로 정해져야 설비 데이터 수집이 운영 자산이 됩니다.

EASY LOGGER 한 대가 맡는 일은 네 가지로 정리됩니다. MC Protocol과 LS F-NET/C-NET, Modbus TCP/RTU로 PLC 값을 주기적으로 읽고, 읽은 값을 MariaDB/MySQL 또는 장비 내부 CSV 파일에 남기며, 같은 값을 MQTT·HTTP API·OPC-UA로 외부에 전달하고, 대시보드 화면에 게이지와 그래프로 보여 줍니다. 제품군 소개는 홈에, 다른 구성 사례는 블로그 글 목록에 정리해 두었습니다.

세 제품이 나눠 맡는 역할

현장단 EASY LOGGER는 값을 재는 쪽에 가장 가까이 놓입니다. 진동센서 신호를 받은 PLC 주소를 MAIN 설정에서 등록하고, 수집 조건 설정에서 CONFIG NAME·TRIGGER TYPE·DATA TYPE·시작 번지·수집요청주기·디바이스 수를 넣으면 그때부터 값이 들어옵니다. FLOAT는 값 하나가 2 Word를 쓰므로 한 설정에서 최대 200개까지 읽습니다.

EASY-LINK는 그 값을 위로 올리는 연결 역할을 맡습니다. 다른 프로토콜과 방향이 반대라서, 상위 장비가 값을 요청하는 것이 아니라 EASY-LINK가 MQTT로 발행한 값을 상위 장비가 구독합니다. 구독 쪽에서는 SUBSCRIBE TOPIC과 ROOT KEY, ADDRESSES를 넣고 STALE AFTER (MS)를 지정해 수신이 끊긴 구간을 결함으로 잡습니다.

상위 EASY LOGGER는 저장과 표시를 맡는 운영 계층입니다. DB 설정에서 MariaDB/MySQL 접속 정보를 넣고 연결 테스트를 마치면 수집값이 쌓이기 시작하고, EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인합니다. 화면 아래 DB·PLC·API·MQTT·OPCUA 상태 표시등은 어느 화면에 있든 그대로 보입니다.

현장 신호가 수집·연결·저장 세 단계를 거쳐 상위로 올라가는 경로

EASY LOGGER OPC UA 예제

읽기 경로는 MAIN 설정에서 등록한 이름을 그대로 따라갑니다. 매뉴얼은 MQTT 토픽, API 엔드포인트, OPC-UA 노드 경로가 모두 PLC NAME과 CONFIG NAME을 기준으로 만들어진다고 못 박고 있습니다. 그래서 PLC NAME을 LINE1_VIB처럼 현장에서 통하는 이름으로 먼저 정하고, 수집 조건의 DATA TYPE을 실제 값 형식과 맞춘 뒤에 상위 클라이언트를 붙이는 순서가 안전합니다. 아래는 조회만 수행하는 구성입니다.

Endpoint: opc.tcp://192.168.0.29:(OPCUA 설정 화면에 지정한 포트)
PLC NAME: LINE1_VIB
CONFIG NAME: VIB_TREND
Node ID: PLC NAME 과 CONFIG NAME 기준으로 생성됨
datatype: FLOAT (수집 조건의 DATA TYPE 과 동일)
읽기 대상: ZR8000 시작, 디바이스 수 8
동작: READ 조회만 사용

값이 안 보이면 화면부터 봅니다. OPCUA 설정 화면의 Node Preview에서 등록한 CONFIG가 노드로 올라와 있는지 확인하고, Runtime Status가 정상인지 봅니다. 그다음 MAIN 설정의 저장 설정 목록에서 STATUS를 봅니다. IDLE이면 수집 조건이 걸리지 않은 상태이고, FAULT면 접속 정보와 주소 범위를 다시 확인합니다. PLC 연동 단계가 끝나지 않으면 노드는 만들어져도 값이 비어 있습니다.

HTTP API·MySQL·MQTT 중 무엇으로 넘길까

이 구성의 주 전달 대상은 HTTP API입니다. 상위 시스템이 필요한 시점에 요청해 가져가는 방식이라 호출 시각과 응답을 남기기 쉽고, 방화벽 정책도 한 방향으로 정리됩니다. 대신 값이 바뀌는 즉시 밀어 주지는 않으므로 초 단위 반응이 필요한 항목에는 맞지 않습니다.

MQTT는 값이 갱신될 때 바로 발행하는 쪽입니다. 반응은 빠르지만 브로커라는 중간 설비가 하나 더 늘고, 계정과 TLS, Retain 여부를 함께 정해야 합니다. MySQL 직접 저장은 조회와 이력 제출에 강합니다. DB 조회 화면에서 기간과 Config, Address, Data Type으로 걸러 CSV로 뽑을 수 있습니다. 다만 DB 저장과 로컬 CSV 저장은 동시에 켤 수 없으므로 현장 조건에 맞춰 하나를 고릅니다.

하나의 수집 값을 요청형과 발행형 경로로 나눠 내보내는 구성

MES·CIM으로 올릴 때의 인터페이스 정리

MES나 CIM 같은 상위 시스템과의 데이터 연동은 세 가지 인터페이스로만 설명하면 충분합니다. MQTT 구독, HTTP API 호출, 그리고 데이터베이스 직접 조회입니다. 상위 시스템이 어느 쪽을 표준으로 쓰는지 먼저 확인하고 나머지는 보조 경로로 남겨 둡니다.

이름 규칙은 먼저 굳히는 편이 좋습니다. PLC NAME과 CONFIG NAME은 운영을 시작한 뒤에 바꾸면 MQTT 토픽과 API 엔드포인트, OPC-UA 노드 경로가 전부 달라집니다. 진동 추세를 한 화면에서 읽는 구성은 설비 모터 진동 추세 기록 구성에서 따로 다뤘습니다.

설비 한 대로 먼저 검증하는 순서

처음부터 라인 전체를 붙일 필요는 없습니다. 진동센서가 물린 설비 한 대에서 PLC 등록, 연결 테스트, 수집 조건 저장, STATUS 확인까지 끝내고 같은 방식으로 범위를 넓히면 됩니다. 이 단계에서 수집요청주기와 디바이스 수 한도만 정리해 두어도 뒤에 붙는 설비는 복사에 가깝습니다.

계정 정리도 같이 합니다. 현장 작업자에게는 monitor, 설비 담당자에게는 editor 또는 admin 권한을 주고, 초기 비밀번호 admin은 설치 현장에서 바꿉니다. 어떤 경로가 맞을지 아직 정하지 못했다면 현장 연결 가능 여부만 먼저 확인해 보셔도 됩니다. 설비 목록과 PLC 기종만 알려 주시면 상담 단계에서 정리해 드립니다.