Frequently Asked Questions
What is ROSSMA.Pipeline?
A hardware-and-software platform for continuous pipeline monitoring. Wireless IoT pressure sensors (plus optional flow and temperature) are placed along the route and transmit over a LoRaWAN network to a cloud or on-premise 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 is the pipeline's nervous system: instead of periodic foot patrols, you get the line's condition continuously and an incident signal within minutes — critical for the long, remote export lines typical of the region.
Which pipelines does it cover?
Crude and product oil, gas, gas-condensate, water transmission, and district cooling/heating networks. For each medium 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 thresholds and calculations match the actual line — important for high-API crude and waxy regional grades rather than a one-size-fits-all 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 micro-leak over several cycles (for statistical confidence). The practical trade-off: critical points run event-driven (fast, slightly higher battery use), quiet sections run periodic (longer battery life). A single sensor can run periodic but "wake up" into event mode when it sees a deviation — useful across vast, sparsely-manned desert routes.
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). Each method returns its own 0–1 confidence, and these are 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. False call-outs are expensive on remote lines, so this matters operationally.
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 propagates 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 medium's bulk modulus, pipe diameter and wall elasticity) — roughly 900–1300 m/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 coordinate. 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 segment length between sensors — ±100–300 m over a 10 km span. So a crew is dispatched to a defined zone, not "somewhere along tens of kilometres." 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 see?
It depends on diameter, operating pressure, sensor spacing and the method mix. Ruptures and unauthorized taps producing a drop of ~1 bar 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. Micro-leaks (0.1–0.5% of flow) barely create an NPW wave, but mass balance catches them: with inlet/outlet flow 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.
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) — valuable under the large diurnal temperature swings of desert operation. 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.
How often are there false alarms?
Rare — and not by luck, but by design. 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 suffering alarm fatigue.
Why LoRaWAN?
LoRaWAN is a low-power, long-range network (kilometres per gateway) on an unlicensed band. For long, remote routes 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 — well suited to export lines crossing desert and sabkha terrain. 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 systems, especially on live and hard-to-access pipelines.
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 operators with on-premise deployment, the connector runs inside your own network.
Which standards does it align with?
The methodology aligns with API 1130 (Computational Pipeline Monitoring for liquids) and ASME B31.4/B31.8 engineering practice widely used by regional NOCs and EPCs. In practice that means continuous monitoring, documentation of every event (time, method, confidence, coordinates), an operator-action audit trail, and reporting you can attach to integrity-management procedures. The system doesn't replace your procedures — it provides the tool and the evidence base: 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 coordinate (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 and hosted?
Role-based access (owner / manager / monitor) with a full audit log; the owner who verified the organization's domain is protected from being changed by other administrators. Crucially for the region, an Enterprise on-premise option deploys via Docker inside your own network, so data never leaves your perimeter — the natural fit for NOCs and operators with strict security or air-gap requirements. Cloud hosting and data-residency arrangements can be tailored to the operator's jurisdiction.
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 a client or regulator with numbers.
Does it handle thermal effects?
Yes — a dedicated module for waxy crude and heated lines. It builds a thermal profile (fluid temperature distribution along the route, accounting for insulation, laying type and weather, fetched automatically by coordinates), flags risk zones where temperature nears the gel/freeze point, computes time-to-gel on shutdown, and for crude analyses rheology: viscosity vs temperature (Walther equation), pour point and Wax Appearance Temperature (WAT). This enables pre-emptive action — start heating or raise throughput before a section congeals — rather than dealing with a blocked line after the fact, which matters for high-pour-point regional crudes.
What are the deployment options, speed, and cost?
Two options. Cloud SaaS — onboarding in days, no infrastructure of your own; you define the route and start monitoring. Enterprise on-premise — full deployment via Docker inside your own network, so data never leaves your perimeter: turnkey installation, SSO/LDAP, custom branding, SCADA integration, a 99.9% SLA and dedicated support — suited to NOCs and operators with strict security or air-gap requirements. Pricing is by industry segment and pipeline length. We prepare an exact quote for your route and operating profile.
How do we start a pilot?
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 20–50 km 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 line. Contact us and we'll help with the sensor-placement layout and the operating-mode selection for your objectives.