Hey All,
We're planning to deploy an Ignition system at our remote operations center (ROC) for monitoring. We currently have 16 remote sites with dedicated Ignition SCADA and SQL servers. We also have about 16 other remote sites using some other form of SCADA and historization. I suspect we'll be polling about 10,000 tags to start, but eventually, I could see the project reaching 100,000+, at 5-10 second poll rates in the next 5 years.
We want to deploy a system that's scalable. The ROC will only have 5 concurrent Vision clients. From what I've, read, it might be advantageous for us to install Ignition on the SQL DB as well as the primary IO/Frontend server. We will also want to utilize the reporting module since the ROC will have all of the priority data from all of our sites. Lastly, we'll install EAM to manage our Ignition Gateways. How would you go about deploying this?
Do we need a separate I/O Server from the Frontend Server?
Is Ignition on the DB Server to utilize the Gateway Network and compression necessary?
What design considerations am I neglecting?
This seems like a perfect question for the sales engineering dept at IA - I know they've seen probably hundreds of similar scenarios, so they would be able to give the best recommendations.
Is there a specific reason you're using Vision for visualization in the ROC? Is that what you already have or are you purchasing a new license?
I may be wrong, but the primary purpose of splitting frontend and backend gateways is to have I/O segregated from visuals. Having a separate I/O gateway for the frontend seems redundant.
EDIT: reread your question, I am dumb. If you want scalability, I would bet IA would recommend just that - to separate frontend and I/O services.
I'm sure there are benefits to having Ignition and SQL on the same gateway, but a drawback we run into all the time with our dev environments that are set up like this is that if there's a query that hangs or eats up all the memory, Ignition is impacted and vice versa. SQL Server seems to be ravenous when it comes to eating memory, so that may impact your gateway performance.
Not much constructive feedback, just a few things to keep in mind...
Thanks for the response! I sent the same request to sales and our account rep.
We've seen the same SQL/Ignition Memory issues on a couple of our locations that share the same box and do have some performance issues.
As for the Vision vs Perspective, we're not married to either. At ICC, I was told to go Vision from numerous people since all clients will be Windows workstations. However, for every person that told me to go Vision, I had someone else telling me to go Perspective. I've done a little in both. Perspective definitely "feels" better and seems more intuitive and polished.
Frontend, Backend, and SQL all on independent machines/VMs, otherwise they will fight for resources. Ensure resources are dedicated if using VMs.
My preference is always Perspective. It's modern, styling is centrally managed, it's responsive to screen resolution, and far nicer to develop in (imo). You're not spending twice as long trying to align and re-align and re-re-align components all the time when you want to add new components into a stack - just add it into a flex and BAM, done for you. Lots of other niceties as well, obviously, like transforms, complex property types, web browser clients, etc
I think vision if these are going to be panels in working areas like machine or process HMI's, otherwise Perspective is pretty nice to develop in, you can use the perspective workstation if you still want that traditional scada feel on the workstation
Why use Vision for panels?
Often we use them for systems that rely on a lot of jogging, where the reliability of the momentary button is pretty good and relying on a stable browser for this is not as good.
Also, drawing more complex process mimics we find a bit easier on vision, perpesctive pipes are okay for simple systems, but without the drawing features of vision or other SCADA systems I don't think perspective is the right choice for those kinds projects.
3 Likes
