Częsty problem automatyków to: jak projektować systemy przy zastosowaniu technologii, które wydają się zmieniać i dezaktualizować z dnia na dzień, aby funkcjonowały one długo, niekiedy przez 10 do 20 lat. Świat informatyki ma za sobą 40 lat błyskawicznego wzrostu i zmian, z kwartalnymi aktualizacjami sprzętu, systemów operacyjnych i aplikacji. Trudno dziś kupić taki sam sprzęt komputerowy jak w zeszłym roku, a nawet w zeszłym miesiącu. Pojawia się jedna lub dwie wersje oprogramowania w ciągu roku, a przestaje się je serwisować po 3 latach. W przypadku systemów operacyjnych (OS) sytuacja jest trochę lepsza. Czas od pojawienia się na rynku do zaprzestania serwisowania wynosi około 5 lat. Niestety, żywotność wszystkich tych systemów jest znacznie krótsza niż typowa długość życia systemu sterowania. Niemniej w systemach sterowania mamy obecnie więcej zaufania do technologii komercyjnych ?z półki?. Wymagasię od nas serwisowania systemów informatycznych zdecydowanie dłużej niż wynosi ich standardowa żywotność.
"Zasady zarządzania cyklem życia odnoszące się do informatyki muszą zostać odwrócone, gdy stosuje się je do systemów sterowania."
Efektywne zarządzanie długością życia systemu sterowania wymaga analizy wszystkich jego elementów. W systemach informatycznych zwykle trudno zmienić podstawowe funkcje, podczas gdy peryferyjne znacznie łatwiej. Podstawowe funkcje typowego systemu informatycznego zbudowane są wokół struktur danych i specjalizowanych aplikacji. Gdy elementy te ulegają zmianie, efekt może oddziaływać na cały system, a zmiany są często odbierane przez użytkownika jako nowe metody zarządzania, metody pracy i systemy komunikacji z nim samym. System operacyjny, standardowe aplikacje i sprzęt są zwykle funkcjami peryferyjnymi. Uaktualnienie systemu operacyjnego serwera (z Microsoft Windows 2000 SP3 do Windows 2000 SP4 lub nawet do Windows Server 2003) może być zdarzeniem nieistotnym, a zmiany w sprzęcie są często niewidoczne dla użytkownika. Nawet zmiany standardowych aplikacji, takich jak edytory tekstu, arkusze kalkulacyjne i przeglądarki, mają zwykle minimalny wpływ na użytkowników.
W zastosowaniach z dziedziny sterowania sytuacja bywa zwykle odwrotna. Gdy używa się SCADA, PLC lub aplikacji sterujących opartych na komputerach PC, zmiana sprzętu, systemu operacyjnego lub aplikacji ma z zasady poważne konsekwencje i może nawet spowodować awarię całego systemu. Zmiany tych podstawowych funkcji wymagaj ą ponownego testowania i atestacji systemu. Niemniej zmiany danych aplikacji i aplikacji specjalnych, takich jak programy PLC i SCADA, często są niezauważalne dla użytkowników, dokonuje się ich regularnie i zwykle wymagają one mniej dokładnego testowania.
Oznacza to, że zasady stosowane do zarządzania cyklem życia systemów informatycznych muszą zostać odwrócone, gdy używa się ich do zarządzania systemami automatyki. Zmiany sprzętu i systemów operacyjnych są trudne do przeprowadzenia w systemach automatyki, łatwiejsze zaś w informatycznych. Zmiany w programach specyficznych dla danego zastosowania i w ekranach komunikacji z użytkownikiem są rozpowszechnione w systemach automatyki, a bardziej skomplikowane w informatycznych. Organizacje stworzone, aby zarządzać cyklem życia systemów informatycznych stosowanych w automatyce muszą opanować odmienny proces udzielania pomocy technicznej, inny zestaw umiejętności i posiadać prawdopodobnie inną strukturę niż standardowe organizacje świadczące pomoc techniczną w dziedzinie informatyki.
Zapewnienie stabilności w warunkach ciągłej zmiany elementów informatycznych wymaga zidentyfikowania systemów, które nie mogą zostać zmienione bez istotnych konsekwencji i tych, których zmiana nie będzie miała poważniejszych skutków. Na przykład sieci mogą być traktowane jako elementy peryferyjne, jeżeli opierają się na standardowej technologii Ethernetu. Podstawowe okablowanie, rutery i mosty zazwyczaj mogą być modernizowane bez poważniejszych konsekwencji i przy ograniczonym testowaniu. Modernizacja serwerów baz danych, plików i wydruku również często może mieć ograniczony wpływ na system. Niemniej zmiany aplikacji takich jak HMI, systemy informatyczne danych technologicznych (historiany), MES i systemy zarządzania procesami wsadowymi, mogą mieć istotne konsekwencje i wymagać dokładnych testów. Centralne systemy powinny podlegać standardowemu cyklowi przeglądów np. dwuletniemu, w którym każdy system podlega inspekcji, ocenia się ryzyko wynikające z jego cyklu życia i podejmuje decyzję pozostawienia, aktualizacji lub wymiany. Systemy nie będące głównymi mogą podlegać inspekcji w mniejszym zakresie lub wtedy, gdy pojawiają się aktualizacje, ponieważ ma to znacznie mniejsze konsekwencje. Elementy podstawowe wymagają wsparcia większej organizacji świadczącej pomoc techniczną, działającej na zasadach projektów, podczas gdy elementom peryferyjnym wystarczą organizacje świadczące pomoc techniczną w przypadku wystąpienia określonych zdarzeń. Utrzymanie stabilności i spójności w świecie informatyki wymaga zwracania uwagi na pomoc techniczną w zakresie podstawowych elementów systemu w czasie trwania całego cyklu jego życia, stałych inspekcji i oceny ryzyka wynikającego z tego cyklu.