Fail on purpose, learn the workflow, then touch hardware. A laboratory’s training lead has three new test engineers and one expensive load cell they are not allowed to break. On the SMI Simulation she hands them a Simulated SMART Measuring Instrument Twin (SST) instead: realistic physics behind exactly the served interface a physical SMART instrument presents, the full certification workflow running against it, and a bench that shows the truth with its own eyes. The platform drives the SST directly; from the served side, software, and people, cannot tell the difference until they are told.
The demo's whole certification chain runs on SSTs. Sign-in runs through the identity service, the demonstration cast assumed as personas; the instance resets nightly.

The story
The rehearsal week, as a laboratory runs it. Monday: the new engineers open the applicant’s and the laboratory’s consoles against the simulated Steelyard LC-500 and walk the whole arc, application to decision, exactly as the end-to-end story tells it, because the demo certifies an SST, not a mock-up. Tuesday: the trainer boots a standalone SST beside the bench (one command, every surface open) and places loads and sweeps the chamber on the world channel while the engineers run the model-driven test program, and the class reads the bench’s dial against the served values: the API reports what it reports, the needle shows what is true. Wednesday: the deliberately drifting cell, and the verdict chain shows what failure looks like. Thursday: the outage scenario, and the monitor degrades to indeterminate, honestly, instead of inventing a verdict. Friday: the same consoles, the same workflow, pointed at the physical instrument, and nothing is new except the hardware.
What you can do today
Every act below was performed against the live services by the scripted capture apparatus before it was listed; each figure names its capture date and links the live surface.
Run the whole certification workflow against a simulated instrument. The live demo certifies the simulated LC-500 against the modelled R 60, application to decision; the rehearsal’s cast signs in through the identity service, each seat assumed as a persona.
Pair the sim bench with your own instrument. The demo’s sim bench is the pairing point for a locally booted SST: one command (the page prints it) boots an instrument side by side with your own checkout, and the world channel opens there: loads, chamber, faults, the clock. The hosted demo keeps the bench unpaired, and the page says so honestly.

Watch a simulated quarter’s surveillance. The demo’s twin console monitors the served feed: drift flags the certificate, an outage degrades verdicts to indeterminate, a served fault opens a service case.
Meet the four instruments. A strain-gauge load cell (OIML R 60; creep and thermal hysteresis), a continuous gas monitor (OIML R 144; drift classes and cross-sensitivity), a Doppler speed meter (OIML R 91; cosine error and rain fade), and an optical conveyor dimensioner (OIML R 129; sampling, reflectance, ambient-light noise), on the SMI Simulation site.
Inspect the machinery. Primmel SST, the framework (primmel/sst: the kind-agnostic runtime, the shell, the bench, the specifications), and OIML SST, the instrument library (oimlsmart/sst: the kinds, the instances, the composites), are public repositories.
How it works
Each SST presents two channels. The /twin channel is the governed projection, its schema generated from the manufacturer’s product reference package; a startup conformance check stops the instrument if the served interface drifts from the package. The /world channel is the physical world: the operator’s loads, faults, and clock. An epistemic wall separates the two: certification logic reads only the served channel, and the wall is what makes the classroom’s central lesson teachable. The twin is driven from the platform, not beside it: the platform’s gateway consumes the /twin channel through its standard connector registry, the same path a physical twin takes.
Today (SMART) and the vision (SMART+)
Today · SMART
- The whole demo rehearses on SSTs today: the LC-500 application, evaluation, and certificate all run against the twins. the demo ↗
- The sim bench pairs with a locally booted SST (the page prints the one command); the twin console monitors the demo’s simulated feed. the bench ↗
- The framework and the instrument library are public and inspectable. the library ↗
The honest questions
Does a simulation prove anything about real instruments?
It proves the workflow and the supply chain, not the physics of a specific device: the served schema is generated from the same product reference packages the platform reads, so an edit that changes the interface fails the instrument’s own startup check. What the SMI Simulation certifies is the certification machinery itself, which is exactly what training needs.
Can a simulated instrument lie?
Yes, and that is the point. The bench shows the physical scene beside the served values; the classroom’s central lesson is reading the dial against the API. The twin-certification program’s probe channel exists because served values alone are never the whole truth.
Why not train on production instruments?
Because production instruments are busy being evidence. The rehearsal space must be free to fail: drift on purpose, outage on schedule, fault injection on demand, reset in seconds. Skills are learned where failing is cheap; the SMI Simulation makes failing free.
What does a training deployment cost us?
Nothing to start: the demo rehearses the whole chain with its fictional cast, and Primmel SST and OIML SST are public repositories your own trainers can boot standalone (one command, every surface open, no platform checkout). The hosted SMI Simulation’s member entitlements are quoted on the technology page.
Where to go next
The whole cast, the whole arc, on the simulated instrument: Applicant, Issuing Authority, Test Laboratory, each seat assumed as a persona through the identity service.
The instruments, the consoles, the bench, the scenario library, and the standalone quickstart.
info@oimlsmart.org: training scenarios and classroom use are the commonest requests; the scenario library is built for that conversation.

