Maria Cymbalyuk's Notebook

12/1/2025-12/7/2025

• Final Paper

I worked on the final paper to get my sections in. I added my parts about making the RTU device and the details about NERC CIP!

11/24/2025-11/30/2025

Thanksgiving Break!

11/17/2025-11/23/2025

• Final Presentation

We presented our final presentation and we made a lot of good progress! Things seem to be coming together more and more.

11/10/2025-11/16/2025

• Fix error
• Final Presentation

I attempted to keep seeing what the issue was but it would not work. Then, Kaden had a new installation for us to try.

I attempted it and it worked...until the final command.

For some reason, I don't have permission and there are some other little details erroring.

According to the instructors, it seems to be getting worse, these errors. And it is frustrating that these little errors are stopping us from doing other work. Next semester, it looks like we may get collective hardware so that this can work! It was a good effort though.

We are beginning to work on the final presentation.

11/3/2025-11/9/2025

• Delete current repo/Kaden installation
• Fix error
• Add comments to devices
• Write callbacks (networking team will let us know)

I continued to try and figure out what the error was. The beginning was working:

Then, we tried to be able to read the error more fully by doing nix develop 2> nix.out

From that, we tried installing dos2unix because we assumed there was an issue with translating between Windows and WSL:

This didn't quite work...Finally, I cloned the repo through WSL instead of through Windows. Everything worked...up to a point:

It seems files keep not being found. I will ask Kaden during the meeting tomorrow.

1. 86 80 linux gnu naming issues
2. There should not be a python in the UV...?
3. past attempts created Python and UV found the wrong Python...We need free threading Python (not problem)

10/27/2025-11/2/2025

• Push RTU to branch
• Delete current repo/Kaden installation
• Add comments to devices
• Write callbacks (networking team will let us know)

I was told to push the RTU to the device-modeling branch and I did it! I also am attempting to do Kaden's installation. The thing is, I am not sure how to delete my current repo (I had it in my Onedrive and then I didn't). I am hoping Chungman can help me out with deleting the repo and then try installing Kaden's program.

I attempted doing Kaden's steps. I recopied the repo and went into his notebook.

However, I began getting a couple of errors with Nix. I will try to look into it. And hopefully figure it out. The error says the file does not exist. However, it is present in my directory. It seems I am missing something....

10/20/2025-10/26/2025

• Build simple RTU
• Add comments to devices
• Write callbacks (networking team will let us know)
• Look at NERC CIP (regulations, laws, etc)

We discussed that we need to build a RTU and were going to talk to Sam if we can just code in the Master. We determined for our "simple" transformer, the bare minimum is (multiple) breakers (our circuit breakers), a transformer (current/power transformer), and a disconnector (which is a switch).

Sam doesn't think it is a good idea to add the extra code into the master to represent the RTU. RTU is an outstation for the control center's master. They are serial connections to other devices from the RTU. He showed us how to physically do it but how to actually implement it is another thing.

I was looking into the NERC CIP.

SCOPE: It is a framework that is applicable to entities operating the BES, including utilities, grid operators, and energy generators.

The standards are as follows:

Asset Identification (CIP-002): Identifying and categorizing critical BES Cyber Systems

Security Management Controls (CIP-003): Establishing security policies and procedures

Personnel and Training (CIP-004): Managing personnel access and training

Electronic Security Perimeters (CIP-005): Protecting electronic access to BES Cyber Systems

Physical Security (CIP-006): Protecting physical access to BES Cyber Systems

Systems Security Management (CIP-007): Managing system security through patch management, malware prevention, etc

Incident Reporting and Response Planning (CIP-008): Reporting and responding to security incidents

Recovery Plans (CIP-009): Creating and keeping recovery plans

Configuration Change Management and Vulnerability Assessments (CIP-010): Monitoring changes and assessing vulnerabilities

Information Protection (CIP-011): Protecting BES Cyber System information

Supply Chain Risk Management (CIP-013): Managing risks from third party vendors

Physical Security (CIP-014): Identifying and mitigating physical security threats

NERC regularly audits entities to ensure compliance and violations can result in huge fines.

The objective is to make sure of the reliability and resilience of the electric grid by securing critical infrastructure from cyber threats.

This info is all from: https://www.cybersaint.io/blog/what-is-nerc-cip

With some help of AI (because I wasn't sure where to start with the RTU), I made a "simple" version of it that acts as an outstation.

It holds a small in memory database of points (BIs and AIs) and an event queue. It has fixed DNP3 points, like BI with one per breaker (breakerClosed[i]) + one for the disconnector (discClosed), AI with three slots (feederAmps A, busKV kV, xfmrKW kW), BO with one command per breaker (breakerCmd[i]) and one for the disconnector (discCmd). These indices are exposed in rtu.point_map so the DNP3 knows what is there. A small adapter reads the PowerTransformer (voltage) and CurrentTransformer (current), converts to kV/A and derives kW as kV * A * PF. The scan loop (scan_once) updates the database where it writes AIs with deadband and mirrors device stats to BIs with edge detection (events only when they change). The controls, select_bo(index, value) validates Group12Var1 (needs to be 0/1 and a known point). Operate_bo(index,value) calls the actual device methods where the breaker is 1 -> close(), 0 -> open() and then updates the corresponding BI. The same is with the disconnector. Basically, this class attempts to front the "basic" devices, produce BI (binary input)/AI (analog input) events and apply BO commands (binary output, which is a command that is sent to the outstation/device). In the RTU, the events produced is the BI: breakerClosed[i], discClosed (only when they change); AI: feederAmps, busKV, xfmrKW (only when change > deadband). The commands accepted are BO: breakerCmd[i], discCmd with values 0/1 through SELECT/OPERATE.

10/13/2025-10/19/2025

• Choose substation diagram/substation setup
• What devices we need in this said substation
• Continue research into how to BUILD RTU (simple)
• Continue adding comments to devices
• Write callbacks (networking team will let us know)
• Look at NERC CIP (regulations, laws, etc)

From my understanding, it seems that only the outstation talks to the master, which in practice for our project can be an RTU or an IED that behaves like an outstation. Field devices are behind it.

May not use all the devices in that list, may have multiple devices (but need to change datapoints so they can be updated/used independently).

We have chosen to use this simple diagram that was used previously (thanks to Sam!). We need to make an RTU device (which will be very interesting).

Don't need serial command. Example: gets breaker command from the master, then calls the trip function in the circuit breaker (just simple).

I attempted to write the comments in 1 device model that it should have "these data points" and "should be updated this way". I plan on showing Kaden and seeing what he thinks. Update: This is what it is supposed to look like!

With Binary Inputs (BI, G1V2)

• BI[0] regulationEnabled - reflects whether closed loop control is enabled. On update, we set True/False whenever BO[0] operates successfully
• BI[1] controllerHealthy - the internal health of controller. On update, we set True at startup and flip to False on an internal fault (otherwise does not change).
• BI[2] inBand - whether voltage is inside band. On update (each scan) we do abs(AI[0] - target_voltage) <= voltage_margin. We write only on a change (edge detect).

With Analog Inputs (AI, G30V5 float and flags)

• AI[0] bayKV - measured bay bus voltage (kV). We update on each scan from measure_voltage() with deadband (like 0.05 kV).
• AI[1] regCmdVoltage - last commanded target voltage (kV). Update on control or controller cation when AO[0] operates or changes internal command, we want to apply the deadband.

With Binary Outputs (BO - G12V1 latch)

• BO[0] enableRegulation - 1=enable, 0=disable. Select: only 0/1, we need the controllerHealthy = True. Operate: commit, then updated BI[0] to mirror state.

With Analog Outputs (AO - G41V1 32 bit)

• AO[0] setTargetVoltaged - new target_voltage (kV). Select: numeric and within bounds, and again needs controllerHealthy = True. Operate: set target_voltage, then update AI[1] which is deadbanded.

Deadbanded means only send an update when the values changes by at least a set threshold. So it filters tiny jitter. Do event or ignore.

10/6/2025-10/12/2025

• Midterm presentation
• Choose substation diagram/substation setup
• What devices we need in this said substation
• What networking part we need
• Write callbacks
• Research RTU
• Look at NERC CIP (regulations, laws, etc)

We completed the midterm presentation this week and presented it! I went over the RTU and the substation diagram that we have found to base our bare bones substation on. I also discussed the need to write the function callbacks.

At our meeting, we decided that we need to know what devices talk to the master (so deal with communication). We need to also leave comments in the models like "this class should have these database points" and "should be updated this way". And like what the outstation should do based on these commands. An outstation is like a circuit breaker for example. We need to write some method that updates its databases whenever it gets a new current amount.

We also need to figure how the master keeps track of indices etc and log it to a file possibly? Can get updates and send commands based on that.

9/29/2025-10/5/2025

• Midterm paper
• Midterm presentation
• Choose substation diagram/substation setup
• What devices we need
• What networking part we need
• Write callbacks
• Research RTU
• Look at NERC CIP (regulations, laws, etc)

This week I primarily focused on the midterm paper. I added my discussion about RTUs and PMUs, as well as the direction we are going with the "bare-bones" substation.

We discussed with Sam our "bare bones" substation. What I found out (from last week) is it is the networking portion of the substation. We want also the PHYSICAL manifestation. We were a little confused but Sam really helped out and gave us a diagram.

There is also this website with configurations that we can use:

https://electrical-engineering-portal.com/bus-configurations-substations-345-kv

There is also this from wikipedia (https://en.wikipedia.org/wiki/File:Breaker_and_a_half.svg):

We are thinking of using this as our most basic substation design (maybe even just the top half) so we can have a working model. After this, we can determine our devices and then determine the "networking" side (which is basically what I did last week). Then, we need to build wrappers so that these device functions in Python can use DNP3 and correspond to a DNP3 command.

9/22/2025-9/28/2025

• Small Substation Example
• Research RTU
• Look at NERC CIP (regulations, laws, etc)
• Write callbacks
• Midterm paper

We will find a small substation example that has the "barest bones" of what we need to implement. Also, huge win! The networking team has made great progress. Once they finish the wrappers, we can start integrating DNP3. The device modeling team should start writing callbacks. Just a highlevel design. The system should be capable of getting requests from the master and routing them appropriately. The callback interface is still in the works but probably should be a table of functions? The master through a library will invoke functions through this interface. We also may need to decide how the interface will expose these functions. Each function in the callback table (which is all in the website below), will be responsible for handling specific datapoints/operations requested by the master. The list of operations has quite a bit but it is standardized. We need to review and implement logic for each supported operation. All this logic can be implemented in Python!

https://docs.stepfunc.io/dnp3/1.6.0/guide/docs/api/outstation/controls

After some research, I have some idea of what we can do to make the "bare bones substation". I am thinking of having

• 1 binary input called breakerClosed (index 0)
• 1 analog input called feederAmps (index 0)
• 1 binary output we can control called breakerCmd (index 0) through Group12Var1 (latch on/off)

And possibly optionally, make 1 analog output through Group41? If I am understanding correctly, we can do the master library go to wrappers (routes request, grp/var/index) and then to python callbacks (logic and update, point values and returns). The "breakerClosed" is read only feedback to the master where True means breaker is closed. This will be updated internally when a control succeeds The "feederAmps" will be read only measurement (like amps). We can hold a float and the let the read path expose it. The "breakerCmd" is the command object the master sends. The select validates (no state change). The operate or directOperate does the action. Value 1 is latch on which makes the breakerClosed = True, value 0 is latch off where the breakerClosed = False. With the analog output, we can set a target instead of doing just on and off.

During the meeting, I installed WireShark and we went through a workshop about investigating packets. We ask what protocols are being used (HTTPS/DNP3/etc), coming from/going, what physical devices are present on the network. The anatomy of the source/destination is we have the address and the port number. We have two types of addresses: IPV4/IPV6 (just unique number). Each input has a unique address. We have the port number, which is like a "door". Ethernet is the second laywer, IPV4/IPV6 is the next layer and so on. TCP/UDP makes sure packets arrive/resends. UDP is where you are willing to lose some information (watching shows, calling people, etc). Simpler devices are more likely to run UDP. 172.16 is reserved for the private network. Many times, the .1.1 is reserved for the router. What systems send a lot of small information: IoT devices, pinging a network, etc. A device usually introduces itself. 239 is like "shouting" to multiple "people". UDP communication is time sensitive, often. Cyber physical system is local, small packets sent, main device to multiple other devices that don't communicate with each other. We may want to minimize jitter to consistently send data at a fixed time interval so that we can get the derivative (which affects performance).

9/15/2025-9/21/2025

• Determine what kind of substation we are modeling
• Write out in pure English api diagram
• Look more at PMU and discuss RTU/PMU
• Look at NERC CIP (regulations, laws, etc)
• Continue research into industrial systems and network security secure protocols

Chungman brought up the fact that we have multiple types of substations (transmission, distribution, etc). We determined last meeting to focus on the distribution substation. However, Sam may want us to make a substation for transmission (PyPower) and distribution (GridLabD). We were told that distribution could have more interesting cybersecurity concepts.

Link for types of substation as well as diagram too - https://en.wikipedia.org/wiki/Substation

This is more info on the PMU - https://en.wikipedia.org/wiki/Phasor_measurement_unit

We discussed the PMU and it would be rough to implement...A hard project. Our simulations don't model the waveform itself (takes too much computational power). So, what does it mean for the time scale to use a PMU at a small scale versus a big time scale (like hours). Also, we need to ask what needs to be modeled in our simulation to make a PMU work. Also, just generally, what things in the grid would be using PMUs.

We then talked about RTUs. RTUs could be useful...and we need to look into it more as well.

We have to keep researching RTUs and see other existing software that simulates the substation. We need to ask Sam about distribution/transmission or combination of both. And also ask about OpenPDC during this meeting. And even bring up a PMU...

We discussed a lot with Sam. With the PMU, we need a higher time fidelity. It is possible to do this in GridLabD through its "dynamic mode". A PMU could be implemented further down the line, once we have the foundation figured out. If we were to do a PMU, we would have to find a specific model of PMU, what it is capable of, what it needs, and we would have to find a firmware update image of it. PMUs give more detail. They look at the distortion and allows us to find faults easier.

We asked him about a transmission vs a distribution substation. Sam said we could do a gateway in between but the main idea is distribution for now, to make it simple.

We also are going to begin building/looking into the RTU/data concentrator as well. It serves as a command point with the rest of the network. Sam said it would be great to implement.

The networking team is writing a generic DNP3 stack/library for the devices

A simple RTU model could be the outstation and serves as the master for all the devices downstream. Since the substation setup is inherently complicated, we need to determine what devices we ACTUALLY need. Our next step is to find a small substation example, the idea being "just these devices".

9/8/2025-9/14/2025

• Kickoff Presentation
• Begin looking at NERC CIP (regulations, laws, etc)
• Inventory devices
• Find basic design of substation
• Begin preliminary research into industrial systems and network security secure protocols
• How physical device connects with "computer" to produce signals, etc
• From that, determine vulnerabilities and how attackers use that vulnerability

I think with what we are trying to do, we should probably choose a standard outdoor distribution or transmission substation layout. With that, we could have a clear framework for our devices. We now need to define the communication and sensing flow (like physical sensor (current/voltage) to transformer/measurement device to RTU or IED to SCADA master via DNP3 or IEC 61850). We should probably also include elements like PMU data capture for real time measurements with timestamps and GPS sync (maybe if we go advanced).

So it seems we may need sensors/measurement units (CTs/PTs, PMUs), RTUs/IEDs handling DNP3 messages interfaces, communication infrastructure and SCADA master/simulation host where devices connect.

To begin figuring out communication and sensing flow (physical to measurement devices then RTU/IED, then to SCADA masters through DNP3 or IEC), I am going to look at some research.

The first part that I found is PMU and synchrophasor foundations.

Phasor Measurement Unit - https://en.wikipedia.org/wiki/Phasor_measurement_unit

A PMU estimates both the magnitude and phase angle of electrical quantities (like voltage or current) using a common time source, like GPS or IEEE 1588, for synchronization.

These synchronized measurements, also called synchrophasors, allow comparability of data from different points in the grid in real time which is important for stability analysis and detecting attacks.

We can map PMUs as data generating nodes that go into our RTU/IED layer or directly to a PDC, then onward to the SCADA master. We can simulate attacks like spoofed time stamps, replay attacks of phasor data, or latency introduction (assess detection through synchronized anomaly detection). We can use open source PDC tools (like openPDC) to take PMU-style data and analyze within our network simulation environment.

Phasor Measurement Unit - https://www.researchgate.net/publication/380721840_PHASOR_MEASUREMENT_UNIT_An_Overview

PMUs are implemented via digital signal processors (DSPs) that digitize analog waveforms using ADCs.

The exact same time sampling across systems is enforced using a GPS-synchronized phase-locked oscillator, giving us high precision.

Functionality wise, a PMU can be a standalone device or embedded within protective relays or other substation equipment.

The option to embed PMU functions within IEDs or relays allows for realistic simulation of how new devices slot into a substation architecture, which gives us flexibility.

Time stamped phasor data structure creates the foundation for anomaly detection, spoofed timestamp attacks, etc.

PMU - https://www.sciencedirect.com/science/article/pii/S2590123024018024 (more info on PMUs)

I also found OpenPDC and FNET. OpenPDC is a protocol that doesn't support DNP3 inherently. However, OpenPDC is an open source software framework that collects, time aligns, archives and redistributes synchorphasor data from PMUs. FNET is a wide area frequency monitoring network which demonstrates a scalable, low cost PMU like deployment.

A PMU could be nice to have in our simulation because it gives huge visibility of the grid. It makes this simulation more realistic and possibly more interesting for security research. I plan to bring it up to Sam.

There was also the mention of an RTU and I wanted to discuss it. Also look more into it.

9/1/2025-9/7/2025

• Kickoff Presentation
• Begin looking at NERC CIP (regulations, laws, etc)
• Inventory devices
• Find basic design of substation
• Begin preliminary research into industrial systems and network security secure protocols
• How physical device connects with "computer" to produce signals, etc
• From that, determine vulnerabilities and how attackers use that vulnerability

I worked on the kickoff presentation and added portions concerning the new security angle we want to tackle with the devices. I also added how we want to synthesize with the networking team concerning the DNP3 protocol and we may want to make new devices/add complexity as we move forward. Anyway, we finished the presentation and presented it! The instructors were happy with our presentation.

We discussed after the presentation where to go. We will look at current research in industrial systems and network security secure protocols. We also want to look at threat models and research best OT practices, as well as how everyting "slots" together. Sam said to not be super nitpicky with substation designs and just generally choose one. That way, we can "choose" one and slot devices in and see how everything operates together. Once we have the bigger picture, we can begin working on the security aspect of the substation simulation.

We need to learn how the system with substations senses/communicates the necessary physical manifestations (current, voltage, etc) to the "computer"/software portion of the substation. From there, we are able to develop threat models. By understanding the general scheme of how networking works within a substation, we can then see what are some common vulnerabilities (probably through research) and how they are used. From there, we can make a plan.

At our meeting, I asked Kaden if we had to change our devices from Python to C (there are some issues with that right now). He says not yet and wants us to try threading first.

In our meeting, we first want to:

• inventory devices
• find a general design to map everything to (and see if we need to add anything)
• begin preliminary research into industrial systems and network security secure protocols

8/25/2025-8/31/2025

• Kickoff Presentation
• Begin looking at NERC CIP (regulations, laws, etc)

It was our second meeting and we were in person this time. We went over federates, the simulation, etc (so on a surface level, how everything operated). We have two new members for the device modeling team, which is exciting! We decided to meet at 1:30 PM on Fridays but this may change in the future/may meet in even smaller groups since we have so many members.

We are going to begin working on the kickoff presentation, where we present where we are starting and where we are hoping to head towards. It seems we are starting to move in the direction of physical device security, which we will get some information on that.

Also, this past summer I interned at a law office and became fairly interested in law. I asked if there was any sort of law research I could do in terms of cybersecurity, etc. Sam told me that there are regulations I can look into for cybersecurity (like security compliance). He told me about NERC CIP, which is the "mandatory Critical Infrastructure Protection reliability standards set by the North American Electric Reliability Corporation (NERC) to secure the North American bulk electric system (BES) from cybersecurity risks". I am going to start looking into that and see what goes on!

We also had our first meeting as a team over discord. We discussed what slides we were going to fill out and work on. We also met with Sam over discord to talk about the security aspect of the devices. He told use there are network protocols that are inherently not very secure (like DNP3 and MODBUS). We may want to start identifying secure OT protocols. We should try to aim for a robust network stack. He also showed us a feeder protection relay (has a network protocol), which is used in substations.

This is the feeder protection relay: https://selinc.com/products/751/docs/

Kaden also provided a cool resource: https://github.com/hslatman/awesome-industrial-control-system-security

8/18/2025-8/24/2025

We went over class logistics and what the class is about. We went over the different teams, as well. Testbeds and resources to perform experiments. We went over the "why".

4/21/2025-4/27/2025

• Final Paper

We are working on the final paper for this semester! Fairly similar to the final presentation. However, sources need to be referenced.

Our final paper is complete! I referenced the sources I used earlier in the notebook. I discussed my device progress and the API writeup for the devices.

4/14/2025-4/20/2025

• Final Presentation

We are primarily working on the final presentation. I will be adding my progress with the devices, as well as the documentation with the types of data transferring between.

Progress has been added! May be refined a bit before the official presentation.

4/7/2025-4/13/2025

• Determine if the data coming from the class is an input or an output to the rest of the network (so research into DNP3)
• Fix file names/class names + delete empty files

Last meeting, we got a bit of help about the API write-up. We have to determine what the input is or if it is an output to the rest of the network (in DNP3 terms). There might be a convention in industry that determines whether it is input/input or output/output (master and device). We need to figure out the object group orientation for binary or whatever other return value. In the end, we can do what we want if we don't find it, as long as it is consistent and it works. This all means that further research into DNP3 must be done.

So, it seems that in DNP3, input is "data gathering" and output is "control commands". Inputs are usually measurements/statuses and are read by the master. The devices act as servers to keep these values and then the master can collect the data. The output is actions that can be begun and are usually written by the master. The outstation acts as a receiver of these commands and responds to them.

In essence, the master station usually requests input data from the device and it can also issue output control commands to the outstation. The outstation has input data (from sensors, readings, etc) and it responds to output commands (control actions from the master).

Here is a great resource for the above: https://www.dnp.org/Portals/0/AboutUs/DNP3%20Primer%20Rev%20A.pdf

"What do the computers talk about? Outstation computers gather data for transmission to the master • Binary input data that is useful to monitor two-state devices. For example a circuit breaker is closed or tripped; a pipeline pressure alarm shows normal or excessive. • Analog input data that conveys voltages, currents, power, reservoir water levels and temperatures. • Count input data that reports energy in kilowatt hours or fluid volume. • Files that contain configuration data. The master station issues control commands that take the form of • Close or trip a circuit breaker, start or stop a motor, and open or close a valve. • Analog output values to set a regulated pressure or a desired voltage level. Other things the computers talk to each other about are synchronizing the time and date, sending historical or logged data, waveform data, and on and on."

3/31/2025-4/6/2025

• Write up API for the objects
• Fix file names/class names + delete empty files (and look at what could be merged)

I wrote up the API for the objects, giving the priority (0-3), the protocol (DNP3 vs ICP), and the data that is being transferred from the object. Interestingly, it seems it depends on the methods within the class. I used the help of https://docs.stepfunc.io/dnp3/1.6.0/rust/dnp3/app/enum.Variation.html and AI to write out the details. The problem is, I do not know all of the devices we need to do. I did the ones I made and the ones Chungman created. I think I also did one Kaden created.

Here is an example of part of the switchgear.py:

3/24/2025-3/30/2025

• Write up API for the objects (so that data is known what to transfer)
• Fix file names/class names + delete empty files (and look at what could be merged)
• Look into the remaining objects (Station_Device, Master_Station, station_gateway, etc)/research and see which ones to begin work on

I asked Chungman what more we could do and he said now we are talking with the networking team about integration. We asked the networking team what they need from us and they said they need an API for the objects/classes so they know what data is being transferred between the devices. I have to look at the extra files on the devices because it seems there is info in it and maybe something can be merged.

A guest speaker came today and it was very informative. He discussed how there is a disconnect between theoretical/practical which leaves a lot of gaps in security. Also, most defense being developed right now is "junk", as in there are many vulnerabilities that can be taken advantage of. That is why research is so important, so that it can be thoroughly tested. Also, it is hard to protect large scale networks since there are so many points of entry. Within most corporations, there is the cyper group, the IT group, and the OT group. Each group has drastically different knowledge bases but they are intertwined. The problem is, these groups do not communicate frequently, which leaves a lot to be desired in security. There needs to be improvement here, where people, technology, and research is considered, not just technology.

3/17/2025-3/23/2025

Spring break :)

3/10/2025-3/16/2025

• Voltage_transformer_sensor
• Current_transformer_sensor
• Push the devices
• Merge devices?
• Look into the remaining objects (Station_Device, Master_Station, station_gateway, etc)/research and see which ones to begin work on

I completed the voltage_transformer_sensor and the current_transformer_sensor objects! They should also be able to inherit from the sensor_device parent class. However, there seems to be some sort of error occurring with the inheritance. I figured it out though...I have to import from the parent class sensorDevice! We have to go back and probably rename file/object names because with files, it needs to be snake case and for the class, it should be camelCase. I don't want to touch anything right now though because Chungman (or someone else) seems to have made the classes for the sensors already named like so. So right now, there are two copies of the voltageTransformer and currentTransformer, as as the sensorDevice. This will need to be discussed. They could probably be merged actually!

There is still the question of reading the value because it should be based on an actual sensor reading. Right now, I am using the random module. I will begin working on the remaining devices.

3/3/2025-3/9/2025

• Midterm Presentation
• Overall research on Sensor_Device and Subclasses (Voltage_transformer_sensor, Current_transformer_sensor)
• "The design of the sensor in electronic voltage transformer" (https://ieeexplore.ieee.org/document/5275829)
• "Voltage Transformers And Sensors For Power Quality Measurements In Medium Voltage" (https://www.electrical-engineering.academy/posts/voltage-transformers-and-sensors-for-power-quality-measurements-in-medium-voltage)
• Voltage_transformer_sensor
• Current_transformer_sensor

We presented our midterm presentation this past week and I think it went really well! We are continuing our work. For me, I am continuing research, specifically in voltage and current transformer sensors. I need to ask Chungman for help in pushing my sensor_device.

https://ieeexplore.ieee.org/document/5275829

"The design of the sensor in electronic voltage transformer" - Notes: "Compared with traditional electromagnetic voltage transformers, EVT has many advantages such as excellent insulation, immune to magnetic saturation, excellent linearity, and is suitable for digital signal processing [1], [2]."

"If adopting EVTs, we can measure the primary voltage in terms of optical principle, resistance voltage divider and capacitive voltage divider. However, the optical measurement is sensitive to the temperature, and the optical sensor is very expensive."

This paper provided a possible model for an electronic voltage transformer (EVT). It has a simple structure, it is small, measures precisely, and can be mass produced. They also can be used in medium/voltage grids. At the moment, however, it is not great for high voltage grids due to the limitations of the insulation. A substation is high voltage, so that will have to be accounted for.

https://www.electrical-engineering.academy/posts/voltage-transformers-and-sensors-for-power-quality-measurements-in-medium-voltage

"Voltage Transformers And Sensors For Power Quality Measurements In Medium Voltage" - Notes:

"Already today, voltage sensors are mainly installed in existing local network stations that require additional voltage measurement on the medium-voltage side. Measuring panels with conventional inductive voltage transformers can only be retrofitted in rare cases for reasons of space. A proven method is to mount sensors in so-called T-connectors. This solution is space-saving and the assembly is carried out by trained personnel in a reasonable time window." "For PQ measurements, frequency-optimized sensors are absolutely necessary in order to comply with the minimum requirement (class 1 according to IEC 61869-6)." "With this frequency-optimized version, PQ measurements up to 150 kHz should also be possible. In addition to good transmission up to 9 or 150 kHz, attention should be paid to the following points for voltage sensors.

• Resistance to temperature and humidity fluctuations over the entire service life
• The sensors should have the widest possible working and storage temperature range
• The hexagonal nut should be made of metal, as wear or damage can occur at higher tightening torques with a pure cast resin design.
• The overall height should be as small as possible so that the door of the switchgear can still be closed according to regulations.
• It would also be helpful to see that the voltage sensors remain undamaged in the T-connectors during the VLF cable test.
• The sensors should be purely passive in order to keep life cycle costs low."

This article presented the functionalities of voltage sensors and what they should be able to accomplish (as noted above). This can provide a good guideline for the object, as well as in the future with other implementations that we may want to consider.

2/25/2025-3/2/2025

• Midterm Paper
• Midterm Presentation
• Overall research on Sensor_Device and Subclasses (Voltage_transformer_sensor, Current_transformer_sensor)
• "The design of the sensor in electronic voltage transformer" (https://ieeexplore.ieee.org/document/5275829)
• "Voltage Transformers And Sensors For Power Quality Measurements In Medium Voltage" (https://www.electrical-engineering.academy/posts/voltage-transformers-and-sensors-for-power-quality-measurements-in-medium-voltage)
• Voltage_transformer_sensor
• Current_transformer_sensor

This week, we are preparing the midterm presentation which will essentially go over our progress thus far. In my case, it is creating an object and completing research on sensors present in substations.

2/18/2025-2/23/2025

• Midterm Paper
• Overall research on Sensor_Device and Subclasses (Voltage_transformer_sensor, Current_transformer_sensor)
• Voltage_transformer_sensor
• Current_transformer_sensor

This whole week was essentially writing the paper. We plan on meeting Wednesday to finalize some parts. I plan on using the research I have already found to discuss sensors in smart grids and then provide the work I have done in terms of making the object.

2/11/2025-2/16/2025

• Overall research on Sensor_Device and Subclasses (Voltage_transformer_sensor, Current_transformer_sensor)
• Sensor Device (overall)
• Voltage_transformer_sensor
• Current_transformer_sensor
• Midterm Paper

This week during class, two researchers came in and discussed their current research. One researcher discussed FPGAs and it was interesting. I, however, was not completely sure what an FPGA was until the end and so, some parts of the presentation went over my head. I understood the need for testing consistently, since bugs are costly. The second researcher was a recent PhD graduate and was doing research on side channel attacks (if I remember that correctly). It was amazing how noise could be used to infiltrate hardware! Again, some things went over my head but I didn't realize how big of a role hardware played in security.

I was not able to attend the meeting on Friday because of TA duties (I had to demo students) and it went a bit over time. However, I got caught up on the fact that we have to begin work on the midterm paper that is due next Thursday. The device modeling subteam is working on the introduction and each team member needs to reference two peer reviewed sources, as well as progress.

I made some progress on my objects. Specifically, I created the sensorDevice parent object. I may have to tweak things as I make the children (Voltage_transformer_sensor and Current_transformer_sensor) but I think this works for now.

The read_value method is going to be cool to implement because this is where the simulation comes in (I am assuming?) and takes in the said value (whatever that value may be). I will get some help from Chungman to push. It is a fairly simple object.

2/4/2025-2/9/2025

• https://ieeexplore.ieee.org/document/7418646 - Design of sensors for a Smart Power Substation
• https://ieeexplore.ieee.org/document/10148232 - Research on Intelligent Monitoring Technology of Substation Equipment Based on Power IoT
• Overall research on Sensor_Device and Subclasses (Voltage_transformer_sensor, Current_transformer_sensor)
• Sensor Device (overall)
• Voltage_transformer_sensor
• Current_transformer_sensor

Attempting to complete the first couple of research papers.

"Design of sensors for a Smart Power Substation" - Notes:

"A modern sensor should have the following characteristics: High linearity: to reduce the measurement errors and use of signal elaboration system with a reduced complexity. High time response: depending on the electromechanical sensors which are ohmic-inductive loads. It is necessary to act on the physical characteristics of the devices (i.e. materials, eventual air-gaps, turns number, etc.). Integration of different functions: design of devices able to guarantee contemporarily many functions, such as integrate in a single device voltage and current measurements."

"The Rogowski sensor is well studied and many applications are presented in literature: in particular in [1] is presented the application of Rogowski coil for the protection relay, in [2] is investigated a protection application with Rogowski sensors from the EMC point of view; the EMC of a Rogowski coil is very important for all of application of the sensors, because the low output voltage of the sensor can be easily corrupted by the noise and an external signal."

This research goes over modern sensors in substations and what they should be able to do. There are specifics, as well, like the Rogowski sensor. Provides insight into what a sensor should be able to do in a substation.

Research on Intelligent Monitoring Technology of Substation Equipment Based on Power IoT - Notes:

"The basic purpose of the remote image monitoring system of the power system is to transmit the real-time image information of the substation to the inspection, centralized control center and other relevant departments to provide services for power safety production. Perform real-time online monitoring of parameters such as voltage, current, power and switching value signals for onsite power distribution. Once the monitored parameters at the monitoring point are abnormal, the alarm can be detected in time, and the relevant personnel shall take necessary measures to avoid safety accidents Support real-time acquisition, automatic periodic acquisition (timed acquisition) and configurable cycle (1 minute–24 hours)."

This research provides a baseline or model to build the sensors off of (this article is particularly in-depth). Zigbee is a possible implementation in the future (a way to wirelessly transfer data). However, for right now, we simply need a sensor that will communicate data. How it is implemented (wirelessly or through a wire) is something will come along in the future.

1/28/2025-2/2/2025

• Github issues
• Research on Sensor_Device and Subclasses (Voltage_transformer_sensor, Current_transformer_sensor)
• Sensor Device (overall)
• Voltage_transformer_sensor
• Current_transformer_sensor

We figured out the Github issues by moving the cloned repository out of the OneDrive, as well as moving GitHub Desktop out of OneDrive. That way, I was able to push my work on the switchgear object to the main github.

I have also gathered several research papers to help with the development of the sensors:

https://ieeexplore.ieee.org/document/10148232

https://ieeexplore.ieee.org/document/7418646

https://pmc.ncbi.nlm.nih.gov/articles/PMC4168462/

https://ieeexplore.ieee.org/document/5275829

https://www.electrical-engineering.academy/posts/voltage-transformers-and-sensors-for-power-quality-measurements-in-medium-voltage

https://pmc.ncbi.nlm.nih.gov/articles/PMC5422181/

\https://accelconf.web.cern.ch/ibic2014/papers/wepf31.pdf

During the meeting on Friday, the device team met briefly. We discussed our next plans. My plan is looking at the first couple of research papers and gathering info on that.

1/20/2025-1/26/2025

• Kickoff Presentation
• Github issues
• Research on Sensor_Device and Subclasses (Voltage_transformer_sensor, Current_transformer_sensor)

We presented the kickoff presentation! Seems that we have a good plan for the semester. We did not meet Friday at 4 because not much was said during the last class due to the presentation and so didn't have a foundation to build off of.

Chungman and I, however, did discuss next steps (since we knew what we wanted to get started with). I thought about how to log info but Kaden popped in and said he is working on something. Chungman is going to do research on the other transformers. I am going to do research on Sensor_device and its subclasses. From there, we will build them.

I also need to figure out my GitHub issues...Which I hope to figure out this weekend.

1/14/2025-1/19/2025

• Setting up the subteam meeting time
• Introduce new members to what we are doing
• Kickoff Presentation

We went over more details about the VIP and finalized subteams. We are also starting to work on the kickoff presentation. It is due next Wednesday for the presentation Thursday. Chungman and I have finished our device modeling slides. We now need to check on the conclusion and make a final check over the presentation before the due date.

1/7/2025-1/12/2024

First week of the semester. Introduced what the team is about and some logistics.

12/3/2024-12/8/2024

• Final Paper

Turned in the final paper :)

11/26/2024-12/1/2024

• Final Paper

Thanksgiving break! We met briefly to discuss how to write the final paper.

Less pressing:

• Github Issues
• Rest of Devices

11/19/2024-11/24/2024

• Final Presentation
• Final Paper

We worked on the final presentation and presented it. I focused on discussing what we accomplished this semester as a subteam and how I created the switchgear. I was told I should look into logging systems when it comes to python since my switchgear object has print statements and it is better to log them.

11/12/2024-11/17/2024

• Switchgear Object
• Github Issues
• Final Presentation

I completed the switchgear object! By referencing Xin Zhao's work, I realized it does not need to be that complicated. I determined it needed a turn_on function, a turn_off, a trip, and a reset function (just in case it gets tripped in the simulation). I showed it to the instructor and it seemed to be good. I had to add else statements just in case something goes horribly wrong but other than that, it seemed okay. I talked to the others of how this would fit in so I can determine what other devices I need to build. The problem is, I couldn't push my changes to the repo. Something is up with my GitHub, which is unfortunate. It was recommended that I move everything to my local machine, instead of OneDrive. I think I understand what that means...I will look into it.

At our Sunday meeting, Adam, Chungman, Alex, Kaden, and I discussed the final presentation. We are going to work on that. I sent the switchgear to Chungman so he can fit it into the diagram since I am still figuring out my github. Kaden and Adam seem to be making great progress with DNP3. Alex plans on cleaning up code. I plan on continuing with the remaining devices/github/the presentation.

11/05/2024-11/10/2024

• Switchgear Object

I was still working on the switchgear object. Frankly, I am at a loss of how to do it. It is a new challenge and I am not sure how to go about it. How complicated is it supposed to be? What do I need to account for? What should I include? How detailed should it be? Kaden requested that Chungman work on the map for how the architecture of the devices would work, so I was assigned the task of completing the remaining devices (the unfilled parts, switchgear, etc).

At the meeting, we continued to work on our respective parts.

10/29/2024-11/03/2024

• ROS Document
• Switchgear Object

The ROS document was completed. Not fully, since we didn't know the answer to certain questions but we filled it out the best we could. As I looked through the repo and did some investigating, it turns out that we actually already have some transformer objects. It is not built from Xin Zhao's device class, rather, it is clearly created by someone else. I didn't know if this was a bad thing and so I asked our instructor and he said it was fine. It was fine since the device class didn't have too much being passed down anyway. Also, the transformer object would be able to work anyway in the simulation. As I did some more digging, it seems that some devices haven't been filled in yet and some didn't exist. I asked our instructor if I should get to work on switchgear (since it is a device). He said I could definitely do that and I didn't know where to start. He recommended I look at manuals of switchgear and try to replicate that as a Python object. Chungman and I got to work on it.

This is one example of a website I referenced: Switchgear Reference

The meeting on Sunday didn't have many new developments. We determined we would keep working on our respective parts.

10/22/2024-10/27/2024

• ROS Document
• Transformer Object

In class, we learned about the different network layers and the make up of DNP3 within said network layers. Chungman and I also determined to make a transformer object, based on Xin Zhao's work since I do not know much about making objects. I asked the instructor and we were informed we need a control element of some sort (something that measures physical elements). Some transformers do this through taps, so we need to implement functions for that. Like changeTap function, changeVoltage function.

At our weekly meeting, Adam, Alex, Chungman, Kaden, and Nicholas attended. We are continuing work on the bindings, the transformer object, and Alex on the circuit breaker. Alex, Chungman, and I were assigned to fill out the ROS team's document concerning our devices. Some questions definitely can't be answered now but we will try our best!

10/15/2024-10/20/2024

• Devices Notes

We were each assigned tasks of what to complete by our 10/20/2024 meeting. Kaden and Adam were going to continue working on the bindings. Alex was going to figure out how to get the timing intervals right with a circuit breaker I believe. Chungman and I were supposed to write up the devices within a substation and write some sort of API. Within that period, I looked at videos, as well as websites highlighting the characteristics of some devices within substations. Using https://www.csqelectric.com/what-are-the-main-components-of-a-distribution-substation, I was able to write up some notes on the devices.

https://docs.google.com/document/d/1ZtMHdJov7VZr7buOC4va_Zk-f20rds6Tm4KKx0wQjzo/edit?usp=sharing

At the meeting, Adam, Chungman, Kaden, and Nicholas joined (as well as myself). We determined that we need to look at the current devices that have been made (by a previous student: Xin Zhao) and see what doesn't already exist. From there, we should then make an object for it. I will probably use Xin Zhao's model.

We determined we had two options when it came to the network. We could go w/ DNP3 or make it more flexible in the future by generalizing it. We decided to make it more flexible for the future. The question arises though of how to architect all of that. Adam and Kaden are continuing their work on the bindings. There was also talk of possibly changing the meeting time because not everyone has been attending.

10/8/2024-10/13/2024

• Midterm Presentation
• Devices Notes

We worked on the presentation. I personally worked on the reasoning behind choosing DNP3 as our protocol over IEC61580 (wrote the slide for it). I then got some help with next steps since I still feel fairly behind in terms of knowledge when it comes to the others. I determined I need to have a foundation in terms of networking. So, I plan on looking into the DNP3 protocol primer, TCP/IP networking basics/wireshark, and "awesome networking".

10/1/2024-10/6/2024

• Midterm Paper
• Midterm Presentation

We worked on the paper and the organized it for submission.

9/24/2024-9/29/2024

• Midterm Paper
• Midterm Presentation

We are gearing up for our first paper together as a team. A bit of a check-in. I looked into IEC61850 vs DNP3 in terms of what protocol we should use when modeling our networks. I specifically looked into https://ieeexplore.ieee.org/document/10318666. IEC61850 is a protocol that has been used in Europe for a long time and DNP3 is more recent in terms of protocols. Towards the end of the paper in the conclusion, it highlights how IEC61850 has "better standardization and organization", "reduced configuration time", and "less physical reconfiguration" (in terms of how the substation is set up in the hardware sense and when something changes, how the network would have to change). However, DNP3 allows simple data values to be routed with a "high degree of integrity".

We discussed this with our instructor and he revealed to us that IEC61850 is complicated and very work intensive. Possibly in the future we can look into implementing this protocol but for now, it seems a bit over our heads. DNP3 may be less secure but it will be less painful fighting the protocol. It seems for now, we are sticking with DNP3.

We then discussed the idea of having a master station per substation or one central master station when we get to the point of expansion. The usual is one central master station and we are going to do this model. It seems the most applicable and simplest. Also, it easily expands into multiple substations being branched from the master station.

In terms of the C bindings, our instructor offered the idea that HELICS actually has C/C++ federates we can use if it gets too finnicky or too tough to debug.

Overall, we want to simulate an individual substation and by extension, the individual devices within the substation and how they talk to each other.

Currently, I am looking into what individual devices we can model.

9/15/2024-9/21/2024

Currently, the NIX installation is having issues...We will deal with that. It has been a VERY busy week for me.

Specifically too, we also want to identify a specific communication path to model and I am hopping on the train to do initial research on the Rust-based DNP3 implementation. Also, I hope to figure out how to prototype C/C++ bindings in Python.

I was able to successfully install NIX and copy over the repositories. However, at some point, I ran out of memory and I had to change a couple of flags.

I removed each -j$(nproc) flag because it defaults to 1 if removed. I used VIM to edit it and to edit it.

9/8/2024-9/14/2024

It completely slipped my mind that we had our meeting....Luckily, Adam put the summary. Essentially, it was what he told me last meeting. I should go through the installation steps in the README on the Github repo.

We made a Trello board where we are making general tasks to figure out what we want to do. Some of the senior members helped us get back up to speed. We determined that we had to research the substation networking structure to figure out exactly what we wanted to simulate with our networking. I learned that DNP3 is the more advanced networking protocol compared to MODBUS, where MODBUS was/is used in simple machines. Since DNP3 has more capabilities, that does mean there are more things to keep track and more things that could go wrong.

9/1/2024-9/7/2024

It is the week of the kickoff presentations. I join the Discord call and we begin dividing ourselves up to create the slides. Within the subteam itself, we have three more subteams:

• Device Modeling Subteam
• Network Protocol Integration Subteam
• Monitoring Subteam

I decide to join the Network Protocol Integration subteam because it interests me the most. I create the slide concerning the various tasks we have to do. Our team's goals are to:

1. Implement strategy pattern with handling networking communications (MODBUS or DNP3)
2. Forking DNP3 library (make custom IP address and port numbers)
3. Making the communication as efficient and secure as possible.

Using Adam's and Filippos' notebooks, I summarized the tasks we must continue.

Task 1 - Address Customization Add address customization to DNP3-Python fork to allow multiple out/master stations (could choose repeating port #/create addresses)

Task 2 - DNP3-Python Functions Take note of which functions are not fully/correctly implemented in the DNP3-Python library (may end up using different library) Try to implement above functionality as needed for the uses within our simulation

Task 3 - Synthesis between DNP3-Python and device models Work DNP3-Python into existing device models

Task 4 - Synthesis between device models and HELICS co-simulation Add device models to HELICS co-simulation

Task 5 - MODBUS Networking Integration Continue Modbus work on networking integration (need to train a new member)

-Time permitting: Network Security (explore vulnerabilities and different scenarios)

The road map for us:

For the network integration subteam, we need to understand network protocols (MODBUS, DNP3). Our primary programming language is Python and our version control is Git/GitHub.

I learn later that instead of saying Adam during the presentation, I was saying Andrew....I ask ADAM what I should specifically do to get started with the team. He told me I should make sure the repository can work on my computer, download MODBUS, DNP3, Wireshark and other resources that may be needed.

Tutorials

HELICS: https://docs.helics.org/

Python: https://docs.python.org/3/tutorial/index.html

ROS: http://wiki.ros.org/ROS/Tutorials

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

Fall 2024 Kickoff Presentation

8/25/2024 - 8/31/2024

We had our second meeting for the VIP and discussed the kick-off presentations coming up. We discussed the structure of the system.

Frankly, quite a bit of information was shared this meeting. There are two options for HELICS configuration:

• Can start each program separately and relies on programs to understand how to communicate with HELICS (run_example.sh) OR
• Can be run via a single json file where json lays out a list of federates (points to "exec", which is the specific program, can establish a "host" which allows programs to run on different servers, and names each federate with "name" (cosim_runner.json)

Transmission_simulator.py Setups

• Python script responsible for simulating transmission side of power grid. It starts by loading "Transmission_json.json" to create HELICS interface. One the simluation is setup, it executes Powerflow every so often.

Contents of Transmission_json.json

• Sets some simulation parameters (coreName/Name, coreType, timing) and establishes Pubs/Subs (key, type, global)

Girdlab-D Configuration (.glm)

• .glm files sets up entire Distribution network
• The key configuration occurs in "helics_msg" and named parent node. "helics_msg" points to another json file.

Gridlab-D Federate Configuration(.json) -It is a very similar structure to Transmission_json.json. Establishes the same HELICS federate parameters. -It also establishes Pubs/Subs

At the end, we choose our respective teams. There are two main subteams: device-modeling and ros-helics. Many people choose ros-helics and device-modeling has only a couple of people. I choose device-modeling. We set up to meet Sundays at 3:30 pm over Discord.

8/18/2024 - 8/24/2024

This week, we had the first meeting for Cyber-Physical Systems. I am in my second year and joined this VIP in the hopes of acquiring experience in research, working with others, and cybersecurity/computer science. I was especially interested in doing something that connects the physical with the cyber space, which the VIP accomplishes.

The slides went over the structure of the course, as well as the frameworks we are working with and the various moving parts in the research project. This VIP is fairly new, only starting in the Fall of 2023 so it is exciting to be a part of something new. We are trying to integrate robot coordination with CPS, specifically substation equipment, and creating a robot co-simulation environment. The following information is from the instructor presentation of Fall 2024.

CPS is defined as a physical system (the plant in this case) that is controlled by a single or multiple networked computers. The state of the physical system is seen through sensors. The state of the physical system is modified through actuators. The computers, sensors, and actuators create the control system.

A single system/local control are like drones, cars, etc. Multiple networked (distributed control) are like the power grid/factories.

The power system is made up of the following:

Co-simulation is the modeling and simulation of separate, coupled, subsystems.

The main tasks are to develop ROS/Turtlebots and HELICS Integration and to develop HELICS device models and networking interface for substation devices. Each team needs to create a technical paper that details the work that was performed during the semester.

ROS/HELICS: Preliminary simulation environment developed over the past two semesters modeling robots maintaining substation. The goal is to continue building integration between ROS and HELICS frameworks.

Device Modeling: Example co-simulation of Device Model, Transmission Model, Distribution model developed. The goal is to develop template networked device models for realistic substation functions.

Physical Modeling: Example co-simulation of Device Model, Transmission Model, Distribution model developed. The goal is to extend existing/develop new physical models to be used by other teams.

Our overall schedule for the semester is:

At the end of the presentation, we were invited to the GitHub page, the Discord, and to state preferences for subteams and project ideas.