4/18/24 -- Class Meeting

• During this meeting, both subteams presented their presentations.

4/17/24 -- Personal Work

• I continued to work on my part of the presentation. I completed the introduction, so I added my progress to the "Key Takeaways & Future Plans - Monitoring" slide. Since I worked on fixing the GridLAB-D bug this semester, I added a picture of the commands we used to fix the issue. These commands include the instructions to pull from the correct GridLAB-D branch so that the cmake error is no longer thrown.

4/16/24 -- Personal Work

• I worked on my part of the presentation, which was the introduction. For this part, I modified the slide to reflect the need to fulfill the requirements outlined by the CIA Triad. I also made sure to not have too much text on the slide.

4/15/24 -- Supplementary Team Meeting

What We Did

• During this meeting, we planned our presentation. We decided that everyone should work on the same parts of the presentation that they had worked on for the midterm presentation. Additionally, everyone should add their progress to their respective "Key Takeaways and Future Plans" slides.

4/11/24 -- Class Meeting

What We Did

• I started looking into the Transmission_simulator.py file.
• The file has two primary functions: create_broker(), destroy_federate(fed).
• create_broker() creates an initial string, creates a broker object, and initializes a boolean value "isconnected." The function returns the broker.
• destroy_federate(fed) disconnects the fed object that is passed into the function.
• After this, part of the code is registering the federate from json. To do this, the code is pulling from the "Transmission_json.json" file. With this information, a new fed object is created and its name, public keys, and subkeys are logged

4/4/24 -- Class Meeting

What We Did

• We got the ./run_example.sh to run.
• The commands we used to fix the bug are below.

Notes

• The commands used to clone the correct branch of gridlabd is below.
• cd cps-cosimulation-env/
• git fetch origin
• git status
• git reset --hard
• git checkout DPatel/setupinstructions
• git submodule update --recursive
• make gridlab-all-install
• nix develop
• make gridlab-all-install
• cd simple_gridlabd_example/
• ./run_example.sh

3/28/24 -- Class Meeting

What We Did

• The branch that fixes the bugs for running the simulation in the gridlabd GitHub repository is Bug Fix #1397.
• We need to create a pull request so that everyone has access to this branch.

Tasks

• Read through bay_controllers.py
• ./run_example.sh

3/14/24 -- Class Meeting

What We Did

• Continued to work on our respective subteam tasks
• I worked on running the ./run_example.sh. I was not able to fix it, as I was getting the same errors before with the cmake command. However, building we realized that there was a branch of gridlabd that had the proper fix. The next step was to pull from that branch so we could have the fixes on our local machine.

3/7/24 -- Class Meeting

What We Did

• Wireshark activity
• Situation: laptop connected to some unknown network. Took a packetcap for about 3 mins. Trying to figure our what is on the system.
• Discover a new IP Address
• Discover who is talking to who

Notes

• Saw no traffic outside 172. This might mean that it is not connected to the internet.
• Controller: sends information
• Might send sensor information, status codes, setpoints. The command will be a small packet. Command and status packets will probably be regular.
• HMI: human machine interface. A rack that has a screen and a keyboard. It is for an engineer to come and observe the system. The interface between the human and the machine. The connection between the human and the controller.
• Database
• HMI streams video data *224 typically means multicast. Multiple machines can be listening to the data going to the 224 address. The data belongs to the netwroking equipment. The newtorking equipment will duplicate the messages.
• 255 is broadcast message.
• Filter: ip.src==172.16.1.10
• 172.16.1.10 is an HMI
• Might have some robots, cameras, video, ROS2
• .10 cannot reach .194 ICMP protocol. Ublox creates wireless semiconductor modules.
• igmp manages multicast
• dhcp assigns ip addresses
• Ethernet controlls data link layer
• ip.src==172.16.1.31||ip.dst==172.16.31
• 6 robots
• arp
• .52 is doing vision process to find objects on the soccer field

3/6/24 -- Personal Work

• I continued reading through the code for the Process Level components under the process_level directory.
• protection_relays.py involves creating the template for protection relays. The ProtectionRelay class's constructor has the following instance variables: name, communication protocol, relay type, current rating, and voltage rating. The ProtectionRelay class's constructor passes the name and communication protocol to the super constructor. It then sets the relay_type, current_rating, and voltage_rating to the values passed into the constructor. The ProtectionRelay class defines the following functions: trip, reset, communicate. According to the documentation, the trip function is supposed to simulate the protection relay tripping. It sets the status variable, which is inherited from device.py, to "tripped." The reset function models the reset of the protection relay after tripping. It sets the status variable back to "active." The communication function simulates the communication behavior according to the communication protocol. It doesn't seem to have been implemented yet.

2/29/24 -- Class Meeting

• We presented our presentation.

Notes

• Some questions we got asked:
• What is our plan for deciding between Modbus and DNP3?
  • From what I remember, our answer was we will use reality as a metric. In other words, we will attempt to model our simulation protocol after what happens in real life.
• What is our plan for conducting fault testing?
  • We will simulate some erratic events in the code, such as a voltage drop. These programmed faults in the code will serve our simulation for now.

2/28/24 -- Personal Work

• I completed my part of the presentation, which was the introduction
• To get an idea of what this portion should look like, I looked through last semester's final presentation and midterm presentation.
• I noticed that the introduction slide included an explanation of the purpose behind our research as well as a restatement of our problem. Pacific Northwest National Laboratory's mission and how it aligns with our mission is also mentioned.

2/27/24 -- Supplementary Team Meeting
Tasks

• Complete my part of the midterm presentation (introduction)

What We Did

• We went over the kickoff presentation feedback
• We divided the presentation into separate parts like the introduction, device modeling progress, network protocol progress, etc.
• We discussed who should complete which part of the presentation

Notes

• Slides should not have too many words on them
• Emphasize the criteria for success and failure
• Keep the hypothetical situation in mind when presenting
• Introduction should frame the problem and provide an overview of our work this semester

2/20/24 -- Personal Work

Tasks

• Get an SSH key
• Pull fixed changes
• Run simple_gridlabd_example
• Read code

What I Completed

• I began reading through the code for the Process Level components under the process_level directory.
• process_device.py creates a new class ProcessDevice that extends from the Device class created in device.py. This class just calls to super constructor (which is in the Device class) and initializes the name and protocol to the values that were passed into the constructor.
• circuit_breakers.py involves creating the template for circuit breakers. The CircuitBreaker class's constructor has the following instance variables: name, protocol, max_current, is_closed, position, and trip_cmd. The CircuitBreaker class's constructor passes the name and protocol to the super constructor. It then sets the max_current to the values passed into the constructor. The is_closed, position, and trip_cmd instance variables are initially set to True, 0, False, respectively. The CircuitBreaker class defines the following functions: close, open, get_max_current, is_closed_status, trip. It also defines the following "getter" functions: get_node_name and get_status_data.

2/15/24 -- Class Meeting

Tasks

• Install Python
• Pull Gridlab-d code
• Begin understanding the python files under the process_level directory

What I Completed

• I successfully installed Python. While I had Homebrew on my system, running brew install python in the command line did not work. To fix this, I tried to first run brew update && brew upgrade. I found these commands at this tutorial: Homebrew Tutorial. While these commands successfully ran, running brew install python did not work again. So, I ended up installing Python from the Python website at this link Python Website. While this downloaded Python, I also needed to install Xcode tools. I installed this using the command given by the terminal. After this, I was able to successfully install Python.
• After installing Python, I attempted to run the simple_gridlabd_example. My first issue was that I was running nix develop only within this directory. To fix this, I ran cd.. to go one directory up. However, when I ran bash run_example.sh, it would not run. We discovered that since I had an M1 chip, gridlabd would not run well on my system. However, gridlabd posted a fix for this last semester. The fixes were simply not merged into the branch that I cloned. Therefore, one member will submit a pull request to the fixed repository and push it to our current branch. After this, I will be able to pull and have the fixes, so that I can run the simple_gridlabd_example.
• Below are the procedures we took to submit a pull request to the fixed repository.

Go to terminal
Git checkout
Copy blue url
Git pull
Git checkout [url]
Git status
Git stash
Git checks [url]
Go up a directory
Git status
Change directory to grid lab-d
Git status
Git remote -v
Git remote add upstream
——
Git checkout git upstream
Git status
Git push origin bugfix-
Git checkout -v macos
Git status

2/8/24 -- Class Meeting

Tasks

• Install Python
• Pull Gridlab-d code
• Read code

What I Completed

• Successfully pulled the helics and gridlabd code.
• I began looking at the code base. Looking through the device_modeling directory, I found the directory_structure.txt file, which will be helpful in understanding the organization of the code. I started looking into the device_base directory and the the device.py python file within that. From what I can understand, this is the base class (or a template) for all of the devices that have been created so far. It has six different functions: init, activate, deactivate, get_status, get_device_name, and get_communication_protocol. These functions will be inherited by the child device classes since they will all require this basic functionality. The init function acts like a constructor and initializes all the instance variables of the Device class. Name and protocol are initially set to the values passed into the init function. Status is initially set to "Inactive." The instance variables are name, protocol, and status. The activate and deactivate functions act as "setter" methods and set the status as "Active" and "Inactive," respectively. The get_status, get_device_name, and get_communication_protocol functions acts as a getter functions for the status, name, and protocol instance variables, respectively.

device_modeling/
│
├── documentation/
│   ├── requirements.txt                       # Project dependencies list
│   └── README.md                              # Project documentation
│
├── simulations/
│   ├── helics-config.json                     # Configuration file for HELICS co-simulation
│   ├── gridlab-d-config.glm                   # Configuration file for GridLAB-D co-simulation
│   ├── run_simulation.py                      # Python script to execute the co-simulation
│   └── results/                               # Directory to store simulation results
│
├── src/
│   ├── device_base/
│   │   ├── device.py                          # Base class for devices
│   │   └── ...
│   ├── process_level/                         # Layer 1: Process Level components
│   │   ├── process_device.py                  # Base class for process-level devices
│   │   ├── circuit_breakers.py                # Implementation for Circuit Breakers
│   │   ├── relay_house.py                     # Implementation for the Relay House
│   │   ├── protection_relays.py               # Implementation for Protection Relays
│   │   ├── sensors/                           # Directory for Sensors (CTs and VTs)
│   │   │   ├── sensor_device.py               # Base class for sensors
│   │   │   ├── current_transformer_sensor.py  # Implementation for Current Transformers (CTs)
│   │   │   └── voltage_transformer_sensor.py  # Implementation for Voltage Transformers (VTs)
│   │   ├── transformers/                      # Directory for Transformers
│   │   │   ├── transformer_device.py          # Base class for transformers
│   │   │   ├── distribution_transformer.py    # Implementation for Distribution Transformers
│   │   │   └── power_transformer.py           # Implementation for Power Transformers
│   │   └── ...
│   ├── bay_level/                             # Layer 2: Bay Level components
│   │   ├── bay_device.py                      # Base class for bay-level devices
│   │   ├── bay_controllers.py                 # Implementation for Bay Controllers
│   │   ├── switchgear.py                      # Implementation for Switchgear components
│   │   └── ...
│   ├── station_level/                         # Layer 3: Station Level components
│   │   ├── station_device.py                  # Base class for station-level devices
│   │   ├── station_gateway.py                 # Implementation for the Station Gateway
│   │   ├── human_machine_interface.py         # Implementation for Human-Machine Interface (HMI)
│   │   └── ...
│   ├── common/                                # Common components shared across layers
│   │   ├── modbus_interface.py                # Implementation for Modbus communication
│   │   ├── dnp3_interface.py                  # Implementation for DNP3 communication
│   │   ├── iec61850_interface.py              # Implementation for IEC 61850 communication
│   │   └── ...
│   └── main.py                                # Main Python script to orchestrate the simulation
│
├── tests/
│   ├── unit_tests/                            # Directory for unit tests
│   │   ├── circuitbreaker_unit_test.py        # Unit test file for Circuit Breakers
│   │   ├── baycontroller_unit_test.py         # Unit test file for Bay Controller
│   │   └── ...
│   ├── integration_tests/                     # Directory for integration tests
│   └── formal_verification/                   # Directory for formal verification tests
│
└── data/                                      # Directory for storing data or configuration files
   ├── test.csv                               # Sample data file
   └── ...

2/7/24 -- Personal Work

Tasks

• Install Python
• Pull Gridlab-d code
• Read code

What I Completed

• Tried to install Python
• Getting error in image below

2/1/24 -- Class Meeting

Tasks

• Install Python
• Pull Gridlab-d code
• Read code

What I Completed

• Went through the README
• Pulled Helics code

1/31/24 -- Personal Work

Tasks

• Pull Helics code
• Pull Gridlab-d code
• Read code

What I Completed

• Clones repositories of cps-cosimulation-env

1/28/24 -- Supplementary Team Meeting

Tasks

• Look at GitHub
• Clone repositories of cps-cosimulation-env
• Get simulation example working
• Go into Distribution, Transmission, Relay and understand .py files

1/25/24 -- Personal Work/Class Meeting

What I Completed

• Created notebook
• Practiced my part of introductory presentation
• Delivered my part of introductory presentation

1/18/24 -- Class Meeting

What I Completed

• Listened to kickoff presentations
• Decided what subteam I'd like to be on
• Shared availability for supplementary team meetings

1/11/24 -- Class Meeting

What I Completed

• Listened to overview of VIP project
• Joined VIP Discord