A robot cell carries four kinds of traffic — safety, process, inspection bulk data and OEM remote service — and they want opposite things from the same uplink. This guide separates them with VLAN 802.1Q, explains why DSCP is only a mark and priority queuing is the behaviour that actually protects latency, puts safety traffic in its place under the IEC 61784-3 black channel principle, rate-limits vision and force data below a measured worst-case uplink, and turns the vendor’s remote session into a time-boxed conduit instead of a standing VPN — then shows what an industrial 4G/5G router with VLAN and QoS for robot cells does about all four, and which E-Lins models ship 802.1Q today.
Four Kinds of Traffic Live Inside One Robot Cell — and They Want Opposite Things
Ask what a robot cell needs from a network and the answer usually arrives as a single number: bandwidth. It is almost always the wrong number — bandwidth is the one property all four traffic types in a cell have enough of. What they compete for is queue position, and they want it in mutually incompatible ways.
Those four want opposite things from the same uplink. Safety traffic is small, periodic, with a deadline in tens of milliseconds. Process traffic is small and frequent, caring about jitter more than absolute delay. Inspection data is enormous and indifferent to delay — a 4 MB image arriving 800 ms late is still useful, provided it did not delay the frame behind it. Remote service is bursty, and must not be reachable from anything else in the cell.
So a cell does not have a bandwidth problem; it has a classification problem. The place to solve it is not the cloud, the carrier or the robot controller — it is the router, the only device that sees all four streams at the instant they contend for the same radio slot. That is what an industrial 4G/5G router with VLAN and QoS for robot cells is bought for: not throughput, but the authority to decide who goes first.
| Traffic class | Typical payload | Cares about | Tolerates | Fails as |
|---|---|---|---|---|
| Safety / control safety PLC ↔ robot controller | 30–200 bytes per frame, 4–20 ms cycle | Deadline, jitter | Nothing much | Safe stop, cell down |
| Process / supervisory cell PLC ↔ MES / SCADA | 100–2,000 bytes per event | Jitter, delivery | 100–500 ms delay | Stale OEE, missed alarms |
| Bulk / inspection cameras, force-torque, trace records | 0.5–8 MB per part | Completeness | Seconds of delay | Buffer overflow, dropped records |
| Remote service OEM engineer ↔ controller | Bursty, kB to hundreds of MB | Isolation, authentication | Anything except exposure | An attack path into L1 |
| A note on what this guide is not |
| This is not an argument for putting safety traffic on a cellular link. It is an argument for knowing exactly which traffic is on which side of the boundary — and for making sure that when the bulk stream saturates the uplink, the safety conversation is not behind it in the queue. |
Why “Just Pull Another Cable” Usually Isn’t the Answer
The instinctive fix for contention is separation by physics: one network per class. On a greenfield line with a patient IT department and an eighteen-month schedule that works. Most cells are not built under those conditions.
Three things kill it. Sequence: the robot arrives in June and the plant’s cabling and IT onboarding are scheduled for October, so for four months the cell runs on something the integrator controls. Ownership: the vision system belongs to quality, the robot to manufacturing engineering, and the service port to the OEM’s contract — two of those three cannot get a firewall change approved in a month. Geometry: cells move, and every physical drop is a change request, a patch panel entry and an asset record.
None of that is a reason to accept a flat network. It is a reason to separate logically, inside one device, and let the plant deal with one cable and one SIM. That is the premise of one uplink four networks: the isolation you wanted from four drops is produced by tagging, queueing and tunnelling in the router, and it survives a forklift move because it is configuration, not copper.
| 4 |
| Traffic classes that contend for one radio slot |
| 1 |
| Uplink the plant will actually approve |
| 2 |
| Queues that matter: one strict, one shaped |
| 0 |
| Extra cable runs needed to separate them |
VLAN 802.1Q: Where to Cut, and What Not to Cut
A VLAN tag is twelve bits of VLAN ID plus three bits of priority in an Ethernet frame. That is the whole mechanism, enough to turn one switch fabric into thousands of separate broadcast domains. What matters is not the tag but where you place the cut, because every cut is a routing decision — and every routing decision is a place where traffic can be delayed, or silently allowed.
Cut by consequence, not by device
One VLAN per device is the easiest scheme and the least useful. If the robot controller and the safety PLC both land on VLAN 10, nothing that matters has been separated: an engineering laptop on the robot’s VLAN is one hop from the safety conversation. Segment by what happens if this stream is delayed, observed or spoofed, and the four classes fall out by themselves.
| VLAN (example) | Carries | Routes to | Queue treatment | Why it is its own domain |
|---|---|---|---|---|
| VLAN 10 — Safety & control | Safety protocol frames, cell PLC ↔ robot controller | Nothing outside the cell | Highest strict-priority queue | Hard deadline; must never leave the cell boundary |
| VLAN 20 — Process & supervisory | Cycle data, alarms, OEE counters, MES handshakes | Plant SCADA / MES via the uplink | Second strict queue, or high-weight | Business-visible; needs delivery guarantees |
| VLAN 30 — Inspection bulk | Camera images, force-torque traces, traceability records | Quality server / historian | Rate-limited and shaped | Must be prevented from filling the uplink |
| VLAN 40 — Remote service | OEM engineering session, program backup, firmware update | Nothing by default; IPsec tunnel on demand | Lowest, and time-boxed | An access path, not a data path — treat it as a door |
Two cuts people get wrong
Camera and robot controller on the same VLAN because they share a switch. They share a switch because it has ports, not because they share a risk profile. A vision system is often the least hardened computer in the cell — general-purpose OS, web interface, updated by whoever sold the camera. Everything it can reach is reachable by whoever compromises it.
Remote service on its own VLAN, then routed everywhere anyway. A VLAN without a routing policy is a label, not a barrier. The point of OEM remote access VLAN design is that it lets you state the real requirement — the vendor may reach the programming port, for ninety minutes, through a tunnel that logs the session — instead of the usual alternative: a permanently reachable port and a promise.
| Check this before you specify: VLAN availability is not uniform across the range |
| In the E-Lins datasheets, VLAN 802.1Q is listed on the H700, H720, H750, H820, H820QO and the H900 family (H900, H900f, H900pf, H900t6, H900uf). On the H685, H685f, H685frc and H820Q the same line reads “VLAN 802.1Q (coming Q4)” — a roadmap item, not a shipped feature. The H685t and H685w list only “VLAN — support multi-LAN”; the H685m, M300 and M400 list no VLAN capability. If 802.1Q is a hard requirement, confirm the firmware state of the exact unit at order time rather than assuming it from the family name. A design that silently degrades into a flat network is worse than no design, because everyone downstream keeps believing the cell is separated. |
QoS: DSCP Is a Mark, Priority Queuing Is a Behaviour — You Need Both
These two get used interchangeably and are not the same thing. The difference is most of what separates a QoS configuration that works from one that looks correct in a screenshot and changes nothing on the wire.
DSCP is six bits in the IP header — a mark. It travels with the packet across the router, the uplink and the carrier’s network, saying “this packet claims to be important”. Nothing is obliged to read it. Hence the most common disappointment in the field: an engineer marks camera and control traffic, watches the cell stutter anyway, and concludes QoS does not work. The mark was correct; nobody built a queue that reads it.
Priority Queuing is the behaviour — the scheduler’s rule for which queue gets the next transmission opportunity when the interface is busy. A strict-priority queue is emptied before lower queues are served at all; a weighted queue gets a defined share. This is what changes latency, and only when the interface is congested.
| The sentence every QoS design has to survive |
| Queueing only does something when there is a queue. On an idle uplink, a perfectly classified packet and an unclassified one arrive at the same time. All the benefit appears during saturation — exactly when a firmware download starts mid-run, or six cameras flush their buffers at once. |
What that means for a robot cell
Classify at the edge of the cell, not the edge of the plant. The router is the first device that sees all four streams, so it is the only one that can classify them before they contend. A mark applied three hops later is documentation.
Safety and process get a strict-priority queue; bulk traffic gets a shaped queue with a hard ceiling. Lower priority alone is not enough — a 4 MB burst served last still occupies the uplink for seconds while nothing else moves. Safety traffic is small and bounded, so strict priority is safe for it; the inspection stream is unbounded, so it needs a ceiling, not merely a lower priority.
Marks are only honoured end-to-end where you control both ends. Across a public cellular network you cannot assume the carrier’s treatment of your DSCP values. What you control is the router’s egress scheduler on the cell side, and that is where the latency guarantee is created.
One more point about QoS DSCP priority queuing on a cellular uplink: the bottleneck is the radio scheduler, whose capacity changes with signal conditions. Ethernet ports may be gigabit while the uplink serves 8 Mbps. Any ceiling must sit below worst-case uplink capacity, not the nominal figure — otherwise the queue forms inside the modem, where your scheduler cannot see or reorder it. Shaping to roughly 70–80% of measured worst-case uplink is a common start, verified on a bad afternoon rather than a good morning.
Where Safety Goes — and What the Uplink Is Allowed to Carry
Every robot cell networking discussion eventually reaches the same anxious question: can safety go over the wireless link? The standards give a more interesting answer than yes or no.
The relevant idea is the black channel principle in IEC 61784-3. A functional-safety protocol such as PROFIsafe, FSoE or CIP Safety assumes the network underneath is not trustworthy. It does not ask the transport to be safe; it adds its own protective measures and treats whatever carries it — copper, fibre, radio, a VPN — as an opaque box that may delay, reorder, corrupt, repeat or lose frames. That is how these profiles reach SIL 3 / PLe over infrastructure with no safety certification at all.
The protective measures are four, each mapping onto something a network does wrong: a sequence number catches repetition, deletion and reordering; a watchdog timeout catches delay; a unique connection ID catches delivery to the wrong partner; an independent CRC catches corruption. (PROFIsafe V2 adds a toggle bit to tell a repeated frame from a new one.) None cares what the black box is made of. All care how long it takes.
| The part that actually constrains your design |
| Safety reaction time is a sum: sensor detection + safety protocol watchdog + controller cycle times + logic execution + actuator stopping time. The network is one term in that sum, not the whole of it. Adding a radio link does not invalidate the sum — it enlarges the network term, and you must check the total still lands inside the stopping distance you validated. |
So the honest answer has three parts. First, no radio link should carry a hard closed-loop control function; a 1 kHz motion loop belongs on EtherCAT or CAN inside the cell — physics, not compliance. Second, a safety protocol built on the black channel principle can legitimately cross a wireless segment, provided the added delay is budgeted against reaction time. Third, a mobile axis must have a defined behaviour on total radio loss, and that is a controlled stop set by the risk assessment, not by the router. The router cannot make a cell safe; it can only fail in a way the cell has already planned for.
So which queue does safety traffic get?
The highest one — for a reason that has nothing to do with the safety protocol’s robustness. PROFIsafe survives a delayed frame by tripping its watchdog and stopping the cell safely. That is a production failure, not a safety failure. Prioritising safety frames over image data does not protect people; it protects cycle time, by preventing a stoppage that a camera burst caused.
One detail follows from this and is easy to get backwards. Safety traffic is deterministic traffic over cellular only in the sense that it is periodic and bounded, so classify it by ingress port or VLAN, never by deep inspection — a safety frame’s path should not depend on a parser.
Vision and Force Data: Shaping, Not Prioritising
The instinct with bulk traffic is to give it a low priority and call the job done. Section 04 explained why that is insufficient: a low-priority queue still occupies the interface completely once the scheduler reaches it. Bulk data needs a ceiling, applied where the queue forms.
Three shapes bulk traffic takes
Post-cycle flush — the camera or force-torque logger buffers locally and dumps on completion or a quality event. This is the dangerous shape: bursts are what a cellular uplink handles worst. A buffer holding forty parts’ worth of traces produces a multi-megabyte transmission at an arbitrary moment. If you can change one thing about a vision system’s network behaviour, change this — make it stream, or flush on a schedule, or flush only when the cell is idle.
| Inspection source | Per-part volume | At 60 parts/hour | Shaping recommendation |
|---|---|---|---|
| 2D seam camera, JPEG | 0.4–1.2 MB | ~7–20 MB/min raw | Ceiling at 40–50% of measured worst-case uplink |
| 3D profile scan, point cloud | 2–8 MB | Sustained peaks | Ceiling + schedule the flush outside cycle peaks |
| Force torque sensor uplink, trace mode | 50–400 kB per trace | Small; latency-tolerant | Process queue if sampled; own VLAN if traced continuously |
| Torque-and-angle fastener records | 2–20 kB per fastener | Negligible, but must not be lost | Process queue; delivery matters more than speed |
| Where the queue forms decides who controls it |
| Shape above the real uplink capacity and the backlog moves from your scheduler into the modem’s buffer. Once it is there, your priorities no longer apply — the modem drains in arrival order. Always verify the ceiling against a measured worst-case throughput, not the nominal bearer rate. |
OEM Remote Service: A VLAN and a Tunnel, Not a Standing VPN
Of the four classes, remote service is the only one that is fundamentally an access path rather than a data path, and it should be designed as a door, not a pipe. Most cells get this wrong in one specific way: somebody installs a VPN client on the robot controller or opens a firewall port, and the OEM’s engineer has permanent reachability to a device that can change motion programs.
The alternative is not complicated, just less convenient — and the inconvenience is the point. Remote service gets its own VLAN with no route to the safety and control VLAN by default. The only way in is a tunnel terminated on the router — IPsec in the E-Lins range, alongside OpenVPN — brought up when a session is authorised and torn down when it ends.
What “authorised” has to mean
A tunnel that is always up is a standing VPN wearing a costume. The properties that make a remote-service conduit defensible are the ones that bound it in time, scope and observability:
- Multi-factor authentication on the session. A pre-shared key proves a device, not a person.
- A time limit. They asked for ninety minutes to load a program; give ninety minutes, then require re-authorisation.
- Least privilege by destination. The controller’s programming port — not the safety PLC, the camera or the plant network.
- An owner on the plant side who knows the session is open and can end it.
- A log that survives the session — who connected, when, from where, and what they reached.
- A revocation path that needs no site visit. When the contract ends, access ends the same day.
An IPsec tunnel for robot service terminated on the cell router is the right place to enforce all six: the router is inside the cell, sees the destination addresses, and needs no plant firewall change request every time the OEM needs in. It is also where the tunnel and the VLAN policy meet — one device decides who gets in and what they may reach.
What Survives a Dual-SIM Switch — and What Doesn’t
A cell router with two SIM cards is not a redundant cell router. It is a router with two chances to establish a session, and the gap between those two statements is about three minutes of production.
When the primary carrier fails — sector outage, tower backhaul problem, an expired SIM nobody noticed — the sequence is: detect, tear down, re-register on the second SIM, establish a new session, then re-establish everything riding on top. E-Lins calls the first part “Dual SIM instant failover switching”, a statement about how fast the switch happens, not how fast applications recover. Applications are where the time goes.
Here is what a design document must be honest about: when the session is re-established, the public IP address changes. Every TCP connection across it is gone, and TCP does not know that — it waits on retransmission timers, and a default Linux keep-alive is around 7,200 seconds. Reasonable on a LAN, absurd on a radio link that just changed identity. Set keep-alives to tens of seconds, or a SIM switch presents to your SCADA as a cell that silently fails to answer for two hours.
| Layer | What happens on switchover | Recovery | Design response |
|---|---|---|---|
| Radio / registration | Detect failure, re-register on second SIM | Seconds (device-dependent) | Tune link-check intervals; avoid false switches |
| IP session | New context, new IP address | Seconds to tens of seconds | Assume the address changes; never hard-code it |
| VPN tunnel | Tunnel must be re-established | Tens of seconds | Use DPD / aggressive rekey; expect a gap |
| TCP application session | Connection dead but undetected | Up to hours at default keep-alive | Keep-alives in tens of seconds |
| VLAN / QoS policy | Unaffected | Immediate | Nothing — this is the point of doing it locally |
The last row is why this belongs in an article about segmentation. VLAN assignments and queue policy are local configuration, and they survive a change of carrier, IP address and tunnel. Everything that makes the cell behave correctly under contention is in force the instant the new session comes up, with no re-convergence and no dependency outside the cabinet. Separating traffic in the cell router rather than a switch three hops away means the policy has no WAN dependency.
Dual SIM is not the only redundancy in the box
There is a second one, overlooked because it is not a network feature: dual power inputs with power failover, and on the H685, H685f, H685frc, H750, H900 and H900t6 the line reads “Dual or Tri Power Inputs / Power Failover”, over 5–40 V DC (5–60 V DC option). In a cell that is the difference between riding through a supply disturbance and rebooting — and a reboot discards every queue, tunnel and classification.
On three models — the H720, H900 and H900t6 — there is also a dual modem, dual SIM online configuration. That is a different architecture from a standby SIM: both modems online rather than one waiting. Where the requirement is continuous connectivity rather than fast recovery, this is the configuration to ask about, and it is not available across the whole range.
Everywhere else the honest framing is dual SIM robot cell failover as fast recovery, not zero loss. Design the cell so a two-minute gap is an inconvenience: buffer what must not be lost at the sender, keep the safety decision local, let inspection data defer.
The Byte Budget: Four Cell Types, Four Numbers
| Cell type | Safety + process | Inspection | Burst events | What dominates |
|---|---|---|---|---|
| Welding | Small, periodic | Seam camera 0.4–1.2 MB/part; weld trace records | Waveform download after a quality hold | Inspection, if the camera streams |
| Machine tending | Small; frequent handshake with the machine tool | Often none, or part-present only | Program load at changeover | Process — rarely bandwidth-bound |
| Dispensing / sealing | Small | Bead inspection camera; force-torque trace if enabled | Path program upload | Camera cadence |
| Assembly with fastening | Small | Torque-and-angle records, 2–20 kB each × many fasteners | Batch traceability export | Record count, not record size |
| The one measurement to take before setting any ceiling |
| Measure worst-case throughput at the installed antenna location, at the busiest hour, on the weakest carrier you intend to use — then set the ceiling below that figure. Nominal bearer rates, coverage maps and a speed test taken at 06:00 on a Sunday all give a number the cell cannot achieve at 14:00 on a Tuesday. |
A robot cell bandwidth budget built this way settles the carrier question before contract time, which is usually when it gets discovered. If worst-minute demand is 40 MB and the measured uplink is 8 Mbps — roughly 60 MB per minute at best, less in practice — the cell is marginal on LTE, and a 5G router for robot cell deployment becomes an engineering decision, not a marketing one. The 5G models here are the H685f, H685frc, H900 family and H820QO; the RedCap H685frc is worth quoting between 4G capacity and full 5G cost.
Ports, Addresses and the Models That Fit
Segmentation is a physical problem as well as a logical one: four VLANs are easier to justify when the box has enough ports for each domain to land. Port count is the least glamorous line in a datasheet and one of the most consequential — a shortage of ports is what pushes people into putting the camera and the safety PLC on the same domain.
| Model | Ethernet ports (datasheet) | VLAN 802.1Q | QoS | SIM | Fit for a four-domain cell |
|---|---|---|---|---|---|
| H900 | 5 × LAN/WAN 10/100/1000 Mbps; 4 LAN with PoE/PoE+/PoE++ (802.3af/at/bt) | Listed | DSCP + Priority Queuing | Dual SIM; dual modem dual SIM online option | Strongest fit — ports, segmentation, redundancy |
| H900f / pf / uf | 2 × GbE + Megabit ports (PoE on 2 LAN, varies by model) | Listed | DSCP + Priority Queuing | Dual SIM | 5G with fewer GbE ports — plan domains accordingly |
| H820 | 5 × LAN/WAN | Listed | DSCP + Priority Queuing | Dual SIM | Good general-purpose cell router |
| H820QO | 2 × LAN | Listed | DSCP + Priority Queuing | Dual SIM (single standard, dual optional) | Only IP68 unit — outdoor/washdown cells, but 2 ports limit domain count |
| H700 | 5 × Gigabit | Listed | DSCP + Priority Queuing | Dual SIM | 5 GbE ports; also the only model with two serial ports |
| H720 | 5 × LAN/WAN | Listed | DSCP + Priority Queuing | Dual SIM; dual modem dual SIM online | Where continuous connectivity matters |
| H685 / H685f / H685frc | Gigabit Ethernet (compact form factor) | Listed as “coming Q4” | DSCP + Priority Queuing | Single SIM | Confirm 802.1Q firmware state before specifying |
Address planning that survives an audit
Three rules, and they cost nothing at design time. One subnet per VLAN, numbered legibly from the VLAN ID — VLAN 10 on 10.10.10.0/24, VLAN 30 on 10.10.30.0/24 — so a routing table read at 2 a.m. needs no cross-reference. Never rely on the cellular IP address: it changes on session re-establishment, it is usually behind carrier-grade NAT, and inbound connections generally do not work. Anything that must be reachable is reachable because it initiated an outbound tunnel, not because somebody port-forwarded to it. Reserve the management address on a domain nothing else uses.
Where robot cell network segmentation has to coexist with legacy serial equipment, note the constraint that runs across the whole range: the datasheet line is “Serial Port RS232 or RS485” — one port, configured as one or the other at order time, not switchable in the field. The H700 is the only model with two serial ports (one DB9, one terminal socket). If the cell has a torque controller on RS-485 and something on RS-232, that fact decides the model before anything else in this article does.
The corresponding software capability — Modbus and DTU (serial to cellular) — is listed on the H685, H685f, H685frc, H720, H820, H820QO and the H900 family. What the datasheets do not state is the Modbus master/slave role, whether the unit converts RTU to TCP, or how many concurrent transactions it holds. Genuine open questions at specification time — better asked at order time than discovered at commissioning.
The Physical Envelope Nobody Puts in the Network Design
A segmentation design that is correct on paper and impossible in the cabinet gets abandoned at 23:00 on the Sunday before start-up. Two physical facts decide whether the box survives, and both are in the datasheets.
Temperature and humidity. Operating specification across the range is −35 °C to +75 °C, storage −40 °C to +85 °C, 5–95% RH non-condensing. A cabinet near a welding cell or above a heat-generating drive sees temperatures a commercial router will not tolerate. And “non-condensing” matters too — a cabinet that sweats during a shutdown is a siting problem, not a router problem.
Ingress. Almost every unit is IP30 in a metal case with anti-lightning protection — right for a DIN rail inside a cabinet, wrong for a washdown cell or outdoors. There is one exception: the H820QO is the only IP68-rated unit. It also has only two Ethernet ports, so plan the four-domain design around that from the start.
Power. Input is 5–40 V DC (5–60 V DC option), with dual power inputs and failover — dual or tri on the H685, H685f, H685frc, H750, H900 and H900t6. A cell network on a single feed reboots with the supply disturbance, and a reboot discards every queue, tunnel and classification. If the cell has both a 24 V instrument supply and a control supply, feed the router from both.
A router in a steel cabinet with its antennas in the same cabinet is a router with a poor link — and a poor link means a lower shaping ceiling, which means the inspection stream backs up, which presents to the plant as “the network is slow”. Antenna placement is a QoS parameter; it is just not written down as one.
Commissioning Checklist: Twelve Steps, in This Order
The order matters more than the steps: classification has to exist before there is traffic to classify, and the failure test has to happen before production.
- Enumerate the four classes first. Note per device: safety, process, inspection or service.
- Confirm VLAN capability on the bench. Not the family — the unit and its firmware. VLAN 802.1Q robot cell design only counts if 802.1Q works.
- Assign VLAN IDs and subnets legibly, and keep a port-to-VLAN drawing with the cell.
- Classify on ingress — by port or tag — and mark DSCP there.
- Build two behaviours: strict-priority for safety and process, rate-limited for inspection, ceiling below measured worst-case uplink.
- Measure the uplink at the antenna location, busiest hour, weakest carrier. Write it down — every later argument is about it.
- Verify behaviour on total radio loss, cell in automatic. The stop category must match the risk assessment; repeat after any safety change.
- Set keep-alives to tens of seconds, not the OS default of hours. A switch noticed two hours late is a two-hour outage.
- Build the remote-service conduit: own VLAN, no route to the control domain, tunnel on the router, MFA, time limit, logging, named owner.
- Test the failure you designed for: saturate the uplink with a real burst; process latency must not move.
- Force a SIM switch under production-like load and record recovery times against Section 08.
- Export the config and photograph the cabinet. Later they are the only artefacts answering “is it still configured as specified?”
| Field case · Automotive Tier-2, welding cells |
| “The seam cameras went live in month four and the cells started stopping. Everyone assumed the robots had a problem. It took two weeks to find out the camera flush was filling the uplink and the safety watchdog was tripping on delay — nothing was broken, the traffic was just unclassified.” |
| A Tier-2 supplier running 14 welding cells added seam-inspection cameras to an existing cellular backhaul. Within three weeks spurious safe-stops reached 11 per cell per week, all logged as watchdog timeouts, none traceable to a hardware fault. Four VLANs and a rate limit below the measured worst-case uplink brought it to under 1 per cell per week. No hardware, camera or carrier contract changed — the only thing that changed was who was allowed at the front of the queue. |
Frequently Asked Questions
Q1：Can safety traffic really run over a cellular uplink?
PROFIsafe, FSoE and CIP Safety follow the black channel principle in IEC 61784-3: they assume the transport is untrusted and add a sequence number, watchdog, connection ID and CRC. A wireless segment is not disqualified — it enlarges the network term in safety reaction time, which you must re-validate. Two boundaries hold: no radio link carries a hard closed-loop control function, and a mobile axis has a defined behaviour on total radio loss, set by the risk assessment, not the router. PROFIsafe over VLAN separation does not make safety depend on the network — it prevents avoidable watchdog trips.
Q2：Does QoS help if the carrier ignores my DSCP marks?
Yes — the guarantee is created locally, not by the carrier. Your router’s egress scheduler decides which queue goes next while the uplink is busy, before the packet reaches the radio. The local queue protects latency during saturation.
Q3：Which E-Lins models support VLAN 802.1Q today?
The datasheets list VLAN 802.1Q on the H700, H720, H750, H820, H820QO and the H900 family. On the H685, H685f, H685frc and H820Q the line reads “VLAN 802.1Q (coming Q4)” — a roadmap item, not a shipped feature. The H685t and H685w list only “VLAN — support multi-LAN”; the H685m, M300 and M400 list none. QoS (DSCP and Priority Queuing) covers a wider set. Confirm the firmware state at order time.
Q4：What happens to my VLANs and queues during a dual-SIM failover?
Nothing, and that is the point — VLAN and queue policy are local configuration with no WAN dependency, so they hold the instant the new session comes up. What does not survive is anything on the old IP session: the address changes, TCP connections are dead but undetected until keep-alives expire, and tunnels must be rebuilt. Keep-alives in tens of seconds; buffer what must not be lost at the sender.
Q5：Can the OEM reach the controller without leaving a VPN permanently open?
Yes, and it should be. Give remote service its own VLAN with no default route to the safety and control domains, and terminate an IPsec tunnel that comes up when a session is authorised and tears down when it ends. Bound it in time, scope and observability — a tunnel that is always up is just a standing VPN.
Q6：Why not just give the cameras their own router and SIM?
Sometimes. But it moves contention from a queue you control to two radio links that vary independently, neither knowing what the other is doing — and doubles the contracts and failure modes. One uplink with a rate-limited queue keeps arbitration where all four streams are visible. Separate links suit cases where inspection demand exceeds one shaped uplink — the Section 09 budget tells you.
| The short version |
| A robot cell does not have a bandwidth problem; it has a classification problem, and the router is the only device that sees all four traffic classes when they contend for one radio slot. Cut the cell into four VLANs by consequence rather than by device. Build two behaviours: a strict-priority queue for safety and process, a rate-limited queue for inspection, ceiling below the uplink capacity you measured on a bad afternoon. Prioritising safety frames protects cycle time, not people — PROFIsafe stops the cell safely on its own. Treat remote service as a door with a time limit. And confirm the environment — −35 to +75 °C, IP30 in a cabinet, IP68 only on the H820QO — before finalising the port plan. |
Designing the network for a robot cell?
Send us the traffic list — what talks to what, how often, and how much — and we will tell you which models carry VLAN 802.1Q and QoS today, how many domains the port count supports, and whether the byte budget puts you on LTE or 5G.
