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.
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.
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.
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.