I'm new to Ignition and haven't designed a system with it before. I have 2 years of experience with HMI design but not with system design. Now, I need to design an Ignition Architecture and I'm not sure where to start. I've seen various Ignition SCADA architectures, but I’d like some input.
The setup involves two areas in the same building. The first area has 60 lines, 10 PLCs, and about 350 tags polling every 10 seconds. The second area also has 60 lines, 10 PLCs, and about 400 tags polling hourly from 5 am to 3 pm. Any advice would be much appreciated. Thank you.
A single reasonably spec'd server could easily handle that as a single gateway. For best maintainability, get a second physical machine (if you've got an IT group, make sure they don't do something silly like give you two VMs in the same physical server) and configure redundancy.
I wouldn't really think you need anything more complicated than that. You could make an argument for separate gateways for the two 'areas', but as long as your intra-plant network is solid, there's probably not really any need.
As @PGriffith said, there isn't really anything from what you describe that warrants a specific architecture beyond just one Ignition gateway - this depends on what each of those 60 lines look like, whether you have fault-tolerance needs (a warm standby database and Ignition gateway), and so on. Polling a few hundred tags hourly and every 10 seconds should be no problem at all, from what I've seen.
Thank you for your input. I also need to plan for future expansion, potentially adding more areas, lines, and extending the setup to 4-5 global sites with data sent to a central server. What should I consider for this?
What are the limitations of logging data in MSSQL, and could it cause lagging or slow retrieval? Should I consider using MQTT? Again, any insights would be much appreciated.
I don't think you need to consider anything additional, for now.
If you decide to integrate multiple sites to a cloud or central gateway down the road, you can establish a gateway network between sites at that point.
By the time you go down that road, you'll probably have enough lessons learned that you will revisit this original site regardless.
I'm not sure if I was wording the post correctly. I want to confirm that when I mentioned '350 tags polling every 10 seconds,' I meant 350 tags per PLC. With 10 PLCs, that's a total of 210,000 tags. Can a single gateway handle this load?"
What everyone else has said....and be sure to keep your database on a separate server too. MSSQL is a memory hog (if not configured correctly).
Don't try to have your local Ignition sites create direct database connections to a centralized SQL server...that communication is too chatty. Instead, have a database server at each site and use the gateway network and remote history providers (and/or tag history splitter) to send data up.
When you have a database on-site, I recommend using database replication (provided by the DB) to push data to remote sites, with the remote tag provider there using database history mode. This places the lightest possible load on the source gateway that is responsible for gathering and storing the history in the first place.
Would this mean that the central database would somehow have 1 or more network ports opened (or exposed) to allow the remote site database to talk to one another? Am I being overly paranoid to have the database exposed that way? I have dealt with IT folks who "Just Say No" to any requests that deal with opening ports to their database. The same folks that will install CloudStrike software....sorry, had to put that in there.
Yes, the replica database will need to pull from a source database. Paranoid shops will put a first replica in the site DMZ, with only the path from DMZ DB to Production DB open, and the remote replica will pull from that first replica. Streaming replica technology keeps replicas within a few seconds (or less) of the origin DB, so two hops is typically not an issue.
Database connections are well understood by IT, so are relatively "easy" to secure. (Well, easy for competent IT folk. )
)