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.

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

MirrorLink misunderstood: 8 myths that need busting

If you're new to MirrorLink, it's a technology that bridges the mobile phone and the car. It allows specially written apps running on the phone to be displayed on the car's head unit, where the user can interact with them.

MirrorLink is intended to extend the life of in-vehicle systems by allowing them to interact with mobile content and to support new features that didn’t exist when the car rolled off the assembly line.

Here's an illustration of how it works:


MirrorLink in-car communication. The protocol between the head unit and the phone can run over several transports, including USB, Bluetooth, or Wi-Fi. This example assumes Bluetooth for the audio back-channel.

When I talk to people in the automotive and mobile industries, I find they share a number of common misconceptions about MirrorLink, which I’d like to clear up. So let's get started, shall we?

1. MirrorLink is an Android technology. In fact, MirrorLink works with multiple mobile platforms. Phones using Android can support it, but so can phones from any other phone maker that supports the standard. Even Apple phones could support it, though Apple has currently chosen to go their own route with Apple-specific solutions.
   
   
2. MirrorLink allows any mobile app to run in the car. This is incorrect. A MirrorLink app can run in the car only if the car maker grants “trust” to that app. Each car maker has a different concept of what brands to promote, what features are safe, or what works well with each car. So, in reality, each app will be enabled depending on the individual make — or even model — of car.
   
   
3. MirrorLink promotes “driver distracting” apps. Also incorrect. MirrorLink is an enabling technology that doesn’t promote any type of app in particular. In fact, because the car maker must grant trust to an app, the app developer can't control what apps run in the car. That responsibility remains the domain of car makers, who tend to avoid anything that will cause distraction when displayed on a front-seat screen.
   
   
4. MirrorLink is the only way to connect an app to the car. There are in fact two others: iPod Out and HTML5. Apple supports iPod Out for Apple devices, which allows selected applications to output analog video to the head unit. (Note that the new iPhone 5 doesn’t support iPod Out.) HTML5 also allows mobile apps to run in the head unit, though its use in car-to-phone bridging is still in the early stages. QNX Software Systems has demonstrated concept vehicles that use BlackBerry Bridge (an HTML5-based technology) to connect an HTML5 app on a BlackBerry phone to the car’s head unit.
   
   
5. Mobile app makers will benefit most from MirrorLink. In fact, car makers may end up taking best advantage of the technology. That’s because they can use MirrorLink to customize and create apps, and to refresh those apps as a way of delivering fresh, new functions to their customers. MirrorLink gives them the ability to do this using a standardized protocol supported by most mobile platforms. Car makers could use MirrorLink very effectively, even if they never allowed any third party apps into their cars.
   
   
6. HTML5 and MirrorLink are incompatible. Not necessarily true. Current versions of MirrorLink use the VNC protocol to exchange graphical data. None of the advantages of HTML5 would be incompatible with a future version of MirrorLink; in fact, some members of the Connected Car Consortium (CCC), including QNX Software Systems, would likely be interested in merging these two standards. That would result in a new version of MirrorLink that uses HTML5 as the underlying communication protocol. (The MirrorLink specification is controlled by the Car Connectivity Consortium, of which QNX is a member.)
   
   Even if MirrorLink does go to HTML5, the industry would still need a VNC-based form of MirrorLink. VNC has much lighter requirements on the head-unit side, so it makes more sense than HTML5 if the car doesn’t have a high-powered CPU or lots of memory. The broadest possible option would be to have phone apps support multiple versions of MirrorLink (today's version with VNC plus a future version with HTML5) and to use whichever one makes sense, depending on what the car supports.
   
   
7. MirrorLink obviates the need for car-downloadable apps. Yes, MirrorLink capability is somewhat similar in purpose to downloading apps into the car; they both extend the functionality of the car after it leaves the factory. Because the customer’s phone will almost certainly be newer than the car’s electronics, it will have a faster CPU, giving the raw speed advantage to a MirrorLink app on the mobile. The MirrorLink app will also have guaranteed data access since the hosting phone will always have a data pipe — something that isn't certain on the car side of the equation.
   
   On the other hand, MirrorLink doesn’t give an app access to car features that would available to a car-downloaded app — features such as vehicle bus access, telematics features, or the navigation system. Also, a car-downloaded app would likely have a faster HMI than any off-board app, even if the mobile had a faster CPU, because of latencies inherent to screen replication. The car-downloaded app would also have better visual integration, as it could take full advantage of the car features, instead of appearing as a bolt-on product. Other factors, based on automaker control, compatibility, or product roadmaps could also favor an in-car solution. Even if you could address some of these issues, there would still be enough reasons for MirrorLink and an auto app store to live side-by-side.
   
   
8. MirrorLink apps can be built today. This is technically true. But, in their enthusiasm, new converts can sometimes forget that cars need to support MirrorLink for anything to actually work. Currently, only aftermarket car stereos support MirrorLink; no production vehicles support it. So if you’re a mobile app developer, the market for MirrorLink apps today is negligible. But expect this situation to improve dramatically over the next two to three years as production vehicles start to ship with this capability built-in.

QNX joins Car Connectivity Consortium

This just in: QNX Software Systems has announced its membership in the Car Connectivity Consortium (CCC), the organization dedicated to developing the MirrorLink standard for car-smartphone connectivity.

MirrorLink offers a way to help car occupants access their smartphone applications. For instance, it could allow occupants to access their phone apps through the infotainment touchscreen, steering-wheel buttons, or other in-car controls.

Source: CCC

As a core member of the CCC, QNX Software Systems will have access to MirrorLink specifications under development and to various MirrorLink work groups. It will also be able to support future MirrorLink options in QNX-based systems, and help drive development of the standard.

“QNX Software Systems is a key player in the evolution of car infotainment technology and we are pleased to welcome them into the organization,” commented Mika Rytkonen, the CCC's chairman and president.

The announcement fits into QNX's strategy of enabling automotive developers to leverage widely supported industry standards.

“We believe in giving automotive customers choice and the flexibility to use the technologies best-suited to their requirements — contributing to the CCC helps us deliver on that commitment,” added Andy Gryc, automotive product marketing manager for QNX. (This is, of course, the same Andy Gryc who contributes to this blog.)

To read the press release, click here.

 

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

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

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

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

Proposed app certification process

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