LTSA and control-system maintenance for terminals: what the contract should cover

LTSA (long-term service agreement) is a service contract that runs for several years and sets, for a defined system, the preventive maintenance, the response to faults, the availability of spare parts, the backups and the reporting. At a fuel or LPG terminal the system is usually the terminal automation system (TAS) and the control equipment around it.

The words "long-term" matter more than they look. A one-off repair fixes a fault, while an LTSA keeps the same people, records and spares tied to the same installation year after year. This guide explains what a good LTSA covers, how it differs from other maintenance contracts, what the clauses should say and how to judge a provider. It draws on Citia's LTSA work at Padalarang and LPG Panjang, and on two standards: IEC 62443-2-4 and ISO 55000.

An LTSA is a promise to look after a specific system for years, with defined duties on both sides.

Three contract models are common. Ad hoc service sends an engineer when something breaks, and the terminal pays per visit. An annual maintenance contract adds scheduled visits for a year. An LTSA runs over several years and ties the scope, the response model, the spare parts, the backups and the reports into one document that is reviewed during its life.

Citia's maintenance service for control systems comes in these forms side by side: a one-time assessment, scheduled maintenance, an annual contract, on-call support or a resident engineer. The right choice depends on how much downtime the terminal can accept and how many people it has on site. A terminal that loads trucks around the clock needs on-call cover that a day-shift contract cannot give.

An LTSA does not replace the terminal's own technicians. It adds specialist knowledge of the TAS and the control system, a second pair of eyes on faults and a record that outlives staff changes. The terminal's people still know the site, the operators and the daily habits of the plant, and the contract should use that knowledge instead of duplicating it.

Maintenance falls into three kinds, and a good contract uses all three.

Preventive maintenance happens on a schedule whether or not anything has failed: cleaning, checking connections, testing backups, replacing parts that wear. Corrective maintenance repairs a fault after it happens. Predictive maintenance, also called condition-based maintenance, uses data such as communication errors, alarm history and device diagnostics to act before a failure.

For a terminal, the data for predictive work already exists in alarm and event logs, server health and gateway statistics. Citia's Condition Monitoring and Maintenance service reads these through inspections, diagnostics, alarm analysis and backup tests, and ranks findings from critical to normal. It does not replace preventive visits. It tells you where the next visit should look first.

Predictive work depends on discipline. If alarms are acknowledged without notes, or logs are overwritten every few days, there is no history to read. Agree in the contract which logs are kept, for how long and who reads them.

A scope is a list of named things, and anything not named is open to argument.

Padalarang shows what a clear list looks like. The TAS LTSA there names the distribution software (FDM and FD-Flow) and the hardware (TAS server, FD-Flow PC, gate interface PC, tapping card and NFC reader). It also lists the supporting items (delivery note printer and LI printer) and the communication equipment (communication card and fibre optic). The LPG Panjang LTSA lists FD-Flow and CSL software, a SCADA system, the TAS server, the FD-Flow and weighing house PCs, the NFC reader, the communication card and the fibre optic.

Both records describe the same difficulty. Equipment outside the contract scope failed and affected the TAS, and the LTSA team was sometimes seen as responsible. A scope should therefore also list what is excluded and who owns it, and say how a fault that crosses the boundary is investigated.

A service level agreement (SLA) turns "we will respond quickly" into a measurable promise.

Define fault severity by its effect on the terminal, not by anyone's feeling. A fault that stops all loading is not the same as a printer that jams. Then attach a response mode to each level: remote support first, on-site attendance, after-hours on-call. The figures for response and restoration belong in the contract, agreed for the site. This guide gives none, because they depend on the terminal's tolerance for downtime.

At LPG Panjang the LTSA is supported by one standby technician during office hours and by on-call cover after hours, who comes to site to troubleshoot and fix a fault that needs direct handling. The lesson recorded there is that on-call cover is essential where operations can run outside working hours.

Remote support saves hours when it is allowed. Agree early how remote sessions are approved and recorded, so the first night-time fault is not delayed by a debate about access.

A spare part helps only if it is the right one, it is on the shelf and someone knows how to configure it.

Spares for a terminal fall into three groups. Items that stop operations when they fail and are slow to obtain should be held on site or by the provider. Cheap items that fail often can be bought on demand. Obsolete items need a plan: either a stock of the last units or a migration.

Two Citia project records show what replacement work involves. At the Jambi fuel terminal, the ATG gateway (an Advantech ECU-1051) was replaced to restore communication between the ATG and the TMS, and the new unit had to be reconfigured. The lesson recorded there is that an end-to-end test from the ATG to the TMS application is mandatory after a device is replaced.

At Cikampek, faulty digital output modules on an Allen-Bradley PLC and a Moxa communication gateway were replaced, with checks of the I/O function and the wiring. The contract should therefore cover the part, its configuration backup, the replacement procedure and the end-to-end test. See the Jambi gateway project and the Cikampek PLC project.

An LTSA works when its routines happen on schedule and leave records.

The Padalarang LTSA runs a monthly visit for routine maintenance and coordination. The team meets the field team and the Pertamina engineering and distribution supervisors to discuss system condition, operational problems and maintenance needs, and it takes a database backup on the server at each visit. Around that monthly rhythm sit a baseline at the start and a lifecycle review at the end of the year.

A backup is only the start of resilience. A backup that has never been restored is an assumption. The guide on PLC and SCADA backup and restore describes how to test one.

Every change to a running system should leave a trace and a way back.

A change, whether a software fix or a new tag, goes through a short path. It starts with a request and its reason, then approval by the terminal's responsible person, a backup before the change, the change itself in a window the operations team agreed, a test afterwards and a written record. Citia's maintenance service states that program changes follow change control, and the Padalarang record lists records of configuration changes as part of its audit trail.

Handover matters just as much. At the end of each visit the provider should leave a report that says what was done, what remains open and what the operators should watch. Without it, the next shift inherits a system that someone else understood.

A contract works better when each side has a named person who can decide.

On the terminal side, name a system owner who accepts reports, approves changes and sets priorities between faults. On the provider side, name a lead engineer who knows the installation and a deputy who can step in. Agree an escalation path that goes beyond the lead, and the working hours of each contact.

Padalarang shows why. Monthly administration crossed several customer offices and needed regular follow-up, and there was a risk of misreading the TAS's functions and access when something irregular happened. Names and authority in writing remove most of that friction.

Maintenance keeps a system running, and lifecycle management decides when to stop repairing it.

ISO 55000:2024 sets out the vocabulary and principles of asset management. Its core ideas are aligning asset objectives with the organisation's objectives, managing assets across their life cycle, and using a management system to improve performance continually. For a control system this means LTSA reports should feed a lifecycle view: which PLCs and servers are near the end of vendor support, which spares are hard to find and which backups are old.

The guides on obsolete PLC and SCADA systems and PLC troubleshooting take these topics further, and the Citia article PLC/SCADA assessment shows how to start from symptoms, topology and backups.

Measure the contract with a short list that the monthly report must answer.

Fewer indicators read better than many. Each one below can be answered from records the provider already keeps, and none needs an invented target: the contract states the agreed levels.

Review the report with the provider every quarter, with the system owner in the room. A report that nobody discusses slowly turns into a formality, and the indicators stop meaning anything.

The commercial side of an LTSA decides who carries the risk, so read it with the technical scope open beside it.

Cost normally follows the scope, the response model and the spare-parts approach. A contract with after-hours on-call cover costs more to deliver than one limited to office hours, and a contract that includes consumed spares differs from one that prices them per item. Compare offers on the same scope and the same service levels, or the comparison means nothing.

Check the end of the contract as carefully as the start. It should say how documentation, backups and configuration records are handed over if the terminal changes provider, and how a renewal updates the scope when equipment is replaced.

Most weak contracts fail in the same few places, so a review can start with a short list.

• No list of exclusions, so every boundary fault becomes a debate.
• Response figures without a definition of severity, so every fault is called critical.
• Backups that are made but never restored in a test.
• Remote access that is allowed in practice and not described in writing.
• Reports that list visits but not causes, changes and open findings.
• No handover of records at the end of the contract.

If three or more of these apply, the contract is probably a call-out service under a long-term name. Fixing the wording costs little. Fixing it after a long outage costs much more.