Module simulator 

SimulatorDriver: an in-process FOPDT (first-order-plus-dead-time) process model, served through the Driver trait, for fully automated E2E tests (no Windows, no Kepware, no external process) and demo mode.

Ported from Model/ProcessModelOPC.py, the Python model the legacy app’s hidden OPCClass.Python test path shells out to (see AGENTS.md’s behavior-spec notes). This module splits into three independent pieces:

• FopdtProcess: the process itself – pure state advanced one tick at a time, with no Driver/async awareness at all.
• VirtualPid: a standalone position-form PID controller, for closed-loop validation (e.g. “do the constants a completed MRFT run just calculated actually control this process well?”) and demos. Not wired into SimulatorDriver – the open-loop MRFT relay test drives the MV itself, so nothing here needs to close the loop automatically.
• SimulatorDriver: the thin Driver shell wrapping one FopdtProcess.

Structs

FopdtConfig

Configuration for a FopdtProcess: the classic three parameters process control literature uses to characterize a first-order-plus-dead-time (FOPDT) process, plus the tick cadence and measurement noise needed to turn the continuous model into a discrete one a Driver can serve one sample at a time.

FopdtProcess

A first-order-plus-dead-time process model, advanced one tick at a time.

SimulatorDriver

The Driver implementation for CI E2E tests and demo mode: an in-process FopdtProcess served through exactly two tags – a PV tag (reading it advances the simulated clock by one tick) and an MV tag (reading it reports the last-written value without advancing anything; writing it records a new controller output). Any other tag is DriverError::InvalidTagValue; Driver::browse is always DriverError::Unsupported, per that method’s own documented convention for drivers with no real tag tree.

VirtualPid

A standalone position-form PID controller, for closed-loop validation and demos (e.g. “do the constants a completed MRFT run just calculated actually control this process well?”). Deliberately not wired into SimulatorDriver/Driver at all: the Driver trait models open-loop tag I/O, and during an actual MRFT relay test the engine itself (bhtune_core::mrft::MrftEngine) drives the MV – nothing needs to close the loop automatically for that. This exists for whatever, later, wants to run this process in automatic mode instead (e.g. simulating a completed tune’s results before trusting them against a real DCS).

VirtualPidConfig

Configuration for a VirtualPid: a standard textbook position-form PID controller – proportional and integral on error, derivative on the measurement rather than the error (to avoid “derivative kick” on a setpoint change) – with output clamping and anti-reset-windup.