식품공장 세척수 유량을 OPC UA와 엣지 서버로 잇는 필드 설계 기준

먼저 결론부터 볼게요

식품공장 모니터링에서 세척수 유량 데이터는 숫자를 모으는 것보다 그 숫자가 어느 라인의 어떤 공정에서 나온 값인지 연결하는 일이 먼저예요. 세척이 끝났다는 판단을 하려면 유량값, 측정 시각, 라인 식별자, 수신 시각을 함께 확인해야 해요. 값 하나만 화면에 표시하면 센서 변화와 통신 지연을 구분하기 어렵고, 상위 시스템으로 전달된 뒤에도 같은 필드인지 확인하기 어려워요.

처음에는 한 대의 유량계와 한 세척 라인만 정해 정상 유량, 경계 유량, 재연결 뒤 값을 비교하는 편이 좋아요. 이 글에서 WASHPLC01, RINSE_FLOW, ns=2;s=LineA.RinseFlow, L/min은 설명을 위한 샘플이에요. 실제 센서 사양, PLC 프로그램, OPC UA 서버 설정과 현장 field address map을 대조해 확정해야 해요. 운영자가 확인할 질문은 간단해요. 어느 필드가 원시값인지, 어떤 단위로 변환했는지, 어느 시각에 수신됐는지, 그 기록이 운영 화면과 외부 시스템에서 같은 의미인지예요.

연결 계층과 운영 계층을 나눠요

EASY-LINK는 확인된 센서·PLC 필드를 목적지까지 연결하는 현장 연결 계층으로 봐요. 한 라인의 유량값을 OPC UA로 읽고 연결 상태만 확인한다면 EASY-LINK 중심으로 시작할 수 있어요. 여러 라인의 수집 이력, 전달 상태와 대시보드 운영을 함께 확인하려면 EASY LOGGER를 더하는 편이 좋아요. EASY LOGGER는 수집 이력·전달 상태·대시보드 운영을 맡고, PLC 인터록이나 공정 제어 로직을 대신하는 제품으로 설명하지 않아요.

OPC UA는 노드와 데이터 타입을 기준으로 필드를 구분하기 좋아요. MQTT는 Topic과 구독 권한으로 여러 소비자에게 현재값을 나누는 데 맞고, HTTP API는 운영 서버의 endpoint와 요청·응답 계약을 맞추는 데 맞아요. MySQL은 외부 스키마에 측정 이력과 수신 시각을 보존할 때 비교할 수 있고 Firebase는 여러 화면에서 현재 상태를 공유할 때 비교할 수 있어요. 이번 deliveryTarget은 엣지 서버예요. 엣지 서버에서 OPC UA 값을 먼저 확인한 뒤 MQTT나 HTTP API로 상위 시스템에 전달하는 구조를 검토할 수 있어요. MES·CIM은 MQTT, HTTP API 또는 DB 인터페이스로 확인된 필드 계약을 협의하는 범위에서 다뤄요.

한국표준협회 자료가 스마트제조 상호운용성과 OPC UA 적용 방안을 소개하는 것처럼, 프로토콜을 선택할 때도 장치 이름보다 필드 의미와 노드 계약을 먼저 정해야 해요. HT Automation 공식 자료는 EASY LOGGER가 PLC 데이터를 수집하고 DB·CSV·MQTT·API·OPC-UA·대시보드로 연결하는 데이터 로거라고 설명해요. 이 자료는 제품 역할의 근거로 사용하고, 특정 현장의 지원 범위는 장비 문서와 설정으로 따로 확인해요. 관련된 스마트팩토리 수질 데이터 운영 글에서 화면과 이력의 관점을 비교할 수 있고, 제품 매뉴얼 자료실에서 버전별 설정 항목을 대조하면 좋아요.

EASY-LINK가 현장 센서와 PLC 필드를 목적지까지 연결하는 역할을 설명해요.

EASY LOGGER가 수집 이력과 전달 상태를 운영 화면에서 확인하는 역할을 설명해요.

현장 필드와 OPC UA 노드를 맞춰요

세척 라인 Line-A의 유량계 필드 RINSE_FLOW가 OPC UA Node ID ns=2;s=LineA.RinseFlow에 대응한다고 가정해요. WASHPLC01, Line-A, Node ID, L/min, Float는 예시이며 현장 field address map, PLC 설정, OPC UA 서버의 namespace와 대조해 확정해야 해요. 먼저 원시 필드와 변환 단위의 관계를 적고, 측정 시각 measuredAt과 수신 시각 receivedAt을 분리해요. 이 매핑을 확인한 뒤 Automatic Node Preview에서 Node ID와 데이터 타입을 보고, Runtime Status에서 연결과 마지막 수신 시각을 확인해요.

EASY LOGGER OPC UA 예제

아래 예시는 WASHPLC01의 RINSE_FLOW 필드가 예시 Node ID에 대응하고 세척수 유량을 Float와 L/min으로 읽는 구성입니다. 실제 노드와 필드는 현장 field address map, OPC UA 서버 namespace, PLC 설정과 대조해 확정해야 해요. Automatic Node Preview에서 endpoint와 Node ID를 확인하고 Runtime Status에서 연결·읽기 상태를 확인한 뒤, Payload Log에서 값·단위·측정 시각을 맞춰요.

OPC UA ENDPOINT: opc.tcp://edge.example.local:4840
NODE ID: ns=2;s=LineA.RinseFlow
DATA TYPE: Float
READ FIELD: RINSE_FLOW
UNIT: L/min

이 endpoint와 Node ID는 예시예요. RINSE_FLOW가 PLC의 예시 필드 주소와 같은 값을 가리키는지 먼저 대조하고, Automatic Node Preview의 Browse 결과와 Runtime Status의 마지막 읽기 시각을 함께 확인해요.

{
  "plc_name": "WASHPLC01",
  "config_name": "LineA_RinseFlow",
  "node_id": "ns=2;s=LineA.RinseFlow",
  "data_type": "Float",
  "values": {"RINSE_FLOW": 42.5},
  "unit": "L/min",
  "measuredAt": "2026-08-19T15:00:00+09:00"
}

이 JSON도 외부 전송 형식의 예시예요. Payload Log에서 RINSE_FLOW, Node ID, 단위와 값을 확인하고 DB History를 사용한다면 외부 운영 DB의 레코드 시각과 measuredAt, receivedAt을 대조해요. Dashboard에서는 현재 유량, 마지막 수신 시각, 라인 ID를 함께 보고 세척 판단에 필요한 흐름을 확인해요.

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

OPC UA 읽기와 쓰기를 함께 검토할 때도 예시 Node ID와 실제 운영 노드를 분리해요. 읽기 값이 정상이어도 쓰기 권한은 별도 승인과 인터록 조건으로 판단하고, 엣지 서버의 Runtime Status와 Payload Log에서 실행 주체와 시각을 남겨요.

작게 연결하고 운영 범위를 넓혀요

처음에는 한 대의 유량계와 한 공정에서 정상값, 경계값, 단절 뒤 재연결을 확인해요. 다음 단계에서 두 번째 라인을 추가하며 Node ID의 namespace와 라인 ID가 섞이지 않는지 확인하고, OPC UA와 MQTT의 전달 시각을 나눠 기록해요. HTTP API를 상위 시스템에 연결한다면 endpoint와 응답 시각을 별도로 남기고, 외부 MySQL을 쓴다면 DB History의 레코드가 Payload Log의 동일한 사건을 가리키는지 확인해요. 그 뒤 Dashboard에서 라인별 현재값과 추세를 보고 범위를 넓히면 주소 오류, 변환 오류, 전달 지연을 나눠 찾기 좋아요.

EASY-LINK만으로 충분한 경우는 한 라인의 확인된 OPC UA 필드를 엣지 서버까지 연결하고 연결 상태를 보는 경우예요. 여러 라인의 저장 이력과 전달 상태, Dashboard를 함께 운영할 때는 EASY LOGGER가 더해져요. 현장 연결 가능 여부가 궁금하다면 센서 모델, PLC field address map, OPC UA endpoint와 Node ID, 필요한 MQTT·HTTP API·외부 DB 컬럼을 준비해 확인·상담·문의해 주세요.