Batterie-Management mit SignalRC

Heute rücken wir mal einen Schritt näher an die Hardware: Für den DDC-Truck, den wir im Artikel „SignalRC – in Echtzeit ans Steuer“ [1] ausführlich vorgestellt haben, möchte ich das Thema Batterie-Management anschneiden. Es soll auch gleichzeitig stellvertretend für jegliche Telemetrie als Beispiel dienen. Denn die Telemetrie des BMS ist mit Abstand die wichtigste im gesamten Projekt.

BMS – was ist das?

Das Batterie-Management-System (BMS) sorgt für die Überwachung, die Regelung und den Schutz der Batterie. Es muss folgende Funktionen haben:

• Spannungsmessung auf allen Zellen
• Spannungsmessung auf der gesamten Batterie
• Strommessung am Ausgang/Eingang
• Schalten der Spannungsversorgung
• Balancen der einzelnen Zellen des Akkus
• Kontrolle des (Ent-)Ladestroms 
• Über-/Unterspannungsschutz

Viele BMS bringen auch weitere Funktionen mit. Für mich war außerdem wichtig:

• Konnektivität für meinen Raspberry Pi
• Hoher Strom am Aus-/Eingang
• Datenblatt für Protokoll oder bestehende Open Source Software zum Lesen
• Preis

Warum braucht man das überhaupt?

Der wichtigste Punkt: Lithium-Akkus sind sehr empfindlich. Sie vertragen keine zu starken Ladungen und Entladungen. Sie dürfen nicht zu viel geladen und nicht zu viel entladen werden, denn das würde sie direkt zerstören, und das wäre bei ihren hohen Preisen sehr schade. 

Weiterhin ist für den Fahrer des DDC-Trucks durchaus entscheidend, wie viel Strom noch im Akku ist. Man will ja nicht auf der Strecke liegenbleiben. 

Alle für den Fahrer wertvollen Daten kann ein BMS anhand der Werte, die es erhebt, recht genau berechnen.

Wie kommt das BMS in Fahrzeug?

Das BMS kommt als komplette Komponente (Bild 1). Man erkennt es leicht daran, dass es das Bauteil ist, zu dem die dicksten Kabel führen – was dem geschuldet ist, wie viel Strom es bewegt.

Im Fall unseres DDC-Trucks handelt es sich um ein Jiabaida 3-4S 100A JBD Smart BMS (keine Werbung, aber doch eine Empfehlung). Wie der Name schon erwarten lässt ist es für 3-4S-Batterien geeignet. Das bedeutet, dass 3 bis 4 Zellen in Reihe geschaltet werden können. Es kann bis zu 100 Ampere Dauerstrom aushalten, was ehrlich gesagt mehr ist als für den Truck nötig, aber in dem Fall habe ich es großzügig überdimensioniert, damit es im Betrieb nicht zu warm wird. Es muss sich schließlich die zirkulierende Luft mit dem Raspberry Pi teilen, der auch schon genug Wärme abgibt.

Außerdem hat es einen seriellen Datenport und ein Bluetooth-Modul, das mit einer App genutzt werden kann. Das macht es einfach, die Schnittstelle zu benutzen, denn man kann die ausgelesenen Werte mit denen in der App vergleichen und sehen, ob das Ergebnis passt.

Wie kommen die Daten in die Software?

Das Gute ist, dass sich schon jemand die Mühe gemacht hat, das Interface zu schreiben. Hier können wir also auf jbdtools zurückgreifen. Das ist ein Python-Tool, das das Auslesen für uns übernimmt und die Daten in der Bash ausgibt. Also bleibt für uns nur, den Output zu parsen und zu verschicken.

SignalRC – TelemetryReaderBase

Wie die meisten Anteile in SignalRC ist auch die Telemetrie modular aufgebaut. So ist auch die Klasse, die das Lesen der BMS Werte durchführt, eine Ableitung und muss in der telemetryChannels in der channelMap.json registriert werden. 

{
   "telemetryChannels": {
     "lifetime": {
       "telemetryType": "LteCar.Onboard.Telemetry.ApplicationLifetimeReader"
     },
     "battery": {
       "telemetryType": "LteCar.Onboard.Telemetry.JbdBmsTelemetryReader",
       "readIntervalTicks": 50,
       "options": {
         "jbdToolPath": "/home/user/jbdtool/jbdtool",
         "channel": "AA:AA:AA:AA:AA:AA"
       }
     }
   }
 }

Das Tolle daran? Das Erweitern ist nach Belieben möglich: Eigene Klasse erstellen, neu kompilieren, und schon kann eigene Hardware angesteuert werden.

Die eingestellten Ticks geben an, in welchem Intervall ein Read gescheduled werden soll. Beim BMS muss es nicht so oft sein, außer man möchte den aktuellen Stromverbrauch auslesen. Denn die anderen Werte ändern sich für gewöhnlich nicht so schnell.

Tickt es noch richtig?

Warum gibt es die Ticks überhaupt? Sie sind ein Mechanismus, um eine zeitgesteuerte Abfrage zu ermöglichen, denn sie meisten Telemetrie-Informationen haben keinen Interrupt, sondern müssen aktiv geholt werden. Sollte der Telemetriewert eigene Events oder Interrupts haben, kann der Tick einfach auf 1 gesetzt werden. Die Events sollten den aktuellen Wert dann in der Instanz cachen. Momentan ist es so, dass die Werte nur beim Tick an den Server gesendet werden. Hier ist aber auch schone eine Erweiterung geplant, die den Entwicklern mehr Freiheit geben soll, wann die Werte gesendet werden.

Jeder Telemetrie-Reader wird von dem SignalRC-Onboard-Client wie ein eigenes Unterprogramm behandelt. Wir können also im Grunde tun, was nötig ist, um die Daten zu bekommen, die wir brauchen.

Wie kommt das Ganze zum Server?

Ähnlich wie die Steuerung zum Onboard-Client kommt, wird die Telemetrie in die andere Richtung zum Server geschickt. Jeder Client hat eine offengehaltene Verbindung. Diese verarbeitet aber nun keine Events vom Server, sondern löst diese dort aus. Damit kann der Server die Daten sofort im Web-Client updaten. 

Der Aufbau einer solchen stehenden Verbindung ist bestechend einfach:

// Verbindung aufbauen
 await _connection.StartAsync();
 
 // Interface für den Proxy angeben
 server = _connection.CreateHubProxy<ITelemetryServer>();
 
 // An der Instanz die Server Funktionen aufrufen
 await _server.UpdateTelemetry(_carId, valueName, value);

Damit kann jeder Telemetrie-Reader, wie auch immer er intern designt ist, seine Daten gegenüber dem Server aktualisieren.

Ausblick: Was kommt noch?

Die Telemetrie in der aktuellen SignalRC-Version ist leider noch recht spärlich ausgeprägt. Das soll sich aber bald ändern: 

Telemetrie als Parameter

Die Telemetriedaten werden im Web Client ohnehin angeliefert, da wäre es doch nur logisch, wenn diese auch in den Controls benutzt werden können. SignalR liefert sie in Echtzeit, so wie die Controller am eigenen Rechner auch. So kann bei jedem Update eines Wertes ein Input verändert werden, der in den Control Flow eingreift.

Mehr Telemetrie-Reader

Im DDC-Truck selbst sind weitere Komponenten verbaut, die zwar theoretisch Werte liefern könnten, aber bisher noch nicht implementiert sind. Beispielsweise: LTE-Empfang, GPS, Live-Strom oder Abstandsmesser. Letzterer ist noch nicht eingebaut, aber geplant. 

Konfigurierbares UI

Ich fände es schön, wenn das User Interface für das Anzeigen der Telemetriedaten freier gestaltet werden könnte. Etwa so, dass man beispielsweise einen Tacho auch als Tacho anzeigt. 

Fazit 

Die Telemetrie hat noch etwas Strecke vor sich, bis sie das meiste aus SignalR herausholt. Wenn es so weit ist werde ich berichten.

[1] Georg Poweleit, SignalRC – in Echtzeit ans Steuer, dotnetpro 10-11/2025, Seite 46 ff.