The smart grid concept seeks to reduce the future need to build power plants by rapidly shuffling power from many different sources to many different areas. It is a a computer controlled juggling act design expressly to eliminate any redundant capacity in the grid. It will eliminate compartmentalization in the grid in order to efficiently move power over long distances (such a from solar plants in Arizona to New York.)

I think the smart grid concept is your classic top-down design intended to accomplish goals largely unrelated to the function of the core system. Like all such systems, it will fail when it comes in contact with the real world.

I may just be picking at semantics here, but dynamic pricing and price response by demands and distributed generators don’t strike me as making the coupling looser. It seems to me that today’s power system is economically disconnected from most of the physical loads drawing energy from it. This disconnect causes dislocations both in the short and long term. Short term: What *should* the price have been in Cleveland at 3:30 p.m. on August 14, 2003? Long term: On-peak demand uninformed by adequate pricing leads to more peaking generation, the cost of which is blended into all hours, failing to inform continued growth of on-peak demand. Those are loose economic couplings that need to be tightened. The Cleveland example shows how too-loose economic coupling can lead to catastrophic breaking of the physical coupling.

Rather, dynamic pricing provides an important negative-feedback loop that currently doesn’t exist from generator to customer and back, and if that loop is tight/timely enough then it can greatly improve overall system stability, in both the economic and physical senses. (I really would love to know what a locational real-time price would have been in Cleveland, and whether loads in the city would have dropped themselves in time if they’d only known. MISO didn’t yet have LMP at the time.) As #3 points out above, the feedback does no good if its timing is too delayed. Delays can turn negative feedback positive, detracting from stability. So, closing communicative loops sounds like economic tightening to me, resulting in physical tightening… in a beneficial way.

Would loosening help the power system? After the blackout some suggested that the Eastern Interconnect should be broken up into asynchronous islands interconnected with DC links, like ERCOT. That would break the synchronous bonds, and would force each island to be more self-reliant. That would be looser coupling between market regions. But I would hate to see that done before dynamic pricing is ubiquitous. I really suspect that with better pricing the system would be much more stable, and that it would have made August 14, 2003, just another regular day for most people.

1) If all the local, real-time adjustments fail, it’s very handy to have a way to quickly reboot the system. If an airline gets into a cascade of late or cancelled flights where each miss causes another one, they can restart their schedule from scratch the next day.

2) If the capacity of a counterparty is high relative to the performance required by the transacting party, then the transacting party can afford to be relatively ignorant about the counterparty’s limitations. On the other hand, if the counterparty’s capability is challenged by the required performance level, then the transacting party has to thread the needle in choosing exactly what to request from the counterparty and so needs to have a good idea about the counterparty’s specific strengths and weaknesses.

For example, if you want to program a computer to invert a small matrix in a normal amount of time, you don’t need to know much about the hardware’s bottlenecks and limitations, but if you want to invert something gigantic you’d have to program with due regard to memory limitations and instruction speeds, As hardware has improved, the boundary where this change takes place has shifted to bigger and bigger matrices.

Programmers face the same problem. Every time they change a piece of code, they’re trying to improve it. But not all changes turn out to be improvements. Programmers have a remarkable array of “change-control systems” (RCS, CVS, git, SubVersion, etc.) to help them manage this problem. They’ve also learned to make changes that are self-contained and easily reversible, to the extent possible.

“Self-contained” and “easily reversible” should be goals for legislation, as well.

Accurate feedback is essential to resilience.

A bridge design could be redundant (extra piers or cables) and resillent (still works after rust or accident damage) – but not robust enough to handle the unanticipated 2X maximum load, or 150 mph winds.

Federalism (with most government functions provided at the state and local level)is a great example of the benefits of decentralized services, which tend to exhibit the fast response to change facet of resillence, and what might be called “customization” in some business environments.

Robustness seems to be a product of redundancy and resillience, but it was used in a differneet way by the bridge code writers. But do consider redundancy as an element of reslliency.

Adapability is another term that fits with the concept of resilliency. Loose coupling provides for adapability. In your example, while your requirements were adaptable with respect to the cow, they appear rigid with respect to fat content. For example, if skim milk is not available, I will drink 1% milk. The transaction could still occur. Obviously for complex systems the interface design is extremely important and interface requirements may well limit the adaptability in many respects.