實體 AI 系統設計:四個美國配送中心的即時數碼孿生與不離開場內的安全視覺分析
System design for physical AI: a live digital twin of four US distribution centers, with safety vision that never leaves the building
這套實體 AI 參考架構為美國四個配送中心建立即時數碼孿生,將倉庫、勞工、場地、影片及承運商資料整合,同時在各中心處理影片,僅傳送事件和短片。架構以 RF-DETR 偵測、OC-SORT 追蹤,並以 Mistral Large 3 675B 和 Qwen3.8-27B 提供助手功能;不訓練模型,透過記憶改善系統。
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/warehouse-digital-twin-us/. The operator is described by class, never by name.
A warehousing and intralogistics operator in the United States runs four distribution centers. The warehouse management system holds locations, inventory and pick paths but not labor, carriers or video. The labor system holds hours and rates but not the floor. The yard lives in a spreadsheet that is stale by mid-shift. Roughly 220 cameras record for security and no one reviews them, and forklift near misses are captured on paper, if at all. Pedestrians suffer 26 percent of all forklift related injuries, and the design exists so that a near miss becomes data the shift it happens.
1. Project the systems of record, do not replace them
The pattern is three tiers. Below sit five systems of record: the WMS, the labor management system, the yard spreadsheet, the video management system and a carrier appointment source. In the middle sits one object model that projects them and stays true by nightly reconciliation against them, with the WMS remaining the system of record. Above sit six services and four surfaces: a live floor console on a tablet, a clip review and coaching queue, the assistant work surface over the twin, and safety analytics. The only system the design retires is the yard spreadsheet, and only after the new dock and yard module holds every field it held.
2. One gate for every source
Every source enters through one integration adapter family: Debezium change data capture against the transactional systems, MediaMTX for the camera streams, normalized events onto an Apache Kafka 4.3 backbone in KRaft mode. Every object carries its source, timestamp and offset; every write is an idempotent upsert on the natural identifier, so a replayed stream cannot duplicate a trailer or a pick task. Telemetry lands in InfluxDB 3 Core, and linuxptp with chrony, under a GNSS-disciplined PTP grandmaster at each site, keeps camera and server clocks close enough that a forklift event and a WMS event order correctly. When the wide area link drops, events and clips buffer on site for the survival window at the measured rate, then doubled.
3. Detection at the edge, nothing but events leaving
Video is processed at each site, so each distribution center gets one industrial edge server with one 48 GB PCIe inference card. RF-DETR detection (the Apache-2.0 Nano to Large checkpoints) runs in Triton Inference Server, and OC-SORT tracks motion only: no appearance model, no re-identification branch, no face recognition anywhere. Speeds come from ground-plane calibrated camera views in meters per second, not pixel heuristics, because a speeding call in a pedestrian zone has to survive a challenge. Only events and short clips cross the boundary, optionally through a hardware-enforced one-way egress. Analytics advise; certified equipment and trained operators keep the safety function, and every event becomes a clip a supervisor reviews.
4. Fourteen objects
The model holds the distribution center, dock door, yard trailer, storage slot, SKU, open order, pick task, associate, labor shift, camera zone, safety event, forklift, shift lead and slotting recommendation, with 14 typed links. One query walks from a yard trailer to the dock door it is staged at, to the SKUs whose travel distance from dock is measured, to the pick tasks those SKUs feed, to the associate each task is assigned to, and to the shift lead who owns that shift. A slotting recommendation states predicted walking saved and move labor before anyone approves it, and runs in shadow mode beside the existing quarterly review first.
5. Models and what they cost to own
Mistral Large 3 675B (Apache-2.0, FP8, about 682 GB) serves the site manager assistant on one node of eight 141 GB cards. Qwen3.8-27B (Apache-2.0, about 31 GB at FP8) runs under vLLM on each site card so the assistant keeps answering when the wide area link drops, beside BGE-M3 (MIT) for retrieval over safety records and procedures. No training run: the system improves through memory, not weight changes. Appendix A prices owning the twelve cards at about 597,000 US dollars over three years (510,000 to 689,000) before the four edge chassis, which are sold by quotation. Renting the same cards in AWS US East runs about 1.86 million on demand and about 699,000 on the deepest three-year commitment, so ownership lands between about three quarters of that commitment and roughly the same price.
A one-site pilot gates everything: 17 items across six workstreams, measured on yard trailer staging and carrier wait time against the spreadsheet baseline, before 2 items carry the design to the remaining three sites.
This design sits with our other industrial ontology examples.
It is one of our sovereign AI reference architectures: the weights, the model and the data stay with the operator.
DOI: https://doi.org/10.5281/zenodo.23556416
Designed on 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/warehouse-digital-twin-us/
來源:DEV Community · dev.to