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.

> 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.

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.

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.

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

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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/

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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 :)

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.

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.

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

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.

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.

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.

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.

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?

"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.

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.