Q : Comment et pourquoi le logiciel RPC a-t-il été développé ?
R : Le concept initial était d’améliorer les données d’essai en reproduisant le comportement mesuré sur le terrain dans un environnement de laboratoire contrôlé et reproductible. Tout a commencé au milieu des années 1970 avec Paul Nawrocke de GM et Richard Lund de MTS. MTS venait de lancer des systèmes d’essais servohydrauliques, les premiers simulateurs de route à quatre postes. L’idée était que, si l’on pouvait faire bouger le vérin comme la route, on pourrait tester des véhicules en laboratoire plutôt que sur le terrain. Pour obtenir des données de charge sur route, les ingénieurs d’essais des équipementiers ont enregistré sur bande les signaux des accéléromètres fixés aux roues d’une voiture roulant sur un terrain d’essai. Les enregistrements ont ensuite été lus dans un ordinateur analogique, qui a transformé les accélérations en profils de déplacement, lesquels ont été transmis à un servocontrôleur exécutant les vérins d’essais. C’était le premier fichier de commande.
Q : Etait-ce une solution viable pour tester les véhicules en laboratoire plutôt que sur le terrain ?
R : Non. Le processus de double intégration de l’accélération et son utilisation comme signal de programmation pour l’entraînement des vérins présentaient un certain nombre de défauts. Cette méthode ne comprenait pas le comportement intrinsèque du servocontrôleur, ni le comportement dynamique encore plus complexe de l’interaction du pneu avec la surface de la route, et par conséquent du plateau du simulateur couplé aux pneus. Paul Nawrocke et Richard Lund ont conclu que s’ils pouvaient développer un modèle mathématique de ces interactions, celui-ci pourrait prédire un meilleur fichier de commande et être utilisé de manière itérative pour affiner la solution prévue. Grâce aux nouveaux ordinateurs numériques capables de faire les calculs, l’idée de corriger la fonction de réponse en fréquence inverse a été améliorée, pour devenir une méthode et une suite de logiciels d’application nommée Remote Parameter Control, ou RPC. Le terme « Remote » signifie qu’un capteur placé sur un système dynamique peut être contrôlé lorsqu’il est éloigné, ou à distance, du vérin qui produit le mouvement. En d’autres termes, nous contrôlons un accéléromètre monté sur un essieu alors que le vérin est éloigné du point où le caoutchouc rencontre la route ou ce que nous appelons aujourd’hui la bande de contact du pneu.
Q : Quand avez-vous commencé à vous intéresser au logiciel RPC ?
R : J’étais chez Ford en train de faire des tests d’acceptation en usine avec RPC, ce que nous pourrions appeler aujourd’hui « RPC Zero ». C’était la première fois que le logiciel RPC était utilisé sur une machine tournante et l’équipe de MTS s’est rapidement rendu compte qu’il fallait plus de puissance de traitement pour calculer les fichiers de commande. Finalement, un processeur vectoriel qui coûtait 34 000 $ en 1978 a été nécessaire pour que cela fonctionne. C’est à ce moment-là que j’ai rencontré l’équipe de MTS et que j’ai été séduit par l’entreprise. Peu de temps après, j’ai eu l’occasion de rejoindre MTS et de faire partie des premiers membres de l’équipe de développement de logiciels pour la dynamique des véhicules de MTS. RPC, c’était tout notre travail.
Q : Comment était le logiciel RPC à l’époque ?
R : Très différent de ce qu’il est aujourd’hui, bien sûr. C’était une interface de questions-réponses sans repères graphiques. Nous travaillions dans MTS BASIC sur des écrans verts. Pour étudier le tracé d’une fonction de réponse en fréquence complète, nous devions imprimer une matrice sur papier de 24 feuilles de large sur 24 feuilles de haut et les disposer toutes ensemble sur le sol. Nous indiquions divers éléments de cette matrice géante de graphiques avec un bâton (oui, un vrai bâton) et réfléchissions aux détails, en nous demandant pourquoi le modèle mathématique nous donnait ou ne nous donnait pas une réponse exploitable et l’interprétait comme une radiographie. Je compare souvent la fonction de réponse en fréquence, ou FRF, à une radiographie du comportement dynamique d’un système.
Q : Comment l’industrie a-t-elle réagi aux capacités du logiciel ?
R : Pour la première fois, les ingénieurs d’essais ont pu recréer un environnement de chargement réaliste en laboratoire. La méthode n’a pas compromis la dynamique du système. Elle a permis de garantir une charge correcte dans une structure dynamique complexe, comme un système de suspension. C’est grâce à la méthode et au logiciel RPC que cela a pu se faire. Qui plus est, des ordinateurs dotés de la puissance de traitement nécessaire pour effectuer les calculs permettant de créer des fichiers de commande dans un délai réaliste sont rapidement devenus disponibles. Nous avons également développé des méthodes d’instrumentation des véhicules avec des jauges de déformation sur les essieux et des capteurs de déplacement pour mesurer le mouvement vertical afin de saisir chaque nuance de la réponse dynamique. Nous avons commencé à vendre des simulateurs de route MTS avec le logiciel RPC. A cette époque, le code source évoluait à chaque installation. Au milieu des années 1980, le logiciel RPC était devenu mondial, ce qui était remarquable étant donné qu’il avait moins de 10 ans.
Q : Quand a été formé le premier groupe d’utilisateurs du RPC ?
R : C’était vers 1980. Les utilisateurs du logiciel RPC ont eux-mêmes organisé la première réunion pour échanger des idées et des expériences. C’était vraiment une initiative populaire. MTS a apporté son soutien à cette première réunion qui s’est déroulée à Détroit et beaucoup de personnes y ont participé. Bien que concurrents, les participants de différents équipementiers ont trouvé un moyen de se réunir et de consacrer leurs efforts à faire progresser la science et à relever des défis communs. Ils ont fait part des connaissances qu’ils avaient acquises en utilisant RPC, des techniques qu’ils avaient développées et des listes de souhaits de ce qu’ils voulaient que le logiciel fasse. A l’instar du RPC lui-même, les groupes d’utilisateurs se sont rapidement imposés. Aujourd’hui, MTS organise des réunions de groupes d’utilisateurs de RPC tous les semestres pour les utilisateurs situés en Amérique du Nord, en Europe, au Japon, en Corée, en Chine, au Brésil et en Inde.
Q : La popularité de RPC a-t-elle changé la façon dont MTS répondait aux besoins de l’industrie ?
R : Oui, MTS a attiré plusieurs personnes qui se consacraient à résoudre les problèmes pour lesquels RPC avait été conçu. C’est pour cela que j’ai rejoint MTS. L’entreprise a également attiré des personnes talentueuses comme Dave Holub, Peter Gunness et Dave Fricke, qui ont appris à utiliser le RPC dans les livres alors qu’ils étaient de jeunes ingénieurs. Dave a mis au point de nouvelles méthodes de modélisation des pneus avant de trouver l’idée de la convergence des réponses des systèmes hybrides, ou HSRC, qui lui a permis de se rapprocher plus que quiconque de la solution au défi de la simulation de route.
Q : Quel est le défi de la simulation de route ?
R : Nous avons toujours appelé RPC simulation de route, et nous le faisons encore, mais il s’agit en fait de la reproduction en laboratoire de résultats mesurés sur le terrain. Les entrées provenant de la route sont différentes des sorties au niveau du moyeu du véhicule d’essai, car il y a un pneu entre les deux. Nous ne pouvons pas mesurer ce que fait la partie inférieure du pneu, c’est pourquoi nous utilisons la méthode RPC pour combler l’écart. Simuler réellement la route, ou « ramener la route dans le laboratoire », serait l’ultime avancée dans les essais physiques.
Q : Quel est l’avantage de ramener la route dans le laboratoire ?
R : L’industrie subit une pression énorme pour accélérer et rationaliser le développement des véhicules. Pour générer un fichier de commande avec le processus RPC, vous devez d’abord collecter des données de charge sur route sur la piste d’essai en utilisant un prototype complet entièrement instrumenté, généralement l’un des quatre qui arrivent par étapes au cours d’un cycle de développement de véhicules de deux ans. Lorsque vous avez terminé les essais avec les données du prototype final, le fabricant a déjà construit l’outillage pour estamper les pièces et les panneaux pour la production. En d’autres termes, il est déjà bien tard et il serait extrêmement coûteux de retravailler la conception si les essais révélaient des défauts. Devant la pression exercée par des calendriers de développement de plus en plus courts, une très forte tendance se dessine pour ramener la route dans le laboratoire et permettre des essais réalistes de type RPC dès que les premiers prototypes de pièces et de systèmes sont disponibles. Ne pas avoir à acquérir des données de charge sur route serait un avantage considérable, car on pourrait commencer à améliorer les conceptions sans avoir de prototype de véhicule fonctionnel.
Q : Existe-t-il une simulation de route réelle ?
R : Oui. En réalité, la méthode HSRC nous permet de ramener la route dans le laboratoire. Il s’agit tout d’abord d’une version numérisée réelle de la surface de la route du terrain d’essai, qui est une sorte de très gros fichier JPEG de la route dans lequel, à la place de la couleur, les pixels représentent la hauteur des cailloux. Le principe d’une solution hybride est de combiner une partie physique (dans ce cas une vraie voiture sur un vrai simulateur de route) et une partie virtuelle, ou un pneu mathématique capable de « rouler » sur le scan numérique de la route. Avec la HSRC, les forces et les mouvements du moyeu de roue physique et les forces et les mouvements du pneu virtuel sont combinés pour préserver l’élément de présence. En d’autres termes, le véhicule physique ressent la présence du pneu virtuel et le pneu virtuel ressent la présence du véhicule physique. La HSRC utilise à la fois la technologie FRF inverse et les stratégies itératives de RPC pour parvenir à reproduire avec précision la charge sur route sur le véhicule sans avoir à acquérir des données de charge sur route. Et tout se passe en laboratoire, sans prototype complet.
Q : Etant donné le potentiel de la HSRC, RPC perdra-t-il de son importance ?
R : Non, pas du tout. RPC sera toujours essentiel pour un certain nombre d’applications. L’acquisition de données sur le terrain restera toujours d’actualité, même si elle sera peut-être moins fréquente. Grâce à la possibilité de ramener la route dans le laboratoire, nous pouvons acquérir des données sur les composants et les sous-systèmes directement à partir d’un essai HSRC sur un véhicule complet. Les données obtenues peuvent être utilisées pour effectuer des essais supplémentaires sur les composants et les sous-systèmes en utilisant la méthode RPC. Qui plus est, le logiciel RPC peut traiter davantage les données acquises en laboratoire pour développer plus efficacement des essais aléatoires et par cycle de blocs. Et n’oublions pas que la méthode RPC est idéale pour les fabricants de composants et de sous-systèmes qui utilisent les données fournies par l’équipementier. Il reste l’un des moyens les plus fiables d’effectuer des essais de durabilité précis.
Q : L’entreprise MTS continuera-t-elle à prendre en charge les méthodes et outils RPC ?
R : Absolument. En continuant à investir dans les outils RPC, nous pourrons tirer pleinement avantage du fait de ramener la route dans le laboratoire. Le logiciel RPC fournit les outils d’analyse et de visualisation des signaux qui sont nécessaires à la mise en œuvre de nouvelles idées d’essai et de corrélation. Ces outils deviendront encore plus importants avec l’évolution des applications HSRC. Nous mettons au point des méthodes pour « voir » la route numérique et visualiser les pneus sur cette route, afin de comprendre comment le système physique/virtuel se présente dans son ensemble. Nous continuerons également à utiliser RPC pour apprendre à appliquer l’analyse des dommages par fatigue lors de la validation des essais HSRC et de l’évaluation de la précision. Nous avons peut-être ramené la route dans le laboratoire, mais il reste encore beaucoup à faire pour réduire la durée des essais, améliorer la précision et fournir des résultats d’essais exploitables. Tout cela nécessite d’améliorer et de faire progresser en permanence les outils et les méthodes RPC.
R : Le concept initial était d’améliorer les données d’essai en reproduisant le comportement mesuré sur le terrain dans un environnement de laboratoire contrôlé et reproductible. Tout a commencé au milieu des années 1970 avec Paul Nawrocke de GM et Richard Lund de MTS. MTS venait de lancer des systèmes d’essais servohydrauliques, les premiers simulateurs de route à quatre postes. L’idée était que, si l’on pouvait faire bouger le vérin comme la route, on pourrait tester des véhicules en laboratoire plutôt que sur le terrain. Pour obtenir des données de charge sur route, les ingénieurs d’essais des équipementiers ont enregistré sur bande les signaux des accéléromètres fixés aux roues d’une voiture roulant sur un terrain d’essai. Les enregistrements ont ensuite été lus dans un ordinateur analogique, qui a transformé les accélérations en profils de déplacement, lesquels ont été transmis à un servocontrôleur exécutant les vérins d’essais. C’était le premier fichier de commande.
Q : Etait-ce une solution viable pour tester les véhicules en laboratoire plutôt que sur le terrain ?
R : Non. Le processus de double intégration de l’accélération et son utilisation comme signal de programmation pour l’entraînement des vérins présentaient un certain nombre de défauts. Cette méthode ne comprenait pas le comportement intrinsèque du servocontrôleur, ni le comportement dynamique encore plus complexe de l’interaction du pneu avec la surface de la route, et par conséquent du plateau du simulateur couplé aux pneus. Paul Nawrocke et Richard Lund ont conclu que s’ils pouvaient développer un modèle mathématique de ces interactions, celui-ci pourrait prédire un meilleur fichier de commande et être utilisé de manière itérative pour affiner la solution prévue. Grâce aux nouveaux ordinateurs numériques capables de faire les calculs, l’idée de corriger la fonction de réponse en fréquence inverse a été améliorée, pour devenir une méthode et une suite de logiciels d’application nommée Remote Parameter Control, ou RPC. Le terme « Remote » signifie qu’un capteur placé sur un système dynamique peut être contrôlé lorsqu’il est éloigné, ou à distance, du vérin qui produit le mouvement. En d’autres termes, nous contrôlons un accéléromètre monté sur un essieu alors que le vérin est éloigné du point où le caoutchouc rencontre la route ou ce que nous appelons aujourd’hui la bande de contact du pneu.
Q : Quand avez-vous commencé à vous intéresser au logiciel RPC ?
R : J’étais chez Ford en train de faire des tests d’acceptation en usine avec RPC, ce que nous pourrions appeler aujourd’hui « RPC Zero ». C’était la première fois que le logiciel RPC était utilisé sur une machine tournante et l’équipe de MTS s’est rapidement rendu compte qu’il fallait plus de puissance de traitement pour calculer les fichiers de commande. Finalement, un processeur vectoriel qui coûtait 34 000 $ en 1978 a été nécessaire pour que cela fonctionne. C’est à ce moment-là que j’ai rencontré l’équipe de MTS et que j’ai été séduit par l’entreprise. Peu de temps après, j’ai eu l’occasion de rejoindre MTS et de faire partie des premiers membres de l’équipe de développement de logiciels pour la dynamique des véhicules de MTS. RPC, c’était tout notre travail.
Q : Comment était le logiciel RPC à l’époque ?
R : Très différent de ce qu’il est aujourd’hui, bien sûr. C’était une interface de questions-réponses sans repères graphiques. Nous travaillions dans MTS BASIC sur des écrans verts. Pour étudier le tracé d’une fonction de réponse en fréquence complète, nous devions imprimer une matrice sur papier de 24 feuilles de large sur 24 feuilles de haut et les disposer toutes ensemble sur le sol. Nous indiquions divers éléments de cette matrice géante de graphiques avec un bâton (oui, un vrai bâton) et réfléchissions aux détails, en nous demandant pourquoi le modèle mathématique nous donnait ou ne nous donnait pas une réponse exploitable et l’interprétait comme une radiographie. Je compare souvent la fonction de réponse en fréquence, ou FRF, à une radiographie du comportement dynamique d’un système.
Q : Comment l’industrie a-t-elle réagi aux capacités du logiciel ?
R : Pour la première fois, les ingénieurs d’essais ont pu recréer un environnement de chargement réaliste en laboratoire. La méthode n’a pas compromis la dynamique du système. Elle a permis de garantir une charge correcte dans une structure dynamique complexe, comme un système de suspension. C’est grâce à la méthode et au logiciel RPC que cela a pu se faire. Qui plus est, des ordinateurs dotés de la puissance de traitement nécessaire pour effectuer les calculs permettant de créer des fichiers de commande dans un délai réaliste sont rapidement devenus disponibles. Nous avons également développé des méthodes d’instrumentation des véhicules avec des jauges de déformation sur les essieux et des capteurs de déplacement pour mesurer le mouvement vertical afin de saisir chaque nuance de la réponse dynamique. Nous avons commencé à vendre des simulateurs de route MTS avec le logiciel RPC. A cette époque, le code source évoluait à chaque installation. Au milieu des années 1980, le logiciel RPC était devenu mondial, ce qui était remarquable étant donné qu’il avait moins de 10 ans.
Q : Quand a été formé le premier groupe d’utilisateurs du RPC ?
R : C’était vers 1980. Les utilisateurs du logiciel RPC ont eux-mêmes organisé la première réunion pour échanger des idées et des expériences. C’était vraiment une initiative populaire. MTS a apporté son soutien à cette première réunion qui s’est déroulée à Détroit et beaucoup de personnes y ont participé. Bien que concurrents, les participants de différents équipementiers ont trouvé un moyen de se réunir et de consacrer leurs efforts à faire progresser la science et à relever des défis communs. Ils ont fait part des connaissances qu’ils avaient acquises en utilisant RPC, des techniques qu’ils avaient développées et des listes de souhaits de ce qu’ils voulaient que le logiciel fasse. A l’instar du RPC lui-même, les groupes d’utilisateurs se sont rapidement imposés. Aujourd’hui, MTS organise des réunions de groupes d’utilisateurs de RPC tous les semestres pour les utilisateurs situés en Amérique du Nord, en Europe, au Japon, en Corée, en Chine, au Brésil et en Inde.
Q : La popularité de RPC a-t-elle changé la façon dont MTS répondait aux besoins de l’industrie ?
R : Oui, MTS a attiré plusieurs personnes qui se consacraient à résoudre les problèmes pour lesquels RPC avait été conçu. C’est pour cela que j’ai rejoint MTS. L’entreprise a également attiré des personnes talentueuses comme Dave Holub, Peter Gunness et Dave Fricke, qui ont appris à utiliser le RPC dans les livres alors qu’ils étaient de jeunes ingénieurs. Dave a mis au point de nouvelles méthodes de modélisation des pneus avant de trouver l’idée de la convergence des réponses des systèmes hybrides, ou HSRC, qui lui a permis de se rapprocher plus que quiconque de la solution au défi de la simulation de route.
Q : Quel est le défi de la simulation de route ?
R : Nous avons toujours appelé RPC simulation de route, et nous le faisons encore, mais il s’agit en fait de la reproduction en laboratoire de résultats mesurés sur le terrain. Les entrées provenant de la route sont différentes des sorties au niveau du moyeu du véhicule d’essai, car il y a un pneu entre les deux. Nous ne pouvons pas mesurer ce que fait la partie inférieure du pneu, c’est pourquoi nous utilisons la méthode RPC pour combler l’écart. Simuler réellement la route, ou « ramener la route dans le laboratoire », serait l’ultime avancée dans les essais physiques.
Q : Quel est l’avantage de ramener la route dans le laboratoire ?
R : L’industrie subit une pression énorme pour accélérer et rationaliser le développement des véhicules. Pour générer un fichier de commande avec le processus RPC, vous devez d’abord collecter des données de charge sur route sur la piste d’essai en utilisant un prototype complet entièrement instrumenté, généralement l’un des quatre qui arrivent par étapes au cours d’un cycle de développement de véhicules de deux ans. Lorsque vous avez terminé les essais avec les données du prototype final, le fabricant a déjà construit l’outillage pour estamper les pièces et les panneaux pour la production. En d’autres termes, il est déjà bien tard et il serait extrêmement coûteux de retravailler la conception si les essais révélaient des défauts. Devant la pression exercée par des calendriers de développement de plus en plus courts, une très forte tendance se dessine pour ramener la route dans le laboratoire et permettre des essais réalistes de type RPC dès que les premiers prototypes de pièces et de systèmes sont disponibles. Ne pas avoir à acquérir des données de charge sur route serait un avantage considérable, car on pourrait commencer à améliorer les conceptions sans avoir de prototype de véhicule fonctionnel.
Q : Existe-t-il une simulation de route réelle ?
R : Oui. En réalité, la méthode HSRC nous permet de ramener la route dans le laboratoire. Il s’agit tout d’abord d’une version numérisée réelle de la surface de la route du terrain d’essai, qui est une sorte de très gros fichier JPEG de la route dans lequel, à la place de la couleur, les pixels représentent la hauteur des cailloux. Le principe d’une solution hybride est de combiner une partie physique (dans ce cas une vraie voiture sur un vrai simulateur de route) et une partie virtuelle, ou un pneu mathématique capable de « rouler » sur le scan numérique de la route. Avec la HSRC, les forces et les mouvements du moyeu de roue physique et les forces et les mouvements du pneu virtuel sont combinés pour préserver l’élément de présence. En d’autres termes, le véhicule physique ressent la présence du pneu virtuel et le pneu virtuel ressent la présence du véhicule physique. La HSRC utilise à la fois la technologie FRF inverse et les stratégies itératives de RPC pour parvenir à reproduire avec précision la charge sur route sur le véhicule sans avoir à acquérir des données de charge sur route. Et tout se passe en laboratoire, sans prototype complet.
Q : Etant donné le potentiel de la HSRC, RPC perdra-t-il de son importance ?
R : Non, pas du tout. RPC sera toujours essentiel pour un certain nombre d’applications. L’acquisition de données sur le terrain restera toujours d’actualité, même si elle sera peut-être moins fréquente. Grâce à la possibilité de ramener la route dans le laboratoire, nous pouvons acquérir des données sur les composants et les sous-systèmes directement à partir d’un essai HSRC sur un véhicule complet. Les données obtenues peuvent être utilisées pour effectuer des essais supplémentaires sur les composants et les sous-systèmes en utilisant la méthode RPC. Qui plus est, le logiciel RPC peut traiter davantage les données acquises en laboratoire pour développer plus efficacement des essais aléatoires et par cycle de blocs. Et n’oublions pas que la méthode RPC est idéale pour les fabricants de composants et de sous-systèmes qui utilisent les données fournies par l’équipementier. Il reste l’un des moyens les plus fiables d’effectuer des essais de durabilité précis.
Q : L’entreprise MTS continuera-t-elle à prendre en charge les méthodes et outils RPC ?
R : Absolument. En continuant à investir dans les outils RPC, nous pourrons tirer pleinement avantage du fait de ramener la route dans le laboratoire. Le logiciel RPC fournit les outils d’analyse et de visualisation des signaux qui sont nécessaires à la mise en œuvre de nouvelles idées d’essai et de corrélation. Ces outils deviendront encore plus importants avec l’évolution des applications HSRC. Nous mettons au point des méthodes pour « voir » la route numérique et visualiser les pneus sur cette route, afin de comprendre comment le système physique/virtuel se présente dans son ensemble. Nous continuerons également à utiliser RPC pour apprendre à appliquer l’analyse des dommages par fatigue lors de la validation des essais HSRC et de l’évaluation de la précision. Nous avons peut-être ramené la route dans le laboratoire, mais il reste encore beaucoup à faire pour réduire la durée des essais, améliorer la précision et fournir des résultats d’essais exploitables. Tout cela nécessite d’améliorer et de faire progresser en permanence les outils et les méthodes RPC.
