At Spectra 2023, Particle announced seven new products and features, ranging from our newest development board (the Photon 2) to a new suite of software tools to create value with machine data (Particle Ledger and Particle Logic). But of everything we launched, I think the sleeper hit was probably Asset OTA, which extends Particle’s OTA software update capabilities to the other components and processors in your device. Put simply: Particle can now deliver systemwide software updates that extend beyond the surface area of the Particle module or gateway into whatever is connected to it.

I call this a “sleeper hit” because it’s not the kind of feature that generally creates buzz and attention; this is about as “in the weeds” as a feature can get. However, sometimes the best features aren’t the sexy ones — they’re the ones that require deep technical expertise combined with great customer discovery to figure out.

In order to explain why Asset OTA is amazing and systemwide software updates are the coolest thing since sliced bread, we’ve got to take a step back and talk about OTA in general. What is it, why does it matter, and why is it so goddamned hard to get right?

What is OTA?

OTA stands for “Over-the-Air”, and generally refers to the ability to remotely update the software on an embedded device over a wireless network. The term OTA is typically used in the context of embedded systems (i.e. not PCs) because before it was introduced, embedded systems could typically only be updated over the wire with physical access to the device (JTAG, USB, serial ports, etc.).

When Particle launched our first development board in 2014, a huge rift had formed between the web world and the embedded world. In the web, software companies had been updating their SaaS products with regular releases since Salesforce introduced the idea of SaaS with its launch in 1999. An ecosystem of “DevOps” tools had popped up to make it easier for software companies to update their software regularly without disrupting the user experience, and use of those tools coalesced around the concept of “Continuous Delivery”. Docker was taking the world by storm, and would soon be supplanted by Kubernetes as the de facto standard for deploying containerized software to servers running webscale software applications.

In contrast, the status quo in embedded systems was the Arduino IDE, which could update one device at a time if it was plugged into your PC. The big innovation for Arduino was that you didn’t have to have a JTAG programmer — you could just plug it straight into your USB port. Cool!

In some sense I could probably describe 80% of Particle’s IoT platform as taking well-worn best practices from the DevOps world and introducing them into embedded systems and IoT. And the very first place we did that was OTA.

If you bought a Spark Core in 2014, it came with a web IDE that was modeled after the Arduino IDE, with a similar programming framework (Wiring) for writing software applications and running them on the device. But the biggest difference? You could “flash” the device wirelessly.

This sounds like it might be a small change; if a device can take a software update over the wire, can’t you just run that same protocol over TCP and call it a day? No, not exactly. Wireless reprogramming introduces security issues (how do you make sure you trust the source of the software update?) and reliability issues (how do you make sure you never brick a device?), especially if you intend to deploy OTA updates to devices that are far afield. Fixing a problem with an over-the-wire update usually just means plugging back in and running the update again; fixing a problem with an OTA update means a truck roll or a recall.

Enter Particle OTA. Since we launched our over-the-air software update feature in 2014, we’ve focused on reliability and security. We did a bunch of clever things to ensure that devices are never bricked, with a series of checks and balances in place to ensure that no matter what happens, a device will always come back online to be reprogrammable again even if you write some bad software and deploy it out to the field. Because we never want this to happen to any of our customers:

These days, Particle’s customers have pushed out ~13 million OTA updates since we released the feature, and have come to trust Particle OTA to allow them to improve their products over time without risking these kinds of horror stories. To my knowledge, the only company out in the world that has a similarly robust OTA service is Tesla — and the way they improve their vehicles over time is an inspiration to us and to our customers. Our goal is to enable our customers to operate the way that Tesla does, treating their products more like “software on wheels” (or on a desk, or on a palette, or in a closet in the back of the office) than like machines and hardware devices. If you fear OTA, you never use it, and your products stagnate; if you trust OTA, you lean on it for “Continuous Delivery” and improve your products over time, the same way that SaaS companies do.

Advancements to Particle OTA

Since the original launch of Particle OTA, we’ve made regular improvements based on customer feedback. These improvements have generally been focused on improving speed, reliability, and scalability. Our goal along the way has always been focused on increasing customers’ trust in the OTA service, and reducing the natural negative side effects of OTA (like the moment when a device is offline installing the update, or the period of time where a fleet is partially upgraded and a user has to manage a fleet of devices with a mix of software versions). These improvements include:

• Application-only OTA in Device OS v0.4: With the release of the Photon, we split the user application and Device OS into separate modules that could be OTA updated independently. Application updates went from taking more than one minute to completing in just a few seconds.
• Intelligent OTA in Device OS v1.2: Devices that are part of a fleet can indicate to the cloud when it is safe for them to receive a firmware update, allowing OTA software updates to be deployed more quickly to devices that are “ready” to receive the update.
• Faster OTA in Device OS v3.0: A new OTA protocol increased the speed of OTA updates when connectivity is strong, while ensuring that updates get completed when connectivity is poor. Software updates are also now compressed and resumable so the device can receive updates through cycles of disconnection and reconnection.

Most recently, in 2021 we made OTA software updates free; customers who use Particle don’t have to pay for cellular data or any usage fees for using our OTA service. We did not want to create any barriers that would keep our customers from continuously updating their devices, so they can deliver value to customers as often as they create it through software upgrades and improvements.

The net result is that our customers keep increasing the rate at which they push out software updates to the devices; Particle OTA is now the fastest, most reliable, and most battle-tested OTA service on the market.

Asset OTA — how it works and why it’s awesome

A couple of years ago, I met a product leader at Tesla who was involved in the development of their OTA capabilities. I asked him what they did that made it possible to deliver software updates the way that they do, and he told me that the key is that every subcomponent of the car has a bootloader (the piece of software that receives and installs an update) and can be updated over-the-wire from the central processor. If one of their vendors doesn’t know how to implement a bootloader, they will implement it for them. Then they can deliver a “bundled” update to the central processor, which includes updates for any necessary subcomponents; the central processor plays a coordinating role ensuring that every subcomponent is running the right version of software such that everything subcomponent works together seamlessly after the update is complete.

As Particle’s customers have implemented us in more complex systems — in particular in vehicles, which often have multiple processors working together — we’ve gotten more requests to make it possible to update not just the Particle device but the system around it. So we built Asset OTA, which introduces into Particle OTA the ability to include a bundle of assets to be delivered to other subsystems as part of the OTA process. These assets would most typically be firmware binaries, although they may also be configuration files, graphics, ML models, or anything else that needs to be delivered into the “system” in which the Particle device resides.

Asset OTA includes three important capabilities that make it possible to deliver a more complex update while maintaining the OTA reliability we’ve become known for. These are:

• Bundling: Asset OTA allows the user to bundle additional files (aka “assets”) alongside a Particle software binary that will be delivered into their devices. This bundle is compressed in order to keep the update fast and efficient, and to consume less storage space on the device.
• Coordination: Delivery of the bundled assets to other processors or subsystems is handled by the Particle device, and the user controls that behavior by writing an update script at the top of their Particle firmware app. Every embedded system is designed differently, and this update script puts the engineer in charge of ensuring that the behavior of a systemwide software updates is customized to match the design of the device.
• Compatibility: The Particle device, through the update script above, ensures that each subsystem is correctly running a compatible firmware application before booting up. This avoids compatibility issues where subsystems come out of sync and the overall system misbehaves in unpredictable ways.

Asset OTA also carries forward the capabilities that already made Particle OTA so powerful — security, reliability, speed, and efficiency. And, as with the rest of Particle OTA, Asset OTA is free for all users; sending OTA software updates does not consume data operations and can be done as often as needed without incurring additional costs.

What can I do with it?

There are a few different ways to use Asset OTA, depending on the design of your IoT system.

Over-the-wire software updates to a vehicle or other complex embedded system

Vehicles and other complex embedded systems tend to have multiple processors that each are responsible for part of the behavior of the system. An e-bike, for instance, may have one processor that handles connectivity (the IoT part), another that handles the display, a third that controls the flow of energy to and from the battery, and a fourth that controls the motor. These subsystems typically communicate with one another via an over-the-wire communications bus such as CAN or RS485.

Asset OTA can be used to bundle updates to each of the subcomponents and distribute those updates over the communications bus, ensuring that the software versions on each subcomponent match and the system behaves as expected.

Over-the-air software updates to local wireless devices over bluetooth or LoRa

Particle customers often use Particle devices as a wireless “gateway” to connect wireless sensors, either using the Bluetooth Low Energy radio on our more recent devices or by adding a LoRa radio. Asset OTA can be used to deliver software updates over BLE, LoRa, or any other local wireless protocol in order to keep wireless sensors up to date and compatible with the software running on the gateway.

Running your application software on a secondary processor

At Particle, we pride ourselves in picking best-in-class microcontrollers to put into our devices. That said, our processor doesn’t meet everyone’s needs; sometimes you might need more memory, or more processing power, or more peripherals, or lower power consumption, or you might want ot use a different programming language/framework like MicroPython or Rust. Asset OTA makes it possible to use a Particle device as a networking module and run the logic of the product on a separate microcontroller like an STM32 or an RP2040. Now you can optimize the hardware design of your product however you want while still taking advantage of Particle OTA to update and improve your product over time.

Something entirely different

If I’ve learned anything about our customers, it is that they are always pushing the limits of our platform and using the features we launch in new and unexpected ways. A year from now I’ll inevitably be writing the follow up blog post explaining the two additional capabilities that Asset OTA unlocks that we didn’t predict — the ones that you all discover on your own.

How do I try it?

Asset OTA is now available in Device OS 5.5.0 and later, and works in our B Series products (Boron + B SoM), the P2 and Photon 2, and our gateways (Tracker One, Tracker SoM, and Monitor One). Instructions to use Asset OTA can be found in the Particle docs by clicking the link below:

Asset OTA documentation

In addition, you can find additional information here at the following links:

• Getting Started
• Device OS API docs
• Example Repos on Github