feature article
Subscribe Now

How Does a Car Talk to the Cloud?

Excelfore Has an Idea

Pop quiz: Is a car a Thing?

This gets us into that perennial discussion of what goes into what group. There are tons of IoT gadgets that fit into the IoT group, but is a car one of them? After all, the car of the future will communicate with the cloud, so it will be on the internet. And it is, of course, a lower-case thing. But does it rate upper case?

Talking to Excelfore, the answer is, “No.” There are, however, lots of Things in a car. Which I guess would make it more like a house: the house itself isn’t the Thing, but it can contain lots of Things.
So… if the car is merely a Thing container, then how do you get the data from the Things up to the cloud, and how do you get commands for the Things down from the cloud? This is Excelfore’s area of focus.

As they tell it, some Tier 1 suppliers have come up with proprietary schemes for connecting the pieces of a smart car and coordinating communication with the outside world. But that means you can’t mix and match components and sub-assemblies; they can interconnect only pieces that happen to speak the proprietary language – or live with not all components getting cloud access. It also significantly complicates the supply chain, since components would need variants for different schemes. And not all Tier 1s are happy with the status quo.

Over the Moon – er – Air

What we’re talking about here is what Excelfore generically refers to as “over-the-air,” or “OTA.” I’ll confess that, based on most-frequent usage, I associate OTA with updates, since IoT discussions often make explicit reference to OTA updates (but less reference to OTA non-updates – that is, anything else OTA).

Then again, this makes sense. While many IoT devices communicate wirelessly, many others don’t; it’s not a requirement. But I’d say it’s a safe bet that automobiles have wireless communication as a requirement, not as a nice-to-have. Unless you want your car to come to the end of its tether, while, at the same time, tangling up the entire highway, you probably don’t want your car communicating over a wire. So over-the-air simply means wireless.

Excelfore is targeting all communication between in-car devices and the cloud, and they’re doing so through their in-car network and their eSync service, which connects car to cloud. The idea is that each provisioned car would have an eSync client in it – which would appear to serve the same purpose as a hub in a home. Each electronic control unit (ECU) or other piece of electronics that needs to report data to the cloud would have an eSync agent.

Those agents all report into the client, which handles the communication with the cloud. The in-car network is wired; the cloud connection is, as we’ve suggested, wireless. Within the car, they have their own proprietary protocol called xl4-bus, which sits atop TLS/TCP/IP. Connecting to the cloud, they use a different proprietary protocol over HTTPS/TLS1.2.

(Click to enlarge; image courtesy Excelfore)

Note that, within the eSync client, the “DM” in “DM Client” stands for “download.” Excelfore’s Director of Marketing Mark Singer says that, “Every time power is applied to the in-vehicle network, all eSync Agents in the car will register with the DM Client, which will assemble a current manifest of all eSync-compliant devices in the vehicle. This manifest ensures that current information on every device, never more than one power-cycle old, is available.” Meanwhile, the HMI (human-machine interface) service provides messages to the infotainment center for display to the driver.

From a programming standpoint, each ECU includes the code for the agent, and the agent has an API that the client uses. The client, meanwhile, uses a different API for connecting to the eSync Server in the cloud, which then communicates with their so-called Campaign Manager by yet another API.

Spreading the Word

“But,” you ask, “how do the ECUs from a variety of different suppliers all end up with the agent code?” That’s where ecosystems come in, and, in order to spur a healthy ecosystem, Excelfore has established the eSync Alliance, intended to help eSync to proliferate and to ensure compatibility through plug-fests and certification.

(Click to enlarge; mage courtesy Excelfore)

The eSync spec itself will be available to alliance members, of which I am not one, so I haven’t seen it. While eSync is intended to replace various Tier-1 proprietary schemes – or to serve Tier 1s that don’t have proprietary schemes – it is itself proprietary to Excelfore, at least until it becomes an official standard.

I asked if that was in the offing, and Mr. Singer said, “Not at this time,” noting that, “Typically, the standards in the automotive sector arise through industrial cooperation, with some number of like-minded companies driving rapid advancement of a common approach to some technical challenge. Then, sometimes, those multi-company de-facto standards will be taken up by the larger standards bodies such as IEEE, ISO or ASE, or they may remain with the smaller more focused industry trade associations.”

Will This Get Me Tracked?

Then there’s the question of privacy, and, yeah, that’s a thing I always come back to. The main purpose for such networks is to let the builders of components understand how those components are performing and how they can be improved.

But, really, there’s tons of information that can, theoretically, be gleaned by having the right data delivered to the cloud for sale to someone else. If some car manufacturer – or the maker of, say, some location-services component – realizes that they can map your locations and see where you went, could they mine that information? Could they, for example, figure out how often you go to Starbucks and then sell that data to Peets?

Another infamous old case was the rental car company that monitored your speed and tacked on an extra $150 if you ever exceeded the speed limit. This particular example illustrates two points: you don’t need a cloud connection to do that (since this was long prior to the current rush to the cloud), and, at least as I recall, the outcry was enough to harm the business – meaning that, as long as the customer realizes what you’re doing (which a $150 charge will do), there may be consequences to behavior viewed as bad.

So how does eSync play into this? Well, as Excelfore tells it, it doesn’t, really. They point out that you can already do all of this stuff without them. So it doesn’t really further enable or curtail the ability to gather any data. All they do is provide the means for communicating the data.

They did point out that the new European GDPR standards can play into this as well. Anonymization is the upcoming name of the game there, and that can be handled by stripping the VIN number from the messages going to the cloud. That way the useful data is still there without identifying the car owner. (You really can’t identify the actual driver – unless cars are equipped with inside cameras and universal facial recognition… or require an account and password for any potential driver… neither of which seems remotely impossible…)

Of course, that’s Europe. What about elsewhere? It’s surprising how many big companies that make money off of personal data are saying that they will apply the European rules universally. Not clear if car makers are going to do that; after all, they make different models for different markets.

But, as noted by Mr. Singer, that really gets to what the OEMs and their suppliers have as a priority for how to make money. If they’re doing it the old-fashioned way – by making, selling, and then improving products – then segregating data for sale for advertising will be a distraction. My skeptical side notes that this makes sense – as long as the BoD doesn’t feel like it’s unnecessarily leaving money on the table.

This is how Excelfore sees things playing out. Even though their contribution to the infrastructure doesn’t directly help or hinder data sale, they don’t see that as a likely outcome of the data gathering.

So, with that, if they’re successful at getting eSync to proliferate, you may find it in a car near you in the coming years.


More info:

eSync Alliance

One thought on “How Does a Car Talk to the Cloud?”

Leave a Reply

featured blogs
Oct 26, 2020
Do you have a gadget or gizmo that uses sensors in an ingenious or frivolous way? If so, claim your 15 minutes of fame at the virtual Sensors Innovation Fall Week event....
Oct 26, 2020
Last week was the Linley Group's Fall Processor Conference. The conference opened, as usual, with Linley Gwenap's overview of the processor market (both silicon and IP). His opening keynote... [[ Click on the title to access the full blog on the Cadence Community s...
Oct 23, 2020
Processing a component onto a PCB used to be fairly straightforward. Through-hole products, or a single or double row surface mount with a larger centerline rarely offer unique challenges obtaining a proper solder joint. However, as electronics continue to get smaller and con...
Oct 23, 2020
[From the last episode: We noted that some inventions, like in-memory compute, aren'€™t intuitive, being driven instead by the math.] We have one more addition to add to our in-memory compute system. Remember that, when we use a regular memory, what goes in is an address '...

featured video

Demo: Inuitive NU4000 SoC with ARC EV Processor Running SLAM and CNN

Sponsored by Synopsys

See Inuitive’s NU4000 3D imaging and vision processor in action. The SoC supports high-quality 3D depth processor engine, SLAM accelerators, computer vision, and deep learning by integrating Synopsys ARC EV processor. In this demo, the NU4000 demonstrates simultaneous 3D sensing, SLAM and CNN functionality by mapping out its environment and localizing the sensor while identifying the objects within it. For more information, visit inuitive-tech.com.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured Paper

New package technology improves EMI and thermal performance with smaller solution size

Sponsored by Texas Instruments

Power supply designers have a new tool in their effort to achieve balance between efficiency, size, and thermal performance with DC/DC power modules. The Enhanced HotRod™ QFN package technology from Texas Instruments enables engineers to address design challenges with an easy-to-use footprint that resembles a standard QFN. This new package type combines the advantages of flip-chip-on-lead with the improved thermal performance presented by a large thermal die attach pad (DAP).

Click here to download the whitepaper

featured chalk talk

Using the Graphical PMSM FOC Component in Harmony3

Sponsored by Microchip and Mouser Electronics

Developing embedded software, and particularly configuring your embedded system can be a major pain for development engineers. Getting all the drivers, middleware, and libraries you need set up and in the right place and working is a constant source of frustration. In this episode of Chak Talk, Amelia Dalton chats with Brett Novak of Microchip about Microchip’s MPLAB Harmony 3, with the MPLAB Harmony Configurator - an embedded development framework with a drag-and-drop GUI that makes configuration a snap.

Click here for more information about Microchip Technology MPLAB® X Integrated Development Environment (IDE)