To start this semester, I gave an overview of the device modeling teams progress to date. Some of those key points were as follows:

• A tiered object oriented design for devices (ie having a base device class that is inherited for process, bay, and station level devices)
• Functional models for some simple devices
• Example scripts showcasing the above functionality
• Research into powerflows utilizing machine learning
• A working example of the Modbus protocol using pyModmus
• A working example of the DNP3 protocol using dnp3-python

I consulted the previous final presentations for this course to give this summary. You can find them here.

1. Fall 2023 Final Presentation

2. Spring 2024 Final Presentation

After discussing our previous progress, the team self-selected themselves into our subteams within Device Modeling.

1. Device Modeling Subteam: Vidur, Zaeem, Xander, Nicholas
2. Network Protocol Integration Subteam: Adam, Maria, Kyle, Alex, Chungman, Kaden
3. Monitoring Subteam: Dhruv, Albert, Ethan, Reva

Following this, I recommended that the each person review past members notebooks, particularly notebooks from people previously in their subteam. That aimed to get them introduced to exactly what future plans their predecessors had. It would also introduce them to the problems we had already run into and how to solve them. Thus, we could prevent duplicated work

We also made our kickoff presentation. This contained what we think will be our goals for the semester, although priorities are always shifting as we learn more about the problem. Fall 2024 Kickoff Presentation

This week I reiterated the problems with the existing DNP3 repo.

There are clearly many issues with the repo. The plan I had at the end of last semester was to fork the dnp3-python repo and attempt to complete and correct the missing functionality. The other option is to find a new, more complete repo for DNP3. Unfortunately this seems to be the most complete python library, although other repos like dnp3 by Step Function I/O exist for alternative languages like Rust.

This leads into the checklist of future plans we had at the last semester.

• Select another DNP3 library or modify/fork the current library
• Create a class that will handle the protocols automatically
• Add this as a property of a device, in device_modeling project
• Make a simple encryption to the values sent by these protocols
• Add libraries to the Nix environment

We decided to make the following our tasks for the semester. They represent a mix of the previous plans and new adjustments we decided on.

This week we decided that the dnp3-python repo would not be sufficient for out purposes. Although attempting to fill out the missing/incorrect functionality sounded like a great learning opportunity, we want to choose a new repo instead. Here are a few of our reasons:

• The quantity of missing functionality
• The complexity of DNP3
• We only have a simple understanding of DNP3, not enough to realistically implement the protocol
• dnp3-python reached end of life in 2022

Kaden proposed that we could still use the dnp3 library made by Step Function I/O. Step Function I/O already provides bindings from Rust -> C. Then we could make the bindings from C -> Rust.

I was initially skeptical of the idea because I was unfamiliar with bindings and it seemed strange to chain the bindings like that. However, because the C bindings were already created, we only had to concern ourselves with the Python bindings. I found this StackOverflow article to be helpful understanding how to connect C to Python. Rust->C->Python

This week I focused on learning about and understanding the C -> Python binding work utilizing ctypes and shared libraries. For ctypes specifically, I found reading through the Python docs to be the most helpful. Particularly for understanding how I would access the functions in the shared library when writing the python classes for the DNP3 outstation and master station. There is a LOT of content in that doc that could be overwhelming so don't feel the need to understand or read everything. The most important section to me were the following:

• Loading dynamic link libraries
• Accessing functions from loaded dlls
• Calling functions
• Fundamental data types

If you are someone that just doesn't like trying to understand the docs, I found this article gives a solid overview of what to do.

Kaden and I set up an example dnp3 repository to mess around with ctypes and the shared library before adding it to the main cps-cosimulation-env repository later on. That can be found here. The files in there are from Step Function I/O's C bindings. Then Step Function I/O also demonstrated an example of the master and outstation communicating via the command line. Our goal will be as follows.

• Replicate the command line example within example repository using master.py and outstation.py instead of the C classes
• Decouple the example from requiring input from the command line (class methods should control the communications)
• Implement the outstation in the co-simulation repository
• Implement the master in the co-simulation repository
• Demonstrate an example of a modeled device with an outstation sending data to a master station in the co-simulation repository

This week we focused on the midterm paper. We started by using last year's final paper as a base. Although this was good to give the new members an idea of the kinds of content and formatting needed in the paper, I think there was probably more reused content than there should've been. The midterm paper is always difficult because by this point most people haven't or are just starting to make real progress. This was probably the most important cause of the reused content. With the final paper later this semester, we should have more original content to contribute as a sub-team.

I'll link our submission for the midterm paper here. My main contributions were in the executive summary, the DNP3 section, and some general editing across the paper.

Like last week, we didn't make much progress. Instead, our time was spent creating the midterm presentation. I'll link the presentation here as well. My contributions were the project goals, roadmap, and some of the DNP3 content. As one of the few returning members, I also had a guiding hand over the entire presentations structure.

Even though I've been with the VIP for a few semesters now, this was my first time making a project roadmap. I used onlinegantt.com to create it. It was free and easy to use. I'm sure there are also many other free alternatives out there.

I liked the ease to break down the tasks into subteams and color code it all. I think I could've improved the way that dates are displayed. It just seemed a little messy to me. Another site might also improve that.

Before the midterm presentation and paper, I had outlined the following goals.

• Replicate the command line example within example repository using master.py and outstation.py instead of the C classes
• Decouple the example from requiring input from the command line (class methods should control the communications)
• Implement the outstation in the co-simulation repository
• Implement the master in the co-simulation repository
• Demonstrate an example of a modeled device with an outstation sending data to a master station in the co-simulation repository

Before I could begin the work on these, I needed to read and understand how the c files in the dnp3 example repository worked.

At first I wanted to read all of dnp3.h. This is essentially all of the Rust stuff that was deemed important enough to port to create the C API. Thus it is over 8000 lines long and WAY too much to just read. Instead I just kinda skimmed the functions that had master or outstation in the name. This introduced me to important functions like dnp3_master_channel_create_tcp. It conveniently has function documentation with it that explains the parameters and exactly what the function does (Important because you can't see the Rust implementation that is associated with it easily).

Then I read over /default_example/master_example.c. This was important to see how a lot of the stuff in dnp3.h actually gets used to create an implementation of the master station.

Reading over all of this and trying to understand it took such a long time that I didn't actually get to code and make progress on that front.

This week I was able to make some progress on coding master.py in the example repository. You can find my commit here.

The main changes were in master.c and master.py. I removed most of the functionality from master.c that wouldn't be useful to this example. For example, we are only interested in tcp at the moment, so I got rid of the serial channel code. I also made some changes to make it more flexible. For example, dnp3_master_channel_config_t get_master_channel_config used to take no parameters and hard coded the master channel's dnp3 address to 1. This would make multiple masters impossible since they would share a dnp3 address. This won't be suitable for our architecture since we plan on having multiple master stations inside of the simulation.

I also gave my first attempt at creating mater.py. This uses ctypes which I learned about a few weeks ago. It takes the shared library from compiling master.c and allows me to access functions like create_master_channel_config(int master_address) from Python. One interesting thing with this is that I can't just import a custom type/structure from that shared library. For example that function returns a MasterChannelConfig. In order to specify that, I needed to create a class with the header class MasterChannelConfig(Structure): in config_classes.py. Then I was able to specify the fields in that structure like the address and buffer size. There I am able to import the primitive data types like c_uint16 for the equivalent to a python int (16 bits).

This week I was able to make even more coding progress with the dnp3 example. I pushed a commit that had the base of a working solution, except I am encountering a segmentation fault when I try to run main.py using my Master class.

Main.py until segfaults

Main.py works with master and outstation

Move example files into main repo

circuitbreaker example in main repo showing outstation and master communication

Thanksgiving

final paper, current limitations, next steps

This week we welcomed the new members to the Device Modeling subteam. Filippos, Vidur, and I are the only returning members from the Fall '23 semester. We presented an overview of the Fall 2023 Final Presentation to catch our new members up to speed. The most important parts were the targets and goals we didn't reach last semester as that is a natural starting point for this semester's work.

Our task this week was to create the kickoff presentation. We were able to use the feedback from last semester's kickoff to create a better presentation. Specifically, we better focused our presentation to revolve around the critical infrastructure grant. This included adding a context slide about the US power grid where we specified our research would focus on simulating the substations. We also tried to include fewer walls of text, and more visuals. However, we thought it was still important to have enough text that someone from a future semester could look at it and understand without our live commentary. We also changed our roadmap from a basic graphic to a Gantt chart with approximated timelines.

Old Roadmap (top) vs New Roadmap (bottom)

Here is a copy of the complete Spring 2024 Kickoff Presentation

(fill in details later)

• error running simple_gridlabd_example? even though it worked before. TODO: look at old notebook entries for guidance
• initially didn't have permissions to run ./run_example, but was able to search for solution and use chmod to give execution permissions chmod command
• current error is ImportError: No module named scipy.io
• verified that this line was always in the script
• verified scipy is installed. Maybe scipy.io is different somehow?

TODO:

• enhance last weeks notebook entry with links, external sources, etc

• fix errors preventing me from running simple_gridlabd_example's ./run_example.sh

• starting to go to Thursday meetings. Disconnected me from the project team. I can catch up on my networking class at another time, it isn't as difficult as I thought so attendance is not required.

• realized I never used the nix develop command after looking through old entries smh

• got error using nix develop

• missing some files from repo like flake.nix, git pull didn't bring them back so I cloned the project again

• able to run simple example now TODO:

• meet with team to discuss assignments

• implement dnp3 communication between circuit breakers and voltage sensors class. sensors read dangerously high voltage -> flip breaker

• attempt to run dnp3-demo from repo. error saying missing module pydnp3. first pip install pydnp3 (failed building wheels). Then tried pip install dnp3-python. Successfully ran after that.

add src as root sources stuff to overcome pycharm issues. explain goal to create a demonstation of dnp3 with circuit breaker we have modeled.

explain how i added dnp3 to circuit breaker. commit it to github and link. explain how I created the script to run an example of the circuit breaker reading current values from dnp3 outstation. explain confusion on group and variation. explain limitations listed in midterm presentation and future plans.

TODO:

• Read the DNP3 Specification to get a better understanding of how it works. Specifically the group and variation tags.
• Add progress to notebook entries in weeks 2/18-2/24 and 2/25-3/2
• Revise all notebook entries in the Spring '24 semester to include the following improvements: external supporting resources like stack overflow pages and website tutorials that were helpful to debug issues, TODO lists with checkboxes clearly display progress completed that week and tasks to complete in future weeks, and improved frequency

I pushed the dnp3_circuit_breaker_py file to GitHub. When I went to stage the file and commit it, the process went smoothly. However, when I attempted to push it, I got a message that password authentication was no longer supported.

I followed the link in the screenshot to GitHub's page about remote repos. I learned that I needed to create a personal access token to act as a password. To do that, I used GitHub's page about managing and creating personal access tokens. I was easily able to create a token and use it in place of my password on the command line push.

Those images were way too large when I originally uploaded them, so I followed a Stack Overflow question to resize them.

I also read into the group and variation aspect of DNP3 which I was confused about in the DNP3 Primer Article. Some key highlights:

Static, present value, analog data can be represented by variation numbers as follows:

1. A 32-bit integer value with flag
2. A 16-bit integer value with flag
3. A 32-bit integer value
4. A 16-bit integer value
5. A 32-bit floating point value with flag
6. A 64-bit floating point value with flag The flag referred to is a single octet with bit fields indicating whether the source is on-line, the data source restarted, communications are lost with a downstream source, the data is forced and the value is over range.

Event analog data can be represented by these variations:

1. A 32-bit integer value with flag
2. A 16-bit integer value with flag
3. A 32-bit integer value with flag and event time
4. A 16-bit integer value with flag and event time
5. A 32-bit floating point value with flag
6. A 64-bit floating point value with flag
7. A 32-bit floating point value with flag and event time
8. A 64-bit floating point value with flag and event time The flag has the same bit fields as for the static variations.

Static analog values are assigned as group 30, and event analog values are assigned as group 32. Static analog values, group 30, can be formatted in one of 6 variations, and event analog values, group 32, can be formatted in one of 8 variations.

Those values can be used as a quick reference in the future. Additional groups, variations, and their meanings can be found here.

TODO:

• Fix issue in demo where values take 2 passes to update when sleep(1) instead of sleep(2)
• Change implementation so that master polls the outstation then outstation sends data (maybe that is already happening? and is why the data isn't always updated immediately?
• Learn what outstation.add_outstation_app(cls, outstation_id, outstation_app) does
• Learn what outstation.set_outstation_application(cls, outstation_application) does
• Learn what outstation.process_point_value(self, command_type, command, op_type) does
• Learn what outstation.configure_database(db_config) does
• Learn what outstation.configure_stack(self) does
• Learn what the masterstation commands to as well (started to become too many to enumerate)

Before Spring Break, one my of goals was to understand the methods that are implemented in the dnp3-python library. I am already familiar with some of the methods like .start(), .shutdown(), .apply_update(measurement, index), and .get_val_by_group_variation_index from creating the dnp3_circuit_breaker.py demo script. However, I know that the library has many more methods and functionality to offer because DNP3 is a robust protocol.

I created a script called dnp3_functions.py. My goal is to add examples of each function offered by dnp3-python being used in a sample context. This will serve to educate future students on how to leverage the library effectively when contributing DNP3 code to our VIP.

At the moment, I've only added examples of .start, .get_config, .add_outstation_app, and .get_outstation_app. However, as I become more familiar with the methods in dnp3-python, I plan to add more so that it can become a comprehensive resource on dnp3-python. I've uploaded the file to my branch, and it can be accessed here

This week I tried to improve on the limitations of dnp3_circuit_breaker.py. In particular, I want to overcome the current limitation of only using 1 outstation and 1 master station. As a recap, the current implementation has a single "sensor" reading random current values. The sensor's outstation sends the floating point value to the circuit breaker's master station. The circuit breaker then reads the value and trips the breaker if the value is too high. I plan on adding a second sensor that sends its own values +- 2 from the first sensor's reading.

In order to differentiate the readings, I will send values from sensor 1 on index 0, and values from sensor 2 on index 1.

The above image is the implementation I came up with. However, when running the script, I noticed that the behavior was not as expected. First, there was a warning printed to the console that an address was already in use. Second, the breaker did not read a valid value from the second sensor. The screenshots are displayed below.

I think both issues will be resolved if I can find a way to manually set the ports that each DNP3 object uses. To do this, I will need to find the illusive documentation for the library, or find the source files and figure it out myself.

This week, I tried yet again to search for existing documentation about the dnp3-python library. I want the documentation so I can better understand the library, particularly how to customize addresses. I searched the PyPi page where I found the library originally. It claims to be a thin wrapper around opendp3 classes and says documentation can be found here, but I have never been able to load the site.

As an alternative to the official documentation, I decided to search for the source code to make sense of it myself. I knew that the GitHub repo was located here. I had struggled to make sense of which files were actually relevant to the Python code I was writing. To help me find the right filenames, I used PyCharm's Go To -> Implementations feature.

From there, I found the outstation_new.py and master_new.py files that defined the methods for each station.

In the GitHub repo, I was able to find these same files through the src -> dnp3_python -> dnp3station path.

At this point I didn't have much time left to analyze the contents of the classes, but I noticed some red flags.

As you can see, many TODO comments are still in the code. Some functions don't work properly, and others have a pass keyword instead of an actual implementation.

This will have to be fixed, or another library will have to be used.

This week, I spent most of my time focused on the Final presentation, which can be found here: Spring 2024 Final presentation.pptx

The key highlights were summarizing my attempts to create a second outstation and realizing that it was not possible because it tried to use the same address used by the first outstation.

Since last week, I did have more time to look at the implementation of the DNP3 stations. There is currently no way to customize the addresses when instantiating a station. Every outstation is hardcoded to the same IP address / port combination. The same is true for the master stations.

This should be a relatively simple fix. My proposed solution is to fork the repository. Then, I will change the constructor to take in port and id values for itself and the station it wants to connect to. Then use those values for creating the addresses. This makes it possible to have multiple outstations and master stations. However, it is not impossible to choose a repeating port number. We should probably implement safeguards against this. Perhaps by changing the implementation to maintain a static, class list of all used ports. Then, when a station is created, choose a port that is not being used.

Perhaps this kind of error avoidance could be better implemented in another way.

This week, we modified our Midterm paper to include our progress to date. Like usual, my contributions focused on the Networking Integration, particularly DNP3. I link the final submission here. Device_Modeling_Team_Research_Paper_Spring_2024___Final.pdf

To fix the issues we noticed with the dnp3-python library next semester, it is necessary to fork the repository. I looked up how to fork a GitHub repository. I created a fork on my personal account, and the repo is located here.

Currently, it has no commits that differ from the original repository. However, this will serve as a starting point for my work in the Fall 2024 semester. It is a public repo, so anyone can view it. At the moment, I am the only collaborator, but I can invite others next semester who are also interested in working on the fork. I've cloned it to my local machine, and created a branch called addresses where I will work on solving the address issue.

Fall 2024 Todo

• add address customization to dnp3-python fork to allow multiple out/master stations
• note which functions are not fully/correctly implemented in the dnp3-python library
• attempt to implement the above functionality as needed for the uses within our simulation
• work dnp3-python into existing device models
• add device models to Helics co-simulation

In addition to the duties above, I will also help to train a new member on the Modbus parts of the networking integration. Filippos will be graduating, and since he was our Modbus expert, someone else will have to continue his work.

• Create GitHub notebook

Researched GitHub's basic formatting syntax and used it to set up this notebook.

Downloaded and set up WSL2 (Windows Subsystem for Linux)

Worked on getting the simple_gridlabd_example to work on my computer by using './run_example.sh'. Initial error was that had no file or directory found to write to.

/results/broker.log
/results/DistributionSim.log
/results/TransmissionSim.log

The solution was to create the 'results' folder manually. Then, the log files were created by the script.

Now encountering the following error, libstdc++.so.6: cannot open shared object file: No such file or directory.

I decided to run ./run_example.sh again this week to solve the error. I was surprised to find that I was getting a new error.

I reinstalled python and started getting errors that certain modules weren't found. I installed them one by one until I realized that I hadn't done nix develop before running the simulation.

After running nix develop, I was back to my original error from last week.

After some fixes were pushed to GitHub by the instructors, I am now able to run simple_gridlabd_example. However, there is no popup with a GUI that shows the graphs associated with the example. That is something to look into for the future.

This week we had our first Interim Progress Report (IPR). As the Device Modeling subteam, we took on the role of an employee at Pacific Northwest National Laboratory (PNNL) as we did for the Kickoff presentation. In this hypothetical scenario, we presented the progress we had made with the $1M program funding we had won from our earlier presentation. My individual responsibility in the slide was to create and present the introduction as well as an overview of our progress to date. The presentation was scored by this rubric

One of the most important outcomes of this presentation was breaking down the roles of individual team members for the rest of the semester. I will be working with Filippos to focus on Network Protocol Research and Integration. Now that this has been decided, I can narrow my research to specifically focus on the networking/communication side of our simulated substation. As the semester progresses, I may choose to organize recurring 1 on 1 meetings with Filippos to discuss our research and plans for implementation.

Our work for next week will primarily focus on the midterm paper. We will use our IPR1 presentation and our research documentation to write a research paper. Unfortunately, we haven't been able to perform much research of our own within the simulation because we are working out bugs. Therefore the paper will mainly be our research and some suggestions for future work.

We divided the responsibilities for the midterm draft as follows.

• Executive Summary: --- Xin
• Introduction: --- Connor & Amani
• Previous Work:
• • 3.1 Co-Simulation for Substation Modeling --- Xin
• • 3.2 Integration of HELICS and GridLAB-D --- Amani & Zaeem
• • 3.3 Model Validation --- Xin
• • 3.4 Data Exchange and Communication --- Adam & Filippos
• • 3.5 Solving Power Flow Equations --- Vidur
• Research Sections:
• • 4.1 Substation Device Co-Simulation for Voltage Regulation --- Xin
• • 4.2 Formal Verification --- Xin
• • 4.3 Integration of Network Protocol --- Adam & Filippos
• • 4.4 Power Flow Equations and Alternative Solving Methods --- Vidur
• Conclusion:
• • 5.1 OOP-Powered Simulation Model Repository --- Connor
• • 5.2 (Require input from the Co-simulation subteam regarding ideas and approaches for the framework and integration) --- Amani & Zaeem
• References

With this delegation, the structure of the paper should flow easily. In accordance with the roles we discussed last week, Filippos and I will be researching and developing the network protocol and communication aspects of our substation simulation.

In other news, the paper deadline got pushed back 1 week so we have more time to organize our research before submitting.

This weeks major progress came from writing and submitting the midterm paper draft.

Co-Simulation, Device Modeling, and Formal Verification: Fortifying Smart Grids for National Security

I've linked the entire paper above, but in case the google drive hosting fails, I will paste my major contributions below.

Effective communication and data transmission within a substation is crucial to establishing a reliable and efficient smart grid. The growing complexity and scale of technology within substations have led to Intelligent Electronic Devices (IEDs) with an extensive array of data points to transmit. To address this need, a new industry standard for intra-substation communication, IEC 61850, has been introduced. However, it is important to note that the implementation of the IEC 61850 protocol is not currently within the scope of our simulation. Instead, we will explore alternative network protocols, such as MODBUS and DNP3 [11].

MODBUS, which was developed in 1979, operates on a master-slave relationship between a central control unit (the master) and individual devices (the slaves). In this setup, the control unit initiates various network operations and awaits responses from the targeted devices. MODBUS is generally known for its simplicity and ease of implementation, making it a popular choice. However, it lacks some of the advanced features offered by protocols like DNP3. It’s worth noting that MODBUS typically requires more bandwidth since it transmits messages as collections of 8-bit characters. Despite this, its versatility has made it applicable in various industries.

On the other hand, DNP3, which was published in 1993, also follows a master-slave relationship. However, DNP3 is tailored for power substations [12], offering more specialized functionality within the network protocol. For example, DNP3 provides support for more robust data types compared to MODBUS and includes the ability to timestamp events, a feature absent in MODBUS. Furthermore, DNP3 messages are encoded into bit strings, allowing for the transmission of more information while utilizing less bandwidth than MODBUS.

In summary, the choice between MODBUS and DNP3 depends on the specific requirements of the application. MODBUS is suitable when simplicity is a priority, while DNP3 excels in efficiency and offers a broader range of functionalities, making it a better choice for applications within power substations.

For further reading into the communication you can reference the following sources I used.

Source 1

Source 2

This week we set up some goals for this semester. Even, if we don't manage to complete it all, these will give us direction into the Spring 2024 semester.

Network Protocol Integration Subteam

• Task 1: Set up the co-simulation environment and run the simple_gridlabd_example (Completed)
• Task 2: Communication Protocol Design Research specific scenarios and define communication protocols for data exchange between devices, the bay controller, and protection relays. Select suitable communication standards and design message formats.
• Task 3: Protocol Implementation Develop code to implement the chosen communication protocols. Ensure that devices can transmit and receive data using these protocols.
• Task 4: Simulation Data Exchange Enable data exchange between GridLAB-D and HELICS through the established communication protocols. Test and verify the reliability of data transmission.

In the coming weeks we will focus on Task 2 and create protocols for communicating between devices within our simulated substation.

Happy Halloween!

We realized that creating protocols was both too ambitious for our timeframe and completely unnecessary. We ended up finding python packages that have already implemented MODBUS and DNP3. We will be learning how to use these packages, PyModbus and dnp3-python, to implement interdevice communication.

PyModbus documentation

dnp3-python documentation

I realized that I should copy the feedback we got on both IPR1 and the midterm paper so that future students can learn from some of the mistakes we made.

IPR 1 Presentation Feedback 12.5/15 (Target Audience Calibration 3.5/5, Concept Clarity 4/5, Roadmap 5/5)

The team presented a very solid improvement over the kickoff, and the technical direction was clear. Walking away from the presentation, we had a clear >sense of the concrete tasking you hoped to accomplish over the remainder of the semester, and the presentation of the progress to date clearly indicated >you have begun to put your plan into action.

The primary critiques we have deal with the structure of IPRs within research timelines. First, you do a good job laying out the problem in your >introduction, but then it is not immediately clear how each of your sub-tasks contribute to solving this problem. The Gantt chart provided provides some >linkage, but a transition slide showing how each subtask composes and contributes to the overall goal would be useful for audience members not >immediately familiar with your project.

Additionally, while your Gantt chart is a great step in illustrating the dependencies between each subtask, it is not clear what the “% Complete” metric >you provide is derived from. Practically, these metrics are either time-based (a task has a defined start and end date, and the % complete is how much >time has elapsed), or a task is decomposed into very granular sub-tasks and milestones (% complete is then based on how many of those tasks are >completed). Finally, the 1-15 columns you include don’t seem to be based on your schedule. All told, this is a great inclusion with the limited project >direction background available to you, but incorporating this feedback will greatly enhance the next version.

I have very little to say about your technical direction, since it seems exactly in line with what we hoped for. If you accomplish everything you set >out to do here, I would be very pleasantly surprised, but I look forward to seeing your results develop!

Aside from the explicitly written feedback, you can notice that we only got 3.5/5 points for audience calibration. We should have placed more emphasis on the context scenario. Particularly that we were looking to showcase the results of the "funding" we had received and our desire to continue to receive funding.

Midterm Research Paper Feedback - 90%

Overall, this paper is an excellent start to documenting your research activities. It presents a reasonably thorough survey of relevant literature, and >how you plan to apply existing methods or technologies to your research problems. These comments are general for the overall submission, and specific >recommendations and comments are provided inline for the submitted pdf.

I generally only had two small issues with the current state of the paper. There are a few places where local structure was slightly abrupt, and more >polish could have been applied. Lastly, there were two places where slightly more information would be appropriate for a full conference submission, and >I provided references to shore those up.

All in all, this paper is a great draft of your final research report, and I look forward to seeing the final documentation of what you accomplish.

I have linked our IPR1 presentation and Midterm Research Paper in earlier sections, but I will do so again for convenience.

Device Modeling IPR1

Midterm Research Paper

Filippos created a simple demo for the Modbus python package. It consisted of a slave and master script. By running them in separate terminals and setting them to the same port, they are able to transmit data.

Modbus Master File

Modbus Slave File

I have been attempting to do something similar to this with the DNP3 package but I am having difficulties understanding the documentation.

Happy Thanksgiving

On a serious note, no further progress was made on account of Thanksgiving break.

I was able to run a basic demo of the DNP3 python package. I'll show the terminal output below.

The code for the demo can be found in the repo under Adam/McAndrews/dnp3 branch. I will link it below for convenience.

DNP3 Demo Code

I hope that this demo can be used to implement communication between our devices in the Spring 2024 semester. It will need some adaptation to fit it to our devices, but nothing dramatic.

Next semester, I can also look into adding a tutorial for installing the dnp3-python package so that future students can catch up quickly. Additionally, it may eventually be added to the initial installations all students do for our VIP.

The last week! I'll try to not sound too excited about that ;)

This week we finished up our final term paper. As I'm writing this now, I realize that it was just meant to be a revision to our previous paper. Instead, I completely rewrote my section, and I think a lot of my peers did too. Oh well!

I've pasted my major contributions to the paper below.

E. Communication and Data Transmission

To ensure the reliability and security of the smart grid, safeguarding each substation from unauthorized influences is paramount. The communication platform employed within a substation can be a potential vulnerability, particularly in the context of cyberattacks [10]. While numerous networking protocols are in use globally, a protocol must be meticulously designed with security and reliability at its core to be deemed suitable for deployment within a substation.

Let us delve into the key factors that constitute an ideal network protocol:

• Security: The protocol must effectively protect against and detect malicious requests from unauthorized users.
• Reliability: It should mitigate packet loss and validate data integrity to identify and rectify corrupted packets.
• Efficiency: The protocol needs to be lightweight enough to run on devices with limited computing power. More- over, it must facilitate prompt responses to critical events within the substation.

In our research, we aim to model a substation using two network protocols, namely Modbus and DNP3. Consequently, it is imperative to assess each protocol against the aforementioned criteria.

Modbus is a straightforward and efficient protocol implemented in a master-slave relationship. Variants of Modbus leverage different transport-level protocols like RTU and TCP. Underlying protocols, such as TCP, incorporate an acknowledgment system to enhance the reliability of Modbus transmissions. Notably, Modbus lacks robust authentication methods, making it suitable for scenarios where swift communication is crucial. Its simplicity allows implementation in devices with limited computing resources. However, the absence of authentication and other security measures renders it less secure [11].

On the other hand, DNP3 is a more intricate protocol offering additional features compared to Modbus. For instance, DNP3 supports time-stamping communications, facilitating more accurate log analysis for unexpected system behavior. Unlike Modbus, DNP3 allows the ”slave” device to send unsolicited responses, enabling the creation of alerts for unforeseen hazards detected in the substation. Secure DNP3 incorporates basic authentication and encryption, though it remains susceptible to attacks [11]. However, the additional functionality comes at a cost, as the associated overhead may render DNP3 less suitable for time-critical situations [10].

Upon comparing Modbus and DNP3, it becomes evident that each protocol has its niche within our simulated substation. When slight delays are acceptable, the advantages of DNP3, including enhanced security features, become particularly relevant. Conversely, in scenarios where speed and simplicity are paramount, and the substation is isolated from potential external threats, Modbus may prove advantageous for facilitating efficient communication among substation devices.

I'll link the (almost!) finished version of the paper below. Some people were still revising or completing their sections so it isn't quite the final product yet.

Draft of Final Term Paper