What is a terminal operating system?
Definition, scope and selection criteria, and why an intermodal terminal needs different software than a container port.
Definition
Terminal operating system in short
A terminal operating system (TOS) is the central software of a transhipment terminal. It brings arrival, handling, storage and departure of every loading unit together in one system: gate, train dispatching, yard management, handling equipment and billing all work off the same stock, kept current in real time.
Without a TOS, that information sits scattered across spreadsheets, paper forms and isolated tools. With one, every movement is documented, the yard stock is correct, and partners receive status messages automatically.
- One system instead of silos
- Real-time stock
- Automatic partner messages
Scope
What a terminal operating system actually runs
Pre-advice & order management
Bookings and inbound data arrive through interfaces or import before the train or truck does.
Gate handling
Entry and exit by reference number, driver identification, damage documentation. Without a TOS this is where the paper jam happens.
Yard management
Every slot georeferenced, every loading unit findable, repositionings as traceable orders.
Train dispatching
Wagon lists, load planning, wagon check at the track, arrival and departure messages to partners.
Handling equipment
Lifting orders appear directly on the crane or stacker terminal instead of being called over the radio.
Billing
Services delivered come out of operational data, not out of a list kept on the side.
Distinction
Deep-sea TOS or inland TOS: the difference that matters
The best-known TOS products come from deep-sea ports. They are built for volumes and organisations an inland or intermodal terminal does not have, and they bring the matching complexity and cost.
| Deep-sea TOS | Inland / intermodal TOS | |
|---|---|---|
| Typical volume | several hundred thousand to millions of units per year | tens of thousands to a hundred thousand |
| Modes in focus | vessel and road | rail and road, partly barge |
| Train dispatching | side topic | core process |
| Implementation | multi-year programme | weeks to a few months |
| Operations | dedicated IT team | usually no IT department |
| Licence model | high one-off investment | usage-based, modular |
Introducing a deep-sea TOS at an intermodal terminal means paying for functions nobody there will use while missing train dispatching as a core process. The other way round, a pure gate or yard tool is not enough as soon as rail is involved. How short the rollout can be depends on data migration and the number of interfaces, not on terminal size: RailHub Duisburg went from project start to go-live in five months, with 15 interfaces and without a single day of parallel operation.
Selection
How to recognise the right TOS
Does it cover rail as a core process?
Wagon lists, load planning and wagon check belong in the system, not in a side application.
Does it work on mobile and offline?
There are radio dead spots at the track and in the crane. If the app stops there, people go back to paper.
Are the EDI standards included out of the box?
EDIGES for bookings and train arrivals, CODECO for arrival and departure messages, COPARN for depot orders, COEDOR for stock reports: all of it should be configuration, not a development project. On top of that come connections to crane controls, video gate and OCR systems.
Can you start modular?
A terminal must be able to begin with the core and add depot, repair or billing later.
Who operates it, and where does the data live?
A terminal without its own IT department needs monitoring and support as part of the product, not as a separate contract. Running it as SaaS takes IT responsibility off the terminal and is faster to start; where operating rules require data to stay in your own data centre, the system has to support that too. Supporting both means the software does not dictate the decision.
Is it a product or a project?
Custom developments stand still after go-live. A product has a roadmap and releases.
Terminology
TOS, yard management system and ERP: where the lines run
Yard management system
Manages slots and vehicle movements on the site. It knows nothing about train dispatching or billing.
ERP
Runs commercial processes: receivables, accounting, controlling. It does not know the terminal stock in real time.
TOS
Sits between them and connects both: it runs operations and hands the billable services to the ERP. The ERP stays in place.
Timing
When the introduction pays off
There is no threshold of loading units above which a TOS becomes “necessary”. The need depends less on size than on the number of people involved: as soon as several people decide about the same stock at the same time, meaning gate, crane, dispatch and billing, every isolated tool costs coordination time and produces stock errors.
The usual triggers are accordingly different, and they all come down to information drifting apart inside the terminal.
- Yard stock regularly disagrees with reality.
- Waiting times at the gate grow while volume stays the same.
- Customers ask for status messages that are sent manually today.
- The existing system is no longer being developed.
- An operator handover or an expansion is coming up and processes have to be set up again anyway.
See a TOS running on your own processes.
We show you smartTOS on the workflows of your terminal, with no obligation and no slide marathon.
Request a demo