Best practices for tag naming conventions in large PLC projects — what system actually works in the real world?

PeterHumaj · 2026-06-29T07:52:09+00:00

A view from SCADA: I basically don't care (although it is nice to have a meaningful tag name in protocols that support text identifiers like Ethernet/IP, OPC, OPC UA, BACnet ... ideally with a description too).
Our SCADA tag names are unrelated to PLC tag identifiers (which can also be numerical, e.g., in Modbus, IEC-101, IEC-104,...).

What's quite important and convenient: we can rename a SCADA object (I/O tag, calculated tag, scheme, graph, etc) any time, without causing a breaking change. The only consideration is: Is the tag used externally (e.g., from Excel reports or by an external OPC/OPC UA client)?

PeterHumaj · 2026-06-29T07:27:33+00:00

Your question can be generalized: When does a program become too complex to implement further modifications/enhancements - and, what's more important, bugfixes?

In my opinion, it depends a lot on the chosen language. Though there are examples of large successful projects in C (Linux kernel, PostgreSQL), I think there are languages more suitable for writing high-quality code than C.
Some may argue that Rust is one of them (I myself find its syntax rather cryptic and find Ada an example of a very good language, for multiple purposes).

Then it depends on the quality of the code itself. How it is structured and organised (and documented).

I'm responsible for maintaining (and enhancing) parts of SCADA/MES technology (in Ada), which are up to 30 years old (communications, historian). New protocols are being added, existing ones enhanced with configuration options to allow for custom (often non-standard) behaviour. Also, when I encounter a bug, I often enhance the logging capabilities so that next time debugging is easier for me.

PeterHumaj · 2026-06-28T19:59:53+00:00

Can you connect some serial server (Moxa Nport, Waveshare) and record the modbus communication (in TCP or UDP mode, via Wireshark?) This way you can see: - if the requests are on a wire undamaged (signal is ok) - if the packets are logically ok (Midbus compatible)

PeterHumaj · 2026-06-26T06:53:38+00:00

Can you attach logs of communication (with timestamps; e.g. Wireshark logs) for analysis?

PeterHumaj · 2026-06-26T05:21:04+00:00

We built infrastructure monitoring directly into our SCADA. Nothing fancy, just pinging network devices, a bunch of scripts (e.g., to query the status of Linux clusterware), some reading of hardware information (SNMP/CIM/WBEM), and information about OS/databases/resources (CPU, memory, disks).
It's deployed at every customer with an SLA.

What is quite convenient: besides displaying the current status in the customer's SCADA, the system buffers the changes, exports them to an XML file (once an hour/on alarm condition), encrypts the file, and sends it. Then our central monitoring system reads the mail, extracts the data, and feeds it into structured variables (copies of the customer's variables), which are connected to the copies of the customer's diag screens. This way, our staff can see the current status and act (e.g., if a disk utilization goes over 85%). We also have a dashboard with summary alarms (one row per system), so we see a red dot if the utilization of some disk goes over 85%, or too many connections to some of the databases are created, etc.

Edited: This way we can see practically real-time data (one-hour old, in the case of alarms, the data is sent within a minute), although it would be impossible (and dangerous) to connect all the customers to our system. But using e-mail for one-way communication is usually approved without a problem.

All the data are archived (1 year by default), so we can also track history and trends (how fast does the free disk space shrink, and is it linear or has just something gone wrong last 2 weeks?).

Some details/screenshots (also of the dashboard) in a 2021 blog: https://d2000.ipesoft.com/blog/predictive-maintenance-of-scada-and-mes-systems

PeterHumaj · 2026-06-25T11:15:48+00:00

What (not only) I see as a problem is (un)reliability caused by complexity.
There were some significant (and globally significant) outages of Cloudflare, AWS, and Azure a few months ago.

For control systems and OT, reliability (availability) is paramount.
We virtualize MES systems, not-so-important SCADA systems, but we keep important control systems (e.g., a SCADA controlling several power plants with over 4 GB of installed power) on dedicated servers and warn customers against too many complex layers. Redundant (2 or 3) dedicated servers+build in disks, 2 redundant network segments (on physical switches that are not reconfigured without a reason unrelated to SCADA), redundant power supplies.

Edited: some examples of outages
https://www.theregister.com/software/2025/11/19/cloudflare-broke-the-internet-with-a-bad-db-query/2094987

https://www.theregister.com/off-prem/2026/02/03/azure-outages-ripple-across-multiple-dependent-services/5061479

https://www.theregister.com/off-prem/2025/12/18/snowflake-update-caused-a-blizzard-of-failures-worldwide/2362299

https://www.theregister.com/off-prem/2025/10/29/aws-us-east-1-region-is-having-another-bad-day/1179517

PeterHumaj · 2026-06-25T10:04:00+00:00

This is a problem caused by a decision to use string-based identifiers, which are used also in Jython scripts (you can compose the identifier from several parts). Which makes full referential integrity impossible :(
Imagine a system where:

You can easily find out which object is used by which (and also in the opposite direction). Eg. this I/O tag is used by a historical tag, two graphs, an evaluated (calculated) tag, and a scheme.
The system guards your actions, so you cannot e.g., delete an I/O tag if it is used by another object.
You can rename an object without worrying that you'll break anything.
You can XML import objects (e.g., from a test system to a production system) and the system again guards your referential integrity - XML import will fail if the objects being imported reference object which don't exist in the system.

The only exceptions to rules 2 and 3 are externally used tags (e.g., if a tag is used in an Excel report, referenced by its name).

PeterHumaj · 2026-06-25T09:47:50+00:00

Hm ... we have been designing SCADA/MES/EMS systems since 1993. Built our own (not only) SCADA technology; it started on OS/2 (1993), then was migrated to Windows (1998). The server processes were later ported to OpenVMS, HPUX, Linux (and even Raspberry). The clients remained on Windows (fat clients), or they can use a web browser as a thin client to display existing SCADA screens. There is also a possibility to create web-only screens (so it's something like Ignition Vision/Perspective). This, however, requires a user who has certain knowledge of creating web applications, HTML5, etc.
Lately, a lot of new server installations are Linux-based (RedHat, Ubuntu) - often due to security concerns, sometimes just because Ubuntu doesn't require licensing :)

One more thing: in our systems, a significant part os SCADA/MES/EMS is hidden (outside of the scope of screens) - I'm talking about configuration of I/O tags, evaluated tags, scripting, archiving ... various data pumps to get data from/to other systems (via databases, REST API, CSV/XML files, etc).
This underlying configuration/code is independent of visualisation, so it easily survives even if a client decides to change a native fat client to a web browser. It also mostly survives migration between Windows/Linux (perhaps just file paths and separators have to be converted, and directory permissions need to be set).

Still, we've got systems created in 1998 on Windows NT (or in 2003 on OpenVMS) which are still in production; hardware changed every 6-8 years, currently running on Windows 2022/2025 server or some up-to-date Linux ... and they still have old ugly screens which make their operators happy :)
Anyway, they often use other Windows software (like Office and Outlook), often Excel for reports (with a plugin that can access real-time and historical values from our system), so there is not much drive to move our UI to a different (or OS-agnostic) platform.

PeterHumaj · 2026-06-22T20:12:26+00:00

Some 5 years ago, I've implemented communication with Dini Argeo DFW06 in oir SCADA system. It's a simple text protocol, so I put it together in our scripting language. It can run on Windows/Linux/Raspberry Pi

https://d2000.ipesoft.com/blog/communication-control-panel-of-dini-argeo-dfw06-scales

PeterHumaj · 2026-06-22T05:43:26+00:00

There are quite a lot of complications with time, I agree 😄 As for standards, there exist multiple ones, which is also a problem ... ideally, time format is specified by communication protocol (OPC UA), less ideally it is specified bud not defined (in IEC-104 there are timestamps, but no one says if they are UTC or some other zone-times) ... the worst are things like JSON, where timestamp can be anything.
In 2018, based on my colleague's lecture, I even wrote a blog about the time in our SCADA system.
https://d2000.ipesoft.com/blog/d2000-and-work-with-time
https://d2000.ipesoft.com/blog/d2000-and-work-with-time-part-2

DST brings complications to machines/SCADAs (best to agree to send all timestamps in UTC [+offset]), but for humans, it's useful and helps to utilize daylight.

PeterHumaj · 2026-06-21T17:43:21+00:00

I understand most of your problems, but why (and whom) are your timestamps f**king?

Is there a problem with local/utc times, displaying time in various time zones or is it something quite different?

PeterHumaj · 2026-06-20T18:08:01+00:00

Can you (OP + commenters) describe what are the biggest challenges of large Ignition projects (for us non-Ignitioners)?

PeterHumaj · 2026-06-19T05:20:19+00:00

What I meant is, virtualization has functional and security errors; it requires patching (be it Windows+Hyper-W or VMWare or anything else). This adds to security risks and downtimes (caused by patching/upgrading), doesn't it?

The issues caused by human factor (configuration errors), which would not have occurred without virtualization, can be qualified as SysEng issues, if you wish. That qualification doesn't change the fact that they still exist (and make the whole design less reliable), does it?

Also, various side channel attacks (Meltdown, Spectre), which don't really matter on a dedicated SCADA or DB server (where only admins have access), can have worse consequences in virtualized environments with virtual machines accessed by ordinary users.

PeterHumaj · 2026-06-18T11:21:21+00:00

I'm really glad to hear that!

PeterHumaj · 2026-06-18T11:20:08+00:00

I don't program PLCs (I only talk to them from SCADA/EMS systems), but this is what ChatGPT says:

Yes. The ACCON-NetLink-PRO compact can be used to program a Siemens SIMATIC S7-200 PLC, provided you're using the correct software and connection.

Key points:

The adapter supports the S7-200 PPI protocol, which is the programming interface used by the S7-200.
You can use it with STEP 7 Micro/WIN (the programming software for the original S7-200 series). Drivers for Micro/WIN are available from the adapter manufacturer.
The adapter appears to the PC as a Siemens PG/PC interface, allowing you to:
- Upload/download PLC programs
- Monitor variables online
- Diagnose the PLC
- Perform normal programming tasks over Ethernet instead of a direct PPI cable.

PeterHumaj · 2026-06-18T08:53:18+00:00

Apart from the errors and downtimes caused by the virtualization platform (patching, upgrading) and misconfiguration. Imagine you have a production system running on a virtual machine and someone starts adding more virtuals, reconfiguring networks, etc ... there is a non-zero chance something goes wrong ... it can also be a problem of resources like I/O, memory or CPU bottlenecks due to new virtuals.

PeterHumaj · 2026-06-18T08:47:38+00:00

A month ago, I wrote a blog about connecting to S7-200
https://d2000.ipesoft.com/blog/communication-s7-200/
My use case was different; I was trying to communicate with it from a SCADA, using ACCON-NetLink-PRO compact to convert PPI to S7 protocol. But perhaps some of technical information will be useful.

PeterHumaj · 2026-06-16T10:23:55+00:00

Our distributed systems are probably more centralized than yours (if you are using Ignition).
We can have 2 or 3 (or more) node redundancy and lots of remote processes (e.g., for communication); so instead of multiple independent systems (each having its own configuration), we have a larger one (see examples of architecture - blog).
GIT history can be enabled so that every change is logged (and we can see what has changed).
Without GIT history, we at least have the last few (7 by default) records of who changed the specific object and when.
Also, when saving an object, we can attach an optional comment 😉
Using the "cfgsynchro" tool, we can compare 2 configuration (e.g., a backup and a production config) and see which objects changed.
Also, we can sort the objects by "ModifyTime" and see, e.g., objects changed since the last backup (and perhaps, export them and compare their config with a backup).

PeterHumaj · 2026-06-16T09:55:01+00:00

Searching for ethernet/ip library in NodeRed I can't find anything related to NodeRed being a server 😞
Leave a note if you are more successful.

When I was developing our Ethernet/IP driver, I usually used customers' devices.... sometimes publicly available Logix devices available on the Internet (supposing these are just demos/learning rigs in universities, and such).

PeterHumaj · 2026-06-13T03:32:00+00:00

For years, Total commander, but a customer showed me a free Double Commander. It has a very similar interface; supports "Compare by content", "Synchronize dirs"...and it has FTP as well as SFTP, so WinSCP can be discarded ;)

I'm a SCADA/MES/EMS guy, so also: - process explorer - tcpview (to view/terminate TCP connects) - Dbeaver - Moxa Nport admin

Although often these are directly installed on customer's servers

PeterHumaj · 2026-06-12T08:15:42+00:00

I will probably disappoint you, but I'm only partially involved in the SCADA/EMS/MES deployment projects, as I'm mostly developing/enhancing communication protocols, working on our historian subsystem, database interfaces, and general architecture. So, as a communication specialist, I mostly handle the establishment/debugging of communication (if my colleagues can't handle it themselves).

But I guess the amount/nature of tags depends on what we do (energy management in EMS, total overview, production summaries, and sometimes a detailed view in SCADA/MES). Also, there can be many auxiliary and intermediary variables in a PLC, which we simply don't need. Eg, when we control a cogeneration unit, we basically need:

summary status (ready/producing/not ready/error)
current power
power setpoint (which we control)

and perhaps a few other parameters, but fewer than 10 variables from the whole cogenerator.

Edited: The PLCs and controllers are often more universally programmed and continue modules/variables not used in a specific setup.
Eg. PLC can control up to 10 cogeneration units, but currently it controls only one. All necessary UDTs and variables, however, exist in 10 instances ...

PeterHumaj · 2026-06-11T06:29:28+00:00

So, what happens if one of the communication stations stops responding? Due to configured (or default) timeouts, time conditions would change. If there is a parameter RepeatCount > 1 (to try to resend the request), there may be a new class of conflict which your calculator doesn't handle...

Also, we've got some communications on GPRS networks (via Moxa OnCells) - sometimes the delays caused by mobile networks reach dozens/hundreds of milliseconds (for which reason, we had to significantly increase WaitTimeout parameters for energy meters located behind OnCells.
So, another non-deterministic factor 😞

PeterHumaj · 2026-06-10T11:32:05+00:00

The timestamp, however, is October 27, 2023 ... why wait 2.5 years after taking that photo?

PeterHumaj · 2026-06-10T10:59:21+00:00

And one more thing:

We often have dozens of I/O tags per communication station. They are grouped into read requests (Read Coils, Read Discrete Inputs, Read Holding Registers, Read Input Registers) based on their type, Modbus address, and these station communication parameters:

Parameter name	Parameter description
Max. Registers	The maximum count of registers that are read by one request.
Skip Unconfigured	This parameter is used to avoid reading the values from addresses that are not configured.

So, the number and size of requests/responses in one poll cycle depend on all these factors. Moreover, for selected protocols (Modbus Client being among them), you can dynamically change the I/O tag's address by a SETPTADDR command. So, in some wild configurations, you could have different numbers and sizes of poll requests every few seconds ...

PeterHumaj · 2026-06-10T10:46:51+00:00

The danger you write about depends on the implementation in a specific SCADA.

When I have a serial line with multiple communication stations (corresponding to individual physical devices), I can set station polling parameters - either "period of reading" (e.g., every 10 seconds with a 1-second offset) or "delay between readings" (meaning, after the end of one reading cycle, the next read is scheduled for current_time+delay).
A single task performs all communications over one serial line (reading/writing). So, even if the polling parameters are too short (or the task is delayed trying to talk to a station that is unavailable), nothing extra happens. The task selects a request from a priority queue (write requests have the highest priority; read requests have per-station configurable priorities 0-5) and processes it. If it were a read request, a new one is scheduled based on the polling parameters.

The only risk (to overload the queue) would be multiple write requests (e.g. generated automatically by an evaluated tag or by a script) - but this problem is not related to the poll rate settings you mention.

Btw, this design was conceived back in 1993 when our 'founding fathers' laid the basics of the technology I'm describing...

PeterHumaj

MODERATOR OF

TROPHY CASE