Modellbasiertes Design strafft Entwicklung von Embedded-Motorsteuerungen

Die System- und Schaltungsmodellierung ist seit langem ein wichtiger Aspekt beim Entwurf von Motorsteuerungssystemen. Modellbasiertes Design (MBD) nutzt elektrische, mechanische und System-Level-Modelle, um Entwicklungskonzepte bereits vor der Realisierung und dem Test physikalischer Hardware zu evaluieren. Die neusten Simulationstools von Mathworks können komplette Embedded-Control-Systeme einschließlich der elektrischen Schaltungen und mechanischen Systeme modellieren. Geeignete Embedded-Programmiertools erzeugen aus Systemmodellen C-Code für die direkte Implementierung von Steueralgorithmen in Embedded-Control-Plattformen.

Diese Tools ermöglichen einen modellbasierten Entwicklungsprozess, bei dem Steueralgorithmen vor dem endgültigen Hardware-Test auf einer Simulationsplattform entwickelt und komplett getestet werden können. Entscheidend für die Realisierung einer erfolgreichen MBD-Plattform ist die Partitionierung des Systemmodells und des Embedded-Software-Codes. Sobald die MBD-Plattform mit einem bekannten Algorithmus im System getestet ist, lassen sich neue Algorithmen entwickeln und auf der Simulationsplattform bei Grenzwerten des Systembetriebs testen.

Der Entwicklungsablauf

Modellbasiertes Design ist eine mathematische und visuelle Methode, die beim Entwurf von Embedded-Control-Systemen zum Einsatz kommen kann. Anstatt komplexe Strukturen und umfangreichen Software-Code manuell zu erstellen, können Entwickler mithilfe von MBD Modelle selber definieren oder aus umfangreichen Bibliotheken mit Funktionen auf der Basis von Continuous-Time- und Discrete-Time-Funktionsblöcken auswählen und diese parametrieren. Solche Modelle lassen sich in Verbindung mit Simulationstools zum Rapid Prototyping, in Software-Test und Hardware-in-the-Loop-Simulationen (HIL)  verwenden.  Mithilfe von Simulation können Entwickler eventuelle Modellierungsfehler und Abweichungen von Spezifikationen sehr frühzeitig im Entwicklungsprozess erkennen. Im Vergleich zur manuellen Programmierung senkt eine automatische Codegenerierung den Entwicklungsaufwand und beschleunigt die Entwicklungsdauer sowie die Markteinführung.

Das MBD-Konzept eröffnet Entwicklern anstelle der klassischen Entwicklungsmethoden neue Wege direkt von der Modell-Erstellung über Simulation und Code-Generierung bis zum HIL-Test. Auf diese Weise kann der Entwickler funktionale Änderungen im System ohne aufwendiges Redesign schnell und einfach umsetzten.

Als Beispiel für den Einsatz von modellbasiertem Design dient im Folgenden der experimentelle Aufbau eines Motorsteuerungssystems mit Regelkreis (Bild 1). Dieses System repräsentiert einen voll funktionsfähigen PMSM-Motorantrieb mit Netzspeisung einschließlich Leistungsfaktorkorrektur, galvanischer Trennung von Steuerungs- und Kommunikationssignalen sowie optischem Drehwinkelgeber. Kern des Systems ist ein ADSP-CM408 mit einem ARM Cortex-M4. Mit kombinierten Tools von IAR und Mathworks implementierte Analog Devices die komplette MBD-Plattform in diesem ASSP (Application Specific Signal Processor).

Bild 0: Prototyp der Motorsteuerung für einen permanenterregten Synchronmotor (PMSM) mit Drehwinkelgeber.Analog Devices

Funktionsblöcke der Motorregelung

Das Antriebssystem besteht aus einem Dreiphasen-Leistungs-Inverter mit galvanisch getrennter Phasenstromrückkopplung und einem permanenterregten Synchronmotor mit Drehwinkelgeber. Im ASSP implementiert sind die Verarbeitung der Motorrückkopplungssignale, die Ansteuerung des Leistungsinverters sowie Regler und Kommunikationsschnittstelle.

Für Modellierungszwecke besteht das System aus drei Hauptblöcken: Leistungsinverter und Motor (Plant), Control-Feedback-Schaltungen und digitaler Controller. Das Plant-Modell nutzt Simulink-Simscape-Komponenten zur Simulation der Inverterschaltung und der elektromechanischen Motorelemente im Continuous-Time-Bereich. Die Feedback-Schaltungsmodelle sorgen für die Signalaufbereitung und Datenumwandlungen zwischen den Controller- und Motorantriebsmodellen.

Simulink-Embedded-Programmiertools erzeugen Embedded-C-Code, mit welchem der Algorithmus sowohl auf der Simulationsplattform als auch auf dem Embedded-Controler lauffähig ist. Die erfolgreiche Umsetzung des MBDs erfordert sorgfälltig definierte System- und Schaltkreismodelle sowie eine geeignete Aufteilung zwischen Systemmodell und der Embedded-Control-Software. Wegen der Mischung aus zeitdiskreten und zeitkontinuierlichen Funktionen im System kommt bei der Simulation ein diskreter Fixed-Step-Solver zu Einsatz.

Platinenaufbau

Die Hardware des Antriebssystems besteht aus Leistungsplatine, Steuerungsplatine und Motor mit Drehwinkelgeber (Bild 1). Die Platine enthält einen Eingangsgleichrichter, ein Dreiphasen-Invertermodul, Strom- und Spannungssensoren, Optokoppler zur galvanischen Trennung von digitalen und analogen Rückkopplungssignalen und einen Signalpuffer für den Drehwinkelgeber.

Bild 1: MBD-Systemplattform einer Motorsteuerung mit geschlossenem Regelkreis.Analog Devices

Die Steuerungsplatine enthält den mit 240 MHz getakteten ASSP und die Motorsteuerungsperipherie bestehend aus PWM-Timer, Quadratur-Encoder-Zähler, SINC-Filter und Embedded-A/D-Wandler. Optional können als Motor-Stromrückkopplung kontaktlose Stromsensoren mit dem Embedded-ADC oder Strom-Shunts mit einem galvanisch trennenden Sigma/Delta-Wandler zum Einsatz kommen.

Die Erfassung der Rückkopplungssignale und die Ausführung des Steueralgorithmus sind auf die vom Prozessor-Interrupt-Mechanismus abgeleitete PWM-Schaltfrequenz synchronisiert. Die Simulation nutzt die gleiche Schaltfrequenz. Der Leistungsinverter nutzt ein Average-Value-Modell, da die Signalsimulation kein brauchbares Steuersignal liefert.

Bild 2: Modell des FOC-Algorithmus zur Motorsteuerung.Analog Devices

Der Motorsteuerungs-Algorithmus

Das Motormodell der SimPowerSystems-Bibliothek ist konfigurierbar, bietet diverse Preset-Modellparameter und lässt den Anwender zwischen einem Custom-Motor- oder einem Inverter-Modell auswählen.

Die zeitdiskreten Funktionen des Motorsteuerungs-Algorithmusmodells lassen sich bei jedem Zeitschritt sowohl auf Simulationsebene wie auch auf der Embedded-Plattform ausführen. Typischerweise sind die Motorreglerfunktionen in einem Subsystemblock enthalten, um den Code-Erzeugungsprozess zu vereinfachen. Der Code-Generator erzeugt vom Steueralgorithmus und seinen Datenstrukturen  ausführbaren C-Code. Der Algorithmus selbst nutzt FOC (feldorientierte Regelung), welcher eine Drehzahlregelschleife mit externem Geber und Stromschleifenregelung mit internen Stromwerten der d-Achsen- und q-Achse enthält (Bild 2).

Die Inverter-Schnittstellen- und Rückkopplungs-Pfade sind in Signalaufbereitungs- und Embedded-Schnittstellenblöcke aufgeteilt. Bei den Stromsensor- und Signalaufbereitungsmodellen handelt es sich um einfache Verstärkerelemente. Das Lagesensormodell ist komplexer, da es ein hochauflösendes inkrementales Lagesignal und ein niedrigauflösendes absolutes Lagesignal verarbeiten muss.

Die Modelle für die Embedded-Signalschnittstelle beinhalten Typ-Wandlungsfunktionen, da die ADCs, SINC-Filter, Zähler und Timer-Peripherie 16- oder 32-bit-Festkomma-Ausgangsdatenregister haben. Das Übertragungsverhalten jeder Embedded-Schnittstelle ist abhängig von der Peripherie-Systemtaktrate, der Abtastrate und den Interface-Register-Einstellungen. Um genaue Simulationsergebnisse zu erzielen, ist eine Anpassung der Modellparameter an die Embedded-Systemkonfiguration erforderlich.

Software-Partitionierung und Code-Erzeugung

Das Motorantriebssystem führt neben der Motoransteuerung weitere Funktionen aus. Für Plattformflexibilität und einfache Entwicklung ist die Embedded-Software in mehrere Funktionsmodule unterteilt. Die wesentlichen Funktionsblöcke sind Systeminitialisierung, Kommunikationsschnittstelle, Applikationsaufgaben, Motorsteuerungsschnittstelle und Motorsteuerungsalgorithmus. Bild 3 beschreibt den High-Level-Drive-Programmablauf, Bild 4 die Code-Struktur.

Bild 3: Interrupt-Service-Routinen des High-Level-Drive-Programms.Analog Devices

Das Hauptprogramm ruft die Initialisierung auf, welche die ASSP-Hardware konfiguriert, und versetzt den Prozessor anschließend in eine Warteschleife. Alle anderen Funktionen werden durch ereignisgesteuerte Interrupt-Service-Routinen (ISRs) aufgerufen. Der ADC-Interrupt hat höchste Priorität. Die ADC-ISR ruft die Motorsteuerungsfunktionen auf, wenn neue Sensordaten bereit stehen. Das ADC-Sampling ist auf die PWM-Schaltfrequenz synchronisiert und steuert die Regelschleife. Die ADC-ISR führt jeden PWM-Zyklus aus. Sie ruft die Motorsteuerungsroutine (PMSMctrl) jedoch nur auf, wenn das Motor-Run-Flag gesetzt ist. Die Auswahl des Motorstrom-Rückkopplungspfades erfolgt vor der Code-Erstellung.

Der PWM-Trip-Interrupt ist asynchron und wird nur bei einem Hardware-Fehler aufgerufen. Als einzige Funktion gibt sie einen Fehler aus, wenn sie die Inverteransteuerung automatisch abschaltet. Die Kommunikationsport-ISR hat eine geringere Priorität. Sie verarbeitet Anwenderbefehle und überträgt Daten, die von einer Debug-Monitor-Funktion erfasst werden. Die Kernel-Timer-ISR verwaltet Hintergrund-Applikationsaufgaben wie etwa Motor-Start- und Stop-Sequencing, die Debug-Monitor-Schnittstelle und andere Housekeeping-Aufgaben.

Bild 4: Code-Partitionierung.Analog Devices

Der Embedded-Code ist nach Funktionsblöcken organisiert anstatt nach Programmablauf. Die System-Initialisierung legt Prozessortaktsignale sowie Leistung und Kernel-Timer standardmäßig fest. Dies erfolgt fast unabhängig von der Applikationsfunktion. Die Kommunikation und Applikations-Task wird durch die Anwenderschnittstelle und System-Management-Anforderungen definiert. Beide sind fast unabhängig vom Motorsteuerungsalgorithmus.

Die Motor-Control-Schnittstellen-Funktion verwaltet den Signaldatenfluss zwischen der Motorantriebs-Hardware und dem Steuerungsalgorithmus. Sie ist abhängig vom angeschlossenen Motor und Drehwinkelgeber (Lagesensor) sowie von der Konfiguration der Rückkopplungssignale. Simulink erzeugt den Motorsteueralgorithmus plattformunabhängig; er enthält Datenstrukturen für Rückkopplungs- und Ansteuerungssignale. Der restliche Treibercode wird manuell erstellt.

Bild 5: Partitionierung des Systemmodells.Analog Devices

Implementierungsdetails

Um MBD optimal einzusetzten, ist es wichtig, die Detailanforderungen für die Modellierung der verschiedenen Teile des Motorsteuersystems zu verstehen und die kritischen physikalischen Systemparameter so genau wie möglich mit den entsprechenden Modellparametern übereinzubringen. Dies beinhaltet auch die Partitionierung des modellierten Systems in unterschiedliche Bereiche. Als generelle Regel genügt es, das gesamte System als PWM-averaged zu modellieren, das bedeutet eine Mittelung des hochfrequenten PWM-Trägersignals sowie eine Ausblendung von PWM-Ripple oder höherfrequenten Störanteilen in Spannungs- oder Stromsignalen.

Tabelle 1Analog Devices

Das Systemmodell ist in logische Blöcke partitioniert. Jeder Block ist, wie im Bild 5 rechts angedeutet, weiter unterteilt. Jeder Unterblock hat ein geeignetes Modellierungskonzept (Tabelle 1). Der Block „User Commands“ ist in dieser Liste nicht enthalten. Die Benutzerbefehle (User Commands) werden im C-Code als globale Parameterstrukturen in den Core-Algorithmus eingebunden. Damit das korrekt abläuft, müssen diese Befehle im Simulink-Algorithmus als global veränderliche Parameter definiert sein.

Bild 6a: Modell-Code Schnittstelle.Analog Devices

Einstellungen zur Code-Erzeugung

Maximale Code-Portabilität und einfache Wartung lassen sich durch Einstellung der automatische Code-Erzeugung als nicht-target-spezifisch erreichen; abgesehen von den Basiseinstellungen wie Typ-Größe, Byte-Ordering und weiteren. Mathworks bietet prozessorspezifische Code-Erzeugungsmodule an, welche Prozessorperipherie und Treiber direkt ansprechen können. Während diese Möglichkeit für einige Anwendungen attraktiv sein mag, liegt der Nachteil jedoch im unhandlichen, weniger portabelen Code. Zudem bedeuten alle Änderungen an Gerätetreibern oder in der Peripheriekonfiguration (beispielsweise eine neuen Prozessorvariante) Änderungen am Code.

Bild 6b: Modell-Code Verteilung.Analog Devices

Daher ist im hier präsentierten Entwurfsbeispiel die Code-Erzeugung ausschließlich auf den Steuerungsalgorithmus beschränkt (Bild 6a). Für sämtliche Peripheriefunktionen gibt es Simulink-Modelle; sie werden im Hauptanwendungsprojekt von Hand codiert beziehungsweise eingebunden. Bild 6b zeigt, wie die Code-Erzeugung vom Mathworks-Controller-Modell mit den anderen Code- und Bibliotheksmodulen des Hauptanwendungsprojektes verknüpft werden.

Bild 7 zeigt das Simulink-Modell mit partitionierten Modellblöcken. Wie angedeutet, wird der Code nur aus einem Teil des Motorsteuerungsmodells, vom Steuerungsalgorithmus, erzeugt. Wichtige Einstellungen für diese Code-Erzeugung erfolgen im Fenster „Configuration Parameters->Hardware Implementation“, wo ein Device-Typ gewählt werden kann, und im Fenster „Configuration Parameters->Code Generation->Interface“, wo die Standard Math-Bibliothek gewählt wird.

Bild 7: Modellierung und Code-Erzeugungs-Einstellungen.Analog Devices

Sprachdialekte von C89/90 und C99

Ein weiterer Faktor im Hinblick auf die Software-Effizienz ist der verwendete Sprachdialekt der Hochsprache C. Zwei übliche Dialekte, die von den meisten Code-Erzeugungstools und Embedded-Workbenches unterstützt werden, sind C89/90 und C99. In erster Linie ist es wichtig, dass alle Tools den gleichen Dialekt nutzen. Falls zum Beispiel die Embedded-Workbench so konfiguriert ist, dass Code entsprechend C99 erstellt wird, müssen auch die automatischen Code-Erzeugungstools Code entsprechend des Standards C99 generieren. Andernfalls kann dies zu einer wesentlich reduzierten Leistungsfähigkeit der Software führen, im ungünstigsten Fall sogar zu unbeabsichtigten Funktionen der Software.

Ein anderer wichtiger Faktor ist die Festkomma-Darstellung im Gegensatz zu Gleitkomma. Beide Codierungsdialekte unterstützen Festkomma. In diesem Fall ist die Wahl des Dialekts unerheblich, solange alle Tools den gleichen Dialekt nutzen. Werden jedoch Gleitkommatypen genutzt, wird die Wahl des C-Dialekts wesentlich wichtiger.

C89/C90 unterscheidet nicht zwischen Single- und Double-Precision-Gleitkomma. Falls der Code auf einem Prozessor laufen soll, der Double-Precision unterstützt, ist das akzeptabel. Bei einem Prozessor, der lediglich Single-Precision unterstützt, wie beispilesweise ein ARM Cortex M4, macht die Unterscheidung einen großen Unterschied. In diesem Fall ist sicherzustellen, dass das Auto-Code-Generation-Tool sowie die Embedded-Workbench den Dialekt C99 nutzen.

Simulink Parameter

Bild 8: Organisation der Code-Module und Funktionsaufrufe für den Algorithmus.Analog Devices

Simulink stellt Toolboxen wie Simscape und Simmechanics bereit, um das elektromechanische System auf einfache Weise zu modellieren, sobald physikalische Parameter bekannt sind. Selbst wenn physikalische Parameter nicht vollständig charakterisiert sind, lassen sich vordefinierte Modelle von Komponenten, zum Beispiel Motoren, mit etwa passenden Spezifikationen für erste Entwürfe des Motorsteueralgorithmus verwenden. Für den Algorithmus selbst gibt es einige nützliche Funktionsblöcke wie Park-Transformationen oder Sinus-Cosinus-CORDIC-Approximation, welche die Entwicklung des Motorsteueralgorithmus vereinfachen.

Grundstruktur des Hauptprogramms

Die Auto-Code-Schnittstelle ist definiert durch einen Funktionsaufruf der Initialisierung, gefolgt von einem oder mehreren Time-Step-Funktionsaufrufen, die innerhalb des Haupt-Programms zu geeigneten Zeitpunkten erfolgen müssen. In diesem Beispiel gibt es zwei Time-Step-Funktionen – den Haupt-Steueralgorithmus, dessen Aufruf mit der PWM-Frequenz von 10 kHz erfolgt, und eine Geschwindigkeits-Messfunktion, die mit 1 kHz aufgerufen wird (Bild 8).

Bild 9a: Reglergeschwindigkeit im modellierten und experimentellen Betrieb. Analog Devices

Wie angedeutet, ist der Code modular organisiert. Dieses führt zu einer geradlinige Integration von applikationsspezifischen Funktionen wie Networking und Schutz. Tasks mit hoher Priorität, wie etwa der Motorsteueralgorithmus, rufen die ISRs in Bild 3 auf. Auf Applikationsebene ruft das Basis-Scheduler-Kernel geplante Tasks (Scheduled Tasks) auf. Die MC-Interface-Routinen befinden sich in den Motor-Control- und Measure-Code-Blöcken, wobei letzterer den Code für das gesamte Handling des Stromrückkopplungsignals beinhaltet. Der ADI-Monitor-Code enthält die Debugging-Monitor-Funktion für den Systemtest. Applikations- und Steueralgorithmus-Signaldaten werden bei aktivem Monitor erfasst. Die Datenübertragung an einen PC erfolg über eine serielle Verbindung zur Darstellung und Analyse.

Bild 9b: q-Achsen-Strom-Referenz für modellierten und experimentellen Betrieb. Analog Devices

Systemtest und Debugging

Nach der Ermiitlung der kritischen Parameter von Tabelle 1 durch Messungen, Berechnungen und Datenblätter lassen sich die jeweiligen Verstärkungsparamter für Drehzahl- und Stromregelschleife mit Hilfe des Simulink-Modells bestimmen. Standard PID-Tuning-Konzepte oder das von Mathworks angebotene PID-Tuner-Tool können hierbei unterstützen.

Die Bilder 9 und 10 zeigen das Verhalten der Stromschleife für den modellierten und den experimentellen Betrieb. Die Abtastung der experimentellen Daten erfolgt in diesem Plot zur Vermeidung von Aliasing nur alle 5ms; der Haupttrend ist jedoch klar ersichtlich.

Bild 10: Leistungsfähigkeit der Stromschleife - modellierte und experimentelle Ergebnisse. Analog Devices

Die Leistungsfähigkeit des modellbasierten, automatisch erzeugten Codes lässt sich durch Untersuchung des zeitlichen Programmablaufs während einer PWM-Periode beurteilen. Dies kann mit Hilfe von I/O-Pins und einem Oszilloskop erfolgen oder auf einfachere Weise mit dem ITM-Event-Feature im Embedded-Workbench-Debugger CSPY von IAR. Die Sequenz von Ereignissen im PWM-Zyklus ist in Bild 11 dargestellt.

Zu Beginn jedes neuen PWM-Zyklus‘ tritt ein PWM-Synchronisationsimpuls auf, der in Hardware mit dem ADC-Timer verbunden ist, welcher das Sampling jedes ADC-Kanals steuert. In diesem Fall erfolgt die Abtastung von Motorströmen sofort nach dem PWM-Sync-Impuls, um sie dann per DMA (Direct Memory Access) in den Speicher zu schreiben. Anschließend werden die Algorithmusfunktion aufgerufen und aktualisierte Werte für das PWM-Tastverhältnis erzeugt. Wie Bild 11 zeigt, benötigt die Ausführung des modellbasierten automatisch erzeugten Codes weniger als 10 % des PWM-Zyklus‘, was genügend Spielraum für zusätzliche Hintergrund-Tasks lässt. Bisherige Bedenken bezüglich der Effizienz von automatisch erzeugtem Code werden damit zunehmend hinfälliger.

Bild 11: Zeitlicher Programmablauf während einer PWM-Periode.Analog Devices

Die relative Größe des Algorithmus-Auto-Codes ist aus Tabelle 2 ersichtlich. Der automatisch erzeugte Code beansprucht lediglich etwas über 10 KByte Speicher, was fast 15 % des gesamten Speichers entspricht. Mit 384 KByte erfüllt das verfügbare SRAM auf dem ADSP-CM408 diese Speicheranforderung leicht. Somit kann das Programm vom SRAM aus mit der höchstmöglichen Geschwindigkeit laufen. Dabei gibt es mehr als genügend Spielraum für komplexere Algorithmen und/oder zusätzliche Monitoring- oder User-Interface-Funktionen.

Tabelle 2: Größen von Code-Modulen.Analog Devices

Applikationsentwicklung

Die Prämisse der hier diskutierten Software war ein aus zwei Hauptkomponenten bestehendes System. Die erste ist eine modellbasierte Komponente, die Steueralgorithmen enthält. Obwohl das Modell unter Berücksichtigung des Embedded-Targets entwickelt wurde, ist der vom Auto-Generation-Tool erzeugte Code im Wesentlichen generisch. Zweitens gibt es eine per Hand geschriebene Software-Komponente, die den generischen Algorithmus-Code an das Embedded-Target anbindet, das Task-Scheduling behandelt und Prozessor-Ressourcen zuweist. Im Hinblick auf die Wiederverwendung von Modellen sowie die Skalierbarkeit, bietet diese Systempartitionierung mehrere Vorteile.

Systemerweiterung um eine zweite Achse

Die bisher betrachtete einachsige Motorsteuerung wird nun auf zwei Achsen erweitert. Das bedeutet zunächst einmal eine schwerwiegende Änderung des Systems. An diesem Punkt wird die Stärke von generischen Modellen offensichtlich. Das bereits entwickelte einachsige Modell machte keine Annahmen bezüglich der Prozessorperipherie. Es ist ein allgemeiner Steueralgorithmus für einen PMSM-Motor. Um das Modell auf zwei Achsen zu erweitern, muss lediglich eine zweite Instanz des einachsigen Modells erzeugt werden.

Die Anpassung von manuell geschriebenme Code erfolgt  entsprechend für zwei Achsen. Hat der Prozessor eine geeignete Peripherie und genügend Rechenressourcen, sind die Modifikationen an dem von Hand geschriebenen Code recht einfach. Unabhängig von der Anzahl der zu steuernden Achsen der von Hand geschriebene Codes gilt es, dem Modelleingang Werte zuzuordnen, den Modellausgang an die Prozessorperipherie weiterzuleiten und zu terminieren, wann das Modell ausgeführt werden soll. Daher geht es beim Übergang von einer auf zwei Achsen im Wesentlichen um die Konfiguration von Peripherie und die Terminierung der Ausführung des Algorithmus‘ der hinzugefügten Achse. Das Verfahren ist durchgängig und möglich durch Verwendung generischer Modelle.

Die Vorteile des modellbasierten Designs sind eher gering, wenn nur ein One-Control-System entwickelt wird. In den meisten Fällen jedoch bedeutet Produktentwicklung mehrere Produktvarianten. Hier wird die Wiederverwendung von Modellen attraktiv, nicht nur wegen der verkürzten Entwicklungszeit, sondern auch wegen der erhöhten Qualität, die aus dem Einsatz vertrauenswürdiger Modelle resultiert. Im Laufe der Zeit wird ein Funktionsentwickler eine Bibliothek mit Modellen erstellen, die – falls korrekt implementiert – produktübergreifend wiederverwendbar sind. Generische Modelle sind auf heutigen sowie auf künftigen Prozessoren lauffähig.

Zur Erfüllung von Anforderungen für Produktvarianten oder die Steuerung mehrerer Achsen können Entwickler manchmal verschiedene Controller-Betriebsarten zur Verfügung stellen. Ein typisches Beispiel ist eine Applikation mit Betriebsarten zur Drehmoment-, Drehzahl- und Positionssteuerung. Die Entwicklung eines Algorithmus zur Positionssteuerung kann in Ebenen erfolgen, aufbauend auf den grundlegenden Funktionsblöcken der Algorithmen zur Strom- und Geschwindigkeitssteuerung.

Bild 12: Profilierte Positionsreferenz.Analog Devices

Positionssteuerungsschleife

In den meisten Applikationen wird eine Positionssteuerungsschleife als äußere Schleife um die innere Drehzahl- und Stromregelschleife genutzt. Ein Basis-Positions-Controller erfordert nur einen proportionalen Verstärkungsausdruck (Gain Term). Ein integraler Ausdruck ist nicht generell erfoderlich, da jeder Steady-State-Fehler in der Positionsschleife in einer Non-Zero-Geschwindigkeitsreferenz resultiert. Davon ausgehend, dass die inneren Strom- und Drehzahlschleifen gut abgestimmt sind, können diese als ideale Blöcke mit Verstärkung Eins (Unity-Gain-Blöcke) betrachtet werden, so dass die Abstimmung der Positionsschleife damit recht einfach ist.

Zusätzlich zu der äußeren Proportionalsteuerschleife kann es wichtig sein, ein Positions-Referenzprofil einzubinden, damit Lasten mit definierter Beschleunigung und Verzögerung bewegt werden. Dies ist wichtig zur Minimierung der mechanischen Belastung in vielen Systemen. In diesem Applikationsbeispiel kommt ein Profil mit konstanter Beschleunigung, konstanter Drehzahl und kontanter Verzögerung auf die Änderung der Positionsreferenz zum Einsatz (Bild 12). Das Ausmaß, mit dem die tatsächliche Geschwindigkeit diesem Profil folgt, hängt vom dynamischen Verhalten des Geschwindigkeits-Controllers ab.

Diese gesamte Funktionalität – Positionsregelkreisverstärkung (Position Loop Gain), Positions-Profil sowie unterstützende Funktionen (Ancillary Functions) wie beispielsweise Anfangspositionierung und Endlageerkennung – ist in Form zusätzlicher Blöcke im modellbasierten Teil des Codes implementiert. Die einzige zusätzliche Änderung im von Hand geschriebenen Code ist die Konfiguration der I/Os zur Implementierung von Anfangsposition (Home Position) und Endlagesignalen (End-Stop-Signals).

(jwa/av)