The Plant Floor Has a Visibility Problem. A New Community Wants to Fix It.

Most industrial operations run on a quiet contradiction. A modern plant or utility produces an enormous volume of data: sensor readings, process variables, equipment states, alarm events. Yet the people running those operations often have surprisingly little real-time visibility into what is actually happening. The data exists. It is just fragmented, siloed, and usually out of reach for the teams and systems that need it most.

That gap is the subject of a new independent white paper, Industrial Observability 2026: Trends, Challenges, and Opportunities, by Lukasz Ciukaj, an OpenTelemetry member and contributor, CNCF Cloud Native RTP organizer, and the founder of the newly formed OpenTelemetry Industrial community. It is also why that community now exists. This post looks at why industrial observability is so hard, why OpenTelemetry is a credible answer, and how a new community-driven initiative is organizing to close the gap.

Why industrial environments are hard to observe

The visibility problem is not a simple technology gap that a bigger monitoring budget can fix. It is the cumulative result of decades of engineering decisions made in an era when connectivity, analytics, and cybersecurity were not primary design considerations. Industrial systems were built to run reliably for twenty or thirty years. Observability was never in the specification.

That history shows up as a set of very concrete constraints, all of which the white paper documents carefully:

• Systems were designed for control, not telemetry. A PLC executing ladder logic at millisecond intervals has one job: reliably controlling a physical process. It was never meant to emit structured telemetry or join a centralized pipeline. The same is true of most DCS controllers, RTUs, and HMI platforms deployed before the mid-2010s.
• Legacy hardware cannot be easily modified. Much of the installed base runs on hardware and operating systems years or decades past vendor support. Vendor contracts often prohibit changes, and update cycles are measured in years, not weeks.
• Protocol fragmentation creates integration complexity. Modbus, DNP3, PROFINET, EtherNet/IP, OPC DA, BACnet: each has its own data model, addressing scheme, and timing characteristics. There is no universal adapter.
• Active monitoring can cause disruption. Scanning and polling are routine in IT. In OT, the same techniques can crash legacy PLCs or introduce latency into time-sensitive control loops. Passive approaches are often the only safe option.
• The network was never built for visibility. Architectures shaped by the Purdue Model were designed for segmentation and control. The deeper you go toward Level 1 and Level 0 devices, the less most organizations can see.

The white paper makes a point that anyone who has worked in a plant will recognize: the "don't touch it" culture among OT engineers is rational, not obstinate. The cost of an instrumentation-related disruption to a running process frequently exceeds the perceived benefit of the monitoring being added. Changing that calculus means demonstrating value incrementally, with approaches that carry minimal operational risk.

Why this matters now, and not just to engineers

The stakes are rising because the ambitions placed on industrial infrastructure have never been higher. Siemens' True Cost of Downtime report estimates unplanned downtime costs the world's 500 largest companies roughly $1.4 trillion annually. CISA identifies asset visibility as a foundational capability for OT cybersecurity, because you cannot secure what you cannot see. And every Industry 4.0 ambition leadership is funding today, whether that's predictive maintenance, AI-driven optimization, or digital twins, shares one dependency: reliable, continuous, well-structured data from the operational environment.

That is the modernization dilemma in a sentence. Organizations are being asked to build advanced analytical and AI capabilities on top of infrastructure they cannot fully observe. The ambition is real. The foundation is incomplete.

Why OpenTelemetry fits the problem

Most observability tools solve one slice of the problem: a specific protocol, signal type, or backend. OpenTelemetry is different. It addresses the telemetry pipeline as a whole, with vendor neutrality as a core design principle. That architecture fits the OT challenge unusually well, because the OT challenge is mostly one of heterogeneity and fragmentation.

The key is the OpenTelemetry Collector and its receiver–processor–exporter model. A single Collector deployment can ingest data from an OPC UA server, a Modbus gateway, and a Prometheus endpoint at once, normalize everything into a common data model, and route it to a SIEM, a time-series database, and a cloud analytics platform in parallel, all without requiring a single legacy device to change. The receiver absorbs the protocol complexity so the rest of the pipeline does not have to. As the white paper frames it, the goal is translation, not replacement: meet each system where it is, and create one common language at the pipeline, not at the source.

OpenTelemetry brings three more things OT badly needs: vendor neutrality that reduces long-term lock-in, a unified model across metrics, logs, and traces that makes cross-signal correlation possible, and semantic conventions, a path toward telemetry that is not just collected but consistently understood across sites. The adoption numbers back this up: per CNCF's 2026 survey, OpenTelemetry has reached 49% production adoption with another 26% of organizations evaluating it.

Promising, but early. That's the opportunity.

Here is the honest assessment the white paper offers, and the reason a community is forming. OpenTelemetry's core framework is production-ready and widely deployed in IT. Its application to industrial environments is active but still developing, driven largely by individual contributors and isolated integration efforts rather than coordinated, community-wide work.

As of June 2026, no OpenTelemetry SIG exists for industrial environments. There is no working group coordinating an industrial roadmap, no shared ownership of the protocol receivers, semantic conventions, and deployment patterns that accelerated OTel in other domains. Industrial-specific semantic conventions (for engineering units, process variable types, equipment hierarchies, alarm states, quality codes) are still nascent. What exists today is real but scattered: experimental Modbus and OPC UA receivers, a production Sparkplug B receiver from the Caspar Water project, an MQTT-to-OTel bridge, and the stable filelog receiver in official contrib.

This is not a criticism of the OpenTelemetry community. It simply reflects where industrial observability sits on the adoption curve. And it is exactly the kind of foundational work that compounds in value across every deployment that adopts it.

Introducing the OpenTelemetry Industrial community

That is the gap OpenTelemetry Industrial (github.com/otel-industrial) is organizing to close. It is a community-driven initiative focused on OpenTelemetry adoption across industrial, manufacturing, OT, IoT, and legacy environments. Its mission is to advance observability, cybersecurity resilience, and standards-based modernization through open technologies and shared knowledge.

One clarification worth stating plainly: this is an independent community initiative. It is not an official OpenTelemetry project, SIG, working group, or CNCF organization. But it collaborates with the broader OpenTelemetry community and welcomes contributions from practitioners, maintainers, vendors, and end users alike. It is a place to share implementation experiences, document existing projects and integrations, discuss industrial requirements, and connect people working on the same hard problems.

If your work touches the plant floor, the IT/OT boundary, or industrial telemetry, here's how to get involved:

• Join the #otel-industrial channel on CNCF Slack
• Attend the monthly community call focused on industrial OTel use cases
• Explore the community and resources repositories at github.com/otel-industrial
• Share your projects, use cases, receivers, and lessons learned

The standards to move telemetry through the industrial stack increasingly exist. Making that telemetry consistently meaningful, and building the receivers, conventions, and reference architectures that get us there, is work no single vendor or engineer should have to do alone. That is what a community is for.

This post draws on Industrial Observability 2026: Trends, Challenges, and Opportunities (v1.0, June 2026) by Lukasz Ciukaj.