‚Model Based Design’ (MBD) w projektowaniu systemów kontroli dla wind osobowych

Poniższy artykuł został napisany w oparciu o doświadczenia pracowników firmy Sterdźwig związane z opracowaniem i wdrożeniem do produkcji nowego systemu sterowania dla wind osobowych. Prace nad nowym rozwiązaniem zaczęliśmy w 2014 roku. Pierwsze dźwigi wyposażone w nowe sterowniki zostały uruchomione pod koniec 2017 roku.

Współczesne systemy sterowania windami są zazwyczaj systemami rozproszonymi tzn. elementy kontrolne, pomiarowe i wykonawcze są rozproszone w całym szybie dźwigowym. Wiele z tych elementów zawiera w sobie układ mikroprocesorowy z oprogramowaniem, a komunikacja między poszczególnymi urządzeniami odbywa się zazwyczaj z użyciem jakiegoś standardu transmisji szeregowej np. CAN (Controller Area Network), RS485, RS422 itp.

W firmie Sterdźwig opracowaliśmy własny standard komunikacji (SterDzwigCAN) który jest protokołem dedykowanym dla urządzeń dźwigowych i opiera się na standardzie magistrali CAN. Ten system transmisji jest przez nas używany już od ponad 10 lat i znalazł zastosowanie w blisko 2000 wind w całym kraju

Sercem systemu sterowania jest tzw. ‚sterownik dźwigowy‚. Jest to rodzaj dedykowanego sterownika mikroprocesorowego, którego zadaniem jest nadzór nad wszystkimi pozostałymi urządzeniami. Jest to najbardziej obciążony obliczeniowo element systemu, pełniący także funkcję głównego interfejsu dla ekip montażowych i konserwacyjnych. Drugim najważniejszym urządzeniem w całym systemie sterowania jest tzw. ‚kontroler grupy’: czyli urządzenie odpowiadające za przydział wezwań i sterowanie ruchem w grupie wind. Istnieje na rynku wiele rozwiązań, które całą funkcjonalność kontrolera grupy zawierają w samym sterowniku windy, ale takie rozwiązanie ma istotne ograniczenia i nie było przez nas brane pod uwagę.

Sterownik windy / kontroler Grupy

Architektura urządzeń

Zarówno sterownik windy jak i kontroler grupy zostały opracowane w tej samej architekturze więc poniższy opis odnosi się do obu tych urządzeń. W architekturze oprogramowania można wyróżnić 3 zasadnicze warstwy:

• system operacyjny czasu rzeczywistego (tzw. RTOS)
• warstwa implementująca tzw. architekturę SOA (Service Oriented Architecture)
• serwisy odpowiadające za poszczególne funkcjonalności urządzenia

Użycie systemów operacyjnych w tzw. ‚urządzeniach wbudowanych’ jest dzisiaj dość rozpowszechnione. W przypadku urządzeń, które w swoim działaniu muszą respektować sztywne ograniczenia czasowe używa się specjalnych wersji systemów operacyjnych – tzw. systemów ‚czasu rzeczywistego’. Dają one programiście pełną kontrolę nad czasem wykonania poszczególnych zadań/wątków przez procesor. W przypadku sterowania windą takie ograniczenia są oczywiste – np. po najechaniu przez rozpędzony dźwig na zabezpieczający aparat końcowy szybu, należy natychmiast rozpocząć hamowanie.

Druga warstwa jest już znacznie ciekawsza i wymaga szerszego omówienia. Około 2007 roku pierwszy raz zetknęliśmy się ze środowiskiem Microsoft Robotics Studio – rozwijanym przez Microsoft oprogramowaniem narzędziowym przeznaczonym dla robotyki. Krótko potem firma Willow Garage zaczęła posługiwać się w swoich rozwiązaniach narzędziem nazwanym ROS (Robotics Operating System). Oba te narzędzia miały wiele cech wspólnych. Przede wszystkim zakładały, że finalne oprogramowanie robota będzie się składać z zestawu tzw. serwisów (architektura SOA) – czyli pewnych komponentów programowych bardzo luźno ze sobą powiązanych (loose coupling).

Od początku, ta architektura wydawała nam się doskonała do zastosowania w przemyśle dźwigowym więc przez kilka lat (dzięki kontaktom z zespołem robotyki w Microsoft) poznawaliśmy rozmaite jej aspekty i uczyliśmy się pisać oprogramowanie. Ostatecznie projekt Microsoft-u został zlikwidowany (wraz z zespołem), ROS bardzo się rozpowszechnił, a Sterdźwig został z bagażem ciekawych ale niewykorzystanych doświadczeń. Wtedy pojawił się pomysł, żeby samodzielnie zaimplementować niezbędne elementy architektury SOA, ale korzystając z usług systemu operacyjnego czasu rzeczywistego. W ten sposób udało się przenieść czasowy determinizm zadań (teraz już serwisów) do warstwy aplikacji i równocześnie mieć narzędzie do pracy z bardzo małymi mikrokontrolerami – oba te elementy są zazwyczaj przeszkodą w użyciu SOA w systemach wbudowanych typu ‚hard-real-time’.

Obydwie omówione warstwy są wspólne zarówno dla sterownika windy jak i dla kontrolera grupy. Różnice pojawiają się w ostatniej warstwie. Każde z urządzeń ma własny zestaw serwisów, odpowiedzialny za jego funkcje. Dla przykładu, serwisy sterownika obsługują: dotykowy panel LCD (interfejs użytkownika), magistralę CAN, kartę pamięci, modem GSM, diagnostykę itp. z kolei kontroler grupy nie posiada interfejsu użytkownika, ale ma za to aż pięć niezależnych serwisów do obsługi magistrali CAN, ponieważ musi pracować jednocześnie w (maksymalnie) 5 niezależnych sieciach dźwigowych (jeden kontroler może koordynować pracę do 5 wind w grupie).

Każde z urządzeń posiada jeden specjalny serwis, w którym zawarta jest główna logika aplikacji. Dla sterownika jest to tzw. ‚program dźwigowy’, a dla kontrolera grupy ‚scheduler’ (czyli ‚planista’). Ponieważ każdy z nich korzysta z usług większości wcześniej opisanych serwisów – w momencie startu subskrybują się do strumieni wiadomości (messages) udostępnianych przez te serwisy.

Zainteresowanych szczegółami odsyłamy do literatury i artykułów opisujących np. ROS (Robotics Operating System). ‚Program dźwigowy’ i ‚scheduler’ są także serwisami, które w największym stopniu podlegają ciągłej modyfikacji. Każda kolejna aktualizacja oprogramowania jest związana głównie ze zmianami w ich kodzie. I to właśnie te serwisy były od początku rozwijane wg. metodyki MBD (Model Based Design) z wykorzystaniem narzędzi z rodziny Matlab/Simulink firmy Mathworks.

Model Based Design

Metodyka MBD zakłada pracę w oparciu o modele: od fazy projektu aż po końcowe testy HIL (Hardware-In-the-Loop). W przypadku sterownika dźwigowego, centralnym modelem jest model serwisu ‚programu dźwigowego’ zbudowany w Simulink-u. Ponieważ logikę działania windy można wygodnie opisywać w języku tzw. ‚maszyn skończenie stanowych’ (FSM), głównym wykorzystywanym narzędziem jest Stateflow.

W tej chwili narzędzia Mathworks umożliwiają dość swobodne mieszanie różnych technik modelowania więc nie ma problemu z łączeniem diagramów FSM z modelami układów dynamicznych w Simulink-u i dużymi blokami obliczeń numerycznych w Matlabie. Model sterownika jest następnie obudowywany modelami otoczenia: napędu głównego, drzwi, stacji piętrowych, ludzi nadających wezwania i dyspozycje itp. Oddzielną grupę stanowią modele symulujące różne awarie systemu – zarówno mechaniczne jak i elektryczne. Ten etap pracy (tzw. MIL: ‚Model-In-the-Loop’) pozwala na wykrycie i eliminację błędów w projekcie.

W przypadku kontrolera grupy, centralnym modelem jest model serwisu ‚scheduler’. Otoczeniem kontrolera grupy są kontrolowane przez niego dźwigi więc nie powinno być zaskakujące, że model ten jest obudowywany wyżej opisanymi modelami sterownika wraz z otoczeniem. W firmie Sterdźwig przeprowadzaliśmy testy MIL na modelach 2 i 3 dźwigów w grupie. Jest tu jednak jeszcze jeden, dodatkowy element, o którym warto wspomnieć. Wewnątrz kontrolera grupy działa kilka algorytmów optymalizacyjnych, których zadaniem jest ciągła optymalizacja zaplanowanych jazd wind.

Proces optymalizacji nie jest w tym wypadku tak oczywisty jak by się mogło wydawać ponieważ szybkość realizacji wezwań i dyspozycji nie jest jedynym czynnikiem, ze względu na który optymalizujemy. Musimy także brać pod uwagę różne aspekty psychologiczne związane z użytkowaniem wind przez ludzi – a to często stoi w sprzeczności z prostym celem minimalizacji czasu obsługi. Z tego względu potrzebne są także dodatkowe metody testowania i wizualizacji samych algorytmów optymalizacyjnych. Używamy do tego dodatkowych modeli które nie są powiązane ani z generacją kodu, ani z późniejszymi testami SIL, HIL itp.

Dopracowany model zostaje następnie przygotowany do procesu generacji kodu źródłowego serwisu. W naszym przypadku jest to język C. Sama generacja kodu jest w pełni automatyczna. Narzędzia Mathworks, włącznie z narzędziami do generacji kodu, mają certyfikaty na zgodność z wieloma normami bezpieczeństwa stosowanymi w przemyśle maszynowym, samochodowym czy lotniczym. Z punktu widzenia przemysłu dźwigowego interesująca jest certyfikacja ze względu na normę IEC 61508. Daje to możliwość późniejszej certyfikacji SIL (Safety Integrity Level) urządzeń.

Po integracji wygenerowanego kodu z resztą kodu źródłowego (RTOS, warstwa SOA, inne serwisy), finalne urządzenie jest testowane w trybie Hardware-In-the-Loop (tzw. testy HIL). W firmie posiadamy kilka stanowisk do przeprowadzania takich testów. Wszystkie bazują na oprogramowaniu ‚Simulink Real Time’ firmy Mathworks. Testy są wykonywane automatycznie przez specjalny komputer przemysłowy (symulator), który uruchamia działające w czasie rzeczywistym modele Simulinka.

W przypadku testów sterownika dźwigowego, symulator pełni rolę otoczenia sterownika: napędu głównego, drzwi kabinowych, systemu odwzorowania położenia w szybie itd. Symuluje również ludzi naciskających przyciski, wchodzących do kabiny, blokujących drzwi itp. W tych testach są wykorzystywane te same modele, z których korzystamy na etapie testów MIL. W efekcie, gotowy sterownik dźwigowy pracuje na stanowisku testowym w warunkach niemal identycznych jak w rzeczywistym budynku.

W przypadku prostych urządzeń, gdzie integracja wygenerowanego kodu polega np. na umieszczeniu jego wywołania w przerwaniu lub prostej pętli timer-a – można dyskutować o zasadności przeprowadzania zautomatyzowanych testów HIL. Jednak w przypadku obu opisywanych urządzeń, wygenerowany kod był tylko jednym z serwisów w finalnej warstwie oprogramowania. Testy HIL pozwoliły nam wykryć i usunąć błędy, które były niemożliwe do zaobserwowania na wcześniejszych etapach pracy. Były to np. błędy w implementacji warstwy SOA, albo błędy w sposobie komunikacji między serwisami. W omawianym projekcie wykorzystywaliśmy dwie różne konfiguracje symulatorów: jedna służyła do testowania sterownika dźwigowego, a druga do testowania kontrolera grupy.

Podsumowanie

Podsumowując nasze dotychczasowe doświadczenia związane najpierw z wdrażaniem, a potem już z używaniem ‚Model Based Design’ trzeba przyznać, że ta metodologia doskonale się sprawdza. Za potwierdzenie niech posłuży fakt, że po ukończeniu testów HIL, pierwszy sterownik dźwigowy został uruchomiony w windzie osobowej w październiku 2017 roku i pracuje tam do dziś. Do tej pory ponad 150 urządzeń zostało zainstalowanych w windach różnych typów w całym kraju. Pierwsze grupy wind wykorzystujące nowy kontroler grupy pracują od grudnia 2018.