The PELUX architecture favors development of feature verticals, i.e. verticals from pixel to silicon.
This is accomplished by a platform which is divided into verticals, where each vertical represents a functional domain, e.g. Media, Telephony, Calendar, Navigation etc. Some parts in the platform are of a "horizontal" nature. It can be distributed functions where a single interface is exposed to multiple verticals, e.g. Bluetooth which exposes interfaces to Telephony, Contacts, Calendar, Media etc. It can also be aggregating functions which gathers and encapsulates information from many verticals to provide a single function of interaction to the system, e.g. Speech, Prediction and Global Search. The platform abstraction, which spans all verticals, serves as a foundation supporting all UI applications. This is illustrated in Fig. 1.
Notice that in many common cases, the UI applications, i.e. the presentation of functions, is considered to be a part of the function. This can still be achieved in this architecture, but by decoupling the applications from the functions the user experience can be designed more independently of the functional partitioning of the underlying system.
Features and Backends¶
To support feature verticals, as well as efficient and independent feature growth, the PELUX architecture applies a pattern which is based on the separation of API facing the UI application developer, the so called Feature, and the code implementing it, the Backend.
A Feature is responsible for controlling a specific feature area, e.g. Media or Climate Control.
Every Feature needs to have a connected Backend, which needs to implement the corresponding feature backend interface. A Backend can be self-contained but most often it's dependent on a set of application and/or platform services.
Qt IVI from Qt Automotive Suite is an example of a platform abstraction component which fulfills the PELUX architecture needs. For a HTML5 setup, the platform abstraction may be a server providing a REST API to the rest of the platform.
Since QtIVI supports multiple Backends per Feature (including no Backends at all), the PELUX architecture can support dynamic appearing services. This implies that a system based on PELUX will become very future proof and reliable, since backends can easily be replaced or added.
Furthermore, the separation of Feature from Backend, makes it also possible to have simulated backends in scenarios where the hardware integration is not yet completely finished. Backends can also be tested separately from the UI application, and the UI application can be tested using a specialized testing backend.
UI Application Management¶
UI applications are owned and controlled by the Application Manager.
Applications are deployed as bundles containing a payload and manifest.
The manifest contains meta-data about the application.
The payload contains read-only data needed by the application.
Application access control is controlled using the application manifests. The manifests are provided by the application developer and needs to be validated by the application store owner.
The application manifests contains a list of capabilities that describe what functions the application needs access to.
The application manifests are owned by the Application Manager and can be requested.
On the target, access control is enforced using a combination of techniques:
- A Linux container created by the SoftwareContainer component. This restricts access by hiding or preventing access over given IPCs.
- Explicitly inside the services, e.g. if a service needs to expose the same interface to all applications, but only allow certain parameters for given requests.
When using the SoftwareContainer, the services exposed inside the container are described using a service manifest. Each capability (from the application manifest) must correspond to a capability defined in a service manifest.
Services doing explicit access control also need a service manifest in order to expose the interface that is explicitly controlled.
One exception to this rule are functions exposed by the System UI. These have access to an unfiltered peer-to-peer D-Bus communication channel to the application. This means that the interface is exposed without the SoftwareContainer being able to restrict access and that the System UI must implement explicit access limitations. To avoid warnings about misconfiguration due to missing capabilities, it is necessary that the capabilities used by the System UI for the explicit access control are declared as empty capabilities through service manifests.
This also means that the list of service manifest is complete, even though the SoftwareContainer does not restrict access to the interfaces exposed by the System UI over the peer-to-peer D-Bus channel.
The information flow from developer to components is described in Fig. 2.
To fulfill the startup requirements for an automotive based system, the Linux boot time needs to be decreased significantly.
Based upon customer needs, it shall be configurable to define that only mandatory kernel modules, like those required for early audio and video shall be built-in and loaded automatically. As soon as the UI is presented and becomes available for the user, other kernel modules and services shall be loaded and started.
Hibernation techniques shall be applied. Upon hibernation, the state of running services are stored in persistent storage at system shutdown. Upon resumption, at system power up, the state of the services are exactly the same as it was before entering hibernation.
Fork on component level or point out other components to use with the Yocto recipe. The Base Platform stays on master and benefits from the open source development and security patches.
MORE INFORMATION TO BE ADDED