The Connected Car and XMPP

I attended O’Reilly Solid 2014 in San Francisco and during my discussions was asked by a few automakers to submit overview of how XMPP and CYTIoT, Inc. can create a more secure, private and efficient platform for the tele/informatics systems in both their vehicles.

Disclaimer, I am not familiar with verbiage on the car industry so please excuse if I am not calling things by their correct name.

Ford was showing off its latest lab success which will allow a person to plug a dongle into the diagnostics port inside the car.  It reminds me of the AT&T Digital Life offering, which makes no sense to me either.   Basically in both cases they have a really cool app that allows the owner of the asset to know what is going on with it, which is fantastic if I am a mechanic or within range of my home to address the event I am being alarmed about (I do not mean turn off light, I mean water leak, gas leak etc.). What is needed is the event to be sent in real time to someone/thing that can take action.

The IoT is still in the visualization and database stage with people being awed by seeing things they have not been able to see before or being told that they will be able to know how their thing is running over a period of time.  Where IoT needs to get is to the actionable stage, where events that affect critical asset or life can be sent to applications or humans that can act upon them in real time and not have to wait for analytics on entire systems to be completed.

In the instance of the car, knowing that oil pressure is low or battery is drawing more power than it should means nothing to most people that drive cars.  The information is important to engineers and mechanics that can act upon the event, maybe action over the connected network can be taken to prevent the engine light from coming on, or immediate connection with a qualified mechanic to address the issue for $100.00 as opposed to $4000.00.  If automated proactive maintenance could happen on automobiles that are basically rolling computers now, how much energy savings would we realize?

Now the issue is getting the data to the proper source efficiently and securely, the last thing we need is hackers taking over vehicles and causing mayhem on the streets.  The current systems do the later, based on HTTP or protocols like MQTT which need external over blown security platforms that are unreliable and unsecured.  The big company solutions need too many resources to be efficient and are incredibly costly to implement and maintain, which they happen to also sell.

Let’s look at what can be done today by using a commercial XMPP platform.  A car can be connected with a secure channel bound connection (channel binding mitigates man in the middle attacks and compromise of data during layer 2 and 3 hacks and attacks).  XMPP enables event driven SOA 2.0, this allows a manufacturer to understand if a car is operating within normal operational state, there is no need to know this every second, send me a file every 5, 15, 60 minutes (your choice) stating the fact as well as the performance fluctuation inside the prescribed normal operational state (this will allow even better defined parameters).   A company can analyze that data and make changes in parameters and manufacturing with the data.

What I want to know, and want to know immediately is when a car (or system within) is acting outside of normal operational state.  Not only do I want to know that, I want to be able to deliver that message to a person (at HQ or in a geographic area to the vehicle) that can take action upon event to prevent damage, expensive repairs and most of all loss of human life.  This is what a protocol built on a proprietary platform with ability to dynamically assign events to endpoints that can take action on the event can do.  They say XMPP is a heavy protocol?  See how heavy any other protocol gets when you add all the functionality of XMPP.  Also consider the bloated infrastructure you need to support those other protocols.

There is need for all types of protocols in the IoT, XMPP is not the universal answer.  XMPP is the answer to the Gateway to Cloud portion of IoT though.  United States Department of Defense believes so as XMPP is mandated for Real Time Communications for Voice, Video, CHAT and Messaging Presence (the last two engulf machine data) based on interoperability and security.  UPnP forum also believes so as they have announced the 60 day public review before final vote which will make XMPP “THE” protocol for UPnP devices to the cloud.

It is time to stop gawking at visual effects and listening to data base startups and established companies marketing.  It is now time to act upon the IoT with the true need, take action upon the systems and events that are going to save critical asset and human life.


2 responses to “The Connected Car and XMPP

  1. Thanks, Michael for sharing your thoughts regarding the usage of XMPP on the IoT. At Bosch Software Innovations we are also using XMPP for connecting gateways to our M2M back end. In particular, we are also using it – no surprise here since we’re Bosch 😉 – to connect cars to our back end. What we are considerably struggling with is establishing and keeping up an XMPP connection on top of the inherently unreliable IP connection provided by GSM (used to connect the car to the internet). In this area, my feeling is that any connection oriented protocols will have difficulties, in particular if the car drives in rural areas where GSM coverage is much less ubiquitous than in metropolitan areas. Do you have any experience with addressing these issues when using XMPP? One of the main issues with XMPP in this context, frmo my point of view, is its unresponsiveness with detecting loss of connection. Any thoughts?


    • We do have a fair bit of experience dealing with unreliable IP connectivity. Staying within the XMPP standards there are not a lot of options to be able to deal with it well, though there are a couple of things you can do within the spec and a few others with a custom solution.

      Detecting connection loss is particularly challenging because you’d really like to depend on TCP to do that for you. It’s cumbersome and not really efficient to have the application try to detect lost connections. If the client is transmitting on a regular basis it’s not too bad as the broken connection will be detected and restored at that point. Since it is desirable to avoid long periods during which the client is unreachable, client heartbeats must be used to detect connection loss which puts additional bandwidth pressure on the system when the connections are good. The actual severity of the problem depends on a few factors like the frequency of client transmission, the need for the client to receive time critical information, and the definition of “time-critical”.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s