Sector · Maritime and ports
Physical AI for maritime and ports
Terminals and port authorities run gates, cranes, yards and finance on separate systems, so nobody sees the whole flow of a box or a truck. These are the questions engineers ask first, answered from 2 published CodeNinja Atoms reference architectures.
- What does a physical AI system for maritime and ports look like?
- Which AI models can a maritime and ports operator run on its own hardware?
- How much compute and hardware does AI in maritime and ports need?
- Is it cheaper to own AI hardware or rent cloud GPUs in maritime and ports?
- What ontology or object model does a maritime and ports AI system need?
- Who approves the decisions an AI system makes in maritime and ports?
What does a physical AI system for maritime and ports look like?
A complete physical AI design for maritime and ports 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 2 such reference architectures for maritime and ports, each free to reuse under CC BY 4.0.
| Design | Country | What it does |
|---|---|---|
| Port Twin | United States | one authoritative digital twin that binds a port's operational systems, live sensor feeds and finance backbone into a thirteen-object ontology, self-hosted on the port's own virtual machines inside the continental United States. |
| Terminal Pulse | United States | truck turn time predicted two hours out and yard congestion seen live, at a container terminal, on the operator's own hardware with no outbound connection. |
Which AI models can a maritime and ports operator run on its own hardware?
Each published maritime and ports 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 |
|---|---|
| Port Twin | One self-hosted open model, BGE-M3, for document retrieval; no generative model and no token stream |
| Terminal Pulse | 5 self-hosted open models: GLM 5.3 (reasoning), Chronos-2 (forecasting), Qwen3-Embedding-0.6B (retrieval), RF-DETR (vision), Roboflow trackers |
| Design | Choice | What was picked | Why |
|---|---|---|---|
| Port Twin | Document retrieval model | BGE-M3 embedding model, 568M parameters, self-hosted at fp16 | The only model in the register; hybrid dense and sparse search over drawings, inspections and messages, with no token stream and no external provider in any interactive path |
| Port Twin | Hardware classes | None purchased; existing enterprise virtual machines only | The requirements buy no equipment; about 1.1 GB of fp16 weights fit standard virtual machine memory |
| Port Twin | Sizing rule | Weights occupy about 2.27 GB at float32, about 1.1 GB at fp16, about 0.6 GB at 8 bit | The fp16 figure is the sizing basis; no KV cache applies because an embedding model generates no token stream |
| Port Twin | Sensing | No new sensing; up to five existing environmental sensor feeds with threshold alerting and historical export, plus a sourced photorealistic 3D mesh | The requirements integrate existing feeds; no camera, sensor or server is purchased |
| Port Twin | Ground | Port-managed servers under the port's own change management, inside the continental United States boundary | The port's own security requirements set the boundary; every workload runs on infrastructure the port already operates |
| Port Twin | Pattern | Adapter tier, one object model, read-only systems of record, Esri GeoEvent Server as the sole feed path | Every source enters through an adapter and the twin never writes back into a system of record |
| Terminal Pulse | Work surface model | GLM 5.3, 753 billion parameters filed, FP8, on one 8-GPU node of the 141 GB HBM class | Bespoke license permits internal commercial use with attribution and no revenue trigger; one node holds the weights with KV headroom. |
| Terminal Pulse | Edge detector | RF-DETR, Apache-2.0, Nano to 2XL checkpoints from about 61 to 254 MB at 16 bit | Real-time on edge GPUs, fine tunable on the operator's own footage, fixed auditable classes. |
| Terminal Pulse | Site forecaster | Chronos-2, Apache-2.0, about 0.48 GB at FP32 | Zero-shot multivariate forecasting with covariates for the two-hour turn time, queue and reefer predictions. |
| Terminal Pulse | Site embedding model | Qwen3-Embedding-0.6B, Apache-2.0, about 1.2 GB at bf16 | The 32K window holds a whole shift's gate and appointment record in one passage. |
| Terminal Pulse | Edge tracker | Roboflow trackers, Apache-2.0 clean-room SORT, ByteTrack and OC-SORT | Per-object counts and conflict geometry at no model memory cost, on CPU beside the detector. |
| Terminal Pulse | Edge compute class | Fanless IP-rated enclosures with accelerator at the yard blocks, gate and quay | Sized from actual streams and models by bench measurement, never from a datasheet. |
| Terminal Pulse | Site inference server | One GPU node, H100-class 80 GB or L40S-class 48 GB | Holds forecaster and embedding model with room for 32K-window activation memory. |
| Terminal Pulse | Frontier node | One 8-GPU node of the 141 GB HBM class, about 10 kW | 904 GB required against 1,128 GB usable, inside the room's power envelope. |
| Terminal Pulse | Camera estate | Reuse of the 220 existing fixed cameras, decided per camera by six gates | Reuse existing CCTV or not is the first sizing rule; new buys carry no domestic US license restriction. |
| Terminal Pulse | Positioning station | RTKLIB with a site-owned GNSS base external positioning service. | Grounds RTG and truck positions without an |
| Terminal Pulse | Time synchronization OCXO, linuxptp and chrony | OCP Time Card grandmaster with holdover reads on one clock through power transfer. | Keeps camera frames, PLC cycles and gate |
| Terminal Pulse | One-way transfer | Lidi over a hardware data diode | Weights and images move inward; nothing queries back across the boundary. |
How much compute and hardware does AI in maritime and ports need?
The compute follows from the models: the published maritime and ports designs size it as follows, from no new hardware to a full GPU node.
| Design | Part | The design |
|---|---|---|
| Port Twin | Compute | No equipment bought: about 1.1 GB of fp16 weights on the port's existing enterprise virtual machines |
| Port Twin | Boundary | Everything runs inside the continental United States on infrastructure the port already operates; no hosted document AI service in the path |
| Terminal Pulse | Frontier compute | One node of eight 141 GB HBM-class GPUs holds GLM 5.3 at FP8 (753 GB of weights, 904 GB with headroom), at about 10 kW |
| Terminal Pulse | Edge | Fanless IP-rated enclosures at the yard blocks, gate and quay; no safety reflex crosses a network hop |
Is it cheaper to own AI hardware or rent cloud GPUs in maritime and ports?
Each maritime and ports 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 |
|---|---|---|
| Port Twin | Three-year cost | No hardware line to price: the design adds software and integration work to servers the port already runs |
| Terminal Pulse | Three-year cost, owned | About 722,000 US dollars with support and power at the US industrial power price |
| Terminal Pulse | Three-year cost, rented | 0.99 million to 2.52 million US dollars for the same GPUs around the clock; ownership is about four fifths the deepest three-year commitment (version 2) |
| Terminal Pulse | Closed model break-even | The cheapest closed model matches the owned stack at about 35 users; above that, ownership is cheaper and the gap grows with every user |
What ontology or object model does a maritime and ports 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 maritime and ports 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 |
|---|---|---|---|
| Port Twin | 13 objects, 13 links | Berth, Navigation channel, Subsurface utility layer, Environmental sensor feed, Parcel / facility, Bathymetric survey surface, Utility gap record, Capital project, Inspection record, Vessel movement record, Truck movement record, PCS message, Engineering document | objects.json |
| Terminal Pulse | 12 objects, 11 links | Vessel Call, Container, Yard Block, RTG, Ship to Shore Crane, Truck Visit, Gate Lane, Rail Cut, Reefer Plug, Yard Person, Transfer Zone, Safety Event | objects.json |
Who approves the decisions an AI system makes in maritime and ports?
In every published maritime and ports design a named person makes the decision that changes the physical world; the system prepares it.
| Design | Human control |
|---|---|
| Port Twin | The twin shows; pilots, berth planners, engineers and finance staff decide in their own systems, and nothing writes back into a system of record |
| Terminal Pulse | Surfaces warn and propose; the named planner acts in the terminal operating system and the named safety supervisor acknowledges every safety event |
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.