INFORMATOR TECHNICZNY WONDERWARE IndustrialSQL Server

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
tel.: 012 428-63-30
fax: 012 428-63-09
e-mail: [email protected]
http://www.astor.com.pl
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ą
2
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.
3
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
4
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.
5