In-Vehicle Infotainment is a term that defines the entertainment and informative applications that are made available in automobiles. IVI allows display screens in cars and hence, the driver, access to maps, GPS, media players, electronic dashboards, engine diagnostics, internet and social networking, and integration with handheld devices, and are the new generation of infotainment in automobile development today.
The current generation of In-Vehicle Infotainment can give you accurate engine diagnostics, in the event of a car breakdown, and can direct you to the nearest service station to report the problem. Things like remote ignition give you the option of warming up the car’s engine before you actually get into the car.
Going by the rate of development in IVI, the future of the automobile industry lies with the intelligent car. It would come as no surprise, in the not-so-distant future, when your car plays a role very similar to a personal assistant. A couple of years from now, it would be wrong not to expect your car to give you suggestions about preparing for the weather, send e-mails, schedule meetings, give you reminders, etc, some of which are features already being worked on while you read this.
The following are some of the challenges faced during the design and development of modern IVI solutions.
Ensuring fast Boot-up
The issue of boot-up time can be a major decision maker when it comes to IVI. The average boot-up time for IVI on the MeeGo platform was approximately 15 seconds. Imagine switching off your engine at a signal and attempting to restart when the signal turns green. An almost-zero delay is preferred, where the instrument cluster becomes functional in less than one second.
While Real-Time Operating Systems [RTOS] are capable of fast boot-up, but a full-fledged Linux OS like MeeGo needs customization to reduce the boot-up time. There are solutions that run a full-fledged Linux OS along with an RTOS which is capable of a fast boot-up to solve this issue for designers, but the designer has to ensure that all the hardware diagnostics are done to ensure smooth operation.
Efficient CPU Usage
Instrument Clusters should be able to acquire information from the various sensors on the automobile and render the data immediately on the display without any delay. High-quality graphics require a high amount of CPU usage and processing, unless there’s a dedicated GPU available to crunch those numbers. Multi-threaded applications require an advanced CPU with multi-core architecture that can handle IVI applications efficiently.
Multiple displays in IVI prove to be a better option for displaying information of several types. For example, the front display shows the instrument cluster, while a movie plays on the left-rear display, and music plays on the right-rear display.
The ability to run numerous applications on a central device and handle multiple displays requires lot of processing, and an efficient graphics processor capable of handling high amounts of rendering. Many IVI-customized boards provide outstanding graphics processing and drivers capable of such operations.
Design Considerations in IVI
IVI solutions, still being in a nascent phase, face considerable drawbacks in mass production. Listed below are some of the key design considerations.
Time to Market
Every automotive manufacturer’s concern in developing an instrument cluster is to be able to provide a solution that matches the specifications of the car, and meets the expectation of the driver. Car manufacturers that have migrated to the use of digital displays can benefit from the technology innovations available in both IVI hardware and software. These solutions facilitate the customization of instrument clusters for various models of cars without causing delays in the designing of customized dashboards.
While developing custom solutions, reusability is given very less consideration. If base components are reusable, then porting it to new designs, platforms and subsequent revisions become possible. Reusability was not considered as a key aspect in software design primarily because hardware and midlevel software platforms did not follow any specific standards, and varied mostly due to technological differences and cost factors. Aiming to make all base components reusable reduces cost and time-to-market of solutions for OEMs.
The high rate of advancements in technology makes it important to develop solutions that can be extensible. The advancements/upgrades, while adding value, must be capable of being incorporated into existing products and solutions. Constraints in hardware/software may not always allow this to be possible. Creating an entirely new system just to add minor technological improvements is not a workable solution. Solutions must always be extensible for improvement and must be able to include new features and technologies.