PASSER À L’ARCHITECTURE E/E ZONALE >> GuardKnox

Avec la croissance continue de la complexité des systèmes électriques/électroniques (E/E) dans les véhicules d’aujourd’hui, on continue de constater une croissance des coûts de conception, d’assistance et de fabrication qui peut être résolue en observant une voie de transition vers une architecture E/E zonale. Un tel changement n’a pas besoin de s’opérer du jour au lendemain, mais peut consister en une évolution au fil du temps à mesure que de nouveaux modèles et fonctionnalités sont ajoutés à la gamme de véhicules d’une marque et que de nouvelles tendances du marché émergent.

Le blog et l’illustration ci-dessous sont une représentation logique du réseau E/E à l’intérieur de la voiture et non une représentation de la disposition physique.

Figure 1:Le chemin de transition évolutif vers l’architecture E/E zonale

L’architecture actuelle la plus couramment utilisée dans les véhicules est souvent appelée « architecture de passerelle centrale » comme le montre la figure 2:

Figure 2:Architecture de passerelle centrale - schéma logique

Dans cette architecture, il arrive souvent qu’un périphérique de passerelle se connecte à de nombreux sous-réseaux, et chaque fonction nécessite ses propres processeurs. Cela implique plus de 150 livres de cuivre pour tout connecter ensemble. Dans la figure 3 ci-dessous, vous pouvez voir le faisceau de câblage typique nécessaire pour connecter l’ensemble des ECU et des capteurs.

Figure 3: Faisceau de câblage typique - Crédit : link.springer.com

Le passage à une architecture E/E zonale (Zonal Architecture) est motivé par les avantages évidents qu’elle offre en termes de consolidation matérielle, de modularité et de réutilisation du matériel et des logiciels, de simplification de la maintenance logicielle et matérielle, de certification et de réduction des coûts globaux.

Dans une transition évolutive vers une architecture E/E zonale, chaque étape apportera des avantages immédiats en termes de réduction des coûts et de différenciation des produits.

La première étape peut être une simple inclusion de quelques contrôleurs de domaine et d’un contrôleur de domaine de passerelle central pour effectuer le gros du travail du contrôle de véhicule. Les contrôleurs de domaine géreront les différents sous-réseaux de domaine et consolideront les fonctions de certaines ECU, contribuant ainsi à les consolider et les simplifier, comme le montre la figure 4.

Figure 4 : Architecture de contrôleur de domaine - schéma logique

À l’étape suivante de l’évolution, un serveur de véhicule sera mis en place pour exécuter des fonctions informatiques centrales plus sophistiquées, comme le montre la figure 5 ci-dessous. Le serveur de véhicule sera un ordinateur multi-rôles, brouillant efficacement les domaines en les décomposant davantage en modules logiciels individuels. Au fil du temps, un plus grand nombre de fonctions pourra être déplacé des contrôleurs de domaine vers le serveur de véhicule, ce qui réduira encore le matériel physique et le câblage tout en augmentant les fonctionnalités. Le choix de contrôler une fonction à partir d’un contrôleur de domaine ou d’un serveur central sera influencé par le cycle de développement de la plateforme E/E du véhicule et peut suivre différents chemins d’évolution. Pour en savoir plus, regardez notre webinaire sur la transition vers l’architecture E/E zonale.

Figure 5 : Architecture zonale - distribuée - schéma logique

Une fois qu’une fonction est contrôlée par le serveur de véhicule, elle peut être facilement transférée à d’autres véhicules de la marque ou de marques associées ainsi qu’au modèle suivant, car il ne s’agit que de modules logiciels. Cela permet de réduire le temps de développement tout en améliorant la fiabilité et la qualité. L’ajout de fonctionnalités logicielles à un modèle de véhicule, pour créer une différenciation de modèle, ne sera plus un exercice de réaménagement majeur, mais un simple changement de logiciel dans une conception E/E commune ; quant à l’ajout de fonctionnalités, il sera plus facile grâce aux mises à niveau du firmware, y compris en post-production. 

Dans l’étape suivante d’une architecture E/E zonale, les marques peuvent aller jusqu’à consolider tous leurs logiciels en un seul serveur de véhicule central, comme le montre la figure 6.

Figure 6 : Architecture zonale - consolidée - schéma logique

À ce stade consolidé, un ou plusieurs serveurs de véhicule hébergeront le logiciel pour toutes les fonctions du véhicule, et se connecteront à quelques ECU qui feront office de passerelles zonales situées physiquement dans diverses zones du véhicule, comme le montre la figure 7. Les passerelles peuvent être connectées dans une architecture en anneau ou en étoile en fonction des exigences de résilience et de redondance. Cela réduira considérablement le coût de développement, de matériel et de câblage, tout en améliorant le temps et le coût de diagnostic et de maintenance.

Figure 7 : Architecture zonale - consolidée - disposition topologique

Cette « architecture zonale consolidée » est davantage futuriste que pratique à l’heure actuelle. Cependant, le travail de fond permettra d’y aboutir alors que la dépendance vis-à-vis du matériel disparaît. GuardKnox travaille avec les principales marques de constructeurs et leur fournit les étapes d’évolution en vue d’atteindre cet objectif visionnaire.
Quelle que soit la voie d’évolution retenue par un constructeur, chaque étape de cette évolution apportera des avantages en termes de portabilité de la fonction, de réduction du développement futur du modèle, de réduction du poids due à la réduction du câblage et de la satisfaction du client grâce à une fonctionnalité accrue aux commandes du conducteur.