Autor: Moritz Olbrich, Dr. Fritz Faulhaber GmbH & Co. KG<\/p>\n
Das Implementieren und Testen neu zu entwickelnder Funktionen (z.B. Antriebsregler) f\u00fcr Antriebssteuerungen k\u00f6nnen fehlerhaft und zeitintensiv sein. Durch den Einsatz einer Rapid Control Prototyping (RCP) Umgebung soll das Entwickeln von neuen Funktionen effizienter werden. Mit dieser Umgebung lassen sich direkt angeschlossene Antriebe auf Modellebene betreiben. Durch bessere Analysem\u00f6glichkeiten und dem zuvor direkten Abgleichen mit der Antriebssteuerung lassen sich Aussagen zur Funktionalit\u00e4t der Erweiterung zu einem fr\u00fchen Zeitpunkt treffen.<\/strong><\/p>\n Soll die Antriebssteuerung um eine weitere Funktion erg\u00e4nzt oder ver\u00e4ndert werden (z.B. Anfrage eines Kunden oder Erweiterung der Funktionalit\u00e4t), wird diese oft zuerst mit Hilfe einer Offline-Simulation \u00fcberpr\u00fcft. Diese Simulationsergebnisse k\u00f6nnen in Abh\u00e4ngigkeit der Qualit\u00e4t des gew\u00e4hlten Modells mehr oder weniger belastbar sein. F\u00fcr eine qualifiziertere Aussage muss die Funktion in Maschinensprache umgesetzt und in eine vorhandene Prototypen-Antriebssteuerung implementiert werden. Dieser Prozess kann durchaus zeitaufw\u00e4ndig und fehlertr\u00e4chtig sein, da auf viele Dinge (Variablendefinitionen, Skalierungen, Bedienen von Schnittstellen \u2026) zus\u00e4tzlich geachtet werden muss. Zudem ist die Analysem\u00f6glichkeit (z.B. Vergleich mit der Simulation) eingeschr\u00e4nkt, da nicht alle Signale der Antriebssteuerung zum Betrachten zu Verf\u00fcgung stehen (siehe auch Abbildung 1,\u00a0PDF<\/a>).<\/p>\n Durch die Verwendung einer Rapid Control Prototyping (RCP) Umgebung zur Funktionsentwicklung l\u00e4sst sich funktionsorientierter entwickeln. Rapid Control Prototyping wird in vielen verschiedenen Gebieten zur Funktionsentwicklung verwendet [1]. Die entwickelten Simulationsmodelle, welche nur die Antriebsregelung beinhalten, werden direkt \u00fcbersetzt und auf das RCP-Board geladen. Auf diesem RCP-Board k\u00f6nnen die Funktionen in Echtzeit direkt mit dem Motor getestet und analysiert werden. Erst nach dem Testen mit der RCP-Umgebung wird die neue Funktion in die Antriebssteuerung implementiert (siehe auch Abbildung 2,\u00a0PDF<\/a>).<\/p>\n Mit der RCP-Umgebung stehen viele Signale zum Betrachten zu Verf\u00fcgung, welche analysiert und abgespeichert werden k\u00f6nnen. M\u00f6gliche Implementierungsfehler lassen sich dadurch besser und schneller beheben. Die blockorientierte Darstellungsweise der Funktionen in der Simulation dient dem anschaulichen Verst\u00e4ndnis. Zudem stehen alle Gr\u00f6\u00dfen im Modell dem Regler zur Verf\u00fcgung.<\/p>\n Die Parameter der Modellumgebung (Abtastzeit, Datentypen der Variablen, Aufl\u00f6sung der Messgr\u00f6\u00dfen) werden so angepasst bzw. herunterskaliert, dass diese den gegebenen Umgebungsbedingungen der Antriebssteuerung entsprechen. Unterschiede im Betriebsverhalten lassen sich ausmachen und beheben. Das macht den expliziten Vergleich bzw. Abgleich zwischen Antriebssteuerung und RCP-Umgebung m\u00f6glich. Aussagen \u00fcber die Funktionalit\u00e4t in der Antriebssteuerung k\u00f6nnen aufgrund von Messungen mit der RCP-Umgebung gemacht werden. Die Messergebnisse k\u00f6nnen zudem zur Verbesserung der Modelle in der Offline-Simulation hergenommen werden. Es gibt durchaus mehrere Ans\u00e4tze zur Realisierung der Funktionen. Diese werden mit den gegeben Bedingungen getestet und miteinander verglichen. So kann fr\u00fcher und besser die Performance verschiedener L\u00f6sungsans\u00e4tze bewertet werden. Durch die fr\u00fchen Tests mit angeschlossenem Motor lassen sich die Ergebnisse der Offline-Simulation pr\u00e4zisieren.<\/p>\n Die Entwicklungsumgebung besteht aus zwei Hauptkomponenten, der Simulationssoftware und dem RCP-Board. Mit der Simulationssoftware (hier MATLAB\/SIMULINK von Mathworks) werden die n\u00f6tigen Modelle erstellt und \u00fcbersetzt. Diese werden dann auf das RCP-Board (hier DS1005 mit ACMC Modul [2] von dSPACE) geladen und mit der dazugeh\u00f6rigen Software (hier ControlDesk [3] von dSPACE) \u00a0betrieben. Das hier eingesetzte RCP-Board stellt verschiedene Ein- und Ausg\u00e4nge bereit, unter anderem unterschiedliche Encoder-Schnittstellen und eine PWM-Einheit zur Block- und Sinuskommutierung. Mit der dazugeh\u00f6rigen Software lassen sich alle m\u00f6glichen Signale im Modell anzeigen und abspeichern sowie Parameter des Modells ver\u00e4ndern (siehe auch Abbildung 3,\u00a0PDF<\/a>).<\/p>\n Eine Vielzahl an Motoren aus dem Produktportfolio der Firma Faulhaber [4] lassen sich f\u00fcr Tests mit der RCP-Umgebung betreiben. Dazu geh\u00f6ren b\u00fcrstenbehaftete, b\u00fcrstenlose DC-Motoren sowie auch b\u00fcrstenlose lineare DC- Servomotoren in unterschiedlichen Baugr\u00f6\u00dfen und Spannungsvarianten. Inkremental- und Absolutencoder sowie analoge oder auch digitale Hall-Sensoren sind m\u00f6gliche Geber, welche mit den Motoren kombiniert werden.<\/p>\n Folgende zus\u00e4tzlich entwickelte Treiber-Hardware ist f\u00fcr den Betrieb dieser Motorvarianz n\u00f6tig: Die Motoren und Geber werden an das Carrier-Board angeschlossen und bei einer Betriebsspannung mit bis zu 24 V betrieben. Auf dem Carrier-Board werden zudem die Phasenstr\u00f6me und Phasenspannungen der Motoren gemessen. Die Endstufen und die Signalverarbeitung f\u00fcr die Geber werden als Module aufgesteckt. Verschiedene Doppel-N Kanal- aber auch PN-Kanal Endstufen-Module k\u00f6nnen f\u00fcr den Betrieb verwendet werden. Das zus\u00e4tzliche Connector-Board stellt das Bindeglied zwischen RCP-Board und Carrier-Board dar. Durch Umsteckm\u00f6glichkeiten auf dem Connector\u2013Board und Umschaltm\u00f6glichkeiten im Simulationsmodell lassen sich die Ein- und Ausg\u00e4nge auf verschiedene Weise nutzen und schnell f\u00fcr einen anderen Motor umkonfigurieren.<\/p>\n Durch die verschiedene Motortechnologien, sehr vielen Motorvarianten mit unterschiedlichen Gebertechnologien und den schier grenzenlosen Lastf\u00e4llen ergibt sich eine Vielzahl an Kombinationsm\u00f6glichkeiten, welche abgedeckt werden m\u00fcssen. Zus\u00e4tzlich entwickelte MATLAB-Skripte erleichtern und beschleunigen das Umkonfigurieren des Modells. So kann \u00fcber eine Bedienoberfl\u00e4che das vorliegende System konfiguriert werden. Die Parameter f\u00fcr Regler- und Simulations-Initialisierung der ausgew\u00e4hlten Systemkonfiguration werden mit Motorparameter aus einer Datenbank erstellt. Mit der Bedienoberfl\u00e4che k\u00f6nnen Parameter-Files abgespeichert werden, um das Simulations-Modell direkt auf dem RCP-Board nach einer Hardware\u00e4nderung umparametrieren zu k\u00f6nnen (siehe auch Abbildung 4,\u00a0PDF<\/a>).<\/p>\n Das Ausw\u00e4hlen der unterschiedlich vorhandenen Modelle, welche sich in der Funktion unterscheiden, wird auch \u00fcber die Bedienoberfl\u00e4che organisiert. Ebenso wird das Erstellen der RCP-Modelle (Build-Prozess) f\u00fcr die RCP-Plattform \u00fcber die Bedienoberfl\u00e4che gestartet, was das \u00c4ndern und Wiederverwenden der Modelle beschleunigt.<\/p>\n Die zu Beginn explizit entwickelten RCP-Simulationsmodelle bilden das Antriebsverhalten der Antriebssteuerung ab. Diese setzen sich zusammen aus der Signalverarbeitung f\u00fcr Geber und diverser Anlog-Gr\u00f6\u00dfen, der Antriebssteuerung mit den verschiedenen Kommutierungsvarianten sowie der Antriebsregelung. Die Ergebnisse des RCP-Modells m\u00fcssen mit der Antriebssteuerung gr\u00fcndlich abgeglichen werden, um die Gleichheit beider Systeme \u00fcberpr\u00fcfen zu k\u00f6nnen.<\/p>\n Der Abgleich der abgespeicherten Messungen dient nicht nur zur \u00dcberpr\u00fcfung der Systeme untereinander. Er wird zudem verwendet, um die Verbesserung der zus\u00e4tzlichen Funktion darstellen zu k\u00f6nnen. Der Abgleich mit den Ergebnissen der Offline-Simulation kann helfen, die Modellqualit\u00e4t zu verbessern (siehe auch Abbildung 5,\u00a0PDF<\/a>).<\/p>\n Die aufgenommenen Messungen von RCP-Umgebung und Antriebssteuerung werden mit den jeweiligen Programmen exportiert. Der Dateiname beinhaltet die relevante System- und Messinformationen. \u00dcber die Bedienoberfl\u00e4che wird das gew\u00fcnschte System konfiguriert und \u00fcberpr\u00fcft, ob f\u00fcr diese Konfiguration Messungen vorhanden sind. Die ausgew\u00e4hlten Messungen werden importiert, skaliert und anschlie\u00dfend in einem Plot zusammen dargestellt. Der Abgleich der Systeme findet \u00fcber das Darstellen der jeweiligen Messungen der Systeme statt.<\/p>\n Durch den Einsatz der Entwicklungsumgebung ist das funktionsorientierte Entwickeln und Testen an der realen Hardware zu einem fr\u00fchen Zeitpunkt in der Entwicklungsphase m\u00f6glich. Daraus ergibt sich eine bessere Systemanalyse und im Gegenzug eine z\u00fcgige Aussage \u00fcber die Funktionalit\u00e4t. Es lassen sich verschiedene Antriebe in wenigen Schritten mit der RCP-Entwicklungsumgebung betreiben. Das \u00dcbereinanderlegen der Simulationsergebnisse mit Messungen der RCP-Umgebung bzw. Messungen der Steuerung verbessert den Vergleich und die Analyse der Systeme untereinander. Fortf\u00fchrend k\u00f6nnen auf dieser Basis weitere Algorithmen\/Regler funktionsorientiert mit der RCP-Umgebung an verschiedenen Antrieben entwickelt und verifiziert werden. Die Programmierung der Controller wird bereits mittels UML-Programmen und Codegenerator [4] beschritten. Die Idee ist hier, dass die zus\u00e4tzlichen Funktionen, welche in der Simulation entwickelt worden sind,\u00a0 direkt in die Antriebssteuerung codegeneriert implementiert werden.<\/p>\nFunktionsentwicklung f\u00fcr Antriebssteuerungen<\/h2>\n
Funktionsentwicklung mit der Rapid Control Prototyping-Umgebung<\/h2>\n
Entwicklung der Hardware- und Softwarekomponenten<\/h2>\n
Variantenhandling<\/h2>\n
Abgleich der Entwicklungsumgebung mit der Antriebssteuerung<\/h2>\n
Zusammenfassung und Ausblick<\/h2>\n
Literaturverzeichnis<\/h2>\n