Eclipse uProtocol Is Simplifying In-Vehicle Device Communication

The growing integration of software into vehicles has brought numerous benefits to automotive OEMs, but has faced significant challenges as well. 

The historically hardware-driven process of vehicle development has resulted in a somewhat fractured landscape of software solutions. Teams across multiple companies have been solving the same problem and developing software following multiple different approaches to achieve the same goal. Even within a single company, there are often difficulties enabling different in-vehicle software domains to communicate with each other effectively. This is multiplied across the industry.

Compounding these challenges is the fact that vehicles themselves contain multiple software domains with their own established protocols, best practices, and legacy software. Infotainment systems, for example, typically rely on Android, but each domain has its own operating system, and all systems must be able to communicate with each other effectively. 

This is a significant problem facing the entire industry. While there is an expectation that safety-critical software communicates accurately and instantly, this is a given for customers, and there’s no customer-facing wow factor.

This is where the Eclipse uProtocol project comes in. It’s not another protocol trying to replace all the others in various domains, but one that maps its APIs to the existing frameworks to ensure interoperability (Figure 1). 

Figure 1: Reference topology targeted for initial stable release

Transport-Agnostic, Cross-Domain Communication on Three Levels

The Eclipse uProtocol project was developed with the aim of building a transport-agnostic, three-layer communication protocol that is fully agnostic to deployment, OS, and device. The core three-part architecture consists of, simply enough, Layer 1, Layer 2, and Layer 3 (Figure 2). 

Figure 2: Breakdown of uProtocol layers

Layer One Manages Sending and Receiving of Events

Layer 1, the transport layer, manages sending and receiving of events between software entities. To do this, three APIs must be implemented on top of the protocol. These are Send, RegisterListener, and UnregisterListener. 

Send is straightforward enough: it sends a message. The RegisterListener API registers source and destination addresses, as well as a callback function which is called each time a message with a particular source and destination arrives. Then, the UnregisterListener API simply unregisters that listener, so even if a message from that source and destination arrives, the registered callback is no longer fired. 

Layer 2 Unifies Descriptions and Manages Routing and Dispatching

Layer 2 contains several concepts. Fundamentally, this communication layer describes data and metadata in a common way to facilitate various functions and handles routing and dispatching of events. 

One crucial element is the uStreamer, a protocol bridging library, which knows how to communicate using the generic Layer 1 transport APIs, listens for request messages, bridges them over to where they need to go, and translates for the other domain. This way, individual apps don’t have to know how to communicate with the other protocols in other domains or even where their message needs to go. The bridging library handles these lower layer details. And if an end user wishes to use a Layer 1 transport that is not in the reference implementation, they only need to write the 500 or 1,000 lines of code necessary for that transport, and they can plug that into these Layer 2 pieces and use it to communicate between devices. 

Another important aspect of Layer 2 is its use of idioms to improve developer ergonomics. These are concrete implementations of the broad messaging capabilities of Layer 1 that are used to avoid the need to fiddle with the rawer methods used at Level 1 to ensure accurate message delivery. These are standard idioms used in middleware communications, including Publish, Subscribe, Server, Client, Notifier, and Notifyee, which allow app developers to ensure reliable communications without having to do the manual work of facilitating Layer 1 communications. The key here for Layer 2 is the ability for any Layer 1 transport to be used, including those implemented by an end-user in a closed-source, production setting.

Layer 3 Enhances Ease-of-Use

Layer 3 provides several useful functions to enhance the flexibility and dynamism of the protocol. 

First, it provides each connected device with its own subscription manager, uSubscription, which manages all the subscriptions both to and from that device. The subscription manager works hand-in-hand with the device’s protocol-bridging instance to coordinate the subscription registry. The subscription managing library is written to work generically with the Layer 1 transport APIs to enable its usage with any transport, even those written by an end user.

There’s also a discovery service, uDiscovery, to facilitate uProtocol’s service-oriented architecture. If you know some of the information of the device you need to communicate with — say, the service ID — you can query the discovery service for the rest. This makes it easier to set up device-to-device communications and keep track of where a given piece of software is functioning in-vehicle.

Finally, Layer 3 also includes a caching service, called uTwin. This has several uses. First, it helps devices that run more quickly or slowly than other devices to cache messages either to or from that device. This allows a slower device to access this cache and continue receiving messages in the correct order, even after the other device has moved on. The other main benefit of uTwin is that it helps new apps get up and running, as they often need some information to kickstart their processes.

Abstracting Over Hardware and Communication Details

All three layers of uProtocol are built on a language library. Available language libraries include Java, Rust, C++, Kotlin, and Python. Combined, the three layers provide several advantages to both OEMs and vehicle consumers. 

The protocol can be thought of as a kind of in-vehicle plumbing, connecting the various in-vehicle software domains and creating much greater modularity. Fundamentally, this is meant to provide three key functionalities: refreshing, reusing, and rearranging. 

Refreshing refers to the fact that for automakers, software has in the past been tied very closely to hardware. So, when an OEM comes out with a new vehicle that has a new infotainment system or some other new piece of hardware, there’s often a lot of heavy lifting involved in changing and rewriting interface software and software that enables the algorithms that support the core business features customers actually want. Because uProtocol abstracts over all that software, OEMs can write software according to uProtocol rules and then bring it forward seamlessly, no matter how the underlying hardware changes. Rather than rewriting many software components, the most that may be needed is writing a new Layer 1 transport implementation to plug in.

Reusing provides the ability to copy software from one vehicle and move it to another. This makes it easier for an OEM looking to integrate a software feature offered in the highest end model into mid-range models without tearing up the interface programming and rewriting it to work with new hardware. 

Finally, rearranging tackles the challenge of limited in-vehicle resources. The separation of in-vehicle domains and limited computational resources available often means that while one device may be at maximum capacity in terms of compute resources used, others may be underused. Consumers get worse performance and available capacity is wasted. However, uProtocol enables device functions to be shuffled between devices or even into the cloud, allowing OEMs to take full advantage of all the computational power available. 

Proof-of-Concept Release an Opportunity to Shape uProtocol

The protocol is rapidly approaching its target date for an alpha release on 30 November 2024. This release won’t contain the full spectrum of capabilities intended for uProtocol — not every programming language or transport supported by uProtocol will have an implementation on release, nor will the uDiscovery service or uTwin cache be present, and the Android domain remains a work in progress.

The alpha release will represent more of a proof of concept. But it’s an exciting one, and one that has big potential in the SDV sphere. 

For example, uProtocol is being included in the Eclipse SDV Working Group’s Eclipse SDV Blueprints. The collaborative initiative is meant to produce blueprints that bring various potential applications of SDV software to life. One is the service-to-signal blueprint, which shows how to use uProtocol to make vehicle services available in a vehicle network and connect the service implementation with physical hardware. 

The fact of the matter is that the automotive industry has been trying to move in the direction of a solution like uProtocol for about a decade. So, uProtocol is tackling a problem that everyone needs solved but no one company can invest in to deliver a solution. In other words, it’s a perfect use case of how open source can provide value. 

And with the departure of GM as the primary backer of uProtocol, there’s room for adoptees of the protocol to take greater control over its future and ensure the protocol works for them. Anyone involved can help shape the protocol at some of the earliest stages while also taking advantage of the significant work that’s already been done to get it where it is. 

If you’re interested in learning more about the project or getting involved, join our Slack channel or LinkedIn group, where I post the highlights of our weekly meetings.