Protocole Eclipse uProtocol
La communication comporte deux dimensions importantes, qu'elle implique des êtres vivants ou des systèmes techniques : le message et le médium. Ou, pour faire une analogie très approximative, la sémantique et la syntaxe.
Le message/la sémantique concerne ce qui est communiqué : deux personnes qui s'accordent sur les mêmes mots et concepts pourront avoir une conversation, qu'elles utilisent la voix, le texte, la langue des signes, le code morse, etc. Il s'agit là du contenu.
Le médium/la sémantique concerne la manière de transférer les informations souhaitées : toute série de symboles (« messages ») peut être transmise entre des parties communicantes, à condition qu'elles s'accordent sur le mécanisme à utiliser et soient capables de l'utiliser. Il s'agit là de la plomberie 1.
Dans le contexte des systèmes techniques, la portée de l'alignement sur le message/la sémantique détermine généralement l'évolutivité d'un actif : tant que le contenu des messages est bien défini, le nombre de parties communicantes peut augmenter et même s'adapter aux changements de plomberie au fil du temps. Les composants d'un tel système deviennent interchangeables et peuvent évoluer indépendamment. De cette manière, la stabilité de la logique métier est réalisable et le marché adressable des offres spécifiques à un domaine se développe (alias « écosystème »).
Dans les systèmes logiciels, la plomberie spécifique est à la fois extrêmement critique et étonnamment malléable : si elle ne fonctionne pas, rien ne circule, elle est très présente et les choses changent et évoluent continuellement. Une grande partie du temps consacré au développement de produits logiciels est consacrée à l'adaptation et à l'intégration de différentes plomberies, et on a l'impression que de nouveaux intergiciels apparaissent un peu partout, presque à chaque occasion 2.
Alors que le reste de cet article se penchera sur l'aspect technique, il convient de souligner les efforts communautaires ouverts existants en matière de normalisation du contenu : les projets COVESA Vehicle Signal Specification (VSS) et Vehicle Service Definition (uService). En collaboration avec le groupe de travail SDV de la Fondation Eclipse, ces groupes tentent sincèrement de mettre en place une offre développée conjointement et pilotée par la communauté dans ce domaine.
La situation SDV
Cela vaut également pour les systèmes embarqués et les architectures SDV (software-defined vehicles), même si quelques difficultés supplémentaires viennent compliquer le tableau. Un système de type SDV comprend des communications entre des parties très disparates : d'un côté, le domaine de la mécatronique avec des microcontrôleurs profondément intégrés dans les véhicules, qui garantissent que lorsque vous freinez, la voiture freine. De l'autre côté, il y a les services cloud et les applications mobiles destinés aux utilisateurs, qui servent à contrôler à distance les fonctions du véhicule, à gérer les profils des conducteurs, et bien plus encore.
Ces deux extrémités du spectre technologique s'accompagnent d'une gamme tout aussi large d'exigences en matière de plomberie utilisée et découlent de domaines d'ingénierie extrêmement divers. Une ligne de communication CAN embarquée en temps réel et à latence minimale est très différente d'une pile de protocoles cloud-to-app, et il existe toute une gamme de nuances entre ces deux extrêmes, chacune étant associée à une certaine culture de développement et à des implications connexes pour l'organisation environnante.
En bref : la plomberie dans le contexte des SDV est compliquée, et pas seulement sur le plan technologique.
Tous les domaines technologiques concernés ont évolué et développé leurs propres solutions pour répondre à leurs besoins. Il existe toute une gamme d'options physiques et de protocoles de transport embarqués, le domaine de l'IoT apporte sa part d'infrastructures de messagerie et de communication, et le cloud a développé une multitude d'options au cours des 10 à 20 dernières années 3. Pourtant, on attend des véhicules modernes et de leurs systèmes informatiques de soutien qu'ils tirent parti de tout cela de manière utile et qu'ils créent une valeur durable pour le client 4.
Une réaction courante face à un nouveau contexte d'exigences et à l'évolution des acteurs technologiques consiste à inventer « une nouveauté » qui résout ce nouveau défi, peut-être même sous la forme d'une norme qui recueille et traite minutieusement tous les besoins potentiellement pertinents de tous les participants 5. Il existe des scénarios où cette approche est valable. Cependant, étant donné que cela élargit le champ des solutions possibles, cela ne résout pas le problème fondamental, mais l'aggrave plutôt : il existe un grand nombre d'options technologiques qui doivent fonctionner ensemble pour créer quelque chose qui ait de la valeur pour les clients.
Vision Eclipse uProtocol
Le groupe de travail SDV de la Fondation Eclipse s'est donné pour mission d'apporter des contributions pertinentes à l'écosystème SDV, et les préoccupations soulevées jusqu'à présent sont donc au cœur des préoccupations du groupe de travail. Alors que le portefeuille du groupe de travail s'enrichit d'excellentes solutions middleware, d'eCal à zenoh, un projet récent vise à proposer une approche intégrative permettant la combinaison systématique et à l'échelle de l'écosystème de composants spécifiques dans des solutions à plus grande échelle. Ce projet, appelé Eclipse uProtocol, a suscité de nombreuses contributions depuis sa publication initiale par GM au second semestre 2023. L'approche uProtocol vise à faire deux choses différemment :
- Il ne s'agit pas d'une autre implémentation de middleware ;
- Il propose plutôt des concepts et des abstractions qui peuvent faciliter la collaboration au sein d'organisations existantes et complexes (couvrant tout le spectre technologique, comme indiqué ci-dessus).
uProtocol est le ciment qui permet de relier les domaines de communication, de la mécatronique au cloud, en fournissant une approche commune pour faire le pont entre une gamme d'options middleware généralement utilisées dans ces domaines. Il fournit des composants d'intégration prêts à l'emploi qui permettent une connexion rapide des implémentations de protocoles de transport couramment utilisés. Il définit également un ensemble d'applications de niveau supérieur qui fournissent une intégration interdomaines pour des préoccupations communes telles que la découverte de services, l'abonnement aux données et la fonctionnalité de jumeau numérique 6.
Pour mieux comprendre la proposition de valeur d'uProtocol, prenons l'exemple d'une fonctionnalité simple que l'on attend aujourd'hui des véhicules haut de gamme et qui implique au moins trois domaines technologiques très différents : l'application compagnon pour smartphone. Si l'on se réfère à des exemples contemporains, ces applications offrent à la fois l'affichage en temps quasi réel des données du véhicule (comme la géolocalisation ou la vitesse actuelle) et l'exécution de commandes à distance (comme la climatisation, l'ouverture du coffre/des portes ou la gestion du processus de recharge).
Ces deux fonctionnalités nécessitent que les données et les commandes transitent depuis les domaines embarqués dans les véhicules, via des appareils informatiques embarqués à haute puissance de calcul, des systèmes d'infodivertissement/connectivité embarqués, des backends de services cloud, vers l'application pour smartphone, et vice versa. Chacune de ces étapes implique probablement au moins un protocole de transport distinct, ainsi qu'un certain nombre d'entités de gestion, de traitement et de stockage des données. Chacune d'entre elles dispose de ses propres API et modèles de programmation, qui sont en constante évolution.
Comparez cela aux besoins des développeurs d'applications métier (« domaine ») : ils doivent interagir avec des services situés à l'autre bout de cette chaîne, qui évoluent probablement dans un contexte technologique très éloigné du leur. Le cycle de vie des produits, l'organisation des opérations et les processus d'ingénierie de ce point terminal éloigné sont très différents des leurs. Le plus souvent, même la signification des termes et des concepts utilisés par ces groupes diffère suffisamment pour créer des obstacles (cf. le thème du message/de la sémantique abordé au début de cet article).
C'est précisément ce vide que uProtocol vise à combler en proposant une méthode unifiée pour définir, localiser et adresser les services et les sources de données dans l'ensemble de ce paysage. Les adaptateurs et passerelles uProtocol introduisent un mécanisme d'adressage global pour les services, une source commune de vérité pour les points de terminaison API, ainsi que les composants de liaison nécessaires pour permettre le flux de données et de commandes au-delà des frontières des domaines. Si uProtocol reprend et intègre des concepts établis tels que la gestion des abonnements réseau pub/sub ou les caches de données de type « jumeau numérique », il est conçu pour dissocier les définitions des API métier de la technologie spécifique utilisée dans un domaine particulier, ainsi que pour intégrer tous les protocoles utilisés dans un scénario de solution spécifique.
En résumé, uProtocol permet aux développeurs d'interagir avec les sources de données et les points de terminaison API de la même manière, quel que soit leur emplacement sur la carte technologique. Au sein d'un maillage de services uProtocol, l'invocation et l'accès aux données fonctionnent de manière identique d'un service embarqué à l'autre, du véhicule au cloud, du cloud au véhicule, de l'application au véhicule, etc. Ces concepts et définitions d'API partagés (alias « modèle de programmation ») peuvent fournir une base commune pour l'alignement entre les équipes de développeurs de divers domaines. uProtocol vise à aider à combler les fossés technologiques et organisationnels.
État d'avancement du projet uProtocol
Le projet uProtocol a attiré l'une des communautés de développeurs qui connaît la croissance la plus rapide au sein du groupe de travail Eclipse SDV. En quelques mois, un ensemble relativement diversifié de contributions a commencé à affluer, contribuant déjà de manière visible à façonner et à étendre les fondements d'un écosystème potentiel compatible avec uProtocol. uProtocol démontre déjà son potentiel en tant que force d'intégration et point de ralliement pour de nombreux composants SDV open source.
Il convient de noter que les spécifications de base et les définitions API sont en cours d'évolution et d'amélioration, qu'un certain nombre de nouvelles bibliothèques de langages de programmation (SDK) sont en cours de développement (actuellement, uProtocol prend en charge Java, C++, Rust, Python et Kotlin) et que la première vague d'adaptateurs de protocole est en cours d'élaboration, reliant Android Binder, Eclipse Zenoh et les courtiers MQTT. Si les choses continuent à évoluer à ce rythme, en 2024, nous verrons le service fabric uProtocol introduit dans un ou plusieurs projets Eclipse SDV Blueprint comme preuve et vitrine visibles du public.
Perspectives
À l'heure actuelle, uProtocol est un élément central de la plateforme Ultifi de GM, apportant à la fois crédibilité et dynamisme à l'ensemble du projet. Cependant, la véritable valeur d'un projet open source réside dans sa capacité à apporter une valeur ajoutée à plusieurs utilisateurs et, éventuellement, à devenir le fondement d'un ensemble diversifié d'offres ouvertes et commerciales qui se développent dans l'espace technologique partagé. Par conséquent, l'adoption supplémentaire d'uProtocol dans des produits réels et des infrastructures opérationnelles est un indicateur clé de succès pour les années à venir.
Pour atteindre cet objectif, il faut davantage d'adaptateurs et de passerelles uProtocol vers des technologies automobiles spécifiques. Pour une communauté open source, cela devient rapidement un défi, car les piles de protocoles automobiles traditionnelles sont généralement propriétaires et/ou protégées par des réglementations IP prohibitives. Par exemple, la vision uProtocol bénéficierait énormément d'une intégration étroite avec l'infrastructure de communication AUTOSAR® telle que SOME/IP, qui représente une partie importante de la communauté de communication orientée services dans le monde automobile embarqué. Les politiques de propriété intellectuelle associées à ces spécifications font de la publication d'implémentations open source une entreprise difficile et chronophage. Une telle tentative est actuellement menée par le projet Eclipse SommR. Nous vous en dirons plus sur ce projet dans notre prochain article de blog.
« La collaboration au-delà des frontières est le meilleur moyen de sortir du jeu habituel des entreprises, où tout le monde est perdant. »
1: Bien sûr, ces deux dimensions s'influencent mutuellement : les contraintes du média déterminent la manière dont les messages sont formulés et utilisés, tandis que les exigences des messages déterminent quel média sera utile.
2: Les ingénieurs en informatique adhèrent pleinement à la théorie de McLuhan selon laquelle « le médium est le message », qui suggère que « [...] c'est le moyen de communication lui-même, et non les messages qu'il véhicule, qui doit être au centre de l'étude ».
3: Même si nous ne l'appelions pas encore « le cloud » à l'époque.
4: « Durable » étant ici le mot clé. On peut viser à créer le produit parfait pour un court instant, mais cet exploit doit être reproduit pour 10 autres gammes de produits en parallèle, puis répété pour toutes ces gammes pendant deux ans, jusqu'à la sortie du produit de nouvelle génération. Et ensuite, toute cette diversité doit être maintenue pendant plus de 10 ans d'exploitation, avec potentiellement plusieurs millions d'unités vendues...
5: C'est pourquoi nous avons autant de normes.
6: Avec une telle portée, il devrait être clair que uProtocol ne cherche pas à être la réponse à tous les cas d'utilisation spécialisés qui se présentent en cours de route. Certaines choses (par exemple, les communications critiques en temps réel au sein d'un sous-domaine d'un véhicule) sont mieux résolues avec des approches existantes, spécialisées et localisées.
Contactez-nous
Vous avez besoin de plus d'informations sur un produit ou un service spécifique ? Ou d'une réponse personnalisée à votre question ?
Nos commerciaux sont prêts à vous aider.