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.