Schnellere Entwicklung von BMS-Software durch Simulation auf Systemebene

Die wachsende Abhängigkeit von der Energiespeicherleistung von Batteriepacks unterstreicht die Bedeutung eines Batteriemanagementsystems (BMS), das maximale Leistung, sicheren Betrieb und optimale Lebensdauer unter verschiedenen Lade-/Entlade- und Umgebungsbedingungen gewährleisten kann. Um die Software für ein BMS zu entwerfen, welches all diese Anforderungen erfüllt, entwickeln Ingenieure Algorithmen für Regelung und Überwachung. Damit wird Folgendes erzielt:

• Regeln des Batterieladeprofils
• Überwachen von Zellspannung und Temperatur
• Ausgleichen des Ladezustands einzelner Zellen
• Schätzen des Ladezustands (State of Charge, SOC) und des Alterungszustands (State of Health, SOH)
• Begrenzen der Leistungseingabe und -ausgabe für den thermischen Schutz und Überladungsschutz
• Bei Bedarf Trennen des Batteriepacks von Stromnetz und Ladegerät

Ingenieure entwickeln diese BMS-Algorithmen und Software, indem sie Simulationen auf Systemebene mit Model-Based Design durchführen. Dank der Simulation können sie einen Einblick in das dynamische Verhalten des Batteriepacks erhalten, Software-Architekturen untersuchen, Betriebsfälle testen und Hardware-Tests zu einem früheren Zeitpunkt im Entwicklungsprozess starten. Das BMS-Simulationsmodell dient als Grundlage für Entwicklungsaktivitäten, einschließlich der Desktop-Simulation der funktionalen Aspekte des Designs, der formalen Verifizierung und Validierung nach Industriestandards sowie der Code-Generierung für die Echtzeitsimulation und Hardware-Implementierung (Abbildung 1).

Desktop-Simulation: Modellierung der BMS-Funktionalität

Die Desktop-Simulation ermöglicht es, funktionale Aspekte der BMS-Entwicklung zu verifizieren, wie z.B. das Lade- und Entladeverhalten, den Entwurf elektronischer Schaltungen sowie Algorithmen für Regelung und Überwachung. Auf dem Desktop werden das Batteriesystem, die Umgebung und die Algorithmen mithilfe von Verhaltensmodellen simuliert. Die Desktop-Simulation kann verwendet werden, um neue Entwicklungsideen zu untersuchen und mehrere Systemarchitekturen zu testen, bevor man sich auf einen Hardware-Prototypen festlegt. Beispielsweise können Sie Konfigurationen und Algorithmen für aktives und passives Balancing untersuchen, um die Eignung des jeweiligen Ansatzes für eine bestimmte Anwendung zu bewerten.

Modellierung und Kennzeichnung der Batteriezelle

Die Simulationen beginnen mit einem genauen Modell des Batteriepacks, in der Regel ein Ersatzschaltbild zur Simulation des thermoelektrischen Verhaltens der Batteriezelle. Das Ersatzschaltbild besteht typischerweise aus einer Spannungsquelle, einem Reihenwiderstand und einem oder mehreren parallel geschalteten Widerstands-Kondensator-Paaren (Abbildung 2). Die Spannungsquelle liefert die Leerlaufspannung, während die anderen Komponenten den Innenwiderstand und das zeitabhängige Verhalten der Zelle modellieren. Diese Elemente sind temperatur- und SOC-abhängig. Da diese Abhängigkeiten individuell für die Chemie jeder Batterie sind, werden sie anhand von Testdaten ermittelt.

Modellierung der Leistungselektronik und passiver Komponenten

Um zu verstehen, wie das BMS mit wechselnden Betriebsbedingungen umgeht, erfordern Simulationen exakte Modelle der Schaltungskomponenten, die das Batteriesystem mit der Stromquelle und der Last verbinden. Mit der Simulation auf Systemebene kann eine Ladequelle, wie z.B. ein Photovoltaik(PV)-System, um die Batterie herum modelliert und die BMS-Algorithmen für verschiedene Betriebsbereiche und unter verschiedenen Fehlerbedingungen validiert werden. Die Last am Batteriepack kann modelliert und simuliert werden, z.B. einen Synchronmotor (PMSM) in einem Elektrofahrzeug, das eine Reihe von Fahrzyklen durchläuft. Modelle aktiver und passiver elektrischer Komponenten, wie z.B. das analoge Front-End für das Balancing, bilden den Ausgleich eines kompletten Batteriesystems.

Entwicklung von Algorithmen zur Überwachungsregelung

Ingenieure entwickeln Algorithmen zur Überwachungsregelung unter Verwendung von Zustandsautomaten und Flussdiagrammen, um eine kombinatorische und sequenzielle Entscheidungslogik für Fehlererkennung und -management, Lade- und Entladeleistungsbegrenzung, Temperatursteuerung und Balancing zu modellieren. Das BMS überwacht, wie das Batteriesystem auf Ereignisse, zeitbasierte Bedingungen und externe Eingangssignale reagiert. Beispielsweise kann für das Laden mit konstantem Strom und konstanter Spannung (constant current, constant voltage = CCCV) jene Logik entwickelt und getestet werden, die bestimmt, wann die Zelle vom Strom-Lademodus in den Spannungs-Lademodus übergeht.

Schätzung des Ladezustands

Es gibt traditionelle Ansätze zur SOC-Schätzung, wie die Messung der Leerlaufspannung (Open-Circuit Voltage, OCV) und die Stromintegration (Coulomb-Zählung). Die Schätzung des SOC für moderne Batteriechemien mit flachen OCV-SOC-Entlade-Signaturen erfordert einen anderen Ansatz. Die erweiterte Kalman-Filterung (EKF) ist ein solcher Ansatz, der nachweislich genaue Ergebnisse bei angemessenem Rechenaufwand liefert. Diese Technik umfasst normalerweise ein Modell des nichtlinearen Systems von Interesse (die Batterie), das den von der Zelle gemessenen Strom und die Spannung als Eingangsgrößen verwendet, sowie einen rekursiven Algorithmus, der die internen Zustände des Systems (darunter SOC) auf der Grundlage eines zweistufigen Vorhersage-/Aktualisierungsprozesses berechnet.

Schätzung des Alterungszustands

Alle Batterien verschlechtern sich aufgrund der kalendarischen Lebensdauer und der Nutzungszyklen und erleiden einen allmählichen Verlust an Reservekapazität sowie einen Anstieg des Innenwiderstands. Während letzterer relativ einfach anhand von Kurzzeitmessungen abgeschätzt werden kann, erfordert ersterer für eine genaue Berechnung eine vollständige Ladung- oder Entladung, was nicht immer praktikabel ist. Diese Herausforderung hat zu einem wachsenden Interesse an Schätzungen des Alterszustands geführt. Anders als bei der SOC-Schätzung gibt es keine allgemeine Übereinkunft darüber, wie SOH zu definieren ist. Üblicherweise werden benutzerdefinierte SOH-Schätzungsalgorithmen entwickelt und simuliert, die mit der spezifischen Interpretation der Batteriealterung in der anwendenden Organisation übereinstimmen.

Testen mit Desktop-Simulation

Mit der Desktop-Simulation können Testfälle ausgeführt werden, um das BMS entlang aller möglichen Zweige der Logik und des geschlossenen Regelkreises zu erproben – ein Abdeckungsgrad, der beim Testen mit Hardware selten erreicht wird. Wenn das Batteriesystem Sicherheitsanforderungen erfüllen muss, können Anwender auf formalen Methoden basierende Tests in ihren Softwareentwicklungsprozess gemäß Standards wie IEC 61508, IEC 61851 und ISO 26262 integrieren. Bei diesem Ansatz dient das Simulationsmodell als ausführbare Spezifikation, die die Entwicklung und das Testen des BMS steuert (Abbildung 3).

Simulation in Echtzeit: Validierung der BMS-Software

Desktop-Simulationsmodelle können zur Generierung von C- und HDL-Code für Rapid Prototyping (RP) oder Hardware-in-the-Loop (HIL)-Tests verwendet werden, um die BMS-Algorithmen mittels Echtzeitsimulation zu validieren. Ziel ist es, den BMS-Controller mit RP und die Balance des Batteriesystems mit HIL zu emulieren. Mithilfe der Echtzeitsimulation für die BMS-Entwicklung können Ingenieure Folgendes tun:

• RP durchführen, um mit der Validierung der Algorithmen zu beginnen, bevor die endgültige Controller-Hardware ausgewählt wird
• Flexibilität eines Echtzeit-Testsystems für schnelle Entwurfsiteration und Tests nutzen
• HIL-Tests durchführen, bevor die Prototyp-Hardware des Batteriesystems verfügbar ist
• eine Kombination aus RP- und HIL-Tests einsetzen, um BMS-Algorithmen für Testfälle zu erproben, die unter Verwendung der tatsächlichen Hardware schwierig, teuer oder zerstörerisch sein können

Durchführen von Rapid Prototyping

Mit RP wird anstelle von handgeschriebenem Code automatisch Code aus einem Reglermodell generiert und auf einem Echtzeitrechner bereitgestellt, der die Funktionen des Mikrocontrollers ausführt. Mit der automatischen Code-Generierung können Algorithmusänderungen, die im Desktop-Modell vorgenommen und validiert wurden, innerhalb von wenigen Stunden auf Echtzeit-Hardware getestet werden anstatt wie bisher innerhalb von Tagen, die für die Neuprogrammierung von Änderungen am Mikrocontroller erforderlich wären. Darüber hinaus können Anwender mit den meisten Simulationswerkzeugen mit Echtzeit-Regelungshardware interagieren, um Algorithmus-Parameter zu ändern und Testdaten zu protokollieren.

Testen mit Hardware-in-the-Loop

Im Falle von HIL-Tests wird C/C++ und HDL-Code aus den Batteriesystemmodellen und nicht aus den Regelungsmodellen generiert, wodurch eine virtuelle Echtzeitumgebung ermöglicht wird, die Batteriepack, aktive und passive Schaltungselemente, Lasten, Ladegerät und andere Systemkomponenten darstellt. Sobald dieser Code auf einem Echtzeitrechner eingesetzt wird, können Ingenieure Simulationen der Hardware mit ihrem Controller-Code durchführen, bevor sie den Controller in einem Batteriesystem-Prototypen testen (Abbildung 4). Dadurch können sie Fehler in der Entwicklung schon finden und korrigieren, bevor diese möglicherweise teure und schwer zu ersetzende Prototyp-Hardware beschädigen. Sie können auch Hardwaredesignfehler aufdecken, wie z.B. die falsche Dimensionierung von Komponenten. Tests, die während der Desktop-Simulation entwickelt wurden, können in die HIL-Tests übernommen werden, um sicherzustellen, dass die Anforderungen im weiteren Verlauf des BMS-Entwurfs erfüllt werden. Obwohl HIL-Tests in erster Linie zum Testen von Code verwendet werden, der auf einem Mikrocontroller oder FPGA läuft, kann stattdessen ein Rapid-Prototyping-System verwendet werden, das mit dem HIL-Setup verbunden ist, bevor die Serien-Controller-Hardware ausgewählt wird.

Produktionsfertige Code-Generierung

Anwender können die validierten Regelungsalgorithmen als Grundlage für die Generierung von produktionsfertigem Code verwenden – entweder optimierten C/C++ Code für Mikrocontroller oder synthetisierbaren HDL-Code für die FPGA-Programmierung oder ASIC-Implementierung. Die automatische Codegenerierung eliminiert manuelle Übersetzungsfehler der Algorithmen und erzeugt C/C++ und HDL-Code mit numerischer Äquivalenz zu den in ihrer Desktop-Simulation validierten Algorithmen. Indem sie ihre Regelungsalgorithmen über alle möglichen Betriebs- und Fehlerbedingungen simulieren, erhöhen sie die Sicherheit, dass der generierte Code mit denselben Bedingungen im realen System zurechtkommt, auch wenn nicht auf alle Bedingungen getestet werden kann. Falls Hardwaretests später anzeigen, dass Algorithmusänderungen erforderlich sind, können Ingenieure einfach die Algorithmen in ihrem Modell modifizieren, Simulationstestfälle erneut ausführen, um die Richtigkeit der Änderungen zu überprüfen, und neuen, aktualisierten Code generieren (Abbildung 5).

Die Simulation auf Systemebene ermöglicht es Ingenieuren, frühzeitig die Auswirkungen von Entwicklungsfehlern während der Entwicklung von BMS-Software zu reduzieren. Algorithmen für Regelung und Überwachungslogik, wie z.B. für Laden und SOC-Schätzung werden anhand von Batteriemodellen, die die Eigenschaften realer Batterien darstellen, getestet. Fehler können vor dem Testen auf Prototyp-Hardware korrigiert werden. Aus den Simulationsalgorithmen wird Softwarecode für das BMS generiert, der für Echtzeittests und Produktionsimplementierung verwendet wird. Dieser zeitsparende Schritt reduziert die Testverzögerungen für Code-Updates und eliminiert manuelle Codierungsfehler.