Matthias SpeicherShowcase
Flotten-Rechner
Ein neutraler Rechner für Logistiker, die vor der Frage stehen, ob und wie sie ihre Flotte elektrifizieren. Er beantwortet nicht „wie viele Batteriemodule kaufst du“, sondern dreht die Frage um: Was braucht dieser Betrieb überhaupt, und wo ist der Engpass? Ergebnisoffen, entlang von Werten, die ein Logistiker aus der Praxis kennt, nicht aus einem Elektrotechnik-Studium.
TypeScript, React, Vite. Rechenkern ohne UI. Alle Rechnungen laufen clientseitig, es geht nichts an einen Server. 72 grüne Tests, 3 Saison-Szenarien. Tour- und Depot-Simulation, PV, BESS mit Peak-Shaving, TCO gegen Diesel inklusive LSVA. Max-min-faires Water-Filling.
Woran man sieht, wie ich denke
Sechs Entscheidungen, die das Werkzeug geprägt haben, jeweils mit dem Preis, den sie gekostet haben.
Ein Modell, zwei Oberflächen
Dieselbe Rechen-Engine trägt zwei völlig verschiedene Einstiege. Ein Expertenmodus, in dem alle Variablen offenliegen, für den, der genau weiss, was er tut. Und ein geführter, natürlicher Modus, der den Einstieg radikal vereinfacht und mit Defaults aus der Praxis arbeitet. Die Entscheidung dahinter: Die Schwierigkeit eines solchen Werkzeugs ist nicht die Rechnung, sondern die Angst vor dem leeren Formular. Wer sich zum ersten Mal mit dem Thema beschäftigt, braucht einen anderen Weg hinein als der Profi, aber beide sollen zum selben Ergebnis kommen. Zwei Oberflächen auf einer Engine, nicht zwei Werkzeuge, sonst driften die Ergebnisse auseinander.
Diesel als Eingabe, nicht Kilowattstunden
Ein Logistiker kennt seinen Dieselverbrauch, nicht seinen kWh/km-Wert. Also ist Diesel der primäre Input, den Strombedarf schätzt das Werkzeug. Der Preis: eine Umrechnung mehr im Hintergrund. Der Gewinn: niemand muss etwas eingeben, das er nicht weiss. Und der Diesel-Vergleich fällt gratis ab.
Den empirischen Umrechnungsfaktor verworfen
Zuerst hatte ich einen festen Faktor gebaut, Diesel geteilt durch Strom. Beim Prüfen an realen Fahrzeugen fiel auf: der Faktor ist nicht konstant, er verschiebt sich je nach Fahrzeugklasse. Also raus damit, ersetzt durch zwei Klassen-Tabellen, die die relative Lage in der Spanne abbilden. Kostet eine zweite Tabelle und neue Logik. Aber die einzelne Zahl hätte plausibel ausgesehen und wäre falsch gewesen, und das ist der teuerste Fehler von allen.
Auslegung auf den Winter, Wirtschaftlichkeit auf den Mix
Reichweite schwankt mit Last und Temperatur. Wenn man die Infrastruktur auf den Jahresdurchschnitt auslegt, erstickt das Depot im Januar. Also wird auf die Winter-Spitzenwoche dimensioniert, aber die Wirtschaftlichkeit auf dem realistischen Jahresmix gerechnet. Zwei Ansichten statt einer, weil eine Zahl hier zwei verschiedene Fragen beantworten müsste.
Peak-Shaving darf die Fahrbereitschaft nie gefährden
Man könnte die Lastspitze so tief wie möglich kappen, das senkt den Leistungspreis. Ich habe es gedeckelt: Shaving nur so weit, dass kein Truck am Morgen schlechter dasteht als ohne. Der Zweck des Depots ist, dass die Trucks fahren. Eine Optimierung, die das gefährdet, optimiert das Falsche.
Vom Lernwerkzeug zum Prüfwerkzeug
Am Anfang arbeitet man sich mit dem Rechner ins Thema ein, versteht, welche Grössen den Ausschlag geben. Später, wenn Angebote von Anbietern auf dem Tisch liegen, wird derselbe Rechner zum Prüfwerkzeug: Man rechnet die Angebote gegen, vergleicht Lösungen, sieht, ob die Zahlen tragen. Dasselbe Werkzeug, zwei Phasen, damit der Logistiker am Ende nicht über den Tisch gezogen wird.
In 27 Sekunden durch den Rechner
Der ganze Weg von der Eingabe bis zur Einordnung, ohne Ton.
In vier Sätzen zur Antwort
Der erste Modus fragt nicht nach Kennzahlen, sondern nach der Flotte, wie man sie beschreiben würde. Die Rechnung dahinter bleibt dieselbe.
Jeder Parameter in der Hand
Derselbe Rechenkern, nur ohne Abkürzungen: Fuhrpark je Fahrzeug, Wochenplan je Tag, Ladeinfrastruktur, Speicher und PV im Detail, bis zur vollständigen Wirtschaftlichkeitsrechnung.
