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.

A quick tour of the QNX CAR 2 application platform

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.
 

HTML5: Bustin' the myths

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.
 

Auto + Mobile

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.
 

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

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:


 

CrackBerry posts first peek at OnStar RemoteLink for BlackBerry PlayBook

Paul Leroux

This morning at CES, CrackBerry.com met up with QNX's Andrew Poliak for a walkthrough of the new OnStar RemoteLink app for the BlackBerry PlayBook.

If you aren't familiar with RemoteLink, it provides a very cool and powerful connection to OnStar-equipped vehicles. From the convenience of your tablet or phone, you can access gas mileage, tire pressure, and other information in real time; you can even remotely start your vehicle and unlock its doors.

Cooler yet, the new version running on the PlayBook boasts a user interface built entirely in HTML5. But enough blather from me. Roll the tape...



Did you know? QNX is the core OS for the PlayBook, but it's also the OS for OnStar and OnStar FMW.
 

HTML5 is a great option for the risk-adverse

The conservative nature of automakers makes them ideal candidates for the brand-spanking new HTML5. Say what?

While this seems paradoxical, it is an interesting take-away from the discussion between TCS' director of engineering Michael Camp and our very own Andy Gryc. If you've got three minutes to spare, watch the latest video in our HTML5 series for the whole story. (As usual, don't miss the ending. ;-)

This interview of Michael Camp is the fourth in a series from QNX on HTML5.

HTML5 and the software engineer

HTML5 appears to have a number of benefits for consumers and car manufacturers. But what is often good for the goose is not necessarily good for the developer. Talking to the guys in the trenches is critical to understanding the true viability of HTML5.

Andy Gryc and Sheridan Ethier, manager of the automotive development team at QNX, pair up for a technical discussion on HTML5. They explore whether this new technology can support rich user interfaces, how HTML5 apps can be blended with apps written in OpenGL, and if interprocess communication can be implemented between native and web-based applications.

So without further ado, here’s the latest in the educational series of HTML5 videos from QNX.



This interview of Sheridan Ethier is the third in a series from QNX on HTML5.