(Kevic27) #1

So i was just thinking about LoRaWAN applications and what would be one way you could explain it by giving an application as an example and i came up with the idea of using it for SCADA (Supervisory control and data acquisition). It obviously isnt directly connected to some port on a system, but using IoT devices, this can collect data. the only problem i can really think of is the downlink for the actuators as i have read that there are some limitations.
This is something i would actually like to try so thoughts anyone? any problems i havent really thought through? Improvements?

(Arjan) #2

This sounds like realtime data. But LoRaWAN cannot guarantee that messages are received. It supports “confirmed” messages, but that will introduce a delay of 2 seconds (RX2) to know that a message was not acknowledged, while the duty cycle regulations will not allow a node to resend right away if it does not get a confirmation. And indeed downlinks are very limited, and confirmations are downlinks too.

Also, for Class A devices (the current status of TTN) downlinks are only possible after an uplink.


(Kevic27) #3

Would it be more easily implemented using a Class C device and sending data to your own server? Or maybe only partially implementing the monitoring aspect of SCADA? Because i was looking it up and i did see this link https://flexscada.com/remote-site-monitoring/flexs-q4-link-labs-lora-radio-module/


However you implement it, the fact that LoRa(WAN) is a best effort communication technology remains. LoRaWAN is great as a low cost technology for capturing low-throughput remote data, but you must always assume that messages at random times might not be received or might be delayed.

I think LoRaWAN is very suited to provide a SCADA system with supplementary data, but process critical data and actuator commands should always be made on a deterministic communication system. E.g. WirelessHART is an example of a wireless deterministic fieldbus.

(Arjan) #5

If you follow the link to Link Labs on that page, you’ll see that’s not LoRaWAN but their own proprietary protocol.

Using LoRaWAN Class C and/or your own server is not going to help if you need a lot of downlinks, as the current gateways are half-duplex, so won’t be listening to any channel if it is transmitting a downlink for just one node. Also, you’d still be sharing the air space, so the packets handled by your own server will still collide with other simultaneous transmissions on the same frequency.

(Kevic27) #6

Oh i think i understand a bit more, thanks for your input and help sir :+1:

(Kevic27) #7

Thank you, i will take what you have said into consideration

(Tim Everitt) #8

The term “SCADA” can mean many things from hard-realtime closed-loop control through to low-rate monitoring. As always it is very important to define what you are trying to achieve. The standardised engineering toolset to define requirements uses Functional Safety (per IEC 61508, etc.), Safety and Integrity Levels (SIL, per IRC 61508, etc.) and Failure Modes and Effects Analysis (FMEA). The most common radio technology for industrial SCADA sensors and actuators is IEEE 802.15.4 running in the 2.4GHz band (no duty cycle limitations) and is used as the PHY layer for WirelessHART, LECIM, ZigBee, etc. It’s short range and so mesh topologies are used. LoRaWAN is a good long-range low-rate service for battery-powered sensors and actuators with low/no reliability requirements and low/no timing requirements. So, LoRaWAN has its place in the SCADA world but - as always - needs to be driven by clear requirements.

(Kevic27) #9

This is very useful, thank you for your input.
I would like your thoughts on something though, given that LoRaWAN is low/no timing requirements I do not think is as big of an issue as the low/no reliability requirements. I cannot particularly think of any practical use cases for LoRaWAN based on the low/no reliability aspect. Can you think of any situations where LoRaWAN can be used as a form of SCADA? Obviously I haven’t defined what I am trying to achieve but I was thinking of LoRaWAN being used for rural setups, possibly in jungle operations for monitoring equipment setups, similarly with mining, oil and gas setups and other such ventures that take you out of a town into jungles or forests.

(Tim Everitt) #10

I am personally working on LoRaWAN deployments in 3 areas where I think that it is well suited. (1) is distributed asset tracking, (2) is agri-tech for both livestock and arable, (3) is urban asset condition-monitoring. All these deployments are tolerant to transaction-loss. The relevant statisticians have advised that as long as transactions are repeatedly sent (e.g. once per hour) then as long as transaction-delivery is 80% or better then, over time, the information will be good-enough for reliable use. None of these deployments have human safety or environmental safety dependent on single individual LoRaWAN transactions.

(Kevic27) #11

What you’re saying makes alot of sense. What do you think about it being implemented as a comparative system for SCADA? So you could have your main SCADA system and when you receive results from LoRaWAN sensor setups you can compare results. Maybe in the case of something like water flow monitoring you can examine flow rates at different points and intermediately compare the flow rate results instead of real time.
Also I was thinking about it in terms of those older “legacy” systems; one that do not have the parts necessary for SCADA implementation such as the connection ports, LoRa could be seen as an IoT solution. (as you said though, maybe not for systems dealing with safety and real time reliability)

(Tim Everitt) #12

I don’t personally think that “comparative” use as you describe is likely to be valuable. This is all part of a much larger array of technologies and products that I think of as “automation”. “IoT” is just a catchy new name. The key game-changers delivered by LoRaWAN (and Sigfox) are; new radio technologies that increase range, operation on ISM RF spectrum, miniaturisation of price, miniaturisation of physical size and miniaturisation of electrical demand. These game-changers significantly move the point at which it becomes technically and commercially viable to implement automation. In my opinion, this is where the real LoRaWAN use-cases are.

(Lora Wansmaru) #13

You can send downlink messages(Acknowledgement) for every packet you receive even when you use Class A but it can make the whole scenario a bit slow as when your Gateway listens to nodes it does not send acknowledgements, however there is no limitations on the downlink messages Gateway sends. For this you have Class C but you need to have a Gateway who supports Class C. Hope it helps.

(Arjan) #14

It’s the other way around: a gateway cannot listen to any of its frequencies and spreading factors when transmitting a downlink on just one. And beware that nodes don’t know when a gateway is not listening, so might very well send at that same time. And then they will send even more messages when they don’t receive the acknowledgement, increasing the chances for collisions with messages from other nodes or gateways, just worsening the problem.

The acknowledgements of confirmed uplinks have a bad impact on your network.

Yes, there is: a gateway has to comply with the same regulations as other LoRaWAN devices (the nodes). So, in regions where a maximum duty cycle is applicable, a gateway needs to adhere to that too. And it needs to handle many nodes within that maximum duty cycle; when handling 1,000 nodes then its duty cycle will be exhausted 1,000 times sooner than that of one of those nodes. And it might also need downlinks for OTAA Join Accepts and ADR.

Excessive downlinks (including acknowledgements for confirmed uplinks) are bad for the network. There’s a very good reason why TTN limits that to at most 10 per node per day.