Remote geotechnical monitoring is not just a sensor connected to a dashboard. A typical arrangement has several stages: an instrument takes a measurement; a logger or acquisition device records or processes it; a communications path moves data onward; and a platform presents information to project users. Those stages can operate at different intervals and can fail in different ways. Campbell Scientific’s programming documentation, for example, distinguishes the measurement or scan interval from the interval at which data is stored to memory.1
For project teams, the practical task is therefore to define what the whole monitoring workflow must do before comparing hardware or platforms. That means agreeing the required measurement timing, data freshness, communications behaviour, reporting, notifications, access, retention and support, together with evidence that those requirements have been commissioned as intended.
How remote geotechnical monitoring works
A useful way to plan a remote monitoring system is to follow the data path from the field measurement to the person who uses the information. The exact components vary by project, but the interfaces between components matter because a reading can exist at one stage without yet being available at the next.
Sensors, data loggers and communications
The sensor or instrument measures the project parameter. A data logger, node or other acquisition device then reads that instrument according to its configured program. Depending on the equipment and configuration, the acquisition device may also apply calculations, store records locally and prepare data for collection or transmission.
Measurement and storage are separate settings. Campbell Scientific’s LoggerNet documentation defines the scan interval as how often the logger executes the measurement instructions, while the data output storage interval controls how often data is stored to memory.1 This distinction is important when a project requirement says only that data must be collected “every five minutes”. Does that mean the sensor is measured every five minutes, a value is stored every five minutes, or a stored value is transmitted every five minutes? Those are different requirements.
Communications can also have more than one stage. A field device may use a local radio network to reach a gateway, while the gateway uses another connection for onward transmission. Worldsensing’s 4G Rugged Gateway is one documented example: it uses LoRa/LoRaWAN for the radio side and provides 4G or Ethernet backhaul.2 That product architecture should not be treated as universal, but it illustrates why “wireless” does not identify the full communications path.
Monitoring platforms and project users
A monitoring platform can centralise readings, present dashboards, generate reports and support other configured workflows. MissionOS, for example, documents configurable dashboards and scheduled automatic reports.3 Those platform features are useful examples, but they do not establish how a particular project has been configured or what service levels apply to it.
The project brief should identify the people who need the information and what they need to do with it. A project manager may need a concise status view, while the nominated technical team may need instrument-level records, timestamps, reference information, exports and an audit trail of changes. The platform presentation should support those needs without hiding the underlying data context.
The system model is therefore not simply sensor → dashboard. It is better considered as:
measurement → local acquisition/storage → collection/transmission → processing/checks → presentation/reporting/notifications → review and response.
Each transition needs an owner, a defined requirement and a way to check that it works.
Measurement frequency, transmission intervals and data freshness
“Real-time” is too imprecise to be a complete monitoring requirement. A project can have frequent measurements but infrequent transmissions, or rapid transmissions of data that were sampled much less often. It can also have a current dashboard with one instrument that has stopped updating.
Taking, storing and transmitting readings
The timing requirements should be separated into the stages that can actually be configured and checked. Campbell Scientific’s documentation shows that a logger can use one interval for measurement and another for storage.1 Its CRBasic documentation also shows that local storage behaviour depends on configuration: data tables are normally organised as ring memory, where new records can overwrite the oldest once the allocated capacity is full, while a FillStop configuration stops storage when the table fills.4 That is one manufacturer’s implementation, but it demonstrates why local storage capacity and behaviour must be confirmed rather than assumed.
A remote monitoring brief should distinguish at least these terms:
| Timing term | What it describes | Requirement to agree |
|---|---|---|
| Measurement or scan interval | How often the instrument is read by the acquisition system | How often does the project need a measurement to be taken? |
| Storage or aggregation interval | How often a value or calculated result is committed to local/project storage | Are individual readings stored, averaged, sampled or otherwise processed? |
| Collection/transmission interval | How often stored information is transferred onward | How frequently should new records leave the field system under normal conditions? |
| Platform processing/update | When received data is processed and becomes available in the project system | What processing or validation steps occur before users see the data? |
| Data freshness | The acceptable age of the latest usable information | How old may the latest accepted reading be before the condition is considered stale? |
The values in this table are project decisions, not universal settings. They should be defined from the monitoring objective, the expected rate of change, power and communications constraints, the importance of timely review and the selected equipment’s capabilities.
Defining how current the information needs to be
Data freshness should be expressed in a way that can be observed. Useful questions include:
- What timestamp represents the measurement time, and is it preserved through the workflow?
- How does the platform show the latest successful reading for each instrument?
- How will delayed data be distinguished from newly measured data?
- When should a user be able to see that an instrument or communications path has stopped updating?
- What happens when delayed records arrive after connectivity is restored?
A dashboard labelled “real-time” does not answer these questions by itself. MissionOS documentation, for example, describes configurable dashboards and scheduled automatic reports.3 That describes presentation capability; it does not define the measurement interval, transmission latency, validation process or end-to-end availability for a particular monitoring arrangement.
For procurement and commissioning, a clearer requirement is usually something such as: define the maximum acceptable age of the latest usable measurement under normal operation, then specify how stale or delayed data will be identified. The actual value must be project-specific.
Choosing communications and planning for interruptions
Remote monitoring depends on both the field communications design and the onward path to wherever data is processed or viewed. The system should be specified for normal operation and for credible interruptions.
Local radio links and onward connectivity
LoRa/LoRaWAN, cellular and satellite communications can all be relevant to geotechnical monitoring, but they solve different parts of the problem and depend on site conditions, equipment compatibility and service availability.
A gateway can illustrate the distinction. The Worldsensing 4G Rugged Gateway uses LoRa/LoRaWAN for its field radio communications and 4G or Ethernet for backhaul.2 In another architecture, an instrument or logger may use cellular communications directly, or a local network may feed a site computer before data is sent onward. The project team should document the actual path rather than use “LoRa”, “4G” or “satellite” as shorthand for the whole system.
Questions to define include:
- Which devices communicate locally, and by what method?
- Where are gateways, repeaters or other intermediary devices required?
- What provides onward connectivity from site?
- What site survey, coverage check or installation test is required before acceptance?
- Which parts of the path depend on third-party communications services?
- How will loss of the local link be distinguished from loss of the onward connection?
A local radio link can be healthy while the internet or cellular backhaul is unavailable. Conversely, the platform may be accessible while one field node has failed. Those conditions should not be reported as the same fault.
Power, local storage and reconnection behaviour
A communications interruption does not necessarily mean measurements have stopped. If the sensor and acquisition system remain powered and have sufficient local storage, measurements may continue locally even though users cannot yet see them. If power fails, however, measurement can stop as well. If storage fills, the result depends on the hardware and configuration.4
The interruption plan should therefore specify:
- how field devices are powered and how loss of power is detected;
- what data is stored locally and for how long under the agreed configuration;
- whether storage overwrites old records, stops when full or behaves another way;
- what happens to queued records when communications return;
- whether data is transmitted automatically after reconnection or requires intervention;
- how duplicates, gaps or out-of-sequence records are handled; and
- how the project will recognise that information is missing rather than simply unchanged.
Do not assume “buffering” means unlimited recovery. Local storage is finite and product-specific. The acceptance check should use the selected hardware documentation and, where safe and authorised, a controlled test of the actual configuration.
Dashboards, data checks and reporting
A monitoring platform should make information usable, but visual presentation and data quality are different functions. A clean graph does not establish that every reading is valid, complete or correctly referenced.
Making readings understandable and traceable
For each monitored item, users should be able to identify what they are looking at. Depending on the project, that can include:
- instrument or sensor identity;
- location and, where relevant, depth or monitored zone;
- engineering units and measurement convention;
- measurement timestamp and latest-update status;
- reference, baseline or datum information needed to interpret the value;
- visible gaps, quarantined or suspect data where the workflow uses those states; and
- a traceable record of approved corrections or configuration changes.
Platform functions can support these controls, but they have to be configured. MissionOS’s current quality-management material, for example, describes centralised data validation and detailed audit trails.5 Those are vendor-described functions; they do not prove that a particular project uses the same rules or that the resulting data has received engineering approval.
The monitoring brief should state who reviews questionable data, what happens to a corrected record, and what evidence remains available to explain the change. That is especially important when automated calculations or transformations sit between a raw reading and the value shown to users.
Automated reports versus engineering interpretation
Automated reports can reduce repetitive administration. MissionOS documentation describes automatic report generation and configurable report/dashboard tools.3 However, a scheduled report is a delivery mechanism. It is not automatically an engineering assessment.
The project should define the difference between:
- automatic presentation — plots, tables, scheduled summaries or status views produced from configured data;
- data checks — automated or human checks intended to identify missing, suspect or inconsistent information; and
- engineering interpretation — review of the monitoring results in the context of the works, ground conditions, design assumptions, observations and the responsibilities of the nominated technical team.
If interpretation or technical commentary is required, it should be explicitly included in the agreed scope, with the reviewer and review frequency identified. A report should not imply engineering sign-off merely because it is generated by a monitoring platform.
Alert configuration and response responsibilities
An alert workflow has several distinct stages: a condition is evaluated, a notification is generated, a delivery channel attempts to send it, a recipient receives it, someone acknowledges or reviews it, and an authorised response may follow. The project brief should not collapse those steps into the single statement “alerts required”.
Threshold approval and notification settings
Thresholds should be traceable to the project’s approved monitoring or response framework. The monitoring system may implement them, but the system itself does not determine the engineering meaning of the values.
Platform documentation shows that configurable alerting features exist. MissionOS, for example, describes alarm functionality with SMS and email options in its Mission Monitor/Base System material.6 That capability should be treated separately from the project’s approved thresholds, recipient list and response procedure.
Before commissioning, confirm:
- who is authorised to approve the threshold values or logic;
- which measured or derived values the thresholds apply to;
- whether alarms use absolute values, rates, persistence or other configured logic;
- who may change thresholds or recipients;
- which channels are used for notifications; and
- what test demonstrates that the configured rules match the approved requirement.
Any test that generates notifications should be planned so it does not create confusion with genuine project alarms.
Acknowledgement, escalation and missing-data conditions
Notification generation is not proof of receipt, and receipt is not proof that the condition has been reviewed. The briefing should therefore define acknowledgement and escalation as operational requirements rather than assume they are inherent platform features.
Questions include:
- Is acknowledgement required, and where is it recorded?
- Who is the primary recipient for each type of notification?
- What happens if no acknowledgement occurs within the agreed project process?
- Are out-of-hours arrangements required, and if so, who is actually rostered or contracted to respond?
- Should missing or stale data create a separate condition from an engineering threshold exceedance?
- Who decides what action follows an alert?
Treat measurement exceedance, instrument failure, communications loss and stale/missing data as different conditions. They may all need visibility, but they do not have the same technical meaning or response.
Data access, security, retention and ownership
Remote monitoring creates an operational data service as well as a field instrumentation system. Access, hosting, retention and close-out should therefore be defined before deployment rather than discovered at the end of the project.
Who can view, export and change information?
Access requirements should reflect roles. Some users may need view-only access; others may need to export data, administer accounts, approve data changes or modify configurations. MissionOS documentation provides one example with differentiated Admin, Creator and Viewer user licences, data export to other programs and a data-handover option.7 The applicable platform and licence must be checked for the actual project.
Define at least:
- who creates and removes user accounts;
- what permissions are needed for different project roles;
- who may export raw and processed data;
- who may change instrument metadata, thresholds, calculations or other configurations;
- whether changes are logged and reviewable; and
- what data format is required for practical handover or independent analysis.
Cybersecurity requirements should be based on the selected platform, the client’s information-security requirements and the agreed hosting arrangement. Do not infer the monitoring platform’s hosting location or controls from the organisation’s public website hosting.
Backup, retention and access after project completion
Backup, retention and ongoing access are separate questions. A backup protects against certain data-loss scenarios; retention defines how long records are kept; and access determines whether users can still retrieve those records under the applicable licence or project agreement.
Maxwell GeoSystems currently states that MissionOS installations undergo a full daily backup under its backup policy.8 That is a vendor statement about its platform. It does not establish a TERRASENSE project-specific recovery point, retention period, restoration commitment or contractual recovery arrangement. It is also different from a general statement that data is “continuously backed up”.
The project brief should confirm:
- hosting arrangement and any required data-location constraints;
- backup method and frequency that apply to the selected service;
- tested recovery or restoration arrangements, where required;
- retention period for raw, processed and reporting records;
- what happens when a subscription or project licence ends;
- what data and configuration records will be exported at close-out; and
- who owns the project data and any derived project-specific information under the contract.
These decisions are commercial and technical requirements. They should not be inferred from a product brochure.
Commissioning, maintenance and support requirements
Installation is not the same as acceptance. Before handover, the project team should agree what will be demonstrated, recorded and reviewed so that the deployed system can be compared with the approved brief.
Agreeing acceptance checks before handover
Acceptance checks should be tied to the requirements already defined. A practical commissioning record might include:
- instrument and logger identification against the agreed schedule;
- confirmation of units, measurement timestamps and configured intervals;
- evidence that data reaches the intended platform or repository;
- confirmation that user access and required export functions work;
- review of the latest-reading/stale-data indication;
- authorised testing of reports and notification routes;
- a safe interruption/reconnection check where it is appropriate to the system and project; and
- handover of configuration records, manuals and agreed baseline/reference information.
The purpose is not to create a universal test script. It is to make each material requirement verifiable. If an interruption test could affect live monitoring or third parties, it should only be performed under an authorised commissioning plan.
Ongoing support and configuration changes
Once the system is operating, the project should know who maintains which part of it. That includes field instruments, power systems, gateways, SIMs or communications subscriptions, platform licences, user accounts and reporting configurations where applicable.
Also define how configuration changes are controlled. Changes to measurement intervals, threshold logic, recipients, units or processing rules can affect the meaning and availability of the data. The system should preserve enough record to identify what changed, when and by whom, and the project should know who is authorised to approve the change.
Support requirements should be specific rather than assumed. Confirm the support channel, applicable service period, fault-reporting process, expected records, responsibilities for site attendance, and what happens after the original monitoring duration is extended. Remote access does not remove the need for field inspection, maintenance or physical intervention when the equipment or site conditions require it.
Project briefing checklist for remote monitoring
Use the following matrix to turn the project requirements into an auditable briefing document. The second and third columns are deliberately not pre-filled with project answers: they should record the actual agreed condition and responsible party. Unknowns should remain visible until resolved.
| Requirement | Agreed value or condition | Responsible party | Evidence or acceptance check |
|---|---|---|---|
| Monitoring objective and instrument list | Define what is being monitored and which instruments/data sources are included | To be agreed | Approved monitoring/instrument schedule or equivalent project record |
| Measurement interval | Define how often each instrument is measured | To be agreed | Logger/configuration record checked against the approved requirement |
| Storage/aggregation interval | Define what values are stored and whether averaging or processing occurs | To be agreed | Data table/configuration review plus sample records |
| Transmission/collection interval | Define normal onward collection or transmission timing | To be agreed | Timestamp comparison during commissioning |
| Data freshness | Define the maximum acceptable age of the latest usable information and how stale data is shown | To be agreed | Demonstration of latest-reading status and delayed-data behaviour |
| Local communications | Define field links, gateways/repeaters and required coverage checks | To be agreed | Site communications test and as-installed records |
| Onward connectivity | Define cellular, wired, satellite or other backhaul and its dependencies | To be agreed | Connection test plus documented service/SIM/network arrangement |
| Power | Define supply, backup where required and low-power/failure indication | To be agreed | Power configuration and agreed failure indication demonstrated |
| Local storage during outage | Define capacity and full-storage behaviour for the selected equipment | To be agreed | Manufacturer documentation plus configuration review; controlled test if authorised |
| Reconnection and delayed records | Define how stored data is recovered, ordered and presented after an interruption | To be agreed | Controlled reconnect/recovery test where safe and authorised |
| Missing-data detection | Define how missing, stale or non-updating data is identified | To be agreed | Demonstrated gap/stale-data condition |
| Dashboard/presentation | Define required instrument IDs, locations, units, timestamps, references and status information | To be agreed | User acceptance review against the approved display requirements |
| Data checks and corrections | Define automated checks, human review, quarantine/correction process and audit trail | To be agreed | Demonstration using agreed test data or review procedure |
| Reporting | Define report contents, frequency, recipients and whether technical interpretation is separately required | To be agreed | Sample approved report and distribution check |
| Thresholds | Identify the approved source and authority for threshold values/logic | To be agreed | Configuration compared with approved threshold record |
| Notification channels | Define email, SMS or other channels and the intended recipients | To be agreed | Authorised test notification and recipient-list review |
| Acknowledgement and escalation | Define whether acknowledgement is required and what process follows non-acknowledgement | To be agreed | Agreed procedure and, if applicable, workflow demonstration |
| Out-of-hours response | Define whether any out-of-hours review is required and the actual responsible arrangement | To be agreed | Contract/procedure confirmation; do not assume 24/7 supervision |
| User access and permissions | Define view, export, administration and configuration rights | To be agreed | Account/permission review during handover |
| Hosting and security requirements | Define applicable hosting, client security and access-control conditions | To be agreed | Supplier/platform evidence matched to project requirements |
| Data ownership | Define contractual ownership of project data and derived information | To be agreed | Contract or approved data-management record |
| Backup and recovery | Define applicable backup and restoration requirements | To be agreed | Platform/service evidence and recovery test if required |
| Retention and close-out access | Define retention period, licence expiry treatment and required export | To be agreed | Close-out/export requirements recorded before deployment |
| Platform/licence/subscriptions | Define licences, communications subscriptions and renewal responsibilities | To be agreed | Commercial schedule or licence record |
| Commissioning acceptance | Define the checks and evidence required before handover | To be agreed | Signed/approved commissioning record for the project |
| Maintenance and support | Define field maintenance, platform support, fault handling and site-attendance responsibilities | To be agreed | Maintenance/support scope and contact process recorded |
| Configuration change control | Define who may approve and implement changes after handover | To be agreed | Change log and approval process demonstrated |
| Extended monitoring period | Define what changes if the project duration increases | To be agreed | Agreed extension process covering licences, communications, maintenance and access |
This matrix is a briefing aid, not a completed remote-monitoring specification. The technical team still needs to select appropriate instruments and system configurations for the project, while the procurement and delivery scope needs to identify who supplies and operates each part.
Discuss Your Project
If you are preparing a remote monitoring brief, bring the monitoring objective, known instrument requirements, site communications constraints, timing needs, reporting expectations and any unresolved responsibilities to the discussion. TERRASENSE can then scope the requested instrumentation and monitoring support against the project-specific requirements and agreed delivery scope.
Public references
-
Campbell Scientific. Step 4 – Set up Output Tables. Relevant sections: measurement or scan interval; Data Output Storage Interval. https://help.campbellsci.com/loggernet-manual/ln_manual/short_cut/step_4.htm. Measurement and storage intervals are logger-programming concepts; this does not define a project-specific monitoring interval.
-
Worldsensing. 4G Rugged Gateway. Relevant sections: overview and main technical specifications; LoRa/LoRaWAN radio communication and 4G/Ethernet backhaul. https://www.worldsensing.com/product/4g-rugged-gateway/. Product-specific architecture example, not a universal remote-monitoring design.
-
Maxwell GeoSystems. MissionOS Base System. Relevant sections: MissionOS Products, Mission Monitor and Canvas Sheets; dashboards, reporting and scheduled automatic reports. https://www.maxwellgeosystems.com/base-system/. Vendor-described platform capability; not evidence of a particular TERRASENSE deployment, licence or service level.
-
Campbell Scientific. DataTable/EndTable (Define Output Table) and FillStop (Stop Storage when Table Fills). Relevant sections: Size/ring-memory behaviour and FillStop remarks. https://help.campbellsci.com/crbasic/cr300/Content/Instructions/datatable.htm and https://help.campbellsci.com/crbasic/cr6/Content/Instructions/fillstop.htm. Configuration-specific Campbell Scientific behaviour; other loggers may handle full storage differently.
-
Maxwell GeoSystems. Quality Improvements. Relevant section: centralised data validation and detailed audit trails. https://www.maxwellgeosystems.com/benefits/quality-improvements/. Vendor-described capability; it does not establish the validation procedure or engineering approval status of a TERRASENSE project.
-
Maxwell GeoSystems. MissionOS Base System. Relevant section: Mission Monitor alarm functions with SMS and email options. https://www.maxwellgeosystems.com/base-system/. Platform functionality does not establish project thresholds, delivery guarantees, acknowledgement or response arrangements.
-
Maxwell GeoSystems. MissionOS Base System and How to Implement. Relevant sections: data export to other programs; User Licences (Admin, Creator, Viewer); Data Handover Option. https://www.maxwellgeosystems.com/base-system/ and https://www.maxwellgeosystems.com/how-to-implement/. Vendor-described examples. Actual permissions, export functions and licence terms must be confirmed for the selected project configuration.
-
Maxwell GeoSystems. System Assurance. Relevant section: Disaster Recovery; vendor states that MissionOS installations undergo a full daily backup. https://www.maxwellgeosystems.com/system-assurance/. Vendor statement only; it does not establish a TERRASENSE project-specific recovery point, retention period or contractual restoration commitment.