Zugegeben: Es existieren einfache Lösungen der elektronischen Kommutierung von bürstenlosen Gleichstrommotoren. Trapez-Kommutierung etwa ist eine Methode, die für viele Anwendungen ausreicht. Allerdings wird dabei immer jeweils eine der Statorwicklungen nicht genutzt. Es hat sich außerdem gezeigt, dass dieses Umschalten nur bei höheren Drehzahlen ab 500 Umdrehungen pro Minute aufwärts  gut funktioniert, bei langsamen Drehzahlen – sprich besonders unter 100 Umdrehungen – wird die Steuerung ungenau.Wesentlich gleichmäßiger laufen sinusförmig kommutierte Motoren. Die drei Wicklungen des Stators werden mit phasenversetzten sinusförmigen Signalen gesteuert.

Dies ermöglicht eine sehr gleichmäßige und genaue Steuerung vor allem in einem niedrigen Drehzahlbereich von zum Beispiel zehn Umdrehungen pro Minute. Das Problem hierbei ist aber, dass die PI-Regler mit steigender Frequenz der Sinuswellen zeitabhängige Fehler aufbauen. Das geht bis zu einem Punkt, an dem sich die Phasen verschieben und kein Drehmoment mehr erzeugt wird. Höhere Geschwindigkeiten sind mit der sinusförmigen Kommutierung daher nicht möglich.

Kurzum: Die genannten, einfachen Lösungen der elektronischen Kommutierung von bürstenlosen Gleichstrommotoren sind für anspruchsvollere Anwendungen, wie etwa in der Robotik, nicht geeignet.

Die feldorientierte Regelung

Feldorientierte Regelung (FOC) geht die Probleme der Kommutierung an, indem sie sich auf den Raumzeiger im Referenzsystem des Rotors bezieht. Wie führt der Weg dahin? Es geht darum, die beiden Magnetfelder in einem elektrischen Motor in ein optimales Verhältnis zu setzen. Der Rotor besteht aus einem Permanentmagneten, gibt also ein Magnetfeld vor. Der Stator muss das zweite Magnetfeld durch drei um 120° versetzte Spulen generieren. Diese drei Spulen werden an einer Gleichspannung, genannt Zwischenkreis, laufend zwischen Plus und Minus umgeschaltet. Ein spezielles Pulsmuster ist dafür in einer Tabelle abgelegt. Zeigt man die Werte dieser Tabelle grafisch an, so war dies früher – wie bereits erwähnt – eine reine Sinuskurve. Diese Sinuskurve wurde in der weiteren Verfeinerung der Methode „aufgebläht“: Zuerst mit einer dritten Oberwelle, dann mit dem Raumvektor.

In den drei Spulen entsteht also ein sich drehendes Magnetfeld – je nachdem wie schnell die Tabellen durchlaufen werden. Dieses Magnetfeld könnte den Rotor nun einfach mitnehmen. Ein Drehmoment entsteht aber immer erst, wenn das Statorfeld etwas vorauseilt; der Rotor zieht nach und das Drehmoment wird wieder zu 0. Die Magnetfelder von Rotor und Stator stehen dann in einer Linie. Dieser Zustand ist für den Motor aber sehr gefährlich, das Drehmoment minimal und der Strom in den Phasen sehr hoch. Zudem würde sehr viel Energie zwischen Motor und Zwischenkreis pendeln. Dies ist der denkbar schlechteste Zustand, der letztlich zum Wärmetod des Motors führen würde.

Wenn jedoch das Magnetfeld des Stators – erzeugt durch die drei Spulen – fast genau um 90° voraus ist, erreicht man das maximale Drehmoment bei geringstem Strom. Es gilt also, diesen Zustand zwischen Rotorposition und Stator-Magnetfeld möglichst perfekt zu halten. – Und genau dies ist die Aufgabe der FOC.

Um das Pulsmuster für die Spulen in diesem Sinne zu steuern, sind allerdings viele Faktoren zu berücksichtigen wie etwa Hauptinduktivität der Spulen, Streuinduktivität, Polrückwirkung oder Motorbelastung. Für eine optimale Regelung ist weiterhin die genaue Rotorposition erforderlich. Für Low-cost-Anwendungen (sensorless) wird die Rotorposition über induzierte Spannungen (Back EMF) oder mathematische Modelle bestimmt beziehungsweise errechnet. Um ein Vielfaches besser ist die Messung mittels Hallsen­soren oder – was noch genauer ist – mit Encoder oder Resolver.

Nicht zuletzt werden zwei Phasenströme benötigt; der dritte ergibt sich dadurch, dass die Summe der drei Ströme 0 ergibt. Diese drei Ströme werden mit der Clarke-Transformation in ein zweidimensionales System übergeführt: eine reelle und eine imaginäre Komponente. Nun kommt die Park-Transformation zur Anwendung und berechnet daraus die direkte Komponente – auch Feld genannt – und die quadratische Komponente.

In Echtzeit mitrechnen

Um die Aufgaben einer FOC zu bewältigen, braucht es spezielle Controller. Sie müssen das Pulsmuster (dreiphasige PWM) bereitstellen, sämtliche Sensoren auslesen, Analogwerte verarbeiten und dann die gesamte FOC durchrechnen. Eine Controller-Architektur, die sich für diese Zwecke besonders eignet, ist beispielsweise die XS1 von Xmos mit mehreren Kernels. Messaufgaben, PWM und Berechnungen laufen hier vollkommen getrennt ab und Softwarepakete für Hall, Encoder, Stromwerte, Regelung und PWM sind mitsamt den Variablen und Parametern gekapselt.

Eine solche Prozessor-Architektur ermöglicht Realtime auf höchstem Niveau und bietet enorme Vorteile gegenüber einem auf Interrupts basierten Controller. Auch Störsignale lassen sich wesentlich besser ausblenden, sofern man jeden Pegelwechsel per Software noch verifizieren kann. Dadurch gibt es kein plötzliches Rütteln im Motor mehr und Ferrite in den Leitungen können entfallen.

FOC in echtzeitfähige Steuerungshardware einzubetten, ist demnach aus vielen Gründen empfehlenswert. Es wird aber vor allem kaum einen auf Interrupts basierten Controller geben, der so schnell rechnet, dass der FOC-Regelkreis synchron zur PWM-Periode bleibt. Ebenfalls synchron dazu müssen die überlagerten Regelkreise für Drehmoment, Geschwindigkeit und Position sein.

Kurzum: Eine Motorsteuerung, die mit Interrupts aufgebaut werden muss, ist in ein zeitliches Korsett gepresst. Ein Con­troller wie Xmos hat keine Interrupts, der Scheduler ist per Hardware integriert und der Vorteil liegt in der parallelen Abarbeitung verschiedener Threads.
Die hier angedeuteten Aufgaben und Anforderungen machen deutlich, warum der Entwicklungsaufwand in der Vergangenheit oft gegen die FOC sprach und warum sie nicht schon viel weiter verbreitet ist.

Eigenentwicklung lohnt sich oft nicht

Normalerweise werden Motorsteuerungen auf eine Anwendung hin entwickelt. Bei einem einzelnen Motor für ein Massenprodukt ist dieser Aufwand vielleicht noch überschaubar. Problematisch wird es allerdings, wenn man zum Beispiel Mehrachssysteme in Gesamtprodukte integrieren möchte und wertvolle Entwicklungsressourcen in die Servo-Controller stecken muss anstatt in das Produkt selbst.

Die Entwicklungswerkzeuge der Dynarc-Plattform bieten umfangreiche Möglichkeiten, das Systemverhalten auf allen Ebenen zu optimieren. Im Bild die Echtzeit-Auswertung der drei Phasenströme eines BLDC-Motors mit der integrierten Oszilloskop-Funktion.

© Synapticon

Eine mögliche Lösung dieses Problems kommt aus dem Umfeld der Service­robotik und der Cyber-Physical Systems. Ein Entwicklungsdienstleister in diesem Bereich Synapticon, hat ein Baukastensystem für die Entwicklung komplexer vernetzter Systeme geschaffen, das auch Steuerungssoftware und Hardware für Motoren umfasst. In dem „Dynarc“ genannten System sind die Module so gestaltet, dass sich Entwickler die für jede Steuerung geeignete Hardwarebasis individuell zusammenstellen können.

Für den Entwickler bedeutet dies folgendes: Zunächst wählt er aus einer Reihe von Modulen die Motorleistungselektronik und Sensorschnittstellen. Eine Komponente dieses Baukastens wäre zum Beispiel das „Somanet IFM Drive DC 100“ für die Ansteuerung von Gleichstrommotoren bei 12 bis 24 V beziehungsweise bis zu 120 W pro Phase auf einer 40×50-Millimeter-Platine. Grundsätzlich reicht das Leistungsspektrum bis hin zu BLDC-Motoren mit 720 W pro Phase bei 12 bis 48 V. Dazu kombiniert man ein Kommunikationsmodul und einen Prozessor. Jedes dieser Kernmodule auf einer 30×30-Millimeter-Platine trägt einen oder zwei XMOS-Prozessoren, von denen jeder 16 deterministische Echtzeit-Cores zur Verfügung stellt.

Die Tatsache, dass 65.000 dieser Rechenkerne in einem verteilten System kombiniert und wie ein einziger Prozessor behandelt werden können, zeigt: Das Konzept ist nicht nur auf einzelne Motorsteuerungen ausgelegt, sondern auf verteilte Embedded-Systeme mit einer Vielzahl von Aktoren und Sensoren. Grundsätzlich wurden die kombinierbaren Modulen des Baukastens vor dem Erfahrungshintergrund der Servicerobotik ausgewählt: alles sehr kompakt, mit geringen Stromverbrauch und geringer Wärme-Entwicklung.

Als dritte Komponente eines Steuerungsknotens wird dann eine Kommunikationseinheit für das gewünschte Bussystem ausgewählt. Zur Wahl stehen etwa Ethercat, CAN, WiFi oder Prozessorbus über LVDS. Der Clou bei dieser Konfiguration: Mit der Zusammenstellung der Elektronik werden über die Dynarc-Plattform sofort und automatisch die passenden, quelloffenen Treiberbibliotheken ausgewählt und integriert. Die Software-Entwicklung in der dazugehörigen Entwicklungsumgebung erfolgt modellbasiert, hardware- und betriebssystemunabhängig. Auf dieser Grundlage werden dann die einzelnen BLDC-Steuerungen entwickelt, mit der gesamten Motorsteuerungs-Algorithmik auf Regler-, Kommutierungs- und PWM-Ebene.

Nicht nur die Hardware, auch die Software liegt modular und quelloffen vor. Hierbei sind sämtliche Bausteine vorhanden, die für den Entwicklungsstart einer Anwendung erforderlich sind. Gleichzeitig hat der Entwickler aber die Flexibilität einer kompletten Eigenentwicklung.

Von der FOC zum Gesamtsystem

Wie bereits angedeutet, ist das beschriebene Baukastensystem nicht auf die FOC-Entwicklung beschränkt. Durch die dazugehörige Entwicklungsplattform eröffnet es darüber hinaus neue Möglichkeiten bei der Gestaltung von Systemarchitekturen. Klassisch würde man simple Steuerungsbefehle wie etwa die Drehzahl von einem zentralen Rechner an den Motor übergeben und die Regelungsschleife über den Feldbus schließen. Nun kann man auch mit abstrakteren Kommandos arbeiten, die dann von den verteilten Prozessoren mit lokaler Intelligenz umgesetzt werden. Die Technik solcher verteilter Embedded-Systeme mit mechatronischen Schnittstellen ermöglicht im nächsten Schritt die Realisierung von Cyber-Physical Systems.

Autor: Nikolai Ensslen ist Geschäftsführer von Synapticon.