Safety and security concepts


Resource Management

How to use cgroups to prioritize, limit and monitor resources usage per group of services in the Linux platform.


Architecture and design patterns

Error Handling

An automotive system must be reliable and stable.

Never assume that a memory allocation from the heap is successful.

Return values from external C-function calls and D-Bus response messages shall be validated and if it can't be handled, the event shall be logged and propagated to the caller. If this pattern is followed, it will automatically store a "stack trace" in the system log. See Log Handling for more information about logging.

TO BE DECIDED Error handling in C++ code (and using D-Bus IPC). Document the decision in Design Decisions.

Log Handling

Logging is crucial for efficient defect analysis. Finding the root cause for failures can be very difficult and time-consuming, especially for transient failures which are difficult and perhaps impossible to repeat.

As mentioned in Error Handling, by logging events the root cause for failures will eventually be easier to find.

Instrumenting the code with logging is intrusive to the system, and will not be deterministic if logging is removed after testing. The function calls made to the log API shall not be conditionally compiled depending on which type of image that is built, i.e. development image or release image.

Log Levels

A log level is associated with each log, and Table 3 describes the supported log levels.

Table 3 Log Levels
Fatal [1] Fatal system error, actions must be taken immediately Loss of the connection to vehicle bus
Error Impact to correct functionality A failure in the system's primary application
Warning A correct behavior can not be ensured An application has exceeded its file storage limit
Informative [2] Unusual event, but not error condition, or normal operation messages that require no actions An application has started, paused or ended successfully
Debug [3] Log messages, which are usable only for debugging a software  
[1]Associated with Syslog levels Emergency, Alert and Critical
[2]Associated with Syslog levels Notice and Informative
[3]The default log level shall never be Debug during system validation or in production code

Log Data Content

The log data for each event shall at least contain:

  • A timestamp
  • A log level as defined in Table 3
  • The dynamic content which triggered the log event, e.g. value of input parameters, return values etc.

The following events shall be logged:

  • Error If memory from heap cannot be allocated
  • Informative Unexpected return values and response messages
  • Informative Unexpected timeouts for service calls
  • Informative A service has been requested to start or stop
  • Informative A service has completed its initialization
  • Informative The kernel has been initialized
  • TO BE DONE add more events

Logging Client APIs

PELUX supports GENIVI DLT, which is a software component for standardized logging and tracing, based upon the AUTOSAR 4.0 DLT logging format. DLT has become the de facto standard in the automotive industry.

Every application that wants to log with DLT needs to register itself with a four-character identifier. The application register one or more log contexts using a three-character identifier. Every context has a current log level.

A DLT client application which can either run on target or on an external tester device, connects to the DLT daemon on target through a TCP port. The daemon gathers logs and traces from applications, which can be transferred to the client application. By using DLT, it's possible to retrieve information from the target without having a SSH server deployed on target.

  • C: For user-space software developed in C, the C-library libdlt from GENIVI shall be used.
  • Qt C++: For Qt bindings in C++, QtGENIVIExtras shall be used.
  • C++: TO BE DECIDED IVI-Logging is a software component which provides a C++ API to send log data to GENIVI DLT. The drawback however, is that the memory footprint of the components using the API becomes relative big since the API is based upon templates. An option would be to use log4cplus and adding a DLT appender as discussed here.


PELUX shall be prepared for On-Board Diagnostics (OBD) and provide built-in APIs which can be used by services and applications to read and write PIDs and generate DTCs.

Persistent Storage

Persistent storage is among other things required for hibernation and recovery to Last-User Context (LUT) for all services, applications and UI. To preserve the life-time of persistent flash memory, running services are not allowed to write to flash at any time.

Hibernation shall be taken in a controlled way, managed by the life-cycle management system. At minimum, hibernation is taken when the system is shut down in a controlled way [4].

To further preserve the life-time, wear leveling shall be used for persistent data which is updated frequently, e.g. at every driving cycle.

[4]The shutdown sequence can also aborted.

Inter-process Communication

D-Bus shall be the preferred IPC for control data.

System Upgrade

See Software Update Management.


To represent characters, Unicode shall be used. It assigns every character a unique number called a code point. The first 256 code points are identical to ISO-8859-1 (Latin1), which is encoded by one byte. In addition, the vast majority of commonly used characters for almost all languages are represented by two bytes in the Basic Multilingual Plane (BMP). The character encoding can either be UTF-8 or UTF-16, and the number of bytes required for the different encoding are different:


  • 1 byte: Standard ASCII (ISO-8859-1)
  • 2 bytes: Arabic, Hebrew, most European scripts excluding Georgian
  • 3 bytes: BMP
  • 4 bytes: All Unicode characters


  • 2 bytes: BMP
  • 4 bytes: All Unicode characters

Due the global intercommunication and the wide spread of using social media in the world, most In-Vehicle Infotainment systems will very likely need support for BMP. Using UTF-16 would be the best choice for achieving a low memory footprint, but since Linux and Qt uses UTF-8 as its default encoding system, PELUX will for conveniance do this too.

In general, the Presentation Layer is Internationalization aware while all layers below are agnostic to this. However, there are cases when certain language and locale based operations needs to be performed in lower layers, e.g. sorting and filtering. This is done by passing the needed context from the Presentation Layer to the lower layer as a part of the query.

Messages from Lower Layers

Characters which are sent in messages between layers shall be encoded with UTF-8 as mentioned in the section above.

Characters which are transferred to/from external systems shall be converted to/from UTF-8 as this is the internal encoding format used.


UI applications shall not contain any hardcoded plain text strings. A text ID translation mechanism shall be used for internationalization and localization. Each text string which shall be presented by the UI application shall be assigned an unique identifier.

Depending on the configured locale, the proper translated text string for the associated text ID is presented for the user in the UI.

Unit Conversion

Conversions between engineering units shall be done in the Presentation layer. Different locales may have different default units, but an end-user may want the ability to change these to fit their needs.

Input Modalities

As mentioned in Scope and context, there are many ways for a user to interact with an IVI system, like:

  • speech
  • touch
  • remote screens
  • remote devices
  • vision / gestures
  • diagnostics

By having multiple modalities, the system becomes more accessible and robust. However, the synchronization of all inputs and to determine which application(s) that shall react on the event is not trivial. A good start is to centralize all user input events to one component, an Interaction Manager.

Input Modalities

Fig. 4 Architecture overview of input modalities

A touch input event shall be received by the UI for an initial decode and translation. The UI shall translate the event into a specific command and send it to the Interaction Manager for further routing.

An input event can have a different meaning depending on which state an application has, i.e. what's in focus. This knowledge is not necessarily known by the UI, but the Application Manager and the Application Backends.

Since multiple applications can be active in parallel, a decision on which of them that shall react on a certain user input must be made. The decision is made by the Application Manager.

It's good to keep track of the source from which the event is originating from (speech, diagnostics, button panel x, touch panel y etc). The Interaction Manager shall add and store this information together with other event data, such as the event state, event id, coordinates, search strings etc. An example of why this can be relevant is for Rear-Seat Entertainment systems where a user input event from the rear seat shall be ignored if parental control is activated.