Informator_techniczny_Wonderware_011.pdf

INFORMATOR TECHNICZNY WONDERWARE

Informator Techniczny nr 11

11-05-1999

IndustrialSQL Server

Dla kogo i w jakich warunkach

Wstęp

Od pewnego czasu podczas rozmów z klientami na ten temat oprogramowania IndustrialSQL bardzo

często padają pytania: „Dlaczego powinienem wykorzystać IndustrialSQL Server? Czym przewyższa on

inne rozwiązania? Czy zakup tego oprogramowania jest dla firmy opłacalny? W jakim czasie ta

inwestycja może się spłacić?”.

Są to naturalne pytania zadawane przez ludzi zajmujących kierownicze stanowiska w zakładach

przemysłowych. Wdrożenie systemu informatycznego do zarządzania procesem jest z pewnością

bardzo złożonym problemem, pociągającym za sobą często niemałe koszty. Osoba odpowiedzialna za

inwestycję musi być przekonana, że zwróci się ona w odpowiednim czasie. Czy IndustrialSQL Server to

gwarantuje?

W poniższych rozważaniach przyjęto założenie, że zostały już zdefiniowane potrzeby przedsiębiorstwa.

Jest bowiem oczywiste, że dobór narzędzia jest uzależniony od celu, który powinien zostać osiągnięty.

Kluczowym momentem jest więc określenie zadań stawianych przed systemem zbierania danych.

Należy precyzyjnie określić:

• jakie dane powinny być zapisywane w bazie danych,

• z jaką częstotliwością,

• w jakim celu.

Dane zbierane przez nasz system służą zwykle do uzyskania informacji, jak przebiegał proces, gdzie

pojawiały się nieprawidłowości i czym były spowodowane, jaka była efektywność na poszczególnych

jego etapach, i wielu innych. Przekłada się to na szereg bardziej szczegółowych pytań, na które

odpowiedzi pragną poznać ludzie pracujący na rozmaitych stanowiskach, od technologów, przez

specjalistów od zarządzania jakością, po kadrę kierowniczą, zainteresowaną finansowymi aspektami

produkcji. System zbierania danych musi dostarczać wszelkich odpowiedzi, na które istnieje

zapotrzebowanie, zatem musi gromadzić wszelkie niezbędne w tym celu dane.

Spróbujemy rozważyć różne sytuacje, które mogą pojawić się podczas projektowania naszego systemu

informatycznego. Dla potrzeb dalszych rozważań przyjmijmy trzy stopnie złożoności takiego systemu,

aby pokazać możliwe sposoby rozwiązania tego zagadnienia. Oznaczmy je literami od A do C. Jest to

oczywiście duże uproszczenie, ale pozwala to na czytelne porównanie różnych wariantów budowanego

systemu.

System duży. W fabryce zbieraniu podlega 7500 lub więcej zmiennych. Zdecydowana większość jest

zapisywana co 1 sekundę, a w przypadku sporej części zapisywane są informacje o każdej zmianie ich

wartości, która to zmiana następuje co najmniej kilkanaście razy na sekundę.

System średni. W fabryce zbieraniu podlega kilkaset zmiennych. Większość z nich zmienia swą wartość

co kilkanaście sekund lub rzadziej.

System mały. W fabryce zbieranych jest kilkanaście do kilkudziesięciu zmiennych, w większości

zmieniających wartość co kilkadziesiąt sekund.

ASTOR Sp. z o.o.

Dział Oprogramowania Przemysłowego

ul. Smoleńsk 29, 31-112 Kraków

e-mail: wonderware1@astor.com.pl

http://www.astor.com.pl

tel.: 012 428-63-30

fax: 012 428-63-09

Czy dla każdego z tych systemów istnieją alternatywy dla IndustrialSQL Server’a? W naturalny sposób

pojawiają się cztery propozycje:

• Zastosowanie innego przemysłowego serwera baz danych.

• Zastosowanie klasycznego serwera baz danych (np. Microsoft SQL Server).

• Zbieranie danych za pomocą oprogramowania wizualizacyjnego i analizowanie ich w biurowym

arkuszu kalkulacyjnym lub biurowej bazie danych.

• Stworzenie od podstaw własnego, kompletnego oprogramowania do akwizycji i udostępniania

danych.

Na wstępie należy odrzucić rozwiązanie pierwsze. Już bowiem pobieżna analiza rynku oprogramowania

dla przemysłu pokazuje, że nie istnieją w tej chwili żadne inne przemysłowe bazy danych w rozumieniu

definiowanym przez IndustrialSQL Server. Podobnie szybko należy skreślić propozycję czwartą. Nikt nie

będzie chciał decydować się na poniesienie ogromnego trudu stworzenia własnego systemu w

momencie, gdy istnieją sprawdzone, kompleksowe rozwiązania, na dodatek cechujące się otwartością i

możliwościami rozbudowy. Próba pójścia w tym kierunku musi spowodować wielokrotne wydłużenie

czasu wdrożenia systemu oraz nawet kilkunastokrotnie wyższe koszty (oczywiście jeżeli chcemy

uzyskać rozwiązanie efektywne i niezawodne).

Pozostają więc dwie możliwości. Przyjrzyjmy się im teraz bliżej.

IndustrialSQL Server a klasyczny serwer baz danych

IndustrialSQL Server zawiera w sobie pełną wersję serwera relacyjnych baz danych Microsoft SQL

Server. W związku z tym może paść pytanie: skoro IndustrialSQL Server i tak jest oparty na serwerze

Microsoft’u, to czy nie wystarczy zastosować właśnie ten ostatni?

Argumenty przeciwko takiemu rozwiązaniu zostały przedstawiane na łamach Biuletynu Automatyki firmy

Astor oraz w ramach Informatora Technicznego nr 8. Zbierzmy je jednak ponownie i przypomnijmy:

• Fabryka A potrafi wygenerować w ciągu miesiąca 20 miliardów wierszy bazy danych. Tyle

właśnie ma największy system relacyjnych baz danych, jaki funkcjonuje na świecie. Łatwo sobie

wyobrazić, jak potężny (i kosztowny) jest system komputerowy, na którym serwer jest

zainstalowany. Tymczasem w fabryce chodzi zwykle o to, aby dane były przechowywane przez

znacznie dłuższy czas, niż miesiąc, a ponadto często istnieje potrzeba analizowania tych danych

w przedziale np. roku lub nawet kilku lat. Należy przyjąć, że taka fabryka potrzebuje około 1

terabajta przestrzeni dyskowej, aby mogła pomieścić te dane. W przypadku fabryki B liczby te są

mniejsze, ale również przekraczają zdolności klasycznego serwera SQL.

• Dane z procesu napływają na ogół bardzo szybko. Nawet jeśli w naszej fabryce A dane

zmieniałyby się rzadziej niż co sekundę, przy tak dużej ich ilości serwer mógłby nie być w stanie

ich wszystkich zapisać. A co wówczas, gdy spora część zmiennych zmienia się co np. 1 dziesiątą

sekundy lub rzadziej? Klasyczny serwer bazy danych zostałby wtedy skazany na ciężkie katusze.

Chociaż trudno precyzyjnie ustalić granice wydajności takiego serwera, jest pewne, że i

wymagania fabryki B znacznie je przekraczają.

• W standardowych serwerach nie ma możliwości wybierania i analizy danych przy określonych

parametrach czasu. Nie można np. pobierać danych z określoną rozdzielczością czasową lub

zapytywać o średnie wartości pewnych parametrów w zadanym przedziale czasowym.

IndustrialSQL Server nie posiada powyższych ograniczeń. Zwiększoną pojemność bazy gwarantuje

bardzo wydajny mechanizm kompresji. Dane mogą być zbierane bardzo szybko ze względu za

zaimplementowanie specjalizowanych modułów archiwizujących, dostosowanych do realiów

przemysłowych. Rozszerzenie języka SQL o funkcje czasowe znacznie zwiększa możliwości wybierania

i analizy danych. Każda zmiana wartości zmiennej zostaje zapisana w bazie razem z tzw. metką

czasową, która jednoznacznie informuje, w której chwili czasu zmiana miała miejsce. Informacja ta jest

później wykorzystywana m.in. do wyszukiwania danych w bazie. Jakie jest podstawowe praktyczne

znaczenie tego faktu?

Niemal każde pytanie odnoszące się do historii przebiegu procesu produkcyjnego dotyczy konkretnego

przedziału czasu. Pytamy: „Jaka była średnia wartość zmiennej w danym okresie czasu ?”, „Jaka była

maksymalna wartość zmiennej w ciągu ostatniej doby ?”, „Ile materiału zużyto w ciągu danego

miesiąca ?”, „Jakie były czasy technologiczne procesu na poszczególnych zmianach w ciągu

ostatniego tygodnia ?”. Ponadto czasami zależności czasowe, o które pytamy są bardziej złożone:

„Jakie były uzyskiwane w ciągu ostatniego roku parametry produktu, jeśli temperatura w zbiorniku

półproduktu w dniu poprzedzającym jego wyprodukowanie osiągnęła zadaną wartość?”, lub „Jakie było

ciśnienie pary wodnej w instalacji dwa dni przed wyprodukowaniem produktu, którego parametry

przekraczały dopuszczalną normę o 10%?”. Czy zastanawiali się Państwo ile warte są odpowiedzi na

tego typu pytania w sensie oszczędności kosztów produkcji czy zwiększenia wydajności ? Albo jak długo

będzie zwracała się inwestycja przemysłowej bazy danych jeżeli pozwoli ona na łatwiejsze i szybsze

odpowiedzi na tego typu pytania ? W wielu polskich zakładach czas przygotowania raportu mierzony jest

w dniach a nawet tygodniach. O ile bardziej efektywne byłoby zarządzanie zakładem gdyby raport

powstawał z opóźnieniem liczonym w minutach a co najwyżej w godzinach ?

Wracając do pytań - często również interesuje nas wybranie określonej liczby pomiarów z zadanego

okresu czasu, lub też narzucenie rozdzielczości czasowej, z jaką wybieramy dane. Wszystkie powyższe

możliwości daje nam IndustrialSQL Server, natomiast w każdym innym rozwiązaniu są one praktycznie

niemożliwe do uzyskania. To samo dotyczy tzw. zapytań ciągłych, czyli zapytań typu: „Przedstawiaj co

10 sekund aktualną wartość zmiennej.” lub „Informuj o każdorazowym przekroczeniu przez temperaturę

określonej wartości, jeżeli jednocześnie poziom w zbiorniku przyjmuje wartość z dozwolonego

przedziału.”.

Czy wszystko, co napisałem powyżej, oznacza, że klasyczny serwer SQL w ogóle nie nadaje się do

zastosowań w przemyśle?

Ktoś może powiedzieć: „W moim zakładzie nie potrzebuję tak zaawansowanych rozwiązań. Potrzebuję

zbierać tylko kilkanaście zmiennych, które zmieniają się raz na kilka, nawet kilkanaście minut. Klasyczny

serwer SQL poradzi sobie z takim zadaniem bez problemu. Po co mi zatem IndustrialSQL Server?”.

Innymi słowy: co wtedy, gdy mamy do czynienia z fabryką C?

Z pozoru w przypadku fabryki C przewaga wydajności IndustrialSQL Server’a traci na znaczeniu. Ale

spróbujmy policzyć ile rekordów będą zajmować dane dotyczące 20 zmiennych zbieranych co 5 minut. Z

prostego rachunku wynika że będzie to ponad 170 tysięcy rekordów. Jest to już liczba przy której

wydajność klasycznego MS SQL Server’a jest istotnym i czasem trudnym zagadnieniem. Zaś w

przypadku IndustrialSQL Server’a obiekt wielkości 20 zmiennych zbieranych co 5 minut jest to bardzo

mały i łatwy do obsłużenia. Ponadto nadal zachowuje swoją aktualność wymieniony powyżej argument

trzeci. Pozostaje także jeszcze kwestia kosztów, w samej rzeczy niezwykle istotna. Porównajmy więc

ceny. Microsoft SQL Server w najprostszej wersji kosztuje około 1300 USD. Tymczasem IndustrialSQL

Server to w przypadku licencji 100 zmiennych koszt około 1600 USD. Jak widać – różnica nie jest zbyt

wielka. Zastosowanie Microsoft SQL Server’a nie pozwala na żadne istotne oszczędności. Powstaje

więc pytanie o celowość takiego rozwiązania. Za niewiele większą cenę otrzymujemy rozwiązanie o

nieporównanie większej funkcjonalności, otwartości i efektywności.

Tak więc klasyczny serwer SQL z pewnością nie jest alternatywą dla IndustrialSQL Server’a. Z listy

przedstawionej na wstępie pozostała nam jeszcze jedna propozycja do rozważenia.

IndustrialSQL Server a oprogramowanie biurowe

Inną alternatywą dla IndustrialSQL Server’a jest wykorzystanie mechanizmów zbierania danych

udostępnianych przez oprogramowanie wizualizacyjne, w połączeniu z biurowymi programami takimi, jak

arkusze kalkulacyjne i bazy danych typu Microsoft Access. Rozważmy zatem taką możliwość.

Na wstępie należy zauważyć, że w przypadku dużych systemów (fabryki A i B) rozważane rozwiązanie

jest rozwiązaniem bardzo złym, najczęściej w ogóle niemożliwym do zaimplementowania. Przyczyny są

takie same, jak wymienione uprzednio, podczas porównywania IndustrialSQL Server’a z klasycznym

serwerem SQL: ogromne zapotrzebowanie na przestrzeń dyskową i wydajność procesu akwizycji

danych, oraz duże trudności w pobieraniu i analizowaniu tych danych. Z zagadnieniem, z którym nie

radzi sobie konwencjonalny serwer SQL, na pewno nie poradzi sobie oprogramowanie biurowe

połączone z najlepszym nawet programem wizualizacyjnym.

Co jednak w przypadku systemu małego, a więc naszej fabryki C? Czy i w tym przypadku zastosowanie

IndustrialSQL Server’a jest celowe? Oprogramowanie InTouch jest przecież wyposażone w możliwość

logowania danych historycznych, które mogą być potem prezentowane w postaci wykresów (trendów).

Istnieje możliwość logowania ich bezpośrednio do dowolnej bazy danych, do której jest dostęp poprzez

standardowy interfejs ODBC. Dane te można również przenosić do arkusza kalkulacyjnego Microsoft

Excel w celu dalszej analizy. Możliwe jest wreszcie wykorzystanie modułu statystycznej kontroli procesu

SPC, będącego częścią oprogramowania InTouch, dającego rozbudowane możliwości analiz

statystycznych. W sumie daje to bardzo duże możliwości i, jak się wydaje, pozwala zakwestionować

sens użycia IndustrialSQL Server’a.

Niewątpliwie w przypadku niewielkich systemów można stworzyć system akwizycji i analizy danych bez

wykorzystania przemysłowej bazy firmy Wonderware. Można jednak zastanowić się, czy będzie to

rozwiązanie efektywne i niezawodne, przede wszystkim – czy spełni wszystkie zadania, jakie są przed

nim stawiane.

Pierwszą istotną przewagą IndustrialSQL Server’a jest jego niezawodność. Serwer powinien pracować

na wydzielonym komputerze, nie realizującym żadnych innych funkcji. Jeżeli w systemie zostanie

zastosowana wysokiej jakości sieć lokalna (tzn. oparta na najlepszych podzespołach i okablowaniu,

należycie chroniona przed uszkodzeniami mechanicznymi), a w szczególności – jeśli zaimplementujemy

system rezerwacji serwera (zastosowanie serwera rezerwowego zdolnego przejąć funkcję serwera

zasadniczego, zastosowanie macierzy dyskowych typu RAID), zapewnimy sobie bardzo wysoki poziom

niezawodności, niemożliwy do uzyskania w przypadku stosowania wyłącznie programu InTouch i

oprogramowania biurowego. Mamy wtedy gwarancję, że nie wystąpią żadne przerwy w zbieraniu

danych. Dodatkowo IndustrialSQL Server zapewnia bezpieczeństwo danych (dostępu do nich nie może

mieć nikt niepowołany).

Drugim istotnym argumentem przemawiającym za zastosowaniem produktu firmy Wonderware także w

naszej fabryce C jest jego otwartość i elastyczność. IndustrialSQL Server został tak zaprojektowany, że

wszelkie zmiany w systemie zbierania danych (utworzenie nowych raportów, zapytań, dodanie

dodatkowych zmiennych podlegających zbieraniu itp.) są łatwe i nie wymagają dużego nakładu pracy i

czasu.

Trzecim, być może najistotniejszym argumentem jest efektywność i wygoda pracy z IndustrialSQL

Server’em. Warto zauważyć, że praca z programem typu Excel przestaje być efektywna, jeśli

wykorzystywany arkusz zaczyna stawać się wyraźnie większy niż rozmiar ekranu. Wiele zadań, które

dzięki IndustrialSQL Server’owi można zautomatyzować (np. automatyczne tworzenie podsumowań za

zadany okres czasu, wszystkie funkcje udostępniane przez programy klienckie dostarczane wraz z

serwerem), w Excel’u trzeba realizować ręcznie.

Jeżeli niezbędne jest wybieranie danych spośród wszystkich zapisanych wartości, konieczne jest

wykorzystanie programu Microsoft Access i wprowadzanie wszystkich danych do jego bazy za

pośrednictwem modułu SQL Access zawartego w programie InTouch. Nawet jednak w takim przypadku

nie jest możliwe zadawanie zapytań powiązanych z czasem oraz zapytań ciągłych, dostępnych jedynie

w IndustrialSQL Server’ze. Jeżeli natomiast rezygnujemy z wykorzystania programu Microsoft Access,

konieczne jest stosowanie bardziej skomplikowanych zabiegów, aby wybierać dane z logu historycznego

InTouch’a wg określonych kryteriów (np. złożone skrypty Excel’a pisane w języku Visual Basic for

Applications). System staje się trudny w obsłudze i kłopotliwa staje się jego ewentualna rozbudowa.

Zupełnie inaczej przedstawia się jednak problem zastosowania Excel’a jako klienta IndustrialSQL

Server’a. Wraz z tym ostatnim dostarczany jest Industrial Workbook , dodatek do Excel’a ułatwiający

pobieranie danych z bazy danych w celu ich obróbki w arkuszu kalkulacyjnym. W takim przypadku Excel

może służyć do tworzenia raportów i podsumowań bazujących na odpowiednio wyselekcjonowanych i

przygotowanych danych.

Podsumowanie

Przyszła pora na podsumowanie naszych rozważań. IndustrialSQL Server posiada wiele cech

unikatowych – niespotykanych w żadnych innych rozwiązaniach. Należą do nich:

• zaawansowana technologia efektywnego i niezawodnego zbierania dużych ilości szybko

zmieniających się danych, połączona z wydajnym mechanizmem ich kompresji,

• rozbudowane funkcje wybierania i analizy danych – możliwość ich analizowania z

uwzględnieniem zależności czasowych,

• możliwość automatycznego tworzenia podsumowań,

• otwartość na rozbudowę i łączenie z innymi elementami systemu informatycznego,

• elastyczność i duża łatwość obsługi.

Cechy te powodują, że w przypadku systemów średnich i dużych nie istnieje żadne rozwiązanie

alternatywne dla IndustrialSQL Server’a, które pozwoliłoby na zrealizowanie tych samych funkcji. W

przypadku systemów małych możliwe są inne rozwiązania, które jednak nie zapewniają niezawodności,

efektywności i elastyczności gwarantowanej przez produkt firmy Wonderware. Biorąc pod uwagę poziom

cen poszczególnych licencji programu oraz stosunkowo niskie koszty wdrożenia (co wynika z łatwości

konfiguracji i obsługi serwera, oraz faktu, że opracowanie aplikacji nie wymaga dużych nakładów

czasowych ani specjalistycznej wiedzy) należy stwierdzić, że w przypadku konieczności

zaimplementowania systemu zbierania i analizy danych produkcyjnych zastosowanie IndustrialSQL

opłaca się, poza nielicznymi wyjątkowymi sytuacjami, niemal zawsze.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: