[RIDDEN]

A control unit whose firmware is generated for your vehicle

NewVCU runs the vehicle's traction, safety and communication. You do not write it in C: you describe it in VCU Forge (vehicle, motor, battery, inverter, features), and Forge generates the firmware, builds it, checks it and flashes it. A new motor or inverter is added as a catalogue entry.

Talk about your vehicleSee the pilot
VCU Forge
The Vehicle page: the test motorcycle's motor, battery and inverter, the limits that bound every setting.
The Vehicle page: the test motorcycle's motor, battery and inverter, the limits that bound every setting.

Two controller tiers

NewVCU

[RIDDEN]

The test motorcycle's controller, riding since September 2026.

Processor
ARM Cortex-M4F, 168 MHz
CAN buses
2, at 500 kbit/s
Inputs
Analogue, digital, wheel speed
Sensors
Inertial unit, GPS
Data
SD card logging, MoTeC i2 export
Tuning
Bluetooth and from the display

NewVCU higher tier

[SOFTWARE-TESTED]

For racing: replacing a motorsport ECU on an electric car with three CAN buses. The firmware builds; it has not yet run on a board.

Processor
ARM Cortex-M7, 550 MHz
CAN buses
3 (FDCAN)
Inputs
Up to 18 analogue channels
Logic
Ported from Simulink, compared step by step with the original code

Dedicated board, in design

[IN DESIGN]

A 4-layer 100 x 80 mm board: sealed 35-way automotive connector, two CAN buses, 12 V supply, inertial unit, microSD, low-side power outputs, USB-C. The render shows the design; the board is not manufactured yet.

Inverters

  • VESC controllers, current-commanded over CAN [RIDDEN]
  • OpenInverter, commanded over CAN [SOFTWARE-TESTED]
  • Any inverter described by a DBC profile [SOFTWARE-TESTED]
3D render of the controller's circuit board

From the datasheet to a vehicle that rides

  1. Describe the vehicle
  2. Tick the features
  3. Let Forge wire it
  4. Tune in real units
  5. Generate and flash
  6. Verify on a PC

Describe the vehicle

Type, motors, battery and inverter. The datasheet's limits bound every setting.

Tick the features

Drive modes, regen, traction control, limiter, logging: a catalogue of features to tick.

Let Forge wire it

Pins assigned automatically, without conflicts. CAN messages described as data, never hard-coded.

Tune in real units

Maps and thresholds in km/h, amps and degrees, edited with the mouse, saved apart from the validated platform.

Generate and flash

Project generated, built with no errors or warnings, flashed over USB, without opening the chip vendor's tools.

Verify on a PC

Every check runs from one button, and the control loop is replayed scenario by scenario before it touches the vehicle.

VCU Forge
The CAN page: every message the controller sends or receives, on which bus, at what rate.
The CAN page: every message the controller sends or receives, on which bus, at what rate.

Vehicle protection

  • Brake overrides throttle, and a vehicle with no brake sensor refuses to start.
  • Two-step arming before any traction.
  • Monitoring of the inverter, pedal plausibility, battery voltages and temperatures, with progressive derating.
  • Hardware watchdog, proven on the motorcycle.
  • A fault book, readable from the display and in the logs.
  • Live settings bounded by the firmware itself: an out-of-range value is refused, whatever sent it.

Checked before it ships

Every release goes through a battery of automatic checks: the logic tested function by function, two static analysers, a build without a single warning, and a closed loop where the real safety and control functions run against a model of the vehicle, fault scenarios included.

Release of 14 October 2026.

WHAT THE VEHICLE MUST DOHOW WE PROVE ITrideshardwareclosed loopfunction by functionVehicle safetythe hazards and what prevents themSystem requirementswhat each function must guaranteeArchitecture and controlthe layers, the control loopSoftware functionsinputs, safety, torque, loggingFirmware Cgenerated by VCU ForgeOn the vehicleVIL: logged rides1 VEHICLE, RIDDENOn the boardPIL passed on a board, HIL plannedIN PROGRESSIn the loop on a PCSIL: real code, vehicle model, 20 faultsEVERY RELEASEUnit testsevery function, static analysisEVERY RELEASE
Done on every release, or riddenPartly done, the rest planned

A green loop proves the software does what is specified, not that the vehicle behaves like the model. Real testing is still required.