Rozdział 5 Podsumowanie

Celem pracy było stworzenie kompletnego systemu wizualizacji i sterowania procesem przemysłowym. W ramach pracy:

Zaprojektowałem strukturę systemu, dokonałem wyboru technologii i narzędzi.
Napisałem prostą bibliotekę serwerową HTTP, która pozwoliła na uniezależnienie wchodzących w skład systemu programów od instalacji innego oprogramowania (np. serwera Apache).
Napisałem serwer parametrów, stanowiący łącznik między systemem SCADA a moim systemem wizualizacji.
Zaprojektowałem zestaw rozszerzeń do języka SVG oraz szablony przekształcające te dokumenty do kilku zadanych postaci wyjściowych.
Dodałem do programu Sodipodi edytor XML, co pozwala na wykorzystanie go w roli edytora schematów.
Stworzyłem konfigurację dla serwera Apache Cocoon, dzięki czemu może on pełnić rolę procesora dokumentów.
Wykonałem własną implementację procesora dokumentów, zachowując zgodność struktury serwisu i konfiguracji z Cocoonem.
Wybrałem dla systemu odpowiednie aplikacje klienckie -- wtyczkę Adobe SVG Viewer oraz przeglądarkę Batik 1.5.
Wykonałem przykładowe wdrożenia -- jedno na serwerze firmy Praterm w Warszawie, a drugie w Przedsiębiorstwie Energetyki Cieplnej w Bytowie.

Podsumowując wykonaną implementację należy zastanowić się, na ile spełnia ona zaprezentowane w rozdziale 2 wymagania:

Założenia funkcjonalne -- zakładana funkcjonalność systemu została w pełni osiągnięta. Wykonane wdrożenie z powodu braku zainteresowania klientów objęło jednak tylko wizualizację procesu, a nie możliwość zdalnego sterowania.
Możliwość dopasowania do istniejących rozwiązań -- system bez problemu współpracuje z systemem SZARP, nie wymagając zmian w jego konfiguracji (a jedynie dodania kilku opcji do plików konfiguracyjnych). Trudno natomiast powiedzieć, czy równie prosta byłaby integracja z innym systemem SCADA, choć podatna na modyfikację architektura serwera parametrów oraz pełna niezależność pozostałych elementów systemu od jego implementacji dają taką nadzieję.
Rozproszenie instalacji, źródeł danych i klientów -- potencjalnie każdy z elementów systemu może działać na innej maszynie. Do konkretnego miejsca przypisany jest jedynie serwer parametrów, który komunikuje się z systemem SZARP przy użyciu pamięci dzielonej. Jednak doświadczenia z wykonanymi wdrożeniami sugerują, że przy powszechnych w Polsce wolnych łączach należałoby sytuować procesor dokumentów w tej samej sieci lokalnej, co serwer parametrów.

Natomiast powiązanie nazwy parametru z adresem IP (lub nazwą) udostępniającego go serwera parametrów zapewnia niezależność schematów od miejsca instalacji i uzyskanie globalnej przestrzeni nazw parametrów.
Dostęp przez Internet -- dostęp z poziomu przeglądarki WWW jest podstawowym i jedynym sposobem korzystania z systemu. Problemem są tylko błędy w generowaniu grafiki bitmapowej dla użytkowników nie dysponujących przeglądarką SVG (nie występują one co prawda przy użyciu jako procesora dokumentów serwera Apache Cocoon).
Niezależność od platformy sprzętowej i programowej po stronie klienta -- jest to zapewnione przez dostęp z poziomu przeglądarki WWW. Także specjalizowana przeglądarka Batik, dzięki temu że jest napisana w Javie, jest niezależna od systemu operacyjnego.
Stabilność i niezawodność -- dotychczas wykonane instalacje pracowały bez przerw przez kilka tygodni. Ze względu na użycie do implementacji części systemu elementów języków C/C++ dość prawdopodobne jest ujawnienie się w przyszłości błędów zagrażających jego stabilności, które będą musiały zostać usunięte. Dotychczasowe doświadczenia wskazują jednak, że osiągnięty poziom stabilności i niezawodności jest już w tej chwili wystarczający.
Wydajność -- instalacja systemu w konfiguracji, gdzie serwer parametrów i procesor dokumentów są zlokalizowane w jednej sieci lokalnej zapewnia możliwość swobodnego korzystania z zasobów systemu także przez modem (między innymi dzięki kompresowaniu wysyłanych dokumentów SVG). W sieci lokalnej, a więc dla najważniejszych klientów, dotychczas wykonane instalacje pozwalają na stwierdzenie, że parametry odświeżane są na bieżąco. Najbardziej obciążającym elementem systemu jest wykorzystanie napisanej w Javie przeglądarki Batik oraz rasteryzacja SVG. Dla współczesnych komputerów nie powinno to jednak stanowić żadnego problemu -- do takich wniosków upoważniają mnie doświadczenia z kilkoma dobieranymi dość przypadkowo konfiguracjami sprzętowymi. Ponieważ wymagania dotyczące wydajności odnosiły się do wyłącznie do poziomu komfortu użytkowników, nie przeprowadzałem szczegółowych testów.
Bezpieczeństwo -- system zapewnia szyfrowaną transmisję i autoryzację użytkowników w przypadku krytycznego elementu, jakim jest zadawanie wartości parametrów. Autoryzacja i szyfrowanie także podczas oglądania wartości parametrów wymagałyby zmian w systemie. Efektem ubocznym zastosowania własnej biblioteki HTTP jest możliwość wydzielenia oddzielnych portów TCP/IP do obsługi każdego rodzaju transmisji (transfer wartości parametrów z serwera parametrów, zadawanie wartości parametrów, pobieranie danych z procesora dokumentów). Pozwala to na ograniczenie dostępności do danej usługi także na poziomie systemu operacyjnego.
Wymagania sprzętowe wobec serwera -- implementacja części serwerowej systemu w języku C++ i wykorzystanie szybkich bibliotek do obsługi XML i XSLT powodują, że wymagania sprzętowe wobec serwera są niewielkie. Najbardziej obciążającym elementem jest rasteryzacja SVG, ale ona także odbywała się bez problemów na każdym z testowanych komputerów.
Łatwość instalacji i konfiguracji -- udało mi się osiągnąć właściwie pełną niezależność konfiguracji od bazowego systemu typu SCADA. Przyjmowane domyślnie opcje konfiguracyjne pozwalają na poprawną pracę systemu¹. Wdrożenia systemu w ciepłowni w Bytowie dokonano zdalnie, przez Internet, co dowodzi łatwości tej procedury. Najbardziej kłopotliwym elementem może być konieczność uaktualnienia i instalacji dodatkowych bibliotek koniecznych do kompilacji oprogramowania. Działania takie nie są jednak konieczne w przypadku korzystania z najnowszych dystrybucji Linuksa.
Łatwość tworzenia schematów -- system jest wyposażony w narzędzie do wizualnego tworzenia schematów, pozwalające na bezproblemowe edytowanie części graficznej schematów. Możliwa jest także konwersja grafiki z innych formatów, oraz wykorzystanie innych programów graficznych. Niestety edycja elementów zależnych od parametrów wymaga ręcznego wpisywania wartości odpowiednich atrybutów w edytorze XML programu Sodipodi. Docelowo przydałaby się możliwość wybierania nazwy parametru i innych opcji spośród prezentowanych przez program możliwości.
Atrakcyjność wizualna -- wykorzystanie jako formatu zapisywania schematów SVG pozwala na osiąganie dowolnych efektów graficznych, ograniczanych tylko wyobraźnią i umiejętnościami twórcy schematu. W tej chwili dość ograniczone są natomiast możliwości tworzenia elementów zależnych od wartości schematów, choć przyjęta architektura (użycie szablonów XSLT) umożliwia łatwe rozbudowanie bazy dostępnych elementów, jeżeli pojawi się taka potrzeba.
Współpraca z innymi systemami zbierania danych -- podział systemu na niezależne warstwy oraz wykorzystanie wysokopoziomowego protokołu dostępu do parametrów, opartego na XML, umożliwiają implementację serwera parametrów korzystającego z innego źródła danych. Dodatkowym atutem jest tu brak jakiś szczególnych wymagań dotyczących postaci obecnych w systemie parametrów oraz zaszycie dużej części logiki systemu w łatwo modyfikowalnych szablonach XSLT.
Możliwość implementacji w ramach pracy magisterskiej -- wykorzystanie protokołu HTTP, języków XML i SVG, szablonów XSLT oraz przeglądarek WWW jako oprogramowania klienckiego pozwoliło na skorzystanie z dużej liczby gotowych rozwiązań i w rezultacie na stworzenie systemu w założonych ramach czasowych.

To krótkie podsumowanie pozwala stwierdzić, że udało się osiągnąć zdecydowaną większość z postawionych założeń. Najsłabszą częścią implementacji wydaje się edytor schematów, słabo zintegrowany z resztą systemu. Widoczne jest to zwłaszcza w porównaniu z innym popularnym na polskim rynku oprogramowaniem do wizualizacji, np. Wonderware InTouch firmy Wonderware. W pakiecie tym, pracującym pod kontrolą systemów Windows, środowisko tworzenia aplikacji (schematów) jest ściśle zintegrowane z oprogramowaniem wizualizacyjnym. Dużo szerszy jest także zestaw dostępnych zależności między tworzonym schematem a wizualizowanym i kontrolowanym procesem [2]. Z drugiej strony przynajmniej potencjalne możliwości graficzne mojego systemu przewyższają większość komercyjnych systemów. Służący tu za przykład Wonderware nie oferuje także takiej elastyczności w możliwych modyfikacjach, częściowo zapewne ze względów marketingowych (za większe możliwości klienci powinni więcej zapłacić, a nie samodzielnie grzebać w systemie). Mój system wyróżnia się także bardzo dobrym przystosowaniem do współpracy z siecią Internet. W systemach konkurencyjnych zwykle moduł serwera HTTP jest opcjonalny, dodatkowy i nie zawsze oferuje klientom korzystającym z przeglądarek pełną funkcjonalność. Z drugiej strony użycie specjalizowanych aplikacji klienckich pozwala na zapewnienie wielu cech, których nie można uzyskać w moim systemie, np. zagwarantowanie zadanego czasu reakcji czy też powiadamianie o zdarzeniach i inicjowanie transmisji danych przez serwer, bez konieczności odpytywania go przez aplikację kliencką.

Trudno przypuszczać, żeby mój system mogło konkurować z oprogramowaniem sprzedawanym ,,z półki''. Natomiast instalowany jako część systemu SZARP, w ramach kompleksowej modernizacji ciepłowni, może udostępniać użytkownikom funkcjonalność porównywalną z produktami konkurencyjnymi. Poza tym możliwości systemu powinny wzrastać wraz z upowszechnianiem się technologii XML, a w szczególności wraz z rozwojem implementacji SVG, szczególnie przeglądarek pozwalających na integrację w jednym dokumencie danych różnych typów.

Zamierzam udostępnić publicznie źródła systemu (łącznie z niezbędnymi fragmentami bibliotek systemu SZARP). Według moich informacji byłby to pierwszy dostępny darmowo system wizualizacji procesu technologicznego. Oczywiście zastosowanie go poza systemem SZARP wymaga wykonania odpowiedniej implementacji serwera parametrów.

Dla samego serwera parametrów przewidziane jest także ważne miejsce w rozwoju systemu SZARP. Wykorzystanie go jako warstwy pośredniczącej między częścią zależną od sprzętu a aplikacjami interfesju użytkownika, pozwoli na uporządkowanie struktury systemu, łatwiejsze tworzenie nowych aplikacji oraz pokonanie wielu ograniczeń obecnej wersji systemu (głównie dzięki stworzeniu globalnej przestrzeni nazw parametrów).

Wykorzystanie technologii XML, będących podstawą wykonanej implementacji, było ciekawym doświadczeniem także z tego względu, że XML (wywodzący się przecież z języka SGML²) jest jednak zorientowany na zastosowania tekstowe. Tymczasem w moim projekcie został użyty do prezentacji danych binarnych (wartości parametrów) w postaci graficznej. I okazało się, że w tej roli sprawdził się całkiem dobrze.

Za najważniejsze osiągnięcie pracy uważam stworzenie funkcjonującego systemu realizującego zadaną funkcjonalność, co potwierdzone zostało udanym wdrożeniem, a także wykorzystanie technologii zapewniających otwartość systemu na nowe rozwiązania, związane z dynamicznie rozwijającymi się zastosowaniami języka XML.

1: Konieczne jest tylko ustawienie w pliku konfiguracyjnym systemu SZARP ścieżki do pliku z konfiguracją procesora dokumentów.
2: Standard Generalized Markup Language -- standard zapisu dokumentów tekstowych zatwierdzony przez ISO.