7 critères clés pour évaluer les logiciels de simulation en temps réel destinés à l'interopérabilité de la recharge des véhicules électriques

Principaux enseignements

• Les tests d'interopérabilité donnent les meilleurs résultats lorsque la synchronisation des protocoles, la réponse électrique et le comportement des systèmes de back-office sont testés comme un seul et même système.
• Les critères d'évaluation les plus importants correspondent directement aux causes de défaillance qui ralentissent déjà votre laboratoire, notamment les dérives de synchronisation, les défaillances rares et la traçabilité insuffisante.
• Le choix d'un logiciel s'avère plus simple lorsque l'on évalue chaque option en fonction de la reproductibilité des tests de régression, de la clarté des diagnostics et de la compatibilité avec les processus existants liés aux logiciels de recharge de véhicules électriques.

Choisissez un logiciel de simulation qui teste le chargeur, le véhicule et les systèmes administratifs comme un seul et même système synchronisé.

Cette norme exclut de nombreux logiciels de recharge de véhicules électriques qui se contentent de relayer des messages ou de suivre un script très limité. Les problèmes d'interopérabilité surviennent généralement en cas de décalage temporel, de réaction trop lente des étages de puissance ou de traitement désordonné des changements d'état par le logiciel de gestion de la recharge. Un chargeur peut passer avec succès un test de traçabilité du protocole tout en échouant lorsqu'un véhicule demande une nouvelle limite de courant lors d'un incident de réseau. Il faut un logiciel capable de mettre en évidence ces défaillances combinées avant que le matériel ne soit déployé sur le terrain.

Cela est important car les logiciels de gestion des bornes de recharge pour véhicules électriques doivent désormais coordonner un plus grand nombre de bornes, de versions de micrologiciels et de données de session que ce que les bancs d'essai précédents devaient prendre en charge. Si votre simulateur n'est pas capable de relier la synchronisation des messages au comportement électrique et à la logique back-office, votre équipe passera des semaines à rechercher des défauts qui auraient dû être détectés lors d'un seul cycle de test reproductible. Un bon choix commence par des critères qui correspondent aux modes de défaillance que vous observez déjà en laboratoire. Cela permet de restreindre votre sélection à des options réalistes.

« Commencez par les défaillances qui font perdre le plus de temps à votre équipe, puis choisissez le logiciel qui permet de reproduire ces défaillances avec le moins de configuration manuelle possible. »

Les tests d'interopérabilité ne se limitent pas à la reproduction des messages de protocole

Un bon logiciel de test d'interopérabilité reproduit l'intégralité de la session de recharge, et pas seulement l'échange de messages. Il faut disposer de modèles de puissance synchronisés dans le temps, des E/S du contrôleur, des conditions de défaillance et des interfaces avec les logiciels de gestion de la recharge des véhicules électriques, afin qu'un résultat positif garantisse la cohérence des enregistrements de la borne, du véhicule et de la session en conditions de charge.

Un chargeur CC en est un bon exemple. La procédure d'établissement de la communication peut sembler correcte, alors que la montée en courant est en retard, que la synchronisation du contacteur est décalée et que le véhicule réagit en émettant une demande d'arrêt. Les journaux de messages ne suffisent pas à eux seuls à expliquer cette défaillance. Un simulateur doit relier les événements de communication à la réponse électrique au cours de la même simulation.

La même règle s'applique aux systèmes centraux. Une demande d'autorisation peut aboutir alors même que le logiciel de gestion de la recharge des véhicules électriques ferme la session trop tard ou envoie un statut erroné au portail de l'opérateur. Ce problème réside dans le décalage entre la logique du chargeur et la synchronisation du back-office. Votre logiciel de test doit prendre en compte ces deux aspects, sinon vous passerez à côté du dysfonctionnement que les utilisateurs constatent réellement.

Les 7 critères d'évaluation des simulateurs de recharge pour véhicules électriques

Les meilleurs critères suivent le déroulement d'une session de recharge, depuis la prise en charge des normes jusqu'à l'adéquation avec la chaîne d'outils. Vous vérifiez si le simulateur est capable de reproduire les échanges de protocoles, les réponses physiques, les conditions de défaillance, automatisation reproductible et la visibilité des données, tant au niveau du logiciel du chargeur de VE que du logiciel de gestion administrative de la recharge des VE.

1. La couverture du protocole doit correspondre aux normes que vous testez

La couverture des protocoles est essentielle lorsque votre laboratoire doit tester la pile exacte utilisée par vos produits, et non un sous-ensemble simplifié. Un simulateur performant prendra en charge les ensembles de messages, les machines à états et les étapes de sécurité requis pour vos travaux actuels, tant pour la recharge en courant alternatif qu'en courant continu. Une flotte mixte en est un bon exemple, car un même programme peut nécessiter le contrôle des stations, la gestion des messages de connexion et de charge, ainsi que la gestion de l'état des chargeurs au sein d'une même campagne. Si le logiciel gère bien un protocole mais impose des stubs rudimentaires pour les autres, votre résultat de réussite ne sera pas très significatif. Vous devriez également vérifier la facilité avec laquelle l'outil bascule entre les profils, les versions et les rôles de session, car les défauts d'interopérabilité apparaissent souvent à ces interfaces.

2. La précision de synchronisation doit être maintenue en boucle fermée sous charge

La précision temporelle permet de déterminer si le simulateur reste fiable lorsque les boucles de contrôle, le trafic de protocole et les modèles d'installation fonctionnent simultanément. Une latence qui semble acceptable lors d'une démonstration en conditions calmes peut se détériorer dès lors que le contrôle du courant, les E/S de mesure et les messages de charge se disputent le temps d'exécution. Imaginez un véhicule qui demande une baisse de courant lors d'un événement thermique tandis que le chargeur met à jour l'état du contacteur et publie un changement d'état en amont. Si la latence augmente lorsque plusieurs sous-systèmes fonctionnent simultanément, vos résultats ne résisteront pas au contact avec le matériel réel. Vous devez rechercher une exécution déterministe, des temps de pas stables et la preuve que la plateforme ces limites pendant de longues séquences de test.

« Si la latence augmente lorsque plusieurs sous-systèmes fonctionnent simultanément, vos résultats ne résisteront pas à la mise en œuvre sur du matériel réel. »

3. Les modèles de l'étage de puissance doivent refléter le comportement du convertisseur

Les modèles de l'étage de puissance sont essentiels, car les défauts de charge proviennent souvent de la réponse électrique plutôt que de la syntaxe des messages. Un simulateur doit reproduire les limites du convertisseur, le comportement de précharge, la dynamique du circuit intermédiaire et les délais de mesure avec suffisamment de précision pour que le contrôleur réagisse comme il le ferait sur un banc d'essai. Prenons l'exemple d'un chargeur haute puissance qui réussit les tests de communication mais se déclenche lorsque la tension demandée s'approche de la limite du pack. Cette défaillance peut provenir d'une simplification du modèle plutôt que de la logique du chargeur, ce qui signifie que votre logiciel de test a masqué le véritable problème. Vous devez vérifier la fidélité du modèle par rapport aux détails de commutation et à la réponse transitoire dont votre équipe a besoin, puis l'adapter à la vitesse requise pour Simulation HIL .

4. L'injection de défauts doit permettre de détecter les rares défaillances d'interopérabilité

L'injection de défauts n'est utile que lorsqu'elle permet de reproduire les cas complexes que votre laboratoire a rarement l'occasion de détecter deux fois.

vous permettra d'introduire des retards de paquets, des pertes de signal, des séquences incorrectes, des dérives de capteurs et des perturbations côté réseau sans avoir à recréer l'intégralité du test à chaque fois. Une session qui échoue après une brève déconnexion du câble ou une réponse d'autorisation retardée en est un exemple courant, car ce défaut peut disparaître lors d'un nouveau test manuel. Vous devez vérifier avec quelle précision l'outil planifie le défaut et dans quelle mesure il combine les erreurs de protocole avec les événements électriques. Si la plateforme prend en charge plateforme des défauts génériques, elle ne sera pas d'une grande aide pour les défaillances qui reviennent sans cesse dans les journaux de terrain.

5. automatisation des tests automatisation permettre d'exécuter des suites de tests de régression reproductibles

automatisation , car les tests d'interopérabilité perdent de leur valeur lorsque chaque nouvelle exécution dépend de la mémoire du laboratoire et d'un timing manuel. Votre logiciel doit planifier les scénarios, réinitialiser les états, comparer les résultats et stocker les données d'une manière qui s'adapte aux cycles de mise à jour du micrologiciel des chargeurs et des systèmes centraux. Une exécution de régression nocturne constitue un critère de référence pratique, car elle montre si le simulateur est capable d'exécuter des dizaines de sessions après une modification du code sans qu'un ingénieur ne soit à ses côtés. Les équipes qui utilisent OPAL-RT pour l'exécution de scripts se concentrent souvent sur la facilité avec laquelle la plateforme les états du modèle, les déclencheurs de protocole et les E/S matérielles en une seule séquence. Si votre outil n'est pas capable de le faire, le suivi des défauts restera lent et irrégulier.

6. Les traces de données doivent mettre en évidence les erreurs de séquence des messages

Le traçage des données doit permettre d'identifier clairement la cause première, et non vous submerger de journaux distincts qui ne concordent jamais. Le simulateur doit disposer d'horodatages synchronisés entre les messages de protocole, les valeurs analogiques, les E/S numériques et les états des contrôleurs, afin que vous puissiez voir ce qui s'est produit en premier et ce qui a suivi. Un cas utile est celui d'un arrêt de session ayant échoué, où le chargeur signale un arrêt normal, le véhicule continue de demander du courant et la valeur du compteur s'affiche en retard. Ce défaut n'apparaît clairement que lorsque tous les événements partagent une base de temps commune. Vous devriez évaluer le logiciel en fonction de la rapidité avec laquelle un nouvel ingénieur peut isoler l'erreur de séquence à partir des traces capturées, car la qualité des traces détermine souvent la durée pendant laquelle un bug reste ouvert.

7. L'intégration de la chaîne d'outils doit s'étendre aux systèmes de back-office

La compatibilité de la chaîne d'outils détermine si le simulateur s'intègre à votre processus de validation global ou s'il reste un simple outil de laboratoire ponctuel. Vous avez besoin d'interfaces fluides avec les frameworks de test, les référentiels de modèles, les systèmes de reporting et les logiciels de gestion administrative de la recharge des véhicules électriques utilisés pour autoriser les sessions, créer des enregistrements de facturation et clôturer les transactions. Un bon exemple est la prise en charge de l'itinérance, où la station se comporte correctement au niveau du connecteur, mais où l'enregistrement de la session échoue lorsqu'il est transmis à la plateforme centrale. Ce défaut touche à la fois la logique du chargeur et la logique métier ; une simulation isolée ne permettra donc pas de le détecter. Vous devez vérifier les options d'importation et d'exportation, l'accès aux API et la facilité avec laquelle le logiciel s'intègre aux systèmes que votre équipe utilise déjà.

Choisissez un logiciel en fonction de vos cas de test les plus risqués

Commencez par les défaillances qui font perdre le plus de temps à votre équipe, puis choisissez le logiciel qui permet de reproduire ces défaillances avec un minimum de configuration manuelle. Cette approche permet de fonder l'évaluation sur des critères tels que la durée, la réponse électrique et l'adéquation avec les processus administratifs, plutôt que sur des listes de fonctionnalités séduisantes mais qui ne vous aident pas dans votre travail de validation actuel.

Une liste de sélection pertinente résulte de quelques tests rigoureux. Testez un scénario où la communication fonctionne mais où le contrôle de l'alimentation présente des défaillances. Testez-en un autre où la session se termine de manière anormale dans le logiciel de gestion des bornes de recharge pour véhicules électriques. Ajoutez-en un troisième qui provoque une régression après une mise à jour du micrologiciel. Si le simulateur gère ces cas sans problème, vous êtes bien plus près d'un choix judicieux.

• Adaptez l'outil aux normes déjà présentes dans votre matrice de test.
• Vérifiez la stabilité de la synchronisation pendant l'exécution en boucle fermée.
• Vérifiez la fiabilité du modèle par rapport aux défauts du chargeur que vous constatez réellement.
• Exiger la réexécution automatique après toute modification du micrologiciel ou du système de gestion.
• Vérifiez les résultats de la trace avant de porter un jugement sur une interface ou un tableau de bord.

Les équipes regrettent souvent d'avoir choisi un logiciel qui semble simple lors d'une démonstration, mais qui devient opaque au moment du débogage. OPAL-RT répond parfaitement à cette étape de l'évaluation, lorsque un laboratoire doit intégrer la synchronisation, les modèles de système, les E/S du contrôleur et automatisation un flux de travail reproductible. Cette adéquation est bien plus importante que des interfaces soignées, car l'utilité de vos résultats dépendra uniquement de la capacité de votre équipe à reproduire, isoler et corriger les défauts.