Worldsensing Alternatives for Wireless Geotechnical and Structural Monitoring Programmes

Why monitoring programmes start looking for a Worldsensing alternative

The most common trigger has nothing to do with the sensors. On construction and infrastructure projects, the instrumentation and monitoring contractor typically owns the hardware account and the platform subscription. The asset owner gets a login while the works are live and a stack of reports when they finish. Then the contract ends, the account closes, and two years later somebody asks what the settlement trend looked like during excavation and the honest answer is that it exists as a series of portable document files. For a structure with a fifty year life that is a poor outcome, and it is the single strongest reason owners start looking at their monitoring stack differently.

The second trigger is heterogeneity. Real monitoring programmes rarely stay on one ecosystem. There are wireless nodes on this section, a legacy cabled logger on the older structure, automated total stations from a survey contractor, manual readings taken by hand on the instruments nobody has automated, and a piezometer network installed by whoever built the thing in 1994. Each arrives with its own software. The engineer responsible for the whole asset has to reason across all of it, and reasoning across four portals is not reasoning.

The third is the shape of the deployment. Low power wireless is an excellent answer where cabling is impractical, and it comes with the constraints that go with radio: gateway placement matters, reading frequency trades against power, and dense structures and deep tunnels are harder environments than open ground. None of that is a defect, but it does mean your monitoring density and cadence are engineering decisions rather than software settings, and teams sometimes discover that during a project rather than before it.

What Worldsensing genuinely does well

The hardware problem it solves is a real one. Installing cable across a live railway, a working tunnel, an operating mine or a slope you cannot easily reach is expensive, slow and sometimes impossible, and cables get cut. Low power wireless nodes that sit out in the field for extended periods without intervention, connecting a broad range of standard geotechnical sensors, remove the largest practical obstacle to instrumenting difficult places.

Two more things deserve credit. It works with sensors from many manufacturers rather than forcing a single brand, which matters because geotechnical instrumentation is a fragmented market and you inherit whatever the previous engineer specified. And the ecosystem is designed with the expectation that data will flow onward into other platforms, which sounds unremarkable and is actually the right architectural posture for this sector. Hardware that assumes it owns your data is far more troublesome over an asset lifetime.

Where it actually strains

• The software layer is deliberately not the destination. It shows you your network and your readings well. It is not built to be the long term system of record for an asset owner, and using it that way exposes the limits quickly.
• Multi source consolidation. Manual readings, automated survey, older cabled loggers and third party contractor data all need to sit in the same picture with consistent instrument identity, and that consolidation is work no hardware vendor does for you.
• Radio planning is real engineering. Gateway coverage, node placement, reading frequency and power budget interact, and changing your mind about reading cadence after installation is not free.
• Per node economics across large programmes. When a scheme runs to hundreds of instrumented points, unit costs and any associated data charges become a line item worth modelling across the full programme duration rather than the first year.
• Account ownership. If the account sits with a contractor, so does the continuity of your data, and that is a commercial arrangement rather than a technical limitation, which is precisely why it gets overlooked until it matters.

Option one: stay, and fix the contract instead of the software

For a large share of readers the fix here is not a purchase at all. Change the specification. Require that the asset owner holds the platform account and grants the monitoring contractor access, rather than the reverse. Require raw data delivery in an open format on a defined schedule, not just reports. Require instrument metadata, installation records, calibration details and coordinates as deliverables. Those clauses cost nothing at tender and are worth more than any tool you could buy afterwards.

Stay entirely as you are if you run one project with one contractor, the reporting is good, and the structure will not be monitored after handover. Building an owner side platform for a single short scheme is overhead you will not recover.

Option two: switch hardware ecosystems

If the hardware genuinely is the problem, the alternatives are credible and specific. Senceive is well known in wireless remote condition monitoring, particularly around rail and structures. Geokon, RST Instruments, Sisgeo and Encardio Rite are established instrumentation manufacturers with their own data acquisition and software offerings. Campbell Scientific remains the reference point for programmable cabled data logging where power and cable runs are practical. Move Solutions and similar newer entrants target wireless structural monitoring with different form factors.

Judge a hardware switch on installation environment first, sensor compatibility second, and software last, because the software is the part you can replace later and the nodes are the part that will be grouted into a borehole. Also consider who supports it locally. Instrumentation programmes fail on maintenance and replacement lead times more often than on specifications.

Option three: build the owner side data layer

The build worth doing is deliberately hardware agnostic. Its job is to be the thing that outlives contractors, projects and vendor decisions. In practice that means ingesting from any source, wireless gateways, cabled loggers, survey exports, manual reading sheets and contractor feeds, into one store with consistent instrument identity and coordinates; holding the metadata that makes readings defensible, including installation records, calibration, conversion factors and their version history; managing trigger levels with approval and attribution; running the response workflow when a level is crossed, with acknowledgement, escalation, inspection and closure; and producing the reporting your engineers, your client and your regulator each need from one dataset.

Build this when you are the asset owner rather than the contractor, when monitoring will continue past handover, when you run multiple concurrent schemes with different contractors, or when instrumentation data feeds decisions with real money attached such as construction sequencing, dewatering or slope management. The payback is partly time and mostly risk: the ability to answer a question about historical behaviour years later, with evidence, without depending on a company you no longer have a contract with.

Cost bands and timelines

Framed against Digital Heroes delivery experience: a focused owner side data layer covering multi source ingestion, the instrument register, trigger levels and reporting runs roughly $40k to $110k over 10 to 14 weeks. A full monitoring platform adding response workflow, portfolio views across schemes, client and stakeholder access, and integration with asset management or building information systems runs roughly $140k to $320k. Because it is hardware agnostic by design, the same platform serves your next scheme with a different instrumentation supplier at no additional licence cost, which is where the economics diverge from per project subscriptions.

Migration reality

Moving the data is usually straightforward and moving the meaning is not. Readings export cleanly enough. What breaks is identity: the same instrument named three ways across a survey schedule, a contractor's platform and a drawing register, with coordinates in two different systems and a datum change nobody documented. Budget real time for reconciling instrument identity before you load anything, because a monitoring database with ambiguous instrument identity is worse than no database.

If you are changing hardware rather than software, remember that installed nodes are effectively permanent on many schemes, so plan for a hybrid estate rather than a cutover, and make sure your data layer treats old and new sources as equals. If a contractor holds the current account, start the export conversation while the relationship is live and the contract is running, not during demobilisation. Data access after a contract closes is a negotiation you will lose.

The honest verdict

Keep the wireless hardware if it is installed and reporting, because the installation is the expensive part and swapping ecosystems mid programme rarely pays. Switch hardware only for installation environment or sensor compatibility reasons, and choose on local support as much as specification. Build the owner side data layer whenever the asset outlives the contract, which for infrastructure is almost always. Own the record, the metadata and the response process; let the nodes, the gateways and the contractors change around it.