Hardware requirements for GENIVI-based infotainment systems

Hardware requirements for GENIVI-based infotainment systems

Technology News |
By eeNews Europe

This article looks at some of the technology areas where the marriage between hardware and software is essential to ensure the development of a top-performing GENIVI infotainment system at the right price.

Key requirements from the automotive OEM

The detailed content of GENIVI software releases is far removed from the real-world requirements of automotive OEMs and their tier one implementers. Paramount for the manufacturer are safety, cost, environmental issues, and usability considerations. These, in turn, are dependent on the hardware platform hosting the infotainment software stack. IVI requirements that correlate directly to the underlying hardware might include:

  • A user interface (UI) complying with National Highway Traffic Safety Administration (NHTSA)
  • driver distraction guidelines
  • System start-up times (typically < 200ms for infotainment first audio)
  • Hibernate/stand-by states, persistence, and memory
  • Screen layout, access, and UI ease of use
  • Domain consolidation, virtualization; links to other automotive functions and data feeds
  • ASIL classification; safety and ISO 26262 conformance
  • Real-time data streams: camera, radar feeds, etc.
  • Minimizing cost by maximizing use of multicore system-on-chip (SoC) hardware

These high-level requirements map down to specific hardware peripherals, whether relating to connectivity, HMI, data-storage, or multimedia audio-video processing.

Hardware-dependent performance
Almost every aspect of the infotainment end product requires a good hardware foundation. The table below (Figure 1) covers some of the necessary peripherals and the infotainment features that leverage each peripheral.

Figure 1: Automotive hardware features and impact on the IVI system functionality.

Typical vendor examples supporting many of the above features include platforms such as the Freescale i.MX6 family, Texas Instruments’ Jacinto range of devices, Renesas R-Car H2/M2, and nVidia’s Tegra family. These platforms are often supplied with software board support packages (BSPs) as a starting point, which often need modification or “hardening” to adapt them for use with the infotainment and GENIVI software components they are hosting.

Let’s take a closer look at some of the more interesting technology areas and how GENIVI is working to align itself with these required hardware capabilities. Most semiconductor providers will advertise support for OpenGL /ES (Embedded Systems) with their silicon – a well-established standard for describing on-screen graphical objects. OpenGL ES technology is royalty-free and provides a cross-platform standard for 2D and 3D graphics on embedded systems, and as a result this standard has become widespread. OpenGL ES is a well-defined subset of the desktop OpenGL standard and provides the low-level interface between software and on-chip, hardware-based graphics acceleration.

For infotainment specifically, a protocol called “Wayland” has been defined to provide graphical layer manager services for GENIVI, and is targeted for use with Linux operating systems. Wayland and its reference implementation called “Weston” define the communication protocol between a graphics server and its clients and are already being adopted in production infotainment systems.

In the automotive domain, most HMI systems use their own window manager implementation for the final HMI layer. Many applications such as navigation systems and cameras around the vehicle are implemented as standalone and use a single Linux service to composite all applications into a final image on the screen. These software-layer manager functions allow the end user to switch between different screens, such as navigation, multi-media browser, round-vehicle cameras, and much more. It is important that they are tied back into the available hardware GPU, and this will normally come with dedicated device drivers from companies like Imagination and Vivante.

Electronic control unit (ECU) hardware

All software ends up on some type of ECU in the vehicle. The quantity of in-vehicle ECUs has steadily grown over the past ten years, but is now beginning to level off as interconnection cost and component cost start to counteract functionality. Designers are looking for ways to consolidate functions, and the combination of different and traditionally disparate Linux-based applications (such as climate control, infotainment systems, and instrument clusters) are now becoming attractive. The introduction of semiconductor big.LITTLE ARM architectures allows mismatched performance requirements to be hosted on a single SoC. Performance/power hungry applications such as multimedia players and navigation systems run alongside lighter applications perhaps running a secure AUTOSAR stack or simpler RTOS-based application.

Linking in smart devices

The GENIVI 5.0 release considers the requirement for smart device integration. Drivers, in particular, want to access the information located on mobile smart devices (tablets, cell phones, etc.) to retrieve data such as music playlists, phone records, and favorite apps (Figure 2). An ecosystem of companies and technologies has emerged to allow smart devices to connect to infotainment head units, and in 2011 an alliance called the Car Connectivity Consortium (CCC) was formed. The CCC focuses on both the connection technology and the managing of phone apps that can be remotely managed and executed from the IVI head-unit. The organization now has around 94 members including several major automotive OEMs and smart device manufacturers. The technology used includes Virtual Network Computing (VNC) to manage remote devices using Remote Frame Buffer (RFB) protocols. RFB allows the screen of the smart device to be reproduced as a thin client on the vehicle’s infotainment screen, but the application still runs on the smart device. The solution also allows for audio routing from the smart device through to the vehicle sound system as well as enabling remote user controls such as steering wheel-based control buttons.

Figure 2: MirrorLink technology is used for connecting remote smart devices to a vehicle’s infotainment head unit. (Picture courtesy Car Connectivity Consortium)

Hosting standard platforms

GENIVI Linux is available with a range of standard enabling technologies that help with the many different layers in the infotainment stack. Increasingly, implementers are looking at Qt 5.0 as an HMI technology, with its rich library of widgets available to put together attractive HMIs. The GENIVI specification includes the QtCore engine that enables run-time implementations of Qt designs to execute on standard hardware. For application development, HTML5 is an attractive multi-platform language that can be used to implement screen-based applications and underlying business logic. HTML5 can be supported on GENIVI-compliant Linux distributions using technologies such as Chromium WebKit. The W3C organization is helping with the further evolution of HTML5 going forward and changes are being closely tracked by the upcoming GENIVI specifications. HTML5 shows great promise in IVI systems moving forward.

In the area of in-vehicle networking, Ethernet and a specific variant for audio-video applications are beginning to appear as replacements for existing MOST-based buses. These networks use a set of protocols that are being developed by the IEEE 802.1 Audio/Video Bridging (AVB) Task Group (Figure 3). There are four primary differences between the AVB architecture and existing 802.11 Ethernet architectures; for example, precise sound and video synchronization (nobody wants to watch a movie with an out of sync sound track). The extensions also cover the ability to screen out or ignore certain network devices – important on a mixed, in-vehicle network. In the vehicle there may be several AVB domains covering camera feeds, rear-screen entertainment, and navigation information, for example.

Figure 3: Audio/Video Bridging (AVB) multimedia network example with non-AVB domains.

Separating hardware

Some car makers and designers plan to keep ECU functions physically separate, for reasons relating to safety, supply chain, or even positioning within the vehicle. In infotainment, there may be units connected to the existing vehicle bus (CAN, Lin, Flexray based) to manage, for example, audio; but these will also need input from the infotainment head unit. New protocols are emerging in the vehicle to allow secure communication between these different hardware subsystems. GENIVI has working groups looking at the Franca IDL framework, an interface description language that will allow different subsystems to communicate with each other.

In the future, designers will have the opportunity to consolidate some of these functions using virtualization, combining multiple different subsystems on a single SoC platform. Embedded software hypervisors provide the resource management and security necessary to successfully manage multiple different domains and reduce the overall number of ECUs needed.


Automotive OEMs are starting to rely on proven innovations through software such as the GENIVI platform. But equally important is having hardware that can support the software functionality in a usable way. Looking ahead, software designers can expect more software development around heads-up display units, gesture recognition, and speech recognition, as well as more robust vehicle-to-vehicle (V2V) and vehicle-to-cloud (V2C) connections. Matching reliable, high-performance hardware platforms with the right integration layers at an affordable price will be a critical part of the puzzle as IVI technology continues to evolve and gain wider acceptance.

About the author: Andrew Patterson is a business development director for the Mentor Graphics Embedded Software Division, specializing in the automotive market, and involved in solutions for Infotainment, Instrument Cluster and AUTOSAR-based ECUs. Prior to Mentor, Andrew spent over 25 years in the design automation market specializing in a wide range of technologies, automotive simulation model development, virtual prototyping, and mechatronics. Andrew holds a Masters degree in Electronic Engineering and Electrical Sciences from Cambridge University, UK.

This article by courtesy of Embedded World

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News


Linked Articles