At a fuel terminal, the terminal automation system (TAS) carries a sales order all the way to product in a truck and then to a billable delivery document, inside a single chain of records. The business processes it automates are order and load authorization, gate control and bay assignment, transfer of product and additive recipes to the batch controllers, delivery documentation, reconciliation of tank inventory against meter data, and feedback to the enterprise resource planning (ERP) system.
The general layering of loading automation, from field devices and batch controllers through PLCs to terminal software, is described on a separate solution page. This page deals with what fuel trading adds on top: many products and additive recipes, biofuel blends, invoicing on volumes corrected to a reference temperature, and tax and record-keeping duties that differ from one country to the next.
From order to delivery document: the life of a load
1. Sales or dispatch creates the order; the TAS generates a load order with customer, product, quantity and truck data, or receives it from the ERP.
2. At the gate, driver and vehicle are identified by card or a similar method; vehicles with missing or expired credentials are not admitted.
3. The TAS assigns a free bay that offers the ordered products and sends a compartment-by-compartment loading plan to the batch controller.
4. Loading cannot start until grounding, overfill and arm-position permissives are made; if any permissive drops out, loading stops automatically.
5. Quantity, temperature and additive data are recorded for each compartment during loading.
6. When loading ends, the delivery document and any other required paperwork are issued, and the data flow to the ERP and inventory records.
When every step of this cycle is time-stamped, a later complaint about quantity or product can be traced back to the order, bay, meter and additive ratio involved, rather than argued from memory.
Product and additive recipes
Many of the grades a fuel terminal sells can be made at the loading arm by adding additives or bio-components to stored base products. The TAS manages the recipes that define which sales product is made from which base product, at what additive ratio and by which blending method. The recipe is passed to the batch controller, which runs sequential or ratio blending and additive injection at the arm.
Good recipe management means changes only by authorized users with a version history, monitoring of additive tank levels, and a decision made in advance about what happens when an additive meter fails. Whether loading should stop or the product should be recorded as a different grade is a quality-procedure question, and the software should implement whatever rule the procedure sets.
Reconciling tank inventory and meter data
A terminal measures quantity in two different ways: loading rack meters measure product dynamically as it moves, while the tank gauging system measures stored product statically. Over defined periods, the TAS compares tank receipts, dispatches and tank levels and reports the difference. That difference may be apparent loss caused by measurement or accounting errors, or physical loss; separating the two means looking at meter proving records, temperature corrections and tank calibration tables together.
Fuel is usually invoiced on volume corrected to a reference temperature. It is therefore good practice for the TAS to store both the gross volume at metering conditions and the standard volume, together with the temperature and density values used in the correction. The reference temperature and the correction method are set by national regulations and the contract.
Processes handled by the TAS and questions for the design
Process | Role of the TAS | Design question to ask |
Gate control | Verifying driver, vehicle and order; blocking unauthorized entry | Which identification method is used, and where are credential expiry dates checked? |
Bay assignment | Choosing a bay that offers the ordered products; managing the queue | How is the bay and product matrix modeled in the software? |
Load authorization | Sending compartment quantities to the batch controller | What happens if communication with the controller is lost? |
Recipe management | Defining additive and bio-component ratios with version control | Who signs off recipe changes and how are they logged? |
Documentation | Producing delivery documents, bills of lading and required official records | Which documents are mandatory under national rules? |
Inventory reconciliation | Comparing tank, meter and dispatch data | How often are reports run and with what tolerance limits? |
ERP integration | Receiving orders; returning dispatch and stock data | Which system holds master data, and can the terminal keep running if the link drops? |
Tax, customs and statutory records are project-specific
In many countries, motor fuel is subject to excise and customs control. Bonded storage, excise duty calculation, reporting to government systems and record retention periods all depend on the country and on the terminal's legal status. For that reason this page makes no promise of compliance with any particular regulation. Before TAS design begins, the operator's finance and legal teams should define which records are produced, in what format, who can access them and how long they are kept. Access control and an audit trail for custody measurement data belong in the same definition.
Keep safety functions outside the TAS
The TAS manages business processes; it should not be the only barrier for safety functions such as truck overfill prevention, ground verification and emergency shutdown. Those functions live in bay-level monitoring devices, in the PLC or, where required, in an independent safety instrumented system. The TAS reads, logs and reports the permissive status, but a software or server outage must not weaken the safety chain.
How TLY Enerji supports TAS projects
TLY Enerji provides engineering support for automation and control systems at fuel truck loading and unloading facilities, including PLC- and SCADA-based monitoring, data acquisition and reporting. Depending on the project, the scope can include selection and supply of batch controllers, meters and field instruments, PLC and DCS configuration, site integration, testing and commissioning, and technical support afterwards. Which party supplies the TAS software itself, the ERP interface and statutory reporting modules is agreed separately on each project.
Information to share when scoping a TAS
· Inventory of bays, arms and batch controllers, and the communication options of existing controllers
· Sales grades, base products and additive and bio-component recipes
· Order flow: where orders originate, who releases them and how delivery documents are printed
· ERP system in use and the expected data exchange
· Tank gauging system and inventory reporting needs
· Tax, customs and record retention obligations under national rules
· Preferred method for gate control and driver and vehicle identification
Related pages
· Automated truck loading terminals: Fluid-independent view of automation layers and the permissive chain.
· Multi-bay fuel loading terminals: The bay and product matrix that underpins TAS bay assignment rules.
· Fuel custody transfer metering systems: Invoicing on standard volume, proving and sealing practice.
· Fuel truck unloading systems: Preventing discharge into the wrong tank and recording receipts.
· Bottom loading for fuel terminals: The bay side of overfill and grounding permissives.
Frequently asked questions
What is the difference between a TAS and a batch controller?
A batch controller runs the delivery of a preset quantity on one arm or bay: it controls the valves, processes the meter pulses and handles additive injection. The TAS works across the whole terminal, managing orders, gate control, bay assignment, recipes, documents and inventory reconciliation. The TAS authorizes the load in the controller and collects the result from it when loading ends.
Can the terminal keep loading if the ERP link goes down?
That is a question to settle early in the design. On many projects the TAS is expected to keep working for a while on orders already downloaded from the ERP and to upload dispatch data once the link is restored. Which transactions may be completed offline should be decided according to the operator's commercial and financial rules.
Can a TAS produce customs and excise records automatically?
Because the TAS already holds the underlying data, report and document generation can be built into it. What records are mandatory, how they are submitted to government systems and how long they must be kept vary by country and terminal status. Until those requirements are defined with the finance and legal teams, the software scope cannot be fixed correctly.
Can a TAS be retrofitted to an existing terminal?
Yes, but first check whether the existing batch controllers can communicate with new software, where the bay permissive signals are gathered and whether the tank gauging system can deliver data. If older controllers cannot talk to the new system, the migration can be phased bay by bay so that dispatch continues throughout.