--- title: "LTSA Contract Meaning: Terminal Control Maintenance | Citia" description: "LTSA (long-term service agreement) fixes maintenance, response, spares, backups and reports for years. See what a terminal control-system contract should cover." url: https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance language: en updated: 2026-11-13 type: article site: Citia Engineering Indonesia --- # LTSA and control-system maintenance for terminals: what the contract should cover LTSA is a multi-year service contract for a terminal control system. See what the scope, service levels, backups, reports and security clauses should say, and how to judge a provider. | Field | Value | | --- | --- | | Topic | Reliability and Lifecycle | | Author | Tim Engineering Citia | | Updated | 2026-11-13 | Key takeaways 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. - LTSA (long-term service agreement) is a multi-year service contract that fixes preventive maintenance, fault response, spare parts, backups and reporting for a defined system. - An LTSA differs from ordinary maintenance by continuity: the same team, the same records and the same spares tied to the same installation year after year. - A good contract names its scope item by item and lists what is excluded, because faults in equipment outside the scope are the most common source of dispute. - Define fault severity by the effect on loading and dispatch, attach a response mode to each level, and set the figures for the site, with on-call cover where operations run outside office hours. - Evidence protects both sides: root-cause notes, change logs, restore-tested backups and access records. IEC 62443-2-4 and ISO 55000 give checklists for security and lifecycle. ## What an LTSA is and how it differs 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. - Commitment: Per call-out | One year of scheduled visits | Several years for a defined system - Response to faults: Best effort, when an engineer is free | Set in the contract for the year | Defined by severity, with on-call cover where needed - Spare parts: Bought when needed | Often excluded or priced per item | Agreed list, stock rules and lead times - Backups and reports: Rarely included | A report after each visit | Routine backups, recorded changes, periodic reports - Continuity of knowledge: Low, a different engineer each time | Medium | High, the same team and records - Best when: The system is non-critical or temporary | The system is stable and the site has its own staff | Loading or dispatch stops when the system fails ## Preventive, predictive and corrective maintenance 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. - Preventive: Scheduled checks, cleaning, backup tests and planned replacement. - Predictive: Alarm history, diagnostics and trends point to a fault that is forming. - Corrective: Repair and root-cause analysis after a fault, with the cause recorded. ## What the scope should list 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. - Systems covered: Named software with versions, and the servers it runs on - Hardware covered: A model list with location and serial number where available - Communication: Network devices, fibre, serial converters and cabling - Supporting equipment: Listed as in scope or out of scope, with the owner named - Software changes: Whether fixes, updates and small development are included - Boundary faults: How a fault between in-scope and out-of-scope items is investigated - Access: Who may log in, from where, and how it is recorded ## Response times and the support model 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. - Example at a terminal: No truck can load, or the TAS server is down | One bay is down, or the weighing link keeps dropping | A report prints wrongly, or a printer fails - Support mode: Remote first, then on site, including after hours | Remote support; on site in working hours | Handled at the next scheduled visit - What the record shows: Cause, fix, time to respond and to restore | Cause and fix | A line in the monthly report ## Spare parts and replacement work 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 . - Critical and slow to get: Examples: TAS server, ATG gateway, PLC I/O modules. Held on site or by the provider and listed in the contract. - Frequent and cheap: Examples: cables, fuses, printer parts. Bought on demand. - Obsolete or end of support: Examples: discontinued PLC modules and PCs. A stock of last units plus a migration plan. ## A year of LTSA: the routine that proves it works 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. ## A suggested rhythm for one year - Start: Baseline. Inventory of hardware, software versions, topology and backups, written down as the starting record. - Every month: Visit and backup. Routine maintenance, a meeting with site supervisors, a database backup and a visit report. - Every quarter: Review. Fault trends, root causes closed, spare stock against the agreed list. - Year end: Lifecycle review. Obsolescence, firmware, spare availability and the scope for the next year. ## Change control and handover 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. - What: The change and the system it touches - Why: The fault or request that caused it - Approved by: A named person on the terminal side - Backup before: Name, date and location of the backup - Test after: What was tested and the result - Way back: How to return to the previous state ## Responsibility, evidence and the audit trail An LTSA is only as good as the evidence it leaves behind. The Padalarang record lists four challenges: monthly administration across the customer's offices, faults in supporting equipment outside scope and unclear limits of responsibility. The fourth is the risk of misreading the TAS's functions and access when a process irregularity or suspected fraud is investigated. The answers were evidence. Faults were documented by source. Troubleshooting followed hardware, software, database, configuration and log checks. Scope and authority were made clear through work documentation, handover reports, inspection results and maintenance reports. An audit trail was kept with routine backups and records of configuration changes. Put those habits into the contract. Require a root-cause note for every fault above minor severity and a change log for every configuration change. Add a handover report for every visit and access records showing who logged in and what they did. These documents protect the terminal and the provider equally when a dispute or an investigation arrives. Separate the fault from the equipment: When something looks like a TAS fault, check the supporting equipment and the network before changing anything in the application. The Padalarang and Panjang records both describe faults that looked like TAS problems and started in equipment outside the contract. ## Named owners and an escalation path 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. ## Security terms in a service contract A service provider with access to a control system becomes part of that system's attack surface. IEC 62443-2-4 (2023 edition) specifies security capabilities that service providers for industrial automation and control systems should offer asset owners during integration and maintenance. It is a useful checklist for a contract even when the terminal does not require certification. Ask the provider how it handles each item in the table, and write the answers into the agreement. The guide on OT cybersecurity at fuel terminals covers the terminal's side. - Remote access: Method, approval per session, session record - Credentials: Named accounts, no shared passwords, removal when staff leave - Patching and changes: Tested first, with a rollback plan and a record - Backups: Stored apart from the system and restore-tested - Incidents: Who is told, how fast, and what evidence is kept ## From maintenance to lifecycle 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. ## Measuring the provider 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. - Response met: Share of faults answered within the agreed time, per severity level - Repeat faults: The same fault returning means the root cause was not fixed - Root-cause notes: Every fault above minor has a cause and a verified fix - Restore test: Date of the last successful restore test for each system - Spare stock: Critical spares on hand against the agreed list - Open findings: Ranked findings from inspections, with owners and dates ## Commercial terms worth reading twice 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. - Inventory the installed base: Hardware, software versions, network and backups, with gaps marked as findings. - List the failures that hurt: Start from what stops loading, weighing or gate control. - Set severity and response: Define levels by effect, attach a response mode, agree the figures. - Name the exclusions: Equipment outside scope, its owner and the boundary-fault rule. - Agree reports and evidence: Visit reports, root-cause notes, change logs, access records. - Plan renewal and exit: Handover of records and scope updates when equipment changes. ## Gaps to look for in an existing contract Most weak contracts fail in the same few places, so a review can start with a short list. 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. - 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. ## Terms explained - LTSA: Long-term service agreement: a multi-year contract for the maintenance and support of a defined system. - SLA: Service level agreement: the measurable response and restoration commitments inside a contract. - Preventive maintenance: Work done on a schedule to avoid failures. - Predictive maintenance: Work triggered by data that shows a fault forming, also called condition-based maintenance. - Corrective maintenance: Repair after a fault has occurred. - Root-cause analysis: Finding the underlying reason for a fault, not only the symptom. - Audit trail: Records of who did what and when, such as logs and change records. - Lifecycle: The span from installation to replacement of an asset, including the point where vendor support ends. ## Frequently asked questions Q: What is an LTSA? A: An LTSA (long-term service agreement) is a service contract that runs for several years and fixes preventive maintenance, fault response, spare parts, backups and reporting for a defined system. It ties the same team and records to the same installation. Q: What is the difference between an LTSA and an ordinary maintenance contract? A: An LTSA runs over several years and bundles scope, response levels, spares, backups and reports, while an ordinary contract often covers a year of visits. The main gain is continuity of people and records. Q: What should a monthly LTSA report contain? A: Faults with severity, cause and fix, response and restoration times, the backup made and its restore-test status, configuration changes, spare stock and open findings with owners. A report with only a list of visits is not enough. Q: How do you measure the performance of an LTSA provider? A: Use a short list: response times met per severity, repeat faults, root-cause notes closed, last successful restore test, critical spares against the agreed list, and open findings. Each can be read from the provider's own records. Q: Is predictive maintenance better than preventive maintenance? A: Neither replaces the other. Preventive work covers known wear on a schedule, and predictive work uses alarm and diagnostic data to decide where to look first. A control system needs both, plus corrective repair when a fault still happens. Q: What should the scope exclude? A: List equipment you own outside the contract, such as supporting devices, power and building systems, and name the owner. Then add a rule for faults that cross the boundary, so investigation does not stop at a dispute. Q: Does a service contract need to follow IEC 62443? A: It does not have to, unless your policy or customer requires it. IEC 62443-2-4 is still a good checklist for remote access, credentials, patching, backups and incident handling, and you can write those expectations into the contract. ## Sources and further reading 1. IEC 62443-2-4:2023 Security for industrial automation and control systems, Part 2-4: Security program requirements for IACS service providers, International Electrotechnical Commission (IEC), 2023 (https://webstore.iec.ch/en/publication/67631) 2. ISO 55000:2024 Asset management: Vocabulary, overview and principles, International Organization for Standardization (ISO), 2024 (https://committee.iso.org/standard/83053.html) 3. Padalarang TAS lifecycle support, PT Citia Engineering Indonesia, 2026 (https://citia-engineering.com/en/projects/padalarang-tas-lifecycle) 4. LTSA for LPG Panjang, PT Citia Engineering Indonesia, 2022 (https://citia-engineering.com/en/projects/ltsa-for-lpg-panjang) 5. Condition Monitoring and Maintenance, PT Citia Engineering Indonesia (https://citia-engineering.com/en/products/condition-monitoring-maintenance) 6. PLC/SCADA assessment: start with symptoms, topology and backups, PT Citia Engineering Indonesia, 2026 (https://citia-engineering.com/en/knowledge/reliability-plc-scada) 7. Reliable terminals: TAS and control system reliability, PT Citia Engineering Indonesia, 2026-10-23 (https://citia-engineering.com/en/webinars/reliable-terminals-tas-reliability) 8. Cover photo by Retired electrician, CC0, Wikimedia Commons (https://commons.wikimedia.org/wiki/File:%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8_%D0%B7%D0%B0%D1%89%D0%B8%D1%82%D1%8B_%D1%80%D0%BE%D1%81%D1%81%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D1%85_%D0%B1%D1%80%D0%B5%D0%BD%D0%B4%D0%BE%D0%B2.jpg) Reviewing a maintenance contract for your terminal?: Send siTia, Citia's assistant on WhatsApp, a short description of your systems and your current support arrangement, and the engineering team will follow up. ## Contact - Company: PT Citia Engineering Indonesia - siTia - Virtual Assistance: [WhatsApp +62 813-2206-507](https://wa.me/628132206507). siTia answers questions about our products, projects and enquiries on WhatsApp. Replies are automated, and a person from the Citia team follows up. - Email: services@citiaengineering.com - Phone / WhatsApp (siTia): +62 813-2206-507 - Location: Bandung, Indonesia [Contact Citia](https://citia-engineering.com/en/contact.md) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://citia-engineering.com/#organization", "name": "Citia Engineering Indonesia", "legalName": "PT Citia Engineering Indonesia", "alternateName": "Citia", "url": "https://citia-engineering.com", "logo": { "@type": "ImageObject", "url": "https://citia-engineering.com/media/citia-logo.png", "width": 950, "height": 328 }, "description": "Citia is an engineering and system integration company in Bandung, Indonesia. We connect field devices, PLC and SCADA, terminal software and enterprise systems, then install, test and maintain them.", "email": "services@citiaengineering.com", "telephone": "+62 813-2206-507", "address": { "@type": "PostalAddress", "addressLocality": "Bandung", "addressRegion": "Jawa Barat", "addressCountry": "ID" }, "contactPoint": [ { "@type": "ContactPoint", "contactType": "customer service", "email": "services@citiaengineering.com", "telephone": "+62 813-2206-507", "url": "https://citia-engineering.com/en/contact" }, { "@type": "ContactPoint", "contactType": "customer support", "name": "siTia - Virtual Assistance", "telephone": "+62 813-2206-507", "url": "https://wa.me/628132206507", "areaServed": "ID", "availableLanguage": [ "id", "en" ] } ], "areaServed": { "@type": "Country", "name": "Indonesia" }, "knowsAbout": [ "Terminal automation system", "Automatic tank gauging", "Tank management system", "SCADA", "Programmable logic controller", "Modbus", "Field instrumentation", "Weighbridge", "Pipeline pressure monitoring", "Industrial IoT" ], "brand": [ { "@type": "Brand", "name": "INTEGRA" }, { "@type": "Brand", "name": "CATALYST" } ], "sameAs": [ "https://www.facebook.com/citiaengineering/", "https://www.instagram.com/citiaengineering/" ] }, { "@type": "WebSite", "@id": "https://citia-engineering.com/#website", "url": "https://citia-engineering.com", "name": "Citia Engineering Indonesia", "inLanguage": [ "en", "id" ], "publisher": { "@id": "https://citia-engineering.com/#organization" }, "potentialAction": [ { "@type": "SearchAction", "name": "Search Citia News", "target": { "@type": "EntryPoint", "urlTemplate": "https://citia-engineering.com/en/news?q={search_term_string}" }, "query-input": "required name=search_term_string" }, { "@type": "SearchAction", "name": "Cari di News Citia", "target": { "@type": "EntryPoint", "urlTemplate": "https://citia-engineering.com/id/news?q={search_term_string}" }, "query-input": "required name=search_term_string" } ] }, { "@type": "WebPage", "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#webpage", "url": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance", "name": "LTSA and control-system maintenance for terminals: what the contract should cover", "description": "LTSA (long-term service agreement) fixes maintenance, response, spares, backups and reports for years. See what a terminal control-system contract should cover.", "inLanguage": "en", "isPartOf": { "@id": "https://citia-engineering.com/#website" }, "publisher": { "@id": "https://citia-engineering.com/#organization" }, "about": { "@id": "https://citia-engineering.com/#organization" }, "breadcrumb": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#breadcrumb" }, "dateModified": "2026-11-13", "mainEntity": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#entity" } }, { "@type": "BreadcrumbList", "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Citia", "item": "https://citia-engineering.com/en" }, { "@type": "ListItem", "position": 2, "name": "Knowledge", "item": "https://citia-engineering.com/en/knowledge" }, { "@type": "ListItem", "position": 3, "name": "LTSA and control-system maintenance for terminals: what the contract should cover", "item": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance" } ] }, { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#entity", "url": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance", "mainEntityOfPage": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#webpage" }, "@type": "TechArticle", "headline": "LTSA and control-system maintenance for terminals: what the contract should cover", "description": "LTSA is a multi-year service contract for a terminal control system. See what the scope, service levels, backups, reports and security clauses should say, and how to judge a provider.", "dateModified": "2026-11-13", "author": { "@id": "https://citia-engineering.com/#organization" }, "publisher": { "@id": "https://citia-engineering.com/#organization" }, "inLanguage": "en", "articleSection": "Reliability and Lifecycle", "datePublished": "2026-11-13", "image": "https://citia-engineering.com/media/covers/ltsa-control-system-maintenance.webp" }, { "@type": "FAQPage", "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#faq", "url": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance", "inLanguage": "en", "isPartOf": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#webpage" }, "mainEntity": [ { "@type": "Question", "name": "What is an LTSA?", "acceptedAnswer": { "@type": "Answer", "text": "An LTSA (long-term service agreement) is a service contract that runs for several years and fixes preventive maintenance, fault response, spare parts, backups and reporting for a defined system. It ties the same team and records to the same installation." } }, { "@type": "Question", "name": "What is the difference between an LTSA and an ordinary maintenance contract?", "acceptedAnswer": { "@type": "Answer", "text": "An LTSA runs over several years and bundles scope, response levels, spares, backups and reports, while an ordinary contract often covers a year of visits. The main gain is continuity of people and records." } }, { "@type": "Question", "name": "What should a monthly LTSA report contain?", "acceptedAnswer": { "@type": "Answer", "text": "Faults with severity, cause and fix, response and restoration times, the backup made and its restore-test status, configuration changes, spare stock and open findings with owners. A report with only a list of visits is not enough." } }, { "@type": "Question", "name": "How do you measure the performance of an LTSA provider?", "acceptedAnswer": { "@type": "Answer", "text": "Use a short list: response times met per severity, repeat faults, root-cause notes closed, last successful restore test, critical spares against the agreed list, and open findings. Each can be read from the provider's own records." } }, { "@type": "Question", "name": "Is predictive maintenance better than preventive maintenance?", "acceptedAnswer": { "@type": "Answer", "text": "Neither replaces the other. Preventive work covers known wear on a schedule, and predictive work uses alarm and diagnostic data to decide where to look first. A control system needs both, plus corrective repair when a fault still happens." } }, { "@type": "Question", "name": "What should the scope exclude?", "acceptedAnswer": { "@type": "Answer", "text": "List equipment you own outside the contract, such as supporting devices, power and building systems, and name the owner. Then add a rule for faults that cross the boundary, so investigation does not stop at a dispute." } }, { "@type": "Question", "name": "Does a service contract need to follow IEC 62443?", "acceptedAnswer": { "@type": "Answer", "text": "It does not have to, unless your policy or customer requires it. IEC 62443-2-4 is still a good checklist for remote access, credentials, patching, backups and incident handling, and you can write those expectations into the contract." } } ] }, { "@type": "DefinedTermSet", "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#glossary", "url": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance", "inLanguage": "en", "isPartOf": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#webpage" }, "name": "Terms explained", "hasDefinedTerm": [ { "@type": "DefinedTerm", "name": "LTSA", "description": "Long-term service agreement: a multi-year contract for the maintenance and support of a defined system.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#glossary" } }, { "@type": "DefinedTerm", "name": "SLA", "description": "Service level agreement: the measurable response and restoration commitments inside a contract.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#glossary" } }, { "@type": "DefinedTerm", "name": "Preventive maintenance", "description": "Work done on a schedule to avoid failures.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#glossary" } }, { "@type": "DefinedTerm", "name": "Predictive maintenance", "description": "Work triggered by data that shows a fault forming, also called condition-based maintenance.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#glossary" } }, { "@type": "DefinedTerm", "name": "Corrective maintenance", "description": "Repair after a fault has occurred.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#glossary" } }, { "@type": "DefinedTerm", "name": "Root-cause analysis", "description": "Finding the underlying reason for a fault, not only the symptom.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#glossary" } }, { "@type": "DefinedTerm", "name": "Audit trail", "description": "Records of who did what and when, such as logs and change records.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#glossary" } }, { "@type": "DefinedTerm", "name": "Lifecycle", "description": "The span from installation to replacement of an asset, including the point where vendor support ends.", "inDefinedTermSet": { "@id": "https://citia-engineering.com/en/knowledge/ltsa-control-system-maintenance#glossary" } } ] } ] } ```