Navis N4 is the platform most likely to appear on a container terminal shortlist anywhere in the world, and the one
most often misunderstood before it is bought. This article explains what N4 is, how it relates to the older SPARCS
product, which terminals it genuinely suits, and what a recognition layer has to do to connect to it cleanly. Docker
Vision sells no platform, so this is written from
the integration side
rather than the sales side.

Key Takeaways

• Navis N4 is the current generation flagship. SPARCS is the earlier product line, and terminals still refer to Navis
  SPARCS when they mean the older deployment they are migrating away from.
• N4 rewards scale and complexity. Below roughly half a million containers a year, much of what you pay for is
  planning depth that will never be configured.
• Integration is well trodden. N4 has the largest ecosystem in the category, which makes connecting a gate OCR layer a
  known quantity rather than an experiment.
• The questions worth asking before committing are about staffing, interface licensing, upgrade testing and data
  extraction, not about feature coverage.

What Navis N4 Is and How It Differs From SPARCS

Navis N4 is an enterprise terminal operating system used by container terminals worldwide to plan vessel operations,
manage the yard, dispatch equipment, process the gate and produce billing. It is the successor to the SPARCS product
line and the platform most commonly named when terminal software is discussed.

SPARCS was the earlier generation and is still referred to constantly, partly because many terminals ran it for years
and partly because the naming overlapped during the transition. When a tender mentions Navis SPARCS today it usually
means a legacy installation being replaced or extended.

The practical difference is architectural. N4 was built around a modern application stack with broader integration
surfaces, while SPARCS reflected the design assumptions of an earlier era. For a terminal evaluating today, N4 is the
live product and SPARCS is context.

What N4 brings is depth. Stowage planning that accounts for weight distribution and discharge sequence, yard
strategies that adapt as the stack fills, equipment dispatch that keeps machines working, and reporting detailed
enough to satisfy shipping line customers and regulators alike.

It also brings an ecosystem, which is underrated. Because so many terminals run it, integration patterns are
documented, consultants exist in most regions, and a vendor connecting to it has almost certainly done so before. That
reduces project risk in a way no feature list captures.

The trade is complexity. N4 is configured rather than merely installed, and the configuration is where the value is
unlocked or lost. A terminal that treats it as shrink wrapped software will get a very expensive version of what it
already had.

Where N4 Fits and Where It Is Over Specified

N4 fits terminals with genuine planning complexity. Multiple berths, high move counts, mixed vessel sizes, congested
yards and demanding shipping line service levels all create optimisation problems worth solving with software, and at
that scale a few percent of crane productivity is real money.

It fits terminal groups too. An operator running several facilities gains from standardising the platform, because
staff move between sites, reporting consolidates and the group negotiates once rather than five times. Local fit is
traded for consistency and that is a defensible choice.

It fits terminals with a systems function. If you employ people whose job includes configuring and tuning the
platform, N4 will repay them. If your systems function is one person who also manages the network and the CCTV estate,
the depth will sit unused.

It is over specified for the mid sized independent terminal, which is the most common mismatch in this market. Under
roughly half a million containers a year, with a single berth or an inland depot operation, the planning modules that
justify the cost rarely get switched on.

It is also over specified where the real constraint is data quality rather than planning. A terminal whose gate is
keyed by hand and whose yard inventory drifts will not be rescued by better optimisation, because the optimiser is
reasoning about a yard that does not exist.

That is worth testing before a selection rather than after. Instrument the gate, measure your discrepancy rate, and
see how much of your apparent planning problem is actually an input problem. Our guide to
why manual gates stop scaling
covers the measurement.

Connecting a Gate OCR Layer to N4

The good news for anyone integrating recognition with N4 is that the path is well established. The platform exposes
documented interfaces for gate transactions, and a recognition vendor with experience in the category will have
connected to them before, which turns a bespoke project into a configuration exercise.

The payload is the part that needs care. N4 wants the owner code and serial number formatted to
ISO 6346 with the check
digit validated, the size and type code, and the event context of lane, direction and timestamp. Sending anything less
means the match to the booking is guesswork.

Confidence handling is where good integrations separate from adequate ones. Passing the recognition score through lets
you write rules inside N4 that treat a high confidence read as authoritative and route a low confidence read to a
clerk. Without the score every read looks equally certain, which is false.

Exception design deserves an explicit session. What happens when the read does not match any expected booking, when a
container arrives twice, or when the code is physically unreadable because the panel is damaged. These are business
rules and the platform will do exactly what you configure, including nothing.

Image evidence should be referenced rather than stored inside the platform. Keep the frames in the recognition layer
and pass a pointer, so that a claim six months later can be settled by retrieving the image without bloating the
operational database. The client describes the flow in
from camera to platform in realtime.

Finally, agree how upgrades will be handled. N4 versions change, and an integration that was written against a
documented interface survives that far better than one that reached into the database. Insist on the supported route
even when a shortcut is offered.

Questions to Ask Before Committing

Ask how many administrators the implementation assumes, and get the answer as a number of people rather than an
adjective. Then compare it honestly with what your organisation will actually fund after the project team disbands,
because that is the staffing the platform will really have.

Ask what the interfaces cost. Whether gate, equipment and reporting interfaces are included or separately licensed
changes the economics of every automation project you will run for the next decade, and it is much easier to negotiate
before signature than after.

Ask who tests upgrades and how long a version upgrade takes in a terminal of your size. A platform that needs a month
of regression testing per upgrade is a real operational commitment, and you should know that before it appears in your
maintenance calendar.

Ask for a reference site of your size in your region. Not the flagship deployment at a transhipment hub, but a
terminal with your volumes and your staffing, and then ask that terminal what the first year was actually like. This
single call is worth more than any evaluation matrix.

Ask what data extraction looks like. What formats, how long, what cost, and whether historical operational data comes
with it. You are unlikely to leave, and the quality of the answer still tells you a great deal about how the
relationship will be run.

Finally, ask what the platform will not do. A vendor who names limits candidly is easier to work with than one who
says yes to everything, and the limits they name are the layers you should be sourcing independently anyway. See our
note on
vendor neutral automation
for why that matters.

Conclusion

Navis N4 is a strong platform aimed at a specific kind of terminal: large, complex, and staffed to run it. Terminals
that match that profile get real value. Terminals that do not tend to pay for depth they never configure, and would be
better served by a lighter platform plus an independent automation layer. Whichever you run, the recognition layer
should stay portable.
Ask Docker Vision how gate
data would flow into your installation.

Frequently Asked Questions

What is Navis N4 used for?

Navis N4 is an enterprise terminal operating system. Container terminals use it to plan vessel stowage and discharge,
manage yard slots, dispatch equipment, process gate transactions and produce billing and regulatory reporting from a
single record.

What is the difference between Navis N4 and SPARCS?

SPARCS is the earlier Navis product line and N4 is the current generation, built on a more modern architecture with
broader integration surfaces. Tenders that mention Navis SPARCS today usually refer to a legacy installation being
replaced.

Is Navis N4 suitable for a mid sized terminal?

Sometimes, but it is frequently over specified. Below roughly half a million containers a year, and without dedicated
systems staff, much of the planning depth that justifies the cost is never configured and never used.

How hard is it to integrate gate OCR with N4?

It is a known quantity rather than an experiment. N4 exposes documented gate interfaces and has the largest
integration ecosystem in the category, so an experienced recognition vendor will have connected to it many times
before.

What data does N4 need from an OCR system?

The owner code and serial number validated against ISO 6346, the size and type code, lane, direction, timestamp, a
confidence score and a reference to the stored image. The confidence score is what makes automated exception routing
possible.

Should image files be stored inside N4?

No. Keep the frames in the recognition layer and pass a pointer instead. That keeps the operational database lean
while still allowing a disputed claim to be settled months later by retrieving the original captured image.

Does N4 include gate OCR of its own?

Gate automation is generally sourced as a separate layer. Keeping it independent means a later platform change does
not force you to replace your cameras, your accuracy baseline and your gate process at the same time.

How long does an N4 implementation take?

Enterprise implementations commonly run two to four quarters once configuration, integration and testing are counted.
Ask specifically about a terminal of your size rather than the flagship reference site, because the two timelines
differ considerably in practice.

What should we ask an existing N4 site?

Ask what the first year was hardest at, how many people administer it now, and what an upgrade costs in effort. Our
overview of
AI trends in terminal operations
covers what changes around the platform.