Referenzarchitektur fuer Port-Digital Twins: Engineering ohne Hardware-Kauf
Eine offene Referenzarchitektur fuer digitale Zwillinge von Haefen verzichtet auf neue Hardware-Investitionen und setzt auf durchgaengige Datenverantwortung des Betreibers. Papier, Objektmodell als JSON und Modellregister sind unter CC BY 4.0 frei nutzbar.
Veröffentlicht am 7. Oktober • Zuerst erschienen auf codeatoms.ai
Dies ist die technische Zusammenfassung einer offenen Referenzarchitektur. Das Papier, sein Objektmodell als JSON und das Modellregister stehen unter CC BY 4.0 frei zur Wiederverwendung zur Verfügung: https://codeatoms.ai/port-digital-twin-us/. Der Betreiber wird über die Klasse beschrieben, niemals über den Namen.
Eine landlord-Hafenbehörde in den USA besitzt die Piers, Liegeplätze, Fahrwasser und Grundstücke, aber nicht die Terminalbetriebssysteme, die auf ihnen laufen. Ihre kritischen Informationen liegen in voneinander getrennten Systemen: im Port-Community-System, in den GIS-Beständen, in AIS-Schiffspositionen, in Lkw-Tor-Transaktionen, in bathymetrischen Vermessungen, in Karten unterirdischer Versorgungsleitungen, in Inspektionen, in technischen Zeichnungen und im Finanz-Backbone. Gefordert ist ein einziger kontrollierter digitaler Zwilling von all dem, innerhalb der kontinentalen USA, auf Infrastruktur, die der Hafen bereits betreibt.
So wird daraus ein System, für das es nichts zu kaufen gibt.
Jede Quelle läuft über einen nur lesenden Adapter in ein Event-Backbone ein, und die Adapter schreiben dreizehn typisierte Objekte: Liegeplatz, Fahrrinne, unterirdische Versorgungsschicht, Umwelt-Sensorfeed, Grundstück oder Einrichtung, bathymetrische Vermessungsfläche, Versorgungslücken-Eintrag, Investitionsprojekt, Inspektionsdatensatz, Schiffsbewegung, Lkw-Bewegung, PCS-Nachricht und technisches Dokument.
Der Liegeplatz ist das zentrale Objekt. Von einem Liegeplatz aus erreicht eine einzige Traversierung die Schiffsmanöver, die ihn berühren, die angrenzende Fahrrinne, die aktuelle bathymetrische Oberfläche dieser Fahrrinne und damit die Unterkiel-Situation, die ein Lotse benötigt. Von einem Grundstück aus gelangt man zum Pachtvertrag, zu den Ertrags- und Aufwandspositionen, zu den Investitionsprojekten, deren Fläche sich mit ihm überschneidet, und zu den Inspektionen seiner Einrichtungen. Eine GIS-Ebene zeigt, wo sich Dinge befinden; die Ontologie sagt, wie sie zusammenhängen.
Das Objektmodell wird als JSON ausgeliefert ( ontology/objects.json, Format hyper-ontology/1 ), sodass man es laden kann, statt es neu zu zeichnen.
Das einzige Modell im Register ist BGE-M3, ein offenes Embedding-Modell für die Dokumentsuche über Zeichnungen, Inspektionen und Nachrichten hinweg.
Gewicht ca. 2,27 GB bei float32, ca. 1,1 GB bei fp16, ca. 0,6 GB bei 8 Bit, kein KV-Cache: Ein Embedding-Modell erzeugt keinen Tokenstrom. Hardware: nichts gekauft, bestehende Enterprise-Virtualisierungs-Instanzen werden genutzt. Es gibt keinen GPU-Cluster zu dimensionieren, weil die Anforderung keinen verlangt. Eine gehostete Document-AI-API wurde geprüft und verworfen: Sie würde Hafendokumente außerhalb der Grenze bringen, die die eigenen Sicherheitsanforderungen des Hafens setzen.
Der Zwilling läuft auf vom Hafen verwalteten Servern unter der eigenen Änderungsverwaltung des Hafens, innerhalb der kontinentalen USA. Er liest die Daten der Terminalbetreiber über das Port-Community-System und hebt die Grenze zwischen Landlord und Betreiber niemals auf: Der Hafen sieht, aber er betreibt die Terminals nicht.
Der Zwilling zeigt. Lotsen, Liegeplatzplaner, Ingenieure und Finanzmitarbeiter handeln in ihren jeweiligen Systemen der Datenhaltung. Die einzigen Einträge, die der Zwilling selbst schreibt, sind seine eigenen: Versorgungslücken-Einträge und Inspektionsarbeitslisten, jeweils verankert an dem Asset, um das es geht.
Es gibt keine Hardware-Position. Die Gewichte passen auf eine Standard-Virtuelle Maschine, und die Anforderung kauft keine Kameras, Sensoren oder Server. Die Kosten bestehen aus Integration und Software auf Infrastruktur, die der Hafen bereits bezahlt, weshalb das Papier keinen Cloud-Vergleich enthält.
Vollständiges Design, Abbildungen und das Objektmodell: das Papier.
Entworfen auf CodeNinja Praxis, der Plattform für den Entwurf physischer KI-Systeme. Das Objektmodell lässt sich in Hyper Ontology importieren, das daraus ein lebendiges System macht. Laden Sie es selbst mit dem offenen hyper-ontology Loader.
Mit Vorlagen lassen sich häufig gestellte Fragen schnell beantworten oder Snippets zur Wiederverwendung speichern.
Sind Sie sicher, dass Sie diesen Kommentar ausblenden möchten? Er wird in Ihrem Beitrag ausgeblendet, bleibt aber über den Permalink des Kommentars sichtbar.
Für weitere Aktionen können Sie in Betracht ziehen, diese Person zu blockieren und/oder eine Meldung wegen unangemessenen Verhaltens einzureichen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 7 • Originally published at codeatoms.ai
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/port-digital-twin-us/. The operator is described by class, never by name.
A landlord port authority in the United States owns the piers, berths, channels and parcels but not the terminal operating systems that run on them. Its critical information sits in disconnected systems: the port community system, the GIS estate, AIS vessel positions, truck gate transactions, bathymetric surveys, subsurface utility maps, inspections, engineering drawings and the finance backbone. The ask is one governed twin of all of it, inside the continental United States, on infrastructure the port already runs.
Here is how that turns into a system with nothing to buy.
Every source enters through a read-only adapter onto an event backbone, and the adapters write thirteen typed objects: berth, navigation channel, subsurface utility layer, environmental sensor feed, parcel or facility, bathymetric survey surface, utility gap record, capital project, inspection record, vessel movement, truck movement, PCS message and engineering document.
The berth is the focal object. From one berth a single traversal reaches the vessel movements that touch it, the channel it adjoins, the current bathymetric surface on that channel, and so the under-keel condition a pilot needs. From a parcel it reaches the lease, the revenue and expense lines, the capital projects whose footprint overlaps it and the inspections against its facilities. A GIS layer shows where things are; the ontology says how they relate.
The object model ships as JSON ( ontology/objects.json, format hyper-ontology/1 ) so you can load it instead of redrawing it.
The only model in the register is BGE-M3, an open embedding model for document retrieval across drawings, inspections and messages.
weights ~2.27 GB at float32, ~1.1 GB at fp16, ~0.6 GB at 8 bit KV cache none: an embedding model generates no token stream hardware none bought: existing enterprise virtual machines Enter fullscreen mode Exit fullscreen mode There is no GPU cluster to size because the requirement asks for none. A hosted document AI API was weighed and set aside: it would move port documents outside the boundary the port's own security requirements set.
The twin runs on port-managed servers under the port's own change management, inside the continental United States. It reads terminal operators' data through the port community system and never collapses the landlord-operator boundary: the port sees, it does not run the terminals.
The twin shows. Pilots, berth planners, engineers and finance staff act in their own systems of record. The only records the twin writes are its own: utility gap records and inspection worklists, each anchored to the asset it concerns.
There is no hardware line. The weights fit a standard virtual machine, and the requirement buys no cameras, sensors or servers. The cost is integration and software on infrastructure the port already pays for, which is why the paper carries no cloud comparison.
Full design, figures and the object model: the paper.
Designed on CodeNinja Praxis, the 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.