mgr inĪ. Piotr Trojanek
prof. nzw. dr hab. Cezary ZieliĔski
Instytut Automatyki i Informatyki Stosowanej Politechnika Warszawska
SPECYFIKACJA ZàOĩONYCH SYSTEMÓW ROBOTOWYCH
Przez záoĪone systemy robotowe rozumiane są takie systemy, które skáadają siĊ z wielu robotów, bądĨ teĪ kiedy roboty wchodzące w ich skáad wyposaĪone są w znaczną liczbĊ czujników lub efektorów. Ich cechą wspólną jest wystĊpowanie skomplikowanych interakcji miĊdzy elementami systemu. W takim przypadku znaczenia nabierają systematyczne metody oraz narzĊdzia, które wspierają wytwarzanie sterowników tej klasy systemów. Odgrywają one istotną rolĊ na wszystkich etapach pracy, począwszy od specyfikacji, przez implementacjĊ, aĪ do testowania i sporządzenia dokumentacji.SPECIFICATION OF COMPLEX ROBOT SYSTEMS
Complex robot systems are those composed of many robots or those, where many sensor and effectors devices are used. Both of them can be characterized with complicated interactions between elements of the system. In this case it is important to use systematized methods and tools, which aids construction of the controllers. They play important role in all the stages of the development, from the specification up to testing and documentation.
1. WPROWADZENIE
W ostatnim czasie coraz wiĊkszą popularnoĞü zyskują metody inĪynierii oprogramowania związane z wytwarzaniem opartym na m odelach (ang. model-driven engineering) [4, 5]. Pozwalaj ą one proces tworzenia oprogramowania potraktowaü jako zbudowanie modelu (specyfikacji), a nastĊpnie jego zautom atyzowane przetwarzanie w celu wytworzenia artefaktów, takich jak szkielet kodów Ĩródáowych czy dokumentacja. W tym podejĞciu wysiáek skoncentrowany jest nie na wytworzeniu pojedynczej aplikacji, ale na opracowaniu m etod specyfikacji m odelu system u oraz jego transformacji do niezbĊdnych artefaktów. Zarówno metody, jak i transformacje, które powstają, nie są zwi ązane z konkretn ą aplikacją, ale pozostaj ą uniwersalne dla ca áej dziedziny problem u. Jako takie mogą byü wielokrotnie stosowanie do rozwiązywania zadaĔ w obrĊbie tej samej klasy.
Kluczowe dla caáego procesu jest zatem okreĞlenie zestawu pojĊü dziedziny (sáownika) oraz zasad ich wzajemnego áączenia (gramatyki) tak, aby w wyniku otrzym aü dedykowany j Ċzyk sáuĪący do specyfikacji z áoĪonych system ów robotowych. Jego zaletam i s ą przede wszystkim wi Ċksza zdolnoĞü ekspresji oraz precyzja form uáowanych wyra ĪeĔ. Dopiero wtedy m oĪna przyst ąpiü do opracowania reguá transformacji modelu systemu na artefakty niezb Ċdne w procesie wytwarzania, dokumentowania oraz testowania sterowników robotowych.
W dalszej cz ĊĞci przedstawiony zosta á sposób konstruowania zbioru poj Ċü dedykowanych do specyfikacji system ów obrotowych oraz ich wzajem nych relacji, a nast Ċpnie nadawania im znaczenia (semantyki).
2. DEFINICJA POJĉû DZIEDZINY
JĊzyk u Īywany do specyfikacji m odeli nazywany jest metamodelem, st ąd j Ċzyk u Īywany do definiowania j Ċzyka jest meta-metamodelem. W celu unikni Ċcia rekursji m eta-metamodele zazwyczaj u Īywane s ą do zdefiniowania sam ych siebie. Form alne definiowanie m odeli wymaga, aby zarówno m etamodel jak i m eta-metamodel by áy tak Īe zdefiniowane form alnie. Przyk áadowe meta-metamodele to diagram y encji [2], czy sk áadnia EBNF ( Extended Backus-Naur Form) [7].
ĝrodowiska wytwarzania opartego na m odelach dostarczaj ą tak Īe swoje specyficzne m eta-metamodele, jak Ecore dla Eclipse Modeling Fram ework [6], GOPRR ( Graph, Object, Property, Role and Relationship) dla MetaEdit+ [4].
Wybór m eta-metamodelu uzale Īniony jest przede wszystkim od dost ĊpnoĞci narz Ċdzi wspierających stworzenie kom pletnego Ğrodowiska m odelowania. MetaEdit+ by áo jednym z pierwszych dostĊpnych komercyjnie narzĊdzi związanych z om awianym podejĞciem [4]. Pakiet Eclipse Modeling Framework [6] jest konkurencyjnym , otwartym Ğrodowiskiem. Dostarcza ono zaawansowanego wsparcia dla jĊzyków modelowania zarówno o graficznej, jak i tekstowej notacji, jak równie Ī narz Ċdzi transform acji w artefakty tekstowe. Poszczególne sk áadniki Ğrodowiska tworzone są w oparciu o standardy OMG (Object Management Group).
2.1. Wprowadzenie do meta-modelu Ecore
Podzbiór m eta-metamodelu Ecore zosta á przedstawiony przy u Īyciu diagram u (rys. 1) wzorowanego na diagram ach klas UML [11]. Klasa reprezentowana jest przy u Īyciu prostok ąta podzielonego na dwie cz ĊĞci – górnej zawieraj ącej nazw Ċ klasy oraz dolnej z jej atrybutam i i typami danych. Sym bole u Īywane dla atrybutów z ró Īnymi warto Ğciami dolnego i górnego ograniczenia iloĞciowego zostaáy zestawione w tabeli.
Rodzaj argumentu Ograniczenie dolne Ograniczenie górne Symbol
opcjonalny 0 1 ß
wymagany 1 1 ß
1
Zdefiniowane s ą trzy rodzaje zwi ązków, oznaczane ró Īnymi sym bolami strza áek. Dziedziczenie uĪywane jest w celu zebrania w áaĞciwoĞci (atrybutów i relacji) innych klas, tzw. bazowych. PojĊcia, które nie reprezentują obiektów dziedziny, ale są poĪyteczne dla modelowania wáaĞciwoĞci innych obiektów, przedstawiane s ą jako klasy abstrakcyjne, z nazwami pisanym i kursyw ą. Zawieranie uĪywane jest do oznaczenia relacji kom pozycji, za Ğ referencja obrazuje po áączenia miĊdzy pojĊciami. Nazwy relacji oraz ich dolne i górne ograniczenia iloĞciowe umieszczane są przy koĔcach strzaáek. Rodzaj relacji Oznaczenie dziedziczenie zawieranie referencja
2.2. Meta-model systemu robotowego
WyjĞciowym poj Ċciem w system ie robotowym jest sam System (rys. 2). Atrybut name jest uĪywany do identyfikacji instancji, za Ğ description jest dodany jedynie w celach
dokumentacyjnych. Te ogólne atrybuty b Ċdą wspólne dla wielu poj Ċü dom eny i m ogą zosta ü wykorzystane do tworzenia nazw oraz komentarzy w generowanych szkieletach kodów Ĩródáowych oraz dokum entacji. System sk áada si Ċ z niezerowej liczby agentów, która zazwyczaj odpowiada liczbie robotów.
Rys. 2. Relacja pomiĊdzy pojĊciem systemu a skáadającymi siĊ na niego agentami 2.2.1. Strukturalna dekompozycja agenta
Agent wykorzystuje sensory oraz efektory sáuĪące odpowiednio do postrzegania i wp áywania na otoczenie, jak równieĪ transmitery, sáuĪące do komunikacji z innymi agentami (rys. 3). Zakáada siĊ przy tym, Īe agent, który zazwyczaj jest uto Īsamiany z pojedynczym robotem, steruje nie wi Ċcej niĪ jednym efektorem . Jednocze Ğnie nie m a ogranicze Ĕ na liczb Ċ sensorów oraz transm iterów. PamiĊü jest związana z wewnĊtrzną zdolnoĞcią agenta do przetwarzania danych. Jest to wymagany skáadnik, bez którego agent nie m oĪe istnie ü, poniewa Ī wtedy nie by áby w stanie przetwarza ü Īadnej informacji.
Rys. 3. Relacja áącząca pojĊcie agenta i jego podsystemy
Sensory, efektory i transm itery róĪnią si Ċ przeznaczeniem, jednak z punktu widzenia projektanta systemu wszystkie one posiadaj ą zdolno Ğü odbierania danych wej Ğciowych oraz publikowania danych wyj Ğciowych. Sk áadają si Ċ one zatem z buforów s áuĪących do odbierania i wysy áania danych, jak zostaáo to zamodelowane przez pojĊcia odpowiednio InputBuffer i OutputBuffer, lecz róĪnią siĊ dolnym ograniczeniem liczebnoĞci relacji inputs i outputs (rys. 4). Sensory wym agają przynajmniej jednego bufora wejĞciowego, zaĞ efektory przynajmniej jednego bufora wyjĞciowego, co odzwierciedla ich zasadniczy kierunek przep áywu danych. W zaleĪnoĞci od wáaĞciwoĞci sprzĊtu czujniki m ogą tak Īe przyjm owaü zlecenia konfiguracyjne, a efektory udost Ċpniaü proprioreceptywne dane o ich aktualnym stanie. Z transm iterami nie s ą zwi ązane ograniczenia liczby buforów, ale wym agają one okre Ğlenia zdalnego agenta (relacja remote), z którym s ą związane. Zak áada si Ċ, Īe relacja ta nie wskazuje na w áaĞciciela transmitera, jak równie Ī, Īe dla kaĪdego transmitera istnieje przynajmniej jeden bufor wejĞciowy lub wyjĞciowy.
Rys. 4. Bufory wejĞciowe i wyjĞciowe uĪywane przez podsystemy skáadowe agenta
Typ danych zwi ązanych z buforam i wej Ğciowymi i wyj Ğciowymi, jak równie Ī z danym i przechowywanymi w pam iĊci wewn Ċtrznej, nie m a wp áywu na ogóln ą architektur Ċ, mi mo t o powinien zosta ü zdefiniowany z dwóch powodów. Po pierwsze, aby przypisa ü szczegó áowe znaczenie wspom nianym poj Ċciom. Po drugie, aby zwi ązaü generowany szkielet kodu z typam i danych zdefiniowanymi w jĊzyku programowania uĪywanym do implementacji. Poáączenie miĊdzy specyfikacją a j Ċzykiem program owania ogólnego przeznaczenia jest realizowane przez poj Ċcie OpaqueData, które áączy instancje klas buforów i danych przechowywanych w pam iĊci wewnĊtrznej z nazwami typów danych zgodnie z atrybutem Type (rys. 5).
Rys. 5. Poáączenie ze zdefiniowanym typem danych 2.2.2. Dekompozycja dziaáania agenta
Aspekt wykonawczy system u wielorobotowego wym aga dekom pozycji jego dzia áania na akcje przypisane poszczególnym agentom . W wi ĊkszoĞci zada Ĕ pojedynczy agent m usi wykonywa ü wiĊcej ni Ī jedn ą aktywno Ğü w czasie swojego Īycia. Ka Īda niezale Īna aktywno Ğü agenta jest nazywana zachowaniem i razem tworzą one repertuar jego zdolno Ğci (rys. 6). Dolne ograniczenie relacji behaviours wynosi 1, poniewa Ī kaĪdy uĪyteczny agent powinien by ü w stanie wykonywa ü przynajmniej jedną czynnoĞü.
Rys. 6. Powiązania miĊdzy agentem a jego zachowaniami
Istnieje wiele sposobów okre Ğlania szczegó áów pojedynczego zachowania, jak równie Ī regu á rządzących przechodzeniem miĊdzy nimi [1]. Zazwyczaj okreĞla siĊ zarówno warunek początkowy jak i ko Ĕcowy, które odpowiednio definiuj ą kiedy zachowanie powinno si Ċ rozpocz ąü oraz zakoĔczyü (rys. 7). Ka Īdy taki warunek reprezentuje predykat (funkcj Ċ Boolowsk ą), którego argumentem jest aktualny stan agenta (tj. zawarto Ğü pam iĊci wewn Ċtrznej oraz stan buforów wejĞciowych i wyj Ğciowych). Zakáada siĊ przy tym , Īe okreĞlenie wartoĞci predykatu (ewaluacja) nie wp áywa na stan agenta, tj. zawarto Ğci jego zm iennych wewn Ċtrznych oraz stanu buforów wyjĞciowych.
Rys. 7. Warunek początkowy i koĔcowy zachowania
Istota zachowania definiowana jest przez funkcjĊ przejĞcia [14], która na podstawie aktualnego stanu agenta (tj. zawarto Ğci pamiĊci wewnĊtrznej oraz stanu buforów wej Ğciowych i wyjĞciowych) wyznacza warto Ğci do wys áania przez bufory wyj Ğciowe oraz uaktualnia te przechowywane w pamiĊci wewn Ċtrznej (rys. 8). Z funkcj ą przej Ğcia zwi ązany jest tak Īe zbiór zdarze Ĕ zewnĊtrznych (relacja events), który okreĞla dane wymagane do kolejnego obliczenia jej wartoĞci i w ten sposób realizowania p Ċtli sterowania. Zwi ązek ten oznaczony jest powi ązaniem z buforam i wejĞciowymi sensorów, efektorów oraz transm iterów, które stanowi ą dla agenta jedyny sposób postrzegania jego sk áadników jak i otoczenia. Funkcja przej Ğcia um ieszcza wynik oblicze Ĕ w okreĞlonych buforach wyj Ğciowych (relacja reactions) i w ten sposób agent oddzia áuje na otoczenie oraz swoje sk áadniki. Zakáada siĊ, Īe zakres relacji wi ąĪącej bufory z funkcj ą przejĞcia nie wychodzi poza pojedynczego agenta.
Rys. 8. Zachowanie jako zbiór funkcji przejĞcia oraz powiązanie z buforami wejĞciowymi i wyjĞciowymi
4. SEMANTYKA POJĉû JĉZYKA DZIEDZINY
Kluczowe dla procesu specyfikacji jest przypisanie znaczenia u Īywanym pojĊciom, zwáaszcza jeĞli chodzi o aspekt wykonawczy systemu wieloobrotowego [13]. SemantykĊ najlepiej jest zdefiniowaü przez okre Ğlenie regu á, które jednoznacznie odwzoruj ą stosowane poj Ċcia na m odel o ju Ī
okreĞlonym sposobie dzia áania, np. j Ċzyk program owania ogólnego zastosowania. Takie rozwiązanie zwi ązuje jednak m etodĊ specyfikacji z konkretn ą platform ą (j Ċzykiem, system em operacyjnym), których szczegóáy czĊsto przesáaniają ogólny obraz dzia áania systemu. Na poziomie specyfikacje korzystniej jest zatem pos áuĪyü si Ċ m odelem, który abstrahuje od szczegó áów implementacyjnych, a pozwala skupiü uwagĊ na zagadnieniach przepáywu danych oraz sterowania. 4.1. Wprowadzenie do sieci Petriego
Sieci Petriego są powszechnie stosowanym m odelem specyfikacji i analizy system ów wspóábieĪnych [9]. Ich zalety, w porównaniu z innym i m odelami, to intuicyjna reprezentacja graficzna oraz ugruntowane metody formalnej analizy wáaĞciwoĞci opisywanego systemu. Byáy one juĪ teĪ wykorzystywane do opisu konkretnych systemów i zadaĔ robotów [12].
Sieü Petriego jest definiowana jako trójka (P, T, A), gdzie P jest skoĔczonym zbiorem miejsc, T jest skoĔczonym zbiorem przej Ğü (P i T są roz áączne, P Q ), za Ğ A okre Ğla relacj Ċ przep áywu,
) ( )
(P T T P
A u u . W notacji graficznej sie ü Petriego jest przedstawiana jako skierowany graf dwudzielny z roz áącznymi zbioram i wierzcho áków odpowiadaj ącymi P i T oraz áukami zgodnie z relacją przepáywu A. Miejsca sieci s ą reprezentowane graficznie za pom ocą okrĊgów, przejĞcia zaĞ í za pomocą prostokątów.
Miejsca reprezentuj ą zazwyczaj stan system u i m ogą zawiera ü dowoln ą niezerow ą liczb Ċ znaczników. Znakowanie M sieci Petriego zdef iniowane jest jako liczba znaczników w ka Īdym z m iejsc, M :Po10. Przej Ğcie jest aktywne, je Ğli w ka Īdym m iejscu po áączonym z nim za
pomocą áuku wej Ğciowego znajduje si Ċ przynajm niej jeden znacznik. Odpalenie aktywnego przejĞcia jest operacją niepodzielną, która pocháania jeden znacznik z kaĪdego miejsca poáączonego z nim áukiem wej Ğciowym i produkuje znacznik w ka Īdym z m iejsc po áączonych áukami wyjĞciowymi.
PrzejĞcia z wielom a áukami wejĞciowym są uĪywane do synchronizacji wspó ábieĪnych czynnoĞci, zaĞ wiele áuków wyj Ğciowych m odeluje rozpocz Ċcie niezale Īnych dzia áaĔ. W celu lepszego modelowania przepáywu sterowania przej Ğcia sieci cz Ċsto rozszerza si Ċ o dozory. Są to wyra Īenia o charakterze predykatów, oznaczaj ące warunki, które dodatkowo m uszą byü speánione, aby dane przejĞcie by áo aktywne. W reprezentacji graficznej um ieszcza si Ċ je w nawiasach kwadratowych obok przejĞcia.
Jedno z bardziej popularnych rozszerze Ĕ om ówionego m odelu, hierarchiczne sieci Petriego [8], pozwalają m odelowaü system na ró Īnych poziom ach szczegó áowoĞci. Przy u Īyciu podstawienia przejĞcia, jednego z podstawowych poj Ċü rozszerzenia, m oĪliwe jest zwini Ċcie fragmentu moduáu sieci do pojedynczego przej Ğcia. ZwiniĊta czĊĞü przedstawiana jest na osobnym module. Moduáy sieci wyĪszego i ni Īszego poziomu zawierają odpowiednio m iejsca gniazdowe (gniazda) portowe (porty). Relacja gniazdo-port wi ąĪe porty m oduáu z m iejscami gniazdowym i podstawianego przejĞcia.
Fuzje są drugim poj Ċciem hierarchii, które pozwala na wym ianĊ znaczników m iĊdzy ró Īnymi moduáami sieci. Miejsca naleĪące do jednej fuzji mogą byü narysowane w kilku egzemplarzach, ale pojĊciowo reprezentują ten sam obiekt.
Podstawienia przejĞü razem z fuzjami stanowią dwa gáówne mechanizmy wspomagające stopniowe projektowanie systemu, odpowiednio przez jego uĞciĞlanie i kompozycjĊ.
Podstawienie przej Ğcia reprezentowane jest graficznie za pom ocą prostok ąta o bokach narysowanych podwójną linią z etykietą nazwy moduáu zawierającego podstawianą sieü, zaĞ porty moduáów í jako m iejsca narysowane lini ą przerywan ą z etykietam i In i Out oznaczaj ącymi odpowiednio port wejĞciowy i wyjĞciowy. Miejsca naleĪące do fuzji oznaczane są wspólną etykietą w prostokątnej ramce.
4.2. Sieci opisujące dziaáanie agenta
Dziaáanie agenta oparte jest na funkcjach przej Ğcia (rys. 8), które stanowi ą podstawowy elem ent warstwy sterowania robota [13]. Sieü, która je reprezentuje, opisuje przechodzenie miĊdzy czterema kolejnymi etapam i: obliczenia kolejnego stanu agen ta, wykonanie akcji, oczekiwanie na zm ianĊ stanu systemu oraz pobranie nowych danych niezb Ċdnych do powtórzenia kroku sterowania (rys. 9). Jedno wykonanie tej sekwencji stanowi akcjĊ elementarną mA
j, gdzie j to identyfikator agenta,
zaĞ m wskazuje na funkcj Ċ przejĞcia związaną z konkretnym zachowaniem. Znacznik pojawia si Ċ w sieci w miejscu portowym oznaczonym etykietą In . Obliczenie wartoĞci funkcji reprezentowane jest przej Ğciem (etykieta Compute next state), po czym w ka Īdym m iejscu sieci zwi ązanym z buforem wyjĞciowym (zgodnie z relacj ą reactions) pojawia si Ċ znacznik. Modeluje to asynchroniczne wys áanie danych przez agenta (etykieta Execute action), który nast Ċpnie przechodzi do stanu oczekiwania (etykieta Wait). Pozostaje on w nim do czasu pojawienia si Ċ danych w buforach wej Ğciowych, co m odelowane jest jako obecno Ğü znaczników w zwi ązanych z nimi miejscach, zgodnie z relacj ą events. Znaczniki konsum owane są przez odpalenie przej Ğcia (etykieta Get new data), po czym ostatni znacznik opuszcza m oduá w m iejscu portowym oznaczonym etykiet ą Out. Bufory wyj Ğciowe jak i wej Ğciowe reprezentowane s ą fuzjam i, dzi Ċki czemu mogą siĊ do nich odwo áywaü zarówno ró Īne funkcje przej Ğcia, jak i agenty. Etykiety tych miejsc mają postaü xcT01, gdzie indeks lewy dolny oznacza odpowiednio bufor wej Ğciowy (x) lub
wyjĞciowy (y), indeks prawy dolny podsystem agenta (T – transm iter, V – czujnik, E – efektor). Indeks prawy dolny drugiego rz Ċdu identyfikuje konkretny bufor w ram ach danego podsystem u [14]. Na rys. 9 zaprezentowano przyk áadową funkcjĊ przejĞcia agenta a0, która oblicza wartoĞci do
przesáania przez transmitery dla dwóch koordynowanych agentów a1 i a2, przy czym pierwsza cyfra
indeksu oznacza w áaĞciciela bufora, a druga agenta zdalnego (zgodnie z relacj ą remote). Sam o przesáanie danych m iĊdzy agentam i zosta áo pom iniĊte na rysunku – jest ono m odelowane pojedynczym przejĞciem áączącym odpowiednie bufory wyjĞciowy i wejĞciowy.
Rys. 9. Moduá sieci Petriego opisujący funkcjĊ przejĞcia
Tak zdefiniowany m oduá zawierający sieü Petriego dla pojedynczej funkcji przej Ğcia moĪe sáuĪyü za u ĞciĞlenie podstawienia przej Ğcia w m odule sieci wy Īszego poziom u, która opisuje cykliczne wykonywanie akcji elem entarnej aĪ do spe ánienia warunku ko Ĕcowego zachowania mB
j (rys. 10).
Sieü ta zawiera przej Ğcia z dozoram i związanymi odpowiednio z warunkiem początkowym (dozór [initial.Condition]) oraz ko Ĕcowym (dozór [terminal.Condition] i jego negacja oznaczona symbolem ), które wczeĞniej zostaáy związane z zachowaniem (rys. 7).
Gáówny m oduá sieci opisuj ącej dzia áanie agenta, aj, zawiera podstawienia przej Ğü zwi ązanych
z moduáami opisuj ącymi poszczególne zachowania (rys. 11). Znacznik (um ieszczony w miejscu oznaczonym etykietą Select behaviour) wskazuje na początkowe znakowanie sieci, tj. stan agenta
w chwili rozpoczĊcia dziaáania systemu. KaĪde z podstawionych przejĞü oznacza jedno z zachowaĔ agenta, które wczeĞniej zostaáy dla niego okre Ğlone (relacja behaviours) (rys. 6). Dziaáanie agenta opisane t ą sieci ą polega na wyborze jednego spo Ğród zachowa Ĕ ze spe ánionym warunkiem początkowym.
Rys. 10. Moduá sieci Petriego opisujący pojedyncze zachowanie
Rys. 11. Gáówny moduá sieci opisujący wybór zachowania przez agenta
Przedstawione sieci stanowi ą struktur Ċ hierarchiczną, gdzie na najni Īszym poziomie znajduje si Ċ pojedyncza akcja elem entarna (rys. 9), która jest cyklicznie wywo áywana w warstwie zachowania (rys. 10). Wybór spoĞród wczeĞniej zdefiniowanych zachowaĔ tego, które w danym stanie systemu powinno by ü aktywne, dokonywany jest w sieci najwy Īszego poziom u. W ykonanie zadania rozumiane jest tutaj nie tylko jako przeprowadzenie wcze Ğniej zdefiniowanej sekwencji zachowa Ĕ [5], ale wybór takiego, które w danym stanie systemu zostaáo przewidziane przez projektanta przez uwaĪną konstrukcjĊ predykatów związanych z ich warunkami początkowymi.
5. PODSUMOWANIE
W artykule zdefiniowano zbiór poj Ċü (tj. ontologi Ċ) u Īywanych do specyfikacji z áoĪonych systemów robotowych. Razem z relacjam i áączącymi okre Ğlone poj Ċcia stanowi on j Ċzyk modelowania specyficzny dla om awianej dziedziny. Zostaá on zdefiniowany formalnie przy uĪyciu narzĊdzi wytwarzania opartego na modelach, dziĊki czemu moĪliwe jest wykorzystanie istniejących narzĊdzi wspom agających generowanie artefaktów takich jak szkielety im plementacji, czy dokumentacja.
Znaczenie poj Ċü i relacji j Ċzyka zosta áo zdefiniowane przez schem aty obrazuj ące ich przeksztaácenie na sieci Petriego, które s ą modelem o form alnie zdefiniowanej sem antyce. W ten sposób zaprezentowana m etoda jest niezale Īna od j Ċzyka program owania czy system u operacyjnego, które zostan ą wykorzystane do im plementacji. Sieci Petriego pozwalaj ą opisywa ü zarówno przepáyw sterowania (z uwzgl Ċdnieniem wspóábieĪnoĞci), jak i danych, oraz m odelowaü komunikacjĊ w system ie rozproszonym . W arstwowa struktura uk áadu steruj ącego zosta áa
zamodelowana przy u Īyciu hierarchii sieci, które jest jedynie rozszerzeniem u áatwiającym modelowanie, zatem nie wp áywa ono na m oĪliwoĞü stosowania dost Ċpnych m etod dla analizy wáaĞciwoĞci sieci (np. wykrywania zakleszczeĔ).
Zaproponowana metoda specyfikacji abstrahuje konkretnej notacji, w której m a byü dokonywana specyfikacja. Mo Īliwe jest zatem tworzenie jej zarówno w form ie tekstowej jak i przypisanie poszczególnym pojĊciom reprezentacji graficznej. Tem at ten nie zosta á tutaj bardziej szczegó áowo poruszony, poniewa Ī dla zastosowanego m eta-metamodelu Ecore istniej ą m etody autom atycznej generacji notacji konkretnej. Zatem z punktu widzenia autorów jest to zadanie m aáo interesujące [10].
Warto zauwa Īyü, Īe zdefiniowanie warstwy w oparciu o sieci Petriego pozwala w ogólno Ğci na stosowanie bardziej záoĪonych struktur niĪ pojedyncze zachowanie, dla przyk áadu juĪ na poziomie sieci wyra Īane m ogą by ü sekwencje czy nawet zestawy wspó ábieĪnie wykonywanych zachowa Ĕ oraz punkty ich synchronizacji.
Praca jest finansowana przez grant badawczy MNiSW N514128733. BIBLIOGRAFIA
1. R.C. Arkin. Behavior-based robotics. The MIT Press, 1998.
2. P. Chen, P. Pin-Shan . The entity-relationship model: Toward a unified view of data. ACM Transactions on Database Systems, 1: 9–36, 1976.
3. G. Karsai, J. Sztipanovits, A. Ledeczi, and T. Bapty. Model-integrated development of embedded software. Proceedings of the IEEE, 91(1):145–164, 2003.
4. S. Kelly, J. P. Tolvanen. Domain-specific modeling: enabling full code generation. W iley-IEEE Computer Society Press, April 2008.
5. Gat, E.; Others. On three-layer architectures. Artificial Intelligence and Mobile Robots, s. 195–210. AAAI Press, 1998.
6. R. C. Gronback. Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit. Addison-Wesley Professional, 2009.
7. International Standard: Inform ation technology. Syntactic metalanguage – Extended BNF. ISO/IEC 14977:1996(E), First Edition, December 1996.
8. K. Jensen and L. M. Kristensen. Coloured Petri Nets: Modeling and Validation of Concurrent Systems. Springer-Verlag New York Inc, 2009.
9. Murata T.: Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77(4):541–580, 1989.
10. Object Managem ent Group. Human-Usable Textual Notation (HUTN) Specification. August 2004.
11. Object Management Group. OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.3. Technical report, May 2010.
12. M. Silva, R. Valette. Petri nets and flexible manufacturing. Advances in Petri Nets 1989. Lecture Notes in Computer Science, vol. 424, s. 374–417. Springer 1990.
13. P. Trojanek, C. ZieliĔski. Specyfikacja systemów wielorobotowych oparta na sieciach Petriego. Metody wytwarzania i zastosowania systemów czasu rzeczywistego. Red. L. Trybus i S. Samo-lej. Wydawnictwa Komunikacji i àącznoĞci, 2010.
14. C. ZieliĔski. Systematic approach to the design of robot programming frameworks. In Proceedings of the 11th IEEE International Conference on Methods and Models
