In the embedded computing industry, the momentum of innovation might fluctuate, but it never stops. There is always the next new thing to adapt to.
Once, that new thing was the Linux® operating system (OS). Then it was Yocto Project, and sophisticated build environments such as OpenEmbedded.
These are now established features of the embedded ecosystem. So what’s next?
In my view, it is containers. Here’s why - and how developers who have not previously used containers can get up to speed with them.
The benefits of using containers in an embedded system
The great advantage of wrapping middleware and software - everything above the level of a lean Linux distribution - in containers is the flexibility it gives, both in development and once a device is deployed in the field.
![Embedded Devices Architecture](/media/blogs/foudnriesfactory-development-overview.png?hash=d3ad07cf43c)
The effect of the use of containers is to isolate each application and middleware function in its own silo, with access to processor resources arbitrated through the Linux OS. In the development process, this enables the workload to be distributed efficiently between developers, each working separately on their own containerized application or function. This is particularly helpful for development teams that have limited access to the hardware target’s development board: each developer or team can work in isolation on a different containerized application without reference to an SoC’s board support package. This helps OEMs to accelerate time-to-market while keeping development hardware costs to a minimum.
Containers also provide flexibility when maintaining and updating devices which are deployed in the field. Traditionally, firmware updates are delivered and deployed as a single monolithic package encompassing the Linux distribution, middleware and applications. After updating the Linux distribution, the device must be rebooted.
In a containerized architecture, discrete containers can be updated without requiring changes to the kernel or to other containers. This makes it possible to implement an over-the-air firmware update without the user even noticing that it has happened.
The isolation provided by containers also helps make embedded devices more reliable: if there is a problem or bug in a containerized application, the system can shut down just that container pending a fix, while keeping the rest of the system up and running.
The final flexibility advantage of containerization is that it unites a project from a single SoC family: containerized applications can be ported easily from one hardware platform to another.
These advantages of containers are more accessible to embedded developers now than ever before, thanks to improvements in hardware compatibility. The embedded industry has inherited container technology from the enterprise world: containers were originally intended for deployment in servers on the x86 architecture.
But there are already plenty of examples of the implementation of containers on, in chips such as Apple’s M2 and the AWS Graviton processor. Today, containers are being used in systems based on SoCs as resource-constrained as a 600MHz CPU with just 512MB of RAM and 4GB of Flash memory. Improved hardware compatibility means that containers are now applicable to most embedded design projects.
Getting started with containers
The best way to learn about using containers is to start working with the Docker container development environment. For users of the FoundriesFactory™ platform, this is made easier because Docker is fully integrated into it.
Boiled down to its essence, a container is a filesystem running on top of another filesystem. So getting comfortable with containers is first of all a matter of navigating your way through the filesystems, and figuring out in Docker how to get into and out of containers. It’s worth dipping your toe into this water: users normally find that it takes little time to get comfortable with the Docker environment and the configuration of containers.
In projects that are firmly committed to a container-based approach, the typical configuration is based on a lean Linux distribution - the Foundries.io Linux microPlatform is an excellent example - with most of the system’s functionality residing in containers rather than in the OS.
How the FoundriesFactory platform supports containerization
The benefits of containers apply to most embedded Linux projects, whichever platform and tools are used. But the FoundriesFactory platform has some extra tricks up its sleeve for users of Docker.
One is version control and fleet management, which ensure that all relevant updates are applied uniformly across all compatible devices. This solves a common problem in embedded products: if one team is responsible for updating the core Linux platform, and a different team updates containers, the updates can be applied to different sets of production units in the field by the two different teams. As a result, deployed devices which should all be running the same version of the Linux OS and the same versions of containers can actually be running different combinations of versions.
This creates the risk that combinations of versions are not properly validated and tested together, and so cause problems when released to devices in the field. This has potentially dangerous consequences for security and functionality.
Teams that use the FoundriesFactory platform to manage the development and maintenance of products avoid this problem because of the platform’s automatic linking of all changes, whether to a container or to the Linux OS: a changed version of a container is tied to a specified version of the Yocto Project Linux distribution in a single immutable image. This ensures that any one version of a container’s software and a specific Linux version are validated and tested together.
This is just one example of the FoundriesFactory platform’s adherence to best practice in the implementation of containers.
A second interesting feature of the FoundriesFactory platform for containerized systems is its support for streamlined production. When you are ready for production, there is an option for ‘container pre-load’: this feature builds the Yocto Project Linux distribution with the configured container images inside. Devices flashed with these images will be able to run the pre-loaded containers straight after flashing. This streamlines onboarding for the end user, enabling the device to start up and run applications without requiring an internet connection.
And of course there is much more besides to enable FoundriesFactory users to take advantage of containers in embedded Linux projects. Contact the Customer Success Engineering team if you would like help in getting started with Docker in the FoundriesFactory environment.