P: ¿Cómo y por qué se desarrolló el software RPC?
R: El concepto inicial era mejorar los datos de las pruebas replicando el comportamiento medido sobre el terreno en un entorno de laboratorio controlado y repetible. Comenzó a mediados de la década de 1970 con Paul Nawrocke de GM y el Dr. Richard Lund de MTS. MTS había introducido recientemente sistemas de prueba servohidráulicos: los primeros simuladores de carretera de cuatro postes. La idea era que si se podía hacer que el actuador se moviera como la carretera, se podrían probar los vehículos en el laboratorio en lugar de en el campo. Para capturar los datos de la carga de la carretera, los ingenieros de pruebas del OEM grabaron en cinta las señales de los acelerómetros colocados en las ruedas de un vehículo que circulaba por un campo de pruebas. Luego, las grabaciones se reprodujeron en una computadora analógica, que convirtió las aceleraciones en perfiles de desplazamiento, que se enviaron a un servocontrolador que ejecutaba los actuadores de prueba. Ese fue el primer archivo de conducción.
P: ¿Era una solución viable para probar los vehículos en el laboratorio en lugar de en el campo?
R: No. El proceso de integración doble de la aceleración y su utilización como señal de programación para el accionamiento del actuador tenía una serie de defectos. El método no comprendía el comportamiento intrínseco del servocontrolador, ni el comportamiento dinámico, aún más complejo, de la interacción del neumático con la superficie de la carretera y, por consiguiente, del plato plano del simulador acoplado al neumático. Nawrocke y el Dr. Lund llegaron a la conclusión de que si podían desarrollar un modelo matemático de estas interacciones, éste podría predecir un mejor archivo de conducción y utilizarse de forma iterativa para perfeccionar la solución prevista. Gracias a las nuevas computadoras digitales capaces de hacer los cálculos, la idea de la corrección de la función de respuesta de frecuencia inversa se perfeccionó, convirtiéndose en un método y en un conjunto de software de aplicación denominado Control Remoto de Parámetros, o RPC. Remoto significa que un sensor en un sistema dinámico se puede controlar cuando está distante o remoto del actuador que proporciona el movimiento. En otras palabras, estamos controlando un acelerómetro montado en un eje mientras que el actuador está alejado del punto en el que el caucho se encuentra con la carretera o lo que ahora denominamos la zona de contacto del neumático.
P: ¿Cuándo se involucró por primera vez con el software RPC?
R: Estuve en Ford haciendo pruebas de aceptación en fábrica utilizando RPC - lo que hoy consideraríamos como "RPC Cero". Era la primera vez que se aplicaba el RPC a una máquina rotativa y el equipo de MTS se dio cuenta rápidamente de que se necesitaba más potencia de procesamiento para calcular los archivos de conducción. Finalmente, se necesitó un procesador de matriz que costó $34.000 en 1978 para hacerlo funcionar. Fue entonces cuando conocí al equipo de MTS y me enamoré de la empresa. No mucho después, tuve la oportunidad de unirme a MTS y terminé entre las primeras personas en el equipo de desarrollo de software de dinámica de vehículos de MTS. El RPC era todo nuestro trabajo.
P: ¿Cómo era el RPC en ese momento?
R: Muy diferente de lo que es hoy, por supuesto. Era una interfaz de preguntas y respuestas sin pistas gráficas. Estábamos trabajando en MTS BASIC en pantallas verdes. Para estudiar el diagrama de una función de respuesta en frecuencia completa, tuvimos que imprimir una matriz de papel de 24 hojas de ancho por 24 de alto y colocarlas todas juntas en el suelo. Señalábamos varios elementos de esta gigantesca matriz de gráficos con un palo (sí, un palo de verdad) y reflexionábamos sobre los detalles, preguntándonos por qué el modelo matemático nos daba o no una respuesta viable y lo interpretábamos como una radiografía. A menudo me refiero a la función de respuesta de frecuencia, o FRF, como una radiografía del comportamiento dinámico de un sistema.
P: ¿Cómo reaccionó la industria a las capacidades del software?
R: Por primera vez, los ingenieros de pruebas pudieron recrear un entorno de carga realista en el laboratorio. El método no comprometió la dinámica del sistema. Proporcionó una carga correcta a través de una estructura dinámica compleja, como un sistema de suspensión. El método y el software RPC lo hicieron posible. Además, rápidamente empezaron a estar disponibles computadoras que tenían la capacidad de procesamiento para realizar los cálculos y crear archivos de conducción en una cantidad de tiempo realista. También desarrollamos métodos para equipar a los vehículos con bandas extensométricas en los ejes y sensores de desplazamiento para medir el movimiento vertical con la intención de captar todos los aspectos de la respuesta dinámica. Comenzamos a vender simuladores de carreteras MTS con software RPC. En ese momento, el código fuente evolucionó con cada instalación. A mediados de la década de 1980, RPC se había convertido en una empresa mundial, lo cual es extraordinario si se tiene en cuenta que tenía menos de 10 años.
P: ¿Cuándo se formó el primer grupo de usuarios de RPC?
R: Fue alrededor de 1980. Los propios usuarios del software RPC organizaron la primera reunión para intercambiar ideas y experiencias. Realmente fue un esfuerzo de base. MTS ayudó a organizar la primera reunión en Detroit y la participación fue muy excelente. A pesar de ser competidores, los asistentes de diferentes fabricantes de equipos originales encontraron una manera de unirse y concentrarse en hacer avanzar la ciencia y abordar retos comunes. Presentaron sus conocimientos sobre el uso de RPC, las técnicas que habían desarrollado y las listas de deseos de lo que querían que hiciera el software. Al igual que el propio RPC, los grupos de usuarios se popularizaron rápidamente. En la actualidad, MTS organiza reuniones bianuales del grupo de usuarios de RPC para usuarios de Norteamérica, Europa, Japón, Corea, China, Brasil e India.
P: ¿La popularidad de RPC cambió la forma en que MTS atendió a la industria?
R: Sí, incorporó a varias personas a MTS que se dedicaron a resolver los problemas para los que se creó el RPC. Por eso me uní. También incorporó a personas con talento como Dave Holub, Peter Gunness y Dave Fricke, quienes aprendieron el RPC siguiendo el libro cuando eran jóvenes ingenieros. Dave desarrolló nuevos métodos de modelado de neumáticos antes de concebir la idea de la Convergencia de Respuesta del Sistema Híbrido, o HSRC, para acercarse más que nadie a la solución del reto de la simulación de carreteras.
P: ¿Cuál es el reto de la simulación de carreteras?
R: Siempre la hemos llamado simulación de carreteras RPC, y todavía lo hacemos, pero en realidad es la réplica de una respuesta medida sobre el terreno en el laboratorio. Las entradas de la carretera son diferentes a la salida en el eje del vehículo de prueba porque hay un neumático entre ellos. No podemos medir lo que está haciendo la parte inferior del neumático, por lo que usamos el método RPC para cerrar la brecha. Simular verdaderamente la carretera, o "llevar la carretera al laboratorio", sería el gran avance en las pruebas físicos.
P: ¿Cuál es la ventaja de llevar la carretera al laboratorio?
R: Existe una tremenda presión en la industria para acelerar y optimizar el desarrollo de vehículos. La generación de un archivo de conducción con el proceso RPC requiere que primero se recojan los datos de carga de la carretera en la pista de pruebas utilizando un prototipo completo y totalmente instrumentado, que suele ser uno de los cuatro que llegan por etapas a lo largo de un ciclo de desarrollo del vehículo de dos años. Cuando se terminan las pruebas con los datos del prototipo final, el fabricante ya ha construido las herramientas para estampar las piezas y los paneles para la producción. En otras palabras, es realmente tarde en el proceso y sería extremadamente costoso rehacer el diseño en caso de que las pruebas revelen algún defecto. Ante la presión de calendarios de desarrollo cada vez más cortos, existe un gran interés por llevar la carretera al laboratorio y permitir la realización de pruebas realistas tipo RPC tan pronto como se disponga de los primeros prototipos de piezas y sistemas. Evitar por completo la adquisición de datos de carga en carretera sería una ventaja importante, ya que se podría empezar a mejorar los diseños sin un vehículo prototipo en funcionamiento.
P: ¿Tenemos alguna simulación real de carreteras?
R: Sí. De hecho, estamos llevando la carretera al laboratorio con el método HSRC. Comienza con una versión digitalizada real de la superficie de la carretera del campo de pruebas, que es una especie de JPEG muy grande de la carretera en la que, en lugar de color, los píxeles representan la altura del canto rodado. La esencia de una solución híbrida es combinar una pieza física, en este caso un vehículo real en un simulador de carretera real, y una pieza virtual, o un neumático matemático capaz de ser "conducido" sobre el escaneo digital de la carretera. Con el HSRC, las fuerzas y los movimientos del cubo de la rueda física y las fuerzas y los movimientos del neumático virtual se combinan para preservar el elemento de presencia. En otras palabras, el vehículo físico siente la presencia del neumático virtual y el neumático virtual siente la presencia del vehículo físico. El HSRC utiliza tanto la tecnología FRF inversa como las estrategias iterativas del RPC para conseguir una realización precisa de la carga de la carretera en el vehículo sin tener que adquirir datos de carga de la carretera. Y todo tiene lugar en el laboratorio, sin un prototipo completo.
P: Dado el potencial de HSRC, ¿el RPC será menos importante?
R: No, en absoluto. El RPC seguirá siendo fundamental para varias aplicaciones. La adquisición de datos de campo nunca pasará de moda, aunque puede volverse menos frecuente. Con la capacidad de llevar la carretera al laboratorio, podemos adquirir datos sobre componentes y subsistemas directamente a partir de un prueba HSRC del vehículo completo. Los datos resultantes se pueden utilizar para realizar pruebas adicionales en componentes y subsistemas utilizando el método RPC. Además, el software RPC puede procesar aún más los datos adquiridos en el laboratorio para desarrollar pruebas de ciclos aleatorios y de bloque de forma más eficiente. Y no olvidemos que el método RPC es ideal para los fabricantes de componentes y subsistemas que utilizan datos suministrados por el OEM. Sigue siendo una de las formas más confiables de realizar pruebas de durabilidad precisos.
P: ¿MTS seguirá admitiendo métodos y herramientas RPC?
R: Por supuesto. La inversión continua en herramientas RPC nos permitirá aprovechar todas las ventajas de llevar la carretera al laboratorio. El software RPC proporciona las herramientas de visualización y análisis de señales necesarias para implementar nuevas ideas de prueba y correlación. Estas herramientas serán aún más importantes a medida que evolucionen las aplicaciones de HSRC. Estamos desarrollando métodos para "ver" la carretera digital y visualizar los neumáticos en esa carretera, de modo que podamos entender cómo es el sistema físico/virtual en su conjunto. También seguiremos utilizando el RPC para aprender a aplicar el análisis de daños por fatiga durante la validación de las pruebas HSRC y la evaluación de la precisión. Puede que hayamos llevado la carretera al laboratorio, pero aún queda mucho por hacer en lo que respecta a la reducción del tiempo de las pruebas, la mejora de la precisión y la obtención de resultados procesables. Todo ello hace necesaria la mejora y el avance continuos de las herramientas y los métodos de RPC.
R: El concepto inicial era mejorar los datos de las pruebas replicando el comportamiento medido sobre el terreno en un entorno de laboratorio controlado y repetible. Comenzó a mediados de la década de 1970 con Paul Nawrocke de GM y el Dr. Richard Lund de MTS. MTS había introducido recientemente sistemas de prueba servohidráulicos: los primeros simuladores de carretera de cuatro postes. La idea era que si se podía hacer que el actuador se moviera como la carretera, se podrían probar los vehículos en el laboratorio en lugar de en el campo. Para capturar los datos de la carga de la carretera, los ingenieros de pruebas del OEM grabaron en cinta las señales de los acelerómetros colocados en las ruedas de un vehículo que circulaba por un campo de pruebas. Luego, las grabaciones se reprodujeron en una computadora analógica, que convirtió las aceleraciones en perfiles de desplazamiento, que se enviaron a un servocontrolador que ejecutaba los actuadores de prueba. Ese fue el primer archivo de conducción.
P: ¿Era una solución viable para probar los vehículos en el laboratorio en lugar de en el campo?
R: No. El proceso de integración doble de la aceleración y su utilización como señal de programación para el accionamiento del actuador tenía una serie de defectos. El método no comprendía el comportamiento intrínseco del servocontrolador, ni el comportamiento dinámico, aún más complejo, de la interacción del neumático con la superficie de la carretera y, por consiguiente, del plato plano del simulador acoplado al neumático. Nawrocke y el Dr. Lund llegaron a la conclusión de que si podían desarrollar un modelo matemático de estas interacciones, éste podría predecir un mejor archivo de conducción y utilizarse de forma iterativa para perfeccionar la solución prevista. Gracias a las nuevas computadoras digitales capaces de hacer los cálculos, la idea de la corrección de la función de respuesta de frecuencia inversa se perfeccionó, convirtiéndose en un método y en un conjunto de software de aplicación denominado Control Remoto de Parámetros, o RPC. Remoto significa que un sensor en un sistema dinámico se puede controlar cuando está distante o remoto del actuador que proporciona el movimiento. En otras palabras, estamos controlando un acelerómetro montado en un eje mientras que el actuador está alejado del punto en el que el caucho se encuentra con la carretera o lo que ahora denominamos la zona de contacto del neumático.
P: ¿Cuándo se involucró por primera vez con el software RPC?
R: Estuve en Ford haciendo pruebas de aceptación en fábrica utilizando RPC - lo que hoy consideraríamos como "RPC Cero". Era la primera vez que se aplicaba el RPC a una máquina rotativa y el equipo de MTS se dio cuenta rápidamente de que se necesitaba más potencia de procesamiento para calcular los archivos de conducción. Finalmente, se necesitó un procesador de matriz que costó $34.000 en 1978 para hacerlo funcionar. Fue entonces cuando conocí al equipo de MTS y me enamoré de la empresa. No mucho después, tuve la oportunidad de unirme a MTS y terminé entre las primeras personas en el equipo de desarrollo de software de dinámica de vehículos de MTS. El RPC era todo nuestro trabajo.
P: ¿Cómo era el RPC en ese momento?
R: Muy diferente de lo que es hoy, por supuesto. Era una interfaz de preguntas y respuestas sin pistas gráficas. Estábamos trabajando en MTS BASIC en pantallas verdes. Para estudiar el diagrama de una función de respuesta en frecuencia completa, tuvimos que imprimir una matriz de papel de 24 hojas de ancho por 24 de alto y colocarlas todas juntas en el suelo. Señalábamos varios elementos de esta gigantesca matriz de gráficos con un palo (sí, un palo de verdad) y reflexionábamos sobre los detalles, preguntándonos por qué el modelo matemático nos daba o no una respuesta viable y lo interpretábamos como una radiografía. A menudo me refiero a la función de respuesta de frecuencia, o FRF, como una radiografía del comportamiento dinámico de un sistema.
P: ¿Cómo reaccionó la industria a las capacidades del software?
R: Por primera vez, los ingenieros de pruebas pudieron recrear un entorno de carga realista en el laboratorio. El método no comprometió la dinámica del sistema. Proporcionó una carga correcta a través de una estructura dinámica compleja, como un sistema de suspensión. El método y el software RPC lo hicieron posible. Además, rápidamente empezaron a estar disponibles computadoras que tenían la capacidad de procesamiento para realizar los cálculos y crear archivos de conducción en una cantidad de tiempo realista. También desarrollamos métodos para equipar a los vehículos con bandas extensométricas en los ejes y sensores de desplazamiento para medir el movimiento vertical con la intención de captar todos los aspectos de la respuesta dinámica. Comenzamos a vender simuladores de carreteras MTS con software RPC. En ese momento, el código fuente evolucionó con cada instalación. A mediados de la década de 1980, RPC se había convertido en una empresa mundial, lo cual es extraordinario si se tiene en cuenta que tenía menos de 10 años.
P: ¿Cuándo se formó el primer grupo de usuarios de RPC?
R: Fue alrededor de 1980. Los propios usuarios del software RPC organizaron la primera reunión para intercambiar ideas y experiencias. Realmente fue un esfuerzo de base. MTS ayudó a organizar la primera reunión en Detroit y la participación fue muy excelente. A pesar de ser competidores, los asistentes de diferentes fabricantes de equipos originales encontraron una manera de unirse y concentrarse en hacer avanzar la ciencia y abordar retos comunes. Presentaron sus conocimientos sobre el uso de RPC, las técnicas que habían desarrollado y las listas de deseos de lo que querían que hiciera el software. Al igual que el propio RPC, los grupos de usuarios se popularizaron rápidamente. En la actualidad, MTS organiza reuniones bianuales del grupo de usuarios de RPC para usuarios de Norteamérica, Europa, Japón, Corea, China, Brasil e India.
P: ¿La popularidad de RPC cambió la forma en que MTS atendió a la industria?
R: Sí, incorporó a varias personas a MTS que se dedicaron a resolver los problemas para los que se creó el RPC. Por eso me uní. También incorporó a personas con talento como Dave Holub, Peter Gunness y Dave Fricke, quienes aprendieron el RPC siguiendo el libro cuando eran jóvenes ingenieros. Dave desarrolló nuevos métodos de modelado de neumáticos antes de concebir la idea de la Convergencia de Respuesta del Sistema Híbrido, o HSRC, para acercarse más que nadie a la solución del reto de la simulación de carreteras.
P: ¿Cuál es el reto de la simulación de carreteras?
R: Siempre la hemos llamado simulación de carreteras RPC, y todavía lo hacemos, pero en realidad es la réplica de una respuesta medida sobre el terreno en el laboratorio. Las entradas de la carretera son diferentes a la salida en el eje del vehículo de prueba porque hay un neumático entre ellos. No podemos medir lo que está haciendo la parte inferior del neumático, por lo que usamos el método RPC para cerrar la brecha. Simular verdaderamente la carretera, o "llevar la carretera al laboratorio", sería el gran avance en las pruebas físicos.
P: ¿Cuál es la ventaja de llevar la carretera al laboratorio?
R: Existe una tremenda presión en la industria para acelerar y optimizar el desarrollo de vehículos. La generación de un archivo de conducción con el proceso RPC requiere que primero se recojan los datos de carga de la carretera en la pista de pruebas utilizando un prototipo completo y totalmente instrumentado, que suele ser uno de los cuatro que llegan por etapas a lo largo de un ciclo de desarrollo del vehículo de dos años. Cuando se terminan las pruebas con los datos del prototipo final, el fabricante ya ha construido las herramientas para estampar las piezas y los paneles para la producción. En otras palabras, es realmente tarde en el proceso y sería extremadamente costoso rehacer el diseño en caso de que las pruebas revelen algún defecto. Ante la presión de calendarios de desarrollo cada vez más cortos, existe un gran interés por llevar la carretera al laboratorio y permitir la realización de pruebas realistas tipo RPC tan pronto como se disponga de los primeros prototipos de piezas y sistemas. Evitar por completo la adquisición de datos de carga en carretera sería una ventaja importante, ya que se podría empezar a mejorar los diseños sin un vehículo prototipo en funcionamiento.
P: ¿Tenemos alguna simulación real de carreteras?
R: Sí. De hecho, estamos llevando la carretera al laboratorio con el método HSRC. Comienza con una versión digitalizada real de la superficie de la carretera del campo de pruebas, que es una especie de JPEG muy grande de la carretera en la que, en lugar de color, los píxeles representan la altura del canto rodado. La esencia de una solución híbrida es combinar una pieza física, en este caso un vehículo real en un simulador de carretera real, y una pieza virtual, o un neumático matemático capaz de ser "conducido" sobre el escaneo digital de la carretera. Con el HSRC, las fuerzas y los movimientos del cubo de la rueda física y las fuerzas y los movimientos del neumático virtual se combinan para preservar el elemento de presencia. En otras palabras, el vehículo físico siente la presencia del neumático virtual y el neumático virtual siente la presencia del vehículo físico. El HSRC utiliza tanto la tecnología FRF inversa como las estrategias iterativas del RPC para conseguir una realización precisa de la carga de la carretera en el vehículo sin tener que adquirir datos de carga de la carretera. Y todo tiene lugar en el laboratorio, sin un prototipo completo.
P: Dado el potencial de HSRC, ¿el RPC será menos importante?
R: No, en absoluto. El RPC seguirá siendo fundamental para varias aplicaciones. La adquisición de datos de campo nunca pasará de moda, aunque puede volverse menos frecuente. Con la capacidad de llevar la carretera al laboratorio, podemos adquirir datos sobre componentes y subsistemas directamente a partir de un prueba HSRC del vehículo completo. Los datos resultantes se pueden utilizar para realizar pruebas adicionales en componentes y subsistemas utilizando el método RPC. Además, el software RPC puede procesar aún más los datos adquiridos en el laboratorio para desarrollar pruebas de ciclos aleatorios y de bloque de forma más eficiente. Y no olvidemos que el método RPC es ideal para los fabricantes de componentes y subsistemas que utilizan datos suministrados por el OEM. Sigue siendo una de las formas más confiables de realizar pruebas de durabilidad precisos.
P: ¿MTS seguirá admitiendo métodos y herramientas RPC?
R: Por supuesto. La inversión continua en herramientas RPC nos permitirá aprovechar todas las ventajas de llevar la carretera al laboratorio. El software RPC proporciona las herramientas de visualización y análisis de señales necesarias para implementar nuevas ideas de prueba y correlación. Estas herramientas serán aún más importantes a medida que evolucionen las aplicaciones de HSRC. Estamos desarrollando métodos para "ver" la carretera digital y visualizar los neumáticos en esa carretera, de modo que podamos entender cómo es el sistema físico/virtual en su conjunto. También seguiremos utilizando el RPC para aprender a aplicar el análisis de daños por fatiga durante la validación de las pruebas HSRC y la evaluación de la precisión. Puede que hayamos llevado la carretera al laboratorio, pero aún queda mucho por hacer en lo que respecta a la reducción del tiempo de las pruebas, la mejora de la precisión y la obtención de resultados procesables. Todo ello hace necesaria la mejora y el avance continuos de las herramientas y los métodos de RPC.
