1. Fachtagung TestRig - Juni 2022 109 Modulare Funktionsarchitektur für mechatronische Prüfsysteme Dr. Michael Winter, Dr. Timo Jungblut, Stefan Glauer, Dr. Steffen Rödling IABG mbH, Ottobrunn, Deutschland Zusammenfassung In modernen Prüfsystemen werden oftmals verschiedene Mess-, Steuerungs- und Regelungssysteme zu einem Systemverbund kombiniert. Die einzelnen Teilnehmer kommunizieren dabei untereinander und mit dem Prüfling über verschiedene Ein- und Ausgänge sowie über diverse Kommunikationsprotokolle. Je nach konkretem Anwendungsfall ergibt sich hierbei eine mehr oder weniger heterogene Systemarchitektur. Im Rahmen des Beitrags wird auf hierfür geeignete Automatisierungs- und Funktionsarchitekturen eingegangen. Diese Architekturen sind im Allgemeinen in drei Ebenen unterteilt. Die unterste Ebene, die Anlagensteuerung, bildet die Basis. Diese Ebene besteht aus einer speicherprogrammierbaren Steuerung mit integrierter Sicherheitssteuerung. Die zweite Ebene beinhaltet die Echtzeitsysteme und die Messtechnik. Die dritte Ebene, die Host-Ebene, besteht aus einem Industrie-PC. Auf diesem läuft im Allgemeinen die grafische Benutzeroberfläche, der Testsequenzer, die Messdatenspeicherung sowie das Postprocessing. Die IABG als Systemanbieter kundenindividueller Prüfsysteme setzt auf einen modularen Baukasten aus flexibel anpassbaren Hard- und Softwaremodulen. Dies ermöglicht, auch bei geringen Stückzahlen, eine schnelle und wirtschaftliche Applikation an die kundenindividuellen Bedarfe. 1. Einleitung Wurden Prüfstände vor einigen Jahren im Wesentlichen von einem zentralen Steuerungssystem (z.B. einem Industrie-PC oder einer speicherprogrammierbaren Steuerung) kontrolliert, werden in modernen Prüfsystemen oftmals verschiedene Mess-, Steuerungs- und Regelungssysteme zu einem Systemverbund kombiniert. Die Gründe für diese Entwicklung sind vielfältig. Weiterentwickelte Normen im Bereich der Maschinensicherheit bedingen den Einsatz speziell zertifizierter Sicherheitshardware. Gestiegene Anforderungen an die Messtechnik sowie die Notwendigkeit der Kommunikation mit aktiven Prüflingen machen die Integration von Teilsystemen bestimmter Hersteller notwendig. Zudem wird bei kundenindividuellen Prüfsystemen oft die Verwendung bestimmter Systeme gefordert. Hintergrund solcher Anforderungen ist häufig, dass der Kunde sich strategisch für die Plattform eines Herstellers entschieden hat und für diese Systeme entsprechend geschultes Personal, Wartungsverträge oder eigene Software-Bausteine vorhält. In diesem Beitrag werden zunächst allgemeine Anforderungen an eine Funktionsarchitektur für kundenindividuelle Prüfsysteme angeführt. Hierauf aufbauend wird die bei der IABG verwendete modulare Funktionsarchitektur in allgemeiner Form dargestellt. Anschließend wird die vorgestellte Architektur auf mehrere Anwendungen appliziert und mit Beispielen aus aktuellen Entwicklungsprojekten veranschaulicht. 2. Anforderungen an die Architekturen Neben allgemeinen Eigenschaften wie z.B. Messdatenerfassung, Speicherung, Bedienung, eine normgerechte Umsetzung der Sicherheitssteuerung, etc. sollte eine HW/ SW-Architektur für kundenindividuelle Prüfsysteme insbesondere flexibel anpassbar, skalierbar sowie schnell und wirtschaftlich umsetzbar sein. Die hieraus resultierenden Anforderungen werden in den folgenden Abschnitten ausführlicher beschrieben: 2.1 Flexibilität Die Funktionsarchitektur sollte flexibel auf Kundenanforderungen angepasst werden können ohne die Kernarchitektur als Ganzes modifizieren zu müssen. Das Spektrum an möglichen Zusatzanforderungen ist relativ breit, kann aber in erster Näherung in folgende Gruppen unterteilt werden: Hardware: Diese Kategorie umfasst sowohl die Einbindung spezieller Messtechnik, als auch die Anbindung an ggf. bereits beim Kunden vorhandener Infrastruktur bzw. Peripheriegeräte wie beispielsweise Hydraulikaggregate oder Klimageräte. Software: Bei aktiven Prüflingen ist oft die Integration der Prüflingskommunikation und ggf. einer entsprechenden Restbussimulation auf einem Echtzeitsystem notwendig. Zudem ist oftmals die Implementierung proprietärer Protokolle und Schnittstellen unter echtzeitfähigen Bedingungen notwendig. 110 1. Fachtagung TestRig - Juni 2022 Modulare Funktionsarchitektur fürmechatronische Prüfsysteme Anbindung an überlagerte Systeme: Sowohl die Konfiguration des Prüfsystems und der durchzuführenden Prüfungen, als auch die Ablage der Messdaten inkl. einer ggf. notwendigen Nachverarbeitung sind häufig an die Kundensysteme und Prozesse anzupassen, beziehungsweise an diese anzubinden. Hierbei werden oft datei- oder datenbankbasierte Vorgehensweisen gewählt. Integration von Kunden-Code: In vielen Anwendungsfällen benötigt der Kunde die Möglichkeit eigene Funktionalität in das Prüfsystem einzubringen. Im einfachsten Fall können dies lediglich Skripte für das Postprocessing sein. Aber auch Kunden-Code, welcher z.B. zur Ansteuerung des Prüflings bzw. des Prüfstands direkt auf den Echtzeitsystemen ausgeführt wird, ist ein häufiges Anwendungsszenario. Hierfür werden klar definierte Schnittstellen und eine entsprechende Überwachung benötigt, um trotz geänderter Software die Anlage in ihren definierten Spezifikationen betreiben zu können. 2.2 Skalierbarkeit Die Architektur sollte in mehrere Dimensionen skalierbar sein und über ausreichend Reserven und Erweiterungsmöglichkeiten für weitere zukünftige Einsatzgebiete des Prüfsystems verfügen. Dies betrifft beispielsweise: Anzahl I/ Os: Sowohl die Anzahl der normalen analogen und digitalen Ein- und Ausgänge, als auch die Anzahl der Kommunikationsschnittstellen sollte leicht erweiterbar sein. Schnittstellen: Es ist notwendig sowohl anlagenseitig, als auch in den speziellen Kundendomänen (z.B. Luftfahrt, Automotive…) alle bekannten Schnittstellen zu unterstützen und neue Schnittstellen schnellstmöglich verfügbar zu machen. Rechenleistung: Die Rechenleistung soll an den entsprechenden Anwendungsfall anpassbar sein. 2.3 Effizienz Bei kundenindividuellen Prüfsystemen geringer Stückzahl spielen die Entwicklungskosten und die Entwicklungszeit eine weitaus größere Rolle als bei der Entwicklung eines Serienproduktes. Daher sind insbesondere bei diesen Systemen folgende Aspekte relevant: Durchgängigkeit der Toolchain: Die Durchgängigkeit zur Matlab/ Simulink-basierten Toolchain der Systementwicklung ist ein entscheidender Faktor. Hierdurch wird es beispielsweise möglich, einen simulativ validierten Regelungsalgorithmus auf einem Echtzeitsystem zu integrieren [1]. Hoher Re-Use-Faktor: Ein modulbasierter, und idealerweise objektorientierter Ansatz steigert den Wiederverwendungsgrad bereits implementierter Funktionsmodule. Treiber für Drittgeräte: Eine hohe Verfügbarkeit von Treibern für Drittgeräte verschiedenster Hersteller steigert Qualität und Effizienz der Entwicklung. Um die Variantenvielfalt zu beherrschen, ist hierbei eine Fokussierung auf Vorzugstypen beziehungsweise -lieferanten wichtiger Kunden und eine enge Abstimmung mit der Hardwareentwicklung erforderlich. 3. Modulare Funktionsarchitektur Abbildung 1 zeigt eine modulare Funktionsarchitektur, die sich für die Realisierung kundenindividueller Prüfsysteme bewährt hat. Diese sieht im Wesentlichen drei Ebenen vor: Eine Ebene für die Anlagensteuerung, eine Ebene für die Echtzeitsysteme und Messtechnik sowie eine Host-Ebene. Auf die grundsätzlichen Aufgaben der einzelnen Ebenen sowie die konkrete Ausgestaltung wird in den folgenden Abschnitten eingegangen. 3.1 Anlagen-Ebene Die Aufgabe der Anlagen- und Sicherheitssteuerung ist es einen sicheren und stabilen Betrieb des Prüfsystems zu gewährleisten. Dazu ist die Anlagensteuerung mit den diversen Anlagenkomponenten des Prüfsystems über digitale und analoge Ein- und Ausgänge sowie über Feldbusse verbunden und führt entsprechende Funktionsmodule zur Ansteuerung und Überwachung der Anlagenkomponenten aus. In Richtung überlagerter Ebenen werden die Anlagenkomponenten entsprechend ihrer Funktionalität gebündelt und mit einer definierten Schnittstelle angebunden. Dies erleichtert die (Wieder-) Verwendung der Komponenten auf den höheren Ebenen. Detailwissen über die konkrete hardwaretechnische Umsetzung ist für die Automatisierung hierbei nicht mehr nötig. Die Sicherheitssteuerung besteht aus einem Sicherheitssteuergerät, das mit den entsprechenden analogen und digitalen I/ Os ausgerüstet ist, um die sicherheitstechnischen Komponenten anzusteuern und zu überwachen. Diese Ebene der Anlagen- und Sicherheitssteuerung besteht in der Regel aus einer speicherprogrammierbaren Steuerung mit integrierter Sicherheitssteuerung. 3.2 Echtzeit- und Messtechnik-Ebene Je nach konkretem Anwendungsfall können die Aufgaben der Echtzeit- und Messtechnik-Ebene sehr unterschiedlich sein. Die Hardware dieser Ebene besteht in der Regel aus einem Echtzeitsystem, basierend auf einem Hardware-in-the-Loop (HiL)-System gängiger Anbieter. In den Prüfsystemen der IABG kommen in Abhängigkeit der Bedarfe und Vorzüge der Kunden als HiL-Systeme sowohl PXI-Systeme der Firma National Instruments als auch Scalexio-Systeme des Anbieters dSPACE zum Einsatz. Auf den HiL-Systemen können in Matlab/ Simulink implementierte Echtzeitfunktionen wie z.B. komplexe Regelungen, Algorithmen zur Online-Datenverar-beitung oder Signalgeneratoren deterministisch und mit hoher Frequenz (typ. größer 10 kHz) ausgeführt werden. Beide 1. Fachtagung TestRig - Juni 2022 111 Modulare Funktionsarchitektur fürmechatronische Prüfsysteme Systemanbieter verfügen zudem über eine breite Palette an digitalen und analogen I/ Os sowie Erweiterungen für die meisten in Luftfahrt und Automotive-Anwendungen gängigen Bus-Systeme. Bei Prüfständen mit sehr hohen Anforderungen an bestimmte Messungen kann die Messtechnik auch um Messsysteme von Drittanbietern erweitert werden. Aufgrund der Ausrichtung der HiL-Systeme eignet sich diese Ebene, neben der Ausführung von Echtzeitalgorithmen, vor allem für alle prüflingsnahen Funktionen. Oft werden die HiL-Systeme vom Kunden auch als Integrationsplattform genutzt um eigene Funktionalität einzubringen oder um die Prüflingskommunikation anzupassen. 3.3 Host-Ebene Die Hardware der dritten Ebene, der Host-Ebene, besteht aus einem handelsüblichen Industrie-PC. Auf diesem läuft die grafische Benutzeroberfläche für das Prüfsystem inkl. der Messdatenverwaltung. Bei Bedarf kann hier auch eine Nachverarbeitung der Messdaten erfolgen. Zudem stellt diese Ebene die Schnittstelle in alle überlagerten Kundensysteme, wie beispielsweise Datenbanken für Messergebnisse oder ERP-Systeme, dar. Die Implementierung der Schnittstellen in die Kundensysteme wird in der Regel kundenindividuell vorgenommen. Abbildung 1: Modulare Funktionsarchitektur für mechatronische Prüfsysteme 112 1. Fachtagung TestRig - Juni 2022 Modulare Funktionsarchitektur fürmechatronische Prüfsysteme 3.4 Applikation und Vernetzung der Ebenen In den vorangegangenen Abschnitten wurden die einzelnen Ebenen der modularen Funktionsarchitektur mit den verwendeten Komponenten und dem jeweiligen Aufgabenspektrum vorgestellt. Sowohl die Vernetzung der Ebenen untereinander, als auch der Teilsysteme innerhalb einer Ebene, erfolgt über klassische Netzwerkkommunikation oder über Feldbusse. Insbesondere wenn ein echtzeitfähiger Datenaustausch zwischen den Teilsystemen benötigt wird, hat sich eine Kommunikation über EtherCAT bewährt. Die Applikation der vorgestellten Architektur an eine konkrete Aufgabenstellung ist keine triviale Aufgabe. Die Fragestellung „Welche Funktion läuft auf welchem System? “ ist für viele Funktionen relativ klar zu beantworten. Für manche Funktionen sind aber durchaus mehrere Antworten richtig. Zudem kann die gewählte Funktionsarchitektur auch mit der hardwaretechnischen Umsetzung und Vernetzung der Automatisierungssysteme wechselwirken. Hierbei sind insbesondere die Übertragungsanforderungen der einzelnen Signale hinsichtlich Bandbreite und Latenz zu berücksichtigen. Daher sind die Auslegung und Applikation der Funktionsarchitektur sowie die klare Definition der Schnittstellen integraler Bestandteil der Konzeptphase bei der Entwicklung eines Prüfsystems. 4. Anwendungsbeispiele Die in allgemeiner Form vorgestellte Funktionsarchitektur soll in diesem Kapitel anhand einiger Umsetzungsbeispiele konkretisiert werden. 4.1 Entwicklungsprüfstand für Elektromotoren Als erstes Applikationsbeispiel wird der in Abbildung 2 dargestellte Entwicklungsprüfstand betrachtet. Das Prüfsystem dient sowohl der Entwicklung und Charakterisierung von einzelnen Elektromotoren als auch von kompletten elektrischen Antriebssystemen, bestehend aus Elektromotor und zugehörigem Steuergerät. Letztere beinhalten wiederum die Leistungselektronik als auch die Funktionen für die Regelung des Motors. Den Kern des Prüfsystems bildet ein elektrischer Antriebsstrang, bestehend aus dem zu testenden elektrischen Antrieb, einer Drehmomentenmesswelle und einem geeigneten Servomotor zur Belastung des Prüflings. Der Prüfling selbst befindet sich in einer Klimakammer. Der betrachtete Prüfstand wird sowohl für die Entwicklung neuer Produkte, als auch für die Durchführung von standardisierten Prüfläufen im Rahmen der Qualitätssicherung verwendet. Abbildung 3 zeigt die zugehörige Funktionsarchitektur. Als Anlagen- und Sicherheitssteuerung wird eine SPS der Fa. Beckhoff eingesetzt. Die Sicherheits-SPS überwacht neben den Not-Halt-Tastern auch die elektrische Energieversorgung des Prüflings, den Frequenzumrichter der Belastungsmaschine sowie die Türzuhaltungen. Die SPS der Anlagensteuerung überwacht und steuert diverse Peripheriesysteme wie den Frequenzumrichter, die Bordnetzsimulation, verschiedene Netzteile und das Klimagerät. Für überlagerte Echtzeitsysteme kann zwischen einem NI PXI-System und einem dSPACE-System gewählt werden. Die Schnittstelle zwischen dem Echtzeit-System und der Anlagensteuerung ist in beiden Fällen durch eine zyklische Netzwerkkommunikation umgesetzt. Dafür wurde im Echtzeitsystem das proprietäre ADS-Protokoll der Fa. Beckhoff implementiert, welches es ermöglicht, Werte der Anlagensteuerung zu lesen und zu schreiben. Das Echtzeitsystem übernimmt die Ausführung der Testsequenzen und die Erfassung der Messdaten. Neben der Sollwertvorgabe für die Belastungsmaschine wird mit den Prüflingen über CAN oder LIN kommuniziert. Die CAN/ LIN-Kommunikation kann durch Austausch der entsprechenden *.dbc/ *.ldf-Dateien an neue Produkte angepasst werden. Eine Erweiterung der Kommunikationsprotokolle, beispielsweise um Flexray oder ARINC 429, ist jederzeit möglich. Zudem integrieren Kunden immer häufiger Simulationsmodelle ihrer Produkte in die Echtzeitumgebung. Diese Modelle entstehen im Rahmen der Produktentwicklung und Reglerauslegung in Matlab/ Simulink und können mit leichten Anpassungen auch als sog. „Digitaler Zwilling“ parallel zum Prüfling in der Echtzeitumgebung ausgeführt werden. Neben dem Echtzeitsystem kann das Prüfsystem optional mit einem Leistungsmesssystem wie z.B. der Fa. Yokogawa ausgerüstet werden. Durch die hochgenaue Messung der Ströme, Spannungen, des Drehmoments und der Drehzahl lassen sich mit dem Prüfsystem präzise Wirkungsgradmessungen unter Variation der Umgebungsbedingungen durchführen. Für die grafische Benutzeroberfläche auf dem Host-PC können die Möglichkeiten der Echtzeitsysteme NI VeriStand oder dSPACE Configuration Desk verwendet werden. Mit diesen Systemen lassen sich via Drag&Drop relativ schnell einfache neue Oberflächen für neue Versuche erstellen, was insbesondere von Entwicklungsteams sehr stark genutzt wird. Wenn eine stärkere Nutzerführung in der Bedienung oder aber auch eine Integration in die Kundensysteme benötigt wird, kann die in NI LabVIEW implementierte IABG E-Motor-GUI verwendet werden. Diese wird auf Wunsch individuell an die Kundenbedarfe angepasst. Ein großer Vorteil der Umsetzung der Benutzeroberfläche mit NI LabVIEW ist dessen weite Verbreitung. Dadurch stehen LabVIEW-Treiber für viele Geräte von 1. Fachtagung TestRig - Juni 2022 113 Modulare Funktionsarchitektur fürmechatronische Prüfsysteme Drittanbietern zur Verfügung. Die beiden unterlagerten Systeme, das PXI-System sowie das Leistungsmessgerät, werden unter Verwendung der entsprechenden Lab- VIEW-Treiber in das Programm der Benutzeroberfläche eingebunden. Die eigentliche Kommunikation findet über Ethernet statt. Abbildung 2: Entwicklungsprüfstand für Elektromotoren In der Benutzeroberfläche sind mehrere Ansichten zur Prüfstandskonfiguration und zur Konfiguration von diversen Lastfällen integriert. So kann der Anwender eine Vielzahl unterschiedlicher Prüfungen, von der einfachen Sprungantwort bis hin zum Wirkungsgradkennfeld, vollautomatisiert durchführen. Die Nachverarbeitung der Messdaten der unterschiedlichen Lastfälle, das Postprocessing, ist mit NI Diadem umgesetzt. Spezifisch für jeden Lastfall werden vollautomatisiert die Messdaten aufbereitet und die Ergebnisse in einer pdf-Datei ausgegeben. Die Skripte zur Reporterstellung sind für den Anwender offen einsehbar und können jederzeit an neue Anforderungen angepasst werden. Durch den modularen Ansatz kann dem Kunden sowohl auf Hardware-, als auch auf Automatisierungsebene eine passgenaue Lösung auf Basis bewährter Bausteine angeboten werden. Insbesondere die Möglichkeit der Einbringung eigener Funktionsbausteine und Simulationsmodelle bietet einen langfristigen Mehrwert. Abbildung 3: Funktionsarchitektur eines Prüfsystems für elektrische Antriebe 114 1. Fachtagung TestRig - Juni 2022 Modulare Funktionsarchitektur fürmechatronische Prüfsysteme 4.2 Funktionsprüfstand für elektromechanische Wankstabilisatoren Im nächsten Beispiel wird die Flexibilität der modularen Funktionsarchitektur an einem konkreten Kundenprojekt aufgezeigt. In diesem Projekt wurde gemeinsam mit ZF- Friedrichshafen ein Funktionsprüfstand für aktive Wankstabilisatoren entwickelt [2,3]. Kern des in Abbildung 4 gezeigten Funktionsprüfstandes ist ein zweiachsiges servohydraulisches Belastungssystem, welches den Prüfling mit Kräften und Wegen beaufschlagt. Der Prüfling selbst wird vom Prüfsystem über ein bidirektionales Leistungsnetzteil mit elektrischer Leistung versorgt. Die Kommunikation zwischen dem Prüfsystem und dem Steuergerät des Prüflings erfolgt über CAN. Zur Nachbildung von Umgebungstemperaturen zwischen -40° und +120°C, befindet sich der Prüfling in einem Prüfraum, der über ein externes Temperiergerät temperiert wird. Die Entwicklung der Automatisierung des Prüfsystems erfolgte in partnerschaftlicher Zusammenarbeit zwischen dem Kunden und der IABG. Die hierbei verwendete Funktionsarchitektur ist in Abbildung 5 dargestellt und zeigt auch die Arbeitsteilung der Funktionsimplementierung auf. Die beschriebene Grundarchitektur ist deutlich erkennbar. Auf der zweiten Ebene ist in diesem Fall ein zusätzliches Echtzeitsystem „CANoe RT“ der Firma Vektor Informatik eingebunden, welches für Automatisierungslösungen des Kunden benötigt wird. Auf diesem System werden die Funktionen für die Kommunikation mit dem Prüfling, die Generierung von Sollsignalen für den Prüfling und den Prüfstand sowie die Speicherung von Messdaten ausgeführt. Diese Funktionsmodule wurden vom Kunden ursprünglich für die Testautomatisierung von Funktionsprüfständen einer anderen Produktgruppe entwickelt und konnten mit geringen Änderungsumfängen direkt übernommen werden. Als zweites Echtzeitsystem kommt ein NI PXI-System mit NI VeriStand zum Einsatz. Auf diesem System werden unter anderem die Funktionen zur Regelung der servohydraulischen Gegenkraftanlage ausgeführt. Abbildung 4: Prüfstand für aktive Wankstabilisatoren Abbildung 5: Funktionsarchitektur eines Prüfsystems für elektrische Wankstabilisatoren 1. Fachtagung TestRig - Juni 2022 115 Modulare Funktionsarchitektur fürmechatronische Prüfsysteme Die auf dem NI PXI-System implementierten Regelungsalgorithmen wurden wie in [1] beschrieben im Rahmen der modellbasierten Entwicklung des Prüfsystems in Matlab-Simulink entwickelt, an Streckenmodellen mit unterschiedlichem Detaillierungsgrad optimiert und getestet und anschließend auf die Zielhardware exportiert. In der Ebene der Anlagensteuerung sind die Funktionen wiederum auf einer kombinierten Anlagen- und Sicherheitssteuerung der Firma Beckhoff implementiert. Diese steuert unter anderem das Hydrauliksystem, die Klemmen der Bordnetzsimulation, diverse Pneumatiksysteme sowie die Sicherheitsfunktionen. Alle Funktionen der Host-Ebene wurden in diesem Projekt vom Kunden in dessen Framework implementiert beziehungsweise aus Vorgängerprojekten übernommen. Die Funktionen auf der Host-Ebene beinhalten unter anderem die Steuerung des CANoe RT-Systems, die Benutzeroberflächen sowie die Ansteuerung der diversen Peripheriegeräte wie zum Beispiel das Klimagerät und die unterschiedlichen Netzteile. Bei der Entwicklung einer gemeinsamen Automatisierungslösung durch zwei Projektpartner sind insbesondere die Schnittstellen zwischen den Systemen der beiden Parteien von besonderer Relevanz. Wie in Abbildung 5 zu erkennen ist, waren im konkreten Beispiel aufgrund der günstig gewählten Funktionsarchitektur nur zwei Softwareschnittstellen zwischen den jeweiligen Leistungsumfängen abzustimmen: Eine Schnittstelle zwischen den beide Echtzeitsystemen sowie eine weitere Verbindung zwischen dem Host-PC und dem PXI-System. Über die „langsame“ Schnittstelle zwischen dem Host- PC und dem PXI-System werden Parameter und Statussignale ausgetauscht. Beispiele hierfür sind Grenzwerte, Einstellungen für die Regelung der Gegenkraftanlage oder Signale zum Aktivieren bestimmter Funktionalitäten, die über die GUI oder die übergeordnete Testautomatisierung gesetzt und von der Host-Ebene auf die Echtzeitebene übertragen werden. Das PXI-System meldet wiederum über diverse Signale den Anlagenstatus an die Host-Ebene zurück. Für die Kommunikation mit dem PXI-System wurde eine Schnittstelle zu NI VeriStand über dessen .NET-API in der Automatisierungslösung des Kunden implementiert. Über die „schnelle“ Schnittstelle zwischen den beiden Echtzeitsystemen werden auf dem CANoe-System generierte Sollwertsignale der Regelung der Gegenkraftanlage übergeben. Gleichzeitig werden alle Messsignale des Prüfstandes, wie beispielsweise Wege, Kräfte, Spannung und Ströme über diese Schnittstelle vom PXI-System zum CANoe-System gesendet, um auf diesem zeitsynchron mit Restbus- und Diagnosesignalen erfasst und gespeichert zu werden. Für die Schnittstelle auf der Echtzeitebene wurde das Vector-spezifische, auf UDP basierende, FDX-Protokoll genutzt, welches eine Echtzeitverbindung via Ethernet mit dem CANoe-RT-System erlaubt. Dabei konnte auf eine bereits bei ZF entwickelte Implementierung des FDX-Protokolls in NI LabVIEW zurückgegriffen werden. Für die Integration dieser Implementierung in die NI VeriStand-Echtzeitengine wurde die beigestellte FDX-Implementierung in ein Custom Device integriert. „Custom Device“ werden Erweiterungen von NI VeriStand auf der Echtzeitebene genannt. Auch die ADS-basierte Schnittstelle zwischen der Anlagensteuerung und dem PXI-System ist über ein IABG-eigenes Custom Device realisiert. Der Kunde konnte durch den gewählten Ansatz seine eigene, schon mehrfach erprobte, Prüfstandsautomatisierung einsetzen, ohne das Gesamtsystem selbst entwickeln zu müssen. Der Prüfstand stellt seine Funktionen über eine klar definierte API/ Schnittstelle zur Verfügung. Der Kunde kann diese Funktionen frei nach Bedarf in seine Prozesslandschaft integrieren. 4.3 Prüfsysteme geringer Komplexität In den beiden vorangegangenen Beispielen wurden komplexe Prüfsysteme für aktive Prüflinge vorgestellt. Die modulare Funktionsarchitektur wird bei der IABG aber auch für Prüfsysteme mit geringeren Anforderungen eingesetzt. Abbildung 6 zeigt ein verallgemeinertes Beispiel. Das Basis-Setup besteht dabei aus einem Host-PC und einer Anlagensteuerung inkl. der obligatorischen Sicherheitssteuerung. Mess-, Steuer- und Regelungstechnik sind auf der Anlagensteuerung implementiert. Diese ist direkt mit dem Host-PC verbunden und kann darüber gesteuert werden. Je nach Kundenbedarf können auf beiden Ebenen die gewünschten Funktionen implementiert werden. Eine spätere Erweiterung der Architektur um eine zusätzliche Echtzeitebene ist dabei weiterhin möglich. Abbildung 6: Funktionsarchitektur einfacher Prüfsysteme 5. Zusammenfassung Ein modularer Baukasten aus flexibel anpassbaren Hard- und Softwaremodulen ermöglicht, auch bei geringen Stückzahlen, eine schnelle und wirtschaftliche Entwicklung und Realisierung von Prüfsystemen unter Berücksichtigung der kundenindividuellen Bedarfe und Wün- 116 1. Fachtagung TestRig - Juni 2022 Modulare Funktionsarchitektur fürmechatronische Prüfsysteme sche. Dies setzt jedoch wiederum geeignete, modulare System- und Funktionsarchitekturen voraus. Insbesondere bei der Entwicklung komplexer, kundenindividueller Prüfsysteme sind im Rahmen der Festlegung der Hard- und Softwarearchitektur die drei Kriterien Flexibilität, Skalierbarkeit und Effizienz zu berücksichtigen. Die vorgestellte modulare Funktionsarchitektur wird allen diesen Anforderungen gerecht. Auch deshalb wurde diese schon in diversen Prüfsystemen, die von der IABG im Auftrag unterschiedlichster Kunden entwickelt und realisiert wurden, umgesetzt. Das Spektrum an Prüfständen, in denen der beschriebene Ansatz angewendet wurde, reicht hierbei von vergleichsweise einfachen Lösungen [6,7] bis hin zu hochkomplexen Systemprüfständen [2,3,5]. Literaturverzeichnis [1] Jungblut, T.; Böhm, L.; Winter, M.; Rödling, S.: Entwicklung von Funktionsprüfständen für aktive Fahrdynamiksysteme: Herausforderungen und Lösungen. In: TAE TestRig, Ostfildern, 2021 [2] Winter, M.; Bultmann, S.: Automatisierung eines Funktionsprüfstands für elektrische Wankstabilisatoren mit NI VeriStand. NI VIP, Fürstenfeldbruck, 2018. [3] Koch, C.; Jungblut, T.: Modulare Prüftechnik für die Funktionserprobung von aktiven Wankstabilisatoren. DVM Workshop Prüfmethodik für Betriebsfestigkeitsversuche in der Fahrzeugindustrie, Ulm, 2019 [4] Winter, M.: A VeriStand-based architecture for physical system tests In: NI Aerospace and Defense Forum, Birmingham, 2019 [5] Keil, M.; Karl, M.; Anderl, T.: Automatisierung von Systemprüfständen für Flugzeugfahrwerke auf Basis National Instruments VeriStand In: NI VIP 2017, Fürstenfeldbruck [6] Hoffmann, S.; Rödling, S.: Energieeffziente Prüfung von Federn und Stabilisatoren mit variablen Amplituden und Frequenzen. In: DVM Workshop Prüfmethodik in der Betriebsfestigkeitsversuche in der Fahrzeugindustrie, Ottobrunn, 2017 [7] Friedrich, F.; Anderl, T.; Pfichner A.: Schwingungserreger für Strukturtests dynamisch belasteter Bauteile. NI VIP, Fürstenfeldbruck, 2018.