Antriebe auf dem Schreibtisch testen

Der Zeitaufwand für die Softwareentwicklung einer Motorsteuerung lässt sich mit einem modellbasierten Ansatz reduzieren. Damit kann für den Softwaretest auf den üblichen Testaufbau der Hardware mit Motor und Antriebssteuerung verzichtet werden. Es genügt ein kleines HIL-System für den Schreibtisch.

Der Siegeszug von Elektromotoren ist seit ihrer Erfindung im 19. Jahrhundert einer der wichtigsten Begleiter der industriellen Revolution und die Erfolgsstory geht weiter. Von mächtigen Generatoren in der Energie-erzeugung bis zu Mikroantrieben in Millimetergröße und kleiner, überall stecken sie drin. Das elektromagnetische Grundprinzip hat sich seither nicht geändert. Darüber hinaus haben sich zahlreiche grundlegende Funktionsprinzipien entwickelt. Die wichtigsten Varianten sind der Gleichstrommotor, Asynchron- und Synchronmotor und der kollektorlose Gleichstrommotor (Brushless DC, BLDC), der eigentlich eine Drehstromsynchronmaschine ist.

Jedes Funktionsprinzip hat spezifische Eigenschaften, die sich für entsprechende Aufgaben eignen. Der Gleichstrommotor gilt beispielsweise als ein robuster und kostengünstiger Alleskönner, nur sein Kommutator für die Stromwendung zur Erzielung einer kontinuierlichen Rotation ist der Abnutzung unterworfen. Der kollektorlose Gleichstrommotor – auch als elektronisch kommutierender Gleichstrommotor bezeichnet – dagegen, enthält kaum Verschleißteile, ist langlebig und eignet sich daher sehr gut für den Dauerbetrieb mit hoher Leistungsdichte.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Anpassung von Motoren an ihren Einsatzzweck

Um die Funktion der Anwendung zu erfüllen, gibt es sehr viele Parameter die gesteuert, eingehalten und überwacht werden müssen. Je nach Motorbauart sind für den Betrieb Parameter wie Stromstärke, Spannung, Magnetfeld, Position des Rotors etc. dem Arbeitsprofil anzupassen. Darüber hinaus gibt es Umgebungsbedingungen, die Einfluss auf den Betrieb des Motors nehmen. Die Umgebungsbedingungen, abgebildet durch Größen wie Temperatur, Druck, Feuchtigkeit, Schwingungen, Anforderungen an die Betriebssicherheit und vieles mehr, nehmen Einfluss auf die Auslegung der Motoren und ihrer Steuerung.

Für diese Aufgaben haben sich inzwischen programmierbare, leistungsfähige und kostengünstige 8/16/32-bit-Mikrocontroller etabliert. Sie verarbeiten Steuersignale ausreichend schnell für die Motorsteuerungen, über Software ist die Anpassung der Regelung an die Umgebungsvariablen möglich und sie bearbeiten die Daten der Ein-Ausgabeinterfaces für die Bedienung. Programme, z. B. für eine Mikrocontroller-gesteuerte Bohrmaschine, erreichen inzwischen leicht eine halbe Millionen Zeilen Programmcode und mehr.

Die Herausforderungen im Entwicklungsprozess

Software für Antriebssteuerungen ist in der Regel umfangreich und komplex. Es arbeiten meist größere Teams an Komponenten, wie zum Beispiel Regelalgorithmen, Sicherheitssystemen, Treibern und hardwarenaher Software sowie an den Programmen der Anwendung. Für den Start der Softwareentwicklung für die Mikrocontroller stehen in der Regel nur Evaluation-Boards der Halbleiterhersteller zur Verfügung, denn die projektspezifische Elektronik ist noch im Entstehen. Oftmals sind neben der Basisauslegung der Hard- und Software einer Steuerung auch Produktvarianten und- Familien zu berücksichtigen. Das schlägt sich in zusätzlicher Komplexität nieder.

Ein Projekt startet meist mit einem Eval-Board für den Mikrocontroller der Wahl. Damit werden Treiber und hardwarenahe Software entwickelt. Darunter fällt auch bereits die Software für die Motorsteuerung. In komplexeren Projekten entstehen hier auch die Programme für Kommunikation, z. B. CAN-Bus-Protokoll oder das Power-Management der Geräte (Bild 1).

Von der Hardware unabhängigere Software der Steuerelektronik baut auf diesen Entwicklungen auf, bevor dann die gesamte Applikation für das Gerät, System etc. in Angriff genommen wird. Die Zielhardware der Steuerung – Mikrocontroller-Steuerung mit Leistungselektronik (Electronic Control Unit, ECU) – liegt dann meist auch schon in einer ersten Version vor. Das ist der Zeitpunkt an dem in der Regel traditionelle Hardware-in-the-Loop-Teststände (HIL) zum Einsatz kommen (siehe Bild 1). Das sind meist aufwendige Teststände die projektspezifisch gerüstet werden müssen – eine teure und rare Ressource, weil sie nicht beliebig und jederzeit jedem Entwickler für die Überprüfung des erzeugten Codes zur Verfügung stehen. Man denke nur an einen Teststand für einen ICE-Antriebsmotor und an Teams, die idealerweise bereits am Projektanfang intensiv Treiber und hardwarenahe Software testen möchten.

Das ist einer der wesentlichen Gründe, weshalb in frühen Phasen der Entwicklung von Embedded-Systemen meist nicht oder nur in geringem Umfang getestet wird. Einzelne Softwarekomponenten werden mit sogenannten Unit-Tests zwar überprüft, das ist sinnvoll und wird auch durch entsprechende Tools gut unterstützt. Sobald die Software mit der Hardware des Endgerätes »verheiratet« werden soll, wird es allerdings problematisch. Warum ist dieser Schritt so kritisch?

• Die Zielelektronik ist meist noch nicht vorhanden. Die Entwicklung findet auf Evaluation-Boards statt, für die es in der Regel keine Testsysteme gibt. Die üblichen Hardware-in-the-Loop-Testsysteme (HIL-Systeme) sind häufig zu groß und zu teuer, um während der Entwicklung kontinuierlich Tests zu ermöglichen.
• Tests mit HIL-Systemen und die anschließenden Systemtests finden meist erst spät im Entwicklungsprozess statt. Fehler, die spät entdeckt werden, sind in der Regel aufwendig zu beheben. Testzyklen in diesen Projektphasen ziehen sich mitunter über Wochen hin.
• Traditionelle HIL-Tests in Kombination mit Simulationselementen sind technisch komplex und schwer zu automatisieren.
• Unit-Tests sind für Tests von hardwarenahen, nebenläufigen oder asynchronen Funktionen, wie sie z. B. in Treibern und Motorreglern vorkommen, schlecht geeignet.

Aus diesen Gründen werden viele Embedded-Systeme in frühen Projektphasen nicht ausreichend oder gar nicht systematisch getestet. Der traditionelle Entwicklungsprozess hat also eine Lücke in der Testsystematik – obwohl die Erfahrung der Entwickler und Unternehmen besagt, dass zu spätes Testen zu Projektverzögerungen führt und die Entwicklungskosten bei später Fehlerbehebung exponentiell steigen.

Praktische Erfahrungen aus Projekten

Um die Entwicklung komplexer Embedded-Software zu beherrschen, haben sich die folgenden Methoden als erfolgreich herauskristallisiert:

• Einführung von modellbasierten Entwicklungsmethoden für Software
• Simulation von Funktionseinheiten, die real noch nicht existieren und erst Zug um Zug entwickelt werden
• Sehr frühzeitiges Testen von Softwarekomponenten im Entwicklungsprozess durch Einführung von Integrationstests mit geeigneten Tools
• Automatisiertes Testen nach jeder Codeänderung (Regressionsverfahren) durch Continuous Integration (CI)

Bei einem modellbasierten Entwicklungsansatz einer Motorsteuerung wer- den Systemkomponenten, die noch nicht real existieren, in einem mathematisch-physikalischen Modell abgebildet. Dafür wird oft Simulink verwendet. Dieses Modell verhält sich wie ein realer Motor mit seiner Ansteuerelektronik. Die entstehende Reglersoftware kann nun gegen das Modell getestet und iterativ verbessert werden. Mit diesem modellbasierten Vorgehen können über die Simulation einer realen Motor-Elektronik-Kombination die Basisfunktionen getestet werden, Varianten lassen sich ausprobieren und der Entwicklungsprozess wird durch die Parallelität von Hard- und Softwareentwicklung beschleunigt.

Auf einer weiteren, höheren Ebene der Entwicklung sind Simulationen der Umgebungsbedingungen von Bedeutung und wünschenswert. Soll zum Beispiel das Lastverhalten eines Antriebs in verschiedenen Klimazonen überprüft werden, kann natürlich ein Motor mit seiner Elektronik als Prüfling in eine Klimakammer gestellt werden, um einen mehrwöchigen Test durchzuführen. Das ist jedoch in der frühen Entwicklungsphase weder zeitgemäß noch rentabel. Dafür bieten sich frühzeitige Simulationen mit Modellen und den geeigneten Werkzeugen an.

Als Alternative ist es möglich, sogenannte Integrationstests einzuführen (Bild 2). Integrationstests ermöglichen es, Softwarefehler frühzeitig zu erfassen und schnell zu korrigieren. Sie ermöglichen es, die Entwicklungszeit zu verkürzen. Im Integrationstest werden die reale »Physik der Anwendung« inklusive weite Bestandteile der Umgebungsbedingungen des gesamten Geräts und auch Teile der Anwendung simuliert. Eine geeignete Hardwareplattform mit Softwarewerkzeugen ist dafür eine wichtige Voraussetzung, vor allem, um auch das Zeitverhalten in Echtzeit untersuchen zu können.
 
In einer modellbasierten Umgebung zur Softwareentwicklung (Tool Chain) werden Testfälle für die entstandenen Softwarekomponenten erzeugt, die gegen die Simulation des Motors getestet werden. Die Test-Hardware ist hierbei das Bindeglied zwischen der echtzeitfähigen Umgebungssimulation und der zu testenden Software auf der projektspezifischen Hardware mit Eval-Board. Für die Simulation, den Ablauf der Testsoftware und die Fehleraufzeichnung ist ein eigener Rechner integriert, der mit dem Eval-Board des Mikrocontrollers über ein Wire-Patch-Feld verbunden ist, mit dem die relevanten Ein-/Ausgabesignale angeschlossen werden.

Die gesamte beschriebene Anordnung wurde vom Unternehmen Protos Software in einem Testsystem »miniHIL« zusammengefasst, das speziell für das Testen von Software für Geräte mit Mikrocontrollern ausgelegt ist. Mit dem miniHIL ist ein Integrationstest möglich, wie er in dem blau umrahmten Feld in Bild 2 dargestellt ist. Das Testsystem erlaubt früh in der Entwicklungsphase eine Codeüberprüfung, ohne dass die reale Hardware schon existieren muss. Es können damit sogar frühzeitig Teile der HIL-Tests erfolgen und große Teile der Acceptance-Tests realisiert und durchgeführt werden. Fähigkeiten, die sich in der Entwicklung sicherheitskritischer Anwendungen als sehr hilfreich und unterstützend erwiesen haben.

1. Antriebe auf dem Schreibtisch testen
2. Kompaktes HIL-System für den Entwicklerschreibtisch