SCADA - Ethernet Radio Qs!

[cariebens]

Heya all,

What ethernet radios are you guys using for your remote SCADA systems? (Water/Wastewater, Oil, etc)

Isn't there an inherent issue of broadcasts on the network that could potentially flood the network? Or is this remedied by proper network planning - managed switches, VLANs, access rules etc.

Looking for some ideas, or at least someone to throw some ideas off of.

Thanks

[Joel_Weder]

I'll let others respond about their field experiences, but I can comment about the capabilities of our Trio Ethernet radios. 

Yes it is possible to easily overload an Ethernet radio network with traffic from an un-disciplined LAN. Consider that the LAN may be operating at 100 Mbps or even 1 Gbps, while the radios may be operating at well under 1 Mbps - in some cases as low as 8 kbps. We include features in the radios to help with this bottle-necking, including (depends on radio type):

- Spanning Tree typically disabled (can be enabled if required)

- Default filter type is "Allow ARP and Unicast" to ignore broadcast & multicast traffic

- Filters which allow many typical protocols to be either allowed or blocked

- Ability to filter based on port #, MAC or IP address

Also, QoS (quality of service) can be configured to ensure each protocol is configured with a maximum allowable data rate. 

I look forward to hearing from others about their actual experiences & lessons learned...

[BevanWeiss]

We tend to use whatever the customer has ingrained, this has been 4RF (Aprisa SR/SR+), Trio radios (D,S,M,E,Q), and GE (MDS) [if we excluded other analogs].

When it comes to digital 'ethernet' radios it is harder to keep the traffic 'clean'.

Having it on a separate VLAN can be incredibly useful, but also makes troubleshooting that much more difficult.

As do things like firewall rules etc.

Definitely blocking multicast traffic (excluding ARP) can be helpful, certainly if you have Rockwell Multicast / EthernetIP IO devices on your network you'll want to give this special consideration.

You'll still tend to get quite a lot of spurious noise if you have PCs etc on the shared network, since they seem to ask for ARP resolution of email servers, domain controllers and lots of software update services very frequently.

This small traffic can have a surprisingly negative impact on a telemetry radio network, it can generate collisions, and just in general messes with the nice orderly seuencing of network traffic.

There are a range of things that can be done, like QoS (prioritising DNP3 / control traffic, and de-prioritising things like HTTP/HTTPS.. but you still need ARP to be prioritised or other things stop working in less graceful ways).

I would really recommend a high level network segmentation however.  That has the best chance of cleaning things up.

Using an RTU with multiple ports can be very helpful.

So my most preferred configuration is with something like the SCADAPack x70 series, and their three ethernet ports.

You can have 1 port dedicated for Radio comms, another port for PLC/IO network traffic comms, and if necessary the 3rd port for SCADA/HMI comms (if not already on the PLC/IO network).