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.
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"?
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 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".
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)
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.
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.
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.
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.
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?
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.
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.
> "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.
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.
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?
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.
> 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.
Windows CE is an unbelievable pile of crap under the hood, easily some of the worst code I've ever seen. It should never have been shipped; it was certainly never made better, at least at a level that mattered. Instead, Microsoft kept adding features. CE speaks volumes about the lack of caring about quality and good design from Microsoft's upper management.
Yes, it was killed a few years ago. But it lasted way too long, and did untold amounts of damage to Microsoft's ability to execute in mobile. They spent a lot of time recovering from many bad decisions, mostly politically driven nonsense having nothing to do with making CE any good.
Considering every sysadmin spent yesterday uninstalling rollup 8 for Exchange 2010 and KB3004394, I'm very worried that MS, as an organization, has fallen from grace on a level never before seen. On top of a million other issues like the failure of Office 2013 and Windows 8 in general.
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.
>Nadella's tenure isn't looking so bright 8 months in.
I think many here would disagree with that, as shown by the last... 8 months of news about open source this, Linux that, iOS/Android apps, web standards, and GitHub.
I've never heard any complaints about Office 2013, and I haven't heard any complaints about Windows 8 that haven't been solved by Windows 8.1 or Windows 10.
I have heard complaints that it was not a major enough upgrade from 2010, but I certainly appreciate it. The new interface is great, and there are a handful of features that have really made a difference for me. Having decent ODF support, having used OO.o since 2.0 betas made the switch to Office much easier. Editing PDFs has also come in handy quite a few times.
Office 2013 apps are incredibly slow to start and run. Outlook, in particular, will lock up for minutes at a time with no network or CPU activity. Some people in my office use OWA instead of Outlook to get around the lockups.
I don't use Outlook, but all the other Office 2013 apps run fine on my Windows tablet, with a dual core Atom and 1GB of RAM. I've had a 20-slide Powerpoint open and being edited at the same time as a several hundred row Excel document. It wasn't fast, but it wasn't painful.
> I'm very worried that MS, as an organization, has fallen from grace on a level never before seen
That's what happens when a company refuses to pay market rate to its top people. Other Seattle-area tech companies have been poaching from Microsoft for years, and Microsoft hasn't bothered to even try to stop it.
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.
IMHO WinCE 6.0+ were pretty nice to work with. It could scale down to a system image that was just a couple of MB in size, and scale up to a full blown miniature version of Windows.
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.
- The WinCE driver model was pretty hopeless; you could write a simple interrupt handler, but a thread was supposed to do most of the work. There was a ton of context switching involved in any I/O, and the drivers tended to have many useless layers of abstraction, which was probably half architectural and half bad practices followed by the CE culture. (We managed to get about 8 Mbits/second of bulk traffic through USB on WinCE, using 100% of the CPU of our 800Mhz ARM, while a later bare-bones embedded system with a gutted but more functional version of the same driver got 40 Mbits/second with about 5% CPU).
- You could choose what features to build in (this was really baroque and complicated, to say the least). I remember getting WinCE down to 6MB, and this got you an empty app with some drivers. It took 45+ minutes to build (we never got incremental builds working reliably), maybe 20-30 seconds to boot, and did nothing. For 6MB. Yike.
- The BSP (Board Support Package) drivers from vendors were miseries. We found so many bugs in them that we just gave up and wrote our own, which wound up being smaller and way more reliable. Our feedback to the BSP folks was usually ignored (I'm hedging "usually" because I don't know a single case of a bug we reported ever being fixed).
Our decision (inside of MS!) to punt WinCE 6 and do our own thing was one of the best we ever made. It was politically rocky for a while, but if we hadn't done it, we would not have shipped.
> - You could choose what features to build in (this was really baroque and complicated, to say the least). I remember getting WinCE down to 6MB, and this got you an empty app with some drivers. It took 45+ minutes to build (we never got incremental builds working reliably), maybe 20-30 seconds to boot, and did nothing. For 6MB. Yike.
Platform Builder wasn't nice. With full interal source access there were esoteric sets of build parameters that worked much better.
That said, the 6MB image got you a complete OS Kernel and Runtime, as well as the full working C Run time, and also a remoting system that allowed for debugging from halfway across the campus.
Not saying you cannot do better with less, but the OS image scaled pretty far down all things considered.
> The BSP (Board Support Package) drivers from vendors were miseries. We found so many bugs in them that we just gave up and wrote our own, which wound up being smaller and way more reliable. Our feedback to the BSP folks was usually ignored (I'm hedging "usually" because I don't know a single case of a bug we reported ever being fixed).
Many of the BSPs were bad. :(
I don't know much about the driver model, I never touched it!
> Our decision (inside of MS!) to punt WinCE 6 and do our own thing was one of the best we ever made. It was politically rocky for a while, but if we hadn't done it, we would not have shipped.
From an application developers point of view working with WinCE (and the automotive variants) was absolutely no pleasant experience.
When you want to implement entertainment stuff you want to reuse software and have it running on CE as well as your development platform. However the the compiler and library support is very limited. Don't even discuss about C++11 - you don't even get a normal standard template library :(
Even for all windows APIs you first have to look up if they are also supported for CE. Then there are kernel features that are so different that you also need extra code for it. E.g. normal Windows supports IOCP, CE does not and Linux does it completely different.
Maybe it's different when you build applications that only target CE. But when you want to have code-sharing between embedded target and normal PCs then working with embedded linux is here a much more pleasent experience where you can run the same code on the target and have state-of-the-art tooling.
Sadly, a lot of CE stuff was deemphasized years ago.
> However the the compiler and library support is very limited. Don't even discuss about C++11
Back when I was on the compiler team, it was a bit before the revitalization of Native had happened at MS, so there wasn't the huge push that there is now. I am sad to hear that CE never got the same compiler love that Windows on ARM got. (All that happened well after I had left.)
> Maybe it's different when you build applications that only target CE. But when you want to have code-sharing between embedded target and normal PCs then working with embedded linux is here a much more pleasent experience where you can run the same code on the target and have state-of-the-art tooling.
Back in the glory days, you did have the same tooling, for anything non-kernel related you got VS support! (If you were doing kernel work you instead dealt with Platform Builder.)
One advantage of One Core at Microsoft is that everyone gets the same tooling now. There was an entire team who had to support a debugging platform for WinCE, but Visual Studio at the time (and to a much lesser extent now) was not designed to support plugging in new debugging frameworks. Thankfully it is now /possible/, back then it required that the WinCE team fork all of VS!
Suffice to say this was a huge headache and it was responsible for a large part of why WinCE's dev story was so unpleasant.
How much did Ford pay Techcrunch to write this glowing advertisement? The interface doesn't look nice at all, look at those harsh shadows and bezels on the edges (especially the buttons). It looks outdated in comparison to iOS and Android. Not to mention the article mentions how smooth the experience is, if you watch the video you can see lag (on maps in particular), UI flicker and other animations for the sake of animating (see the keyboard come into view). It might be faster than SYNC2, but it is not as perfect as this paid-for looking piece proclaims.
The article fails to also mention that QNX is owned by Blackberry, they acquired QNX Software Systems in 2010. I am honestly surprised that this isn't a stated fact in the article. In-fact, it is a known fact that QNX dominates the in-car operating system market and have contracts with a few other car manufacturers, notably BMW.
The real story here is: Microsoft loses out to market dominating Blackberry QNX.
From the article: "Sadly, since the new Sync runs on a totally different hardware, vehicles that shipped with the old version will not get the new hotness."
This is the #1 reason why I'm not interested in high-tech displays and car automation from the car manufacturers.
I drive an 18-year-old car, mostly because I enjoy not having a car payment. I'd rather deal with an ancient cassette deck than have more of my dashboard functionality imprisoned in an ancient (and possibly poor-performing) UI that cannot be upgraded.
dashboard functionality imprisoned in an ancient (and possibly poor-performing) UI that cannot be upgraded.
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.
Doesn't that pretty much describe a cassette deck? :)
LOL, yes, if the manufacturer components aren't intended to be upgradeable via software. A virtual speedometer or gas-gauge, for instance, should be simple enough to never need a patch.
Navigation and entertainment systems, on the other hand, can be a lot more complex. Not only does mapping software need to be upgraded, but I think there can be some temptation on the part of content publishers to endlessly tweak potential revenue channels (the continuously increasing number of apps on my AppleTV comes to mind).
What happens when one of these updates results in degraded performance? Again with an Apple comparison: I think about my iPhone 4S' performance after iOS7 rolled out. A vehicle's performance degrades as it gets more mileage, but it can be offset by care and maintenance. What happens when a manufacturer (or their subcontractor) pushes an update that turns your 2-year-old responsive console system into a sluggish mess? Would you have purchased the car if it had performed like that?
Which is why it doesn't need to be upgraded at all! All you need is map database updates- that road closed, this new road was put in, end of story. My Garmin works like that, and I've seen first-hand with it that map databases tend to stay current "enough" for years.
Through that lens, you could view the fact that pre-WiFi, pre-cellular dash systems can only be upgraded by invasive action at the dealer as a blessing...
+1; car companies write awful software, and trying to keep up with mobile dev is a losing proposition. CarPlay and Android's equivalent are the right moves IMO. I just want my car to tell me the speed and RPM, let me shift the transmission by hand, and maybe have a big dumb screen to show things from my phone on. L
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.
I drive a newish Golf and all the tech available with the car was vastly overpriced. You want MP3? 800 bucks please. I just swapped the head unit for an aftermarket with all the things I wanted (with was just a BT receiver).
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.
Agreed, and even if the software was great (it currently isn't), I don't want a touchscreen taking up valuable space that could have been used for physical buttons. No matter how good a touchscreen interface is, it can't be used without looking at it (barring advancements in tactile feedback).
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...
Mine is approaching 30 years old (still performs great - I think periodic maintenance is largely responsible) and came from the factory with not very many amenities, but I've upgraded it with some extra sensors and a display for engine info/GPS/etc. I try to keep away from large, closed, proprietary systems whenever possible...
I simply put a Pioneer in place of the factory head unit on our ten year old Scion. It has Apple CarPlay, which is really all I need and is well-executed IMO. All of the modern tech I need for $700 and an hour's work Wish I could do the same with our Nissan Leaf, but the head unit is way too tied to all of the other systems.
I'd say this is more of an argument against manufacturer installed systems. I've had a number of aftermarket systems and they've all performed better (plus an aftermarket system is $500-700 and can be swapped out for a newer model relatively easily).
I bought a great Sony double-DIN head unit for like $250 and installed it myself. Now I have bluetooth handsfree + audio streaming and it make the stock speakers in my car sound amazing.
This is a larger factor for me than is given weight by car reviewers (with the exception of Consumer Reports' negative reviews of Ford SYNC). Knowing how much better car interfaces can and will be, I have steered clear of the current crop.
Ford is missing the mark by charging for map updates. They should offer free updates with oil changes - which gives them an opportunity to get the owner back in the dealership and to talk with them. "How's your car doing? Good. Let us know when you're ready to trade it in. In the meantime, we've updated your maps for free."
They certainly did but consider at the time the WIFI module does not connect to the Internet. It was only for inside the vehicle to sync with your device or give your device an Internet connection. The internal software never looks at the Internet; it's firewalled. And there are a ton of good reasons for this (see my post above).
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.
Interestingly, not a single mention of the word Blackberry in the entire article. Not that it's required, QNX is being pushed as a separate brand but still, makes me wonder if that is intentional. Scoring Ford for QNX is a pretty nice win for Blackberry.
QNX is still run as an entirely separate company, its one of the only remaining jewels in Blackberry/RIM's treasure chest. While they are developed with somewhat common and aligned goals, development is still fairly separate. Additionally QNX has been slow (partly due to funding) to take up the QT BB10 side of things as it is not generally part of their core business.
Had the same reaction. Business going from microsoft to blackberry seems like it would have been the interesting spin, even if it requires a bit of transitivity.
Message to QNX people; would it be possible to re-instigate the tradition from the late 90s where QNX was released as demo version for enthusiasts to play around with? The sheer stability and performance of that 1.3mb-floppy-ready OS still amazes me to this day (came with full gui, 3d models, editor and web browser..!).
They really botched that. QNX went from closed source to free-for-hobbyists to closed source to fully open source to closed source.
This killed open source development efforts for QNX. There used to be a Firefox build for QNX. The underlying QNX OS technology is great, but the organization, which has now been acquired twice, is a pain to deal with.
"Software updates come by way of Wifi. All cars equipped with the new version of Sync will also be loaded with a WIFI receiver, allowing Ford to push software updates to Sync"
Either the author is confused, or you're literally going to have to connect your car to a WiFi network to receive updates.
That sounds about right, actually. In practice, this shouldn't be a big deal for people who live in a house where WiFi reaches the garage, but I can see it being a PITA for anyone who lives in an apartment.
And nearly every phone I've seen in the last few years is attached to a carrier that charges extra for the WiFi access point feature, and even then is limited to 5GB of data. Updating your car over LTE-connected WiFi could cost you a pretty penny.
Just ridiculous. Our carriers in Switzerland tried to pull that after iPhone brought that 'feature' to them, but this was quickly ironed out by some actual competition. We have three carriers with somewhat good coverage.
I know that the US is much larger than Switzerland, but we have four carriers with good coverage. The problem is, there's only one carrier that is both willing and able to be competitive (T-Mobile). There's another one that is willing to be competitive, but due to some technical limitations, unable to (Sprint). AT&T and Verizon are both big enough to not need to compete with anyone (including themselves).
And then you remember that AT&T and Verizon used to be the same company...
I'd argue that in a bigger country there should be more competition rather than less. Of course you have the issue with population density, but if you just look at your densely populated areas, they should allow much more competition than what you have now. Once again it seems to be lobbying leading to monopolies that hamper the economy. People need to start to understand that US style capitalism isn't really deserving its name in many fields - if a market is so skewed it can't be entered anymore, then it by definition can't be a working capitalistic system.
The flip side is that the build out of a satisfactory nation wide network ought to be a lot cheaper in total in a small country. Maybe even less political depending on how Switzerland's federal system works, e.g. how involved are cantons in telecom regulation, access issues (back haul) etc.?
I would also expect Switzerland to have less regime risk than the US.
> how involved are cantons in telecom regulation, access issues (back haul) etc.?
They aren't. I also wouldn't compare a Swiss canton to a US state - Switzerland in total is about as large and about as populated as an average US state - which is true for most
many European contries. So IMO it's a better comparison to just look at Europe as a whole and you'll probably find much more regulatory grind for the carriers. And yes, of the three Swiss carriers only one is domestic only, so the others deal with this vast landscape of regulations just fine.
So to conclude I don't see how regulations are the problem - the US with a more centralistic system than Europe as a whole should do better there. My suspicion is that because the US regulations can be influenced at the federal level, it's just much easier for Big Corp. to pour lots of money into lobbying to get their way. In European countries you (a) don't get as much ROI and (b) the political system doesn't lend itself as much to it because there is a more diverse party landscape in almost all European nations, so you would have to deal with more people to get a majority. This is why I think that the US needs two things politically:
1) a switch to a more proportional election system in order to break gerrymandering and the two-party system.
2) decentralisation for industry regulations.
Both these would lead to more difficult lobbying and it has better political representation as a nice 'side effect'.
We do have more competition, or at least we have more carriers. That was partially my point. We have one more carrier than you do (although we are much larger). The problem is merely that the competitors don't really compete too much.
Whenever I read Americans complaining about their carrier, there's lots of people saying that they can't switch because only their current carrier has the coverage they need. With good coverage I mean at least 95% of the population being covered by a particular carrier, so the people who can choose between all three are 0.95^3 ~= 86% of the population. In Switzerland all three have >99% coverage of population. Granted, that's much easier than doing it for all of the US, but how about similarly dense areas? In the US there are three metros with more people than Switzerland: New York, LA and Chicago. Note that this comparison is going easy on American carriers, since Switzerland does not have the density of a metropolitan area, and is geographically much more difficult. Do you get a choice of at least three carriers with >99% there?
On a Blackberry Z10 it's just two touches: the first touch gets the main settings menu from the top (I think the same as any Android), then hitting the Hotspot icon. I use this all the time to feed the Internet to my laptop and even a couple pieces of remote machinery. I'd expect to do this to update such a car as well. And I'm really old in HN years.
How can carriers know when the phone is acting as a hotspot, and why are those bytes more expensive?
WiFi is a heck of a lot simpler than cellular. Just because it can be done by a boutique vendor selling very expensive products (Tesla) doesn't mean it's the top choice of the everyman vendor (Ford).
Look for the "Free wifi here!" signs at your local Ford dealer service parking lot.
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.
Recently I moved my family to the 'burbs and needed a car after 5 city years without one. I did not buy a Ford Flex - an otherwise perfect and very desirable 7 seat family car - simply because of its horrid touchscreen. In every other way it was brilliant, but I just couldn't do it.
Ford's recent models are truly excellent cars (I've rented many Tauruses, Explorers, and Fusions over the last couple of years), but they were all utterly ruined by that dreadful system with its awful, ugly, laggy console you're forced to use for everything that isn't actually driving.
I never once got that to work (Blackberry or iPhone). The USB port did charge the phone though.
I did manage to get music from an iPhone through the USB port, but that was on an Expedition which has a different system (and it also only worked sporadically, requiring lots of re-plugging).
Such a crying shame. Since the company moved to the global platform and started making ROW-quality cars in the USA, I've been so impressed. They look good, drive well, ride comfortably, have good engines, have fantastic interiors (by mass-market US standards)... Then you go to turn up the AC and you realize that the rotting turd in the center console means that Ford hates you.
Nair stated emphatically that there is a “hard and fast” firewall between Sync and “mission critical systems” in the car.
Wow I sure hope that's a dumbed-down explanation for the press, because I don't want my radio and (say) my ABS or traction control to have enough of a connection to each other to even establish any kind of "firewall" between them.
In a lot of cases there are multiple CAN or similar buses, like one for engine components, one for accessories, one for emissions (OBD2), etc. There definitely are valid concerns with malicious attacks, but they can be mitigated a bit by separating devices to different buses.
See my response above. There is a firewall. I won't divulge too many details other than what anyone can learn by simply disassembling a SYNC module but will say all software for SYNC must be signed and approved by Ford. The SYNC module has two CPUs. The Freescale iMX handles all the graphics and I think it was a V850 from Renesance that handles all vehicle bus communication. Between these two CPUs there is a firewall which restricts what the graphics processor (iMX) can & can't get out on the CAN bus. The communication is essentially proxied; 3rd party software doesn't have a direct connection to any vehicle network.
And the concern is precisely as you said. They don't want 3rd party software setting off air bags as the inside joke always was.
>> Wow I sure hope that's a dumbed-down explanation for the press, because I don't want my radio and (say) my ABS or traction control to have enough of a connection to each other to even establish any kind of "firewall" between them.
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.
Regardless of what the real reason was, it is nice to see mikro-kernels being used in production.
Funny how many successful embedded OS are micro-kernels while desktops OS are still struggling to achieve similar designs, the best being the Mac OS X and Windows hybrid designs.
The Microsoft Sync system in my current Ford (2015) and last Ford (2013) were the worst onboard computers I've used. They crash when restarting your iPhone if connected by usb. They loose connection with my phones. They require you use buttons on the steering wheel to select usb input and can not do it via the touch screen display when all other input sources are available. There are countless reasons why consumers should rejoice for the fact that a superior solution was picked here.
Ford committed to the hacker community that their systems could be open and maybe a standard connector will be made... but anything is better than Ford Sync.
Great, now I have two workarounds instead of using a giant screen that's installed in the front of the car that you have to use for everything else. The voice commands suck if you're speaking English as a second language BTW.
This is unfortunate, as it does signal less competition which is never good.
QNX is excellent and has been the clear dominant player in the auto world for decades. However I think is unlikely Ford will go with QNX for the major in-vehicle display in a wider capacity, Intel/Apple/Microsoft will throw cash at the pie to make it worth using their suite of technologies. Also don't forget Ford would have already used QNX already, its in embedded system everywhere! QNX just needs a better good IoT pitch yet for it to become better known or popular in the mainstream software world.
I got a Ford CMAX (which I really love!), and the dealer tried to eagerly sell me the SYNC system.
I found a car that had all I wanted, but SYNC was there so I told him I would walk away and find one that didn't have the SYNC, and was ready to do it too. In the day they lent me it to test drive, it had all sorts of WTF and features not working.
So eventually they gave me the car without charging the $1200+ for it.
I live in the Redmond area. As I was leaving he mentioned that most Microsoft employees declined that system too.
Thank God, I own 2 Fords including a Focus Electric. Sync has been by far the most painful part of ownership. Unintuitive, slow, buggy, flakey bluetooth - just a terrible user experience.
Its good for around town driving, stressful for longer trips due to varying range (50-80 miles). Biggest complaint is because it is FWD, and the battery in back, traction is terrible going from a stop up hills, or on wet surfaces.
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.