Page tree
Skip to end of metadata
Go to start of metadata


GENIVI builds its reusable, IVI platform based on a flexible but standard Reference Architecture.  This Reference Architecture serves as a blueprint for building a full IVI solution and it also shows the primary target functional areas of the work from GENIVI.  The Compliance Specification steers the standardization, specifying exactly what is expected in the architecture implementation to build a GENIVI Compliant(r) solution. 


This common description allows you to use trusted open source components when building an Infotainment solution. The architecture also helps to avoid fragmentation on non-competitive areas of the software design. Members using the Compliance Specification to build a solution can register their product under the GENIVI compliance program and obtain a license to use the GENIVI Compliant(r) trademark in their solution marketing materials.  This branding will give buyers confidence that the solution adheres to GENIVI standards and to the component choices that ease integration and extension of the solution. 

Architecture Overview

GENIVI does not deliver a given design but a tool box that will let you make choices. In order to have a common understanding of the pieces in the box with a high level view of their role, a reference Block Diagram has been drawn.


GENIVI focus is on the “middleware” represented here by the yellow and the purple layers.

The yellow layer deals with key infrastructure domains. The smaller blocks map to individual software components, that are available in the open source community, some of them being developed in GENIVI open source projects.

In the purple layer above, the smaller blocks represent functional domains that may need several software components to be addressed, part of the software components needed may be commercial software components. 

GENIVI Compliance Specification

GENIVI compliance specification defines requirements on the middleware. The content of the Compliance Specification document can be seen as a list of software components that are described in different ways depending on their importance in the system built and the level of standardization that GENIVI wants to achieve in the area.

Thanks to the compliance specification mechanism, GENIVI can steer  standardization level to maximize reuse where it is worth and let freedom where competition brings more value. The use of P2 level let some flexibility both on features content (i.e., navigation interfaces are P2 as they would not be needed in a radio) and on standard enforcement (where the community is not ready to decide a unique standard), the use of P1 level leads to a strict standardization of either code, interfaces or requirements.

Companies can show their commitment to the standard through GENIVI Compliance programs.

  • "GENIVI Compliant" branding for platforms or products
  • "Works with GENIVI" branding for pieces of code

Learn more about these programs on

How does the compliance specification cover the architecture block diagram?

GENIVI target has been defined and work is still in progress in several areas. 

The detailed status is available in the documents listed in the next section.  An overview on how GENIVI defines its roadmap is also given in the appendix 2 “GENIVI Roadmap”.

More details on Architecture and Compliance Specification  

You can get a description of each domain of the block diagram in Appendix 3.

A static high level block diagram is not enough to describe an architecture. Developers need to understand deeper the data structures used and communication between the components.


Detailed Architecture and Compliance Specification are part of the members benefits. If your company is not a member yet you can find member benefits at

Promote these benefits in your company and join us!

Full Reference Architecture Document

Compliance Specification

Foreseen target for compliance specification


  • No labels