Obsolescence Management of Software Components

Introduction to Obsolescence Management- White Paper

Obsolescence Management of hardware components can be well understood and implemented: 

1. You generate a Bill of Materials (BOM) of all the components of your systems. 
2. You then assess risks of obsolescence of these components to prioritise and develop strategies to deal with obsolescence, then continually monitor and review.

However, one item not always included in the BOM is software therefore software is just as important to the BOM like any other component.

Then the same process manages the obsolescence of the software components like it did for the hardware components. What is a software component in Obsolescence Management?

What is a software component in Obsolescence Management?

A software component comes in two distinct types:

• Commercial off the shelf (COTS) software,
• Customer-specific software.

The management of both types of software component is important.

Customer-specific software is software developed bespoke for your systems. This could include source code, open source components, third party commercial components, data, requirements, documentation and associated manuals.  Considering this during obsolescence management is important as together it constitutes customer-specific software 

How does software become obsolete?

Since software does not wear out and is easy to duplicate, obsolescence issues does not affect it in the same way as hardware.

However software differs from hardware through one special requirement: the need for change.

Because software is complex, running systems can have undiscovered design faults that need fixing immediately. Similarly, it is impractical to test all possible permutations of inputs and outputs of a complex system so there can be operational faults discovered where the system does not comply with the requirements, and these need to be fixed.

Generally, you need to be able to enhance a complex software system to improve performance or when requirements change or when regulations change to ensure continuing compliance.  External factors such as cyber security threats can also force changes to a software system.

Any unsupported changes to software results in obsolete software.

What causes software obsolescence?

There are many causes of software obsolescence, both direct and indirect including:

• Hardware – new hardware may not support old software, and it’s not always possible to purchase supported, old hardware. Obsolescence issues with hardware can subsequently cause obsolescence issues with software.  The reverse is also true where new software does not run on old hardware. So, where strategies involve upgrading software, then the impact on hardware platforms needs consideration.
• COTS software – software suppliers obsolete their software as part of their business model, to encourage users to invest in upgrades. And so any unpatched COTS software can cause issues with cyber security vulnerabilities
• Loss of software integrity – uncontrolled changes leaves documentation out of date and software unsupportable over time. Poor revision control, backups and media management all damage the integrity of the software thus making it very difficult to support changes.
• Data formats change – old software may employ data formats for saving information that themselves become obsolete and are not compatible with newer operating systems.
• Support vendors go out of business – any contracted support of the system can cause the support vendor to go out of business therefore it may not be easy to find others with the same level of expertise.
• Suppliers do not sell licenses any more – suppliers of a system may stop selling or renewing licenses for old software preventing it from running (or running legally and properly licensed).
• Loss of expertise for old systems – the software may use old programming languages and old programming tools with which younger engineers have no experience.  Knowledge of the requirements of a system and experience of the equipment under control may be held by older engineers.
• Across industry, research suggests that 50% of skilled labour will retire in next 10 years, and consequently this can lead to obsolescence issues.

Is software obsolescence a problem?

With a major rise in use of programmable systems over the last 25 years, software obsolescence has become a major problem which will continue to grow.  This manifests in many ways including:

• Extended downtimes when faults occur since it takes much longer to restore the software and get it back up and running.
• Forced and unplanned expenditure on upgrading hardware and software. When there is a failure of obsolete software the only solution may be to upgrade which can also result in the need to upgrade hardware and have to be done unexpectedly when there is no planned budget for this activity.
• Greatly increased upgrade costs to reverse engineer obsolete software that has lost all its integrity.
• Safety issues raised through software obsolescence. Recently there has been a regulatory focus on obsolescence management as part of the overall integrity management of systems.
• Non-compliance when running software not properly licensed.
• Cyber Security vulnerabilities can appear in obsolete software via newly discovered cyber threats and through unpatched software.

How to manage software obsolescence?

Manage software obsolescence as part of your general obsolescence management. This is achievable by using a 5 Step Approach in compliance with the international standard for obsolescence management IEC 62402.

Generate Bill of Materials

Include all software components in your BOM including:

• Customer-Specific Software – software components you have created or had created for you.
• COTS Software – software components you have purchased.
• Target Environment – the runtime platform of your production systems including operating systems and dependent hardware.
• Development Environment – the development/test platforms including operating systems and dependent hardware.
• Interfaces – drivers and other interface software required for your systems to communicate with each other and with external systems.

Dependencies

Software components tend to have multiple dependencies on other software components, hardware components and support activities.

A chain links these dependencies, with multiple tiers.  The number of dependencies grows at each tier and an obsolescence issue at any tier can affect the top level software.

The Bill of Materials should include the dependencies. 

Assess Probability of Obsolescence

You can determine the probability of the obsolescence of software components by considering the probabilities of the various causes of software obsolescence occurring for your systems.

The probability of obsolescence is further increased by the software component having multiple dependencies.  Assuming the probabilities of obsolescence of all dependencies are independent then the probability at any tier will increase by the sum (OR) of all the dependent probabilities:

Assess Impact of Obsolescence

Many impacts of obsolescence require consideration and assessment.

Extended downtimes or forced large and unexpected upgrades can contribute to increased and unplanned costs.

A forced system freeze where no changes are possible will reduce performance of your systems and increase running costs.

Security breaches, safety issues and regulatory notices will incur extra costs but also cause damage to your reputation and future growth potential.

Assess Risk of Obsolescence

The overall risk of obsolescence is calculated from the impact of obsolescence and the probability of it happening, using a risk matrix:

Carrying out risk analysis in multiple passes is possible such as the disregard of low risks, and the analysis of medium and high risks in more detail. This then allows you to prioritise the software components and develop strategies, working through the top priorities first.

Develop Strategies

By developing strategies, obsolescence risks of your software components is reduced. This includes both reactive or proactive strategies. 

A reactive strategy means do nothing until a problem arises.  Usually this would only be applicable for low risk components but employable where the costs of a proactive strategy are prohibitively high.  Careful consideration of cyber security and safety implications of any reactive strategy is crucial due to the risk it carries. 

A proactive strategy means taking action before a problem occurs to reduce the probability or impact of the problem and so reduce the risk.

For software components there are many proactive strategies:

• Rigorous configuration change management to protect the integrity of the software. This allows supported changes in the future. This process will ensure all supporting information and documentation are kept up to date.
• Emulation to allow old software to run on new hardware.
• Open source/portability to reduce the dependency on operating systems and programming platforms. There is a portability standard for Programmable Logic Controllers (IEC 61131-3), foundation (PLCopen), and also higher level languages like Java. 
• Patching to ensure the latest installation of (security) updates. It is important to properly manage patches and have a testing and roll out plan, which ties in with your BOM.
• Suppliers may allow License downgrades to keep software running after it is no longer a current product.
• Licence downgrade by suppliers to keep software running after it is no longer a current product.
• In-house knowledge base to retain expert knowledge in-house and not rely on external contractors.
• Support contracts placed for long term support of systems to ensure continuity of support and guarantee availability of expertise.

When considering strategies to reduce the probability (and therefore risk) of obsolescence try to break the chain of dependencies.  Target nearer the top of the chain to get the biggest risk reduction.

Obsolescence Management System

All obsolescence information including your plans, BOM, risk assessments, strategies and reviews should be held in an obsolescence management system.  But much of this information is also used in your configuration change management, cyber security management and intellectual property (IP) management.

In order to optimise investment, it makes sense to use a common system to manage all this information. This can be a configuration management system that manages your software and hardware configurations and all associated information such as change control, fault logging and documentation.  A configuration management system can also manage your obsolescence.  This allow all your existing configuration information to feed in to your obsolescence management.

How much will it cost/save?

Obsolescence management is a cost avoidance exercise.  It prevents you having extra and unplanned costs.

You can also save cost investment by using a configuration management system to feed information into your obsolescence management and further share costs by using the same data and system for your cyber security management and IP management.

On a large site the BOM may contain 30,000 hardware components of which includes 2000 medium or high risk.

The same site may have 400 software components, of which it is likely a higher percentage will be medium or high risk, say 50%.  There will also be more dependencies with software resulting in more complex analysis of risks.

So as an estimate you could expect software obsolescence management to be around 10-20% of the cost of hardware obsolescence management, for the same site.

As for what savings you could make, there is little historical research on losses due to software obsolescence issues.  Companies tend to be secretive when they are hit by these issues, especially if there have been cyber security breaches, for fear of damaging their reputations.  However, there is some research being carried out currently, so we may be able to have a better understanding of potential savings in the future.

Conclusions

You should carry out obsolescence management of your software components as well as your hardware components using the same management process, in line with the obsolescence management standard IEC 62402.

Software becomes obsolete when changes are no longer supported.  You can manage your obsolescence by: 

• Adding software components to your Bill of Materials.
• Including dependencies to other software and hardware.
• Assessing probabilities, impacts and risks.
• Determining strategies to reduce risks.
• Breaking the chain of dependencies to reduce probabilities and risks.
• Reducing costs by using a common configuration management system to manage obsolescence, cyber security and intellectual property.

Software obsolescence management will avoid extra and unplanned costs, ensure the integrity of your systems and protect the reputation of your company.

References

1. IEC 62402:2007, Obsolescence management – application guide
2. IEC 62443, Industrial communication networks – Network and system security
3. IEC 61131-3:2013, Programmable controllers – Part 3: Programming languages
4. Sandborn P (2007), Software Obsolescence – Complicating the Part and Technology Obsolescence Management Problem, IEEE Trans on Components and Packaging Technologies, Vol. 30, No. 4, pp. 886-888
5. Rajagopal S, Erkoyuncu J A, Roy R (2014), Software obsolescence in defence, 3rd CIRP Global Web Conference
6. Romero Rojo F J, Roy R, Kelly S (2012). Obsolescence Risk Assessment Process Best Practice, Journal of Physics: Conference Series, 2012, Volume 364, 012095
7. Schmid E, Kosugi G, Ibsen J, Griffith M (2016). Don’t get taken by surprf
8. ise: planning for software obsolescence management at the ALMA Observatory, Proc. SPIE 9913, Software and Cyber infrastructure for Astronomy IV, 99131A
9. Rajagopal S (2015). Software Obsolescence Online Survey Results, SCAF Workshop “Data Maturity and its Applications”
10. The IIOM

Written by Iain Rennie. As AGSL’s Product Development Manager, Iain Rennie is responsible for leading the company’s product development and technology strategy. Before joining AGSL in 2008, Iain was employed for 14 years as a process control and automation specialist for Elite Control Systems Limited, where he worked on projects in Europe, China, the USA and Azerbaijan. He is the company’s Quality Manager, and heads the Asset Guardian software solution development team. Iain holds a Bachelor of Science - Honours degree in Mathematical Physics from the University of Edinburgh, and a Master’s degree in Control Systems Technology from Edinburgh’s Napier University in Edinburgh, where he graduated with distinction. A Chartered Engineer, he is a member of the Institution of Engineering and Technology (IET).