Hi, I’m Dmytro.
I’m a software engineer trying to understand the electrical grid: how it works, where software lives inside it, and what happens when networks, devices, and physical processes have to work together.
Software in the Grid is where I explore that world. I follow systems through their layers, rebuild simplified versions, and use code, diagrams, and experiments to make the machinery easier to reason about.
If you’re new here, start with the grid itself or the networks connecting it. Software Foundations is the supporting section for the lower-level ideas behind those systems.
Software in the Grid
The main focus is software in power infrastructure: substations, SCADA, industrial networks, and the protocols connecting them. I’m interested in how these systems communicate, how they are tested, and how timing, security, and failures affect their behavior.
Understand the grid. Start with a map of the European power system: the physical machinery, the organisations operating it, and where software fits.
Follow the network. Start with Ethernet and IP, then follow the machinery into Linux, substations, and industrial protocols. The question underneath it all: what changes when packets carry measurements, protection events, and commands?
Software Foundations
This section holds the deeper work on networking, operating systems, security, cryptography, and time. These projects stand on their own, and they also build the understanding I draw on when exploring grid software.
TLS: build an incomplete protocol, find what breaks, and work toward encryption, integrity, key exchange, certificates, and trust.
Cryptography: explore the machinery underneath, from ciphers and hashes to message authentication and public-key encryption.
Time: follow timestamps down to Linux clocks, drift, NTP, PTP, and the problem of getting several computers to agree on “now.”
HTTP and operating systems: Building Your Own Web Server follows requests through sockets, TCP, concurrency, and operating system interfaces. It is where this rebuilding habit started.
How I work
I usually begin with a smaller or deliberately incomplete model, make it work, and find the assumption that breaks. Then I introduce the next piece because the problem makes it necessary.
The finished technology often hides the reasons for its own shape. Broken versions are much less polite. They show you exactly what is missing.
You can find code and experiments on GitHub. I publish as I learn, so the map keeps changing as I understand more.
If you want to follow that work, subscribe to Software in the Grid.