국책과제 시험 압력 데이터를 Mitsubishi PLC에서 MySQL로 잇는 기준

먼저 맞출 것은 장비보다 데이터 계약이에요

국책과제 개발에서 시험 장비 데이터를 모을 때는 측정값을 많이 쌓는 일보다 나중에 같은 실험을 다시 읽을 수 있게 만드는 일이 먼저예요. 압력 값 하나에도 장비 ID, PLC 필드, 단위, 측정 시각, 수신 시각과 시험 단계가 함께 있어야 해요. 그래야 시제품 검증 결과를 비교할 때 센서 변화와 수집 지연을 섞지 않을 수 있어요.

이번 글은 Mitsubishi PLC에 연결된 압력센서 한 지점에서 시작해 외부 MySQL 이력으로 이어지는 인터페이스를 설명해요. RNDPLC01, PRESSURE_PV, D0120, kPa, float는 설명을 위한 예시이고 실제 센서 사양, PLC 프로그램과 현장 field address map을 대조해 확정해야 해요. 국가연구개발사업 연구관리 표준매뉴얼이 연구데이터 생산·관리 실적과 데이터 유형, 보존 기관·식별자 같은 항목을 제시하는 만큼, 수집 단계에서부터 기록의 의미를 정해 두는 편이 좋아요.

시험장비 필드와 PLC 주소를 나란히 적어요

압력센서의 원시 필드 PRESSURE_PV가 Mitsubishi PLC의 예시 주소 D0120에 대응한다고 가정해 볼게요. 이 매핑은 실제 field address map과 대조해 확정하고, kPa 변환 배율과 소수점 처리도 PLC 설정표에 남겨야 해요. measuredAt은 센서·PLC에서 값이 만들어진 시각이고 receivedAt은 수집 계층이 받은 시각으로 분리해요.

이 표를 먼저 정하면 MQTT는 상태를 여러 소비자에게 나누는 경로, HTTP API는 운영 서버의 endpoint와 요청·응답 계약, MySQL은 외부 스키마의 보존·검색 경로, Firebase는 여러 화면에서 현재 상태를 공유하는 경로로 비교할 수 있어요. 어느 경로가 더 좋다고 단정하기보다 시험 결과의 원본성, 조회 방식, 담당 권한을 기준으로 선택해야 해요.

Mitsubishi PLC 현장 필드를 목적지로 연결하는 EASY-LINK의 공식 승인 이미지예요.

연결과 운영 계층을 나눠요

EASY-LINK는 확인된 Mitsubishi PLC 필드를 읽어 MQTT, HTTP API, MySQL, Firebase 같은 확인된 전달 경로로 연결하는 현장 연결 계층으로 설명할 수 있어요. 한 시험장비의 현재 압력값을 외부 MySQL에 남기고 연결 상태만 확인한다면 EASY-LINK 중심으로 시작할 수 있어요. 여러 장비의 수집 이력, 전달 상태와 Dashboard를 함께 운영해야 한다면 EASY LOGGER를 더하는 편이 좋아요.

EASY LOGGER는 저장 이력·전달 상태·대시보드 운영을 맡는 운영 계층이에요. EASY-LINK가 저장 이력이나 Dashboard를 단독으로 대신한다고 보지 않고, MES·CIM도 확인된 MQTT·HTTP API·DB 인터페이스로만 연계 범위를 협의해야 해요. 국가기술표준원이 산업 데이터 표준화와 상호운용성 실증 확대를 설명한 것처럼, 상위 시스템에 보내기 전 필드 이름과 시각의 의미를 먼저 맞추는 흐름이 중요해요.

관련된 국책과제 시험장비 가동 이력 운영 기준을 함께 보면 장비 상태와 데이터 이력을 나누는 질문을 비교할 수 있어요. 제품 역할과 버전별 설정 항목은 EASY 제품 매뉴얼 자료실에서 대조해 보세요.

전달 방식을 목적에 맞게 비교해요

MQTT는 시험 상태를 여러 구독자에게 전달하거나 수집 상태를 실시간에 가깝게 나눌 때 검토해요. HTTP API는 운영 서버가 정한 endpoint, 인증 방식, 요청·응답 필드를 계약으로 맞출 때 적합해요. MySQL은 외부 스키마에서 기간별 시험 기록을 조회하고 재현성 자료와 대조할 때 유리하고, Firebase는 현재 상태를 여러 화면에 공유할 때 비교할 수 있어요.

따라서 measuredAt, receivedAt, 장비 ID, 시험 단계와 단위를 네 경로에서 같은 의미로 유지하는지가 선택 기준이에요. 연구데이터를 외부에 공개하거나 공동 활용할지는 과제와 기관의 관리 기준으로 정하고, 이 글에서는 특정 과제의 공개·평가·선정을 보장하지 않아요. 데이터 표준화는 연계 가능성을 높이는 설계 기준이지 결과를 보장하는 절차는 아니에요.

EASY LOGGER MySQL 예제

아래 예시는 RNDPLC01의 PRESSURE_PV 필드가 예시 PLC 주소 D0120에 대응하고 kPa 단위의 float로 읽히는 상황이에요. 장비명·필드명·주소는 실제 field address map과 PLC 설정을 대조해 확정해야 해요. 수집한 필드가 외부 스키마 rndops의 외부 테이블 pressure_history로 들어간다고 가정하며, 이것은 EASY LOGGER 내부 스키마가 아니에요. DB History Logs에서 저장 성공·오류와 보존 상태를 확인하고 외부 DB 조회 결과의 measuredAt, receivedAt을 함께 대조해요.

SELECT equipment_id, field_name, pressure_kpa, measured_at, received_at, trial_step
FROM rndops.pressure_history
WHERE equipment_id = 'RNDPLC01'
ORDER BY measured_at DESC;

이 쿼리의 테이블·컬럼과 D0120의 값은 예시이며 외부 DB 문서와 현장 주소 맵을 맞춰야 해요. DB History Logs에서 해당 레코드의 저장 시각과 오류 상태를 보고, Runtime Status에서 마지막 수신 시각을 확인한 뒤 Dashboard에서 현재 압력과 시험 단계별 추세를 연결해 보면 돼요. 보존 기간과 삭제·아카이빙 기준도 외부 DB 운영 정책으로 정해요.

EASY LOGGER에서 저장 이력과 전달 상태를 운영하는 역할을 보여주는 공식 승인 이미지예요.

작게 검증한 뒤 범위를 넓혀요

처음에는 한 대의 시험장비와 한 압력 필드만 선택해 현장 표시값, PLC 원시값, 변환값, 외부 MySQL 레코드의 시각을 맞춰요. 다음 단계에서 한 공정의 두 번째 장비를 추가하고 장비 ID와 시험 단계가 섞이지 않는지 확인해요. 이후 MQTT·HTTP API·MySQL·Firebase 중 필요한 목적지만 확장하면서 Payload Log, DB History Logs와 Dashboard의 같은 사건을 비교하면 주소 오류와 전달 지연을 나누기 쉬워요.

현장 연결 가능 여부가 궁금하다면 Mitsubishi PLC 모델, 센서 사양, PLC field address map, 외부 MySQL 스키마와 필요한 화면을 준비해 확인·상담·문의해 주세요. EASY-LINK만으로 충분한 연결인지 EASY LOGGER까지 필요한 운영인지도 이 자료를 기준으로 함께 확인할 수 있어요.