[NEW!] Latest rules and evaluation procedure: link.

Online Web interface: http://fitipc190.tugraz.at:3000

We are happy to announce that we have received 13 submissions from 13 different countries (31% of the submissions were from outside Europe) and that the competition will take place during EWSN 2016!

Overall, 15% of the submissions are fully authored by industry people, while the remaining submissions come from academia and research institutions from all over the world.

Additional details about the competition logistics are summarized below, along with a short FAQ section.

Due to the nature of the solutions submitted, a single category has been defined. The top three teams will be awarded the following prizes:

• 1^st place: 750€
• 2^nd place: 500€
• 3^rd place: 250€

The results of the competition will be announced in a plenary dependability session during the main conference on Tuesday morning, February 16^th 2015. The top three teams will be awarded a cash prize and will also be given the opportunity to give a 10 min talk about their solution during this session.

The preliminary program of the EWSN 2016 dependability competition can be found here. The competition will take place on Monday, 15.02.2016 (all day), and the winners will be announced in a dedicated session of the main conference track on Tuesday, 16.02.2016 (morning). Each team will have the chance to test their setup and prepare on Sunday, 14.02.2016 (all day) and on Saturday, 13.02.2016 (afternoon). 

The final advanced program is the following:

The solutions of the contestants will be evaluated according to three criteria:

• Reliability of transmissions: number of changes in the lighting condition that were missed (i.e., that were not correctly reported to the sink);
• End-to-end latency: time necessary to communicate a change in the lighting condition to the sink node;
• Energy-efficiency: overall power consumed by the nodes in the network (measured in hardware).

For each criterion, a separate ranking of the solutions will be derived. Points will be assigned to the contestants based on their rank (13 points to the team ranked first, 12 points to the team ranked second, etc.), and the final classification will be derived by summing the points obtained in each ranking. The team with the highest score wins, i.e., the team with the best rankings across all three metrics.

In the case of a tie, the organizers will consider the relative differences in each metric, and in case there are no significant differences, the most energy-efficient solution will be selected.

The competition will take place indoors, in office and laboratory rooms at Graz University of Technology. The exact location and number of sensor nodes will not be disclosed beforehand, in order to avoid solutions that are specifically engineered in advance for the evaluation scenario. However, all contestants are provided with an upper bound on the number of nodes and their density, so that they can correctly dimension their solution. In particular, contestants can expect not more than 15 wireless sensor nodes that will be deployed over an area of approximately 150 m2.

A detailed file with all logistic information can be found here.

Is there going to be only one sensing node generating “changes in the lighting condition” events (light on / light off)?

Yes, there is going to be only one sensing node that generates events to be captured and communicated to the sink. No data needs to be collected from the other nodes that will act as forwarders only.

How often will the “changes in the lighting condition” be scheduled?

Changes in the lighting condition will follow a predefined pattern that will not be disclosed beforehand. The light source will, however, not change in sub-second timescales. Contestants can safely assume that there will be at least 2 seconds in between each change in the lighting condition.

Can the “changes in the lighting condition” already occur at time 0?

No, there will be some slack time from boot time in order to allow contestants to carry out node and topology discovery. The duration of this slack time will be approximately 20 seconds.

How is interference practically generated?

Interference will be generated using JamLab [1]. Multiple wireless sensor nodes will act as interferers, each on a specific IEEE 802.15.4 channel. The reproduced interference will resemble the interference patterns of common appliances (e.g., Wi-Fi devices and microwave ovens). Contestants cannot assume that some IEEE 802.15.4 channel will be constantly interference-free. Please note that JamLab records and emulates interference patterns from real-world devices, but does not back-off and stop interfering  in case one of the sensor nodes is transmitting strong messages nearby (as, for example, Wi-Fi access points do [2]). An example of a Contiki application running JamLab emulating a Wi-Fi video streaming can be found here.

[1] http://soda.swedish-ict.se/4110/1/boano11JamLab.pdf

[2] http://research.microsoft.com/pubs/138258/sensys10-final172.pdf

Will JamLab be already active since time 0?

Yes, JamLab will be active since the beginning of the experiment, i.e., also during node and topology discovery (if any). However, interference may vary over time, and the one recorded at time 0 is not necessarily representative of the one that may occur later.

Can additional interference be present in the area?

During the competition days, the Wi-Fi access points of the building should be disabled and no particular sources of interference are expected. We will nevertheless monitor the radio interference in the surroundings and, in case some particular disturbance is detected, the experiment will be repeated.

How is the energy consumption of the nodes measured? Is it going to be measured on all nodes?

Power consumption of nodes will be measured using additional hardware. In principle, the measurement will be carried out on all nodes and will start at boot time, i.e., node and topology discovery (if any) will account for the total power consumption of the sensor nodes.

Can the submission be kept confidential?

Yes, there is the possibility to keep the submission confidential (no publication in the ACM digital library, and no disclosure of ranking after the competition). Each contestant will be specifically asked about this at a later stage.

Software upload: is a single version of the firmware necessary?

Contestants will be asked to provide a single firmware for all nodes (source, sink, relays).

Is the reading of the sensor given or should it be implemented by each contestant?

As the sampling strategy may affect all three metrics (reliability, latency, and energy-efficiency), each team should come up with its own strategy. In order to fine-tune the operation of the light sensor (e.g., select a correct threshold), a dedicated setup and preparation session will be available before the competition. The sensor nodes used are Maxfor / Advanticsys MTM-5000 sensor nodes, and the light sensor properly works with common software (e.g., using Contiki’s sensor reading on the sky platform).

How does a node knows its identity (source, sink, relay)?

The ID of each node can be read from the on-board external flash. In this case, the ID is an unsigned short (16 bits) number, and an example program in Contiki on how to read it from flash is available here. Alternatively, also the 48-bit unique ID chip (DS2411) can be used.

How does the sink node signal it received a packet to the outside world?

The sink will turn one of the GPIO pins of the expansion header high (light on) or low (light off) according to received packets. The exact pin specifications will be communicated on a later stage.

Is there any limitation in the number of packets sent? Is repeated signaling for the same packet allowed?

The sink only reproduces on the GPIO pins the light pattern of the source node. There is no constraint on the number of packets sent.

Will the contestants have USB access to the nodes in the testbed during the competition? 

For debugging purposes, it will be possible for the contestants to access the nodes via USB during the preparation phase. During the competition itself, however, the FTDI interface of the nodes will be disabled.