Frankenstein and the future networked car

So what do Frankenstein and the future networked car have in common, you ask? Simple: both are compelling stories brought to life in Geneva, Switzerland.

In Mary Shelley’s Frankenstein the creature is seen climbing Mont-Salève after having fled Geneva during a lightning storm:

“I thought of pursuing the devil; but it would have been in vain, for another flash discovered him to me hanging among the rocks of the nearly perpendicular ascent of Mont-Salève.”

Mont-Salève, overlooking Geneva
Photo: Benoit Kornmann

Of course, the future networked car is a very different type of story, but compelling nonetheless. The laboratory in this story is the ITU Symposium on The Future Networked Car being held within the Geneva Auto Show on March 5 to 6, where many new ideas will be brought to life by convening leaders and technical experts from the automotive and ICT communities.

The event, organized by the International Telecommunications Union (ITU), will consist of high-level dialogues and several technical sessions; these include a session on integrating nomadic devices in cars, where I will discuss how technology standards can help minimize driver distraction. The dialogues will cover road safety and innovation for the future car, and will feature key leaders such as the presidents of Fédération Internationale de l’Automobile (Jean Todt) and Infiniti (Johan de Nysschen). The technical sessions will explore automated driving, connected car use cases, emergency services, and, of course, nomadic device integration. Speakers for these sessions come from a mix of automakers, tier one suppliers, ICT companies, standards development organizations (SDOs), industry groups, and government agencies.

The symposium also includes a session jointly organized by the ITU and UNECE Inland Transport Committee that deals with the human factors and regulatory issues introduced by automated driving. This session is an encouraging sign that the ITU and UNECE will continue the collaboration they started last June (see my previous post, “UN agencies take major step towards international standards for driver distraction”).

Hope to see you in Geneva!

The ultimate show-me car

The fifth installment in the CES Cars of Fame series. Our inductee for this week: a most bodacious Bentley.

It's one thing to say you can do something. It's another thing to prove it. Which helps explain why we create technology concept cars.

You see, we like to tell people that flexibility and customization form the very DNA of the QNX CAR Platform for Infotainment. Which they do. But in the automotive world, people don't just say "tell me"; they say "show me". And so, we used the platform to transform a Bentley Continental GT into a unique concept car, equipped with features never before seen in a vehicle.

Now here's the thing. This is the same QNX CAR Platform found in the QNX reference vehicle, which I discussed last week. But when you compare the infotainment systems in the two vehicles, the differences are dramatic: different features, different branding, different look-and-feel.

The explanation is simple: The reference vehicle shows what the QNX CAR Platform can do out of the box, while the Bentley demonstrates what the platform lets you do once you add your imagination to mix. One platform, many possibilities.

Enough talk; time to look at the car. And let's start with the exterior, because wow:



The awesome (and full HD) center stack
And now let's move to the interior, where the first thing you see is a gorgeous center stack. This immense touchscreen features a gracefully curved surface, full HD graphics, and TI’s optical touch input technology, which allows a physical control knob to be mounted directly on the screen — a feature that’s cool and useful. The center stack supports a variety of applications, including a 3D navigation system from Elektrobit that makes full use of the display:



At 17 inches, the display is big enough to display other functions, such as the car’s media player or virtual mechanic, and still have plenty of room for navigation:



The awesome (and very configurable) digital instrument cluster
The instrument cluster is implemented entirely in software, though you would hardly know it — the virtual gauges are impressively realistic. More impressive still is the cluster’s ability to morph itself on the fly. Put the car in Drive, and the cluster will display a tach, gas gauge, temperature gauge, and turn-by-turn directions — the cluster pulls these directions from the center stack’s navigation system. Put the car in Reverse, and the cluster will display a video feed from the car’s backup camera. You can also have the cluster display the current weather and current sound track:



The awesome (and just plain fun) web app
The web app works with any web browser and allows the driver to view data that the car publishes to the cloud, such as fluid levels, tire pressure, brake wear, and the current track being played by the infotainment system. It even allows the driver to remotely start or stop the engine, open or close windows, and so on:



The awesome (and nicely integrated) smartphone support
The Bentley also showcases how the QNX CAR Platform enables advanced integration with popular smartphones. For instance, the car can communicate with a smartphone to stream music, or to provide notifications of incoming email, news feeds, and other real-time information — all displayed in a manner appropriate to the automotive context. Here's an example:



The awesome everything else
I’ve only scratched the surface of what the car can do. For instance, it also provides:

• Advanced voice rec — Just say “Hello Bentley,” and the car’s voice recognition system immediately comes to life and begins to interact with you — in a British accent, of course.
   
• Advanced multimedia system — Includes support for Internet radio.
   
• Video conferencing with realistic telepresence — Separate cameras for the driver and passenger provide independent video streams, while fullband voice technology from QNX offers expanded bandwidth for greater telepresence.
   
• LTE connectivity — The car features an LTE radio modem, as well as a Wi-Fi hotspot for devices you bring into the car.

Moving pictures
Okay, time for some video. Here's a fun look at the making of the car:



And here's a run-through of the car's many capabilities, filmed by our friends at TI during 2013 CES:

RealVNC, QNX team up for mobile-to-vehicle connectivity

Paul Leroux

This just in: QNX and RealVNC have announced that they are collaborating to bring RealVNC’s implementation of the MirrorLink smartphone-to-vehicle connectivity standard to the QNX CAR Platform for Infotainment.

With RealVNC’s MirrorLink-certified SDK integrated in the QNX CAR Platform, QNX can offer a variety of connectivity features for integrating cars and smartphones through Wi-Fi, Bluetooth, and USB.

“We are delighted to work with QNX on integrating VNC Automotive into the QNX CAR Platform... many tier 1 and auto OEM customers are already using the proven combination of RealVNC and QNX technologies in production programs,” said Tom Blackie, VP Mobile RealVNC.

Read the full press on the QNX website.

Garmin taps QNX technology to create K2 infotainment platform

Complete digital cockpit delivers navigation, diagnostics, streaming media, smartphone integration, and voice recognition

Paul Leroux

This just in: Garmin International has selected the QNX CAR platform to power the Garmin K2, a next-generation infotainment solution for automakers.

Most people are familiar with Garmin's many portable GPS devices, from sports watches to action cameras to PNDs. But the K2 is a different animal altogether — a complete “digital cockpit” that comprises multiple digital displays, on- and off-board voice recognition, smartphone integration, and optional embedded 4G connectivity.

The K2 is designed to give drivers simple, intuitive access to navigation, vehicle diagnostics, streaming media, and realtime Web information. It's also designed with scalability in mind, so automakers can use it to address diverse market requirements and cost targets.

According to Matt Munn, managing director of Garmin’s automotive OEM group, “the QNX CAR platform has played a major role in helping us to achieve our goal of providing both world-class software reliability and flexible access to emerging consumer applications. From the proven stability and performance of the QNX architecture to the company’s worldwide industry recognition, QNX was the logical choice.”

Other key features of the K2 include a 3D-enhanced city model, a predictive services calendar, and remote personalization and control via a web portal or smartphone.

Here's the K2 at a glance:

Source: Garmin

And here's a demo of the system, filmed by Engadget at 2013 CES:



For more information on this announcement, read the press release. And for more on the K2 itself, visit the Garmin blog.

Specs for Cars?

Tina Jeffrey

As Google Glass, the latest in experimental computer wearables, starts to make its way into the hands of select users, a multitude of use cases is popping up. For instance, a WIRED article recently explored the notion of your car being a ‘killer app’ for Google Glass. Now, you may not want to think of your car as a killer app, but let’s contemplate this use case for a moment.

Drivers wearing Glass could pair their new specs to their phone and instantly have a personal heads-up display (HUD) that overlays virtual road signs and GPS information over the scene in front of them. For instance:


Source: Google

Glass also understands voice commands and could dictate an email, display turn by turn directions, or set up and display point-of-interest destination data based on a simple voice command such as “Find the nearest Starbucks”.

This is all very cool — but does it bring anything new to the driving experience that isn’t already available? Not really. Car makers have already deployed voice-enabled systems to interface with navigation and location-based services; these services either run locally or are accessed through a brought-in mobile device and displayed on the head unit in a safe manner. ADAS algorithms, meanwhile, perform real-time traffic sign detection and recognition to display speed limits on the vehicle’s HUD. All this technology exists today and works quite well.

Catch me if you can
Another aspect to consider is the regulatory uncertainty created by drivers wearing these types of devices. Police can spot a driver with their head down texting on a cellphone or watching a movie on a DVD player. But detecting a driver performing these same activities while wearing a head-mounted display — not so easy. There’s no way of knowing whether the activities a driver is engaged in are driving related or an outright distraction. Unlike an HUD specified by the automaker, which is designed to coordinate and synchronize displayed data based on vehicle conditions and an assessment of cognitive load, a head-mounted display like Glass could give a driver free reign to engage in any activity at any time. This flies in the face of driver distraction guidelines being promulgated by government agencies.

Don’t get me wrong. Glass is cool technology, and I see viable applications for it. For instance, as an alternative to helmet cams when filming a first-person perspective of a ski run down a mountain, or in taking augmented reality gaming to the next level. (You can see many other applications on the Glass site.) But Glass is a personal display that operates as an extension of your cellphone, not as a replacement for a car’s HUD. Cars need well-integrated, useable systems that can safely enhance the driving experience. Because of this, I don’t believe that devices like Glass, as they are currently conceived, will garner a spot in our cars.

Enabling drivers to interact safely with applications and services

Since February 2011, QNX Software Systems has been leading an international standards effort to help drivers interact safely with applications and services. And not just apps on phones, but apps running in the cloud, in roadside infrastructure systems, in the car itself, and other locations.

If you jump to the end of this post, you’ll find a list of use cases being targeted by this effort. For now, let’s look at Use Case 2, Scenario A (arbitration of external message), which illustrates how we are working towards a comprehensive framework for managing distraction and workload.

Keeping priorities straight
In this user scenario, a navigation maneuver is given priority over a social media status update message. The blue call-out boxes indicate where the ITU-T recommendations under development can enable safe interaction between the driver and applications. For instance, ITU-T recommendation G.SAM will define mechanisms for prioritizing navigation, while G.V2A will define the communications interface between the app and the driver-vehicle interface (DVI), and P.UIA will recommend characteristics of the auditory social media message.

Remember that the focus here isn't on how to implement social media in the car, but rather, on how best to manage workload and distraction.



Giving a navigation maneuver priority over a social media status update message

Often, I am asked how this effort differs from the MirrorLink standard being developed by the Car Connectivity Consortium. The simple answer is that MirrorLink addresses only some of the use cases listed below. For instance, the scope of MirrorLink is limited to applications and services running on nomadic devices. Furthermore, adaptation of the driver-vehicle interface and external applications and services in the current MirrorLink solution uses a simple two-state approach, driving or not driving, which limits the ability of the vehicle to control the timing and modality of communications with the driver. Also, MirrorLink doesn’t adequately address arbitration or integration of communications with all external applications and services.

In for the long haul
At QNX Software Systems, our aim is to:

1. Work with the relevant parties to identify solutions to the problem of technology-related driver distraction and workload. These parties include automotive, telecommunications, and consumer electronics organizations; standards development groups; academia; and government agencies.
2. Determine which aspects of the solution should be standardized, then help drive this standardization.
3. Align QNX product roadmaps as solutions develop.

To be clear, this is a longer term strategy that will take years to realize. Both the standardization process and the time it takes to deploy technology in vehicles must be factored in. Therefore, we are also pursuing shorter term solutions, some of which I hope to cover in future posts.

The end of the beginning
The first major milestone in this effort was achieved at the closing plenary of the ITU-T Study Group 12 meeting, held on March 28 in Geneva. Here, the final report and 4 deliverables of the ITU-T Focus Group on Driver Distraction were approved. There was also approval of a liaison statement communicating these results to a large list of organizations working on this topic.

This marks the end of the focus group, but is really just the beginning for QNX and ITU-T efforts in this area. In future posts, I will explore various aspects of this comprehensive strategy.

---

Use cases and user scenarios targeted by ITU-T recommendations

Use Case 1: Interaction with external application/service
   a) Application on nomadic device
   b) Application on cloud-based server
   c) Downloaded Application
   d) Broadcast of roadway information
   e) Tethering
Use Case 2: Arbitration and integration of external message
   a) Arbitration of messages
   b) Integration of messages
   c) Both arbitration and integration of messages
   d) E-call
Use Case 3: Negotiation of network Quality of Service (QoS)
   a) Application selects network
   b) Application suspends interaction
   c) Application availability due to roaming
Use Case 4: Management of multiple dialogues
   a) Opening/closing an application
   b) Switching between applications
   c) Interaction with background application
Use Case 5: Adaptation of DVI (driver-vehicle interface) and external applications/services to driver abilities
   a) Driver with disability
   b) Dynamically changing driver capabilities
   c) Detection of impaired driver state
Use Case 6: Adaptation of DVI and external applications/services to roadway situation
   a) Driver busy notification
   b) Delay of message delivery in demanding driving situation
   c) Change message format based on road conditions
   d) Interruption of driver interaction
Use Case 7: Adaptation of DVI and external applications/services to vehicle status
   a) Vehicle enters safe operating condition (e.g., park gear, < 5 m.p.h., etc.)
   b) Driver adjusts vehicle controls (e.g., climate control, etc.)
   c) Suppression of hazard alert due to safe speed
Use Case 8: Adaptation of DVI and external applications/services to local regulations
   a) Application blocked
   b) Application suspended
   c) Interface modality disabled
   d) Age restriction
   e) Content restriction

For details on these use cases, download the FG Distraction Use Cases report.

Traveling on reserve power

Or how a new kind of electro-mobility can be fun. A guest post from Thomas Fleischmann of Elektrobit Automotive.

Thomas Fleishmann

Imagine you are always driving on reserve power. You find this difficult? Get used to it — and welcome to the new era of electro-mobility! Vehicles like the Chevy Volt, with its secondary combustion engine, are already addressing this challenge — but having to support two types of driving technology can be challenging and costly.

So how can electro-mobility, which is supported by software, be implemented meaningfully? And how do we get drivers to accept it? Certainly not by abandoning the driver with nothing but a nicely animated display of the car’s battery condition.

Let's assume you live in a big city. You don’t even own a car. Instead, you subscribe to a certain number of hours of travel time with your favorite car brand. In addition to your S or XL subscription for four weeks a year, you get access to a fossil-fuel engine for your vacation in another state or country twice a year.

In the morning you find and reserve a car with your BlackBerry phone and get into it at a nearby charge-point. The HMI adapts to your profile settings automatically — your friends, contacts, addresses, and music are already there. The navigation system is your energy consultant; it tells you, based on traffic conditions and topography, how far you can drive with this car and, at the appropriate time, suggests an available electric socket within easy reach. Or the system warns you to turn back soon if you want to arrive home safely. After parking the car successfully, your smartphone guides you for the last few kilometers by bus or subway to your destination — it knows the way and easily adopts the data of your navigation system.

Using software solutions like EB GUIDE or EB street director and frameworks like the QNX CAR application platform you can concentrate on creating the end-user experience and transform the journey on reserve power into something fun and convenient — suddenly an electric vehicle becomes a smart mobility concept.

Check this out; I fried it last week. The yellow center represents the area in which you can drive and go back home. The white area represents the range you can drive, depending on traffic or topography:

---

Thomas Fleischmann is Senior Product Manager at Elektrobit Automotive responsible for the HMI solution EB GUIDE. Contact him at Thomas.Fleischmann@elektrobit.com.

What if…

Imagine if your car could help you become more connected to friends and family — and to the road ahead. Enter a new video that peers into the not-so-distant future.

It blows my mind, but some people still see connectivity in the car as the enemy. They think that, the more connected the car, the more distracting and dangerous it will be. But you know what? Responding to their concerns is easy. I simply ask them what if.

For instance, what if connectivity helped you drive with greater situational awareness? What if it helped you sidestep traffic jams and axle-busting pot holes? What if it helped you detect a stop sign hidden behind a tree? And what if it helped you become more connected to the people important to you, as well as to the road and the cars around you?

When we talk connectivity at QNX, that’s the kind of connectivity we envision. It isn’t just about Bluetooth or Wi-Fi or LTE — that’s only the plumbing. Rather, it’s about keeping you in tune and in sync with your car, your environment, your business, your friends. Your life.

Top 8 questions for squeezing high-end tech into low-end infotainment

A couple of weeks ago, I hosted a webinar that addressed the question, “Is it possible to build an infotainment system that meets today's customer demands with yesterday's price tag?” The webinar explored several ways to reduce RAM and ROM requirements, eliminate hardware, and share hardware, all with the goal of cutting BOM costs.

As always, the audience asked lots of great questions, several of which I have answered here. Of course, these provide only a hint of the ground covered in the webinar, so I invite you to download the archived version to get the full details.

Built-in phone module versus brought-in smart phone: what is your take on this, and is a hybrid approach feasible?
The approach will vary from automaker to automaker. I think that embedded phones will be required for certain cars, especially if they use systems that rely on cloud-based services. This approach adds to the BOM cost, of course, but it may reduce overall cost, depending on what features can be off-loaded to the cloud.

Some brands will encourage brought-in devices as the lowest-cost alternative. The consumer will then have to deal with the setup and maintenance issues required to pair or charge the phone. I don’t see a clear-cut analysis that says one method will be better than the other — it really depends on what you want to accomplish.

Any thoughts on using MirrorLink to clone a virtual display to a remote physical LCD?
If you’re talking about a remote (as in cloud-based) device, I would say that HTML5 is a much more natural choice for a server-based application. If it’s a brought-in device, then MirrorLink or HTML5 could be appropriate.

If GPS is moved to a brought-in phone, how will a stolen vehicle be located?
It won’t be, unless the phone was left in the vehicle. This is one of the trade-offs you make when trying to reduce cost.

Of the cost-saving techniques you discussed, which are most likely to be used?
Already, some system designers are removing wake-up micros and DSPs. I’m not aware of any systems where the LCD has been removed, but this approach would probably offer the largest cost savings, making it a likely choice for entry-level systems and cost-sensitive markets.

Security and reliability are the main concerns of a head unit. Squeezing high-end technologies into low-end systems won’t relax those expectations. For instance, smart phone integration will be an add-on instead of replacing functionality of the head unit. Thoughts?
The trade-offs will need to be communicated to the customer. You can never build a head-unit augmented with a smartphone that works as reliably as the head unit operating by itself. As an OEM or Tier 1, you just don’t have enough control over the brought-in devices.

As an industry, we need to educate consumers. If they start relying on the phone in the car to provide certain features, then they will have to expect an inevitable degradation in overall system quality. It comes back to that famous adage: “cost, quality, or time — pick two”.

MirrorLink has a defined communication interface to the head unit. You also mentioned HTML5 as an option. Is there a defined standard yet for transmitting the HTML5 up to the head unit?
The interface between web server (i.e. phone) and web client (i.e. head unit) is already well established and tested. For some specialized features (for instance, allowing HTML5 code to access vehicle services) some standardization may be required. This will hopefully be a topic of discussion in November, at the automotive HTML5 workshop hosted by the W3C in Rome. Some Connected Car Consortium members have also discussed the possibility that, in the future, MirrorLink could add a transport mechanism based on HTML5.

You discussed peripheral sharing, using QNX transparent distributed processing. Does QNX TDP require secure authentication between distributed boxes?
No, it does not. It relies on standard POSIX user group permissions to provide access rights to devices.

Can you discuss any trends you see regarding Ethernet or TCP/IP in the vehicle?
Ethernet is definitely becoming more interesting in the vehicle, due to the introduction of Ethernet AVB. It makes a very natural replacement for audio-video transmission over MOST, and the additions to AVB that fulfil strict timing requirements can replace CAN or MOST for non-media vehicle messages. Ethernet also has obvious advantages when you need to access Wi-Fi networks, cloud services, and mobile devices.

HTML5 SDK for the QNX CAR 2 platform — the back story

Kerry Johnson

Today, at SAE Convergence, QNX Software Systems announced the new HTML5 SDK for the QNX CAR 2 application platform. I’d like to provide some insight into this announcement, describe what you can expect to find in the SDK, and explain how it builds on the HTML5 capabilities already available in the QNX CAR 2 application platform.

Enabling apps for the car
Almost every consumer who owns a smart phone or tablet is familiar with the app experience: you go to an online marketplace, find apps of interest, and download them onto your device. With the HTML5 SDK, the automotive team at QNX is creating an analogous experience for the car.

Just as Apple, Android, and RIM provide SDKs to help vendors develop apps for their mobile platforms, QNX has created an SDK to help vendors to build apps for the QNX CAR 2 application platform. The closest analogies you will find to our HTML5 SDK are Apache Cordova and PhoneGap, both of which provide tools for creating mobile apps based on HTML5, CSS, JavaScript, and other web technologies.

App developers want to see the largest possible market for their apps. To that end, QNX also announced today that it will participate in the W3C’s Web and Automotive Workshop. The workshop aims to achieve industry alignment on how HTML5 is used in the car and to find common interfaces to reduce platform fragmentation from one automaker to the next. Obviously, app developers would like to see a common auto platform, while automakers want to maintain their differentiation. Thus, we believe the common ground achieved through W3C standardization will be important.

It bears mentioning that, unlike phone and tablet apps, car apps must offer a user experience that takes driver safety into consideration. This is a key issue, but beyond the scope of this post, so I won’t dwell on it here.

So what’s in the SDK, anyway?
As in any SDK, app developers will find tools to build and debug applications, and APIs that provide access the underlying platform. Specifically, the SDK will include:

• APIs to access vehicle resources, such as climate control, radio, navigation, and media playback
• APIs to manage the application life cycle: start, stop, show, hide, etc.
• APIs to discover and launch other applications
• A packaging tool to combine application code (HTML, CSS, JavaScript) and UI resources (icons, images, etc.) with QNX CAR APIs to create an installable application – a .bar file
• A emulator for the QNX CAR 2 platform to test HTML5 applications
• Oh yeah, and documentation and examples

The development and deployment flow looks something like this:




Emulator and debugging environment
The QNX automotive team has extended the Ripple emulator environment to work with the QNX CAR 2 application platform. Ripple is an emulation environment originally designed for BlackBerry smart phones that RIM has open sourced on github.

Using this extended emulator, application developers can test their applications with the correct screen resolution and layout, and watch how their application interacts with the QNX CAR 2 platform APIs. For example, consider an application that controls audio in a car: balance, fade, bass, treble, volume, and so on. The screenshot below shows the QNX CAR 2 screen for controlling these settings in the Ripple emulator.


Using the Ripple emulator to test an audio application. Click to magnify.

In this example, you can use the onscreen controls to adjust volume, bass, treble, fade, and balance; you can also observe the changes to the underlying data values in the right-hand panel. And you can work the other way: by changing the controls on the right, you can observe changes to the on-screen display. The Ripple interface supports many other QNX CAR 2 features; for examples, see the QNX Flickr page.

You can also use the emulator in conjunction with the Web Inspector debugger to do full source-code debugging of your Javascript code.

Creating native services
Anyone who has developed software for the QNX Neutrino OS knows that we offer the QNX Momentics Tool Suite for creating and testing C and C++ applications. With the QNX CAR 2 application platform, this is still the case. Native-level services are built with the QNX Momentics suite, and HTML5 applications are built with our new HTML5 SDK. We've decided to offer the suite and the SDK as separate packages so that app developers who need to work only in the HTML5 domain needn't worry about the QNX Momentics Tool Suite and vice versa. Together, these toolkits allow you to create HTML5 user interface components with underlying native services, where required.

MirrorLink misunderstood: 8 myths that need busting

If you're new to MirrorLink, it's a technology that bridges the mobile phone and the car. It allows specially written apps running on the phone to be displayed on the car's head unit, where the user can interact with them.

MirrorLink is intended to extend the life of in-vehicle systems by allowing them to interact with mobile content and to support new features that didn’t exist when the car rolled off the assembly line.

Here's an illustration of how it works:


MirrorLink in-car communication. The protocol between the head unit and the phone can run over several transports, including USB, Bluetooth, or Wi-Fi. This example assumes Bluetooth for the audio back-channel.

When I talk to people in the automotive and mobile industries, I find they share a number of common misconceptions about MirrorLink, which I’d like to clear up. So let's get started, shall we?

1. MirrorLink is an Android technology. In fact, MirrorLink works with multiple mobile platforms. Phones using Android can support it, but so can phones from any other phone maker that supports the standard. Even Apple phones could support it, though Apple has currently chosen to go their own route with Apple-specific solutions.
   
   
2. MirrorLink allows any mobile app to run in the car. This is incorrect. A MirrorLink app can run in the car only if the car maker grants “trust” to that app. Each car maker has a different concept of what brands to promote, what features are safe, or what works well with each car. So, in reality, each app will be enabled depending on the individual make — or even model — of car.
   
   
3. MirrorLink promotes “driver distracting” apps. Also incorrect. MirrorLink is an enabling technology that doesn’t promote any type of app in particular. In fact, because the car maker must grant trust to an app, the app developer can't control what apps run in the car. That responsibility remains the domain of car makers, who tend to avoid anything that will cause distraction when displayed on a front-seat screen.
   
   
4. MirrorLink is the only way to connect an app to the car. There are in fact two others: iPod Out and HTML5. Apple supports iPod Out for Apple devices, which allows selected applications to output analog video to the head unit. (Note that the new iPhone 5 doesn’t support iPod Out.) HTML5 also allows mobile apps to run in the head unit, though its use in car-to-phone bridging is still in the early stages. QNX Software Systems has demonstrated concept vehicles that use BlackBerry Bridge (an HTML5-based technology) to connect an HTML5 app on a BlackBerry phone to the car’s head unit.
   
   
5. Mobile app makers will benefit most from MirrorLink. In fact, car makers may end up taking best advantage of the technology. That’s because they can use MirrorLink to customize and create apps, and to refresh those apps as a way of delivering fresh, new functions to their customers. MirrorLink gives them the ability to do this using a standardized protocol supported by most mobile platforms. Car makers could use MirrorLink very effectively, even if they never allowed any third party apps into their cars.
   
   
6. HTML5 and MirrorLink are incompatible. Not necessarily true. Current versions of MirrorLink use the VNC protocol to exchange graphical data. None of the advantages of HTML5 would be incompatible with a future version of MirrorLink; in fact, some members of the Connected Car Consortium (CCC), including QNX Software Systems, would likely be interested in merging these two standards. That would result in a new version of MirrorLink that uses HTML5 as the underlying communication protocol. (The MirrorLink specification is controlled by the Car Connectivity Consortium, of which QNX is a member.)
   
   Even if MirrorLink does go to HTML5, the industry would still need a VNC-based form of MirrorLink. VNC has much lighter requirements on the head-unit side, so it makes more sense than HTML5 if the car doesn’t have a high-powered CPU or lots of memory. The broadest possible option would be to have phone apps support multiple versions of MirrorLink (today's version with VNC plus a future version with HTML5) and to use whichever one makes sense, depending on what the car supports.
   
   
7. MirrorLink obviates the need for car-downloadable apps. Yes, MirrorLink capability is somewhat similar in purpose to downloading apps into the car; they both extend the functionality of the car after it leaves the factory. Because the customer’s phone will almost certainly be newer than the car’s electronics, it will have a faster CPU, giving the raw speed advantage to a MirrorLink app on the mobile. The MirrorLink app will also have guaranteed data access since the hosting phone will always have a data pipe — something that isn't certain on the car side of the equation.
   
   On the other hand, MirrorLink doesn’t give an app access to car features that would available to a car-downloaded app — features such as vehicle bus access, telematics features, or the navigation system. Also, a car-downloaded app would likely have a faster HMI than any off-board app, even if the mobile had a faster CPU, because of latencies inherent to screen replication. The car-downloaded app would also have better visual integration, as it could take full advantage of the car features, instead of appearing as a bolt-on product. Other factors, based on automaker control, compatibility, or product roadmaps could also favor an in-car solution. Even if you could address some of these issues, there would still be enough reasons for MirrorLink and an auto app store to live side-by-side.
   
   
8. MirrorLink apps can be built today. This is technically true. But, in their enthusiasm, new converts can sometimes forget that cars need to support MirrorLink for anything to actually work. Currently, only aftermarket car stereos support MirrorLink; no production vehicles support it. So if you’re a mobile app developer, the market for MirrorLink apps today is negligible. But expect this situation to improve dramatically over the next two to three years as production vehicles start to ship with this capability built-in.

QNX CAR 2 — the extended version

The world of video is a ruthless one; just as we posted the QNX CAR demo it was out of date.

But, hold on a minute. As I write this I realize it’s not the video world at all; it’s the software world that creates new technology at breakneck speed. And QNX certainly does its part.

The QNX CAR 2 application platform has come a long way in a matter of months. We needed to update the original video to keep pace with the technology but also to address customer demand for more detailed information.

So this video is a step-by-step demo – definitely not for the tire kicker. But if you really want details on what automakers and tier ones can achieve with QNX CAR technology, hit play.

For safety’s sake, why don’t cars just disable phones?

With all the focus on driver distraction, this is a question that I get asked occasionally. It’s a simple question, with a less than simple answer.

Using technology to control inappropriate phone use has been a topic at some of the driver distraction meetings I've attended. One proposed solution involves a technique called micro location — using ultrasonic waves to identify where in the cabin the phone is located. There are other ways to triangulate the phone's position, but they all require coordination between the phone and car. Knowing where the phone resides in the car is a requirement, as most passengers wouldn’t be happy to have their phone automatically disabled, just because they’re in the car. And the solution can’t be based only on the GPS speed of the phone, or you’d have lots of irate bus, taxi, train, or subway riders.

The fact is, unless all phone makers and car makers agree on the same standard, there's no incentive for either side to build half of a feature. You’d need to deploy potentially expensive technology that wouldn’t work unless you pair exactly the right phone with the right car. This likely won't happen unless companies are legislated to do so.

Given the speed of automotive development, it’s impossible for the car guys to build a technology that the phone guys won't leave in the dust, unless some guarantees are put in place. The adoption of Bluetooth is a good example. It took years before Bluetooth became widespread in phones, but its adoption had more to do with Bluetooth earpieces, not connections to cars. Car makers took a long time to roll out Bluetooth support as a standard feature because too many phones either didn't have it or had an implementation that wasn't fully compatible. Eventually, the two markets synchronized, but it took several years.

One argument against a technology-mandated disable is that not all jurisdictions agree on what is, or isn’t, allowable. In the US, 45 out of 50 states have some form of prohibition against using phones in cars. But what is disallowed varies widely by state — some don't allow any use of the phone (even hands-free), some prohibit teenagers but no other age groups, some disallow texting but not hands-free, some disallow use for commercial vehicles but not private vehicles, and some allow everything.

Another argument against a technological solution is that people can be educated to assume responsibility for their behavior. For example, why don't all cars have a blood alcohol level blow-tester hooked up to the ignition? Technically it's possible, but it's very expensive to do it from the car maker's standpoint. One could argue that it is worth it to have cars protect us from ourselves. But as a society, we've decided that, in the case of drunk driving, we are willing to give people back the responsibility. Rather than control the problem with technology, we socialize and educate people that driving intoxicated is an undesirable behavior.

We could, of course, decide to do the same with mobile technology, by educating personally instead of solving technically. This approach may make more sense than a technology-based prohibition: technology always moves at light speed compared to legislative mechanisms of control.
 

New webinar: Understanding mobile apps for the car

You're an app developer. You're looking for new opportunities. You were hoping, perhaps, that Web-connected refrigerators would be the next big thing. Being first to market with a fridge app — that would have been cool, right? I mean, literally.

Problem is, the market for fridge apps hasn't warmed up yet. I'm sure it will, though. But until then, why not the car? Cars are already connected. Car makers want to make them even more connected. And those cars will need apps, whether those apps are hosted on a phone, in the cloud, or in the car itself.

Interested? Intrigued? Then set your calendar to the webinar happening this Thursday, June 28, at 1:00 pm ET. Here's the official synopsis:

Wouldn't your app look good here?

Understanding Mobile Apps for Automotive

Today's merger of mobile handsets and automotive platforms is creating a brand-new market for app developers. However there are many differences between a phone and car.

This session provides an introduction to the automotive market for the app developer looking to get into this space. Learn how a car infotainment system is structured, UI considerations that help prevent driver distraction, why HTML5 promises to be the next killer development environment for the car, and more.

On the downside, you won't learn about apps for white goods. But, because the webinar is hosted by my inimitable colleague Andy Gryc, who has actually written software for cars, you will get the straight goods. Which is, well, cool.
 

Report from CTIA Wireless: Apps in the Car

You wouldn’t think that CTIA Wireless, a mobile show, would be a good venue for a car guy. But automotive journalist Doug Newcomb put together a set of panels that managed to attract everyone from the automotive industry who attended the show.

I met a good number of friends from a variety of automakers, tier one suppliers, and hardware and software vendors. I also had the distinct pleasure of participating in one of Doug's panels, which was moderated by Damon Lavrinc of WIRED.

The topic was the future of apps in the car, and it generated a spirited discussion. Panel participants included Geoff Snyder from Pandora, Michelle Avary from Toyota, Henry Bzeih from Kia, and Scott Burnell from Ford — all experts on the topic.

Andy speaking on the

apps panel. Videos of all

the panels are now online.

In general, we agreed: apps are coming to the car. They have already arrived in several cases, and it’s only a matter of time before they come to mass-market vehicles. And apps are not for North American alone: it's a worldwide phenomenon.

Mind you, we engaged in lively debate on a number of questions: What role does the mobile app developer play? How to deal with the fragmentation caused by different OEM app platforms? How to deal with driver distraction? And when will the "one man app" ever make it into the car? We all had good and varied opinions on these topics, and the session was very well received by the audience.

Derek Kuhn, QNX vice president of sales and marketing, also participated in a panel session, titled "Can we all just get along… for the consumer's sake?". That panel focused on how the industry as a whole can create a more seamless experience for the consumer. Derek's co-panelists included Mark Harland from GM, Leo McCloskey from Airbiquity, Brian Radloff from Nuance, and Niall Berkery from Telenav.

Did I mention? Videos of all the panels are now on Doug Newcomb's website — check them out!
 

OnStar RemoteLink app comes to BlackBerry smartphones

This just in: The RemoteLink App from OnStar, which allows smartphone owners to remotely start their vehicles, check fuel levels, and lock or unlock their doors, is now available for the BlackBerry Bold 9900 and 9930 phones.

RemoteLink has been available for iPhone and Android phones, but many OnStar subscribers have asked for a BlackBerry version of the app. In response, Onstar wrote a new version for the BlackBerry platform, in HTML5.

“Writing the app using HTML5... positioned us to be more flexible supporting new phone operating systems,” said Steve Schwinke, director of advanced systems development for OnStar.

Opening screen
for RemoteLink
© GM Company 

In 2011, OnStar added navigation to RemoteLink, allowing users to search for a destination on their smartphone and send it directly to their vehicle. Users can then access the route through the QNX-powered OnStar system.

By leveraging OnStar’s connection to the vehicle, the app can report on oil levels, tire pressures, fuel level, and lifetime miles per gallon. It also offers remote commands, such as remote start, door lock/unlock, and horn/light activation.

According to OnStar, a total of 821,000 smartphone owners actively use the RemoteLink app.

To read OnStar's press release, click here. To download the RemoteLink app from BlackBerry App World, click here.

On a related note, here's a conversation between QNX's Andy Gryc and OnStar's Steve Schwinke. The topic: how HTML5 can benefit the auto industry.


 

Concept car out. Reference vehicle in.

Our big announcement for Telematics Update is that we are not showing a concept car. Odd news, you say. The truth is, we're not building a concept car because we are building a reference vehicle. Splitting hairs? Not really.

Unlike the Corvette and the Porsche, our demo for this show will be based on the exact same technology that our customers are using today to design their next-generation systems.

So why vehicle instead of car? Is it a truck? Nope. A van? Negative. What about a motorcycle? Double negative.

I was hoping to give you a sneak peek at what we are working on but I'm not allowed to give away the details. However, I did manage to get these shots – let me know if you can see the vehicle. :-)


 

Find me a Starbucks! QNX concept car showcases power of WATSON speech engine

Yes, you can talk to the QNX concept car and tell it what to do.

Recently, our friends at AT&T invited us to bring the concept car to their "Living the Networked Life" event in New York. We said yes, of course! After all, what could be cooler than riding the streets of Gotham City in a digitally pimped-out Porsche 911?

Kidding aside, the event provided an excellent opportunity to demonstrate how the car takes advantage of WATSON, AT&T's natural-language speech engine. To get an idea of what WATSON can do, check out this video from Terrence O'Brien of Engadget:



For the full Engadget article, click here. And stay tuned for more updates from the Living the Networked Life event.
 

QNX joins Car Connectivity Consortium

This just in: QNX Software Systems has announced its membership in the Car Connectivity Consortium (CCC), the organization dedicated to developing the MirrorLink standard for car-smartphone connectivity.

MirrorLink offers a way to help car occupants access their smartphone applications. For instance, it could allow occupants to access their phone apps through the infotainment touchscreen, steering-wheel buttons, or other in-car controls.

Source: CCC

As a core member of the CCC, QNX Software Systems will have access to MirrorLink specifications under development and to various MirrorLink work groups. It will also be able to support future MirrorLink options in QNX-based systems, and help drive development of the standard.

“QNX Software Systems is a key player in the evolution of car infotainment technology and we are pleased to welcome them into the organization,” commented Mika Rytkonen, the CCC's chairman and president.

The announcement fits into QNX's strategy of enabling automotive developers to leverage widely supported industry standards.

“We believe in giving automotive customers choice and the flexibility to use the technologies best-suited to their requirements — contributing to the CCC helps us deliver on that commitment,” added Andy Gryc, automotive product marketing manager for QNX. (This is, of course, the same Andy Gryc who contributes to this blog.)

To read the press release, click here.

 

What the connected car is really all about (and what we need to do about it)

Recently, I was invited to participate in a webinar that highlighted hits and misses at Mobile World Congress. It occurred to me that some of you might be interested in what I had to say — at the very least, I’d earn points with Paul Leroux, our editor, for spontaneously offering up a blog post. :)  So here's what I said... almost verbatim.

First, a quick intro on QNX: Many will know us as the wholly owned subsidiary of RIM whose software platform powers the BlackBerry PlayBook. But we also provide the de facto standard platform for all types of in-vehicle infotainment and navigation systems. And it’s from this perspective that I offer these comments.

My primary observation is regarding the evolving dialogue surrounding the connected car and what I think it represents. Three years ago we were here with Alcatel-Lucent, showcasing the first LTE connected concept car, based on a Toyota Prius. This car proved so popular that we had to hire a security guard to help manage the traffic. Now, three years later, there are a number of connected production vehicles to be seen, including a QNX-based BMW 7 series in the GSMA’s connected home exhibit. And the announcements this year focused not so much on broadband connectivity per se (it's here, people expect it), but on the integration of the smart phone with the vehicle.

At QNX, we talk about the personalization of the in-vehicle experience, as people want to bring in their own devices, their own music, their own contacts and other content — and experience these in the vehicle setting. For instance, Ford not only announced the B-Max vehicle, but used MWC as a platform to launch Ford Sync for Europe. Toyota and Samsung, meanwhile, announced support for Samsung Mobile Car Application for integration of phones to the car's head unit. So if step one was getting a broadband connection to enable a consumer experience in the car, and step two is about personalizing that experience, what’s next? 

I think that, ultimately, the connected car is all about the consumer, and this is how revenue will be generated in a way that connected telematics on its own could never do. You could be an automaker interested in improving how to service a car and its owner after the car has driven off the dealer's lot. Or you could be a carrier interested in extending your offer beyond connectivity to deliver value-added services. Or perhaps you’re a small business trying to get more people in the door. In each case, the car represents a new frontier. And it offers the added value of context – not only do you know if someone is available and where they are, but you also know that they are driving a vehicle. 

The next few years are going to be very exciting as the automotive and mobile industries converge to address this opportunity. Think about the brands involved: Companies like Audi, BMW, and GM on one hand and the likes of AT&T, Verizon, and Vodafone on the other. They’re mutually dependent — neither group will be successful without the other. Automotive needs to leverage the investments being made for smart phones, be it device technology, network infrastructure, or developer communities. Meanwhile, the mobile industry has to consider the nature of automotive in terms of safety, security, and liability, not to mention product life cycles. 

It's safe to say that automotive is just the first example of this type of industry convergence and transformation. All of the carriers are looking at M2M as a huge untapped market opportunity. And within the classic embedded market, there are an almost infinite number of market segments, truly an example of the Long Tail. 

It will be exciting to watch how mobile transforms those markets and vice versa — what will mobile look like in 5 years from now? I don’t think we can easily predict it; after all, it's not going to be like anything we’ve seen before. But I can’t wait to find out.

So there you have it. If you'd like to hear the entire webinar, you can register here to access the archived version.