Persistent asynchronous messaging for HTML5 automotive 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.
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.
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).
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.
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 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:
* C/C++ programs interface directly with the vehicle hardware, and read and write relevant PPS objects.
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.