IoT continuous deployment keeps software current
But continuous deployment is no mystery for some industries. Web-based offerings, such as Facebook and Netflix, have been using it for a while. It has never been necessary, or possible, for traditionally stand-alone embedded devices to be updated in this way. However, with IoT and constant connectivity, these Internet connected embedded devices can now be part of a continuous practices approach.
There are some other changes that are complementing the adoption of continuous practices. For instance, there has been an increasing awareness and interest in agile methodologies within the embedded space and, while they have been commonplace for high-end enterprise IT developers for many years, they are no longer viewed as being a trendy or passing phrase. An agile approach often comes with the practice of continuous integration. Sometimes it involves so-called “squad teams,” these are small engineering teams that take full responsibility for a specific task from design, to implementation and test, final integration, test automation and a nightly test-and-build system. This results in new feature development, fully production tested and integrated, built into the final system on a regular period, which should be every 1 – 3 weeks. Perhaps some teams might already be using a continuous delivery approach, so for them the step to continuous deployment is to remove the manual step from production to deployment.
For many developers, taking the step to a continuous deployment approach might not be that dramatic. If your team is already embracing agile and continuous integration, then moving to a continuous deployment process can appear to be a logical next step. Perhaps for some embedded development teams that have not started to implement an agile methodology the steps involved will be large and rather daunting.
While accepted for enterprise application development the actual use of continuous practices for embedded development does have some special considerations. This blog from Mike Bria in 2009 provides some key considerations that are still relevant today. First, It is more difficult to test evolving software since the corresponding hardware may not be readily available. Second, there is less freedom to change your mind, because the corresponding hardware change may come with unacceptably high cost. Third, there is less ability to leverage “learn as you go” techniques, considering the hardware construction may demand a more upfront style of planning and design.
Certainly, since software for embedded devices is so tightly connected to special built hardware, the situation is different compared to the general world of IT. A blog by David Rosen regarding continuous delivery describes this very well. He points that there is an enormous amount of legacy In terms of codebases as well as product architectures, team organizations, build systems, and test environments. Also, there is an insatiable need for compute infrastructure, especially when you consider the build times when using C/C++, which is well known for being long and CPU intensive. He also notes the difficulty to efficiently integrate and manage test automation when you’re dependent on manual configuration and deployment of physical targets. Finally, there is a costly and time-consuming need to verify development with regulatory requirements such as IEC 61508 and DO 178-B.
All of these complicating factors make it feel like true agile and continuous practices, including continuous delivery and continuous deployment, is simply not really achievable for embedded developers. How can they ever manage to have a quick and easy release process? There are two major complications that stand out:, the lack of immediate and ubiquitous access to target hardware and the lack of flexibility to change and modify hardware. These are, fortunately, being addressed in full system simulators that can run unchanged production binaries in a managed simulated environment.
Making the end-to-end time of the build-test-release cycle short is perhaps the most important aspect to address for any IoT-based embedded development. And, when everyone in the development team has access to virtual target hardware, which is possible to freely change and scale, suddenly you have a technical infrastructure that makes it possible to dramatically shorten lead times.
The IoT promises to dramatically change traditional business models and move historically product-centric revenues to service-based ones. This transformation is significant and represents the most significant change many organizations might have experienced during their lifetime. For embedded developers adopting agile practices and continuous integration coupled with internet connectivity opens up opportunities to incorporate full system simulation.
5 lessons on embedded software modelling
7 cardinal sins of embedded software development
Mastering the embedded software design cycle
About the Author
Eva has worked in the embedded software industry for nearly 20 years. She has had a number of positions within product management, product marketing and engineering for tools and real time operating systems. Ms Skoglund is located in Stockholm, Sweden, and is Product Line Manager for Simics Tools at Wind River. She holds a Master of Science degree in Computer
Science from the Royal Institute of Technology in Stockholm.
Join over 2,000 technical professionals and embedded systems hardware, software, and firmware developers at ESC Minneapolis Nov 4-5, 2015 and learn about the latest techniques and tips for reducing time, cost, and complexity in the embedded development process.
The Embedded Systems Conference and EDN are owned by UBM Canon.