Cyber security and connected cars

What does cyber security mean, what does it affect, why is it becoming critical, and what can you do about it? Those were some of the questions I addressed in a recent webcast on automotive cyber security, hosted by SAE International. I represented the software side of things and was accompanied by my hardware colleagues Richard Soja and Jeffrey Kelley, who work at Freescale and Infineon respectively.

I’ve hosted webinars on a variety of automotive and embedded software topics, but none with such an impressive range of participants. We had people from government organizations of several countries, not to mention automakers, tier 1 and tier 2 auto suppliers, telematics companies, mobile developers, concerned individuals, and even utility companies. And the range of questions and comments was equally diverse — from specific insights about elliptical encryption to sweeping “how does this affect society” musings.

My key takeaway: QNX isn’t alone in its concern for automotive cyber security. We have years of experience in building secure trusted systems and we’re excited to help customers build tomorrow’s secure cars. Nice thing is, the rest of the world is starting to get on board as well.

If you're interested, you can download the archived version of the webinar.

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.

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.
 

What's the word on HTML5?

Ten videos on HTML5 in the car. Actually, there are only nine — but I'm getting ahead of myself.

Paul Leroux

Has it been two years already? In November 2011, a group of my QNX colleagues, including Andy Gryc, launched a video series on using HTML5 in the car. They realized that HTML5 holds enormous potential for automotive infotainment, from reducing industry fragmentation to helping head units keep pace with the blistering rate of change in the mobile industry. They also realized it was important to get the word out — to help people understand that the power of HTML5 extends far beyond the ability to create web pages. And so, they invited a variety of thought leaders and industry experts with HTML5 experience to stand in front of the camera and share their stories.

All of which to say, if you're interested in the future of HTML5 in the car, and in what thought leaders from companies such as OnStar, Audi, Gartner, Pandora, TCS, and QNX have to say about it, you've come to the right place. So let's get started, shall we?


Interview with Steve Schwinke of OnStar
Andy Gryc catches up with Steve Schwinke, director of advanced technology for OnStar, who is bullish on the both the short- and long-term benefits of HTML5:




Interview with Mathias Haliger of Audi
Derek Kuhn of QNX sits down with Mathias Haliger, head of MMI system architecture at Audi AG, who discusses the importance of HTML5 to his company and to the industry at large:




The analyst perspective: Thilo Koslowski of Gartner
Andy gets together with Thilo Koslowski, VP Distinguished Analyst at Gartner, to discuss the notion of controlled openness for the car — and how HTML5 fits into the picture:




Interview with Tom Conrad of Pandora
Andy meets up with Tom Conrad, CTO at Pandora, to get his take on the benefits of standardizing on HTML5 across markets:




Interview with Michael Camp of TCS
Andy Gryc sits down with Michael Camp, director of engineering for in-car telematics at TeleCommunication Systems (TCS), to get a software supplier's perspective on HTML5:




Interview with Matthew Staikos
Andy talks with Matthew Staikos, former web-technology manager at BlackBerry, about the impact of HTML5 on hardware options, memory usage, and app stores:




The myth buster interview
Andy and Kerry Johnson get together to discuss how HTML5 apps can deliver snappy performance, run without a Web browser, and even work without an Internet connection:




Interview with Sheridan Ethier
Andy drops in on Sheridan Ethier, manager of the QNX CAR Platform development team, to get a developer's perspective on HTML5:




Kickoff video
And last but not least, here is the video that started it all. Andy Gryc gives his take on why he believes HTML5 is destined to become the foundation for next-gen automotive apps:




Blooper video
Did I say last but not least? Sorry, I have one more video that you just have to see:

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.

What happens when autonomous becomes ubiquitous?

Seventeen ways in which the self-driving car will transform how we live.

Let’s speculate that at least 25% of cars on the road are autonomous — and that those cars are sufficiently advanced to operate without a human driver. Let’s also assume that the legal issues have been sorted out somehow.

How would this impact society?

• The elderly could maintain their independence. Even if they have lost the ability to drive, they could still get groceries, go to appointments, visit family and friends, or just go for a drive.
   
• Cars could chauffer intoxicated folks safely home — no more drunk drivers.
   
• Municipalities could get rid of buses and trains, and replace them with fleets of vehicles that would pick people up and drop them off exactly where they want to go. Mass transit would become individual transit.
   
• Car sharing would become more popular, as the cost could be spread among multiple people. Friends, family members, or neighbors could chip in to own a single car, reducing pollution as well as costs. The cars would shuffle themselves to where they are needed, depending on everyone’s individual needs.
   
• Fewer vehicles would be produced, but they would be more expensive. This could drive some smaller automakers out of business or force more industry consolidation.
   
• Cities could get rid of most parking lots and garages, freeing up valuable real estate for homes, businesses, or parks.
   
• Taxi companies would either go out of business or convert over to autonomous piloted vehicles. Each taxi could be equipped with anti-theft measures, alerting police if, say, the taxi detects it is being boarded onto a truck.
   
• We could have fewer roads with higher capacities. Self-directed cars would be better equipped to negotiate inter-vehicle space, being more “polite” to other vehicles; they would also enable greater traffic density.
   
• Instead of creating traffic jams, heavy traffic would maintain a steady pace, since the vehicles would operate as a single platoon.
   
• Autonomous cars could completely avoid roads under construction and scatter themselves evenly throughout the surrounding route corridors to minimize the impact on detour routes.
   
• There would be no more hunting for parking spots downtown. Instead, people could tell their cars to go find a nearby parking spot and use their smartphones to summon the cars back once they’re ready to leave.
   
• Concerts or sporting events would operate more smoothly, as cars could coordinate where they’re parking. The flow of vehicles exiting from events would be more like a ballet than a mosh pit.
   
• Kids growing up with autonomous cars would enjoy a new level of independence. They could get to soccer games without needing mom or dad to drive them. Parents could program the car to drive the children to fixed destinations: sports game and home.
   
• School buses could become a thing of the past. School boards could manage fleets of cars that would pick up the children as needed by geographic grouping.
   
• You could send your car out for errands, and companies would spring up to cater to “driverless” cars. For example, you could set up your grocery list online and send your car to pick them up; a clerk would fill your car with your groceries when it shows up at the supermarket.
   
• Rental car companies could start offering cars that come to you when you need them. Renting cars may become more popular than owning them, since people who drive infrequently could pay by the ride, as opposed to paying the capital cost of owning a vehicle.
   
• Cars would become like living rooms and people would enjoy the ride like never before — reading, conversing, exercising, watching TV. Some people may even give up their home to adopt a completely mobile existence.
   

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.

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

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

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.

QNX Auto Summit Japan 2011 – ‘Automotive at the speed of Mobility’

The QNX Auto Summit Japan 2011 will be starting soon, here in Nagoya, Japan.  We’re expecting a good crowd of Tier 1s and OEMs from across Japan.  QNX technology is being showcased in a BMW X5 and Audi A8 - as seen below - as well as in many of our partner demos.  The theme of the event is ‘Automotive at the speed of Mobility’!  Industry speakers will focus on how the worlds of automotive and mobility are converging at a break-neck speed, and what Tier 1s and OEMs will need to know to design for these next-generation systems.  Should be interesting!  Stay tuned for more.

Car Connectivity Consortium (CCC) MirrorLink meeting, Chicago, September 29, 2011

For those who aren't yet reset on "MirrorLink", it's the new term for what previously was called TerminalMode.  The name change is a definite improvement.  I informally polled people to ask them what they though when they first heard "Terminal Mode".  Basically the answers fell into two camps: either a telnet replacement or a disease you really don't want your doctor saying that you have. Neither sound like a real ringing endorsement!  MirrorLink as a term makes sense.  Good job CCC.

Here are some of my observations and notes from the CCC show in Chicago last week.

• MirrorLink will not be going away any time soon--there is enough industry momentum to keep it alive for a while.  Sounds like roughly 60% of the car makers and 60% of the mobile makers are behind it to some extent or another.
• QNX is very bullish on HTML5 as a replacement for MirrorLink-like features, but it doesn’t look like HTML5 is part of the future MirrorLink strategy at all.  Instead, they’re looking at HDMI or MDL—direct video from the mobile with a control channel.  This is a generic replacement for iPod out, and it's an approach that we've considered as well and will likely support, so this is a good alignment at least in direct video technology. Even though they don't see the wisdom of the HTML5 path yet (patience--they'll get there :-).
• OEMs don’t seem to realize how badly this will impact their revenue chain or are taking the "cross your fingers" approach.  Certainly many seemed to be focused solely on the value MirrorLink provides by enabling customers and building new markets.  I think it's somewhat Pollyanna-ish to not admit MirrorLink has the potential to completely decimate in-vehicle navigation uptake.  If I can bring my phone in for navigation for a half-way decent experience with a built-in screen, who's going to spend $3000 on a nav-only solution? 
• MirrorLink isn’t as focused as much on enabling third party apps (although they did talk about it), but more about mirroring custom-built phone apps into the car.  Everything that was demoed in the demo room breakout was a customized app that provided an integrated experience.  This is both bad and good.  Bad because it definitely reduces the short-term promise of opening up a huge third party ecosystem.  Good because I think it's the only reasonable way to go--there's really no other way OEMs can justify the liability of phone apps within the car, unless they can have some measure of control.
•  I still think that there's a significant amount of work they need to address safety concerns around driver distraction. MirrorLink the specification, and the general CCC communications contains "driver-safe" messaging.  However, my take is that the actual participation level people, especially on the mobile side seem to discount their accountability when you bring third party apps into the car, and nothing in the specification really makes it possible for an automotive outsider to make a car-safe app.  I highly doubt this approach will fly. The application level certification that is planned for a future MirrorLink 1.1 release seems almost a mandatory requirement before this issue can be put to bed.

Proposed app certification process

• Interestingly, almost every car company I talked to had a different take on how MirrorLink will impact their strategy—some see it as a low-end only play, but others see it as a high-end play.  There's still a lot of confusion as to where it slots into product lines.  I didn’t talk to anyone there who isn’t going to do it at all (not surprising given that the show was completely MirrorLink-focused), but some didn't seem to put a lot of weight behind it.  The perception I had was that some were doing it to "keep up with the Joneses."
• I give the CCC credit for realizing that MirrorLink has a lot of danger for the fragmentation whirlpool that has plagued Android releases and that makes Bluetooth interop the biggest nightmare for those who implement it and test it.  To that end, they're really trying to take this one head-on. It's still very early days to see if they will be successful, with the first MirrorLink 1.0.1 systems coming out in production.  (Alpine's aftermarket ICS-X8 earns that "first to market" distinction.) I hold out hope that CCC can keep MirrorLink interop from becoming a quagmire, but this is a bugger of a problem to fix in an area that tries to tie "slow-moving" car tech with the mobile space, so keep your eyes peeled...

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 and the W3C: setting a new standard

For almost two years, you’ve heard us talk about HTML5 in the car, particularly as it applies to the QNX CAR Platform for Infotainment. And now, we're taking the next step: working with the entire automotive community to develop a standard set of JavaScript APIs for accessing vehicle sensor information.

Andy Gryc (that’s me of course) and Adam Abramski (from Intel and representing GENIVI) are co-chairs in the World Wide Web Consortium (W3C) Automotive and Web Platform Business Group. Yes, our group name is a mouthful. But the translation is that Adam and I are working with W3C group members to create a standard that everyone can agree on.

Between GENIVI, Tizen, Webinos, and QNX, four different APIs are in use today. So what’s the process? All of these APIs have been submitted to the W3C group members as contributions. Those contributions form the groundwork, creating a baseline for where we need to go. Collectively as a group, we need to merge these four APIs — figure out the commonalities and harmonize the differences to create a new standard that takes the best features of all the proposals.

This effort takes some time, but the group intends to complete a first draft by December this year. Either Tina Jeffrey (my colleague, who’s doing some of the heavy lifting) or myself will be posting our progress here, so keep an eye out for our updates!

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!