P: Como e por que o Software RPC foi desenvolvido?
R: O conceito inicial era melhorar os dados de teste replicando o comportamento medido em campo, mas em um ambiente de laboratório controlado e repetível. Isso começou em meados da década de 1970 com Paul Nawrocke da GM e o Dr. Richard Lund da MTS. A MTS havia apresentado recentemente sistemas de teste servo-hidráulico - os primeiros simuladores de estrada de quatro hastes. A ideia era, se você pudesse fazer o atuador mover-se como a estrada, você poderia testar veículos no laboratório ao invés de fazê-lo no campo. Para capturar dados de carga na estrada, os engenheiros de testes OEM fizeram um registro em fita dos sinais dos acelerômetros fixados às rodas de um carro sendo conduzido sobre um campo de provas. As gravações foram então reproduzidas em um computador analógico, que transformou as acelerações em perfis de deslocamento, que foram alimentados por um servocontrolador que movimentava os atuadores de teste. Esse foi o primeiro arquivo de unidade.
P: Foi uma solução viável para testar veículos no laboratório em vez de fazê-lo no campo?
R: Não. O processo de dupla aceleração integradora e sua utilização como sinal de programação para o acionamento do atuador teve uma série de falhas. O método não compreendia o comportamento intrínseco do servocontrolador, nem o comportamento dinâmico ainda mais complexo da interação do pneu com a superfície da estrada e, subsequentemente, a superfície plana do simulador acoplado ao pneu. Nawrocke e o Dr. Lund concluíram que se eles pudessem desenvolver um modelo matemático dessas interações, ele poderia prever um arquivo de unidade melhor e ser usado de forma iterativa para ajustar a solução prevista. Habilitado pelos novos computadores digitais capazes de fazer as contas, a ideia da correção da função de resposta de frequência inversa foi ajustada, tornando-se um método e um conjunto de software aplicativo chamado Remote Parameter Control, ou RPC. Remoto significa que um sensor em um sistema dinâmico pode ser controlado quando ele está distante, ou remoto, do atuador que fornece o movimento. Em outras palavras, estamos controlando um acelerômetro montado em um eixo enquanto o atuador está distante do ponto em que a borracha se encontra com a estrada ou o que agora chamamos de patch de contato do pneu.
P: Quando você se envolveu pela primeira vez com o software RPC?
R: Eu estava na Ford fazendo testes de aceitação de fábrica usando o RPC, que chamaríamos hoje de "RPC Zero" Foi a primeira vez que o RPC foi aplicado a uma máquina rotativa e a equipe MTS rapidamente percebeu que era necessário mais poder de processamento para computar os arquivos de unidade. Eventualmente, foi necessário um processador de matriz que custou $34.000 em 1978 para que ele funcionasse. Foi quando conheci a equipe da MTS e me apaixonei pela empresa. Pouco tempo depois, tive a oportunidade de me juntar à MTS e acabei entre as primeiras pessoas da equipe de desenvolvimento de software de dinâmica veicular da MTS. O RPC era todo o nosso trabalho.
P: Como era o RPC naquela época?
R: Muito diferente do que é hoje, é claro. Era uma interface de perguntas e respostas sem indicações gráficas. Estávamos trabalhando na MTS BASIC em telas verdes. Para estudara plotagem de uma função de resposta de frequência completa, tivemos que imprimir uma matriz de 24 folhas de largura por 24 folhas de altura e colocá-las todas juntas no chão. Apontamos vários elementos desta matriz gigante de gráficos com um bastão (sim, um bastão real) e ponderamos os detalhes, perguntando-nos por que o modelo matemático estava ou não nos dando uma resposta funcional e o interpretando como um raio-x. Muitas vezes me refiro à Função de Resposta em Frequência, ou FRF, como um raio-x do comportamento dinâmico de um sistema.
P: Como a indústria reagiu às capacidades do software?
R: Pela primeira vez, engenheiros de teste puderam recriar um ambiente de carga realista no laboratório. O método não comprometeu a dinâmica do sistema. Proporcionou uma carga correta em toda uma estrutura dinâmica complexa, como um sistema de suspensão. O método e o software RPC tornaram isso possível. Além disso, computadores que tinham o poder de processamento para realizar os cálculos para criar arquivos de unidade em um tempo realista estavam rapidamente se tornando disponíveis. Também desenvolvemos métodos de instrumentação de veículos com medidores de pressão nos eixos e sensores de deslocamento para medir o movimento vertical com a intenção de capturar cada nuance da resposta dinâmica. Começamos a vender simuladores de estrada MTS com software RPC. Naquela época, o código fonte evoluía a cada instalação. Em meados dos anos 80, o RPC tinha se tornado mundial, o que era notável considerando que tinha menos de 10 anos de idade.
P: Quando foi formado o primeiro grupo de usuários do RPC?
R: Foi por volta de 1980. Os próprios usuários do software RPC organizaram a primeira reunião para trocar ideias e experiências. Foi realmente um esforço das bases. A MTS ajudou a apoiar aquela primeira reunião em Detroit e a participação foi ótima. Apesar de serem concorrentes, os participantes de diferentes OEMs encontraram uma maneira de se reunirem e se concentrarem no avanço da ciência e na abordagem de desafios comuns. Eles apresentaram insights que tinham adquirido usando RPC, técnicas que tinham desenvolvido e listas de desejos sobre o que queriam que o software fizesse. Assim como o próprio RPC, os grupos de usuários rapidamente se tornaram "populares". Hoje, a MTS realiza reuniões bianuais do grupo de usuários RPC para usuários na América do Norte, Europa, Japão, Coreia, China, Brasil e Índia.
P: A popularidade da RPC mudou a forma como a MTS atendeu à indústria?
R: Sim, atraiu várias pessoas para a MTS que se dedicaram a resolver os problemas que o RPC foi feito para resolver. Foi por isso que eu me associei. Também trouxe pessoas talentosas como Dave Holub, Peter Gunness e Dave Fricke que aprenderam RPC em livros como jovens engenheiros. Dave desenvolveu novos métodos de modelagem de pneus antes de se lançar na ideia da Convergência de Resposta do Sistema Híbrido, ou HSRC, para se aproximar, mais do que ninguém, da solução do desafio da simulação da estrada.
P: Qual é o desafio da simulação de estrada?
R: Sempre chamamos de simulação de estrada RPC - e ainda chamamos - mas na verdade é a replicação de uma resposta medida em campo no laboratório. As entradas da estrada são diferentes da saída do fuso do veículo de teste porque há um pneu no meio deles. Não podemos medir o que o fundo do pneu está fazendo, então usamos o método RPC para preencher a lacuna. Simular verdadeiramente a estrada, ou "trazer a estrada para o laboratório", seria a última novidade em testes físicos.
P: Qual é a vantagem de trazer a estrada para o laboratório?
R: Há uma tremenda pressão na indústria para acelerar e agilizar o desenvolvimento de veículos. A geração de um arquivo de unidade com o processo RPC exige que, primeiro, você colete dados de carga na pista de teste usando um protótipo completo e totalmente instrumentado, normalmente um de, talvez, quatro que chegam em etapas ao longo de um ciclo de desenvolvimento de dois anos do veículo. Quando você terminar os testes com os dados do protótipo final, o fabricante já terá construído as ferramentas para estampar as peças e painéis para a produção. Em outras palavras, está realmente tarde no jogo e seria extremamente caro retrabalhar o projeto caso os testes revelassem quaisquer falhas. Dada a pressão por prazos de desenvolvimento cada vez mais curtos, há uma força muito forte para trazer a estrada para o laboratório e permitir testes realistas do tipo RPC assim que as primeiras peças e sistemas protótipos estiverem disponíveis. Evitar completamente a aquisição de dados de carga nas estradas seria uma vantagem significativa, pois você poderia começar a melhorar os projetos sem um protótipo de veículo em funcionamento.
P: Temos alguma simulação de estrada real?
R: Sim. Na verdade, estamos trazendo a estrada para o laboratório com o método HSRC. Ele começa com uma versão digitalizada real da superfície da estrada, que é uma espécie de JPEG muito grande da estrada onde, em vez de cor, os pixels representam a altura das pedrinhas. A essência de uma solução híbrida é combinar uma parte física - neste caso um carro real em um simulador de estrada real - e uma parte virtual, ou um pneu matemático capaz de ser "conduzido" sobre o scan digital da estrada. Com o HSRC, as forças e movimentos da central física da roda e as forças e movimentos do pneu virtual são combinados para preservar o elemento de presença. Em outras palavras, o veículo físico sente a presença do pneu virtual e o pneu virtual sente a presença do veículo físico. O HSRC utiliza tanto a tecnologia FRF inversa quanto as estratégias iterativas do RPC para realizar uma realização precisa da carga rodoviária no veículo sem a necessidade de adquirir dados de carga rodoviária. E tudo isso acontece no laboratório, sem um protótipo completo.
P: Dado o potencial do HSRC, será que o RPC se tornará menos importante?
R: Não, de forma alguma. O RPC continuará sendo fundamental para uma série de aplicações. A aquisição de dados de campo nunca sairá de moda, embora possa se tornar menos frequente. Com a capacidade de trazer a estrada para o laboratório, podemos adquirir dados sobre componentes e subsistemas diretamente de um teste HSRC para veículos completos. Os dados resultantes podem ser usados para realizar testes adicionais em componentes e subsistemas usando o método RPC. Além disso, o software RPC pode processar ainda mais os dados adquiridos no laboratório para desenvolver testes de ciclo aleatórios e de bloqueio de forma mais eficiente. E não podemos esquecer que o método RPC é ideal para fabricantes de componentes e subsistemas que utilizam dados fornecidos pela OEM. Continua sendo uma das formas mais confiáveis de realizar testes de durabilidade precisos.
P: A MTS continuará a apoiar os métodos e ferramentas de RPC?
R: Com certeza. O investimento contínuo em ferramentas de RPC nos permitirá realizar o benefício total de trazer a estrada para o laboratório. O software RPC fornece as ferramentas de análise e visualização de sinais necessárias para implementar novos testes e ideias de correlação. Estas ferramentas se tornarão ainda mais importantes à medida que as aplicações HSRC evoluírem. Estamos desenvolvendo métodos para "ver" a estrada digital e visualizar os pneus naquela estrada, para que possamos entender como o sistema físico/virtual se parece como um todo. Também continuaremos a usar o RPC para aprender como aplicar a análise de danos por fadiga durante a validação do teste HSRC e a avaliação da precisão. Podemos ter trazido a estrada para o laboratório, mas ainda há muito a fazer no que diz respeito à redução do tempo de teste, à melhoria da precisão e à entrega de resultados de teste acionáveis. Tudo isso exige melhoria contínua e o avanço das ferramentas e métodos de RPC.
R: O conceito inicial era melhorar os dados de teste replicando o comportamento medido em campo, mas em um ambiente de laboratório controlado e repetível. Isso começou em meados da década de 1970 com Paul Nawrocke da GM e o Dr. Richard Lund da MTS. A MTS havia apresentado recentemente sistemas de teste servo-hidráulico - os primeiros simuladores de estrada de quatro hastes. A ideia era, se você pudesse fazer o atuador mover-se como a estrada, você poderia testar veículos no laboratório ao invés de fazê-lo no campo. Para capturar dados de carga na estrada, os engenheiros de testes OEM fizeram um registro em fita dos sinais dos acelerômetros fixados às rodas de um carro sendo conduzido sobre um campo de provas. As gravações foram então reproduzidas em um computador analógico, que transformou as acelerações em perfis de deslocamento, que foram alimentados por um servocontrolador que movimentava os atuadores de teste. Esse foi o primeiro arquivo de unidade.
P: Foi uma solução viável para testar veículos no laboratório em vez de fazê-lo no campo?
R: Não. O processo de dupla aceleração integradora e sua utilização como sinal de programação para o acionamento do atuador teve uma série de falhas. O método não compreendia o comportamento intrínseco do servocontrolador, nem o comportamento dinâmico ainda mais complexo da interação do pneu com a superfície da estrada e, subsequentemente, a superfície plana do simulador acoplado ao pneu. Nawrocke e o Dr. Lund concluíram que se eles pudessem desenvolver um modelo matemático dessas interações, ele poderia prever um arquivo de unidade melhor e ser usado de forma iterativa para ajustar a solução prevista. Habilitado pelos novos computadores digitais capazes de fazer as contas, a ideia da correção da função de resposta de frequência inversa foi ajustada, tornando-se um método e um conjunto de software aplicativo chamado Remote Parameter Control, ou RPC. Remoto significa que um sensor em um sistema dinâmico pode ser controlado quando ele está distante, ou remoto, do atuador que fornece o movimento. Em outras palavras, estamos controlando um acelerômetro montado em um eixo enquanto o atuador está distante do ponto em que a borracha se encontra com a estrada ou o que agora chamamos de patch de contato do pneu.
P: Quando você se envolveu pela primeira vez com o software RPC?
R: Eu estava na Ford fazendo testes de aceitação de fábrica usando o RPC, que chamaríamos hoje de "RPC Zero" Foi a primeira vez que o RPC foi aplicado a uma máquina rotativa e a equipe MTS rapidamente percebeu que era necessário mais poder de processamento para computar os arquivos de unidade. Eventualmente, foi necessário um processador de matriz que custou $34.000 em 1978 para que ele funcionasse. Foi quando conheci a equipe da MTS e me apaixonei pela empresa. Pouco tempo depois, tive a oportunidade de me juntar à MTS e acabei entre as primeiras pessoas da equipe de desenvolvimento de software de dinâmica veicular da MTS. O RPC era todo o nosso trabalho.
P: Como era o RPC naquela época?
R: Muito diferente do que é hoje, é claro. Era uma interface de perguntas e respostas sem indicações gráficas. Estávamos trabalhando na MTS BASIC em telas verdes. Para estudara plotagem de uma função de resposta de frequência completa, tivemos que imprimir uma matriz de 24 folhas de largura por 24 folhas de altura e colocá-las todas juntas no chão. Apontamos vários elementos desta matriz gigante de gráficos com um bastão (sim, um bastão real) e ponderamos os detalhes, perguntando-nos por que o modelo matemático estava ou não nos dando uma resposta funcional e o interpretando como um raio-x. Muitas vezes me refiro à Função de Resposta em Frequência, ou FRF, como um raio-x do comportamento dinâmico de um sistema.
P: Como a indústria reagiu às capacidades do software?
R: Pela primeira vez, engenheiros de teste puderam recriar um ambiente de carga realista no laboratório. O método não comprometeu a dinâmica do sistema. Proporcionou uma carga correta em toda uma estrutura dinâmica complexa, como um sistema de suspensão. O método e o software RPC tornaram isso possível. Além disso, computadores que tinham o poder de processamento para realizar os cálculos para criar arquivos de unidade em um tempo realista estavam rapidamente se tornando disponíveis. Também desenvolvemos métodos de instrumentação de veículos com medidores de pressão nos eixos e sensores de deslocamento para medir o movimento vertical com a intenção de capturar cada nuance da resposta dinâmica. Começamos a vender simuladores de estrada MTS com software RPC. Naquela época, o código fonte evoluía a cada instalação. Em meados dos anos 80, o RPC tinha se tornado mundial, o que era notável considerando que tinha menos de 10 anos de idade.
P: Quando foi formado o primeiro grupo de usuários do RPC?
R: Foi por volta de 1980. Os próprios usuários do software RPC organizaram a primeira reunião para trocar ideias e experiências. Foi realmente um esforço das bases. A MTS ajudou a apoiar aquela primeira reunião em Detroit e a participação foi ótima. Apesar de serem concorrentes, os participantes de diferentes OEMs encontraram uma maneira de se reunirem e se concentrarem no avanço da ciência e na abordagem de desafios comuns. Eles apresentaram insights que tinham adquirido usando RPC, técnicas que tinham desenvolvido e listas de desejos sobre o que queriam que o software fizesse. Assim como o próprio RPC, os grupos de usuários rapidamente se tornaram "populares". Hoje, a MTS realiza reuniões bianuais do grupo de usuários RPC para usuários na América do Norte, Europa, Japão, Coreia, China, Brasil e Índia.
P: A popularidade da RPC mudou a forma como a MTS atendeu à indústria?
R: Sim, atraiu várias pessoas para a MTS que se dedicaram a resolver os problemas que o RPC foi feito para resolver. Foi por isso que eu me associei. Também trouxe pessoas talentosas como Dave Holub, Peter Gunness e Dave Fricke que aprenderam RPC em livros como jovens engenheiros. Dave desenvolveu novos métodos de modelagem de pneus antes de se lançar na ideia da Convergência de Resposta do Sistema Híbrido, ou HSRC, para se aproximar, mais do que ninguém, da solução do desafio da simulação da estrada.
P: Qual é o desafio da simulação de estrada?
R: Sempre chamamos de simulação de estrada RPC - e ainda chamamos - mas na verdade é a replicação de uma resposta medida em campo no laboratório. As entradas da estrada são diferentes da saída do fuso do veículo de teste porque há um pneu no meio deles. Não podemos medir o que o fundo do pneu está fazendo, então usamos o método RPC para preencher a lacuna. Simular verdadeiramente a estrada, ou "trazer a estrada para o laboratório", seria a última novidade em testes físicos.
P: Qual é a vantagem de trazer a estrada para o laboratório?
R: Há uma tremenda pressão na indústria para acelerar e agilizar o desenvolvimento de veículos. A geração de um arquivo de unidade com o processo RPC exige que, primeiro, você colete dados de carga na pista de teste usando um protótipo completo e totalmente instrumentado, normalmente um de, talvez, quatro que chegam em etapas ao longo de um ciclo de desenvolvimento de dois anos do veículo. Quando você terminar os testes com os dados do protótipo final, o fabricante já terá construído as ferramentas para estampar as peças e painéis para a produção. Em outras palavras, está realmente tarde no jogo e seria extremamente caro retrabalhar o projeto caso os testes revelassem quaisquer falhas. Dada a pressão por prazos de desenvolvimento cada vez mais curtos, há uma força muito forte para trazer a estrada para o laboratório e permitir testes realistas do tipo RPC assim que as primeiras peças e sistemas protótipos estiverem disponíveis. Evitar completamente a aquisição de dados de carga nas estradas seria uma vantagem significativa, pois você poderia começar a melhorar os projetos sem um protótipo de veículo em funcionamento.
P: Temos alguma simulação de estrada real?
R: Sim. Na verdade, estamos trazendo a estrada para o laboratório com o método HSRC. Ele começa com uma versão digitalizada real da superfície da estrada, que é uma espécie de JPEG muito grande da estrada onde, em vez de cor, os pixels representam a altura das pedrinhas. A essência de uma solução híbrida é combinar uma parte física - neste caso um carro real em um simulador de estrada real - e uma parte virtual, ou um pneu matemático capaz de ser "conduzido" sobre o scan digital da estrada. Com o HSRC, as forças e movimentos da central física da roda e as forças e movimentos do pneu virtual são combinados para preservar o elemento de presença. Em outras palavras, o veículo físico sente a presença do pneu virtual e o pneu virtual sente a presença do veículo físico. O HSRC utiliza tanto a tecnologia FRF inversa quanto as estratégias iterativas do RPC para realizar uma realização precisa da carga rodoviária no veículo sem a necessidade de adquirir dados de carga rodoviária. E tudo isso acontece no laboratório, sem um protótipo completo.
P: Dado o potencial do HSRC, será que o RPC se tornará menos importante?
R: Não, de forma alguma. O RPC continuará sendo fundamental para uma série de aplicações. A aquisição de dados de campo nunca sairá de moda, embora possa se tornar menos frequente. Com a capacidade de trazer a estrada para o laboratório, podemos adquirir dados sobre componentes e subsistemas diretamente de um teste HSRC para veículos completos. Os dados resultantes podem ser usados para realizar testes adicionais em componentes e subsistemas usando o método RPC. Além disso, o software RPC pode processar ainda mais os dados adquiridos no laboratório para desenvolver testes de ciclo aleatórios e de bloqueio de forma mais eficiente. E não podemos esquecer que o método RPC é ideal para fabricantes de componentes e subsistemas que utilizam dados fornecidos pela OEM. Continua sendo uma das formas mais confiáveis de realizar testes de durabilidade precisos.
P: A MTS continuará a apoiar os métodos e ferramentas de RPC?
R: Com certeza. O investimento contínuo em ferramentas de RPC nos permitirá realizar o benefício total de trazer a estrada para o laboratório. O software RPC fornece as ferramentas de análise e visualização de sinais necessárias para implementar novos testes e ideias de correlação. Estas ferramentas se tornarão ainda mais importantes à medida que as aplicações HSRC evoluírem. Estamos desenvolvendo métodos para "ver" a estrada digital e visualizar os pneus naquela estrada, para que possamos entender como o sistema físico/virtual se parece como um todo. Também continuaremos a usar o RPC para aprender como aplicar a análise de danos por fadiga durante a validação do teste HSRC e a avaliação da precisão. Podemos ter trazido a estrada para o laboratório, mas ainda há muito a fazer no que diz respeito à redução do tempo de teste, à melhoria da precisão e à entrega de resultados de teste acionáveis. Tudo isso exige melhoria contínua e o avanço das ferramentas e métodos de RPC.
