국책과제 개발 시험장비 전력 데이터를 HTTP API로 남기는 방법

먼저 정할 것: 측정값보다 기록의 기준이에요

국책과제 개발 현장에서 시험장비의 전력 데이터를 상위 검증 시스템으로 넘길 때는 ‘얼마나 많이 모으는가’보다 같은 조건의 데이터를 다시 읽을 수 있는지가 중요해요. 전력계의 유효전력, 전압, 전류, 역률처럼 측정 항목을 먼저 정하고 장비 식별자, 단위, 수집 시각, 시험 단계, 결측 상태를 함께 기록해야 해요. 이렇게 해야 연구개발 과정에서 조건이 바뀌었을 때 값의 차이를 설명할 수 있어요.

국가연구개발혁신법은 연구개발성과의 유지·관리와 정보의 공개·연계를 다루고 있고, IRIS 공고도 실험검증과 성능검증 같은 산출물을 구분해요. 그래서 이 글에서는 지원이나 평가 결과를 말하지 않고, 시험 데이터를 재현 가능한 형태로 남기는 연결·전달 구조만 다뤄요.

전력계에서 검증 시스템까지 데이터 흐름

권장 흐름은 전력계·시험장비 → PLC 또는 계측 인터페이스 → EASY-LINK → HTTP API → 상위 검증 시스템이에요. 현장에서는 전력계의 측정 필드와 PLC 주소를 먼저 매핑하고, 원시값과 변환값을 구분해요. 예를 들어 active_power, voltage, current, power_factor라는 필드에 단위와 수집 시각을 붙이면 나중에 동일한 시험 조건을 다시 찾기 쉬워요. 주소와 필드명은 장비 매뉴얼에 있는 실제 맵을 기준으로 정해야 해요.

시험장비의 전력 데이터를 연결 계층에서 검증 시스템과 저장 경로로 나누어 전달하는 흐름이에요.

EASY-LINK는 LS XGT, Mitsubishi MC, Modbus RTU/TCP처럼 현장 장치에서 데이터를 수집하고 MQTT, HTTP API, MySQL, Firebase로 전달하는 산업용 IoT 게이트웨이 역할을 맡아요. 즉 연결과 전달의 경계를 담당해요. EASY-LINK만으로 충분한 경우는 전력계 한 대의 값을 정해진 형식으로 HTTP API에 보내고, 별도 이력·운영 화면이 필요하지 않을 때예요. 대시보드와 저장 이력은 EASY LOGGER의 운영 범위로 두고, EASY-LINK는 현장 연결과 전달에 집중해요.

HTTP API·MQTT·MySQL·Firebase 선택 기준

주 전달 대상이 HTTP API라면 검증 시스템이 요구하는 인증 방식, 요청 주기, 응답 코드, 재전송 기준, 실패 보관 위치를 먼저 확인해요. API는 필드와 스키마를 명시하기 쉽고 상위 애플리케이션과 연결하기 좋지만, 수신 서버가 중단됐을 때의 재전송과 중복 수신 처리를 함께 설계해야 해요.

MQTT는 발행과 구독으로 여러 소비자가 같은 데이터를 받을 때 편리하고, MySQL은 조회·보존·조건 검색이 필요한 외부 데이터베이스에 적합해요. Firebase는 모바일·웹 중심의 빠른 상태 공유가 필요할 때 검토할 수 있어요. 어느 방식이 항상 우월한 것은 아니며, 이 글의 주 경로는 HTTP API이고 MQTT·MySQL·Firebase는 검증된 대안으로 비교하는 범위예요. MES·CIM은 MQTT, HTTP API 또는 DB 인터페이스를 통해 연결하는 상위 시스템으로 설명해요.

연구개발 데이터의 관리 항목을 더 넓게 잡아야 한다면 국책과제 개발 장비 이력 관리 기준에서 장비 상태와 운영 이력의 구분을 함께 살펴볼 수 있어요. 제품의 연결 범위는 산업용 IoT 게이트웨이 제품 정보에서 확인하면 돼요.

EASY LOGGER HTTP API 예제

EASY LOGGER까지 필요한 경우는 여러 시험장비의 수집 주기와 저장 이력, 전달 상태, 대시보드를 함께 운영해야 할 때예요. EASY LOGGER는 통합 수집과 저장 이력·전달 상태 관리, 대시보드 운영을 맡고, EASY-LINK는 현장 연결과 전달 경로를 맡는 식으로 경계를 나누면 좋아요. 현장 필드 active_power가 실제 PLC 또는 Modbus 주소 POWER_ADDR에 매핑된다는 가정은 예시일 뿐이며, 실제 주소 맵과 대조해야 해요.

아래는 테스트 서버를 향한 POST JSON 예시예요. write_callback_url은 쓰기 동작을 뜻하는 callback endpoint 예시이며, 실제 주소와 권한은 운영 환경에서 별도로 확정해야 해요.

{
  "device_id": "POWER_METER_01",
  "measurement": "active_power",
  "value": 123.4,
  "unit": "kW",
  "captured_at": "2026-08-12T06:00:00Z",
  "write_callback_url": "https://example.test/api/write-callback"
}

이 예시의 active_power와 POWER_ADDR 매핑을 먼저 확인한 다음 Automatic Endpoint Preview에서 요청 경로와 필드를 확인해요. Runtime Status에서는 수집·전달 상태를 보고, API Payload Log에서는 실제 POST JSON과 응답·재시도 이력을 확인해요.

WRITE CALLBACK을 호출할 때는 아래 다섯 경계를 같은 순서로 지켜야 해요.

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

상위 검증 시스템이 같은 payload를 중복으로 받지 않도록 device_id, 측정 시각, 시험 단계, 원본 식별자를 조합한 키를 협의해요. 이 키의 구체적인 저장 스키마는 시스템 담당자가 정하고, EASY LOGGER 내부 스키마라고 단정하지 않아요.

한 장치에서 시작해 수집 상태와 HTTP API 전달 이력을 확인한 뒤 범위를 넓히는 운영 흐름이에요.

한 장치·한 공정에서 검증하는 순서

처음부터 모든 시험장비를 연결하지 말고 전력계 한 대와 한 공정의 한 시험 단계로 시작해요. 첫 단계에서는 원본 표시값과 수집값을 같은 시각에 비교하고, 단위 변환·소수점·시간대·결측 처리 규칙을 문서화해요. 다음에는 HTTP API 수신 서버를 테스트 주소로 연결해 응답 코드와 재전송을 확인하고, 마지막에 EASY LOGGER의 저장 이력과 대시보드에서 수집 시각과 전달 상태를 함께 살펴봐요.

확장할 때는 장비 식별자와 필드명 규칙을 고정한 뒤 두 번째 장비를 추가해요. 전력계가 정상 범위의 값을 내더라도 마지막 수신 시각이 오래됐다면 데이터 경로가 멈춘 것일 수 있으니, 값 자체와 Runtime Status를 분리해 판단해야 해요. 이 과정은 연구 데이터를 재현 가능한 형태로 남기는 운영 기준을 만드는 데 도움이 돼요.

마무리: 연결 가능 여부부터 확인해요

HTTP API 연계가 필요한지, MQTT나 외부 MySQL이 더 맞는지는 상위 검증 시스템의 수신 방식과 보존 요구를 먼저 보면 결정할 수 있어요. EASY-LINK만으로 연결·전달을 끝낼지, EASY LOGGER로 저장 이력·전달 상태·대시보드까지 운영할지도 장비 수와 확인 주기에 따라 나누면 돼요.

실제 도입을 서두르기보다 전력계 모델, PLC 또는 Modbus 주소 맵, 측정 필드와 단위, HTTP API 샘플, 현장 네트워크 조건을 정리해 현장 연결 가능 여부부터 확인해 보세요. 관련 설정을 더 살펴보려면 EASY LOGGER API 사용 안내와 자료실에서 현재 버전에 맞는 내용을 확인하면 좋아요.