Part V. Lesson 21. Power and Networks.
A system runs on two invisible things: the power feeding it and the network carrying its decisions. Both are boring until the afternoon the voltage sags during a peak wave and the drives fault, or the day someone puts the controls network on the same flat switch as the office and a backup job starves the sorter of its routing messages.
You're not the electrical contractor and you're not the network engineer. But the same rule from discovery holds: understand both well enough to have an intelligent conversation with each, and to catch the decision that will hurt the project when it's made by someone who can't see the whole system. This lesson is that conversation.
The system lives in two electrical worlds. High-voltage AC, typically 480-volt three-phase, feeds the big motors, the sorter drive, and the panels. Low-voltage DC, typically 24 volts, runs the controls: the PLC I/O, the MDR zones, the sensors from Lesson 19, and the safety devices from Lesson 20. Which world a component lives in tells you where it draws power and what it costs to feed, and a step-down inside the control panel turns the high-voltage feed into the 24-volt control domain.
The machine controls from Lesson 20 don't act alone. They talk over an industrial network, and the naming here is exact because it's a real standard. EtherNet/IP is an industrial Ethernet network protocol built on the Common Industrial Protocol, or CIP. It carries the standard control traffic between the PLC and the WCS and the device-level equipment down at the machine.
The engineering point under the names is worth holding onto: one physical industrial network can carry both ordinary control and safety-rated control at once. That's why the safety architecture from Lesson 20 and the routing traffic can share infrastructure without the safety messaging losing its integrity.
Sharing one network doesn't make the safety traffic and the standard traffic the same thing. CIP Safety wraps its messages so a safety controller can prove one arrived whole, in time, and from the right device, and it treats a missing or late safety message as a trip, not a shrug. The network is common; the integrity guarantee on the safety traffic isn't.
Treating the OT network like an IT network. IT patches on a schedule and reboots when it needs to. An OT network runs equipment that can't take a surprise reboot mid-shift, and it lives or dies on uptime and timing. Manage it like the office network and you'll either break production applying a patch at the wrong moment or leave it unpatched because nobody dared touch it. It needs its own owner and its own rules.
A critical security patch comes out for a controller on your OT network. The customer's IT wants it applied tonight. The plant runs a peak wave tonight. Name who should be in that decision, and what has to be true about your network design for that patch to go on without stopping the line. If your answer is "just apply it," you've never watched a patch take a line down.
The question that comes back to bite projects isn't which protocol you picked. It's who owns the OT network. IT owns the office side. The controls team owns the machine logic. And the network in between, the one running the whole floor, everybody assumes somebody else has it. Then a patch is due, or something gets in, and it turns out that network was nobody's job. Ask the ownership question in the design meeting, out loud, and write down the name. It's the cheapest insurance on the project and almost nobody buys it until after they've needed it.
Next: What has to move between systems, how fast, and what happens when it doesn't arrive?