Introduction and Goals¶
PELUX is considered as an enabler for building and developing automotive Linux-based systems, including converged automotive systems and In-Vehicle Infotainment systems.
Automotive In-Vehicle Infotainment systems are very complex and besides having newly developed software, it often also contains legacy software components. All features are likely not known when the project starts, and there is need to add new features during the development process but also after start of production.
Each customer has different configurations and different existing solutions. Having a toolbox with solutions that can be added or removed to a project configuration, allows us to provide solutions while allowing the customers to reconfigure the final platform.
The pace in which UI features are developed are likely different from the pace in which platform features and services are developed. PELUX solves this with a platform abstraction layer, which decouples presentation from the platform, see Architecture Overview.
This document is loosely based on the arc42 document template.
To avoid vendor lock-in using proprietary software, the agnostic reference integration platform PELUX shall use an extensive set of largely independent open source software components for automotive applications.
PELUX shall be based on Linux, but shall also have the ability to execute in converged systems using a hypervisor.
PELUX shall be released within 6 months after every stable Yocto release to provide a secure system.
PELUX shall be hardware agnostic to support processors and hardware architectures from many different vendors.
PELUX shall be HMI agnostic so the customer can choose between Qt/QML, HTML5 or any other technology for UI application development.
PELUX shall support multimodal interaction to enable a stunning user experience for the cars of tomorrow.
PELUX shall support dynamic content and 3rd party application development to enable new features during the whole life-cycle of the vehicle.
PELUX shall support remote software update so the end-user can take advantage of the latest version of software instantly.
- Flexibility: Each customer has different configurations and different existing solutions.
- Reliability: With support for connected services and the ability to provide new and updated 3rd party applications, the platform must isolate potential failures from spreading.
- Portability: Each customer has different hardware requirements and may have existing partnership with semiconductor vendors.
- Usability: UX and embedded developers have different needs and would like to have the best-in-class of development workflow.
- Maintainability: The platform must be maintainable through the whole product life-cycle of the vehicle.
- Chapters Architecture Constraints and Scope and context present the setting for the architecture.
- The Solution Strategy chapter introduces strategies employed in the architecture.
- The Architecture Overview chapter discusses the architectural building blocks.
- The Concepts chapter discusses concepts that cuts through many domains and components in the platform.
- The Realization of Features chapter discusses how features are realized.
- The Design Decisions describe key design decisions.
- The Glossary contains terms and their definitions which are used within this document.