For systems integration, test, and software engineering teams

Start integration testing before the hardware is ready.

RapidHMI turns an Interface Control Document (ICD) into a working mock Human Machine Interface (HMI). Configure an interactive representation of the target interface and begin integration testing before the physical hardware or production HMI is available.

  • Start integration before hardware is available
  • Catch mapping faults early, while they're cheap to fix
  • Reuse one platform across projects
Request early access See how it works

Early-stage prototype under active development. Binary protocols are the initial focus, with support for JavaScript Object Notation (JSON), Data Distribution Service (DDS), and Controller Area Network (CAN) planned.

"We're still waiting on the real HMI."

"We need to test before the hardware arrives."

"The ICD says one thing, the system sends another."

"We keep building the same throwaway tools."

The problem

Integration testing starts too late.

On large programs, the parts of a system are rarely ready at the same time. Teams wait for shared hardware, the production HMI, or access to a lab. By the time everything comes together, mapping and configuration problems are expensive to find and slow to fix.

Hardware is a bottleneck

Test rigs and labs are costly, shared, and hard to book. Work stops while teams wait for access.

Implementation drifts from the ICD

What the Interface Control Document (ICD) specifies and what the system actually sends often differ. That gap usually surfaces late.

The same throwaway tools

Engineers rebuild one-off test scripts for every project instead of reusing one repeatable setup.

Slow debugging

Reproducing a problem can need several teams in the room at once. Every cycle takes longer than it should.

What it replaces

You've probably built this tool before, more than once.

Most teams already solve this problem on every project. The work usually falls to one or two engineers, gets written under delivery pressure, and is rebuilt from scratch the next time round. RapidHMI is meant to take the place of that recurring effort.

Temporary Python scripts

Quick utilities to parse a feed or print decoded fields, written for one task and rarely documented.

Throwaway Qt applications

Small desktop apps that show a handful of values, maintained by whoever happens to be free.

Custom protocol viewers

One-off viewers for a specific message format that don't survive past the program they were built for.

One-off UDP listeners

Scripts that open a socket, dump packets to the console, and get deleted once the task is done.

Spreadsheet field maps

Excel sheets mapping bytes to fields and units, kept in step with the real system by hand.

Internal test harnesses

Bespoke rigs to inject messages, rebuilt each time because the last one was too project-specific to reuse.

None of these are the wrong call in the moment. The cost is that the same work is repeated on the next program, and the next. RapidHMI aims to replace that cycle with one reusable platform: the same load, validate, run workflow on every project, instead of a fresh throwaway utility each time.

How it works

Configure once. Validate. Run.

RapidHMI is driven by a project, with much of its definition derived from an Interface Control Document (ICD). The project defines how data is received, interpreted and connected to an interactive mock Human Machine Interface (HMI). Validate the project, then run it against live or simulated systems to exercise both incoming and outgoing communication.

An Interface Control Document (ICD) defines a RapidHMI project containing receivers, schemas, rule sets, and bindings. The validated project runs as an interactive mock HMI with gauges, status LEDs, a switch, a dial, and a button. Incoming protocol messages update the widgets, and operating the widgets sends protocol messages back to the connected system.
From an ICD to a running, interactive mock HMI, with protocol data flowing both ways.

The workflow, step by step

  1. 1Create a RapidHMI project
  2. 2Configure data sources
  3. 3Define schemas
  4. 4Configure rule sets
  5. 5Create bindings
  6. 6Validate the project
  7. 7Run the mock HMI
  8. 8Send & receive live data

Built from your ICD

Define the interface once. Receivers define where data comes from, schemas describe message layouts, rule sets decode protocol data, and bindings connect decoded values to the mock HMI. Much of this comes straight from the Interface Control Document (ICD).

An interactive mock interface

Build an interactive mock interface using switches, indicators, gauges, dials, buttons, and displays that behave like the target system. It provides an interactive representation of the target interface for integration, testing and verification.

Two-way communication

Incoming protocol messages update the widgets in real time. Operating with widgets such as switches and buttons can generate protocol messages back to connected systems, allowing both input and output paths to be exercised.

What it does today

Built for engineers, focused on the basics first.

This is an early prototype. The current focus is binary protocols and a clear load, validate, run workflow that teams can rely on. We would rather do that part well than claim more than the tool does.

Project-based setup

Keep a project's data sources, message formats, and mappings together in one file you can version and reuse.

Load, validate, run

A simple workflow with clear stages, so it is obvious what is being checked and what is being executed.

Configuration checks

Catch broken references, duplicates, and format problems before runtime, with clear messages.

Configure receivers

Configure where protocol data enters the project.

Message mapping

Turn raw bytes into named, readable values using the message format you define.

Live value monitoring

Watch the mock HMI respond to live or simulated data.

Inject test data

Feed crafted messages into the running mock HMI to test specific cases on demand.

Validation before run

An invalid project is stopped before it starts, so you do not chase faults that the configuration could have caught.

Why it matters

The case for adopting it.

RapidHMI is being designed around the real cost of late integration. These are the recurring costs it aims to reduce, the reasons a team would choose it over rebuilding tooling again.

Less waiting on shared hardware

Move integration work off shared rigs and expensive labs onto a desktop, so progress doesn't stall waiting for a slot.

Less engineering effort

Describe the data once and reuse it, instead of writing fresh code for every interface on every project.

Lower integration risk

Find mapping and configuration faults early, when they are cheap to fix, not at formal integration.

Less repeated debugging

Reproduce and inspect a problem from one place, without pulling several teams into the lab for every cycle.

Less throwaway tooling

Replace one-off scripts with a setup the whole team can version, share, and carry to the next project.

Lower cost per cycle

Cut the time and money spent re-running integration each time a definition or mapping changes.

Why not build it yourself?

You could build this in-house. Most teams already have.

The question isn't whether your engineers can write another viewer or test harness. Clearly they can. It's whether it's worth rebuilding the same tool, program after program, instead of investing once in something that carries across them.

Internal one-off tooling
  • Rebuilt or adapted for each new program
  • Owned by one engineer; knowledge leaves when they do
  • Undocumented and rarely tested
  • Tied to a single protocol or project
  • Maintenance competes with delivery work
  • Hard to hand over or reuse across teams
RapidHMI as a platform
  • One workflow that carries across projects
  • Configuration lives in version control, not in someone's head
  • Validation built into the workflow
  • Designed to support more protocols over time
  • Maintained as a shared platform, not a side task
  • Reusable across teams and programs

To be clear: RapidHMI is early, and for some jobs a quick script will always be the right answer. The point isn't that internal tooling is wrong. It's that the same problem recurs on every integration program, and a reusable platform removes the repeated cost of solving it from scratch.

Who it's for

Teams that carry integration risk.

RapidHMI is being built for the people who feel late integration first, on large programs in regulated and safety-critical industries.

  • Systems integration engineers
  • Test & verification engineers
  • Software engineers
  • Technical leads
  • Engineering managers
  • Simulation teams
  • HMI developers

Common across defence, aerospace, automotive, mining, and industrial automation

Programs span years Hardware arrives late Many teams, one system Strict interface documents Expensive lab and rig time High cost of late faults Repeatable testing required Long integration phases
The longer-term vision

A mock HMI is the starting point, not the limit.

#TODO Binary protocols are the initial focus, with support for JavaScript Object Notation (JSON), Data Distribution Service (DDS), and Controller Area Network (CAN) planned.

Now

Binary protocols

Load a project, validate it, run the mock HMI, and interact with it.

Next

JSON messages

Support for JavaScript Object Notation (JSON), a common text-based message format.

Later

DDS and CAN

Data Distribution Service (DDS) and Controller Area Network (CAN), to cover more integration environments.

Exploring

Record, replay, design, test

Record and replay captured sessions, protocol replay against the mock HMI, a visual HMI designer, and automated testing: the full integration workflow, not just live monitoring.

Each step reuses the same core, so the platform grows by extension rather than by bolting on unrelated features.

Key terms

Terms used on this page.

Plain definitions for the terminology above, for anyone newer to integration work.

Human Machine Interface (HMI)
The controls and displays people use to interact with a system. An HMI may include switches, buttons, indicators, gauges, dials and displays.
Mock HMI
An interactive representation of the target interface used for integration, testing, and verification before the production HMI or hardware is available.
Interface Control Document (ICD)
The document that defines how two systems exchange data: the message formats, fields, and units.
Protocol
The agreed format and rules for how data is sent between systems, for example binary, JSON, DDS, or CAN.
Data Distribution Service (DDS)
A publish-subscribe standard for sharing real-time data between distributed systems.
Controller Area Network (CAN)
A messaging bus widely used in vehicles and industrial equipment to connect controllers and sensors.
Integration testing
Checking that separate parts of a system work correctly together, not just on their own.
Data source
Where RapidHMI reads incoming messages from during a test.

Interested in early access?

RapidHMI is an early-stage prototype, built around real integration problems. If your team waits for hardware, finds mapping issues late, or keeps rebuilding the same tooling, we would like to talk about a pilot.

Contact us about a pilot See how it works

No production claims. This is an honest look at where the prototype is today.