Commit ac9966a0 authored by Jan Mayer's avatar Jan Mayer
Browse files


parent 6e125cf9
Pipeline #33672 passed with stages
in 1 minute and 59 seconds
......@@ -8,18 +8,19 @@ Memap starts a jetty server with a simple REST API for onboarding of local EMS a
| Functionality | Path | Return Codes |
| ------ | ------ | ------ |
| Start Simulationp | ` POST /memap/message/` | 201 - Created |
| start simulation | ` POST /memap/message/` | 201 - Created |
Once a [JSON configuration file]( is received in the body of such a request, the information is internally forwarded to the OpcUaBuildingController, who creates a building instance for every endpoint/local EMS in the JSON and creates virtual representations including an OPC UA client for every listed device, respectively. These virtual representations are MEMAP-internal actors, which collect informations from the OPC UA servers of their respective EMS (by subscriptions) and forward these information to the MEMAP-central problem formualtion and optimizer through messages. Optimized power setpoints for the onboarded devices are internally communicated back to the device actors, which then write the setpoints to the respective nodes of the local EMS Servers.
### Starting MEMAP Server
* Download the latest release
* Execute e.g. `java -jar memapCore_v101.jar jetty 24 900`, where
* the first argument gives the **mpc horitzon** in setpoints
* the second argument gives the **stepsize** in seconds
* in the above example: 15 min steps and horizon of 6 hrs. *Note: all forecasts at the local EMS have to provide corresponding forecasts*
* starts emulating 2 Buildings for MEMAP VPN at opc.tcp://localhost:4880 and opc.tcp://localhost:4890
* Download the latest [release](
* Execute e.g. `java -jar memapServer.jar jetty 24 900`, where
* the first argument (`jetty`) starts the jetty webserver. You may also chose `help`
* the second argument (`24`) gives the **mpc horitzon** in steps
* the third argument (`900`) gives the **stepsize** as time in seconds
In the above example this would mean 15 min. timesteps and a forecast-horizon of 6 hrs.
-> *Note: all forecasts at the local EMS have to provide corresponding forecasts*
### Onboarding
The onboarding was done using an internal version of [OpenVisu](, which is an open-source user interface from MEMAP-partner Holsten Systems for auto-discovery and visualization of OPC UA nodes. Alternatively, one can use (and personalize) our existing JSON-files or create it maually. Any free REST clients (e.g. postman) can then be used to send the file as body as described above:
......@@ -45,3 +46,13 @@ To test the functionality, two python based mocked buildings are provided in the
two building-Servers are created and are acessible under `opc.tcp://localhost:4880` and `opc.tcp://localhost:4890`.
Onboarding as described above can be done using [this JSON](
# memapGui
In **planning mode** multiple local energy management systems (EMS) can be simulated over a given time period, using the same optimization algorithm as in server mode.
To start the graphical user interface of the MEMAP planning tool, got to the latest [release](, download the artefacts and start (double click) `memapPlanningTool.jar`.
Buildings can be placed to the design area via drag & drop and the minimum necessary parameters for each added item (Demand, Producer, Volatile Producer, Coupler, Storage, Connection) for the two sectors (electric, heat) have to be inserted. Historical load (and generation) profiles are then used to simulate the advantages of a colloborative predictive control of the multi-building system versus the sum of all single-building optimizations, using the same algorithm as in server mode.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment