Websocket (ws://) is becoming a preferred protocol than http:// for high speed real time applications like stock market trading, online gaming etc. I think, SCADA manufacturers who adopt this technology will have a strong advantage in IOT data collection, ML and smart infrastructure SCADA projects.
1 Like
NJ SCADA is built upon socket.io which uses websockets internally. Even IGNITION uses websocket for communicating between Ignition servers.Its definitely better choice for real time applications like SCADA/IOT/Chat etc. Its light weight (smaller packet headers than HTTP) and supports push technology.
I am doing some experiment. I would like to serve all latest alarm and tag values from Ignition as JSON. How can i do that?.
Ignition already uses websockets…
3 Likes
I did some digging and found these resources.
https://docs.inductiveautomation.com/display/DOC79/Gateway+Network
Logger filters:
metro.Transports.Websocket
metro.Transports.Websocket.WSFactory
.........................
I am very happy that Ignition is truly built on strong internet foundations.
I would like to know, if Ignition is using websocket data streaming between the client and the server, like they do in online trading platforms. BTW, does NJSCADA do webstreming for the clients?.
......................
Of course they are built on technologies that make up the internet. Is making http calls not a strong internet foundation? You need to realize that websockets were not standardized until after Ignition 7 came out.
I think, the upcoming Reactjs perspective vision module is going to be a game changer. I think, they will use websocket data streaming.
Indeed HTTP is based on strong Internet foundation. However HTTP was based on request/response architecture which was OK for web based IT applications wherein server responds to client requests, it cannot send packets on its own to clients. Where as real time applications like SCADA are more of server sending data periodically to all clients. The web socket model is more suitable for this. Admittedly the websocket protocol came in existence later than when Ignition came. websocket is being used in Ignition as an after thought only for server to server communication not client to server communication. Socket.IO allows client/server communication also on web-sockets. Ignitions's client server is not based on web sockets, its based on HTTP. which is a pull technology, NJ SCADA is 100% based on socket.io which is a push technology.
regards
PEAMANJ Technologies
To the best of my knowledge Ignition is not using websockets for client/server communication, its using HTTP protocol, let alone streaming mode of data transfer! NJSCADA uses socket.io to send packets to all clients,it doesn't do streaming, its periodic publishing of the data to all clients every 1 seconds.
I fully understand the difference between HTTP calls and web sockets. As for the server to server communications using web sockets, that is because that part of the system did not have to be backwards compatible, because it was a new feature. We can understand why they didn’t change the way the client works in Ignition 7.x, but one could guess that web sockets will be the basis for client communications in 8.0.
1 Like
Ignition is using HTTP calls for client/server communications, not web sockets.
Does it use JSON payload for client server communication?.
No JSON has an over head for tag value pair every cycle. JSON makes sense for one time data fetch like in IT applications wherein you fetch different data packets on each query. Where as in SCADA we are sending same packet values every cycle , so it doesn't make sense to send name value pairs every cycle, just values in a fixed sequence is enough, unless you change the screen (or packet). NJ SCADA also uses broad cast to send data to all clients at the same time (push) this minimizes over heads on network. HTTP works on request / response mode which is per client based.
Its very easy to publish packets as JSON in NJ SCADA though!
The idea is to propose a JSON SCADA which can do the following:
- Collect IOT data from JSON API's and csv files sent by thousands of RTUs by FTP.
- Process it.
- Stream the processed data and alarms as JSON API (like online trading servers) for other consumers. This server will be deployed on a private cloud at CCC connected to high speed streaming netwrorks like PubNub.
- Serve the data on "MODBUS TCP Master/Slave" for SCADA consumers like Ignition.
- Any tag, client limits?.
- Retain the last value upon reboot or network failure etc
Is it possible?.
I mean, we could make a list of items that both SCADA packages do and do not support at this time, but I do not think that is good use of time. There is probably a reason Ignition is a fast growing SCADA platform and a reason why no one has heard of NJ SCADA before.
I see NJ SCADA as an excellent partner product for Ignition. It fills the missing link in Ignition and SCADA products in general. It's NOT possible for any solution provider to innovate and fulfil every wish list. This is the reason, IA provides an SDK and encourages Module developers.
I have been searching for a solution since long time which can meet the above specs. Honestly, Mr.PramanJ is the only person who had patiently answered all my questions and has given me enough confidence to propose a solution which exceeds my client's expectation.
Good SI's are the one who open up the regional market for a product. I can say that "Igniton + NJSCADA" is a lethal combo for IOT CCC.
Amazing demo on UI performance benchmarking by Reactjs creator, Dan Abramov. FB manages more than 50 million messages and posts every day, at lightning speed by tapping the power of websockets. SCADA clients can benefit a lot from Reactjs framework. IA has taken the right decision to build a Reacttjs based vision module.
Other than the current mobile client, I have not seen anything that NJ SCADA can do that Ignition can’t, mainly because the software doesn’t seem to have an installer or is downloadable from the vendor’s website. I have not seen anything that NJ SCADA can do that isn’t possible with Ignition, or in the development pipeline for Ignition. What missing link does NJ SCADA provide?
I usually stay out of these types of conversation, but I feel most of these discussions normally offer little value to the community, while eventually turning into a sales effort for NJ SCADA. Just my take on it anyways.
4 Likes
I consider NJ SCADA not as a packaged product but as a very powerful tool for Ignition. We have to keep in mind that NJ SCADA is an Ignition SI in the first place. He first sells Ignition and then tries to sell his product as a value addition. He is highly respected by the automation community in India and a very good brand ambassador for Ignition.
Successful companies have always encouraged and built a powerful eco system to flourish around their product. Software is a cut throat business. No one can claim that his product is unbeatable. Many a wonderful solutions have disappeared overnight because someone else came up with something else better.