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

Purpose -

About this document:

This is a working document to stage and develop content for a GENIVI Style Guide Wiki.

The content will contain usage & design standards for anyone creating GENIVI Alliance visual materials including print, web, presentation decks and the GENIVI In-Vehicle Infotainment (IVI) interface.

The purpose of the Style Guide Wiki will be to provide a searchable platform for a single source for design standards and their evolution.

The graphical assets for the GENIVI Demo Platform HMI are located at

IVI Applications - 

Abbreviations and acronyms: 

Always spell out acronyms on first use in a document followed by the acronym in parentheses. The acronym alone may be used alone for subsequent use.

For example:

The GENIVI Demo Platform (GDP) is a useful tool when designing your In-Vehicle Infotainment (IVI) system. The GDP was introduced at the GENIVI All Member Meeting (AMM). The twice-yearly AMM is the premier event for Open Source IVI development.

Abbreviations and place names:

Spell out complete place names, including streets, states and countries on first use.

Exceptions: The acronyms USA and UK may be used without reference to the full country names. In press releases, Associated Press (AP) abbreviation rules apply.


A well-designed product is accessible to users of all abilities, including handicaps or impairments, and reduces distractions for the driver.

  • Clear — help users navigate by designing clear layouts with distinct calls to action. Every button, image, and line of text make the screen more complicated. Simplify with the following:

    • Clearly visible elements

    • Sufficient contrast and size

    • A clear hierarchy of importance

    • Key information discernible at a glance

  • Robust — design your app to accommodate a variety of users. Assume drivers have a very short attention span and make it easy to:

    • Navigate: give users confidence in knowing where they are in the app and what is important

    • Understand important tasks: reinforce important information through multiple visual and textual cues. Use color, shape, and text to communicate what’s happening

  • Specific — support assistive technology such as voice, screen readers, and gesture


Type - 


Use Helvetica for everything. If Helvetica is not available on your device, use its Windows-based “twin,” Arial.

Avoid condensed and extended versions.

 Eurostyle – Typeface used in GENIVI logo

Helvetica – Main typeface for all communications

Arial – Acceptable replacement for Helvetica


  • Do not run type on top of photographs or gradated illustrations when it conflicts with the standards listed here, or safety standards

  • Never use special effects on type

  • Visually presented text should meet the legibility recommendations contained in ISO International Standard 15008:2009(E). An abbreviated version of some of these standards as they apply to type are listed in the following slide*

  • Above all, legibility and content that is easy to grasp quickly is of the utmost importance

  • User testing determines whether or not an IVI is truly legible, well spaced, easy to see in different types of light, doesn’t distract the driver, and is accessible — meaning that the designated system function is operable by the driver while the vehicle is in motion

  • Driver goals can be met through executions for various systems

    *The weight of Helvetica Neue is lighter than the recommended ISO standard

International Standard (ISO) 15008:

Visually presented text should meet the legibility recommendations contained in ISO International Standard 15008:2009(E)- “Road vehicles — ergonomic aspects of transport information and control systems — specifications and compliance procedures for in-vehicle visual presentation.”

  • Character outlining — if contrast is not sufficient between a character and it’s background, additional means shall be applied

  • Character shadows — the stroke width of the outline by character height ratio should be less than 0,08 for characters without serifs. If the size of a character is so small that the stroke width of the outline would be less than 0,35 mm, an outline should be avoided to ensure readability

  • 4.5.2 The x-height for Helvetica is sufficient; for typefaces that have a proportion of x-height (height of “x”) to cap-height that is less than 65%, the font size should be increased so that their x-height is 70% of the recommended Cap height in Table 1 in order as to compensate for the smaller optical (or perceived) size

  • 4.5.5 Spacing

    • Typefaces selected shall be evenly and proportionately spaced and the space between vertical strokes (such as between l and m) should range between 150 - 240% of the stem width. The space between diagonal characters and a vertical (such as between v and l) should be a minimum of 85% of the stem width. Two diagonal characters shall not touch

    • The words space is related to the intercharacter spacing of the typeface. The proportion of word space to intercharacter space can range between 250 and 300%

    • Line spacing shall be maintained at a minimum of one average stem width. Text line spacing, T, is defined by the distance between the descender line of the current text line and the ascender line of the following text line

  • 4.5.6 Case — dynamic text, especially text related to messages that are urgent in nature, should be set in mixed or lower case, unless otherwise required by the national body. Uppercase could be used for texts that are a permanent part of the UI such as buttons and labels as the frequency and predictability of appearance of such text will improve the reading time required


Text - 

Text and NHTSA Safety Guidelines:

In order to reduce distraction, proposed National Highway Traffic Safety Administration (NHTSA) Guidelines recommend that in-vehicle devices be designed so that displays are easy for the driver to see and content is easily discernible.

Tasks associated with text that are considered to inherently interfere with a driver’s ability to safely operate the vehicle included the following:

  • displaying automatically scrolling text

  • manual text entry of more than six button or key presses during a single task

  • reading more than 30 characters of text (not counting punctuation marks) during a single task

  • manual text entry for the purpose of text-based messaging, other communication, or internet browsing

  • displaying text for reading from books, periodical publications, web page content, social media content, text-based advertising and marketing, or text-based messages

After the NHTSA made changes to their guidelines, the character-based limit for manual text entry was replaced by a recommendation against any amount of manual text entry by the driver for the purpose of text-based messaging, other communication, or internet browsing. The character-based limit for displaying text to be read has been replaced by a recommendation 

Text Sizes:

Font legibility is affected by the complexity of backgrounds, contrast, weight, tracking, kerning, leading, and alignment.

Using a 2:1, ratio for primary to secondary fonts is preferable for situations where text corresponds to numeric values such as temperature units, number pads, superscript, and subscript.

A 4:3 ratio is also applied to primary and secondary text heights when contrasting for visual hierarchy.

However, when a particular font, such as Helvetica Neue, does not meet the ISO standards for minimum weight, it would be recommended to scale it up as a secondary font. Primary to secondary fonts are used where contrast is

A minimum font size of 24px, or 7mm in height, whichever is larger — is recommended.

A maximum font size of 48px, or 12mm in height — is recommended.

Wherever clarification is needed, please refer to the document ISO International Standard 15008:2009(E)- “Road vehicles — ergonomic aspects of transport information and control systems — specifications and compliance procedures for in-vehicle visual presentation.”

Text Truncation and Abbreviation:

Avoiding truncation wherever possible is preferable. If truncation is required, such as in a text field, an ellipses shall indicate that there are more characters. When using truncation, the entire character at the end of the string must be visible.

Buttons may not be truncated.

Abbreviations have two types, and the way users think of them can affect the speed at which they are read and comprehended. Therefore,

Wherever clarification is needed, please refer to the document ISO International Standard 15008:2009(E)- “Road vehicles — ergonomic aspects of transport information and control systems — specifications and compliance procedures for in-vehicle visual presentation.”

Text Size Examples:

Coming soon...


Text Examples:


Logo Usage - 

Download link and spacing:

Please visit the GENIVI website logo page for downloads and for a downloadable Trademark and Logo Usage Guide.


The GENIVI logo must maintain a minimum space around it to achieve maximum visibility. This is measured by using the “G” in the logo. Two “G’s” around all sides can serve a visual reference to the space needed.


The logo CANNOT be modified in any way. It should only be used in the supplied formats. Please contact GENIVI for other formats.


Use the solid GENIVI logos (black or white) and not the old “chrome” logo.

(Images coming soon...)


Color Palette - 

Color Palette for print:

(Images coming soon...)


Pantone 647 C

 Pantone 646 C
 Pantone 420 C
 Pantone 425 C
 Pantone 1385 C
 Pantone 1685 C
 Pantone 1245 C


Color Palette for screen:

(Images coming soon...)


#00627f rgb(0, 98, 127)

 #1E9EB3 rgb(30, 158, 179)
 #CAC8C8 rgb(202, 200, 200)
 #555759 rgb(85, 87, 89)
 #D87900 rgb(216, 121, 0)
 #873A1F rgb(135, 58, 31)
 #C9920E rgb(210, 146, 14)
 #C80014 rgb(200, 0, 20)

Screen Size Recommendations - 

IVI (In Vehicle Infotainment) Configuration:

  • 11-inch Diagonal

  • 1920x1080 16:9

  • 200ppi

(Image coming soon...)


Cluster Configuration:

  • 12.3-inch Diagonal

  • 1920x710 8:3

  • 166ppi

(Image coming soon...)


IVI "Handedness" Recommendations - 

Left-hand vs. right-hand driving:

Highest priority items should be placed closest to the driver, populating from upper right to lower left for right hand drive scenarios.

Certain components, such as modal windows that close on a particular side, may be flipped to accommodate right hand drive. Option selectors and positive action buttons should be placed closest to the driver. Keyboards should be placed slightly closer to the driver than the passenger.

Hit area tests (HAT) are recommended for areas that tend to harder to reach, such as right behind the steering wheel and furthest away in terms of accuracy. As users get closer to the edges of the screen, they tend to be less accurate.

Please see further information on HAT here:


IVI Grid Layout - 

Grid Layout:

To meet the requirements of the 1920px by 1080px screen size for the IVI, we recommend using a 60px by 60px grid in order to meet the 15mm by 15mm minimum press area with a 15.22mm by 15.22mm press area. The creates a width of 32 grid unit (GU) by 18 GU. Therefore, the design pixel units for the press area for this grid would be 120px by 120px, or 2GU by 2GU.

11-inch screen - 1920px by 1080px (16:9 ratio), 220ppi


Homescreen - 

Homescreen Layout Configuration:

Laid out on a 60px by 60px grid, the homescreen has 1680 pixels for the floating icons which launch applications.

There is no outer perimeter interior padding.

The sidebar space is 240px wide. The vertical 900 pixel high bar along the edge between the icon space and the sidebar launches the application grid when tapped or swiped.

Please note that the ghosted letters next to the word ‘GENIVI’ in the sidebar logo are for spacing reference only (see slide 9). 

11-inch screen - 1920px by 1080px (16:9 ratio), 220ppi

Artboard 1.png


Application Grid - 

Application Grid Layout Configuration:

Laid out on a 60px by 60px grid, each application button is 300px (H) by 510px (W), and separated by 15px.

The outer perimeter (interior padding of the outermost dimensions of 1920 by 1080px) of the application grid is 60 px even all the way around, with the option to scroll down further, should there be a need for more than 9 application buttons.

The sidebar space is 240px wide.

11-inch screen - 1920px by 1080px (16:9 ratio), 220ppi



Application Open - 

Application Open Layout Configuration Specifications:

Laid out on a 60px by 60px grid, an open application is 1680px (H) by 1080px (W).

There is no outer perimeter interior padding.

The sidebar space is 240px wide.

Default background application container color:

#d87900, rgb(216, 121, 0), opacity: 100%.

11-inch screen - 1920px by 1080px (16:9 ratio), 220ppi



Sidebar - 

IVI Sidebar:

The GENIVI sidebar contains persistent displays such as the GENIVI logo, the date & time. It also serves as an application grid launcher.



Icons for IVI - 

Unlabeled Icon Containers:

All icons must be backed by a solid color from the GENIVI Style Guide swatch. Icons intended as buttons must be backed by a square or circular container.

 Color Palette for Print:                                                                                                               Color Palette for Screen


Based on a 1920px x 1080px screen, the container minimum is 120px. The container maximum is 175px.    

The min icon size is 60% of its container and the max icon size is 75% its container.


There are instances when an oversized container may be necessary. While the container would exceed 175px, the icon should not exceed a maximum of 130px.

Unlabeled Icon Boundaries:

Min icon size (innermost boundary): 60% of container size  

Max icon size (middle boundary): 75% of container size
Exterior padding (outermost boundary): Approx 60% of container

Icon Variants:

Icons often have contextual variants and require conditional indicators.  

  • Numeric Variants – For numeric variants, a number contained in either a circle (for mechanical increments) or alert-style callout (for human-related increments) is applied to the icon and purposefully exceeds the icon boundaries within its container. The font is Arial and the text size min is 27pt.

  • "Connected" Variants – The universal WiFi icon represents “connected / transmitting / receiving” and should be used as a status variant. When applying it to system icons, its agnostic “point of origin” should be replaced by the icon itself. Both icons should be treated as 1 unit and adhere to the style guide icon sizing. The “transmission wave” symbols should always point upward. In some instances they might be needed as part of an original icon with no variant.


IVI Press Areas - 

Press Area:

The minimum press (touch) area for the In Vehicle Infotainment (IVI) screen is 15mm (height) by 15mm (width), or 120px (2GU) by 120px.

There should be no less than 60px (1 GU) of spacing between press areas.

11-inch screen - 1920px by 1080px (16:9 ratio), 220ppi


GENIVI Alliance Components - 

Button States: 

Buttons communicate the action that will occur when the user touches them. For this style guide, flat buttons shall be the standard.

Use buttons in dialogs and containers, but only mix button types when you have a good reason to, such as emphasizing an important function.

All buttons are flat. Variations include rectangular filled buttons, text-only buttons, or round buttons. They may be used in dialogs, toolbars, or inline. They do not lift, but fill with the active color upon press.

Button text should be capitalized in languages that have capitalization. 


Filled Button

Text Only Button

Round Button


Button Specifications: 

Give buttons with backgrounds a minimum visual size of 90px high by 90px wide. The press area — which is 120px by 120px, or 2GU by 2GU — would extend around the minimum height of a 90px button. 

Press Areas
Filled ButtonText Only ButtonRound Button


Additional button types include:

  • dropdown buttons - display multiple selections

  • toggle buttons - group related options; toggles allow a single choice to be selected or deselected

For more detailed information on buttons, please visit the Google Material Design component page.


Dialogs, also known as modals or pop-ups, inform users about a specific task and may contain critical information, require decisions, or involve multiple tasks. They are a sub-type of modal windows.

Dialogs contain text and UI controls. They retain focus until dismissed or a required action has been taken. Use dialogs sparingly because they are interruptive.

Dialog types include:

  • Alerts

  • Simple menus

  • Confirmation dialogs

Dialogs should not:

  • Appear partially on screen or be obscured, either by other elements or the screen edge

  • Open another dialog from within a dialog

  • Contain scrolling content

Dialog Specifications: 

Dialogs always retain focus until dismissed or a required action has been taken. They may also be dismissed by touching outside of it, or by using a close button located in the upper right hand corner.

Button press area specifications apply to close buttons and text buttons. Text only buttons should align right according to their press area widths and minimum spacing between (60px, or 1GU).

Text within a dialog shall meet the specified requirements for copy.

For more detailed information on dialog boxes, please visit the Google Material Design component page.



A divider is a thin rule/line that groups content in lists, or separates components. They help organize page content and hierarchy into individual tiles. See dividers on the list slide, the menu slide, and the homescreen layout configuration slide.

Full-bleed dividers emphasize separate content areas and sections that require more distinct visual separation.

Full-bleed specs are:

  • 8px thick by the width or height of the screen

  • #d87900 rgb(216, 121, 0), or #cac8c8 rgb(202, 200, 200)

  • Opacity — 100%

List dividers, or inset dividers, are used to separate related content, group content, or in conjunction with anchoring elements such as aligned icons or avatars. These are used as an alternative to spatial separation or subheaders.


List divider specs are:

  • 1px thick by the width or height of the container, or the elements themselves

  • Colors shall be themed in accordance with the application, elements, or icons

  • Opacity — TBD, 20% is suggested

For more detailed information on dividers, please visit the Google Material Design component page.


A list consists of a single continuous column of rows of equal width, which must be vertically aligned. A list usually has a sub-header, and may consist of sets of data types, such as images and text. If the primary distinguishing content consists of images, use a grid list. Lists may contain scrollable content.

Density: like buttons, list line items shall have a minimum press area of 120px in height. List widths may vary, from quarter, to half, to almost full screen width. If a scrollbar in present, it must meet minimum press area width and padding requirements.

Lists can be sorted or filtered by date, size, alphabetical order, or other parameters.

Lists shall have a background that contrasts the font color of #555759. List Sub Head fonts can provide contrast to their background, using an app theme in accordance to the GENIVI color palette.

List Specifications: 

  • The majority of space on a list tile should be dedicated to the primary action

  • Place the most distinguishing content towards the left of the tile

  • In tiles with multi-line content, place the most distinguishing content on the first line

  • Place supplemental actions on the right side

  • Minimum press area and padding widths are applied to separate actions on a tile

  • Extra bottom padding is required for scrollable lists, on the last list item

  • Vertical scrolling only

For more detailed information on lists, please visit the Google Material Design component page. 


Grid Lists: 

A grid list is an alternative to a standard list, and consists of a repeated pattern of cells arrayed in a vertical and horizontal layout. They are best used on similar data types, and help improve the visual comprehension of the content they contain. Grid lists are best suited to presenting homogeneous data, such as images. The application grid layout is a grid list.

There are several types of grid lists:


  • Image only

  • Single-line text

  • Single-line text with icon

Grid list specs:


  • Vertical scrolling only

  • Grid lists must apply the standards for minimum press areas and their surrounding padding minimums; if the visual padding between grid list elements is less than 60px (1GU), then the press area must be smaller than the element itself and retain the minimum padding between cells of 60px.

For more detailed information on grid lists, please visit the Google Material Design component page.


Menus are lists that display choices — with one choice per line, on a transient sheet of material that appears upon interaction with a button, action, or other control. Menus appear above other in-app elements, but should only be used for simple lists with few list items, and only in the most simple of forms. It must contain at least two menu items. Each menu choice consists of a discreet option or action that can affect the app, the view, or selected elements within a view. Menus may be dismissed by tapping outside of a menu, by selecting a menu item, or by following the prompts to accept or dismiss. If there is a system “Back” button this should also cancel the action and close the menu.

Contextual menus dynamically change their available menu items based on the current state of the app. Some list items may appear to be disabled or “grayed out” if the content or action isn’t currently available as a choice. 

Menus should NOT be used in the following ways:

  • As a primary method for navigation within an app

  • Should not be nested in an IVI setting

  • Menus that are positioned right over their elements and include many elements, such as the states of the USA, should be carefully considered prior to including due to the amount of scrolling and distraction. Components or features, such as automatically completing abbreviated words, voice input, or even disabling certain types of inputs while driving should be considered instead of a complex menu

For more detailed information on menus, please visit the Google Material Design component page.


A picker is a simple way to select a single value from a pre-determined set.

Picker varieties include but are not limited to date and time related selections. Past time selections shall not be available.

Actions may include swiping, tapping, or rotating in order to make a selection, with the least number of taps in a dialog box. Care consideration must be applied here in order to present the user with the most natural and least distracting options. Left to right actions may be easier and more precise than vertical, and switching to rotary selections may be too far from the current conventional options to be considered natural. Research and testing may help support some types of actions over others.



Presenting a picker in a less conventional manner, such as a carousel for each selection, might be an easier gesture for a user. In the example here, a horizontal swipe would allow longer and faster swipes with more control. More space is used, but having the visual array of choices may be more useful for particular applications. Choices would ‘snap’ down the center to provide further visual confirmation of selections.

Minimum press areas and padding must be applied, thus limiting available screen real-estate.

For more detailed information on pickers, please visit the Google Material Design component page.


Progress Bars: 

A progress bar is an activity indicator that visually represents content loading. Progress bars can be either linear or circular. The color can be themed, or use an overlay with high contrast colors, such as light grey #cac8c8 and dark grey #555759, or dark blue #00627f and light blue #1e9eb3. Transparency may be desirable in order to see the UI underneath.

There are two types of progress bars:


  • Determinate indicators — display how long an operation will take

  • Indeterminate indicators — visualize an unspecified wait time, and can become determinate as soon as the percentage completed is detectable

For video, visit XXX (move to asset location coming soon....) For more detailed information on progress bars, please visit the Google Material Design component page.

Progress Bar Examples: 

We might recommend that however progress bars are used, whether linear or circular, that it be consistent. Perhaps linear where a user can still interact with the UI, and circular when a delay or halt in standard operations must be paused.




Selection Controls: 

  • Checkboxes — allow the user to select multiple options from a set by providing a boolean interface (on/off) for each option offered, and saves space compared to using on/off switches

  • Radio buttons — allow the user to select one option from a set when a user needs to see all available options side-by-side, but uses more space than a dropdown

  • Switches — toggle the state of a single settings option

The option that is being controlled, as well as the state it’s in, should be made clear from the corresponding inline label. Minimum press areas and padding must be applied.

For more detailed information on selection controls, please visit the Google Material Design component page.


Radio Buttons




A slider allows users to select from a range of values by moving the slider thumb. They’re ideal for adjusting settings that reflect intensity levels such as volume. If a slider indicates values on the ends, the smallest/lowest value shall be to the left of the slider, and the highest/largest value on the right.

There are several varieties of sliders:

  • Continuous sliders — allow users to select a value along a subjective range, and do not require a specific value to make adjustments (though in some cases may offer an editable numeric value)

  • Discrete sliders — allow user to select a specific value from a range, when a user needs to know the exact value. The slider thumb ‘snaps’ to evenly spaced marks along the slider rail

Minimum press areas and padding must be applied.


Continuous Sliders
NormalArtboard 1.png


For more detailed information on sliders, please visit the Google Material Design component page.


A subheader is a list tile that delineates sections of a list or grid list, and may be displayed inline with tiles or associated with content. Subheaders are typically related to filtering or sorting criteria. Upon scrolling, subheaders remain pinned to the top of the screen until pushed off screen by the next subheader.

There are three varieties of subheaders:

  • List subheaders (see example on the list slide)

  • Grid subheaders

  • Menu subheaders

Subheader specs:

  • Left aligned with icon, list text, avatar, or promoted action

  • Use a color other than the list, grid, or menu color to delineate content; colors may be themed with an app’s color palette, as long as it meets appropriate contrast ratios

  • Container height shall be 2 GU, or 120px

  • Upper and lower case, as all caps are reserved for buttons

  • Font size — TBD

 For more detailed information on subheaders, please visit the Google Material Design component page.


A tab makes it easy to explore and switch between different views. Utilizing button states and specifications, tabs enable content organization at a high level, such as switching between views, data sets, or functional aspects of an app. Tabs may encourage lateral navigation within the context of an app.

Present tabs as a single row above their associated content, or along one side, where it is visually appealing within the app layout. Tab labels should be clear and descriptive.

Don’t use tabs for carousels or pagination of content, which involve viewing content, not navigation. Don’t use tabs with swipeable content, because swipe gestures are used for navigating between tabs.

Keep tabs next to their content, rather than stacking them in a column away from the content underneath, or in a row if the content is next to them.

In the context of an IVI, avoid scrollable tabs, which don’t allow muscle memory to develop, or tabs with menus. Menus in addition to tabs would divert more attention away from the road.

Minimum press areas and padding must be applied.

For more detailed information on progress bar indicators, please visit the Google Material Design component page.

Text Fields: 

Text fields allow users to input text, select text, and lookup data via auto-completion.

Text field varieties include:

  • Single-line — automatically scroll their content to the left as the text input cursor reaches the right edge

  • Multi-line — automatically break to a new line for overflow text and scroll vertically when the cursor reaches the lower edge

  • Full-width — useful for more in-depth tasks such as paragraph input; breaks like multi-line text

Available functionality includes:

  • Character counter — use in fields where a character restriction is in place (for example: titles)

  • Auto-complete — present real-time suggestions or completions in dropdowns, so users can enter information more accurately and efficiently

  • Search filter —as a user types, the content underneath is filtered and sorted

  • Required fields — indicate that a field is required by displaying something, like an asterisk () next to the field

  • Password input redaction — disguised by default; midline ellipses are displayed to represent each character of a password entered (such as ••••••)

Text field inputs types include:

  • Numbers — phone number, credit card number, PIN

  • Text — proper name, username, URL

  • Mixed formats — email address, street address, search query

Auto-capitalization: the first letter in each text field, and the first letter of each sentence.

Labels: these should be in sync with the chosen color palette, but provide contrast to the text input fields and the background.

There shall be states for error handling (#c80014), focus, and disabled states for both labels and text-input fields.

Minimum press areas and padding must be applied.

For more detailed information on progress bar indicators, please visit the Google Material Design component page.

Component overview: 


Components with a required minimum press area are displayed with their press area zones.

Press Areas ------ (Image Coming soon)


GENIVI Alliance Copyright - 

Copyright © GENIVI Alliance, Inc. (2016)

This work is licensed under a Creative Commons Attribution-No Derivatives 4.0 International License.

The full license text is available at 

Elements of this GENIVI Alliance document may be subject to third party intellectual property rights, including without limitation, patent, copyright or trademark rights (such a third party may or may not be a member of GENIVI). GENIVI is not responsible and shall not be held responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights.

GENIVI and the GENIVI Logo are trademarks of GENIVI Alliance in the U.S. and/or other countries. Other company, brand and product names referred to in this document may be trademarks that are claimed as the property of their respective owners.

The above notice and this paragraph must be included on all copies of this document that are made.

GENIVI Alliance, Inc.

2400 Camino Ramon, Suite 375

San Ramon, CA 94583, USA


GENIVI Alliance Important Notice - 

GENIVI Alliance, Inc. reserves the right to make corrections, enhancements, improvements and other changes to this guide.

GENIVI is not responsible and shall not be held responsible in any manner for identifying or failing to identify any or all such safety standards and how they are applied. GENIVI assumes no liability for applications or designs that may be produced with assistance from the information in this style guide. Users shall provide adequate design and operating safeguards. Testing and other quality control techniques are recommended prior to use in a moving vehicle.

User acknowledges and agrees that it is solely responsible for compliance with all legal, regulatory and safety-related requirements concerning any information used in this style guide. User represents and agrees that it has all the necessary expertise to create and implement safeguards which anticipate dangerous consequences of failures, monitor failures and their consequences, lessen the likelihood of failures that might cause harm and take appropriate remedial actions. User will fully indemnify GENIVI and its representatives against any damages arising out of the use of any GENIVI information or software in safety-critical applications.

The above notice and this paragraph must be included on all copies of this document that are made.

GENIVI Alliance, Inc.

2400 Camino Ramon, Suite 375

San Ramon, CA 94583, USA 

  • No labels