The problem: control design is iterative, manual, and slow
Tuning even a basic PID controller demands repeated open-loop and closed-loop testing on a detailed plant model, performed by a Control Engineer. There is no closed-form algorithm for an optimal PID — the process is inherently trial-and-error — and the effort multiplies when moving to gain-scheduled or multi-loop architectures.
LLMs seem like a natural fit for this task. An engineer can already ask "How should I tune a PI controller for 100 ms settling?" and receive a high-quality answer. The missing step is going from advice to action: letting the LLM run the simulations directly. Model Context Protocol (MCP) makes this theoretically possible by giving an LLM a structured API to any local application — including a simulator.
In practice, two obstacles make this unworkable with detailed physical models. First, Simscape and similar tools are too slow: a single transient simulation can take minutes, stalling an LLM that expects sub-second feedback. Second, closed-loop operation requires the LLM to intervene between every timestep — injecting new inputs based on previous outputs — which is computationally infeasible at real simulation rates.
ROMs as the enabling substrate
Fast enough for real-time LLM interaction, accurate enough for engineering decisions
Simthetic directly addresses these issues. For many design problems such as tuning a PI controller, a very detailed model might not be needed. We can easily tune a PI controller with a ROM (Reduced Order Model) of the original detailed physical model, and obtain correct parameters which can be used directly in the hardware.
In order to enable interaction with an LLM, the ROM needs to be both accurate enough and fast enough so that the results are meaningful and that the LLM can interact with it in real-time. We have demonstrated both in our previous white-papers on the ROM Framework and Embedded Deployment.
In those papers, we demonstrated a DCDC Buck ROM with 5× faster performance versus an already optimised DLL detailed plant model. Metrics such as RMSE, MAE, and MaxErr were evaluated when building the ROM, ensuring a good fit to the detailed physical model.
The utilised ROM enabled an open-loop simulation of 10 seconds within 15 wall-clocked seconds, including all LLM inference overheads. The closed-loop simulation extends this to around 30 wall-clocked seconds — still well within reasonable computation time for an LLM.
Architecture deep-dive: hook injection and zero-rebuild workflow
The key aspect to enable AI-in-the-loop simulation is making sure that the LLM is not actually stepping in between every simulation cycle, but rather giving it an interface to test different functions at simulation runtime. This is where Simthetic's implementation of MCP comes in — at Simthetic, we build an application which runs on your laptop containing not only the ROM but also the MCP (i.e., API) which lets any LLM interact with it.
The concept is simple: Simthetic provides a way for the LLM to inject code into the ROM execution cycle, without having to rebuild the ROM at all. A hook is a user-defined Python function injected at each ROM timestep, receiving current outputs and returning modified inputs. While testing different methods or strategies via the LLM, the built ROM never changes — it simply represents the plant model.
def hook(outputs: dict) -> dict:
# outputs: {"V_out": ..., "I_out": ..., ...}
# return: {"Duty_Cycle": ...}
...For every ROM, Simthetic provides a pre-built agent with in-depth knowledge about the MCP and ROM interaction. The user simply prompts this agent as one would normally do, except this agent knows precisely how to get data into and out of your ROM.
Our MCP implementation minimises token usage. We want the LLM to set inputs based on outputs (closed-loop), so we have implemented an approach of custom code injection directly within the ROM via the MCP. The LLM then waits for the simulation to end and receives the full data output, which it can analyse and use to propose new changes to the code for a subsequent iteration.
Case study: LLM-designed PI controller for a Buck converter
From specification to tuned gains in a single conversation
In order to demonstrate this workflow, we created a demo for a DCDC Buck converter. The plant model is built in MATLAB Simscape and exposes the following interfaces:
| Direction | Signals |
|---|---|
| Inputs | Duty_Cycle, V_in_set, R_load_set |
| Outputs | V_in, I_in, V_out, I_out |
After going through our ROM pipeline, we have a ROM which closely resembles the behaviour of the detailed Simscape model but runs much faster. We can now use our agent to interact with the ROM, making very complex requests. In this example, we prompted the LLM to tune a PI controller which manipulates the Duty_Cycle input and controls V_out, with loose performance requirements.
This was the raw prompt output from the LLM for the PI controller tuned parameters:
| Parameter | Symbol | Value | Notes |
|---|---|---|---|
| Plant DC gain | K | 23.930 V / (ΔDC) | (14.399 − 12.006) / (0.6 – 0.5) |
| Plant time constant | τ | 0.525 ms | t_settle(2%) / 4 |
| Closed-loop target TC | λ | 5.0 ms | IMC design choice |
| Proportional gain | Kp | 0.004389 | τ / (K · λ) |
| Integral gain | Ki | 8.3578 s⁻¹ | 1 / (K · λ) |
| Per-step integral gain | Ki·dt | 0.0004179 | Ki × 50 µs |
| Nominal duty cycle | DC_nom | 0.50 | Operating point for identification |
| Nominal output voltage | V_out_nom | 12.006 V | At DC = 0.50, Vin = 24 V, R = 5 Ω |
| Duty cycle limits | DC_min / DC_max | 0.2 / 0.8 | Saturation + anti-windup bounds |
| ROM timestep | dt | 50 µs | Must match control loop rate |
| Expected CL settling | t_settle | ~20 ms | 4 · λ, 2% band |
The LLM autonomously ran 7 simulations with different control parameters in open-loop, and was able to fully characterise the ROM system to tune a PI controller within 5 minutes. All meaningful outputs are saved in a local folder so you can verify what was done by the LLM. We then prompted the LLM to "run a dynamic closed-loop test with that tuned controller, with a target of 13.0 V at the V_out output, while varying V_in from 20 to 40 V":
Benchmarks: accuracy vs. Simscape reference
Finally, all that's left is to verify if the PI controller is actually working in Simscape. It could be that the ROM and LLM have completely hallucinated the results. So we go back to Simscape and to our detailed physical model, and inject this exact PI controller into it:
To the naked eye, there is no apparent difference between the ROM V_out signal and the Simscape signal using the LLM-generated controller. The error is dominated by the initial condition (IC) transient. Once the ROM catches up with the unset initial condition, the performance is sound. The behaviour of the controller is most definitely validated — V_out is kept well controlled at 13.0 V, showing great steady-state performance. This would be a great baseline to move forward with real hardware or HIL tests.
| Metric | Value | Description |
|---|---|---|
| Post-settle RMSE | 149 mV | 1.1% of 13 V setpoint |
| Post-settle MaxErr | 1156 mV | One transient bump after settle, while ROM catches up to unset IC |
| Steady-state error | −0.16 mV | Essentially perfect |
| Full-trace RMSE | 1148 mV | Dominated by IC mismatch at startup |
Implications: what changes when simulation becomes conversational
Interacting with a model via LLM prompts makes it trivial to create complex use cases. We no longer need to manually set up input test vectors — we can simply prompt "run a simulation with a sine wave of 100 Hz at the Vin_set input". This alone would be a huge time-saver, but Simthetic takes it a step further. By allowing the LLM to interact with the ROM in a deeper way, we are able to run closed-loop simulations, enabling much more complex prompts such as optimisation or analysis of phenomena.
Failure modes and limitations
One limitation is clearly initial condition setting and transient behaviour. Without exposing a ROM input where we can explicitly set initial conditions, the ROM will take some time before converging to the detailed model's solution. Very fast transients in general are not well replicated by the ROM, but this is to be expected from a simplified model. In general, the results are more than enough for a vast set of applications, but one should be careful when using a ROM for very fast transient phenomena.
One must also be careful about any LLM-generated code which gets injected into the ROM. In this case, we formally validated the logic and performance of the PI controller, but it could be that the PI controller generated by the LLM has logical errors — which would undermine the engineer's debugging activity by spending time fine-tuning PI parameters to improve performance, while the underlying issue was just basic PI controller logic.
Closed-loop simulations, even with an optimised hook strategy as presented, can still significantly impair the performance of the ROM. By making the ROM pause at every step to evaluate a custom function before setting its inputs, we are potentially slowing down the ROM significantly — depending on the complexity of the injected custom code.
Conclusion
In practice, Simthetic has developed an AI engineering simulation assistant tool, with natural language as its interface, opening the door to incredible gains — particularly in prototyping efficiency. The hook mechanism is entirely agnostic to the physical domain.
We have demonstrated that, with a 5-minute closed-loop workflow via an LLM, it is possible to generate a tuned PI controller validated against the detailed Simscape model, achieving a post-settling RMSE of 149 mV (1.1% of the 13 V setpoint). Compared to today, where 5 minutes would likely not even be enough to run the detailed physical model due to its computational complexity.
The same workflow applies to a thermal management system (LLM tunes a cooling fan PID), a motor drive (LLM tunes field-oriented control gains), or a battery BMS (LLM optimises charge profiles). The only requirement is a Simthetic ROM — which any physical model can produce. Reach out to us to see a live demonstration of how Simthetic can accelerate your simulation pipelines today.