PPS messaging connects HTML5 and hardware

Andy Gryc, QNX Software Systems

May 17, 2012

Andy Gryc, QNX Software Systems

Human-Machine Interfaces (HMIs) developed with HTML5 reside in a high-level, virtualized environment, and they work well in this environment. This fact does not preclude their needing to access hardware, however. In mobile devices, for example, they need to retrieve the device orientation and, if there are GPS or accelerometer chips, information these chips provide for applications that use geo-location. In-vehicle systems need to retrieve even more information from low-level components such as the CAN bus, GPIO pins, and I2C and SPI devices.

Writing specific interfaces to communicate between the HMI and each low-level service is a costly—and likely unsustainable—proposal. A better approach is to use an HMI-agnostic, asynchronous messaging model such as Persistent Publish/Subscribe (PPS). A service for pushing out changes and receiving notifications, PPS provides a simple and effective way for the HMI to communicate with low-level components and the vehicle hardware.

The problem
A problem facing developers of almost all but the simplest systems is the increasing diversity and complexity of components at all levels. On the one hand, an automotive infotainment system integrate many devices and services—from multimedia players to virtual mechanics; on the other, pressures such as release schedules, budgets, and re-usability needs have made HMI development in native C/C++ code prohibitively expensive and too time-consuming.

HTML5 and its ancillary technologies (CSS3, JavaScript, AJAX, JSON, etc.) offer an excellent, non-proprietary solution for building rich, device-agnostic HMIs. Unfortunately, like other high-level HMI technologies, HTML5 doesn't offer a simple solution for communicating between the HMI layer and the many low-level components found in today's systems.

With HTML5 becoming the HMI technology of choice, the problem facing system architects, then, is finding or devising a light-weight messaging model that bridges the gap between the HTML5 layer and disparate low-level components. Further, because: A) many systems must be able to expand to include new devices and technologies, and B) many HMIs must accommodate applications using different HMI technologies, such as Elektrobit GUIDE and Qt, this messaging model must be open. That is, it must be able to integrate these new components and technologies, easily and efficiently.
 
To read the complete article, which gives details on how object-based PPS works, system scalability, and a car-application architecture, click here, courtesy of EE Times Europe Automotive.

To receive a weekly highlights update delivered directly to your inbox by signing up for our weekly automotive electronics newsletter here.