Skip to content

Over-the-Air ECU Updates Without the Risk: The Raptor-DEV Workflow EMB Power Runs for UK Vehicle Programmes

A secure over-the-air (OTA) update strategy means a vehicle programme can fix a software issue or roll out a new feature without calling every unit back to a workshop. At EMB Power, New Eagle's exclusive UK and EU partner for the Raptor toolchain, we build that capability around the Raptor-DEV model-based development environment and New Eagle's field-programming tools — so updates stay controlled, auditable and recoverable, whether they reach the vehicle over a network or through a direct connection at the roadside.

Why OTA Capability Belongs in the Architecture From Day One

For an EV or hybrid programme, the case for OTA capability is practical rather than aspirational: a fix for a software defect can reach the fleet without a workshop visit, a feature can be rolled out after launch rather than held for the next model year, and a response to an emerging safety or emissions requirement can go out on the manufacturer's own timeline. None of that removes the need for the usual validation and sign-off a vehicle programme already requires — it changes how a confirmed fix gets to vehicles already in the field. Retrofitting that capability after the architecture is fixed is considerably harder than specifying it from the outset, which is why we raise it early with programmes still at the controls-architecture stage.

The Raptor-DEV Workflow: From Simulink Model to Deployable Firmware

Raptor-DEV keeps update preparation inside the same Simulink®-based workflow used to build the rest of the control strategy, rather than treating firmware packaging as a separate, bolted-on step. In practice that looks like:

  1. Build, simulate and bench-test the control logic in Simulink using Raptor-DEV's native blocks, then compile it for the target controller — a Raptor GCM, RCM or body control module, depending on the application.
  2. Run the compiled application through Raptor-Test for automated regression checks, so a change to one function doesn't silently break another.
  3. Generate the reflash package from Raptor-DEV and apply the signing and integrity-check options the toolchain provides, so only an authorised, unmodified image can install.

Keeping this in one toolchain matters most once a programme is issuing its third or fourth field update: the packaging and verification steps are repeatable rather than reinvented for each release.

When There's No Network: Field Programming Without a Backend

Production OTA over cellular or Wi-Fi depends on a telematics gateway and a backend to serve the update — infrastructure most prototype and low-volume programmes don't have yet, and won't need to build for a one-off field fix. New Eagle's Raptor-Service tooling, which EMB Power supplies and supports as a node-locked subscription, covers that gap: it lets a field engineer connect directly to the target controller over USB-to-CAN and apply a signed update on the spot, with the same integrity checks the OTA path uses and a record of what was applied. EMB Power can confirm the exact service hardware and connector configuration for your specific controller and project — get in touch before specifying a field-recovery workflow around it.

Security and Fault Visibility Are Part of the Update, Not an Afterthought

Raptor controllers support secure boot, so an unsigned or tampered image is rejected before it can run, and reprogramming itself follows the standard UDS (ISO 14229) diagnostic services rather than a bespoke scheme — which matters when a field technician or a second supplier needs to understand the process without being handed a private spec. The core reprogramming sequence uses four standard UDS services: RequestDownload, TransferData, RequestTransferExit and RoutineControl.

UDS Service Service ID Role in a reflash
RoutineControl0x31Runs pre/post-programming routines (e.g. erase, checksum)
RequestDownload0x34Opens the transfer from the tool to the ECU
TransferData0x36Carries the firmware payload in blocks
RequestTransferExit0x37Closes the transfer and triggers validation

Service IDs per ISO 14229 (UDS); confirm the exact routine and parameter implementation against your specific Raptor controller's documentation before relying on it in a production workflow.

Avoiding the Common Pitfalls

Three habits separate a smooth OTA rollout from a stressful one: keep update packages modular so a delta update doesn't force an all-or-nothing reflash; run the full workflow — success, interruption and recovery paths alike — on real hardware rather than in simulation only; and make sure field engineers have a tested recovery route (not just the production OTA path) before the first update ships to a vehicle outside the workshop.

Why Engineering Teams Work With EMB Power

EMB Power is New Eagle's exclusive UK and EU supplier of Raptor control hardware and the Raptor-DEV model-based development toolchain, and now of the OpenECU range following New Eagle's 2026 acquisition of Pi Innovo. That gives UK and EU controls teams direct access to current Raptor and OpenECU hardware, UK-based engineering support for specifying and validating an OTA or field-programming workflow, and a single point of contact rather than a generic reseller handoff.

FAQ

Do we need a telematics gateway before we can do any OTA updates at all?

Only for the production, over-the-network path. A prototype or low-volume programme can get the same signed, validated update onto a controller via a direct USB-to-CAN field-programming connection, without building backend infrastructure first.

What stops a corrupted or malicious update from bricking the controller?

Secure boot rejects an unsigned or tampered image before it runs, the RequestTransferExit step triggers a validation check once the transfer completes, and a tested fallback recovery route should always exist alongside the primary update path.

Can an existing controls architecture be retrofitted for OTA, or does it need to be designed in from the start?

It can be retrofitted, but it's materially more work: finding the bandwidth, memory partitioning and security hooks after the architecture is fixed takes longer than allocating them at the design stage. We'd rather have that conversation early.

If you're specifying an OTA or field-programming strategy for an EV, hybrid or off-highway controls project, contact EMB Power to talk through the right Raptor-DEV and service-tooling setup for your programme.