Concept Designs

Definition Hardkeys: Also known as Hardware keys; Any controls in the car system connected to the Head unit. Examples of hardkeys are volume controls, fixed function buttons (back, forward, home screen, play pause), rotary controls etc. Traditionally hardkeys referred only to physical controls (e.g. switches, rotary dails etc), hence hardware keys. But current systems are far more flexible and due to that this design can also refer to software buttons rendered by the system UI outside of the applications control or touch sensitive areas with software controlled functionality. [Read More]

This document is intended to give a high-level overview of application handling by Apertis. Topics handled include the storage of applications and related data on the device, the format of the distributable application bundle files, how they’re integrated into the system, and how the system manages them at run-time. Topics related to the development of applications are covered by several other designs. Unfortunately, the term “application” has seen a lot of misuse in recent times. [Read More]

Network management is the task of managing the access to networks. In other words, deciding when and through which means to connect to the internet. In an IVI context this task is affected by several conflicting requirements. Connectivity may be spotty at times, with tunnels, high speed causing WiFi networks to come and go quickly, low cell phone signal strength, and so on. On the other hand, potentially good connectivity while parked, since the user might have high quality WiFi at the office and at home. [Read More]

This document outlines our design for address book contacts within the Apertis system. It describes the many sources the system can draw upon for the user’s contacts, how it will manage those contacts, which components will be necessary, and what work will be needed in the middleware space to enable these features. Contacts are representations of people that contain some details about that person. These details are often directly actionable: phone numbers can be called, street addresses may be used as destinations for the navigation system. [Read More]

This documents several approaches to debugging components of an Apertis system, either during development, or in the field. This includes debugging tools for reproducing and analysing problems; and logging systems for gathering data about problems and about system behaviour. The major considerations with a debugging and logging system are: Reproducibility: Many of the hardest problems to diagnose are ones which are hard to reproduce. A set of debugging tools should make it easy to reproduce problems, and certainly should not make the problems disappear when being debugged. [Read More]

This documents existing solutions for geo-related features (sometimes known as location-based services, LBS) which could be integrated into Apertis for providing geolocation, geofencing, geocoding and navigation routing support for application bundles. As of version 0.3.0, the recommended solutions for most of the geo-requirements for Apertis are already implemented as open source libraries which can be integrated into Apertis. Some of them require upstream work to add smaller missing features. Larger pieces of work need to be done to add address completion and geofencing features to existing open source projects. [Read More]

Apertis will store several types of information – media files, documents, contacts, e-mails, applications and their preferences, chat logs, and more. Much of this content will be stored with the application that generates or consumes it. A file manager would be very cumbersome for finding content in all these locations, and some of these data types are not strictly files. A powerful search system needs to be implemented to facilitate convenient access to the user’s data. [Read More]

This documents a suggested design for an inter-domain communication system, which exports services between different domains. Some domains can be trusted such as the automotive domain. Some domains are untrusted such as the consumer-electronics domain. Those domains can execute on a variety of possible configurations. The major considerations with an inter-domain communication system are: Security. The purpose of having separate domains is for security, so that untrusted code (application bundles) can be run in one domain while minimizing the attack surface of the safety-critical systems which drive the car. [Read More]

This design explains how the Apertis platform will be made localizable and how it will be localized to specific locales. “Internationalization” (“i18n”) is the term used for the process of ensuring that a software component can be localized. “Localization” (“l10n”) is the process of adding the necessary data and configuration so an internationalized software adapts to a specific locale. A locale is the definition of the subset of a user’s environment that depends on language and cultural conventions. [Read More]

This document covers the management of media content in the Apertis platform. There are several types of media content to handle in the platform: images, audio, video and documents. We can identify the following operations with media: Media Indexing: extracting metadata from media content and store it in a format that allows fast retrieval. Media Browsing: locate the media content and access its metadata. Solution provides a general overview of the technologies used, like an executive summary of Appendix: Media management technologies, as well as a high level view of the solution proposed. [Read More]