Rapid development and reusable design for the connected car

One system, many vehicle models
Unlike wheel rims, which can be shared only by similar vehicles, a single software system may well be appropriate for every model, from sub-compacts to trucks. Buyers considering a sub-compact and buyers considering a pickup truck may want pretty much the same functionality from their in-vehicle systems. The catch, though, is that these buyers will almost certainly respond positively to very different HMI designs — their "look and feel" — and that more than a simple change of hubcap is usually required to rebrand a user interface to align it with a vehicle model’s design and market appeal. In fact, extensive HMI design work is probably required for each model.

Figure 2: The QNX CAR architecture separates the Adobe Flash HMI from the underlying RTOS and services. Graphic designers and user interface developers can brand and implement a different HMI for every vehicle line and model, in as many languages as they need, without changing a line of code outside the HMI. A second Flash player is available to run untrusted applications.

Further, though HMI fashion does not change with every season, user interface designs do nonetheless become dated rather quickly. Who does not remember the embossed lettering so common of web sites in the mid 1990s?

After the initial investment to create distinctive branding for every vehicle line, further work will be required every year to bring HMI designs up to date in alignment with new vehicle models. These requirements: unique branding for every vehicle model, and regular updates to the look and feel for each model, underline the importance of an architecture that minimizes the work and the risks involved with changing an invehicle HMI.

When choosing a software system to support in-vehicle connected systems, it is important, therefore, to consider how easily the HMI can be branded and customized for use across vehicle lines, then updated and revised in the future.

A well-designed system should facilitate this sort of HMI-level work, and ensure that it does not imply changes to the underlying functionality. In short, the system architecture should permit HMI developers to design and build as many different HMIs as are required, and this development should have no impact on any part of the system below the HMI.

Choosing an HMI development community
To mitigate the costs of HMI design, projects should consider using a technology that is both appropriate for in-vehicle systems, and supported by a large and experienced developer community. This technology should be an automotive-quality technology proven in embedded environments and backed by a mature community.

The correct technology choice ensures that projects will be able to focus on building the user interfaces that will distinguish their vehicle lines, rather than struggling to find workarounds to compensate for unexpected behaviors. A mature developer community provides a large talent pool that projects can draw upon when staffing their HMI design and development teams, and it allows projects to benefit from the deep knowledge and experience of the development community as a whole.

Adobe Flash Lite
Our experience with the QNX CAR (Connected Automobile Reference) project has shown us that these requirements can be met by building an HMI framework that uses Adobe Flash Lite (Adobe Flash for embedded applications) for the HMI, along with a small set of Flash Action Script Extensions (ASE) that allow Flash code to interface directly with native C/C++ code. These extensions provide all the required interfaces to various services: the QNX Persistent Publish/Subscribe service (PPS), the QNX Aviage Multimedia Suite, and the QNX database server (QDB).

As well as using a technology supported by the large community of Web developers and HMI designers accustomed to working in Flash, this strategy allowed us to employ an architecture that neatly separates the HMI from the underlying components: Webkit (browser), Bluetooth, GPS, audio control, and the multimedia suite. HMI designers create and implement any number of customized user interfaces to meet corporate branding requirements and vehicle model needs. Designers can achieve coherence with overall vehicle aesthetics, and even offer buyers a selection of designs without concern about any adverse effects on functionality, as no changes are required to the underlying components.

Figure 3: In QNX CAR, the Adobe Flash-based user interface uses PPS to communicate with underlying services and the QNX Neutrino RTOS. The HMI can be changed without any code changes below the HMI.