Websocket for real time high performant SCADA

Interface between Ignition and NJSCADA is a very simple Ignition module (called gatewaycomm) which has to be installed on Ignition server. On starting of the module, it reads a list of Tag paths from a predefined file from a predefined path on Ignition server, that NJSCADA needs from Ignition for displaying on ARSCADA and mSCADA clients served by the NJSCADA server (nodejs server former Apache server) and opens a TCP socket on a thread to communicate with NJSCADA server. So basically NJSCADA and Ignitions are two back to back servers communicating with each other on a TCP socket on request / response basis. The NJSCADA server (nodejs server) can reside on same physical machine as Ignition server (to save on hardware) or can reside on a separate physical machine depending upon choice. (its a trade off between Ignition server loading and network loading although overheads are very small depending upon size of the Tag Path list or number of Tags required by NJSCADA) . So basically the Tag Paths file is the Tag Data base for NJSCADA! It requests this data from gatewaycomm module periodically at a predefined cycle time (which can be configured in a NJSCADA configuration file) and refreshes it in memory. Clients log in to NJSCADA server on HTTP port 3000 (configurable) and select the ARSCADA pages or mSCADA page to be displayed. NJSCADA server refreshes all its logged in clients every predefined cycle with the latest tag data base values in a broadcast mode. Similarly commands from clients (i.e. buttons pressed) are sent to NJSCADA server which in turn send the name value pair string to gatewaycomm server which updates the Tag Value on Ignition server. So if the gatewaycomm module is replaced with a modbus driver to a PLC, or an OPC Server, then NJSCADA can become a standalone SCADA by itself ! (But that’s not our intent right now as it need a lot more effort like support , maintenance/upgrade/ testing/ reliability etc, we want to remain an add on to Ignition).

Another way to Interface NJSCADA with Ignition is thru an OPC UA Client in NJSCADA communicating with Ignition’s builtin OPC UA server. This way there is no need of installing a gatewaycomm module in Ignition. This way NJSCADA can even be interfaced with any SCADA supporting OPC UA. However this requires OPC UA server to expose its tags to third party clients.

1 Like

NJSCADA has never tried to do anything which Ignition already does! (ARSCADA/mSCADA/UNISEMS are the three modules it supports which compliment Ignition). The FTP discussion was initiated by Mr Alamsha, which honestly I have’t understood clearly or been convinced about. I was trying to understand and hoping to get convinced about it. If something cannot be achieved easily with Ignitions flexibility supported by it, then perhaps we are on wrong track in trying mold Ignition to achieve it thru Ignition.

In my opinion Ignitions biggest strength lies in its Scriptability on clients as well as server side to customize it to any SCADA requirements (of course within the definition and scope of SCADA) which no other SCADA vendor provides. That’s what makes Ignition a flexible product not a rigid finished product (take it or leave it approach).

1 Like

This is actually wrong. I can. There are various other SIs on here doing some amazing things with Ignition. No one ever said we are saying something is crash proof, but being able to extend on the core functionalities of Ignition through the provided scripting interfaces happens frequently. We can limit our risk by proper testing, using coding standards, and understanding the needs of our clients. Adding functionality through scripting, for the most part, is as reliable as any other piece of code in any other python project. Again, find a competent SI.

4 Likes

Awesome! I did not get that from going through the discussions, so that is nice to know, and I was really just pointing out that feature discussion. FTP libraries are baked into Ignition’s python and java resources, and we regularly interface with FTP sites, in a reliable manor. I am all for adding functionality to Ignition through the SDK (we have many modules), but it seemed like an on-going sales pitch every other day on the forum. (All good now)

Is there some things that Ignition can not do well (Mobile support, which regularly voice my disappointment for this module, as an example)? Absolutely. However, IA is working on rectifying those issues, as well as other short comings in 8.0 (afaik).

To me, Ignition is a platform for building applications. As always, if someone new to Ignition, or even an experienced veteran needs help with something going into production, I would recommend talking to some of the more technical firms, including, but not limited to, Kymera Systems, Automation Professionals (pturmel), Perfect Abstractions, etc.

Why FTP based data collection matters for IOT?

When it comes to data collection, FTP remains unbeatable. This is the heart of internet protocol and works reliably since 70’s. The key advantages of FTP are:

  1. Everything is recorded in a file. It remains as the primary proof of record from the origin and can be archived without any tampering or manipulation.

  2. I have automated some respectable petrochemical tank farm management projects. Even though they have smart meters transmitting the tank stock level to the CCC periodically, the management database relies only on the tamper proof FTP records transmitted directly from each tank since decades. They will never accept the data from the smart meters.

Hope that explains why FTP based data collection is mandatory when you deal with large scale IOT projects for the governments.

I would not have initiated this discussion had i found a solution within Ignition eco system which meets the requirements. I have even posted a separate topic on this but nothing solid came up. The only thing i found was instrument interface module which i did not find suitable to propose for a large scale IOT project. I have implemented something very powerful which is working perfectly since more than a decade.

My best suggestion is, IA must look seriously into this opportunity and build a rock solid JSON API and FTP based data collector for large scale IOT projects. Even they must implement FTP based S&F capability within Ignition Edge, to qualify for big IOT projects.

Found it interesting/ Looks like something similar to what you are doing with NJSCADA.

Its something using python scripting, I am doing it thru a module in Ignition written in JAVA.

I am not trying to come off as brash, but you are wrong. While FTP is an important protocol, it definitely is not an IOT protocol.

  1. FTP is probably the protocol the farthest from being a IOT protocol. Everything recorded to a “file” is just a false security. Anyone could tamper with your file, both in transit and at rest. MQTT/Pubnub/HTTP are all better protocols to use for this, as opposed to FTP.

  2. Cool, you automated a system that was based on FTP. That means that your client already had an existing software solution to run part of the business. That does not mean that every company does it this way, nor should they. FTP should only be used at the “last leg” in this solution.

FTP is possible in Ignition, and it is rather easy. It is by no means “required for large scale IOT projects”.

As for the discussion, it is something that many SIs can do. Like I said earlier, partnering with other competent SIs can help you achieve your project goals.

5 Likes

I am brainstorming some concepts and you are most welcome to share your ideas and opinion. cool… :slight_smile:

You are right. FTP is easy, ubiquitous, available in every RTU and a long haul data transfer workhorse. For example, you and i got our 300+ mb Ignition by FTP. Ofcourse, entire world does this way and it works perfectly every time. If any network failure happens, my torrent downloader retries and continues downloading from where it was left. This solution is available for uploading also, since decades.

Is this kind of robust file transfer possible with MQTT?. BTW, how many RTUs do you think have got MQTT?.

if your RTUs are capable of uploading/downloading files using FTP, then you can simply upload them to Ignition gateway server using PYTHON scripts on Ignition server directly!

Let me reproduce the CCC specs and please let me know, what’s possible and not possible with Ignition jython scripting.

  1. Collect IOT data from JSON API’s servers and csv files sent by thousands of RTUs by FTP. The FTP files are encrypted as per the latest internet standards and the data collector must run the file parsing decryptor supplied by the client and serve the data.

  2. Process it on the ML/AI engine server supplied by the client( this is supplied by IBM. May be Watson engine).

  3. Stream the processed data and alarms on JSON API (like online trading servers) for 1000’s of mobile and remote control centre consumers. The CCC server will be deployed on a private cloud at CCC connected to high speed streaming networks like PubNub and so on.

  4. Serve the data on “MODBUS TCP Master/Slave” for SCADA consumers like Ignition, WinCC OA and so on.

  5. Scalable, unlimited tags and clients capability. (Ignition is best qualified here)

  6. RTU’s are deployed on a private mobile network which charges by data transfer volume. To keep the monthly bills within the budget, RTUs are designed to report by exception and go offline like old fashioned PSTN lines. Whenever they connect to the MODBUS data server at CCC, all RTU tags are automatically updated and also a timestamped encrypted csv file is transferred by FTP. So, the data collecting server or SCADA stations won’t be able to periodically scan the remote RTUs to validate the tags.

  7. SCADA stations can scan the front end “MODBUS TCP Master/Slave” data server at CCC as usual to avoid tag fault errors and disruption of services. In fact, the front end server simulates the remote RTUs.

  8. Retain and serve the last value of all tags to SCADA consumers upon reboot or network failure etc.The data servers shall be fault tolerant and shall continue to serve the data seamlessly on the same IP to data consumers, in case of any changeover or maintenance

  9. The SCADA database will have 2 timestamps, from the origin and destination. SCADA station must display and serve all alarms and history with both timestamps.

Kindly keep in mind, the data collection and processing load is very high on the JSON API and FTP file parsing servers. There are some high volume data server agents contracted by the client. Most of the JSON payloads served by tham are deeply nested from health services, financial services and so on. The objective of this project is to correlate all the information with the help of ML/AI algorithms and provide specialized services for 1000’s of consumers. Clients pay big amount for this service and they demand high quality service.

Needless to mention that multiple servers will be working in tandem on cloud to collect, process and serve the IOT data. Please feel free to ask me, if you don’t understand any part of this spec.

  1. Which one is better?.
  2. If the client is willing to pay for better performance, which communication option with Ignition server would you recommend?.

Can you please throw some light on this.

Performance wise java module should be faster as it’s I compiled code than python but I haven’t tried python approach , may be it’s easier to develop , perhaps some other si may comment on it.

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.