Wednesday, November 28, 2012

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.

Friday, November 23, 2012

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.

Friday, October 26, 2012

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.

Wednesday, October 24, 2012

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!

Tuesday, July 10, 2012

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.

Thursday, June 14, 2012

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.

Wednesday, June 13, 2012

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.

Thursday, April 12, 2012

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?

Wednesday, April 4, 2012

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.