Pourquoi l'informatique automobile est-elle si chère ?

Même si on a trop souvent tendance à l’oublier : d'un point de vue historique, l’auto est un produit matériel. Pendant longtemps, les innovations ont souvent exclusivement porté sur la technologie des matériaux, les éléments mécaniques et le système de transmission.

Traditionnellement, lorsque différents systèmes de commande étaient installés dans un véhicule, ces unités fonctionnaient dans un premier temps de manière indépendante. La commande moteur, l’ABS ou le système de commande de l’airbag utilisaient des informations issues de différents capteurs et ces dispositifs exécutaient leurs tâches de manière indépendante. On a toutefois assisté à une évolution fondamentale ces dernières années : le développement de véhicules connectés et automatisés impose que les systèmes présents dans le véhicule échangent des informations et fonctionnent ensemble comme un système cohérent.

Les structures dans l’industrie automobile et les équipementiers classiques ont connu elles aussi une évolution historique. Les systèmes de commande sont traditionnellement du ressort des différents départements – chacun d’entre eux ayant sa propre conception des processus de développement, des contraintes fonctionnelles, des interfaces et d’autres caractéristiques. Mais la complexité de l’architecture des systèmes de commande et des logiciels ne cesse de croître. Plus les composants sont interconnectés plus l’intégration et les tests exigent des efforts importants. Par ailleurs, le rythme des innovations tend à suivre celui de l’électronique de divertissement. Tout ceci impose aux matériels et aux logiciels de nouvelles contraintes dès le processus de développement qui s’étend sur plusieurs années.

L’idéal et la réalité

La situation est la suivante : prenons le cas d’une fonction présente dans un véhicule de génération X, avec un éventail de 100 fonctions logicielles. Dans la génération suivante X+1 du véhicule, l’éventail de fonctions passe à 120 fonctionnalités grâce à différentes innovations. Sur les 100 fonctions logicielles, seule une partie des 20 fonctionnalités supplémentaires doit être adaptée et le reste peut être intégré tel quel. Si l'on considère, en simplifiant, qu’en moyenne toutes les fonctionnalités exigent un effort de développement comparable, cela revient à dire que les perfectionnements apportés à un paquet logiciel augmentent d'un tiers environ l’effort de développement nécessaire pour passer d'une génération de véhicule à l’autre.

Mais la réalité est très différente. L’expérience du projet montre qu’en passant d'une génération de véhicule à l’autre, l’effort de développement et d’adaptation est tout aussi important que l’effort de développement global de la génération précédente. Les données typiques des projets montrent que lors d’un changement de génération, près de 40% de cet effort de développement est mobilisé pour de nouvelles fonctions et demandes de modifications. L’essentiel des 60% correspond à la maintenance des fonctions existantes ainsi qu’à l’intégration et aux tests conduits pendant toute la durée du développement jusqu’à la mise en production. Par ailleurs, toutes les nouvelles fonctionnalités et demandes de modification ne portent pas forcément sur des fonctions observables par les clients. Ceci signifie que le client ne perçoit qu’une infime partie de l’effort de développement comme une amélioration sensible dans le véhicule. L’effort important pour le suivi du logiciel présent mobilise des capacités qui pourraient être investies autrement dans le développement des innovations.

Le défi de la richesse des variantes

Cet écart est dû selon nous à deux facteurs. Le premier défi concerne le nombre élevé de variantes fonctionnelles auxquelles un composant logiciel doit satisfaire. Différents constructeurs automobiles demandent pour la même fonction des implémentations et des interfaces différentes. Ceci oblige à adapter et à tester sans cesse un produit logiciel aux niveaux fonctionnel et applicatif. Dans les cas d’applications de navigation par exemple, les contraintes des constructeurs automobiles sont très proches. Il peut toutefois y avoir de nettes différences au niveau des détails d’implémentation. Ceci oblige à modifier les modules logiciels existants ou à adapter les fonctionnalités des différents constructeurs à l’aide de variantes dans le code source. Au lieu d’un développement agile consistant à réutiliser des composants logiciels éprouvés, le logiciel connaît dans les faits un développement multiple. Cette approche est peu performante et peut par ailleurs dégrader la qualité, en donnant lieu à un nombre difficilement gérable de variantes de la fonction de base, qui remplissent finalement la même fonction.

Cette profusion de variantes complexifie encore plus les systèmes logiciels actuellement présents dans l’automobile. Chaque fois qu’un module est ajouté  et qu’une interface est modifiée, l’effort associé à l’intégration et aux tests augmente, sans parler de l’effort financier.

Variantes matérielles et de plates-formes

Le deuxième point concerne le nombre important de variantes matérielles et de plates-formes chez les différents constructeurs automobiles. Le nombre de variantes de configuration compte tenu des différents types de carrosseries et ensembles motopropulseurs, variantes d’habitacle et fonctions de confort et d’assistance a considérablement augmenté. Ce nombre est lui-même multiplié par les variantes liées aux marques et aux régions. Les constructeurs automobiles s’efforcent de limiter cette diversité en mettant en œuvre des stratégies de plate-forme et des concepts modulaires. Ils déploient par exemple des systèmes de commande conçus pour plusieurs modèles de véhicules et réutilisent une part sensiblement plus élevée de matériels et de logiciels pour les éléments présents dans un système modulaire. La conséquence est que les logiciels de ces systèmes modulaires doivent maîtriser cette multiplicité de configurations de véhicules. Enfin, le logiciel assure la flexibilité des approches modulaires ou de plates-formes – grâce à des adaptations logicielles dans les différents systèmes de commande. En d’autres termes, la complexité des configurations de véhicules est déplacée vers le logiciel qui doit être en mesure de gérer les différentes variantes d’équipements. Ceci crée des variantes logicielles et contribue à une complexité accrue.

Associé au nombre élevé, précédemment évoqué, de variantes fonctionnelles dans toutes les autres aspects du véhicule, ceci crée une charge excessive pour l’intégration et les tests logiciels. Par ailleurs, cette charge ne concerne pas seulement la première mise en  production mais aussi toutes les mises en production des véhicules concernés.

Gestion active des variantes

Pour résoudre ces problèmes, plusieurs approches sont possibles. Un premier élément important concerne la volonté de renforcer la standardisation, par exemple dans le cadre d’organismes comme AUTOSAR, NDS ou VDA. Pour la standardisation logicielle indépendamment du constructeur, il est possible d’optimiser les potentiels de manière à permettre une réutilisation effective des logiciels. Un premier pas dans la bonne direction consiste à s’appuyer sur les standards existants comme AUTOSAR, la version AUTOSAR 4.0 étant nettement plus avancée en termes de standardisation indépendamment du constructeur. En la matière, il appartient aux constructeurs automobiles et aux éditeurs de logiciels de renforcer la standardisation réelle afin de pouvoir bénéficier pleinement des effets d’échelle dans le développement logiciel, y compris entre plusieurs constructeurs. Ceci est d’autant plus important que les mises à jour des logiciels automobiles doivent de plus en plus être réalisées indépendamment du cycle de vie logiciel afin de déployer de nouvelles fonctionnalités ou de faire face à l’évolution des menaces en matière de sécurité. La complexité des logiciels deviendra à terme ingérable sans une standardisation effective.

La localisation des variantes dans l’architecture logicielle constitue un levier de réglage supplémentaire. La responsabilité en incombe aux éditeurs de logiciels. L’objectif du développement logiciel doit être de devoir gérer des variantes que dans un minimum d’endroits du logiciel, par exemple dans les couches matérielles ou d’abstraction et de les exclure d’autres domaines tels que le logiciel fonctionnel. Ceci permet d’utiliser des composants logiciels standardisés de manière modulaire sur différentes plates-formes matérielles et de les réutiliser dans différentes combinaisons. Ceci réduit par ailleurs sensiblement le nombre de combinaisons possibles et, à cette occasion, la charge d'intégration et de test tout en améliorant la qualité du produit. Dans le cadre du développement d’AUTOSAR 4.0, nous avons défini de manière conséquente une architecture dans le logiciel de base et a implémenté les variantes à l’extérieur du logiciel de base.

Une autre approche afin de maîtriser la complexité des logiciels et d’améliorer la flexibilité du développement consiste à faire appel à des méthodes de développement agiles éprouvées issues de l’informatique classique, comme Scrum ou production. Elles autorisent des processus de développement plus légers et permettent de travailler de manière plus ciblée. L’optimisation du processus doit toutefois être précédée par une remise à plat des prérequis : Quelle doit être l’ampleur des nouveaux développements logiciels dans un projet de véhicule ? Ces méthodes ne permettent pas de réduire la complexité inhérente aux logiciels mais permettent d’améliorer l’efficacité des procédures de développement.

La valeur logicielle

En choisissant des systèmes embarqués, il importe de considérer le coût total de possession (TCO). Dans l’industrie automobile, on continue souvent à se focaliser sur les prix des pièces (Bill of Materials, BoM) sans tenir compte des coûts associés au développement logiciel. Ainsi, un client  a décidé t de remplacer un micro-contrôleur dans un système de commande pour économiser un euro de coûts matériels par pièce. Ce montant est certes à considérer lorsqu’il s’agit de produire 8 millions de systèmes de commande. Le client n’a toutefois pas pris en compte dans le calcul le fait que le remplacement de la puce entraînerait au moins 10 millions d’euros de coûts liés à l’adaptation et au développement d’un nouveau logiciel. L’évaluation des coûts de développement sur la base du BoM est pertinente principalement lorsque le coût des composants est à prendre en compte. Mais cette logique ne s’applique plus lorsque la part du logiciel représente l’essentiel des coûts de développement.

La question est donc de savoir si l’optimisation du prix des systèmes de commande sur le prix unitaire du matériel a encore de l’avenir. À une époque où le logiciel est un facteur déterminant de l’expérience de conduite dans pratiquement tous les domaines, nous – à savoir l’industrie automobile dans son ensemble– devons remettre en question nos principes de calcul et les structurer en fonction de l’importance du logiciel.

Nous sommes tous conscients de la place incontournable que prendra le logiciel pour la mobilité de demain et, par conséquent, pour nos modèles économiques. La plupart des innovations sont désormais réalisées dans le domaine de l’électronique et du logiciel. La maîtrise de la complexité dans le développement logiciel est la condition préalable pour que nous puissions continuer à profiter demain de cette capacité d’innovation. La réalisation de cet objectif passe par une mise en commun de nos efforts.