i think for this case using Timescale Cloud + UMH ...
# umh-support
j
i think for this case using Timescale Cloud + UMH could be the way to go. Timescale Cloud for storing the data, then UMH to get the Historian functionalities like Grafana etc.. Probably community edition would be fine for you. With UMH it would be like this: 1. Use Hetzner to get a cheap bare-metal VM (you can also use AWS or Azure, but they are like 10x more expensive) 2. Install the community edition of UMH onto it and use the inbuilt TimescaleDB (will do it by default) 3. Point the machines to send the data via MQTT to the HiveMQ instance running in the UMH on Hetzner. If the machines only provide an OPC UA server the setup will get more complex as you would need a protocol converter from OPC UA to MQTT / Kafka on the edge at every machine. You can simply leverage the UMH for this as well. As you are the machine builder, I would strongly suggest to send the data out via MQTT. 4. Once you get it working and can confirm the business value, you could outsource the TimescaleDB part to TimescaleDB Cloud (depending on your needs) 5. if you need enterprise support and guidance on the way, feel free to contact us (www.umh.app)
d
I've made (and tested) an architecture for the historian problem i was talking about last week. I will make a drawing; I'm open for feedback! 😄
j
that is one way to do it, and actually quite similar to what one of our customers is doing. also with node-red in the edge devices. over time, there are some scalability issues with using in the current setup at the edge, especially when monitoring everything. if @Mateusz has time, he can maybe explain a little bit better what they are currently facing at a customer
If I remember correctly they struggle with the reliability of the OPC UA servers of the machines, and they would like to use the Management Console to monitor it better. but for this they would then need to use UMH on the edge as well.
d
Thanks! 🙂 What do you think about the ingress side? We can also publish to Kafka, would that give an advantages in your opinion?
How would you approach the edge side to avoid using node-red (avoiding scaling issues)? (Telegraf?)
j
to be honest: i think if you already have everything for nodered (hardware, etc.) then you should start with it. It is important to first show also others the value of the system before optimizing it. Then at some point you could install the UMH on a edge device, and use the management console to extract data (and monitor data sources). it is differently if you need to buy the siemens open controller beforehand, then we should talk again
otherwise it looks good to get started with a couple factories / machines
d
Machine side hardware is there and completely working, we have node-red there already for a few other usecases (interacting with other equipment in the factory and alerting) so that's done
j
yeah, so go with it and start creating value for your customers and users 🙂 everything else we can do then as a second step
m
Our customer is using edge devices with NodeRed for custom applications, extraction and as an additional security layer (usefulness debatable). Only troublemaker is the need to manually restart the OPC-UA flow to connect to the OPC-UA server whenever it restarts. Not a big thing, but once you increase the number of devices you will run into tons of overhead. We handle this edge case over Benthos which solves connections issues automatically. With only two machines and this architecture you will be completely fine for now. Good luck with the project. Keep us posted!
d
I'm planning to scale to 50 machines worldwide within 2 years. (my costumer is an OEM so we're always talking X machines, not full plants) We're testing a few solutions in parallel atm. I'm currently quite happy with UMH.
i also have a node-red OPC => MQTT link. I have not yet noticed i have to restart the flow manually? Whenever Node-red is running, the OPC flow is running and the server directly connects. I've looked into benthos on the edge but didn't see any real advantages for my usecase. I like the simplicity and flexibility of node-red. But indeed we will run into scalability issues later on.
m
My specific example is due to the implementation of the OPC-UA server by the OEM. These can vary in quality quite a lot. If yours are stable, you will be fine for now. If you consider moving to Benthos later on, this will be a rather quick change as the management console guides you quickly through the process.
d
ahhh ok, yea. Jeremy mentioned this as well yesterday. I did not know there was such variation on OPC servers. (i almost always work with the OPC servers of Siemens S7-1500 plcs)
4 Views