Automotive & Mobility
Automotive software for vehicle units that lose coverage and still have to update
Indeema engineers the firmware and companion software for units that ride on a vehicle: reports that wait for coverage, updates that survive a lost connection, and the apps that talk to what the vehicle carries. Here is what changes when a product travels, and where we join it.
See what the trip changesThe route
A vehicle takes the product away from the network
A telemetry unit on a vehicle is not a device on a shelf. It works along a route, and the route decides what it can do.
The unit rides with the vehicle.
Coverage comes and goes
Cellular service is strong in one street and absent in the next. The unit does not choose when it can report.
Storage is finite
While coverage is gone, readings wait on the unit. How much can wait, and what happens when the space runs out, are design decisions.
The vehicle is someone else’s design
The unit travels with a vehicle its maker designed, and still has to be configured and updated after it leaves the workshop.
The trip with gaps
Four conditions follow from a route with gaps
Each one is a design decision, not a default.
Coverage disappears
Coverage is part of the route, not a fault. In the telemetry-unit project the team anticipated the cellular module being unable to reach the network.
Reports wait in finite storage
A queue holds telemetry reports until coverage returns. It was designed against limited storage and lost messages.
An update can lose its connection halfway
The firmware update flow was built so that a lost connection does not leave the unit unusable.
The unit can still be configured locally
A person with a laptop can configure the unit over USB, with or without coverage.
Where we join
Most of the system is already there
In the telemetry-unit project the client had two board revisions, an embedded framework in place and a backend with charts. The embedded software was basic.
The data a vehicle reports, on a laptop and a phone.
The vehicle
its maker’sDesigned and owned by the company that builds it.
The unit
boards the client had, firmware Indeema wroteTwo board revisions already existed. Indeema wrote the embedded application that runs on them.
The server
already thereA backend with a development server and data visualisation was in place before the work began.
The work is a join, not a start. If the vehicle’s own signals or interfaces are your starting point, tell us first: they change the scope.
In engineering terms
What the trip changes in the firmware
What automotive software engineering has to settle once the product travels: four consequences, in the order they appear.
Reporting is a queue, sized to the storage the unit has
How it fills, and what leaves first when coverage returns, is written into the acceptance criteria.
An update has a recovery plan
The update flow is designed around the moment the connection is lost, so that the unit comes back in a state it can recover from.
Configuration does not need coverage
A cable and a laptop remain a way in when the network is not.
Ownership is drawn before the code
Thread-based firmware on an RTOS, checked against written acceptance criteria at each milestone. Where the firmware ends and the board or the server begins is agreed first.
In practice
Two products
A vehicle unit and a vehicle component, and the part of each that Indeema built.
- Vehicle telemetry unitFirmware for a light electric vehicle’s telemetry unit
A maker of electric vehicles had a telemetry unit with two board revisions, an embedded framework in place and a backend with charts, but only basic firmware.
- Indeema owned
- The embedded application on an RTOS: cellular modem initialisation, a telemetry report queue, an over-the-air firmware update flow and USB configuration. Quality checks against acceptance criteria at every milestone. A team of six, 2021 to 2022.
- The hard part
- Coverage cannot be assumed. The queue was designed against limited storage and lost messages, and the update was designed to survive a lost connection.
Read the projectA lost connection, staged on the bench.
- Vehicle-component productA companion app for a recreational-vehicle battery system
A European maker of lithium batteries for motorhomes and RVs had a Bluetooth app that showed charge, voltage and temperature from the battery’s own management system, on a legacy codebase.
- Indeema owned
- A new native iOS and Android application, built from scratch after a code review: Bluetooth Low Energy integration, a refreshed interface and compatibility across battery generations. Ongoing adaptation as the battery’s firmware evolves. From 2024.
- The hard part
- The supplier’s documentation was incomplete, so behaviour was confirmed on the batteries themselves, while older batteries kept working.
Read the project
The app beside the battery module it connects to.
Where the work continues
Where this leads next
- Hand over Embedded & Firmware
The method behind the unit: RTOS work, update flows and acceptance criteria.
- Hand over Applications & Experience
Companion apps for a connected component.
- Hand over Connected Product Engineering
When the product has to behave as one system across device, cloud and app.
Background reading: What vehicle telemetry is · IoT in the automotive industry
If the thing that moves is an aircraft, start with Drones & UAV. If the unit is fixed to equipment at a site, start with Manufacturing. Work that changes how a vehicle drives needs safety specialists from the start and sits outside this page.
Where to start
Start with the vehicle unit you want to build
Bring us
- The vehicle or component, and where the unit fits
- What already exists: boards, firmware, an app or a server
- How it will be updated and configured once it is out