Field Report: Setting up a Software Product Line (SPL) Architecture based on Zephyr
summary
Field report documents building a secure IoT software product line on Zephyr using a reuse and extend paradigm, forks and live reuse across more than 50 repositories with one proprietary manifest repo. Work uses the Zephyr build system, module.yaml extension settings, ztest and twister for test runs, and Zephyr docs generators; verification gaps are identified but the prototype proves promising and recommends extensibility, live reuse, composability as next steps.
AI-written summary · about
chapters (24)
- 0:00Intro
- 0:42Preface
- 2:55What is a Software Product Line (SPL) Architecture?
- 4:09A Software Product Line is NOT
- 6:40Product Line Adoption and Institutionalization
- 7:26Speaking from Experience
- 11:51How Zephyr is being used as an SPL
- 17:54Costs of a Software Product Line
- 18:57SPL Core Asset Support: Architecture
- 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
- 24:02SPL Core Asset Support: Test Plans/Cases/Data Must consider variation points and multiple instances of the product line
- 25:24SPL Core Asset Support: Tools and Processes Must be more robustan required for single product development
- 27:06SPL Core Asset Support: Project Plans Must be generic or be made extensible to accommodate product variations
- 28:16SPL Core Asset Support: People, Skills, and Training Must involve training and expertisecentered around the assets and procedures associated with the product line
- 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
- 34:55Proposals: Embrace Extensibility (cont) MISRA Dir 3.1 (Required), states
- 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
- 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
- 40:32Multi-Project Integration Issues: Documentation
- 41:36Multi-Project Integration Issues: Verification
- 43:56Multi-Project Integration Issues: Implementation
- 46:19Multi-Project Integration Issues: Design
- 48:44Multi-Project Integration Issues: Requirements
- 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
55mZephyr: An Ideal Platform for Introducing Processes of Safety-Critical Embedded Systems
09mZephyr RTOS in Industry Research & Product Development
39mZephyr Project: Unlocking IoT Innovation with an Open Source RTOS
45mLeveraging Zephyr RTOS for modern embedded systems: a perspective from education and research
14mWhat is Zephyr and Where Is It Heading To?
10mLightning Talk: From Ideas to 3 Firmwares Powering Railway-Infrastructure Monitoring...
13mKeynote: Zephyr is Not a Product!
31mA Zephyr User Story