An important difference between Ignition and other SCADAs is that it is the only SCADA which is JAVA based (AFAIK) ! All others are Windows based. IMO this is big plus from security point of view. I remember, about a decade+ ago, most of the WinCC installations had a serious virus attack ! (I guess JAVA systems also had Log4j issue recently!).
Another advantage being JAVA based IMO is its JYTHON scripting capability which allows building/extending SCADA’s server and client functionality without having to build the system. (I guess .NET allows C# scripting!)
Only negative aspect could perhaps be the server response time slower and non deterministic being byte code execution by JRE. (But I guess so is .NET based systems!).
Serious vulnerabilities are found in libraries and products across the entire spectrum of languages/frameworks/ecosystems available. Everything from internet backbone fundamentals like the Linux Kernel, OpenSSL having one RCE after another, a constant stream of Windows security releases, to higher level frameworks like .NET or libraries like Log4J.
Nobody is in a superior position and talking crap about another technology for its security track record is definitely throwing stones in a very fragile glass house.
Hmm, this is something we are concerned about for sure, though it seems like most of what we use scripting for now (mainly mulitmonitor navigation and some custom control pop-ups) is just built in to the application so wouldn't need scripting. Though I'm sure there will end up being something that does need it.
My point was pros and cons of any other JAVA v/s non JAVA based application should also be considered while selecting between Ignition and VTScada or any other non JAVA based SCADA as well.
I just saw today that there is an attack that has popped up that has targeted OPC UA Servers (in part). In reading through it, it seems to come down to not using default credentials
That kind of stuff is built in to it. Its the custom animation stuff and other cute stuff people do with scripting that can get you into trouble. Its hard to parse string data with scripting and the scripting interface is not friendly. Some scripting may also require application restarts (custom reports and things like that). I’ve done a couple of Wonderware to VTScada conversions and they were not fun to try to do 1:1 conversions because of the scripting stuff there were doing in Wonderware.
Don’t get me wrong its a solid SCADA platform that comes working well out of the box with very little changes to be made for basic setups. If recommend a scada platform for a small facility and they aren’t willing to look at Ignition VTScada is my backup 99% of the time.
So it sounds like VTScada kind of puts you in a box, meaning if what you need is there then it’s great, but if you need to do something special then it could be a nightmare. Also sounds a bit like FactoryTalk.
Sometimes too much flexibility in a package can lead to subjectivity in design, involve steep learning curve in proper usage, introduce bugs in system, necessitate rigorous testing ,which could lead to system crashes , memory leaks etc, whereas system design using built-in features and functionality and using the package only as its envisioned and designed and intended for using built-in features by the development team, results in a more robust system, gives less chance of creating mess in the system. Sometimes working with limited options is easier to work with like RISC architecture v/s CISC architecture as an example. You may have to work more but learn/choose/decide less like paint v/s some other animation tool!
Its fine to do R&D but risky on live projects with stringent dead lines and quality requirements where a time tested and proven and one generation older technology solution is preferred.
I worked with all these three products (GE’s iFIX+Historian, VTScada, Igntion) and built a few projects in each of them. I don’t pretend to be a guru. Just want to add that there is no perfect thing in this world which helps you in absolutely everything you do. I would only mention the negative aspects. From what I feel I can outline the following:
GE. The big downside - the products cost. If you want to use A&E Historian - be ready also pay for to MS SQL license, as it does not support any other SQLs.
Plus, now days moving to HTML5 world they have to rely on third party libraries. As always it is not always a good thing.
VTScada. The downside is development environment. I can’t say it is bad. it is different. Probably if you plan to work only with VTScada projects, after a few years you will have everything you need, you will obtain your own set of objects, scripts, OEM layers app etc…
Yes - it runs on MS OSs only. But the beauty of VTScada, I think, is reliability and minimum dependency from Windows/MS libraries. They even rewrote some OS level calls. You don’t need to have any Visual C++ or .Net installed. The story tech support guy shared with me was about upgrading the 30 years old project which was developed in some first VTScada DOS versions. All the guys had to do is to restore the project in latest version for Windows and everything worked as it worked in DOS version.
I like Ignition and Inductive’s developers and support teams. Yes, it is cross platform, OS agnostic etc. It gives you flexibility. But the price of this flexibility is it still depends … on JAVA, JRE and sometime on sets of different versions and generations of Python and other packages used earlier. You need to know in advance of your migration what library environment you must have on your target system/platform.
Another downside is using SQL for Historian. Yes, it is not a good idea to demonstrate the client how their new proposed Igntion Historian performs against their existing Proficy Historian for example.
You might be right.
I had a project where I made a script for migrating the data from GE’s Historian to Ignition. Initial development was done on Windows platform, but then we also tested it on Ubuntu and there was some issue with some Python function calls, it required 2.7 or 3.5 addition (I don’t recall right now), which was not a portion of initial setup on Ubuntu
