설비 모터 진동 추세를 기록하고 한 화면에서 읽는 구성

진동값을 기록해 두면 달라지는 판단

설비 담당자가 모터 이상을 알아채는 시점은 대체로 소리와 손끝의 감각입니다. 문제는 그 감각이 기록으로 남지 않는다는 점입니다. 지난달과 이번 주 중 어느 쪽이 더 심해졌는지 묻는 순간, 답할 근거가 사라집니다.

진동값을 일정한 간격으로 남겨 두면 판단의 성격이 달라집니다. "지금 이상한가"가 아니라 "4주 전 대비 얼마나 올라갔는가"를 놓고 정비 시점을 정할 수 있습니다. 베어링 교체를 이번 계획 정지 일정에 넣을지 다음 정기 점검까지 미룰지가 숫자로 정리되고, 예비품 발주 시점도 같은 근거를 씁니다.

한국생산기술연구원의 「회전기계 상태감시 시스템 개발」 보고서는 진동 가속도 RMS 값과 파워 스펙트럼을 상태 판정의 기본 지표로 제시합니다. 지표 자체는 오래전에 정리된 것이고, 현장에서 모자란 쪽은 대개 그 값을 끊기지 않게 모아 두는 경로입니다. 중소기업 전략기술 로드맵이 스마트팩토리 과제로 센서 기반 이상징후 감지를 꼽는 이유도 같습니다. 이 글은 그 경로를 어떤 순서로 구성하는지 다룹니다.

계층을 나누면 설정이 단순해집니다

구성은 세 개 층으로 나누어 잡습니다. 값을 재는 층, 값을 실어 나르는 층, 값을 쌓고 보여 주는 층입니다. 한 장비가 세 역할을 모두 떠안으면 통신이 끊겼을 때 어디부터 봐야 할지 판단하기 어렵습니다. 층을 나누어 두면 값이 안 보일 때 확인 순서가 정해집니다. 센서가 안 읽히는지, 전달이 끊겼는지, 저장이 막혔는지를 차례로 좁혀 갈 수 있습니다.

현장 계측 계층에는 EASY-LOGGER를 둡니다. 진동센서 값을 내보내는 변환기나 컨트롤러에 Modbus RTU로 붙어 정해진 수집 주기마다 값을 읽어 오는 자리입니다. RS485 한 포트에 여러 대를 물릴 수 있고, 이때 요청은 하나씩 순서대로 처리되므로 같은 포트에서 동시에 열리는 세션은 언제나 한 개입니다.

EASY-LINK는 그 사이의 연결 역할을 맡습니다. 장치가 측정값을 MQTT로 발행하면 상위 장비가 그 토픽을 구독해 받아 갑니다. 요청과 응답이 아니라 발행과 구독이라 방향이 반대이고, 브로커가 잠시 끊겨도 해당 설정만 SKIPPED로 표시되며 나머지 수집은 계속 돕니다. 복구되면 알아서 재개합니다.

상위에는 EASY LOGGER를 운영 계층으로 둡니다. 산업용 IoT 게이트웨이로서 값을 DB에 쌓고, MQTT와 HTTP API, OPC-UA로 내보내며, 게이지와 그래프로 표시합니다. EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인합니다.

계측·연결·저장 세 계층으로 나눈 진동 데이터 경로

Modbus RTU 수집 조건을 등록합니다

MAIN 설정에서 순서는 항상 같습니다. PLC 정보 입력, 연결 테스트, PLC 저장, 수집 조건 입력, 설정 저장, STATUS 확인입니다.

CONNECTION PROTOCOL에서 Modbus RTU를 고르면 COM 포트, Baudrate, Parity, Bytesize, Stopbits, Unit ID 입력란이 나타납니다. Unit ID는 1에서 247까지 넣을 수 있습니다. PLC NAME은 나중에 바꾸기 어렵습니다. MQTT 토픽과 API 엔드포인트, OPC-UA 노드 경로가 모두 이 이름을 기준으로 만들어지기 때문입니다. LINE1_VIB처럼 현장에서 통하는 이름으로 처음에 정해 두십시오.

수집 조건에서는 CONFIG NAME, PLC SELECT, TRIGGER TYPE, DATA TYPE, 시작 번지, 수집요청주기(ms), 디바이스 수를 넣습니다. 진동 RMS처럼 실수로 오는 값은 FLOAT를 고릅니다. FLOAT와 DWORD는 값 하나가 2 Word를 쓰므로 한 설정에 최대 200개이고, WORD와 BIT는 400개입니다. 저장 설정 목록의 STATUS가 RUNNING으로 바뀌면 정상입니다.

EASY LOGGER OPC UA 예제

OPC-UA는 상위 시스템이 값을 끌어가는 읽기 조회 경로로만 씁니다. 앞에서 정한 PLC NAME과 CONFIG NAME이 노드 경로에 그대로 들어가므로 클라이언트 쪽 주소를 따로 설계할 필요가 없습니다. 아래는 조회에 쓰는 접속 정보 형태입니다.

Endpoint       : opc.tcp://192.168.0.29:<OPCUA 설정 화면에 표시된 Port>
Node ID (base) : LINE1_VIB / VIB_RMS
Node ID (item) : LINE1_VIB / VIB_RMS / 40001
datatype       : FLOAT
access         : read only
Node Preview   : LINE1_VIB / VIB_RMS 하위에 디바이스 수만큼 노드 표시
Runtime Status : RUNNING

Node Preview에서 위 경로가 의도한 대로 나오는지 먼저 보고, Runtime Status가 정상으로 표시되는지 확인합니다. 화면 맨 아래 상태 표시등에도 OPCUA 항목이 항상 붙어 있어 어느 화면에 있든 연결 여부를 볼 수 있습니다. datatype이 수집 설정의 DATA TYPE과 어긋나면 값이 그럴듯하게 보이면서도 틀리게 들어오므로, Node Preview 단계에서 맞춰 두시기 바랍니다.

저장 대상은 MySQL로 두고 나머지는 보조로 씁니다

이 구성의 주 전달 대상은 MySQL입니다. 추세 그래프는 같은 값을 여러 번 되짚어 읽어야 하고, 기간을 지정한 조회와 CSV 출력이 필요하기 때문입니다. DB 설정에서 Host Address와 Port, User, Password를 넣고 연결 테스트로 확인합니다. MariaDB와 MySQL의 기본 포트는 3306입니다. DB 저장과 로컬 CSV 저장은 배타적이라 동시에 켤 수 없습니다.

MQTT는 값이 바뀔 때마다 곧바로 알려야 할 때 유리합니다. 대신 브로커에 남는 것은 마지막 값뿐이라 Retain을 켜도 이력 조회는 되지 않습니다. HTTP API는 상위 프로그램이 필요할 때만 당겨 가는 방식이라 붙이기는 쉬우나, 짧은 주기 추세를 만들려면 호출 횟수가 그만큼 늘어납니다. Firebase는 외부 화면을 빠르게 띄우기에 좋지만 사내망 밖으로 값이 나가는 구조이므로 설비망 정책과 먼저 맞춰야 합니다.

MES나 CIM 같은 상위 시스템과 붙일 때도 규격을 새로 만들지 않습니다. MQTT, HTTP API, 데이터베이스 세 가지 인터페이스 가운데 상대 시스템이 이미 쓰는 쪽을 고르면 됩니다.

추세 조회는 데이터베이스, 즉시 알림은 메시지 발행으로 나눈 전달 경로

모터 한 대로 먼저 확인해 보십시오

처음부터 라인 전체를 걸 필요는 없습니다. 문제가 잦았던 모터 한 대에 진동센서와 수집 설정을 걸고 2주치 추세가 쌓이는지 본 뒤, 같은 방식으로 단계적으로 범위를 넓히면 됩니다. 사무실에서 봐야 하는 원격 모니터링은 WireGuard VPN 설정을 뒤에 붙이는 순서가 안전합니다.

설비 목록과 통신 방식만 알려 주시면 현장 연결 가능 여부를 먼저 확인해 드립니다. 데이터 추세 분석을 어디까지 자동화할지는 그다음에 정해도 늦지 않습니다. 제품군 구성은 홈에서, 다른 현장 구성 사례는 블로그 글 목록에서 보실 수 있습니다. 같은 읽기 경로를 엣지 서버에 연결한 사례는 로봇 공정 상태 데이터를 OPC UA로 잇는 기준에 정리해 두었습니다.