블로그›2026. 8. 10.

진동센서 데이터를 OPC UA로 연결할 때 확인할 현장 기준

먼저 결론부터 볼게요

진동센서 데이터를 OPC UA로 연결할 때는 Node ID부터 정하기보다 값이 지나가는 경로를 먼저 그려야 해요. 센서의 진동값이 PLC에 어떤 단위와 배율로 들어오는지, PLC의 원시값을 어느 OPC UA 노드로 읽을지, 마지막으로 운영 화면에서 수집·전달 상태를 어떻게 확인할지를 한 흐름으로 맞춰야 해요.

스마트팩토리에서는 진동값 하나만 현재 화면에 보이는 것보다 측정 시각, PLC 수집 시각, OPC UA 읽기 시각과 마지막 정상 수신 시각을 나눠 남기는 일이 중요해요. 그래야 값이 오래된 것인지, PLC 주소가 잘못된 것인지, OPC UA 연결만 끊긴 것인지 구분할 수 있어요. 처음에는 한 장치의 한 진동 필드로 정상값과 통신 단절을 차례로 확인해 보세요.

센서·PLC 주소와 운영 목적을 먼저 맞춰요

진동센서가 Modbus TCP로 PLC에 연결된다면 실제 현장 주소 맵에서 센서 이름, PLC 주소, 데이터 타입, 단위, 배율과 정상 범위를 함께 확인해요. 아래에서 쓰는 LINE_A, D0100, VIBRATION_RMS는 설명을 위한 예시이며 실제 적용 전 현장 필드 주소 맵과 대조해야 해요. 같은 RMS 값이라도 원시 정수와 변환된 mm/s 값이 다를 수 있으니 변환 전후를 따로 기록하는 편이 좋아요.

이 단계에서는 센서·PLC와 외부 데이터 경로 사이의 현장 연결 계층을 먼저 확인해요. 주소 변환과 필요한 전달만 있으면 연결 계층만으로 시작할 수 있어요. 반면 여러 장치의 저장 이력, 전달 상태, 운영 화면을 함께 관리해야 한다면 기록과 모니터링 계층을 추가해 역할을 나눠요.

현장 연결 계층을 보여 주는 공식 이미지예요. 센서·PLC 데이터를 외부 경로로 넘기는 역할을 검토할 때 참고해요.

전달 대상에 따라 운영 범위를 정해요

이번 주제의 주 전달 대상은 엣지 서버에서 확인하는 OPC UA예요. OPC UA는 endpoint와 Node ID, 데이터 타입을 계약으로 맞추기 좋고, 현장 값과 상위 운영 화면 사이의 읽기 상태를 확인하기 쉬워요. 다만 모든 목적지에 OPC UA가 같은 답은 아니에요. 여러 소비자가 이벤트를 구독하면 MQTT, 요청·응답과 외부 시스템 계약이 중심이면 HTTP API, 외부 스키마에 장기 이력을 쿼리하려면 MySQL, 웹·모바일 상태 동기화가 목적이면 Firebase를 비교해 볼 수 있어요.

이 지점에서 EASY-LINK는 센서·PLC와 외부 경로를 잇는 연결 역할을 맡고, EASY LOGGER는 수집 데이터의 저장 이력과 전달 상태를 관리하는 운영 계층으로 구분해요. EASY LOGGER를 사용하면 Runtime Status에서 연결과 마지막 정상 수신 시각을 먼저 보고, Payload Log에서 전달된 값과 오류를 확인할 수 있어요. 저장 이력은 외부 DB나 설정된 이력 화면의 보존 정책과 함께 확인하고, Dashboard(대시보드)에서는 현재 RMS 값과 마지막 수신 시각을 함께 보여줘요. OPC UA가 정상 응답해도 원본 측정 시각이 오래됐다면 센서나 PLC 구간을 다시 봐야 해요.

EASY LOGGER 공식 이미지예요. PLC 데이터 수집, 저장·전달 경로와 Dashboard 운영을 한 계층에서 확인하는 역할을 보여 줘요.

EASY LOGGER OPC UA 예제

아래 endpoint, Node ID와 데이터 타입은 OPC UA 예시 형식이에요. LINE_A의 진동 필드가 PLC의 D0100에 대응한다고 가정했으며, 이 주소와 이름은 실제 현장 필드 주소 맵과 대조해 사용해야 해요. Automatic Node Preview에서 endpoint와 Node ID를 확인한 뒤 Runtime Status에서 연결 상태와 마지막 읽기 시각을 확인하고, Payload Log 또는 Dashboard에서 값이 이어지는지 봐요.

OPC UA ENDPOINT: opc.tcp://LOGGER_HOST:4840/easylogger/server/
READ NODE ID: ns=2;s=EASY_LOGGER/Devices/LINE_A/Tags/VIBRATION_RMS
READ DATA TYPE: Double
PLC FIELD MAP: D0100 -> VIBRATION_RMS

위 예시의 D0100은 진동센서 원시 필드와 Node ID의 대응을 설명하기 위한 이름이에요. 실제 배율과 단위는 PLC 주소 맵에서 확인한 뒤 Automatic Node Preview의 Data Type과 맞추고, Runtime Status에서 마지막 정상 읽기를 확인해요. Payload Log에는 측정값과 시각이 기대한 필드로 남는지, Dashboard에는 현재값과 수신 상태가 함께 보이는지 연결해 봐요.

읽기 payload의 필드명과 값 형식도 현장 맵에 맞춰야 해요. 다음은 VIBRATION_RMS를 Double로 읽었다고 가정한 예시이며, 실제 payload 스키마는 확인된 OPC UA 연계 계약과 대조해야 해요.

{
  "node_id": "ns=2;s=EASY_LOGGER/Devices/LINE_A/Tags/VIBRATION_RMS",
  "datatype": "Double",
  "value": 2.37,
  "unit": "mm/s"
}

이 payload가 들어오면 Runtime Status에서 연결·수집 상태를, Payload Log에서 실제 Node ID와 값의 기록을, Dashboard에서 현재 RMS와 마지막 수신 시각을 확인해요. 값이 없을 때는 Node ID, PLC 주소, 데이터 타입, 네트워크 연결을 한꺼번에 바꾸지 말고 한 항목씩 비교해요.

OPC UA WRITE를 검토한다면 읽기와 별도의 권한으로 두고, 아래 노드도 실제 주소 맵과 허용 노드 범위를 대조해야 해요. RESET_COMMAND와 Boolean 값은 설명용 예시예요.

WRITE NODE ID: ns=2;s=EASY_LOGGER/Devices/LINE_A/Tags/RESET_COMMAND
WRITE DATA TYPE: Boolean
ALLOWED NODE RANGE: LINE_A/Tags/RESET_COMMAND
PLC FIELD MAP: RESET_COMMAND -> D0200

쓰기 동작은 Runtime Status에서 권한과 PLC 인터록 상태를 확인한 뒤 시험하고, Payload Log에서 요청 결과와 응답 시각을 남겨요. 운영 화면에서는 쓰기 성공만 보고 설비가 실제로 동작했다고 단정하지 말고 PLC 피드백 필드와 수동 복구 절차를 함께 확인해야 해요.

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

한 장치에서 단계적으로 넓혀요

1단계에서는 진동센서 한 대와 PLC 주소 한 구간만 읽고, 현장 표시값·PLC 원시값·OPC UA 값의 시각을 맞춰요. 2단계에서는 정상 범위, 경계값, 통신 단절과 재연결을 차례로 기록해 Runtime Status와 Payload Log의 차이를 확인해요. 3단계에서 다른 장치와 Dashboard를 추가하고, 필요한 경우 MQTT·HTTP API·MySQL·Firebase 중 외부 목적지와의 계약을 비교해요.

EASY-LINK만으로 현장 연결과 단순 전달이 충분한지, EASY LOGGER까지 더해 이력·전달 상태·Dashboard를 함께 운영할지는 장치 수와 담당자의 확인 범위에 따라 달라져요. 제품을 처음부터 모두 묶기보다 현재 센서 형식, Modbus TCP 설정, PLC 주소 맵, OPC UA endpoint와 운영 목적을 먼저 정리하면 판단이 쉬워져요.

현장 연결 가능 여부를 확인하고 싶다면 구매나 쓰기 설정부터 시작하지 않아도 돼요. 센서 모델, PLC 제조사와 주소 형식, OPC UA 사용 여부, 필요한 화면과 전달 대상을 정리해 가볍게 확인해 보세요.

이 글의 진동 데이터 운영 기준은 기존 엣지 서버 연계 글과 함께 비교해 볼 수 있어요.

#EASY-LINK #EASY LOGGER #스마트팩토리 #진동센서 #Modbus TCP #OPC UA #엣지 컴퓨팅 #센서 데이터 수집 #설비 데이터 수집 #MQTT #HTTP API