Konstrukcja systemu telemetrycznego z zastosowaniem technologii internetowych

Transkrypt

1 Politechnika Poznańska Wydział Elektryczny Instytut Automatyki i Inżynierii Informatycznej Maciej Brencz Konstrukcja systemu telemetrycznego z zastosowaniem technologii internetowych Praca magisterska Promotor: dr inż. Jarosław Warczyński Recenzent: dr hab. inż. Karol Rumatowski, prof. PP Poznań 2008

2 Streszczenie Niniejsza praca dyplomowa ma na celu skonstruowanie systemu telemetrycznego wyposażonego w interfejs ethernetowy umożliwiający wykonywanie zdalnych pomiarów temperatury oraz akwizycję danych. Praca zawiera opis sieci Ethernet, protokołów TCP/IP, procesu implementacji komunikacji sieciowej w mikrokontrolerze AVR oraz konstruowania systemu. W ramach pracy zrealizowano algorytm gradientowego sterowania wielopunktowym rozkładem temperatury. Opisano podstawy teoretyczne zastosowanego algorytmu, proces jego implementacji w środowisku MATLAB oraz wyniki badań. Słowa kluczowe Ethernet, telemetria, sterowanie gradientem temperatury, regulacja PID

3 Abstract The main purpose of the thesis was to design telemetry system with Ethernet interface allowing remote temperature measurement. The thesis contains description of Ethernet protocols and shows the way they were implemented. The system software, electronics and its features are also described. Algorithm of gradient multipoint temperature distribution control was implemented using MATLAB. The thesis contains description and results of tests of the new temperature gradient control method. Keywords Ethernet, telemetry, gradient temperature control, PID control

4 Spis treści 1. Wstęp Wprowadzenie Cele pracy Charakterystyka źródeł Przegląd istniejących rozwiązań Wire-Chip Termokontrola iologik E Omron EJ Omron CJ Etherrape Zastosowane technologie Magistrale komunikacyjne SPI Wire Sieć Ethernet Rys historyczny Adres MAC Ramka ethernetowa

5 SPIS TREŚCI Model warstwowy Stos TCP/IP Wybrane protokoły komunikacyjne Konstrukcja systemu telemetrycznego Założenia Mikrokontroler Czujniki temperatury Zegar RTC Karta pamięci SD/MMC Blok zasilania Sterownik PWM Interfejs diagnostyczny RS Blok wyświetlacza LCD i klawiatury Sterownik Ethernetu Implementacja stosu TCP/IP Obsługa podstawowych protokółów TCP/IP Obsługa sesji TCP Interpretacja odbieranych ramek Serwer Wykorzystane technologie Implementacja serwera Firmware systemu Omówienie kodu źródłowego Wykonanie części elektronicznej systemu

6 SPIS TREŚCI 5 5. Konstrukcja systemu sterowania Sterowanie gradientem temperatury Opis algorytmu Interfejs Współpraca ze środowiskiem MATLAB Testowa płytka grzewcza Implementacja algorytmu w pakiecie MATLAB Układ otwarty Identyfikacja parametrów płytki grzewczej Układ otwarty z odprzężeniem Układ zamknięty Wyniki badań Uzyskane przebiegi Zestawienie wyników Wnioski Podsumowanie 96 A. Zawartość płyty CD 98 B. Schematy elektroniczne 99 Bibliografia 106

7 Spis rysunków 2.1. Moduł Wire-Chip Urządzenie z serii iologik E2000 z modułem LCD Modułowy sterowniki temperatury serii EJ1 firmy Omron Sterowniki PLC serii CJ1M firmy Omron Zmontowana płytka projektu Etherrape SPI: układ nadrzędny i trzy układy slave SPI: bufor cykliczny złożony z dwóch rejestrów przesuwnych Przebiegi sygnałów na magistrali 1-Wire Ramka sieci Ethernet IEEE Modele warstwowe i umiejscowienie w nich wybranych protokołów Podstawowy węzeł sieci implementujący stos TCP/IP Przykład zawierania się danych pakietu UDP w protokołach warstw niższych (transportowej, Internetu, dostępu do sieci) Proces nawiązywania i zakończenie sesji TCP Schemat blokowy systemu telemetrycznego Wyprowadzenia mikrokontrolera ATmega Schemat blokowy mikrokontrolera ATmega Czujnik temperatury DS18B Zegar czasu rzeczywistego DS Sposób podłączenia karty SD/MMC do magistrali SPI

8 SPIS RYSUNKÓW Sposób podłączenia układu MAX Sposób podłączenia wyświetlacza alfanumerycznego opartego o sterownik HD Schemat blokowy sterownika Ethernetu ENC28J Analizator pakietów Wireshark Interfejs WWW systemu telemetrycznego Ustawienia bitów konfiguracyjnych dla mikrokontrolera ATmega System telemetryczny zmontowany na płytkach stykowych Rozproszenie temperatury na powierzchni płyty grzewczej Sterowanie z odprzężeniem Sterowanie gradientem temperatury Interpretacja wartości średniej i gradientu Metoda identyfikacji G p Interfejs WWW systemu w przeglądarce Opera Aplikacja DAQ w środowisku MATLAB Testowa płytka grzewcza Model układu otwartego w pakiecie Simulink Przebieg temperatur w odpowiedzi na pobudzenie skokiem jednostkowym jednego z kanałów Przebiegi uzyskane w trakcie identyfikacji parametrów modelu systemu Model układu otwartego z odprzężeniem w pakiecie Simulink Przebieg temperatur w odpowiedzi na pobudzenie skokiem jednostkowym kanału temperatury średniej t ave Model układu zamkniętego w pakiecie Simulink Odpowiedź skokowa użyta do wyznaczenia nastaw regulatora PID metodą Zieglera-Nicholsa Odpowiedź skokowa: t ref ave = 40 o C, algorytm sterowania gradientem Odpowiedź skokowa: t ref ave = 40 o C, algorytm klasyczny

9 SPIS RYSUNKÓW Odpowiedź skokowa: t ref ave = 60 o C, algorytm sterowania gradientem Odpowiedź skokowa: t ref ave = 60 o C, algorytm klasyczny Odpowiedź skokowa: t ref ave = o C, algorytm sterowania gradientem Odpowiedź skokowa: t ref ave = o C, algorytm klasyczny Odpowiedź skokowa: t ref ave = 60 o C, t ref grad = [1, 1, 1, 1], algorytm sterowania gradientem Odpowiedź skokowa: t ref ave = 60 o C, t ref grad = [1, 1, 1, 1], algorytm klasyczny B.1. Mozaika płytki systemu B.2. Schemat montażowy płytki systemu B.3. Mozaika płytki grzewczej B.4. Schemat montażowy płytki grzewczej

10 Spis tablic 3.1. Zestawienie komend obsługujących numery seryjne urządzeń 1-Wire Krótka charakterystyka mikrokontrolera ATmega Porównanie wybranych czujników temperatury Zestawienie komend czujnika DS18B Bilans poboru mocy przez system Spis komend interfejsu RS Zestawienie kontrolerów Ethernetu 10Base-T Wartości nastaw regulatorów PID dla testowej płytki grzewczej (algorytm sterowania gradientem) Wartości nastaw regulatorów PID dla testowej płytki grzewczej (algorytm sterowania bez odprzężenia) Zestawienie wskaźników jakości regulacji dla algorytmu sterowania gradientem temperatury Zestawienie wskaźników jakości regulacji dla klasycznego algorytmu sterowania temperaturą

11 Rozdział 1 Wstęp 1.1. Wprowadzenie Obecnie obserwujemy dynamiczny rozwój systemów szeroko rozumianego monitoringu i automatyki. Za sprawą rozwoju elektroniki sterowniki zyskują nową funkcjonalność oraz implementują coraz bardziej zaawansowane algorytmy sterowania. Rozwój techniki mikroprocesorowej i układów peryferyjnych daje możliwość realizacji złożonych algorytmów w tanich ośmiobitowych mikrokontrolerach dysponujących już odpowiednią mocą obliczeniową. Wykorzystanie powszechnie dostępnego Ethernetu jako sieci transmisyjnej pozwala łatwo, szybko i stosunkowo niskim kosztem podłączyć sterowniki nie tylko do sieci lokalnej, ale także do Internetu, dając olbrzymie możliwości zdalnego monitoringu i sterowania procesami technologicznymi dosłownie z dowolnego miejsca na świecie bez ograniczania się do konkretnej platformy sprzętowej czy systemowej. Zagadnienie sterowania procesami termicznymi jest jednym z trudniejszych w teorii automatyki z uwagi na wysoką inercję obiektów cieplnych. Maszyny takie jak wtryskarki tworzyw sztucznych, piece rusztowe stosowane w spalarniach odpadów czy piece wielostrefowe w elektrowniach, a także technologie produkcji układów półprzewodnikowych stawiają wysokie wymagania przed sterownikami. Wymagają one bowiem zapewnienia określonych rozkładów temperatur w konkretnych punktach.

12 ROZDZIAŁ 1. WSTĘP Cele pracy Za cel pracy postawiono wykorzystanie mikrokontrolera do realizacji akwizycji danych oraz zaimplementowanie w nim serwera WWW i serwera bazy danych jako podstawy do zdalnego monitorowania obiektów. Zakres poszerzono o praktyczną implementację sterownika opartego o gradientowy algorytm regulacji temperatury. Przedmiot pracy podzielić można na cztery główne zagadnienia: ˆ Projekt systemu telemetrycznego implementującego transmisję ethernetową, wielopunktowy pomiar temperatury oraz akwizycję danych. ˆ Wykonanie interfejsu WWW sterownika umożliwiającego podgląd stanu systemu, obserwację wartości pomiarów i odczyt danych pomiarowych z pamięci systemu. ˆ Realizacja algorytmu sterowania gradientem temperatury opartego o regulatory PID. ˆ Konstrukcja stanowiska testowego i dydaktycznego. Rozdział pierwszy zawiera wprowadzenie do pracy. Rozdział drugi stanowi przegląd występujących na rynku podobnych systemów pomiarowych. Kolejny rozdział zawiera opis zastosowanych technologii. W rozdziale czwartym opisano proces projektowania systemu telemetrycznego, implementacji transmisji ethernetowej oraz tworzenia oprogramowania. Ostatni, piąty rozdział zawiera opis i sposób implementacji zastosowanego algorytmu regulacji oraz prezentuje konstrukcję i możliwości całego systemu telemetrycznego wraz z jego interfejsem WWW Charakterystyka źródeł W trakcie pisania pracy korzystano z wielu rodzajów źródeł. Podstawowym źródłem informacji były noty katalogowe i aplikacyjne użytych układów elektronicznych oraz dokumenty PDF dostępne w sieci (opisy protokołów sieciowych, zastosowanego algorytmu sterowania). W trakcie pisania pracy wykorzystano także literaturę związaną z teorią sterowania, podstawami automatyki, elektroniką, programowaniem oraz zagadnieniami sieciowymi.

13 ROZDZIAŁ 1. WSTĘP 12 Niezwykle pomocna była także analiza kodów źródłowych biblioteki AVRlib dostępnej na licencji GNU. Nieoceniony wkład w rozwiązywanie problemów z komunikacją sieciową wniósł analizator pakietów Wireshark.

14 Rozdział 2 Przegląd istniejących rozwiązań 2.1. Wire-Chip Cyfrowy serwer pomiaru temperatury Wire-Chip jest produktem polskiej firmy SolidChip. Rysunek 2.1 przedstawia jego pojedynczy moduł. Rysunek 2.1: Moduł Wire-Chip System działa w oparciu o magistralę 1wire firmy Maxim-Dallas. Wire-Chip może komunikować się ze sterownikiem PLC lub komputerem poprzez port szeregowy RS485. Wykorzystanie magistrali 1wire umożliwia tworzenie rozległej sieci sond.

15 ROZDZIAŁ 2. PRZEGLĄD ISTNIEJĄCYCH ROZWIĄZAŃ 14 System znajduje zastosowanie w: ˆ telemetrii ˆ inteligentnych budynkach ˆ klimatyzacji i wentylacji ˆ suszarniach i magazynach 2.2. Termokontrola Jest to system termostatowania i monitoringu temperatury. Dane z wielu czujników temperatury trafiają do komputera, który na podstawie zadanych nastaw, steruje wieloma wyjściami cyfrowymi. Termokontrola korzysta z modułów Wire-Chip, do których podłącza się czujniki temperatury DS18B20. Sterowanie wyjściami odbywa się poprzez moduły z rodziny ADAM-4000 firmy ADVANTECH. Oprogramowanie komputera PC realizuje następujące funkcje: ˆ rejestracja danych pomiarowych i stanów wyjść ˆ alarmowanie o stanach granicznych (o wartościach zadanych przez użytkownika) ˆ wizualizacja stanów pracy, danych pomiarowych i stanów wyjściowych ˆ dane gromadzone są w bazie danych 2.3. iologik E2260 Firma Moxa jest producentem serii iologik E2000 (rysunek 2.2) urządzeń pod wspólną nazwą Active Ethernet I/O pozwalających dokonywać pomiary i sterować wyjściami analogowymi/cyfrowymi poprzez sieć Ethernet. Model E2260 przeznaczony jest do integracji systemów korzystających z rezystancyjnych czujników temperatury (RTD) może współpracować z czujnikami typu

16 ROZDZIAŁ 2. PRZEGLĄD ISTNIEJĄCYCH ROZWIĄZAŃ 15 Rysunek 2.2: Urządzenie z serii iologik E2000 z modułem LCD PT, JPT i Ni. Warstwa sieciowa oparta o Ethernet 100Mb obsługuje szereg protokołów: Modbus/TCP, SNMP, HTTP, TCP i UDP. IoLogic E2260 oferuje rozdzielczość mierzonych temperatur o wartości 0, 1 o C oraz częstotliwość próbkowania wynoszącą 12 Hz Omron EJ1 Sterownik serii EJ1 firmy Omron jest modułowym urządzeniem umożliwiającym regulację temperatury w czterech punktach. Sterownik może współpracować z termoparą, czujnikami typu Pt-100 i termistorami. Posiada on w zależności od modelu wyjścia napięciowe lub prądowe. Istnieje możliwość wzajemnej współpracy 16 modułów. Rysunek 2.3: Modułowy sterowniki temperatury serii EJ1 firmy Omron Sterownik posiada także złącze RS485 umożliwiające komunikację ze sterownikiem PLC. Modele z serii EJ1 realizują sterowanie dwupołożeniowe oraz regulację PID z funkcją autostrojenia.

17 ROZDZIAŁ 2. PRZEGLĄD ISTNIEJĄCYCH ROZWIĄZAŃ Omron CJ1 Seria CJ1 to urządzenia modułowe o szerokim wachlarzu możliwości - od prostych jednostek sterujących po wysoko wydajne modele obsługujące do 2560 punktów We/Wy z czasem wykonania instrukcji wynoszącym 20 ns. Daje to możliwość elastycznej konfiguracji systemu sterowania - analogowe i cyfrowe moduły punktów We/Wy i sterujące można dowolnie ze sobą łączyć. Kopie zapasowe i dane mogą być rejestrowane na kartach typu CompactFlash. Dostępne są także interfejsy sieci ProfiBus-DP, DeviceNet, ControllerNet, Ethernet i CompoBus/S. Rysunek 2.4: Sterowniki PLC serii CJ1M firmy Omron W ofercie firmy Omron znajduje się także sterownik CJ1G-CPU45P-GTC, implementujący opracowany w ośrodku badawczym tej firmy algorytm sterowania gradientem temperatury [9], obsługujący do 1280 punktów We/Wy z dziesięciopunktowym sterowaniem gradientem temperatury Etherrape Etherrape jest otwartym projektem rozpoczętym w roku 2006 z myślą o stworzeniu platformy ethernetowej dla mikrokontrolerów. Obecnie system implementuje: ˆ komunikację ethernetową wraz ze stosem TCP/IP ˆ prosty serwer WWW ˆ komunikację po RS232

18 ROZDZIAŁ 2. PRZEGLĄD ISTNIEJĄCYCH ROZWIĄZAŃ 17 ˆ komunikację po RS485/422 ˆ obsługę urządzeń 1wire ˆ odbiór i nadawanie sygnałów w podczerwieni (system RC5) Rysunek 2.5: Zmontowana płytka projektu Etherrape Projekt oparty jest o mikrokontroler AVRmega644 firmy ATMEL oraz sprzętowy sterownik sieci Ethernet ENC28J60 firmy Microchip. Zdjęcie, dostępnej w sprzedaży, płytki Etherrape znajduje się na rysunku 2.5. Oprogramowanie modułu zostało napisane w języku C z wykorzystaniem darmowego mikrostosu TCP/IP - µip [35] stworzonego specjalnie dla 8 bitowych mikrokontrolerów.

19 Rozdział 3 Zastosowane technologie 3.1. Magistrale komunikacyjne System telemetryczny, będący przedmiotem niniejszej pracy dyplomowej, łączy w sobie wiele urządzeń peryferyjnych. Większość z nich dostępna jest w wersjach z różnymi interfejsami (SPI, 1-Wire, I 2 C, Microwire... ). Celem ograniczenia liczby koniecznych do implementacji protokołów wybrane zostały dwie popularne magistrale: SPI i 1wire SPI Serial Peripheral Interface Bus jest szeregową, synchroniczną magistralą działającą w trybie full duplex (jednoczesne nadawanie i odbieranie danych) opracowaną przez firmę Motorola i implementowaną sprzętowo w większości mikrokontrolerów (także w używanym w opisywanym systemie mikrokontrolerze ATmega32 [23]). Interfejs SPI znaleźć można w takich urządzeniach jak czujniki temperatury, przetworniki ADC, ekrany dotykowe, kodeki audio, pamięci EEPROM i FLASH, zegary RTC. Każda karta pamięci MMC i SD posiada także interfejs SPI. Magistrala wykorzystuje cztery linie cyfrowe: ˆ CLK - linia sygnału zegarowego generowanego przez układ nadrzędny ˆ MOSI - dane wysyłane przez układ nadrzędny do wybranego układu slave

20 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 19 Rysunek 3.1: SPI: układ nadrzędny i trzy układy slave ˆ MISO - dane odbierane przez układ nadrzędny od wybranego układu slave ˆ SS - linia wyboru układu slave (aktywna sygnałem niskim, niezależna dla każdego urządzenia slave) Większość urządzeń z interfejsem SPI posiada trójstanowe wyjścia wchodzące w stan wysokiej impedancji, jeśli nie zostały wybrane przez układ nadrzędny. Jest to warunek konieczny do podłączenia wielu urządzeń slave do wspólnego układu nadrzędnego (patrz rysunek 3.1). Układ nadrzędny odpowiada za generowanie sygnału zegarowego odpowiedniego dla wybranego urządzenia slave, a następnie dokonuje jego wyboru wymuszając stan niski na jego linii SS. W okresie każdego taktu zegara następuje dwukierunkowa transmisja: urządzenie nadrzędne wysyła po linii MOSI kolejne bity odczytywane przez urządzenie slave, zaś urządzenie slave wysyła po linii MISO kolejne bity odczytywane przez urządzenie nadrzędne. Taki sposób komunikacji często nazywa się buforem cyklicznym - patrz rysunek 3.2. Pozostałe, niewybrane urządzenia slave ignorują dane obecne na linii MOSI i nie wysterowują linii MISO. Pojedyncza transmisja SPI zwykle składa się z ośmiu bitów. W dowolnym momencie transmisji układ nadrzędny może ją przerwać poprzez zdjęcie stanu niskiego z odpowiedniej linii SS. Magistrala SPI posiada wiele zalet takich jak jednoczesna komunikacja dwukie-

21 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 20 Rysunek 3.2: SPI: bufor cykliczny złożony z dwóch rejestrów przesuwnych runkowa, większą szybkość (w porównaniu do magistrali I 2 C), możliwość przesyłu dowolnej liczby bitów w słowie i proste interfejsowanie (układy slave nie wymagają układów taktujących). Wśród wad SPI wymienia się brak sprzętowej kontroli przepływu, brak potwierdzenia odbioru danych przez układ slave oraz mały zasięg w porównaniu do sieci CAN czy RS Wire 1-Wire jest magistralą komunikacyjną opracowaną przez firmę Dallas. Magistrala ta wykorzystuje tylko jedną linię sygnałową oraz dwie linie zasilania i masy. Opcjonalnie (w trybie tzw. zasilania pasożytniczego) linia zasilania może zostać pominięta - urządzenie jest wówczas zasilane z linii sygnałowej przy wykorzystaniu zawartego w odbiorniku kondensatora. 1-Wire jest siecią typu multi-slave. Do jednego urządzenia nadrzędnego (master), sterującego transmisją, podłączyć można wiele różnego rodzaju urządzeń slave [22]. Komunikacja odbywa się w trybie asynchronicznym (bez linii z taktującym sygnałem zegarowym), half-duplex (brak możliwości jednoczesnej komunikacji w obie strony). Magistrala ta, z uwagi na swoją niską prędkość transmisji (wynoszącą 16 kb/s), używana jest głównie do podłączania cyfrowych termometrów, pamięci EEPROM, sterowników ładowania akumulatorów, zamków elektronicznych ibutton, przetworników DAC, zegarów RTC. Korzystną cechą tej magistrali jest możliwość przesyłania, przy poprawnej konfiguracji, sygnałów na odległościach ponad 100 metrów. Od strony sprzętowej obsługa magistrali 1-Wire wymaga jednego wyjścia trójstanowego mikrokontrolera oraz dołączonego zewnętrznego rezystora podciągającego do poziomu napięcia zasilania. Dostępne są także specjalizowane sterowniki łączące urządzenia 1-Wire z magistralami typu USB i I 2 C.

22 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 21 Protokół komunikacyjny Protokół komunikacyjny magistrali 1-Wire [25] stawia przed oprogramowaniem urządzenia nadrzędnego wysokie rygory czasowe. Komunikacja odbywa się w specjalnych szczelinach czasowych (slotach) trwających 60 µs. W tym czasie magistrala transmituje pojedynczy bit. Wyróżnia się cztery rodzaje sygnałów (rysunek 3.3): ˆ Reset/Presence Komunikację zawsze rozpoczyna układ nadrzędny. W tym celu przez okres 8 szczelin czasowych (480 µs) wymusza on na linii sygnałowej stan niski. Jeśli do magistrali podpięte są urządzenia slave, powinny one po 60 µs od zwolnienia linii sygnałowej przez układ nadrzędny, wymusić na niej przez kolejne 60 µs stan niski. Brak takiego stanu pozwala układowi nadrzędnemu wykryć sytuację, w której do magistrali nie jest podpięte żadne urządzenie slave. Rysunek 3.3: Przebiegi sygnałów na magistrali 1-Wire [22] [25] ˆ Write 1 Wysłanie wartości 1 przez układ nadrzędny następuje poprzez wymuszenie

23 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 22 stanu niskiego na linii sygnałowej przez od 1 do 15 µs. Układ nadrzędny zwalnia następnie linię sygnałową do końca trwania szczeliny czasowej. ˆ Write 0 Wysłanie wartości 0 przez układ nadrzędny następuje poprzez wymuszenie stanu niskiego na linii sygnałowej przez cały okres trwania szczeliny czasowej (tzn. 60 µs). ˆ Read Odczytanie wartości wysłanej przez urządzenia slave rozpoczyna się od wymuszenia przez okres od 1 do 15 µs stanu niskiego na linii sygnałowej przez układ nadrzędny. Następnie układ slave powinien potrzymać linię sygnałową w tym stanie, jeśli chce wysłać wartość 0 lub zwolnić linię, jeśli chce wysłać wartość 1. Jak łatwo zauważyć sygnały Write 1 i Read są identyczne. Ich interpretacja zależy od wewnętrznego stanu urządzenia slave, a nie przebiegu czasowego sygnału. Identyfikacja urządzeń slave Identyfikacja urządzeń slave odbywa się poprzez unikalny, 64 bitowy numer seryjny (ROM code) zapisany w pamięci ROM każdego z urządzeń slave. Składa się on z trzech części: 8 bitów kodu rodziny określającego model podłączonego układu, 48 bitów kodu seryjnego oraz 8 bitowego kodu kontrolnego CRC. Protokół pozwala wybrać te z urządzeń slave, z którymi chcemy się komunikować. Twórcy standardu 1-Wire wyszczególnili cztery funkcje określone wspólnym mianem ROM functions (ich zestawienie zawiera tablica 3.1): Tablica 3.1: Zestawienie komend obsługujących numery seryjne urządzeń 1-Wire Komenda Kod Opis Read ROM 0x33 Identyfikacja pojedynczego urządzenia slave na magistrali Skip ROM 0xCC Ignoruj adresowanie (wysyłaj do wszystkich urządzeń slave) Match ROM 0x55 Zaadresuj określone urządzenie Search ROM 0xF0 Identyfikacja wszystkich urządzeń slave na magistrali

24 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 23 ˆ Read ROM W przypadku obecności tylko jednego urządzenia slave na magistrali, komenda ta umożliwia odczyt jego numeru seryjnego. ˆ Skip ROM Komenda ta pozwala zignorować adresowanie urządzeń slave i wysłać dane do wszystkich urządzeń slave podłączonych do magistrali. ˆ Match ROM Komenda pozwala wybrać określone urządzenie slave poprzez podanie jego numery seryjnego. ˆ Search ROM Komenda umożliwia stworzenie listy numerów seryjnych wszystkich urządzeń slave podpiętych do magistrali [26]. Po wysłaniu komendy Search ROM przez urządzenie nadrzędne, urządzenia slave wystawiają jednocześnie pierwsze bity swojego numeru seryjnego. Odczytana wartość będzie iloczynem logicznym pierwszych bitów numerów seryjnych wszystkich urządzeń slave. Następnie urządzenia slave wysyłą logiczną negację pierwszego bitu swoich numerów seryjnych. Ponownie odczytany zostanie ich iloczyn logiczny. Urządzenie nadrzędne odsyła teraz otrzymaną wartość iloczynu logicznego - nakazuje to urządzeniom slave dalej wysyłać kolejne pary odnoszące się do kolejnych bitów numerów seryjnych. Wykrycie kombinacji bitów wskazującej na obecność kilku urządzeń slave o tym samym ciągu dotychczas odczytanych bitów numeru seryjnego zmusza układ nadrzędny do podjęcia decyzji - układ nadrzędny może odesłać 0 lub 1 wyłączając określoną cześć układów slave, których numery seryjne nie zgadzają się ze wzorcem wysyłanym stopniowo przez układ nadrzędny. Po wykonaniu 64 cykli opisanego powyżej algorytmu, zidentyfikowany zostanie numer seryjny jednego z urządzeń slave. Układ nadrzędny powinien ponowić wysłanie komendy Search ROM, tym razem wybierając inne kombinacje, aby odczytać numery seryjne wszystkich układów slave.

25 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE Sieć Ethernet Zgodnie z założeniami system wyposażono w interfejs ethernetowy. W ramach pracy wykonano moduł sprzętowego kontrolera sieciowego oraz oprogramowanie realizujące komunikację sieciową Rys historyczny Określenie Ethernet odnosi się do standardów, z których korzysta się budując lokalne sieci komputerowe. W ich skład wchodzi specyfikacja kabli oraz sygnałów nimi przesyłanych, formaty ramek i protokoły niższych warstw. Wszystkie te wymogi zostały zebrane w standardzie IEEE [4]. Opracowany w roku 1976 przez Roberta Metcalfa w ośrodku badawczym Xeroxa Ethernet jest obecnie najpopularniejszym standardem sieci lokalnych. Pierwsza wersja (Xerox Ethernet) opracowana w roku 1978 umożliwiała komunikację na kablu koncentrycznym o maksymalnej długości 2500 m z prędkością 2,94 Mb/s. Dwa lata później powstał standard 10BASE5 korzystający z kabla koncentrycznego o impedancji falowej 50Ω pracujący z szybkością 10 Mb/s w segmentach sieci o długości do 500 m. W roku 1990 wprowadzono standard 10Base-T wykorzystujący jako okablowanie skrętkę (kabel składający się ze skręconych z sobą par przewodów miedzianych). W standardzie tym odstąpiono od podłączania wszystkich komputerów do wspólnego kabla koncentrycznego zakończonego specjalnymi terminatorami (rezystorami zapobiegającymi niepożądanym odbiciom sygnału) zapewniając większą niezawodność całej sieci. Do podłączenia więcej niż dwóch komputerów wymagany jest koncentrator przesyłający otrzymane dane na jednym porcie do wszystkich pozostałych. Protoplastą Ethernetu opartego na skrętce był StarLAN stworzony w połowie lat osiemdziesiątych przez AT&T, jednak 10Base-T był pierwszym tego typu standardem niezależnym od dostawców Adres MAC Każda maszyna (dokładniej karta siecowa) w sieci ethernetowej posiada przypisany, unikalny w danej sieci, adres MAC. Składa się on z 48 bitów i pozwala na adresowa-

26 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 25 nie ramek ethernetowych. Pierwsze 24 bity określają producenta danej karty sieciowej, kolejne 24 bity to wartość przypisana do danego egzemplarza karty na etapie produkcji (przykładowo karta o adresie MAC 00:1A:92:E1:22:69 wyprodukowana została przez firmę Realtek). Karty ethernetowe wyprodukowane w ostatnich latach pozwalają na zmianę przypisanego im numeru MAC. Definiuje się także tzw. adres rozgłoszeniowy (broadcast address). Dane wysłane na adres FF:FF:FF:FF:FF:FF odbierane są przez wszystkie karty sieciowe w danej sieci Ramka ethernetowa Dane przesyłane w sieciach ethernetowych organizowane są w tzw. ramki z danymi o długości do 1500 bajtów 1. Każda ramka posiada przypisany adres nadawcy i odbiorcy oraz numer typu. Rysunek 3.4: Ramka sieci Ethernet IEEE [4] Ramka ethernetowa opracowana została w roku 1978 przez firmy DEC, Intel i Xerox. Obecnie stosowana jest jej nieznacznie zmodyfikowana wersja (rysunek 3.4), opisana standardem IEEE [4], składająca się z: ˆ preambuły siedem bajtów złożonych z ciągu naprzemiennych zer i jedynek. Pozwala to na szybką synchronizację odbiorników ˆ SFD (start frame delimiter) znacznik początku ramki w postaci sekwencji 8 bitów: W sieciach akademickich i badawczych spotykane są także ramki z danymi o długości do 9000 bajtów, zwane Jumbo frames.

27 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 26 ˆ adresu MAC odbiorcy (6 bajtów) ˆ adresu MAC nadawcy (6 bajtów) ˆ typu (2 bajty) wartość mniejsza od 1500 oznacza długość ramki, większa - typ przenoszonego w ramce pakietu (np. 0x0800 dla pakietu IPv4, 0x0806 dla pakietu ARP) ˆ danych (od 46 do 1500 bajtów) porcja danych krótsza niż 46 bajtów uzupełniana jest zerami ˆ FCS czterobajtowa suma kontrolna CRC Model warstwowy Model TCP/IP Model TCP/IP (zwany także modelem DoD - akronim Department of Defense) jest specyfikacją dla protokołów sieciowych. Rozwój protokołów TCP/IP, które są obecnie niekwestionowanym standardem przesyłu danych w Internecie, rozpoczął się we wczesnych latach 70. Agencja Rozwiniętych Projektów Badawczych Obrony Departamentu Obrony Stanów Zjednoczonych DARPA po stworzeniu pierwszej rozległej sieci internetowej DARPANET rozpoczęła intensywne prace nad technologiami przesyłu danych. Wynikiem tych badań był model, którego założeniem jest podział zagadnienia komunikacji w sieci na wzajemnie ze sobą współpracujące warstwy. Programiści mogą niezależnie tworzyć implementacje protokołów poszczególnych warstw, jeśli określą oni sposób wymiany danych między poszczególnymi warstwami [18]. Sieć DARPANET przełączyła się całkowicie na standard TCP/IP w styczniu 1983 roku, w roku 1985 protokoły te wprowadzono do szerszego, komercyjnego użytku. Model TCP/IP jest standardem komunikacji otwartej dającym możliwość komunikacji między różnymi urządzeniami, bez względu na ich fizyczną funkcjonalność oraz platformę systemową.

28 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 27 Model ISO/OSI Prace nad modelem ISO/OSI (Open System Interconnection) rozpoczęto w roku 1977 w amerykańskim instytucie ANSI (w roboczej grupie ds. systemów rozproszonych DISY). Bazując na pracach instytutu ANSI Międzynarodowa Organizacja Normalizacyjna ISO rozpoczęła rozwój własnego modelu OSI. OSI posiadało dwa główne elementy: abstrakcyjny model sieci składający się z siedmiu warstw oraz zestaw konkretnych protokołów. Wpływ wprowadzonego w 1979 roku modelu OSI [5] nie wykroczył poza pewien model podejścia do zagadnień sieciowych. W praktyce protokoły sieciowe nie przestrzegają rygorystycznie podziału w modelu OSI. Strukturę protokołów bardziej odzwierciedla model TCP/IP. Rysunek 3.5: Modele warstwowe i umiejscowienie w nich wybranych protokołów Rysunek 3.5 zawiera porównanie dwóch opisanych powyżej modeli warstwowych oraz zestawienie wybranych protokołów w odpowiednich warstwach Stos TCP/IP Każdy interfejs sieciowy realizuje tylko część fizyczną komunikacji oraz niekiedy proste filtrowanie pakietów. Obsługą odbioru i wysyłania pakietów danych musi zająć się oprogramowanie (np. system operacyjny komputera). Każdy współczesny system operacyjny zawiera w swojej strukturze stos TCP/IP, czyli obsługę protokołów sieciowych TCP/IP [18]. Nazwa pochodzi od dwóch najważniejszych protokołów: TCP i IP. Określenie stos wynika zaś z warstwowej struktury protokołów, w których pakiet danych warstwy

29 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE aplikacje sieciowe... \ /.. \ / TCP UDP \ / IP * ARP \ ENET ---@ o Ethernet Rysunek 3.6: Podstawowy węzeł sieci implementujący stos TCP/IP [18] wyższej zawarty jest w ramce przenoszonej przez warstwę niższą (patrz rysunek 3.7). Każda z warstw modelu DoD realizuje inny element transmisji. Warstwa aplikacji zapewnia oprogramowaniu dostęp do komunikacji sieciowej. Warstwa transportowa zapewnia dostarczenie pakietu w ramach danego systemu do określonej aplikacji (protokół TCP zapewnia także potwierdzenie otrzymania pakietu i możliwość wymuszenia jego retransmisji w przypadku błędów). Pakiety z warstwy transportowej zawierają się jako dane w pakietach IP warstwy sieciowej (Internetu), która odpowiada za odnalezienie adresata danych w sieci. Warstwa dostępu do sieci zawiera protokoły obsługujące niskopoziomową kontrolę transmisji (takie jak ARP i RARP). Oprócz implementacji stosu TCP/IP będących standardem w systemach opera-

30 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 29 Rysunek 3.7: Przykład zawierania się danych pakietu UDP w protokołach warstw niższych (transportowej, Internetu, dostępu do sieci) cyjnych takich jak FreeBSD, Linux, Unix czy Windows, istnieją także implementacje dedykowane dla systemów wbudowanych, takie jak Lightweight TCP/IP [34] czy µip [35]. Adres IP Komputery w sieci Ethernet adresowane są numerami MAC interfejsów sieciowych. Protokoły TCP/IP korzystają jednak nie z adresów MAC, a z 32 bitowych adresów IP. Komunikacji w sieci Ethernet musi więc towarzyszyć konwersja adresów IP (używanych przez protokoły wyższych warstw) na adresy MAC potrzebne do adresowania ramek ethernetowych. Konwersja ta możliwa jest dzięki protokołowi ARP [18]. Z adresowaniem IP związane jest pojęcia maski sieciowej. Pomaga ona określić przynależność adresu IP do danej sieci. Często stosowaną maską w sieciach lokalnych jest W tym przypadku adresy IP w sieci mają zmienne wartości tylko w ostatnim członie (bajcie) adresu IP (np , , ) - odpowiadające wartościom w masce sieciowej równym zero. Maska sieciowa nabiera znaczenia, jeśli sieć lokalna posiada połączenie z Internetem (poprzez urządzenie zwane bramą). Brama dzięki znajomości swojego adresu IP i maski sieciowej pozwala stwierdzić czy dany pakiet IP adresowany jest do urządzenia znajdującego się w obrębie sieci lokalnej. Brama dokonuje prostego binarnego porównania swojego i docelowego adresu IP na bitach, dla których maska ma wartości 1. Jeśli wartości są zgodne, urządzenie docelowe znajduje się w sieci lokalnej

31 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 30 i pakiet TCP/IP nie musi jej opuszczać. W przeciwnym wypadku konieczne jest opuszczenie sieci lokalnej i wysłanie pakietu do najbliższego urządzenia w sieci Internet, który taki pakiet przekaże dalej. Adresy IP w ramach sieci lokalnej mogą być automatycznie przydzielane dzięki zastosowaniu takich protokołów jak DHCP i BOOTP. Urządzenia bezpośrednio podłączone do sieci Internet otrzymują adresy IP przypisane (dynamicznie na określony czas lub na stałe) przez usługodawcę [3]. Porty Protokoły UDP i TCP umożliwiają identyfikację konkretnych aplikacji i usług w docelowym systemie dzięki mechanizmowi portów. Numery portów zawierają się w przedziale od 0 do (16 bitów). Historycznie numery zarezerwowane są dla standardowych usług sieciowych[17]. Aplikacje użytkownika mogą korzystać z portów o numerach od 1024 wzwyż. Mechanizm portów pozwala jednoznacznie określić, która z aplikacji powinna obsłużyć przychodzący do systemu pakiet. Przykładowo pakiety TCP kierowane na port 21 przeznaczone są dla serwera FTP, a na port 80 - HTTP. Aplikacje obsługujące pakiety UDP posiadają niezależny od TCP zestaw portów Wybrane protokoły komunikacyjne Stos TCP/IP jest w istocie zbiorem obsługiwanych w danej jego implementacji protokołów internetowych. Poniżej opisano protokoły użyte w tworzeniu interfejsu sieciowego systemu telemetrycznego. Podczas ich implementacji korzystano z dokumentów RFC (Request For Comments), które nie mają mocy oficjalnej, jednak pewna ich część (głównie dotycząca właśnie protokołów sieciowych) została później przekształcona w oficjalne standardy. ARP Protokół ARP [16] (Address Resolution Protocol) jest metodą znajdowania adresów sprzętowych, jeśli znany jest tylko adres warstwy sieciowej. Używa się go przede wszystkim do translacji adresów IP na adresy MAC, jednak jego zastosowanie nie

32 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 31 ogranicza się tylko do sieci Ethernet. Protokół ARP pracuje w warstwie dostępu do sieci. Komunikacja korzystająca z adresów MAC możliwa jest tylko w obrębie danej sieci lokalnej. W przypadku konieczności przesłania danych poza daną sieć lokalną, protokół ARP zwraca adres MAC bramy sieciowej, która prześle dany pakiet poza sieć lokalną. Systemy operacyjne tworzą specjalne tablice ARP zawierające odpowiadające sobie pary adresów warstwy sieciowej (IP) z przypisanym do niego adresem fizycznym (MAC). Zapobiega to każdorazowemu wysyłaniu zapytania ARP. Gdy host A chce wysłać dane do komputera o adresie IP , to: 1. host A wysyła na adres rozgłoszeniowy sieci zapytanie ARP: kto ma adres IP ? 2. zapytanie ARP trafia do wszystkich komputerów w danej sieci lokalnej 3. host B, która posiada przypisany szukany adres IP, odpowiada: ja mam przypisany ten adres IP - mój adres MAC to 00:07:95:05:5A:9A 4. host A dodaje w tablicy ARP wpis, że wszystkie pakiety adresowane do powinny być wysłane przez warstwę dostępu do sieci na adres 00:07:95:05:5A:9A ICMP ICMP [14] (Internet Control Message Protocol) jest protokołem warstwy Internetu (warto dodać, że pakiety ICMP są przesyłane w pakietach protokołu IP należącego do tej samej warstwy). Wykorzystywany jest on głównie w diagnostyce sieci. Pakiety ICMP nie niosą w sobie żadnych danych, a jedynie informacje diagnostyczne o niemożności połączenia się z danym hostem czy niedostępności żądanej usługi. Wiele powszechnie stosowanych poleceń w konsolach systemów operacyjnych bazuje na protokole ICMP. Polecenie ping wysyła pakiety ICMP Echo request i Echo reply.

33 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 32 IP IP [13] jest protokołem warstwy Internetu służącym do przesyłania danych w grupach zwanych pakietami. Protokół IP nie gwarantuje, że pakiety dotrą do adresata, nie zostaną pofragmentowane czy zduplikowane. Pakiety IP mogą także dotrzeć do adresata w innej kolejności niż zostały do niego wysłane. Kontrolę poprawności dostarczenia danych zapewnia protokół wyższej warstwy TCP. Protokół IP umożliwia określenie priorytetu z jakim pakiet powinien być przesyłany w sieci. W pakiecie określa się do jakiego węzła sieci (określonego poprzez adres IP) ma on trafić. Opisane dalej protokoły UDP i TCP, korzystając z mechanizmu portów, określają dokładnie do jakiej aplikacji lub usługi systemowej danego węzła ma trafić pakiet danych. UDP Protokół UDP [12] (User Datagram Protocol) umożliwia przesyłanie krótkich wiadomości, zwanych datagramami. UDP jest protokołem bezpołączeniowy, bez narzutu na tworzenie i kontrolę połączenia, nieposiadającym kontroli przepływu i mechanizmów retransmisji pakietów. Korzyścią jest większa szybkość przesyłu danych, strumieni dźwięku i wideo, pakietów gier sieciowych. Przykładem protokołów warstw aplikacji korzystając z UDP są NFS, DHCP i VoIP. Protokół UDP implementuje także sumę kontrolną danych przesyłanych w pakiecie UDP. Pakiet IP również zawiera w sobie sumę kontrolną, jednak liczoną tylko z danych znajdujących się w nagłówku IP. Suma kontrolna UDP jest więc jedyną metodą weryfikacji integralności przesłanych danych. W celu dalszego przyspieszenia transmisji istnieje także możliwość zignorowania sumy kontrolnej (przez przypisanie do niej wartości zero). TCP TCP [15] (Transmission Control Protocol) jest protokołem połączeniowym implementującym kontrolę połączenia poprzez mechanizm sum kontrolnych i numerów sekwencyjnych. Umożliwia to wysłanie żądania retransmisji niedostarczonych pakietów.

34 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 33 Koszt utrzymania połączenia TCP jest zdecydowanie większy niż transmisja za pomocą datagramów UDP, jednak w protokołach FTP, SSH, HTTP, POP3, SMTP zalety TCP przeważają nad jego wadami. Choć specyfikacja protokołu zawiera definicję pakietu TCP, wywołaniu instrukcji wysłania danych nie musi towarzyszyć wysłanie jednego pakietu TCP. Dane z jednego wywołania instrukcji mogą zostać podzielone na kilka pakietów, a dane z kilku wywołań instrukcji wysłania połączone w jeden pakiet. Podobnie odbierane dane mogą pochodzić z kilku pakietów TCP łączonych przez stos TCP/IP. Sesja TCP TCP jest protokołem połączeniowym [19] - w odróżnieniu od UDP, pozwalającego natychmiastowo wysłać konkretne dane, TCP wymaga najpierw nawiązania połączenia. Połączenie TCP składa się z trzech faz: 1. nawiązanie połączenia 2. transfer danych 3. zakończenie połączenia Każdy pakiet TCP posiada numer sekwencyjny i numer potwierdzenia oraz zestaw flag. Dzięki numerowi sekwencyjnemu odbiorca może określić kolejność w jakiej dane z otrzymanych pakietów powinny zostać złożone. Numer potwierdzenia pozwala na poinformowanie nadawcy o pomyślnym odebraniu pakietu. Flagi to 6 bitowe pole w nagłówku pakietu TCP mogące zawierać: ˆ URG pozwala określić priorytet pakietu ˆ ACK zawartość pola numer sekwencyjny jest istotna (pakiet jest potwierdzeniem odbioru) ˆ PSH wymusza przesłanie pakietu ˆ RST reset połączenia ˆ SYN synchronizacja połączenia (używana w trakcie zestawiania sesji TCP)

35 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 34 Rysunek 3.8: Proces nawiązywania i zakończenie sesji TCP [19] ˆ FIN zakończenie połączenia Sesja TCP (rysunek 3.8) rozpoczyna się w momencie wysłania przez klienta pustego pakietu TCP z ustawioną flagą SYN z pewnym początkowym numerem sekwencyjnym n A. W odpowiedzi serwer wysyła pakiet z ustawionymi flagami SYN i ACK (funkcja net tcp synchronize() stosu TCP/IP). Jako numer potwierdzenia zostaje wpisany otrzymany od klienta numer sekwencyjny n A zwiększony o 1. W pole z numerem sekwencyjnym zostaje wpisana unikalna, wybrana przez serwer wartość n B. Jeśli serwer nie odpowie w odpowiednim czasie, klient wysyła po raz kolejny pakiet z flagą SYN lub po określonej liczbie takich prób rezygnuje z połączenia. Ostatni etap zestawienia sesji TCP to wysłanie przez klienta pakietu z flagą ACK w celu wymiany numerów sekwencyjnych i potwierdzenia (funkcja net tcp acknowledge() stosu TCP/IP).

36 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 35 Po tej fazie nawiązywania połączenia obie strony (klient i serwer) wymieniły się swoimi numerami sekwencyjnymi, jednocześnie mając pewność, że druga strona zna ich numer sekwencyjny. Pozwala to założyć z dużym prawdopodobieństwem (numer sekwencyjny jest wartością 32 bitową o możliwych wartościach), że odpowiedź faktycznie pochodzi od serwera, z którym ma nastąpić połączenie, a nie od użytkownika, który chce je przejąć. Na tym etapie wymiany pakietów sesja TCP jest już zestawiona. Obie strony mogą teraz wymieniać się pakietami TCP za każdym razem zwiększając numer sekwencyjny o 1. W celu zakończenia połączenia jedna ze stron może wysłać pakiet z flagą FIN i odpowiednim numerem sekwencyjnym. DHCP Protokół DHCP [3] (Dynamic Host Configuration Protocol) umożliwia komputerom podłączonych do sieci uzyskać dane konfiguracyjne takie jak swój adres IP, adres IP i MAC bramy sieciowej oraz maskę sieciową. Procedura uzyskania tych danych przedstawia się następująco: 1. Poszukiwanie serwera DHCP Na adres rozgłoszeniowy sieci zostaje wysłany pakiet DHCP DISCOVER. Pakiet może zawierać prośbę o przydzielenie ostatnio używanego adresu IP. 2. Oferta DHCP Serwer DHCP pracujący w danej sieci odpowiada pakietem DHCP OFFER zawierającym propozycję adresu IP oraz inne dane konfiguracyjne. 3. Żądanie DHCP Klient powinien teraz na adres rozgłoszeniowy odpowiedzieć pakietem DHCP REQUEST potwierdzającym otrzymanie propozycji adresu IP. 4. Potwierdzenie DHCP Po otrzymaniu pakietu DHCP REQUEST serwer wykonuje ostatni etap konfiguracji. Odpowiada pakietem DHCP ACK zawierającym czas dzierżawy przyznanego adresu IP i inne dane zażądane przez klienta. Klient powinien teraz odpowiednio skonfigurować swój interfejs sieciowy.

37 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 36 Pakiety DHCP przenoszone są w pakietach UDP. Ich interpretacja następuje w funkcjach z przedrostkiem net dhcp. NTP NTP [10] (Network Time Protocol) jest protokołem precyzyjnej synchronizacji czasu. Wzorcowy czas (strefa UTC) powinien pochodzić ze specjalnych cezowych zegarów atomowych, jednak dopuszczalne są obecnie inne źródła. NTP jest jednym z najstarszych protokołów internetowych nadal będących w użyciu - stworzony został w roku Obecnie używana wersja protokołu (NTP v4) pozwala uzyskać dokładność synchronizacji rzędu 10 ms przy synchronizacji z serwerem internetowym, a przy użyciu sieci lokalnej może zostać uzyskana dokładność na poziomie 200 µs. Implementacja protokołu NTP okresowo (zwykle co 64 sekundy) wysyła pakiety UDP na port 123 serwera NTP celem wyliczenia własnego opóźnienia względem referencyjnego źródła czasu. W celu synchronizacji płynnie przyspieszany lub zwalniany jest programowy zegar komputera - nie ma konieczności dokonywania skokowych zmian czasu. W przypadku większych różnic (większych niż 128 ms) między porównywanymi czasami, NTP stosuje skokową zmianę czasu. Protokół ten pozwala na szybką synchronizację czasu nawet dziesiątek tysięcy maszyn bez przeciążania łącz i procesorów komputerów. W Polsce działają dwa serwery NTP dostarczające urzędowy czas UTC: tempus1.gum.gov.pl ( ) i tempus2.gum.gov.pl ( ). Są to serwery oparte o atomowy zegar cezowy 5071A znajdujący się w Głównym Urzędzie Miar. Działa także ogólnoświatowy klaster serwerów NTP - ntp.org. HTTP HTTP [6] (Hypertext Transfer Protocol) to protokół transmisji informacji. Został on stworzony w celu przesyłania stron WWW w sieci Internet. Protokół ten działa na zasadzie żądania (request) i odpowiedzi (response). Żądanie zostaje wysłane przez klienta (najczęściej przeglądarkę internetową, stosowną bibliotekę w kodzie innego programu, narzędzie działające w linii poleceń systemu)

38 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 37 do serwera. Serwer, nasłuchujący najczęściej na porcie TCP o numerze 80, zwraca do klienta odpowiedź w postaci odpowiedniego pliku HTML, pliku CSS, skryptu JS lub obrazka. Przykładowa sesja HTTP wygląda następująco. Klient (w tym przypadku program curl) wysyła żądanie przesłania głównej strony serwisu (GET /) do serwera HTTP: GET / HTTP/1.1 User-Agent: curl/ (i486-pc-linux-gnu) libcurl/ OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5 Host: macbre.dyndns.info:8080 Accept: */* Klient w tym przypadku wysyła także informację o sobie (nagłówek User-Agent). Serwer odpowiada zwracając treść pliku HTML: HTTP/ OK Content-Type: text/html Cache-Control: private, must-revalidate Server: Telemetry (Apr :08:27) X-Powered-By: ATmega32&ENC28J60 <html><head> <title>telemetria</title> </head> <body> <h1>telemetria</h1> </body></html> Odpowiedź zawiera informację o pomyślnym przetworzeniu zapytania (HTTP/ OK), typie danych w niej zawartych (Content-Type: text/html), sposobie obsługi buforowania w pamięci podręcznej przeglądarki (Cache-Control) oraz nazwie

39 ROZDZIAŁ 3. ZASTOSOWANE TECHNOLOGIE 38 i wersji serwera (Server). Po linii odstępu znajduje się odpowiedź, która powinna zostać wyświetlona w oknie przeglądarki WWW lub zapisana do pliku.

40 Rozdział 4 Konstrukcja systemu telemetrycznego 4.1. Założenia Na wstępie procesu projektowania systemu telemetrycznego przygotowano listę założeń i wymagań, które powinien spełniać: ˆ mikrokontroler 8-bitowy jako układ nadzorujący pracę systemu ˆ autonomiczność systemu (możliwość samodzielnej pracy bez komputera) ˆ zestaw czujników do wielopunktowego pomiaru temperatury ˆ sterowanie gradientem temperatury ˆ możliwość akwizycji danych pomiarowych wewnątrz systemu ˆ dostęp do systemu poprzez interfejs ethernetowy ˆ wyświetlacz LCD używany do podglądu stanu systemu ˆ diagnostyczne złącze RS232 ˆ końcówki mocy umożliwiające sterowanie układami wykonawczymi (grzałki) ˆ możliwość współpracy systemu z pakietem MATLAB

41 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 40 Elementy grzewcze PWM Układ sterowania w systemie MATLAB Mikrokontroler RS232 SPI 1-Wire PC (terminal) Czujniki temperatury Karta SD/MMC, zegar RTC, pamięć EEPROM, Ethernet Rysunek 4.1: Schemat blokowy systemu telemetrycznego Na podstawie powyższych założeń przystąpiono do konstruowania systemu, którego schemat blokowy przedstawiono na rysunku 4.1. Niniejszy rozdział zawiera omówienie składowych elementów systemu. Bardziej szczegółowe informacje o zastosowanych układach elektronicznych (opis wyprowadzeń, dokładny opis protokołów, charakterystyki) znaleźć można w dołączonych do pracy na płycie CD notach katalogowych i aplikacyjnych. W rozdziale opisano także proces implementacji transmisji ethernetowej oraz tworzenia oprogramowania w języku C [2] Mikrokontroler Rynek oferuje obecnie szeroką gamę mikrokontrolerów produkowanych przez wszystkie znane firmy w branży. Przy wyborze mikrokontrolera kierowano się kilkoma czynnikami:

42 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 41 ˆ funkcjonalność ˆ dostępność ˆ stosunek funkcjonalności do ceny ˆ dostępność narzędzi programistycznych ˆ obudowa przeznaczona do montażu przewlekanego celem redukcji kosztów tworzenia płytki drukowanej Rysunek 4.2: Wyprowadzenia mikrokontrolera ATmega32 Warunki te spełnia mikrokontroler ATmega32 [21] z rodziny AVRmega produkcji firmy Atmel (jego krótką charakterystykę przedstawiono w tablicy 4.1). Mikrokontrolery tej rodziny są bardzo popularne w Polsce, powszechnie dostępne i tanie. Producent udostępnia bezpłatne środowisko programistyczne AVR Studio. Programowanie ATmegi odbywać się może w asemblerze i języku C (po doinstalowaniu darmowego pakietu WinAVR). Ważnym argumentem przemawiającym za wyborem tego mikrokontrolera jest bogactwo dostępnych dedykowanych bibliotek, not aplikacyjnych i przykładowych kodów źródłowych. Atmega32 posiada w swej strukturze (rysunek 4.3): ˆ dwa timery 8 bitowe

43 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 42 Tablica 4.1: Krótka charakterystyka mikrokontrolera ATmega32 Architektura 8 bitowa, RISC Szybkość taktowania Pamięć programu Pamięć EEPROM Pamięć SRAM Linie I/O 32 Interfejsy Napięcie zasilania do 16 MHz 32 kb (do 10 tysięcy cykli zapis/odczyt) 1 kb (do 100 tysięcy cykli zapis/odczyt) 2 kb USART, SPI, I 2 C 5V Pobór prądu 22 ma (16MHz, 5V) ˆ jeden timer 16 bitowy ˆ czterokanałowy układ PWM ˆ przetwornik ADC o rozdzielczości 10 bitów (8 kanałów) ˆ komparator analogowy ˆ układ Watchdoga ˆ detektor spadku napięcia resetujący układ (Brown Out) W ramach pracy powstało oprogramowanie systemu napisane w języku C realizujące następujące funkcje (szerszy opis każdego z elementów systemu i oprogramowania znaleźć można w dalszych punktach niniejszego rozdziału): ˆ akwizycja danych Płytka systemu została wyposażona w gniazdo kart SD/MMC, które służą jako pamięć do składowania danych uzyskanych z pomiarów. Dostęp do nich możliwy jest poprzez interfejs sieciowy zarówno poprzez przeglądarkę internetową jak i pakiet MATLAB. System wyposażono także w zegar czasu rzeczywistego, który jest automatycznie synchronizowany z internetowym serwerem czasu dzięki wykorzystaniu protokołu NTP. ˆ pomiar i sterowanie temperaturą Jednym z głównych zadań w pracy jest sterowanie rozkładem temperatury. Za

44 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 43 Rysunek 4.3: Schemat blokowy mikrokontrolera ATmega32 pomiar temperatury odpowiedzialne są cyfrowe czujniki DS18B20 firmy Microchip. Programowo zaimplementowano regulatory PID oraz algorytm sterowania gradientem temperatury. Zrealizowano także ośmiokanałowy sterownik PWM. Elementami wykonawczymi są rezystory drutowe o mocy kilku watów. ˆ serwer WWW Komunikację ethernetową zrealizowano w oparciu o dedykowany sterownik Ethernetu ENC28J60 firmy Microchip obsługujący transmisję z prędkością do 10Mb/s. Układ ten sprzętowo realizuje fizyczną część komunikacji oraz proste filtrowanie pakietów wg adresów MAC. Pozostała część komunikacji realizowana jest przez oprogramowanie systemu. System wyposażono także w pamięć

45 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 44 EEPROM przechowującą szablony i pliki używane przez serwer WWW Czujniki temperatury W trakcie prac konstrukcyjnych nad systemem telemetrycznym zdecydowano się skorzystać z cyfrowych czujników temperatury. W odróżnieniu od czujników analogowych, nie wymagają one skomplikowanej kalibracji, nie ma także potrzeby wykorzystywania przetworników ADC wnoszących dodatkowe błędy i niepewności pomiarowe. Cyfrowe czujniki temperatury charakteryzują się podobnymi parametrami co ich analogowe odpowiedniki, zarówno w odniesieniu do zakresów mierzonych temperatur, jak i dokładności samych pomiarów. Dodatkowo niektóre czujniki cyfrowe posiadają mechanizmy jednoznacznej weryfikacji odczytu zmierzonych wartości. W tablicy 4.2 zestawiono parametry kilku wybranych modeli czujników. Tablica 4.2: Porównanie wybranych czujników temperatury Nazwa Rodzaj Zakres Dokładność Uwagi DS18B20 Cyfrowy -55 do 125 o C ±0,5 o C interfejs 1-Wire LM95071 Cyfrowy -40 do 150 o C ±1 o C interfejs SPI TC72 Cyfrowy -55 do 125 o C ±2 o C interfejs SPI TCN75 Cyfrowy -55 do 125 o C ±0,5 o C interfejs I 2 C TC1046 Analogowy -40 do 125 o C ±0,5 o C liniowa zależność V/ o C KTY81 Analogowy -55 do 150 o C ±1,5 o C nieliniowa zależność R/ o C LM35 Analogowy -55 do 150 o C ±0,5 o C liniowa zależność V/ o C Z uwagi na wysoką cenę nie brano pod uwagę rezystancyjnych czujników temperatury opartych na platynie i niklu takich jak: Pt100, Pt500 czy Ni100. Dysponują one bardzo szerokim zakresem pomiarowym z uwagi na wysoką temperaturę topnienia materiałów, z których zostały wykonane. Dla celów porównawczych w tablicy 4.2 przedstawiony został tani czujnik rezystancyjny PTC (Positive Temperature Coefficient), w którym wzrost temperatury skutkuje wzrostem rezystancji, typu KTY81. Z dostępnej oferty czujników cyfrowych wybrany został czujnik DS18B20 produkcji firmy Maxim-Dallas posiadający interfejs 1-Wire. Z uwagi na konieczność podłączenia kilku czujników temperatury w celu wykonywania pomiarów wielopunktowych, nie zdecydowano się na czujniki z interfejsem

46 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 45 SPI. Konieczność prowadzenia osobnych linii SS dla każdego z czujników wymagałaby wykorzystania ośmiu wyjść mikrokontrolera (zamiast pojedynczego wyjścia w przypadku magistrali 1-Wire). Czujnik DS18B20 Rysunek 4.4 przedstawia wyprowadzenia czujnika DS18B20 (wersja w obudowie typu TO92) [28]. Wykorzystanie magistrali 1-Wire pozwala na łatwą obsługę systemów pomiarowych składających się z wielu czujników. Zestawienie używanych przez ten czujnik komend znajduje się w tablicy 4.3. Rysunek 4.4: Czujnik temperatury DS18B20 System w trakcie wykonywania procedury inicjalizacyjnej skanuje magistralę 1- Wire (instrukcja Search ROM) tworząc listę podłączonych czujników. Tablica 4.3: Zestawienie komend czujnika DS18B20 Komenda Kod Opis Convert T 0x44 Rozpocznij pomiar temperatury Read Scratchpad 0xBE Odczytaj zawartość pamięci scratchpad wraz z kodem CRC Write Scratchpad 0x4E Zapisz wartości progów alarmowych i bajtu konfiguracyjnego Komenda rozpoczęcia pomiaru temperatury Convert T wysyłana jest jednocześnie do wszystkich czujników (komenda Skip ROM), a następnie po zakończonym pomiarze z kolejnych czujników (komenda Match ROM) odczytywane są z pamięci scratchpad czujników zmierzone wartości temperatury. Natychmiast po odczytaniu wszystkich zmierzonych wartości do czujników wysyłana jest kolejna komenda Convert T.

47 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 46 Czujniki zastosowane w systemie zostały skonfigurowane do pracy z 12 bitową rozdzielczością, co odpowiada precyzji pomiarów ±0,0625 o C. Taka konfiguracja pozwala na mierzenie temperatury co jedną sekundę (czas dokonania pomiaru przez czujnik wynosi maksymalnie 750 ms) Zegar RTC System telemetryczny wyposażono w precyzyjny zegar czasu rzeczywistego (Real- Time Clock) DS1306 [27] firmy Maxim z interfejsem SPI/Microwire. Odmierza on sekundy, minuty, godziny, dni miesiąca, dni tygodnia, miesiące i lata (z uwzględnieniem lat przestępnych do roku 2100). Z uwagi na znikomy pobór mocy (rzędu setek na) istnieje możliwość jego zasilania z litowej baterii 3V lub kondensatora o pojemności rzędu 1F. Rysunek 4.5: Zegar czasu rzeczywistego DS1306 Dane zegara i kalendarza (jako wartości w kodzie BCD) dostępne są poprzez interfejs szeregowy (SPI lub jego starsza wersja Microwire) jako wartości rejestrów wewnętrznych DS1306. Dodatkowo dostępna jest 96 bajtowa przestrzeń nieulotnej pamięci RAM podtrzymywanej bateryjnie. Układ oferuje także wyjścia zegarowe 1Hz i 32kHz typu otwarty kolektor oraz dwa programowalne alarmy. Wyjście 1Hz zostało użyte w systemie jako sygnał synchronizujący jego pracę. Wskazania zegara RTC są okresowo synchronizowane z internetowym serwer czasu NTP oraz prezentowane na wyświetlaczu alfanumerycznym. Możliwa jest także zmiana nastaw zegara z poziomu interfejsu WWW.

48 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO Karta pamięci SD/MMC Opisywany system telemetryczny posiada funkcję akwizycji danych pomiarowych. Miejscem ich składowania jest karta pamięci SD/MMC [33] umieszczana w specjalnym złączu znajdującym się na płytce systemu. Rysunek 4.6: Sposób podłączenia karty SD/MMC do magistrali SPI Karty SecureDigital (SD) opracowano jako rozwinięcie standardu kart Multi- MediaCard (MMC), stąd wsteczna kompatybilność urządzeń obsługujących karty SD z kartami MMC. Istnieje jednak kilka różnic między obydwoma rodzajami kart. Karty Secure Digital posiadają dodatkowe piny 8 i 9 (niewykorzystywane jednak w opisywanym dalej trybie komunikacji SPI), mają możliwość mechanicznej blokady zapisu (wykrywanej przez odpowiednie styki znajdujące się w gnieździe), szybkiego zapisu strumieniowego (kolejnych sektorów) oraz ochrony praw autorskich poprzez kontrolę dostępu do danych na karcie. Karty MultiMediaCard (MMC) i SecureDigital (SD) posiadają, oprócz swoich własnych interfejsów, także intefejs SPI (rysunek 4.6) mogący pracować z częstotliwością do 20/25 MHz (MMC/SD). Zestaw instrukcji dla obu kart jest niemal identyczny - karty SD implementują bowiem dodatkowy zestaw instrukcji, co pozwala na ich odróżnienie do kart MMC. Zaimplementowane w systemie funkcje współpracują zarówno z kartami SD jak i MMC. System na starcie wykrywa rodzaj karty (SD/MMC), podaje jej rozmiar i nazwę przypisaną przez producenta. Karty pamięci SD/MMC nie posiadają możliwości zapisu pojedynczych bajtów, możliwe są tylko operacje na 512 bajtowych sektorach. Z uwagi na niewielki rozmiar pamięci RAM (2 kb) zastosowanego mikrokontrolera zdecydowano się na współ-

49 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 48 dzielenie pamięci przez bufor ramki ethernetowej i bufor obsługujący operacje odczytu/zapisu na karcie. Problem interfejsowania karty (pracującej z napięciem zasilania 3,3V) z mikrokontrolerem zasilanym napięciem 5V rozwiązano stosując dzielnik napięcia zrealizowany na parze rezystorów dla każdej z linii magistrali SPI. Zapis danych na karcie Z uwagi na ograniczone rozmiary pamięci Flash zastosowanego mikrokontrolera, system telemetryczny nie tworzy na karcie klasycznego systemu plików (takiego jak powszechnie stosowany w pamięciach tego typu system FAT). W oprogramowaniu zaimplementowano natomiast prosty system plików (plik fs.c). Dane z pomiarów ( pliki ), poprzedzone nagłówkiem (z informacją o m.in. nazwie i rozmiarze pliku), zapisywane są do kolejnych sektorów na karcie. System oferuje funkcje tworzenia, otwierania, zapisywania i odczytu z wybranego pliku. Każdy plik zajmuje pojedynczy sektor karty (512 bajtów). Pozwala to na zapis wartości ponad 200 próbek do pojedynczego pliku. Funkcje zapisu pomiarów i ich odczytu dostępne są z poziomu interfejsu WWW Blok zasilania System telemetryczny zasilany jest napięciem stałym o wartości 12V ze źródła stabilizowanego o wydajności prądowej 1A. Układy elektroniczne wymagają napięć zasilających o wartości 3,3 i 5V z łącznym poborem prądu na poziomie około 500 ma (tablica 4.4). Jako elementy grzewcze zastosowano drutowe rezystory 100Ω o mocy około 1,5W podłączone bezpośrednio do napięcia zasilania. W przypadku załączenia maksymalnej mocy, grzałki pobierają prąd o natężeniu 600 ma. Blok zasilania 5V Napięcie 5V konieczne do zasilenia większości układów elektronicznych systemu wytwarzane jest przez liniowy stabilizator 7805 w obudowie TO220. Stabilizator ten

50 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 49 Tablica 4.4: Bilans poboru mocy przez system Nazwa Pobór prądu Napięcie zasilania ATmega32 22mA 5V 25LC mA 5V DS1306 1,2mA 5V DS18B20 1mA 5V MAX232A 10mA 5V ENC28J60 120mA 3,3V SD/MMC 100mA 3,3V Wyświetlacz LCD 122mA 5V Diody LED 30mA 5V Razem: 200mA (5V) 220mA (3,3V) osiąga wydajność prądową do 1,5A oraz posiada zabezpieczenia termiczne i przeciwzwarciowe. Konieczność dostarczenia prądu o natężeniu około 0,5A wiążę się ze stratami mocy na samym stabilizatorze wyrażonymi wzorem (4.1). W strat = (V in V out ) I out (4.1) co po podstawieniu odpowiednich wartości daje wynik W strat = 3,5W. Wartość taką może odprowadzić metalowa powierzchnia, będąca integralną częścią obudowy stabilizatora. Jednak, celem redukcji temperatury wewnątrz urządzenia, zdecydowano się na zamontowanie małego radiatora do obudowy układu. Blok zasilania 3,3V Napięcie 3,3V (konieczne do zasilenia kontrolera Ethernetu i karty MMC/SD) wytwarzane jest przez liniowy stabilizator LDO firmy Microchip o oznaczeniu MCP1827(S) Stabilizator zasilany jest napięciem 5V. Mały spadek mocy na stabilizatorze ((5V 3,3V ) 0,22A 0,37W ) wiąże się z brakiem konieczności użycia radiatora.

51 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO Sterownik PWM Końcówki mocy kluczujące elementy grzewcze sterowane są sygnałem PWM, którego wypełnienie kontrolują regulatory PID. Mikrokontroler ATmega32 posiada cztery sprzętowe kanały PWM kontrolowane przez używane już w oprogramowaniu systemu timery, stąd konieczność programowej realizacji sterownika PWM. Sterownik PWM zaimplementowany w systemie posiada 8 niezależnych kanałów z przebiegami wyprowadzonymi na port A (8 wejść nieużywanego w projekcie przetwornika ADC). Okres jednego przebiegu PWM trwa około 1 sekundę z szerokością wypełnienia modulowaną w zakresie od 0 do 255. Wartości wypełnienia są programowo buforowane i przepisywane na początku okresu PWM. Do generowania przebiegów wykorzystywane jest przerwanie od przepełnienia zegara Timer0 następujące co około 2 ms. Jako końcówkę mocy zastosowano układ ULN2803 [32] zawierający osiem tranzystorów NPN w układzie Darlingtona. Każda z końcówek posiada wydajność prądową 500mA, maksymalne napięcie wyjściowe równe 50V i zabezpieczenie przed przepięciami w postaci diody. ULN2803 może być sterowany bezpośrednio sygnałami TTL z wyjść mikrokontrolera. Zaimplementowany sterownik PWM pozwala na podłączenie ośmiu obciążeń o maksymalnej mocy 6W każdy. Podłączenie odbiorników o większej mocy wymaga zastosowania dodatkowych tranzystorów Interfejs diagnostyczny RS232 Oprócz interfejsu ethernetowego system wyposażony został w diagnostyczne złącze RS232. Wysyłane na nie są informacje uzyskiwane w trakcie inicjalizacji i pracy systemu - m.in. lista czujników 1-Wire, dane o interfejsie sieciowym (adres IP, MAC) i informacje o odebranych pakietach. Operator może także wysłać do systemu komendy (tablica 4.5) w celu uzyskania dodatkowych informacji. Komunikacja realizowana jest sprzętowo przez moduł USART mikrokontrolera. Jako konwerter poziomów napięć TTL na -15/+15V (wymagane przez specyfikację interfejsu RS232 [2]) zastosowano układ MAX232 [29] w typowej dla niego aplikacji

52 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 51 Komenda k n p r t u Tablica 4.5: Spis komend interfejsu RS232 Opis Konfiguracja systemu Dane o interfejsie sieciowym (adresy IP i MAC, statystyki pakietów) Aktualne wypełnienia kanałów PWM Reset systemu telemetrycznego Aktualnie zmierzone wartości temperatur Uptime (czas działania) systemu (rysunek 4.7). Interfejs pracuje z prędkością kb/s z konfiguracją 8N1 (8 bitów danych, bez bitu parzystości, z pojedynczym bitem stopu). Na płytce znajdują się także dwie sygnalizacyjne diody LED oznaczone jako RX i TX prezentujące aktywność magistrali. Rysunek 4.7: Sposób podłączenia układu MAX232 Niektóre dostępne przejściówki USB-COM posiadają na wyjściu sygnały magistrali RS232 na poziomie napięć TTL (niezgodnie ze standardem). W takim przypadku obecność układu MAX232 uniemożliwia komunikację. Układ ten należy wyjąć z podstawki oraz zewrzeć parami nóżki i Poniżej zamieszczono informacje wysyłane interfejsem RS232 w trakcie inicjalizacji systemu: Telemetria v0.75 Maciej Brencz 2007/08

53 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 52 Wersja: May :03:49 AVR-GCC v1.6.0 ( ) SPI..[ok].* ETH: enc28j60.* EEPROM [id 0x29] 128 kb.* SD [OK] S016B 15552kB.* RTC: DS1306 1WIRE: reset magistrali (urzadzenia slave podlaczone).* DS18B20 x5..- #0 28:80EB5D #1 28:A #2 28:62EB5D #3 28:950D #4 28:2BED5D ETHERNET..[ok].* MAC C * IP * enc28j60 rev. B5 INIT..[ok] DHCP: wyslano pakiet discovery DHCP: oferta (od ) DHCP: wyslano pakiet request DHCP: gotowe! IP: Brama: / B F8 Maska:

54 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 53 NTP: wyslane zapytanie NTP: :05: pyta: kto ma IP ? 4.9. Blok wyświetlacza LCD i klawiatury System zawiera także wyświetlacz alfanumeryczny 2x16 oparty o sterownik HD44780 [20] (rysunek 4.8). Posiada on możliwość zaprogramowania ośmiu znaków użytkownika. Funkcję tą wykorzystano dla liter polskiego alfabetu. Rysunek 4.8: Sposób podłączenia wyświetlacza alfanumerycznego opartego o sterownik HD44780 Na wyświetlaczu prezentowane są informacje o systemie zorganizowane w postaci menu obsługiwanego przez cztery przyciski klawiatury do nawigacji po pozycjach głównego menu i podmenu. Struktura menu przedstawia się następująco: ˆ prezentacja bieżącej godziny i daty oraz pomiarów temperatury z trzech wybranych czujników ˆ pomiary z wszystkich podłączonych czujników temperatury ˆ informacje o warstwie sieciowej: adres IP systemu

55 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 54 adres IP bramy sieciowej informacja o korzystaniu z DHCP statystyka odebranych pakietów statystyka wysłanych pakietów adres MAC systemu ˆ poziomy wypełnienia kanałów sterownika PWM ˆ informacje o systemie: data kompilacji oprogramowania systemu wersja użytego kompilatora czas pracy systemu (tzw. uptime) wersja kontrolera Ethernetu liczba wykrytych czujników temperatury pojemność pamięci firmware systemu informacja o rodzaju i pojemności karty pamięci Sterownik Ethernetu Zgodnie z założeniami systemu telemetrycznego komunikacja powinna odbywać się wg standardu 10Base-T. Obecnie coraz więcej producentów koncentruje się na wytwarzaniu układów dla 10-krotnie szybszego Ethernetu 100 Mb/s. Tak szybka komunikacja wymaga także szybkiego interfejsu, stąd zastosowanie znajduje w takich układach 32-bitowa szyna PCI. Jej obsługa przez 8-bitowy mikrokontroler jest praktycznie niemożliwa, stąd obszar poszukiwań sterownika Ethernetu należało zawęzić do grupy kontrolerów pracujących w standardzie 10Base-T, nadal wytwarzanych przez niektórych producentów. Ich zestawienie zamieszczono w tablicy 4.6. Większość kontrolerów Ethernetu posiada obudowę TQFP o 100 wyprowadzeniach oraz wymaga podłączenia wielu zewnętrznych elementów pasywnych. Na etapie projektowania systemu komunikacyjnego zdecydowano się skorzystać ze sterownika firmy Microchip o oznaczeniu ENC28J60 (rysunek 4.9) [31].

56 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 55 Tablica 4.6: Zestawienie kontrolerów Ethernetu 10Base-T Oznaczenie Magistrala RAM [kb] Pobór prądu [ma] AM79C961A ISA 16 0,26 75 CS8900A uniwersalna 0,26 75 ENC28J60 SPI DM9008 ISA 8/16 4,5 55 LAN91C111 uniwersalna Rysunek 4.9: Schemat blokowy sterownika Ethernetu ENC28J60 Jest to samodzielny kontroler Ethernetu 10Base-T w obudowie z 28 wyprowadzeniami posiadający w swej strukturze sprzętową obsługę tworzenia i dekodowania ramek ethernetowych (z funkcją automatycznego generowania i weryfikacji sumy kontrolnej CRC, uzupełniania ramki do długości 60 bitów, retransmisji w przypadku kolizji oraz opcjonalnego odrzucania pakietów z błędną sumą CRC). ENC28J60 posiada także funkcję sprzętowego filtrowania pakietów wg m.in. adresu MAC. Układ wyposażono w statyczną pamięć RAM o pojemności 8 kb, którą można dowolnie rozdysponować pomiędzy pamięć na ramki wysyłane i odbierane. Przenoszenie danych w pamięci SRAM możliwe jest dzięki szybkiemu interfejsowi DMA. Układ posiada interfejs obsługi przerwań generujący zbocze na odpowiednim wyprowadzeniu.

57 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 56 Kontroler taktowany jest z szybkością 25 MHz i zasilany napięciem 3,3V (maksymalny pobór prądu wynosi 180 ma). Układ posiada interfejs SPI o maksymalnej częstotliwości pracy 20 MHz oraz wejścia zgodne z poziomami TTL (+5V). Sterownik ENC28J60 wymaga niewielu zewnętrznych elementów. Interfejs sieciowy podłączony jest do skrętki za pomocą gniazda RJ45 z wbudowanym transformatorem sygnałowym oraz dwoma diodami sygnalizacyjnymi sterowanymi przez układ kontrolera Implementacja stosu TCP/IP Jednym z głównych problemów pracy była implementacja interfejsu sieciowego dla systemu telemetrycznego. Głównymi ograniczeniami w implementacji stosu TCP/IP w mikrokontrolerze ATmega32 była pojemność pamięci programu (32 kb) oraz pamięci operacyjnej SRAM (2 kb) niemal całkowicie zajętej przez bufor ramki ethernetowej (1518 bajtów). Dodatkowo bufor ten wykorzystywany jest w operacjach na karcie pamięci SD/MMC. Skorzystano z funkcji filtracji ramek sprzętowo realizowanej przez układ ENC28J60 - odrzucane są wszystkie ramki z docelowym adresem MAC innym niż ten przypisany do systemu (nie dotyczy to pakietów wysyłanych na tzw. adres rozgłoszeniowy). Dzięki temu udało się ograniczyć liczbę ramek, które po przetworzeniu przez oprogramowanie systemu byłyby odrzucane jako nieistotne. Kontroler Ethernetu posiada obsługę jedynie sprzętowej warstwy modelu TCP/IP. Interpretacją pakietów i odpowiadaniem na nie musi zająć się oprogramowanie mikrokontrolera ATmega32 nadzorującego pracę całego systemu telemetrycznego. Funkcje implementujące stos TCP/IP znajdują się w pliku net.c. Stos TCP/IP zaimplementowany w systemie realizuje następujące funkcje: ˆ automatyczna konfiguracja warstwy sieciowej systemu za pomocą protokołu DHCP ˆ odpowiadanie na zapytania ARP dotyczące adresu MAC systemu ˆ odpowiadanie na pakiety ICMP typu Echo Request (polecenie ping <adres IP systemu>)

58 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 57 ˆ regularne wysyłanie zapytania NTP do zewnętrznego serwera o synchronizację zegara RTC systemu ˆ obsługa zapytań HTTP ˆ obsługa pakietów UDP skryptu aktualizującego firmware systemu ˆ obsługa komunikacji z pakietem MATLAB Stos zrealizowany w ramach pracy zawiera wbudowaną funkcję net stack() zajmującą się obsługą podstawowych protokołów. W pliku net.h zdefiniowany zostały (w formie struktur języka C) ramki poszczególnych protokołów. Po wykryciu typu ramki, następuje jej zrzutowanie na wskaźnik o typie konkretnej struktury. Pozwala to na łatwą i czytelną interpretację danych zawartych w ramce. Stos zawiera także funkcje net is my ip() i net is my mac() pozwalające sprawdzić czy otrzymany pakiet jest faktycznie adresowany do systemu. Dodatkowo w stosie znajduje się grupa funkcji diagnostycznych net dump... pozwalających na wysłanie na złącze RS232 zawartości podanej ramki ethernetowej, danych o warstwie sieciowej, podanego adresu IP i MAC Obsługa podstawowych protokółów TCP/IP Każdy protokół posiada w stosie własną funkcję obsługi (oznaczoną odpowiednim prefiksem), która jako parametr otrzymuje wskaźnik do danych pakietu konkretnego typu (np. arp packet* dla pakietu ARP [16]). Funkcja winna odpowiednio zinterpretować otrzymane dane, utworzyć odpowiedni pakiet odpowiedzi i wysłać go poprzez interfejs kontrolera Ethernetu. Dostępna pamięć SRAM o pojemności 2 kb nie pozwala na utworzenie dwóch niezależnych buforów na ramkę odebraną i do wysłania - tworzenie nowej ramki odbywa się na ramce właśnie odebranej. Implementacja stosu TCP/IP dostarcza także zbiór funkcji umożliwiających enkapsulację pakietów protokołów warstw wyższych w pakiety coraz niższych warstw (kolejno TCP/UDP, IP oraz Ethernet) - net make... packet(). Realizują one zapis takich danych jak numery portów, adresy IP i MAC systemu oraz zajmują się

59 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 58 obliczaniem sum kontrolnych [1] pakietów IP (net checksum()). Funkcje te zwracają rozmiar utworzonego przez nie pakietu, a jako jeden z parametrów przyjmują rozmiar pakietu warstwy wyższej, który podlega enkapsulacji. Kolejność bajtów Przy interpretacji danych otrzymywanych w pakietach TCP/IP należy zwrócić szczególną uwagę na kolejność bajtów. W pakietach TCP/IP (podobnie jak w procesorach SPARC, Motorola czy Simatic S7) stosuje się bowiem system big endian, w którym to bajt najstarszy przesyłany jest jako pierwszy (analogicznie do stosowanego codziennie sposobu zapisu liczb w systemie dziesiętnym). Z kolei procesory z rodziny Intel x86, AMD64 czy AVR korzystają z systemu little endian, w którym to bajt najmłodszy przesyłany jest jako pierwszy. Przykładowo wartość szesnastkowa 0234EAF2 przesłana jako big endian trafi do odbiorcy w niezmienionej kolejności (0234EAF2), natomiast przesłana jako little endian - w kolejności odwrotnej (F2EA3402). W pliku net.c zaimplementowano funkcje htons i htonl pozwalające konwertować wartości dwu- (integer) i czterobitowe (long) między dwoma formami zapisu. Przykład obsługi protokołu TCP/IP Funkcja obsługi pakietów ARP wygląda następująco: void net_arp_response(arp_packet* arp, ethernet_packet* eth) { unsigned char i; net_dump_ip(arp->src_ip); rs_text_p(pstr(" pyta: kto ma IP ")); net_dump_ip(arp->dest_ip);rs_send(? ); rs_newline(); // sprawdź czy to pakiet dla nas (IP) if (!net_is_my_ip(arp->dest_ip)) return;

60 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 59 // wypełnij pakiet odpowiedzi ARP // // -> przepisz dane nadawcy do odpowiedzi for (i=0; i<4; i++) arp->dest_ip[i] = arp->src_ip[i]; for (i=0; i<6; i++) arp->dest_mac[i] = arp->src_mac[i]; // -> wpisz nasze IP i MAC for (i=0; i<4; i++) arp->src_ip[i] = my_net_config.my_ip[i]; for (i=0; i<6; i++) arp->src_mac[i] = my_net_config.my_mac[i]; // typ pakietu ARP: odpowiedz arp->opcode = HTONS(NET_ARP_OPCODE_REPLY); // twórz pakiet ethernetowy unsigned int len = net_make_eth_packet(eth, (unsigned char*) arp, arp->dest_mac, 28); } // wyślij pakiet enc28_packet_send((unsigned char*)eth, len); Parametrami funkcji jest wskaźnik do struktury zawierającej dane pakietu ARP oraz wskaźnik do danych ramki ethernetowej. Na początku funkcji ma miejsce wysłanie na interfejs diagnostyczny RS232 informacji o odebranych pakiecie ARP z danymi nadawcy i adresem IP, o który zdalny system pyta. Funkcja net is my ip() pozwala sprawdzić czy zdalny system pyta o adres MAC systemu telemetrycznego - następuje porównanie adresu IP z otrzymanego pakietu (arp->dest ip) z adresem IP systemu.

61 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 60 Jeśli zdalny host rzeczywiście pyta o adres MAC systemu, następuje wypełnienie odpowiednich pól struktury odwzorowującej pakiet ARP. Następnie tworzona jest ramka ethernetowa (net make eth packet()) poprzez podanie wskaźnika do bufora w pamięci SRAM, wskaźnika do ramki wyższej warstwy (pakiet ARP), adresu MAC odbiorcy (skopiowanego z otrzymanego pakietu ARP) oraz rozmiaru ramki warstwy wyższej (pakietu ARP). Funkcja enc28 packet send() kopiuje wskazany pakiet z pamięci SRAM mikrokontrolera do bufora kontrolera Ethernetu oraz wysyła komendę żądania wysłania pakietu Obsługa sesji TCP Na podstawie informacji zawartych w [19] oraz korzystając z analizatora pakietów Wireshark (rysunek 4.10) zrealizowano obsługę sesji TCP. Funkcja net stack() określa (na podstawie flag w odebranym pakiecie TCP) jakim rodzajem pakietu należy odpowiedzieć. Obsługa sesji TCP zajmuje się odpowiednim zwiększeniem numerów seryjnego i potwierdzenia pakietu, a w momencie synchronizacji stos generuje losowy numer sekwencyjny. Rysunek 4.10: Analizator pakietów Wireshark Przebieg pojedynczej sesji TCP (od strony flag pakietów TCP) wygląda następująco: > klient

62 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 61 < serwer (system telemetryczny) > SYN < SYN+ACK pakiet odesłany przez net_tcp_synchronize() > ACK > ACK+PUSH treść żądania < ACK < ACK+FIN+PUSH odpowiedź (wygenerowana przez funkcję obsługi danego protokołu) > FIN+ACK < ACK pakiet odesłany przez net_tcp_acknowledge() Funkcja obsługi danego protokołu działającego w oparciu o pakiety TCP (np. HTTP) zwraca tylko dane, które należy przesłać w pakiecie. Utworzeniem odpowiedniego pakietu TCP zajmuje się funkcja net make tcp packet(). Pakiet ten następnie należy przesłać w pakietach protokołów niższych warstw tworząc kolejno ramki typu IP i Ethernet. Obsługa sesji TCP jest zadaniem kosztownym - konieczne jest przechowywanie w pamięci stanu każdej z otwartych sesji (para numerów seryjnych i potwierdzenia, numery portów... ). Dlatego w prezentowanej implementacji stosu zrezygnowano z wysyłania kilku pakietów danych w ramach pojedynczej sesji TCP. System otrzymuje pojedynczy pakiet danych od klienta, generuje i odsyła pakiet odpowiedzi wraz z ustawionymi flagami zakończenia połączenia. Podejście takie znacznie upraszcza implementację stosu i zmniejsza wymagania odnośnie pojemności pamięci RAM, jednak odbywa się to kosztem ograniczenia ilości możliwych do przesłania danych, np. jako odpowiedzi na żądanie HTTP Interpretacja odbieranych ramek Moduł sieciowy systemu działa na zasadzie serwera oczekując na nadchodzące żądania i odpowiadając na nie, samemu nierozpoczynając transmisji (z wyjątkiem okresowych prób aktualizacji nastaw zegara RTC). Przybycie pakietu i jego zapisanie w buforze sterownika ENC28J60 sygnalizowane jest niskim sygnałem na linii przerwania INT1 mikrokontrolera. Następuje wówczas uruchomienie funkcji on int1(),

63 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 62 która magistralą SPI pobiera pakiet z bufora sterownika do pamięci SRAM mikrokontrolera i interpretuje jego zawartość wg schematu: 1. ramki ethernetowe kierowane są najpierw do funkcji net stack() obsługujące protokoły ARP, ICMP, DHCP, NTP i TCP (procedura inicjalizacji sesji TCP i potwierdzania otrzymania pakietów [19]) 2. w przypadku braku możliwości obsługi ramki wewnątrz stosu (funkcja net stack() zwraca wartość NET STACK UNHANDLED), jest ona kierowana dalej 3. kolejne instrukcje warunkowe sprawdzają typ ramki (obsługa tylko ramek typu IPv4) oraz typ pakietu niesionego w ramce IP (UDP lub TCP) 4. po spełnieniu tych warunków w blokach switch (oddzielnych dla pakietów UDP i TCP) znajdują się wywołania funkcji obsługi pakietów nadchodzących na określone porty Deklaracja funkcji obsługi pakietu wygląda następująco: unsigned int foo_handle_packet(unsigned char* data); Funkcja ta przyjmuje jako parametr wskaźnik do danych niesionych przez pakiet UDP/TCP (*data). Funkcja powinna zapisać dane zwrotne pod wskaźnik *data oraz zwrócić rozmiar danych wysyłanych jako odpowiedź - stos zajmie się opakowaniem danych w pakiety niższych warstw oraz wyliczeniem odpowiednich sum kontrolnych. W podany sposób zrealizowana jest obsługa komunikacji ze środowiskiem MA- TLAB, aktualizacja pamięci firmware oraz zaimplementowany prosty serwer WWW. Takie elastyczne podejście ułatwia rozwój systemu poprzez dodawanie nowych funkcjonalności Serwer WWW Zgodnie z założeniami użytkownik systemu powinien posiadać do niego dostęp poprzez przeglądarkę internetową. W tym celu w ramach pracy zrealizowano miniserwer WWW domyślnie pracujący na portach 80 i 8080.

64 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO Wykorzystane technologie Aby uatrakcyjnić wygląd interfejsu (rysunek 4.11), skorzystano z nowoczesnych technologii takich jak CSS, JS i AJAX. Rysunek 4.11: Interfejs WWW systemu telemetrycznego CSS (Cascading Style Sheets) umożliwia określenie wyglądu (np. koloru, rozmiaru, położenia, kroju i stylu czcionki) poszczególnych elementów strony. Java- Script (w skrócie JS) umożliwia zaś stworzenie krótkich funkcji ułatwiających korzystanie z interfejsu WWW. AJAX (Asynchronous Javascript And XML) jest techniką umożliwiającą dynamiczne aktualizowanie treści strony bez konieczności jej przeładowania. Korzystając ze skryptów w języku JavaScript możliwe jest wysłanie w tle żądania do serwera, odebranie odpowiedzi i dokonanie na jej podstawie odpowiednich czynności. Zastosowanie AJAXa umożliwia przykładowo dynamiczne aktualizowanie wartości pomiarów temperatury co sekundę bez konieczności ciągłego odświeżania całej strony, na której prezentowane są wartości. Wystarczy pobranie z serwera krótkiej informacji o samych wartościach temperatur w specjalnym formacie JSON (Java- Script Object Notation), który można łatwo i szybko przetworzyć w języku Java- Script. Przykładowa odpowiedź w tym formacie wygląda następująco:

65 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 64 {0:22.8, 1:22.7, 2:22.7, 3:22.7, 4:22.8} Redukcja ilości przesyłanych danych Przedstawione powyżej podejście do interfejsu redukuje ilość danych, które muszą zostać wysłane do użytkownika oraz obciążenie samego systemu. Dodatkowo kod skryptów w języku JavaScript i stylów CSS znajduje się w osobnych plikach, które przeglądarka pobiera tylko za pierwszym razem. Przechodząc na kolejne podstrony interfejsu przeglądarka pobiera je ze swojej pamięci podręcznej, dzięki odpowiednim nagłówkom Cache-Control dołączanym przez serwer do odpowiedzi: ˆ wartość max-age=0 wymusza stałe odświeżanie zawartości pliku przez przeglądarkę ˆ wartość max-age= informuje przeglądarkę, że może ona korzystać z lokalnej kopii pliku przez 10 lat Implementacja serwera WWW W funkcji obsługi pakietów on int1() znajduje się blok odpowiedzialny za kierowanie pakietów adresowanych na porty 80 i 8080 do funkcji znajdujących się w pliku webpage.c. Serwer WWW implementuje obsługę dwóch podstawowych typów żądań HTTP: GET oraz POST. Żądanie GET stosowane jest do przesyłania statycznych danych, które podlegają buforowaniu przez przeglądarkę na wcześniej opisanych zasadach. Natomiast żądanie POST (wg zaleceń z dokumentu [6]) służy do przesyłania klientowi wyników operacji (np. pomiarów temperatury) oraz wysyłania do serwera poleceń wykonania konkretnej operacji (np. zadanie wypełnienia kanału sterownika PWM). Odpowiedzi na żądania typu POST wysyłane przez serwer nie podlegają buforowaniu przez przeglądarkę. W funkcji webpage handle http() następuje rozdzielenie otrzymanych zapytań HTTP na trzy grupy: 1. podstrony interfejsu (rozkład temperatur, wysterowania kanałów PWM, ustawienia,... ) np. GET \info, GET \ident,

66 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO statyczne pliki: style CSS, skrypty JS i obrazki PNG np. GET \static\util.js, GET \static\telemetry.css 3. dynamicznie generowana zawartość w formacie JSON np. POST \json\status, POST \json\ds Obsługa każdej z podstron interfejsu znajduje się w osobnych funkcjach. Podstrony składane są z trzech szablonów zapisanych w pamięci firmware systemu: nagłówka (tytuł strony, załączenie podstawowych plików JS i CSS, ustawienia strony kodowej tekstu), treści i stopki (informacje o wersji systemu). Każdy ze statycznych plików CSS/JS/PNG również przechowywany jest w pamięci firmware, skąd wybierany i wysyłany jest do użytkownika przez funkcję webpage get static content(). Funkcja webpage get json content() zajmuje się interpretacją i generowaniem odpowiedzi w formacie JSON. Możliwe jest pobranie wartości pomiarów temperatur z czujników, informacji o systemie, zmiana nastaw zegara RTC, odczyt i zmiana wypełnienia wybranego kanału sterownika PWM oraz przeprowadzenie procedury identyfikacji parametrów Firmware systemu Dane statyczne (szablony stron HTML, pliki CSS, skrypty JS, obrazki PNG) przechowywane są w pamięci EEPROM - firmware, skąd za pomocą funkcji firmware read sector() z pliku firmware.c mogą zostać skopiowane do podanego bufora (np. do ramki ethernetowej). Pamięć zastosowana w systemie (moduł o interfejsie SPI z rodziny 25xxxx [30]) ma pojemność 1 Mb (128 kb). Posiada ona wydajność do miliona cykli kasowania i zapisu oraz czas przechowywania danych wynoszący ponad 200 lat. Fizycznie pamięć składa się ze stron po 256 bajtów każda. Programowo zawartość pamięci została podzielona na sektory o pojemności 1,2 kb (5 fizycznych stron). Pierwszy sektor (oznaczony numerem 0) zawiera informacje o zajętości sektorów - kolejne bajty w tym sektorze zawierają dwubajtowe słowa określające rozmiar danych w kolejnych sektorach pamięci (wartość 0 oznacza pusty sektor). Taka organizacja

67 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 66 pamięci pozwala na zapisanie do 128 plików (o rozmiarze do 1250 bajtów), które mogą być wykorzystywane m.in. przez zaimplementowany w systemie mini-serwer WWW. Aktualizacja Za aktualizację zawartości pamięci firmware systemu odpowiada prosty skrypt napisany w języku PHP (loader.php). Na podstawie podanej listy plików tworzy on obraz, który wgrywany jest do pamięci EEPROM z użyciem protokołu UDP. Skrypt loader.php zawiera dwie zmienne konfiguracyjne ($host i $port) określające pod jakim adresem IP działa system, którego pamięć chcemy zaktualizować oraz na jakim porcie UDP zdalny system nasłuchuje na pakiety aktualizujące firmware. Tablica asocjacyjna $files zawiera spis plików, które należy wgrać do systemu wraz z numerami sektorów, do których każdy z nich powinien trafić. Skrypt na podstawie powyższych danych tworzy binarny obraz kolejnych sektorów i przesyła go porcjami 256 bajtowymi do systemu w pakietach UDP kierowanych na port Każdy pakiet posiada pięciobajtowy nagłówek z informacją o typie pakietu i adresie, od którego zacząć zapisywać dane. Skrypt weryfikuje także poprawność procesu aktualizacji oraz wyświetla jego podsumowanie. Aktualizacja pamięci możliwa jest w trakcie pracy systemu. Niezbędne jest jedynie późniejsze odświeżenie strony w przeglądarce WWW Omówienie kodu źródłowego Oprogramowanie systemu powstało w języku C [2] w darmowym środowisku AVR Studio (w wersji 4.13) udostępnianym przez producenta mikrokontrolera ATmega32 - firmę ATMEL. Kompilator zawarty w tym środowisku pozwala jedynie na kompilację programów napisanych w asemblerze, dlatego skorzystano z darmowego kompilatora języka C - WinAVR z biblioteką avr-libc w wersji [24]. Oprogramowanie systemu pracuje na zasadzie przerwań. Po przeprowadzeniu inicjalizacji mikrokontrolera i wszystkich jego peryferiów program wchodzi w nieskończoną pętlę, oczekując na następujące zdarzenia:

68 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 67 ˆ przerwanie od opadającego zbocza na INT0 generowane przez zegar RTC DS1306 co sekundę ˆ przerwanie od opadającego zbocza na INT1 generowane przez sterownik ENC28J60 po odebraniu pakietu ethernetowego ˆ przerwanie od przepełnienia zegara Timer0 (co 2 ms) wykorzystywane przez sterownik PWM do generowania przebiegów na wyjściach końcówki mocy ˆ przerwanie od przepełnienia zegara Timer1 (co 25 ms) wykorzystywane przez funkcję poolingu sprawdzającą regularnie stan urządzeń peryferyjnych systemu (pobranie aktualnego czasu z zegara RTC, dokonanie pomiaru temperatury, aktualizacja wskazań menu, odbiór komend z interfejsu RS232) Dla ułatwienia prac kod został podzielony na pliki wg realizowanych funkcji: ˆ telemetry.h dane konfiguracyjne systemu (przypisanie wyjść mikrokontrolera, załączenie pozostałych plików nagłówkowych, makrodefinicje) ˆ telemetry.c funkcje inicjalizacyjne systemu, obsługa przerwań ˆ lib/1wire obsługa magistrali 1-Wire ˆ lib/config obsługa zapisu/odczytu konfiguracji systemu z pamięci EEPROM mikrokontrolera ˆ lib/daq komunikacja z systemem MATLAB i akwizycja danych z poziomu intefejsu WWW ˆ lib/ds1306 obsługa zegara czasu rzeczywistego (RTC) DS1306 ˆ lib/ds18b20 funkcje obsługi czujnika temperatury DS18B20 ˆ lib/eeprom obsługa pamięci EEPROM z interfejsem szeregowym z rodziny 25xxxx ˆ lib/enc28 obsługa kontrolera Ethernetu ENC28J60

69 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 68 ˆ lib/firmware obsługa pobierania danych statycznych z pamięci firmware systemu i jej aktualizacji ˆ lib/fs prosty system plików tworzony na karcie pamięci SD/MMC ˆ lib/keys obsługa klawiatury ˆ lib/lcd obsługa wyświetlacza alfanumerycznego ˆ lib/menu obsługa menu ˆ lib/net implementacja stosu TCP/IP ˆ lib/pwm programowy sterownik PWM ˆ lib/rs obsługa magistrali szeregowej RS232 ˆ lib/sd obsługa kart pamięci SD/MMC ˆ lib/spi funkcje pomocnicze obsługi magistrali SPI ˆ lib/webpage obsługa żądań HTTP Nazwy funkcji poprzedzone są przedrostkami określającymi, którego fragmentu funkcjonalnego kodu dotyczą. Istotną kwestią przy programowaniu mikrokontrolerów z rodziny AVR są wartości bitów konfiguracyjnych (tzw. fuse bits), których zestawienie znajduje się na rysunku W przypadku wymiany mikrokontrolera ATmega32 na inny egzemplarz konieczne jest ich odpowiednie zaprogramowanie Wykonanie części elektronicznej systemu Schematy ideowe i montażowe (dodatek B) stworzone zostały w programie Eagle, płytki powstały metodą termotransferu. Na etapie projektowania i testów korzystano z prototypowych płytek stykowych (rysunek 4.13).

70 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 69 Rysunek 4.12: Ustawienia bitów konfiguracyjnych dla mikrokontrolera ATmega32 Złącza dostępne na płytce Płytkę systemu wyposażono w następujące złącza: ˆ gniazdo zasilania DC 5mm / podwójne złącze ARK ˆ złącze DB9 interfejsu RS232 ˆ gniazdo RJ45 do podłączenia kabla sieciowego ˆ złącze czteropinowe do podłączenia czujników temperatury zamontowanych na płytce grzewczej ˆ złącze interfejsu programowania ISP typu KANADA (2x5 pinów) do podłączenia programatora mikrokontrolera ATmega32 ˆ wyprowadzenia końcówki mocy sterownika PWM dostępne na zaciskach typu ARK ˆ gniazdo do podłączenia wyświetlacza LCD

71 ROZDZIAŁ 4. KONSTRUKCJA SYSTEMU TELEMETRYCZNEGO 70 Rysunek 4.13: System telemetryczny zmontowany na płytkach stykowych Blok zasilania System wyposażony jest w typowe gniazdo DC 5mm pozwalające podłączyć dowolny stabilizowany zasilacz 12V o wydajności prądowej minimum 1A. Dodatkowo na płytce znajdują się dwa zaciski typu ARK, do których podłączyć można np. wyprowadzenia zasilacza ATX. Na płytce umieszczono mostek prostowniczy - dzięki temu nie jest istotna polaryzacja napięcia na wtyku zasilającym DC / złączu ARK. Trzy diody LED sygnalizują obecność trzech napięć zasilających: +3,3, +5 i +12V.

72 Rozdział 5 Konstrukcja systemu sterowania 5.1. Sterowanie gradientem temperatury We współczesnym przemyśle wtryskarki, pakowarki, piece wielostrefowe, urządzenia stosowane w produkcji półprzewodników stawiają wysokie wymagania co do sterowania temperaturą, szczególny nacisk kładąc na odpowiedni rozkład temperatury w wielu punktach pomiarowych. Niejednorodność temperatury lub jej nieodpowiedni rozkład w procesach przejściowych może wyraźnie wpłynąć na jakość końcowego produktu uzyskiwanego w procesie produkcyjnym. Rysunek 5.1: Rozproszenie temperatury na powierzchni płyty grzewczej W procesach termicznych niejednorodność temperatury na powierzchni przewodzącej ciepło obserwowana jest zarówno w czasie trwania procesów przejściowych jak i w stanie ustalonym. W stanie ustalonym niejednorodność taką można usu-

73 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA 72 nąć stosując proste regulatory PID oraz odpowiednio projektując samą maszynę uwzględniając charakterystyki cieplne. Niejednorodność temperatury w procesach przejściowych spowodowana jest zjawiskiem przewodzenia ciepła od grzałek do ogrzewanego przedmiotu. Płyta grzewcza jest zwykle przymocowana do obudowy urządzenia skutkując zróżnicowaną rezystancją cieplną na jej powierzchni (rysunek 5.1). Zjawisko to jest obserwowane szczególnie w przypadku dużych i cienkich powierzchni grzewczych. Zależności termiczne między grzałkami rozmieszczonymi na powierzchni płytki wprowadzają do systemy nieliniowości, które są zależne od m.in. kształtu ogrzewanej powierzchni, rozmieszczenia na niej grzałek, rezystancji termicznej itd. Zastosowanie klasycznego regulatora PID do tego typu zadań jest więc znacznie utrudnione. Odprzężenie statyczne Rozpatrywany system posiada wiele sprzężeń między poszczególnymi obszarami ogrzewanej powierzchni. Grzałka włączona w jednym z obszarów wpływa (jako sygnał zakłócający) na temperaturę sąsiednich. Rysunek 5.2: Sterowanie z odprzężeniem Autorzy publikacji [9] wprowadzili do modelu systemu człony odprzęgające D 1 i D 2 usuwające wzajemne zależności między grzałkami (rysunek 5.2) dane wzorami: D 1 = P 12(0) P 11 (0) D 2 = P 21(0) P 22 (0) (5.1) (5.2)

74 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA 73 Precyzyjna identyfikacja parametrów nieliniowych zależności termicznych P ij w rozpatrywanym systemie jest niezwykle trudna, stąd zdecydowano się na rozpatrywanie zależności niskiego rzędu korzystając tylko ze wzmocnień statycznych sterowanego obiektu, bez uwzględnienia dynamika obiektu. Jest to jednak zabieg wystarczający do osiągnięcia pożądanej jednorodności w stanach przejściowych Opis algorytmu W celu zapewnienia jednorodności temperatury także w stanach przejściowych, zaproponowano w [9] nowe podejście oparte na fizycznych właściwościach zjawiska przewodzenia ciepła [11]. Rysunek 5.3: Sterowanie gradientem temperatury Niejednorodność temperatury wynika, co oczywiste, z różnic temperatur w poszczególnych punktach. Jeśli możliwe jest więc sterowanie różnicą temperatur (gradientem), możliwe jest także sterowanie z zachowaniem jednorodności temperatury. Zadanie sterowania podzielono więc na dwa podzadania: 1. sprowadzenie gradientu temperatur między punktami pomiarowymi do zera, celem minimalizacji wzajemnych sprzężeń 2. sterowanie wartością średnią temperatur wg przyjętego punktu odniesienia

75 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA 74 Rysunek 5.3 przedstawia schemat systemu sterowania wg proponowanego algorytmu. Układ sterowania składa się z klasycznych regulatorów PID, konwertera G m i prekompensatora G c. Sterowaniu podlega obiekt zamodelowany jako G p. Zadaniem konwertera G m R n n jest konwersja zmierzonych wartości temperatur na wartość średnią i gradienty, gdzie n to liczba kanałów, dla których odbywa się sterowanie. Wartościami zadanymi są wartość średnia t ref ave i zadane wartości gradientów t ref grad(i) (dla i = 1... n 1). Rysunek 5.4 przedstawia przykład dla wartości średniej i gradientu z dwóch punktów pomiarowych x 1 i x 2, z których uzyskiwane są wartości temperatur odpowiednio t 1 i t 2 przy zadanej wartości SP (Set Point). Rysunek 5.4: Interpretacja wartości średniej i gradientu Wartość średnia i wektor gradientów wyrażają się następującymi wzorami: t ave = n 1 j=0 t j n (5.3) t grad = [t 1 t 0,..., t n 1 t n ] (5.4) Stąd konwerter G m przedstawić można jako macierz:

76 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA 75 G m = 1 n n n n (5.5) Należy zaznaczyć, że wyrażenia (5.3) i (5.4) nie są określone odgórnie i powinny zostać zmodyfikowane zależnie od warunków, które zostaną przedstawione dalej. Prekompensator G c pełni dwie funkcje: konwertuje wyjścia regulatorów PID na wartości, którymi należy wysterować grzałki oraz wprowadza odprzężenie zależności termicznych między obszarami (wyrażających się jako elementy pozadiagonalne macierzy G p ). Druga funkcja wymaga znajomości parametrów modelu sterowanego obiektu (macierz G p ). Identyfikacja modelu obiektu Rysunek 5.5 przedstawia sposób identyfikacji parametrów modelu obiektu G p. Na grzałki podawany jest 30 sekundowy skok wartości sterującej, następnie przez czas 180 sekund następuje naturalne chłodzenie obiektu, po czym załączana jest kolejna grzałka. Obiekt identyfikowany jest metodą zależności wejście/wyjście. Jeśli sprzężenia termiczne są słabe, G p jest macierzą diagonalną: G p = diag (G 00, G 11,..., G nn ) (5.6) W praktycznych aplikacjach elementy pozadiagonalne nie mogą jednak zostać pominięte z uwagi na obecność (często dość silnych) sprzężeń. Stąd prekompensator G c musi być zaprojektowany tak, aby redukować pozadiagonalne elementy macierzy G p : G c = (G m G p ) 1 (5.7) Dobór parametrów Aby zapewnić statyczne odsprzężenie spełniony musi być warunek (5.8) nieosobliwości iloczynu macierzy konwertera G m i modelu obiektu G p.

77 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA 76 Rysunek 5.5: Metoda identyfikacji G p [9] G m (0) G p (0) 0 (5.8) W praktyce elementy diagonalne macierzy G p będą dominujące i warunek nieosobliwości zostanie spełniony, jeśli odpowiednio dobrany zostanie wektor t grad. Przy jego tworzeniu należy uwzględnić odległości między punktami pomiarowymi, moc poszczególnych grzałek oraz rezystancję termiczną płyty. Praca [9] sugeruje użycie w tym celu metody elementów skończonych. Zadaniem przedstawionego algorytmu jest zminimalizowanie sprzężeń termicznych poprzez utrzymywanie możliwie najmniejszych wartości gradientów w poszcze-

78 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA 77 gólnych punktach. Za sterowanie tymi wartościami odpowiadają regulatory PID, stąd niezwykle istotny jest odpowiedni dobór wartości ich parametrów. W tym celu zastosować można metodę Zieglera-Nicholsa [7] lub inne metody stosowane do wyznaczania nastaw regulatorów PID. Sygnał identyfikacyjny podawany jest na transmitancję G m G p G c. Odpowiedź układu w stanie przejściowym jest uzależniona od najwolniejszego z torów. Stąd parametry regulatora odpowiedzialnego za sterowanie wartością średnią t avg powinny wynikać z nastaw regulatora dla najwolniejszego elementu wektora gradientów Interfejs WWW Dostęp do systemu możliwy jest z poziomu dowolnej nowoczesnej przeglądarki WWW (takiej jak Opera, Firefox czy Internet Explorer). Rysunek 5.6: Interfejs WWW systemu w przeglądarce Opera Użytkownik poprzez interfejs WWW (rysunek 5.6) zyskuje dostęp do: ˆ aktualizowanych co sekundę pomiarów temperatury, ˆ sterownika PWM (podgląd aktualnych wartości wypełnień w poszczególnych kanałach oraz możliwość ich zmiany), ˆ funkcji akwizycji danych z wybranego czujnika temperatury określając częstotliwość próbkowania oraz ilość próbek do zapisania w pliku na karcie pamięci SD/MMC,

79 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA 78 ˆ procedury identyfikacji parametrów systemu (rozdział 5.1.1), ˆ informacji o systemie (dane o używanej karcie pamięci, wersji oprogramowania, adresie IP i MAC, możliwość zmiany nastaw zegara RTC systemu wg czasu komputera) Współpraca ze środowiskiem MATLAB W pakiecie GUIDE przygotowano graficzną aplikację typu DAQ (rysunek 5.7) dla systemu MATLAB pozwalającą na akwizycję danych pomiarowych z systemu telemetrycznego i ich wizualizację na wykresach. Aplikacja posiada funkcję eksportu zebranych danych do pliku mat lub przestrzeni roboczej celem ich dalszej obróbki. Rysunek 5.7: Aplikacja DAQ w środowisku MATLAB W środowisku MATLAB zrealizowano także szereg pomocniczych m-skryptów służących m. in. do identyfikacji parametrów macierzy G p [9], wyznaczania wartości

80 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA 79 macierzy G m i G c oraz parametrów regulatorów PID. Wykorzystano także pakiet Simulink jako regulator sterujący w czasie rzeczywistym procesem termicznym poprzez sieć Ethernet. Funkcja akwizycji danych (dostępna z poziomu interfejsu WWW) pozwala na zapis pomiarów do pliku na karcie pamięci. Dane te można następnie pobrać i zaimportować do pakietu MATLAB. Implementacja komunikacji sieciowej Komunikacja sieciowa zrealizowana została z wykorzystaniem darmowego toolboxa TCP/UDP/IP toolbox for MATLAB (dostęp do pomocy możliwy jest po wpisaniu w konsoli polecenia help pnet). Przesyłanie danych odbywa się w pakietach UDP wysyłanych do systemu telemetrycznego na port Ramki komunikacyjne mają następujący format: ˆ pierwszy bajt zawiera kod rodzaju instrukcji do wykonania przez system (odczyt, zapis) ˆ drugi bajt zawiera kod instrukcji do wykonania (zwrócenie liczby czujników, wartości pomiarów temperatury, wysterowań kanałów PWM, informacji o wersji, zadanie zmiany wysterowania konkretnego kanału PWM) ˆ kolejne bajty zawierają dane specyficzne dla danej instrukcji (np. wartości pomiarów temperatury) Przykładowe instrukcje prezentują się następująco: ˆ i zwraca informacje o systemie (wersja oprogramowania) ˆ rt dokonuje odczytu pomiarów temperatur ˆ rf pobiera wartości wypełnień wszystkich kanałów sterownika PWM ˆ sf156 ustawia wypełnienie kanału 1 sterownika PWM na wartości 56 Graficzna aplikacja DAQ oraz m-skrypty pełnią w komunikacji z systemem telemetrycznym rolę klienta, który rozpoczyna komunikację, wysyła odpowiednie komendy i oczekuje na odpowiedzi.

81 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA Testowa płytka grzewcza W celu zbadania w praktyce implementowanego algorytmu sterowania gradientem temperatury zmontowano na płytce uniwersalnej prosty układ z pięcioma modułami: grzałką opartą o rezystor 100Ω (moc grzewcza ok. 1,5W) oraz cyfrowym czujnikiem temperatury DS18B20 (rysunek 5.8). Rysunek 5.8: Testowa płytka grzewcza Moduły zostały rozmieszczone liniowo w odległości co 12 mm. Całość została przykryta metalową płytką o grubości 2,5 mm ściśle przylegającą do modułów. Płytka posiada wyprowadzone zaciski do podłączenia napięcia zasilania +12V oraz wyjść z końcówki mocy. Wyprowadzone zostało także złącze goldpin służące do podłączenia magistrali 1wire wraz z zasilaniem +5V czujników temperatury. Tak zmontowana płytka grzewcza podlegała czynnościom opisanym w dalszych punktach Implementacja algorytmu w pakiecie MATLAB W pakiecie MATLAB stworzono, obok przedstawionej wcześniej aplikacji typu DAQ, model systemu wraz z regulatorami PID, dając możliwość sterowania rzeczywistym obiektem z poziomu systemu MATLAB.

82 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA Układ otwarty Prace w pakiecie Simulink rozpoczęto od stworzenia modelu płytki grzewczej w układzie otwartym (rysunek 5.9). Rysunek 5.9: Model układu otwartego w pakiecie Simulink Model ten pozwala na dowolną zmianę (za pomocą suwaków) wypełnienia każdego z pięciu kanałów PWM wysterowujących grzałki umieszczone na płytce. Do przestrzeni roboczej zapisywane są wartości wysterowań oraz mierzone temperatury. System opisany jako Płytka grzewcza zawiera w sobie wywołanie m-funkcji heater.m. Funkcja ta jest bezpośrednim połączeniem środowiska symulacyjnego z rzeczywistym obiektem w postaci płytki grzewczej. Wysyła ona pakiety UDP zadanymi wysterowaniami kanałów PWM oraz pobiera aktualne wartości temperatur. Blok RTBlock synchronizuje pracę środowiska Simulink z czasem rzeczywistym. Zamykanie pętli zwrotnej następuje co sekundę - jest to okres wystarczający do sterowania tak wolnozmiennymi procesami jak procesy termiczne. Wykonano szereg pomiarów w układzie otwartym korzystając z interfejsu WWW systemu (zakładka Wyjścia). Przebiegi temperatur będące wynikiem pobudzenia skokiem jednostkowym jednego z kanałów PWM znajdują się na rysunku Układ pobudzono skokiem wartości sterującej ogrzewaniem kanału nr 5. Zaznacza się, opisywany we wstępie teoretycznym, wpływ sprzężeń - wzrost temperatury następuje również w pozostałych kanałach.

83 ROZDZIAŁ 5. KONSTRUKCJA SYSTEMU STEROWANIA 82 Rysunek 5.10: Przebieg temperatur w odpowiedzi na pobudzenie skokiem jednostkowym jednego z kanałów Identyfikacja parametrów płytki grzewczej W połączeniu z interfejsem WWW systemu możliwe jest przeprowadzenie procedury identyfikacyjnej (rysunek 5.5) parametrów macierzy G p [9] modelującej płytkę grzewczą. W zakładce Identyfikacja należy kliknąć przycisk Rozpocznij identyfikację - na okres 30 sekund załączane będą kolejne kanały sterownika PWM z odstępami 180 sekundowymi na schłodzenie się płytki. Rysunek 5.11: Przebiegi uzyskane w trakcie identyfikacji parametrów modelu systemu