스마트팩토리 압축공기 유량을 MQTT로 모아 MySQL에 남기는 구성

압축공기 사용량은 왜 숫자로 남겨야 합니까

압축공기는 공장에서 전기 다음으로 비싼 유틸리티에 속하지만, 어느 라인이 얼마를 썼는지 숫자로 답할 수 있는 현장은 많지 않습니다. 요금은 매달 청구서로 오는데 사용 이력은 어디에도 남아 있지 않기 때문입니다.

세종특별자치시 에너지 절약 안내는 공기압축기에 고성능 제습설비를 적용하면 대기로 방출되어 낭비되는 10%의 압축공기를 2% 이내로 줄일 수 있고, 압축공기의 압력을 낮춰 가동 대수까지 줄일 수 있다고 설명합니다. 다만 이런 개선안을 실제로 집행하려면 개선 전후를 비교할 사용량 곡선이 먼저 있어야 합니다.

운영 판단에 필요한 값은 세 가지입니다. 라인별 순간 유량, 누적 사용량, 그리고 생산이 멈춘 시간대의 유량입니다. 야간과 휴일에도 유량이 떨어지지 않는다면 배관 누설을 의심할 근거가 됩니다. 값이 쌓여 있어야 누설 점검 시점을 감이 아니라 날짜로 정할 수 있고, 압축기 대수 조정이나 압력 하향도 근거를 갖고 논의할 수 있습니다.

반대로 값이 없으면 논의는 늘 같은 자리에서 멈춥니다. 누가 봐도 낭비가 있는 것 같은데 얼마인지 말할 수 없으니 투자 결정이 뒤로 밀립니다. 그래서 개선보다 계측과 기록이 먼저입니다.

유량계 값을 서버까지 옮기는 경로 설계

압축공기 메인 배관과 라인 분기에 설치하는 유량계는 대개 RS485 한 쌍으로 값을 내보냅니다. 이 신호를 사무동 서버까지 그대로 끌고 가면 배선 거리와 노이즈가 문제가 되고, 유량계를 한 대 더 붙일 때마다 선을 다시 깔아야 합니다. 현장 판넬에서 값을 한 번 받아 네트워크 메시지로 바꾸면 이 부담이 사라집니다. 이 지점에서 센서 데이터 수집 계층과 저장 계층을 나눠 설계합니다.

EASY-LINK는 이 구간의 연결 역할을 맡는 산업용 IoT 게이트웨이입니다. 판넬 안에서 유량계와 시리얼로 붙어 값을 읽고, 읽은 값을 MQTT 메시지로 브로커에 발행합니다. 상위에서는 배선이 아니라 토픽 하나만 알면 값을 받을 수 있습니다.

EASY LOGGER는 발행된 값을 구독해 쌓는 운영 계층입니다. MC Protocol, LS F-NET/C-NET, Modbus TCP/RTU로 PLC를 직접 읽는 것 외에, CONNECTION PROTOCOL에서 EASY-LINK를 골라 장치가 발행한 값을 구독하는 방향도 지원합니다. EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인하므로, 값이 비어 있는 구간이 저장 쪽 문제인지 현장 쪽 문제인지 구분됩니다.

압축공기 배관의 유량 값이 현장 판넬을 거쳐 서버 저장까지 이어지는 경로

수집 조건과 저장 설정 등록 순서

MAIN 설정의 PLC 연결 설정에서 CONNECTION PROTOCOL을 EASY-LINK로 고르고 PLC NAME을 넣습니다. PLC NAME은 MQTT 토픽과 HTTP API 엔드포인트, OPC-UA 노드 경로에 그대로 들어가므로 LINE3_AIR처럼 현장에서 통하는 이름으로 처음에 확정합니다. 브로커 출처는 자체 브로커를 쓰는 Self와 이미 돌고 있는 현장 브로커를 쓰는 External 중에 고르며, External이면 BROKER HOST, PORT, USERNAME, PASSWORD, CLIENT ID, TLS를 채웁니다.

수집 조건 설정에서는 주소를 계산하지 않고 메시지에 실려 오는 키를 그대로 씁니다. SUBSCRIBE TOPIC에 구독할 토픽을, ROOT KEY에 JSON 첫 단계 키를, ADDRESSES에 저장할 주소키를 쉼표로 구분해 넣습니다. TRIGGER는 메시지가 올 때마다 한 행을 남기는 On message와 주기마다 최신값 한 행을 남기는 Timer 중에 고릅니다. 수신이 끊긴 상황을 잡으려면 STALE AFTER (MS)를 넣어, 그 시간 동안 값이 없으면 null로 저장하고 결함으로 표시하게 합니다. 토픽 스캔을 누르면 실제로 들어오는 토픽과 키를 확인해 입력란을 채울 수 있습니다.

DATA TYPE은 장치가 보내는 형식과 맞춥니다. 매뉴얼은 Word를 WORD (UInt16)로 잘못 맞추면 음수가 양수로 바뀌어 -21095가 44441로 저장되고도 오류가 나지 않는다고 경고합니다. 저장 대상은 DB 설정에서 정하며, MariaDB와 MySQL은 Port 3306, 자체 DB 저장이면 Host Address에 127.0.0.1을 넣고 연결 테스트 후 저장합니다. DB 저장과 로컬 CSV 저장은 동시에 켤 수 없습니다.

EASY LOGGER MQTT 예제

MQTT 설정에서 브로커 주소와 Port를 넣고 Publish를 켜면 수집값이 외부로 나갑니다. 이 구성은 값을 내보내기만 하므로 Publish만 켜고 Subscribe는 끕니다. 발행 토픽은 PLC이름/CONFIG이름/READ 형태이며, 설정 저장 전에 Topic Preview에서 실제 문자열을 확인합니다. 아래는 LINE3_AIR에 AIR_FLOW_MAIN 수집 설정을 등록했을 때의 READ Topic과 payload 예입니다.

READ Topic : LINE3_AIR/AIR_FLOW_MAIN/READ

payload:
{
  "config": "AIR_FLOW_MAIN",
  "values": {
    "FLOW_NOW": 128.4,
    "FLOW_TOTAL": 918233
  }
}

values 안의 키는 수집 조건의 ADDRESSES에 넣은 주소키와 같습니다. 발행이 되고 있는지는 화면 아래 MQTT 상태 표시등과 Runtime Status에서 보고, 실제로 나간 메시지는 Payload Log에서 확인합니다. 저장 설정 목록의 STATUS가 RUNNING이면 정상이고, 브로커가 끊기면 그 설정만 SKIPPED로 바뀌었다가 복구되면 재개합니다.

MySQL·MQTT·HTTP API 중 어디로 보낼지

이 구성의 주 전달 대상은 MySQL입니다. 유량 이력은 주 단위, 월 단위로 비교해야 의미가 생기므로 기간 조회와 CSV 출력이 되는 데이터베이스에 남기는 편이 유리합니다. DB 조회 화면에서 테이블과 기간을 정하고 Config, Address로 범위를 좁혀 조회한 뒤 CSV로 뽑습니다.

MQTT는 실시간 전달에 강합니다. 값이 갱신될 때마다 구독 측이 바로 받으므로 현장 표시 화면에 적합하지만, 브로커가 끊긴 구간은 그대로 비어 이력 보관에는 부족합니다. HTTP API는 상위 시스템이 필요한 시점에 요청해 가져가는 방식이라 요청 기록이 남고 방화벽 정책이 엄격한 망에서 다루기 쉬운 대신, 요청 주기보다 짧은 변화는 놓칩니다. Firebase 같은 외부 클라우드 저장은 사외에서 보기 편하지만 회선이 끊기면 그 구간이 비는 점은 같습니다.

MES나 CIM과 붙일 때도 규격을 새로 만들지 않고 MQTT, HTTP API, 데이터베이스 세 인터페이스 중에서 고릅니다. 상위 시스템이 이미 MySQL을 보고 있다면 같은 데이터베이스에 테이블을 하나 늘리는 방식이 데이터 연동 비용이 가장 낮습니다.

실시간 전달과 이력 저장 경로를 나눠 그린 구성 예

한 대부터 붙여 보는 순서

스마트팩토리 현장에서 설비 데이터 수집 범위를 처음부터 넓게 잡으면 배선과 검증이 함께 늘어납니다. 압축공기 메인 배관의 유량계 한 대와 수집 설정 하나로 시작해, 값이 빠짐없이 쌓이는지 일주일 정도 확인한 뒤 라인 분기로 범위를 넓히는 순서가 안전합니다. 같은 방식으로 단계적으로 대상을 늘리면 토픽 이름 규칙도 자연스럽게 정리됩니다.

제품 구성은 HT Automation 홈에서, 다른 현장 사례는 블로그 글 목록에서 보실 수 있습니다. HTTP API와 MQTT를 함께 쓴 사례는 검사 데이터를 HTTP API와 MQTT로 운영에 잇는 설계 기준에 정리해 두었습니다. 도입 여부를 정하기 전에 쓰고 계신 유량계와 브로커 정보만 알려 주시면 현장 연결 가능 여부를 먼저 확인해 드립니다.