Factory Automation Network Design: Connecting PLCs, Serial Devices and IP Cameras on One Network

The three layers of a factory automation network

A factory network is not one network. It is three, joined at a small number of points, and the reason to separate them is that they fail differently. A camera losing a frame is an inconvenience. A PLC losing a scan is a stopped line or a scrapped batch. Running both on one flat segment means the second problem is caused by the first.

Field layer – machines, sensors and the serial bus

This is where the physical process meets the network: proximity and photoelectric sensors, encoders, drives and variable-frequency drives, weighing instruments, barcode scanners, energy meters, and the actuator and valve islands. Much of this equipment speaks RS485 or RS232 rather than Ethernet, and much of it is older than the network you are designing. This layer also carries the equipment with the worst environmental conditions and the least tolerance for a maintenance visit: a drive cabinet, a wash-down area, a conveyor frame.

Control layer – PLCs, cells and the gateway

The control layer holds the line controllers: PLCs and DCS controllers, machine HMIs, motion controllers, and the gateway that translates between the plant protocols and the IT side. It is the layer that most factory networks are designed for and the layer that usually defines the temperature and EMC requirement on the specification. Traffic here is small in volume and severe in consequence.

Management layer – SCADA, video and the core

The management layer is where data is stored, displayed and acted on: the SCADA or historian server, the MES connection, the video recorder and its archive, the time synchronisation source, and the core switch that links the plant to the enterprise network. Its availability matters, but its failures are recoverable in a way that a stopped production line is not, and it is normally rack-mounted in an air-conditioned room rather than on the shop floor.

Figure 1 – Factory automation network reference architecture: field, control and management layers, the traffic each one carries, and the four design decisions that hold it together.

What belongs on each layer, and what to specify

The practical value of the three-layer model is that each layer gets a different device specification instead of one compromise device everywhere.

Segment before you optimise

The single most useful thing you can do to a factory network is put the control traffic, the video traffic and the management traffic on separate VLANs, and then decide explicitly which of them is allowed to be interrupted. That decision is what makes everything after it simple.

A flat network is a design decision too, and it is the one that produces the strange incidents that are hard to explain later: the line controller that hangs whenever a camera is reconnected, the HMI that stutters when somebody opens the video wall, the PLC that times out during a firmware download on the office side. None of those are faults in the equipment. They are all consequences of two traffic classes sharing a broadcast domain and a queue that nobody assigned a priority to.

Bringing serial equipment onto Ethernet

Serial interfaces survive in factories for good reasons. A 4-20 mA or RS485 instrument is cheap, robust, needs no IP address and no firmware update, and works on a two-wire cable that any electrician can terminate. Machines are also replaced far less often than networks: a packaging line installed in 2008 is still running, and its drives, scales and scanners still speak Modbus RTU on an RS485 bus. Replacing the machine to get an Ethernet port is not a network project. Converting the bus is.

Figure 2 – A serial device server in the signal path: the legacy RS485 bus on one side, a VLAN-segmented Ethernet network and Modbus TCP on the other, and the four details that decide whether it works reliably.

What a serial device server actually does

A serial device server is a small industrial computer with a serial interface and an Ethernet interface, and its job is to make the serial port reachable across the network. Practically, that means it supports several different operating modes, and the mode you choose decides what software has to change.

Three details that decide whether it works

Termination and bias. An RS485 bus needs 120 Ω at both physical ends and a defined idle state through pull-up and pull-down resistors. Without them, the bus floats when no device is transmitting, the receiver sees noise, and the symptom is intermittent CRC errors that disappear whenever an engineer is standing there. Some multi-port servers expose this per channel as a DIP switch, which is the feature to look for if the installation is long or noisy.

Polling arithmetic. A polled bus gets slower with every device you add, and the cycle time is the sum of every device’s response time. If a project adds four energy meters to a bus that is already at 400 ms, the control system’s scan time changes. It is worth calculating the bus cycle before adding devices rather than after, and worth keeping the polled bus on its own segment so its latency cannot affect anything else.

Isolation and protection. A serial device server on a factory floor shares an electrical environment with drives, contactors and welding equipment. Port surge protection, a built-in overcurrent limit and isolated serial interfaces are not optional extras on that wall; they are the difference between a device that lasts and a device that gets replaced every eighteen months.

Winsure serial device servers

Winsure builds serial device servers in three shapes: a compact single-port unit for one legacy device, a DIN-rail multi-port unit for a machine or a cabinet, and a rack-mount unit for a serial concentrator. A serial-to-fibre unit covers the case where the distance or the electrical environment rules out copper.

All four share the same industrial envelope: a metal IP40 enclosure, no fan, an operating range of −40 ~ +85 °C, a 100,000 hour MTBF, and port protection specified as IEC 61000-4-5 Level 3 on both the power and the Ethernet ports, with 4 kV / 6 kV lightning protection and reverse-polarity protection on the supply. On a shop floor those figures matter more than the datasheet’s headline feature list.

Ring redundancy: why RSTP and ERPS decide whether the line stops

In a star topology, every device has exactly one path back to the controller, and any single cable fault isolates everything behind it. In a factory that is an unacceptable design, because the cable is the cheapest component in the system and the most frequently damaged: a forklift, a panel being moved, a contractor drilling a cable tray, a wash-down hose. A ring gives every device two paths and turns a cable fault into an event rather than an outage.

What you are really buying is the recovery time

The number that matters in a ring is not bandwidth, it is how long the network takes to reconverge after a link breaks. That interval decides what survives:

· Under about 50 ms, a Modbus TCP transaction or a PROFINET cycle normally completes without the controller noticing.

· Between 50 ms and 200 ms, a PLC typically rides through on its own retry logic, but a camera stream drops a few frames and an HMI may show a stale value.

· Beyond that, most industrial protocols declare a communication fault and the controller reacts: the line stops, or a drive is commanded to a safe state.

That is why a factory ring is specified by recovery time rather than by switch throughput, and why the protocol choice matters more than the port count.

Where the ring goes, and where it does not

The ring belongs at the field and access layers, where the long cable runs and the vulnerable physical routes are. It is usually not worth extending into the management layer, where cabinets are in the same room and a fault affects nothing physical. It is also worth resisting the temptation to put every switch in one large ring: a ring with twenty nodes has a longer reconvergence and a larger failure domain than two rings of ten, and the second ring costs one more pair of ports.

Two practical notes. Ring ports should not be edge ports, and auto-edge detection should be off on them, or a topology change can be misread. And whatever the datasheet claims, the recovery time should be verified with your own traffic rather than taken from a marketing table – a test that involves pulling one cable while the line is running is worth more than any specification.

Putting IP cameras on the same network as control traffic

The title of this article says one network, and that is achievable and normal. It does not mean one flat segment. Cameras on a production line are valuable – for quality records, for fault diagnosis, for seeing what happened before an alarm – but their traffic profile is the opposite of control traffic: sustained, large, and tolerant of a few lost frames.

The other video-specific setting worth knowing is multicast. A video wall with six decoders watching the same camera can either receive six separate unicast streams or one multicast stream that all six join. On a factory network with a handful of cameras the difference is small, but the moment a control room displays a matrix of views, IGMP snooping on the switches stops the plant network from carrying traffic that nobody is watching.

The three device roles, and how to choose between them

Every factory automation network comes down to three device roles, and most projects get into difficulty by using one of them where another belongs. They are not competing products; they are three different jobs.

Choosing a serial device server

Four questions settle the model:

1.How many serial ports, and which electrical interface? A single legacy device needs one port; a machine cabinet may need four or eight; a serial concentrator for a control room may need sixteen or thirty-two. Confirm RS232, RS485 or RS422 per port, and whether the interface has to be selectable in software.

2.Where is it mounted? DIN-rail inside a panel, wall-mounted near the machine, or 1U in a rack. This is the decision that determines the enclosure and the dimensions, and it is worth settling before the port count.

3.What is the electrical environment? Confirm the temperature range, the port surge protection and whether the serial interface is isolated. A device on the same supply as a large drive needs the protection figure, not just the temperature figure.

4.What has to keep working on the software side? If existing SCADA software must not be modified, virtual COM support is the requirement. If a PLC or SCADA already speaks Modbus TCP, Modbus TCP to RTU is the requirement. These lead to different configuration and, occasionally, to a different model.

Choosing the industrial communication gateway

The gateway is the right device when the problem is not a serial port but a protocol: when a substation speaks IEC 60870-5-104, a meter speaks DL/T 645, a controller speaks DNP3, and the plant historian speaks OPC UA. Winsure’s wsCom/TX series runs an embedded Linux system with an RTC, a temperature sensor and hardware encryption, dual redundant 9-60 VDC power input, and a protocol set that covers OPC UA client and server, Modbus, IEC 101 to IEC 104, IEC 61850 MMS client and server, DNP3.0, DL/T 645 and others. Three sizes cover the range: the wsCom/TX-2T-4C with four serial ports and 4G support, the wsCom/TX-2T-8C with eight serial ports plus four digital inputs and four digital outputs, and the rack-mount wsCom/TX-6T-16C with sixteen serial ports, sixteen Ethernet ports, two CAN 2.0B interfaces and relay alarm contacts.

When the run leaves the building

Once the network crosses between buildings or follows a cable route longer than copper can carry, the design changes to fibre. That is a media-converter question rather than a switch question, and the same range covers it: industrial media converters for the field cabinets, single-mode patch cords and fibre cable for the route itself, and optical distribution frames where the fibre terminates in each building. Winsure publishes the same design as a packaged smart manufacturing network, which is worth reading as a worked example of the three-layer model described above.

Getting to a design answer

Send five things and the design conversation becomes short: the number of serial devices and their interfaces, the controller and its protocol, the number and type of cameras, the mounting location of each cabinet, and the maximum cable run between the furthest device and the control room. We will come back with a layer-by-layer equipment list, the ring recovery time the design achieves, and the PoE budget with margin.

OEM and ODM requirements are supported, including labelling and firmware configuration for a specific production programme. Written quotations are issued within 24 hours. The switching range is summarised on the managed industrial switch and industrial grade switch category pages, with the full range on the switches index. For representative models, see the wsCom3028G-4GSFP-8G/DC-INT, the wsCom3010G-2GSFP-8G/DC-INT and the wsCom3010LG-2GSFP-8G/DC-INT. For the fibre side of the design, see the industrial fibre media converters, the wider transceiver range, fibre optic cable and single-mode patch cords.

Winsure Communication is a Shenzhen-based industrial communication manufacturer, founded in 2016 within the Hansun group, with a factory under ISO 9001, ISO 14001 and ISO 45001 management systems. The background is on the about us page, the wider set of industry references is on industry solutions, the full catalogue on products, and the technical team can be reached through contact us.

Frequently asked questions

1.Can I run PLC control traffic and IP cameras on the same switch?

On the same physical network, yes – on the same switch port budget and the same queue, no. Put the cameras on their own VLAN with their own queue priority, size the uplink for the sum of all camera streams, and give the control traffic priority so a camera burst can never delay a controller cycle. If the two must share an uplink, shape the video at the camera rather than relying on the switch to sort it out later.

2.Do I need a serial device server or an industrial gateway?

It depends on what the problem actually is. If the problem is a serial port – an RS485 instrument that needs to be reachable over the network – a serial device server is the right device. If the problem is a protocol – equipment speaking IEC 60870-5-104, DL/T 645 or DNP3 that has to be presented to a historian as OPC UA – then an industrial communication gateway is the right device, and it usually has serial ports as well.

3.What is the difference between Modbus RTU and Modbus TCP?

They are the same data model and function codes over different transports. Modbus RTU runs over a serial line, typically RS485, with a CRC and a strict master-slave timing. Modbus TCP runs over Ethernet with a TCP header and no CRC, and allows more than one client. A serial device server in Modbus TCP to RTU mode translates between the two, so a SCADA system that speaks Modbus TCP can poll devices that only speak Modbus RTU.

4.What recovery time should a factory ring achieve?

Aim for under 50 ms if a PLC or a motion controller is on the ring, because that keeps the interruption inside the controller’s tolerance and avoids a declared communication fault. RSTP is usually enough for simple rings where a short interruption is acceptable. ERPS (G.8032) is the right choice where a controller must not see the fault, and it is standardised so it does not lock the plant into one switch vendor.

5.Can we keep our existing SCADA software?

Usually yes. Virtual COM port support lets a serial device server appear to the Windows host as a local COM port, so an existing SCADA driver continues to work with no modification. The device the driver talks to is physically at the far end of the Ethernet network, but the software does not need to know that. This is normally the fastest migration path, and it is the reason to confirm VCOM support before choosing a model.

6.How do I choose between RS232, RS485 and RS422?

RS232 is point-to-point, short-distance and legacy, which makes it common on older instruments and programming ports. RS485 is a two-wire multidrop bus, which is what most factory instruments and drives use, and it is the reason a single serial device server can serve four or eight devices on one cable. RS422 is a four-wire differential link, point-to-point or with a small number of drops, used where distance or noise rules out RS232. Choose a server with software-selectable interfaces if the project contains more than one of them.