Pomiary Automatyka Robotyka 4/2022

Rok 26 (2022) Nr 4(246)

ISSN 1427-9126, Indeks 339512

Redaktor naczelny

Korekta Druk Wydawca

Kontakt Pomiary Automatyka Robotyka-

Rada Naukowa

Drodzy Czytelnicy,

Redaktor naczelny kwartalnika Pomiary Automatyka Robotyka

Pomiary Automatyka Robotyka, ISSN 1427-9126, R. 26, Nr 4/2022, 5–26, DOI: 10.14313/PAR_246/5

Aby ocenić, jaki wpływ będą miały roboty na społeczeństwo, należy skrupulatnie przeanalizować obecny stan wiedzy, a w szczególności wskazać fundamentalne problemy, które jeszcze nie zostały rozwiązane, mające istotne znaczenie dla potencjalnych zmian społecznych powodowanych rozwojem robotyki. Wspomniany wpływ zależy od inteligencji robotów, więc ten aspekt dominuje w przedstawionej tu analizie. Rozważania zostały podzielone na trzy części: 1) analizę czynników technicznych wpływających na inteligencję i bezpieczeństwo robotów, 2) analizę obecnych możliwości robotów, 3) analizę przewidywań dotyczących rozwoju robotyki, a w konsekwencji poglądów na skutki tego rozwoju dla społeczeństwa. Niniejszy artykuł poświęcony jest pierwszemu z wymienionych tu trzech zagadnień.

Motywacja

Ostatnio nasiliły się w prasie i opracowaniach o bardziej naukowym charakterze katastroficzne doniesienia przestrzegające przed rozwojem sztucznej inteligencji i robotyki. W wersji skrajnej wieszczą one, iż ludzie staną się zbędni, a maszyny przejmą władzę nad Światem. W istocie, słowo robot pojawiło się po raz pierwszy w sztuce Karela Čapeka o tytule “R.U.R –Rossumovi Univerzální Roboti” [145] napisanej w 1920 r. Jej prapremiera odbyła się w 1921 r. Już w tym pierwszym dziele poświęconym robotom zawładnęły one naszą planetą. Początkowo posłuszne maszyny obdarzono uczuciami, co doprowadziło je do wniosku, że ludzie, którzy wskutek pojawienia się robotów stali się bezproduktywni, a więc są niepotrzebni. Bunt robotów doprowadził niemal do wyplenienia ludzi. Ten scenariusz oparty jest na przeświadczeniu, że roboty mogą się stać bardziej inteligentne od ludzi, a co więcej mogą podejmować decyzje bez uwzględniania ludzkich zasad moralnych. Wprawdzie wyeliminowanie ludzi przez roboty wydaje się mało prawdopodobne, ale z faktu, że są stosowane w coraz to więk-

szej liczbie dziedzin gospodarki wynika, iż będą miały istotny wpływ na społeczeństwo. Motywacją do napisania niniejszego artykułu była próba rozstrzygnięcia, na ile roboty zmienią zasady funkcjonowania społeczeństw.

Odpowiedź na tak postawione pytanie wymaga określenia aktualnego stanu robotyki, a w szczególności pokazania, jaki jest stan podstawowych czynników kształtujących zarówno inteligencję jak i możliwości ruchowe tych urządzeń. Istotne jest też tempo zachodzących zmian technologicznych. Na podstawie literatury dotyczącej oddziaływania maszyn na zachowanie ludzi, należy przewidzieć, jaki wpływ będą miały roboty na społeczeństwo. W dużej mierze jest to uwarunkowane stopniem akceptacji tych urządzeń przez ludzi, tworzonym prawem oraz prawami ekonomii. Zawarta tu analiza jest wynikiem studiów literaturowych i streszcza główne nurty w debacie toczącej się nad tym problemem od lat. Jak każda prognoza, obarczona jest niepewnością, tym większą im dłuższy jest horyzont przewidywania.

Ta część artykułu koncentruje się przede wszystkim na tych aspektach robotyki, które związane są z inteligencją i sterowaniem robotów. Oczywiście inteligencja nie jest oderwana od możliwości ruchowych i percepcyjnych tych maszyn, więc i te zagadnienia będą pojawiać się w tym tekście.

Aby ocenić, jaki wpływ na społeczeństwo będą mieć roboty, trzeba przyjrzeć się nieco bardziej szczegółowo, jak obecnie próbuje się wytworzyć inteligentne zachowania tych urzą-

dzeń. Ponadto należy dokonać projekcji, do czego będą zdolne w przyszłości, a to można jedynie zrobić analizując obecne trendy rozwojowe. Niemniej jednak wpierw trzeba skierować snop światła na fundamentalne czynniki wpływające na inteligencję robotów. By uporządkować dyskusję, na wstępie należy nieco lepiej scharakteryzować przedmiot zainteresowań.

Przystoi na wstępie dobrze określić przedmiot zainteresowania artykułu. Niestety nie ma jednej ogólnie przyjętej definicji robota. Większość definicji cierpi albo na zbytnią szczegółowość, wykluczającą urządzenia powszechnie uważane za roboty, albo na zbytnią ogólnikowość, umożliwiającą zaliczenie do robotów urządzeń, które trudno jest uznać za takowe. Joseph Engelberger, który wspólnie z Georgem Devolem założył firmę Unimation, w której wytworzono pierwsze roboty przemysłowe [103], gdy został zapytany o definicję robota, wyrażając swą frustrację brakiem adekwatnego określenia, powiedział: I can’t define a robot, but I know one when I see one. (Nie potrafię zdefiniować robota, ale rozpoznaję go, gdy go widzę.) [34].

W tym artykule przyjęto bardzo szeroką definicję robota, niemniej jednak wyklucza ona oprogramowanie nieoddziałujące na środowisko fizyczne. Tak więc, robot stanowi system, który wpływa na otoczenie fizyczne przez swoje efektory (manipulatory, chwytaki, nogi, koła etc.), określa stan środowiska za pomocą swych receptorów (czujników) oraz obdarzony jest imperatywem wewnętrznym do realizacji zadań zdefiniowanych albo przez jego projektanta albo przekazywanych pośrednio lub bezpośrednio przez człowieka. System sterowania robota na podstawie danych uzyskanych z receptorów oraz definicji zadania, stanowiącego wspomniany imperatyw do działania, steruje efektorami tak, aby owo zadanie zrealizować. Działanie robota w środowisku fizycznym oczywiście nie wyklucza jego interakcji z cyberprzestrzenią. System robotyczny jest pojęciem bardziej ogólnym, składając się z co najmniej jednego robota oraz ewentualnie z dodatkowych urządzeń współpracujących.

Już w latach 80. XX w. przewidywano, iż sztuczna inteligencja będzie miała kluczowe znaczenie dla robotyki. Michael Brady, jeden z prekursorów robotyki, określił ją, jako dziedzinę badającą połączenie akcji z percepcją [21]. Wskazał ponadto, że jeżeli roboty mają się zachowywać inteligentnie, to centralną rolę odegra w tym połączeniu sztuczna inteligencja. Niestety jednoznaczne określenie czym jest sztuczna inteligencja jest bodaj jeszcze trudniejsze niż zdefiniowanie robota. George Luger i William Stubblefield przyjmują, że jest to gałąź informatyki zajmująca się automatyzacją inteligentnego zachowania [93]. Natomiast Stuart Russell i Peter Norvig, w klasycznym dziele poświęconym sztucznej inteligencji [122], pokusili się o podział jej definicji na kategorie. Z ich analizy wynikało, że istnieją cztery kategorie systemów korzystających ze sztucznej inteligencji. Są to systemy: 1) myślące, jak ludzie, 2) działające, jak ludzie, 3) myślące racjonalnie i 4) działające racjonalnie. Pierwsze dwie kategorie definicji odnoszą się do sposobu funkcjonowania ludzi, a więc wykorzystywane są przez kognitywistykę, czyli naukę o obserwacji i analizie działania oraz modelowaniu umysłu i mózgu, natomiast dwie ostatnie jedynie wymagając racjonalności, dotyczą systemów osiągających dobre efekty swego działania w kontekście posiadanej wiedzy, a więc dobrze nadają się do wykorzystania przez nauki inżynierskie, w szczególności do optymalizacji działania systemów.

Aby oderwać rozważania na temat inteligencji od kontekstu ludzkiego Alan Turing opracował eponimiczny test [143].

Test ten jest swoistą grą polegającą na zgadnięciu przez człowieka, na podstawie prowadzonej konwersacji z niewidocznym interlokutorem, czy jest to człowiek czy maszyna. Jeżeli jest to maszyna, a testujący nie jest w stanie stwierdzić tego

z pewnością, to mamy do czynienia ze sztuczną inteligencją. Test ten nie jest powszechnie wykorzystywany, ze względu na subiektywność osądu, czy obserwowane działanie jest inteligentne czy nie.

Yann LeCun uważa, że istotą inteligencji jest zdolność do przewidywania. Czasami wyraża to jako zdolność do uczenia się przewidywania, a więc podstawą inteligencji są zdolność przewidywania oraz umiejętność uczenia się. Wszakże należy pamiętać, że te zdolności potrzebują odpowiednich zasobów wiedzy (zgromadzonej lub dostępnej do zdobycia ze środowiska), aby rozumowanie przebiegało szybko zasoby te muszą być odpowiednio zorganizowane. W szczególności maszyny potrzebują wiedzy zdroworozsądkowej, którą ludzie zdobywają w dzieciństwie, i na podstawie której są w stanie przewidywać konsekwencje swoich czynów. LeCun rysuje interesującą koncepcję badawczą mająca prowadzić do budowy maszyn inteligentnych w swojej wizji [90]. Wizja ta dotyczy badań w celu stworzenia inteligentnych maszyn, które uczą się, jak zwierzęta, które potrafią wnioskować i planować, i których zachowanie jest określone ogólnymi celami, a nie na sztywno zaprogramowane bądź zewnętrznie nadzorowane albo motywowane otrzymywaniem zewnętrznych nagród. LeCun spodziewa się, że rozwiązaniem problemu będzie architektura systemu złożona z wielu głębokich sieci neuronowych imitujących poszczególne obszary ludzkiego mózgu. Istotną rolę w jego podejściu odgrywa model świata, który zazwyczaj był ignorowany przy wykorzystywaniu sieci neuronowych. Pozwala on przewidywać rezultaty działania robota, a więc ma fundamentalne znaczenie dla planowania działań.

Pomimo że istnieje wiele różnych kategorii robotów, to nie dopracowano się ścisłej ich klasyfikacji. Jako zgrubne kryterium można zastosować stopień strukturyzacji (uporządkowania) środowiska, w którym dany robot działa. Wtedy można wyróżnić trzy główne kategorie robotów: przemysłowe, usługowe oraz terenowe. Dwie ostanie kategorie w literaturze bywają wspólnie określane jako roboty zaawansowane (ang. advanced robots) [132]. Roboty przemysłowe działają w otoczeniu w pełni strukturalnym, gdzie położenia wszystkich obiektów są ściśle określone, więc roboty tej kategorii nie muszą mieć receptorów albo mają ich niewiele, bo w pełni mogą polegać na swojej wiedzy o pozycjach przedmiotów znajdujących się w środowisku. Roboty terenowe działają w otoczeniu, którego strukturę trudno określić, np. las, sad albo pole. Te roboty mogą zrealizować swoje zadania tylko przy wykorzystaniu różnorodnych receptorów. Roboty usługowe działają w środowisku o częściowo określonej strukturze, np. w pomieszczeniach mieszkalnych, biurowych czy szpitalnych lub gastronomicznych. Roboty tej kategorii również potrzebują receptorów do realizacji zadania. Ta podstawowa kategoryzacja robotów może być dalej rozbudowywana poprzez zastosowanie dodatkowych kryteriów klasyfikacji, szczególnie że wymienione wyżej podstawowe kryterium jest ciągłe, a nie dyskretne, a więc roboty przemysłowe i terenowe jawią się jako skrajne kategorie robotów usługowych. Dlatego, z jednej strony, roboty usługowe, działające w środowisku częściowo strukturalnym, obejmują szczególnie szeroką rodzinę robotów, a z drugiej, obecne roboty przemysłowe nie muszą działać w otoczeniu w pełni strukturalnym, a terenowe mogą realizować swoje zadania w środowisku częściowo strukturalnym, np. na drogach publicznych. Wśród robotów usługowych wymienia się takie podkategorie jak roboty osobiste (ang. personal), stosowane w domach, roboty profesjonalne (ang. professional), stosowane w biurach lub szpitalach, roboty asystujące (ang. assistive) lub kompani (ang. companions) wspomagający ludzi niepełnosprawnych i starszych, czy koboty (ang. collaborative robots, co-robots, cobots) [161]. Te ostatnie są robotami bezpośrednio współpracują-

cymi z ludźmi przy produkcji, a więc można je zakwalifikować zarówno do kategorii robotów przemysłowych jak i usługowych. Powstały one wskutek rozwoju technologii potrzebnych do konstrukcji robotów usługowych, a technologie te dopiero wtórnie zostały zastosowane w przemyśle. Stało się tak, ponieważ uznano, że są na tyle bezpieczne, że dzięki nim roboty mogą wchodzić w bezpośrednie interakcje z ludźmi, a więc standardowo stosowane zewnętrzne bariery i ogrodzenia odgradzające roboty przemysłowe od pracowników w tym przypadku nie są konieczne. Jak widać, ścisłe rozgraniczenie kategorii robotów jest trudne, bo jak określić ścisłe kryteria podziału, które nie zachodzą wzajemnie na siebie. Dlatego podany podział będzie tu stosowany jedynie dla ogólnej orientacji.

Robot musi być w stanie zrealizować powierzone mu zadanie, więc sposób przekazania mu tego zadania staje się kluczowy. Stąd musimy zająć się zarówno sposobami programowania robotów, jak i architekturami tych systemów.

Istnieją dwa poglądy na temat programowania robotów. Pierwszy, węższy, definiuje programowanie robotów jako sposób określania zadania, które robot ma wykonać. Drugi, szerszy, postuluje, że programowanie robotów jest tożsame z wytwarzaniem oprogramowania dla robotów, a więc obejmuje także tworzenie ich sterowników. Jak zwykle w przypadku robotyki, nie jest to podział dychotomiczny, ponieważ wiele robotów przeznaczonych jest do autonomicznego wykonywania zadań, które zostały określone na etapie tworzenia ich sterowników, a więc trudno jest rozróżnić część odpowiedzialną za wykonanie zadania od pozostałych części, które sterują urządzeniem. Dlatego lepiej jest przyjąć tę szerszą definicję.

Od momentu powstania pierwszych robotów korzystających z serwomechanizmów przemysł preferował uczenie robotów, podczas gdy ośrodki akademickie pracowały nad specjalizowanymi językami programowania robotów. W tym przypadku uczenie rozumiane jest jako przemieszczanie przez operatora ramienia robota przemysłowego do pozycji, które muszą być osiągnięte, by zrealizować zadanie, i zapamiętywanie ich. Zapamiętane pozycje stanowią program, który jest odtwarzany. Program nauczony w ten sposób może być wielokrotnie odtwarzany w celu powtarzania realizacji zadania. Istnieją dwie formy uczenia: PTP (point to point) oraz CP (ang. continuous path). Pierwsza forma polega na doprowadzaniu końcówki manipulatora do odległych od siebie pozycji specyficznych dla wykonywanego zadania, by je zapamiętać. W trakcie odtwarzania programu sterownik dokonuje interpolacji trajektorii. Druga forma zmusza sterownik do automatycznego zapamiętywania pozycji na trajektorii co bardzo krótki czas, dzięki czemu unika się interpolacji. Pierwsza forma wykorzystywana jest do obsługi maszyn, transportu obiektów lub montażu, natomiast druga np. do malowania natryskowego. Zaletą uczenia jest prostota programowania, która nie wymaga zbyt wysokich kwalifikacji od programisty. Niestety modyfikacja fragmentu zadania bądź wykorzystanie odczytów czujników stanowi tu niebagatelny problem, nie wspominając o braku czytelnej dokumentacji stworzonego programu.

Wad tych nie mają programy zapisane w specjalizowanych językach programowania robotów, ale tutaj kompetencje programisty muszą być o wiele wyższe, by zapisać program w formie tekstowej. Co więcej, roboty nawet tego samego typu nieznacznie się różnią między sobą, więc ich końcówki będą osiągały pozycje zadane z różną dokładnością. To powoduje konieczność kalibracji albo mechanizmu ramienia albo programu. W toku rozwoju robotów przemysłowych oba sposoby programowania zostały zintegrowane [163]. Obecnie kluczowe, ale nieliczne, pozycje są uczone, a pozostałe określane są w tekście programu względem tych nauczonych.

Specjalizowane języki programowania robotów ponadto oferują wszelkie możliwości, które posiadają proceduralne uniwersalne języki programowania. Fakt ten spowodował odejście od języków specjalizowanych na korzyść języków uniwersalnych, takich jak C, C++ czy Pascal. Struktura programu zapisywana była w języku uniwersalnym, natomiast elementy specyficzne dla robota, takie jak instrukcje ruchu czy obliczenia geometryczne, realizowane były przez biblioteki, zapisane w tym samym języku uniwersalnym (np. PASRO (ang. Pascal for Robots) [17, 18] lub RCCL (ang. Robot Control C Library) [67]). Wprawdzie zmniejszyło to czytelność programów w stosunku do tych zapisanych w językach specjalizowanych, ale likwidowało konieczność tworzenia kompilatorów bądź interpreterów tych języków, i zmniejszało koszt wprowadzania modyfikacji do języka przy inkorporacji nowych urządzeń (np. czujników) do systemu. Niestety biblioteki nie dawały wskazówek, jak tworzyć oprogramowanie o odpowiedniej architekturze. Tej niedogodności miały zaradzić programowe struktury ramowe (ang. programming frameworks), np. Player [40, 60, 144], OROCOS (ang. Open Robot Control Software) [31, 32], ROS (ang. Robot Operating System) [120], YARP (ang. Yet Another Robot Platform) [57, 102], ORCA [22, 23], MRROC++ (ang. Multi-Robot Research Oriented Controller based on C++) [156, 158–160, 168] i inne [166]. Oferowały one wzorce użycia, co stanowiło pewną wskazówkę dla programistów, jak poprawnie konstruować programy. Większość struktur ramowych skupiała się na tzw. idiomach, a więc wzorcach dotyczących kodu w konkretnym języku programowania. Nieliczne odnosiły się do wzorców projektowych lub architektonicznych [77].

Zarówno biblioteki, jak i struktury ramowe koncentrowały się na fazie implementacji w budowie oprogramowania, ignorując specyfikację. Natomiast dobre praktyki wytworzone na gruncie inżynierii oprogramowania podkreślają konieczność tworzenia specyfikacji przed przystąpieniem do implementacji [125]. By temu problemowi zaradzić powrócono do języków specjalizowanych, ale w innej postaci. Języki zorientowane na konkretną dziedzinę DSL (ang. Domain-Specific Language) wywodzą się z ogólnego podejścia do projektowania zwanego inżynierią opartą na modelu MDE (ang. Model Driven Engineering) [30, 108]. Model uwypukla najistotniejsze właściwości systemu, pomijając szczegóły implementacyjne. Zastosowanie MDE do tworzenia oprogramowania prowadzi do automatycznej generacji kodu tworzonego systemu – przynajmniej częściowo. W robotyce stosuje się zarówno języki modelowania ogólnego przeznaczenia, takie jak UML [117], jak i języki specjalnie opracowane do modelowania systemów robotycznych [30]. Ponieważ różne aspekty systemu tworzone są za pomocą różnych języków dziedzinowych, potrzeba wielu narzędzi, by przetworzyć i zweryfikować model, aby w rezultacie powstał kod pożądanego systemu. Wskazane jest, by zestaw narzędzi (ang. toolchain) był jak najmniej liczny, bo w przeciwnym razie trudność jego opanowania powoduje niechęć programistów do jego używania. W tym nurcie stworzono również sparametryzowany meta-model, który może być przekształcony w program sterownika dowolnego robota poprzez określenie funkcyjnych parametrów oraz struktury hierarchicznej sieci Petriego [55].

Chcąc uczynić programowanie robotów, rozumiane jako przekazywanie im zadań do wykonania, jeszcze bardziej zbliżone do tego, jak ludzie przekazują sobie polecenia, zaczęto pracować nad programowaniem przez demonstrację (ang. programming by demonstration). Wykorzystując kamery, mikrofony oraz inne czujniki robot przygląda się pracy człowieka oraz słucha jego komentarzy, w ten sposób jest instruowany, jak ma wykonać zadanie [14, 15]. Dzięki temu kwalifikacje człowieka w zakresie programowania robotów stają się zbędne, natomiast ludzki nauczyciel musi umieć wykonać czynności, by samodzielnie zrealizować zadanie, które później robot ma powtórzyć. Osiągnięcie takiej formy programowania jest bardzo trudne, więc

proponowane są rozwiązania prostsze. W skrajnym podejściu za programowanie przez demonstrację można uznać uczenie typu PTP lub CP, ale nie o to tu chodzi. Dlatego bada się zastosowanie czujników sił i dotyku oraz kamer do wspomagania demonstracji [112]. Próbuje się też stosować rozszerzoną rzeczywistość w trakcie programowania robota. Ponadto stara się definiować zadania poprzez ograniczony zestaw sparametryzowanych umiejętności [136] określonych na podstawie standardowych procedur operacyjnych dla robotników produkcyjnych [116]. Podstawowymi problemami są [14]: −kiedy i kogo robot ma imitować? – usunięcie z prezentacji wykonania zadania czynników nieistotnych jest trudnym zagadnieniem, jak ma być imitowany ruch człowieka, skoro struktury kinematyczne oraz parametry odnoszące się do wymiarów robota i człowieka są różne, roboty mają słabo rozwinięty zmysł dotyku, więc bardzo źle rozpoznają fakturę i temperaturę przedmiotów.

Do tego zestawu podstawowego należałoby dodać zdolność do uogólniania swych obserwacji, by na podstawie jednej prezentacji można było wykonywać podobne zadania – byłby to krok w kierunku sztucznej ogólnej inteligencji (AGI). Pomimo istotnego postępu w metodach programowania robotów, zlecanie zadań robotowi w taki sposób, jak to robią ludzie między sobą, jest jeszcze dość odległą przyszłością.

Aby ocenić do czego zdolne są roboty, trzeba nieco więcej powiedzieć, jak są one sterowane i jak wyglądają ich systemy sterowania. Dlatego skoncentrujemy się na architekturach systemów robotycznych. Pożądanymi cechami robotów współdziałającymi z ludźmi są: inteligencja, autonomia, zdolność do komunikacji, wnioskowania i uczenia się. Aby uzyskać te cechy trzeba zaprojektować złożony sterownik robota lub bardziej ogólnie, systemu robotycznego. Jest to zadanie nietrywialne, stąd wiele jest propozycji jego rozwiązania.

Pomimo liczności opracowywanych systemów robotycznych nie istnieje jedna metoda ani przedstawiania ich architektur, ani klasyfikacji ich struktur (np. [33, 37, 47, 49, 52, 96, 97, 114, 150]). W pracach [43, 83], poświęconych architekturom systemów robotycznych, wskazano, że do ich opisu trzeba określić: −strukturę architektoniczną, czyli prezentację podsystemów i ich połączeń, styl architektoniczny, czyli opis wykorzystywanych konceptów obliczeniowych i komunikacyjnych, określających aktywność lub funkcje systemu – zapewne lepiej byłoby to nazwać funkcjami architektury, niż stylem architektonicznym.

Niemniej jednak praca [83] wskazuje, że dla większości stworzonych systemów trudno określić zarówno ich strukturę jak i styl (funkcje). Pomimo prowadzenia prac dotyczących formalnej specyfikacji oprogramowania sterującego robotami [7, 94, 95, 157, 165] i jego formalnej weryfikacji [81, 82] niestety takie ścisłe podejście do procesu wytwarzania sterownika nie uzyskało szerszej akceptacji środowiska robotyków. Zazwyczaj architektury przedstawiane są za pomocą nieformalnych opisów tekstowych oraz diagramów blokowych o bardzo zróżnicowanym poziomie szczegółowości, przy zastosowaniu różnych środków graficznych. Prowadzi to do poważnych problemów w implementacji i dokumentacji tak opisanych systemów, nie wspominając kłopotów przy próbach modyfikacji ich działania. Najpopularniejszą formą architektoniczną w robotyce jest struktura warstwowa. Podział na warstwy jest albo tworzony na podstawie częstotliwości powtarzania zachowania komponentów systemu [50] albo przez dekompozycję zadania na podzadania. Dominują architektury dwu- [106] i trójwar-

stwowe, np.: czuj–planuj–działaj SPA (ang. sense–plan–act), reaktywna uogólniająca (subsumption) [25–27], hybrydowe planująco–reaktywne [6], hierarchiczne [4, 59]), inspirowane biologicznie [94, 95, 138], wykorzystujące przekonanie–pragnienie–intencję BDI (ang. belief–desire–intension) [111, 129].

Jedną z najstarszych architektur jest architektura SPA, używana na przykład przez robota Shakey już w latach sześćdziesiątych XX w. [107]. W tej architekturze moduły: percepcji, planowania i wykonawczy połączone były kaskadowo, co wprowadzało duże opóźnienie w reagowaniu na zmiany zachodzące w środowisku. Model środowiska, niezbędny do planowania działań, zapisywany był w języku STRIPS, o którym więcej napisano w sekcji 2.9.

Ponieważ planowanie jest czasochłonnym zadaniem, R. Brooks zaproponował alternatywną architekturę -– architekturę uogólniającą, w której zachowania zostały zdefiniowane jako: reakcje na bodźce sensoryczne lub producenci aktywności. Jeśli reakcje dolnej warstwy nie były w stanie poradzić sobie z zadaniem, reakcje górnej warstwy hamowały lub tłumiły działania dolnej warstwy, przejmując kontrolę nad systemem, a tym samym uogólniając ich działania. W takim systemie reprezentacja środowiska nie występuje. Brooks twierdził, że najlepszym modelem środowiska jest ono samo, więc wystarczy jedynie odczytywać bodźce z niego pochodzące [27]. Ponieważ przetwarzanie informacji w takich systemach odbywa się równolegle (wszystkie zachowania działają jednocześnie, a ostateczny wynik ich działania jest superpozycją propozycji generowanych przez te zachowania), to reakcje robota są prędkie. W systemach o architekturze SPA dekompozycja na moduły następuje według funkcji, które poszczególne moduły mają realizować w potoku przetwarzania informacji, poczynając od percepcji a kończąc na akcji, natomiast w architekturze uogólniającej dekompozycja dokonywana jest na zachowania, z których każde samodzielnie może realizować pewne proste zadanie – zachowania działają wspólnie i równolegle, by zrealizować zadanie złożone. Architektura uogólniająca może być budowana stopniowo, gdzie każda nowa warstwa nadaje więcej kompetencji działaniom systemu. Niemniej jednak na każdym etapie system jest w stanie działać w środowisku, być może słabo, ale jednak zachowywać się w miarę sensownie. Należy zwrócić uwagę, że w architekturze SPA podsystem percepcyjny działa na wszystkich dostępnych sygnałach pochodzących ze środowiska i na tej podstawie buduje aktualny stan modelu tego środowiska, by w konsekwencji podjąć decyzję, co do dalszych swoich działań. Natomiast w architekturze uogólniającej poszczególne moduły (zachowania) działają tylko na części odczytów czujników, więc agregując je uzyskują częściową reprezentację środowiska. Reprezentacja całości jest rozproszona i, co więcej, jest cechą emergentną takiego systemu. Prawdopodobnie podobnie działają systemy nerwowe u zwierząt, stąd wiara Brooksa, że tym sposobem można wytworzyć inteligencję ssaków, a może i ludzką – niestety nie udało się tego jeszcze osiągnąć. Wszakże ewolucja potrzebowała na to kilkaset milionów lat.

Ponieważ architektura SPA wydaje się być zbyt powolna, a architektura uogólniająca, choć bardzo reaktywna, nie jest dalekowzroczna, pojawiły się architektury hybrydowe. Były one zwykle projektowane jako systemy trójwarstwowe, realizujące: planowanie (warstwa deliberatywna), sekwencjonowanie (zwykle implementowane jako automat skończony przełączający zachowania) i sterowanie urządzeniami (czyli warstwa odpowiedzialna za sterowanie efektorami i agregację danych z receptorów – w sumie tworząc warstwę reaktywną).

Istnieje wiele odmian architektury BDI, różniących się szczegółami. Cechą wspólną jest wyróżnienie stanów umysłu (ang. mental states), które są emanacją pracy układu sterującego. W literaturze (np. [83, 111, 129]) przyjmuje się, że są to: 1) przekonania, czyli posiadana informacja, 2) pragnienia, czyli

motywacja do działania i 3) intencje systemu, czyli wybrany plan działania. Tak naprawdę, to te trzy atrybuty razem określają aktualny stan systemu. Przekonania odpowiadają wiedzy, jednak różnią się tym, że wiedza jest z pewnością prawdziwa, podczas gdy przekonania mogą takie nie być. Przekonania obejmują zbiór informacji dotyczących samego agenta i jego środowiska, w tym innych czynników, a także zasad wnioskowania do tworzenia nowych przekonań. Pragnienia reprezentują cele, które agent chce osiągnąć albo poprzez własne działania, albo które mogą być wymuszone przez pewne czynniki zewnętrzne. Cele są pragnieniami, do realizacji których agent aktywnie dąży. Intencje to pragnienia, do których zobowiązał się agent, wybierając i realizując plan, który prowadzi do ich spełnienia. Reaktywne zachowanie agenta jest spowodowane zdarzeniami, zarówno generowanymi zewnętrznie, jak i wewnętrznie. Architektura BDI opiera się na interpreterze, który jest wyzwalany przez zdarzenia. Aktualizuje on przekonania i pragnienia, a w konsekwencji realizuje nowe intencje.

Istotny wpływ na architektury systemów robotycznych miało wprowadzenie pojęcia agenta upostaciowionego. Koncepcja agenta upostaciowionego została spopularyzowana przez Rodneya Brooksa [26], podczas debaty nad problemem, czy roboty potrzebują modeli otoczenia oraz planowania do inteligentnego działania w złożonym środowisku. Tradycjonaliści, zwani zwolennikami GOFAI (ang. Good Old Fashioned Artificial Intelligence), uważali, że robot powinien działać w architekturze SPA, a więc wpierw pozyskać informacje ze środowiska, następnie, na podstawie uaktualnionego stanu modelu, zaplanować swoje czynności, by w końcu je wykonać. Brooks twierdził, iż wykonanie takiego cyklu obliczeń trwa na tyle długo, że w dynamicznie zmieniającym się środowisku, w momencie, gdy dochodzi do wykonania zaplanowanych czynności, stan otoczenia jest już na tyle zmieniony, że te czynności są nieadekwatne do sytuacji. Dlatego twierdził, że robota należy traktować jako agenta upostaciowionego, tj. agenta mającego materialne ciało, który powinien być usytuowany, tj. działać bezpośrednio w rzeczywistym środowisku, a nie używać uproszczonego jego modelu do planowania swych działań [24, 27, 28]. Robot powinien być reaktywny, a inteligencja pojawi się w wyniku interakcji agenta z rzeczywistym środowiskiem. Przetwarzanie sygnałów pochodzących ze środowiska wymaga inteligencji, więc ją stymuluje. Innymi słowy, inteligencja jest tu traktowana jako efekt emergentny oddziaływania robota i środowiska kształtującego jego zachowanie.

Ani zwolennicy GOFAI, ani Brooks nie udowodnili, że ich podejścia są jedynie słuszne, dlatego pojawiły się agenty hybrydowe, mające właściwości zarówno reaktywne, jak i deliberatywne [6]. Debata ta pobudziła wielu autorów do skoncentrowania się na koncepcji agenta. Klasyczny tekst o sztucznej inteligencji [122] traktuje agenta jako coś, co działa. Taka wszechogarniająca definicja jest zbyt ogólna, stąd podręcznik ten nadaje agentom określone cechy: autonomię, czyli działanie bez pomocy człowieka, umiejętność postrzegania środowiska, wytrwałość, adaptację do zmian zachodzących w środowisku, zdolność do podejmowania zadań innych agentów. Dodatkowo różnicuje agenty wprowadzając pojęcia: agenta racjonalnego, który wytwarza optymalny wynik swoich działań lub optymalny oczekiwany rezultat, jeśli działa w niedeterministycznym środowisku. agenta uczącego się, który doskonali swoje możliwości dzięki zdobytemu doświadczeniu. Agent upostaciowiony wyewolułował z pojęcia agenta programowego używanego w informatyce. Niestety większość tekstów poświęconych agentom (np. [109]) wskazuje, że nie ma ścisłej definicji tego pojęcia. Według Hyacintha Nwany [110] jednym z podstawowych kryteriów klasyfikacji agentów programowych

jest to, czy są one stacjonarne czy mobilne, co określane jest na podstawie tego, czy są one umiejscowione na jednym komputerze, czy poruszają się po sieci. Ponadto agenty mogą być: reaktywne, deliberatywne lub hybrydowe. Wyróżnia się szczególną klasę agentów – agenty interfejsujące, które umożliwiają użytkownikom interakcję z różnymi systemami.

Michael Wooldridge [147] definiuje agenta jako system komputerowy ulokowany w określonym środowisku, w którym może działać autonomicznie, aby osiągnąć określony cel. Definicja ta jest podstawą tekstu [111], który wymienia pożądane właściwości agenta. Agent powinien być reaktywny, tj. reagować na zmiany zachodzące w otoczeniu, proaktywny, tj. dążyć do celu, społeczny, tj. zdolny do interakcji z innymi agentami, elastyczny, tj. zdolny do osiągnięcia celu na różne sposoby, odporny, tj. zdolny radzić sobie z ewentualnymi błędami.

Niewątpliwie istnieje wiele podobieństw między agentem programowym i upostaciowionym, ale podstawową różnicą jest to, że ten pierwszy funkcjonuje wewnątrz komputera lub sieci komputerowej, a więc umownie rzecz ujmując w cyberprzestrzeni, natomiast ten drugi ma ciało materialne i funkcjonuje w środowisku rzeczywistym. Należy też zwrócić uwagę, że agent upostaciowiony nie powinien być utożsamiany z robotem, gdyż jednego robota może tworzyć wiele agentów upostaciowionych, ale nie na odwrót [162]. Istotnym jest to, że w przypadku agentów upostaciowionych ich interakcja z otoczeniem ma fundamentalne znaczenie dla powstania i rozwoju inteligencji systemu z nich złożonego.

Obecnie dąży się do tego, aby roboty realizowały swoje zadania autonomicznie, a więc bez pomocy człowieka. Rozróżnia się dwa ogólne typy autonomii: energetyczną i decyzyjną. Ten pierwszy typ determinuje, czy źródło zasilania robota w energię znajduje się na jego pokładzie czy nie. Ten drugi wskazuje, czy przy realizacji zadania potrzebny jest współudział człowieka. W tym przypadku raczej mówi się o stopniu lub poziomie autonomii, w zależności od wpływu operatora na wykonywanie czynności prostych. Możemy tu mieć do czynienia z urządzeniami teleoperowanymi, gdy człowiek jest odpowiedzialny za sterowanie ruchem urządzenia lub o dużym stopniu autonomii, gdy całe zadanie jest realizowane bez udziału operatora. Zarówno robot chirurgiczny da Vinci [19], jak i łazik marsjański Sojourner [41] są urządzeniami teleoperowanymi. W przypadku urządzeń w pełni autonomicznych, operujących w złożonym i zmiennym środowisku, inteligencja operatora musi zostać zastąpiona tą sztuczną.

Międzynarodowe stowarzyszenie Society of Automotive Engineers (SAE), zajmujące się m.in. standaryzacją, zdefiniowało sześć poziomów autonomii samochodów, numerując je od 0 do 5 [92]. W tym przypadku pojazdy traktowane są jako roboty mobilne. Samochody przypisane poziomowi 0 są pod pełną kontrolą kierowcy i co najwyżej informują go o niebezpieczeństwie. Na poziomie 1 człowiek i układ sterowania współkierują pojazdem, np. kierownicą zawiaduje człowiek, a prędkość regulowana jest przez automat. Na poziomie 2 układ sterowania w pełni kieruje pojazdem, ale człowiek stale powinien czuwać nad sytuacją panującą na drodze i natychmiast przejąć sterowanie, o ile zauważy, że dzieje się coś niepokojącego. Dopiero poziom 3 autonomii zezwala kierowcy odwrócić uwagę od sytuacji na drodze, bo w tym przypadku to samochód jest odpowiedzialny za wykrywanie sytuacji niepokojących i wtedy wzywa kierowcę, by przejął kontrolę nad pojazdem. Ten poziom autonomii umożliwia, przykładowo, automatyczne kierowanie w korku lub na autostradzie. Na poziomie 4, gdy spełnione są odpowiednie warunki drogowe, udział człowieka w kierowaniu nie jest wymagany, więc może się on zająć dowolną inną aktywnością. Samochód może wezwać kierowcę do interwencji, ale jeżeli ten nie zareaguje, to pojazd może zacząć dążyć do zapar-

kowania. Taka sytuacja może powstać, gdy warunki pogodowe zmienią się drastycznie. Pojazdy sklasyfikowane na poziomie 5 nie wymagają uczestnictwa kierowcy w sterowaniu pojazdem niezależnie od warunków drogowych. Wyższe poziomy autonomii obecnie są jedynie przedmiotem badań. IEEE pracuje nad standardem dotyczącym bezpieczeństwa pojazdów autonomicznych (P2846 Draft Standard for Assumptions for Models in Safety-Related Automated Vehicle Behavior). Zarys standardu P2846 określa zbiór założeń dla dających się przewidzieć scenariuszy, które należy brać pod uwagę przy tworzeniu modeli związanych z bezpieczeństwem pojazdów sterowanych automatycznie. Standard jest tworzony, aby wszystkie firmy tworzące autonomiczne samochody, niezależnie od użytych technologii, tak samo rozumiały bezpieczne zachowanie pojazdu na drodze. Z punktu widzenia konsumentów standard tworzy sytuację, w której kupujący samochód nie będzie musiał zastanawiać się, który wybrać z punktu widzenia reguł bezpieczeństwa.

Cel, który robot ma zrealizować, może być określony w fazie projektowania robota – zazwyczaj tak się dzieje w przypadku robotów specjalizowanych wykonujących złożone zadanie. Zadania mogą też być formułowane i zmieniane w trakcie działania robota. Wtedy układ sterowania robota musi zawierać interpreter poleceń. Zazwyczaj lista poleceń wyrażana jest jako język programowania robota. Jest to szczególnie często stosowana metoda programowania robotów przemysłowych [163]. Interakcja między operatorem i nie w pełni autonomicznym robotem usługowym bądź terenowym odbywa się albo poprzez dedykowaną konsolę (np. [41]) albo głosem w ograniczonym języku naturalnym (np. [164]). W obu przypadkach musi istnieć wewnętrzny język sterownika robota służący reprezentacji poleceń.

Niezależnie od tego, w jaki sposób robotowi zostanie przekazane zadanie do wykonania, istotne są kategorie pojęciowe służące określeniu tego zadania. Te kategorie tworzą ontologię [66]. Złożoność ontologii, z której korzysta robot, determinuje poziom jego inteligencji. Ontologia określa zarówno byty, jak i relacje między nimi. Podstawowym celem jej stosowania jest umożliwienie wnioskowania dotyczącego realizacji zadania, a więc planowanie. Szczegółowość planowania zależna jest od ilości wiedzy zdroworozsądkowej (ang. commonsense knowledge), którą dysponuje robot. Zasób wiedzy zdroworozsądkowej posiadany przez robota w istotny sposób determinuje zdolność do prawidłowego zrealizowania zadania. Przykładowo, jeżeli w ontologii robota nie występuje pojęcie pola grawitacyjnego, to pozostawienie przedmiotu w powietrzu, bez podparcia, będzie uznane za rozsądne rozwiązanie, ale w rzeczywistości spowoduje katastrofę.

Wyróżnia się różne poziomy ontologiczne. Dla robotów manipulacyjnych zwykło się definiować cztery poziomy. Na najniższym poziomie zadanie definiuje się określając kolejne położenia lub trajektorie ruchu końcówki manipulatora za pomocą wartości zmiennych złączowych, a więc kątów lub przesunięć między członami łańcucha kinematycznego. Jest to dla operatora dość niedogodny sposób definiowania zadania, gdyż faktyczny cel działania robota nie zostaje wyjawiony –co ma być wykonane, wynika z sekwencji zapisanych położeń złączy. Kolejny poziom dotyczy określenia pozycji końcówki, z którą związano kartezjański układ odniesienia. Definiując jego położenie i orientację wskazuje się pozycje docelowe końcówki. W tym przypadku nadal cel działania nie jest określony jawnie, ale sposób definicji trajektorii jest o wiele bardziej intuicyjny. Ontologie dwóch wspomnianych poziomów definiują zadanie w kategoriach ruchu robota pomiędzy pozycjami zadanymi wyrażonymi w różnych przestrzeniach: konfiguracyjnej (złączy) i operacyjnej (końcówki). Człowiek jednak, nawet jeżeli wydaje mu się dość szczegółowe polecenia, jest przyzwy-

czajony do definiowania zadania poprzez wskazywanie przedmiotów i określanie związanych z nimi czynności. W ontologii tego poziomu pojawiają się nazwy kategorii obiektów oraz relacji między nimi [154, 155]. Relacje odgrywają fundamentalną rolę, gdyż, przykładowo, postawienie filiżanki na spodku i przemieszczenie spodka, spowoduje zmianę pozycji filiżanki, ale nie na odwrót. Przy sklejeniu dwóch obiektów relacja staje się symetryczna, bo przemieszczenie dowolnego z obiektów przesuwa drugi z nich. Stosując ontologie tego poziomu czynności przestają dotyczyć bezpośrednio robota, a odnoszą się do potencjalnie nieskończonej liczby obiektów znajdujących się w środowisku. Sytuacja staje się bardzo skomplikowana. Jedynie obiekty uchwycone przez robota mogą być przemieszczane. Ponadto obiekty mogą być pozostawione jedynie w miejscu, w którym będą podparte stabilnie, a więc trzeba uwzględnić zarówno grawitację jak i tarcie. Nawet jeżeli uwzględni się pełny model dynamiki środowiska, co oczywiście nie jest możliwe ze względu na brak precyzyjnej znajomości wszystkich jego parametrów, to nadal zadanie formułowane jest w kategoriach szczegółowych przemieszczeń – wprawdzie tym razem obiektów, a nie robota bezpośrednio. Należy zwrócić uwagę, że ludzie komunikując się ze sobą zakładają, że ich interlokutorzy mają zdroworozsądkową wiedzę o zachowaniach obiektów i w związku z tym wystarczy by polecenie odnosiło się jedynie do celu, który ma być osiągnięty. Plan realizacji zadania musi zostać wygenerowany przez osobę, której wydano polecenie. Planowanie wymaga kolejnego poziomu ontologicznego. Najbardziej pożądanym byłoby przekazywanie robotowi poleceń w języku naturalnym. Niestety język naturalny potrafi być wieloznaczny, a ponadto jego rozumienie wymaga od interlokutorów nie tylko posiadania wiedzy zdroworozsądkowej, ale również znajomości kodów kulturowych. Dla porozumienia się ludzi między sobą, a więc i dla komunikowania się z robotami, obie strony dialogu muszą wykorzystywać tę samą ontologię. Ponadto dla naturalnej współpracy z ludźmi roboty same muszą wyrażać emocje i odpowiednio reagować na emocje tych, z którymi wchodzą w interakcje.

Ontologie stanowią podstawę do tworzenia baz wiedzy. Jakość bazy wiedzy ocenia się określając, co można wywnioskować za jej pomocą, na jakie zapytania jest w stanie odpowiedzieć i ile czasu zajmuje znalezienie odpowiedzi. Przykładowo, KnowRob [139] to baza wiedzy przeznaczona do użytku przez roboty. KnowRob był wzorowany na ontologii ogólnego przeznaczenia Cyc [98], która wszakże nie zawierała pojęć związanych z robotyką. KnowRob zawiera pojęcia zaczerpnięte z robotyki i używane do opisu gospodarstw domowych, czyli: zdarzenia, informacje czasowe, akcje, zadania złożone, parametry akcji, obiekty, informacje czasoprzestrzenne, procesy, komponenty robota i opis jego możliwości. Interakcja z bazą KnowRob odbywa się za pomocą zapytań. KnowRob jest zanurzony w programowej strukturze ramowej CRAM (ang. Cognitive Robot Abstract Machine) [11]. W skład systemu wchodzą: bazy wiedzy (reprezentacja wiedzy), moduł dysponujący metodami wnioskowania, moduł akwizycji wiedzy (interfejs do podsystemu percepcji oraz sieci WWW), moduł sterowania robotem oraz modułu interakcji z człowiekiem za pomocą mowy. CRAM wykorzystuje procedury przetwarzające dane z podsystemów percepcji oraz sterowania efektorami, aby uzyskać dane, które są przekształcane w symboliczną reprezentację, na której można wykonywać wnioskowanie. Maszyna CRAM wykorzystuje język CPL (ang. CRAM Plan Language) do planowania działań robota. Baza wiedzy KnowRob służy do wnioskowania, jakie działania powinien wykonać robot (tryb zapytań) oraz do przechowywania informacji zebranych przez system percepcji (tryb powiedz). Wykorzystuje koncepcję wirtualnych baz wiedzy, które nie przechowują informacji, ale obliczają je na żądanie przy użyciu najbardziej aktualnych danych dostarczanych przez podsystem percepcji lub

przy użyciu innych już dostępnych danych obecnych w bazie wiedzy. KnowRob wykorzystuje zarówno ogólne, jak i specjalne metody wnioskowania. Preferuje szybkość wnioskowania nad jego ogólność. KnowRob korzysta także z OWL (ang. Web Ontology Language), który przechowuje formuły zapisane w logice opisowej DL (ang. Description Logic) w pliku zapisanym w formacie XML stworzonym do reprezentacji wiedzy w sieci semantycznej (ang. Semantic Web). Instrukcje OWL są wewnętrznie reprezentowane w KnowRob jako predykaty języka Prolog, więc można użyć mechanizmów wnioskowania Prologu. Wszakże należy zwrócić uwagę, że Prologowi brakuje mechanizmów wnioskowania zajmujących się niepewnością, właściwościami przestrzennymi czy czasowymi.

Człowiek zlecając wykonanie zadania zakłada, że jego wykonawca posiada wiedzę zdroworozsądkową, więc w poleceniu nie są zawarte oczywistości. Ponieważ roboty wiedzy zdroworozsądkowej nie mają, to muszą ją wywnioskować na podstawie zasobów zawartych w swej bazie wiedzy lub mogą ją pozyskać z sieci. RoboEarth [140, 141] ma być zasobem internetowym dla robotów, tj. World Wide Web dla robotów. Generowanie treści przez użytkowników jest podstawą WWW. RoboEarth chce przenieść to podejście na roboty. Roboty mogą wymieniać informacje bez interwencji człowieka. Platforma RoboEarth jest dostarczana jako zestaw pakietów ROS. Wiedza uzyskana za pomocą RoboEarth jest reprezentowana w kategoriach aksjomatów logicznych. Formalnym językiem przedstawiania wiedzy dla robotów do wykorzystania i wnioskowania jest język SRDL (ang. Semantic Robot Description Language), który umożliwia opis: akcji i ich parametrów, pozycji obiektów i modeli potrzebnych do ich rozpoznawania, informacji dodatkowych o danych (np. sposób reprezentacja pozycji, jednostek przypisanych wielkościom liczbowym, formatów plików), wymagań nałożonych na robota w zakresie wykorzystania dostępnych informacji, modeli własnych robota i obiektów oraz metod dopasowywania wymagań zadań do możliwości robota. Modele obiektów zawierają informacje o tym, jak je rozpoznać (rysunki i obrazy CAD) oraz jak je poruszać. Modele rozpoznawania można pobrać z sieci WWW. Jeśli robot nie ma modelu obiektu, którego potrzebuje, w swojej lokalnej bazie wiedzy, to może zażądać jego pozyskania poprzez RoboEarth. Środowiska są reprezentowane jako mapy. Niestety siatki zajętości (ang. occupancy grid) nie mogą być używane do wnioskowania, więc w tym celu wykorzystywane są mapy semantyczne. SRDL jest realizowany jako rozszerzenie ontologii KnowRob.

Na marginesie dyskusji na temat roli ontologii w robotyce należy zauważyć, że komunikujące się ze sobą roboty muszą korzystać nie tylko z tego samego języka, ale również z tej samej ontologii [105]. W przeciwnym razie nie będą się mogły porozumieć. Co więcej, często sterowniki robotów konstruowane są jako systemy składające się z agentów. Foundation for Intelligent Physical Agents (FIPA), jedno ze stowarzyszeń standaryzacyjnych IEEE, określiło standard komunikacji międzyagentowej, który zakłada, że wiadomości przesyłane między agentami zawierają informacje o języku komunikacji oraz wykorzystywanej ontologii [115]. Tak więc ontologie są istotne dla sposobu komunikacji wewnątrz sterownika systemu robotycznego oraz sposobu jego komunikowania się ze światem zewnętrznym, a przez to także dla Internetu Rzeczy oraz Przemysłu 4.0.

Podejmowano próby proceduralnego określenia jednoczesnego działania robota w środowisku rzeczywistym i jego modelu, np. przy implementacji języka TORBOL (ang. Transformation Of Relations Between Objects Language) [154]. Interpreter tego języka wybierał właściwy wariant wykonania akcji (dokładniej realizacji relacji między obiektami) na podstawie stanu modelu środowiska. Niestety, gdy możliwych wariantów

realizacji zadania jest nadmiernie wiele, a w szczególności nie jesteśmy w stanie przewidzieć, jak wiele, to napisanie wariantowego programu sterującego robotem staje się niemożliwe. Mnogość wariantów wynika z tego, że środowisko, w którym operuje robot może przyjmować bardzo wiele stanów, a co więcej cel wykonania zadania wpływa na wygenerowany plan. Przykładowo, jeżeli zadaniem jest wyjęcie butelki ze skrzynki, to najlepiej złapać ją za szyjkę, a jeżeli chcemy z niej nalać sok, to trzeba ją schwycić z boku. Jeżeli to drugie jest niemożliwe, to trzeba wyjąć butelkę ze skrzynki trzymając ją za szyjkę, odstawić gdzieś i zmienić chwyt na dostosowany do nalewania soku. Przenoszenie otwartej butelki z sokiem może się odbywać jedynie w pionie. Natomiast jej orientacja przestrzenna może być dowolna, gdy butelka jest pusta albo zamknięta. Widać, że nawet takie trywialne zadanie ma multum wariantów. W takich sytuacjach trzeba uciec się do planowania opartego na wnioskowaniu prowadzonym na podstawie zgromadzonych faktów. Fakty te pochodzą z własnej bazy wiedzy robota oraz z jego podsystemu percepcyjnego. Wykorzystanie tego zasobu wiedzy umożliwia wyrażenie zadania w niezwykle zwięzły sposób. Zamiast wielce rozgałęzionego programu mającego instrukcje dla każdego z możliwych wariantów, mamy ogólną, zwięzłą specyfikację zadania, a program wnioskujący, biorąc pod uwagę zgromadzoną wiedzę, musi opracować szczegółowy plan działań dla robota, ale dla tej konkretnej sytuacji.

Jednym z przejawów inteligencji jest zdolność do planowania swych działań. Im horyzont planowania dłuższy, a postawione zadanie trudniejsze lub bardziej abstrakcyjne, tym inteligencja musi być wyższa. W robotyce wyróżnia się trzy formy planowania. Planowanie ścieżki robota określa drogę, po której robot ma się przemieścić. Planowanie trajektorii wskazuje, gdzie na ścieżce robot ma się znaleźć w określonym czasie. Wreszcie planowanie zadań określa czynności (akcje), jakie robot powinien wykonać, by zrealizować zadanie. Ta ostatnia forma planowania jest najtrudniejsza, ale też i najciekawsza. Pierwsze dwie, nazywane zbiorczo planowaniem ruchu [80], sprowadzają się do wyznaczenia matematycznej funkcji określającej drogę od aktualnie zajmowanej pozycji do celu, z ominięciem przeszkód. Zazwyczaj wykorzystuje się do tego metody optymalizacyjne albo interpolację.

Do planowania zadań potrzebny jest opis środowiska (świata) wyrażony w pewnym języku oraz program wnioskujący, który na podstawie tego opisu wygeneruje plan realizujący zadanie. Planowanie zadań odbywa się w przestrzeni stanów, która modeluje świat, w którym działa robot. Owa przestrzeń określa, jakie są możliwe stany środowiska (obiektów znajdujących się w nim), a czasem również stany robota (np. jego położenie, orientacja i prędkość). Do planowania wymagany jest opis stanu początkowego i pożądanego stanu końcowego, a ponadto potrzebny jest algorytm, który znajdzie sekwencję akcji zmieniających stan początkowy w końcowy [88, 122]. Akcje przekształcające stan świata mogą być traktowane jako funkcje przejścia dla stanów tego świata. Dodatkowo mogą być narzucone ograniczenia na stany pośrednie bądź może być sformułowane kryterium optymalności planu, tzn. funkcjonał określający pod jakim względem plan ma być najlepszy.

Najbardziej znanym planerem (i jednocześnie językiem opisu) jest STRIPS [56, 122]. Sposób opisu stanu, który zastosowano w STRIPS, wykorzystywany był przez wiele innych planerów. Celem STRIPS było przekształcenie początkowego stanu świata w końcowy, za pomocą dostępnych akcji. Akcja mogła być wykonana jedynie, gdy były spełnione warunki początkowe (ang. preconditions) dla niej, i zmieniała stan świata zgodnie z definiującymi ją efektami zwanymi warunkami końcowymi (ang. postconditions). Stany zadania, początkowy i końcowy, były określane za pomocą zbioru warunków, które w tych stanach powinny być spełnione. Stany były opisywane za pomocą rachunku predykatów pierwszego rzędu [122], natomiast robot

operował w tzw. świecie klo cków, a więc w wielce uproszczonym modelu środowiska rzeczywistego. Co więcej, środowisko to było deterministyczne, w pełni obserwowalne i nie działały w nim inne agenty prócz robota. Założono zamknięty model świata, tzn. wszystkie warunki podstawowe, które nie zostały explicite wymienione jako prawdziwe uznawano jako fałszywe. W planerze ADL zrezygnowano z tego założenia – wartość logiczna niewymienionych warunków podstawowych traktowana była jako nieznana [122]. Później te ograniczenia zostały zniesione, a model świata stawał się coraz bardziej zbliżony do rzeczywistego.

STRIPS jest warty wspomnienia nie tylko ze względów historycznych, ale przede wszystkim dlatego, że większość późniejszych języków planowania bazowała na tym języku. W szczególności obecnie najbardziej popularna rodzina języków mających w swych nazwach akronim PDDL (ang. Planning Domain Description Language) wywodzi się od STRIPS. PDDL [61] stał się rodzajem standardu w dziedzinie planowania zadań. Języki te dzielą zadanie na dwie części: 1) opis dziedziny oraz 2) opis problemu. Opis dziedziny jest rodzajem ontologii określającej hierarchię typów obiektów i obiektów, sparametryzowane akcje, które mogą być realizowane, oraz predykaty określające fakty dotyczące dziedziny. Natomiast opis problemu zawiera obiekty znajdujące się w świecie robota, stan początkowy świata oraz opis stanu końcowego. Planery, które korzystają z opisu zadania w języku PDDL wytwarzają albo w pełni uporządkowane plany TOP (ang. totally ordered plan) albo częściowo uporządkowane POP (ang. partially ordered plan). W pierwszym z tych przypadków kolejność zaplanowanych akcji jest uporządkowana liniowo i stanowi sekwencję, w drugim, kolejność niektórych czynności nie jest wskazana, w szczególności mogłyby być wykonane równolegle. Późniejsze modyfikacje języka PDDL wprowadzały możliwość występowania zdarzeń, które zostały wywołane przez inne agenty działające w świecie. Ponadto prócz akcji wywołujących dyskretne zmiany stanu wprowadzono takie, które działały z czasem ciągłym. Pojawiły się też probabilistyczne warianty PDDL (PPDDL), które przypisywały wynikom akcji prawdopodobieństwo sukcesu. Język RDDL (ang. Relational Dynamic influence Diagram Language) wprowadził do planowania częściową obserwowalność stanu. W języku tym można wyrazić częściowo obserwowalne decyzyjne procesy Markova POMDP (ang. Partially Observable Markov Decision Processes). Zastosowanie procesów decyzyjnych Markova do podejmowania decyzji w obliczu niepewności jest trudne ze względu na olbrzymią liczbę możliwych stanów, więc wprowadzane są ograniczenia, które umożliwiają znalezienie planu w skończonym czasie [54]. Powyższe rozszerzenia podstawowego języka PDDL zwiększają skuteczność wygenerowanych planów – innymi słowy, poprawne wykonanie planu w rzeczywistym środowisku staje się coraz bardziej prawdopodobne.

Podstawowymi problemami w planowaniu jest duża liczba możliwości, które pojawiają się zarówno przy zwiększaniu liczby akcji możliwych do zastosowania, jak i wariantów zaistniałych sytuacji, oraz fakt, że pełny stan może nie być obserwowalny dla robota. Próbowano podejścia z wariantowością (ang. contingency planning), gdzie generowano plany na wszelkie ewentualności, natomiast w trakcie realizacji planu uzyskiwano dodatkową informację z układu percepcyjnego i na tej podstawie decydowano, który wariant wybrać. Obecnie raczej stosuje się przeplanowywanie. Jeżeli w trakcie wykonania planu zastana sytuacja odbiega od tej oczekiwanej planuje się ponownie uwzględniając nową sytuację. Niestety planowanie jest obliczeniochłonne, więc zajmuje dużo czasu. Oznacza to, że system powoli reaguje na zdarzenia zewnętrzne. Aby tego uniknąć, do planowania stosuje się algorytmy przerywalne w dowolnym momencie (ang. anytime algorithm) [72]. One zwracają aktualną, w momencie przerwania, wersję planu. Wersja ta

nie będzie doskonała. Gdyby algorytm miał więcej czasu, to by ją ulepszył. Niemniej jednak dłuższe planowanie oznaczałoby, że perfekcyjny plan będzie nieaktualny. Lepszy jest słaby plan na czas, niż najlepszy, ale za późno. Algorytmy tego typu stosowane są do planowania, w miarę zdobywania nowej wiedzy o środowisku [69]. Więcej wiedzy oznacza lepszy plan, ale nowej wiedzy nie można pozyskiwać w nieskończoność. Ponadto prowadzone są pracę nad planowaniem hierarchicznym, w którym akcje wyższego rzędu mogą być dekomponowane na akcje niższego rzędu [71]. Hierarchiczne sieci zadań HTN (ang. Hierarchic Task Network) powodują, że planowanie nie dotyczy jedynie przekształcania stanu świata, ale również dekompozycji akcji złożonych na proste. Stąd określa się to jako planowanie w przestrzeni zadań. Istnieje ponadto technika transformacyjnego tworzenia planów. Polega ona na budowaniu wstępnego planu realizacji zadania z bibliotecznych schematów. Następnie taki plan jest przekształcany i korygowany, aż uzyska ostateczną formę [53, 104].

Gdy określony jest już plan w postaci sekwencji akcji, które prowadzą do realizacji zadania, trzeba jeszcze wyznaczyć trajektorie ruchu robota. Wtedy stosowane jest planowanie trajektorii. Niestety na tym etapie może się okazać, że dla wybranej akcji nie istnieje dopuszczalna trajektoria ruchu, a więc ta akcja jest niemożliwa do wykonania. Wtedy trzeba plan zmodyfikować. Dlatego już w fazie generacji planu weryfikuje się wykonalność wybranych akcji. Ten rodzaj planowania nazywany jest łącznym planowaniem wykonania zadania i ruchu robota TAMP (ang. task and motion planning) [76, 151]. Należy zauważyć, że dochodzi tu do połączenia planowania dyskretnego, związanego z wyborem akcji w kolejnych chwilach, z generacją ciągłej w czasie trajektorii ruchu, a więc połączenia planowania dyskretnego i ciągłego.

Gdy już plan zostanie wygenerowany i rozpocznie się jego wykonanie, może się zdarzyć, że robot otrzyma kolejne polecenie, o wyższym priorytecie wykonania. Niestety w tej sytuacji metody znane z informatyki, polegające na odłożeniu stanu procesu na stos i wykonaniu procedury obsługi przerwania, nie mogą być zastosowane [51, 62]. Przykładowo, robot sprząta po posiłku, i w momencie gdy niesie talerz do zmywarki, ktoś dzwoni do drzwi. Aby gość nie odszedł, trzeba przerwać sprzątanie i otworzyć drzwi. Pojawienie się robota u drzwi z talerzem w ręku, uniemożliwi ich otwarcie. Wpierw trzeba odstawić gdzieś talerz. Po obsłużeniu gościa trzeba odzyskać talerz, by kontynuować sprzątanie. Widać tu, że potrzebne są dodatkowe czynności zawieszające realizację poprzedniego zadania, a potem jego kontynuację. Potrzebne jest dodatkowe planowanie. Co więcej, łańcuch przerwań kolejno wszczynanych zadań może być długi. Rozwiązanie tego problemu jest otwartym zagadnieniem badawczym.

Języki typu STRIPS, ADL czy PDDL umożliwiają określenie faktów dotyczących zarówno środowiska jak i zadania, które ma być zrealizowane – służą do reprezentacji wiedzy dla celów wnioskowania. Ta wiedza musi być przetworzona przez program wnioskujący, czasami zwany maszyną wnioskującą lub generatorem planów. Maszyna wnioskująca przetwarza specyfikację wyrażoną w jednym z wymienionych języków na plan [142]. Osobnym problemem jest to, że robot może nie być jedynym agentem działającym w środowisku, a więc wtedy jego system percepcyjny musi być w stanie przetworzyć odczyty z czujników na symboliczną reprezentację stanu świata – nazywa się to problemem kotwiczenia (ang. anchoring problem) [42]. Najczęściej po wykryciu takiej niespodziewanej zmiany stanu świata plan musi być uaktualniony.

Metody wnioskowania używane w robotyce niekiedy dzielone są na dwie szerokie kategorie: wnioskowanie logiczne oraz wnioskowanie probabilistyczne [10]. To pierwsze zazwyczaj oparte jest na rachunku predykatów pierwszego rzędu, natomiast to drugie na bayesowskiej teorii prawdopodobieństwa.

Ponieważ do wnioskowania zawsze używa się jakiejś logiki, ściślejszym jest podział na: wnioskowanie oparte na ścisłych faktach i regułach, wnioskowanie probabilistyczne oraz wnioskowanie posybilistyczne. Te dwie ostanie formy wnioskowania są zbiorczo zwane rozumowaniem w warunkach niepewności [74]. W przypadku wnioskowania probabilistycznego mamy do czynienia z wielkościami przyjmującymi pewne wartości z różnym prawdopodobieństwem, które określone jest na podstawie częstości występowania, natomiast gdy wnioskowanie odbywa się na podstawie informacji o nieprecyzyjnym znaczeniu mamy do czynienie z rozumowaniem przybliżonym [74]. Brak precyzji może dotyczyć zarówno faktów (np. nieprecyzyjne pomiary lub nieprecyzyjny opis sytuacji) lub reguł (np. zależności między zmiennymi nie są pewne). Należy zwrócić uwagę, że we wnioskowaniu probabilistycznym zdarzenie, które może wystąpić, zdefiniowane jest precyzyjnie, jedynie jego wystąpienie jest niepewne. Natomiast w rozumowaniu posybilistycznym samo zdarzenie jest określone w sposób nieprecyzyjny. Do tego dochodzi jeszcze możliwa niekompletność informacji niezbędnej do wnioskowania, nie wspominając o możliwości uzyskiwania informacji sprzecznych.

Nawet dla wnioskowania opartego na ścisłych faktach i regułach podstawowym problemem jest to, że implementacja tych form wnioskowania w pełnym zakresie czyni przetwarzanie danych nieefektywnym, więc potrzebne są pewne zawężenia, by wnioskowanie stało się wydajne. Rachunek predykatów pierwszego rzędu jest nierozstrzygalny (ang. undecidable), czyli maszyna przetwarzająca napisy nie jest w stanie rozstrzygnąć, czy dowolne napisy przetwarzanego języka są prawdziwe czy nie. Dlatego często korzysta się z języków o ograniczonych możliwościach, takich ja wymienione już STRIPS, ADL czy PDDL. W matematyce istnieje rodzina języków reprezentowana zbiorczą nazwą logik opisowych DL (ang. Description Logic). Wprawdzie języki te ograniczają reprezentację świata, ale są rozstrzygalne i obliczeniowo do zaakceptowania. Jeżeli liczba obiektów w rozpatrywanym świecie jest skończona, to można zastąpić logikę pierwszego rzędu logiką zdań, jednak kosztem wprowadzenia olbrzymiej liczby zdań opisujących ten świat. Niemniej jednak logika zdań jest rozstrzygalna, więc w skończonym czasie można dzięki niej rozstrzygnąć rozpatrywany problem.

Jednym z podstawowych problemów przy wnioskowaniu jest zapis zmian zachodzących w świecie przy wykonaniu pojedynczej akcji. Zwane jest to problemem tła (ang. frame problem) [122]. Przykładowo, jeżeli robot wyjął z szafki butelkę, to pozostałe przedmioty znajdujące się w tej szafce nie zmieniły swoich położeń – oczywiście przy założeniu, że robot manipulując jednymi przedmiotami nie strąca innych. Język opisujący zmianę stanu na skutek wykonania pojedynczej akcji powinien wymagać jedynie zapisu zmian, które nastąpiły w świecie, a nie ponownego opisu wszystkich relacji, które w tym świecie zachodzą. Na to się nakładają rozbieżności między posiadaną przez robota bazą wiedzy a stanem faktycznym występującym w środowisku, np. wskutek działań innych agentów. Ponadto logiki dwuwartościowe nie uwzględniają stopnia zachodzenia pewnych relacji. Tym zajmuje się logika rozmyta [48, 74], która jest jedną z logik wielowartościowych. Inne logiki tego typu uwzględniają, że fakty mogą być prawdziwe lub nie, ale również nieznane. Powo duje to niemożność stosowania reguły wyłączonego środka.

Wnioskowanie na podstawie wiedzy niepełnej jest możliwe, ale im ta niepewność jest większa, tym trudniej jest to robić jedynie na podstawie reguł logiki opartej na faktach pewnych.

By zwiększyć użyteczność wnioskowania, w takich sytuacja lepiej zastosować metody probabilistyczne (np. podejścia bayesowskie, teorię konfirmacji bądź teorię Dempstera-Shafera) lub posybilistyczne (np. wnioskowanie rozmyte).

Prawdopodobieństwo odnosi się tu do tego, czy dany fakt jest prawdziwy. Stosując sieci bayesowskie bądź procesy decyzyjne Markova można wywnioskować prawdopodobieństwo zdarzenia. Sieci bayesowskie powstają przez narysowanie grafu acyklicznego, którego węzły reprezentują zmienne losowe. Łuki skierowane łączą węzły reprezentujące zmienne zależne. Jeżeli wybrana zmienna jest warunkowo zależna od innych zmiennych, to węzły reprezentujące te zmienne stanowią poprzedniki w grafie węzła odpowiadającego wybranej zmiennej. Dzięki takiemu przedstawieniu zależności łatwiej jest operować na wycinkach grafu, by ustalić prawdopodobieństwo wynikowe. Sieci takie mogą być stosowane zarówno do wyjaśniania przyczyn obserwowanych efektów (diagnostyka) jak i określenia prawdopodobieństwa powstania efektów gdy znane są przyczyny (określanie związków przyczynowych). Dla zmiennych zależnych od czasu, opisujących stan procesu, posiadających własność Markowa, powstają dynamiczne sieci bayesowskie. Własność Markowa wymaga, by stan następny w czasie zależał od stanu aktualnego, ale nie od jego poprzedników, czyli stan następny jest warunkowo niezależny od stanów poprzedzających stan aktualny. W takich sieciach wnioskowanie przebiega szybko.

Predykaty opisujące stan przestrzenny środowiska uzupełniane są o zależności czasowe. Przykładowo może być potrzeba, by zaznaczyć, że jedna akcja musi poprzedzać inną lub że dwie sytuacje muszą zachodzić jednocześnie. Taki opis umożliwia algebra interwałowa (ang. interval algebra). W tym przypadku planowanie polega na poszukiwaniu takiego usytuowania akcji w czasie, by spełnić narzucone ograniczenia czasowe. Tego typu problemy rozwiązywane są przez sprowadzenie tak postawionego zagadnienia do problemu spełniania ograniczeń CSP (ang. Constraint Satisfaction Problem), a następnie stosuje się standardowe algorytmy rozwiązujące takie problemy [122]. Jeżeli wymagane jest ustalenie konkretnego czasu rozpoczęcia i zakończenia poszczególnych akcji do planowania stosuje się harmonogramowanie [29]. Istnieją też formalizmy łączące przedziały czasowe i punkty na osi czasu [73]. Niemniej jednak planowanie z zastosowaniem tak skomplikowanych opisów świata jest zagadnieniem obliczeniowo trudnym.

Ponieważ zazwyczaj stan środowiska jest tylko częściowo obserwowalny, natomiast proces decyzyjny jest sekwencyjny, to planowanie można przedstawić jako częściowo obserwowalny decyzyjny proces Markowa POMDP (ang. Partially Observable Markov Decision Process) [75]. Jest to probabilistyczny automat skończony, w którym każdej trójce (stan aktualny, akcja, stan następny) przyporządkowano wartość liczbową nagrody. Z przejściem między stanem aktualnym i następnym, pod wpływem konkretnej akcji, związane jest jego prawdopodobieństwo. Planowanie polega na maksymalizacji sumy nagród wskutek wykonywania sekwencji akcji. Ponieważ stan środowiska nie jest w pełni obserwowalny, to musi być odtwarzany na podstawie obserwacji. Związek miedzy stanem i obserwacją też jest probabilistyczny. Niestety to w istotny sposób komplikuje wnioskowanie, czyniąc go nieefektywnym. Dlatego stosuje się uproszczenia tego modelu [76].

W przypadku stosowania teorii zbiorów rozmytych opis zaistniałych sytuacji jest niepewny [48, 74]. Dana sytuacja zachodzi do pewnego stopnia (np. zmierzona temperatura do pewnego stopnia określana jest jako ciepła, a do pewnego stopnia jako gorąca – może to wynikać z subiektywnych odczuć obserwatora lub eksperta). Dlatego w teorii zbiorów rozmytych przypisuje się stopień przynależności elementu (np. zmierzonej temperatury) do danego zbioru – stopień ten jest zawarty w przedziale od 0 do 1, ale nie wynika on z częstości zjawiska, a więc nie ma charakteru probabilistycznego. Baza reguł łączy rozmyte przesłanki z rozmytymi wnioskami – zazwyczaj konstruowana jest przez ekspertów na podstawie ich intuicji popartej bogatym doświadczeniem, stąd brak precyzji określeń. Najczęściej

wnioskowanie rozmyte składa się z matematycznych reguł dotyczących: rozmywania (ang. fuzzyfication), czyli określenia stopnia przynależności elementu do poszczególnych zbiorów rozmytych, agregacji, czyli wyznaczania na podstawie stopni przynależności elementów należących do różnych uniwersów siły działania (ang. firing) poszczególnych reguł znajdujących się w bazie, −skalowania lub przycinania, by wyznaczyć siłę wniosku, akumulacji tak zmodyfikowanych wniosków wynikających z poszczególnych reguł oraz wyznaczenia ostatecznej wartości ostrej (ang. defuzzyfiction), w sumie tworzących przepis na wyznaczenie ostatecznego wniosku – najczęściej decyzji bądź sterowania.

Pomimo prób integracji różnych podejść do planowania [64] nie istnieje jedna zbiorcza forma opisu uwzględniająca wszystkie powyższe zagadnienia. Ponadto jednym z podstawowych problemów przy wykonaniu planu jest rozstrzygnięcie, czy obserwowany obiekt jest tożsamy z tym występującym w bazie wiedzy, a więc i w planie. W takiej sytuacji tworzona jest reprezentacja stanów odzwierciedlających przekonania (ang. belief) robota o stanie świata. Przykładowo, jeżeli robot pozostawił zielony kubek w szafce w kuchni, a teraz widzi zielony kubek na stole w pokoju, to musi rozstrzygnąć, czy oba kubki są tożsame, czy to są dwa różne, acz podobne egzemplarze. W tej sytuacji próbuje się odwoływać do planowania probabilistycznego [16]. Ponadto nie wszystkie obiekty są zawsze widoczne, a jeżeli nawet są w zasięgu wzroku robota, to niekoniecznie są dla niego osiągalne. Kolejnym problemem jest rozróżnienie tego, co jest istotne, od tego, co nie. Nieograniczone gromadzenie wiedzy doprowadzi do przepełnienia pamięci oraz nieefektywnego przeszukiwania ogromnej bazy wiedzy. Stąd powinna być gromadzona wiedza potrzebna jedynie do rozwiązania aktualnego zadania, ale to czyni robota i jego sposób planowania mało ogólnym. Niestety wszystkie te problemy oraz wiele innych, o których nie było tu mowy, oznaczają konieczność prowadzenia dalszych badań, by stworzyć inteligentnego robota potrafiącego rozumować stosując wiedzę symboliczną.

Prócz wnioskowania dotyczącego realizowanego zadania, roboty powinny doskonalić wykonanie powtarzalnych czynności. Stąd intensywne prace nad uczeniem maszynowym [38]. Historycznie oprogramowanie komputerów wykorzystywało algorytmy, które określały kolejne kroki przetwarzania danych. Zadaniem programisty było stworzenie precyzyjnego algorytmu determinującego, co komputer ma zrobić i w jakiej kolejności. Uczenie maszynowe umożliwia odejście od tego żmudnego sposobu tworzenia oprogramowania. Tutaj algorytm uczący, na podstawie olbrzymiej liczby przykładów, uczy się wykonywania pożądanego zadania przez modyfikowanie wag połączeń w sieci. Tak więc, ustalanie sekwencji czynności komputera zostało zastąpione strojeniem wag. Uczenie maszynowe wykorzystuje sieci, które się samodoskonalą w wykonywaniu postawionego im zadania na podstawie dostarczanych danych. Dane te służą określeniu modelu, a dokładniej związku między danymi a rezultatem. Zazwyczaj można wyróżnić dwa etapy pracy sieci: uczenie i wnioskowanie. W pierwszym na podstawie danych treningowych sieć uczy się wykonywania swego zadania, a drugim realizuje to zadanie. Zasoby potrzebne do uczenia nie są potrzebne w trakcie realizacji zadania.

Wyróżnia się kilka sposobów uczenia: nadzorowane (ang. supervised), nienadzorowane (ang. unsupervised), częściowo nadzorowane (ang. semi-supervised), ze wzmacnianiem (ang. reinforcement learning) [152]. Jeżeli dane uczące są zaetykietowane, a więc znane jest, jaki rezultat sieć powinna wytworzyć

dla tych danych, to mamy do czynienia z uczeniem nadzorowanym. Jeżeli rezultat nie jest z góry znany, to takie uczenie nazywamy nienadzorowanym. Jeżeli tylko część danych uczących jest zaetykietowana, to mamy do czynienia z uczeniem częściowo nadzorowanym, a więc metodą pośrednią między poprzednio wymienionymi metodami skrajnymi. Niezależnie od zastosowanej metody uczenia sieci neuronowe różnią się architekturami [3, 123]. Ich liczność uniemożliwia dokładne omówienie tego zagadnienia w tym artykule.

Uczenie nadzorowane wykorzystywane jest do klasyfikacji (rozpoznawania obiektów) lub przewidywania wartości funkcji na podstawie jej argumentów – zazwyczaj bardzo wielu. Natomiast uczenie nienadzorowane używane jest do poszukiwania struktury danych wejściowych. Sieć wyodrębnia cechy danych. Na podstawie wartości tych cech dokonuje klasyfikacji danych. W związku z tym uczenie nienadzorowane używane jest do klasteryzacji danych, wykrywania anomalii, asocjacji lub filtrowania. W tym ostatnim przypadku stosuje się autoenkodery, które dokonują wpierw kompresji danych wejściowych, by uzyskać zbiór cech, na podstawie którego odtwarzany jest zbiór danych pierwotnych – oczywiście w tym procesie odtworzenie nigdy nie jest akuratne.

Ponieważ etykietowanie jest zarówno czasochłonne, jak i kosztowne, a co więcej nie zawsze znany jest pożądany rezultat działania sieci, metody uczenia nienadzorowanego są często stosowane. By poprawić ich działanie i jednocześnie nie ponosić zbyt wielkich kosztów procesu uczenia, stosuje się uczenie częściowo nadzorowane. Przykładem sieci, która wykorzystuje tę formę uczenia jest sieć GAN (ang. Generative Adversarial Network), w której generator produkuje nowe dane przypominające dane oryginalne, natomiast dyskryminator próbuje ocenić, czy ma do czynienia z danymi oryginalnymi czy wygenerowanymi. W każdej iteracji dzięki dodatniemu sprzężeniu zwrotnemu sieci generatora i dyskryminatora się doskonalą w wykonywanych przez siebie zadaniach. Dzięki temu sieci GAN mogą być wykorzystywane do detekcji anomalii [148]. W przypadku sieci neuronowych uczenie nadzorowane prowadzone jest przez wzmacnianie wag połączeń proporcjonalnie do różnicy między pożądaną aktywacją i aktualną. Różnica ta zwana jest błędem. Dokonuje się tego na podstawie iteracyjnej optymalizacji funkcji celu zbudowanej na bazie wspomnianych różnic. Zazwyczaj stosuje się wsteczną propagację błędu (ang. backpropagation) zaczynając od warstwy wyjściowej sieci, a kończąc na warstwie wejściowej. Natomiast uczenie nienadzorowane wykorzystuje regułę Hebba [68], która mówi, iż waga połączenia neuronów, których działanie jest skorelowane, powinna ulegać wzrostowi, jeżeli zachodzi relacja przyczynowo-skutkowa między aktywnością tych neuronów. Oczywiście brak takiej korelacji prowadzi do osłabienia połączenia. Uczenie nienadzorowane działa na podstawie przyjętej metryki podobieństwa danych.

Uczenie ze wzmacnianiem, gdzie dane uczące nie są zaetykietowane, wykorzystuje znajomość nagrody związanej z wykonaniem czynności na podstawie tych danych wejściowych. Algorytm uczenia dąży do maksymalizacji skumulowanych nagród. Takie algorytmy są często używane w robotyce do uczenia się podejmowania decyzji w miarę eksploracji środowiska, np. nawigacji w nieznanym otoczeniu. Uczenie ze wzmacnianiem uczy sieć przewidywać kolejny krok działania w taki sposób, by końcowa nagroda była najwyższa. W trakcie działania robot uczy się na podstawie przeszłych swoich działań oraz eksperymentuje z nowymi strategiami, dzięki czemu może się doskonalić.

Rozwój badań nad sieciami neuronowymi miał swoje wzloty i upadki. Od mniej więcej 2012 r. badania te znów przeżywają rozkwit. Spowodowane jest to opanowaniem technologii zrównoleglania obliczeń. Odkąd pojawiły się procesory graficzne GPU (ang. Graphic Processing Unit) prowadzenie dostatecznie

szybko obliczeń, które w przypadku sieci neuronowych daje się łatwo zrównoleglić, umożliwiło tworzenie ogromnych sieci nazywanych głębokimi (ang. Deep Learning Neural Networks). Sieci te uczą się na milionach danych, dzięki czemu są w stanie z dostateczną pewnością realizować postawione przed nimi zadania. Typowym przykładem jest sieć AlphaGo, która rozgrywając partie go ze swoją repliką, nauczyła się grać tak dobrze, że była w stanie pokonać arcymistrza [133].

Dotychczas głównym polem zastosowania uczenia maszynowego w robotyce była percepcja, a w szczególności rozpoznawanie obrazów oraz sygnałów mowy [79], ale powoli się to zmienia. Obecnie pracuje się także nad samodoskonalącymi się robotami, które dostosowują swoje zachowania do środowiska, w którym działają. Firma Google stworzyła Brain Team [2], zespół którego zadaniem jest zbadanie wpływu uczenia maszynowego na robotykę oraz robotyki na uczenie maszynowe. W tym celu wyposażono duże laboratorium w tzw. farmę robotów. Roboty te uczyły się chwytania przedmiotów i przekazywały sobie nawzajem wiedzę, którą zdobyły na temat przemieszczania i chwytania obiektów widzianych przez siebie [91]. Każdy z robotów wykorzystywał jedną kamerę umieszczoną na statywie obok manipulatora. Konwolucyjna sieć neuronowa uczyła się chwytania obiektów. Założono, że układ oko-ręka nie będzie kalibrowany, więc dostosowanie ruchów do uzyskiwanego obrazu także podlegało uczeniu. Uczenie prowadzono w ciągu dwóch miesięcy wykorzystując od 6 do 14 robotów, dzięki czemu dane uczące składały się z 800 tysięcy prób chwycenia obiektów. W drugim eksperymencie wykorzystano 9 robotów innego typu, które wykonały 900 tysięcy prób, ale im przekazano wiedzę zdobytą w pierwszym eksperymencie. Okazało się, że transfer wiedzy wspomaga uczenie, ale nadal potrzeba olbrzymiej ilości dodatkowych danych. Wprawdzie w obu eksperymentach wykorzystywano różne manipulatory, ale w obu przypadkach miały one po 7 stopni swobody oraz chwytaki dwupalczaste. Obiekty, których różnych typów użyto 1100, wyjmowane były z pojemnika, w którym zgromadzone były w sposób nieuporządkowany, tak że częściowo się przesłaniały, a co więcej ich chwytanie wymagało przesuwania innych przedmiotów. Wykorzystano uczenie bez nadzoru. To, czy próba uchwycenia się powiodła, ustalane było na podstawie stopnia zamknięcia chwytaka oraz różnicy w wyglądzie obrazu pojemnika po uchwyceniu przedmiotu i ponownym jego wrzuceniu przez robota do pojemnika. Początkowo robot nie miał wiedzy na temat obiektów, które będzie widział. Przeprowadzone eksperymenty wskazują, że wiedza zdobyta przez robota jednego typu w umiarkowany sposób wspomaga uczenie podobnego robota, a co więcej ilość danych, które są potrzebne do uczenia chwytania bez nadzoru musi być ogromna. Zebranie tych danych jest procesem niezmiernie czasochłonnym. Niemniej jednak ten niealgorytmiczny sposób podejścia do chwytania wykazał, że roboty nauczyły się różnych strategii chwytania obiektów sztywnych i miękkich. Obiekty sztywne były chwytane poprzez ustawienie palców chwytaka po przeciwnych stronach obiektu, natomiast w przypadku obiektów miękkich chwytak był wgniatany w obiekt i chwytał go przez uszczypnięcie.

W sztucznej inteligencji istnieją dwa podstawowe nurty. Pierwszy bazujący na wnioskowaniu symbolicznym i drugi opierający się na sztucznych sieciach neuronowych. Ten drugi, obecnie jest niezmiernie popularny, ponieważ wykazał swoją wyższość przy zastosowaniu do zadań, z którymi ten pierwszy miał istotne kłopoty, np. rozpoznawanie obrazów bądź mowy. Niemniej jednak należy zwrócić uwagę, że sieci neuronowe, a w szczególności głębokie sieci neuronowe, mają istotne wady. Szerzej rzecz ujmując, sztuczne sieci neuronowe doskonale się sprawdzają w klasyfikacji, gdzie dominuje porównanie ze wzorcem, natomiast dużo gorzej im idzie, gdy muszą znaleźć korelacje między nieprzystającymi do siebie zdarzeniami, np.

w diagnostyce uszkodzeń. Ponadto wytrenowana sieć rozwiązuje jedynie zadanie, którego ją nauczono. Zmiana zadania zazwyczaj wymaga ponownego uczenia od początku, a często również zmiany struktury sieci. Koszt trenowania jest wysoki, ponieważ do uczenia potrzeba olbrzymich ilości różnorodnych danych przykładowych, a co więcej przy uczeniu nadzorowanym muszą to być dane zaetykietowane, a proces etykietowania jest dość pracochłonny. Próby douczania takich sieci dla nowych danych często kończą się pogorszeniem wykonywania zadania dla poprzednich kategorii danych. Uczenie głębokie (ang. deep learning) niewątpliwie odniosło wielki sukces w wielu dziedzinach. Niemniej jednak uważa się, że w zastosowaniach krytycznych jego użycie jest ryzykowne. Podstawowym problemem jest brak wytłumaczenia (ang. explainability), dlaczego sieć daje takie rezultaty, jakie daje. W tej sytuacji nasza pewność, co do działania systemu, przestaje być oparta na rozumieniu, a zaczyna wynikać z wiary. Co więcej, w trakcie douczania sieci wykonywania nowego zadania może ją dotknąć gwałtowana amnezja – zapomni tego, czego się nauczyła wcześniej [119]. Próbą rozwiązania tego problemu jest stworzenie wyjaśnialnej sztucznej inteligencji (ang. explainable AI).

Wymienione problemy są obecnie przedmiotem intensywnych badań. Rozwiązanie tych problemów upatruje się w ściślejszym odwzorowywaniu sposobu działania mózgu niż to ma miejsce w sztucznych sieciach neuronowych powszechnie stosowanych. Jednym z podejść jest zastosowanie sieci typu ART (ang. adaptive resonance theory) [35, 65], które kategoryzują informacje jednocześnie na podstawie oczekiwanego rezultatu obserwacji oraz danych sensorycznych, tak jak to się dzieje w ludzkim umyśle, który stara się dopasować to co widzimy lub słyszymy do naszych oczekiwań. Sieci ART umożliwiają zachowanie odpowiedniej równowagi między zdobywaniem nowej wiedzy i stabilnością starej.

Algorytmy ewolucyjne dążą do wyboru najlepszego rozwiązania postawionego zagadnienia naśladując procesy ewolucyjne, stąd i stosowana terminologia zaczerpnięta jest z tej używanej do opisu doboru naturalnego [5]. Algorytmy ewolucyjne można uznać za jedną z technik optymalizacji albo za metodę stopniowego doskonalenia rozwiązania. Każde rozwiązanie zagadnienia stanowi osobnika. Ów osobnik reprezentowany jest chromozomem składającym się z genów. Algorytm ewolucyjny działa na populacji osobników. Dla każdego osobnika można obliczyć stopień jego przystosowania do środowiska. Służy temu funkcja przystosowania, która dobierana jest do rozpatrywanego zagadnienia. Algorytm ewolucyjny z pokolenia na pokolenie dokonuje reprodukcji populacji, czyli wybiera osobniki, które będą stanowiły podstawę konstrukcji kolejnego pokolenia osobnikó. Następnie wykonuje operacje genetyczne na zreprodukowanej populacji: mutacje, czyli modyfikację pojedynczych genów w chromosomie, i krzyżowanie, czyli sklejanie części chromozomów uzyskanych z różnych osobników. Dalej dokonuje oceny osobników tak zmodyfikowanej populacji, po czym następuje sukcesja. Ocena osobników i sukcesja służą selekcji. Selekcja jest prowadzona tak, by osobniki lepiej przystosowane przechodziły do kolejnego pokolenia z wyższym prawdopodobieństwem niż te gorzej przystosowane. Niemniej jednak i te ostatnie mogą być reprodukowane, co umożliwia wyrwanie się rozwiązania z ekstremum lokalnego. To powoduje, że algorytmy genetyczne uznawane są za metody optymalizacji globalnej. Po etapie selekcji powyższe kroki są powtarzane znów od reprodukcji, aż spełnione zostanie kryterium stopu, kończące wykonanie algorytmu. Najbardziej wartościowy osobnik uznawany jest za rozwiązanie postawionego zagadnienia.

Ponieważ w naturze osobniki silniejsze lub inteligentniejsze są lepiej dostosowane do życia w środowisku, a to ulega ciągłym zmianom, to mówi się tu o adaptacji. Zdolność do

adaptacji jest jednym z przejawów inteligencji. Algorytmy ewolucyjne były stosowane do rozwiązywania bardzo różnych problemów, w szczególności wyłoniło się programowanie genetyczne, które stosowane było do ewolucyjnego tworzenia programów zamiast ręcznego ich pisania [85, 137]. Algorytm ewolucyjny rozpoczynał pracę od populacji osobników (programów) słabo rozwiązujących postawiony problem, a następnie sprawdzał, jak osobniki kolejnych populacji dają sobie z tym problemem radę. Swego czasu pokładano w tym sposobie programowania wielkie nadzieje i prorokowano zmierzch klasycznej informatyki. Tak się jednak nie stało – nadal programy pisane są przez programistów.

Inteligencja roju jest cechą emergentną, czyli wyłaniającą się na skutek samoorganizowania, współdziałania i lokalnego pośredniego bądź bezpośredniego komunikowania się wielu prostych autonomicznych agentów wchodzących w skład zdecentralizowanych systemów [12, 13]. Samoorganizacja jest procesem, w którym wewnętrzna organizacja systemu złożonego z autonomicznych agentów wchodzących w interakcje ze swym otoczeniem samoistnie wzrasta, bez udziału koordynatora. Istotą jest kolektywne działanie prostych jednostek [113]. Symulacyjne badania nad tego typu systemami początkowo były prowadzone pod szyldem sztucznego życia (ang. artificial life). Sam termin „sztuczne życie” został spopularyzowany przez Christophera Langtona [86] i odnosi się do życia stworzonego przez człowieka, a nie przez naturę [87]. Wprawdzie prace nad tą dziedziną dotyczyły również związków chemicznych, ale większość badań poświęconych było aspektom matematycznym i symulacjom komputerowym wyimaginowanych systemów składających się z prostych automatów. W szczególności usiłowano odtworzyć systemy biologiczne. Do chwili obecnej nie udało się stworzyć niczego rzeczywiście żywego w sensie biologicznym. Nie wiadomo, czy to dobrze czy źle, ale sam Langton miał wątpliwości, czy nie stworzy to nowych niebezpieczeństw.

W 1970 r. John Conway opracował grę symulacyjną nazwaną Life [58], w której na dwuwymiarowej nieskończonej płaszczyźnie podzielonej na kwadratowe komórki umieszcza się pewną liczbę komórek żywych. Komórki tworzą rodzaj szachownicy, a więc każda z nich ma osiem sąsiadek. Komórka z dwoma lub trzema bezpośrednimi sąsiadkami pozostaje żywa, komórka martwa z trzema żywymi sąsiadkami staje się żywa (reprodukcja), natomiast wszystkie pozostałe komórki żywe umierają (wskutek przeludnienia). Okazało się, że przy tych trywialnych regułach rządzących zachowaniem komórek, zależnie od stanu początkowego, można obserwować wielką różnorodność zachowań organizmów złożonych z komórek żywych – mogą one się rozrastać, oscylować, ginąć lub przemieszczać w różnych formacjach. Komórki stanowią niezwykle prosty model automatu – automatu komórkowego.

Prace nad samopowielającymi się automatami zostały jednak zainicjowane wcześniej, bo już pod koniec lat 40. ubiegłego wieku, przez Stanisława Ulama oraz Johna von Nemanna. Von Nemann zauważył, że jeżeli jeden automat ma stworzyć drugi, to ten pierwszy powinien być bardziej skomplikowany niż ten drugi, ponieważ powinien dysponować dodatkowymi środkami na tworzenie automatów [146]. Niemniej jednak natura tak nie działa. W toku ewolucji organizmy prostsze reprodukują się w taki sposób, że w konsekwencji powstają organizmy coraz bardziej skomplikowane. Rozwiązaniem tego problemu było odwołanie się do Maszyny Turinga [143], która na podstawie prostych inskrypcji jest w stanie tworzyć inskrypcje bardziej złożone. Wprawdzie z matematycznego punktu widzenia te prace są niezmiernie interesujące, ale dotychczas nie dały odpowiedzi na pytanie, jak skonstruować fizyczny automat samopowielający się, a w szczególności jak stworzyć takiego inteligentnego robota.

Inspirację do badań nad inteligencją rojów, pomijając kwestię reprodukcji, stanowi obserwacja owadów społecznych (ang. social insects), np. mrówek [63], termitów czy pszczół, które dysponują bardzo prostymi układami nerwowymi, ale zdolne są do współpracy, a w szczególności do tworzenia bardzo złożonych struktur, takich jak mrowiska, termitiery czy gniazda. Przykładowo, termitiery powstające na sawannach, gdzie latem jest niezmiernie gorąco, są tak skonstruowane, że ich wentylacja grawitacyjna zapewnia temperaturę i wilgotność wewnątrz kopca zapobiegającą usmażeniu się owadów zamieszkujących termitierę. Żaden z termitów nie dysponuje całościowym planem budowy kopca, niemniej jednak powstaje struktura spełniająca globalne oczekiwanie. Co więcej, termitiery są cały czas modyfikowane (poprawiane), by mikroklimat w nich panujący był odpowiedni. Należy zwrócić uwagę, że większość owadów społecznych porozumiewa się pośrednio przez stygmergię, czyli pozostawianie innym insektom znaków w środowisku (np. feromonów) [20]. Budowa termitiery stymulowana jest sygnałami pozyskiwanymi ze środowiska, stygmergią i oczywiście imperatywem wewnętrznym do wykonywania tej pracy.

Zainteresowanie rojami powodowane jest ich zaletami, które chcielibyśmy umieć odtworzyć w systemach technicznych. Zalety te są następujące: −każdy owad wykazuje proste zachowanie, co wymaga jedynie prostego układu sterowania, ale rój wytwarza złożone struktury bądź zachowania, −każdy owad ma ograniczone możliwości wpływania na środowisko, każdy owad ma ograniczone możliwości percepcyjne i poznawcze (kognitywne), −łatwo się adaptują do zmian zachodzących w środowisku, system jest odporny – eliminacja lub awaria niektórych jednostek nie naraża na fiasko funkcjonowania całego systemu.

Niestety mają one również poważne wady: rezultat działania systemu jest emergentny, a więc jest trudny do przewidzenia lub do zaprogramowania, wynik bazuje nie tylko na zachowaniach jednostki, ale także na interakcjach z innymi osobnikami i środowskiem, przez co jest trudny do przewidzenia, brak wiedzy o globalnym celu może prowadzić do stagnacji lub zakleszczenia.

Z punktu widzenia realizacji technicznej systemy o strukturze roju mają następujące cechy: nie wymagają centralnego planowania – nie potrzebują koordynatora, −mają rozproszoną strukturę, −jednostki komunikują się przez środowisko (stygmergia) –komunikacja bezpośrednia rodzi problem ze skalowalnością, bo przy wielu robotach trudno jest zorganizować komunikację wielu-do-wielu, −ma proste reguły zachowań indywidualnych, −wytwarza złożone zachowanie adaptacyjne systemu, są skalowalne – struktura układu sterowania każdego robota jest taka sama, niezależnie od liczby robotów, są elastyczne – roboty mogą być dodawane lub zabierane ze środowiska bez konieczności modyfikacji specyfikacji zadania, są odporne – nie tylko ze względu na redundancję jednostek, ale także ze względu na minimalistyczny projekt jednostki.

Gdyby udało się określić sposób konstrukcji prostych robotów, które poprzez interakcje z otoczeniem oraz wzajemną komunikację byłyby w stanie tworzyć pożyteczne struktury złożone, to byłby to bardzo atrakcyjny sposób tworzenia np. budowli – same mogłyby zespalać się w celu utworzenia np. mostu nad rzeką. Ciekawą próbą, w tym kierunku, było

zaprojektowanie ponad tysiąca robotów, które przemieszczając się po płaszczyźnie stale stykając się krawędziami były w stanie tworzyć konkretne kształty dwuwymiarowe [121]. Niestety, mimo licznych prac na ten temat, jedynie udało się opracować bardzo szczególne systemy zdolne do bardzo ograniczonych zachowań realizujących globalne oczekiwania, np. wspólne pchanie pudła [169], tworzenie formacji, wspólne patrolowanie lub agregowanie się w zespoły robotów w celu realizacji konkretnego celu. Tworzenie takich systemów zazwyczaj sprowadza się do konstrukcji wielu prostych robotów, a następnie weryfikowania, czy uda im się osiągnąć globalny cel. Jeżeli nie, to roboty są modyfikowane, a następnie powtarzany jest krok weryfikacyjny. Innymi słowy, takie systemy zazwyczaj tworzone są metodą prób i błędów.

Często w przypadku zadań złożonych i heterogenicznym składzie grupy wprowadzany jest element rozdzielający zadania elementarne między poszczególne roboty. Taki system zawierający roboty obserwacyjne, manipulujące i przemieszczające został stworzony w ramach projektu europejskiego Swarmanoid [46]. Aby wykonać zadanie polegające na przyniesieniu książki znajdującej się na półce w regale, roboty obserwacyjne musiały latając po pomieszczeniach znaleźć regał z książką, następnie dwa roboty przemieszczające musiały zanieść robota manipulującego do regału, by ten wspiął się na niego i zdjął książkę. Każdy z robotów miał niewielki zasięg swojej komunikacji radiowej, więc dodatkowo roboty musiały sobie stworzyć sieć komunikacyjną. Takie zadanie wymaga zaplanowanie jego wykonania i przydzielenie zadań elementarnych poszczególnym robotom. Przy rozdziale zadań do wykonania, można mieć wątpliwości, czy nadal mamy do czynienia z rojem. Nie zmienia to faktu, że mamy tu do czynienia z dużą grupą współpracujących robotów przy realizacji złożonego zadania, ale jest ono zadane z góry, a nie wyłania się samoistnie z interakcji między robotami dysponującymi prostymi algorytmami postępowania.

Interfejsy te konstruowane są ze względów terapeutycznych, ale także poznawczych. W tym drugim przypadku przede wszystkim chodzi o odkrycie tajników działania mózgu, ale niektórzy spodziewają się, że dzięki tym badaniom będzie można usprawnić działanie mózgu. Inni obawiają się, że doprowadzi to do transhumanizmu.

Od lat 60. ubiegłego wieku badane są elektroniczne interfejsy z mózgiem BMI (ang. Brain Machine Interfaces). Celem takiego interfejsu jest wytworzenie wzajemnego powiązania między mózgiem zwierzęcia lub człowieka oraz napędem manipulatora, sztucznej nogi lub obrazu na ekranie komputera, by w pętli sprzężenia zwrotnego wykorzystać wolicjonalną aktywność elektryczną mózgu do sterowania ruchami tego napędu [89]. Zwierzę lub człowiek korzysta zarówno z własnych receptorów, np. zmysłu wzroku, jak i stymulacji bezpośredniej poprzez elektrody wytwarzające wrażenie, że np. dotyka twardego lub miękkiego przedmiotu. W niektórych eksperymentach zamiast sterować jakimś urządzeniem technicznym pacjent może sterować własna kończyną, z którą wskutek wypadku utracił łączność przez własny obwodowy układ nerwowy. Intensywność tych badań stale zwiększa się od lat 90. XX wieku. Celem tych badań jest: ustalenie i wykorzystanie zasad działania i właściwości plastycznych mózgu oraz tworzenie nowych terapii przywracających mobilność i czucie pacjentom z ciężkimi niepełnosprawnościami.

Z punktu widzenia poznawczego głównym celem jest zbadanie właściwości fizjologicznych mózgu, w tym zdolność grup neuronów w korze czuciowo-ruchowej do kodowania informacji i wykazywania plastyczności podczas uczenia się zwierząt nowych zadań motorycznych. Niemniej jednak cel terapeu-

tyczny był pierwotny. Z powodzeniem wszczepia się obecnie implanty ślimakowe p ołączone z mikrofonem, by przywrócić słuch. W celu przywrócenia wzroku, zbadano pozytywnie, czy implanty umieszczane w korze wzrokowej są w stanie przywrócić zdolność do wykrywania światła. Stosowano również substytucję jednego zmysłu drugim. Elektrody umieszczone na plecach pacjenta były pobudzane przetworzonym obrazem z kamery, dzięki czemu pacjenci po 10 godzinach uczenia się korzystania z urządzenia byli w stanie poprzez czucie dotyku wykrywać obiekty znajdujące się w pobliżu. Istotny postęp w miniaturyzacji implantów pozwolił zwiększyć rozdzielczość implantów umożliwiając jednoczesne pobieranie i wysyłanie sygnałów z/do wielu neuronów. Dzięki temu zwierzęta były w stanie jedynie za pomocą aktywności swoich mózgów włączać urządzenia, a w niektórych przypadkach poruszać np. ramieniem robota. Na pacjentach, którzy musieli być poddani operacyjnemu leczeniu choroby Parkinsona, wykazano, że te same techniki, które były stosowane na zwierzętach, można stosować na ludziach, by uzyskać wzorce ruchowe na podstawie sygnałów podkorowych. Niestety istnieją problemy z biokompatybilnością wielokanałowych implantów mózgowych. Niemniej jednak wykazano, że za pomocą takich implantów można ustalić wzorce ruchowe i je później odtworzyć, co umożliwia sterowanie urządzeniami za pomocą myśli. Co więcej można też pobudzać odpowiednie rejony mózgu, by wytworzyć wrażenia haptyczne.

Prócz technik inwazyjnych stosuje się też interfejsy nieinwazyjne wykorzystujące sygnały EEG. W ten sposób, np. za pomocą otwierania i zamykania oczu można sterować prostym urządzeniem. Ta technika była też stosowana do sterowania wózkami inwalidzkimi oraz egzoszkieletami montowanymi na nogach. Interfejsy nieinwazyjne nie wymagały stosowania procedur chirurgicznych i nie są związane z ryzykiem zakażenia lub tworzenia się blizn wokół elektrod umieszczonych w mózgu. Niestety ich rozdzielczość jest niska, a jakość uzyskiwanych sygnałów niezbyt wysoka. Niemniej jednak techniki nieinwazyjne są preferowane, bo nie zagrażają pacjentowi. Istnieje też technika pośrednia, która wprawdzie wymaga otwarcia czaszki, ale elektrody umieszczane są na powierzchni mózgu, a nie są wprowadzane do niego. Istnieją też interfejsy oparte na technikach obrazowania wykorzystujących np.: −funkcjonalny MRI, gdzie mierzy się odpowiedzi chemodynamiczne mózgu, magnetoencefalografię, która mierzy pola magnetyczne indukowane przez elektryczną aktywność neuronów, −pomiar wykorzystujący promieniowanie świetlne w bliskiej podczerwieni, by mierzyć koncentrację we krwi oksyhemoglobiny i deokshemoglobiny.

Niestety te metody pomiarowe wymagają specjalnych stanowisk laboratoryjnych.

Ponieważ roboty muszą działać w środowisku naturalnym istotna jest prędkość reakcji na bodźce pochodzące z otoczenia. Podobnie, jak u zwierząt wyższych, w robotach kluczową rolę odgrywa koordynacja kończyn ze wzrokiem. W tym celu konstruuje się serwomechanizmy wizyjne [36, 135]. Największym problemem jest szybkie rozpoznanie obrazu – detekcja i lokalizacja pożądanego obiektu. Układ składający się z kamery, procesora i oprogramowania przetwarzającego obraz zazwyczaj działa zbyt powoli, by reagować na szybko poruszające się przedmioty. Tu postępy spodziewane są raczej dzięki ulepszonym urządzeniom przetwarzającym obrazy, a nie doskonalszym algorytmom. Ostatnio opracowana fotoniczna głęboka sieć neuronowa może analizować obrazy bez potrzeby stosowania modułów pamięci, przetwornika analogowo-cyfrowego oraz zegara taktującego, czego wymagają procesory elektroniczne [8]. Może rozpoznać obraz w mniej niż 570 pikosekund. Roz-

miar układu fotonicznego to 9,3 mm2. Klasyfikację liter p i d w zbiorze 216 liter sieć wykonała z dokładnością 93,8 %, natomiast liter a, t, p i d w zbiorze 432 liter dokonała z dokładnością 89,8 %. Konwencjonalna 190-neuronowa sieć dokonywała tego z dokładnością 96 % – oczywiście zabierało jej to dużo więcej czasu. Ta fotoniczna sieć musi zostać udoskonalona, by radzić sobie z bardziej skomplikowanymi obrazami, z jakimi mają do czynienia roboty.

Wizja Przemysłu 4.0 zakłada wykorzystanie Internetu Rzeczy (IoT), inteligentnych urządzeń oraz chmur obliczeniowych do produkcji wyrobów dostosowanych do indywidualnych potrzeb klienta. Ta wizja rozszerza się w naturalny sposób także na świadczenie usług zarówno publicznych jak i przez urządzenia zainstalowane w domach. Chmura obliczeniowa może wspomagać roboty w przetwarzaniu i gromadzeniu informacji, szczególnie jeżeli ilość informacji oraz złożoność algorytmów przetwarzania danych jest duża. Pomysł zintegrowania robotów z siecią IoT doprowadził do powstania koncepcji Internetu rzeczy robotycznych IoRT (ang. Internet-of-Robotic-Things) [134]. Inkorporacja robotów do Internetu rzeczy zwiększa możliwości ich współdziałania z innymi urządzeniami znajdującymi się w ich otoczeniu, poprzez zrozumienie, jakie są ich cele, oraz wykorzystanie czujników znajdujących się w środowisku, a przyłączonych do sieci. Z punktu widzenia IoT dodanie robotów umożliwia wykorzystanie aktywnego czucia, czyli wykorzystanie ruchomości robota do zebrania lepszych odczytów czujników. Roboty, urządzenia produkcyjne i produkty mają komunikować się przez sieć, dzięki czemu następuje efektywniejsze wykorzystanie zasobów produkcyjnych do zindywidualizowanego wytwarzania. Ponieważ u podłoża tej koncepcji tkwi wymiana informacji między rozproszonymi urządzeniami poprzez sieć, niezbędne jest zapewnienie odpowiedniego poziomu cyberbezpieczeństwa. Istotnym elementem tej wizji jest zastosowanie sztucznej inteligencji. Między innymi zakłada się samodoskonalenie działania systemu wytwarzania lub świadczącego usługi dzięki jego uczeniu się. Inkorporowanie robotów do sieci, prócz zalet, niestety ma też wady – naraża je na różne formy ataków cybernetycznych.

Przyczynami podatności systemów robotycznych na cyber-ataki mogą być [149]: połączenia z sieciami przewodowymi lub bezprzewodowymi, korzystanie z platform programowych podatnych na ataki (np. systemów operacyjnych zawierających dziury lub tylne wejścia (ang. backdoors)), stosowanie oprogramowania sterującego stworzonego bez uwzględnienia zabezpieczeń przeciwko atakom, adopcja niewłaściwych środków zabezpieczających przeciwko atakom, brak odpowiednich procedur zabezpieczających w trakcie interakcji personelu z systemem robotycznym (np. autentyfikacja, kodowanie wiadomości, autoryzacja, szkolenie operatorów). Ataki mogą być prowadzone przez: blokowanie łącz komunikacyjnych (np. przez ich zakłócanie lub spowodowanie odmowy świadczenia usług wywołane nadmiarowym ich żądaniem DoS (ang. denial of service)), przechwytywanie komunikacji, wstrzykiwanie do oprogramowania systemu wrogiego oprogramowania (np. wirusy, trojany), nieuprawnione zdobywanie informacji o sposobach dostępu do systemu, modyfikowanie przesyłanych informacji, nadmierne zużycie zasobów robota (np. wyczerpanie akumulatorów lub przeciążenie komputera sterującego), fizyczne uszkodzenie sprzętu wykorzystywanego przez system robotyczny lub zakłócanie działania jego czujników. Powodem ataków zazwyczaj jest albo chęć przejęcia kontroli nad systemem w celu upośledzenia jego funkcji lub pozyskiwanie w sposób nieuprawniony danych wrażliwych. Upośledzenie funkcji może polegać np. na zakodowaniu danych w celu uzyskania okupu w zamian za odkodowanie danych.

Współczesne roboty są sterowane komputerowo, więc ich oprogramowanie, jak widać z tego, co zostało napisane powyżej, podlega w dużej mierze tym samym zagrożeniom, co oprogramowanie innych systemów informatycznych. Oczywiście istnieją różnice, ale duża część zagrożeń jest wspólna, dlatego wiele metod ochrony systemów informatycznych przed atakami jest wykorzystywanych również przez robotyków. Modelowanie zagrożeń polega na stworzeniu abstrakcyjnego modelu oprogramowania w celu zidentyfikowania możliwości, celów oraz motywacji atakującego, tak aby w efekcie utworzyć katalog możliwych zagrożeń [131]. Proces modelowania zagrożeń ma prowadzić do identyfikacji i oceny zagrożeń dla firmy wykorzystującej oprogramowanie oraz określenia skutków ewentualnego ataku i do znalezienia środków zaradczych w przypadku ich wykrycia.

W pracy [127] podkreślono, że analiza zagrożeń wymaga stworzenia abstrakcyjnego modelu systemu oraz profili agresorów, biorąc pod uwagę zarówno ich cele jaki i metody działania. Aby taki model był przydatny do analizy zagrożeń bezpieczeństwa, powinien obejmować zarówno oprogramowanie, jak i osoby z niego korzystające [130]. Brak modelu użytkownika w istotny sposób utrudnia analizę problemów związanych z autentyfikacją, a w szczególności czyni kłopotliwym wskazanie możliwych metod przeprowadzenia ataku. Prace przeglądowe [78, 101, 127, 128] przedstawiają najbardziej popularne metody projektowania systemów informatycznych biorące pod uwagę zapewnienie cyberbezpieczeństwa. Większość przedstawianych metod koncentruje się na fazie formułowania wymagań dla projektowanego systemu oraz na jego specyfikacji.

Metoda modelowania zagrożeń STRIDE [78], [127] (nazwana tak od angielskich słów: Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, Elevation of privilege), opracowania w 1999 r., używana przez wiele lat przez firmę Microsoft, bierze pod uwagę szeroki repertuar możliwych zagrożeń. Są to: −udawanie użytkownika uprawnionego do korzystania z systemu, dzięki naruszeniu procedur sprawdzających autentyczność (autentyfikacja), −modyfikacja danych, czyli naruszanie ich integralności, −wypieranie się swoich działań (zazwyczaj jest to związane z modyfikacją logów), −naruszanie poufności danych, doprowadzanie do odmowy dostarczania usług przez wyczerpywanie zasobów (DoS) oraz zwiększanie swoich przywilejów w celu uzyskania nieuprawnionego dostępu do zastrzeżonych zasobów.

Analiza systemu prowadzona jest przez jego dekompozycję na podsystemy. Najczęściej stosuje się w tym celu diagramy przepływu danych DFD (ang. Data Flow Diagram). Diagramy te tworzone są z czterech typów pojęć: procesów (funkcji), magazynów danych, przepływu danych, jednostek zewnętrznych (terminatorów), a w przypadku analizy bezpieczeństwa uzupełniane są przez zaznaczenie obszarów zaufania (ich granice wyznaczają zmianę niezbędnego stopnia uprzywilejowania). DFD wybrano do przeprowadzenia analizy cyberbezpieczeństwa, ponieważ większość ataków dotyczy danych i ich przetwarzania [130]. Każdy z elementów takiego diagramu analizowany jest pod kątem wymienionych tu zagrożeń. Dla ułatwienia analizy stosuje się przygotowane szablony zawierające listy pytań, na które należy udzielić odpowiedzi. Wadą metody STRIDE jest to, że dla dużych systemów, składających się z wielu modułów, z których każdy może podlegać wielu zagrożeniom, określenie środków zaradczych jest żmudne. Ponadto niezbędna jest lista potencjalnych zagrożeń. Na podstawie wymienionych tam zagrożeń oraz dzięki znajomości struktury systemu formułowane są środki zaradcze.

Dlatego firma Microsoft zmodyfikowała metodę STRIDE, a w konsekwencji powstała metoda DREAD (ang. Damage potential, Reproducibility, Exploitability, Affected users, Discoverability) [70, 130], która po kilku kolejnych latach uległa dalszym modyfikacjom. W metodzie DREAD ocenia się:

−jak wielką szkodę może wyrządzić atak?

−jak łatwo jest odtworzyć atak?

−jak wiele pracy trzeba włożyć w przeprowadzenie ataku?

−jak wielu ludzi będzie dotkniętych skutkami ataku?

−jak trudno jest odkryć atak?

Przy stosowaniu DREAD ewaluacji liczbowej podlega ryzyko wystąpienia każdego z wymienionych zagrożeń. Pierwsze trzy zagrożenia oceniane są w skali trójstopniowej, a ostanie dwa w czterostopniowej.

W 2012 r. opracowano zestaw narzędzi o akronimie PASTA (ang. Process for Attack Simulation and Threat Analysis –proces symulacji ataku oraz analizy zagrożeń, czyli niepożądanych zdarzeń), służący do stworzenia modelu zagrożeń z punktu widzenia atakującego system. Siedmiokrokowy proces modelowania określa ryzyko wystąpienia zagrożeń. Pierwszy krok polega na zdefiniowaniu swoich celów biznesowych oraz określeniu partnerów, którzy będą mieli styczność z tworzonym oprogramowaniem oraz przepisów rządzących dziedziną, której oprogramowanie dotyczy. W szczególności należy określić, jakie wartościowe zasoby mogą być zagrożone, by je odpowiednio chronić. W drugim kroku określa się techniczne zasoby (oprogramowanie i sprzęt) i jakie są współzależności między poszczególnymi komponentami. Innymi słowy, określa się kontekst, w którym będzie funkcjonowało tworzone lub badane oprogramowanie. Trzeci krok zajmuje się dekompozycją systemu. Określa przypadki użycia, role, usługi, źródła danych, przywileje użytkowników. W tym kroku tworzy się diagramy przepływu danych DFD oraz określa obszary zaufania. W czwartym kroku następuje analiza zagrożeń, polegająca na budowie katalogu zagrożeń z punktu widzenia dziedziny zastosowań tworzonego oprogramowania oraz probabilistyczna analiza możliwych scenariuszy ataków. W tym kroku bada się logi, jeżeli istnieją, by określić przeszłe wektory ataków. Piąty krok to detekcja słabości na podstawie drzew zagrożeń. Krok szósty polega na modelowaniu ataków i analizie ich skutków. W tym celu budowane są drzewa ataków, a w efekcie określane są drogi i sposoby prowadzenia możliwych ataków. Istotnym elementem jest wskazanie, jak przypadki użycia mogą zostać przetransformowane w przypadki nadużycia. Wreszcie w kroku siódmym przeprowadzana jest analiza ryzyka pojawienia się poszczególnych ataków i określane są sposoby przeciwdziałania im. Do działań związanych z poszczególnymi krokami powstały narzędzia programistyczne wspomagające pracę analityków.

Koncepcja drzew ataków została opracowana w 1999 r. [126]. Korzeniem drzewa jest cel ataku, gałęźmi są cele cząstkowe, natomiast jego liśćmi są metody osiągnięcia celu. Dla analizowanego systemu konstruuje się wiele takich drzew, bo różne mogą być cele ataku. Gałęzie wychodzące z węzłów drzewa mogą być w relacji OR lub AND. Zazwyczaj określa się też koszt osiągnięcia tego celu przypisując wartości celom cząstkowym. Cenę ataku określa się poruszając od liści do korzenia. Koszt ataku może być określany biorąc pod uwagę różne kryteria, np. czy dana czynność jest łatwa do wykonania czy trudna, czy wymaga specjalistycznego sprzętu czy nie, jest legalna czy nie. Można też oszacować koszt monetarny wykonania czynności lub prawdopodobieństwo jej sukcesu, przez co można oszacować całkowity koszt lub prawdopodobieństwo ataku. Drzewa ataku konstruuje się albo dla całego systemu albo dla poszczególnych jego elementów. Powinny być skojarzone z wiedzą o umiejętnościach atakujących. Istnieją opracowane wskazówki, jak powinno się konstruować takie drzewa [126].

Metoda modelowania zagrożeń PnG (ang. Persona non Grata) koncentruje się na motywacjach i umiejętnościach atakujących [39]. Atakujących definiuje się jako osoby wchodzące w interakcje z systemem w sposób niedopuszczalny. Analitycy stosując tę metodę patrzą na system z punktu widzenia osoby atakującej. Przyglądają się każdej z wymaganych cech systemu przez pryzmat tego, jak może ona być nadużyta. W ten sposób określa się, jak oprogramowanie zareaguje na przypadek niewłaściwego użycia.

Karty bezpieczeństwa (ang. Security Cards) są techniką badania bezpieczeństwa za pomocą zestawu kart, które zawierają pytania i przykłady ataków [45]. Karty te używa się w trakcie sesji burzy mózgów, jako ułatwienie do generacji pomysłów dotyczących ataków możliwych do przeprowadzenia. Karty podzielone są na cztery zestawy ułatwiające udzielanie odpowiedzi na następujące grupy pytań:

kto lub co (np. klimat) może ponieść stratę wskutek ataku? −jakie są motywacje atakującego? −jakie zasoby posiada atakujący? −jakich używa metod ataku?

Metoda SQUARE (ang. Security Quality Requirements Engineering Method) została opracowana w 2005 r. przez Software Engineering Institute Carnegie Mellon University [100]. Celem opracowanej metody było wprowadzenie do projektowania systemów informatycznych, już w początkowej fazie ich tworzenia, elementów mających zapewnić bezpieczeństwo produktu finalnego. Jeżeli wymagania nałożone na projektowany system nie są poprawnie wyrażone, powstanie system nieodpowiedni lub niskiej jakości. Korekty na etapie wdrażania są bardzo kosztowne i prowadzą do projektów, które znacznie przekraczają budżet i trwają dłużej niż zakłada harmonogram. Metoda wymaga wykonania dziewięciu następujących kroków. Krok pierwszy prowadzi do uzgodnienia definicji pojęć używanych przez wszystkich udziałowców projektu – tu najczęściej korzysta się z definicji ujętych w standardach. Krok drugi polega na sformułowaniu wymagań dotyczących bezpieczeństwa systemu (identyfikacji celów). Trzeci krok dotyczy wskazania narzędzi, które zostaną wykorzystane do pracy nad stworzeniem bezpiecznego systemu, np. scenariuszy działania, przypadków użycia i nadużycia, formularzy. Krok czwarty zajmuje się oceną ryzyka związanego z poszczególnymi zagrożeniami. W kroku piątym dokonuje się wyboru technik pozyskiwania informacji od udziałowców o zagrożeniach. W kroku szóstym wybrane technik stosuje się do pozyskania niezbędnych informacji od udziałowców. Krok siódmy polega na kategoryzacji wymagań dotyczących bezpieczeństwa. W kroku ósmym przypisuje się priorytety poszczególnym kategoriom zagrożeń. W ostatnim kroku dokonuje się ostatecznej inspekcji efektów pracy i tworzy ostateczną dokumentację przeprowadzonego procesu decyzyjnego.

Ponieważ wiele ze wcześniej przedstawionych podejść do modelowania zagrożeń koncentruje się jedynie na pewnych aspektach dziedziny, stworzono również metody hybrydowe wykorzystujące kilka z wcześniej powstałych narzędzi. Jedną z takich metod jest hTMM (ang. Hybrid Threat Modeling Method) stworzona przez Software Engineering Institute Carnegie Mellon University w 2018 r. [101]. Została ona zainspirowana przez STRIDE. Łączy ona w sobie: SQUARE, Security Cards i PnG. Oto główne kroki metody. Wpierw należy określić system, dla którego ma być przeprowadzona analiza zagrożeń. Następnie należy zorganizować burzę mózgów z zastosowaniem kart bezpieczeństwa. W burzy mózgów powinni wziąć udział użytkownicy (obecni lub przyszli) oraz nabywcy systemu, jego projektanci i wdrożeniowcy oraz eksperci zajmujących się cyberbezpieczeństwem. Kolejnym krokiem jest usunięcie z zestawu osób atakujących mało prawdopodobnych PnG, tj. takich, dla których wektory ataku są nierealistyczne. Po tym

następuje podsumowanie wyników za pomocą narzędzi wspomagających. Te działania powinny doprowadzić do skonkretyzowania odpowiedzi na następujące pytania:

−kto lub co może zainicjować atak?

−jaka jest motywacja atakującego?

−co jest celem ataku?

biorąc pod uwagę zasoby i umiejętności atakującego, jaki może być wektor ataku?

−jakie mogą być efekty ataku?

−jak dotkliwe mogą być efekty ataku? z jakim typem ataku mamy do czynienia (np. DoS, udawanie użytkownika)?

Na tej podstawie przeprowadza się formalną ocenę ryzyka, przykładowo używając metody SQUARE.

Metoda CVSS (ang. Common Vulnerability Scoring System), opracowana przez NIST (ang. National Institute of Standards and Technology), a obecnie utrzymywana przez stowarzyszenie FIRST, przypisuje wartość numeryczną podatności na zagrożenie [1]. Zastosowano trzy metryki: podstawową (ang. base), czasową (ang. temporal) oraz środowiskową (ang. environmental). Pierwsza zajmuje się zagrożeniami niezależnymi od czasu i środowiska, w którym działa system, druga zajmuje się zagrożeniami zależnymi od czasu, a trzecia tymi zależnymi od środowiska, które wykorzystuje użytkownik. Wpierw obliczana jest wartość metryki podstawowej, a następnie jest ona modyfikowana przez wartości wynikające z określenia wartości dwóch pozostałych metryk. Wartość metryki podstawowej określana jest przez organizację utrzymującą oprogramowanie, natomiast dwie pozostałe metryki określane są przez konkretnych użytkowników, którzy znają warunki, w których użytkują system. Przykładowo, zmiana zagrożenia w czasie może być spowodowana przez aktualizację systemu operacyjnego, natomiast zagrożenia wynikające z uwarunkowań środowiskowych zmieniają się w zależności od zabezpieczeń dodatkowych stosowanych przez konkretnego użytkownika. Metryka podstawowa zbudowana jest z dwóch zestawów wartości. Pierwszy dotyczy możliwości wykorzystania podatności na atak (ang. exploitability), a druga konsekwencji ataku (ang. impact). Pierwszy zestaw wskazuje na łatwość dokonania ataku na podatny komponent oraz niezbędne środki techniczne do jego przeprowadzenia. Drugi zestaw kwantyfikuje skutki pomyślnie przeprowadzonego ataku na ten komponent. Metryka bazowa daje wynik w zakresie 1–10 i jest uzupełniana przez wektor liczb wskazujący na wpływ powyżej wymienionych ocen cząstkowych.

Pełna ocena zagrożeń, którym może podlegać system robotyczny, możliwa jest jedynie w przypadku dogłębnej znajomości struktury i sposobu działania tego systemu [84]. Aby ocenić zagrożenia, wymienia się tu następujące wektory ataku (drogi, którymi ataki są przeprowadzane): sprzęt, sieć, system operacyjny i oprogramowanie wbudowane, a ponadto oprogramowanie aplikacyjne. Stwierdzono tam, że cyberbezpieczeństwo systemu wymaga: konfidencjonalności, czyli uniemożliwienia nieautoryzowanego ujawnienia danych, zachowania integralności, czyli zapobieżenia modyfikacji bądź skasowania danych, oraz dostępności, czyli zapewnienia dostępu do danych w sposób terminowy i niezawodny. Prócz danych zagrożone mogą być również inne zasoby, w szczególności urządzenia, i dostarczane usługi, a dokładniej kod programów je świadczące.

Analiza cyberbezpieczeństwa dotyczy zarówno sposobu konstrukcji systemów jak i ich użytkowania. W przypadku systemów informatycznych powszechnego użytku agresorzy mogą w celu zmylenia użytkownika podstawić nieprawdziwą stronę internetową, ale ten sposób jest powszechnie znany. W przypadku robotów należy zwrócić uwagę, że ludzie inaczej zachowują się wobec innych ludzi, a inaczej wobec robotów. Ludzie mają dużo większe zaufanie do robotów społecznych niż do

innych ludzi. Nie przypuszczają, że roboty te mogą posłużyć do spowodowania szkód. Przykładowo, o ile nie byliby skłonni wpuścić do strefy zastrzeżonej obcej osoby, to zbadano, że nie mieli takich oporów w przypadku robotów [84]. Prócz problemów związanych z konstrukcją bezpiecznego oprogramowania rozważana jest kwestia, analizy istniejącego oprogramowania, które nie było stworzone według postulowanych zasad, a teraz należy określić stopień jego odporności na ataki. W tym celu prowadzone są prace badawcze mające na celu automatyczną konwersję takiego oprogramowania w modele standardowo używane do analizy odporności na ataki (np. DFD) [130].

Ostatecznym wynikiem powyżej opisanych metod analizy jest wskazanie środków zaradczych zapobiegających skutkom ataków. Przykładowymi środkami obrony są: −Ściany ogniowe (firewall), służące blokowaniu niechcianych wiadomości nadchodzących z sieci, jednocześnie przepuszczające te pożądane, Systemy wykrywania i zapobiegania włamaniom (ang. Intrusion Detection System, Intrusion Prevention System), które porównują dane w przychodzących pakietach ze znanymi wzorcami ataków i je albo jedynie wykrywają albo również neutralizują ich szkodliwe działanie, Pułapki ściągające na siebie ataki (honeypot), umożliwiające zdobycie informacji o atakującym, dzięki stworzeniu sztucznego środowiska przypominającego rzeczywiste będące owocem pożądania intruza.

Należy zwrócić uwagę, że w przypadku robotów, nie tylko połączenie z siecią może być źródłem zagrożenia. Roboty korzystają z czujników do pozyskiwania informacji o stanie swego otoczenia. Atak może nastąpić poprzez wrogie oddziaływanie na czujniki. Taki atak będzie tworzył iluzję, którą układ sterowania robota potraktuje, jako rzeczywistość i zacznie podejmować niewłaściwe decyzje. To z kolei może prowadzić do jego uszkodzenia lub zniszczeń w jego otoczeniu. Jest to szczególnie niebezpieczne w przypadku robotów przeznaczonych do celów militarnych, które nierzadko są uzbrojone.

W przypadku robotów kompanów, lub szerzej patrząc robotów usługowych, dąży się do tego, by interakcja między człowiekiem a robotem odbywała się w języku naturalnym z użyciem mikrofonów i głośników, a także kamer w celu analizy wyrazu twarzy oraz gestykulacji. Nie każdy człowiek powinien mieć możliwość wydawania poleceń takiemu robotowi. W takim przypadku potrzebne są zabezpieczenia biometryczne, np. bazujące na rozpoznawaniu głosu, bądź twarzy [9], tęczówki [44], a nawet odcisków palców [118]. Ponadto każdy sterownik robota powinien być wyposażony w oprogramowanie monitorujące zachowanie tego robota, w celu detekcji anomalii. Minimalnym wymaganiem jest sygnalizacja wykrycia takiego nienormalnego zachowania, natomiast pożądanym jest by sterownik był w stanie dokonać korekty swego działania w celu osiągnięcia stanu normalnego (samonaprawa, ang. self-healing). Jeżeli to nie jest możliwe, to element systemu, który uległ atakowi powinien być izolowany. Jeżeli system jest w stanie jedynie wykryć atak, to powinien przechowywać logi rejestrujące jego aktywność, by możliwa była analiza prowadząca do wykrycia, co konkretnie się stało i skąd nastąpił atak. Ponadto należy podkreślić, że szyfrowanie komunikacji w istotny sposób utrudnia prowadzenie ataków.

Prócz ataków na wyprodukowanego i funkcjonującego już robota rozpatruje się również ataki prowadzone w trakcie jego wytwarzania lub projektowania – może dojść do sabotażu, wynikiem którego będzie celowe wstawienie do oprogramowania tylnego wejścia, przez które osoby niepowołane będą mogły w przyszłości dostać się do wnętrza systemu. W przypadku robotów wykorzystujących systemy sterowania o zmiennej strukturze (np. [167]), gdzie na potrzeby realizacji dużej różnorodności zlecanych zadań, robot musi wymieniać moduły

wykonujące te zadania, względnie łatwo jest przesłać z repozytorium umieszczonego w chmurze zainfekowany moduł. Roboty też mogą korzystać z usług świadczonych przez chmury obliczeniowe, np. przekazując obliczeniochłonne zadania do realizacji zdalnej. Przekazywanie danych i odbieranie wyników podatne jest na cyberatak. Co więcej, roboty działają w czasie rzeczywistym, więc spowolnienie otrzymania wyników przez atak typu DoS może w istotny sposób zaburzyć funkcjonowanie systemu.

Niestety nie ma jeszcze spójnego zestawu rekomendacji, jak konstruować cyberbezpieczne systemy robotyczne. Istnieją jedynie ogólne rekomendacje, głównie zaczerpnięte z inżynierii oprogramowania oraz zalecenia dotyczące wybranych form ataków na systemy konkretnego typu. Widać, że potrzebny tu jest duży wysiłek badawczy, by stworzyć odpowiednie standardy. Oczywiście standaryzacja jest wskazana, ale należy zwrócić uwagę, że badacze zajmujący się cyberbezpieczeństwem nadal poszukują rozwiązań niekonwencjonalnych. W szczególności szukają inspiracji w naturze [99, 124]. Zwracają uwagę, że konwencjonalny atak, składający się z: 1) instalacji wrogiego oprogramowania (ang. malware) – najczęściej dzięki oszukaniu użytkownika, 2) wprowadzenie zainfekowanego komputera do botnetu, dzięki czemu atakujący przejmuje kontrolę nad tym komputerem, 3) zainicjowanie kolejnego ataku z użyciem tego komputera,

ma swoje odpowiedniki w biologii. Przykładowo niektóre pająki zastawiają pułapki feromonowe, które powodują, że owady są wabione do ich pajęczyn, tak jak wabieni są internauci na niebezpieczne strony. Do przekazywania informacji w botnecie wykorzystuje się steganografię [153], czyli ukrywanie tajnej wiadomości w publicznie dostępnych danych, np. w obrazach, modyfikując je niezauważalnie dla ludzkiego oka. Podobnie działają niektóre grzyby, które infekują mrówki, powoli je trawiąc. W pewnym momencie dochodzi do przejęcia kontroli nad zachowaniem mrówki. Mrówka jest zmuszana do wędrówki do miejsca optymalnego dla rozwoju kolejnego pokolenia zarodników. Studiowanie zachowania roślin, grzybów i zwierząt pokazuje, jakie mogą być wektory ataku, ale również jak się przed nimi bronić.

Ponadto należy zwrócić uwagę, że cyberbezpieczeństwo, traktowane jako nauka, zajmuje się wykrywaniem oraz ochroną przed: wrogim przejęciem, modyfikacją zachowania lub zniszczeniem robota, ale zupełnie pomija możliwość samoistnej zmiany jego działania na potencjalnie groźne dla ludzi, a to jest przedmiotem troski wielu futurystów. Przez samoistną zmianę rozumiem tu transformację działania robota wskutek „świadomej” decyzji sztucznej inteligencji wbudowanej w jego sterownik.

1. Common Vulnerability Scoring System version 3.1: Specification Document CVSS Version 3.1 Release. https:// www.first.org/cvss/ specification-document, 2019.

2. Google Brain Team. https://research.google/teams/ brain/robotics/, 2022.

3. Aggarwal C.C., Neural Networks and Deep Learning: A Textbook. Springer, 2018, DOI: 10.1007/978-3-319-94463-0.

4. Alami R., Chatila R., Fleury S., Ghallab M.M., Ingrand F., An architecture for autonomy. The International Journal of Robotics Research, Vol. 17, No. 4, 1998, 315–337, DOI: 10.1177/027836499801700402.

5. Arabas J., Wykłady z algorytmów ewolucyjnych. Wydawnictwa Naukowo-Techniczne, Warszawa 2001.

6. Arkin R.C., Behavior-Based Robotics. MIT Press, 1998.

7. Armbrust C., Kiekbusch L., Ropertz T., Berns K., Soft robot control with a behaviour-based architecture. Soft Robotics, 81–91, Springer, 2015, DOI: 10.1007/978-3-662-44506-8_8.

8. Ashtiani F., Geers A., Aflatouni F., An on-chip photonic deep neural network for image classification. „Nature”, No. 606, 2022, 501–506, DOI: 10.1038/s41586-022-04714-0.

9. Azimi M., Pacut A., Investigation into the reliability of facial recognition systems under the simultaneous influences of mood variation and makeup. „Computers & Electrical Engineering”, Vol. 85, 2020, DOI: 10.1016/j.compeleceng.2020.106662.

10. Beetz M., Chatila R., Hertzberg J., Pecora F., AI Reasoning Methods for Robotics, [In:] Siciliano B., Khatib O. (red.), Springer Handbook of Robotics, Springer, 2016, 329–356, DOI: 10.1007/978-3-319-32552-1_14.

11. Beetz M., Mösenlechner L., Tenorth M., CRAM – A Cognitive Robot Abstract Machine for Everyday Manipulation in Human Environments. „IEEE/RSJ International Conference on Intelligent Robots and Systems”, IROS, Taipei, Taiwan, 1012–1017, DOI: 10.1109/IROS.2010.5650146.

12. Beni G., From swarm intelligence to swarm robotics „Lecture Notes in Computer Science”, Vol. 3342, 2004, DOI: 10.1007/978-3-540-30552-1_1.

13. Beni G., Wang J., Swarm intelligence in cellular robotic systems. „Robots and Biological Systems: Towards a New Bionics”, Springer, 1993, 703–712, DOI: 10.1007/978-3-642-58069-7_38.

14. Billard A., Calinon S., Dillmann R., Learning from humans, [In:] Siciliano B., Khatib O. (red.), Springer Handbook of Robotics, Springer, 2016, 1995–2014, DOI: 10.1007/978-3-319-32552-1_74.

Przegląd podstawowych czynników wpływających na inteligencję robotów, zawarty w tej części artykułu, wskazuje na następujące istotne fakty: opracowanie każdego z wymienionych tu czynników wymagało dużego wysiłku badawczego, −w każdym z tych przypadków osiągnięto duży postęp, stworzenie inteligentnego robota wymaga inkorporacji wszystkich opisanych tu czynników do jego sterownika, patrząc na każdy z tych czynników oddzielnie, niestety osiągnięty stan jest nadal niewystarczający, by roboty mogły dorównać ludzkiej inteligencji, nie wspominając już o jej przewyższeniu.

W drugiej części tego artykułu pokazane będzie, na ile wybrane tu kluczowe technologie, niezbędne do wytworzenia inteligentnego zachowania robotów, w istocie umożliwiły stworzenie takich maszyn.

15. Billard A., Calinon S., Dillmann R., Schaal S., Robot programming by demonstration. [In:] Siciliano B., Khatib O. (red.), Springer Handbook of Robotics, Springer, 2008, 1371–1394, DOI: 10.1007/978-3-540-30301-5_60.

16. Blodow N., Jain D., Marton Z., Beetz M., Perception and probabilistic anchoring for dynamic world state logging 10th IEEE-RAS International Conference on Humanoid Robots, 2010, 160–166, DOI: 10.1109/ICHR.2010.5686341.

17. Blume C., Jakob W., PASRO: Pascal for Robots. Springer–Verlag, 1985.

18. Blume C., Jakob W., Programming Languages for Industrial Robots. Springer–Verlag, 1986.

19. Bodner J., Augustin F., Wykypiel H., Fish J., Muehlmann G., Wetscher G., Schmid T., The da Vinci robotic system for general surgical applications: a critical interim appraisal. “Swiss Medical Weekly”, Vol. 135, 2005, 674–678, DOI: 10.4414/smw.2005.11022.

20. Bonabeau E., Dorigo M., Theraulaz G., Swarm Intelligence: From Natural to Artificial Systems. Oxford University Press, New York, Oxford, 1999.

21. Brady M., Artificial intelligence and robotics. “Artificial Intelligence”, Vol. 26, No. 1, 1985, 79–121.

22. Brooks A., Kaupp T., Makarenko A., Williams S., Orebäck A., Towards component-based robotics. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS’05), 2005, 163–168, DOI: 10.1109/IROS.2005.1545523.

23. Brooks A., Kaupp T., Makarenko A., Williams S., Orebäck A., Orca: A component model and repository. [In:] Brugali D. (red.), Software Engineering for Experimental Robotics, Vol. 30 serii Springer Tracts in Advanced Robotics, 2007, 231–251, DOI: 10.1007/978-3-540-68951-5_13.

24. Brooks R.A., Elephants don’t play chess. “Robotics and autonomous systems”, Vol. 6, No. 1–2, 1990, 3–15, DOI: 10.1016/S0921-8890(05)80025-9.

25. Brooks R.A., A robust layered control system for a mobile robot, “IEEE Journal of Robotics and Automation”, Vol. 2, No. 1, 1986, 14–23, DOI: 10.1109/JRA.1986.1087032.

26. Brooks R.A., Intelligence without reason, Artificial Intelligence: critical concepts, 3:107–163, 1991.

27. Brooks R.A., Intelligence without representation. “Artificial Intelligence”, Vol. 47, No. 1–3, 1991, 139–159, DOI: 10.1016/0004-3702(91)90053-M.

28. Brooks R.A., New approaches to robotics, “Science”, Vol. 253, No. 5025, 1991, 1227–1232, DOI: 10.1126/science.253.5025.1227.

29. Brucker P., Scheduling Algorithms. Springer-Verlag, Berlin, Heidelberg, wyd. 5, 2007.

30. Brugali D., Model-driven software engineering in robotics: Models Are Designed to Use the Relevant Things, Thereby Reducing the Complexity and Cost in the Field of Robotics, “IEEE Robotics Automation Magazine”, Vol. 22, No. 3, 2015, 155–166, DOI: 10.1109/MRA.2015.2452201.

31. Bruyninckx H., Open robot control software: The OROCOS project. Proceedings of the IEEE International Conference on Robotics and Automation (ICRA), Vol. 3, 2001, 2523–2528, DOI: 10.1109/ROBOT.2001.933002.

32. Bruyninckx H., The real-time motion control core of the OROCOS project. Proceedings of the IEEE International Conference on Robotics and Automation (ICRA), 2003, 2766–2771, DOI: 10.1109/ROBOT.2003.1242011.

33. Bulter Z., Rizzi A., Distributed and cellular robots. [In:] Siciliano B., Khatib O. (red.), Springer Handbook of Robotics, Springer, 2008, 911–920, DOI: 10.1007/978-3-540-30301-5_40.

34. Carlisle B., Robot mechanisms. Proceedings of the 2000 ICRA Millenium IEEE International Conference on Robotics and Automation, 2000, DOI: 10.1109/ROBOT.2000.844134.

35. Carpenter G., Grossberg S., Adaptive resonance theory [In:] Sammut C., Webb G. (red.), Encyclopedia of Machine Learning, Springer, 2010, 22–35, DOI: 10.1007/978-0-387-30164-8_11.

36. Chaumette F., Hutchinson S., Corke P., Visual Servoing [In:] The Handbook of Robotics, Springer, 2016, 841–866.

37. Chibani A., Amirat Y., Mohammed S., Matson E., Hagita N., Barreto M., Ubiquitous robotics: Recent challenges and future trends. “Robotics and Autonomous Systems”, Vol. 61, No. 11, 2013, 1162–1172, DOI: 10.1016/j.robot.2013.04.003.

38. Cichosz P., Systemy uczące się. Wydawnictwa Naukowo-Techniczne, Warszawa 2007.

39. Cleland-Huang, J., How well do you know your personae non gratae? “IEEE Software”, Vol. 31, No. 4, 2014, 28–31, DOI: 10.1109/MS.2014.85.

40. Collett T., MacDonald B., Gerkey B., Player 2.0: Toward a practical robot programming framework. Proceedings of the Australasian Conference on Robotics and Automation (ACRA), December 2005.

41. Cooper B., Driving on the surface of mars using the rover control workstation. Proceedings of the International Conference on Space Operations, SpaceOps ’98, June 1–5 1998.

42. Coradeschi S., Saffiotti A., An introduction to the anchoring problem. “Robotics and Autonomous Systems”, Vol. 43, No. 2-3, 2003, 85–96, DOI: 10.1016/S0921-8890(03)00021-6.

43. Coste-Maniere E., Simmons R., Architecture, the backbone of robotic systems. Proc. IEEE International Conference on Robotics and Automation ICRA ’00, Vol. 1, 2000, 67–72.

44. Czajka A., Kasprzak W., Wilkowski A., Verification of iris image authenticity using fragile watermarking. “Bulletin of the Polish Academy of Sciences: Technical Sciences”, Vol. 64, No. 4, 2016, 807–819, DOI: 10.1515/bpasts-2016-0090.

45. Denning T., Friedman B., Kohno T., The security cards – a security threat brainstorming toolkit. https: //securitycards.cs.washington.edu/, 2013.

46. Dorigo M., Floreano D., Gambardella L., Mondada F., Nolfi S., Baaboura T., Birattari M., Bonani M., Brambilla M., Brutschy A., Burnier D., Campo A., Christensen A., Decugniere A., Di Caro G., Ducatelle F., Ferrante E., Forster A., Gonzales J., Guzzi J., Longchamp V., Magnenat S., Mathews N., Montes de Oca M., O’Grady R., Pinciroli C., Pini G., Retornaz P., Roberts J., Sperati V., Stirling T., Stranieri A., Stutzle T., Trianni V., Tuci E., Turgut A.E., Vaussard F., Swarmanoid: A novel concept for the study of heterogeneous robotic swarms. “IEEE Robotics & Automation Magazine”, Vol. 20, No. 4, 2013, 60–71, DOI: 10.1109/MRA.2013.2252996.

47. Doriya R., Mishra S., Gupta S., A brief survey and analysis of multi-robot communication and coordination, 2015 International Conference on Computing, Communication Automation (ICCCA), 1014–1021, DOI 10.1109/CCAA.2015.7148524.

48. Driankov D., Hellendoorn H., Reinfrank M., An Introduction to Fuzzy Control. Springer-Verlag, Berlin, Heidelberg, 1993.

49. Dudek G., Jenkin M.R.M., Milios E., Wilkes D., A taxonomy for multi-agent robotics. “Autonomous Robots”, Vol. 3, No. 41996, 375–397, DOI: 10.1007/BF00240651.

50. Dudek W., Szynkiewicz W., Winiarski T., Nao Robot Navigation System Structure Development in an Agent-Based Architecture of the RAPP Platform. [In:] R. Szewczyk, C. Zieliński, M. Kaliczyńska (red.), Recent Advances in Automation, Robotics and Measuring Techniques, Vol. 440 serii Advances in Intelligent Systems and Computing (AISC), Springer, 2016, 623–633, DOI: 10.1007/978-3-319-29357-8_54.

51. Dudek W., Winiarski T., Scheduling of a Robot’s Tasks with the TaskER Framework. “IEEE Access”, Vol. 8, 2020, 161449–161471, DOI: 10.1109/ACCESS.2020.3020265.

52. Farinelli A., Iocchi L., Nardi D., Multirobot systems: a classification focused on coordination. “IEEE Transactions on Systems, Man, and Cybernetics”, Part B (Cybernetics), Vol. 34, No. 52004, 2015–2028, DOI: 10.1109/TSMCB.2004.832155.

53. Fedrizzi A., Mosenlechner L., Stulp F., Beetz M., Transformational planning for mobile manipulation based on action-related places. 14th International Conference on Advanced Robotics, ICAR, Munich, Germany, June 22–26 2009.

54. Ferrer-Mestres J., Dietterich T., Buffet O., Chadès I., Solving k-mdps. Proceedings of the International Conference

on Automated Planning and Scheduling, Vol. 30, 2020, 110–118, DOI: 10.1609/icaps.v30i1.6651.

55. Figat M., Zieliński C., Parameterised robotic system metamodel expressed by Hierarchical Petri nets. “Robotics and Autonomous Systems”, Vol. 150, 2022, DOI: 10.1016/j.robot.2021.103987.

56. Fikes R., Nilsson N., Strips: A new approach to the application of theorem proving to problem solving. “Artificial intelligence”, Vol. 2, No. 3–4, 1971, 189–208, DOI: 10.1016/0004-3702(71)90010-5.

57. Fitzpatrick P., Metta G., Natale L., Towards long-lived robot genes. “Robotics and Autonomous Systems”, Vol. 56, No. 1, 2008, 29–45, DOI: 10.1016/j.robot.2007.09.014.

58. Gardner M., Mathematical Games: The fantastic combinations of John Conway’s new solitaire game “Life” “Scientific American”, Vol. 223, 1970, 120–123, DOI: 10.1038/scientificamerican1070-120.

59. Gat E., On three-layer architectures. D. Kortenkamp, R. P. Bonnasso, R. Murphy (red.), Artificial Intelligence and Mobile Robots, 195–210. AAAI Press Cambridge, MA, 1998.

60. Gerkey B.P., Vaughan R.T., Støy K., Howard A., Sukhatme G.S., Mataric M.J., Most Valuable Player: A Robot Device Server for Distributed Control. Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2001, 1226–1231, DOI: 10.1109/IROS.2001.977150.

61. Ghallab M., Howe A., Knoblock C., Mcdermott D., Ram A., Veloso M., Weld D., Wilkins D., PDDL—The Planning Domain Definition Language, 1998.

62. Gierse G., Niemueller T., Claßen J., Lakemeyer G., Interruptible Task Execution with Resumption in Golog. G. Kaminka, M. Fox, P. Bouquet, E. Hüllermeier, V. Dignum, F. Dignum, F. van Harmelen, (red.), Twenty-Second European Conference on Artificial Intelligence (ECAI), 2016, 1265–1273, Den Haag, The Netherlands, IOS Press, DOI: 10.3233/978-1-61499-672-9-1265.

63. Gordon D., Ant Encounters: Interaction, Networks and Colony Behavior. Primers in Complex Systems. Princeton University Press, 2010.

64. Gregory P., Long D., Fox M., Beck C., Planning modulo theories: Extending the planning paradigm. Proceedings of the International Conference on Automated Planning and Scheduling, Vol. 22, No. 1, 2012, 65–73, DOI: 10.1609/icaps.v22i1.13505.

65. Grossberg S., Conscious Mind, Resonant Brain: How Each Brain Makes a Mind. Oxford University Press, 2021.

66. Guarino N., Oberle D., Staab S., What is an ontology? S. Staab, R. Studer (red.), Handbook on Ontologies, 1–20. Springer-Verlag, Berlin, 2009.

67. Hayward V., Paul R.P., Robot manipulator control under Unix RCCL: A robot control C library. “International Journal of Robotics Research”, Vol. 5, No. 4, 1986, 94–111, DOI: 10.1177/027836498600500407.

68. Hebb D., The Organization of Behavior. Wiley & Sons, New York, 1949.

69. Horsch M., Poole D., An anytime algorithm for decision making under uncertainty. XIV Conference on Uncertainty in Artificial Intelligence, UAI’98, 1998, 246–255, DOI: 10.5555/2074094.2074123.

70. Howard M., Lipner S., The Security Development Lifecycle. Microsoft Press, 2006.

71. Höller D., Behnke G., Bercher P., Biundo S., Fiorino H., Pellier D., Alford R., HDDL: An Extension to PDDL for Expressing Hierarchical Planning Problems. Vol. 34, No. 6, 2020, 9883–9891, DOI: 10.1609/aaai.v34i06.6542.

72. Jesus A., Liefooghe A., Derbel B., Paquete L., Algorithm selection of anytime algorithms. Proceedings of the 2020

Genetic and Evolutionary Computation Conference, 850–858, DOI: 10.1145/3377930.3390185.

73. Jonsson P., Krokhin A., Complexity classification in qualitative temporal constraint reasoning. “Artificial Intelligence”, Vol. 160, No. 1-2, 2004, 35–51, DOI: 10.1016/j.artint.2004.05.010.

74. Kacprzyk J., Rozumowanie w warunkach niepewności. [In:] W. Traczyk (red.), Problemy sztucznej inteligencji, 77–114, Warszawa, 1995. Wiedza i Życie.

75. Kaelbling L., Littman M., Cassandra A., Planning and acting in partially observable stochastic domains. “Artificial Intelligence”, Vol. 101, No. 1-2, 1998, 99–134, DOI: 10.1016/S0004-3702(98)00023-X.

76. Kaelbling L., Lozano-Perez T., Integrated task and motion planning in belief space. “The International Journal of Robotics Research”, Vol. 32, No. 9-10, 2013, 1194–1227, DOI: 10.1177/0278364913484072.

77. Kaisler S., Software Paradigms. Wiley Interscience, Hoboken, 2005.

78. Kaneko T., Threat analysis using STRIDE with STAMP/ STPA. Proceedings of the International Workshop on Evidence-based Security and Privacy in the Wild and the 1st International Workshop on Machine Learning Systems Engineering, wolumen CEUR-2809, Nara, Japan, 2018.

79. Kasprzak W., Rozpoznawanie obrazów i sygnałów mowy Oficyna Wydawnicza Politechniki Warszawskiej, 2009.

80. Kavraki L., LaValle S., The handbook of robotics Motion Planning, 139–161. Springer, 2016.

81. Kiekbusch L., Armbrust C., Berns K., Formal verification of behaviour networks including sensor failures. “Robotics and Autonomous Systems”, Vol. 74, 2015, 331–339, DOI: 10.1016/j.robot.2015.08.002.

82. Kiekbusch L., Armbrust C., Berns K., Formal verification of behaviour networks including hardware failures. Vol. 302, 2016, 571–1582, DOI: 10.1007/978-3-319-08338-4_113.

83. Kortenkamp D., Simmons R., Brugali D., Robotic systems architectures and programming. B. Siciliano, O. Khatib (red.), Springer Handbook of Robotics, 2nd Edition, 283–306, Springer, 2016, DOI: 10.1007/978-3-319-32552-1_12.

84. Lacava G., Marotta A., Martinelli F., Saracino A., La Marra A., Gil-Uriarte E., Mayoral-Vilches V., Cybsersecurity issues in robotics. “Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications”, Vol. 12, No. 3, 2021, 1–28, DOI: 10.22667/JOWUA.2021.09.30.001.

85. Langdon W., Poli R., McPhee N., Koza J., Genetic programming: An introduction and tutorial, with a survey of techniques and applications. J. Fulcher, L. Jain (red.), Computational Intelligence: A Compendium, Vol. 115, 2008, 927–1028, Berlin, Heidelberg, DOI: 10.1007/978-3-540-78293-3_22.

86. Langton C., Self-reproduction in cellular automata. “Physica D: Nonlinear Phenomena”, Vol. 10, No. 1, 1984, 135–144, DOI: 10.1016/0167-2789(84)90256-2.

87. Langton C., Artificial Life : An Overview. MIT Press, Cambridge Mass., 1995.

88. LaValle S., Planning Algorithms. Cambridge University Press, 2006.

89. Lebedev M., Nicolelis M., Brain-machine interfaces: From basic science to neuroprostheses and neurorehabilitation. “Physiological Reviews”, Vol. 97, No. 2, 2017, 767–837, DOI: 10.1152/physrev.00027.2016.

90. LeCun Y., A path towards autonomous machine intelligence. https://openreview.net/pdf?id=BZ5a1rkVsf, 2022.

91. Levine S., Pastor P.S., Krizhevsky A., Ibarz J., Quillen D., Learning hand-eye coordination for robotic grasping with deep learning and large-scale data collection. “Internatio-

nal Journal of Robotics Research”, Vol. 37, No. 4–5, 2018, 421–436, DOI: 10.1177/0278364917710318.

92. Litman T., Autonomous vehicle implementation predictions implications for transport planning. Victoria Transport Policy Institute, November 2018.

93. Luger G.F., Stubblefield W.A., Artificial Intelligence and the Design of Expert Systems. Benjamin-Cummings, Redwood, 1989.

94. Lyons D.M., Prerational intelligence, Vol. 2: Adaptive behavior and intelligent systems without symbols and logic serii Studies in cognitive systems, [In:] A Schema-Theory Approach to Specifying and Analysing the Behavior of Robotic Systems, 51–70. Kluwer Academic, 2001.

95. Lyons D.M., Arbib M.A., A formal model of computation for sensory-based robotics. “IEEE Transactions on Robotics and Automation”, Vol. 5, No. 3, 1989, 280–293, DOI: 10.1109/70.34764.

96. Matarić M.J., Michaud F., The Handbook of Robotics, Behavior-Based Systems, 2008, 891– 909. Springer, DOI: 10.1007/978-3-540-30301-5_39.

97. Matarić M.J., Issues and approaches in the design of collective autonomous agents. “Robotics and Autonomous Systems”, Vol. 16, No. 2-4, 1995, 321–331, DOI: 10.1016/0921-8890(95)00053-4.

98. Matuszek C., Cabral J., Witbrock M., DeOliveira J., An Introduction to the Syntax and Content of Cyc. Proc. 2006 AAAI Spring Symposium on Formalizing and Compiling Background Knowledge and Its Applications to Knowledge Representation and Question Answering, 44–49, Stanford, California, March 2006.

99. Mazurczyk W., Rzeszutko E., Security–a perpetual war: Lessons from nature. “IEEE IT Professional”, Vol. 17, 2015, 16–22, DOI: 10.1109/MITP.2015.14.

100. Mead N., Hough E., Stehney T., Security quality requirements engineering (SQUARE). Raport instytutowy CMU/ SEI-2005-TR-009, Carnegie Mellon University, Software Engineering Institute, November 2005.

101. Mead N., Shull F., Vemuru K., Villadsen O., A hybrid threat modeling method. Raport instytutowy CMU/SEI2018-TN-002, Carnegie Mellon University, Software Engineering Institute, March 2018.

102. Metta G., Fitzpatrick P., Natale L., YARP: Yet Another Robot Platform. “International Journal on Advanced Robotics Systems”, Vol. 3, No. 1, 2006, 43–48, DOI: 10.5772/5761.

103. Munson G., The rise and fall of Unimation Inc. – story of robotics innovation & triumph that changed the world! “Robot Magazine”, December 2010.

104. Müller A., Kirsch A., Beetz M., Transformational planning for everyday activity. 17th International Conference on Automated Planning and Scheduling, ICAPS, 248–255, Providence, Rhode Island, September 22–26 2007.

105. Nalepa G., From Good Robots to Useful Intelligent Agents [In:] K. Tchoń, W. Gasparski, (red.), A Treatise on Good Robots, 159–170. Transaction Publishers, 2014.

106. Nesnas I., The CLARAty project: Coping with hardware and software heterogenity. [In:] D. Brugali (red.), Software Engineering for Experimental Robotics, 31–70. Springer–Verlag, 2007.

107. Nilsson N., Shakey the robot. SRI International Technical note 323, 1984.

108. Nordmann A., Hochgeschwender N., Wigand D., Wrede S., A survey on domain-specific modeling and languages in robotics. “Journal of Software Engineering for Robotics”, Vol. 7, 2016, 75–99.

109. Nwana H., Software agents: an overview. “The Knowledge Engineering Review”, Vol. 11, No. 3, 1996, 205–244, DOI: 10.1017/S026988890000789X.

110. Nwana H.S., Ndumu D.T., A Brief Introduction to Software Agent Technology, 29–47. Springer Berlin Heidelberg, Berlin, Heidelberg, 1998.

111. Padgham L., Winikoff M., Developing Intelligent Agent Systems: A Practical Guide. John Wiley & Sons, 2004.

112. Pan Z., Polden J., Larkin N., Duin S.V., Norrish J., Recent progress on programming methods for industrial robots “Robotics and Computer-Integrated Manufacturing”, Vol. 28, No. 2, 2012, 87–94, DOI: 10.1016/j.rcim.2011.08.004.

113. Parker L., Rus D., Sukhatme G., The handbook of robotics. Multiple Mobile Robot Systems, 1335–1380. Springer, 2016.

114. Parker L.E. Multiple mobile robot systems. [In:] O. Khatib, B. Siciliano (red.), Springer Handbook of Robotics, 921–941. Springer, June 2008.

115. Pałka P., Wieloagentowe systemy decyzyjne. Oficyna Wydawnicza Politechniki Warszawskiej, Warszawa, 2019.

116. Pedersen M.R., Nalpantidis L., Andersen R.S., Schou C., Bøgh S., Krüger V., Madsen O., Robot skills for manufacturing: From concept to industrial deployment. “Robotics and Computer-Integrated Manufacturing”, Vol. 37, 2016, 282–291, DOI: 10.1016/j.rcim.2015.04.002.

117. Pilone D., Pitman N., UML 2.0 in a Nutshell. O’Reilly, 2005.

118. Pinto A., Pedrini H., Krumdick M., Becker B., Czajka A., Bowyer K., Rocha A., Counteracting presentation attacks in face, fingerprint, and iris recognition. [In:] M. Vatsa, R. Singh, A. Majumdar (red.), Deep Learning in Biometrics. CRC Press, 2018.

119. Pretz K., Don’t Trust Deep Learning, Says Brain Modeler – Stephen Grossberg maintains his approach to intelligence is better. “IEEE Spectrum”, 54–55, June 2022.

120. Quigley M., Gerkey B., Conley K., Faust J., Foote T., Leibs J., Berger E., Wheeler R., Ng A., ROS: an opensource Robot Operating System. Proceedings of the OpenSource Software Workshop at the International Conference on Robotics and Automation (ICRA), 2009.

121. Rubenstein M., Cornejo A., Nagpal R., Programmable self-assembly in a thousand-robot swarm. “Science”, Vol. 345, No. 6198, 2014, 795–799, DOI: 10.1126/science.1254295.

122. Russell S., Norvig P., Artificial Intelligence: A Modern Approach. Pearson Education, Upper Saddle River, N.J., 2003.

123. Rutkowski L., Metody i techniki sztucznej inteligencji Wydawnictwo Naukowe PWN, Warszawa, 2005.

124. Rzeszutko E., Mazurczyk W., Insights from nature for cybersecurity. “Health security”, Vol. 13, No. 2, 2014, 82–87, DOI: 10.1089/hs.2014.0087.

125. Sacha K., Inżynieria oprogramowania. Wydawnictwo Naukowe PWN, Warszawa, 2010.

126. Schneier B., Attack trees. “Dr. Dobb’s Journal”, December 1999.

127. Shevchenko N., Threat modeling: 12 available methods Raport instytutowy, Carnegie Mellon University, Software Engineering Institute, 2018

128. Shevchenko N., Chick T., O’Riordan P., Scanlon T., Woody C., Threat modeling: A summary of available methods. Raport instytutowy, Carnegie Mellon University, Software Engineering Institute, July 2018.

129. Shoham Y., Agent-oriented programming. “Artificial Intelligence”, Vol. 60, No. 1, 1993, 51–92, DOI: 10.1016/0004-3702(93)90034-9.

130. Shostack A., Experiences Threat Modeling at Microsoft MODSEC@MoDELS, 2008.

131. Shull F., Evaluation of threat modeling methodologies. http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=474197, 2016.

132. Siciliano B., Sciavicco L., Villani L., Oriolo G., Robotics: Modelling, Planning and Control. Advanced Textbooks in Control and Signal Processing. Springer, London, 2009.

133. Silver D., Huang A., Maddison C., Guez A., Sifre L., Driessche G., Schrittwieser J., Antonoglou I., Panneershelvam V., Lanctot M., Dieleman S., Grewe D., Nham J., Kalchbrenner N., Sutskever I., Lillicrap T., Leach M., Kavukcuoglu K., Graepel T., Hassabis D., Mastering the game of go with deep neural networks and tree search. “Nature”, Vol. 529, 2016, 484–489.

134. Simoens P., Dragone M., Saffiotti A., The internet of robotic things: A review of concept, added value and applications. “International Journal of Advanced Robotic Systems”, Vol. 15, No. 1, 2018, DOI: 10.1177/1729881418759424.

135. Staniak M., Zieliński C., Structures of visual servos. “Robotics and Autonomous Systems”, Vol. 58, No. 8, 2010, 940–954, DOI: 10.1016/j.robot.2010.04.004.

136. Stenmark M., Haage M., Topp E.A., Simplified programming of re-usable skills on a safe industrial robot – prototype and evaluation. Proceedings of the IEEE/ACM Conference on Human-Robot Interaction (HRI), Vienna, Austria, March, 6–9 2017, DOI: 10.1145/2909824.3020227.

137. Taleby Ahvanooey M., Li Q., Wu M., Wang S., A survey of genetic programming and its applications. KSII Transactions on Internet and Information Systems, Vol. 13, No. 4, 2019, 1765–1793, DOI: 10.3837/tiis.2019.04.002.

138. Tang F., Parker L., A Complete Methodology for Generating Multi-Robot Task Solutions using ASyMTRe-D and Market-Based Task Allocation., 2007 IEEE International Conference on Robotics and Automation, 3351–3358, DOI: 10.1109/ROBOT.2007.363990.

139. Tenorth M., Beetz M., KnowRob: a knowledge processing infrastructure for cognition-enabled robots. “International Journal of Robotics Research”, Vol. 32, No. 52013, 566–590, DOI: 10.1177/0278364913481635.

140. Tenorth M., Perzylo A.C., Lafrenz R., Beetz M., The RoboEarth language: Representing and exchanging knowledge about actions, objects, and environments. IEEE International Conference on Robotics and Automation. 2012, DOI: 10.1109/ICRA.2012.6224812.

141. Tenorth M., Perzylo A.C., Lafrenz R., Beetz M., Representation and exchange of knowledge about actions, objects, and environments in the RoboEarth framework “IEEE Transactions on Automation Science and Engineering”, Vol. 10, No. 3, 2013, 643–651, DOI: 10.1109/TASE.2013.2244883.

142. Traczyk W., Metody wnioskowania w systemach ekspertowych. [In:] W. Traczyk (red.), Problemy sztucznej inteligencji, 53–75, Warszawa, 1995. Wiedza i Życie.

143. Turing A., Computing machinery and intelligence “Mind”, Vol. 59, No. 236, 1950, 433–460, DOI: 10.1093/mind/LIX.236.433.

144. Vaughan R.T., Gerkey B.P., Reusable robot software and the Player/Stage project. [In:] D. Brugali (red.), Software Engineering for Experimental Robotics, Vol. 30 serii Springer Tracts in Advanced Robotics, 267–289, Springer, 2007, DOI: 10.1007/978-3-540-68951-5_16.

145. Čapek K., Four Plays: R.U.R., The Insect Play, The Makropulos Case, The White Plague. Methuen Publishing Ltd., 1999.

146. von Neumann J., The general and logical theory of automata. Cerebral Mechanisms in Behavior. The Hixon Symposium, 1–41. John Wiley & Sons, New York, 1951.

147. Wooldridge M., Multiagent systems. Intelligent Agents, 27–77. MIT Press, Cambridge, MA, USA, 1999.

148. Xia X., Pan X., Li N., He X., Ma L., Zhang X., Ding N., GAN-based anomaly detection: A review. “Neurocomputing”, Vol. 493, 2022, 497–535, DOI: 10.1016/j.neucom.2021.12.093.

149. Yaacoub J.-P., Noura H., Salman O., Chehab A., Robotics cyber security: Vulnerabilities, attacks, countermeasures, and recommendations. “International Journal of Information Security”, Vol. 21, No. 1, 2022, 115—158, DOI: 10.1007/s10207-021-00545-8.

150. Yim M., Shen W.-M., Salemi B., Rus D., Moll M., Lipson H., Klavins E., Chirikjian G.S., Modular self-reconfigurable robot systems [grand challenges of robotics]. “IEEE Robotics & Automation Magazine”, Vol. 14, No. 1, 2007, 43–52, DOI: 10.1109/MRA.2007.339623.

151. Zhang X., Zhu Y., Ding Y., Zhu Y., Stone P., Zhang S., Visually grounded task and motion planning for mobile manipulation. IEEE International Conference on Robotics and Automation (ICRA), May 23–27 2022.

152. Zheng N., Mazumder P., Fundamentals and learning of artificial neural networks. [In:] Learning in EnergyEfficient Neuromorphic Computing: Algorithm and Architecture Co-Design, 11–60, 2020.

153. Zielińska E., Mazurczyk W., Szczypiorski K., Trends in steganography. “Communications of the ACM”, Vol. 57, No. 3, 2014, 86–95, DOI: 10.1145/2566590.2566610.

154. Zieliński C., TORBOL: An object level robot programming language. “Mechatronics”, Vol. 1, No. 4, 1991, 469–485, DOI: 10.1016/0957-4158(91)90032-6.

155. Zieliński C., Description of semantics of robot programming languages. “Mechatronics”, Vol. 2, No. 2, 1992, 171–198, DOI: 10.1016/0957-4158(92)90030-R.

156. Zieliński C., The MRROC++ system. Proceedings of the First Workshop on Robot Motion and Control, RoMoCo ’99, 147–152, DOI: 10.1109/ROMOCO.1999.791067.

157. Zieliński C., A Quasi-Formal Approach to Structuring Multi-Robot System Controllers. Second International Workshop on Robot Motion and Control, RoMoCo’01, 121–128, DOI: 10.1109/ROMOCO.2001.973442.

158. Zieliński C., Formal approach to the design of robot programming frameworks: the behavioural control case “Bulletin of the Polish Academy of Sciences – Technical Sciences”, Vol. 53, No. 1, 2005, 57–67.

159. Zieliński C., Systematic approach to the design of robot programming frameworks. Proceedings of the 11th IEEE International Conference on Methods and Models in Automation and Robotics (on CD), 639–646. Technical University of Szczecin, 2005.

160. Zieliński C., Transition-function based approach to structuring robot control software. [In:] K. Kozłowski (red.), Robot Motion and Control, Vol. 335 serii Lecture Notes in Control and Information Sciences, 2006, 265–286. Springer-Verlag.

161. Zieliński C., Koboty – w przemyśle i laboratoriach badawczych. „Automatyka”, Nr 12, 2020, 28–40, 2020.

162. Zieliński C., Robotic System Design Methodology Utilising Embodied Agents, Vol. 296 serii Advances in Intelligent Systems and Computing, 523–561. Springer, 2021.

163. Zieliński C., Kornuta T., Stefańczyk M., Szynkiewicz W., Trojanek P., Walęcki M., Języki programowania robotów przemysłowych. „Pomiary Automatyka Robotyka”, Vol. 16, Nr 11, 2012, 10–19.

164. Zieliński C., Stefańczyk M., Kornuta T., Figat M., Dudek W., Szynkiewicz W., Kasprzak W., Figat J., Szlenk M., Winiarski T., Banachowicz K., Zielińska T., Tsardoulias E.G., Symeonidis A.L., Psomopoulos F.E., Kintsakis A.M., Mitkas P.A., Thallas A., Reppou S.E., Karagiannis G.T., Panayiotou K., Prunet V., Serrano M., Merlet J.-P.,

Arampatzis S., Giokas A., Penteridis L., Trochidis I., Daney D., Iturburu M., Variable structure robot control systems: The RAPP approach. “Robotics and Autonomous Systems”, Vol. 94, 2017, 226–244, DOI: 10.1016/j. robot.2017.05.002.

165. Zieliński C., Kornuta T., Diagnostic requirements in multi-robot systems. [In:] J. Korbicz, M. Kowal (red.), Intelligent Systems in Technical and Medical Diagnostics, Vol. 230 serii Advances in Intelligent Systems and Computing, 345–356. Springer, 2014.

166. Zieliński C., Kornuta T., Programowe struktury ramowe do tworzenia sterowników robotów, „Pomiary Automatyka Robotyka”, R. 19, Nr 1, 2015, 5-14, DOI: 10.14313/PAR_215/5.

167. Zieliński C., Szynkiewicz W., Mianowski K., Nazarczuk K., Mechatronic design of open-structure multirobot controllers. “Mechatronics”, Vol. 11, No. 8, 2001, 987–1000, DOI: 10.1016/S0957-4158(00)00038-6.

168. Zieliński C., Trojanek P., Stigmergic cooperation of autonomous robots. “Journal of Mechanism and Machine Theory”, Vol. 44, No. 4, 2009, 656–670, DOI: 10.1016/j.mechmachtheory.2008.08.012.

In order to assess the impact of robots on society, it is necessary to carefully analyze the state-of-the-art, and in particular the fundamental issues that have yet to be resolved, however having significant impact on the potential societal changes resulting from the development of robotics. The aforementioned impact depends on the level of intelligence of robots, so this aspect dominates in the presented analysis. The presentation has been divided into three parts: 1) analysis of technical factors affecting the intelligence and security of robots, 2) analysis of current capabilities of robots, 3) analysis of diverse predictions of how robotics will evolve, and thus the attitudes towards the influence of the result of this development on society. This part of the paper is devoted to the first of the above mentioned three issues.

Keywords

ORCID: 0000-0001-7604-8834

This study provides a new class of controllers for freeflying space manipulators subject to unknown undesirable disturbing forces exerted on the end-effector. Based on suitably defined taskspace non-singular terminal sliding manifold and the Lyapunov stability theory, we derive a class of estimated extended transposed Jacobian controllers which seem to be effective in counteracting the unstructured disturbing forces. The numerical computations which are carried out for a space manipulator consisting of a spacecraft propelled by eight thrusters and holonomic manipulator of three revolute kinematic pairs, illustrate the performance of the proposed controller.

1. Introduction

Space manipulators are extensively applied in recent years in space operations such as an on-orbit high-tolerance assembly tasks, maintenance, inspection and precise capturing and transferring space debris [10]. Space manipulators are complex and highly non-linear dynamic systems composed of a spacecraft (platform or satellite) on which holonomic robotic manipulator is mounted. The spacecraft is actuated by thrusters or other propellers and the links of holonomic manipulator are usually driven by electric DC motors. There are two modes of operations of space manipulators: free-flying and free-floating. In the case of free-flying dynamic systems, a spacecraft’s controller is active. On the other hand, in the free-floating operational mode, a platform controller is turned off. Due to high potential costs of a space mission, space manipulators have to be robust against actuator failures. This means that such dynamic systems are, by nature, over-determined (number of actuators is greater than the number of coordinates uniquely describing a configuration of the whole space robotic system). It is worth noting that the space operations requiring extremely high accuracy still make a great challenge for space manipulators due to various uncertainties of, e.g., parts or sub-parts to be assembled, end-effector tasks, etc., which are rigidly gripped and transferred by the end-effector along a desired trajectory mostly expressed in task (Cartesian) coordinates. In practice, for example, either a known or unknown

sub-part (by its geometry and mass) introduces structural and/or parametric uncertainties in both kinematic and dynamic equations of the space manipulator. As a result, transferred sub-parts generate undesirable external disturbances (e.g., Coriolis and/or centrifugal forces) acting on the end-effector which may result in large tracking errors. When accomplishing the complicated assembly process, the space manipulator (or at least a holonomic manipulator) should attain possibly maximal manipulability measure [25]. Otherwise, a complex and time-consuming reconfiguration of the whole space manipulator has to be carried out to make it possible accomplishment of assembly operations by the end-effector. The control of space manipulators is usually decomposed into two stages. In the first stage, the space manipulator has to attain a close vicinity of a target using the thrusters (the rendezvous). In the second one, the target must be captured in a close range using only the holonomic manipulator actuators (the docking). Most of the works devoted to control process in Cartesian task coordinates concern an on-orbit docking maneuvers (e.g., with tumbling target) [17–19, 23] for which, the thrusters are turned off what implies a non-holonomic movement. In [17, 19, 23], the authors have applied a Jacobian transposed technique with full knowledge of kinematics and dynamics to steer space manipulator to a close target. An off-line control based on endogenous space approach and accurate knowledge of both kinematic nd dynamic equations has been offered in [18]. Let us note that control algorithms proposed in [17–19, 23] may lead, e.g., to configurations with small manipulability measure what prevents accomplishment of complicated assembly operations. In order to increase the mobility of in-orbit robotic systems, both thrusters of spacecraft and actuators of holonomic manipulator are assumed to be active (in works [11–13, 15, 16, 24]) in controlling the space manipulator during the trajectory tracking tasks. Unfortunately, a vast majority of control algorithms is expressed in the space of generalized (joint) coordinates [11–13, 24]. Due to the fact that a huge amount of trajectory tracking tasks is expressed in Cartesian (task) coordinates, the algorithms proposed in works [11–13, 24] are

not suitable for accomplishment of such tasks. Only a very few works has been reported which tackle the problem of trajectory tracking control of fully actuated space manipulators in task coordinates. In [15, 16], a modified transpose Jacobian control algorithm has been presented, which employs stored data of the control command in the previous time step as a learning tool to yield improved performance. Nevertheless, the control laws from [15, 16] are only stable and require the full knowledge of kinematic equations.

In this work, a new class of controllers for space manipulator subject to undesirable forces exerted on the end-effector, is introduced. Due to unstructured nature of external disturbance forces, kinematics and dynamics of the mechanism is assumed herein to be uncertain. In order to tackle the trajectory tracking control problem subject to unstructured, a new non-singular terminal sliding manifold (TSM) is proposed. Based on the TSM introduced, we propose a new robust controller (incorporating a transposed extended estimated Jacobian matrix) which tackles unknown external forces and uncertainties of kinematic as well as dynamic equations. By fulfilment of a reasonable assumption regarding the Jacobian matrix, the proposed control scheme is shown to be finite-time stable. The remainder of the paper is organized as follows. Section 2 introduces kinematic and dynamic equations of the space manipulator including external forces acting on the end-effector. Section 3 sets up a class of robust controllers solving the trajectory tracking control problem in a finite-time. Section 4 presents computer example of the end-effector trajectory tracking by a space manipulator which is subject to external disturbance forces. Finally, some concluding remarks are drawn in Section 5.

eral, non-linear with respect to q) and k is the dimension of the task space. On account of the fact that space manipulator becomes mostly in practice a redundant mechanism with respect to a task to be accomplished, the following inequality holds true: . nk ≥ Consequently, there exists a possibility to augment vector of the end-effector coordinates pe by additional task coordinates pa (specified by the user) of the following general form [20]: () , aa pfq = (4)

where : nn-k fa → is at least twice continuously differentiable mapping with respect to q. From the practical point of view, redundant degrees of freedom of the mechanism may either satisfy additional task requirements (constraints) [20, 21] or optimize performance criteria reflecting the kinematic characteristics of the mobile manipulator [7]. Concatenating fe(q) with fa(q), one obtains generalized kinematic-differential mappings which relate q with augmented task coordinates e a

p p p ⎛⎞ = ⎜⎟ ⎝⎠ () , pfq = () , pJqq = (5) where e a

f f f ⎛⎞ = ⎜⎟ ⎝⎠ and f J q ∂ = ∂ is the n × n extended Jacobian matrix. The task accomplished by the space manipulator is to track both desired end-effector trajectory () , ek d pt ∈ [ ) 0, t ∈∞ and auxiliary (user specified) trajectory () an-k d pt ∈ Introducing the task tracking error e = f(q ) − pd(t), where , e d d a d

The control scheme designated in the next section is applicable to holonomic mechanical systems comprising both non-redundant and redundant space manipulators considered here, which are described, in general, by the following dynamic equations, expressed in generalized coordinates [14, 19]: () ()() ,,, MqqCqqqBvdqq +=+ (1)

where ()T 1 ,..., n n qqq=∈ denotes the space manipulator configuration including location and orientation of spacecraft with respect to a global coordinate system OX1X2X3 and joint coordinates of the holonomic manipulator; M(q) is the n × n positive definite inertia matrix; () , Cqqq denotes the n–dimensional vector representing centrifugal and Coriolis forces; () , dqq describes the n–dimensional external disturbance signal; B(q) stands for the n × m non-singular control matrix; v is the m–dimensional vector of steering signals (forces generated by thrusters of spacecraft and torques provided by actuators of holonomic manipulator); n denotes the dimension of the space of generalized coordinates and m stands for the number of controls. By assumption, we have mn ≥ (safety and reliability of the space mission when a thruster is damaged). Without loss of generality, d is assumed to be upper estimated as follows

(),,,dtqq α ≤ (2)

where a( ) is the time dependent, non-negative locally bounded Lebesgue measurable function. Location and orientation of the end-effector with respect to the global coordinate system OX1X2X3 is described by the kinematic equation

() , ee pfq = (3)

where k pe ∈ denotes the coordinates of the end-effector; : nk fe → represents k-dimensional mapping (in gen-

p p p ⎛⎞ = ⎜⎟ ⎝⎠ the finite time control problem may be formally expressed by means of the following equations: () lim0, tT et → = () lim0, tT et → = (6) where 0 T ≤ denotes a finite time of convergence of f(q) to pd and ()() 0 etet== for tT ≥ The aim is to determine control u, for which, the corresponding trajectory q = q(t) as being the solution of differential equations (1), accomplishes the space manipulator task (6).

Before we propose the control law solving the kinematic task (6), some useful concepts are first introduced. Let () ˆˆ JJq = and () ˆˆ BBq = denote estimates of the uncertain generalized extended Jacobian matrix J(q) and full rank control matrix B(q) given by formulas (5), (1). In further considerations, ˆ J and full rank matrix ˆ B are assumed to fulfil the following inequalities: () 1T min ˆˆ 0, aJMJ λ <≤ (7) and 12 0, bba≤+< (8) where

# B denotes the Moore-Penrose pseudo-inverse matrix of B It is worth noting that inequality (8) can be in practice fulfilled by selection of measurement devices, which provide both kinematic and dynamic parameters of space manipulator with sufficient accuracy. Let us also observe that inequality (7) means non-singularity of extended estimated Jacobian matrix ()Jq Nevertheless, relations (7)–(8) are only needed in the proof of the finite-time stability of the controller to be designated. The estimate of constant a from (7) can be determined based both on the numerical solution with respect to q of the following system of algebraic equations: f(q) = p d(t) and the knowledge of the components of the nominal kinematic and dynamic equations J(q) and M(q). Motivated partially by the computed torque methodology [8], we propose a new extended estimated transposed Jacobian control law of the following form: ˆˆ#T , vBJu = (9) where n u ∈ is a new control to be determined. Applying (9) as a non-linear control law, inserting it to the right-hand side of (1) and determining q gives

1#T11 ˆˆ qMBBJuMCqMd =−+ (10)

Let us also twice differentiate e with respect to time thus obtaining (11)

In order to design a controller solving the space manipulator task (6), we introduce the following non-singular integral sliding vector variable n s ∈ defined in task coordinates as follows ()() ( ) 2 1 01 0 0, t seeeed α α =−++ωωτ ∫ (12) where 1 1 2 ; a a α = a1, a2 are positive odd numbers, a1 < a2 < 2a1, 1 2 1

2 ; 1 α α α = + w0, w1 stand for controller gains. The odd variables a1 and a2 ensure the finite-time convergence of the task errors () , ee to the origin ()() ,0,0.ee = The time derivative of (12) results after simple calculation and taking into account (11) in the following expression:

1#T ˆˆ , sJMBBJu=+ (13) where

In further analysis, an upper estimate of will be needed. It takes the form given below: , ≤ (14)

where ( ) () 2 1 2 01 , wqeepd α α αωω =+++− w denotes a construction parameter of the space manipulator. In what follows, we provide a useful lemma [8].

If s(t) = 0 for 0 tT≥≥ then task errors () , ee of (6) stably converge to the origin in a finite time.

Based on (7)–(8), (12)–(14), we propose the following simple control law for the space manipulator solving the kinematic task (6):

cs cs as utqs ⎧ −+≠ ⎪ = ⎨ ⎪ ⎩ (15)

() () 0 for0 ,, 0otherwise,

where c, c0 denote controller gains to be specified further on. Applying the Lyapunov stability theory, we now derive the following result.

Theorem 1. If w0, w1, c0 > 0 and 12 1 c c bb a

′ = + with c ¢ > 1 then

control scheme (9), (15) guarantees stable convergence in a finite time of the task tracking errors () , ee to the origin ()() ,0,0.ee =

Proof. Consider a Lyapunov function candidate 1 ,. 2 Vss = (16)

Computing the time derivative of (16) and replacing v by (9) results in the following expression: () () 1T1T 1#T

VsJMJusJJMJu sJMBBBJus

=+−+ −+ (17)

ˆˆˆˆ ,, ˆˆˆ ,,.

Replacing u from (17) by (15) and then using (7)–(8), one obtains the inequality () 12 0 cbcb Vsccs aa ⎛⎞ ≤+−+++ ⎜⎟ ⎝⎠ (18)

On account of (14) and using assumption regarding c0 as well as 12 1 c c bb a

′ = + with c ¢ > 1 from Theorem 1, we have () () 12 0011. cbcb Vsccccs aa ⎛⎞ ≤+−+++≤−− ′ ⎜⎟ ⎝⎠ (19)

Based on (19) and (12), we conclude that TSM manifold s = 0 is stably attainable in a finite time. Finally, from Lemma 1, it follows that origin ()() ,0,0ee = can also be attained in a finite time 0. T ≥

Two remarks may be made regarding the control law (9), (15) and Theorem 1.

Let us observe that term in controller (15) will cause undesirable chattering effect in a small neighbourhood of s = 0. In order to eliminate the chattering, a known boundary layer technique of control law may now be utilized as follows () () () 0 0

cs cs as utqs cs c a

for ,,, otherwise,

ε ε ε

⎧ ℘ ⎪ ⎪ = ⎨ ⎪ −+ ⎪ ⎩ (20)

where ε is a user-specified arbitrarily small positive real number (size of boundary layer). Let () , eet ε = and be the solutions of control problem (1), (9), (12) and (20). Although boundary layer control is a well known technique, its desired property of uniform ultimate boundedness has been established for linear sliding variables s, e, e and diagonal actuation matrices of non-zero diagonal components (or of constant signs) in [22] as well as for dynamic systems fulfilling

the so called matching conditions with known actuation matrices in work, e.g., [2], respectively. On the other hand, expression (12) is a non-linear differential equation with respect to and (),. eet ε = Moreover, B is uncertain non-diagonal actuation matrix. Consequently, the classic results regarding the ultimate uniform boundedness of and () , eet ε = may not, in general, apply in our case. Hence, based on the results from work by [8], we may conclude that task errors (),, eet ε = () , eet ε = converge uniformly with respect to time t (t ³T) to the origin as 0, ε → i.e. (),0 et ε → as 0. ε →

Let us note that expressions (9), (15) present a transpose Jacobian controller. In such a context, the use of the transpose of the Jacobian matrix to robotic manipulators in [3, 4, 16] is a well-known technique.

However, works [3, 4, 16] present stability analysis for the set-point control problems. On the other hand, Theorem 1 provides stability analysis for the trajectory tracking of the space manipulator whose both kinematic and dynamic equations are uncertain as well as disturbances acting on the mechanism are unknown. In such a context, it is worth noting the fact that authors from works [5, 6] have also shown finite-time convergence of their controller using however the inverse of the Jacobian matrix.

In each of the four corners of the spacecraft, there are two thrusters that propel it. Moreover, the holonomic manipulator is actuated by three DC motors which generate three generalized torques in the joints of the kinematic pairs. Hence, the mechanism from Fig. 1 generates m = 11 steering signals. The space manipulator is assumed to operate in a three dimensional task space (k = 3). Hence, it becomes redundant mechanism with

k = 3 redundant degrees of freedom. In the numerical computations, SI units are used. The nominal values of both kinematic and dynamic parameters of the space manipulator have been taken from work [1]. The nominal values of link lengths of the holonomic manipulator are equal to l1 = 0 449 [m], l2 = 0 449 [m] and l3 = 0 3103 [m]. The coordinates (p1, p2) of the manipulator mounting point equal (p1, p2) = (0 377 [m], −0 001 [m]).

In this section, we illustrate the performance of the proposed robust controller (9), (20) using the data of the planar space manipulator constructed in the Space Research Centre of the Polish Academy of Sciences [1] and schematically depicted in Fig. 1. This mechanism consists of a freeflying spacecraft

Fig. 1. A kinematic scheme of the space manipulator with force F acting on the end-effector Rys. 1. Schemat kinematyczny manipulatora kosmicznego z siłą F działającą na koniec efektora whose posture is described by two position variables x1,c, x2,c and orientation angle q with respect to the global coordinate system OX1X2. The planar holonomic manipulator (of three revolute kinematic pairs of the V-th order) whose configuration is described by the three joint angles y1, y2 and y3, respectively is rigidly attached to the spacecraft at the point (p1, p2) – see Fig. 1. Consequently, vector of generalized coordinates q of the space manipulator from Fig. 1 equals q = (x1,c, x2,c, q, y1, y2, y3)T with n = 6.

Distance w from the spacecraft geometry centre to each of corner is equal to w = 0.2 [m]. The dynamic parameters take the following nominal values: spacecraft mass m0 = 58 7 [kg], masses of the first, second and third links of the holonomic manipulator equal m1 = 2 82 [kg], m2 = 2 82 [kg] and m3 = 4 64 [kg], respectively; spacecraft inertia I0 = 2 42 [kg m2], links inertias are equal to I1 = 0 06 [kg m2], I2 = 0 06 [kg m2] and I3 = 0 05 [kg m2], respectively. The kinematic equations of the space manipulator from Fig. 1 take the following form: () ,1 ,2 ,3 1,12123 2,12123 123

f pfqf f xpcpslclclc xpspclslsls yyy

e eee e c c

⎛⎞ ⎜⎟ === ⎜⎟ ⎜⎟ ⎝⎠ +−+++ ⎛⎞ ⎜⎟ +++++ ⎜⎟ ⎜⎟ +++ ⎝⎠

θθθθθ θθθθθ θ

123 123,

(21) where c q = cos( q ); s q = sin( q ); () 1 cos; i j j ciy θθ=+ ∑ () 1 sin; i j j siy θθ = =+ ∑ i = 1, …, n and n = 3, respectively. Due to inequality n − k = 3 > 0, we can augment vector pe by additional coordinates 3 pa ∈ of the geometric centre of spacecraft and its orientation, as follows () 1, 2,

c aac

x pfqx θ

⎛⎞ ⎜⎟ == ⎜⎟ ⎜⎟ ⎝⎠ (22)

Disturbing signal d from (1) is assumed in the simulation to take the following form: () () ()

e e

fq q dqF fq q

∂ ⎡⎤ ⎢⎥ ∂ ⎢⎥ = ⎢⎥ ∂ ⎢⎥ ∂ ⎣⎦ (23)

T ,1 ,2 ,

where 2 ∈ denotes external force vector (imitating the action of, e.g., a sub-part to be assembled) exerted on the end-effector. It takes the following form (external forces of a Brownian motion type):

(24) where X(t) ~ N(0, 1); i = 1, 2; 0,25. t ∈ ⎡⎤ ⎣⎦ The actuator matrix B in (1) equals () () 33 3833 , Bspacecraf BqTr θ × ××

⎡⎤ = ⎢⎥ ⎣⎦ (25)

10

2.5

2

1.5

3 ||e|| [m]

1

0.5

0510152025 t[s] 0

0.5

0

1 v 3 [N]

-0.5

0510152025 t[s] -1

Fig. 5. Force v3 of the third thruster for controller (9), (20) Rys. 5. Siła v3 trzeciego pędnika typu cold-gas dla sterownika (9), (20)

0.8

0.6

1 v 1 [N]

0.4

0.2

0510152025 t[s] 0

1 v 2 [N]

0.5

0.4

0.3

0.6 v 4 [N]

0.2

0.1

Fig. 2. The logarithm of the Euclidean norm of task errors e for controller (9), (20) Rys. 2. Logarytm normy Euklidesowej błędow zadaniowych e dla sterownika (9), (20) 0510152025 t[s] 0

Fig. 6. Force v4 of the fourth thruster for controller (9), (20) Rys. 6. Siła v4 czwartego pędnika typu cold-gas dla sterownika (9), (20)

0.5

0

-0.5

0510152025 t[s] -1

Fig. 4. Force v2 of the second thruster for controller (9), (20) Rys. 4. Siła v2 drugiego pędnika typu cold-gas dla sterownika (9), (20)

0.8

0.6

1 v 5 [N]

0.4

0.2

Fig. 3. Force v1 of the first thruster for controller (9), (20) Rys. 3. Siła v1 pierwszego pędnika typu cold-gas dla sterownika (9), (20) 0510152025 t[s] 0

Fig. 7. Force v5 of the fifth thruster for controller (9), (20) Rys. 7. Siła v5 piątego pędnika typu cold-gas dla sterownika (9), (20)

troller (9), (20) are chosen as a = 0 1, b1 = 0 03, b2 = 0 06. In order to simplify numerical computations, rough conservative estimates of wi, i = 1, 2 have been assumed. Hence, coefficients wi were chosen as follows w1 = 1 and w2 = 0 02, respectively. The initial configuration q(0) and velocity () 0 q are assumed to be equal to q(0) = (0, 0, 0, −0.458, 2.19, −0 161)T and ()00, q = respectively. The task realized by controller (9), (20) is to track desired augmented trajectory pd(t) which takes the form

0.5

0

1 v 6 [N]

-0.5

0510152025 t[s] -1

Fig. 8. Force v6 of the sixth thruster for controller (9), (20) Rys. 8. Siła v6 szóstego pędnika typu cold-gas dla sterownika (9), (20)

0.25

0.2

0.15

0.3 v 7 [N]

0.1

0.05

0510152025 t[s] 0

Fig. 9. Force v 7 of the seventh thruster for controller (9), (20) Rys. 9. Siła v7 siódmego pędnika typu cold-gas dla sterownika (9), (20)

0.8

0.6

1 v 10 [Nm]

0.4

0.2

0510152025 t[s] 0

Fig. 12. Torque v10 of the second holonomic manipulator joint for controller (9), (20) Rys. 12. Moment napędowy v10 drugiego ogniwa manipulatora holonomicznego dla sterownika (9), (20)

0.4

0.3

0.2

0.5 v 11 [Nm]

0.1

0510152025 t[s] 0

0.5

1 v 8 [N]

-0.5

0

0510152025 t[s] -1

Fig. 10. Force v8 of the eight thruster for controller (9), (20) Rys. 10. Siła v8 ósmego pędnika typu cold-gas dla sterownika (9), (20)

0.7

0.6

0.5

0.4

0.8 v 9 [Nm]

0.3

0.2

0.1

Fig. 11. Torque v9 of the first holonomic manipulator joint for controller (9), (20)

Rys. 11. Moment napędowy v9 pierwszego ogniwa manipulatora holonomicznego dla sterownika (9), (20)

0.4

0.35

0.45 F x 1 [N]

0.3

0.25

0510152025 t[s] 0.2

Fig. 14. Disturbing external force F x1 acting on the end-effector with controller (9), (20) Rys. 14. Zewnętrzna siła zakłocająca F x1 działająca na koniec efektora dla sterownika (9), (20)

0.52

0.5

0.48

0.54 F x 2 [N]

0.46

0.44

0.42

Fig. 13. Torque v11 of the third holonomic manipulator joint for controller (9), (20) Rys. 13. Moment napędowy v11 trzeciego ogniwa manipulatora holonomicznego dla sterownika (9), (20) 0510152025 t[s] 0

0510152025 t[s] 0.4

Fig. 15. Disturbing external force F x 2 acting on the end-effector with controller (9), (20) Rys. 15. Zewnętrzna siła zakłócająca F x 2 działająca na koniec efektora dla sterownika (9), (20)

The estimates , J B of the uncertain Jacobian matrix J(q) and control matrix B(q) are assumed in the computations to be equal to ˆ

, JJJ =+Δ ˆ , BBB =+Δ (27)

where each element ΔJi,,j, 1,6 ij ≤≤ 1 of matrix ΔJ and each element ΔB i,j, 16, i ≤≤ 111 j ≤≤ of ΔB were randomly generated according to normal distribution 0 1N(0, 1). In order to attain the convergence of task errors e at least less or equal to 10−6, with simultaneous fulfilment of inequalities 01 i v ≤≤ for i = 1 : 8 (forces generated by thrusters of the spacecraft), the following numerical values of gain coefficients are taken for controller (9), (20: w0 = 2, w1 = 6, a1 = 3/5, e = 0 01, c ¢ = 2 4, and c0 = 0.77, respectively. On account of the physical properties of thrusters, we have equivalently modified computations of the thrusters forces vi, i = 1 : 8 as follows [26]. If vi(t) < 0 then vi(t) := 0. Otherwise vi(t) := 2vi(t), where symbol := means assigning a value to a variable. The results of numerical computations are depicted in Figs 2−15. As is seen from Fig. 2, our controller generates tracking errors e, which are practically for 3 t ≥ equal to zero. Steering signals (eight forces generated by thrusters and three torques provided by DC motors of holonomic manipulator) are depicted in Figs 3−13. As is seen from Figs 3−13, control variables vi, i = 1 : 8 fulfil inequalities 01. i v ≤≤ Moreover, all the steering signals v1, ..., v11 are absolutely continuous functions of time. Although, manipulator torques/forces (see Figs 3−13) present continuous mapping, the control signals shown in Figs 3−13 could not be feasible in real case due to the physical limitations of the actuators. In such a case a smoothing of torques/forces should be carried out. In order to eliminate additional phase delay related with recursive low-pass filters, one could apply Newton predictor enhanced Kalman filter (NPEKF) [9] which provides a wide bandwidth and significantly reduced phase lag. Finally, Figs 14−15 present one realization of external disturbing force acting on the end-effector which tracks extended desired trajectory pd(t).

Let’s know that the control algorithm (9), (15) is also able to converge to desired trajectory pd starting from an arbitrary initial configuration. However, in order to maintain control constraints on usually imposed space craft thrusters, the control gains related to space craft should be sufficiently small. In practice, they should be chosen by trials and errors.

5. Conclusions

A new class of task space TSM controllers with finite-time stability when tracking a desired end-effector trajectory by the space manipulator has been proposed in this paper. On account of the fact that external forces acting on the mechanism are unknown, we have offered a sliding technique which seems to be effective in counteracting those undesirable forces. Moreover, our controller provides physically realizable steering signals. Another feature of the control law proposed is the elimination of the Jacobian matrix inverse (or pseudo-inverse) from the trajectory tracking. Instead, estimated extended Jacobian transpose matrix has been used. Applying the Lyapunov stability theory, control strategy (9), (15) is shown to be finite-time stable by fulfilment of practically reasonable assumptions. Numerical computations have shown that controller (9), (20) well performs under conditions of unknown external disturbances, uncertain kinematics and dynamics of the mechanism. Although our transposed estimated Jacobian controller needs some knowledge extracted from

both the system kinematics and dynamics of the mechanism, the approach is able to handle uncertainties in kinematics and dynamics of the space manipulator as well as unknown external forces.

This work was supported by: (i) the European Regional Development Fund within the BB-PL INTERREG V A 2014-2020 Program, project: ”SpaceRegion: cross-border integration of the space sector”, no. 85038043; (ii) internal program of CBK PAN, project TT.402.365.2021; (iii) Marshal of the Lubuskie Voivodeship.

1. Basmadji F.L., Chmaj G., Rybus T., Seweryn K., Microgravity testbed for the development of space robot control systems and the demonstration of orbital maneuvers, [In:] Photonics Applications in Astronomy, Communications, Industry, and High-Energy Physics Experiments 2019, Romaniuk R.S., Linczuk M., (Eds), Vol. 11176, International Society for Optics and Photonics. SPIE, 2019, 1158–1172, DOI: 10.1117/12.2537981.

2. Brogliato B., Neto A.T., Practical stabilization of a class of nonlinear systems with partially known uncertainties, “Automatica”, Vol. 31, No. 1, 1995, 145–150, DOI: 10.1016/0005-1098(94)E0050-R.

3. Cheah C., On duality of inverse Jacobian and transpose Jacobian in task-space regulation of robots, [In:] Proceedings of the IEEE International Conference on Robotics and Automation, ICRA 2006, 2571–2576, DOI: 10.1109/ROBOT.2006.1642089.

4. Cheah C., Lee K., Kawamura S., Arimoto S., Asymptotic stability of robot control with approximate Jacobian matrix and its application to visual servoing, [In:] Proceedings of the 39th IEEE Conference on Decision and Control, Vol. 4, 2000, 3939–3944, DOI: 10.1109/CDC.2000.912329.

5. Defoort M., Floquet T., Kökösy A.-M., Perruquetti W., A novel higher order sliding mode control scheme, “Systems & Control Letters”, Vol. 58, No. 2, 2009, 102–108, DOI: 10.1016/j.sysconle.2008.09.004.

6. Defoort M., Floquet T., Kökösy A.-M., Perruquetti W., Higher order sliding modes in collaborative robotics, [In:] Sliding Modes after the First Decade of the 21st Century: State of the Art, Lecture Notes in Control and Information Sciences, Fridman L., Moreno J., Iriarte R. (Eds), Vol. 412. Berlin, Heidelberg: Springer, 2012, 409–437, DOI: 10.1007/978-3-642-22164-4_15.

7. Galicki M., Inverse kinematics solution to mobile manipulators, “The International Journal of Robotics Research”, Vol. 22, No. 12, 2003, 1041–1064, DOI: 10.1177/0278364903022012004.

8. Galicki M., Constraint finite-time control of redundant manipulators, “International Journal of Robust and Nonlinear Control”, Vol. 27, No. 4, 2016, 639–660, DOI: 10.1002/rnc.3591.

9. Han J.D., He Y., Xu W., Angular acceleration estimation and feedback control: An experimental investigation, “Mechatronics”, Vol. 17, No. 9, 2007, 524–532, DOI: 10.1016/j.mechatronics.2007.05.006.

10. Hu Q., Zhang J., Maneuver and vibration control of flexible manipulators using variable-speed control moment gyros, “Acta Astronautica”, Vol. 113, 2015, 105–119, DOI: 10.1016/j.actaastro.2015.03.026.

11. Jia S., Jia Y., Xu S., Hu Q., Maneuver and active vibration suppression of free-flying space robot, “IEEE Transactions on Aerospace and Electronic Systems”, Vol. 54, No. 3, 2018, 1115–1134, DOI: 10.1109/TAES.2017.2775780.

12. Jia S., Shan J., Finite-time trajectory tracking control of space manipulator under actuator saturation, “IEEE Transactions on Industrial Electronics”, Vol. 67, No. 3, 2020, 2086–2096, DOI: 10.1109/TIE.2019.2902789.

13. Khaloozadeh H., Homaeinejad M. Reza, Real-time regulated sliding mode controller design of multiple manipulator space free-flying robot, “Journal of Mechanical Science and Technology”, Vol. 24, 2010, 1337–1351, DOI: 10.1007/s12206-010-0403-7.

14. Moosavian S.A.A., Dynamics and control of free-flying robots in space: A survey, “IFAC Proceedings Volumes”, Vol. 37, No. 8, 2004, 621–626, DOI: 10.1016/S1474-6670(17)32047-5.

15. Moosavian S.A.A., Papadopoulos E., Free-flying robots in space: an overview of dynamics modeling, planning and control, “Robotica”, Vol. 25, No. 5, 2007, 537–547, DOI: 10.1017/S0263574707003438.

16. Moosavian S.A.A., Papadopoulos E., Modified transpose Jacobian control of robotic systems, “Automatica”, Vol. 43, No. 7, 2007, 1226–1233, DOI: 10.1016/j.automatica.2006.12.029.

17. Nanos K., Papadopoulos E.G., On the dynamics and control of free-floating space manipulator systems in the presence of angular momentum, “Frontiers in Robotics and AI”, Vol. 4, 2017, 26.1–26.19, DOI: 10.3389/frobt.2017.00026.

18. Ratajczak A., Ratajczak J., Trajectory reproduction algorithm in application to an on-orbit docking maneuver with tumbling target, [In:] 12th International Workshop on Robot Motion and Control, RoMoCo 2019, 172–177, DOI: 10.1109/RoMoCo.2019.8787367.

19. Rybus T., Seweryn K., Sasiadek J.Z., Control system for free-floating space manipulator based on nonlinear model

predictive control (NMPC), “Journal of Intelligent & Robotic Systems”, Vol. 85, 2017, 491–509, DOI: 10.1007/s10846-016-0396-2.

20. Seraji H., A unified approach to motion control of mobile manipulators, “The International Journal of Robotics Research”, Vol. 17, No. 2, 1998, 107–118, DOI: 10.1177/027836499801700201.

21. Seraji H., Colbaugh R., Improved configuration control for redundant robots, “Journal of Robotic Systems”, Vol. 7, No. 6, 1990, 897–928, DOI: 10.1002/rob.4620070607.

22. Slotine J.-J.E., Li W., Applied nonlinear control. Englewood Cliffs, New Jersey: Prentice Hall, 1991.

23. Xu W., Hu Z., Yan L., Yuan H., Liang B., Modeling and planning of a space robot for capturing tumbling target by approaching the dynamic closest point, “Multibody System Dynamics”, Vol. 47, 2019, 203–241, DOI: 10.1007/s11044-019-09683-3.

24. Yao Q., Robust finite-time trajectory tracking control for a space manipulator with parametric uncertainties and external disturbances, “Proceedings of the Institution of Mechanical Engineers, Part G: Journal of Aerospace Engineering”, Vol. 236, No. 2, 2022, 396–409, DOI: 10.1177/09544100211014754.

25. Yoshikawa T., Manipulability of robotic mechanisms, “The International Journal of Robotics Research”, Vol. 4, No. 2, 1985, 3–9, DOI: 10.1177/027836498500400201.

26. Zappulla R., Virgili-Llop J., Zagaris C., Park H., Sharp A., Romano M., Floating spacecraft symulator test bed for the experimental testing of autonomous guidance, navigation, and control of spacecraft proximity maneuvers and operations, [In:] AIAA/AAS Astrodynamics Specialist Conference. Calhoun, 2016, 1–26, DOI: 10.2514/6.2016-5268.

W pracy zaproponowano nową klasę sterowników dla manipulatorów kosmicznych przy uwzględnieniu nieznanych, niepożądanych sił zakłócających wywieranych na koniec efektora. W oparciu o odpowiednio zdefiniowane nieosobliwą, końcową rozmaitość ślizgową i teorię stabilności Lapunowa wyprowadzono klasę rozszerzonych estymowanych transponowanych sterowników Jakobianowych, ktore wydają się być efektywne w przeciwdziałaniu nieustrukturyzowanych sił zakłocających. Podejście zilustrowano również obliczeniami numerycznymi dla manipulatora kosmicznego składającego się z bazy napędzanej przez osiem pędników typu cold-gas i manipulatora holonomicznego o trzech parach kinematycznych obrotowych.

ORCID: 0000-0003-0445-1717

ORCID: 0000-0002-9048-9334

ORCID: 0000-0003-2769-33994

ORCID: 0000-0001-7934-8058

Pomiary Automatyka Robotyka, ISSN 1427-9126, R. 26, Nr 4/2022, 37–42, DOI: 10.14313/PAR_246/37

Extremal problems for integral time lag infinite order parabolic systems are studied in the paper. An optimal boundary control problem for distributed infinite order parabolic systems in which integral time lags appear in the Neumann boundary conditions is solved. Such equations constitute in a linear approximation a universal mathematical model for many diffusion processes (e.g., modeling and control of heat transfer processes). The time horizon is fixed. Using the Dubovicki-Milutin framework, the necessary and sufficient conditions of optimality for the Neumann problem with the quadratic performance indexes and constrained control are derived.

1. Introduction

Extremal problems play an increasing role in applications of control theory [20]. Despite a great variety of these problems, they can be converted by a unified functional-analytic framework, first suggested by Dubovicki and Milutin.

In 1962 Dubovicki and Milutin found a necessary condition for an extremum in the form of an equation set down in the language of functional analysis. They were able to derive, as special cases of this condition, almost all previously known necessary extremum conditions and thus to recover the lost theoretical unity of the calculus of variations.

In particular, in the paper [6], the Dubovicki-Milutin approach was adopted for solving optimal control problems for parabolic-hyperbolic systems. The existence and uniqueness of solutions of such parabolic-hyperbolic systems with the Dirichlet boundary conditions are discussed. Using the Dubovicki-Milutin framework, the necessary and sufficient conditions of optimality for the Dirichlet problem with the quadratic performance indexes and constrained control are derived.

In the papers [9–13], the Dubovicki-Milutin approach was used for solving boundary optimal control problems for the case of time lag parabolic equations [9] and for the case

of parabolic equations involving time-varying lags [10, 11], multiple time-varying lags [12], and integral time lags [13] respectively.

The sufficient conditions for the existence of a unique solution of such parabolic equations [9–13] are presented. Such equations with deviating arguments are a well-known mathematical tool for representing many physical phenomena.

Consequently, in the papers [9–13], the linear quadratic problems of parabolic systems with time lags given in various forms (constant time lags [9], time-varying lags [10, 11], multiple time-varying lags [12], integral time lags [13], etc.) were solved.

Extremal problems for integral time lag infinite order parabolic systems are investigated. The purpose of this paper is to show the use of the Dubovicki-Milutin theorem [11] in solving optimal control problems for distributed parabolic systems.

As an example, an optimal boundary control problem for a system described by a linear infinite order partial differential equation of parabolic type in which integral time lag appears in the Neumann boundary condition is considered. Such equation constitutes in a linear approximation universal mathematical model for many diffusion processes (e.g., modeling and control of heat transfer processes). The right-hand side of this equation and the initial condition are not continuous functions usually, but they are measurable functions belonging to L 2 or L ∞ spaces. Therefore, the solution of this equation is given in a certain Sobolev space [17]. The performance indexes have the quadratic form. Finally, we impose some constraints on the boundary control. Using the Dubovicki-Milutin theorem, the necessary and sufficient conditions of optimality with the quadratic performance indexes and constrained control are derived for the Neumann problem.

h is an integral time lag such that (),,hab ∈ Ψ0 is an initial function defined on Σ0

Let Ω be a bounded set of Rn with smooth boundary Γ. We define the infinite order Sobolev space H ∞{a a, 2}(Ω) of functions Φ(x) defined on Ω [1, 2] as follows

{} ()()() 2 2 0 ,2: HaxCaD α αα α

∞ ∞∞ =

⎧⎫ ⎪⎪ Ω=Φ∈ΩΦ<∞ ⎨⎬ ⎪⎪ ⎩ ⎭ ∑ (1)

where C ∞(Ω) is a space of infinite differentiable functions, a a 0 is a numerical sequence and ‖ ‖2 is a norm in the space L2(Ω), and () () 1 1 n n

D xx

α α α α ∂ = ∂∂ (2) where a = (a1, …, a n) is a multi-index for differentiation, 1 n i i αα = = ∑

The space H –∞{a a, 2}(Ω) [1, 2] is defined as the formal conjugate space to the space H ∞{a a, 2}(Ω), namely (3) where () 2L α Ψ∈Ω and 2 2 0 aαα α

∞ Ψ<∞ ∑

The duality pairing of the spaces H ∞{a a, 2}(Ω) and H –∞{a a, 2}(Ω) is postulated by the formula (4) where

From above, H ∞{a a, 2}(Ω) is everywhere dense in L2(Ω) with topological inclusion and H –∞{a a, 2}(Ω) denoted the topological dual space with respect to L2(Ω) so we have the following chain

The parabolic operator ()At t ∂ + ∂ in the state equation (1) satisfies the hypothesis of Lions and Magenes [17] and A(t) is given by and (9) is an infinite order elliptic partial differential operator [3]. (10) where: A

y γ ∂ ∂ is a normal derivative at Γ, directed towards the exterior of Ω, cos(n, xi) is an i-th direction cosine of n, n-being the normal at Γ exterior to Ω and ()()() ,,, b a qxtyxthdhvxt =−+ ∫ (11)

Now we shall present the sufficient conditions for the existence of a unique solution of the mixed initial-boundary value problem (5)–(8) for the case where the boundary control () 2vL∈Σ For this purpose we introduce the Sobolev space H ∞,1(Q) ([17], vol. 2, p. 6) defined by (12)

which is the Hilbert space normed by (13) where the space H 1(0,T;  H 0(Ω)) is defined in Chapter 1 of [17], vol. 1, respectively.

Conditions

we formulate the control problem for the system described by the following parabolic equation:

The existence of a unique solution for the mixed initial-boundary value problem (5)–(8) on the cylinder Q can be proved using a constructive method, i.e., first, solving (5)–(8) on the subcylinder Q1 and in turn on Q2, etc. until the procedure covers the whole cylinder Q. In this way the solution in the previous step determines the next one. Then the following result is fulfilled [15]:

Theorem 1: Let y0, Ψ0, v, and u be given with () 2 00 , L Ψ∈Σ () 2vL∈Σ and

Then, there exists a unique solution for the mixed initial-boundary value problem (5)–(8). Moreover, for j = 1, …, K.

In the sequel, we shall fix

In this paper we shall consider the optimal boundary control problem i.e., () 2vL∈Σ

Let us denote by the space of states and by () 2UL∈Σ the space of controls. The time horizon T is fixed in our problem.

The performance index is given by (14)

where li ≥ 0 and l1 + l2 > 0; zd is a given element in () 2 LQ and N is a strictly positive linear operator on () 2L Σ into () 2L Σ

From the Theorem 1 [15] it follows that for any ad vU ∈ the cost function (14) is well-defined since We assume the following constraints on control: ad vU ∈ is a closed, convex set with non-empty interior, a subset of U. (15).

The optimal control problem (5)–(8), (14), (15) will be solved as the optimization one in which the function u is the unknown function.

Taking advantage of the Dubovicki-Milutin theorem [11] we shall derive the necessary and sufficient conditions of optimality for the optimization problem (5)–(8), (14), (15).

The solution of the stated optimal control problem is equivalent to seeking a pair which satisfies the equation (5)–(8) and minimizing the performance index (14) with the constraints on control (15).

We formulate the necessary and sufficient conditions of the optimality in the form of Theorem 2.

The solution of the optimization problem (5)–(8) exists and it is unique with the assumptions mentioned above; the necessary and sufficient conditions of the optimality are characterized by the following system of partial differential equations and inequalities:

State equation (16)

Outline of the proof

Due to the Dubovicki-Milutin theorem [11], we approximate the set representing the inequality constraints by the regular admissible cone (RAC), the equality constraint by the regular tangent cone (RTC), and the performance index by the regular improvement cone (RFC).

a) Analysis of the equality constraint

The set Q1 representing the equality constraint has the form (20)

Adjoint equations (17)

We construct the regular tangent cone (RTC) of the set Q1 using the Lusternik theorem (Theorem 9.1 [5]). For this purpose, we define the operator P in the form (21)

The operator P is the mapping from the space () () ¢ HQL ∞ ×Σ into the space

Maximum condition (18)

Moreover () (19)

The Fréchet differential of the operator P can be written in the following from: (22)

In fact, t ∂ ∂ (Theorem 2.8 [18]), A(t) (Theorem 2.1 [16]) and Aγ ∂ ∂ (Theorem 2.1 [17]) are linear and bounded mappings.

By virtue of the Theorem 1 [15], we can prove that P’ is the operator “one to one” from the space onto

Considering that the assumptions of Lusternik’s theorem are fulfilled, we can write down the regular tangent cone (RTC) for the set in a point () 00 , yv in the form

() () () () () {}0000 1 ,,,;,,0RTCQyvyvEPyvyv=∈= ′ (23) where the cone (23) is the subspace (Theorem 9.1 [5]).

Therefore, using Theorem 10.1 [5] we know the form of the functional belonging to the adjoint cone

() () () () 0011,0,,, fyvyvRTCQyv =∀∈ (24)

b) Analysis of the constraint on controls

The set Q2 = Y × Uad representing the inequality constraints is a closed and convex one with non-empty interior in the space E.

By virtue of Theorem 10.5 [5] we find the functional belonging to the adjoint regular admissible cone (RAC), i.e. () () () 00 22,,, fyvRACQyv ∗ ⎡⎤ ∈ ⎣⎦

We notice that if E1, E2 are two linear topological spaces, then the adjoint space to E = E1 × E2 has the form () {} 121122 ,;, EffffEfE ∗∗∗ ==∈∈ and f(x) = f1(x1) + f2(x2)

So we note the functional () 2 , fyv as follows () () () 212 , fyvfyfv ′′ =+ (25) where () 1 0 fyyY ′ =∀∈ (Theorem 10.1 [5]), () 2 fv ′ is a support functional to the set Uad in a point v0 (Theorem 10.5 [5]).

c) Analysis of the performance functional

Taking advantage of Theorem 7.5 [5], we find the regular improvement cone (RFC) of the performance index (14) () () () () () {}0000 ,,,;,,0RFCIyvyvEIyvyv=∈< ′ (26)

where: () () 00 ,, Iyvyv ′ is the Fréchet differential of the performance index (14) and it can be written as

Using the definition of the support functional [5] and dividing both members of the obtained inequality by λ0, we finally get (32)

The last inequality is equivalent to the maximum condition (18).

In order to prove the sufficiency of the derived conditions of the optimality, we use the fact that constraints and the performance index are convex and that the Slater’s condition is satisfied (Theorem 15.3 [5]). In fact, there exists a point () 2 ,int yvQ ∈ such that () 1 ,.yvQ ∈ This fact follows immediately from the existence of non-empty interior of the set Q2 and from the existence of the solution of the equation (5)–(8) as well. The uniqueness of the optimal control follows from the strict convexity of the performance index (14).

The above remarks complete the proof of Theorem 2. One may also consider the similar optimal control problem with the performance index (33) where zΣd is a given element in () 2L Σ

On the basis of Theorem 10.2 [5] we find the functional belonging to the adjoint regular improvement cone (RFC), which has the form (27) where: l0 > 0.

d) Analysis of Euler-Lagrange’s equation

The Euler-Lagrange equation for our optimization problem has the form 3 1 0 i i f = ∑ (28)

Let p(x,t) be the solution of (14) for (y0 , v0).

Let us denote by y the solution of (),0Pyv = ′ for any fixed v Then taking into account (24), (25) and (27) we can express (28) in the form (29)

From the Theorem 1 [15] and the trace theorem [17] for each () 2 , vL∈Σ there exists a unique solution with Thus () ˆ , Iyv is well-defined. Then the solution of the formulated optimal control problem is equivalent to seeking a pair which satisfies the equation (5)–(8) and minimizing the cost function (33) with the constraints on control (15).

We can prove the following theorem:

The solution of the optimization problem (5)–(8), (33), (15) exists and it is unique with the assumptions mentioned above; the necessary and sufficient conditions of the optimality are characterized by the following system of partial differential equations and inequalities: State equation (16)

Adjoint equations (34)

We transform the first component of the right-hand side of (29) introducing the adjoint variable by adjoint equations (17).

After transformations we get

Substituting (30) into (29) gives

(30)

Maximum condition (35)

The idea of the proof of the Theorem 3 is the same as in the case of the Theorem 2.

In the case of performance indexes (14) and (33) with λ1 > 0 and λ2 = 0, the optimal control problem reduces to the minimizing of the functional on a closed and convex subset in a Hilbert space. Then, the optimization problem is equivalent to a quadratic programming one [7, 8, 14] which can be solved by the use of the well-known algorithms, e.g., Gilbert’s [4, 7, 8, 14] ones. The practical application of Gilbert’s algorithm to optimal control problem for a parabolic system with boundary condition involving a time lag is presented in [14]. Using the Gilbert’s algorithm, a one-dimensional numerical example of the plasma control process is solved [14].

1. Dubinskii Ju.A., Sobolev spaces of infinite order and behavior of solution of some boundary value problems with unbounded increase of the order of the equation, “Matiematiczeskii Sbornik”, Vol. 98, 1975, 163–184.

2. Dubinskii Ju.A., Non-trivality of Sobolev spaces of infinite order for a full Euclidean space and a Tour’s, “Matiematiczeskii Sbornik”, Vol. 100, 1976, 436–446.

3. Dubinskii Ju.A., About one method for solving partial differential equations, “Doklady Akademii Nauk SSSR”, Vol. 258, 1981, 780–784.

4. Gilbert E.S., An iterative procedure for computing the maximum of a quadratic form on a convex set, “SIAM Journal on Control”, Vol. 4, No. 1, 1966, 61–80, DOI: 10.1137/0304007.

The derived conditions of the optimality (Theorems 2 and 3) are original from the point of view of application of the Dubovicki-Milutin theorem [11] in solving optimal control problems for infinite order parabolic systems in which integral time lags appear in the Neumann boundary conditions. The proved optimization results (Theorems 2 and 3) constitute a novelty of the paper with respect to the references [7, 8, 14] concerning application of the Lions framework [16] for solving linear quadratic problems of optimal control for the case of the Neumann problem. The results presented in the paper can be treated as a generalization of the results obtained in [9–13] to the case of integral time lags appearing in the Neumann boundary conditions.

The obtained optimization theorems (Theorems 2 and 3) demand the assumption dealing with the non-empty interior of the set Q2 representing the inequality constraints. Therefore, we approximate the set Q2 by the regular admissible cone (RAC) (if intQ2 = f then this cone does not exist) [11]. The obtained results can be reinforced by omitting the assumption concerning the non-empty interior of the set Q2 and utilizing the fact that the equality constraints in the form of the parabolic equations are “decoupling”. The optimal control problem reduces to seeking 0 2vQ ∈ ′ and minimizing the performance index I(v). Then, we approximate the set 2Q ′ representing the inequality constraints by the regular tangent cone (RTC), and for the performance index I(v) we construct the regular improvement cone (RFC) [11].

The proposed methodology based on the Dubovicki-Milutin approach can be presented on a specific case study concerning hyperbolic systems described by infinite order partial differential equations of the hyperbolic type in which time lags appear in the integral form both in the state equations and in the Neumann boundary conditions.

Moreover, the Dubovicki-Milutin framework can be applied to solving optimization problems for a sophisticated case of infinite order parabolic systems with deviating arguments given in the integral form such that () 0, hb ∈ with a = 0.

Another direction of research would be the analysis of case studies with numerical examples concerning the determination of optimal boundary control with constraints for infinite order parabolic systems with integral time lags.

An interesting possible future research direction may consist in formulation of extremal problems for advanced modern control strategies, for example, event-based control [19].

5. Girsanov I.V., Lectures on Mathematical Theory of Extremum Problems, Publishing House of the University of Moscow, Moscow 1970 (in Russian).

6. Kowalewski A., On optimal control problem for parabolic-hyperbolic systems, “Problems of Control and Information Theory”, Vol. 15, 1986, 349–359.

7. Kowalewski A., Optimization of parabolic systems with deviating arguments, “International Journal of Control”, Vol. 72, No. 11, 1999, 947–959, DOI: 10.1080/002071799220498.

8. Kowalewski A., Optimal Control of Infinite Dimensional Distributed Parameter Systems with Delays, AGH University of Science and Technology Press, Cracow, 2001.

9. Kowalewski A., Miśkowicz M., Extremal problems for time lag parabolic systems, Proceedings of 21st International Conference on Process Control (PC), 446–451, Strbske Pleso, Slovakia, June 6-9, 2017, DOI: 10.1109/PC.2017.7976255.

10. Kowalewski A., Extremal problems distributed parabolic systems with boundary conditions involving time-varying lags, Proceedings of 22nd International Conference on Methods and Models in Automation and Robotics (MMAR), 447–452, Międzyzdroje, Poland, August 28–31, 2017.

11. Kowalewski A., Extremal problems for parabolic systems with time-varying lags, “Archives of Control Sciences”, Vol. 28, No. 1, 2018, 89–104, DOI: 10.24425/119078

12. Kowalewski A., Extremal problems distributed parabolic systems with multiple time-varying lags, Proceedings of 23rd International Conference on Methods and Models in Automation and Robotics (MMAR), 791–796, Międzyzdroje, Poland, August 27-30, 2018.

13. Kowalewski A., Miśkowicz M., Extremal problems for integral time lag parabolic systems, Proceedings of 24th International Conference on Methods and Models in Automation and Robotics (MMAR), 7–12, Międzyzdroje, Poland, August 26–29, 2019.

14. Kowalewski A., Duda J., On some optimal control problem for a parabolic system with boundary condition involving a time-varying lag, “IMA Journal of Mathematical Control and Information”, Vol. 9, No. 2, 1992, 131–146, DOI: 10.1093/imamci/9.2.131.

15. Kowalewski A., Krakowiak A., Time-optimal boundary control of an infinite order parabolic system with time lags, “International Journal of Applied Mathematics and Computer Science”, Vol. 18, No. 2, 2008, 189–198.

16. Lions J.L., Optimal Control of Systems Governed by Partial Differential Equations, Springer-Verlag, Berlin-Heidelberg, 1971.

17. Lions J.L., Magenes E., Non-Homogeneous Boundary Value Problems and Applications, Vols 1 and 2, Springer-Verlag, Berlin-Heidelberg, 1972.

Adam Kowalewski was supported under the research program no. 16.16.120.773 at AGH University of Science and Technology, Krakow, Poland. Marek Miśkowicz was supported by the Polish National Center of Science under Grant DEC-2018/31/B/ST7/03874.

18. Maslov V.P., Operators Methods, “Nauka”, Moscow 1973 (in Russian).

19. Miśkowicz M. (Ed.), Event-Based Control and Signal Processing, CRC Press, 2016.

20. Ioffe A.D., Tihomirov V.M., Theory of Extremal Problems, Elsevier, 2009.

Zaprezentowano ekstremalne problemy dla systemów parabolicznych nieskończonego rzędu z całkowymi opóźnieniami czasowymi. Rozwiązano problem optymalnego sterowania brzegowego dla systemów parabolicznych nieskończonego rzędu, w których całkowe opóźnienia czasowe występują w warunkach brzegowych Neumanna. Tego rodzaju równania stanowią w liniowym przybliżeniu uniwersalny model matematyczny dla procesów dyfuzyjnych. Korzystając z metody Dubowickiego-Milutina wyprowadzono warunki konieczne i wystarczające optymalności dla problemu liniowo-kwadratowego.

ORCID: 0000-0001-5792-2039

ORCID: 0000-0003-3737-4690

Abstract: In this paper the novel control and communication scheme designed to ease the development and maintenance of the robotic astronomical telescope device is presented. The proposed solution allows the user to remotely access any signal in the controller of the telescope without imposing any additional overhead during telescope operation. The implemented scheme can be used by both an automated control system and human operators for easy supervision, control, and maintenance of the device.

1. Introduction

Development of autonomous robotic telescopes poses considerable challenges concerning reliability and maintainability of the supervised system. Devices designed with the aim of deployment in distant isolated locations, with possibly harsh and changing environmental conditions, require special means of supervision and maintenance to ensure their constant and infallible operation. Ivanescu et al. [6] presented some challenges of the telescope working in such conditions, which resulted in the need for constant supervision by a human operator. The demand for development of modern systems that allow easy and automated supervision or maintenance has recently been reported by Marchiori et al. [11]. Importantly, proposed solutions have to be lightweight in terms of computational resources as the performance of the telescope controller cannot be hindered during normal operations. Moreover, the need for a simplified graphical user interface for the control of the telescopes by the final user has also been reported, e.g. Abareshi et al. [1] with growing interest in taking advantage of modern web-based technologies as used by Sadeh et al. [12] or Edwards et al. [3]. Satisfaction of all these requirements introduces significant difficulty for any team working on the development of automated robotic telescopes.

In this paper a novel framework for software architecture designed to ease the development and maintenance of autonomous telescopes is presented. Recently, this architecture has been successfully employed in the SkyLab laboratory established at the Poznan University of Technology in 2018. The pro-

gresses in development of the SkyLab were already reported by Kozlowski et al. [8]; Krysiak et al. [10]; Kozłowski et al. [9].

The proposed framework takes advantage of an internal communication scheme, which makes it possible to monitor every single signal in the software realization of the telescope controller without affecting the real-time operation of the control loop. Multiple client applications able to communicate with the controller were implemented using this approach. They include services used to automatically synchronize the clock of the controller, acquire and store the data produced during the operation of the telescope, and control of the telescope using a graphical interface, either for maintenance or regular observations. The use cases presented in this paper confirm the wide applicability of the proposed framework.

The rest of the paper is organized as follows. Section 2 presents the overall structure of the discussed telescope system. In Section 3 details of the internal communication scheme are described. Section 4 presents the client application designed mainly for astronomical operations and Section 5 describes the client application for maintenance and development. In Section 6 the example of some possibilities of the proposed system is presented. Section 7 concludes the paper.

The considered software architecture was designed for a set of astronomical telescope mounts currently developed at the Institute of Automatic Control and Robotics. The discussed collection consists of autonomous robotic mounts for a single telescope of diameter of either 0.5 m or 1 m. Currently, all of the SkyLab mounts work under the same framework presented in this paper. The example of the mount used in SkyLab is given in Fig. 1.

The developed solution consists of several interconnected devices including Mimas – Spartan 6 FPGA, microcontroller (MCU) STM32H743ZI2 with the high performance CPU ARM Cortex-M7 operating up to 480 MHz, an electronic security system with energy dissipation function (UZE), the compu-

Fig. 1. The mount carrying a 0.5 m class telescope (PlaneWave CDK20 0.51-m f/6.8 Corrected Dall-Kirkham with resolving power 0.28 arcsec and camera FLI PL16803 CCD 4096 × 4096 9 μm pixels with resolution 0.54 × 0.54 arcsec/px and field of view 0.61 × 0.61 deg) used in SkyLab Rys. 1. Montaż z teleskopem klasy 0,5 m (PlaneWave CDK20 0.51-m f/6.8 Corrected Dall-Kirkham z maksymalną zdolnością rozdzielczą 0,28 arcsec oraz camerą FLI PL16803 CCD 4096 × 4096 9 μm piksele o rozdzielczości 0,54 × 0,54 arcsec/px z polem widzenia 0,61 × 0,61 deg) stosowany w SkyLab

ter Raspberry Pi 4 (RPI) and the miniature NTP/PTP time server NTS-pico3 (GPS). The architecture of this system, with all channels of data exchange between the nodes, is graphically presented in Fig. 2.

The STM32 is a main real-time controller which is responsible for performing low-level tasks such as processing data, computing trajectory, controlling motors and overviewing all external devices to ensure faultless operation. The control system loop is designed to work with a 10 kHz frequency for both axes of the telescope mount. Using the I2C interface, the STM32 communicates with the UZE module to obtain the temperature and current measurements of the motors and to adjust a supply voltage or energy dissipation function settings. The main controller program is written in a standard C/C++ programming language. Here, the novel programming framework introduced by Gawron and Kozłowski [4] was employed to manage the code structure and ensure the exchange of information between separate modules. The FPGA is used mainly for signal processing and gathering of measurements, including

telescope positions, status of encoders, supply voltage and current of the drives, which later are sent to the main STM32 controller. The communication between FPGA and STM32 is made possible by employing a fast SPI interface with STM32 in a role of a main device. FPGA is also tasked with exercising custody over drives controller as a watchdog and, in case of failure, interrupt PWM signals which control the drives. The RPI runs Linux-based Raspbian operating system with realtime Preempt RT kernel modified to incorporate support of the Precise Time Protocol (PTP). The real-time system is crucial to guarantee a minimum latency between external interrupts and the interrupt handling, and consistent behavior of thread scheduling. Due to its networking capabilities, the RPI platform serves mainly as a relay for communication between the STM32 controller and external client applications. The communication between STM32 and RPI through the SPI interface is adjusted to use the ASTCom communication library, which is described in detail in Section 3. As the RPI is the only computer-scale node in the considered system, it also hosts several of those client services. The Relay program provides service support with the SPI interface and transmission of data between STM32 and external clients, including a Virtual Star Server (VSS), Database Relay, Robot Supervisor Panel (RSP) or Time Synchronizer (TimeS). The task of Database Relay is to intercept the data streaming from the STM32 and save all transmitted data to an external database for future reference. The Virtual Star application is designed to ensure a proper operation of the telescope in astronomical observation tasks, while diagnostic operations can be carried out through a multi-function web application RSP. The RPI communicates with the external world by Ethernet connection, taking advantage of Websocket or HTTP protocol.

In a case of astronomical observations, an availability of reliable clock source is a crucial requirement to obtain a high level of tracking accuracy, as it is vital to calculate a position of an observed object in a given time instant. Thus, a custom time

Fig. 2. Software, hardware and communication architecture of the telescope system Rys. 2. Oprogramowanie, osprzęt i architektura systemu komunikacji w układzie teleskopu

synchronization module was developed using a proposed communication scheme. To this end, a GPS module is employed, which is connected to the RPI using an Ethernet standard. This enables the RPI to periodically update its internal system clock through the PTP protocol, as described in Cochran et al. [2]. However, in order to employ the PTP synchronization, the system kernel has to provide control of the hardware clock and packet timestamping at the hardware or software layer, which is ensured by the aforementioned kernel modifications. Once the synchronization of its system clock is performed, the RPI can be treated as the main source of time measurements in the considered system. By taking advantage of this notion, the program TimeS reads the synchronized system timestamp of the hindmost full second and transfers it in the UTC format to the STM32 using the proposed ASTCom approach, thus updating the internal clock of the telescope control system. In order to avoid time diverging, an additional one 1PPS (a pulse per second) signal is routed directly from the GPS module into one of the digital inputs of the STM, which enables the control system to precisely assign the received UTC timestamp to the time instant marked by the 1PPS pulse.

Data storage during the operation of the automatic control system is an element of high importance, as it was emphasized by Story et al. [13]. In particular, thanks to recorded signals, it is possible to conduct an in-depth analysis of the conducted experiments, as well as to diagnose the cause of the possible system defects based on the data collected over a wide time horizon. An open-source time series database InfluxDB installed on an external server with plenty of storage space is used for gathering and saving data from the controlled system. As has been mentioned earlier, the program Database Relay, running on the RPI machine, catches streamed signals and saves data into the database using InfluxDB’s custom command language similar to mySQL by the HTTP protocol. An arbitrary choice of stored data is given to the user of the telescope system and these can be defined using the RSP and VS applications, both of which are equipped with a user-friendly GUI. To access the database and download the data series, one can make use of the HTTP protocol directly or take advantage of a custom application that works as a module of the MATLAB environment. Any calculations, visualization, or data processing can also be done in the MATLAB program.

serialization of custom defined classes, the special macro AST_ VARIABLE_DEFINE is declared which, when included in the class definition, declares a set of functions used to serialize and deserialize all variables of the chosen class. The types of variables and a proper way of their processing are discovered automatically by the library. Thus, once a class is defined, a call to a single function automatically serializes an entire content of its object, including any member objects that were implemented taking advantage of the AST_VARIABLE_DEFINE. A globally accessible Collection class is then defined, which can be called to recursively scan and register any object of the ASTVariable type. During this process, information about name, type, address of data in physical memory and addresses of serializing and deserializing functions of the object are stored in memory of the Collection singleton. Due to to the recursiveness of this operation, it is sufficient to register only the top level object, provided that all member objects are also of the ASTVariable type. Thus, if any change in the structure of the software is made, there is no requirement for any additional modifications outside the affected classes, as their proper registration is automatically ensured by the top level class. It is of major significance that all of these operations are performed either at compile time or on the device startup and does not in any way slow down main computation tasks executed online by a CPU. Once the initial registration of objects is performed, the current state of any signal in the telescope can be easily obtained by invoking the Collection object with name and type of the required variable.

In order to facilitate the communication and data exchange between various nodes of the telescope environment, the novel communication protocol called the Astronomic Communication Library (ASTCom) was proposed and implemented. The library provides an interface for serialization and real-time exchange of data between various devices through the Websocket protocol. The serialization itself is performed using a custom format similar to the well-known MessagePack format enhanced with several extensions to accommodate features of the proposed scheme. Mainly, the possibility to dynamically configure the set of exchanged data at run-time is introduced.

The basis of the ASTCom library design is the system of variable and class registration, which allows the library to discover each and every desired variable declared in the code of the telescope controller. To this end, a conceptual ASTVariable is defined as any variable or class that can be serialized by the ASTCom library. Serialization procedures for multiple basic types (e.g. integer, float, string, array, etc.) are predefined by the library itself. Moreover, ASTVariable can also represent a function with an arbitrary signature. In order to enable

In order to make use of the proposed approach, two separate modules are implemented – the Endpoint module, to be employed on board of the telescope, and the Client module, run in each of the client applications. Both modules are derived from the single Interface class. These two are then used to establish communication between various devices in the ASTCom network. To this end, a series of hard-coded ASTCommands is defined and used to exchange basic commands between devices. These are in nature similar to functions of the Modbus protocol and are first used to establish a formal connection between the nodes, during which version compatibility is verified and access rights are granted through password verification. Each connection is represented in both parties by a separate Connection class object, which stores all information necessary to carry on the communication. It has to be noted that multiple Client devices can be simultaneously connected to a single Endpoint and their number can be limited by the Endpoint to reduce the performance impact. Once the connection is defined, the Client uses proper ASTCommands to query the Endpoint device and request it in order to define new ASTMessages – virtual structures consisting of several ASTVariables with a unique ID number assigned. Once the Endpoint receives such request, it queries the Collection for desired entries and copies pointers to serialization functions. Hence, once the ASTMessage is defined in the Endpoint, it is directly available for use, and no additional overhead is created beside brief configuration of the messages, which can be done before the proper start of operation of the telescope system. On the Client side, the newly defined ASTMessage is also bound to a chosen locally defined variable of the same type. It is noteworthy that as the serialization procedures of the basic types are hard-coded into the library, the Client device is not required to have counterparts of the defined data in its source code, as they can always be built in the runtime from objects of basic types. On both sides, defined ASTMessages are stored in the MessageRegister class object, with a notion that the Endpoint defines a single register used by all connections, while the Clients assign separate storage for each connection. The process of ASTMessage definition can be seen as creating of a bond between the local and remote variables on two devices. In case of an ASTMessage containing

an ASTVariables representing the function, the bound is made between the function on one device and variables used as its arguments on the other. Such messages containing references to a function can be transferred only in one direction, as arguments can only be written to functions. A graphical scheme showing an example of this binding is given in Fig. 3.

The proposed approach was first implemented in C++ code, as this is the language of the main controller of the telescope. To enable support of various client applications, the Client class with all necessary dependencies was later ported into JavaScript (using LLVM/Clang-based Emscripten compiler), pure C and C# (using p/invoke feature).

Fig. 3. Example of variable binding in ASTCom. Note that function reset() is called without any argument and the remote variable int pos is used to invoke a local callback function. Variables float tau and float var4 can be transferred in both directions Rys. 3. Przykład łączenia zmiennych w ASTCom. Zauważyć można, że funkcja reset() wywoływana jest bez argumentów, a zdalna zmienna int pos wykorzystywana jest do wywołania funkcji lokalnej. Zmienne float tau oraz float var4 mogą być przesyłane w obu kierunkach

Two modes of data exchange are supported by the ASTCom library – the private channel communication used to transfer data between two devices and the stream channel used by the Endpoint to broadcast large amounts of data to all connected clients. All of the aforementioned ASTCommands are also sent through the private channel. Importantly, the ASTCom library does not specify a precise transport layer of the channels, and thus the communication can be carried out using several medias, including Websocket, TCP/IP or SPI communication with both channels supported by a single connection or separated between two independent routes, e.g. two separate Websocket connections. The Client can request to exchange the data through one of these communication channels. In case of the private channel, the Client requests a single exchange of data of a chosen ASTMessage in the desired direction – the data can be both read from or written to the telescope. Once the command is carried out, the values of the bound variables are identical on both devices. If the considered ASTMessage contains ASTVariables representing the function, it is remotely invoked, which can be used to control the behavior of the telescope controller.

While the private channel is designed mainly to control the telescope by the user or the supervisor, the stream channel is intended for constant acquisition of information about the state of the adevice. To this end, the Client may request the Endpoint to start recording chosen ASTMessages with a desired frequency. Currently, on the considered setup of the telescope controller, the recording with a frequency up to 10 kHz is possible. The Endpoint executes such a command, by cyclically serializing the value of requested variables into a local predefined buffer. Once a certain volume of data is acquired, the data is flushed and sent to all connected Clients, which receive the packets containing the amassed record of state of the telescope in the previous time instants. Importantly, Clients may bind the received data to some custom callback functions and this way process each sample of data separately upon arrival. Thus, a significant amount of data can be exchanged between devices to allow constant monitoring of the telescope performance.

In order to enable the user to interact with the telescope and perform standard astronomical calculations, the automated control VirtualStar (VS) system was developed. It is responsible for real-time data acquisition and processing (e.g. axes states are continuously monitored) and, most importantly, it is a complex tool for calculation of desired telescope trajectories based on the movements of celestial objects. All these computations are possible with the use of commonly known astronomical libraries (SOFA, SGP4) as reported by Vallado et al. [14]; Hohenkerk [5]. Moreover, this software is responsible for management of the graphical presentation layer and processing of user requests. In order to ensure full system scalability and security in data storage, the VirtualStar system design consists of two separate subsystems (shown in Fig. 2 as the VSS and VSC modules). C# and .Net Core 3.1 tools were chosen to implement all subsystem components, including open source astronomical libraries – nuget packages written as wrappers for C++ source tools. The server-based subsystem part has been built specifically for the linuxarm distribution, while the client part is only available as the Windows application.

The basis of the VirtualStar Server (VSS) structure is the ASTCom Client module which enables the exchange of the current state of any signal processed by the STM32 controller. Directly at startup, the ASTMessages are defined according to the rules specified by the ASTCom modules. A custom JSON-based configuration file contains a set of variable and function names paired with specific ASTCom library signals, which are used to properly configure the connection. Then, after a successful connection, each signal is transferred to the graphical presentation layer or sent to other subroutines within the VSS module, such as the kinematic calibration module (known as pointing model), for feature control tasks of the telescope system. The computation and data preparation are completely independent of the telescope mechanics, making it possible, for example, to continuously provide trajectory samples while tracking satellites without waiting to reach a previous point. Connected to the ASTCom Endpoint, VSS takes advantage of the private communication channel to query the Endpoint device and request it to perform the following commands: initialize/ start/reset trajectory, getting a free buffer space, rotation around the horizontal axis (control of the altitude angle), rotation around the vertical axis (control of the azimuth angle), and sending next trajectory positions. In addition, using this mode, it also reads signals considered to be the general state of the device: telescope positions from encoders (instrumental altitude and azimuth angles), operating state, status and potential errors of each axis, and current time measured in microseconds. Meanwhile, the stream channel communication is used by the VSS to receive continuous tracking errors data with a specified frequency. Then, these position errors are stored in internal data arrays until they are forwarded to the VirtualStar client’s presentation layer, described briefly below. It should be noted that both the mount driver and ASTCom library process requests synchronously, while the VirtualStar system handles all commands fully asynchronously. This means that at the VSS level it was necessary to include a synchronization

module, thanks to which overloads and communication errors were avoided. It is a simple mutex-based implementation that always passes only one thread to the requesting function and holds all others until it is released.

The user interface of the VirtualStar is designed as a standalone desktop VirtualStar Client application based on the Windows Presentation Foundation (WPF) framework and .Net Core 3.1. Its basic structure consists of the background communication layer and the graphical user interface with data presentation features. The exchange of data between the VSS and the VSC is performed on a separated communication layer using a Websocket protocol. All high-level application commands inputted by the user through the graphical layer are immediately converted to messages in JSON format and sent to the VSS, where they are serialized to particular commands recognized by the mount driver. Once a command is sent to the VSS, the VSC waits for the response stating that the command was correctly classified, executed, and completed successfully. Furthermore, the communication with the VSS is kept active by using a watchdog, which informs about any possible gaps in sending requests even though the Websocket state is still open. By applying a continuous time synchronization with the mount driver, both STM32 controller and VirtualStar subsystems operate in the same clearly defined time domain. Thus, all discrete points approximating the desired trajectory are fully synchronized and the motion actions are performed with a valid coordinates conversion time.

The graphical user interface layer (Fig. 4) shows the current coordinates as instrumental positions in the horizontal system (based on encoders values) (1), as well as current astronomical coordinates, both in the horizontal and equatorial systems (2). The last item in the vertical stack is the field for the input of the slewing targets (3), defined in any coordinate system. Other functionalities of the system (4) include: switching to a passive or active state, starting or stopping sidereal

tracking, sending TLE orbital elements data for satellite tracking, monitoring operations of the entire system and reacting to possible errors and faults, preparing a file for the calculation of pointing model coefficients, and generating an automatic observations program.

The web application called the Robot Supervisor Panel (RSP) was created to facilitate the development and testing of the telescope system and to enable the designer to interact with the system in a simple and easy way. The main focus of the RSP is given to diagnostics, parameter tuning, online visualization with signal processing, and the possibility of conducting experiments for the telescope development and maintenance. The application is written using standard web development tools, including Hyper-Text Markup Language (HTML), Cascading Style Sheets (CSS) with Leaner Style Sheets (LESS) and Java Script (JS). Additionally, the JS front-end framework Vue.js is used for simplification of the design process and maintenance of the code. The most significant advantage of this framework is the reactivity feature. Namely, after any change of a reactive state, the interface structure is updated automatically. Moreover, this framework supports the modular structure of the application, which enables to dynamically modify the page depending on data received from the telescope system and the user’s interaction.

The main target of RSP is an exchange of information with the telescope system by taking advantage of the ASTCom communication library. The RSP interface is divided into several panels, each responsible for a different functionality. The first panel, called Board, can be used to initiate a connection with the telescope system. Once the connection is successfully established, the application queries the telescope controller

Fig. 4. VirtualStar graphical user interface (a color inversion is applied to the image for readability) Rys. 4. Interfejs graficzny aplikacji VirtualStar (dla zwiększenia czytelności zastosowano inwersję kolorów na ilustracji)

for a list of all available variables which are then separated into three types: streaming signals, parameters, and executable functions. An internal structures corresponding to these remote variables are then dynamically created to be used in further processing. These dynamically defined variables are used to exchange data with the telescope controller. It should be noted that for writing, reading, and streaming requests, the RSP takes advantage of a private channel to communicate with the Endpoint, and streaming channel to receive streaming data of requested signals.

The Board tab also shows all basic information about the device, including connection status, telescope status, and possible errors. The designed layout allows the user to keep an eye on the device and connection status without much effort. A full overview of all statuses and errors for each module of the telescope system can be found on the Diagnostics tab. In this tab, the user is able to check states of low-level controller, motors or a trajectory status. The card Signals presents remote variables available for streaming and is responsible for defining commands for a stream of chosen signals with a frequency up to 10 kHz that is equal to the sampling frequency of the main controller. The Plot card, as the name suggests, is used to visualize received data of streamed variables. Moreover, an additional tab called Compute is provided, which enables the user to perform algebraic calculations using streamer signals, the results of which can be later displayed in Plot tab. Significantly, each card offers a possibility to save its current state to a local configuration file, which can be later loaded to restore all settings with just a one click, e.g. if there is a need to recreate a past experiment.

Using the Parameters card, one can easily read and modify the parameters values of the telescope system to perform the controller tuning. During the tuning process there is no need to restart the system to apply new settings and this process can be done online, while the telescope executes the ordered task. The online browser of signals received from the controller helps to manually tune up parameters to obtain the required performance of the control system for various conditions.

The Input card enables to send predefined control commands like start, stop, or reset, and custom commands to remotely execute functions with given arguments. From this panel the user is also able to define a trajectory for each axis by giving a mathematical formula dependent on time and additionally specifying experiment duration. This function of the RSP has been used for experimental validation in Section 6.

In order to present the practical possibilities of the proposed software framework, the experiment was performed using the real telescope system operating in SkyLab. The experiment was conducted for a whole-night tracking of drifting sinusoidal trajectory specified for the single axis of the telescope with an average speed of approximately 0.0095 rad/min that resulted in an axis covering the distance of 6.8 rad in 12 h. Data acquisition was carried out throughout the experiment with a frequency of 1 kHz. The change of axis position from the start of experiment, motor current, and position tracking error were chosen for recording. Notably, all data was gathered directly from the drive controllers and visualizes the performance of the mount itself irrespectively from properties (e.g. resolving power) of the optical part of the telescope. Due to the simple character of the desired trajectory, the RSP module was used for its generation. Alternatively, VS application could be employed to perform the experiment with a trajectory corresponding to movement of some celestial objects. The database was used for online storage of acquired measurements. Significantly, the experiment was conducted remotely and no kind of human supervision was required throughout the experiment. The results of the experiment are given in Fig. 6.

In Fig. 7 a zoomed view of only the first two seconds of the experiment with full resolution of 1000 samples per second is given. Notably, both these figures were created using the same data from the same experiment. This exposes the possibilities of the proposed solution to monitor the performance of the telescope in different time scales while preserving high time accuracy even for long acquisition periods. In particular, one can distinguish different dynamic effects visible in Fig. 6 and 7

Fig. 6. Data obtained during the whole experiment Rys. 6. Dane uzyskane w trakcie całego eksperymentu

The design of a control architecture for autonomous telescope mounts can be regarded as an interesting and challenging task due to a high complexity of the system, difficulties in achieving high performance of motion control and a reliable operation of the system over a long period of time in various environmental conditions. The tools described in the paper have been created taking into account these requirements. The implemented communication library ensures that adding new signals to the growing code of the controller will not take much effort, and no significant changes on the client side will be necessary. The designed web application allows monitoring, tuning the telescope control system and conducting experiments from one place that can be convenient for system designers and engineering scientists. This diagnostic tool can also be used during the maintenance to keep performance on the highest level and prevent failures of the system. Alternatively, the VirtualStar system enables astronomers to efficiently carry out desired observations. The database provides access to measurements gathered during observations to later conduct an analysis of the acquired data.

The future work may include extension of functionality of the presented client applications, including implementation of log viewer and adding additional conversion and calculation functions in the web application. Moreover, reliability and security of the considered communication scheme should be increased. Specifically, introduction of some security measures concerning prevention of unauthorized access to the communication network may be considered as a crucial issue for the employment of the telescope mounts working under the proposed framework. Additionally, there is still a space for the development of the error detection process to achieve better effectiveness and reliability of the telescope control system, including analysis of collected data.

Fig. 7. Detailed view of data obtained in the first 2 s of the experiment Rys. 7. Szczegółowy widok danych uzyskanych w pierwszych 2 s trwania eksperymentu

– vibrations visible in the wider time horizon are presumably caused by the presence of cogging torque due to the electromechanical structure of the motors, while the tracking errors observed in the short time scale are attributed to the vibrations of the mechanical mount which is not perfectly stiff. The data obtained from the whole experiment takes approximately 1 GB of memory when stored in optimized MATLAB data format and over 4 GB when written into text based .csv file.

The gathered data can be used not only for experimental purposes, but also to supervise the performance of the telescope system in order to detect failures and react as quickly as possible to any reduction in control quality, which may otherwise lead to loss of functionality of the system. In the worst case, it can help diagnose a broken element thanks to the recorded historical data. This subject was discussed in Katal et al. [7], where difficulties and possible techniques to deal with data analyze problem were presented.

We would like to express our thanks to our late leader, Professor Krzysztof Kozłowski who was the initiator of series of projects focused on the development of technologies for autonomous optical observation systems implemented at the Poznan University of Technology.We would also like to thank Bartłomiej Krysiak, PhD, and Mateusz Ochocki, MSc, who are the designers of the mechanical structure of the telescopic mount used in the SkyLab, and Tomasz Jedwabny, MSc, who designed and integrated the electronic units of the system, and Stanisław Kozłowski, PhD, for his support in the field of astronomy and SST, and active participation in the functional development of the SkyLab laboratory. We also thank Piotr Mieszała, MSc, for his technical and administrative support of the projects.

This research was funded by the Poznan University of Technology grant number 0211/SBAD/0121.

1. Abareshi B., Marshall R., Gott S., Sprayberry D., Cantarutti R., Joyce D., Williams D., Probst R., Reetz K., Paat A., et al., A new telescope control software for the Mayall 4-meter telescope, „Software and Cyberinfrastructure for Astronomy IV”, Vol. 9913, 2016, 645–656. SPIE, DOI: 10.1117/12.2233087.

2. Cochran R., Marinescu C., Riesch C., Synchronizing the Llinux system time to a PTP hardware clock. IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication, 2011, 87–92, DOI: 10.1109/ISPCS.2011.6070158.

3. Edwards P., Amy S., Brodrick D., Carretti E., Hoyle S., Indermuehle B., McConnell D., Mader S., Mirtschin P., Preisig B., et al., Remote access and operation of telescopes by the scientific users. „Observatory Operations: Strategies, Processes, and Systems V”, Vol. 9149, 2014, International Society for Optics and Photonics, DOI: 10.1117/12.2058794.

4. Gawron T., Kozłowski K., Semi-automated synthesis of control system software through graph search, „Advanced, Contemporary Control”, 2020, 1092–1103, Springer, DOI: 10.1007/978-3-030-50936-1_91.

5. Hohenkerk C.Y., SOFA and the algorithms for transformations between scales & between systems. [In:] H. Schuh, S. Boehm, T. Nilsson, N. Capitaine (eds.), „Proc. of Journées Systémes de Référence Spatiotemporels 2011”, 2012, 21–24.

6. Ivanescu L., Baibakov K., O’Neill N.T., Blanchet J.P., Blanchard Y., Saha A., Rietze M., Schulz K.H., Challenges in operating an Arctic telescope. „Ground-based and Airborne Telescopes V”, Vol. 9145, 2014, 1489–1509, SPIE, DOI: 10.1117/12.2071000.

7. Katal A., Wazid M., Goudar R.H., Big data: Issues, challenges, tools and Good practices. [In:] 2013 Sixth International Conference on Contemporary Computing (IC3), 2013, 404–409, DOI: 10.1109/IC3.2013.6612229.

8. Kozlowski K., Pazderski D., Krysiak B., Jedwabny T., Piasek J., Kozlowski S., Brock S., Janiszewski D., Nowopolski K., High precision automated astronomical mount. [In:] Conference on Automation, 2019, 299–315, Springer, DOI: 10.1007/978-3-030-13273-6_29.

9. Kozłowski S., Pazderski D., Krysiak B., Patelski R., Jedwabny T., Kozłowski K., Sybis M., SkyLab: Research

and development facility for ground based observations. „Ground-based and Airborne Telescopes VIII”, Vol. 11445, 2020, 1399–1408, SPIE, DOI: 10.1117/12.2576332.

10. Krysiak B., Pazderski D., Kozłowski S., Kozłowski K., High efficiencydirect-drivemountforspacesurveillanceandNEO applications. „Publications of the Astronomical Society of the Pacific”, Vol. 132, No. 1015, 2020, DOI: 10.1088/1538-3873/ab9cc5.

11. Marchiori G., Formentin F., Rampini F., Reliability-centered maintenance for ground-based large optical telescopes and radio antenna arrays. „Groundbased and Airborne Telescopes V”, Vol. 9145, 2014, 1346–1354, SPIE, DOI: 10.1117/12.2057593.

12. Sadeh I., Dezman D., Oya I., Pietriga E., Schwarz J., The Graphical User Interface of the Operator of the Cherenkov Telescope Array. [In:] Proc. of International Conference on Accelerator and Large Experimental Control Systems (ICALEPCS’17), Barcelona, Spain, 8-13 October 2017, 186–191. JACoW, 2018, DOI: 10.18429/JACoW-ICALEPCS2017-TUBPL06.

13. Story K., Leitch E., Ade P., Aird K., Austermann J., Beall J., Becker D., Bender A., Benson B., Bleem L., et al., South Pole Telescope software systems: control, monitoring, and data acquisition. „Software and Cyberinfrastructure for Astronomy II”, Vol. 8451, 2012, International Society for Optics and Photonics, DOI: 10.1117/12.925808.

14. Vallado D.A., Crawford P.S., Hujsak R., Kelso T.S., Revisiting Spacetrack Report #3. [In:] AIAA Astrodynamics Specialist Conference, 2006.

Artykuł przedstawia nowy system sterowania i komunikacji zaprojektowany w celu usprawnienia rozwoju i utrzymania zrobotyzowanego montażu teleskopu astronomicznego. Proponowane rozwiązanie umożliwia użytkownikowi zdalny dostęp do dowolnych sygnałów wewnątrz sterownika bez zwiększonego obciążenia podczas pracy systemu. Zaimplementowane rozwiązanie może być wykorzystywane zarówno przez automatyczny system nadzorujący, jak i przez użytkownika lub operatora, do nadzoru, sterowania i utrzymania urządzenia.

ORCID: 0000-0002-1675-4259

ORCID: 0000-0002-7301-5436

ORCID: 0000-0003-4260-9909

ORCID: 0000-0002-8732-7350

Pomiary Automatyka Robotyka, ISSN 1427-9126, R. 26, Nr 4/2022, 53–59, DOI: 10.14313/PAR_246/53

Streszczenie: W niniejszej publikacji zaproponowano metodę lokalizacji wizyjnej z wykorzystaniem obrazów z symulowanej kamery oraz mapy georeferencyjnej. Model BSP oraz symulacja lotu zostały wykonane w pakiecie MATLAB Simulink, który przesyłał dane dotyczące orientacji BSP do opisywanego programu. Wizualizacja obrazu z kamery została wykonana w czasie rzeczywistym przy pomocy oprogramowania FlightGear, której obraz również był przechwytywany przez program NW. Metoda ta realizowana jest przez dwa procesy w dwu modułach: Global Positioning Component oraz Motion Positioning Component. Pierwszy z nich porównuje obraz z symulowanej kamery z ortofotomapą. Drugi wyznacza pozycję na podstawie oceny przemieszczenia punktów charakterystycznych w obrazie w stosunku do ostatnio znanej lokalizacji. Wynik działania obu modułów ilustrowany jest w oknie graficznym aplikacji NW, co pozwala na wizualne porównanie uzyskanych wyników. W przypadku globalnej metody lokalizacji wymagana jest dodatkowa korekcja orientacji kamery w celu wyznaczenia pozycji w przestrzeni 2D. W tym celu wykorzystano dane dotyczące bieżącej orientacji kamery wyrażone w kwaternionach. Pozwoliło to na wprowadzenie poprawki pozycji, co znacząco poprawiło dokładność wyniku uzyskiwanego w module GPC mimo znacznych przechyleń BSP podczas symulowanego lotu.

Wprowadzenie

Nawigacja Bezzałogowych Statków Powietrznych (BSP) wykorzystuje do samolokalizacji głównie systemy satelitarne GNSS (ang. Global Navigation Satellite Systems). W sytuacji utraty łączności lub braku dostępu usługi GNSS sprawne pilotowanie statku bezzałogowego jest niemożliwe. Powstaje więc potrzeba zapewnienia bezpieczeństwa lotów i nieprzerwanej nawigacji przez wprowadzenie redundancji informacyjnej. Potrzeba ta wynika również z konieczności zmniejszenia

podatności systemu nawigacji satelitarnej na zakłócania czy oszustwa (ang. jamming/spoofing). Ze względu na oczekiwaną uniwersalność rozwiązania, preferowane są systemy nawigacji, których oprzyrządowanie jest lekkie i zajmuje niewiele miejsca a wykorzystujące je metody nawigacji nie potrzebują dodatkowej zewnętrznej infrastruktury.

Jednym z możliwych rozwiązań zapewnienia ciągłej nawigacji BSP, bez konieczności dodatkowej infrastruktury zewnętrznej, jest system lokalizacji wykorzystujący analizę obrazu pozyskiwanego z kamery pokładowej [1]. Takie systemy często wyposażone są w stabilizator elektromechaniczny, pozwalający na uzyskanie stabilnego obrazu z kamery w celu zniwelowania zniekształceń w obrazie. Autorzy artykułu [2] wykorzystali techniki głębokiego uczenia maszynowego. Do treningu sztucznej sieci neuronowej zastosowano wcześniej przygotowane zdjęcia lotnicze. Wytrenowana sieć identyfikowała charakterystyczne cechy w obrazie uzyskanym na żywo z kamery pokładowej zamontowanej na gimbalu.

Z kolei w publikacji [3] przedstawiono system, który nie wymaga stosowania stabilizatora. Składa się on z trzech głównych komponentów. Pierwszy komponent stosuje metodę VIO

(ang. Visual Inertial Odometry) do nawigacji względnej. Wykorzystuje ona metodę odometrii wizyjnej o nazwie VINS-Mono, która integruje urządzenie MIMU (ang. Micro Inertial Measurement Unit) i kamerę monokularową, aby oszacować stany ruchu kamery (np. pozycję, położenie i prędkość) i zrekonstruować pozycję 3D śledzonych cech. Drugi komponent porównuje obrazy z kamery pokładowej z ortofotomapami. Z obrazu lotniczego najpierw wyodrębniane są cechy mapy w trybie off-line za pomocą algorytmu SIFT (ang. Scale-Invariant Feature Transform) z biblioteki OpenCV. Następnie obraz z kamery jest obracany i skalowany w celu uzyskania podobnej orientacji i skali, jaką ma mapa z repozytorium off-line. Do tych transformacji wykorzystywany jest zwrot UAV oraz wysokość wyznaczona z zastosowaniem metody VIO. Charakterystyczne punkty są następnie porównywane z ortofotomapą. Do lokalizacji obiektu wykorzystywany jest algorytm PNP (Perspektywa-N-Punkt), który polega na oszacowaniu pozycji kamery, bazując na zestawie punktów 3D oraz odpowiadającym im rzutom 2D na obrazie. Ostatnim komponentem jest graf dokonujący fuzji danych (łączy on względne wyniki nawigacji z VIO z pozycjami geodezyjnymi pochodzącymi z ortofotomapy). Przeprowadzono walidację proponowanej metody. Kamera wraz z MIMU zostały sztywno przymocowane do korpusu UAV. Wykonano dwa loty w różnych środowiskach o nieznanych współrzędnych początkowych. Wyniki pokazują, że proponowana metoda może zapewnić dokładność lokalizacji z błędem pozycji mniejszym niż 4 m w locie na wysokości 100 m i błędem mniejszym niż 9 m w locie na wysokości 300 m.

W publikacji [4] opisano system łączący tradycyjne techniki widzenia komputerowego z sieciami głębokiego uczenia do porównania obrazu satelitarnego (referencyjnego) z obrazem pochodzącym z UAV (docelowego) na potrzeby lokalizacji. Parametrami wejściowymi są obraz z kamery, ortofotomapa

wraz z georeferencją oraz wstępną pozycją UAV. Moduł kalibracji odpowiada za wyodrębnienie obszaru ROI (ang. Region Of Interest) oraz wstępne wyznaczenie lokalizacji na podstawie poniższych równań. Przy pomocy równań (1) i (2) obliczane są współrzędne pikseli pixx, pixy określających położenie UAV, przy znanych współrzędnych geograficznych UAV: lon, lat, współrzędnych brzegowych obrazu: lon n, lat e, lat w, lon n oraz znanym wymiarze mapy: widthmin, widthmax, heightmin, heightmax. Wzory (3) i (4) służą do obliczenia współrzędnych geograficznych: lat, lon na podstawie współrzędnych na obrazie w pikselach: pixh, pixw. Proces odnajdywania punktów charakterystycznych jest realizowany tak, aby przetwarzanie klatek wideo odbywało się w czasie rzeczywistym. Porównano wynik działania algorytmów ORB, SURF i SIFT wyszukujących cechy charakterystyczne na obrazach. Stwierdzono, że metoda ORB jest szybsza od pozostałych, jednak charakteryzuje się mniejszą dokładnością dopasowania porównywanych dwu obrazów w przypadku zmiany skali jednego z nich.

Mniejsza dokładność dopasowania obrazów o różnych skalach powodowała spadek dokładności pozycjonowania UAV podczas zmiany jego wysokości. W celu eliminacji tego problemu zaimplementowano funkcję skalowania mapy na podstawie wysokości lotu. W kolejnym kroku wykorzystano wytrenowaną sieć UNet do semantycznej segmentacji obiektów. Sieć ta została wybrana ze względu na wysoką wydajność obliczeniową. Następnym krokiem była ocena podobieństwa wykrytych kształtów na obrazie z kamery pokładowej do tych wykrytych na mapie. Dopasowane kształty są stosowane do obliczania macierzy homografii [5] w celu zwiększenia dokładności pozycjonowania UAV.

Schemat pokazany na Rys. 1. przedstawia, opracowaną w ramach prowadzonych badań, koncepcję systemu nawigacji wizyjnej (NW). Podczas prawidłowego funkcjonowania lokalizacji satelitarnej autopilot PixHawk korzysta z jej danych do określenia swojego położenia geograficznego. Moduł Drone Component w sposób ciągły pobiera dane z autopilota PixHawk za pomocą protokołu MAVLink (ang. Micro Air Vehicle Link – protokół do komunikacji stosowany w pojazdach bezzałogowych). Następnie sprawdzany jest status danych podających lokalizację. Dzieje się to w bloku decyzyjnym oznaczonym na schemacie FIX status. W przypadku pozytywnego statusu (dane kompletne) dane z sensorów lokalizacyjnych zapisywane są w pamięci. W przypadku negatywnego statusu, dane przechowywane w pamięci przekazywane są do modułu GPC (ang. Global Positioning Component) oraz MPC (ang. Motion Positioning Component), natomiast znacznik czasu, w którym te dane zostały zarejestrowane przekazywany jest do Filtering component. Global Positioning Component wyznacza pozycję na podstawie porównania obrazu ze znaną mapą (przechowywaną w pamięci), natomiast Motion Positioning Component wyznacza pozycję na podstawie oceny przemieszczenia punktów charakterystycznych w obrazie w stosunku do ostatnio znanej lokalizacji. Pierwszy z nich wykorzystuje metody klasycznej analizy obrazu zaimplementowane w OpenCV oraz metody oparte na uczeniu maszynowym. Charakteryzuje się długim czasem przetwarzania obrazów oraz niewielkim błędem systematycznym wyniku. Drugi komponent (MPC) wykorzystuje algorytm Optical Flow, co przekłada się na krótszy czas realizacji obliczeń oraz większy błąd systematyczny. W celu uzyskania małego błędu systematycznego oraz dużej szybkości przetwarzania danych oba komponenty pracują równolegle. Wyznaczona w module Global Positioning Component lokalizacja przekazywana jest do Filtering component oraz Motion Positioning Component w celu aktualizacji pozycji odniesienia. Oba moduły korzystając z funkcji OpenCV, wyznaczają współczynnik ufności uzyskanego wyniku (ang. confidence). W kolejnym kroku moduł Filtering component, uwzględniając obliczone współczynniki ufności, określa pozycję oraz w odniesieniu do ostatniego znanego czasu, generuje pakiet danych zgodny ze standardem NMEA, który trafia do autopilota. Wyznaczona na podstawie danych wizyjnych lokalizacja jest również deponowana w module Drone Component w celu ponownego wykorzystania w przypadku braku dostępnych danych z systemów satelitarnych (dane z GNSS & Compass sensors).

3. Ortofotomapa

Składnikiem Global Positioning Component jest funkcja odpowiedzialna za wygenerowanie wycinka ortofotomapy w otoczeniu lokalizacji BSP z użyciem danych dotyczących całego

obszaru przechowywanego w pamięci. Początkowo dane dotyczące mapy stanowiły jeden plik o rozszerzeniu *.geotiff zawierający wybrany obszar o wysokiej rozdzielczości. W metadanych danego pliku znajdowały się również informacje na temat lokalizacji narożników mapy oraz stosowanego układu współrzędnych. Jednak ze względu na ograniczenia pamięci w przypadku otwierania dużych plików, zastosowano metodę podziału mapy znaną jako Slippy Map [14]. Jest to metoda stosowana powszechnie w mapach internetowych typu Google Maps [15] czy OpenStreetMap [16]. Pozwala ona na podzielenie ortofotomapy dużego obszaru na małe kafelki a następnie uporządkowanie ich w odpowiednich katalogach o nazwach związanych z rozdzielczością oraz podkatalogach o nazwach związanych z lokalizacją wzdłuż równoleżników. Nazwy plików graficznych *.png o rozdzielczości 256 × 256 pikseli skojarzone są z lokalizacją wzdłuż południków. Na podstawie wysokości BSP, pobranej przez Drone Component, możliwe jest obliczenie GSD (ang. Ground Sampling Distance), co pozwala na dobranie właściwej rozdzielczości mapy. Pobrana lokalizacja geograficzna determinuje wybór odpowiednich katalogów oraz plików zawierających ortofotomapy w otoczeniu danej lokalizacji. Tak uporządkowany system pozwala na wczytanie minimalnej ilości danych, co przekłada się na mniejsze obciążenie pamięci oraz na szybkość działania.

W celu pozyskania filmów, obrazujących nagrania z kamery wideo zbierane w trakcie lotu BSP, wykorzystano otwarty źródłowy symulator FlightGear [17] Wybór ten został podyktowany możliwością integracji z oprogramowaniem MATLAB Simulink, w którym możliwe jest zaimplementowanie różnych modeli latających, co opisano między innymi w publikacji [6]. W przyszłości pozwoli to na testowanie opracowywanej nawigacji na różnych platformach powietrznych – zarówno załogowych, jak i bezzałogowych.

Poniżej przedstawiono wizualizację funkcjonowania systemu dla przelotu z kamerą, której oś optyczna skierowana jest prostopadle do płaszczyzny ziemi. Dla tego przypadku, wspomniany wcześniej komponent GPC prawidłowo określa pozycję BSP, ponieważ obraz z kamery stanowi prostokątny wycinek mapy, a geometryczny środek tego prostokąta – lokalizację BSP w rzucie na tę mapę. Wizualizacja została podzielona na cztery części: obraz w prawym górnym rogu – widok z kamery z zaznaczonymi punktami charakterystycznymi algorytmu Optical Flow, poniżej – wycinek mapy z zaznaczonym rzutem pola widzenia kamery oraz trajektoriami lotu BSP, lewy dolny róg – parametry wykorzystane do obliczeń wraz z wyznaczoną lokalizacją geograficzną, obraz po prawej – cała wczytana mapa z zaznaczonym wycinkiem obszaru wokół BSP, polem widzenia kamery oraz wyznaczonymi trajektoriami lotu.

Trudniejszym zadaniem jest porównanie obrazów uzyskanych pod różnymi kątami widzenia. Kąt widzenia nie tylko zmienia geometrię obrazu, lecz również wpływa na nierównomierności w rozkładzie rozdzielczości w danym widoku. W pracy skupiono się na geometrycznym wyznaczeniu lokalizacji podczas wychylenia BSP względem poziomu (rys. 2). Ma to na celu uniknięcie potrzeby stosowania stabilizowanej mechanicznie głowicy optycznej, co znacznie zmniejsza masę i objętość systemu, oraz zapewnia większą niezawodność dzięki minimalizacji elementów ruchomych. Na potrzeby przedstawionego zadania wygenerowano symulację przelotu BSP ze zmiennymi wychyleniami do 30° względem płaszczyzny ziemi. Na rys. 3 pokazano wizualizację działania systemu bez korekcji kąta wychylenia.

Wyznaczona lokalizacja przez Global Positioning Component znacząco odbiega od prawidłowej, wyznaczonej przez GNSS.

Rys. 2. Wizualizacja funkcjonowania systemu; niebieski – rzeczywista trajektoria lotu BSP, żółty – trajektoria wyznaczona przez moduł MPC, czerwony – trajektoria oraz rzut pola widzenia kamery na mapę 2D – wynik algorytmu GPC (Źródło: opracowanie własne)

Fig. 2. Visualization of the system functioning; blue – the actual UAV flight trajectory, yellow – the trajectory determined by the MPC module, red – the trajectory and the projection of the camera’s field of view onto the 2D map – the result of the GPC algorithm (Source: own study)

Spowodowane jest to brakiem kompensacji kąta wychylenia dla wyznaczanej pozycji.

Na podstawie dopasowanych punktów źródłowych na obrazie wideo do odpowiadających im na mapie, zostaje wyznaczona macierz homografii H [5], która zawiera pozycję i orientację kamery. Do jej wyznaczenia zastosowano metodę RANSAC (ang. RANdom SAmple Consensus), która wymaga co najmniej

czterech, niewspółliniowych punktów charakterystycznych. Za pomocą macierzy H rzutującej punkty płaszczyzny kamery na płaszczyznę mapy oraz przy uwzględnieniu wymiarów obrazu wideo wyznaczane są punkty czworokąta, który reprezentuje pole widzenia kamery na płaszczyźnie mapy. Jeśli oś optyczna kamery jest skierowana prostopadle w kierunku ziemi, rzutowane pole widzenia jest prostokątem o długościach boków w proporcji adekwatnej do wymiarów sensora kamery. Położenie centroidu L (punktu określającego geometryczny środek figury) wyznaczonego prostokąta odpowiada rzutowi prostopadłemu punktu lokalizacji BSP na mapę 2D.

Rys. 3. Symulacja funkcjonowania systemu w przypadku zmiennych wychyleń BSP – pitch, roll, yaw [7] w zakresie od 0° do 30° względem układu NED, którego początek związany jest z lokalizacją BSP; GPC –czerwony, GNSS – niebieski (Źródło: Opracowanie własne)

Fig. 3. Simulation of the system operation in the case of variable BSP deflections – pitch, roll, yaw [7] in the range from 0° to 30° in relation to the NED system, the beginning of which is related to the BSP location; GPC –red, GNSS – blue (Source: Own study)

Rys. 4. Wizualizacja wyznaczania lokalizacji za pomocą centroidu L prostokąta stanowiącego rzut pola widzenia kamery na płaszczyznę mapy, gdy oś optyczna kamery jest skierowana prostopadle w kierunku ziemi (Źródło: Opracowanie własne)

Fig. 4. Visualization of determining the location using the centroid L of a rectangle constituting the projection of the camera’s field of view onto the map plane, when the optical axis of the camera is directed perpendicularly towards the ground (Source: Own study)

W przypadku zmiany kąta Φ osi optycznej kamery względem ziemi występuje zniekształcenie obrazu – kamera obejmuje szerszy obszar ziemi w kierunku, w którym nastąpiła zmiana kąta. Przy znacznym wychyleniu płaszczyzny kamery względem płaszczyzny ziemi, pole widzenia kamery nie obejmie obszaru na którym znajduje punkt lokalizacyjny L. Powo duje to konieczność wprowadzenia korekcji lokalizacji w zależności od kąta Φ.

Przy transformacji współrzędnych uwzględnia się trzy układy współrzędne o oznaczeniach: −NED – (ang. Nord East Down), układ o niezmiennej orientacji względem mapy, o początku związanym z poruszającym się w przestrzeni BSP. W tym układzie oś X skierowana jest na północ, oś Y na wschód, a oś Z w dół; BSP – układ związany ze statkiem powietrznym o początku pokrywającym się z początkiem układu NED lecz o orientacji zmieniającej się względem NED zgodnie z obrotami roll, pitch oraz yaw statku powietrznego BSP; MAP – układ, którego orientacja oraz pozycja jest na stałe związana z mapą.

Do testowania opracowanej metody wykorzystano model platformy BSP sprzężony z kamerą, opracowany z wykorzystaniem pakietu MATLAB Simulink. Jednym z parametrów wyjściowych modelu jest orientacja kamery względem układu

(6)

Osie układu współrzędnych nieobróconej kamery pokrywają się z osiami układów NED i BSP, natomiast wektor orientacji BSPP camera kamery w układzie BSP wyrażony jest jako: ⎥ ⎥ ⎥ ⎥ ⎥ ⎦

⎤ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣

⎡ = 1 0 0 0 camera BSP P (7)

Wynikiem działania (6) jest kwaternion NEDp’: ⎥ ⎥ ⎥ ⎥ ⎥ ⎦

⎡ = ′ p NED p NED p NED NED z y x p

⎤ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣

0 (8)

Rys. 5. Pole widzenia kamery; DC, DM oraz DF to najbliższa, środkowa oraz najdalsza odległość w polu widzenia kamery, natomiast h to wysokość BSP nad ziemią; RC, RM oraz RF to odległości między dolną, środkową a górną częścią pola widzenia kamery (a). Rzut pola widzenia kamery na płaszczyznę mapy. Krawędź WC znajduje się bliżej kamery (b) (Źródło [8]

Fig. 5. Camera field of view; DC, DM and DF are the closest, middle and farthest distance in the field of view of the camera, while h is the UAV height above the ground; RC, RM, and RF are the distances between the lower, middle, and upper parts of the camera’s field of view (a). Projection of the camera’s field of view onto the map plane. The edge of the toilet is closer to the camera (b) (Source [8])

MAP wyrażona kwaternionem MAPq. Jest on reprezentowany przez cztery elementy wskazane w (5), gdzie q0, q1, q2, q3 są liczbami rzeczywistymi, natomiast i, j i k są wzajemnie ortogonalnymi wektorami jednostkowymi osi układu MAP.

q = q0 + iq1 + jq2 + kq3 (5)

Każdy pojedynczy obrót wokół pewnego wektora opisany jest przez kwaternion jednostkowy, natomiast podwójny obrót – przez pomnożenie kwaternionów jednostkowych. Kwaternion sprzężony q * reprezentuje obrót przeciwny do danego co jest reprezentowane przez zmianę znaku części wektorowej kwaternionu: q* = q0 – iq1 – jq2 – kq3. Aby wyznaczyć kwaternion NEDp’ obrotu kamery zamocowanej na BSP, względem układu NED należy pomnożyć: kwaternion orientacji BSPq kamery w układzie BSP, wektor NEDP camera stanowiący oś obrotu układu BSP względem NED oraz kwaternion sprzężony BSPq* orientacji kamery.

z którego współrzędne wektora NEDx p, NEDyp, NEDz p wskazują kierunek oraz zwrot osi optycznej kamery w układzie NED. Rzutowane są one na płaszczyznę mapy 2D w postaci współrzędnych MAPx m oraz MAPym, przy uwzględnieniu wysokości h: h z x x p NED p NED m MAP = (9) h z y y p NED p NED m MAP = (10)

Wartości współrzędnych MAPx m oraz MAPy m, stanowiące punkt przecięcia się osi optycznej kamery z płaszczyzną mapy 2D, odejmowane są od współrzędnych wyznaczonego przez komponent GPC centroida L. Pozwala to na uwzględnienie orientacji kamery podczas wyznaczania rzeczywistego położenia BSP.

Na rysunku 6 porównano trajektorie wyznaczonej lokalizacji za pomocą komponentu GPC, bez uwzględnienia orientacji kamery, oraz z jej uwzględnieniem w stosunku do rzeczywistej trajektorii wyznaczonej przez moduł GNSS. Dla przeprowadzonej symulacji wykazano znaczącą poprawę dokładności pozycjonowania. Dalsze prace będą polegały na

wyznaczeniu maksymalnych wychyleń BSP przy zachowaniu zadowalających wyników.

6. Wnioski

Poprzednie prace [1, 9] dotyczyły opisu metody nawigacji wizyjnej przy założeniu, że oś optyczna kamery jest zawsze prostopadła do płaszczyzny terenu. Sytuacja taka dotyczy układu wykorzystującego gimbal (stabilizator elektromechaniczny). Stabilizuje on orientację kamery ale znacząco zwiększa stopień skomplikowania konfiguracji sprzętowej. W pracy skupiono się na geometrycznym wyznaczeniu lokalizacji BSP z uwzględnieniem zmian orientacji kamery BSP względem układu NED, a tym samym względem układu odniesienia mapy. Pokazano, że podczas odchylenia osi optycznej kamery od osi prostopadłej do płaszczyzny ziemi, lokalizacja wyznaczona przez algorytm GPC zawiera błąd, który może zostać skompensowany przez uwzględnienie zmiennej orientacji kamery. W tym celu wykorzystano kwaternion orientacji kamery pochodzący z modelu zaimplementowanego w programie MATLAB Simulink. Uwzględnienie orientacji kamery znacząco poprawiło dokładność wyznaczania lokalizacji (rys. 6). Przyszłe prace będą skupiały się na wykorzystaniu danych z żyroskopu autopilota do stabilizacji obrazu. Pozwoli to na przeprowadzenie testów na rzeczywistej platformie nieposiadającej stabilizatora. Planowane są również prace związane z wykorzystaniem kamer zdarzeniowych do wykrywania punktów charakterystycznych wymaganych jako dane w module MPC. Pozwoli to osiągnąć nie tylko wystarczającą do samonawigacji dokładność wyznaczania pozycji geograficznej, ale i odpowiednią częstotliwość generowania wyniku w celu zapewnienia całkowitej redundancji modułu GNSS.

1. Pogorzelski T., Zielińska T., Vision Based Navigation Securing the UAV Mission Reliability, [In:] Automation 2022: New Solutions and Technologies for Automation, Robotics and Measurement Techniques, AISC, Vol. 1427, 2022, 251–263, DOI: 10.1007/978-3-031-03502-9_26.

2. Mughal M.H., Khokhar M.J., Shahzad M., Assisting UAV Localization via Deep Contextual Image Matching,

“IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing”, Vol. 14, 2021, 2445–2457, DOI: 10.1109/JSTARS.2021.3054832.

3. Mao J., Zhang L., He X., Qu H., Hu X., Precise Visual-Inertial Localization for UAV with the Aid of A 2D Georeferenced Map, arXiv, 2021, DOI: 10.48550/arXiv.2107.05851.

4. Nassar A., Amer K., ElHakim R., ElHelw M., A Deep CNN-Based Framework For Enhanced Aerial Imagery Registration with Applications to UAV Geolocalization, [In:] IEEE/ CVF Conference on Computer Vision and Pattern Recognition Workshops (CVPRW), 2018, DOI: 10.1109/CVPRW.2018.00201.

5. Ivashechkin M., Barath D., Matas J., USACv20: robust essential, fundamental and homography matrix estimation, arXiv, 2021, DOI: 10.48550/arXiv.2104.05044.

6. Welcer M., Szczepański C., Krawczyk M., The Impact of Sensor Errors on Flight Stability, „Aerospace”, Vol. 9, No. 3, 2022, DOI: 10.3390/aerospace9030169.

7. Kowalik R., Łusiak T., Novak A., A Mathematical Model for Controlling a Quadrotor UAV, „Transactions on Aerospace Research”, Vol. 2021, No. 3, 2021, 58–70, DOI: 10.2478/tar-2021-0017.

8. Burke C., Rashman M., Wich S., Symons A., Theron C., Longmore S., Optimising observing strategies for monitoring animals using drone-mounted thermal infrared cameras, „International Journal of Remote Sensing”, Vol. 40, No. 2, 2019, 439–467, DOI: 10.1080/01431161.2018.1558372.

9. Pogorzelski T., Majek K., Onboard to Satellite Image Matching for Relocalization of the UAVs, [In:] Proceedings of the 3rd Polish Conference on Artificial Intelligence, 2022, 25–27.

10. Babinec A., Apeltauer J., On accuracy of position estimation from aerial imagery captured by low-flying UAVs, „International Journal of Transportation Science and Technology”, Vol. 5, No. 3, 2016, 152–166, DOI: 10.1016/j.ijtst.2017.02.002.

11. Fellner A., Konieczka R., Rotorcraft in the performance based navigation international civil aviation organization implementation, “Transactions on Aerospace Research”, Vol. 2019, No. 1, 2019, 53–64, DOI: 10.2478/TAR-2019-0005.

12. Rose D., Rotation Quaternions, and How to Use Them, 2015. [On-line] https://danceswithcode.net/engineeringnotes/quaternions/quaternions.html.

13. Craig J.J., Introduction to Robotics, Pearson Education Limited, 2014.

14. Slippy map tilenames, [On-line] https://wiki.openstreetmap. org/wiki/Slippy_map_tilenames.

15. Google, Google Maps, Alphabet, [On-line] www.google.pl/ maps/.

16. Coast S., Open Street Map, OpenStreetMap Foundation, [On-line] www.openstreetmap.org.

17. FlightGear, [On-line], https://www.flightgear.org/.

Rys. 6. Wizualizacja obliczonej lokalizacji przez komponent GPC bez korekcji – kolor czerwony, GPC z uwzględnieniem korekcji – kolor cyjan, w porównaniu do rzeczywistej trajektorii lotu – kolor niebieski, w przypadku zmiennych wychyleń do 30° względem płaszczyzny ziemi (Źródło: Opracowanie własne) Fig. 6. Visualization of the calculated location by the GPC component without correction – red, GPC with correction – cyan, compared to the actual flight trajectory – blue, in the case of variable deflections up to 30° with respect to the ground plane (Source: Own study)

Abstract: This publication proposes a visual localization method using images from a simulated camera and a georeferenced map. The UAV model and flight simulation were made in the MATLAB Simulink package, which sent UAV orientation data to the described program. The visualization of the camera image was performed in real time using the FlightGear software, the image of which was also captured by the NW program. This method is performed by two processes in two modules: Global Positioning Component and Motion Positioning Component. The first one compares the image from the simulated camera with the orthophotomap. The second determines the position based on the assessment of the displacement of characteristic points in the image in relation to the last known location. The result of the operation of both modules is illustrated in the graphic window of the NW application, which allows for a visual comparison of the obtained results. With the global method of location, additional camera orientation correction is required to determine the position in 2D space. For this purpose, data on the current camera orientation expressed in quaternions were used. This allowed for the introduction of a position correction, which significantly improved the accuracy of the result obtained in the GPC module despite significant UAV tilts during the simulated flight.

Keywords

ORCID: 0000-0002-8299-0727

ORCID: 0000-0002-8299-0727

Pomiary Automatyka Robotyka, ISSN 1427-9126, R. 26, Nr 4/2022, 61–67, DOI: 10.14313/PAR_246/61

W artykule przedstawiono projekt i realizację bezzałogowego pojazdu podwodnego o napędzie hybrydowym. Pojazd może być sterowany zdalnie w pozycji nawodnej, jak również posiada możliwość przemieszczenia podwodnego do wskazanego rejonu w celu przeprowadzenia rozpoznania oraz ataku poprzez detonację przenoszonego ładunku lub autodestrukcję. W artykule przedstawiono projekt i wykonanie konstrukcji mechanicznej, warstwy sprzętowej, programowej oraz wnioski wynikające ze wstępnych badań w basenie laboratoryjnym i w środowisku morskim.

Wprowadzenie

Bezzałogowe pojazdy podwodne stanowią ważny element ochrony i monitorowania podwodnej infrastruktury technicznej. Pojazdy takie mogą być również wykorzystane do inspekcji kadłubów jednostek pływających, obszarów przeznaczonych pod budowę morskich farm wiatrowych, wspierania specjalistycznych prac podwodnych oraz do prowadzenia i wspierania morskich akcji ratunkowych.

Aktualnie znanych jest wiele pojazdów o konstrukcji torpedopodobnej, a także kształtami przypominających żywe organizmy morskie [2–4]. W zależności od konstrukcji kadłuba, stosowane są napędy z jednym lub kilkoma pędnikami. Wśród pędników wyróżnia się konstrukcje przetwarzające ruch obrotowy lub oscylacyjny na siłę naporu [5].

Główne trendy rozwojowe bezzałogowych technologii morskich, takich jak bezzałogowe pojazdy nawodne i podwodne, przedstawiono w artykule [1]. Wśród trudności w projektowaniu pojazdów podwodnych należy wymienić ograniczenia środowiska wodnego w propagacji fal elektromagnetycznych, co eliminuje większość znanych z pojazdów lądowych lub statków powietrznych systemów pozycjonowania [6] lub komunikacji [7]. Z powodu trudności w autonomizacji pojazdów podwodnych szeroko stosowane są pojazdy zdalnie sterowane ROV (ang. Remotely Operated Vehicle). Pojazdy autonomiczne AUV (ang. Autonomous Underwater Vehicle) wykorzystują do nawigacji

i kontroli położenia przestrzennego systemy hydroakustyczne [8], logi [9], sonary [10], czujniki głębokości, systemy wizyjne [11] oraz czujniki inercyjne.

Prezentowany w artykule pojazd jest wyposażony w napęd hybrydowy, który łączy w sobie zalety pędników falowych i obrotowych. Pędniki obrotowe stanowią napęd główny pojazdu, natomiast napęd falowy wykonany jest z elastycznego tworzywa sztucznego w kształcie płetwy, co umożliwia dodatkowo regulację i utrzymanie głębokości zanurzenia. Pojazd został opracowany w ramach konkursu Ministra Obrony Narodowej, w którym szczególną uwagę zwrócono na wytrzymałość konstrukcji [20], zapewnienie wysokiej autonomiczności energetycznej oraz parametry eksploatacyjne. Istotnym parametrem jest również możliwość modyfikacji pojazdu podnoszącej jego autonomiczność i utylitarność.

Kolejne podrozdziały artykułu zawierają projekt pojazdu wraz ze schematem części sprzętowej i programowej, wyniki realizacji modelu fizycznego oraz zdjęcia z testów w basenie i w środowisku morskim.

2. Projekt pojazdu

Kadłub pojazdu składa się z korpusu oraz dwóch elementów zamykająco-uszczelniających. Główny element konstrukcyjny wykonany jest rury aluminiowej o średnicy 200 mm, długości 1000 mm oraz grubości ścianki równej 5 mm. Stosunek całkowitej długości do średnicy pojazdu wynosi 6:1. Takie rozwiązanie zapewnia minimalizację oporu hydrodynamicznego [12], sztywność konstrukcji, wodoszczelność, jak i odporność na uszkodzenia mechaniczne podzespołów elektronicznych umieszczonych wewnątrz. Metalowa konstrukcja chroni przed szkodliwymi czynnikami zewnętrznymi i wypromieniowuje ciepło podzespołów elektronicznych. Korpus pojazdu został zamknięty obustronnie denkami (Rys. 1).

Połączenie elementów realizowane jest poprzez dopasowanie kanałów uszczelnień metodą skrawania precyzyjnego elementów

wciskowych. Uszczelnienie stanowią podwójne zespoły oparte na o-ringach. Denko przednie (Rys. 1) stanowi bazę montażową dla zespołu płetw (nr 2 na Rys. 2), czujników oraz pozostałych elementów elektronicznych (nr 2 na Rys. 1). Układ napędowy płetw przedstawiony jest na Rys. 1. W celu zapewnienia łatwego i szybkiego serwisu, większość podzespołów zainsta-

Rys. 1. Model denka przedniego: 1 – przeniesienie napędu płetw przednich, 2 – otwory na czujnik ciśnienia, odpowietrznik i włącznik główny, 3 – kanały uszczelnień, 4 – serwomechanizmy Dynamixel AX 18A

Fig. 1. Model of the front cap: 1 – transmission of the side fin drive, 2 – holes for the pressure sensor, air vent and main power switch, 3 – sealing channels, 4 – Dynamixel AX 18A servos

Rys. 3 Kadłub przed malowaniem oraz wyposażenie wewnętrzne pojazdu Fig. 3. The hull before painting and the interior parts of the vehicle

Rys. 2. Model CAD bezzałogowego pojazdu podwodnego: 1 – pędniki główne, 2 – pędniki boczne, 3 – korpus główny, 4 – osłona denka przedniego, 5 – kamera, 6 – antena Wi-Fi, 7 – kiosk z modułem GPS Fig. 2. Design of the unmanned underwater vehicle: 1 – main propulsors, 2 – side propellers, 3 – the hull, 4 – front bottom cover, 5 – camera, 6 – Wi-Fi antenna, 7 – dome with GPS antenna

lowano w przedniej części pojazdu i zintegrowano z denkiem przednim. Wysunięcie korpusu pojazdu zapewnia łatwy dostęp do elementów wykonawczych i sterujących, zapewniając jednocześnie pełną funkcjonalność pojazdu w czasie dalszych modernizacji.

W tylnej części pojazdu zamontowano zespół napędu głównego wyposażony w dwa pędniki obrotowe (nr 1 na Rys. 2). Tylna oraz przednia część kadłuba zostały wyprofilowane w celu minimalizacji oporu hydrodynamicznego. Przednia część pojazdu dodatkowo osłania mechanizmy przeniesienia napędu płetw, czujnik głębokości, włącznik pojazdu oraz elektryczne złącza diagnostyczne.

Zanurzenie pojazdu realizowane jest zmianą kąta natarcia płetw poprzez skierowanie generowanego przez płetwy wektora naporu, aby zmienić w ten sposób wypadkową siłę naporu generowaną przez układ napędowy. Zmiana kursu pojazdu realizowana jest przez zamianę naporu generowanego przez pędniki główne (tylne).

W celu zapewnienia zakładanego, 12-godzinnego ciągłego czasu pracy, zastosowano zespół trzech niezależnych od siebie akumulatorów o łącznej pojemności 48 Ah. Bazując na platfor-

mie komputerowej Raspberry Pi model 4B opracowano układ wykonawczo-integrujący oparty na systemie operacyjnym Linux. Aplikacja sterująca ma następujące funkcje: komunikacja w standardzie Wi-Fi ze stacją brzegową (operatorem) w celu transmisji rejestrowanych danych, np. obraz z kamery, parametry od czujników; ciągła rejestracja obrazu z kamery do pamięci układu wykonawczego; sterowanie trajektorią pojazdu zgodnie z instrukcjami wysyłanymi w czasie rzeczywistym; −powrót pojazdu do zadanego punktu w przypadku niepowodzenia misji; −odczyt oraz rejestracja parametrów czujników, takich jak: IMU, kompas elektroniczny, czujnik głębokości, czujnik zalania, czujnik temperatury, czujnik ciśnienia. Dokładne parametry w/w czujników i sensorów zamieszczono w Tabeli 2, schemat połączeń zaprezentowano na Rys. 4.

W Tabeli 1 przedstawiono główne parametry eksploatacyjne otrzymane podczas testów i pomiarów. Zasięg transmisji nawodnej zależny jest od mocy naziemnej stacji Wi-Fi. Zastosowana w pojeździe antena ma możliwość ręcznej zmiany położenia z pionowego na poziomy, a także może być zamocowana na

Rys. 4. Schemat układu sensorów, zasilania i sterowania pojazdem Fig. 4. Scheme of the sensors, power supply and control system of the vehicle

Tab. 1. Parametrami technicznymi pojazdu

Tab. 1. Technical parameters

Nazwa REBA

Wymiary1500 × 200 × 220 mm

Masa35 kg

Prędkość maksymalna2,5 m/s

Tryby pracyzdalny, półautonomiczny

Ciągły czas pracy na jednym ładowaniu12 h Maksymalny zasięg transmisji nawodnej120 m

Zanurzeniedo 15 m

Masa przenoszenia ładunkudo 15 kg

Komputer sterujący Raspberry PI 4B

ZasilanieGENS ACE Akumulator LiPo Tattu 16 000 mAh 22,2 V 30C

Napęd tyłThrusters T200 (2 szt.)

Napęd przódDynamixel AX-18 A (2 szt.)

Tab. 2. Zastosowane sensory i ich parametry

Tab. 2. Used sensors and their parameters

PodzespółNazwaParametry

Czujnik orientacjiVectorNAV VN100T 3-osiowy, zakres żyroskopu ±2000°/s, częstotliwość 800 Hz, napięcie 5 V, moc 220 mW

Moduł GPSNEO-M9N 92-kanałowy odbiornik GNSS, dokładność 1,5 m, max. częstotliwość aktualizacji: 25 Hz (4 jednoczesne GNSS), dokładność prędkości: 0,05 m/s

Czujnik ciśnienia BlueRobotics BAR30 I2Cnapięcie 3,3 V, zanurzenie do 300 m

Czujnik temperaturySHT31zakres pomiarowy: od –40 °C do 125 °C, dokładność: ± 0,3 °C

Czujnik zalaniaBlueRobotics Leak Sensorzasilanie 5 V, pobór prądu 20 mA

KameraKamera IMX477 12,3MPx HQ sensor: IMX477, rozdzielczość: 4056 px × 3040 px, 12,3 MPx wymiary piksela: 1,55 μm × 1,55 μm, przysłona: F 1,4 Obiektyw6mm CS-Mount format: 1/2,3”, ogniskowa: 6 mm, przysłona: F 1,4, kąt widzenia: 65° montaż: CS-Mount, tylna ogniskowa: 12,5 mm

Moduł sterującyBasic ESCnapięcie pędnika 7–26 V, pobór prądu pędnika do 30 A, napięcie PWM 5 V Łączność

Tp-Link TL-CPE210 procesor: Procesor Qualcomm Atheros 560 MHz, MIPS 74Kc, pamięć: 64 MB DDR2 RAM, 8 MB Flash, moc transmisji: 27 dBm/500 mW

Moduł oświetleniaMatryca LED RGB 5 × 5 I2Cnapięcie 5 V

pływaku i połączona z pojazdem elastycznym przewodem. Takie rozwiązanie stosowane było m.in. w pojeździe przedstawionym w artykule [13]. Zasadniczym trybem pracy pojazdu jest autonomiczna realizacja misji zaplanowanej przez operatora poprzez wyznaczenie i wskazanie koordynatów przebytej trasy na mapie. Do planowania misji i kontroli pojazdu służy stacja operatora z wdrożoną dedykowaną aplikacją. W położeniu nawodnym operator może w pełnym stopniu kontrolować pojazd z poziomu systemu operacyjnego poprzez połączenie Wi-Fi.

Masa przenoszonego ładunku została wyznaczona na podstawie dodatkowej masy dodanej do wnętrza pojazdu w celu zapewnienia zakładanej (lekko dodatniej) pływalności, zależnej od parametrów środowiskowych (gęstości wody).

Część programistyczna została zaimplementowana, poprzez wykorzystanie środowiska programistycznego Python oraz dostępnych bibliotek [17–20]. Platforma sprzętowa umożliwia integrację przez oprogramowanie sterowania pojazdu z czuj-

nikami oraz systemem wizyjnym. Funkcje komputera nadrzędnego pełni jednopłytowy minikomputer Raspberry PI 4B bazujący na układzie Broadcom BCM 2711 z 64-bitowym procesorem quad-core 64 ARM-8 Cortex-A72 o taktowaniu 1,5 GHz. Do realizacji zagadnień dotyczących sekcji programowej wykorzystano język programowania Python, umożliwiający zarówno programowanie obiektowe, strukturalne jak i funkcyjne. Wielowątkowość umożliwia zaimplementowanie dwóch głównych trybów pracy pojazdu. Pierwszy z nich umożliwia sterowanie pojazdem w pozycji nawodnej za pomocą kontrolera: program odczytuje dane z urządzenia sterującego, a następnie za pomocą specjalnej depeszy wysyła impuls sterujący do pędników, których charakterystyka w funkcji prędkości obrotowej i napięcia zasilania została przedstawiona na Rys. 5. Pojazd może pracować w dwóch podstawowych trybach, zdalnym oraz półautonomicznym. W trybie zdalnym operator posiada pełną kontrolę nad sterowanym pojazdem za pomocą dedykowanego kontrolera, ponadto może dostosować prędkość do aktualnych warunków atmosferycznych czy rodzaju misji.

Rys. 5 Charakterystyki pędników T200 w funkcji prędkości obrotowej i napięcia zasilania [16] Fig. 5. T200 Thruster Performance [16]

Rys. 7. Podgląd obrazu wizyjnego podczas realizacji zadań nawodnych Fig. 7. Preview of the image during the execution of tasks on the water surface

Podgląd obrazu z kamery realizowany jest w czasie rzeczywistym. Operator odbiera na bieżąco depesze sensoryczne, informujące o temperaturze, ciśnieniu, współrzędnych geograficznych, położeniu przestrzennym, składowych prędkości oraz zużyciu energetycznym.

Wielowątkowość umożliwiła integrację systemów wykonawczych i sterujących, co pozwoliło na wdrożenie trybu pół-autonomicznego, odpowiedzialnego za realizację misji podwodnej. Operator wyznaczając punkty przejścia, programuje trasę, głębokość oraz prędkość pojazdu, następnie definiuje interwał dokładności – czyli czas, w jakim pojazd będzie się wynurzał –w celu odczytania danych położenia i skorygowania toru przejścia. W tym trybie programowane jest również działanie kamery, która może rejestrować obraz w trybie ciągłym lub w sposób zdefiniowany, np. tylko przy wynurzeniu lub na danej głębokości. Po osiągnięciu zadanego punktu realizowany jest dalszy cel misji, np. rozpoznanie poprzez rejestrację wideo czy samodestrukcję.

Układ wykonawczy oraz sensory zasilane są niezależnie jednym z trzech zamontowanych na pojeździe akumulatorów. Pojemność bazowa wynosi 16 Ah, akumulator jest odseparowany od zasilania układów sterujących (Rys. 4). W przypadku awarii układu sterowania takie rozwiązanie pozwala na utrzymanie wymiany informacji pojazdu ze stacją bazową, ponadto pojazd ma możliwość zbierania danych sensorycznych oraz ciągłej rejestracji obrazu z kamery, nawet do 35 godzin (uzależnione od pojemności przestrzeni dyskowej komputera wykonawczego). Pozostałe dwa akumulatory bezpośrednio zasilają pędniki oraz serwomechanizmy płetw.

System wizyjny realizowany jest za pomocą kamery ArduCam OV5647 z sensorem OV5647 umieszczonej wewnątrz szczelnie zamkniętego kiosku. Kamera wyposażona jest w system motorycznego ustawiania powiększenia i ostrości, co poprawia jakość pracy podczas przemieszczania się pojazdu. Urządzenie

wyposażone jest w matrycę o rozdzielczości 5 Mpx oraz wspiera tryb 1080 px/30 fps. Dodatkowo moduł kamery został wyposażony w obiektyw LS-2718 CS mount o parametrach: ogniskowej 4 mm oraz kącie widzenia równym 93°. Ponadto przesłona 1,4 z formatem 1/2,5” pozwala na nagrywanie całego obszaru roboczego znajdującego się przed pojazdem. Zastosowanie wymienionej przesłony generuje obraz dobrej jakości, zarówno w pełnym słońcu, jak i o zmroku [14]. Taki zestaw łączy się z platformą sprzętową za pomocą dedykowanej taśmy FFC/ FPC. Za realizację podglądu w czasie rzeczywistym (Rys. 7) odpowiada serwer sieciowy RPI-Cam-Web. Interfejs użytkownika umożliwia kontrolę ustawienia kamery za pomocą skryptu przeglądarkowego. Interfejs wykorzystywany jest do podglądu obrazu w czasie rzeczywistym oraz współpracuje z dystrybucją systemów Linux, dzięki czemu jest możliwość elastycznego dopasowania możliwości jego programowania. W zależności od panujących warunków, pory dnia, operator ma możliwość definiowania jasności, kontrastu oraz nasycenia obrazu.

Na Rys. 8 przedstawiono zdjęcia modelu fizycznego pojazdu wykonane w basenie laboratoryjnym, kolejno od lewej burty (a), od dziobu (b) oraz od rufy (c). Konstrukcja przedniej kopuły zapewnia opływowy kształt pojazdu i jednocześnie zabezpiecza mechanizm płetw. Kopuła, kiosk oraz stelaż tylnego napędu zostały wykonane z polilaktydu z wykorzystaniem metody druku 3D o zwiększonych parametrach wytrzymałościowych z przeznaczeniem dla środowiska morskiego. Zespolenie kiosku oraz anteny zostało zrealizowane metodą precyzyjnego dopasowania i wykończenia oraz za pomocą warstwy neutralnego silikonu i kleju termicznie aktywowanego. Oświetlenie i kamera systemu wizyjnego zostały zespolone z kioskiem wyłącznie klejem aktywowanym termicznie.

Testy w środowisku morskim pozwoliły na weryfikację szczelności kadłuba, zakładanej (lekko dodatniej) pływalności oraz stabilności położenia pojazdu. Ponadto umożliwiły sprawdzenie pojazdu w rzeczywistych, niekorzystnych warunkach przy falowaniu do stanu morza 5 stopni skali Beauforta (Rys. 9b). Przeprowadzone testy pozwoliły zweryfikować długotrwałość autonomiczności energetycznej pojazdu oraz podstawowe parametry eksploatacyjne, w tym prędkość przemieszczania

Rys. 6. Planowanie misji podwodnej Fig. 6. Planning of an underwater mission

b) c)

Rys. 8. Zdjęcia modelu fizycznego pojazdu w basenie, widok od: a) lewej burty, b) części czołowej, c) rufy Fig. 8. Images of the physical model of the vehicle in the pool, the view from: a) the left stern, b) the frontal part, c) the stern

się dla zadanych parametrów sterujących zespołu napędowego. Prędkość przemieszczania z maksymalną prędkością wynosi 2,5 m/s, przy zakładanych parametrach żywotność pracy pojazdu na jednym ładowaniu wynoszącym 12 godzin. Dzięki regulowanej mocy oraz zastosowaniu szerokiego rozstawu pędników otrzymano manewrowość pojazdu, którego promień skrętu jest mniejszy niż jeden metr, zapewnia to możliwość szybkiej i precyzyjnej zmiany położenia. Łączność bezprzewodowa w położeniu nawodnym pozwala na sterowanie pojazdem w czasie rzeczywistym, rejestrację obrazu wizyjnego oraz zbieranie danych sensorycznych na dystansie do 120 m. Realizacja misji autonomicznej pozwala na zanurzenie pojazdu do 15 m. W celu niwelacji błędu położenia pojazd powinien wynurzyć się w interwale 100 m w celu rekalkulacji pozycji względem GPS.

a)

b)

Rys. 9 Testy w środowisku morskim w zróżnicowanych warunkach pogodowych, a) stan morza 1-2 w skali Beauforta b) stan morza 4-5 w skali Beauforta Fig. 9. Tests in the marine environment under various weather conditions, a) sea state 1-2 on the Beaufort scale b) sea state 4-5 on the Beaufort scale

Opracowana konstrukcja modułowa umożliwia implementację i testy różnych algorytmów sterowania. Dalsze prace będą prowadzone w szczególności nad zwiększeniem autonomii pojazdu oraz wdrożeniem innowacyjnych algorytmów sterowania napędów hybrydowych. Opracowana konstrukcja umożliwia testowanie zarówno różnych napędów biomimetycznych w celu oceny zakładanych parametrów technicznych i eksploatacyjnych, jak również zaawansowanych algorytmów sterowania o zmiennej modulacji i częstotliwości pracy pędników. Ponadto pojazd może służyć do skrytego rozpoznania wskazanego akwenu, infrastruktury portowej oraz przesyłowej okrętów, a nawet portów. Pojazd może zostać zwodowany w sposób skryty, a następnie zrealizować misję polegającą na dopłynięciu do wskazanego rejonu, zarejestrowaniu obrazu i powrocie we wskazane miejsce w celu przekazania danych lub podłożenia ładunków wybuchowych we wskazane miejsce infrastruktury krytycznej.

Konstrukcja ma potencjał rozwoju w zastosowaniu cywilnym – w inspekcji kadłubów jednostek pływających, rurociągów, obszarów przeznaczonych pod budowę farm wiatrowych, wspierania specjalistycznych prac podwodnych oraz morskich akcji ratunkowych.

Dalsze działania badawcze ukierunkowane będą na zwiększenie możliwości operacyjnych pojazdu przez programową implementację algorytmów sztucznej inteligencji, które z wykorzystaniem specjalistycznych sensorów umożliwią zarejestrowanie, a następnie identyfikację i klasyfikację wybranych obiektów podwodnych, m.in. min, wraki okrętów lub instalacji gazociągowych.

Kolejnym, równie istotnym kierunkiem badań, jest implementacja algorytmów unikania przeszkód oraz zapewnienie zakładanego stopnia autonomii. Zmniejszy to zagrożenie utraty pojazdu, spowodowane kolizją z niewykrytymi elementami znajdującymi się w akwenie wodnym.

“NAŠE MORE: znanstveni časopis za more i pomorstvo”, Vol. 67, No. 1, 2020, 14–18, DOI: 10.17818/NM/2020/1.3.

9. Cohen N., Klein I., BeamsNet: A data-driven approach enhancing Doppler velocity log measurements for autonomous underwater vehicle navigation. “Engineering Applications of Artificial Intelligence”, Vol. 114, 2022, DOI: 10.1016/j.engappai.2022.105216.

1. Olejnik A., Tendencje rozwojowe bezzałogowej techniki morskiej. „Polish Hyperbaric Research”, Vol. 55, No. 2, 2016, 7–28, DOI: 10.1515/phr-2016-0008.

2. Panda J.P., Mitra A., Warrior H.V., A review on the hydrodynamic characteristics of autonomous underwater vehicles “Proceedings of the Institution of Mechanical Engineers, Part M: Journal of Engineering for the Maritime Environment”, Vol. 235, No. 1, 2021, 15–29, DOI: 10.1177/1475090220936896.

3. Malec M., Morawski M., Zając J., Fish-like swimming prototype of mobile underwater robot. “Journal of Automation, Mobile Robotics and Intelligent Systems”, Vol. 4, No. 3, 2010, 25–30.

4. Szymak P., Praczyk T., Naus K., Szturomski B., Malec M., Morawski M., Research on biomimetic underwater vehicles for underwater ISR. “Ground/Air Multisensor Interoperability, Integration, and Networking for Persistent ISR VII”, SPIE, Vol. 98310L, 126–139, DOI: 10.1117/12.2225587.

5. Piskur P., Szymak P., Sznajder J., Identification in a laboratory tunnel to control fluid velocity. [In:] Advanced, Contemporary Control, 2020, 1543–1552, Springer, Cham, DOI: 10.1007/978-3-030-50936-1_128.

6. Felski A., Jaskólski K., Zwolak K., Piskur P., Analysis of Satellite Compass Error’s Spectrum. “Sensors”, Vol. 20, No. 15, 2020, DOI: 10.3390/s20154067.

7. Jaskólski K., Marchel Ł., Felski A., Jaskólski M., Specht M., Automatic Identification System (AIS) Dynamic Data Integrity Monitoring and Trajectory Tracking Based on the Simultaneous Localization and Mapping (SLAM) Process Model “Sensors”, Vol. 21, No. 24, 2021, DOI: 10.3390/s21248430.

8. Piskur P., Gąsiorowski M., Digital Signal Processing for Hydroacoustic System in Biomimetic Underwater Vehicle.

10. Jebelli A., Chaoui H., Mahabadi A., Dhillon B., Tracking and mapping system for an underwater vehicle in real position using sonar system. “International Journal of Robotics and Automation”, Vol. 37, No. 1, 2022.

11. Żak B., Hożyń S., A Concept for Application of a Stereo Vision Method in Control System of an Underwater Vehicle [In:] Applied Mechanics and Materials, Vol. 817, 2016, 73–80, DOI: 10.4028/www.scientific.net/AMM.817.73.

12. Divsalar K., Improving the hydrodynamic performance of the SUBOFF bare hull model: a CFD approach. “Acta Mechanica Sinica”, Vol. 36, No. 1, 2020, 44–56, DOI: 10.1007/s10409-019-00913-7.

13. Szymak P., Praczyk T., Pietrukaniec L., Hożyń S., Laboratory stand for research on mini CyberSeal. “Measurement Automation Monitoring”, Vol. 63, No. 7, 2017, 228–233.

14. Powarzyński D., Mobile Wheeled Robot to Support the Task of the Alarm Sub – Unit, “Scientific Journal of Polish Naval Academy”, Vol. 223, No. 4, 2020, 53–66, DOI: 10.2478/sjpna-2020-0015.

15. Kiciński R., Szturomski B., Pressure Wave Caused by Trinitrotoluene (TNT) Underwater Explosion—Short Review “Applied Sciences”, Vol. 10, No. 10, 2020, DOI: 10.3390/app10103433.

16. BlueRobotics, T200 Thruster, https://bluerobotics.com/ store/thrusters/t100-t200-thrusters/t200-thruster-r2-rp/

17. Python, multiprocessing — Process-based parallelism, https://docs.python.org/3/library/multiprocessing.html

18. https://github.com/bluerobotics/ms5837-python

19. https://pypi.org/project/pyax12/

20. https://docs.python.org/3/library/socket.html

The article presents the design and implementation of an unmanned underwater vehicle with hybrid propulsion system. The vehicle can be controlled remotely as well as it has the ability to reach the indicated area in order to carry out reconnaissance and attack by detonating the carried load or self-destructing. The article presents both the hardware and software layers as well as the results of preliminary tests.

Keywords

ORCID: 0000-0002-4554-2546

ORCID: 0000-0002-8823-4316

ORCID: 0000-0001-9031-1504

ORCID: 0000-0003-2131-1660

ORCID: 0000-0002-3513-62454

Tekstroniczne transpondery RFID rozszerzają możliwości projektantów sprzętu AGD. Nowego zastosowania można doszukać się w technice pralniczej, gdzie za pomocą transponderów RFID wszytych w odzież możliwe jest zakodowanie informacji i późniejsze ich wykorzystanie do wyboru najlepszego programu prania dla danego rodzaju tkaniny lub prowadzenia statystyk zużycia materiału. W ramach prac zaprojektowany i zbudowany został model demonstracyjny urządzenia piorącego wykorzystującego do swojego działania transpondery (identyfikatory) RFIDtex. Przygotowano system sterowania dla zbudowanego modelu pralki wyposażonej w urządzenie RWD (Read-Write Device), wspierający podejmowanie decyzji o wyborze danej funkcji na podstawie danych dostarczanych przez identyfikatory RFIDtex zintegrowane z odzieżą. W ramach prac sprawdzono również skuteczność działania urządzenia z wykorzystaniem przygotowanych próbek.

1.

Wprowadzenie

Naturalną cechą człowieka jest poszukiwanie sposobów ułatwienia codziennego życia. Szczególnie poszukujemy rozwiązań dla czynności, które są przez nas regularnie powtarzane, jak pranie ubrań, przygotowywanie posiłków i inne. Już w 1858 r. Hamilton Smith zgłosił pierwszy patent na pralkę wykorzystującą bęben obrotowy, a blisko 20 lat później, w 1874 r., William Blackstone zaprojektował urządzenie piorące jako prezent dla żony [1]. Rozwój napędów elektrycznych w XX w. umożliwił uproszczenie budowy i zintegrowanie całego napędu pralki [2]. Przez lata zasada prania ubrań z wykorzystaniem wody i detergentów nie zmieniała się, ale sama konstrukcja pralki była ciągle unowocześniana. Mimo wielu zmian na przestrzeni całego okresu eksploatacji urządzeń piorących użytkownik nadal decyduje o tym, co umieszcza w bębnie oraz jakie detergenty i parametry prania stosuje do włożonej mieszaniny różnych rodzajów ubrań. Wybór choćby jednego złego elementu z grupy zróżnicowanych ustawień może spowodować nieodwracalne uszkodzenia.

Rozwiązaniem tego problemu może być zastosowanie odpowiednich algorytmów, które przejęłyby etap decyzyjny, odciążając tym samym użytkownika od rutynowych działań. Aby to było możliwe system wbudowany musi zostać poinformowany o zawartości bębna. Ręczne wprowadzanie danych o parametrach ubrań na panelu pralki jest często mało wygodne i uciążliwe. Aby usprawnić ten etap można w odzieży umieścić identyfikatory, na podstawie których będzie można bezprzewodowo uzyskać dokładne informacje o materiale i zaleceniach jego konserwacji. Potencjalnym nośnikiem danych jest transponder tekstroniczny RFIDtex opracowany na Politechnice Rzeszowskiej [3].

Zastosowanie nowoczesnych rozwiązań opartych na technice RFID w sprzęcie AGD może pomóc wypracować zupełnie nowe, odmienne podejście do prania automatycznego. Zaangażowanie użytkownika w cały proces obsługi można ograniczyć do niezbędnego minimum. Temperatura wody, ilość detergentu, liczba poszczególnych powtórzeń etapów czy prędkość obrotowa bębna mogą zostać automatycznie dostosowane do zawartości bębna. Potencjał jest znacznie większy, gdy wykorzystamy rozwiązania z obszaru Internetu Rzeczy. Dzięki temu dla nowych tkanin programy prania zawsze będą aktualne, a samo urządzenie piorące nie będzie wyłącznie skonfigurowane pod kilka lub kilkanaście stałych, mało modyfikowalnych planów pracy. W tej idei można pójść o krok dalej, zbierając informacje zwrotne, na przykład o degradacji materiału, czy generując dokładne statystyki. W przemysłowym, a więc masowym wykorzystaniu, jak w branży hotelarskiej, pozwoli to na optymalizację kosztów za pomocą świadomego wybierania jakości pościeli czy ręczników. Proponowane podejście może przedłużyć żywotność ubrań, zoptymalizować zużycie wody, energii elektrycznej i detergentów czyniąc codzienny proces bardziej ekologicznym.

Niestety, pralki wykorzystujące systemy RFID nie są dostępne na rynku konsumenckim. Aktualne badania dotyczą samego wpływu procesu prania na transpondery tekstylne RFID w standardowych pralkach [4, 5]. W rezultacie nie było możliwe przetestowanie działania eksperymentalnych transponderów RFIDtex w warunkach zbliżonych do rzeczywistych. Stąd zaistniała potrzeba zbudowania modelu pralki automatycznej, umożliwiającego badania laboratoryjne oraz badania skuteczności odczytu danych z transponderów tekstronicznych zintegrowanych z tkaninami. Dopiero w przypadku zapewnienia wysokiej skuteczności identyfikacji i przeprowadzenia kompleksowego odczytu informacji z pamięci transponderów wbudowanych w tkaniny, możliwe jest zaimplementowanie zaawansowanej funkcjonalności.

Opracowany model pozwala na symulację pierwszej fazy prania tkanin, czyli umieszczanie tkanin z naszytymi transponderami w bębnie i sterowanie bębnem w taki sposób, aby możliwe było odczytanie informacji o znajdujących się w nim tekstyliach. Założono, że program sterujący pracą modelu powinien sugerować najlepszy program prania dla tkanin umieszczonych w bębnie. W pracy opisano strukturę mechaniczną, elektryczną i elektroniczną modelu laboratoryjnego oraz wstępne badania skuteczności identyfikacji tkanin za pomocą zintegrowanych transponderów RFIDtex. Odrębnym przedmiotem badań pozostają procedury związane z algorytmami odczytu transponderów, modelem protokołu komunikacyjnego oraz doborem odpowiedniego programu mycia.

Podstawowy system identyfikacji radiowej (RFID) złożony jest z urządzenia odczytująco-zapisującego (RWD) wyposażonego w co najmniej jedną antenę oraz co najmniej jednego transpondera (ID), który zawiera w swojej strukturze obwód anteny, mikroprocesor i pamięć (rys. 1). W zintegrowanej pamięci transpondera zawiera się numer seryjny i inne spreparowane dane o identyfikowanym obiekcie. Dane odczytane za pomocą RWD są najczęściej przekazywane do dalszej analizy. Możliwe jest również zapisywanie danych do pamięci transpondera. Pozwala to na aktualizację zawartości pamięci transpondera na różnych etapach cyklu życia identyfikowanego obiektu. Proces wymiany danych między RWD a ID odbywa się tylko w strefie odpytywania (IZ) systemu RFID [6]. Definicję IZ można rozumieć jako grupę warunków polowych, elektrycznych i komunikacyjnych, które muszą być spełnione aby uzyskać pewne rozpoznanie wielu obiektów oznaczonych transponderami. Jeżeli w IZ znajduje się tylko jeden obiekt z ID, proces rozpoznawania obiektu nazywany jest identyfikacją pojedynczą. Jeżeli w IZ znajduje się wiele obiektów wyposażonych w ID, wymiana danych z nimi wszystkimi odbywa się z wykorzystaniem mechanizmu antykolizyjnego zgodnie z algorytmem określonym przez protokół i nazywa się to identyfikacją wielokrotną [7].

W ostatnich pracach badawczych synteza IZ obejmowała badania eksperymentalne oraz obliczenia analityczne i numeryczne zasięgu systemu RFID [8], ale w rzeczywistych wdrożeniach często stosowana jest metoda prób i błędów [9]. W przypadku, gdy wewnątrz IZ znajduje się wiele obiektów, a ich położenie i orientacja może zmieniać się dynamicznie, obliczenia parametrów systemu RFID są jeszcze bardziej wymagające ze względu na parametry opisujące dynamikę zmian w systemie. Aby usystematyzować działanie systemów RFID, opracowano kilka standardów. Najpopularniejszymi przykładami są ISO 15693 [10], ISO 14443 [11] oraz ISO 18000 [12].

Rys. 1. Uproszczony schemat działania systemu RFID z różnymi rodzajami transponderów Fig. 1. A simplified diagram of an RFID system operation with different types of transponder

Warunki pracy proponowanego systemu RFID podyktowały wybór transponderów zgodnych z normą ISO 18000-63. Umożliwiają one identyfikację wielu obiektów jednocześnie, dzięki zaimplementowanym w normie protokołom antykolizyjnym.

Systemy identyfikacji radiowej RFID UHF pracują zazwyczaj w zakresie 860–960 MHz, a także na częstotliwościach 2,45 GHz i 5 GHz. Wybór wartości częstotliwości pracy zależy od regionu świata. Na kontynencie europejskim systemy RFID działają w zakresie 865–870 MHz zgodnie z protokołem określonym przez normę ISO/IEC 18000-63. Obecnie w tym zakresie częstotliwości funkcjonują cztery rodzaje transponderów: pasywne, półpasywne, półpasywne z systemem zbierania energii oraz tekstroniczne.

Najpopularniejszy transponder pasywny RFID zawiera antenę i chip (rys. 2a). Podłoże może przybierać różne kształty, zazwyczaj są to breloki, karty, etykiety, szklane tuby, krążki, monety. Mogą być wykonane z materiałów takich jak ceramika, plastik, metal, szkło itp. Dostęp do wewnętrznej pamięci transponderów jest możliwy tylko przez RWD z wykorzystaniem interfejsu radiowego [13].

Kolejną grupą o rosnącym znaczeniu na rynku są półpasywne transpondery RFID ze zintegrowanym dodatkowym zasilaniem (np. wymiennym lub niewymiennym akumulatorem litowym) (rys. 2b). Dodatkowa moc baterii jest wykorzystywana do zwiększenia zasięgu odczytu, a tym samym strefy odpytywania [13], ale może być również wykorzy-

stana do zapewnienia dodatkowych funkcji zaimplementowanych w strukturze transpondera (rys. 2c). Dodatkowe funkcje transpondera mogą przybierać różne formy, takie jak pomiary wielkości fizycznych (temperatury, ciśnienia, wilgotności), przechowywanie zebranych informacji w rozszerzonej pamięci lub wymiana danych przez dodatkowe interfejsy radiowe lub kablowe [14].

Niezależnie od pasma częstotliwości, podstawowo transponder RFID składa się z chipa elektronicznego i anteny [13]. Najczęściej takie urządzenie budowane jest jako jednolita konstrukcja, w której chip jest wlutowany [15], wklejony [16] lub w inny sposób [17] podłączony do anteny. W tej konstrukcji antena transpondera wykonana jest z materiałów przewodzących na podłożu sztywnym (np. laminat niskożelazowy, ceramiczny) lub elastycznym (np. papier, PET, Kapton). Zgodnie z nowoczesną koncepcją automatycznych systemów identyfikacji RFID, transpondery są mocowane do obiektów na różne sposoby, na stałe lub czasowo [13]. Powoduje to wytwarzanie transponderów o różnych kształtach. Nie ma uniwersalnej konstrukcji transpondera do oznaczania dowolnego obiektu. W każdym przypadku rozwoju systemu RFID należy wybrać transponder z gotowych konstrukcji lub (co jest korzystniejsze) zaprojektować rozwiązanie dedykowane danemu obiektowi z uwzględnieniem wielu pól fizycznych, chemicznych, elektromagnetycznych, elektrycznych i komunikacyjnych warunków jego pracy w docelowym zastosowaniu systemu RFID.

Najnowsze podejście do projektowania transponderów RFID pokazano na rysunku 2d. W tego typu konstrukcjach chip i antena umieszczone są na fizycznie odseparowanych i izolowanych galwanicznie podstawach. Antena może być haftowana lub wszyta nićmi przewodzącymi, jak również innymi technikami, np. przez wciśnięcie drutu przewodzącego stanowiącego antenę w tkaninie. Transponder RFIDtex [3] może być wytwarzany jako wykrój (np. guzik lub etykieta) i zintegrowany z tkaniną przez przyszycie go do oznakowanego elementu tekstylnego. Dzięki tej koncepcji (rys. 2d) można uniknąć problemów związanych z podłączeniem chipa RFID do elastycznego i postrzępionego podłoża tekstylnego, a tym samym można zwiększyć wytrzymałość układu scalonego [18, 19].

Głównym celem opracowanego laboratoryjnego modelu pralki był demonstracyjny charakter zastosowania transponderów tekstronicznych RFIDtex ISO 18000-63 w przyszłych, nowoczesnych urządzeniach AGD oraz możliwość prowadzenia pomiarów wydajności identyfikacji w środowisku symulującym pranie. Głównym zadaniem skonstruowanego urządzenia było odczytanie informacji z pamięci transponderów wszytych w odzież umieszczoną w bębnie maszyny, które zawierały unikalny numer UID oraz informacje dotyczące ograniczeń zdefiniowanych przez producenta, jak temperatura i typ prania, możliwość wirowania czy rodzaj polecanych detergentów. W oparciu o odczyty danych z wielu transponderów zaprojektowano również system wspomagający podejmowanie decyzji o odpowiednim programie prania oraz wyświetlający informacje o wybranym programie. Dodatkowo system został wyposażony w funkcję programowania transponderów za pomocą urządzenia do odczytu/zapisu oraz możliwość szybkiego odczytu pojedynczego transpondera. Funkcje te są używane przez użytkownika do samodzielnego zapisywania dodatkowych informacji w pamięci transponderów wbudowanych w odzież.

Na rysunku 3 przedstawiono uproszczony schemat blokowy zaprojektowanego i wykonanego urządzenia. Centralnym elementem jest mikrokontroler STM32, który odpowiada za odbieranie, przesyłanie i przetwarzanie danych. Mikrokontroler steruje pracą urządzenia RWD, wyświetlacza oraz jednostki napędowej bębna pralki. Do mikrokontrolera bezpośrednio podłączony jest dotykowy wyświetlacz LCD. Dzięki temu można zarządzać całym urządzeniem, a przetwarzane dane prezentować w przyjaznej dla użytkownika formie. Urządzenie odczytująco-zapisujące UHF FEIG jest podłączone do mikrokontrolera za pomocą konwertera RS-232–UART. Aby odczytać dane z transponderów wszytych w ubrania do urządzenia odczytująco-zapisującego podłączono przez multiplekser trzy anteny zewnętrzne. Mikrokontroler steruje pracą układu napędowego zmieniając położenie ubrań względem nieruchomych anten. Urządzenie zostało również wyposażone w zestaw czujników mierzących prędkość obrotową bębna, umożliwiających precyzyjnie zaplano-

Rys. 2. Rodzaje budowy identyfikatorów RFID Fig. 2. Types of construction of RFID tags

wany obrót, oraz czujnik otwarcia drzwiczek zapobiegający nieplanowanemu uruchomieniu urządzenia.

Aby zapewnić wysoką skuteczność identyfikacji w proponowanym systemie konieczna jest optymalizacja procesu skanowania odzieży. Na dokładność odczytu danych z pamięci transpondera ma wpływ wiele czynników, m.in. odległość transpondera od anteny, zakłócenia zewnętrzne oraz liczba transponderów w strefie odpytywania. Przedstawiona na uproszczonym schemacie blokowym koncepcja procesu skanowania (rys. 4) zakłada odczyt danych z pamięci transpondera podczas obrotu bębna, a szczegółowe opracowanie zostanie poświęcone szczegółom algorytmu i modelu komunikacji.

Rys. 4. Algorytm procesu skanowania w urządzeniu piorącym Fig. 4. Algorithm of the scanning process in the washing machine

Mikrokontroler STM32 steruje opracowanym laboratoryjnym modelem pralki. Mikrokontroler oparty został na 32-bitowym procesorze ARM serii Cortex-M4, ma 512 kB pamięci FLASH i 128 kB pamięci RAM. Płyta ewaluacyjna w wersji Nucelo-64 ma dodatkowe wyprowadzenia i zintegrowany programator oraz debugger [20].

Poszczególne elementy zostały połączone z mikrokontrolerem zgodnie z szczegółowym schematem blokowym, na którym strzałkami zaznaczono kierunki przesyłania informacji (rys. 5). Sposób komunikacji został odpowiednio dobrany dla każdego komponentu. W celu prawidłowego uporządkowania przestrzennego podzespołów w urządzeniu zaprojektowano dwie płyty PCB (rys. 6), pozwalające na odpowiednią organizację okablowania w obudowie modelu pralki.

Płyty przyłączeniowe zostały również zaprojektowane w taki sposób, aby wiele elementów można było łatwo zamontować do obudowy urządzenia. Płyta oznaczona jako PCB1 jest w formie nakładki na płytę ewaluacyjną mikrokontrolera oraz jest elementem łączącym płytę z mikrokontrolerem i PCB2. Zaprojektowane płyty połączone zostały ze sobą złączem Molex Mini-Fit (raster 4,2 mm). Na płycie PCB2 zainstalowano przetwornice DC. Do płyty PCB2 za pomocą dodatkowych złącz podłączone zostały zewnętrzne czujniki, sterownik silnika i urządzeniem odczytu/zapisu FEIG RFID (przez konwerter RS-232) (rys. 7).

W obudowie pralki zintegrowany został ekran z panelem dotykowym. Wyświetlacz służy do sterowania urządzeniem, a także przedstawia informacje, które są istotne dla użyt-

kownika. Dodatkowo umożliwia podgląd wykrytych transponderów oraz raportów o błędach jakie wystąpiły podczas skanowania zawartości bębna.

Do sterowania pracą silnika wykorzystany został zewnętrzny układ mostka H, który na podstawie otrzymanego sygnału PWM na wejściu umożliwia zmianę kierunku oraz prędkości obrotowej bębna. W celu zwiększenia precyzji sterowania wykorzystano układ sprzężenia zwrotnego z czujnika magnetycznego. Poszczególne elementy elektroniczne zasilane były z wbudowanego zasilacza prądu stałego o napięciu 12 V.

Jako urządzenie odpowiedzialne za odczyt i zapis pamięci transponderów zastosowano FEIG ID ISC.MRU102 RWD [68]. Jest to urządzenie pracujące w paśmie UHF. Praca w tym zakresie częstotliwości daje możliwość odczytu w średnich i krótkich zakresach, współpracując jednocześnie z wieloma transponderami znajdującymi się w strefie odpytywania urządzenia RWD. System ten został wyposażony przez producenta w porty komunikacyjne takie jak RS-232 i USB. Dostępna jest wbudowana antena na płycie RWD. System został przystosowany do pracy zarówno z transponderami krótkiego, jak i dalekiego zasięgu. Urządzenie RWD zostało również wyposażone w trzy złącza, umożliwiające podłączenie trzech dodatkowych anten zewnętrznych. Za pracę tych anten odpowiada multiplekser zintegrowany z RWD. Aby opracowane urządzenie działało poprawnie i efektywnie, zapewniając odpowiednią skuteczność identyfikacji, zostało opracowane dedykowane oprogramowanie.

Rys. 3. Uproszczony schemat blokowy urządzenia Fig. 3. Simplified block diagram of the device

Rys. 5. Schemat blokowy opracowanego prototypu urządzenia piorącego Fig. 5. A block diagram of the development of a washing device prototype

Rys. 6. Płyty PCB wykorzystane w prototypie urządzenia piorącego Fig. 6. PCBs used in the washing machine prototype

6. Sterowanie

Obsługa wielu różnorodnych komponentów oraz zintegrowanie z usługami chmurowymi wymagało podzielenia oprogramowania na części. Specyfikacja problemu sterowania urządzenia piorącego, którego elementy elektroniczne mogą ulec zmianie

w przyszłości wpasowuje się w koncepcje maszyny wirtualnej [21]. Możliwość przenaszalności oprogramowania w tego rodzaju systemach wbudowanych otwiera nowe możliwości personalizacji, generując wymierne ekonomiczne skutki.

Oprogramowanie podzielone zostało wg schematu przedstawionego na rysunku 5. Koncepcja wzoruje się na niezwodnych systemach sterowania stosowanych przez sterowniki PLC. Nisko-

poziomowa obsługa elementów takich jak urządzenie RWD, wyświetlacz z panelem dotykowym implementowane obsługiwane są poza systemem sterowania. Właściwe sterowanie urządzeniem, czyli programy prania, obsługa czujników czy interakcja z użytkownikiem opracowana została z wykorzystaniem języków normy ISO 61131-3 na platformie CPDev [22]. Wymiana danych między niskopoziomową obsługa peryferii a programem sterownia maszyną piorącą odbywa się za pomocą wspólnej pamięci i specjalnych bloków natywnych. Implementacja sterowania cyklem prania wpasowuje się w koncepcje grafów sekwencji języka SFC.

Zaletą zastosowania wymienionego podziału bloków oprogramowania jest łatwość aktualizacji bez wpływu na zastosowane peryferia. Jednakowy program prania może zostać zaimplementowany w wielu różnorodnych urządzeniach. Praktyczna realizacja urządzenia piorącego wymaga wzięcia pod uwagę współczesnych wymogów, jak funkcji dodania ubrania w czasie prania. Realizacja takich zmian w programach w języku SFC jest uproszczona. Najważniejszą zaletą jest jednak możliwość przygotowania niezależnych programów prania dla specjalistycznych detergentów czy zestawów ubrań. Zasada działania pralek bębnowych dostępnych aktualnie nie różni się między producentami, zauważalne są wyłącznie ograniczenia maksymalnej masy umieszczonej w bębnie lub prędkości obrotowej bębna.

Urządzenie może zostać z łatwością przystosowane do aktualnych warunków w danym regionie.

Podstawowym badanym aspektem była efektywność systemu identyfikacji umieszczonych transponderów wewnątrz bębna, która miała na celu zobrazowanie precyzji działania opracowanego modelu urządzenia oraz poprawności projektu pod kątem prawidłowego wdrożenia systemu RFID w modelu laboratoryjnym pralki. Podczas testów przyjęto kilka założeń. Do badań wykorzystano tkaniny bawełniane z naszytymi transponderami RFIDtex. Bęben wypełniony był wyłącznie tkaninami wyposażonymi w transpondery. Identyfikacji grup transponderów dokonano podczas ruchu bębna, symulując w ten sposób warunki panujące w bębnie pralki. W opracowanym modelu w bębnie nie było wody. Podczas procesu skanowania bęben był obracany, aby każdy ze zintegrowanych z tkaniną identyfikatorów znajdował się jak najbliżej układu antenowego RWD przez określony czas.

W celu stworzenia bezszumowego środowiska i uniknięcia wpływu zaburzeń elektromagnetycznych na badane urządzenie

Rys. 8. Wyniki efektywność odczytu transponderów RFIDtex w modelu pralki Fig. 8. The results of the efficiency of reading RFIDtex transponders in a washing machine model

badania przeprowadzono w komorze bezechowej. Zastosowanie technologii RFID wymagało odpowiednich rozwiązań technicznych i materiałów, aby zaproponować demonstracyjne środowisko pracy systemu RFID wolne od wpływu metali na proces odczytu numeru seryjnego transponderów RFIDtex, a także uzyskania odpowiedniej strefy odpytywania. Testy urządzeń polegały na wykonaniu skanu polegającego na odczytaniu numerów seryjnych transponderów. Dane były następnie przetwarzane przez mikrokontroler i przechowywane w pamięci systemu.

W ramach testów przeprowadzono proces identyfikacji w zakresie od jednego do trzydziestu transponderów. Przy każdej próbie odczytu, w bębnie opracowanego urządzenia umieszczano z góry określoną liczbę transponderów (od 1 do 30) i podejmowano pięć prób odczytu grupy. Pojedyncza sekwencja odczytu trwała 2 s, z czego połowa czasu była przeznaczona na analizę i zapis uzyskanych wyników. Na podstawie liczby poprawnie odczytanych transponderów w każdej próbie, określono średnią liczbę identyfikacji w pięciu próbach oraz procentową skuteczność identyfikacji grupy transponderów.

Zastosowane w modelu urządzenie RWD firmy FEIG zostało wyposażone w funkcję wielokrotnego odczytu grupy transponderów. Cechę tą wykorzystano w celu zwiększenia wydajności modelu. Opracowane rozwojowe oprogramowanie zapisywało w pamięci systemu mikroprocesorowego wynik ustawionej sekwencji odczytów grupy transponderów, a następnie dynamicznie budowało listę odczytanych transponderów. Dzięki zaimplementowaniu tej funkcjonalności udało się zwiększyć efektywność odczytu grupy transponderów, co udowodniono powtarzając proces identyfikacji w zakresie od dwóch do sześciu odczytów grupy transponderów. Próby te powtórzono również pięć razy. Czas trwania skanów dostosowywany był dynamicznie dzięki możliwościom protokołu ISO18000-63.

Uzyskane wyniki pomiarów (rys. 12) świadczą o poprawności działania zaprojektowanego i wykonanego demonstratora laboratoryjnego. Nawet przy pojedynczym skanie, który obejmował identyfikację grupy obiektów wyposażonych w transpondery, system wykazał wysoką skuteczność odczytu (rzędu 100 %) do 15 obiektów w bębnie. Zwiększenie liczby skanów spowodowało osiągnięcie 100 % skuteczności identyfikacji, nawet jeśli w bębnie znajdowało się do 22 obiektów. Zmie-

rzona skuteczność identyfikacji grup spadła najszybciej przy użyciu tylko jednego skanu, a dla 30 obiektów w bębnie wyniosła tylko 46 %. W przypadku grupy skanowanej sześciokrotnie sprawność nawet przy 30 obiektach w bębnie utrzymała się na poziomie 90 %. To pokazało, że możliwe jest efektywne wykorzystanie systemów RFID i transponderów RFIDtex w technologii pralniczej.

Przedmiotem pracy było zautomatyzowanie działania urządzeń piorących za pomocą identyfikacji bezprzewodowej z wykorzystaniem identyfikatorów RFIDtex. Zaprojektowany i zbudowany został model laboratoryjny pralki wspierającej proponowany system, umożliwiający badanie pracy takich urządzeń. Podczas realizacji modelu przyjęto założenie, że identyfikacja będzie odbywać się gdy bęben nie jest wypełniony wodą. Wynikało to z założenia o dostosowaniu programu prania do zestawu odzieży z możliwością usunięcia elementów powodujących znaczne konflikty z wybranymi parametrami.

Opracowany i zbudowany model został poddany serii testów, które wykazały sprawną identyfikację transponderów wewnątrz bębna. W ramach prac opracowano również oprogramowanie do zarządzania urządzeniami wraz z odpowiednim modelem komunikacji.

Opracowane urządzenie demonstruje innowacyjne podejście do procesu prania tekstyliów sterowane informacjami odczytanymi z transponderów RFIDtex wszytych w tkaniny. Może służyć jako podstawa do budowy w pełni funkcjonalnego prototypu pralki automatycznej, która wykorzystuje informacje zapisane w pamięci transponderów RFID do dostosowywania procesu prania.

Należy podkreślić, że wykorzystanie informacji o parametrach tkanin może pozwolić na zupełnie nowe podejście do sterowania procesem prania. Otwiera również zupełnie nowe pola badawcze, wśród których są aspekty związane ze sterowaniem procesem prania, w tym doborem najlepszego programu prania dla wielu tkanin jednocześnie, sterowaniem procesami automatycznego dozowania detergentu, prędkością obrotów bębna czy zmianami temperatury wody podczas procesu pra-

nia oraz wpływ całego procesu sterowania na zużycie wody, energii elektrycznej i detergentów.

Projekt finansowany w ramach programu Ministra Edukacji i Nauki pod nazwą „Reginalna Inicjatywa Doskonałości” w latach 2019–2023 nr projektu 027/RID/2018/19 kwota finansowania 11 999 900 zł.

1. Maxwell L.M., Save Womens Lives: History of Washing Machines, 1st ed.; Oldewash: Eaton, CO, USA, 2003; ISBN 978-0972971003.

2. Ho T., Chen M.-S., Lin J.-S., Chen P.-H., The design and implementation of the BLDC motor drive for a washing machine. [In:] Proceedings of the 1st IEEE Global Conference on Consumer Electronics, Tokyo, Japan, 2012, 156–157, DOI: 10.1109/GCCE.2012.6379565.

3. Liu T., Lin C., Lo C., Implementation of a novel high-perJankowski-Mihułowicz P., Węglarski M., Chamera M., Pyt P., Textronic UHF RFID Transponder. „Sensors”, Vol. 21, No. 4, 2021, DOI: 10.3390/s21041093.

4. NXP Demonstrates NFC Washing Machine. https://www. nfcw.com/2012/03/05/314143/nxp-demonstrates-nfc-washing-machine.

5. Shen B., Ding X., Wang Y., Ren S., RFID-Embedded Smart Washing Machine Systems in the Big Data Era: Value Creation in Fashion Supply Chain. [In:] Fashion Supply Chain Management in Asia: Concepts, Models, and Cases; Shen B., Gu Q., Yang Y., Eds.; Springer Series in Fashion Business; Springer: Singapore, 2019. DOI: 10.1007/978-981-13-2294-5_7.

6. Ukkonen L., Sydanheimo L., Kivikoski M., Read Range Performance Comparison of Compact Reader Antennas for a Handheld UHF RFID Reader. “IEEE Communications Magazine”, Vol. 45, No. 4, 2007, 24–31, DOI: 10.1109/MCOM.2007.348674.

7. Gotfryd M., Lichoń W., Pawłowicz B., The issue of data exchange in the UHF band RFID system with an Semi-Passive Transponder. “International Journal of Electronics and Telecommunications”, Vol. 62, No. 2, 2016, 141–146. DOI: 10.1515/eletel-2016-0019.

8. Węglarski M., Jankowski-Mihułowicz P., Factors Affecting the Synthesis of Autonomous Sensors with RFID Interface “Sensors”, Vol. 19, No. 20, 2019, DOI: 10.3390/s19204392.

9. Honeywell International Inc. Intermec RFID Tags & Media, Meeting the Scalable RFID Challenge; Honeywell International Inc.: Charlotte, NC, USA, 2013.

10. International Organization for Standardization/International Electrotechnical Commission. Identification Cards—Contactless Integrated Circuit Cards—Vicinity Cards; ISO/IEC: Geneva, Switzerland, 2006.

11. International Organization for Standardization/International Electrotechnical Commission. Identification Cards—Contactless Integrated Circuit Cards—Proximity Cards; ISO/IEC: Geneva, Switzerland, 2016.

12. International Organization for Standardization/International Electrotechnical Commission. Information Technology— Radio Frequency Identification for Item Management—Part 6: Parameters for Air Interface Communications at 860 MHz to 960 MHz General; ISO/IEC: Geneva, Switzerland, 2013.

13. Dobkin D.M., The RF in RFID: UHF RFID in Practice, 2nd ed.; Newnes: Oxford, UK, 2012.

14. Węglarski M., Jankowski-Mihułowicz P., Pitera G., Jurków D., Dorczyński M., LTCC Flow Sensor with RFID Interface. „Sensors”, Vol. 20, No. 1, 2020, DOI: 10.3390/s20010268.

15. Oppert T., Azdasht G., Zakel E., Teutsch T., Laser assisted soldering and Flip-Chip attach for 3-D packaging. [In:] Proceedings of the 31st IEEE/CPMT International Electronics Manufacturing Technology Symposium, Petaling Jaya, Malaysia, 2006, DOI: 10.1109/IEMT.2006.4456437.

16. Simegnaw A.A., Malengier B., Rotich G., Tadesse M.G., Van Langenhove L., Review on the Integration of Microelectronics for E-Textile. “Materials”, Vol. 14, No. 17, 2021, DOI: 10.3390/ma14175113.

17. Wang Y., Gauch M., Ristau D., Overmeyer L., Fine-pitch chip-on-flex packaging of optoelectronic devices using low tem-perature optodic bonding. [In:] Proceedings of the Pan Pacific Microelectronics Symposium, Big Island, HI, USA, 2016, DOI: 10.1109/PanPacific.2016.7428418.

18. Corchia L., Monti G., Tarricone L., Wearable antennas: Nontextile versus fully textile solutions. “IEEE Antennas and Propagation Magazine”, Vol. 61, No. 2, 2019, 71–83, DOI: 10.1109/MAP.2019.2895665.

19. Luo C., Gil I., Fernández-García R., Wearable Textile UHFRFID Sensors: A Systematic Review. “Materials”, Vol. 13, No. 15, 2020, DOI: 10.3390/ma13153292.

20. UM1724 User Manual STM32 Nucleo-64 Boards (MB1136). www.st.com/resource/en/user_manual/um1724-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf.

21. Sadolewski J., Trybus B., Compiler and virtual machine of a multiplatform control environment. “Bulletin of the Polish Academy of Sciences. Technical Sciences”, Vol. 70, No. 2, 2022, DOI: 10.24425/bpasts.2022.140554.

22. Rzo ca D., Sadolewski J., Stec A., wider Z., Trybus B., Trybus L., Developing a multiplatform control environment, “Journal of Automation Mobile Robotics and Intelligent Systems”, Vol. 13, No. 4, 2019, 73–84, DOI: 10.14313/JAMRIS/4-2019/40.

Textronic RFID transponders extend the possibilities of home appliance design. New application can be found in the laundry technology, where by means of RFID transponders sewn into the garment it is possible to encode information and use it later to select the best washing program for a given type of fabric or to keep statistics of material usage. As part of this work, a demonstration model of a washing device using RFIDtex transponders (identifiers) was designed and built. A control system was prepared for the constructed model of a washing machine equipped with a RWD (Read-Write Device) device, supporting decision-making about the selection of a given function on the basis of data provided by RFIDtex identifiers integrated with the clothing. The effectiveness of the device was also checked using prepared samples.

Keywords

ORCID: 0000-0002-2748-1145

ORCID: 0000-0003-4280-6611

ORCID: 0000-0001-9469-2754

ORCID: 0000-0002-9199-3460

ORCID: 0000-0002-4588-3973

Pomiary Automatyka Robotyka, ISSN 1427-9126, R. 26, Nr 4/2022, 79–84, DOI: 10.14313/PAR_246/79

Streszczenie: Artykuł przedstawia koncepcję budowy architektury niskoenergetycznego sterownika programowalnego opracowanego zgodnie z normą IEC 61131-3. Uniwersalność dotyczy swobody wyboru jednostki centralnej oraz możliwości łatwej wymiany algorytmu sterującego. Do proponowanego rozwiązania wybrana zostaje jedna z omówionych trzech metod opracowywania i dystrybucji oprogramowania. W ramach prac przygotowany został prototypowy sterownik w oparciu o elementy ewaluacyjne, z przeznaczeniem do pracy w środowisku rozproszonym. W artykule przedstawiono również porównanie wydajności energetycznej wybranych układów STM32 z kilku odmiennych serii.

Wprowadzenie

Komputerowe systemy sterowania zrewolucjonizowały nasz system funkcjonowania i wykonywania różnego rodzaju operacji, wspierając w wykonywaniu codziennych działań i automatyzując procesy produkcyjne. Programowalne sterowniki logiczne PLC zazwyczaj kojarzone są z zastosowaniem w przemyśle, gdzie ich głównym zadaniem jest sterowanie procesami. Przy bardzo mocnym uproszczeniu, wygenerowane sterowanie jest efektem zmiany wejść. Różnorodne czujniki dostarczają potrzebnych danych do poprawnego rozpoznania zachodzących procesów.

Niewielkie systemy sterowania, często mieszczące się w jednej szafie sterowniczej, mogą wykorzystywać do swojego działania dane pochodzące z rozproszonej sieci czujników. Budowa takich systemów wymaga nakładów finansowych przeznaczonych na moduły stosujące przemysłowe protokoły komunikacyjne. Podczas próby rozszerzenia potencjalnych granic wykorzystania sterowników PLC można napotkać na ograniczenia związane z obsługiwanymi technologiami, jak komunikacja bezprzewodowa lub wsparcie nowoczesnych rozwiązań transmisji danych. Brak na rynku dedykowanych rozwiązań lub ich koszt zmusza projektantów do łączenia sterowników PLC z zewnętrznymi, dedykowanymi systemami.

Naturalnym następstwem eksploatacji każdego systemu sterowania jest jego modyfikacja lub modernizacja. Języki normy IEC 61131-3 upraszczają i standaryzują wprowadzanie stosownych zmian. Z kolei wykorzystanie w systemie urządzeń spoza auto-

matyki przemysłowej, zamiast dedykowanych modułów może skutecznie uniemożliwić wprowadzenie modyfikacji dostosowanych do nowych wymogów.

W 1999 r. Kevin Ashoton zaprezentował termin Internet Rzeczy IoT (ang. Internet of Things), który przez wiele lat ewoluował, stale zwiększając popularność, a obecnie pozwolił zaistnieć 14,4 mld różnych urządzeń [1]. Zakres potencjału stosowania IoT jest bardzo szeroki, obejmuje przemysł (Industrial IoT), zarządzanie miastami (smart city), usługi zdrowotne, urządzenia gospodarstwa domowego (smart home) a nawet wykorzystany jest na urządzeniach noszonych (wearables).

Wydaje się, że można skutecznie doposażyć nowoczesne rozwiązania IoT w zasady określone w standardach automatyki, w szczególności w normie IEC 61131-3, opracowując hybrydę przemysłowych i przenaszalnych rozwiązań dedykowanych do szerokiego grona odbiorców. Dzięki takiemu zabiegowi, przez wykorzystanie wieloletniego doświadczenia branży automatyki, poprawiona zostanie spójność opracowywania systemów wykorzystujących do swojego działania zróżnicowane elementy.

Ważnym aspektem systemów Internetu Rzeczy jest zapotrzebowanie na energię. Producenci elektroniki systematycznie poprawiają wydajność energetyczną swoich urządzeń. Zasilanie bateryjne jest tu podstawowym sposobem dostarczenia energii do urządzenia. Podstawowym parametrem branym pod uwagę podczas wyboru konkretnego rozwiązania będzie interwał wymiany źródła zasilania. Sposobem na uniknięcie zbyt częstego serwisowania mogą być alternatywne źródła energii jak ogniwa fotowoltaiczne.

Rozproszony system sterowania wymaga rozwinięcia kwestii projektowania, dystrybucji oraz obsługi oprogramowania. Ustalenie odpowiednich zasad i poznanie możliwych ograniczeń jest konieczne do poprawnej pracy uniwersalnego systemu PLC z IoT.

Rys. 1. Struktura systemu rozproszonego monitorowania parametrów rzeki Fig. 1. Structure of a distributed monitoring system for river parameters

Zaprojektowanie systemu sterowania zaczyna się od ustalenia badanych zmiennych fizycznych wiążąc to z wymaganym sterowaniem. Ciekawym przykładem może być system monitorowania i reagowania dla hydrologii, badający zmiany jakości i poziomu wód np. w rzece. Zróżnicowane warunki oraz duże rozproszenie systemu wymagać będzie skonstruowania rozmaitych stacji badawczych. Dodatkowo, w planie takiego systemu należy przewidzieć rozszerzenie możliwości pomiarowych systemu oraz jego rozbudowę o kolejne stacje monitorująco-sterujące.

Przykładową strukturę takiego modelu zamieszczono na rysunku 1. Zróżnicowane stacje pracują w jednym, spójnym systemie. Wykorzystując komunikację krótkiego i dalekiego zasięgu możliwe jest zbudowanie sieci stacji monitorujących i sterujących. Liczba badanych parametrów może zostać rozbudowana ponad kilka przykładowych elementów przestawionych na rysunku. Urządzenia pozbawione możliwości stałego źródła zasilania wyposażone są w alternatywny systemu pozyskiwania i magazynowania energii. Tym samym stają się samowystar-

Rys. 2. Trzy sposoby opracowywania oprogramowania dla systemów w normie IEC 61131-3 Fig. 2. Three ways to develop software for systems in the IEC 61131-3 standard

czalnymi stacjami rozmieszczonymi np. w trudnym rozległym terenie. Urządzenie typu gateway umożliwia natomiast scalenie rozproszonego systemu i dostęp do rozwiązań chmurowych.

Realizacja powyższej koncepcji systemu monitorująco-sterującego w oparciu o typowe sterowniki PLC wygeneruje znaczący koszt pojedynczego punktu obserwacji i prawdopodobnie ograniczy możliwość znacznego zwielokrotnienia i zagęszczenia czujników. Wymóg stałego źródła zasilania dodatkowo zawęzi możliwość montażu stacji badawczych do niewielkiego obszaru. Dedykowane systemy monitorowania będą uzależniać projekt wyłącznie od kompatybilnych elementów, blokując innowacyjność i utrudniając rozszerzanie i uzależniając je od producenta.

Wychodząc na przekór pojawiającym się ograniczeniom, podczas projektowania systemu monitowania możliwe jest zastosowanie uniwersalnych rozwiązań, w którym część sterująca jest niezależna od konkretnej platformy sprzętowej i łatwo reprogramowalna. W takim podejściu uzyskamy idealne dopasowanie co do zastosowanych technologii, czujników, sterowań oraz źródła zasilania.

Przy projektowaniu rozbudowanych systemów sterowania zastosowanie zunifikowanego mechanizmu tworzenia oprogramowania i jego dystrybucji jest pożądaną cechą. W systemach sterowania standaryzacja języków programowania jest osiągana przede wszystkim dzięki normie IEC 61131-3. W narzędziach implementujących tę normę oprogramowanie opracowywane jest obecnie na trzy różne sposoby.

W pierwszym z nich, przedstawionym z lewej strony rysunku 2, programy IEC (na przykład w języku ST) kompilowane są do kodu natywnego platformy docelowej. Stosunkowo nieskomplikowane środowisko wykonawcze pozwala na efektywne wykonywanie wdrożonego oprogramowania. Podejście to stosowane jest przez dużych producentów, którzy produkują urządzenia w długich seriach oparte o zunifikowane komponenty sprzętowe. Jest to rozwiązanie dla określonego procesora, ponieważ zmiana platformy wymaga nowego kompilatora.

Drugie podejście, przedstawione w części środkowej rysunku 2 polega na przetłumaczeniu programów IEC na kod w języku C/C++, a następnie wygenerowaniu natywnego kodu binarnego za pomocą kompilatorów specyficznych dla każdej z platform [2-4]. Pierwszy krok umożliwia tworzenie kodu wieloplatformowego, jednak drugi etap utrudnia dystrybucję programów na różne platformy, gdyż niezbędne jest wykorzystanie wielu kompilatorów C/C++. Przygotowany kod binarny jest jednak dobrze dostosowany do danej platformy, co oznacza dobrą wydajność. Istnieje również trzecie podejście pokazane na rysunku 2 z prawej strony. Jego celem jest uniezależnienie dystrybuowanego kodu od platformy docelowej. Rozwiązanie opiera się na koncepcji maszyny wirtualnej [5, 6]. Wygenerowany przenaszalny wieloplatformowy kod jest interpretowany przez odpowiednie środowisko wykonawcze na platformie docelowej [IsaGraf 7, Straton 8]. Wspominane środowisko wykonawcze określane jest często jako maszyna wirtualna VM (ang. Virtual Machine), ponieważ emuluje działanie procesora definiowanego programowo [9]. Rozwiązanie to umożliwia łatwą wymianę oprogramowania w tracie pracy urządzenia oraz przenoszenie oprogramowania między zróżnicowanymi platformami. Ponadto wdrożenie nie wymaga dodatkowego kroku natywnej kompilacji. Wadą jest natomiast mniejsza wydajność wykonywania oprogramowania. Mimo to, podejście wykorzystujące VM jest interesujące dla małych i średnich przedsiębiorstw, które produkują urządzenia w krótkich seriach, wykorzystując przy tym różnorodne procesory i mikrokontrolery.

Rys. 3. Składowe oprogramowania sterownika PLC opartego na maszynie wirtualnej Fig. 3. Components of PLC software based on a virtual machine

W omawianej koncepcji sterownika programowalnego jako narzędzie do tworzenia oprogramowania zastosowano pakiet CPDev [10]. Maszyna wirtualna CPDev jest przenośna, co oznacza, że można dostosować do różnych platform sprzętowych i procesorowych [11]. W swojej idei oparta jest na architekturze harwardzkiej, a więc wykorzystuje do pracy dwa osobne obszary pamięci czyli kodu i danych (rys. 3). Pierwszy przechowuje interpretowany kod w postaci binarnej, drugi –wartości zmiennych prostych i złożonych (tablic, struktur). W zależności od potrzeb i sprzętu, maszyna wirtualna może korzystać z różnych metod dostępu do pamięci [12].

Pracujący sterownik PLC w oparciu o maszynę wirtualną wykonuje trzy fazy pracy (rys. 3):

Pre cycle: odczyt wartości zmiennych z wejść fizycznych i źródeł zewnętrznych;

VM task: przetwarzanie kodu maszynowego i interpretacja danych;

Post cycle: ustawianie wyjść na podstawie obliczonych wartości zmiennych, komunikacja, diagnostyka, testowanie itp.

Moduł przetwarzania instrukcji jest kluczowym elementem całej architektury. Zestaw instrukcji dla maszyny wirtualnej składa się z bezpośrednich odpowiedników normy IEC 61131-3, skoków, instrukcji kopiowania pamięci oraz wywołań podprogramów [11,13].

Przedstawiona na rys. 3 struktura zakłada, że sterownik wykonuje pojedyncze zadanie składające się z programów i innych jednostek organizacyjnych [14]. Aby uruchomić więcej zadań jednocześnie można utworzyć dodatkowe instancje maszyn wirtualnych. W przypadku procesora wielordzeniowego można to osiągnąć poprzez przypisanie każdej instancji maszyny wirtualnej do konkretnego rdzenia. W przypadku wielozadaniowego systemu operacyjnego, zadania VM wykonywane są jako wątki lub procesy [15].

4. Sterownik PLC Low Power

Konwencjonalny sterownik PLC nie zawiera systemów oszczędzania energii. Ze względu na charakterystykę jego pracy, w szczególności potrzebę utrzymania stałego czasu cyklu, część fazy Post cycle z rys. 3 pozostaje zwykle niewykorzystana. Z tego powodu, po wykonaniu programu wraz z niezbędnymi elementami komunikacji oraz diagnostyki, możliwe jest bezpieczne uśpienie urządzenia na czas oczekiwania na następny cykl. W zależności od interwału wykonywania cyklu zastosowanie takiego rozwiązania może przynieść znaczące efekty w obszarze zapotrzebowania na energię. Układy licznikowe będą odpowiedzialne za regularne wybudzanie urządzenia dla uzyskania stałego cyklu.

Poziomy oszczędzania energii, do których można wprowadzić dany układ elektroniczny są mocno zróżnicowane, pozwalając na dostosowanie ich głębokości do potrzeb. Do budowy prototypów rozważano m.in. mikrokontrolery serii STM32, NRF, ESP32. Przykładowo, w układzie STM32L476 można wyróżnić następujące tryby pracy [16]:

Run mode – normalny tryb pracy mikrokontrolera; Sleep – CPU zostaje zatrzymany, wszystkie peryferia zostają włączone i mogą wybudzić CPU, gdy wystąpi przerwanie lub zdarzenie;

Low-power run – zmniejszona częstotliwość procesora do 2 MHz, program może być wykonywany z pamięci SRAM lub FLASH, zasilanie procesora pochodzi z regulatora małej mocy, peryferia taktowane mogą być z HSI16;

Low-power sleep – włączenie tego trybu wymaga uprzedniego uruchomienia trybu Low-power run, zatrzymywany jest tylko zegar procesora, po wybudzeniu przez zdarzenie lub przerwanie system powraca do trybu Low-power run; Stop 0, Stop 1, Stop 2 – tryb zatrzymania osiągający najniższe zużycie energii przy zachowaniu zawartości pamięci SRAM i rejestrów. Większość zegarów zostaje zatrzymana, podtrzymywane są wyłącznie LSE i LSI; Różnica między poziomami zatrzymania, a więc i ilością możliwych działających peryferii mogących wybudzić układ ze stanu uśpienia; Stand by mode – tryb czuwania z którego wybudzenie może nastąpić po resecie za pomocą dedykowanego pinu lub watchdoga lub specjalnych konfigurowalnych zdarzeń od pinów WKUP oraz RTC. Pamięć zostaje utracona z wyjątkiem rejestrów w domenie kopii zapasowej; Shutdown – tryb wyłączenia, najniższy poziom zużycia energii, sposoby wybudzenia układu zbliżone do trybu Stand by mode.

Podstawowym wymogiem dla sterownika przemysłowego jest nieprzerwane i niezawodne działanie. Stąd wyłącznie niezagospodarowany czas może zostać wykorzystywany na zmniejszenie poboru energii urządzenia. Sterownik powinien być regularnie wybudzany – zgodnie z zadanym cyklem, za pomocą wewnętrznych liczników generujących przerwania. Dostępne tryby usypiania układu pozwalają na opracowanie dwóch odmiennych metod oszczędzania energii.

Pierwszym podstawowym sposobem jest usypianie układu do poziomu, w którym pamięć tymczasowa oraz rejestry są podtrzymywane. Dzięki takiemu zabiegowi urządzenie pracuje w sposób zbliżony do układów niewykorzystujących funkcji oszczędzania energii. Uzyskane rozwiązanie pozwala w bardzo prosty sposób zaimplementować tryb energooszczędny.

Drugie rozwiązanie polega na wykorzystaniu najbardziej radykalnych systemów zarządzania energią i zmniejszenie poboru prądu poprzez wyłączenie wszystkich zbędnych peryferii, w tym systemu potrzymania pamięci SRAM. Takie podejście pozwala na uzyskanie najniższych możliwych poziomów zapotrzebowania

Rys. 4. Prototypowy sterownik PLC oparty na płycie ewaluacyjnej Nulceo-64 wyposażonej w mikrokontroler STM32L476 i nakładkę PLC01A1

Fig. 4. Prototype PLC controller based on the Nucleo-64 evaluation board equipped with the STM32L476 microcontroller and the PLC01A1 module

na energię, ale pociąga za sobą konsekwencje w postaci utraty pamięci tymczasowej. Ze względu na potrzebę podtrzymania pamięci ulotnej w proponowanym sterowniku, możliwe jest wykonanie zrzutu pamięci ulotnej do alternatywnej nieulotnej, która przy wznowieniu pracy urządzenia zostanie przywrócona. Przy bardzo dużym okresie czasu uśpienia sterownika względem długości pojedynczego cyklu sterownika, tryb ten może przynieść bardzo wymierne efekty.

Prototyp sterownika PLC przedstawiony został na rysunku 4. Do budowy wykorzystana została płyta ewaluacyjna Nucelo-64 z mikrokontrolerem STM32L476. Za dopasowanie wejść i wyjść do standardu automatyki odpowiada płyta rozszerzeń PLC01A1. Zbudowany model posiada wbudowany programator i debuger w wersji ST-LINK/V2-1. Płyta ewaluacyjna umożliwia pomiar prądu wbudowanego mikrokontrolera oraz doprowadzenie zewnętrznego zasilania.

Do porównania sprawności energetycznej zgodnie z wytycznymi [17] wybrano serię mikrokontrolerów STM32 firmy STMicroelectronics. Każdy układ można scharakteryzować właściwościami takimi jak wykorzystana architektura, możliwa maksymalna częstotliwość taktowania, średni pobór prądu na MHz oraz wydajność obliczeniowa. W większości broszur informacyjnych mikrokontrolerów, szczególnie nakierowanych na zasilanie bateryjne, można znaleźć informacje o wydajności układu względem poboru prądu.

Producenci deklarują wydajność przy pomocy testu CoreMark, który w odróżnieniu od Dhrystone lepiej pasuje do systemów wbudowanych. Specyficzny sposób działania oprogramowania wykorzystuje uproszczony benchmark do określenia maksymalnej wydajności maszyny wirtualnej. Dlatego też, do porównania zużycia energii średni pobór prądu w trybie pracy (RUN) maszyny jest mierzony tylko przy maksymalnej częstotliwości chipa, a wszystkie zewnętrzne peryferia są wyłączone. Sygnał zegarowy do procesora podawany jest z HSE z wykorzystaniem

Tab 1. Porównanie układów pod względem maksymalnej wydajności, energochłonności oraz wydajności w proponowanej aplikacji Tab 1. Comparison of systems in terms of maximum efficiency, energy consumption and efficiency in the proposed application

mikrokontroler max częstotliwość (MHz)

deklarowana wydajność (CoreMark)

konsumpcja prądu (μA/MHz) czas cyklu (μs) wynik (μA/cykl)

STM32F07248106270241 63065,23

STM32F30372245380144 51154,91

STM32F446180608178122 92221,88 STM32L47680273,5128,75123 01215,82 STM32F746216108250082 46941,23

pętli PLL a oprogramowanie jest ładowane z pamięci FLASH. Wyniki czasu pojedynczego cyklu są średnią przygotowanych dla trzech metod dostępu do pamięci przez maszynę wirtualną.

Tabela 1 obrazuje mocne zróżnicowanie między seriami układów. Skupiając się na różnicach między zastosowanymi przykładami architektury, chipy z serii Cortex-M4 mają najlepszą wydajność energetyczną. Najniższa seria Cortex-M0 jest najmniej wydajna spośród zestawienia. W razie zapotrzebowania na największą możliwą wydajność spośród gamy tego producenta, najlepiej sprawdzi się najwyższa seria 7 w wersji zwykłej F lub usprawnionej H.

Przedstawione wyniki zostały uzyskane dla programu sterującego wykonywanego przez maszynę wirtualną CPDev. Maszyna interpretuje instrukcje w przenośnym kodzie binarnym i wykonuje je jako bloki kodu maszynowego dla docelowego procesora. Każda instrukcja VM wymaga więc kilku instrukcji procesora. Dodatkowy narzut czasowy jest wynikiem ochrony obszarów pamięci danych używanych przez zmienne, co zabezpiecza przed poważnymi awariami w przypadku wystąpienia błędu programowania. Zwiększona złożoność obliczeniowa jest kompensowana przez przenośność i kompatybilność kodu pomiędzy różnymi platformami.

to utrzymanie jednolitej struktury oprogramowania i dystrybucji w niejednorodnym pod względem sprzętowym systemie rozproszonym. Zastosowaną w projekcie maszynę wirtualną można umieścić na dowolnej platformie, od zaprezentowanych mikrokontrolerów przez klasyczne systemy operacyjne, jak również rozwiązania chmurowe.

Projekt finansowany w ramach programu Ministra Edukacji i Nauki pod nazwą „Regionalna Inicjatywa Doskonałości” w latach 2019–2023 nr projektu 027/RID/2018/19 kwota finansowania 11 999 900 zł.

1. Hasan M., State of IoT 2022: Number of connected IoT devices growing 18% to 14.4 billion globally https://iot-analytics.com/number-connected-iot-devices.

2. Beremiz Integrated Development Environment, www.beremiz.org.

3. Tisserant E., Bessard L., Sousa M., An Open Source IEC 61131-3 Integrated Development Environment. [In:] IEEE International Conference on Industrial Informatics, 2007, 183–187, DOI: 10.1109/INDIN.2007.4384753.

4. GEB Automation. GEB Automation IDE Guide. www.gebautomation.org.

W ramach prac opracowany został rozwojowy energooszczędny sterownik PLC oparty o mikrokontroler STM32 z serii L o niskim poborze prądu (Ultra Low Power) firmy STMicroelectronics. Wykorzystanie układu o nazwie kodowej STM32L476 jest kompromisem między wydajnością i niskim poborem prądu w badanym zestawieniu. Podsumowująca kolumna poboru prądu względem czasu cyklu (Tab. 1) prowadzi do wniosku, iż w zastosowaniu energooszczędnym układ tego typu dobrze sprawdzi się w roli elementu wykonawczego. Mniejsze zapotrzebowanie na energię można będzie osiągnąć przede wszystkim w systemach pracujących z długim okresem cyklu oraz wzbudzanych do działania zewnętrznymi zdarzeniami. W zastosowaniach, w których można spotkać tego rodzaju pracę oprogramowania sterującego zasilanie jest często zapewniane przez ogniwa bateryjne lub akumulatorowe, niekiedy wspomagane przy pomocy ogniw fotowoltaicznych. Proponowane rozwiązanie może więc usprawnić funkcjonowanie rozwiązań IoT, a szczególnie część związaną z rozproszonymi urządzeniami sterującymi i monitorującymi.

Zaproponowana architektura niskoenergetycznego sterownika logicznego uwzględnia korzyści płynące ze standaryzacji oprogramowania. Dzięki wykorzystaniu maszyny wirtualnej możliwe jest zastosowanie pojedynczego zestawu narzędzi (kompilatora) obsługującego różne mikrokontrolery. Ułatwia

5. Cavalieri S., Puglisi G., Scroppo M.S., Galvagno L., Moving IEC 61131-3 applications to a computing frame-work based on CLR virtual machine. [In:] Proceedings of the IEEE 21st International Conference on Emerging Technolo-gies and Factory Automation, Berlin, Germany, 6–9 September 2016; 1–8.

6. Lee Y., Jeong J., Son Y., Design and implementation of the secure compiler and virtual machine for developing se-cure IoT services. “Future Generation Computer Systems”, Vol. 76, 2017, 350–357, DOI: 10.1016/j.future.2016.03.014.

7. Rockwell Automation. ISaGRAFWorkbench. www.isagraf.com.

8. COPA-DATA France. STRATON. www.straton-plc.com.

9. Zhang M., Lu Y., Xia T., The design and implementation of virtual machine system in embedded SoftPLC system [In:] Proceedings of the International Conference on Computer Science and Applications, Trento, Italy, 6–8 June 2013; 775–778, DOI: 10.1109/CSA.2013.185.

10. Rzońca D., Sadolewski J., Stec A., Świder Z., Trybus B., Trybus L., Developing a multiplatform control environment, “Journal of Automation Mobile Robotics and Intelligent Systems”, Vol. 13, No. 4, 2019, 73–84, DOI: 10.14313/JAMRIS/4-2019/40.

11. Trybus B., Development and Implementation of IEC 61131-3 Virtual Machine. “Theoretical and Applied Informatics” Vol. 23, No. 1, 2011, 21–35.

12. Hubacz M., Sadolewski J., Trybus B., Obsługa typów danych normy PN-EN 61131-3 w architekturze ARM z ograniczeniami dostępu do pamięci. „Pomiary Automatyka Robotyka”, R. 26, Nr 1, 2022, 23–31, DOI: 10.14313/PAR_243/23..

13. Sadolewski J., Trybus B., Compiler and virtual machine of a multiplatform control environment. “Bulletin of the Polish Academy of Sciences. Technical Sciences”, Vol. 70, No. 2, 2022, DOI: 10.24425/bpasts.2022.140554

14. IEC 611313:2013; Programmable Controllers—Part 3: Programming Languages. European Committee for Electrotechnical Standardization: Brussels, Belgium, 2013.

15. Wang K.C., Embedded Real-Time Operating Systems. Embedded and Real-Time Operating Systems; Springer: Cham, Germany, 2017, 401–475, ISBN 978-3-319-51517-5.

16. Nota katalogowa STM32L476. www.st.com/resource/en/ datasheet/stm32l476rg.pdf.

17. Wu H., Chen C., Weng K., An Energy-EfficientStrategyfor Microcontrollers. “Applied Sciences”, Vol. 11, No. 6, 2021, DOI: 10.3390/app11062581.

Abstract: The article presents the concept of building a low-energy programmable controller architecture developed in accord-ance with the IEC 61131-3 standard. The universality concerns the freedom of choice of the central unit and the possibility of easy replacement of the control algorithm. One of the three methods of software development and distribution is selected for the proposed solution. As part of the work, a prototype controller was prepared based on evaluation elements, intended to work in a distributed environment. The article also presents a comparison of the energy efficiency of selected STM32 systems from several different series.

Keywords

ORCID: 0000-0002-2748-11454

ORCID: 0000-0001-9469-2754

ORCID: 0000-0002-4588-3973

W artykule przedstawiono możliwości poprawy parametrów czasowych komunikacji między sterownikiem przemysłowym PLC a panelem operatorskim HMI. Jak pokazano, niekiedy odpowiednia konfiguracja zadań komunikacyjnych, zmniejszająca liczbę poleceń przesyłanych w protokole Modbus kosztem konieczności transmisji dodatkowych danych, może prowadzić do minimalizacji łącznego czasu cyklu komunikacyjnego. Przedstawione rozwiązanie zostało zaimplementowane w pakiecie inżynierskim CPDev.

Wprowadzenie

W rozproszonych systemach automatyki często zachodzi konieczność wymiany danych między sterownikiem przemysłowym PLC (ang. Programmable Logic Controller) lub PAC (ang. Programmable Automation Controller) a panelem operatorskim HMI (ang. Human-Machine Interface). Artykuł dotyczy wybranych aspektów takiej komunikacji, zwłaszcza występujących w pakiecie inżynierskim CPDev podczas komunikacji PLC z HMI za pomocą protokołu Modbus. Można go zasadniczo traktować jako kontynuację pracy [1], gdzie skupiono się na analizie sytuacji, gdy panel HMI jest urządzeniem nadrzędnym cyklicznie odpytującym sterownik PLC. Tu przedstawiono odmienne podejście, równie często występujące w praktyce inżynierskiej, gdy to HMI jest urządzeniem podrzędnym, do którego PLC cyklicznie zapisuje dane.

W kolejnym rozdziale zamieszczono krótki przegląd literatury związanej z problematyką poruszaną w artykule. Szczególną uwagę poświecono zagadnieniom związanym ze środowiskiem CPDev, normą IEC 61131-3 i komunikacją z panelami HMI. Trzeci rozdział przedstawia proponowane podejście, a także prostą analizę pokazującą, kiedy grupowanie zmiennych prowadzi do skrócenia cyklu komunikacyjnego. Ostatni rozdział zawiera zwięzłe podsumowanie.

Pakiet inżynierski CPDev (ang. Control Program Developer) jest opracowanym w Katedrze Informatyki i Automatyki Politechniki Rzeszowskiej środowiskiem pozwalającym na programowanie sterowników przemysłowych w językach normy IEC 61131-3 [17], przyjętej w Polsce jako PN-EN 61131-3. Prace nad pakietem CPDev rozpoczęły się kilkanaście lat temu [2], środowisko jest ciągle rozwijane i rozbudowywane. Przebieg prac nad jego implementacją, jak też aktualny opis środowiska CPDev można znaleźć m.in. w [3, 4]. Obecnie CPDev jest wdrożony przez kilku producentów systemów automatyki, czterech polskich i dwóch zagranicznych (Hiszpania, Holandia).

Norma IEC 61131-3 [17] definiuje pięć specjalistycznych, dziedzinowych języków programowania, przeznaczonych dla sterowników PLC i PAC. Są to języki: −ST – Structured Text, −IL – Instruction List, −FBD – Function Block Diagram, −LD – Ladder Diagram, −SFC – Sequential Function Chart

Dobry opis języków normy można znaleźć w książce [5]. Wszystkie z wymienionych języków wspierane są przez środowisko CPDev.

Pakiet CPDev został zaprojektowany w taki sposób, by ułatwić jego implementację przez różnych producentów PLC, niezależnie od zastosowanej platformy sprzętowej. Jest to osiągane dzięki odseparowaniu środowiska graficznego od oprogramowania sterownika. Programy sterowania w językach normy są kompilowane do opracowanego na potrzeby CPDev kodu pośredniego VMASM (ang. Virtual Machine Assembler), a następnie wykonywane przez specjalizowany interpreter wchodzący w skład oprogramowania wbudowanego (ang. firmware) PLC, zwany maszyną wirtualną [6]. Kod źródłowy maszyny wirtualnej został przygotowany w języku C, dzięki czemu może być łatwo zaimplementowany na praktycznie dowolnym mikroprocesorze.

Istniejące wdrożenia obejmują zarówno sterowniki PLC bazujące na niewielkich ośmiobitowych mikrokontrolerach (np. AVR), jak też większe (ARM), a także rozwiązania soft-PLC pracujące na komputerach z architekturą x86.

Komunikacja w rozproszonych systemach automatyki zazwyczaj wykorzystuje dedykowane sieci przemysłowe [7]. Są to sieci polowe [8], a w nowszych rozwiązaniach coraz częściej Ethernet [9]. W przypadku sieci polowych stosowane są rozwiązania opisane w normie IEC 61158 [18]. Można także dostrzec tendencję do coraz szerszego wykorzystywania w komunikacji przemysłowej rozwiązań heterogenicznych, integrujących różne rodzaje sieci [10], zwłaszcza w dużych systemach. Niewielkie rozproszone systemy automatyki często jednak nadal bazują na szeregowej magistrali komunikacyjnej (np. RS-485) z protokołem Profibus lub Modbus. Zwłaszcza otwarty protokół Modbus jest bardzo popularny wśród producentów niewielkich aparatowych urządzeń automatyki.

Panele operatorskie HMI są często stosowane m.in. do wizualizacji danych procesowych, ustawiania parametrów [11, 12]. Środowisko inżynierskie CPDev również pozwala na projektowanie prostych ekranów graficznych dla panelu HMI za pomocą narzędzia CPVis [13] wchodzącego w skład CPDev. Jego funkcjonalność w tym zakresie opisywano także w [14]. Przykładowy ekran procesowy HMI, przygotowany za pomocą CPVis dla autopilota okrętowego [15], pokazano na rysunku 1.

Sterownik PLC wymienia dane z panelem HMI za pomocą magistrali komunikacyjnej, zazwyczaj RS-485, a w nowszych rozwiązaniach Ethernet. W przypadku sieci polowych często stosowane są protokoły takie, jak np. Profibus czy Modbus. Na potrzeby dalszych rozważań przyjmijmy komunikację za pomocą bardzo popularnego protokołu Modbus RTU. Jest to protokół oparty na paradygmacie master-slave, co oznacza, że jedno z urządzeń jest urządzeniem nadrzędnym (ang. master) inicjującym transmisję, a pozostałe są urządzeniami podrzędnymi (ang. slave) odpowiadającymi na polecenia. Warto zauważyć, że w komunikacji paneli HMI ze sterownikiem PLC stosuje się zarówno takie rozwiązania, gdzie HMI jest urządzeniem nadrzędnym cyklicznie odpytującym PLC o wartości wizualizowanych zmiennych, jak też takie, gdzie PLC pełni rolę mastera przesyłając do HMI aktualne wartości zmiennych po każdym cyklu obliczeń. Pierwszy z przypadków został przeanalizowany w [1], tu zajmiemy się tylko drugim podejściem.

Protokół Modbus określa szereg funkcji służących do wymiany danych. Najpopularniejsze z nich to: −FC1 – odczyt zmiennych binarnych, −FC2 – odczyt wejść binarnych, −FC3 – odczyt rejestrów, −FC4 – odczyt rejestrów wejściowych, −FC5 – zapis pojedynczej zmiennej binarnej, −FC6 – zapis pojedynczego rejestru, −FC15 – zapis wielu zmiennych binarnych, −FC16 – zapis wielu rejestrów.

Zakładając, że sterownik PLC jako urządzenie nadrzędne zapisuje do panelu HMI wielobitowe zmienne, wykorzystywane będą głownie polecenia FC6 i FC16. Funkcja FC6 pozwala na zapis pojedynczego szesnastobitowego rejestru, natomiast polecenie FC16 zapisuje wiele następujących po sobie rejestrów. Ich ramki przedstawiono odpowiednio na rysunkach 2 i 3.

Rys. 2. Ramka polecenia FC6 Modbus RTU Fig. 2. Frame of Modbus RTU FC6 function

W module CPVis zastosowano podobną koncepcję z interpreterem przetwarzającym kod pośredni, tym razem dotyczącym grafiki. CPVis składa się z graficznego edytora uruchamianego na PC i środowiska wykonawczego (interpretera) uruchamianego na docelowym panelu HMI. Ekrany procesowe są przygotowywane w edytorze CPVis z elementów bibliotecznych, prostych (jak np. linia, prostokąt) oraz złożonych (np. wykres). Poszczególne parametry tych elementów mogą być stałe lub uzależnione od wartości wizualizowanych zmiennych, np. wysokość prostokąta może odzwierciedlać poziom cieczy w zbiorniku, jego kolor temperaturę itp. Interpreter CPVis na panelu HMI cyklicznie generuje bieżący obraz na podstawie aktualnych wartości wizualizowanych parametrów. Proces ten szczegółowo omówiono w [16].

Odpowiedź na funkcję FC6 przesyłana przez urządzenie podrzędne, zakładając poprawne wykonanie zapisu, jest kopią przesłanego polecenia. Ramka odpowiedzi na funkcję FC16 zawiera liczbę zapisanych rejestrów, przedstawiono ją na rysunku 4. Można zauważyć, że długość ramki odpowiedzi w obu przypadkach (FC6 i FC16) jest identyczna i wynosi 8 bajtów. Rozmiar ramki polecenia FC6 również wynosi 8 bajtów, natomiast długość ramki funkcji FC16 jest zmienna i zależy od liczby zapisywanych rejestrów. Oczywiste jest, że w przypadku, gdy chcemy zapisać tylko jeden rejestr, to użycie dedykowanego polecenia FC6 pozwoli na przesłanie krótszego komunikatu, a w onsekwencji na skrócenie czasu transmisji w porównaniu do bardziej uniwersalnego, ale dłuższego FC16. Z drugiej strony, jeżeli zachodzi konieczność zapisu dwóch lub większej liczby kolejnych rejestrów, to szybsze będzie użycie jednego wywołania FC16 niż kilku FC6, zapisując rejestry pojedynczo. Może się jednak zdarzyć, że rejestry, które chcemy zapisać w jednej transakcji komunikacyjnej nie następują bezpośrednio po sobie. Oczywiście najwygodniej byłoby, aby wszystkim zmiennym wizualizowanym na HMI przydzielić kolejne adresy, np. za pomocą modyfikatora AT w języku ST. Niestety nie zawsze jest to możliwe, gdyż te same zmienne mogą być stosowane na kilku ekranach procesowych. Mogą być także elementami większych zmiennych złożonych (tablic,

Rys. 1. Ekran HMI autopilota okrętowego opracowany w CPVis Fig. 1. HMI screen of ship autopilot developed in CPVis

Adres slave 1B Kod funkcji 1B (0×10)

Adres początkowy 2B Liczba rejestrów 2B Liczba bajtów 1B Dane n * 2B CRC 2B

Rys. 3. Ramka polecenia FC16 Modbus RTU

Fig. 3. Frame of Modbus RTU FC16 function

Adres slave 1B Kod funkcji 1B (0×10) Adres początkowy 2B Liczba rejestrów 2B CRC 2B

Rys. 4. Ramka odpowiedzi FC16 Modbus RTU

Fig. 4. Frame of reply to Modbus RTU FC16 function

struktur), co narzuca ich odpowiednie rozmieszczenie w pamięci sterownika. W naturalny sposób pojawia się pytanie, czy w pewnych wypadkach nie byłoby korzystne przesłanie także dodatkowych zmiennych, poza wymaganymi, tylko po to, by użyć pojedynczego polecenia FC16 zamiast kilku FC6.

Rozważmy sytuację, gdy potrzebujemy przesłać dwie szesnastobitowe zmienne (dwa rejestry) rozdzielone w pamięci sterownika przez k innych rejestrów, przeanalizujmy dwa sposoby by to osiągnąć.

Przyjmijmy następujące oznaczenia: tb – czas transmisji jednego znaku (zależny od ustalonej prędkości łącza komunikacyjnego), t m – czas potrzebny na przygotowanie polecenia przez urządzenie nadrzędne (master), t s – czas potrzebny na przygotowanie odpowiedzi przez urządzenie podrzędne (slave), tcyclei – łączny czas cyklu komunikacyjnego w i-tym przypadku.

Pierwszy sposób wymaga użycia dwóch osobnych poleceń FC6 aby zapisać rejestry pojedynczo. Po przygotowaniu pierwszego polecenia przez urządzenie nadrzędne (co trwa t m) rozpoczyna się transmisja ramki. Ramka FC6 liczy 8 bajtów, a więc czas potrzebny na jej przesłanie to 8 * tb. Protokół Modbus RTU definiuje detekcję końca ramki jako wykrycie ciszy na magistrali trwającą 3,5 * tb, dopiero więc po tym czasie urządzenie podrzędne zacznie przetwarzać polecenie i przygotowywać odpowiedź. Po czasie t s rozpocznie się transmisja odpowiedzi trwająca 8 * tb, a następnie cisza przez 3,5 * tb. Po zakończeniu transmisji pierwszego rejestru w podobny sposób zostanie przesłany kolejny, finalnie otrzymujemy więc:

Drugi sposób zakłada transmisję za pomocą jednego polecenia FC16 dwóch pożądanych rejestrów i k nadmiarowych rejestrów, leżących między nimi. Oznacza to, że ramka polecenia FC16 będzie mieć rozmiar 13 + 2k bajtów. Oczywiście jest to możliwe dla 121 k ≤ z uwagi na ograniczenie długości całej ramki Modbus do 255 bajtów. Finalnie uzyskujemy:

Obliczmy różnicę 12 . ttcyclecycle Jeżeli jest ona dodatnia, to znaczy, że korzystniejszy jest przypadek drugi, jeżeli ujemna – pierwszy.

() 12 182 cyclecyclebms ttkttt −=−++

Łatwo zauważyć, że dla 9 k ≤ optymalne będzie wykorzystanie pojedynczego polecenia FC16, niezależnie od wartości czasów tb, t m, t s > 0. Osiągane parametry czasowe są lepsze, mimo konieczności przesłania nadmiarowych danych (dodatkowych rejestrów). Dla 10 k ≥ wybór optymalnego sposobu komunikacji zależy od konkretnych wartości tb, t m i t s. Kontynuujmy analizę dla przykładowych wartości tych parametrów. Czas transmisji jednego znaku tb zależy od ustalonej prędkości łącza komunikacyjnego. Przykładowo dla transmisji z prędkością 9600 bps w formacie 8N1 (osiem bitów danych, brak kontroli parzystości, jeden bit stopu) tb wynosi 0,9375 ms, a dla transmisji z prędkością 115 200 bps w formacie 8N1 tb = 78,125 μs. Można zauważyć, że dla wyższych prędkości transmisji dodatkowy narzut czasowy potrzebny na przesłanie nadmiarowych rejestrów będzie stosunkowo niewielki. Czasy tm, ts są wielokrotnie wyższe, rzędu kilku lub kilkunastu milisekund. Przyjmijmy przykładowo t m = t s = 10 ms. Obliczoną rożnicę 12 ttcyclecycle dla dwóch prędkości transmisji pokazano na wykresie (Rys. 5).

Rys. 5. Różnica tcycle1 – tcycle2 dla dwóch prędkości transmisji

Fig. 5. Difference tcycle1 – tcycle2 for two baudrates

Rys. 6. Różnica tcycle1 – tcycle2 dla prędkości 115 200 bps w zależności od t m + t s i k Fig. 6. Difference tcycle1 – tcycle2 for 115 200 bps baudrate, depending on t m + t s and k

Jak widać, dla przyjętych t m i t s przy prędkości 115 200 bps nawet dla bardzo dużych wartości k, możliwych do obsłużenia pojedynczą ramką Modbus, korzystniejsza będzie transmisja zgrupowanych zmiennych jednym poleceniem FC16, wraz z dodatkowymi rejestrami. Jeśli używana jest prędkość transmisji 9600 bps to już przy k = 20 lepiej będzie transmitować rejestry pojedynczo, osobnymi poleceniami FC6.

Zmiana t m i t s również będzie wpływać na wybór korzystniejszego sposobu transmisji, odpowiednio przesuwając próg k, dla którego grupowanie rejestrów jest opłacalne. Można potraktować sumę t m +t s jako jedną zmienną, k jako drugą i rozważać różnicę 12 ttcyclecycle jako funkcję tych dwóch zmiennych przy ustalonej prędkości łącza. Odpowiedni wykres dla prędkości 115 200 bps przedstawiono na rysunku 6. Odcieniami czerwonego oznaczono zakres, w którym lepsze jest użycie funkcji FC16, a niebieskiego – FC6, na biało wynikowe 12 ttcyclecycle w pobliżu zera.

4. Podsumowanie

Zapis danych ze sterownika PLC do panelu operatorskiego HMI niejednokrotnie można zrealizować na kilka sposobów, odpowiednio grupując zmienne i wykorzystując różne polecenia Modbus. W artykule przeanalizowano przypadek, gdy sterownik PLC jest urządzeniem nadrzędnym, a zapis może przebiegać z użyciem funkcji Modbus FC6 lub FC16. Jak pokazano, niekiedy korzystne może być przesyłanie dodatkowych rejestrów, poza wymaganymi. Mimo transmisji nadmiarowych danych, zmniejszenie liczby komunikatów przesyłanych w ramach jednego cyklu komunikacyjnego, może prowadzić do poprawy osiąganych parametrów czasowych.

Projekt finansowany w ramach programu Ministra Edukacji i Nauki pod nazwą „Regionalna Inicjatywa Doskonałości” w latach 2019–2023, nr projektu 027/RID/2018/19, kwota finansowania 11 999 900 zł.

1. Rzońca D., Poprawa wydajności komunikacji sterownika przemysłowego z panelem operator skim HMI w środowisku inżynierskim CPDev, „Pomiary Automatyka Robotyka”, Vol. 24, No. 1, 2020, 35–40, DOI: 10.14313/PAR_235/35.

2. Rzońca D., Sadolewski J., Stec A., Świder Z., Trybus B., Trybus L., Mini-DCS system programming in IEC 61131-3 structured text, “Journal of Automation, Mobile Robotics and Intelligent Systems”, Vol. 2, No. 3, 2008, 48–54.

3. Rzońca D., Sadolewski J., Stec A., Świder Z., Trybus B., Trybus L., Implementacja środowiska inżynierskiego na przykładzie pakietu CPDev, „Pomiary Automatyka Robotyka”, Vol. 24, No. 1, 2020, 21–28, DOI: 10.14313/PAR_235/21.

4. Rzońca D., Sadolewski J., Stec A., Świder Z., Trybus B., Trybus L., Developing a Multiplatform Control Environment, “Journal of Automation, Mobile Robotics and Intelligent Systems”, Vol. 13, 2019, 73–84, DOI: 10.14313/JAMRIS/4-2019/40.

5. Kasprzyk J., Programowanie sterowników przemysłowych Wydawnictwa Naukowo-Techniczne, 2006.

6. Trybus B., Development and Implementation of IEC 61131-3 Virtual Machine, “Theoretical and Applied Informatics”, Vol. 23, No. 1, 2011, 21–35.

7. Silva M., Pereira F., Soares F., Leão C.P., Machado J., Carvalho V., An Overview of Industrial Communication Networks, [In:] New Trends in Mechanism and Machine Science (Flores P., Viadero F., eds.), (Cham), 933–940, Springer International Publishing, 2015, DOI: 10.1007/978-3-319-09411-3_97.

8. Thomesse J., Fieldbus Technology in Industrial Automation, “Proceedings of the IEEE”, Vol. 93, No. 6, 2005, 1073–1101, DOI: 10.1109/JPROC.2005.849724.

10. Scanzio S., Wisniewski L., Gaj P., Heterogeneous and dependable networks in industry – A survey, “Computers in Industry”, Vol. 125, 2021, DOI: 10.1016/j.compind.2020.103388.

11. Fiset J.-Y., Human-Machine Interface Design for Process Control Applications. Instrumentation, Systems and Automation Society, 2009.

12. Zhang P., Human–machine interfaces, [In:] Advanced Industrial Control Technology (Zhang P., ed.), 2010, 527–555, Oxford: William Andrew Publishing.

13. Jamro M., Trybus B., Configurable Operator Interface for CPDev Environment, “Pomiary Automatyka Robotyka”, Vol. 17, No. 2, 2013, 426–431.

14. Jamro M. Trybus B., IEC 61131-3 programmable human machine interfaces for control devices, [In:] 6th International Conference on Human System Interactions (HSI), 2013, 48–55, DOI: 10.1109/HSI.2013.6577801.

15. Rzońca D., Sadolewski J., Stec A., Świder Z., Trybus B., Trybus L., Ship Autopilot Software – A Case Study,

[In:] Advanced, Contemporary Control (Bartoszewicz A., Kabziński J., Kacprzyk J., eds.), (Cham), 2020, 1499–1506, Springer International Publishing, DOI: 10.1007/978-3-030-50936-1_124.

16. Rzońca D., Stec A., Trybus B., Control Program Development in CPDev Using SFC Language, HMI and Runtime Environment, [In:] Automation 2018 (Szewczyk R., Zieliński C., Kaliczyńska M., eds.), (Cham), 2018, 223–232, Springer International Publishing, DOI: 10.1007/978-3-319-77179-3_21.

17. IEC, “IEC 61131-3 – Programmable controllers – Part 3: Programming languages”, 2003.

18. IEC, “IEC 61158 – Industrial Communication Networks –Fieldbus Specifications”, 2007.

The paper presents the possibilities of improving the time parameters of communication between the industrial PLC and the HMI operator panel. As shown, sometimes the appropriate configuration of communication tasks, reducing the number of commands sent in the Modbus protocol at the expense of the necessity to transmit additional data, may lead to the minimization of the total communication cycle time. The presented solution has been implemented in the CPDev engineering environment.

Keywords

ORCID: 0000-0001-5724-0978

Marcin Bednarek

Pomiary Automatyka Robotyka, ISSN 1427-9126, R. 26, Nr 4/2022, 91–98, DOI: 10.14313/PAR_246/91

Streszczenie: W artykule opisano wybrane fragmenty procesu diagnozowania komunikacji między stacją procesową i operatorską, a także między stacjami procesowymi minisystemu rozproszonego, zbudowanego na bazie modułowego sterownika przemysłowego AC800F. W wyniku przeprowadzonych eksperymentów uzyskano informacje dotyczące sposobu transmisji i położenia wartości zmiennych procesowych w przesyłanych komunikatach. Informacje te można wykorzystać do podjęcia decyzji dotyczących dodatkowych zabezpieczeń przesyłu lub skomunikowania stacji systemu z rozszerzającymi zasobami użytkownika.

1. Wprowadzenie

W skład rozproszonych systemów sterowania DCS (ang. Distributed Control System) wchodzi kilka rodzajów stacji [1, 2]. Są to głównie: stacje procesowe PS (ang. Process Station) – sterowniki przemysłowe odpowiedzialne za realizację programu sterowania procesem przemysłowym; stacje operatorskie OS (ang. Operator Station) – pełnią rolę systemów wizualizacji, oddziaływania operatorskiego oraz obsługi alarmów; −stacje inżynierskie ES (ang. Engineering Station) – zwykle komputery przenośne, służące do konfiguracji pozostałych stacji systemu, uruchamiania i diagnozowania działania systemu oraz komunikacji [3].

W jednym z wariantów (Rys. 1), stacje systemu mogą być połączone siecią przemysłową bazującą na architekturze magistralowej [4]. Dane przesyłane magistralą trafiają do wszystkich podłączonych urządzeń. Ze względu na zasadniczą cechę sieci przemysłowej, którą powinna się charakteryzować, czyli determinizm czasowy dostarczania wiadomości – zastosowany protokół komunikacyjny powinien wprowadzać odpowiedni mechanizm dostępu do łącza. Powinien on sterować w odpowiedni sposób interfejsami nadawczymi stacji systemu zapobiegając ewentualnym kolizjom. Typowymi przedstawicielami tego rodzaju sieci są Modbus [5, 6] oraz Profibus [7, 8]. W każdym z wymienionych standardów stosowany jest mechanizm

odpytywania (ang. polling) urządzeń podrzędnych przez nadrzędne (tzw. master-slave). Dodatkowo Profibus oferuje możliwość korzystania z wielu masterów, dlatego zastosowano w nim mechanizm wymiany żetonu (ang. token). Tylko urządzenie aktualnie wyposażone w token może nadawać. W obydwu standardach doskonale znane są pola danych komunikatów i miejsca przesyłu wartości zmiennych w ramce. Diagnozowanie komunikacji w tym wariancie nie wymaga dodatkowych zabiegów, wystarczy bowiem zainstalowanie, w jednej ze stacji, oprogramowania monitorującego bezproblemowo wszystkie

Rys. 1. System wykorzystujący magistralową sieć polową Fig. 1. System using a fieldbus network

komunikaty wysyłane na magistralę. Chcąc rozbudować system o nowe elementy wystarczy oprogramować interfejs komunikacyjny zgodnie z podanymi standardami [5–8].

Innym sposobem połączenia urządzeń rozproszonego systemu sterowania jest wykorzystanie struktury gwiaździstej (Rys. 2) i standardu Ethernet [9, 10]. Elementy systemu połączone są za pomocą przełącznika sieciowego [11]. Do przełącznika podłączona jest także diagnozująca stacja inżynierska. W celu poprawnego diagnozowania komunikacji, oprócz zainstalowania odpowiedniego oprogramowania sniffera umożliwiającego przechwyt danych (co wystarczyło w przypadku z Rys. 1), należy skierować do niego „kopię” ruchu sieciowego. Jednym z rozwiązań jest odpowiednie ustawienie przełącznika, stosując np. port lustrzany [11, 12], na który dodatkowo jest przesyłany cały ruch sieciowy pomiędzy diagnozowanymi stacjami. Stację diagnozującą podłącza się wtedy do przygotowanego w ten sposób portu przełącznika. Takie połączenie występuje w systemie rozpatrywanym w dalszej części artykułu. Istnieją dwie tendencje w realizacji komunikacji między elementami systemu. Jedną z nich jest wykorzystanie standardowych rozwiązań bazujących na sieci Ethernet. Należy wspomnieć tu o najbardziej popularnych „następcach” Modbus i Profibus, czyli Modbus TCP [13, 14] lub też Profinet [15, 23, 24]. W tym przypadku również znana jest budowa pola danych pakietu TCP lub datagramu UDP [16]. Jednak niektórzy producenci decydują się na zastosowane do wymiany danych między stacją procesową, operatorską i inżynierską własnych, zamkniętych, nieudokumentowanych protokołów komunikacyjnych [25].

Diagnozowanie nieudokumentowanych, firmowych protokołów przeprowadza się na zasadzie badania „czarnej skrzynki” [17]. Oznacza to, że podczas badania dysponuje się jedynie znajomością wartości danych wysyłanych i odbieranych. Natomiast nie są znane informacje dotyczące m.in. rozmieszczenia zmiennych w polu danych komunikatu lub sposobu ich przesyłania. Strukturę pola danych można poznać w wyniku diagnozowania komunikacji. Ze względu na to, że diagnozowanie dotyczy firmowego, zamkniętego protokołu [25], nie został on dotychczas przedstawiony w ogólnodostępnych źródłach. Istnieją wprawdzie informacje dotyczące komunikacji w podobnym systemie [26], jednak ograniczają się do przedstawienia znanych typów komunikacji. Badania komunikacji koncentrują się wokół testowania podatności systemów DCS na ataki [20, 27] i luk w zabezpieczeniach [27]. Diagnozowanie komunikacji

obejmuje też zagadnienia zabezpieczeń zewnętrznych, np. stosowania firewalli [18, 28], czy też szyfrowania danych i dystrybucji kluczy [19, 29]. Badana jest również odporność systemów na ataki typu DDoS [13]. W większości jednak badania poświęcone są testowaniu udokumentowanych protokołów przemysłowych, w tym protokołu MMS [20] w sterownikach AC800M. Dedykowane, zamknięte, firmowe protokoły w dalszym ciągu wymagają poznania ich parametrów i funkcjonalności. W rozpatrywanym w artykule systemie, zbudowanym na bazie stacji procesowej AC800F i oprogramowania wizualizacyjnego DigiVis wykorzystano właśnie tego rodzaju firmowe, dedykowane rozwiązanie [25]. Czy takie rozwiązanie jest lepsze? Można pozornie odnieść wrażenie, że przecież zamknięty, dedykowany protokół komunikacyjny wydaje się bezpieczniejszy, ze względu na jego słabą znajomość przez ewentualnych intruzów, próbujących dostać się do systemu i zaburzyć jego prawidłowe funkcjonowanie. Czy należy czuć się komfortowo i bezpiecznie przesyłając dane ze stacji procesowej do operatorskiej, wizualizującej operatorowi trwający, sterowany proces przemysłowy właśnie takim firmowym, zamkniętym protokołem? Ze względu na ogólną, prawidłową tendencję do tworzenia sieci przemysłowej jako oddzielnej izolowanej struktury, można by odpowiedzieć twierdząco. Z drugiej strony, informacje przedstawione w części 2, dotyczące diagnozowania komunikacji, mogą nieco ostudzić entuzjazm zwolenników zamkniętych rozwiązań.

Problem diagnozowania komunikacji stacja procesowa – stacja operatorska (PS-OS), jak każdy proces diagnozowania składa się z dwu etapów: badania diagnostycznego i wnioskowania [18]. Wnioskowanie przeprowadzono na podstawie danych uzyskanych w wyniku badania diagnostycznego zrealizowanego w układzie przedstawionym na Rys. 3. Stacja procesowa połączona jest z operatorską przez przełącznik sieciowy. Do przełącznika podłączona jest także diagnozująca stacja inżynierska z zainstalowanym oprogramowaniem sniffera przechwytującym transmitowane dane. Zastosowano tu także odpowiednie ustawienie przełącznika (tzw. port lustrzany [11]), dołączając stację diagnozującą do portu, na który kopiowany jest cały ruch pomiędzy stacjami. Dodatkowym utrudnieniem w danym przy-

Rys. 3. Diagnozowanie komunikacji pomiędzy stacjami operatorskimi Fig. 3. Diagnosing communication between operator stations

Rys. 2. Rozpatrywany system wykorzystujący standard Ethernet Fig. 2. System under consideration using the Ethernet standard

padku jest brak znajomości struktury komunikatu, co zmusza do wielokrotnego powtarzania przechwytywania transmitowanych danych, kolejnych zmian wartości przesyłanych danych i obserwacji zmiany wartości bajtów pola danych datagramu (stwierdzono po rozpoczęciu nasłuchu komunikacji, że stacje wymieniają dane wg protokołu UDP) [16]. Komunikacja wg UDP jest szybsza niż wg TCP [16]. Przesyłane komunikaty w przeciwieństwie do transmisji TCP nie muszą być potwierdzane przez stronę odbiorczą. Mimo szybkości oferowanej przez połączenie UDP, zastosowanie protokołu bezpołączeniowego (bez potwierdzania) do komunikacji ze stacją operatorską, gdzie wizualizuje się sterowany proces i przeprowadza się oddziaływanie operatorskie jest problematyczne ze względu na bezpieczeństwo dostarczenia danych. W celu zdiagnozowania miejsca w komunikacie, gdzie przesyłane są wartości zmiennych procesowych, w stacji procesowej uruchomiono nieskomplikowany układ sterowania (Rys. 4), tzw. układ „start-stop” [22] w języku FBD [30]. Sygnały na wejściach i wyjściach są binarne. Realizuje on funkcję podtrzymania stanu wysokiego na wyjściu, w układzie dwóch wejść obsługiwanych z przycisków monostabilnych, z priorytetem wejścia „stop” – opisaną wzorem: stop wyjscie start wyjscie i i i ∧ ∨ = ) ( 1

gdzie: start, stop – zmienne wejściowe; wyjscie – zmienna wyjściowa; oznaczenia z indeksem dolnym (i–1) dotyczą wartości zmiennej z poprzedniego cyklu obliczeniowego, oznaczenia z indeksem (i) – cyklu aktualnego.

Ten prosty układ „strat-stop”, po podłączeniu w strukturze sprzętowej do wejść i wyjścia sterownika, umożliwia obsługę wyjścia z poziomu fizycznych przycisków monostabilnych.

Na stacji operatorskiej uruchomiono nieskomplikowaną wizualizację, pokazującą stan zmiennej wyjscie za pomocą statycznego koła zmieniającego kolor (wyjscie = 0 – czerwony, wyjscie = 1 zielony). Zastosowanie jak najprostszego układu sterowania i wizualizacji miało za zadanie zminimalizować liczbę przesyłanych danych między stacjami, w celu uproszczenia wnioskowania diagnostycznego dotyczącego znaczenia pól w komunikacie.

W pierwszej fazie eksperymentu pozostawiono wyjście w stanie 0. Na ekranie stacji operatorskiej uzyskano obraz koła w kolorze czerwonym (Rys. 5). Jednocześnie uruchomiony sniffer zarejestrował datagram, którego pole danych przedstawia rysunek 5. Niebieską ramką zaznaczono wartości pól, na które należy

Rys. 4. Testowy schemat FBD – przesył jednej wartości (wyjscie = 0) Fig. 4. FBD test diagram – one value transfer (wyjscie = 0)

Rys. 5. Wizualizacja i przesyłane dane dla przypadku: wyjscie = 0 Fig. 5. Visualisation and data transferred for the case: wyjscie = 0

Rys. 6. Wizualizacja i przesyłane dane dla przypadku: wyjscie = 1 Fig. 6. Visualisation and data transferred for the case: wyjscie = 1

Rys. 7. Testowy schemat FBD – przesył dwóch wartości (wyjscie = 0, wyjscie2 = 0) Fig. 7. FBD test diagram – two value transfer (wyjscie = 0, wyjscie2 = 0)

zwrócić uwagę. Zwrócono uwagę na wartość 16(hex), która zawarta była we wszystkich komunikatach i oznaczała numer systemowy stacji operatorskiej (dziesiętnie 22). Na czwartym bajcie od końca pola danych zarejestrowano wartość 00. Aby potwierdzić, że jest to wartość zmiennej wyjscie, należało zmienić jej stan i ponownie obserwować zawartość pola danych datagramu.

Wielokrotne próby przełączania przyciskami (start, stop) dołączonymi do wejść binarnych sterownika, wysterowującymi zmienną wyjscie w stan wysoki potwierdziły, że dla stanu wysokiego zmiennej wyjscie (kolor zielony koła, niebieska ramka – Rys. 6) nastąpiła zmiana na czwartym bajcie od końca pola danych (z 00 na 01). Tym samym znaleziono miejsce przesyłu wartości zmiennej w komunikacie.

Diagnozowanie komunikacji kontynuowano rozbudowując nieznacznie układ sterowania przez dodanie zmiennej wyjscie2, która przyjmować powinna wartość tożsamą ze zmienną wyjscie (Rys. 7). Celem powielenia zmiennych było zaobserwowanie, w jaki sposób przesyłane są dwie wartości zmiennych ze stacji procesowej do stacji operatorskiej.

Na obrazie graficznym stacji operatorskiej dodano drugie koło. Kolor wyświetlania, analogicznie jak poprzednio, uzależniono od stanu zmiennej wyjscie2. W pierwszej fazie nie wysterowano wyjść układu i przesyłano stany niskie obydwu zmiennych. Na obrazie graficznym (Rys. 8) obydwa koła miały kolor czerwony, oznaczający transmisję stanu niskiego wartości zmiennych.

Rys. 8. Wizualizacja i przesyłane dane dla przypadku: wyjscie = 0, wyjscie2 = 0 Fig. 8. Visualisation and data transferred for the case: wyjscie = 0, wyjscie2 = 0

Zwrócono uwagę na kilka obserwowanych elementów: a) długość pola danych datagramu, która zmieniła się o cztery bajty (Rys. 8) w stosunku do przypadku przesyłu jednej wartości zmiennej; b) czwarty bajt od końca i ósmy bajt od końca (wartości 00); c) pierwszy (oznaczony strzałką) bajt pola danych i trzeci (wartość 20 w ramce).

Następnie przyporządkowano poziom wysoki sygnału (przyciskiem podłączonym do start) zmiennej start. Wynikiem wykonania układu z diagramu FBD (Rys. 7) było podanie na wyjścia wyjscie i wyjscie2 wartości logicznej „1” (TRUE).

Rys. 9. Wizualizacja i przesyłane dane dla przypadku: wyjscie = 1, wyjscie2 = 1 Fig. 9. Visualisation and data transferred for the case: wyjscie = 1, wyjscie2 = 1

Potwierdzeniem przesłania wartości zmiennych wyjściowych była wizualizacja na odległej stacji operatorskiej zielonych kół (oznaczających wyjscie = wyjscie2 = 1 – Rys. 9). W wyniku transmisji dwóch wartości (wyjscie = wyjscie2 = 1) w przechwyconym polu danych na czwartym i ósmym bajcie od

Rys. 10. Zmienione dane w przypadku zewnętrznego zakłócenia przesyłu Fig. 10. Changed data in the case of external transfer disruption

ności jest zawarta w nagłówku TCP/ UDP suma kontrolna liczona na podstawie całego komunikatu (a nie tylko z pola danych). Czy ewentualna podmiana wartości danych procesowych oraz umieszczenie danych w spreparowanym komunikacie będzie traktowane przez stację operatorską jako poprawne? Podczas prób zastanawiano się: co stałoby się, gdyby został zakłócony przesył danych? Gdyby pomimo wysterowania wyjść w stan wysoki, został zaburzony obraz? Czy jest to tu możliwe? Posiłkując się schematem FBD (Rys. 7) można z góry założyć, że pojawienie się różnych wartości zmiennych wyjscie i wyjscie2 nie jest możliwe, są one bowiem dołączone do wspólnej linii sygnałowej.

Rys. 11. Wizualizacja w przypadku zewnętrznego zakłócenia przesyłu Fig. 11. Visualization in the case of external transfer disruption

Rys. 12. Diagnozowanie komunikacji pomiędzy stacjami procesowymi Fig. 12. Diagnosing communication between process stations

końca zdiagnozowano wartości 01. Wykonując jeszcze kilkadziesiąt dodatkowych, innych niż opisane prób, zaobserwowano, że zmienne transmitowane są kolejno od czwartego bajtu od końca, co cztery bajty w stronę początku wiadomości (stąd potwierdzenie wyniku obserwacji „b)”). Zwiększa się też długość pola danych datagramu (z 60B na 64B – potwierdzenie wyniku obserwacji „c)”)

Stacja operatorska służy do wizualizacji działania procesu przebiegającego w stacji procesowej. Zatem operator powinien otrzymywać na ekranie synoptycznym wiarygodne dane. Należy zaznaczyć, że badany protokół komunikacyjny nie wyposażono w mechanizm obliczania sumy kontrolnej z wartości pola danych. Jedynym mechanizmem kontroli integral-

W celu przetestowania możliwości zaburzenia wizualizacji, spreparowano odpowiedni datagram z podmienioną wartością czwartego bajtu od końca (zmiana z 01 na 00 – por. Rys. 10). Oczywiście zadbano, aby pojawiał się on około dwukrotnie częściej niż cykl nadawczy stacji procesowej i czas odświeżania. Stacja operatorska otrzymywała więc datagramy poprawne i – znacznie częściej – zaburzone, spreparowane (bezwładność odświeżania wizualizacji powodowała wyświetlanie stanu zgodnego z podmienionymi danymi). W wyniku przeprowadzonego eksperymentu, otrzymano obraz przedstawiony na Rys. 11. Zwizualizowano sytuację niemożliwą w przypadku zdatności systemu sterowania (jednoczesne różne wartości zmiennych na wyjściach), zatem skutecznie zakłócono transmisję!

4. Diagnozowanie

W celu diagnozowania komunikacji pomiędzy stacjami procesowymi zestawiono układ przedstawiony na Rys. 12. W przypadku łączenia fizycznych stacji procesowych, diagnostykę przeprowadza się z poziomu stacji inżynierskiej. Jeśli w konfiguracji zamiast jednej ze stacji zostanie użyty emulator, to testowanie można przeprowadzić ze stanowiska emulatora. Zastosowano tu podobne „zabiegi” wstępne do przedstawionych w części 2.

W celu poprawnej komunikacji między stacjami procesowymi skonfigurowano układ komunikacji obydwu stron wykorzystujący bloki komunikacyjne FBD. Kolejne kroki procesu konfiguracji, obejmują: wybranie w strukturze sprzętowej modułu komunikacyjnego (Ethernet), przyporządkowanie odpowiedniego interfejsu sieciowego (określającego rodzaj protokołu UDP/TCP),

a następnie dodanie bloków komunikacyjnych wysyłających/ odbierających dane odpowiednio z każdej strony (Rys. 13). Do testów wybrano ww. sposób zestawienia komunikacji: najpierw używając interfejsu UDP, potem – TCP. W wyniku przeprowadzonych doświadczeń i wielokrotnych przesyłów danych różnice nie były znaczące.

Proces diagnozowania komunikacji PS-PS przebiegał podobnie do fragmentu przedstawionego w punkcie drugim, dotyczącego komunikacji PS-OS. Ze względu na znaczną objętość wyników badań, najważniejsze wyniki wnioskowania dotyczącego ruchu sieciowego między stacjami procesowymi zebrano syntetycznie poniżej: −stały pierwszy bajt pola danych (wartość 20); −bajt rozmiaru przesyłanej zmiennej (nr 3) – pierwszy bajt rozmiaru danych;

−numeracja komunikatów – znaleziono także bajt przekazujący numer każdego kolejnego komunikatu (nr 13) – inkrementowany po każdym wysłaniu; bajt numeracji (nr 15) – zawiera ID modułu odbierającego; pierwszy bajt statusu (nr 17) – blok wysyłający ustawia na „00”; potwierdzenie odebrania – ustawienie w wiadomości zwrotnej bajtu statusu na „01”; bajt statusu czasu timeout (nr 19) – pierwszy bajt zawierający wartość czasu timeout; próba wysyłania wartości typu integer – 2-bajtowa wartość umieszczona jest na końcu pola danych (potwierdzenie jest krótsze o dwa bajty);

−format danych – wartości przesyłane są w formacie odwróconym (najpierw najmniej znaczące bajty).

Rys. 14. Propozycja dodatkowego zabezpieczenia przez użytkownika przesyłanych danych Fig. 14. Proposed additional user-protection of transferred data

Rys. 13. Sposób konfiguracji komunikacji stacji procesowej Fig. 13. Process station communication configuration method

W artykule przedstawiono wybrane fragmenty procesu diagnozowania komunikacji pomiędzy stacją procesową i operatorską, a także pomiędzy dwiema stacjami procesowymi mini-systemu rozproszonego. Na podstawie przedstawionego w punkcie drugim fragmentu badania można zauważyć, że proces diagnozowania jest bardzo pracochłonny. Badanie przeprowadzane jest właściwie na zasadzie „czarnej skrzynki”. W wyniku przeprowadzonych eksperymentów uzyskano informacje dotyczące sposobu transmisji i położenia wartości zmiennych procesowych w przesyłanych komunikatach.

Informacje te można wykorzystać do skomunikowania stacji systemu z rozszerzającymi zasobami użytkownika. Przykładem może być brama (ang. gateway) PS – Modbus TCP, umożliwiająca komunikację między zewnętrznymi systemami i emulatorem, w którym nie zaimplementowano protokołu Modbus TCP.

Omówione w artykule wyniki diagnozowania komunikacji między stacją procesową i stacją operatorską pokazują wyraźnie, że przesył danych, wizualizujących proces sterowany przez stację procesową, jest realizowany bez dodatkowych zabezpieczeń. W celu zapewnienia większego bezpieczeństwa proponuje się zestawić połączenie stacja procesowa – emulator (Rys. 14).

Na stanowisku emulatora stacji procesowej powinno być uruchomione oprogramowanie wizualizacyjne wymieniające dane lokalnie w ramach jednego fizycznego stanowiska. Oprócz danych zawierających wartości zmiennych procesowych, alternatywnym kanałem komunikacyjnym (fizycznym lub logicznym) może być przesłana wartość funkcji skrótu pierwotnej wiadomości, obliczona z użyciem uzgodnionego parametru ziarna. Układ komparacyjny w stacji odbiorczej po wykonaniu analogicznych obliczeń, porównywałby przesłane i obliczone wartości funkcji skrótu. Tylko w przypadku zgodności, wartość zmiennej procesowej byłaby wizualizowana na stacji operatorskiej. Nie zapobiegnie to oczywiście celowym, wyrafinowanym atakom na integralność przesyłanych komunikatów, ale zminimalizuje możliwość wizualizacji niewłaściwych danych.

1. Bednarek M., Dąbrowski T., Olchowik W., Selected practical aspect of communication diagnosis in the industrial network, „Journal of KONBiN”, Nr 49, 2019, 383–404, DOI 10.2478/jok-2019-0020.

2. Bednarek M., Dąbrowski T., Trójpoziomowe zabezpieczanie integralności i poufności przesyłanych danych w sieci przemysłowej, „Biuletyn WAT”, Vol. LXVI, nr 1, 2017, 81–90, DOI: 10.5604/01.3001.0009.9486.

3. Bednarek M., Będkowski L., Dąbrowski T., Komparacyjno-progowe diagnozowanie w systemie transmisji komunikatów, „Przegląd Elektrotechniczny”, nr 5, 2008, 320–324.

4. Bacidore M., Ethernet vs. fieldbus: the right network for the right application, www.controldesign.com, 17.10.2016.

5. Chipkin P., Modbus for Field Technicians, Createspace Independent Publishing Platform, 2011.

6. Goldstein A., Tutorial on Modbus RTU Slave Design: How to Design Modbus Slave Device in C, Amazon Digital Services, US, 2020.

7. Solnik W., Zajda Z., Sieć Profibus DP w praktyce przemysłowej. Przykłady zastosowań, Wydawnictwo BTC – Korporacja, e-book, Legionowo, 2013.

8. Bender K., PROFIBUS: Fieldbus for Industrial Automation, Prentice-Hall, 1993.

9. Danielis P., Skodzik J., Altmann V., Schweissguth E.B., Golatowski F., Timmermann D., Schach J., Survey on realtime communication via ethernet in industrial automation

environments, Proceedings of the 2014 IEEE Emerging Technology and Factory Automation (ETFA), 2014, DOI: 10.1109/ETFA.2014.7005074.

10. Spurgeon Ch.E., Zimmerman J., Ethernet: The Definitive Guide: Designing and Managing Local Area Networks, O’Really Media, 2014.

11. Ansari S., Rajeev S.G., Chandrashekar H.S., Packet sniffing: a brief introduction, „IEEE Potentials”, Vol. 21, No. 5, 2003, 17–19, DOI: 10.1109/MP.2002.1166620.

12. Leslie F., Sikos L.F., Packet analysis for network forensics: A comprehensive survey, „Forensic Science International: Digital Investigation”, Vol. 32, 2020, DOI: 10.1016/j.fsidi.2019.200892.

13. Ackerman P., Industrial Cybersecurity, Packt Publishing, Birmingham-Mumbai, 2021.

14. Coutu M., The Technicians Guide to Modbus TCP, Amazon Digital Services LLC – KDP Print US, 2020.

15. Popp M., Industrial communication with Profinet, e-book, Profibus & Profinet International (PI), 2018.

16. Stevens R., TCP/IP Illustrated. The Protocols, Vol. 1, Addison-Wesley 2012.

17. Syed M., Black box thinking, John Murray Press, 2016.

18. Cheswick W.R., Bellovin S.M., Rubin A.D., Firewalls and Internet Security: Repelling the Wily Hacker. Addison-Wesley Longman Publishing Co. Inc., Boston, MA, USA, 2003.

19. Dawson R., Boyd C., Dawson E., Nieto J.M.G., Skma: a key management architecture for scada systems, „ACSW Frontiers ’06: Proceedings of the 2006 Australasian workshops on Grid computing and e-research”, Australian Computer Society, Inc., 183–192, Darlinghurst, Australia, 2006.

20. Sorensen J., T., Security in Industrial Networks, Norwegian University of Science and Technology, July 2007.

21. Dąbrowski T., Diagnozowanie systemów antropotechnicznych w ujęciu potencjałowo-efektowym, Wydawnictwo Wojskowej Akademii Technicznej, Warszawa, 2001.

22. Bednarek M., Wizualizacja procesów – laboratorium, Oficyna Wydawnicza Politechniki Rzeszowskiej, Rzeszów 2004.

23. Tob, Profinet – podstawy, teoria i praktyka, https://iautomatyka.pl.

24. Profibus & Profinet International (PI), PROFINET Technology and Application – System Description, e-book, 2018.

25. Dokumentacja techniczna Freelance. Getting Started, Version 9.2 SP1, ACC, 2010.

26. System 800xA. AC800M Communication Protocols, ABB, 2003–2016.

27. Byres E.J., Hoffman D., Kube N., On shaky ground –a study of security vulnerabilities in control protocols Tech. rep., Wurldtech Analytics Inc, Wurldtech Analytics Inc. 208-1040 Hamilton St. Vancouver BC Canada V6B 2R9, 2006.

28. Bryes E., Karsch J., Carter J., Firewall deployment for Scada and process control networks. Tech. Rep. 1.4, NISCC, National Infrastructure Security Co-ordination Center P O Box 832 London, February 2005.

29. Beaver C.L., Gallup D.R., NeuMann W.D., Torgerson M.D., Key management for Scada. Tech. Rep. SAND20013252, Sandia National Laboratories, Sandia National Laboratories Albuquerque NM 87185-0785, Mai 2003.

30. Norma IEC 61131-3:2013. Programmable controllers –Part 3: Programming languages

Abstract: The article describes selected fragments of the process diagnosing communication between a process and operator station, and between process stations of a distributed mini-system based on an AC800F modular industrial controller. Conducted experiments provided information on the transmission method and location of process variable values in transferred messages. The information can be used to make a decision regarding additional transfer protections or communicating system stations with expanding user resources.

Keywords ORCID: 0000-0001-8987-5134

Mariusz Ginter

Streszczenie: Artykuł prezentuje czujnik prądu elektrycznego zbudowany ze światłowodowego interferometru różnicowego wykorzystujący efekt Faradaya we włóknie jednomodowym. Został on użyty do pomiaru przebiegów prądu o dużych amplitudach i częstotliwości sieciowej. Czujnik optyczny nie wprowadza dodatkowej rezystancji i indukcyjności. Elementem magnetoczułym jest światłowodowa cewka wykonana z kwarcowego jednomodowego włókna telekomunikacyjnego. Światłowód, w którym rdzeń jest skręcony dookoła swojej osi, charakteryzuje się małym wpływem wielkości zakłócających, tj. drganiom mechanicznym i zmianom ciśnienia na pracę interferometru różnicowego poprzez indukowanie we włóknie szklanym dwójłomności liniowej. Zaproponowano sposoby eliminacji wielkości wpływowych na działanie światłowodowego czujnika prądu przez zmniejszenie dwójłomności liniowej indukowanej w światłowodzie od tych wielkości. Wykreślono zależność znormalizowanego natężenia światła w układzie podstawowym i z lustrem na końcu światłowodu. Zaprezentowano wyniki badań eksperymentalnych rozwiązania konstrukcyjnego interferometru różnicowego bazującego na efekcie Faradaya, pracującego na długości fali 1550 nm. Zrealizowano pomiary prądu sinusoidalnego o częstotliwości 50 Hz i o amplitudach z zakresu 100–1500 A. Wyznaczono niepewność pomiaru amplitudy prądu elektrycznego w zakresie wartości mierzonych, którą oszacowano na wartość nie większą niż 1,5 %.

1.

Wprowadzenie

Zastosowanie układów optycznych w konstrukcjach czujników wielkości elektrycznych i magnetycznych jest pożądane z wielu względów. Czujniki optyczne mają parametry, których nie oferują klasyczne czujniki wielkości fizycznych. Metody pomiarowe natężenia prądu elektrycznego o dużych wartościach, m.in. boczniki wiroprądowe, cewki Rogowskiego mają niezadowalające właściwości metrologiczne. Pomiary prądu z zastosowaniem tych metod są obarczone wadami w postaci podatności na zakłócenia zewnętrzne, wprowadzania indukcyjność poprzez sprzężenie magnetyczne (transformator Rogowskiego) oraz

rezystancji i indukcyjności (boczniki) [5, 9]. Zastosowanie fali świetlnej, jej parametrów, tj. natężenia światła, kąta skręcenia płaszczyzny polaryzacji jako nośnika informacji pomiarowej eliminuje zakłócenia pochodzące od zewnętrznych pól elektrycznych i magnetycznych. Zakłócenia te mogą silnie odkształcać sygnał elektryczny na drodze od elementu badanego do układu pomiarowego, szczególnie jest to istotne w miejscach, gdzie występuje przepływ prądów o dużych amplitudach.

Użycie światłowodowego interferometru różnicowego, wykorzystującego efekt Faradaya, do pomiaru dużych amplitud prądu elektrycznego jest celowe ze względu na wymagania stawiane układom pomiarowym. Zwłaszcza porównując właściwości proponowanego rozwiązania w stosunku do obecnie stosowanych metod pomiarowych.

Schemat czujnika prądu bazującego na interferometrze różnicowym zbudowanym ze światłowodu jednomodowego wykorzystującego efekt Faradaya przedstawiono na rys. 1 [10].

Na rys. 2 przedstawiono zasadę działania światłowodowego czujnika prądu wykorzystującego efekt Faradaya, który jest

oddziaływaniem pola magnetycznego wytworzonego przez płynący w przewodniku prąd elektryczny na płaszczyznę polaryzacji propagującego światła liniowo spolaryzowanego. Płaszczyzna ta zostaje skręcona (rys. 1), a kąt skręcenia jest zależny od kierunku wektora indukcji magnetycznej i kierunku rozchodzenia się światła. Zjawisko Faradaya jest wywołane oddziaływaniem elektronów magnetoczułego światłowodu z zewnętrznym polem magnetycznym [2, 11].

Rys. 1. Schemat światłowodowego czujnika prądu w konfiguracji podstawowej wykorzystującego efekt Faradaya Fig. 1. The diagram of a fiber optic current sensor in a basic configuration using the Faraday effect

Rys. 4. Wykres zależności znormalizowanego natężenia światła na wyjściu czujnika prądu od kąta rotacji Faradaya oraz dwójłomności liniowej

Fig. 4. The characteristics of the dependence of the normalized light intensity at the output of the current sensor on the Faraday rotation angle and linear birefringence

(3) gdzie: P0 – maksymalna moc na wyjściu czujnika prądu.

Dla dostatecznie małych wartości kąta Θ można zależność (3) zapisać jako: (4)

Rys. 2. Zasada działania światłowodowego czujnika prądu w konfiguracji podstawowej wykorzystującego efekt Faradaya Fig. 2. The principle of operation of a fiber-optic current sensor in a basic configuration using the Faraday effect

Kąt skręcenia płaszczyzny polaryzacji Θ jest zależny od długości drogi dl, którą światło przebywa w ośrodku, znajdującym się w polu magnetycznym, oraz od natężenia H pola magnetycznego [1, 13]:

(1)

W światłowodowym czujniku prądu (rys. 1), włókno jest owijane N razy wokół przewodu z prądem o natężeniu I. Światło jest propagowane we włóknie wzdłuż linii pola magnetycznego, co powoduje, że kąt skręcenia płaszczyzny polaryzacji jest maksymalny dla ustalonych parametrów toru optycznego [3, 8, 12]. Stosując prawo Ampera, liniowa całka pola magnetycznego z równania (1) redukuje się do wyrażenia: VNI = Θ (2)

Stałą Verdeta V charakteryzuje zdolność danej substancji do skręcania płaszczyzny polaryzacji w polu magnetycznym [1, 4, 14].

Moc optyczną na wyjściu układu optycznego można zapisać w postaci:

Zgodnie z wyrażeniem (4) natężenie światła jest liniową funkcją mierzonego prądu. Uzyskanie wymaganej liniowości wiąże się z ograniczeniem zakresu zmian sygnału użytecznego na wyjściu światłowodowego czujnika prądu [5, 6, 13].

Wpływ dwójłomności liniowej na działanie czujnika prądu wykorzystującego efekt Faradaya jest decydujący. Do opisu światłowodowego czujnika polarymetrycznego wykorzystano macierze Jonesa, które opisują zmianę stanu polaryzacji przy przejściu fali świetlnej przez poszczególne elementy toru optycznego [6, 7].

Dla konfiguracji podstawowej czujnika prądu (rys. 1) można na podstawie schematu funkcjonalnego (rys. 3.) wyznaczyć stan polaryzacji po przejściu fali świetlnej przez wszystkie elementy toru optycznego. Znając macierze Jonesa elementów wchodzących w skład czujnika prądu oraz wektor stanu polaryzacji fali wejściowej E(0) otrzymano wektor wyjściowego natężenia pola elektrycznego E(L):

gdzie: AP – macierz Jonesa polaryzatora, – macierz Jonesa światłowodu jednomodowego, na który oddziałuje mierzony prąd i czynniki wpływowe, AA – macierz Jonesa analizatora.

Do opisu światłowodu jednomodowego, na który działają wielkości zakłócające oraz pole magnetyczne powstałe od mierzonego prądu opisuje macierz [6, 7]:

Rys. 3. Schemat funkcjonalny światłowodowego czujnika prądu w konfiguracji podstawowej Fig. 3. The functional diagram of a fiber-optic current sensor in a basic configuration

(6)

gdzie: β – dwójłomność liniowa, VNI = Θ ,

Wykres zależności znormalizowanego natężenia światła na wyjściu czujnika prądu od kąta rotacji Faradaya oraz dwójłomności liniowej przedstawiono na rys. 4. Analizy dokonano na podstawie opisu układu pomiarowego w konfiguracji podstawowej (rys. 1) na podstawie zależności (5) i (6). Uwzględniono parametry poszczególnych elementów użytych w torze optycznym.

Wzrost wartości zakłócającej dwójłomności indukującej się w falowodzie przy niezmienionym kacie rotacji Faradaya powoduje, że maleje sygnał na wyjściu czujnika polarymetrycznego. Dla dużych wartości dwójłomności liniowej czułość układu na zjawisko Faradaya ma bardzo małą wartość. Powinno się dążyć, aby w układzie rzeczywistym liniowa dwójłomność światłowodu była jak najmniejsza, co przekłada się na wzrost sygnału użytecznego [1, 14]. Aby zwiększyć sygnał użyteczny można zastosować na końcu światłowodu lustro oraz zastosować sprzęgacz światłowodowy lub lustro półprzepuszczające (rys. 5).

Zastosowanie lustra w układzie powoduje podwojenie drogi optycznej światła liniowo spolaryzowanego w polu magnetycznym wytworzonym przez mierzony prąd. Przekłada się to na dwukrotne zwiększenie kąta skręcenia polaryzacji w stosunku do układu podstawowego czujnika prądu.

Dla konfiguracji czujnika prądu z lustrem na końcu światłowodu (rys. 5) można na podstawie schematu funkcjonalnego (rys. 6.) wyznaczyć stan polaryzacji po przejściu fali świetlnej przez wszystkie elementy toru optycznego, używając macierzy Jonesa poszczególnych elementów takich samych jak dla układu podstawowego: (7)

gdzie: AP – macierz Jonesa lustra.

Rys. 5. Schemat światłowodowego czujnika prądu wykorzystującego efekt Faradaya w konfiguracji z lustrem na końcu światłowoduu Fig. 5. The diagram of a fiber-optic current sensor using the Faraday effect in a configuration with a mirror at the end of the fiber

Rys. 7. Wykres zależności znormalizowanego natężenia światła na wyjściu czujnika prądu dla konfiguracji z lustrem na końcu światłowodu od kąta Faradaya oraz dwójłomności Fig. 7. The characteristics of the dependence of the normalized light intensity at the output of the current sensor for the configuration with a mirror at the end of the fiber on the Faraday angle and birefringence

Analizy dokonano na podstawie opisu układu pomiarowego w konfiguracji z lustrem na końcu światłowodu (rys. 5.) na podstawie zależności: (7) i (6). Uwzględniono parametry poszczególnych elementów użytych w torze optycznym. Wykres zależności znormalizowanego natężenia światła na wyjściu czujnika prądu od kąta rotacji Faradaya oraz dwójłomności liniowej dla układu czujnika prądu z lustrem na końcu światłowodu został przedstawiony na rysunku 7.

Zarówno dla konfiguracji podstawowej, jak i dla polarymetru z lustrem na końcu światłowodu, kompensacja wpływu drgań mechanicznych jest utrudniona. Zastosowanie tego typu układów pomiarowych nie powinno być stosowane tam, gdzie występują drgania mechaniczne indukujące dwójłomność we włóknie. Czujnik należy umieścić tak, aby uniemożliwić oddziaływanie drgań.

Czujnik prądu wraz z układem pomiarowym wykonanym dla długości fali 1550 nm przedstawiono na rys. 8. Wykorzystano tu światłowodowy czujnik prądu w konfiguracji podstawowej. W rozwiązaniu konstrukcyjnym tor optyczny czujnika jest zamknięty, tzn. światło propaguje od źródła do detektora w elementach światłowodowych. Zwiększa to niezawodność oraz łatwość implementacji przedstawionego układu do różnych warunków pomiarowych. Jako źródło światła wykorzystano laser S3FC1550 firmy Thorlabs o długości fali 1550 nm [7], który charakteryzuje się regulowaną mocą wyjścia. W celu uzyskania dużej czułości napięcia wyjściowego układu pomiarowego w stosunku do amplitudy prądu, ustalono moc wyjściową o wartości 0,8 mW. Jako analizatora światła użyto liniowego polaryzatora światłowodowego typu ILP1550PM-FC-1. Natężenie światła na wyjściu toru optycznego mierzone jest

Rys. 6. Schemat funkcjonalny czujnika prądu wykorzystującego efekt Faradaya w konfiguracji z lustrem na końcu światłowodu Fig. 6. The functional diagram of a current sensor using the Faraday effect in a configuration with a mirror at the end of the optical fiber

Rys.

przez fotodetektor PDA 10CF-EC, który ma w swojej budowie wzmacniacz.

Jako przetwornik prądu zastosowano cewkę światłowodową o 30 zwojach i średnicy 8 cm, szerokość cewki to 5 mm. Jest ona wykonana z telekomunikacyjnego włókna jednomodowego o symbolu OFS-D-11-5-11/23 firmy Siecore. W zastosowanym włóknie skręcenie rdzenia to 15 obrotów na 1 m, co odpowiada 1 obrotowi rdzenia światłowodu na około 6,7 cm. Światłowód, z którego nawinięto cewkę, został skręcony wokół własnej osi w celu zmniejszenia indukowanej dwójłomności liniowej od czyn-

Charakterystyka statyczna wykonanego czujnika polarymetrycznego została określona przez pomiar prądów o częstotliwości przemysłowej f = 50 Hz (rys. 9). Błąd nieliniowości charakterystyki nie przekracza 1 %.

Czułość układu interferometru różnicowego wykorzystującego efekt Faradaya przy parametrach układu: cewka 30 zwojowa, długości fali 1550 nm, mocy źródła światła 0,8 mW określono

Rys. 9. Charakterystyka statyczna czujnika prądu Fig. 9. The static characteristics of the current sensor

ników wpływowych. Stała Verdeta dla dwutlenku krzemu jest zależna od długości fali i w zastosowanym czujniku przy świetle o 1550 nm jest w przybliżeniu równa 0,6 μrad/A. Możliwa więc jest do uzyskania wartość czułości definiowana jako zmiana kąta skręcenia płaszczyzny polaryzacji w zależności od amplitudy natężenia mierzonego prądu nie większa niż Θ/I = 18 μrad/A.

W wykonanym układzie optycznym światło o długości fali 1550 nm z lasera jednomodowego po przejściu przez elementy układowe oraz kontroler polaryzacji jest spolaryzowane liniowo. Tak spolaryzowane światło wprowadza się do światłowodu typu OFS-D-11-5-11/23, aby zapewnić maksymalną widzialność oraz liniowość zmian polaryzacji pod wpływem mierzonego prądu. Płaszczyznę polaryzacji światła jednomodowego można zmieniać za pomocą światłowodowego kontrolera polaryzacji [5, 8].

na 35 mV/kA. Niepewność względna pomiaru amplitudy prądu elektrycznego w zakresie wartości mierzonych wartkości nie jest większa niż 1,5 %.

Wymuszenia o zadanych wartościach amplitud wytworzono z użyciu transformatora zwarciowego TW-1a. Przykładowe przebiegi prądów o wartościach amplitud 400 A i 1400 A i o częstotliwości 50 Hz przedstawiono na rys. 10.

Analiza wpływu dwójłomności liniowej na działanie światłowodowego czujnika prądu w konfiguracji podstawowej i z lustrem na końcu włókna wykazuje, że wraz ze wzrostem dwójłom-

8. Układ światłowodowego czujnika prądu z wykorzystaniem światłowodu jednomodowego i źródła światła o długości fali 1550 nm Fig. 8. The system of a fiber optic current sensor with the use of a single-mode fiber and a light source with a wavelength of 1550 nm

a) b)

Rys. 10. Przebiegi prądów o częstotliwości f = 50 Hz i wartościach skutecznych: a) 400 A i b) 1400 A Fig. 10. The current waveforms with frequency f = 50 Hz and rms values: a) 400 A and b) 1400 A

ności sygnał użyteczny maleje. Indukowana w światłowodzie dwójłomność od czynników zakłócających silnie tłumi zmianę kąta rotacji Faradaya, dlatego w układach optycznych powinna ona być minimalizowana. Zastosowanie układu światłowodowego czujnika prądu z lustrem zwiększa dwukrotnie kąt skręcenia polaryzacji światła pod wpływem mierzonego prądu, przyczyną jest zwiększenie dwukrotnie drogi optycznej światła w polu magnetycznym wytworzonym przez płynący prąd w przewodniku.

Wykorzystanie źródła światła o długości fali 1550 nm umożliwia sprzęgnięcia światłowodowego czujnika prądu z systemami telekomunikacyjnymi. Możliwa jest też łatwa rekonfiguracja układu pomiarowego. Można go zastosować tam, gdzie występują silne zakłócenia elektromagnetyczne lub występują szkodliwe czynniki chemiczne.

Optycznym sygnałem wejściowym, który jest wprowadzany do interferometru różnicowego jest jednomodowa wiązka światła uzyskana z lasera wielomodowego przez zastosowanie światłowodowej siatki Bragga, która z widma wiązki wielomodowej odbija mod o pożądanej długości fali i mocy optycznej. Płaszczyznę polaryzacji światła jednomodowego można zmieniać za pomocą światłowodowego kontrolera polaryzacji, aby uzyskać maksymalną widzialność i liniowość zmian polaryzacji pod wpływem oddziaływania mierzonego prądu.

Przeprowadzono pomiary prądów sinusoidalnie zmiennych o częstotliwości 50 Hz w zakresie amplitud 100–1500 A. Uzyskana nieliniowość tej konstrukcji nie przekracza 1 %, a oszacowana niepewność typu B pomiaru prądu wynosi 1,5 %. Uzyskane wyniki pomiarów wskazują, że zastosowanie przetwornika z interferometrem różnicowym prądu jest uzasadnione a dokładności są wystarczające do zakładanych pomiarów energetycznych. Dalsze badania powinny być prowadzone pod kątem ograniczenia indukowanej dwójłomności liniowej od czynników zakłócających tj. temperatury, drgań mechanicznych. Zastosowanie lustra na końcu światłowodu zwiększa dwukrotnie czu-

łość układu, jednak aby moc optyczna na wyjściu czujnika była liniową zależnością natężenia prądu elektrycznego zmiany te powinny być dostatecznie małe.

1. Aerssens M., Gusarov A., Brichard B., Massaut V., Mégret P., Wuilpart M., Faraday Effect Based Optical Fiber Current Sensor for Tokamaks, 2nd International Conference on Advancements in Nuclear Instrumentation Measurement Methods and their Applications, 2011, DOI: 10.1109/ANIMMA.2011.6172868.

2. Chen G.Y., Newson T.P., Detection bandwidth of fibre-optic current sensors based on Faraday effect, “Electronics Letters”, Vol. 50, No. 8, 2014, 626–627, DOI: 10.1049/el.2014.0426.

3. Frazao O., Baptista J., Santos J.L., Recent advances in high-birefringence fiber loop mirror sensors, “Sensors”, Vol. 7, No. 11, 2007, 2970–2983, DOI: 10.3390/s7112970.

4. Fu H.Y., Wu C., Tse M.L.V., Zhang L., Cheng K.-C.D., Tam H.Y., Guan B.-O., Lu C., High pressure sensor based on photonic crystal fiber for downhole application, “Applied Optics”,Vol. 49, No. 142010, 2639–2643, DOI: 10.1364/AO.49.002639.

5. Ginter M., Fiber optic sensor for measuring currents with mains frequencies, Proceedings of SPIE, tom 10808, zeszyt 1080805, 2018, DOI: 10.1117/12.2500167.

6. Ginter M., Measurement of impulse current using polarimetric fiber optic sensor, “Photonics Applications in Astronomy, Communications, Industry, and High Energy Physics Experiments”, Vol. 10445, 2017, DOI: 10.1117/12.2280349.

7. Ginter M., Pomiar prądu sinusoidalnego z użyciem światłowodowego interferometru różnicowego, „Metrologia Badania i Zastosowania, Monografie, Studia, Rozprawy”, M152, Politechnika Świętokrzyska, 2022, 42–49.

8. Ginter M., Światłowodowy czujnik polarymetryczny do pomiaru prądu, „Pomiary Automatyka Kontrola”, Vol. 57, No. 3, 2011, 274–276.

9. Mihailovic P., Petricevic S., Fiber Optic Sensors Based on the Faraday Effect, “Sensors” (Basel), Vol. 21, No. 19, 2021, DOI: 10.3390/s21196564.

10. Nedoma J., Fajkus M., Martinek R., Measurement of electric current using optical fibers: A Review, “Przegląd Elektrotechniczny”, R. 93, Nr 11, 2017, 140–145, DOI: 10.15199/48.2017.11.30.

11. Sun L., Jiang S., Marciante J.R., All-fiber optical magnetic-field sensor based on Faraday rotation in highly terbium-doped fiber, “Optics Express”, Vol. 18, No. 6, 2010, 5407–5412, DOI: 10.1364/OE.18.005407.

12. Torbus S.A., Zastosowanie światłowodów telekomunikacyjnych G.652, G.653 i G.655 w polarymetrycznych czujnikach natężenia prądu, „Pomiary Automatyka Kontrola”, Vol. 57, No. 5, 2011, 441–446.

13. Wang H., Guan Y., Study on Long-term Operation Stability of Fiber Optical Current Transformer Based on Faraday Effect, International Conference on Intelligent Transportation, Big Data and Smart City, 2015, 767–770, DOI: 10.1109/ICITBS.2015.194.

14. Zubia J., Casado L., Aldabaldetreku G., Montero A., Zubia E., Durana G., Design and Development of a Low-Cost Optical Current Sensor, “Sensors”, Vol. 13, No. 102013, 13584–13595, DOI: 10.3390/s131013584.

Abstract: The article presents an electric current sensor built of a fiber-optic differential interferometer using the Faraday effect in a single-mode fiber. It was applied to measure current waveforms with large amplitudes and mains frequency. The optical sensor does not introduce additional resistance and inductance into the measured circuit, which is a desirable phenomenon in this type of measurements. The magnetosensitive element is an optical fiber coil made of a quartz single-mode telecommunications fiber. The optical fiber, in which the core is twisted around its axis, is characterized by a small influence of disturbing quantities, i.e., mechanical vibrations and pressure changes, on the working of the differential interferometer by inducing linear birefringence in the glass fiber. The methods of elimination of the quantities influencing the operation of the optical fiber current sensor were proposed by reducing the linear birefringence induced in the optical fiber from these quantities. The dependence of the normalized light intensity was plotted. The results of experimental research on a design solution of a differential interferometer based on the Faraday effect, operating at a wavelength of 1550 nm, are presented. The sensor was used for measurements of sinusoidal current with a frequency of 50 Hz and amplitudes ranging 100–1500 A. The uncertainty of measurement of the electric current amplitude was determined in the range of the measured values, which was estimated at no more than 1.5 %.

Keywords

ORCID: 0000-0002-3759-8531

Pomiary Automatyka Robotyka, ISSN 1427-9126, R. 26, Nr 4/2022, 105–111, DOI: 10.14313/PAR_246/105

W artykule przedstawiono opis przypadku zapewnienia ciągłości produkcji urządzenia przeznaczonego do kasowania biletów przy niedoborach dostaw na rynku komponentów elektronicznych. Uwzględnione zostały kryteria podejmowanych decyzji i ich wpływ na projekt kasownika. Zaproponowano rozwiązania, które mogą zmniejszyć ryzyko wstrzymania produkcji przez wykorzystanie zamienników brakujących elementów z uwzględnieniem minimalizacji kosztów takich zmian.

1.

Wprowadzenie

W celu wyprodukowania określonych dóbr należy stworzyć system produkcyjny. Jest to celowo zaprojektowany oraz zorganizowany układ materialny, energetyczny i informacyjny eksploatowany przez człowieka i służący wytworzeniu określonych produktów w celu zaspokojenia różnorodnych potrzeb klientów [1]. Sieć zależności i powiązań systemu produkcyjnego przedstawiono na Rys. 1.

W systemie produkcyjnym w odniesieniu do podstawowych czynników materialnych będących przedmiotem przetwarzania można wyróżnić następujące procesy (Rys. 2):

−pozyskiwania surowców i materiałów, czyli zakupu, −składowanie i przygotowywanie do produkcji, właściwy proces produkcyjny, czyli przetwarzanie zasobów, −składowanie towarów, przygotowywanie do zbytu, −dystrybucja i obsługa odbiorców.

Procesy te wyznaczają podstawowe obszary działań operacyjnych powtarzających się z cykli na cykl. W odróżnieniu od pozostałych czynników wytwórczych (np. ludzie, majątek trwały) procesy te są odmienne, nie mają cechy całkowitej odnawialności w kolejnych cyklach produkcyjnych.

Rys. 1. Uogólniony schemat systemu produkcyjnego [1] Fig. 1. Generalized diagram of the production system [1]

Zmienność procesów jest wynikiem zmieniających się warunków otoczenia. Od 2020 r. globalne łańcuchy dostaw doznały poważnych zawirowań, co utrudnia produkcję urządzeń elektronicznych i wymaga weryfikacji dotychczasowych metod pozyskiwania surowców i materiałów oraz projektowania i konstrukcji wyrobów.

Niskie koszty pracy oraz niskie marże będące wynikiem dużej konkurencyjności spowodowały, że główne fabryki i dostawcy

komponentów elektronicznych na świecie znajdują się w Azji. Jest tak również w przypadku, kiedy oficjalna siedziba producentów docelowych rozwiązań znajduje się w Europie lub USA. Mechanizmy logistyczne między Europą a Dalekim Wschodem zawsze stanowiły słabą stronę tej współpracy. W szczególności trwająca pandemia COVID-19, a następnie wojna w Ukrainie, utrudniły, a niekiedy wręcz zablokowały, możliwość transportu towarów [2]. W efekcie niektóre z nich stały się niedostępne, co ogranicza lub całkowicie uniemożliwia lokalną produkcję urządzeń. Skomplikowany mechanizm logistyczny na rynku komponentów elektronicznych okazał się bardzo wrażliwy na warunki ekonomiczne, geopolityczne i sytuację epidemiologiczną.

W artykule przedstawiono działania związane z rozwiązaniem problemu braków układów półprzewodnikowych oraz innych komponentów i podzespołów elektronicznych podczas procesu wprowadzenia do produkcji kasownika biletów typu NV1. Związane były one z koniecznością przeprojektowania urządzenia w taki sposób, aby ograniczyć przestoje produkcyjne i związane z tym straty finansowe.

Jak już wspomniano globalne zawirowania spowodowały zakłócenia procesów w lokalnych systemach produkcyjnych. W przypadku kasownika NV1 było to związane w szczególności z procesem zakupu komponentów niezbędnych do jego produkcji. Z końcem 2020 r. praktycznie z dnia na dzień zmieniła się dostępność oraz cena elementów elektronicznych niezbędnych do produkcji kasownika. Nawet w przypadku zadeklarowanej przez dostawcę dostępności komponentu realizacja zamówienia w określonym terminie cechowała się wysokim poziomem niepewności. Przykładowo dostawcy oznaczali dostępność produktu za trzy miesiące, a następnie po dwóch miesiącach wydłużali ten czas do sześciu miesięcy. Skutkowało to brakiem możliwości ustalenia przewidywalnego planu produkcji (zakłócenie zarządzania produkcją) i składania ofert sprzedaży urządzeń z deklarowanym terminem dostawy oraz instalacji. Terminowość jest podstawowym wymaganiem w procedurach przetargowych i zazwyczaj powiązane jest z nią naliczanie kar umownych. Ryzyko związane z terminowością zaopatrzenia a co za tym idzie – produkcji można próbować przenieść na dostawcę komponentu. Jeśli jednak nie jest on uczestnikiem

Rys. 2. Schemat systemu produkcyjnego w gospodarce rynkowej [1]

Fig. 2. Diagram of the production system in the market economy [1]

Rys. 3. Widok zewnętrzny kasownika NV1 Fig. 3. Overview of the NV1 device

postępowania przetargowego i dodatkowo konkurencyjność w produkcji danego komponentu jest niewielka, to nie znajdzie uzasadnienia ekonomicznego do podejmowania takiej odpowiedzialności. Mimo tego starano się uzyskać realną deklarację dostępności układu w rozmowach z producentami.

3. Kasownik NV1

Urządzenie NV1 (Rys. 3) jest kasownikiem biletów papierowych i elektronicznych [5]. Rozwiązanie oparte jest o SoM (ang. System on Module,) [3] Raspberry Pi Compute Module 3 (CM3) w wersji bazowej oraz wersjach CM3+ i CM3+Lite [9]. Uruchamiany jest na nim system Linux, najczęściej w dystrybucji Raspberry Pi OS. Z systemem tym zintegrowane jest dodatkowe oprogramowanie umożliwiające obsługę funkcji kasownika. Kasownik przystosowane jest do montażu w autobusach oraz integracji z wewnętrznymi systemami wymiany danych i sterowania. Interakcja z użytkownikiem odbywa się

Fig. 4. NV1 mainboard, major components visible

za pomocą ekranu dotykowego i komunikatów dźwiękowych. Urządzenie może być dodatkowo wyposażone w czytnik kodów 2D (np. kod kreskowy, kody dwuwymiarowe), mechanizm kasowania biletów papierowych, terminal płatniczy, czytnik kart bezstykowych i beacon Bluetooth (nadajnik Bluetooth do radiowego rozgłaszania określonej informacji).

Kasownik NV1 to urządzenie modułowe składające się z szeregu podzespołów [5] połączonych wiązkami kablowymi z płytą główną (Rys. 4). Płyta główna jest najbardziej złożonym funkcjonalnie podzespołem kasownika. Znajduje się na niej zasilanie całego urządzenia, jak również wszystkie niezbędne interfejsy komunikacyjne. Umieszczony w niej mikrokontroler z rodziny STM32 pełni rolę podstawowego układu nadzorującego poprawną pracę komponentów sprzętowych (ang. hardware supervisor). Komunikuje się on z komputerem CM3, który jest główną jednostką sterującą całego urządzenia [9]. Wybierając rozwiązania sprzętowe dla płyty głównej brano pod uwagę jego wymagania. Jednym z nich była konieczność zastosowania kontrolera Ethernet przeznaczonego do połączenia z siecią. Jest nim układ LAN9514 [6], który z powodzeniem stosowany jest w kolejnych SoM z rodziny Raspberry Pi. Liczba podłączonych peryferii (urządzeń do komunikacji, terminali płatniczych) w urządzeniu wymusza zastosowanie sprzętowego powielania interfejsów USB, jak również konwersję USB-UART (układ FT232RQ) [7]. Specyficznym rozwiązaniem jest także stosowanie konwersji DPI-LVDS (przejście z równoległego interfejsu grafiki na szeregowy) przy wykorzystaniu układu DS90CF383B [8], ponieważ moduł CM3 nie ma tego kontrolera [9]. Interfejs LVDS (ang. Low Voltage Differential Signaling) jest często stosowanym rozwiązaniem w ekranach dotykowych LCD. Zastosowany w module CM3 interfejs multimediów HDMI (ang. High Definition Media Interface) jest nieużyteczny, ponieważ konwersja HDMI-LVDS jest droższa w implementacji od konwersji DPI-LVDS.

Początki komercjalizacji (produkcja pierwszych partii wyrobu) kasownika NV1 zbiegły się w czasie z początkiem pandemii COVID-19. Spodziewając się zakłócenia dostaw z Dalekiego Wschodu, gdzie obostrzenia związane z sytuacją epidemiologiczną zostały wprowadzone najwcześniej, rozważono możliwy wpływ wspomnianych perturbacji na produkcję urządzenia. Dostawcy podzespołów zostali poproszeni o określenie czasów dostaw i dostępności komponentów. Następnie wybrano najważniejsze elementy z punktu widzenia działania urządzenia tj. takie, dla których nie istnieją zamienniki, jakie można zastosować bez konieczności wprowadzenia zmian w projekcie płyty głównej.

Priorytetem stało się zgromadzenie odpowiednich zapasów magazynowych tych elementów. W pierwszej kolejności zaku-

piono układy, których zamiana wiązałaby się z największymi kosztami zmian w projekcie i oprogramowaniu urządzenia. Należał do nich m.in. mikrokontroler STM32. Zastosowanie zamiennika wymagałoby implementacji nowego oprogramowania układowego (ang. firmware).

Z przyczyn finansowych zakupy zostały rozłożone w czasie, a dynamiczna sytuacja na rynku elektroniki spowodowała, że niektóre dostępne początkowo układy, jak CM3 (komputer sterujący) czy FT232RQ (translator USB – UART), zniknęły z rynku. Stało się to główną przyczyną do wprowadzenia niezbędnych zmian sprzętowych na płycie głównej.

Kryteriami wyboru zamienników dla układu SoM były: −parametry mechaniczne, najważniejszy z nich to wymiary płytki z układem – nie brano pod uwagę zastosowania układu, który nie mieściłby się w obudowie urządzenia (koszt projektu i wykonania nowej obudowy zamyka się w kwocie rzędu kilkuset tysięcy złotych i byłby zupełnie nieakceptowalny), parametry elektroniczne, najważniejsze to: pojemność dostępnej pamięci (wymagania dla systemu i aplikacji na urządzeniu, parametr zgłoszony przez programistów) oraz liczba wyjść GPIO (wyjścia ogólnego przeznaczenia – podłączenie komponentów kasownika), kompatybilność wsteczna związana z możliwością podłączenia układu do płyty głównej, zgodność ze standardami SMARC (ang. Smart Mobility ARChitecture) i Qseven, która zapewnia większą kompatybilność między różnymi zamiennikami układu SoM, dostępność komponentu – dla etapu projektowania (kilka egzemplarzy rozwojowych) i dla produkcji seryjnej, −szacowany koszt prac programistycznych związany z wdrożeniem i przetestowaniem nowych komponentów [4], deklarowana przez dostawcę cena komponentu (która może ulegać fluktuacjom, niemniej pozwala na rekalkulacje ostatecznej ceny kasownika NV1).

W trakcie poszukiwań zamienników uwzględniono standardy, które zapewniają dostępność różnych rozwiązań sprzętowych o tych samych gabarytach oraz strukturze połączeń zewnętrznych. Należą do nich standardy SMARC oraz Qseven, za których wykonanie i określenie odpowiada międzynarodowa organizacja SGET (ang. Standardization Group for Embedded Technolgies) [10]. Ideą tych standardów jest określenie parametrów, jakie mają spełniać komputery jednopłytkowe tak, aby można było łatwo stosować rozwiązania różnych firm. Dlatego układ i funkcje wyprowadzeń takiego komputera oraz parametry zasilania są identyczne w rozwiązaniach różnych producentów, co czyni je atrakcyjnymi zamiennikami [10].

Wzorcowym rozwiązaniem był tutaj mikrokomputer Raspberry PI CM3+, dobierając zamienniki starano się, aby parametry były najbardziej zbliżone do tego rozwiązania. Wyniki analizy rynku podsumowano w Tab. 1.

Na etapie analizy rynku nie znaleziono rozwiązania SoM, które byłoby kompatybilne z CM3 na poziomie podłączenia układu. Spowodowało to konieczność zaprojektowania płyty adaptera. Po dalszym przeanalizowaniu rynku pod kątem wymienionych kryteriów oraz potencjalnych zamienników wybrano dwa komponenty: −CoreBoard PICO3288-LVDS (duża dostępność) [11], −MSC SM2S-IMX8NANO (standard SMARC) [12].

Podjęto również decyzję, że projekt powinien obejmować możliwość użycia w przyszłości Compute Module CM4 [13] mimo braku gwarancji dostępności. Układ ten jest następcą CM3, któ-

Rys. 4. Wnętrze kasownika NV1, (zaznaczone najważniejsze podzespoły)

Tab. 1. Wykaz zamienników SoM

Tab. 1. SoM replacement list

Model i producent

Czas realizacji zamówienia produkcyjnego [tygodnie] Decyzja

CoreBoard PICO3288-LVDS URVE 3

MSC SM2S-IMX8NANO

Avnet Embedded

Raspberry Pi CM4

Raspberry Pi Foundation

gwarantowane 52, możliwa wcześniejsza realizacja

Zaakceptowany: duża dostępność, układ stosowany w innych projektach (posiadana wiedza i doświadczenie)

Zaakceptowany: standard SMARC, gwarancja dostawcy dotycząca dostępności i bardzo atrakcyjna cena

52Zaakceptowany: następca układu CM3

Colibri-arm-family Toradex 8–20

Trizeps VIII Mini 59 B11.E0910 Keith & Koep GmbH 32

Zaakceptowany (jako opcja): kompatybilny z układem CoreBoard PICO3288-LVDS, jednak cena przekraczała budżet projektu

Odrzucony: brak wbudowanej pamięci eMMC, dostępne jedynie złącze microSD na płycie SoM

ROM-5721CD-RDA1E ROM-5780CO-REA1E Advantech 30Odrzucone: stosunkowo długi czas realizacji przy przeciętnej cenie

Verdin-arm-family Toradex 8–20Odrzucony: cena znacznie przekraczała budżet projektu

VAR-SOM-6UL Variscite Ltd. 26Odrzucony: zbyt mała pojemność pamięci RAM

LEC-PX30-Q-1G-16G-R ADLINK Technology Inc. 36

Odrzucony: długi czas realizacji zamówienia, cena znacznie przekraczała budżet projektu

rego produkcja zakończy się w 2025 r. Wybór CM4 jest naturalnym etapem modernizacji kasownika.

Kryteria decyzji obejmowały również parametry techniczne takie jak dostępność określonych interfejsów. Stosowane obecnie w kasowniku komputery jednopłytkowe Raspberry Pi Compute Module 3 (CM3) w wersji bazowej, CM3+ i CM3+Lite wykorzystują procesor Broadcom BCM2837B0. Współpracuje z 1 GB pamięci RAM LPDDR2. Z kolei układ SoM CM3 i CM3+ zawiera wbudowaną pamięć eMMC o pojemności 8 GB, w wersji CM3+Lite zastępuje ją karta microSD. Odpowiednie złącze zostało umieszczone na płycie głównej w pierwotnym projekcie urządzenia (Rys. 5).

W kasowniku użyto interfejsu graficznego DPI, który wykorzystuje aż 27 wyjść GPIO. Obsługa ekranu z interfejsem LVDS wymaga zastosowania układu konwertującego DPI-LVDS (DS90C385).

Urządzenie NV1 wykorzystuje również: −dwa interfejsy I2C, dwa interfejsy UART (w tym jeden pełny – z kontrolą przepływu), −sygnał stereofoniczny w formie sygnału PWM (ang. Pulse WIdth Modulation), port USB, który jest zwielokrotniony czterokrotnie przez układ LAN9514, który umożliwia połączenie z siecią Ethernet.

−Układ SoM CM3 wymaga trzech napięć zasilających: 5 V, 3,3 V i 1,8 V. Podłączony jest poprzez kartę SODIMM 200 pin, 1,8 V i tego typu złącze zostało umieszczone na płycie głównej kasownika NV1.

Mikrokomputer Raspberry Pi CM4 wyposażony jest w procesor BCM2711, czterordzeniowy Cortex A72 taktowany z częstotliwością 1,5 GHz. Użyto wersji z 1 GB pamięci RAM oraz 8 GB eMMC. Układ ten posiada 28 wejść GPIO, dlatego konieczna była rezygnacja z interfejsu DPI na rzecz HDMI. Układ SoM CM4 podobnie jego poprzednik wyposażony jest w interfejsy I2C, UART i dźwiękowy. Dostępny jest tylko jeden port USB.

Układ został uzupełniony o moduł nadawczo-odbiorczy warstwy fizycznej Ethernet. Zaletą tego układu są jego wymiary zbliżone do CM3 oraz sposób zasilania (układ wymaga jedynie zasilania 5 V).

Jak już wspomniano w trakcie poszukiwań zamienników rozważono uwzględnienie standardów SMARC oraz Qseven. Drugi z nich był zbyt duży gabarytowo i nie nadawał się do zastosowania w kasowniku. Podczas rozmów z dystrybutorami okazało się, że gwarantowaną perspektywę dostępności ma moduł MSC SM2S-IMX8NANO. Zaletą zastosowania tego modułu jest jego kompatybilność (a tym samym adaptera oraz płyty głównej) z każdym innym rozwiązaniem SMARC. Układ SoM zgodne z tym standardem cechują się niskim poborem mocy zaczynają-

Rys. 5. Płyta główna z zamontowanym mikrokomputerem CM4 Fig. 5. Mainboard with CM4 installed

cym się od kilku watów oraz niewielkimi i ściśle zdefiniowanymi wymiarami: 82 mm × 50 mm i 82 mm × 80 mm. Płytki drukowane (PCB) modułów mają 314 wyprowadzeń, które współpracują z nisko profilowym złączem kątowym o rozstawie 0,5 mm. Standaryzacja złącza jest pożądaną cechą, ponieważ umożliwia stworzenie adaptera, który obsłuży wiele alternatywnych rozwiązań, a nie tylko jeden model czy rodzinę modeli od konkretnego producenta.

Układ CoreBoard PICO3288-LVDS [11] używa procesora Rockchip RK3288K, zawierającego cztery rdzenie taktowane z częstotliwością 1,8 GHz. Mikrokomputer dysponuje 2 GB pamięci RAM oraz 8 GB eMMC. Układ produkowany jest w dwóch wersjach, jedna z interfejsem graficznym LVDS, druga z DPI. Druga wersja jest bardziej dostępna. Układ ma co najmniej trzy porty USB, a jego wymiary są zbliżone do wymiarów modułu CM3.

Układ Avnet MSC SM2S-IMX8NANO [12] to kolejne akceptowalne rozwiązanie sprzętowe dla komputera sterującego. Moduł ten został zbudowany w oparciu o procesor I.MX 8M zawierający dwa rdzenie Cortex-A53 taktowane z częstotliwością 1,4 GHz. Układ jest wyposażony w 1 GB RAM, 8 GB eMMC oraz wiele peryferii, z których najważniejsze to LVDS, UART, I2C, cztery porty USB oraz Ethernet. Wykorzystywane jest podobne złącze SODIMM, ale zastosowano inną kolejność wyprowadzeń oraz standard zasilania 1,8 V (w CM3 2,5 V). Wymusiło to zaprojektowanie kolejnej płyty PCB przejściowej zapewniającej z jednej strony integrację z modułem Avent, a z drugiej – z płytą główną. Kluczowa była tutaj translacja poziomów logicznych sygnałów cyfrowych, ponieważ moduł Avnet pracuje w standardzie 1,8 V, a płyta główna 3,3 V.

Dla układu scalonego FT232RQ nie znaleziono zamiennika, który nie wymagałby modyfikacji płyty głównej kasownika. Wybrano układ CP2102 [14] kierując się głównie jego dostępnością, funkcjami oraz kompatybilnością z istniejącym rozwiązaniem. Najważniejsze cechy układu CP2102 to: zintegrowany układ nadawczo-odbiorczy USB, −zintegrowany oscylator, −kompatybilność ze standardem USB 2.0, −obsługa podstawowych formatów danych UART.

Układ ten ma inne wyprowadzenia i obudowę niż układ FT232RQ, co wymusiło zmiany w płycie głównej kasownika.

Podłączenie zamiennika mikrokomputera związane było z przygotowaniem odpowiedniego adaptera. Głównymi założeniami projektowymi dla płyty pośredniczącej między układem SoM a płytą główną były: zachowanie mechanicznej kompatybilności ze złączem SODIMM jak i układem SoM, zachowanie wymiarów zewnętrznych, które umożliwią montaż SoM w obudowie kasownika, zapewnienie przekazywania cyfrowych sygnałów sterujących (na które składają się głównie sygnały interfejsów komunikacyjnych) między SoM a płytą główną, −zapewnienie prawidłowego zasilania modułu, −umożliwienie przekształcenia sygnału video w standardzie HDMI na sygnał LVDS.

W trakcie konstrukcji najtrudniej było spełnić ostatni warunek, ponieważ konieczność zastosowania wielu dodatkowych elementów elektronicznych podnosi koszt materiałowy.

Zaprojektowany adapter dla mikrokomputera CM4 (Rys. 5) spełnia wszystkie powyższe założenia oraz cechuje się niewielkimi wymiarami. Dzięki temu całość rozwiązania umieszczono w pierwotnej obudowie, która nie była przygotowana na tego rodzaju modyfikacje.

Implementacja adaptera dla mikrokomputera CoreBoard PICO3288-LVDS (Rys. 6) była ułatwiona z powodu wymiarów modułu SoM. Jego całkowity gabaryt wraz z adapterem pozwolił na umieszczenie go w obudowie kasownika. Głównym problemem było przeniesienie sygnałów interfejsu LVDS do złącza graficznego na płycie głównej. W tym celu wykorzystano nieużywane wcześniej w CM3 złącze do interfejsu kamery. Płyta główna została doposażona w odpowiednie zworki, które w danym wariancie montażowym umożliwiają wybór odpowiedniego połączenia, ponieważ dla niektórych komputerów korzystniej jest bezpośrednio łączyć interfejs LVDS z wyświetlaczem (nie wymaga to dodatkowego przekształcenia DPI-LVDS). Adapter ma złącze SODIMM 200 kompatybilne ze złączami rodziny komputerów jednopłytkowych Colibri-arm-family, które w przyszłości mogą być kolejnymi zamiennikami SoM.

Płyta przejściowa w standardzie SMARC między MSC SM2S-IMX8NANO a płytą główną kasownika (Rys. 7) była najtrud-

Rys. 6. Płyta główna z modułem adaptera dla CoreBoard PICO3288-LVDS

Fig. 6. Mainboard with adapter module for CoreBoard PICO3288-LVDS

Rys. 7. Płyta główna z zamontowanym modułem adaptera w standardzie SMARC Fig. 7. Mainboard with SMARC standard adapter module installed

niejsza w realizacji. Wymiary samego modułu i złącza SMARC okazały się na tyle duże, że niezbędne było odpowiednie zaplanowanie i rozłożenie ich na płycie adaptera. Konieczne było również dostosowanie poziomów napięć linii GPIO i interfejsów UART i I2C mikrokomputera (1,8 V) do poziomów napięć tych sygnałów na płycie głównej (3,3 V).

Dostosowanie płyty głównej do płyt adapterów wiązało się z problemami zarówno natury mechanicznej jak i elektrycznej. Podstawowym problemem mechanicznym była konieczność zmieszczenia się z płytą adaptera w ograniczonej przestrzeni obudowy urządzenia. Kolejnym było podparcie i umocowanie płyty adaptera w dodatkowych punktach. Masa zamienników komputera sterującego okazała się większa od masy nominalnego układu CM3. Spowodowało to konieczność wzmocnienia całości i rozłożenia dodatkowej masy. Modyfikacje te przedstawiono na Rys. 8.

Ostatnią z dokonanych zmian w połączeniach PCB płyty głównej było przystosowanie jej do zamontowania alternatywnego układu dla FT232RQ. W tym celu wykorzystano dolną warstwę, na której umieszczono odpowiednie wyprowadzenia dla układu CP2102.

Równolegle do opisanych powyżej zmian układowych prowadzone były prace programistyczne. Możliwe to było dzięki oferowaniu przez producentów płytek rozwojowych oraz kilku sztuk innych układów, które były dostępne bezzwłocznie i pozwoliły na przygotowanie prototypów układów wraz z oprogramowaniem. Prace programistyczne obejmowały: dostosowanie systemu operacyjnego Linux (konfiguracja systemu obejmująca sterowniki dla nowych układów), konfigurację aplikacji w celu integracji z nowymi układami, testy aplikacji i współdziałania wszystkich komponentów oraz zmiany wynikające z otrzymanych wyników.

7. Wnioski

Rys. 8. Dodatkowe punkty podparcia (mocowania) płyty adaptera na płycie głównej Fig. 8. Additional mounting holes for the adapter board on the mainboard

Rys. 9. Widok płyty głównej z układem CP2102

Fig. 9. View of the mainboard with the CP2102 chip

Doświadczenia przedstawione w powyższym studium przypadku pokazują, że: projektując nowe urządzenie należy określić jego najważniejsze elementy, a następnie zbadać ich dostępność aktualną oraz w przyszłości, −w miarę możliwości należy zadbać o redundancję najważniejszych układów, wskazane jest wybieranie do projektu elementów w typowych obudowach oraz spełniających przyjęte standardy (jak SMARC czy Qseven), produkowanych przez więcej niż jednego producenta; dzięki temu znalezienie zamiennika lub alternatywnego dostawcy staje się bardziej prawdopodobne, kryterium dostępności układu, a w szczególności jego dynamiczna zmienność jest głównym ryzykiem utrzymania ciągłości produkcji; deklarowana dostępność nie powinna być głównym kryterium wyboru komponentu, warto uzyskać od producenta gwarancję dostępności, −należy określić konkretne, istotne w danym projekcie, kryteria wyboru alternatywnych komponentów oraz oszacować ich wpływ nie tylko na projekt elektroniczny, ale również na proces produkcyjny, niezbędna jest efektywna komunikacja i współpraca ze wszystkimi uczestnikami projektu (w przedstawionym przypadku informacje od programistów pozwoliły wyeliminować nieodpowiednie rozwiązania już na etapie analizy rynku), w pierwszej kolejności należy zabezpieczyć stany magazynowe elementów programowalnych, dzięki temu nie ma konieczności modyfikacji oprogramowania, jeśli to możliwe oprogramowanie powinno zapewniać jego wysoką przenośność (modułowość, odpowiednia abstrakcja na poziomie sprzętowym), warto z wyprzedzeniem rozważyć prowadzenia dodatkowych prac projektowych związane z możliwością wykorzystania układów alternatywnych.

Globalizacja produkcji oraz nieobserwowane wcześniej na taką skalę jej negatywne skutki będące wynikiem uzależnienia od dostawców z Azji i łańcuchów transportu mogą zachwiać ciągłością produkcji na rynku lokalnym.

Warto mieć to na uwadze planując systemy produkcyjne. Globalizacja, pociągająca za sobą znaczne geograficzne oddalenie poszczególnych składników systemu jest jednocześnie bardzo podatna na zakłócenia (komunikacyjne, ekonomiczne itp.).

Rynek powinien zacząć podążać w kierunku deglobalizacji, ponieważ jego destabilizacja nie jest powolna i nie zmienia się na przestrzeni lat, ale tygodni. Przywrócenie i ustabilizowanie się produkcji i transportu będzie najprawdopodobniej długotrwałe, jeśli obecnie w ogóle możliwe, z uwagi na sytuację geopolityczną. Prace nad kasownikiem typu NV1 pokazują, że w obecnej sytuacji warto z góry przyjąć założenia projektowe, które zmniejszą ryzyko (zastosowanie zamienników, elementów alternatywnych itp.).

Artykuł powstał w oparciu o wyniki realizacji projektu WND-RPPD.01.02.01-20-0141/19 „Inteligentny kasownik –kompleksowe rozwiązanie w transporcie publicznym”.

1. Durlik I., Inżynieria zarządzania, cz. I i II, Wydawnictwo Placet, Warszawa 2004–2005.

2. Epidemia w Chinach rzuca swój cień na rynek elektroniki, „Elektronik”, Nr 3, 2020, str. 20.

3. Komputery jednopłytkowe, „Elektronik”, Nr 7, 2022, str. 20.

4. Kanagachidambaresan G.R., Role of Single Board Computers (SBCs) in rapid IoT Prototyping, Springer, 2021, DOI: 10.1007/978-3-030-72957-8.

5. Pawłowicz G., Metody zapewnienia EMC kasownika biletów według Regulaminu EKG ONZ nr 10.06, „Pomiary Automatyka Robotyka”, R. 25, Nr 3, 2021, 87-93, DOI: 10.14313/PAR_241/87.

6. Microchip, LAN9514, [www.microchip.com/en-us/product/LAN9514].

7. FTDIChip, FT232R – USB UART IC, https://ftdichip.com/products/ft232rq/

8. Texas Instruments, DS90CF383B, [www.ti.com/product/DS90CF383B?keyMatch=DS90CF38 3B&tisearch=search-everything&usecase=GPN].

9. Dokumentacja układu Raspberry Pi Compute Module 3+ Lite https://datasheets.raspberrypi.com/cm/cm3-plus-datasheet.pdf

10. Standardization Group for Embedded Technologies, https://sget.org/

11. Dokumentacja układu CoreBoard PICO3288-LVDS, https://eveo.pl/elektronika-digital-signage/urve-coreboard-pico3288-lvds/

12. Dokumentacja układu MSC SM2S-IMX8NANO

https://embedded.avnet.com/product/msc-sm2s-imx8nano/

13. Dokumentacja układu Raspberry Pi Compute Module 4 [www.raspberrypi.com/products/compute-module-4/?variant=raspberry-pi-cm4001000].

14. Dokumentacja układu CP2102 [www.silabs.com/documents/public/data-sheets/CP2102-9.pdf].

The article presents a description of the case of ensuring the continuity of production of a ticket validator device in the presence of supply shortages in the market for electronic components. The criteria for decision-making and their impact on the design of the ticket validator are considered. Solutions are proposed that can reduce the risk of production stoppage by using replacements for missing components, taking into account the minimization of the cost of such changes.

Keywords

ORCID: 0000-0002-6121-9888

Informacje dla Autorów

Nie drukujemy komunikatów!

Wskazówki dla Autorów Pomiary Automatyka Robotyka

Kwartalnik naukowotechniczny Pomiary Automatyka Robotyka jest indeksowany w bazach BAZTECH, Google Scholar oraz INDEX COPERNICUS w bazie naukowych realizacji idei Otwartej Nauki, naukowo-technicznym Pomiary Automatyka Robotyka. Punktacja Ministerstwa naukowe w kwartalniku Pomiary Automatyka Robotyka wynosi obecnie naukowych i recenzowanych naukowe – automatyka, elektrotechnika i elektronika.

Pomiary Automatyka Robotyka 1. wymieniowego Autora 2. jej powstanie

3. przeniesienie praw

Kalendarium wybranych imprez

Data konferencji

Nazwa konferencji

Informacje dodatkowe

XXVII Konferencja NaukowoTechniczna automation 2023 07–09 / 03 / 2023 10 / 10 / 2022 www: mail:

21 13–16 / 06 / 2023 15 / 01 / 2022 Rumunia www: mail: ecc23admin@euca-ecc.org 26–29 / 06 / 2023

Gliwice www: mail:

22nd 09–14 / 07 / 2023 31 / 10 / 2022

Jokohama www: mail: 19–20 / 07 / 2023

Teneryfa www: mail: info@iceccme.com 7–8 / 09 / 2023

Niderlandy www: mail:

Safety for Technical th 4–6 / 06 / 2024

Ferrara th 27–30 / 08 / 2024 Kyoto th 4–6 / 09 / 2024 Lyon Francja

MONOGRAFIE STUDIA ROZPRAWY Warszawa

Igor

NASZE WYDAWNICTWA

Technical Sciences Quarterly

W numerze:

POMIARY•AUTOMATYKA•ROBOTYKA PA R PAR Informacje dla Autorów – 69 Nasze wydawnictwa – 73 Wydarzenia – Dr h. c. Profesora Janusza Kacprzyka – 74 Kalendarium – 76 jutro – 77 | 78

1/2022 ISSN 1427-9126 Indeks 339512 Cena 25,00 zł w tym 8% VAT 3 Od Redakcji 5 Krok dyskretyzacji nastawy PID w dyskretnym serwomechanizmie 11 17 23 33 41

POMIARY•AUTOMATYKA•ROBOTYKA PA R PAR Informacje dla Autorów 59 Kalendarium 63 Wspomnienie – Profesor Edward Jezierski – 64 Nasze wydawnictwa – 68 | Nasze monografie – 69 70

Technical Sciences Quarterly Measurements Automation Robotics Ponadto:

Technical Sciences Quarterly |

W numerze:

3/2022 ISSN 1427-9126 Indeks 339512 Cena 25,00 zł w tym 8% VAT 3 Od Redakcji 5 17 23 29 37

www.par.pl W numerze:

POMIARY•AUTOMATYKA•ROBOTYKA PA R PAR Informacje dla Autorów – 55 59 60 Kalendarium – | 119

MONOGRAFIE STUDIA ROZPRAWY

Hypersonic Technologies for Launching and Problems of Inertial Navigation

Warszawa 2022

Igor Korobiichuk, Viktorij Mel’nick Volodimir Karachun

Sieć Badawcza Łukasiewicz –

dziedzinach

Zgłoszenie należy przesłać na adres konkurs@piap.lukasiewicz.gov.pl do dnia 31 stycznia 2023 r. Regulamin konkursu i formularz zgłoszeniowy są dostępne na stronie www.piap.pl

Autorzy najlepszych prac otrzymają nagrody pieniężne lub wyróżnienia

w kategorii prac doktorskich: I nagroda 3500 zł II nagroda 2500 zł w kategorii prac magisterskich: I nagroda 3000 zł II nagroda 2000 zł w kategorii prac inżynierskich: I nagroda 2500 zł II nagroda 1500 zł inżynierskie, magisterskie i doktorskie

Organizator konkursu

Akademii