TwinSimulate + Modelica Bridge : First-class physical modeling without leaving the control diagram

If you build cyber–physical systems, you already know the pain: physical dynamics live in Modelica, controls live in block diagrams, and the “glue” is often not so seamless.

We’ve been tightening that loop inside TwinSimulate.

This post introduces Phase 1: a practical, production-minded integration that lets engineers author Modelica, compile with OpenModelica, and co-simulate with TwinSimulate control blocks—with a workflow that feels closer to “one model” than “two tools stitched together.”

At a high level, Phase 1 adds a Modelica bridge block to TwinSimulate that:

Points at a .mo model (your physical plant, thermal network, drivetrain, etc.)
Uses your machine’s OpenModelica compiler (omc) to generate an FMI co-simulation FMU

Lets you connect standard TwinSimulate control blocks (PID, discrete regulators, signal processing, scopes, etc.) around the physical model
The important design choice: TwinSimulate stays the cockpit. OpenModelica remains the authoritative Modelica toolchain, but users aren’t forced into a perpetual import/export loop for day-to-day iteration.

Why this architecture works (technical depth, without overclaiming)
FMI as the stable execution contract
Modelica compilers produce excellent executable artifacts via FMI. TwinSimulate already had a mature FMU co-simulation path—timing, stepping, variable mapping, and build integration.

Phase 1 intentionally reuses that contract rather than inventing a parallel simulation kernel on day one. That gives you:

Correctness leverage: you inherit the compiler’s generated dynamics and Jacobians (as applicable to exported FMU semantics)
Engineering leverage: one integration surface (FMI CS) to maintain, harden, and support across platforms
Release leverage: faster time-to-value because runtime risk is bounded
Compilation caching that respects engineering reality
Modelica compilation can be expensive. A naive “compile every click” UX would feel broken.

So the workflow supports incremental caching of compiled artifacts keyed on model inputs (file fingerprint, model name, compiler flags, toolchain path). Practically: fast iteration when you’re tuning control blocks and re-running simulations, without silently accumulating unbounded disk usage—cache retention and size caps keep the behavior predictable for IT and users.

Co-simulation ergonomics: where “easy” actually matters
The hard part of FMU workflows is rarely “run the FMU.” It’s:

discovering inputs/outputs
mapping parameters
aligning sample time and internal solver microsteps
keeping paths and build settings consistent across machines
Phase 1 pushes many of those concerns into guided UI flows and sensible defaults, while still exposing the knobs engineers need when models get serious.

Advantages vs the classic “export FMU and re-import” loop
1) Reduced toolchain friction
Instead of treating OpenModelica as a separate publishing step for every iteration, engineers can stay in TwinSimulate for the tight loop: tweak plant → validate → simulate with controller → plot.

2) Better team partitioning
You can still have Modelica experts work in OMEdit when they want—but integration testing becomes something controls engineers can drive without becoming OpenModelica power users.

3) Stronger story for “digital twin readiness”
Digital twins are not “ML only.” They’re often physics + controls + data. Phase 1 is a clean bridge for the physics side without forcing an unnatural modeling style inside the control tool.

Use cases that immediately benefit
Motion / mechatronics: plant dynamics in Modelica, torque/speed loops in TwinSimulate
Thermal / fluid-ish reduced models: RC networks, lumped thermal models, first-order plants, low-order surrogates
Power electronics / electrical reduced-order models (where Modelica libraries shine) paired with supervisory control
Rapid control prototyping: compare multiple plant variants quickly while keeping the controller structure stable
Customer demos: one TwinSimulate session shows “real physics + real controls” without a toolchain lecture first
What “easy” means in TwinSimulate (and what it doesn’t)
What it does well
Unified simulation session: one diagram, one run, one results story
Leverages existing strengths: scopes, logging, codegen targets, and the bridge ecosystem you already use
OpenModelica remains the compiler: you keep access to Modelica’s expressiveness and libraries ecosystem
What it is not (yet)
This is Phase 1, not Simscape parity:

It’s not claiming a fully native Modelica authoring canvas inside TwinSimulate (that’s a different class of product surface area)
Library-scale physical palettes and domain-specific connection semantics are intentionally Phase 2+ work

Phase 1 is meant to be high leverage now, while setting up a credible roadmap.

https://twinsimulate.com

Видео TwinSimulate + Modelica Bridge : First-class physical modeling without leaving the control diagram канала TwinSimulate