Even if software were perfect, this makes sense as a defense-oriented decision. It's harder to hack a physical switch. Air gaps can be bridged.
There are also plenty of reasons to automate things. It allows for for faster reactions to problems and interesting new ways to reroute power. Both approaches have pros and cons, and there are good reasons for backing either approach.
Russia attacked Ukraine in a new way, and we responded by trying to become more well-defended against that new attack. Much as I agree that coding interviews are problematic, I fail to see how your point follows.
The values that we hold in the industry are often the very things that lead to problems. We love generic things that can flexibly serve multiple purposes. And then we end up with a data port (USB) that is also used as a power source. What could possibly go wrong if I plug my computer to get power, but that same connection can be used to attack my computer? We love the cloud, but what could possibly go wrong if I hook my front door lock up to it? If the IT industry built cars, rolling down the window would occasionally cause the undocumented ejection seat to kill the passenger.
It is possible to write safe and secure software. It's expensive, but it's possible.
Digitizing the grid has enormous upside, to the tune of billions in savings and improved resiliency/response to weather related outages. It we could do it safely and securely it'd be a no-brainer.
We're just trading a devil we know for a (preventable) devil we don't.
BTW: digitized grids aren't even necessarily more vulnerable. In a complex system, the increased latency and miscommunication opportunities introduced by human operators are also a potential attack vector...
The neat thing is that already basically exists in the form of voltage.
If you've ever watched your voltage, you'd noticed that it isn't a perfect 110 or 220. It is often higher or lower. When it is higher, there is a local surplus, when it is lower, there is a high load.
We could do this today. We might not have current pricing, but we do have load vs production information.
> When it is higher, there is a local surplus, when it is lower, there is a high load.
Or perhaps the voltage got too low, and an on-load tap changer in one of the transformers increased the output voltage. Voltage does not necessarily follow the load. AFAIK, the thing generators themselves use as the main feedback signal is not voltage, but frequency; but it's not a useful signal for consumers, given that generators are much stronger at keeping the frequency at its nominal value.
Load causes the voltage to drop (that's what's happening when a "brown out" is triggered). Some loads cause the current to lead or lag the voltage wave (Inductive vs Capacitive loads, most are Inductive, particularly with heavy duty equipment). But that isn't changing the frequency but rather the phase of the current. This is all tied up with a number referred to the "Power factor" (see https://en.wikipedia.org/wiki/Power_factor ). essentially, the farther shifted current is from voltage, the more work is done by the power plants essentially heating grid wires (rather than doing something useful)
So, power grids will do 2 things. First, they'll work to keep the current and voltage phase in sync. They do this by adding extra capacitors/inductors.
Second, they work to maintain the voltage of their tie in to to the grid.
Generally speaking, the type of power plant matters as well. Base load plants will simply dump onto the grid at a constant rate (without really caring about what the voltage is) while peaker and load following plants will attempt to vary output relative to their voltage to try and keep the grid voltages stable.
You are correct, the voltage variance can be misleading at the customer level if the transformer is actively adjusting it's voltage ratio. I didn't consider that.
I don’t think we should go back to manual operation (as the default, but should be overridable). Instead we should be using stricter compilers, and better unit, integration tests, and fuzz testing to test as many edge conditions as possible.
Not to be a pessimist, but just because a software error never caused a catastrophic space shuttle accident doesn't necessarily mean that the software actually was safe and secure.
There are also plenty of reasons to automate things. It allows for for faster reactions to problems and interesting new ways to reroute power. Both approaches have pros and cons, and there are good reasons for backing either approach.
Russia attacked Ukraine in a new way, and we responded by trying to become more well-defended against that new attack. Much as I agree that coding interviews are problematic, I fail to see how your point follows.