Ford Ditches Microsoft for QNX in Latest In-Vehicle Tech Platform

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

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.

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.

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.

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.

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

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.

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?

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.

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 imagine the politics at Microsoft still remain at, "Catch up to Apple, make our own iPad, iPhone, etc" instead of delivering a good product in the dozen other realms they compete in. Of course the automakers were going to ditch the MS product. Its substandard.

I really wish MS would find a way to up their game. Nadella's tenure isn't looking so bright 8 months in. Not sure if MS is salvageable, to be honest. I sometimes think how much better the products would be if Clinton actually tried to split up the enterprise stuff from the home stuff during the anti-trust settlement, instead of allowing MS to continue as-is and continue to force IE6 on the web for 4 or 5 more years than it deserved to.

The target markets are pretty limited: obviously not smartphones, not automotive infotainment, really just vertical devices (industrial control panels, portable inventory/barcode scanners)

WinCE 6 is still used widely for car radios, especially by the cost-sensitive Asian suppliers (but not as much by OEs/tier-1s who are all going QNX/Linux). Unfortunately MS hasn't kept supporting it with new toolchains, VS2008 is the newest version that can target CE5/CE6.

Microsoft was once dominant in high-end infotainment, now they're not even trying to compete.

Prior versions of CE were a bit janky sure, but remember the sort of hardware it was meant to run on. Having a limited number of process slots isn't the worst idea in the world if you are targeting just a couple MB of RAM!

I'd say that just like any other large legacy code base, CE had some good parts and some bad parts. Everyone on the (6.0+ at least) kernel team knew their stuff, as did the media codec team. I know the C Run Time for 6.0+ was good (I was on the test team for it ;) ).

The lack of a concept of a current working directory was interesting though, of course no smart phone today has such a thing (and we'd think people to be crazy if they requested it!) but the idea was so baked into parts of the Win32 API that it was a fair bit of a porting pain for developers.

Drivers were always a problem for Windows Mobile devices. I actually owned some rock solid high performing WinMo phones, but they were few and far in-between. My Motorola Q9h is still the best smartphone experience I have ever had, it felt /natural/ for me to use, I cannot say that of any other phone I've used since. Also it was lightening fast on just 96MB of RAM. WinMo crawled at 64MB, but it flew at 96MB!

As an example of what it was like from the inside trying to make everything work, when working on WinMo6.5, we couldn't get our OEM partners to give us source access to their keyboard driver for us to make fixes for them to our test devices! (You ever try testing software when you cannot get hardware that it runs on? Ugh) They considered their keyboard driver to be "secret".

These types of problems were a large part of the reason behind the decisions for MS to write the majority of drivers for Windows Phone. When they wiped all the code, and started out with a brand new kernel, the decision was made to limit SoC support to ensure platform stability.

And that there is the kicker about mobile development. Every single new platform is a whole new adventure when it comes to software stability. Because so much changes when platforms iterate, you have a lot of drivers that need to be written.

Traditionally on PC we've only had a handful of chipset manufacturers, and the field has shrunk considerably. But in the late 90s I remember certain VIA AMD chipsets having known stability issues (a large part of the reason why AMD went to making all their own chipsets and not relying on 3rd parties anymore), and more recently even Intel has not been immune to bugs in their chipset drivers.

Now that the mobile field has consolidated to just a few chipset vendors (although this is changing with a flood of Chinese chipsets finally reaching awareness amongst western companies) that iterate on a good schedule, well at least phones don't just randomly reboot.

GPU drivers are still crap though, I'm not sure if the Windows Phone team still writes their own, but they sure as heck did for WinPhone7, there've been multiple posts on HN about Smartphone GPU driver bugs, I wish someone would test out WinPhone for those same issues! :)

tl;dr Aging embedded OS kernels don't behave well when scaled to 15x what they were intended to do. Just when WinCE started to get really good (involving a complete kernel rewrite) it was de-emphasized by the company.

Right now I could just get a DIN2 system with Arduino and plug an OBD-II to the car to get info from the central unit, but what I have works for me.

If I were an auto mfg, I'd make a car with an iPad in the dash in a modular mount. If you wanted to replace it or whatever down the line, get the new mount for the newest whatever tablet. They'd save so much on software, since their car control stuff could just be an app (or just actual buttons), and owners would be happier because an iPad or Nexus tablet is lightyears ahead of the junk they currently put in cars.

Doesn't that pretty much describe a cassette deck? :)

It's easy to fall into the version-chaser trap with easily upgradable digital systems. But I've come to realize, when it comes to digital appliances, do they really need to be upgraded? I don't think so. My Toyota has a basic touchscreen UI that will probably never receive a software update, but you know what? That's fine. The CD player works, the radio works, the bluetooth works, and it will all continue to work. It really isn't all that different from the cassette decks of my past cars.

Luckily, it's still possible to buy a new car that doesn't have a giant LCD in the middle of the dashboard, but I don't know how long that will last...

Also, because SYNC is not connected to the internet it does not have an always on connection. SYNC uses data over voice. Think old school dial up internet connection. SYNC, however, dialed into a partner company that provided a strict set of customer experienced data like ball scores, get your horoscope, etc...

So to update maps, requires you to plug an update stick into the USB port. MAPs are also very large data and would take too long to update on a dial up connection. Again, it has WIFI but the WIFI is not internally used by SYNC or wasn't when I was on the program.

Secondly, because of the partnership with INRIX, I think INRIX gets some kickback for maps updates. And after the trial period, if you decide to keep traffic and direction subscription, I think INRIX also got a kickback for that too.

It will be interesting to see where SYNC goes in the future with 4G now available. When I was at Ford, they wanting to have a celluar data service that was vendor agnostic but it gave them problems for 911 assist. Maybe that has improved.

My point is that there are a whole host of problems a first mover has to over come. Yea they made some mistakes but dam, you have to give them credit for being one of the first to start putting some of this out there.

http://kolibrios.org/en/index

Its based on:

http://www.menuetos.net/

second this. I was really impressed with QNX - I played with it a bit and stopped when the licensing changed.

Seems like this sync process is a point to target for hackers / law enforcement. Imagine turning cars into bugging devices just by doing a drive-by update on Sync.

Or the lulz of having the media screen rickroll someone relentlessly.

For me, the test was to pair my phone before I left the rental car garage. Ford was the most difficult compared to Nissan, Chevy, Dodge and Toyota.

Don't worry. The airbag supplier is looking out for themselves and doesn't want anything screwing up their modules function. The engine controller and brake system are certainly connected via CAN but you're not going to reflash anything without using the correct protocol and having the right key for each controller. You also don't need to worry about buffer overflows or such because CAN is strictly limited to 8 byte (or less) packets and a 29bit message ID. Most messages define particular signals to be in those bytes and critical signals have checks run on them. And on and on...

No, it's not perfect but I don't think you need to worry.