SZARP przenosi swój kod źródłowy na GitLab’a! Nasze repozytorium istnieje teraz pod tym adresem. Przejście na nową platformę do zarządzania repozytorium podyktowane zostało przez wiele jej zalet w stosunku do serwisu GitHub. Dzięki systemowi płynnego wdrażania możemy szybciej dostarczać aktualizacje naszego oprogramowania, a mnogość dostępnych narzędzi pozwala nam skupić się na pisaniu kodu i zapewnieniu najlepszej jakości naszego produktu.
GitLab posiada wiele praktycznych funkcjonalności, między innymi zintegrowany system śledzenia zadań, który pozwala na modyfikację wielu zadań jednocześnie. Jak wiadomo jakość kodu zależy w dużej mierze od rygorystycznego podejścia do jego recenzowania, a od teraz nie musimy angażować do tego zewnętrznych narzędzi, ponieważ GitLab oferuje nam wbudowane rozwiązanie. Oprócz tego posiada mechanizm monitorowania całego cyklu produkcji kodu, a także alternatywną opcję zarządzania projektem za pomocą SSH. Dużym plusem GitLab’a jest również szczegółowa dokumentacja dotycząca operacji na repozytoriach, którą udostepnia. Kolejną funkcjonalnością, z której skorzystaliśmy jest uruchomienie platformy na swoim serwerze, bez obawy o bezpieczeństwo i dostępność kodu zapewniane przez zewnętrzną firmę 😉 Oprócz ułatwień, do takiej zmiany skłoniła nas rosnąca liczba programistów, którą zrzesza GitLab.

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.

W ostatnim czasie bardzo dużo działo się w naszym projekcie na githubie. Zaczęliśmy od generalnego przeglądu kodu w celu pozbycia się wszelkiego rodzaju błędów i ostrzeżeń w czasie kompilacji i budowania paczek z naszym SZARPem. Przy okazji tych prac porzuciliśmy wsparcie dla analizy (boilery out!), psetd oraz sporej gamy przedawnionych daemonów. Później wzięliśmy się za przeniesienie naszych aplikacji okienkowych na bardziej aktualną wersję wxWidgets co znacznie usprawni wprowadzenie nowych funkcjonalności. W międzyczasie poprawiliśmy sterte (nie stos) błędów, bardzo często mylnie oznaczonych jako features. W tym roku zespół contributorów wyszedł z tarczą. Ba, nawet trzema.

 

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

 

W związku z nowymi zaleceniami dotyczącymi dobrego utrzymania stron internetowych, od tej pory strona szarp.org będzie serwowana za pomocą protokołu https. Jednocześnie następuje zmiana w sposobie dostępu do pakietów szarpa. Od tej pory adresem pod którym można znaleźć repozytorium szarpa jest packages.szarp.org

SZARP, od samego początku (pomijając krótki okres niemowlęctwa, gdy działał pod kontrolą systemu operacyjnego DOS) posiada architekturę bardzo, w swoim duchu, UNIX-ową. SZARP to kolekcja niezależnych procesów, z których każdy posiada (z grubsza) tylko jedno zadanie i, z założenia, ma je wykonywać idealnie 🙂

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! 🙂

W minionym półroczu SZARP przeszedł gruntowne porządki związane z kodowaniem znaków. Rzecz pozornie bez znaczenia dla zwykłego użytkownika, ale w praktyce jednak nader często doskwierająca. O co chodzi?

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 ostatnich miesiącach SZARP został rozbudowany o wsparcie dla urządzeń mobilnych. Wersja mobilna programu przeglądającego udostępnia wszystkie podstawowe funkcje takie jak: przeglądanie wykresów, tryb rozdwojonego kursora, wartości średnie i sumaryczne, wyszukiwanie parametrów i zestawów po nazwach. Wersja mobilna została zaimplementowana w przenośnej technologii HTML5+JS, dzięki czemu może być uruchamiana na każdym urządzeniu mobilnym, niezależnie od systemu operacyjnego (w szczególności wspierane są systemy Android i Windows Phone). Interfejs użytkownika został przeprojektowany tak, by zapewnić wygodną pracę nawet na małych ekranach telefonów przy użyciu zdarzeń dotyku. Dzięki temu wersja mobilna oprogramowania SZARP, stanowi dobre uzupełnienie dla bazowego systemu SZARP, uruchamianego na komputerach PC.

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.

Oj, strasznie zaniedbujemy Szanownych Czytelników witryny http://szarp.org skąpo sącząc informacje ze świata SZARPa. Żeby chociaż trochę poprawić nasze notowania, śpieszymy z kolejnym wpisem. Dzisiaj mamy dla Was jeszcze ciepły, prosto z naszej kuźni, screenshot eksperymentalnej wersji programu draw3.

No dobra, obrazek jak obrazek, można powiedzieć. Co właściwie zasługuje w nim na uwagę?  Bardzo uważny czytelnik może dostrzec jedną rzecz, której w produkcyjnej wersji programu zobaczyć nie można. A mianowicie rozdzielczość rysowanego wykresu. Jest to coś czego dotychczas SZARP nie był w stanie swoim użytkownikom zaoferować – rysowany wykres ma rozdzielczość pół-sekundy. Osiągnięcie takiej rozdzielczości było możliwe dzięki nowemu formatowi bazy danych, który przynajmniej teoretycznie rzecz biorąc pozwala na względnie efektywne przechowywanie danych z rozdzielczością do jednej nano sekundy. Co prawda w przypadku draw3 rysowanie wykresów o rozdzielczości 1ms byłoby problematyczne, ale gdy zaistnieje taka potrzeba, jak najbardziej do zrobienia! Ok, to kiedy będzie SZARPa z nowym formatem bazy danych będzie można zobaczyć w akcji na żywo? Już nie długo, mamy nadzieję. Musimy jeszcze posuwać trochę błędów oraz dobudować kilka brakujących elementów układanki. Gdy to się stanie, nie omieszkamy o tym poinformować.

Wychodząc naprzeciw szerokim rzeszom naszych użytkowników, którzy już od wielu miesięcy domagają się paczek SZARPa na wydany w kwietniu Ubuntu 12.04 LTS (Precise Pangolin), prezentujemy – SZARP i precyzyjny łuskowiec:

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

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

Podążając za najnowszymi trendami, SZARP przenosi swój kod źródłowy na github’a. Nowy URL projektu to https://github.com/Newterm/szarp. Zassać kod źródłowy SZARPa można używając np. takiej komendy:

• 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.

Oj, obijaliśmy się ostatnio z uzupełnianiem http://szarp.org. Nie żeby w SZARPie nic się nie działo, co to to nie. Z powodu właśnie takich zajęć jak rozwój SZARPa i intensywna praca, aktualizowanie strony odkładane było ad calendas graecas. Jednak tego zaniedbania nie dało się zbyt długo ukryć przed szefostwem 😉 Po kilkukrotnym nagabywaniu, że nic tu się nie dzieje, nie pozostało nam nic innego, jak nadrobić zaległości. Oto krótka notka z tego co u SZARPa słychać.

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.