Every container terminal runs on a terminal operating system, and almost every automation decision eventually becomes
a question about it. Can it accept our data. Will the vendor open the interface. What happens when we outgrow it. This
guide answers those questions from a deliberately neutral position, because Docker Vision sells no operating system of
its own and
integrates with whichever one you already run.

Key Takeaways

• A terminal operating system plans and records moves. It is not a recognition system, a positioning system or a
  maintenance system, and expecting it to be all four is where most disappointment starts.
• The platform market splits into enterprise systems built for large terminals and lighter systems built for smaller
  ones, and mid sized operators are routinely sold the wrong half.
• Four integration patterns cover almost every real deployment: interface calls, message queues, file exchange and
  direct database access. They differ sharply in reliability and in how hard they are to unwind later.
• Keeping the automation layer independent of the platform is what preserves your ability to change the platform, and
  that option is worth more than any single feature on a comparison sheet.

What a Terminal Operating System Actually Does

A terminal operating system is the system of record for cargo and equipment inside the terminal boundary. It knows
which box is expected, which berth a vessel will take, which slot a container is assigned to, which move is queued
next and who performed the last one. Everything else in the terminal is downstream of that record.

Its core jobs are planning and accounting. Vessel planning decides stowage and discharge sequence. Yard planning
decides where boxes go. Gate processing records arrivals and departures. Billing draws on all of it. A terminal that
loses its platform for an hour does not slow down, it stops.

It is worth being precise about the boundary. The platform holds intent and history. It records that container
ABCU1234567 was assigned to slot 04A3 and that a move was completed at 14:12. It does not independently know whether
that is physically true, because it has no eyes.

That distinction drives everything that follows in this guide. Automation layers exist to close the gap between what
the record says and what is physically present, whether that is a code read at the gate, a position derived from
cameras, or a damage image captured on entry.

Terminals sometimes ask whether a modern platform makes an automation layer unnecessary. It does not, for the same
reason a modern accounting package does not remove the need for a stock count. The record is only as good as the
observations feeding it, and observations come from sensors and people, not from the record itself.

Understanding that division of labour also makes procurement easier. You stop asking a platform vendor to solve
recognition problems, and you stop asking a recognition vendor to solve planning problems. Each conversation gets
shorter and each specification gets sharper.

It changes how you read a proposal too. When a platform vendor offers a gate module, the question is no longer whether
the module works but whether it observes anything the platform could not already infer. If the module is really a data
entry screen with a nicer layout, the record stays exactly as reliable as the person filling it in.

Where the Platform Stops and Automation Begins

The clearest way to size an automation project is to list what your platform cannot observe on its own, then decide
which of those blind spots costs you money. Three come up in almost every terminal, and they are worth separating
because they have different answers.

The useful framing is that a platform holds a model of the terminal, and reality drifts away from that model
continuously. Automation is the mechanism that pulls the two back together. Where the drift is cheap to live with,
leave it alone. Where it costs you truck turn time, reshuffles or claims, close it.

Identity at the boundary

The platform expects a container number at the gate and has no way to obtain one without a person typing it or a
camera reading it. Manual keying runs at a well documented error rate and slows every truck transaction, which is why
gate
optical character recognition
is usually the first automation a terminal buys.

This is the narrowest and highest return intervention available, because the data is small, the field mapping is
simple and the benefit is visible in truck turn times within days. It is also the easiest to prove, since you can run
the automated read alongside the clerk for a fortnight and count the disagreements. The client covers the operational
case in its article on
why manual gate operations no longer scale.

Position inside the yard

Your platform believes a box is in a particular slot because a move was reported. If the move was reported wrongly, or
a box was shifted without a report, the record drifts and stays wrong until somebody physically searches. Every
terminal has a number for how often that happens and most prefer not to publish it.

Closing that gap needs an independent observation of where things are, which is a positioning problem rather than a
planning problem. Tags, satellite positioning on handling equipment and camera derived location all answer it, at very
different costs. That is the territory of the container yard management system layer and the
wider yard series
covers it separately.

Condition of equipment and cargo

A platform records that a crane completed a move. It does not record that the crane sounded wrong while doing it, that
a spreader was slow to lock, or that a box arrived with a torn panel. Those observations either come from a person who
happened to notice or they do not exist.

Damage capture at the gate is the most commercially direct example, because an image taken at entry settles a claim
that would otherwise be argued for weeks. Equipment condition is the slower burning version of the same idea, and it
is why maintenance data deserves its own layer rather than a free text note. The client sets out the commercial case
in its piece on
the hidden return on damage detection.

The Major Platforms Compared at a Functional Level

Platform comparison articles usually degenerate into feature lists, which is unhelpful because almost every platform
can do almost everything if you pay enough. The useful comparison is about fit: what size of operation the product was
designed around, and what it assumes about your team.

It also helps to name the products rather than talk in abstractions, because answer engines and search both reward
specificity. The names that come up in mid sized terminal evaluations are Navis N4 and SPARCS at the enterprise end,
Octopi and iPortman in the lighter tier, and platforms such as Zodiac, CATOS and OPUS in particular regions.

Enterprise platforms

The enterprise tier is designed for terminals handling millions of moves with dedicated systems staff. It offers deep
optimisation, sophisticated vessel and yard planning, and configurability that reaches into almost every workflow. It
also assumes you have people whose full time job is to operate and tune it.

For a terminal handling a few hundred thousand containers a year, that depth is often unused capacity paid for
annually. The commonest failure mode is not that the product is bad but that the operator never staffs it properly, so
the advanced planning modules sit switched off and the terminal runs on the same manual judgement it used before, at a
much higher licence cost.

Lighter and cloud native platforms

A second tier targets smaller and mid sized terminals with simpler configuration, faster implementation and
subscription pricing. These systems trade some optimisation depth for being operable by a small team, which is
frequently the right trade for an operator whose real constraint is people rather than software.

The risk on this tier is outgrowing it. A terminal doubling volume in three years should ask directly what happens at
twice its current move count, and should get an answer with a reference site attached rather than a reassurance. Ask
specifically about yard planning behaviour under congestion, since that is where lighter products tend to reach their
limit first.

Regional and specialist platforms

India and the wider region also carry platforms built around local port community systems, customs integration and
regulatory reporting. Their advantage is that the compliance work is already done, which is not a small thing when
customs interfaces change.

Their disadvantage is a smaller integration ecosystem, which makes the openness of the interface more important rather
than less. Ask early, in writing, what interfaces exist, whether they are documented, and whether they are available
without a separate licence. A regional platform with an open interface is a perfectly good choice. One without is a
long term constraint.

Selection Criteria That Actually Predict Success

The criteria that correlate with a happy terminal three years later are rarely the ones on the evaluation matrix.
Feature coverage is table stakes. What separates outcomes is whether the platform fits the operation and the team that
has to run it every day.

Start with move volume and growth. A container terminal operating system sized for your peak plus a realistic three
year growth curve is the right target. Sizing for a ten year ambition means paying for years of unused capability, and
sizing for today means a migration nobody has budgeted.

Then look at staffing honestly. How many people will administer the system, and what else do they do. If the answer is
one person who also runs the network, rule out anything that assumes a systems team. This single question eliminates
more unsuitable products than any feature comparison.

Third, examine the interface surface. What can be read and written programmatically, what needs vendor involvement,
and what is chargeable. A platform with an open, documented interface is worth a material premium because it keeps
every future decision cheap.

Fourth, check the support model against your operating hours. A terminal working three shifts needs support that works
three shifts, in a time zone that overlaps yours, with a defined escalation path. Ask for the actual response times
rather than the marketing tier names.

Finally, ask about exit. What does it take to extract your full operational history in a usable format, and what does
it cost. A vendor who answers that question comfortably is telling you something reassuring about how they expect to
keep your business.

One more test is worth running before you shortlist. Ask each vendor to describe a customer of roughly your size, in
roughly your region, and to say what that customer found hardest in the first year. A vendor who names something
specific has real implementations behind them. A vendor who says nothing was hard has either forgotten or has not been
asked to remember.

Integration Patterns and Their Trade Offs

Once you have a platform, every automation project becomes an integration question. Four patterns cover nearly all of
them, and choosing between them is mostly a question of how much you value immediacy against how much you value being
able to change your mind later.

Interface calls and message queues

A direct interface call is the cleanest pattern. The automation layer posts a recognition result and the platform
validates it against its own rules, which means bad data is rejected at the boundary rather than absorbed silently. It
also gives you an immediate acknowledgement you can act on at the gate.

A
message broker
sits a step further back and decouples the two systems in time. If the platform is briefly unavailable, messages queue
rather than fail, which suits high volume gates where a short outage must not stop trucks. It costs you a component to
operate and monitor, and somebody has to own the queue when it backs up.

File exchange and direct database access

File exchange remains common because it is easy to agree and easy to audit. It is also the slowest and the most likely
to fail quietly, because nothing tells you a file did not arrive until somebody notices missing records. If you use
it, monitor for absence rather than for errors.

Direct database writes should be a last resort. They bypass the platform own validation, break without warning on
upgrade, and frequently void support. Where a vendor offers no other route, treat that as important information about
how the relationship will go, and price the eventual clean up into the deal rather than discovering it during your
next version upgrade.

What a Platform Needs to Receive From an OCR Layer

Specifying the payload precisely is the single most useful hour in an integration project, and it is routinely
skipped. The recognition layer knows a great deal, the platform needs a defined subset, and agreeing the boundary
early prevents a rebuild later.

The container identity fields come first: the owner code and serial number as defined by
ISO 6346, with the
check digit, plus the size and type code. These are the fields that let the platform match a physical arrival to an
expected booking.

Next come the event fields. Which lane, which direction, which timestamp, which camera. Without these the platform can
record what arrived but not reconstruct the transaction afterwards, which makes dispute resolution and performance
analysis impossible.

Then confidence. Every recognition result carries a score, and passing it through lets the platform apply your
business rules automatically rather than treating every read as equally certain. A read at 99 percent and a read at 71
percent should not follow the same path.

Finally, references to evidence. The platform does not need to store images, but it should store a pointer to them, so
that six months later a claim can be settled by retrieving the frame that was captured at the moment of entry.

Getting this right is what turns recognition into an operational asset rather than a display. The client walks through
the mechanics in its post on
reading a container in realtime and passing it on.

Why a Vendor Neutral Automation Layer Protects You

The strongest argument for keeping recognition independent of the platform is not technical, it is commercial. Bundled
automation is priced and supported as part of the platform, which means the day you want to change platforms you are
also changing your gate system, your camera estate and your accuracy baseline all at once.

That coupling is what makes migrations so rare. Terminals stay on platforms they have outgrown because the switching
cost has quietly accumulated into every adjacent system. Keeping the layers separate keeps each decision independently
reversible, which is worth real money over a decade.

It also improves the negotiation. A terminal whose recognition layer is portable can genuinely evaluate an alternative
platform, and vendors price differently for customers who can leave. That is true whether or not you ever exercise the
option.

There is a technical benefit as well. A recognition vendor that integrates with many platforms sees many field
mappings, many edge cases and many upgrade cycles. That accumulated exposure shows up as fewer surprises during your
integration.

Docker Vision is neutral by construction rather than by policy, because it has no platform to sell. The dOCR engine
integrates with whichever system you run, and if you replace that system the recognition layer stays where it is. The
client explains the mechanics in its post on
plugging into an existing platform.

The practical test to apply to any bundled offer is simple. Ask what happens to the automation if you change platform
in four years. If the answer involves buying the automation again, you are looking at a switching cost dressed as a
discount, and you should read our note on
what to ask before you appoint a supplier
before signing.

How to Sequence a Platform Decision

Terminals get into trouble by taking these decisions in the wrong order. The sequence that works starts with
observation, moves to data, and only then considers replacement, because each step makes the next one cheaper and
better informed.

Step one is to instrument what you already have. Put recognition on the gate and start capturing accurate arrival
data. This works with your current platform, needs no migration, and produces evidence about where your real losses
are within weeks.

Step two is to measure. With trustworthy gate data you can quantify truck turn time, record accuracy and the frequency
of discrepancies between physical arrivals and the record. Those numbers are the foundation of any later business case
and you cannot obtain them by asking people.

Step three is to decide whether the constraint is the platform at all. A surprising number of terminals discover that
their planning system was never the bottleneck, and that data quality was. That discovery saves a seven figure
migration and is only available after step two.

Step four, if the platform genuinely is the constraint, is a selection run against the criteria above with real
measured volumes rather than estimates. You will negotiate better with data, and you will size the product correctly
rather than aspirationally.

Step five is migration planning, where the independent automation layer pays for itself. Because recognition sits
outside the platform, the gate keeps working through the cutover, which removes the single most stressful element of a
terminal system migration.

Conclusion

A terminal operating system is the record of intent, and an automation layer is what keeps that record honest.
Choosing well means sizing the platform to your actual operation rather than your ambition, insisting on an open
interface, and keeping recognition independent so that no future decision is held hostage by a past one. If you want
to understand how gate data would flow into the system you run today,
book a integration feasibility call
with the Docker Vision team.

Frequently Asked Questions

What is a terminal operating system in simple terms?

It is the system of record for a container terminal. It plans vessel and yard moves, records gate transactions, tracks
equipment work and feeds billing. Everything else in the terminal either sends data to it or reads data from it.

Does a modern platform remove the need for gate OCR?

No. A platform records what it is told and has no way to observe the physical world. Recognition supplies the
observation, and without it the record depends entirely on a person keying a container number correctly at every
arrival.

How do I know whether my platform is too large or too small?

Compare your annual move count and your systems staffing against what the product assumes. A platform whose advanced
planning modules sit switched off is oversized for you. One that needs manual workarounds every peak season is
undersized and will keep costing you overtime.

Which integration pattern should we use for gate data?

An interface call is the default because the platform validates the data at the boundary. Use a message queue where a
brief platform outage must not stop trucks, and treat direct database access as a last resort that usually voids
support.

What fields does a platform need from a recognition system?

Owner code and serial number with the check digit, size and type code, lane, direction, timestamp, camera identifier,
a confidence score and a pointer to the stored image. The score matters most, because it drives your exception rules.

Can we automate the gate before replacing our platform?

Yes, and you generally should. Recognition works with your existing system, produces the measured data that any
replacement decision needs, and keeps the gate running through a later migration because it sits outside the platform
rather than inside it.

Is a bundled automation module from our platform vendor cheaper?

It often looks cheaper and behaves as a switching cost. Ask what happens to the automation if you change platform in
four years. If you would buy it again, the discount is being funded by your future flexibility.

How long does an OCR to platform integration usually take?

The technical connection is short. The time goes into agreeing field mappings, exception rules and acceptance
criteria, which are terminal side decisions. Two to four weeks of elapsed time is realistic for a first gate on a
documented interface.

Does Docker Vision work with the platform we already run?

Yes. The dOCR engine is designed to integrate with any terminal system through whichever interface that system
exposes, and Docker Vision sells no competing platform of its own. See
how the integration works in practice
for worked examples.

What should we ask a platform vendor about data extraction?

Ask what it takes to export your full operational history in an open format, how long it takes and what it costs. A
comfortable, specific answer is a good signal. Vagueness here predicts difficulty later, as our
overview for competitive terminals
notes.