A curated list of open technology projects to sustain a stable climate, energy supply, biodiversity and natural resources.

emobility-smart-charging

Smart charging algorithms with REST API for electric vehicle fleets.
https://github.com/SAP/emobility-smart-charging

Category: Consumption
Sub Category: Mobility and Transportation

Keywords from Contributors

archiving transforms measur generic optimize compose observation projection animals conversion

Last synced: about 14 hours ago
JSON representation

Repository metadata

Smart charging algorithms with REST API for electric vehicle fleets

README.md

emobility-smart-charging

Build Status
REUSE status

Contents:

  1. Description
  2. Requirements
  3. Download and Installation
  4. Getting Started
  5. Known Issues
  6. How to obtain support
  7. To-Do (upcoming changes)

Description

This repository is an implementation of smart charging for electric vehicles (EVs). It contains a charging optimizer which schedules EVs for charging throughout the day.
The optimization algorithm addresses the following goals:

  • Main goal: Ensure all EVs are charged at the end of the day while respecting infrastructure constraints
  • Secondary goal: Minimize peak load (avoid peaks in power consumption)
  • Secondary goal: Minimize electricity prices (charge EVs at times when electricity is cheap if prices vary)

Refer to [1] for a detailed explanation of the algorithm.

On a technical note, this repository contains the following components:

  • The algorithm for charging optimization (implemented in Java)
  • A server with a REST API for accessing the algorithm (implemented with Spring Boot)
  • A frontend "playground" application to test REST API input parameters and check results (implemented with Angular 8)
  • A Dockerfile to containerize the components described above

[1] O. Frendo, N. Gaertner, and H. Stuckenschmidt, "Real-Time Smart Charging Based on Precomputed Schedules", IEEE Transactions on Smart Grid, vol. 10, no. 6, pp. 6921 – 6932, 2019.

Requirements

The application may be run either with or without Docker.

With Docker

The application can be containerized using Docker and the Dockerfile in this repository. If the application is run via Docker the other requirements may be ignored.

Without Docker

The server requires Java and the dependency management tool Maven.
The minimum required Java version is Java 8.

Enter java -version and mvn -version in your command line to test your installation.

The frontend is optional. The server and its REST API will work without the frontend.
The requirements for the frontend are Node.js and its package manager NPM.

Enter node --version and npm --version in your command line to test your installation.

Download and Installation

With Docker

The simplest way to run this application is to use the public Docker image.
First, pull the Docker image:

docker pull sapemob/evse_emobility-smart-charging

Next, start the application by running the Docker container (the server runs on port 8080).
Parameters:

  • -d Detached mode: Run container in the background
  • -p Publish a container's port to the host: Change the first port in 8080:8080 to adjust which port you want the application to run on
docker run -d -p 8080:8080 sapemob/evse_emobility-smart-charging

Alternatively, you can build the Docker image yourself using the Dockerfile in this repository.
This will compile the server and the frontend.
Parameters:

  • -t Tag the image with a name
docker build -t sapemob/evse_emobility-smart-charging .

Without Docker

This section is relevant if the application should be run without Docker, for example for development purposes.

First, compile the server:

mvn clean install

(Optional) Prepare and compile the frontend:

cd frontend/
npm install
npm run build:playground

Start the server (from the root directory of the repository):

java -jar target/emobility-smart-charging-0.0.1-SNAPSHOT.jar

Accessing the application

After you have started the application it runs on localhost:8080.
The frontend can be accessed via /playground/index.html.
The API documentation is implemented via Swagger and can be accessed via /swagger-ui.html.

Generate TypeScript mappings (optional)

If you plan to use the API in a project which uses TypeScript you can generate the expected types of API requests and responses using the following command:

mvn typescript-generator:generate

This approach is used in the frontend. Type declarations are generated in the file frontend/src/assets/server_types.d.ts.

Getting Started

The purpose of this section is to get you started on using the charging optimizer API.

The easiest way to understand the interface of the API is to tinker with the playground (/playground/index.html). The playground is a visual interface which lets you edit the input for the charging optimizer in a natural way. The playground translates your model into a JSON request which is the technical input to the charging optimizer. You can easily pick up how to assemble JSON requests for the optimizer by observing how your playground input is reflected in the generated request.

Understanding charging optimizer input

In the top part of the playground screen you can edit the following input parameters:

  • Current time: This is the actual time of day assumed by the optimizer. The optimizer can only schedule charging sessions after the current time, not before. By default, the playground uses midday as current time.

  • Charging infrastructure: The charging infrastructure consists of a hierarchy of fuses reflecting the technical installation of the charging hardware. In real life, fuses are installed in a tree structure. There is typically one fuse per charging station, another fuse for a set of charging stations, and then further fuses for sets of fuses. By default, the playground contains a charging infrastructure with two levels of fuses to illustrate the concept of the tree structure.

  • Fuse: Each fuse is characterized by the current at which the fuse cuts off the power supply. The charging optimizer assumes three-phase electrical circuits. Therefore, each fuse is defined by a triplet of current values, one per phase. The playground lets you add further fuses to the infrastructure by clicking the corresponding buttons. By default, the playground uses 32 Ampere per phase for new fuses.

  • Charging station: Each charging station is characterized by the current at which the built-in fuse cuts off the power supply. The playground lets you add further charging stations by clicking the corresponding buttons. By default, the playground uses charging stations with 32 Ampere fuses.

  • Car: In the playground, cars can be added to charging stations to express their arrival at the charging station. When you add cars via the corresponding button, semantically you create a charging demand. In the charging optimizer, the cars with their charging demands are the central items for the optimization process. The charging optimizer creates one charge plan per car. Therefore you need to have at least one car in your input for the charge optimizer to create a non-trivial output. The more cars you add to the input, the higher becomes the competition for the scarce resource of charging current. With more cars, the available charging capacity is divided and more cars are assigned only partial or no charging opportunities.
    When you check out the generated JSON request you will notice the long list of parameters per car.

Use the button “Show circuit diagram of fuse tree” to visualize the wiring of the configured charging infrastructure.

Understanding charging optimizer output

To trigger the charging optimizer us the button labelled Optimize charge plans. The resulting JSON response contains a list of charge plans, one per car. Note that the actual charge plan for the car is labelled currentPlan and consists of a list of 96 entries. Each entry corresponds to a 15 minute interval since midnight. The entered value specifies the charging current which the optimizer assigns to this car in the given interval.

Additionally, the playground visualizes the aggregated charge plans in a stacked diagram. Each vehicle’s charge plan is represented by one color. The placement of the colored boxes along the horizontal axis indicates start and end of the charging intervals. The height of the boxes corresponds to the respective charging power (in Watt).

Known Issues

Please refer to the list of issues on GitHub.

How to obtain support

Please use the GitHub issue tracker for any questions, bug reports, feature requests, etc.

To-Do (upcoming changes)

  • Provide translation of charging profiles to the Open Charge Point Protocol (OCPP) 1.6 or 2.0
  • Provide parameters for standard EV models
  • Document API EV parameters in Swagger

Owner metadata


GitHub Events

Total
Last Year

Committers metadata

Last synced: 6 days ago

Total Commits: 62
Total Committers: 9
Avg Commits per committer: 6.889
Development Distribution Score (DDS): 0.339

Commits in past year: 2
Committers in past year: 2
Avg Commits per committer in past year: 1.0
Development Distribution Score (DDS) in past year: 0.5

Name Email Commits
Oliver Frendo o****o@s****m 41
Jérôme Benoit j****t@s****m 9
dependabot[bot] 4****] 6
Nadine Gärtner n****r@s****m 1
Nico Pöringer n****r@s****m 1
Pengyue Jiang 5****g 1
Priyanka 6****r 1
Priyanka Sakundarwar 4****r 1
Tobias F 3****e 1

Committer domains:


Issue and Pull Request metadata

Last synced: 1 day ago

Total issues: 6
Total pull requests: 58
Average time to close issues: 4 months
Average time to close pull requests: about 2 months
Total issue authors: 4
Total pull request authors: 7
Average comments per issue: 2.0
Average comments per pull request: 0.31
Merged pull request: 19
Bot issues: 0
Bot pull requests: 41

Past year issues: 0
Past year pull requests: 3
Past year average time to close issues: N/A
Past year average time to close pull requests: 7 minutes
Past year issue authors: 0
Past year pull request authors: 2
Past year average comments per issue: 0
Past year average comments per pull request: 0.0
Past year merged pull request: 1
Past year bot issues: 0
Past year bot pull requests: 0

More stats: https://issues.ecosyste.ms/repositories/lookup?url=https://github.com/SAP/emobility-smart-charging

Top Issue Authors

  • ofrendo (3)
  • LucasBrazi06 (1)
  • CVEDetect (1)
  • lundin (1)

Top Pull Request Authors

  • dependabot[bot] (41)
  • ofrendo (6)
  • jerome-benoit (5)
  • aamotharald (2)
  • thenewpyjiang (2)
  • OliveGerste (1)
  • CVEDetect (1)

Top Issue Labels

Top Pull Request Labels

  • dependencies (41)

Dependencies

pom.xml maven
  • com.googlecode.json-simple:json-simple 1.1.1
  • io.springfox:springfox-bean-validators 2.8.0
  • io.springfox:springfox-swagger-ui 2.8.0
  • io.springfox:springfox-swagger2 2.8.0
  • javax.xml:jaxb-api 2.1
  • joda-time:joda-time 2.10.6
  • org.apache.commons:commons-collections4 4.1
  • org.hibernate:hibernate-validator 6.0.13.Final
  • org.rosuda.REngine:REngine 2.1.0
  • org.rosuda.REngine:Rserve 1.8.1
  • org.springframework.boot:spring-boot-devtools
  • org.springframework.boot:spring-boot-starter
  • org.springframework.boot:spring-boot-starter-actuator
  • org.springframework.boot:spring-boot-starter-tomcat
  • org.springframework.boot:spring-boot-starter-web
  • org.springframework.security:spring-security-config
  • org.springframework.security:spring-security-web
  • org.springframework.boot:spring-boot-starter-test test
frontend/package-lock.json npm
  • 1234 dependencies
frontend/package.json npm
  • @angular-devkit/build-angular ~0.901.0 development
  • @angular/cli ~9.1.0 development
  • @angular/compiler-cli ~9.1.0 development
  • @angular/language-service ~9.1.0 development
  • @types/jasmine ~3.3.8 development
  • @types/jasminewd2 ~2.0.3 development
  • @types/node ^12.11.1 development
  • codelyzer ^5.1.2 development
  • jasmine-core ~3.4.0 development
  • jasmine-spec-reporter ~4.2.1 development
  • karma ~4.1.0 development
  • karma-chrome-launcher ~2.2.0 development
  • karma-coverage-istanbul-reporter ~2.0.1 development
  • karma-jasmine ~2.0.1 development
  • karma-jasmine-html-reporter ^1.4.0 development
  • protractor ~5.4.0 development
  • ts-node ~7.0.0 development
  • tslint ~5.15.0 development
  • typescript ~3.8.3 development
  • @angular/animations ~9.1.0
  • @angular/cdk ~8.2.3
  • @angular/common ~9.1.0
  • @angular/compiler ~9.1.0
  • @angular/core ~9.1.0
  • @angular/forms ~9.1.0
  • @angular/material ^8.2.3
  • @angular/platform-browser ~9.1.0
  • @angular/platform-browser-dynamic ~9.1.0
  • @angular/router ~9.1.0
  • @svgdotjs/svg.js ^3.0.16
  • chart.js ^2.9.3
  • chartjs-plugin-annotation ^0.5.7
  • hammerjs ^2.0.8
  • ng-json-view ^3.0.0
  • ng2-charts ^2.3.0
  • observable-slim ^0.1.5
  • panzoom ^9.2.1
  • rxjs ~6.5.4
  • tslib ^1.10.0
  • zone.js ~0.10.2
Dockerfile docker
  • maven 3.6.1-jdk-8-alpine build
  • node lts-alpine3.13 build
  • openjdk 8-jre-alpine build

Score: 6.639875833826537