Persistent asynchronous messaging for HTML5 automotive HMIs

Automotive infotainment systems integrate many devices and services, and pressures such as release schedules, budgets and re-usability requirements make human machine interface (HMI) development in native C/C++ code expensive and time-consuming. HTML5 and its ancillary technologies (CSS3, JavaScript, AJAX, JSON, etc.) offer a non-proprietary solution for building rich, device-agnostic HMIs.

Unfortunately, HTML5 doesn’t offer a simple solution for communicating between the HMI and low-level components. Persistent Publish/Subscribe can be used for this communication. It is a light-weight, open messaging model that:

* bridges the gap between the HTML5 layer and low-level components

* expands to include new devices and technologies

* accommodates applications using different HMI technologies, such as Elektrobit GUIDE, Qt, and OpenGL ES.

Persistent publish/subsribe

The QNX implementation of PPS is an object-based service with publishers and subscribers in a loosely coupled messaging architecture. Any PPS client can be a publisher, a subscriber, or both a publisher and subscriber. (*See Figure 1)

PPS objects are integrated into the file system pathname space, and publishing is asynchronous. Publishers modify objects and their attributes, and write them to the file system. When a publisher changes an object, the PPS service informs clients subscribed to the object. PPS clients can subscribe to multiple objects, and PPS objects can have multiple publishers and subscribers. Thus, publishers can use one object to communicate information to all that object’s subscribers.

PPS clients must know which PPS objects are of interest. If they are publishers, they must know what to publish and when; if they are subscribers, they must know to which objects they must subscribe, and which object attributes interest them. PPS clients need to manage buffers and errors only when making open(), read() and write() POSIX API calls, when determining if their reads should be blocking or non-blocking, and when confirming that they understand what they read.

PPS leverages the services of standard POSIX file systems, so it works with any programming language or application environment. A component written in one language can communicate with components written in another language. No special knowledge of the other components is needed.

Persistence

A Persistent Publish/Subscribe service can maintain data across reboots. Persistence is determined by the designer, who sets this characteristic for individual attributes.

When PPS is running it maintains its objects in memory, but saves persistent objects to storage, either on demand or at shutdown. It restores them on startup, either immediately or on first access. The underlying persistent storage requires a file system and storage media (hard disk, NAND or NOR flash).

PPS can simplify startups. With many messaging models, if a client comes up after the server, or loses contact at any time, it needs a data update, in case something changed. With PPS, however, the service restores its persistent objects on startup, then maintains them. When a client starts or reconnects, it gets current data just by reading these objects. (See Figure 2).

System Scalability

With PPS, the only connection between publisher and subscriber is an object, so if necessary designers can delay decisions on module connection points and data flow until runtime. These decisions are neither hardcoded nor directly linked, and can be adapted as requirements evolve—or even change dynamically as the system runs.

PPS also simplifies integration of new components. Since publisher and subscriber don’t have to know each other, developers need only to decide what data new components should publish, and what data they need from other PPS clients. No API fine-tuning of APIs is required, and system complexity doesn’t increase.

PPS Implementation

The QNX CAR platform offers an ideal use-case for PPS. Key capabilities of this application platform include:

* HMI: HTML5-based

* Information and entertainment: multimedia, radio, internet radio, weather reporting, support for phone- and home-based media

* Automotive interfaces: climate control and virtual mechanic

* Navigation, handsfree, speech, social networking

(*See Figure 3).

The QNX CAR platform supports a variety of applications as well as a range of low-level software components connected directly to hardware devices. It thus requires a simple and scalable messaging model to handle communications between many disparate components.

The HMI for the platform uses HTML5 with a JavaScript framework that includes the Sencha and jQuery JavaScript libraries. The system architecture is designed to support easy integration of other HMI technologies such as Qt, Adobe AIR, and Elektrobit GUIDE. The HTML5 and Cascading Style Sheets (specifically, CSS3) facilitate migration of applications to and from the in-vehicle system and mobile devices (smartphones and tablets).

The PPS messaging handles communications between most system components and the HMI. Since PPS messaging is technology- and language-agnostic, only a small number of APIs is needed to provide the interfaces between the HMI and the underlying components. Specifically:

* a PPS API handles communications between the HMI and the PPS service

* an SQL API interfaces with local media databases

* UI core APIs handle communications between the HTML5 layer and a user-interface core component, and between this component and other HMI technologies.

(*See Figure 4)

In summary, the HMI-hardware communication works as follows:

* JavaScript wrapper classes and JNEXT handle HMI-hardware communication.

* C/C++ programs interface directly with the vehicle hardware, and read and write relevant PPS objects.

* To access this information from the HMI, JavaScript in the HMI calls a JavaScript wrapper class to communicate with a JavaScript PPS class, which exposes a natural class-based JavaScript API to other callers.

* Internally, the wrapper makes calls to an instance of a PPS class, which uses JNEXT to allow the JavaScript to call into the native code, and read and write relevant PPS objects. (*See Figure 5).

Conclusion

HTML5 is fast becoming not just a popular HMI technology, but a viable environment for delivering rich, flexible user interfaces. Our experience has shown us that HTML is no longer just the standard for presenting web content, but an HMI technology for all sorts of applications—connected and not connected, using browser-based or HTML5 engine-only environments. We have also seen how a PPS messaging model facilitates communication between the many software components, technologies and devices. Equally important, PPS enables a flexible architecture that requires relatively little work to integrate new devices and technologies.