reklama
reklama
reklama
reklama
reklama
reklama
reklama
reklama
© Milan Jukrovic / Dreamstime Komponenty | 25 czerwca 2012

Upraszczanie przemys艂owych rozwi膮za艅 komunikacyjnych

Nie ma jednego standardu komunikacji przemys艂owej i cz臋sto korzysta si臋 z nieprogramowalnych uk艂ad贸w ASIC lub FPGA. Generuje to dodatkowe koszty dla producent贸w system贸w automatyki przemys艂owej na etapach projektowania, produkcji i wsparcia.
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 鈥瀋ut-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 鈥瀋ut-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 鈥濧DD 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, 鈥濱ndustrial 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] 鈥濧pplication 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
reklama
reklama
Za艂aduj wi臋cej news贸w
February 20 2019 12:04 V12.2.3-1