Warum die automatische Codegenerierung der manuell geschriebenen Konverter-Firmware überlegen ist

Wichtigste Erkenntnisse

• Durch die automatische Codegenerierung entfällt die wiederholte Übersetzung zwischen Steuerungsentwurf und Firmware, wodurch der Überprüfungsrückstand abgebaut wird und die Implementierung stets mit dem Modell übereinstimmt.
• Der generierte Reglercode funktioniert am besten, wenn das Modell bereits feste Zeitabläufe, numerische Grenzwerte, die Schutzreihenfolge und Prozessor-Einschränkungen berücksichtigt.
• Manuelle Firmware spielt bei der Einrichtung von Peripheriegeräten und Systemdiensten nach wie vor eine wichtige Rolle, während der Regelkreis selbst am meisten von der modellbasierten Generierung und dem Prototyping profitiert.

Die automatische Codegenerierung ist der manuell geschriebenen Konverter-Firmware überlegen, wenn sich die Regelungsgesetze ständig ändern und das Timing dennoch exakt bleiben muss.

Teams, die an Stromrichtern arbeiten, haben selten Schwierigkeiten mit der Programmierung in C. Ihre Herausforderungen liegen vielmehr in der Neuanpassung von Stromregelkreisen, der Aktualisierung der Schutzlogik und der Sicherstellung, dass die Abtastzeiten nach jeder Designänderung weiterhin synchron sind. Der Absatz von Elektroautos erreichte im Jahr 2023 fast 14 Millionen, und etwa 18 % aller verkauften Autos waren Elektrofahrzeuge. Diese Größenordnung erhöht den Druck auf den Code für Stromrichter und Motorsteuerung, und die manuelle Arbeit an der Firmware wird zum flaschenhals. Sie sind besser beraten, wenn das Steuerungsmodell zur „Quelle der Wahrheit“ wird und der Steuerungscode aus diesem Modell abgeleitet wird. Dieser Ansatz eignet sich für Umrichterlabore und Lehrlabore, in denen sich die Algorithmen ständig weiterentwickeln und Low-Level-Firmware-Arbeiten den Fortschritt behindern.

Durch die automatische Codegenerierung werden Steuerungsmodelle in eingebettete software umgewandelt

Die automatische Codegenerierung wandelt ein Regelungsmodell in C-Code um, wobei die Modellstruktur, das Timing und der Datenfluss erhalten bleiben. Sie erstellen das Regelgesetz aus Blöcken oder Gleichungen, legen Abtastzeiten fest und generieren Quelldateien für die Zielplattform. Dadurch bleibt die Implementierung eng mit dem validierten Entwurf verknüpft. Außerdem verkürzt sich so der Übergang von der Simulation zur Ausführung.

Ein Stromregler für einen Dreiphasen-Wechselrichter ist ein anschauliches Beispiel. Sie können Clarke- und Park-Koordinatenumrechnungen, Proportional-Integral-Regelkreise, Sättigung sowie die Berechnung des Tastverhältnisses bei der Pulsweitenmodulation modellieren und anschließend Code für den Interrupt-Schritt generieren. Jeder Signalpfad bleibt vor der Bereitstellung sichtbar. Bei manuell erstellter Firmware ist diese Logik häufig über verschiedene Dateien, Makros und Interrupt-Verzweigungen verteilt.

Der Gewinn besteht nicht darin, dass sich die Codequalität auf Knopfdruck wie von Zauberhand verbessert.

„Der Vorteil ergibt sich daraus, dass der Übersetzungsaufwand zwischen der Steuerungsentwicklung und der Firmware-Implementierung entfällt.“

Jedes Mal, wenn Sie die Verstärkungen neu abstimmen, eine Vorwärtskopplung hinzufügen oder einen Anti-Windup-Pfad einfügen, bleiben das Modell und der Code aufeinander abgestimmt. Diese Abstimmung ist wichtiger als die reine Tippgeschwindigkeit, da bei Konverter-Projekten der Großteil der Zeit für die Überarbeitung und nicht für die Erstimplementierung aufgewendet wird.

Der Schwerpunkt bei der Firmware-Entwicklung verlagert sich vom Schreiben von Code hin zur Gestaltung des Verhaltens

Der Schwerpunkt der Arbeit verlagert sich von manuellen Programmieraufgaben hin zur Definition des genauen Regelverhaltens im Modell. Sie legen weiterhin Raten, Datentypen, Skalierungen und Schnittstellen fest. Sie müssen keine Stunden mehr mit Standard-Scheduler-Code und der wiederholten Verknüpfung von Signalen verbringen. Ihr Aufwand verlagert sich auf die Regelungsabsicht, wo Fehler schwerwiegendere Folgen haben.

Ein phasenverschobener Vollbrücken-Regler veranschaulicht diese Verschiebung gut. Beim manuellen Code müssen Sie die Messwerte des Analog-Digital-Wandlers verknüpfen, die Messwerte normieren, den Kompensationsblock einplanen, die Ausgänge begrenzen und nach jeder Unterbrechung die Phasenlogik konsistent halten. Der generierte Code muss zwar noch konfiguriert werden, doch das Kompensationsgesetz bleibt in einem Modell erhalten. Dadurch haben Sie eine zentrale Stelle, an der Sie das Verhalten während einer Entwurfsprüfung überprüfen können.

Entwicklungsteams unterschätzen oft, wie viel der manuellen Arbeit an der Firmware aus reiner Routinearbeit besteht. Das Kopieren von Verstärkungswerten, das Umbenennen von Variablen und das Umformulieren von Gleichungen in Ganzzahlberechnungen tragen nicht zum Verständnis der Steuerung bei. Diese Schritte führen zudem zu unbemerkten Abweichungen zwischen der Simulation und der Ausführung im eingebetteten System. Die automatische Codegenerierung beseitigt einen Großteil dieser Routinearbeit, sodass bei der Validierung keine Zeit mit Fehlern verschwendet wird, die auf Übertragungsfehler zurückzuführen sind.

Embedded Coder eignet sich für Motorsteuerungs-Zielsysteme wie beispielsweise C2000

Kleine Steuerungsprozessoren wie der C2000 eignen sich für die Codegenerierung, da sie Aufgaben mit festen Schritten, vorhersehbare Interrupts und explizite Ein-/Ausgabe-Timings erwarten. Ein geeigneter Generator ordnet die Modellraten diesem Ausführungsmuster zu. Sie überprüfen weiterhin die Speichernutzung und die Timings der Peripheriegeräte. Die Steuerungslogik gelangt in einer Form an den Prozessor, die vom Zielsystem ausgeführt werden kann.

Ein gutes Beispiel hierfür ist ein feldorientierter Motorregler. Das Modell kann die Stromrekonstruktion, die Drehzahlschätzung, Proportional-Integral-Regler, Entkopplungsterme und die Raumvektormodulation umfassen, während die Peripherieeinstellungen außerhalb des Regelgesetzes bleiben. Der generierte Code deckt die sich wiederholende Regelungsaufgabe ab. Handgeschriebener Code kann dann die analoge Abtastung, die Synchronisation der Pulsweitenmodulation, Fehlerabschaltungen und Kommunikationsschnittstellen darum herum integrieren.

Genau diese Unterscheidung ist der Grund, warum die modellbasierte Regelung bei diesen Geräten so gut funktioniert. Der Prozessor eignet sich hervorragend für die deterministische Ausführung von Regelkreisen, reagiert jedoch sehr empfindlich auf ständige Neuprogrammierungen, während der Algorithmus noch in der Entwicklung ist. Der generierte Reglercode liefert Ihnen lesbare Funktionen, die mit Modellblöcken verknüpft sind, was bei der Codeüberprüfung, der Kalibrierung und der Fehlersuche im Labor hilfreich ist. Das entspricht viel eher der Absicht hinter der Simulink-Codegenerierung als eine vollständige Neuprogrammierung der Firmware nach jeder Neuanpassung.

Die Firmware des manuellen Umrichters wird langsamer, wenn sich die Regelkreise ständig verändern

Handgeschriebene Konverter-Firmware verlangsamt die Entwicklung, da jede Änderung an den Steuerungslogiken einen zweiten Übersetzungsschritt von Gleichungen in Code erfordert. Dieser zusätzliche Schritt führt zu Revisionsrückständen, Nachprüfungsaufwand und Terminrisiken. Probleme Software verursachten in den Vereinigten Staaten im Jahr 2022 Kosten in Höhe von mindestens 2,41 Billionen US-Dollar. Konverter-Teams erleben jede Woche eine kleinere Version dieser Verschwendung.

Ein Programm zur Entwicklung einer doppelt aktiven Brücke beginnt oft mit einem Modulationsverfahren, wobei nach Vorliegen der Testergebnisse aus dem Labor dann eine Soft-Start-Logik, eine Totzeitkompensation und eine Strombegrenzung hinzugefügt werden. Jede Änderung an der Firmware betrifft die Skalierung, das Interrupt-Timing und die Fehlerinteraktionen. Die Ingenieur:innen die Ingenieur:innen sich zwar auf die mathematischen Grundlagen einigen, gehen jedoch bei den Implementierungsdetails dennoch unterschiedliche Wege. Diese Kluft vergrößert sich jedes Mal, wenn sich die Regelstruktur ändert.

Manueller Code ist nach wie vor ausreichend, solange der Algorithmus stabil ist und das Team das Gerät genau kennt. Probleme treten jedoch früher auf, als die meisten Teams erwarten, da Konverterprojekte im ersten Testzyklus selten stabil bleiben. Die folgende Tabelle zeigt, wohin sich der Aufwand in der Regel verlagert, sobald mit den Überarbeitungen begonnen wird. Sie verdeutlicht, warum der Engpass eher bei der Umsetzung und den erneuten Tests liegt als bei der Berechnung selbst.

Der generierte Controller-Code hängt von einem sauberen, deterministischen Modellentwurf ab

Der generierte Code ist nur so gut wie die Modellstruktur, die zeitliche Disziplin und die zugrunde liegenden numerischen Entscheidungen. Ein sauberes Modell mit festem Schritt führt zu lesbarer software. Ein schlampiges Modell führt software zu verwirrender software . Das Modell muss die eingebettete Realität widerspiegeln, bevor die Codegenerierung beginnt.

Ein für die Codegenerierung bereitiges Konvertermodell weist einige erkennbare Merkmale auf. Die Raten sind explizit angegeben. Die Zustände werden auf kontrollierte Weise zurückgesetzt. Die Signalgrenzen liegen dort, wo hardware eintritt. Die numerischen Werte sind auf das Ziel abgestimmt.

• Jede Steuerungsaufgabe verwendet eine feste Abtastzeit, die mit einem tatsächlichen Interrupt übereinstimmt.
• Jedes Zurücksetzen des Zustands ist sichtbar und mit einem definierten Betriebszustand verknüpft.
• Sensorskalierung und Aktuatorgrenzen tauchen im Modell auf, nicht nur im Wrapper-Code.
• Die Datentypen spiegeln die Grenzen des Prozessors wider, bevor die Zeitmessung beginnt.
• Schutzpfade werden in einer bekannten Reihenfolge ausgeführt, die dem Regelzyklus entspricht.

Diese Regeln klingen zwar banal, verhindern aber die schlimmsten Überraschungen. Ein Modell mit versteckten Ratenübergängen oder Annahmen bezüglich Gleitkommazahlen lässt sich zwar kompilieren, versagt jedoch unter Interrupt-Belastung auf einem kleinen Prozessor. Eine übersichtliche Struktur erleichtert zudem die Überprüfung der generierten Dateien gemeinsam mit anderen Firmware-Entwicklern. Man verlangt vom Generator nicht, ein Modellierungsproblem zu lösen, das nach wie vor Aufgabe der Ingenieur:innen ist.

Beim Prototyping der Steuerung wird das Timing überprüft, bevor mit der Low-Level-Firmware-Entwicklung begonnen wird

Mithilfe von Steuerungsprototypen können Sie das Ausführungszeitverhalten, das Ein- und Ausgabeverhalten sowie das Regelkreisverhalten testen, bevor Sie sich auf die Details der Low-Level-Firmware festlegen. Dieser Schritt deckt Terminüberschreitungen, mangelhafte Skalierbarkeit und Schwachstellen in der Schutzlogik auf, solange der Algorithmus noch leicht zu bearbeiten ist. So wird das Timing zu einer Entwurfsvariable und nicht zu einer späten Überraschung.

Ein Laboraufbau, bei dem ein modellbasierter Regler mit einem C2000-Regelungsprototyp kombiniert wird, macht den Nutzen schnell deutlich. OPAL-RT nutzt dieses Konzept, damit Ingenieur:innen Studierende Umrichter- und Motoralgorithmen anhand eines laufenden Anlagenmodells iterativ optimieren können, anstatt jede Überarbeitung manuell in die Firmware einprogrammieren zu müssen. Stromgrenzwerte, Observer-Verstärkungen und Aktualisierungen der Pulsweitenmodulation lassen sich unter Fehlerbedingungen und bei Sprungänderungen überprüfen. Der Fokus der Arbeit liegt dabei auf der Regelungsqualität und dem Ausführungszeitpunkt.

Diese Phase ist wichtig, da eine Simulation allein nicht alle Probleme aufdeckt. Interrupt-Jitter, Quantisierung, die Synchronisation der analogen Abtastung und die Sättigungsordnung wirken auf einem Desktop-Modell oft harmlos.

„Durch das Erstellen von Prototypen werden diese Ecken und Kanten sichtbar, bevor das Team sie im Randcode versteckt.“

Sie erreichen die letzte Phase der Firmware-Entwicklung mit weniger Unbekannten und einem Steuerungsgesetz, das bereits bewiesen hat, dass es termingerecht ausgeführt werden kann.

Die Codegenerierung schlägt fehl, wenn Modelle hardware außer Acht lassen

Die Codegenerierung scheitert in der Praxis, wenn das Modell von idealen mathematischen Bedingungen und unbegrenzten hardware ausgeht. Kleine Steuerungsprozessoren unterliegen strengen Zeitvorgaben, haben eine endliche Auflösung und müssen bestimmte Peripherievorgaben einhalten, die das Modell berücksichtigen muss. Generierter Code kann einen Regelungsentwurf, der den Interrupt-Slot überschreitet, nicht retten. Er macht die Diskrepanz lediglich früher sichtbar.

Ein digitaler Regelkreis zur Leistungsfaktorkorrektur kann bei doppelter Genauigkeit und ohne Sensorverzögerung stabil erscheinen, sich dann aber fehlerhaft verhalten, sobald er mit quantisierten analogen Werten und einer verzögerten Strommessung betrieben wird. Der generierte Code ist dabei nicht das Problem. Das Modell hat die Schnittstelle zum Regelobjekt und die Grenzen des Prozessors nicht berücksichtigt. Ähnliche Probleme treten auf, wenn ein Modell eine Logik mit variabler Schrittweite verwendet, die sich nicht in einen festen Interrupt-Zeitplan einfügen lässt.

Diese Falle umgeht man mit Disziplin. Sensorfilterung, Umwandlungsverzögerung und Aktuatorsättigung sollten im Modell berücksichtigt werden. Wählen Sie frühzeitig Datentypen aus, die zum Prozessor passen, und beobachten Sie anschließend nach jeder Funktionsänderung die Ausführungszeit. Teams, die dies beherrschen, betrachten die Codegenerierung als Implementierungsmethode und nicht als Ersatz für das eigene Urteilsvermögen beim Embedded-Design.

Manueller Code eignet sich nach wie vor für die Steuerung von Peripheriegeräten im Rahmen von Regelkreisen

Manueller Code hat nach wie vor seinen Platz an den Rändern einer Konverter-Steuerung, insbesondere für die Inbetriebnahme der Platine, Kommunikationsstacks, benutzerdefinierte Schutzfunktionen und die gerätespezifische Einrichtung von Peripheriegeräten. Der Regelkreis selbst profitiert am meisten von der automatischen Codegenerierung. Diese Aufteilung sorgt für Klarheit dort, wo sich das Verhalten häufig ändert, und ermöglicht eine manuelle Feinabstimmung dort, wo hardware feststehen.

Ein praktischer Firmware-Stack sieht oft so aus. Generierter Code steuert den Strom- oder Spannungskreis, während handgeschriebener Code die Startabläufe, die Fehlerprotokollierung, Busmeldungen und die nichtflüchtige Speicherung von Parametern verwaltet. Diese Aufteilung spiegelt wider, wie Wandlerprojekte im Labor tatsächlich ablaufen. Die Regelgleichungen ändern sich während der Abstimmung wöchentlich, während sich die Peripheriefunktionen früher stabilisieren und sorgfältige manuelle Arbeit belohnen.

Aus diesem Grund ist die automatische Codegenerierung bei den meisten Steuerungsaufgaben der handgeschriebenen Konverter-Firmware überlegen. Der Vorteil liegt nicht in kürzeren Quelldateien. Der Vorteil besteht vielmehr in einer engeren Abstimmung zwischen dem Modell, dem Sie vertrauen, dem von Ihnen verifizierten Timing und dem Code, den Sie ausliefern. OPAL-RT entspricht dieser Einschätzung sehr gut, da es den Schritt unterstützt, in dem Steuerungsteams die Ausführung auf hardware nachweisen, hardware die Low-Level-Firmware-Arbeiten das Design festlegen.