Wykorzystanie UML i Modeliki w szybkim projektowaniu

Wykorzystanie UML i Modeliki w szybkim projektowaniu

Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
Wykorzystanie UML i Modeliki w szybkim projektowaniu
mechatronicznym
Zbigniew Mrozek,
Politechnika Krakowska, [email protected]
Streszczenie
Przekazywanie informacji odgrywa istotną rolę w działaniu urządzeń mechatronicznych i może być łatwo przedstawione na
diagramach UML. Dodatkowo, na poziomie modelowania szczegółowego, istotną w mechatronice integrację modeli
elementów o różnej naturze można uzyskać przez jednoczesne użycie Simulinka i Modeliki. Zdaniem autora, terminologia
i notacja używana w UML może być zaadoptowana do projektowania interdyscyplinarnych systemów mechatronicznych oraz
jako narzędzie do sporządzania dokumentacji na wszystkich etapach projektowania.
1 Projektowanie jako część cyklu życia produktu
Cykl życia (life cycle) jest pojęciem używanym w inżynierii programowania i oznacza cykl faz, przez które
system przechodzi w okresie tworzenia, eksploatacji oraz konserwacji i modyfikacji oprogramowania. Cykl
życia kończy się z chwilą zaprzestania użytkowania programu. Cykl życia wyrobu mechatronicznego pokazano
na rysunku 1. W porównaniu do metody klasycznej projektowania, najbardziej istotne różnice to:
• Użycie komputerowego wspomagania na każdym etapie projektowania. Pozwala to na szybką realizację
kolejnych kroków projektowania. Powtórzenie realizacji nawet kilku etapów nie stanowi żadnego problemu.
• Proces projektowania ma charakter iteracyjny. Na każdym etapie jest prowadzona weryfikacja uzyskanych
rezultatów i może być podjęta decyzja o ewentualnym cofnięciu tego procesu o jeden lub kilka kroków.
Pętle prototypowania oznaczono podwójnymi liniami. Są to:
1. symulacja off-line z wykorzystaniem modelu symulacyjnego projektowanego wyrobu
2. szybkie prototypowanie w trybie HiL. Mogą tu być wykorzystane fragmenty elementów rzeczywistego
systemu na przykład model fizyczny części mechanicznej systemu z czujnikami i elementami
wykonawczymi lub prototyp fizyczny układu sterowania. Elementy fizyczne współpracują z modelem
wirtualnym pozostałej części systemu poprzez przetworniki analogowo-cyfrowe i cyfrowo-analogowe.
3. szybkie prototypowanie z prototypem sterownika wykonanym w docelowej technologii (ASIC/FPGA
[14,21] lub z użyciem komputera przemysłowego)
Rysunek 1 Mechatroniczne podejście do prototypowania jako fragment cyklu życia wyrobu
16
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
2 Wykorzystanie UML w projektowaniu mechatronicznym
Przekazywanie informacji odgrywa istotną rolę w działaniu urządzeń mechatronicznych i może być łatwo
przedstawione na diagramach UML. Zdaniem autora, terminologia i notacja używana w UML może być
zaadoptowana do projektowania interdyscyplinarnych systemów mechatronicznych oraz jako narzędzie do
sporządzania dokumentacji na wszystkich etapach projektowania. Komputerowe systemy CASE wspomagająceprojektowanie są wykorzystywane nie tylko w części merytorycznej, ale też do zarządzania wymaganiami
użytkowników i procesem projektowania.
Stosowania UML pozwala na ujednolicenie notacji, wczesne wykrywanie luk i niespójności w specyfikacji
wymagań oraz zapewnienie zgodności użytych nazw. Użycie sformalizowanej, graficznej formy
dokumentowania na wszystkich etapach projektowania ułatwia komunikowanie się członków
interdyscyplinarnego zespołu przygotowującego projekt. Pozwala to na przyspieszenie prowadzonych prac oraz
znacznie zwiększa szansę zakończenia sukcesem projektów dużych i złożonych systemów.
Podejście interdyscyplinarne oznacza, że konstrukcja i technologia produkcji wyrobu jest opracowana z
uwzględnieniem różnych systemów i technologii, aby uzyskać efekt synergii (synergia: współdziałanie kilku
czynników dające łączny efekt skuteczniejszy niż suma ich oddzielnych działań).
Członkowie interdyscyplinarnego zespołu mają różne umiejętności. Posługują się odmiennymi sposobami
projektowania i opisu uzyskanych rezultatów. Daje to z jednej strony szansę stworzenia wyrobu, którego nie
mógłby zaprojektować żaden z fachowców pracując oddzielnie. Z drugiej strony stwarza to potrzebę określenia
wspólnego języka (terminologii i notacji), który posłuży im do precyzyjnego, łatwego i jednoznacznego
porozumiewania się i dokumentowania realizowanych etapów projektu. Wspólny język powinien ułatwić
precyzyjne określenie przeznaczenia, funkcji i własności projektowanego produktu i jego elementów
składowych. Takim językiem może być opisany dalej UML. Jest on łatwy do zrozumienia i możliwy do
zaakceptowania przez wszystkich uczestników realizujących projekt.
2.1 Język UML
UML (unified modeling language) stworzono w celu modelowania systemów informatycznych. Jest to język
uniwersalny, obiektowo zorientowany przydatny do projektowania systemów niezależnie od ich przeznaczenia i
od języka, w którym będzie zaimplementowany docelowy system [1-4, 25,26]. Precyzja i uniwersalność notacji
języka UML powoduje, ze ponawiane są próby zastosowania go w dziedzinach innych niż informatyka. Już w
roku 1998 wykorzystano UML do projektowania systemu sterowania taśmociągiem i sortownikiem pojemników
[7]. W dalszej części rozdziału podano przykłady wybranych diagramów UML dla automatu spawającego z
użyciem robota, opisywane przez autora w pracy [12] oraz dla automatycznego tostera.
Model projektowanego systemu ma postać diagramów graficznych. Każdy rodzaj diagramu pokazuje te
elementy przyszłego systemu, które są istotne z wybranego punktu widzenia, a pomija bądź upraszcza inne
elementy. Wysoki poziom abstrakcji pozwala na zwięzły opis nawet bardzo dużych systemów. Jest on
uzupełniany o opis werbalny w postaci scenariuszy oraz komentarze i inne informacje. Oczywistym jest, że
użycie tylko jednego typu diagramu nie jest wystarczające. Praktycznie zawsze wykorzystuje się oba diagramy
statyczne:
• diagram przypadków użycia (use cases)
• diagram klas.
Wybór dodatkowych diagramów jest uzależniony od aktualnych potrzeb i doświadczenia projektantów. Są to:
diagramy dynamiczne (behawioralne):
• diagramy interakcji
o diagram sekwencyjny
o diagram współpracy (collaboration), zwany też diagramem czynności
• diagram aktywności (activity)
• diagram stanu (statechart)
Diagramy implementacyjne:
• diagram komponentów
• diagram konfiguracji (deployment), zwany też diagramem wdrożeniowym
nie są dostosowane do specyfiki projektowania systemów mechatronicznych i nie będą tu omawiane. Ich rolę
może pełnić diagram architektury, przydatny w projektowaniu systemów czasu rzeczywistego. Jest
on zdefiniowany w RtS (Real –time Studio [17]),
17
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
2.2 Kolejność i sposób tworzenia diagramów UML
Punktem startowym projektu realizowanego z wykorzystaniem UML jest specyfikacja wymagań w postaci
scenariuszy i diagramu przypadków użycia (rys. ).
Kolejnym krokiem jest wstępny podział podstawowych funkcji projektowanego wyrobu (są one pokazane na
zrobionym wcześniej diagramie przypadków użycia) na podsystemy mechaniczne, urządzenia wykonawcze oraz
na podsystemy przetwarzające informację. Prowadzi to do wstępnego wyboru struktury systemu. Podsystemy i
wybrane ich elementy mogą być pokazane na diagramie architektury (rys.4) lub jako klasy i obiekty na
diagramie klas (rys.5).
Przy projektowaniu systemów czasu rzeczywistego, w którym dokonuje się rozdziału funkcji na sprzęt i
oprogramowanie, należy przygotować diagram architektury. Pozwala on na łatwe pokazanie kanałów
komunikacyjnych oraz konfiguracji i architektury systemu. Stanowi on dobrą podstawę do omawiania integracji
całego systemu i do przygotowania projektu szczegółowego podsystemów elektronicznych i
mikroprocesorowych.
Uzgodniony ze zleceniodawcą opis tworzonego wyrobu może zawierać błędy i niedokładności. Najwięcej
błędów wykrywa się tworząc diagramy interakcji (sekwencyjny lub współpracy) oraz diagramy stanu. Brak
precyzji lub niejednoznaczność w specyfikacji wymagań uniemożliwia wykonanie tych diagramów i zmusza do
doprecyzowania specyfikacji wymagań. Tak wczesne wykrycie błędów zmniejsza koszty ich poprawiania i
związaną z tym stratę czasu. Błędy w specyfikacji wymagań powinny być usunięte we współpracy ze
zleceniodawcą i przyszłym użytkownikiem.
Rysunek 2 Wykorzystanie języka UML w projektowaniu mechatronicznym (opis w tekscie)
Diagram sekwencyjny (rys.7) i diagram współpracy (rys6) pokazują sposób realizacji funkcji lub usługi podanej
w przypadkach użycia. Są one zarazem graficznym zobrazowaniem informacji zawartych w odpowiednich
scenariuszach. Nazwy klas i obiektów do tych diagramów pobiera się z diagramu klas. Jeśli odpowiedniej klasy
brakuje, to należy ją utworzyć i wpisać do diagramu klas. Można też zmienić nazwę lub opis klasy już
istniejącej, jeśli nie była odpowiednio zdefiniowana.
W rezultacie, przygotowanie diagramów sekwencyjnych (lub współpracy) pozwala na uszczegółowienie i
weryfikację informacji przedstawionych na diagramie klas i zawartej w scenariuszach.
Wszystkie możliwe stany wybranego obiektu można pokazać na diagramie stanu (rys.8). Jest to istotna różnica
w porównaniu do opisanych wyżej diagramów sekwencynych i diagramów współpracy, które pokazują tylko
sekwencje zawarte w wybranym scenariuszu. Przystępując do tworzenia diagramu stanu należy określić stan
18
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
początkowy, stan końcowy (jeśli istnieje) i stabilne stany pośrednie. Następną czynnością jest wyrysowanie
przejść pomiędzy stanami stabilnymi. Warunki przejścia (wyrażenie logiczne) lub nazwę zdarzenia
powodującego przejście podaje się obok linii przejścia, łączącej wybrane stany.
Diagram aktywności (activity diagram) jest odmianą omówionego wyżej diagramu stanów. Pokazuje się w nim
wewnętrzne zmiany stanów systemu lub podsystemu. Zmiany te nie są powodowane przez zdarzenia zewnętrzne
(events), ale przez zakończenia jednego lub kilku (w przypadku procesów równoległych) procesów
wewnętrznych.
Jeśli jakieś uwagi mają być widoczne na ekranie lub na wydrukach, to w wolnym miejscu dowolnego diagramu
można umieścić ikonę notatki (ikona ma postać kartki z podwiniętym rogiem) i wpisać tam potrzebne
informacje. Ikona notatki powinna być dowiązana do dowolnie wybranego elementu diagramu.
2.2.1 Diagram przypadków użycia
Etap analizy rozpoczyna się od uzgodnienia ze zleceniodawcą wymagań i wizji przyszłego wyrobu. Obejmuje to
określenie granic systemu jako całości oraz zebranie i opisanie najważniejszych jego cech i scenariuszy jego
działania.
Diagramy przypadków użycia (use case diagram) tworzy się w oparciu o wymagania zleceniodawcy i przyszłych
użytkowników. Przypadki użycia pozwalają na graficzne pokazanie własności systemu w taki sposób, jak są one
widziane po stronie użytkownika. Funkcje projektowanego wyrobu są przedstawiane w postaci owalnych ikon z
nazwą funkcji lub jej opisem (rys.3). Taka forma specyfikacji jest zrozumiała dla zleceniodawcy i przyszłego
użytkownika, Zarazem jest ona wystarczająco precyzyjna i jednoznaczna, aby mogła być wykorzystana przez
projektantów.
W języku UML definiuje się aktorów, którzy z zewnątrz oddziaływują na pracę systemu. Aktorem może być
zarówno człowiek (użytkownik lub operator systemu) jak i dowolne urządzenie znajdujące się na zewnątrz
projektowanego systemu. W przypadku automatycznego tostera aktorem jest użytkownik wkładający pieczywo
do tostera. Diagram przypadków użycia pokazuje możliwości oddziaływania aktora na system (i odwrotnie).
Symbolem aktora jest uproszczony rysunek przedstawiający człowieka. Zdefiniowanie aktorów pozwala na
precyzyjne określenie granicy pomiędzy projektowanym systemem i jego otoczeniem.
Przypadki użycia są wykorzystane do określenia interfejsu pomiędzy budowanym systemem i jego
użytkownikiem oraz do określenia funkcjonalności i odpowiedzialności podsystemów projektowanego wyrobu.
Rysunek 3 Diagram przypadków użycia dla tostera automatycznego
Wysoki poziom abstrakcji i możliwość pominięcia niepotrzebnych na tym etapie szczegółów pozwalają na
sporządzenie prostego i przejrzystego diagramu przypadków użycia nawet dla bardzo skomplikowanych
systemów. Diagramy przypadków użycia i opisane dalej scenariusze stanowią podstawę wszystkich następnych
etapów projektowania, testowania i odbioru gotowego projektu.
2.2.2 Scenariusz
Scenariusz to opisana w języku naturalnym wybrana sekwencja zachowań i komunikatów wymienianych
pomiędzy aktorami a projektowanym systemem oraz werbalny opis reakcji systemu i aktorów na te komunikaty.
Scenariusz podaje, co dzieje się wewnątrz przypadku użycia. Dla każdego przypadku użycia można podać wiele
różniących się pomiędzy sobą scenariuszy, opisujących typowe zachowania systemu oraz zachowania
wyjątkowe, na przykład w warunkach awarii. Przykładowy scenariusz może wyglądać następująco:
Operator spawarki mocuje na pozycjonerze elementy do spawania. Wybiera z menu program
spawania i zadaje trajektorię ruchu głowicy spawającej. Następnie uruchamia automat
spawalniczy. Automat włącza wydawanie gazu, wody chłodzącej, obcina końcówkę drutu
19
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
elektrody, po czym rozpoczyna spawanie. Jeśli łuk elektryczny nie zajarzy się lub zgaśnie
podczas spawania, automatycznie ponawia się próbę jego zapalenia...
Scenariusze są używane do tworzenia i weryfikacji diagramu przypadków użycia, diagramu sekwencyjnego,
diagramu współpracy i diagramu stanów. Są też używane podczas testowania, weryfikacji i walidacji systemu.
2.2.3 Diagram architektury systemu.
Podczas tworzenia przypadków użycia określa się granice pomiędzy projektowanym systemem i jego
otoczeniem. Jest to właściwa chwila, aby zdefiniować interfejsy pomiędzy systemem a zewnętrznymi aktorami.
W przypadku spawania łukowego z użyciem robota aktorem jest operator (spawacz) i ewentualnie pracownik,
którego zadaniem jest wpisanie i konserwowanie biblioteki programów spawania (aktor Programowanie).
Przykładem aktora jest także łuk spawalniczy (aktor Luk_spaw), który czasem nie zapala się albo
nieoczekiwanie gaśnie. Łuk spawalniczy jest zjawiskiem zewnętrznym względem spawarki. Parametry łuku
spawalniczego są mierzone i rejestrowane przez system, a w wypadku niezajarzenia się łuku lub jego zgaśnięcia,
uruchamiane są procedury obsługi wznowienia pracy spawarki.
W odróżnieniu od systemów informatycznych, systemy mechatroniczne mają często dedykowany hardwarowy
interfejs użytkownika w postaci specjalizowanych wyświetlaczy, przycisków pokręteł i innych elementów.
spawarka System Architecture Diagram
SYSTEM Gniazdo Spawalnicze
subsystem_pozycjoner
CAN
subsystem_Robot
Subs._szafa_sterownicza
CAN
naped_pozycjonera
sterownik_robota
sterownik_pozycjonera
zasilacz_spaw
naped_robota
CAN
can
glowica_spaw-
CAN
ajaca
CAN
Luk_spaw
Programowa
i
CAN
konsola_opera-
wydawanie_drut
u gazu_i_wody
tora_spawarki
Operator
Rysunek 4 Diagram architektury dla systemu spawania łukowego z użyciem robota
Czujniki (tensometry, enkodery, etc) i elementy wykonawcze (serwomechanizmy i silniki) powinny być
wybrane w początkowej fazie projektowania, co potwierdza Gawrysiak [7]. Grega [5] wskazuje na potrzebę
wczesnego wyboru protokołów i standardów. Decyzje te są istotnym poszerzeniem informacji zawartych w
diagramie przypadków użycia i powinny być uwzględnione podczas analizy specyfikacji projektowania
systemu. Tego typu informacje można przedstawić na diagramie architektury systemu w pakiecie RtS [17] który
jest rozszerzeniem języka UML. Diagram architektury jest ukierunkowany na pokazanie konfiguracji systemów
czasu rzeczywistego.
2.2.4 Obiekty i klasy
Kolejnym krokiem jest zidentyfikowanie (wyszukanie) obiektów i klas. Diagram klas określa strukturę
wewnętrzną systemu i jego podsystemów. Szczegółowość przedstawienia struktury budowanego systemu na
diagramie klas jest znacznie wyższa, niż można to pokazać na diagramie architektury. Wstępną wersję diagramu
klas buduje się w oparciu o wiedzę o systemie, zawartą w scenariuszach i w diagramie przypadków.
W przypadku systemów mechatronicznych, obiektami są urządzenia bądź ich wydzielone podzespoły,
sterowniki lub ich bloki funkcjonalne oraz interfejsy, czujniki i elementy wykonawcze. Obiekty realizują
czynności opisane przez przypadki użycia i scenariusze. Analiza rzeczowników i czasowników w scenariuszu
pomaga zidentyfikować obiekty, a także ich atrybuty i metody. Rzeczowniki są kandydatami na nazwy
obiektów, klas i ich atrybutów, a czasowniki są kandydatami na nazwy metod. W miarę postępu prac
projektowych diagramy będą uzupełniane o dodatkowe obiekty i klasy, a ich opis będzie uzupełniany o nowe
atrybuty, metody i inne elementy.
20
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
Wstępną postać diagramu klas można utworzyć już na etapie analizy systemu, w oparciu o scenariusz i diagram
przypadków użycia. Autor nie zna sposobu, które by pozwolił: poprawnie i jednoznacznie zidentyfikować
wszystkie obiekty oraz przypisać im wszystkie właściwe atrybuty i metody. Tworzenie diagramów jest procesem
iteracyjnym i nie należy się przy tym śpieszyć. Te same obiekty i klasy są wykorzystywane do budowy różnych
diagramów. Przygotowując kolejne diagramy, można tworzyć brakujące obiekty (lub modyfikować obiekty już
istniejące) w taki sposób, aby miały potrzebne w danym momencie atrybuty i metody.
Rysunek 5 Diagram klas dla zrobotyzowanego stanowiska spawalniczego. Podwójna linia
pozioma w pod nazwami ::sterow_robota oraz ::drut_woda_gaz pokazuje, że pominięto
atrybuty.
Diagram klas dla automatu spawalniczego pokazano na rysunku (rys.5). Notacja używana w diagramie klas
i w diagramie obiektów jest następująca: trzy prostokątne przedziały zawierają (poczynając od góry) kolejno:
1. nazwę (podanie nazwy jest obowiązkowe),
2. atrybuty (można pominąć)
3. metody danego obiektu lub klasy (można pominąć).
Linie łączące obiekty i klasy oraz umieszczone tam komentarze (dokładniej role i komunikaty) pokazują
wzajemne relacje obiektów lub klas. Odczytuje się je następująco: konsola_operatora steruje
zasilacz(em)_spaw(arki). Linie zakończone rombem oznaczają relację zawierania (przynależności), np.
głowica_spaw należy do zasilacz(a)_spaw(arki).. Cyfry i gwiazdki określają krotność występowania obiektów
danej klasy np. jedno (1) zrobotyzowane stanowisko spawalnicze oraz (*)jeden lub więcej zasilacz spawarki
(*)jeden lub więcej robot. Dziedziczenie oznacza się linią z domkniętą trójkątną strzałką. Strzałka zawsze
wskazuje rodzica. Może to prowadzić do błędów, gdyż intuicyjnie postrzegany jest zazwyczaj odmienny
kierunek dziedziczenia: od rodziców do dzieci, co jest niezgodne z UML.
2.2.5 Diagram sekwencyjny i diagram współpracy
Diagram sekwencyjny (rys.6) i diagram współpracy (rys.7) są uszczegółowieniem diagramu przypadków użycia.
Pokazują one wybraną sekwencję działań aktora oraz reakcję obiektów z projektowanego systemu na te
działania.
Rysunek 6 Diagram sekwencyjny dla automatycznego tostera
Pokazują, co robi wywołany obiekt, aby zrealizować zadania podane w diagramie przypadków użycia, w sposób
opisany w scenariuszu. Oba diagramy pokazują współpracę obiektów. Jest ona poprzedzana poprzez wymianę
komunikatów z żądaniem, aby wołany obiekt wykonał określone czynności. Komunikat można tu traktować jako
21
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
wywołane metody kolejnego, wołanego obiektu. Diagram współpracy (rys.7) pokazuje te same obiekty co
diagram sekwencyjny. Są one uporządkowane i ponumerowane w kolejności ich reagowania na działania aktora
i innych obiektów. Ten sam obiekt może wystąpić wielokrotnie, jeśli był wielokrotnie aktywny.
Rysunek 7 Diagram współpracy dla automatycznego tostera
2.2.6 Diagram stanów
Opisane powyżej diagramy sekwencyny i współpracy pokazują tylko niektóre sekwencje działania aktorów
i wybranych obiektów, odpowiadające wybranemu scenariuszowi. Wszystkie możliwe stany wybranego obiektu
można pokazać na diagramie stanu,. opartym na formalizmie graficznym Harel’a [1987]. Diagram stanu pozwala
na czytelny i zwarty opis logiki systemu reaktywnego, w którym sygnały wyjściowe zależą nie tylko od
sygnałów wejściowych, ale też od stanu wewnętrznego tego systemu. Kolejne stany obiektu są pokazane jako
prostokątne bloki o zaokrąglonych krawędziach. Stan początkowy systemu jest oznaczony przejściem z czarną
kulką, a stan końcowy przejściem z czarną kulką w okręgu. Systemy wbudowane (embedded) są przeznaczone
do pracy ciągłej i nie mają stanu końcowego.
Rysunek 8 Przykład diagramu stanów dla automatu spawalniczego(MATLAB/STATEFLOW)
Jeszcze więcej możliwości daje wykorzystanie na tym etapie specjalizowanego oprogramowania (np.
STATEFLOW w połączeniu z MATLAB i SIMULINK, opisane przez autora w pracy [9]) obsługującego
diagramy stanów. Zaletą takiego podejścia jest możliwość stworzenia wirtualnego prototypu i symulacji jego
pracy metodą HiL (hardware in the loop). Wadą jest wyjście poza środowisko narzędzi CASE i utrata
możliwości automatycznego aktualizowania diagramów w oparciu o bazę danych systemu CASE.
2.2.7 Diagram aktywności (czynności)
Diagram aktywności (activity diagram) jest odmianą diagramu stanów. Pokazuje się w nim zmiany stanów, które
nie są powodowane przez zdarzenia zewnętrzne (events), ale przez zakończenie jednego lub kilku (w przypadku
procesów równoległych) procesów wewnętrznych. Na rysunku 9 przedstawiono czynności wykonywane
podczas przygotowania spawarki do pracy. Na diagramie pokazano możliwość równoczesnego włączenia wody i
22
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
gazu oraz wysunięcia drutu. Pozostałe czynności są wykonywane w odpowiedniej kolejności. Pogrubione linie
służą do synchronizacji procesów. Na diagramie pokazano, że ruch głowicy (do punktu startowego) można
wykonać po włączeniu wody chłodzącej, gazu ochronnego (obojętnego lub aktywnego) oraz wysunięciu i
obcięciu końcówki drutu, będącego elektrodą spawającą. Znaczenie diagramu aktywności polega na pokazaniu
możliwości równoległego wykonywania pewnych czynności.
Rysunek 9 Diagram aktywności dla procesu przygotowania spawarki
2.3 Pakiety oprogramowania CASE wspomagające użycie UML
Produkty firmy Rational Inc, wykazują bardzo wysoki stopień zgodności ze standardem języka UML. Są one szeroko
stosowane przy tworzeniu systemów informatycznych na potrzeby banków, linii lotniczych oraz innych
zleceniodawców. Rational Rose służ do modelowania wizualnego w jęzku UML. Rational Rose RT jest przeznaczone
do wspomagania projektowania systemów oprogramowania czasu rzeczywistego.
Real-TimeStudio (RtS) z Artisan Software Tools Inc, jest określany przez producenta jako narzędzie
wspomagające projektowanie systemów czasu rzeczywistego. Z punktu widzenia projektanta systemów
mechatronicznych jest on łatwiejszy w obsłudze. Oferuje też rozszerzenie języka UML o dodatkowe diagramy, z
których najważniejszym dla zastosowań mechatronicznych jest diagram architektury.
Reasumując, pakiet RtS jest mniejszy Rational Rose i posiada część możliwości, które w przypadku Rational
Rose wymagają innych programów z zestawu Rational Suite. Doświadczenie autora pokazuje, że RtS jest lepiej
dostosowane do wymagań projektowania systemów mechatronicznych, niż konkurencyjne produkty.
3 Oprogramowanie wspomagające modelowanie i symulację
Do projektowania oraz symulacji układów sterowania autor używa program MATLAB z rozszerzeniem
SIMULINK i STATEFLOW. Zastosowany w tym systemie interfejs graficzny umożliwia analizę oraz syntezę
układu sterowania na poziomie bloków funkcjonalnych. Odciąża to projektanta od ręcznego pisania kodu
sterownika oraz umożliwia łatwe i szybkie zmiany projektowanego układu sterowania. Dodatkowe rozszerzenie
RTW (real time workshop) przetwarza schematy blokowe SIMULINKA i STATEFLOW na program w języku
C, co umożliwia symulację on-line i w trybie HiL.
Opisy innych pakietów CACSD (computer aided control system design) wspomagających projektowanie
systemów sterowania, w tym narzędzi do programowania sterowników logicznych PLC są podane przez. Grega
w [5].
3.1 Modelica
Istotą podejścia zastosowanego w Modelice jest modelowanie fizyczne. Oznacza to, że połączenie ikon
elementów na schemacie blokowym realizuje prawa fizyki obowiązujące w miejscu połączenia. Jest to pewna
analogia do grafu wiązań (Bond grafu), a zarazem istotna różnica w porównaniu do SIMULINKA, gdzie
połączenia bloków służą jedynie do jednokierunkowej transmisji informacji. Przy omawianiu własności
Modeliki, autor wykorzystuje pakiet Dymola, który dostarcza narzędzia do tworzenia tych modeli i wykorzystuje
modele z Modeliki do symulacji.
23
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
Istotnym usprawnieniem projektowania interdyscyplinarnego w Modelice jest ujednolicenie sposobów tworzenia
i zapisu modeli. Umożliwia to łatwe tworzenie modeli złożonych, zawierające elementy i podsystemy o różnej
naturze fizycznej, pochodzące z różnych pakietów symulacyjnych.
Przy tworzeniu Modeliki pracowali naukowcy, przedstawiciele przemysłu i niewielkich firm softwarowych.
Język Modelica został stworzony zbiorowym wysiłkiem twórców kilku wcześniejszych, obiektowozorientowanych języków: Propozycje standaryzacji w zakresie modelowania przez długi czas nie miały wsparcia
ze strony wiodących producentów. Powodem mogła być obawa o utratę części dotychczasowych rynków zbytu i
zmniejszenia dochodów. Sytuacja zmieniła się, gdy realizację tego problemu podjęto w ramach projektu ESPRIT
"Simulation in Europe Basic Research Working Group (SiE-WG)", finansowanej przez Wspólnotę Europejską.
Autor tej pracy uczestniczył we wczesnym etapie prac SiE-WG podczas odbywania stażu na uniwersytecie w
Gandawie (Belgia) w roku 1995.
Standardowa postać modeli z bibliotek Modeliki może być wykorzystana przez dowolny pakiet symulacyjny pod
warunkiem zastosowania odpowiedniego translatora. Powinien on dokonać przekształceń symbolicznych
równań różniczkowych (ODE) i różniczkowo-algebraicznych (DAE). Potrzebna jest też analiza struktur
dziedziczenia klas modeli i połączeń bloków w schematach graficznych oraz wiele innych operacji. Nie jest to
problem banalny, gdyż Modelika akceptuje równania źle uwarunkowane i w postaci uwikłanej. Problemy te
zostały rozwiązane przez niektórych producentów oprogramowania:
• Dymola z firmy Dynasim AB (uczestnik zespołu opracowującego Modelikę), w wersji 4 jest w pełni
zintegrowana z Modeliką. Język ten opisano w dalszej części pracy
• MathModelica z firmy MathCore wraz z Modeliką tworzy środowisko symulacyjne, które może być
zintegrowane z pakietami Mathematica oraz Microsoft Visio.
MATLAB i Dymola uzupełniają się wzajemnie. Mogą one współpracować ze sobą dzięki narzędziom
opracowanym przez Dynasim AB (producent Dymoli i. Pozwala to na wykorzystanie bogatych bibliotek obu
pakietów do modelowania systemów o różnej naturze fizycznej oraz wykorzystanie ich do prototypowania w
czasie rzeczywistym.
W Modelice przyjęto, że równania różniczkowe (ODE: ordinary differential equations) i równania różniczkowoalgebraiczne (DAE: differential analog equations), opisujące zjawiska zachodzące w modelowanym urządzeniu,
nie muszą być przekształcane do równania stanu w postaci:
dx / dt = f ( x, u )
y = g ( x, u )
(1)
gdzie
x – wektor zmiennych stanu
u – wektor zmiennych na wejściu
y – wektor zmiennych na wyjściu
Pakiet Modelica akceptuje równania w postaci niejawnej deklaratywnej (2), umożliwiającej późniejsze
przypisanie zmiennych modelu do wejść i do wyjść systemu Błąd! Nie można odnaleźć źródła odwołania.:
f (t , dx / dt , x, y ) = 0
(2)
gdzie:
x – wektor zmiennych dynamicznych (ich pochodna występuje we wzorze)
y – wektor zmiennych algebraicznych (pochodna nie występuje we wzorze)
t – czas
Oznacza to, że równanie (2), w przypadku wielkości dualnych (takich, jak prąd i napięcie w układach
elektrycznych lub siła i przesunięcie w układach mechanicznych) nie określa, która wielkość jest wymuszeniem,
a która odpowiedzią obiektu. W powyższym równaniu x, y to nieznane wektory zmiennych, przy czym równanie
zależy też od pochodnych wektora x. Przykładowo model dwójnika szeregowego RC może być wykorzystany do
obliczenia zależności prądu ładowania od przyłożonego napięcia i czasu, a też pozwala obliczyć napięcie na
kondensatorze w funkcji przepływającego prądu i czasu.
Zaletą takiego podejścia jest możliwość wykorzystania tego samego modelu niezależnie od sposobu pobudzania
modelowanego systemu. Właściwą postać równań czyli przeniesienie odpowiednich zmiennych układu równań
na lewą stronę jest dokonywane przez oprogramowanie symulacyjne.
24
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
3.1.1 Biblioteka standardowa i biblioteka dodatkowa modeli
Modelica jest dostępna w Internecie bezpłatnie wraz z dwoma pakietami bibliotecznymi: standardowym i
dodatkowym (additions). Biblioteka ThermoFluid jest dostępna nieodpłatnie pod adresem
www.SourceForgeProject/Modelica.htm. Dodatkowo można dokupić biblioteki oferowane jako opcje pakietu
Dymola (rozdział 3.2). Są to: HyLib (Hydraulics library) i Powertrain (układy przekazywania mocy w
pojazdach). Biblioteki Modeliki mają wielopoziomową strukturę hierarchiczną. Poniżej pokazano ikony z
biblioteki specjalistycznej elementów obrotowych z biblioteki podstawowej Modeliki.
Rysunek 10 Biblioteka podstawowa: bloki elementów obrotowych
Modelika jest obiektowo-zorientowana i każdy jej element ma pola, w których przechowywane są wszystkie
istotne, z punktu widzenia celu symulacji, parametry wybranego bloku. Przypisanie parametrom potrzebnych
wartości jest wykonywane w sposób dogodny dla użytkownika, w oparciu o typowe dane katalogowe dla
wybranego urządzenia.
W modelu przekładni (rys.11) wejściem jest moment i kąt na wale_a (ang. flange_a), a wyjściem jest kąt i
moment przyłożony na wale_b przekładni (ang. flange_b). Prócz tego określa się wartości następujących
parametrów:
• Przełożenie (ratio),
• Sprawność (gear efficiency) uwzględniająca straty na tarcie w zębach przekładni,
• tarcie w łożyskach, mokre (friction_pos) i suche (peak)
• elastyczność, tłumienie i luzy
Jeśli niektórym parametrom nie nadano wartości, to przyjęte zostaną wartości domyślne.
Rysunek 11 Model przekładni
Rozdzielenie tarcia w łożyskach, tarcia w zębach przekładni i tarcia suchego umożliwia poprawną symulacje
przy uruchamianiu i zatrzymaniu przekładni oraz przy pracy z dowolną prędkością.
3.2
Dymola
W grupie programów przydatnych do modelowania złożonych urządzeń mechatronicznych należy zwrócić
uwagę na Dymolę (dynamic modeling language) – obiektowo zorientowany pakiet do modelowania i symulacji
obiektów fizycznych. Dymola wykorzystuje modele w standardzie Modeliki, co ułatwia symulowanie układów
o mieszanej naturze fizycznej: mechanicznych, elektrycznych, termodynamicznych, chemicznych oraz innych,
25
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
opisanych równaniami lub modelami Modeliki. Dymola jest oferowana dla Windows 98/2000/NT/ME oraz dla
Unix i Linux.
Połączenie elementów Modeliki na schemacie blokowym służy nie tylko do jednokierunkowej transmisji
informacji (jak w SIMULINKU), lecz realizuje prawa fizyki obowiązujące w miejscu połączenia. Wbudowany
do Dymoli translator może dokonać symbolicznego przekształcenia ponad 100 000 równań dla potrzeb
symulacji. Edytor graficzny pozwala na przeglądanie, edycję i tworzenie nowych modeli. Dymola wspomaga
symulację w czasie rzeczywistym (również HiL), ale może też wygenerować M-pliki do Matlaba i bloki
podsystemów SIMULINKA, działające w oparciu o S-funkcję (C-Mex plik). Umożliwia to pełne wykorzystanie
możliwości SIMULINKA. Przeniesione z Dymoli bloki podsystemów mogą być kompilowane przez Real Time
Workshop i wykorzystane do prototypowania w środowisku dSPACE w czasie rzeczywistym. Połączenie
Modeliki z SIMULINKIEM (poprzez Dymolę) ułatwia prototypowanie bardzo dużych i skomplikowanych
systemów, których model można przygotować w Modelice. Wyniki obliczeń Dymoli sa zapisywane w binarnym
formacie MAT-pliku, co umożliwia ich przetwarzanie w środowisku MATLABA.
4 Wnioski końcowe
W systemie mechatronicznym współpracują z sobą elementy i podsystemy o różnej naturze fizycznej: układy
mechaniczne, elektryczne, elektroniczne oraz oprogramowanie. O jakości całego systemu decyduje współpraca
jego elementów składowych (daje to efekt synergii) oraz parametry najsłabszego elementu.
Złożoność współczesnych konstrukcji oraz konieczność (ze względu na konkurencyjność rynku) skrócenia czasu
powstawania produktu powoduje, że projekty nowych wyrobów są zazwyczaj tworzone przez wieloosobowe
zespoły fachowców różnych specjalności. Proces projektowania może być wspierany przez narzędzia
CAD/CAM, CAE, PDM i CASE oraz przez odpowiednią organizację pracy zespołu projektantów. Powszechne
jest wykorzystywanie komputerowych systemów wspomagania - nie tylko w części merytorycznej, ale też do
zarządzania wymaganiami użytkowników i procesem projektowania [10, 17-24].
Nowym i bardzo efektywnym narzędziem do modelowania systemów interdyscyplinarnych jest język Modelica.
Jest on oparty na koncepcji modelowania fizycznego, co oznacza wymóg spełniania obowiązujących praw fizyki
w złączach używanych do połączenia elementów składowych modelu złożonego. Jest zasadnicza zmiana w
porównaniu do dotychczasowych narzędzi (np. SIMULINK), gdzie połączenie elementów schematu blokowego
oznaczało przekazywanie tylko informacji i tylko w jednym kierunku. Pakiet symulacyjny Dymola może być
stosowany do modelowania układów o mieszanej naturze fizycznej: mechanicznych, elektrycznych,
termodynamicznych, chemicznych oraz innych, opisanych równaniami lub zawartych w bibliotekach. Dymola
jest zgodna ze standardem modelowania języka Modelica. Modele symulacyjne są tworzone przez graficzne
łączenie ikon z bibliotek Modelicy. Wyniki obliczeń są zapisywane w MAT-pliku, w standardzie MATLABA i
mogą być przedstawione na wykresie jako funkcja czasu lub innej zmiennej. Oba pakiety, MATLAB i Dymola
uzupełniają się wzajemnie. Mogą one współpracować ze sobą dzięki narzędziom opracowanym przez
producenta Dymoli. Pozwala to na wykorzystanie bogatych bibliotek obu pakietów do modelowania systemów
o różnej naturze fizycznej oraz wykorzystanie ich do prototypowania w czasie rzeczywistym.
Stosowanie języka UML do modelowania struktury i działania dużych i bardzo dużych systemów umożliwia
ujednolicenie notacji, wczesne wykrywanie luk i niespójności w specyfikacji wymagań. Istotne jest też
automatyczne zapewnienie przez pakiet CASE zgodność nazw i opisów elementów projektowanego systemu na
wszystkich diagramach i w dokumentacji systemu [11-13]. Narzędzia CASE istotnie zwiększają efektywność
i produktywność, pozwalając na skrócenie czasu tworzenia końcowego produktu. Ułatwiają też wprowadzenie
sterowania jakością oraz identyfikację odpowiedzialności, zgodnie z normami ISO 9000. Zdaniem autora
stosowanie UML jest uzasadnione nawet przy realizacji niewielkich projektów interdyscyplinarnych.
Możliwości języka UML zostały szybko docenione przez rynek. Pakiety CASE (computer aided system
engineering) oferują narzędzia wspomagające kolejne etapy komputerowego wspomagania projektowania z
wykorzystaniem języka UML. Obecnie oferowane jest ponad 60 pakietów oprogramowania o różnej jakości,
wspierających wykorzystanie UML. Dwa z nich: Rational Suite i Real Time Studio zostały wykorzystane w tej
pracy. Umożliwiają one automatyczne dokumentowanie prac i wprowadzanych zmian. CASE sprawdza też
formalną poprawność i zgodność wykonywanych diagramów z diagramami wcześniej przygotowanymi.
Pozwala to na automatyczne wychwycenie błędów formalnych i braku spójności różnych elementów projektu.
W rezultacie koszt i strata czasu na dokonanie poprawek i modyfikowanie projektu są relatywnie niskie, gdyż
znaczną ich część wykonuje się we wczesnym etapie realizacji projektu. Stosowanie narzędzi CASE poprawia
26
Projektowanie Mechatroniczne, Zagadnienia wybrane, red. T.Uhl, KRiDM AGH Kraków, 2002,
komfort pracy projektantów i wydaje się niezbędne nawet przy tworzeniu niewielkich systemów. Dodatkowym
walorem jest automatyczne generowanie dokumentacji budowanego systemu przez narzędzia CASE.
Autor składa podziękowanie firmom ARTiSAN Software Tools, Inc (GB); Rational Software Corporation (USA) i Premium
Technology Sp zoo za bezpłatne udostępnienie wersji ewaluacyjnej programów: Real-time Studio, Rational Rose Suite
i Rational Rose RT, firmom The MathWorks Inc(USA) i ONT(Kraków) za udostępnienie pakietu MATLAB z bibliotekami i
firmie Dymosim AB za udostępnienie pakietu Dymola..
5 Literatura
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
Booch, G. Rumbaugh, J. Jacobson I The Unified Modelling Language User Guide, Addison Wesley,
1999, WNT Warszawa 2000
Bruegge B, Dutoit A, Object-Oriented Software Engineering: Conquering Complex and Changing
Systems, Prentice-Hall, 1999,
Douglas, B.P. Real-time UML: Developing Efficient Objects for Embedded Systems. Addison Wesley,
1998.
Douglas, B.P. Designing Real-time Systems with UML, Part I-III, Embedded Systems, 03-05,1998.
Elmqvist H, Mattsson S.E, Otter M, Modelica — the new object-oriented modeling language, 12th
European Simulation Multiconference ESM'98, Manchester, UK1998
Grega Wojciech, Sterowanie cyfrowe w czasie rzeczywistym, Wyd. WEAIiE AGH Kraków, 1999
Gawrysiak M. Etapy projektowania mechatronicznego wg. R. Isermanna (w T.Uhl, Warsztaty
projektowania mechatronicznego), Kraków 2002
McLaughlin Michael J., Moore Alan, Real-Time Extensions to UML, Timing, concurrency, and
hardware interfaces, Dr. Dobb's Journal December 1998
Mrozek B, Mrozek Z, MATLAB 6, poradnik użytkownika Wydawnictwo PLJ, Warszawa 2001.
Mrozek Z Sterowanie elastycznym ramieniem robota, str 178-210 w Wybrane problemy
projektowania mechatronicznego , red. T. Uhl, KRiDM AGH, 1999
Mrozek Z, UML as integration tool for design of the mechatronic system, Second Workshop on Robot
Motion and Control, pp:189-195, Oct 18-20, Bukowy Dworek, 2001
Mrozek Z, Metodyka wykorzystania UML w projektowaniu mechatronicznym, Pomiary Automatyka
Kontrola Nr 1, pp.25-28, 2002
Mrozek Z, Mrozek B, Adjei O, Teaching object oriented software engineering with UML, 13-th
Annual Conference on Innovations in Education for Electrical and Information Eng, York, 2002
Mrozek Z, Komputerowo wspomagane projektowanie systemów mechatronicznych, Zeszyty
Naukowe Politechniki Krakowskiej, seria Inżynieria Elektryczna i Komputerowa nr 1 (2002,
w przygotowaniu)
Petko M. Implementacja układów sterowania w układach ASIC/FPGA, Pomiary Automatyka Kontrola
Nr 1, pp.18-21, 2002,
Rational Rose, Rational Rose RT (i inne oprogramowanie z Rational Software Corporation),
Real-time Studio, ARTiSAN Software Tools, Inc. July 2001,
Uhl T (edytor), Bojko T, Mrozek Z, Petko M, Szwabowski W, Korendo Z, Bogacz M, Wybrane
problemy projektowania mechatronicznego, Wydawnictwo Katedry Robotyki i Dynamiki Maszyn,
AGH Kraków 1999.
Uhl T System komputerowego wspomagania projektowania mechatronicznego, Pomiary Automatyka
Kontrola Nr 1, pp.14-17, 2002
Uhl T, Bojko T, Mrozek Z, Szwabowski W, Rapid prototyping of mechatronic systems, Journal of
Theoretical and Applied Mechanics, pp.655-668, vol.38.3, 2000
Uhl T, Bojko T, Mrozek Z, Petko M, Szwabowski W, Korendo Z, Bogacz M; - Wybrane problemy
projektowania mechatronicznego, Katedra Robotyki i Dynamiki Maszyn, AGH Kraków 1999."
Uhl T, Mrozek Z, Petko M Rapid control prototyping for flexible arm, Preprints of 1-st IFAC
Conference on Mechatronic Systems, vol II, pp 489-494, Darmstadt, September 18-20, 2000.
Uhl T, Bojko T, Mrozek Z, 1999, Mechatronic Approach Towards Designing and Implementing of
Control Systems, Proceedings of the First Workshop on Robot Motion and Control pp 135-140 ,
RoMoCo, Poznan , June 28-29,
Uhl, Bojko, Mrozek, Szwabowski, Sterowanie elastycznym ramieniem robota - szybkie
prototypowanie i implementacja I Krajowych Warsztatów Metod Szybkiego Prototypowania,
Kraków, 26-27 listopad 1998
Uhl T, Śliwa Z, Wybrane zagadnienia systemów CAD/CAM i ich zastosowań, CCATIE Kraków 1996.
UML for Real Time System Design,, ISG 1998
OMG Unified Modeling Language Specification v.1.4, Sept. 2001. (oraz inne dokumenty
z OMG:Object Management Group), http://www.omg.org
27