SOA, Network Protocols and Connected Car Framework for Future Vehicles

Author’s Introduction

Prashanth comes with an experience of 15+ years in the Industry. Few of his favorite topics are; Human Machine Interface, Connected Cars, Android, Machine Learning and Artificial Intelligence. He has worked in countries like Germany, Singapore, USA, Romania, Sweden and now in India. Currently he is leading the activities of Cockpit Systems and Solutions in Elektrobit India Pvt Ltd. His expertise lies in designing and developing the devices for connected/autonomous car environment.

1 Abstract

As the world moves towards Autonomous vehicles, vehicles get more and more connected. Connected vehicles constantly interact with the back end/cloud ecosystem/infrastructure. The whole ecosystem has been moving towards the Service Oriented Architecture (SOA). Some OEMs call them Connected OS / Autonomous OS. The connected cars get served by multiple services, which are hosted as services. Not only on the back end, but also some of the micro services are even hosted on the infotainment head unit and other connected devices of the cars, for the internal communication between these devices. The communication happens over Ethernet, with different TCP/UDP/HTTP based protocols. The services on the cloud or the back end may provide data to the connected car. These data may correspond to various domains like vehicle information, positioning data, Analytics data or even the data needed for the autonomous vehicle movement. The services within the car are used to communicate the data in between the electronic devices, like the vehicle related data, data from the connected phone, Navigation or just entertainment data. This complete ecosystem can be considered as the backbone of the future cars. Some of the OEMs start calling it as Autonomous OS / Connected Car OS. All in all, there needs to be a Service Oriented Architecture and the connecting protocols, which becomes the core of this kind of mobility system. In this paper I would like to discuss different SOA and protocols used for few of the use cases of such a mobility system, and their analysis.

2 Introduction

Connectivity brings in more features, and facilities into the vehicles. Today the automobile industry is at the edge of a transformation. The transformation comes in because of Connectivity and Autonomous driving. Connectivity can enable autonomous driving through virtual driving or by running high computational algorithms on the cloud, or by providing real time data to the car to make decisions, etc. In addition, Connectivity can provide services to human driven vehicles, which can improve the ride quality, provide analytic services, mobility or fleet management. To provide the services to connected vehicles, it needs an infrastructure, uninterrupted internet, and service enabled in-car infrastructure, connected devices inside the car. A connected eco-system which enables the services is the backbone of the new era of mobility.

Here is an example connected car with such a connected eco-system

To achieve such an eco-system based on Service Oriented Architecture (SOA), a focused emphasize on network protocols is needed. There are different protocols available, out of which the protocol should be selected on need basis.

3 Service-Oriented Architecture in the Connected Vehicles

Service-Oriented Architecture in the vehicles can serve multiple use cases. There could be multiple services to which a car can be subscribed to, based on the requirements. The car can host some of the services internally, to serve the internal consumers or the external consumers. The consumers are nothing but the devices or the software applications. In a connected vehicle ecosystem, these can be the end points, where the data from other publishers / transmitters / broadcasters can be consumed for the applications. The endpoint in a connected ecosystem can not only be a consumer, but also can be producer. Meaning, it can be broadcasting data for other consumers. Such an end point can exist in the cloud or inside the car itself. These devices will be getting the data from the sensors, head units, usage stats, etc.

Basically, such an ecosystem can be shown as below:

When we are talking about the vehicles, the user base is large, and the above set up must be scaled for multiple users. Below is such a scaled set up:

As shown, there will be multiple requests and streaming services running, which requires a powerful backend. Car makers may set up their own backend or can go with the cloud services provided by second party like Google, Amazon or Microsoft.

I have shown multiple clouds and a separate content server in the above architectures. This is to represent the third-party clouds and the third-party content servers. The main cloud should be secured. I am referring the backend provided by the car maker as the main cloud. Third-party clouds should be used as per the requirement in the vehicle or the applications. In the current day cars, the third-party services can be like music, video, navigation, Localization, Personalized content services, etc. Or even analytics services. But they are not limited to these.

There are some important services they should be hosted on the main cloud:

1. Vehicle service
2. Security Service
3. User Management
4. Device Management
5. Personalization

Those services which are needed as per the third-party applications can be hosted on the third-party cloud. Content server provides the streaming service.

The scaled architecture only provides a high-level overview, but the exact implementation details are not the scope of this work.

3.1 Services within the car

Below diagram shows the SOA within a car’s context.

The above diagram shows few of the devices in the car. These are not all. A car can have anything more than 50 such electronic devices / Electronic Control Units today. The architecture shown in the above picture is an example. Physically, all the electronic devices are connected to a gateway in the car, and the services are hosted on the Infotainment head unit. The communication may happen through the gateway, at the application level it looks like the communication is happening between the Head Unit and the connected devices. Some of the services hosted on the head unit may correspond to their counterparts on the backend / cloud. Ideally a unit which is connected to the internet, can host the services, to which all other devices can be connected in SOA fashion. In the example above, the Infotainment head unit hosts those services. Service 1 to N represent each service which is related to a feature / set of features. For example, let us say Service 1 is “Vehicle Service”. This service can be responsible for providing the status of vehicle related data to the other connected devices. To be more specific, let us consider the status of the door lock. In some cars, the central locking system locks the doors of the car when the driver shifts the gear from 1^st to 2^nd. This is an information, that may be used by another in car electronic device. For example, the Rear Seat Entertainment, to show the status of the doors on the screen. The central locking system is controlled by the Body Control Module of the car. The gear status is observed by the power train control module. In the conventional cars today, the communication between the Powertrain Control Module and the Body Control Module happen over CAN. All other devices connected to the CAN gateway get this data over CAN network. When we move to SOA, the communication will be over ethernet. The Vehicle Service on the Infotainment Head unit should update the status of the doors by getting the data from the ECUs like Body Control and Powertrain Control Modules. So that all those connected devices can be updated about the door status. This is on a higher level. Still there exists a CAN communication between the ECUs and the Head Unit. On the other hand, SOA can be extended further one step by hosting the individual services on the ECUs itself. Below diagram shows such a system where the services are running on each different ECUs, and the data is shared across the devices in the car.

In this architecture all these devices are connected to the Gateway over ethernet and the services are distributed. This kind of architecture may replace CAN with Ethernet. This is a fully connected car, on the other hand, it needs a higher level of security, because the ECUs like Engine Control Module is connected to the internet.

3.2 Services on the Cloud

The above diagram shows a complex set up of the backend/cloud. The computer and the mobile phone shown in the diagram are the end points for the users to monitor the data/analytics. These users can be the OEMs or the car owners or the maintenance service providers (Service stations, mechanics, etc.).

There is a secured cloud or backend to which the car mainly connects to. From there the services in this cloud can decide to access the third-party clouds or backends or even content providers. The main backend can decide to route the data directly to the car or through itself. It depends on the OEM how they want to design it.

3.2.1 Proprietary Cloud / Backend

The backend can serve for multiple application. Vehicle related applications will be the primary focus. In addition to vehicle related applications, there could be applications like multimedia for the entertainment, GNSS or Map services for navigation, Telematics data for information. It is always two ways. Gather the vehicle related data from the vehicle. Provide services based on the vehicle data to the vehicle. The Car makers can prefer their own security enabled backend. This backend will then be the one which will be serving primarily the vehicle related applications. It would not sound wise to share the vehicle related data of individual customers with secondary service providers. On the other hand, it is not practical to provide some of the services from the primary cloud. For this reason, car makers can use second- or third-party providers. For example, multimedia service can be provided by Amazon prime, Netflix, Saavn, Spotify or Gaana. This will be provided by streaming. The primary cloud can help to set up the streaming channel between the vehicle and the third-party cloud.

The primary backend can be a cloud or server based. Car makers can also consider hosting their secured cloud using Cloud service providers like Amazon AWS, Google Cloud or Microsoft Azure for that matter.

3.2.2 Second / Third party Cloud

Third party cloud can be any backend which provides the services to the car owners, drivers or riders. In the previous section I discussed about the multimedia streaming. There are also map service providers in the market, like Tom Tom. Other third-party services include Car servicing, third party play stores (For Android devices in the car), gaming, Social Networking websites, etc. In future, mobility providers like Uber, Ola, Lyft, Grab, Bounce, etc. also may tie up with the Car / Bike makers, as the cars of future may become more and more shared mobility focused than owned. These services may come as integrated part of the car’s interior electronics. (Similar way how pre-installed Facebook app comes with the phone while buying a new phone).

4 Protocols

The connected cars come with a lot of scope for different types applications. To establish the connection within the car, as well as with the backend, the backbones are the network protocols. There are many network protocols available, out of which the protocols must be chosen as per the application requirements. The applications can be segregated into but not limited to:

1. Vehicle Functionalities
2. Multimedia
3. Phone connectivity
4. Over the air updates
5. Navigation
6. Analytics

Each of the use case needs different types of communication. Below are the protocols which can support the above listed features.

1. RESTFul
2. MQTT
3. XMPP
4. RTP / RTSP

4.1 RESTful

Representational State Transfer or REST works on 6 principles. It provides CRUD communication pattern to the users. CRUD stands for Create, Request, Update and Delete. Most of the REST frameworks provide 4 types of APIs. PUT, GET, DELETE, UPDATE. REST works on HTTP.

4.2 MQTT

MQTT is always good for communication with less overhead. MQTT is quite popular in IoT space. This protocol can be used for the inter device communication within the car. MQTT works on the principle of topics. There is always a device which hosts the broker. All other devices host the clients. MQTT works on TCP, in the ISO stack, it is just above the TCP / IP layer. On the application level the MQTT works on a Publisher – Subscriber fashion. When a client registers itself with the broker, it lists the topics available with it. Same way do all other clients. Now, any client can subscribe to any topic available with the broker. So that whenever there is any new data is available with a client, it posts it to the broker, so that it will be intimated to all other clients who have subscribed to that topic. Below sequence diagram shows the working of MQTT in a simple way.

This kind of model is well suited for the communication between the ECUs and Electronics within the car. A modern car can have anything more than 50 ECUs. These ECUs are connected via CAN or Flexray. When these devices are connected via Ethernet, MQTT can be the best suited protocol for notification and small data transfer. A car can have a gateway which hosts the broker, all other devices can host the clients. It can also be designed in a way that, traditional car network can persist, gateway can convert from CAN data into Ethernet data. To start with, the OEMs are moving towards Ethernet in the Infotainment space. Below is such an architecture

In the above diagram, the broker can be either in a separate device like a gateway or on the infotainment head unit. Each device connected to the Ethernet switch should have a MQTT Client. Each of the ellipses shown inside the Infotainment head unit / Gateway block are different MQTT topics. The network below the Infotainment Head Unit / Gateway block is Ethernet where as the network to the right of this block is CAN. The ECUs communicate over CAN to the CAN gateway, and there should be a mechanism to connect the CAN Gateway to the Ethernet world. The communication shown from CAN gateway to the Infotainment Head unit is one way so that the ECUs are not controllable from the Ethernet world.

1.1      XMPP

XMPP is the Extensible Messaging and Presence Protocol, a set of open technologies for instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data.

XMPP is one of the protocols which is popular in the chat applications like ICQ or Google Talk. In the future cars, there can be chat applications to provide communication between the passengers. The future cars can be Electric, Autonomous and both. The interior of the car can be a living room by itself. Passengers can use the car’s infotainment platform to communicate with each other. XMPP can also be used for the communication between the devices just like how the humans communicate. One downside of XMPP is it is not as lightweight as MQTT. So, it can be expensive for the devices to communicate with each other. A simple XMPP architecture with 2 clients look like below

Below is an example set up of network using XMPP for a connected car

4.4 RTP / RTSP

In the world of Infotainment, there is a lot of media data flowing. Media can be shared between the devices with in the car or it can be streamed from outside the cars. In the connected cars, the media can be streamed from the internet. Usually the device which provides internet to the car is the TCU. So, until the TCU the media is streamed using the service provider’s network, from TCU, the data must be streamed via car’s network. Real Time Transfer protocol or Realtime Transfer Streaming Protocol are well suited for this job. Below diagram shows the streaming connections in a car.

4.5 Combination

As it is mentioned in the beginning, a car can have multiple features and domains. Each of these can have different use cases. The features of the cars are growing as a new technology comes into the car. On the other hand, each different types of applications or use cases need different types of communication technique. So, a combination of different network protocols will help the OEMs to achieve deeper levels of connectivity. I would like to propose a combination of protocols to achieve SOA in the modern cars, based on the applications.

In the above diagram, it shows a connected car framework (Set of libraries) which is present in all the connected devices. A main device / unit which also has this framework, can host the services to which the other devices can connect to, and request the data or send the data. Depending on the application, it can make appropriate calls. To generalize, I propose a framework which internally uses other network technologies.

With this kind of set up, the OEMs can have access to data from multiple domains inside the car, which will help them to provide better analytics service. With larger data, OEMs can use technologies like Machine Learning & Artificial Intelligence in the background for better services.

5 Conclusion

As the future of automotive industry is connectivity and autonomous, it is a need for every OEM to have an infrastructure for the same. This can be achieved mainly with multiple network protocols and data transfer techniques. A framework which combines these technologies together can serve as a backbone of the whole infrastructure. This framework should be the part of all those connected devices inside the car and the backends.

6 Summary & Future Work

In summary, connected car technology has multiple layers. It depends on what level of connectivity the OEMs want to achieve. It is closely related with the use cases and applications those the OEMs want to provide to the end customers. It may range from vehicle functions, analytics, in-vehicle communication to applications with artificial intelligence. I have touched the individual topics in a very high level, there is a lot of scope to get into the details of each application.