Python code also is using the same websocket approach like you do, i think. Is that correct?.
I was also once very much excited about MQTT. When i insisted our RTU vendor for MQTT embedded RTUs, this is what he replied:
"We implemented MQTT in our RTUs and carried out field study for more than a year. We studied thousands of transactions and found MODBUS TCP and FTP were miles ahead and 100% outperformed MQTT hands down on every transaction. We have decided NOT to pursue MQTT any more for our RTU business. MQTT is definitely light weight and may be suitable for home automation business, smart sensors and embedded devices like thermostats, temperature sensors and so on. If you want MQTT RTUs, please find some other supplier. We are NOT interested. Thanks".
I have not seen FTP in any RTU that I have used in production. So maybe this is an Asia thing. What link are you using to download Ignition from? I have never seen an FTP link for an Ignition binary, IA's website uses HTTP for file transfer. Also, you mention torrents. Well, the BitTorrent protocol is not FTP, and I have never seen BitTorrent on an RTU either.
As for file transfer over MQTT, yes, it is possible and reliable. We have transferred video, images, VPN configuration files, SSL certificates, and even firmware upgrades over MQTT.
Yes, this is possible with Ignition, the built in FTP libraries, and python.
Yes, Ignition can more this information into Watson
Yes, MQTT, PubNub, HTTP REST, can all move data and provide endpoints to be consumed by other applications.
Ignition can talk Modbus as a master natively already, and implementing a slave would be relatively easy as well.
Yes, Ignition is good at this, and they are getting better with every release.
Having Ignition act as an FTP client to the RTUs is possible, but based on the report by expection statement, it seems like you want the RTU to be a client to an FTP server. Either way, Ignition can do this, either as a client, or by watching an local directory on the server exposed as an FTP target. Ignition already supports Modbus as a master, and a slave can be built as required.
Same as my other Modbus comments. This is possible.
Ignition retains values of tags already, but some sort of persistence layer could be used, a SQL server, a NoSQL database, etc.
Yep, all comes down to database design. This is possible.
Define a high processing load. The JSON API would probably be a set of REST endpoints, and FTP, well that is just an FTP server with Ignition watching the folders, and processing on change. As stated previously, MQTT, PubNub, TCP/UDP streams, web sockets, all are possible with Ignition.
Who is your RTU vendor? I have been building SCADA systems for 15 years, and MQTT is the biggest jump from an architecture standpoint in my career. Every system I have ever built would be magnitudes better using MQTT as opposed to Modbus or whatever other protocol we were using. I disagree with your vendor, and based on how many vendors there are adding MQTT to their products. I suspect that either your RTU vendor doesn’t know what they are doing, or they have alternative motives for not supporting MQTT. Their analysis of the protocol is just wrong. I am not saying remove Modbus/FTP, but I can not see how they came up with that conclusion.
As an example, their has been a company using MQTT for over 20 years, in the Oil and Gas industry. I could be wrong, but they have 20,000 miles of pipeline, and the MQTT infrastructure has had 99.999% reliability over that time frame. I can assure you it is not just suitable for home automation and smart sensors. This installation has been pulling from (1,000s,10,000s, I can not remember the number, but a lot) of PLCs and RTUs for that period, and rather successfully.
To sum this part of our conversation up, MQTT was built for industrial use, and there is a lot of successful use cases of MQTT in industry.
5 Likes
This is one point where Ignition beats every SCADA vendor hands down. I have strongly recommended Ignition for this and hope it goes well.
I agree with you. I think, IA can build a custom Ignition data server which simulates a big software Modbus Master/Slave RTU on Linux + retain last tag values + serve Alarms and Tag data as JSON Payload to IT servers + serve web pages to Ignition clients. Other things IT will take care.
I have proposed a pilot project to start with and build upon it gradually. Let's see how it goes. Thanks for the wonderful discussion.
You love to use MQTT for file transfer and i love to use FTP. I will never use MQTT for file transfer.
I am happy with Modbus + FTP RTU. I don't want MQTT RTU.
For home automation projects, i 100% support MQTT. But for data collection, i will use only FTP. Again HA is not my core domain and i can't discuss much on this.
For me as well the ftp bit instead of mqtt or pubnub was confusing ! If you are confident that your RTUs can communicate with a central computer using ftp then it’s not difficult to interface it to ignition server using jython scripts on server or nodejs using JavaScript. I am a fan of JavaScript and modejs. As files are received from RTUs over ftp they can trigger an event on modejs to update ignition tag values in memory. Nodejs is required as JavaScript cannot do file iio , where as it’s excellent in communication. We will not need the other modules of arscada and m scada , they will be optional
As I had mentioned and you also suggested it’s better to pilot it on a simple test case. Both approaches of jython and modejs can be tried. I can do the modejs approach faster and someone else can do the jython approach faster. At least we will understand each others requirements and approaches better.
In reply to you question "python scripts also use wesocket?’ I guess python scripts on server will update ignition tag values using its appropriate communication library, (you can refer to it’s documentation) to update tags values once ftp files are received . There is no wesocket involved here. Njscada also uses socket.io only for communicating with its arscada or mscara clients. If we are not using these modules of njscada then you are using njscada as nodejs server for file io as JavaScript cannot do disk read write.
You can use ignitions unlimited clients for CCC and mobile clients that it supports.
Please go through my specs once again patiently and it's final. My reply above to Kyle_Chase is what i wanted from Ignition and i hope IA can do it.
Your JS/Python coding skills and deep knowledge on Ignition engineering will be a very good asset for any Ignition project. I have already decided to engage you, if everything goes well.
http://forum.inductiveautomation.com/t/mqtt-issues-in-ignition/16789/8
Please post your views there. Thanks.
Only missing link for the jigsaw puzzle is the FTP RTUs. Pubnub also provides interface with Watson and offers capability of unlimited storage of messages sent or received thru it on it’s servers in cloud for persistence. But we are not yet decided if pubnub or mqtt are required at all if ftp is going the job!
I will be glad to do a pilot with you on experimental basis.
But of course njscada can talk to your RTUs as well on socket.io (web sockets) in addition to mscada and arscada clients (if any!). However On RTUs you have to send packets as stringified JSON files rather than ftp. We have see if nodejs supports FTP client and server npm then it can directly send receive ftp files directly to you RTUs.
Don't worry. That's my baby 
I would like to call the front end data server as Commander My first preference for Commander is customized Ignition. If IA can't do that, i will look into your offer.
Nevertheless, your njscada experience elevates you as one of the best Ignition experts. My opinion is, you can make more money with Ignition than njscada. Ignition is like Rolls Royce. Whereas njscada is not even a product in the first place. It's a very good showcase of your coding skills. Can you submit an evaluation copy and compliance statement of njscada to the consultant?. Without this, it will never ever prequalify as a SCADA product anywhere in the world.
I think, you can repackage your njscada for home automation on Ignition Edge platform. If you like. we can discuss at the MQTT thread posted above. i think, you will get very good support from IA too.
Njscada is targeted as an add on to ignition. The front end ftp server can be built in njserver or a third party open source Linux based server that you have used in your project itself! From there data can be pumped in and and out of ignition using jython scripts or njscada.
Another advantage of njscada will be additional interface of arscada and mscada clients if customer prefers.
Regarding your home automation market for njscada it’s possible to integrate with ignition edge thru OPC server. Alternatively it can integrate directly with RTU s on SNMP or ftp protocols without the edge .
How will you collect data from HA devices to the OPC server?.
Sorry for my late and brief responses I am enjoying holidays in Europe till mid June. HA devices I guess communicate over zigbee,modbus, backnet ,modems and rtus We need drivers for these in opc ua server in ignition edge or njscada
No. All those projects have failed and trashed. I have updated my post above. Pls check it.