Multiscreen Challenges and Opportunities for Vehicle Designers

Adopting automotive UI technologies with agility.

Drivers and passengers expect to connect and synchronize their own mobile devices to in-car systems and access them from the dashboard as well as to make comfort adjustments within the vehicle just as easily using their smartphones and tablets. While devices may run various operating systems and versions, users expect the experience of using these devices within the vehicle to be seamless.

At the same time that this user expectation of seamlessness is becoming the norm, the car is becoming an IT platform in which the in-vehicle systems expose Application Programming Interfaces (APIs) to third-party devices that allow the development of additional services without the direct involvement of the car OEM (Figure 1). These trends generate significant challenges.

Figure 1: In-vehicle systems expose APIs to third-party devices.

Even when an OEM has control of a single compute platform, such as the embedded microcontroller in a dashboard display, modifications to the application to take advantage of new user interface (UI) techniques can involve considerable rework at the API level. When making changes to suit a new look-and-feel, developers have to ensure that each successive update does not impact performance or introduce faults. This problem becomes far more complex when the OEM has to consider interaction with myriad different user devices.

Abstraction as the Answer

What is needed is some way to abstract the details of the underlying operating system to allow a single codebase to run across multiple targets. Attempts have been made to provide cross-platform portability for applications on the desktop at the language level, but they have limitations. Java, for example, has broad support, but most implementations fail to adapt to the specific requirements of individual devices along with introducing performance overhead through a virtual machine.

The broad adoption of web-enabled apps and online content offers one possibility: using web technologies, such as the HTML5 that consists of HyperText Markup Language (HTML), Cascading StyleSheet (CSS) version 3 and different JavaScript based script programs. HTML5 makes it possible to deploy rich media applications on any mobile platform that has full, consistent support for the standard. But HTML5 has some key drawbacks. For example, HTML5 as such isn’t designed for effective UI design. What’s more, web browsers are still inconsistent in their rendering of HTML5, and the performance is difficult to get to the level of native systems. In automotive systems, there is no room for any performance overhead.

HTML5’s approach is, however, attractive, particularly for multiscreen applications as the technology would be usable on web browsers as well. HTML5 applications segregate the core business logic from the user interface. Changes in interfaces can be represented by the use of different presentation layers that reflect the differences in target screen or platform, from the size of the display through to the types of interaction that it supports. In this way, a presentation layer developed for one operating system can be treated differently from that needed for a smartphone, for instance. The HTML5 methodology also emphasizes responsive web design targeting an optimal viewing experience for a certain screen size by just designing one flexible presentation.


If well-designed techniques are used, the two layers can communicate seamlessly with each other and provide the event-driven responsiveness that users now expect from user interfaces. What is required is an applications framework that not only supports the separation of business logic from presentation, but also streamlines tuning the user interface to each target device. The goal is not to use the same code across all targets but rather to maximize the amount of common code while still supporting responsive user interfaces.

For example, although each target operating system will expose networking services in its own way, a high-level applications framework can hide those differences through the use of common services. The same API can be offered across supported target platforms and similar APIs extend to cloud services and access to databases as well as to common connected-device functionality such as cameras and GPS-based location services. A good architectural design allows direct access and easy integration to the native services of the system, such as the automotive buses and controls, but is careful not to couple these too tightly—possible defects in the UI must not affect any of the underlying systems.


Figure 2: A cross-platform framework such as Qt enables taking a technical approach forward to true multiscreen approaches where the same service or application is used everywhere: the user’s home computer, tablet, car and his smartphone. Even though the same code works as-is across platforms Qt internally separates the declarative UI design from the imperative UI logic.

Application frameworks have been employed on desktop applications, often using a widget-centric infrastructure. Traditionally, these techniques employ callbacks, which are pointers to C or C++ functions. When a UI event occurs, the callback uses the pointer to notify the function of a change. There are two problems with this approach. First, the programmer has to ensure that the callback is made using the right argument, which complicates maintenance and can lead to errors being introduced as the UI is changed. Second, the technique calls for the interface and business-logic code to be tightly connected as each callback needs to know exactly which function to access.

Dodging a Maintenance Headache

Now coming onto the market are high-level applications frameworks, such as that offered by The Qt Company, which take a more flexible approach to signalling across the logic-interface boundary (Figure 2). This can be achieved using a “signals and slots” mechanism. Under this paradigm, functions register their interest in signals by adding themselves to slots. A signal can be connected to more than one slot, making the system more flexible than callbacks. And the technique is type-safe, eliminating one of the biggest maintenance headaches of using callbacks.


Figure 3: Although each target device and operating system will expose networking services in its own way, a high-level application framework makes those differences transparent through the use of common services. Such a framework makes it possible to re-use the same technology and even code directly for multiple screens. In addition, the framework can be used to expose an API for additional software services, making the Automotive IVI a platform itself.

Using those slots, signals of interest pass along to any interested function so, for example, a mapping application can check GPS position, and a separate weather application can use the same course and position data to check for possible road-condition problems ahead. The same business logic works whether the client runs in the dashboard environment or in an app developed by a car OEM for a smartphone (Figure 3).

By paying careful attention to software architecture and by embracing the concept of a portable multiscreen-oriented software framework, many of the challenges designers of automotive dashboard and infotainment confront can be eased. A move towards framework-based development enables car manufacturers to become more agile in their adoption of user-interface technologies while preserving the carefully planned and documented software that these applications require.


headshotTuukka Ahoniemi is a technical product marketing manager at The Qt Company. He holds an M.Sc. (tech) in Computer Sciences and is based in Tampere, Finland.

Share and Enjoy:
  • Facebook
  • Google
  • TwitThis