What is a tank management system? From level readings to tank tickets and stock

A tank management system (TMS) is an application that collects ATG data from every tank, calculates standard volume, records stock movements and issues tank tickets for receipts, deliveries and closing stock.

The automatic tank gauge (ATG) answers how high the product stands in one tank. The TMS answers the questions a terminal manager asks every morning: how much product the terminal holds, what came in, what went out and whether the figures agree. It does this by combining gauge readings with each tank's configuration and calibration table.

Citia INTEGRA TMS is Citia's TMS. It reads level, temperature and volume from the ATGs through a gateway, keeps live and historical data in an SQL database, issues tank tickets and posts physical inventory to SAP. The sections below describe how any TMS works, using that system as the reference example.

In plain terms, a TMS is the stock book of the tank farm, filled in automatically from the gauges instead of by hand.

The functions repeat across vendors. The TMS application walkthrough shows them on screen. A dashboard gives each tank's level in millimetres and temperature in °C. The configuration page holds product, height, diameter, tape and bob values. A tank ticket register carries a verification step, and a monitoring table lists volume, pumpable volume, ullage and flow rate. Manual entry of water level and density is allowed where the gauge does not measure them.

The design choice that matters most is which values are measured and which are typed in. Every manual field needs a name, a time and a reason in the record, because those fields are where disputes start.

Data moves in one direction: from the gauge on the tank, through a gateway, into the TMS server, and on to the business system. The reverse direction is used only for configuration and specific commands, such as asking a servo gauge to find the water interface.

The gateway is the link people forget until it fails. It polls each gauge over the field protocol, often Modbus RTU on RS-485, and passes the values to the server network. If the gateway stops, every tank in the TMS freezes at its last value. The server stores live values and history, applies the tank tables and holds the tickets. Posting to SAP happens over the intranet once a ticket or stock figure is verified.

Three systems touch tank data in a terminal, and confusing them leads to wrong expectations in a project scope. A common example: new gauges are expected to produce tank tickets on their own, when without a TMS and correct tables they only deliver levels.

The ATG is an instrument; it measures. The TMS is an application; it turns measurements into inventory. A terminal automation system (TAS) runs the distribution workflow from order to gate-out, including truck loading through meters and batch controllers. The TAS may read tank levels from the TMS, but it does not replace it. A longer explanation sits in TAS, TMS and TPS Integration compared.

When writing a project scope, name the system of record for each figure, for example the TMS for physical stock and the TAS for quantities loaded into trucks.

A tank whose gauge has stopped talking still shows a number in many systems, and that number is the risk.

A stored value does not prove the device is still sending fresh data. The TMS should mark a reading stale once its time stamp ages past an agreed limit, raise a communication alarm, and block that value from new tickets. During the outage the operator switches the tank to manual dip entry, with the reason recorded. When the link returns, the first automatic reading is compared with a fresh dip before the tank goes back to automatic.

At the Jambi fuel terminal, a gateway fault cut tank data to the TMS until the unit was replaced and the RS-485 and Ethernet lines were protected against surges. The lesson recorded there applies widely: after any device replacement, run an end-to-end test from the ATG to the TMS screen. For mixed gauge fleets, see integrating ATGs from several brands.

Two Citia projects show the parts of a TMS job that rarely appear in a brochure: testing inside a running facility and setting up user access.

The Cikampek tank-monitoring upgrade for Pertamina in 2025 integrated monitoring of level, pressure, temperature and tank status with facilities already in operation. Before integration, the team ran wiring verification, communication tests, loop checks, I/O tests and functional tests, under permit to work and job safety analysis. According to the project notes, verifying installation and configuration before commissioning cut troubleshooting time.

At the Redeco Petrolin chemical terminal, the TMS reads tank sensors over Modbus serial communication, raises high-high, high, low and low-low alarms with operator acknowledgement, and separates access by role for admin, operator and supervisor. Role separation matters for inventory: the person who edits a ticket should not be the only person who verifies it. Once tickets are reliable, the next step is loss reconciliation, comparing book stock with measured stock every day.

A TMS tender that only asks for a dashboard will get a dashboard. The useful specification describes the gauges, the documents and the rules the system must follow.

• Installed gauges. List every tank with gauge brand, model, interface and protocol, as the existing ATG integration checklist recommends.
• Calculation basis. Name the correction tables per product, the source of density, and who maintains the calibration tables.
• Documents. Attach the tank ticket format in use and the reports operations already signs.
• Data rules. State the stale-data limit, which fields may be entered by hand, and who verifies a ticket.
• Interfaces. Describe the ERP posting, the network path and any link to the TAS.
• Acceptance. Define the end-to-end tests per tank before go-live, including a comparison with manual dips.

With these points written down, vendors price the same scope and the commissioning team has a clear finish line.