Automotive: Mobile connectivity

Showing posts with label Mobile connectivity. Show all posts

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.

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:

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.
Determine which aspects of the solution should be standardized, then help drive this standardization.
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.

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.

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.

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?

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.
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.
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.
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.
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.
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.
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.
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.

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.

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.

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.

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!

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.

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. :-)

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.

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.

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.

LTE connected concept car

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.

If you're looking for a quick, two-minute intro to the QNX CAR 2 application platform, you've come to the right place.

In this video, Kerry Johnson, automotive product manager at QNX, takes us on a tour of the platform, including its home screen, media player, application area, HTML5 support, phone app, and acoustic processing.

Ready? Then hit the Play button and let's get started:

In case you didn't know, the QNX CAR 2 platform forms the basis of the QNX concept car, a specially modified Porsche 911 that demonstrates what to expect in next-generation car infotainment systems. Earlier this year, the platform drove home with a 2012 Best of CES award, in the Car Tech category.

Did you know you can build HTML5 apps that don't use an Internet connection? Did you know you can run HTML5 apps without a web browser? And did you know HTML5 apps can show snappy performance even on automotive silicon? (As you can well imagine, in-car infotainment systems don't ship with quad-core server-class CPUs.)

If you answered no to any of these questions, you need to stop for a minute and check out this interview with QNX Software Systems' Kerry Johnson. Heck, even if you answered yes to all three questions, you'll probably still appreciate what Kerry has to say — and besides, you'll catch a glimpse of a complete in-car UI coded in HTML5. What could be bad?

While I have you, check out Andy Gryc's Q&A series on HTML5, if you haven't already. You'll find the first two installments here and here.

I love this play on words. I can’t claim it as my own but I think it’s very cool that the word automobile breaks down into auto and mobile. I’m sure the term originally referred to automatically mobile horseless-carriages or some such thing. According to one online source, the word dates from 1895 and means “self-propelled motor vehicle”.

But today, it represents the convergence of two historically independent industries, auto and mobile. Now, more than ever, consumers are extending their digital lives into their cars. They want a personalized in-vehicle experience, including access to their music, to their friends, to their favourite places, and to their schedules — both personal and professional. And that’s just the beginning.

Following the Consumer Electronics Show (CES) in January, I heard many in the industry refer to CES as one of the most important automotive shows of the year. You heard that right: CES is now considered an automotive show.

The new QNX concept car is
scheduled to appear at MWC.

Now it’s February and QNX Software Systems is headed to Barcelona where we will demonstrate our connected concept car on the BlackBerry stand in Hall 7 at Mobile World Congress. This same car won a Best of CES award in the car tech category.

MWC is the show for mobile phones and everything related. During the show, we will participate on a luncheon panel hosted by Fierce Markets, Paving the Way to Success for the Connected Car. Other panelists include Ford, AT&T, and the GSMA.

MWC isn’t known as an auto-focused event but I expect this to change. Most carriers see the connected car as an emerging growth market, as do silicon vendors. Meanwhile, handset and car companies work towards improving the integration of the mobile experience into the car without impacting driver distraction.

Auto + Mobile. End of story.

For more info on the panel, click here.

Paul Leroux

This just in: Antuan Goodwin of CNET has posted a video walkthrough of the new QNX concept car, which showcases the many capabilities of the QNX CAR 2 application platform.

Antuan touches on all of the car's salient features, including one-touch smartphone integration, backseat entertainment, video streaming, rich app support, ultra HD voice technology, and the reconfigurable digital instrument cluster. Check it out:

Automotive

Include stories and information on automotive technology.

Pages

Unordered List

Specs for Cars?

Enabling drivers to interact safely with applications and services

Traveling on reserve power

What if…

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

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

MirrorLink misunderstood: 8 myths that need busting

QNX CAR 2 — the extended version

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

New webinar: Understanding mobile apps for the car

Report from CTIA Wireless: Apps in the Car

OnStar RemoteLink app comes to BlackBerry smartphones

Concept car out. Reference vehicle in.

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

QNX joins Car Connectivity Consortium

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

A quick tour of the QNX CAR 2 application platform

HTML5: Bustin' the myths

Auto + Mobile

New CNET video takes you on guided tour of QNX concept car

Automotive technology

Labels

Popular Posts Automotive

Blog Archive