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.