• Work on the final presentation and record slides
• Compile progress across the sub team to update slides
• Final paper

This week we met as a sub team and compiled our progress in terms of technical work. Ethan and I sent over the code we worked on regarding fault detection and anomaly detection to see if we could combine our progress and get our code to run in the cosimulation. One thing that I want to work on in the future is figuring out how to pull the simulated faults from grid lab-d and run the threshold logic on those faults. We also began working on the final paper which is due next since classes are now over.

• Find a better way to log faults

This week I wanted to figure out a better way or a written function to log faults instead of just having the timestamp conditional and the log faults addition in the federate. I tried seeing if I could just make a python function to do this instead, the only setback was that I didn't know where to put this or how to integrate it with the other files.

Here is what I started to look at:

import os from datetime import datetime

def log_faults(faults, time_step=None):
    if not faults:
        return

    with open(FAULT_LOG_FILE, "a") as log_file:
        for fault in faults:
            timestamp = f"Time {time_step}" if time_step is not None else datetime.now().isoformat()
            log_entry = f"[{timestamp}] {fault}\n"
            print(log_entry.strip())  # Optional: Console debug
            log_file.write(log_entry)

This would create a sample output for the logs looking something like this:

[Time 180] Voltage dip (below standard)
[Time 240] Voltage anomaly (statistical deviation)
[Time 300] Severe overvoltage! Potential fault.

• Potentially work on timestamp information for fault detection
• Continue working on simulator and seeing what else to add

I wanted to see if for the logging portion of the fault detection I could somehow simulate the timestamp or add a feature to display the timestamp. I ran into some issues when figuring out where to place the following code:

if time_step is not None:
        current_faults = [f"[Time {time_step}] {fault}" for fault in current_faults]

I wasn't sure if this code should be in the simulator file or the Helics federate considering that the Helics federate has the other data logging code.

Spring Break! We had no meetings this week.

• Add anomaly detection to the simulator file

Now that I have a skeleton or outline of the fault detection logic regarding the parameter thresholds for current and voltage swells or dips, I wanted to add some logic that would detect anomalies in the substation. This required me to go back into the papers we were looking through last semester as background research.

Here is some of the baseline code:

  if len(baseline_data) >= 3:
        mean = statistics.mean(baseline_data)
        stdev = statistics.stdev(baseline_data)
        lower_bound = mean - 2 * stdev
        upper_bound = mean + 2 * stdev

        if current_pos < lower_bound or current_pos > upper_bound:
            current_faults.append("Voltage anomaly (statistical deviation)")

• Fix simulator file

The main goal for this week was to add more to the Monitoring_simulator.py file to see if I could fully implement the fault detection logic and thresholds as we discussed in the meeting 2 weeks ago with our advisor. That way I could then see if we could connect with the ROS/Helics team to work on implementing the simulated gridlab-d faults.

Here is some code I changed up and added: import statistics

def analyze_voltage(data, time_step=None):
    current_faults = []

    standard_min = 0.95
    standard_max = 1.05
    absolute_min = 0.90
    absolute_max = 1.10

    current_pos = data[-1]
    baseline_data = data[:-1] if len(data) > 1 else data

    # Threshold-based checks
    if current_pos < standard_min:
        current_faults.append("Voltage dip (below standard)")
    elif current_pos > standard_max:
        current_faults.append("Voltage swell (above standard)")

    if current_pos < absolute_min:
        current_faults.append("Severe undervoltage! Potential fault.")
    elif current_pos > absolute_max:
        current_faults.append("Severe overvoltage! Potential fault.")

• Work on Midterm presentation
• Fix simulator

This week we had our midterm presentation so that main goal for the week was to finish up the slides for that and also record our slides since we are all virtual members. My assignment was to do the first tasks slide and then also record that. Here were the tasks I was working on:

1. Task 1 - Co-simulation Scenario Design: Write framework code for specific error scenarios based on a device to ensure that HELICS can react to it. Add to current HELICS federate and integrate with other files
2. Task 2 - Implement Real Time Data Monitoring Enable live time data visualization and data recording for analysis within the co-simulation environment.

• Meet on Saturday to determine next steps
• Send federate out to the rest of the team so they can work from there
• Fix simulator file
• Finish midterm paper

This week we met on Saturday so that I could get Dhruv and Ethan caught up on my Helics federate progress. I also wanted to add the code I wrote from 2-3 weeks ago into the federate to implement the logging functionality for the fault detection:

voltage_history.append(current_voltage)
faults = analyze_voltage(voltage_history, current_time)

if faults:
    for fault in faults:
        print(fault)
        with open("fault_log.txt", "a") as f:
           f.write(fault + "\n")

• Implement simulator into federate.
• Have a meeting with advisors to discuss better communication
• Fix simulator file
• Work on Midterm paper

This week we had a meeting with the device modeling sub team advisor on 2/15/25 and got some advice on where to go for the Monitoring sub team as well as how we can stay up to date with the in person members. Here are some of the notes from the meeting:

• look into anomaly detection
• receive values from fault creation from grid lab d and check if they fall out of a range of values which means it is a fault
• ros helics figured out how to get grid lab d to model the faults
• fix helics federate

Following the meeting, as a sub team we just worked on finishing the midterm paper and adding in our research that we completed for the first half of the semester as well as finishing the conclusion section which is what we were tasked with. We did not have any technical progress this week due to the paper.

• Continue working out logic to simulate fault detection.
• Organize a meeting with advisors or rest of the team to be caught up.

Our sub team has been feeling out of the loop on the rest of the team's progress lately because none of us are in person nor can we make the virtual meeting on Fridays, so we want to figure out a way to communicate with everyone else rather than just Discord.

I continued working on fault detection however I did not run my previous code because this was simply placed in the Monitoring_simulator.py file without anything else. Instead I used the research from last semester to find thresholds for the fault detection and wrote this code for the simualator:

def detect_fault(total_load, previous_load, currentA, currentB, currentC, voltage):

    faults = []

    # Sudden load change

    if abs(total_load - previous_load) / max(previous_load, 1) > 0.5:

        faults.append("Sudden load change (>50%)")

    # Current imbalance (simple L-L or L-G fault detection)

    imbalance = max(abs(currentA - currentB), abs(currentB - currentC), abs(currentC - currentA))

    if imbalance > 100:  # Customize threshold

        faults.append("Phase current imbalance")

    # Voltage abnormality

    if abs(voltage) < 0.8 or abs(voltage) > 1.2:  # per-unit voltage range

        faults.append("Voltage out of range")

    return faults

• Begin working out logic to simulate fault detection.

This week I started to look through the code we already had and tried to use the past research and papers that we had looked through in other semesters to work out some code for logging fault detection without any logic tied to it yet.

This is what I began with:

faults = detect_fault(load, last_load, currentA, currentB, currentC, voltage)

if faults:

with open("fault_log.txt", "a") as f:

    f.write(f"[Time {current_time}] Faults Detected: {faults}\n")

• Discuss next steps with Ethan and Dhruv
• Communicate with in person members

The in person members presented the kickoff presentation and said the feedback was good! Since the Monitoring sub team has not gotten a chance to plan out exactly what work we are going to start / continue off of for this semester, that is what I plan on doing when communicating with Ethan and Dhruv this week.

A good first starting point would be to continue working on the Helics federate I started last year and also continuing research on potential faults. I also aim to ask the ROS/Helics team how we can integrate with them.

• Kickoff Presentation

After finalizing the sub teams and getting new members introduced to the project, we were introduced to the Kickoff Presentation. We decided to divide up roles for who would work on each slide depending on their sub teams and what they did last semester.

I was in charge of completing the Monitoring sub team Tasks slide and also recording my presentation. I added some details from the feedback we received after the final presentation last semester which included working with the ROS/Helics team.

This was the first meeting of the semester. I am a virtual student this semester so I had to reach out to my old team members and new members on the team that do attend in person to get caught up. The only thing that was discussed was an introduction to the research and past work.

We filled out a form for all members and decided on an additional meeting time for the sub team. We picked Fridays.

Planned out the kickoff presentation and assigned slides to each team member. I was in charge of the monitoring sub team slides, specifically the goals, tasks, and resources we need to get the new members caught up.

We presented our kickoff presentation. Some key takeaways are that the monitoring sub team might combine with the ROS/HELICS monitoring sub team to work on similar goals, as well as finding a starting point for the monitoring sub team since this is a new focus/task this semester.

1. Run the simple gridlab d example to make sure the updates from last semester still work.
2. Catch up new members on sub team.

Attempted to run nix develop but was getting an error that send the command did not exist. I tried to find a quick fix for this by checking my existing files that I used last semester.

Realized that after a macOS update, some nix files got erased, so we created a new zshrc file and added the following:

if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then . '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' fi

This was found through the source: https://www.reddit.com/r/Nix/comments/11ynxa5/every_macos_update_needs_me_to_rerun_the_nix/

After running again, I realized another issue was the my terminal was in bash so we changed to z shell to properly run nix develop.

1. Continue to get new team members up to speed.
2. Organize sub teams and tasks.

After a team meeting, we created a task board to organize our goals better.

What we did:

1. Created Trello board and added tasks
2. Assigned members to tasks and broke out into sub team groups

The monitoring sub team is going to start with researching basic substation features and details to get a better sense of what we need to simulate. We also wanted to brainstorm potential faults that could occur and plan those out by considering how to detect problems.

Began looking through the different substation components such as the circuit breakers, voltage regulators, transformers, and capacitors, and what factors they each rely on to get a greater understanding of what the monitoring technical work will look like. I used: https://epe.pnnl.gov/pdfs/Distribution_system_infographic.pdf

• Circuit breakers: an electrical safety device designed to protect circuits from damage that could be caused from overcurrent, overload, or short circuits. The main job is to continuously monitor the current flowing through the circuit. There is a trip mechanism designed to determine if the current exceeds a threshold that could damage the circuit.
• Voltage Regulator: a device in a circuit that maintains a constant output voltage level regardless of load conditions. There are linear voltage regulators or switching voltage regulators which are more efficient and better for high-power circuits.
• Transformer: a device that transfers energy between circuits using electromagnetic induction. It is used to change voltage levels while maintaining the same frequency.
• Capacitor: a component that stores and releases energy in a circuit. The key properties are capacitance and voltage rating which is the maximum voltage it can handle without breaking.

1. Continue research on substation device factors and potential faults or issues that could arise due to equipment, etc.
2. Meet with sub team on Sundays to report progress and set new goals.

Researched more with the sub team on the common problems that arise within substations specifically due to equipment. The main factors that played into this were insulation breaking down, overheating, and mechanical wear. We also identified some methods that could be used to detect these issues.

1. Monitor fluctuating temperature, current, or voltage levels.
2. Use circuit breakers to try and distinguish abnormal conditions from normal conditions. The circuit breaker would accomplish this by interrupting the current of any overloaded circuits, short circuits, or ground faults. This could be detected by recognizing drops in power output, any interruptions in the power supply, or abnormal use of the equipment.

We considered merging the monitoring subteam or atleast combining our work and progress with the ROS/Helics sub team because they were mainly focusing on fault detection and implementing this as one of their main goals for this semester. Since this is one of our sub team's tasks we thought it would make sense to collaborate at some point.

Also researched another potential issue with the substation which is transformer overloading. This can be described as high demand on power supply systems. The way to detect this issue when writing our code would be to implement a method that would load monitoring systems to then detect any signs of high power flow. A way to identify that there is an issue would be to detect transformers that are overheating based on the temperature parameter, check for any system alarms triggered, or detect any unstable voltage levels.

1. Continue research on potential faults for the substation to help write the code.
2. Potentially coordinate with the ROS/Helics sub team on fault implementation.
3. Divide the midterm paper section and work on writing it.

Mainly worked on the midterm paper and changing the sections around to include the monitoring sub team and our future goals and current research that we are doing on potential faults.

Researched further on protection system faults and failures. Identified that key failures were relay malfunctions, communication failures, and CT/PT issues.

Also discussed with the monitoring sub team that we need to get started on technical progress and utilize the research we have done so far.

1. Brainstorm ways to begin technical progress.
2. Continue researching further in depth on the protection system failures since we have already implement relay scripts in the past.

Discussed how to break up the midterm presentation and presented any progress made per sub team. Not much work was done since this week was fall break.

Fall break so no progress during this week.

1. Work on assigned slides for the midterm presentation as a whole team.
2. My personal goal was to check in with the entire monitoring subteam and make sure everyone's progress was reflected in the tasks slide which is what I was responsible for.
3. Continue trying to make some technical progress.

Fall break so we did not have our usual Sunday meeting. Everyone just worked on the midterm presentation on their own.

Presented the midterm presentation (I presented the goals and tasks slides) and received feedback:

1. The monitoring sub team should work with the ROS/Helics team at some point because we have very similar goals for this semester.
2. The next best step to make technical progress for monitoring is to try and create a new python Helics federate to set up the rest of the code.

1. Plan steps to write code
2. Delegate research tasks

Continued to research more on the protection system failures:

• Relay Failure: This usually occurs when the a relay component fails which leads to misoperation and a power system breakdown.
• Communication Failure: This system includes the power line carrier and fiber optic systems. Potential problems can range from channel delays, buffers, channel switching, or interruptions due to equipment problems. This can cause data transmission errors or data loss. Source: https://ieeexplore.ieee.org/document/9375616

The devices sub team also shared a helpful document which compiles some of the research and work they have done on each substation device that we could then use to help us with the monitoring code because we need to determine which parameters are useful to us. https://docs.google.com/document/d/1ZtMHdJov7VZr7buOC4va_Zk-f20rds6Tm4KKx0wQjzo/edit?usp=sharing

We discussed the best way to start the Helics python federate or the JSON files for monitoring and where to get ideas on how to start. These are some of our combined ideas:

• compare and contrast any errors
• monitoring physical parameters from other device models that we are receiving from grid lab d
• look to see if they make sense in a larger context
• research potential physical parameters: energy, electricity conservation
• transmission lines and distribution lines: if current and power on transmission, then distribution should have current and power
• randomly inject faults using grid lab d
• reach out to ROS HELICS subteam for the faults

1. Get started on writing code
2. Reach out to ROS/Helics
3. Continue researching if necessary

Mainly checked in with other group members on their progress and seeing how I could build from there. We combined our research to see what everyone had collectively compiled. I also created a new JSON filed in the simple_gridlabd_example folder called Monitoring.json.

I begin working on the JSON file by first looking at the previous files that already exist within the folder and then adding to Monitoring.json:

`"coreInit": "--federates=1",

"coreName": "Monitoring Federate",

"coreType": "zmq",

"name": "Monitoring",

"offset": 0,

"period": 60,

"timeDelta": 1,

"logfile": "output.log",

"log_level": "warning",

"uninterruptible": true,`

1. Continue working on code files and potentially add more.
2. Share progress with new members on the monitoring sub team.

The next thing I worked on adding to the JSON file was the publications. After discussing with the sub team and then looking back through the background research I did, we decided that one of the most important parameters to include is the voltage level. I continued to look more into how this could be used to monitor the substation since fault detection is mainly done through the voltage changes.

I added the publication code to Monitoring.json:

`"publications": [

        {

        "key": "Monitoring/transmission_voltage",

        "type": "complex",

        "global": true

        }

]`

1. Continue working on code files and potentially create a new federate.
2. Add to background research on faults.

I then researched and looked through already existing files to learn how to add the subscriptions section for the file. We realized the current is also an important parameter to include as a baseline so we used total load for the subscription.

I worked on adding the subscription code to Monitoring.json:

`"subscriptions": [

    {

    "key": "IEEE_123_feeder_0/totalLoad",

    "type": "complex",

    "required": true

    }

]

1. Divide slides for next week's final presentation.
2. Take pictures of code progress for the slides.

Divided up slides for the final presentation and created new slides to add our new progress from this semester. Mainly worked on completing my slides and checking over the rest of the sub team's to make sure everything aligns.

We presented our final presentations for the semester. I presented the tasks slide and showed the tasks we completed this semester as well as the tasks we aim to work on next semester. I showed a snippet of the JSON file rough draft I started working on for monitoring. I also proposed combining this sub team into the ROS/Helics team for next semester to avoid duplicate work.

1. Divide work for the final paper and submit the paper by Dec 4
2. Complete peer evaluation
3. No more meetings for the semester

• Discussed CPS basis concepts
• Explored the two sub teams: ROS/HELICS and Device Modeling
• Completed the Welcome Survey and joined the CPS Discord server and Github

• Discussed Kickoff Presentation requirements and future presentation dates.
• Split into sub team groups and reviewed where the team left off last semester and what this semester's goals are.
• Picked a secondary meeting time: Sunday around 1pm. This is to plan the Kickoff Presentation.
• Learned about what goes into making a simulation from scratch. Continuous processes are modeled discretely on computers. Time stepping and picking the appropriate time for different simulations.
• Discussed how HELICS runs 3 simulators: Grid Lab D, ROS2 and Gazebo, and PyPower.

• Had a remote meeting with the Device Modeling subteam.
• Planned the kickoff presentation by dividing slides between members, looking at past presentations as a guide and choosing which subtask we are going to work on for the semester.
• Aiming to finish my slide (Conclusion slide) by Wednesday night.

• Practiced Kickoff Presentation with team before VIP meeting.
• Presented Kickoff Presentation and received feedback such as equally splitting up the subteams. Spring 2024 Kickoff Presentation: Device Modeling

Online Meeting Notes:

• Goals before Thursday: Run HELICS simulation, Clone repository, read the READ ME for the GitHub page and follow instructions.
• Directory: cps-cosimulation-env > gridlabd testing environment > Transmission_simulator.py
• Run simple_gridlab_example, run_example_sh, Relay, Transmission Distribution folders, understand how they work by looking at code

Spent the entire meeting following the Read Me on the git repo and trying to get nix installed. In terms of steps and commands that I managed to get through:

The main error I keep running into is when running the command make all: I attempted to fix this by clearing out the HELICS and gridlab-d folders of any build folders or extraneous items, but this didn't work.

Tasks:

• Build HELICS and gridlab-d
• Run example files

What I did: Worked through trying to build HELICS and gridlab-d and realized that Mac has a .DS_Store file that was preventing the command make all-install and git submodule update from running. Once we deleted those files from gridlab-d and HELICS, I was able to build both of them with the command make all-install.

Tasks:

• Run simple gridlab-d example

What I did: Tried to run the "simple gradlab-d example" files but was running into the error of "python not found". I knew that nix gets python onto your computer but I couldn't figure out how to fix this issue so I began looking through the "Transmission_Simulation.py" file.

In this session we worked on fixing the python issues that prevented the example from running.

1. First check if python was on my Mac by running the command python
2. Navigate to cd poetry.lock which is where we located python
3. Now when running the bash run_example.sh the example begins to run but takes too long so I had to stop it by using control z.
4. We then started a new branch on the repository called macOS_fix and pushed changes to GitHub.

1. I had to figure out how to connect my SSH key onto GitHub first so I used https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account

Worked on the research paper by looking at last year's paper and then changing a few things so they are updated for this semester. I was responsible for the executive summary portion.

I ran bash run_example.sh and now I am getting the error no module name 'scipy' and that I need to import spicy.io as spio

We realized that the reason why I was getting an error was because we accidentally pulled the wrong gridlab-d version from the repository, so we worked on pulling the correct version and pushed those changes to the macOS_fix branch. These are the commands we used to pull from the fixed repository:

1. Go to terminal
2. Git checkout
3. Copy blue url
4. Git pull
5. Git checkout [url]
6. Git status
7. Git stash
8. Git checks [url]
9. Go up a directory
10. Git status
11. Change directory to grid lab-d
12. Git status
13. Git remote -v
14. Git remote add upstream
15. Git checkout git upstream
16. Git status
17. Git push origin bugfix-
18. Git checkout -v macOS
19. Git status

This week we worked on our midterm progress presentation. We decided to create a new sub team dedicated to Monitoring which will be the focus of our progress for next semester. I was allocated the task of the conclusion and references slide.

We presented our midterm presentation in class. Some of the questions we got asked were regarding our plans for Modbus and DNP3, as well as conducting fault testing. We responded to the plan for fault testing by saying that our Monitoring subs team will handle this.

We did a red teaming packet capture activity in Wireshark. Takeaways:

• Look at the source to get a sense of where the packets are coming from.
• Commands tend to be small packets and data would be large packets.
• HMI: Human Machine Interface, for engineers to observe the state of the substation, collects information from the controllers and displays it
• 224 is a special type of IP address because multiple machines can listen to the data

Tasks:

• Continue reading through Python files

What I did: Notes about the circuit_breakers.py script

• Constructor includes instance variables for name, protocol, max_current, is_closed, position, and trip_cmd.
• The circuit breakers class also has the following methods: close, open, get_max_current, is_closed_status, and trip. There are additional getter methods.

Tasks:

• Continue reading through Python files

What I did: Notes about protection_relays.py

• Constructor includes instance variables for name, communication protocol, relay type, current rating, and voltage rating.
• The class contains the following methods: trip, reset, communicate.
• The trip method simulates the protection relay tripping by setting the status variable to "tripped". The rest method reverses this process by setting the status variable back to "active".

Tasks:

• Pull from BugFix branch
• Continue reading through Python files

What I did:

• We found the branch that has the fixes for the grid lab-d simulation: BugFix#1397.
• We created a pull request from this branch onto macOSFix.

Notes about process_device.py

• ProcessDevice extends the Device superclass. The only instance variables are name and protocol, which are initialized through the superclass's constructor.

Tasks:

• Run the example file
• Push fix changes to branch

What I did: We got the simple_example.sh to run by using the following commands to get the correct gridlab-d simulation.

• cd cps-cosimulation-env/
• nix develop
• git fetch origin
• git status
• git reset --hard
• git checkout DPatel/setupinstructions
• git submodule update --recursive
• make gridlab-all-install
• make gridlab-all-install
• cd simple_gridlabd_example/
• ./run_example.sh

This week I just continued reading through the Python files. I focused on and Relay_simulator.py and Transmission_simulator.py since the example now ran on my computer.

I began looking through the powerflow.ml files, including server.py and gnn.py to get a better understanding of the simulation.

This week we only worked on the final presentation. I completed my part which was the Monitoring sub team slides and the conclusion slides. We presented this in class on 4/18/24.