Engineering Practice
How to write a terminal automation system specification and RFQ
Write a TAS specification from processes, interfaces, failure cases and acceptance tests, so proposals from terminal automation vendors can be compared.
- Topic
- Engineering Practice
- Updated
- 13 November 2026
- Reading time
- 4 min
- Sections
- 6
A good terminal automation system (TAS) specification starts from the list of processes and documents the terminal must produce, then derives the field devices, interfaces, system availability and after-sales support from that list.
A specification written as a feature wish list invites proposals that tick every box and still fail on site. This guide follows the order an experienced owner's engineer uses for an RFQ (request for quotation) or a KAK (kerangka acuan kerja). If you need the basics first, the INTEGRA TAS product page shows the full gate-to-gate chain, and the article on TAS, TMS and TPS explains where each system's responsibility ends.
Scope
Start from processes and documents
Write down what the terminal does and what paper it must produce before you write a single technical requirement. Everything else in the specification should trace back to that list.
For a fuel terminal the list usually covers receipt, storage, truck loading, gate control and reporting. For each process, name the trigger, the data it needs, the person who approves it and the document it closes with: tank ticket, delivery note, good issue, stock report. Requirements that do not trace to a process are either missing a process or are not needed.
Process inventory
List each process, its trigger, approver and closing document.
Field survey
Record every bay, meter, controller, gate and network cabinet with brand, model and condition.
Interface list
Define each data link, its owner, format and failure rule.
Acceptance criteria
Turn requirements into tests with pass and fail conditions.
FAT, SAT and SIT plan
Agree where and how each test runs, and who signs.
Support and spares
Specify response, backups, spares and the end of the support period.
Interfaces
The interface list is the core of the specification
Most TAS projects that run late are late at an interface, not inside the TAS. Each link between two systems has two owners, two vendors and two ideas of what a message means.
For every interface, write the direction of data, the trigger, the message content, the protocol, the owner on each side and what happens when the other side does not answer. The Citia Integrated TAS Portfolio shows a typical set: RFID and gate, a Siemens S7-300 PLC, WebAccess SCADA, INTEGRA TAS and TMS, and SAP with SIOD.
Ask bidders to say which side of each interface they will build, and which side they expect the owner or another vendor to supply.
- ERP
- Orders in, results and postings out
- Distribution system
- Shipment data, for example SIOD
- TMS
- Tank stock and tank tickets
- Batch controllers
- Presets in, batch results out
- PLC / SCADA
- Pumps, valves, permissives
- Gate
- RFID, barrier, weighbridge for LPG
Availability
Specify behaviour when something fails
A specification that only describes normal operation will get a system that only works in normal operation. Write the failure cases as requirements, each with a test.
Three cases cover most of the risk. When the ERP link is down, the terminal should keep loading against orders already received and queue the postings. If the TAS server fails, the specification should say whether a standby server takes over and what happens to a batch in progress. A network drop at one bay should let the running batch finish or stop safely, with no new batch starting.
Avoid asking for an availability percentage you cannot test. Ask instead for the switchover procedure, the recovery time you will witness at SAT, and the backup and restore procedure.
Testing
Acceptance tests: FAT, SAT and SIT
Acceptance tests are where the specification is proven, so the tests must be in the RFQ. A bidder prices what you ask it to prove.
IEC 62381:2024 sets out requirements and checklists for the factory acceptance test (FAT), an optional factory integration test (FIT), the site acceptance test (SAT) and the site integration test (SIT). Its purpose is to give owner, buyer and vendor one agreed basis for test scope and responsibilities. Use it as the frame and add terminal-specific cases: a full loading with a real truck per product, a gate-to-gate transaction posted to the ERP, and each failure case from the section above.
Test stages under IEC 62381:2024
- Factory
FAT
Software and panels tested against the specification with simulated signals.
- Factory, optional
FIT
Integration with other systems tested before shipment.
- Site
SAT
Installed system tested with real field devices.
- Site
SIT
End-to-end tests with ERP, TMS and other site systems.
Lifecycle
Support, spares and security in the contract
A TAS is used for many years after the project team leaves, so the specification must describe that period too. The contract model decides who answers the phone at night.
Citia's support records show what to write down. At Padalarang, faults in equipment outside the TAS contract were often seen as the TAS team's responsibility, so the boundary of scope had to be made explicit. At LPG Panjang, one standby technician covered office hours with on-call support outside them, and recurring communication loss between the weighbridge controller and the weighing house PC needed structured troubleshooting.
For security, IEC 62443-2-4:2023 lists the security program requirements an asset owner can ask of an industrial automation service provider during integration and maintenance. Ask bidders which of those requirements they already meet.
| Criterion | Project only | Project + LTSA | Service model |
|---|---|---|---|
| Who owns faults after handover | Owner, after warranty | Shared, as written in the LTSA scope | Provider, within the service terms |
| Changes such as new products | New purchase order each time | Often included up to an agreed limit | Part of the service |
| Backups and restore tests | Owner's IT team | Scheduled in the LTSA | Provider's responsibility |
| Main risk | Knowledge leaves with the project team | Unclear scope boundaries | Dependence on one provider |
Checklist
A checklist for the RFQ
Process and document list
Every process with its trigger, approver and closing document.
Site survey data
Brands, models and condition of all field devices and cabinets.
Interface list
Owner, format, protocol and failure rule for each link.
Failure behaviour
ERP down, server down and bay network loss, each with a test.
Tests and support
FAT, SAT and SIT scope, spares list, response times and restore drills.
Security practice
Remote access rules and the provider's position against IEC 62443-2-4.
When proposals arrive, score them on how well they answer the interface list and the failure cases, not on the length of the feature table. Ask each bidder to name a reference site where the same interfaces run today, and talk to the people who maintain it.
Terms used in this article
- RFQ
- Request for quotation, the document that asks vendors for priced proposals.
- KAK
- Kerangka acuan kerja, the Indonesian term of reference for a project.
- FAT
- Factory acceptance test, run before shipment with simulated signals.
- SAT
- Site acceptance test, run after installation with real devices.
- SIT
- Site integration test, end-to-end with other site systems.
- LTSA
- Long-term service agreement for maintenance and support after handover.
- Interface list
- Table of every data link between systems, with owners and rules.
Frequently asked questions
What should a TAS RFQ contain at minimum?
A TAS RFQ should at minimum contain the process and document list, site survey data, the interface list, failure behaviour, acceptance tests and the support scope. Without the interface list and tests, proposals cannot be compared fairly.
How do you evaluate terminal automation system vendors?
Evaluate vendors on how they answer your interfaces and failure cases, and check a reference site that runs the same interfaces. A long feature list matters less than a clear plan for integration, testing and support.
What is the difference between FAT and SAT?
FAT is run at the vendor's facility before shipment with simulated signals; SAT is run on site after installation with real devices. IEC 62381:2024 also defines SIT for end-to-end tests with other site systems.
Why should spare parts and backups be in the specification?
Spare parts and backups must be in the specification because they decide how fast the terminal recovers from a fault. If they are added after award, they are priced without competition and often left out.
Which standard covers the security duties of an automation service provider?
IEC 62443-2-4:2023 covers the security program requirements for service providers that integrate and maintain industrial automation and control systems. It belongs to the ISA/IEC 62443 series.
Sources and further reading
- IEC 62381:2024 Automation systems in the process industry: FAT, SAT and SIT (opens in a new tab)
- IEC 62443-2-4:2023 Security program requirements for IACS service providers (opens in a new tab)
- ISA/IEC 62443 Series of Standards (opens in a new tab)
- Padalarang TAS lifecycle support (opens in a new tab)
- LTSA for LPG Panjang (opens in a new tab)
- Integrated TAS Portfolio (opens in a new tab)
Next step
Prepare the technical discussion for your facility.
Bring the equipment list, diagrams and symptoms you have. The Citia team helps map the next step.
Related products and solutions
- KnowledgeTerminal automation system architecture: field, control, application and enterprise layersTAS architecture has four layers, from field devices to ERP. See how they connect, what fails at each layer, where redundancy pays and how to segment the network.
- KnowledgeHow to choose an industrial automation system integrator in IndonesiaChoose an automation system integrator by evidence: similar projects, documentation, support after handover and clear scope. This guide gives a checklist you can apply to any bidder.
- KnowledgeIntegrating TAS and TMS with SAP: what data flows and how to handle failuresA TAS and TMS link to SAP carries orders, filling results and tank stock. See the data per transaction and how queues, retries and reconciliation keep it correct when the connection fails.
- ProductIntegrated TAS PortfolioTAS as one engineered platform: loading, gates, monitoring, maintenance and enterprise links.
- ProductINTEGRA TASRuns truck loading at fuel and LPG terminals, from order and gate-in to filling and gate-out documents.
- ProductCondition Monitoring & MaintenanceKeeps TAS, PLC, SCADA, servers, gateways and networks healthy, with backups you can restore.
- ProjectPadalarang TAS lifecycle supportDistribution TAS maintenance and troubleshooting
- ProjectLTSA for LPG PanjangThe long-term service agreement (LTSA) for the TAS at LPG Panjang keeps the Terminal Automation System (TAS) reliable and available. The TAS supports LPG receipt, storage and distribution.
- KnowledgeTAS, TMS and TPS Integration: what does each system manage?Separate distribution processes, inventory measurements and document reporting before defining integration.