In my prototype i plan to have 5 simulated controllers (1 S7, 1 Emerson, etc, etc) but after a short discussion with a colleague he told me that we should prepare for up to 150 masters per topology. To be honest when i heard that i freaked out a bit but that’s life.
And after saying that, now comes the reason that i researched Elixir/Erlang/BEAM of its dynamic nature. Simply because my colleague explained to me that it is not sufficient to just statically apply a configuration and “talk” to the controllers, the even more difficult thing is to have a dynamic way of identifying, connecting and receiving data from a newly connected controller for example.
This seems as i suppose one of the selling points. In my case this will literally be the first important step to move forward.
To be honest i have never heard or used it. Would not that stress the machine in some ways? or affect the systems longevity? Sorry for asking something like that, i am ignorant on this subject.
Do you have to perform any heavy calculations on the data coming in or just, parse into JSON or whatever, store, put into message-queue?
What is the bandwidth of the connected nodes? Is 38400bps correct?
What is the worst case burst you have to expect?
OTP is made for that.
Having a GenServer for each connected client, makes it easy and robust.
Implementing that with threads or OS-processes gives you some more headaches.
The Heavy Calculations will be very few if any. In a general concept, i would need to parse the data, and then either persist or push to a local MQ (RabbitMQ/NATS/Verne/ still in research)
For that one i cannot really give an educated answer sadly.
Thats the first test that i will be conducting after i will have the app working as a prototype and my simulated PLCs running.
We have a similar application. While the servers in the field have very low load, we also have a central system in the cloud which has to handle all systems. To test the central system I have specs what the maximum load can be (need to know bandwidth, max burst rate, burst frequency). Then frames (in your case modbus-RTU-frames) are generated according to the specs, containing some random dummy data and a sequence number.
Expect: central system gets all frames (if needed: also in correct order).
Erlang is very good for this kind of stuff, will handle more than you think.
I don’t know that much about ZRAM. I’ve used it in some computers and I’ve read some companies using it in their servers to have more memory available for their server apps. If you use 50% for ZRAM, It basically uses half of your RAM for compressed memory swap. So it works like a in-memory compressed swap file. I think Chrome OS for example uses 50% ZRAM by default.
I have already found this during my research but ofc it is a commercial product so as a first part of this evaluation it is a no-go , on a later stage maybe my boss would evaluate this. By the way although never used EMQ Broker, I heard very nice feedback on its performance and ease of use (talking for the open source one)
Neuron and the modbus plugin are open source. The broker is open source also. If the main effort of your application is to aggregate modbus data from many nodes, it is all there already. All the extra processing you might have to do is easily done with the rule engine or just by an MQTT client.
Concerning message queues: If MQTT is enough for your demands, use it. Very easy, lightweight, robust.
Paid support from EMQX will greatly speed up development and should be very efficient.
I’d definitely write an inquiry to EMQX and see what they think how their product fits with your needs (while it seems like a good fit, I can’t judge)
Yes certainly the MQTT protocol seems a good fit from the data collection onward. I was not aware that these parts were also OS so that means I need to keep digging. Of course if the value return is great, it would be easier for me to discuss this with my boss and communicate with them.
