A lightweight router in front of isolated runtimes
2ot keeps the execution surface small while routing work from scripts and LLM harnesses to the compiler, protocol services and vendor-specific executables that own each operation.
2ot.exe is the stable gateway
The root executable contains routing and schema logic rather than embedding every compiler, vendor SDK and automation host into one process. A configured workspace lets common commands infer the active vendor; explicit tia, codesys and twincatroutes remain available for vendor-specific operations.
Compiler island
The compiler stays independent from vendor host packages. Parsing, semantic analysis, diagnostics, lowering and target emission live on the compiler side; vendor transports and IDE automation live outside that boundary. This keeps vendor SDK constraints from leaking through the entire dependency graph.
How common commands route
The calling harness sees a stable command even when the implementation belongs to a separate leaf executable.
| Surface | Owner | Why it is separate |
|---|---|---|
| 2ot transpile | compiler | Analysis, lowering and target emission stay independent of vendor automation. |
| 2ot check --fast | compiler | Fast diagnostics avoid the startup cost of vendor software. |
| 2ot lsp | LSP service | Protocol transport stays separate while reusing compiler analysis. |
| 2ot mcp | MCP service | Agent transport consumes schema-described tools instead of embedding every implementation. |
| 2ot build / pull / push | configured vendor runtime | Workspace metadata routes operations to TIA, CODESYS or TwinCAT when vendor access is required. |
Fast diagnostics take the short path
2ot check --fast routes directly to compiler analysis and deliberately avoids vendor startup. That is the low-latency diagnostic path; an authoritative vendor build can still be invoked later through the configured runtime.
The command surface is self-describing
The gateway can enumerate installed routes and normalize schema-emitting commands into a machine-readable MCP surface. Automation scripts and LLM harnesses can therefore share the same routing contract instead of drifting into separate APIs.
Siemens stays behind a dedicated integration boundary
TIA Portal Openness calls, process control, workspace synchronization and local IPC belong to the Siemens runtime rather than the compiler core. The same separation applies to local Siemens API knowledge-graph tooling: generated vendor-derived metadata stays on the licensed developer machine instead of becoming part of the public website.
See the architecture in context
A guided walkthrough can show how the gateway, compiler and vendor runtimes fit underneath the engineering workflow or harness you already prefer.