This should be possible. Your comment brought me to a solution, maybe you can confirm it:
PLC → (OPC UA) → Raspberry Pi (Subscribe to OPC UA data) → Arduino (LoRaWAN end-node) → Gateway → TTN
This way the preprocessing isn’t located on the LoRaWAN end-node and the Arduino only sends data, if lets say the status of the machine changes.
Data by exception is a good use case for LoRaWAN - rather than sending monitored data as a regular stream do local processing and send a regular status message/summary as needed with options for exception based alarming as and when needed…good for things like preventative maintenance or system down/failing/excusion alarming. As noted above consider what happens if message does not get through - 'cause Radio/RF 
- there no such thing as an SLA for open free space radio as you never know what a neighbour might do or where an interferer may come from and what it may generate…
“This project is supposed to be the topic for my bachelor thesis” - what other research have you done to look at the topology - hint, the Arduino as a LoRaWAN end node seems redundant if you look at what the Pi-Supply HAT does - but just asking us if it will help with “LoRa-handling” shows no real investigation. Ask yourself, what does this product do for a Raspberry Pi.
It occurs to me that a system whoes purpose is possibly to warn of machine failure\defect needs the PLC end node to operate with a secure\relaible send and acknowledge packet type system.
Thanks for all the input. Like @descartes mentioned, there is more research to do.
Summary
LoRaWAN should not be used,
There are ways to wire up a Raspberry Pi, to become a LoRaWAN node (e.g. Pi-Supply)
Frankly that doesn’t really sound like a LoRa radio application, LoRaWAN or otherwise. Ranges are short enough that a lot of other wireless technologies, or even wired ones, are probably better. And they’re going to offer you far fewer usage limitations.
If these were say, irrigation pumps scattered over a large area of farmland, that might be more a LoRa radio (and potentially LoRaWAN) application.
But not really mains powered stuff in a building.
For a serious industrial application of your requirements you may have a look into the SIMATIC IOT2050. It is an Linux based edge device and allows to attach Arduino Extension Shields (like LoRa Borads). At the Siemens IOT Forum Website I saw an Application note which describes how to setup the system.
I think there are more Pi3B running factories than what you realize, I have seen deployment of 40, they all been running for years and not a single failure.
Does it need to go to the cloud? You could collect PLC data on your rPi via OPC UA (I’ve done that easily with a PLC and rPi) and then send it to AWS/Azure/googlecloud
My other thpught is, you could use LoRa, not LoraWAN. Scatter a few LoRa nodes and a few LoRa receivers around your Hall. (But as was pointed out, this is a LoraWan forum, not LoRa.)
That’s an interesting idea. I’ve been eyeing the siemens iot2050 but haven’t tried one. It seems robust and I like the arduino shield feature.
It took a while but now I see “things” more clearly (The Things Network haha). Jokes aside, this is a post to wrap up the thread for other community members who find themselfs in the same position.
Hardware:
Setup:
Just put the HAT on the RPi, no more wiring is needed. There are a lot of repos on github to set up the RPi as LoRaWAN node, this was the most suitable for me GitHub - computenodes/dragino: LoRaWAN implementation in python.
If this GitHub repo goes down, you can also find a copy in one of my GitHub repos. If you set your node up, always be aware:
In terms of connecting it to a PLC: I’m not there yet but if there is interest, I will share it here.
Right now I use the additional GPS module on the HAT for a GPS-mapper (send location every minute via LoRaWAN). This could be interesting for people who want to contribute to TTN Coverage.
So it’s possible to use the RPi as a LoRaWAN-node in IIoT applications.
Is it as low-power as other nodes? - No.
Are other solutions “easier”? - Definitely, e.g. PLC → OPCUA → Ethernet has way less limitations. Nevertheless the use-case decides. And a lot of great replies with things to consider were made here.
Every minute, for a whole day ?
Best case (close to Gateway) that would be around 85 secs of air time per day.
Worst case (long distance from Gateway) that would be 1,804 secs of air time per day.
It’s not running 24h, just when needed (1-2h a day max) and with a low SF. The main objective is to place the gateway in the best position, where it covers the most needed spots on our plant.
Which doesn’t seem to be helped by uplinking its position once a minute unless you are positioning it by some radio prediction method on a very slippery surface such that it keeps moving …
I plug the RPi in and run around with it. If a package reaches the gateway, it will be forwarded and the GPS-data gets stored in a database. There is no other gateway near, so I can be sure it doesn’t get forwarded by another gateway.
How do you know?
The Things Stack Discovery. Private LNS for evaluating gateway positions, no other gateway interferes.
This does not stop any other gateway that is in the area hearing your transmissions and forwarding them to its Network Server for processing.
Hence the FUP and the laws relating to Duty Cycle.
Before you point us at the map, you may want to search the forum for the number of times people point us at the map and then we tell them that not everyone is on the map, certainly not other network providers.
For sure, every gateway is hearing every LoRaWAN message transmitted in range. But doesn`t a private LNS mean, that only the own gateways connected to the private LNS forward accepted packages?
Are these not the basic principles?
Public LNS → shared gateways
Private LNS → gateways are not shared
Don’t be worried, I won’t point at any map. But the location is so isolated, even cellular communication is barely possible (which does not mean anything, just for reference).
Nope, not at all, not even a little bit, because gateways do not have any autonomy beyond checking the CRC of the packet - if it passes, the it’s forwarded - it can’t decrypt so it doesn’t know. So if forwards to the NS. This means your frequent transmissions fill the airwaves and require all gateways that hear the uplinks for pass them on.
It actually means that the situation is worse than we thought - any LoRaWAN gateways in the area will be using a backhaul that is has a significant ongoing cost.
Isolated locations often make use of the Long Range radio system known as LoRa.
But as you have PLC devices, it can’t be that isolated. Or it’s a poor application of PLC devices where a more direct data acquisition / sensing scheme would be appropriate.