스마트팩토리 로봇 공정 상태 데이터를 OPC UA로 엣지 서버에 연결하는 기준

먼저 결론부터 볼게요

로봇 공정의 상태 데이터는 생산량을 보여주는 숫자 하나보다 다음 운영 판단을 빠르게 만드는 기준에 가까워요. 사이클이 끝났는지, 대기 시간이 길어졌는지, 재시작 전에 어떤 상태였는지를 같은 시각으로 확인해야 작업자가 현장과 운영 화면을 오가며 추측하는 시간을 줄일 수 있어요. 그래서 먼저 센서와 PLC에서 어떤 필드를 읽고, 그 값으로 어떤 조치를 판단할지 정하는 일이 필요해요.

데이터가 필요한 이유는 이상을 자동으로 단정하기 위해서가 아니에요. 정상 범위와 변화 시점을 남겨 두면 작업자는 정지 원인 확인, 점검 순서 결정, 교대 인계 같은 판단을 같은 기준으로 시작할 수 있어요. 수집 주기, 단위, 상태 코드, 마지막 갱신 시각을 함께 기록하고 한 대의 로봇 셀에서 값이 맞는지 확인한 뒤 범위를 넓히는 흐름이 안전해요.

현장 신호를 엣지 서버에서 정리하고 OPC UA 클라이언트가 필요한 노드를 읽는 흐름이에요.

현장 값을 운영 판단으로 바꾸는 순서

먼저 로봇 컨트롤러의 운전 상태, 사이클 완료, 알람 코드, 현재 작업 번호처럼 판단에 필요한 필드를 정해요. 샘플 PLC 이름, 설정 이름, 주소는 예시이며 실제 필드 주소 맵과 대조해야 해요. 주소 맵에는 필드명, PLC 주소, 데이터 타입, 단위, 상태 코드의 의미, 수집 주기와 변경 시각을 같이 남겨요. 그래야 PLC 값과 화면의 값이 다를 때 주소 문제인지 변환 문제인지 구분할 수 있어요.

EASY-LINK는 로봇 셀과 PLC의 신호를 수집해 정해진 전달 대상으로 보내고, 현장 연결을 담당하는 산업용 IoT 게이트웨이 역할을 맡아요. 작은 라인에서 센서 데이터 수집과 MQTT 또는 HTTP API 전달만 필요하다면 이 역할만으로 시작할 수 있어요.

EASY LOGGER는 여러 수집 항목을 묶는 데이터 로거로서 수집 주기, 저장 이력, 전달 상태와 대시보드 운영을 맡아요. 여러 셀의 상태를 비교하거나 데이터 추세 분석을 해야 하고, 누락 시각과 재연결 시점을 함께 확인해야 한다면 EASY LOGGER를 운영 계층으로 검토하는 편이 좋아요. EASY-LINK와 EASY LOGGER를 항상 함께 써야 하는 것은 아니며, 연결 범위와 이력 관리 범위를 나누어 판단하면 돼요.

전달 방식도 목적에 맞춰 비교해요. MQTT는 여러 구독자가 실시간 상태를 받을 때 유리하고, HTTP API는 업무 서버가 요청과 응답을 관리할 때 이해하기 쉬워요. MySQL은 외부 스키마에 이력을 쌓아 기간별 조회를 할 때 적합하고, Firebase는 모바일이나 웹 화면에서 상태를 빠르게 확인할 때 검토할 수 있어요. 이 글의 deliveryTarget은 엣지 서버이며, 엣지 서버에서 원본 상태를 정리한 뒤 OPC UA로 읽게 하는 구조를 말해요.

MES와 CIM은 MQTT, HTTP API 또는 DB 인터페이스로 연계 범위를 정의해요. 확인되지 않은 전용 커넥터를 전제로 하지 않고, 필드명과 시각 기준을 먼저 맞춘 뒤 필요한 인터페이스를 선택해야 해요. 제품 소개와 기능 범위는 EASY LOGGER 제품 안내에서, 화면 운영 절차는 EASY LOGGER 대시보드 가이드에서 이어서 확인할 수 있어요.

한 셀에서 단계적으로 검증해요

처음에는 한 대의 로봇과 한 공정의 상태 필드만 골라요. PLC 원시값, EASY LOGGER의 수집값, 엣지 서버의 전달값, OPC UA 클라이언트의 표시값을 같은 시각에 비교하고, 정상 운전·사이클 완료·알람 전환을 순서대로 기록해요. 값이 멈추면 통신 상태와 마지막 갱신 시각을 먼저 보고, 값은 갱신되지만 의미가 다르면 주소 맵과 데이터 타입을 다시 대조해요.

공식 제품 이미지는 제품 역할을 확인하는 참고 자료로 사용하고, 연결 범위는 현장 주소 맵으로 확정해요.

이렇게 작게 시작하면 설비 데이터 수집 범위를 넓힐 때 기준이 흔들리지 않아요. 대시보드에서는 현재 상태와 최근 변경 시각을 보고, 저장 이력에서는 사이클별 누락을 보고, Runtime Status에서는 연결과 전달 상태를 확인하는 식으로 화면의 목적을 나눠요. 현장 연결 가능 여부 확인이나 상담을 요청할 때는 로봇 모델, PLC 주소 맵, 필요한 주기, 외부 인터페이스와 권한 범위를 함께 준비하면 좋아요.

EASY LOGGER OPC UA 예제

로봇 셀의 CycleState 필드는 샘플 PLC ROBOT_CELL_01의 D120 주소와 대응한다고 가정한 예시예요. 실제 PLC 이름, 설정 이름, 주소는 현장 필드 주소 맵과 대조하고, Automatic Node Preview에서 생성된 경로와 데이터 타입을 확인해야 해요. 이 매핑을 먼저 확정한 뒤 엣지 서버의 OPC UA 클라이언트가 같은 노드를 읽도록 연결해요.

endpoint: opc.tcp://EDGE_SERVER_HOST:4840
nodeId: ns=2;s=RobotCell/ROBOT_CELL_01/CycleState
dataType: Int16
access: CurrentRead
field: CycleState -> PLC D120

위 endpoint, Node ID, 데이터 타입은 형식 확인을 위한 예시이며 실제 값은 현장 주소 맵과 일치해야 해요. Automatic Node Preview에서 CycleState가 보이는지 확인하고, OPC UA 클라이언트가 읽은 상태와 EASY LOGGER의 Runtime Status에서 RUNNING, LAST ERROR, 마지막 갱신 시각을 함께 확인해요. 대시보드에는 현재 상태를 표시하고 저장 이력에는 사이클 완료 시각을 남겨 운영 판단의 근거를 이어가요.

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

OPC UA 읽기와 쓰기의 권한은 분리해서 검토하고, 쓰기가 필요한 경우에도 샘플 노드와 현장 승인 절차를 먼저 확인해요. 이 예제는 로봇을 원격 제어한다는 뜻이 아니라 상태 데이터를 읽고 운영 화면에서 확인하는 기준을 설명해요.