연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
T14. 산업용 프로토콜 번역, 코드 생성, 프로그램 합성
- T14-5구조대응2025년 이후
Training LLMs for Generating IEC 61131-3 Structured Text with Online Feedback
한국어 검토 보기
해결 문제
- IEC 61131-3 정형 텍스트는 공개 학습 데이터가 적다. 문법도 까다롭다. 그래서 일반 모델이 잘 못 쓴다.
핵심 구조
- 선호 기반 학습을 온라인으로 돌린다. 컴파일러 피드백과 LLM 기반 전문가 평가를 매 회 반영해 미세조정한다.
주요 결과
- 컴파일 성공률이 올라갔다. 기존 모델보다 나은 성능을 보고한다.
한계
- 컴파일 성공이 곧 현장 안전성은 아니다. 평가자 역할을 다른 LLM이 맡아 편향 가능성이 있다.
우리 기능과의 연결
- 회사 연결: 실행 결과를 다시 학습 신호로 넣는 구조는 설비 데이터 수집 드라이버 코드나 변환 규칙을 스스로 고쳐가는 방식에 대응할 수 있다.
- T14-1유사문제
Evaluating Large Language Models Trained on Code
한국어 검토 보기
해결 문제
- 큰 언어모델이 자연어 설명만 보고 실제로 도는 코드를 쓸 수 있는지 재는 방법이 없었다. 문법이 맞는지가 아니라 기능이 맞는지를 재야 한다.
핵심 구조
- GitHub 코드로 GPT를 추가 학습시켜 Codex를 만든다. 함수 설명문에서 파이썬 함수를 만드는 문제 164개를 모아 HumanEval 벤치마크를 만든다. 채점은 단위 테스트 통과 여부로 한다.
주요 결과
- Codex가 HumanEval 문제의 28.8퍼센트를 풀었다. 같은 조건에서 GPT-3는 0퍼센트, GPT-J는 11.4퍼센트였다. 문제마다 답을 100개씩 뽑아 그중 하나라도 맞으면 인정하는 방식으로는 70.2퍼센트를 풀었다.
한계
- 연산이 길게 이어지거나 변수 묶임이 복잡한 문제에서 크게 떨어진다. 파이썬 단일 함수 위주라 산업 제어 언어는 다루지 않는다.
우리 기능과의 연결
- 회사 연결: 자연어 설명을 실행 가능한 코드로 바꾸고 그 결과를 테스트로 검증하는 문제라, 업무 실행 에이전트와 같은 문제를 다룬다. 아래 2번부터 6번까지의 산업 코드 생성 논문들이 모두 이 벤치마크 방식 위에 서 있다. 같은 해 나온 짝 벤치마크는 15번 MBPP다.
- T14-2유사문제
ChatGPT for PLC/DCS Control Logic Generation
한국어 검토 보기
해결 문제
- 자연어 요구사항을 PLC와 DCS 제어 로직으로 바꿀 수 있는지 확인한다. PLC는 공장 설비를 제어하는 산업용 컴퓨터다. DCS는 공정 전체를 나누어 제어하는 시스템이다.
핵심 구조
- 대표 범주 10개에 걸쳐 프롬프트 100개를 만든다. GPT-4로 답을 생성하고 사람이 평가한다.
주요 결과
- 상당수 경우에서 문법적으로 맞는 IEC 61131-3 정형 텍스트(ST) 코드를 만들었다. 쓸 만한 추론 능력도 보였다. 프롬프트 모음을 벤치마크 기반으로 공개했다.
한계
- 탐색적 연구다. 정량 벤치마크가 아니다. 문법이 맞아도 의미가 맞는지는 따로 검증하지 않았다.
우리 기능과의 연결
- 회사 연결: 자연어 지시를 설비 제어 로직이나 실행 스크립트로 바꾸는 업무 실행 에이전트와 같은 문제를 다룬다.
- T14-3구조대응
LLM4PLC: Harnessing Large Language Models for Verifiable Programming of PLCs in Industrial Control Systems
한국어 검토 보기
해결 문제
- GPT-4나 LLaMa2를 그냥 쓰면 산업 제어용으로 쓸 수 있는 프로그램이 나오지 않는다.
핵심 구조
- 생성과 검증을 반복하는 파이프라인이다. 문법 검사기, 컴파일러, SMV 모델 검증기를 붙인다. 프롬프트 설계와 LoRA 미세조정을 함께 쓴다. LoRA는 모델 일부만 저비용으로 학습시키는 방법이다.
주요 결과
- 생성 성공률이 47퍼센트에서 72퍼센트로 올랐다. 전문가 설문 기준 코드 품질이 2.25점에서 7.75점(10점 만점)으로 올랐다. FischerTechnik 제조 실습 장비에서 실제로 돌려 확인했다.
한계
- 검증 도구가 존재하는 언어와 도메인에서만 성립한다. 실습 장비 규모라 대형 라인 검증은 아니다.
우리 기능과의 연결
- 회사 연결: 생성한 결과를 컴파일러와 검증기로 되먹여 고치는 구조는 AI 기준정보 생성과 AI 보고서의 자동 검증 단계에 대응할 수 있다.
- T14-4후보
Agents4PLC: Automating Closed-loop PLC Code Generation and Verification in Industrial Control Systems using LLM-based Agents
한국어 검토 보기
해결 문제
- PLC 코드 생성과 검증을 사람 개입 없이 닫힌 고리로 돌리는 방법을 찾는다.
핵심 구조
- 여러 에이전트가 역할을 나눠 맡는 다중 에이전트 시스템이다. 검색 증강 생성(RAG), 프롬프트 기법, 사고 사슬을 함께 쓴다. 검증 가능한 PLC 코드 생성용 벤치마크도 같이 만든다.
주요 결과
- 기존 방법 대비 여러 난이도 지표에서 크게 앞섰다고 보고한다.
한계
- 벤치마크가 저자들이 만든 것이다. 실제 산업 현장 적용은 향후 과제로 남겼다.
우리 기능과의 연결
- 회사 연결: 역할을 나눈 에이전트가 생성과 검증을 반복하는 구조는 업무 실행 에이전트 설계의 향후 적용 후보다.
- T14-6유사문제
Automated Control Logic Test Case Generation using Large Language Models
한국어 검토 보기
해결 문제
- PLC와 DCS 제어 로직 테스트는 테스트 케이스 만들기가 어렵다. 기존 기호 실행이나 탐색 기반 방법은 형식 사양이 필요하고 상태 폭증 문제가 있다.
핵심 구조
- 프롬프트에 코드를 넣고 LLM이 테스트 케이스를 합성한다.
주요 결과
- 오픈소스 자동화 라이브러리 OSCAT의 함수 블록 10개로 평가했다. 단순하고 중간 정도 복잡도 프로그램에서 문장 커버리지가 높았다. 빠르고 쓰기 쉽다.
한계
- 생성된 테스트의 단언문(assertion)이 틀린 경우가 많다. 사람이 손봐야 한다.
우리 기능과의 연결
- 회사 연결: 만든 코드나 규칙을 스스로 시험하는 문제라, 제조 AI 분석 결과와 기준정보의 자동 검증에 같은 문제를 다룬다.
검토 메모
- 참고: arXiv 초록 페이지에는 게재 정보(journal-ref)가 비어 있다. dblp 서지 레코드에 ETFA 2024 정식 게재본이 잡힌다. 프리프린트가 아니라 동료평가를 거친 학회 논문이다.
- T14-7유사문제
Automated generation of OPC UA information models - A review and outlook
한국어 검토 보기
해결 문제
- OPC UA 정보 모델을 사람이 손으로 만들기가 번거롭다. OPC UA는 산업 설비 통신 국제 표준이다. 정보 모델은 설비 데이터의 뜻과 구조를 스스로 설명하게 만든 틀이다.
핵심 구조
- 자동 생성 방법을 유형별로 정리한 리뷰 논문이다. 관계형 데이터베이스에서 뽑는 방법, 도메인 모델이나 엔지니어링 도구와 언어에서 변환하는 방법, 부품 단위 모델을 합치는 방법을 비교한다.
주요 결과
- 도구 생태계와 엔지니어링 도구 사이의 상호운용이 OPC UA 잠재력을 여는 전제라고 결론짓는다.
한계
- 리뷰다. 새 실험 결과는 없다. 개별 방법의 현장 성능 비교는 부족하다.
우리 기능과의 연결
- 회사 연결: 설비 데이터에 뜻을 붙여 표준 모델로 자동 변환하는 문제라, QFactory MES의 AI 기준정보 생성 및 설비 데이터 수집과 같은 문제를 다룬다.
검토 메모
- 참고: 원문 제목은 콜론이 아니라 줄표를 쓴다. 출판사 표기는 "models — A review and outlook", dblp 표기는 "models - A review and outlook"이다.
- T14-8후보
Discoverer: Automatic Protocol Reverse Engineering from Network Traces
한국어 검토 보기
해결 문제
- 응용 계층 통신 규약의 사양을 알아내는 일이 거의 다 수작업이었다. 침입 탐지나 취약점 점검을 하려면 규약 사양이 필요한데 문서가 없다.
핵심 구조
- 통신 기록만 보고 메시지 포맷을 자동으로 복원하는 도구다. 특정 규약에 맞춘 규칙 없이, 여러 규약에 공통으로 나타나는 표현 관용구를 추론하는 방식으로 돈다.
주요 결과
- 텍스트 규약 HTTP 하나와 이진 규약 RPC, CIFS/SMB 두 개로 평가했다. 추론한 포맷의 90퍼센트 넘게가 실제 포맷 하나에 정확히 대응했다. 추론 포맷이 기록 속 메시지의 95퍼센트 이상을 덮었다.
한계
- 실제 포맷 하나가 평균 다섯 개 추론 포맷으로 쪼개져 나온다. 덮은 메시지가 실제 포맷 종류로는 30에서 40퍼센트에 그친다. 기록에 없는 경로는 못 잡는다.
우리 기능과의 연결
- 회사 연결: 통신 규약 역공학의 원조 논문이다. 문서 없는 설비 통신 규격을 기록만 보고 해석해야 하는 상황이 있어, 설비 데이터 수집의 향후 적용 후보다. 아래 9번 NetPlier가 이 계보를 잇는다. 반대로 실행 바이너리를 뜯는 계열은 14번 Polyglot이다.
- T14-9후보
NetPlier: Probabilistic Network Protocol Reverse Engineering from Message Traces
한국어 검토 보기
해결 문제
- 사양이 공개되지 않은 통신 프로토콜을 통신 기록만 보고 알아내야 한다.
핵심 구조
- 통신 메시지들을 다중 서열 정렬로 맞춘다. 메시지 종류를 가르는 핵심 필드를 확률 추론으로 고른다. 그 결과로 메시지를 묶고, 포맷을 복원하고, 상태 기계를 재구성한다.
주요 결과
- 프로토콜 10종 평가에서 기존 최고 수준을 크게 앞섰다. 사물인터넷 프로토콜 분석과 악성코드 조사에 유용하다고 밝힌다.
한계
- 통신 기록에 나타난 동작만 복원한다. 기록에 없는 예외 경로는 못 잡는다. 암호화된 통신에는 바로 못 쓴다.
우리 기능과의 연결
- 회사 연결: 문서 없는 설비 통신 규격을 기록만 보고 해석해야 하는 상황이 있어, 설비 데이터 수집의 향후 적용 후보다. 기록이 아니라 실행 파일을 보는 쪽은 14번 Polyglot이다.
- T14-10구조대응
Automated Attack Synthesis by Extracting Finite State Machines from Protocol Specification Documents
한국어 검토 보기
해결 문제
- 프로토콜 사양이 영어 산문(RFC 문서)으로만 있다. 이걸 사람이 상태 기계로 옮기면 오래 걸리고 논리 오류가 난다.
핵심 구조
- 세 단계 혼합 방식이다. 첫째, 기술 문서용 대규모 단어 표현 학습이다. 둘째, 사양 문장을 프로토콜과 무관한 중간 표현으로 옮기는 제로샷 학습이다. 셋째, 중간 표현을 특정 프로토콜의 상태 기계로 바꾸는 규칙 기반 변환이다.
주요 결과
- BGPv4, DCCP, LTP, PPTP, SCTP, TCP 여섯 개 프로토콜로 검증했다. TCP와 DCCP에서는 뽑아낸 상태 기계로 공격 시나리오 합성까지 자동화했다.
한계
- 규칙 기반 마지막 단계가 프로토콜마다 손이 간다. 문서가 애매하게 쓰인 부분은 복원이 어렵다.
우리 기능과의 연결
- 회사 연결: 사람이 읽는 사양 문서에서 기계가 쓰는 모델을 뽑아내는 구조라, 설비 매뉴얼과 규격서에서 기준정보와 수집 규칙을 만드는 작업에 대응할 수 있다.
- T14-11구조대응
Syntax-Guided Synthesis
한국어 검토 보기
해결 문제
- 프로그램 합성은 원래 "논리식으로 준 정확성 사양을 만족하는 프로그램을 찾아라"였다. 프로그램 합성은 사양만 주면 프로그램을 자동으로 만들어내는 기술이다. 그런데 찾을 공간이 너무 넓어 잘 안 풀린다.
핵심 구조
- 논리 사양에 더해 후보 프로그램의 모양을 문법으로 제한하는 문제 틀을 정의한다. 입력은 배경 이론, 만족해야 할 논리식, 후보 식의 집합을 정하는 문법 세 가지다. 출력은 그 문법이 허용하는 식 중 논리식을 만족하는 것이다.
주요 결과
- 흩어져 있던 여러 합성 연구를 하나의 표준 문제 정의로 묶었다. 이 정의를 바탕으로 표준 입력 형식, 벤치마크 모음, 해법 경진대회(SyGuS-COMP)가 만들어졌다. 공식 사이트는 https://www.sygus.org 다.
한계
- 문법을 사람이 잘 짜 줘야 한다. 문법이 너무 넓으면 안 풀리고 너무 좁으면 답이 아예 없다. 논리로 검증 가능한 이론 안에서만 성립한다.
우리 기능과의 연결
- 회사 연결: 이 분야의 표준 문제 정의 틀이다. 이 계열의 앞 고리는 13번 Combinatorial Sketching이다. 후보 공간을 문법으로 좁히고 사양을 만족하는 변환식을 찾는 구조라, 설비 태그와 코드 체계를 표준 기준정보로 바꾸는 변환 규칙 생성에 대응할 수 있다. 아래 12번 FlashFill이 이 틀의 대표 사례다.
- T14-12구조대응
Automating string processing in spreadsheets using input-output examples
한국어 검토 보기
해결 문제
- 일반 사용자가 표 안의 문자열 데이터를 정리하려면 프로그램을 짜야 한다. 그걸 못 하니 손으로 반복한다.
핵심 구조
- 제한된 정규식과 조건, 반복을 담은 작은 문자열 처리 언어를 설계한다. 입력과 출력 예시 몇 개만으로 그 언어의 프로그램을 합성하는 알고리즘을 제시한다.
주요 결과
- 사용자들이 어려워하는 다양한 문자열 변환 작업을 예시 몇 개로 자동화했다. 나중에 엑셀의 빠른 채우기 기능으로 제품화됐다.
한계
- 문자열 도메인에 한정된다. 예시가 애매하면 의도와 다른 프로그램이 나온다.
우리 기능과의 연결
- 회사 연결: 예시 몇 개로 변환 규칙을 만들어내는 구조라, 설비별 태그명과 코드 체계를 표준 기준정보로 바꾸는 AI 기준정보 생성에 대응할 수 있다.
- T14-13구조대응
Combinatorial Sketching for Finite Programs
한국어 검토 보기
해결 문제
- 프로그램 합성기는 그때까지 도메인별 규칙을 사람이 넣어줘야 돌았다. 규칙을 안 넣으면 후보 공간이 너무 넓어 못 푼다.
핵심 구조
- 스케치라는 방식을 쓴다. 프로그래머가 뼈대만 있는 부분 프로그램을 쓰고, 어려운 조각은 구멍(hole)으로 비워둔다. 원하는 동작은 따로 사양으로 준다. SKETCH 언어와 합성기가 구멍을 채운다. 채우는 방법은 도메인 규칙이 아니라 일반화된 불리언 만족성(SAT) 기반 조합 탐색이다. 해법 후보를 찾는 SAT 풀이기와 그 후보가 모든 입력에서 사양과 같은지 확인하는 SAT 풀이기를 짝지어 돌린다. 반례가 나오면 입력 집합에 넣고 다시 돈다.
주요 결과
- AES 암호 알고리즘의 효율적 구현을 합성했다. 가장 복잡한 부분을 합성기가 만들었고 약 한 시간 걸렸다. 유한 프로그램 부류에서는 원리상 항상 스케치를 완성할 수 있다고 밝힌다.
한계
- 유한 프로그램에 한정된다. 구멍의 자리와 모양을 사람이 잡아줘야 한다. 탐색 문제 자체가 계산량이 크다(2QBF).
우리 기능과의 연결
- 회사 연결: 골격과 구멍으로 후보 공간을 좁혀 합성하는 방식의 원조 논문이다. 위 11번 Syntax-Guided Synthesis가 이 계열을 하나의 표준 문제 정의로 묶었다. 변환 규칙의 틀을 사람이 잡고 빈칸만 기계가 채우는 구조라, 설비 태그를 표준 기준정보로 바꾸는 변환 규칙 생성에 대응할 수 있다.
검토 메모
- 참고: 논문 표지의 저자 순서는 Saraswat이 Seshia보다 앞이다. dblp는 Seshia를 앞에 적는다. 저자 다섯 명은 같다.
- T14-14후보
Polyglot: Automatic Extraction of Protocol Message Format using Dynamic Binary Analysis
한국어 검토 보기
해결 문제
- 통신 규약 역공학을 통신 기록만 보고 하면 한계가 있다. 기록에는 의미 정보가 없기 때문이다.
핵심 구조
- 통신 기록 대신 실행 바이너리를 본다. 프로그램이 받은 데이터를 처리하는 방식 자체가 메시지 포맷을 드러낸다는 점을 쓴다. 에뮬레이터 안에서 프로그램을 돌리고, 네트워크로 들어온 바이트에 표시를 붙여 어디로 퍼지는지 따라간다(동적 오염 분석). 이 방식을 섀도잉이라 부르고 Polyglot 도구로 구현했다.
주요 결과
- 실제 구현체로 규약 다섯 개를 평가했다. DNS, HTTP, IRC, Samba, ICQ다. 결과를 사람이 손으로 만든 Wireshark 포맷과 비교했다. 차이가 작았고, 남은 차이는 구현체마다 필드를 다르게 다루기 때문이었다. 그 차이를 찾는 것 자체가 지문 생성과 퍼징에 쓸모 있다고 밝힌다.
한계
- 분석에 넣은 메시지의 포맷만 얻는다. 안 나온 메시지는 모른다. 필드 자료형이나 바이트 순서 같은 속성은 뽑지 않는다. 바이트 단위라 1바이트보다 짧은 플래그 필드는 못 가른다. 메시지 경계 찾기는 향후 과제로 남겼다. 난독화에는 약하다.
우리 기능과의 연결
- 회사 연결: 위 8번 Discoverer와 9번 NetPlier는 통신 기록만 보는 방식이다. 이 논문은 실행 바이너리를 뜯는 반대편 대표 계열이다. 설비 드라이버 실행 파일은 있는데 규격서가 없는 상황이 있어, 설비 데이터 수집의 향후 적용 후보다.
- T14-15유사문제
Program Synthesis with Large Language Models
한국어 검토 보기
해결 문제
- 큰 언어모델이 자연어 설명으로 코드를 얼마나 쓰는지 재려면 문제 모음이 더 필요하다. 파이썬 입문 수준 문제와 수학 문제를 함께 봐야 한다.
핵심 구조
- 파라미터 244M에서 137B까지 모델을 놓고 비교한다. 벤치마크 두 개를 새로 만든다. MBPP는 입문 수준 파이썬 문제 974개다. MathQA-Python은 수학 문제를 파이썬으로 옮긴 23,914개다. 몇 개 예시만 주는 방식과 미세조정 방식을 둘 다 잰다. 사람이 대화로 고쳐주는 실험도 한다.
주요 결과
- 합성 성능이 모델 크기에 대해 로그 선형으로 는다. 가장 큰 모델이 MBPP에서 예시 몇 개만 줬을 때 59.6퍼센트, 미세조정하면 약 69.6퍼센트를 풀었다. MathQA-Python에서는 83.8퍼센트였다. 사람이 한 번 고쳐주면 오류율이 절반으로 줄었다.
한계
- 모델이 자기가 만든 프로그램의 실행 결과를 잘 예측하지 못한다. 입문 수준 파이썬 문제 위주라 산업 제어 언어는 다루지 않는다.
우리 기능과의 연결
- 회사 연결: 위 1번 HumanEval과 짝을 이루는 표준 코드 생성 벤치마크다. 벤치마크 축이 둘이라야 2번부터 6번까지의 산업 코드 생성 논문이 어떤 평가 관행 위에 서 있는지 제대로 잡힌다. 자연어 지시를 실행 가능한 코드로 바꾸고 테스트로 채점하는 문제라, 업무 실행 에이전트와 같은 문제를 다룬다.
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기