JHAP Janusz Hajda - Automatyka Przemysłowa ul. Klasztorna 5, 41-922 Radzionków tel.0602 578 549, tel./fax.(032) 389-91-04 email: j.hajda@wp.pl, jhap@jhap.pl Nowoczesne systemy SCADA z bezpośrednim dostępem przez Internet. Tworzenie aplikacji. Janusz HAJDA Grzegorz ZIELIŃSKI Wprowadzenie W niniejszej publikacji omówione zostaną niektóre aspekty tworzenia aplikacji SCADA dla modułu TSX ETY510 1 sterownika Premium firmy Schneider Electric, z wykorzystaniem nowoczesnej biblioteki NFC SCADA Library. Biblioteka ta jest jednym z pierwszych produktów z logo Intechion oferowanych przez firmę JHAP. Poruszone zostaną również kwestie bezpieczeństwa, oraz pożądane kierunki rozwoju. Nowoczesne systemy SCADA, wykorzystujące moduł serwera WWW sterownika PLC do stworzenia łatwo dostępnej, prostej w obsłudze, nie wymagającej instalacji aplikacji SCADA, są coraz bardziej powszechne. Aplikacje takie mogą być dostępne publicznie, a jednocześnie można bardzo dokładnie dopasowywać profile użytkowników, ze szczególnym uwzględnieniem uprawnień. Także proces tworzenia i wdrażania takiej aplikacji jest znacząco krótszy i tańszy w porównaniu z klasycznymi aplikacjami SCADA. Dodatkowe informacje można uzyskać pod adresami zamieszczonymi na końcu tej publikacji. Rysunek 1 - sterowniki PLC z serwerami WWW w sieci ETHERNET Przedstawienie modułu serwera WWW sterownika Premium oraz porównanie dostępnych bibliotek zostało przedstawione m.in w publikacji zamieszczonej w miesięczniku PAK ze stycznia 2004. 1 Te same rozwiązania mogą być stosowane w modułach TSX ETZ 510 sterownika Micro oraz 140 NOE 771 sterownika Quantum
Przykładowy aplet Tworzenie aplikacji najlepiej omówić na przykładzie umieszczania i konfigurowania pojedynczego apletu. Apletem tym będzie VerticalIndicatorPanelApplet (patrz rysunki). Umieszczenie apletu na stronie w najprostszym przypadku sprowadza się do wstawienia tagu <applet> z odpowiednimi parametrami, określającego nazwę apletu czy ścieżkę do archiwów z wykorzystywanymi klasami. W omawianym przypadku będzie to tag postaci: <applet name="firstpanelapplet" codebase="/classes" code="com.intechion.applets.extra.verticalindicatorpanelapplet.class" archive="nfclibdemo.jar"> </applet> Parametr name określa nazwę apletu, która musi być unikalna w zakresie danej strony WWW, parametr codebase określa ścieżkę (w notacji UNIX'owej) do archiwów z apletami, parametr code określa kanoniczną (pełną) nazwę apletu, natomiast parametr archive zawiera nazwy wszystkich archiwów *.jar zawierających wykorzystywane przez aplet klasy. Większość apletów użytkowych korzysta jedynie z klas zawartych w głównym archiwum biblioteki (NFCLib.jar lub NFCLibDemo.jar w zależności od wersji), natomiast wszystkie aplety systemowe korzystają z klas zawartych w osobnych archiwach taki podział pozwala na łatwe uaktualnianie aplikacji i dopasowywanie zestawu apletów do zadania (problematyka ta wykracza poza temat niniejszej publikacji i zostanie omówiona osobno). Należy zauważyć, że w powyższym przykładzie nie określono żadnych parametrów specyficznych dla apletu. Przede wszystkim nie określono jego rozmiaru, stylu graficznego, skali, kolorów... Nie określono również adresu ani typu zmiennej monitorowanej. W tym stanie aplet nie zgłosi żadnej zmiennej do monitorowania, użyje domyślnych parametrów wyglądu, a jego wielkość zostanie określona przez przeglądarkę (np. w IE będzie to 192x192 piksele). Dostrajanie apletu Aplet NFC SCADA Library można dostrajać z wykorzystaniem prekonfiguracji, postkonfiguracji lub obu tych technik. Prekonfiguracja polega na wstawieniu odpowiednich tagów <param> pomiędzy znaczniki tagu <applet>. Dla przykładowego apletu mogłoby to wyglądać następująco: <applet name="firstpanelapplet" codebase="/classes" code="com.intechion.applets.extra.verticalindicatorpanelapplet.class" archive="nfclibdemo.jar"> <param name="style" value="system"> <param name="scaletype" value="eu_engineering"> <param name="eutoplimit" value="1000"> <param name="eubottomlimit" value="-1000"> <param name="plctoplimit" value="100"> <param name="plcbottomlimit" value="-100"> <param name="plcvalue" value="54"> <param name="address" value="%mw1"> <param name="datatype" value="int"> </applet>
W porównaniu z wartościami domyślnymi, styl apletu zostanie dopasowany do systemu operacyjnego, skala będzie miała zakres od -1000 do 1000 i notację inżynieryjną (czyli od -10E02 do 10E02), natomiast wartość pobierana z PLC będzie liczbą typu integer odczytaną spod adresu %MW1, przyjmującą wartości od -100 do 100. Aplet automatycznie dokona przeliczenia tak, aby granice zakresów pokrywały się, dzięki czemu pobrana z PLC wartość np. 70 będzie odpowiadała wartości 7E02 na skali apletu. Dodatkowo parametr plcvalue określa domyślną wartość, wyświetlaną zanim zostanie nawiązana komunikacja ze sterownikiem i aplet zacznie otrzymywać rzeczywiste wartości z PLC. Natomiast poniższy przykład: <applet name="firstpanelapplet" codebase="/classes" code="com.intechion.applets.extra.verticalindicatorpanelapplet.class" archive="nfclibdemo.jar"> <param name="style" value="crossplatform"> <param name="scalepos" value="left"> <param name="scaletype" value="percent"> <param name="eutoplimit" value="1000"> <param name="eubottomlimit" value="-1000"> <param name="plctoplimit" value="100"> <param name="plcbottomlimit" value="-100"> <param name="plcvalue" value="54"> <param name="address" value="%mw1"> <param name="datatype" value="int"> <param name="normalcolor" value="#ffff00"> </applet> w porównaniu z poprzednim ustawi styl apletu na niezależny od systemu (jest to ustawienie domyślne), umieści skalę po lewej stronie, podziałka będzie procentowa, od 0% do 100%, co przy zachowaniu zakresu po stronie PLC od -100 do 100 spowoduje przeliczenie przykładowej wartości PLC równej 54 na wartość 77% (dla skali procentowej zachowane z poprzedniego przykładu parametry eutoplimit i eubottomlimit nie mają znaczenia). Dodatkowo kolor wypełnienia zostanie zmieniony na żółty. W analogiczny sposób mogą być definiowane poziomy alarmowe i poziomy ostrzeżeń (niezależnie górne i dolne) oraz ich kolory (domyślnie czerwony dla alarmu, żółty dla ostrzeżenia, zielony dla stanu normalnego). Rysunek 2 - aplet VerticalIndicatorPanel - od lewej: wartości domyślne oraz dwa przykłady prekonfiguracji
Postkonfiguracja jest znacznie wygodniejszym sposobem dostrajania apletu, gdyż korzysta z wizualnego narzędzia apletu ConfManager. Korzystanie z ConfManager'a wymaga umieszczenia odpowiednio sparametryzowanego tagu <script> przed tagiem apletu. Ustawienia uzyskane w procesie postkonfiguracji są nadrzędne w stosunku do ustawień prekonfigurowanych, przy czym mogą je wykorzystywać jako wartości początkowe. Rysunek 3 - postkonfiguracja (przykład 1 analogicznie jak dla prekonfiguracji) Rysunek 4 - postkonfiguracja (przykład 2 analogicznie jak dla prekonfiguracji)
Rysunek 5 - postkonfiguracja (przykład rozbudowanego okna edycji parametru) Komunikacja Między sterownikiem a każdym z apletów użytkowych musi istnieć jedno- lub dwukierunkowa (w zależności od apletu) wymiana informacji. Niektóre biblioteki (m.in. w niektórych przypadkach biblioteka FactoryCast) zezwalają na samodzielną komunikację aplet sterownik. Jest to o tyle niepożądane, że zachęca do projektowania bardzo nieefektywnych aplikacji nierzadkie są przypadki, kiedy dwa lub więcej apletów monitoruje jedną zmienną (np. wskaźnik wychyłowy i wskaźnik cyfrowy), jeśli każdy z nich komunikuje się ze sterownikiem samodzielnie, prowadzi to do znaczącego wzrostu ruchu na łączach. NFC SCADA Library nie zezwala na samodzielną komunikację każdy aplet użytkowy zgodny ze specyfikacją biblioteki wymaga pośrednictwa systemowego apletu CommManager. Aplet ten jest umieszczany jednokrotnie na każdej stronie stanowiącej autonomiczny fragment aplikacji. Podczas inicjowania transmisji aplet ten odpytuje poszczególne aplety na stronie, pobierając od nich żądania monitorowania i/lub zapisu określonych typów zmiennych pod określonymi adresami na podstawie ich analizy tworzona jest zoptymalizowana tablica zapytań. Następnie tworzy jedno połączenie ze sterownikiem, które jest wykorzystywane do monitorowania wszystkich zgłoszonych zmiennych, przy czym każda unikalna para adres/typ jest sprawdzana jeden raz, po czym o wartości zmiennej powiadamiane są wszystkie aplety które zgłosiły żądanie jej monitorowania. Istotnym aspektem jest fakt, iż transmisja nie startuje natychmiast po załadowaniu strony. Uruchomienie nawet podglądu wymaga zalogowania się użytkownika. Daje to pełniejszą kontrolę nad funkcjonowaniem aplikacji.
Kwestie bezpieczeństwa W zdalnie dostępnych aplikacjach SCADA bezpieczeństwo jest jednym z najważniejszych aspektów. Biblioteka NFC SCADA Library zawiera specjalny aplet AuthManager jeden z trzech apletów systemowych, wymaganych na każdej stronie zawierającej autonomiczny fragment aplikacji. Dostarcza on przede wszystkim informacji kluczowych dla działania pośredniczącego w transmisji apletu CommManager. Podczas przetwarzania przez CommManager'a otrzymanych od apletów użytkowych żądań monitorowania i/lub zapisu określonych zmiennych PLC, każde żądanie jest analizowane z wykorzystaniem reguł autoryzacyjnych dostarczonych przez moduł AuthManager. Wynikiem analizy jest przyjęcie lub odrzucenie żądania. W przypadku żądań zapisu, dodatkową, braną pod uwagę regułą, jest pobierana ze sterownika definicja obszarów oraz pojedynczych adresów dozwolonych do zapisu. Widać tu znaczącą różnicę w porównaniu z innymi bibliotekami (np. FactoryCast), gdzie kontrola zezwolenia na zapis należy do samego apletu użytkowego, tak że jest możliwe zapisywanie zmiennych oznaczonych jako tylko do odczytu, co stanowi rażące naruszenie zasad bezpieczeństwa i zagraża stabilności programu sterownika. Podstawowy system autoryzacji zaimplementowany w bibliotece NFC SCADA Library stanowi kolekcję zdefiniowanych użytkowników, wraz z zestawem szczegółowych uprawnień, indywidualnych dla każdego użytkownika. W niektórych przypadkach można zastosować dodatkową Rysunek 6 - aplet AuthManager okno logowania autoryzację opartą o inteligentne karty chipowe. Użytkownicy system uprawnień Stopień złożoności systemu uprawnień dostępnego w bibliotece NFC SCADA Library jest zmienny, dostosowywany do potrzeb określonego klienta. Jego rozpiętość waha się od zestawu kilku podstawowych uprawnień (monitorowanie, zapis, zmiana konfiguracji) do rozbudowanych zestawów uprawnień pozwalających na indywidualne traktowanie poszczególnych adresów, grup adresów, określonych apletów, grup apletów itp. Istnieje możliwość zdefiniowania pewnych standardowych profili użytkowników, co pozwala skrócić czas tworzenia profilu użytkownika nie pozbawiając jednocześnie administratora aplikacji możliwości dokładnego dopasowania zakresu przyznawanych uprawnień. Należy wyraźnie podkreślić odejście od klasycznego, hierarchicznego systemu autoryzacji znacznie mniej elastycznego i efektywnego.
Rysunek 7 - aplikacja zarządzania listą uprawnień Smartcards pewność zabezpieczeń W niektórych przypadkach nawet rozbudowany system uprawnień będzie zbyt słabym zabezpieczeniem, gdyż jego słabym punktem jest login i hasło tak zwany czynnik ludzki. Ludzie najczęściej mają problemy z wymyśleniem i zapamiętaniem odpowiednio złożonego hasła, stąd w większości przypadków jest ono trywialne imię żony, data urodzin, imię kota... Dlatego stosuje się generatory haseł lub wymusza się odpowiedni stopień złożoności hasła niestety, takie hasło zostaje najczęściej zapisane na przysłowiowej kartce przyczepionej do monitora. Alternatywę stanowią systemy autoryzacji nie wymagające pamiętania loginu i hasła. Przykładem może być system kart chipowych, znanych pod nazwą smartcards. Nie może być on oczywiście stosowany zawsze i wszędzie w pewnym stopniu ogranicza on jedną z istotniejszych zalet omawianego typu aplikacji SCADA, jaką jest możliwość dostępu z dowolnego komputera wyposażonego w przeglądarkę WWW z obsługą Javy. Teraz dochodzi jeszcze wymóg podłączenia do komputera czytnika kart chipowych. Jednak w miarę jak ta technologia zdobywa popularność, coraz więcej komputerów (a zwłaszcza laptopów) ma standardowo wbudowany taki czytnik. Dla aplikacji wykorzystujących bibliotekę NFC SCADA Library proponowane jest rozwiązanie oparte na kartach procesorowych, zgodnych ze standardami ISO/IEC 7816-3 i 7816-4, wyposażonych w 2 do 30 kb pamięci EEPROM oraz w procesor z wbudowanym sprzętowym wsparciem dla algorytmów szyfrowania DES, AES, RSA czy mniej znanych
algorytmów eliptycznych. Duża pamięć pozwala na przechowywanie sporej ilości danych (uprawnienia, klucze, kody...) a algorytmy szyfrowania zapewniają bezpieczną transmisję przez Internet. W zależności od potrzeb można całkowicie zastąpić klasyczne logowanie kartami chipowymi, lub też (aby nie tracić mobilności) wymagać logowania kartą jedynie w szczególnych przypadkach, np. dla definiowania użytkowników i ich uprawnień. Możliwe jest też np. wydzielenie modułu definiowania użytkowników jako stacjonarnej aplikacji, która wygenerowaną listę szyfruje kluczem prywatnym (przy pomocy karty chipowej) po czym wysyła ją do sterownika. Aplikacja mobilna posiada jedynie klucz publiczny pozwalający na odczyt uprawnień, ale już nie na ich modyfikację. Użytkownicy logują się klasycznie, przy użyciu loginu i hasła, ale odkrycie haseł nie pozwala na zmianę uprawnień użytkownika czy wprowadzenie własnego. Przyszłość urządzenia mobilne itp. Pakiet NFC SCADA Library jest stale rozwijany. Planowane kierunki rozwoju to m.in. lekka wersja przystosowana do pracy na małych urządzeniach mobilnych (np. telefony GSM z technologią Java) oraz szyfrowanie transmisji, przede wszystkim jednak opracowanie jeszcze wydajniejszych bibliotek komunikacyjnych. Ten ostatni kierunek jest aktualnie głównym tematem prac, wyniki wstępnych prac są niezwykle obiecujące. Cały czas powstają także nowe aplety wizualizacyjne, czyniąc bibliotekę NFC SCADA Library coraz lepszym i wydajniejszym narzędziem do projektowania zdalnie dostępnych aplikacji SCADA. Podsumowanie Pakiet NFC SCADA Library bazuje na najnowszej dostępnej wersji języka Java i jest stale aktualizowany. Jest wygodny i łatwy w użyciu, zarówno dla projektanta jak i dla końcowego użytkownika. Zapewnia wysoki stopień bezpieczeństwa, pozwalając na użycie stworzonych aplikacji zarówno w intra- jak i w internecie. Zastosowany elastyczny model autoryzacji daje znacznie większą kontrolę nad uprawnieniami użytkowników niż klasyczny model hierarchiczny. Możliwość zastąpienia lub uzupełnienia klasycznego logowania autoryzacją z użyciem kart chipowych (smartcards) czy identyfikatorów bezprzewodowych (RFID) podnosi jeszcze standard bezpieczeństwa. Planowane kierunki rozwoju, jak wsparcie dla urządzeń mobilnych (PDA, telefony z technologią Java), wsparcie dla OPC czy szyfrowanie transmisji czynią NFC SCADA Library pakietem na miarę XXI wieku. Demonstracja pakietu NFC SCADA Library oraz dodatkowe informacje o produkcie będą czasowo dostępne pod adresem http://nfc.intechion.com. Dodatkowo odpowiedzi na pytania będzie można uzyskać poprzez e-mail: nfc@intechion.com / nfc@intechion.pl lub j.hajda@wp.pl / jhap@jhap.pl