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.
By the end of this lesson you should be able to tell the 480-volt world from the 24-volt world and say what lives in each, name the panel, short-circuit, power-quality, and grounding awareness a solutions engineer owes the electrical team, explain how EtherNet/IP and CIP Safety carry control and safety traffic on one industrial network, and make the case for segmenting the OT network and controlling who touches it.
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.
You don't size the electrical equipment. But four awareness points travel with you into the conversation with the electrical team, so nothing they hand back surprises you.
Sizing the conductors, breakers, transformers, and grounding electrodes is the electrical engineer's final design. What you carry is the awareness and the load picture, so the numbers they hand back don't blindside the project.
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.
CIP Safety is a functional-safety communication protocol, an extension of CIP, and it carries the safety-rated messaging: the e-stops, the light curtains, and the interlocks that run off the safety PLC from Lesson 20. It rides over the same EtherNet/IP network as the standard control traffic. Both EtherNet/IP and CIP Safety are trademarks of ODVA, Inc., and the names matter because they point to specific things an engineer is expected to know cold.
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. Device-level networks connect the field devices at the machine into that same picture.
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.
What rides that network, and how fast it has to answer, is Lesson 22's problem. Here it's the medium and the protocol; the timing budget is next.
The control system runs on an operational-technology network, an OT network, and it isn't a business IT network. It prioritizes uptime and deterministic timing, it runs equipment that can't be casually rebooted for a patch, and it should be segmented, kept separate, from the business and IT network, so an office problem can't reach the sorter and a floor problem can't reach the office.
The decision card: segmenting the OT network from the business network.
Remote access is real and necessary. The controls vendor needs a path in to support the system. But that path has to be controlled and accounted for, not an always-open door that nobody remembers is there.
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.
So OT cybersecurity is now part of the conversation, and it lands on three things: a patching cadence the OT network can actually tolerate, incident-response basics for when something does get in, and a clear answer to a question everyone assumes is settled and often isn't, which is who owns the OT network. That last one needs a named owner, or the network in between becomes nobody's job until it breaks.
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.
If the controls vendor needs remote access to support the system, then design a controlled path in, one that's accounted for and can be closed, and get IT and the controls team to agree on who owns it before go-live. Tradeoff: a controlled path is more work to set up than leaving a modem on. Verify: ask one question in the design meeting. If the vendor needs to log in at 2 AM during a peak outage, exactly how do they get in and who knows they did. If nobody can answer cleanly, you found the gap before an auditor or an intruder did.
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.
Now lay Riverside onto the architecture. Power first: Dana told you the building has 480 volt three phase power available at two panel locations, one in the northwest mechanical room and one near the southeast corner. That's the high-voltage world feeding the panels and the sorter drive. A 24-volt DC control domain runs the rest: the MDR zones, the sensing from Lesson 19, and the safety devices from Lesson 20.
Networks next. EtherNet/IP carries the standard control traffic between the PLC and the WCS. CIP Safety carries the pull-cord e-stop and the forklift-crossing safety messaging from the Lesson 20 safety PLC over that same network. Ray's WMS-response query, the latency item still open on your architecture, is what rides that EtherNet/IP path from the PLC toward the WCS and the WMS.
Architecture last. The OT network, the PLC, the WCS, and the safety controller, is segmented from Riverside's business network, and the controls vendor gets a controlled remote-access path for support. Then the ownership question: Ray owns IT and the WMS, but the OT boundary needs its own named owner, and that's a conversation to have now, not at go-live.
Write the power-and-network note: the two voltage domains, the network segments, the EtherNet/IP and CIP Safety assignment, the remote-access owner, and the name of the person who owns Riverside's OT network. Add it to your controls architecture summary. If you can't name the OT-network owner yet, that blank is the point. Put it on the page so it doesn't get lost.
Every smart decision you designed in the last three lessons, the sensing, the routing, the safe stop, runs on two things this lesson made visible: the power feeding the machines and the network carrying their decisions. Lose the power and every controller goes dark. Lose the network, or hang it off the office switch, and the decisions arrive too late to matter. Defend both, keep the office and the floor on their own sides of the wall, and the system you've built since Lesson 18 has something solid to stand on: powered, connected, and defended.