Sector · Discrete manufacturing and automotive
Physical AI for discrete manufacturing and automotive
Vehicles and people share plant roads, test tracks and yards, and the cameras, gates and test schedules that should prove who was where are usually separate systems. These are the questions engineers ask first, answered from 1 published CodeNinja Atoms reference architecture.
- What does a physical AI system for discrete manufacturing and automotive look like?
- Which AI models can a discrete manufacturing and automotive operator run on its own hardware?
- How much compute and hardware does AI in discrete manufacturing and automotive need?
- Is it cheaper to own AI hardware or rent cloud GPUs in discrete manufacturing and automotive?
- What ontology or object model does a discrete manufacturing and automotive AI system need?
- Who approves the decisions an AI system makes in discrete manufacturing and automotive?
What does a physical AI system for discrete manufacturing and automotive look like?
A complete physical AI design for discrete manufacturing and automotive names what to sense, which existing systems to join, the object model that joins them, the models and hardware, the three-year cost and the person who approves every action. CodeNinja Atoms has published 1 such reference architecture for discrete manufacturing and automotive, each free to reuse under CC BY 4.0.
| Design | Country | What it does |
|---|---|---|
| Pit Camera Watch | United States | a fully on-premises camera monitoring system that puts every turn, crossing, pit entry and access point of a vehicle proving ground on footage the operator owns, with exportable clips and camera uptime it can prove. |
Which AI models can a discrete manufacturing and automotive operator run on its own hardware?
Each published discrete manufacturing and automotive design names its models and why, and every model is open-weight or no model is used at all, so the operator can run it on hardware it owns.
| Design | Models |
|---|---|
| Pit Camera Watch | D-FINE, Apache-2.0, for retrospective search over the archive (test vehicle, support vehicle, pedestrian); about 8 to 124 MB of weights |
| Design | Choice | What was picked | Why |
|---|---|---|---|
| Pit Camera Watch | Detection model | D-FINE, Apache-2.0, BF16, N to X tiers | Unconditional license keeps the weights in the operator's hands; N through L fit the 48 GB card; ahead of DEIM on matched compute in the July 2026 comparison. |
| Pit Camera Watch | Site inference server | 48 GB PCIe inference GPU class server in the ASHRAE A2 conditioned server room, N+1 | The entry class for plant server rooms running vision, and retrospective search plus 80 to 120 streams of decode fit it with headroom for a second model. |
| Pit Camera Watch | Recorder and serving runtime | Frigate NVR v0.18.0 with its built-in ONNX detector runtime | Open source the operator owns outright; keeps 30-day retention, ONVIF and RTSP exits and local detection without per-camera license rents. |
| Pit Camera Watch | Camera heads | Fixed multi-sensor thermal and visible heads, no wireless radios, Section 889 screened with producer-of-record statements | Zone coverage needs always-present calibrated views, and camera provenance is the first procurement gate on a test site. |
| Pit Camera Watch | Site networking | Managed PoE switches over underground single-mode fiber, two strands per pole | The requirement fixes the fiber architecture, and PoE Type 1 and 2 per-port budgets cover the heads without pole-side power electronics. |
| Pit Camera Watch | Enclosures and power | NEMA-rated outdoor enclosures, 277/120/24 V step-down transformer feeds, Network UPS Tools for clean shutdown | Heat, storms and sun angle degrade heads and light budgets, and clean shutdown protects the archive. |
| Pit Camera Watch | Time synchronization | OCP Time Card GNSS grandmaster with holdover oscillator, Chrony 4.9, linuxptp where PTP-aware switches exist | Evidentiary ordering across 80 to 120 recorded streams requires one clock. |
| Pit Camera Watch | Identity | Keycloak on-premise single sign-on with hardware token sign on for Linux hosts | Only booth operators and the safety office reach the isolated network, under the operator's identity policy. |
| Pit Camera Watch | Observability | Prometheus, Grafana and Loki on the isolated network | Camera uptime must be a first-class metric, not a vendor health page. |
| Pit Camera Watch | Sizing rules | The survey evidence pack, pixels on target first, low light as a budget, mounting geometry decides what you see | Coverage is proven in phase one evidence, never assumed from a camera count. |
| Pit Camera Watch | Patterns | A site-scale camera onboarding reference architecture and an on-premises video search blueprint | Onboarding, clip retrieval and search patterns adopted with no managed cloud, keeping the audio visual core on-premises. |
How much compute and hardware does AI in discrete manufacturing and automotive need?
The compute follows from the models: the published discrete manufacturing and automotive designs size it as follows, from no new hardware to a full GPU node.
| Design | Part | The design |
|---|---|---|
| Pit Camera Watch | Compute | One 48 GB L40S-class card per recorder host, in the conditioned server room; nothing at the poles |
Is it cheaper to own AI hardware or rent cloud GPUs in discrete manufacturing and automotive?
Each discrete manufacturing and automotive design prices three years of ownership in its Appendix A, with every price cited, against renting the same capacity from a cloud region at its deepest three-year commitment where hardware is bought.
| Design | Line | Three years |
|---|---|---|
| Pit Camera Watch | Three-year cost | About 474,000 to 871,000 US dollars to own over three years, mostly camera heads; the two recorder hosts alone cost about four fifths of the deepest three-year AWS commitment, and there is no per camera license at any pole count (Appendix A) |
What ontology or object model does a discrete manufacturing and automotive AI system need?
The object model is the part that makes the system an ontology rather than a pipeline: typed objects for the things in the discrete manufacturing and automotive operation, with properties, status values and typed links. Every published design ships its object model as hyper-ontology/1 JSON that loads into Hyper Ontology.
| Design | Size | Objects | Download |
|---|---|---|---|
| Pit Camera Watch | 15 objects, 13 links | The site, Camera Pole, Camera Head, Underground Fiber Run, Safety Gate, Operator Booth Display, Server (the operator's own system), 30-Day Footage Archive, Incident/Accident Record, The site Operator, Gate Officer, Safety Office Reviewer, Vehicle Under Test, Test Cycle, The operator's own system Power/Fiber assessment package | objects.json |
Who approves the decisions an AI system makes in discrete manufacturing and automotive?
In every published discrete manufacturing and automotive design a named person makes the decision that changes the physical world; the system prepares it.
| Design | Human control |
|---|---|
| Pit Camera Watch | Booth operators watch and decide; nothing raises an automated alarm; only the safety office can export a clip |
Every answer on this page is drawn from the papers linked in it: each paper's At a glance table, model register and cost appendix. Full text for agents: llms-full.txt. Designed on Praxis; object models load into Hyper Ontology.