Field Report: Setting up a Software Product Line (SPL) Architecture based on Zephyr

on YouTube ↗53m

" summary

Argues Zephyr can serve as the basis for a secure IoT software product line and reports a working prototype built by forking and extending many projects into over 50 repositories with one proprietary manifest repo, using Zephyr 2.6.0, module.yaml and twister/ztest for builds and tests, and Zephyr docs for traceability. Cites an HP SPL that supported 400 developers and a historical example where a new model firmware was assembled in 30 minutes. Recommends CI verify module extensions, workspace-level docs, and config overlay locations.

AI-written summary · about

" chapters (24)

1. 0:00Intro
2. 0:42Preface
3. 2:55What is a Software Product Line (SPL) Architecture?
4. 4:09A Software Product Line is NOT
5. 6:40Product Line Adoption and Institutionalization
6. 7:26Speaking from Experience
7. 11:51How Zephyr is being used as an SPL
8. 17:54Costs of a Software Product Line
9. 18:57SPL Core Asset Support: Architecture
10. 21:33SPL Core Asset Support: Software Components Must be designed to be general without a loss of performance must build in support for variation points
11. 24:02SPL Core Asset Support: Test Plans/Cases/Data Must consider variation points and multiple instances of the product line
12. 25:24SPL Core Asset Support: Tools and Processes Must be more robustan required for single product development
13. 27:06SPL Core Asset Support: Project Plans Must be generic or be made extensible to accommodate product variations
14. 28:16SPL Core Asset Support: People, Skills, and Training Must involve training and expertisecentered around the assets and procedures associated with the product line
15. 31:27Assessment: What is needed for SPL Best Practice? Starting with Zephyr v2.6.0 functionality • Embrace Extensibility . How is each aspect of the ecosystem impacted by module
16. 34:55Proposals: Embrace Extensibility (cont) MISRA Dir 3.1 (Required), states
17. 36:14Proposals: Embrace Life REUSE Live REUSE includes topologies where the Zephyr repository is just another module in the workspace • Proposal The Zephyr document generation tools support workspace-level content coming from the manifest repository
18. 37:28Proposals: Embrace Composability Composability means managing boards, drivers, and subsystems so that they can be assembled into a working device without requiring crafting or tuning
19. 40:32Multi-Project Integration Issues: Documentation
20. 41:36Multi-Project Integration Issues: Verification
21. 43:56Multi-Project Integration Issues: Implementation
22. 46:19Multi-Project Integration Issues: Design
23. 48:44Multi-Project Integration Issues: Requirements
24. 50:25Engineering, the Path Forward Software Product Line is the current best practice model for what we are trying to achieve with rouse of Copen source software in embedded systems.

" related talks

• 32mArchitecting an IoT Product Line: Part 1 - ScopingGregory Shue · Zephyr Developer Summit 2022
• 35mBoosting Product Development With the Zephyr RTOS – a Critical ReflectionStephan Linz, Moritz Marquardt · Open Source Summit Europe 2025
• 16mKeynote: The Rise of Frameworks in Zephyr: From Devices to Subsystems to FrameworksAnas Nashif · Zephyr Developer Summit 2023
• 15mLightning Talk: A Reusable Zbus Based Architecture, Abstracting Core Application ComponentsJaco Liebenberg · Zephyr Developer Summit 2025
• 43mGoing West: How We Develop and Maintain a Zephyr-based Microcontroller SDKCarles Cufí · Zephyr Developer Summit 2023
• 27mInsights on the Re-Architecting to a Single Codebase, Running on Different Hardware...Ziv Hershkovitch, Erez Shaul · Zephyr Developer Summit 2023
• 41mFuture of Zephyr Device ModelEderson de Souza · Embedded Open Source Summit 2024
• 15mIs the Zephyr Device Tree Too Complicated?Tim Guite · Open Source Summit Europe 2025