Sök bland vanliga frågor (FAQ)
Trio Q Series - Bandwidth Challenges
It is important to ensure clarity about the bandwidth capabilities of the Trio Q Series data radio. There are significant challenges with trying to connect a high speed (hard-wired) LAN to a narrowband radio system. The Q radios are capable of at BEST 32 kbps over-the-air, compared to at least 10 Mbps for a hard-wired system. (often as much as 1 Gbps) On average this 32 kbps will actually be less due to several factors, for example:
- The radio system's own internal protocol overhead
- Some radio links may have lower receive signal levels (or higher interference/noise levels) so have to talk more slowly eg 16 kbps now and then or maybe even once in awhile 8 kbps.
- A system may include some repeaters. Store & Forward type repeaters will significantly increase the latency (delay) on any message sent through them. (typically double)
When sending a single polling message (eg Modbus) through a Q Series radio system including NO repeaters, the typical delay might be around 100 milliseconds, not counting any necessary response time by the destination RTU or PLC. Through one repeater it will go up to around 200 ms. Through 2 in-series repeaters the delay will again rise, to around 300 ms. If there are collisions due to overly-high traffic loading, or interference/noise events, there will be significant delays caused by radio layer Retries. Any SCADA Host system must as a result be ready to wait as much as 2-3 seconds for a response, though it would typically get a response in the time frame discussed above. (based on number of in-series repeaters)
When a Q Series radio system is configured for the (default) Transparent Bridge mode, each radio will transmit all data that it hears on its LAN ports. If there's a repeater in the system, it likewise will repeat everything. The only exception is that in each radio you can enable a simple Ethernet traffic filter. There are three settings. Off is the default. ARP and Unicast Only allows through Address Resolution Protocol messages and messages addressed to specific destinations. Unicast Only is rarely used as it requires the creation and maintenance of an ARP table on each computer connected to the radio system. The filter will help block unwanted Broadcast traffic and some Multicast traffic, but cannot help at all with Unicast traffic. (traffic with a specific destination)
If the radios are configured for IP Routing mode, typically to allow multiple repeaters in one system, ARP messages will, by default, be blocked from going over the air as the radio system is now considered to be a Wide Area Network (WAN). ARP only exists on a LAN. That's one good thing. Each radio and any devices locally connected must be configured to be on a unique LAN in this mode. Then IP Routing rules are created in each radio to forward messages to an appropriate destination LAN. If there is no Routing rule in a radio for a message directed to a specific LAN, it will drop that packet. So IP Routing rules can help block some traffic not meant to go over the radio system. But such rules cannot stop or slow down traffic for which rules exist.
The biggest single problem that can exist is when the SCADA Host computer is configured to poll many sites very rapidly for a very large amount of data. This works fine on a 100 Mbps hard-wired network but will drag a 32 kbps radio link to its knees. No sort of filter can block this from happening, as all the traffic is desired traffic, there's just way too much of it. The only way to make such a system work is to ensure that only ONE message goes out at any time, then the SCADA Host waits for the reply, then after a brief delay it sends the next message. Note that the "brief delay" mentioned is perhaps 100 milliseconds between polls, to give the radio system time to perform its own internal "housekeeping" functions without creating great odds of collisions or timeouts. If there were some way to tell the Host to poll rapidly when on the high speed system, and to slow down and add those 100 ms pauses between polls, when on the backup system, it would work far better.
- The radio system's own internal protocol overhead
- Some radio links may have lower receive signal levels (or higher interference/noise levels) so have to talk more slowly eg 16 kbps now and then or maybe even once in awhile 8 kbps.
- A system may include some repeaters. Store & Forward type repeaters will significantly increase the latency (delay) on any message sent through them. (typically double)
When sending a single polling message (eg Modbus) through a Q Series radio system including NO repeaters, the typical delay might be around 100 milliseconds, not counting any necessary response time by the destination RTU or PLC. Through one repeater it will go up to around 200 ms. Through 2 in-series repeaters the delay will again rise, to around 300 ms. If there are collisions due to overly-high traffic loading, or interference/noise events, there will be significant delays caused by radio layer Retries. Any SCADA Host system must as a result be ready to wait as much as 2-3 seconds for a response, though it would typically get a response in the time frame discussed above. (based on number of in-series repeaters)
When a Q Series radio system is configured for the (default) Transparent Bridge mode, each radio will transmit all data that it hears on its LAN ports. If there's a repeater in the system, it likewise will repeat everything. The only exception is that in each radio you can enable a simple Ethernet traffic filter. There are three settings. Off is the default. ARP and Unicast Only allows through Address Resolution Protocol messages and messages addressed to specific destinations. Unicast Only is rarely used as it requires the creation and maintenance of an ARP table on each computer connected to the radio system. The filter will help block unwanted Broadcast traffic and some Multicast traffic, but cannot help at all with Unicast traffic. (traffic with a specific destination)
If the radios are configured for IP Routing mode, typically to allow multiple repeaters in one system, ARP messages will, by default, be blocked from going over the air as the radio system is now considered to be a Wide Area Network (WAN). ARP only exists on a LAN. That's one good thing. Each radio and any devices locally connected must be configured to be on a unique LAN in this mode. Then IP Routing rules are created in each radio to forward messages to an appropriate destination LAN. If there is no Routing rule in a radio for a message directed to a specific LAN, it will drop that packet. So IP Routing rules can help block some traffic not meant to go over the radio system. But such rules cannot stop or slow down traffic for which rules exist.
The biggest single problem that can exist is when the SCADA Host computer is configured to poll many sites very rapidly for a very large amount of data. This works fine on a 100 Mbps hard-wired network but will drag a 32 kbps radio link to its knees. No sort of filter can block this from happening, as all the traffic is desired traffic, there's just way too much of it. The only way to make such a system work is to ensure that only ONE message goes out at any time, then the SCADA Host waits for the reply, then after a brief delay it sends the next message. Note that the "brief delay" mentioned is perhaps 100 milliseconds between polls, to give the radio system time to perform its own internal "housekeeping" functions without creating great odds of collisions or timeouts. If there were some way to tell the Host to poll rapidly when on the high speed system, and to slow down and add those 100 ms pauses between polls, when on the backup system, it would work far better.
Publicerad för:Schneider Electric Sverige
Utforska mer
Produktfamilj
Utforska mer
Produktfamilj
