Definition
TOS (Terminal Operating System) is an information system used by port terminals to manage container loading and unloading, stacking, gates, vessel stowage, container assembly and disassembly, and other operations. TOS interfaces with customs single window systems, shipping companies, freight forwarders, railways, inland ports, and other systems to achieve full-process container visibility, operational coordination, and trade compliance. TOS is the core system of smart ports and automated terminals.
TOS manages the scheduling of quay cranes, yard cranes, and yard trucks, optimizing yard utilization and operational efficiency. It connects with EDI and APIs to enable data exchange such as manifests, stowage plans, and container movements.
Technical Features
TOS relies on gate RFID, weighbridges, quay cranes, yard cranes, video recognition, and other IoT devices to collect operational data. Gates, mobile devices, and remote operation points upload data to TOS via IoT SIM cards. The port environment is complex (metal interference, mobile scenarios), demanding high network coverage and stability. Integration with the single window requires ensuring real-time and accurate data transmission.
Use Cases
TOS is widely used in seaports, river ports, bonded ports, inland ports, and other terminal scenarios. Gate RFID, weighbridges, and quay cranes upload operational data to TOS via IoT SIM cards, supporting container tracking, trade compliance, and supply chain visibility. SimtoLink provides stable networking and dedicated APNs for port IoT devices, ensuring real-time data collection and cross-border data exchange for TOS.
Where a container move lands in the terminal system
A terminal operating system keeps the vessel, the yard, the gate, and machine dispatch in one set of work orders. What the cellular side actually has to deliver is an event that changes a container's state: gate-in, gate-out, weighing, quay-crane load or discharge confirmation, and the bay-row-tier after a yard crane sets the box down. Each event needs at least the container number, the move type, the equipment id, the time, and the position. In the yard the position is bay, row, and tier. On the quay it is the ship bay and the cell. The two coordinate systems cannot be mixed. If a message enters the system and does not match the current order, the system leaves the container in its previous state, and the external truck and the stowage plan start to see different slots.
Manifests, bay plans, and gate messages exchanged with the line and the forwarder sit at a different level from what field equipment reports. The first describes the plan. The second describes a move that has already happened. The IoT SIM covers the second level at points that cannot take a fixed fiber: a traveling yard crane, a temporary gate, a weighbridge far from the equipment room, and license-plate recognition. Pictures and container moves should queue separately. A recognition photo is large. When it shares a narrow channel with the short message that confirms a set-down, the short message is delayed, and the container in the system lags the moment the spreader has already unlocked.
What the gate and the yard crane need in order to be online together
Before the gate, the weighbridge, and the yard crane can all send data into the same terminal system, they need one clock and one container-number rule. A gate clock a few minutes slow puts the gate-in time outside the appointment window. A yard-crane clock a few minutes fast makes the set-down look earlier than the gate-in. Container numbers should use the same check rule. When a recognition result conflicts with an RFID tag, there has to be a manual-confirm flag. Both paths must not write "confirmed" at the same time. Container steel, gantry structure, and quay spreaders change the signal around an antenna. The module belongs outside the cab, or on a remote antenna, and the coverage should be tried along the gantry travel path.
The equipment should be able to queue locally. During a cell handover, a short loss of service, or a master-station rejection, events stay on the equipment in order and are sent later with their original time, rather than sending only the current slot and covering the moves in between. If the master station whitelists by source address, a change in the SIM's address causes a stretch of rejections. It looks as if the equipment is offline while the attach is still up. When release information is exchanged with the Single Window, the container state in the terminal system should already be closed. An internal event that is not closed should not be treated as proof of arrival on the customs side.
A slot that lags, and a gate move posted twice
A slot usually lags when the set-down confirmation fails to send and the driver has already left on the field instruction. The system still shows the old bay. The next order goes to an empty cell or to a cell that already holds a box. A duplicate gate move is the opposite: a gate retry sends the same container in twice, the system creates two in-yard records, and at gate-out it is unclear which one to close. A retry has to carry the same event id. The master station deduplicates on that id, updates the arrival time, and does not create a new move.
A weight tied to the wrong container move also leaves a false record. The truck number on the weighbridge ticket matches, but the container number comes from the previous truck's recognition cache, and the weight is booked to the wrong box. A night shift that only checks whether equipment is online, and does not sample event-id continuity or slot positions, piles these errors up until stowage finds them the next day. If yard management and gantry crane data keeps its own set of slots, the two sides need to agree which one is the slot of record after set-down. When both coordinates can be written, an older message that arrives later writes the new position back.
When a yard crane works the same bay continuously, the start cell of the next move should match the target cell of the previous move, or the temporary cell after a reshuffle. If it does not, automatic slot updates should stop, and the shift should check whether a move was missed or a container number was read as the box beside it. If a quay-crane discharge confirmation enters only the bay plan and not yard receipt, the system thinks the box has left the ship while the yard has no cell to pick it from. A backfill has to keep both event ids, the ship confirmation and the yard receipt. Once they are merged into one "in yard" record, the missing receipt cell cannot be recovered. When an external truck is called to the gate, that receipt record should already be closed.