Applications

Analyse en temps-réel de la dynamique de systèmes

Pour plusieurs projets, l'objectif principal est de developer une simulation afin d'étudier la réponse dynamique d'un système soumis à un certains stimuli qui ne peuvent être analysés de quelconque autre façon. Par exemple, un aéronef est constitué de plusieurs sous-systèmes qui interagissent tous ensemble. La manière la plus efficace d'étudier l'impact d'un système sur les autres est de le tester sur un prototype virtuel de l'aéronef. De plus, en intégrant un opérateur dans la boucle, tel un pilote d'essai, plusieurs failles du design peuvent être détectées bien avant qu'un prototype physique soit construit.

Tests de composantes mécaniques sur plateforme virtuelle

Il existe une tendence grandissante pour l'utilisation de cellules d'essais reproduisant le comportement dynamiques de systèmes afin de tester de nouvelles composantes d'ingénierie pour lesquelles elles sont destinées. Par exemple, une transmission automobile peut être installée sur un banc de test reproduisant le comportement routier d'un véhicule pour un large éventail de conditions d'utilisation. De cette façon, le manufacturier économise sur les coût liés au véhicule de test, ne depend pas de la performance d'un conducteur d'essai et tous les tests sont entièrement répétables.

Développement de systèmes de contrôle

Le cycle en V est une représentation du processus typique utilisé pour le développement de systèmes de contrôle. Peu importe l'application, qu'elle soit automobile, aérospatiale, robotique ou d'électrotechnique, l'utilisation de la simulation temps-réel et non temps-réel est dictée par le besoin de développer des lois de commande robustes pour un système complexe. Les simulateurs RT-LAB peuvent aider tout au long de ce processus.

La première étape du cycle consiste en l'analyse des requis. À ce niveau, il est nécessaire de bien définir l'étendue du système à commander (un moteur à combustion, un moteur électrique, une bras robotisé, un aéronef), auquel on réfère en utilisant le terme générique processus, ainsi que les entrées du système que le contrôleur peut influencer (d'admission de carburant, niveau de tension, couple appliqué) et les sorties à commander (vitesse, position, altitude). Il est également important de définir la performance (temps de stabilisation, dépassement, marge de phase, marge de gain) que notre système commandé doit atteindre. Cette dernière information deviendra le critère de validité de notre contrôleur.

La prochaine étape est la conception haut-niveau du contrôleur, aussi appelée logiciel-dans-la-boucle. Ici, le modèle du processus est simulé conjointement avec le modèle du contrôleur afin de valider la stratégie de contrôle envisagée. Pour ce faire, la simulation est nécessaire, mais pas nécessairement en temps-réel puisque toutes les composantes (processus et contrôleur) font partie d'un modèle mathématique commun. Cependant, il peut être utile de distribuer le calcul de ce modèle sur plusieurs unités de traitement afin d'accélérer la simulation et avancer à l'étape suivante plus rapidement. Cette distribution d'un modèle est prise en charge de façon transparente par RT-LAB.

Une fois la stratégie de contrôle choisie vient le prototypage fonctionnel. C'est le stade d'implémentation de l'algorithme de contrôle dans un système capable d'exécuter l'algorithme en temps-réel tout en permettant d'interfacer le simulateur avec le processus réel. Durant tout le cycle de développement, il est souhaitable de limiter l'utilisation du processus réel puisque celle-ci est coûteuse en prend généralement beaucoup de temps. Ici, cependant, il est nécessaire de le faire afin de valider la stratégie et d'adjuster les paramètres de contrôle. Plus le modèle de processus utilisé est fidèle, moins le temps nécessaire sera important puisque l'étape de conception haut-niveau aura déjà fourni un contrôleur plus performant. Une cible RT-LAB compacte est une plateforme de prototypage idéale intégrant les interfaces d'entrées/sorties. Pour des applications de recherche ou à faible volume de production, le système RT-LAB peut même être utilisé comme plateforme finale et le prototypage est donc réalisé sur le même matériel.

L'algorithme de contrôle devrait maintenant permettre d'atteindre les performances désirées. C'est donc le temps de traduire l'algorithme en code de production et de l'implanter sur le prototype de plateforme. Le produit de cette étape est un vrai contrôleur, intégrant probablement des fonctions de diagnostic additionnelles, mais dans un format prêt pour la production.

Avec le contrôleur prototype, la première étape consiste en la réalisation des tests unitaires. Ces tests de bas niveau permettent la validation des interfaces d'entrée et de sortie ainsi que des fonctionalités de base du contrôleur. Parce que ces tests n'implique que l'opération de base du contrôleur, un simple simulateur en boucle ouverte est suffisant. Ceci veut dire que le système de test ne fait qu'exciter les entrées du contrôleur tout en observant ses sorties. Il n'y a donc pas de modèle du processus pour "fermer la boucle". Le système utilisé ici peut être un simulateur statique dédié, comme le système TestDrive d'Opal-RT, qui pourra être utilisé lors de la production pour la validation fonctionnelle des calculateurs de série. Autrement, une simulateur du type RT-LAB Engineering Simulator permet d'utiliser le système HIL complet (voir ci-bas) nécessaire pour les tests d'intégration avec un modèle simplifié en boucle ouverte.

Une fois les fonctionnalités de base validées, les tests d'intégration ou matériel-dans-la-boucle (HIL) devront être réalisés afin de valider l'ensemble des lois de commande telles qu'implémentées dans le matériel prototype. Ceci inclut toutes les conditions normales d'opération ainsi qu'un maximum de scénarios plus pointus et potentiellement problématiques. Afin de réaliser ces tests, un système temps-réel simulant le modèle du processus est la meilleure solution envisageable. Il s'agit d'une mesure moins onéreuse et plus flexible pour la génération et la reproductibilité des conditions normales d'utilisation et des scénarios de faillite que l'utilisation du vrai système à commander. Dépendamment de la complexité du modèle, un système RT-LAB simple ou avec calcul distribué peut être utilisé pour l'exécution du modèle de processus en temps-réel.

Une fois toutes les étapes précédentes complétées, le contrôleur prototype devrait maintenant avoir été testé en profondeur et être prêt à être relié à un vrai système. Les tests opérationnels permettront de finaliser la calibration et l'ajustement des paramètres de contrôle.

Tests de systèmes de contrôle en série

Une fois les contrôleurs en production de série, au lieu de les inspecter avec un vrai système à contrôler, ils peuvent être facilement testés en utilisant le même banc statique (en boucle ouverte) utilisé à l'étape de prototypage, permettant ainsi des tests automatisés, rigoureux et répétables. Le système TestDrive est un parfait exemple d'une solution développée pour les tests en série. Avec l'intégration de la gestion des bus d'alimentation et de la configuration logicielle de tout le conditionnement des signaux, ce système permet l'adaptabilité rapide nécessaire pour les tests en série.

Acquisition de données et capture d'événements discrets à haut débit

Les fonctionalités uniques de RT-LAB en matière d'archivage de données à haute vitesse et de capture d'événements discrets ainsi que l'acquisition et l'écriture de données directement sur la cible en font un outil idéal pour des applications d'acquisition de données. De plus, le support d'applications embarquées vous permet de créer des systèmes autonomes pour une opération à distance ou non-supervisée.

Formation d'opérateurs

Puisque le modèle mathématique du système a déjà été développé pour le processus de design, il est possible d'utiliser RT-LAB comme plateforme de formation très abordable pour les opérateurs du système. L'interface de programmation applicative (API) de RT-LAB permet de relier le modèle à l'interface de manipulation réelle afin de fournir un environement proche de la réalité utile pour permettre à l'opérateur d'apprendre les procédures et à gérer les scénarios de faillite sans causer de dommages ou blessures.