Dev.SN ♥ developers
Sections
Dev.SN
joekiser writes "In 2010, Ford Motor Company was rated as top-five automotive manufacturer in terms of quality, per J.D. Power and Associates. This was a major turnaround for the automotive giant, which had faced bankruptcy just two years prior. This high reliability rating would be short lived however; Ford began installing touch screen hubs powered by Microsoft SYNC, which were both confusing and buggy.
By 2012, Ford quality rankings had dropped to 23rd, even after numerous software upgrades and a rebranding of SYNC to "MyFordTouch." One customer reported:
"The voice controls typically do not work until the vehicle has been on for five to 10 minutes, meaning short trips require dialing phone calls by hand, only to have the call cut off when the system finally starts up."
This slide continued into 2013, when Ford ranked 27th of 28 brands (as an aside, Ford's premium brand, Lincoln, ranked one slot higher that year at 26th).
Apparently, Ford Motor Company has had enough. On Friday, the Detroit News reported that Ford will make the switch to QNX on future vehicles. This is the same platform currently used by Acura, Audi, BMW, and Land Rover."
[ED Note: "Ford Motor Company's decision to move to QNX aside, I'll be heavily considering a Blackberry for my next phone, especially with rumors of a 64-bit octa-core model for later this year. BB10 also has gotten rave reviews for its design and ease-of-use."]
(Score: 5, Insightful) by LookIntoTheFuture on Sunday February 23 2014, @04:17PM
How about a removable, upgradable and open source entertainment system that works in all vehicles? Nevermind, you can't lock people in that way.
(Score: 3, Insightful) by Nerdfest on Sunday February 23 2014, @04:19PM
It doesn't even need to be opeb source, although that's always a bonus. There should be a standard, open API though, so entertainment and communication systems can talk to the car's systems while being upgradable. Basically, the system is the OS and the car is a set of peripherals.
(Score: 4, Funny) by Anonymous Coward on Sunday February 23 2014, @07:35PM
My Honda's OS had a rogue process that used up the battery and bricked my car! But because the body work is so thin it was a soft-brick and I could pry the bonnet open with little effort and jump start it with iTunes jump-starter and iBattery iLeads. It just worked. I'm so happy!
(Score: 1) by weilawei on Sunday February 23 2014, @04:34PM
(Score: 5, Interesting) by Grishnakh on Sunday February 23 2014, @04:46PM
People have been building CarPCs for at least a decade now, usually based on miniITX systems. They never got any farther than a hobbyist's toy. There's a lot of big problems with the idea of building a CarPC if your vehicle is less than 20 years old or so: many cars make it very difficult to remove and replace the factory stereo system. Frequently the factory system is integrated with other systems, usually the HVAC system or controls. Moreover, on many cars there's just no good place to put the LCD screen for your CarPC system, unless you're really handy with plastic (or fiberglass) fabrication. Back in the 80s and 90s, with many cars (esp. non-American cars), they followed the DIN standard, so it was really easy to remove a factory stereo and replace it with an aftermarket unit. Not any more; there's just too much integration, a lot of stereos aren't even rectangular (they are inside, but the dashboard panels they hide behind aren't).
If you're talking about building some kind of aftermarket system that anyone can install in a modern car, these challenges are probably too big to overcome without significant engineering and manufacturing resources. There's already companies in this market, such as Kenwood, Pioneer, etc.: they make replacements for certain vehicles. But they're not nearly as universal as they used to be. And there's no way you can compete against them, unless you build very high-priced systems for a very small niche market that only owns a very small number of vehicle models that your system is compatible with.
(Score: 5, Interesting) by weilawei on Sunday February 23 2014, @05:16PM
I think you raised a lot of really good points about the high barrier to entry.
On the cars I've replaced stereos, I've never run into HVAC integration--but I've also only replaced stereos, not full-blown in-car entertainment systems that can control other aspects of the vehicle. Also, the vehicles I've worked on are primarily 90's vehicles, with a few in the early 2000's (94, 97, 03, 03, offhand).
I think that the modifying the body work and integrating new plastic/fiberglass/carbon fiber panels has become easier, with the advent of 3D printing and readily available sheets of fiber and resin, and tutorials on YouTube, et al. Most of the time, my issues with removing and replacing interior body panels in a car is breaking the little tabs and plastic "screw" type things, which aren't intended to be removed and replaced often--a necessity when trying to tweak something.
I don't think that focusing on selling a specific product is the correct approach. I think that the best approach would be to design a small base system, around an embedded processor like an ARM chip, on something like a Mini-ITX motherboard, as you mentioned. Then, publish the design of the system, from soup to nuts. Let a community form around the needed methods of modifying the bodywork of specific makes and models.
As for integration with the car: I think you're spot on here. This is going to be the most difficult area. However, many vehicles have a wide open CAN for integration, with no encryption or obfuscation. Barring troubles like that, it seems feasible to begin with a small set of makes/models, enumerate the capabilities accessible via the CAN (or other in-car network). Then, define an API that supports enumerating device capabilities and provides a generic function to access a given capability. When the system is loaded into the car, an appropriate driver can be loaded for the specific capability of a given make/model. CAN in cars commonly allows access to pretty much everything, from any point in the network.
As for making it user friendly--that's a function of time. At first, you need to show a working proof-of-concept that is also extensible. Trying to shoehorn one particular piece of hardware or one particular driver into all cars is a recipe for nothing fitting. Once we have an API (think POSIX), we can develop hardware for specific cars, drivers for specific cars, but it can all follow a single API, allowing userland programs to query capabilities and perform useful tasks.
Phew. It's a ton of work, but it's not impossible. You raised a really good point there. It does require a wide ranging set of skills--but hey, look, we're on SN. There's plenty of REALLY smart people here, some of the smartest in the world (and some of the trolliest), if the comments from /. are any indication, and assuming that some of them migrated. I think the core problem is developing for a specific car first, rather than assuming a generic car and implementing an API to abstract the differences of specific implementations. The problem with in-car systems is that we're stuck in an embedded mindset, when these devices keep acquiring more and more functionality, and their relation to the actual act of driving becomes secondary. The development model should be closer to that of desktop development or possibly smartphone/tablet development.
(Score: 2, Interesting) by sjames on Sunday February 23 2014, @08:11PM
Even with 3d printing, etc it's a lot harder than it used to be. In the late '70s and '80s, you could just go buy a radio anywhere and expect it to work. All you had to do was splice power and speaker wires (the antenna connection was standard). The knobs were adjustable for different dash cutouts. You could generally choose either the knobs from the OEM radio or the new ones.
That's not to say trying to get the old radio out through the crowded space behind the dash wasn't a pain in the ass, but it wasn't like your car would suddenly not start anymore or the door locks would malfunction if you had trouble.
(Score: 1, Informative) by Anonymous Coward on Sunday February 23 2014, @09:26PM
>However, many vehicles have a wide open CAN for integration, with no encryption or obfuscation.
Not really. You can plug into the CAN bus directly, of course, and there is no encryption or obfuscation, as you say. However, this bypasses the filtering hardware that's in front of an IVI to prevent it from crapping onto the CAN bus in the event of a bug.
(Score: 1) by weilawei on Sunday February 23 2014, @11:33PM
What do you think it would take to replace the functionality of that filter, but for a generic in-car infotainment computer? If you had a well-defined set of boundaries between modules (each implementing a specific task, either as a driver or in userland), perhaps you could have a core kernel enforcing and/or mediating their interactions with the CAN.
(Score: 5, Interesting) by joekiser on Sunday February 23 2014, @04:38PM
I always thought the touchscreen on newer cars should be replaced by tablets. Music, maps, movies can be provided by the tablet. Standardize on one connector, and let the user BYOD. Instead of upgrading the car, the owner can upgrade to a newer tablet later on.
Any dealer or brand-specific software can be pushed to the application stores.
The World is Yours.
Former
(Score: 2, Insightful) by ButchDeLoria on Sunday February 23 2014, @07:33PM
If not standardized on a single connector, maybe allow some inset adapters for Lightning and microUSB to whatever connector.
(Score: 3, Informative) by NCommander on Sunday February 23 2014, @04:56PM
To be honest, the head unit on most cars is relatively easy to replace, and the connection between the stereo and the rest of the car has been standardized for years. I don't know commerical units off the top of my head that are "hacker friend", but this proves that people have done it: http://lifehacker.com/power-a-car-stereo-with-a-ra spberry-pi-1491617303 [lifehacker.com]
Still always moving
(Score: 4, Insightful) by c0lo on Sunday February 23 2014, @05:00PM
Picture me stupid but, for the life of me, I don't get it: am I buying a car or a smartphone/tablet on wheels?
I mean, from the POV of the driver, what's the point of having a GPS navigator/mobile phone embedded in your car? What's wrong with having the smartphone of your choice (if you so much like to use a smartphone as a navigator), mounted somewhere you can see/hear?
How about a car that comes only with speakers and, maybe, lcd displays for the back seats and has only has HDMI input - let the user plug whatever s/he likes?
(Score: 4, Insightful) by frojack on Sunday February 23 2014, @09:22PM
Well, you've hit on the most obvious solution.
Bluetooth integration with the phone already in your pocket.
Stop making me upgrade my In-Dash Maps.
Stop making me have to add music to the in-dash music storage.
Stop making the goddamed car system obsolete the minute I drive off the dealer's lot.
There is enough capabilities in Bluetooth stacks to handle every thing a phone can
provide, so when Google Maps improves, you car gets smarter, and when you book mark a cool restaurant it follows you to the car.
Cars are never going to keep up, so they just might as well Give Up trying.
Even if you have to install one App per brand of car it would be better than expensive built in stuff going obsolete.
Discussion should abhor vacuity, as space does a vacuum.
(Score: 2, Informative) by Grishnakh on Sunday February 23 2014, @10:00PM
Stop making me have to add music to the in-dash music storage.
Actually, many cars these days have built-in USB ports (frequently hidden inside the center console) so you can plug in your own USB thumb drive with your music. If you need more space, just buy a bigger thumb drive (and they're dirt cheap these days). The only problem with this scheme is that you probably can't keep your music in Vorbis or Opus formats, but still, it's fairly convenient. When you want to update your car's collection, just pop out the thumb drive, plug it into your computer, and run rsync.
The rest of your points are dead-on, however. Trying to build stuff into cars isn't working, because computers and software change and are replaced much faster than cars.
(Score: 2) by frojack on Sunday February 23 2014, @10:22PM
My car has USB and SD car inputs, as well as the Bluetooth audio on the phone, which the car finds, and indexes, and makes available for selection.
The problem comes when I get out of the car, and my gets in, it takes it a while to grind through all that music to build it into a catalog for selection from the dash. So for me, its just as easy to drag my entire music collection to the SD card, and let it index that. I can then just speak the command to play an artist or title and do it all hands free.
Discussion should abhor vacuity, as space does a vacuum.
(Score: 2, Interesting) by c0lo on Sunday February 23 2014, @10:04PM
I just had another occasion to see how old I am (at least as a mind-set): somebody mentioned that "Zimbra allows you to share files". My immediate reaction: "Why would I want to do file sharing through Zimbra?"
Turned out that the UNIX philosophy [wikipedia.org] is not quite in the nowadays users' attitude, but rather "convergence" and "integration".
Well, my mobile does have a camera (which I don't use - but couldn't find a mobile without one), much less Bluetooth (and no HDMI output for sure). But at least I managed make sure that:
If in the future I won't be able to buy "just a car" but only "mobile phone or a flying circus on wheels", it's very unlikely I'll use those modules (probably I'll spend some extra effort to understand how to disable them).
(Score: 1) by weilawei on Sunday February 23 2014, @11:26PM
I think you're definitely right about the convergence approach. People want their one gadget to do all the electronic stuff, and don't want to carry 14 different pieces of kit.
I do think that the UNIX philosophy and convergence are compatible. Think about how an OS is usually (roughly) structured: kernel, libraries, CLI programs, GUI programs. Transmission [debian.org] as a great example of UNIX philosophy: it uses a core library, libtransmission, and each GUI/CLI/daemon relies on this core library. They don't try to do it themselves, they simply solve their part of the problem.
If you build your system in a modular fashion, with modules that do only one thing, and do it well, you can more easily maintain larger systems--and you can layer stuff over it with ease: a GUI, a CLI, a daemon, a web interface, etc.. The real issue with infotainment systems (and many other products) is that they're designed in a monolithic fashion, instead of being composed of smaller, self-contained units which communicate over well-defined protocols with known semantics. You don't need a lot of overhead here, but you need, at a minimum, a generic convention for boundaries and communication across them.
I'd like to see modern cars designed with this sort of modularity in mind--heck, you can even pitch it as a way for car companies to segment the market further, by downloading new modules for new functionality. Those of us who like our cars for their ability to transport us (instead of being a mobile theater) would be free to skip over the options and save some cash. I'll keep buying older cars, until I can buy something without all the bells and whistles. However, I'd still really prefer to see an open-source implementation. I think a real draw would be a manufacturer supported API (a real one; I'll leave you to argue over the definition of that), but good luck with that, despite the incredibly beneficial effects of fostering a community around your product.
(Score: 1) by mojo chan on Sunday February 23 2014, @07:14PM
Check out Mirrolink and Miracast. Basically mirroring your phone's screen, complete with touch control, on the head unit. All the power and apps of your phone, but on the head unit's screen that is much easier to reach and operate (phones wobble about in the holder when you poke them). Works with most Android phones and I believe the iPhone as well. AOSP if you want fully open source.
If my car had a double DIN slot I'd get that kind of set up. Wireless charging so I can just chuck the phone in the slot below the head unit and have it powered, and an NFC tag to automatically start "car mode" with a special home screen. Almost zero boot time because the phone is already on, fully internet access to live traffic or streaming audio, and obviously things like voice dialling and SMS dictation work very well.
const int one = 65536; (Silvermoon, Texture.cs)
(Score: 1) by ArhcAngel on Sunday February 23 2014, @10:25PM