Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC TR 63090: Industrial Automation — Lifecycle Management of Automation Systems
Structured methodology for managing industrial automation systems from concept through decommissioning
1. Scope and Rationale of IEC TR 63090
IEC TR 63090 provides a structured technical report on lifecycle management methodologies for industrial automation systems. Unlike conventional asset management standards that focus on physical equipment maintenance, this TR addresses the entire automation system lifecycle — from concept definition and requirements engineering, through design, integration, commissioning, operation, and finally decommissioning or modernisation. The motivation is clear: industrial automation systems now have operational lifespans of 15-25 years, while their component technologies (controllers, networking hardware, software platforms) become obsolete every 3-7 years. Without systematic lifecycle management, plants face escalating maintenance costs, cybersecurity vulnerabilities due to unsupported software, and ultimately forced migration under crisis conditions.
The report synthesises principles from IEC 60300 (dependability management), IEC 61508 (functional safety), IEC 62264 (enterprise-control system integration), and ISA-95 to create a unified lifecycle model tailored specifically to the automation domain. It identifies six distinct lifecycle phases and prescribes activities, deliverables, and review gates for each phase. The TR is primarily targeted at automation engineers, plant managers, and system integrators responsible for sustaining automation system performance over extended time horizons.
A key insight from the TR: the total cost of ownership (TCO) of an automation system is typically 3-5 times the initial capital expenditure, with 60-70 % of that cost incurred during the operations and maintenance phase. Lifecycle planning from day one is therefore not optional — it is economically essential.
| Lifecycle Phase | Duration (Typical) | Key Deliverables | Review Gate |
|---|---|---|---|
| Concept & Requirements | 3-6 months | System requirement specification (SRS), functional design specification (FDS) | Requirements review |
| Design & Engineering | 6-18 months | P&ID, control philosophy, I/O list, network topology, software architecture | Design review (PDR/CDR) |
| Integration & Testing | 3-9 months | Factory acceptance test (FAT), site acceptance test (SAT), loop check reports | FAT/SAT sign-off |
| Commissioning & Startup | 1-6 months | Commissioning plan, startup procedures, training records | Operational readiness review |
| Operations & Maintenance | 10-20 years | Change management records, patch logs, obsolescence reports, performance KPIs | Annual lifecycle review |
| Decommissioning / Modernisation | 3-12 months | Migration plan, decommissioning procedure, data archival | End-of-life review |
2. Core Lifecycle Management Processes
2.1 Obsolescence Management
The TR identifies technology obsolescence as the single greatest lifecycle risk for automation systems. Unlike mechanical assets that wear out gradually, electronic components (microprocessors, FPGAs, communication ICs) become unavailable abruptly when manufacturers discontinue production — often with only 12-24 months of last-time-buy notice. The TR recommends a three-tier obsolescence management strategy: (1) strategic sourcing — selecting controller platforms and I/O modules from vendors with demonstrated long-term availability commitments (typically 10+ years); (2) proactive monitoring — subscribing to component lifecycle databases (e.g., SiliconExpert, IHS Markit) to receive early warnings of discontinuation; and (3) technology refresh planning — establishing a rolling 5-year technology refresh roadmap that groups component replacements into planned upgrade campaigns rather than ad hoc crisis interventions.
2.2 Change and Configuration Management
Automation systems undergo continuous change throughout their operational life — control logic modifications, HMI screen updates, network configuration changes, and security patch deployments. The TR mandates a rigorous change management process aligned with IEC 61508 / IEC 62443 requirements: all changes must be documented in a change request, reviewed by a change control board (CCB), tested in a staging environment, approved with documented risk assessment, and deployed with a rollback plan. Configuration management requires a software version control repository (typically Git or dedicated DCS configuration management tools) that maintains the complete history of all automation project artefacts — controller application code, HMI applications, alarm configurations, and device parameter files.
A 2023 industry survey cited in the TR found that 47 % of automation system incidents traced back to undocumented or inadequately reviewed changes. Implementing a disciplined change management process is consistently identified as the highest-return investment for improving automation system reliability.
3. Engineering Design Insights
3.1 Lifecycle Cost Modelling
To support investment decisions, the TR presents a total cost of ownership (TCO) model for automation systems. The model decomposes costs into five categories: capital expenditure (CAPEX) — hardware, software licenses, engineering; installation cost — panel fabrication, wiring, field termination; commissioning cost — startup support, performance tuning, documentation; operating cost — energy, consumables, maintenance labour, spare parts inventory carrying cost; and end-of-life cost — decommissioning, environmental disposal, data migration. The TCO model enables engineers to compare alternatives such as “purchase 10 years of spare parts upfront” versus “rely on vendor availability guarantees” on a net present value (NPV) basis discounted at the company’s weighted average cost of capital (WACC).
3.2 Cybersecurity Lifecycle Management
The TR integrates cybersecurity lifecycle management per IEC 62443, recognising that an automation system’s security posture degrades over time as new vulnerabilities are discovered. The recommended cybersecurity lifecycle includes: (1) initial security zone and conduit design per IEC 62443-3-2 during the design phase; (2) secure commissioning with hardened configurations (disabled unused services, changed default passwords, patched firmware); (3) continuous vulnerability monitoring and patch management during operations; (4) periodic security assessment audits every 12-18 months; and (5) secure decommissioning that ensures removal of authentication credentials and encryption keys before disposal of control hardware.
Plants that implement the full lifecycle management framework described in IEC TR 63090 report 28 % lower automation system TCO and 40 % fewer unplanned shutdowns over a 15-year operating horizon compared to plants using reactive or ad hoc lifecycle practices, according to data from a multinational chemical company’s internal benchmarking programme.
4. Frequently Asked Questions
Q1: At what point in a system’s life should lifecycle management begin?
The TR is emphatic: lifecycle management must begin during the concept phase, before any hardware is purchased. Key decisions made early — platform selection, network architecture, vendor relationships — have disproportionate influence on downstream obsolescence risk and maintainability.
The TR is emphatic: lifecycle management must begin during the concept phase, before any hardware is purchased. Key decisions made early — platform selection, network architecture, vendor relationships — have disproportionate influence on downstream obsolescence risk and maintainability.
Q2: How often should the obsolescence management plan be updated?
Annually, at minimum. The TR also recommends a “trigger-based” update whenever a critical component receives a last-time-buy notice or the vendor announces a major technology roadmap change (e.g., migration from Windows 10 IoT to Windows 11 IoT).
Annually, at minimum. The TR also recommends a “trigger-based” update whenever a critical component receives a last-time-buy notice or the vendor announces a major technology roadmap change (e.g., migration from Windows 10 IoT to Windows 11 IoT).
Q3: What is the recommended approach for legacy automation systems that never had lifecycle management?
The TR recommends a “baseline assessment” — a comprehensive audit of the current system’s hardware, software, network, and documentation status — followed by risk-ranking of identified gaps and a prioritised remediation plan. Even systems in mid-life benefit significantly from retrospective lifecycle management implementation.
The TR recommends a “baseline assessment” — a comprehensive audit of the current system’s hardware, software, network, and documentation status — followed by risk-ranking of identified gaps and a prioritised remediation plan. Even systems in mid-life benefit significantly from retrospective lifecycle management implementation.
Q4: Does the TR apply to PAC/PLC-based systems, DCS, and SCADA systems equally?
Yes, the lifecycle principles are technology-agnostic. However, the specific activities within each phase differ: DCS lifecycle management places stronger emphasis on configuration management and change control across thousands of I/O points, while SCADA lifecycle management emphasises cybersecurity patching and communication link redundancy.
Yes, the lifecycle principles are technology-agnostic. However, the specific activities within each phase differ: DCS lifecycle management places stronger emphasis on configuration management and change control across thousands of I/O points, while SCADA lifecycle management emphasises cybersecurity patching and communication link redundancy.
