The device responsible for flooding the network with data appears to be a programmable logic controller (PLC) connected to the plant's Ethernet network, according to an NRC information notice on the incident. The PLC controlled Unit 3's condensate demineralizer -- essentially a water softener for nuclear plants. The flood of data spewed out by the malfunctioning controller caused the variable frequency drive (VFD) controllers for the recirculation pumps to hang.It is what you get when you use a non-deterministic (crash) protocol like Ethernet instead of a time division protocol like MilStd 1553 or an arbitrated protocol like CAN Bus. The fundamental problem is Einstenian. What is simultaneous when signals only travel at the speed of light? Unless you provide each unit on the bus with its own time slot (1553) or arbitrate addresses as they go down the bus (CAN) you will have problems when two transmitters try to start at the same time (which assumes absolute time at a certain level - a problem that need ony concern engineers)
Crash buses are not allowed in critical systems in aircraft design.
In a nuke plant all systems are critical. Three Mile Island started with a valve malfunction and a burnt out lightbulb in a relatively non-critical part of the plant.
So why don't people stick with the more deterministic buses? There is a lot of design and documentation overhead with such an approach. Every time a new element is added to the bus the bus control software must be at minimum inspected and at most totally reconfigured. In addition the peak data handling capacity of such busses is not as good as Ethernet especially over longer distances. The alternative of course is to continue on with the plug and pray approach. I might note that all wireless busses are essentially crash busses. They will not help much.
BTW I have nuke plant operational experience (US Navy) and aircraft electrical systems design experience (Sundstrand Aerospace).