ArticlePDF Available

Agent Structure of Multimodal User Interface to the National Cybersecurity Platform – Part 1

September 2019
Pomiary Automatyka Robotyka 23(3):41-54

DOI:10.14313/PAR_233/41

Authors:

Włodzimierz Kasprzak

Warsaw University of Technology

Maciej Stefańczyk

Warsaw University of Technology

Wojciech Dudek

Warsaw University of Technology

Show all 8 authorsHide

Content uploaded by Maksym Figat

Content may be subject to copyright.

Zezwala się na korzystanie z artykułu na warunkach

licencji Creative Commons Uznanie autorstwa 3.0

1. Wprowadzenie

Termin cyberbezpieczeństwo odnosi się do zbioru zagadnień

związanych z zapewnieniem bezpieczeństwa użytkowania sieci

komputerowych, a w szczególności Internetu. Dotyczy on

zabezpieczenia infrastruktury sieciowej używanej przez agendy

państwa, prywatne korporacje oraz indywidualnych użytkow-

ników przed cyberatakami. Działania związane z cyberbezpie-

czeństwem przede wszystkim koncentrują się na zapobieganiu

cyberatakom, ale jeżeli one już nastąpią, to na maksymalnym

ograniczeniu ich skutków. Podstawowym celem jest zapobiega-

nie wyciekom danych oraz udaremnianie ataków polegających

na uniemożliwianiu realizacji usług dostarczanych przez sieć.

Stopień zależności współczesnych państw od systemów telein-

formatycznych osiągnął taki poziom, że przypadkowe lub zamie-

rzone uszkodzenie tej infrastruktury może pociągnąć za sobą

Autor korespondujący:

Cezary Zieliński, c.zielinski@ia.pw.edu.pl

Artykuł recenzowany

nadesłany 15.07.2019 r., przyjęty do druku 16.09.2019 r.

Agentowa struktura wielomodalnego interfejsu

do Narodowej Platformy Cyberbezpieczeństwa,

część 1.

Włodzimierz Kasprzak, Wojciech Szynkiewicz, Maciej Stefańczyk, Wojciech Dudek, Maksym Figat,

Maciej Węgierek, Dawid Seredyński, Cezary Zieliński

Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Instytut Automatyki i Informatyki Stosowanej, Nowowiejska 15/19,

00-665 Warszawa

Streszczenie: Ten dwuczęściowy artykuł przedstawia interfejs do Narodowej Platformy

Cyberbezpieczeństwa (NPC). Wykorzystuje on gesty i komendy wydawane głosem do sterowania

praca platformy. Ta część artykułu przedstawia strukturę interfejsu oraz sposób jego działania,

ponadto prezentuje zagadnienia związane z jego implementacją. Do specyfikacji interfejsu

wykorzystano podejście oparte na agentach upostaciowionych, wykazując że podejście to może

być stosowane do tworzenia nie tylko systemów robotycznych, do czego było wykorzystywane

wielokrotnie uprzednio. Aby dostosować to podejście do agentów, które działają na pograniczu

środowiska fizycznego i cyberprzestrzeni, należało ekran monitora potraktować jako część

środowiska, natomiast okienka i kursory potraktować jako elementy agentów. W konsekwencji

uzyskano bardzo przejrzystą strukturę projektowanego systemu. Część druga tego artykułu

przedstawia algorytmy wykorzystane do rozpoznawania mowy i mówców oraz gestów, a także

rezultaty testów tych algorytmów.

Słowa kluczowe: Narodowa Platforma Cyberbezpieczeństwa, rozpoznawanie obrazu, rozpoznawanie gestów, rozpoznawanie mowy, rozpoznawanie mówcy

katastrofalne skutki. Dlatego potrzebne są narzędzia służące

wykrywaniu, zapobieganiu oraz minimalizacji skutków działań

naruszających bezpieczeństwo infrastruktury teleinformatycznej

istotnej dla funkcjonowania państwa oraz jego obywateli. W tym

celu tworzona jest Narodowa Platforma Cyberbezpieczeństwa

(NPC), która umożliwi bieżące monitorowanie funkcjonowania

sieci oraz zapewni koordynację w skali kraju działań służących

wykrywaniu i zapobieganiu niepożądanym sytuacjom w cyber-

przestrzeni. Mowa tutaj o sieciach wykorzystujących protokoły

TCP/IP, mobilnych sieciach bezprzewodowych, sieciach two-

rzących Internet Rzeczy (IoT) oraz sieciach automatyki prze-

mysłowej.

Narodowe centra cyberbezpieczeństwa powstały w większości

państw wysokorozwiniętych, np. w Wielkiej Brytanii, USA czy

Holandii [1–3]. Ich zadaniem jest monitorowanie, gromadzenie

i analiza danych o podatnościach, zagrożeniach i naruszeniach

cyberbezpieczeństwa oraz zapobieganie cyberatakom i reago-

wanie na incydenty na poziomie państwa. Przykładem systemu

monitorowania bezpieczeństwa sieci jest prototypowy system

SEQUESTOR zainstalowany w Pacic Northwest National

Laboratory (USA) [5]. System korzysta z wielu źródeł danych,

w tym programów antywirusowych, narzędzi sieciowych, analizy

zdarzeń systemowych i ruchu sieciowego. Integracja danych z tak

różnorodnych źródeł stanowi prawdziwe wyzwanie projektowe.

Szczególnie istotna jest czytelna prezentacja tych danych, a to

się łączy bezpośrednio ze sterowaniem przez operatorów sys-

Pomiary Automatyka Robotyka, ISSN 1427-9126, R. 23, Nr 3/2019, 41–54, DOI: 10.14313/PAR_233/41

temu, jak dane mają być przedstawione. Kompleksowa analiza

pracy sieci wymaga wykrywania korelacji zachodzących zdarzeń,

analizy sytuacyjnej oraz dynamicznej i statycznej analizy ryzyka.

Aby narzędzie do takiej analizy było użyteczne, potrzebne są

odpowiednie metody i techniki do wizualizacji wielowymiaro-

wych danych [29, 30].

W systemie SEQUESTOR wizualizacja danych została zor-

ganizowana za pomocą SEQViz [5]. Dane są przedstawiane gra-

cznie w postaci dwóch skoordynowanych widoków: ogólnego

widoku sieci (w postaci grafu) oraz widoku modelu behawio-

ralnego. Modele są wzorcami anomalii, czyli zachowań wska-

zujących na potencjalne zagrożenie lub atak. Aby wspomóc

analityków sieci w wykrywaniu wzorców w danych dotyczą-

cych działania sieci i wykrywaniu anomalii opracowano panel

BubbleNet do ich wizualizacji [21]. Panel ten przedstawia dane

w różnych widokach: widoku lokalizacji w postaci mapy z prze-

strzenną informacją zakodowaną z użyciem tzw. pseudo-karto-

gramów Dorlinga [7], widoku czasowego w postaci wykresów

słupkowych oraz widoku atrybutów przedstawiających gracznie

różne atrybuty danych.

W pracy [12] przedstawiono wizualny system interaktywny do

wykrywania anomalii w danych czasoprzestrzennych zebranych

z różnych źródeł danych strumieniowych. Interaktywny interfejs

graczny użytkownika tego systemu składa się z ośmiu głównych

widoków, w tym makro- i mikromapy, widoku czasowego wzorca

oraz widoku inspekcji cech. Użytkownik za pomocą myszki może

wybrać obszar na makromapie i wyświetlić na mikromapie listę

anomalii wykrytych dla tego obszaru. Może również wykonać

operacje powiększania i przesuwania oraz zmiany trybu wyświe-

tlania na obu mapach.

System VisIDAC [32] umożliwia w czasie rzeczywistym

wizualizacje 3D danych o zdarzeniach dotyczących cyberbez-

pieczeństwa, zebranych przez systemy wykrywania włamań zain-

stalowane w różnych sieciach. Dane o zdarzeniach są wyświetlane

w postaci gracznej na trzech panelach: dla wejściowego, wyj-

ściowego i docelowego ruchu sieciowego. W celu łatwego rozróż-

nienia rodzajów zdarzeń są stosowane różne kształty i kolory.

Opracowanie systemu do monitorowania sieci pod kątem

jej cyberbezpieczeństwa pociąga za sobą konieczność stworze

nia wielomodalnego interfejsu operatora umożliwiającego mu

inteligentne sterowanie obrazowaniem zjawisk zachodzących

w cyberprzestrzeni. Niniejszy artykuł poświęcony jest opisowi

takiego interfejsu, który umożliwia sterowanie zobrazowaniem

za pomocą głosu i gestów operatora. Gesty tworzone są przez

operatora – ruchy sylwetki, rąk i głowy. Oprogramowanie do

rozpoznawania mowy i werykacji mówcy zapewnia bezpieczny

sposób zadawania komend głosowych przez uprzywilejowanego

operatora systemu obrazowania.

Prace badawcze poświęcone wielomodalnym interfejsom czło-

wiek-komputer są prowadzone od ponad 40 lat [15, 16, 23, 33].

Celem tych badań jest opracowanie metod i technik interakcji

ludzi z komputerem w pełni wykorzystujących sposoby natu-

ralnej komunikacji i interakcji człowieka z otoczeniem. Inter-

fejsy wielomodalne charakteryzują się dwiema podstawowymi

cechami: łączeniem wielu typów danych oraz przetwarzaniem

tych danych w czasie rzeczywistym przy określonych ogranicze-

niach czasowych [15].

Sposób prezentacji operatorowi oraz analitykom zebranych

danych o działaniu sieci w istotny sposób wpływa na efektyw-

ność ich pracy. Wielomodalny interfejs umożliwia im dostosowa-

nie sposobu prezentacji do ich wymagań. Sterowanie prezentacją

danych za pomocą komend głosowych i gestów umożliwia

obsługę systemu przez osoby, które nie zostały specjalnie do

tego przeszkolone, a co więcej, ułatwia prezentację stanu sieci

osobom podejmującym decyzje, które nie muszą być zaznajo-

mione ze sposobem działania interfejsu. Do codziennej obsługi

systemu przez przeszkolony personel używane będą standardowe

urządzenia wejściowe, takie jak klawiatury i myszki. Ponadto

interfejs umożliwia rozpoznanie mówcy i automatyczną jego

autoryzację w systemie.

Ten artykuł poświęcony jest sposobowi tworzenia interfejsu do

Narodowej Platformy Cyberbezpieczeństwa (NPC), ale sposób

ten może być wykorzystany także do budowy innych interfejsów.

Ogólne metody tworzenia oprogramowania są określone przez

inżynierię oprogramowania [28]. Niewątpliwie należy się do nich

stosować, ale konkretne systemy mają swoją specykę, która

również wpływa na architekturę powstającego oprogramowania.

Interfejs stanowi styk między otoczeniem zycznym, w którym

znajduje się operator, a platforma NPC. Podobne cechy mają

systemy robotyczne, które także operują w środowisku zycz-

nym, z jednej strony wpływając na nie, a z drugiej pozyskując

z niego informacje. Podobnie interfejs oddziałuje na operatora,

z jednej strony przekazując mu niezbędne dane, a z drugiej

pozyskuje od niego informacje, jak konkretnie ma platforma

zaprezentować zebrane dane. Dlatego postanowiono skorzystać

z bogatego doświadczenia w konstrukcji systemów sterowania

robotami i zastosować podejście wykorzystujące agenty upo-

staciowione [37–40] zarówno do specykacji jak i implementa-

cji interfejsu. Prezentacja tej metody zastosowanej do budowy

interfejsu jest głównym celem tego artykułu.

2 Wymagania i ogólna koncepcja

rozwiązania

W procesie projektowania systemu pierwszym krokiem jest jego

wyodrębnienie ze środowiska. Tutaj system stanowią platforma

NPC wraz z przedstawianym tu interfejsem do niej. Założono,

że kontakt operatora z systemem będzie najbardziej naturalny,

jeżeli będzie się można z nim porozumiewać tak, jak ludzie

porozumiewają się ze sobą, a więc za pomocą głosu i gestów.

Dlatego interfejs NPC wyposażono w kamery i mikrofony.

Ponadto operator w procesie powoływania systemu do życia

musi go skongurować, a następnie nim administrować. W tym

celu używa standardowych urządzeń wejściowych komputera,

takich jak myszka, klawiatura czy ekran dotykowy (touch-

pad). Informacja zwrotna wytwarzana przez system przed-

stawiana jest na ekranie monitora, a konkretnie w okienkach

pojawiających się na nim, a ponadto interakcja następuje za

pomocą kursorów przemieszczanych po ekranie. Przyjęto, że

operator działa w środowisku zycznym rozszerzonym o ekran

monitora. System porozumiewa się z operatorem za pomocą

wymienionych urządzeń i okienek pojawiających się na ekra-

nie. Z uwagi na fakt, że dotychczas operator kontaktował się

z platformą NPC za pomocą urządzeń wejściowych, takich

jak: ekrany dotykowe, myszki lub klawiatury, przyjęto iż inter

fejs będzie przekształcał komendy głosowe i te wydawane za

pomocą gestów do formatu komend wprowadzanych z urzą-

dzeń wejściowych.

Gesty związane są z ruchem rąk, a więc obrazy uzyskiwane

z kamer muszą być zbierane z dostatecznie dużą częstotliwością.

Przyjęto, że przetwarzanie zarówno obrazów jak i mowy powinno

być na tyle szybkie, by dla operatora czas między wydaniem

komendy a inicjacją jej wykonywania był niezauważalny. W ana-

lizie mowy powstaje opóźnienie między zakończeniem wypowia-

dania komendy a wynikiem analizy. Przyjęto, że dopuszczalne

opóźnienie wynosi 1 s, gdyż po zakończeniu wypowiedzi trzeba

odczekać, aby zdecydować, czy pojawi się pauza czy wypowiedź

będzie kontynuowana. Na to potrzeba około 200 ms, a do tego

dochodzi jeszcze czas analizy polecenia. W przypadku przetwa-

rzania obrazu użytkownik współpracuje dużo ściślej z systemem

– sterując położeniem kursora oczekuje dużo szybszych reakcji

i ciągłości jego przemieszczania. Z tego względu przyjęto, że

Agentowa struktura wielomodalnego interfejsu do Narodowej Platformy Cyberbezpieczeństwa, część 1.

POMIARY•AUTOMATYKA•ROBOTYKA NR 3/2019

analiza obrazu powinna odbywać się z szybkością co najmniej

20 klatek na sekundę, natomiast opóźnienie reakcji nie powinno

być większe niż 100 ms.

Struktura interfejsu operatora musi być dostosowana do wyżej

sformułowanych wymagań. Ponieważ interfejs jest kongurowany

za pomocą standardowych urządzeń wejściowych komputera lub

pobudzany do działania przez operatora wydającego komendy

głosowe lub gestykulacje, a ponadto oddziałuje na operatora

wyświetlając dane, można jego strukturę określić za pomocą

agentów upostaciowionych [18, 36], które realizują swoje zadanie

zbierając dane z otoczenia za pomocą receptorów, by przekształ

cić je na oddziaływania na to otoczenie za pomocą efektorów.

Należy jedynie adekwatnie zdeniować receptory i efektory inter-

fejsu. Dotychczas agenty upostaciowione były wykorzystywane

do tworzenia systemów sterowania systemami robotycznymi [37–

40]. Niniejszy artykuł pokazuje ich użyteczność w projektowaniu

systemów, które nie są związane z robotyką.

3. Agenty upostaciowione

W klasycznym podejściu agent deniowany jest jako twór dzia-

łający autonomicznie, postrzegający swoje środowisko, mający

charakter trwały, a ponadto mający zdolność do dostosowy-

wania się do zmian w swoim środowisku, a co więcej mogący

przejąć cel innego agenta [26]. Niemniej jednak tutaj przyjęto

denicję bardziej zwięzłą, a jednocześnie ogólniejszą. Przyjęto,

że agent jest tworem dążącym do realizacji zadania, postrze-

gającym swoje środowisko i wpływającym racjonalnie na nie.

Zadanie stanowi wewnętrzny imperatyw agenta do działania.

Jest ono realizowane w środowisku, zgodnie z aktualnie panu-

jącymi w nim warunkami, dzięki informacji uzyskiwanej z oto-

czenia. Tam gdzie środowisko ma charakter zyczny, agent

oddziałuje na nie przez swoje efektory i postrzega je za pomocą

swoich receptorów. Agent działający w zycznym otoczeniu

musi mieć zyczną powłokę (postać), by na nie oddziaływać.

W związku z tym zwykło się go zwać agentem upostacio-

wionym [18, 36]. Agentowa struktura systemu będzie okre-

ślona dalej. Tutaj wystarczy zauważyć, że działania operatora

działającego w środowisku rejestrowane są za pomocą takich

receptorów jak kamery czy mikrofony, natomiast system NPC

oddziałuje na operatora, traktowanego jako element otocze-

nia, poprzez okienka oraz kursory pojawiające się na obrazie

wyświetlanym na ekranie monitora, a więc zarówno okienka

jak i kursory mogą być traktowane jako efektory. Wewnętrz-

nym imperatywem systemu jest rozpoznawanie komend opera-

tora i przekształcanie ich w odpowiednie zobrazowanie danych.

Wykorzystanie agentów do określenia struktury systemu ma

tę zaletę, że można użyć formalnej notacji, opracowanej spe-

cjalnie do opisu zarówno struktur systemów, jak i sposobów ich

działania. Główne elementy tej notacji zostaną opisane poniżej.

Agent aj, gdzie j jest jego oznaczeniem, składa się z: efekto-

rów rzeczywistych E

oddziałujących na środowisko (w przy-

padku interfejsu NPC są to okienka oraz kursory pojawiające

się na ekranie monitora), rzeczywistych receptorów Rj (ściśle

mówiąc chodzi o eksteroceptory, gdyż proprioceptory sprzężone

są bezpośrednio z efektorami) zbierających dane o stanie otocze-

nia oraz systemu sterowania Cj realizującego zadanie przez

wpływanie na efektory na podstawie odczytów uzyskiwanych

z receptorów (w interfejsie NPC są nimi mikrofony i kamery).

System sterowania Cj składa się z trzech typów podsystemów:

wirtualnych efektorów e

, wirtualnych receptorów r

oraz

podsystemu sterowania c

. Agent może zawierać wiele recep-

torów rzeczywistych R

j,l

i wiele receptorów wirtualnych r

j,k

, gdzie

l i k są ich oznaczeniami. Podobnie w jego skład może wchodzić

wiele efektorów rzeczywistych E

j,m

i wiele efektorów wirtualnych

j,n

, gdzie m i n są ich oznaczeniami. Wirtualne efektory e

j,n

i receptory rj,k prezentują podsystemowi sterowania cj urządze-

nia wykonawcze i środowisko w postaci właściwej do określenia

sposobu realizacji zadania – w tym przypadku są to polecenia

dotyczące sposobu prezentacji wyników analizy, które ma wyko

nać platforma NPC. Wirtualne efektory dokonują transformacji

złożonych poleceń na elementarne rozkazy sterujące sprzętem

(w przypadku NPC są to okienka i kursory), natomiast wirtu-

alne receptory przekształcają odczyty z czujników (w przypadku

NPC są to zapisy dźwięku i obrazy) na abstrakcyjne pojęcia nie-

zbędne do zwięzłego wyrażenia realizowanego zadania. Agenty

mogą się również komunikować między sobą. Na rys. 1 przedsta-

wiono wewnętrzną strukturę agenta upostaciowionego.

Podsystemy agenta aj, a więc: podsystem sterowania cj, wir-

tualne efektory e

j,n

, wirtualne receptory r

j,k

, rzeczywiste efek-

tory Ej,m i rzeczywiste receptory Rj,l (rys. 1), kontaktują się ze

sobą przez bufory komunikacyjne. Bufory oznaczane są przed-

nim indeksem dolnym: x – wejściowe, y – wyjściowe, nato-

miast pamięć wewnętrzna podsystemu pozbawiona jest takiego

indeksu. Górny lewy indeks przy oznaczeniu bufora określa typ

podsystemu, z jakim ten bufor współpracuje.

Wszystkie podsystemy agenta działają według tego samego

wzorca [37–40]. Każdy zawiera automat skończony FSM (ang.

Finite State Machine), z którego stanami skojarzono zachowa-

nia. Każde zachowanie jest sparametryzowane funkcją przejścia

oraz warunkami końcowymi i błędu. Zachowanie jest powtarzane

do momentu spełnienia dowolnego z wymienionych warunków.

Zakończenie wykonania zachowania powoduje przejście auto-

matu skończonego do stanu następnego, który jest wybierany na

podstawie warunków początkowych etykietujących łuki skiero-

wane grafu automatu. Czynności związane z zachowaniem zależą

od postaci funkcji przejścia. Funkcja ta pobiera dane z buforów

wejściowych oraz pamięci wewnętrznej podsystemu i oblicza

nowe wartości dla buforów wyjściowych oraz pamięci wewnętrz-

nej. Zachowanie, oprócz obliczenia funkcji przejścia, zajmuje się

wczytaniem nowych wartości do buforów wejściowych oraz roze-

słaniem danych z buforów wyjściowych do innych podsystemów.

Rys. 1. Ogólna struktura agenta upostaciowionego

Fig. 1. General structure of an embodied agent

W. Kasprzak, W. Szynkiewicz, M. Stefańczyk, W. Dudek, M. Figat, M. Węgierek, D. Seredyński, C. Zieliński

4. Zadania interfejsu i kategorie jego

operatorów

Interfejs do systemu obrazowania informacji NPC odgrywa trzy

role, w zależności od kategorii operatora, z którym wchodzi

w interakcje. Umożliwia:

− użytkownikowi (np. kierownikowi NPC) dogodne sterowanie

wizualizacją informacji tworzonej przez platformę NPC,

− serwisantowi kongurację danej instalacji interfejsu,

−

administratorowi systemu zarządzanie zasobami (danymi

o gestach, osobach i komendach głosowych) oraz tworzenie

modeli: gestów, komend głosowych i użytkowników.

Role te związane są z trzema różnymi aspektami (trybami)

pracy interfejsu: sterowanie, kongurowanie, administrowanie

(tworzenie modeli i zarządzanie danymi).

Użytkownik za pomocą interfejsu zleca platformie wykonanie

swoich poleceń, a więc przedstawienie danych w odpowiedni

sposób. Serwisant zajmuje się kongurowaniem sprzętu i para-

metryzacją oprogramowania do analizy obrazów i mowy. Kon-

guracja sprzętowo-programowa każdego z modułów interfejsu

polega na doborze jego parametrów wewnętrznych dla danej

instalacji systemu. Administrator zarządza modelami gestów,

poleceń i użytkowników, ale przede wszystkim dostarcza dane

treningowe i uruchamia uczenie się systemu (tworzenie modeli).

Odnosi się to zarówno do zarządzania informacją dotyczącą

użytkowników systemu, jak i danych dotyczących poleceń, które

system może zrealizować. W tym pierwszym przypadku do sys-

temu można wprowadzać nowych użytkowników bądź usuwać

tych wcześniej wprowadzonych oraz edytować dane użytkownika.

W drugim przypadku można dodawać i usuwać polecenia oraz

je modykować (edytować).

Uczenie w systemie zastosowano do zdeniowania następu-

jących przyporządkowań: gestów poleceniom, instrukcji wyda-

wanych głosem komendom oraz rozpoznawania mówcy w celu

określenia jego uprawnień. Przewidziano, że użytkownicy róż-

nej rangi będą mieli różne uprawnienia do wydawania poleceń

systemowi. Proces uczenia odbywa się w dwóch fazach. Wpierw

zbierane są próbki o właściwej postaci, a następnie uczony jest

odpowiedni klasykator. Nadzór nad procesem uczenia spoczywa

na administratorze systemu.

Sterowanie polega na rozpoznawaniu poleceń użytkownika

wydawanych głosem lub gestem. Polecenia te są przekształ-

cane w bodźce zazwyczaj generowane przez myszkę (ruch kur-

sora, kliknięcie), klawiaturę (wciśniecie klawisza) bądź ekran

dotykowy (dotknięcia). Bodźce te oddziałują na okienka repre-

zentowane agentami lub na inne programy uruchomione na

komputerze. Są one przez te agenty lub programy interpreto-

wane, przykładowo jako: obrót obrazu, zbliżenie lub oddalenie

widoku wyświetlanego w oknie (zoom). Agenty reprezentujące

okna mogą być częściami modułów interfejsu lub platformy.

Interfejs przekształca gesty oraz komendy wydawane głosem na

polecenia dla platformy.

5. Modułowa struktura interfejsu

System NPC (rys. 2) składa się z platformy, która zbiera dane

o aktywności w sieci, analizuje je i prezentuje wyniki, oraz

z interfejsu, za pomocą którego użytkownik instruuje plat-

formę, w jaki sposób te wyniki powinny zostać zaprezentowane.

Aby móc sterować prezentacją wyników analizy, interfejs musi

być odpowiednio skongurowany i zarządzany. Tutaj skoncen-

trowano się jedynie na sposobie konstrukcji interfejsu. Zawiera

on trzy moduły: prezentacji, wizyjny i audio.

Każdy moduł skomponowany jest z agentów. Liczba modu-

łów wynika ze sposobu interakcji operatora z interfejsem oraz

sposobu interakcji interfejsu z platformą NPC. Użytkownik

może wydawać polecenia albo za pomocą głosu albo za pomocą

gestów, a więc istnieją dwa oddzielne źródła poleceń, a co za tym

idzie dwa odrębne moduły je przetwarzające: audio i wizyjny.

Niezależnie od źródła, wydawane polecenia muszą wpływać

bezkoniktowo na działanie platformy NPC. Dlatego pojedyn-

czy dysponent platformy, agregujący polecenia otrzymywane

z różnych źródeł, jest optymalny – jest nim moduł prezentacji.

W konsekwencji powstała trójmodułowa struktura interfejsu.

Moduł wizyjny służy do przetwarzania poleceń wydawanych

gestami, natomiast moduł audio zajmuje się komendami wyda-

wanymi głosem i identykacją mówcy. Moduł prezentacji jest

odpowiedzialny za agregację rozkazów pochodzących z modułów

przetwarzających polecenia użytkownika (tzn. modułów wizji

i audio). Efektem działania tego modułu jest selekcja polecenia

operatora, które ma być przekazane platformie do realizacji.

Opracowany interfejs umożliwia wydawanie poleceń za

pomocą głosu i gestów, które muszą być przetłumaczone na

postać akceptowaną przez platformę, czyli kody generowane

przez tradycyjne urządzenia wejściowe (klawiatura, mysz, ekran

dotykowy itp.). Odbywa się to dwuetapowo. Wpierw moduły

wizyjny i audio zamieniają odpowiednio gesty bądź komendy

głosowe na ich identykatory, a następnie moduł prezentacji

zamienia te identykatory na kody poleceń wydawanych przez

urządzenia wejściowe. Identykatory urządzeń w systemie ope-

racyjnym komputera, w którym uruchomiono interfejs, mogą się

zmieniać. Moduły audio i wizyjny odnoszą się do typów imitowa-

nych urządzeń wejściowych, natomiast moduł prezentacji chcąc

wykonać akcję musi się odwołać do identykatora konkretnego

urządzenia obsługiwanego przez system operacyjny. Identyka-

tor ten jest zmienny i przez to musi być dostarczony modułowi

prezentacji. Interfejs przekazuje prezentowanym oknom infor-

macje o elementarnych zdarzeniach, np. dotyku i przesunię-

ciu palca po ekranie. Informacja ma postać generowana przez

wspomniane urządzenia wejściowe. Sterownik okna interpretuje

te elementarne zdarzenia (a dokładniej sekwencje tych zdarzeń)

powodując np. zoom lub obrót. Założono, że zbiór możliwych

akcji użytkownika (gestów i komend głosowych) jest ustalony

(w przypadku gestów) względnie ograniczony (w przypadku

komend głosowych) przez twórcę systemu. Tablica asocjacji

akcji, utworzona przez projektantów systemu, może być co naj-

wyżej modykowana przez serwisanta systemu, aby ewentual-

nie lepiej dostosować konkretną instalację systemu do potrzeb

danego użytkownika/administratora.

6. Role interfejsu

6.1. Kategorie operatorów interfejsu

Interfejs jest używany przez różne kategorie operatorów zgod-

nie z przypisanymi im rolami. Użytkownicy wykorzystują go do

sterowania sposobem prezentacji danych generowanych przez

platformę. Podstawową formą działania interfejsu jest prze-

kształcanie poleceń użytkownika na pożądany sposób prezen-

Rys. 2. Struktura systemu NPC

Fig. 2. Structure of the NCP system

Agentowa struktura wielomodalnego interfejsu do Narodowej Platformy Cyberbezpieczeństwa, część 1.

POMIARY•AUTOMATYKA•ROBOTYKA NR 3/2019

tacji danych. Metoda sterowania okienkami została opisana

przy okazji prezentacji poszczególnych modułów interfejsu.

Każdy z modułów ma interfejs administracyjno-serwisowy

zawiadujący własnym oknem GUI (ang. Graphical User Inter-

face). Moduł prezentacji wykorzystuje swoje okno do wyświe-

tlania logów otrzymanych z wszystkich trzech modułów oraz

do wysyłania instrukcji do każdego z modułów. W odpowiedzi

na otrzymane z modułu prezentacji instrukcje, moduły wizji

i audio: przechodzą w tryb wstrzymania, wznawiają działanie

po wstrzymaniu lub wczytują nową kongurację.

Administrator modułu audio ma możliwość tworzenia i zarzą-

dzania modelami komend głosowych i mówców. Do tego celu

wykorzystuje interfejs administracyjno-serwisowy, który uak-

tywnia funkcje uczenia modułu audio. Komenda głosowa składa

się z sekwencji 1–3 słów, wypowiadanych w sposób ciągły bez

widocznych przerw między słowami. Pozwala to interpretować

tę sekwencję jako pojedynczą izolowaną frazę zdaniową i rozpo-

znawać ją jako jedną z komend, dla których stworzono model

akustyczny. Model akustyczny komendy ma postać sekwencji

cech krótkookresowych ramek sygnału i jest oparty na cechach

mel-cepstralnych [17] i pochodnych tych cech. Model głosowy

mówcy ma postać mieszaniny rozkładów Gaussa w przestrzeni

cech ramek. Szczegółowe omówienie tych modeli znajduje się

w drugiej części tego artykułu w jego sekcji 2. Rola admini-

stratora modułu audio w procesie tworzenia modeli polega na

zebraniu próbek głosowych odpowiednich komend i mówców,

uruchomieniu procedur uczenia i na zdeniowaniu tablicy aso-

cjacji treści komend i mówcy z numerami klas udostępnia-

nymi przez moduł audio. Administrator jest przy tym świadomy

istnienia tablicy asocjacji komend i ograniczeń, co do maksy-

malnej liczby dostępnych komend i mówców. Jeśli z tablicy

asocjacji komend wynika, że komenda nr 1 służy do wywoła-

nia „pochwycenia” elementu gracznego, to administrator może

nazwać tę komendę jako „pochwyć” lub „drag” lub jeszcze ina-

czej, w sposób zrozumiały dla użytkownika. Wtedy ta klasa

powinna być uczona na podstawie próbek głosowych zawiera-

jących treść „pochwyć” itp.

6.2. Role modułu wizji

Zarządzanie modelami przez administratora modułu wizyj-

nego polega na powiązaniu identykatorów gestów z ich klasą.

Identykatory gestów przekazywane są do modułu prezenta-

cji w trakcie użytkowania interfejsu. Zbiór gestów i ich forma

są ustalone z góry, a system analizy gestów jest dostarczony

w postaci już nauczonej. Administrator nie ma bezpośrednio

możliwości deniowania i uczenia własnych gestów, tak jak

to ma miejsce w przypadku modułu audio. Jednak może zle-

cić serwisantowi lub twórcy systemu wykonanie modykacji

zbioru gestów. Uwzględniając powyższą możliwość, bezpośred-

nie zarządzanie modułem wizji przez administratora polega

jedynie na ewentualnej modykacji tablicy asocjacji gestów,

czyli odwzorowania: moja nazwa gestu ↔ numer/klasa gestu

w module wizji.

Moduł wizyjny, po wczytaniu plików konguracyjnych, przy-

gotowany jest do współpracy z użytkownikiem. Aby sterowa-

nie gestami było skuteczne, użytkownik musi być widoczny dla

kamery. W tym celu moduł wizyjny wyświetla rysunek poka-

zujący, w jakim obszarze powinien stać użytkownik, by móc

sterować systemem, np. kursorami. Kursory to odwzorowanie

dłoni użytkownika na ekran.

Rolą serwisanta systemu wizyjnego jest, oprócz samej sprzę-

towej instalacji systemu, jego wstępna konguracja i kalibracja.

Serwisant wprowadza (w plikach konguracyjnych) położenie

i orientację kamery względem układu współrzędnych ustalonego

dla punktu odniesienia (np. środka ekranu). Wykonuje też kali-

brację stereo-pary kamer w celu uzyskania zestawu parametrów

wewnętrznych (ang. intrinsic parameters) i zewnętrznych (ang.

extrinsic parameters). Do jego zadań należy też wstępne ustawie-

nie parametrów akwizycji tak, aby dopasować je do warunków

oświetleniowych panujących w miejscu instalacji.

6.3. Role modułu audio

Moduł audio sprawuje kontrolę nad okienkami umożliwiają-

cymi administratorowi przełączanie się między następującymi

trybami pracy: trybem zarządzania zasobami (zarządza-

nie poleceniami, użytkownikami oraz nagraniami; zapisywa-

nie plików konguracyjnych i nagrań mowy), uczeniem się

modeli mówców i modeli komend (oraz zapisywaniem modeli

do plików) i trybem sterującym, umożliwiającym rozpoczęcie

rozpoznawania poleceń oraz identykacji użytkowników (wczy-

tanie modeli mówców oraz komend, rozpoczęcie rozpoznawa-

nia komendy/mówcy). Po przejściu w tryb sterowania moduł

audio rozpoczyna nasłuch sygnałów z mikrofonów oczekując na

polecenia wydawane przez użytkownika. W trybie tym identy-

katory rozpoznanych poleceń oraz rozpoznanych użytkowników

są przekazywane do modułu prezentacji.

Administracja modułem audio polega na: wprowadzaniu lub

usuwaniu poleceń, wprowadzaniu lub usuwaniu użytkowników,

nadzorze oraz zlecaniu rejestracji i przechowywania próbek głosu

użytkowników, uaktualnianiu system plików konguracyjnych,

a ponadto uruchamianiu dla danego użytkownika lub polecenia

procesu uczenia. Podczas czynności administracyjnych użytkow-

nik wykonuje polecenia administratora. Na jego żądanie użyt-

kownik podaje swoje dane, umożliwiając w ten sposób swoją

identykację, a następnie przechodzi do nagrywania próbek gło-

sowych. Użytkownik wprowadzony do systemu może wydawać

polecenia modułowi audio. Administrator modułu audio komu-

nikuje się z nim za pomocą okienek GUI, wybierając za pomocą

myszki pola okienek i wprowadzając informację tekstową do

wybranych pól okienek.

6.4. Konfiguracja modułów

Serwisant oddzielnie konguruje każdy z modułów. Konguro-

wanie modułu prezentacji polega na: ustaleniu rozdzielczości

monitora (co wymusza zmianę wielkości emulowanego ekranu

dotykowego), zmianie adresów modułów audio i wizji, zmianie

parametrów emulowanego ekranu dotykowego oraz zmianie

identykatorów przypisanych do bodźców inicjujących akcje

systemu operacyjnego. Każdy identykator określa pewną

akcję, która powinna zostać wykonana na oknie gracznym

platformy NPC. Jest ona wynikiem polecenia otrzymanego od

modułu prezentacji, pobudzonego przez moduł:

− audio, który rozpoznał komendę głosową, lub

− wizji, który rozpoznał gest.

Kongurowanie modułu wizji sprowadza się do:

−

wyboru obszaru, w którym użytkownik będzie mógł wykony-

wać gesty sterujące,

− kalibracji kamer,

−

ustalenia związku między przestrzenią trójwymiarową a jej

dwuwymiarowym zobrazowaniem,

−

modykacji tablicy asocjacji akcji/bodźców (dodawanie lub

usuwanie przyporządkowania rozpoznawanych gestów do iden-

tykatorów akcji/bodźców (i skrótów klawiszowych) genero-

wanych przez imitowane urządzenie wejściowe.

Kongurowanie modułu audio wymaga od serwisanta wyko-

nania następujących czynności:

− instalacji sprzętu,

−

ustawienia parametrów karty akwizycji – wybór kana-

łów akwizycji,

−

ustawienia parametrów akwizycji sygnału audio, czyli:

poziomu szumu, częstotliwości próbkowania, wielkości ramki

sygnału, długości wektora cech itp.,

−

modykacji tablicy asocjacji akcji/bodźców (dodania lub usu-

nięcia przyporządkowania rozpoznawanych komend głosowych

W. Kasprzak, W. Szynkiewicz, M. Stefańczyk, W. Dudek, M. Figat, M. Węgierek, D. Seredyński, C. Zieliński

do identykatorów akcji/bodźców (i skrótów klawiszowych)

generowanych przez imitowaną myszkę.

Część z wymienionych czynności wykonywanych jest przez

serwisanta bezpośrednio na sprzęcie wchodzącym w skład inter-

fejsu.

7. Dekompozycja modułów na agenty

Podstawową jednostką kompozycji interfejsu jest moduł.

Podział na moduły związany jest z trzema podstawowymi

funkcjami, które realizuje interfejs w celu umożliwienia

użytkownikowi łatwej interakcji z platformą NPC. Są nimi:

przekształcanie gestów na polecenia dla platformy NPC, trans-

formacja komend wydawanych głosem na polecenia dla tej

platformy oraz integracją poleceń w celu spójnej prezentacji ich

skutków na ekranie obserwowanym przez użytkownika. Każdy

z tych modułów został skomponowany z agentów. Niektóre

z tych agentów reprezentują okna ukazujące się na ekranie

monitora traktowanego jako element środowiska.

się agentów: (a = prezGUI, b = prez), (a = audioGUI_nr,

b = audio) (gdzie nr ∈ {init, user, command, control}),

(a = visionGUI, b = vision).

Agent generujący bodźce a

OID

(rys. 4) wyposażony jest

w receptory rzeczywiste R

OID,1,g

, takie jak mysz, klawiatura

lub ekran dotykowy – tu zbiorczo oznaczone jako g. Pojedynczy

wirtualny receptor rOID,1 agreguje informacje uzyskane z tych

urządzeń wejściowych. Efektorami rzeczywistymi tego agenta

są kursory, a dokładniej rzecz ujmując, generatory bodźców

zazwyczaj inicjowanych wspomnianymi urządzeniami wejścia.

Agent aOID ma trzy efektory rzeczywiste EOID, d. Dwa efektory

tworzą na ekranie monitora kursory: pierwotny (d= mainPoin-

ter) i wtórny (d = secPointer), a jeden efektor (d = keyExecu-

tor) imituje klawiaturę generując bodźce, takie jak rzeczywista

klawiatura. Informacja do tych trzech efektorów rzeczywistych

dostarczana jest przez efektor wirtualny eOID,1.

Agent a

OID

oraz agenty a

(reprezentujące okna) wchodzą

w interakcje za pośrednictwem stygmergii [6], a więc przez

zastosowanie komunikacji poprzez środowisko, którego czę-

ścią jest ekran monitora. Agenty aa odczytują bodźce genero-

wane przez aOID za pomocą swoich rzeczywistych receptorów

Rα

a,1,↔f

. W tym przypadku receptorami rzeczywistymi Rα

a,1,↔f

są

elementy okna (f) czułe na bodźce zewnętrzne. Przykładowa

interakcja między kursorem a elementami okna realizowana

jest w następujący sposób. Agent aOID wykorzystując jeden ze

swoich rzeczywistych efektorów E

OID,d

(d – element aktywny

wytwarzający bodziec) oddziałuje na rzeczywisty receptor okna

a,1,↔f

(f – element pasywny odbierający bodziec, np. przyciski

lub suwak). Następnie agent aa przekazuje uzyskaną informa-

cję do kolejnego agenta, który zrealizuje akcję wywoływaną

tym bodźcem.

7.1. Moduł prezentacji

Moduł prezentacji utworzony jest z trzech agentów: a

prez

(rys.5), aprezGUI (agent typu aa – rys. 3) i aOID (rys. 4). Komu-

nikację między tymi agentami w module prezentacji przedsta-

wiono na rys. 6.

Podsystem sterowania agenta aprez ma jedynie bufory komuni-

kacji międzyagentowej i pamięć wewnętrzną. Bufory komunika-

cji międzyagentowej umożliwiają interakcję nie tylko z dwoma

pozostałymi agentami modułu prezentacji, ale również z agen-

tami aaudio i avision. Agent aprez wykonuje następujące zadania:

− tłumaczenie gestów otrzymanych od agenta avision na odpo-

wiednie imitacje akcji urządzeń wejścia (myszy, klawiatury,

ekranu dotykowego) i przesyłanie tych zleceń do agenta a

OID

aby ten je zrealizował,

Rys. 3. Ogólna struktura a gentów repreze ntujących okna

urucha miane na ekranie komputera; α – nazwa agenta

reprezentującego okno, β – nazwa age nta, z którym ten a gent się

komunikuje

Fig. 3. General structure of agents representing windows appearing on

the computer screen; α – name of the agent representing the windows,

β – name of the agent with which this agent communicates

Ogólną strukturę agentów reprezentujących okna aa, gdzie

a to substytut nazwy agenta, określa rys. 3. Agentów tego

typu w systemie jest wiele. Rzeczywistymi efektorami E

a, j

każ-

dego takiego agenta są miejsca służące wyświetlaniu informacji

w oknie (j). Ta informacja pojawia się w środowisku i wten

sposób oddziałuje na operatora. Natomiast rzeczywistymi

receptorami R

a,f

tego agenta są obiekty wrażliwe na bodźce

(f) wytwarzane przez efektory agenta a

OID

(ang. Operator

Interface Devices). Agent aa ma po jednym efektorze i recep-

torze wirtualnym, odpowiednio: e

a,1

i r

a,1

. Współpracują one

z wieloma efektorami i receptorami rzeczywistymi: Ea, j, Ra,f.

Liczba receptorów rzeczywistych zależy od liczby pól okna,

z którymi użytkownik może wejść w interakcję (np. przycisk

lub suwak). Natomiast liczba efektorów rzeczywistych zależy

od liczby pól, w których może być wyświetlana informacja.

Agenty okien aa komunikują się bezpośrednio z innymi agen-

tami ab interfejsu. Istnieją następujące pary komunikujących

Rys. 4. St ruktura agenta generującego b odźce; g {mysz, klawi atura,

ekran dotykowy}, δ {mainPointer, secPointer, keyExecutor} agent

ten ma 3 efektory i 3 receptory

Fig. 4. Structure of the agent generating stimulus; g [mouse, keyboard,

touchscreen}; δ {mainPointer, secPointer, keyExecutor} this agent has

3 eectors and 3 receptors

Agentowa struktura wielomodalnego interfejsu do Narodowej Platformy Cyberbezpieczeństwa, część 1.

POMIARY•AUTOMATYKA•ROBOTYKA NR 3/2019

− tłumaczenie identykatorów poleceń otrzymanych od agenta

aaudio na odpowiednie skróty klawiaturowe i przesyłanie ich do

agenta aOID, aby ten je zrealizował,

−

przesyłanie poleceń zmiany trybu pracy do agentów a

vision

i aaudio. Polecenia te podsystem cprez otrzymuje od agenta aprezGUI,

−

przesyłanie logów do agenta a

prezGUI

, aby ten je wyświetlił.

Logi te pochodzą od samego podsystemu cprez oraz od agen-

tów avision i aaudio.

Zadaniem agenta aOID jest wykonywanie odpowiednich ope-

racji za pomocą swych efektorów rzeczywistych EOID,d (kurso-

rów), w celu oddziaływania na inne agenty reprezentujące okna,

poprzez stygmergię. Operacje te wyzwalane są albo poleceniami

agenta a

prez

albo bodźcami generowanymi przez rzeczywiste

receptory ROID,g, gdzie g ∈ {mysz, klawiatura, ekran dotykowy}.

Agent aprezGUI jest odpowiedzialny za wyświetlanie informacji

otrzymanych od agenta a

prez

oraz odczytywanie bodźców pocho-

dzących ze środowiska, w tym przypadku ekranu komputera,

a konkretnie kliknięć myszy lub naciśnięć klawiatury imitowa-

nych przez agenta a

OID

. Bodźce te są przechwytywane za pomocą

przycisków okna – rzeczywistych receptorów agenta aprezGUI.

7.2. Moduł audio

7.2.1. Struktura

Moduł audio składa się z pięciu agentów (rys. 7): podsta-

wowego agenta aaudio oraz agentów pomocniczych zarządzają-

cych oknami:

− agenta aaudioGUI_init reprezentującego pojedyncze okno, służące

do wyboru poniżej wymienionych okien,

−

agenta a

audioGUI_user

reprezentującego okno zarządzania użyt-

kownikami,

−

agenta a

audioGUI_command

reprezentującego okno zarządzania pole-

ceniami oraz

− agenta aaudioGUI_control reprezentującego okno sterowania i prze-

prowadzania uczenia na podstawie posiadanych nagrań.

Cztery agenty reprezentujące okna mają strukturę agenta aa,

gdzie a Î {audioGUI_init, audioGUI_user, audioGUI_com-

mand, audioGUI_control}, a więc ich wewnętrzna struktura

odpowiada tej z rys. 3. Każdy z czterech wspomnianych agentów

GUI reprezentuje pojedyncze okno wyposażone w przyciski oraz

elementy służące do wyświetlania odpowiednich informacji zwią-

zanych z konkretnym agentem GUI modułu audio. Tylko jeden

agent GUI modułu audio sposród: a

audioGUI_user

, a

audioGUI_command

oraz aaudioGUI_control jest aktywny w danym momencie.

Struktura wewnętrzna agenta a

audio

została przedstawiona

na rys. 8. Agent a

audio

składa się z podsystemu sterowania

caudio pozyskującego informacje z receptora wirtualnego raudio,mic

i oddziałującego na efektor wirtualny e

audio,ui

. Podsystem c

audio

wyposażony jest w bufory transmisyjne umożliwiające komuni-

kację z agentem a

prez

oraz wspomnianymi agentami GUI modułu

audio. Receptor wirtualny r

audio,mic

agreguje dane z receptora rze-

czywistego Raudio,mic, który zawiera mikrofony, sprzętowy prze-

twornik analogowo-cyfrowy oraz sterownik programowy tego

przetwornika zainstalowany w systemie operacyjnym. Natomiast

efektor wirtualny e

audio,ui

steruje efektorem rzeczywistym E

audio,ui

który reprezentuje głośnik komputera, bądź system nagłośnie-

nia pomieszczenia.

Rys. 5. St ruktur a agenta

prezentacji

Fig. 5. Structure of the agent

presentation

Rys. 6. Komunikacja międzyagentowa w m odule pr ezentacji

Fig. 6. Interagent communication in the presentation module

Rys. 7. Dekompozycja modułu audio na agent y

Fig. 7. Decomposition of the audio module into agents

Rys. 8. Struktura agenta audio aau dio, gdzi e nr ϵ {init, user,

command, control}

Fig. 8. Structure of the audio agent, where nr ϵ {init, user, command,

control}

W. Kasprzak, W. Szynkiewicz, M. Stefańczyk, W. Dudek, M. Figat, M. Węgierek, D. Seredyński, C. Zieliński

Moduł audio, a dokładniej podsystem sterowania c

audio

agenta aaudio, umożliwia:

−

administratorowi systemu – tworzenie i zarządzanie modelami

komend oraz użytkowników,

− użytkownikowi – sterowanie głosem platformą.

Administrator wpływa na moduł audio komunikując się

z agentem aOID za pomocą jego receptorów. Agent ten wykorzy-

stując swoje efektory komunikuje się z odpowiednim agentem

GUI stosując stygmergię. W dalszej kolejności podsystem ste-

rowania wspomnianego agenta GUI przesyła odpowiednie pole-

cenia do podsystemu caudio agenta aaudio. Konguracja modułu

audio polega na odpowiednim ustawieniu sprzętu oraz stworze-

niu odpowiedniego pliku konguracyjnego, co wykonywane jest

przez serwisanta bez udziału agenta aaudio.

7.2.2. Zachowania

Działanie agentów GUI a

, tj. a

audioGUI_init

, a

audioGUI_user

audioGUI_command

, a

audioGUI_control

polega na odbieraniu za pomocą

swoich rzeczywistych receptorów informacji ze środowiska

(ekranu monitora), np. o wciśniętym przycisku w jednym

z odpowiadających im okien, wysyłaniu powyższych informa-

cji do agenta a

audio

, odbieraniu danych z a

audio

oraz wyświe-

tlaniu ich za pomocą rzeczywistych efektorów (odpowiednich

elementów okien).

Działanie agenta a

audio

, a dokładniej jego podsystemu stero-

wania c

audio

, opisuje automat skończony przedstawiony na rys.

9. Z każdym ze stanów automatu związane jest odpowiednie

zachowanie. W stanie początkowym

init

audio

podsystem c

audio

ocze-

kuje na polecenie otrzymane z c

audioGUI_init

. Polecenie to może

dotyczyć albo przetwarzania komend głosowych albo zarządza-

nia zasobami. Otrzymywane polecenia, powodując zmianę stanu

automatu skończonego, powodują tworzenie agentów GUI lub

zakończenie ich istnienia – w ten sposób okienka pojawiają się

i znikają z ekranu. W konsekwencji prezentowany system ma

zmienną strukturę [39], w której agenty pojawiają się i znikają.

Polecenie rozpoczęcia rozpoznawania komend, otrzymanie

z caudioGUI_init powoduje, że podsystem caudio przechodzi do stanu

sterowanie

audio

, w którym realizuje zachowanie polegające na stwo-

rzeniu agenta aaudioGUI_command (reprezentującego okno służące do

sterowania rozpoznawaniem), a następnie dokonuje ciągłej akwi

zycji sygnału audio i na bieżąco wykonuje detekcję mowy

w sygnale oraz analizuje każdy izolowany fragment mowy w celu

rozpoznania mówcy i komendy. W zależności od tego, czy roz-

poznano mówcę czy też nie, stosowany jest dedykowany model

komend takiego mówcy lub model ogólny. Zakończenie zacho-

wania związanego ze stanem

sterowanie

audio

powoduje unicestwienie

agenta a

audioGUI_command

, a w związku z tym i okienka, którym zawia-

duje.

W stanie

zarzadzanie

audio

podejmowana jest decyzja, jakimi danymi

(zasobami) ma zarządzać caudio. Automat robi to na podstawie

danych otrzymanych z c

audioGUI_init

. Po przejściu do stanu

polecenia

audio

albo

uzytkownicy

audio

uruchamiane jest zachowanie inicjujące odpo-

wiedniego agenta, tj. aaudioGUI_command lub aaudioGUI_user i możliwe jest

dodawanie, usuwanie i aktualizowanie danych zawartych w pliku

konguracyjnym odpowiednio poleceń i użytkowników. Po

zakończeniu działania zachowań następuje zakończenie działania

odpowiedniego agenta GUI.

W stanie

nagrania

audio

uruchamiany jest agent a

audioGUI_control

, dzięki

czemu możliwe jest przeprowadzenie sesji nagraniowej dla

wybranego użytkownika. Sesja nagraniowa polega na nagraniu

po n próbek (powtórzeń) dla wszystkich poleceń wczytanych

z pliku konguracyjnego, gdzie n jest liczbą próbek deniowaną

przez administratora modułu audio. Podczas sesji nagraniowej

audio

komunikuje się z wirtualnym receptorem r

audio,mic

, w celu

akwizycji sygnału audio, oraz z podsystemem sterowania agenta

aaudioGUI_control, w celu kontrolnej wizualizacji oscylogramu nagra-

nia, a ponadto z eaudio,ui w celu odtworzenia przez głośniki roz-

poznanego polecenia. Na koniec tworzony jest plik w formacie

wave z nagraną próbką, będący elementem wewnętrznej pamięci

podsystemu sterowania caudio.

W stanie

uczenie

audio

uruchamiany jest agent aaudioGUI_control i ini-

cjowane jest uczenie, tj. automatyczne tworzenie modeli użyt-

kowników i poleceń w oparciu o zebrane wcześniej próbki

głosowe (podczas sesji nagraniowych z udziałem przyszłych użyt-

kowników). Proces uczenia wykonywany jest prawie wyłącznie

przez wirtualny receptor raudio,mic, który realizuje funkcje:

− dekodowania danych w formacie wave,

− analizy wstępnej i parametryzacji sygnału mowy,

− tworzenia modeli mówców i modeli komend,

− serializacji modeli następnie zapisywanych do plików.

Zakodowane w formacie wave dane są przesyłane do podsys-

temu sterowania c

audio

, a ten wypisuje je do rezydującego w jego

pamięci wewnętrznej systemu plików. W razie potrzeby podsys-

tem sterowania caudio może pobrać ze swojej pamięci wewnętrznej

uprzednio przygotowany plik, przesłać jego treść do wirtualnego

receptora r

audio,mic

, który zdekoduje dane w formacie wave do

postaci wektora próbek sygnału (liczb) i w tej postaci zapamięta

je na czas przetwarzania.

7.3. Moduł wizyjny

Moduł wizyjny składa się z trzech agentów. Głównym jest

agent a

vision

(rys. 10), który odpowiada za realizację zadania

sterowania gestami. Komunikuje się on z agentami avisionGUI

oraz a

vision−database

(rys. 11), które są odpowiedzialne za reali-

zację odpowiednio gracznego interfejsu użytkownika oraz

bazy danych.

Agent a

vision

składa się z podsystemu sterowania c

vision

, wirtual-

nego receptora r

vision

oraz dwóch rzeczywistych receptorów R

vision,1

i Rvision,2 będących kamerami RGB zestawionymi w stereoparę.

Pozostałe agenty mają jedynie podsystemy sterowania. Agent

avision komunikuje się ponadto z agentem aprez.

Automat skończony podsystemu sterowania cvision agenta wizyj-

nego a

vision

(rys. 12) w swym stanie początkowym

init

vision

uru-

chamia zachowanie, które komunikuje się z agentem avision−database

w celu pobrania modeli gestów statycznych i dynamicznych oraz

pozostałych danych potrzebnych do pracy agenta (m.in. zapisa-

nych parametrów kamer), a następnie przechodzi do rozpozna-

wania gestów. Najpierw w stanie

poszukiwanie_twarzy

vision

uruchamiana

jest procedura poszukiwania twarzy operatora. Jeśli zostanie

ona odnaleziona w oczekiwanym miejscu przestrzeni roboczej,

to automat przechodzi do stanu

poszukiwanie_dloni

vision

, w którym usta-

lane jest położenie obu dłoni operatora. Po ich poprawnym zlo-

kalizowaniu automat przechodzi do stanu

rozpoznawanie_gestów

vision

w którym rozpoznaje i śledzi dłonie oraz interpretuje gesty sta-

tyczne i dynamiczne. W przypadku utraty możliwości śledzenia

Rys. 9. Automat skońc zony prze łączaj ący zachowania pod systemu

sterowania caudio

Fig. 9. Finite state automation switching behavioours of the control

subsystem caudio

Agentowa struktura wielomodalnego interfejsu do Narodowej Platformy Cyberbezpieczeństwa, część 1.

POMIARY•AUTOMATYKA•ROBOTYKA NR 3/2019

dłoni bądź twarzy operatora automat wraca do stanu – odpo-

wiednio

poszukiwanie_dloni

vision

lub

poszukiwanie_twarzy

vision

. Trywialne auto-

maty skończone wirtualnego receptora rvision,1 i rzeczywistych

receptorów R

vision,1

i R

vision,2

agenta a

vision

przedstawiono na rys.13.

Podsystem sterowania agenta avisionGUI, odpowiedzialnego za

wyświetlanie okna interfejsu użytkownika modułu wizyjnego,

realizuje tylko jedno zachowanie. Polega ono na wyświetlaniu

w swoim oknie obrazów otrzymywanych od agenta a

vision

oraz

przesyłaniu do tego agenta poleceń będących efektem interakcji

z agentami wytwarzającymi kursory na ekranie albo dostarcza-

jącymi informacji o wciśnięciu klawiszy klawiatury bądź innym

zdarzeniu wywoływanym przez urządzenie wejściowe.

8. Charakterystyka agentów

upostaciowionych interfejsu NPC

Agenty upostaciowione, z których skomponowano inter-

fejs NPC, odpowiadają ogólnej denicji agenta przedstawio-

nej w części 3. tego artykułu. Literatura dotycząca agentów,

zarówno programowych, jak i stosowanych w robotyce, jest

bogata i, jak już wspomniano, nie doczekała się jednoznacznej

denicji tego pojęcia. Denicje tam przedstawione zazwyczaj

odnoszą się do licznych cech różnorodnych typów agentów.

Warto tutaj spojrzeć na agenta upostaciowionego pod kątem

często wymienianych atrybutów różnych typów agentów.

Pojęcie agenta upostaciowionego zostało spopularyzowane

przez Rodneya Brooksa (np. [9]) w trakcie debaty dotyczącej

sztucznej inteligencji. Tradycyjna sztuczna inteligencja koncen-

trowała się na modelu środowiska (jego reprezentacji), by móc

wyciągać wnioski dotyczące przyszłych akcji do wykonania przez

system. Planowanie akcji było głównym przedmiotem zaintereso-

wania badaczy. Brooks zakwestionował to podejście stwierdzając,

że najlepszym modelem środowiska jest ono samo, a inteligentne

działanie jest wynikiem ewolucyjnego procesu prowadzącego do

doskonalenia sposobu działania systemu [8, 10, 11]. W rozu-

mieniu Brooksa, dwoma podstawowymi cechami agenta jest

posiadanie ciała/postaci (ang. embodiment) oraz usytuowanie

(ang. situatedness), czyli egzystowanie w realnym otoczeniu,

a nie w świecie abstrakcyjnym (uproszczonym). Wymienia on

również inteligencję będącą następstwem wyłaniania (ang. emer-

gence) jako efektu interakcji między agentem i jego otoczeniem.

Spór między Brooksem i przedstawicielami klasycznej sztucz-

nej inteligencji, dotyczący wyższości agentów reaktywnych nad

deliberatywnymi, nie został jednoznacznie rozstrzygnięty, bo

do inteligentnego działania potrzebne jest, w istocie, zarówno

wnioskowanie prowadzone w oparciu o model świata, jak i zacho-

wania reaktywne wykorzystujące uogólnianie (ang. subsump

tion) – powstały więc agenty hybrydowe (np. [4]). Co najmniej

niektóre agenty wykorzystane do stworzenia interfejsu NPC są

upostaciowione, gdyż posiadają ciało, a więc mikrofony i ekran

monitora, służące do kontaktu z operatorem znajdującym się

w środowisku. Ponadto są usytuowane, ponieważ przetwarzają

sygnały dźwiękowe i świetlne bezpośrednio pochodzące z tego

otoczenia. Sygnałami tymi są mowa oraz gesty operatora. Mamy

tu jednak do czynienia z agentami hybrydowymi, bo sygnały te

nie oddziałują w sposób bezpośredni na efektory, a więc nie jest

to system czysto reaktywny. Wpierw te sygnały przetwarzane

są na postać symboliczną komend, a więc wykorzystują modele

wiążące sygnały z ich znaczeniem.

Spór dotyczący emergencji inteligencji w systemach dopro-

wadził do rozpowszechnienia pojęcia agenta w środowisku

naukowców zajmujących się sztuczna inteligencją. Klasyczny

podręcznik tej dziedziny [26] zbudowany jest właśnie wokół poję-

cia agenta. W najbardziej ogólnej postaci traktuje agenta jako

coś, co działa. Taka denicja jest zbyt ogólna, więc dodatkowo

wyróżnia pożądane cechy agentów: autonomiczne sterowanie,

Rys. 10. Str uktura agenta wizyjnego

Fig. 10. Structure of the agent vision

Rys. 11. Struktura agenta bazy d anych modułu audio

Fig. 11. Structure of the agent audio data base

Rys. 12. Automat skończony przełączaj ący zachowania pod systemu

sterowania cvision

Fig. 12. Finite state automaton switching the behaviours of the control

subsystem cvision

Rys. 13. Auto maty skończone przełącz ające zachowani a

rzeczywistych receptorów Rvision,1 i Rvision,2 oraz wirtualnego receptora

rvision,1

Fig. 13. Finite state automaton switching the behaviours of real receptor

Rvi sio n,1 i Rvisi on,2 and virtual receptor rvi sio n,1 of the agent avision

W. Kasprzak, W. Szynkiewicz, M. Stefańczyk, W. Dudek, M. Figat, M. Węgierek, D. Seredyński, C. Zieliński

czyli działanie bez udziału człowieka, zdolność do postrzega-

nia środowiska, długotrwałość działania, adaptacja do zmian

zachodzących w środowisku, zdolność do przejmowania celu

działania innych agentów. Dodatkowo wymieniane są agenty

racjonalne, a więc takie, których działanie przynosi najlepszy

skutek lub najlepszy spodziewany skutek (jeżeli mamy do czy-

nienia z niepewnością). Pojawiają się też agenty uczące się czyli

takie, które polepszają wyniki swojego działania w miarę zdoby-

wania nowych doświadczeń. Agenty interfejsu NPC, po dostro-

jeniu modeli przez uczenie, działają autonomicznie, dysponują

zdolnością do postrzegania środowiska (zdolność do interakcji

z operatorem), niektóre istnieją tak długo, jak długo istnieje

interfejs, a agenty pomocnicze zarządzające oknami działają

przez czas, kiedy są niezbędne do realizacji konkretnej operacji.

Nie mają one zdolności adaptacyjnych i nie mogą przejmować

celu działania innych agentów.

Różnorodność cech przypisywanych agentom wynika z ewolu-

cji, która doprowadziła do pojawienia się tego pojęcia na gruncie

informatyki. W podręczniku [25] autor wywodzi agenta z poję-

cia aktora, które stanowi elementarne obliczenie wykonywane

równolegle z innymi takimi obliczeniami. Aktory zmieniają swój

stan wewnętrzny oraz komunikują się z innymi aktorami. Uogól-

nieniem aktora stał się aktywny obiekt, działający w swym wła-

snym wątku. Uogólnienie aktywnego aktora doprowadziło do

pojęcia agenta, który stanowi autonomiczną jednostkę działa-

jącą w środowisku. Jednostka ta dąży do realizacji swojego celu,

co wymaga wykonywania pewnych czynności oraz komunikacji

z innymi agentami. Efektem tych rozważań historycznych jest

określenie agenta w bardzo podobny sposób, jak zdeniowano

agenta upostaciowionego.

Podjęto też próbę mariażu agentów działających w cyberprze-

strzeni z tymi funkcjonującymi w przestrzeni zycznej [13]. Roz-

wój systemów operacyjnych doprowadził do powstania pojęcia

procesu. Początkowo procesy komunikowały się ze sobą jedy-

nie wewnątrz systemu operacyjnego, ale wraz z rozwojem sieci

komputerowych ta komunikacja musiała zostać rozszerzona, co

doprowadziło do powstania koncepcji cyberprzestrzeni. Wspo-

mniana praca pokazuje możliwości i konsekwencje przekrocze-

nia granicy cyberprzestrzeni w celu wniknięcia do przestrzeni

rzeczywistej, w której działają urządzenia, a więc i roboty.

Ponieważ proces funkcjonuje w obrębie pojedynczego systemu

operacyjnego, to uogólnienie tego pojęcia na cyberprzestrzeń dla

odróżnienia zostało nazwane agentem. Cyberprzestrzeń stanowi

środowisko, w którym agent działa, a więc postrzega ją i wpływa

na nią. Dalsza ewolucja doprowadziła do powstania agentów

mobilnych, które są zdolne do przemieszczania się w cyberprze-

strzeni. Ponieważ roboty przemieszczają się w przestrzeni rzeczy-

wistej, dostrzeżono tu, z jednej strony paralelę, a z drugiej strony

pole ciekawych badań na styku tych przestrzeni. Podstawą tych

rozważań był rozwój pojęć – od algorytmu przez obiekt do

agenta. Motywacją była konieczność dekompozycji algorytmu,

w celu umysłowego zrozumienia złożoności tworzonego systemu

przez projektanta. Wspomniana ewolucja zwiększała stopień

autonomii działania kolejno wymienionych pojęć. W pracy [13]

zdeniowano M-agenta, który na podstawie danych pozyskanych

ze środowiska oraz wewnętrznego modelu służącego symulacji

możliwych zachowań, wybiera optymalną strategię działania i te

realizuje wpływając na środowisko. Specykacja M-agenta za

pomocą opisanego tu agenta upostaciowionego została przed-

stawiona w [35]. Jednak do sterowania platformą za pomocą

gestów i mowy nie jest potrzebny wyranowany model otocze-

nia – wystarczą wzorce gestów i komend.

Agentom programowym (software’owym) poświęcona jest

praca [22], w której przytoczono różne kryteria, według któ-

rych można sklasykować agenty. Wyróżnia się agenty statyczne

i mobilne, w zależności od tego czy mogą się one przemieszczać

po sieci. Agenty interfejsu NPC są statyczne. Natomiast praca

[22] odnosi się do omawianych wyżej agentów reaktywnych,

deliberatywnych i hybrydowych oraz autonomiczności agentów.

Podnosi kwestie uczenia się i zdolności do współpracy między

agentami. Agenty interfejsu NPC uczą się jedynie w trakcie

ich konguracji, natomiast współdziałają ze sobą, by osiągnąć

wspólny cel. Wspomniana praca sugeruje wykorzystanie jednego

wspólnego języka do porozumiewania się agentów. Tu taki język

nie został stworzony. Poszczególne agenty porozumiewają się

ze sobą dzięki oddzielnym zestawom przesyłanych wiadomości.

Wreszcie wymieniana jest oddzielna klasa agentów interfejso-

wych służących do porozumiewania się użytkowników z sys-

temami. Interfejs NPC spełnia, jako całość, dokładnie tę rolę.

Należy też zauważyć, że część agentów interfejsu NPC to agenty

upostaciowione, a część to agenty czysto programowe.

Tekst [24] bazuje na denicji agenta zaproponowanej przez

Wooldridge’a [34], mówiącej że agent stanowi system kompute-

rowy, który jest usytuowany w pewnym środowisku i jest zdolny

do autonomicznych działań w tym środowisku w celu realizacji

zadań, dla których został zaprojektowany. Praca [24] wymie-

nia pożądane cechy inteligentnego agenta: reaktywność, czyli

zdolność do reagowania na zmiany zachodzące w środowisku;

proaktywność, czyli dążenie do realizacji celu; socjalność, czyli

zdolność do wchodzenia w interakcje z innymi agentami; ela-

styczność, czyli zdolność do osiągania celów różnymi sposobami

oraz odporność, czyli umiejętność radzenia sobie z błędami.

Agenty wchodzące w skład interfejsu NPC do pewnego stopnia

mają wszystkie te cechy. Z kolei praca [31] traktuje o progra-

mowaniu zorientowanym agentowo, jako uogólnieniu programo-

wania obiektowego, określa agenta przez takie właściwości jego

„umysłu”, jak: przekonania, zdolności, wybory oraz zobowiąza-

nia. To podejście wywodzi się z prac dotyczących architektury

BDI (ang. belief, desire, intension) [24, 31]. Przekonania dotyczą

aktualnego stanu środowiska i samego agenta, pragnienia wyni-

kają z celu, który ma być osiągnięty, natomiast intencje dotyczą

pragnień, do których osiągnięcia agent się zobowiązał, a więc

dotyczą wyboru planu osiągnięcia celu. W przypadku agentów

interfejsu NPC nie wprowadzono pojęcia „umysłu”, gdyż jest on

nadmiarowy w stosunku do potrzeb. W konsekwencji tu prezen-

towane agenty upostaciowione nie korzystają z architektury BDI.

Na gruncie sztucznej inteligencji prowadzone są również prace

dotyczące zdobywania nowej wiedzy przez agenty. Przykładowo

praca [27] opisuje system wieloagentowy stosujący logikę niemo-

notoniczną do wnioskowania, w celu odpowiedzi na zapytania.

Mógłby to być ciekawy kierunek rozwoju interfejsu NPC, dający

użytkownikowi możliwość nie tylko sterowania prezentacją wyni-

ków działania platformy, ale również kierowania do niej zapytań.

Na gruncie informatyki rozpatrywane są również masywne

systemy wieloagentowe (ang. Massive Multi-Agent Systems),

złożone z olbrzymiej liczby agentów. W takich systemach głów-

nym problemem jest skalowalność komunikacji agentów. Roz-

wiązanie tego problemu w dużej mierze zależy od technologii

implementacji agentów jako wątków, oraz sposobu realizacji

przesyłania wiadomości między agentami. Polem zastosowa-

nia takich systemów są, przykładowo, obliczenia ewolucyjne

[20]. Chwilowo w systemach robotycznych tak olbrzymie liczby

agentów nie występują, stopień współbieżności jest więc dużo

niższy niż ten przedstawiony w pracy [20]. Należy się jed-

nak spodziewać, że w przyszłości roje robotów mogą stać się

ogromne. Wtedy wykorzystanie takich technologii może być

koniecznością. Informatycy badają również ewolucyjne sys-

temy wieloagentowe (ang. Evolutionary Multi-Agent Systems),

w których każdy z agentów reprezentuje pojedyncze rozwią-

zanie zadania optymalizacji [19]. Agenty wchodzą w interak-

cje między sobą (rozmnażają się, współzawodniczą o zasoby)

przekazując sobie skwantowany zasób zwany energią. Z punktu

widzenia informatyki istotne jest odseparowanie obliczeń od

modelu ich realizacji (sekwencyjnego, równoległego, typu prze-

Agentowa struktura wielomodalnego interfejsu do Narodowej Platformy Cyberbezpieczeństwa, część 1.

POMIARY•AUTOMATYKA•ROBOTYKA NR 3/2019

pływ danych dataow). Przedstawiany w tym artykule model

agenta również abstrahuje od jego implementacji, a więc spo-

sobu prowadzenia obliczeń.

Na zakończenie dyskusji dotyczącej relacji między prezento-

wanym tu agentem upostaciowionym i agentami deniowanymi

w bardzo bogatej literaturze tematu warto jeszcze wspomnieć

o inżynierii systemów wieloagentowych [14]. Podstawą jest roz-

dzielenie fazy specykacji systemu od fazy jego implementa-

cji, czyli realizacja ogólnych zaleceń inżynierii oprogramowania

[28]. Istotnym jest dodatkowe zalecenie mówiące, że specyka-

cję należy sporządzić dla każdego agenta oddzielnie, a działanie

całości systemu powinno wynikać z interakcji tych agentów.

Kolejnym zaleceniem jest przyporządkowanie każdej roli lub

grupie ról pokrewnych, które system ma pełnić, jednego agenta

realizującego te role. Ponadto zaleca się stosowanie automatów

skończonych do opisu działania agentów. Specykacja i imple-

mentacja interfejsu NPC jest zgodna z tymi ogólnymi zalece-

niami. Należy jednak podkreślić, że wśród zaleceń brak było

wskazówek na temat wewnętrznej struktury i sposobu działa-

nia agentów. Prezentowany tu sposób tworzenia systemu wielo-

agentowego jest konkretniejszy, przez co ułatwia projektantowi

stworzenie systemu wieloagentowego. Zarówno struktura, jak

i sposób działania określone są wzorcami.

9. Interakcja interfejsu z systemem

operacyjnym

Jedną z decyzji dotyczących implementacji jest ta odnosząca

się do liczby komputerów, które mają realizować zadania sys-

temu. Bezpośredni wpływ na nią ma obliczeniochłonność

stosowanych algorytmów. W przypadku relatywnie niskiej obli-

czeniochłonności kod wszystkich agentów wchodzących w skład

projektowanego systemu można ulokować na jednym kompute-

rze. Z taką sytuacją mamy do czynienia w przypadku interfejsu

NPC. Na rys. 14 przedstawiono ogólną zasadę implementacji

komunikacji zarówno między agentami jak i podsystemami

agentów, w przypadku gdy wszystkie agenty i podsystemy

wykonywane są przez ten sam komputer. Komunikacja ta

odbywa się za pośrednictwem systemu operacyjnego. Schemat

ten pokazuje również sposób interakcji między podsystemami

a sterownikami (ang. driverami) urządzeń oraz między sterow-

nikami a urządzeniami wykorzystywanymi przez interfejs NPC.

Jak widać, implementacja zakłada powstanie struktury trój-

warstwowej, w której górną warstwę bezpośrednio określa specy-

kacja. Poniżej znajduje się warstwa odpowiadająca systemowi

operacyjnemu komputera. W tej warstwie rezydują zarówno

sterowniki urządzeń – receptorów i efektorów, a także oprogra-

mowanie organizujące przekazywanie informacji między wątkami

i procesami. Najniższą warstwę tworzą tylko urządzenia, które

same w sobie mogą zawierać oprogramowanie, ale to tworzone

jest przez producentów sprzętu i jest ukryte przed projektan-

tem systemu.

10. Podsumowanie

Artykuł poświęcony jest specykacji i implementacji wielomo-

dalnego interfejsu do sterowania prezentacją wyników wytwa-

rzanych przez Narodową Platformę Cyberbezpieczeństwa. Ta

część artykułu koncentruje się na opisie struktury i sposobu

działania interfejsu. Do jego specykacji wykorzystano kon-

cepcję agentów upostaciowionych. Dotychczas ta metoda spe-

cykacji stosowana była do systemów robotycznych, a więc do

opisu urządzeń działających w środowisku zycznym. Tutaj

jednak mamy do czynienia z systemem działającym na styku

środowiska zycznego, w którym funkcjonuje operator, oraz

cyberprzestrzeni, w której tworzone są wyniki analizy aktyw-

ności w sieci. Ten charakter środowiska wymagał specycznego

rozdzielenia systemu i środowiska. W szczególności zakwali-

kowano ekran monitora do środowiska, natomiast elementy

okienek i kursory pojawiające się na tym ekranie zaliczono do

receptorów i efektorów reprezentujących je agentów. Ponadto

agenty zostały pogrupowane w moduły, co nadało systemowi

hierarchiczny charakter. Wyróżniono trzy takie moduły: audio,

wizji oraz prezentacji. Dzięki zastosowaniu grup współpra-

cujących agentów struktura powstałego interfejsu ma naturę

otwartą. System może być rozszerzony o kolejne moduły, jeżeli

trzeba dodać następne tryby porozumiewania się operatora

z systemem, a ponadto każdy z modułów może być wzbo-

gacany o kolejne agenty realizujące dodatkowe funkcje tych

modułów. Obecne tryby porozumiewania się mogą być roz-

Rys. 14. Schemat komunikacji międzyagentowej i wewnątrzagentowej zastosowanej w interfejsie NPC

Fig. 14. Intra-agent and inter-agent communication employed by the NCP interface

W. Kasprzak, W. Szynkiewicz, M. Stefańczyk, W. Dudek, M. Figat, M. Węgierek, D. Seredyński, C. Zieliński

szerzane przez dodawanie nowych komend głosowych oraz

gestów sterujących, w tym wykonywanych głową oraz stero-

wanie mimiką twarzy. Wszystko to umożliwia względnie proste

rozszerzenie struktury, a przez to zwiększenie jej możliwo-

ści. Rozszerzając tę strukturę należy wykorzystać to, co już

istnieje, jako wzorzec. Zastosowana metoda projektowa ma

swoje korzenie w inżynierii oprogramowania, w szczególności

przykłada istotną wagę do dwóch faz tworzenia systemu: fazy

specykacji odpowiadającej na pytanie, co ma być stworzone,

oraz fazy implementacji deniującej, jak to ma być wykonane.

To rozdzielenie zainteresowania (ang. separation of concerns)

projektanta prowadzi do stworzenia hierarchicznego systemu

o przejrzystej architekturze. Wspomniana hierarchia obejmuje

następujące warstwy: modułu, agenta, automatu skończonego,

funkcji przejścia.

Obecnie podstawowymi sposobami komunikacji operatora

z interfejsem są polecenia wydawane albo głosem albo gestem.

Wprowadzono też bezpieczny tryb dostępu do platformy wyko-

rzystujący identykację mówcy. Wstępne testy wykazały wysoką

skuteczność obecnych trybów porozumiewania się z systemem.

Druga część artykułu poświęcona będzie zastosowanym algoryt

mom rozpoznawania: mowy, mówcy i gestów. Ponadto przedsta-

wione zostaną wyniki przeprowadzonych testów.

Podziękowania

Praca wykonana w ramach projektu CYBERSECIDENT

/369195/I/NCBR/2017, współnansowanego przez Narodowe

Centrum Badań i Rozwoju w ramach programu CyberSecIdent.

Bibliografia

1. The National Cyber Security Centre, Holandia, https://

www.ncsc.nl [on-line: dostęp 5-04-2019].

The National Cyber Security Centre, Wielka Brytania,

https://www.ncsc.gov.uk [on-line: dostęp 5-04-2019].

The National Cybersecurity and Communications Inte-

gration Center, USA, https://ics-cert.us-cert.gov [on-line:

dostęp 5-04-2019].

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

Best D.M., Endert A., Kidwell D., 7 key challenges for

visualization in cyber network defense. Proceedings of the

Eleventh Workshop on Visualization for Cyber Security,

VizSec ’14, 33–40, DOI: 10.1145/2671491.2671497.

Bonabeau E., Dorigo M., Theraulaz G., Swarm Intelli-

gence: From Natural to Articial Systems. Oxford Uni-

versity Press, New York, Oxford, 1999.

Bostock M., Pseudo-Dorling cartogram, https://bl.ocks.

org/mbostock/4055892, 2015. [on-line: dostęp 5-04-2019].

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.

9. Brooks R.A., Intelligence without reason. Articial intel-

ligence: critical concepts, 3:107–163, 1991.

10.

Brooks R.A., Intelligence without representation. Articial

Intelligence, 47(1-3):139–159, January 1991.

11. Brooks R.A., New approaches to robotics. “Science”, Vol.

253, No. 5025, September 1991, 1227–1232,

DOI: 10.1126/science.253.5025.1227.

12. Cao N., Lin C., Zhu Q., Lin Y., Teng X., Wen X., Voila:

Visual anomaly detection and monitoring with streaming

spatiotemporal data. IEEE Transactions on Visualization

and Computer Graphics, Vol. 24, No. 1, Jan 2018, 23–33,

DOI: 10.1109/TVCG.2017.2744419.

13.

Cetnarowicz K., Inteligencja wokół nas. Współdziałanie agen-

tów softwareowych, robotów, inteligentnych urządzeń, Vol.

15, rozdział M–agent, 137–167. Wydawnictwo EXIT, 2010.

14. DeLoach S., Wood M., Sparkman C., Multiagent systems

engineering. “International Journal of Software Engineer-

ing and Knowledge Engineering”, Vol. 11, No. 3, 2001,

231–258, DOI: 10.1142/S0218194001000542.

15.

Dumas B., Lalanne D., Oviatt S.. Human Machine Inter-

action, Vol. 5440 serii Lecture Notes in Computer Science,

rozdział Multimodal Interfaces: A Survey of Principles,

Models and Frameworks, 3–26, Springer, 2009.

16.

Jaimes A., Sebe N., Multimodal human–computer interac-

tion: A survey. “Computer Vision and Image Understand-

ing”, Vol. 108, No. 1–2, 2007, 116–134, Special Issue on

Vision for Human-Computer Interaction,

DOI: 10.1016/j.cviu.2006.10.019.

17. Kasprzak W., Rozpoznawanie obrazów i sygnałów mowy.

Ocyna Wydawnicza Politechniki Warszawskiej, 2009.

18.

Kornuta T., Zieliński C., Robot control system design

exemplied by multi-camera visual servoing, “Journal of

Intelligent & Robotic Systems”, Vol. 77, No. 3–4, 2013,

499–524, DOI: 10.1007/s10846-013-9883-x.

19.

Krzywicki D., Faber Ł., Dębski R., Concurrent agent-based

evolutionary computations as adaptive dataows. “Concur-

rency and Computation Practice and Experience”, Vol. 30,

No. 22, 2018, 1–29, DOI: 10.1002/cpe.4702.

20.

Krzywicki D., Turek W., Byrski A., Kisiel-Dorohinicki M.,

Massively concurrent agent-based evolutionary computing.

“Journal of Computational Science”, Vol. 11, 2015, 153–

162, DOI: 10.1016/j.jocs.2015.07.003.

21.

McKenna S., Staheli D., Fulcher C., Meyer M., Bubblenet:

A cyber security dashboard for visualizing patterns. Euro-

graphics Conference on Visualization (EuroVis), Vol. 35,

No. 3, June 2016, 281–290, DOI: 10.1111/cgf.12904.

22. Nwana H.S., Ndumu D.T., A Brief Introduction to Soft-

ware Agent Technology, 29–47. Springer Berlin Heidelberg,

Berlin, Heidelberg, 1998.

23.

Oviatt S., Schuller B., Cohen P., Sonntag D., Potamianos

G., Kruger A. (eds), The Handbook of Multimodal-Mul-

tisensor Interfaces, Vol. 1: Foundations, User Modeling,

and Common Modality Combinations. ACM Books Series.

Association for Computing Machinery (ACM), 2017.

24.

Padgham L., Winiko M., Developing Intelligent Agent

Systems: A Practical Guide. John Wiley & Sons, 2004.

25.

Pałka P., Wieloagentowe systemy decyzyjne. Ocyna

Wydawnicza Politechniki Warszawskiej, Warszawa 2019.

26.

Russell S., Norvig P., Articial Intelligence: A Modern

Approach. Prentice Hall, Upper Saddle River, N.J., 1995.

27.

Rybiński H., Ryzko D., Wiech P., Learning of Defaults

by Agents in a Distributed Multi-Agent System Environ-

ment, 197–213. Springer Berlin Heidelberg, Berlin, Hei-

delberg, 2013.

28.

Sacha K., Inżynieria oprogramowania. Wydawnictwo

Naukowe PWN, Warszawa 2010.

29.

Sethi A., Wills G., Expert-interviews led analysis of EEVi

– a model for eective visualization in cybersecurity. 2017

IEEE Symposium on Visualization for Cyber Security

(VizSec), Oct 2017, 1–8,

DOI: 10.1109/VIZSEC.2017.8062195.

30. Shiravi H., Shiravi A., Ghorbani A., A survey of visual-

ization systems for network security. IEEE Transactions

on Visualization and Computer Graphics, Vol. 18, No. 8,

2012, 1313–1329, DOI: 10.1109/TVCG.2011.144.

31.

Shoham Y., Agent-oriented programming. “Articial Intel-

ligence”, Vol. 60, No. 1, 1993, 51–92.

32.

Song B., Choi J., Choi S.-S., Song J., Visualization of

security event logs across multiple networks and its appli-

cation to a CSOC. “Cluster Computing”, 1–12, Nov 2017.

33.

Turk M., Multimodal interaction: A review. “Pattern Rec-

ognition Letters”, Vol. 36, 2014, 189–195,

DOI: 10.1016/j.patrec.2013.07.003.

34.

Wooldridge M., Multiagent systems. Ch. Intelligent

Agents, 27–77. MIT Press, Cambridge, MA, USA, 1999.

Agentowa struktura wielomodalnego interfejsu do Narodowej Platformy Cyberbezpieczeństwa, część 1.

POMIARY•AUTOMATYKA•ROBOTYKA NR 3/2019

35.

Zieliński C., Inteligencja wokół nas. Współdziałanie agen-

tów softwareowych, robotów, inteligentnych urządzeń,

wolumen 15, rozd. Formalne podejście do programowa-

nia robotów – struktura układu sterującego, 267–300,

EXIT, 2010.

36. Zieliński C., Figat M., Hexel R., Communication within

multi-FSM based robotic systems. “Journal of Intelligent

& Robotic Systems”, Vol. 93, No. 3–4, 2019, 787–805,

DOI: 10.1007/s10846-018-0869-6.

37.

Zieliński C., Kornuta T., Diagnostic requirements in

multi-robot systems. Korbicz J., Kowal M. (eds), Intel-

ligent Systems in Technical and Medical Diagnostics,

wolumen 230 serii Advances in Intelligent Systems and

Computing, 345–356. Springer, 2014.

38.

Zieliński C., Kornuta T., Winiarski T., A systematic

method of designing control systems for service and eld

robots. 19th IEEE International Conference on Methods

and Models in Automation and Robotics, MMAR, 1–14.

IEEE, 2014.

39.

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 SE., Karagian

nis 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.

40.

Zieliński C., Winiarski T., Kornuta T., Agent-based struc-

tures of robot systems. J. Kacprzyk, et al. (eds), Trends

in Advanced Intelligent Control, Optimization and Auto-

mation, Vol. 577 AISC, 493–502, 2017,

DOI: 10.1007/978-3-319-60699-6_48.

Abstract: This two part paper presents an interface to the National Cybersecurity Platform utilising

gestures and voice commands as the means of interaction between the operator and the platform.

Cyberspace and its underlying infrastructure are vulnerable to a broad range of risk stemming from

diverse cyber-threats. The main role of this interface is to support security analysts and operators

controlling visualisation of cyberspace events like incidents or cyber-attacks especially when

manipulating graphical information. Main visualization control modalities are gesture- and voice-based

commands. Thus the design of gesture recognition and speech-recognition modules is provided. The

speech module is also responsible for speaker identification in order to limit the access to trusted users

only, registered with the visualisation control system. This part of the paper focuses on the structure

and the activities of the interface, while the second part concentrates on the algorithms employed for

the recognition of: gestures, voice commands and speakers.

Keywords: National Cybersecurity Platform, image recognition, gesture recognition, speech recognition, speaker recognition

Agent Structure of Multimodal User Interface to the National

Cybersecurity Platform – Part 1

dr hab. inż. Wojciech Szynkiewicz

W.Szynkiewicz@elka.pw.edu.pl

ORCID: 0000-0001-6348-1129

Adiunkt w Instytucie Automatyki i Infor-

matyki Stosowanej na Wydziale Elektro-

niki i Technik Informacyjnych Politechniki

Warszawskiej. Zajmuje się zagadnieniami

sterowania i programowania robotów,

autonomicznej nawigacji, planowania

zadań i cyberbezpieczeństwa robotów.

Autor i współautor ponad 90 publikacji

w wymienionych obszarach badawczych.

prof. dr hab. inż. Włodzimierz Kasprzak

W.Kasprzak@elka.pw.edu.pl

ORCID: 0000-0002-4840-8860

Jest profesorem na Wydziale Elektroniki

i Technik Informacyjnych (WEiTI) Politech-

niki Warszawskiej (PW). W PW pracuje od

1997 r. Obecnie jest kierownikiem Zespołu

Percepcji Maszyn w IAiIS. Jego zaintere-

sowania badawcze obejmują algorytmy

i techniki automatycznej analizy obrazów

i sygnału mowy oraz metody rozpozna-

wania wzorców i uczenia maszynowego. Jest

autorem/współautorem ponad 160 publikacji

naukowych i członkiem towarzystw naukowych IEEE, IEEE CI Soc., IEEE SMC

Soc., TPO (IAPR), DAGM.

W. Kasprzak, W. Szynkiewicz, M. Stefańczyk, W. Dudek, M. Figat, M. Węgierek, D. Seredyński, C. Zieliński

mgr inż. Maciej Węgierek

wegierek.maciej@gmail.com

ORCID: 0000-0003-0779-255X

Jest doktorantem w Politechnice War-

szawskiej w Instytucie Automatyki i Infor-

matyki Stosowanej. Pracował w między-

narodowym grancie badawczym INCARE

(Active and Assisted Living JP Komisji Euro-

pejskiej). Jego zainteresowania naukowe

obejmują specykacje wymagań, struk-

tury oraz zasady działania sterowników

robotów.

prof. dr hab. inż. Cezary Zieliński

c.zielinski@ia.pw.edu.pl

ORCID: 0000-0001-7604-8834

Jest profesorem zwyczajnym na Wydziale

Elektroniki i Technik Informacyjnych (WEiTI)

Politechniki Warszawskiej (PW). W PW

pracuje od 1985 r., a od 2008 r. również

w Przemysłowym Instytucie Automatyki

i Pomiarów PIAP. W PW sprawował funkcje:

prodziekana ds. nauki i współpracy między-

narodowej WEiTI (2002–2005), zastępcy

dyrektora ds. naukowych Instytutu Auto-

matyki i Informatyki Stosowanej (IAiIS)

(2005–2008), dyrektora IAIS (2008–2016) oraz prodziekana ds. ogólnych WEiTI

(2016–). Od 1996 r. jest kierownikiem Zespołu Robotyki w IAiIS. Od 2007 r. jest

członkiem Komitetu Automatyki i Robotyki Polskiej Akademii Nauk. Jego zainte-

resowania badawcze koncentrują się na zagadnieniach związanych z programo-

waniem i sterowaniem robotów.

mgr inż. Maksym Figat

maksym_figat@pw.edu.pl

ORCID: 0000-0002-1898-0540

Absolwent Wydziału Matematyki i Nauk

Informacyjnych. W 2012 r. uzyskał tytuł inży-

niera, a w 2013 r. tytuł magistra (z wyróż-

nieniem) na specjalizacji „Projektowanie

systemów CAD/CAM”. Jest doktorantem na

Wydziale Elektroniki i Technik Informacyj-

nych Politechniki Warszawskiej (PW). W PW

pracuje od 2014 r. w projektach badawczych

krajowych i międzynarodowych, a od 2018 r.

na stanowisku asystenta badawczo-dydak-

tycznego. Jego zainteresowania badawcze koncentrują się na zagadnieniach

związanych z językami dziedzinowymi, specyfikacja systemów robotycz-

nych, automatyczna generacja kodu sterowników robotów na podstawie

formalnej specyfikacji.

mgr inż. Dawid Seredyński

dawid.seredynski@pw.edu.pl

ORCID: 0000-0003-2528-6335

Jest doktorantem na Wydziale Elektroniki

i Technik Informacyjnych (WEiTI) Politechniki

Warszawskiej (PW). W PW pracuje od 2013 r.

w projektach badawczych krajowych i mię-

dzynarodowych, a od 2018 r. na stanowisku

asystenta naukowo-dydaktycznego. Jego

zainteresowania badawcze obejmują zagad-

nienia związane z planowaniem i realizacja

złożonych zadań przez roboty usługowe.

mgr inż. Wojciech Dudek

wojciech.dudek@pw.edu.pl

ORCID: 0000-0001-5326-1034

Jest doktorantem i asystentem naukowym

w Politechnice Warszawskiej w Instytucie

Automatyki i Informatyki Stosowanej.

Pracował w międzynarodowych gran-

tach badawczych, m.in. RAPP (7PR Komisji

Europejskiej) i INCARE (Active and Assisted

Living JP Komisji Europejskiej). Jego zain-

teresowania naukowe obejmują systemy

sterowania usługowymi robotami mobil-

nymi, ich lokalizacje, nawigacje i harmoni-

zacje ich zadań.

mgr inż. Maciej Stefańczyk

maciej.stefanczyk@pw.edu.pl

ORCID: 0000-0001-9948-6319

Absolwent Wydziału Elektroniki i Technik

Informacyjnych Politechniki Warszawskiej.

W 2010 r. uzyskał tytuł inżyniera, w 2011 r.

tytuł magistra inżyniera, oba z wyróżnie-

niem. W 2011 r. rozpoczął prace nad dokto-

ratem dotyczącym zastosowania aktywnej

wizji wraz z systemami opartymi na bazie

wiedzy w systemie sterowania robotów. Od

2012 r. pracuje na Politechnice Warszaw-

skiej, początkowo jedynie przy realizacji

projektów, a obecnie na stanowisku asystenta. Główne zainteresowania

naukowe obejmują zastosowanie informacji wizyjnej zarówno w robotyce,

jak i systemach rozrywki komputerowej.

Agentowa struktura wielomodalnego interfejsu do Narodowej Platformy Cyberbezpieczeństwa, część 1.

POMIARY•AUTOMATYKA•ROBOTYKA NR 3/2019

Control System of Two Handed Service Robot

Article

Dec 2021

Dawid Seredyński

This work presents an example control system of a service robot. All used concepts, tools and open source software are described. The control system is presented starting from configuration of hardware, specification, up to its implementation. Generality of the image allows the reader to look at the problem globally, while some important, detailed aspects are highlighted. Simulation–related problems are also described. The presented system of WUT Velma robot has been used in many research works.

Ocena wiedzy, umiejętności i postaw studentów Wydziału Filologicznego Uniwersytetu Łódzkiego w zakresie bezpiecznego korzystania z Internetu

Article

Full-text available

Aug 2022

Anna Sikorska

W artykule podjęto rozważania nad kompetencjami studentów Wydziału Filologicznego Uniwersytetu Łódzkiego w zakresie bezpiecznego korzystania z Internetu. Celem badań było poznanie i ocena wiedzy, umiejętności i postaw studentów w obrębie niezagrożonej konsumpcji treści zamieszczanych i spotykanych w sieci każdego dnia, a także innych aspektów związanych z wyzwaniami cyberprzestrzeni. Zwrócono również uwagę na potencjał kompetencji informacyjnych i cyfrowych, których nie powinno brakować szczególnie (choć nie tylko) osobom studiującym. Kluczowe znaczenie mają zatem: ustawiczny rozwój tych umiejętności, pozyskiwanie wiedzy i świadomość potencjalnych zagrożeń. Realizacji wyznaczonych celów posłużyły następujące metody badań: metoda krytycznej analizy literatury przedmiotu, metoda bibliograficzna oraz metoda sondażu diagnostycznego. Niezbędne dla zrozumienia istoty problemu i zagłębienia się w tematykę bezpieczeństwa w sieci było przywołanie definicji „cyberprzestrzeni”, „cyberbezpieczeństwa”, „kompetencji cyfrowych” i „kompetencji informacyjnych” oraz scharakteryzowanie wybranych zagrożeń bezpieczeństwa w sieci, czego dokonano dzięki przeglądowi literatury. W części o charakterze metodologicznym wskazano przedmiot badań, cele i problemy badawcze, określono zasady doboru próby oraz opisano metody, techniki i narzędzia badawcze. Część badawcza stanowi analizę wyników badania ankietowego przeprowadzonego na studentach Wydziału Filologicznego Uniwersytetu Łódzkiego. Badanie przeprowadzone na reprezentatywnej grupie studentów pozwoliło ustalić, jakich trudności związanych z korzystaniem z Internetu studenci Wydziału Filologicznego Uniwersytetu Łódzkiego najczęściej doświadczają, jakich zagrożeń w sieci obawiają się najbardziej, w jaki sposób studenci chronią swoje zasoby, prywatność i wizerunek w Internecie, z jakich źródeł czerpią wiedzę o cyberbezpieczeństwie i jak oceniają swoje kompetencje w tym zakresie. Z analizy można odczytać, że większość badanych ma podstawową wiedzę niezbędną do odpowiedzialnego korzystania z zasobów Internetu oraz umiejętności korzystania z narzędzi umożliwiających lepszą ochronę w cyfrowej przestrzeni. Zaleca się jednak prowadzenie dalszych badań w tym kierunku.

Communication Within Multi-FSM Based Robotic Systems

Article

Full-text available

Mar 2019
J INTELL ROBOT SYST

The paper presents a robotic system design methodology based on the concept of an embodied agent decomposed into communicating subsystems, whose activities are specified in terms of FSMs invoking behaviours parameterised by transition functions and terminal conditions. In the implementation phase, this specification is transformed into a system composed of a whiteboard providing communication means and logically labelled FSMs (LLFSMs) defining the system behaviour. These concepts are used to generate the code of the robot controller. The inclusion of inter-subsystem communication model completes the resulting system design with respect to our previous work that did not account for this model. Thus communication plays a central role in this presentation. The design methodology is exemplified with a rudimentary table tennis ball-collecting robot. The presented methodology and the implementation tools are suitable and beneficial for application to the design of other robotic systems.

Visualization of security event logs across multiple networks and its application to a CSOC

Article

Full-text available

Jan 2019
CLUSTER COMPUT

We introduce VisIDAC presented in Song at al (In: Nguyen, P.Q., Zhou, J. (eds.) Information Security—20th International Conference, ISC 2017, Security and Cryptology, vol. 10599. Springer International Publishing, 2017), which is a 3-D real-time visualization of security event log collection detected by intrusion detection systems installed in multiple networks. VisIDAC consists of three parallel plane-squares which represent global source networks, target networks, and global destination networks. Security events are displayed in different shapes, colors and spaces, according to their main features. It helps security operators to immediately understand the key properties of security events. We also apply VisIDAC to a public cyber security operations center, Science and Technology Cyber Security Center (S&T-CSC), and demonstrate its usefulness. VisIDAC allows users to grasp more intuitively the overall flow of security events and their trend, makes it easy to recognize large-scale security events such as network scanning, port scanning, and distributed denial of service attacks, and is also effective to distinguish security event types: which target network they are related to; whether they are inbound or outbound traffic; whether they are momentary or continuous; and what protocol and port number are mainly used.

Expert-interviews led analysis of EEVi — A model for effective visualization in cyber-security

Conference Paper

Full-text available

Oct 2017

The area of visualization in cyber-security is advancing at a fast pace. However, there is a lack of standardized guidelines for designing and evaluating the resulting visualizations. Furthermore, limited end-user involvement in the design process leads to visualizations that are generic and often ineffective for cyber-security analysts. Thus, the adoption of the resultant cyber-security visualizations is low and this highlights a major research gap. This paper presents expert-interview based validation of EEVi - a model developed to aid in the design and evaluation process of cyber-security visualizations, with a view to make them more effective for cyber-security analysts. A visualization is considered effective if the characteristics of the visualization are essential for an analyst to competently perform a certain task. Thirteen experts were interviewed (six visualization designers and seven cyber-security analysts) and their feedback guided revisions to the model. The responses were subsequently transposed from qualitative data to quantitive data in order to perform statistical analyses on the overall data. This demonstrated that the perspectives of visualization designers and cyber-security analysts generally agreed in their views of effective characteristics for cyber- security visualization, however there was no statistically significant correlation in their responses.

Logics for Multiagent Systems

Article

Full-text available

Sep 2012

Logic can be a powerful tool for reasoning about multiagent systems. First of all, logics provide a language in which to specify properties-properties of an agent, of other agents, and of the environment. Ideally, such a language then also provides a means to implement an agent or a multiagent system, either by somehow executing the specification, or by transforming the specification into some computational form. Second, given that such properties are expressed as logical formulas that form part of some inference system, they can be used to deduce other properties. Such reasoning can be part of an individual agent's capabilities, but it can also be done by a system designer or the potential user of the agents. Third, logics provide a formal semantics in which the sentences from the language are assigned a precise meaning: if one manages to come up with a semantics that closely models the systemunder consideration, one then can verify properties either of a particular system(model checking) or of a number of similar systems at the same time (theorem proving). This, in a nutshell, sums up the three main characteristics of any logic (language, deduction, semantics), as well as the three main roles logics play in systemdevelopment (specification, execution, and verification). Copyright © 2012, Association for the Advancement of Artificial Intelligence. All rights reserved.

Concurrent agent-based evolutionary computations as adaptive dataflows

Article

Sep 2018
CONCURR COMP-PRACT E

This paper introduces a new formal description of the execution model for agent‐based computing systems in the form of an adaptive dataflow decoupled from the domain‐specific semantics of the computation. We show that the execution models studied in previous work can be unified in this common model. The parameters of the model such as queuing policies and granularity of the data in the flow are analyzed. Several queueing alternatives are benchmarked to demonstrate how they affect the efficiency of the computation. Using the example of a multi‐agent evolutionary optimisation problem solver, the new approach is shown to outperform the classic one. This proposed model is well suited to functional languages and can be easily mapped onto different classes of hardware – from simple single‐core computers to distributed environments.

Voila: Visual Anomaly Detection and Monitoring with Streaming Spatiotemporal Data

Article

Aug 2017

The increasing availability of spatiotemporal data continuously collected from various sources provides new opportunities for a timely understanding of the data in their spatial and temporal context. Finding abnormal patterns in such data poses significant challenges. Given that there is often no clear boundary between normal and abnormal patterns, existing solutions are limited in their capacity of identifying anomalies in large, dynamic and heterogeneous data, interpreting anomalies in their multifaceted, spatiotemporal context, and allowing users to provide feedback in the analysis loop. In this work, we introduce a unified visual interactive system and framework, Voila, for interactively detecting anomalies in spatiotemporal data collected from a streaming data source. The system is designed to meet two requirements in real-world applications, i.e., online monitoring and interactivity. We propose a novel tensor-based anomaly analysis algorithm with visualization and interaction design that dynamically produces contextualized, interpretable data summaries and allows for interactively ranking anomalous patterns based on user input. Using the “smart city” as an example scenario, we demonstrate the effectiveness of the proposed framework through quantitative evaluation and qualitative case studies.

Agent-Based Structures of Robot Systems

Conference Paper

Jun 2017

Robot control systems structures based on agents are presented. Agents are classified into 8 categories, with the embodied agent being the most general one. Out of those agents diverse control systems are built. Single/multi-robot systems are considered, where robots can have single or multiple effectors. The presentation of the subject relies on already implemented systems.

Variable structure robot control systems: The RAPP approach

Article

May 2017
ROBOT AUTON SYST

This paper presents a method of designing variable structure control systems for robots. As the on-board robot computational resources are limited, but in some cases the demands imposed on the robot by the user are virtually limitless, the solution is to produce a variable structure system. The task dependent part has to be exchanged, however the task governs the activities of the robot. Thus not only exchange of some task-dependent modules is required, but also supervisory responsibilities have to be switched. Such control systems are necessary in the case of robot companions, where the owner of the robot may demand from it to provide many services.

An overview of the multiagent systems engineering methodology

Article

Jan 2000

BubbleNet: A Cyber Security Dashboard for Visualizing Patterns

Article

Jun 2016

The field of cyber security is faced with ever-expanding amounts of data and a constant barrage of cyber attacks. Within this space, we have designed BubbleNet as a cyber security dashboard to help network analysts identify and summarize patterns within the data. This design study faced a range of interesting constraints from limited time with various expert users and working with users beyond the network analyst, such as network managers. To overcome these constraints, the design study employed a user-centered design process and a variety of methods to incorporate user feedback throughout the design of BubbleNet. This approach resulted in a successfully evaluated dashboard with users and further deployments of these ideas in both research and operational environments. By explaining these methods and the process, it can benefit future visualization designers to help overcome similar challenges in cyber security or alternative domains.

Agent Structure of Multimodal User Interface to the National Cybersecurity Platform – Part 1

Recommended publications

Agent Structure of Multimodal User Interface to the National Cybersecurity Platform – Part 2

Agent-based approach to the design of a multimodal interface for cyber-security event visualisation...

Utilisation of Embodied Agents in the Design of Smart Human–Computer Interfaces—A Case Study in Cybe...

EARL—Embodied Agent-Based Robot Control Systems Modelling Language