EASY LOGGER 사용 예제: 공정라인 폐쇄망에서 PLC 데이터를 OPC UA로 읽고 쓰기

먼저 결론부터 볼게요

외부 인터넷과 분리된 공정라인에서 PLC 데이터를 OPC UA로 다룰 때는 연결 자체보다 데이터가 망 밖으로 나가지 않는지, 읽기와 쓰기 권한이 분리되어 있는지를 먼저 확인해야 해요. 이번 구성은 공정라인 폐쇄망 안에서 Mitsubishi PLC의 제어 상태를 읽고, 필요한 경우 테스트 노드에서 검증한 뒤 제한적으로 쓰며, 결과를 같은 망의 MySQL에 남기는 흐름이에요. 클라우드 전송을 전제로 하지 않기 때문에 현장 보안 승인과 망 분리 정책을 기준으로 설계를 좁혀 가는 게 핵심이에요.

폐쇄망이라고 해서 시간 동기화와 계정 관리가 덜 중요해지는 건 아니에요. 값이 바뀐 시각과 작업 계정을 함께 확인할 수 있어야 읽기·쓰기 결과를 나중에 비교할 수 있고, 내부 DB에 남은 이력도 운영 판단에 쓸 수 있어요. 실제 허용 범위, 보안 승인, 계정 수명과 망 분리 방식은 현장 담당자와 보안 담당자가 확인해야 해요.

공정라인 데이터와 망 경계를 먼저 나눠요

먼저 공정 상태를 어떤 필드로 표현할지 정해요. 예를 들어 운전 가능 여부, 자동·수동 상태, 인터록 상태처럼 제어에 영향을 줄 수 있는 값을 PLC 주소 맵에 적고, 각 항목의 Node ID, 데이터 타입, 단위를 함께 기록해요. 아래 이미지는 특정 장비의 외형이 아니라 PLC에서 로컬 저장소까지 이어지는 추상 흐름을 보여줘요.

PLC의 공정 상태를 폐쇄망 안에서 읽고 제한적으로 쓰는 데이터 흐름이에요.

EASY-LINK는 현장 PLC와 전달 경로 사이의 게이트웨이로서 연결 역할을 맡고, 필요한 데이터를 수집해 망 내부의 다음 계층으로 보내는 범위를 검토해요. 반면 EASY LOGGER는 여러 수집 설정을 묶는 데이터 로거로서 수집 주기, 저장 이력, 전달 상태를 통합 관리하고 운영 화면에서 확인하는 계층이에요. 대시보드는 EASY-LINK 단독 내장 기능으로 보지 않고 EASY LOGGER의 운영 범위로 나눠 설명해야 해요.

제품을 선택할 때도 역할을 섞지 않는 게 좋아요. 처음에는 한 장치와 한 공정의 읽기 노드만 정해 주소 매핑과 Runtime Status를 확인하고, 그 결과가 안정적일 때 같은 공정의 기록 범위를 넓혀요. 그다음 여러 공정 상태를 같은 기준으로 기록하고 이력을 계속 관리하려면 EASY LOGGER를 함께 검토해요. 실제 Mitsubishi PLC 모델과 통신 조건, 허용 노드 범위는 제품 자료와 현장 주소 맵을 대조해야 해요.

폐쇄망에서 전달 대상을 비교해요

이번 deliveryTarget은 MySQL이에요. MySQL은 같은 망의 외부 스키마에 수집 시각, PLC 식별자, Node ID, 값, 품질 상태를 남겨 기간별 이력을 조회하려는 경우에 검토할 수 있어요. EASY LOGGER의 DB 설정·조회 흐름은 EASY LOGGER DB 설정과 이력 조회 안내에서 확인할 수 있고, 실제 테이블과 보존 기간은 현장 DB 담당자가 정해야 해요.

MQTT는 여러 내부 소비자에게 상태 변화를 전달하기 좋은 경로이고, HTTP API는 별도 운영 서버가 정한 요청·응답 계약에 맞출 때 비교할 수 있어요. Firebase는 외부 서비스 의존성과 망 정책을 따로 검토해야 하므로 이번 폐쇄망 구성의 우선 목적지로 두지 않아요. 즉 MQTT·HTTP API는 실시간 전달과 시스템 계약을 비교하는 대안이고, MySQL은 같은 망에서 조회 가능한 운영 이력으로 비교하는 대상이에요. 이 차이를 기준으로 프로토콜 비교와 데이터 연동 범위를 정하고, 실제 허용 경로는 현장 보안 담당자와 확인해야 해요.

제품 이미지에서 확인되는 것처럼 EASY-LINK는 현장 연결 계층을, EASY LOGGER는 수집·저장·전달 상태를 확인하는 운영 계층을 맡겨 구분할 수 있어요.

EASY-LINK가 현장 연결과 데이터 전달을 맡는 게이트웨이 역할을 보여주는 승인 이미지예요.

EASY LOGGER가 수집 주기와 저장 이력, 전달 상태를 관리하는 데이터 로거 역할을 보여주는 승인 이미지예요.

읽기와 쓰기를 분리해 검증해요

OPC UA 연결 전에는 서버 Endpoint, PLC 필드와 Node ID의 대응, 데이터 타입, 읽기 권한과 쓰기 권한을 한 표에서 대조해요. 아래 값은 형식을 설명하기 위한 예시라서 실제 주소처럼 복사하면 안 돼요. Automatic Node Preview에서 승인된 노드 계층을 먼저 보고, Runtime Status에서 세션·읽기·쓰기 상태를 확인해요.

EASY LOGGER OPC UA 예제

공정라인 필드 AUTO_RUN이 Mitsubishi PLC의 제어 상태 Node ID에 대응한다고 가정해요. 실제 필드명과 Node ID는 현장 주소 맵에서 확인하고, 아래 예제의 Boolean이 실제 노드의 데이터 타입과 맞는지도 대조해야 해요.

endpoint: opc.tcp://PLC-GATEWAY.local:4840
Node ID: ns=2;s=ProcessLine/ControlState/AUTO_RUN
data type: Boolean
read: true
write: true
value: false

읽기부터 테스트 노드의 현재값과 PLC 화면값을 같은 시각에 비교해요. 쓰기가 필요하다면 운영 노드가 아닌 테스트 노드에서 값의 범위와 인터록 반응을 검증하고, 운영 승인 뒤에만 허용된 노드로 범위를 좁혀요. Automatic Node Preview에서 Node ID와 데이터 타입이 주소 맵과 일치하는지 확인한 다음 Runtime Status에서 마지막 처리 시각과 오류를 확인하고, 내부 MySQL의 저장 이력과 실제 PLC 상태를 대조해요.

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

시간·계정·복구 기준을 남겨요

폐쇄망의 운영 서버, EASY LOGGER, PLC, MySQL 사이 시간대와 동기화 기준을 확인해요. 시간 기준이 서로 다르면 같은 값을 읽고 쓴 기록도 순서가 뒤섞일 수 있어요. 계정은 개인별로 관리하고, 읽기 계정과 쓰기 계정의 권한·사용 기간·변경 이력을 현장 정책에 맞춰 정해요. 어떤 정책을 적용할지는 보안 승인과 담당자 확인이 필요해요.

망 경계, 계정과 시간 기준, 운영 승인과 인터록을 별도 확인하는 흐름이에요.

값이 예상과 다르면 먼저 Node ID와 데이터 타입, 다음으로 세션 상태와 시간 동기화, 마지막으로 MySQL 저장 이력을 구간별로 확인해요. 쓰기 결과가 반영되지 않았을 때는 재시도부터 하지 말고 승인된 복구 절차와 PLC 인터록 상태를 먼저 확인하는 편이 안전해요.

현장 연결 가능 여부를 확인하려면 Mitsubishi PLC 모델, OPC UA Endpoint, 허용할 Node ID 범위, MySQL 저장 위치를 정리해 보세요. 연결 조건과 메뉴별 확인 항목은 EASY LOGGER OPC UA 설정 안내와 제품 매뉴얼 자료에서 함께 대조하면 좋아요.