PLC 프로그램 자동 오류 검사·수정 솔루션 조사 및 도입 계획 — 근거 기반 분석과 산출물 평가 방안
초록
PLC(IEC 61131-3) 프로그램의 자동 오류 검사·수정 솔루션을 정적분석/정형검증/벤더 시뮬레이션/AI 기반 자동수정 4개 범주로 실증 조사하고, 각 범주의 산업 채택 사례와 학술적 성숙도를 근거로 단계별 도입 로드맵을 제안한다. 아울러 정밀도·재현율·거짓양성률 등 확립된 지표를 이용해 도입 산출물(결함 검출률, 오탐률, 수정 소요시간)을 평가하는 방법론을 함께 제시한다.
PLC 프로그램 자동 오류 검사·수정 솔루션 조사 및 도입 계획 — 근거 기반 분석과 산출물 평가 방안
문서 메타데이터
- 작성: Ari · Commander
- 작성일: 2026-09-07
- 관련 프로젝트: CMG X Welder 협동로봇 용접 셀 (제어 로직/PLC 연동 검토 참고 자료)
- 범위: 시중에 실재하는 PLC 정적분석·정형검증·AI 기반 자동수정 솔루션 조사, 근거 기반 단계별 도입 계획, 산출물(도구 도입 효과) 평가 방법론
요약
PLC(Programmable Logic Controller) 프로그램의 결함은 생산 중단뿐 아니라 안전사고로 직결될 수 있어, 수동 코드 리뷰만으로는 품질을 담보하기 어렵다. 본 보고서는 (1) 실제 존재하는 PLC 자동 오류 검사·수정 솔루션을 정적분석/정형검증/벤더 시뮬레이션·테스트/AI 기반 자동수정 4개 범주로 조사하고, (2) 각 범주의 성숙도·리스크를 근거로 단계적 도입 계획을 제시하며, (3) 도입 후 산출물(결함 검출률, 오탐률, 수정 소요시간 등)을 정량 평가할 수 있는 방법론을 제안한다.
핵심 결론: 정적분석(낮은 리스크·빠른 ROI) → 벤더 시뮬레이션/유닛테스트 결합 → 안전필수 로직에 한해 정형검증 → AI 기반 자동수정은 보조 도구로만, 사람 검토 필수의 순서로 도입하는 것이 산업계 실제 사례와 학술 연구 결과에 부합한다.
1. 배경 및 목적
PLC 프로그램(래더 다이어그램·구조화 텍스트 등 IEC 61131-3 언어)은 수십 년간 축적된 레거시 코드, 다수 엔지니어의 손을 거친 수정 이력, 그리고 하드웨어 종속적 부작용(사이드 이펙트) 때문에 일반 소프트웨어보다 정적 검증이 어렵다고 알려져 있다. 그럼에도 PLC 프로그래밍 언어의 특성(제한된 문법, 명시적 상태) 자체는 정적 분석 기법에 유리한 조건을 제공한다 (Prähofer & Angerer, IEEE).
CMG X Welder와 같은 협동로봇 용접 셀은 티칭펜던트·아크센싱·안전 인터록 로직이 PLC/컨트롤러 펌웨어 수준에서 얽혀 있어, 로직 결함이 곧 용접 품질 저하나 안전 인터록 오작동으로 이어질 수 있다. 본 조사는 이런 배경에서 "자동으로 검사하고, 가능하면 자동으로 수정까지 하는" 솔루션이 실제로 어디까지 와 있는지, 그리고 그걸 우리 프로젝트에 어떤 순서로 들여올 수 있는지를 근거를 갖고 정리하기 위한 것이다.
2. 조사 방법론
공개된 학술 문헌(IEEE, arXiv), 벤더 공식 문서, 산업 매체 기사를 교차 확인하여 다음 4개 범주로 솔루션을 분류했다.
- 정적 분석(Static Analysis) — 코드를 실행하지 않고 규칙/패턴/데이터흐름 분석으로 결함을 찾는 도구
- 정형 검증(Formal Verification / Model Checking) — 수학적 모델에 대해 모든 입력·실행 경로를 검증하는 기법
- 벤더 시뮬레이션·유닛테스트 — 실제 PLC 없이 가상 컨트롤러로 테스트 케이스를 실행하는 도구
- AI/LLM 기반 자동 생성·수정 — 최근 2년 내 학술적으로 활발히 연구되고 있는, 자연어/컴파일러 피드백 기반 자동 수정 접근
각 범주에 대해 "검사만 하는가, 수정까지 하는가", "상용/오픈소스 여부", "실제 산업 적용 사례 유무"를 기준으로 근거를 정리했다.
3. 솔루션 조사 결과
3.1 정적 분석 도구
| 도구 | 제공 방식 | 핵심 내용 | 근거 |
|---|---|---|---|
| PLC Checker (Schneider Electric, 구 Itris Automation) | 상용, 2008년 출시 | PLCopen 코딩 가이드라인 지원, 규칙 위반마다 메시지 생성, 1400명 이상 사용자 확보 | Control Design |
| CODESYS Static Analysis | 상용(Professional Developer Edition 번들), 무료 Light 버전 존재 | 100개 이상 규칙, PLCopen 가이드라인 기반 + 확장, 20개 이상 품질 메트릭, 최근 버전은 "코드 스멀" 탐지 + 수정 힌트 제공 | CODESYS 공식 |
| IEC Checker | 오픈소스 | PLCopen SW Construction Guidelines 26개 규칙 체크, 선언부 분석, 도달불가 코드·미사용 변수 탐지 | GitHub |
| Symbolic Execution 기반 ST 분석 (학술) | 연구 프로토타입 | Structured Text 프로그램에 대해 기호 실행으로 정적 분석 수행, 패턴매칭·데이터흐름 분석을 넘어서는 정밀도 목표 | IEEE 2024 |
PLCopen 코딩 가이드라인은 2016년 4월 발표된 64개 모범사례 규칙(명명규칙·주석·코딩관행·언어사용)으로, 위 도구들 대부분이 공통 기준으로 채택하고 있다 (PLCopen, Automation.com). 즉 "무엇을 오류/나쁜 코드로 볼 것인가"에 대한 업계 표준이 이미 존재하며, 자체 규칙을 처음부터 설계할 필요가 없다는 점이 중요한 근거다.
3.2 정형 검증 (Model Checking)
| 도구 | 개발/운영 주체 | 핵심 내용 | 근거 |
|---|---|---|---|
| PLCverif | CERN, 2019년 내부 사용 시작 → 2020년 9월 오픈소스 공개 | Siemens SCL(TIA Portal) 및 OpennessScripter 경유 FBD 입력 지원, CBMC(SAT 기반 유한상태 검증)·nuXmv(BDD/IC3 기반 무한증명) 백엔드 사용 | CERN Document Server, arXiv 2203.17253 |
| PLCverif 실적 | CERN SPS-PPS 가속기, GSI 중이온가속기 | 2019년부터 안전필수(Safety-critical) 빔 인터록 시스템 실제 검증에 투입, 수동 리뷰를 통과했던 잠재적 안전 위반(latent safety violation)을 실제로 검출한 사례 있음 | arXiv 2203.17253 |
| ESBMC-PLC / ESBMC-PLC+ / ESBMC-GraphPLC | 학술 연구(2026년 최신) | SMT 기반 모델체킹으로 IEC 61131-3 래더 다이어그램(텍스트 및 PLCopen XML 그래픽 형식 포함)을 검증, PLCverif 후속 통합 프레임워크로 제안됨 | arXiv 2606.15461, arXiv 2606.23870 |
정형 검증은 정적 분석보다 훨씬 강력한 보증(모든 입력·실행 경로에 대한 수학적 증명)을 제공하지만, 모델링 비용이 크고 실행 시간이 오래 걸리는 경향이 있어 안전필수 로직에 선택적으로 적용하는 것이 CERN 사례를 포함한 실제 관행이다.
3.3 벤더 시뮬레이션·유닛테스트 도구
| 도구 | 벤더 | 핵심 내용 | 근거 |
|---|---|---|---|
| TIA Portal Test Suite (+ PLCSIM Advanced) | Siemens | Arrange-Act-Assert 구조의 테스트 케이스를 표 형식으로 정의, 가상 PLC(PLCSIM Advanced)로 실행해 입력 주입·출력 캡처·고해상도 리포트 생성. 물리적 하드웨어 없이 자동 테스트 가능 | Outlier Automation, Siemens 공식 문서 |
| Studio 5000 Emulate / Logix Echo | Rockwell Automation | 물리 컨트롤러 없이 제어 로직 검증·테스트·최적화, FactoryTalk Logix Echo는 실제 Rockwell PLC 프로젝트를 컨트롤러/I/O 변경 없이 그대로 다운로드해 테스트 가능 | Rockwell 공식 |
| 가상 시운전(Virtual Commissioning) | Rockwell + MapleSim/Emulate3D/Simulink 연계 | 물리 프로토타입 제작 전 제어 코드를 모델에 대해 HIL(Hardware-in-the-Loop) 방식으로 테스트 | Maplesoft |
이 범주는 "오류 검사"보다는 "회귀 방지(코드를 고친 뒤 기존 동작이 안 깨졌는지 확인)"에 강점이 있다. 정적분석·정형검증으로 못 잡는 런타임/타이밍 관련 결함을 여기서 보완할 수 있다.
3.4 AI/LLM 기반 자동 생성·수정 (신흥 분야, 성숙도 낮음)
| 연구/도구 | 핵심 내용 | 근거 |
|---|---|---|
| LLM4PLC | 사용자 피드백 + 외부 검증도구(문법 검사기, 컴파일러, SMV 검증기)를 결합한 반복(iterative) 파이프라인, LoRA 파인튜닝으로 성능 개선 | ACM ICSE-SEIP 2024 |
| 컴파일 오류 자동 수정 (산업 임베디드 코드 대상) | 테스트 케이스 없이 LLM이 컴파일 오류를 수정 — 83% 그럴듯한(plausible) 수정 성공률, 그중 17%는 원본과 정확히 일치(exact match) | arXiv 2510.13575 |
| 구문 오류 자동 수정 (이산 컨트롤러 합성용) | MATIEC으로 구문 오류를 탐지 후 "수정 프롬프트"를 생성해 LLM에 피드백하는 파이프라인 | arXiv 2512.07261 |
| 한계 — GPT-4/LLaMA2 등 범용 LLM | 산업제어시스템(ICS)용 유효한 PLC 프로그램 생성에 실패하는 사례가 다수 보고됨 → 도메인 특화 파이프라인(문법 체커·컴파일러·정형검증기와의 결합) 없이는 신뢰 불가 | ACM ICSE-SEIP 2024 |
| 정적 버그 탐지의 오탐 완화에 LLM 활용 | (PLC 전용은 아니지만 참고할 방법론) 산업 현장에서 정적분석 오탐률이 90%를 넘는 문제를 LLM으로 재판별해 줄이는 실증 연구 | arXiv 2601.18844 |
결론적으로 AI 기반 "자동 수정"은 아직 컴파일/구문 오류 등 좁은 범위에서만 신뢰할 만한 성공률(83%)을 보이며, 안전 관련 로직의 의미(semantic) 수정에 그대로 맡길 단계는 아니다. 다만 "정적분석이 만들어낸 대량의 오탐을 걸러주는 보조 판별자" 역할로는 이미 실증된 활용법이 있다.
4. 근거 기반 도입 계획
조사 결과를 종합하면, 리스크가 낮고 근거(산업 채택 사례)가 가장 두꺼운 것부터 순서대로 도입하는 것이 합리적이다.
1단계 (0~2개월) — 정적 분석 파일럿 도입
- PLCopen 코딩 가이드라인 기반 도구(CODESYS 사용 환경이면 CODESYS Static Analysis, 그 외 벤더는 PLC Checker) 파일럿 적용
- 오픈소스 IEC Checker를 병행 검토(비용 없이 26개 핵심 규칙만 우선 스크리닝)
- 선정 이유: 1400명 이상 사용자 기반, 업계 표준 규칙셋 존재 → 도입 리스크가 가장 낮음
2단계 (2~4개월) — 벤더 시뮬레이션/유닛테스트 결합
- 사용 컨트롤러 벤더에 맞춰 TIA Portal Test Suite+PLCSIM Advanced 또는 Studio 5000 Emulate/Logix Echo 도입
- 정적분석에서 못 잡는 런타임 결함을 회귀 테스트로 보완
- 선정 이유: 물리 하드웨어 없이 반복 테스트 가능 → 현장 정지 리스크 없이 검증 주기 단축
3단계 (4~8개월) — 안전필수 로직에 한해 정형검증 적용
- CMG X Welder의 안전 인터록·비상정지 로직 등 안전필수(safety-critical) 구간에 한정하여 PLCverif류 모델체킹 시범 적용
- CERN 사례처럼 "수동 리뷰를 통과한 잠재적 안전 위반"을 잡아내는 것이 목표이므로, 전체 코드가 아니라 리스크가 높은 구간에 선택 적용
- 선정 이유: 모델링 비용이 크므로 ROI가 확실한 구간에만 투입해야 함
4단계 (8개월~, 시범) — AI 보조 도구 제한적 적용
- LLM 기반 자동 수정은 컴파일/구문 오류 자동 제안 범위로 한정하고, 모든 제안은 사람이 최종 승인
- 정적분석 오탐률이 높을 경우, LLM을 "오탐 재판별기"로 시범 활용
- 선정 이유: 현재 연구 성숙도(83% plausible-fix 수준, 의미적 오류에는 신뢰 부족)를 고려한 보수적 적용
CMG X Welder 프로젝트 연계 제안
X Welder의 티칭펜던트 UI 로직·아크센싱 오프셋 보정 로직·안전 인터록은 3단계(정형검증) 적용 우선순위가 높은 후보다. 반면 일반 티칭 패턴 로직(수직/수평/호/원)은 1~2단계만으로도 충분할 가능성이 크다 — 즉 전체를 한 단계로 몰아넣지 말고, 로직의 안전 관련도에 따라 도입 단계를 차등 적용하는 것을 권장한다.
5. 산출물(도입 효과) 평가 방법론
"도구를 도입했다"는 것 자체가 산출물이 아니라, 결함을 실제로 더 잘 찾아내고, 덜 틀리고, 더 빨리 고쳤는가가 산출물이다. 학술적으로 확립된 정적분석 평가 지표를 그대로 차용한다.
5.1 핵심 지표
| 지표 | 정의 | 왜 필요한가 |
|---|---|---|
| 정밀도(Precision) | 참양성 / (참양성 + 거짓양성) | 오탐이 많으면 엔지니어가 도구를 신뢰하지 않고 무시하게 됨 |
| 재현율(Recall) | 참양성 / (참양성 + 거짓음성) | 실제 결함을 놓치면 도구 도입 의미가 없음 |
| F-Score | 정밀도·재현율의 조화평균 | 두 지표 간 트레이드오프를 한 숫자로 요약 |
| 거짓양성률(FPR) | 거짓양성 / (거짓양성 + 참음성) | 산업 현장 정적분석 도구는 통상 FPR이 매우 높다는 것(90% 이상 사례 보고)이 알려져 있어(arXiv 2601.18844), 이 수치를 반드시 별도로 추적해야 함 |
참고: 일반적으로 기업용 정적분석 도구는 "결함을 놓치지 않는 것"(재현율)을 "오탐을 줄이는 것"(정밀도)보다 우선하도록 설계되는 경향이 있고, 그 결과 거짓양성률이 90%를 넘는 사례까지 보고된다 (arXiv 2601.18844). 즉 "경고가 많이 뜬다 = 도구가 잘 작동한다"가 아니라는 점을 평가 설계 단계에서부터 반영해야 한다.
5.2 평가 절차 제안
- 베이스라인 수집 — 도구 도입 전 최근 6개월간 실제 발생한 PLC 결함(현장 리포트, 버그 트래커) 목록을 수집해 "정답 데이터셋(ground truth)"으로 삼는다.
- 재현 테스트 — 같은 코드베이스에 도구를 실행해, 베이스라인의 결함 중 몇 건을 실제로 잡아내는지(재현율), 그 외에 얼마나 많은 무관한 경고를 내는지(정밀도/FPR)를 측정한다.
- 수정 소요시간(MTTR) 비교 — 결함 발견부터 수정 완료까지 걸리는 시간을 도구 도입 전/후로 비교한다. 벤더 테스트 도구(3.3절)는 특히 이 지표에 기여할 것으로 예상된다.
- AI 자동수정 제안의 채택률 — 4단계 도입 시, LLM이 제안한 수정 중 사람이 그대로 채택한 비율을 별도로 추적한다(학술 문헌의 83% plausible-fix, 17% exact-match 수치를 우리 환경에서 재현되는지 검증).
- 파일럿 성공 기준(예시, 사업 특성에 맞게 조정 필요)
- 정적분석: 재현율 60% 이상 & FPR 40% 이하일 때 정식 도입 검토
- 벤더 테스트 도구: 결함 수정 후 회귀 테스트에 걸리는 평균 시간이 기존 대비 50% 이상 단축
- 정형검증: 안전필수 구간에서 수동 리뷰가 놓친 결함을 1건 이상 실제로 검출 (CERN 사례가 근거)
- AI 보조: 사람이 그대로 채택하는 비율이 50% 미만이면 해당 단계는 보류하고 파이프라인 재검토
5.3 평가 시 유의사항
- 위 성공 기준 수치는 확정값이 아니라 조사된 학술/산업 사례를 참고선으로 삼은 제안치이며, 실제 파일럿 착수 전 우리 코드베이스 특성(라인 수, 기존 결함 밀도)에 맞게 조정이 필요하다.
- 여러 정적분석 도구 간 경고 일치율이 낮다는 연구 결과(arXiv 2101.08832)가 있으므로, 한 도구의 결과만으로 "결함이 없다"고 판단하지 않는다.
6. 리스크 및 제한사항
- 정형검증의 확장성 한계 — 모델링 비용이 크므로 전체 코드베이스에 일괄 적용은 비현실적. 안전필수 구간 선별이 전제조건.
- AI 자동수정의 신뢰성 한계 — 범용 LLM은 유효한 ICS 프로그램 생성에 실패한 사례가 보고됨. 도메인 특화 검증 파이프라인 없이 단독 사용 금지.
- 오탐 피로(Alert Fatigue) — 산업 현장 정적분석 도구의 높은 FPR 보고 사례를 감안하면, 초기 파일럿에서 경고를 거르지 않고 그대로 현업에 노출하면 도구 자체가 외면받을 위험이 있음. 1단계부터 "심각도별 필터링" 운영 규칙을 함께 설계해야 함.
- 안전 로직 자동 수정 금지 원칙 — 어떤 단계에서도 안전 인터록·비상정지 관련 로직의 자동 수정 결과를 사람 승인 없이 배포하지 않는다.
7. 결론 및 다음 단계
실재하는 PLC 자동 검사·수정 생태계는 "검사(정적분석·정형검증)"는 상당히 성숙한 반면, "수정"은 컴파일/구문 오류 범위를 벗어나면 아직 연구 단계라는 것이 이번 조사의 핵심 근거다. 따라서 이번 계획은 검사 자동화를 먼저 확실히 정착시키고, 수정 자동화는 좁고 안전한 범위(컴파일 오류)부터 조심스럽게 확장하는 순서로 설계했다.
다음 단계 제안: 1. 사용 중인 PLC/컨트롤러 벤더 확정 (CODESYS 계열인지, Siemens/Rockwell 계열인지에 따라 1~2단계 도구 선택이 달라짐) 2. 1단계 정적분석 파일럿 대상 코드베이스(모듈) 선정 3. 5.2절 평가 절차에 필요한 "베이스라인 결함 데이터셋" 수집 착수
참고 자료
- Prähofer, H. & Angerer, F., "Static Code Analysis of IEC 61131-3 Programs: Comprehensive Tool Support and Experiences from Large-Scale Industrial Application", IEEE. https://ieeexplore.ieee.org/document/7557072/
- "Static Code Analysis of IEC 61131-3 ST Programs via Symbolic Execution", IEEE, 2024. https://ieeexplore.ieee.org/document/10831127/
- IEC Checker (오픈소스). https://github.com/iec-checker/iec-checker
- PLCopen Software Construction Guidelines. https://plcopen.org/software-construction-guidelines
- "PLC Checker supports PLCopen coding guidelines", Control Design. https://www.controldesign.com/industry-news/news/11312959/plc-checker-supports-plcopen-coding-guidelines
- CODESYS Static Analysis 공식 페이지. https://www.codesys.com/ecosystem/release-lifecycle/releases-updates/static-analysis/
- "PLCverif: A Tool to Verify PLC Programs Based on Model Checking Techniques", CERN Document Server. https://cds.cern.ch/record/2213507
- "PLCverif: Status of a Formal Verification Tool for Programmable Logic Controller", arXiv:2203.17253. https://arxiv.org/abs/2203.17253
- "ESBMC-PLC: Formal Verification of IEC 61131-3 Ladder Diagram Programs Using SMT-Based Model Checking", arXiv:2606.15461. https://arxiv.org/pdf/2606.15461
- "ESBMC-PLC+: A Unified IEC 61131-3 Formal Verification Framework as a PLCverif Successor", arXiv:2606.23870. https://arxiv.org/pdf/2606.23870
- "Using Siemens Test Suite Advanced for Application Tests in TIA Portal", Outlier Automation. https://www.outlierautomation.com/blog/using-siemens-test-suite-advanced-for-application-tests-in-tia-portal
- Siemens TIA Portal Test Suite 공식 문서. https://docs.tia.siemens.cloud/r/en-us/v20/tia-portal-test-suite/application-test/test-case-execution/introduction
- Studio 5000 Logix Emulate, Rockwell Automation 공식. https://www.rockwellautomation.com/en-in/products/software/factorytalk/designsuite/studio-5000/studio-5000-logix-emulate.html
- "Virtual Commissioning with MapleSim & Studio 5000", Maplesoft. https://www.maplesoft.com/solutions/engineering/AppAreas/Virtual-Commissioning-Studio5000.aspx
- "LLM4PLC: Harnessing Large Language Models for Verifiable Programming of PLCs in Industrial Control Systems", ACM ICSE-SEIP 2024. https://dl.acm.org/doi/10.1145/3639477.3639743
- "Auto-repair without test cases: How LLMs fix compilation errors in large industrial embedded code", arXiv:2510.13575. https://arxiv.org/html/2510.13575
- "Automatic Syntax Error Repair for Discrete Controller Synthesis using Large Language Model", arXiv:2512.07261. https://arxiv.org/pdf/2512.07261
- "Reducing False Positives in Static Bug Detection with LLMs: An Empirical Study in Industry", arXiv:2601.18844. https://arxiv.org/html/2601.18844v1
- "A Critical Comparison on Six Static Analysis Tools: Detection, Agreement, and Precision", arXiv:2101.08832. https://arxiv.org/pdf/2101.08832
이 보고서는 CMG X Welder 프로젝트의 제어 로직 품질 관리 방안을 검토하는 과정에서 작성되었으며, 위 도입 계획·평가 기준 수치는 확정된 사업 계획이 아니라 조사된 근거를 바탕으로 한 제안이다. 실제 도입 전 사용 중인 PLC/컨트롤러 벤더, 코드베이스 규모, 안전 인증 요구사항에 맞춘 재검토가 필요하다.