FCTEL / NETWORKING & CONFIGURATION
Configure industrial-switch QoS at the congested egress, then prove it with the real services.
Identify PLC, machine-vision and management traffic; verify the trust boundary for CoS or DSCP markings; map each class to the switch’s supported queues; and compare application behavior with egress counters during controlled load. QoS cannot create bandwidth or repair a faulty physical link.
1. Start with the actual congestion point
A production line may carry PLC exchanges, HMI commands, machine-vision streams and network-management traffic over the same industrial Ethernet infrastructure. Quality of Service matters when packets compete for a particular output port. For example, several cameras can feed a shared uplink faster than the uplink can transmit during a peak. At that egress, the switch must choose which frames receive transmission opportunities and which frames wait or are discarded. QoS does not solve an optical link with bit errors, a persistent switching loop, a stalled PLC or an application whose own processing time dominates the round trip.
Before changing a configuration, draw the path from each source to its destination. Record physical ports, VLANs, unicast or multicast behavior, normal and peak traffic, and the time or loss limits agreed by the process owner. Inspect utilization, errors, discards and application logs on the suspected uplink. A port near capacity for long periods needs a capacity or traffic-engineering review: a faster uplink, a separate video path, better video encoding, or tighter multicast distribution may matter more than a queue setting. QoS is a way to manage competition for finite capacity, not a substitute for capacity.
2. Classify services without promoting everything to high priority
Begin with classes that an engineer can verify by capture and topology. A PLC’s cyclic exchange may deserve different treatment from engineering downloads or diagnostics originating from the same workstation. A camera may send both modest control messages and a high-bit-rate video stream. Treating every packet from a device or VLAN as critical is often too coarse. Ask the operations team which frames protect a control function, which frames are required for operator awareness, and which can tolerate buffering or occasional loss.
IEEE 802.1p Class of Service is carried in a VLAN tag at Layer 2; DSCP is an IP-layer marking. Neither label is useful until you confirm that the endpoint sets it, intermediate devices preserve or rewrite it as intended, and the egress switch maps it into a real queue. A camera or laptop plugged into an untrusted access port should not be allowed to claim the highest priority merely by marking its own traffic. At trusted boundaries, existing markings may be accepted. Elsewhere, classify by a validated port, VLAN or supported match rule, then mark or remark as the approved policy requires. Check again after any routed hop because the incoming DSCP may not be the same value that reaches the bottleneck.
3. Map verified classes to supported queues
An official FCTEL managed industrial switch product page describes CoS/DSCP classification, multiple queue scheduling options and port rate control. This establishes a relevant product-family capability, not a universal configuration recipe. Confirm the ordered model, hardware revision, firmware, queue count and actual management interface before following any menu sequence. Export the existing configuration and record the software version first.
Set the ingress trust policy, then map each approved service class to a supported egress queue. Strict priority can be appropriate for a narrow, bounded critical class, but an uncontrolled high-priority stream can starve lower queues. Weighted scheduling allocates service among queues, yet weights must reflect the measured peak mix and minimum service needs; equal weights are not automatically fair to the process. For high-volume video, combine sensible source encoding, multicast control and, where supported, shaping or policing. Preserve reachability for management and alarms. A queue plan should describe not only what gets priority but what happens to every other service during a fault.
4. Make each change observable and reversible
Save the current switch configuration, port and VLAN map, network topology, and baseline monitoring screens. Choose one path for a limited trial. First confirm the direction of traffic at the access and uplink ports. Next verify that the classifying rule actually matches the expected frames. Then check that CoS or DSCP values and the queue counters rise when the known test traffic is present. Only after that should you apply scheduling or rate limits. Change one class of setting at a time and record the before-and-after state, including the exact rollback command or saved configuration.
Do not saturate a production control network simply to demonstrate congestion. Reproduce the traffic mix in an isolated test where practical. If a site test is necessary, obtain a maintenance window, set a traffic ceiling and duration, define immediate stop conditions, and have both process and network personnel observe the trial. A ring-protected network needs the same review on the alternate egress: a fiber break can redirect several services onto a different uplink with a different queue policy. The relevant question is whether the protected service still works under the designed fault, not whether a configuration checkbox remains enabled.
5. Accept the result at both network and application layers
Test at least three conditions: normal low load, bounded contention at the known egress, and stable operation after the injected load is removed. Record the PLC’s observed cycle variation and timeout count, operator-interface response, vision-stream delay and frame loss, and the switch’s transmit and drop counters for each output queue. The process owner must define acceptable limits; this article cannot invent a universal millisecond target for all PLC systems. A passing queue counter alone does not prove that the application met its timing requirement.
If PLC timeouts improve but video becomes unusable, revisit the allocation and traffic source. If queue counters do not change, the frames may not cross the expected egress, the classification may not match, or the marking may be rewritten upstream. If every service worsens together, investigate physical errors, a loop, multicast flooding or source overload before retuning priorities. Keep packet captures, load profile, test duration, firmware and policy versions, observed exceptions and the rollback record with the handover package. Repeat the test after a new camera is added, the PLC application changes, a VLAN is redesigned or ring protection redirects traffic.
A useful evidence sheet for the commissioning team
For each trial, record the switch port and direction, the ingress service class, the original CoS or DSCP value, any remarking rule, the selected output queue and the actual egress port. Place a timestamped application observation beside the queue counter snapshot. The engineer should be able to explain why a particular packet entered that queue and what happened to its neighboring classes at the same moment. If the switch exposes only aggregate port counters, supplement them with packet captures and endpoint logs rather than claiming a per-queue result that was never measured.
Test traffic should resemble the production packet sizes and burst behavior, not only a steady stream of large frames. Video encoders may produce peaks around scene changes; PLC exchanges can be small and periodic; management downloads can create unexpected bursts. An average utilization figure can hide the short queue buildup that causes a timeout. Conversely, a single isolated timeout may come from an endpoint or an application task rather than the switch. Correlating synchronized timestamps across the PLC, camera, switch and monitoring system is essential before attributing an improvement to QoS.
6. Separate QoS from the controls around it
Giving an entire PLC port the highest priority can also promote engineering downloads and maintenance traffic. Giving every camera the lowest priority can damage alarm video. Setting DSCP without checking trust and egress mapping can have no practical effect. QoS also does not stop a Layer-2 storm, clean a dirty optical connector or make a slow application fast. For a video-heavy site, read the related industrial IGMP Snooping guidance for multicast distribution and the broadcast-storm troubleshooting guide for loop diagnosis. Those controls complement queue scheduling but address different failure modes.
The most reliable industrial QoS policy is therefore modest, documented and measurable. It begins with an observed bottleneck, applies only verified service classes, states what lower-priority traffic will receive, and is judged by actual production behavior under agreed test conditions. Specific configuration details and supported queue options must always be checked against the manual for the delivered FCTEL switch and its firmware.
7. Questions to resolve before the next expansion
Ask whether the network diagram identifies the same egress in normal and protected topology, whether the new camera or machine will change the peak load, and whether the switch has the queue and counter visibility needed for repeatable acceptance. Verify who owns the classification policy at each trust boundary. Check that a replacement switch will receive the same approved policy rather than only an IP address. Finally, define how the team will detect a drift in queue drops, PLC timeouts or video quality after commissioning. These questions turn an initial configuration exercise into an operating practice.
