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.

Read More

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.

Read More