Q: How and why was RPC Software developed?
A: The initial concept was to improve test data by replicating field-measured behavior in a controlled and repeatable laboratory environment. It started in the mid-1970s with Paul Nawrocke from GM and Dr. Richard Lund from MTS. MTS had recently introduced servohydraulic test systems — the first four-poster road simulators. The idea was, if you could make the actuator move like the road, you could test vehicles in the lab instead of in the field. To capture road load data, OEM test engineers made a tape recording of the signals from accelerometers attached to the wheels of a car being driven over a proving ground. The recordings were then played back into an analog computer, which turned the accelerations into displacement profiles, which were fed to a servocontroller running the test actuators. That was the first drive file.
Q: Was it a viable solution for testing vehicles in the lab instead of in the field?
A: No. The process of double integrating acceleration and using it as a programming signal for the actuator drive had a number of flaws. The method did not comprehend the intrinsic behavior of the servocontroller, nor the even more complex dynamic behavior of the tire interaction with the road surface, and subsequently the flat pan of the tire-coupled simulator. Nawrocke and Dr. Lund concluded that if they could develop a mathematical model of these interactions, it could predict a better drive file and be used in an iterative manner to refine the predicted solution. Enabled by new digital computers capable of doing the math, the idea of inverse frequency response function correction was refined, becoming a method and a suite of application software named Remote Parameter Control, or RPC. Remote means that a sensor on a dynamic system can be controlled when it is distant, or remote, from the actuator providing the motion. In other words, we are controlling an accelerometer mounted on an axle while the actuator is remote from the point where the rubber meets the road or what we now refer to as the tire contact patch.
Q: When did you first become involved with RPC software?
A: I was at Ford doing factory acceptance testing using RPC — what we would think of today as “RPC Zero.” It was the first time RPC had been applied to a rotating machine and the MTS team quickly realized more processing power was needed to compute drive files. Eventually an array processor that cost $34,000 in 1978 was required to make it work. That’s when I met the MTS team and fell in love with the company. Not long after, I had a chance to join MTS and wound up among the first people on the MTS vehicle dynamics software development team. RPC was our entire job.
Q: What was RPC like at that time?
A: Very different than it is today, of course. It was a question and answer interface with no graphical cues. We were working in MTS BASIC on green screens. To study the plot of a full frequency response function, we had to print out a matrix of paper 24 sheets wide by 24 sheets tall and lay them all together on the floor. We would point to various elements of this giant matrix of graphs with a stick (yes, a real stick) and ponder the details, wondering why the math model was or was not giving us a workable answer and interpreting it like an x-ray. I often refer to the Frequency Response Function, or FRF, as an x-ray of the dynamic behavior of a system.
Q: How did the industry react to the software’s capabilities?
A: For the first time, test engineers could recreate a realistic loading environment in the lab. The method did not compromise the dynamics of the system. It provided correct loading throughout a complex dynamic structure, like a suspension system. The RPC method and software made this possible. In addition, computers that had the processing power to perform the calculations to create drive files in a realistic amount of time were rapidly becoming available. We also developed methods for instrumenting vehicles with strain gages on the axles and displacement sensors to measure vertical motion with the intent of capturing every nuance of the dynamic response. We started selling MTS road simulators with RPC software. At that time, the source code evolved with every installation. By the mid-1980s RPC had gone global, which was remarkable considering it was less than 10 years old.
Q: When was the first RPC users’ group formed?
A: It was around 1980. RPC software users themselves organized the first meeting to exchange ideas and experiences. It was really a grassroots effort. MTS helped support that first meeting in Detroit and the turnout was great. Despite being competitors, attendees from different OEMs found a way to come together and focus on advancing the science and addressing common challenges. They presented insights they had gained using RPC, techniques they had developed and wish lists of what they wanted the software to do. Like RPC itself, the users’ groups caught on quickly. Today, MTS stages RPC users’ group meetings on a biannual basis for users in North America, Europe, Japan, Korea, China, Brazil and India.
Q: Did the popularity of RPC change how MTS served the industry?
A: Yes, it drew several people to MTS who were dedicated to solving the problems RPC was made to address. That’s why I joined. It also brought talented people like Dave Holub, Peter Gunness and Dave Fricke, who learned RPC by the book as a young engineer. Dave developed new methods of modeling tires before hitting upon the idea of Hybrid System Response Convergence, or HSRC, to come closer than anyone to solving the road simulation challenge.
Q: What is the road simulation challenge?
A: We have always called RPC road simulation — and still do — but it is actually the replication of a field-measured response in the lab. Inputs from the road are different than the output at the test vehicle spindle because there is a tire in between them. We can’t measure what the bottom of the tire is doing, so we use the RPC method to bridge the gap. Truly simulating the road, or “bringing the road into the lab,” would be the ultimate breakthrough in physical testing.
Q: What is the advantage of bringing the road into the lab?
A: There is tremendous pressure in the industry to accelerate and streamline vehicle development. Generating a drive file with the RPC process requires you to first collect road load data on the test track using a fully instrumented, complete prototype — typically one of maybe four that arrive in stages over a two-year vehicle development cycle. By the time you’re finished testing with the data from the final prototype, the manufacturer has already built the tooling to stamp out the parts and panels for production. In other words, it’s really late in the game and it would be extremely expensive to rework the design should testing reveal any flaws. Given the pressure of shorter and shorter development schedules, there is a very strong push to bring the road into the lab and enable realistic RPC-like testing as soon as the first prototype parts and systems become available. To avoid acquiring road load data altogether would be a significant advantage because you could start improving designs without a functioning prototype vehicle.
Q: Do we have any real road simulation?
A: Yes. We are in fact bringing the road into the lab with the HSRC method. It begins with an actual digitized version of the proving ground road surface, which is a kind of very big JPEG of the road where instead of color, the pixels represent the height of the pebbles. The essence of a hybrid solution is to combine a physical part — in this case a real car on a real road simulator — and a virtual part, or a mathematical tire capable of being “driven” over the digital scan of the road. With HSRC, the forces and motions of the physical wheel hub and the forces and motions of the virtual tire are combined to preserve the element of presence. In other words, the physical vehicle feels the presence of the virtual tire and the virtual tire feels the presence of the physical vehicle. HSRC uses both the inverse FRF technology and the iterative strategies of RPC to bring about an accurate realization of the road load on the vehicle without having to acquire road load data. And it all takes place in the lab, without a complete prototype.
Q: Given the potential of HSRC, will RPC become less important?
A: No, not at all. RPC will remain critical for a number of applications. Field data acquisition will never go out of style, although it may become less frequent. With the ability to bring the road into the lab, we can acquire data about components and subsystems directly from a full-vehicle HSRC test. The resulting data can be used to perform additional tests on components and subsystems using the RPC method. Additionally, RPC software can further process the lab-acquired data to develop random and block cycle tests more efficiently. And let’s not forget that the RPC method is ideal for component and subsystem manufacturers using data supplied by the OEM. It remains one of the most reliable ways to perform accurate durability testing.
Q: Will MTS continue to support RPC methods and tools?
A: Absolutely. Continued investment in RPC tools will enable us to realize the full benefit of bringing the road into the lab. RPC software provides the signal analysis and visualization tools needed to implement new testing and correlation ideas. These tools will become even more important as HSRC applications evolve. We are developing methods to “see” the digital road and visualize the tires on that road, so we can understand how the physical/virtual system looks as a whole. We will also continue to use RPC to learn how to apply fatigue damage analysis during HSRC test validation and accuracy assessment. We may have brought the road into the lab, but there is still much to do with respect to reducing test time, improving accuracy and delivering actionable test results. All of this necessitates the continuous improvement and advancement of RPC tools and methods.
A: The initial concept was to improve test data by replicating field-measured behavior in a controlled and repeatable laboratory environment. It started in the mid-1970s with Paul Nawrocke from GM and Dr. Richard Lund from MTS. MTS had recently introduced servohydraulic test systems — the first four-poster road simulators. The idea was, if you could make the actuator move like the road, you could test vehicles in the lab instead of in the field. To capture road load data, OEM test engineers made a tape recording of the signals from accelerometers attached to the wheels of a car being driven over a proving ground. The recordings were then played back into an analog computer, which turned the accelerations into displacement profiles, which were fed to a servocontroller running the test actuators. That was the first drive file.
Q: Was it a viable solution for testing vehicles in the lab instead of in the field?
A: No. The process of double integrating acceleration and using it as a programming signal for the actuator drive had a number of flaws. The method did not comprehend the intrinsic behavior of the servocontroller, nor the even more complex dynamic behavior of the tire interaction with the road surface, and subsequently the flat pan of the tire-coupled simulator. Nawrocke and Dr. Lund concluded that if they could develop a mathematical model of these interactions, it could predict a better drive file and be used in an iterative manner to refine the predicted solution. Enabled by new digital computers capable of doing the math, the idea of inverse frequency response function correction was refined, becoming a method and a suite of application software named Remote Parameter Control, or RPC. Remote means that a sensor on a dynamic system can be controlled when it is distant, or remote, from the actuator providing the motion. In other words, we are controlling an accelerometer mounted on an axle while the actuator is remote from the point where the rubber meets the road or what we now refer to as the tire contact patch.
Q: When did you first become involved with RPC software?
A: I was at Ford doing factory acceptance testing using RPC — what we would think of today as “RPC Zero.” It was the first time RPC had been applied to a rotating machine and the MTS team quickly realized more processing power was needed to compute drive files. Eventually an array processor that cost $34,000 in 1978 was required to make it work. That’s when I met the MTS team and fell in love with the company. Not long after, I had a chance to join MTS and wound up among the first people on the MTS vehicle dynamics software development team. RPC was our entire job.
Q: What was RPC like at that time?
A: Very different than it is today, of course. It was a question and answer interface with no graphical cues. We were working in MTS BASIC on green screens. To study the plot of a full frequency response function, we had to print out a matrix of paper 24 sheets wide by 24 sheets tall and lay them all together on the floor. We would point to various elements of this giant matrix of graphs with a stick (yes, a real stick) and ponder the details, wondering why the math model was or was not giving us a workable answer and interpreting it like an x-ray. I often refer to the Frequency Response Function, or FRF, as an x-ray of the dynamic behavior of a system.
Q: How did the industry react to the software’s capabilities?
A: For the first time, test engineers could recreate a realistic loading environment in the lab. The method did not compromise the dynamics of the system. It provided correct loading throughout a complex dynamic structure, like a suspension system. The RPC method and software made this possible. In addition, computers that had the processing power to perform the calculations to create drive files in a realistic amount of time were rapidly becoming available. We also developed methods for instrumenting vehicles with strain gages on the axles and displacement sensors to measure vertical motion with the intent of capturing every nuance of the dynamic response. We started selling MTS road simulators with RPC software. At that time, the source code evolved with every installation. By the mid-1980s RPC had gone global, which was remarkable considering it was less than 10 years old.
Q: When was the first RPC users’ group formed?
A: It was around 1980. RPC software users themselves organized the first meeting to exchange ideas and experiences. It was really a grassroots effort. MTS helped support that first meeting in Detroit and the turnout was great. Despite being competitors, attendees from different OEMs found a way to come together and focus on advancing the science and addressing common challenges. They presented insights they had gained using RPC, techniques they had developed and wish lists of what they wanted the software to do. Like RPC itself, the users’ groups caught on quickly. Today, MTS stages RPC users’ group meetings on a biannual basis for users in North America, Europe, Japan, Korea, China, Brazil and India.
Q: Did the popularity of RPC change how MTS served the industry?
A: Yes, it drew several people to MTS who were dedicated to solving the problems RPC was made to address. That’s why I joined. It also brought talented people like Dave Holub, Peter Gunness and Dave Fricke, who learned RPC by the book as a young engineer. Dave developed new methods of modeling tires before hitting upon the idea of Hybrid System Response Convergence, or HSRC, to come closer than anyone to solving the road simulation challenge.
Q: What is the road simulation challenge?
A: We have always called RPC road simulation — and still do — but it is actually the replication of a field-measured response in the lab. Inputs from the road are different than the output at the test vehicle spindle because there is a tire in between them. We can’t measure what the bottom of the tire is doing, so we use the RPC method to bridge the gap. Truly simulating the road, or “bringing the road into the lab,” would be the ultimate breakthrough in physical testing.
Q: What is the advantage of bringing the road into the lab?
A: There is tremendous pressure in the industry to accelerate and streamline vehicle development. Generating a drive file with the RPC process requires you to first collect road load data on the test track using a fully instrumented, complete prototype — typically one of maybe four that arrive in stages over a two-year vehicle development cycle. By the time you’re finished testing with the data from the final prototype, the manufacturer has already built the tooling to stamp out the parts and panels for production. In other words, it’s really late in the game and it would be extremely expensive to rework the design should testing reveal any flaws. Given the pressure of shorter and shorter development schedules, there is a very strong push to bring the road into the lab and enable realistic RPC-like testing as soon as the first prototype parts and systems become available. To avoid acquiring road load data altogether would be a significant advantage because you could start improving designs without a functioning prototype vehicle.
Q: Do we have any real road simulation?
A: Yes. We are in fact bringing the road into the lab with the HSRC method. It begins with an actual digitized version of the proving ground road surface, which is a kind of very big JPEG of the road where instead of color, the pixels represent the height of the pebbles. The essence of a hybrid solution is to combine a physical part — in this case a real car on a real road simulator — and a virtual part, or a mathematical tire capable of being “driven” over the digital scan of the road. With HSRC, the forces and motions of the physical wheel hub and the forces and motions of the virtual tire are combined to preserve the element of presence. In other words, the physical vehicle feels the presence of the virtual tire and the virtual tire feels the presence of the physical vehicle. HSRC uses both the inverse FRF technology and the iterative strategies of RPC to bring about an accurate realization of the road load on the vehicle without having to acquire road load data. And it all takes place in the lab, without a complete prototype.
Q: Given the potential of HSRC, will RPC become less important?
A: No, not at all. RPC will remain critical for a number of applications. Field data acquisition will never go out of style, although it may become less frequent. With the ability to bring the road into the lab, we can acquire data about components and subsystems directly from a full-vehicle HSRC test. The resulting data can be used to perform additional tests on components and subsystems using the RPC method. Additionally, RPC software can further process the lab-acquired data to develop random and block cycle tests more efficiently. And let’s not forget that the RPC method is ideal for component and subsystem manufacturers using data supplied by the OEM. It remains one of the most reliable ways to perform accurate durability testing.
Q: Will MTS continue to support RPC methods and tools?
A: Absolutely. Continued investment in RPC tools will enable us to realize the full benefit of bringing the road into the lab. RPC software provides the signal analysis and visualization tools needed to implement new testing and correlation ideas. These tools will become even more important as HSRC applications evolve. We are developing methods to “see” the digital road and visualize the tires on that road, so we can understand how the physical/virtual system looks as a whole. We will also continue to use RPC to learn how to apply fatigue damage analysis during HSRC test validation and accuracy assessment. We may have brought the road into the lab, but there is still much to do with respect to reducing test time, improving accuracy and delivering actionable test results. All of this necessitates the continuous improvement and advancement of RPC tools and methods.
