DEV Community

Umar Bilal
Umar Bilal

Posted on Originally published at codeatoms.ai

System design for physical AI: an auditable plant reliability study built on one object model

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/plant-reliability-assessment-saudi-arabia/. The operator is described by class, never by name.

An energy and utilities operator in Saudi Arabia needs a reliability and performance assessment across its desalination and treatment plants: which systems drive unavailability, whether sparing matches criticality, and whether past root cause analyses hold up. Each plant's work orders, trip history and design documents live in separate systems that were never joined, so every availability figure is rebuilt by hand and defended without a traceable basis.

Here is how that turns into a study that can be audited.

1. Read exports, not live interfaces

Three record sources, the plant CMMS, the plant historian and the O&M and design documentation, enter as exports through three read-only adapters. Live integration into plant control networks would import a whole compliance program the scope never funded; exports keep the crossing one way and the study reproducible.

2. Join the records into thirteen objects

Plant, production train, equipment, failure mode, work order, downtime event, major event, availability prediction, availability target, criticality index, spare part, RCA report and reliability program. Which closed work orders sit on equipment ranked above the criticality threshold, how much production their trains lost, and whether a spare was held for each, is one traversal across five links and three silos.

3. Compute availability you can rerun

Availability comes from Monte Carlo simulation on reliability block diagrams built from each plant's own failure study, traceable to ISO 55000. A packaged tool was set aside: a method the operator can rerun and audit outranks a rented black box.

4. An empty model register is an answer

No inference workload is contracted, so the register holds no model and the design buys no hardware. Naming a model would put a speculative artifact where the requirement expects an auditable method.

5. People move every status

A prediction moves from drafted to reviewed to accepted only when a named reviewer accepts it; an RCA report is validated only when a named engineer signs it. Each phase is gated on milestone evidence, not calendar hope.

Full design, figures and the object model: the paper.


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)