There is nothing simple about managing industrial automation software systems. Many interwoven factors mean a narrow focus is a system killer. An application specialist might say “let's load the latest” for the newest features, but that recommendation rarely accounts for everything it implicitly agrees to. Managing software systems has become a critical systems-thinking exercise for many organisations, even those that wouldn't describe themselves as operating critical infrastructure, and software is now increasingly part of the safety case that must be assessed.
Remotely operating plant and equipment has become standard practice, but the human element of that remote management, arguably the most important part, hasn't always kept pace in terms of security, staging practice, and systems engineering discipline. Many software systems have advanced significantly in functional capability and security. Systems management practice and business process haven't always kept up with the same demand.
Every piece of software, industrial, desktop, or otherwise, requires maintenance. There's a myth that software systems behave unpredictably; the truth is software is deterministic, doing what it's supposed to do in an expected way. What's harder to see is that the environment and data around it are constantly changing. Software is repeatable, but the environment it operates in never quite repeats.
“Updating a system” can mean anything from a full upgrade to a minor hotfix, and the actual step involved can be trivial or genuinely difficult. Operating system vendors release constant updates, mostly for bug fixes and closing security vulnerabilities, and tools like Windows Update exist to make this near-automatic. From a vendor's perspective, having every user on the same software version reduces support costs and the complexity of maintaining multiple legacy versions, which is part of why software reaches “end of life” even while it still works.
Many vendors release new versions annually, sometimes with intermediate releases, and patches for security or critical bugs as needed. Industrial automation has a much smaller user base than desktop software, so managers typically schedule upgrades based on the risk of changing a system with known operational performance, the benefit of upgrading, whether current patches keep pace with vulnerability remediation, and any pending hardware refresh. IT infrastructure managers should have their own plan rather than mirroring vendor wishes, since even identical software behaves differently across environments that are never quite the same. How software is staged into production is the key mitigation step toward as close to full certainty as possible.
A staging environment closely matching the destination production system provides a sandbox to test new versions, patches, or hotfixes before they reach anything live. Critical infrastructure managers often run several staging environments, development, test, pre-production, and production, which can look excessive until you're managing a genuinely critical system, at which point it's the bare minimum.
A development environment, often on lower-grade hardware, is where anything goes and configuration changes can be tested without disrupting formal staging, expendable and easily reinstated clean. A test environment should be maintained closely to production, where user acceptance testing happens in a controlled sandbox, helping administrators catch obvious deficiencies before wider rollout, and may incorporate real test devices and business interfaces for realistic data. Pre-production should match production as closely as possible, including any redundant functionality, since staging redundancy before deployment moves the certainty envelope further still, even though network interfaces will always be unique to each environment.
Each stage focuses on improving certainty: validating that previous functions still work, confirming new functions behave as expected, reducing operational risk, building administrator familiarity, and getting ready for the next cycle of finding and resolving issues quickly. Updating large-scale or specialised application software also carries risk around retrospective testing of interfaces, APIs, or special functions that the average QA process won't catch. The rule of thumb: check for patches even on clean installs, and test special cases yourself, since past performance doesn't guarantee future behaviour.
The ideal setup above may not be practical to fund for every organisation. Very small organisations may reasonably decide no staging environment is necessary, accepting the risk of automatic rollouts. Even then, a software support partner can offer a degree of safety through a customer-aligned development lab, testing core software functionality rather than server infrastructure or business interfaces.
Our recommendation is to stage all software, no exceptions. If your support partner doesn't have a lab that can mirror your specific environment, find a partner that can.
Beyond operating system changes and application updates, the most overlooked, and most vulnerable, area is configuration management: how a system is uniquely set up, and how every major and minor change since is tracked, applied, and stored for rollback and forensic purposes.
Once a platform is staged and showing high confidence, no exception logs, no interface errors, the application itself still needs proving functional. Application developers are usually certified partners of the OS vendor, developing against pre-release OS software that's itself still changing, so applications are always playing catch-up, and an OS patch can be available before the application release that's meant to support it. For industrial automation specifically, the criticality is heightened: you cannot ship a release overnight and fix it later based on customer feedback, a strategy some app providers tolerate but operational environments cannot.
There's usually a real delay between an OS release becoming available and the automation software being officially supported on it. Moving ahead of the supported OS version is a risk, and likely breaches the end-user licence agreement. Configuration management responsibility, whether application or hosting software, always remains with the user. There are no shortcuts: the platform manager has to decide whether to wait or proceed with caution.
There's no single rule that fits every system, but a systems view is essential. Some practical starting points:
This approach comes from years of managing critical, and not so critical, software systems. We believe the risks in industrial automation are preventable, or at least manageable, with a willingness to face them directly rather than defer them.
With good practice, every organisation can move closer to full certainty.