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