System design for physical AI: predictive maintenance across five fleet records

By Muhammad Umar. 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/open-pit-mine-haul-fleet-saudi-arabia/. DOI 10.5281/zenodo.23889774. The operator is described by class, never by name.

An open pit mine in Saudi Arabia works a haul fleet of about 35 trucks of the 100 tonne class against one electric rope shovel of the 600 tonne class, feeding a crusher. A final drive announces its failure for months before it arrives on the ramp: rising wear metals in the laboratory's oil records, payload strain on ramp segments in the fleet system's cycles, an escalating alarm in telematics, and a rebuild history in the maintenance system that says the component is past its mean time between failures. Each system holds one link and none holds the chain, so the failure announces itself on the ramp with a loaded truck on it instead of in the workshop.

1. Two adapter families, one door

Five systems of record feed the design, all the operator's own and all read only at the door: the fleet management and dispatch system, the operator's own telematics, the maintenance management system, the oil laboratory and the mine plan. Two adapter families carry every fact in. The integration adapter handles vendor APIs, database reads and scheduled file exports; the telemetry adapter handles high rate signals from the truck bus and the edge units. Every fact carries its source system, its provenance class and a synchronized timestamp, and replays are idempotent. Writes return only through the owning systems, after a named approval and with an audit trail: approved haul redrafts into the fleet system's assignments, approved work orders and rebuild records into the maintenance system. No agent has a direct path to a machine. Truck positions come from the fleet system, so no tracking or trajectory layer is added.

2. A backbone that survives the link

Apache Kafka 4.3.x in KRaft mode runs on the site servers, partitioned by machine so one truck's events land in order, delivered at least once to idempotent consumers. Buffering happens twice: at the edge, where units hold events and small image crops while the private LTE link is down, and in the backbone, whose retention covers a replay after a consumer failure. The spectrum is shared access with no guaranteed channel, so the design sends events and crops, never continuous pixels. Linuxptp with chrony keeps sensors and systems on one clock. Models and containers arrive one way through a hardware data diode running Lidi into an air gapped Harbor registry, so the update path can never become an egress path. The time series store is deliberately left open: InfluxDB 3 Core, TimescaleDB and QuestDB are compared, and the choice lands after phase one measures the real telemetry rates.

3. Sixteen objects, one walk

The object model holds sixteen objects with thirteen typed links: haul truck, shovel, component, haul road segment, haul cycle, payload record, telematics alarm, oil sample, tyre reading, work order, rebuild, ground engaging tool and shift, plus the maintenance planner, the dispatcher and the mine superintendent. A query starts at a telematics alarm on a truck working the ramp, walks to the haul cycles it ran over that segment, to the final drive with its hours since rebuild, to the oil trend on that component and to the findings at its last rebuild. Every one of those records exists today. The walk between them does not. A work order sits at "Drafted by agent" until a named person moves it to "Approved".

4. Detect at the bucket, forecast on site

The edge tier is an automotive grade octa core SoC on the trucks and at the shovel bucket camera, chosen over off the shelf edge boxes or GPU modules that need a heat path a sealed cab mount cannot give; a fan would pull dust through the board. It serves Grounding DINO, the Swin-T checkpoint at about 345 MB at 16 bit, through ONNX Runtime under K3s, to catch a missing tooth before it travels to the crusher, with the Swin-B checkpoint at about 467 MB as the fallback. The site servers run Chronos-2 zero shot with covariates, about 0.24 GB at 16 bit, thresholding forecast residuals for anomaly, and BGE-M3 at about 1.1 GB for retrieval over records that mix Arabic and English. Chronos-2 was picked over fine tuned models, which would move the operator's data into weights, and over TimesFM 3.0 and Moirai 2.0, whose non commercial terms cannot ship inside the boundary.

5. One node, sized by arithmetic

GLM 5.3 is filed at 753 billion parameters. At FP8 that is 753 GB of weights; a 1.2 planning factor brings the requirement to 904 GB. One node of eight 141 GB GPUs, about ten kilowatts in the site server room, gives 1,128 GB, which leaves 375 GB beside the weights against the 151 GB the factor reserves. It runs under vLLM and drafts for three agents: the health ranking the maintenance planner approves, the haul redraft the dispatcher approves, and the tooth loss alert the shovel operator confirms. The one exception to named approval is the tooth loss stop, which follows the site safety procedure. Rankings improve through memory of work order outcomes and planner decisions, never through weights. GLM 5.3's bespoke license permits commercial use, fine tuning and redistribution; Grounding DINO and Chronos-2 are Apache-2.0 and BGE-M3 is MIT, so the operator holds every copy.

Appendix A prices the node at about 556,000 US dollars to own over three years (528,000 to 580,000), with power at the Saudi industrial electricity tariff. Renting the same eight cards on the cheapest three year commitment in AWS Middle East (UAE) is about 751,000, so ownership costs about three quarters of it. Renting is a price reference only: AWS listed no Saudi region on the day the prices were read, and the fleet records would cross the border.

The rollout is four phases and 18 scope items (5, 6, 6, then 1), gated on the fleet ontology standing on the systems of record, the private LTE network across the pit, the tooth loss stop agent, and a six month measured run against the operator's own baselines of unplanned downtime, mean time between failures, tooth loss reaching the crusher and cost per tonne.

Made with CodeNinja Praxis, the CodeNinja Atoms platform for designing physical AI systems. The object model imports into Hyper Ontology. Paper, ontology and register: https://codeatoms.ai/open-pit-mine-haul-fleet-saudi-arabia/

One design in the CodeNinja Atoms industrial AI reference architecture: open designs for real industrial operations by sector, each with its object model, open weight models, compute and three year cost.