Batteriemanagementsystem ohne Mikrocontroller

Moderne Hochvoltbatterien werden zur Reichweitensteigerung immer dichter an ihre Betriebsgrenzen gebracht. So wird das Maximum aus der teuersten Komponente im Fahrzeug herausgeholt und das Verhältnis von Kosten und Nutzen verbessert. Doch auch die Peripherie kann dazu beitragen, die absoluten Kosten zu reduzieren. Vitesco Technologies stellt dazu ein Batteriemanagementsystem mit vereinfachter Architektur vor.

Die Hochvoltbatterie (HVB) ist im Elektrofahrzeug unverändert die teuerste Einzelkomponente, auch wenn die Kosten pro kWh immer weiter sinken. Aktuell liegen sie bei etwa 120 US-Dollar pro kWh und werden voraussichtlich in den nächsten drei Jahren auf unter 90 US-Dollar pro kWh fallen [1]. Die tatsächliche Entwicklung der Batteriekosten hängt aber nicht nur von technischen Fortschritten, sondern auch von geopolitischen Faktoren ab, die nur schwer vorhersehbar sind. Daher gilt es umso mehr, die Kosten rund um die Batterie möglichst niedrig zu halten. Dieser treibende Faktor erklärt zusammen mit den Anforderungen, die an die Batteriesicherheit gestellt werden, warum die HVB und damit das Batteriemanagementsystem (BMS) aktuell im Fokus der Aufmerksamkeit stehen.

Der zweite treibende Faktor ist die Weiterentwicklung der Elektrik/Elektronik (E/E)-Architektur in allen Fahrzeugklassen. In traditionellen Fahrzeugarchitekturen sind zahlreiche Steuergeräte (Electronic Control Units, ECUs) verbaut und über das System verteilt, von denen jede eine bestimmte Funktion im Fahrzeug erfüllt. Mit der Elektrifizierung, Digitalisierung und dem wachsenden Umfang zusätzlicher Funktionen, wie zum Beispiel im Infotainment, bei Komfort und Steuerung sowie für das autonome Fahren, hat die Anzahl der ECUs und damit auch deren Kosteneinfluss drastisch zugenommen.

Mit dem Leistungsfortschritt bei der Halbleitertechnik haben sich neue Möglichkeiten für die Architektur ergeben. Da die Leistung der Halbleiter mit jeder Generation steigt - und mit ihr die Kosten der Komponente - ist es sinnvoll, diese höhere Leistung von weniger Chips so weit wie möglich auszunutzen und dafür die Anzahl der ECUs zu senken. In Bild 1 ist die so entstehende fahrzeugzentrierte Architektur mit wenigen Hochleistungsrechnern im rechten Modell dargestellt. Sie bündelt die Funktionen in Teilbereiche zu einer zonalen Systemarchitektur [2, 3].

Bild 1

Fahrzeugzentrierte Architekturen mit wenigen Hochleistungsrechnern (rechte Bildhälfte) können die Zahl der ECUs im Fahrzeug um über 90 % reduzieren (linke Bildhälfte) (© Vitesco Technologies)

Es kann davon ausgegangen werden, dass der Marktanteil von teil- bis vollelektrifizierten Fahrzeugen bis 2030 weiter steigt. Das Steuergerät des BMS in die zukünftige E/E-Systemarchitektur zu integrieren, ist somit ein logischer Schritt in Richtung Systemoptimierung. Dabei geht es um die Frage, wie viele Halbleiter benötigt werden beziehungsweise wo und wie sich diese Anzahl reduzieren lässt. Im Folgenden wird am Beispiel des BMS gezeigt, unter welchen Bedingungen eine Vereinfachung möglich ist.

Status Quo

Das BMS besteht aus einem zentralen Batteriesteuergerät (Battery Management Unit, BMU) samt Software, einem Hochvoltstromsensor (High-Voltage Sensing Device, HVSD) sowie mehreren Zellüberwachungseinheiten (Cell Monitoring Units, CMUs). In dieser Konfiguration sind in Summe bis zu sechs Halbleiter verbaut. Auf der BMU ist in der Regel eine Steuerungssoftware gespeichert, die mit dem HVSD und den CMUs verbunden ist. Dieses System steuert und überwacht den Zustand der Batterie auf Zellebene und berechnet den Alterungszustand (State of Health, SOH) sowie den Ladezustand (State of Charge, SOC), Bild 2.

Bild 2

Klassische Architektur eines Batteriemanagementsystems (VCU: Fahrzeugsteuergerät (Vehicle Control Unit), CMU: Zellüberwachungseinheit (Cell Monitoring Unit), BMU: zentrales Batteriesteuergerät (Battery Management Unit)) (© Vitesco Technologies)

Für eine Aufteilung und zukünftige Integration des BMS in die Gesamtfahrzeugarchitektur sind die zwei Pfade einer BMU wichtig: Es gibt einen Hochvolt- und einen Niedervoltpfad. Beide sind in heutigen Produktdefinitionen in einem Produkt zusammengefasst. Der Vorteil des aktuellen Systemdesigns ist, dass es kompakt ausgelegt ist. Nachteilig sind jedoch die große Zahl von Komponenten innerhalb der Batterie sowie die geringe Flexibilität in der Steuerung. Die Steuerung des Batteriezustands erfolgt zentral über die BMU und ist damit an diese Komponente gebunden. Aus der übergeordneten Perspektive betrachtet ist das BMS nichts weiter als eine Funktion, die in der Batterie verbaut ist - eine ECU mit ein paar Sensoren innerhalb des Batteriegehäuses.

Öffnet man dieses System und löst sich von den vorhandenen Grenzen, dann ergeben sich neue Möglichkeiten. Programmiert man die Software unabhängig von der Hardware, wie es in Zukunft im softwaredefinierten Fahrzeug (Software-Defined Vehicle, SDV) Standard sein wird, dann stellt das Anforderungen an beide Teile: Die Hardware wird integriert, die Software muss zusätzliche Funktionen erfüllen und flexible Module beinhalten, wie nachfolgend dargestellt.

Zukünftige Rolle von Software und Modulentwicklung

Die Software im Fahrzeug ist nach dem Branchenstandard Autosar entwickelt: die signalbasierte Classic-Plattform auf Mikrocontrollern und die Adaptive-Plattform auf Mikroprozessoren, die gemäß einer serviceorientierten Architektur aufgebaut sind. Modulare BMS-Software für verschiedene E/E-Architekturen muss unterschiedliche Anforderungen erfüllen. Funktionsteile mit hohen Echtzeitanforderungen oder hohen Sicherheitsklassen können nur auf mikrocontrollerbasierten Systemen nahe der Sensorik und Aktuatoren implementiert werden und unterliegen typischerweise aufwendigeren Freigabeprozeduren. Strategie- und Managementfunktionen sowie Zustandsautomaten auf Fahrzeugebene können durchaus davon getrennt auf Mikroprozessoren ausgeführt werden und unterliegen häufig schnelleren Aktualisierungszyklen.

Mit der Zentralisierung in Hochleistungsrechnern steigen der Softwareumfang und die Komplexität der Softwareintegration. Darum ist es notwendig, die Software in kleinere, unabhängige Einheiten zu teilen und diese so gut wie möglich rückwirkungsfrei zum restlichen Softwaresystem zu gestalten. Technologien wie Software Cluster oder Hypervisor, die mittlerweile in der Autosar-Classic-Welt verfügbar sind [2], erlauben diese nahezu rückwirkungsfreie Aktualisierung von Programmteilen unabhängig vom restlichen Softwaresystem, Bild 3. Die Software-Cluster-Technologie ermöglicht darüber hinaus eine automatische Verbindungstechnik der Schnittstellen zum Restsystem; sie kann auch mit noch nicht vorhandenen Schnittstellen umgehen und erlaubt dadurch eine weitestgehend unabhängige Entwicklung in getrennten Teams oder Unternehmen.

Bild 3

Softwarepartitionierung und Separierung in Autosar Classic und Adaptive (© Vitesco Technologies)

Zukünftige BMS-Struktur

In der modularen Systemarchitektur wird das zentrale Batteriesteuergerät des BMS aufgeteilt und in die neue E/E-Architektur im Fahrzeug integriert. Die Funktionen können flexibel aus dem Batteriekörper extrahiert und in den Zone Controller oder in den Master Controller integriert werden. Ein wesentlicher Punkt ist die Kommunikation und Informationsweitergabe von den Zellüberwachungseinheiten (Slave CMUs) zum zentralen Steuergerät (Master CMU) - in diesem Fall dem Zone Controller. Hier gilt es zu beachten, dass die Informationen aus dem Batteriegehäuse nach außen transportiert werden müssen. In der in Bild 4 gezeigten Lösung laufen die Informationen innerhalb der Batterie von den Slave CMUs über eine Daisy-Chain-Topologie zur Master CMU. Auf der Hardwareebene reduziert diese Vereinfachung die Zahl der Komponenten in der Batterie - es fällt die BMU samt Platine, Gehäuse, Steckverbindungen und Kabel weg. Als Schnittstelle nach außen kann der CAN dienen oder in Zukunft eine Ethernetverbindung zur Master CMU. Er enthält den Mikrocontroller oder Mikroprozessor mit der Leistung für die zusätzlichen Softwarefunktionen.

Bild 4

Neue Systemarchitektur mit Integration der BMU-Funktion in den Zone-/Master-Controller (© Vitesco Technologies)

Die größte Optimierung jedoch ergibt sich aus der Integration der BMU-Funktion in den Zone Controller. Durch diese Integration erhält der Mikrocontroller auf dem Zone Controller die Informationen von den Slave CMUs, verarbeitet sie und übernimmt so die Funktionen des BMU. Das bedeutet mehr als Stücklisten- und Kostenoptimierungen, denn durch die Trennung von Hardware und Software ist das System unabhängig vom Batterielieferanten. Die Softwarefunktion kann damit einmal entwickelt und wiederverwendet werden.

Vor- und Nachteile

Das Auftrennen von Hardware und Software bringt wie bei den meisten ECUs den Vorteil der Flexibilität und Nutzung gemeinsamer Peripherie sowie Rechenleistung. Im Speziellen kann damit das BMS als Ganzes schneller und einfacher weiterentwickelt werden, da die Bindung an die Batterie aufgehoben wird. Es lassen sich leichter neue Softwarefunktionen unabhängig vom ursprünglichen Hersteller integrieren. So können aufgrund gesteigerter Rechenleistung präzisere State-of-X(SOX)-Prädiktionsalgorithmen implementiert werden. Mit diesen können unter anderem wesentliche SOX-Batterieparameter wie SOC/SOH mit einer höheren Genauigkeit bestimmt werden, was wiederum zu einer gesteigerten Batteriereichweite führen kann.

Des Weiteren ist nun eine performante Cloudanbindung einfach zu realisieren, die weitere KI-basierte Analysemöglichkeiten zur Identifizierung von Batterieanomalien erlaubt sowie die Möglichkeit schafft, über diese Schnittstelle durch entsprechende Updates over-the-air einzugreifen.

Herausforderung und gleichzeitig Voraussetzung für eine erfolgreiche Realisierung ist die Softwareclusterung. Dafür muss die Softwarearchitektur mitwachsen und auch kommende ASIL-D-Anforderungen für Überspannung, Strom und Temperatur müssen eingearbeitet werden.

Fazit und Ausblick

Wenn man das bisherige BMS zu einem Cluster aus Softwareblöcken zusammensetzt, können Kosten gespart, die Komplexität der Hardware reduziert und die Fertigung vereinfacht werden. Weiterentwickelte, modulare Software mit hohem Wiederverwendungsanteil macht die steigende Komplexität der Software beherrschbar. Die zukünftige Struktur befindet sich bereits in der zweiten Generation und soll 2028 in Serie gehen.

Neben einem nachträglichen Softwareupdate, das mit der neuen BMS-Architektur und einer entsprechenden Cloudanbindung bereits möglich ist, wäre der nächste Entwicklungsschritt ein sich selbst parametrisierendes BMS. Dies sähe die Implementierung einer von Batterie und Zelltyp unabhängigen Grundkonfiguration des BMS vor, das sich selbstständig während der Fahrt und gestützt von der Cloud an die jeweiligen Batterieparameter anlernt.

Zusammenfassend können durch ein BMS ohne Microcontroller, dessen Funktionen sich in einer zonalen Architektur wiederfinden, zum einen Hardwarekosten reduziert und zum anderen Potenzial für neue Funktionen geschaffen werden.

Literaturhinweise

• [1] Goldman Sachs (Hrsg.): Electric vehicle battery prices are falling faster than expected. 1. November 2023. Online: https://www.goldmansachs.com/intelligence/pages/electric-vehicle-battery-prices-falling.html, aufgerufen: 24. Januar 2024

• [2] Mader, R.; Winkler, G.; Reindl, T.; Pandya, N.: The Cars Electronic Architecture in Motion: The Coming Transformation. Tagungsband, 42. Wiener Motorensymposium, 2021

• [3] Hackelsperger, M.; Reindl, T.; Mader, R.; Winkler, G.: Master Controller für das softwaredefinierte Fahrzeug. In: ATZelektronik (17) 2022, Nr. 7-8, S. 44-47