What "vendor-agnostic" actually means in industrial control
In industrial control, vendor-agnostic is a precise architectural property, not a marketing position. It means three things at once. First, the engineering work product (the model, the specification, the design intent) does not assume a specific PLC family, runtime, or instruction set. Second, the platform can produce deployable code for several different hardware targets from the same source. Third, switching the target is a deployment-time decision, not a re-engineering project.
All three matter. A platform that lets you target Siemens and Rockwell only by writing two parallel codebases is not vendor-agnostic, it is dual-vendor. A platform that lets you target several hardware families but tightly couples its model layer to one vendor's data structures is vendor-agnostic only as long as that vendor's data structures are sufficient. True vendor independence requires that the model is conceptually higher than any one vendor's stack and that the code generators sit beneath it as interchangeable parts.
Why most "multi-vendor" claims are not truly vendor-agnostic
It is worth understanding why vendor lock-in exists in the first place. Industrial control vendors compete on hardware, but their commercial moat is the engineering ecosystem around it: the IDE, the libraries, the certified function blocks, the training, the integrator network. Each of these is genuinely useful, and each of them also raises the cost of moving to a different vendor. The result is not a conspiracy. It is the predictable outcome of a market where vendors are rewarded for making their stack the easiest place to start a project and the hardest place to leave. Vendor-agnostic platforms exist because asset owners and operators eventually pay the long-term cost of that asymmetry, and they want a way out.
"Multi-vendor" appears in marketing material across the industrial automation landscape, but the architectures behind that label vary widely.
- Translation layers map one vendor's instruction set onto another vendor's runtime. They make the same hand-written code run on multiple hardware families, with caveats about supported instructions and timing behavior. They reduce porting effort but they do not remove lock-in: the engineering work product is still vendor-specific.
- Configurators let engineers compose pre-built blocks that have implementations for several PLC families. They are useful where the system fits the configurator's library, and brittle where it does not.
- Model-centric platforms sit above the hardware layer entirely. The model has no vendor in it. Code generators are the only vendor-aware part of the stack, and they are pluggable. Switching targets means selecting a different generator, not rewriting the system. The model stays untouched.
The first two reduce friction. Only the third removes lock-in as an architectural concern. The distinction is invisible at small scale and decisive at the scale of a national infrastructure operator with hundreds of objects to maintain over thirty years.
The architectural requirement: a model layer above the hardware layer
Vendor-agnostic control software requires a model layer that is conceptually above any one vendor. In a model-centric platform that layer holds the structure of the system, the behavior, and the interfaces. The vendor-specific knowledge (instruction set, timing, IO mapping, runtime libraries) is encapsulated in code generators that translate the model into deployable code for each target. The two layers are kept distinct by construction.
This is the same separation of concerns that lets a CAD model drive a CNC mill from any manufacturer, or a circuit schematic produce a PCB layout for any fabricator. The design captures intent. The toolchain handles the translation. Industrial control is one of the last engineering domains where this pattern is still rare, mostly because the runtime requirements (deterministic execution, certified libraries, safety integrity) make naive abstraction expensive. The platforms that get this right invest heavily in the code generators precisely so the model stays clean.
What vendor-agnostic enables
The architectural separation pays off in three places.
Procurement flexibility. Hardware can be selected for price, availability, certification, or local-support reasons without re-engineering the system. In supply-constrained periods (which industrial automation has been in repeatedly since 2020) this is the difference between a project that ships and a project that waits.
Lifecycle independence. A controller that goes end-of-life does not force a re-engineering project. The model continues to be the maintained artifact, and a new code generator targets a replacement controller. The asset owner is not held hostage to the vendor's roadmap.
Reduced lock-in cost. Lock-in compounds across decades. Licensing escalations, support contract renegotiations, and forced upgrades are all easier to absorb when the system can credibly migrate. Even when migration never happens, the option to migrate is what disciplines the commercial relationship.
In our experience, the asset owners who chose vendor-agnostic platforms in the early 2000s and stayed with them are now on their third generation of underlying hardware, with the same model still running the system. The asset owners who chose vendor-locked stacks in the same period are mostly facing rip-and-replace projects.
Practical limits
Vendor-agnostic does not mean vendor-blind. There are real limits to be honest about.
Vendor-specific libraries inside the model. In practice, the parts of a system that touch IO, drives, safety, or specialized hardware often rely on vendor-supplied function blocks. Those blocks are vendor-specific by definition, and a model that uses them inherits that dependency. The architectural answer is to isolate the vendor-specific parts at the lowest layer of the model (the modules that actually talk to hardware) and keep the higher behavioral layers (sequence logic, coordination, system behavior) free of vendor assumptions. The result is a model where the bottom is partly vendor-shaped and the top is portable. That is honest vendor-independence, not magical hardware abstraction.
Real-time edge cases. A few extreme real-time requirements (microsecond-class loops, high-frequency motion control) sit close enough to the hardware that vendor-specific implementations are unavoidable. A model-centric platform handles this by letting engineers invoke vendor-specific blocks at the edges, with the rest of the system staying portable.
Vendor-specific features. Some controllers ship with proprietary diagnostics, integrated safety, or motion libraries that have no direct equivalent on other hardware. A vendor-agnostic system can still use these features when they matter; it just makes that dependency explicit instead of letting it leak through the whole stack.
Certification considerations. Safety certification (IEC 61508, IEC 61511) is granted to specific hardware-software combinations. Vendor-agnostic does not mean every target is certified for every use; it means the design layer is portable, while certification is reasoned about per target.
Vendor-agnostic platforms that pretend these limits do not exist are easy to spot in production. The platforms that name them, design around them, and document them are the ones to take seriously.
Examples of platforms designed for vendor-agnostic deployment
Vendor-agnostic platforms are rare in industrial control because the architecture has to be there from the start. Retrofitting it onto a stack that was originally built around one vendor's runtime almost never produces a clean separation, and the seams show up in production. Cordis SUITE is one of the few platforms in the world built vendor-agnostic from the foundation. Since 2000, the same model has been generating deployable code for major PLC families and embedded targets, including Siemens, Beckhoff, Rockwell, Mitsubishi, CODESYS, Phoenix Contact, Bosch Rexroth ctrlX, Saia Burgess, and .NET/C# runtimes. The platform has been used in production across national infrastructure, cleanrooms and high-tech manufacturing, water management, and energy systems for over two decades. That track record is the difference between a code generator that works in a demo and a code generator that holds up in the field.
Most of the platforms that ship a vendor-agnostic story today were not vendor-agnostic five years ago. Architecture this strict is not something you add later, and the seams show in production.
Other platforms in adjacent categories (low-code OT environments, integration tools, controller-portability layers, configurator-based systems) take partial steps in this direction with different trade-offs around how completely the model is freed from vendor assumptions and how many target families are genuinely supported in production.
When evaluating any candidate, the questions worth asking are concrete. Where does the model end and the vendor-specific code begin? What is the upgrade path when one target controller goes end-of-life? Is the code generator a maintained part of the platform or a project-specific extension? What share of the platform's customer base actually deploys to multiple vendors in production? Honest answers to these separate the platforms built for vendor independence from the ones that wear the label.
One question that separates the genuinely vendor-agnostic from the rest: can the platform also work in the other direction? In modernization projects, asset owners often start with deployed vendor-specific code and need to bring it back into a portable model. Platforms built around true vendor-agnostic architecture handle this case. Platforms built around one-way code generation do not.