Dla unikni¦cia niejednoznaczno±ci warto przytoczy¢ okre±lenia sze±ciu podstawowych terminów, które b¦d¡ stosowane w pracy. S¡ to: system lub ukªad sterowania automatycznego, sterowanie, regulacja, estymacja i predykcja.
System sterowania automatycznego oznacza ukªad sterowania zªo»ony z wielu obiektów sterowania i automatycznych urz¡dze« steruj¡cych, wzajemnie oddziaªuj¡cych na siebie [27]. Terminy system i ukªad b¦d¡ traktowane w pracy jako synonimy i stosowane zamiennie.
Sterowanie to dziaªanie na okre±lony ukªad, maj¡ce na celu zapewnienie jego zachowania si¦ w »¡-dany sposób [35, strona 18], [38, strona 71]. Regulacja za± to sterowanie w systemie zamkni¦tym, z p¦tl¡ sprz¦»enia zwrotnego [35, 38]. Znaczenie poj¦cia sterowanie jest ogólniejsze w stosunku do regulacji. Cho¢ w rozprawie rozpatrywane b¦d¡ gªównie ukªady regulacji (ze sprz¦»eniem zwrot-nym), nazywa¢ je b¦dziemy niekiedy ukªadami sterowania, gdy» w ±wietle powy»szych de nicji nie stanowi to bª¦du.
Terminy estymacja i predykcja de niowane s¡ najcz¦±ciej w kontek±cie probabilistycznym i stocha-stycznym [15, strony 797 i 801], [27]. W odniesieniu do procesów stochastycznych, predykcj¦ traktuje si¦ czasem jako szczególny przypadek estymacji [72, strona 146], [123, strona 82]. Obie nazwy by-waj¡ jednak stosowane równie» w przypadkach, gdy nie jest akcentowany losowy charakter zjawisk. W pracy [86, strona 89] terminem estymata stanu okre±lono wynik asymptotycznego odtwarzania stanu systemu dynamicznego przy pomocy obserwatora Luenbergera. Nie zakªadano tam wyst¦-powania zakªóce« sygnaªów ani niezgodno±ci modelu z obiektem, a jedynie przyj¦to, »e nie jest znany stan pocz¡tkowy obiektu. Z kolei w pracy [115, strony 114 i 115] autor pisze o predykowaniu (przewidywaniu, prognozowaniu) sygnaªu wyj±ciowego obiektu dynamicznego, równie» nie stawiaj¡c wymagania obecno±ci losowych zakªóce« czy niezgodno±ci modelu z obiektem.
W niniejszej pracy termin estymacja stanu stosowany b¦dzie mi¦dzy innymi w odniesieniu do asymp-totycznego odtwarzania stanu przy pomocy obserwatora Luenbergera oraz technik pokrewnych (patrz podrozdziaª III.2.2), zarówno w obecno±ci zakªóce«, jak i przy ich braku. Z kolei okre±le-nie predykcja (przewidywaokre±le-nie, prognozowaokre±le-nie) stanu u»yte zostaokre±le-nie w przypadku, gdy na podstawie znajomo±ci stanu x obiektu w chwili czasu t1 (i ewentualnie w chwilach wcze±niejszych), przewidy-wana jest warto±¢ stanu w chwili t2, pó¹niejszej w stosunku do t1 (t2 > t1). Tu równie» okre±lenie to odniesiemy zarówno do przypadku z zakªóceniami b¡d¹ niepewno±ci¡ modelu, jak i bez nich. Predykcja ma miejsce zarówno wówczas, gdy na podstawie tera¹niejszo±ci (i ewentualnie przeszªo±ci) prognozujemy przyszªo±¢, jak i w sytuacji, gdy na podstawie przeszªo±ci staramy si¦ przewidzie¢ nie-znan¡ tera¹niejszo±¢. W systemach rozproszonych ten ostatni przypadek zachodzi, gdy na podstawie danych pomiarowych opó¹nionych z powodu transmisji okre±lamy estymat¦ aktualnej warto±ci stanu systemu. Predykcj¦ nazywa¢ b¦dziemy niekiedy estymacj¡. Uzasadnienie takiego zamiennego u»ycia terminów mo»na znale¹¢ mi¦dzy innymi w pracy [110, strona 126], gdzie (dla systemów z czasem dyskretnym) jednokrokow¡ predykcj¦ nazywa si¦ estymacj¡ a priori.
Rozdziaª II
Stan wiedzy
Poniewa» na przestrzeni ostatnich kilkudziesi¦ciu lat rozproszone systemy sterowania cieszyªy si¦ (i wci¡» ciesz¡) rosn¡cym zainteresowaniem naukowców oraz in»ynierów, znaczny jest zasób dost¦p-nych publikacji traktuj¡cych na ich temat. Niniejszy rozdziaª stanowi przegl¡d literatury i prezentuje podstawowe trendy w interesuj¡cej dziedzinie. Z konieczno±ci nie jest on kompletny ani wyczerpu-j¡cy nie pozwala na to charakter i cel niniejszego opracowania. Zamiast tego Autor wybraª kilka przykªadów, które w jego subiektywnej ocenie s¡ najciekawsze, a zarazem najbardziej reprezenta-tywne dla poszczególnych kierunków bada« w domenie systemów rozproszonych.
Wymagane wªasno±ci rozproszonych ukªadów regulacji mo»na osi¡ga¢ na kilka sposobów, wymie-nionych w podrozdziale I.5. Trzy spo±ród podanych tam metod zostan¡ zilustrowane przykªadami zebranymi w nast¦pnych podrozdziaªach.
II.1 Doskonalenie metod transmisji w sieciach telekomunikacyjnych
Jeden ze sposobów poprawy jako±ci regulacji w systemach rozproszonych polega na mody kowaniu protokoªu transmisji b¡d¹ struktury i kon guracji sieci telekomunikacyjnej w taki sposób, by wpªyw jej obecno±ci na prac¦ ukªadu regulacji automatycznej byª jak najmniejszy. W podej±ciu tym stosuje si¦ w niezmienionej postaci standardowe algorytmy sterowania. W trzech kolejnych podrozdziaªach opisane s¡ przykªady u»ycia tej techniki w odniesieniu do sieci Ethernet, która z jednej strony zyskuje coraz wi¦ksz¡ popularno±¢ w automatyce, a z drugiej stwarza mo»liwo±ci znacz¡cej poprawy jako±ci sterowania po zastosowaniu omawianej metody.
II.1.1 RETHER Real-Time Ethernet
W pracy [125] opisano protokóª sieciowy RETHER (Real-Time Ethernet), który zapewnia deter-minizm przesªa« w sieci Ethernet. By go zastosowa¢, nale»y wyposa»y¢ wszystkie w¦zªy sieciowe wspóªpracuj¡ce z danym segmentem sieci w odpowiednie sterowniki programowe (driver). Nie jest natomiast potrzebna wymiana standardowych, sprz¦towych kart sieciowych. Dopóki »aden z w¦-zªów nie zgªasza potrzeby przesyªania danych w trybie czasu rzeczywistego, wszystkie w¦zªy re-alizuj¡ standardowy dla sieci Ethernet algorytm dost¦pu do medium CSMA/CD. Je±li natomiast który± z w¦zªów zainicjuje tryb czasu rzeczywistego (RT), po wst¦pnej fazie negocjacji, ustalania priorytetów i po wymianie potwierdze«, rozpoczyna si¦ transmisja oparta na wymianie znaczników (token). Ma ona charakter periodyczny. Kolejne w¦zªy otrzymuj¡ znaczniki w ustalonej kolejno±ci.
W danej chwili czasu jedynie w¦zeª posiadaj¡cy znacznik mo»e transmitowa¢ dane, dzi¦ki czemu nie wyst¦puj¡ kolizje. Czas przetrzymywania znacznika przez ka»dy z w¦zªów jest ograniczony, a jego warto±¢ ustalana jest indywidualnie, w zale»no±ci od zapotrzebowania zgªoszonego przez w¦zeª. Ka»dy z w¦zªów mo»e transmitowa¢ zarówno dane krytyczne czasowo, jak i dane niekrytyczne. Dla tych ostatnich przewidziane s¡ oddzielne okna czasowe.
Stosuj¡c protokóª RETHER unika si¦ kolizji, a to zapewnia deterministyczne warunki transmisji. Autor pracy [125] testowaª stworzony przez siebie protokóª RETHER, przesyªaj¡c za jego pomoc¡ dane multimedialne, jednak nic nie stoi na przeszkodzie u»ycia go równie» do celów sterowania. II.1.2 RTnet sie¢ czasu rzeczywistego dla systemu RTAI
Twórcy zestawu protokoªów sieciowych RTnet [54, 71] zastosowali koncepcj¦ podobn¡ do u»ytej w protokole RETHER. Dzi¦ki wyeliminowaniu jednoczesnych prób transmisji, unikn¦li wyst¦powa-nia kolizji. Rozwi¡zanie RTnet powstaªo jednak z my±l¡ o zastosowaniu gªównie do celów sterowawyst¦powa-nia automatycznego, a jako warstw¦ zyczn¡ mo»e ono wykorzystywa¢ nie tylko Ethernet. Odpowiednie sterowniki programowe (driver), realizuj¡ce protokoªy RTnet, opracowano dla systemu operacyjnego RTAI [10,33,34]. System ten pozwala wykonywa¢ zadania czasu rzeczywistego na komputerze klasy PC, a do swojej pracy wymaga systemu operacyjnego Linux [1]. Sterowniki RTnet wspóªpracuj¡ z typowymi kartami sieciowymi, w które wyposa»ane s¡ komputery klasy PC. Aplikacji u»ytkownika udost¦pniaj¡ interfejs API wzorowany na koncepcji gniazdek (sockets), zaadaptowany do specy- ki zada« czasu rzeczywistego. Konstrukcja stosu omawianej rodziny protokoªów przedstawiona jest schematycznie na rysunku II.1, zaczerpni¦tym z pracy [71]. Wykorzystywany tu algorytm dost¦pu do medium to TDMA (Time Division Multiple Access). Jeden, wybrany w¦zeª sieci peªni rol¦ w¦zªa zarz¡dzaj¡cego (master), pozostaªe za± s¡ mu podporz¡dkowane (slave). Ka»dy z w¦zªów posiada przydzielon¡ mu szczelin¦ czasow¡ (time slot), w ramach której mo»e wysyªa¢ w sie¢ pakiety. Przy-dziaª szczelin czasowych ma zasadniczo charakter statyczny i realizuje si¦ go na etapie kon guracji systemu. Dla zachowania bezkolizyjnej pracy systemu konieczne jest precyzyjne synchronizowanie zegarów wszystkich w¦zªów sieciowych, realizowane przy pomocy stworzonego w tym celu proto-koªu. Twórcy protokoªów RTnet przewidzieli mo»liwo±¢ transmisji danych niekrytycznych czasowo, z wykorzystaniem techniki tunelowania pakietów. W sieci mo»na umieszcza¢ zapasowe w¦zªy zarz¡-dzaj¡ce, które przejmuj¡ kontrol¦ nad sieci¡ w przypadku awarii w¦zªa zasadniczego. Jest to istotne dla zwi¦kszenia niezawodno±ci systemu. Mo»liwe jest doª¡czanie nowych w¦zªów typu slave w czasie pracy systemu, jednak nie jest to mechanizm w peªni dynamiczny ich przewidywana przyszªa obecno±¢ musi by¢ uwzgl¦dniona wcze±niej, na etapie kon guracji systemu.
Opisane wªasno±ci czyni¡ protokóª RTnet w peªni przydatnym w rozproszonych systemach ste-rowania. Warto doda¢, »e zarówno RTnet, jak i RTAI oraz niektóre dystrybucje systemu Linux rozpowszechniane s¡ na zasadzie wolnego (ang. free like freedom) oprogramowania i s¡ bezpªatne nawet wówczas, gdy stosuje si¦ je do celów komercyjnych.
II.1.3 Przeª¡cznik sieci Ethernet z odr¦bn¡ kolejk¡ komunikatów krytycznych czasowo Rozwi¡zania opisane w poprzednich punktach (RETHER i RTnet) wykorzystuj¡ standardowe sprz¦-towe karty sieciowe (NIC) Ethernet, w które wyposa»one s¡ w¦zªy systemu rozproszonego, jednak
Rys. II.1: Stos protokoªu RTnet (NIC karta sieciowa, RT Driver sterownik programowy karty sieciowej, Loopback p¦tla zwrotna, RTnet Core trzon oprogramowania RTnet, RTcap mechanizm przechwytywania pakietów (packet capturing extension), RTmac ±rodowisko dla de-terministycznego protokoªu dost¦pu do medium (deterministic media access control framework), noMAC mo»liwo±¢ pracy bez deterministycznego protokoªu dost¦pu do danych, TDMA pro-tokóª wielodost¦pu z podziaªem czasu, VNIC wirtualna karta sieciowa, RTcfg usªuga kon -gurowania w¦zªów doª¡czanych dynamicznie do segmentu sieci w trakcie pracy systemu (real-time con guration service), UDP/IP, ICMP, ARP protokoªy sieciowe, API interfejs aplikacji u»ytkownika. ródªo: [71].
wymagaj¡ dokonania wymiany programowych sterowników implementuj¡cych stos protokoªów sie-ciowych. Je±li nie jest to mo»liwe, a u»yta sie¢ z wieloma w¦zªami bazuje na technologii Switched Ethernet, popraw¦ warunków transmisji mo»na osi¡gn¡¢ przez mody kacj¦ zasady dziaªania prze-ª¡czników sieciowych (switch). Sposób ten opisany jest w pracach [21, 104]. Ju» samo zastosowanie przeª¡czników zamiast koncentratorów (hub) ogranicza domeny kolizyjne w sieci Ethernet, przyczy-niaj¡c si¦ do skrócenia czasów przesyªu danych. Dalsza poprawa jest mo»liwa przez zaimplemento-wanie w przeª¡cznikach mechanizmu QoS (Quality of Service). Ten ostatni sposób jest szczególnie u»yteczny w sieciach, które przesyªaj¡ zarówno dane krytyczne jak i niekrytyczne czasowo. Prze-ª¡cznik z mechanizmem QoS zawiera w swej strukturze logicznej kilka (co najmniej dwie) kolejek komunikatów wychodz¡cych, przyporz¡dkowanych ka»demu z portów. Schematycznie przedstawiono to na rysunku II.2b, zaczerpni¦tym z [21]. Ka»da z kolejek danego portu ma przypisany priorytet, który decyduje o kolejno±ci, w jakiej wysyªane s¡ pakiety z kolejek. Pakiety krytyczne czasowo kiero-wane s¡ do kolejki posiadaj¡cej pierwsze«stwo wysyªania. Wymagane wªasno±ci transmisji osi¡ga si¦ stosuj¡c odpowiednio dobrane algorytmy harmonogramowania w przeª¡czniku oraz stosuj¡c kilka poziomów priorytetów (np.: najwy»szy dane okresowe krytyczne czasowo, ±redni dane nieokre-sowe krytyczne czasowo, najni»szy pozostaªe dane niekrytyczne czasowo).
Opisane rozwi¡zanie pozwala osi¡gn¡¢ maªe warto±ci opó¹nie« przesyªania komunikatów krytycz-nych czasowo, nawet w przypadku gdy sie¢ jest dodatkowo mocno obci¡»ona wymianami niekrytycz-nymi. Pozwala to wykorzystywa¢ t¦ sam¡ sie¢ Ethernet zarówno do zada« sterowania, jak i przesyªu
a) b)
Rys. II.2: Przeª¡cznik sieciowy (switch) z mechanizmem QoS: a) zasada dziaªania najprostszego przeª¡cznika, b) wiele kolejek dla jednego portu wyj±ciowego. ródªo: [21].
innych danych. Wspóªdzielenie takie nie jest jednak polecane, gdy» nie zapewnia tak wysokiej nie-zawodno±ci sterowania jak sie¢ dedykowana.