F: Wie und warum wurde RPC-Software entwickelt?
A: Das ursprüngliche Konzept bestand in der Verbesserung von Testdaten durch Replizieren des im Feld gemessenen Verhaltens in einer kontrollierten und wiederholbaren Laborumgebung. Es begann Mitte der 1970er Jahre mit Paul Nawrocke von GM und Dr. Richard Lund von MTS. MTS hatte vor kurzem servohydraulische Testsysteme eingeführt – die ersten Vier-Poster-Straßensimulatoren. Die Idee war, dass man Fahrzeuge im Labor statt auf einer Teststrecke testen könnte, wenn man den Aktuator dazu bringen könnte, sich wie die Straße zu bewegen. Um Daten zur Straßenbelastung zu erfassen, zeichneten die Testingenieure des OEM die Signale von Beschleunigungsmessern auf, die an den Rädern eines Autos angebracht waren, das über ein Testgelände gefahren wurde. Die Aufzeichnungen wurden dann in einen Analogrechner eingespielt, der die Beschleunigungen in Wegprofile umwandelte, die einem Servoregler zugeführt wurden. Dieser Regler wiederum betrieb die Testaktuatoren. Das war die erste Drive-Datei.
F: War es eine praktikable Lösung, um Fahrzeuge im Labor statt im Feld zu testen?
A: Nein. Das Verfahren, die Beschleunigung doppelt zu integrieren und als Programmiersignal für den Aktuatorantrieb zu verwenden, barg eine Reihe von Fehlern. Die Methode berücksichtigte weder das intrinsische Verhalten des Servoreglers, noch das noch komplexere dynamische Verhalten der Reifeninteraktion mit der Fahrbahn und in der Folge die flache Wanne des reifengekoppelten Simulators. Nawrocke und Dr. Lund kamen zu dem Schluss, dass, wenn sie ein mathematisches Modell dieser Wechselwirkungen entwickeln könnten, dieses eine bessere Drive-Datei vorhersagen und in einer iterativen Weise verwendet werden könnte, um die vorhergesagte Lösung zu verfeinern. Die Idee der inversen Frequenzgangkorrektur wurde durch neue Digitalcomputer für die Berechnungen verfeinert und zu einer Methode und einer Anwendungssoftware namens Remote Parameter Control (RPC) weiterentwickelt. Ferngesteuert bedeutet, dass ein Sensor an einem dynamischen System auch dann noch gesteuert werden kann, wenn er vom Aktuator, der die Bewegung ausführt, weit entfernt ist. Mit anderen Worten, wir steuern einen Beschleunigungssensor, der auf einer Achse montiert ist, während der Aktuator von dem Punkt entfernt ist, an dem das Gummi die Straße berührt (Reifenaufstandsfläche).
F: Wann haben Sie sich zum ersten Mal mit RPC-Software beschäftigt?
A: Ich habe bei Ford Werksabnahmeprüfungen mit RPC durchgeführt – was wir heute als „RPC Zero“ bezeichnen würden. Es war das erste Mal, dass RPC auf eine rotierende Maschine angewendet wurde, und das MTS-Team erkannte schnell, dass mehr Rechenleistung für die Berechnung der Antriebsdateien benötigt wurde. Schließlich wurde ein Array-Prozessor benötigt, der im Jahr 1978 34.000 US-Dollar kostete, damit er funktionierte. Damals lernte ich das MTS-Team kennen und war sofort Feuer und Flamme für das Unternehmen. Kurze Zeit später hatte ich die Chance, bei MTS einzusteigen und wurde zu einem der ersten Mitarbeiter des MTS-Entwicklungsteams für Fahrzeugdynamik-Software. RPC war unsere alleinige Aufgabe.
F: Wie war RPC zu dieser Zeit?
A: Ganz anders als heute natürlich. Es war eine Frage- und Antwort-Schnittstelle ohne grafische Hinweise. Wir haben in MTS BASIC auf grünen Bildschirmen gearbeitet. Um den Verlauf einer vollständigen Frequenzgangfunktion zu studieren, mussten wir eine Matrix aus Papier ausdrucken, die 24 Blatt breit und 24 Blatt hoch war, und sie alle zusammen auf den Boden legen. Wir zeigten mit einem Stock (ja, einem echten Stock) auf verschiedene Elemente dieser riesigen Matrix von Graphen und grübelten über die Details nach, fragten uns, warum das mathematische Modell uns eine brauchbare Antwort gab oder nicht und interpretierten es wie ein Röntgenbild. Ich bezeichne die Übertragungsfunktion (Frequency Response Function, FRF) oft als Röntgenbild des dynamischen Verhaltens eines Systems.
F: Wie hat die Branche auf die Fähigkeiten der Software reagiert?
A: Zum ersten Mal konnten die Testingenieure eine realistische Belastungsumgebung im Labor nachstellen. Die Methode hat die Dynamik des Systems nicht beeinträchtigt. Sie sorgte für eine korrekte Belastung in einer komplexen dynamischen Struktur, wie z. B. einem Aufhängungssystem. Die RPC-Methode und -Software machten dies möglich. Außerdem wurden schnell Computer verfügbar, die über die nötige Rechenleistung verfügten, um die Berechnungen zur Erstellung von Drive-Dateien in einer realistischen Zeitspanne durchzuführen. Wir entwickelten auch Methoden zur Instrumentierung von Fahrzeugen mit Dehnungsmessstreifen an den Achsen und Wegsensoren zur Messung der vertikalen Bewegung mit der Absicht, jede Nuance des dynamischen Verhaltens zu erfassen. Wir haben mit dem Verkauf von MTS-Straßensimulatoren mit RPC-Software begonnen. Zu dieser Zeit wurde der Quellcode mit jeder Installation weiterentwickelt. Mitte der 1980er-Jahre war RPC global geworden, was bemerkenswert war, wenn man bedenkt, dass das Unternehmen weniger als 10 Jahre alt war.
F: Wann wurde die erste RPC-Benutzergruppe gegründet?
A: Das war um 1980 herum. Die RPC-Software-Anwender selbst organisierten das erste Treffen, um Ideen und Erfahrungen auszutauschen. Es war wirklich eine Graswurzelbewegung. MTS hat dieses erste Treffen in Detroit unterstützt und die Beteiligung war großartig. Obwohl sie Konkurrenten sind, fanden die Teilnehmer von verschiedenen OEMs zueinander und konzentrierten sich auf die Weiterentwicklung der Wissenschaft und die Bewältigung gemeinsamer Herausforderungen. Sie präsentierten Erkenntnisse, die sie durch den Einsatz von RPC gewonnen hatten, Techniken, die sie entwickelt hatten, und Wunschlisten, was sie von der Software erwarten. Wie RPC selbst, haben sich die Benutzergruppen schnell durchgesetzt. Heute veranstaltet MTS alle zwei Jahre RPC-Anwendergruppentreffen für Anwender in Nordamerika, Europa, Japan, Korea, China, Brasilien und Indien.
F: Hat die Popularität von RPC die Art und Weise verändert, wie MTS die Branche bedient?
A: Ja, es zog einige Leute zu MTS, die sich der Lösung der Probleme widmeten, für die RPC gemacht war. Deshalb bin ich beigetreten. So gewannen wir auch talentierte Leute wie Dave Holub, Peter Gunness und Dave Fricke, der als junger Ingenieur RPC nach dem Buch lernte. Dave entwickelte neue Methoden zur Modellierung von Reifen, bevor er auf die Idee der Hybrid System Response Convergence, kurz HSRC, stieß. So kam er der Lösung der Herausforderung der Straßensimulation näher als jeder andere.
F: Was ist die Herausforderung der Straßensimulation?
A: Wir haben RPC immer als Straßensimulation bezeichnet – und tun dies auch heute noch – aber eigentlich ist es die Replikation einer im Feld gemessenen Reaktion im Labor. Die Eingänge von der Straße sind anders als die Ausgänge an der Spindel des Testfahrzeugs, da ein Reifen dazwischen liegt. Wir können nicht messen, was die Unterseite des Reifens macht, also schließen wir die Lücke mit der RPC-Methode. Die Straße wirklich zu simulieren, oder „die Straße ins Labor zu bringen“, wäre der ultimative Durchbruch bei physikalischen Tests.
F: Worin besteht der Vorteil, wenn man die Straße ins Labor zu holt?
A: In der Branche herrscht ein enormer Druck, die Fahrzeugentwicklung zu beschleunigen und zu optimieren. Das Erzeugen einer Drive-Datei mit dem RPC-Verfahren erfordert, dass Sie zunächst mit einem voll instrumentierten, kompletten Prototyp – typischerweise einer von vielleicht vier, die im Laufe eines zweijährigen Fahrzeugentwicklungszyklus schrittweise eintreffen – Straßenbelastungsdaten auf der Teststrecke sammeln. Wenn Sie die Tests mit den Daten des endgültigen Prototyps abgeschlossen haben, hat der Hersteller bereits die Werkzeuge zum Ausstanzen der Teile und Platten für die Produktion gebaut. Mit anderen Worten: Sollten die Tests irgendwelche Fehler aufdecken, werden diese erst sehr spät im Prozess und in Verbindung mit hohen Kosten behoben. Angesichts des Drucks immer kürzerer Entwicklungszeitpläne gibt es einen sehr starken Druck, die Straße ins Labor zu bringen und realistische RPC-ähnliche Tests zu ermöglichen, sobald die ersten Prototypenteile und Systeme verfügbar sind. Auf die Erfassung von Straßenbelastungsdaten ganz zu verzichten, wäre ein erheblicher Vorteil, weil man mit der Verbesserung von Konstruktionen ohne ein funktionierendes Prototypfahrzeug beginnen könnte.
F: Haben wir eine echte Straßensimulation?
A: Ja. Mit der HSRC-Methode bringen wir tatsächlich die Straße ins Labor. Es beginnt mit einer tatsächlichen digitalisierten Version der Straßenoberfläche des Testgeländes, die eine Art sehr großes JPEG der Straße ist, bei dem die Pixel anstelle von Farbe die Höhe der Kieselsteine darstellen. Bei einer hybriden Lösung werden ein physisches Teil – in diesem Fall ein reales Auto auf einem realen Straßensimulator – und ein virtuelles Teil, oder ein mathematischer Reifen, der über den digitalen Scan der Straße „gefahren“ werden kann, kombiniert. Mit HSRC werden die Kräfte und Bewegungen der physischen Radnabe und die Kräfte und Bewegungen des virtuellen Reifens kombiniert, um das Element der Präsenz zu erhalten. Mit anderen Worten: Das physische Fahrzeug spürt die Anwesenheit des virtuellen Reifens und der virtuelle Reifen spürt die Anwesenheit des physischen Fahrzeugs. HSRC nutzt sowohl die invertierte FRF-Technologie als auch die iterativen Strategien von RPC, um eine genaue Realisierung der Straßenbelastung des Fahrzeugs zu erreichen, ohne Straßenbelastungsdaten erfassen zu müssen. Und das alles findet im Labor statt, ohne einen kompletten Prototyp.
F: Wird RPC angesichts des Potenzials von HSRC an Bedeutung verlieren?
A: Nein, ganz und gar nicht. RPC wird für eine Reihe von Anwendungen unentbehrlich bleiben. Die Datenerfassung vor Ort wird nie überflüssig sein, auch wenn sie vielleicht seltener wird. Indem wir die Straße ins Labor bringen, können wir Daten über Komponenten und Subsysteme direkt aus einem HSRC-Test für ein ganzes Fahrzeug gewinnen. Die resultierenden Daten können für weitere Tests an Komponenten und Subsystemen mit der RPC-Methode verwendet werden. Zusätzlich kann die RPC-Software die im Labor erfassten Daten weiterverarbeiten, um Zufalls- und Blockzyklustests effizienter zu entwickeln. Nicht zu vergessen, dass die RPC-Methode ideal für Komponenten- und Subsystemhersteller ist, die die vom OEM gelieferten Daten verwenden. Es ist nach wie vor eine der zuverlässigsten Methoden für genaue Haltbarkeitstests.
F: Wird MTS weiterhin RPC-Methoden und -Tools unterstützen?
A: Auf jeden Fall. Mit weiteren Investitionen in RPC-Tools werden wir die Vorteile, dass wir die Straße ins Labor gebracht haben, noch besser ausnutzen. Die RPC-Software bietet die Signalanalyse- und Visualisierungswerkzeuge, die für die Umsetzung neuer Prüf- und Korrelationsideen benötigt werden. Diese Werkzeuge werden mit der Weiterentwicklung der HSRC-Anwendungen noch wichtiger werden. Wir entwickeln Methoden, um die digitale Straße zu „sehen“ und die Reifen auf dieser Straße zu visualisieren, damit wir verstehen können, wie das physische/virtuelle System als Ganzes aussieht. Wir werden auch weiterhin RPC verwenden, um zu lernen, wie man die Ermüdungsschadensanalyse während der HSRC-Testvalidierung und Genauigkeitsbewertung anwendet. Wir haben zwar die Straße ins Labor gebracht, aber es gibt noch viel zu tun, wenn es darum geht, die Testzeit zu reduzieren, die Genauigkeit zu verbessern und verwertbare Testergebnisse zu liefern. All dies erfordert die kontinuierliche Verbesserung und Weiterentwicklung von RPC-Tools und -Methoden.
A: Das ursprüngliche Konzept bestand in der Verbesserung von Testdaten durch Replizieren des im Feld gemessenen Verhaltens in einer kontrollierten und wiederholbaren Laborumgebung. Es begann Mitte der 1970er Jahre mit Paul Nawrocke von GM und Dr. Richard Lund von MTS. MTS hatte vor kurzem servohydraulische Testsysteme eingeführt – die ersten Vier-Poster-Straßensimulatoren. Die Idee war, dass man Fahrzeuge im Labor statt auf einer Teststrecke testen könnte, wenn man den Aktuator dazu bringen könnte, sich wie die Straße zu bewegen. Um Daten zur Straßenbelastung zu erfassen, zeichneten die Testingenieure des OEM die Signale von Beschleunigungsmessern auf, die an den Rädern eines Autos angebracht waren, das über ein Testgelände gefahren wurde. Die Aufzeichnungen wurden dann in einen Analogrechner eingespielt, der die Beschleunigungen in Wegprofile umwandelte, die einem Servoregler zugeführt wurden. Dieser Regler wiederum betrieb die Testaktuatoren. Das war die erste Drive-Datei.
F: War es eine praktikable Lösung, um Fahrzeuge im Labor statt im Feld zu testen?
A: Nein. Das Verfahren, die Beschleunigung doppelt zu integrieren und als Programmiersignal für den Aktuatorantrieb zu verwenden, barg eine Reihe von Fehlern. Die Methode berücksichtigte weder das intrinsische Verhalten des Servoreglers, noch das noch komplexere dynamische Verhalten der Reifeninteraktion mit der Fahrbahn und in der Folge die flache Wanne des reifengekoppelten Simulators. Nawrocke und Dr. Lund kamen zu dem Schluss, dass, wenn sie ein mathematisches Modell dieser Wechselwirkungen entwickeln könnten, dieses eine bessere Drive-Datei vorhersagen und in einer iterativen Weise verwendet werden könnte, um die vorhergesagte Lösung zu verfeinern. Die Idee der inversen Frequenzgangkorrektur wurde durch neue Digitalcomputer für die Berechnungen verfeinert und zu einer Methode und einer Anwendungssoftware namens Remote Parameter Control (RPC) weiterentwickelt. Ferngesteuert bedeutet, dass ein Sensor an einem dynamischen System auch dann noch gesteuert werden kann, wenn er vom Aktuator, der die Bewegung ausführt, weit entfernt ist. Mit anderen Worten, wir steuern einen Beschleunigungssensor, der auf einer Achse montiert ist, während der Aktuator von dem Punkt entfernt ist, an dem das Gummi die Straße berührt (Reifenaufstandsfläche).
F: Wann haben Sie sich zum ersten Mal mit RPC-Software beschäftigt?
A: Ich habe bei Ford Werksabnahmeprüfungen mit RPC durchgeführt – was wir heute als „RPC Zero“ bezeichnen würden. Es war das erste Mal, dass RPC auf eine rotierende Maschine angewendet wurde, und das MTS-Team erkannte schnell, dass mehr Rechenleistung für die Berechnung der Antriebsdateien benötigt wurde. Schließlich wurde ein Array-Prozessor benötigt, der im Jahr 1978 34.000 US-Dollar kostete, damit er funktionierte. Damals lernte ich das MTS-Team kennen und war sofort Feuer und Flamme für das Unternehmen. Kurze Zeit später hatte ich die Chance, bei MTS einzusteigen und wurde zu einem der ersten Mitarbeiter des MTS-Entwicklungsteams für Fahrzeugdynamik-Software. RPC war unsere alleinige Aufgabe.
F: Wie war RPC zu dieser Zeit?
A: Ganz anders als heute natürlich. Es war eine Frage- und Antwort-Schnittstelle ohne grafische Hinweise. Wir haben in MTS BASIC auf grünen Bildschirmen gearbeitet. Um den Verlauf einer vollständigen Frequenzgangfunktion zu studieren, mussten wir eine Matrix aus Papier ausdrucken, die 24 Blatt breit und 24 Blatt hoch war, und sie alle zusammen auf den Boden legen. Wir zeigten mit einem Stock (ja, einem echten Stock) auf verschiedene Elemente dieser riesigen Matrix von Graphen und grübelten über die Details nach, fragten uns, warum das mathematische Modell uns eine brauchbare Antwort gab oder nicht und interpretierten es wie ein Röntgenbild. Ich bezeichne die Übertragungsfunktion (Frequency Response Function, FRF) oft als Röntgenbild des dynamischen Verhaltens eines Systems.
F: Wie hat die Branche auf die Fähigkeiten der Software reagiert?
A: Zum ersten Mal konnten die Testingenieure eine realistische Belastungsumgebung im Labor nachstellen. Die Methode hat die Dynamik des Systems nicht beeinträchtigt. Sie sorgte für eine korrekte Belastung in einer komplexen dynamischen Struktur, wie z. B. einem Aufhängungssystem. Die RPC-Methode und -Software machten dies möglich. Außerdem wurden schnell Computer verfügbar, die über die nötige Rechenleistung verfügten, um die Berechnungen zur Erstellung von Drive-Dateien in einer realistischen Zeitspanne durchzuführen. Wir entwickelten auch Methoden zur Instrumentierung von Fahrzeugen mit Dehnungsmessstreifen an den Achsen und Wegsensoren zur Messung der vertikalen Bewegung mit der Absicht, jede Nuance des dynamischen Verhaltens zu erfassen. Wir haben mit dem Verkauf von MTS-Straßensimulatoren mit RPC-Software begonnen. Zu dieser Zeit wurde der Quellcode mit jeder Installation weiterentwickelt. Mitte der 1980er-Jahre war RPC global geworden, was bemerkenswert war, wenn man bedenkt, dass das Unternehmen weniger als 10 Jahre alt war.
F: Wann wurde die erste RPC-Benutzergruppe gegründet?
A: Das war um 1980 herum. Die RPC-Software-Anwender selbst organisierten das erste Treffen, um Ideen und Erfahrungen auszutauschen. Es war wirklich eine Graswurzelbewegung. MTS hat dieses erste Treffen in Detroit unterstützt und die Beteiligung war großartig. Obwohl sie Konkurrenten sind, fanden die Teilnehmer von verschiedenen OEMs zueinander und konzentrierten sich auf die Weiterentwicklung der Wissenschaft und die Bewältigung gemeinsamer Herausforderungen. Sie präsentierten Erkenntnisse, die sie durch den Einsatz von RPC gewonnen hatten, Techniken, die sie entwickelt hatten, und Wunschlisten, was sie von der Software erwarten. Wie RPC selbst, haben sich die Benutzergruppen schnell durchgesetzt. Heute veranstaltet MTS alle zwei Jahre RPC-Anwendergruppentreffen für Anwender in Nordamerika, Europa, Japan, Korea, China, Brasilien und Indien.
F: Hat die Popularität von RPC die Art und Weise verändert, wie MTS die Branche bedient?
A: Ja, es zog einige Leute zu MTS, die sich der Lösung der Probleme widmeten, für die RPC gemacht war. Deshalb bin ich beigetreten. So gewannen wir auch talentierte Leute wie Dave Holub, Peter Gunness und Dave Fricke, der als junger Ingenieur RPC nach dem Buch lernte. Dave entwickelte neue Methoden zur Modellierung von Reifen, bevor er auf die Idee der Hybrid System Response Convergence, kurz HSRC, stieß. So kam er der Lösung der Herausforderung der Straßensimulation näher als jeder andere.
F: Was ist die Herausforderung der Straßensimulation?
A: Wir haben RPC immer als Straßensimulation bezeichnet – und tun dies auch heute noch – aber eigentlich ist es die Replikation einer im Feld gemessenen Reaktion im Labor. Die Eingänge von der Straße sind anders als die Ausgänge an der Spindel des Testfahrzeugs, da ein Reifen dazwischen liegt. Wir können nicht messen, was die Unterseite des Reifens macht, also schließen wir die Lücke mit der RPC-Methode. Die Straße wirklich zu simulieren, oder „die Straße ins Labor zu bringen“, wäre der ultimative Durchbruch bei physikalischen Tests.
F: Worin besteht der Vorteil, wenn man die Straße ins Labor zu holt?
A: In der Branche herrscht ein enormer Druck, die Fahrzeugentwicklung zu beschleunigen und zu optimieren. Das Erzeugen einer Drive-Datei mit dem RPC-Verfahren erfordert, dass Sie zunächst mit einem voll instrumentierten, kompletten Prototyp – typischerweise einer von vielleicht vier, die im Laufe eines zweijährigen Fahrzeugentwicklungszyklus schrittweise eintreffen – Straßenbelastungsdaten auf der Teststrecke sammeln. Wenn Sie die Tests mit den Daten des endgültigen Prototyps abgeschlossen haben, hat der Hersteller bereits die Werkzeuge zum Ausstanzen der Teile und Platten für die Produktion gebaut. Mit anderen Worten: Sollten die Tests irgendwelche Fehler aufdecken, werden diese erst sehr spät im Prozess und in Verbindung mit hohen Kosten behoben. Angesichts des Drucks immer kürzerer Entwicklungszeitpläne gibt es einen sehr starken Druck, die Straße ins Labor zu bringen und realistische RPC-ähnliche Tests zu ermöglichen, sobald die ersten Prototypenteile und Systeme verfügbar sind. Auf die Erfassung von Straßenbelastungsdaten ganz zu verzichten, wäre ein erheblicher Vorteil, weil man mit der Verbesserung von Konstruktionen ohne ein funktionierendes Prototypfahrzeug beginnen könnte.
F: Haben wir eine echte Straßensimulation?
A: Ja. Mit der HSRC-Methode bringen wir tatsächlich die Straße ins Labor. Es beginnt mit einer tatsächlichen digitalisierten Version der Straßenoberfläche des Testgeländes, die eine Art sehr großes JPEG der Straße ist, bei dem die Pixel anstelle von Farbe die Höhe der Kieselsteine darstellen. Bei einer hybriden Lösung werden ein physisches Teil – in diesem Fall ein reales Auto auf einem realen Straßensimulator – und ein virtuelles Teil, oder ein mathematischer Reifen, der über den digitalen Scan der Straße „gefahren“ werden kann, kombiniert. Mit HSRC werden die Kräfte und Bewegungen der physischen Radnabe und die Kräfte und Bewegungen des virtuellen Reifens kombiniert, um das Element der Präsenz zu erhalten. Mit anderen Worten: Das physische Fahrzeug spürt die Anwesenheit des virtuellen Reifens und der virtuelle Reifen spürt die Anwesenheit des physischen Fahrzeugs. HSRC nutzt sowohl die invertierte FRF-Technologie als auch die iterativen Strategien von RPC, um eine genaue Realisierung der Straßenbelastung des Fahrzeugs zu erreichen, ohne Straßenbelastungsdaten erfassen zu müssen. Und das alles findet im Labor statt, ohne einen kompletten Prototyp.
F: Wird RPC angesichts des Potenzials von HSRC an Bedeutung verlieren?
A: Nein, ganz und gar nicht. RPC wird für eine Reihe von Anwendungen unentbehrlich bleiben. Die Datenerfassung vor Ort wird nie überflüssig sein, auch wenn sie vielleicht seltener wird. Indem wir die Straße ins Labor bringen, können wir Daten über Komponenten und Subsysteme direkt aus einem HSRC-Test für ein ganzes Fahrzeug gewinnen. Die resultierenden Daten können für weitere Tests an Komponenten und Subsystemen mit der RPC-Methode verwendet werden. Zusätzlich kann die RPC-Software die im Labor erfassten Daten weiterverarbeiten, um Zufalls- und Blockzyklustests effizienter zu entwickeln. Nicht zu vergessen, dass die RPC-Methode ideal für Komponenten- und Subsystemhersteller ist, die die vom OEM gelieferten Daten verwenden. Es ist nach wie vor eine der zuverlässigsten Methoden für genaue Haltbarkeitstests.
F: Wird MTS weiterhin RPC-Methoden und -Tools unterstützen?
A: Auf jeden Fall. Mit weiteren Investitionen in RPC-Tools werden wir die Vorteile, dass wir die Straße ins Labor gebracht haben, noch besser ausnutzen. Die RPC-Software bietet die Signalanalyse- und Visualisierungswerkzeuge, die für die Umsetzung neuer Prüf- und Korrelationsideen benötigt werden. Diese Werkzeuge werden mit der Weiterentwicklung der HSRC-Anwendungen noch wichtiger werden. Wir entwickeln Methoden, um die digitale Straße zu „sehen“ und die Reifen auf dieser Straße zu visualisieren, damit wir verstehen können, wie das physische/virtuelle System als Ganzes aussieht. Wir werden auch weiterhin RPC verwenden, um zu lernen, wie man die Ermüdungsschadensanalyse während der HSRC-Testvalidierung und Genauigkeitsbewertung anwendet. Wir haben zwar die Straße ins Labor gebracht, aber es gibt noch viel zu tun, wenn es darum geht, die Testzeit zu reduzieren, die Genauigkeit zu verbessern und verwertbare Testergebnisse zu liefern. All dies erfordert die kontinuierliche Verbesserung und Weiterentwicklung von RPC-Tools und -Methoden.
