Arduino-based SCADA guidelines

[Dannyx]

Good day everyone. I hope I'm posting in the right place, since this topic may very well fall into other categories as well, but I thought I'd go with the beginners section, because that's what I'd be called in this situation

Here's the deal: I'm trying to design (although "design" is a bit too ambitious at the moment) a system to monitor some remote stations which are out in a field somewhere. These stations are some very small sewage treatment gadgets which pass water through some filters with the help of air to essentially separate the solids from the water which is then sent on its way to a bigger plant of facility or whatever - doesn't matter. The operation of the stations themselves is also beyond the purpose of discussion at the moment, so why am I doing this ? These stations are completely "dumb", meaning there's no monitoring of anything at all: no sensors, no control panel or display, no PLC, nothing. Just an air pump plugged into a wall socket with an MCB ! That's it: it just pumps away constantly until either a worker comes by to shut it off or until the pump's diaphragms give in. My idea is to smarten these up a bit to both learn something new and valuable in the process (SCADA) and make life easier for the crew who has to periodically check on them. There's 12 of these all together in various locations around the county and they're spread over a very large area too, so that comes down to a lot of gas mileage...

At the very least, I intend to add to each box two temperature sensors as well as an airflow meter to the output of the pump. The temperature sensors would read both the temperature inside the box as well as of the outside air (for reference) and turn on a fan when the box gets too hot inside. The pump is a medium-sized pump (brand name "Secoh" if you want to search for pictures, for reference) inside this box which gets scorching hot in the summer when the sun is beaming down directly on it in the middle of nowhere ! The airflow meter would report when the pump has stopped for whatever reason. The possibilities are endless really.

How do we achieve all this ? Surely there's off the shelf solutions out there already doing this sort of SCADA, but I want it to be both DIY as well as budget friendly, so I thought an Arduino might be ideal.

Now here's why I said it may be too ambitious: I DO know my way around the Arduino to a degree. I have built some small projects with it and am familiar with the interfaces and some of the commands, so that is the easy-ish part. I don't know squat about programming though ! The HMI (the PC program the user looks at and sees all the values and controls) is what brings me to my knees in this whole deal: I have no idea where to start really. I need the Arduinos in each station to read some pins and report the values back to a DIY program on a remote computer....yikes :| We start off small, on the workbench of course. You can't expect it to work straight away without thorough testing...

That is what I DON'T know how to do. What I AM willing TO do is learn just that. Trouble is I'm not entirely sure WHAT I should learn...there's so many resources and possible versions of this project that I really don't know which way to look ! Most seem to revolve around around C#, something I've never worked with unfortunately. I don't think it's feasible for me to start learning C# from the absolute beginning hoping that I'd eventually gain enough knowledge to design something like this, so my idea is to find a pre-made program and adapt it to suit my needs....not sure. Like I said, VERY intimidating stuff. So many protocols too ! RS485, Modbus....man ! Makes your head spin, especially since there's no universally agreed on version ! Every time I think I'm about to stick to an idea someone demonstrates, ANOTHER one pops out and makes me think "hmm...yeah, this one's even better" and by the time I finish looking into that one, ANOTHER one comes up....

THIS one comes rather close to what I'm trying to do, but the HMI part is lacking, since it's made in that third party tool the guy shows, which although makes it easier, doesn't look like there's a way to expand it and make it "multi-client", though I haven't looked into it. Seems that "MUDBUS.H" is also a popular library to add to the Arduino to do this.


I'd like some pointers or ideas about how I should go about achieving this. I'd mean a lot to me. Thank you.

[rstofer]

The only way to eat an elephant is one byte at a time.  Start somewhere and keep going until it is done.

I think MODBUS is as good as any and, specifically, MODBUS RTU using RS485 as the link layer.  You will have to find examples of this using Arduinos.  You obviously need a master node in the office (I would use a Raspberry Pi because it has networking and a disk) and then some number of Arduinos for the slaves.

If you wish, you can use the Arduino MODBUS Library with wired Ethernet or WiFi.

So, build up a couple of slaves and a master and get them talking to each other.  That's step 1.

Then build out the slaves in terms of sensors and the ability to report specific measurements in response to specific request.

It doesn't look like there is a TCP version of MODBUS for the Pi but I didn't look all that hard
https://www.instructables.com/id/How-to-Use-Modbus-With-Raspberry-Pi/

Here's an Instructable for the Arduino:
https://www.instructables.com/id/How-to-Use-Modbus-With-Arduino/

There's a lot of info on the Internet but the two Instuctables will probably get things talking.

For the Arduino:
https://www.arduino.cc/en/ArduinoModbus/ArduinoModbus

More for the Pi
https://jacekhryniewicz.wixsite.com/website/raspberry-pi-with-modbus-tcp

The nice thing about wired Ethernet is that the TCP protocol guarantees a clean packet but you need one network cable per gadget.  RS485 is just a pair of wires (and shield) strung between the devices.  WiFi has the advantage of being, well, wireless.  This helps prevent ground loop issues or differing ground potentials along the route.

The question with WiFi is whether it is close enough to the master or to some access point.

Lots of decisions to make...

Finally, teach the Pi what questions to ask of each slave and them decide what to do with the data.  Archive it in a file?  Present it on a web page?

This project is going to take a while!

[rstofer]

If RS485 is practical, that's probably the way I would go.  It's simple, there is an add-on board for handling it and the Arduino library already exists.  I would string 3 or 4 Arduinos together with perhaps 1 meter of cable between them.  I guess I would stick them down to the bench so they didn't flop around.  You will be programming them individually so I would connect them all to a powered hub.  I would figure out which COM port each slave used so I would know which port to select in the Arduino IDE.  To program a different device all I would have to do is change the COM port.  Simple!

On the Pi, I would probably be using the command line for everything so a simple Telnet session should work fine.  PuTTY seems to work pretty well for me.  If you want to use gedit, you need to use the Pi console, Telnet won't handle it.

Here's something cool!  If you use a Raspberry Pi as the master, you can install the Arduino IDE and libraries and use the master to program all the slaves.  The whole project and all the development tools run on the Pi.  The new 4GB Raspberry Pi 4 makes a terrific development platform.  I use it as my preferred desktop when I am using Linux.  It's pretty darn fast!

https://www.amazon.com/gp/product/B07TXSQ47L

Scroll down a bit and pick up the entire package for $82

[RoGeorge]

For the HMI side, could be:
- MyOpenLab (a very light alternative to LabView)
- Scilab/Xcos (a light alternative to Matlab + Simulink)
- Node-RED (a more recent platform)
- Python (runs on almost any OS and and on almost any machine including Raspberry Pi, has plenty of modules about anything one can imagine, probably the best option)

There are some other free open source platforms out there, some are intended for SCADA, some already have (or are built around) a Modbus server, etc. but last time I searched (some years ago) couldn't found any to remember.

[Dannyx]

Thanks for the nice pointers. It really helps.

No, I don't think RS485 is possible in this case because from what I understand, RS485 is used to connect a master to a slave. In this case, it would connect the Arduino with the sensors on it to the Pi or whatever on the HMI side. Trouble is, if I understand it correctly, RS485 is a wired-type connection, requiring 3 wires at the very least. This obviously won't work in our applications because the stations are miles away from each other and from where the operator watching the HMI will sit, so wires won't work here - we have to go "cellular" (though this may be the wrong term for it).

It just so happens this company I work for also manages some other remote stations, in the form of shipping containers housing some industrial equipment which also talk to a head office to report various water parameters and the way they did it there was via a GSM modem with a SIM card in it which essentially connects the container to the internet. The head office probably has a VPN setup to these to access the different devices there as if they were part of the LAN so this is what I'm thinking of doing as well: hook up the Arduino to the internet via its Ethernet shield right at the box where the pump is and then VPN to that network to make the Arduino feel as if it were sitting next to my HMI (Pi, PC, other Arduino whatever the "base station" may be), so to simulate this, I first need to get the sensors and the TCP connection going on the bench and THEN worry about deploying it in the field as described...I have an Arduino Mega on hand, but don't have a shield for it. Guess it's Aliexpress time and....well...... I'm just going to go for it - the only way to do it is to just...do it

[Dannyx]

I did some more research on my own to clear things up a bit. I installed the Arduino MODBUS library to have a look through it, but haven't actually done anything with it - I'm still learning how it works so I know exactly what hardware I'd need.

One example in this library shows reading a temperature sensor. This is perfect and it's one of the things I'm actually trying to achieve here, but then I noticed the temperature sensor ITSELF speaks MODBUS and this is where I got a bit confused: my idea was to use any random junk I find Aliexpress to make this work, but turns out this particular example employs a device which specifically speaks MODBUS....hope that makes sense. I thought MODBUS refers ONLY to the protocol between the Arduino reading the sensor and the PC or Raspberry PI hosting the HMI (the "master" and the "slave"), but it turns out some of these sensors use MODBUS out of the box. My image of a "sensor" in "Arduino land" has always been that of a device with either an analog "OUT" pin or an I2C SCL/SDA connection, but turns out there also exist MODBUS ones which talk over those "A/B" wires....

[RoGeorge]

A sensor is a sensor, and can speak whatever protocol, or no protocol.  SCADA architecture is unrelated with Arduino, so take SCADA as a reference, then try to implement it with whatever you have at hand, dedicated HMI (or DIY PC/RPi HMI), industrial RTU and PLC (or DIY Arduino/whatever RTU and PLC), industrial sensor that can talk SCADA protocols like MODBUS (or DIY sensors with a microcontroller), etc.

Sounds like your Arduino library is a Modbus master interrogating other slave devices, in your case the slave device(s) is a remote temperature sensor.

You'll need to find a library that can act as Modbus slave for Arduino, and another library that can act as Modbus master for the HMI side that you'll put in a PC or a RPi.


Any good SCADA design must start with the plant side, and the process you want to monitor and control.
- understand the process and the plant
- choose the number of parameters you need to monitor/control
- decide the range and the precision required for each instruments and each actuator according to the process you plan to control and monitor 
- draw a block diagram with the plant and the location/distances of the main parts including each sensor, each actuator, the command and control room, and the physical distances between them
- draw a diagram with the process, the very one you expect to see in the central HMI display

Only after the above steps are completed, you can move to more details in the design, like deciding the protocols, the physical medium for communication and the architecture/layout of the communication channels, the types of sensors, software packages and libraries and so on.

[Dannyx]

SCADA architecture is unrelated with Arduino

Yes, my title was a bit misleading to begin with, since when I wrote my post my understanding of what SCADA is was a bit fuzzy - it should've been "Let's talk about MODBUS for Arduino"


As far as the actual hardware involved, I'll start off very simple and read a temperature sensor for a proof of concept setup on the bench. Once that's done, I'll add something in the other direction - an output - like an LED to simulate something getting turned on/off. Then connect the two together: if the temperature reaches X, turn on the LED...and just keep expanding I guess...

[RoGeorge]

Let me remind the goals you set by yourself:

Here's the deal: I'm trying to design (although "design" is a bit too ambitious at the moment) a system to monitor some remote stations which are out in a field somewhere.
...
My idea is to smarten these up a bit to both learn something new and valuable in the process (SCADA) and make life easier for the crew who has to periodically check on them.

Again, you are doing it upside down.  You should think it in terms of a SCADA system, not in terms of Arduino thermometer talking Modbus.

Do you want to learn SCADA, or Arduino?

Even more, if you'll try to convince your boss to let you change something with an Arduino thermometer on a breadboard, you won't go very far.  If you'll come with a nice SCADA design, they might listen to you.  Management doesn't care about wires, bits and breadboards, they want to see a bird-eye view presentation, with benefits and costs about something they know well, the plant and the process.

However, if you insist to implement an Arduino RTU thermometer, then just search for "Arduino Modbus RTU thermometer" 

First random search result



(Didn't watch it in full, the author makes some confusion in using the correct SCADA therms, IMO, but it's an example of a thermometer display on the PC using Modbus)

[rstofer]

You really need to write up the actual requirements because it may turn out that SMS is an appropriate protocol and handling that over GSM should be trivial.  Even GSM <=> GSM (a phone call) may be adequate.

There are a lot of GSM/SMS Arduino projects on the Internet.

It gets down to whether or not there is some kind of real-time requirement.  MODBUS, in particular, was created to allow multiple PLCs to talk to each other (read/set relays) in near real-time (there is some latency).  Different control systems within a plant could interact quickly.  Initially, this was low level stuff - relay to relay and quite fast.

SCADA does the same kind of thing with more of an emphasis on the HMI aspects and can be built on top of MODBUS which can be built on top of GSM.  I see it used for building automation and while some amount of logic is available, mostly it is a monitor and display kind of thing.  Lots of time spent creating schematics for display on a monitor.

In your initial description you are talking about small control loops (temp sensor => fan) that could be (and may already be) implemented locally.  Real-time control from a central station doesn't bring anything to the dance because it takes a mechanic to drive out to fix the problem; hardly real-time.  What you do need is notice that something has failed but it's unlikely that a central station (w/ operator) can do much about it or that they could do it faster than a local control (swap pumps with duplexer, etc.).

Your distances are enormous so GSM is actually a pretty good idea.  One approach is to have the central station make phone calls periodically to each of the remotes and get status information.  Another approach is to have the slaves send a text message when something goes wrong.  This would presumably be a lot less traffic but you wouldn't know if a slave had died.  You could have the slave send an "I'm Alive!" text from time to time.

So, figure out exactly what you want to monitor, exactly what you want to control and how long you have to do these things.  Don't force real-time where it isn't necessary.

[rstofer]

If anything is reported to the master as a failure, the master should send an SMS to the appropriate group of people.  This is done all the time in computer facilities.  IT specialists are notified immediately when an error is detected.

The HMI is pretty, the HMI is cool, but if nobody is watching the blinking lights, what good is it?  First there is an alarm, then somebody has to go to the HMI and then figure out how to deal with the problem.  An SMS could include the description of the problem as well as an anticipated solution (bring something special to the site).

There's an opportunity to add real expertise to what would ordinarily be a monitor stuffed in a corner.

Control loops are boring, some amount of machine intelligence is much more interesting.

[Dannyx]

Ok, let's dig deeper: the idea behind this project of mine is, first of all, of course, to gain some credit for coming up with a solution to a problem. Ok, it's not a BIG problem, but the only way to start is to start off small and this is a perfect project, since it doesn't involve dangerous machinery or high voltages (well, 230v at most). The "problem", as you pointed out, is just that: someone has to go visit each station at semi-random to see if there's anything wrong with them - if they had a way to report their status, the tech would only need to go there if needed (dead pump)...that's the way I see it.

I know that particular vid - came across it myself. Actually, monitoring the temperature of the station is entirely optional - it's just a bonus I came up with, since it's probably the most basic thing you can do - it's the pump's output that's important, to know if it's decreased due to broken hoses, clogged intake filters or worn out membranes, or if it's died entirely (torn membrane - happens all the time since it runs continuously).

Sure, an Arduino project doesn't instill too much confidence in the grand scheme of thing, but nobody really cares as long as it performs good, right ? I'd certainly make sure to make the final project "look good". Like I said, confidence in something like this is low because there's no doubt in my mind that there already exists professional equipment specifically designed for stuff like this, but that's just it: the price ! The lower the price of the parts and the cost of the whole project, the bigger the profit can be ! I know what my boss wants and how he "operates" ! Take the money and run ! Who cares as long as it works ?!

[RoGeorge]

At first, you'll need to define a minimum of specifications:
- how many parameters to you want to monitor, and what are those parameters (on/off motor state, RPM, level or debit analog values, etc.)?
- how often?
- what type of sensors do you already have, if any?
- distance matters, how widespread are those sensors, and how many?

Make a block diagram of the plant/system.  Put some distances on it.  You need to know data throughput and distances.  If you don't have the exact values, then put some ranges.

You need to know what is already in place up and running.  Are there any other data systems (or maybe local automation loops), etc.?

[Ground_Loop]

If this is a learning opportunity for you and/or a cost saving effort for your company, great.  But you realize that you're reinventing the wheel here.  All this capability exists in the world of industrial controls already.  Sensors, controllers, SCADA packages, wireless telemetry all exist as now mature technologies and are well established in the water/waste water industries.

[Renate]

It seems that everybody is taking a different approach to all this.
This is mine.
The big/important question is getting data from the remote site to the central site.

Not to be a spoil sport, but a system of putting a big red light on your box and a sign saying,
"If this light is on please call 800-555-1212 and report site #1234."
You'd be amazed how often this technology is usage in water/sewage infrastructure.
Oh, it's not the most reliable solution.

Have you figured out what GSM/CDMA/GPRS/UHF modems will cost? What the service will cost? X 12?

I am a big fan of MODBUS and I'm running 10 ATMega328P custom boards on an RPi,
but you're talking about a small area at each location, so I'm not sure that MODBUS is the best fit.
My little boards have the RS-485 built in, I wouldn't want to use an Arduino with a separate add-on.

Once you have the data connection planned you can add your sensors.

[hendorog]

For dumb-ish sites in the past (20+ years ago) we used off the shelf radio 'modems' with direct I/O connections on them.
You short the input on the remote end, and an output on the base turns on.
You short an input on the base end and the remote end output turns on.
This mapping of inputs to outputs was configurable.
This was in the hills in the countryside around a small town for a water treatment plant (connecting the dam, bores, booster pumps, treatment plant and the office in town), which all had good line of sight.

The base unit also had a serial port which supported MODBUS, so a PLC or other device could poll the state of the registers and view/drive the remote I/O as if it was local.

Google seems to say that there are cellular versions of this concept available now (Cellular remote I/O). Since you are talking sewerage, which implies population, then cellular is probably going to work better than a radio link. There are IoT type remote I/O modem products as well which go via cellular through a server.

I agree with the above sentiment that you should figure out how to talk to the remote sites first.

Some ideas -these are just random google results, not recommendations:

https://www.neteon.net/products/edge-connectivity/remote-io/cellular-remote-io.html
https://www.ursalink.com/en/cellular-io-uc3x

[SmallCog]

There are a few decisions to make early on

Will it be a push or pull network? Modbus SCADA systems operate on a pull system, a slave mostly listens and replies only when spoken to.

In this situation your HMI will periodically hit up each of your sites for a temperature. The sites will just sit there waiting for a read. It works well but your HMI needs to be able to find your sites which can mean mucking around with VPN’s or DDNS if you’re using cellular connections

In the world of monitoring/telemetry/IoT you get both styles, but having the device push its readings can negate some network complexity - you can set up a server on the net and your field devices can talk to it no matter what technology you implement to get them online.

At work I have effluent treatment plants on SCADA but for what you’re trying to accomplish you could also use environmental data loggers or gear intended for irrigation or sports field lighting

There are cheap industrial out of the box devices that will monitor sensors and send email alerts and/or close relays. If you set up a static IP or dynamic DNS you can also pull up a web page and have a look at what’s going on, giving you something like a HMI (but not an overview of your whole network)

There’s 100 ways to tackle this bug if I was knocking this up out of Banggood gear it’d be a D1 or D1 mini talking to your sensors and switching a relay. They’d be using PHP to talk to a server (via a wifi cellular hotspot router thingy) that server would take care of data logging and the HMI and could easily send emails to designated contacts if it senses a failure.

Web people to do php /sql are a dime a dozen letting you outsource the HMI and/or minimising the amount of specialist knowledge required to update or maintain the system later

Run the D1 and hotspot off a battery, monitor the mains to know if your site is down due to a failure or a power outage.

Getting stuff out via PHP with a D1 programmes using Arduino IDE:
https://educ8s.tv/arduino-esp8266-email-tutorial/

Non contact mains sensing with an Arduino:
https://youtu.be/cDuObAR42Nw

An alternative to setting up your own server:
https://youtu.be/XI_2eypZDwc

[Dannyx]

Ok, let's go down this rabbit hole a bit more and keep adding details. Thanks for all the nice replies ! It's really something. I mentioned a few of the details in my original post, but I don't blame anyone for not getting to the end - I tend to ramble on and on and that puts people off...

I thought I'd actually show you some pictures of one of these boxes.....unimpressive, isn't it ? Like I said before, yes, I'm reinventing the wheel here, but it's all a learning experience, plus my company would certainly not be willing to invest thousands in equipment just for me to play with, whereas small development boards like these are easily available and I can even put together a kit with my own pocket money, since they're cheap as chips. The client would also have to agree to this whole project to begin with (these are not OUR stations - we're just providing maintenance to them), so I still have a long way to go before this becomes the new hot sh!t in sewage treatment monitoring....kiddin'

How many parameters to measure: I'd say 3 (box temperature, outside temperature, pump output). I'm sure this can be expanded as needed. I'm not entirely sure which exact sensor I'd use for either of them, but I imagine for the pump output I'd insert a flow meter inline with its output...provided such thing exists for DIY projects like this - haven't really dug up Aliexpress yet to find out. Same for the temperature: I found a variety of sensors, like the DS18B20, but haven't settled on one. Can't figure out how to add links to text by the way...can anyone help me ? I wanted to insert the link to this sensor on Ali

Distance from the sensors to the control board ? 0m to 2-3m at most. The board would sit in that metal box there and would have a temp sensor inside, one on the outside and a flow sensor on that pump, so not far at all.

How often do these need to be read ? Ideally in real time, since there would be someone watching over them, though I'm aware this is challenging on a couple of different levels, so I could probably limit it to each station only reporting if there's an error (which can only mean the pump has died).

What is already in place: nothing. No electronics at all ! Just those MCBs you see there which are manually operated by whoever visits this box (IF EVER !).

It would probably be a "pull" topology for now, as someone said, since there's nothing an operator can actively control at this point (aside from maybe turning that fan on/off, which could be handled by the local Arduino directly once the temperature gets to a certain point). Turning the pump itself on/off remotely may also be something they'd want to be able to do, so a "push" configuration may also be required in the long run, but let's just stick with "pull" for now.

Connecting to the boxes: I'm no network expert, but the way I described it is similar to how I've seen in done in other places: GSM router to get the thing on the internet and then a VPN to the monitoring station....there's a couple of things I'm not sure of, the first being whether multiple VPN connections like these are possible. There's 12 of these standalone boxes, each with their own router and connection ! The software would also need to be able to read that many at once....it gets complicated :|

[Renate]

Of all the parameters we've discussed, we haven't covered money or interest.

Which of these have the owners said?

• "This would be kind of neat if we can do it for a one-off charge of $X for a little equipment."
• "This is important and we can cover a one-off charge of $X and service charges of $Y / month."

Add in the fact that modems seem to cost between $50 and $1500, the MCU/sensor cost could be insignificant.

[Dannyx]

None of that was brought into discussion - that's my boss's job and knowing him, he'd be willing to see it through to completion, since he likes automation and IoT stuff, since he regards it as being the future of IT, so we want a bite of it too JUST fixing electronics is not gonna get you very far, hence why I regard this as a personal opportunity.

[RoGeorge]

LoRa might work too.  The hardware is cheaper, it doesn't make the system dependent of a 3^rd party service/network (the GSM provider), unlimited messages, and it's free to use, while GSM requires monthly payments.

[Renate]

Well, when you're brainstorming it doesn't hurt to think of all the possibilities, even the sillier ones.

• Rooted "burner" phone, i.e. Tracphone. Tap into the internal I²C bus and put your sensors on that.
• Nonrooted "burner" without USB OTG. Use a RPi and ADB to call up an app, paste data and send.
• Nonrooted "burner" with USB OTG. Use an Arduino Leonardo (ATMega32u4) and a custom Android app.

I would be very interested to know what is currently the cheapest new Android that has USB OTG, especially if you can buy it without any airtime add-on.
The Moto E4 does have USB OTG. You can get a used one for $30.

[Dannyx]

Not sure I understand what you're calling a "burner" in this particular setup "Hacking" stuff is interesting and I like it, but in this case I think it might actually complicate the setup....though you could argue what I'm trying to achieve is already pretty complicated.

EDIT: I think the distances are too great for LoRa to cover, though I could be mistaken.

[Renate]

Not sure I understand what you're calling a "burner".

So-called because they are reputedly used by crooks who buy them for a single conversation then throw them away to avoid any evidence of connection.
Edit: Hmm, I do see some new Androids for $25 without any airtime purchase requirement. https://www.bestbuy.com/site/simple-mobile-tcl-a1-black/6325619.p?skuId=6325619
More edits: Wow, I just learned that there are a bunch of resellers of IoT, data-only, 64kbps, unlimited GSM service for about $3/month.
$40 will get you a year.
I think the unlimited is better/safer than paying for each MB, especially when a software bug on your side causes it to jabber emdlessly.

[RoGeorge]

distances are too great for LoRa

Only you know the distances 

This is where that nice block diagram of the whole SCADA system, with the locations and distances between equipment would have come in handy, to know the distances between stations.

"Miles away" or "spread around the country" is not precise enough.  You need to make drawings and define specifications with numbers.  Same for "real time" data, put some numbers.  "Real time" is a dedicated term, and I'm sure you don't need to collect real time data.

It's good you took pictures. 
That's a part of what we called "site survey", together with choosing the location for the new equipment, finding a path and distance for cables, see if there will be any need for buried or suspended cables, etc.

Those boxes looks like they have no climatisation.  If so, no mobile phone and no Arduino will work between -30...+70 *C.  Even the most expensive industrial PLCs will be challenged by the temperatures found in a metal box placed outside.  You will need a minimum of climatisation, or to find some other place for the electronics, for example underground, but then you'll need to avoid moisture/water and gases accumulation, maybe an external antenna, too.

[Dannyx]

I have no idea of the distances myself. All I know, roughly, is that the closest is at 1km away from where "home base" would be (since it's installed right in their courtyard) and the furthest ones are 20km+ from "home base". There IS some documentation for this whole project, outlining where these stations are dropped along the canal, and I had a look at it myself at one point, but I didn't bother to remember anything because I didn't care at that point. The key word is "FAR" !

I probably have hundreds of pictures, several for each of the 12, although there's really nothing different other than their location - the boxes themselves are identical, so that's really all you need to see.

Temperature aspects: yes, I too thought of that. The temperature swings are going to be wild there! Freezing cold in the winter and boiling hot in the summer ! There IS actually a heater in there, in the form of a heatsink with what looks like a resistor in the middle of it, but it's not automated: someone has to go there and flip the MCB to turn it on. At the opposite end of the temperature spectrum, there is no fan to cool the box ! The box cools down purely by natural airflow happening through those vents, which in some cases is not enough. Some boxes are in the shade, under foliage and trees and stuff, which helps to a degree, but most are out in the open...

As a side note, I created a small automation for my car's windows using an Arduino Pro Mini, but haven't installed it yet and I'm actually concerned whether it would survive in a car in the middle of summer when the inside temperatures can probably exceed 50c ! Only one way to find out and that is to take my project which is still on its breadboard inside the car, park the car in direct sunlight and let it roast on the passenger seat for a whole day under the scorching summer sun and then test it This would replicate the conditions it'd have to face once I install it in the dashboard.

[Renate]

Those boxes looks like they have no climatisation.

There is a circuit breaker for a heater.

[Dannyx]

Yes, that is the heater I was talking about, but it needs to kick in automatically once the temperature reaches a critical level for whatever's in there (Arduino for instance)...

EDIT:......which according to this discussion, is -40ish degrees C ! https://forum.arduino.cc/index.php?topic=3928.0

[Renate]

Which according to this discussion, is -40ish degrees C!

Err, you don't have to wait until it's that cold.
I hate to be low tech, but a normal bimetallic thermostat might be sufficient.

How disastrous would the loss of aeration be?
How often do the pumps die?
How often do the air jets clog?

For monitoring I think a pressure sensor tee'ed into the air line would tell you what you want.
No pressure = dead pump.
High pressure = clogged lines/jets.

For easy availability, consider using an automotive turbo manifold air pressure sensor.
There are many common ones that run on 5V and have a range of +/- 100kPa (+/- 1 atm, +/- 14.7 PSI).
You don't need the vacuum part of the range.

[Dannyx]

How disastrous would the loss of aeration be?
How often do the pumps die?
How often do the air jets clog?

By no means "disastrous" - some of these don't work to begin with and have been down for years on end now (which is where we come in to restore them when the project finally gets approved and commissioned).

Given that they run all the time, I'd say they die after 1 year in the best of cases, if not more often than that ! The bastards are surprisingly expensive to purchase new ! Crazy prices for what's essentially a large aquarium pump ! Thankfully, our marketing department, or whoever's in charge, managed to find us a website which carries diaphragms and other parts for them to at least cut down the costs of fixing them. Even these aren't cheap, hence why I think it was appropriate to also create a schedule for them, so the poor things wouldn't have to run all the time. Sure, this could very well be implemented with one of those plug-in timers, as a crude and quick solution, but there's a problem I spy: I don't know about others, but the particular timers I have around the house tend to run fast, so they drift around 5 minutes per month, requiring adjusting every now and then to make sure they're still accurate...not something you want to do in a semi-industrial environment. Sure, this could be made part of the monthly inspection we conduct on them anyway, but still...

OFF-TOPIC: Here's another photo of the actual tank where the air ends up, just so you get a better understanding of what these things actually are. Water comes in through the fitting on the far right and exists through the left where that metal shield is. Air comes from the pump, through the 4 valves and down to the bottom of the 4 compartments where the bubblers are. I have not seen these to know what they actually are. They could be proper components (diffusers ?), or they could just be something as simple as a piece of pipe with holes in it. The 4 chambers are connected at the base. As the water is agitated by the air, any remaining solids get separated from the water and they get caught in what resembles those egg trays in your fridge These are installed horizontally just below the water line. You can just about make out one of these very faintly in the top-right of the rightmost chamber. As more and more water enters the basin, the level eventually reaches the drain on the left where the "clean" water goes on its way into a sewage pipe or back into the canal directly, depending on the location of the station, and since the sediments are now at the bottom of the tank, the top of the body of water is "clean"...that's the idea.

[Renate]

Hmm, I think that I would have gone with a seated valve instead of those ball valves.
They might have been cheaper and easier to adjust/balance.

[Dannyx]

Yes, there are probably other things which could've been executed better (outside the automation part which is completely absent) but I guess the price point was also a factor. I'm no plumber, so I don't know the cost of "good" valves vs. cheapo ones, though I DO know seated ones are favoured and considered more high quality...

[Dannyx]

Someone mentioned using Python for the HMI side. THIS  ? > https://pypi.org/project/PyScada/

Also, EasyBuilderPro looks like a nice tool, though I haven't seen any prices mentioned anywhere, so I'm not sure what it costs...

[Dannyx]

Oh yeah, by the way, since we're still on the topic of protocols and stuff: is MQTT a protocol similar to MODBUS ? Ok, the question's pretty stupid on its own - I'm not an idiot, I'm aware they're NOT the same thing or compatible - but are they both protocols ? I always hear MQTT mentioned whenever talking about "smart" houses and automation and I was curious if it's a "language" that two devices talk to connect, since it helps clear out the confusion. It's got no place in an industrial environment, so that's beside the point - I wasn't planning to use it in our SCADA thingy here....