Over the course of the Ars Technica 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 by 4G.

But even as a picture of the evolution of traffic over the next decade comes into focus, what isn’t yet clear is the future of the automobiles we’ll see in this next-generation traffic flow. Specifically, one question remains unanswered: Will the silicon brain of these vehicles be built in, or will we simply plug in our smartphones and use their processors, wireless signals and displays?

I put this question to the Ars Technica OpenForum participants, and the discussion that ensued was 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.

In an interview with Ars Technica, Kavey Hushyar, CEO of aftermarket telematics maker Telemetria, insisted that “built-in” is the future, and 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 two things: Safety and the built-in computer’s secure and reliable integration with an automobile’s vast network of sensors and modules. This makes a lot of sense, as anyone who has had to fuss with a finicky, flaky 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, which means automakers need to maintain control over all of the critical computing functions in a car. As we approach 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. This is why Intel and Nvidia are aggressively pursuing the automotive sector. Both companies, traditionally associated with the PC, server, and supercomputer markets, are angling to get their CPUs, GPUs and SoCs into cars, and often tout their auto efforts at conferences.

Finally, the automakers 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 on to suggest 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.”

Pages:12 View All