Adaptiv Stratum
Menu
ConsultingIndustriesService BusinessesIndustrial & Applied TechnologyStructured ModernizationData AnalyticsVirtual AgentWhy Work With UsOur ApproachEngineering Leadership & StewardshipEngineering & Delivery StandardsPeople & AI ExpertiseCompanyClient Portal
Client portalTalk to us
← Engineering Examples

Sensors, IoT & Telemetry · Engineering example

Remote Asset Monitoring

Keep geographically distributed equipment understandable when power or communications are unreliable. Preserve event time, measurement quality, local alarms, and service context so a remote team can distinguish an asset issue from a missing signal.

Remote equipment measurements buffered locally and transported securely to a service review workflow

The operating challenge

A silent site is not a healthy site.

A utility, field-service organization, or industrial operator may supervise dozens of unmanned assets over cellular, radio, or intermittent broadband links. The central screen can show the last reading without showing that it is hours old. A lost connection, a dead sensor, a power interruption, and an actual process fault demand different responses. A trustworthy monitoring program keeps those conditions separate and preserves local control even when the network is unavailable.

Missing is not normal

When a site stops reporting, the central system no longer knows its current state. Reusing an old green status as if it were live can delay a field response.

Remote evidence is incomplete

Level, pressure, flow, vibration, or temperature may arrive late or out of order. Local maintenance and power events may explain the condition better than one measurement.

Dispatch has a real cost

Unnecessary trips consume technician time. A missed high-priority condition can affect service, safety, or the environment. Priority rules must reflect the asset and consequence.

Why modernize: Improve the context and reliability of remote decisions, not merely add a dashboard. The monitoring layer should make uncertainty and communications health visible while the asset's approved local protections continue to work.

Illustrative operating example

A lift station stops reporting during a storm.

This distributed-utility scenario is illustrative. It is not a claim about a completed customer installation, a spill, or a guaranteed improvement in response time.

Imagine a remote wastewater lift station whose level and pump-state updates normally arrive every few minutes. During a storm, the communications link drops. The last central reading showed a normal wet-well level, but that value is now stale. The local controller and its approved high-level protections must continue independently. The remote team needs to know whether the site has lost power, lost only its modem, or experienced a high-level event while the link was down.

  1. Identify what is still known.Show the last verified event time, heartbeat, local power status where available, and the approved alarm channel. Do not display the stale level as current.
  2. Protect the local operation.Existing pump controls, high-level alarm devices, and local emergency procedures remain in place. The analytical service neither overrides nor delays them.
  3. Classify the communications issue.Check modem and gateway state, power or battery status, carrier outage information if available, and neighboring sites. Separate network failure from sensor failure and process alarm.
  4. Use an approved response path.Operators apply consequence-based rules for check-in, alternate communications, or field dispatch. A model may help organize evidence but cannot authorize a risky remote action.
  5. Recover the event history.If local buffering survived, upload original event times and sequence after reconnection. Reconcile duplicate or delayed records, then document what actually happened and whether the escalation was appropriate.

What operations would see

Lift Station LS-4: telemetry unavailable

The last normal process reading is historical, not proof of current status.

Last verified state
Wet-well level and pump status with event time, age, and source quality.
Current uncertainty
Communications unavailable; local process state is unknown to the central viewer.
Safeguards
Local controller and approved alarm path remain authoritative; their availability is checked separately.
Response
Operator follows the site-specific continuity and dispatch procedure and records the finding.

Other high-priority situations

The same architecture helps very different field assets.

Remote compressor or generator changes behavior

Runtime, starts, temperature, fuel or energy, and maintenance notes can show a persistent deviation. Compare to operating mode and duty before creating a service request. A missing sensor cannot be treated as a normal temperature.

Useful report: asset mode, valid measurements, communications gaps, review reason, and technician finding.

Multiple sites lose power together

A regional outage may affect both equipment and communications. Group incidents by geography and timestamp while retaining each site's unique alarm and backup-power status. A common-cause hypothesis helps prioritize checks but does not prove each site safe.

Useful report: site-level last contact, power evidence, backup status, criticality, and confirmed field condition.

What a modernization would connect

Design for interrupted communications from the start.

The local controller and alarm architecture are the first boundary. A separate, approved read-only telemetry path can add context, event history, and service workflow. If the link fails, the site continues operating under its existing design; the central service declares the visibility loss plainly.

Required operating evidence

  • Site, asset, sensor, and controller identity
  • Event time, receipt time, sequence number, and clock quality
  • Process values and equipment state with explicit units and limits
  • Gateway power, modem health, link quality, and last heartbeat
  • Local alarms, backup power, maintenance, and field observations
  • Source, quality, and age of any last-known reading

Delayed records must retain their original event time, not appear as new faults at upload time.

Connected technical layers

  • Existing site controller and independently approved alarms
  • Read-only edge collection with bounded local buffering
  • Authenticated transport with replay and duplicate handling
  • Central historian, fleet view, and work-order or incident workflow

Remote access and network segmentation follow site security policy; monitoring does not imply permission to control the asset.

Local asset and alarmsTimestamped edge recordIntermittent transportCentral reviewField finding and closure

Show process condition, sensor condition, and communications condition as separate states. An unavailable link cannot be collapsed into either “all clear” or “asset fault.”

Where automation and AI fit

Automate confidence in the signal before predictive labels.

Deterministic automation

Check heartbeat age, sensor freshness, range and plausibility, power state, event ordering, and repeated alarms. Buffer records locally and reconcile them after reconnection. Route documented conditions through existing priority and on-call rules.

Analytical models

For assets with reliable history, compare behavior against similar duty and environmental conditions. Validate whether a trend gives useful advance notice beyond simple thresholds; avoid asserting a failure time from sparse remote data.

Evidence-linked AI assistance

An approved assistant can summarize the last verified state, outage timeline, similar site events, and outstanding questions for dispatch. It must separate observation from inference and never describe stale data as a current reading.

Human and local authority

Operators and qualified technicians decide response, dispatch, repair, and return to service. Existing local protection and approved alarm paths remain independent of the advisory service.

How we examine a proposed solution

AI advisors review resilience and evidence, not live control.

These Adaptiv Stratum AI advisory roles can support bounded research and design review. They are not field operators or a claim that named agents are installed at a customer site.

Argus

Challenges sensor identity, timestamps, edge buffering, and link health.

Aegis

Examines outage, alarm, power, and fallback failure modes.

Hephaestus

Reviews local controller separation and equipment interfaces.

Pythia

Tests whether trends add useful warning beyond transparent rules.

Clio

Checks incident reconstruction and measured response outcomes.

Themis

Challenges on-call authority, audit trail, and unsupported reliability claims.

What becomes visible

A fleet report must show both asset condition and visibility.

The site view supports a current operational response. The fleet view shows whether monitoring coverage, communications, and response practice are improving. Neither substitutes a stale reading for a live one.

Per-site event record

  • Asset and site identity, service criticality, and on-call owner
  • Last verified process state and age of each measurement
  • Alarm, sensor, power, and communications states separately
  • Buffered events with original timestamps and reconciliation status
  • Dispatch decision, field finding, action, and closure

Fleet measures

  • Telemetry availability and maximum blind period by site
  • Sensor faults, power events, and communications outages
  • Valid-data coverage and delayed-event backlog
  • Time from valid condition to operator acknowledgment and field action
  • False alarms, missed conditions, and repeat incidents
  • Backup-power and alternate-communications test results

A high percentage of delivered messages can hide a consequential multi-hour outage. Report the longest blind interval, priority of affected assets, and whether the independent alarm path worked.

Operating safeguards

Make communication failure visible without weakening local protection.

  • Site-specific consequence and alarm classification
  • Read-only analytics separated from local control and approved alarms
  • Explicit stale, missing, delayed, and unknown data states
  • Timestamp, clock-quality, sequence, replay, and duplicate checks
  • Bounded edge buffer and documented behavior when full
  • Power, carrier, and alternate-communications plans appropriate to the site
  • Authenticated connections and controlled remote access
  • Regular exercises of outage, restoration, and field response procedures

A practical first phase

Choose one important site and test what happens when the link fails.

  1. Define consequence.Identify the asset, critical alarms, response owner, and exact decisions that require a trustworthy remote view.
  2. Document the local system.Confirm existing controller, sensor, alarm, power, and communication paths before attaching a read-only collector.
  3. Prove the record.Validate point identity, event time, freshness, buffer capacity, and how service findings enter the history.
  4. Exercise an outage.Under an approved test plan, disconnect the analytical transport, observe local behavior, escalation, and replay, then confirm no silent “normal” status is shown.
  5. Judge readiness.Measure useful visibility, alert quality, operator response, and failure recovery before expanding to other sites.

Begin with one remote decision

Which site would worry you if it went silent?

One asset, its current alarm plan, and recent communications history are enough to frame a practical first review.

Discuss a remote-site question →

Evidence and further reading

Plan for a communications outage, not only normal telemetry.

These public primary sources inform the method. The lift-station situation above is illustrative, not an Adaptiv Stratum customer case study.