산업자동화 엔지니어링을 위한 검증 가능한 Agent Harness

한국어 버전

프론티어 모델을 쓰는 개발 방식은 강력하지만, 산업자동화 엔지니어링에서는 그것만으로 충분하지 않다. 모델 성능도 중요하지만, 실제 현장 프로젝트에서는 접근성, 비용, 보안, 고객사 자산 보호, 검증 가능성이 모두 함께 중요해진다.

특히 B&R Automation Studio, IEC 61131-3 Structured Text, mappView 같은 환경에서는 LLM이 코드를 “그럴듯하게” 생성하는 것보다 더 중요한 문제가 있다.

LLM이 만든 변경이 실제 Automation Studio 프로젝트 구조 안에 안전하게 적용되고, 정적 검사와 빌드 결과로 검증되며, 실패하면 다시 고쳐질 수 있는가?

이번 글은 이 질문을 기준으로 진행한 Local Automation Studio Agent Harness 실험을 정리한 것이다.

왜 단순 코드 생성으로는 부족한가

처음 질문은 단순했다.

“Local LLM이 PLC 코드나 HMI XML을 생성할 수 있을까?”

하지만 실제로 실험해보니 핵심은 code generation 자체가 아니었다. 산업자동화 프로젝트는 하나의 ST 파일만으로 끝나지 않는다. .typ, .var, Package.pkg, Cpu.sw, HMI content XML, binding XML, eventbinding XML, library descriptor, task registration 같은 여러 surface가 함께 맞아야 한다.

그래서 모델이 한 파일의 코드를 잘 써도, 프로젝트 레벨에서 등록 관계가 틀어지면 빌드가 깨진다. 반대로 모델의 출력이 조금 부족하더라도, 정확한 source surface를 가져오고, 작은 patch를 만들고, 검증 루프를 돌릴 수 있으면 실무적으로 더 안정적인 결과를 만들 수 있다.

현재 Harness 구조

현재 실험 중인 구조는 다음 흐름에 가깝다.

source-grounded retrieval
-> widget / program profile selection
-> JSON patch packet or patch-plan
-> copied AS project fixture에만 적용
-> XML / ST / Package.pkg / Cpu.sw static checks
-> Automation Studio build or validation gate
-> build / validation error를 모델에 다시 제공
-> repair patch
-> rebuild / revalidate

여기서 중요한 원칙은 원본 Automation Studio 프로젝트를 직접 수정하지 않는 것이다. 모든 mutation은 copied sandbox fixture 안에서만 수행하고, live PLC transfer, deploy, warm start, cold start 같은 실제 장비 액션은 수행하지 않는다.

즉, 이 harness는 “AI가 PLC를 마음대로 고치는 구조”가 아니다. 오히려 반대다. AI의 출력은 항상 제한된 sandbox, patch contract, static oracle, build gate 안에서만 움직인다.

Local model, DGX resident model, Codex의 역할 분리

이번 실험에서 흥미로웠던 점은 모든 일을 하나의 큰 모델에 맡기지 않았다는 것이다. 역할을 다음처럼 나누었다.

Local PC / Qwen 계열 작은 모델
-> tool calling controller
-> harness sequence manager
-> build gate requestor

DGX Spark / resident coding model
-> source-grounded B&R code generator
-> JSON patch packet writer

Codex
-> tool executor
-> observer
-> evidence collector
-> build result verifier

B&R MCP / Automation Studio
-> compile-only build authority

작은 local model은 전체 코드를 직접 작성하려고 하지 않는다. 대신 어떤 tool을 어떤 순서로 호출할지 결정하고, build gate를 요청하는 controller 역할을 맡는다. 더 큰 resident model은 source-grounded patch generation을 담당한다. Codex는 tool executor와 evidence collector로 제한하고, 최종 판정은 Automation Studio build가 맡는다.

이 구조의 핵심은 명확하다.

모델이 최종 판정자가 아니라, build/oracle이 최종 판정자다.

B&R Automation Studio 실험 결과

실험에서는 B&R Automation Studio 6 / IEC 61131-3 Structured Text 기준으로 별도 PID benchmark program을 생성했다.

생성 범위는 다음을 포함했다.

• ST program 생성
• Global.typ structure type 추가
• Global.var global instance 추가
• Package.pkg Program object 등록
• Cpu.sw cyclic task 등록
• Automation Studio build 수행

최종 build 결과는 다음과 같았다.

Build: 0 error(s), 4 warning(s)

4개의 warning은 baseline project에도 존재하던 unused variable 계열 warning이었다. 새로 생성된 프로그램은 compile, link, build 단계에 정상적으로 포함되었다.

이 결과를 “LLM이 Automation Studio를 완전히 이해했다”라고 해석하면 안 된다. 더 정확한 해석은 다음이다.

Local LLM workflow는 source-grounded retrieval, patch contract, static validation, build/repair loop 안에 놓였을 때 B&R Automation Studio 프로젝트에 적용 가능한 code generation candidate를 만들 수 있다.

Fine-tuning보다 Harness를 먼저 고정한 이유

Fine-tuning은 분명히 매력적이다. B&R ST coding style, Package.pkg 등록 패턴, Cpu.sw task registration, .typ / .var 분리 규칙, mappView widget XML 패턴을 학습시키면 성능이 좋아질 가능성이 있다.

하지만 이번 실험에서는 fine-tuning보다 harness를 먼저 고정하는 것이 더 중요하다고 판단했다.

실패 원인이 단순히 “모델이 B&R syntax를 모른다”가 아니었기 때문이다. 실제 실패는 보통 다음 쪽에 가까웠다.

• 필요한 source surface를 정확히 못 잡음
• Package.pkg / Cpu.sw 등록 관계를 놓침
• .typ / .var scope를 잘못 나눔
• B&R ST subset에 맞지 않는 표현을 사용함
• output format contract가 깨짐
• build error를 repair prompt로 충분히 구조화하지 못함

이 상태에서 fine-tuning을 먼저 하면 모델이 일부 스타일을 더 잘 따라 할 수는 있지만, project-level consistency 문제는 그대로 남는다.

그래서 순서는 이렇게 잡았다.

1. Harness 먼저 고정
2. Retrieval / patch contract / static oracle / build loop 안정화
3. 반복 실험에서 evidence-labeled run artifact 축적
4. 그 데이터를 기반으로 fine-tuning 또는 preference tuning 검토

산업자동화 code generation에 필요한 데이터는 단순한 raw project dump가 아니다. 필요한 것은 user request, retrieved evidence, patch plan, final diff, static oracle result, build result, repair reason이 함께 묶인 검증 가능한 run artifact다.

Long Context보다 중요한 것

이번 실험에서 얻은 가장 큰 결론은 다음이다.

큰 context 모델에 전체 프로젝트를 넣는 것보다, 정확한 source surface를 retrieval하고, 작은 patch를 생성한 뒤, build/oracle로 검증하는 loop가 더 실용적이다.

128K, 256K context가 있다고 해서 전체 프로젝트를 통째로 넣는 방식이 항상 안정적인 것은 아니다. Automation Studio 프로젝트는 여러 파일과 등록 관계가 함께 맞아야 하기 때문에, 필요한 surface를 정확히 고르고 작은 변경을 만든 뒤 검증하는 방식이 더 실무적이었다.

결국 Local LLM을 산업자동화에 쓰려면 모델 하나만 바꾸면 안 된다. retrieval, tool calling, patch contract, static oracle, build feedback, serving profile, token budget, safety guardrail, evidence report가 함께 설계되어야 한다.

결론

내가 만들고 있는 것은 단순한 “PLC 코드 생성기”나 “HMI XML 생성기”가 아니다.

목표는 더 명확하다.

산업자동화 엔지니어링을 위한 검증 가능한 Agent Harness

이번 실험에서 확인한 핵심은 다음과 같다.

• Local LLM은 모든 코드를 직접 작성하지 않아도 된다.
• 작은 모델은 tool orchestration을 맡을 수 있다.
• 큰 resident model은 source-grounded generation을 맡을 수 있다.
• Harness는 patch contract와 validation gate를 맡는다.
• 최종 판정은 build/oracle이 수행해야 한다.

다음 단계는 PID program generation, ST skeleton, global type/variable, data object, IEC library, ANSI C task, OPC UA export, mappView widget generation을 각각 reusable benchmark item으로 고정하는 것이다.

결국 Local LLM의 실무적 가치는 “큰 모델 하나가 모든 코드를 작성하는 것”이 아니다. 작은 local model, 큰 resident model, deterministic tools, build authority를 조합해서 산업자동화 엔지니어링을 검증 가능한 workflow로 바꾸는 것이다.

---

English Version

Frontier models are powerful, but relying only on them is not enough for industrial automation engineering. In real engineering projects, model capability is only one part of the problem. Accessibility, cost, security, customer-specific assets, and verifiability matter just as much.

This is especially true in environments such as B&R Automation Studio, IEC 61131-3 Structured Text, and mappView. In this domain, the important question is not whether an LLM can produce plausible code.

The more important question is:

Can an LLM-generated change be safely applied to a real Automation Studio project structure, validated by static checks and build results, and repaired based on exact failure feedback?

This post summarizes my experiment with a Local Automation Studio Agent Harness around that question.

Why Simple Code Generation Is Not Enough

The first question was simple:

“Can a Local LLM generate PLC code or HMI XML?”

After several experiments, I think that was the wrong question.

Industrial automation projects are not made of a single ST file. A real Automation Studio project includes .typ, .var, Package.pkg, Cpu.sw, HMI content XML, binding XML, eventbinding XML, library descriptors, task registration, and other related surfaces.

Even if a model writes one file well, the project can still fail if registration relationships are wrong. On the other hand, even if the model output is imperfect, the workflow can become much more practical if the harness retrieves the exact source surface, creates a small patch, validates it, and repairs failures through a build feedback loop.

Current Harness Structure

The current structure is closer to this:

source-grounded retrieval
-> widget / program profile selection
-> JSON patch packet or patch-plan
-> apply only to a copied AS project fixture
-> XML / ST / Package.pkg / Cpu.sw static checks
-> Automation Studio build or validation gate
-> return build / validation errors to the model
-> repair patch
-> rebuild / revalidate

The important rule is that the original Automation Studio project is not modified directly. All mutation happens only inside a copied sandbox fixture. No live PLC transfer, deploy, warm start, or cold start is performed.

So this is not a system where AI freely changes PLC code. It is the opposite. The AI output is constrained by a sandbox, patch contract, static oracle, and build gate.

Separating the Roles

One of the most useful design choices was not assigning everything to one large model. The roles were separated:

Local PC / smaller Qwen-class model
-> tool calling controller
-> harness sequence manager
-> build gate requestor

DGX Spark / resident coding model
-> source-grounded B&R code generator
-> JSON patch packet writer

Codex
-> tool executor
-> observer
-> evidence collector
-> build result verifier

B&R MCP / Automation Studio
-> compile-only build authority

The smaller local model does not try to write all code directly. It controls which tools to call and when to request the build gate. The larger resident model handles source-grounded patch generation. Codex is constrained to execution and evidence collection. Automation Studio build remains the final authority.

The core principle is simple:

The model is not the final judge. The build/oracle is.

B&R Automation Studio Result

In this experiment, the benchmark task was to generate a separate PID program for B&R Automation Studio 6 / IEC 61131-3 Structured Text.

The generated scope included:

• ST program creation
• Global.typ structure type addition
• Global.var global instance addition
• Package.pkg Program object registration
• Cpu.sw cyclic task registration
• Automation Studio build execution

The final build result was:

Build: 0 error(s), 4 warning(s)

The 4 warnings were baseline unused-variable warnings already present in the reference project. The newly generated program was included in compile, link, and build stages successfully.

This does not mean that the LLM fully understands Automation Studio. The better interpretation is:

A Local LLM workflow can generate buildable B&R Automation Studio code candidates when it is placed inside a source-grounded retrieval, patch contract, static validation, and build/repair loop.

Harness First, Fine-Tuning Later

Fine-tuning is still interesting. It could help with B&R ST coding style, Package.pkg registration patterns, Cpu.sw task registration, .typ / .var separation rules, and mappView widget XML patterns.

But in this experiment, stabilizing the harness first seemed more important than fine-tuning first.

Most failures were not caused only by the model “not knowing B&R syntax.” The real failure modes were closer to:

• retrieving the wrong source surface
• missing Package.pkg / Cpu.sw registration relationships
• mixing .typ and .var scopes incorrectly
• using ST expressions outside the B&R-compatible subset
• breaking the output format contract
• failing to structure build errors into repair prompts

If I fine-tune first, the model may imitate some patterns better, but the project-level consistency problem remains.

So the current order is:

1. Stabilize the harness first.
2. Fix retrieval, patch contract, static oracle, and build loop.
3. Collect evidence-labeled run artifacts.
4. Use those artifacts later for fine-tuning, preference tuning, or tool-use tuning.

For industrial automation code generation, useful data is not just a raw project dump. The useful dataset should include the user request, retrieved evidence, patch plan, final diff, static oracle result, build result, and repair reason.

Long Context Is Not Enough

The biggest lesson from this work is:

A larger context window does not automatically solve project-level code generation.

Even with 128K or 256K context, simply putting the entire project into the model is not always stable. Automation Studio projects depend on multiple files and registration relationships. The more practical strategy is to retrieve the exact source surface, generate a small patch, validate it, build it, and repair with exact error feedback.

To use Local LLMs effectively in industrial automation, changing the model is not enough. Retrieval, tool calling, patch contracts, static oracles, build feedback, serving profile, token budget, safety guardrails, and evidence reports must be designed together.

Conclusion

What I am building is not just a “PLC code generator” or an “HMI XML generator.”

The goal is:

A verifiable Agent Harness for industrial automation engineering.

The main takeaway so far:

• A Local LLM does not need to write all code directly.
• A small model can orchestrate tools.
• A larger resident model can generate source-grounded patches.
• The harness can enforce patch contracts and validation gates.
• The build system should remain the final authority.

The next step is to turn each task into a reusable benchmark item: PID program generation, ST skeleton generation, global type/variable generation, data object creation, IEC library integration, ANSI C task generation, OPC UA export, and mappView widget generation.

The practical value of Local LLMs is not that one large model writes everything. It is that a small local model, a larger resident model, deterministic tools, and build authority can work together to turn industrial automation engineering into a verifiable workflow.

---

Tags: IndustrialAutomation, PLC, IEC61131-3, StructuredText, AutomationStudio, B&R, mappView, LocalLLM, AIAgent, ToolCalling, CodeGeneration, ManufacturingAI, DGXSpark, RTXSpark