SommR arrive

Dans la première partie de cette (très courte) série, nous avons abordé la sémantique et la syntaxe de la communication, ainsi que leur signification dans le contexte des software-defined vehicles (SDV). Nous avons examiné de manière préliminaire les défis liés à la création de produits concrets dans un monde où les solutions potentielles sont nombreuses et en constante évolution, et où la culture d'ingénierie est tout aussi variée dans le domaine des véhicules. Nous avons conclu en nous intéressant au projet Eclipse uProtocol et à la manière dont il vise à apporter une valeur ajoutée dans ce contexte.

Nous allons maintenant consacrer un peu plus de temps à l'étude des facteurs de réussite de la vision uProtocol. Nous allons approfondir une opportunité, en nous projetant dans ce qui pourrait se passer cette année si plusieurs éléments s'alignent comme prévu.

Le protocole uProtocol n'est pas en soi une solution exhaustive à tous les problèmes de communication dans le monde automobile. Il pourrait plutôt être qualifié de « méta-middleware », fournissant une base et des concepts communs pour permettre la communication entre les services dans les domaines technologiquement diversifiés impliqués dans les scénarios modernes impliquant des véhicules, le cloud et des applications.

Pour qu'une infrastructure logicielle comme celle-ci soit vraiment couronnée de succès, il faut que de nombreux facteurs soient réunis. Comme nous l'avons laissé entendre dans le premier article, la plupart d'entre eux ne sont pas de nature technique. Définissons quelques dimensions du succès, qui serviront de toile de fond au reste de cette discussion.

Le succès technologique est l'axe où quelque chose résout un problème technologique spécifique et le fait suffisamment bien pour être considéré comme adapté à l'usage prévu, mesuré par les indicateurs de performance clés techniques pertinents dans un scénario donné.

La réussite en matière de maturité consiste à remplir des exigences « non techniques » qui vont au-delà du simple code : l'objectif et l'état d'esprit de la communauté de développeurs consistent-ils à créer et à maintenir des logiciels prêts à être mis en production ? Cela se traduit-il par la création et l'évolution d'artefacts non liés au code qui sont en rapport avec les indicateurs de conformité aux processus de qualité et y contribuent ?

Le succès de l'adoption est essentiellement le multiplicateur de valeur ajoutée d'un projet, où la question posée est : « Ce code est-il utilisé de manière productive par plus d'une organisation ? » Cet attribut a en fait un deuxième effet, plus implicite, mais tout aussi souhaitable : chaque adoptant et contributeur actif d'une base de code sait par définition « comment les choses fonctionnent », ils parlent le même vocabulaire. Il s'agit là d'un avantage majeur pour toute collaboration commerciale, car les parties impliquées peuvent passer outre l'alignement conceptuel et technique et se concentrer directement sur la partie de leur travail liée à la création de valeur.

La réussite d'un écosystème se produit lorsque tous les facteurs ci-dessus s'alignent et que la technologie de base permet l'extensibilité et encourage les contributions de toutes sortes. Un écosystème performant permet aux participants de tirer parti du succès de l'adoption des éléments de base pour leur propre extension et contribution, tant pour les modèles ouverts que commerciaux. Les écosystèmes peuvent créer des boîtes à outils incroyablement efficaces pour résoudre des problèmes spécifiques. À titre d'exemple particulièrement réussi, comparez l'écosystème Cloud Native Compute Foundation qui s'est développé autour des concepts fondamentaux (et de la mise en œuvre) de Kubernetes (k8s).

Même si je serais (agréablement) surpris de voir uProtocol atteindre l'ampleur de k8s, nous pouvons tout de même envisager les étapes de réussite ci-dessus pour ce projet plus modeste et discuter des idées qui pourraient nous aider à suivre cette voie.

Pour que uProtocol soit utile en tant que maillage de services automobiles, il doit se connecter aux protocoles automobiles, c'est-à-dire aux réseaux de communication embarqués des domaines mécatroniques. C'est là que les choses se compliquent généralement, pour des raisons qui mériteraient un article à part entière. Dans ce texte, nous allons donc imaginer un scénario utile au niveau conceptuel et au niveau de l'écosystème, même si une mise en œuvre réelle ne peut être rendue publique au moment de^{la rédaction de} cet^article1.

Conformément au thème évoqué ci-dessus, une bonne première étape pour uProtocol dans le domaine automobile embarqué serait de relier les réseaux pub/sub aux deux extrémités du spectre. Du côté automobile, un protocole pertinent est AUTOSAR® SOME/IP, une spécification pour la communication de type pub/sub au-dessus de l'infrastructure réseau automobile. En créant une implémentation SOME/IP uPClient, nous pouvons intégrer les segments de réseau SOME/IP au maillage de services uProtocol plus large. Cela permettrait de mettre en œuvre le cas d'utilisation décrit ci-dessus, dans lequel un datagramme de vitesse est publié par une entité au sein d'un réseau SOME/IP embarqué ², puis acheminé vers d'autres segments de l'infrastructure réseau/protocole via les mécanismes uProtocol.

Le principal défi lié à cette idée est à nouveau d'ordre non technique : SOME/IP est une spécification AUTOSAR®, ce qui signifie que les implémentations open source de la version actuelle de la spécification sont interdites par la licence AUTOSAR IP ³, et qu'il ne peut donc y avoir d'implémentation d'une connexion uProtocol-SOME/IP dans un projet open source.

À ce stade, au sein du groupe de travail Eclipse SDV, nous attendons l'arrivée de SommR. SommR est une implémentation entièrement nouvelle de SOME/IP en Rust, qui serait parfaitement adaptée à la création d'un pont uProtocol. Depuis l'annonce du projet au milieu de l'année 2022, le contributeur au projet s'efforce d'obtenir l'autorisation concernant les politiques IP d'AUTOSAR®. Bien que cela n'ait pas encore abouti, il y a de fortes chances pour que le résultat soit positif d'ici la fin de l'année.

Une fois SommR disponible, nous verrons apparaître un uPClient qui s'y connectera, permettant ainsi l'intégration de SOME/IP dans les maillages de services uProtocol. Cela nous permettra de créer le scénario d'application compagnon décrit ci-dessus, ainsi que des configurations similaires incluant des unités de contrôle SOME/IP. Nous espérons ainsi établir un premier pont entre les mondes open source et automobile traditionnel.

Un autre élément pourrait s'avérer intéressant dans ce contexte : les projets SommR et uProtocol visent tous deux à fournir et à maintenir un code prêt à l'emploi pour une utilisation dans des produits automobiles. Les détails et l'étendue de cette initiative sont encore en cours d'élaboration, mais on peut d'ores et déjà affirmer qu'elle couvrira de manière substantielle des aspects tels que la définition des processus (via le processus de développement de la Fondation Eclipse), la spécification des exigences du projet, la documentation, la couverture des tests et les indicateurs de performance clés associés, etc. Ces projets sont susceptibles d'être les premiers à adopter le programme Eclipse SDV de qualité/maturité (également en cours de développement), qui vise à fournir les bases nécessaires à l'utilisation de ce logiciel dans les processus d'ingénierie des produits automobiles commerciaux.

En résumé, Eclipse uProtocol et le projet Eclipse SommR à venir peuvent devenir une vitrine illustrant comment l'open source peut être un catalyseur essentiel pour la création d'une infrastructure logicielle automobile. Cette vitrine comprendra :

Intégration transparente de la technologie automobile établie avec les piles réseau de type informatique, pour former un ensemble plus vaste.

Exemple concret illustrant comment les modèles de développement ouverts et les fondations open source peuvent permettre une collaboration de premier ordre et à faible coût entre les partenaires de la chaîne de valeur automobile.

un incubateur et un terrain d'essai pour montrer comment les projets OSS peuvent fournir une qualité logicielle de niveau automobile, et ainsi peut-être même donner une idée de ce que cela signifie réellement...

Si l'un des éléments mentionnés ici vous semble pertinent, nous serions ravis de vous accueillir dans l'espace Slack Eclipse SDV, lors de nos réunions sur le projet uProtocol, sur la liste de diffusion ou lors de l'un de nos événements communautaires (pour plus d'informations sur la manière de procéder, veuillez vous reporter à cette page d'informations Eclipse SDV).

¹: Mais voir la dernière section de l'article.

²: Non, un maillage uProtocol ne remplacerait pas une solution dédiée optimisée pour une communication en temps réel à haut débit et à très faible latence. Oui, cela laisse encore de nombreux cas d'utilisation pertinents et attendus par les clients (qui sont en fait généralement beaucoup plus visibles pour eux). Non, uProtocol dans son ensemble n'est probablement pas un objet utile pour discuter de la certification de sécurité automobile, même si certaines sous-parties et certains adaptateurs dédiés pourraient très bien l'être.

³: Nous connaissons le projet vsomeip. Mais compte tenu de la controverse actuelle concernant toute implémentation ouverte des spécifications AUTOSAR® existantes, nous ne savons pas trop quelle position adopter à ce sujet.