Im Wohlfühlmodus: Batteriesysteme für den Rennsport und die Serie

In batterieelektrischen Fahrzeugen (Battery Electric Vehicle, BEV) spielt das Batteriemanagementsystem (BMS) eine zentrale Rolle. Es besteht aus dem Batterie-Management-Controller (BMC) und den Zellmodul-Controllern (Cell Module Controller, CMC). Die CMCs sind direkt in die Module der Hochvoltbatterie integriert und liefern Messwerte wie Zellspannung- und Temperatur an den BMC. Zudem sind sie für das „Cell Balancing“ verantwortlich: Hochvoltbatterien bestehen aus vielen einzelnen Niedervolt-­Batteriezellen. Allerdings führen Toleranzen zu individuellen physikalischen Eigenschaften der Zellen, wodurch es zu Problemen bei der Nutzung des Systems kommen kann. Um das zu verhindern, gleichen die CMCs den Ladezustand der Zellen aus – entweder passiv durch parallel geschaltete Widerstände oder aktiv durch den Transfer von Ladung von schwächeren zu stärkeren Zellen. Der BMC ist die zentrale Instanz des BMS und nutzt neben den Messwerten der CMCs auch eigene Stromsensoren. Eine seiner Aufgaben ist es, die Sicherheit der Batterie zu gewährleisten. Denn Batteriesysteme enthalten große Mengen an Energie und sind in der Lage, diese Energie sehr schnell freizusetzen. Eine unkontrollierte oder ungewollte Freisetzung ist unbedingt zu verhindern. Zudem muss der BMC einen optimalen Kompromiss zwischen der Lebensdauer der Batterie und der Performance finden, weil der Betrieb außerhalb der Spezifikationen zu Schäden am System führen kann. Typische Ursachen dafür sind zu hohe Ströme, zu hohe oder zu tiefe Temperaturen, was den Elektrolyten schädigt oder zu einer höheren Stromempfindlichkeit führt, sowie Über- oder Unterspannungen, die den Elektrolyten oder die aktiven Materialien schädigen können.

Um das zu verhindern, werden durch das BMS je nach Batteriezustand Stromgrenzen verändert, Betriebsmodi begrenzt oder die Kühlung angepasst. „Auf Basis der Messwerte von zahlreichen Temperatur-, Strom- und Spannungssensoren leitet das BMS drei entscheidende Parameter der Batterie ab: den Ladezustand (State of Charge, SoC) und die Kapazität, die die Restreichweite bestimmen, und den Innenwiderstand, der die Performance begrenzt“, erklärt Lukas Mäurer, Projektleiter Hochvoltbatterie-­Funktionen bei Porsche Engineering. „Außerdem ist es für Sicherheitsfunktionen wie die Überstrom-Abschaltung und die Crash-Erkennung sowie für die Kommunikation mit den anderen Controllern im Fahrzeug verantwortlich.“

 

Mehr als 20 Jahre Erfahrung

Porsche Engineering hat bereits diverse BMS im Kundenauftrag entwickelt und kann dabei alle Aufgaben übernehmen, die längs des V-Modells anfallen – von der Anforderungserhebung bis hin zum Fahrzeugtest. „Als Unternehmen sind wir schon seit mehr als 20 Jahren auf diesem Gebiet tätig, ich selbst beschäftige mich seit sechs Jahren mit Batteriemanagementsystemen“, sagt Mäurer. Trotz aller Erfahrungen in zahlreichen Projekten bleibt die Entwicklung eines BMS selbst für erfahrene Entwickler eine anspruchsvolle Aufgabe: Die Software ist ausgesprochen komplex, was sowohl die Technik als auch die Projektleitung vor einige Herausforderungen stellt. Darum legt Porsche Engineering großen Wert auf einen stringenten und transparenten Prozess. An seinem Beginn steht das Anforderungsmanagement, dem die Experten besondere Aufmerksamkeit schenken. „Denn es werden nicht nur die technischen Grundlagen gelegt – hier entscheidet sich auch der weitere Projektverlauf“, betont Achim Olpp, Projektleiter bei Porsche Engineering.

Prüfung des Lastenhefts

Bereits bei der „Wareneingangsprüfung“ eines neuen Lastenheftes müssen mögliche Probleme erkannt und beseitigt werden. Olpp verweist auf die „Rule of Ten“: Mit jeder Stufe der Software-Entwicklung steigen die Kosten für die Fehlerbehebung um den Faktor 10. Der Aufwand nimmt mit jedem Prozessschritt zu, da bereits erfolgte Arbeit überprüft und ab dem Fehler erneut erledigt werden muss. Auch Folgefehler müssen wieder „eingefangen“ werden. Dies gefährdet fast automatisch die oft eng gesteckten Terminpläne, insbesondere bei Software für mehrere Kunden in angepassten Varianten.

Um solchen Zusatzaufwand zu verhindern, hat es sich bewährt, dass der Verfasser des Software-Pflichtenheftes unter der Leitung des Anforderungsingenieurs alle Projektbeteiligten zu einem „Review“ des vom Kunden gelieferten Lastenheftes zusammenruft. „Dann sind alle an einem Tisch versammelt, darunter die Software-Architekten und -Entwickler sowie die Tester und der Kunde“, erklärt Olpp. „So kann man die Anforderungen aus dem Lastenheft viel besser verstehen und die möglichen Lösungen für das Pflichtenheft gezielter festlegen. Bei mehreren Kunden bietet das Review die Möglichkeit zur Moderation unterschiedlicher Interessen.“ Das erhöhe zu Beginn zwar etwas den Aufwand, führe langfristig aber zu einer deutlichen Zeitersparnis. Auf dieser soliden Basis baut die Planung der Arbeitsumfänge auf. „Wir veranstalten zwei Wochen vor jedem Software-Releasezyklus einen Kapazitäts-Workshop, bei dem der Bedarf des Kunden mit den zur Verfügung stehenden Ressourcen abgeglichen wird“, berichtet Olpp. „So wissen wir genau, was in der zur Verfügung stehenden Zeit erreicht werden kann. Und der Kunde kann gegebenenfalls die Arbeitspakete priorisieren.“

 

Kapazitäten klar aufzeigen

Präzises Kapazitätsmanagement kann auch den gefürchteten „Scope Creep“ verhindern helfen. Dabei verändern sich die Anforderungen an ein Produkt kontinuierlich und ungesteuert während seiner Entwicklung, was oft zu Verzögerungen führt. „Wenn man seine Kapazitäten klar aufzeigt, kann man auch die Auswirkungen einer solchen Anforderungsdynamik besser verstehen und koordinieren“, so Olpp. Speziell beim Einsatz von Software-Gleichteilen für mehrere Modelle und Marken ist bei diesem Schritt viel Sorgfalt nötig. Denn falsch eingesteuerte Umfänge können aufgrund der modularen Terminschiene gleich mehrere Fahrzeugbaureihen gefährden. Software-Architekten sind bei der BMS-Entwicklung ebenfalls mit einigen Herausforderungen konfrontiert. Sie müssen unter anderem berücksichtigen, dass die Zellchemie und der Aufbau der Batterien sich ständig weiterentwickeln.
„Eine veränderte Batterie-Kühlung hat unter anderem Auswirkungen auf das Thermomanagement“, erklärt Mäurer. „Die Temperatur der einzelnen Batteriezellen kann nicht vollständig sensorisch erfasst werden. Wenn beispielsweise 60 Sensoren genutzt werden, um die Temperatur für 200 Zellen zu bestimmen, muss die Software-Architektur verschiedene Verbaupositionen der Sensoren und unterschiedliche Kühlkonzepte wie mehrseitige Kühlplatten unterstützen.“ Darum müsse man die BMS-Funktionen so entwickeln, dass sie sich leicht an solche Veränderungen anpassen lassen. Auch bei der Software-Architektur führt der Einsatz von Software-Gleichteilen zu zusätzlichen Herausforderungen. Sie machen modulare Strukturen erforderlich, die einerseits die Anforderungen eines spezifischen Fahrzeugs erfüllen und andererseits nicht zu Nachteilen bei anderen Modellen führen.

„Ohne solide Prozesse ist ein BMS-Projekt wie ein Hochhaus ohne stabiles Fundament.“
Achim Olpp, Projektleiter bei Porsche Engineering

An Ressourcen anpassen

Die Software-Entwicklung folgt auf die Festlegung der Software-Architektur und hat das Ziel, Lösungen aus der Vorentwicklung serientauglich zu machen. Eine typische Aufgabe besteht zum Beispiel darin, Algorithmen an die begrenzten Ressourcen hinsichtlich Rechenleistung und Speicherkapazität der Steuergeräte in Fahrzeugen anzupassen – ohne dass die Qualität der Ergebnisse leidet. „In der Vorentwicklung wird in der Regel meist nur eine einzige Zelle mit Sensoren überwacht, im Fahrzeug sind es mehrere Dutzend“, sagt Mäurer. „Man kann den für einen Prototyp verwendeten Algorithmus in der Serie aber nicht einfach dutzende Male nacheinander ablaufen lassen, weil dadurch die erforderliche Rechenleistung zu hoch würde.“ Zudem werden in BEVs viele innovative Funktionen eingesetzt, zum Beispiel für das Schnellladen. Sie operieren oft an der Grenze des aktuell technisch Machbaren. Diese Funktionen müssen beim Übergang vom Prototypen- zum Serienstand so robust gemacht werden, dass sie unter allen Bedingungen ohne Probleme ablaufen. „Beim Schnellladen könnte man das durch die Implementierung von Regelalgorithmen erreichen, die den Ladestrom bei drohender Überhitzung oder Spannungsüberschreitung begrenzen“, sagt Mäurer.

„Wir haben viele Erfahrungen bei der BMS-Entwicklung gesammelt, vom Rennsport bis zur Großserie.“
Lukas Mäurer, Projektleiter Hochvoltbatterie-Funktionen bei Porsche Engineering

Verfolgt der Kunde zusätzlich eine Software-Gleichteilstrategie, müssen die Entwickler auch eine hohe Anpassbarkeit ihrer Funktionen gewährleisten, um sich beispielsweise an verschiedene Zellchemien oder Hardware-Konzepte anpassen zu können. „Software-Entwicklung für die Serie ist eine Transferleistung, für die unter anderem Porsche Engineering besonders gute Voraussetzungen mitbringt“, fasst Mäurer zusammen. „Wir haben viele Erfahrungen bei der BMS-Entwicklung gesammelt, vom Rennsport bis zur Großserie. Unsere Lösungen sind in allen Marken des Volkswagen-Konzerns vertreten, aber auch im 919 Hybrid, dem Le-Mans-Sieger von Porsche.“ Daneben verfügt Porsche Engineering auch über ein eigenes Zell- und Batterie-Know-how sowie über Erfahrungen mit neuen Technologien wie 800-Volt-Netzen in Fahrzeugen. Wie gut die entwickelte Software die Anforderungen erfüllt, bewerten die Experten erstmals beim Modultest. Dabei werden die kleinsten Einheiten der Programme – zum Beispiel für die Berechnung der Restkapazität – mit definierten Eingangswerten gespeist. Liefern sie die erwarteten Ergebnisse, arbeitet der Algorithmus grundsätzlich korrekt. Andernfalls müssen die Software-Entwickler den Programmcode bearbeiten. „Als erster Verifikationsschritt bietet der Modultest viel Potenzial, um Zeit und Geld einzusparen“, so Mäurer. „Denn alles, was hier gefunden wird, wäre später im Projektverlauf nur mit deutlich höherem Aufwand zu beheben.“

Vier-Augen-Prinzip beim Test

Bei Porsche Engineering gilt für den Modultest das Vier-Augen-Prinzip: Programmierung und Test werden von unterschiedlichen Mitarbeitern durchgeführt. Ganz am Ende kommt noch ein Vertreter der Qualitätssicherung hinzu, der neben dem Ergebnis auch die zuvor durchlaufenen Entwicklungsprozesse validiert. So ist sichergestellt, dass die nächsten Schritte des V-Modells – Integrations-, Software- und Fahrzeugtests – auf einer guten Grundlage aufbauen können. Denn für den gesamten Entwicklungsprozess gilt der Hinweis von Projektleiter Olpp: „Ohne solide Prozesse ist ein BMS-Projekt wie ein Hochhaus ohne stabiles Fundament.“