The automotive industry faces a number of challenges related to software communication:

• In-vehicle communication is largely inherited from legacy architectures that were mostly based on CAN networks. In addition to mechatronics software for which the existing infrastructure was developed, vehicles now include multiple powerful SoCs that run massive amounts of software. This software requires new communications mechanisms.

• Vehicles are now connected to the cloud and other devices (e.g. mobile), and this connectivity requires a communication mechanism that can guarantee properties such as recovery from loss of connection and secure data transmission, driving yet different requirements on the communications framework

• Access to vehicle data from the cloud, and sharing of this data in the cloud, drives yet other requirements such as scaling and reliability

• Despite having varying requirements, all above requirements aim at transferring the same vehicle-related data, and end up being served by the same software components running that produce the data

• Defining specific communication patterns for each and every "environment" drives redundant work, complexity and probable incompatibilities

uProtocol addresses these challenges by providing a small number of communication patterns, exposed with a set of programming APIs available and consistent across the vehicle eco-system (in-vehicle ECUs, cloud and mobile). This approach enables seamless communication between applications and services, wherever they are hosted. Using uProtocol, application developers can focus on the functionality they need to develop, rather than the plumbing necessary to access the relevant services they require, and service providers develop their service once for all consumers, wherever they are hosted.

Multiple communication mechanisms have been developed over the years, each solving specific problems: SOME/IP for in-vehicle inter-ECU communication, MQTT for IoT-to-Cloud communication, Linux IPC variants for intra-SoC communication, Binder for Android IPC, etc. A connected vehicle system will require multiple of these systems, creating the challenge of bridging them together. Rather than trying to develop a new, "more universal" protocol, uProtocol’s approach is to "map" its APIs to existing frameworks, and ensure interoperability across them. This approach enables to use and combine multiple communication frameworks, while ensuring end-to-end communication between software components.

A communication protocol enabling developers to build apps and services that communicate seamlessly across one or multiple inter-connected messaging middleware.

Key principles of uProtocol:

• Unified service addressing scheme (uri and specific related to this)

  • Using the standard uri scheme (rfc3986)

  • Location-independent mechanism to access services without knowledge of where they are specifically hosted

• Support rpc, pub/sub and notification design patterns, with key properties:

  • Attachment to messages (and automatic transfer of attachments from publisher to subscriber)

  • Permission & priority management

• Well-defined APIs formalized in protobuf for accessing services

• Developers access services by using generated code from protobuf definitions:

  • Code generation is specific to language

• Protocol is layered to make it easy for developers to use and implement, and also facilitate adding support for new languages and transport mechanisms

• Same subscription API across all platforms, formalized as a service itself (uSubscription service) where the subscription flows across platforms and across different transports automatically

  • Implementation may be custom to a given platform (not relying on generated code)

1. Pick a Programming Language: To build applications and services (uEs) that uses uProtocol, you’ll first need to pick a programming languages, such as: Rust, Java, C++, Python, and Kotlin. Each library contains a README that will explain how to build and use uProtocol for their programming language.

2. Pick a Transport: Next you’ll need to decide the communication middleware (transports) your uE will run on top of, some options are Eclipse Zenoh, SOME/IP, MQTT 5, Android (Binder), etc…​ Check out the list of projects below to find a combination of language and transport that suits your needs, if you don’t find one, we would love a contribution back :-).

3. Setup a Deployment: Finally, to run your uE, you’ll need set of additional core services running in your system. The core services, such as uSubscription, uDiscovery, etc…​ are required to complete the protocol and connect your application/service to other implementations (i.e. to connect your Android system with a Linux implementation, connect to the cloud, etc…​).

If you want to know all the details of how it works, feel free to browse the Specifications