Artykuł w PAK - Pomiary, Automatyka, Kontrola (03/2004)

Transkrypt

Artykuł w PAK - Pomiary, Automatyka, Kontrola (03/2004)
HAP
J
Janusz Hajda - Automatyka Przemysłowa
ul. Klasztorna 5, 41-922 Radzionków
tel.0602 578 549, tel./fax.(032) 389-91-04
email: [email protected] , [email protected]
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 ETY5101 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:
[email protected] / [email protected]
lub
[email protected] / [email protected]

Podobne dokumenty