SoylentNews is people
SoylentNews
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, Interesting) by weilawei on Sunday February 23 2014, @09: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 Monday February 24 2014, @12:11AM
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 Monday February 24 2014, @01:26AM
>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 Monday February 24 2014, @03:33AM
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.