SommR is coming
A first step from uProtocol into the embedded automotive domain
In the first part of this (very little) series, we stuck our toe in the waters of communication semantics and syntax, and what both of these can mean in the context of software-defined vehicles (SDVs). We took a tentative look at the challenges associated with building actual products in a world where the landscape of potential solution options is huge and growing, coupled with an equally wide variety in engineering culture within the vehicle product scope. We wrapped things up by taking a look at the Eclipse uProtocol project and how it aims to add value in this context.
Now, we will spend a bit more time investigating success factors for the uProtocol vision. We will pursue one opportunity a bit farther, with an outlook for what might happen this year if a few stars align as expected.
uProtocol success factors
uProtocol by itself is no all-inclusive solution to all the vehicle world's communication problems. Rather, it could be called 'meta-middleware', providing glue and common concepts to allow inter-service communication between the technologically diverse domains involved in modern vehicle-cloud-app scenarios.
For a piece of software infrastructure like this, it takes a conjunction of many spheres to become truly successful. As we have hinted at in the first article, most of these are not of a technical nature. Let us define a few dimensions of success, as a backdrop for the remainder of this discussion.
Technological success is the axis where something solves a specific technological problem and does it sufficiently well to be considered fit for purpose measured by whatever technical KPIs are relevant in a given scenario.
Maturity success is about fulfilling 'non-technical' requirements that go beyond pure code: is it the goal and mindset of the developing community to build and maintain production-ready software? Does this result in the creation and evolution of non-code artefacts that relate to and contribute to quality process adherence metrics?
Adoption success is essentially the value-add multiplier of a project, where the question asked is: "Is this code productively used by more than one organization?" This attribute actually has a second, more implicit effect that is still highly desirable: Every active adopter and contributor of a codebase per definition knows 'how things work', they speak the same vocabulary. This is a major boon for any commercial collaboration, as the involved parties can skip the conceptual and technical alignment and go straight to the value creation part of their work.
Ecosystem success happens when all of the above factors align, and the core piece of technology allows for extensibility and encourages contributions of all kinds. A successful ecosystem allows participants to leverage the adoption success of the core elements for their own extension and contribution - both for open and commercial models. Ecosystems can create incredibly successful toolboxes for solving specific problem areas - as an extremely successful example, compare the Cloud Native Compute Foundation ecosystem that grew up around the core concepts (and implementation) of kubernetes (k8s).
While I would be (delightedly) surprised to see uProtocol grow to the scope of k8s, we can still envision the above steps of success for this smaller project and discuss ideas that might help us along that path.
uProtocol concepts
To illustrate uProtocol concepts, let us imagine a use case where speed information for a specific vehicle is being requested from a smartphone companion app, which results in a speed-datagram subscription request travelling all the way from the app, via a bunch of backend services, to the vehicle in question, and inside the vehicle to the domain and control unit that is actually able to provide the requested datapoint. The subscription endpoint processes the subscription request and proceeds to publish speed information to its "network neighborhood", which is then picked up and forwarded along the entire chain by the uProtocol service mesh, resulting in the companion app displaying (almost) current vehicle speed.
uProtocol defines a couple of components to achieve this:
- uPClient implementations that adapt the overarching uProtocol sub/sub and command/response messaging to specific transport protocols. For example, there can exist a Rust implementation of a uPClient for the MQTT protocol.
- uStreamers are able to route messages (pub/sub data, command/response messages) between different transport protocol domains. To do this, a uStreamer connects to at least two uPClients, and tracks which messages need to go from one to the other.
- uSubscription services manage inter-domain subscriptions - for example, if two different pub/sub networks are part of a larger solution, uSubscription components in each of these networks keep track of and forward subscription requests from clients in one network for messages that originally are published in the other.
There is more detail, and a few more components - like uTwins which can be used for caching/buffering/storing data within a domain or for a set of domains (like for the entire vehicle) - but we will stick close to the core building blocks for this article.
This architecture of components with designed-in extension points exhibits the key characteristics that an ecosystem might be built on: it combines a definition of the core programming model (APIs, semantics) with the clear understanding that only adoption and the building of a larger toolbox in a community will truly bring the original vision to life. uProtocol becomes exponentially more useful with each adopter who adds to this toolbox. For instance, adding a single new uPClient adapter will raise the value of each other uProtocol component, because it extends the applicability of all of them to a new environment.
The embedded connection
For uProtocol to be useful as an automotive service mesh, it needs to connect to automotive protocols, i.e., in-vehicle communication networks of mechatronics domains. This is where things usually become complicated, for reasons that would fill an article of their own. So in this text we will picture a scenario that is useful on a conceptual and ecosystem level, even though an actual implementation cannot be made publicly available at the time of this writing1.
In keeping with the theme lined out above, a good first step from uProtocol into the embedded automotive domain would be to link up pub/sub networks on both ends of the spectrum. On the automotive side, one relevant candidate protocol is AUTOSAR® SOME/IP, a specification for pub/sub style communication on top of automotive network infrastructure. By creating a SOME/IP uPClient implementation, we can make SOME/IP network segments become part of the larger uProtocol service mesh. This would enable the example use case described above, where a speed datagram is published by an entity inside an in-vehicle SOME/IP network 2 and then routed to other segments of network/protocol infrastructure via uProtocol mechanisms.
The main challenge with this idea is again non-technical: SOME/IP is an AUTOSAR® specification, which means that open source implementations of the current spec version are prohibited by the AUTOSAR IP license 3, and therefore there can't be an implementation of a uProtocol-SOME/IP connection in an open source project.
Hopes for SommR
At this point, in the Eclipse SDV working group we are waiting for SommR to come. SommR is a from-scratch implementation of SOME/IP in Rust, which would be a perfect fit for building a uProtocol bridge to. Since the project announcement in the middle of 2022, the project contributor has been working to achieve clearance regarding AUTOSAR® IP policies, and while this has not yet come to fruition, chances are for a positive outcome within this year.
Once SommR is here we will see a uPClient linking to it, thus enabling SOME/IP integration into uProtocol service meshes. This will allow us to build the companion app scenario above, as well as similar setups that include SOME/IP control units. We hopefully will get a first bridge between the open source and traditional automotive worlds.
One more thing that might become interesting in this context: both SommR and uProtocol projects aim to deliver and maintain production-ready code for use in automotive products. Details and extent of this are still evolving, but it is safe to say that there will be a substantial coverage of concerns like process definition (via the Eclipse Foundation Development Process), project requirements specification, documentation, test coverage and related KPIs, etc. These projects are likely to become early adopters of the (equally still-developing) Eclipse SDV quality/maturity program, which aims to provide the foundations for this software to be used in commercial automotive product engineering processes.
Takeaway
To summarize, Eclipse uProtocol and the upcoming Eclipse SommR project can become a showcase for how open source can be a key enabler for building automotive software infrastructure. This showcase will include:
seamless integration of established automotive domain technology with IT-style network stacks, building a larger whole.
hands-on example of how open development models and open-source foundations can enable first-order, low overhead collaboration between partners in the automotive value chain
an incubator and proving ground for how OSS projects can provide automotive-grade software quality, and thus maybe even some idea of what that actually means...
If anything mentioned here sounds relevant to you, we would be delighted to welcome you in the Eclipse SDV Slack space, our uProtocol project meetings, the mailing list, or any of our community events (for more info on how to do any of that, please refer to this Eclipse SDV info page).
"Collaboration across boundaries is the best way out of the usual zero-sum corporate game."
1: But see the last section of the article.
2: No, a uProtocol mesh would not replace a dedicated solution that is optimized for high-throughput, lowest-latency real-time communication. Yes, that still leaves many use case scenarios that are relevant and expected by customers (in fact, that usually are much more visible to customers). No, uProtocol as a whole is likely not a useful object for discussing automotive safety certification - although sub-parts and dedicated adapters very well might be.
3: We are aware of the vsomeip project. But with the ongoing controversy about any open implementation of existing AUTOSAR® specifications, we are not quite sure where we stand wrt that one.
Contact us
Do you have any questions? Feel free to send us a message. We will be more than happy to help.
Contact us today!