Introduction and Goals

Introduction

PELUX is considered as an enabler for building and developing automotive Linux-based systems, including converged automotive systems and In-Vehicle Infotainment systems.

The In-Vehicle Infotainment domain is transitioning from a monolithic approach, where a single supplier delivers a complete software stack executing on top of a custom hardware, to a distributed model, where many parties are involved. This model can also contain software components being added after start of production by third parties on behalf of the OEMs.

To enable the distributed model, the software platform architecture has to be prepared for a modularized approach, where components can be integrated with a minimum modification.

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 Building Block View.

PELUX is the right choice for OEMs, Tier-1s or anyone who needs a Linux-based systems without vendor lock-in to kick-start projects for series-production products and Proof-of-Concepts (PoC).

PELUX is not considered as a complete product, more an executable architecture. The level of completeness of the deployed components may differ.

This document is loosely based on the arc42 document template.

Requirements Overview

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 enable personalization and user profile management to enable a unique user experience for multiple end-users.

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.

Quality Goals

  • 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.

Reader's Guide

  • Chapters Constraints and Scope and Context present the setting for the architecture.

  • The Solution Strategy chapter introduces strategies employed in the architecture.

  • The Building Block View chapter discusses the architectural building blocks.

  • The Runtime View chapter discusses the behavior of building blocks as scenarios, covering important use cases or features, building blocks.

  • The Concepts chapter discusses concepts that cuts through many domains and components in the platform.

  • The Design Decisions describe key design decisions.

  • The Realization of Features chapter discusses how features are realized.

  • The Glossary contains terms and their definitions which are used within this document.