groundrun.io

Keeping Critical Components Up to Date: That's When You Want Groundrun

Keeping Critical Components Up to Date: That's When You Want Groundrun

Every embedded software team knows how important it is to keep critical components up to date, but every team also knows how hard it is to do in practice.

Or: it used to be hard. But not anymore.

Here is one example of how easy it is today to keep important components up to date.

Zephyr is the leading open source operating system for embedded devices today. In October 2026, Zephyr 4.5 was released. Ideally, this means that every team using Zephyr should update their code.

But, as teams working with embedded and connected products know, updating such a critical component is significant work: it may break things at every layer. Suddenly things like a device registration flow may fail to work, in subtle ways. And, even worse, invisible things such as power consumption and battery life may change in unexpected ways.

This is why we built Groundrun: to help teams automatically ensure that everything just keeps working, even after the upgrade.

And: with AI coding agents, the upgrade itself is easy.

Why Keep Critical Components Up to Date?

Security fixes is probably the most important reason why everyone should keep their critical components up to date. Zephyr, as any respectable project, maintains has a list of vulnerabilities. And under the EU's Cyber Resilience Act, manufacturers must "handle vulnerabilities during the lifecycle of their products", from December 2027.

But also because keeping up with critical components on every step means a smaller incremental change, which is easier to manage. The longer we postpone an upgrade, the more work we need to do, and the harder it is to apply a critical security fix when it arrives.

What Makes Keeping Up Difficult?

For every new release of one of the components, we both need to do the actual work of upgrading and we need to ensure that everything keeps working: both what our users see (interaction with the device), and what our users do not see (battery life, performance).

This used to mean a lot of work for a lot of people, beyond the actual work of upgrading: if the firmware team upgrades a component, it could mean that the app team or the cloud team will need to check that their systems still work with the new firmware.

With Groundrun, we have automated all that: the entire system gets tested, end-to-end, on every update. Both what the user sees and what they don't see but that still affects them, such as power consumption.

A Case Study: Updating a Bluetooth Sensor to the Latest Version

The sensor app's commission sheet for sensor sns-969f, scanned and ready to commission, with the site, asset tag and note filled in and the Commission button active.
Installing a sensor in the companion app.

A sensor is deployed on machinery to keep track of its vitals. The sensor has a Bluetooth chip that, whenever the operator is near, streams its vital readings to the operator. When no operator is around, the most important data is stored on the device.

This device was developed on Zephyr 4.4.2, the older version of the OS. Now we want to update it to the latest version, 4.5.

The sensor should continue working as intended, of course. So we want to test that all the user flows still work.

Also, we do not want its battery to drain faster than before: the power consumption should stay the same.

So we hook everything up to Groundrun rig:

  • A phone, that runs the app
  • A bunch of sensors

And then we give our AI coding agents the task of updating the Zephyr component from 4.4.2 to 4.5 and ask it to use the Groundrun rig to continuously validate itself. The Groundrun system does:

  • Runs the app: fully automating every user action, such as adding a sensor, placing it on the map, and ensuring that the process works.
  • Measures critical data: response times, power consumption of the hardware.

And once the AI coding agent is done, Groundrun reruns every user action through the app, on the real hardware, to ensure everything still works.

Hardware recording from a Groundrun rig: the app collecting data from three nearby sensors over Bluetooth, running the latest version of the system (Zephyr 4.5). We measure the power consumption to ensure that battery life isn't affected by the upgrade.

Looking at the power consumption specifically, we see that it matches what we had before.

Zephyr 4.4.2 average 19.84 µA 0 10 20 30 40 Zephyr 4.5.0 average 19.70 µA 0 10 20 30 40 0 s 5 s 10 s 15 s 20 s current (µA)
Sensor 3's current over the same 20 seconds of the run on each version, spike tops cut off at 40 µA. The dashed line is the average over the whole 17-minute measurement.
Average currentZephyr 4.4.2Zephyr 4.5.0
Sensor 119.80 µA19.76 µA
Sensor 319.84 µA19.70 µA

The sensor still has a battery life of roughly one year on a coincell battery.

Conclusions

Connected products are exposed: they need to be kept up to date at any time. As the manufacturer of these devices, we need to keep all of our critical components up to date. This used to be difficult.

Thanks to Groundrun, keeping critical component up-to-date is now easy: Groundrun ensures that every visible user action still works as expected, and that invisible metrics like power consumption are as they should be.

In this case study, a critical component of a customer product was upgraded: from Zephyr 4.4.2 to Zephyr 4.5. The Groundrun system ensures that everything still worked, during and after the upgrade.


Groundrun helps connected product teams keep critical components up to date with AI coding agents, by validating the user flows and the current draw on their own hardware: Groundrun platform overview.