TinyOS and SecRose

5.1.1 Description of TinyOS

The TinyOS Operating System

TinyOS is a miniature operating system designed for use in sensor networks and other embedded systems written in the nesC programming language [31, 53, 64]. TinyOS is a flexible, application-specific operating system, which follows a component-based, event- driven model.

The system is built from a set of reusable components that are assembled into an application- specific executable, capable of running in a sensor board. Instead of multithreading, TinyOS provides an event-driven concurrency model, which utilises components that interface with each other.

Component model of TinyOS

Every TinyOS program is a graph of components, which interact together using three computational abstractions: commands, events and tasks. The programming model of nesC provides component creation and access in the form of services, which are called interfaces. An application connects components using a wiring specification, which defines which

components will be used by the application. This mechanism excludes the components that are not required from the executable.

Commands are requests for a component to perform some service. When the operation concludes, an event informs the commanding component of its success or failure. Commands

and events might also post a task to be executed at a convenient time by the operating system‟s scheduler. Both hardware and software resources are abstracted by TinyOS as

components. The component system manages the underlying software and hardware interfacing at low level while the application is only waiting for an event to inform it that the

command has finished.

Each component defines a number of interfaces that it provides or uses. The interfaces specify how the component may interact with other components. Interfaces contain both commands

117 and events. A command is a function implemented by an interface provider while an event is a function implemented by its user

Components can be modules or configurations. Modules contain the actual code of the

component while configurations connect this component’s code together with other

components. The connection process is called wiring. Via this process, a configuration might

wire a number of components, which in turn may be configurations that wire more

components resulting to the creation of a tree of components. The tree is then called a

supercomponent and in that case, the module of the component in the base of the tree is controlling the tree. Essentially, applications are supercomponents.

5.1.2 Operation of TinyOS

Programming and execution model of TinyOS

TinyOS itself and the applications that run on it are written in nesC; an event-driven dialect of C. NesC is a dialect of C, it is no different from C other than in the way that functions and libraries are defined and linked. As opposed to C, there is no linking in nesC. The linking process is replaced by the wiring of components.

TinyOS provides a scheduler, or execution model, which coordinates simultaneous commands

and events that run between the components. The scheduler also manages energy consumption, puts hardware components into sleep mode and other housekeeping tasks. The scheduler allows for real-time task execution and for low priority execution.

NesC and the scheduler are designed to solve a number of engineering issues regarding event- driven execution. The system for example can detect data races statically. The execution model consists of run-to-completion tasks for computation and asynchronous interrupt handlers signalled by the hardware. The scheduler might execute tasks in any order but it must obey the run-to-completion requirement.

Simulators

Due to the nature of wireless sensor networks, development of complex applications might be a difficult process requiring expensive hardware [60-61]. A number of development tools and

118 methodologies have been proposed to assist the process and minimise the development constraints.

The most important are the simulation tools. They consist of software that attempts to represent the behaviour of the sensor hardware on a personal computer. They create instances of virtual hardware and deploy them on a virtual network. The development of SecRose used the TOSSIM [62] and Avrora [63] simulators and the avr-gcc compiler [133] and the associated debugging modes and tools.

TOSSIM [62] is the pc simulator that comes with TinyOS as a tool for development and testing using a desktop computer. It works by abstracting the hardware-specific functions, e.g. the memory, into C functions with similar input and output. TOSSIM is able to produce a pc executable, which simulates the WSN when run, allowing the sensor network applications to be run as if they were normal executables for the pc architecture.

Avrora [63] uses a different, slower but highly accurate approach to simulate sensor networks. Its authors describe it as an instruction-level sensor network simulator, which runs the actual microcontroller programs in a simulated environment. Avrora implements an event queue [134] to coordinate events. This preserves the accuracy and correctness of the simulator. In addition, it utilises a radio synchronisation technique, which allows the nodes to communicate with precision timing.

5.1.3 Communication model and SecRose’s position

Communication facilities of TinyOS

TinyOS provides a networking architecture, implemented as a combination of communication components. These components define how packets are requested by the application, constructed by the operating system and handed to the hardware radio component for transmitting.

The communication facilities of TinyOS are much lighter and they look different from traditional communication protocols and specifications. However, it is apparent that the

119 design has been influenced by (a) the OSI model [66], (b) the TCP/IP protocols[9, 135] and (c) the 802.11 MAC protocols [67].

TinyOS uses a layering model but since it is extremely lightweight, some of the OSI definitions are missing and others are combined. One or more components are used to achieve the computational tasks involved. The following layers can be distinguished:

 Application layer, expressed by the application

 Transport layer, multiple components achieve the functionality of generating and pre- processing a packet with its headers and data. Key components are;

o AMStandard, initially generates a packet with its header and data

o MicaHighSpeedRadioM, for mica2 nodes, is responsible for sending the packet to lower layers on a byte-by-byte basis

 Network layer, also facilitated in a number of components, most importantly;

o ChannelMonC, responsible for monitoring the channel for idleness and/or transmissions

o SpiByteFifoC, is responsible for sending the packet to the hardware in a bit-by-bit stream

Note that there is no physical layer. Medium access is controlled by the transport layer and the network layer is responsible for the actual data transmission.

TinyOS packets are defined to have the following fields:

Destination Type Length Group Data CRC

2 1 1 1 0...29 2

The numbers express size in bytes. The Type field, sometimes referred to as AM, is equivalent to the TCP port field, the Group field is intended to allow clustering or other type of node grouping. The data contain the packet‟s data payload, which ranges from 0 to 29 bytes. The exact size of the payload is defined in the length field. Note the lack of a source address.

The acknowledgement packet is a simple stream of four identical bytes, which operates in the physical layer, and is sent by every node that happens to receive any packet.

120

SecRose in relation with TinyOS

SecRose updates the transportation-layer components of TinyOS and it is therefore facilitated in the MicaHighSpeedRadioM component. It also introduces and interfaces with a new nesC component, called SecRose.

The MicaHighSpeedRadioM component accepts outgoing packets from the AMStandard component and sends them to radio via the SpiByteFifoC component. Incoming packets are intercepted by ChannelMonC and are sent to MicaHighSpeedRadioM as well.

SecRose‟s implementation replaces the most significant parts of MicaHighSpeedRadioM and communicates with SecRose for additional functionality. The control component of SecRose12 is primarily implemented in MicaHighSpeedRadioM while all the other components reside in SecRoseM.

121