Skip to content

Shorten R&D time from ideation to production in IoT

3 min read

Abstract network of physical devices on the Internet using a network connection with statistics numbers 3d illustration

Continuous integration (CI) shortens embedded IoT software development time by applying unit tests, early integration tests, and automated testing. Yaniv Nissenboim, VP Product at Jumper Labs, explains why CI tools like Jenkins, Travis CI, and GitLab CI must be adapted for embedded systems, where a physical device in the testing loop creates unique constraints.

Why Is CI Critical for Embedded IoT Software?

Continuous integration is critical for embedded IoT software because these systems are distributed, connected, updated over the air, and prone to security breaches. As market demand to shorten development time from ideation to mass production increases, embedded software teams face more testing and quality assurance challenges than ever before.

In this series of posts, I’m going to explore different methods that can help shorten development time. These posts will be focused on streamlining and enabling continuous integration processes for embedded software development, including examples. If you are not familiar with the continuous integration process, I encourage you to learn about it if you want to ship high quality code, faster.

How Does CI Work in Embedded Software?

Continuous integration in embedded software follows a lifecycle of committing changes to a source control repository, triggering automatic builds at least once daily, and running automated tests on either a physical device or a testing machine. The physical device makes CI for embedded systems more complex than for web or mobile software.

The continuous integration lifecycle in embedded software development advocates to:

  1. Commit changes regularly to a source control repository.
  2. Build and integrate the software automatically at least once a day (recommended: after every code submission).
  3. Test the software automatically after a build is done. Either on the physical device/system or on a testing machine.
  4. Automatically test the software on the target physical device (sometimes you also need to run manual acceptance tests on the target physical device).
  5. Deploy.
  6. Analyze the report after each stage.

Note that a proper continuous integration process and automated software testing enables embedded software developers to work on different part of the system and code base simultaneously. When each commit triggers regression software tests, you get feedback as early as possible and fix bugs before it cost you with too many resources.

There are many available continuous integration tools, but none were built for embedded software development.

How Do You Choose a CI Tool for Embedded?

Choosing a CI tool for embedded software requires evaluating parameters including cloud-hosted versus self-hosted deployment, license type, integrations with IDEs and source control systems, supported platforms, and dashboard visualization. Popular CI tools include Jenkins, Buildbot, Travis CI, Circle CI, TeamCity, VSTS/TFS by Microsoft, and GitLab CI, though none were built specifically for embedded software development.

What Must You Consider for CI in Embedded Systems?

Implementing CI in embedded systems requires a modular, granular CI tool that integrates easily with different toolchains. According to Yaniv Nissenboim of Jumper Labs, the testing pipeline can grow too long, running automated tests on a physical device requires a tailored hardware lab, and running regression tests after every commit may not always be feasible, even though it is recommended.

Apart from the CI tool, as testing is done on a physical device, you need to take into account that:

  1. The testing pipeline might get too long.
  2. Running automated tests “on device” requires tailored hardware lab and integration to the CI tool.
  3. Running efficient unit, integration and system tests requires running your code an x86 machine.
  4. Running regression tests after every commit might not be feasible (although recommended).

On the next series of posts, we’ll get to the details and introduce practices to enable CI for embedded software and propose a portable build server, tailored for embedded software development.

More about Cybersecurity for Embedded Systems

 

The aYanivrticle was written by Yaniv Nissenboim and originally was published here. Yaniv  is an accomplished tech leader with a proven track record of taking an idea to a working product. Yaniv is an innovator at heart with a passion for technology and people. He has 15 years of experience in R&D (SW and HW) – development, management and execution, Product Management, Startup Building, System Architecture, Team Building, Market Research and Business Development. Yaniv is VP Product at Jumper Labs. 

Related Reading

Share with your network