I don't know which idea you are talking about, if it is usage of NodeJS, indeed I am a fan of NodeJS for its simplicity. However, while we are going ga ga over nodeJS, there is nothing magical about it as projected in the video. In fact NodeJS is pretty dumb compared to other web technologies. It simply reduces its work to just responding to each request whichever connection it comes from using websockets and be ready for processing next request. The onus of processing the request without blocking it, is shifted to the developer to quickly respond to it or to delegate it to an asynchronous call and return to OS, or else the whole system will hang or crash! Of course there are instances when you just cant afford to use asynchronous calls such as when reading a file to initialize paramaters or read on a tcp socket, then you have to use a blocking call or an async block judiciously. So its more of a challenge for the developer to visualize what's going on in your system. But that's an interesting exercise to design a system based on NodeJS. Life is tough in NodeJS but rewards are high!
The ability of handling millions of users in NodejS is irrelevant for SCADA application, as number of users will be few hundred at max! Though unlimited clients is a USP for all web based SCADA's like Ignition, compared to client/server based traditional SCADAs.
I didn't understand your suggestion on usage of block-chain ! It looks too far fetched!
as mentioned in my website, the eval version is available only on request basis. However I am going to make a download link available on my website for gatewaycomm and NJSCADA, by end of June.
yes its written in Java as an Ignition module. When installed on Ignition, it just reads tagpaths file from a predefined location and waits on a TCP socket for NJSCADA to connect to it. When NJSCADA is installed and started , it does a handshake with gatewaycomm and they start communicating with each other like sending values of tags listed in tagpaths file from Ignition to NJSCADA periodically and writing commands received from NJSCADA clients (like button pressed etc) to Ignition data base. So gatewaycomm is not a standalone program , its just a gateway between all modules of NJSCADA (like ARSCADA, mSCADA, UNISEMS).
(though its an old video of Tomcat version of ARSCADA, and gatewaycomm was called AR-signed module. The Tomcat is replaced with NodeJS server in the latest version).
1.Gatewaycomm is very specific to Ignition it uses its SDK to read write tags to Ignition memory tags. Any JSON payload handling has to be done by NJSCADA on one of its clients. You need gatewaycomm module if you have to talk to Ignition.
2. MQTT is third party I cannot integrate it with them it will open a new pandora's box for me.
3. As said earlier, gatewaycomm is required only for communication between Ignition and NJSCADA using its own propitiatory protocol , cannot be made available for third party modules.
ok. May be you have to write a dedicated "MQTTgatewaycomm"in future. [quote="PRAMANJ, post:91, topic:18194"]
Any JSON payload handling has to be done by NJSCADA on one of its clients. You need gatewaycomm module if you have to talk to Ignition.
[/quote]
This answer is not clear. My question is, can gatewaycomm work as a JSON payload server and consumer seamlessly?.
MQTT has its own module for communicating with Ignition, why should I have one more? If anyone wants to use MQTT with Ignition they will use their module, why will anyone need my gatewacomm? I use PubNub for IoT instead of MQTT , then what is the need for me to develop such a module for MQTT.
The server and consumer is built in my NJSCADA server module, which can receive JSON and send JSON. The ARSCADA, mSCADA, UNISEMS are like modules to NJSCADA server which can be removed from it, if only JSON payload server is required. gateway comm module acts as a pipe between JSON payload server and Ignition. (You can think of them as one module if you wish!).
The NJSCADA server will talk to gatewaycomm module on one side,( without ARSCADA and mSCADA) , and to a client delivering and receiving JSON payloads on the other end.
In fact it can communicate with many clients to send / receive JSON packets connecting to many different sources, if required.
It works in standalone mode where 10 tags are simulated from 0 to 100, for demo purposes. So still there is a possibility of reverse engineering, but I have obfuscated my JS code.
It was originally designed to provide Virtual tour interface to Ignition as an add on module ARSCADA. The mSCADA was built later as optional module with limited SCADA features using SVG, but can be extended with REACT or VUE, but Ignition is the IMPALA for SCADA as you said.
Since Ignition Perspective is on React, i suggest, you offer your UI on VUE/Angular. Cut a deal with Kendo UI. and showcase awesome apps. You can make some money
After ARSCADA, a remote dash board module RMSCADA was built using PubNub which were the missing features in Ignition. Later I mSCADA was built to add HTML5 and SVG based graphics (Ignitionâs UI is build on JAVA swing library). My mission is to leverage latest developments in technology in Industrial Automation domain.
