[[PageOutline(1-3,Table of Contents,inline)]] = Introduction = == Architectural Overview == [[Image(arhi.png, center)]] The Check architecture consists of the following entities: * '''WSN Island''': Sensor nodes organize into a multi-hop wireless network with tree topology in which some nodes act as routers for the end node leaves. * '''Edge Router''': An embedded network coordinator. Acts as a sink to the sensor node data and routes the island network traffic to an IPv6 network. * '''Gateway''': Binary Web Services (COAP) running on a machine in the same network with the Edge Router. * '''Check Services''': Self-healing, Task Scheduling and Monitoring Framework. == Hardware-Software Architecture == An entire Check WSN architectural example is given in the diagram below. The sensor network itself is built around [http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=4291 RZRAVEN] and Sparrow nodes that form a heterogeneous multi-hop network using a modified version of Atmel's [http://sensei-dev1.grid.pub.ro:8184/rd RUM] protocol over which we ported the Binary Web Services application and our own task scheduling and monitoring apps. The edge router is an embedded ARM7 [http://www.atmel.com/dyn/resources/prod_documents/doc6195.pdf board] running a modified version of the [http://www.utasker.com/ uTasker OS]. An IPv6 layer added over the existing OS allows the SAM7X platform to act as an IPv6 Edge Router in addition to an 802.15.4 PAN Coordinator. The PAN Coordinator performs the classical functions defined in section 5.3 of the IEEE 802.15.4-2006 specification. It will start and maintain a non-beaconing network. The edge router functionality will route IPv6 network traffic to the appropriate end and router nodes based on their specific IPv6 addresses. SAM7X provides multiple interfaces for users to interact with the 802.15.4 wireless network. Among these are RS232, USB, telnet and simple direct web interface. [[Image(sensei+rum.png, center)]] The Gateway service acts as a mediator between the network and the Check framework service suite. == Hardware Requirements== In order to build a working WSN Island, the following devices and tools are needed: * Ubuntu or Windows PC. * [http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=4291 RZRAVEN] or Sparrow nodes * [http://www.atmel.com/dyn/resources/prod_documents/doc6195.pdf AT91SAM7X-EK] development board with an attached AT86RF2xx family transceiver ([http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3945 RZ502] kit + [http://www.dresden-elektronik.de/shop/prod90.html?language=en REB] extension board recommended) * [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3808 AVRISP], or any other compatible programmer for the sensor nodes. * [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3892 AT91SAM-ICE], or compatible JTAG emulator for the edge router. == Software Requirements== * avr-gcc compiler or [http://winavr.sourceforge.net/ WinAVR] (for Windows) * avr-dude programmer or [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVRStudio] (Windows) * [http://www.segger.com/cms/jlink-software.html Jlink] programmer for the edge router. * [https://svn-batch.grid.pub.ro/svn/Sensei-WP5/node-rum-coap/ source code] for the sensor nodes * [https://svn-batch.grid.pub.ro/svn/Sensei-WP5/gateway/ Gateway] code Optional (for the edge router): * [http://www.utasker.com/ uTasker] source code * [http://www.codesourcery.com/sgpp/lite/arm ARM g++] compiler ==Installation== Sensor nodes: * Edit the PLATFORM option in [https://svn-batch.grid.pub.ro/svn/Sensei-WP5/node-rum-coap/rum_src/Makefile this] Makefile to match your hardware (RAVEN for RZRAVEN, leave undefined for Sparrow) * Compile the code using the above Makefile or use one of the precompiled binaries can be found in [https://svn-batch.grid.pub.ro/svn/Sensei-WP5/node-rum-coap/bin/AVR/ this] folder. * Program the binary into the flash memory of the node using avr-dude or AvrStudio. Edge Router: * Program the edge router with this [https://svn-batch.grid.pub.ro/svn/Sensei-WP5/node-rum-coap/bin/SAM7X/SAM7X_2400mhz_ipv6_coord.bin binary] using Jlink * Telnet the router (its default IP address should be 192.168.1.125). You should gain access to the following interface: [[Image()]] = Monitoring and reprogramming= == Reprogramming - Gateway Watchdog == The SENSEI Gateway Watchdog is a monitoring and control service for the SENSEI Gateway. It allows for remote starting, stoping and updating the gateway code and can report the version string and uptime of the currently running gateway binary. === Software Requirements === Installing the Gateway Watchdog requires the following software packages: * [http://www.ubuntu.com/ Linux PC (Ubuntu)] * g++, make * [http://www.alhem.net/Sockets/ Sockets C++ library] (Also included in lib/Sockets-2.3.7; make clean; make; make install) * libxml2, libxml2-dev * libssl, libssl-dev === Project Organization === The watchdog shares its code with the gateway implementation and can be found in the [https://ncit-cluster.grid.pub.ro/trac/Sensei-WP5/browser/gateway /gateway] folder in the SVN. * [https://ncit-cluster.grid.pub.ro/trac/Sensei-WP5/browser/gateway/bin /bin] executables * [https://ncit-cluster.grid.pub.ro/trac/Sensei-WP5/browser/gateway/src /src] Gateway and Watchdog Code * [https://ncit-cluster.grid.pub.ro/trac/Sensei-WP5/browser/gateway/xml /xml] Location of resource descriptions * [https://ncit-cluster.grid.pub.ro/trac/Sensei-WP5/browser/gateway/lib /lib] Sockets++ library * [https://ncit-cluster.grid.pub.ro/trac/Sensei-WP5/browser/gateway/config /config] Configuration files (unused) * [https://ncit-cluster.grid.pub.ro/trac/Sensei-WP5/browser/gateway/log /log] Log files (unused) === Compiling the Gateway Watchdog === Some packages are required to be installed prior to the compilation of the Gateway Watchdog. Please install the following packages from the Ubuntu repository if you did not do already so. {{{ $ sudo apt-get install gcc g++ libssl-dev libxml2-dev }}} Sockets library also needs to be installed: {{{ $ cd ./lib/Sockets-2.3.7 $ make clean $ make $ sudo make install }}} The top-level Makefile will build everything with the following, which places the executables in ./bin. {{{ make }}} To clean everything do {{{ make clean }}} === Running the Gateway Watchdog === The watchdog must be run from the root of the project {{{ ./bin/watchdog }}} Available command line options are: -p HTTPD port (default: 9000) [[BR]] -s HTTPD hostname for inserting in resource desciption (default: localhost) [[BR]] -d domain name inserted in resource description (default: example.com) [[BR]] -w WSAN island name inserted in resource description (default: Example) [[BR]] -f folder where the gateway binary can be found (default: ./) [[BR]] -c gateway binary filename (default: sensei-gateway) [[BR]] -cert ssl certificate filename, also enables https operation [[BR]] -pass ssl certificate passphrase, necessary if the certificate file is encrypted [[BR]] The SENSEI Gateway Watchdog server runs by default on port 9000. It exposes the following URIs: * /start - a POST request starts the gateway if not already started * /stop - a POST request stops the gateway * /update - a POST request with a form that has a 'file' field named 'code' updates the gateway binary, a 'text' field named 'version' can also be sent as the version string for the newly uploaded binary, otherwise version string will be taken from the uploaded file * /uptime - a GET request returns the uptime of the gateway in seconds or -1 if the gateway is not started * /version - a GET request returns the gateway version string, if one is available. For the /start, /stop and /uptime urls GET requests are also accepted. They return an HTML page that allows easy access to the operations from a browser. === Test demo === The Gateway Watchdog provides monitoring and control of the SENSEI Gateway. To run a demo, please start the Watchdog service by giving the following commands in a console: {{{ $ make $ ./bin/watchdog -f bin/ -c sensei-gateway -d pub.ro -w test }}} This will start the Gateway Watchdog which runs an http server at '''localhost:9000'''. You will be able to see the registered gateway watchdog URIs by querying the Resource Directory at http://sensei-dev1.grid.pub.ro:8184/rd. A possible response from the Resource directory is shown below. [[Image(rd.png, center)]] The watchdog service will now accept requests at the following URIs: * Start Gateway http://localhost:9000/start * Stop Gateway http://localhost:9000/stop * Update Gateway code http://localhost:9000/update * Gateway uptime http://localhost:9000/uptime * Gateway version http://localhost:9000/version As an example, by pointing your browser to the [http://localhost:9000/start Start Gateway] URI you should see following response [[Image(start.png, center)]] Clicking the Start button will start the gateway if it is not already started. You can check that the gateway is running by clicking the following link http://localhost:8000 By pointing your browser to the [http://localhost:9000/stop Stop Gateway] URI you should see the following response [[Image(stop.png, center)]] Clicking the Stop button will stop the gateway. By pointing your browser to the [http://localhost:9000/update Update Gateway code] URI you will be able to upload a new binary to the gateway and, optionally, specify a version string for this binary, as shown bellow. [[Image(update2.png, center)]] Note that to run the new gateway code you have to stop and then start the gateway. = Scheduling = The Scheduling algorithm is presented as a stand-alone application that gathers information about the network from a Resource Directory (types of nodes, topology). Prerequisite: Prior to executing the scheduler the sub-tasks of the application have to be already programmed on the nodes, as stopped tasks. {{{ ./check-schedule }}} Arguments: * RD is the URI of the Resource Directory * tdag is a Task Dependency Acyclic Graph. It contains a graph of data dependencies between tasks and their associated bandwidth. The format is a textfile containing * t, number of tasks * d, number of dependencies * a tuple (x,y,z) for each edge in the dependency graph on one line, with x,y being incident tasks and z being the bandwidth. * tskmap is a task mapping file, associating each task in Task Dependency Acyclic Graph to the names of the tasks that have to be run on the network. * tuples (x,s) are present on every line, x being the task index in the tdag file and s being the name of the task associated. Tasks are started based on their names Example of a tdag file: The application in question has one sensing task (0) and two different event detections (tasks 1 and 3) and a sink task to notify in the case of an event (task 2) {{{ 4 4 0 1 10 1 2 1 0 3 20 2 3 1 }}} The associated tskmap will be: {{{ 0 sense 1 ed1 3 ed2 2 present }}} One run of the application is enough to calculate the best scheduling of the application over the network, the application will directly access the nodes and start the required tasks, provided the tasks are already present on the sensor nodes. = Self-healing = The Self-healing service in the Check framework overlays the self-healing capabilities provided by the stack running on the nodes. The latter continously ensures a correct topology of the island, while providing, through Sensei interfaces, topology information and individual node attributes. In case a node fails to respond and a timeout message is received, then the Self-healing service chooses another node with the requested capability and automatically redirects the request to it.