Differences

This shows you the differences between two versions of the page.

--- ladeloesung [2026/02/01 16:25] – andi
+++ ladeloesung [2026/02/01 22:44] (current) – [Elektrisch] admin
@@ Line 4: / Line 4: @@
   * verhindern, dass sie über einen längeren Zeitraum per Ladegerät auf 100% erhalten werden.
   * unnötige Zyklen vermeiden
-  * möglichst die Batterien auch während der Saison nicht mit 100% Ladestand lagern (Entladen auf storage charge während der Saison wäre hingegen kontraproduktiv)
+  * möglichst die Batterien auch während der Saison nicht mit 100% Ladestand lagern (Entladen auf storage charge während der Saison wäre hingegen kontraproduktiv bezüglich Zyklen)
   * Die Batterien sollten aber auch nicht im fast leeren Zustand gelagert werden. Laden auf Storage, dann auf 100% vor Flugtag wäre am besten.
@@ Line 10: / Line 10: @@
 ===== Standard Ladelösung =====
-  * Die Ladegeräte wenn aktiv, laden die Akkus immer auf 100%.
+{{:charger_original.png?400|}}
-  * Wenn nicht aktiv, ist das Ladekabel mechanisch getrennt (Relaiskontakt)
+  * Die Ladegeräte sind durch ein Datenkabel mit dem BMS verbunden. Protokoll ist unbekannt. Ladevorgang scheint Kollaboration zwischen BMS und Ladegerät (z.B. Steuerung der Strombegrenzung). Ladegerät wird nur aktiviert bei vorhandener Datenverbindung (und deaktiviert, wenn die Datenverbindung getrennt wird).
+  * Wenn nicht aktiv, ist das Ladekabel mechanisch getrennt (normally open Relaiskontakt).
+  * Der Ladeprozess wird automatisch gestartet (BMS ein, Ladegerät verbunden) und endet immer bei 100%.
   * Wenn volle Batterie eingesteckt bleibt, wird wahrscheinlich eine Erhaltungsladung gemacht (TBV. wie? periodisch? Zwischendurch auch getrennt?)
+  * Balancing scheint Teil des Ladevorgangs zu sein und wird im BMS gemacht (leichte Entladung einzelner Zellenschichten).
+  * Entladegerät stoppt Entladung bei 50% automatisch (Storage charge, nur bei Einwinterung).
 ===== Anforderungen =====
 ==== Funktion ====
-  *
+  * Die FES-Akkus sollen kurz vor einem Flugtag auf 100% geladen werden (basierend auf Reservation, evtl. mit Zusatzflag oder durch interaktive Anforderung des Piloten in separatem System)
+  * Die FES-Akkus sollten unmittelbar nach einem Flug mit starkem FES-Gebrauch auf eine mittlere Ladung aufgeladen werden (automatischer Ladestopp)
+  * Ladungserhaltung soll unterdrückt werden (wenn z.B. Flugzeug doch nicht benutzt wurde).
+  * Batterieladezustand sollte remote abgefragt werden können.
+  * Ladezyklen und andere relevante Aktivitäten sollten geloggt werden.
+  * Die Einheit sollte überwacht werden (mit automatischer Benachrichtigung an benannte Personen bei Problemen oder Unerreichbarkeit).
 ==== Mechanisch ====
@@ Line 34: / Line 44: @@
+===== Architektur =====
+==== Elektrisch ====
+Steuerung ist in die Einheit eingebaut und hat folgende elektrische Funktionen:
+{{:charger_steuerung.png?400|}}
+**Aktivierung/Deaktivierung Ladevorgang**
+  * **Charger Schalter:** Damit kann das Ladegerät von der Steckdose getrennt werden. Unter der Annahme, dass dabei das Relais im Ladekabel aufgeht.
+  * **BMS Comm (Nur Trennung RX):** Bewirkt ebenfalls das Öffnen des Relais im Ladekabel (kontrollierter, als einfach die Speisung abzuklemmen?).
+**Erkennung/Verfolgung des Ladezustands**
+  * **Ohne Unterstützung**: basiert alleine auf Zeitschaltung und Informationen von Bediener.
+  * **BMS Comm (Trennung RX, abhören RX, allenfalls Übernahme TX):** Mit reverse engineering des Protokolls, könnten Batterieinfos vom BMS abgehört/abgefragt werden. Auch Informationen zum Ladevorgang sollten hier verfügbar sein.
+  * **Spannungsmessung:** Alternativer Weg, zu Batteriespannungs-Infos zu kommen ohne Protokoll-Analyse. Nachteil: Eigene Messung kann divergieren von BMS-Messung.
+--> HW Design sollte evtl. alle Möglichkeiten vorsehen.
+==== Bedienung ====
+=== UI Lokal ===
+== Controls ==
+Controls für Request sollten zustandsfrei sein, also zum Beispiel 3 Taster (Full, Storage, Abort).
+== Anzeigen ==
+LEDs? Welche Zustände sind nötig? Ladestand ist auf den BMS Displays verfügbar, also braucht es vielleicht nur die Unterscheidung der Zustände gemäss Diagramm unten.
+=== Remote ===
+== Vernetzung ==
+WIFI Modul? (Anfrage bei Roger hängig bezüglich Leerrohren zw. Clubhaus und Hangar für Installation Access Point in Hangar)
+== API ==
+Eine RESTful API würde sich anbieten. Absetzen von Requests sowie Anzeige von Zustand, evtl. Ladestand und Logs.
+Komplexere Funktionalitäten (Scheduling/Einbindung Reservationssystem) würden dann komplett auf Intranet implementiert.
+==== Software ====
+Die Steuerung kann Ladeprozesse unabhängig und selbstständig zu Ende führen. Zum starten eines Ladeprozesses braucht es einen Request - entweder von einem lokalen UI oder von remote.
+{{:sm_request.png?400|}}
+Das Zustandsdiagramm zeigt, wie die Steuerung auf Requests reagiert (grüne Pfeile) und wie sie den Ladevorgang zu Ende führt (schwarzer Pfeil). Dieses Design kann nicht zwischen lokalen und remote-Requests unterscheiden. Die entsprechenden Kontrolleinheiten (UI oder remote) müssen selber stateless sein, und dürfen nur einzelne Requests absenden. Insbesondere darf die Remote-Applikation nicht versuchen, einen lokal abgebrochenen Prozess wieder zu starten.