A common problem for control engineers is how to design systems for long lifetimes, often 10 to 20 years, when using technologies that seem to change and become obsolete daily.

The IT world has over 40 years of explosive growth and changes with quarterly upgrades in hardware, operating systems, and applications. It is difficult to buy the same IT hardware today that you bought last year, or even last month. Application software has one or two releases per year and loss of support after 3 years. Operating systems (OSs) are a little better; the time from first release to out-of-support is about 5 years. Unfortunately, all of these lifetimes are much shorter than the typical lifetime of a process control system. Yet, we now have more reliance on commercial off-the-shelf technologies in control systems and are asked to support IT systems well beyond their normal lifetimes.

Effectively managing the lifecycle of automation systems requires looking at all system elements. In IT systems, core functions generally are difficult to change while peripheral functions are easier to change. The typical IT system has core functions built around data structures and specialized applications. When these elements change, the effect can ripple through the entire system and changes are often visible to the user through new business processes, operating procedures, and application interfaces. The OS, standard applications, and hardware are typically peripheral functions. Upgrade of a server OS (from Microsoft Windows 2000 SP3 to Windows 2000 SP4 or even to Windows Server 2003) can be a minor event, and changes in hardware are often invisible to the user. Even changes to standard packaged applications, such as word processors, spreadsheets, and browsers, usually have a minimal impact on users.

In control applications, the situation is often reversed. In applications where SCADA, PLC, or PC-based control are used, a change in the hardware, OS or packaged application usually has a major impact and may even cause the entire system to fail. Changes to these core functions require retesting and revalidation of the entire system. However, changes to application data and special applications, such as PLC and SCADA programs, are often invisible to users, routinely performed, and usually require less retesting.

This means that the rules used to manage the lifecycle of IT systems need to be inverted when used to manage the lifecycle of process automation systems. Hardware and OS changes are difficult in automation systems and easier in IT systems. Changes in application-specific programs and user interface screens are common in automation systems and more difficult in IT systems. Organizations set up to do lifecycle management of process automation IT systems need to have a different support process, a different skill set loading, and probably a different organization than standard IT support organizations.

Providing stability with continually changing IT elements requires identifying systems that cannot change without significant impact and identifying systems that can change with minor impact. For example, networks are peripheral if they are based on standard Ethernet technology. Basic network wiring, routers, and bridges can often be updated with minimal impact and limited testing. Database servers, files servers, and print servers can also often be updated with limited impact. However, changes to packaged applications, such as HMI, historians, MES, and batch systems, can have significant impact and require major testing. Core systems should be placed on a standard review cycle, such as once every two years, where each system is reviewed, lifecycle support risks are determined, and the decision to retain, upgrade, or replace is made. Non-core systems can be reviewed on a shorter cycle or when upgrades are available, since upgrades are less severe. Core elements will need a larger support organization that operates on a project basis, while peripheral systems will primarily have reactive support organizations. Creating stability and consistency in the IT world requires attention to core lifecycle support elements and continual review and evaluation of lifecycle risk.