Welcome to my Virtual Notebook for VIP: Cyber Physical Systems!

• Engaged in an in-depth discussion on the foundational principles of Cyber Physical Systems and introduced the overall methodology and structure behind the teams.
• Explored the vast and intricate dynamics within the two sub-teams: ROS/HELICS and Device Modeling.
• Successfully completed the Welcome Survey, thereby gaining access to the Cyber Physical Systems Discord server, and attempted to access the GitHub Organization/Repository.
• Addressed rising concerns and questions about future work.

To Do List:

• Read over criteria/rubric for kickoff presentation.
• meet with subteam to pick and give roles for the presentation.

• Deliberated upon the stipulated requirements for the Kickoff Presentation and identified the dates alongside our roles.
• Established meeting times to Sundays around 1 PM to coordinate efforts for planning the Kickoff Presentation and future tasks. To Do List:
• work on my portion of the kickoff presentation: specifically I have to research the vast technologies and their purpose within our projects.
• Compile list of sources needed for presentation.

• Facilitated remove meeting with the Device Modeling sub-team.
• Assigned deliverables to each individual member.
• Researched the vast technologies utilized by each sub-team, specifically focusing on HELICS, Grid Lab D, PyPower, delineating their individual purposes, and compiled them into a single document.
• Effectively coordinated and delivered deliverables by Tuesday night to provide adequate time in preparation for live presentation.

Introductory Information: MODBUS: https://www.csimn.com/CSI_pages/Modbus101.html DNP3: https://www.dpstele.com/dnp3/index.php Pypower: https://pypower.readthedocs.io/en/latest/ Git & GitHub: https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners

• Rehearsed Kickoff Presentation with the Device Modeling team prior to the virtual meeting.
• Delivered Kickoff Presentation while securing valuable feedback.

• Outlined objectives to be fulfilled before the physical meeting, including cloning the repository on local device and executing the HELICS simulation (README document was assigned to read for brief background information).
• Reviewed basic notebook setup via provided link on discord.
• Assigned tasks to perform before the physical meeting including executing the run_example_sh and simple_gridlab_example files.

• Began developing/installing the nix environment and
• Nix: program that establishes other programs, and runs everything we need to develop the codebase (such as c and c++ compilers), environment defined the flake.nix file.
• once inside the run make all -> installs and develops HELICS and GridLab-D
• make all command in terminal skips the download for HELICS but not GridLab-D

• Began class by addressing pressing concerns related to gridlab-d installation.

1. If you receive a zsh: command not found: cmake error when attempting to cmake ../ -DCMAKE_INSTALL_PREFIX=../../install -DGLD_USE_HELICS=ON -> make sure you correctly installed nix using the nix develop command.
2. To check, I ran nix develop in the cps-cosimulation-env folder, and if you properly installed it/or installed it in general you should receive/output:

• Installing dependencies from lock file
• No dependencies to install or update.
• You can also check the location/if you're in the correct nix environment by running the which make command (in the same cps-cosimulation-env folder). If you're in the proper environment you should receive: /nix/store/assortment of numbers and letters-cmake/bin/cmake Note: There might be a slight difference in the return statement for each user; however, the key is the /nix/store/ (<- that is not a command, it's and output).

3. Then rerun the commands in the following order:

• cd gridlab-d

• mkdir build <- if you already ran the command the terminal would return "mkdir: cannot create directory build: File exists", don't worry, it means the file/folder was already developed -> continue with the commands.

• cd build

• cmake ../ -DCMAKE_INSTALL_PREFIX=../../install -DGLD_USE_HELICS=ON

• Now I received an error stating `/Users/myusername/desktop/cps-cosimulation-env/gridlab-d" does not appear to contain CMakeLists.txt.

• What we did afterward was we:

• deleted junk files processed and developed by mac

• pushed and committed changes to the original repository.

• changes: deleted and removed unnecessary instructions (since we alter the submodule for examples that was maintained/removed the submodule from its location and it resolved the error with the make all command).

• Now the make all command properly develops and compiles the necessary files, and the make all-install command correctly deposits the resulting files into a folder, within a directory, to which the computer and user can access.

To Do List:

• Begin journey with python.
• Python is very similar to java so you can breeze through the fundamental mods such as variables.
• Go over basics in python and compare to javas implementation.

• This week marked the beginning of my journey with Python. I delved into various resources to kickstart my learning process, including but not limited to:

• Utilizing the beginner documentation at https://docs.python.org/3/tutorial/index.html.

• Engaging in basic practice sessions at https://www.w3schools.com/python/.

• Exploring concise learning materials found at https://do1.dr-chuck.com/pythonlearn/EN_us/pythonlearn.pdf.

As I transitioned from Java, the initial disparities between the two languages became apparent:

• In Java:

• Printing statements/functions: System.out.print(), System.out.println(), System.out.printf()

• In Python:

• Printing is simplified to the print() function.

• Retrieving the type of object/data stored in a data type is accomplished using the type() function. For example, type('Hello, World!') would return str. Notably, Python employs single quotes (' ') to denote strings, differing from Java where single quotes represent characters (char: ' ').

• Additionally, I progressed through Chapter 2: Variables, expressions, and statements in the book "Python for Everybody" (pdf).

To Do List:

• Work on my part of the research paper.
• Implement the Enhanced Device-Communication Integration section.
• Reread old presentation along with other articles to understand concepts discussed.

• During this week, I worked on my portion of the research paper. Specifically, I had to implement the Enhanced Device-Communication Integration section.
• My contributions:
• A. Enhanced Device-Communication Integration
• Our ongoing research endeavors are focused on the continual implementation of the Modbus protocol as the primary communication protocol within the intricate smart grid infrastructure. Modbus remains at the forefront of our efforts, serving as a foundational block for establishing communication among various grid components. Not only does it support various data types allowing diverse application requirements, but its simplicity proves to be crucial as it eases the implementation phase. As we delve deeper into our research, we are also continuing the integration of more advanced protocols, such as DNP-3, to further enhance our communication framework. While initially considering the implementation of IEC 61850, we encountered functional complexities that prompted us to reassess our approach. Consequently, we decided to terminate our usage of this protocol and focus our attention on DNP-3, which offers heightened security measures better aligned with the demands of the smart grid ecosystem [15].
• The usage of the PyModbus library underscores our current endeavors aimed at creating models that facilitate seamless communication among smart grid devices. This adaptable Python library serves as a crucial stepping stone towards the integration of more sophisticated and secure communication protocols [16]. Our transition from Modbus to protocols like DNP-3 in subsequent research phases is strategic, as it enables the development of a comprehensive and adaptable communication framework tailored to meet the evolving cybersecurity needs and complexities within the grid environment. This approach aligns with industry trends and ensures the continued evolution and resilience of the smart grid’s communication infrastructure.

To Do List:

• Work on my part of the midterm presentation.
• Use potential scenario to work on monitoring slide and explain how we plan to develop it in the future.
• learn the basics associated with what the scenario encompasses to obtain a fundamental understanding of topic.

• During this week, I dedicated my efforts to my section of the midterm presentation. Specifically, my task involved developing the monitoring slide. I concentrated on leveraging our previously outlined potential scenario to track the advancement in monitoring the performance and consistency of co-simulation environments amidst faults and unforeseen occurrences.
• My contributions:
• Scenario:

1. Initial State (3:00): Co-simulation in state of normal operation, network voltage levels maintaining stability.
2. Simulated Fault (4:00): introduce a simulated fault (Ex: power surge) to assess systems response.
3. DNP3 Communication for Fault Information (5:00): Use DNP3 protocol to share fault information, helps environment automatically disconnect affected lines.
4. Fault Recovery (6:30): system properly recovers from fault, voltage levels gradually return to normal.
5. Load Increase (7:30): unforeseen event generates load decrease, increasing voltage levels.
6. Modbus Communication for Voltage Adjustment (7:35): Use Modbus protocol to deploy communication between the Bay Controller and the main transformer, adjusts tap setting to restore voltage levels.
7. Tap Setting Response (8:00): transformed responds to tap setting set by Bay Controller, restores voltage levels to normal.
8. End State (9:00): simulation concludes with equipment monitoring voltage levels ensuring stability. Future Plans:

• Develop python scripts to aid us in our efforts to monitor the co-simulation environment as it faces and resolves unforeseen incidents and faults.
• Log changes occurring within the environment to provide a live feed of the ever changing environment in its efforts to facilitate stability.

To Do List:

• Continue working throughout the python book.
• begin working on functions module
• learn basic functions using list examples
• engage with math module
• work on any tasks given in class.

• This week I started the functions module within the book.
• Notes:
• Finding the maximum and minimum values in a list using the max() and min() functions. max() returns largest character in string, min() returns smallest character in string. `>>> max('Hello world') 'w'

min('Hello world') ' '`

• len() : returns number of items in its argument/parameter list, >>> len('Hello world') 11

• This string contains 11 characters including the space.

• Type Conversion Functions:

• int() : can turn a string with a integer value present into an actual integer `>>> int('32') 32

int('Hello') ValueError: invalid literal for int() with base 10: 'Hello'`

• The reason the 2nd portion is invalid is due to the string input. If it was an integer representation of a string, as displayed in the previous example, it would actually return an integer.

• Python has built in math functions; however, these are limited to certain operations. If we want to utilize the full range of operation that python has to offer for mathematical computations we need to import the math module (not class). In python, we import modules (file containing python definitions and statements. Modules can also contain classes, functions, variables, or runnable code. importing it practically imports its contents within your current file) not classes.

• import math -> imports math module for operations such as math.sin() -> Ex: math.sin(0.7) => 0.64421768.

• import random -> imports random module generating pseudorandom numbers between 0.0 and 1.0. It works similarly to the java random class. However, in java you need to make a random object to generate the numbers and initialize the variables with that random number.

• Ex in java:

• import java.util.Random;

• Random rand = new Random();

• int num = rand.nextInt();

• We also covered a red teaming packet capture activity in wireshark:

• An IP address like 224 is unique because multiple machines can receive data through it.

• HMI, or Human Machine Interface, serves as a platform for engineers to monitor the substation's status. It aggregates information from controllers and presents it.

• Observation: No activity detected beyond the 172 range. This absence may indicate a lack of internet connectivity.

• Controller: Source of information transmission, potentially relaying sensor data, status codes, and setpoints. Commands likely comprise small packets, while status packets may follow a regular pattern.

• HMI (Human Machine Interface): Interface equipped with a screen and keyboard, facilitating engineers' system observation. Serves as a conduit between humans and machines, acting as the intermediary between users and controllers.

• HMI streams video data via *224, commonly indicating multicast. Multiple machines can intercept data addressed to 224, which is managed by networking equipment responsible for duplicating messages. Broadcast message designation: 255

To Do List:

• Work on tasks if assigned next class/meeting period.
• dive a little into ai using python and how/if we can connect it to our goal/research.

• Continued to work on our respective subteam tasks
• Tried to work on the error I encountered with running the ./run_example.sh file.
• Also, I looked a little into scikit-learn: Simple and efficient tools for data mining and data analysis. Includes various machine learning algorithms, preprocessing techniques, and model evaluation tools.
• looked into some code using sklearn that related to loading a dataset and using that dataset to train a machine learning model => iris = load_iris(),
• Ai could be helpful in debugging a lot of miniature errors, and could be crucial in our attempts to work toward developing the monitoring aspect.

To Do List:

• Continue to learn more about the various python packages that offer information on training AI and see if I can somehow connect it to monitoring rather than just the basic debugging aspect.
• Continue to learn python via the book and online training using geeksforgeeks.

• Spring Break!!!
• To do list:
• Get back and rolling into learning python and go over the DSA topic of lists.

• Learned more about lists and how I can use them in basic operations (Little bit into cs 1332 using python)
• general examples:
• my_list = [1, 2, 3, 4, 5]
• print(my_list[0]) # Output: 1
• `print(my_list[-1]) # Output: 5
• my_list.append(6) # Appends 6 to the end of the list
• my_list.insert(2, 7) # Inserts 7 at index 2
• my_list.remove(3) # Removes the first occurrence of 3
• popped_element = my_list.pop() # Removes and returns the last element

To Do List:

• see if I can figure out how to debug my ./run_example.sh troubles.
• Prepare for the presentations by doing research on the co-simulation environment and how its stability can be studied throughout many faults.

• Worked on debugging my attempt on running ./run_example.sh.
• Had to pull from my remote branch to obtain changes made previously.
• Commands used:
• make all-install
• make gridlab-all-install
• make helics-all-install
• downloaded newest verion of python to stay updated. Errors:

To Do List:

• See if I can figure out stacks within python, traverse the various data structures but within python
• look through coded examples using stacks.

• Looked at stacks today: follows LIFO (last in first out), practically the last element thats added to the stack is the first one to be removed.

• Coded examples:

• stack = []

• stack.append(item)

• item = stack.pop()

• top_item = stack[-1]

• # Pushing elements onto the stack

• stack.append(1)

• stack.append(2)

• stack.append(3)

• # Popping elements from the stack

• item = stack.pop() # Removes and returns 3

• print("Popped item:", item)

• # Viewing the top element of the stack

• top_item = stack[-1] # Returns 2

• print("Top item:", top_item)

• # Checking if the stack is empty

• if len(stack) == 0:

• `print("Stack is empty")`
  

• else:

• `print("Stack is not empty")`
  

To Do List:

• Work on presentation due next class period.
• Specifically, you need to implement the monitoring slides and the key takeaways slide along with the future plans for monitoring in general.

• Today we gave a live presentation for our topics. I specifically had the task to deal with the monitoring slides and the key takeaways alongside future plans.
• Slides I implemented:
• Scenario:

1. Initial State (3:00): Co-simulation in state of normal operation, network voltage levels stable.
2. Simulated Fault (4:00): introduce a simulated fault (Ex: power surge) to assess systems response.
3. DNP3 Communication for Fault Information (5:00): Use DNP3 protocol to share fault information, helps environment automatically disconnect affected lines.
4. Fault Recovery (6:30): system properly recovers from fault, voltage levels gradually return to normal.
5. Load Increase (7:30): unforeseen event generates load decrease, increasing voltage levels.
6. Modbus Communication for Voltage Adjustment (7:35): Use Modbus protocol to deploy communication between the Bay Controller and the main transformer, adjusts tap setting to restore voltage levels.
7. Tap Setting Response (8:00): transformer responds to tap setting set by Bay Controller, restores voltage levels to normal.
8. End State (9:00): simulation concludes with equipment monitoring voltage levels ensuring stability.

• Future Plans:

1. Develop python scripts to aid us in our efforts to monitor the co-simulation environment as it faces and resolves unforeseen incidents and faults.
2. Log changes occurring within the environment to provide a live feed of the ever changing environment in its efforts to facilitate stability.

• I altered the gridlab-d installation instructions via a personal branch on github. To summarize, the update iterates over all of the instructions to properly install Gridlab-D alongside HELICS via the make all/make all-install command instead of throwing a cmake error.
• In the near future, we plan to initiate the simulations for monitoring the environment by writing and structuring python code to optimally support a live simulation with additive measures to stimulate faults.

To Do List:

• Work on research paper thats due on the 24th.
• Specifically, implement the Co-Simulation: Scenario and Process(Monitoring), and Enhanced Device-Communication Integration slides.
• Develop future plans/things I plan to implement for the monitoring portion.

• This week we don't have class we just have to work on our final research paper and update notebooks if we haven't.
• My parts:
• Achieving seamless integration between HELICS and GridLAB-D is pivotal for establishing a dependable co-simulation environment. This enables the evaluation of system consistency and performance under diverse conditions, including faults and unforeseen events.

1. Initial State (3:00): The co-simulation starts with normal substation operation, maintaining network voltage stability.
2. Simulated Fault (4:00): A simulated fault, like a power surge, is introduced to assess the system's response.
3. DNP3 Communication for Fault Information (05:00): DNP3 protocol facilitates communication among substation devices to share fault data, leading to automatic disconnection of affected lines.
4. Fault Recovery (06:30): The system successfully recovers from the fault, with voltage levels gradually returning to normal.
5. Load Increase (7:30): An unforeseen event causes a load decrease, elevating voltage levels across the network. Modbus Communication for Voltage Adjustment (7:35): Using Modbus protocol, the Bay Controller interacts with the main transformer to monitor and adjust tap settings, restoring voltage levels.
6. Tap Setting Response (8:00): The transformer responds to the tap setting, gradually restoring voltage levels to normal.
7. End State (09:00): The simulation concludes with substation equipment actively monitoring and controlling voltage levels, ensuring system stability and reliability.

This timed sequence offers a comprehensive evaluation of the co-simulation's durability, reliability, and efficacy in responding to unexpected events and faults. It yields valuable insights into the integration of HELICS and GridLAB-D, ensuring robust system performance.

• Our ongoing research efforts are dedicated to the continuous integration and refinement of the Modbus protocol within our smart grid infrastructure. Modbus stands as a cornerstone in our communication framework, facilitating seamless interaction among various grid components \cite{PyModbus}. Its versatility in supporting diverse data types meets a wide range of application needs, while its straightforward implementation process streamlines our development efforts.

As we progress in our research, we are also expanding our communication capabilities by incorporating more advanced protocols like DNP-3. This integration enhances the robustness of our communication framework, offering additional security measures vital for the evolving demands of the smart grid ecosystem. Our decision to focus on DNP-3 aligns with our commitment to prioritizing security and efficiency in our communication protocols.

The Modbus and DNP3 protocols are pivotal in monitoring and managing the co-simulation environment. Currently, Python scripts are in staging to be developed to leverage the Modbus protocol for real-time monitoring, particularly in facilitating communication between the Bay Controller and the main transformer to monitor and adjust tap settings in response to voltage fluctuations, while changes in voltage levels and tap settings are logged continuously for live feed updates. Additionally, the DNP3 protocol enables fault communication among substation devices, automating responses such as the automatic disconnection of affected lines upon fault detection to ensure system stability, with ongoing efforts focused on developing scripts to monitor the co-simulation environment, capturing real-time data on system behavior and responses to unforeseen incidents, thus enhancing overall surveillance capabilities \cite{DNP-3}. In the future, we plan to enhance our monitoring capabilities by integrating more advanced protocols, thus augmenting the system’s fault detection mechanisms, and allowing us to streamline data logging processes for improved efficiency.

To do list:

• Wish peers and professors/Vip leaders a happy summer break, and we will hopefully meet in the Fall.

• Organized the kickoff presentation and assigned slides to each team member. I was responsible for the slides related to the monitoring sub-team. Specifically, I was tasked to fabricate our goals.

To Do List:

• Complete my portion of the kickoff presentation and confine it to the bounds of the criteria/rubric.

I completed my goals section before the presentation day but couldn't attend class in person due to a scheduling conflict. The team likely presented the kickoff presentation. Some key takeaways include that the monitoring sub-team will collaborate with ROS/HELICS, and work on similar tasks. Additionally, we need to establish a starting point for the monitoring sub-team, as it is a relatively new focus for this semester.

Goals:

1. Log co-simulation environment changes: Continuously monitor and record the evolving state of the co-simulation environment to ensure system stability and any changes that will impact overall performance.

2. Python scripts for incident resolution: Develop Python scripts to support monitoring efforts by analyzing and resolving unexpected incidents and faults, enhancing the system’s resilience.

3. Alerts for anomaly detection: Develop an automated alert system to detect and notify members of and potential anomalies or irregularities in the environment to maintain system reliability by resolving issues before they escalate.

To do:

• Meet with team virtually on Sunday (September 8th 2024) to discuss the process moving forward.

• Met with team to discuss the process moving forward.

• Review the installation steps in the README on the GitHub repository. Aim to complete this before class on Thursday so we can address any issues together during class.

• If you haven’t done so yet, start your notebook in the GitHub wiki. The rubric is available in Canvas, and you should refer to old notebooks for examples.

• Try to run example
• Log changes done on presentation to github wiki
• Read some wikis if you have time to get familiar with topics
• Meeting started around 3:30 PM
• Discussed if new members began the installation process for the required materials/software.

To Do:

• relearn concepts that were forgotten over time such as the functionality of DNP3.

• Didn't physically meet in class. Worked on trying to get my nix installed again (I believe it didn't install last semester due to minimal errors, and it froze). Read through the README to see if I could find anything relevant in troubleshooting.
• I skimmed through the DNP3 documentation and protocol primer to refresh my understanding of its functionality and usage.
• Monitoring sub team made a Trello Workspace; however, we didn't assign tasks yet as it is relatively new. Link:
• https://www.dnp.org/About/Overview-of-DNP3-Protocol
• https://www.dnp.org/Portals/0/AboutUs/DNP3%20Primer%20Rev%20A.pdf

To Do:

• Meet with team on Sunday to discuss progression of Monitoring sub team.

• Met with team and discussed the splitting of class meeting between the three different sub teams to specialize on relevant tasks.

- Networking:

• The Trello board currently has three tasks.
• Add yourself to one of the three tasks and aim to research it by Thursday.
• Develop plan for most essential communications within a substation (that we want to model first).

- Device Modeling:

• Review existing models in repo.
• Check if models are complete or if they need additional work done.
• Document and investigate devices that exist in substations but aren't within our current repo.

- Monitoring (My sub team):

• Programming challenging at this time (since it's new)

• Brainstorm ideas about the potential issues that could occur in substations.

• Consider how to detect these problems and identify their important factors.

• Divide class meetings into three distinct sessions (1 for each team).

• Division allows us to target tasks specifically designated for our team.

To Do:

• Research potential issues that could occur in substations. How to detect them and their identifying factors.

- Potential issues with substations:

• Some common issues with substations relate to equipment failure. Their identifying factors mainly relate to overheating, insulation breakdown, and mechanical wear. - Methods:

• The methods we can use to detect them would be to monitor fluctuating temperature, voltage, and current levels. We can use devices like circuit breakers to identify abnormal conditions (circuit breakers interrupt the current of overloaded electrical circuits, ground faults, and short circuits). - Identifying Factors:

• The identifying factors for these issues are the drops in power output, unpredictable power interruptions, and irregular operation of the equipment.

• Link to papers:

• https://ieeexplore.ieee.org/document/10318666

• https://www.eaton.com/us/en-us/products/utility-grid-solutions/grid-automation-system-solutions/fundamentals-of-substation-automation.html

• To Do:

• Continue research about issues within substations and their identifying factors.

• Weekly meeting with team on Sunday at 3:30 PM to discuss progress within individual sub teams.

• Conducted weekly team meeting.

• Updated team members on the progress made within the monitoring sub team and our plan moving forward.

• Discussed option of joining another sub team since monitoring is relatively new and a substantial amount of progress (technical) can't be made.

• To Do:

• Continue research about issues within substations and their identifying factors.

• Discuss and assign portions of the research paper to individual members.

• Potential Issues with Substations: Excessive demand on power systems (transformer overloading).

• Methods: Methods to detect them would be to load monitoring systems such as the Supervisory Control and Data Acquisition (SCADA) to detect high power flow.

• Identifying Factors: An identifying factor for this issue is overheating of transformers and other devices, system alarms triggered by SCADA, and voltage instability.

• Link to papers:

• https://ieeexplore.ieee.org/document/10318666

• https://www.eaton.com/us/en-us/products/utility-grid-solutions/grid-automation-system-solutions/fundamentals-of-substation-automation.html

- To Do:

• Continue research about issues within substations and their identifying factors.
• Weekly meeting with team on Sunday at 3:30 PM to discuss progress within individual sub teams.

• Worked on midterm papers with rest of monitoring subteam. Split up the portions of the paper effectively (for monitoring). I focused on writing the potential faults within a substation.

My work:

• Potential Faults within Substation:
• In our previous study, we highlighted several potential faults that can occur within substations. One common issue relates to the excessive demand on power, specifically transformer overloading. There are multiple methods to detect this fault including the utilization of load monitoring systems like Supervisory Control and Data Acquisition (SCADA). SCADA enables us to identify high power flow, voltage instability, and triggers system alarms when transformers begin overheating.
• Another frequent fault within our substation relates to equipment failure. Equipment failure is identifiable by overheating, mechanical wear, and insulation breakdowns. These issues are detectable via monitoring fluctuations in temperature, voltage, and current levels. Devices such as circuit breakers effectively ease the identification process by allowing us to pinpoint abnormal conditions by interrupting the current of overloaded electrical circuits. Lastly, we can identify this fault by monitoring drops in power output, unpredictable power interruptions, and irregular operation of the equipment

To Do List:

• Meet with Team on Sunday during our 3:30 PM meeting .
• Currently, monitoring subteam isn't gaining traction in our research. We need to discuss the plan moving forward and split up tasks.

Notes from meeting (I wasn't able to attend since I had a time conflict with another class):

• Add your name next to the content you contributed in the comments.
• Cite at least one peer-reviewed paper in your work.
• If you're using content from the previous semester's paper, ensure that all information is still accurate and up-to-date by reviewing and bullet-pointing it.

• Wasn't able to attend the meeting on October 6th due to an external class going over time.
• Discussed how to tackle the midterm presentation. I wasn't able to generate a video as I received a response too late.

To Do List:

• Fall break is coming so we're taking the time to spend it with family.

• Fall break so we didn't meet virtually.

To Do List:

• Continue to receive updates on monitoring progress and tasks.

• Wasn't physically present in class since I have a time conflict and some exams (due to this -> wasn't able to work on much).

To Do List:

• Meet with team on Sunday.

• Wasn't able to meet with peers during this virtual session due to an external class going over time.
• Read over some documents posted on Discord relating to the devices we want to model alongside their functionality specifics.
• No updates from monitoring subteam as no member joined the virtual meeting.
• Google docs: https://docs.google.com/document/d/1ZtMHdJov7VZr7buOC4va_Zk-f20rds6Tm4KKx0wQjzo/edit?usp=sharing To Do List:
• View and understand the parts within the device modeling repository.
• Link: Github Repo - Device modeling

To Do List:

• Meet with team on Sunday.

• Began reading paper "Design of an Industrial IoT-Based Monitoring System for Power Substations" as it directly relates to what the monitoring subteam is attempting to implement.

• Key Notes from paper:

  • Focus is on Industrial IoT (branch of IoT focused on real-time (RT) monitoring and control in industrial environments, supports tasks related to monitoring equipment, identifying faults, and enhancing grid reliability and stability) for real-time substation monitoring.
  • Data Acquisition: Sampling critical parameters at varying rates.
  • Synchronization: GPS ensures precise timestamps to avoid insecure protocols
  • Data Processing: Combines FPGA and CPU processing to ensure optimal RT performance.
  • IIoT in relation to power substation relevance ensures optimal resource utilization and reduces downtime.
  • Field-Programmable Gate Arrays (FPGA-Based System): offers high-speed hardware suited for real-time applications.
  • High-Speed Data Acquisitions: collect real-time parameters (voltage, current, temp, and breaker status).
    • sampling rates: there are adjustable rates for steady-states (normal condition/operation), and transient conditions (rapid changes).
  • GPS Synchronization:
    • Helps ensure precise timing for all data. As a result, it enables accurate analysis and cross-device coordination.
    • provides timestamping which is crucial for detecting and analyzing transient conditions.

• To do list:

  • Continue reading and understanding "Design of an Industrial IoT-Based Monitoring System for Power Substations" paper and concepts
  • Continue reading papers relating to real life implementations of Monitoring Systems for power substations to deepen understanding of IIot-based systems components and application in real substations. Moreover, identify key points to include IIoT features into our personal substation model.

• Continued reading paper "Design of an Industrial IoT-Based Monitoring System for Power Substations"

• Key Notes from paper P2:

  • Data Processing and Storage: So the FPGA processing practically handles low-latency tasks like signal filtering computations, and condition monitoring.
  • CPU Processing: practically complements FPGA by running advanced algorithms and longer analyses.
  • Network-Attached Storage (NAS): practically offers centralized and secure storage for long-term data archiving.
    • This also supports distributed access for analytics and visualizations.
  • Steady-State conditions:
    • practically covers normal operations where parameters remain intact or in predefined ranges.
    • Moreover, it helps in assessing the performance, energy efficiency, and signs of degradation.
  • Now for Transient Conditions:
    • Transient conditions require immediate detection and resolution because if that doesn't occur -> cascading failures do.
    • I believe this includes faults, surges, and other means of changes that occur rapidly.
  • We need to include secure protocols and encrypted communication safeguards to sensitive substation data as IoT and IIoT systems are vulnerable to cyberattacks (because they are interconnected).
  • It also discussed an improved means for fault detection (real-time systems are able to detect and isolate faults faster than SCADA systems). Also, predictive maintenance allows us to monitor equipment and predict failures before they occur. As a result, it reduces overall costs and enhances stability and reliability.
  • So in the paper, the system generated large data volumes as proven in this quote "produces a large amount of data during operation. Three phases of voltages on two 138-kV lines are measured simultaneously with a sampling rate of 2000 samples per second for each phase, which produces 12 000 input data every second". Static IP is used as a solution to ensure reliable communication across each device and protocols such as TCP/IP is are for secure data transfer.
  • Types of communication methods:
    • Tag communication: updates the HMI with the latest data and it's pretty efficient buy also lossy. Should only be suitable for display.
    • Stream communication: transfers data from FPGA to CPU using buffers and its optimized for high-speed tasks which balances CPU load and avoids buffer overflow.
    • FTP: mainly connection-oriented protocol that is used to send binary files to the NAS, and it's preferred for its low latency in requests that are successive.
    • Publish-Subscribe Pattern: practically simplifies data distribution by decoupling the senders and receivers. Also, it ensures that only relevant data is shared (which in turn enhances scalability and security).

• To do list:

  • Wrap up reading the paper and notes on key portions to deepen understanding.
  • Review cybersecurity portion of system.

• So for the cybersecurity of the system some core measures are taken. One is to replace the NTP with GPS synchronization for accurate time and enhanced security. Moreover, write access to controllers is denied (mainly from display-only computers).

• Main things I took away from the paper:

  • Time Synchronization: we should attempt to use GPS synchronization for precision and to avoid any NTP vulnerabilities, this also helps to ensure timestamps for HELICS events remain accurate.
  • Cybersecurity aspect: we need to employ firewalls for federate interactions and to secure sensitive components. Also, we should attempt to implement user authentication to minimize any exposure of our code (to limit tampering).
  • We should design the HELICS federate with a modular design that we can reprogram if necessary (just like the FPGA framework).
  • We should also enable flexible event-triggered mechanisms for diverse applications (fault analysis).
  • We should attempt to use predefined triggers to log events efficiently for federate simulations.

• To do list:

  • Divide the slides up for the final presentation and or develop new ones to display the research conducted throughout the semester.
  • Make video on my portion of the final presentation as I have a time conflict.

• Divided the slides up for the final presentation and developed new slides to include the progress we made this semester. So far, Device Modeling hasn't made much visible progress. As a result, the goals remain the consistent from the previous presentation.
• For this week, I delivered my portion of the presentation via a video. Specifically, I targeted the goals section of Device Modeling since I was the one to develop and research the tasks our team wishes to accomplish in the near future. Development of a HELICS federate has begun and that was mentioned in the video (I believe).
• To do list:
  • Fall break so we won't have a meeting next week
  • wrap up classes

• Thanksgiving holiday
• To do list:
  • Enjoy time with family and friends
  • Split up final paper
  • Prepare for final exams
  • Complete Peer Evaluations

My contribution/addition to final paper:

The analysis of potential faults provides a stable foundation for enhancing our framework. To further build on the research derived on potential faults, we are attempting to integrate a fault detection and response system within our environment. This system will provide a realistic representation of substation faults by incorporating physical device models alongside network communication protocols. The focus of our implementation will be fault detection integration, communication protocol resilience, and real-time monitoring.

• Fault Detection Integration: We aim to incorporate identifiable fault patterns into our model to simulate how particular components respond to stressful conditions. Specifically, we plan to implement detection mechanisms to monitor temperature variations, mechanical wear indicators via sensor data, and voltage instability abnormalities.

• Communication Protocol Resilience: We aim to develop robust communication channels to maintain data integrity during fault conditions and facilitate secure data exchange during critical periods. Specifically, we plan to represent how fault information transmits throughout the hierarchy. Additionally, this step is crucial for us to understand how effectively fault information can be transmitted and used.

• Real-Time Monitoring: Building on the lessons from the 2012 India Blackout, we aim to focus on monitoring voltage levels and power flow throughout our grid in real time. Moreover, we plan on including the ability to seamlessly track power exchanges, load balancing mechanisms, and control systems for voltage supervision.

This approach to fault detection aligns with our framework using HELICS and GridLAB-D. As a result, it allows us to test and validate various fault scenarios while ensuring system reliability and security.

• To do list:
  • Finish final paper and note book for feedback and continue preparing for finals.

• First meeting of the semester and so I reached out to team members to discuss the plan moving forward. Currently, the monitoring team is at a standstill as I've done research on the faults but haven't worked on establishing a log. Simple log implementation can be derived via a log template in Notion, which contains fields to document the co-simulation environments efficiency and points of weakness.
• Essentially, we discussed the research conducted last semester and made points to improve our contributions this semester.
• A application resembling LettuceMeet was used to establish additional meeting times for this semester. The team finalized on Friday; however, Fridays are difficult for me as I have work.

To Do List:

• Discuss Kickoff presentation and assign roles and slides to each member of monitoring subteam.

• We ended up finalizing the subteams this week and afterward we discussed the project (while briefing new team members).
• Discussed Kickoff presentation and how to address the slides that require alterations. Specifically, I updated the goals portion of the monitoring subteam to include our progression on the HELICS federate file.
• I was unable to record a video for my portion as I fell ill, and it was difficult to talk. I informed the VIP lead via Discord of my problems.

To Do List:

• Discuss steps moving forward with Ethan and Reva.

• Planned to communicate steps moving forward with Ethan and Reva. Currently, the monitoring subteam is at a standstill and I'd like to discuss the next steps to continue progression. Specifically, we need to provide steps on what needs to be covered and who is responsible, provide a description of the next priority alongside the dependencies or receive external input. I plan to aid in the development of the HELICS federate this semester.

To Do List:

• Establish private meeting with Reva and Ethan to discuss progress on HELICS federate and what to target next.

Notes:

• Primarily worked through the paper "A survey of anomaly detection methods for power grids" by Srinidhi Madabhushi and Rinku Dewri.

General Notes:

• The paper specifically focuses on categorizing detection methods and their specific applications in the power grid. It references challenges and gaps within the research as well (analyzing over 190 research articles to provide a review).
• Papers general structure starts with methodology, then background info, then in-depth review of past attacks and underlying impacts.

• General depiction of the physical layer of our ideal power grids. This image essentially allows me to understand how anomalies can occur at any stage by breaking down the physical assembly line into key components (From data breaches in the control centers to defective sensors). Also, physical anomalies like transformer damage and line tripping could occur.

• This image illustrates the spectrum of attacks that could occur (Physical, Cyber, and Human attacks), also underlines the need for anomaly detection techniques that can identify various fault or anomaly origins.
• Anomaly Detection: identifies data patterns that deviate from expected outcomes or behaviors. The detection areas are at the field-level (physical pieces of technology), network-level (communication systems), and centralized (control centers). There are also three main classes to the techniques.

Supervised approach:

• Method relies on labeled datasets (both normal and anomalous events are pre-identified) to train the models. Classical techniques like Support Vector Machines, Decision Trees, and Random Forests are used to learn patterns from historical data. Afterward, the models should be capable to classify new data into 2 distinct categories: Normal, Abnormal.

Semi-supervised Approach:

• Methods address how labeled data for anomalies are scarce by exclusively modeling normal behaviors. Once a model of this state is established, the deviations from it will serve as an indicator for anomalies (techniques include ARIMA or Support Vector Regression, and distance strategies to assess prediction errors, computing an anomaly score).

Unsupervised Approach:

• Methods mainly useful when there isn’t any labeled data. Specifically, this approach uses clustering, statistical analysis, to detect anomalies based on the inherent structure of the data. Essentially, it looks for clusters or patterns that are different from the majority to indicate issues.

Source:

• A survey of anomaly detection methods for power grids

To Do List:

• Continue working through the paper "A survey of anomaly detection methods for power grids" by Srinidhi Madabhushi and Rinku Dewri.
• Attempt to develop a skeleton python file of the concepts referenced in the paper.

Notes:

• Attempted to develop a skeleton python file to demonstrate the unsupervised anomaly detection approach. Specifically, it uses the Isolation Forrest algorithm.

    import numpy as np
    from sklearn.ensemble import IsolationForest

    data_normal = np.random.rand(100, 2)

    data_anom = np.array([[1.5, 1.5], [1.7, 1.6], [1.6, 1.8]])

    data = np.concatenate((data_normal, data_anom), axis=0)
    
    detector = IsolationForest(contamination=0.03, random_state=42)
    
    detector.fit(data)
    
    # Predict anomaly labels: 1 (normal) and -1 (anomaly)
    predictions = detector.predict(data)
    anomaly_indices = np.where(predictions == -1)[0]  
    
    # Output the prediction labels for all data points
    print("Anomaly Prediction Labels:", predictions)
    
    # List the positions of the outliers or anomalies
    print("Indices of Detected Anomalies:", anomaly_indices)

    Output:
    Anomaly Prediction Labels: [ 1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
    1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
    1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
    1  1  1  1  1 -1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
    1  1  1  1 -1 -1 -1]
    Indices of Detected Anomalies: [77 100 101 102]

• This just generates sensor data to simulate normal behavior then injects abnormal points. The model predicts which instances deviate from the normal standard.
• The paper also reviewed historical attacks like the Stuxnet work attack and explained how anomalies can manifest in real scenarios. It also explored how coordinated manipulations using IoT can disturb grid balance.
• Some of the future challenges mentioned in this paper were:

• Real-Time Detection: Essentially the want to balance speed with accuracy.
• Concept Drift: To adapt the models to an evolving grid with unpredictable and progressing behavior.
• Limited Data: Means what it's labeled as.

To Do List:

• Continue researching papers on anomaly detection. Another one I found was "Anomaly Detection in Power Grids via Context-Agnostic Learning". I most likely will just start on that next.

Notes:

• Primarily worked through the paper "Anomaly Detection in Power Grids via Context-Agnostic Learning" by SangWoo Park and Amritanshu Pandey.

General Notes:

• The paper specifically focuses on real-time anomaly detection in power grids using SCADA (Supervisory Control and Data Acquisition) values or data. The authors primarily introduce an algorithm GridCAL which is supposed to address the limitations of the previous methods used. Essentially, it is supposed to transform real-time power flow measurements into context-agnostic values. This would enable the analysis of measurements across multiple grid context, it also allows us to derive a statistical model to serve as a foundation for fault/anomaly detection.
• It dives into how network topology processors (NTPs) are essential for real-time grid monitoring and contingency analysis. NTPs outputs are sensitive to measurement errors which causes divergence and deteriorates grid reliability. They go into how the existing approaches like applying statistical models to data have limitations like a high false positive rate because they ignore the dynamic contexts. The main idea is GridCAL which would model the grid as a time-varying graph G(τ), edges should change with topology, nodes need to stay as is. It will essentially help reduce false positives and handle anomalies.

Algorithms:

• The image above is algo 2.
• Algo 1: would compute the graph distances between the current and historical studies, and assigns weights to historical data based on resemblance to current grid.
• Algo 2: applies the context-agnostic mapping to the current and historical data, computes the weighted mean (μi) and standard deviation (σi) for each sensor, flags anomalies if deviation exceeds the threshold.
• Their test cases used is the Polish power grid (with 2383 buses and 2896 lines). Essentially, they found out that GridCAL outperforms prior methods in detecting topology errors, and reduces false positives by normalizing the data to a baseline.

Source:

• Anomaly Detection in Power Grids via Context-Agnostic Learning

To Do List:

• Meet with Ethan, Reva, and instructor Samuel Litchfield to address issues in team progression.

Overview:

• Conducted a subteam realignment meeting with Ethan, Reva, and our instructor Samuel Litchfield. We honed in on the issues with the standstill the monitoring subteam faced and developed options to resolve it while paving lanes to advance development.

Meeting Notes:

• Fault injection modules in test set up, do rough threshold comparison, then literature survey in anomaly detection for variables. Protection relays look over currents.

Additional Notes from Reva:

• 1. look into anomaly detection
• 2. 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
• 3. ros helics figured out how to get grid lab d to model the faults
• 4. fix helics federate

• I also contributed to the conclusion section of our midterm research paper.

My contribution:

• This progress sets the groundwork for future enhancements in our power grid resilience by leveraging optimal communication protocols. As we continue, we plan to explore and enhance compatibility with various grid simulation tools and expand the fault detection capacity to strengthen response mechanisms.

To Do List:

• Work on dividing up midterm presentation and fulfill my part.

Notes:

• I was tasked to revise the goals for the monitoring subteam (since we conducted a meeting to expedite our progress):

My contribution:

• 1. Integrate Fault Detection Modules: Continue to improve HELICS federate, ensure smooth interaction with GridLAB-D for fault modeling, and ensure physical variables are received and processed correctly for faults.
• 2. Develop Threshold-Based Fault Detection System: Implement a fault detection system that identifies and documents expected voltage and ranges for normal operations. Implement logic to compare values against inflated and minute thresholds.
• 3. Research and Implement Anomaly Detection Procedures: Research existing scholarly papers on anomaly detection algorithms while implementing a baseline comparison by calculating and comparing historical averages to flag deviations.

To Do List:

• Begin researching and updating the existing HELICS federate, work on expanding knowledge on anomaly detection through more research, and optimize a base for Monitoring_simulator.py file.

Notes:

• Worked on altering some portions of Reva's Monitoring_simulator.py. Specifically, I want to add a parameter for thresholds checking (not implemented yet but should be simple) into the HELICS Federate (I will probably base it off standard voltage rates).

My Changes:

• I will most likely set the minpart and maxpart to be 110.0 and 130.0 for simplicity (not said in my example but wanted to inform).

import statistics

def analyze_voltage(data, thresholds, key="<name_of_key>", time_step=None):
    current_faults = []

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

    # Fetch thresholds
    try:
        threshold = thresholds[key]
        st_Min = threshold.get("<minpart>", 110.0)
        st_Max = threshold.get("<maxpart>", 130.0)

        # define absolute limits as ±5% of the midpoint
        midpoint = (st_Max + st_Min) / 2
        buff_O = 0.05 * midpoint
        abs_Min = st_Min - buff_O
        abs_Max = st_Max + buff_O

    except KeyError:
        print(f"[WARNING] Thresholds not found for: {key}")
        st_Min = 110.0
        st_Max = 130.0
        midpointVal = (st_Max + st_Min) / 2
        buff_O = 0.05 * midpointVal
        abs_Min = st_Min - buff_O
        abs_Max = st_Max + buff_O

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

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

    return current_faults

• This is just a simplistic change which should work when I can actually pass in the thresholds as a param and look for the key in my Federate.

• An example of attempting to input in the future when I add the thresholds portion to the federate.

  "testThresholds": {
    "<name_of_key>": {
      "<minpart>": <val>,
      "<maxpart>": <val>
    }
  }

dataVal = [119.5, 120.4, 118.8, 131.8, 134.7, 109.9, 108.9, 121.4, 111.0, 110.5, 130.0]
faultVal = analyze_voltage(dataVal, thresholds, key = <name_of_key>)
print(faultVal)

• The mock test would include several normal, near high threshold, above max thresholds, and more. This would allow me to essentially test the functionality to derive if the thresholds are causing issues. Another thing was Reva had it in per-unit standards (I believe, nominal Volt = 120V, min = min/120 = 0.xxxx). I changed mine to simulate the data in real voltage units.

To Do List:

• Continue working on skeleton structure of Monitoring.py.
• Get to progressing HELICS Fed soon.

Notes:

• Wasn't really able to do much coding this week since I had exams. Instead, I just working through the paper "Enhanced Anomaly-Based Fault Detection System in Electrical Power Grids" by Wisam Elmasry and Mohammed Wadi.

General Notes:

• The paper just introduces an approach to detecting faults in electrical power grids using anomaly detection techniques.
• There is a critical need for early and accurate fault detection in electrical power grids, and existing methods aren't working to the full capacity in real-world applications. It also highlights similar problems to the paper I've read before. Specifically, its data scarcity and system complexity that is an issue.
• They are trying to propose a system that leverages advanced preprocessing and optimization standards to enhance performance.
• "Noise is another face of outliers in data. The noise in data is a set of rare samples that fall far away from the majority of data. There is no precise way to identify noise in general. But with the help of the concept of noise explained above, some statistical methods can be utilized to find out noise candidates. One of the well-known noise filtering methods is the interquartile range (IQR)" [1]. Essentially, they use the IQR method to filter out outliers.

Source: [1] W. Elmasry and M. Wadi, “Enhanced anomaly‐based fault detection system in electrical power grids,” Wiley, Feb. 14, 2022. [Online]. Available: https://onlinelibrary.wiley.com/doi/10.1155/2022/1870136

• Enhanced anomaly‐based fault detection system in electrical power grids

To Do List:

• Week of Spring Break and so nothing planned so far.

Notes:

• Week of Spring Break and we did not meet.

To Do List:

• Nothing as of this week since its break!
• Try to complete the paper "Enhanced Anomaly-Based Fault Detection System in Electrical Power Grids".

Notes:

• Continued and finished the paper "Enhanced Anomaly-Based Fault Detection System in Electrical Power Grids".

General Notes:

• The PSO or particle swarm optimization based algorithm is essentially used for hyperparameter tuning. Specifically, it just simulates a swarm of particles that move through the hyperparameter space to find the optimal config that maximizes model precision. Some key characteristics of it are:
• Inertia weight: It essentially controls the impact of the velocities used previously.
• Number of Particles + Iterations: It essentially determines the depth of the search.
• Swarm dynamics is basically how the candidate solutions explore the space. The update mechanism is the movement of the particles.

• This image is just a representation of the Receiver Operating Characteristic (ROC) curves of the used models. Essentially, the ROC curves are for the two main models used for anomaly detection: One-Class Support Vector Machine (OC-SVM) and the Principal Component Analysis (PCA). Essentially, the ROC curves display the trade-off between false and true positive ratings across multiple thresholds. OC-SVM has higher TPR at lower FPRs, and so it handles balancing the detection of true anomalies while minimizing the false positives. While PCA performs generally worse as it is a reconstruction-error based method (less robust for fault/anomaly detections).

My attempt to recreate a skeleton of OC-SVM and PCA

from sklearn.svm import OneClassSVM
from sklearn.decomposition import PCA

oC_SVM = OneClassSVM('rbf', nu = 0.1)
oC_SVM.fit(subset_T)
an_fault_scores = oC_SVM.decision_function(subset_E)

pca_Mod = PCA(n_components = 2)
pca_Fin = pca_Mod.fit_transform(matrix)

To Do List:

• Work on updating HELICS Federate with threshold logging (what I did previously).

Notes:

• Reviewed the HELICS Federate:

{
    "coreInit": "--federates=1",
    "coreName": "Monitoring Federate",
    "coreType": "zmq",
    "name": "Monitoring",
    "offset": 0,
    "period": 60,
    "timeDelta": 1,
    "logfile": "output.log",
    "log_level": "warning",
    "uninterruptible": true,
    "publications": [
        {
        "key": "Monitoring/transmission_voltage",
        "type": "complex",
        "global": true
         }
    ],
    "subscriptions": [
        {
        "key": "IEEE_123_feeder_0/totalLoad",
        "type": "complex",
        "required": true
        }
    ]
}

• Can potentially update the Federate to include thresholds (wanted to get to this and now getting to it) as a simple fault detection mech. Generally optimal to keep voltage levels within 5% of nominal voltage. Ex: Nominal voltage at service is 120V, then the normal range would be 114V to 126V, but I just set a hard line for testing.

{
  "coreInit": "--federates=1",
  "coreName": "Monitoring Federate",
  "coreType": "zmq",
  "name": "Monitoring",
  "offset": 0,
  "period": 60,
  "timeDelta": 1,
  "logfile": "output.log",
  "log_level": "warning",
  "uninterruptible": true,

  "publications": [
    {
      "key": "Monitoring/transmission_voltage",
      "type": "complex",
      "global": true
    }
  ],

  "subscriptions": [
    {
      "key": "IEEE_123_feeder_0/totalLoad",
      "type": "complex",
      "required": true
    }
  ],

  "testThresholds": {
    "Monitor_volt": {
      "minVal": 110.0,
      "maxVal": 130.0
    }
 }

• Image depicts voltage fluctuations, sag, and interruptions. It just serves as a visual reference to the goal of including the thresholds portion. Essentially if we have a variation, interruption, or overvoltage, then the system alters us by triggering a warning.
• Essentially, this would just allow me to compare each received value to a valid range and if the mag falls outside of it the it would likely flag it (or trigger warning).

General voltage ranges:

• North American Voltage Ranges

To Do List:

• Continue to see if I can derive improvements to the HELICS Federate, want to see how to add more granular logging for anomaly or fault detection.

Notes:

• Established roles for the final paper. Specifically, the monitoring subteam was assigned the conclusion portion. However, we made some progress throughout the semester and so I am most likely going to update the Potential Faults within Substations portion.
• Worked on adding granularity to the logging for anomaly or fault detection portion of the federate.

{
  "coreInit": "--federates=1",
  "coreName": "Monitoring Federate",
  "coreType": "zmq",
  "name": "Monitoring",
  "offset": 0,
  "period": 60,
  "timeDelta": 1,
  "logfile": "output.log",
  "log_level": "warning",
  "uninterruptible": true,

  "publications": [
    {
      "key": "Monitoring/transmission_voltage",
      "type": "complex",
      "global": true
    }
  ],

  "subscriptions": [
    {
      "key": "IEEE_123_feeder_0/totalLoad",
      "type": "complex",
      "required": true
    }
  ],

  "testThresholds": {
    "Monitor_volt": {
      "minVal": 110.0,
      "maxVal": 130.0
    }
  },

    "diagLog": {
     "enable": true,
     "log_faults_or_anomaly": true,
     "log_violations": true
}

To Do List:

• Work on updating the Potential Faults within Substations portion for the final paper.
• Add or alter portions of the conclusion for the final paper.

Notes:

• Primarily worked on final research paper and final presentation, due on April 16-24th 2025 by 11:59 PM.
• I specifically contributed to the final presentation by updating the monitoring subteam goals since we made progress.
• I specifically contributed to the final paper by including progress in the Potential Faults within Simulations section I wrote and conclusion.

My Contributions:

1. Enhance current HELICS Federate:

• Continue to improve HELICS federate to support instantaneous fault analysis by expanding the active subscription to include currents and individual voltage levels of each phase to broaden fault detection standards.

2. Develop Threshold-Based Fault Detection System:

• Integrate output in CSV format for enhanced logging and visualization.
• Add intensity/severity levels to classify faults and assign by rank.
• Expand logic to allow for frequency deviation or current analysis.

3. Research and Implement Anomaly Detection Procedures:

• Research existing scholarly papers on anomaly detection algorithms while implementing a baseline comparison by calculating and comparing historical averages to flag deviations.
• Incorporate standard deviation based anomaly detections to pinpoint abnormal and unexpected trends.

My Contributions:

• Progressing on these core principles, we plan to leverage statistical and machine learning algorithms to monitor sensor data and identify deviations indicating evolving faults continuously. We also aim to develop a comprehensive fault mechanism that uses real-time measurements captured by physical models to network traffic patterns. The focus of our implementation will be fault detection integration, communication protocol resilience, and real-time monitoring.

• Communication Protocol Resilience: We aim to develop robust communication channels to maintain data integrity during fault conditions and facilitate secure data exchange during critical periods. Specifically, we plan to represent how fault information transmits throughout the hierarchy. Additionally, this step is crucial for understanding how effectively fault information can be transmitted and used. Progressing on these core goals, we also aim to incorporate cryptographic algorithms and real-time intrusion detection. This enhancement would enable proactive monitoring of data flows and permit rapid isolation and negation of detected intrusions and anomalies.

• Real-Time Monitoring: Building on the lessons from the 2012 India Blackout, we aim to focus on monitoring voltage levels and power flow throughout our grid in real-time. For real-time data monitoring and advanced anomaly detection, we plan to analyze time series data from key variables, facilitating the identification of faults in real time. Moreover, we plan on including the ability to seamlessly track power exchanges, load balancing mechanisms, and control systems for voltage supervision. In addition, we aim to incorporate machine learning models to analyze evolving data patterns and leverage historical data to allow for continuous calibration of our thresholds. As a result, it would enable swift interventions to minimize the risk of surging failures.

• In summary, our co-simulation environment enables effective modeling of current communication applications and serves as an outlet for fault detection and cybersecurity, ultimately enhancing the power grid.

To Do List:

• Finished my sections of the final paper, so the only thing left is to have a good summer!