RapidHMI Early access
Desktop tool for integration, test and software engineers

Build a mock Human Machine Interface that talks to your system.

An HMI is the set of controls and readouts people use to operate a system. RapidHMI lets you build one visually, bind its controls to protocol fields, and run it against a real or simulated system. Data arriving updates the interface. Operating a control sends correctly encoded data back.

Not a UI mock-up. A mock interface that speaks your protocol.

Request early access See how it works

Windows desktop application, under active development.

The RapidHMI application window. A project tree lists data sources, message formats, decoding and display values. A live values panel shows an altitude readout of 12,480 feet, a heading, a mode and a link status. A diagnostics panel reports that the project validated with no errors.
One project holds the data definitions, the interface and the bindings between them.
Why not just write it

You could write the tool. You have probably written it before.

Every project seems to need a small interface: a protocol viewer, a debug panel, a UDP utility, a quick Qt or WinForms app. The interesting part takes an afternoon. The rest is the same plumbing every time.

The work involved in writing a one-off tool, compared with configuring the same thing in RapidHMI.
Writing another tool RapidHMI
Read the interface definition Read the interface definition
Write parsing and decoding Define the message schema
Write networking code Configure the connection
Build a Python, Qt, WinForms or WPF interface Design the interface visually
Wire decoded values to widgets Bind controls to fields
Write encoding for outgoing messages Configure what a control sends
Compile, debug, repeat Validate and run
Maintain another application Reuse the project next time

The first row is deliberately identical. RapidHMI does not replace your understanding of the system. It replaces the code you write around it.

How it works

Define, design, bind, connect.

Four steps, all of them visual. No code, no build step.

  1. 1

    Define

    Describe the binary messages your system exchanges: the fields, their types and where they sit in the data. Then point it at a UDP or TCP connection.

  2. 2

    Design

    Lay out the interface with the controls you need. Gauges, indicators, switches, dials, buttons and readouts.

  3. 3

    Bind

    Point a control at a field. A gauge reads one value, a switch writes another. This is configuration, not binding code.

  4. 4

    Connect

    Run it against the real system or a simulator. Live data drives the interface, and what you do on screen goes back out.

Both directions

Data comes in. Interactions go back out.

This is the part that separates RapidHMI from a packet viewer or a screen designer. The mock interface is on the wire, not next to it.

Incoming

  1. System sends a message
  2. RapidHMI decodes the fields
  3. Bound controls update

A field moves a gauge. A state bit lights an indicator. A counter fills a readout.

Outgoing

  1. You operate a control
  2. RapidHMI encodes the message
  3. System receives it

Flip a switch, turn a dial, press a button. The correctly encoded message goes out.

An interface definition such as an ICD is read by the engineer, who configures a RapidHMI project made up of a connection, message schemas, controls and bindings. The project is validated and run as a mock HMI containing a gauge, a numeric readout, status indicators, a switch, a dial, a button and a progress bar. Incoming protocol data from the connected system updates the controls, and operating a control sends encoded protocol data back. The connected system may be real or simulated.
You read the interface definition and configure the project. RapidHMI does not import an ICD and produce a finished interface for you.
What it gives you

The parts you would otherwise build.

Binary message schemas

Describe a message field by field: name, type, position and size. The schema does the decoding on the way in and the encoding on the way out.

Controls that behave

Gauges, indicators, switches, dials, buttons and numeric readouts that respond to values and produce them.

Validation before you run

Broken references, missing fields and configuration mistakes are reported up front instead of turning into runtime puzzles.

A project you can keep

Everything is configuration in one project, so you can put it in version control, hand it over, and adapt it for the next interface.

When it is useful

Anywhere you need an interface for a while.

Before the hardware exists
Stand in for a system or a production HMI that has not arrived yet, and start integration work early.
Debugging a live link
Watch decoded fields change while the system runs, and send messages back by hand to see how it responds.
Building the other side
Developing one subsystem? Use a mock HMI as its counterpart so you can exercise your side properly.
Simulation and rigs
Drive the interface from a simulator rather than the real system, or use it to drive a rig yourself.
Instead of a throwaway utility
Replace the packet dump script and the one-off viewer with a project that survives the program it was built for.
A convenient engineering panel
When you just want somewhere to see the values and poke the system, without the production HMI in the way.

The same problem turns up in defence, aerospace, automotive, mining and industrial automation: long programs, several teams, and interfaces that need exercising before everything is in one room.

Where it is today

Early access

RapidHMI is under active development and heading toward a first release. The focus is binary message formats carried over UDP and TCP. CAN fits the same kind of system communication and is a natural step later, but it is not supported today.

Define the data. Build the mock interface. Connect it. Interact with the system.

Request early access

No public download yet. Get in touch and we will show you where it stands.