Best Practices for PLC and SCADA Integration in Industrial Facilities

I would like to hear practical recommendations for integrating PLC and SCADA systems in industrial facilities such as factories and warehouses.

What should be considered during the early design stage to ensure reliable communication, future expansion, cybersecurity, alarm management, and smooth integration with electrical and MEP systems?

It would also be useful to know what common mistakes cause problems during commissioning and how they can be avoided.

Looking forward to learning from the community’s experience.

Use Linux on all production systems.

Never assume you won't be expanding. Build everything with the idea that you're going to need/want to scale it.

Different perspective from the technical answers, I work in the hiring side in automation which means I spend my weeks hearing engineers describe projects that went wrong. A few patterns come up so often in those conversations that they're worth adding to a best practices thread:

The SCADA developer getting involved too late is probably the most common one. The PLC side gets designed and half built, then the SCADA team inherits whatever tag structure exists and the whole integration fights that decision for years. The projects people tell me they are proud about are the ones where naming conventions and data structure were agreed before anyone wrote code.

Take the technical guidance from the people above me, this is just the view from the exit interviews.

Indeed. PLC programmers often have no idea that structures matter to SCADA, especially for comms performance. I highly recommend segregating tag hierarchies for SCADA monitoring from hierarchies for SCADA commands from hierarchies that are purely internal to the PLC. While there are nuances by PLC brand, the fundamentals of comms optimization (big blobs of densely packed data) apply to all of them.

On that note, if at all possible have the PLC code written around UDTs instead of AOIs. Ignition is much more efficient reading UDT members than AOI members. The UDT can be fed to the AOI.

This word document was produced by Claude (AI). I asked it to collate the best practices scraped from the forum back in March. It did a pretty good job, except that it created separate tables for each of the poor/better practices, and didn't size the comment columns well...
The forum doesn't allow uploading docx so I had to zip it.

Ignition_Best_Practices_Guide.zip (26.6 KB)

Spot on about UDTs over AOIs for Ignition comms optimization.

A few practical takeaways from real-world plant startups:

  1. Standardize Tag Hierarchy Early: Don't let PLC devs dump random tags. Use structured UDTs with separated read/write/internal blocks so driver requests can pack data efficiently.

  2. Device Connection Strategy: Avoid poll-rate overkill on non-critical tags. Split fast-changing process variables and slow diagnostic tags into different poll groups.

  3. OPC-UA Security: Enforce Sign & Encrypt at the PLC/OPC level from day one. Don't leave security for "after commissioning" — it almost never happens.

  4. Alarm State Management: Handle alarms directly at the PLC level (latching/state) and pass structured states to Ignition, rather than trying to calculate alarm logic purely inside SCADA scripts.

What PLC platform are you pairing with Ignition for this facility (Logix, Siemens, Beckhoff)?

LLM much?

Fair play! Bullet points do look a bit robotic, but I just habit-write notes like that. Bottom line remains though — flat tags and poll rates will destroy OPC performance every time. What's your go-to strategy for OPC-UA polling groups when dealing with thousands of tags?

Even that response sounds very LLM-ey... :face_with_raised_eyebrow:

Maybe the second response was intentionally drafted purely in AI to make a point. Sounds like something I would do :grin:

I've been watching this account since approved. The posts are obviously AI generated, but I can't really fault that on its own, it's often better than reading somebody whose native language isn't English attempt it anyway.

If it turns into spam just report it.

To be fair, AI-detection tools have a poor track record, especially with those whose writing style is particularly formal. Cough.

Busted! Kevin is spot on. English isn't my native language, so I run my thoughts through AI to clean up grammar and phrasing before posting. Guess it tends to polish things into that signature robotic tone. No spam intended here, just genuinely interested in how you guys structure large tag counts in Ignition without tanking the scan rates. Appreciate the honesty and understanding from you all. I'll tone down the heavy editing so it sounds more human!

The struggles of this day and age trying to know if one is some agent spamming posts on its own or is it someone just using a auto formatting for grammar and language barriers.

This long dash is usually a dead giveaway though.

No, that (the em-dash) is just one of the most common false positives, popular with us formal types. :frowning:

I've known quite a few formal types, and I've never seen any of them use it.
But I'm willing to believe there are some who do. And I will note I did say "Usually".

The real giveaway is ending the posts asking questions like he does at the end of his posts imo

Makes me think of everytime I google something now

It was these as well as the summary headings in the numbered list for me

This one in particular didn't sound like what a human would come up with for the content of that point, particularly for a forum post

But now at least it makes sense. I think I would write in your native language and use Google translate instead to translate into English so your thoughts come through unadultered. Although I only know English so I don't actually know how well it translates... At lease those little grammatical errors it might produce would sound more human though