antriebstechnik 5/2026

SPECIAL: PRÜFSTÄNDE

SPECIAL: PRÜFSTÄNDE Joshua Summa, Managing Director und Co-Founder, es:saar, Saarbrücken MOTOR BRING-UP DOMÄNENÜBERGREIFENDES TESTEN Wer Regelungstechnik für elektrische Antriebe selbst entwickelt, kennt das Problem: Sobald der Prüfstand übernimmt, verschwindet die Sicht auf interne Softwarezustände - ausgerechnet dann, wenn sie zur Fehlersuche gebraucht werden. Ein domänenübergreifender Testansatz verbindet Messdaten und Reglervariablen auf einer Zeitachse. So lassen sich Ursachen statt Symptome analysieren und Parameter im laufenden Betrieb optimieren, ohne erneutes Kompilieren oder Neustart. Das Testen von Motor-Controllern in Antriebssystemen folgt einem bekannten Pfad: von der Modellierung des Antriebssystems über MiL-, SiL- und HiL-Tests bis hin zum realen Prüfstand. Solange das System in der Simulation läuft, lässt sich das Softwareverhalten direkt beobachten. Am Prüfstand ändert sich das: dort stehen in der Regel nur physikalische Messgrößen zur Verfügung. Das Problem: Abweichungen zwischen Simulation und realem Verhalten lassen sich schwer nachvollziehen, weil das interne Variablenverhalten der Software am physischen Prüfstand nicht direkt messbar ist. Es wird höchstens abgeleitet. Geeignete Methoden, um Messungen an Laufzeitvariablen zugänglich zu machen, waren bislang für viele Entwicklungsteams nicht verfügbar oder zu aufwendig in der Integration. Domänenübergreifendes Testen setzt hier an: Bei diesem Ansatz werden Laufzeitvariablen als Messsignale aus der Software- Domäne erfasst und mit Messsignalen aus der physikalischen Domäne auf einer Zeitachse synchronisiert. Dies ermöglicht Regler- Tuning, Sensorkalibrierung und Validierung direkt am Prüfstand und zur Laufzeit und damit, dass Entwickler früher vom Modell zum realen Systemtest kommen. Dieser Beitrag zeigt, was das in der Praxis bedeutet, und wie es den Weg vom Modell zum qualifizierten System verkürzt. REGLER TRIFFT AUF ECHTEN MOTOR Der Regler ist entworfen. Das Antriebssystem wurde modelliert oder durch Messungen identifiziert, die Regler-Software entwickelt, die Simulation zeigt, was erwartet wurde. Dann trifft der eigene Regler auf den echten Motor. Die Drehzahl schwingt beim Hochlauf über, ein Pfeifen ist zu hören. Der Phasenstrom liegt im erwarteten Bereich, aber was im Regler intern passiert, bleibt unsichtbar. Es erschließt sich, dass es ein Tuning-Problem ist, darum folgen mehrere Schleifen: Anpassen, Kompilieren, Flashen, Neustarten, Warten, Messen. Und wieder von vorne. Dieses Szenario hat einen Preis: Längere Entwicklungszyklen, höhere Testkosten, mehr Abhängigkeit von HiL-Infrastruktur, die nicht jedes Team betreiben kann. Wer Zugriff auf eine HiL-Station hat, verlagert den Qualifizierungs- und Kalibrierungsaufwand in die Simulation, dabei jedoch ohne Garantie, dass das reale Verhalten zufriedenstellend abgebildet ist und die Simulation ausreicht. Das ist einer der Hauptgründe, warum sich Teams gegen Eigenentwicklung entscheiden: Nicht, weil die Regelungstechnik an sich zu komplex wäre, sondern weil der Testaufwand vom funktionierenden Modell zum qualifizierten System zu hoch ist. Wer eine eigene Motorregelung entwickelt, hat mehr Freiheitsgrade als jemand, der einen zugekauften Motion Controller parametriert. Bei einem komplexen Regler mit vielen Parametern multipliziert sich das schnell. Und irgendwann steht eine strategische Entscheidung im Raum: Lohnt sich eine Eigenentwicklung überhaupt, oder kauft man besser ein? Um Laufzeitvariablen als interpretierbare Messwerte und Stellwerte zugänglich zu machen, kann die offene Middleware es:prot herangezogen werden. Diese kann in den C-Code eines beliebigen Mikrocontrollers integriert werden. Für jedes Signal wird in der Software-Konfiguration definiert, was ein Datenpunkt bedeutet: Name, Typ, Skalierungsfaktor. Variablen werden aus dem Code abgegriffen und an ein konfigurierbares Protokoll zur Datenübertragung übergeben, optimalerweise mittels DMA-basiertem Datentransports. Durch diesen softwarebasierten Ansatz entfällt der Bedarf an externen Debug- oder Trace-Probes, Symbol-Dateien oder Ausführungsstopps für den Datenzugriff. Die Daten werden zyklisch mit einer hohen Datenrate ausgetauscht und von der Datenakquise-Software es:scope auf einem Computer über eine serielle Schnittstelle oder Netzwerk empfangen. Der 40 antriebstechnik 2026/05 www.antriebstechnik.de

SPECIAL: PRÜFSTÄNDE 01 01 Mit Reglervariablen und Messsignalen auf einer Zeitachse schneller vom Modell zum qualifizierten System 02 02 Neben Software hat es:saar auch ganze Prüfstände im Angebot Datenaustausch ist dabei bidirektional: Über es:scope und mittels es:prot lassen sich Parameter zur Laufzeit anpassen und Befehle direkt an das laufende System senden. Das Ergebnis: Das System arbeitet unterbrechungsfrei weiter, während seine Variablen in Echtzeit beobachtet und asynchron gesteuert werden können. ZWEI DOMÄNEN, EINE ZEITACHSE Der softwarebasierte Ansatz macht Laufzeitvariablen als Messwerte zugänglich. Aber eine vollständige Einsicht in das Systemverhalten entsteht erst, wenn diese zusammen mit physikalischen Messsignalen auf einer gemeinsamen Zeitachse dargestellt werden. Erst dann lässt sich Kausalität erkennen: wenn ein Problem auftritt und wann genau und welches Softwareverhalten dazu geführt hat. Das ist das Prinzip des domänenübergreifenden Testens (Cross-Domain Testing, CDT). Die Grundlage dafür ist ein gemeinsames Protokoll: Sowohl die Controller-Software als auch es:mod, das DAQ-System von es:saar, verwenden es:prot für die Datenübertragung. es:mod setzt dabei zusätzlich auf IEEE 1588 PTP zur netzwerkbasierten Zeitsynchronisation. Ab es:scope 2.0 lassen sich damit mehrere Datenquellen synchronisiert auf einer gemeinsamen Zeitachse zusammenführen. Ein domänenübergreifender Prüfstand für Motoranwendungen lässt sich mit den beschriebenen Werkzeugen direkt aufbauen. Der typische Aufbau besteht aus einem DUT-Controller mit integriertem es:prot, dem DUT-Motor, einem Inverter für die Motoransteuerung, einem Computer mit es:scope und es:mod als zentralem DAQ-System für Sensorsignale. es:mod übernimmt dabei zwei Rollen: als Datenakquisegerät für Sensorsignale und als Inverter mit Dreiphasen-Wechselrichter für die Motoransteuerung des Gegenmotors. MOTOR BRING-UP MIT CDT Der Hochlauf beginnt, die Drehzahl schwingt über. Das ist ein bekanntes Kalibrierungsproblem mit vielen möglichen Ursachen. Und ein Pfeifen ist zu hören, dessen Ursprung von außen nicht zu greifen ist. Der Phasenstrom zeigt eine Anomalie, aber was im Regler intern passiert, bleibt unsichtbar. Also: Anpassen, Kompilieren, Flashen, Neustarten, Warten, Messen. Bis das Überschwingen innerhalb der Toleranz ist. Beim Pfeifen ändert sich erstmal nichts. Noch eine Iteration. Mit CDT ändert sich das. Das Verhalten des Drehzahlreglers ist direkt sichtbar und synchronisiert mit der gemessenen Drehzahl auf derselben Zeitachse dargestellt. Die Parameter werden in einer einzigen Iteration zur Laufzeit kalibriert und dadurch wird die Überschwingung in den Toleranzbereich reduziert. Die Ursache des Pfeifens wird endlich identifiziert, da mit CDT die gemessene Rotorposition, gestellte Spannung und resultierender Strom auf einer Zeitachse dargestellt sind. So ist erkennbar, dass der Positionssensor driftet, sprich die vom Regler angenommene Position von der tatsächlichen abweicht und Spannung und Strom passen nicht mehr zusammen.Die Ursache ist identifiziert, der Parameter korrigiert, die Auswirkung sofort getestet. Was vorher viele Schleifen brauchte, wird zu wenigen gezielten Eingriffen. Da die Einsicht in das Softwareverhalten erhalten bleibt, wird der Weg vom Modell zum qualifizierten System transparenter und Qualifizierungskosten sinken. Der zu hohe Testaufwand am realen System erzwang früher strategische Entscheidungen gegen Eigenentwicklung - CDT adressiert genau das. Es kann früher am realen System getestet werden. Die Schwelle zur Eigenentwicklung sinkt. Und mit ihr die Abhängigkeit von zugekauften Lösungen. Bilder: es:saar www.essaar.de DIE IDEE „Sobald der echte Motor läuft, wird der Regler zur Blackbox - jede Korrektur kostet einen kompletten Iterationszyklus. Die Lösung liegt nicht in mehr Simulation, sondern darin, Software- Interna und physikalische Messdaten synchron auf einer Zeitachse sichtbar zu machen. So wird aus vielen Iterationen eine gezielte.“ Joshua Summa, Managing Director und Co-Founder, es:saar, Saarbrücken www.antriebstechnik.de antriebstechnik 2026/05 41