R-002 - Market, Certification, Regulation, and Positioning Facts¶

Status: Research record, 2026-10-07. Facts gathered from public sources; each carries its source. Where a host was unreachable from this environment, the fact comes from the search-engine summary of that page and is marked (summary). Purpose: Establish the external constraints and the competitive field that EmbLinkRTOS must be positioned against, before the mechanism-level comparison in R-001 and the differentiation decisions in R-003.

1. Who uses what¶

Fact	Source
Among about 2,300 embedded professionals and hobbyists surveyed in 2025, FreeRTOS is used by 82% of RTOS users and Zephyr by 14%; every other RTOS is in low single digits. Professionals diversify (VxWorks, ThreadX); hobbyists concentrate on FreeRTOS and Zephyr	JetBrains State of Embedded 2025 (summary)
Zephyr’s own community lists the recurring complaints it hears: “bloated and poor real-time performance compared to other RTOSes”, “I already have a vendor HAL, why more abstraction”, “Devicetree is so complex, macrobatics”, “how mature is this upstream driver”, “what is west and why must I learn Python”, “why is my board not supported”	FOSDEM 2025 Zephyr Roasting Party (summary)
Teams move from FreeRTOS to Zephyr for modularity, middleware, maintainability, board breadth, and tooling; the migration cost is a different kernel API, build system, configuration model, and HAL	Zephyr migration guide blog (summary)

Reading. The market is a duopoly of a small, simple kernel with a thin feature set (FreeRTOS) and a large platform whose complexity is its main complaint (Zephyr). The space between them, a kernel with Zephyr-class platform capabilities and FreeRTOS-class simplicity and footprint, is where EmbLinkRTOS positions itself, and the complaint list above is a checklist of what not to repeat.

2. Measured performance in the public record¶

Fact	Source
On an STM32F429 (Cortex-M4F), with asserts disabled and the tick at 20 Hz, a cooperative context switch measured 223 cycles on FreeRTOS v10.4.4 and 524 cycles on Zephyr v2.6.0; Zephyr’s own benchmark reported 468 cycles for the same operation. Each scenario was run 1,000 times	UL Solutions, Measuring RTOS performance part II (summary); part I (summary)
Zephyr’s `latency_measure` sample output (platform unspecified): context switch via yield 315 cycles, ISR return to interrupted thread 289 cycles, thread create 382 cycles, semaphore give with no waiters 59 cycles, mutex lock 83 cycles, FIFO put without context switch 214 cycles; results are affected by stack canaries and object statistics options	Zephyr tests/benchmarks/latency_measure README
ThreadX advertises a 2 KB instruction and 1 KB RAM minimal footprint (core services 2,000 bytes, queues 900, event flags 900, semaphores 450, mutexes 1,200, block pools 550, byte pools 900), sub-microsecond context switch, boot in fewer than 120 cycles, and at 200 MHz: thread suspend or resume 0.6 µs, queue send or receive 0.3 µs, semaphore get or put 0.2 µs, interrupt response 0.0 to 0.6 µs; determinism “whether there are 200 threads ready or just one”	ThreadX overview
Zephyr’s minimal sample on an Arm Cortex-M board: 7 to 8 KB ROM with multithreading, 3 to 4 KB with multithreading but no preemption and no timers, 2 to 3 KB with multithreading and timers disabled	Zephyr minimal footprint sample (summary)

Reading. Vendor claims are not comparable with each other (different boards, clocks, compilers, options). The only honest way to compete on numbers is to publish our own harness that runs the same operations on the same board for FreeRTOS, Zephyr, ThreadX, and EmbLinkRTOS, with the metadata rules of 05 §4.4. That harness is a deliverable (R-003 §5). ThreadX’s footprint table is the bar for the tiny profile; FreeRTOS’s switch cost is the bar for the base profile.

3. Safety certification landscape¶

System	Status	Source
Eclipse ThreadX	Certified by SGS-TÜV Saar: IEC 61508 SIL 4, IEC 62304 Class C, ISO 26262 ASIL D, EN 50128, UL/IEC 60730-1 and 60335-1 Class B; the first open-source RTOS with these certifications; MISRA C:2004 and C:2012 compliant for all required and mandatory rules	ThreadX announcement FAQ (summary); ThreadX overview
Zephyr	Written concept approval toward IEC 61508 SIL 3 / SC 3, route 3s (pre-existing code) as a Safety Element out of Context; a defined scope of about 15,000 lines (kernel services, initialization, APIs) out of 2.4 million; an auditable branch cut from main alongside an LTS branch; coding guideline enforcement in stages, tooling still “in evaluation”; SIL 3 requires 100% entry-point, statement, and branch coverage; StrictDoc-based docs-as-code requirements with traceability	Zephyr safety overview; Embedded World 2026 roadmap talk (summary); first submission announcement (summary)
SafeRTOS (WHIS)	FreeRTOS’s functional model taken through a HAZOP, redesigned, and developed under an IEC 61508 SIL 3 life cycle; certified by TÜV SÜD in 2007; sold with a Design Assurance Pack containing every life-cycle artifact; FreeRTOS itself holds no certification but ships CBMC memory-safety proofs and VeriFast functional proofs for parts of the kernel	WHIS (summary); FreeRTOS CBMC proofs
embOS-Safe (SEGGER)	IEC 61508 SIL 3, IEC 62304 Class C, ISO 26262 ASIL D; embOS-Ultra offers tickless, cycle-resolution timing specified in ms, µs, ns, or cycles; zero interrupt latency design; MISRA C:2012; SystemView tracing	SEGGER embOS-Safe (summary); embOS (summary)
RTEMS SMP	ESA-funded pre-qualification to ECSS-E-ST-40C and ECSS-Q-ST-80C for criticality category C on LEON3 and LEON4 multicore; a public Qualification Data Package and a defined “space profile” subset; extended in November 2025 to the GR765 and more of the POSIX API	RTEMS SMP QDP; ESA ESSR
INTEGRITY, VxWorks 653, LynxOS-178, PikeOS	Commercial separation kernels compliant with ARINC 653; INTEGRITY sells “certified freedom from interference” and guaranteed processor resources per partition	Green Hills INTEGRITY (summary); separation kernel survey (summary)

Reading. Certification is the dividing line between “used in products” and “allowed in safety products”. The open-source field has one certified kernel (ThreadX) and one in progress (Zephyr, with a lesson: certifying after the fact means writing requirements for 15,000 lines of existing code and inventing the tooling late). EmbLinkRTOS’s choice to write requirements, traceability, coverage, and coding rules before the first line of kernel code (05 §4 to §6) is the direct answer; it can reduce later evidence reconstruction, but certification feasibility and cost still depend on the chosen product scope, safety process, tools, independent assessment and maintenance capacity. Not claiming certification until achieved stays absolute (v0.1 §32).

4. Regulation that will apply to products using EmbLinkRTOS¶

Fact	Source
EU Cyber Resilience Act: notification bodies from 11 June 2026; from 11 September 2026 manufacturers must report actively exploited vulnerabilities (early warning in 24 hours, notification in 72 hours, final report within 14 days of a fix) and severe incidents; from 11 December 2027 all obligations apply: secure by design, conformity assessment, technical documentation, CE marking, a machine-readable SBOM covering at least top-level dependencies, vulnerability handling, and security updates through the support period; documentation retained ten years	Docker CRA overview (summary); Noze on SBOM and reporting (summary); SaM Solutions 2026 readiness (summary)
CISA and FBI “Product Security Bad Practices” (October 2024): manufacturers of products in memory-unsafe languages should publish a memory-safety roadmap by 1 January 2026 showing a prioritized approach to eliminating memory-safety vulnerabilities in priority components	TechRepublic (summary); The New Stack (summary)
The Rust compiler is qualified for functional safety (Ferrocene: ISO 26262 ASIL D, IEC 61508 SIL 3, IEC 62304); bare-metal Rust on Cortex-M is production-mature; RTIC and Embassy are the two mainstream Rust concurrency models	Derek Molloy, state of embedded Rust mid-2026 (summary); Hubble guide (summary)
FreeRTOS+TCP shipped 13 CVEs in 2018 (four remote code execution, seven information disclosure, one denial of service), affecting FreeRTOS up to 10.0.1, AWS FreeRTOS up to 1.3.1, and the commercial derivatives built on the same functional model	Security Affairs (summary)
The automotive hypervisor and mixed-criticality OS market is estimated at USD 562 million in 2025 and projected to grow at about 35% a year as ECUs consolidate into zonal and domain controllers that must run ASIL D functions beside QM software	GM Insights (summary)

Reading. Three external forces push in the same direction as the v0.2 architecture: regulators require SBOMs, vulnerability processes, and update capability (04 §6 already requires them); security agencies require a memory-safety story for C products (01 §2 item 9: hardened C now, language-neutral ABI, hardware safety features, Rust-ready); and the automotive market is moving toward mixed criticality on microcontrollers, which is exactly what partitions, budgets, and time-table scheduling (03 §2.2, §8) exist for.

5. Scheduling ideas from systems outside the MCU mainstream¶

Idea	How it works	Source
QNX adaptive partitioning	Each partition has a CPU budget as a percentage, measured over a sliding window (100 ms by default). Under load every partition gets at least its budget; when a partition underuses its budget, the free time is given to partitions that want more, so the scheduler behaves like a normal priority scheduler when the system is not overloaded and like a partition scheduler when it is. Critical threads (by default those started by an I/O interrupt) may exceed their partition’s budget up to a separate critical budget; exhausting that is “bankruptcy” with a configurable policy. Server threads run in the partition of the client they serve, so resource managers bill time to their clients automatically	QNX system architecture (summary); critical threads (summary); partition inheritance (summary)
seL4 MCS scheduling contexts	CPU time is a kernel object with budget b and period p: a thread may not run more than b out of every p µs. Partial contexts (b < p) are sporadic servers with a refill list (time, amount); on preemption or block the consumed amount is scheduled as a refill one period later; the refill list is bounded (two slots plus `extra_refills`), and overflow merges refills and forfeits budget. Full contexts (b = p) are round-robin. Passive servers own no context and run on the client’s context donated over `Call`, returned on `ReplyRecv`. Exhausting a budget raises a timeout fault to a handler with the consumed time. Priority decides when a thread runs; budget decides how much	seL4 MCS tutorial; seL4 manual, threads
RTIC resource ceilings	Shared resources are declared with the tasks that use them; the framework computes each resource’s priority ceiling at compile time (Stack Resource Policy / immediate ceiling); locking raises `BASEPRI` to the ceiling for the critical section; the result is deadlock-free, bounded priority inversion, no blocking, a single stack; resources shared only among same-priority tasks need no lock at all	RTIC book, resources
ThreadX preemption threshold	A thread may set a threshold priority above its own; while it runs, only threads with priority higher than the threshold may preempt it, which cuts context switches and, per ThreadX, improves schedulability	ThreadX overview

Reading. These four ideas are the strongest candidates for making EmbLinkRTOS’s temporal protection (03 §2.3) better than “fixed priority plus budgets”: sliding-window budgets with idle-time sharing (QNX) instead of hard periodic budgets only; budget donation to servers over Ports (QNX inheritance, seL4 passive servers) so a driver partition is billed to its client; compile-time ceilings computed from the hardware and thread description (RTIC) as the implementation of the ceiling protocol; and preemption threshold as an optional scheduling attribute. R-003 decides which become ADRs.

6. Sources that could not be read directly¶

The following hosts were blocked by this environment’s egress policy, so their content is cited from search-engine summaries and should be re-read before being quoted in any external material: ul.com, qnx.com, docs.sel4.systems, inovex.de, publish.obsidian.md, lp.jetbrains.com, rtic.rs, zephyrproject.org, hosted-files.sched.co, archive.fosdem.org, segger.com, promwad.com, arxiv.org. Where a GitHub mirror of the same content existed (seL4 tutorial and manual, RTIC book, Zephyr docs and benchmark README, ThreadX docs), the GitHub copy was read in full and is the cited source.