__________________________________________
* Politechnika Poznańska.
Michał KRYSTKOWIAK*
Mariusz ŚWIDERSKI*
CYFROWY STEROWNIK ROZPROSZONY
FUNKCJONUJĄCY W RAMACH INTERNET OF THINGS
W artykule przedstawiono budowę prototypu sterownika rozproszonego wyposażo- nego w jeden spójny panel użytkownika, stanowiący interfejs HMI. Sposób realizacji sterownika, ze względu na specyfikę obranego algorytmu sterowania, opisano w trzech częściach, a mianowicie: wprowadzającej, programowej i elektrycznej. W części wpro- wadzającej omówiono koncepcję sterowania oraz uproszczony algorytm pracy sterowni- ka, w części programowej przybliżono najistotniejsze kwestie dotyczące budowy aplika- cji internetowej oraz oprogramowania mikrokontrolera. W części elektrycznej zaprezen- towano natomiast schematy oraz obwód drukowany płyty sterownika.
SŁOWA KLUCZOWE: Internet rzeczy, sterowanie rozproszone, inteligentna instalacja domowa
1. WPROWADZENIE
Powszechny i coraz tańszy dostęp do Internetu stanowi medium, które nie jest już postrzegane tylko jako narzędzie pozwalające wysyłać i odbierać pocztę elektroniczną oraz przeglądać strony internetowe. Obecnie Internet jest nośni- kiem informacyjnym łączącym większość urządzeń w naszym otoczeniu, przy- kładowo: kalendarz online z własnymi notatkami można przeglądać zarówno w telefonie, komputerze, a nawet w zegarkach. Podobnie dzieje się z analizą natę- żenia ruchu w naszych miastach. Czujniki umieszczone na skrzyżowaniach w mieście i kamery gromadzą informacje o ruchu i przez sieć internetową transfe- rują je do serwerów, które przetwarzają dane na postać przyjazną użytkowniko- wi, po czym ją wyświetlają na tablicach w mieście, na stronach internetowych, czy też w aplikacjach mobilnych.
Niestety większość wymienionych rozwiązań charakteryzuje się nieprzystęp- ną ceną i wymogiem posiadania tzw. stałego adresu IP. Dla przeciętnego użyt- kownika są to dość istotne ograniczenia. O ile wysoka cena może być do zaak- ceptowania, to już nie zawsze istnieje techniczna możliwość uzyskania stałego adresu IP. Wychodząc naprzeciw tym wymaganiom i chcąc stworzyć proste
i niedrogie urządzenie będące podstawą do zbudowania systemu rozproszonego sterowania [6] przeznaczonego dla każdego użytkownika autorzy zaproponowali rozwiązanie opisane w niniejszym artykule.
Założeniami wstępnymi budowanego systemu było spełnienie następujących postulatów:
– urządzenia powinny funkcjonować mając dostęp fizyczny do dowolnej sieci LAN (z dostępem do Internetu),
– zapewnienie możliwości zarządzania pracą dowolnej ilości sterowników za pomocą jednego panelu użytkownika końcowego stanowiącego interfejs HMI,
– zachowanie konkurencyjnej ceny w stosunku do innych rozwiązań oferowa- nych na rynku.
2. OPROGRAMOWANIE STEROWNIKA I APLIKACJI INTERNETOWEJ
Koncepcyjnie przyjęty został model składający się z: interfejsu użytkownika – układ sterująco-nadzorczy, płyty sterownika – układ wykonawczy, bazy da- nych – układ pośredniczący w wymianie danych. Poglądowo tą koncepcję za- prezentowano na rys. 1.
Rys. 1. Koncepcja działania sterownika
Należy pamiętać, że koncepcja wyjściowa zakłada istnienie więcej niż jednej płyty sterownika, która z punktu widzenia systemu dla użytkownika będzie tworzyć jeden integralny system.
Działanie sterownika mikrokontrolerowego rozpoczyna się m.in. od inicjali- zacji zmiennych, ustalenia kierunku wejść i wyjść, konfiguracji timera i połą- czenia UART [2]. Następnie w głównej pętli programu sprawdzana jest wartość binarnej zmiennej kontrolnej, której stan zmieniany jest w timerze. Gdy wartość zmiennej wynosi 1, wtedy następuje odpytanie serwera PHP, a zwrotnie zostaje pobrana zawartość strony, na której znajduje się określona ramka danych.
W przepisywaniu ramki z postaci ciągu znakowego do tablicy uczestniczy bufor cykliczny, który otrzymane dane konwertuje (tzw. proces prasowania) na doce- lowy format [3]. Ostatnim fragmentem pętli głównej jest odczytywanie stanu
przycisków wejściowych. Wejścia sterownika reagują na zbocze nastrajające, a następnie zostaje wykonanie przepisywanie ich stanów do tablicy wejść celem ich późniejszego wysyłania. Opisany algorytm przedstawiono na rys. 2.
Rys. 2. Algorytm realizowany przez mikrokontroler w sterowniku
Komunikacja pomiędzy płytą sterownika, a aplikacją internetową odbywa się za pomocą skryptu PHP o nazwie check.php [5]. Przykładowo skrypt ten wywoływany jest przez sterownik w następujący sposób (rys. 3):
Rys. 3. Adres internetowy wywołujący zdarzenie na panelu użytkownika
Jest to tak naprawdę strona internetowa, która dynamicznie reaguje na powyż- sze zapytanie, generując w treści następujący ciąg znaków (rys. 4):
Rys. 4. Ramka danych dla sterownika
gdzie: a – oznacza ciąg znaków reprezentujący początek ramki, b – jest to wek- tor wyjść [0-7], c – oznacza bit wyboru priorytetu pomiędzy przyciskami fi- zycznymi, a sterowaniem zdalnym, d – jest to ciąg znaków reprezentujący ko- niec ramki.
Sterownik każdorazowo, co określony interwał czasowy (domyślnie testo- wany 2 s), łączy się z skryptem check.php używając podanej formy adresu (rys. 3). Skrypt sprawdzając poprawność danych, wyświetla odpowiednie dane dla wybranego sterownika na stronie. W przypadku, gdy dane mają niepopraw- ny format lub są niekompletne skrypt nie wyświetli żadnej treści, co będzie jednoznaczne z niepoprawną komunikacją. Sterownik na brak ramki w odpo- wiedzi nie zareaguje niespodziewanie, gdyż ramka nie zawiera frazy początko- wej ani końcowej. Wybór fraz sterujących ramką okazał się zagadnieniem dość kłopotliwym w realizacji. Jednoznakowe lub składające się ze znaku specjalne- go frazy sterujące powodowały, że do analizy brane były niezamierzone treści ramki, np. fragmenty komunikatów o błędzie serwera. Testując różnego rodzaju frazy, wybrane zostały zaprezentowane powyżej, gdyż podczas testów nie zo- stały zakłócone żadnymi niepożądanymi danymi. Podsumowując komunikacja między sterownikiem, a aplikacją internetową zachodzi przez prosty plik skryp- tu, który na pytanie w postaci adresu internetowego wysłanego przez sterownik odpowiada stroną internetową, która jest odczytywana, a następnie analizowana przez sterownik. Omawiany tok postępowania został szczegółowo zilustrowany na rys. 5.
Aplikacja kliencka (rys. 6) składa się z panelu użytkownika oraz panelu ad- ministracyjnego, dostępnego dla użytkownika z odpowiednimi uprawnieniami.
Poziom uprawnień zapisywany jest w bazie użytkowników w polu permissions danego użytkownika. Użytkownik standardowy na ekranie swojego urządzania widzi plan obiektu, w którym dany sterownik pracuje. Ponadto aplikacja pozwa- la na zmianę hasła aktualnego użytkownika oraz na zarządzanie sesją, tj. logo- wanie lub wylogowanie. Panel standardowego użytkownika składa się ze strony html, która odpowiedzialna jest za wygląd, skryptu jQuery i Ajax wykonanego w technologii JavaScript oraz skryptów po stronie serwera w technologii PHP.
Użytkownik nie dostaje wprost możliwości edycji wyglądu głównego oka pane- lu – okno to jest przygotowywane wraz z sterownikiem dla każdego użytkowni- ka indywidualnie. Oczywiście proces ten został odpowiednio zautomatyzowany poprzez wbudowane funkcje Ajax i powtarzalne bloki kodu, ostatecznie projek- tant panelu musi tylko znać język html i podstawy JavaScript.
Rys. 5. Algorytm realizowany przy każdym połączeniu sterownika z skryptem check.php
Rys. 6. Wygląd panelu użytkownika (widoczny przykładowy plan obiektu)
Dla każdego modułu w systemie do dyspozycji jest 17 elementów sterują- cych gotowych do implementacji.
Tabela 1. Opisy elementów tablicy sterującej wyglądem panelu użytkownika Opis wejścia Nazwa JS Opis wyjścia Nazwa JS
Wejście 0 [nazwa]_stat_in0 Wyjście 0 [nazwa]_stat_out0 Wejście 1 [nazwa]_stat_in1 Wyjście 1 [nazwa]_stat_out1 Wejście 2 [nazwa]_stat_in2 Wyjście 2 [nazwa]_stat_out2 Wejście 3 [nazwa]_stat_in3 Wyjście 3 [nazwa]_stat_out3 Wejście 4 [nazwa]_stat_in4 Wyjście 4 [nazwa]_stat_out4 Wejście 5 [nazwa]_stat_in5 Wyjście 5 [nazwa]_stat_out5 Wejście 6 [nazwa]_stat_in6 Wyjście 6 [nazwa]_stat_out6 Wejście 7 [nazwa]_stat_in7 Wyjście 7 [nazwa]_stat_out7
[nazwa]- nazwa modułu Priorytet
sterowania [nazwa]_stat_auto Panel użytkownika jest wyposażony w moduł logowania i zmiany hasła. Sam proces logowania, od strony Ajax jest bardzo prosty ponieważ jeśli login i hasło są przesłane, to wykonywana jest metoda CheckUser, której argumentami są właśnie zmienne login i hasło przesłane z formularza. Wyświetlanie błędów w wypadku podania nieprawdziwych danych, przeładowanie strony po popraw- nym załadowaniu i inne aspekty wizualne obsługiwane są w skrypcie przy po- mocy jQuery. Logowanie po stronie serwera działa w następujący sposób:
– zmienne login i hasło są oczyszczane z znaków niebezpiecznych dla SQL, a hasło dodatkowo jest przetwarzane przez kryptograficzną funkcję skrótu oraz dopisane do pewnej stałej frazy – ma to na celu zapewnienie bezpie- czeństwa, gdyż baza wtedy nie przechowuje jawnie hasła użytkownika, – przy użyciu powyższych danych jest generowane zapytanie do bazy,
– następuje wykonanie zapytania oraz sprawdzenie czy zwrócono jeden rekord, – jeżeli zwrócono jeden rekord tworzona sesja i wypełniona zostaje tablica
sesji.
Gdy liczba rekordów różna jest od 1 wtedy użytkownik dostaje komunikat o niepowodzeniu logowania.
Po zalogowaniu użytkownika z uprawnieniami administracyjnymi (rys. 7) w dolnej części panelu athome pojawi się link do panelu administracyjnego.
Cały panel administracyjny pozwala na zarządzanie modułami: dodawanie, usuwanie i edycja (dla testów), a także na pełne zarządzanie użytkownikami w systemie. Panel nie jest obsługiwany dynamicznie, a więc po każdej akcji następuje przeładowanie strony.
Rys. 7. Wygląd panelu użytkownika (widoczny przykładowy plan obiektu)
3. BUDOWA ELEKTRYCZNA STEROWNIKA
W dalszych rozważaniach zaprezentowano warstwę fizyczną płyty sterowni- ka, przy budowie której starano się zminimalizować ilość elementów systemu (rys. 8.).
Rys. 8. Struktura architektury sprzętowej sterownika
Dokonując wyboru rozwiązania dla zrealizowania komunikacji Wi-Fi, posłu- żono się modułem ATNEL-WIFI232-T [4]. Zawiera on niezbędne elementy konieczne do realizacji transmisji, a ponadto dysponuje szeregiem funkcji, które można wykorzystać przy rozbudowie systemu. Najważniejsze cechy modułu wymieniono poniżej:
– obsługa protokołu TCP/UDP, a także http,
– obsługa 3 trybów pracy: jako STA (station) czy AP (acces point), a także trybu mieszanego AP+STA,
– konfiguracja przy pomocy komend AT,
– system obsługujący w pełni stos TCP dla IPv4 i IPv6, – wyprowadzenia RX i TX do komunikacji UART (RS232), – obsługa standardów WIFI b/g/n,
– obsługa zabezpieczeń WEP, WPA, WPA2 oraz szyfrowania AES,
– pin zarządzania poborem prądu,
– małe wymiary 22 mm x 13,5 mm x 6 mm, – certyfikat FCC/CE.
Podczas wyboru mikrokontrolera kierowano się dwoma czynnikami, a mia- nowicie ceną i zgodnością z posiadanymi programatorami. Doskonałym wybo- rem okazał się mikrokontroler rodziny AVR ATMEGA8A-AU. Maksymalna częstotliwość taktowania mikrokontrolera wynosi 16 MHz, jednak nie jest to najbardziej optymalna wartością zewnętrznego oscylatora, ponieważ według noty katalogowej przy Baud Rate równym 115200 bps liczba błędów w trans- misji może wynosić -3,5% całej transmisji. Korzystając z dokumentacji tech- nicznej dobrano częstotliwość taktowania o wartości 11,0592 MHz, zapewnia- jąc tym samym błąd na poziomie 0% dla Baud Rate równego 115200 bps. Ele- mentami wykonawczymi na płycie sterownika są przekaźniki RM96-1011-35- 1005. Parametry wybranych przekaźników w zupełności wystarczające, by ste- rować większością urządzeń w domach. Jednak z uwagi, iż prąd cewki przekaź- nika jest dość duży, a w systemie pracować może 8 przekaźników jednocześnie należało zastosować układ ULN2803ADW. Jest to układ scalony typu darling- ton, posiadający 8 wyjść każde po 500 mA i o maksymalnym napięciu 50 V, co w zupełności odciąża mikrokontroler. Zabezpieczeniem zarówno układu ULN2803ADW, jak i mikrokontrolera ATMEGA8A-AU przed przepięciami pochodzącymi od cewki przekaźnika są diody LL4148 o napięciu wstecznym na poziomie max 100 V i prądzie przewodzenia równym 150 mA.
Schemat, jak i płyta PCB zostały zaprojektowane w programie Eagle.
Układ zasilania bazuje na złączu, na które podawane jest napięcie stabilizo- wane +5 V i jest wyposażone w diody LED, który sygnalizują obecność napięcia o wymaganych parametrach.
Rys. 9. Schemat układu zasilania wraz z mikrokontrolerem
Rys. 10. Widok zmontowanej płyty sterownika
Wyjścia sterownika fizycznie stanowią przekaźniki (dla każdego z nich zo- stała dodana dioda, która sygnalizuje aktualny stan pracy wyjścia). Wejściami układu są bezpośrednio wyprowadzone piny mikrokontrolera. W przypadku długich linii lub linii narażonych na zakłócenia elektromagnetyczne, należy za- stosować dodatkowo diody, które będą chroniły przed przepięciami, jak również przed potencjałem ujemnym na wejściu.
5. WNIOSKI I PODSUMOWANIE
Zaprojektowany i zbudowany sterownik, jak również opracowany algorytm sterownia spełnia oczekiwania autorów. Najbardziej problematyczna, z punktu widzenia poświęconego czasu, okazała się budowa i konstrukcja ramki przesy- łania danych. Pierwszą założoną ramka była ramka w formacie #00000000#, początkowo pozbawiona możliwości sterowania priorytetem. W sytuacji takiej przypadkowo sterownik do analizy pobierał ciąg znaków, który nie był efek- tem pracy skryptu, a stroną błędu serwera. Niestety, ani dostawca usług www nie mógł przeciwdziałać temu zjawisku, ani oprogramowanie moduły Wi-Fi, dlatego została podjęta decyzja, że słowa sterujące ramką muszą zostać zmie- nione na sof00000000eof. Modyfikacja okazała się rozwiązaniem dzięki któ- remu sterownik nie miał problemów z odbieraniem właściwych danych pocho- dzących od skryptu php. Podczas uruchamiania sterownika napotkano na pew- ne problemy ze stabilnością połączenia w sieciach lokalnych lub stabilnością samych połączeń internetowych, na które użytkownik nie ma wpływu.
Sterownik w zupełności spełnia postawione na początku wymagania. Po- twierdziły to testy, w których nie było sytuacji aby jakieś polecenie zostało zignorowane przez sterownik. Odnotowano wprawdzie kilku sekundowe opóź- nienia, ale były one spowodowane opóźnieniami wynikającymi z konstrukcji sieci.
LITERATURA
[1] Lyons R.G.: Wprowadzenie do cyfrowego przetwarzania sygnałów. WKŁ, War- szawa 1999.
[2] Francuz Tomasz: AVR. Praktyczne projekty. Helion 2013.
[3] Kardaś Mirosław: Język C Pasja programowania mikrokontrolerów 8-bitowych Wydanie II. Atnel 2014.
[4] http://atnel.pl/atnel-wifi232-t.html - ATNEL-WIFI232-T
[5] Świderski M.: ROZPROSZONY CYFROWY STEROWNIK URZĄDZEŃ DOMU INTELIGENTNEGO, Praca magisterska, Poznań 2015.
[6] Kaczorek T.: Teoria sterowania i systemów. PWN, Warszawa 1999.
THE DIGITAL DECENTRALIZED CONTROL SYSTEM WITHIN THE INTERNET OF THINGS
The article presents the construction of a distributed control prototype equipped with one consistent user control panel, which is the HMI interface. The realization of the control, due to the nature of the chosen control algorithm, was described in three parts, namely: introducing, software, and electrical. The introducing part explains the concept of controlling and simplified algorithm of the controller work. The software part approximates the most important issues concerning the construction of a web application and microcontroller’s software. While the electrical part presents schemes and printed circuit of controller board.
(Received: 5. 02. 2016, revised: 4. 03. 2016)
