Why We Built for Brownfield Deployments, Not Greenfield

When we started building SensorVault, the first question was: who's the customer? The obvious answer is industrial facilities that want sensor-based monitoring. But "industrial facility" covers a huge range, and different parts of that range have very different problems.

A greenfield facility — new construction, built from scratch in the last few years — can specify a single sensor vendor, a single protocol, a modern cloud-connected control system, and a network architecture designed for IoT from day one. These facilities exist, and they're great projects. They're also maybe 5% of the total addressable market for industrial monitoring.

The other 95% are brownfield: facilities built in pieces over decades, with equipment from ten different manufacturers, three different control system generations, and a network architecture that evolved from "we added ethernet to the OT VLAN in 2009" rather than from a principled design. These are the facilities with the most acute monitoring needs — older equipment fails more unexpectedly, maintenance practices are often reactive rather than predictive, and the ROI on sensor monitoring is highest.

They're also the hardest customers to serve with a platform designed for greenfield assumptions.

What Greenfield Assumptions Look Like in Code

Greenfield-first platforms typically assume: a single sensor protocol (usually MQTT or a specific vendor's API), consistent timestamp formats (UTC ISO 8601), consistent engineering units from all sensors, reliable network connectivity with no need for local buffering, and a control system that can be configured to push data rather than requiring polling.

These assumptions simplify the platform enormously. If every sensor speaks MQTT with JSON payloads and UTC timestamps, normalization is trivial. If the network is always up, you don't need a buffering layer. If you control the sensor hardware selection, you can mandate a specific form factor and battery type.

The problem is that brownfield facilities break every one of these assumptions simultaneously. The Modbus RTU instruments from 1998 can't speak MQTT. The timestamps from the legacy SCADA historian are in local time with no timezone information. The pressure sensors report in bar while the flow meters report in gallons per minute. The cellular backhaul goes down for 4-6 hours during thunderstorms. The PLCs require polling — they don't push data.

A platform built on greenfield assumptions handles brownfield facilities with customization: someone has to write a Modbus adapter, handle the timestamp conversion, build a normalization layer, add local buffering. That customization work is expensive, takes months, and creates a system nobody understands how to maintain when the person who built it leaves.

The Decisions We Made Early

We made three foundational decisions in the first six months of development that shaped everything since.

First: protocol support is a core product feature, not an integration project. Modbus RTU/TCP, OPC UA, MQTT, BACnet, HART, 4-20mA, and the handful of other protocols that cover 90% of brownfield instrumentation — these are all built-in, not add-ons. We wrote the drivers, we maintain them, we test them. Customers don't write Modbus adapters. We already wrote the Modbus adapter.

Second: the edge agent runs offline-capable. Every deployment gets a gateway with local persistent storage and alert evaluation. If the WAN link is down, sensors still get monitored, alerts still fire locally, and data is buffered for upload when connectivity is restored. This was architecturally expensive — maintaining a consistent state between edge and cloud adds significant complexity. We paid that cost upfront because the alternative was a platform that stops working when the internet goes down, which is not acceptable in industrial operations.

Third: normalization is configuration, not code. We built a device profile system: each sensor type has a profile that specifies how to read from it and how to convert its output to canonical units and format. Adding a new sensor type requires a new profile file, not a code change. Over four years, we've built profiles for 200+ industrial sensor and instrument types. When a new customer shows up with a sensor we haven't profiled before, adding it takes hours, not weeks.

What Brownfield Actually Means in a Deployment

Let's be specific. A typical brownfield manufacturing facility we work with has: a primary PLC network running Modbus TCP to 80-120 instruments, a DCS on the process side with OPC UA connectivity, 20-40 aging sensors with no digital output at all (4-20mA only, requiring ADC conversion at the gateway), some newer wireless MQTT sensors that an operations engineer installed as a skunkworks project, and a building management system on BACnet. None of this is exceptional. This is normal.

Getting all of that onto a single monitoring platform with a single alert model and a unified dashboard requires handling all five integration paths. A greenfield-first platform handles one or two of them well and treats the others as professional services. We handle all five in the product.

The 4-20mA inputs are worth describing specifically because they're often overlooked. A massive amount of brownfield instrumentation outputs 4-20mA analog signals — the 4mA corresponds to 0% of the measurement range, 20mA to 100%, and the signal is proportional in between. These sensors have no digital interface at all. Getting their data into a digital monitoring system requires either an analog input module at the gateway that converts the current loop to a digital value, or a dedicated transmitter with a digital output. We support both paths. Many platforms don't support either.

The Operational Payoff

The decision to build for brownfield means our sales process is slower. We're often talking to operations teams that have had bad experiences with IoT platforms that couldn't handle their legacy equipment. There's skepticism to work through. Pilots matter more because teams need to verify that the platform actually handles their specific configuration before committing.

The payoff is that when customers go to production, they don't have a pile of custom integration code that degrades over time. The platform handles the hard parts. Their team manages configuration, not code. When they add a new building with a different protocol mix, they add it in the same way they added the first building, using the same tools and the same workflow.

Brownfield facilities aren't a niche. They're the industry. We built for where the industry actually is, not where we wish it was.