We work with these embedded operating systems and system layers
From Embedded Linux and Windows Embedded to Android, right through to microcontroller software and bootloader customisations. This overview shows you the key operating system environments and integration levels we work with in embedded projects.
Why the choice of embedded OS is relevant to the project
The choice of embedded operating system affects not only the subsequent software environment, but also the overall technical integrability of a device.
Hardware integration
Maintainability & Updates
Resources & Runtime
Embedded Linux is particularly useful when a system requires more than a fixed runtime environment. As soon as custom hardware, specialised drivers, network functions, security mechanisms, graphical user interfaces or long-term update strategies are required, Linux offers a robust and adaptable foundation.
We work with Embedded Linux using, amongst other things, Yocto, Debian and similar distribution-based approaches – always depending on the target hardware, maintenance strategy and product requirements. The focus is not on selecting the best-known distribution, but on technical suitability for the specific device.

Practical example: Linux BSP for real-time-capable target hardware
A real-time-capable Linux BSP was adapted to the requirements of the target hardware for Stührenberg GmbH. A TQ-Systems TQMa6UL module served as the hardware basis. Embedded Linux was the appropriate choice here because a customisable, hardware-oriented system basis with controllable BSP and driver integration was required.
Windows Embedded in technically defined system environments
Windows CE, Windows Embedded Compact, Windows 10 IoT Core or Windows-based x86 target systems are relevant in embedded environments where a defined platform, an existing system environment or specific driver requirements make this approach appropriate.

Practical example: USB touchscreen driver under Windows Embedded Compact 7
Drivers for two different USB touch panels were developed for TESOMA GmbH and integrated into a Beckhoff CX9020 PLC running Windows Embedded Compact 7. Windows Embedded was the right system platform in this case because the existing target system was already based on it and the aim was to integrate more cost-effective displays without having to modify the existing application or the underlying system environment.
Android for selected embedded systems with a focus on GUIs
Android can be a suitable choice in an embedded environment if the user interface, touch interaction and the nature of the application are more important than maximum system efficiency or a strictly controlled reduction of the runtime environment.
Compared with leaner Linux-based approaches, Android entails different requirements in terms of resource usage, platform architecture and technical maintenance. Android should therefore always be assessed in the context of the hardware, user interface and product objectives.
Android is particularly useful when
- the user interface is a central part of the product
- touch control and GUI logic are very much at the forefront
- the hardware platform provides a suitable foundation for the product
In this field too, SIGMA has experience in porting and adapting Android to suitable embedded platforms – including the customisation of embedded Linux kernel components where the platform and software stack so require.
Not every embedded system needs a full-fledged operating system
A full-fledged embedded OS is not necessarily the best solution for every project. Where functions are clearly defined, strict resource limits apply, or particularly direct access to peripherals and runtime behaviour is required, operating system-independent approaches or microcontroller-based software may be the technically sounder choice.
Particularly in control, measurement, testing or communication tasks, it is often more robust and cost-effective to develop software specifically for the hardware and task at hand, rather than carrying a larger operating system infrastructure.
The foundation underlying the operating system
An embedded system does not only become technically relevant once the actual operating system has started. The bootloader, hardware initialisation, device tree and board support package all play a decisive role in determining how smoothly a system boots up and how controllable the platform is during operation.
Bootloader
Device Tree
BSP adjustment
Secure Boot & HardeningWhich embedded OS is best suited to which task?
The final choice of operating system is not determined by a single product feature, but by the interplay of hardware, user interface, maintainability, security requirements and the effort involved in integration.
| Operating system platform | Deployment scenarios | Technical requirements |
|---|---|---|
| Embedded Linux | Customised hardware, complex interfaces, network functions, equipment that can be maintained over the long term | Kernel, device tree, drivers, BSP, updatability, security, controllable system foundation |
| Windows Embedded | Defined Windows target environments, existing device platforms, specific display or driver requirements | Driver integration, BSP customisation, peripheral connectivity, technical enhancement of existing platforms |
| Android | Devices with powerful GUIs, touch controls, and app-like user guidance on suitable hardware | Resource requirements, platform adaptation, integration at the kernel level, interaction between the GUI and system architecture |
| Without OS / µController | Specialised control, measurement, testing or communication tasks where resources are limited | Direct hardware access, compact runtime, tailored toolchain, clear division of responsibilities |
| Bootloader & BSP | Systems with customised start-up behaviour, specific hardware initialisation or enhanced security requirements | U-Boot, Barebox, E-Boot, Startsequenz, Hardwareinitialisierung, Secure Boot, Härtung |
Our practical project experience
The quality of a chosen embedded OS is demonstrated not in a theoretical comparison, but in a real-world project. In practice, the aim is to integrate the operating system base, hardware, drivers, boot chain and system behaviour in such a way that the target device operates stably, is maintainable and can withstand technical demands. The following references illustrate the types of project scenarios in which Embedded Linux, Windows Embedded, Android, OS-independent approaches or hardware-specific adaptations are best suited for use.
Finding the right embedded OS platform with SIGMA
An embedded system does not become resilient simply by selecting an operating system at an early stage, but rather by ensuring that the system architecture is properly aligned with the hardware, the target device and the product lifecycle. That is why we always consider the operating system, BSP, drivers and boot behaviour within the overall context.

Clarify requirements and constraints

Conduct a technical assessment of the operating system infrastructure

Specify the BSP, drivers and boot chain

Implementing system integration and commissioning

Ensuring the system’s performance and making it sustainable in the long term
The choice of embedded OS depends on the hardware, resources, user interface concept, security requirements, maintainability and the effort involved in integration. Embedded Linux is often the best option for more complex systems requiring long-term maintenance. Windows Embedded is relevant where there is a defined target Windows environment or an existing system infrastructure. Android is better suited to devices with a strong graphical user interface and touch-based operation. For clearly defined tasks, an OS-independent or microcontroller-based approach may also be the better choice.
Embedded Linux is particularly suitable when a system requires custom hardware integration, driver customisation, networking capabilities, the ability to receive updates, security mechanisms or long-term maintenance. Its strength lies in the controllable customisability of the kernel, device tree, drivers and user space.
Technically, Android is based on Linux, but is more geared towards GUI- and app-based use. Embedded Linux is generally more flexible and offers greater customisation when it comes to the kernel, boot chain, resource optimisation and customer-specific system integration. Android is particularly suitable when the user interface and touch interaction are the main focus.
Windows Embedded is relevant in situations where existing platforms, defined target environments or specific driver and peripheral requirements call for a Windows-based system architecture. In such cases, the decisive factor is not the technological trend, but rather how the overall system can be seamlessly maintained or adapted from a technical perspective.
A BSP is always required when the operating system and target hardware are not compatible with a standard image. This applies in particular to custom boards, specialised peripherals, customised boot sequences, or hardware-specific requirements for drivers and initialisation.
The bootloader and device tree are key components of platform integration. The bootloader initialises the hardware and hands control over to the target system. Under Linux, the device tree describes how hardware components are integrated. Errors in these areas have a direct impact on boot behaviour, driver linking and hardware detection.
No. For specialised control, measurement, testing or communication tasks, a microcontroller-based or OS-independent approach may make more technical sense. The key factor is whether an operating system is actually necessary for the specific device task.
Key requirements include a controllable boot process, the ability to apply updates, reproducible system states and a maintainable system foundation. Depending on the platform, these include, amongst other things, Secure Boot, hardening, maintenance of the kernel and drivers, and a well-structured BSP.
We will be happy to present solutions for your industry and your processes. Talk to the specialists for SMEs.
request now
