CONNECT. NORMALISE. TRUST.
Environmental Monitoring Data Integration Platform
RAUZ connects sensor, survey, environmental and remote-sensing data through a vendor-neutral layer that preserves provenance, normalises context and prepares trusted evidence for analysis and decisions.
Data Integration
One engineering view across different monitoring systems.
RAUZ Data Integration is an operational platform capability for connecting monitoring, survey, environmental, agricultural and remote-sensing information without forcing a project to replace useful field systems. The objective is not to collect more data. It is to preserve source, time, units, location, metadata and quality context so that different observations can be compared and used reliably.
Fragmented evidence
Projects often split information across logger portals, spreadsheets, survey files, environmental systems, satellite products, reports and contractor records.
Traceable integration
RAUZ retains provenance and project metadata while normalising the elements that must be comparable: identifiers, time, units, coordinates, references and project hierarchy.
Trusted downstream analysis
Integrated data becomes a controlled input for QA/QC, monitoring analytics, anomaly investigation, alert review, reporting and independent interpretation.
The Integration Problem
Different systems can describe the same physical problem without speaking the same data language.
A project may already have reliable instruments and experienced contractors, yet still lose engineering time reconciling timestamps, units, naming conventions, coordinate systems, baseline changes and disconnected data ownership. Integration should reduce that friction without erasing the meaning carried by each source.
Technical fragmentation
- Different timestamps and time zones
- Mixed engineering units
- Inconsistent sensor and location identifiers
- Separate coordinate or reference systems
- Manual and automated records in different formats
- Missing metadata or uncertain baselines
Project fragmentation
- Different contractors own different datasets
- Construction events sit outside monitoring platforms
- Survey and instrumentation are reviewed separately
- Environmental context is not aligned with engineering data
- InSAR products are delivered outside ground-monitoring workflows
- Reports are produced from repeated manual reconciliation
Data Sources & Interfaces
Connect the evidence the project already has.
RAUZ is designed as a vendor-neutral intelligence layer. Data can be received through agreed interfaces where the source system, ownership, permissions and technical format allow it. The specific connection route is defined project by project.
Instrumentation
Inclinometer, piezometer, settlement, tilt, crack, strain, load, vibration, water-level and other time-series monitoring records where available.
Survey & positioning
Total-station observations, GNSS, levelling, coordinates, reference points and spatial observations where the reference framework is known.
Environmental & field data
Weather, water, noise, vibration, air, soil, agricultural and other environmental observations appropriate to the project question.
Remote sensing
Satellite-derived products, including suitable InSAR ground-motion information, can be retained as a separate evidence source and compared with ground observations.
The OGC SensorThings API provides an open, geospatial-enabled model for managing and retrieving observations and metadata from heterogeneous IoT systems. MQTT is an open publish/subscribe transport protocol widely used in machine-to-machine and IoT contexts. RAUZ does not claim that every project must use either standard; they illustrate why clear interfaces and metadata models matter in mixed monitoring environments.
Engineering Data Model
Preserve provenance before normalising comparison.
The most important integration decision is not where the data is stored. It is how an observation remains traceable to its source and interpretable in the correct engineering, environmental and spatial context.
A practical information model
Data Quality & QA/QC
Integration should expose uncertainty, not hide it.
RAUZ uses the integrated layer to support repeatable data-quality checks before engineering interpretation. The exact rule set depends on the instrument, project, frequency, metadata and contractual monitoring requirements.
Completeness & continuity
Identify missing records, unexpected gaps, duplicate timestamps, flat-lines and interruptions that may affect trend or alarm interpretation.
Units & references
Check unit consistency, reference changes, baseline discontinuities and coordinate or datum issues before combining observations.
Source behaviour
Screen unusual jumps, impossible values, abrupt resets, sensor health indicators and other patterns that may require source verification.
Cross-source consistency
Compare neighbouring or complementary observations to see whether an apparent change is isolated, repeated or supported by independent evidence.
Metadata integrity
Retain instrument IDs, location, orientation, installation details, source ownership and processing history needed for defensible review.
Quality status
Keep quality findings visible downstream so a graph, alert or report does not silently treat uncertain input as verified evidence.
Integration Workflow
A controlled route from source data to engineering use.
The workflow separates connection, normalisation and QA/QC from later interpretation. That separation makes it easier to trace where a value came from, what changed during processing and how much confidence should be placed in the result.
Batch onboarding
Useful for historical monitoring datasets, spreadsheet archives, survey records, reports or project data that must be organised before review.
Recurring data flow
Suitable where project systems can provide scheduled exports, APIs, telemetry or another approved recurring interface.
Cross-Source Context
The platform should retain the physical context behind the numbers.
The same displacement or environmental change can have a different meaning depending on geology, stratigraphy, groundwater, climate, construction stage, asset geometry and measurement method. RAUZ therefore treats project context as part of the integration model rather than as an afterthought to the dashboard.
Geology & stratigraphy
Project-controlled ground information can be linked to monitoring zones, instrument depths or asset locations so that interpretation remains tied to the actual ground model.
Groundwater and environmental conditions
Water levels, rainfall, temperature and other relevant observations can be aligned in time where they are part of the project evidence and technically appropriate to compare.
Events and asset state
Excavation stages, tunnelling progress, loading, operational changes and other controlled records can be retained alongside monitoring data to support event-based review.
Applications
One integration layer, different engineering and environmental questions.
The architecture is intentionally cross-domain. The same principles—provenance, metadata, normalisation, QA/QC and traceable downstream use—can support infrastructure, environmental and agricultural monitoring without forcing every domain into the same measurement model.
Ground & infrastructure
Excavations, tunnels, rail, roads, bridges, slopes, dams, buildings and other monitored assets where multiple ground, structural and survey sources must be reviewed together.
Environmental monitoring
Water, weather, noise, vibration, air, site and environmental observations that may need to be related to assets, locations, events or compliance workflows.
Remote sensing
Satellite-derived ground-motion or other spatial products used as complementary evidence alongside site measurements and project information.
Agriculture & natural systems
Soil, weather, irrigation, microclimate and related field observations where the project needs consistent time, location and sensor metadata across distributed sites.
Industry Context
Open interfaces and mixed-source monitoring are already established industry requirements.
RAUZ does not present data integration as a unique idea. Mature monitoring and infrastructure platforms show the same underlying need: connect heterogeneous sources, preserve metadata and make information available for analysis and decisions. RAUZ differentiates itself by keeping the integration layer vendor-neutral and tied to independent engineering and environmental interpretation.
| Official source | What it demonstrates | Relevance to RAUZ |
|---|---|---|
| Bentley iTwin Sensor Data | Bentley documents REST APIs for third-party sensor and data-source integration, with connections, devices, sensors and time-series observations. | Shows why explicit interfaces, entity hierarchy and sensor metadata are fundamental to infrastructure data integration. |
| Sixense Beyond Monitoring | Sixense states that its monitoring platform integrates multiple sensor types, third-party sources and multiple formats for geotechnical, structural and environmental monitoring. | Confirms the industry need to consolidate mixed project evidence rather than manage each monitoring source in isolation. |
| OGC SensorThings API | The OGC standard provides an open, geospatial-enabled way to manage and retrieve observations and metadata from heterogeneous IoT systems. | Provides an official reference for interoperable sensor observations and metadata. |
| OASIS MQTT | MQTT is an open lightweight publish/subscribe transport protocol designed for machine-to-machine and IoT contexts. | Illustrates one possible telemetry interface class; RAUZ does not require all projects to use MQTT. |
| ESA Sentinel-1 | ESA documents radar interferometry as a method for detecting ground deformation across wide areas from repeat satellite acquisitions. | Shows why remote-sensing products may form a separate spatial evidence layer that must retain their own geometry and limitations when integrated with ground data. |
RAUZ Role
A vendor-neutral layer between measurement systems and technical decisions.
RAUZ does not need to replace a functioning logger, portal, instrumentation contractor or survey workflow to add value. The platform connects the evidence, preserves traceability and prepares it for the next layer: monitoring analytics, diagnostics, alerts, independent review and engineer-reviewed reporting.
Interface definition
Review available systems, source ownership, access methods, frequency, export options and metadata before defining the integration route.
Engineering data mapping
Map instruments, locations, assets, observations, project stages and criteria so integrated values retain engineering meaning.
QA/QC configuration
Apply repeatable checks appropriate to each source before the information is used in analytics, alerts or reporting.
Cross-source analysis
Enable comparison between monitoring, survey, environment, construction context and suitable remote-sensing evidence.
Downstream automation
Feed validated data into alert intelligence, automated reporting and AI-assisted review while retaining source traceability.
Independent interpretation
Keep observation, data-quality finding, automated result and engineering conclusion distinguishable in the review workflow.
Technical Boundaries
Integration quality is limited by source quality, access and context.
A defensible integration architecture states its limits. RAUZ defines interfaces and quality rules project by project because not every monitoring system exposes the same data, metadata, history or access method.
What integration cannot fix automatically
- Missing historical readings that were never recorded
- Unknown or undocumented baseline changes
- Incorrect sensor installation metadata
- Unstable survey references that were not documented
- Unavailable proprietary interfaces or access restrictions
- Project conclusions unsupported by adequate evidence
What must remain project-specific
- Geology, stratigraphy and ground model
- Groundwater and environmental conditions
- Construction and operational sequence
- Trigger values and contractual criteria
- Instrument performance requirements
- Local professional and data-governance requirements
Official References
Technical context from official public sources.
The references below are used to support the industry and standards context on this page. They are not presented as RAUZ project references or partnerships.
- Open Geospatial Consortium — OGC SensorThings API Standard ↗Official standard for open, geospatial-enabled management and retrieval of observations and metadata from heterogeneous IoT sensor systems.
- OASIS Open — MQTT Version 5.0 ↗Official MQTT standard describing the lightweight client-server publish/subscribe transport protocol used in IoT and machine-to-machine contexts.
- Bentley iTwin Platform — Sensor Data API Overview ↗Official Bentley developer documentation describing third-party sensor/data-source integration, connections, devices and sensors.
- Sixense — Beyond Monitoring Platform ↗Official Sixense page describing integration of sensor data from multiple sources, formats and third-party services for geotechnical, structural and environmental monitoring.
- European Space Agency — Sentinel-1 Instrument ↗Official ESA explanation of Sentinel-1 SAR and radar interferometry for monitoring surface deformation.
- RAUZ — Monitoring Analytics ↗Related RAUZ capability showing how integrated monitoring evidence is used downstream for analytics and interpretation.
FAQs
Common questions about monitoring data integration.
Does RAUZ require a project to replace its existing monitoring system?
What information is needed before data can be integrated?
Can RAUZ combine manual readings with automated data?
Can InSAR be integrated with ground instrumentation?
Does data integration automatically resolve abnormal readings?
Can the integrated data feed alerts and automated reports?
Where can RAUZ support projects?
Discuss Your Data Architecture
Start with the systems you already have.
Send RAUZ a short description of the existing monitoring sources, data formats, reporting workflow and the engineering or environmental question you need the integration layer to support. We can then define the interfaces, metadata, QA/QC and downstream outputs that should be discussed before a quotation is prepared.
1. Existing systems
List the instruments, loggers, survey sources, environmental systems, remote-sensing products and current software or reporting tools.
2. Available interfaces
Identify APIs, exports, databases, file formats, telemetry routes and data ownership or access constraints.
3. Required outcome
Explain whether the priority is QA/QC, analytics, anomaly investigation, alerts, automated reporting, independent review or a combination.