Von der Idee zur Innovation
Batterie-Managementsysteme (BMS) mit Model-Based Design
BMS sind essenziell für sichere, langlebige und effiziente Batterien in Elektrofahrzeugen. NXP bietet mit der Model-Based Design Toolbox (MBDT) einen Ansatz zur Entwicklung und Validierung von BMS nach ISO 26262 ASIL D. Darüber hinaus ermöglicht eine Cloud-Anbindung Over-the-Air-Updates.
Batterieelektrische Fahrzeuge (BEVs) leisten einen wichtigen Beitrag für einen sauberen, kohlenstoffneutralen und nachhaltigen Verkehr. Kunden erwarten, dass die Batterien ihrer Fahrzeuge zuverlässig, effizient, langlebig und sicher sind. Das hierfür verantwortliche Steuergerät ist das Batteriemanagementsystem (BMS). Aufgabe des BMS ist es, den Betrieb der Batterie zu überwachen, ihre Leistung zu optimieren, Ungleichgewichte zwischen einzelnen Zellen auszugleichen, vorzeitige Alterung zu verhindern und einen sicheren Betrieb zu gewährleisten. Automobilhersteller und -zulieferer müssen solche BMS effektiv mit Workflows entwickeln, testen, validieren und zertifizieren, die Normen wie ISO 26262 und insbesondere die darin enthaltenen, höchsten Anforderungen gemäß ASIL D erfüllen.
Die etablierte Lösung für die Entwicklung von Steuergeräten und Software in der Automobilindustrie ist das Model-Based Design (MBD). Während dieses gesamten Entwicklungsprozesses dienen Software- und Systemmodelle als ausführbare Spezifikationen, welche die Entwicklung, Verfeinerung und Optimierung sowie das Testen und die Verifikation von Hardware und Software ermöglichen. Diese Modelle bilden einen intuitiven digitalen Faden und können später wiederverwendet werden, um Systeme anzupassen und weiterzuentwickeln. Sie dienen aber auch als digitale Zwillinge für die Pflege und Überwachung von Systemen sowie die Reaktion auf Störfälle.
NXP entwickelt als Halbleiterunternehmen Prozessoren/Controller für den Automobilbereich. Zur Bewältigung aktueller Herausforderungen beim Entwurf eingebetteter Systeme, wie Motorsteuerungen oder BMS, bietet NXP die Model-Based Design Toolbox (MBDT) an, eine Sammlung von Werkzeugen, die das MathWorks-Ökosystem MATLAB und Simulink mit den Prozessorfamilien von NXP verbindet (Abbildung 1). Die Toolbox integriert den modellbasierten Systementwurf, die Hardware-Implementierung und die Validierung in einer durchgängigen Toolkette.
Jobangebote+ passend zum Thema
Die MBDT ist eine Sammlung von Tools und Bibliotheken, die die Algorithmen-Entwicklung in MATLAB und Simulink beschleunigen und das nachfolgende Prototyping auf NXP-Mikrocontrollern und -Prozessoren unterstützen. Die Toolbox ermöglicht die Konfiguration, Generierung und Bereitstellung von Anwendungen auf NXP-Prozessoren und erlaubt die Verwendung externer Konfigurationstools für Pins, Taktgeber und Peripheriegeräte, darunter etwa die S32 Configuration Tools von NXP.
Darüber hinaus generiert die MBDT Code auf Basis der Echtzeittreiber (RTD) von NXP für Autosar- und Nicht-Autosar-Anwendungen mit dem Embedded Coder. So ermöglicht sie Model-in-the-Loop- (MIL) und Software-in-the-Loop- (SIL) -Tests auf dem Desktop, aber auch die Verifikation und Validierung auf Hardware mit Processor-in-the-Loop- (PIL) und Hardware-in-the-Loop- (HIL)-Methoden. Die MBDT unterstützt zudem Autosar Adaptive für den Übergang zu serviceorientierten Architekturen. Zum Lieferumgang gehören zahlreiche Beispiele, die sowohl zu Lernzwecken als auch als Ausgangspunkt für eigene Implementierungen genutzt werden können.
Die Hardware
NXP bietet ein vollständig analysiertes und dokumentiertes Referenzdesign für die Entwicklung von Hochspannungs-Batteriemanagementsystemen (HVBMS) an, das auch die ISO 26262 ASIL D erfüllt. Das Referenzdesign umfasst eine komplette Hardware-Lösung für Tests, Implementierung und Prototyping (Abbildung 2). Es basiert auf einer S32K3 MCU und dem im File Exchange zu findenden MathWorks-BMS-Modell für den Entwurf und das Testen von Lithium-Ionen-Batterien. Damit vereinfacht, entlastet und beschleunigt es die Integration von HVBMS-Software und -Hardware in Automobilsystemen.
Das Hardwarepaket besteht aus drei Steuerplatinen: der Battery Management Unit (BMU), der Cell Management Unit (CMU) und der Battery Junction Box (BJB). Die BMU verarbeitet Daten von allen anderen BMS-Modulen, gibt Befehle für das Cell Balancing und trifft Entscheidungen zur Gewährleistung der Sicherheit. Die BMU kommuniziert mit dem Fahrzeugrechner (Vehicle Control Unit, VCU) und steuert die Schützschalter, die die Batterie mit den Wechselrichtern und Motoren oder dem Ladegerät verbinden.
Die CMU misst Zellspannungen, Temperaturen und Ströme und gleicht Zellungleichgewichte mit einem Strom von bis zu 300 mA aus. Die Batteriezellen-Controller (BCCs) der CMU sind seriell als Daisy Chain verbunden und ermöglichen die Erweiterung des Systems um weitere Batterien, indem zusätzliche Einheiten angeschlossen werden können.
Die BJB misst verschiedene Hochspannungen über das gesamte BMS sowie genau und redundant den Systemstrom und überwacht aus Sicherheitsgründen den Isolationswiderstand zwischen Batterie und Chassis. Zur Kommunikation mit der BMU nutzt sie das isolierte Electrical Transport Protocol Link (ETPL) oder CAN.
Der Workflow
Der mit der MBDT, dem Hardware-Referenzdesign und MathWorks-Tools erstellte Workflow bietet eine integrierte Lösung von den Anforderungen bis zur abschließenden Implementierung (Abbildung 3).
a) Model-in-the-Loop
In diesem Schritt wird das BMS anhand der Software-Anforderungen mit Simulink entworfen und in seine Komponenten zerlegt. Das oben erwähnte Beispiels-BMS kann als Ausgangspunkt für die Entwicklung von BMS-Algorithmen in Simulink verwendet werden. Die Entwicklung erfolgt auf Grundlage eines Batteriemodells, das von einem einfachen Ersatzschaltbild bis hin zur vollständig parametrisierten Darstellung eines bestimmten physischen Batterietyps reichen kann.
In dieser Phase wird die allgemeine Steuerungsstrategie der Anwendung festgelegt und anhand der Testfälle validiert, um die Anforderungen zu erfüllen. Mit dem Simulink Data Inspector lassen sich alle relevanten Parameter auf ihre erwarteten Werte hin überprüfen. Durch frühzeitiges Testen wird sichergestellt, dass Entwurfsfehler nicht in Phasen weitergetragen werden, in denen ihre Behebung mehr Aufwand und Nacharbeit erfordert.
b) Software-in-the-Loop
Sobald der anfängliche Entwurf die Anforderungen erfüllt und sich wie gewünscht verhält, wird zum ersten Mal ein Steuerungs-Code generiert. Embedded Coder generiert C-Code aus dem BMS-Modell, der dann zu einer Objektdatei kompiliert, auf dem Desktop ausgeführt und mit dem Batteriemodell verglichen wird (Abbildung 4).
In diesem Schritt wird geprüft, ob das Modell prinzipiell in C-Code umgewandelt werden kann, und die Ingenieure können erforderliche Änderungen vornehmen. Außerdem wird verifiziert, dass sich der C-Code genauso verhält wie das Simulink-Modell. Danach lassen sich erste Daten zum Ausführungsprofil sammeln.
c) Processor-in-the-Loop
Als Nächstes wird erneut C-Code aus dem BMS-Modell generiert, dieses Mal aber cross-kompiliert. Die MBDT lädt den Code auf die MCU herunter und führt ihn über die Registerkarte SIL/PIL in Simulink automatisch gegen das Batteriemodell aus. Der Code kann auf unterschiedlichen Mikrocontrollern ausgeführt werden, um die leistungsfähigste Architektur für das endgültige Design auszuwählen.
Mit dem Simulink Data Inspector lassen sich die Ergebnisse nun visualisieren und mit denen der SIL-Tests vergleichen, um den Algorithmus auf dem Prozessor zu verifizieren. Code-Profiling-Daten zeigen die Ausführungszeit sowie die Speicher- und Stack-Nutzung an und stellen so sicher, dass der Prozessor den Controller-Code verarbeiten kann oder ob leistungsfähigere Hardware in Betracht gezogen werden sollte.
Bis hierhin ist weder eine physische Batterie noch ein Batterieemulator erforderlich. Die Ingenieure können daher den Algorithmus gegen ein virtuelles Batteriepaket entwerfen, das plausible Daten entsprechend dem Verwendungszweck und den Spezifikationen liefert. Dies beschleunigt die Entwicklung und vermeidet lange Iterationszyklen. Durch das Testen an einem Batteriemodell werden außerdem Gefahren vermieden, die beim Testen eines neuen Steuerungsalgorithmus auftreten können, etwa ein Feuerausbruch oder andere kostspielige Schäden an einem Batteriestapel jener Größe, die zum Antrieb eines Fahrzeugs erforderlich wäre.
d) Hardware-in-the-Loop (HIL)
In der letzten Testphase wird der BMS-Algorithmus auf dem Prozessor in Echtzeit ausgeführt. In diesem Schritt fügt man die MBDT-Blöcke hinzu, um die Anwendung auf eine spezifische Hardware anzupassen. Dann speist man den entworfenen BMS-Algorithmus mit Signalen vom analogen BMS-Frontend und führt den generierten C-Code der eingebetteten Anwendung aus – entweder gegen ein auf Echtzeit-Hardware ausgeführtes Batteriemodell (etwa auf einem Speedgoat-Rechner) oder gegen einen Batterieemulator. Auf diese Weise können Ingenieure das BMS-Design unter sicheren Bedingungen testen, ohne eine echte Batterieanlage zu beschädigen und Gefahren zu verursachen.
Zweck dieses Schritts ist es, den endgültigen BMS-Entwurf in Echtzeit zu validieren, um sicherzustellen, dass er in einem realen Szenario die gleichen Ergebnisse liefert wie in den vorherigen Schritten. HIL dient insbesondere dazu, Probleme im Zusammenhang mit den physikalischen Kommunikationskanälen und E/A-Schnittstellen, wie Dämpfung oder Verzögerungen, zu erkennen und festzustellen, ob diese die Leistung des Controllers und seine Fähigkeit zur sicheren Steuerung des BMS beeinträchtigen.
e) Prototyping
Dieser letzte Schritt wird typischerweise mit einer echten Batterie durchgeführt. Um das Prototyping zu erleichtern, das mit einem erheblichen Zeit- und Kostenaufwand verbunden sein kann, bietet NXP Batteriezellen-Emulatoren zusammen mit den Hardware-Referenzdesigns im Paket an. Dies ermöglicht das Testen unter zahlreichen Betriebs- und Fehlerbedingungen, wie Unter- oder Überspannung. Darüber hinaus bietet das NXP-Evaluierungsboard die Möglichkeit, Sensoren – wie etwa einen Drucksensor – anzuschließen, um ein thermisches Durchgehen zu erkennen, das den Druck im Inneren der Box erhöhen könnte.
Der vollständige Aufbau ist in Abbildung 5 dargestellt. Er umfasst das HVBMS-Referenzdesign (unten Mitte) und kann mit NXP FreeMASTER (oben Mitte) als Edge-Gerät zur Überwachung und Stromanpassung oder mit der Vehicle Network Toolbox über CAN (unten rechts) verbunden werden. Eine NXP S32G GoldBox wird dem Basis-Hardware-Referenzdesign hinzugefügt und über CAN angeschlossen, um entweder auf die MathWorks Cloud Services (unten links) oder die AWSCloud Services (oben links) zuzugreifen.
Indem der Strom durch das Batteriepaket oder die Temperatur mithilfe des FreeMASTER sowie über die Schieber der Potentiometer am Batteriezellen-Emulator (oberhalb von »CAN«) eingestellt werden, können Ingenieure Zellungleichgewichte, Über- und Unterspannungen sowie Über- und Unterströme simulieren. Die Ergebnisse lassen sich sofort überprüfen. Auf diese Weise kann das HVBMS feinabgestimmt werden, ohne teure Geräte oder Batterieprototypen zu riskieren.
Das Herzstück: Schätzung des Ladezustands (State-of-Charge, SoC)
Eine der schwierigsten Aufgaben für ein BMS ist die Bestimmung des Ladezustands eines Batteriestapels. Der SoC (State-of-Charge) kann nicht direkt gemessen werden, da die Spannung einer Batterie eine Funktion der Ladung, der Temperatur sowie des Zustands oder des Alters der Batterie ist. Es erscheint zwar einfach, eine Batterie mit einem bestimmten SoC zu nehmen und immer wieder über die erfassten Lade- und Entladeströme zu integrieren (Coulomb-Zählung), doch ist das über eine längere Lebensdauer der Batterie nicht möglich. Ungenauigkeiten bei der Strommessung, die durch die Alterung der Batterie und die Umgebungsbedingungen verursacht werden, summieren sich zwangsläufig und führen zu Unsicherheiten, einer verringerten Lebensdauer und Effizienz sowie potenziell zu Gefährdungen. Für ein System mit hoher Integritätsanforderung ist dies inakzeptabel.
Die übliche Methode zur Schätzung des SoC ist die Verwendung eines erweiterten Kalman-Filters (EKF), der den SoC anhand von Batteriemessungen von Strömen, Spannung und Temperatur kontinuierlich vorhersagt. Diese rekursive SoC-Schätzung erfordert ein exaktes, dynamisches Zellmodell, das auch die Betriebs- und Umgebungsbedingungen einbezieht. Sie ist ressourcenintensiv, erhöht die Prozessorlast und die Anforderungen und muss für jeden neuen Zellentyp parametrisiert werden.
Ein alternativer Weg zur SoC-Schätzung ist die Verwendung eines neuronalen Netzes (NN) mit Deep Learning. Der hierzu eingesetzte Algorithmus muss mit genügend experimentellen Daten für Ströme, Spannungen und Temperaturen trainiert werden, die unter einem breiten Spektrum von Bedingungen gesammelt wurden.
MATLAB bietet verschiedene Optionen für die Implementierung neuronaler Netze für Machine Learning und Deep Learning sowie für deren Import und Export mit gängigen Tools wie Keras, TensorFlow und Caffe oder im ONNX-Format (Abbildung 6). Experten für NNs können ihre Arbeit mit Ingenieuren teilen, die besser mit MATLAB vertraut sind, sodass diese die Netze in Modelle integrieren, aber auch neu trainieren oder durch Reinforcement Learning verbessern können.
Carlos Vidal und Phillip Kollmeyer, Experten des McMaster Automotive Resource Centre in Hamilton, Ontario, haben gezeigt, dass ein solcher Algorithmus den SoC genau vorhersagen kann, ressourceneffizienter ist als ein Kalman-Filter und sich mit wenigen Änderungen an verschiedene Zelltypen anpassen lässt. Das Implementieren des Algorithmus erfordert nur 55 Neuronen. Die Grundlagen der Entwicklung und des Einsatzes dieses Algorithmus werden in zwei MathWorks-Webinaren beschrieben. Die im Rahmen des Projekts gesammelten Trainingsdaten sind online für die Öffentlichkeit zugänglich.
Das hier vorgestellte HVBMS-Modell enthält zu Demonstrationszwecken sowohl den EKF als auch den NN-Algorithmus. In Abbildung 7 sind beide Teilsysteme rot hervorgehoben. Die Simulationsergebnisse für beide Implementierungen sind in Abbildungen 4 dargestellt, und sowohl das NN (blaue Linie im Bereich rechts) als auch der EKF (orangefarbene Linie) stimmen mit dem echten SoC (gelbe Linie) überein, wie die Simulationsergebnisse zeigen. Das NN ist jedoch, wie oben beschrieben, die effizientere Implementierung.
Verwendung von Cloud-Diensten mit CAN-Nachrichten
Eine Option für den beschriebenen Workflow zur Erstellung eines digitalen Zwillings des BMS-Systems (Abbildung 5) besteht darin, die BMS-Lösung an ein Gateway-Gerät (etwa eine NXP GoldBox auf Basis des S32G-Prozessors) anzuschließen, dass das System mit der Cloud verbindet. Die über den CAN-Bus zwischen dem HVBMS und dem S32G (NXP-Automobilnetzwerk-Prozessor) ausgetauschten Daten werden mithilfe von AWS IoT FleetWise effizient gesammelt und in der Cloud organisiert.
Im Gegensatz zu den gezeigten Beispielen, die sich auf ein einzelnes Gerät konzentrieren, lässt sich dieser Dienst auf eine ganze Fahrzeugflotte ausweiten. Datenerfassungskampagnen für eine solche Flotte können über die AWS-Weboberfläche bereitgestellt werden. Der IoT FleetWise-Edge-Agent, der auf der GoldBox läuft, beginnt dann, diese Sensordaten an den Cloud-Dienst zu senden, der die Werte im AWS Timestream speichert. Zu diesem Zweck werden das Fahrzeug und seine Sensoren in der Cloud modelliert und das Schema der Datenerfassung definiert. Von der Timestream-Datenbank werden die Daten dann zur Verarbeitung in das MathWorks Cloud Center geladen.
Eine Möglichkeit, solche Daten zu nutzen, besteht darin, den für die SoC-Schätzung oder einen anderen Teil der Software verwendeten NN-Algorithmus durch das Sammeln von Flottendaten zu verbessern. Insbesondere Deep-Learning- und Machine-Learning-Anwendungen werden von diesem Ansatz profitieren. Eine weitere Möglichkeit besteht darin, die Daten für die Reaktion auf Störfälle zu nutzen. Wenn ein oder mehrere Fahrzeuge unerwünschte Verhaltensweisen oder Fehler zeigen, lassen sich diese mithilfe digitaler Zwillinge des Fahrzeugs oder des betroffenen Systems analysieren.
Durch eine Rekonstruktion der Bedingungen, unter denen der Fehler auftrat, und eine Simulation der jeweiligen Modelle lässt sich feststellen, ob es sich um ein generelles Problem oder einen Einzelfall handelt. In beiden Fällen besteht eine mögliche Lösung darin, ein Over-the-Air-Update (OTA) für das betroffene Fahrzeug oder auch mehrere bereitzustellen. Zusätzlich lassen sich Felddaten für die Erhaltung des State-of-Health der gesamten Flotte nutzen, indem der Kapazitätsverlust von Batterien ausgewertet und bessere Strategien für das Cell Balancing oder ein verbessertes Ladeverhalten entwickelt werden.
Um ein Software-System eines Fahrzeugs, das bereits auf der Straße eingesetzt wird, zu verbessern, müssen Ingenieure die im Betrieb gesammelten Daten in ihre Entwicklungsmodelle zurückführen, die Modelle als digitale Zwillinge nutzen und den in diesem Artikel beschriebenen Workflow erneut durchlaufen. Die Effizienz dieser Arbeitsweise lässt sich steigern, indem so viel wie möglich von diesem Prozess automatisiert wird, etwa die Datenanalyse, die Ausführung von Testfällen und der Build-Prozess. Cloud-Dienste sind ein wichtiges Werkzeug für Automobilhersteller bei der Einführung von DevOps für SDVs, beim Übergang zur Software Factory für Fahrzeuge mit serviceorientierten Architekturen, und schließlich für das autonome Fahren.
All diese Aktivitäten können dazu beitragen, in der Automobilindustrie den Wandel von der klassischen Software-Entwicklung zu agileren oder DevOps-Ansätzen zu erreichen. Am Ende wird dies die Entwicklung von Software-definierten Fahrzeugen (SDV) vorantreiben – ein Automobil mit Funktionen, die in erster Linie durch Software definiert sind und ständig aktualisiert, optimiert und personalisiert werden können.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
vCharM von Vector
Einfache und schnelle Integration von Ladesäulen
Zusammenarbeit von MathWorks und NXP
Model-Based Design Toolbox für Batteriemanagementsysteme
Was ist TinyML, und was kann es?
MathWorks: »TinyML bringt KI an die Edge«
Für die Hexagon-NPU von Qualcomm
Neues Hardware Support Package von MathWorks
