Ask five terminal managers what a terminal operating system tos does and you will get five answers, most of them too
broad. The software is powerful and narrow at the same time, and knowing exactly where its edges sit is what stops a
terminal buying the wrong thing, or
connecting a recognition layer to the wrong part of it. This article sets out the five modules every platform contains, the four jobs no platform can do alone, and a quick
test of whether yours is earning its licence fee.

Key Takeaways

• A terminal operating system tos is a planning and record keeping system. It decides what should happen and records
  what was reported, which is not the same as knowing what happened.
• Five modules appear in every platform: vessel planning, yard planning, gate processing, equipment control and
  billing. Everything else is a variation on those five.
• The four jobs it cannot do are identity capture, physical positioning, condition assessment and equipment health,
  all of which need an observation the software has no way to make.
• A platform that spends most of its day being corrected by people is not underpowered, it is underfed. The fix is
  usually better input data rather than a bigger licence.

What the Letters Stand For and What the Software Does

TOS stands for terminal operating system, and the phrase is used interchangeably with terminal operation system in
tender documents across the region. The product category covers software that plans, sequences and records cargo
movement inside a marine or inland terminal, from the moment a vessel is announced to the moment a truck leaves the
gate.

The mental model that helps most is a ledger with a scheduler attached. The ledger holds the authoritative position of
every container and every piece of equipment. The scheduler decides which move happens next and who performs it. Every
screen in the product is a view onto one of those two things.

That is a genuinely large job. A mid sized terminal handling three hundred thousand containers a year performs well
over a million individual moves, each of which has to be planned, dispatched, confirmed and billed. Doing that on
spreadsheets is possible and is why some terminals still have very tired planners.

It is also a job with a hard boundary. The platform is authoritative about intent, not about reality. It records that
a move was completed because somebody or something reported completion. If that report was wrong, the platform is
confidently wrong until an independent observation corrects it.

This is not a criticism of the software category. Ledgers are supposed to trust their inputs. It does mean that the
quality of a terminal operating system tos deployment is determined more by what feeds it than by which product was
chosen, which is the opposite of how most selections are run.

Terminals that understand this spend their budget differently. They buy a platform that fits, then invest in making
its inputs trustworthy, rather than buying the most capable platform and feeding it the same manually keyed data they
used before.

The Five Modules Every Platform Contains

Vessel planning is the first. It handles the stowage plan, the discharge and load sequence, crane allocation and berth
scheduling. On a busy quay this is where the most sophisticated optimisation lives, because a poorly sequenced
discharge costs hours of container crane time that cannot
be recovered.

Two jobs inside vessel planning deserve their own mention. The first is EDI and file processing. The module ingests
the inbound BAPLIE bay plan and COPRAR loading and discharge instructions from the shipping line, reconciles any
discrepancies against the manifest, and generates the outbound departure BAPLIE and COARRI messages once the vessel
has been worked. When those files disagree, this is where the planner finds out, ideally before the vessel is
alongside rather than during the operation.

The second is IMDG and safety compliance. The plan is checked against the three dimensional segregation rules of the
International Maritime Dangerous Goods (IMDG) Code, which govern how far apart incompatible hazardous cargo must sit
across bays, rows and tiers. The module also checks deck lashing forces and stack weight limits, and verifies that the
stow does not breach the SOLAS bridge visibility line. A plan that fails any of these checks cannot sail, however
efficient its crane sequence looks.

Yard planning is the second. It assigns arriving containers to slots, manages stack heights, plans repositioning and
tries to minimise the moves needed to retrieve a box later. Good yard planning is invisible. Bad yard planning shows
up as reshuffles nobody scheduled.

Gate processing is the third and the one closest to the outside world. It matches arriving trucks against bookings,
validates container identity, checks documentation, produces the interchange receipt and releases the vehicle. It is
also the module most often left running on manual data entry.

Equipment control is the fourth. It dispatches work to cranes, straddle carriers and internal vehicles, tracks who is
doing what, and records completion. In more automated terminals it also drives the machines directly rather than
instructing a driver.

Look ahead queue management sits inside this module. Rather than releasing one job at a time, the system regulates the
dispatch queue so that each crane, straddle carrier and internal vehicle already holds its next few moves, sequenced
so that horizontal transport reaches the quay crane just as the crane needs it. A well tuned queue keeps the crane
working. A badly tuned one leaves trucks waiting under the boom, or the crane waiting for trucks.

Billing and reporting is the fifth. Every move, every storage day and every ancillary service has to become an invoice
line, and every regulator and shipping line customer wants a report. This module is unglamorous and is often the
reason a terminal cannot change platform easily.

Anything a vendor presents beyond these five is usually a specialisation of one of them, or an adjacent layer being
sold as part of the platform. Knowing the difference matters when you compare quotations, because adjacent layers are
frequently things you can buy independently and better.

Four Things a Platform Cannot Do Without Help

The first is identity capture. A container arriving at the gate has a code painted on it and the platform has no way
to read it. Somebody types it, or a camera reads it. There is no third option, and the choice between those two sets
your error rate for every downstream process.

The second is physical positioning. Once a box is in the yard, the platform believes it is where the last completed
move said it is. Any unreported movement, mis keyed slot or equipment error creates a silent divergence that persists
until a person searches for the container and fails to find it.

The third is condition. Whether a container arrived with a dented panel, a broken seal or a failed refrigeration unit
is a visual and sensory judgement. Terminals that rely on a driver walk around and a paper note are relying on the
least reliable link in the whole chain to protect them from claims.

The fourth is equipment health. The platform knows a crane completed forty moves. It does not know that the hoist
motor is drawing more current than it did last month, or that a spreader is taking longer to lock. Those are
maintenance signals and they need instrumentation the platform does not have.

Each of these gaps has a cost that can be measured. Identity errors show up as gate rework and misdelivery. Position
errors show up as search time and unproductive moves. Condition gaps show up as disputed claims. Equipment gaps show
up as unplanned downtime during peak.

The useful discipline is to price each gap before shopping for a solution. A terminal that knows it loses four hundred
hours a year to container searches has a specific problem with a specific budget, which is a far better starting point
than a general wish to be more automated.

How to Tell Whether Yours Is Working Hard Enough

The first test is the override rate. Count how often planners manually overrule the system recommendation for slot
allocation or work sequencing. A high override rate usually means the system is working from data the planners know to
be wrong, which is an input problem wearing a software costume.

The second is the search rate. How many times a week does somebody have to physically look for a container that the
platform says is somewhere it is not. Most terminals have never counted this, and the number is usually higher and
more expensive than anyone expected.

The third is gate dwell. Time the transaction from arrival at the gate to release, and separate out the portion spent
keying and verifying identity. If a meaningful share of the total is data entry, the platform is not the constraint
and no upgrade will fix it.

The fourth is the unused module count. Walk the product menu and mark which modules your team actually uses in a
normal week. Paying enterprise licence fees for planning optimisation that nobody has configured is a very common and
very quiet waste.

The fifth is the spreadsheet census. Ask each department which spreadsheets they maintain alongside the platform and
why. Every one of those is a gap the software did not close, and reading them together gives you a more honest
requirements list than any vendor workshop will.

Run those five and you will usually find the same conclusion. The platform is adequate and the data reaching it is
not. That is a cheaper problem to fix than a migration, and it is where
any evaluation of a supplier
should start rather than end.

Conclusion

A terminal operating system tos plans and records. It does not see, and it cannot verify itself. Every terminal that
has been disappointed by a platform bought it expecting perception and received accounting, which was always what the
category offered. Get the five modules working on data you can trust and the software will do what it was built for.
If you want to understand where your own inputs are weakest,
ask Docker Vision for a gate data review.

Frequently Asked Questions

What does TOS stand for in a container terminal?

TOS stands for terminal operating system, the software that plans and records cargo movement inside the terminal.
Tender documents in the region also use terminal operation system for the same category, and the two phrases mean the
same thing.

Is a terminal operating system the same as a warehouse management system?

No. A warehouse system manages goods on shelves inside a building. A terminal system manages containers, vessels,
cranes and gates across an open yard, with berth planning and equipment dispatch that warehouse products do not
contain.

Can a small terminal run without a platform at all?

Some very small operations still run on spreadsheets, and it works until volume or audit requirements catch up. The
practical limit is usually reached when planners cannot reconstruct what happened yesterday without asking three
people.

Why does our platform keep showing containers in the wrong slot?

Because it records reported moves rather than observed ones. Any unreported repositioning or mis keyed slot creates a
divergence that persists silently. Closing it needs an independent observation of physical position rather than a
software setting.

Does upgrading the platform improve data accuracy?

Rarely on its own. A newer platform records the same inputs more elegantly. If the container number is still being
typed by a clerk at the gate, the error rate stays broadly where it was before the upgrade was paid for.

Which module should a terminal automate first?

Gate processing, almost always. It is the module with the highest manual content, the simplest data to capture, and
the fastest visible benefit in truck turn time, which makes it the easiest case to prove to a finance team.

How many people are needed to administer a platform?

Enterprise products assume a dedicated systems team. Lighter products are designed to be run by one or two people
alongside other duties. Mismatching this is the most common cause of an expensive platform sitting half configured.

Can Docker Vision feed data into any platform?

Yes. The dOCR engine is built to integrate through whichever interface your platform exposes, and Docker Vision sells
no competing system of its own. Our post on
edge processing inside the terminal
explains where the reads actually happen.

What is the quickest way to test whether ours is underperforming?

Count planner overrides, container searches and gate keying time across one full week. If those three numbers are
high, your inputs are the problem rather than the software. Our guide to
reading a container in realtime
explains the fix.