> For the complete documentation index, see [llms.txt](https://doc.realvirtual.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.realvirtual.io/components-and-scripts/interfaces/fmi.md). # FMI / FMU (Pro) {% hint style="info" %} This interface was completely rebuilt in realvirtual **6.3.5** (Professional) on top of a new high-performance native co-simulation core. It replaces the previous, deprecated FMI integration. {% endhint %} ## Overview The FMI interface connects **FMUs (Functional Mock-up Units)** to your realvirtual simulation. FMI (Functional Mock-up Interface) is the open industry standard for exchanging simulation models, supported by more than 150 tools such as Modelica, Dymola, Simulink, Amesim and OpenModelica (see [fmi-standard.org](https://fmi-standard.org)). With the **FMU Interface** you can bring validated physics and controls models — hydraulic cylinders, electrical drives, thermal models, controllers — directly into your virtual commissioning scene. The FMU calculates its dynamics in perfect sync with the Unity physics timestep, and all FMU variables appear as ordinary realvirtual PLC signals that you connect to Drives, Behaviors and other components like signals from any other interface. The interface supports **FMI 2.0 Co-Simulation** FMUs with a Windows 64-bit binary. ## Quick Start 1. Copy your `.fmu` file into `Assets/StreamingAssets/FMU/` (create the folder if it does not exist). StreamingAssets is required so the FMU is available as a real file in built applications. 2. Add the component **realvirtual > Interfaces > FMU (FMI 2.0)** to an empty GameObject. 3. Enter the file name (e.g. `BouncingBall.fmu`) into **Fmu File**. 4. Click **⬇️ Import Signals**. All FMU inputs, outputs and tunable parameters are created as signal GameObjects under the interface — in Edit Mode, so you can wire them to your components before pressing Play. 5. Connect the signals to your scene (Drives, Behaviors, custom scripts) and press Play. The interface loads the FMU, shows 🟢 Connected, and steps the model in sync with the physics. ## Key Properties **Fmu File** (string) The `.fmu` package to load. Relative names are resolved against *Assets/StreamingAssets/FMU/*; absolute paths are used as-is. **Step Mode** (enum) How the co-simulation is advanced. **Physics Synced** (default) performs exactly one macro step per FixedUpdate with the Unity physics timestep — FMU time stays identical to the simulation time, and pause or `Time.timeScale` changes are honored automatically. **Free Running** steps the FMU on a background cycle independent of physics, e.g. for faster-than-realtime co-simulation. **Step Size** (float, seconds) In Physics Synced mode this is the internal *sub-step* resolution: the physics timestep is divided into equal sub-steps of approximately this size (values equal to or larger than the physics timestep result in exactly one step per FixedUpdate). In Free Running mode it is the fixed macro step per communication cycle. The step size is never derived from frame time — co-simulation stays deterministic. **Tolerance** (float) Solver tolerance passed to the FMU at initialization. **Allow Viewer To Fmu** (bool) If enabled, values written to the PLC input signals (from Unity, the WebViewer or MCP) are sent into the FMU before each step. If disabled, input signals are ignored. **Import Signals** (button) Creates or updates the FMU's signals in Edit Mode by reading the FMU's own `modelDescription.xml` — no manual signal mapping needed. Re-importing is safe: existing signals keep their user-set values. ## Signals Signals are named **`.`** (e.g. `BouncingBall.h`) and follow the standard realvirtual convention: | FMU variable | realvirtual signal | Direction | | ----------------------------- | ------------------------------------------ | ----------- | | Output / calculated parameter | `PLCOutputFloat` / `Int` / `Bool` / `Text` | FMU → scene | | Input / tunable parameter | `PLCInputFloat` / `Int` / `Bool` / `Text` | Scene → FMU | | Fixed parameter, local, time | *(no signal)* | internal | Input signals are initialized with the FMU's declared start values, so the model behaves exactly as designed until you change an input. Fixed (non-tunable) parameters cannot be changed after FMU initialization — this is defined by the FMI standard — and therefore get no signal. Each FMU Interface hosts exactly one FMU. To use several FMUs in one scene, add one interface per FMU. ## Common Use Cases * **Detailed component physics** – Simulate a pneumatic cylinder, hydraulic axis or electrical drive with a validated FMU model instead of approximating it in Unity. * **Controls-in-the-loop** – Run a controller model exported from Simulink or Modelica against your virtual machine. * **Plant models for virtual commissioning** – Couple domain-specific simulation models (thermal, fluid, mechanical) developed by simulation specialists into the commissioning scene. * **Live model tuning** – Tunable FMU parameters are ordinary input signals; adjust them at runtime from the Inspector, the WebViewer or MCP. ## Error Behavior The interface degrades cleanly: if the native core or the FMU file is missing, the interface simply stays **Disconnected** and logs a warning — the scene never crashes. FMU step rejections (`fmi2Discard`) and errors are reported in the Console with the FMU's own log messages. ## See Also * [Simulink Interface](/components-and-scripts/interfaces/simulink.md) — direct MathWorks Simulink co-simulation * [Custom Interfaces](/components-and-scripts/interfaces/custom-interfaces.md) — building your own interface --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://doc.realvirtual.io/components-and-scripts/interfaces/fmi.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.