La validation du code des calculateurs (ECU) au moyen d’une simulation Software-In-the-Loop (SIL) fait désormais partie intégrante du développement de calculateur dans le secteur automobile. Alors qu’il y a quelques années il était plus courant de tester des sous-systèmes, la simulation de l’ensemble du système prend aujourd’hui une place de plus en plus importante. L'une des raisons est le niveau croissant de mise en réseau et les dépendances associées entre les calculateurs. Les simulations globales sont particulièrement importantes pour les équipementiers (OEM) – les fournisseurs délivrent généralement les calculateurs virtuels (V-ECU) requis pour cela. En matière de collaboration, les équipementiers sont souvent confrontés à la question suivante : Que dois-je faire pour obtenir le V-ECU adapté à la simulation globale auprès du fournisseur ?
La solution : Un standard pour les V-ECU
Le standard FMI (Functional Mock-up Interface) est disponible pour échanger des V-ECU simples dans les premières phases de développement. Pour les V-ECU plus complexes, toutefois, ce standard n'est pas suffisant, surtout si ceux-ci incluent une interface de bus. C’est pourquoi le projet FMI Layered Standard Network Communication (Communication réseau en couche standardisée de la norme FMI) est un travail intensif sur un nouveau standard qui permet des échanges efficaces entre partenaires pour de tels V-ECU. Les avantages pour la validation sont évidents :
- Baisse des coûts d’intégration grâce à une meilleure interopérabilité des outils et des plateformes de test
- Collaboration plus efficace grâce à un effort de coordination considérablement réduit entre les équipementiers et les fournisseurs
Découvrez toutes les informations sur l'état de développement actuel du standard et comment dSPACE le soutiendra à l'avenir.
FMI 3.0 et le concept de standard en couches
Le standard FMI est déjà largement utilisé dans le domaine des modèles de simulation et facilite considérablement la collaboration entre les équipementiers et les fournisseurs. Dans la version 3.0, un certain nombre de fonctionnalités ont été ajoutées pour créer la base de son utilisation pour les V-ECU qui seront plus complexes à l'avenir, notamment :
- Variables d’horloge permettant le déclenchement des événements
- Bornes permettant de regrouper les variables d’entrées/sorties
- Le concept de standard en couches
Ce dernier permet d’ajouter de nouvelles fonctionnalités au standard FMI existant sans changer le standard d’origine.
FMI Layered Standard Network Communication (Communication réseau en couche standardisée de la norme FMI)
Depuis mi-2022, dSPACE supporte activement les activités liées à la FMI Layered Standard Network Communication (Communication réseau en couche standardisée de la norme FMI) et apporte ses nombreuses années d’expérience dans le domaine de la simulation de bus. L'accent est toujours mis sur l'acceptation du nouveau standard par toutes les parties impliquées, c'est-à-dire les équipementiers, les fournisseurs et les fournisseurs d'outils.
Le projet a récemment franchi une première étape importante : la version « alpha », première version du standard pour la simulation de bus CAN. Cette étape a été essentielle car les V-ECU peuvent maintenant être testés et échangés entre les partenaires de développement sur cette base. Des travaux sont en cours sur d'autres bus tels que LIN, Ethernet et FlexRay, et les premières versions seront également disponibles d’ici peu.
Les résultats des travaux sont transparents et consultables en ligne en libre accès.
La bonne interface pour chaque V-ECU
Une condition préalable à l'acceptation d'un standard est son applicabilité aux cas d'utilisation pertinents. Ceux-ci peuvent varier considérablement pour les V-ECU et dépendent généralement du niveau du V-ECU. Si les niveaux de V-ECU sont classés de 0 à 4 comme dans le livre blanc de ProSTEP iViP Exigences pour la standardisation des V-ECU , une interface bus devient pertinente à partir du niveau 2 par exemple.
Alors que les V-ECU de niveau 0 et de niveau 1 pouvaient déjà être créés et échangés sur la base de la FMI, le nouveau standard Communication réseau en couche standardisée de la norme FMI est requis à partir du niveau 2. En résumé : Quel que soit le type de V-ECU avec l’interface de bus que vous souhaitez créer ou échanger, le nouveau standard fournira une interface standardisée adaptée.
Bon à savoir
Le niveau d'un V-ECU fournit des informations sur son état de développement. En ce qui concerne la simulation, la règle suivante s’applique : Plus le développement du V-ECU progresse, plus les détails doivent être pris en compte.
- Niveau 0 et niveau 1 : Dans les premières phases du développement, l’accent est mis sur la validation des composants applicatifs individuels. Le type exact de transmission de signal entre les V-ECU est secondaire et n'est généralement pas encore entièrement spécifié.
- À partir du niveau 2 : La communication par bus et l’intégration du V-ECU dans une simulation globale deviennent de plus en plus importantes. À partir de là, le logiciel de base pour la communication par bus doit être intégré dans le V-ECU. Pour une intégration plus facile et une création plus rapide du V-ECU, un logiciel de base simplifié qui ne comprend que le module de communication (COM) est généralement utilisé dans les premières phases de développement.
- Niveau 3 : Ces V-ECU sont très proches du calculateur réel et ne diffèrent idéalement qu'en termes de modules de pilote matériel-dépendants. Tous les logiciels de base situés au-dessus de ces modules font partie de l’objet de test ici et sont donc entièrement intégrés dans le V-ECU.
Abstraction des signaux physiques
Si un logiciel de base simplifié, qui inclut uniquement le module de communication (COM), est utilisé pour les V-ECU de niveau 2, on parle familièrement de coupe haute , car seule la couche supérieure du logiciel est incluse dans le V-ECU. La Communication réseau en couche standardisée de la norme FMI fournit ce qu’on appelle l'abstraction des signaux physiques comme une interface pour la création de ces V-ECU. Cette interface est axée sur la transmission des signaux de bus individuels et l’heure de la transmission.
Abstraction de réseau
Avec les V-ECU de niveau 3, l’ensemble du logiciel de base situé au-dessus du module pilote CAN (Controller Area Network) est généralement intégré dans le V-ECU. La coupure dans le logiciel est donc à un niveau très bas, généralement dans les modules pilotes matériel-dépendants, ce que l’on appelle une coupure basse . Le nouveau standard en couches définit également une interface adaptée à cette situation avec l'Abstraction de réseau. Ici, la transmission n'a pas lieu au niveau signal du bus, mais sur la base des trames/PDU (Protocol Data Units) associées.
L'Abstraction de réseau développe son plein potentiel en conjonction avec une simulation de bus supplémentaire. Cela permet d’inclure le timing et la priorisation des messages de bus ainsi que les états d’erreur lors de la transmission des trames/PDU dans la simulation. Le logiciel de base intégré peut ainsi être testé de manière très réaliste.
Dans ce contexte, il est particulièrement pratique pour l'utilisateur, si la plateforme de simulation fournit la simulation de bus directement comme une fonctionnalité intégrée. C’est là que VEOS entre en jeu : La plateforme dSPACE pour la simulation sur PC inclut déjà la simulation de bus requise, ce qui facilite grandement la configuration du système de simulation pour les utilisateurs.
Quelle interface est la bonne pour mon cas d'utilisation ?
Une simulation du bus au niveau de la couche Abstraction des signaux physiques est particulièrement adaptée dans ces cas :
- V-ECU de niveau 2 dans les premières phases
- Les autres participants à la simulation fournissent des signaux réseau exclusivement sous forme de signaux physiques.
- Une coupure dans le V-ECU au niveau du module de communication (COM) est possible et la granularité de la simulation est acceptable.
Dans une simulation de bus au niveau de la couche Abstraction de réseau , les signaux réseau sont échangés sur la base des trames associées. Le logiciel de base peut donc être coupé à partir du niveau du module PDU Router (PduR) jusqu’au niveau matériel. Cette couche est donc adaptée dans les cas suivants :
- V-ECU de niveau 2 et de niveau 3 contenant le logiciel de base sous le module COM
- D'autres participants à la simulation, par exemple des modèles restbus, fournissent des messages de bus basés sur des trames/PDU.
- La simulation du comportement du bus est souhaitée ou nécessaire.
Création et simulation de V-ECU avec dSPACE
Le nouveau standard en couches joue également un rôle clé chez dSPACE, en particulier dans le domaine de la simulation SIL. Le support du standard est en cours de mise en œuvre étape par étape dans les outils dSPACE – initialement pour SystemDesk, l’outil dSPACE de génération de V-ECU, et pour VEOS, la plateforme de simulation sur PC.
Les utilisateurs qui travaillent déjà avec les outils peuvent continuer à les utiliser sous leur forme habituelle et profiter de ces fonctionnalités supplémentaires :
SystemDesk
Les modules MCAL pour les pilotes de bus peuvent également être intégrés dans les V-ECU à l'avenir s'ils doivent ensuite être exportés en tant que FMU (*.fmu). Jusqu’à présent, cela n’était possible qu’avec les V-ECU en conjonction avec le format dSPACE-propriétaire *.vecu. Cela signifie que les V-ECU peuvent être créés sur la base de FMI3 et de l'Abstraction de réseau du standard en couches.
VEOS
La plate-forme de simulation reconnaîtra automatiquement les FMU avec la Communication réseau en couche standardisée de la norme FMI basée sur l'Abstraction de réseau pendant l’importation. Dans ce contexte, VEOS n’affiche pas les terminaux de bus comme variables ou ports, mais comme contrôleurs de bus comme d’habitude. Les simulations de restbus sous forme de conteneurs de simulation de bus (BSC) peuvent toujours être connectées directement aux V-ECU. VEOS supportera également la simulation du comportement du bus comme d’habitude.
Quelles seront les prochaines étapes ?
Avec la version alpha du standard en couches pour CAN, le groupe de travail FMI a franchi une première étape importante. En plus de la spécification actuelle, les premières démos, un C-API et la documentation pratique pour la création de FMU avec bus CAN sont déjà disponibles et accessibles au public. Des contrôles croisés sont en cours pour garantir l’interchangeabilité entre les fabricants d’outils et éliminer les incohérences finales de la spécification.
En parallèle, le groupe travaille sur la spécification d’autres bus comme FlexRay. Un premier projet est déjà disponible pour LIN. Les principes de base étant les mêmes pour tous les types de bus, le groupe de travail peut s’appuyer sur les résultats de la spécification CAN, ce qui accélère considérablement le processus. dSPACE continuera également à être fortement impliqué dans ce domaine.
En ce qui concerne les outils dSPACE, la mise en œuvre et le support du standard en couches battent leur plein : SystemDesk et VEOS commenceront par CAN, d'autres outils dSPACE et le support d'autres bus suivront.
À propos des auteurs
Markus Süvern
Team Lead, Production Software & SIL Simulation, dSPACE GmbH
Christian Becker
Product Manager, Production Software & SIL Simulation, dSPACE GmbH
