연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
T15. OPC UA, Asset Administration Shell, MQTT과 제조 상호운용성
- T15-2.10구조대응2025년 이후
ESP32-Based Sparkplug B Gateway Framework for Brownfield PLC Integration into an IIoT Unified Namespace: A Data Foundation for Intelligent Industrial Systems
Šenk 외 (2026) 구형 PLC를 Sparkplug B 통합 이름공간에 붙이는 게이트웨이
한국어 검토 보기
해결 문제
- 이미 깔린 구형 PLC는 제조사마다 통신 규약이 다르다. 교체는 현실적으로 어렵다.
핵심 구조
- ESP32 기반 저가 엣지 게이트웨이를 만들었다. Festo CI, Mitsubishi SLMP, Siemens S7comm을 각각 어댑터로 받아 MQTT/Sparkplug B로 올린다. ISA-95 계층에 맞춘 통합 이름공간을 Ignition에 구성했다. 게이트웨이와 브로커 사이는 TLS로 보호한다.
주요 결과
- PLC와 구성별로 각각 2만 회씩 측정했다. TLS를 켠 상태에서 요청부터 발행까지 평균 시간은 Festo 38.62밀리초, Mitsubishi 20.28밀리초, Siemens 16.80밀리초였다.
한계
- PLC 3종에 한정된다. 게이트웨이 하드웨어가 저사양이라 고빈도 대용량 수집에는 제약이 있다.
- T15-2.1유사문제
The Future of Industrial Communication: Automation Networks in the Era of the Internet of Things and Industry 4.0
Wollschlaeger 외 (2017) 산업통신의 미래, 프로토콜 지형 개괄
한국어 검토 보기
해결 문제
- 사물인터넷과 사이버물리시스템이 들어오면서 공장 통신망이 어디로 가는지 정리된 그림이 없었다. 현장 버스, 산업용 이더넷, 인터넷 기술이 뒤섞이는 국면이었다.
핵심 구조
- 산업통신 발전 흐름을 세대별로 훑는다. 산업용 이더넷과 시간확정 네트워킹(TSN, 정해진 시각에 데이터가 도착하도록 보장하는 이더넷 기술)의 진행 상황을 정리한다. 공장에서 5G가 맡을 자리도 짚는다. 마지막에 표준화가 왜 필수인지 논증한다.
주요 결과
- OPC UA를 포함한 프로토콜들이 각각 어느 계층에서 무슨 역할을 맡는지 배치도를 준다. 통신 규약 하나로 다 되는 게 아니라 계층별 조합이 답이라는 결론이다. 인용 수는 OpenAlex 기준 1,716건이다(2026-08-27 확인).
한계
- 개괄 논문이다. 실험이나 성능 수치가 없다. 2017년 시점이라 AAS와 MQTT Sparkplug 확산 이후 상황은 담기지 않았다.
- T15-2.2유사문제
Insights into Mapping Solutions Based on OPC UA Information Model Applied to the Industry 4.0 Asset Administration Shell
Cavalieri & Salafia (2020) OPC UA 정보모델로 AAS를 표현하는 방법
한국어 검토 보기
해결 문제
- AAS 메타모델을 OPC UA 정보모델로 어떻게 옮길지 정해진 답이 없었다.
핵심 구조
- AAS 메타모델 요소를 OPC UA 노드로 바꾸는 모델링 기법 몇 가지를 제시하고, 기존 방식과 비교한다.
주요 결과
- 각 매핑 방식의 장단점을 정리했다. 정답 하나를 강요하지 않고 선택 기준을 준다.
한계
- 성능 측정이 없다. 당시 AAS 메타모델이 초기 판이라 지금 판과 차이가 있다.
- T15-2.3구조대응
Reusing OPC UA information models in the Asset Administration Shell
Weiss & Reichelt (2023) OPC UA 노드셋을 AAS 서브모델로 재사용
한국어 검토 보기
해결 문제
- OPC UA와 AAS는 메타모델이 근본적으로 다르다. 잘못 이으면 상호운용성이 깨진다.
핵심 구조
- 변환 규칙을 하나씩 명시한다. 기존 OPC UA 노드셋을 그대로 읽어 AAS 서브모델을 자동으로 만들어 준다.
주요 결과
- 현장 데이터를 상위 시스템에 그대로 노출하는 통로가 생긴다. 회사 간 데이터 교환 영역으로 맥락이 보존된다.
한계
- 규칙 명세와 개념 증명 중심이다. 대규모 현장 검증이나 성능 수치가 없다.
- T15-2.4유사문제
OPC UA versus ROS, DDS, and MQTT: Performance Evaluation of Industry 4.0 Protocols
Profanter 외 (2019) OPC UA, ROS, DDS, MQTT 성능 비교
한국어 검토 보기
해결 문제
- 산업 현장에서 어떤 통신 규약을 골라야 하는지 근거가 부족했다.
핵심 구조
- 기능 비교, 연결 수립과 데이터 전송의 패킷 오버헤드 비교, 그리고 오픈소스 구현으로 왕복 시간 측정.
주요 결과
- 유휴 상태, CPU 부하 상태, 네트워크 부하 상태에서 각각 왕복 시간을 쟀다. 같은 호스트에 노드 500개를 둔 시험도 했다.
한계
- 2019년 당시 오픈소스 구현 기준이다. 구현체가 바뀌면 수치도 바뀐다.
- T15-2.5구조대응
Evaluation and Extension of OPC UA Publish/Subscribe MQTT Binding
Raddatz 외 (2020) OPC UA PubSub의 MQTT 바인딩 구현과 지연 측정
한국어 검토 보기
해결 문제
- OPC UA 클라이언트/서버 방식은 일대다 배포에 약하다. OPC UA Part 14(PubSub)를 MQTT로 실제로 물려 보고 지연을 재야 했다.
핵심 구조
- open62541 오픈소스 스택으로 OPC UA-MQTT 바인딩을 구현했다. 크레인 모델을 주소공간에 만들고 라즈베리파이 2대와 Mosquitto 브로커로 시험대를 꾸렸다.
주요 결과
- 클라이언트/서버 방식이 지연이 가장 컸다. UDP 멀티캐스트(UADP)가 가장 빨랐고 MQTT는 브로커 처리 시간만큼 그 사이에 놓였다. 브로커 처리 시간 자체는 메시지 크기와 거의 무관했다.
한계
- 구독자 1개, 라즈베리파이 2대 규모다. 저자들도 다수 구독자 환경 검증을 후속 과제로 남겼다.
- 평가 대상 규격: 위 1.1의 OPC 10000-14 Part 14
- T15-2.6후보
Open-Source Implementations of the Reactive Asset Administration Shell: A Survey
Jacoby 외 (2023) 오픈소스 AAS 구현체 비교 조사
한국어 검토 보기
해결 문제
- AAS 구현체가 여럿인데 무엇을 골라야 할지 비교 자료가 없었다.
핵심 구조
- GitHub와 Google Scholar를 뒤져 오픈소스 구현 4개를 골랐다. 평가 기준을 정하고 시험 프레임워크를 만들어 AAS 모델 요소와 API 호출 지원 여부를 찍었다.
주요 결과
- 모두 최소 기능은 지원한다. 그런데 사양을 세부까지 다 구현한 것은 하나도 없었다. 구현체끼리 호환이 안 되는 지점이 드러났다.
한계
- 2023년 시점 스냅샷이다. AAS 사양과 구현체가 빠르게 바뀌므로 유효 기간이 짧다.
- T15-2.7후보
Generation of Asset Administration Shell With Large Language Model Agents: Toward Semantic Interoperability in Digital Twins in the Context of Industry 4.0
Xia 외 (2024) 대형 언어모델 에이전트로 AAS 자동 생성
한국어 검토 보기
해결 문제
- AAS 인스턴스를 사람이 손으로 만드는 비용이 크다. 설비 사양서에 있는 정보를 표준 모델로 옮기는 작업이 반복 노동이다.
핵심 구조
- 의미 노드(semantic node)라는 자료구조를 정의해 문장에서 의미를 뽑는다. 그 위에 언어모델 에이전트를 올려 기술 사양서에서 표준 디지털 트윈 모델을 뽑아낸다.
주요 결과
- 유효 생성률 62~79퍼센트를 보고했다. 원문 정보 상당 부분을 오류 없이 옮겼다는 뜻이다. 여러 언어모델 비교와 검색 증강 생성(RAG) 구성요소 제거 실험도 함께 실었다.
한계
- 생성률이 100퍼센트가 아니다. 사람 검수가 여전히 필요하다. 사양서 품질에 결과가 크게 좌우된다.
- T15-2.8구조대응
File- and API-based interoperability of digital twins by model transformation: An IIoT case study using asset administration shell
Platenius-Mohr 외 (2020) 모델 변환으로 디지털 트윈 상호운용성 확보
한국어 검토 보기
해결 문제
- 회사마다 디지털 트윈 형식이 달라 정보 교환이 막힌다.
핵심 구조
- 정보모델을 유연하게 변환하는 시스템을 만들었다. 파일 기반 교환과 API 기반 교환을 양방향으로 지원한다.
주요 결과
- ABB Ability 디지털 트윈을 AAS 형식으로 실제 변환한 사례를 보였다. 필요할 때 그때그때 상호운용성을 만들어 내는 방식이 가능함을 확인했다.
한계
- 사례 연구 1건 중심이다. 변환 규칙을 사람이 맞춰 줘야 한다. 성능이나 대규모 확장은 다루지 않았다.
- T15-2.9유사문제
Streaming Machine Generated Data via the MQTT Sparkplug B Protocol for Smart Factory Operations
Koprov 외 (2022) MQTT Sparkplug B로 공작기계 데이터 스트리밍
한국어 검토 보기
해결 문제
- 스마트 제조에서는 데이터 흐름이 더 이상 위아래 계층 구조가 아니다. 설비 단에도 지능이 붙는다.
핵심 구조
- 기존 공작기계 제어기에 MQTT Sparkplug B를 붙였다. 기계 제어기에서 현장 네트워크로, 다시 클라우드 플랫폼으로 데이터를 흘린다.
주요 결과
- 설비와 클라우드 사이에 발행/구독 통신을 세웠다. 정보기술망과 운영기술망 사이에 통합 이름공간(Unified Namespace)을 비교적 쉽게 만들 수 있음을 보였다.
한계
- 짧은 레터 논문이다. 구현과 시험 운전 보고 위주이고 대규모 성능 수치나 장기 운영 결과는 없다.
- T15-2.11구조대응
A Cyber-Physical Machine Tools Platform using OPC UA and MTConnect
Liu 외 (2019) OPC UA와 MTConnect를 잇는 공작기계 플랫폼
한국어 검토 보기
해결 문제
- 공작기계를 연결하려면 정보모델과 통신 규약이 표준이어야 한다. 그런데 현장에는 OPC UA 계열과 MTConnect 계열이 따로 돌아간다. 둘 사이가 안 통한다.
핵심 구조
- CNC 공작기계용 OPC UA 정보모델을 일반형으로 만들고, 그걸 바탕으로 개발 절차를 제시한다. 그다음 MTConnect 정보모델과 데이터를 OPC UA 쪽으로 바꿔 주는 변환 인터페이스를 만들었다. OPC UA 기반 시제품을 기존 MTConnect 기반 시제품과 합쳐 하나의 플랫폼으로 묶었다.
주요 결과
- 두 표준을 한 플랫폼에서 같이 쓸 수 있게 했다. 그 위에 OPC UA 클라이언트, 증강현실 착용형 조작 화면, 클라우드 제조 구상을 얹어 활용 사례를 보였다. 저자들은 현장 생산 효율이 뚜렷이 좋아졌다고 보고한다.
한계
- 시제품 수준 통합이다. 지연 시간이나 처리량 같은 통신 성능 수치는 따로 제시하지 않는다. 효율 개선 주장의 측정 조건이 좁다.
- 관련 규격: 위 1.1의 OPC UA for MTConnect, 1.3의 MTConnect Standard
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기