Hardware requirements for GENIVI-based infotainment systems
The GENIVI 5.0 specification will be published in late 2013. With each new specification release, GENIVI’s open source base platform becomes more functional and usable by implementers of in-vehicle infotainment (IVI) systems. However, the final performance of any GENIVI IVI system is dependent on the underlying hardware and the corresponding peripheral components available to the designer. To get the best possible performance the software needs to be specified with the hardware peripherals in mind. To this end, major semiconductor suppliers are now converging on the must-have range of features for vehicle infotainment systems.
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.
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.
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.