Ujednoliciliśmy także nasze licencjonowanie do GPLv3 co ma na celu głównie dostosowanie ochrony licencyjnej do współczesnego stanu informatyki. GPLv3 bierze pod uwagę między innymi systemy prawne spoza USA, kwestie patentów na oprogramowanie, ochronę DRM, proceder tiwoizacji oraz problem istnienia wielu niezgodnych ze sobą licencji. Po więcej informacji odsyłamy na oficjalną stronę projektu GNU.

Kolejna nowinka dotyczy SZARPa pod Windows’em! Utrzymanie oddzielnego kodu dla użytkowników Microsoftowego systemu operacyjnego zastąpiliśmy nową funkcjonalnością, która pojawiła sie w systemach Windows 10 Professional. Użytkownicy tego systemu mogą korzystać z najnowszej wersji naszego oprogramowania za pomocą terminala Ubuntu (instrukcja jak to zrobić jest już tutaj). Dzięki temu użytkownicy Windowsa mają możliwość używania wersji Linuksowej, a my, programiści, możemy skupić się na rozwijaniu jednego kodu co znacznie upraszcza jego utrzymanie.

Podczas tych prac narodziła się potrzeba wprowadzenia obsługi nowego protokołu FC firmy Danfoss. Protokół ten określa technikę dostępu zgodnie z zasadą master-slave dla komunikacji szeregowej. Nie będziemy się tu rozwodzić na temat szczegółowej specyfikacji, ale warto zwrócić uwagę na jakość i ilość dokumentacji. Ostrzegamy – godna polecenia jest tylko angielskojęzyczna wersja dokumentacji.

Po krótkiej dyskusji na temat czy powinien to być osobny program czy może wykorzystać całe dobro oferowane przez metadaemon, szerzej znany jako borutadmn, odpowiedź była jasna. Nasza poczciwa boruta dostanie kolejny protokół do obsługi. Tylko od czego zacząć?

My zaczęliśmy od przeglądu dokumentacji (raz kolejny polecamy wersje angielskojęzyczną!), gdzie określimy newralgiczne momenty tego protokołu. Mieliśmy nie zagłębiać się w szczegółową specyfikację, ale protokół tego wymagał. Z dokumentacji dowiedzieliśmy się, że w celu uzyskania danych musimy stworzyć 16 bajtowy telegram

gdzie:

• STX jest zawsze 0x02 (nie lubimy magic numbers),
• LGE w przypadku 16 bajtowego telegramu zawsze będzie 0x0E (hic!)¹,
• ADR to jest adres naszego slave, powiększony o 0x80 (7 bit zawsze jest 1),
• Databytes to zawartość telegramu (rozwinięte poniżej),
• BCC to suma kontrolna w postaci logicznego XOR na wszystkich pozostałych bajtach.

Databytes w naszym przypadku zawiera 6 pozycji 2 bajtowych – PKE, IND, PWE_HIGH, PWE_LOW, PCD₁, PCD₂. W PKE znajduje się numer parametru oraz funkcja o jaką prosimy żeby falownik wykonał z danym parametrem. IND wykorzystywany jest do odpytania parametrów typu array. Pozostałe pozycje wykorzystane są przez slave w celu przekazania informacji.

Wracając do borutydmn, jest to metadaemon zawierający już w sobie wtyczki do obsługi takich protokołów jak modbus (tcp i serial, client i server), zet (tcp i serial, client), fp210 (serial, client), lumel (serial, client), wmtp (tcp, client). Oparty jest na obsłudze zdarzeń z biblioteki libevent, która zapewnia ciągłość wykonywanych zadań na wielu urządzeniach. Zapewnia to wydajną pracę przy jak najmniejszym nakładzie pracy sprzętu. Pisząc nowy moduł do naszego metadaemona staraliśmy się trzymać standardu C++11, co nie zawsze było zgodne z duchem naszej boruty.

Po kilku dniach nierównej walki borutadmn został okiełznany i nasz contributor otrzymał pierwsze dane z falownika Danfoss VLT 6000. Nastąpiła faza testów tak zwanych na stole, które wykryły szereg nieprawidłowości w utrzymaniu stabilności komunikacji. Błędy te zostały jak najszybciej zlokalizowane i poprawione.

Konfiguracja odczytu z falowników Danfoss za pomocą protokołu FC jest bardzo zbliżona do konfiguracji daemona dla innych protokołów. Na potrzeby naszego nowego modułu musieliśmy wprowadzić nowy atrybut do elementu param zwany parameter-number znajdujący się w przestrzeni nazw ipk-extra. Odpowiada on numerowi parametru, który chcemy odczytać. Po szczegóły konfiguracji zapraszamy do naszej sekcji Dokumentacja.

W najbliższym czasie wtyczka powinna pojawić się w nowszym metadaemonie borutadmn_z opartym na libzmq co oferuje jeszcze więcej możliwości, m.in. odczyt i zapis danych 2/4 bajtowych bez znaku.

__________________
¹ – na nasze potrzeby wykorzystujemy jedynie telegramy 16 bajtowe (LGE=0x0E), ale dopuszczalne są również telegramy 8 bajtowe wtedy pod LGE podstawiamy 6

SZARP w typowej instalacji składa się z jednego procesu akumulującego dane wszystkich parametrów, oddzielnego procesu zajmującego się zapisywaniem parametrów do bazy, procesu udostępniającego aktualne dane przez protokół HTTP, procesów (zwanych demonami) komunikujących się ze urządzeniami, gdzie często jest to jeden proces uruchomiony na jedno urządzenie.

Wszystkie te procesy wykorzystują „znane i lubiane” UNIX-we mechanizmy komunikacji międzyprocesowej, aktualne wartości parametrów przekazywane są przez segmenty pamięci dzielnej, do której dostęp odbywa się za pomocą klasycznego schematu czytelników i pisarzy, a dane do urządzeń przekazywane są przez kolejki komunikatów.

Poniżej w sposób artystyczny przedstawiono część systemu SZARP zajmującą się akwizycją parametrów oraz mechanizmów komunikacji między tej części składowymi:

Taki sposób zaprojektowania systemu oraz sposób jego implementacji posiada kilka bardzo przyjemnych cech, jak wyraźna separacja między poszczególnymi komponentami i ich zadaniami oraz odporność systemu jako całości na awarie jego pojedynczych komponentów.

Niestety, obecna implementacja posiada też kilka ograniczeń, których świadomość istnienia, z czasem stała się dla nas na tyle dolegliwa, że postanowiliśmy coś z tym zrobić.

Jednym z ograniczeń obecnej architektury systemy jest to, że wartości przemierzające trasę od urządzeń do bazy danych, nie mają związanych ze sobą znaczników czasowych. Założenie jest takie, że wszystko co znajduje się w obszarach pamięci dzielonych to wartości aktualna. Dostęp do tych danych poszczególne komponenty dokonują ze stałą częstotliwością, a dokładny moment kiedy to się odbywa ustalany jest przez tyknięcia zegara danego komponentu (+ ew. oczekiwanie na uzyskanie dostępu do danego obszaru). Ponieważ zegary poszczególnych komponentów nie są ze sobą zsynchronizowane, wrzucając daną wartość do bazy danych, nigdy nie możemy być pewni kiedy dokładnie ta wartość została pobrana – wiemy jedynie że stało się to od 1 do 4 tyknięć zegarów temu. Ponieważ zazwyczaj zegary pracują z wystarczająco szybko, ta różnica nie ma znaczenia. Jednak czasami warto by było być bardziej dokładnym, i szybszym.

Drugą kwestią jest zafiksowanie architektury na jednym typie wartości, 16-bitowych liczbach całkowitych. To co segmenty pamięci dzielonej przechowują, to właśnie tablice 16-bitowych int-ów. Co prawda rzeczywistość jest trochę bardziej skompilowana i SZARP nie ma problemów ze zbieraniem i przetwarzaniem wartości o większym rozmiarze, to faktem jest, że problem ten nie jest rozwiązany w sposób systematyczny.

Jak więc sugeruje tytuł tego tekstu, postanowiliśmy przebudować odrobinę istniejącą architekturę SZARPa.

Zatem, już bez dalszych wstępów, Panie i Panowie, oto przed Wami – projekt nowego SZARPa! (replika pracy anonimowego artysty z XXI wieku)

Jak można zauważyć, istnieje kilka zasadniczych różnic między istniejącą a planowaną architekturą. Przede wszystkim, głównym mechanizmem komunikacji miedzy procesami nie jest już pamięć dzielona, a sockety ZeroMQ pracujące w schemacie producent-konsument.

Pojawia się nowy, centralny komponent systemu parhub, którego zadaniem jest rozgłaszanie otrzymanych komunikatów (wysyłanych głównie przez demony), do wszystkich zarejestrowanych konsumentów. Parhub jest to jedyny proces, z którym muszą się komunikować pozostałe komponenty systemu.

Drugą istotną zmianą jest to, że wartości przesyłane w komunikatach zawierają znacznik czasowy. Niezależnie od tego jak długo dany kounikat podróżował do celu, zawsze jesteśmy w stanie precyzyjnie powiedzieć kiedy dokładnie dana wartośc została pobrana. Poza tym, komunikaty są przesyłane asynchronicznie, a zatem komponent otrzymujący komunikat może zacząc jego przetwarzanie natychmiast, nie będąc związany tyknięciami żadnego zegara.

Istotną zmianą jest również to, że wartości parametrów przesyłane w komunikatach mogą mieć różne typy i rozmiary.

Bardzo ważną cechą nowej architektury jest fakt, że parcook może zostać do niej wpięty jako jeszcze jeden demon, co pozwoli na jej stopniowe wdrażanie, bez konieczności przerabiania od razu wszystkich demonów na nowy sposób komunikacji.

Teraz wystarczy tylko zakasać rękawy i do roboty!

Oprogramowanie SZARP jest aktywnie rozwijane już od przeszło 20 lat i co za tym idzie z pewnością znajdziemy w nim fragmenty kodu napisane te kilkanaście lat temu. W tamtym czasie do kodowania znaków narodowych (których w języku polskim nie brakuje) stosowano szereg rozproszonych standardów opisanych w normie ISO/IEC_8859. Rok 2006 przyniósł istotną zmianę – do użytku zaczął wchodzić, dziś powszechnie używany, jednolity system kodowania UTF-8 (implementujący standard Unicode). W czym rzecz? Przecież SZARP wspiera i używa kodowania UTF-8 nie od wczoraj.

Otóż nie do końca – okazało się, że w zadziwiająco wielu miejscach kodowanie Latin-2 (ISO 8859-2) było albo wpisane „na sztywno” albo uznawane za domyślne (dekadę wcześniej wydawało się to właściwe). W szczególności dotyczyło to modułu odpowiadającego za konwersję pomiędzy różnymi kodowaniami. Stąd „krzaki” w napisach wychodziły tu i ówdzie przy różnych okazjach. I dlatego należało tę kwestię uporządkować.

Wprowadzone zmiany nie były znaczące ilościowo, bo zamknęły się w zaledwie kilkuset liniach kodu, ale poprawiane funkcje konwersji są używane przez niemal każdą część SZARP-a. Z tego powodu wszelkie modyfikacje musiały być wprowadzane ostrożnie i potem starannie testowane. Mimo zachowania tych zasad kilka błędów się przemknęło i ujawniło kilka miesięcy później.

W tej chwili, po pół roku pracy i testowania poprawionej wersji SZARP-a na serwerach i terminalach, możemy ogłosić, że SZARP w pełni wspiera kodowanie UTF-8.

W implementacji użyto technologii WebSockets, otwierającej nowy paradygmat programowania aplikacji internetowych – asynchronicznego przepływu informacji na linii serwer-przeglądarka bez konieczności interakcji ze strony użytkownika. Dzięki temu stało się możliwe aktualizowanie na bieżąco danych przychodzących od serwera SZARP i wyświetlanie ich w przeglądarce. Drugim przykładem zastosowania tej technologii jest zaimplementowana przez firmę Newterm mobilna wersja panelu sterowania.

• deb http://newterm.pl/debian precise main

(Wskaż menadżerowi pakietów w swoim łuskowcu wyżej podany URL żeby zainstalować paczki SZARPa)

• git clone https://github.com/Newterm/szarp.git

Przypuszczalnie przez jakiś czas strona szarp.sf.net zostanie aktywna, jednak nie planujemy jej aktualizować – wszelkie nowe zmiany będą trafiały na githuba.

Niewątpliwie największą (ciągle będącą w fazie „prodkucji”) zmianą to nowy format bazy danych SZARPa. Cała ta fatyga z nowym formatem bazy danych ma taki cel, by SZARP mógł przechowywać w sposób efektywny dane z (niemal) dowolną rozdzielczością czasową. Oprócz tego że SZARP będzie bardziej „precyzyjny”, to także:

• Baza danych będzie zajmowała mniej miejsca na dysku.
• Skróci się czas synchronizacji bazy danych.
• Zniknie podział na synchronizowane na lokalny komputer wartości 10-minutowe oraz pozostające wyłącznie na serwerze, do których dostęp wymaga aktywnego połączenia do serwera/internetu średnie 10-sekundowe.
• Przy nowym formacie bazy danych wszystkie dane będą sychronizowane na lokalny komputer, a późniejszy do nich dostęp będzie możliwy off-line.

Jedną ze zmian wprowadzanych do bazy danych niejako przy okazji, to obsługa wielu typów danych. Aktualna baza SZARPa pozwala na przechowywa nie tylko jednego typu daych, co w zdecydowanej większości wypadków jest wystarczające, ale dla niektórych rodzajów parametrów jednak nieoptymalne i wymagające ekstra zabiegów, gdy dany parametr nie pasuje do jednego ogólnie przyjętego profilu. Razem z nowy formatem i silnikiem bazy danych przybędzie więcej ciekawych możliwości, ale o nich szczegółowo opowiemy jak będziemi mieli już wszystko gotowe. Z pozostałych nowinek, może nie tak dużych jak zmiana formatu bazy danych, ale też wartych uwagi, wymienić można:

• Do draw3 dodana została opcja ekstrakcji danych, chociaż w dużej mierze duplikuje ona funkcjonalność ekstraktora3 to pozwala na szybkie (bez potrzeby odpalnia dodatkowej aplikacji) wykesportowanie danych do pliku. W odróżnieniu od ekstraktora3, w draw3 można eksportować dane z zestawów użytkownika oraz sieciowych. Biblioteka obsługująca logowanie w SZARPie „liblog” została rozbudowana o obsługę konfigurowalnych backednów. Dzięki tej zmianie SZARP potrafi logować z na kilka sposobów:
  – Logowanie klasyczne – jest to sposób wykorzystywany dotychczas przez SZARPa, logowanie odbywa się poprzez bezpośrednie pisanie do plików
  – Syslog – ten backend loguje za pomocą standardowej unixowej biblioteki syslog
  – Async_syslog – to naszego wlasnego autorstwa, oparta na liblog biblioteka implementująca protokół syslog, napisana z myślą o aplikacjach wykorzystującyh libevent
• W draw3 na wykresach rocznych, miesięcznych, tygodniowych oraz okresu sezonu możliwe jest wybranie czy każdy punkt ma reprezentować:
  – wartość średnią parametru dla właściwego okresu czasu (roku dla dekady, miesiąca dla roku, itd.), jest to domyślny (i jedyny dostępy dotychczas) sposób rysowania wykresów
  – ostatnią wartość z okresu reprezentowanego przez punkt (czyli np. na ekranie rocznym każdy punkt będzie reprezentował wartość parametru z ostaniego dnia miesiąca godziny 23:50) różnicę między ostatnią a pierwszą wartośćią 10-minutową próbką dla okresu reprezentowanego przez punkt (np. dla roku będzie to różnica między wartością z 23:50 ostatniego dnia miesiąca a 00:00 pierwszego dnia miesiąca)
  Ostatnie dwa warianty są szczególnie przydatne przy rysowaniu parametrów reprezentujących wartośći licznikowe. Zmiany sposobu rysowania wykresów dokunuje się z menu kontekstowego listy wykresów (z prawej strony okna).
  i jak zwykle, mnóstwo drobnych usprawnień i bug-fixów.