PIRRO
- • Team A
- • Team B
- • Team C
Final Assignment

Sws
---+!!SWS 2009 &#8212; Final Assignment

|Your report may be in Dutch or English. Acceptable formats are: plain text (ASCII), pdf, and Word.|
|E-mail it, at the latest on Sunday 15 November 2009, to =[[mailto:lambert@cs.uu.nl][lambert@cs.uu.nl]]=.|

---++Part I: Sensor Network for Intruder Detection (SNIDE)

---+++Introduction
The company Sensensen-Cibility (!S3CY) produces sensor networks. A sensor network consists of a collection of processors, known as _nodes_, that are equipped with sensors and that can communicate with each other by exchanging messages.

For the market of asset protection and intruder detection, !S3CY is designing a new low-energy-consumption network architecture, dubbed SNIDE. As shown in the figure below, a deployed SNIDE network consists of a number of nodes, placed strategically along the perimeter of the asset to be protected, arranged in a cycle. Each node can communicate directly with its two immediate neighbour nodes. For sending messages to farther nodes (that is, two or more hops away), a store-and-forward message transfer method is needed.

    <img src="%ATTACHURLPATH%/S3Cy.png" alt="S3Cy.png" width='345' height='219' />

SNIDE nodes can be in a low-energy mode, the _sleep_ state, and in normal mode, the _wake_ state. While asleep, a node is inactive and cannot collect sensor input or send or store messages. Before a node goes to sleep, it can set a timer; when the timer goes off (like an alarm clock), the node wakes up. A node that is awake can also send a WUP (wakeup) message to a neighbour node, which will cause it to wake up if asleep.

Nodes can read the sensor register, which indicates the current amount of motion in the field of view. The motion-detection sensors are inherently noisy, and so a fairly high threshold level must be set to avoid any bird or stray cat, in conjunction with an accidental noise spike, to initiate an alarm phase. On the other hand, the sensors are not highly sensitive, and the threshold level should not be too high so that a serious intrusion may go undetected. But in case of a real intrusion, several nodes should get suspicious sensor readings. The solution is to have sensors exchange data and to let the network make a collective decision that alarm initiation is warranted.

All nodes are identical, in the sense that they have the same architecture, features and capabilities. Although they run at the same clock speed, they operate asynchronously.

---+++Sensing
A node can perform the action MLRead, which causes the current motion level, as measured by the sensor, to be recorded in the motion-level register _MLR_. Register _MLR_ is a temporal variable that can be read by the program running on the node. Its value changes over time; it does not change spontaneously, however, but only as the effect  of the MLRead command. The value is an unsigned byte, range 0 to 255.

---+++The clock and timer
Each node has an onboard clock that sends a TIC event to the processor every millisecond.

A node can perform the action CTRead, which causes the current time, as kept by the clock, to be recorded in the clock-time register _CTR_. The clock keeps the time with a granularity of 1 millisecond, and counts modulo 65536, so that time 65535 is followed by time 0.

A node can perform the action Sleep(_t_), which causes the node to go into sleep state, while setting the timer register to _t_. The timer register _TMR_ automatically decrements by 1 every millisecond and the timer sends a WUP event when _TMR_ reaches 0, so that the node will be woken up _t_ milliseconds in the future. The parameter _t_ must be in the range 0 to 65535.

---+++Communication, messages and events
Each node has four communication ports: two for sending messages and two for receiving messages. Sending a message is an action initiated by the sending node. Receiving a message is an in-event. The ports are linked up, forming communication channels, as indicated in the figure below. Additionally, there is an "internal" port CP (not shown) related to the clock.

    <img src="%ATTACHURLPATH%/Comm.png" alt="Comm.png" width='475' height='111' />

Messages sent from port S0 on a node will be received on port R1 of one neighbour; messages sent from port S1 will be received on port R0 of the other neighbour. However, if messages are sent simultaneously to the same node by both of its neighbours, neither one is received. A node that is currently sending also cannot receive messages, temporarily, so messages can get lost. Also, while a node is asleep it cannot receive any other type of message than the WUP message.

There are three types of messages/events:
   * TWT _string_. The message has a parameter, which is a short string (max. 140 characters); it can be sent and be received between two nodes.
   * WUP. This message can be sent and be received between two nodes, and can also be sent to a node by it's onboard alarm clock. If received by a node in the sleep state (on port CP), it will then go into wake state.
   * TIC. This is an in-event only, sent every millisecond by the node's onboard clock &#8212; but only while the node is in wake state.

A node can perform the action Send(_portnr_, _msg_), where _portnr_ is either 0 or 1 (corresponding to ports S0 and S1, respectively), and _msg_ is either a TWT message or a WUP message.

---+++Your task
*Give a precise specification of a single SNIDE node.* This specification should serve as input to a team of programmers for producing a SNIDE node simulator, which in turn will be used in simulations of SNIDE networks to test various intrusion detection methods for critical parameters such as robustness, avoidance of false alarms, and energy consumption. Therefore it must be *precise* and *detailed*, unambiguously answering all questions they may have.

Before the spec is given to the programming team, it will be scrutinized by the engineers who have designed the SNIDE node, to make sure it reflects the actual hardware. If you get some detail wrong because the natural language description is necessarily imprecise, they will catch it if your spec is sufficiently precise. If the specification of some detail is vague, the risk exists that the engineers may not notice this and read the text with one interpretation, while the programming team may read it with a different interpretation, leading to serious problems and high costs later on. So keep in mind: the risk of getting a detail wrong is low, while the risk of leaving it vague is high.

---++Part II:  Essay

Write a brief essay in which you summarize, in your own words, what you learned in this course.  Please don't use more than one page.

_Note. This part will not count in determining your grade._
Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	Comm.png	manage	7.6 K	26 Oct 2009 - 10:14	LambertMeertens
png	S3Cy.png	manage	6.2 K	25 Oct 2009 - 23:55	LambertMeertens