Hacker News Reader

Comment by blinkingled | Hacker News Reader

The whole thing reeks of NIH and some poor saps trying to save their butts by trying to be forcefully relevant.

Apple and Google already solved the UI problem - you don't need to have the damned ugly in-car UI anymore. Just stick decent hardware with Android Auto and CarPlay support and be done with it. Make decent looking apps for each platform to provide functionality outside of platform supported features.

I just don't understand why on earth would Ford need to have their own system with QNX, WiFi updates and Maps that are not free. What problem does it solve that is worth solving at the expense of reinventing the wheel and making users deal with yet another system?

Edit: One way Ford to justify it is to think of the non-SmartPhone, non-Apple, non-Google users. Though in terms of numbers, at least in the US this bunch is a tiny minority. Ford could give them a Moto G free with every Car for not having to pay for QNX licensing fees, maps and updates etc.! OR they could limit the QNX based independent system to lower end cars and make the higher end ones compatible with Android Auto and CarPlay.

There's also the question of longevity - what if in 2017 Apple and Google stop being compatible with the older version of Carplay/Auto compatible implementation Ford shipped in their 2014 car? What if users switched to non-Apple, non-Android phones? In that case it would make the in-car system useless for the user. So given people use cars for way longer than SmartPhones - I guess it makes some sense for Ford to have an independent system.

Regardless they should still rid themselves of the NIH and stick with Android based UI and not have their own based on QNX. That part hardly makes sense.

View on HN

Do not do this.

In 15 years, your car will still be around but there is a very good chance that neither CarPlay nor Android Auto will exist anymore.

You're going in the right direction - this is slightly less stupid than having something like a Pandora client permanently installed in your car such that it cannot and will not ever be updated once the next model year comes out and Pandora makes breaking API changes or ceases to exist.

The only reasonable thing to do is provide long-lived open standard interfaces like the 3.5mm analog connector. Anything else is deliberately anti-consumer planned obsolescence. It doesn't matter if you think "Android is the platform of the future" or something. It probably isn't. Don't tie something with the release-replacement cycle of a car to a disposable device like a smartphone.

This puts things in perspective, I appreciate that. However, Ford (and others) seem to already tie their cars to one or another type of transient tech. Like the above-mentioned Inrix for maps, or my Pioneer stereo phoning home to some unidentified service to get the traffic. Is Inrix going to be around longer than Google or the 3.5mm jack? I'd rather automakers provided something like a simple, reliable smartphone docking station, with speakers, mics (don't skimp on those like Ford does), and maybe some kind of a display integration, and leave the UI and the smarts to the fast-moving mobile market. But they seem to prefer to force-feed you those crappy, sometimes insanely overpriced systems and web services that still don't seem likely to outlive Google or the car itself.

Tesla rolled their own Linux-based in-car system, and its absolutely gorgeous and a pleasure to use. I highly recommend stopping by a showroom to see it in person.

> I just don't understand why on earth would Ford need to have their own system with QNX, WiFi updates and Maps that are not free.

I agree this is the wrong way to go about this, but rolling your own solution should not be indicative of NIH syndrome if existing options are sub-optimal.

The also lured/poached some UI folks from Apple [1] to work on it.

You think risk-averse Ford would attract the same talent as a hot-as-shit disruptor with a large upside stock potential and the chance to "redefine the world"?

[1] http://9to5mac.com/2014/07/29/much-of-teslas-ui-design-team-...

I was one of the architects working on Ford SYNC. Internally, Ford has a big problem with open source software from a legal stand point. You have a fortune-5 company here. Translation for you: They are a very large target for lawsuits. The open source software provides no indemnification.

You also have to remember when SYNC was in the planning stages long before the public knew about it. I was part of the original team responsible for taking the whole concept to reality.

I can tell you that internally, it was one of the most well run software architecture teams I was ever apart of. The middle level managers really know how to run software teams which is not something you might expect from a big old automotive company.

But in many ways, our hands were tied. Recall about the time Bill Gates and Bill Ford riding around in a model-T. A lot of us didn't want Windows for automotive and were trying to champion Linux. Also, the iMX3 which was in the first generation SYNC modules was at the time a slow processor.

And to top things off, a fair bit of the software running on the SYNC module is not written by Ford. Ford partnered up with a crappy company called B-Squared.

The Maps are not Ford's either. When I was on the team, Ford had partnered with INRIX for Maps, traffic and direction.

SYNC is just not a simple single board computer with some apps running on it. There is an entire eco-system build around the SYNC module because it's connected to the vehicle networks (CAN Bus). Microsoft & Ford being partners (Windows servers in data center), Microsoft wanted to handle some of the software development but when Ford asked Microsoft to sign off on some legal agreement asking MS to take any and all responsibility for things like inadvertently deploying an air bag, they backed off.

Also, Ford SYNC as I said has an eco system of roughly 20-30 backend applications that support it. Some of these have to do with 911 assist and the TREAD act. The TREAD act is the US Federal Government's oversight on safety claims.

Because via SYNC you can report problems and have your vehicle serviced, their is a lot internal logic that keeps track of what is called EOL (End of Line) data about a vehicle which needs to funnel into TREAD act reporting.

Think about the not so long ago Toyota problem where they tried to blame floor mats for gas peddles getting stuck.

EDIT: Also, the GUI is not Microsoft CE native. The WindowsCE is just the OS running on the SYNC module. The GUI was Adobe ActionScript. Trust me, many of us yelled very loud about how stupid an idea this was but because B-Squared own the implementation (not the architecture), they were aloud to chose whatever they wanted to meet Ford specs. The results are a history less: JD Powers gave it SYNC poor ratings and many of us (myself included) got the hell out of dodge.

Middle managers, managing the day to day software architecture and specifications, were caught between a rock and a hard place with senior management (Allan Mullaly, Mark Fields, Bill Ford, Marcy Klevorn) pushing these partnership relationships we were forced to work within.

"The GUI was Adobe ActionScript. Trust me, many of us yelled very loud about how stupid an idea this was but because B-Squared own the implementation (not the architecture), they were aloud to chose whatever they wanted to meet Ford specs."

Sadly, this is how GUI design is in a lot of larger companies. The corporation hires a design firm to flesh out the UI concepts and test them on customers, so they quickly storyboard stuff up in Illustrator and Adobe Flash/Shockwave/whatever.

The concepts get tested, everyone gives a thumbs up, and then the software team gets handed a bunch of precooked assets and wireframes and told "make it run."

Then it's up to the embedded guys to make the system fly, except either a) the design firm has created graphics and animations so complex the underpowered hardware (designed and certified years ago on the last h/w cycle) can't make it go or b) the design guys took way too long in testing and focus groups so now the software guys are under the gun and instead of a rewrite/port, they port a crappy FlashLite player to the target hardware and cross their fingers.

The original Apple TV does this, in a fashion. The whole UI is a glorious mess of Quartz Composer.

Granted, that's no ActionScript, but very much a prototype being pressed into duty.

> The open source software provides no indemnification.

Just as Google and Apple do, QNX contains multiple open source components from other parties that QNX does not own the copyright to including code licensed under APACHE, BSD-2C, BSD-3C, BSD-OPENSSL, BSD-V, ISC-V, GPL2-EX2, MIT, MIT-V, MPL, MPL10, PYTHON, UL, ZLIB (this is copy-pasted from QNX's own open source license compliance documentation). Anyone can sue Ford directly for using those components just as they can with the use of Google or Apple software.

Now, if QNX itself provides a complete indemnification from both copyright and patent lawsuits arising from the use of said code and Apple and Google do not, that's a different story. But unless that is the case, Ford is no safer with QNX.

I'm not a lawyer but sat in many of the internal meetings. From what I understand, anyone who signs up to work with Ford Motor also signs a legal agreement saying you take on legal responsibility for your actions....

As an example, Ford is also a big Linux shop but they do not use any old Linux distro. They have partnered with Novell (SUSE Linux) who indemnifies them from all open source code found in the SUSE distribution.

When I was on Ford SYNC, no Google code ran on the module. The feature they are talking about is called Send To Sync and it's a web service where the SYNC module can receive a map planned on Google Maps. The mapping software in Ford SYNC is simply given the data output in the form of lat/long info.

There is no way that Novell or QNX are big enough to indemnify Ford unless we're talking about some kind of huge business or E&O policy or something; in which case Ford is paying the bill for that.

It doesn't matter that it's open source, it matters that you're buying it from someone who is assuming the liability if it's bad. Bad when I worked for the government we bought a lot of Red Hat enterprise licenses not because we wanted the support (it was for a classified machine) but simply because we weren't allowed to use "freeware".

There are providers of indemnification for certain components. OpenLogic is a big provider.

I agree that Ford appears to consider the benefit of a QNX system high enough to accept the risk of patent lawsuit.

They do now that they know the "benefit" of a WinCE system!

Disclaimer: I'm also working in the industry.

My thoughts are that Adobe Actionscript (in conjuction with AIR) isn't that bad. It could do years ago everything that is now reinvented with HTML5 and MVC frameworks (like angular), has a decent performance (if the port of the AIR runtime to your plattform was well done) and the the language is halfway sane (at least better then Javascript). I also liked it better then the new trend towards QT, because you can do everything in a single language.

I actually know some high end cars with some decent user-interfaces that are also using Adobe technology.

However you can do crappy UIs and a crappy implementation in every technology. If JD power gave bad ratings it's most likely more due to a bad UI design and usability than due to the underlying technology.

I actually had expected that Ford uses Silverlight Embedded, as this was pushed by Microsoft at that time. Interesting that this is not case.

Good to hear that Ford has at least some decent understanding about software. Here in europe trying to do something Software-like isn't a pleasant experience at all.

Former ActionScript developer here. Can confirm, it was actually pretty great. It's a hell of a lot more of a cleaner language than Javascript, for instance.

Don't forget that most game UIs are still built in ActionScript, and they're just fine.

A lawyer can find a legal issue in pretty much anything you intend to do. I've seen teams getting railroaded by this. It usually starts with someone higher up wanting some legal advice and the lawyer seizes the opportunity and scares the hell out of execs. Sometime company had been burned by lawsuit already so they double down on even a remotely possible legal threats. Suddenly everything is required to go through the legal team who let you know that all your possible actions might cause getting sued. Before you know company needs a large legal team to review and craft complicated stupid agreements even with janitors.

The fact is that there are fairly easy workarounds for this kind of legal threats. The "I Agree" is quite powerful button. Most consumer protection legal threats are actually fairly difficult to execute - thanks to severely weakened consumer protection laws in most states. Even if they do get executed in few rare cases or even become class action, settlements are fairly easy to achieve with often tiny impact on balance sheets. I understand that risks in automotive industry is higher when safety is compromised that case cause billions of dollars in recall in extreme cases (for example, Toyota and Firestone cases) but this is like wearing bullet proof vest all the time because you fear you will get in to some physco's shooting spree. These lawyer driven companies don't get wake up call until competition starts doing all these supposidly legally risky things and grabs all market share. Companies that win usually are fire firstt, ask forgiveness later kind. This is also the reason why enterprisy companies like Ford will never come out first with self driving car even if they had tech.

> Ford partnered up with a crappy company called B-Squared.

I had to work with some of those folks after they left B-Squared. Ugh. I shouldn't have to explain why you shouldn't just dump everything in the master branch, how to write a unit test, or why it's a bad idea to pull builds for app store submission from a random dev's machine. But I did. Which went a long way in explaining my horrific experience with the SYNC-enabled Ford I rented once. To someone not versed in the basics of professional software development, choosing embedded Adobe Flash probably seems like a good idea.

OMG, some of the backroom conversations where utterly laugh out loud hilarious. I distinctly recall getting a test spec. from B-Squared that read and I quote, "the application will leak memory just not megs and megs." This was literally in one of their test specs., I kid you not. The test was design to exercise certain features while monitor memory for tell tale signs of a software bugs.

B-Squared had some very good talent also; a few of my UW CSE classmates worked there in the mid/late 90s. I think it kind of went downhill when none of their own products took off and they basically became a pure consulting company.

This explains a lot. Every time I use my car stereo to play music from my iPhone I wonder if any decision maker at Ford tried to use the entertainment system for its intended purpose.

Interesting insights. Not sure if any of this also applies to MyFordTouch... ehh turd. I haven't seen any embedded system as slow, sluggish and buggy as MyFT. After bringing my gf's 2014 Ford Fusion for the 5th time to the dealer for MyFT issues we decided to file a lemon claim with Ford. Don't get me wrong, Ford isn't the only car manufacturer with crappy half-asked infotainment solutions. As a matter of fact, I can't say I've actually seen any implementation done right, except for possibly Audis MMI, which doesn't rely on touchscreens and touch buttons as much but has physical buttons for operating HVAC controls, navigation, etc. In my opinion, very big mistake by Ford to replace all of the physical buttons by stupid touchy buttons you constantly end up activating unintentionally or having to wait for the sluggish GUI/touchscreen to load up just to adjust HVAC controls. In my opinion a good example of rushing out a product and trying to solve problems that don't exist.

Ford MyTouch is just a marketing term for SYNC; they are the same things just called different things. Everyone inside Ford calls it SYNC but rest of the world and what you see in dealerships is MyTouch.

Ford had another venture with DWalt (the tool company) and they partnered with Magneti Marelli who did most of the work. I wasn't involved in that project, but that endeavor was a situation where Ford basically said here some dashboard space and a list of specs., make it work. This system was called Ford Works.

Thanks for the insight - having worked for long in the Enterprise trenches I can certainly understand the difficulties of moving one thing to other. However it mostly takes strong management to get over the inertia in the name of doing something greater.

But as far as the Open Source indemnification goes - for the Android Auto use case it would be completely irrelevant right? That would be like suing Vizio for showing a pirated movie on the screen as far as I can tell.

For using AOSP - I can see that there may be some reservations there. But it is not unprecedented - Honda I think is using Android 4.0.4 to run their in-car system. Besides the biggest threat to Android from a patent / legal standpoint is Microsoft. Worst case Ford would pay up the $5 or whatever and still win on not paying QNX and having a better solution.

As for the dependencies / ecosystem - they could still support the older released models and start working with vendors/suppliers to get what they need supported on the new system. It's doable because presumably with the new Architecture - most things are either built in or you don't need those and people already have experience building what's missing. For example I don't see why they can't build the CAN Bus connectivity into Android in a way that it supports the same existing functionality.

I know it's work, money and risk but I think it would be towards a better outcome and there are some potential saving in not rebuilding everything from scratch and maintaining it and paying less royalties etc.

I presume the older software is tied to a relationship with B-Squared that has deteriorated beyond what current economics will allow and B-Squared doesn't know QNX or Linux. B-Squared's claim to fame is they talk about how much they know WindowsCE very well. It's their tool of choice even though Adobe ActionScript is largely to blame.

Keep in mind to add SYNC to your vehicle, it's $300 (or it was when it first came out). Cheap right? Ford is in the business to sell cars and what sells more cars, they want.

I'm not a lawyer, I see your point and was somewhat vocal on my own, but in my tenure I learned that Ford is a very successful company and they pay smart people to keep them out of trouble. I have to give Ford props for not taking any bail out money but I digress...

One more tid-bit I will add is that Ford never deals directly with the public. You get your vehicle serviced through dealerships.

So when Ford SYNC came out, they were trying to find away for customers to buy additional services via the SYNC system. This of course meant Ford had to now deal with the whole concept of accepting credit cards or finding a partner who knew how to accept credit cards.

As an architect on the team, one of my tasks was to assess the whole PCI compliance, what it would do to us if we got hacked, etc... In the early days, Ford tried to partner with PayPal to handle the credit card stuff but because Ford has a products it would collect for that are also provided by 3rd parties, it just made things very challenging. I'll spare the details but one of the issues I worked on was single sign on technology. You have a mix of technologies like WS-Federation, SAML, etc... and trying to get Ford and all the partners to adopt and stand up this stuff takes a L O N G time. Consider also some of these smaller companies don't have same budget as a Fortune-5 or even know what SAML is so you have a lot of educating going on too.

I've always wondered how B-Squared got such big design wins. They also did the Coca-Cola Freestyle.

Best I can tell is that they're so tight with Microsoft (ex-employees, maybe?) so when a large F-100 class company wants an embedded GUI and goes to Microsoft first, MS sells them on WinCE and then points the client to B-Squared to finish the work.

Or maybe B-Squared is the only firm left still writing GUIs for WinCE.

Your comment hit me like a bolt of lightning. Every time I use a Freestyle machine I can't believe someone delivered a product that is so agonizingly slow. It's such a basic idea, why does it take what feels like 1-2 seconds to respond to Every. Single. Click.

Last time I ate at a restaurant that had a Freestyle machine, the thing was stuck in an error state and everyone had to stand around and wait for the cashier to go reboot it before they could fill the soda cups they had purchased. Disaster.

Freestyle has been a very successful marketing concept, mostly for Coca-Cola. Less so for the stores that adopt the machine. It isn't exactly driving traffic into the stores like Coke had promised. They've also had a slew of maintenance problems.

Pepsi has had time to catch up and has recently launched Spire, their multi-flavor machine. They chose a simpler approach and skipped the whole microfluidic flavor cartridge thing. It's simply a revamped fountain/flavor dispenser with a new interface. It works just as well as Freestyle IMO, and actually has an advantage of using less physical space up front (but still needs the whole syrup stack behind the scenes)

http://www.pepsispire.com/

I know of no cars in the US that are selling with Android-based head units (those Honda ones are Europe-only). There are plenty of cars with Linux-based head units though

Thanks emcrazyone - can you comment at all about whether the team looked at the large and mature history of learning and standardization of displays and controls in the air / flight industry? These displays and controls are designed to optimally communicate information and reduce distraction in a safety critical environment -- just like driving.

The short answer is no. Ford partnered with B-Squared because someone knew someone is the way I understood things. Around the time SYNC was getting to be announced, Bill Gates & Bill Ford were seen in local media (TV news, papers, etc...) riding around in a model-T at Henry Ford Village with the reports being that Microsoft wanted to get into automobiles. Out of this, somehow, B-Squared was chosen (pushed on guys like me) with the comments always being they have a lot of domain expertise in bringing up WindowsCE on embedded platforms.

If you interested in the flight industry, something I've been looking at too:

Check out Disti (www.disti.com). Disiti is a company with an HMI(Human Machine Interface) that is gaining a lot of attention and they came out of a military flight industry. Their displays are in the Apache helicopter and the Virgin Atlantic Space Ship as a couple of their selling points. Because of their military involvement, everything they do is ISO26262 compliant which is attractive to the automotive space.

That is sales and marketing in a nutshell: Someone knew someone.

Don't forget that after all your math and science and engineering efforts are over, it still comes down to who knows whom. I'm not trying to be cynical, I'm trying to say: Plan for your end game. Don't fool yourself about the actual nature of that end game; it is not technical.

> Microsoft wanted to handle some of the software development but when Ford asked Microsoft to sign off on some legal agreement asking MS to take any and all responsibility for things like inadvertently deploying an air bag, they backed off. ... Think about the not so long ago Toyota problem where they tried to blame floor mats for gas peddles getting stuck.

Are you saying that the navigation and entertainment system in Ford vehicles is not isolated from the critical safety systems? If that's the case I hardly think sluggish interaction is the biggest problem.

Normally they are seperated. Safety related features run on dedicated ECUs running a real-time OS like Autosar. They are communicating via bus systems (CAN, LIN, Flexray). Even the vehicle related features on infotainment systems normally run on a dedicated CPU in the headunit (running an RTOS) which communicates with the entertainment-related CPU (running WinCE, QNX, Linux...) by IPC.

Some bad designs might neglect those guidelines and build everything in one box to save costs. However I hope that those only happens in the cheapest offerings.

However I think the discussion between Ford and MS could be more due to political reasons. Automotive OEMs like to put all risks (whether likely or unlikely) to their suppliers and make them liable. Changes from standard automotive contracts are unlikely. And MS might not be not accept such a standard contract.

>If that's the case I hardly think sluggish interaction is the biggest problem.

It is crazy because it's not as though a CAN or LIN bus is an expensive thing. It has been discussed ad nauseam that the option systems need to be segregated from the critical systems, and as far as I was aware, the entertainment / option systems were segregated.

Ford's also the company that has critical systems disable if the key is bumped out of the ignition. And then "Fixed" it by closing the hole on the keyfob so people couldn't hook more stuff on it and thus reduce the chance of it falling out.

The fact that any safety critical systems just die when the key comes out of the ignition, while moving at high speeds, is even more damning, IMO.

Sure you're not thinking about GM? They're the ones who were in the news recently for those ignition issues.

Oh dear, you're right, but it's too late to edit. Please downvote to hide it.

My point though is that the fact cars would be that fragile at all, that simple mistakes could disable critical systems, is bizarre. The MP3 player system should be totally unable to affect other operations, full stop. The ignition system shouldn't be able to kill power to critical systems.

Airplane passengers shouldn't be able to access flight controls.

> You have a fortune-5 company here. Translation for you: They are a very large target for lawsuits. The open source software provides no indemnification.

I work for another fortune-5 company who uses linux in many products that we sell. Another well-regulated industry, too. I will concede that the hazards for operating automobiles are well-beyond many other industries' products.

I own a 2010 Ford Fusion with SYNC and I really enjoy the features. I suppose it could've been done better, but the speaker-independent voice recognition is stellar.

Yeah, B-Squared is not a company I would do business with again. Very crappy code, very frustrating to work with.

That's some great insight, thanks. I own a Ford and Sync is just a horrible, PITA to operate piece of software. Extremely slow and sluggish. Maps and directions had hardly any intelligence to it and most of the time I end up pulling GMaps on my phone - not something I envisioned doing when I purchased the car with the then-awesome (or so I thought) navigation system.

The one thing I do like though, is the voice commands. At least that actually made things easier. Speech recognition wasn't perfect, but it worked most of the time.

I wish there were more competition in the automobile in-vehicle tech platform space. I wish someone would get it right, given that most people are in their vehicles a good portion of the day.

Wow, this is an amazing comment. I'm actually quite happy with sync on the 2014 ford escape. It is easy for me to get to what I need to do. Over time, I've realized it's better than a lot of physical button implementations for certain things.

I have a 2014 Escape too and I am happy with Sync insofar as I can get most things I need done done without actually using Sync :-) HVAC has buttons below the screen, radio has buttons on the steering wheel. And the feature I use most often is probably the hands-free phone call integration over bluetooth, which seems to work well without any intervention once it is set up.

Agreed that the actual GUI is atrocious and clunky. The way it deals with text messages is hilarious. Really I just pretend it doesn't exist and I'm happy.

Great post, thanks for taking the time to share! And, interesting point about how well-run the architecture team was ... and how it wound up not mattering because of the relationships that senior management was pushing.

I have never seen team who only does architecture and no implementation ever succeed. You usually end up with lot of UML diagrams and PPTs that are unfortunately not executable. When "implementors" arrive at the scene, they realize all the things that had been overlooked from 30,000ft. Finally what gets implemented is either good with little resemblance to those pesky UML or terrible but in full compliance of "architecture". Avoid pure architecture teams at all cost.

Unfortunatly that happens in automotive too often :( OEMs have little knowledge about implementation, most actual work is done by contractors.

Thank you for the details. I always wondered what was going on over on the other side of the wall.

The first generation of the Ford's SYNC computer was designed in cooperation with Continental AG and is built around a 400 MHz Freescale i.MX31L processor with an ARM 11 CPU core, uses 256MB of 133 MHz Mobile DDR SDRAM from Micron and 2GB of Samsung NAND flash memory, runs the Windows Embedded Automotive (CE) operating system, and uses speech technology by Nuance Communications.

http://en.wikipedia.org/wiki/Ford_Sync

The first generation SYNC has a monochrome display (blue or red on black) with a very basic GUI (like a 90s Nokia cell phone). Despite a 400MHz CPU and WinCE the menu is slow and looks ugly, but it is solid and works.

Later SYNC generations had a graphical GUI with touch, that's probably the slow Actionscript based one the other commentor mentioned.

With the MyTouch issues, several european Ford 2014 models still ship with the first generation SYNC. The SYNC menu features an appstore entry despite the appstore was never activated for non-US models. The Google Maps feature is not available, in the EU version. The MyFord website with additional diagnostic features about the car as well as software update downloads is only available for US car models. There are no updates e.g. for the european models, not from the car dealers nor from Ford website.

Sorry to threadjack, but since you're here...do you have information on where to find coding standards for the auto industry? I'm kind of curious how you manage these projects with weird and precise requirements and using languages like C. Any good stories?

A starting point for you is the so-called MISRA-C standard: http://en.wikipedia.org/wiki/MISRA_C

All the automotive companies are interested in ISO26262. ISO26262 has many levels. Although, SYNC had no safety connection so it wasn't required to meet any of the ISO26262 levels.

http://www.misra-c.com/

There's also the question of longevity

That's one of the big arguments for QNX. The QNX microkernel is very stable. It barely changes from year to year. Versions from 15 years ago run fine. There's no need for OS updates.

Cars last a long time. I have a 1985 Ford Bronco in my driveway, and it still has the original EEC IV electronic engine control unit, still working fine. That was designed for a 30 year lifespan, and it made it.

I agree. I was friends with Dan Hildebrandt, he was one of the (few) guys who worked on the actual microkernel. In my opinion, QNX is the only example of a viable microkernel OS (it's way the heck better than Mach ever was).

I love Linux, use it all day, every day, but I can see the wisdom of choosing QNX. It's very stable.

The downside is you don't get all the new shiny stuff that runs on Linux without some amount of effort. I suspect Ford doesn't care, Ford has always been more about "it works" than "it's shiny".

Says the dude who just bought a 1994 F15 5 speed so his son can learn how to drive a manual :)

>Apple and Google already solved the UI problem - you don't need to have the damned ugly in-car UI anymore.

I haven't seen a good example of those systems not sucking yet. Also, they require that you plug in your phone, which is really a downgrade from our current Bluetooth systems.

>Ford could give them a Moto G free with every Car for not having to pay for QNX licensing fees, maps and updates etc.!

Or they could just build the Moto G into the car! And now you are back to square one.

Are they seriously not wireless? What the hell were they thinking?

> "Apple and Google already solved the UI problem"

Have you seen any demos of these systems? Because I thought this as well until the video evidence began to mount. Both CarPlay and Android Auto are slow, laggy and overly complicated solutions. And that's before we account for both systems' odd reliance on cloud-driven voice navigation. And that's without trying to account for the frankly-unlikely notion that people will fish their device out of their pocket/bag, and physically plug it into their car, with any regularity.

Both Apple and Google's efforts are attempts to cram their existing platforms into a use-case where it isn't needed and it just doesn't fit. It's akin to Microsoft trying to cram kbm windows onto a tablet. That is not the way forward for car manufacturers. That's not the way forward for anyone.

The primary desired integrations by the user are: being able to listen to the audio that's on their device and exchanging voice with contacts on their device.

Even turn-by-turn is a thing that most people, most of the time, don't need. And when they do need it, the odds of having their own car, or a car in which they had any choice on the underlying in-dash technology, are low. Niche groups might select a car/radio and regularly plug their device in to attain these features -- just as niche people suffered various iterations of Windows Tablets over the last decade. But there will be no widespread adoption or use.

What's needed is an update to bluetooth [1] and dash designs that acknowledge mobile devices by providing a universal mount and some signalling method that can shift those devices, themselves, into a "car mode". So 80% of the time, 80% of people aren't mounting anything and are having a better experience.

And when they do want some device feature, they don't need to hunt through the purchase process for various possible mounts, suffer fiddly installs and then live with obscured dash controls.

So I see every reason in the world why Ford would need a competent in-dash solution above and beyond simply supporting CarPlay and Android Auto.

As to why Ford would want a QNX solution with wi-fi, for-pay turn-by-turn, etc? Fleet sales / rental services.

[1] improve the audio handling. improve the pairing situation. voice command pass through.

I'm probably one of the niche guys but I see wider applications for this. I like in dash GPS which I have from an after market unit. I use it frequently. The problem is that to update the maps, you need to purchase a CDROM for a hundred smackers. Once you have it for free on your phone you are not going to do that. So I use the phone. Hooked up, the voice instructions play through the stereo. Direct connection is noticeably superior to blutooth for this purpose. The only problem is the awkwardness of screen control access. I could just mount the phone to the dash but the iPhone screen is a little small.

What I want is to connect my phone and then have a nice big touch screen on the dash that functions like the phone. I don't care much about voice control (I don't have Siri) but I suppose it would be nice.

I'll look for the videos. It seems improbably to me that they could screw this up but I am often dissappointed

It looks like you have no glue in terms of software development requirements in the automotive industry. Software development for embedded devices is a totally different story than software development in the IT industry. The is no minimal viable product and then deliver experience with some updates. Everything has to work from day 0. Otherwise you will have a big PR disaster. Mercedes had that with its E-Class model W210. Only a few companies have exemptions from that like Tesla. A well established company like Ford, GM, Volkswagen or so who delivers something like 50.000 cars a month over all their different models requires different software quality requirements than a company like Tesla who delivers 20.000 cars a year and is considered as a Startup, which may have some hick-ups.

Another issue is, that you have even in a simple car you have at least 15 different control units and the HMI/MMI is only one of these. Throwing hardware at it means increasing prices, which you don't want as a consumer. Also remind you, that development of a car starts somewhere 3 to 5 years before you buy the car. Because the hardware has to be tested very extensively so that everything works in without problems in most worst environment like from Alaska to Mojave desert. Designing hardware with such a broad requirement is not as easy as you may think. That is the reason why automotive rated components are way more expensive than industrial rated components, not even talking about consumer rated components. The problem of what you call "decent hardware" is, that it is only consumer rated from 0°C (32°F) to 80°C (176°F) vs. automotive rated, which is -20°C (-4°F) to 125°C (257°F). Then there are also EMI requirements and much more.

The only consumer company that is close to the quality requirements of the automotive industry is Apple. But Apple has a different advantage over the automotive industry, which is they sell millions of their phone within a month vs. a carmaker sells a million of a model may be within 3 to 5 year, depending on the market level (small car vs. premium car). The iPhone within a car is only one ECU, but a car as at least 15 of them (up to 100 in the premium class, like Mercedes S class, Porsche). So the cost structure is completely different.

Another thing: Android Auto and CarPlay are no OS at all. Both are just interface definitions. Both are implemented by QNX for example. That said, QNX was one of the first suppliers who teamed up with Apple to provide an integration of the iPod.

Car companies probably don't want a vendor lock-in. Android Auto and CarPlay may be two options but what if one goes away or becomes unattractive in the future?

Great point, I realized soon after I posted and so I updated my OP. But still they could have gone with Android based system instead of QNX - it's open source, the Lollipop UI is gorgeous and since it would be a fork, there's no lock-in worry. Developers would be able to write / port apps and extensions easily as well.

I can't put this delicately.

It's a car. It's not going to have an app store. You don't want an app store. You don't need an app store.

QNX is a well-understood RTOS--look up "hard real time".

There's a lot more important things in a car for an OS than being able to display a notification on Facebook; things like deploying airbags, coordinating brakes, and all these other things.

The Sync system isn't doing any of the important things you mention. It's infotainment.

Furthermore the notion that you'd be sharing core processing between safety-critical car functionality with infotainment functionality is downright scary. These should always be (are they?) discrete systems.

I can cause my BMW's i-drive (CIC-HIGH NBT F20 2013) to completely crash if I perform a specific action. After fifteen seconds the system detects the freeze and reboots. The way the reboot occurs strongly suggests the reboot is performed by a hardware level supervisor. But the rest of the car continues to function.

CarPlay and Android Car don't help you very much: They require a phone to operate. If you don't have one you get nothing. That doesn't sound like a big issue now but keep in mind that car multimedia is in development for about 4 years and then the cars are in the market >= 15years. This means if you now start to design a system around CarPlay you would need a iphone that supports the current CarPlay protocol in 2034. That's very unlikely. And when you don't have one you get nothing at all, neither music nor navigation.

Directly building a system on top of android instead of QNX or a custom linux distribution is certainly possible. Every approach here has some pros and cons. Keep in mind that not all of android is open source and available for everyone. You can't directly use a normal Android phone UI because it is not certified for in-car use (driver distraction regulations). But you could at least use it's UI framework and some of the widgets. For the widgets there is the question if you want them. If they started development 3-4 years ago and based on android you would now get a brand new Ford with a Android 2.3 UI. Wouldn't look sexy either and even less in some years from now. Therefore going with some custom UI can make sense.

Can't answer your question for CarPlay, but wouldn't Android Auto forkable if need-be? Not desireable, but an option for a car company wishing to hedge its bets.

How long is any particular flavor of Android going to be supported, vs QNX or some other unix-like RTOS?

Yes, you could contract for longer support, but how much current energy will remain with whoever's engineers you contracted to for supporting that older and older version?

Also, QNX is an RTOS. Maybe they actually needed an RTOS. How well does Android do as an RTOS?

...non-SmartPhone, non-Apple, non-Google users ... at least in the US this bunch is a tiny minority.

"Two-thirds of Americans now have smartphones:"

http://www.engadget.com/2014/02/11/two-thirds-of-americans-n...

One-third is not a tiny minority.

What percentage of new car buyers have smartphones? I have a feeling that most people without smartphones will not be in the market for a new car...

Even if it was 99.99999% I would bet that there's still a huge percentage that has no idea what their phone can do, let alone Bluetooth pairing it. I'd even guess that many people think Bluetooth is the name just for those douchey headsets.

I suspect it's a tiny minority of the people who are in the market for cars with built-in interactive systems like this, though.

> Make decent looking apps for each platform to provide functionality outside of platform supported features.

CarPlay and Android Auto both do not allow arbitrary apps (which would be needed to i.e. control the head unit's FM/AM radio or climate controls). I expect this will happen someday, but it's not here yet.

is this a certification issue ? I know that QNX is certified for several CAN-bus deployments... maybe Android is not certified for those kind of environments. Again not sure if this is part of the vehicle CAN bus anyway.

Reply on news.ycombinator.com