TOS module
Vessel & Berth Planning
11 buyer-selectable criteria in the current taxonomy.
Specialist research · Ports, maritime & terminal operations
Terminal Operating Systems for Container Ports & Cargo Operations
TechSelectAI maintains a specialist, evidence-based research model for selecting Terminal Operating Systems (TOS) used in container port management and mixed-cargo terminal operations. The model focuses on operational requirements—not review popularity—and separates verified product capability evidence from buyer-specific fit scoring.
7 active TOS products85 specialist TOS criteria3 mobile-access criteria tracked separately68 recorded evidence sources
What a modern TOS evaluation needs to cover
A Terminal Operating System decision goes far beyond a generic software feature list. TechSelectAI's specialist model organizes the operational questions buyers commonly need to validate during discovery, shortlist, RFP and reference checks.
TOS module
Yard Strategy & Inventory
11 buyer-selectable criteria in the current taxonomy.
TOS module
Gate, Truck & Landside Operations
11 buyer-selectable criteria in the current taxonomy.
TOS module
Rail & Intermodal Operations
7 buyer-selectable criteria in the current taxonomy.
TOS module
Equipment Dispatch & Automation
10 buyer-selectable criteria in the current taxonomy.
TOS module
Reefer, DG & Special Cargo
7 buyer-selectable criteria in the current taxonomy.
TOS module
Integration, Data & Ecosystem
11 buyer-selectable criteria in the current taxonomy.
TOS module
Billing, Analytics & Operational Control
9 buyer-selectable criteria in the current taxonomy.
TOS module
Platform Architecture, Resilience & Security
8 buyer-selectable criteria in the current taxonomy.
Berth planning and berth management software in a TOS
Berth planning software in container-terminal environments typically sits inside, or alongside, the Terminal Operating System. Buyers should validate vessel-call planning, berth allocation, quay/stowage execution, real-time plan updates and any companion planning modules rather than assuming every TOS includes the same berth-management scope.
RTG / RMG operations software inside a TOS
RTG and RMG operations are usually part of the TOS equipment-dispatch layer rather than a standalone software category. Buyers should validate RTG/RMG dispatch, yard-priority sequencing, work queues, equipment availability, position/status inputs, VMT execution and any optimization or automation modules as separate evidence-backed requirements.
TOS integration: EDI, APIs and external systems
Terminal Operating System integration is broader than a single API checkbox. Buyers should validate carrier EDI, REST/web services, event or streaming patterns, PCS/customs, gate and OCR subsystems, reefer platforms and finance/ERP interfaces as separate evidence-backed requirements with product, module and implementation scope kept explicit.
Container yard efficiency and throughput inside a TOS
Container-yard efficiency is not a single feature. Buyers should validate yard strategy rules, block and stack allocation, automated decking or grounding, import/export segregation, housekeeping and remarshalling, rehandle minimization, yard density/capacity visibility and exception handling as separate evidence-backed requirements. Throughput improvement depends on the operating model, equipment, data quality, integrations and configuration rather than a generic TOS label.
Current TOS research dataset
Research coverage is not a product score or ranking. It measures how much of the current TOS capability model has a known evidence status. Research pending means not yet verified—not unsupported—and does not imply lower product quality.
DP World
CARGOES TOS+ (Zodiac)
DP World-developed terminal operations suite, historically known as Zodiac, with OPS and optional suite modules spanning billing, auto gate, yard and equipment optimization, automation, RTLS and operational analytics.
34% research coverage30 / 88 known facts
CyberLogitec
CyberLogitec OPUS Terminal
Integrated container terminal operating system for berth, vessel, yard, gate, rail and equipment operations with optimization and semi-to-fully automated terminal support.
40% research coverage35 / 88 known facts
Kaleris
Navis Mixed Cargo TOS
Kaleris General Cargo / Navis Mixed Cargo TOS, formerly MTN / Master Terminal, for multipurpose terminals handling containers, breakbulk, dry and liquid bulk, project cargo, RoRo, vehicles and other mixed cargo across vessel, yard, gate, truck, rail and barge operations.
25% research coverage22 / 88 known facts
Kaleris
Navis N4 TOS
Navis N4 terminal operating system from Kaleris for complex container terminals, covering planning, execution, automation integration, optimization, operational visibility and enterprise terminal workflows.
52% research coverage46 / 88 known facts
Realtime Business Solutions
RBS TOPS Expert
Terminal operating system family for real-time container-terminal planning and execution across vessel, berth, yard, gate, rail, equipment, automation and operational analytics.
63% research coverage55 / 88 known facts
Tideworks Technology
Tideworks Mainsail
Marine terminal operating system for cargo, inventory, vessel activity and gate operations, supported by Tideworks planning, equipment-control, customer-visibility and EDI companion products where selected.
51% research coverage45 / 88 known facts
Total Soft Bank
Total Soft Bank CATOS
Container terminal operating system for berth, ship, rail, gate and yard planning with equipment supervision, optimization, EDI connectivity and operational analytics.
51% research coverage45 / 88 known facts
How to interpret TechSelectAI TOS evidence
Not yet verified does not mean not supported. It means the current TechSelectAI evidence set has not established the exact capability. Vendor RFP responses, project-specific configuration, implementation documentation or terminal references may verify additional capability.
SupportedCurrent evidence establishes the capability for the evaluated product or documented scope.
Conditional / partialThe capability may depend on an edition, add-on, companion module, third-party integration or implementation scope.
Not yet verifiedEvidence is incomplete. TechSelectAI does not convert missing evidence into a negative product claim.
Not supportedUsed only when evidence establishes that the evaluated product does not support the capability.
Designed for TOS procurement and technical evaluation
1. Define terminal requirementsCapture vessel, yard, gate, rail, equipment, automation, cargo, integration, billing, resilience and security needs.
2. Review evidenceSeparate demonstrated product capability from optional modules, implementation examples and claims that are still unverified.
3. Build the shortlistCompare products against the buyer's actual must-have criteria rather than a generic market popularity list.
4. Validate through RFPUse vendor responses, architecture workshops, reference terminals and implementation evidence to close remaining research gaps.
Research transparency
TechSelectAI is not claiming that every TOS capability is permanently verified or universally included in every implementation. Optional modules, companion products, integrations and project-specific configurations are kept explicit where the available evidence requires that distinction. Evidence confidence and product fit are separate signals.
Terminal Operating System implementation roadmap
A TOS implementation is an operating-model transformation touching vessel, yard, gate, equipment, billing, external interfaces and terminal-control processes. The implementation plan should therefore be built around terminal flows and exception recovery, not only application installation.
Why this matters: software selection is incomplete until the buyer can explain how the chosen solution will be configured, integrated, tested, cut over and supported. This framework is vendor-neutral; exact installation commands and sizing must come from the selected vendor and implementation partner.
1. Operational discovery
Freeze the target operating model before configuration.
- Map vessel, yard, gate, rail, equipment, reefer, dangerous-goods, billing and exception flows.
- Baseline truck turn time, yard rehandles, equipment productivity, berth/vessel KPIs and manual interventions.
- Define future-state responsibilities between operations, planning, IT, finance and external stakeholders.
2. Terminal model configuration
Translate the physical and operational terminal into controlled master data and rules.
- Model terminal layout, blocks, rows, stacks, lanes, berths, equipment, service definitions and calendars.
- Define yard strategies, work queues, allocation rules, operational statuses and exception codes.
- Document which behaviors are standard configuration, custom logic, companion module or external subsystem responsibility.
3. Integration & automation
Prove every operational interface and its recovery path.
- Catalogue EDI, API, PCS/customs, OCR/ANPR, gate, VBS, reefer, equipment-control, ERP/billing and reporting interfaces.
- Define idempotency, retries, sequencing, monitoring, reconciliation and manual fallback for each critical interface.
- Validate automation boundaries and safe degraded modes for equipment or gate subsystems.
4. Data migration & rehearsal
Enter cut-over with reconciled operational data.
- Classify master, reference, historical and open operational transactions.
- Run repeatable migration rehearsals with record counts, financial totals and operational reconciliations.
- Rehearse open vessel calls, yard inventory, appointments, holds, reefer and dangerous-goods states.
5. Operational acceptance
Test the terminal, not just screens.
- Run representative vessel, gate, yard, equipment and exception scenarios end-to-end.
- Load-test critical interfaces and peak operational windows.
- Test TOS/network/subsystem interruption, BCP operation and post-restore reconciliation.
6. Cut-over & stabilization
Make go-live controlled and reversible.
- Use a minute-by-minute cut-over plan with freeze windows and rollback criteria.
- Establish command center, vendor escalation, hypercare shifts and KPI monitoring.
- Compare post-go-live productivity and exception rates against the pre-implementation baseline.
Configuration and architecture questions
Use these questions during discovery, solution design, vendor workshops and implementation governance. They are intended to expose hidden dependencies before they become change requests.
Terminal topology
- How are blocks, lanes, berths, equipment and operational zones represented?
- Which changes require downtime, migration or re-planning?
- How are temporary or overflow areas governed?
Operational rules
- Which yard strategy, dispatch, planning and exception rules are configurable?
- How are rules versioned, approved and moved between environments?
- What operational behavior depends on custom code?
Interfaces
- Who owns carrier EDI mappings and external certificates?
- How are duplicates, late messages and replay handled?
- What is the manual fallback if a gate/OCR/PCS/equipment interface fails?
Resilience
- What functions remain available during WAN, database or subsystem outages?
- What RPO/RTO is contractually supported?
- How is open transactional state reconciled after recovery?
Implementation acceptance tests
A demo can establish product potential; acceptance testing must prove the configured solution in the buyer's operating model. These scenarios should be adapted into formal UAT and operational-readiness evidence.
| Scenario | What to prove | Evidence to retain |
|---|---|---|
| Vessel-to-yard flow | Discharge/load planning, execution updates, exceptions and inventory accuracy across a representative vessel call. | Scenario script, timestamps, inventory reconciliation, interface logs and business sign-off. |
| Truck gate journey | Appointment/pre-advice, OCR/ANPR, driver/truck/container validation, lane exception and completion. | Turn-time record, gate transaction logs, exception evidence and fallback result. |
| Yard exception | Unplanned location, blocked equipment, rehandle, hold, reefer or dangerous-goods exception without corrupting inventory. | Before/after inventory, work instructions, audit trail and supervisor approval. |
| Interface outage | Critical carrier/PCS/gate/equipment interface unavailable and later restored. | Queued/retried messages, reconciliation totals, manual workaround and recovery timing. |
| BCP recovery | TOS or core infrastructure interruption followed by controlled restoration. | RTO/RPO result, BCP transactions, reconciliation evidence and unresolved exceptions. |
Implementation evidence pack
Before final acceptance, retain an auditable package covering the following artifacts.
Architecture & scope
- Approved solution architecture
- Environment and responsibility matrix
- Licensed modules / edition scope
- Security and identity design
Configuration & data
- Configuration workbook and change history
- Master-data ownership and migration mapping
- Interface inventory and reconciliation rules
- Known limitations and accepted design decisions
Testing & cut-over
- UAT scenarios, defects and retest evidence
- Performance/resilience/recovery results
- Cut-over schedule and rollback criteria
- Business continuity and manual fallback procedures
Operations
- Monitoring and alert ownership
- Backup/recovery and DR runbook
- Support/escalation matrix and hypercare plan
- Upgrade/patch governance and periodic access review