Protocol Over Product

Why the proprietary robotics stack is becoming a component, not a platform.

Industrial robotics was built around a bargain: accept the vendor’s closed stack, and in return get a machine that moves safely, predictably, and with someone accountable when it stops the line. For decades, that bargain made sense. The problem is that the factory changed. The robot is no longer an isolated machine. It is a node in a heterogeneous, software-defined production system. And a closed stack that once reduced integration risk now increasingly creates it.

The proprietary robotics stack is a collapsed architecture. That is not only a commercial observation, though the commercial incentives are real. It is a structural description of how a set of genuinely distinct technical problems, real-time motion control, sensor data distribution, fleet coordination, application logic, and service delivery, got bundled into a single vendor product and sold as one inseparable thing.

The bundling was not pure invention. Safety certification, uptime accountability, liability, and the genuine complexity of early integration were real reasons to consolidate inside one vendor relationship. A single throat to choke still means something when a robot arm stops a production line. But commercial logic has always run alongside technical logic in these architectures, and the two are now separating. The market is building the seams between layers. That is the architectural break worth tracking.

What Is Actually Shifting

The transition in robotics is not a single standard displacing another. It is a layered architecture replacing a collapsed one.

Proprietary control systems work by collapsing all functional layers into a single vendor stack. The communication layer, the coordination layer, the application layer, the data layer, and the service relationship are bundled together and sold as one product. The lock-in is architectural. Each layer depends on the others in ways that make partial substitution expensive and full substitution prohibitive.

What open standards are doing is defining clean interfaces between those layers and allowing each to be addressed, evolved, and substituted independently. The structural analogy is what TCP/IP did to networking: it did not replace the hardware. It defined the interfaces that made the hardware substitutable. The question is not whether this is happening in robotics. It is which layers open up first, which resist longest, and what moves into the space between them.

The Protocol Stack Is Not One Thing

Most coverage of the open robotics transition treats the protocol question as a competition between alternatives. The reality is that different protocols solve different problems in different layers of the stack, and the mature architecture uses them in combination.

At the middleware layer, ROS 2 has become the default open reference architecture for much of distributed robotics software, especially where teams need modularity, simulation, perception, planning, and cross-vendor integration. ROS 2’s most common middleware implementations are built on DDS and IDL. DDS itself is a mature publish-subscribe middleware family used across demanding distributed systems, including industrial, automotive, defense, and aerospace contexts. DDS gives ROS 2 a publish-subscribe foundation with configurable QoS controls, designed for distributed state sharing, perception pipelines, and inter-process coordination. DDS also carries tradeoffs: discovery behavior, configuration complexity, and resource consumption can become pain points in high-bandwidth or multi-network deployments, especially when perception data must move beyond a local robot or cell.

The most serious open complement to DDS gaining momentum around ROS 2 deployments is Eclipse Zenoh. Zenoh addresses a problem DDS was not originally optimized for: unified communication across constrained edge devices, robot networks, and cloud-connected systems. Intrinsic has publicly backed Zenoh’s role around ROS 2 Jazzy Jalisco. Zenoh is not yet as embedded as DDS in the ROS 2 ecosystem, but it is a serious candidate for bridging ROS 2 systems beyond a local DDS domain, particularly in deployments where data must span edge and cloud infrastructure within a single coherent fabric.

Critically, in production industrial systems, neither ROS 2 nor Zenoh usually owns the certified servo and safety layer. High-frequency servo loops and certified safety functions usually remain below open middleware, in vendor controllers, drives, PLCs, and industrial Ethernet networks such as EtherCAT, PROFINET, and EtherNet/IP, with safety handled through certified mechanisms such as FSoE, PROFIsafe, or CIP Safety depending on the automation stack. This is the layer where the automation engineer’s question lands: how does your open stack talk to my physical safety PLC? The honest answer is that it orchestrates around it. ROS 2 does not replace the certified motion controller. It coordinates above it, using fieldbus bridge layers where necessary. The near-term shift is not open middleware replacing the PLC. It is open middleware surrounding and orchestrating it.

One layer up, OPC UA provides the structured information model for machine-to-machine communication and vertical integration into enterprise systems. The OPC UA for Robotics companion specification, formally OPC 40010-1, Robotics Part 1: Vertical Integration, provides a standardized information model for exposing robot asset data, state, and kinematics to plant and enterprise systems. This is not a task execution layer. It is an information modeling layer, designed to give plant-floor robot data the semantic structure that enterprise systems can consume without vendor-specific translation.

Then there is MQTT, which is doing something different from both. MQTT, the OASIS standard messaging protocol for IoT, is characterized by its lightweight publish-subscribe architecture, which reduces configuration overhead and requires less bandwidth to communicate across heterogeneous infrastructure. The emerging model pairs OPC UA inside the plant for structured, context-rich machine communication, with MQTT as the transport for data moving to dashboards, cloud analytics, and cross-facility systems. Sparkplug, governed under the Eclipse Foundation, adds a standardized topic namespace, payload structure, and state model to MQTT-based industrial systems. That does not make MQTT equivalent to OPC UA as an information-modeling system, but it makes MQTT substantially more usable as an interoperable IIoT transport layer than it was without it.

At the fleet coordination layer, VDA 5050 defines how AGVs and autonomous mobile robots communicate with fleet management systems regardless of manufacturer. Worth being precise: VDA 5050 is a master-control-to-vehicle interface, not a general robotics interoperability standard and not a vehicle-to-vehicle protocol. Direct communication between vehicles and decentralized traffic negotiation remain open technical challenges in mixed-fleet environments. Within its defined scope, Version 3.0, released March 2026, added planned path sharing between freely navigating robots and fleet management systems, and a zone concept for communicating traffic rules across heterogeneous fleets. In automotive and intralogistics procurement, VDA 5050 is increasingly becoming a procurement lever for mixed-fleet interoperability.

ROS 2 is becoming infrastructure, not the entire system, with commercial deployments combining open-source components with proprietary extensions in the layers above and below it. That is a near-term equilibrium. As layer interfaces stabilize, the pressure on proprietary bundles compounds from both directions.

The Layers That Will Resist Longest

The counterargument to the open stack thesis is that industrial robotics is not consumer computing. Safety certification, deterministic motion control, liability, warranty support, and uptime accountability all favor conservative control architectures. ISO 10218, updated in 2025, reinforces the point: robot safety is not just a controller feature. Part 1 addresses the robot as partly completed machinery; Part 2 addresses integration, commissioning, functional testing, programming, operation, maintenance, and repair. Open middleware does not erase those obligations.

This is why the transition will not look like open-source software replacing proprietary controllers. The certified control boundary does not vanish. Whether it lives in a cabinet, distributed drives, safety I/O, or embedded controllers, that layer remains conservative because it carries the liability. The proprietary controller becomes an encapsulated component inside a larger open architecture rather than the undisputed owner of the entire stack. It retains its certified function. It loses its position as the exclusive interpreter of what the system knows about itself.

That ordering is already visible in early adopter deployment patterns. Lock-in weakens first at the edges: fleet management, data visibility, simulation, task orchestration, analytics, and cross-vendor integration. The certified motion layer moves last. The proprietary stack does not disappear. It becomes an island, precisely defined, with open protocols governing everything around it.

Who Owns the Standard

The question serious operators should be asking is not whether open standards are gaining traction. They clearly are. The question is whether those standards have durable governance, or whether “open” is a positioning strategy that one company captures once the ecosystem matures.

The governance infrastructure here is more credible than a typical vendor-led interoperability campaign. The Open Source Robotics Foundation launched OSRA as a mixed-membership, meritocratic governance structure for ROS, Gazebo, Open-RMF, and related infrastructure. NVIDIA, Qualcomm, and Intrinsic joined as Platinum members, and NVIDIA has since contributed ROS 2 work around accelerated robotics and physical AI. OSRA governs OSRF projects through a Technical Governance Committee with distributed membership rather than any single company’s control.

VDA 5050 is governed jointly by the VDA and VDMA with active development conducted openly via GitHub. Eclipse Zenoh and Sparkplug both operate under the Eclipse Foundation. The ROS-Industrial Consortium adds a production-readiness layer with its own roadmap process and code quality standards.

This is not a loose GitHub project waiting to be captured by the first scaled commercial sponsor. The governance is institutional enough that capture becomes harder, more visible, and more contestable than it has been in prior industrial standards cycles.

Where the Business Logic Lands

Google’s thesis through Intrinsic is explicit: every machine, arm, or mobile unit currently requires specialized programming, middleware, and hardware-specific tuning, and abstracting that complexity into a unified operating layer is the commercial opportunity. Pichai has reportedly compared Intrinsic’s ambition to Android. The analogy is instructive, but the market dynamics are inverted from the original. Android succeeded because hardware OEMs wanted to escape building their own software stacks and welcomed a free OS. Established robotics OEMs, FANUC, Yaskawa, ABB, KUKA, view their proprietary software as their primary margin driver and lock-in mechanism. They are not waiting to be liberated. Intrinsic is not filling a vacuum. It is running an encirclement strategy against incumbents who are actively resisting abstraction.

The strategic logic underneath that strategy is worth naming directly. Flowstate is positioned as an all-in-one development environment for production-grade automation, with the broader ambition of making diverse robotic hardware programmable through a common software layer. By supporting and participating in OSRA rather than controlling it, Intrinsic helps strengthen the open foundation that lowers baseline engineering costs across the entire industry, effectively commoditizing the plumbing that competitors have used as a lock-in mechanism, while building proprietary monetization through Flowstate in the application layer above it. Worth being precise: Intrinsic acquired the for-profit arm of the Open Source Robotics Corporation. OSRF retained governance of ROS, Gazebo, and Open-RMF. Intrinsic participates in that governance. It does not control it. The Foxconn joint venture, focused on AI-enabled robotics for electronics assembly and factory orchestration, is the production-scale test case for that bet.

This is the platform move: open the interfaces below you, monetize the coordination layer above them. In that world, the scarce asset is no longer exclusive access to the controller. It is the ability to make heterogeneous machines useful, observable, and governable across their lifecycle.

The industrial integrators who move earliest to open-stack fluency are building a parallel position for the same reason. Not because OEMs will disappear, but because differentiation shifts from hardware alone toward integration, deployment, lifecycle support, and the assurance layer above the certified motion core.

The Harder Point

The open standards movement in robotics is often framed as a developer convenience story. Faster integration, reduced friction, lower mixed-fleet deployment costs. Those things are real and they matter.

But the more durable argument is about what the layered architecture does to information asymmetry.

The legacy business model of robotics OEMs was built on it. Only the vendor held the keys to the data stack. Diagnostics, performance telemetry, failure history, operational limit documentation: all of it sat behind proprietary interfaces, accessible only through vendor tooling, at the level of abstraction the vendor chose to expose. That asymmetry was not incidental. It was the foundation of the premium service relationship. Charge for the hardware, then charge again for every interaction with what the hardware knows.

Open standards do not eliminate proprietary value. They force a transition from the gatekeeper model to an assurance model. The operators building sophisticated autonomous fleets are increasingly constructing their own data infrastructure. The insurers and liability frameworks governing these systems are demanding auditable, vendor-neutral evidence chains. The regulatory and liability layer forming around autonomous industrial systems is likely to reward continuous, accessible demonstration of operational assurance, not point-in-time certification documents filed at the factory gate.

The companies that read that correctly are building positions in orchestration, observability, and assurance above the certified motion core. The ones holding the proprietary line are not doomed. Many will remain essential. But they are losing the ability to decide what the system is allowed to know about itself.

That is the real platform shift. Not robot versus robot. Not protocol versus protocol. Product becomes component. Protocol becomes leverage. Assurance becomes the business.

#robotics #industrialautomation #openstandards #ros2 #opcua #iiot #operationalassurance #manufacturingtechnology #autonomoussystems

Michael Entner-Gómez is a strategist, technologist, and writer focused on the convergence of the world’s most critical infrastructure sectors: energy, transportation, and telecommunications. Using a systems-thinking approach, he helps industry incumbents and disruptors future-proof their operations, scale complex platforms, and navigate the shift to software-defined everything.

This article is not sponsored, not paid, and not written to please. It’s written to inform.