Welcome to the new Schneider Electric Community

It's your place to connect with experts and peers, get continuous support, and share knowledge.

Close
Important Announcement: WELCOME to the new Schneider Electric Community! Community is now no longer part of Exchange, and is now rebranded under se.com. If you have any bookmarks and links saved, we request you to update them to ensure that you continue accessing our community from this new location. For any issues that you might encounter as part of this change, please reach out to SchneiderCommunity.Support@se.com, and the team will help to get your issues resolved.
Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we’ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
82410members
349920posts

SCADA - Ethernet Radio Qs!

Remote Operations Forum

Collaborate and share knowledge on the extensive range of remote systems and devices, including SCADA radios and RTUs, on the Schneider Electric Exchange Remote Operations (formerly SCADA & Telemetry) forum. From commissioning SCADA integration devices and software, to enhancing existing installations or troubleshooting, connect with a global community of experts and users. Subscribe today.

cariebens
Crewman
Crewman
0 Likes
2
342

SCADA - Ethernet Radio Qs!

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

2 Replies 2
Joel_Weder
Commander Commander
Commander
0 Likes
0
328

Re: SCADA - Ethernet Radio Qs!

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...

 

Joel Weder
Remote Operations Specialist
Schneider Electric
BevanWeiss
Spock
Spock
0 Likes
0
180

Re: SCADA - Ethernet Radio Qs!

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).


Lead Control Systems Engineer for Alliance Automation (VIC).
All opinions are my own and do not represent the opinions or policies of my employer, or of my cat..