Rapid development and reusable design for the connected car

The connected car places a myriad of new possibilities at the disposal of automobile manufacturers. These new possibilities are not without their challenges, however. Specifically, manufacturers will have to ensure that new applications and upgrades can be easily incorporated into existing systems. They will also have to implement version controls, so that users (or the manufacturers themselves) will be able to roll back in-vehicle technologies to older releases if desired or required. Similarly, manufacturers will need to manage provisioning (based, for example, on Vehicle Identification Number) so that users download only applications and upgrades designated for their vehicles, and which their in-vehicle systems support.

Finally, manufacturers will have to guarantee that the continuous changes to in-vehicle systems made possible by the connected car will not cause problems with existing applications and functionality. It would be unfortunate if, for example, during a cross-country vacation trip, a car owner downloaded a new navigation application only to find that it starved his media player. A minor annoyance for the driver would reflect badly on the vehicle line as a whole.

The first part of the solution to these challenges is the same as the solution to the needs of rapid HMI development, rebranding and customization: a framework that separates the HMI from the underlying technologies. The second part of the solution is to separate available resources so that new applications can run, while guaranteeing resources to essential processes across the system.

The QNX CAR framework and PPS

Persistent Publish/Subscribe
PPS is an object-based service with publishers and subscribers in a loosely-coupled messaging architecture.¹ Any PPS client to the service can be a publisher only, a subscriber only, or both a publisher and a subscriber, as required by the implementation.

Publishers and subscribers only need to be able to read and write objects and their attributes in the PPS filesystem pathname space. Subscribers must of course know what objects and attributes interest them, and publishers must know what objects and attributes may interest subscribers, but neither publisher nor subscriber needs to know anything more about other parts of the system. Objects are written to permanent storage, offering persistence across reboots.

We implemented PPS to handle messaging between Adobe Flash applications and all data source publisher components; that is, for Webkit (browser), Bluetooth, GPS, audio volume control, etc. Chief among the advantages offered by the PPS messaging model is that the API between the components is consistent and loosely coupled.

Just as PPS allows us to redesign our HMI without touching the underlying applications, it allows us to add new components — vehicle telematics or ITS awareness, for instance — to our QNX CAR implementation without the time-consuming development usually required with other messaging paradigms. All that is needed is that all parties know what they need to publish, and what they need to read in from PPS. Further, this architecture ensures that other components do not require changes to accommodate new additions — changes which, as every software developer knows, at best require exhaustive testing, at worst introduce errors.

PPS thus provides us with a messaging model that allows us to add new components to our in-vehicle system with minimal effort beyond the HMI work required so that users can use the new capabilties offered.

Resource separation

Secondary Flash player
To ensure that a newly introduced application does not introduce problems to our system, we chose to implement a secondary Adobe Flash player. The player is reserved for untrusted applications; that is, for applications that we have not confirmed will run cleanly without adverse effects on the reliability and performance of other applications, or of the system as whole.

Like all Flash players, this secondary player runs in its own virtual machine environment, and hence can be neatly separated from the rest of the system. Applications in this secondary player’s virtual machine environment can not deprive applications in the primary player or other components in the system of the resources they require.

This simple approach allows us to try virtually any Flash application we choose, without worrying that it might bring down the system. In fact, any developer could write an application and run it on this secondary player without danger. He could use adaptive partitioning to ensure that the secondary Flash player did not interfere with applications in the primary Flash player, and that the applications this secondary player ran would not starve the system.

¹ For a more detailed description of QNX PPS, see Ben VandenBelt, "Persistent Publish/Subscribe for Embedded Industrial Applications". QNX Software Systems, 2010. www.qnx.com.