Over the course of our series on the Future of Cars, a clear picture has emerged of where traffic flow is headed in the next few years. If today's traffic is like a bloom of bacteria that responds collectively to changes in the environment, then tomorrow's networked traffic, where all the cars are linked to the road, to the cloud, and to one another by a wireless nervous system, will be more like a fully formed, adaptive and evolving organism. In addition to the existing network of sensors already embedded in roads and highways, the cars themselves will become collections of sensors enmeshed in a peer-to-peer wireless network, with some master nodes on that network connected to the cloud via 4G.
But while picture of the evolution of traffic over the next decade has started to take shape, what isn't yet so clear is the future of the actual car that will take part in this next-generation traffic flow. Specifically, one question remains unanswered: will the silicon brain of a future car be built-in, or will we plug our smartphones into the vehicle and use the smaller devices' processors, wireless radios, and displays?
I put this question to our OpenForum participants, and the discussion that ensued was very, very good. But before I summarize what the OpenForum agreed on as a long-term solution (there was a surprising amount of consensus about how things should go), I'll first present a summary of both sides of the issue.
The case for built-in: safety, reliability, regulation
In an interview with Ars, Kavey Hushyar, CEO of aftermarket telematics maker Telemetria, insisted that "built-in" is the future, and that the smartphone has a "long way to go" before it can work as a viable in-car computing solution.
Most of Hushyar's case against the smartphone centers on safety, and on the built-in computer's tight, secure, 100 percent reliable integration with the modern automobile's sprawling network of sensors and modules. This makes a lot of sense, as anyone who has had to fuss with a finicky, flakey smartphone can tell you. You definitely would not want an Android phone performing any sort of critical or safety-related computing in your car. Can you imagine having to "force quit" the app that takes in real-time braking data from the cars ahead of you and applies the brake in emergencies to keep you from rear-ending someone?
Then there are the liability and regulatory issues, with mean that automakers need to maintain control over all of the critical computing functions in a car, and as we creep closer to the world of drive-by-wire, the definition of "critical" will expand to fill ever more user-facing roles and functions.
The makers of high-performance computer chips know well that there's a huge, unfilled appetite for compute cycles in the car—especially as drive-by-wire becomes feasible—and this is why Intel and NVIDIA are aggressively pursuing the automotive sector. Both of these companies, which we traditionally associate with the PC, server, and supercomputer markets, are angling to get their CPUs, GPUs, and SoCs into cars, and they often tout their auto efforts at conferences.
Finally, the carmakers themselves are still committed to going the built-in route because it lets them differentiate, although that is changing. OpenForum user emozilla, who claims to be a software engineer at a car company in Detroit, posted the following comment to this effect:
As much as we geeks lament the simplicity of in-vehicle computing interfaces (my 2008 Lincoln MKZ's nav system is agreeably woefully lacking) the truth is that each OEM guards their electronics architecture as a prized pig to be leveraged as a competitive advantage.
But he went ton to suggest that car companies are starting to realize that letting consumer electronics makers take on some parts of the in-car experience is the way of the future, and that "when it comes to infotainment, it's best to let the professionals do their job."
The case for plug-in: Moore's Law
I personally have been a fan of bringing my own hardware to the car since I started using GPSes back with the original Garmin Nuvi. I consistently preferred my own Garmin to every OEM solution I ever used. And now that I use Android, I far prefer putting my Nexus S in "Car Mode" and driving that way to any kind of built-in solution that I've seen.
I'm also not alone. All of the posters were for some variant of the BYO option, though most of them would like better support from the car.
Aside from the obvious issues with expensive DVD updates for in-car systems (this particular gripe will go away, though, when cars come with 4G connections), user stevenkan nicely sums up the fundamental reason that plug-in beats built-in for our audience:
I just don't see a good way around the fact that people own cars 3-5x longer than they do their phones, and car [makers] are allergic to providing upgradeable pieces.
Because we refresh phones more often, they can keep pace with Moore's Law easier than cars can. You might have 2X the horsepower in a new car than you do in your new phone, but in two years your phone will be caught up, and in another two it will surpass. And in ten years, the phone will far and away exceed the car. And as wireless networks evolve, it's easier to bring your own radio. People refresh their phones much more often than their cars, so why not let users bring the latest radio silicon?
Then there's the flexibility factor, which stevenkan also highlights:
Regarding the screen, placeability trumps size IMNSHO. I much prefer running TomTom on my iPhone, suction-cupped to my windshield as high up as California legally permits, rather than running an in-car nav system where the screen is down near my knees somewhere.
Reader Stainless gives another argument in favor of plug-in, and one that I hadn't thought of:
[Built-in loses because it's] tied to the car. You're paying for non-vehicle specific features (Nav / entertainment) as opposed to vehicle specific features (AWD), but only getting them in one vehicle. Again the $2000 Nav that I can't walk around, use in a rental or loan to a spouse (at least not without the car). The movie playback device that won't come with me on the plane, in the hotel, etc.
In all, the discussion participants' preference for plug-in vs. built-in appear to be largely conditioned by dissatisfaction with carmakers' built-in options. Most in-car systems to date are old, slow, user-hostile, inflexible, redundant, and massively overpriced.
But given the aforementioned reasons why built-in will continue to be with us, is there any hope that the problems with in-car computing will go away, or that smartphone-based plug-in solutions will have a fighting chance?
It turns out that there is hope, and that our readers largely agree on the way forward.
Let Detroit handle driving, and Silicon Valley handle everything else
User GeoSixPack opened up the thread with a great exposition of what the rest of us essentially want in an in-car computing experience. He writes:
What I really want is the ability to carry around my portable computing solution (aka, my smartphone), and have it seamlessly integrate into the car's hardware. Does the car have a superior GPS receiver (perhaps due to better antennas or antenna placement)? Then I want the car to provide a positioning service that my phone can discover and use like its own built in GPS. Does my phone have a better navigation program? Then I'd like to be able to use the car's screen to run it (via a remote desktop-like connection). I, of course, want the phone to integrate into the car's stereo, allowing me to control my streaming music or stored mp3s, via driving friendly in-car controls. Why not just store the mp3s in the car or install a streaming app in the car? Because, when I get out of the car, I want the music I was listening to to continue...seamlessly.
User .milfox elaborates on this scenario, and takes it in a direction that I myself have often fantasized about:
Now, I'd love a universal standard to interface my mobile with the car, but the primary identity should be driven by my mobile, not the car's UI, which should be a plug-in to that at best. Ideally, it'd be a "drop in" dock with a standardized interface and "sleeves" for different models (sorta like the N1 desktop dock), and there should be an airplay-like API so that the device's screen gets blown up to a nice 7" or so display.So here's the scenario. You get in your vehicle, drop your mobile in the car slot. The mobile authenticates itself to the vehicle, and takes over the console display. (You can have it be a pop-up/hidden one if it really makes you feel better). There, you authenticate yourself and then the car starts. Car should utilize the mobile's media library, navigation system, communications, etc, while providing a nicer display and perhaps its own add-in background app for systems monitoring.
In essence, what both of these users are advocating is a hybrid system, where the built-in parts of the car deal with critical driving and safety issues, and the plug-in parts handle everything else. So the car would have two types of electronics systems in it: a built-in system for dealing with the critical car sensors and with the environment (i.e. the road, the peer-to-peer traffic network, drive/passenger safety, critical broadcast alerts, emergency response, etc.), and a set of interfaces that let a smartphone handle communication, human-driven navigation, and entertainment.
In such a hybrid scenario, carmakers could focus on doing what they do best, and leave the user experience side of things to consumer electronics makers.
The main barrier to this kind of development is that the modern automobile is a mess of different (and in many cases, proprietary) buses and protocols. Reader JimZ writes:
The problem with plug-in solutions is how do you integrate them with the car? The advantage that built-in systems have is that they're developed around the car's electronics architecture, all of which are manufacturer specific. Sure, most everyone these days is using CAN, but there's still single-wire, two-wire, 11-bit, 29-bit, etc. Plus even with that every manufacturer has their own message architecture, so trying to develop products that can work with multiple nameplates is challenging to say the least.
The answer, of course, is standardization. We're a long way from that, but reader emozilla offers a ray of hope:
As a software engineer in Detroit working in the automotive electronics subfield, I can say conclusively that unfortunately Jim Z has the gist of things. As much as we geeks lament the simplicity of in-vehicle computing interfaces (my 2008 Lincoln MKZ's nav system is agreeably woefully lacking) the truth is that each OEM guards their electronics architecture as a prized pig to be leveraged as a competitive advantage...However, the upside is that what most people consider "in-car computing" doesn't revolve around the true controls systems inside of a vehicle (a modern car contains well over 20 discrete computing units, the most complex of which, the engine controller, contains several millions of lines of code) but rather an extension of the mobile computing paradigm. When I listen to most people describe their ideal in-car computing experience, I hear something much more applicable to a Cupertino solution than, say, a Detroit solution.While I don't believe in the immediate future we'll see any iPads built into cars (regulatory considerations aside), I can tell you that the automotive industry is increasingly realizing that when it comes to infotainment, it's best to let the professionals do their job. I think Android is uniquely positioned here to pull this off...
Let's hope that emozilla is right. It would be great to see cars that let the user's smartphone take over all of the user-facing electronics, while the car's built-in hardware handles the core driving duties. By the time that day gets here, smartphones will be as at least as powerful as today's low-end laptops, so they'll have that much more to offer any car that can seamlessly integrate them into its electronics.
No comments:
Post a Comment