-
Notifications
You must be signed in to change notification settings - Fork 11
Release Notes 0.8
The 0.8 release of Testbed Runtime implements some long-awaited features and some requirements of the SmartSantander project. Please see the full list of issues closed here. For a description of the main changes, see below.
Important: the automatic configuration reloading feature introduces changes to the configuration file format that requires testbed providers to update their configuration files. Please check the documentation below!
Testbed Runtime's iWSN is now able to reload configuration files at runtime! Originating as a SmartSantander requirement this feature may also come in handy for others. The application core now observes the conf/tr.iwsn-testbed.xml
configuration file for changes and acts accordingly, always trying only to start/stop/reload/reconfigure the components that actually changed.
Important: through the introduction of this feature it was necessary to change the semantics of the iWSN configuration file. In the 0.7.2 and earlier versions multiple <application>
tags were allowed to have the same name
attribute. Starting with 0.8 this name
attribute must be unique in the configuration of one host!
So, if you had e.g. two sensor node devices attached and an according configuration like this:
<nodes id="gatewayXX.yourtestbeddomain.org">
...
<applications>
...
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
<ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:wisebed:uzl1:0x221e</urn>
<type>telosb</type>
<usbchipid>XBUNEJDX</usbchipid>
</ns4:wsnDevice>
</application>
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
<ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:wisebed:uzl1:0x211c</urn>
<type>isense</type>
</ns4:wsnDevice>
</application>
...
</applications>
...
</nodes>
You must now make sure to make the name
attribute of the <application>
tags unique, e.g. by attaching the URN of the node for which the <application>
tag is defined:
<nodes id="gatewayXX.yourtestbeddomain.org">
...
<applications>
...
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp-urn:wisebed:uzl1:0x221e">
<ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:wisebed:uzl1:0x221e</urn>
<type>telosb</type>
<usbchipid>XBUNEJDX</usbchipid>
</ns4:wsnDevice>
</application>
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp-urn:wisebed:uzl1:0x211c">
<ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:wisebed:uzl1:0x211c</urn>
<type>isense48</type>
</ns4:wsnDevice>
</application>
...
</applications>
...
</nodes>
The rationale behind this is that Testbed Runtime must be able to tell which part of the configuration file actually changed so that only this part must be reloaded.
Testbed Runtime is now able to detect sensor node devices being attached and detached and to reconnect to the nodes at runtime. For this feature to work the iWSN configuration file (conf/tr.iwsn-testbed.xml
in the assembly) must be updated as follows: Assume you have a gateway host with both an iSense as well as a Telos B device attached. Then the relevant part of the configuration file in 0.7.2 looked as follows:
<nodes id="gatewayXX.yourtestbeddomain.org">
...
<applications>
...
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
<ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:wisebed:uzl1:0x221e</urn>
<type>telosb</type>
<usbchipid>XBUNEJDX</usbchipid>
</ns4:wsnDevice>
</application>
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
<ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:wisebed:uzl1:0x211c</urn>
<type>isense</type>
</ns4:wsnDevice>
</application>
...
</applications>
...
</nodes>
Now, for the 0.8 version to support automatic reconnection to devices you must configure another <application>
tag into the configuration file:
<nodes id="gatewayXX.yourtestbeddomain.org">
...
<applications>
...
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsndeviceobserver.WSNDeviceObserverFactory" name="WSNDeviceObserver">
<ns5:wsnDeviceObserver>
<mapping mac="0x221e" usbchipid="XBUNEJDX"/>
...
</ns5:wsnDeviceObserver>
</application>
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp-urn:wisebed:uzl1:0x221e">
<ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:wisebed:uzl1:0x221e</urn>
<type>telosb</type>
</ns4:wsnDevice>
</application>
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp-urn:wisebed:uzl1:0x211c">
<ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:wisebed:uzl1:0x211c</urn>
<type>isense48</type>
</ns4:wsnDevice>
</application>
...
</applications>
...
</nodes>
The WSNDeviceObserver
application observes the serial ports of the gateway host and throws events of devices found on which the WSNDeviceApp
listens. In order for the WSNDeviceObserver
to know the MAC address of a newly attached device it either reads it from the device if supported or it resolves it by looking up the USB chip ID in the <mapping>
-tags (Telos B).
In the old versions of Testbed Runtime a DLESTXETX-framing decoder was used per default. This framing decoder makes sense with sensor node device operating systems which delimit packets using DLE STX ... DLE ETX
bytes. However, other operating systems than iSense OS use different framing algorithms. Therefore, in version before 0.8 testbed client applications had to call the setChannelPipeline() method to configure the de-framing algorithm according to the operating system used in the experiment or to remove data stream preprocessing in the backend altogether.
Testbed Runtime 0.8 now per default doesn't do any preprocessing or de-framing at all. However, it now allows you to set a default channel pipeline for each individual node in iWSNs configuration file (conf/tr.iwsn-testbed.xml
in the assembly) if you think it is necessary because, e.g. your iSense sensor node devices are running iSense OS 99% of the time. You can do this by setting a <defaultChannelPipeline>
-tag which can either take the name of a configuration file that follows the configuration file format defined by the netty-handlerstack project (see dlestxetx-framing.xml, empty.xml and isense-otap.xml for examples) or by placing the XML contained in these config files directly into the tag:
<application name="WSNDeviceApp-urn:local:0xb2a6" factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory">
<wsn:wsnDevice xmlns:wsn="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:local:0xb2a6</urn>
<type>isense48</type>
<defaultChannelPipeline>
<configurationXml>
<itm-netty-handlerstack>
<handler name="dlestxetx-framing" factory="dlestxetx-framing" />
</itm-netty-handlerstack>
</configurationXml>
</defaultChannelPipeline>
</wsn:wsnDevice>
</application>
<application name="WSNDeviceApp-urn:local:0xb2a7" factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory">
<wsn:wsnDevice xmlns:wsn="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
<urn>urn:local:0xb2a7</urn>
<type>isense48</type>
<defaultChannelPipeline>
<configurationFile>empty-channelpipeline.xml</configurationFile>
</defaultChannelPipeline>
</wsn:wsnDevice>
</application>
Although 0.7.2 already supported the iSense Core Module 3 there was no distinction between the old iSense Core Module and the new. In Testbed Runtime 0.8 the Strings isense39
and isense48
can be used to distinguish between them, both in the configuration files and the WiseML file.
We recently updated the Lübeck testbed by replacing some of the iSense nodes with JN5139R1 CPUs with the new iSense nodes featuring the Jennic 5148 CPU. Please see the testbed site for details.