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.
 

Read More

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.
 

Read More

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.
 

Read More

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.
 

Read More

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!

Read More

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

Read More

Next week: CES, CTS, AT&T, NAIAS. Phew!

It has been a hectic week back from Christmas vacation trying to get all the last minute preparations ready for the Consumer Electronics Show (CES), the Consumer Telematics Show (CTS) in Las Vegas and the North American International Automotive Show (NAIAS) in Detroit.

CES has become a  "must attend" show for automotive, due to the continued convergence between the consumer and automotive industries. (Yes, that's an intentional pun, and SAE Convergence is this year, but thankfully not until October.) Our CES QNX booth is tucked right behind the RIM booth #30326 in the main hall. We'll have some really cool new demos that you'll definitely want to check out! I can't give you details until next week, but trust me they are worth the wait.

We've got QNX representatives speaking both at CTS, which is the Monday before in Mandalay Bay, and at the AT&T Developer Conference which is the Sunday and Monday before at the Palms hotel.

And finally there's NAIAS at Cobo Hall.  I'm skipping CES this year to give some love to my home town.  I'll be back in Detroit, keepin' it old school. If I don't see you there, look me up. Peace out.

Read More

I've always wondered about Android support...

My colleague Jeff Schaffer sent me this link, which gives an interesting analysis of Android support on various devices.

Clearly, it's pretty tough to stay on top of the Android release game. One very good reason for car makers to be wary, as they'll be bound to move even slower than handset makers.

Read More

Adobe’s out of mobile? Read the fine print

The blogosphere is a-buzz with Adobe’s apparent decision to abandon Flash in mobile devices. I get the impression, though, that many people haven’t bothered to read Adobe’s announcement. If they did, they would come away with a very different conclusion.

Let me quote what Adobe actually said (emphasis mine):

"Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer adapt Flash Player for mobile devices to new browser, OS version or device configurations. Some of our source code licensees may opt to continue working on and releasing their own implementations. We will continue to support the current Android and PlayBook configurations with critical bug fixes and security updates."

What’s being discontinued is the Flash plug-in for mobile browsers. Adobe will still support and work on Mobile AIR, and on the development of standalone mobile applications.

A number of cross-platform applications today are implemented in Adobe AIR, and that’s staying the same. Adobe is being smart — they’re picking and choosing their battles, and have decided to give this one to HTML5. We’re big believers in HTML5, and Adobe's announcement makes complete sense: Don’t bother with the burden of Flash plug-in support when you can do it all in the browser. You can still build killer apps using Adobe AIR.
 

Read More

BBDevCon — Apps on BlackBerry couldn't be better

Unfortunately I joined the BBDevCon live broadcast a little too late to capture some of the absolutely amazing TAT Cascades video. RIM announced that TAT will be fully supported as a new HMI framework on BBX (yes, the new name of QNX OS for PlayBook and phones has been officially announced now). The video was mesmerizing — a picture album with slightly folded pictures falling down in an array, shaded and lit, with tags flying in from the side. It looked absolutely amazing, and it was created with simple code that configured the TAT framework "list" class with some standard properties. And there was another very cool TAT demo that showed an email filter with an active touch mesh, letting you filter your email in a very visual way. Super cool looking.

HTML5 support is huge, too — RIM has had WebWorks and Torch for a while, but their importance continues to grow. HTML5 apps provide the way to unify older BB devices and any of the new BBX-based PlayBooks and phones. That's a beautiful tie-in to automotive, where we're building our next generation QNX CAR software using HTML5. The same apps running on desktops, phones, tablets, and cars? And on every mobile device, not just one flavor like iOS or Android? Sounds like the winning technology to me.

Finally, they talked about the success of App World. There were some really nice facts to constrast with the negative press RIM has received on "apps". First some interesting comparisons: 1% of Apple developers made more than $1000, but 13% of BlackBerry developers made more than $100,000. Whoa. And that App World generates the 2nd most amount of money — more than Android. Also very interesting!

I can't do better than the presenters, so I'll finish up with some pics for the rest of the stats...

Read More

QNX Auto Summit Japan 2011

How many car guys does it take to change a light bulb?  Three normally, but only one if you've already lifted  the engine block out of the way!

There's an actual reason for this joke which I'll explain in the epilogue.  But let me shamelessly segue: there's a whole room full of car folks here in Nagoya, and they're working on something which needs a good more heavy lifting than needed to change that troublesome light bulb.  They're building tomorrow's car systems.  To help, QNX is hosting a full day event here in beautiful Nagoya, covering what the latest goings on are in the automotive space that's near and dear to our hearts--in-cab vehicle electronics.

Getting seated before the day begins

Our first presenter was Dr. Motoyuki Akamatsu, who broke the ice with a very entertaining video about an early 1966 study on driver distraction.  The driver is wearing a device that looks like a giant eyelid that closes over his face on regular intervals, occluding his vision.  The driver is coincidentally also the narrator, calmly describing the whole experiment as his view of the road is completely blocked every couple seconds or so.  This is all while normal traffic is flowing around his car, totally unaware that this test driver could run into them at any moment. What they got away with in the sixties! The rest of his talk was equally informative; Akamatsu-san talked about how modern testing for driver distraction is done, and how mobiles can impact that.

I gave a talk about picking the right HMI (or UX if you prefer) framework for automotive infotainment.  There's a ton of choice out there--HTML5, Adobe AIR, Qt, Android, Meego, EB Guide,  OpenGL ES--I could go on and on. There are a lot of things to consider.  Given that I didn't have an abundance of time and that it was all being dynamically translated into Japanese, I couldn't cover as much as I might have wanted.  Look for a future blog from me where I can give the topic a little bit more space.  (Mini-spoiler alert: I've listed my favorite first.)

The president of ARM Japan gave a talk about ARM use in vehicles. A short summary: ARM processors are on the rise everywhere in the car, and trending upwards. ARM licensed 6 billion CPUs last year, and they predict 100 billion devices by 2020.  Japan is probably the only area where they aren't dominating (yet). A short roadmap then was presented about Cortex family--A8, A9, A15, and A5. Also he talked about the ARM M series. I must apologize that my jet lag affect my attention span during ARM M series (that architecture is almost irrelevant in infotainment, if that's an excuse). He also talked about ARM's Mali GPU built on Midgard architecture (supporting both OpenGLES 2.0 and DirectX9). 

Alex Kinsella of RIM gave a talk about separation of personal and enterprise use of devices, in a way that gives simultaneously more freedom for the user and more options and security for the enterprise.  All very cool stuff for enabling more OEM options to the vehicle.

Our very own Andrew Poliak talked about the various different connectivity options between cars and mobiles--both where we are today (MirrorLink, iPod Out, Remote Skin/BlueTooth SPP+A2DP) and where we see that they're going (HTML5, HDMI/MDL, USB 3.0).

Andrew explains OEM's evolving needs and timelines

Roger Lanctot of Strategy Analytics had a lot of interesting things to share about their in-depth research, covering current industry trends and some of Roger's predictions.

• Global smartphones are right now 38% of the mobile market, with all signs of growth.
• You need good traffic info that's predictive.  If it's not, its worthless, and navigation and traffic services are still the biggest customer desire out of an in-car system.
• Solve distraction problems before they are regulated out by governments.
• Apps in the car will be very important.  Their research shows over 55% buyers (world wide average) want it.  OEMs though take note--this will sell cars, but there's no profit in it for the OEM themselves.
• Many different connectivity options exist. Nobody has hmi nailed yet, so there's a big opportunity to get it right.
• HMI solutions are converging on mobile device communications.

Roger lists every mobile connectivity solution known to man

Probably most emphasized facts of Roger's presentation were about China.

• China is important. If you don't play there you're writing your own ticket for irrelevance. It's the fastest growing automotive market, with a rich aftermarket space.
• China infotainment solutions are like the wild west right now, and include some crazy displays that Roger showed us with dozens of touch buttons.  They've even got systems that have the ability to create and edit docs while driving! Microsoft Word at 70mph, here I come!  I can't wait for the next IDE to have in-vehicle recognition so I can program while driving.  
• China has exceedingly complex HMIs with apparent disregard for any regulations that might exist. 
• China is not the safest place.  They've got tons of new drivers, new infrastructure, and growth rates that exceed their experience.  The World Health Organization estimates 200,000 vehicle fatalities (significantly higher than China's officially reported numbers).  That's around 18% the world total vehicular fatalities.  Wow.

Finally, our VP of Sales and Marketing Derek Kuhn ended up with a description of where QNX is going for the future automotive platforms with QNX CAR 2.  In a word?  Awesomeness.  (Coincidentally, this is Derek's favourite word.) In ten? Full support for almost everything car makers ever dreamed of. 

We wrapped up the day with a cocktail hour for all our guests and some Formula 1 race day ticket give-aways to some lucky attendees.  

Guests having caught their taxis or trains, and the show nicely wrapped, the QNX staff gave secret surprise birthday wishes to our Alison Canavan, the world's best event coordinator, and to the world's most thoughtful person and our Auto Summit Japan emcee, Kosuke Abe.

All in all, a very busy and successful day.  I'm pooped.  And that's a wrap.

You've probably forgotten about the car guy lightbulb joke already, but I'll finish explaining it anyway. My girlfriend had one of her car's headlights burn out, and she asked me if I could fix it. My male chivalry and handyman pride made me jump at the opportunity to help! I naively went out to the car with a screwdriver, expecting to maybe loosen the screws around the light enclosure, pop out the bulb, put in the new one, and dust off my hands for a well deserved beer in one minute flat. It became immediately obvious that Honda had something much more nefarious in mind when they built the Civic. No screws.  You had to remove the bulb from the back, but there wasn't any obvious way for a human hand (well, no adult human, anyway) to fit in the allotted space.  I went back into the house, grabbed a handful of tools this time, and spent the next 20 minutes trying to figure out what parts of the car needed to be disassembled to get at the light bulb. This wasn't immediately fruitful either, so I went back in the house, consulted the Internet, and lo and behold--I wasn't just an idiot.  I found many other posts from many other delighted Civic owners.  It looked like the most popular solution was to remove the battery, battery cage and power steering pump mounts, lift the power steering out of the way, and then you could get at the bulb.  More of a challenge than I was really looking for, I'm afraid, so I went back to my girlfriend, tail between my legs, and shamefully recommended that she take it to the dealer.

I couldn't help smiling at her retelling of the dealer visit.  The first mechanic came out, all confident with a line something like "well, many guys don't really know how to do car stuff, so we'll take care of it."  Then he spent about 15 minutes digging around, trying to discover how on earth you get the stupid bulb out.  He finally had to call over his boss to get assistance.  They did end up replacing the bulb, but it was a little more complicated than he expected too! Tally it up--me and two mechanics--three guys to replace a light bulb. 

Good thing that building automotive software is so much easier.

Read More