Dans un entretien exclusif accordé à L’Embarqué, Bruno Abou, vice-président, directeur des ventes Europe et directeur général France d’Elektrobit (EB), et Guillaume Cordon, expert senior Architecture système pour cette société spécialiste des solutions matérielles et logicielles pour l’industrie automobile, donnent leur vision de l’évolution en cours vers le véhicule défini par logiciel et apportent un éclairage particulier sur les nouvelles ambitions d'Elektrobit dans l’Hexagone.

Dans l’industrie automobile, on évoque régulièrement les véhicules connectés, mais aussi les véhicules autonomes et, de plus en plus, les véhicules définis par logiciel ou SDV (Software Defined Vehicle). Comment la société Elektrobit, en tant qu’éditeur de briques logicielles et d’outils de développement présent depuis longtemps sur le marché automobile, perçoit-elle cette évolution ?

GUILLAUME CORDON Par le passé, dans la phase de conception classique d’un véhicule, il était de règle d’associer une fonction à une "boîte", et c’est un équipementier automobile qui était chargé de réaliser le tout, matériel et logiciel compris. Aujourd’hui, il y a une nouvelle dynamique en cours où l’on pense d’abord à des fonctions logicielles sans que l’on sache en pratique sur quelles architectures matérielles elles vont venir s’accoster au final, l’idée sous-jacente étant toutefois de profiter de l’arrivée de processeurs de plus en plus puissants. A l’instar, pour schématiser, de ce qu’a pu connaître l’industrie des smartphones il y a quelques années.

Cette dichotomie entre logiciel et matériel conduit à une architecture flexible et évolutive dont l’avantage est de permettre de développer et d’intégrer de nouvelles fonctions à un rythme toujours plus rapide, et ce tout au long du cycle de vie du véhicule, éventuellement en temps réel.

Cette évolution a forcément des conséquences sur l’architecture du véhicule…

GUILLAUME CORDON Oui, puisque les dizaines de calculateurs tous focalisés sur une fonction unique, comme l’éclairage, les essuie-glace, etc. sont amenés à disparaître. On revient donc vers des architectures centralisées avec, d’un côté, un ou plusieurs calculateurs centraux, ou Performance Controllers, dotés d’une très forte puissance de calcul et destinés à traiter des volumes très importants de données, et, de l’autre, des contrôleurs de zone, ou Zonal Controllers, qui embarquent les nouvelles fonctions logicielles et qui ont vocation à interconnecter ces gros contrôleurs centraux (au nombre de trois à cinq par véhicule) avec le reste du véhicule comme les capteurs, les actionneurs, etc.

Le tout évidemment doit s’accompagner d’une méthodologie pour définir le véhicule avec de nouvelles plates-formes de développement, des SDK, des API à respecter et d’un environnement et orchestrateur logiciel parfois dénommé Car OS ou Automotive OS qui permet l’ajout de nouvelles fonctions dans la voiture, indépendamment de l’architecture matérielle.

Dans l’évolution vers le véhicule défini par logiciel, existe-t-il des contraintes qu’il faut absolument respecter ?

GUILLAUME CORDON Il y a effectivement trois points importants que doivent prendre en compte tous les intervenants impliqués dans le développement des véhicules définis par logiciel. Tout d’abord, c’est la capacité à extraire la complexité de l’architecture E/E (électrique et électronique) d’une automobile pour en faire une seule structure homogène. Ensuite, il faut des mécanismes de supervision et de gestion de l’Automotive OS (avec en standard des fonctionnalités de mise à jour). Enfin l’existence d’un écosystème qui permette aux développeurs de s’exprimer est absolument crucial.

En corolaire, c’est un virage à 90° pour la chaîne d’approvisionnement qui s’annonce. Il n’y aura plus de pièces mécaniques liées à une fonction particulière (airbag, lève-vitre…) comme il est d’usage dans une organisation horizontale. On va passer à une organisation verticale avec une nette séparation des plates-formes logicielles et matérielles. Ce qui va permettre de disposer de fonctions plus rapidement, de répondre au besoin constant d’innovations et de réduire le temps de mise sur le marché.

Aujourd’hui il n’est plus concevable de patienter deux ans pour voir l’arrivée d’une nouvelle fonction logicielle, aussi bien chez les constructeurs historiques que chez les utilisateurs. Il faut désormais innover rapidement, disposer de la meilleure fonction avant les autres.

Ce mouvement s’accompagne-t-il chez les constructeurs automobiles de la volonté de disposer en interne d’une activité logicielle ?

GUILLAUME CORDON C’est évident parce qu’au moment où le logiciel devient prépondérant, il n’est plus question pour eux de payer pour les lignes de code de chaque pièce automobile. La vague a été lancée par Tesla en tant que nouvel acteur sur le marché automobile. Un constructeur historique comme Volkswagen a même créé en 2020 avec Cariad une filiale entièrement focalisée sur le logiciel avec l’ambition de créer une plate-forme logicielle unifiée et échelonnable pour les modèles de véhicules du groupe et bénéficiant d’un accès à tous les domaines du véhicule. Sous le nom de VW.OS, elle pourrait être mise en œuvre à partir de 2025. La stratégie est similaire chez Mercedes avec MB.OS qui sera introduit vers le milieu de la décennie.

Tous les constructeurs n’ont pas toutefois cette même ambition car il est particulièrement difficile de changer de stratégie en un jour lorsqu’on dispose d’une base solide de clients. Mais en fait le véritable nerf de la guerre, c’est la définition d’une API qui va permettre d’abstraire vis-à-vis du logiciel la complexité de l’architecture matérielle d’une automobile, car il est évident que certains constructeurs ne voudront pas payer des royalties sur des plates-formes logicielles fournies par des concurrents.

Sur cette API, que l’on peut dénommer Vehicle API et qui devra être beaucoup plus complète que ce que proposent les standards Autosar par exemple (qui se situent à un niveau inférieur), seront portés tous les services applicatifs (diagnostics, détection d’intrusions…). Or aujourd’hui chaque constructeur veut la sienne, à l’instar d’un Renault notamment qui a d’ores et déjà porté son choix sur l’environnement Google. Et l’on a vu fleurir une dizaine d’initiatives industrielles visant à spécifier cette API dont plusieurs open source comme Covesa, Eclipse SDV ou Soafee. A l’instar de ce qu’a connu le marché de la téléphonie mobile où il n’existe en gros plus que trois acteurs - iOS, Android et Huawei - tout le monde ne survivra pas. En Europe, on peut supposer qu’à terme il ne restera que deux Vehicle API sur le marché dont l’une open source.

Quant aux équipementiers et aux fournisseurs de rang deux – comme les éditeurs de logiciels présents depuis de nombreuses années sur le marché automobile –, ils doivent s’adapter sans toutefois devancer la cadence au risque de ne pas trouver leur marché… D’autant qu’il leur faut à la fois satisfaire les acteurs historiques et les nouveaux acteurs !

Comment un éditeur de logiciels pour l’automobile comme Elektrobit peut-il justement se positionner face à ces évolutions ?

BRUNO ABOU Pour une société comme Elektrobit, la stratégie est de se focaliser sur du logiciel moins différentiateur comme le système d’exploitation temps réel où nous disposons d’un réel savoir-faire avec en particulier la mise à disponibilité il y a une dizaine d’années des premiers OS compatibles Autosar certifiés au niveau Asil-D vis-à-vis de la sûreté de fonctionnement pour les architectures monocœurs et multicœurs. C’est là que réside notre valeur ajoutée que nous complétons avec du middleware Autosar Classic ou Autosar Adaptive, des environnements Linux, voire un environnement Android pour l’infodivertissement. Certaines fonctions différenciantes et essentielles comme les mises à jour over-the-air sont aussi au nombre des compétences qu’Elektrobit maîtrise.

Notre objectif est de continuer à renforcer nos compétences sur le bas niveau, sur les services qui vont autour, ainsi que sur les outils de développement associés. L’environnement de développement, qui aujourd’hui a tendance à migrer vers le cloud, est d'ailleurs un axe majeur à la fois pour Elektrobit et sa maison-mère l’équipementier Continental. L’une des dernières annonces en ce sens est l’intégration de certains des produits logiciels d’Elektrobit au sein du framework CAEdge de Continental. CAEdge fournit un environnement de développement pour les architectures de véhicule à très forte composante logicielle qui permet aux constructeurs automobiles et à leurs partenaires de collaborer plus efficacement pour développer et tester des logiciels dans le cloud, puis les déployer en toute sécurité directement dans les véhicules.

Que représente aujourd’hui la société Elektrobit en France ?

BRUNO ABOU Elektrobit est présent en France depuis 2008 et compte une centaine de personnes réparties entre Carrières-sur-Seine, dans la banlieue parisienne, et Toulouse. Les premières équipes sont arrivées sur Toulouse en 2021 dans le cadre d’un accord avec Continental, mais depuis la fin de l’année dernière, Elektrobit dispose de ses propres bureaux dans la capitale occitane.

L’une des raisons principales de notre présence à Toulouse est la volonté de bâtir une relation encore plus forte avec Continental, là où le groupe mène des activités de recherche et développement et où se trouve le siège France de Continental Automotive. A ce titre, il faut rappeler que Continental dispose de trois grands départements Software focalisés respectivement sur les briques logicielles pour les contrôleurs automobiles ECU (un domaine de compétence de Toulouse), sur les plateformes logicielles intéressant l’ensemble des activités de Continental, et sur les plates-formes et services eHorizon, qui permettent aux véhicules connectés de "voir" au-delà de leurs propres capteurs de vision.

A l’heure actuelle, Elektrobit compte une trentaine de personnes sur Toulouse impliquées sur des projets en cours avec Continental (dont l’un pour Renault Software Labs, qui en est dans sa troisième année) ainsi qu’avec des constructeurs automobiles, dont il n’est pas possible de parler aujourd’hui. L’autre raison de la présence d’Elektrobit sur Toulouse est de profiter de la présence d’industriels locaux pour étendre nos activités vers d’autres domaines verticaux relativement nouveaux pour nous comme l’aéronautique…

Propos reccueillis par Pierrick Arlot

Vous pouvez aussi suivre nos actualités sur la vitrine LinkedIN de L'Embarqué consacrée au marché automobile : Embedded-Automotive