Résumé

Les tests Software-in-the-Loop (SIL) font désormais partie intégrante du développement logiciel dans l’industrie automobile. En même temps, l'abréviation SIL couvre un très large éventail de sujets. Cet article de blog décrit ce que signifie la simulation SIL et quelles exigences et défis elle implique.

Tout d'abord, les tests SIL correspondent simplement à l'utilisation d'un logiciel - quel que soit son état - dans un environnement simulé afin de le mettre à l'épreuve, de vérifier les bits et les octets. Et c'est justement là que les subtilités commencent : Les tests d'un morceau de code C ou d'une fonction logicielle unique nécessite un environnement et des scénarios de test différents de ceux d'un réseau de calculateurs complet. Il est également nécessaire de faire la distinction entre les tests du logiciel avec une stimulation pure des interfaces (boucle ouverte) et l'intégration avec, par exemple, un modèle de comportement physique en boucle fermée (boucle fermée).

Système sous test - Du logiciel au calculateur virtuel

Le système sous test (SUT) est au centre de tous les tests, car c'est précisément le logiciel qui devra plus tard faire ses preuves sur un calculateur dans le monde réel. Les tests SIL se déroulent entièrement sans le matériel de l'ECU, ce qui présente de nombreux avantages, tels que la réduction des coûts, une évolutivité aisée dans le cloud, etc. Mais est-il possible de représenter des conditions de fonctionnement réalistes sans matériel ?

Contrairement aux calculateurs logiciels, qui fonctionnent avec des modèles Simulink®//Stateflow® simplifiés, les tests SIL utilisent des calculateurs virtuels (V-ECU) à cette fin. En général, un calculateur virtuel peut être n'importe quel type de logiciel de calculateur - d'une simple fonction au logiciel complet indépendant du matériel d'un calculateur. La grande différence avec les modèles simples est que les V-ECU sont basés sur un code de production réel. Les V-ECU peuvent également avoir différents niveaux d'abstraction, en fonction de l'endroit où ils sont utilisés. Dans l'industrie, la classification en cinq niveaux s'est imposée à des fins de caractérisation, qui sont brièvement décrites ci-dessous :

Cinq niveaux d'abstraction établis pour les V-ECU

Niveau 0

Dans le cas le plus simple, un modèle est disponible, par exemple, dans MATLAB/Simulink ou sous la forme d'une FMU (Functional Mock-up Unit). Cela signifie que seuls les tests de l'algorithme de contrôle de l'ECU sont possibles, puisque, par exemple, le logiciel de base ou le code de production de l'application de contrôle sont absents.

Niveau 1

Dans ce cas, le V-ECU contient le code de production original des applications individuelles jusqu'à la couche d'application complète d'un véritable calculateur. D'autres éléments, tels que les fonctions du logiciel de base (BSW), doivent être fournis par l'environnement de simulation ou un BSW simplifié pour la simulation doit être intégré dans le V-ECU.

Les V-ECU de niveau 1 fonctionnent au niveau du signal et permettent, par exemple, de tester des fonctions réparties sur différents composants.

Niveau 2

En étendant le V-ECU avec des parties du logiciel de base, qui est créé à des fins de simulation, les tests au niveau du bus et du réseau deviennent possibles. Le test est toujours axé sur la fonction du logiciel d'application, mais il est étendu à des fonctions telles que la surveillance du bus, les interfaces de diagnostic ou les modèles de messagerie véhicule (restbus).

Niveau 3

Un calculateur de niveau 3 V contient également le code de production du logiciel de base. Il peut être utilisé, par exemple, pour tester l'intégration logicielle d'un calculateur ou pour tester l'intégration de plusieurs calculateurs.

Niveau 4

Si le code de production a été compilé pour le matériel du calculateur ou s'il contient des dépendances matérielles, l'intégration d'une simulation au niveau des instructions matérielles est nécessaire.

Comment créer un V-ECU ?

En fonction du contexte du projet, les SUT ou les V-ECU existent déjà et doivent seulement être exécutés sur ou être couplés à la plateforme de simulation et d'intégration, par exemple, en tant que FMU, algorithme ROS ou même en tant qu'artefact V-ECU au format dSPACE. Il n'est donc pas nécessaire de créer votre propre V-ECU. Cependant, si seul le code est disponible, il doit être lié aux interfaces du simulateur et éventuellement complété par des fonctions pour la simulation. dSPACE offre des options pour le faire ; il s'agit de la création de V-ECU.

Il existe plusieurs façons de créer un V-ECU dans la chaîne d'outils dSPACE, en fonction du domaine d'application, des exigences du projet et du fait que le développement soit basé sur AUTOSAR ou non. Les développeurs de fonctions et de logiciels qui ne travaillent qu'avec des composants individuels peuvent créer un V-ECU directement avec Simulink ou TargetLink. Le résultat est un simple V-ECU (niveau 1) composé uniquement d'une partie sélectionnée de la couche d'application du logiciel de l'ECU. Il permet de mener des tests élémentaires sur fonction. De même, avec le SDK V-ECU, les fonctions C ou C++ peuvent être connectées directement à partir d'un environnement IDE aux interfaces du simulateur VEOS, puis déboguées pendant la simulation, également dans l'environnement IDE.

Dans notre exemple, où le logiciel doit être testé dans l'ensemble du réseau, cela n'est pas suffisant. Nous avons besoin d'un V-ECU qui contienne autant que possible le calculateur réel. Pour ce faire, il faut combiner des composants logiciels, des fonctions, des logiciels de base et un code non AUTOSAR provenant de différentes sources. Tout cela se fait de manière centralisée avec le logiciel SystemDesk. Le V-ECU global ainsi généré contient l'environnement d'exécution (RTE) et des parties du logiciel de base (niveaux 2 et 3) en plus de la couche d'application. L'environnement d'exécution et les parties logicielles sont connectés aux interfaces VEOS par SystemDesk. Avec un tel V-ECU, il est possible d'effectuer des tests approfondis, y compris la surveillance du bus et les interfaces de diagnostic, par exemple.

La génération de V-ECU à partir du code de production pour les ECU existants peut s'avérer compliqué lors de la mise en œuvre des tests SIL. Nos nombreuses années d'expérience nous ont permis de gérer de nombreux projets clients avec tous les types de V-ECU. Pour une mise en œuvre réussie du SIL, nous offrons une assistance sur la meilleure façon d'aborder la génération de V-ECU dans des cas spécifiques.

Modèles de simulation pour une boucle fermée

Les modèles de simulation représentent le pendant nécessaire du SUT. Ainsi, des variables d'entrée réalistes sont fournies et les variables de sortie correspondantes sont traitées judicieusement par le SUT pour permettre un essai de roulage virtuel complet. Il en résulte un large éventail d'exigences pour les modèles de simulation - de la simulation d'une dynamique véhicule réaliste et de différentes variantes de groupes motopropulseurs à des simulations de trafic complètes avec de nombreux participants et des environnements réalistes en 3D avec différents phénomènes météorologiques et des modèles de capteurs correspondants basés sur la physique. Selon la fonction à tester, différents niveaux d'abstraction sont également nécessaires. Les dSPACE Automotive Simulation Models (ASM) fournissent des exemples de modèles de simulation appropriés avec un large éventail de détails pour les variantes de véhicules et de groupes motopropulseurs. dSPACE AURELION offre des modèles détaillés d'environnement en 3D et de capteurs. Cela permet d'aborder tous les domaines de l'automobile, en particulier les applications ADAS/AD et l'e-mobilité, et de les développer et les valider en boucle fermée.

Un exemple typique d'interaction entre le SUT et le modèle de comportement physique est illustré à la Figure 3. Outre l'état du véhicule, le SUT attend les données des capteurs d'environnement et transmet le résultat de la planification de la trajectoire au système actionneur. Ainsi, pour pouvoir tester le SUT dans des conditions réalistes, plusieurs calculateurs sont impliqués, qui à leur tour ont leurs propres exigences vis-à-vis du véhicule et des modèles environnementaux. La simulation de capteurs joue un rôle particulièrement important dans ce contexte et peut être configurée de manière flexible, depuis de simples listes d'objets jusqu'à des données réalistes telles que des nuages de points lidar.

Maintenant que le SUT est disponible en tant que V-ECU et que les modèles ont été sélectionnés, il reste une question clé : Comment connecter les différents composants les uns aux autres pour une simulation complète ?

Plateforme de simulation et d’intégration

VEOS est utilisé comme plateforme centrale pour la simulation et l'intégration des différents composants de simulation. Les V-ECU et les modèles de simulation, ainsi que tout ce qui est nécessaire à la simulation, peuvent y être rassemblés. VEOS ne se limite pas aux artefacts et outils dSPACE, mais supporte toutes les normes pertinentes. Si l'intégration par le biais de normes n'est pas possible, il est possible de recourir à la co-simulation. Cela permet d'intégrer des composants polyvalents allant de modèles tiers à d'autres middleware (ROS, etc.), des calculateurs basés sur POSIX et des V-ECU de niveau 4 (simulation de liste d'instructions au niveau matériel).

En tant que plateforme centrale, VEOS est également responsable de la simulation elle-même. VEOS assure la synchronisation temporelle et la communication entre les différents composants de la simulation. La synchronisation temporelle rend la simulation indépendante des conditions en temps réel. Par conséquent, non seulement la simulation ne nécessite pas de matériel mais, dans de nombreux cas, elle s'exécute plus rapidement que sur le HIL. Elle est déterministe et donc reproductible - si tous les artefacts connectés le permettent. En même temps, la synchronisation temporelle permet une représentation exacte de la communication. VEOS permet à la fois une communication basée sur des signaux entre les participants à la simulation et l'échange de messages de bus. VEOS simule les bus réels en prenant également en compte le comportement temporel de la communication par bus. Comme pour le HIL, il est possible d'accéder à la communication par bus dans VEOS pour surveiller les messages de bus et l'injection de défauts.

Malgré son rôle central et l'étendue de ses fonctionnalités, VEOS est une plateforme légère qui peut être étendue du PC de bureau jusqu'au cloud. Il est donc possible d'effectuer des tests à partir d'un calculateur individuel jusqu'à un véhicule virtuel.

Une fois qu'un niveau suffisant de maturité logicielle a été démontré dans les tests SIL, le passage au simulateur HIL se fait sans effort, car les composants et les expériences du SIL peuvent être réutilisés.

Validation automatique

Pour assurer le suivi des campagnes de test à grande échelle, il ne manque qu'un environnement de validation central. Celui-ci est très exigeant : Tout d'abord, la simulation doit être configurée, contrôlée, puis par la suite automatisée. Les tests doivent être planifiés et exécutés de manière centralisée, en tenant compte des différentes méthodologies de test, par exemple les tests basés sur les exigences ou les scénarios. Il en ressort un avantage décisif : Les tests peuvent être effectués 24 heures sur 24, 7 jours sur 7, et permettent une collaboration entre les différents sites. Parallèlement, la traçabilité directe des exigences, des cas de test et des rapports de test est possible, conformément à la recommandation de la norme ISO 26262.

Avec le Test Solution Package (AutomationDesk en association avec SYNECT) et SIMPHERA, dSPACE propose deux solutions qui répondent à deux objectifs d'application différents et qui s'intègrent parfaitement dans la chaîne d'outils.

Les deux solutions offrent un support dans les trois phases importantes pour la réussite des tests : La création de tests, la mise en œuvre des tests créés et la gestion de tous les artefacts, y compris les résultats pertinents pour les tests.

Pour la création de tests, il est important que l'utilisateur dispose d'une interface simple mais puissante pour configurer les cas de test. Ceci est possible dans tous les domaines en utilisant AutomationDesk pour les tests typiques basés sur les exigences. Pour les tests spéciaux orientés ADAS/AD, tels que les SCBT, SIMPHERA offre une interface intuitive pour la configuration de ces tests. Les tests créés dans AutomationDesk sont ensuite généralement gérés dans SYNECT, d'où ils peuvent également être exécutés sur des plateformes HIL distribuées à l'échelle mondiale, par exemple. Les résultats sont stockés dans une base de données centrale et sont donc disponibles de manière centralisée, ce qui favorise la collaboration. En outre, les résultats sont également liés aux exigences couvertes par le test à l'aide d'outils ALM (outils dans lesquels les exigences pour le logiciel sont décrites et tracées). En tant que solution cloud, SIMPHERA offre des avantages dans l'exécution à grande échelle de tests basés sur des scénarios, qui conduisent à une quantité énorme de cas de test spécifiques en raison d'un grand nombre de paramètres et de grandes plages de paramètres. L'exécution à grande échelle, massivement parallèle dans le cloud réduit considérablement le temps nécessaire pour générer les résultats de test requis. Ici aussi, les résultats sont stockés de manière centralisée dans une base de données, où ils sont disponibles pour une analyse ultérieure.