Yes exactly. In fact NJSCADA can be called a mini SCADA server. It collects data from Ignition thru GCM rather than from PLC with a driver. Eventually it will also have an OPC UA server in it.
Don't know if its a missing link, but yes its based on new technology of NodeJS which is a paradigm shift in server technology from threaded to un-threaded which is a new trend in IT industry today. You get best of both worlds with the combination i guess.
The GCM handles one TCP connection on one thread at the moment but can be easily extended to handle multiple threads serving multiple instances of NJSCADA. I hope multiple instances of NodeJs can be run on the same machine on different ports, I need to try that. If not then I am trying to change from TCP to websocket connection between GCM and NJSCADA so that we can install NJSCADA anywhere on network. TCP is not reliable for large packet size. Alternately it can be based on your idea of FTP between GCM and NJSCADA servers!
Biggest difference is its size (<100kb rether than few hundred MB!) of course NodeJs it self is about 15 MB! Also we have the advantage of nosql data bases like mongo db and alike which are much easier and smaller than SQL.
why not, it can be installed anywhere where NodeJS can be installed !
I am actually stuck with session management in NJSCADA for multiple clients, being combination of ExpressJS and socket.io its become mind boggling! I hope I can come out with a robust solution to this problem. NodeJS being unthreaded is suitable for single page applications. This is delaying and holding back the release of NJSCADA Beta version!
You can think about deploying an online demo of NJSCADA on RPi at your website. It will be very attractive for hobbyists and University students. I feel that, NJSCADA as a light weight front end server on Raspberry Pi for Ignition will become the holy grail for your product.
I would suggest MQTT-JSON payload between GCM and NJSCADA. For some reason, i can see that you are bit allergic to MQTT. You need to rethink about it. I have carried out some big MQTT-JSON payload tests along with Mongo DB and can say that it's light years ahead of FTP in terms of performance, web standards and consumption by end user apps and small foot print devices like RPI, Android etc. I will go for FTP when MQTT is absolutely not possible like in traditional Modbus RTUs.
I suggest as an alternative. try MQTT-JSON PubSub form Ignition GW. It's very easy for you because you have the tags and alarms ready to PubSub. Theoretically, unlimited nr of clients can PubSub from either side on different topics on the same port. I have all the building blocks to do it from Ignition server. I can share the details with you to speed up your work. To understand what i mean, check out this post.
FYI, the index.html file is using "mqttws31.js" library.
I am going to make the whole NJSCADA/ARSCADA/RMSCADA (PUBNUB) & the GCM.modl with obfuscated code and a sample project available on GitHub for every one to download and try.
My understanding of MQTT is that it needs a broker in between the source and sink. Its not simple as TCP or WEBSOCKET or FTP for that matter between two points. Just understanding and publishing packets in MQTT formats is not enough. How can I write MQTT-JSON packet in GCM without knowing the format! MQTT is not an open protocol like the other three mentioned above. Its a propitiatory protocol.
My current problem is that of communication between NJSCADA server and its clients (The ARSCADA /Alarms/ States) over LAN. Communication between Ignition GW and NJSCADA is not the problem mentioned here, You have suggested a different solution here.
However In my opinion, MQTT is similar to PubNub except that PubNub is in public cloud, and MQTT broker is in private which might make MQTT more efficient than PubNub due to special representation of compressed data and being a dedicated broker server . But look at PubNub's advantage that its readily available, you can just get started now, and packets are in simple stringified JSON objects format! Of course the response may not be deterministic for every message but still you have the guarantee of maximum 250 mili seconds of latency. MQTT is not an open standard. Your above diagram can be represented with PubNub as well.