Kooperation für die Formula Student
Mit Elektronik an die Pole-Position
Jedes Jahr konzipiert das Studierendenteam Mainfranken Racing einen neuen Rennwagen für die Formula Student. Bei der Elektronik- und Softwareentwicklung setzen die Nachwuchsingenieurinnen und -ingenieure auf zwei namhafte Player aus dem Automotive-Geschäft – mit Erfolg.
Aus der Idee einzelner motorsportbegeisterter Studenten an der Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt im Jahr 2006 wurde die Teilnahme an der Formula Student aus der Taufe gehoben. Motivierte Studenten unterschiedlicher Fachbereiche bildeten ein Team namens Mainfranken Racing (MFR). Mainfranken Racing e.V. ist mittlerweile ein eingetragener, gemeinnütziger Verein mit Sitz an der Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt. Neben dem Aufbau eines effizienten Fahrzeuges ist es Ziel des Vereins, sich im Rahmen mehrerer internationaler Wettbewerbe mit der Konkurrenz zu messen.
Dazu ist es unabdingbar, jede Saison einen möglichst leichten, aber zugleich auch leistungsstarken und konkurrenzfähigen Rennwagen zu entwickeln. Um das zu erreichen, werden die verschiedenen Komponenten über Monate hinweg geplant und gefertigt. In den vergangenen 18 Jahren wurden auf diese Weise viele Veränderungen und Innovationen umgesetzt. So ist Mainfranken Racing in den ersten elf Saisons noch mit einem Verbrennungsmotor an den Start gegangen und ab dann mit einer Elektrovariante.
Mit dem dritten E-Fahrzeug des Teams kam dann unter anderem der Umstieg auf ein Monocoque aus Carbonfaser, um die höchstmögliche Gewichtsersparnis im Chassis zu erzielen. Ein Monocoque ist eine spezielle Konstruktion, die das Chassis bildet und den Rahmen ersetzt. Dadurch kann eine höhere Stabilität bei weniger Masse im Fahrzeug erreicht werden. Der Fertigungsprozess allerdings ist sehr aufwendig und erstreckt sich über mehrere Monate. Das aktuelle, vierte Fahrzeug mit E-Motor, der MF16, beinhaltet zusätzlich ein autonomes System, das bei entsprechenden Wettbewerben an den Start geht.
In der Saison 2024/2025 konnte Mainfranken Racing große Erfolge feiern: Anfang August belegte das Team in den Driverless-Disziplinen mit seinem autonomen System in Tschechien den dritten Platz und in Frankreich stand es mit dem zweiten Platz in der Gesamtwertung auf dem Podest.
Jobangebote+ passend zum Thema
XMC-Mikrocontroller und Trace32-Debugger im Einsatz
Für zentrale Fahrzeugfunktionen, von denen exemplarisch im weiteren Verlauf dieses Beitrags einige detailliert erläutert werden (Dashboard, Batteriemanagementsystem, Traktionskontrolle und Schlupfregelung), hat Mainfranken Racing sich für Mikrocontroller aus Infineons XMC-Familie entschieden. Infineon ist seit Langem enger Partner und Sponsor von MFR.
Die XMC-Mikrocontrollerfamilie basiert auf Arm-Cortex-M-Kernen. Die XMC1000-Mikrocontroller vereinen den Arm-Cortex-M0-Kern sowie markterprobte und differenzierende, in einem 65-nm-Prozess gefertigte Peripherie, während die XMC4000 auf einem Arm Cortex-M4 mit einem integrierten DSP-Befehlssatz basieren.
Lauterbachs Debug- und Trace-Tools unter der Marke Trace32 sind bei sämtlichen wichtigen Automobilherstellern, deren Zulieferern und Chip-Herstellern im Einsatz. Um einen möglichst einfachen und problemlosen Einsatz mit den XMC-Chips sicherzustellen, hat sich Mainfranken Racing folgerichtig für Lauterbachs µTrace entschieden, der das Debuggen auf Cortex-M-CPUs mit der höchsten am Markt verfügbaren Bandbreite erlaubt. Zusätzlich zu seinen führenden Debug-Fähigkeiten auf dem Cortex-M-Markt kann µTrace Echtzeitinformationen wie System-Traces und parallele ETM-Flow-Traces aufzeichnen und so beispielsweise Code Coverage und Code Profiling ermöglichen.
Inbetriebnahme des µTrace-Debuggers
Zum ersten Testen der Trace- und Debug-Schnittstelle eines XMC4700-Mikrocontrollers wurde ein eigenes Evaluierungsboard entworfen (Bild 1a).
Zweck dieser Platine war es, möglichst schnell den Trace32 µTrace Debugger mit der gegebenen Hardware in Betrieb nehmen zu können. Bild 1b zeigt das Blockdiagramm des Evaluierungsboards. Das vollständige Set-up mit µTrace-Debugger und Platine ist
in Bild 2 ersichtlich. Dank der einfachen Konfiguration der Software Trace32 PowerView konnten der µTrace-Debugger mit diesem testweisen Aufbau schnell in Benutzung gebracht und die ersten Probleme in der eigenen Software gefunden werden.
Anwendungsfall Dashboard
In Bild 3 ist die Leiterkarte des Dashboards zu sehen. Das Dashboard dient als zentrale Anzeige für eine Vielzahl von Fahrzeugparametern und -zuständen, einschließlich des Ladezustands des Akkus und der Temperatur des Kühlkreislaufs.
Es bietet auch die Möglichkeit, die Funktion des autonomen Fahrens (Driverless) zu aktivieren, indem ein Drehknopf auf dem Cockpit betätigt wird. Die gewählte Driverless-Mission wird durch eine blaue LED signalisiert und anschließend über den CAN-Bus an das Fahrzeug übermittelt. Zusätzlich registriert das Dashboard den Zustand eines Ready-to-Drive-Buttons und sendet diesen Wert ebenfalls über den CAN-Bus an das Fahrzeug. Zur Visualisierung der Daten werden hauptsächlich Status-LEDs und ein LC-Display verwendet.
Die Architektur der Dashboard-Software ist in Bild 4 dargestellt. Die Software liest die benötigten Informationen über das CAN-Interface direkt aus dem Fahrzeug-CAN aus. Das Hardware-Interface übernimmt die Erfassung des Encoders für die Driverless-Mis- sionen sowie des Buttons für die Ready-to-Drive-Funktion. Im State-Handler werden die abgerufenen Werte entweder dem Status einer Status-LED zugeordnet oder entsprechend konvertiert, um sie auf dem LC-Display darstellen zu können. Dabei wird über das CAN-Interface der Status an das Fahrzeug gesendet, über den LED-Switcher die entsprechende Farbe für die Status-LED festgelegt oder es werden Parameter auf dem LC-Display angezeigt.
Die Ansteuerung des LC-Displays erfolgt über SPI, wobei alle spezifischen Befehle zur Ansteuerung des Displays direkt in der LC-Display-Node implementiert sind. Um eine ansprechende und benutzerfreundliche Bedienoberfläche zu schaffen, wird die Grafikbibliothek LVGL verwendet. Der Entwicklungsprozess erfolgt mithilfe von GuiGuider, einer UI-Toolbox, die eine intuitive Erstellung von Benutzeroberflächen ermöglicht. Das LVGL-Lib-Interface dient als Brücke, um auf die verschiedenen Komponenten von LVGL und GuiGuider zuzugreifen. Das ermöglicht die Navigation zwischen verschiedenen Bildschirmen, die Anpassung von Parametern und viele andere Funktionen.
Der µTrace-Debugger in der Dashboard-Entwicklung
Bei der Softwareentwicklung für das Dashboard liegt das Hauptaugenmerk auf der Integration einer Grafikbibliothek mit dem Mikrocontroller sowie dem vorliegenden Display. Der µTrace-Debugger konnte dabei helfen, einen Speicherallokationsfehler zur Laufzeit des Dashboards zu finden. Geäußert hat sich der Fehler dadurch, dass nach mehrfachem Umschalten zwischen verschiedenen Seiten auf dem Display die Software abgestürzt ist.
Die Fehlersuche wurde durch das Tracen des Ablaufs der Software beschleunigt, indem bis zum Absturz der Software aufgezeichnet wurde. Durch Analysieren des abgelaufenen Codes kurz vor dem Softwarefehler konnte das Problem auf ein Speicherproblem eingegrenzt werden. Schlussendlich wurde das Problem in der Speicherallokation der Grafikbibliothek gefunden, die eine eigne malloc-Funktion nutzt. Durch Umstellen auf die Standard-C-malloc-Funktion konnte der Fehler behoben werden.
| Die Formula Student – ein studentischer Konstruktionswettbewerb |
|---|
|
Bei der Formula Student handelt es sich um einen Wettbewerb, bei dem Hochschulteams einen einsitzigen Rennwagen konstruieren und fertigen. Für die Planung und den Bau des Fahrzeugs haben die Teams von Oktober bis August Zeit. Bei verschiedenen Renn-Events treten die Teams dann mit ihren Fahrzeugen in verschiedenen Disziplinen gegeneinander an. Doch nicht nur die Geschwindigkeit auf den vorgegebenen Tracks entscheidet über den Gesamtsieg. Die sogenannten statischen Disziplinen spielen ebenfalls eine wichtige Rolle. Dazu gehört etwa die Präsentation des Designs und des Businessplans, aber auch eine Kostenaufschlüsselung. Bevor der eigentliche Wettbewerb beginnt, müssen die Teams die technische Abnahme, das sogenannte »Scrutineering«, bestehen. Bei Fahrzeugen der Formula Student Electric, also mit elektrischem Antriebsstrang, werden die elektrische Sicherheit sowie die Technik und Sicherheit allgemein geprüft. Darüber hinaus durchlaufen die Fahrzeuge einen »Kipptisch« genannten statischen Test, einen Regentest und einen Bremstest. Erst wenn all diese Prüfungen erfolgreich bestanden sind, werden die Fahrzeuge zum Wettbewerb zugelassen. |
Anwendungsfall Batteriemanagementsystem
Das Steuergerät des Batteriemanagementsystems (BMS-Master) verwaltet das Batteriemanagementsystem der HV-Batterie und führt die Fehlerüberwachung innerhalb des Akkus durch (Bild 5).
Der Master kommuniziert mit den BMS-ICs durch einen UART-Transceiver über ein isoliertes UART-Protokoll (Bild 6). Die BMS-ICs sind an die Li-Ionen-Zellen des Akkumulators angeschlossen und messen Zellspannungen und Zelltemperaturen.
Außerdem können Entladewiderstände an jede einzelne Zelle angeschlossen werden, um die Zellen auf das gleiche Spannungsniveau zu entladen, das sogenannte »Balancing«.
In Bild 7 sind die Softwaremodule des Batteriemanagementsystems zu sehen. Links sind Eingänge in die Software aufgezeigt. Dabei handelt es sich um das Isolationsüberwachungsystem (IMD); die BMS-ICs sind per Bussystem angeschlossen.
Außerdem ist der Mikrocontroller an den Fahrzeug-CAN-Bus angeschlossen und mit einem Stromsensor verbunden. Zur Speicherung nicht volatiler Daten ist ein EEPROM vorhanden. Das BMS-System kommuniziert über das BMS-Interface mit den ICs und liest so Messdaten wie Zelltemperaturen und -spannungen ein. Aus Zelldaten und dem Lade-/Entladestrom wird der State of Charge (SOC) sowie der State of Health (SOH) berechnet.
- Mit Elektronik an die Pole-Position
- Der µTrace-Debugger in der BMS-Entwicklung
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Sensor- und RF-Geschäfte gebündelt
SURF: Infineons neue Geschäftseinheit startet 2025
dSpace auf der CES
Nahtlose SIL/HIL-Validierung beschleunigt Software-Entwicklung
Nahtlose Interoperabilität
RTI kündigt DDS-Einführung in allen AUTOSAR-Plattformen an
Umwelt-/Klimaschutz bei hoher Qualität
Ressourcenschonende Lösungen für die Automobilindustrie
E-Auto-Innovation durch Kooperation
Nano-Stromsensoren für Hochleistungsanwendungen im Fahrzeug
SDVs verändern die Fahrzeugentwicklung
Plattformunabhängiges Softwaredesign für neue E/E-Architekturen
