D: Come e perché è stato sviluppato il software RPC?
R: Il concetto iniziale era migliorare i dati dei test replicando il comportamento misurato sul campo in un ambiente di laboratorio controllato e ripetibile. Tutto è iniziato a metà degli anni '70 con Paul Nawrocke di GM e il Dr. Richard Lund di MTS. MTS aveva recentemente introdotto i sistemi di prova servoidraulici, i primi simulatori stradali a quattro poster. L'idea era che se si fosse riusciti a far muovere l'attuatore come la strada, sarebbe stato possibile testare i veicoli in laboratorio anziché sul campo. Per acquisire i dati relativi al carico su strada, gli ingegneri di test OEM hanno registrato su nastro i segnali provenienti dagli accelerometri fissati alle ruote di un'auto guidata su un terreno di prova. Le registrazioni sono state quindi riprodotte in un computer analogico, che ha trasformato le accelerazioni in profili di spostamento, che sono stati inviati a un servocontroller che esegue gli attuatori di prova. Quello era il primo drive file.
D: Era una soluzione praticabile per testare i veicoli in laboratorio anziché sul campo?
R: No. Il processo di doppia integrazione dell'accelerazione e di utilizzo come segnale di programmazione per l'azionamento dell'attuatore presentava una serie di difetti. Il metodo non comprendeva il comportamento intrinseco del servocontroller, né l'ancor più complesso comportamento dinamico dell'interazione del pneumatico con il manto stradale, e successivamente il piatto del simulatore accoppiato al pneumatico. Nawrocke e il dottor Lund hanno concluso che se fossero riusciti a sviluppare un modello matematico di queste interazioni, sarebbe stato possibile prevedere un drive file migliore e utilizzarlo in modo iterativo per perfezionare la soluzione prevista. Abilitata da nuovi computer digitali in grado di eseguire calcoli matematici, l'idea della correzione della funzione di risposta in frequenza inversa è stata perfezionata, diventando un metodo e una suite di software applicativo chiamato Remote Parameter Control, o RPC. Remoto significa che un sensore su un sistema dinamico può essere controllato quando è distante, o remoto, dall'attuatore che fornisce il movimento. In altre parole, stiamo controllando un accelerometro montato su un asse mentre l'attuatore è lontano dal punto in cui la gomma incontra la strada o quella che ora chiamiamo la zona di contatto del pneumatico.
D: Quando sei stato coinvolto per la prima volta nello sviluppo del software RPC?
R: Ero alla Ford per eseguire i test di accettazione in fabbrica utilizzando RPC, quello che oggi chiameremmo "RPC Zero". Era la prima volta che l'RPC veniva applicato a una macchina rotante e il team di MTS si rese subito conto che era necessaria una maggiore potenza di elaborazione per calcolare i drive file. Per farlo funzionare serviva un processore array che costava 34.000 dollari nel 1978. È stato allora che ho incontrato il team MTS e mi sono innamorato dell'azienda. Non molto tempo dopo, ho avuto la possibilità di unirmi a MTS e sono finito tra le prime persone nel team di sviluppo del software di dinamica dei veicoli MTS. Ci occupavamo solo di RPC.
D: Com'era l'RPC a quel tempo?
R: Ovviamente molto diverso da come è oggi. Era un'interfaccia di domande e risposte senza spunti grafici. Stavamo lavorando in MTS BASIC su schermi verdi. Per studiare la trama di una funzione di risposta in frequenza completa, abbiamo dovuto stampare una matrice di carta di 24 fogli di larghezza per 24 fogli di altezza e adagiarli tutti insieme sul pavimento. Indicheremmo i vari elementi di questa gigantesca matrice di grafici con un bastoncino (sì, un vero bastoncino) e rifletteremo sui dettagli, chiedendoci perché il modello matematico ci dava o meno una risposta praticabile e interpretandolo come una radiografia. Mi riferisco spesso alla funzione di risposta in frequenza, o FRF, come una radiografia del comportamento dinamico di un sistema.
D: Come ha reagito l'industria alle capacità del software?
R: Per la prima volta, gli ingegneri di test hanno potuto ricreare un ambiente di carico realistico in laboratorio. Il metodo non ha compromesso la dinamica del sistema. Ha fornito il caricamento corretto attraverso una struttura dinamica complessa, come un sistema di sospensione. Ciò è stato possibile grazie al metodo RPC e al software. Inoltre, stavano rapidamente diventando disponibili computer che disponevano della potenza di elaborazione necessaria per eseguire i calcoli richiesti per creare drive file in un lasso di tempo realistico. Abbiamo anche sviluppato metodi per dotare i veicoli di estensimetri sugli assi e di sensori di spostamento per misurare il movimento verticale con l'intento di acquisire ogni sfumatura della risposta dinamica. Abbiamo iniziato a vendere simulatori stradali MTS dotati del software RPC. A quel tempo, il codice sorgente si è evoluto con ogni installazione. A metà degli anni '80 RPC era diventato globale, il che era notevole considerando che aveva meno di 10 anni.
D: Quando è stato formato il primo gruppo di utenti RPC?
R: Era il 1980 circa. Gli stessi utenti del software RPC hanno organizzato il primo incontro per scambiarsi idee ed esperienze. È stata davvero un'iniziativa partita dal basso. MTS ha contribuito a supportare quel primo incontro a Detroit e l'affluenza è stata grandiosa. Nonostante fossero concorrenti, i partecipanti di diversi OEM hanno trovato un modo per riunirsi e concentrarsi sul progresso della scienza e su come affrontare le sfide comuni. Hanno presentato le intuizioni che avevano acquisito utilizzando RPC, le tecniche che avevano sviluppato e gli elenchi di ciò che volevano che il software facesse. Come lo stesso RPC, i gruppi di utenti hanno preso piede rapidamente. Oggi, MTS organizza riunioni di gruppo di utenti RPC su base biennale per gli utenti in Nord America, Europa, Giappone, Corea, Cina, Brasile e India.
D: La popolarità di RPC ha cambiato il modo in cui MTS ha servito il settore?
R: Sì, ha attirato diverse persone a MTS che si sono dedicate alla risoluzione dei problemi per cui RPC è stato creato. Ecco perché ho partecipato. Ha anche portato persone di talento come Dave Holub, Peter Gunness e Dave Fricke, che ha studiato l'RPC da manuale da giovane ingegnere. Dave ha sviluppato nuovi metodi di modellazione degli pneumatici prima di imbattersi nell'idea di Hybrid System Response Convergence, o HSRC, per avvicinarsi più di chiunque altro alla soluzione della sfida della simulazione stradale.
D: Qual è la sfida della simulazione stradale?
R: L'abbiamo sempre chiamata simulazione stradale RPC - e lo facciamo ancora - ma in realtà è la replica di una risposta misurata sul campo in laboratorio. Gli input dalla strada sono diversi dall'output sul perno del veicolo di prova perché c'è uno pneumatico tra di loro. Non possiamo misurare cosa sta facendo il fondo del pneumatico, quindi usiamo il metodo RPC per colmare il divario. Simulare veramente la strada, o "portare la strada in laboratorio", sarebbe la svolta definitiva nei test fisici.
D: Qual è il vantaggio di portare la strada in laboratorio?
R: C'è un'enorme pressione nel settore per accelerare e ottimizzare lo sviluppo dei veicoli. La generazione di un drive file con il processo RPC richiede che tu raccolga prima i dati del carico stradale sulla pista di prova utilizzando un prototipo completo e completamente strumentato, in genere uno dei quattro che arrivano a scaglioni nel corso di un ciclo di sviluppo del veicolo di due anni. Quando hai finito di testare con i dati del prototipo finale, il produttore ha già costruito gli strumenti per stampare le parti e i pannelli per la produzione. In altre parole, è davvero in ritardo rispetto al processo complessivo e sarebbe estremamente costoso rielaborare il design se i test rivelassero eventuali difetti. Considerata la richiesta di programmi di sviluppo sempre più brevi, c'è una spinta molto forte per portare la strada in laboratorio e consentire test realistici simili a RPC non appena i primi componenti e sistemi del prototipo diventano disponibili. Evitare di acquisire del tutto i dati sul carico stradale sarebbe un vantaggio significativo perché potresti iniziare a migliorare i progetti senza un prototipo di veicolo funzionante.
D: Abbiamo una vera simulazione stradale?
R: Sì. Stiamo portando la strada in laboratorio con il metodo HSRC. Inizia con una versione digitalizzata effettiva della superficie stradale del terreno di prova, che è una sorta di JPEG molto grande della strada dove invece del colore, i pixel rappresentano l'altezza dei ciottoli. L'essenza di una soluzione ibrida è combinare una parte fisica - in questo caso un'auto reale su un vero simulatore di strada - e una parte virtuale, o uno pneumatico matematico in grado di essere "guidato" sulla scansione digitale della strada. Con HSRC, le forze e i movimenti del mozzo della ruota fisico e le forze e i movimenti dello pneumatico virtuale sono combinati al fine di preservare l'elemento di presenza. In altre parole, il veicolo fisico sente la presenza dello pneumatico virtuale e lo pneumatico virtuale sente la presenza del veicolo fisico. HSRC utilizza sia la tecnologia FRF inversa che le strategie iterative di RPC per realizzare un'accurata realizzazione del carico stradale sul veicolo senza dover acquisire dati sul carico stradale. E tutto si svolge in laboratorio, senza un prototipo completo.
D: Visto il potenziale di HSRC, l'RPC diventerà meno importante?
R: No, assolutamente. RPC rimarrà fondamentale per una serie di applicazioni. L'acquisizione dei dati sul campo non passerà mai di moda, anche se potrebbe diventare meno frequente. Grazie alla capacità di portare la strada in laboratorio, possiamo acquisire dati su componenti e sottosistemi direttamente da un test HSRC a veicolo completo. I dati risultanti possono essere utilizzati per eseguire ulteriori test su componenti e sottosistemi utilizzando il metodo RPC. Inoltre, il software RPC può elaborare ulteriormente i dati acquisiti in laboratorio per sviluppare test di cicli casuali e a blocchi in modo più efficiente. E non dimentichiamo che il metodo RPC è ideale per i produttori di componenti e sottosistemi che utilizzano i dati forniti dall'OEM. Detto questo, rimane uno dei modi più affidabili per eseguire test di durata accurati.
D: MTS continuerà a supportare metodi e strumenti RPC?
R: Assolutamente. I continui investimenti in strumenti RPC ci consentiranno di sfruttare appieno il vantaggio di portare la strada in laboratorio. Il software RPC fornisce gli strumenti di analisi del segnale e di visualizzazione necessari per implementare nuove idee di test e correlazione. Questi strumenti diventeranno ancora più importanti con l'evoluzione delle applicazioni HSRC. Stiamo sviluppando metodi per "vedere" la strada digitale e visualizzare gli pneumatici su quella strada, in modo da poter capire l'aspetto del sistema fisico/virtuale nel suo insieme. Continueremo inoltre a utilizzare RPC per capire come applicare l'analisi dei danni da fatica durante la convalida dei test HSRC e la valutazione dell'accuratezza. Anche se abbiamo portato la strada in laboratorio, c'è ancora molto da fare per ridurre i tempi di test, migliorare la precisione e fornire risultati di test attuabili. Tutto ciò richiede il miglioramento continuo e l'avanzamento degli strumenti e dei metodi RPC.
R: Il concetto iniziale era migliorare i dati dei test replicando il comportamento misurato sul campo in un ambiente di laboratorio controllato e ripetibile. Tutto è iniziato a metà degli anni '70 con Paul Nawrocke di GM e il Dr. Richard Lund di MTS. MTS aveva recentemente introdotto i sistemi di prova servoidraulici, i primi simulatori stradali a quattro poster. L'idea era che se si fosse riusciti a far muovere l'attuatore come la strada, sarebbe stato possibile testare i veicoli in laboratorio anziché sul campo. Per acquisire i dati relativi al carico su strada, gli ingegneri di test OEM hanno registrato su nastro i segnali provenienti dagli accelerometri fissati alle ruote di un'auto guidata su un terreno di prova. Le registrazioni sono state quindi riprodotte in un computer analogico, che ha trasformato le accelerazioni in profili di spostamento, che sono stati inviati a un servocontroller che esegue gli attuatori di prova. Quello era il primo drive file.
D: Era una soluzione praticabile per testare i veicoli in laboratorio anziché sul campo?
R: No. Il processo di doppia integrazione dell'accelerazione e di utilizzo come segnale di programmazione per l'azionamento dell'attuatore presentava una serie di difetti. Il metodo non comprendeva il comportamento intrinseco del servocontroller, né l'ancor più complesso comportamento dinamico dell'interazione del pneumatico con il manto stradale, e successivamente il piatto del simulatore accoppiato al pneumatico. Nawrocke e il dottor Lund hanno concluso che se fossero riusciti a sviluppare un modello matematico di queste interazioni, sarebbe stato possibile prevedere un drive file migliore e utilizzarlo in modo iterativo per perfezionare la soluzione prevista. Abilitata da nuovi computer digitali in grado di eseguire calcoli matematici, l'idea della correzione della funzione di risposta in frequenza inversa è stata perfezionata, diventando un metodo e una suite di software applicativo chiamato Remote Parameter Control, o RPC. Remoto significa che un sensore su un sistema dinamico può essere controllato quando è distante, o remoto, dall'attuatore che fornisce il movimento. In altre parole, stiamo controllando un accelerometro montato su un asse mentre l'attuatore è lontano dal punto in cui la gomma incontra la strada o quella che ora chiamiamo la zona di contatto del pneumatico.
D: Quando sei stato coinvolto per la prima volta nello sviluppo del software RPC?
R: Ero alla Ford per eseguire i test di accettazione in fabbrica utilizzando RPC, quello che oggi chiameremmo "RPC Zero". Era la prima volta che l'RPC veniva applicato a una macchina rotante e il team di MTS si rese subito conto che era necessaria una maggiore potenza di elaborazione per calcolare i drive file. Per farlo funzionare serviva un processore array che costava 34.000 dollari nel 1978. È stato allora che ho incontrato il team MTS e mi sono innamorato dell'azienda. Non molto tempo dopo, ho avuto la possibilità di unirmi a MTS e sono finito tra le prime persone nel team di sviluppo del software di dinamica dei veicoli MTS. Ci occupavamo solo di RPC.
D: Com'era l'RPC a quel tempo?
R: Ovviamente molto diverso da come è oggi. Era un'interfaccia di domande e risposte senza spunti grafici. Stavamo lavorando in MTS BASIC su schermi verdi. Per studiare la trama di una funzione di risposta in frequenza completa, abbiamo dovuto stampare una matrice di carta di 24 fogli di larghezza per 24 fogli di altezza e adagiarli tutti insieme sul pavimento. Indicheremmo i vari elementi di questa gigantesca matrice di grafici con un bastoncino (sì, un vero bastoncino) e rifletteremo sui dettagli, chiedendoci perché il modello matematico ci dava o meno una risposta praticabile e interpretandolo come una radiografia. Mi riferisco spesso alla funzione di risposta in frequenza, o FRF, come una radiografia del comportamento dinamico di un sistema.
D: Come ha reagito l'industria alle capacità del software?
R: Per la prima volta, gli ingegneri di test hanno potuto ricreare un ambiente di carico realistico in laboratorio. Il metodo non ha compromesso la dinamica del sistema. Ha fornito il caricamento corretto attraverso una struttura dinamica complessa, come un sistema di sospensione. Ciò è stato possibile grazie al metodo RPC e al software. Inoltre, stavano rapidamente diventando disponibili computer che disponevano della potenza di elaborazione necessaria per eseguire i calcoli richiesti per creare drive file in un lasso di tempo realistico. Abbiamo anche sviluppato metodi per dotare i veicoli di estensimetri sugli assi e di sensori di spostamento per misurare il movimento verticale con l'intento di acquisire ogni sfumatura della risposta dinamica. Abbiamo iniziato a vendere simulatori stradali MTS dotati del software RPC. A quel tempo, il codice sorgente si è evoluto con ogni installazione. A metà degli anni '80 RPC era diventato globale, il che era notevole considerando che aveva meno di 10 anni.
D: Quando è stato formato il primo gruppo di utenti RPC?
R: Era il 1980 circa. Gli stessi utenti del software RPC hanno organizzato il primo incontro per scambiarsi idee ed esperienze. È stata davvero un'iniziativa partita dal basso. MTS ha contribuito a supportare quel primo incontro a Detroit e l'affluenza è stata grandiosa. Nonostante fossero concorrenti, i partecipanti di diversi OEM hanno trovato un modo per riunirsi e concentrarsi sul progresso della scienza e su come affrontare le sfide comuni. Hanno presentato le intuizioni che avevano acquisito utilizzando RPC, le tecniche che avevano sviluppato e gli elenchi di ciò che volevano che il software facesse. Come lo stesso RPC, i gruppi di utenti hanno preso piede rapidamente. Oggi, MTS organizza riunioni di gruppo di utenti RPC su base biennale per gli utenti in Nord America, Europa, Giappone, Corea, Cina, Brasile e India.
D: La popolarità di RPC ha cambiato il modo in cui MTS ha servito il settore?
R: Sì, ha attirato diverse persone a MTS che si sono dedicate alla risoluzione dei problemi per cui RPC è stato creato. Ecco perché ho partecipato. Ha anche portato persone di talento come Dave Holub, Peter Gunness e Dave Fricke, che ha studiato l'RPC da manuale da giovane ingegnere. Dave ha sviluppato nuovi metodi di modellazione degli pneumatici prima di imbattersi nell'idea di Hybrid System Response Convergence, o HSRC, per avvicinarsi più di chiunque altro alla soluzione della sfida della simulazione stradale.
D: Qual è la sfida della simulazione stradale?
R: L'abbiamo sempre chiamata simulazione stradale RPC - e lo facciamo ancora - ma in realtà è la replica di una risposta misurata sul campo in laboratorio. Gli input dalla strada sono diversi dall'output sul perno del veicolo di prova perché c'è uno pneumatico tra di loro. Non possiamo misurare cosa sta facendo il fondo del pneumatico, quindi usiamo il metodo RPC per colmare il divario. Simulare veramente la strada, o "portare la strada in laboratorio", sarebbe la svolta definitiva nei test fisici.
D: Qual è il vantaggio di portare la strada in laboratorio?
R: C'è un'enorme pressione nel settore per accelerare e ottimizzare lo sviluppo dei veicoli. La generazione di un drive file con il processo RPC richiede che tu raccolga prima i dati del carico stradale sulla pista di prova utilizzando un prototipo completo e completamente strumentato, in genere uno dei quattro che arrivano a scaglioni nel corso di un ciclo di sviluppo del veicolo di due anni. Quando hai finito di testare con i dati del prototipo finale, il produttore ha già costruito gli strumenti per stampare le parti e i pannelli per la produzione. In altre parole, è davvero in ritardo rispetto al processo complessivo e sarebbe estremamente costoso rielaborare il design se i test rivelassero eventuali difetti. Considerata la richiesta di programmi di sviluppo sempre più brevi, c'è una spinta molto forte per portare la strada in laboratorio e consentire test realistici simili a RPC non appena i primi componenti e sistemi del prototipo diventano disponibili. Evitare di acquisire del tutto i dati sul carico stradale sarebbe un vantaggio significativo perché potresti iniziare a migliorare i progetti senza un prototipo di veicolo funzionante.
D: Abbiamo una vera simulazione stradale?
R: Sì. Stiamo portando la strada in laboratorio con il metodo HSRC. Inizia con una versione digitalizzata effettiva della superficie stradale del terreno di prova, che è una sorta di JPEG molto grande della strada dove invece del colore, i pixel rappresentano l'altezza dei ciottoli. L'essenza di una soluzione ibrida è combinare una parte fisica - in questo caso un'auto reale su un vero simulatore di strada - e una parte virtuale, o uno pneumatico matematico in grado di essere "guidato" sulla scansione digitale della strada. Con HSRC, le forze e i movimenti del mozzo della ruota fisico e le forze e i movimenti dello pneumatico virtuale sono combinati al fine di preservare l'elemento di presenza. In altre parole, il veicolo fisico sente la presenza dello pneumatico virtuale e lo pneumatico virtuale sente la presenza del veicolo fisico. HSRC utilizza sia la tecnologia FRF inversa che le strategie iterative di RPC per realizzare un'accurata realizzazione del carico stradale sul veicolo senza dover acquisire dati sul carico stradale. E tutto si svolge in laboratorio, senza un prototipo completo.
D: Visto il potenziale di HSRC, l'RPC diventerà meno importante?
R: No, assolutamente. RPC rimarrà fondamentale per una serie di applicazioni. L'acquisizione dei dati sul campo non passerà mai di moda, anche se potrebbe diventare meno frequente. Grazie alla capacità di portare la strada in laboratorio, possiamo acquisire dati su componenti e sottosistemi direttamente da un test HSRC a veicolo completo. I dati risultanti possono essere utilizzati per eseguire ulteriori test su componenti e sottosistemi utilizzando il metodo RPC. Inoltre, il software RPC può elaborare ulteriormente i dati acquisiti in laboratorio per sviluppare test di cicli casuali e a blocchi in modo più efficiente. E non dimentichiamo che il metodo RPC è ideale per i produttori di componenti e sottosistemi che utilizzano i dati forniti dall'OEM. Detto questo, rimane uno dei modi più affidabili per eseguire test di durata accurati.
D: MTS continuerà a supportare metodi e strumenti RPC?
R: Assolutamente. I continui investimenti in strumenti RPC ci consentiranno di sfruttare appieno il vantaggio di portare la strada in laboratorio. Il software RPC fornisce gli strumenti di analisi del segnale e di visualizzazione necessari per implementare nuove idee di test e correlazione. Questi strumenti diventeranno ancora più importanti con l'evoluzione delle applicazioni HSRC. Stiamo sviluppando metodi per "vedere" la strada digitale e visualizzare gli pneumatici su quella strada, in modo da poter capire l'aspetto del sistema fisico/virtuale nel suo insieme. Continueremo inoltre a utilizzare RPC per capire come applicare l'analisi dei danni da fatica durante la convalida dei test HSRC e la valutazione dell'accuratezza. Anche se abbiamo portato la strada in laboratorio, c'è ancora molto da fare per ridurre i tempi di test, migliorare la precisione e fornire risultati di test attuabili. Tutto ciò richiede il miglioramento continuo e l'avanzamento degli strumenti e dei metodi RPC.
