GENIVI Open Source Projects
GENIVI employs an “upstream first” model and actively adopts and/or adapts existing components residing in the FOSS community to meet the defined requirements for its IVI software platform. In some cases, however, software to meet defined requirements does not exist in any upstream project. In those cases, GENIVI hosts projects that facilitate the development of required functionality in an open and collaborative manner, consistent with the best practices of other FOSS projects. Further, cases may exist for new projects to be launched which implement automotive functionality not yet defined by GENIVI or that may employ a different and innovative approach that GENIVI should consider for future platform releases.
The following list represents the GENIVI Alliance's Open-Source Community Projects for Automotive Software.
To learn more about the Alliance-sponsored public open-source community projects please view the FAQ document or explore the current projects listed below.
Want to be notified when NEW GENIVI Alliance Project Project sites are added? Sign up to receive a courtesy notification email. (Note: you should receive a confirmation email after signing up. If it is not showing up it may have been misplaced in the junk mail folder.)
AF_BUS D-Bus Optimization
As an alliance, GENIVI aims to leverage Linux and other Open Source
technologies. One of the tools GENIVI aims to re-use, D-Bus,
has become a de facto standard for many components to communicate
with each other.
Without precluding the option of using other IPC mechanisms, GENIVI
decided that D-Bus will be a part of any GENIVI system. Early tests
however showed that the performance of D-Bus could be improved and in
response to test findings, the D-Bus optimization project was launched.
The result of our efforts are approximately 100% improvement in
throughput and similar results for latency.
D-Bus uses AF_UNIX sockets as an underlying transport to communicate between the D-Bus deamon and clients. Clients can send multicast messages over D-Bus, so a multicast transmission is emulated in user-space over a set of unicast unix sockets. This emulation has some undesirable behaviors that affects the system performance such as lots of context switches and messages being copied between user-space processes and the kernel.
To overcome this limitation the AF_BUS socket address family was created. AF_BUS is based upon AF_UNIX but extended for multicast operation. By replacing D-Bus transport to use AF_BUS sockets, most of the message passing logic can be done in the kernel. This reduces considerably the number of context switches and messages copies required thus improving the D-Bus IPC system performance.
The AudioManager is a framework for managing audio in the IVI context. It shall provide a framework that;
- is able to manage audio abstracts hard and software with a common API in a way that the business logic can be implemented dependent from the actual used audio routing mechanisms
- makes it possible to implement different business logics for different projects
- independent from hard and software routing mechanisms
- is capable of managing dynamic added sources and sinks as well as static setups
- manages audio routing with the use of audio routing mechanisms that are interchangeable
- provides a common and simple API to command components like HMI and sources
- uses the standard GENIVI compliant mechanisms for tasks like persistence, user management and lifecycle
- The AudioManager is NOT yet another routing mechanism audio server
Christian Linke at firstname.lastname@example.org
Diagnostic Log and Trace
DLT is a reusable open source software component for standardized logging and tracing in infotainment ECUs based on the AUTOSAR 4.0 standard. The goal of DLT is the consolidation of the existing variety of logging and tracing protocols on one format.
- Verbose and none-verbose mode support
- System log-level and individual log-levels for contexts
- Binary transport of messages
- Message injection callback
- Predefined control messages
- Support for multiple applications and multiple contexts organized in a hierarchy
- Support for different interfaces between daemon and viewer (TCP/IP, Serial)
- Adapters to connect Linux log facilities like syslog
- User library and daemon provides a temporary internal buffer
- Trace message (network message) support
- Single trace file on Client side
- Many configuration options
Alexander Wenzel - email@example.com
IVI Layer Management
In the automotive domain, most HMI systems use their own window manager implementation. Many applications (e.g. navigation, reverse camera) are implemented standalone and therefore one service is used to composite all applications to final image on the screen Layer Manager. The goal of this work package is to define a common API and provide a proof-of-concept implementation for the IVI Layer Management Service. The service improves the existing vendor-specific layer management implementations which have the following features:
- Fixed number of hardware layers
- Hardware accelerated compositing
- Platform dependent
- Number of layers not extensible during runtime
- Vendor-specific implementation
- No standardized interface
- Hardware dependent
- No change during runtime possible
The IVI Layer Management has the following Enhancements:
- Well-defined interface
- Standardized compositing
- Convenient and consistent access to hardware accelerated modules
- Separation of HMI and Layer Management
- Dynamically Extensions during runtime
- Low integration complexity
- Reduced dependency on hardware
Among the different virtualization technologies Linux Containers (LXC) are particularly appealing for implementing multi-hosting embedded systems, by providing a userspace container object that supports full resource isolation and resource control for an application or a system.
The purpose of the LXCBENCH incubation project is to gain a better understanding of the capabilities of Linux Containers through benchmarking.
Before adopting this technology, it is strongly advised that users quantify the overhead it introduces and assess quantitatively the use cases where LXC can be beneficial.
The benchmarking activity we foresee aims to measure the performance of an LXC-equipped system versus a reference system not equipped with virtualization. For this purpose we selected the Phoronix Test Suite (PTS), see: http://www.phoronix-test-suite.com. PTS is an automated open-source testing framework and we envision the following measurement to be executed on a given hardware platform:
- Out-of-the-box Linux system (e.g., Ubuntu or similar). Run PTS to collect a set of measurements to be used as the baseline.
- Out-of-the-box Linux system enriched with 1 container, running Linux (e.g., Ubuntu itself, or Android). Run PTS in the baseline system only, run PTS in the container, run PTS in both concurrently.
After collecting the performance measurements in the above scenario, overheads will be evaluated by comparing the performance score of the baseline system with those of the container-enriched system.
It is relevant to underline here that the goal of the project is not to measure raw performance of a given hardware platform, rather to understand the overhead coming from the adoption of virtualization on different hardware configurations. For this purpose, we intend to repeat the same measurements on different hardware platforms, equipped with both single-core and multi-core (e.g., iMX5, iMX6), and to quantify the overheads before and after virtualization.
The outcomes of this project are twofold:
- A set of configuration scripts to set-up the test environment and run the tests. This will allow interested individuals to reproduce the same experiments we will perform.
- Overhead figures showing the impact of virtualization. We do not believe providing the raw performance figure is relevant, as this activity does not intend to measure the pure performance of a certain architecture or to compare the pure performance of different architectures. Conversely, it aims at quantifying the price system architects have to pay when including LXC as the virtualization solution in their architectures.
Prof. Massimo Violante (Politecnico di Torino) at firstname.lastname@example.org
Gianpaolo Macario (Mentor Graphics) at email@example.com
Questions about the LXCBENCH Project or for maintenance requests
Use the LXCBENCH Mailing List firstname.lastname@example.org
Node Startup Controller (NSC)
Part of the Lifecycle subsystem in GENIVI
The Node Startup Controller (NSC) was introduced into the lifecycle package for GENIVI in order to handle some startup and shutdown functionality. It essentially "extends" systemd to implement some IVI requirements that are not done by systemd itself because they are not generally applicable for all Linux systems (as determined through discussion with the systemd community). However, similar functionality might be desired in non-automotive systems so we hope this can be useful and/or develop into something shared across domains.
The main areas of responsibility for the NSC are:
- Last User Context (LUC) Management
- Legacy Application Shutdown
- Target Startup Monitoring
Node State Manager (NSM)
Part of the Lifecycle subsystem in GENIVI
The node state management is the central function for information regarding the current running state of the embedded system. The Node State Manager (NSM) component provides a common implementation framework for the main state machine of the system. The NSM collates information from multiple sources and uses this to determine the current state(s).
The NSM notifies registered consumers (applications or other platform components) of relevant changes in system state. Node state information can also be requested on-demand via provided D-Bus interfaces.
The node state management also provides shutdown management, so one part of the information which is provided is the shutdown request notification to the consumers.
The node state management is the last/highest level of escalation on the node and will therefore command the reset and supply control logic. It is notified of errors and other status signals from components that are responsible for monitoring system health in different ways.
Internally, node state management is made up of a common generic component, Node State Manager (NSM), and a system-specific state machine (NSMC) that is plugged into the Node State Manager. Through this architecture there can be a standardized solution with stable interfaces towards the applications, which still allows for product-specific behavior through the definition of the specific state machine.
Persistence Client Library
The Persistence Management is responsible to handle persistent data, including all data read and modified often during a lifetime of an infotainment system. "Persistent data" is data stored in a non-volatile storage such as a hard disk drive or FLASH memory.
GENIVI defines the structure for the persistence management to meet standardization of GENIVI compliant platforms and some unique requirements introduced by the automotive domain.
SmartPhoneLink is a project which intends to standardize and wrap the many in-vehicle interfaces which may exist in the automotive context. The end goal is to provide an expandable software framework to both mobile application developers and automotive head unit creators for the creation of brought-in applications that appear integrated onto a head unit.
Many in-vehicle HMI’s use different colors, templates, icons, fonts, voice systems and input methods for their infotainment systems. With SmartPhoneLink, a template-based approach is provided by the automotive head unit and allows for different HMI frameworks to follow a specific set of guidelines ensuring a consistent experience to a developer. By leveraging this common API and a brought-in device, automotive head units leverage the complete power of the brought-in device using the APIs being executed on the mobile device.
SmartPhoneLink consists of two (2) distinct parts of software; a core automotive piece which wraps in-vehicle services and integrates to the in-vehicle HMI, and a mobile proxy, which executes APIs to access and use services on the automotive head unit. The in-vehicle core has some of the following features:
- Manages the physical discovery and logical transport connection to a mobile device application
- Can support white-labeled, multi-function but single application use cases, as well as single app, single function use cases
- Provides a consistent interface for applications to understand the capabilities of an in-vehicle head unit
- Manages and maintains the state of connected mobile applications and notifies applications of appropriate state changes
- Wraps in-vehicle services such as buttons, displays, voice, menu systems, audio controls and other common vehicle inputs and outputs to a common messaging format and API
- Is expandable to allow for specific OEM or head unit manufacturer APIs or messaging
- Creates a template- and meta-based UI that creates consistent developer experiences regardless of the actual HMI representation
The mobile proxy components include some of the following features:
- Provides a common, abstracted interface to the in-vehicle infotainment system to integrate to SmartPhoneLink-enabled mobile applications
- Is available for Android and iPhone applications
- Supports TCP, Bluetooth and Apple-specific protocol implementations for transport, and can be expanded to include other transports
- Simplifies transport discovery, connection, and protocol use
- Is expandable to allow for specific-OEM or head unit manufacturer APIs or messaging