9 sposobów na uniknięcie kryzysowej modernizacji sprzętu IT w automatyce

Nikt nie lubi być wzywanym do serwisu starej automatyki lub systemów informatycznych. Systemami takimi, bez wsparcia technicznego, dokumentacji i oznaczeń, nikt nie chcę się zająć, bo najczęściej oznacza to: „zabrałeś się za to, więc teraz to jest Twój problem”.

Ostatnio musieliśmy się zająć naprawą paru dwunastoletnich routerów, które służyły do sterowania automatyką budynku, zbierania danych i powiadamiania obsługi o ewentualnych alarmach. System był czymś pomiędzy automatyką przemysłową a IT biznesowym. Sprzęt był typowy dla zastosowań biznesowych, ale jego aplikacja – łącząca automatykę budynku i systemów użytkowych – już nie. Nie był to ważny system sterujący produkcją, ale ważny system obsługujący automatykę budynku. Był on w kiepskiej kondycji, z występującymi sporadycznie problemami z pamięcią i ze skorodowanymi połączeniami, jako że routery nie pracowały w kontrolowanym środowisku dedykowanym do takiego sprzętu. Kiedy system się w końcu zepsuł, mieliśmy do czynienia z sytuacją „skoro się za to zabrałeś, to teraz to skończ”.

Nikt nie chciał dotykać takiego systemu – wykorzystywał on interfejs RS-232 oraz niezrozumiały wiersz poleceń. Nie istniała żadna dokumentacja i nie było można znaleźć nikogo, kto 12 lat temu pracował nad konfiguracją tego sprzętu. W dodatku nie robiono backupów, a schematu przywracania systemu nigdy nie przetestowano. Ponieważ było wiadomo, że przy pierwszej instalacji pracował profesjonalny automatyk jasnym było, że mamy do czynienia z zaawansowanym systemem. Po wielu próbach naprawienia starego sprzętu zainstalowaliśmy w końcu cztery nowe switche z obsługą z poziomu przeglądarki, stworzyliśmy nową dokumentację, a także opracowaliśmy i przetestowaliśmy plan awaryjnego przywracania systemu.

Z perspektywy czasu mogę powiedzieć, że zaangażowaliśmy do tego najlepszą możliwą ekipę wyposażoną w odpowiedni sprzęt. Nasi automatycy regularnie serwisują systemy, które mają 10, 20 a nawet 30 lat. Regularnie też pracują z dokumentacją starych systemów nazywanych MULES (Mature Unsupported Legacy Execution Systems). Często mają do czynienia z interfejsem opartym o wiersz poleceń i bezpośrednim podłączeniem, które były powszechne od lat 80-tych do początku XXI wieku. Często również muszą radzić sobie z systemami sterowania lub wsparcia produkcji, współpracując przy tym z personelem w kwestii opracowania grafiku czynności serwisowych.

Podobne sytuacje będą miały miejsce również w przyszłości. Systemy opracowywane począwszy od połowy lat 80-tych bazowały najczęściej na komercyjnym sprzęcie i oprogramowaniu, które nie są już kompatybilne ze współczesnym biznesowym sprzętem IT. Sprzęt oraz oprogramowanie IT dedykowane do zastosowań biznesowych jest zwykle kompatybilne z systemami maksymalnie 10-cio letnimi, podczas gdy ten stosowany w automatyce musi współpracować również z systemami znacznie starszymi. Jako, że kompatybilność i wsparcie dla starszych systemów opartych o rozwiązania biznesowe spada, to automatycy będą musieli przejąć obsługę takich systemów.

9 sposobów, by uniknąć kryzysu

Istnieje parę prostych zasad, których dział IT powinien przestrzegać, by w razie problemów modernizacja nie była prowadzona na zasadzie działania w sytuacji kryzysowej.

1. Przede wszystkim trzeba zapewnić trwałe oznaczenie umożliwiające identyfikację wszystkich systemów.

2. Każdy system powinien mieć przypisany dział, który zapewnia wsparcie oraz określone interwały serwisowe.

3. Nie można zakładać, że w firmie nic nie zmieni się przez 10 lat, dlatego trzeba być gotowym na zmianę oznakowania.

4. Należy przeprowadzać przynajmniej raz do roku przegląd urządzeń, a także sprawdzać, czy dokumentacja instalacyjna jest dostępna i aktualna oraz czy istnieją procedury przywracania systemu.

5. Jeśli w firmie nie ma dedykowanego systemu utrzymania ruchu, można wykorzystać elektroniczny kalendarz do pilnowania terminów oraz zapisywania dodatkowych informacji.

6. Powinno się wykorzystywać planowanie długoterminowe w zarządzaniu informacjami.

7. Nie można polegać na tym, że takie same urządzenia, np. serwery, będą dostępne za 5 lub 10 lat.

8. Nie wolno zakładać, że dyskietki lub płyty CD będą w użyciu za 15 lat.

9. Nie należy oczekiwać, że końcowy użytkownik dostarczy potrzebnych informacji o systemie.

Jeśli pewnego dnia będziesz w zespole, który pracuje przy systemach typu MULES, bądź przygotowany, że spotkasz nieznane środowisko informatyczne. Nie możemy przewidzieć, jak będą wyglądały systemy IT w przyszłości, ale jeśli historia może nas czegoś nauczyć, to tego, że systemy te będą kompletnie różne od tego co znamy dziś – opartych na Ethernecie i serwerach.

Autor: Denis Brandl jest prezesem BR&L Consulting w Karolinie Północnej w USA. Jego firma skupia się na IT dla branży produkcyjnej.

Tłumaczenie: Dawid Miś