Auto trivia, BlackBerry PlayBook tablet, and #QNXLive sessions

As we begin to look forward to a brand new year, we still have a couple of fun activities for you to keep a look out for as the holidays begin to wind down.

Friday, December 28 will be the last chance for you to win a BlackBerry PlayBook tablet in our automotive trivia sweepstakes. We’ll be tweeting out this year’s final trivia question on Friday at 1 p.m. ET, and if you respond back to @QNX_Auto with the correct answer, you will be entered into December’s drawing. More information can be found here: http://ow.ly/gl9sb.

Additionally, we still have two more #QNXLive Twitter sessions coming up on January 3 and January 11. On Thursday, January 3 at 1 p.m. ET, Linda Campbell, director of QNX strategic alliances, will answer your questions on the subject “Whose technology is in my car? A look at the partner technologies and capabilities found in the cars of today and tomorrow.” And then on Friday, January 11 at 1 p.m. ET live from CES 2013, Mark Rigley, director of concept development, will answer your questions on the new technology concept car that we’ll be unveiling at CES 2013.

We thank everyone who has participated in our #QNXLive sessions to date with Andy Gryc and Andrew Poliak. We had some great questions come in from @StephenBB81, @jmznvs, @BBABrian and @MitchCurtis20, and are looking forward to your additional questions. Remember, you can submit your questions now or day-of by sending a tweet to @QNX_Auto and using the hashtag #QNXLive. If your question is selected, we’ll be sure to give you a shout-out in addition to answering your question. More here: http://ow.ly/glaLk.

Here’s to a fantastic rest of the holidays and a very prosperous 2013!

Meet the QNX concept team: Allan Hudgins, web developer

In this installment of the concept team interview series, we catch up with one of the team’s newest members: Allan Hudgins

Allan Hudgins

Allan, tell us a bit about yourself and your role on the concept team.
I’ve been a software developer for a decade or so, having previously worked on satellite communication systems and emergency notification systems. On the concept team, I have been making use of new ‘real-time’ web technologies that make it possible to have near-instant, bi-directional communications between a web browser and a QNX-based device, over the Internet.

What do you like best about being on the concept team?
It’s a refreshing change from developing production software. The pressure and deadlines are still there, but it’s much easier to focus on coming up with the right ideas and executing on them than it sometimes is under a production-oriented process. I like how much control I have over the design of the solutions I contribute to the team’s projects. There are no mandates beyond getting things done, getting them done well, and getting them done quickly. Well, and have fun doing it!

Has there been a standout moment for you while working on the team?
On my first day at QNX I discovered that a developer had ported Node.js, a real-time web technology, to the QNX OS. I knew I could do some interesting things with Node.js, and within the next two weeks, I was able to create a demo that got everyone excited. I remember Mark Rigley telling me, “Wow, you don’t know what you’ve done!” That was pretty cool — eased the ‘new guy’ jitters for sure.

What is your biggest challenge right now? What keeps you up at night?
I’m usually thinking about how to solve the next problem — right now, it’s a feature for the technology concept car at CES. Creating scalable architectures is part of it, which is an interesting challenge when you’re leveraging a lot of very new technologies. Things don’t always work like it says on the back of the box.

What is your dream car?
Growing up, I always wanted a mini-van like my father. Now, with two kids, I’m afraid that wish might actually come true. I’ve driven the Porsche concept car – I’d like one of those. Please.

Anything particular you’re excited about right now?
The new concept car, of course! It’s beautiful, and it will be cool to see when it’s finished. Generally, though, I like the idea of a car pushing data to the cloud and the user being able to see that data in a meaningful way. For instance, by getting data gathered from other cars, the driver could see if there was a faster way to commute to work, and how long it would take. I think that’s not too far off.

Who would you like to see seated in a QNX technology concept car or reference vehicle?
I’d like to see my 15 month old in the passenger seat, but I don’t know what he’d do — play with the windows, maybe!

Open standards, open source, and why the difference matters

As Andy Gryc reported in a previous post, Paul Hansen of the Hansen Report asked six automakers whether they plan to ship products based on the GENIVI open source platform. Not one of them said yes.

This underwhelming response to open source may seem surprising, especially to people outside of the auto industry. It seems even more surprising when you consider the many companies that belong to the GENIVI Alliance — a veritable who’s who of high-tech and automotive companies, from ARM to IBM to Volvo. Why the disconnect?

A couple of reasons come to mind. First, the automotive market is exceedingly competitive. Asking automakers to collaborate on a common OS platform — the GENIVI approach — is arguably a non-starter. Also, many automakers seem to grasp that open source OSs don't necessarily address the issues that matter to them most.

Allow me to explain. Automotive companies entertain the option of using open source for several reasons. They want to avoid vendor lock-in. They want to leverage a large developer community. They want to access a rich toolset. And, in many cases, they hope to avoid the costs of runtime licensing.

Yes, open source can help address these requirements. But more often than not, open standards offer a better route to achieving what automakers really need.

Vendor neutral, OS neutral, hardware neutral
Take the goal of avoiding vendor lock-in. An open standard is, by definition, vendor neutral. It is typically the product of a collaborative and transparent process free of domination by a single company or interest group. Likewise, it isn’t controlled or maintained by a single, self-interested entity. HTML 5, for instance, isn’t owned by any one company, but is a standard embraced by Apple, Google, Microsoft, Mozilla, QNX, and others.

HTML5 isn't just vendor neutral; it's also OS and hardware neutral. By using it as an HMI and application environment, automakers gain the freedom to choose the best OS platform for the job at hand, and the option to migrate across platforms, if required. In other words, HTML5 enables automakers to use the platform that can offer fastest boot speed, the highest reliability, the best mobile device integration, or the best performance on automotive silicon — things that can reduce costs and improve the user experience. (To put this another way, the underlying OS platform is anything but a commodity — a fact demonstrated every day in the mobile device world.)

An open source platform may or may not share these characteristics. Even though developers can access the source code, a single entity may still control the technology’s roadmap and licensing terms. In effect, the platform can constitute a single point of failure for the automaker — exactly what automakers try to avoid. Compare this to an open standard, which is defined collaboratively and then supported over a long period of time. POSIX, with its 20+ year history, comes to mind.

Also, open standards like HTML5 are unencumbered by the protective licensing terms often associated with open source OSs — terms that can lead to greater system costs and complexity. For instance, the GNU Public License (GPL) that governs use of the Linux OS ensures that any modifications to the original program are released as open source. That's a problem for any OEM that doesn’t want to “open source” its technology; for instance, vehicle bus information. It is also incompatible with the certifications and licenses of consumer device manufacturers whose licensing terms are designed to prevent integration of their code with GPL code bases; iPod support and integration is a good example. Such technologies must, as a result, be separated into another virtualized OS or onto external hardware modules. The result is a more expensive and more complex system — another thing that automakers try to avoid.

Delivering the goods
Of course, all this hinges on whether a standard like HTML5 can deliver the goods. And from my perspective, it does. For instance, it can provide all the capabilities of a traditional HMI toolkit, including a rendering engine, content authoring and packaging tools, and sophisticated graphic transitions. But unlike proprietary solutions, it can also help automakers:

• tap into a vast pool of apps and developers
• integrate with mobile devices
• build user interfaces that incorporate virtually any delivery model
• customize the UX and simplify access to mobile apps
• customize apps and the UX for context: park, creep, drive, etc.

In addition, HTML5 can, with the right platform, work in concert with other HMI technologies (Adobe AIR, OpenGL ES, Qt, etc.) and blend seamlessly with those technologies on same display. As a result, system designers can choose the most appropriate technology for each application.

Incorporating open source
So is open source a total non-starter in automotive? Absolutely not.

In fact, many standards incorporate open source. Let us once again consider HTML 5. While it is built on an open standard, many HTML5 implementations are developed using open source solutions. For instance, many of the current, industry-leading HTML5 solutions are built on Webkit, an open source solution governed by the Lesser GNU Public License or LGPL.

The point is, the most successful solutions will combine the best that open standards, open source, and proprietary platforms have to offer. But if you were mandate an “open” solution, an open standard would be the best to rally behind.

---

If you're interested in this topic, we recommend you listen to the webinar that Andrew gave last week, "In-vehicle product differentiation: open standards vs open source." — Ed.

TI’s Jacinto 5 automotive processor selected for Audi's “MIB High” infotainment system

Well, it couldn't happen to a nicer technology partner. Yesterday, Texas Instruments announced that the QNX-based MIB High system, the next-generation infotainment platform for Audi vehicles, is the first automotive system to incorporate the TI Jacinto 5 automotive infotainment processor. According to the TI press release, the Jacinto 5 plays a key role in the system’s architecture, which consist of a multimedia applications unit and a highly integrated radio-and-car-control unit.

If you’re unfamiliar with the Jacinto 5, it’s an automotive-qualified multicore processor based on an ARM Cortex-A8 core. The processor integrates a variety of automotive peripherals and connectivity options.

QNX’s role in the MIB High was revealed in 2011, when e.solutions announced that QNX Software Systems had been chosen to supply the system’s OS and multimedia engine. See my blog post on that announcement, where I explain why the architecture of MIB High is so cool.

And if you’d like to check out the MIB High first hand, may I suggest you take one of these for a test drive.

Meet Justin Moon, product manager turned concept designer

We recently met Mark and Jon from the QNX concept development team. This week we meet up with Justin Moon, who is on secondment from his product management job to the team behind the cars. Justin works on a variety of things, from concept design to realization to system architecture and a host of other things that change daily – which is exactly how he likes it.

Justin has been working with QNX concept cars from the very beginning, something you can tell right away when speaking with him. Couple his love of cars and tech with an atmosphere of fun, variety and exemplary teamwork and - well, they may have trouble getting him off secondment!

Have an auto question for QNX? Have it answered in a LIVE Twitter session

Have a question that you have been dying to ask us? Well here’s your chance. Leading up to CES 2013 we will hold a series of LIVE Twitter sessions with our automotive experts on topics from the connected car and beyond, and we want to hear from you! In January, we’re even going to give you the opportunity to ask about the new technology concept car that we’ll be unveiling at CES 2013 — more to come on that later.

Each session will have a specific topic and QNX automotive expert but the questions they answer will be up to you. We’re kicking things off on Wednesday,  December 12 at 1 pm ET with Andy Gryc, product marketing manager on the topic of the connected car landscape – past, present and future. In this session, Andy will look at what can be done today and what the future may bring for consumers and the connected car.

Additional topics and experts include:

• Tuesday, December 18 at 1 pm ET: Andrew Poliak, director, business development, automotive - Automotive technology around the world - a look at the cars and technology features around the world.
• Thursday, January 3 at 1 pm ET: Linda Campbell, director, strategic alliances - Whose technology is in my car? A look at the partner technologies and capabilities found in the cars of today and tomorrow.
• Friday, January 18 at 1 pm ET: Mark Rigley, director of the concept development team answers questions about the new QNX technology concept car unveiled at CES 2013.

You can submit your questions now or day-of by sending a tweet to @QNX_Auto and using the hashtag #QNXLive. If your question is selected, we’ll be sure to give you a shout-out in addition to answering your question.

So get your questions ready and stay tuned to @QNX_Auto for our upcoming live Twitter sessions!

Oh, and in case you're wondering who I am and what I'm doing here .... I'm the social media marketing manager at QNX, and I look forward to seeing your questions - and hearing our experts' answers.

Volvo to ship self-driving cars in 2014

Yes, you read that right. According to an article published yesterday in the Wall Street Journal, the Swedish car maker has stated that, within two years, it will launch cars that can drive themselves at speeds of up to 31 miles per hour. It's all part of an ambitious plan to produce "accident free" vehicles by 2020.

I knew that some automakers were planning to roll out their first autonomous vehicles in the relatively near future. It seems that one automaker has decided to eliminate the "relatively".

Who will foot the legal bill for your self-driving car?

If a self-driving car gets in an accident and hurts someone, who is at fault? This isn’t an academic question. Unless automakers get a consistent answer as to whom will be held accountable, and when, the era of autonomous vehicles may be off to a rocky start.

Ideally, automakers would like to see regulations set at the federal level: one set of rules for each entire country, rather than different rules for each province, state, county, or region. That may or may not happen. For instance, only a small number of states in the U.S. allow self-driving cars to be tested on their roadways, but already, the laws governing liability vary from state to state. (I assume that, in the European Union, such laws would be consistent from country to country — please comment if I assume incorrectly.)

This inconsistency is but one of the legal roadblocks to a self-driving future, according to a recent article published by Law360.com. For instance, the article also discusses how an automaker may be subject to liability claims if it simply designs a vehicle in a way that allows someone to install driverless technology.

Will all this put a stop to self-driving cars? Don’t count on it. People will inevitably demand cars with autonomous capabilities, if a recent survey is anything to go by. And automakers will get in the game if for no other reason than to stay competitive and attract customers (which, when you think of it, is the raison d’être of any business).

In fact, automakers may have little choice. According to Law360, some automakers have been subject to lawsuits because they didn’t install electronic stability control in their vehicles, a technology known to save thousands of lives annually. If some self-driving technologies can indeed reduce accidents, as research suggests, then automakers may, in effect, be forced to deploy them. And call me naïve, but I assume that governments could likewise be held accountable if they implement laws that slow the deployment of accident-reducing technology.

My take? It seems to be in everyone’s interest to make the self-driving car happen.

Read the full Law360 article here. Registration is required, but is fast and painless.

Meet the QNX concept team: Jonathan Hacker, software developer

Jonathan Hacker

Last week, we treated you to an interview with Mark Rigley, the concept development team’s director. This week, we meet up with someone who has worked on several of the team’s projects, including the Porsche 911 and Jeep Wrangler. His name is Jonathan Hacker — a wonderful aptronym, if ever there was one.

So tell us, Jon, what do you do on the concept team?
I’m a software developer. I spend much of my time listening to people so I can understand what, exactly, we want to accomplish in a concept system. I then figure out how we can use software to achieve our goal. I also spend quite a bit of my time coding.

What do you like best about being on the concept team?
I like taking a big problem, coming up with a crazy solution that no one had thought of, and turning it into something real.

Has there been a standout moment for you while working on the team?
Yes, when we were trying to get the digital speedometer to work on the Porsche 911. We drove dozens of laps around QNX headquarters while I sat in the passenger seat with my laptop, taking readings off the Porsche’s CAN bus. It was a blast — especially since we got the speedometer to work!

What is your biggest challenge right now? What keeps you up at night?
Working on concept projects is a juggling act. There are always many little pieces of software and hardware drivers being developed at the same time, and everything has to come together seamlessly. I’ve always been more of a programmer than a project manager, so making sure everything stays on track keeps me on my toes.

Who would you like to see seated in a QNX technology concept car or reference vehicle?
This couldn’t happen in real life because he’s a fictional character, but in almost every mockup produced by our designers, Gordon Freeman is phoning the car — you know, the protagonist in the Half-Life video game series. So it would be awesome to see Gordon Freeman sitting in the car. But unless it’s someone in a costume, that’s not going to happen!

What is your dream car?
The Porsche ruined most other cars for me; it really is that amazing. But If I had to pick one, it would be the Audi R8. It’s a fantastic looking car.

Are you excited about the new concept car that we plan to unveil at CES?
Of course — it’s going to rock! We are building some really awesome stuff into this car. People will be impressed.

Look ma, no driver!

Some of us talk about autonomous cars, some of us dream of owning one, and some of us actually get to ride in one. Andy Gryc is one of the latter. Head over to his blog to see a video he took while being chauffeured in a self-driving vehicle developed at the University of Parma — think of it as the ultimate in hands-free systems.

Would this be an awesome way to tour Italy, or what?

What if…

Imagine if your car could help you become more connected to friends and family — and to the road ahead. Enter a new video that peers into the not-so-distant future.

It blows my mind, but some people still see connectivity in the car as the enemy. They think that, the more connected the car, the more distracting and dangerous it will be. But you know what? Responding to their concerns is easy. I simply ask them what if.

For instance, what if connectivity helped you drive with greater situational awareness? What if it helped you sidestep traffic jams and axle-busting pot holes? What if it helped you detect a stop sign hidden behind a tree? And what if it helped you become more connected to the people important to you, as well as to the road and the cars around you?

When we talk connectivity at QNX, that’s the kind of connectivity we envision. It isn’t just about Bluetooth or Wi-Fi or LTE — that’s only the plumbing. Rather, it’s about keeping you in tune and in sync with your car, your environment, your business, your friends. Your life.

From out behind the curtain

The first of an interview series with the QNX concept team

Imagine if you went to a Rolling Stones concert and the entire band played behind a curtain. That would be totally weird, right? Well, we realized that much the same scenario was playing out with the QNX concept team. Their work, including the QNX concept car, has appeared in A-list venues like CES and Mobile World Congress, yet the team itself has remained largely behind the curtain. And that’s too bad, since the team members embody the qualities I like best about QNX. Innovation, for example.

So, in the spirit of setting things right, we decided to pull back that curtain and make some introductions. And where better to start than with Mark Rigley, the team’s director.

If I were to describe Mark in one word, I’d choose chutzpah. Or gumption. Or moxie. He is the antithesis of wait-and-see. To spot him in a room, just look for the guy who says, “Let’s do it!” when everyone else is still stuck in “maybe,” “might work,” or “I need to get back to you on that.” And when you think about it, that attitude fits the bill perfectly. Because when your job is to take something like a Porsche 911 (an example of automotive perfection, if ever there was one) and make it even cooler, you’d better have a measure of confidence in yourself — and in your team.

Indeed, if anything shines out from this interview, it is the awe and respect that Mark holds for his team members. (Okay, I’ll admit it. Something else shines brightly: Mark’s enthusiasm for the next QNX technology concept car. Did I mention the team is working on one?)

QNX drives into CES 2013 as a CES Innovations Award Honoree

Derek Kuhn

It is hard to believe that CES 2013 is less than eight weeks away. We look forward to it every year as it has become an important event not only for our company, customers, and partners, but for the automotive community as a whole. We will be hitting the 2013 event in style — and with an awesome award!

As a kick-off to CES, we exhibited at the CES Unveiled event in New York last week and gave folks an up-close and personal look at our reference vehicle – the specifically modified Jeep Wrangler Sahara. We demonstrated how our QNX CAR 2 application platform is helping to bring a new level of personalization into the vehicle. From the reskinnable digital instrument cluster, infotainment system, and media player to HD hands-free communication and voice recognition, the reference vehicle stole the show.

Adding to the excitement for the event was the announcement that the QNX CAR 2 application platform was named an International CES Innovations 2013 Design and Engineering Awards Honoree, in the Software & Mobile Apps category. Sponsored by the Consumer Electronics Association (CEA) the program was created to honor outstanding design and engineering in consumer electronics products across 29 product categories.

The countdown is on for CES 2013. Until then, check out my interview with the one and only Dave Graveline at CES Unveiled:



And before you go, here are some photos from the Unveiled event:


And we’re off! The CES Unveiled show floor is open


Checking out the tablet connectivity in the QNX reference vehicle


Hanging out with the guys from GamerFitNation.com


Being interviewed for the radio show "Into Tomorrow with Dave Graveline"

Top 8 questions for squeezing high-end tech into low-end infotainment

A couple of weeks ago, I hosted a webinar that addressed the question, “Is it possible to build an infotainment system that meets today's customer demands with yesterday's price tag?” The webinar explored several ways to reduce RAM and ROM requirements, eliminate hardware, and share hardware, all with the goal of cutting BOM costs.

As always, the audience asked lots of great questions, several of which I have answered here. Of course, these provide only a hint of the ground covered in the webinar, so I invite you to download the archived version to get the full details.

Built-in phone module versus brought-in smart phone: what is your take on this, and is a hybrid approach feasible?
The approach will vary from automaker to automaker. I think that embedded phones will be required for certain cars, especially if they use systems that rely on cloud-based services. This approach adds to the BOM cost, of course, but it may reduce overall cost, depending on what features can be off-loaded to the cloud.

Some brands will encourage brought-in devices as the lowest-cost alternative. The consumer will then have to deal with the setup and maintenance issues required to pair or charge the phone. I don’t see a clear-cut analysis that says one method will be better than the other — it really depends on what you want to accomplish.

Any thoughts on using MirrorLink to clone a virtual display to a remote physical LCD?
If you’re talking about a remote (as in cloud-based) device, I would say that HTML5 is a much more natural choice for a server-based application. If it’s a brought-in device, then MirrorLink or HTML5 could be appropriate.

If GPS is moved to a brought-in phone, how will a stolen vehicle be located?
It won’t be, unless the phone was left in the vehicle. This is one of the trade-offs you make when trying to reduce cost.

Of the cost-saving techniques you discussed, which are most likely to be used?
Already, some system designers are removing wake-up micros and DSPs. I’m not aware of any systems where the LCD has been removed, but this approach would probably offer the largest cost savings, making it a likely choice for entry-level systems and cost-sensitive markets.

Security and reliability are the main concerns of a head unit. Squeezing high-end technologies into low-end systems won’t relax those expectations. For instance, smart phone integration will be an add-on instead of replacing functionality of the head unit. Thoughts?
The trade-offs will need to be communicated to the customer. You can never build a head-unit augmented with a smartphone that works as reliably as the head unit operating by itself. As an OEM or Tier 1, you just don’t have enough control over the brought-in devices.

As an industry, we need to educate consumers. If they start relying on the phone in the car to provide certain features, then they will have to expect an inevitable degradation in overall system quality. It comes back to that famous adage: “cost, quality, or time — pick two”.

MirrorLink has a defined communication interface to the head unit. You also mentioned HTML5 as an option. Is there a defined standard yet for transmitting the HTML5 up to the head unit?
The interface between web server (i.e. phone) and web client (i.e. head unit) is already well established and tested. For some specialized features (for instance, allowing HTML5 code to access vehicle services) some standardization may be required. This will hopefully be a topic of discussion in November, at the automotive HTML5 workshop hosted by the W3C in Rome. Some Connected Car Consortium members have also discussed the possibility that, in the future, MirrorLink could add a transport mechanism based on HTML5.

You discussed peripheral sharing, using QNX transparent distributed processing. Does QNX TDP require secure authentication between distributed boxes?
No, it does not. It relies on standard POSIX user group permissions to provide access rights to devices.

Can you discuss any trends you see regarding Ethernet or TCP/IP in the vehicle?
Ethernet is definitely becoming more interesting in the vehicle, due to the introduction of Ethernet AVB. It makes a very natural replacement for audio-video transmission over MOST, and the additions to AVB that fulfil strict timing requirements can replace CAN or MOST for non-media vehicle messages. Ethernet also has obvious advantages when you need to access Wi-Fi networks, cloud services, and mobile devices.

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

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

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

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

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

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

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

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

Recall? What recall?

Red Bend demonstrates firmware-over-the-air (FOTA) updates of QNX CAR 2 application platform at Telematics Munich

I think anyone with a passing knowledge of software development in automotive would agree that the infotainment systems currently under development are light years ahead of the systems that shipped only 5 years ago. The blurring of the automotive and the consumer experience is accelerating at an amazing pace. And the processing power being specified for next-gen infotainment aligns with what is expected in advanced smart phones.

It's no surprise, then, that the size of the code base and the complexity of the underlying software is growing at a similar pace. This complexity creates a maintenance challenge. On your phone, upgrades are pushed out regularly in a way that you barely notice: you get a notification of an update, push a couple buttons, and presto, you are up to date. In automotive, if we stick to the traditional methodology, this same type of upgrade would require a recall. You'd have to take your car to the dealership and they would reflash whatever needs to be updated. Expensive for the auto manufacturer and a big pain for the consumer.

Thankfully, people are thinking about this. Companies like Red Bend Software have cut their teeth in the mobile space, specializing in firmware-over-the-air updates, or FOTA for short. They can generate something called a delta file, which effectively encapsulates the difference (or delta) between what is currently on the end device and the new software build. In some cases, the file can be up to 50 times smaller than the new build. They also have the ability to track current load status of all the devices deployed.

So what does that get you? Using FOTA, OEMs will be able to minimize the network bandwidth required for upgrades and to manage the update process remotely, moving us all towards that Zen state of automagic. I don't know about you, but anything that saves me a trip to the dealer is a good thing.

Red Bend will demonstrate this capability by updating versions of the QNX CAR 2 application platform this week at Telematics Munich. So if you happen to be there, do stop to check it out.

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.

Autonomous cars? Suddenly, I’m not so skeptical

Guest post from Emil Dautovic, European automotive business development manager for QNX Software Systems

As a driving enthusiast, I have always felt a bit skeptical about the notion of autonomous cars. The reason is simple: I actually enjoy driving and don’t want someone else to do it for me, in this case the car itself.

Recently, however, my skepticism has begun to soften. I am fascinated, for example, by the SARTRE road train project, where a lead vehicle takes responsibility for a platoon of semi-autonomous cars. Also, recent research from the U.S. Highway Loss Data Institute suggests that, when it comes to some driving tasks, ADAS systems can already put many human drivers to shame.

Autonomous drive will become especially important when today’s “always on” generation starts to buy cars in earnest. They will, no doubt, want to consume multimedia and interact through social media even while on the road, and automakers will need to accommodate them.

HMIs with more (and less) distraction
What would this mean for car makers? Among other things, the infotainment system in a self-driving car could offer an HMI mode that gives the driver more freedom to pay attention to non-driving activities. When the car subsequently needs a human driver (for instance, it becomes disconnected from a road train), the infotainment system could disable these features and immediately go back to a less distracting user interface.

Also, driver assist systems — such as those for detecting animals and pedestrians — would need to be integrated with the road train system to decide how to react when, say, a rabbit runs in front of the car. For instance, should the car brake and warn other cars of the fact, or would it be safer to simply keep driving? It will be interesting to follow this initiative and see how the technical and business aspects evolve, and how, for example, the owner of the lead vehicle will be paid.

For another interesting example of research into autonomous drive, check out the BRAiVE project led by the VisLab team at the University of Parma. The BRAiVE project uses a variety of sensors, with a focus on low-cost alternatives that could realistically integrated into in production cars.

Bells and whistles
So what kind of impact could all this have on a company providing automotive software platforms?

There will, I believe, be an increased demand for a platform that could run all of these applications, enabling the advanced use cases while ensuring that critical functions always have enough processor power. And, of course, the platform will have to be reliable. If this same platform could offer all the bells and whistles available in consumer electronics and demanded by younger drivers, the self-driving future might prove to be a bit closer than we think.

By the way, if you’re unfamiliar with the SARTRE road train project, check out this video:

---

More about Emil
Emil Dautovic is an automotive business development manager at QNX Software Systems, where he is responsible for the European automotive market. Prior to joining QNX, he worked as a business area manager for The Astonishing Tribe (TAT), where he built TAT's automotive business from scratch and helped transform the company into an important player in the automotive HMI field with leading automotive OEMs and tier ones. He has also worked at AU-System (later Teleca and Obigo), where he served as a consultant on GSM base station development and as a sales representative serving mobile phone OEMs and ODMs worldwide. Emil holds an M.Sc. in Electronic Engineering from Lunds Tekniska Högskola.

Word of the day: Electrification

At this week’s Convergence in Detroit, Mark Reuss, NA president of GM, told a crowd at Tuesday’s keynote, “Hybridization is no longer enough; electrification is the future.”

What struck me most about this statement was the word, electrification; I had yet to hear it in the automotive context. So I did what anyone with a rocket stick would do, I googled it on my way home. The trail led back to GM’s blue paper on sustainable urban mobility, Roadmap to 2030.

For some time now I’ve been thinking about getting an electric or hybrid car but have been bemoaning the lack of choice. Apparently, the fact that a new ground-transportation paradigm requires wide-spread societal alignment hadn’t occurred to me. You just put up a few recharging stations, right?

GM EN-V electric concept car
Source Wikipedia

GM makes eight recommendations in their blue paper, two of which I find to be particularly interesting:

• Integrate electrically powered, connected vehicles into a multi-modal transport system that incorporates sophisticated inter-city transport, comprehensive subway systems, traditional vehicle movement, and specialized smaller urban vehicles
   
• Identify a series of “lighthouse” projects to demonstrate the potential and viability of connected electrically driven vehicles in a controlled environment such as an eco-city or small town

It is nice to see a company taking such a definitive stand and boldly painting a vision for the future; this kind of creative thinking is what we need.

I was surprised to discover the blue paper is from 2010; still if you haven’t already read it, it is worth a look. You can download the paper from the GM web site.

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

Hanging out with the cool kids at the EcoCAR booth

If you read Jin Xu's post earlier this week, you are already up to speed on the EcoCAR 2 competition established by General Motors and the U.S. Department of Energy. If you didn't read it, here's the skinny: To drive home with first prize, university teams must reduce the environmental impact of a 2013 Chevy Malibu without compromising performance, safety, or consumer acceptability. If that sounds hard, it is. Which explains why, out of 150 university teams that applied to compete, only 15 made the grade.

Today, at SAE Convergence, I was lucky enough to meet two of the talented young people participating in this competition: Ahmed Uddin from Wayne State University and Andrew Palmer from Ohio State University. Ahmed and Andrew had just finished delivering remarks at the EcoCAR booth when they stopped to chat with me about their projects.

The EcoCAR 2 Chevy Malibu

The Wayne State team dub themselves the Hybrid Warriors, and they are modifying the Malibu with a parallel-through-the-road PHEV. In a nutshell, the modified Malibu has two power trains, with an electric motor in back and a 2.4L engine in front. By taking this parallel approach, the team has actually upped performance, even though they replaced the stock engine with a power plant that cranks out less power, takes up less room, and puts out fewer emissions. Before these modifications, the car went from 0 to 60 in 9.5 seconds; now it takes only 8.9 seconds.

Meanwhile, the Ohio State team has opted for a series-parallel PHEV that uses an electric motor for the rear axle and a 1.8 L engine for the front. The systems can operate in charge-depleting, charge-sustaining series, and charge-sustaining parallel modes. Personally, I was fascinated by Andrew Palmer's description of the team's infotainment system (redesigning the center stack is an optional component of the EcoCAR 2 competition) and how they aim to make phone connectivity more seamless.

Cooler yet, the team is working on augmented reality, using a BlackBerry PlayBook. Picture this: You hold a PlayBook over the engine of your car, and the screen overlays a transparent view of the engine. The possibilities for this kind of functionality are enormous, and I invite you to check out two blog posts (here and here) from another Andrew — QNX's Andrew Poliak — for examples of how augmented reality could pimp your next ride.

Before you go, remember to follow @QNX_Auto on Twitter, where I will continue to tweet out reports from SAE Convergence.

HTML5 SDK for the QNX CAR 2 platform — the back story

Kerry Johnson

Today, at SAE Convergence, QNX Software Systems announced the new HTML5 SDK for the QNX CAR 2 application platform. I’d like to provide some insight into this announcement, describe what you can expect to find in the SDK, and explain how it builds on the HTML5 capabilities already available in the QNX CAR 2 application platform.

Enabling apps for the car
Almost every consumer who owns a smart phone or tablet is familiar with the app experience: you go to an online marketplace, find apps of interest, and download them onto your device. With the HTML5 SDK, the automotive team at QNX is creating an analogous experience for the car.

Just as Apple, Android, and RIM provide SDKs to help vendors develop apps for their mobile platforms, QNX has created an SDK to help vendors to build apps for the QNX CAR 2 application platform. The closest analogies you will find to our HTML5 SDK are Apache Cordova and PhoneGap, both of which provide tools for creating mobile apps based on HTML5, CSS, JavaScript, and other web technologies.

App developers want to see the largest possible market for their apps. To that end, QNX also announced today that it will participate in the W3C’s Web and Automotive Workshop. The workshop aims to achieve industry alignment on how HTML5 is used in the car and to find common interfaces to reduce platform fragmentation from one automaker to the next. Obviously, app developers would like to see a common auto platform, while automakers want to maintain their differentiation. Thus, we believe the common ground achieved through W3C standardization will be important.

It bears mentioning that, unlike phone and tablet apps, car apps must offer a user experience that takes driver safety into consideration. This is a key issue, but beyond the scope of this post, so I won’t dwell on it here.

So what’s in the SDK, anyway?
As in any SDK, app developers will find tools to build and debug applications, and APIs that provide access the underlying platform. Specifically, the SDK will include:

• APIs to access vehicle resources, such as climate control, radio, navigation, and media playback
• APIs to manage the application life cycle: start, stop, show, hide, etc.
• APIs to discover and launch other applications
• A packaging tool to combine application code (HTML, CSS, JavaScript) and UI resources (icons, images, etc.) with QNX CAR APIs to create an installable application – a .bar file
• A emulator for the QNX CAR 2 platform to test HTML5 applications
• Oh yeah, and documentation and examples

The development and deployment flow looks something like this:




Emulator and debugging environment
The QNX automotive team has extended the Ripple emulator environment to work with the QNX CAR 2 application platform. Ripple is an emulation environment originally designed for BlackBerry smart phones that RIM has open sourced on github.

Using this extended emulator, application developers can test their applications with the correct screen resolution and layout, and watch how their application interacts with the QNX CAR 2 platform APIs. For example, consider an application that controls audio in a car: balance, fade, bass, treble, volume, and so on. The screenshot below shows the QNX CAR 2 screen for controlling these settings in the Ripple emulator.


Using the Ripple emulator to test an audio application. Click to magnify.

In this example, you can use the onscreen controls to adjust volume, bass, treble, fade, and balance; you can also observe the changes to the underlying data values in the right-hand panel. And you can work the other way: by changing the controls on the right, you can observe changes to the on-screen display. The Ripple interface supports many other QNX CAR 2 features; for examples, see the QNX Flickr page.

You can also use the emulator in conjunction with the Web Inspector debugger to do full source-code debugging of your Javascript code.

Creating native services
Anyone who has developed software for the QNX Neutrino OS knows that we offer the QNX Momentics Tool Suite for creating and testing C and C++ applications. With the QNX CAR 2 application platform, this is still the case. Native-level services are built with the QNX Momentics suite, and HTML5 applications are built with our new HTML5 SDK. We've decided to offer the suite and the SDK as separate packages so that app developers who need to work only in the HTML5 domain needn't worry about the QNX Momentics Tool Suite and vice versa. Together, these toolkits allow you to create HTML5 user interface components with underlying native services, where required.

QNX, NVIDIA team up to deliver infotainment solutions

Today, at SAE Convergence, QNX announced that it is working with graphics leader NVIDIA to bring infotainment solutions to the automotive market. As part of this initiative, the companies will integrate support for the NVIDIA Tegra processor into the QNX CAR 2 application platform.

The Tegra system-on-chip is the size of thumbnail, yet it incorporates a quad-core ARM CPU and a GeForce GPU, as well as dedicated audio, video, and image processors.

The NVIDIA Tegra visual
computing module

“QNX Software Systems and NVIDIA have a proven track record of delivering on production programs for Audi... and we’re excited to add support for Tegra to the latest generation of our automotive platform,” said Linda Campbell, QNX director of strategic alliances.

Speaking of Audi, NVIDIA is bringing an Audi A6 to SAE Convergence, equipped with an infotainment system powered by technology from QNX and NVIDIA. The system bristles with high-end features, including 3D navigation with Google Maps and Google Earth, as well as natural voice recognition.

For more information on this announcement, read the press release, and for more information on QNX activities at SAE Convergence, visit our Convergence overview page.

Getting schooled for the future: EcoCAR 2 Year 2 Kicks Off!

Guest post from Jin Xu, global education program manager for QNX Software Systems

Jin Xu

Back in July, my colleague Romain Saha wrote about QNX Software Systems' role in EcoCar 2, a three-year competition established by the U.S. Department of Energy (DOE) and General Motors that challenges university teams to redesign the powertrain of a 2013 Chevy Malibu. To win, teams must reduce the environmental impact of the powertrain without compromising performance, safety, or consumer acceptability — a tall order! Last month, I got to take part in the much-anticipated kickoff to the competition, the Fall Workshop, and learned some interesting things along the way.

Before I delve into the details, allow me to set the stage. Competition to participate in EcoCAR 2 is fierce: out of the 150 universities that applied to compete, only 15 made it through — two of them from Canada. Each year, about 300 students contribute to their respective teams in a range of skillsets, from mechanical and electrical engineering to software development, business management, and community outreach.

Breeding ground
The EcoCAR 2 initiative is part of the DOE's 24-year-old series of advanced vehicle technology competitions, which are a mainstay of the automotive industry and have become a veritable breeding ground for talent. More than 70% of participants will land jobs in the automotive industry and, in a true testament to the competition's "circle of life," many student participants return as organizers and sponsors. The Fall Workshop served as a primer for participants, including training sessions for the donated components and software, including our QNX CAR 2 application platform. Suffice it to say, EcoCAR 2 is a big deal — and we're proud to be a part of it.

Center stack competition

For the first time, competing
teams can create their own

center stack

So what stood out about this year's workshop? For the first time in the competition's history, a reconfigurable center stack is being offered to the competition teams, a nod to how both EcoCar and the larger automotive industry have expanded beyond their mechanical roots. Students have been asked to use Freescale's i.mx6 Sabre ARD board and to choose their preferred software to design the center stack of the future. Each team will have to complete their center stack design by May 2013 to be eligible for the Freescale Innovation Award. A representative from QNX Software Systems will serve as a judge for these awards and will evaluate the designs for look and feel, responsiveness, completeness, and overall innovation.

Center stack platform: The
Freescale i.mx6 Sabre ARD board

On the first day of the workshop, we demonstrated the QNX CAR 2 application platform on the Freescale Sabre board. All 15 teams attended our training session, and we plan to provide them with further training on the platform in early 2013.

EcoCAR comes to SAE Convergence
If you’re in Detroit this week, you’re in luck. EcoCAR will hold remarks in their booth, M15, at SAE Convergence on October 16 from 12:15 to 1 pm ET. The remarks will feature speakers from the DOE and two of the university participants, Ohio State and Wayne State.

I was impressed how just a few days in September could hold so much potential for the future of our industry. It was an honor to take part in the EcoCAR 2 workshop on behalf of QNX Software Systems, and I am excited to see how the students will use the QNX CAR 2 application platform to drive automotive technology forward!

Trend Spotting at SAE Convergence 2012

Guest post from automotive journalist Doug Newcomb

One of the Technical Sessions at the semi-annual SAE Convergence in Detroit on October 16 and 17 is titled Mega Trends and Their Effect on Automotive Electronics. While you’ll have to wait to find out what the participating executives, engineers, and analysts will reveal in the session concerning the rapidly evolving car technology space, here are three areas that are bound to be hot topics at the show.

Driver Distraction
This issue is at the forefront of everyone’s minds — automakers, suppliers, safety advocates, government officials, and consumers — as cars become increasingly connected. In order to help drivers keep their eyes on the road and hands on the wheel while still accessing the features they want, car companies and suppliers like QNX are developing cutting-edge technologies ranging from intuitive and configurable touchscreen displays to more accurate voice-activation systems that make control easier and less distracting.

Automakers are also being proactive in anticipating distractions: Ford is developing technology that assesses a driver’s workload so that some features can be deactivated in certain situations, and BMW’s pioneering work in “pupilometry” helps determine how drivers visually react when receiving information behind the wheel.



Ford's driver workload estimator (source Ford)

Standards
As more automakers integrate portable devices into the dash, drivers are increasingly frustrated by the fragmentation that’s occurring with first-generation systems. Features that are available for one smartphone platform may not be available for another, for example, and incompatibility issues are common. A push for an industry-wide standard has resulted in the Car Connectivity Consortium (CCC), of which QNX is a member. With MirrorLink, CCC’s industry-wide standard, portable device integration would be more straightforward and seamless for consumers. Getting all parties onboard will take significant effort though, since automakers have traditionally developed proprietary systems. But MirrorLink has substantial support, and the HomeLink system that’s allowed integration of garage-door openers into vehicles for years shows that such standards can be achieved.

Autonomous Cars
Two years ago, self-driving cars would have seemed like a distant sci-fi dream. But since the last SAE Convergence in 2010, Google has logged more than a quarter of a million miles with its fleet of self-driving Toyota Prius and Lexus RX450h vehicles. And this year the company has been instrumental in pushing through legislation that’s made self-driving cars legal in Nevada and California.

Audi is another pioneer in the space, developing an autonomous TT that drove solo up Colorado’s Pikes Peak. BWM has also debuted self-driving technology, and Cadillac recently revealed that its semi-autonomous Super Cruise lane-keeping technology will be available by the middle of the decade. Plus, Google’s announcement of its intention at the SAE World Congress in April to work directly with automakers and suppliers on self-driving technology will undoubtedly help accelerate this game-changing trend.

These are three topics are sure to be heavily discussed — and debated — at SAE Convergence 2012. Stop by the QNX booth during the show to see what the company is doing in these and other areas — or to share what trends you’ve spotted.

---

More about Doug
A widely respected reporter and editor with nearly three decades of experience in automotive journalism, Doug Newcomb currently writes for WIRED Autopia and for his own car technology portal, dougnewcomb.com. In 2008, he joined Edmunds.com as a senior editor, where he created the site’s Car Technology section. Prior to Edmunds, he worked as an editor for a variety of automotive publications, including Car Audio and Electronics, Car Stereo Review, and Road&Track Road Gear; he also contributed to many others, including Popular Mechanics, MSN Autos, Corvette Quarterly, and SEMA News. In 2008, he published his first book, Car Audio for Dummies (Wiley).

The ISO 26262 functional safety standard: No way but up?

I was scanning some Google alerts the other day when my eyes stopped at an announcement from Freescale. The headline didn’t mince words: the Freescale Qorivva MPC5643L microcontroller, a 32-bit part based on the Power architecture, has become the first automotive MCU to receive ISO 26262 functional safety certification.

Did you notice? Freescale didn’t say only; they said first. Which suggests they see ISO 26262 as a growing trend in automotive. If so, I think they see right.

If you’re unfamiliar with ISO 26262, let me provide the Reader’s Digest version. First and foremost, it applies to automotive electronic or electrical systems that could pose a hazard (i.e. hurt people) if they malfunction. Examples include anti-lock brakes, traction control systems, adaptive cruise control systems, engine control units, and digital instrument clusters.

Will more automotive
components soon come
with stickers like this?

The standard isn’t concerned with how well such systems perform. Rather, it’s about reducing the risk, and mitigating the effects, of any malfunction that may cause injury or death. So even if something bad unexpectedly happens in a 26262-certified system — and the assumption is that bad things will happen, no matter how well the system is designed and tested — the system will minimize potential harm. For instance, consider the scenario where a high-priority software process enters an infinite loop and starts to gobble up CPU cycles. Obviously, it’s important to prevent this error from happening in the first place. But even if it does happen, the system should prevent the rogue process from starving other critical processes of CPU time. It should also achieve a graceful recovery from the failure state.

ISO 26262 applies to production passenger vehicles with a gross mass up to 3500 kilograms (7716 pounds). Anything else is out of scope. But while the scope is limited, the standard itself is comprehensive. It covers functional safety aspects of the entire development process, from requirements specification to product decommissioning. And in case you were wondering, it’s closely related to IEC 61508, the international safety standard with a very long history and which many other safety standards reference.

So why do I think that 26262 is on the ascent? For starters, the first edition of the standard was published less than a year ago, yet a silicon vendor has already spent the considerable effort to get an MCU certified. Achieving certification to a standard like ISO 26262 doesn’t come easy, so I assume Freescale did it only because they anticipate market demand. (Disclaimer: This statement isn’t based on any special knowledge of Freescale’s business, but is simply my opinion. Interpret it as such.)

TÜV Rheinland:
Also in the game

It doesn’t stop at Freescale. TÜV Rheinland, a global provider of technical services for safety-critical systems, now offers 26262 services (training, consulting, testing, certification, you name it) for a wide variety of automotive components in multiple geographies. And if TUV has gotten in the game, it’s a good signal that the 26262 standard has legs.

Meanwhile, the LinkedIn group dedicated to 26262 has more than 3600 members and grew by more than 50 members last week alone. If you visit the group, you’ll find engineers from automotive OEMs and tier ones looking for guidance on satisfying 26262 requirements — a sure sign that support for the standard is gearing up.

From what I can tell, things haven’t gotten to the point where a company has been mandated to have its automotive systems certified to ISO 26262. But it will happen. And chances are, it will snowball: the more companies that adopt the standard, the more others will feel the pressure and follow suit. Which means it’s only a matter of time before more ISO 26262 product announcements show up in my Google alerts.