Styczeń przyniósł ponad 30 większych zmian w repozytorium SZARP. Duże części programu przeglądającego draw3 zostały w poprzednim miesiącu przepisane w celu uproszczenia kodu, co spowodowało wprowadzenie sporej ilości drobnych błędów. Do czasu upewnienia się, że wszystkie zostały usunięte, wstrzymujemy jeszcze opublikowanie kolejnej wersji 'stabilnej’. Najważniejsza funkcjonalna zmiana jaka zaszła w SZARP to usprawnienie komunikacji z aplikacjami Windows korzystającymi z mechanizmu DDE. (Dynamic Data Exchange) to starodawny protokół typu „kolejka komunikatów” wprowadzony przez Microsoft w Windows 2.0 w 1987 (!) roku. Umożliwia programom wymianę krótkich komunikatów o dowolnej treści, np. poinformowanie edytora tekstu o zmianie wartości komórki w Excelu. Firma Wonderware, producent popularnego oprogramowania SCADA – InTouch, była jedną z pierwszych, które wprowadziły DDE do zastosowań w automatyce przemysłowej. Jest także twórcą NetDDE – odmiany DDE działającej przez sieć, która była nawet licencjonowana przez Microsoft i dostępna w wielu wersjach systemu Windows. Ostatecznie z powodów bezpieczeństwa zniknęła z Windows wraz z drugim service packiem do Windows XP i wydaniem Windows Vista. Jednak stare dobre DDE dostępne jest we wszystkich wersjach, nawet w nowym ślicznym Windows 7 (przy okazji – SZARP pod Windows według raportów użytkowników działa także pod Windows 7). Poza tym zawsze można doinstalować NetDDE od Wonderware. DDE z założenia jest technologią niebezpieczną – nie ma żadnej możliwości zidentyfikowania, od kogo pochodzi komunikat dostarczony do aplikacji. Nowsze technologie, takie jak COM, OLE czy OPC miały zastąpić DDE, ale jest ono nadal popularne w wielu zastosowaniach, w tym także w wymianie danych z systemami SCADA. Nie ma żadnego prostego sposobu na połączenie się z programu działającego pod Linuksem (takiego jak serwer SZARP) do programu pod Windows korzystającego z DDE. DDE (oraz NetDDE) bazuje na własnościowych protokołach Microsoftu i nie istnieją żadne niezależne implementacje – jeśli ktoś potrzebuje DDE, korzysta po prostu z API win32. W celu umożliwienia wymiany danych z programami SCADA pracującymi pod Windows (tak naprawdę – właśnie z aplikacją InTouch), SZARP używał prostego skryptu w Pythonie – ddespy – który zamieniał zapytania XML-RPC przesyłane z komputera z Linuksem na zapytania DDE do aplikacji Windows. Początkowo skrypt obsługiwał tylko jeden szczególny przypadek aplikacji – dostępny do InToucha sterownik protokołu Modbus (MBENET). Ostatnie zmiany (w tym zmiana nazwy – z ddespy na ddeproxy) umożliwiają proste pobranie do SZARP dowolnych danych z systemu InTouch lub innej aplikacji Windows wykorzystującej DDE. Wystarczy znać nazwy 'itemów’ (w terminologii DDE), które odpowiadają nazwom 'tagów’ (w terminologii InTouch). Dzięki pythonowej filozofii 'dołączonych baterii’ (batteries included) i rozszerzeniom Win32, stworzenie serwera XML-RPC, który jednocześnie jest klientem DDE, wymaga napisania w Pythonie dosłownie kilku linijek kodu. Po uruchomieniu skrypt działa w tle. Dzięki narzędziu py2exe (http://www.py2exe.org) nie jest konieczna oddzielna instalacja pod Windows Pythona i rozszerzeń Win32 – całość można zapakować w zgrabny zbiór jednego pliku EXE i kilku DLL. Jako że ddeproxy używa standardowego protokołu XML-RPC, może być wykorzystane niezależnie od SZARP – do przesyłania danych z dowolnej aplikacji używającej DDE (np. Excela) do dowolnego klienta XML-RPC.
Instalacja ddeproxy nie obniża w znaczący sposób bezpieczeństwa Windows – w każdym razie dużo mniej niż np. uruchomienie usługi NetDDE. Obsługiwane są tylko komunikaty DDE 'Request’ (umożliwiające wyłącznie odczyt), a do komunikacji wykorzystywany jest pojedynczy, konfigurowalny port TCP, dostęp do którego można łatwo ograniczyć za pomocą firewalla. Prostota wykorzystania ddeproxy daje dobrą okazję aby wypróbować SZARP obok używanego obecnie innego systemu SCADA dla Windows – wystarczy jedynie stary komputer PC na którym zainstalujemy Debiana i ściągniemy pakiety SZARP, a możemy korzystać z zupełnie nowych możliwości analizy danych historycznych. Pozostałe styczniowe zmiany w SZARP dotyczą między innymi procesu uruchamiania przez SZARP swoich sterowników (demonów linii). Dotychczas było to robione za pośrednictwem powłoki (sh -c), co prowadziło do problemów z propagacją sygnałów oraz dość nieoczywistych zachowań w przypadku użycia w poleceniu uruchamiającym sterownik specjalnych konstrukcji powłoki (np. przekierowania wyjścia do innego procesu). Inne wymienione w pliku NEWS.pl zmiany, to początek zapewne dość długiej drogi do obsługi przez bazę danych próbek o lepszej niż obecnie rozdzielczości – np. 10 sekund zamiast obecnych 10 minut, co pozwoliłoby też rozszerzyć zakres zastosowań systemu. W tej chwili planujemy, że te dokładniejszy dane dostępne byłyby jedynie w ramach lokalnej instalacji (bez propagacji przez Internet), ale wiele szczegółów technicznych może się jeszcze zmienić.