Filippos Notebook - cps-vip/cps-cosimulation-env GitHub Wiki

9/4 - 9/10

  • Followed the GitHub instructions and made the initial setUp in my MacOs (silicon).

9/11 - 9/17

  • Made small research on Modbus and DNP3.
  • Worked on the report for the above topics.
  • Watched videos about how helics work.

9/18 - 9/24

  • There is a new way to update the project.
git pull
make
make install
  • And before running anything use:
nix develop
  • However there is still an issue when running gridlab-d example on my silicon mac
(cps-cosim-env) eduroam-128-61-97-111:simple_gridlabd_example philippossophias$ ./run_example.sh
HELICS Version: 3.4.0 (2023-01-19)
Relay: Federate Relay has been registered
Relay: Registered Subscription ---> IEEE_123_feeder_0/currentA
Relay: Registered Subscription ---> IEEE 123_feeder_ 0/currentB
Relay: Registered Subscription ---> IEEE 123_feeder_0/currentC
Relay: Registered Subscription
---> IEEE_123_feeder_0/totalLoad

9/25 - 10/01

10/02 - 10/09

  • Worked on midterm presentation.
  • In the meeting we split the slides in parts so everyone can work on their own time.
  • I need to find time to watch this video about gridlab: https://www.youtube.com/watch?v=mjSraESOtE0
  • Had a second meeting on Tuesday for discussing some more research that we did.
  • On the slides I talked about:
    • OPP Inheritance
    • Protocols

10/12 - 10/19

  • Worked on the Team research paper.
  • Made some more research on DNP3 and MODBUS
  • Modbus
    • Modbus might be suitable for communication between devices within a substation, especially if the devices are legacy or primarily support Modbus.
    • If you have straightforward requirements, like merely reading measurements or setting parameters without the need for event logging, Modbus can suffice.
    • If your electric sector SCADA system interfaces with some industrial devices (e.g., power meters, simple controllers), Modbus might be the native or simpler protocol choice.
    • If the system has many older devices that primarily support Modbus or if there's a need to keep costs down, Modbus might be chosen. However, consider the limitations, especially around security. -DNP3
    • DNP3 is often the preferred protocol for communication between central systems and substations or RTUs in the electric sector. Its ability to handle event-based data collection with time stamps allows for more efficient and detailed monitoring, which is crucial for electric utilities.
    • Many modern IEDs in substations, such as protective relays and recloser controllers, natively support DNP3, which can provide detailed event and fault records.
    • For communications over larger distances or between different sections of the grid, DNP3's features like time synchronization and secure authentication can be vital.
    • If you have critical assets where command authentication is necessary to ensure that control commands are genuine, DNP3 with Secure Authentication should be used.
  • Prioritize DNP3 for most electric utility SCADA applications, especially for communication to and from remote sites and for any operations requiring time-stamped event data, security, or advanced features.

10/20 - 10/27

  • Tried on ECE linux computers
  • Needs sudo account
  • Tried on a virtual machine inside macOs silicon, but the VM crashed on "nix develop"
  • Simple and good for RTU implementation:
  • To convert the RTU to TCP, to read it from wireshark I will try use (I tried and i cant find a way to install it on macos):

10/28 - 11/03

  • I used for macOS something called socat, to connect to serial ports
    • Used "brew install socat" to install it
socat -d -d pty,raw,echo=0 pty,raw,echo=0
2023/11/01 14:23:24 socat[12345] N PTY is /dev/ttys001
2023/11/01 14:23:24 socat[12345] N PTY is /dev/ttys002
2023/11/01 14:23:24 socat[12345] N starting data transfer loop with FDs [5,5] and [7,7]
  • ttys001 for slave and ttys002 for master
  • Then run slave and then master

11/04 - 11/11

  • I made aa copy of the simple_gridlabd_example and I named it gridlab_testing_enviroment and I started working there.
  • I used pyModbus to make a connection with TCP.
  • I used port 502 and I made a simple master and slave and started send some data.

11/12 - 11/25

  • I made a python file called receiver outside of the helics simulation
  • Inside transmission_simulator.py Ι added some lines that will send the voltage on the receiver when running the simulation.
  • To work firstly I had to run reader.py and then the gridlabd simulation.
  • However I only managed to send small data, in order to send floating numbers I sould consider using encoding.
  • I also enabled wireshark for package analysis. -found tcp handshake and modbus protocol.
  • I pushed my project under the branch ph/modbus

01/08 - 01/21

  • Beginning of the spring semester
  • In the first meeting, met the new team and schedule weekly meetings in Sunday 15:00

01/22 - 01/28

  • This week we have the first presentation of the semester
  • We split the slides, I took the Modbus network

01/29 - 02/11

  • In the meeting we tried to set up everyones computer in the team to run gridlab_d
  • They where some issues, with most of the resolved in the meeting on Tuesday 02/01
  • From 02/06 we will start researching and making new models as to ubgrade the Modbus and DNP3 connections
  • Set the task to the others to read the code in the gridlabd_example and in the device modelling folder
  • Started looking again: https://pymodbus.readthedocs.io/en/latest/source/client.html
  • I will start by using the coils instead of the registers:
client.write_coil(1, True, slave=1)        # set information in device

result = client.read_coils(2, 3, slave=1)  # get information from device
print(result.bits[0])                      # use information

02/12 - 02/18

  • Write coil can be only used to send boolean values, so in our can for now we should stick with write register
  • With in a single register we can send values 0 up to 65535, for bigger values multiple registers should be used
  • For multiple register, write registers should be used.
  • An idea could be to write in one register the imaginary part and in two the real part (first for before and second for after the floating point)
  • In a tcp packet you can have up to 125 registers
  • This is in reader
di_data_block = ModbusSequentialDataBlock(0, [0]*100)  # Discrete Inputs: OFF state
co_data_block = ModbusSequentialDataBlock(0, [0]*100)  # Coils: OFF state
hr_data_block = ModbusSequentialDataBlock(0, [0]*100)  # Holding Registers: Zero-initialized
ir_data_block = ModbusSequentialDataBlock(0, [0]*100)  # Input Registers: Zero-initialize
  • Address is set to start from 0
  • The initial values are 0 and then you set up the quantity

02/19 - 02/25

packed_float = struct.pack('>f', float_value)  # '>f' for big-endian 32-bit float
reg1, reg2 = struct.unpack('>HH', packed_float)  # '>HH' for two big-endian 16-bit parts
  • But may need to split this up to more registers because the numbers may be bigger or more precise
  • To convert it back to float:
packed_float = struct.pack('>HH', reg1, reg2)
float_value = struct.unpack('>f', packed_float)[0]
  • Nov we can do the same for real and imaginary part:
packed_voltage_real = struct.pack('>f', voltage_gld.real)  # '>f' for big-endian 32-bit float
reg1, reg2 = struct.unpack('>HH', packed_voltage_real)  # '>HH' for two big-endian 16-bit parts

packed_voltage_imag = struct.pack('>f', voltage_gld.imag)  # '>f' for big-endian 32-bit float
reg3, reg4 = struct.unpack('>HH', packed_voltage_imag)  # '>HH' for two big-endian 16-bit parts

client.write_registers(address, [reg1, reg2, reg3, reg4])
  • After doing that and running the simulation I found out that all imaginary values where 0, so I may remove them
  • Reader output:
Read Values: (136593.359375 + 0.0j) V 
Read Values: (143009.28125 + 0.0j) V 
Read Values: (142973.140625 + 0.0j) V 
Read Values: (143027-65625 + 0.0j) V 
Read Values: (142983.921875 + 0.0j) V 
Read Values: (142988.65625 + 0.0j) V 
Read Values: (143001.90625 + 0.0j) V 
Read Values: (142956.984375 + 0.0j) V 
Read Values: (142959.703125 + 0.0j) V 
Read Values: (142961-078125 + 0.0j) V
Read Values: (142957.6875 + 0.0j) V
...

02/26 - 03/03

  • This week we had to make a presentation
  • We split up all the parts (there is a file in google dock with those details)
  • I had the modbus networking part
  • In order to create the slides I had to make a new capture of data using wireshark
  • I explained everything found in wireshark in the slides
  • Then I also wrote the about the code I wrote with the encoding
  • And I wrote the goals fot this and the next semesters

03/04 - 03/10

  • We analysed a network capture in class
  • We used Wireshark
  • It was communication network between robots, playing football, and their sensors
  • There is a writeup word file form more informations

03/11 - 03/17

  • Tried to run device_modeling folder
  • To work I should open on device_modeling folder the vs_code
  • And move the bay_controller_demo outside src
  • If I want to keep it inside I should remove src from the beginnings in the imports
  • The current summation just generates random data but this can be integrated in the gridlabd_example and use helics
  • Thats what we are going to work on the next days

03/18 - 03/24

  • Spring break

03/25 - 03/31

  • Having two ideas
    • Implement Modbus with TCP externally of the Helics
    • Make a Modbus packate and send it through helics
  • With the second option we will have more control over the package
  • But it will be more difficult to implement
  • Some links I was looking:
  • General goal is to connect device_modelling folder with simple_gridlabd_example.
  • Now device modelling is just working with random values, no Helics.
  • Some other observation, is that the current devices in Relay are imported in helecs, from IEEE. So I should check how this works

04/01 - 04/07

  • https://docs.helics.org/_/downloads/en/latest/pdf/
  • Stopped for a moment looking at Modbus, and concentrated at helics
  • Found out that helics take the values from gridlab-d
  • Start checking Gridlab-d/powerflow/substation.cpp
  • Aim is to start manipulating switches from glm and py scripts
  • I will have to change the publications and subscriptors
  • In particular, in gridlab-d a switch should be a subscriptor and in helics a publication

04/08 - 04/14

object switch {
    name sw13152;
    phases "ABCN";
    from n13;
    to n152;
    status CLOSED;
};
  • From there I tryed to change the value of the status
  • To do that I went into the IEEE_123_feeder_0.json and added a subscription
{
     "required": true,
     "key": "Relay/switchA",
     "type": "string",
     "info" : {
          "object" : "sw13152",
          "property": "status"
     }
}
  • Then I went into the Relay_config.json and add a publication
{
    "name": "SwitchA",
    "key": "Relay/switchA",
    "type": "string",
    "global": true
}
  • Then in Relay_simulator.py I tried to to change the value by using: h.helicsPublicationPublishString(pub, "OPEN")
  • The above is documented used for enumarations too (Tried later)
  • Then I created a publication in gridlab and a subscription in helics to check if the value was actually changed (Check code)
  • After running it the status value was chagned
  • After that I tried to change the value phase_A_state that is a variable from the parent class but it was unsuccessful, I will need to figure out what went wrong, I am guessing something else is affecting this value
  • Though I was able to read this value
  • What I realised it that if I change the status to OPEN, then phase_A_state will change to OPEN too so I guess those two are connected

04/15 - 04/24

  • At that time the main focus was on creating the final presentation and paper.
Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️