Dependency Problem Google ORTools

[Alex]

Hi everyone,

I am trying to set up a highlevel scheduler using Google OR-Tools ( OR-Tools forJava) to solve the MILP.

Unfortunately I get dependency errors when integrating the code in OpenEMS. In a simple maven project the dependency

  		<dependency>
		    <groupId>com.google.ortools</groupId>
		    <artifactId>ortools-java</artifactId>
		    <version>9.12.4544</version>
		</dependency

works fine and I get no error.

If I paste the same dependency to the pom.xml in OpenEMS and add ortools to the buildpath I first get the error message “NoClassDefFoundError: com/sun/jna/Platform”. After also adding this dependency i get the error

Resource ortools-win32-x86/ was not found in ClassLoader

Did anyone use OR-Tools successfully in OpenEMS? Did anyone have the same problem or any advice how to solve this?

Thanks in advance, any help is appreciated!

Regards
Alex

[sebastian.asen]

Hallo Alex,

möglicherweise musst du ähnlich wie für andere Libraries einen Wrapper erstellen.
Ich benötige aber auch selten komplett neue Libraries und bin deshalb auch nicht ganz so fit darin.

openems/io.openems.wrapper at develop · OpenEMS/openems

VG
Sebastian

[Alex]

Hi Sebastian,

danke für den Tipp!
Ich habs mal versucht nachzubauen, aber bin mit meinem Halbwissen leider nicht weiter gekommen. Werde versuchen es mit einer anderen Bibliothek zu machen.

Grüße
Alex

[stefan.feilmeier]

Hallo Alex,

kannst du vielleicht mehr über dein Entwicklungsziel sagen? Ich könnte mir vorstellen, dass für dich die Entwicklungen am “Energy Scheduler v2” nützlich sind, an dem wir intensiv arbeiten.

Letzer Backport dazu: Energy Scheduler v2 / Time-of-Use-Tariff optimization (ALPHA) by sfeilmeier · Pull Request #3029 · OpenEMS/openems · GitHub

Gruß,
Stefan

[Alex]

Hallo Stefan,

ich würde gerne ein MILP-Problem lösen, welches aus PV-Prognose, TOU-Tariff und angeschlossenen E-Fahrzeugen die optimale Lastverschiebung berechnet. Kann der Solver des Energy Schedulers soetwas auch?

Mein aktueller Workaround ist das MILP in Python über Google OR-Tools lösen zu lassen und die Daten über JSON auszutauschen.

Viele Grüße
Alex

[stefan.feilmeier]

Ja, sowas kann der “Energy Scheduler v2” auch und es wäre toll, hier weitere Mitstreiter zu finden.

Hast du einen konkreten Laboraufbau oder findet das alles nur in Simulationen statt?

Der Ansatz in OpenEMS ist kein MILP, sondern ein Fahrplan für vordefinierte Betriebsmodi

• Für E-Auto-Beladung z. B. “keine Beladung”, “PV-Überschuss”, “Schnellladung” → (siehe Code)
• Für Batteriespeicher z. B. “Eigenverbrauchsoptimierung”, “Verzögerte Entladung”, “Beladung aus dem Netz” → (siehe Code und FEMS Anleitung)

Diese Fahrpläne werden dann jeweils simuiliert und anhand einer Kostenfunktion verglichen. Gleichzeitig wird der Fahrplan dann in Echtzeit ausgeführt und viertelstündlich angepasst.

• Simulation Speicher → Code
• Kostenfunktion → Code
• Anwendung in Echtzeit → Code

Gruß,
Stefan

[stefan.feilmeier]

FYI, hier ist gerade eine Diskussion, die auch interessant sein könnte:

Clarification about Genetic Algorithm and Time-of-Use Controller

Hello. Could someone please explain how is the provided genetic algorithm supposed to be used? I had a look at the code but couldn’t understand how to activate it (unlike the other algorithms, there is no controller for it) and what fitness or cost functions there are. Is it the same algorithm talked about at the OpenEMS Conference in November 2024, which this blog post mentions? Is it a real-time algorithm, such the Symmetric Ess Balancing controller? Could you also explain how to use the Time…

[Alex]

Hallo Stefan,

vielen Dank für die ganzen Infos.

Leider muss ich sagen, dass mit meinem mittelmäßigen Verständnis von Java es extrem schwer ist nachzuvollziehen, wie “io.openems.edge.energy” funktioniert.

Aus dem grundlegenden Problem hätte ich folgende Struktur erwartet:

Input Data:

• System state (e.g. SoE of ESS)
• Predictions
• Costs
• Configurations
  
  Model:
• Constraints
• Physical relations (energy and SoE dependency, efficiency, …)
  
  Solver:
• Result: Optimal scheduling of controllable components
  
  Interpretation of Scheduling:
• Realtime control of 15 minutes scheduling result (Use Grid Only, Balance Grid, …)

Was ich gefunden habe:
Model → EnergyFlow (io.openems.edge.energy.api)
Interpretation of Scheduling → StateMachine (io.openems.edge.controller.ess.timeofusetariff)

Wie alles miteinander verschachtelt/verknüpft ist, ist für mich nur sehr schwer zu durchblicken, was für mich ein großer Overhead bedeuten würde, um schlussendlich das Modell umzusetzen, welches ich in OR-Tools schon habe. Dies als kleine Rückmeldung dazu, dass man es vielleicht den “kleinen” Programmierern etwas vereinfachen könnte…

Hierzu eine Verständnisfrage:
Warum wurden die Predictions/TOU tariffs nicht als Komponenten über die Config hinzugefügt, sondern über einen PredictionsManger (dessen Implementierung ich nicht gefunden habe)?

[stefan.feilmeier]

Dass es einfach wird hat ja auch niemand behauptet. Ich bin ziemlich überzeugt davon, dass der eingeschlagene Weg der Optimierung sinnvoll ist (das sehe ich nicht zuletzt an meinem privaten System aus PV+Speicher+2xE-Autos+Dynamischer Stromtarif).

Und deshalb versuche ich auch Leute dafür zu gewinnen, gemeinsam daran zu arbeiten - um so das Wissen zu verbreiten und die Funktionen zu Dokumentieren (hier um Forum, später auch in der OpenEMS Doku)

Die Variante über ein separates MILP in Python etc. ist wiederum für uns schwierig, weil sie kompliziert auf tausende Systeme zu skalieren ist. Sind deine Entwicklungen irgendwo offen verfügbar?

Und nochmal die Frage: Hast du einen konkreten Laboraufbau oder findet das alles nur in Simulationen statt?

Warum wurden die Predictions/TOU tariffs nicht als Komponenten über die Config hinzugefügt, sondern über einen PredictionsManger (dessen Implementierung ich nicht gefunden habe)?

Da jeder Predictor definieren kann, für welche Channels er geeignet ist (z. B. nur für Verbrauch oder nur für Erzeugung), ist das über den PredictorManager abstrahiert.

Für den TimeOfUseTariff gibts das noch nicht, allerdings werden wir das vermutlich auch bald brauchen, da wir für manche Situationen den Brutto-Preis (Kostenfunktion) und für manche den Netto-Preis (Solarspitzengesetz: keine Vergütung der Einspeisung bei negativen Netto-Preisen) brauchen.

Vielleicht ist es auch sinnvoll, dass wir die Fragen mal in einem Teams-Call klären, oder wir diskutieren die Energy-Scheduler-Architektur einmal in einem OpenEMS Networking Friday.

[Alex]

Das wäre super, wenn ich mich da einmal per Teams melden könnte, das Angebot nehme ich gerne an! Mein Code ist gerade noch in Bearbeitung sobald ich hier eine Runde Sache habe, würde ich mich nochmal melden.

Der Workaround über Python ist nicht optimal und sicher keine dauerhafte Lösung. Gerne arbeite ich hier bei einer reinen OpenEMS-Lösung mit!

Angewendet werden soll es sowohl in einer Simulation als auch auf der im Rahmen des Forschungsprojektes SKALE aufgebauten Ladestation mit 12 DC-Ladepunkten, PV-Anlage und Batteriespeicher: