Every automation trade show floor repeats one word: open. Open platform, open architecture, open ecosystem. When a single adjective describes everything a supplier sells, it tells a buyer almost nothing. "Open" has no shared definition in industrial automation, so on its own it functions as marketing rather than specification.

Christopher Deloglos, U.S. Strategic Product Manager for Weidmüller USA, argues the way past the marketing speak is a short list of concrete questions a buyer can put to whoever uses the term.

Five questions that separate open from closed

• Can you run third-party software on the device, including software that competes with the supplier's own, and on whose approval?
• Can you reach the operating system, and what does the supplier document about doing that?
• Can you move your application to another supplier's hardware later, or are you locked in the moment you build?
• Does the supplier publish a software bill of materials, a vulnerability process, and a support end date?
• What does exercising that open access do to your warranty and your certification?

A platform can pass one test and fail the next. A controller can host any container you like and still trap your application when you try to leave. A supplier can publish high-quality APIs and say nothing about what happens to support when someone opens a shell. Openness is a set of independent measures, not a single dial, and honest suppliers let buyers check each one.

From protocol interoperability to application freedom

The definition has shifted. Open Automation 1.0 meant interoperability: could a controller talk to another supplier's I/O or SCADA without a custom driver? That fight is largely won. OPC UA and MQTT are now common — ground Automation World covered in April with Ken Crawford, senior director of Strategic Automation Solutions.

Deloglos draws a sharp line between open and open source. Open source describes software whose code users may inspect, modify, and redistribute. Open, for buying purposes, describes the freedom to run third-party software and move applications to other hardware.

Open Automation 2.0 means application freedom. The litmus test: can you run someone else's software on the control or edge device itself? Consider a single controller running a PLC runtime from one supplier, a data-logging application from a second, and an HMI panel from a third, all simultaneously. The pieces share data through a common protocol rather than through custom glue code. The payoff is fewer forced purchases, less custom integration, and the freedom to pick the best tool for each job.

What openness costs, and who answers the 2 a.m. call

Openness is a cost a supplier chooses to pay, not a free virtue. Letting a competing application onto a platform means giving up some exclusivity. A buyer should treat every open decision as a tradeoff and ask what the supplier gave up.

Security is the objection suppliers pushing back on open systems hear most often. Opening a system does add attack surface, and it shifts some decisions onto the customer. But ISA/IEC 62443, the relevant standard, already accounts for host devices running general-purpose operating systems. What matters is the discipline around it: signed software, segmented networks, role-based access, and a working vulnerability process. Governed openness does not mean disabling integrity controls that block unsigned code; it gives customers a documented way to sign and run their own software while preserving those controls.

Serviceability is the part people forget. If a team modifies an open system and it fails at 2 a.m., who owns the problem? Most suppliers do not answer that in writing. A buyer needs specifics: which modifications void support, which do not, and what it takes to return to a supported state. Deloglos argues suppliers should publish that position plainly as an industry standard.

The OT/IT seam

Open systems land on the boundary between OT and IT, and the requirements genuinely conflict. IT teams expect containers, fleet management, and observability. OT teams need deterministic timing, safety certification, and change control that resists casual edits. An open platform does not erase that tension; it gives each side room to work on the same hardware.

How industries balance those demands explains their uneven progress. Process industries have done the most visible standards work through NAMUR and The Open Group's Open Process Automation Forum, though deployment at scale is still catching up. Discrete manufacturing and OEM machine builders often move faster in practice, because the payback on flexible multi-supplier systems shows up quickly. Look at what is actually running in plants, not only at what committees are specifying.

Regulation sets the floor in 2027

The next standard of openness is being shaped by regulation as much as by technology. The EU Cyber Resilience Act turns vulnerability handling, security documentation, and a stated support period into a baseline for anything sold into that market. Reporting obligations land first, with full requirements following in 2027. Once that floor is in place, security disclosure stops being a differentiator and becomes the price of entry.

The suppliers who win on openness will not be the ones who say the word most often. They will be the ones who let a buyer verify it, in an afternoon, on the bench. The question the development raises for integrators and plant engineers: when your next datasheet says "open," can your supplier survive that bench test — and will they answer the five questions in writing?