Driving with the Invisible Man

A little more than a week ago, I had the pleasure of visiting Professor Alberto Broggi of Vislab and of University of Parma, Italy.  Dr. Broggi and I talked about autonomous cars and what they're doing to advance that field--all extremely interesting stuff. I got to see one of the famous orange vans that they took on an autonomous driving tour from Parma to Shanghai.

The best part though, was when he offered to take me for a drive in their current test vehicle. Of course, I jumped at the chance!  Here's a short video of a piece of the experience. To set the stage, we headed out on this test run: the prof and I in the rear seat, and one of his grad students in the driver's seat. We were following a lead vehicle driven by another student. The "driver" wasn't driving, but monitoring the system, and I could see that he wasn't using the steering wheel, brake or gas. Impressive!

What really made an impact was when we stopped. Professor Broggi's student got out, walked over to the lead vehicle, hopped in, and they took off. He had set our car to follow the lead car, and we drove off in a leisurely pursuit of the lead vehicle.  With nobody in the front seat.

It was a rush! It was an amazingly strange feeling, watching the car take us down the road, adjusting speed up and down smoothly, moving over from the shoulder to avoid pedestrians on the side of the road, and "observing" the traffic laws. Quite a unique experience, to be sure.

An experience I'm sure will be experienced by many people sooner than we think.

The Art Of The Possible, and why it drives me nuts

There are lots of phrases people misuse, and plenty deep is the corporate lingo cesspool. Art of the Possible is my latest favourite. It actually means something akin to "compromised effort", in that you're achieving what's barely possible, instead of something which should be an aspiration. For example, "Politics is the art of the possible" quoted from Otto Von Bismarck. I'm pretty sure he wasn't saying that politics is a wonder-world of delight.

However, I've seen it (and heard it) many times when trying to evoke some grand vision or a construction where anything is imaginable. Technology people seem especially prone to this--maybe because "possible" for an engineer is a much broader space. It always makes me cringe. For me it not only sounds like grandstanding, but it makes me immediately think of exactly the opposite of what the speaker was intending. It makes me think that the speaker is talking about something that barely works!

If I ever send you a link to this little old blog post of mine, it just means you've triggered my Art of the Possible abuse alarm.

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

-->

The panel

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 GM, Ford, Audi, Fiat, Nissan, and Toyota. Paul asked the participants to raise their hands if they would have any significant GENIVI products in production within the next five years.

The one punch

None of the panelists raised their hands. The answer caught me off guard so of course I immediately tweeted it (@truegryc). Though GM and Nissan are members of GENIVI, 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 them coming up as a competitor in automotive RFIs, RFQs, and RFPs less and less.

I have a few speculations as to why GENIVI hasn’t taken off as anticipated. 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 favourite 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 Sysems and our software isn’t open source, I definitely see value for open source in certain situations for automotive. 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 this; it can also be achieved through open standards, which is how we achieve it 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 free

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 in Detroit last week, and I've got a couple observations that I'll be blogging about. Here’s the first.

The Panel
The second day of the show, there was a very informative OEM panel.  The moderator, Paul Hansen, 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 quite 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
Stepping 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) would have to jump through hoops trying to cut, fold and tear their existing software to meet those custom specs. And 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 reduce the time required to release them. That means they will need to—more and more—reuse instead of re-invent. Several OEMs at the forefront of this trend have been already exploring this.  How? By working directly with the Tier 1 and suppliers to design the system with a 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 1’s, and the software suppliers benefit from using a consistent platform amongst themselves.  So Mr/Ms Carmaker: would you like to see our roadmaps? We would absolutely love to share them.  We’d even like to help build them with you!

HMI Tools Revisited

A little while ago, I wrote a blog about HMI design tools. I made the point that I thought many of these tools had challenges, from ease of use to code maintainability. I asked for feedback on that blog, and I got some. Some agreed with my viewpoint and some didn’t.

For example, I received some feedback about Elektrobit GUIDE from a QNX-er who used to work at Elektrobit. My colleague has direct knowledge of EB GUIDE, whereas admittedly I have none, so his feedback helps illuminate the other side of the story.

 Sample of EB GUIDE design with visual state machine

EB GUIDE is probably the best known and most widely used tool in automotive HMI development. According to my colleague, here are some of the features that make it a good fit for automotive:

• State-machine based. EB GUIDE lets you build the entire HMI without resorting to code. Constructing the HMI through state machines is more often closer to how the OEM supplies the specification. And it makes the final design more testable. 
• Integration of speech. EB GUIDE provides options to fully integrate speech recognition into the HMI—it can be coupled directly with the state machine. This is a pretty unique capability. 
• Simulation and testing. The ability to instantly simulate any model that you build is especially powerful, especially for designers. Most times, designers are left out of the loop—they need an engineer to see the realization of their work. Simulation gives them the ability to be self-sufficient. And test frameworks allow an OEM to guarantee that an implemented design is exactly as they’ve specified. 

Good feedback! Any other thoughts anyone wants to contribute?

The Pace of High Tech Life

How many times have you heard yourself or a colleague or a customer or a business partner say things like the following:

• I'm up to my eyeballs in work
• I'll have to get back to you once I get a breather
• I'm triple-booked; can you reschedule?
• Sorry--I dropped the ball on that
• I'm using lunch to dig myself out of email

Not to mention all the work emails timestamped after 10:00pm, or the fact your inbox already has 40 new emails when you get into work although you stopped checking it after dinner.  Its starting to become an unsustainable pace.

Here's a quintessential example--a picture taken of a colleague's inbox.  It's a little blurry, but if you can't make it out it says 1355 unread emails.  (I happened to take this pic when she and I were both on a conference call, and I've been too busy to ask her why on earth her inbox was that full.)

1355 unread emails?  Indeed, which is why I had to take a picture. There could be a lot of rational explanations about this, but here's one easy explanation.  I myself get roughly about 150 emails a day.  My coworker travels a lot, and she was gone the week before.  So, it's easily conceivable that this is just backlog from her trip for a single week.  That's just a sad statement for living high-tech today. I know that I'm busier than I've ever been, and every time I talk to anyone else (in my company or anyone else's), I always get the same reply--I'm swamped.

I've been thinking about blogging about this topic for a while, but ironically, I didn't have the time.  I did have time to tweet about it, earlier though.  (That's one of the things that makes me love Twitter--it's so much less of a commitment.)

How are you doing at your job?  Busy?  Yep, that's what I thought. Is it everyone in high tech? Is it endemic to the whole Western world? If you've got a spare 10 seconds, I'd love to get your comments.

Andy's Telematics Detroit wrap-up: how to make auto shows even better

Telematics Detroit was, for us, a good event again this year. The Jeep was a great success, with lots of people filling all four seats on a pretty constant basis, and lots of people waiting to see what HTML5 really can do. The show was busy and loud, even if you don't include the car alarm going off near the end of the event.  In the quiet of my hotel room, away from the clamour, I reflected on the event and came up with two main observations.

1) Telematics Detroit's main value is in networking. For industry old timers like me, it's always like a big reunion party.  It was great to see old friends from jobs long ago, friends who have done business with QNX for many years, and friends who have never done business with QNX but love us all the same.  It was great to build on our existing partner relationships, and to work on blossoming new ones. It's great to catch up with people, building up your own business-card sized slice into their personal career trajectory

More than ever, it's clear that the car app has finally taken hold.  I talked to many mobile developers who are targeting the car; we're helping them figure out how to bridge the mobile-car gap.

An anecdote shows how important networking is to this event. The Telematics Update party sponsored by Slacker had two live bands, an open bar, and cheerleaders milling through the crowd.  Telematics and Tonics (the event brought to life by my good friend and former boss John Correia, and sponsored by QNX, Agero, and Tweddle) was held at the same time across the street.  We didn’t have a live band, an open bar, or cheerleaders, but people still found our party a great place to mix and mingle.

2) I think that the sessions at many auto events need a face lift.  This isn't just about Telematics Update—it's a reflection of many shows I've been to lately.  I heard from a few people that they had walked out of talks after the first couple minutes, or that they generally thought the content of the sessions or the panels was not as valuable as they could be. Having done panels (yes, I did one this time) and speaking engagements (no, I didn't do one this time) at many shows, I think I can shed some light on why this is.
Every show has to organize months in advance, so abstracts are created months earlier, which allows them to schedule and print show guides, etc.  With this model, you're planning for what's going to be discussed several months ahead of time.  Is this time lag critical?  Sometimes it can be—if you're working in a fast paced industry, it may mean you're not going to be able to talk about something brand new.

There’s a bigger problem: the people you invite to speak are industry experts.  And experts are in high demand. Which means that they're multi-tasking and being pulled in many different directions all the time. The show content they need to deliver is just a small fraction of what they need to output each and every day. As it's so far in the future, it often gets prioritized low on the list, often only getting completed days (or hours) before the show.  Old material is often recycled, the presentation may be unpolished, and the slides may be uninteresting. This lack of ability to put quality time into creating a clear and concise message and refining it generally leads to presentations that are difficult to follow, or that add little value.

What would help? I can think of a couple things that could be tried:

• Don't use printed guides at all, and leave the content and abstracts flexible until days before the show. Also, keep the content automatically updated on a web site—why kill trees for no reason? Not committing to a specific topic months in advance means the material can be fresh and relevant to that very week.
• Except for the keynote, make the session rooms smaller and more intimate, and instead of having a one-way presentation that turns into a core dump, create open Q&A sessions around areas of expertise. This approach can encourage an interactive conversation that grows in the direction of audience interest, instead of potentially boring the audience or, even worse, going over their heads.  The speaker is an expert—they don't have to prepare anything, except be prepared to talk.  A panel session isn't exactly what I have in mind—even a panel is a little prescriptive and doesn't dig down into the details that can really engage the audience
• Create and enforce use of a standardized presentation template.  SAE does it. As a content creator, I have often cursed SAE’s policy, but it definitely drives consistency. SAE's template was less than attractive in years past, but this year it was actually decent. A standardized template has many advantages: it helps limit the number of slides and the amount of text on each slide; it also enforces appropriate image/diagram usage.  If done right, it can help presenters create something that works well for the size and expectations of the audience.

The argument against HMI modeling tools

I was recently asked by a customer whether or not I would recommend use of HMI modeling or code generation tools. I thought maybe everyone might not agree with my viewpoint, so to spark some discussion I’ve posted my response here.

Let me start with some disclosures. I have in the past used Rational Rose quite a bit. It's a UML code generation tool, not an HMI one, but there is a good deal of similarity. And I've used Adobe Flash, which has many of the same characteristics as the other HMI tools you've mentioned. But I haven't directly used HMI tools myself, so my response comes from analogy to Rose or Flash, but not from personal experience. For what it's worth.

That said, I think that modeling tools are good for building small (or disposable) models, and not as good for long-term or big scale projects. I think this can be chalked up to a number of factors:

• Ease of use. It seems like the ease of use of a modeling tool is a good thing, and it is. But it also enables creation of a working model without having thought it through completely. The tools are designed to be used in part at least by HMI specialists. Because HMI builders are not always software engineers, they aren't necessarily entrenched in the ways of good software development. You can end up with a rat's nest because the model grew organically. If you're building an HMI through code, you don't have a choice—you have to think it through first. This doesn't guarantee a good design, but I would argue it has to help.

• Maintainability. You can't keep the whole of the project in a visual language like state machines—you have to drop into script/code at some point, whether that coding is directly supported in the tool environment or not. The physical separation of state machine vs code leads to a mental break, and means that it's far harder to think about. You've got to do multiple conceptual jumps to write/read/interpret. I don't know if this in itself harms maintainability, but it seems to be a hindrance once the models get rather complex. The break between visual and scripting makes it also much harder to do simple tasks. Search and replace comes to mind, but it's even a problem just finding the code that you're looking for. I find environments like Flash exceedingly frustrating in this regard, especially when it comes to someone's code other than your own. Code snippets are scattered "willy nilly" throughout the model. It might make sense to the original author, but not always to the reader. It's also hard to comment the visual model.  "It's obvious, so you don't need comments!" That statement is only said if you've never maintained anyone else's code, and everyone else knows the truth. Software artifacts like design decisions, explanations, log tracking, or PR management cannot be reasonably kept in visual models, so you lose that connection with the past history of the code.

• Familiarity. Would you ever want to reuse your first C++ program? Nope. Me neither. There’s a reason why I never put my freeware Songbird Studio program into open source.  I was too embarrassed to let anyone see how awful my first try at C++ was. The first few models in any language are not a good reflection of what you could build with the tool once you’ve had a few disasters under your belt first. The subset of knowledgeable experts on most HMI tools is quite small. In most organizations, it can be zero to start with. That leads to a "weekend experiment" type of feel to some of the models.

If you have experts in a particular tool, I know they can create well-structured and maintainable models. I’ve seen experts in action, and then it’s a beautiful thing.  And it's also very well suited for applications where the behavior can be wholly contained within a state machine.  I also think these cases are the exception rather than the rule. If the model is small enough, it might not matter. My own personal guideline is that if the model has become too big to be readable on a single sheet of paper, it's probably going to be a problem for your average software developer.

(You may read this and think I’m an old school dyed-in-the-wool traditionalist, but for the record I’d like to point out that I use the Eclipse IDE and not vi.)

What do you think?  I'm certainly happy to be proven wrong--do you have experience with these tools that you can share?

Katimavik is on the chopping block!

If you're not Canadian (or an honorary Canadian), you won't know what Katimavik is.  As an explanation for my followers from other locations, it's kind of like the Peace Corp for Canadian teens.  It's a very successful volunteering program for helping install a sense of purpose, and giving kids some direction when they most need it. Like a light-weight, short-duration version of sending a kid to military school, but much more fun, and no stigma attached.  The kid gets to go to a different part of the country, learn new skills, meet new people, and perform valuable volunteering. It's been around for more than 30 years in Canada.

And this year, it lost funding.  A good friend who's son was headed down a questionable path ended up turning around due to Katimavik, and met a nice girl there to boot.  I know what Katimavik is because over the last three years, I kept running into people that say that Katimavik changed their lives or the life of someone they loved.  What a tragedy to see such a loved and valuable institution die due to a funding cut.

As I'm not a Canadian citizen, I can't vote.  But for those of you Canadians who can, give Parliament a piece of your mind!  Go to their main page--they've got a number of online petitions you can join.

Update on Nuance acquisition history

My earlier blog on Nuance is already out of date, as I was missing a few new feathers in Nuance's cap, so here's the update.

I'm starting to run out of room!  Make sure you click on the diagram to get the full expansion.  This adds Vlingo and Loquendo.