There were over 30 commits into SZARP repository in January. In previous month large parts of draw3 program code was rewritten in order to make code simpler to manage, which introduced quite a few bugs, so we are holding ‘stable’ release for a moment, to make sure all of them are removed. The major functional change was improving communication with DDE-enabled Windows applications.
DDE (Dynamic Data Exchange) is an ancient message-queue-like protocol introduced by Microsoft in Windows 2.0 in 1987 (!). It enables applications to exchange any kind of data, for example to automatically update some value in word processor when it is changed in Excel. Wonderware, producer of popular InTouch SCADA software, introduced DDE into world of automation. It even created network-enabled version of DDE – NetDDE, which was licensed by Microsoft in some versions of Windows. It was finally removed from Windows for security reasons in Windows XP service pack 2 and Windows Vista. But old, ordinal DDE is currently available even in new shiny Windows 7 (BTW – szarp4win works under Windows 7) and you can always install NetDDE from Wonderware. DDE is insecure by nature, there’s no way to identify origin of request. There are newer technologies like COM, OLE and OPC that intended to replace DDE, but it is still popular in some applications, including exchanging data with SCADA systems.
There is no easy way to connect from Linux application (like SZARP Scada) to Windows application using DDE. DDE (and NetDDE) is based on proprietary Microsoft technologies, there aren’t any independent implementations – Windows applications just use win32 API. For the need of exchanging data with Windows-based SCADA (InTouch, actually) SZARP was using small Python script called ddespy which transferred XML-RPC request from Linux box (SZARP ddedmn driver) to DDE request on Windows box. Initialy it was working only for one special case – InTouch Modbus driver (MBENET). Recent changes (including script name changed from ddespy to ddeproxy) allow SZARP to easily fetch all data from InTouch or other DDE-enabled application – you just need to know ‘items’ names (in DDE nomenclature), which are really ‘tagnames’ (in InTouch nomenclature).
Thanks to Python ‘batteries included’ philosophy and Python Win32 extensions writing XML-RPC server working as DDE client is easy and requires just a few lines of code. When started, it just silently run in background. With py2exe (http://www.py2exe.org) tool you can easily deploy script as a single exe plus a bunch of dll files, without the need of independent Python + Win32 extensions installation. Because ddeproxy uses standard XML-RPC protocol, you can also use it independent of SZARP – to fetch data from virtually any DDE Windows application (like Excel) to any XML-RPC client.
Installing ddeproxy does not really exposes security of your Windows box – at least far less then NetDDE service. It serves only ‘Request’ DDE messages (it means read-only access) and runs on a single, configurable TCP port, that can be easily filtered on firewall.
Easy ddeproxy deployment is a great way to give SZARP a try if you are using some Windows-based SCADA – you just need to get an old PC box, install Debian on it, fetch SZARP packages and enjoy a new level of historical data analyses availability.
Other January changes include refining of drivers launching process. Until now we were using shell (sh -c) to start drivers (line daemons), which lead to some problems with signal distributing and to rather unexpected results if special shell constructions (like pipeline) where used in drivers command lines.
Other change mentioned in NEWS file is a start of long process toward handling of shorter time intervals in historical data base – for example 10 seconds instead of current 10 minutes, which can also make SZARP suitable for more applications. At this moment we plan to narrow down availability of these data to local installation (without distributed propagation), but almost every technical detail can still change. | There were over 30 commits into SZARP repository in January. In previous month large parts of draw3 program code was rewritten in order to make code simpler to manage, which introduced quite a few bugs, so we are holding ‘stable’ release for a moment, to make sure all of them are removed. The major functional change was improving communication with DDE-enabled Windows applications.