Custom system integration
Embedded Redesign
Board Support Package for System Houses
When Build, Test, and Release No Longer Align in a Traceable Manner
In established embedded projects, dependencies often develop gradually. Build environments vary, libraries are maintained manually, and releases depend on specific computers or the expertise of individuals. As the product’s lifecycle extends, this becomes a technical and organizational risk.
Non-reproducible build environments
Unclear Dependencies
Manual Releases and UpdatesDocker containers are not always Linux-based
Containerization is not limited to Linux. Modern Windows systems can run Windows containers. For Linux, however, Docker and similar container technologies provide particularly well-established mechanisms for packaging and isolating applications.
Containerizing traditional Windows applications requires a customized technical assessment. Windows Embedded Compact (WinCE) is not equivalent to modern Windows container environments and is generally not a Docker target platform.
Containerization is not a complete embedded system architecture
The following technical overview focuses on Linux-based embedded systems. Here, the kernel, drivers, and a system base - created, for example, with Yocto - form the foundation on which Docker containers can be run.
Containerization structures the application layer. It does not replace embedded Linux, the kernel, and drivers, nor does it replace an update, persistence, or recovery strategy.
Docker-based containers encapsulate applications and their defined user-space dependencies. This can make development, testing, and deployment significantly more manageable. However, the hardware-close system base remains a central task of embedded development.
What Containerization Can Do- Version and deploy individual services separately
- Make build and test environments more reproducible
- Create defined images as traceable release artifacts
- Organize versioned application releases in a more controlled manner
Decisions That Must Be Made at the System Level- Hardware access to interfaces and peripherals
- System services, user permissions, and network architecture
- Resource management, startup behavior, and real-time requirements
- System updates, persistence, recovery, and fallback strategies
The Difference Between Containerization and Virtualization
Containers and virtual machines both aim to isolate applications from one another. However, their technical implementation is fundamentally different.
| Criterion | Container | Virtual Machine |
|---|---|---|
| Operating System | Uses the host's operating system | Includes its own guest operating system |
| Linux kernel | Shared with the host system | Runs within the respective guest operating system |
| Resource Requirements | Generally lower, depending on the application and brand image | Higher Performance Through an Additional Operating System and Virtualization |
| Start-up behavior | Typically faster, depending on the application and initialization | System startup usually takes longer |
| Isolation | Separation at the operating system level | Separation via Virtualized Hardware |
| Typical Embedded Application | Modularization of Linux Applications on Appropriate Target Devices | Specific requirements for platform separation or runtime environments |
This does not automatically make containers the better solution. For embedded projects, the key question is:
Does the container boundary improve maintainability, repeatability, and updatability to such an extent that it justifies the additional operational overhead?
When Docker Containerization Makes Sense in an Embedded Environment
Containerization is not a standard component for every device. It should be used when it provides a clear technical benefit.
Docker containerization is often useful when …
- multiple services or applications need to be versioned separately
- applications have clear dependency boundaries
- build and test environments need to be reproducible
- individual components need to be updated independently of the base OS
- a clear build, test, and release process needs to be established
A different architecture may be more suitable if …
- Flash, RAM, or CPU resources are very limited
- a lightweight native application can perform the same task more easily
- hardware access is very tightly and privilegedly tied to the application
- particularly deterministic response times are a key priority
- a container runtime makes device operation disproportionately complex
The decision is not based on a single criterion. SIGMA evaluates the target hardware, target system, application architecture, interfaces, resources, and planned device operation in their overall context.
On the target hardware, an embedded Linux kernel - built using Yocto, for example - provides the kernel, drivers, and system services. On top of that, the Docker Engine runs applications in separate containers.
- Containers: contain the application, runtime libraries, and their own file system
- Common foundation: All containers use the host system’s Linux kernel
- Clear boundary: The bootloader, kernel, drivers, and hardware integration remain part of the system foundation
Versioning Code and Dockerfiles
The application, build description, and tests are stored in a traceable manner in the Git repository
Run a GitLab Pipeline
A GitLab Runner executes the defined build and test steps of the pipeline
Create an ARM Image
The container image is built to match the target architecture of the embedded system
Store Image in Registry
Verified versions are deployed with version numbers in a container registry
Controlled Deployment
The target device receives the approved image through the designated update or deployment process
GitLab in the Embedded Workflow
GitLab can integrate Git repositories, CI/CD pipelines, and a container registry into a single platform. GitHub can also be used for version control and automated workflows. Which environment is right for your project depends on your existing infrastructure, permission model, and build process.
Yocto provides the system foundation - Docker structures the application
An Yocto-based embedded Linux system can be specifically tailored to the target hardware and product requirements. The bootloader, kernel, drivers, system services, and the required software scope are defined at the system level.
Docker builds on top of this foundation. Containers organize applications and their dependencies without decoupling the embedded system from its hardware-related responsibilities.
A container can only operate reliably if the underlying Linux system is compatible with the device's hardware, application, and planned lifecycle. This architecture describes the Linux-based approach. Modern Windows containers have different requirements regarding the host system, compatibility, and operating model.
On Linux systems, Docker containers use the host system's kernel. However, the application and its native libraries within the container must be compatible with the target device's CPU architecture.
A container image built for an Intel or AMD machine with x86_64 will not run natively on an ARM-based embedded system - such as one with an i.MX system on chip. The fact that both systems run Linux is not sufficient.
The image must therefore be built to match the target architecture. Depending on the project, options include native ARM builds, cross-compilation, or multi-platform builds using appropriate build environments. GitLab CI/CD can automate this architecture-specific build and test pipeline.
Containers are lighter than virtual machines, but they still consume resources. In real-world operations, container runtimes, images, temporary files, logs, and persistent data must fit within the flash, RAM, and CPU budgets.
GPIOs, USB devices, serial interfaces, cameras, network adapters, and other peripherals remain explicit integration tasks. Permissions, device files, interface stability, and error handling must be planned at the system level.
Container images are typically treated as immutable. Configurations, calibration values, payload data, and log data therefore require a clearly defined persistence strategy.
A new container image is not a complete update strategy. It must be clear how versions are released, distributed, activated, and rolled back in the event of errors. Interactions with the operating system, kernel, and device data must also be taken into account.
Containerization does not provide real-time capability. Time-critical requirements must be met by the entire architecture - from hardware and drivers, through the operating system and scheduling, all the way to the application.
Create and Deploy Container Images in a Controlled Manner
Docker containers are reliable product components only if the origin, version, and contents of the images used remain traceable.
Containerization is not a standalone security guarantee. Security is achieved through embedded security customizations and the interplay of the system foundation, permissions, controlled images, network architecture, the update process, and well-developed software.
Containerization as Part of a Resilient Embedded Architecture
SIGMA doesn't just provide support for using individual tools. We consider containerization in the context of the underlying Linux system, target hardware, applications, the build process, and device operation.
Evaluate Container Suitability and Architecture
Integrating Embedded Linux and Yocto
Organizing Build, Test, and CI/CD
Plan Updates, Recovery, and Handover
Assess the Existing System
Document the target hardware, operating system, applications, interfaces, and existing build and release processes.
Defining Container Boundaries
Determine which components are part of the system foundation and which services can be effectively containerized.
Develop a Reference Architecture
Define the image structure, permissions, persistence, logging, registry, and deployment path.
Automating Builds and Tests
Integrate builds, tests, and artifact generation into a traceable process - tailored to the target architecture.
Validate on Target Hardware
Check resources, startup behavior, interfaces, failure scenarios, and update paths on the actual target system.
Documentation and Handover
Document the architecture and operational processes, coordinate them transparently, and hand them over in a way that ensures long-term maintainability.
Containerization requires an understanding of embedded systems below the application layer
A Docker image alone does not turn an application into a reliably operable embedded product. What matters most is an understanding of the entire chain - from the SoC and target hardware, through the operating system, the kernel, and drivers, to the application, the update process, and recovery in the event of a failure.
SIGMA integrates these layers in embedded software development. We do not manufacture hardware and are not tied to any specific platform providers. This allows us to evaluate technologies such as Docker, Yocto, or GitLab based on their actual benefits for your device.
No. Containerization is not exclusively tied to Linux. Modern Windows systems also support Windows containers.
In the embedded environment, however, Docker-based containerization is predominantly used on Linux systems. Linux can be tailored specifically to target hardware using build systems such as Yocto. In addition, container technologies are widely established there, and the system foundation can be precisely tailored to resources, drivers, interfaces, and the planned device operation.
Windows Embedded Compact (WinCE) is not comparable to modern Windows container environments and is generally not a Docker target platform.
No. Whether Docker is a good fit depends on the kernel configuration, resources, application architecture, security requirements, and operating model. For very small systems or particularly lightweight applications, native integration may be the better solution.
In principle, this may be possible for applications running on modern Windows systems. Key factors include the version of Windows used, compatibility between the host and the container, the application architecture, and requirements for hardware access and operation.
This page focuses on Linux-based embedded systems. For Windows applications, technical suitability should therefore be evaluated on a project-by-project basis.
In principle, this is possible, but it must be integrated in a targeted manner. Device files, permissions, interface stability, error handling, and the ability to update are part of the system architecture and not merely a Docker configuration.
Not native. The included applications, libraries, and base images must be compatible with the target ARM architecture. To achieve this, native ARM builds, cross-compilation, or multi-platform builds can be used.
Yes. GitLab can integrate version control, CI/CD pipelines, and a container registry. The specific implementation depends on the project size, existing infrastructure, target architectures, and the desired release process.
To some extent. Applications can be versioned and updated separately from the underlying operating system. However, dependencies between the container runtime, kernel, drivers, system services, and the application must still be taken into account.
Docker does not provide a real-time guarantee. For time-critical functions, latency, determinism, and error handling must be planned and validated across hardware, drivers, the operating system, scheduling, and the application.
We will be happy to present solutions for your industry and your processes. Talk to the specialists for SMEs.
request now
