Wybór systemu czasu rzeczywistego do szybkiego sterowania

| Technika

Gwałtowny wzrost zainteresowania systemami embedded w ostatnich latach zaciera granice pomiędzy prawdziwymi systemami operacyjnymi czasu rzeczywistego (RTOS), a systemami operacyjnymi, które obsługują systemy wbudowane. Mówiąc ogólnie, systemy RTOS stały się częścią wbudowanych systemów operacyjnych. Wyzwania w opracowywaniu różnych aplikacji mogą znaleźć rozwiązanie dzięki wbudowanym systemom operacyjnym, jednak są i takie, do realizacji, których konieczne jest wykorzystanie deterministycznego systemu operacyjnego czasu rzeczywistego.

Wybór systemu czasu rzeczywistego do szybkiego sterowania

Rys. 1. Sterowanie w zamkniętej pętli

Jedną z najważniejszych aplikacji tej kategorii jest sterowanie z dużą szybkością. Aplikacje szybkiego sterowania znajdują się w szeregu urządzeń i systemów, począwszy od przyrządów medycznych, poprzez maszyny do pakowania, po systemy symulacji silników pojazdów.

Najbardziej rozpowszechnionym rodzajem sterowania, które wymaga działania w czasie rzeczywistym, jest system sterowania w zamkniętej pętli sprzężenia zwrotnego. Systemy sterowania w zamkniętej pętli obejmują na ogół trzy podstawowe działania (rysunek 1).
-zbieranie sygnałów sprzężenia zwrotnego ze sterowanego systemu,
-przetwarzanie sygnałów wejściowych w oparciu o zdefiniowany algorytm,
-generowanie sygnałów wyjściowych, które wpływają na proces.

Aby odróżnić systemy szybkiego sterowania od wszystkich innych aplikacji sterowania, należy zwrócić uwagę na to, że systemy szybkiego sterowania wymagają działania przy czasie pętli 1ms lub mniej – lub też deterministycznego wykonywania powyższych trzech działań z częstotliwością co najmniej 1kHz. Na dodatek systemy te muszą osiągać czas pętli sterowania, aby uniknąć krytycznego dla wykonywanego zadania błędu systemu.

Systemy szybkiego sterowania wymagają rozwiązania w postaci deterministycznego systemu czasu rzeczywistego. Podczas, gdy wymogiem absolutnie najważniejszym jest wydajność, istnieją też inne wymagania wobec systemów szybkiego sterowania. Aby dokonać wyboru systemu RTOS, odpowiedniego dla aplikacji użytkownika, należy wziąć również pod uwagę czynniki takie jak: wydajność, programistyczne narzędzia do tworzenia aplikacji, wykrywanie i usuwanie błędów programu, integracja algorytmu sterowania, wsparcie dla sprzętu i we/wy, wielkość kodu i możliwości komunikacji.

Wydajność

Rys. 2. Czas reakcji na przerwanie

Przy wyborze RTOS największe znaczenie ma niezawodność i wydajność. System operacyjny powinien spełniać podstawowe wymagania dotyczące mocy obliczeniowej, umożliwiającej działanie programu sterowania. Jednym z najważniejszych wymogów jest krótki czas obsługi przerwań. System musi reagować szybko i przewidywalnie wobec zdarzeń, m.in. pojawienia się nowego sygnału wejściowego. Kryteria oceny wydajności systemy to maksymalny czas reakcji procedury obsługującej przerwania (ISR) oraz maksymalny czas reakcji wątku obsługującego przerwania (IST). Aplikacje szybkiego sterowania, m.in. symulacje typu hardware-in-the-loop (symulowany obiekt dołączony jest do sterownika za pomocą sygnałów fizycznych) oraz systemy sterowania ruchem wymagają na ogół czasów ISR i IST poniżej 10µs.

Większość „prawdziwych” systemów RTOS, m.in. Wind River VxWorks, QNX Neutrino oraz Green Hills Software Integrity, spełnia powyższe wymagania. Na dodatek, istnieją różne połączenia Linuksa oraz programów szeregujących w czasie rzeczywistym m.in. RTLinux i RTAI, dzięki którym również możliwe jest rozwiązywanie wyzwań aplikacji sterowania w czasie rzeczywistym. Z drugiej strony, systemy operacyjne, których opracowanie nie uwzględniało zastosowań dla czasu rzeczywistego np. Windows XP Embedded oraz podstawowe dystrybucje Linuksa, nie spełniają wymagań dotyczących czasów reakcji na przerwania.

Środowisko projektowe

Rys. 3a. LabView Execution Trace Toolkit

Następny etap rozważań oznacza środowisko projektowe, niezbędne dla zaprogramowania konkretnego systemu RTOS. Podobnie, jak wydajność odnosi się do „koni mechanicznych” RTOS, tak środowisko projektowe działa podobnie do zawieszenia zapewniającego wygodę w użytkowaniu. Podczas, gdy RTOS może mieć wszystkie właściwe parametry, środowisko projektowe posiada ogromny wpływ zarówno na jakość oraz szybkość projektowania, jak i na całkowity sukces przedsięwzięcia. Dotyczy to zarówno możliwości tak prostych, jak np. podświetlenie składni albo realizacja funkcji oraz tak potężnych, jak kompatybilność narzędzi do generowania kodu czy też do kontroli dostępu do kodu. Narzędzia generowania kodu mogą zaoszczędzić programistom wiele czasu przeznaczonego na projektowanie, niezależnie od ich doświadczenia w programowaniu. Kolejnym czynnikiem, który należy wziąć pod uwagę, jest dostępność dodatkowych narzędzi do środowisk projektowych. Środowiska oparte na oprogramowaniu Eclipse, m.in. Wind River Workbench and QNX Momentics oferują szeroki zestaw niezależnych rozszerzeń.

Niezależne oceny dotyczące czasu reakcji systemów operacyjnych czasu rzeczywistego na zdarzenia zewnętrzne oraz poradnik dotyczący wyboru (RTOS Buyer’s Guide) można znaleźć na stronie internetowej firmy Dedicated Systems Experts www.dedicated-systems.com/experts.

Wyszukiwanie i poprawianie błędów

Rys. 3b. LabView Execution Trace Toolkit

Jeżeli system zdolny jest do szybkiego sterowania, to jeszcze nie znaczy, że tę zdolność potrafi też utrzymać. Możliwość wyszukiwania i poprawiania błędów przy użyciu wybranych narzędzi programowania w systemach czasu rzeczywistego, zapewnia tworzenie udanego systemu sterowania, a nie wplątanie się w spiralę nieustannych poszukiwań trudnych do uchwycenia błędów. Standardowe funkcje, jak wykonywanie krokowe, metody printf() i syslog() są niezbędne, ale trudno jest optymalizować aplikację czasu rzeczywistego bez zastosowania zaawansowanych narzędzi do wyszukiwania i poprawiania błędów. Dotyczy to narzędzi profilowania aplikacji, analizy pamięci oraz śledzenia wykonywania procedur. Programy profilujące aplikacje i pamięć oferują wgląd w wykorzystanie procesora oraz pamięci przez każde z zadań wykonywane przez system. Dzięki ustaleniu, które zadania wykorzystują w najwyższym stopniu zasoby jednostki centralnej CPU i pamięci, szybko można określić przestrzenie, które wymagają optymalizacji. Przy tym należy pamiętać, że poziom technicznego wsparcia, zapewniony przez producenta RTOS, może być krytyczny w fazach projektowania oraz wykrywania i poprawiania błędów.

Narzędzia śledzenia wykonania to wyższy poziom debugowania, umożliwiający uwidocznienie wykonywania wątku, zobrazowanie przerwań, wywłaszczania oraz innych zdarzeń. Dzięki tym narzędziom użytkownik, w odniesieniu do swojej aplikacji może określić, jakie trudności w szeregowaniu zadań oraz problemy w taktowaniu powodują brak stabilności sterowania (rysunek 3). Przykładami zaawansowanych narzędzi debugowania są m.in. Green Hills Software EventAnalyzer dla Integrity OS, LabView Execution Trace Toolkit firmy National Instruments, system profiler QNX Momentics dla Neutrino oraz Wind River ScopeTools dla VxWorks i Linuksa.

Integracja algorytmu

Określenie „duża szybkość” wskazuje nie tylko na proces szybkiego sterowania, ale oznacza też zaawansowane strategie sterowania. Sercem systemu sterowania jest algorytm albo wyrażenie logiczne, które przetwarza sygnały wejściowe w celu uzyskania odpowiednich wyników. W zależności od aplikacji, algorytm sterowania zawiera prostą, dyskretną logikę do kierowania zaworami i przekaźnikami, aż po złożone równania różniczkowe, określające profil ruchu.

W miarę wzrostu złożoności algorytmu, konieczny może się okazać dostęp do wysokopoziomowych, skomplikowanych funkcji matematycznych, jak algorytmy szybkich transformacji Fouriera, czy algorytmy PID. Ponieważ większość zintegrowanych środowisk projektowania RTOS nie zawiera takich bibliotek, użytkownik musi przebadać szereg możliwości. Może opracować własny algorytm, jakkolwiek zajmie mu to wiele czasu i wymaga trudno dostępnej wiedzy. Szukane algorytmy mogą być częścią biblioteki o otwartym dostępie do kodu źródłowego (Open Source), można je też zakupić od dostawców oprogramowania. W ostateczności, użytkownik może również rozważyć użycie wysokopoziomowych narzędzi projektowania takich, jak graficzne środowisko do projektowania LabView, które zawiera funkcje analizy i może być wykorzystane bezpośrednio do programowania sterowników wbudowanych.

Sprzęt wbudowany

Rozważania o szybkich systemach sterowania nie byłyby kompletne bez dyskusji na temat właściwych celów przetwarzania sprzętowego. Użycie dostępnych opcji oprogramowania jest często utrudnione przez z góry określoną platformę sprzętową, albo wybór sprzętu jest ograniczony przez wsparcie określonego zestawu narzędzi. Trzeba przyjrzeć się wydajności procesora, kosztom oraz specyfikacjom środowiskowym i to tylko kilka spośród ważnych elementów. Na przykład systemy symulacji typu hardware-in-the-loop wymagają wysokowydajnych procesorów i na ogół najlepiej obsługiwane są przez procesory wielordzeniowe. Nie wszystkie systemy RTOS-y mają jednakowe wsparcie dla procesorów wielordzeniowych, a zatem stopień wsparcia jest bardzo ważnym czynnikiem, który należy wziąć pod uwagę przy dokonywaniu wyboru.

Przemysłowe systemy sterowania dla maszyn czy też urządzenia-sterowniki w trudnych warunkach środowiskowych mogą wymagać procesorów, które potrafią pracować w ekstremalnym przedziale temperatur od -40 do 70 ◦C, a w niektórych przypadkach nawet większych. Oczywiste jest, że do urządzeń sterowania zasilanych z baterii nadają się procesory niskiej mocy. Największa wydajność procesorów, które muszą odpowiadać ograniczeniom ze strony surowych warunków zewnętrznych oraz poboru mocy, jest naturalnie niższa od wydajności procesorów ogólnego przeznaczenia. Oznacza to, że systemy RTOS-y dysponują mniejszą mocą, dlatego ważniejszymi parametrami w ich przypadku stają się wydajność i wielkość.

Połączenie systemu sterowania z symulowanym obiektem odbywa się za pośrednictwem kart we-wy, które przekazują fizyczne sygnały sterowanego systemu. Możliwości interfejsów obejmują w dowolnej kombinacji napięcia analogowe, prądy, sygnały cyfrowe, sygnały z modulowaną szerokością impulsu, sygnały w.cz. Dlatego użytkownik powinien poszukać systemu o szerokim wsparciu dla sprzętu obsługującego wymagane typy obwodów wejścia-wyjścia. Przy wyborze poszczególnych modułów interfejsów, na przykład przetworników A/C i C/A, czy też wielofunkcyjnych kart akwizycji danych PCI z dużą liczbą kanałów we-wy, należy zwrócić uwagę na możliwości programowania. Znacznie więcej kodu trzeba opracować dla tworzonych na zamówienie elementów, w przeciwieństwie do użycia gotowego sprzętu dla ze sterownikami na magistrale, m.in. PCI, PCI Express, CompactPCI, PXI, PXI Express, VME itd. Urządzenia dostępne na rynku wyposażone są na ogół w sterowniki wyższego poziomu, w zależności od dostawcy. Niektórzy dostawcy mają w swojej ofercie tylko pakiety wsparcia płyt głównych BSP, z instrukcjami Peek i Poke, podczas gdy inni oferują interfejsy programowania aplikacji API, które zawierają rozszerzone możliwości, np. transfer z bezpośrednim dostępem do pamięci DMA. Karty we-wy mogą się różnić pod względem spełniania wymagań krytycznych dla systemów sterowania, dotyczących m.in. dokładności, izolacji oraz połączenia z układami wzmacniaczy pomiarowych.

System sterowania łącząc się poprzez układy we-wy z symulowanym obiektem, jednocześnie koresponduje z operatorem przy użyciu protokołów komunikacyjnych oraz graficznych interfejsów użytkownika. Wszechobecność Ethernetu pozwala na komunikację TCP, jednym z najważniejszych protokołów. System RTOS wykorzystany do programów sterowania musi posiadać solidny stos TCP do porozumiewania się ze światem zewnętrznym. Istnieje wiele różnych wbudowanych interfejsów ogólnego zastosowania, m.in. USB, Bluetooth, I2C i SPI, które są przydatne dla systemów sterowania, a poza nimi interfejsy przemysłowe, których system sterowania może również potrzebować. Na przykład przemysł lotniczy używa do komunikacji protokołów ARINC 429 i AFDX, przemysł motoryzacyjny protokołów CAN, LIN oraz FlexRay, a automatyka przemysłowa protokołów DeviceNet, Profibus, a także Modbus. Tak więc podsumowując, należy zdawać sobie sprawę z dostępnych pakietów BSP oraz interfejsów API dla danych systemów RTOS, a także z rozmiaru potrzeb projektowania w celu integracji specyficznych protokołów do aplikacji użytkownika.

Nie odkrywajmy Ameryki!

Niniejszy artykuł pokazuje, jak można zaprojektować system sterowania poprzez dokonanie wyboru systemu operacyjnego czasu rzeczywistego i narzędzi projektowania w celu stworzenia od podstaw aplikacji do sterowania. Jest to prawidłowe podejście w przypadku wielu aplikacji, ale istnieje jeszcze inna, alternatywna droga. Inżynierowie zajmujący się automatyką przemysłową przez szereg lat realizowali systemy sterowania używając ogólnodostępnych programowalnych sterowników logicznych (PLC) oraz modułów we-wy. Stosowanie sterowników PLC, z założenia, było ograniczone do aplikacji sterowania o niższej wydajności oraz głównie dyskretnej logiki oraz prostych algorytmów sterowania.

W ostatnich latach nowa generacja systemów wbudowanych, nazwanych programowalnymi sterownikami automatyki (PAC), połączyła cechy wbudowanych obliczeń z wysoką niezawodnością sterowników PLC. Patrząc z perspektywy oprogramowania, sterowniki PAC umożliwiają wykorzystanie systemów czasu rzeczywistego za pomocą środowisk programowania wysokiego poziomu, np. LabView. Istnieje również możliwość wykorzystania narzędzi niskopoziomowych w przypadku bardziej zaawansowanych aplikacji. Koszty sprzętowe PAC, w przeliczeniu na jednostkę, są wyższe niż koszty sprzętu wbudowanego, ale za to koszty projektowania są na ogół o wiele niższe, a poza tym krótszy jest też czas ich wdrożenia do produkcji. Przy dużych ilościach najlepszą decyzją jest realizacja systemów wbudowanych wg potrzeb klienta. Dokonując implementacji niewielu wdrożeń, należy się zastanowić, czy możliwy do wdrożenia PAC nie byłby lepszym rozwiązaniem.

Podsumowując powyższe rozważania, przy wyborze RTOS dla aplikacji szybkiego sterowania należy przeanalizować szereg czynników. Przed podjęciem decyzji sprawdzić trzeba wydajność, wsparcie sprzętowe oraz integrację we-wy. W jakim stopniu będzie brany pod uwagę każdy z czynników, zależy od potrzeb aplikacji, jakkolwiek należy rozpatrzyć je wszystkie w celu zapewnienia końcowego sukcesu stworzonego systemu sterowania.

Gerardo Garcia, National Instruments