Obsolescence Management of Software Components

Published by Iain Rennie on
Iain Rennie, product manager at Asset Guardian Solutions Limited discusses obsolescence management of software components

Introduction

Obsolescence management of hardware components can be well understood and implemented.  You generate a Bill of Materials (BOM) of all the components of your systems.  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.  Software should be added to the BOM like any other component.  Then the obsolescence of the software components can be managed using the same process as hardware components.

What is a software component?

A software component comes in two distinct types:

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

Both types of software component should be managed for obsolescence.

Customer-specific software is software that may have been developed bespoke for your systems, and could include source code, open source components, third party commercial components, data, requirements, documentation and associated manuals.  All this together constitutes customer-specific software and should all be considered during obsolescence management.

How does software become obsolete?

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

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

Because software is complex there can easily be undiscovered design faults in a running system that need to be fixed when they are discovered.  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.

If changes to software cannot be supported then software is obsolete.

 What causes software obsolescence?

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

  • Hardware – new hardware may not support old software, and it may not be possible to purchase old hardware that is supported. Obsolescence issues with hardware can 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, the impact on hardware platforms also has to be considered.
  • COTS software – software suppliers obsolete their software as part of their business model, to encourage users to invest in upgrades. If COTS software is not being patched then issues can arise with cyber security vulnerabilities.
  • Loss of software integrity – uncontrolled changes leave documentation out of date and software unsupportable over time. Poor revision control, backups and media management all damage the integrity of the software 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 – if support of the system is contracted out, then the support vendor can go out of business and 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, it is estimated that 50% of skilled labour will retire in next 10 years, so 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:

  • 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 can be 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 as new cyber threats are discovered and software is not being patched.

 How to manage software obsolescence?

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

AG 5-Step Approach to effective Obsolescence Management

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 that may be 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.

Multiple Dependencies

These dependencies are linked together in a chain, with multiple tiers.  The number of dependencies grows at each tier and an obsolescence issue at any tier can affect the top level software.

Chain of software dependencies

Dependencies should be added to the Bill of Materials.

Assess Probability of Obsolescence

The probability of obsolescence of software components can be determined 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:

Probability of Obsolescence Management

Assess Impact of Obsolescence

There can be many impacts of obsolescence and each should be considered and assessed.

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 can be calculated from the impact of obsolescence and the probability of it happening, using a risk matrix:

Assess Risk and Impact of Obsolescence
Obsolescence Risk Matrix

Risk analysis can be done in multiple passes where low risks are disregarded and medium and high risks are analysed in more detail.  This then allows you to prioritise the software components and develop strategies, working through the top priorities first.

Develop Strategies

Strategies should be developed to reduce the obsolescence risks of your software components.  The strategies may be reactive or proactive.

A reactive strategy means do nothing until a problem arises.  Usually this would only be applicable for low risk components but may be employed where the costs of a proactive strategy are prohibitively high.  Careful consideration should be given to cyber security and safety implications of any reactive strategy.

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 that can be employed:

  • Rigorous configuration change management to protect the integrity of the software and ensure changes can be supported 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) and foundation (PLCopen), and also higher level languages like Java were developed to be portable.
  • Patching to ensure the latest (security) updates are installed. It is important to properly manage patches and have a testing and roll out plan, which ties in with your BOM.
  • Planned upgrades allows you to plan budgets and downtime when it best suits you if upgrades become necessary.
  • Licence downgrade may be allowed 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.

Break the chain of dependencies

Obsolescence Mangement 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.  A configuration management system that manages your software and hardware configurations and all associated information such as change control, fault logging and documentation can be used to also manage your obsolescence.  This allow all your existing configuration information to feed in to your obsolescence management.

Configuration Management System

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 2000 may be considered as 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.  This should be done using the same management process, in line with the obsolescence management standard IEC 62402.

Software becomes obsolete when changes can no longer be supported.  This obsolescence can be managed 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”

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).