DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • How To Design Reliable IIoT Architecture
  • Build a Simple Chat Server With gRPC in .Net Core
  • Managing Data Residency, the Demo
  • Building and Deploying Microservices With Spring Boot and Docker

Trending

  • How To Design Reliable IIoT Architecture
  • Build a Simple Chat Server With gRPC in .Net Core
  • Managing Data Residency, the Demo
  • Building and Deploying Microservices With Spring Boot and Docker
  1. DZone
  2. Data Engineering
  3. Big Data
  4. How to Approach OTA Updates for IoT

How to Approach OTA Updates for IoT

See the role OTA updates play in IoT systems, learn which approaches are right for you, an the challenges in implementing OTA update mechanisms.

Jessica Califano user avatar by
Jessica Califano
·
Jun. 19, 18 · Opinion
Like (4)
Save
Tweet
Share
19.78K Views

Join the DZone community and get the full member experience.

Join For Free

We were recently discussing a new IoT project with a client, and their most pressing questions and product requirements centered around OTA (over-the-air) device updates. Consequently, we thought it would be useful to share some best practices for supporting OTA updates, since they are an increasingly important factor in determining IoT system success.

What Is OTA and Why Is It Important?

You’ve probably heard about the numerous OTA-related horror stories in the past couple of years that have seen people locked outside rental properties by bricked smart locks, stuck watching a single channel on their smart TVs, and far more seriously, unwittingly driving cars that can be remotely controlled by hackers. We’re going to outline how we approach designing OTA update capabilities so that you can avoid building a system with a similar fate.

An over-the-air (OTA) update is a mechanism for remotely updating internet-connected hardware with new settings, software, and/or firmware. The OTA update mechanism is a core part of a system’s architecture, with the remote hardware device being responsible for identifying and applying updates to itself, and the cloud server responsible for distributing updates to its connected hardware clients.

At this point in the evolution of IoT, it is well established that a robust OTA update mechanism is an essential component for any successful IoT system design. It’s not feasible to update devices deployed in the field using the traditional manual method, which involves connecting each embedded device to a PC with a cable. The traditional method doesn’t scale beyond the development phase, and failure to update geographically dispersed devices means missing out on everything from critical security patches and bug fixes to the latest product features.

OTA Updates Using Temboo

The Three OTA Architectures for IoT

There’s no-one-size-fits all approach to OTA. The right approach for a given IoT project depends on the nature of the hardware under consideration, the overall system architecture, the abilities of the team building the product, and the product itself. The most common OTA update scenarios are as follows:

  1. Edge-to-cloud OTA updates: An internet-connected microcontroller is capable of receiving new firmware images from a remote server. These images can contain updates to both the microcontroller’s underlying hardware capabilities, as well as to the application running on top of them.

  2. Gateway-to-cloud OTA updates: An internet-connected gateway, responsible for managing a fleet of local edge devices, is capable of receiving updates from a remote server that alters any or all of its software application, the software application’s host environment, and / or the gateway device’s firmware.

  3. Edge-to-gateway-to-cloud OTA updates: An internet-connected gateway is responsible for managing a fleet of locally connected edge devices, which in turn are capable of receiving remote firmware updates via the gateway.

Going into the technical details of each OTA architecture is outside the scope of this overview, but what’s more important are the numerous design considerations that you should be paying attention to, regardless of which OTA update approach applies to the IoT product or system that you’re building.

Important OTA Design Considerations for IoT Systems

As mentioned earlier, many IoT horror stories involve customers being left with bricked devices as a result of failed OTA updates. What these incidents have in common is not only that the new device image was buggy, a perpetual risk when software is involved, but that the OTA mechanism was not implemented in a fail-safe manner, meaning that neither the user nor the manufacturer could easily rollback or overwrite the bad image.

Here are some key considerations to take into account when thinking about OTA update solutions for IoT systems:

  • Automatic recovery from corrupted or interrupted updates is a must. OTA updates should be atomic, either succeeding completely or failing gracefully in a recoverable manner. A failed update should be capable of rolling back to the previous stable version, and no update should have the ability to disable a device’s connection to the update server and preventing further updates from being pushed.

  • Code provenance and integrity checks are essential. While a connected device’s ability to receive remote updates introduces many advantages, it also poses security concerns. Cryptographic code signing must be used to confirm that connected devices only accept code from verified authors, and that the code hasn’t been altered in transit.

  • Code compatibility verification is advisable. If you’re supporting multiple MCU architectures in the field, you’ll be distributing multiple firmware images as part of your OTA update process. It is strongly advisable to first confirm that the image received by a given remote device is actually appropriate for the client’s MCU architecture before applying the update – e.g., check that you’re applying an image built for a TI CC3220 to an MCU of that type. An inadvertent mismatch of this nature can have consequences that are difficult, if not impossible, to recover from.

  • Use secure communication channels by default. All OTA updates should be performed over encrypted communication channels. This should include not only the TLS connection between the cloud and internet-connected gateway or edge, but also the local connection between the gateway and its edge devices.

  • Partial updates should be possible. To decrease both bandwidth consumption and on-device processing time, partial updates should be supported so that only the changes to a firmware image need to be transmitted and applied to a given device.

Five Questions When Considering OTA Updates for IoT

Before we wrap up, here’s five questions to ask yourself when considering an OTA update technology in the IoT context:

  • Does the OTA update mechanism support automatic recovery from failed updates while preserving its connection to the update server?

  • Is security a first-class feature of the OTA mechanism and not something bolted on as an afterthought?

  • Can OTA updates be applied in an efficient manner, minimizing resources like network bandwidth, storage, and compute?

  • Can OTA updates be applied at various levels within a given application e.g., application configuration updates versus device firmware updates?

  • Does the OTA update mechanism leverage container technology (or similar) to work seamlessly across diverse hardware and software environments?

IoT Architecture application Firmware workplace Software security Connection (dance)

Published at DZone with permission of Jessica Califano. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • How To Design Reliable IIoT Architecture
  • Build a Simple Chat Server With gRPC in .Net Core
  • Managing Data Residency, the Demo
  • Building and Deploying Microservices With Spring Boot and Docker

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: