Does anyone here run a project with a high ammount of tags on one server? let’s say +20.000. We are looking into a group SCADA and I am impressed by the Ignition engineering potential and licencing model.
So let’s say we would run a High end Server and do an exelent job in setting up the ignition software. In theory I could run (according to Ignition) up to 250.000 and 300 consecutive users on a single server. Now that sounds massively impressive if that is true.
So are there Forum members who run 20K+ and have a stable system.
Reason I ask is because our IT deparatment is looking for a Domestic solution where every SCADA instance runs on a separate server (20 projects means 20 servers). Now we do not need to discuss why that is a bad idea, I have experiance with SCADA solutions, but none with Ignition.
P.S. I do not work for an OEM, but for a company that has a number of Manufacturing plants (food)
It's actually not a bad idea, as you don't have a single point of failure, but I would still have "one server to rule them all and in the darkness bind them".
Ignition is highly scalable, so you can distribute different loads to different servers if you like. Our typical installations are 50k+ tags and we use two normal servers for this, one Ignition(4 core 16gig memory) and one Database(8 core 32gig memory). We can handle 100-200 users no problem, it is stable.
These days with virtual servers, IT handle all the server installs and specs and we just install the software and go. If we need more power, they upgrade the virtual machine.
A solution as shown in your layout is offcourse managble and good practice. The solution that our IT department is looking into runs on Raspberry-Pi devices. It would mean that 5 big projects, and 30 small project would run from 35 hardware platforms. All these devices need to be managed,and none of them offer redundancy. Therefore this Domestic (Hungarian) solution would not work for me.
And for the sake of pricing, I am currently not in a position to include Enterprice Architecture in the comparison. (But I do have server redundancy in my price)
But I do appriciate the idea of the Enterprise Architecture, and it would be great if such a solution can be implemented on a conventional Ignition installation as well, one that would be in operation for lets say 2 years.
So basically you are running a single license for Ignition? and you chose to have your DB on premise. But the DB solution can be whatever is within the support of Ignition, there are no additional cost for the solution that you choose. I am running a trial version right now, and I use a PostgreSQL DB.
Okay, so far it does all sound good! There is one other thing that I would like to touch up on, this Domestic supplier claims that when in Ignition one uses 5000+ modbus tags, there will be severe performance issues.
Now, I have no clue on what information there claim is based, but it sounds unlikely to me. Unless it is inherent to the Modbus protocol. But also this sounds a bit far fetched since I have worked in refrigeration plants where large ammonts of tags were used to visualize refrigerant processes.
We have a single server system that has about 160k tags, maybe 60-80k of those are coming from PLCs and the other are one of the internal types (memory or expression). The CPU usage is quite high, averaging around 60-70%, however the server is underspecced and will be replaced in the near future. Their system also has a large number of expression tags and tag event scripts, which put additional load onto the system. That being said though, the stability of the system hasn’t been an issue.
SQL server is separated into its own VM. I would never locate this offsite unless you have a gigabit connection, otherwise you will be introducing lag into the system which will affect client performance, as well as gateway performance and stability.
That’s right, single ignition license and a DB. We use either MariaDB or PostgreSQL. Sometimes MSSQL if IT or a customer insist, this hurts me inside though.
Raspberry Pi devices are great, but I wouldn’t run a SCADA or production environment on them at all.
You're much, much more likely to overload a PLC with 5000 tags than Ignition. Many modbus devices in particular are much less powerful hardware, so if you do things wrong in Ignition (ie, add 5000 tags all polling at a constant 1 second rate) you'll easily overwhelm your device, which manifests as slow communication in Ignition, because tag values come in slow or not at all. Being precise about which tags you actually bring in to your SCADA system, and the use of leased tag groups (which poll at a 'fast rate' when actively being viewed, and a slow rate otherwise) are options to help reduce this problem; but fundamentally it's one at the device level.
I would concur with Paul, any OPC tag that goes bad quality is most likely to be network/end device issue, if the Modbus devices are serial connection via Ethernet gateway, the amount of points you can read and the poll rate will be quite limited, to help with this the Gateway Driver Stats page has a nice circle gauge that displays bandwidth.
As for Ignition performance/scalability, I have not found anything that comes close, one of our gateways is running 170,000 Tags & 1600 Devices, 500 of which are Modbus with 20-30 points from each is about 10,000 Modbus Tags, stability and client response is good.
Thanks for all the input, seems that Ignition delivers it’s promises. I understand that basically the infrastructure is key in the installation. (project and hardware hierarchy)
Additionally it seems that there is an active organized community to support the product!
Yes indeed, Ignition has a great community around it, always willing to help and share solutions. Check out Ignition Exchange if you haven't seen it yet, lots of shared resources, all free. Ignition Exchange | Inductive Automation
With the benefit of having a modern, easy-to-use, and powerful forum backbone to drive it! Not like the majority of other products' forums from the 20th century
I just checked one of our bigger projects, and it has 77k tags, without ever running into an issue on Ignition regarding tag performance (the Ignition instance is maxed at 4GB memory, the server has 8GB and uses around 10% CPU on a 4 core @ 2.3 GHz)
But those tags do come from different PLCs (the majority comes from 3 Beckhoff PLCs using OPC-UA, with a minority coming from specific machinery).
Note that you also shouldn’t underestimate your tag count. We put a lot of configuration into tags (like device name, device parameters, …).
Since these tags are very static, they cause very little CPU usage (communication usually happens on tag change), but do add to the tag count.
A single motor has grown to about 50 tags on our installations. This includes parameters (max/min/auto speed, ignition configurations like name, description, display path, …), controls (bits for putting a stop on motors or letting it run), alarming info, …
Ignition is awesome and we have quite a few installs running 200k+ tags. We usually find that number of tags per PLC is more of the bottleneck. A limit on the PLC end. E.g. I wouldn’t exceed 15k OPC tags per L8x PLC if you’re using the Ignition OPC-UA server. But you can be smart about how you bring your OPC data in and unpack them with expression tags with well tuned scan classes.
Another thing you can do, is separate your vision server from your tag provider server.
I think our installation will differ a little from the most common implementations.
I work for a group of companies that all share the same Domain network. These companies range from Salami production plant, to Animal feed, to Manure separators etc.
We are in the process of a central OT organization (finally) to manage and standardize our OT equipement and software. One of the topics is to bring the majority of local SCADA to a central location. This is why I am interested in Ignition. With Ignition I only have to manage two servers (redundancy) and the licencing model is unrivaled.
Our Enterprise network is pretty well setup, consiting of mostly enterprice level Cisco hardware and it is well managed by a team of IT proffesionals. Our central ERP communicates with multiple plants without issues.
Our Ignition implementation will be quite diverse. Consisting of a number of protocols, and a multitude of devices, from a number of plants throughout the country. We communicate mostly with existing OT infrastructure. We have a range of installations and tag count differs greatly. We have installation with just 300 tags and installations between 10K and 20K tags. Too me it seems that the most important thing is the foundation on which we setup the projects. (Polling speeds, leased tag groups etc.) At some point where SCADA does not control the installations, but only provide visual feedback we will replace the old SCADA for the Ignition version.
It promises to be an interesting project, and it seems that at least the Ignition product can meet our expectation, offcourse on sites where we have faster processes that generate a relative large ammount of data, I am planning on usiong Ignition Edge devices.
Additionally Ignition gives us the option to work with, and without integrators. This level of independence is one of the main drivers (together with licensing strategy)
You would maybe be better with a hub and spoke of a local DB on the site, with full Ignition, there are examples of this architecture on the IA website.
I say maybe because your idea of relatively large might vary to mine.
Some Edge information;
Can store up to 1 week of data or 10M rows, whichever may come first.
Adding MQTT removes this 10M row limit.
Can be used a local client fall back if the link is lost to the main gateway.
I’m not a big fan of placing the Ignition server on a different site than the clients. A long distance network is always less reliable than a local network, and harder to scale up.
I would advise to have one Ignition server per site (it can be an edge license if it’s just a single machine). And connect those servers to a central server. Though finally it’s all risk assessment. How much would you lose per hour the Ignition connection is down, how likely is it to happen, and how much do the extra licenses and server equipment cost.
With the EAM module, it still helps a lot in standardisation without it needed to be hosted on one location.
If all sites can work independently, there’s also little use in having a backup installation. With well-managed virtual servers, you can get a backup back online in minutes. And if sites can work independenly, a crashing computer will only cause issues on one site.
In my experience, a backup installation also causes issues from time to time because it’s Ignition specific, so the IT team generally has no idea how to work with it (while they do know everything about virtual server management). And it also requires you to put more effort in the design of your system (what database will you connect them with, how are scripts executed, …).
