Remote Tank Inventory with Radar Level: Architecture and Acceptance

Remote inventory is a measurement and data-governance system, not simply a radar connected to a modem. The level must represent the intended product condition, be converted through a controlled tank table or density basis and arrive with timestamp and quality intact. Power, communications, buffering, cybersecurity and alarm ownership determine whether the value remains useful during outages. Acceptance should prove the complete path from the tank to the authorized user and state the uncertainty and response appropriate to inventory, operations and safety decisions.

Define the business and operational use

State whether data supports replenishment, production planning, customer visibility, transfer reconciliation, local control or alarms. Define update time, availability, uncertainty and escalation from each use. Remote inventory should not silently become an overfill protection function. Identify the accountable owner for measurement, tank conversion, communications and response to invalid data.

Establish measurement meaning

Document antenna reference plane, tank zero, level range, product, temperature, density and tank geometry. Decide whether the transmitted value is distance, level, percent, volume or mass and where conversion occurs. Use one controlled tank table and preserve its revision. For irregular tanks or solids, state representativeness and conversion uncertainty honestly.

Engineer field reliability

Verify radar suitability, mounting, beam path, process seal, weather protection, hazardous approval, grounding and surge protection. Size power for transmitter, RTU, modem and cold-start demand. For solar or battery systems, calculate autonomy using realistic communication duty and temperature. Provide local diagnostics and safe maintenance access so remote operation does not make field evidence inaccessible.

Design communications for loss

Choose cellular, Ethernet, radio or other telemetry links based on coverage, latency, cost and site policy. Define protocol, addresses, retries, buffering, deduplication and backfill. Preserve original measurement timestamps. A dashboard should distinguish fresh, delayed and stale data; the last received level must not appear current after a communications outage.

Carry quality and diagnostics

Transmit device fault, lost echo, out-of-range, maintenance and communication status with the value. Define how gateways and platforms map quality. Avoid converting invalid data to zero or an apparently normal percent. Retain enough diagnostics to separate process change, radar fault, field power, network and platform problems without unnecessary site visits.

Control cybersecurity and access

Use approved authentication, encryption and network architecture. Remove default credentials, restrict configuration writes and record account ownership. Separate monitoring from remote control where possible and require change authorization for range, tank table and alarms. Define patch, certificate and account-recovery responsibilities over the system lifecycle.

Design alarms and notifications

Set thresholds, delay, hysteresis and priority from operational consequence and maximum rate. Define who receives notifications, how acknowledgement works and what happens when data is stale. Test time zones and escalation. Critical site actions may require a local independent alarm because a cloud notification depends on several shared communication and software layers.

Accept end to end

Compare known field levels with radar, RTU payload, platform value, reports and alarm messages. Test power loss, communications outage, buffering, backfill, stale indication and user access. Record timestamps and quality at every boundary. Retain configuration, tank table, network settings, test evidence and recovery instructions with named owners.

Engineering checklist

Define use, uncertainty and ownership.
Control level-to-volume conversion.
Design field power and environmental protection.
Preserve timestamps through outages and backfill.
Carry quality with every value.
Test alarms and failure recovery end to end.

Frequently asked questions

Can remote inventory replace overfill protection?

Not automatically. Protective independence and proof testing require a separate risk-based design.

Should the platform store only percent full?

Usually retain raw level, units, timestamp, quality and conversion revision for traceability.

What is the key outage test?

Prove stale indication, buffering, correct backfill and no duplication or false alarm on recovery.

Need a project-specific review? Send process data, drawings, photographs and acceptance criteria through our contact page.