Étude de cas Tata Elxsi : virtualisation des calculateurs pour les tests SIL automatisés
Réduisez la durée des essais des calculateurs de 10 jours à moins de 8 heures grâce aux essais SIL automatisés
Le client
Tata Elxsi figure parmi les principaux prestataires mondiaux de services de conception et de technologie dans divers secteurs, notamment l’automobile, l’audiovisuel, les communications, la santé et les transports. Tata Elxsi collabore avec les principaux constructeurs et fournisseurs des secteurs de l’automobile et des transports pour leur fournir des services de R&D, de conception, d’intelligence artificielle générative (GenAI) et d’ingénierie produit, depuis la conception jusqu’au lancement et au-delà. L’entreprise rassemble une expertise dans les domaines des technologies des véhicules autonomes, électriques et connectés, ainsi que des véhicules définis par logiciel (SDV), s’appuyant sur un réseau mondial de studios de conception, de centres de développement et d’un vivier international de plus de 11 000 ingénieurs et spécialistes.
Le défi
Permettez la réalisation de tests dans un environnement « Software-in-the-Loop » (SiL) en virtualisant un calculateur AUTOSAR, en simulant des composants externes et en transformant les procédures de test manuelles en cas de test automatisés et exécutables.
Les essais traditionnels de type « Hardware-in-the-Loop » (HiL) nécessitent des bancs d’essai physiques et un travail manuel. Les essais de type « Software-in-the-Loop » (SiL) réduisent cette dépendance en exécutant le logiciel de l’ECU dans un environnement virtuel, ce qui élimine le besoin de matériel et permet des essais évolutifs.
Une exigence essentielle est que l’ECU virtuelle (vECU) exécute le même logiciel que l’ECU de série. Si le logiciel diffère, les essais devront être répétés sur du matériel, ce qui réduit l’intérêt de la virtualisation. Il est essentiel de maintenir un comportement et des interfaces identiques.
Dans ce cas d’utilisation cible, l’ECU traite les signaux d’entrée provenant de commandes physiques pour diverses fonctions d’application. L’ECU communique avec des périphériques via des interfaces série telles que I²C, tandis que l’échange de données avec d’autres ECU du véhicule s’effectue via le réseau CAN.
Un autre défi concerne les scénarios de mise en veille et de réveil. L’ECU peut se trouver en mode veille ou être hors tension. Lorsqu’une trame de gestion du réseau arrive via le réseau CAN ou qu’un signal GPIO est reçu d’un périphérique, l’ECU doit se réveiller ou s’allumer. L’application doit identifier la source du réveil et effectuer les actions appropriées, telles qu’une séquence de démarrage spécifique et une vérification de l’état du système. Ces comportements doivent être modélisés et validés dans l’environnement virtuel.
Les signaux provenant des périphériques connectés et des interfaces série doivent également être simulés pour permettre une interaction complète avec le vECU. Les étapes de test manuelles doivent être converties en cas de test automatisés afin de soutenir l’Intégration continue (CI) et les tests de régression.
L’objectif est de réaliser des tests logiciels précoces sans matériel, en réduisant la charge de travail manuelle, tout en intégrant des tests automatisés dans un pipeline d’intégration continue (CI) et de tests continus (CT). Cette approche soutient l’accélération des cycles de développement et l’assurance d’une couverture de test cohérente.
La solution
Créez une vECU de niveau 3 à l'aide de pilotes MCAL virtuels et d'une simulation de bus basée sur CANoe afin de permettre la réalisation de tests complets au niveau de la qualification logicielle.
Pour permettre les tests SIL, unvECU1 de niveau 3 est créé à l’aide de vVIRTUALtarget. L’outil remplace le système d’exploitation et les pilotes MCAL par leurs équivalents virtuels. Les pilotes de périphériques complexes (CDD) ont été portés sur la plateforme virtuelle. Cette approche garantit que le même logiciel d’application s’exécute aussi bien sur l’ECU virtuelle que sur l’ECU réel, préservant ainsi l’équivalence fonctionnelle entre les environnements.
L’approche de virtualisation inclut le pilote de l’émetteur-récepteur CAN. Cela permet une simulation précise du réseau, y compris la transmission et la réception de messages CAN ainsi que la gestion des trames de gestion du réseau, même lorsque le vECU est en mode veille ou hors tension. Un émetteur-récepteur réseau virtuel surveille le trafic CAN. Il peut déclencher des transitions de réveil ou de mise sous tension en activant l’alimentation virtuelle ou en déclenchant une interruption de réveil via le GPIO, reproduisant ainsi le comportement de la configuration physique.
Les scripts CAPL simulent des périphériques au sein d’une configuration CANoe. Les variables système CANoe permettent de stimuler l’ECU virtuelle à l’aide de signaux analogiques et numériques, ce qui facilite l’interaction avec des boutons, des commutateurs et d’autres entrées. Les interfaces de communication série telles que I²C sont également émulées via ce mécanisme, garantissant ainsi une couverture complète des scénarios de communication. Cette configuration crée un environnement réaliste dans lequel l’ECU virtuelle peut interagir avec des périphériques et des réseaux externes simulés, comme s’il fonctionnait au sein d’un système physique.
Les procédures de test manuelles ont été converties en cas de test automatisés, exécutés via CANoe et gérés à l’aide de vTESTstudio. Cela constitue la base de l’Intégration continue (CI) et des tests continus (CI/CT) au sein de pipelines basés sur serveur, par exemple avec les CANoe Server Editions.
En virtualisant les pilotes, les composants matériels et les interactions avec les périphériques, cette solution offre un environnement de test entièrement virtualisé qui reproduit le comportement du matériel, soutient la validation précoce des logiciels et s’intègre de manière transparente dans les flux de travail automatisés. Elle permet de tester rapidement les logiciels intégrés sans recourir au matériel réel, ce qui facilite la réalisation de nouveaux tests et de tests de régression efficaces après les corrections de bugs et la mise en œuvre de demandes de modification.
Les avantages
La mise en place précoce des tests, la réutilisation des logiciels et l'automatisation permettent d'accélérer la mise à disposition, d'améliorer la qualité et de limiter les risques dès les premières étapes.
- La durée des tests a été considérablement réduite, passant de 10 jours à moins de 8 heures
- Les tests manuels ont été remplacés par des scénarios automatisés, ce qui rend le développement agile et adapté aux véhicules définis par logiciel (SDV)
- Les tests et le débogage en boucle fermée sont possibles sans avoir besoin d’un système matériel réel
- Le même logiciel d’application et le BSW AUTOSAR s’exécutent aussi bien sur les cibles vECU que réelles
- Les environnements virtuels permettent une exécution en parallèle et une évolutivité aisée
- L’approche « Shift-Left » permet une validation plus précoce dans le cycle de développement, réduisant ainsi les défauts en fin de cycle et les problèmes d’intégration
