Tu nie chodzi jedynie o technikę

Czasami integracja systemów informatycznych (technik IT): komputerowego wspomagania procesów biznesowych oraz nadzorowania i prowadzenia procesów produkcyjnych wydaje się trudniejsza niż kiedyś. Nie jest to bynajmniej spowodowane faktem, że problem ten jest dziś bardziej skomplikowany. W rzeczywistości obecne normy przemysłowe oraz współczesne języki symboliczne (np. XML) nawet ułatwiają samą integrację. Okazuje się ona jednak trudniejsza ze względu na fakt, że podstawowe techniki są dzisiaj takie same jak kiedyś. W czasach, gdy te systemy opierały się na firmowych komputerach i sieciach, łatwo było zadecydować, gdzie znajdują się granice – zarówno granice odpowiedzialności, jak i ograniczenia techniczne były wówczas takie same. Obecnie te granice są nieostre, ponieważ używamy serwerów działających w systemach MS Windows i Linux, z komercyjnymi bazami danych oraz standardowymi sieciami w aplikacjach regulacji, nadzorowania i zarządzania.

 Często zdarza się, że gdy podczas projektowania nadchodzi moment podjęcia decyzji o rozdzieleniu systemu, decydującym czynnikiem jest technika, a nie podstawowe wymogi automatyki. Każdy, kto potrafi posługiwać się jakimś narzędziem, ma naturalną skłonność, by stosować je również do takich zadań, do których nie zostało ono zaprojektowane. Któż z nas nie używał na przykład śrubokrętu do wbijania gwoździ? Stosując w automatyce techniki informatyczne musimy nie tylko sami być świadomi, ale również uzmysłowić wszystkim pracownikom działów IT, że sam fakt zastosowania danej techniki w innych obszarach nie oznacza wcale, że należy jej używać wszędzie. I chociaż istniejące rozwiązania mogą spełniać wiele wymogów dotyczących funkcjonalności, należy również wziąć pod uwagę kwestie związane z dostępnością, niezawodnością i stabilnością. Aby pamiętać o tych wymogach przy rozważaniu zastosowania technik informatycznych, należy przyswoić sobie dwie proste prawdy: „czas na nikogo nie czeka” oraz „rzeczywistości nie da się cofnąć”.

Projektując systemy informatyczne zazwyczaj bierze się pod uwagę wymagania dotyczące wydajności, takie jak średni czas reakcji na przejrzenie raportu, dostęp do danych bądź drukowanie raportu. Opóźnienia czasu reakcji dla zastosowań biznesowych mogą być uciążliwe i zmniejszać wydajność, jednak tylko w wyjątkowych okolicznościach przyczyniają się one do generowania strat finansowych. Opóźnienia czasu reakcji dla systemów pracujących w procesach wytwórczych mogą być naprawdę niebezpieczne i kosztowne. Należy bowiem pamiętać, że „czas na nikogo nie czeka”. Jeśli na skutek awarii sieci operator traci na kilka minut możliwość wglądu w proces, wówczas ludzie mogą być narażeni na ryzyko, produkt może ulec zniszczeniu bądź może zostać uszkodzony sprzęt. Stosując systemy informatyczne w automatyce, należy mieć świadomość implikacji, które z tego faktu wynikają, a także zdawać sobie sprawę z architektury aplikacji. W przypadku, gdy stosowanie standardów technik IT ma charakter ogólny, na przykład pojedynczy bank danych dla całego systemu automatyki, należy rozważyć, co się stanie, gdy będzie on tymczasowo niedostępny. Dzieje się tak zwłaszcza wtedy, gdy dostęp do jednego urządzenia odbywa się za pośrednictwem rozległej sieci komputerowej WAN. Chociaż funkcje wymagane przez automatykę i charakter przedsięwzięcia mogą być spełnione przez pojedynczą aplikację, fakt, iż systemy pracujące w czasie rzeczywistym nie mogą sobie poradzić z nieokreślonymi opóźnieniami, oznacza, że rozwiązania IT nie zawsze są najlepsze.

Inną wspólną cechą systemów informatycznych dla biznesu jest to, że większość działań może zostać „odtworzonych”. W wielu takich systemach kopie zapasowe tworzone są po każdej transakcji bądź w zaplanowanych odstępach czasu. Jeśli aplikacja zawiedzie i baza danych ulegnie zniszczeniu, jest ona „odzyskiwana” w stanie sprzed awarii, a transakcje wykonywane są ponownie. Z wyjątkiem sytuacji szczególnych – jak w przypadku komunikacji pomiędzy firmami typu business-to-business bądź pomiędzy firmą a klientem (business–to-customer) – większość transakcji biznesowych może być odtworzona. Jednak problemy automatyki są znacznie bardziej wymagające. Kiedy już dane działanie zostanie podjęte, wówczas jego cofnięcie jest bardzo kosztowne lub wręcz niemożliwe. Rozmontowanie gotowego samochodu jest tylko kosztowne, ale „odmieszanie” roztworu chemicznego jest niemożliwe. Ogólnie rzecz biorąc, zastosowania IT, które polegają na możliwości ponowienia działania w przypadku zaistnienia awarii, nie nadają się do stosowania w automatyce. Na przykład, gdy w projekcie automatyki stosuje się usługę automatycznego pobierania poprawek, jeśli zostanie przesłana nieprawidłowa poprawka, wówczas w środowisku biznesowym może to być naprawione przy minimalnej utracie wydajności, natomiast w środowisku automatyki takie zdarzenie może spowodować poważne straty produkcyjne a nawet uszkodzenia mechaniczne.

Stosując rozwiązania IT w środowisku automatyki należy pamiętać, że tu nie chodzi jedynie o technikę. Działające rozwiązanie wymaga również wytężonej uwagi na kwestie związane z dostępnością, niezawodnością oraz stabilnością. Rozwiązań IT nie należy stosować tylko dlatego, że są dostępne. One muszą również spełniać wszelkie wymagania dla konkretnego nowego zastosowania.

 

Dennis Brandl, dbrandl@brlconsulting.com, jest prezesem BR&L Consulting – firmy konsultingowej zajmującej się rozwiązaniami IT dla przemysłu.