Connected vehicles and future technologies
The connected car is a good part of the solution to the problem of implementing new and future consumer technologies in vehicles. As well as offering vehicle buyers a host of new features, from infotainment systems to integration with Intelligent Transport Systems, connected car technology will enable vehicle owners to download new applications they want to add to their systems. It will also enable manufacturers to push new applications and upgrades out to their vehicles.
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
In QNX CAR we created a framework that separates the Adobe Flash HMI from the underlying applications and created a small set of ActionScript extensions to interface between the two. We created an extension for our PPS service, one for the QNX Aviage Multimedia Suite, and one for QDB, the QNX database server.
PPS is an object-based service with publishers and subscribers in a loosely-coupled messaging architecture.1 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.
The technologies we chose for QNX CAR offer two techniques (beyond standard process and memory protection) for managing the impact of new applications on an in-vehicle system. First, the Adobe Flash-based HMI allows us to run a secondary Flash player whose virtual machine serves as a "sandbox" for running untrusted applications. Second, the QNX Neutrino RTOS offers adaptive partitioning, a unique technology that dynamically offers unused CPU time to processes that need it, but guarantees resources to critical processes.
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.
1 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.