This Dezyne modelling example is ICT team’s submission for the Dezyne Challenge 2018.
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
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
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
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.
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.
Sample Charger Scenario I
A car arrives, user gets authorized and the car is charged at full power.
Sample Scheduler Scenario I
The scheduler queries the network for availability.
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.
Sample Scheduler Scenario II
The scheduler responds to a change in the network.
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.
More details about the project is demonstrated in this video.
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
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.
If you have questions that weren’t answered by this Guide,
let our support team help you out.