DEV Community

Umar Bilal
Umar Bilal

Posted on Originally published at codeatoms.ai

System design for physical AI: catching flatlined and swapped radar tank gauge readings

This is the engineering summary of an open reference architecture. The paper, its object model as JSON and the model register are free to reuse under CC BY 4.0: https://codeatoms.ai/tank-gauge-integrity-pakistan/. The operator is described by class, never by name.

A fuel terminal in Pakistan gauges thirteen tanks with radar tank gauges wired on three serial Modbus RTU loops into one centralized gauging host. A flatlined gauge reads as a plausible low level. A swapped gauge makes two tanks trade identities. Both surface only when the central inventory picture disagrees with physical stock, long after the signal failed.

Here is how that turns into readings that fail loudly.

1. Survey the signal before buying anything

The loops' signal health is invisible today. The design measures it first, then engineers three booster installations from the survey, each inside an explosion proof junction box with its own field power supply, under the gauging host manufacturer's written authorization. The survey sets the count, not the paper.

2. Model the loop, not just the tank

Fifteen typed objects: fuel tank, radar tank gauge, communication loop, Modbus booster, junction box, gauge reading, data quality event, central inventory picture, loop wiring as-built, service order, warranty record, OEM authorization letter, HSE work permit, instrumentation technician and location engineer. From a distorted level at one tank, one query reaches the loop, the booster that serves it, the as-built that documents it, the technician assigned to it and the permit that covers the work.

3. Deterministic checks, no learned model

freshness        a gauge that stops answering its polls
flatline         a stuck value that keeps arriving looking valid
address binding  a reading attributed to the wrong tank, the signature of a swap
Enter fullscreen mode Exit fullscreen mode

Every check is a rule an instrument engineer can read, so the model register is empty by design. The ontology service and the integrity monitor run as two containers on the operator's own site application server, inside its OT boundary, projecting a central inventory picture over the gauging host without replacing it.

4. A named person closes every event

Each data quality event moves from open to acknowledged to resolved, and every transition names the person who made it. The location engineer signs acceptance; no phase closes without a signature.

5. What it costs

No compute to buy. The field equipment sits inside the requirement's own supply scope and is priced by OEM quotation against the survey, so the paper prints no list prices.

Full design, figures and the object model: the paper. Cite it as DOI 10.5281/zenodo.23157967.


Designed on CodeNinja Praxis, CodeNinja's platform for designing physical AI systems. The object model imports into Hyper Ontology, which turns it into a living system. Load it yourself with the open hyper-ontology loader.

Top comments (0)