Batteriemanagementsystem (BMS)

Begriffe aus einer mit Batterien betriebenen Welt. Früher war es die 1,5 Volt Mignonzelle, die den Walkman betrieben hat, der nur ganz selten das Band der Lieblingskassette verschlungen hat (Kids von heute werden nie verstehen, wieso Kassetten und Bleistifte untrennbar zusammengehörten). Es folgten die ersten Mobiltelefon-Akkus, Lichter für die Fahrradlampe, Spielzeuge, Rauchmelder, und, natürlich, Autobatterien, ohne die das Fahrzeug nicht mal mehr starten mag. Heute sind es ganze Arrays an Batterien, vor allem seit dem Anbruch des Zeitalters der Elektrofahrzeuge, bei denen Batterien bzw. Akkumulatoren eine noch wichtigere Rolle denn je spielen. Die Batteriesysteme in Fahrzeugen müssen gesteuert und geprüft werden, Daten müssen auslesbar sein und für Werkstätten und OEMs verfügbar gemacht werden.

Dies ermöglichen Batteriemanagement-Systeme, mal wie hier getrennt geschrieben, mal in einem Wort („Batteriemanagementsysteme“), mal praktisch mit „BMS“ abgekürzt, worauf auch wir im Lauf des Artikels zurückgreifen werden. Aber was muss so ein „BMS“ denn überhaupt können? Was macht ein solches System zu einem guten System, und was müssen Zulieferer und Knowledge-Partizipanten wissen und können, um starke BMS für OEMs zu entwickeln?

Einen Überblick gibt dieser Artikel, bei dessen Lektüre wir nun viel Spaß wünschen.

Die Einleitung nimmt es sicherlich schon ein Stück weit vorweg: Ein Batteriemanagementsystem muss, hence the name, die Batterie managen. Das ist indes komplexer, als es zunächst klingen mag; schließlich müssen sehr viele verschiedene Zustände ausgelesen werden. Wir konzentrieren uns hierbei nur bedingt auf die technische Komponente, auf die zahlreichen zu bedenkenden Aspekte in Sachen technischer Voraussetzung, Sensoren, Bus-Systeme zum Auslesen der Daten und vielem mehr – dies zu berücksichtigen, ist Aufgabe des Requirements Engineerings, dem eine gesonderte Rolle in der Entwicklung zukommt, die wir im Verlauf noch aufgreifen werden.

Ein Batteriemanagementsystem überwacht viele Standardfunktionen, wie die Temperatur der Batterie, den Ladestand oder die Anzahl der Ladezyklen und deren benötigte Zeit. Es muss indes auch bestimmte Funktionen ausführen oder zumindest delegieren können: Was geschieht, wenn die Batterie eine kritische Temperatur überschreitet? Wird ein Signal ausgelöst? Von welchem Sensor, und an welches Steuergerät übermittelt der Sensor die Daten, und was fängt das Steuergerät damit an? Wohin sendet es sein Notfall-Signal, und was geschieht dann? Wie lässt sich dies testen, und muss dies schon in der Entwicklung berücksichtigt werden? (Spoiler: Gute Entwicklung berücksichtigt schon links oben im V-Modell Testszenarien.) Auch das Verhindern von Über- oder Unterladung der Batterie gehört zu den Aufgaben eines BMS. Eine unkontrollierter Überladungsvorgang könnte im schlimmsten Fall zur Explosion der Batterie führen, eine ständige Tiefenentladung die Batterie ebenfalls zerstören, da Akkus grundsätzlich keinen unter die letzten Prozent der Batteriekapazität fallenden Ladestand erreichen sollten – indes, dies ist nur ein Beispiel aus dem großem Sammelsurium der Aufgaben eines BMS. Es benötigt Kommunikationsschnittstellen, muss Parameter berechnen und vieles mehr. Welche Anforderungen genau an ein BMS zu stellen sind, gibt in aller Regel der OEM vor, vor allem, wenn dieser kein eigenes Komplettsystem aus Batterie und BMS hat, sondern lediglich eine bestehende Batterie-Struktur, in deren Rahmen möglichst viele Batterien im Unterboden des Fahrzeugs verbaut wurden. Hierfür ein BMS zu entwickeln, ist eine typische Aufgabe für Tier-1-Zulieferer wie beispielsweise die Cognizant Mobility. Natürlich gibt es auch andere Anbieter von Batteriemanagementsystemen wie Victron, Infineon, Marquardt und einige mehr. Die Cognizant Mobility stellte uns allerdings einige Experten zur Seite, mit denen wir abklopfen durften, was genau ein gutes Batteriemanagementsystem ausmacht und welche Entwicklungsschritte hierfür besonders wichtig sind, um starke und innovative Arbeit abzuliefern.

Die Frage, was letztlich ein gutes BMS definiert, mag von Hersteller zu Hersteller und von Entwickler zu  Entwickler unterschiedlich ausfallen. Aus Sicht der Cognizant Mobility sind indes Modularität und Skalierbarkeit entscheidende Faktoren, um kundenorientiert und vor allem effizient an modernen BMS zu arbeiten. Die meisten Tier 1 OEMs haben feste Plattformstrategien – ein Beispiel wären große Unternehmen wie Bosch oder Infineon. Dies hat auch seine Berechtigung. Aber wer ist der Kunde? Ist der Kunde ein namhafter Fabrikant wie Audi, BMW oder Mercedes, haben auch diese ihre eigenen Plattformstrategien, die nicht für Zulieferer angepasst werden. Stattdessen besteht bereits ein Plan, wie Batterien in Fahrzeuge integriert werden sollen. Aufgabe des Zulieferers ist eine softe Aufstellung, in deren Rahmen das vorgegebene – und in der Regel nicht veränderliche – Lastenheft des Auftraggebers abgearbeitet wird.

Um dies zeit- und kostensparend für den Kunden umsetzen zu können, ist eine hohe Modularität erforderlich, die eine schnelle und effektive Anpassung auf den Kundenwunsch zulässt. Dies betrifft sowohl die Software – eine der Kernkompetenzen der Cognizant Mobility – als auch Hardware und die Steuergeräte-Ebene. Lässt sich schnell und unkompliziert umsetzen, was auf Kundenseite gewünscht ist, ermöglicht dies eine erste Wertschöpfung.

Hierbei zu unterscheiden – auch wenn wir Hardware und Software mitunter in einem Zug nennen – ist dennoch die eigentliche Hochvoltbatterie als Produkt, und das reine Batteriemanagementsystem. Oft geben Hersteller die Fertigung der Batterie an ein eigenes Subunternehmen aus, während für das BMS andere Zulieferer mit entsprechenden Kompetenzen beauftragt werden. Das ist nicht immer und überall so, das genannte Beispiel ist indes ein durchaus exemplarisches.

Natürlich gibt es auch andere Modelle, wie eingangs angedeutet: Manche Feldhersteller haben bereits ein Package Modell, in dessen Rahmen das Fahrzeug mit der gewünschten Anzahl an Batterien bestückt wird, für das es aber kein Managementsystem gibt. Hier kommen Software- und Knowledge-Zulieferer ins Spiel, die die Entwicklung der Systeme übernehmen. Diese müssen sich entsprechend nicht nur mit der reinen Software-Entwicklung auskennen, sondern idealerweise auch Kenntnisse über Zellphysik und Ladetechnik besitzen. Schließlich sollte bekannt sein, wie ein BMS reagieren muss, wenn eine Batterie mit über 200 kW zwangsgeladen wird. Steigt deren Temperatur in der Folge auf 300 Grad, können die Folgen verheerend sein. Auch zu wissen, wie ein Algorithmus zur Lade- und Entladetechnik programmiert werden muss, ist essenziell, immerhin entlädt man eine Batterie – auch dies haben wir schon angedeutet – nicht auf null Prozent, da diese sonst schlicht kaputt geht.

All diese Aspekte, gemeinsam mit Modularität und flexibler Skalierbarkeit, sind Kernelemente eines guten Batteriemanagementsystems, natürlich gepaart mit ausgiebigem Wissen über Anforderungsmanagement und Wissen auf Programmierebene. Sehen wir uns das doch auch einmal genauer an.

Ganz ehrlich? Wir könnten es uns an dieser Stelle sehr einfach machen und aussagen, dass gute Kenntnisse in der Embedded Systems Entwicklung wichtig sind, und das Kapitel schließen. Es wäre nämlich wahr – nur eben nicht der Detailblick, den wir bei den Mobility Rockstars gerne bieten möchten. Gehen wir also etwas mehr in die Tiefe und sehen uns die vier Säulen an, auf denen – jenseits des Testings – die Entwicklung eines starken BMS beruht.

Funktionale Sicherheit (branchenintern gerne salopp mit „FuSi“ abgekürzt) ist ein elementarer Baustein, der bereits zu Beginn des V-Modells berücksichtigt werden muss. Schließlich ist Sicherheit unerlässlich. Über die generelle Bedeutung Funktionaler Sicherheit und deren Wichtigkeit haben wir bereits einen Artikel gemeinsam mit der betreffenden Fachabteilung verfasst, den findet ihr bei Interesse unter diesem Link.

FuSi muss also schon zu Beginn im Requirements Engineering berücksichtigt werden, wofür es wichtig ist, das Fahrzeug nicht nur auf die Batterie zu reduzieren, sondern in seiner Gesamtheit wahrzunehmen. Es gilt beispielsweise abzuwägen, welche Kontrollsysteme redundant implementiert werden oder anderweitig umgesetzt werden sollen. Werden hierzu früh sinnvolle Konzepte erstellt, kann dies den Aufwand und in direkter Folge auch die Kosten erheblich minimieren. Speziell Funktionale Sicherheit und das Anforderungsmanagement sind daher immens wichtige Kompetenzen in der Entwicklung von Batteriemanagementsystemen. Fast schon von selbst versteht sich die Entwicklung nach Automotive Spice, einem State-of-the-Art-Standard in der Embedded Entwicklung zur Bewertung der Prozessreife, nach denen Zulieferer in der Regel auch auditiert werden – bedeutet, dass OEMs Audits bei Zulieferern abhalten, in deren Rahmen alle Fragen rund um die Entwicklung und Implementierung beantwortet werden können müssen. Dabei geht es oft gar nicht im Detail um das „wie“, sondern das „was“: Der Automotive Spice (ASPICE) Standard sagt aus, was getan werden muss, und der Zulieferer muss im Rahmen des ASPICE Audits darlegen, wie er es umsetzt.

Für jedes große Projekt, nicht nur in der Entwicklung von Batteriemanagementsystemen, ist ein ausführliches Anforderungsmanagement eine Schlüsselkompetenz. Hierbei gilt noch zu unterscheiden zwischen Requirements Engineering und Requirements Management – zwei verschiedene Aufgaben, die im deutschsprachigen Begriff des „Anforderungsmanagements“ enthalten sind und dort keine weitere Unterscheidung erfahren.

Das Requirements Management präsentiert sich vornehmlich als administrative Aufgabe, die sich mit der Verwaltung von Kundenanforderungen befasst, diese für andere Rollen im Projekt bereitstellt und sich mit der Baseline-Erstellung befasst. Im Requirements Engineering geht es sowohl grundsätzlich als auch in diesem spezifischen Projektfall um die Erstellung aller für das Projekt relevanter Anforderungen - in diesem Fall für Batteriemanagementsysteme: Welche Module, welche Signale, welche Algorithmen sollen für bestimmte Funktionen verwendet werden. Gutes Anforderungsmanagement macht hierbei vor allem aus, besonders feingranular zu arbeiten und Anforderungen aufzuteilen: Nur so viele Anforderungen, wie unbedingt nötig, diese aber so granular, dass kein Interpretationsspielraum für die nächsten Schritte und Stakeholder besteht. Selbst das spätere Testing wird idealerweise schon zu Beginn berücksichtigt. Ein Beispiel wäre also die Batterie, und hier speziell die Temperatur, die vom BMS gemessen werden soll. Klingt nach einer simplen Anforderung, aber es steckt mehr dahinter – wie wird die Temperatur denn gemessen? Von welchen Sensoren? Ist genug Platz auf der Platine, sind alle Bauteile vorhanden, um die Funktionen auszuführen? Welche Bauteile genau? Welche Funktionen speziell, damit alle Signale von der Software interpretiert werden können, und wie und in welcher Form soll die Interpretation ausgegeben werden? Wohin? In jedem Fall, oder wird ein Signal, dass eine Standardfunktion wiedergibt, anders gewertet als ein Notfall-Signal?

Um dies effektiv und kompetent in das Anforderungsmanagement zu implementieren, sind Erfahrung und Kommunikation unbedingt erforderliche Kompetenzen. Gespräche auf wiederkehrender Basis mit Product und Function Ownern, mit Testern, mit Scrum-Teams – sie alle sollten bei entsprechenden Reviews beteiligt sein, um dem Kunden ein optimales Projekt und letztendlich Produkt anbieten zu können.

Auf diesen Punkt gehen wir ehr der Vollständigkeit halber ein. Selbstverständlich handelt es sich um einen essenziell wichtigen Aspekt in Sachen Knowhow und Kompetenz, der aber eher die generelle Fähigkeit zur Embedded Systems Entwicklung beschreibt. Sicher, ein BMS hat spezielle Anforderungen: Es gibt einen sehr hohen Anteil an Complex Device Drivers, die direkt an Hardwareschnittstellen andocken können, es bestehen viele Spezialanschlüsse. Direkte Mess-Pins müssen beispielsweise nach speziellen Anforderungen der Batterien-Hardware entwickelt werden.

Nachdem die Basis-Software-Entwickler (Stichwort Classic Autosar Standard, mehr dazu in diesem Artikel), vereinfacht gesagt, das „Betriebssystem“ entwickeln, auf dem im weiteren Verlauf die Anwendungssoftware aufsetzt, können die Funktionen im V-Modell angegangen werden (Beispiel für ein V-Modell: https://evav.omnex.com/7-levers/automotive-spice ). Funktionen wie der Ladestand, Wartungsaufforderungen und vieles mehr – die Beispiele kennt ihr ja inzwischen. Funktionen werden beispielsweise mit Matlab Simulink geschrieben, das als eines der wichtigsten Tools überhaupt in der Funktionsentwicklung gilt. In diesem Rahmen werden Funktionen grafisch modelliert, woraus automatisiert Code erzeugt wird. Dies wird unter dem Begriff der modellgetriebenen Software-Entwicklung zusammengefasst, in aller Regel mit „MDSD“ abgekürzt.

Fast unnötig zu erwähnen, dass die Stärke eines Zulieferers im Bereich der Entwicklungsebene vor allem in Expertise besteht, in Projekterfahrung und in einem sauberen Ineinandergreifen des Anforderungsmanagements, der Funktionalen Sicherheit sowie der Basis- und Anwendungssoftware-Entwicklung.

Was bleibt final zu sagen in einem ausführlichen Fachartikel, der alle relevanten Punkte abdeckt? Vielleicht, dass Batteriemanagementsysteme komplexe Produkte sind, die in einem hochdynamischen Projektumfeld eine Vielzahl an Skills abrufen, um korrekt entwickelt zu werden. Während es in diesem Bereich sicherlich zahlreiche Unternehmen gibt, die eine entsprechende Entwicklung anbieten, teils autonom, teil als Teil anderer Zulieferer („Bodyleasing“), gibt es dennoch große Unterschiede in der Effizienz, die sich für Kunden nicht nur in Produktzufriedenheit, sondern auch erspartem Aufwand und Kosteneinsatz widerspiegelt. Insbesondere das Anforderungsmanagement ist ein immens wichtiger Punkt, dem nicht unter allen Umständen angemessene Aufmerksamkeit zuteil wird, ebenso wie die frühe Einbindung Funktionaler Sicherheit und einer granularen Aufteilung aller Tasks, die schon von Beginn an Eventualitäten, wechselnde Anforderungen und Tasks bis hin zum Testing berücksichtigt.

Unbedingt relevant, um diesen Anforderungen gerecht zu werden, ist die Offenheit gegenüber sämtlichen technologischen Lösungsansätzen. Es gilt, sich vom Gros des Mindsets mancher Zulieferer zu lösen, die viel daran setzen, Kunden in ein eigenes System zu lotsen und einen durchaus beabsichtigten Lock-In-Effekt zu erzeugen, wie dieser von unbedachten Cloud-Migrationen bekannt ist. Ein Batteriemanagementsystem sollte sich also in der Entwicklung an den Kunden anpassen, und nicht der Kunde an die Systeme des Zulieferers – vor dem Hintergrund der ISO21434 ein überaus wichtiger Punkt, der sogar an Zulassungsrelevanz gewonnen hat.

Natürlich bedeutet dies auch, dass sich Entwickler schnell an neue Technologien gewöhnen sollten – gerade in der derzeit herrschenden Materialknappheit können sich Hardware Stacks ändern, Zelltechnologien folgen. Mit einem flexiblen Baukasten können Zulieferer wie die Cognizant Mobility schnell reagieren, Stichwort Parametrierbarkeit: Nicht immer muss für jeden Kunden eine neue Lösung erfunden werden, aber Anpassung und Flexibilität sind elementar. Der Code, in dem die letztliche Wahrheit liegt, muss nicht neu geschrieben werden, aber erweiterbar bleiben, um die propagierte Technologieoffenheit auch zu leben. Und dies gilt im sprichwörtlichen wie übertragenen Sinne – das Rad dreht sich, und wir mit ihm.

Kommt also gerne auf uns zu, wenn ihr euch als Auftraggeber im Bereich BMS aufgestellt habt und nun echtes, flexibles und effizientes Entwicklungspotential sucht – wir unterhalten uns gerne unkompliziert und geben eine erste, unverbindliche Einschätzung ab.

Aber auch für alle anderen Leser ist die Reise hier noch nicht zu Ende, denn wir haben noch weitere tolle Links für euch, nämlich hier, hier oder hier, oder ihr scrollt noch ein Stück weiter und lest euch noch einen weiteren, spannenden Tech-Artikel zur Mobilität von Morgen durch.

Danke für die Aufmerksamkeit.