Virtualisation des ECU : parcours

La plupart des ECU respectent une architecture bien définie (voir Figure 1) établie par AUTOSAR, qui est une architecture logicielle standardisée développée en collaboration par les constructeurs automobiles, les fournisseurs et d’autres parties prenantes. Elle fournit une plate-forme commune pour le développement, l’intégration et la gestion de logiciels dans les véhicules modernes. AUTOSAR vise à répondre à la complexité croissante des systèmes électroniques automobiles en définissant un cadre standardisé pour l’architecture logicielle, les interfaces d’application et les protocoles de communication.

Cette approche ouverte et standardisée permet à différents composants logiciels automobiles de divers fournisseurs de fonctionner ensemble de manière fluide, ce qui favorise l’interopérabilité et l’évolutivité. AUTOSAR favorise la réutilisation des modules logiciels, facilitant ainsi le développement et la maintenance des logiciels par les constructeurs automobiles sur différents modèles de véhicules et unités de commande électroniques. Cela se traduit par des processus de développement plus efficaces, des délais de mise sur le marché réduits et une fiabilité globale du système améliorée dans l’industrie automobile.

^{Figure 1 : Architecture de couche ECU AUTOSAR}

Comme illustré dans la Figure 1, l’architecture AUTOSAR se compose de quatre couches conférant des capacités à une ECU. L’utilisation de cette architecture dans la simulation d’ECU facilite la validation précoce des fonctionnalités, éliminant la nécessité d’attendre l’ECU physique, ce qui accélère le processus de test.

Pour mieux comprendre l’objectif de chaque couche, explorons les tâches principales de chacune des quatre couches de l’architecture de la plate-forme AUTOSAR Classic.

1. Couche d’application :
   • Implémente le code d’application de niveau principal.
   • Organise les composants logiciels (SWC) pour des fonctionnalités distinctes au besoin.
   • Implémente des interfaces standardisées associées aux SWC pour développer des applications automobiles.
   • Facilite la communication entre les composants via des ports bien définis, permettant l’interaction avec la couche logicielle de base AUTOSAR.
   • Déclenche l’exécution cyclique ou événementielle de l’implémentation réelle dans les SWC, impliquant des entités exécutables telles que la réception de données.
2. Couche d’environnement d’exécution :
   • Agit comme une couche de middleware.
   • Fournit des services de communication pour les composants logiciels AUTOSAR et les applications avec des pièces de capteur/d’actionneur AUTOSAR.
   • Rend les SWC indépendants des mappages d’ECU spécifiques.
   • Spécialisations pour chaque ECU et application.
   • Garantit l’autonomie des composants logiciels AUTOSAR, favorisant la flexibilité et la portabilité.
3. Couche de configuration du logiciel de base (BSW) :
   • Couche d’abstraction ECU :
     1. S’interface avec la couche d’abstraction de microcontrôleur (MCAL) pour l’accès périphérique.
     2. Établit une API pour l’interaction MCU (unité de microcontrôleur), garantissant l’indépendance du matériel ECU.
     3. Indépendance d’installation vis-à-vis de la MCU tout en s’appuyant sur le matériel ECU.
   • Drivers complexes :
     1. Gère des fonctions complexes (par exemple, contrôle d’injection).
     2. Accède directement à la MCU pour répondre à des exigences de cadencement spécifiques.
     3. Installe une interface standardisée conformément aux directives AUTOSAR.
   • Couche d’abstraction de microcontrôleur :
     1. Accède directement aux périphériques MCU sur puce et aux périphériques externes.
     2. Garantit une indépendance logicielle supérieure par rapport aux spécifications de la MCU.
     3. Établit une interface non affectée par les spécifications MCU standardisées.
4. Couche de microcontrôleur :
   • Agit comme une interface permettant la communication entre les couches logicielles et les périphériques matériels du microcontrôleur.

En explorant ces couches plus en détail, il devient évident que la couche d’application joue un rôle central en encapsulant les fonctionnalités de base de l’ECU. En tirant parti du code de cette couche, nous pouvons simuler notre vECU avec précision.

Pour obtenir une simulation précise d’une vECU, il est essentiel d’adopter une approche structurée (voir Figure 2). Par conséquent, en effectuant les étapes clés suivantes, nous pouvons atteindre notre objectif.

1. Modélisation d’applications : commencez par créer un modèle complet qui représente avec fidélité les capacités de l’ECU à l’aide des logiciels MathWorks® MATLAB® et Simulink®.
2. Création de l’application : établissez un mappage précis des multiples signaux d’E/S présents dans l’ECU avec les composants AUTOSAR. Ce mappage peut être réalisé à l’aide d’outils tels que les logiciels MATLAB, Simulink ou ISOLAR-A*.
3. Configuration logicielle de base : reproduisez les composants logiciels de base essentiels qui régissent le fonctionnement de l’ECU. Cette tâche peut être accomplie à l’aide d’ISOLAR-B*.
4. Construction d’ECU virtuelle : lancez le processus de virtualisation de l’ECU à l’aide d’un fichier de configuration avec le logiciel Synopsys, dénommé Silver.
5. Simulation d’ECU virtuelle : utilisez le logiciel NI VeriStand, associé à la plate-forme de test temps réel NI HIL, qui crée une simulation efficace compte tenu de la capacité de reconfiguration de ses ports d’E/S en fonction du type de signal souhaité. Cette capacité permet de simuler la vECU de manière alignée sur des spécifications client précises. La transition fluide entre diverses vECU est réalisée en cliquant sur un bouton permettant aux utilisateurs de passer d’une ECU simulée à une autre.

^* ISOLAR-A et ISOLAR-B font référence aux outils logiciels proposés par ETAS pour le développement de logiciels embarqués dans les ECU automobiles. Ils permettent de créer des logiciels conformes AUTOSAR en normalisant les architectures pour bénéficier d’une évolutivité et d’une interopérabilité améliorées. Pour en savoir plus, consultez la documentation ETAS officielle ou contactez directement l’organisation.

La représentation visuelle suivante résume le processus recommandé pour la virtualisation des ECU. Afin de vous guider à chaque étape, nous avons mis en évidence les outils recommandés par NI en gras. En outre, chaque étape répertorie d’autres outils populaires que vous pouvez envisager d’utiliser pour les processus respectifs. Cette approche structurée vise à améliorer la clarté et à permettre la prise de décisions éclairées lors de la mise en œuvre de la virtualisation des ECU.

^{Figure 2 : Processus de validation virtuelle}

Par conséquent, en suivant ces étapes bien définies, nous pouvons simuler efficacement le comportement de n’importe quelle ECU de véhicule, en offrant un puissant outil pour le développement et les tests automobiles, tout en gagnant du temps et en allant de l’avant dans le processus de test.

• Développement de systèmes HIL automobiles flexibles
• Explorez la technologie HIL et le test de logiciels embarqués

[1] https://www.synopsys.com/verification/virtual-prototyping/silver.html

[2] https://www.autosar.org/standards/classic-platform