Upraszczanie przemysłowych rozwiązań komunikacyjnych

1. Wstęp Przemysłowe rozwiązania komunikacyjnie różnią się znacznie od rozwiązań komunikacyjnych powszechnego użytku. Powinny one być deterministyczne, szybkie i bezpieczne w działaniu, co powinno zapewnić większą wydajność cyklów produkcji, łatwiejszą konserwację i regulację maszyn. Jednym z początkowych udoskonaleń w rozwiązaniach dla przemysłu jest sterowane środowisko umożliwiające projektowanie układów automatyki przed ich wdrożeniem. Na rynku w dalszym ciągu jest zapotrzebowanie na rozwiązania łączące fazy komunikacyjne układów wejścia-wyjścia działających w czasie rzeczywistym i z przesunięciem czasowym. Dotyczy to między innymi standardowego ruchu TCP/IP na potrzeby konfiguracji i zarządzania. W przypadku ruchu w czasie rzeczywistym do tej pory dostępne były szeregowe układy Fieldbus, na przykład systemy Profibus [1] pracujące w konfiguracji master-slave o przepustowości do 12 megabitów na sekundę. Technologia Profibus posiada wysokie wymagania dla systemów działających w czasie rzeczywistym dotyczące wysyłania ramki odpowiedzi po 960 ns (11 bitach) po odebraniu pakietu. Wymaga to przetwarzania w czasie rzeczywistym na poziomie pakietów, które są zwykle obsługiwane w nieprogramowalnych układach. Industrial Ethernet wymusza przetwarzanie pakietów przychodzących z szybkością 100 Mb/s, co stawia systemom jeszcze większe wymagania. Z tego względu można znaleźć coraz więcej układów ASIC i FPGA dla różnych standardów. W konfiguracji typu master-slave wymagane jest minimalizowanie czasu przetwarzania pakietów w urządzeniach slave. Umożliwia to aktualizowanie wszystkich urządzeń typu slave w krótkim cyklu komunikacyjnym. W przypadku układów w standardzie Industrial Ethernet dostępne są dwa porty fizyczne, które przetwarzają pakiety przychodzące w trybie ciągłym lub „cut-through”. Przykładem rozwiązania działającego w standardzie Industrial Ethernet w trybie ciągłym jest EtherCAT [2]. Wszystkie pakiety odbierane przez pierwszy port wychodzą przez drugi port z modyfikacjami wejścia-wyjścia wprowadzonymi w czasie przebywania pakietu w kontrolerze typu slave. Opóźnienie w kontrolerze typu slave jest uzależnione od czasu przetwarzania pakietu. 16-bitowe przetwarzanie pakietów w standardzie Ethernet 100 Mb/s powoduje opóźnienie 160 ns. Inne opóźnienia wprowadzane przez infrastrukturę fizyczną sieci Ethernet oraz synchronizację różnych domen czasowych między układami wynoszą od 600 do 700 ns. Switche typu „cut-through”, takie jak Profinet IRT [3], podejmują decyzję na podstawie nagłówka pakietu. Kontroler slave musi w tym przypadku czekać na informacje o nagłówku i odfiltrować dane przed ich przekierowaniem do drugiego portu. Opóźnienie między elementami układu wynosi w tym przypadku od 1 do 3 us. Wymagania dla rozwiązań Industrial Ethernet w zakresie czasu oczekiwania i fluktuacji powodują, że stosowanie procesorów z przetwarzaniem potokowym do realizacji wieloprotokołowych kontrolerów slave, nie daje satysfakcjonujących rezultatów. Moduł czasu rzeczywistego PRU [4] jako programowalny co-procesor obsługujący wieloprotokołową komunikację przemysłową spełnia wymagania co do czasów oczekiwania i fluktuacji dla standardu Ethernet do 100 Mbit/s. 2. Programowalny moduł czasu rzeczywistego 32-bitowy procesor RISC jest przystosowany do przetwarzania pakietów danych w czasie rzeczywistym. Podsystem modułu PRU jest wyposażony w dwa procesory o częstotliwości taktowania 200 MHz. Architektura tego układu opiera się na 40 prostych instrukcjach do obsługi operacji logicznych, arytmetycznych i sterowania przepływem danych. Każda instrukcja na rejestrach układu wykonywana jest w ciągu jednego cyklu. Dane mogą być odczytywane i zapisywane za pomocą poleceń odczytu i zapisu w pamięci systemowej. Transfery danych mogą odbywać się w trybie burst, a czas ich wykonania zależy od czasu dostępu do pamięci. 2.1 Rdzeń jednostki czasu rzeczywistego Na rysunku 1 przedstawiono schemat jednego z rdzeni modułu PRU. Architektura ta nie działa w trybie potokowym, co oznacza, że pobieranie, dekodowanie i wykonywanie instrukcji odbywa się w pojedynczym takcie zegara układu PRU. Dzięki temu dane w rejestrach przetwarzane są w czasie rzeczywistym. Rejestry układu mają długość 32-bitów i pozwalają na adresowanie pojedynczych bitów lub słów 8, 16- i 32-bitowych. Rejestr 30 jest zmapowany do portów I/O i może być używany jako port wyjściowy ogólnego przeznaczenia. Rejestr R31 jest także zmapowany do portów I/O i reprezentuje stan wejść ogólnego przeznaczenia. Programowanie GPIO w module PRU generuje jitter rzędu 5 ns lub jednego cyklu zegarowego układu. Dwa końcowe bity rejestru R31 zmapowane są do kontrolera przerwań. PRU sprawdza bity 30 i 31 rejestru R31 dla generacji przerwań. Moduł PRU może także generować przerwania, zapisując dane w pierwszych pięciu bitach rejestru 31. Kontroler przerwań obsługuje maksymalnie 64 zdarzenia, które można zgrupować w 10 kanałach. Rysunek 1: Programowalny moduł czasu rzeczywistego Typowa instrukcja modułu PRU działa z 3 argumentami. Na przykład instrukcja ADD R3,R2,R1 zapisuje sumę rejestrów R1 i R2 w rejestrze R3. Ponieważ nie określono pola rejestru, operacja przyjmuje argumenty 32-bitowe. W instrukcji „ADD R3.b3, R2.b0, R1.b0” zastosowano wartości 8-bitowe, a wynik zostaje zapisany w najstarszym bajcie rejestru R3. Operacje bitowe są oznaczane jako Rx.ty. Instrukcja CLR R0.t17 powoduje skasowanie bitu 17 w rejestrze 0. Instrukcja QBBS label,R0.t17 powoduje skok do etykiety "label" w przypadku ustawienia bitu 17 w rejestrze R0. Czas wykonania operacji QBBS (szybki skok warunkowy po sprawdzeniu bitu) wynosi jeden cykl i jest niezależny od wyniku. Deterministyczne instrukcje jednocyklowe zawierające skoki warunkowe i warunkowe testowanie bitów sprawiają, że programowanie modułu PRU przypomina bardziej projektowanie opóźnień czasowych interfejsów, niż programowanie w języku wysokopoziomowym. Pobieranie i wysyłanie danych do pliku rejestru korzysta z trybu pakietowego ze szczegółowością na poziomie bajtów. Na przykład instrukcja SBCO R15.b3, C31, 4, 17 zapisuje w pamięci systemowej 17 bajtów pod adresem określonym w rejestrze C31 z offsetem 4 bajtów, zaczynając od najbardziej znaczącego bajtu rejestru R15. Analogicznie instrukcja LBBO R1, R0, 0, 16 powoduje załadowanie 16 bajtów z pamięci systemowej do rejestrów od R1 do R4. W tym przykładzie adres systemowy znajduje się w rejestrze R0 bez dodatkowego offsetu. 2.2 Programowanie modułu PRU Instrukcje modułu PRU operujące na rejestrach utrudniają rozumienie kodu programu podczas tworzenia złożonych projektów. Asembler procesora PRU udostępnia narzędzia ułatwiające odczytywanie i porządkowanie kodu. Znane z języka C dyrektywy preprocesora, takie jak #define, #include i #ifdef można w podobny sposób używać podczas programowania modułu PRU. Polecenia asemblera z kropkami pomagają tworzyć struktury, makra i przypisania do pliku rejestru. Zamiast wskazywać zawartość pakietu za pośrednictwem rejestru i bajtów offsetu użytkownik może zmapować strukturę do pliku rejestru i odwoływać się przez PktBuf.length. Oprogramowanie modułu PRU można debugować dwiema metodami. Pierwszą metodą jest uruchomienie serwera debuggera na głównym procesorze, używającego portu Ethernet do komunikacji z IDE w komputerze PC. Taki serwer debuggera dostępny jest dla procesorów ARM działających pod kontrolą systemu Linux. Innym rozwiązaniem jest użycie interfejsu JTAG w środowisku Code Composer Studio do debugowania kilku rdzeni równocześnie. Ważne funkcje debugera to: pułapki, praca krokowa, podgląd pamięci i stanu rejestrów oraz licznik cykli zegarowych. Driver PRU uruchomiony na procesorze host służy do obsługi funkcji modułu PRU w aplikacji. Dotyczy to między innymi ładowania, uruchamiania i zatrzymywania oprogramowania PRU, a także obsługi przerwań. W przypadku synchronizacji czasowej w sieciach Industrial Ethernet różnica między zegarem referencyjnym a zegarem lokalnym jest okresowo mierzona i filtrowana. Prosty algorytm uśredniania zmniejsza fluktuacje cykli. Obliczenia filtru trwa 4 cykle przy założeniu, że dane znajdują się w rejestrach. 3. Standardowy procesor ARM ze zintegrowanym interfejsem Industrial Ethernet Standardy Industrial Ethernet różnią się w zależności od rodzaju implementacji sprzętowych. Dzięki modułowi PRU i dodatkowemu układowi sprzętowemu możliwe jest zastosowanie pojedynczego bloku funkcyjnego do implementowania różnych standardów, takich jak EtherCAT czy Profinet. Na rysunku 2 przedstawiono przemysłowy procesor komunikacyjny AM335x [5] ze zintegrowanym układem PRU. Szybkie, 32-bitowe połączenie pomiędzy procesorem ARM Cortex A8 i modułami PRU zapewnia aplikacji dostęp do sieci Industrial Ethernet w czasie rzeczywistym. 64 kB pamięci podręcznej trzeciego poziomu (L3) stanowi bufor komunikacyjny jak również bufor przełączający w przypadku sieci Profinet IRT. Procesor AM335x może działać w trybie MCU z blokadą kodu krytycznego w pamięci podręcznej drugiego poziomu (L2). W przypadku większych systemów istnieje możliwość zastosowania pamięci DDR. Dzięki szerokiej gamie modułów peryferyjnych rodzina procesorów AM335x jest z powodzeniem stosowania w układach sterowania, napędach i czujnikach wyposażonych w interfejs Industrial Ethernet. Pobór mocy w przypadku urządzeń EtherCAT typu slave nie przekracza 500 mW. Układy AM335x mogą pracować w szerokim zakresie temperatur, spełniając wymagania przemysłowe. Rysunek 2: Przemysłowy procesor komunikacyjny AM335x Odnośniki [1] IEC61158-3-3, „Industrial communication networks – Fieldbus specifications – Part 3-3: Data-link layer service definition – Type 3 elements”, January 2008 [2] EtherCAT Specification ETG.1000.3 S, V1.0.2, Date: January 2012 [3] „Application Layer protocol for decentralized periphery and distributed automation”, Technical Specification for PROFINET, Version 2.3 – Date: October 2010 [4] Strony wiki na temat modułów PRU: http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem [5] Przemysłowy procesor komunikacyjny AM335x: www.ti.com/am335x Autorem artykułu jest Thomas Leyrer z Texas Instruments, System Application Manager w jednostce Industrial Automation Lab zlokalizowanej we Freising. Na co dzień zajmuje się takimi zagadnieniami jak Fieldbus / Industrial Ethernet przy zastosowaniu procesorów do aplikacji wbudowanych TI. Thomas Leyrer ma 20 lat doświadczeń w pracy w TI. © TI