Industrial Networking

The network is infrastructure, not cabling.

Plant networks usually grow one machine at a time until nobody has a complete picture. Then something intermittent starts happening and there is no drawing to work from.

EtherNet/IPModbus TCP & RTUProfinetOPC UAVLANsMQTT
Overview

Most plant networks were never designed.

They were extended. A switch here when a line was added, an unmanaged five port device in a panel because it was what someone had, a second DHCP server nobody remembers installing. It works, until traffic from one machine starts affecting another.

The symptoms are recognisable: connections that drop when a particular process runs, controllers that lose comms during a storm of broadcast traffic, and faults that clear themselves before anyone can look at them.

The fix is usually structure rather than hardware, segmentation, a documented IP scheme and managed switches configured deliberately. It is unglamorous work that removes a whole category of future problems.

Protocols we work with

  • EtherNet/IP, implicit and explicit messaging, CIP
  • Modbus, TCP and RTU, including gateway configuration
  • Profinet & Profibus, Siemens estates and mixed plants
  • OPC UA / DA, connecting mixed PLC brands to SCADA
  • MQTT / Sparkplug B, remote and distributed sites
  • Serial, RS 232, RS-485 and the converters in between
What we do

What we do on plant networks.

Design for new installations, and rescue work for networks that grew organically.

Network design

Topology, segmentation and addressing planned before installation, sized for what the plant will look like after the next expansion.

Switch configuration

Managed switches set up properly: VLANs, port security, IGMP snooping for multicast traffic and spanning tree that will not cause an outage.

Protocol integration

EtherNet/IP, Modbus TCP and RTU, Profinet, Profibus, serial and OPC UA, including getting devices from different vendors to cooperate.

Troubleshooting

Packet capture, traffic analysis and cable testing to find the cause of intermittent comms failures.

Segmentation & security

Separating control traffic from business traffic, with firewall rules that let the data you need cross and nothing else.

Documentation

IP address schedules, network drawings and port assignments. The document that should already exist and usually does not.

Detail

Where networks go wrong.

  • Flat networks, every device on one subnet, so broadcast traffic from one machine reaches every controller in the plant.
  • Unmanaged switches, no visibility, no diagnostics and no way to isolate a problem port without unplugging things.
  • Undocumented addressing, duplicate IPs discovered only when two devices are powered at the same time.
  • Ring topologies without protocol, a physical ring with no spanning tree is a broadcast storm waiting for a maintenance shift.
  • Mixed multicast traffic, EtherNet/IP implicit messaging flooding ports that should never see it, because IGMP snooping was never enabled.
  • Business and control on one network, a backup job on the office side causing control layer timeouts at 2am.
  • Consumer grade hardware, office switches in panels, running at temperatures they were never rated for.
  • Cable practice, control cable run alongside VFD output cable, producing faults that appear only when a drive is loaded.
Common questions

Answers before you call.

We design, configure and document. Physical installation is usually done by an electrical contractor, and we are happy to work alongside yours or recommend one along the Wasatch Front.

Usually. It requires capturing traffic over a long enough period to catch the event, which means leaving monitoring in place rather than visiting once. Intermittent faults are solved by patience and data, not by inspection.

For anything beyond a couple of devices, yes. Unmanaged switches give you no diagnostics, and the moment you have a problem the lack of visibility costs more than the switches would have.

Yes, and it is one of the highest value changes most plants can make. It typically involves VLANs, a firewall between layers and explicit rules for the data that needs to cross.

Yes, particularly for distributed sites and remote assets where polling over a slow or intermittent link is impractical.

Do you have a network drawing?

If the answer made you hesitate, that is usually the place to start.

Or call (801) 946-2710, Monday, Friday, 8:00am, 4:30pm MT