FMU Validator¶

The FMU validator runs a Functional Mock-up Unit co-simulation on the submission and exposes the FMU's output variables as values you can write CEL rules against.

It's the right tool for accepting and gating dynamic models — controls algorithms, HVAC plant components, electric-vehicle charging logic, anything packaged as an FMU — where the question isn't "is the file structurally valid?" but "does the model behave correctly when driven with a known input profile?"

What you'll need¶

• A Validibot deployment licensed for an edition that includes the FMU validator.
• A workflow whose allowed file types include FMU (.fmu) and whatever format you use for the driver (typically JSON or YAML).
• An FMU package to test against.
• A driver definition: the inputs to feed the FMU, the simulation time range and step, and which outputs you care about.

How an FMU step works¶

When a submission reaches the step, Validibot:

1. Reads the FMU's modelDescription.xml and lists declared input and output variables. These appear as step inputs (i.<variable>) for rules and inspection.
2. Resolves the driver — combining the static driver definition on the step with any per-submission overrides — into a concrete simulation plan.
3. Dispatches the FMU + driver to an isolated FMU runtime container.
4. Captures the requested output series as step outputs (o.<variable>, typically as series you can aggregate with helpers like mean(), max(), percentile(), duration()).
5. Runs your assertions against i.*, o.*, p.*, and s.*.

Setting up an FMU step¶

1. Open the workflow editor and click Add step.
2. Pick FMU from the validator library. If it's greyed out, check that your deployment's license includes it and the workflow's allowed file types include FMU.
3. Give the step a name like "Controls behaviour check" and a short description.
4. Define the driver:
5. Simulation start time, stop time, and communication step.
6. Input variables to set, and either constant values, a tabular profile, or references to submission fields.
7. Output variables to capture for assertions.
8. (Optional) Tighten runtime guards — wall-clock timeout, memory ceiling.
9. Click Save step.
10. Add step assertions against the captured outputs.

Outputs as series¶

Many FMU outputs are time series — the value of a temperature, voltage, or set point over the simulation horizon. Validibot's CEL helpers are designed for that shape:

# Mean room temperature stays within a comfort band
mean(o.room_temp_C) >= 20.0 && mean(o.room_temp_C) <= 24.0

# 95th-percentile peak never exceeds the limit
percentile(o.peak_power_w, 0.95) <= 7500.0

# Spend no more than 100 samples outside the comfort band
duration(o.room_temp_C, v < 19.0 || v > 25.0) <= 100

# Maximum control error is small
max(o.tracking_error) < 0.5

If you'd rather assert on a single scalar, helpers like mean(), max(), min(), sum(), percentile(), and round() get you there — see the CEL Expressions page for the full list.

When to gate on inputs vs. outputs¶

Like the EnergyPlus validator, the FMU validator separates input-stage and output-stage assertions:

• Input-stage assertions run before the co-simulation. Use them to bail out fast on structurally wrong FMUs ("this FMU must declare variable room_temp_C", "FMI version must be 2.0 or 3.0").
• Output-stage assertions run on the captured series. Use them for behavioural rules.

A failed input-stage assertion saves you the simulation cost.

Tips¶

• Pin the driver in the step, not the submission. A driver baked into the workflow step is reproducible — every submission runs against the same inputs. If you let submitters supply their own driver, two submissions become hard to compare.
• Capture only the outputs you assert against. Capturing every variable is tempting but slows the run and bloats artifacts.
• Promote thresholds to signals. If your comfort band, peak limit, or tracking-error tolerance is referenced in multiple assertions, define it once as a workflow signal (s.peak_limit_w) and reference it everywhere.
• Chain a cheap structural check first. A Basic step that validates the FMU's declared inputs and outputs match what your driver expects catches obvious mismatches before the co-simulation fires up.

Where to next¶

• Data Namespaces — how i.* and o.* fit together for a multi-stage validator.
• CEL Expressions — operators and the series-friendly helpers (mean, percentile, duration).
• EnergyPlus Validator — the sibling advanced validator for building-energy simulations.