Automatisierte Integration beschleunigt Entwicklung von E-Auto-Steuergeräten
In einem Bereich, in dem Millisekunden über optimale Leistung oder Systemverzögerung entscheiden können, war der Wettlauf um die Beschleunigung der Entwicklung von Elektrofahrzeugen (EV) nie dringlicher. Da die Elektrifizierung die automobile Landschaft neu gestaltet, steht Entwicklungsingenieure unter enormem Druck – nicht nur schneller zu innovieren, sondern dies auch zuverlässig, sicher und in großem Maßstab zu tun. Vor diesem Hintergrund erregt eine neue Methodik, die kürzlich in einer Studie im Journal of Chongqing University of Technology (Natural Science) vorgestellt wurde, ernsthafte Aufmerksamkeit in akademischen und industriellen Kreisen. Sie verspricht, Entwicklungszeiten zu verkürzen, menschliche Fehler zu reduzieren und die Integration komplexer Steuerungslogik in reale Hardware zu standardisieren.
Kern der Innovation ist die nahtlose Verschmelzung von High-Level-Steuerungsstrategieentwurf und Low-Level-Treiberkonfiguration für eingebettete Systeme – zwei Bereiche, die historisch betrachtet strikt voneinander getrennt waren. Traditionell folgt die Entwicklung einer Fahrzeugsteuereinheit (VCU), dem „Gehirn“ jedes reinen Elektrofahrzeugs, einem V-Modell-Workflow: Ingenieure entwerfen anwendungsschichtnahe Steuerungslogik (z.B. Drehmomentarbitrierung, Schaltlogik), simulieren diese umfassend, generieren automatisch Code (oft via MATLAB/Simulink) und fügen diese Logik dann manuell in die separat codierten Hardwaretreiber für Mikrocontroller wie der STM32-Serie ein. Dieser letzte Integrationsschritt, der anfällig ist für Variableninkonsistenzen, Versionsabweichungen und manuelle Tippfehler, war lange ein Nadelöhr.
Der neu vorgeschlagene Ansatz dreht den Spieß um. Anstatt Anwendungs- und Treibercode in getrennten Umgebungen zu generieren, demonstrierte das Team – unter der Leitung von Huan Shen, Jianguo Mao, Fuliang Zhou, Wei Chen und Zhiwei Yan vom College für Energie- und Antriebstechnik der Universität für Luft- und Raumfahrt Nanjing – einen vollständig co-simulierten, co-generierten Workflow. Ihre Methode nutzt zwei eng gekoppelte Werkzeuge von STMicroelectronics und MathWorks: STM32CubeMX und STM32-MAT/TARGET, wobei Letzteres ein offizielles Simulink-Integrationspaket ist, das chip-level-Peripheriekonfigurationen in Drag-and-Drop-Simulink-Blöcke übersetzt.
Man kann sich das so vorstellen: Früher war der Bau einer modernen VCU wie die Montage eines Hochleistungssportwagens in zwei separaten Werkstätten – eine für Motor und Getriebe, eine andere für Chassis und Elektronik – wobei Ingenieure hin- und herpendelten und hofften, dass die Befestigungspunkte und Kabelbäume passten. Jetzt, mit diesem Workflow, ist es, als ob das gesamte Fahrzeug von einer einzigen, synchronisierten Montagelinie rollt – Motor, Steuergerät, Sensoren und Aktoren werden alle in einer einheitlichen Umgebung modelliert, simuliert und kompiliert.
Die Implikationen sind erheblich – nicht nur für die Effizienz, sondern auch für Sicherheit und Skalierbarkeit.
Sehen wir uns an, wie das in der Praxis aussieht. Die Forscher wählten den STM32F407ZGT6, einen weit verbreiteten 32-Bit-ARM-Cortex-M4-Mikrocontroller, der häufig im Automobil-Prototyping und in Mittelklasse-Steuergeräten zum Einsatz kommt. Anstatt register-level C-Code für Analog-Digital-Wandler (ADCs), allgemeine Eingabe-/Ausgabebausteine (GPIOs) oder UART-Kommunikation zu schreiben, konfigurierten sie zunächst alle Hardware-Peripheriegeräte – Pin-Belegungen, Clock-Trees, Abtastraten, Interrupt-Prioritäten – visuell in STM32CubeMX. Nach dem Export wurde diese Konfiguration automatisch als Bibliothek von sofort einsatzbereiten Blöcken in Simulink importiert: ADC_Read, GPIO_Read, UART_TX und so weiter.
Diese Blöcke waren keine Platzhalter; es handelte sich um funktional akkurate Darstellungen der tatsäch Hardwaretreiber. Das bedeutete, dass das Team, wenn es seine Anwendungslogik erstellte – welche kritische Funktionen wie Fahrzeug-Hoch-/Runterfahrsequenzen, Gangzustandsverwaltung, Pedalsignalinterpretation und Drehmomentarbitrierung abdeckte – echte Sensoreingänge (z.B. Gaspedalstellung, Bremsstatus, Gangwahl-Signale) direkt in algorithmische Blöcke auf derselben Modellierungsoberfläche verdrahten konnte. Kein Rätselraten mehr bei Datentypen oder Skalierungsfaktoren. Keine falsch ausgerichteten Puffergrößen oder vergessenen Initialisierungsaufrufe.
Ein besonders eleganter Aspekt der Strategie liegt in der Handhabung von Zustandssequenzen – einem notorisch schwierigen Bereich der EV-Steuerung. Betrachten wir den Prozess des Fahrzeugstarts. Er muss einer strikten Reihenfolge „Niedervolt zuerst, dann Hochvolt“ folgen, um katastrophale Lichtbögen oder Beschädigungen empfindlicher Elektronik wie dem Batteriemanagementsystem (BMS) oder dem Motorumrichter zu verhindern. In konventionellen Workflows würde diese Sequenz prozedural codiert: eine Reihe von If-Else-Prüfungen, Timer-Triggern und Flag-Umschaltungen – schwer zu visualisieren, noch schwerer zu verifizieren.
Hier modellierten die Forscher die Hoch-/Runterfahr-Energieflüsse als Zustandsautomaten, eingebettet in Simulink, wobei die Übergänge nicht nur durch logische Bedingungen, sondern durch Echtzeit-Hardwaresignale aus der virtuellen Treiberschicht gesteuert wurden. Wenn beispielsweise das simulierte „KEY_ON“-GPIO-Signal high ging, triggerte das Modell die VCU, das BMS zu wecken (via eines virtuellen CAN- oder diskreten Signals), wartete auf ein „BMS_OK“-Handshake (in diesem Prototyp als konstant 0 simuliert), und schaltete dann den Vorladerelais. Das System überwachte kontinuierlich eine simulierte „Controller-Spannung“ (gespeist von einem ADC-Block, der eine Spannungsteiler-Messung nachbildete) und schloss den Hauptschütz erst, sobald die Spannungsdifferenz zwischen Controller und Batterie unter 15 Volt fiel – und spiegelte so die reale Vorladelogik wider.
Entscheidend war, dass dies keine reine Simulation blieb. Nachdem das vollständige Modell – Anwendungslogik verwoben mit Hardwaretreibern – zusammengebaut war, nutzte das Team Simulinks Real-Time Workshop (RTW), um ein komplettes, kompilierfertiges C-Projekt für Keil µVision (eine standard ARM-Entwicklungsumgebung) automatisch zu generieren. Im Hintergrund rief MATLAB STM32CubeMX via COM-Automatisierung auf, um sicherzustellen, dass der generierte Code perfekt mit der konfigurierten Hardware-Abstraktionsschicht (HAL) synchronisiert blieb. Keine manuellen Bearbeitungen. Keine Copy-Paste-Fehler. Ein Klick, eine kohärente Codebasis.
Dann folgte der eigentliche Test: Das Deployment.
Die Forscher bauten einen semi-physischen Prüfstand. Mechanische Potentiometer standen für Gaspedal und Bremspedal. Tastenschalter imitierten Schlüsselpositionen (AUS/ON/START) und Gangwähler (D/N/R). Diese speisten echte analoge und digitale Signale in die physischen Pins des STM32-Boards – keine simulierten Eingaben hier. Währenddessen überwachte ein LabVIEW-basierter Host-PC die von der VCU gesendete UART-Telemetrie, protokollierte Zeitstempel, Statusflags, Drehmomantanforderungen und Spannungswerte in Echtzeit.
Die Ergebnisse waren frappierend – nicht weil die VCU neue Funktionen ausführte, sondern weil sie bekannte Funktionen fehlerfrei und vorhersehbar ab dem ersten Start ausführte.
In einer Testsequenz wurde bei 1,3 Sekunden die „KEY_ON“-Taste gedrückt. Innerhalb von Millisekunden löste die VCU das BMS-Wake-Signal aus und schloss den Vorladerelais (PreRelay = 1). Als der Operator langsam das „Controller-Spannung“-Potentiometer drehte, verharrte das System im Vorlade-Modus – wartend – bis die simulierte Spannung 85 V (gegenüber einer festen 100 V Batterie) erreichte. Zu diesem Zeitpunkt, genau wie entworfen, öffnete der Vorladerelais (PreRelay = 0) und der Hauptschütz schloss (MainRelay = 1). Niedervoltanlauf abgeschlossen.
Dann, bei 3,9 Sekunden, wurde „KEY_START“ betätigt. Die VCU aktivierte den Motorcontroller (MCU_Enable = 1), verifizierte das Fehlen von Fehlern und aktivierte den DC/DC-Wandler. Das System ging in den „Bereit“-Modus – Lichter an, keine Fehler, Antriebsstrang aktiviert. Alle Zustandsübergänge entsprachen der erwarteten zeitlichen Abfolge und logischen Abhängigkeiten. Keine ausgelassenen Schritte. Keine Wettlaufsituationen.
Noch aussagekräftiger war die dynamische Fahrsimulation. Bei 1,2 Sekunden wurde der Gangwähler von Neutral auf Drive bewegt. Die VCU bestätigte, dass die Fahrzeuggeschwindigkeit unter 8 km/h lag (eine Sicherheitsbedingung für den Vorwärtsgang) und autorisierte den Schaltvorgang. Dann, bei 1,4 Sekunden, wurde das Gaspedal auf 30% gedrückt – und das Drehmoment stieg sanft an, initiierte die Vorwärtsbewegung im simulierten Dynamikmodell.
Der eigentliche Stresstest kam bei 2,3 Sekunden: ein direkter Wechsel von Drive auf Reverse während das Fahrzeug sich noch mit 5 km/h vorwärts bewegte. Herkömmliche Weisheit – und viele Serien-Steuergeräte – würden dies als unsicher ablehnen. Doch das Team hatte explizit eine Niedriggeschwindigkeits-Zweirichtungs-Schaltfreigabe (≤8 km/h) codiert, um die Manövrierfähigkeit im urbanen Raum ohne Sicherheitseinbußen zu verbessern. Und das System folgte: Das Drehmoment kehrte sich um, Verzögerung setzte ein, die Geschwindigkeit fiel auf null, und die Rückwärtsbewegung begann – keine Aussetzer, keine Abkopplungen.
Dann, der entscheidende Beweis: Bei 5,0 Sekunden wurde das Bremspedal betätigt. Sofort – innerhalb desselben Steuerungszyklus – fiel der Drehmomentbefehl auf null, ungeachtet der Gaspedalstellung. Diese „Bremsprioritäts-Übersteuerung“ ist eine nicht verhandelbare Sicherheitsanforderung, weltweit vorgeschrieben. Die Tatsache, dass sie unmittelbar auslöste, selbst während einer aggressiven Beschleunigung, validierte nicht nur die Logik, sondern auch die Echtzeit-Determiniertheit des automatisch generierten Codes. Später, bei 18,2 Sekunden, übersteuerte eine weitere Bremsung eine Volllasteingabe mit identischer Zuverlässigkeit – ein essenzielles Verhalten für Notfalleingriffe.
Was hervorsticht, ist nicht schicke KI oder exotische Hardware. Es ist Disziplin. Es ist die Eliminierung der vermeidbarsten Fehlerquelle in der automobilen Embedded-Entwicklung: menschliche Übertragungsfehler. Wie viele Feldrückrufe gingen auf einen Tippfehler in einem CAN-Signal-Skalierungsfaktor zurück? Auf eine vergessene Initialisierung eines Watchdog-Timers? Auf eine Versionsinkonsistenz zwischen einem Algorithmen-Update und seiner HAL-Abhängigkeit?
Diese Arbeit umgeht diese Risiken durch Design. Wenn das Simulink-Modell die Spezifikation ist und der Code das Modell ist – komplett kompiliert, ohne manuelle Eingriffe – wird der Weg vom Konzept zum Silizium nachvollziehbar, wiederholbar und zertifizierbar. Das ist Musik in den Ohren von Functional-Safety-Ingenieuren, die nach ISO 26262 arbeiten. Die Rückverfolgbarkeit verbessert sich. Die Testabdeckung wird aussagekräftiger. Modellwiederverwendung über Fahrzeugplattformen hinweg – etwa von einem Stadtauto zu einem leichten Nutzfahrzeug – wird ohne wochenlange Re-Integrationsarbeit machbar.
Industrieveteranen werden Parallelen zur AUTOSAR-Vision einer geschichteten, standardisierten Softwarearchitektur erkennen. Doch während eine vollständige AUTOSAR-Einführung für kleinere OEMs oder Startups nach wie vor kostspielig und komplex bleibt, bietet dieser Simulink + STM32-MAT/TARGET-Weg eine pragmatische Mitte: streng genug für sicherheitskritische Funktionen, doch zugänglich genug für Rapid Prototyping und akademische Forschung.
Freilich räumt die Arbeit ein, dass ihr Umfang ein Machbarkeitsnachweis ist. Die Fehlersignale waren fest codiert (BMS_Fault = 0, VCU_Fault = 0), was die Validierung vereinfachte. Echte Fahrzeuge müssen Dutzende asynchrone Fehlerflags, thermische Drosselkurven, Isolationsüberwachung und Notlaufstrategien handhaben – Schichten, die hier noch nicht modelliert wurden. Und während die Echtzeitleistung auf einem repräsentativen Mikrocontroller verifiziert wurde, würde die Skalierung auf Multi-Core-Prozessoren oder zeitgesteuerte Architekturen (z.B. für ASIL-D-Systeme) eine tiefere Integration mit RTOS-Schedulern und Speicherschutzeinheiten erfordern.
Die Autoren selbst weisen auf den nächsten logischen Schritt hin: Hardware-in-the-Loop (HIL) Co-Validierung. Der Vergleich der Ausgabe des automatisch generierten Embedded-Codes mit der ursprünglichen Simulink-Offline-Simulation – nicht nur in der Logik, sondern in der Zeitgenauigkeit – würde Jitter, Worst-Case Execution Time (WCET) und Interrupt-Latenz unter Last quantifizieren. Diese Daten sind vor einem Serieneinsatz unerlässlich.
Dennoch ist die Grundlage solide. Und der Zeitpunkt könnte nicht besser sein.
Man betrachte die Makrotrends: EV-Startups stehen unter brutalem Kapitaleffizienzdruck. Etablierte OEMs kämpfen darum, Tausende von Ingenieuen umzuschulen, die in Verbrennungsmotorenlogik verwurzelt sind. Regulierungsbehörden verschärfen die Prüfung softwaredefinierter Sicherheit. In diesem Umfeld sind Werkzeuge, die Entwicklungszyklen komprimieren ohne Strenge zu opfern, nicht nur bequem – sie sind existenziell.
Bereits jetzt deuten Hinweise darauf, dass große Tier-1-Zulieferer ähnliche Workflows pilotieren. Einige erweitern das Paradigma über VCUs hinaus – auf Batteriemanagement, Thermalsysteme, sogar auf steer-by-wire Controller. Der gemeinsame Nenner? Behalte die Autorität des Modells. Lass die Maschine den Code schreiben.
Wird dies handoptimierten Assembler für ultra-latenzarme Motorsteuerung ersetzen? Unwahrscheinlich. Es wird immer einen Platz für handwerkliche Embedded-Kunst auf höchstem Leistungsniveau geben. Doch für die überwältigende Mehrheit der Fahrzeugsteuerungsfunktionen – Zustandsverwaltung, Signalarbitrierung, Modusübergänge, Diagnosesequenzen – ist dieses Maß an Automatisierung nicht nur praktikabel. Es entwickelt sich zur Best Practice.
Back in Nanjing mag der Laboraufbau bescheiden wirken: ein Steckbrett, einige Potentiometer, ein Laptop mit LabVIEW. Doch was er repräsentiert, ist weitaus größer: eine stille Revolution in der Art und Weise, wie intelligente Fahrzeuge entstehen – nicht in fragmentierten Silos aus Code und Hardware, sondern als vereinheitlichte, in sich konsistente Systeme, verifiziert bevor die erste Lötstelle abkühlt.
Da die Elektrifizierung Fahrt aufnimmt, ist der Engpass nicht mehr die Batteriechemie oder die Motortopologie. Es ist die Engineering-Bandbreite. Methoden wie diese sparen nicht nur Wochen an Integrationsfrust – sie schaffen kognitiven Freiraum für Ingenieure, um sich auf das zu konzentrieren, was Fahrzeuge wirklich ausmacht: Fahrgefühl, Nuancen der Energierückgewinnung, adaptive Thermomanagementstrategien, Resilienz bei Over-the-Aire-Updates. Die Erfahrung, nicht die Grundlagenarbeit.
Und in einer Branche, in der Markenloyalität heute ebenso von Software-Reaktionsfähigkeit wie von Fahrwerksdynamik abhängt, könnte diese Fokusverschiebung entscheidend sein.
Ein letzter Hinweis: Die DOI der Studie ist nicht nur eine Zitatsfußnote. Sie ist ein Wegpunkt. Eine Markierung im Übergang von „Code als Handwerk“ zu „Code als kontinuierliches, verifiziertes Artefakt“. Für Entwickler, die täglich mit Integrationsdrift und Testschulden kämpfen, ist sie es wert, gebookmarkt zu werden.
Denn die Zukunft der Fahrzeugsteuerung wird nicht Zeile für Zeile in C geschrieben werden. Sie wird von Ende zu Ende mit Zuversicht modelliert, simuliert und generiert werden. Und diese Zukunft ist, dank Arbeiten wie dieser, bereits auf der Teststrecke.
Autoren: Huan Shen, Fuliang Zhou, Jianguo Mao, Wei Chen, Zhiwei Yan Einrichtung: College für Energie- und Antriebstechnik, Universität für Luft- und Raumfahrt Nanjing Zeitschrift: Journal of Chongqing University of Technology (Natural Science) DOI: 10.3969/j.issn.1674–8425(z).2023.05.002