Give your ideas a working model. A temperature filter model moves slowly in perspective, showing the weighted inputs and the feedback through its memory.

Your next system starts here

Modeloop removes the distance between an algorithm, the people who shape it, and the hardware that makes it real.

Modeloop running beside a microcontroller connected for firmware deployment
Software becomes real when it reaches the board.

One vertical stack

From idea to chip.

We believe building systems people trust shouldn’t slow down engineering

Today’s workflow is deeply fragmented. Brilliant engineers spend hours acting as manual translators for syncing static diagrams, fighting glue code, and stitching fragmented tools together instead of solving real problems.

We want to close the gap between high-level architectural intent and bare-metal execution, eliminating the friction that causes behavior drift and lost momentum.

Modeloop's vision is one vertical stack where engineers ideate, design, simulate, verify and flash with minimal friction. It brings the speed of modern software engineering to safety-critical systems.

  1. 01 Ideate
  2. 02 Design
  3. 03 Simulate
  4. 04 Verify
  5. 05 Generate
  6. 06 Flash

Speed comes from removing repetition.

Today’s model-based tools force you into endless busywork. A simple logic modifications translates into ten minutes of dragging blocks, re-wiring signals and manually updating unit tests. We believe engineers should spend that time improving the system.

We turn models into executable specifications. Modeloop lets you use the fastest representation for your needs, editing graphically on the canvas or directly via text. Define behavioral scenarios, write unit tests and and let our automated test harness run them continuously across your design.

Modeloop is a unified workspace for embedded software. It replaces disjointed diagrams and manual test harnesses to speed up embedded software development.

A controller and plant connected as an executable model in Modeloop
The model is not a picture of the system. It is where the system begins.

Cloud-native collaboration

The model should be where the team meets.

Embedded systems are built by teams. Their tools should help people think together, not force them to work in turns.

Today, too much engineering happens around the model. One person edits it. Someone else reviews a screenshot. Decisions drift into chat threads, meetings, and folders full of competing versions.

We want the model itself to become the shared engineering space, immediately accessible to the people who need it.

Collaboration

People should shape the same model in real time and see who is present. Every change needs an author, a deterministic revision and visible semantic conflicts.

Make every decision traceable.

Decisions that shape the system behavior should not disappear into chat or meetings. We want them captured as requirements linked to the model, so every change has a clear purpose.

Share the model, not a copy.

Sharing a model should be as simple as sharing a link. Everyone opens the same project at the same revision, with the right access and no uncertainty over which version is current.

Cloud-native keeps teams in control.

Teams collaborate in the cloud while keeping ownership of their models and generated artifacts. They work locally, inspect history, use open files, and control access. They review decisions while the system is still taking shape.

Version control and Git

A model history you can read.

Source code earned its place in Git because engineers can inspect it, discuss it, and return to any decision. Models deserve the same clarity.

Visual engineering tools often reduce version control to binary files, noisy diffs, and fragile merges. Meaningful changes become lines no engineer can trust.

When a team cannot see how a model changed, it loses the reasoning behind the system it is responsible for.

See meaning, not file noise.

A useful diff says that a gain changed, a signal was rerouted, or a state was added. The same model must produce the same text every time.

Merge intent, never pixels.

Stable identity lets independent changes combine cleanly. A semantic conflict must stop and ask an engineer, never silently change the behavior of the system.

Git stays Git.

Models, requirements, tests, and build configuration belong under one revision. Teams keep their existing Git workflow while CI reproduces generated artifacts and evidence.

History should lead back to proof.

Every reviewed revision should run its simulations, verify its requirements, regenerate its code, and reproduce its firmware. A commit should answer what changed and whether the system remains trustworthy.

One model. One team. One history.

From first idea to running firmware, Modeloop connects the work, the people, and the proof in one engineering loop.

Build together. Prove every change. Ship from the same model.

Features

standard_library.mdl

d(t)

y(t)

r(t)

51

blocks in one

standard library

Math

18

Logic

12

Input / Output

08

Sources

04

Tensor

03

Routing

03

Lookup

02

Processing

01

Math

Σ

×

|x|

xⁿ

∫

Integrator

lim

tan

√

d/dt

Logic

(A ∧ B) ∨ C

A

B

C

∧

AND

∨

OR

Q

Sources

u(t)

SINE

1.0 Hz

∿

sin

↗

ramp

⌜

step

▮

pulse

Maps

f(x, y)

y

x

Tensor

transpose

→

3 × 4

4 × 3

supervisor.sfc
Idle entry/ count=0 during/ tick++ Active entry/ run() exit/ stop() [start] reset
formal-mapping
Formal Semantics User Model Controller synthesizes Mathematical Model x'(t) = A·x(t) + B·u(t) y(t) = C·x(t) + D·u(t)
testing.spec

UNIT TESTING

TEST CASE

step_response

INPUTS

ref_speed

120.0

load_torque

0.0

EXPECTED OUTPUT

motor_speed

120.0

TOLERANCE

motor_speed

± 0.5

motor_speed [rpm]

0

60

120

180

t = 1.84 s

0 s

1 s

2 s

3 s

4 s

ASSERTION RESULT

eventually

motor_speed = 120 ± 0.5

SIMULATION

EXECUTION TARGETS

Same specification

01

MIL

02

SIL

Generated C

Δ 0.0002

03

PIL

Cortex-M

Δ 0.0008

MAX TARGET DELTA

< 0.001

numeric parity

PlotLab — results
Signals ref F_out x_out err 12 signals t [s]

Build your algorithm using elementary blocks. Compose your diagram hierarchically through subsystems.

Model your Finite State Machine (FSM) with visual states, transitions and events

Establish range boundaries for each signal and mathematically verify that the model remains valid across the entire input space.

Write unit tests and run simulations to validate the functional correctness of your model.

Run your model and inspect every signal trace in real time

Start Designing Today

No install required. Open your browser and build your first system.

Want the native desktop app?

Join the waitlist for early desktop access

By joining, you ask us to manage your waitlist registration and referral progress under our Privacy Policy and Terms. Unrelated promotional or marketing email requires a separate opt-in.