DEV Community

Umar Bilal
Umar Bilal

Posted on Originally published at codeatoms.ai

System design for physical AI: a camera count is not coverage, so prove it pole by pole on a vehicle proving ground

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/test-site-camera-monitoring-us/. The operator is described by class, never by name.

A vehicle proving ground in the United States runs test vehicles through marked turns, a pit entry and crossings where people walk. Its camera system was bought in 2013 and has decayed into outages, dead heads and no redundancy, and nobody has a diagram of the cable routes. The question it cannot answer: where was every vehicle and every person when something happened, and can you show it again thirty days later?

The tempting answer is a purchase order with a camera count on it. Here is why that is the wrong unit, and what the design does instead.

1. Survey first, because a camera count is not coverage

No pole is ordered until a coverage survey shows every crossing, pit entry, turn and access point held at the required pixels on target, with low light treated as a budget and mounting geometry deciding what each head actually sees. Any dead spot is closed by geometry or accepted in writing. The survey evidence pack is the phase one exit gate, so the money at risk is still small if it fails.

2. Two strands per pole, home to one room

40 to 60 poles carry fixed thermal and visible heads, no wireless radios, each fed by Power over Ethernet from managed switches, with NEMA rated enclosures and step-down transformer feeds at the poles. New underground single-mode fiber runs two strands to every pole and lands at the operator's own termination building, where the recording tier sits in a conditioned server room. Every head is screened under Section 889 with a component-level bill of materials before purchase, and an adapter rejects any device it was not provisioned for.

3. An N+1 recorder you own outright

Open-source Frigate NVR records 80 to 120 streams on a primary and a standby host, each holding the full 30 days on local disk. There is no message broker, because nothing downstream subscribes; ordering comes from time instead, an OCP Time Card grandmaster with a holdover oscillator disciplining every host, so an exported clip is evidentiary on its timestamps alone.

4. One detector, searched after the fact

The estate is passive: people watch, nothing raises an alarm, so no model sits in the live path. D-FINE, Apache-2.0 on both code and weights, runs over the archive when the safety office asks a question, such as every clip of a person near a turning vehicle. Its weights are about 8 MB for the N tier and 124 MB for X, a rounding error on a 48 GB card whose real budget is decode. RF-DETR was set aside because its XL tiers sit under a platform license.

5. What it costs, and what it never costs

Owning the whole estate costs about 474,000 to 871,000 US dollars over three years from public list prices, and the camera heads are most of it: a thermal and visible head is seven to eight thousand dollars, one per pole. The compute is the small line. Two recorder hosts with one L40S class card each cost about 32,600 dollars over three years, about four fifths of renting the same two cards on the deepest three-year AWS commitment, and that rented figure stores none of the footage. What it never costs is a license per camera: the recorder is open source and the detector is Apache-2.0, so adding the sixty-first pole adds hardware and nothing else.

6. Acceptance per use case, not per camera

Camera uptime is a first-class metric with re-runnable quarterly acceptance tests, and the estate is accepted one use case at a time: a pedestrian crossing watched through a shift, a test cycle reconstructed from 30 days of footage. The last gate is forensic search returning the right clip from the right camera at the right time.

Full design, figures, the cost appendix with every price cited, and the fifteen-object model: the paper. DOI: https://doi.org/10.5281/zenodo.23296077

Its fifteen objects sit beside every other published object model in the industrial ontology examples collection.


Designed on CodeNinja Praxis, the CodeNinja Atoms 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)