This Dezyne modelling example is ICT team’s submission for the Dezyne Challenge 2018.

The application

As electrical vehicles become more and more mainstream there is a growing demand for charging stations. At the same time the available power at a site may put a limitation on how many cars can be charged simultaneously.

For our contribution to the Dezyne Challenge we have designed a smart charger. When connected in a network these chargers will negotiate to distribute available power dynamically depending on the demand at hand. This way the chargers are able to share available power efficiently, while respecting the site’s limitations. Possible chargers actions are for example charging at full power, scaling down to free up power for other chargers, or waiting till other chargers are finished.

Specification and design choices

Principles

  • Total power consumption is limited

  • First come first serve

  • No central controller

  • No limit on number of chargers sharing power resources

  • Charging involves authorization and financial transactions

Implementation Choices

  • Maximum of 2 cars charging at the same time

  • One car: full power, two cars: both half power. Following cars get queued

  • Chargers communicate in a peer-to-peer network

  • Fixed configuration of three chargers

  • Basic calls to related servers are stubbed

Implementation

image image image

Architecture

The Dzn system consists of Dzn implemented and handwritten components. The "Scheduler" is responsible for initiating communication in the network and deciding at what power the charger should charge at. The "Charger" is responsible for initiating charging, receive charging requests and authorization via the "AuthorizationUnit" handwritten component. Currently the Authorization procedure just mimics an authorization by always succeeding but the system is capable of handling authorization failure as well. The "Hardware" initiates charging via Rpi handwritten components and keeps track of time via "TimerComp" component.

image

Project Results

Conceptual diagram

Let us consider a case, where the car connected to charging station 1 wishes to charge. Charging station 1 sends a request to charging station 2 and 3 via Iquery1 and Iquery2. It request the other two charging station visa IScheduler. So in this case, there will be two direct connection in which charging station 1 acts as client and charging station 2 and 3 acts as a server.

In a single process system, the interfaces (IQuery and IScheduler) are connected directly, we break the interface and connect is via Zeromq.

The same pattern applies when charging station 2 and 3 request for charging. In total, there will be six direct socket connections while all three charging station act both as client and as server in a peer-to-peer configuration.

image

Sample Charger Scenario I

A car arrives, user gets authorized and the car is charged at full power.

image

Sample Scheduler Scenario I

The scheduler queries the network for availability.

image

Sample Charger Scenario II

A first authorization fails, charging starts at half power, and halfway continues at full power.

We explicitly over ride/ignore this behavior in the code.

image

Sample Scheduler Scenario II

The scheduler responds to a change in the network.

image

Sample Scheduler Scenario III

The scheduler scales up as more power becomes available in the network and scales down again when another car in the network requests power.

image

More details about the project is demonstrated in this video.

Lessons learned

We were using Dezyne timers for calculating the time required for charging a car. We were facing issues while implementing the Dezyne timer in the Smart Charger project. After support from Verum colleagues, we understood that we should use thread safe shell while using the timer. It would be more handy for users if there is a dedicated documentation and code example on how to use timers.

We faced blocking issues in the communication between Raspberry Pi since we used synchronous reply in the concurrent system. This also introduces race condition in the communication. This implementation defect can be captured using the external feature keyword. Unfortunately, we could not verify because of the verification issues in the Dezyne tool.

We also faced the issue of version control since we were working remotely. Thus, we also concluded to use git hub tool for version control.

Tips and guidelines for others

Smart charger does not have a centralized controller. All the smart charger system run concurrently and coordinate among themselves to share a power line. We implemented a system where three chargers share a power line.

We run each smart charger system on separate Raspberry Pi. Raspberry Pi coordinate/communicate among themselves using Zeromq communication protocol.

RaspberryPi identify other Pi’s using IP address. The Zeromq communication protocol code is available in handwritten code and this has to be changed every time based on Raspberry Pi’s IP address. It is advisable to use fixed IP address for the Pi’s.

There are three files in the Smart Charger project.

  • Smartcharger_Pi1 - Runs on Pi 1. IP Address:192.168.1.116

  • Smartcharger_Pi2 - Runs on Pi 2. IP Address:192.168.1.137

  • Smartcharger_Pi3 - Runs on Pi 3. IP Address:192.168.1.114

All the Pis are connected in Peer to Peer fashion using Zeromq. Since there is no centralized controller in our application, every Pi requires two interfaces (IQuery1 and IQuery2) and provides an interface IScheduler.

Note: In the ideal case, every smart charger should provide two IScheduler interface but we modeled using one IScheduler interface and integrated using hand written code.

Pi 1 is connected to Pi 2 and Pi 3 in a Peer to Peer Fashion.

  • End port of Pi 1 which acts as server for Pi 2 : 5555

  • End port of Pi 1 which acts as server for Pi 3 : 5554

Pi 2 is connected to Pi 1 and Pi 3 in a Peer to Peer Fashion.

  • End port of Pi 2 which acts as server for Pi 1 : 5550

  • End port of Pi 2 which acts as server for Pi 3 : 5551

Pi 3 is connected to Pi 1 and Pi 2 in a Peer to Peer Fashion.

  • End port of Pi 3 which acts as server for Pi 1 : 6000

  • End port of Pi 3 which acts as server for Pi 2 : 6001

Documentation

You can download the example in a zip-file here.

Note that all of the diagrams included in this document have been produced in and exported from Dezyne. The System View and State Charts are part of the Dezyne editor. The Sequence Trace has been produced using the Dezyne simulation engine.