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.
Linking in smart devices
The GENIVI 5.0 release considers therequirement for smart device integration. Drivers, in particular, wantto access the information located on mobile smart devices (tablets, cellphones, etc.) to retrieve data such as music playlists, phone records,and favorite apps (Figure 2 ). An ecosystem of companies andtechnologies has emerged to allow smart devices to connect toinfotainment head units, and in 2011 an alliance called the CarConnectivity Consortium (CCC) was formed. The CCC focuses on both theconnection technology and the managing of phone apps that can beremotely managed and executed from the IVI head-unit. The organizationnow has around 94 members including several major automotive OEMs andsmart device manufacturers. The technology used includes Virtual NetworkComputing (VNC) to manage remote devices using Remote Frame Buffer(RFB) protocols. RFB allows the screen of the smart device to bereproduced as a thin client on the vehicle’s infotainment screen, butthe application still runs on the smart device. The solution also allowsfor audio routing from the smart device through to the vehicle soundsystem as well as enabling remote user controls such as steeringwheel-based control buttons.
Figure2: MirrorLink technology is used for connecting remote smart devices toa vehicle’s infotainment head unit. (Picture courtesy Car ConnectivityConsortium)
Hosting standard platforms
GENIVILinux is available with a range of standard enabling technologies thathelp 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 attractiveHMIs. The GENIVI specification includes the QtCore engine that enablesrun-time implementations of Qt designs to execute on standard hardware.For application development, HTML5 is an attractive multi-platformlanguage that can be used to implement screen-based applications andunderlying business logic. HTML5 can be supported on GENIVI-compliantLinux distributions using technologies such as Chromium WebKit. The W3Corganization is helping with the further evolution of HTML5 goingforward and changes are being closely tracked by the upcoming GENIVIspecifications. HTML5 shows great promise in IVI systems moving forward.
Inthe area of in-vehicle networking, Ethernet and a specific variant foraudio-video applications are beginning to appear as replacements forexisting MOST-based buses. These networks use a set of protocols thatare being developed by the IEEE 802.1 Audio/Video Bridging (AVB) TaskGroup (Figure 3 ). There are four primary differences between theAVB architecture and existing 802.11 Ethernet architectures; forexample, precise sound and video synchronization (nobody wants to watch amovie with an out of sync sound track). The extensions also cover theability to screen out or ignore certain network devices – important on amixed, in-vehicle network. In the vehicle there may be several AVBdomains covering camera feeds, rear-screen entertainment, and navigationinformation, for example.
Somecar makers and designers plan to keep ECU functions physicallyseparate, for reasons relating to safety, supply chain, or evenpositioning within the vehicle. In infotainment, there may be unitsconnected to the existing vehicle bus (CAN, Lin, Flexray based) tomanage, for example, audio; but these will also need input from theinfotainment head unit. New protocols are emerging in the vehicle toallow secure communication between these different hardware subsystems.GENIVI has working groups looking at the Franca IDL framework, aninterface description language that will allow different subsystems tocommunicate with each other.
In the future, designers will havethe opportunity to consolidate some of these functions usingvirtualization, combining multiple different subsystems on a single SoCplatform. Embedded software hypervisors provide the resource managementand security necessary to successfully manage multiple different domainsand reduce the overall number of ECUs needed.
AutomotiveOEMs are starting to rely on proven innovations through software suchas the GENIVI platform. But equally important is having hardware thatcan support the software functionality in a usable way. Looking ahead,software designers can expect more software development around heads-updisplay units, gesture recognition, and speech recognition, as well asmore robust vehicle-to-vehicle (V2V) and vehicle-to-cloud (V2C)connections. Matching reliable, high-performance hardware platforms withthe right integration layers at an affordable price will be a criticalpart of the puzzle as IVI technology continues to evolve and gain wideracceptance.
Andrew Patterson is a business developmentdirector for the Mentor Graphics Embedded Software Division,specializing in the automotive market, and involved in solutions forInfotainment, Instrument Cluster and AUTOSAR-based ECUs. Prior toMentor, Andrew spent over 25 years in the design automation marketspecializing in a wide range of technologies, automotive simulationmodel development, virtual prototyping, and mechatronics. Andrew holds aMasters degree in Electronic Engineering and Electrical Sciences fromCambridge University, UK.