시제품 진동 데이터를 모아 검증 판단으로 연결하는 기준

먼저 판단 기준을 세워요

시제품을 만들 때 진동 값은 측정 자체보다 비교 가능한 기록으로 남기는 일이 중요해요. 같은 장치라도 측정 시점, 동작 조건, 주소와 단위가 달라지면 개발 전후의 차이를 설명하기 어려워요. 그래서 먼저 묻는 질문은 ‘값을 어디로 보낼까’가 아니라 ‘어떤 판단을 남길까’예요.

국가연구개발성과 정보는 연구개발사업에서 나온 보고서와 성과를 관리·공개하는 통로예요. 시제품 검증도 이 흐름처럼 측정 조건, 원시값, 변환값, 확인 시점을 함께 남겨야 다음 실험에서 같은 기준을 다시 볼 수 있어요. 진동 데이터는 정상 범위 하나만 보는 자료가 아니라 동작 단계별 변화와 반복 측정의 차이를 비교하는 재료가 돼요.

진동 데이터가 필요한 순간

진동센서를 붙인 목적을 고장 예측처럼 크게 잡기보다, 이번 실험에서 확인할 판단으로 좁히는 편이 좋아요. 예를 들어 모터 구동 전후의 값 비교, 특정 회전 단계의 반복성 확인, 시험 조건 변경 뒤 변화 기록처럼 질문을 한 문장으로 적어요. 그래야 센서 데이터 수집 주기와 보존할 필드가 자연스럽게 정해져요.

국가법령정보센터의 산업안전보건법은 작업환경 실태를 파악하기 위한 측정과 분석을 정의하고 있고, 관련 규칙은 진동 기계·기구의 관리와 작업자에게 알려야 할 사항을 다뤄요. 이 글은 법정 작업환경 측정 절차를 대신하지 않아요. 다만 시제품 데이터도 측정 조건과 관리 기준을 함께 기록해야 해석의 경계를 지킬 수 있다는 점을 참고할 수 있어요.

먼저 진동센서 필드명, 측정 단위, 시료화 조건, 시험 단계, PLC 원시 주소를 한 표에 놓아요. Vibration_RMS처럼 읽기 쉬운 이름을 써도 실제 주소와 데이터 타입은 현장 주소 맵으로 대조해야 해요. 한 대의 시험 장치와 한 공정 단계에서 시작하면 값의 의미와 전송 상태를 분리해 확인하기 쉬워요.

연결과 운영을 나눠요

EASY-LINK는 진동센서와 PLC의 신호를 수집해 정해진 전달 대상으로 보내는 게이트웨이 역할을 맡을 수 있어요. 현장 연결 계층이 필요한 경우에 충분하고, 측정 주기·저장 이력·전달 상태를 여러 장치에서 통합 관리하는 역할까지 대신한다고 보지는 않아요. PLC 연동 방식과 전송 목적지만 정리하면 단독 사용 범위를 먼저 판단할 수 있어요.

EASY LOGGER는 진동 데이터의 수집 주기와 저장 이력, 전달 상태를 관리하는 운영 계층과 대시보드 역할을 맡아요. 시제품 여러 대의 시험 기록을 비교하거나 담당자가 화면에서 누락 구간을 확인해야 한다면 함께 쓰는 편이 유용해요. EASY LOGGER만으로 센서가 PLC 주소를 자동으로 의미 있게 해석한다고 단정하지 말고, 주소 맵과 설정을 먼저 맞춰야 해요.

EASY LOGGER가 수집 주기와 저장 이력, 전달 상태를 관리하는 운영 계층의 예시예요.

전달 방식을 비교해요

HTTP API는 외부 검증 서비스나 연구관리 시스템이 정한 요청 형식에 맞춰 값을 전송할 때 판단하기 쉬워요. MQTT는 발행과 구독으로 여러 소비자가 같은 이벤트를 받을 때 편하고, MySQL은 외부 스키마에서 시험 기록을 조회·비교할 때 적합해요. Firebase는 서버를 별도로 두기 어려운 조회 화면에서 선택할 수 있지만, 어떤 방식이든 데이터의 출처와 시점을 함께 남겨야 해요.

이 글의 프로토콜 비교 기준은 속도가 아니라 확인 지점이에요. HTTP API는 응답과 Payload Log를 보고, MQTT는 Topic과 구독 상태를 봐요. MySQL은 외부 DB의 테이블과 기록을 조회하고, Firebase는 정한 경로의 값과 이력을 확인해요. MES나 CIM 같은 상위 시스템은 MQTT, HTTP API 또는 DB 인터페이스 연계로만 설계하고, 확인되지 않은 전용 커넥터를 전제로 삼지 않아요.

진동센서와 PLC 값을 게이트웨이에서 나눠 전달하고 검증 화면에서 비교하는 흐름이에요.

기록을 비교 가능한 형태로 만들어요

시험 기록에는 측정 시각, 장치 식별자, 시험 단계, 원시값, 변환값, 단위, 주소 맵 버전을 함께 두는 게 좋아요. 값이 달라졌을 때 센서 변화인지 PLC 변환 문제인지 HTTP API 전송 문제인지 순서대로 좁힐 수 있기 때문이에요. 데이터 추세 분석을 할 때도 한 번의 최고값보다 같은 조건에서 반복된 구간과 누락 구간을 먼저 표시해야 해요.

EASY-LINK만으로 충분한 경우는 한 장치의 값을 확인된 HTTP API로 전달하고 외부 시스템이 저장과 비교를 맡을 때예요. EASY LOGGER를 더하면 여러 장치의 수집 주기, 저장 이력, 전달 상태, 대시보드 화면을 한 운영 흐름으로 묶을 수 있어요. 제품 선택은 구매 조합이 아니라 누가 어느 화면에서 어떤 판단을 해야 하는지로 정하면 돼요.

제품의 연결 역할과 운영 역할을 더 구분하고 싶다면 산업용 데이터 수집 제품 소개를 살펴보고, 장비별 설정 항목은 제품 매뉴얼 자료실에서 확인해 보세요. 대시보드로 이력을 읽는 관점은 실시간 데이터 시각화 구성 가이드와도 이어져요.

작은 범위에서 검증해요

처음부터 시험 장치 전체를 묶기보다 한 대, 한 공정 단계, 한 HTTP API 요청으로 시작해요. 주소 맵과 Payload Log의 필드가 맞는지 확인한 뒤 측정 조건을 하나씩 늘리면, 설비 데이터 수집과 데이터 연동의 변경 원인을 기록하기 쉬워요. 누락이 생겼을 때는 진동센서 원시값, PLC 값, Runtime Status, 외부 응답 순서로 확인해요.

국책과제 개발에서 데이터 수집은 결과를 좋게 보이게 만드는 장치가 아니라 다음 판단을 재현하는 기록이에요. 시험 조건과 주소가 바뀌면 그 사실을 이력에 남기고, 결과가 기대와 달라도 원인을 분리해 다음 실험의 기준으로 삼아요. 현장 연결 가능 여부를 확인하고 싶다면 현재 센서 종류, PLC 주소 맵, 전달 대상과 확인할 화면을 정리해 상담해 보세요.

EASY LOGGER HTTP API 예제

아래의 PLC_NAME, CONFIG_NAME, D100, D102와 호스트명은 예시예요. 진동센서의 RMS 필드는 PLC 주소 맵의 D100과, 온도 보조 필드는 D102와 대응한다고 가정했으므로 실제 필드 주소 맵과 대조해야 해요. Automatic Endpoint Preview에서 요청 대상을 확인하고 Runtime Status와 Payload Log에서 전달 상태와 수신 필드를 이어서 봐요.

POST JSON and callback endpoint evidence are checked together in this example.

{
  "method": "POST",
  "endpoint": "http://LOGGER_HOST:8000/api/write/PLC/CONFIG",
  "payload": {
    "D100": 1,
    "D102": 23.77
  },
  "write_callback_url": "http://LOGGER_HOST:8000/api/write/PLC/CONFIG"
}

This is a POST JSON example for the external validation flow. The callback endpoint is http://LOGGER_HOST:8000/api/write/PLC/CONFIG; reconcile D100 and D102 meanings, units, and write range with the actual PLC field address map before use.

API Payload Log should show the same callback endpoint and the D100/D102 payload. Compare it with Runtime Status delivery state and the request target in Automatic Endpoint Preview.

WRITE CALLBACK을 호출할 때는 테스트 주소를 사용해요.

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

HTTP API의 응답과 Payload Log가 같은 시험 시각을 가리키는지 확인하면 전송 성공과 측정값 유효성을 분리해 판단할 수 있어요.