Every lab digitization project eventually meets the same wall: which of these hundreds of instruments can we actually get data out of, and how hard will each one be? The vendor demos never answer it, because the answer isn’t about any single instrument — it’s about the chain of boxes between the instrument and the place the data needs to live.
We built the answer into one place. Our Digital Lab: Equipment & Integration Map catalogs 426 instruments from 154 vendors across 46 categories, and rates each one on how it really moves data: file export, REST or SOAP APIs, OPC-UA, or a proprietary format with no API at all. It’s free to browse and filter.
The delay is in the chain of boxes, not the sensor
A digital sensor is not automatically an OPC-UA or MQTT sensor. In nearly every real architecture, the probe still reaches the data layer through a chain of intermediaries: a transmitter, a converter, a gateway, a PLC, or a SCADA system. Building and validating that chain is where the integration hours quietly add up.
That changes what you should actually be evaluating. The measurement quality of a given probe is rarely the deciding factor in a digitization program. The number of boxes and protocol hops between that probe and your data layer is. Two labs can buy the identical instrument and land months apart on integration, purely because of the architecture they wrapped around it.
How hard the 426 instruments are to connect
Score all 426 instruments on integration effort and the distribution is more forgiving than most teams expect.
- 231 are easy to connect. Reachable through file export, a documented REST/SOAP API, or a standard protocol, with no custom work.
- 137 need real engineering time. Reachable, but only through a driver, converter, or configuration step someone has to build and validate.
- Only 58 are genuinely hard. Proprietary formats with no API — the instruments that actually justify the worry, and the ones vendor demos never mention.
Plain file export alone still covers 351 of the 426 instruments. REST and SOAP APIs cover another meaningful slice, and OPC-UA a smaller but growing one. Modern standards like SiLA2, OPC-UA LADS, and MQTT are emerging alongside the older ASTM and HL7 formats that still run most of the floor. Most instruments can expose their data. The truly proprietary, no-API cases are the minority — but that minority is exactly where the cost and the timeline hide, because it’s the one category a standard connector can’t absorb.
Three mistakes that stall these programs
The same three show up again and again, and none of them is a hardware problem:
- Treating integration as one undifferentiated task. This over-budgets the easy 351 and under-budgets the hard 58 — the average hides the outlier that actually blows the timeline.
- Starting with the hardest, most proprietary instruments to “prove the concept.” It’s the worst possible first project: maximum risk, minimum early confidence, and no reusable pattern to show for it.
- Building each connection as a bespoke, one-off bridge that never gets reused on the next vessel, the next line, or the next site — so the same work gets paid for again every time.
Connect the easy instruments first
For the categories we know best, we ship connectors covering 73 instruments across 8 categories, with documented know-how on 7 more — see our lab system integration work for what that looks like on a live, multi-vendor lab ecosystem. Our advice is the one the map itself encodes: start with the quick-win categories, prove the data flows end to end, then extend across the harder, proprietary long tail once the foundation holds. That sequencing is also the core of our Digital Lab approach — assess what you actually have before committing to how you’ll connect it.
What to do about it
Lab digitization stalls between the sensor and the system, not at the sensor. Rate every instrument separately instead of budgeting them as one block, map each one to how it actually moves data, connect the easy ones first, and build every connection so the next instrument can reuse it.