CODE THAT STAYS IN SPEC
Forja
Year
2025 → present
Role
Sole engineer
Status
Primary focus
Stack
React 19 · Claude API · .NET 4.8
Forja turns requirements documents into TIA Portal projects. It also runs the other way: point it at a legacy TIA project and it extracts a spec you can read. Eight agents do the work, and everything compiles against a real TIA Portal install via Openness — or you find out why it didn't.
The symmetry is the point. Greenfield projects start as a description and end as a compiling TIA project. Legacy projects start as TIA code and end as an editable spec. Both meet in the middle at a structured machine model. The same tool that writes the next project can read the one you inherited.
The problem
PLC work eats engineering hours on tasks that look identical project to project but aren't. Translating functional descriptions into SCL. Wiring IO lists. Laying out HMI screens. Hand-auditing codebases inherited from other vendors. Every site has its own naming, its own hardware, its own safety constraints. You can't template it. You also can't avoid it.
The obvious move is to ask a chatbot to write SCL. That doesn't work. PLC code has to compile against specific hardware, follow project-specific naming, and obey standards that a general model has no particular reason to know. Forja is built for Siemens TIA Portal specifically, hooked into TIA Openness so every generated block gets compiled in the loop.
The shape of the system
FDS Builder — structured interview + fidelity review
Pac-Audit — deterministic extract + AI for inferential facts only
Derived spec — machine hierarchy (System → Subsystem → Assembly → Device)
Forge Wizard — eight-agent generation + PLCsim validation
TIA project — imported + compiled via .NET Openness bridge
Four pillars, two directions. The FDS Builder takes an instrument register and runs a structured interview with the engineer, one field at a time. A Fidelity Reviewer catches cases where the AI's take on an answer drifted from what the engineer actually said. Pac-Audit goes the other way: point it at an existing TIA project and it reverse-engineers a spec in the same shape. Anything you can compute from Openness is extracted deterministically. Only the genuinely interpretive parts — intent, fault handling, non-standard patterns — go through an AI, with evidence citations required.
Both paths produce the same derived spec: a machine hierarchy of System → Subsystem → Assembly → Device, with permissives, sequences, tags, timeouts, and fault handling in a common schema. The Forge Wizard takes that spec and runs it through the generation pipeline — hardware configuration, IO list, interface contracts, device and assembly function blocks, process sequence code, HMI screens, and the final TIA project. Every step produces a reviewable artefact, runs through PLCsim, and gets imported and compiled against a live TIA Portal instance.
The fourth pillar is free. Because Pac-Audit and the FDS Builder produce the same shape of spec, a V15 project can be extracted, edited in structured form, and regenerated onto a current TIA version without starting from scratch. The engineer picks what to port verbatim and what to let Forge re-emit. The spec is the bridge between the project you inherited and the one you want to ship.
FDS Builder
Instrument register — kicks every run off
Questionnaire and/or Matrix — either path, or both
Sequence Builder — invoked once per state
Pac-Audit
TIA Portal import — via .NET Openness C# bridge
AI investigation — interpretive facts, evidence-cited
Questionnaire — engineer fills residual gaps
Source of Truth — same schema FDS Builder produces
The hard bits
Eight agents, one pipeline
Everything Forja produces comes from eight agents. The Project Manager plans the run and delegates. The Code Architect writes SCL. The Standards Enforcer, IO Validator, and Safety Auditor each review blocks against their own rules. The Pattern Librarian watches corrections as they happen. The HMI Designer lays out WinCC screens. The HMI Tag Linker wires each element to the right PLC data block.
They run as a pipeline, not a chorus. Specialists do their job. Reviewers send findings back for a rewrite pass when they need one. When two reviewers disagree, the PM surfaces the disagreement instead of silently picking a side. Every hand-off produces an artefact the engineer can edit, rewind, or regenerate without blowing away the run.
A Conformance Reviewer is in the works. Its job is to check both directions: every requirement traces to generated code, every generated behaviour traces back to a requirement. That's the one kind of bug nothing else in the pipeline catches — code that compiles, passes every standards check, and still doesn't do what was asked.
Extracting spec from legacy without hallucinating
Pac-Audit points the same platform at an existing project instead of a blank canvas. The extraction rule is strict. Anything computable from structured Openness data goes through a deterministic extractor. Block interfaces, call graphs, state machines, cross-reference graphs — all of it, no inference. This isn't a style choice. It's the difference between a derived spec you can trust and one you can't.
Only the genuinely interpretive parts go through an AI. Intent. Fault-handling prose. Non-standard patterns an engineer used instead of the conventional one. Every AI-extracted fact carries an evidence citation (which block, which line, which comment) and a confidence flag. If Pac-Audit can't find evidence, it says so instead of inventing plausible text. The spec ships with a provenance trail for every AI claim, because a spec nobody can verify is worth nothing.
Every correction becomes a rule
Forja is supposed to get better with use. When a generation fails to compile in TIA, the error comes back through the bridge. A compile-fix agent proposes a correction. The fix is re-imported. If it holds, the diff between what was generated and what actually compiled gets classified by the Pattern Librarian and saved. Every future run starts seeded with the approved library, across every agent and every project.
Engineers also feed reference material into a shared knowledge base: Siemens manuals, internal standards, design profiles. The Project Manager reads each document and only distributes the relevant sections to the agents that need them. Safety standards go to the Safety Auditor. ISA-101 material goes to the HMI Designer. Nothing gets broadcast. Every piece of knowledge lives with the agent that uses it.
When sources disagree, a seven-level priority hierarchy picks a winner: Platform Rules → Design Profile → Correction Patterns → FB Templates → Agent Knowledge → Reference Library → Prompt Sections. Per-project overrides are available when a team needs them. The point is to encode the team's judgment: manual corrections, approved review comments, compile fixes, all carried forward into the next run.
The TIA Openness bridge
TIA Portal has no REST API. The only programmatic interface is TIA Openness, a COM-style .NET library that ships with TIA Portal. Talking to it means a .NET Framework 4.8 process running on the same Windows machine as TIA Portal itself.
The bridge is a C# console app that wraps Openness and exposes HTTP and WebSocket on port 5102. The web app posts generated SCL and hardware configuration to it. The bridge opens the TIA project, imports artefacts in the right order, triggers a compile, and streams the errors back via WebSocket. Before anything gets near real hardware, the bridge also runs PLCsim passes against the generated blocks. Supports V17 through V20. Launches on demand, shuts down when idle, so TIA Portal doesn't stay open between runs.
The result
Forja is in use on live projects. Engineers run instrument registers through the FDS Builder to produce customer-ready specs, push those specs through the Forge Wizard to get a compiling TIA project, and point Pac-Audit at inherited codebases to turn them into the same spec shape — ready to edit or regenerate onto a current TIA version. Every correction made along the way becomes a pattern in the library, ready for the next run.
The Conformance Reviewer is the next big piece. When it's in, the pipeline will verify both directions: every requirement traces to code, every behaviour traces to a requirement. That closes the last gap — code that compiles, passes every standards check, and still doesn't do what was asked.