Shorten R&D time from ideation to production in IoT

Shorten R&D time from ideation to production in IoT

This is an introduction to continuous integration in embedded software for IoT, and it’s the first one in a series of posts. If you are familiar with continuous integration, you can jump to What do you need to consider for CI in embedded? and skip the intro.

Intro

Software development and testing are two of the most important and time-consuming tasks in the creation of an embedded system. Embedded systems in the IoT space demand even more testing and quality assurance as these systems are distributed, connected, updated over the air and prone to security breaches. As market demand to shorten the development time from ideation to mass production increases, the embedded software development team is becoming overwhelmed with challenges like never before. The embedded industry, specifically in IoT, has realized that the one of the ways of dealing with these challenges is to apply continuous integration processes — unit tests, early integration tests and automated testing. While continuous integration is in wide use in web and mobile development software teams, applying it in the embedded software world is not an easy task as you have a physical device in the loop, with all its constraints.

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 continuous integration look like in embedded software development?

The diagram below is a simple illustration of a continuous integration process for embedded systems. What makes CI for embedded systems different is the physical device the software runs on.

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 to choose the right continuous integration tool for your embedded software team?

When comparing CI tools, you’ll find the following parameters:

1. Cloud hosted/Self Hosted — portability and flexibility.
2. License type.
3. Integrations and plugins to IDEs, source control systems, cloud services, project management tools and more.
4. Developed language
5. Supported platforms
6. Notifications
7. Dashboard and release process visualization

Among the popular CI tools out there you can find — Jenkins, Buildbot, Travis CI, Circle CI, TeamCity, VSTS/TFS by Microsoft, GitLab CI and more. But as the web is full of CI tools comparisons and recommendations, I will only outline the ones that work for embedded software development (in my opinion, feel free to comment).

What do you need to consider for CI in embedded?

A post by James Munns summarizes the different techniques in continuous integration for embedded, there’s also a TL;DR spreadsheet that sums it up (feel free to add your comments and thoughts).

In embedded software testing, you always need to adapt something to support your unique setup, so first and foremost the CI tool you want to use for embedded software must be modular, granular and easily integrated with different tool chains.

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 article 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.