Introduction to Zephyr
Relevant source files
The following files were used as context for generating this wiki page:
The Zephyr Project is a scalable real-time operating system (RTOS) designed for resource-constrained and embedded devices across multiple hardware architectures. It is optimized for footprint and built with a primary focus on security and functional safety. Zephyr supports a wide range of applications, from simple environmental sensors and wearables to sophisticated IoT wireless gateways and industrial controllers.
Sources: README.rst:22-29, doc/introduction/index.rst:5-10
Zephyr's ecosystem provides a modular architecture where components can be enabled or disabled via Kconfig, allowing developers to incorporate only the specific capabilities required for their application. This modularity extends to networking stacks, Bluetooth Low Energy (BLE) support, and various file systems.
Sources: doc/introduction/index.rst:104-106, doc/security/security-overview.rst:262-270
Core Architecture and Design
Zephyr utilizes a monolithic design where the kernel and application code are compiled into a single static binary. This approach eliminates the need for dynamic loaders and reduces the exposed attack surface, as system calls are implemented as function calls without requiring context switches in standard configurations.
Sources: doc/security/security-overview.rst:83-88, doc/introduction/index.rst:127-133
Layered Model
The system follows a layered architecture model to organize modules with similar functionality. This separation allows for distinct roles within the system and facilitates safety certifications by limiting the scope of safety-relevant components.
The diagram above illustrates the high-level layered architecture of the Zephyr OS, separating application services from kernel core and hardware abstraction layers.
Sources: doc/security/security-overview.rst:232-243, doc/safety/safety_overview.rst:196-205
Key Kernel Services
Zephyr provides a comprehensive suite of services for embedded development:
| Service Category | Description |
|---|---|
| Multi-threading | Supports cooperative and preemptive threads with priority-based scheduling. |
| Interrupts | Compile-time registration of interrupt handlers. |
| Memory Allocation | Dynamic allocation for fixed-size or variable-size memory blocks. |
| Synchronization | Binary, counting, and mutex semaphores for thread safety. |
| Data Passing | Message queues and byte streams for inter-thread communication. |
| Power Management | Policy-defined system power management and fine-grained device management. |
Sources: doc/introduction/index.rst:38-59
Supported Architectures
Zephyr is designed to be highly cross-architecture, supporting a wide variety of CPU types and developer tools.
- ARM: Cortex-M (v6-M, v7-M, v8-M), Cortex-A (v7-A, v8-A), and Cortex-R (v7-R, v8-R).
- Intel: x86 (32- and 64-bit).
- RISC-V: 32- and 64-bit variants.
- Others: ARC (v2, v3), MIPS, SPARC V8, Tensilica Xtensa, and Renesas RX.
Sources: doc/introduction/index.rst:12-25, README.rst:31-35
Security and Safety Principles
Security is a foundational element of the Zephyr Project, managed by a dedicated Security Subcommittee. The project adheres to established design principles to prevent violations and mitigate impacts.
Secure Design Principles
Zephyr implements several core security paradigms:
- Open Design: Using publicly accepted cryptographic algorithms (PSA Crypto/mbedTLS) rather than "security by obscurity."
- Least Privilege: Threads and programs operate with the smallest set of permissions required for their tasks.
- Fail-safe Defaults: Services are restricted by default and must be explicitly enabled.
- Execution Protection: Includes stack guards to detect overruns and memory partitioning to isolate threads.
Sources: doc/security/security-overview.rst:104-111, doc/security/security-overview.rst:248-275
Functional Safety (IEC 61508)
The project aims for SIL 3 / SC 3 certification for a specific subset of the kernel. This involves rigorous requirements tracing, 100% structural test coverage (statements and branches), and adherence to strict coding guidelines to minimize systematic errors.
The safety workflow ensures that code within the safety scope undergoes additional analysis and verification before being included in a safety-certified release.
Sources: doc/safety/safety_overview.rst:41-45, doc/safety/safety_overview.rst:116-135, doc/safety/safety_overview.rst:225-245
Documentation and Build System
Zephyr uses a modern toolchain for both code building and documentation generation. The documentation is written in reStructuredText (.rst) and processed by Sphinx and Doxygen.
Documentation Generation Flow
The documentation build process integrates multiple sources to create the final HTML or PDF output.
Visual representation of the documentation build process combining source code comments and manual guides.
Sources: doc/contribute/documentation/generation.rst:11-37
Build Tools
- West: Zephyr's meta-tool for repository management, building, and flashing.
- Devicetree (DTS): Used to describe hardware topology, allowing the same driver code to run on different boards by fetching hardware specifics from the DTS.
- Kconfig: A configuration system that allows fine-grained control over which kernel features and drivers are included in the build.
Sources: doc/introduction/index.rst:135-143, doc/contribute/documentation/generation.rst:31-33
Release Lifecycle
Zephyr follows a time-based release cycle (approximately every 6 months) rather than a feature-driven one.
- Development Phase: A 5-month window where the main branch is open for new features.
- Stabilization Phase: A period where only bug fixes, documentation, and tests are allowed, leading to multiple Release Candidates (RCs).
- Long Term Support (LTS): Published every 2-3 years, these releases are maintained for 5 years and are the recommended foundation for commercial products.
Sources: doc/project/release_process.rst:8-25, doc/project/release_process.rst:180-195
Conclusion
Zephyr provides a robust, modular, and secure environment for embedded development. By combining a highly configurable kernel with extensive cross-architecture support and a rigorous focus on security and safety standards like IEC 61508, it serves as a reliable platform for both hobbyist projects and critical industrial applications.