Our best CES yet

Anecdotes and observations from the QNX booth at 2013 CES

As a wrap-up to last week’s Consumer Electronics Show, I would love to regale you with all the cool technologies and nifty gadgets that I saw. But over the course of the entire four days, I rarely left the 20’x40’ patch of white carpet that was the QNX booth — with brief exceptions, of course, for bodily maintenance. The booth was just too busy for me to get away. If you checked out the QNX booth webcam, you know what I'm talking about.

Paul Leroux and Nancy Young have already posted a lot of information and photos about the show and the new QNX concept car, which is based on a Bentley Continental GT. So let me provide my personal view of CES through assorted anecdotes or observations collected at the booth.

• As you’d expect, the Bentley got a lot of attention. But our reference vehicle, based on a Jeep Wrangler, got more attention than I thought it would, even though this is the third time we’ve shown it in public. Many of the people interested in the Jeep just wanted to see what our QNX CAR application platform looked like “out of the box” without customization. And some were confessed Jeep or truck aficionados, without the “luxury brand lust” experienced by most.
   
• People in the auto industry knew who we were without introduction. Non-automotive people didn’t know who we were until I mentioned that “we are a wholly owned subsidiary of Research In Motion,” at which point most of them said “Oh, you’re that QNX.” Seems that your average person has heard quite a bit about QNX in the context of BlackBerry, but has no idea that the same company is doing things in automotive — or in anything else, for that matter. I usually then spoke about our 30+ year legacy in life- and mission-critical systems. When people learned that an OS used for mission-critical systems will also power their next potential phone, their reaction was “wow—that’s really cool.”
   
• Tanner Foust is a really nice young kid. (Actually, he’s not that much younger than me, but he sure looks young!) I didn’t know who he was when he was being filmed in the booth, surrounded by a throng of admirers. But since then, I’ve watched a lot of his YouTube videos and boy, can he drive! He's an accomplished race car driver, TV personality, and stuntman for lots of famous movies, but it’s nice to see he hasn’t let it go to his head.
   
• We wanted to make sure that our concept car respected the Bentley brand. To do that, we ran our design sketches by the folks at Bentley and they occasionally suggested some tweaks. It was all our own work, however, and the Bentley folks never saw it before it hit the show floor. When they came to the booth, they were very happy with what they saw — enough so that they said “it looked like we did it.” That, to me, was the ultimate compliment.
   
• Most frequent question: “Are you giving this away?” As it turns out, it’s something that people have said for every concept car we’ve done to date. Second most frequent question: “Can I drive it?” Unfortunately, but unsurprisingly, the answer to both is “No.”
   
• I was a little surprised by the enthusiastic response to the car's video conferencing. Of course, it works only while the car is parked, and you only get audio while the car is in Drive. But the part that seemed to impress people the most is the audio: two channel stereo and a full 20Hz to 22KHz means that the call sounds so much better than your typical hands-free call. You could see the reaction when the our director of acoustics Phil Hetherington started talking — you don’t know what you’ve been missing until you hear it.
   
• Bentley wanted us to add our video conferencing solution to the technology concept car. Because many Bentley vehicle owners aren’t necessarily the drivers, this feature makes a whole lot more sense for rear-seat systems than you might initially imagine.
   
• I was really impressed by two members of the media: Brian Cooley of CNET and Craig Peterson of Clear Channel. Both could receive a five minute technology core dump, quickly digest it, and talk intelligently about it on video or live radio (respectively) with no stumbles, questions, or missteps. I’ve had the pleasure of seeing both in action before, but their consummate professionalism is really quite amazing.
   
• I and every other QNX’er was delighted that we didn’t win the CNET Best of CES award! Instead, our customer, Chevrolet, won it for their MyLink system, and we couldn’t have been happier. Two out of the three nominees were QNX-based systems (the Garmin K2 was the other), so our odds were good. I’d rather that we never win another Best of CES award if it meant that one of our customers could always win instead.
   
• A number of people asked about the RIM booth and its absence. I explained that RIM was focusing on their launch at the end of January, and that since they wouldn’t have a new product to show the public, it didn’t make sense to be there. (It’s notable that Microsoft wasn’t there either, and Apple never is.) RIM was in Las Vegas in a hotel outside the convention center, giving media private previews of the upcoming phones that seemed to be extremely well received. And we had a few of our RIM compatriots helping us out at the QNX booth as well.
   

That’s all I’ve got to say about CES 2013 — our best show yet. See you next year!

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.

Open source software in auto: a time that’s come (and gone)?

As mentioned in my previous post, Paul Hansen of the Hansen Report held an OEM panel at SAE Convergence. The panel was international in scope, with North America, Europe, and Japan equally represented through Ford, GM, Audi, Fiat, Nissan, and Toyota. Paul asked the participants to raise their hands if they would have any significant products based on the GENIVI open-source platform in production within the next five years.

The one punch
None of the panelists raised a hand. The answer caught me off guard so of course I immediately tweeted it (@truegryc). Though GM and Nissan are members of the GENIVI Alliance, they don’t have any GENIVI project with enough volume worth talking about. The other panelists aren’t planning to use GENIVI, either. (If BMW was on the panel, the total hands may not have been zero, but their singular stance would still be telling.)

The two punch
A similar question, about how OEMs could best utilize open source software, created an uncomfortably pregnant pause, with panelist members furtively looking at each other. Eventually, Ricky Hudi from Audi decided to tackle the issue directly. I’m paraphrasing his answer, but he said that open source software has not paid off as much as anticipated and that the risks of using it within automotive are still underappreciated.

Why not?
The sheer number of GENIVI members lends an impression of vitality. Despite that, we’ve seen GENIVI coming up as a competitor in automotive RFIs, RFQs, and RFPs less and less.

I have a few speculations as to why this is so. No OEM wants to spend tons of time and engineering effort to build something that helps every one of their competitors, and I don’t believe IP rights were clearly delineated from the beginning. As a committee-run organization, GENIVI seems to have responded sluggishly to new technologies; it also seems to have a conspicuously absent HMI strategy. And I think that people have figured out by now that building a production infotainment system is a hell of a lot harder than simply bolting a media player on top of your favorite OS.

Building communities
Does the lukewarm OEM response signal a rough road ahead for automotive open source software in general? Or for other up-and-coming replacements like Automotive Grade Linux? For the record, although I work for QNX Software Systems and our software isn’t open source, I definitely see value for open source in certain automotive situations. Open source provides a lot of value in broad efforts like building developer communities and fleshing out ecosystems. But open source isn’t the only way to accomplish these goals; they can also be achieved through open standards like HTML5, which is our approach at QNX. In fact, shortly after Mr. Hansen’s OEM panel, QNX’s Andrew Poliak held a Convergence session that focused on this exact point.

"Free" isn’t
Car companies often pursue open source with a single-minded goal of “getting software for free”. But within automotive, at least, using open source is not free. There are a lot of costs in producing software; licensing is just the part that impacts the Bill Of Materials. Non-recurring engineering costs, training, expertise creation, expertise retention, support, and licensing compliance add up: these items can easily overwhelm runtime license costs. Unfortunately, some companies have learned this lesson the hard way.

Can I get a roadmap? Amen!

I attended SAE Convergence last week, and I've got a couple observations that I'll be blogging about. Here’s the first.

The Panel
On the second day of the show, I attended a very informative OEM panel moderated by Paul Hansen. Paul asked the automakers what their suppliers could do to help them build their infotainment systems. Alan Amici from Fiat said, "I would like suppliers to share their roadmaps," to which the other OEMs nodded in agreement. On the surface, this seems like a rather gentle, generic request. However, I think it's actually a powerful insight that signals a fundamental change in our industry. Mr. Amici took a cue from our former president Theodore Roosevelt, speaking softly but carrying a big stick. Let me elaborate.

The History
If you stepped back in our way-back machine to three years ago or earlier, you'd find a persistent pattern. Every OEM would fully spec every software feature of every module. Which meant that every Tier 1 and software supplier, including QNX Software Systems, would have to jump through hoops trying to cut, fold, and tear their existing software to meet those custom specs. It also meant building tons of new software on top to fill the gaps. The reasoning here is pretty simple — an automaker is building a custom system, so why not build something that reflects exactly what they want? In this environment, we always presented our software roadmap and the OEMs would look politely, but it rarely influenced their designs. Instead, we ended up providing a completely bespoke version of our software stack.

The Change
About two years ago, we started to notice a powerful undercurrent in automotive that bucks this trend. Why the change? OEMs absolutely need to create consumer relevant products, and to reduce the time required to release them. More and more, they need to reuse rather than re-invent. Several OEMs at the forefront of this trend have already been exploring this. How? By working directly with the Tier 1 and suppliers to design the system with an eye towards heavy reuse of existing technologies, instead of trying to design each system from the ground up.

The Apps
This effort to reuse instead of recreate will be necessary not just to reduce the time of delivery, but also to enable any type of cross-brand app experience. Apps that live in app stores require a consistent set of APIs. It’s very hard to do that if every single OEM is busy customizing and recreating every aspect of the system software. The “we’ll design our own” approach will result in fragmentation even worse than that experienced by the Android community. Unconstrained, it carries the threat of creating dozens of independent silos, with no ability to share apps between car makers. It means dilution of the already small automotive volume into even tinier markets — one for each automaker — which doesn’t bode well for anyone building automotive apps. OEMs will need to buck the desire to customize everything if they want to build a thriving app community.

The Punchline
When automakers are focused on their value-add, like HMI designs and custom features, instead of reinventing plumbing, it helps everyone. The OEMs, the tier ones, and the software suppliers benefit from using a consistent platform amongst themselves. So Mr/Ms Carmaker: would you like to see our roadmaps? We'd absolutely love to share them. We’d even like to help build them with you!

This post originally appeared in Andy's True Gryc blog.

In-car infotainment and the art of doing more with less

Granted, the title for this blog post doesn't have the pizazz of, say, "Zen and the Art of Motorcycle Maintenance." (Are you old enough to even remember that book?) But it does capture the gist of a webinar that Andy Gryc will deliver next week.

His title for the webinar is "Squeezing high-end technologies into low-end infotainment systems." Admittedly, it's more direct than mine. Which is fitting, given that Andy has direct experience designing in-car systems. OnStar, for example.

But I digress. I'm sure you'd like to know what Andy plans to cover, so here's the overview:

Squeezing high-end technologies into low-end infotainment systems

Today's infotainment systems have it all – full multimedia, mobile device integration, POI-enabled navigation, speech recognition, high-resolution graphics, and cloud connectivity. The only problem is all of these features come with a big price tag.

Join Andy Gryc, automotive marketing manager, for this webinar, where he answers the question: Is it possible to build an infotainment system that meets today's customer demands with yesterday's price tag?

A 50-minute session (plus Q&A), this webinar covers a number of techniques to help slim down your next infotainment's BOM cost; it also suggests ways to target the luxury segment as well as the more cost-conscious, high-volume one with the same basic technology.

Date: Tuesday October 23, 2012

Time: 12:00 pm ET

Duration: 1 hour, including Q&A

Registration: Click here to register

Who should attend: Automotive software engineers and managers

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.

The hidden cost of ethanol

Because of the drought plaguing the mid-west, about 2.2 billion less bushels of corn will be produced this year. That correspondingly means a huge hike in corn prices, from $6/bushel in May to a record high of $8.50/bushel today, a 40% increase. That fact got me thinking about ethanol.

Oil independence sounds like a good thing, right? Grow our own fuel, from a renewable resource, without strip mining the land or polluting the earth. Who wouldn’t want that?



There seems to be a good deal of debate about how ethanol is produced and what impact it actually has. Massive lobbyists are on both sides—agribusiness on one side, and petroleum on the other—so it pays to look at where the information is coming from.

The unfortunate reality of current corn production is that it needs a lot of oil to keep it going. Fossil fuels are used for farm machinery, fertilizer, and pesticides. Raising corn uses a terrific amount of fresh water, which is not an unlimited resource. Because of these factors, raising corn for ethanol does not necessarily reduce the carbon footprint of your gas tank—in fact, it may increase it.

Some plants are much better than corn when it comes to carbon footprint, like switchgrass, algae, sawdust, or sugar cane. These all use either material that is already waste or much more of the plant. Corn ethanol the way it's made today uses at most 50% of the kernel—just the starch. The rest of the kernel, stalk, husk, cob, is cellulose waste that could be used, but current production methods can’t take advantage of it.

Unfortunately, you can’t pick where your ethanol comes from. I want a green tank, but I can’t choose the source of any ethanol I might buy. Because ethanol is primarily made from corn today, for now it would seem that the balance tilts away from ethanol as a truly green choice. That isn’t to say that all biofuels will always be problematic. There’s certainly something to be said for voting for further ethanol development and breaking our dependency on oil. But I feel that in the current biofuel environment, voting for ethanol is really just lining the pockets of agribusiness. We’ve gotten the “green” message ahead of the true bigger picture of the implications of ethanol production.

(But if you want to be truly green, your best bet is to be a vegan that bikes everywhere. That’s a little ambitious—even for me. As a compromise, just drive an electric car and charge it up with your windmill.)

Am I crazy for talking to my car?

Earlier this afternoon, I participated in a connected car panel at SpeechTEK 2012, hosted by our friend Mazin Gilbert from AT&T. The other panelists included Greg Bielby of VoltDelta, Thomas Schalk of Agero, and Hakan Kostepen of Panasonic.

Even though Mazin did a fantastic job, not every panelist had a chance to answer every question. I was itching to answer some, so here are my responses to the questions that I didn't get to answer, or where I feel I could have provided a more complete response.

Have speech technologies matured to the point where they can be used robustly in the car? The general answer to this question from the panel was yes, but I think the real answer is a qualified yes. The technologies exist, but often aren't applied or may need auto-specific adaptations to handle in-cabin noise or other issues. Natural language recognition was an oft-stated driving technology, but a missing piece to the puzzle is hybrid recognition. I don't mean pushing recognition wholesale to the cloud, like Siri does. I mean a true split of the recognition effort, where each part does what it’s best at. Put the front half of acoustic processing in the vehicle to clean up the audio and convert the waveform to frequency-domain data, then send the data to the cloud-based server. The cloud server can then parse and interpret the data, and send back the result.

Hybrid speech rec solves three problems at once: better audio signals (the car can improve audio specific to the in-cabin environment), better cost (frequency data is far more compressed than raw audio, so you pay less for data transfer), and better responsiveness (hybrid rec gives the server time to start working on the response while it's coming in instead of waiting for the whole utterance to finish before starting).

Is driver distraction a major business driver, or is it the "Siri effect"? Currently, the car industry seems to use driver distraction as a reason to push a lot of features into speech. Many of those uses are gimmicky. Personally, I don't care if I can set my climate control system with voice — why would I when I can simply turn a dial? I once had someone ask me about the feasibility of adding voice recognition commands for rolling down the windows. I asked him, "Yes, but wouldn't people just push the window button?"

We shouldn’t implement speech commands just because we can. They may have contributed to excitement in the early adopter crowd, but we're beyond that now. Mind you, there are some seriously useful ways to use voice. For instance, any time you need to pick from a huge number of choices, voice recognition is the natural way to go. Calling contacts ("Call Sarah Potter"), entering destinations ("Go to 3121 South Park Street"), or picking music ("Play Audioslave") are all much easier than using an HMI to enter the same information, and safer to boot. It just has to work consistently and accurately.

Will car makers see more speech moving to the cloud, or will it be a hybrid of cloud and embedded? I disagree with the majority of the panel on this one, and, I think, the majority of people in the industry. Most auto people believe a hybrid between embedded and cloud allows the best of both worlds — good recognition and updatability when connected, and consistent reliability when not. My colleague Andrew Poliak also champions this view with a memorable catch phrase: Zombie Apocalypse. That is, you still want the system to work, albeit partially, when the infrastructure isn't available.

But if you ask me, everyone is missing the point — theirs is a technology-centric point of view. Everyday customer acceptance of a particular technology is notoriously harsh: if it doesn't work well, it gets rejected out of hand. Good cloud solutions beat an embedded solution hands-down; they just need some improvements (see my hybrid bullet above). Once a customer experiences a good solution, they will become frustrated with one that performs poorly. In my opinion, it's better not to offer the service at all, than to try a graceful degradation of capability, because most customers won't understand or care. Spend the effort instead on making sure you always have an acceptable cloud connection — either through multiple redundant mechanisms or a car-based powerful antenna — and you'll be better off. Even when the car knows some data that the cloud doesn't (like a mobile's contact list or music selection), there's no need to handle that on the embedded side. The cloud recognition server is powerful enough to not require the data set a priori. And I think we can predict an eventual migration of phone data to cloud-based data (or cloud-synchronized data) that makes the car's knowledge either easily transferrable or less relevant.

Who makes money, and how, from voice-enabled agents or voice services? This was one of the best questions of the panel, because nobody really knows the exact model, but everybody agreed that customer tolerance is very low. The most likely candidate is ad-based revenue. This doesn't mean reading ads aloud to the driver, but rather, positively influencing search results for either active or temporary situation-based points of interest (POIs). Depending on how valuable the service is to the driver, there will still be an option for service-based payments and high-value apps.

Standards and building mobile apps — will it come? You need standards if you want to build an app platform that will promote application creation and adoption. That's what we're doing with the QNX CAR 2 application platform — creating a way for someone other than the car companies to join the ecosystem and to deploy their apps to the car in a controlled way. But don't forget, you need a standard way to deploy apps for the cloud half of the recognition, too.

To close, let me share two photos. One was taken outside the Marriott Marquis, the hotel hosting the conference just off of Times Square in NYC. The other is from our PR agency, Breakaway Communications. What do they have in common? Wooden water towers. Sorry, I couldn't help myself; I just love those things. They just look so quaint in a city full of glass and brick.

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.
 

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!
 

Rockin' the phone at BlackBerry World

I'm at BlackBerry World 2012 (as you already know if you're following my tweets), and it really is amazing.

In his keynote, RIM's CEO Thorsten Heins provided stats on how the average BlackBerry user isn't just connected, but hyper-connected. BlackBerry users engage in more social media, use more organizational tools, and download more apps per day than other smartphone users. (I wasn't quick enough to type up all the stats, but I'm sure you can find them elsewhere.)

Introducing the BlackBerry
10 dev alpha device

Is the BlackBerry platform an entertainment tool? Productivity tool? Social media hub? All of these, but more than anything else, BlackBerry creates success. The 77 million BlackBerry users worldwide are more agile, productive, competitive, and nimble than their counterparts.

Here are some great factoids I was able to capture:

• Mippin is a worldwide mobile development shop responsible for 50,000 apps on iOS, Android, and BlackBerry. But BlackBerry accounts for 70% of their downloads.
   
• Occipital offers a very cool panorama camera app, which they demo'd this morning. It took them only 7 days to port to BlackBerry 10, and it already performs better than the Android version.
   
• Fishlabs creates mobile games. It took them one day to port Galaxy on Fire to the BlackBerry PlayBook tablet. (And it is one awesome app — I gotta go download it tonight :-)
   
• App World for the PlayBook underwent 240% growth in Q4 2011.
   
• 90% of Fortune 500 companies standardize on BlackBerry.
   

Stay tuned for more pix and reports from what promises to be an awesome show!

Autonomous cars? Surely, you're joking

No, I'm not. And stop calling me Shirley.

Five years ago, I would have called someone nuts if they said cars would soon be driving themselves. But next week, I'm going to say just that. On Monday I'm headed to Detroit for the 2012 SAE World Congress, and the rise of driver-less cars is one of the points I'm going to make as part of a panel on the future of telematics.

Saying that cars could or should drive themselves might get some people up in arms.  Am I advocating taking away the driver's rights? What happened to The Ultimate Driving Experience? What about Fahrvergnügen?

I enjoy driving as much as anyone. And yes, generally, I want to be in control of my car. But I see the writing on the wall, and it comes from three things:

Elderly boomers
My grandfather told me once a couple years before his death that drivers today were so rude

—they were always giving him the finger. I sympathized, until I took a ride with him. I white-knuckled it the whole way as he drove 40 mph in a 70 zone, straddling two lanes of traffic and getting plenty of hand gestures all the way. He didn't drive for much longer after that, fortunately for him and everyone else on the roadway.

My dad is still a good driver, but slowly and surely, my parents are getting there. What happens when all the boomers lose their ability to drive safely? Especially in North America, where distances are so long and independence is a given?

Gen AO
Otherwise called Generation Always On, this group includes anyone who picks their car based on their phone, rather than the other way around. There's a whole generation of people whose need to connect and socialize is far stronger than their need to drive. I'd argue this narrow generational definition could be extended to almost all of us at one time or another.

How many of us (not asking for hands) have been guilty of glancing at their phone while driving? Okay, now how many of us have seen other drivers drift a little too far out of their lane (looking at their phones, presumably) and then all of a sudden snap back to their lane? Right, me too.

Google
It's not just Google; it's also a bunch of very smart and driven (pun intended) people at lots of universities and high-tech companies. Google has motive: it can generate a lot more ad revenue if people are searching, and people can search a lot more if they're not driving. University researchers also have motive: Driver-less cars pose a very challenging problem that would be prestigious to solve. What's more, Google's proven it can be done—on real roads—with their driverless car. Enough that they convinced Nevada to pass a law allowing autonomous cars, with other states soon to follow.

Add those three things together, and what do you get? Yep—driverless cars, sooner than you might think. If I get to the point where I'm endangering others, I'll willingly let my car drive, rather than give up mobility. And wouldn't we all be a little safer if cars came with a cruise-control-like automatic pilot? Yes, I'm sure we would. This is the one thing that could permanently solve any form of distracted driving: a human not driving. I was never was much for Knight Rider, but KITT? Bring it on.
 

Everything you wanted to know about HTML5 in the car, Part III

Welcome to the third installment in my Q&A series on HTML5 in the car. In Part II, we looked at web servers, native plug-ins, instrument clusters, and display updates. This week, we turn our attention to tools, touch gestures, UI performance, and vehicle resources.

Are there any HTML5 HMI builder tools available?
Most of the well-known IDEs, including Eclipse, Dreamweaver, and Netbeans, support some flavor of HTML5 in their latest release. Adobe Edge, a new tool now available in preview, also lets you create animated HTML5 content. I suggest you check out the HTML5 Tools site, which publishes up-to-date tool reviews.

Often, automotive customers will ask system designers to make an infotainment system work "like an iPhone,” with the popular gesture controls. Does HTML5 support "inertial" menus and two-finger zoom?
Multi-touch is handled at the app level; here’s an example. Pinch zooming at the browser level is browser-dependent — the QNX browser handles it, but not every browser does. As for physics-based scrolling, HTML5 doesn’t support it “out of the box”; it needs to be added. Frameworks like Sencha Touch provide these types of controls.

Will the performance of HTML and JavaScript be adequate for critical user interface components or computations, such as safety-related notifications?
This has to be tested on a case-by-case basis. For the UI elements, yes, the performance should be adequate. Our testing indicates you can build HMIs that are surprisingly responsive. Also, our WebKit port lets you do things things like run JavaScript code in other tabs, threads, or processes to ensure those ocmponents aren’t being thread-blocked by something less critical.

I do get a little gun-shy recommending HTML5 for safety-critical components, because JavaScript isn't inherently real-time. If you wouldn't feel comfortable using Java for a critical coding task, you shouldn't use HTML5 either. If you want predictable, real-time performance for a lower-level computation that cannot tolerate any delay, the code should execute in a non virtual-machine environment. Most code doesn’t really fit that description, so most of the time JavaScript should work just fine.

How do you call vehicle resources — vehicle HMI, vehicle diagnostics information, etc. — on a HTML web app in the car? What's the process in plain words?
In plain words, it’s kinda hard. :-) But here’s my best take on this question: we solve this by creating a vehicle-bus driver that exports data through a publish/subscribe mechanism. The HTML5 layer talks to that piece through a JavaScript interface.
 

Everything you wanted to know about HTML5 in the car, Part II

Welcome to the second installment in my Q&A series on HTML5 in the car. Last week, we looked at CSS, cross-platform execution, and asynchronous design. This week, we turn our attention to web servers, native plug-ins, instrument clusters, and display updates.

If I don’t use a web server in my infotainment system, will I miss out on some features of HTML5?

A web server isn’t strictly necessary, but there are two very good reasons for including one. First, it lets you export a user interface to devices outside the car, thereby allowing mobile phones or tablets to run apps that are hosted on the vehicle head unit. Second, it lets you export internal car resources, as a URL, to HMI software running in the head unit. For instance, the web server could provide the HMI with access to static vehicle-configuration data (through an xml file) or to a back-up camera (through a video stream).

Will using native code plug-ins compromise my ability to leverage HTML5?

This is tricky, because a lot of things you want to do may require native code. So, yes, use native code, but do it judiciously. The more native code you use, the more it will limit the cross-platform capability of the HTML5 code that relies on it. The good news is that with HTML5 gaining so much functionality, plug-ins are needed far less than ever before.

A sample climate control app from the
QNX CAR 2 platform, created with HTML5.

Would you consider HTML5 as an option for cluster instruments: speedometers, tachometers, etc.?

At this point, I’d say no. HTML5 makes a lot of sense for in-vehicle infotainment, but it doesn’t provide the response needed for a vehicle cluster and it won't ensure safety-critical certification. Plus, the instrument cluster isn’t where you realize a lot of HTML5’s value: downloadable apps, connectivity to mobile devices, and so on. If the cluster and the infotainment system eventually merge into one big screen, then it’s more likely you could use HTML5 for both — but that’s still a few years out.

What’s a good way to get responsive display updates (10Hz update) into HTML5? Websockets?

If you need to deliver high-speed updates to your head unit, Websockets is one way to go. Make sure, however, that you don’t stall the rest of the JavaScript engine while your main thread is blocked on tasks. If you create another thread to monitor for changes, you can do it just as effectively (and probably with less work) with a JNEXT or NPAPI call into native code.
 

Everything you wanted to know about HTML5 in the car, Part I

My HTML5 webinar generated a lot of interesting dialog about what HTML5 means for in-vehicle systems. People asked questions about everything from security and performance to WebGL and cross-platform execution. Many of the same questions come up with when I speak with customers and analysts, which got me to thinking: Why not address them in this blog?

So without further ado, here is the first of my "FAQs" on HTML5 in the car. If you have a question and you don’t see it answered here, leave a comment and let me know! I’ll try my best to answer it in a future post.

How can you create multiple in-vehicle user interfaces using a single HTML5 code base?
The key to achieving this is the Cascading Style Sheets language, or CSS.

CSS controls the look and feel of web pages, but it can also be used to control the look and feel of a vehicle head unit. By changing a single CSS file, you can, for example, change all the fonts and background colors in a website (or head unit) from Arial and white to Verdana and black.

Mind you, CSS does much more than that. It also lets you specify how individual tags in HTML documents are displayed: layout, margins, sizes, colors, behavioral characteristics, events, and so on. Consider, for example, a phone app accessed through the vehicle head unit. If that app provides an HTML5-based user interface, each OEM could provide a default CSS that controls how the app looks on the head unit, adapting the app to meet in-vehicle usability standards and, of course, branding it.

A sample app from the QNX CAR 2 application
platform, created with HTML5

Let’s say your phone has an HTML5 navigation app that you want to run in your Audi today and your Chevy tomorrow. Although the phone serves up the app content identically in both cases, the Audi system can use a CSS to ensure that the app looks ‘Audi-like’, with that distinctive black and silver coloring, and the Chevy system can use a CSS that gives it the app the look-and-feel of OnStar. In effect, CSS can give the OEM more control over brought-in applications than other types of ‘screen replication’ technologies, like MirrorLink or iPod Out.

Keep in mind, though, that CSS can’t solve different OEM input philosophies, such as touch, hardkey, softkey and so on. You could use CSS to change the appearance for different inputs, but you would still need to have JavaScript hooking things up underneath.

You mentioned that cross-platform execution is a key benefit of HTML5. Do you have any recommendations on how to implement it?
Cross-platform execution is definitely something you want to keep in mind when designing software for vehicle head units. If you’re careful to ensure your app avoids features specific to the embedded environment, you can use mobile and embedded apps with the same HTML5 code base. It shouldn’t be difficult to make sure your app runs in both environments, but it’s better to plan for this going into design. That way, you can avoid using anything that prohibits cross-platform execution.

Could HTML5 replace the current HMI systems in head units that support multiple applications, and still be event driven and asynchronous in nature?
Definitely. JavaScript in HTML5 supports the concept of separate threads, called workers, that can handle events asynchronously. Although workers have some restrictions, such as the inability to modify the Document Object Model (DOM) or access globals, they should still be able to handle most asynchronous events. Maximum flexibility may require additional support from the HTML5 engine. To that end, QNX Software Systems has invested a lot of time in improving WebKit to allow code to run in separate engine web views, in different threads, in different processes, and even in completely independent HTML5 engine instances.

Stay tuned for Part II, where I plan to tackle questions on web browsers, web servers, and instrument clusters.
 

HTML5 Hackathon

Learn how to put together HTML5 apps at the HTML5 Hackathon. You'll get hands-on experience with WebWorks, which is the BlackBerry tool for building applications with HTML5.

That'll get you primed for building HTML5 apps for the QNX CAR 2 application platform!

The Coolest Cars at NAIAS

Here's the Cliff Notes version of North American International Auto Show industry preview. (Cole's notes for my Canadian followers.)

The show was a great one, especially compared to last year. Industry people were there from across the globe, and most of the exhibits were packed. (The pictures below that were absent of people required patience, timing, and retakes.)  NAIAS was strong, despite some debate about how it may be losing relevance with Europeans or Asians. Jaguar LandRover was missing this year. But it's still the show where the big three pulls out all the stops; very few other major automakers want to risk being absent.  Cobo hall was filled with absolutely massive displays of new models, concept cars, and interactive displays from Audi, BMW, Chrysler, Daimler, Fiat, Ford, GM, Hyundia, Kia, Toyota, Volkswagen, and many others.

There was a lot to see.  Unfortunately due to my other show duties, I didn't get a lot of time on the show floor.  What I saw was pretty darn cool, and here are the highlights.

Smart Art





Not your father's Mercedes




Honda Fit - an Insightful design



The ultimate jacked suspension on a Ford Raptor

F-150 King Ranch.  Sweet! (Except I don't do leather)

Chevy Miray concept.  Holy gull-wing, Batman!

Miray from the back looks just as wicked

TRU 40S — another very cool GM concept.  Love the white satin  finish

Lexus LF-LC.  Concept based on Lexus LFA.  Looks fast (that's why it's blurry).

LF-LC from the rear.  This is the view you'll normally have, but far smaller.

Nothin' but sliver Porsches.  Drool.

VW Bugster.  Combination bug and roadster.  Huh.

Via.  Don't know what it is, but it sho' looks cool.

Audi R8GT.  Nice side vents to cool off those brakes.

I just liked this mini hung up on the wall.  Looked cute — want one in my den.

BMW concept car.  Tron, anyone?

BMW Active Hybrid; a little more practical than the above pic

Audi e-tron

Audi RS 5 Coupe -- aggressive grille!

Another Smart concept car--perfect for the city (bikes in the back)

Chrysler 700C.  Now this is a minivan any man would agree to

Another view of the 700C

300SRT8.  Didn't know SRT made normal cars

SRT Challenger

SRT Yellow Jacket - Starsky

SRT Super Bee - Hutch