We have covered RIMâ€™s QNX Automotive group quite a few times especially as RIM presents BlackBerry 10 as a mobile platform solution beyond the mobile space. We can all understand how apps are helpful in mobile products. But how can automotive apps help us and and how do they differ from those in the mobile space? That is exactly what QNX Auto is doing with the QNX platform and BlackBerry 10 in the future.
QNX, the company which was acquired by RIM in 2010 and whose operating system is the basis for BlackBerry 10â€™s OS, set out to answer these questions in a webinar entitled â€œUnderstanding Mobile Apps for Automotiveâ€ which they presented earlier this month. Automotive Product Marketing Manager Andy Gryc led the webinar and attempted to explain how developers could get their mobile apps into the car.
One important thing to realize, according to Gryc, is the differences in requirement for mobile apps when compared with apps for cars. In mobile, production time and life-cycle time are both very short â€“ possibly as short as a few months. In vehicle electronics, on the other hand, production time can take years. This is not due to incompetence on the part of car manufacturers, but due to the very nature of the automobile: When dealing with a product, like a car, which is very expensive and which has a great potential for danger, great care has to be taken when designing the apps and the infotainment system.
The biggest concern of all with mobile apps is driver distraction. Obviously, itâ€™s everybodyâ€™s concern if drivers are focusing their attention (not to mention their eyes) on infotainment and not on the road. Because of this, apps should be designed differently for the automotive space. For example, animation in apps, which can be cool in a mobile unit, can be deadly in a car and should obviously be kept to a minimum.
However, looking at car infotainment systems as an evil which should be contained is only looking at half of the picture. Various technologies, some of which exist today and some of which are not too far off in the future, can actually help keep eyes on the road. For example, voice recognition technology which can dial phone numbers â€“ and which could one day post statuses to Facebook â€“ can play a big role in keeping drivers from taking their hands off the wheel and their eyes off the road.
Some of Grycâ€™s talking points, though not necessarily directly relevant to developers, were interesting in and of themselves. One of these concerned the necessity of relegating apps to sandboxes so as to allow the vital car infotainment features (i.e. navigation) to operate even when other applications crash. Another was the importance of â€œfast bootâ€ â€“ having the infotainment system power up quickly. This is necessary because, as Gryc put it, people donâ€™t want to have to plug their cars in and have them charge all night. Due to that, the entire infotainment system is generally turned off along with the car, and the ability to boot quickly becomes most important.
Bringing the mobile app into the car might not be as simple as it sounds. Because of the nearly unlimited warranties commonly found on cars, customers expect to be able to have their cars serviced at the dealer and expect the dealer to fix or replace the defective parts. So dealerships have to have the parts to fix the infotainment systems even ten years after the car is purchased.
Also, as mentioned earlier driver distraction is a big concern. Conginzant of that, Gryc gave some distraction avoidance guidelines for developers. Some of these were suggestions that developers should: limit the amount of time required for offroad glances (to 2 seconds or less); use speech recognition technologies when possible; minimize total task duration to 15 seconds; Â keep apps predictable and consistent (i.e. shifting menus should certainly be avoided); and last but not least, make applications ignorable (in case you really have to pay attention to the road).
With regard to how to developers can get their existing mobile apps into a car, there are a few different options. Â Mirrorlink (which used to be called Terminal Mode) is an existing standard which can take a phone app and adapt it into an app for a car. Another possibility is using a QNX CAR based platform. Discussing that angle,Â Gryc stated that in the near future they hope to have a QNX CAR SDK with Webworks and Ripple that will allow applications in HTML5 to be deployed in various devices.
The automotive space, while intriguing, has its own challenges and should not be treated by app-developers as though it were just another mobile platform. Driver distraction is an issue that must be dealt with and even putting existing apps into the infotainment systems is not necessarily that simple. But whatever obstacles there may be, thereâ€™s no question that the automotive space can provide an alluring opportunity to motivated developers.