검증 게이트로 PLC 코드 실행 신뢰성 높이기

왜 중요한가

PLC 코드 생성은 독립적인 POU가 컴파일되는지만으로 실제 제어 로직의 신뢰성을 판단하기 어렵습니다. SemaPLC는 기존 프로젝트에 코드를 맞추고 specification, compilation, live runtime의 외부 검증 결과가 모두 기록될 때만 완료를 인정해, 정적 점수가 비슷한 방법 사이의 실행 동작 차이를 드러냈습니다.

핵심 기여

검증 게이트 기반 PLC 에이전트 하니스

SemaPLC는 task 또는 기존 PLC project를 grounding context로 사용하고 specification audit, compilation, live runtime validation을 하나의 반복 루프에 결합합니다. 검증 결과가 실패하거나 없으면 diagnostic feedback을 바탕으로 로직을 수정하며, 모델의 자기 판단만으로 완료하지 않습니다. 수정이 발생하면 이전 verdict를 무효화하고 모든 검사를 다시 실행해 보고된 pass와 실제 전달 바이트를 일치시킵니다.

독립 POU와 프로젝트 맥락의 이중 평가

117개 independent-POU task에서는 held-out judge의 strict verified pass rate로 기존 benchmark와 비교합니다. 65개 project-context task에서는 기존 IEC 61131-3 ST project 안에서 integrated compilation, static behavior, dynamic behavior를 같은 task 분모로 따로 측정합니다. 이 구분으로 코드가 빌드되는지, 텍스트 수준 요구사항을 만족하는지, 실행 trace가 기준 동작과 일치하는지를 분리해 확인합니다.

정적 평가와 실행 평가 사이의 차이 측정

SemaPLC의 dynamic behavior 평균은 52.2로, baseline 최고 평균인 AutoPLC의 31.4보다 높았습니다. Baseline의 static behavior 평균은 71.7에서 75.7 사이로 서로 가까웠지만 dynamic behavior 평균은 22.4에서 31.4 사이로 벌어졌습니다. 이 결과는 PLC 로직의 timer, reset, state transition, interlock 오류가 실행 단계에서 더 분명하게 드러난다는 점을 수치로 확인합니다.

핵심 아이디어 이해하기

일반적인 LLM code generation은 요구사항을 입력으로 받아 독립적인 코드를 출력하고, 모델이나 단순 compiler check가 충분하다고 판단하면 결과를 반환합니다. PLC에서는 코드가 문법적으로 맞아도 기존 project의 변수와 function block interface에 연결되지 않거나, scan cycle에 따른 상태와 timing을 잘못 처리할 수 있습니다. 따라서 compile 성공은 실행 가능한 최소 조건일 뿐이며, 요구사항에 맞는 외부 동작까지 보장하지 않습니다.

SemaPLC는 먼저 task context 또는 기존 project에서 관련 module, variable declaration, interface, function block을 찾고 그 범위 안에서 로직을 생성합니다. 생성된 코드는 specification audit, compilation, live runtime validation을 차례로 거치며, 각 검사는 pass 여부와 구체적인 diagnostic을 외부 도구 로그에 남깁니다. 실패한 검사의 diagnostic이 다음 Repair 입력으로 들어가므로 입력은 요구사항과 project context이고, 처리 과정은 생성, 실행 검사, 국소 수정의 반복이며, 출력은 로그로 검증된 구현 또는 failure입니다.

검증 게이트는 모델의 자기 보고를 신뢰하지 않고 검사 결과가 completion criteria를 만족하는지 판정합니다. 어떤 수정이라도 이전 verdict를 무효화하고 후보의 정확한 바이트에 대해 검사를 다시 수행하며, 로그에 없는 pass는 unchecked로 낮춥니다. 이 방식은 코드가 컴파일되지만 fault 조건에서 잘못된 setpoint를 출력하는 문제처럼 정적 검사만 통과하는 의미 오류를 live runtime에서 잡아냅니다.

Function track의 strict 기준은 원문 식인 $\mathrm{VerifiedPass}(L_f)=\mathbb{1}[V_f\ge0.80]$ 을 사용합니다. 여기서 $L_f$ 는 생성된 POU, $V_f$ 는 요구사항에서 파생된 속성 중 model check로 verified satisfied가 된 비율이며, $V_f$ 가 0.80 이상이면 pass이고 117개 중 94개 속성이 만족되어 $V_f=94/117≈0.803$ 이면 기준을 넘습니다. 미지원 구성, 번역 실패, timeout으로 결론이 나지 않은 속성은 실패로 세므로 모델의 낙관적 판단이 점수에 직접 반영되지 않습니다.

방법론

SemaPLC의 입력은 자연어 control requirement $R$ 과 context $X$ 입니다. Function track에서는 $X$ 가 local POU interface이고 project-context track에서는 기존 PLC project이며, Ground 단계가 project structure와 관련 module을 찾아 변수, 타입, function block, build convention을 정리한 grounded context를 만듭니다. 그 다음 Generate가 $R$ 과 grounded context로 logic $L$ 을 만들고, 내부 skill library는 IEC 61131-3 semantics, function-block signature, compiler pitfall, verification 순서를 제공하지만 benchmark 답안이나 task-specific property는 포함하지 않습니다.

검증 과정은 specification audit, compilation, live runtime validation 세 종류의 check를 외부 도구로 실행하는 구조입니다. Specification audit는 named device, signal, published variable, threshold, boundary condition, interlock, mutual exclusion, priority, scan-cycle state semantics를 clause 단위로 검사하고, compilation은 syntax, type, symbol, interface와 integrated build를 확인하며 source line과 error category를 반환합니다. Runtime validation은 구현을 build하고 deploy한 뒤 runtime을 초기화하고 scenario input을 주입해 외부 변수를 sampling하며, requirement에서 파생된 assertion 또는 숨겨진 기준 프로그램의 golden trace와 관측 trace를 비교합니다.

검사 실패가 남아 있으면 SemaPLC는 diagnostic을 이용해 Repair를 수행하고 다시 검증합니다. 각 check에는 최대 $r=2$ 회의 repair round가 있으며, 후보가 수정되면 모든 검증 결과를 비우고 exact bytes에 대해 전체 check를 재실행합니다. completion은 모든 필수 check가 logged external verdict로 기준을 만족할 때만 발생하고, retry가 소진되거나 interaction budget이 끝나면 failure가 반환됩니다.

Project-context track의 점수는 integrated compilation $C(P')\in\{0,1\}$ , static behavior $S(P',R_p)\in[0,100]$ , dynamic behavior $D(P',\mathcal{T})\in[0,100]$ 으로 나뉩니다. Integrated compilation은 기존 project와 새 logic을 결합한 프로그램 $P'=P\oplus L_p$ 의 RuSTy build 성공 여부이며, static behavior는 실행 없이 assertion oracle의 satisfied 비율을 계산합니다. Dynamic behavior는 최대 6개 시나리오에서 후보와 기준 프로그램의 출력 port trace를 비교해 scenario별 일치 비율을 평균내며, build, deployment, timeout, trace 누락은 해당 점수를 0으로 처리합니다.

주요 결과

117개 independent-POU task에서 SemaPLC는 7개 backbone model 모두에서 가장 높은 strict verified pass rate를 기록했으며 평균은 72.6%였습니다. 가장 강한 baseline인 Agents4PLC의 평균 63.9%보다 8.8포인트 높았고, GPT-5.5에서도 SemaPLC가 82.1%로 Agents4PLC의 78.6%와 AutoPLC의 79.5%를 앞섰습니다. 같은 backbone에서 harness를 제거한 bare 설정과 비교하면 모든 모델이 8.5에서 33.3포인트 상승했고, 평균 compile rate도 85.5%에서 99.2%로 높아졌습니다.

65개 project-context task에서는 SemaPLC의 integrated compilation 평균이 89.4%로 baseline의 58.7에서 81.5% 범위를 상회했습니다. Static behavior 평균은 81.6으로 가장 높았고 7개 모델 중 5개에서 선두였지만, 가장 큰 차이는 live runtime에서 나타났습니다. Dynamic behavior 평균은 52.2로 baseline 최고값 31.4보다 높았으며, 모든 모델에서 SemaPLC가 1위를 기록했습니다.

Coking-refinery plant의 Section 8 사례에서 요구사항은 FT-701의 유량이 50 kg/hr 미만이면 SlaveSP를 500으로, transmitter fault이면 2500으로 설정하도록 했습니다. Agents4PLC는 컴파일에는 성공했지만 fault 조건에서 먼저 쓴 2500을 low-flow 조건의 500이 덮어썼고, SemaPLC의 중간 후보도 하나의 정적 수동 출력값만 사용해 low-flow 입력에서 2500을 관측했습니다. SemaPLC는 live runtime에서 500 기대값과 2500 관측값의 불일치를 얻은 뒤 원인별 출력 선택으로 수정했고, 재검증에서 low-flow 500과 fault 2500을 모두 확인했습니다.

DeepSeek-V4-Flash에 대한 누적 ablation에서는 generate only의 dynamic score가 23.1이었고 specification, compilation, runtime check를 차례로 추가하자 30.3, 43.7, 54.1로 상승했습니다. Compilation check의 단일 증가폭은 13.4포인트였으며, runtime check를 추가했을 때 10.4포인트가 더 올랐습니다. 평균 interaction cost는 34k tokens와 8.9 requests에서 full harness의 129k tokens와 47.8 requests로 증가해, 실행 신뢰성 향상이 추가 model interaction과 build, deploy, execute 비용을 요구한다는 점도 확인됐습니다.

Formal pipeline에서는 timer가 포함된 32개 program의 174개 property가 모두 inconclusive였고, timer가 없는 program의 conclusive 비율은 75.7%, REAL이 포함된 program은 87.0%였습니다. 이 결과는 scan cycle을 가로지르는 stateful timing construct가 해당 formal pipeline에서 충분히 판정되지 않음을 뜻하며, runtime validation이 timer와 reset 동작을 직접 확인해야 하는 이유가 됩니다. 논문은 unseen condition에서의 동작은 측정하지 않았고, 가장 강한 model에서 SemaPLC의 우위가 좁아진다고 명시했습니다.

기술 상세

Harness의 agent core는 generic event-driven tool-use core이며 PLC-specific 기능은 shared PLC MCP tool layer로 분리됩니다. 이 tool layer는 syntax checking, compilation, deployment, runtime status와 logs, live variable reading and forcing, trace sampling, scripted behavior checks를 제공하고 동일 기능을 command-line interface로도 노출합니다. 따라서 모델은 자연어 출력만 반환하는 대신 project를 조회하고 코드를 편집한 뒤 실제 PLC 환경의 결과를 다음 결정에 사용합니다.

Project grounding은 전체 plant를 새로 합성하지 않고 기존 project의 bounded scope 안에서 관련 module을 찾는 방식입니다. Agent는 established variable과 function block을 재사용하고 기존 interface를 재정의하지 않으며, rules file과 curated wiki에서 scan-cycle semantics, function-block signature, control pattern, compiler pitfall을 가져옵니다. 이 자료는 generic IEC 61131-3와 verifier semantics를 담고 benchmark answer나 task-specific property는 담지 않습니다.

Runtime validation은 build, deploy, initialize, input injection, external-variable sampling, trace comparison 순으로 실행됩니다. SemaPLC는 자체 평가용 scenario를 task specification에서 파생하고, 실제 점수에 쓰는 scenario와 golden trace는 숨겨진 reference에서 별도로 만들므로 scoring artifact를 generation 단계에 노출하지 않습니다. Sampling으로 모든 scan cycle을 기록하지 못하는 transient event는 persistent assertion으로 검사하고, flat trace는 wiring, 변화하지만 틀린 trace는 block logic, 늦은 transition은 timer나 edge detector를 우선적인 repair 대상으로 삼습니다.

Dynamic score는 65개 task와 최대 6개 scenario의 output port trace를 기준 프로그램과 비교해 계산합니다. Boolean과 numeric 출력은 동일 scenario에서 정확히 비교하며 scenario별 core output port 일치 비율을 평균내어 $D(P',\mathcal{T})$ 를 얻습니다. 예를 들어 두 scenario에서 각각 4개 port 중 3개와 4개가 일치하면 task의 해당 평균은 $(75+100)/2=87.5$ 가 되며, compilation failure나 missing trace가 있으면 실행하지 못한 task는 0점입니다.

Verification gate의 세 가지 불변 조건은 bounded retries, edit invalidation, earned claims입니다. 각 check의 retry는 2회로 제한되고 수정이 발생하면 이전 verdict를 모두 폐기하며, machine-readable sentinel이 tool-call log와 교차 확인되지 않으면 pass가 아니라 unchecked로 처리합니다. Function track에서는 SemaPLC가 72.6% 평균을 냈고 project track에서는 integrated compilation 89.4%, static behavior 81.6%, dynamic behavior 52.2를 기록했지만, project track의 requests는 Agents4PLC의 6.9보다 많은 34.1 per task였습니다.

한계점

Dynamic scoring은 숨겨진 reference에서 파생한 제한된 scenario set만 실행하므로 평가에 포함되지 않은 조건에서의 제어 동작은 측정하지 않습니다. 또한 가장 강한 model에서는 SemaPLC의 우위가 좁아졌고, runtime validation을 포함한 full harness는 project track에서 task당 평균 34.1 requests와 129k tokens를 사용했습니다.

실무 활용

SemaPLC는 기존 PLC project의 모듈과 인터페이스를 보존하면서 Structured Text 로직을 생성하고, compilation과 live runtime 결과가 확인된 경우에만 전달하는 개발 보조 구조로 활용할 수 있습니다. 특히 timer, reset, interlock, priority처럼 코드 텍스트와 실제 scan-cycle 동작이 다를 수 있는 제어 로직에서 유효성이 높습니다.

기존 PLC project의 변수와 function block을 재사용하는 Structured Text 로직 생성
자연어 control requirement를 clause 단위로 audit하고 compiler diagnostic으로 수정
live runtime에 scenario input을 주입해 timer, reset, interlock, state transition 검증
후보 trace와 기준 golden trace를 비교하는 프로젝트 수준 regression test

코드 공개 여부: 공개

코드 저장소 보기

키워드

SemaPLC(PLC 코드 생성을 위한 검증 게이트 에이전트 하니스)PLC(프로그램 가능 논리 제어기)Project Grounding(기존 프로젝트 맥락 기반 생성)Live Runtime Validation(실행 환경 검증)Dynamic Behavior(동적 동작 평가)Structured Text(IEC 61131-3 텍스트 언어)

용어 해설

프로그램 가능 논리 제어기(Programmable Logic Controller): — 공장 생산라인, 발전소, 수처리 시설의 설비를 정해진 제어 로직에 따라 반복 실행하는 산업용 컴퓨터입니다. 입력 신호를 scan cycle마다 읽고 Structured Text 같은 IEC 61131-3 언어로 작성된 프로그램을 실행한 뒤 밸브나 모터 같은 출력 장치를 제어합니다.
프로그램 조직 단위(Program Organization Unit): — PLC 프로그램을 구성하는 함수, 함수 블록, 프로그램 단위입니다. 독립적인 POU 생성은 요구사항과 국소 인터페이스만으로 로직을 만드는 작업이지만, 실제 배포에서는 기존 프로젝트의 변수, 타입, 함수 블록과 함께 컴파일되고 실행되어야 합니다.
구조화 텍스트(Structured Text): — IEC 61131-3에서 정의한 텍스트 기반 PLC 프로그래밍 언어입니다. 변수 대입, 조건문, 함수 블록 호출을 코드로 표현할 수 있으며, SemaPLC는 기존 프로젝트의 Structured Text 로직을 수정하고 통합 빌드합니다.
모델 검사(Model Checking): — 프로그램이 요구사항에서 파생된 형식 속성을 만족하는지 상태 공간이나 논리 모델을 기준으로 판정하는 검증 방식입니다. PLC 코드에서는 지원되지 않는 구성, 번역 실패, 시간 초과가 발생하면 만족이나 위반 어느 쪽도 아닌 미결과로 처리될 수 있습니다.
기준 실행 추적(Golden Trace): — 동일한 입력 시나리오에서 기준 PLC 프로그램이 생성한 외부 출력의 시간 순서 기록입니다. 후보 프로그램을 live runtime에 배포하고 입력을 주입한 뒤 관측한 trace와 기준 trace를 비교하면 정적 코드 검사만으로 놓치는 timer, reset, 상태 전이, 출력 timing 오류를 확인할 수 있습니다.

검증 게이트로 PLC 코드 실행 신뢰성 높이기

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 기사

Semantic Triangulation을 통한 LLM 코드 환각 감소

DeepSWE 소프트웨어 엔지니어링 벤치마크

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

관련 토론

댓글

관련 기사

Semantic Triangulation을 통한 LLM 코드 환각 감소

DeepSWE 소프트웨어 엔지니어링 벤치마크