-Sub Team meeting has been finalized for Mondays @ 7 p.m. We were introduced to Github and the instructions for setting up our devices to work on the project located in a Read.me file on git.

Voltage Transformer/Current Transformer: measures voltage and currents in substation. Also passes info to relay to determine if fault condition is present.

Fault Condition: Irregular patterns that indicate substation should stop

Merging Units: Converts voltage measurement into digital form that gets passed onto IEC 61850 and protection system

IEC 61850: communication protocol for handling digital info inside a substation

Disconnector: Mechanical switch inside substation

• allows circuit breakers to be isolated -Cannot break load current and fault current??

Circuit Breaker- Has job of breaking load current and fault current. Has critical role in protection system of the substation.

Transformer: performs function of "step up" and "step down" of voltage. -Contains Buckhold Relay which detects failure in transformer.

Relay House: monitors voltage and current to see if there's a fault. If fault is present it sends a message to circuit breaker. -Contains a battery that powers equipment if there's an outage.

Protection System of Substation: Protects grid from faults and responds if faults are presents -Made up of (VT/CT, Disconnectors, Circuit Breakers, Relay)

Surge Arrester: Protects transformer and other components of substation from high frequency surges such as lightning strikes.

9/11- Group Meeting Notes

Go through HELICS tutorials

Continue research on substation & network protocols

Share research: videos/docs when you find it useful/appropriate

Will primarily use Python over C++

Source: I found an article that talks about faults that substations experience. At some point we could simulate these in the co simulation: https://electrical-engineering-portal.com/download-center/books-and-guides/power-substations/fault-current-cb#:~:text=Faults%20usually%20occur%20in%20a,two%20phases%20may%20be%20involved.

What is a fault? Any abnormal electrical current in a substation.

Faults can cause different max fault currents. I think simulating faults in the co-simulation would be a good way for testing the system to failures that could occur in on actual substation.

Common fault causes are short circuits to earth, between live conductors, or broken conductors.

Types of Faults:

1. Phase to Earth
2. Phase to Phase
3. Phase to Phase to Earth
4. Three Phase
5. Three Phase to Earth

"Phase"- refers to 3 lines that are usually on transmission lines.

Successfully finished setting up the nix develop environments along with building HELICS and Gridlab-D

Samuel Litchfield recommended this paper to answer the research questions:

https://www.google.com/url?q=https://electrical-engineering-portal.com/res/Schematic-Representation-Of-Power-System-Relaying.pdf&sa=D&source=docs&ust=1696523449981589&usg=AOvVaw3cAXGRRC9Ef_n-Spx5Zyhd

1. What are the primary substation functions that need to be modeled for co simulation? 2.How can substation device models be designed to accurately replicate the behavior of real world substation equipment?
2. What are the key parameters and variables that need to be considered when modeling substation functions?

Q2: In the paper that Samuel Litchfield commented on, we can model our co-simulation of substations after the schematics of actual substation/ power relay systems. This allows us to have a foundation for ourselves to improve on but also makes sure we know the connections between substation components and the connections with the communication systems. The paper also shows examples of drawings of various complexities. To start off the co-simulation we can start by implementing the simple 1 line diagram of the schematic then move on to incorporating the more complex diagrams into the co-simulation as we make the program more robust.

Q3:

Load- to determine the amount of voltage running through a substation at a given time.

Busbars/Load for Busbars- the structures that conduct and transfer energy to different parts of the substation.

Feeder Lines- The lines that carry voltage from the busbars to different components of the substation.

Control/Communication Lines- for monitoring the status of the substation and equipment. Carry signals throughout the substation.

Fiber Optic Lines- Carry data between control systems in the substations. **This may be related IEC 61850.

Voltage Levels

Current Levels

Transformer() - main function in a substation to step up and step down the voltage.

Circuit Breaker()- interrupt current flow when protective relays detect a fault.

** Can model the above with OOP with the correct parameters.**

-A way to measure faults is also important as there are many different type of faults.

This week I wrote out the instructions for how to run the simple gridlab-d example in git for windows. To get to CPS co-simulation environment:

1. run "cd" press tab 2x to get everything in the current directory.
2. run "cd cps-" press tab to complete path
3. run "nix develop" this puts us in the environment
4. run "run nix develop" this shows the environment
5. run "git pull" in the environment to get the latest updates from the repository
6. run "nix develop" to update the newest packages we got from git pull
7. inside the CPS co-sim environment run "ls" to see what all lives in the directory
8. run "cd simple.gridlab_example"
9. run "ls"
10. run "./run._example.sh" this gives the command to run the example
11. Use control +C to stop the simulation
12. run "ls" identify kill_all.sh
13. run "./kill_all.sh" If the previous step doesn't work try to run "sudo ./kill_all.sh"

This week the team met to discuss who would be responsible for sections concerning the mid-semester paper. I was assigned the section concerning the implementation of HELICS and Gridlab-D and the initial approach for the co-simulation involving framework and integration.

This week I was assigned to the Co-Simulation subteam to pursue the following tasks: Co-simulation Subteam

Task 1: Set up the co-simulation environment and run the simple_gridlabd_example (Completed)

Task 2: Core Code and API Documentation Analyze the simple_gridlabd_example and Electric Vehicle example from HELICS to identify core code components and APIs. Document findings in the Research Documentation.

Task 3: Co-simulation Scenario Design Define the specific scenarios for voltage variations within the grid. Determine the timing and parameters for voltage level changes. Write the framework code for the specific scenario.

Task 4: Real-time Data Monitoring Implement a real-time monitoring system to track voltage levels during co-simulation. Enable visualization and data recording for analysis within the co-simulation environment.

Task 5: Fault Tolerance and Recovery Implement mechanisms for fault tolerance and recovery to ensure simulation integrity.

This week I started dissecting the relay.simulator.py file from the gridlab-D example in order to get a better understanding of the process for creating federates inside of HELICS.

1. Imports:

   • The script starts by importing several Python libraries and modules.

2. Logger Configuration:

   • The script configures a logger to capture log messages. It sets the logger's level to DEBUG and specifies that log messages should be streamed to the console.

3. create_broker Function: -intended for creating a HELICS broker. A broker is a central component in HELICS that manages communication between federates (simulators).

4. destroy_federate Function:

   • This function is responsible for disconnecting and freeing a HELICS federate. It is called at the end of the script to clean up resources.

5. Main Script Execution:

   • The main part of the script starts with the conditional check: if __name__ == "__main__":, ensuring that the following code only runs when the script is executed, not when it's imported as a module.

6. HELICS Federate Initialization:

   • The script creates a HELICS federate using a JSON configuration file named "Relay_config.json." It registers interfaces and retrieves the federate's name. It also logs the HELICS version and confirms the registration of the federate.

7. Publication and Subscription:

   • The script registers publications and subscriptions for the federate. Publications are used to send data from this federate, while subscriptions are used to receive data from other federates or sources. The script logs the registered publications and subscriptions.

8. Execution Mode:

   • The script enters the initialization and execution modes of the HELICS federate. The initialization mode sets up the federate, and the execution mode allows it to actively participate in the co-simulation.

9. Co-simulation Loop:

   • Inside a loop, the script iterates over time intervals to perform the co-simulation.

10. Termination and Cleanup:

    • After the co-simulation loop is completed, the script requests the termination time and logs the destruction of the federate.

This week I started dissecting the relay-config.json file to get a better understanding of how federates function and the necessary components for implementing HELICS and Gridlab-D.

1. coreInit:

   • This parameter specifies initialization options for the core, which is responsible for managing communication between federates. In this case, it indicates that there is a single federate.

2. coreName:

   • The name of the core is set to "Relay Federate."

3. coreType:

   • The communication protocol used by the core is "zmq" (ZeroMQ).

4. name:

   • The name of the federate is "Relay."

5. offset:

   • The offset parameter is set to 0, which means the federate's time will be synchronized with the global simulation time.

6. period:

   • The federate operates with a period of 60 seconds, meaning it performs its actions at regular intervals of 60 seconds.

7. timeDelta:

   • This parameter sets the time delta to 1. It specifies the smallest time step that the federate can take.

8. logfile:

   • The federate's log messages are written to a file named "output.log."

9. log_level:

   • The log level is set to "warning," which means log messages with severity levels equal to or higher than "warning" will be recorded.

10. uninterruptible:

    • This parameter is set to "true," indicating that the federate should not be interrupted during its execution.

11. subscriptions:

    • This section defines the data that the federate subscribes to. It includes the following four subscriptions:
      • "CurrentA" subscribes to the "IEEE_123_feeder_0/currentA" key
      • "CurrentB" subscribes to the "IEEE_123_feeder_0/currentB" key
      • "CurrentC" subscribes to the "IEEE_123_feeder_0/currentC" key
      • "TotalLoad" subscribes to the "IEEE_123_feeder_0/totalLoad" key

These subscriptions indicate that the federate will receive data related to electrical currents (A, B, C).

In the group meeting this week, the co-simulation team decided to prioritize becoming familiar with the Gridlab-D components of the co-simulation. The members of the co-simulation team agreed to meet over the Thanksgiving break to work on this process together. As a team, we worked on the relay_house.py file in hopes of running a basic co-simulation.

-The Co-simulation team met over Thanksgiving break to discuss creating .glm files and to work on the Gridlab-D implementation into the project. -We worked together to gain a better understanding of the .json files from the HELICS example and how we can implement them into our co-simulation.

This week I started on the helics-config.json file. Using what I researched from the HELICS examples, I used the file to register all the current devices as federates in HELICS. We also had our final presentation.

Example: ######################################################## PROCESS_LEVEL_FEDERATES ####################################################### { "directory": "device_modeling/src/process_level", "exec": "python -u process_device.py", "host": "localhost", "name": "ProcessDevice" },

{
  "directory": "device_modeling/src/process_level",
  "exec": "python -u circuit_breakers.py",
  "host": "localhost",
  "name": "CircuitBreaker"
},

{
  "directory": "device_modeling/src/process_level",
  "exec": "python -u protection_relays.py",
  "host": "localhost",
  "name": "ProtectionRelay"
},
{
  "directory": "device_modeling/src/process_level",
  "exec": "python -u relay_house.py",
  "host": "localhost",
  "name": "RelayHouse"
},