The reason modules were developed by PRAMANJ Technologies for Ignition was to fill the following gaps in Ignition leveraging the latest developments in technologies using the SDK released by Ignition in 2014 and the marketplace created by Ignition inviting module developers like me to add new features and functionalities to Ignition based on their experience and ideas they may have!:
ARSCADA module to add a augmented reality interface to Ignition for existing as well as new customers of Ignition.
mSCADA (formerly RMSCADA) for remote interface to Ignition over Internet using PubNub.
UNISEMS - simulation models interface to Ignition based on proven Simulation technology used in Power Plant Simulators.
Initially these modules used Apache Tomcat server but subsequently they were merged merged in single package called NJ SCADA and Apache was replaced with Node.JS server as it was the latest technology and has better features for real time applications. NJ SCADA just augments the Ignition SCADA package adding new functionality using latest technologies like AR, HTML5/SVG, NodeJs etc.
I have been just trying to reply all the posts and questions of Mr Alamsha. It seems to address his querries arising out of latest developments in technology like socket.io, react.js etc. although I haven't yet understood his requirements clearly.
NJSCADA works in a different way than traditional HTML approach and the comparisons between Ignition and NJSCADA were only to the extent of these differences between the working of the two packages not to say which is right or wrong. Ignition is indeed the fastest growing SCADA package. Its due to their open discussion forum and SDK and market showcase that we are able to discuss our ideas, it by no means is a marketing mechanism.
we wiil definitely provide a download and evaluation version of NJSCADA. However its not an established package like Ignition , it will take some time to come to that stage. Initially it needs hand holding to try on exiting Ignition projects. We are just trying to leverage Ignition's success.
I think my biggest issue is the fact that there has never been any video or example of NJ SCADA working in unison with Ignition. I would love to see this, and maybe understand how NJ SCADA actually interfaces with Ignition. I have seen the configuration window on YouTube, but the configuration seems tedious and slow at best. Some of the other topics, such as the FTP discussion, can be handled by Ignition very easily, without a third party software stack being thrown in the mix. No offense, but I would not want to see someone use something like NJ SCADA for something Ignition can already do.
I am not trying to kill the discussion, I just want there to be more meaningful information being provided to the community.
Ignition is in a different league. It's not possible to bend and twist Ignition by the end user. If we do so, it will trigger instability and crash the system. If you go through the FTP discussion patiently, you will realize this.
I have done enough research with the instrument interface module for FTP data collection which is a third party driver and it doesn't meet my requirement, especially dual timestamp part . I have my own third party proven solution to do this job outside Ignition. IA does not support any third party solutions including MQTT engine which is the heart of Ignition Edge. The reason is, system stability.
Try to meet my specs above + ML engine integration within Ignition. Any sensible SI will never mess around with Ignition to do this kind of job and IA will NOT take any responsibility to support this kind of innovation within their framework.
BTW, if IA can roll out all the solutions and Ignition can do all the the job, why do they need SI's?. Let the producer become the consumer.
Ignition 100% can reliably pull information from FTP server, without any third party modules. It is totally possible for a competent integrator to bend and twist Ignition to do things that are not built inside the box, without introducing instability. Inductive does support MQTT through their partner Cirrus Link, Ignition and MQTT is the basis for most systems we are developing now. There is no issue with stability.
It sounds to me like you need to find a competent integrator to help you with your projects, as most of the things you have posted to the forum are either in the development pipeline for IA, available from other module developers, or are just features a competent SI could build as part of a solution.
If the system crashes. IA will declare it as violation of EULA.
You can visit the above link and see that "Cirrus Link Solutions MQTT Modules for Ignition" is clearly categorised under third party modules. Please read the EULA agreement for third party modules.
Any support request for MQTT engine will be silently forwarded by IA support to cirrus link support. In fact, Ignition Edge is a software which is meant for embedded system manufacturers. A normal SI will not take the risk of bundling it in his own hardware and deploying it in the field. He would prefer to buy an IE embedded product which meets his requirement. When that happens, the legal burden of IE support will rest on the shoulders of OEM.
No SI in this world can claim that he knows how to bend and twist a product to put his stuff inside without risking instability. Even the manufacturer can NOT guarantee that his product is crash proof. Every system has limits and boundary conditions. We are ordinary humans and we can NOT predict every possible source of failure for the machines we build. Above all, there's something called "Will of God". This is integral part of US legal system.
We usually customise Ignition a lot. With tons of custom scripts. However, most instabilities we experience usually come from the surrounding system:
Windows installing updates and rebooting without possibility to stop it
The OS running out of disk space
Network configuration being changed without prior notice
...
We've only noticed instabilities during startup with our custom code, and even then, it's limited to what we can't simulate in the office. Any other instabilities usually comes from neglected or bad PC and network maintenance.
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.
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).
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.
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.
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:
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.
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.
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.
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.
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.
I am brainstorming some concepts and you are most welcome to share your ideas and opinion. cool..
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.
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.
Process it on the ML/AI engine server supplied by the client( this is supplied by IBM. May be Watson engine).
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.
Serve the data on "MODBUS TCP Master/Slave" for SCADA consumers like Ignition, WinCC OA and so on.
Scalable, unlimited tags and clients capability. (Ignition is best qualified here)
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.
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.
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
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.
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.
. I have my own third party proven solution to do this job outside Ignition. IA does not support any third party solutions including MQTT engine which is the heart of Ignition Edge. The reason is, system stability.