Electronics Guide

Architecture and Design

FreeRTOS follows a minimalist design philosophy, providing a small, efficient kernel that implements core RTOS functionality without unnecessary features. The project documentation cites a typical kernel binary image of roughly 4 to 9 kilobytes; configurations that enable optional features such as software timers, event groups, and full mutex support commonly land nearer 10 to 12 kilobytes. Only three source files plus one architecture-specific port file are required to build the kernel. RAM usage scales with the number of tasks and the queue and stack sizes chosen by the application developer, so the practical floor is set by the application rather than the kernel.

The kernel implements preemptive, cooperative, or hybrid scheduling with configurable time slicing. The number of priority levels is set by the application through a single configuration constant and is bounded only by available RAM, except where the architecture-optimized task selection is enabled: that path uses a count-leading-zeros instruction over a 32-bit ready-priority bitmap, which caps the system at 32 priorities on Arm Cortex-M and similar targets. The scheduler supports both static and dynamic task creation, though static allocation is preferred for deterministic behavior and safety-critical applications, where dynamic heap use is often prohibited outright. Version 11.0.0 of the kernel, released in December 2023, added symmetric multiprocessing support to the mainline distribution, allowing a single kernel instance to schedule across multiple identical cores.

Key Features

FreeRTOS provides essential RTOS primitives including tasks, queues, semaphores, mutexes with priority inheritance, event groups, software timers, and stream and message buffers. The kernel supports tickless idle mode for low-power applications, reducing power consumption when no tasks require execution. Task notifications offer a lightweight alternative to semaphores for simple signaling scenarios.

Extensive hardware abstraction layers support virtually every major microcontroller family including the Arm Cortex-M, Cortex-A, and Cortex-R series, as well as RISC-V, ESP32, PIC, and AVR. This broad portability allows developers to migrate applications between hardware platforms with minimal kernel-level changes, since only the port layer and the configuration header normally differ. Silicon vendors commonly ship FreeRTOS ports and example projects in their own software development kits, which shortens bring-up considerably.

AWS Integration and Extensions

Amazon's acquisition of FreeRTOS brought integration with AWS IoT services through FreeRTOS libraries for MQTT, HTTP, device shadows, and over-the-air updates. The coreMQTT and coreHTTP libraries provide AWS-optimized connectivity while remaining usable with any cloud provider. These additions extend FreeRTOS from a pure RTOS into an IoT-capable platform.

The FreeRTOS-Plus ecosystem adds TCP/IP networking, file systems, command-line interfaces, and trace visualization. Third-party middleware from various vendors provides additional protocol stacks, security libraries, and application frameworks that build upon the FreeRTOS foundation.

Licensing and Support

FreeRTOS uses the MIT open-source license, permitting use in commercial products without royalty payments or source code disclosure requirements. The project moved to MIT from its earlier modified GPL terms at version 10, removing the last practical licensing friction for closed-source products. This permissive licensing combined with the backing of a major technology company makes FreeRTOS attractive for both startups and established companies. Commercial support is available through AWS and numerous third-party consultancies.

Long-term support releases receive security patches and critical bug fixes for a defined period, which matters for products that ship for years against a frozen code base. FreeRTOS itself carries no safety certification, but WITTENSTEIN high integrity systems supplies two licensed editions: OPENRTOS, which offers the same functional model under commercial terms with warranty and support, and SAFERTOS, which reimplements the same programming model against a certified development process and ships with certification evidence for standards including IEC 61508 and DO-178C. Teams that prototype on FreeRTOS and later face a certification requirement therefore have a migration path that preserves most application-level code.

Architecture and Capabilities

VxWorks implements a monolithic kernel architecture optimized for deterministic performance, with applications able to run either in kernel space for lowest overhead or as memory-protected real-time processes. Interrupt and context-switch latencies fall in the low single-digit microsecond range or below on current processors, but the figure that matters for certification is the characterized worst case for a specific board support package and hardware configuration, not a headline best case. Wind River publishes those numbers per platform, and caches, memory controllers, and interrupt controller topology dominate them. Memory protection through MMU support enables fault isolation between applications, crucial for mixed-criticality systems where tasks of different safety levels coexist.

The platform supports both 32-bit and 64-bit architectures including Arm, Intel x86, and PowerPC, the last remaining significant in legacy aerospace and defense programs long after it faded from commercial computing. Symmetric multiprocessing enables utilization of multi-core processors with a single system image, and asymmetric configurations allow VxWorks to occupy some cores while another operating system occupies the rest. VxWorks 653, the ARINC 653-compliant variant, implements strict temporal and spatial partitioning for integrated modular avionics, so applications at different design assurance levels can share a processor while each partition retains its own fixed time window and memory region.

Development Environment

Wind River Workbench provides an Eclipse-based integrated development environment with specialized tools for RTOS development. The debugger supports kernel-aware debugging, displaying task states, queue contents, and synchronization object status. System Viewer enables real-time visualization of system behavior including task execution, interrupts, and resource usage.

VxWorks includes comprehensive middleware covering networking protocols, file systems, security, and graphics. The platform supports POSIX interfaces for application portability and provides runtime analyzers for memory leaks, stack overflow, and performance bottlenecks. Simulated targets allow development and testing without physical hardware.

Safety Certification

VxWorks offers pre-certified configurations for major safety standards including DO-178C (avionics), ISO 26262 (automotive), IEC 62304 (medical), and IEC 61508 (industrial). Wind River provides certification evidence packages containing documentation, test results, and traceability matrices that reduce the certification burden for application developers.

The VxWorks Cert Edition specifically targets safety-critical markets with additional analysis artifacts and reduced configuration options that simplify certification arguments. Using a certified RTOS significantly reduces the effort required to certify the overall system compared to developing or certifying an RTOS independently.

Licensing Considerations

VxWorks licensing involves upfront development seat licenses and per-unit royalties for deployed systems. Licensing costs are substantially higher than open-source alternatives, but the cost is often justified by reduced development time, comprehensive support, and certification value for safety-critical applications. Long-term support agreements ensure continued updates and security patches.

Microkernel Architecture

The QNX microkernel implements only essential services: scheduling, interrupt handling, interprocess communication, and timer management. All other services including device drivers, file systems, and network protocols run as user-space processes with full memory protection. This architecture isolates faults, allowing driver failures to be detected and recovered without affecting other system components.

Interprocess communication uses synchronous message passing as the fundamental abstraction. A client sends a message to a server and blocks until receiving a reply, creating a simple and predictable programming model. The microkernel routes messages efficiently, and the resulting system achieves performance competitive with monolithic designs while maintaining architectural advantages.

Adaptive Partitioning

QNX Adaptive Partitioning Scheduler provides guaranteed CPU resource allocation to application partitions. Each partition receives a guaranteed minimum percentage of processor time, preventing any application from starving others. During light system load, unused partition time is redistributed to applications that need it, maximizing resource utilization.

This partitioning approach supports mixed-criticality systems where applications of different importance levels coexist. Critical applications receive guaranteed resources regardless of behavior from less critical components. The adaptive nature avoids the resource waste of static partitioning while maintaining isolation guarantees.

Automotive Applications

QNX has achieved dominant market share in automotive digital cockpits, instrument clusters, and infotainment systems, and it has since expanded into advanced driver assistance systems. Counterpoint Research figures cited by the company in December 2025 put QNX software in more than 275 million vehicles on the road, up from roughly 175 million five years earlier. The QNX Hypervisor enables virtualization of multiple operating systems on shared automotive hardware, running QNX alongside Linux or Android for different functions, which is the standard way a single system-on-chip now hosts a safety-relevant cluster and a general-purpose infotainment stack side by side. QNX OS for Safety is pre-certified to ISO 26262 ASIL D, the highest automotive safety integrity level.

The QNX Software Development Platform provides multimedia frameworks, graphics libraries, and connectivity stacks optimized for automotive applications. Integration with major automotive silicon platforms and ecosystem partnerships with tier-one suppliers support streamlined development of production automotive systems.

Security Features

The microkernel architecture inherently limits the attack surface compared with monolithic kernels: a network stack or device driver compromised in user space holds no kernel privilege, and the trusted computing base subject to formal scrutiny is correspondingly small. Process isolation ensures that exploitation of one component does not automatically compromise others. QNX supplies secure boot, file system encryption, and fine-grained privilege controls, and the platform has been evaluated under Common Criteria. Because connected vehicles now fall under cybersecurity regulation and the ISO/SAE 21434 process standard, vendors increasingly supply security evidence alongside functional safety evidence, and the two arguments are developed together rather than sequentially.

Performance Characteristics

ThreadX achieves exceptional performance through hand-optimized assembly code for critical paths on supported architectures. Context switching and interrupt handling routines are written in assembly for each supported processor to minimize execution time. The result is sub-microsecond context switch times on typical microcontrollers.

The kernel footprint starts at approximately 2 kilobytes of code space, making ThreadX suitable for the most constrained devices. All services have deterministic execution time independent of system state or the number of objects in the system. This predictability simplifies worst-case analysis and ensures consistent real-time behavior.

Middleware Ecosystem

ThreadX ships alongside a family of complementary components that were carried over intact from the Azure RTOS suite. NetX Duo provides dual IPv4/IPv6 TCP/IP networking with optimized implementations of common protocols including HTTP, MQTT, and CoAP. FileX implements FAT-compatible file systems optimized for flash media, with LevelX adding flash wear leveling. GUIX offers graphics and touch screen support, and USBX handles USB host and device functionality.

The modular platform allows developers to select only needed components, maintaining a minimal footprint while providing comprehensive middleware when required. The components remain fully usable with any backend infrastructure; connectors for Azure IoT and other cloud services are optional rather than required.

Safety Certification

ThreadX holds pre-certifications for IEC 61508 SIL 4, IEC 62304 Class C, ISO 26262 ASIL D, and EN 50128 SW-SIL 4. These certifications cover safety-critical applications in industrial, medical, automotive, and rail transportation domains. Certification packages include all required documentation, test results, and safety manuals.

Those certifications, originally obtained by Express Logic and Microsoft through an accredited assessor, transferred to the Eclipse Foundation with the code in October 2024, an unusual arrangement that the foundation describes as the first pairing of accredited safety certification with an open-source license. The certification artifacts, safety manuals, and the qualified binaries they apply to are made available through a ThreadX Alliance subscription rather than as part of the free source distribution, which is the mechanism that funds the recurring cost of maintaining certification as the code evolves. Static configuration options, full source code availability, and detailed documentation support certification activities and safety case development.

Licensing Model

Under Eclipse Foundation stewardship, ThreadX and its companion components are distributed under the permissive MIT license, permitting use in commercial products without royalties or source disclosure. Commercial support, indemnification, and the pre-existing safety-certification packages are available through Microsoft and ThreadX Alliance member companies for customers requiring guaranteed support levels. This arrangement combines open-source accessibility with enterprise support options.

PREEMPT_RT Patch

PREEMPT_RT makes almost the entire Linux kernel preemptible, bounding the intervals during which a high-priority task can be delayed. Originally developed by Ingo Molnar, Thomas Gleixner, and a long list of collaborators, it converts most spinlocks into priority-inheriting sleeping locks, moves interrupt handling into schedulable kernel threads, and shrinks the remaining regions that run with preemption or interrupts disabled. Priority inheritance throughout the locking layer is what prevents unbounded priority inversion inside the kernel, which is the failure mode that makes an unpatched kernel unusable for hard deadlines.

PREEMPT_RT enables Linux to achieve worst-case scheduling latencies in the tens to low hundreds of microseconds on well-configured hardware, adequate for many industrial, motion control, and audio applications. After roughly two decades as an out-of-tree patch set, the work was merged into the mainline kernel in Linux 6.12, released in November 2024, with the long-running rework of the kernel's console printing code as the final blocker; mainline support covers x86-64, 64-bit Arm, and RISC-V. Real-time behavior is now a kernel build option rather than a separate tree, which removes the maintenance burden of rebasing patches onto each new kernel and lets developers use standard Linux tools, drivers, and applications unchanged.

Achieving the advertised latencies still depends heavily on system configuration. CPU isolation, interrupt affinity, disabled power management states, avoidance of system management interrupts on x86, and careful driver selection all matter, and a single badly behaved driver holding interrupts off can dominate the worst case. Measurement with a tool such as cyclictest under realistic load, rather than on an idle system, is the only defensible way to characterize a deployment.

Xenomai

Xenomai implements a dual-kernel architecture where a small real-time co-kernel runs alongside the Linux kernel. The co-kernel handles time-critical tasks with hard real-time guarantees, while Linux manages non-critical functions. Tasks can transition between real-time and Linux execution modes, enabling integration of real-time and general-purpose code.

Xenomai 3 offers the Cobalt co-kernel alongside Mercury, a single-kernel configuration that layers the same programming interfaces over a PREEMPT_RT kernel, so application code can move between the two without a rewrite. Cobalt supports several API personalities, or skins, including POSIX and emulations of legacy RTOS interfaces such as VxWorks and pSOS, which eases migration from proprietary platforms. Xenomai 4 restructures the design around the EVL core and Dovetail, an interrupt-pipeline interface that replaced the older I-pipe and is far less invasive to the mainline kernel, addressing the maintenance difficulty that made the I-pipe hard to carry forward. The dual-kernel approach reaches low single-digit microsecond latencies while preserving full Linux functionality for non-critical components, at the cost of a second scheduling domain that developers must reason about explicitly, since an inadvertent call into a Linux service migrates a task out of the real-time domain.

RTAI

Real-Time Application Interface (RTAI) pioneered the dual-kernel approach for Linux real-time extensions. RTAI interposes a real-time executive between the hardware and the Linux kernel, giving the executive first access to interrupts and CPU time. Linux runs as the lowest priority task, executing only when no real-time tasks require service.

RTAI achieves excellent worst-case latency on supported hardware platforms and remains community-maintained, but development activity has declined markedly compared with Xenomai and PREEMPT_RT, and its dependence on the aging I-pipe interrupt pipeline ties it to older kernel versions. It is best regarded as a platform for existing installations rather than a default choice for new designs; with PREEMPT_RT now in the mainline kernel, the practical case for a dual-kernel architecture has narrowed to applications with latency budgets in the single-digit microseconds.

Commercial Embedded Linux

Several vendors provide commercially supported embedded Linux distributions with real-time capabilities. Wind River Linux combines Linux with Wind River's embedded systems expertise and shares board support and certification practices with its VxWorks line. Red Hat Enterprise Linux for Real Time and SUSE Linux Enterprise Real Time offer enterprise-grade real-time kernels with defined support lifetimes. These distributions supply tested real-time kernel configurations, board support packages, tuning tools, and professional support. Now that the real-time code is in the mainline kernel, the vendor's value shifts from carrying patches to validating configurations, characterizing latency on specific hardware, and standing behind the result.

Commercial distributions provide release management, security updates, and long-term support that may be required for industrial deployments. Vendor support simplifies addressing issues and provides accountability for regulated industries. The trade-off is licensing costs compared to self-supported community distributions.

Integrity RTOS

Green Hills Software's INTEGRITY RTOS implements a separation kernel architecture in which memory and time partitions are established at build time and enforced by hardware, so a fault or compromise in one partition cannot propagate. The INTEGRITY-178B variant was certified under Common Criteria at EAL 6+ against the Separation Kernel Protection Profile, a level of security assurance reached by very few operating systems, and the platform is used at DO-178C design assurance level A in avionics. It targets aerospace, defense, and automotive applications requiring the utmost assurance levels.

The MULTI integrated development environment provides Green Hills' optimizing compilers and advanced debugging tools, and a gatekeeper mechanism mediates inter-partition communication according to a statically defined policy. INTEGRITY-178 tuMP addresses certified multicore deployments in avionics, where the central difficulty is bounding interference between cores that share caches, memory controllers, and interconnects. Airworthiness guidance on multicore processors, notably the CAST-32A position paper and the AMC 20-193 rule material that succeeded it, requires applicants to identify and mitigate those shared-resource interference channels, and RTOS support for partitioning them is what makes such a system certifiable at all.

PikeOS

PikeOS from the German vendor SYSGO combines a separation kernel with a type-1 hypervisor, allowing multiple partitions to run different guest environments, from bare application code and POSIX personalities to full Linux instances, on a single processor under strict time and space partitioning. The architecture suits mixed-criticality consolidation, where a certified control function and an uncertified rich operating system must share hardware without the latter being able to affect the former.

SYSGO supplies certification evidence across several domains, including avionics under DO-178C and ARINC 653, railway under EN 50128, industrial functional safety under IEC 61508, and automotive under ISO 26262. This breadth makes PikeOS a common choice in European aerospace and rail programs and in projects that must satisfy security as well as safety objectives.

Deos

Deos from DDC-I is a time and space partitioned RTOS certified to DO-178C design assurance level A, with an ARINC 653 interface for integrated modular avionics. Its distinguishing scheduling feature is slack reclamation, which redistributes processor time budgeted to a partition but not consumed by it to other partitions that can use it, improving utilization without weakening the guarantees that make the schedule certifiable.

Deos is supplied with the full certification artifact set required for an airworthiness submission, and DDC-I positions it against the established avionics platforms for cockpit displays, flight management, and unmanned aircraft systems. Its existence illustrates a broader point about the certified RTOS market: the software is essentially a vehicle for the evidence package, and the evidence is what customers are buying.

Nucleus RTOS

Nucleus RTOS, originally from Accelerated Technology and later Mentor Graphics, is now part of Siemens following the acquisition of Mentor and its rebranding as Siemens EDA. Nucleus dates to the early 1990s and provides a commercial platform with full source code availability, emphasizing connectivity through extensive networking protocol support and USB middleware. It supports Arm, MIPS, and other processor architectures with a consistent API across platforms, and safety-certification packages are available for industrial, medical, and avionics use.

Nucleus ReadyStart provides pre-integrated board support packages that accelerate development on supported platforms, and the graphical user interface framework supports touch screens. Siemens continues to support the platform and its installed base, and its position within a large industrial automation portfolio offers integration paths that standalone RTOS vendors cannot match. New major releases have nonetheless been infrequent, and Nucleus attracts fewer new designs than the market leaders, so a long-lived program adopting it today should confirm the roadmap and support commitments directly with the vendor.

embOS

SEGGER's embOS is a compact, high-performance kernel that integrates closely with the company's widely used J-Link debug probes, emWin graphics library, and embOS-View and SystemView analysis tools. It provides priority-based preemptive scheduling with an optional round-robin mode, unlimited priority levels, zero-latency interrupt handling for interrupts that do not call kernel services, and deterministic, fragmentation-free memory pools. embOS-Safe is the certified variant, supplied with evidence for functional safety and medical device standards. The small footprint and the quality of the surrounding tool chain make it attractive for teams already standardized on SEGGER hardware, and its royalty-free licensing model avoids the per-unit fees typical of traditional commercial kernels.

Micrium µC/OS

The Micrium µC/OS family, acquired by Silicon Labs in 2016, includes the µC/OS-II and µC/OS-III real-time kernels along with complementary middleware for TCP/IP, USB, file systems, and graphical interfaces. µC/OS became a fixture of embedded education because its source is compact, heavily commented, and documented in books that walk through the kernel line by line, and it accumulated a substantial industrial installed base with safety certifications behind it.

In 2020 Silicon Labs released the µC/OS source under the Apache 2.0 license and ended its own external support for the products. Weston Embedded Solutions, founded by former Micrium engineers, now maintains the open-source code base and offers a commercially supported successor line, Cesium RTOS, together with certification support. Teams evaluating µC/OS should therefore distinguish clearly between the freely licensed legacy source, which carries no vendor support, and the commercially maintained descendant.

Real-Time Requirements

The strictness of timing requirements significantly influences platform selection. Applications with deadlines measured in single-digit microseconds, or with small memory budgets, favor compact kernels such as ThreadX, embOS, or FreeRTOS, where the entire code path can be reasoned about. Applications with deadlines in the tens to hundreds of microseconds that also need a rich software environment are well served by a PREEMPT_RT Linux kernel or by QNX. Where the requirement is not merely a deadline but a demonstrable argument that the deadline is met, the decisive factor becomes certification evidence rather than measured latency, which pushes the choice toward VxWorks, INTEGRITY, PikeOS, or Deos.

Quantify required response times, deadline miss tolerance, and timing jitter limits before comparing platforms. Vendor benchmark figures are typically best-case measurements on an idle system with caches warm, so treat them as an upper bound on achievable performance rather than a prediction. Measure on the actual target under maximum interrupt load, full system utilization, and worst-case cache and memory contention, and remember that on multicore parts the interference between cores frequently dominates anything the kernel contributes.

Safety and Certification

Applications in regulated industries often require or benefit from pre-certified RTOS platforms. Evaluate which safety standards apply to the target application (DO-178C, ISO 26262, IEC 62304, IEC 61508) and what certification levels are required. Consider both kernel certification and certification packages that include documentation, test results, and safety manuals.

Pre-certified platforms reduce certification effort and risk compared to certifying custom or less-supported solutions. However, certification comes at premium pricing and may constrain configuration options. The certification decision involves balancing certification costs against internal capability to certify less-supported alternatives.

Hardware Support

Verify that candidate platforms support target processor architectures and specific devices. Evaluate the quality and completeness of board support packages or hardware abstraction layers. Consider peripheral support for interfaces required by the application including networking, storage, graphics, and specialized I/O.

Broad platform support provides flexibility for future hardware changes, while specialized support for specific silicon may offer better optimization. Multi-core support becomes essential for applications requiring significant processing power or utilizing current processor families.

Development Ecosystem

Evaluate development tools, debugging capabilities, and available middleware. Consider IDE integration, compiler quality, and kernel-aware debugging support. Assess available middleware for networking, file systems, USB, graphics, and other required functionality. Documentation quality and community or vendor support affect development efficiency.

Developer familiarity with candidate platforms influences productivity. Training requirements and learning curves should factor into selection decisions, especially for teams new to embedded development or transitioning from different platforms.

Commercial Considerations

Total cost of ownership includes development licenses, per-unit royalties, support agreements, and indirect costs from development efficiency differences. Open-source platforms minimize direct costs but may require more internal expertise. Commercial platforms with comprehensive support may reduce development time and risk.

Vendor stability matters for long-lived products. Evaluate vendor financial health, acquisition risk, and commitment to the platform. Consider source code availability and escrow arrangements that protect against vendor failure. Long-term support availability ensures continued updates and security patches throughout product lifecycle.

Application-Specific Factors

Specific application domains may favor particular platforms. Automotive cockpit applications benefit from QNX's established ecosystem. Aerospace and defense commonly use VxWorks with its certification heritage. IoT devices may favor FreeRTOS or ThreadX for their cloud platform integration. Industrial automation may leverage Linux variants for integration with existing IT infrastructure.

Consider ecosystem partnerships, reference designs, and application examples in the target domain. Existing software components or libraries may have specific platform requirements. Integration with other systems may favor platforms with compatible interfaces or protocols.

API Compatibility

Migration between RTOS platforms requires adapting application code to different APIs. POSIX compatibility layers on some platforms ease migration from Unix-like systems. Abstraction layers can isolate application code from specific RTOS APIs, facilitating future migrations. However, abstraction may sacrifice performance or access to platform-specific features.

Behavior Differences

Beyond API differences, RTOS platforms exhibit different scheduling behaviors, priority handling, and timing characteristics. Applications may depend implicitly on specific platform behaviors that change during migration. Thorough testing under realistic conditions is essential to uncover behavior-dependent issues that API-level analysis misses.

Middleware and Integration

Migration also involves replacing or porting middleware components including networking stacks, file systems, and device drivers. Evaluate middleware compatibility and porting effort for each candidate platform. Consider whether middleware source code is available if porting becomes necessary.

Security Enhancement

Increasing connectivity of embedded systems drives security requirements higher, and regulation has begun to make them mandatory rather than optional. The European Union's Cyber Resilience Act imposes obligations on products with digital elements, including vulnerability handling and security update provision across a defined support period, while United Nations Regulation No. 155 requires a cybersecurity management system for vehicle type approval. RTOS platforms have responded with secure boot, encrypted storage, runtime integrity checking, signed over-the-air update mechanisms, and alignment with standards such as IEC 62443 for industrial systems. Memory protection and partitioning help contain breaches, and a documented software bill of materials has become a routine deliverable rather than a courtesy.

Multi-Core and Heterogeneous Processing

Modern embedded processors increasingly feature multiple cores and heterogeneous architectures combining different processor types. RTOS platforms are evolving to support asymmetric multiprocessing, where different operating systems run on different cores, and symmetric multiprocessing with thread migration between cores. Efficient communication between heterogeneous processing elements becomes a key capability.

Cloud and Edge Integration

IoT deployments drive integration between embedded devices and cloud platforms. RTOS vendors partner with cloud providers to offer streamlined connectivity and device management. Edge computing pushes more processing to devices, requiring RTOS platforms to support local analytics and machine learning inference alongside traditional real-time functions.

Consolidation and Open Source

The RTOS market shows both consolidation through acquisitions and a steady migration toward open-source models. Amazon's acquisition of FreeRTOS and Microsoft's later contribution of ThreadX to the Eclipse Foundation brought major technology companies into the embedded RTOS space and pushed flagship kernels under permissive licenses; Silicon Labs took a similar route with µC/OS, and the mainlining of PREEMPT_RT removed the last structural argument for out-of-tree real-time Linux. Foundation-governed projects such as Zephyr and Eclipse ThreadX attract broad industry-consortium support, challenging traditional royalty-based commercial models while maintaining enterprise-grade, safety-certifiable capabilities. The result is that the commercial boundary is shifting away from the kernel source and toward what surrounds it: certification evidence, long-term support commitments, indemnification, board support packages, and tooling. Companion coverage of the foundation-governed and community kernels appears in Open-Source RTOS Platforms.