Szybkie prototypowanie układów regulacji w systemach mechatronicznych
Tony Lennon, The MathWorks
Większość inŜynierów kręci głową z niedowierzaniem, gdy słyszy, Ŝe termin MECHATRONIKA ma
juŜ 40 lat. Pierwszy raz został uŜyty przez Tetsuro Mori w 1969 do opisania systemu złoŜonego z
części mechaniczno – elektrycznej, kontrolowanego przez aplikację wbudowaną (Rysunek 1).
Simulation – Symulacja
Modeling – modelowanie
Real-time testing – testowanie w
czasie rzeczywistym
Mechanical – mechaniczny
Mechanics – mechanika
Hydraulics – hydraulika
Thermal – cieplny
Electrical – elektryczny
Magnetics – magnetyka
Electronics – elektronika
Mechatronics – mechatronika
Microcontrollers – mikrokontrolery
Digital controls – cyfrowe systemy
sterowania
Embedded software – wbudowane
oprogramowanie
Rys. 1. Mechatronika stanowi synergiczne powiązanie zagadnień mechaniki i elektroniki kontrolowanych
przez system wbudowany
Systemy wbudowane (ang. Embedded Systems) są to dedykowane architektury komputerowe, które są
integralną częścią całego urządzenia. Rozwiązanie w oparciu o systemy wbudowane zwiększa
szybkość i niezawodność, zmniejsza zuŜycie energii i podnosi bezpieczeństwo pracy. Systemy
wbudowane są stosowane:
– w przemyśle samochodowym (ABS, ESP, komputer pokładowy),
– w przemyśle obronnym (sterowanie w samolotach, rakietach),
– w przemyśle maszynowym, np. PLC,
– jako sterowniki robotów mechanicznych,
– w sterownikach bankomatów, czy teŜ innych urządzeń codziennego uŜytku.
Systemy mechatroniczne wykorzystują zaawansowane mikroprocesory sterujące złoŜonymi
procesami, w których zaleŜności między sprzętem a oprogramowaniem są bardzo złoŜone. Dlatego
inŜynierowie stają przed duŜym wyzwaniem – muszą pogodzić wymagania aplikacji z ograniczeniami
sprzętowo-programowymi, na jakie mogą napotkać.
W tradycyjnym podejściu do projektowania systemu wbudowanego, na początku tworzy się
specyfikację i wymagania projektu, następnie określa strategię sterowania i fizyczny prototyp, później
zaś projekt jest implementowany w sprzęcie i na końcu testowany.
Rys. 2. Tradycyjny proces tworzenia projektu
Zbyt późno znalezione błędy w sprzęcie lub programie są zwykle bardzo kosztowne i trudne do
usunięcia, potrzeba bowiem duŜo czasu na ich wykrycie i poprawienie. Bardzo często pojawiają się
błędy związane ze złą, niekompletną lub nawet powodującą konflikty z innymi modułami
specyfikacją. Przez róŜne rodzaje błędów (Rys. 2) projekty nie kończą się w załoŜonym czasie,
natomiast wynikowa aplikacja zwykle nie jest zgodna z początkowymi załoŜeniami projektu.
Projektowanie aplikacji w oparciu o modele (ang. Model-Based Design)
Projektowanie z uŜyciem modeli ułatwia rozwijanie systemów mechatronicznych przez opracowanie i
wykorzystywanie jednego spójnego środowiska do projektowania i łączenia elementów
mechanicznych, elektronicznych, pneumatycznych, termicznych itp.
Rys. 3. Projektowanie z uŜyciem modeli
Podejście takie jest zdecydowanie bardziej programowe, dlatego teŜ inŜynierowie mogą łatwo
porównywać projekty róŜnych systemów jak równieŜ zarządzać nowymi koncepcjami bez kosztów
związanych z budowaniem stanowiska pomiarowego i budową fizycznych prototypów. InŜynierowie
są w stanie w czasie całego projektu, znacznie szybciej i efektywniej testować nowe pomysły,
konfrontować je z przyjętymi wymaganiami i wcześniej niŜ w przypadku budowy prototypów
fizycznych wykrywać błędy wynikające ze złego funkcjonowania aplikacji bądź źle przyjętych
załoŜeń/uproszczeń. PoniewaŜ dzieje się to w czasie symulacji, błędy te są łatwe do usunięcia i
kosztują mniej, co zmniejsza ogólne koszty projektu. Podejście MBD daje współcześnie moŜliwości
automatycznej generacji kodu dla aplikacji wbudowanej, co zmniejsza błędy wynikające z ręcznego
opracowania kodu źródłowego aplikacji sterujących zarówno dla otwartych układów sterowania jak i
zamkniętej pętli sprzęŜenia zwrotnego charakterystycznej dla układów regulacji automatycznej.
Continuous test and verification – ciągłe testy i weryfikacja
Models – modele
Design with simulation – projektowanie z uŜyciem symulacji
Executable specifications from models – wykonywalne specyfikacje
opracowane z uŜyciem modeli
Implementation with automatic code generation – implementacja z
uŜyciem mechanizmu automatycznego generowania kodu
Rys. 4. Model-Based Design (Projektowanie oparte o modele)
W podejściu określanym jako „Model-Based Design” przez model rozumie się wykonywalną
specyfikację, która w unikalny sposób określa rzeczywiste i kontrolowane zachowania obiektu przy
pomocy reprezentacji matematycznej (zwykle są to układy nieliniowych równań róŜniczkowych).
InŜynierowie mogą sprawdzić model w trakcie symulacji komputerowej, która pokaŜe jego
właściwości dynamiczne i wpływ na zachowanie całego procesu/systemu. Model określa
jednoznacznie relacje matematyczne oczekiwanego zachowania systemu (w tym przypadku złoŜonego
układu mechatronicznego).
Podejście systemowe, razem z wykonywalną specyfikacją, daje przewagę nad specyfikacją pisemną,
poniewaŜ umoŜliwia juŜ na początkowym etapie sprawdzenie poprawności załoŜeń, wymagań,
redundancji lub konfliktu z innymi wymaganiami.
Pisemne specyfikacje będą istniały zawsze i inŜynierowie mogą je dołączać do projektu opartego na
MBD. Pomagają one zachować zgodność ze standardami takimi jak ISO 9001 lub IEC 61508.
Dodatkowo śledzenie wymagań ze specyfikacji w czasie projektowania systemu pokazuje, jak
inŜynier interpretuje dane wymaganie. Specyfikację w wersji elektronicznej moŜemy takŜe
wykorzystać do testowania, łącząc kryteria testów ze scenariuszami testów uŜywanymi w czasie
trwania całego projektu.
Rozwijanie projektu opartego na modelu w podejściu Model-Based Design
Diagram blokowy jest naturalną reprezentacją projektu opartego na modelu (Rys. 5). Model posiada
wejścia, tj. sygnały dostarczane przez zewnętrzne wymuszenia i wyjścia, pokazujące reakcję modelu.
Wejścia i wyjścia reprezentowane są przez rzeczywiste wartości jak np. napięcie, temperatura, pH,
ciśnienie itp.
Rys. 5. Diagram blokowy pokazuje cały model w przystępny dla inŜyniera sposób
Wewnątrz modelu, bloki połączone są liniami, które odwzorowują matematyczne relacje pomiędzy
nimi (a ściślej przepływ informacji pomiędzy elementami modelu). Bloki te mogą być obiektem
regulowanym lub procesem, który reprezentuje rzeczywiste działanie systemu mechatronicznego, np.
model silnika prądu stałego. Matematyczny model silnika moŜe być całkiem prosty, np. zamiana
napięcia na moment obrotowy. ZłoŜoność modelu moŜemy zwiększyć dodając więcej wejść do
modelu, np. zakłócenia od napięcia albo dodając więcej parametrów, np. temperaturę czy wpływ
efektów nasycenia magnetycznego. Blok lub podsystem (zgrupowane bloki) moŜe być fragmentem
większego systemu i realizować np. filtrację, przetwarzanie sygnału na podstawie sygnału
wyjściowego lub zdarzeń występujących w modelu. MoŜe być równieŜ modułem kompensującym
albo sterowaniem w systemie. Podstawą podejścia MBD jest model oparty na parametrach
skupionych, który reprezentuje fizykę systemu. Równania róŜniczkowe zwyczajne (ODE) lub
róŜnicowe (DAE) określają kolejne stany systemu bazując na modelu i relacjach, wejścia do wyjścia,
np. dla silnika DC moŜe to być zaleŜność napięcia wejściowego do momentu obrotowego wału.
Równania róŜniczkowe są obliczeniowo bardziej wydajnym sposobem opisu dynamiki o parametrach
skupionych w porównaniu do równań róŜniczkowych cząstkowych PDE, na których opiera się metoda
elementów skończonych MES.
Dzięki uŜyciu ODE, jako mechanizmu obliczeniowego dla systemu mechatronicznego , moŜliwie jest
symulowanie systemów złoŜonych z elementów róŜnych domen projektowania, np. mechaniki,
elektroniki, pneumatyki itp.
Modelując zachowanie systemu w oparciu o równania matematyczne, osoba projektująca musi dobrze
znać zjawiska fizyczne zachodzące w systemie. Systemy mechatroniczne są przewaŜnie nieliniowe,
trzeba w nich uwzględniać takie cechy jak histereza, siła tarcia i efekty cieplne, na które taki system
jest naraŜony w warunkach rzeczywistych.
Poprawianie modelu
Kiedy opis matematyczny systemu staje się zbyt trudny lub czasochłonny do opracowania,
inŜynierowie mają do wyboru inne moŜliwości. Pierwsza z nich to podejście wykorzystujące dane
empiryczne z obiektu rzeczywistego (ang. Data-Driven Modeling, Rys. 6), w myśl którego mając dane
wejściowe i wyjściowe jesteśmy w stanie stworzyć przybliŜony model matematyczny systemu,
uŜywając metod identyfikacji lub wykorzystując zalety sztucznych sieci neuronowych. Podejście to
nie daje jednak wglądu w fizykę systemu, ale daje dokładną reprezentację rzeczywistego systemu w
określonym zakresie danych testowych.
Mając przybliŜone parametry zidentyfikowanego obiektu oraz dane rzeczywiste, moŜemy
doprecyzować model przy uŜyciu technik optymalizacji, a następnie dokonać walidacji przez zbadanie
odpowiedzi modelu na zestaw danych testowych.
Rys. 6. Porównanie podejść do projektowania
Podejście MBD pozwala inŜynierom budować model krok po kroku, zaczynając od bardzo
podstawowego i stopniowo dodając kolejne elementy systemu. Takie podejście pozwala na
wcześniejsze wykrycie błędów i umoŜliwia wybranie optymalnego rozwiązania. Dzięki takiemu
podejściu jesteśmy w stanie budować bardzo skomplikowane systemy stopniowo dodając nowe
elementy mechaniczne, elektryczne, hydrauliczne, cały czas sprawdzając czy nasz system pracuje
poprawnie i spełnia określone wymagania.
MoŜliwe jest takŜe łączenie oprogramowania CAD (SolidWorks, ProEngineer) z MBD przy
modelowaniu mechaniki. System mechaniczny jest importowany z projektu trójwymiarowego razem z
parametrami, takimi jak masa, inercja, połączenia i zastępowany matematyczną reprezentacją bloków,
które reprezentują bryły mechaniczne, łączniki z pliku CAD. Przyśpiesza to rozwijanie
zaawansowanych systemów mechanicznych, poniewaŜ importowany jest gotowy system
mechaniczny, zgodny z załoŜeniami.
Opracowanie systemu sterowania
Po zamodelowaniu zachowania systemu, następnym krokiem jest zaprojektowanie systemu
sterowania, który będzie zawierał wiele wariantów sterowania: nie tylko dla celów sterowania w
otwartej pętli ale równieŜ dla celów regulacji w pętli zamkniętej (Rys. 7).
Sterowanie w otwartej pętli realizuje regulator nadrzędny, który zapewnia poprawną pracę układu w
oparciu o róŜne tryby pracy systemu. Projektanci uŜywając rozbudowanych mikroprocesorów mogą
stworzyć bardziej rozbudowane interfejsy dające większa kontrolę na urządzeniem. Dzięki temu
moŜliwe jest zaimplementowanie automatycznie wykonywanych algorytmów samo-diagnozujących
działanie systemu, powrót do normalnej pracy, wykrywanie i obsługę błędów oraz bezpieczny start-
stop całego urządzenia. Badania symulacyjne pomagają testować projekt od samego początku,
zwiększając tym samym ergonomię urządzenia i pozwalają znaleźć rozwiązanie optymalne, które: po
pierwsze nie uszkodzi sprzętu, a po drugie nie stwarza potencjalnego niebezpieczeństwa wystąpienia
sytuacji groźnej/niebezpiecznej.
W systemach mechatronicznych moŜliwe jest uŜywanie wielu zamkniętych pętli sprzęŜenia zwrotnego
działających z róŜnymi parametrami. Algorytm sterujący, moŜe być zarówno regulatorem PID jak i
wielowymiarowym regulatorem liniowo-kwadratowym LQG.
Projektowanie z uŜyciem modeli wspiera projektowanie a następnie dostrajanie sterowników w
pętlach sterowania. Dostrajanie sterowania bezpośrednio w sprzęcie jest bardzo trudne i czasochłonne,
często teŜ powoduje rozstrojenie dla określonego punktu pracy układu. Projektowanie za pomocą
modeli umoŜliwia inŜynierowi na analizę odpowiedzi zamkniętych układów regulacji, pozwala
rozwijać sposoby odsprzęgania układu (w sytuacji gdy takie odprzęganie jest wymagane) i dostrajać
wzmocnienia kompensatorów róŜnymi metodami, bazującymi na technikach optymalizacji.
Controller – regulator
Plant – obiekt sterowania
Actuators
–
elementy
wykonawcze
System – system
Sensors – czujniki
U – wartość zadana
Y – wartość regulowana
Rys. 7. Układ regulacji zamkniętej z pętla regulacji automatycznej
Podejście oparte na modelach (MBD) pomaga inŜynierom zasymulować i sprawdzić działanie
systemu sterowania przed jego uruchomieniem w warunkach rzeczywistych. Model jest narzędziem,
które pozwala zdecydować kiedy uŜyć tańszego czujnika z większą tolerancją, zamiast drogiego i
czułego. InŜynierowie mogą dokładnie określić jaki komponent wybrać, tak aby system
mechatroniczny działał poprawnie i był w miarę tani.
Testowanie i weryfikacja systemu
Testowanie i weryfikacja podczas rozwoju aplikacji wymaga zdefiniowania i wykorzystania
standardowych testów w połączeniu z opracowaną metodyką projektowania układów sterowania.
Stosowanie standardowych testów lub testów wytrzymałościowych (ang. harness tests) daje
inŜynierowi pewność, Ŝe system rozwijany jest zgodnie z ogólnie przyjętymi normami. Kryteria
testowania, określające czy projektowany układ/system jest zgodny/nie zgodny (ang. pass/fail tests)
jak i przyjęte zakresy tolerancji są realizowane w połączeniu z elektronicznym opracowaniem
specyfikacji oraz wymaganej dokumentacji.
Na podstawie przeprowadzonych i odpowiednio udokumentowanych testów, inŜynierowie określają
czy model jest juŜ kompletny i skończony, czy teŜ wymaga wprowadzenia dalszych poprawek.
Weryfikacja testów pozwala zdecydować, czy moŜliwe i celowe przy danych załoŜeniach jest
przystąpienie do budowy fizycznego prototypu.
Podejście wykorzystujące modele (MBD) pomaga inŜynierom stworzyć kompletny zestaw testów ,
których muszą następnie uŜywać podczas wszystkich etapów rozwijania projektu i testowaniu
produktu.
Dostosowywanie przyjętego modelu do załoŜeń produkcji
Po opracowaniu działającego i przetestowanego algorytmu sterowania, inŜynierowie następnie muszą
zaimplementować model, który zostanie przekazany do działu wykonawstwa.
Implementacja wiąŜe się z przepisaniem algorytmu sterowania na kod C, HDL lub na język zgodny z
normą IEC 61131-3 (np. język tekstu strukturalnego ST), który będzie uruchamiany na systemie
docelowym czasu rzeczywistego. Na proces ten składa się m.in. konwersja algorytmu sterowania z
modelu ciągłego (analogowego) na dyskretny, często w formacie stało-przecinkowym. Podczas testów
inŜynierowie mogą porównać cyfrową wersję algorytmu sterowania do wersji analogowej z obiektem
sterowanym i stwierdzić, w jaki sposób konwersja cyfrowa wpływa na zachowanie całego systemu.
Opracowanie modelu pozwala inŜynierom zbadać takŜe inne aspekty digitalizacji. InŜynierowie mogą
dobrać odpowiednie przetworniki A/D i D/A tak, aby zapewnić poprawny sygnał i wyeliminować
nakładanie się sygnału (aliasing). Systemy mechatroniczne wykorzystują do działania procesory,
działające z róŜną szybkością i częstotliwością próbkowania.
Podejście Model-Based Design daje projektantom moŜliwość symulowania i testowania systemu w
róŜnych konfiguracjach tak, aby odpowiednio oszacować koszty implementacji systemu i wybrać
optymalny wariant. Projektanci stoją bowiem często przed dylematem, czy uŜyć re-programowalnych
stało-przecinkowych układów FPGA czy teŜ znacznie szybszych i wydajniejszych zmienno-
przecinkowych układów DSP.
Testowanie systemów mechatronicznych w czasie rzeczywistym
Testowanie w czasie rzeczywistym jest następnym krokiem cyklu projektu prowadzonego zgodnie z
podejściem Model-Based Design. Na tym etapie, generowany jest automatycznie kod C, HDL albo
PLC. InŜynierowie mogą wygenerować kod dla sterownika, obiektu sterowanego, lub na oba te
komponenty, w zaleŜności od tego, jaki sposób testowania chcą wybrać. Projektowanie z uŜyciem
modeli oraz funkcjonalnością automatycznego generowania kodu zapewnia funkcjonalność, dzięki
której inŜynierowie zwolnieni są ze Ŝmudnego działania pisania tworzenia kodu aplikacji ręcznie,
przyśpieszając tym samym etap prac wdroŜeniowych. Projektanci systemów nie muszą być ekspertami
od pisania kodu, a wygenerowany w ten sposób kod nie jest naraŜony na błędy ludzkie.
Testowanie aplikacji moŜe być realizowane na dwa sposoby:
– Rapid Prototyping, (RP) – szybkie prototypowanie;
– Hardware in the loop (HIL) simulation.
Podczas testowania inŜynierowie mogą pobierać dane w czasie rzeczywistym i zmieniać parametry w
kodzie podczas pracy.
Tabela 1 pokazuje moŜliwości, jakie daje testowanie w czasie rzeczywistym. InŜynierowie mogą
wybrać odpowiedni sposób pozwalający na wyłapanie czasochłonnych i krytycznych błędów, zanim
zostanie opracowana docelowa aplikacja.
Typ testowania
Algorytm sterujący
Obiekt sterowany
Rapid prototyping
Kod uruchamiany na systemie
czasu rzeczywistego
Rzeczywisty sprzęt
Hardware-in-the-loop
Kod
uruchamiany
na
docelowym procesorze
Kod uruchamiany na systemie
czasu rzeczywistego
Tabela 1. Scenariusze testowania aplikacji sterujących w czasie rzeczywistym, Rapid prototyping i hardware-
in-the loop simulation
U – wartość zadana
Y – wartość regulowana
Controller – regulator
Motor – silnik
Rys. 8. Testowanie Rapid Prototyping
Podczas szybkiego prototypowania (Rapid Prototyping), kod algorytmu sterującego generowany jest
na kontroler, który działa na systemie czasu rzeczywistego i jest podłączony do istniejącego sprzętu.
System sterowania w modelu zawiera wszystkie potrzebne wejścia/wyjścia, wygenerowany kod
zarządza wszystkimi tymi urządzeniami i inŜynier nie musi ich samodzielnie programować.
U – wartość zadana
Y – wartość regulowana
Controller – regulator
Plant – sterowany proces
Rys. 9. Testowanie Hardware in the loop
W podejściu „Hardware in the loop”, kod generowany jest zarówno z modelu obiektu sterowanego jak
i z algorytmu sterującego.
Kod z modelu obiektu sterowanego uruchamiany jest na systemie czasu rzeczywistego, a kod z
algorytmu sterującego uruchamiany jest na docelowej architekturze sprzętowej i podłączany jest do
systemu czasu rzeczywistego na którym uruchomiony jest obiekt sterowany. Testowanie HIL moŜe
być zapewnione takŜe poprzez symulowanie obiektu na komputerze lub stacji roboczej.
Jakość wygenerowanego kodu
Projektowanie za pomocą modelu pozwala inŜynierowi zaprojektować model, z którego generowany
jest później kod C, HDL, PLC lub na dedykowany procesor bądź system czasu rzeczywistego. Proces
generacji kodu moŜe być zoptymalizowany na wybrany procesor, przez uŜycie specjalistycznych
sterowników udostępnianych w postaci bloków przez producentów procesorów. Kod generowany z
modelu opartego o takie bloki róŜni się od kodu generowanego na system rzeczywisty, poniewaŜ są w
nim elementy, które wykorzystują bardziej moŜliwości obliczeniowe danego procesora, pamięć, typ
danych, przerwania itp. Optymalizacja kodu dostosowuje automatycznie styl pisania programów do
stylu producenta sprzętu przez co wydajniej wykorzystywane są zasoby sprzętowe oraz ułatwia się
pracę osobom wdraŜającym system w całe urządzenie.
Podsumowanie
Projektowanie za pomocą modeli jest wydajnym sposobem rozwijania systemów mechatronicznych.
InŜynierowie mogą rozwijać i testować zachowanie modelu obiektu lub procesu w czasie symulacji na
komputerze klasy PC. Do najwaŜniejszych zalet takiego podejścia naleŜy zaliczyć:
– MoŜliwość projektowania i testowania wielu róŜnych pomysłów na realizację układu sterowania
systemu mechatronicznego, bez ponoszenia kosztów i marnowania czasu na budowę prototypów.
– Jedno środowisko projektowe, w którym modeluje się wykonywalną specyfikację, tzw. MODEL,
do którego następnie dodaje się elementy elektroniczne, mechaniczne, pneumatyczne, termiczne
itd.
– Redukcję kosztów i czasu potrzebnego do znalezienia i wyeliminowania wszystkich błędów na
kaŜdym etapie projektowania mechatronicznego.
– MoŜliwość rozwijania złoŜonych systemów wbudowanych, które dają uŜytkownikom większą
kontrolę przy projektowaniu systemów mechatronicznych.
– MoŜliwość automatycznej generacji kodu pozwalającą na szybkie sprawdzenie urządzenia w
rzeczywistych warunkach.
Artykuł pod redakcją Pawła Bytnara, Oprogramowanie Naukowo-Techniczne z Krakowa
Zastosowanie
techniki
automatycznego
generowania
kodu
w sterowaniu
układami
mechatronicznymi
Krzysztof Pietrusewicz
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie
W skrócie:
– szybkie prototypowanie
– badania symulacyjne HIL
– implementacja w systemie sterowania
Szybkie prototypowanie
Polega na automatycznym generowaniu kodu programu sterowania do wybranej platformy docelowej
z poziomu Matlab/Simulink. Nawet bardzo złoŜone struktury regulatorów mogą w łatwy sposób
zostać zaimplementowane w ramach funkcji sterujących urządzenia czasu rzeczywistego. Wiele
potencjalnie dobrych koncepcji nie jest wprowadzanych w Ŝycie z uwagi na długi czas (i
niebezpieczeństwo niepowodzenia) implementacji w urządzeniu docelowym. Dzięki szybkiemu
prototypowaniu wszystkie koncepcje moŜna efektywnie i szybko przetestować w warunkach
rzeczywistych.
Symulacje Hardware-In-the-Loop
KaŜda modyfikacja regulatora (parametrów, struktury) niesie ze sobą niebezpieczeństwo uszkodzenia
urządzenia sterowanego podczas prac uruchomieniowych. Zagadnienie badań symulacyjnych HIL
polega na przesłaniu do docelowego systemu sterowania zarówno regulatora jak i modelu sterowanego
procesu (opracowanych w Matlab/Simulink). Odpowiednio przygotowana aplikacja PLC pełni rolę
systemu obliczeniowego symulowanego modelu sterowanego procesu. Dzięki temu moŜliwe jest (bez
niebezpieczeństwa uszkodzenia elementów rzeczywistego procesu) przetestowanie rozmaitych
koncepcji systemów sterowania (regulatorów). MoŜliwe jest równieŜ testowanie takiego rozwiązania,
w którym zarówno regulator jak i symulowany proces wgrywane są do jednego systemu docelowego.
AR4Matlab firmy Bernecker&Rainer
Jak juŜ wspomniano, szybkie prototypowanie oferuje wiele moŜliwości w zakresie prostej i
elastycznej implementacji najbardziej nawet wyszukanych struktur układów regulacji w systemach
B&R. Innowacyjne rozwiązania układów regulacji, które w przeszłości byłyby pewnie zarzucone z
powodu nakładu pracy, jaki trzeba byłoby ponieść na ich przetestowanie w warunkach eksperymentu
praktycznego, mogą być współcześnie badane i rozwijane z uŜyciem Matlaba i Simulinka, a następnie
wgrywane do sterowników B&R za pomocą AR4Matlab (B&R Automation Studio Target dla
Simulink).
Rys. 1. Schemat szybkiego prototypowania w układach B&R
Pracochłonna, ręczna implementacja kodu, niosąca często ryzyko popełnienia błędu, naleŜy juŜ do
przeszłości. Procedura jest całkiem prosta (patrz rysunek powyŜej): zadanie opracowane w formie
schematu blokowego modelu Matlab/Simulink w kilku krokach przenoszone jest do sterownika B&R
z uŜyciem funkcji B&R Automation Studio Target dla Simulink.
Aby uniknąć zniszczenia elementów (np. urządzeń wykonawczych) sterowanego procesu podczas
testów nowo opracowywanych algorytmów sterowania, dobrze jest najpierw zaimplementować
krytyczne dla działania elementy w środowisku emulacyjnym (symulującym rzeczywiste działanie).
W tym celu moŜna wykorzystać drugi sterownik B&R (patrz rysunek 2). Zadanie sterowania,
stanowiące emulację sterowanego systemu, symuluje zachowanie rzeczywistego procesu tak
dokładnie na ile jest to moŜliwe. Nowe koncepcje systemów sterowania testowane są dzięki temu w
ś
rodowisku symulacyjnym, bez ryzykowania zniszczenia komponentów sprzętowych sterowanego
procesu.
a)
b)
Rys. 2. Schemat badania Hardware-in-the-loop z uŜyciem jednego (a) lub dwóch (b) systemów
docelowych B&R
JeŜeli zastosowanie moŜe mieć sterownik o wystarczająco duŜej mocy obliczeniowej, wtedy obydwa
zadania – sterowania i emulacji procesu – mogą zostać uruchomione na jednym systemie docelowym.
Jest to moŜliwe dzięki strukturze zadań sterowania w projekcie Automation Studio. NaleŜy tutaj
zauwaŜyć, Ŝe wszędzie tam, gdzie podczas badań symulacyjnych hardware-in-the-loop potrzeba
uwzględniać specyfikę działania fizycznych wejść/wyjść, naleŜy stosować dwa systemy docelowe,
osobno dla układu regulacji, a osobno dla modelu sterowanego procesu.
Cechy charakterystyczne AR4Matlab
Największą zaletą AR4Matlab i jego funkcji automatycznego generowania kodu programu dla
sterownika PLC jest to, Ŝe uŜytkownicy, dla których środowisko Matlab/Simulink jest typowym
narzędziem symulacji oraz projektowania układów sterowania, w błyskawiczny sposób opanują
technikę programowania zadań sterowania w sprzęcie B&R. UŜytkownicy ci z pewnością docenią
moŜliwość przeniesienia swoich pomysłów wprost do programu, wykonywanego przez
deterministyczny wielozadaniowy system operacyjny czasu rzeczywistego, przez fizyczne urządzenie
sterujące.
Z drugiej strony, uŜytkownicy sterowników B&R wraz z AR4Matlab uzyskują nowe, wielofunkcyjne
narzędzie, mogące w efektywny sposób poprawić jakość projektowanych, złoŜonych systemów
sterowania dzięki moŜliwości ich weryfikacji w warunkach symulacji Hardware-in-the-loop
(algorytm wraz z modelem symulacyjnym sterowanego procesu wykonywane są w czasie
rzeczywistym, przez urządzenie sterujące).
Przykład zastosowania
Z uwagi na swoje właściwości, oprogramowanie AR4Matlab znajduje zastosowanie wszędzie tam,
gdzie konieczny jest duŜy nakład pracy, a wynik podejmowanych działań nie jest do końca pewny.
Takim właśnie przypadkiem z całą pewnością są projekty naukowo-badawcze. Oprogramowanie
AR4Matlab wykorzystywane jest podczas realizacji projektu OCEAN (projekt rozwojowy,
finansowany ze środków Ministerstwa Nauki i Szkolnictwa WyŜszego, zatytułowany „Opracowanie i
badania prototypu obrabiarkowego zespołu posuwowego z napędami liniowymi sterowanego w dwóch
osiach z układu CNC o otwartej architekturze”), prowadzonego przez interdyscyplinarny zespół
Wydziału Elektrycznego i Wydziału InŜynierii Mechanicznej i Mechatroniki Zachodniopomorskiego
Uniwersytetu Technologicznego w Szczecinie pod kierownictwem profesora Stefana Domka,
Dziekana Wydziału Elektrycznego ZUT. Aktualnie prowadzone są próby na obiekcie, jakim jest
obrabiarka z układem napędowym opartym o śruby toczne. Kolejne badania będą obejmować
rozwiązanie oparte o silniki liniowe.
Obiektem sterowania jest 3-osiowa obrabiarka (frezarka) sterowana numerycznie. Z punktu widzenia
systemu sterowania jest to „arystokrata” wśród obiektów. Z jednej strony łączy wszystkie aspekty
automatyzacji procesów przemysłowych (komunikacja w sieci, sterowanie cyfrowe, sterowanie
ruchem z uŜyciem serwonapędów, wizualizację sterowanego procesu), z drugiej zaś parametry
obróbki skrawaniem (w przypadku frezowania metali jest to dokładność na poziomie pojedynczych
mikrometrów) sprawiają, iŜ zagadnienie poprawy jakości sterowania tego typu układami stanowi
bardzo atrakcyjny temat i nie lada wyzwanie.
Rys. 3. Obiekt badawczy – korpus frezarki 3-osiowej
Upraszczając, realizacja podstawowych funkcji systemu sterowania CNC sprowadza się do kilku
czynności:
– włączenie zasilania,
– sprawdzenie komunikacji
– inicjalizacja systemu CNC,
– inicjalizacja poszczególnych osi ruchu,
– zasilenie regulatorów w osiach,
– oczekiwanie na ruch/rozpoczęcie wykonywania programu obróbki,
– rozpoczęcie realizacji funkcji zawartych w programie,
– zakończenie wykonywania programu obróbki.
To, co moŜna zrobić w otwartym systemie sterowania dodatkowo (w porównaniu do dostępnych na
rynku systemów CNC), poza realizacją funkcji zawartych w programie obróbki, stanowi o
indywidualnych cechach systemu. System otwarty, którego architekturę sprzętowo-programową
opracowano w ramach omawianego tutaj projektu, posiada aktualnie funkcjonalności, dzięki którym
moŜliwe będzie (po opracowaniu zaleceń co do postępowania i odpowiednich algorytmów
obliczeniowych) wprowadzenie korekt procesu obróbczego, które obejmować będą m.in.:
– bloki korekcyjne uwzględniające zagadnienia termiczne podczas obróbki,
– bloki korekt uwzględniających drgania układu,
– bloki korekt z uwagi na siłę skrawania,
– bloki korekt z uwagi na odkształcenia/niedokładności konstrukcji obrabiarki,
– bloki korekt z uwagi na zmienne w czasie obciąŜenie układu napędowego wskutek ubytkowego
charakteru obróbki,
– bloki korekt z uwagi na początkowe połoŜenie obrabiarki względem przedmiotu obrabianego,
– bloki korekt on-line, uwzględniających opracowany w ramach projektu model układu i jego
zmienność.
System w aktualnej wersji umoŜliwia podczas wykonywania procesu obróbki wprowadzanie (jako
korekty wartości zadanych w poszczególnych osiach ruchu) wprowadzanie dodatkowych sygnałów, co
400 mikrosekund. Alternatywnie, moŜliwe jest (co 2 milisekundy) dokonywanie zmian wartości
parametrów regulatorów serwonapędów w poszczególnych osiach ruchu.
Rys. 4. Schemat koncepcji układu sterowania
Funkcje sterujące (po opracowaniu modelu), zostaną rozbudowane (po przeprowadzeniu
odpowiednich badań symulacyjnych na przyjętych modelach) i zaimplementowane w ramach
kolejnych, planowanych w przyszłości projektach (na lata 2010 – 2013), w bibliotece oprogramowania
Matlab/Simulink, opracowanej podczas realizacji zadań badawczych projektu OCEAN.
Rys. 5. Biblioteka Matlab/Simulink z opracowywanymi blokami korekcyjnymi
Dzięki zastosowaniu narzędzi takich jak AR4Matlab, tak opracowane (nawet o duŜym stopniu
skomplikowania) bloki korekcyjne moŜna będzie szybko przetestować (dzięki funkcjonalności
automatycznego generowania kodu) w warunkach pracy na obiekcie rzeczywistym. Pierwsze próby
implementacji korekt, z uwagi na niedokładności i luzy w korpusie, zaplanowane są na czerwiec
bieŜącego roku.