열처리 노 온도와 유지 시간을 값으로 남겨 품질 판단에 쓰는 구성

노 안의 온도는 왜 숫자로 남아야 합니까

열처리 공정은 목표 온도에 도달했는지보다 그 온도를 얼마나 유지했는지가 품질을 가릅니다. 그런데 현장에서는 조작 패널의 표시값을 눈으로 보고 작업일지에 옮겨 적는 방식이 아직 많습니다. 이 기록은 적어 넣은 순간의 값 하나만 남기고, 그 사이 몇 분 동안 온도가 어떻게 흔들렸는지는 남기지 못합니다.

문제가 생겼을 때 판단할 근거가 없다는 뜻입니다. 경도 편차가 난 로트를 두고 노의 상태인지, 장입량인지, 작업 순서인지 가르려면 그 시간대의 온도 곡선과 유지 시간이 필요합니다. 값이 없으면 원인 분석은 경험담으로 끝나고, 같은 불량이 다음 달에 다시 나옵니다.

값이 쌓이면 달라지는 운영 판단

중소벤처기업부의 2024년 스마트제조혁신실태조사에서 제조데이터를 수집하는 기업은 60.8%, 그중 분석까지 하는 기업은 52.1%로 조사되었습니다. 값을 모으는 일과 값을 쓰는 일 사이의 간격이 그대로 보이는 수치입니다. 그래서 센서 데이터 수집을 시작하기 전에 그 값으로 무엇을 판단할지부터 정하는 편이 좋습니다.

노 한 대의 온도가 초 단위로 남으면 판단 항목이 세 가지로 늘어납니다. 설정값 대비 실제 유지 구간을 계산해 로트별 품질 근거로 씁니다. 승온 시간이 길어지는 추세를 보고 히터와 단열재 교체 시점을 잡습니다. 야간 무인 운전에서 온도가 벗어난 시각을 특정해 다음 날 아침 확인 항목으로 넘깁니다. 판단이 정해지면 필요한 주기와 보존 기간도 따라서 정해집니다.

현장 값이 상위 계층까지 가는 경로

값을 재는 쪽과 값을 쌓아 보여 주는 쪽은 역할을 나누는 편이 관리하기 쉽습니다. 노 옆에는 열전대와 온도센서를 물린 수집 장치가 붙고, 그 값은 한 계층 위로 올라가 저장과 화면을 담당하는 장비가 받습니다. 두 계층을 잇는 방식으로는 MQTT 구독이 편합니다. 발행하는 쪽과 받는 쪽이 서로의 주소를 몰라도 되기 때문입니다.

EASY-LINK가 이 구간의 연결 역할을 맡습니다. 현장에서 잰 값을 정해진 토픽으로 발행하면 상위 장비가 그 토픽을 구독해 받아 갑니다. 브로커는 현장에 이미 돌고 있는 것을 써도 되고, 상위 장비가 가진 브로커를 그대로 써도 됩니다.

EASY LOGGER는 그 값을 받아 쌓는 산업용 IoT 게이트웨이이자 운영 계층입니다. MAIN 설정의 PLC 연결 설정에서 CONNECTION PROTOCOL을 EASY-LINK로 고르고, PRODUCT와 브로커 출처를 정합니다. 현장 브로커를 쓰면 External · 장치 브로커에서 BROKER HOST와 PORT, 계정, TLS를 넣고, 자체 브로커를 쓰면 Self · 관리자 MQTT 재사용을 골라 MQTT 설정 화면의 브로커를 그대로 씁니다.

수집 조건에는 SUBSCRIBE TOPIC, ROOT KEY, ADDRESSES, TRIGGER, STALE AFTER (MS)를 넣습니다. 토픽 스캔을 누르면 브로커에 실제로 들어오는 토픽과 키가 나오고, 결과를 클릭하면 입력란이 자동으로 채워집니다. STALE AFTER (MS) 동안 수신이 없으면 값은 null로 저장되고 결함으로 표시되며, 브로커가 끊긴 설정만 SKIPPED가 되고 나머지 수집은 계속 돕니다. EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인합니다.

구독 방식으로 올라온 값이 저장과 화면 계층으로 이어지는 구조입니다.

EASY LOGGER HTTP API 예제

API 설정 화면에서 내보낼 CONFIG을 고르면 Endpoint Preview에 실제 호출 주소가 만들어집니다. 주소는 PLC NAME과 CONFIG NAME을 기준으로 조립되므로 이름은 처음 등록할 때 현장에서 통하는 형태로 정해 두어야 합니다. POST 본문은 JSON 한 덩어리로 나가고, 쓰기 결과를 돌려받을 callback endpoint 주소는 write_callback_url에 넣습니다. 필드 이름은 화면에 표시된 형태를 그대로 따릅니다.

[PUBLISH] POST  Endpoint Preview에 표시된 주소
Content-Type: application/json

{
  "plc": "HEAT_LINK",
  "config": "FURNACE_TEMP",
  "root_key": "RTU1",
  "address": "40001",
  "value": 8624,
  "write_callback_url": "http://<상위-시스템-주소>/callback"
}

읽기만 쓸 때는 WRITE TOPIC을 비워 둔 채 운용하고, 값 보정처럼 쓰기 경로를 함께 열 때는 아래 경계를 지킵니다.

테스트 주소만 사용합니다.

최소 권한만 부여합니다.

허용 주소 범위를 제한합니다.

PLC 인터록을 확인합니다.

수동 복구 절차를 준비합니다.

WRITE CALLBACK을 호출합니다.

발행을 켠 뒤에는 API 설정 화면의 API Payload Log에서 실제로 나간 본문과 응답 코드를 시각과 함께 확인합니다. 화면 아래 STATUS 표시등의 API 항목이 정상인지, 실패 건이 반복되는지도 같은 자리에서 봅니다.

MQTT·HTTP API·MySQL 중 무엇으로 넘길 것인가

MQTT는 값이 갱신될 때마다 브로커로 밀어 주므로 화면 갱신이 빠르고 구독자를 늘리기 쉽습니다. 다만 순서와 누락을 어떻게 처리할지가 받는 쪽 몫으로 넘어갑니다. MySQL에 바로 넣는 구성은 조회와 이력 제출에 강하지만, 상위 시스템이 테이블 구조를 알고 있어야 하고 계정과 포트를 열어 주어야 합니다.

이 글의 주 전달 대상인 HTTP API는 요청 한 건마다 응답 코드가 돌아와 성공과 실패를 그 자리에서 가릅니다. 상위 시스템의 인증 체계를 그대로 쓸 수 있다는 점도 장점입니다. 반면 건당 오버헤드가 있어 100ms 고속수집 구간을 그대로 올리기에는 무겁습니다. 초 단위 주기로 충분한 열처리 공정에서는 HTTP API 쪽이 관리 비용이 낮습니다. MES와의 데이터 연동도 결국 MQTT·HTTP API·데이터베이스 세 인터페이스 가운데 무엇을 고르느냐의 문제로 정리됩니다.

전달 방식에 따라 확인 지점과 운영 부담이 달라집니다.

노 한 대로 시작해 범위를 넓히는 순서

스마트팩토리 과제라고 해서 전 라인의 설비 데이터 수집을 한꺼번에 열 필요는 없습니다. 온도 편차가 잦은 노 한 대에 먼저 붙여 2주간 값을 쌓고, 판단이 실제로 되는지 본 다음 단계적으로 범위를 넓히는 순서가 안전합니다. 첫 대에서 정한 이름 규칙과 주기가 그다음 설비에 그대로 복사되므로 확장은 빨라집니다.

구성 사례와 다른 공정 적용 예는 HT Automation 홈과 기술 블로그 목록에서 볼 수 있고, 같은 방식으로 유량 값을 다룬 압축공기 유량 수집 구성도 참고가 됩니다. 도입을 결정하기 전에 현재 쓰는 온도 조절기와 노 제어반 사양만 알려 주시면 현장 연결 가능 여부를 먼저 확인해 드립니다. 상담 단계에서 수집 주기와 보존 기간까지 같이 정리해 드립니다.