GM Backed "Open Source Protocol" for Connecting Vehicle Apps and Services
projects.eclipse.org
projects.eclipse.org
"Up to the cloud"
There is no need for a car to "up to the cloud". Just give me a local Bluetooth network that reports back to me engine ECU reports, statistical logistical reports and driver stats. Because as soon as you leave the ground to "reach the cloud" that's where open-source stops.
The end-goal is, not surprisingly, to take away ownership and control. "Open source" is just a distraction, a way to paint this in a trendy positive light. Lots of things that are truly open source are actually user-hostile too. Whether the source is open doesn't really matter here.
Especially during the winter when it's -15C or below it's really nice to step into a warm car compared to an ice cold car.
But that would not require a subscription.
If you want to make that trade you guys go ahead. Me: bad trade.
Just look at this garbage. Not one mention of any of the issues or security problems these companies are condemning themselves to, not to mention the consumers…
https://www2.deloitte.com/content/dam/Deloitte/de/Documents/...
Vehicles can last 10-20 years, but updates from manufacturers top out at 5-7 and are almost exclusively closed source and lawsuit / litigation heavy and willing.
It is kill box territory.
Not a hard feature to program
You can start a car from 2km away by pushing a button on the key ring. This is a solved problem. That doesn't involve a smartphone.
Besides an app allows much more than a simple on off.
Not saying you should have to sell your privacy for ut, but there are some potential positive things by having the car connected to the cloud. So if there's a way to do that without the shenanigans then that might be good.
Who started this myth?
I love how tech people always believe that what they dont like nobody likes and consumers are forced.
Most people simply don't give shit if things go over local networks or clouds. People like opening an app and seeing if somebody is stealing from their car. To prewarm the car from whereever they are. And so on and so on.
And its not actually what traditional car companies want. In fact, they are in panic mode because new companies like Tesla and car makers from China have interduced these things and costumers prefer prefer it.
So now they are rushing to catch up and often doing it badly.
Since it's not named in the title it's: Eclipse UProtocol. Protobuf & CloudEvents. Url-based, with different devices ("UDevice") each getting their own dns name ("UDomain"). Somewhat transport agnostic. Http2, amqp, mqtt, dds (used some in ROS robotics os).
This makes me rather miss Webinos, which was a connected is with pretty interesting end user privacy systems kind of built in that let the device kr car talk to a cloud, but a user defined cloud.
Why? Auto vendors realized they lost control through their ineptitude of the user interface, and want it back. Problem is no one wants what they have to offer, that is a sub-par experience in every way to simply letting them use their phone as a screen in their car already there.
Automobile vendors realized they screwed up and lost real estate while they were still screwing with Microsoft, Clarion, all the other WinCE vendors and few others longer than they should, and are simply going to piss everyone off trying to take it back again.
I imagine partly because it uses the physical buttons located around the screen, partly because automakers have much more stringent requirements for software validation.
e.g. Maybe 1 out of 1000 times the built in maps app crashes, gives an error, or doesn't respond to an input. That ratio is more like 1 in 10 for Maps in Carplay.
What's the reasoning behind this? Apple itself tends to be late in supporting a lot of things, but when they do it's more polished then competitors.
I was addressing the parent's claim that the Carplay integration is 'much worse' then other automakers.
Carplay & android auto do have issues connecting at first but the apps themselves never seem to crash.
Have you never had an unresponsive screen before?
Count yourself lucky if you have a stable, crash free Google Maps experience!
Since it's not named in the title it's: Eclipse UProtocol. Protobuf & CloudEvents. Url-based, with different devices ("UDevice") each getting their own dns name ("UDomain"). Somewhat transport agnostic. Http2, amqp, mqtt, dds (used some in ROS robotics os).