8 sposobów na udoskonalenie projektów dotyczących systemów sterowania

Aby zapewnić sukces projektu systemu sterowania, należy postępować zgodnie z niniejszymi zaleceniami.

Systemy sterowania procesami stają się coraz potężniejsze i coraz bardziej skomplikowane. Szacuje się, że w przyszłości w jeszcze większym stopniu będą stanowić integralną część systemów obejmujących cały zakład bądź całe przedsiębiorstwo.

Dobrze zaprojektowany, oparty na sieci system nadzorujący proces przynosi znaczne korzyści. Z kolei uruchamianie i obsługa niewydajnych systemów może pochłonąć wiele czasu – straty mogą okazać się nader kosztowne i trudne do nadrobienia. Nieprawidłowo zaprojektowane lub powolne systemy zwiększają zmęczenie operatora i mogą być przez to niebezpieczne.

Projektowanie systemów sterujących nie powinno znajdować się na marginesie, poza ogólnymi planami projektowymi i biznesowymi przedsiębiorstwa. Oto kilka sposobów uniknięcia niebezpieczeństw związanych z projektowaniem systemów sterowania.

1. Wymiana informacji przed wizytą

Przed wizytą u klienta należy przygotować plan takiej wizyty i przedstawić go wszystkim zainteresowanym projektem osobom. Trzeba się na przykład dowiedzieć, czy klient oczekuje prezentacji danych przekazywanych do modułów SAP? Czy zostanie przedstawiona i uzgodniona lista tagów XML? Wymagania należy określić przed wizytą, aby druga strona miała wystarczająco dużo czasu na przygotowanie się.

Czy będzie potrzebna analogowa linia telefoniczna lub sala konferencyjna? Czy cel wizyty jest czysto techniczny, czy należy poświęcić czas na omówienie harmonogramu prac związanych z projektem? Możliwość wcześniejszego przygotowania się do wizyty to znaczne ułatwienie dla drugiej strony. Z kolei nie wypada zmuszać do czekania, aż zostanie spełniona prosta, ale za to bardzo istotna prośba.

2. Zaakcentowanie szaty graficznej przyjaznej dla operatora

Operatorzy pracujący w fabrykach spędzają z systemami sterowania więcej czasu niż ktokolwiek inny. Oprócz pracy wykonywanej na linii czy na zewnątrz, sporo czasu (a nawet niekiedy cały czas pracy) operator spędza naprzeciwko monitora, pracując z graficznym interfejsem. Dlatego najpierw należy zadbać, aby ten właśnie aspekt programowania został solidnie przygotowany i zaaprobowany. Zakład może jakoś sobie poradzić bez ciągłego sięgania do systemu ERP, ale nie będzie poprawnie pracował, jeśli ekran naprzeciwko operatora będzie czarną, szklaną płaszczyzną.

Nie spotykany do tej pory zakres możliwości terminali NT ułatwia zaprogramowanie na wyświetlaczu bardzo dużej liczby „zakłóceń wizualnych”. Skomplikowane podglądy maszyn, oznaczanie rur różnymi kolorami, migające wartości oraz wskaźniki imitujące fizyczne urządzenia wyglądają dobrze na prezentacjach, ale powiększają zmęczenie i poirytowanie operatora. Nie należy ulegać pokusie i zapełniać ekran nadmiarem informacji.

3. Oprogramowanie należy testować inteligentnie

Trzeba próbować wynaleźć słabości programu – radzenie sobie z sytuacjami wyjątkowymi jest kluczowym zagadnieniem. Na przykład podczas testowania okien dialogowych trzeba spróbować wpisać bezsensowne symbole zamiast wartości dozwolonych czy poprawnych nastaw. Należy spróbować otworzyć większą liczbę okien, niż jest to zalecane. Rzeczywiste, robocze środowisko operacyjne różni się od środowiska programisty; trzeba uwzględnić, że operatorzy będą naciskać wiele przycisków szybciej, niż jest to przewidziane i często nie wtedy, kiedy powinni.

Najlepsze są rzeczywiste rezultaty. Podczas testowania systemu sterowania i zapisywania otrzymanych wyników najlepiej posługiwać się rzeczywistymi numerami wskaźników, dosłownie brzmiącymi komunikatami i szczegółowymi opisami. Dzięki takiemu podejściu można prześledzić procedury testowania oraz powtórzyć je, co jest wymagane w niektórych gałęziach przemysłu.

Należy brać pod uwagę życzenia klienta. Na przykład przed testowaniem regulatora PID trzeba uzgodnić, czy testowany ma być szablon (template), pojedynczy przypadek (single instance) czy wszystkie możliwe warianty. Niektórzy klienci mogą nie życzyć sobie testowania szablonów regulatorów PID, uznając to za marnowanie przeznaczonych na projekt pieniędzy. Przegląd (wspólny) standardowych procedur QA (quality assurance – zapewnienie jakości) powinien udzielić odpowiedzi na to pytanie.

Trzeba pamiętać, że projekt dotyczący programu sterującego procesem, to nie tylko sam program. Za zgodą klienta na którymś etapie testowania mały zespół ludzi powinien sprawdzić każdy terminal wejściowy i wyjściowy, wykonać symulację i zmierzyć rezultaty. Sprawdzanie pętli (loop checking) po wykonaniu instalacji jest znacznie łatwiejsze, ponieważ większość problemów zostaje ograniczona z racji specyfiki konkretnego zastosowania. Wykrywanie i usuwanie w małym zespole usterek programu sterującego przed wdrożeniem go jest znacznie bardziej wydajne niż zmuszanie całego zespołu osób testujących program w pętli do wprowadzania zmian w programie. Podczas testowania należy otwierać i zawory FO (zazwyczaj otwarte), i zawory FC (zazwyczaj zamknięte). Należy porównywać elementy ekranu z listą I/O.

4. Klient powinien być właścicielem dokumentów

Systemy dostarczane „pod klucz” mają pewne zalety, ale jeśli nie są zarządzane we właściwy sposób, mogą więcej kosztować użytkownika końcowego. Jeśli klient nie jest właścicielem, programista systemu sterującego musi współpracować z wieloma osobami, próbując wprowadzać zmiany i odpowiadać na pytania. Użytkownik końcowy znający wszystkie aspekty projektu działa jako swoisty filtr.

Na przykład grafika ekranowa powstaje często w rezultacie przeniesienia na ekran rysunków z planów i dokumentacji zakładowej. Dokumenty te są zmieniane i ulegają dezaktualizacji w miarę rozbudowy lub przekształceń fabryki i samego systemu sterującego. Sprawdzanie każdej wersji tylko po to, żeby odkryć wprowadzenie małej zmiany w instalacji rurowej kosztowałoby dostawcę programu sporo czasu i pieniędzy. Powierzenie kontroli klientowi może zapewnić wyższą jakość (poprawność i precyzję) odwzorowania. Proces konstruowania oprogramowania jest wysoce nieliniowy, zatem angażowanie w projekt wielu stron znacznie go spowalnia.

5. Należy się dowiedzieć, czy potrzebna jest właśnie „ta maszyna”

Ze względu na niektóre procedury oraz wymagania charakterystyczne dla danej gałęzi przemysłu oprogramowanie powinno być testowane na konkretnym sprzęcie, który będzie pracował w tej właśnie fabryce. Wykonawcy oprogramowania powinni okresowo sprawdzać harmonogramy (grafiki czasowe), konsultując je bezpośrednio z firmą, aby upewnić się, czy nie ma konfliktu między wymaganiami programistycznymi a produkcyjnymi. Trochę niezręcznie jest wstrzymywać produkcję, kiedy nie da się wprowadzić prostej z założenia zmiany, co w konsekwencji opóźnia wysyłkę produktu. Jeśli do testowania mają być użyte terminale (fascimile terminals) i systemy sterujące, klient powinien być o tym powiadomiony.

6. Współpraca z Obsługą Klienta

Czasami zgłaszający się z reklamacją użytkownik wyświadcza przysługę projektantowi oprogramowania. Należy uszanować fakt, że właściciel systemu sterującego w istocie testuje go przez sam fakt jego obsługiwania. Taki test jest kosztowny dla właściciela, ale tani dla osoby konfigurującej system. Zespół obsługujący przez cały czas pracuje w obrębie systemu i działa jako naturalny mechanizm wychwytywania błędów w czasie rzeczywistym. Dział Techniczny oraz dział Obsługi Klienta firmy programistycznej powinny zostać uczulone na zwracanie szczególnej uwagi na wszelkie skargi klienta i przekazywanie ich w całości zespołowi wykonującemu oprogramowanie dla tego użytkownika.

     Aby osiągnąć sukces w realizacji projektu dotyczącego systemu sterującego, należy postępować zgodnie z wymienionymi zaleceniami.

 

     Przestrzeganie kilku prostych zasad bezpieczeństwa na początkowych etapach projektu może w znacznym stopniu przyczynić się do sukcesu całego przedsięwzięcia. Oto osiem zalecanych działań:

 

1. Przed odbyciem wizyty u klienta należy sprecyzować oczekiwania.

2. Ze szczególną uwagą należy potraktować graficzny interfejs użytkownika; operatorzy sporo czasu spędzają przed monitorem.

3. Oprogramowanie należy testować inteligentnie; jeśli coś może się wydarzyć, to najprawdopodobniej się wydarzy.

4. Trzeba pamiętać, że klient końcowy powinien być właścicielem list I/O, planów i dokumentacji oraz innych dokumentów; kontrola powinna być w gestii klienta.

5. Jeśli zachodzi potrzeba przetestowania rzeczywistej maszyny, należy się upewnić, że jest ona dostępna do celów testowych.

6. Współpraca z personelem klienta może być cennym źródłem informacji.

7. Wszystkie zainteresowane osoby należy zachęcać do uczestnictwa w projekcie, na bieżąco je informować oraz zdobywać od nich dane i opinie.

8. Należy się wstrzymać z wprowadzaniem aktualizacji projektu do osiągnięcia ważnych etapów modernizacji środowiska projektu.

7. Uzyskanie aprobaty osób zaangażowanych

Jeśli aktualizacja programu (upgrade) jest niewielka, a jej wpływ będzie nieznaczny, przed wprowadzeniem zmian wystarczy powiadomić o tym osoby, których to dotyczy (dział informatyki, produkcję, dział techniczny). Należy rozważyć znaczenie wprowadzanych zmian. Nikt nie lubi być zaskakiwany całkiem nowym środowiskiem pracy. Lepiej zapytać operatorów o ich zdanie na temat grafiki interfejsu i spotkać się z przedstawicielami działu informatyki (IT), aby ustalić najlepsze sposoby włączenia systemu do fizycznej warstwy zakładu. Należy również wziąć pod uwagę kwestie czasu. W przypadku procesów okresowych aktualizacja czy zmiana mogą zostać wprowadzone „po cichu”. W przypadku aktualizacji ciągłych należy zastosować specjalne środki ostrożności.

8. Oczekiwanie na aktualizację programu i pakiety serwisowe (service packs)

Opracowanie systemu sterującego nie jest projektem trywialnym. Zazwyczaj zajmuje wiele miesięcy. Podczas prac nad projektem z pewnością pojawią się aktualizacje systemu operacyjnego oraz różnych elementów dostarczanych przez dostawców. Z wprowadzaniem ich należy się wstrzymać do czasu osiągnięcia ważnych etapów realizacji projektu. Takie planowanie ułatwia izolowanie problemów związanych z samym procesem aktualizacji.