Frequently Asked Questions
What is NeoSensors?
A hardware-and-software platform for continuous pipeline monitoring. Wireless IoT pressure sensors (plus optional flow and temperature) are placed along the right-of-way and transmit over a LoRaWAN network to a cloud platform. The platform analyses the live measurement stream with four independent algorithms in real time to detect, classify and locate leaks and unauthorized taps, and also builds thermal profiles and forecasts. In effect it's a low-cost computational monitoring (CPM) layer that adds real-time leak detection to liquids, gas and water systems — and a documentation trail that supports your leak-detection program.
Which pipelines does it cover?
Crude and refined-product lines, natural gas, gathering systems, water transmission and distribution (AWWA networks), and district energy. For each fluid the system uses its own physical model — density, bulk modulus, acoustic wave speed, viscosity-temperature behaviour. This matters because the same pressure drop means a different leak size in oil, gas and water, and the wave speed that drives localization accuracy differs substantially between them. Pipe parameters (diameter, wall thickness, material, roughness) are defined per segment, so detection is tuned to the actual line rather than a generic setting.
How fast does it detect a leak?
It depends on the sensor mode. In event-driven mode the sensor itself reacts to abnormal pressure dynamics and transmits immediately — NPW detection takes under a minute. In periodic mode (transmission every 1–15 minutes) detection time equals the transmission interval times a leak-size factor: a rupture is caught in half a cycle, a small leak over several cycles (for statistical confidence). The practical trade-off: critical points run event-driven (fast, slightly higher battery use), low-risk segments run periodic (longer battery life). A single sensor can run periodic but "wake up" into event mode on a deviation — a flexible way to meet response-time expectations across a large system.
What detection methods are used?
Four independent methods combined by a decision-fusion engine: NPW (Negative Pressure Wave — fast localization of ruptures and taps), hydraulic gradient (comparing the measured pressure profile against a Darcy-Weisbach calculation), mass balance (reconciling inlet vs outlet flow — catches slow leaks), and an AI/ML anomaly model (Isolation Forest — flags unusual patterns the formulas don't describe). This is a multi-method CPM approach in the spirit of API 1130. Each method returns its own 0–1 confidence, fused with weights. The point of multi-method is cross-confirmation: any single method can false-trigger on water hammer or a pump switch, but independent agreement of two or three sharply cuts false alarms while widening the detectable range — from an instant rupture to a slow weep — which is exactly the reliability/sensitivity balance an API 1175 program targets.
How does the NPW method work?
When a leak starts, fluid suddenly escapes and pressure drops sharply at that point, creating a rarefaction (negative pressure) wave that travels both ways along the pipe. Its amplitude follows the Joukowsky equation (ΔP = ρ·c·Δv), and its propagation speed c follows the Korteweg formula (accounting for the fluid's bulk modulus, pipe diameter and wall elasticity) — roughly 3,000–4,300 ft/s in steel/liquid lines. Adjacent sensors register the wave's arrival at different instants; from the time-difference-of-arrival and the known wave speed, the platform triangulates the leak location. The method is accurate because it relies on the physics of wave propagation rather than indirect symptoms: the wave arrives within fractions of a second, and with well-synchronized sensors the localization error is a few percent of the segment length.
How accurate is localization?
Typically ±1–3% of the sensor-to-sensor segment length — about ±0.06–0.18 mi over a 6 mi span. So a crew is dispatched to a defined zone, not "somewhere along miles of right-of-way." Four factors drive it: sensor density (closer spacing → tighter zone), time-synchronization accuracy (the method is sensitive to milliseconds), wave-speed fidelity (depends on correct pipe and fluid parameters), and signal attenuation (amplitude falls over long spans). The Digital Twin module shows the expected accuracy per segment in advance and suggests where to add a sensor to move a "fair" zone into "good."
What leak size can it detect?
It depends on diameter, operating pressure (PSI), sensor spacing and the method mix. Ruptures and unauthorized taps producing a drop of roughly 15 PSI or more are caught reliably by NPW. Large-diameter lines produce a smaller drop for the same hole, so their threshold is lowered or sensors are added. Small leaks (0.1–0.5% of flow) barely create an NPW wave, but mass balance catches them: with inlet/outlet meters the system accumulates the imbalance and triggers once it significantly exceeds the noise. So NPW covers fast events and mass balance covers slow weeps; together they span the full range. The Digital Twin computes the minimum detectable leak per zone for your configuration — useful evidence for a leak-detection design.
What is the adaptive threshold and why does it matter?
Fixed, manually-set thresholds were the old way — too low on noisy lines (false alarms), too high on quiet ones (missed small leaks). The platform now continuously learns each sensor's normal pressure noise — the standard deviation (σ) of sample-to-sample changes over a rolling window (default 48 h) — and computes the threshold per sensor: effective threshold = max(instrument floor, k·σ), where k is the sensitivity factor (default 5σ, recommended 4–6σ). A quiet sensor gets a low threshold (catches small drops); a noisy one gets a higher threshold (ignores its own swings). A key safeguard: windows of already-confirmed leaks are excluded from learning, so a real incident can't inflate the threshold and teach the system to ignore it. Sensitivity is one slider, and a calibration table shows the learned σ and effective threshold per sensor — supporting the documented, tunable detection-reliability expectations of API 1175.
How often are there false alarms?
Rare — and not by luck, but by design, which keeps operator call-out fatigue down. After a detection the system watches pressure for ~10 more minutes and runs auto-verification: did pressure recover, do neighbouring sensors correlate, what does the AI/ML model say? Pump switching, water hammer and valve operations show a characteristic signature (fast recovery, locality) and are classified as "false alarm" or "needs investigation" rather than escalating to an incident. Your decisions then train the system: marking an event false feeds that pattern back, and if a pipeline's auto-confirmations get overturned several times, the system stops auto-confirming there and routes events to manual review. The goal is an operator who responds to trustworthy signals instead of alarm fatigue.
Why LoRaWAN?
LoRaWAN is a low-power, long-range network (miles per gateway) on the unlicensed US915 band. For gathering systems, water mains and remote rights-of-way it solves the core pain of wired systems: a sensor needs neither a comms cable nor mains power — it runs on a battery for years. One gateway covers a large stretch of the line, and the LoRa modulation is robust to interference. Cellular NB-IoT is also supported where coverage exists.
What is the sensor battery life?
About 5 years at a 15-minute transmission interval. Battery life scales linearly with transmission frequency: transmit more often, drain faster. So critical points stay event-driven (transmit only on deviation — economical and fast) and the rest run periodic at a sensible interval. The Digital Twin calculator shows the "detection time ↔ battery life" trade-off so you can pick the balance.
Does it need cabling or power to each sensor?
No. Sensors are fully autonomous: battery plus the LoRaWAN radio link. The only requirement is LoRaWAN gateway coverage along the route; one gateway serves a large stretch. This dramatically lowers capex and installation time versus wired or fibre-optic systems, especially on live and hard-to-access lines.
Can it integrate with existing SCADA?
Yes. Today, data ingestion is available via REST API — point or batch: temperature, pressure, flow and other parameters from your SCADA enrich the calculations with real field measurements (useful, e.g., for thermal computations and cross-checks). Direct industrial connectors for OPC UA and Modbus (where the platform subscribes to SCADA tags itself, with no intermediary) are on the roadmap and not yet implemented — we keep a clear line between what's shipping and what's planned. For Enterprise on-premise deployments, the connector runs inside your own network.
How does it support regulatory compliance?
It's a computational monitoring layer aligned with API 1130 (CPM) and supports an API 1175-style leak-detection program (the LDR — Leak Detection Reliability — framework). Automatic event reporting — time, method, confidence, coordinates — plus an operator-action audit trail help document detection performance for PHMSA under 49 CFR Part 195 (hazardous liquids) and Part 192 (gas). The system doesn't replace your O&M procedures or your control-room management plan — it provides the tool and the evidence base showing who responded to an incident, when, and how.
How is a leak shown on the map?
Every route node carries coordinates (lat/long), chainage and burial depth, and segments between nodes have their own properties. On an event the platform doesn't just "light up a sensor" — it computes the probable leak location (by NPW triangulation) and highlights the zone on an interactive, GIS-referenced map, with chainage and nearest nodes/equipment. That immediately gives the crew a dispatch point and context (which valve, which section, what depth).
How is data secured?
Role-based access (owner / manager / monitor) with a full audit log, hosted on North American cloud infrastructure; the owner who verified the organization's domain is protected from being changed by other administrators. Privacy and data-handling follow CCPA/PIPEDA practice (see our Privacy Policy and DPA). For operators who require it, an Enterprise on-premise option deploys via Docker inside your own network, so data never leaves your perimeter.
Is there a digital twin for design?
Yes, and it's a key module. Digital Twin computes — before any hardware is installed — coverage zones and their quality, NPW attenuation blind spots (where the wave decays below threshold and a leak wouldn't be detected), optimal sensor placement and transmission intervals for a target detection time, and a battery-life estimate. A built-in emulator replays leak scenarios of various sizes and shows how the system would respond. The practical value: you design sensor layout deliberately (where and how many, to cover the whole route with no blind zones) instead of trial-and-error on a live asset — and you can justify the configuration to management or a regulator with numbers.
Does it handle cold-weather and thermal risk?
Yes. For water mains and district-heating lines it builds a thermal profile (fluid temperature distribution along the route, accounting for insulation, burial and weather, fetched automatically by coordinates), flags freezing-risk zones, computes time-to-freeze on shutdown, and for heated oil lines analyses rheology: viscosity vs temperature (Walther equation), pour point and Wax Appearance Temperature (WAT). This enables pre-emptive action — start trace heating or raise throughput before a section freezes — rather than dealing with a frozen or congealed line after the fact, valuable for northern US and Canadian operations.
What are the deployment options and cost?
Cloud SaaS with self-serve onboarding and tiered subscriptions (Monitor / Detect / Professional), billed by pipeline length — start on a free trial and define your route in the platform. For larger operators, an Enterprise on-premise option deploys via Docker inside your own network (data never leaves it), with installation support, SSO/LDAP, custom branding, SCADA integration, a 99.9% SLA and dedicated support. We'll scope an exact quote for your system and operating profile.
How do we start?
The path is simple. You define the pipeline in the platform (route on the map, nodes with coordinates, segments with characteristics), place sensors — physically, or first in the Digital Twin to verify coverage — and monitoring begins. We recommend a representative 10–30 mi section to start: enough to see real statistics within a month (events, false alarms, detection time) and judge the impact before scaling to the full system. Sign up for a free trial or request a guided pilot, and we'll help with the sensor-placement layout and operating-mode selection.