SZARP ewoluuje !

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

Porządki w kodowaniu znaków w SZARP-ie

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.

SZARP na urządzenia mobilne

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.

Zerkając w przyszłość…

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

SZARP na Ubuntu Precise

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)

Przeprowadzka na githuba

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.

Co tam Panie w SZARPie?

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.

Wiosenne porządki i nieustający marsz naprzód

Witajcie użytkownicy SZARPa! Wiosna nadeszła, a za kilka dni będziemy jeść wielkanocne jajka, pomyśleliśmy ze to bardzo dobry moment żeby napisać co działo sie z SZARPem przez ostatnie klka tygodni:

  • wypuściliśmy nową wersję SZARPa dla Windows, jej głównym atutem w stosunku do wersji poprzedniej jest znaczące przyśpieszenie synchronizacji danych (ponad 2,5-krotne), poza tym ta wersja zawiera wszystkie nowe ficzery które znajdują się w linuxowej wersji systemu SZARP.
  • nasz kolega zakończył pracę nad nową aplikacją systemu – PyIPK. PyIPK jest to oparte na pluginach narzędzie do edycji konfiguracji systemu SZARP (plików params.xml). Jako pierwsza aplikacja w SZARPie posiada zarówno graficzny (oparty na Qt) jak i tekstowy interfejs użytkownika.
  • uporządkowaliśmy kod serwera komentarzy oraz najbardzej chyba złożonej częsci draw3 – kontrolera wykresów dodaliśmy nowy duży feature do draw3 – parametry i zestawy sieciowe (ale o tym już pisaliśmy).

Ta lista w żaden sposób nie wyczerpuje wszystkich zmian jakie zaszły w SZARPie od naszego ostaniego podsumowania, w tym czasie do repozytorium SZARPa zostało wprowadzonych ponad 700 zmian zawierających dużo drobnych poprawek i usprawnień których nie sposób tutaj wymienić.
Do następnego razu i udanego dyngusa!

Pakiety SZARPa dla dystrybucji Ubuntu Oneric

Właśnie zamieściliśmy pakiety SZARPa skompilowane dla dystrybucji Ubuntu Oneric. Najnowszą wersję SZARPa skompilowną dla Oneiric-a można zainstalować po wprowadzeniu następującego adresu repozytorium w menadźerze pakietów:

  • http://newterm.pl/debianoneiric main

Od tej chwili Oneric staje się oficjalnie wspieraną przez nas wersją Ubuntu.

SZARP jesienią

Ostatnie miesiące były bardzo pracowitym okresem dla deweloperów systemu SZARP którzy byli zaangażowani w dwa większe projekty rozwojowe dotyczące SZARPa. Projekty te prawdopodobnie ujrzą świtało dzienne na początku przyszłego roku. W międzyczasie udało nam się przygotować kilka mniejszych i nie takich znowu małych zmian do systemu SZARP:

  • Uzupełniono dokumentację daemona uśredniającego meaner3.
  • Przywrócono przycisk ‚SEZON’ w interfejsie programu przeglądającego.
  • Poprawiono obsługę kodowania ISO-8859-2 w programie raporter.py.
  • W daemonie k601dmn dodano zabezpieczenie na wypadek braku dostępu do portu szeregowego. Program będzie próbował odzyskać połączenie co minutę.
  • Poprawiono dwa drobne błędy we wtyczce modbus do daemona boruta.
  • Dodano funkcję logowania aktywności programu przeglądającego pozwalającą na lepsze dostosowanie aplikacji do potrzeb użytkowników.
  • Poprawiono system logowania zdarzeń w programie przeglądającym żeby nie blokował programu w wypadku braku połączenia sieciowego.
  • Usunięto błąd powodujący wyłączanie się programu przeglądającego przy używaniu parametrów i zestawów sieciowych w przypadku nie skonfigurowanego serwera komentarzy.
  • Poprawiono wyświetlanie informacji o dostępności nowej wersji programu przeglądającego.
  • Usunięto błąd w menu programu przeglądającego.
  • Poprawiono wsparcie dla pythona2.x w skryptach wykorzystujących ten język.
  • Dodano nową aplikację do edycji konfiguracji – pyipk.
  • Poprawiono skrypty instalacyjne pakietu szarp-xsltd aby nie nadpisywał konfiguracji przy aktualizacji.
  • Poprawiono wsparcie dla protokołu Modbus ASCII w daemonie boruta.
  • Usprawniono obsługę zestawów zawierających więcej niż 12 wykresów w programie przeglądajacym.
  • Poprawiono program filler aby poprawnie zachowywał się na Debianie Squeeze.
  • Zmieniono domyślnie używany parser konfiguracji na szybszy i mniej pamięciożerny parser oparty na xmlReader API.