SEMINAR REPORT on TinyOS FOR SENSOR NETWORKS
Computer Science Clay|
Active In SP
Joined: Jan 2009
14-06-2009, 10:20 AM
JOSE MATHEW K.
Cochin University of Science and Technology
Sensor networking is an emerging technology that has a wide range of potential applications including environment monitoring, military applications, smart spaces, medical systems and robotic exploration. Sensor networks may consists of different types of sensors such as pressure, temperature, light, sound, biological signal, chemical, strain, altitude, acceleration, seismic, metal detectors, humidity etc. which makes it possible to use them in a variety of application areas. The objectives in the development of wireless sensor networks are : 1) it must be power efficient 2) it must be reliable and 3) the delays must be low. So the most important factor in the design of wireless sensor networks is the OS platform, which supports an energy efficient wireless protocol stack besides a low power micro controller and an RF transceiver having low power operating modes. TinyOS is a small open-source, energy efficient operating system developed by UC Berkeley, which supports large-scale, self-configuring sensor networks. The operating system is named TinyOS (Tiny Microthreading Operating System) because of its small size. TinyOS is specifically designed for network embedded systems. TinyOS has a programming model tailored for event-driven applications as well as a very small footprint. The core OS requires only 396 bytes of code and data memory, combined. TinyOS has several important features: a component-based architecture, a simple event-driven concurrency model, and split-phase operations. nesC (Network Embedded Systems C) is a programming language designed for networked embedded systems that represent a new design space for application developers. An example of networked embedded system is a sensor network, which consists of thousands of tiny, low power motes (sensor nodes) each of which executes concurrent, reactive programs that must operate with severe memory and power constraints. nesC applications are built by writing and assembling components. The most important feature of nesC is that it supports and reflects Tiny OSâ„¢s design. Since nesC is based on the concept of components, it directly supports Tiny OSâ„¢s event-based concurrency model. This report aims at an overview of wireless sensor networks in general. It then focuses on an OS platform viz. TinyOs and a programming language viz. nesC specially designed for such types of networks. Some of the applications of wireless sensor networks are also discussed.
As the post-PC era emerges, several new niches of computer system design are taking shape with characteristics that are quite different from traditional desktop and server regimes. One of the most interesting of these new design regimes is networked sensors. The availability of micro-sensors and low-power wireless communications have enabled the development of low-cost, low-power, multifunctional sensor nodes that are small in size and communicate with each other for performing distributed sensing tasks. These tiny sensor nodes, which consist of sensing, data processing, and communicating components, leverage the idea of sensor networks. Sensor networking is an emerging technology that has a wide range of potential applications including environment monitoring, military applications, smart spaces, medical systems and robotic exploration. Sensor networks may consists of different types of sensors such as pressure, temperature, light, sound, biological signal, chemical, strain, altitude, acceleration, seismic, metal detectors, humidity etc. which makes it possible to use them in a variety of application areas such as military applications, environmental applications, health monitoring and home applications. In any practical networks, long range wired networks may not be a fully feasible idea. The requirements like long cabling, power etc. will be difficult to handle. In such occasions, using wireless communication also will be a viable one. Hence through wireless link, base stations and other network nodes can be communicated. Most of the communication applications are wireless. Wireless sensor networks find a lot of applications in the military environment. They can be an integral part of military command, control, communications, computing, intelligence, surveillance, reconnaissance and targeting systems. Some of the applications of sensor networks are Monitoring friendly forces, equipment and ammunition; battlefield surveillance; reconnaissance of opposing forces and terrain; targeting; battle damage assessment; and nuclear, biological and chemical attack detection and reconnaissance.
The objectives in the development of a wireless sensor networks are : 1) it must be power efficient 2) it must be reliable and 3) the delays must be low. So the most important Page 8 factor in the design of wireless sensor networks is the OS platform, which supports an energy efficient wireless protocol stack besides a low power micro controller and an RF transceiver having low power operating modes. Tiny OS is a small open-source, energy efficient operating system developed by UC Berkeley, which supports large-scale, self-configuring sensor networks. The operating system is named Tiny OS (Tiny Microthreading Operating System) because of its small size. Tiny OS is specifically designed for network embedded systems. Tiny OS has a programming model tailored for event-driven applications as well as a very small footprint. The core OS requires only 396 bytes of code and data memory, combined. TinyOS has several important features: a component-based architecture, a simple event-driven concurrency model, and split-phase operations. nesC (Network Embedded Systems C) is a programming language for networked embedded systems that represent a new design space for application developers. An example of networked embedded system is a sensor network, which consists of thousands of tiny, low power motes each of which executes concurrent, reactive programs that must operate with severe memory and power constraints. nesC applications are built by writing and assembling components. A component provides and uses interfaces. These interfaces are the only point of access to the component. The most important feature of nesC is that it supports and reflects TinyOSâ„¢s design. Since nesC is based on the concept of components, it directly supports TinyOSâ„¢s event-based concurrency model. This report is organized as follows. Chapter 2 gives an introduction to sensors with a reference to the popular class of sensors nodes (or motes) developed by Berkeley University. Chapter 3 discusses about wireless sensor networks and the need for a specialized operating system for the same.
Chapter 4 gives an introduction to TinyOS, a small, open-source, energy-efficient operating system developed by University of California at Berkeley, exclusively for embedded wireless sensor network applications. Chapter 5 presents an overview of nesC (Network Embedded Systems C) programming language which works with TinyOS family of motes. Chapter 6 highlights some of the applications of wireless sensor networks with a special reference to an application pertaining to underwater acoustics. The conclusion is given in Chapter 7. 9
Advances in networking and integration have enabled small, flexible, low-cost nodes that interact with their environment through sensors, actuators and communication. Single- chip systems are now emerging that integrates a low-power CPU and memory, radio or optical communication, and substantial MEMs-based on chip sensors; these nodes are colloquially referred to as motes or smart dust. Target costs (for single-chip motes) are less than 10 cents per unit, which enables networks with potentially tens of thousands of motes. Target power consumption means that motes can last years with low-bandwidth communication, or even be battery-free when fueled by ambient power (e.g., heat from the environment). A mote is nothing more than a wireless receiver/transmitter. The mote itself does not have any sensors built-in. It should also be mentioned that the motes have super low power consumption. The consumption is significantly lower than anything currently available, including Blue tooth stuff. The mote requires a 3-volt power supply.
A sensor is a small device capable of sensing or measuring some data. The parameters which may be sensed could be sound, pressure, temperature, light, acceleration, humidity and so on. In fact, a mote is a device combing a small microprocessor, one or more sensors and a radio. In Fig. 2.1 we can see that a typical sensor node contains an embedded processor, sensor, memory module, transceiver and the power resource. One important point to note about sensor nodes is that the processor and the memory are of very limited capacity.
Wireless Sensor Nodes
Of all these, the mote developed by Berkeley University and later commercialized by a company called Crossbow has gained popularity. This particular mote is called MICA mote or sometimes it is also referred to as Berkeley mote.
2.3.1 MICA Mote
The hardware MICA2 Mote, is a third generation mote module used for enabling low- power, wireless, sensor networks. The MICA2 Mote features several new improvements over the original MICA Mote. The MICA Mote hardware was developed by UC Berkeley to be extremely power-efficient while maximizing user-flexibility and user-customization. Now the manufactures of MICA Motes are Crossbow Technologies. A developerâ„¢s kit is available from Crossbow, which provides a complete system for creating wireless sensor networks including Mote processor/ radio boards, Mote sensor boards, and a Mote programming/serial interface board. The MICA Mote is the cornerstone of a powerful wireless sensor networking technology. The MICA Mote connects and processes sensor data and communicates it via a unique multi-hop radio transceiver. The MICA mote supports a wide variety of sensor types such as: Acceleration, Magnetic, Light, Temperature, Acoustic, and Sounder. Based on feedback from the first few thousand wireless sensors deployed, UC Berkeley and the collaborating researchers devised a second-generation platform to add improvements to the first. The 2 nd generation platform is named MICA, because the final electronic implementation of MICA resembles its silicate relative that separates into thin mineral leaves. Likewise the MICA electronic hardware is a series of thin processor/radio and sensor circuit cards sandwiched together to form an integrated wireless smart sensor. The third generation platform is called MICA2 and the fourth generation platform is called MICA2DOT. A typical MICA mote is shown in Fig. 2.3. A surface-mount 51-pin connector provides a flexible but standard interface between MPR (processor/radio) boards and MTS (sensor) boards. The processor/radio board is MPR400CB and the sensor board is MTS300CA. Custom sensor board designs are built by including the 51-pin connector on the design and wiring the appropriate signals to the connector.
2.3.2 Processor and Radio Platform (MPR400CB)
The MPR400CB is based on the Atmelâ„¢s ATmega 128L. The ATmega 128L is a low- power micro controller which runs TOS from its internal flash memory. Using TOS, a single processor board (MPR400CB) can be configured to run your sensor application/processing and the network/radio communications stack simultaneously. The MICA2 51-pin expansion connector supports Analog Inputs, Digital I/O, I2C, SPI, and UART interfaces. These interfaces make it easy to connect to a wide variety of external peripherals. The MPR400 (MICA2) uses an ISM band radio transceiver module for wireless communication. The radio transceiver on the mote is the model CC1000 from Chipcon. CC1000 is a true single-chip UHF transceiver designed for very low power and very low voltage wireless applications. It has three working modes, i.e., receiving, transmitting, and sleep, the current draw by each of these modes is 10 mA, 27 mA (peak), and <1 Ã‚ÂµA respectively. The salient features of MICA2 mote are summarized in Table 2.1 below. 13 Fig. 2.3 - A Typical MICA Mote Page 14 14 Processor/Radio Board MPR400CB Remarks Processor Performance Program Flash Memory 128K bytes Measurement (Serial) Flash 512K bytes >100,000 Measurements Configuration EEPROM 4 K bytes Serial Communications UART 0-3V transmission levels Analog to Digital Converter 10 bit ADC 8 channel, 0-3Vin Other Interfaces DIO, I2C, SPI Current Draw 8 mA < 15uA Active mode Sleep mode Multi-Channel Radio Center Frequency 868/916 MHz ISM bands Number of Channels > 8, > 100 Programmable, country specific Data Rate 38.4 Kbaud Manchester encoded RF Power -20 - +5 dBm Programmable, typical Receive Sensitivity -98 dBm Typical, analog RSSI at AD Ch. 0 Outdoor Range 500 ft 1/4 Wave dipole, line of sight Current Draw 27 mA 10 mA < 1 Ã‚ÂµA Transmit with maximum power Receive Sleep Electromechanical Battery 2X AA batteries Attached pack External Power 2.7 - 3.3 V Connector provided User Interface 3 LEDs User programmable Page 15 Size (in) (mm) 2.25 x 1.25 x 0.25 58 x 32 x 7 Excluding battery pack Excluding battery pack Weight (oz) (grams) 0.7 18 Excluding batteries Excluding batteries Expansion Connector 51 pin All major I/O signals 2.3.3 Sensor Board Various sensor boards are available from Crossbow and other resources. These boards connect onto the MICA2 through a surface mount 51-pin connector. The 51-pin connector supports Analog Inputs, I2C, SPI, UART, and a multiplexed Address/Data bus. The sensor board, which is used in this work, is MTS300CA. The MTS300CA is a flexible sensor board with a variety of sensing modalities. These modalities include Light, Temperature, Acoustic, and Sounder. MTS300CA can be used both on MICA and MICA2 Motes. 2.3.4 Base Station/Interface Board The base station allows the aggregation of sensor network data onto a PC or other computer platform. The MICA2 architecture is unique in that any sensor node (MPR400CB) module can function as a base station by plugging the MPR400CB processor/radio board into a basic interface board, known as the Mote Interface Board (MIB). Different interface boards are now available. The interface board is named as MIB510CA.
The motes can be programmed, by attaching them to the Mote Interface Board. The MIB can be interfaced with the PC by connecting it to the serial port. The mote has an on board flash that can be programmed. The mote that is to be programmed is connected to the 51 pin male connector on the board. Once the TinyOS environment is installed, a command line interface is used to install the TinyOS code and assign the MoteID number, which is used to identify each mote in the sensor network. More experienced users may program Motes with JTAG or with the TinyOS over-the-Air Network Programming application called Netprog.
WIRELESS SENSOR NETWORKS
The history of wireless networks started in the 1970s and the interest has been growing ever since. During the last decade, and especially at the end, the interest has almost exploded probably because of the fast growing Internet. Today we see two kinds of wireless networks but the difference between them is not as obvious as it may seen. The first kind and most used today is a wireless network built on top of a wired network and thus creates a reliable infrastructured wireless network. The wireless nodes, also connected to the wired network and able to act as bridges in a network of this kind are called base-stations. An example of this is the cellular-phone networks where a phone connects to the base-station with the best signal quality. When the phone move out of range of a base-station it does a hand-off and switch to a new base-station within reach. The hand-off should be fast enough to be seamless for the user of the network. Other more recent networks of this kind is wireless networks for offices, cafes etc which usually are called Wireless Local Area Networks (WLAN). The other kind is, as it may seem the orthogonal kind. One where there is no infrastructure at all except the participating mobile nodes. This is called an infrastructurless network or more commonly an ad hoc network. The word ad hoc can be translated as improvised or not organized which often has a negative meaning, but the sense in this context is not negative but only describing the network situation, i.e. dynamic.
Wireless Sensor Networks
Wireless Sensor Networks (WSN) are composed of a large number of sensor nodes (order of hundreds or thousands) which are densely deployed either inside the phenomenon or very close to it. Such a network normally consists of a large number of distributed nodes that organize themselves into a multi-hop wireless network. Each node has one or more sensors, embedded processors and low-power radios, and is normally battery operated. Typically, these nodes coordinate to perform a common task. WSNs have a wide range of potential applications including environment monitoring, smart spaces, medical systems and robotic exploration. WSNs are likely to be widely deployed in the future because they greatly extend our ability to monitor and control the physical environment from remote locations. Such networks can greatly improve the accuracy of information obtained via collaboration among sensor nodes and online information processing at those nodes. There are numerous research activities in WSN in the last few years, which have wide variety of topics including environmental applications, habitat monitoring, MAC layer protocols for WSNs, querying WSNs, security issues, coverage problem, timing synchronization, etc. All in these topics, researchers try to get more accurate results from WSN applications despite lots of constraints.
Differences between WSNs and Other Kinds of Networks
WSNs operate under different constraints than traditional network domains. One source of difference is the hardware itself. Sensor nodes are heavily constrained by both communication capability and energy. Node communication hardware is often a simple radio transceiver that has limited bandwidth, on the order of a few tens of Kbps. Sending a single bit of data can consume the energy of executing a thousand instructions. As opposed to measuring bandwidth in megabytes or kilobytes, every packet is precious. Energy constraints are further compounded by the fact that the networks are expected to exist unattended for long periods of time. This degree of energy conservation is usually not an issue when discussing wired and even 802.11 networks. Laptops can be recharged, but sensor networks die.
The other point of distinction is in the attributes of the communication network. WSNs may operate at a scale of hundreds, thousands, or more. They exhibit highly transient loss patterns, which are susceptible to changes in environmental conditions. Irregularities in the network such as asymmetric links often arise.
WSN is also significantly different from cellular networks. In these traditional networks the tasks of organization, routing and mobility management is done to optimize QoS and high bandwidth efficiency. These networks are designed to provide good throughput/delay characteristics under high mobility conditions. Energy consumption is of secondary importance as the battery packs can be replaced as needed. However WSNs consist of hundreds to thousands of nodes that are designed for unattended operation. The nodes are generally stationary after deployment except for a few mobile nodes. The traffic is of a statistical nature as compared to the multimedia rich data in and cellular networks. The data rate is expected to be very low to the order of 1-1000kb/s. Unlike conventional networks the main goals are prolonging the life of the network and prevent connectivity degradation through aggressive energy management as the batteries cannot usually be replaced because of operations in hostile or remote environments. In WSNs the flow of data is predominantly unidirectional from the sensor nodes to a sink (base station).
3.3.1 AdHoc Networks vs WSN
There are some clear cut distinction between Ahhoc networks and Wireless Sensor
Â¢ Sensor networks are mainly used to collect information while adhoc networks are designed for distributed computing rather than information gathering
Â¢ Usually, as sensor network is deployed by one owner, while adhoc network could be run by several unrelated units.
Â¢ The number of nodes in sensor networks can be several orders of magnitude higher
than that in an adhoc network.
Â¢ Unlike a node in a adhoc network, a node in a sensor network may not have a unique ID.
Â¢ Sensor nodes are much cheaper than nodes in an adhoc network and are usually deployed in thousands.
Â¢ Power resources of sensor nodes could be very limited; however, nodes in an adhoc networks can be re-charged.
Â¢ Usually, the data in sensor networks are bound either downstream to nodes from a sink or upstream to sink form nodes, while in adhoc networks, the data flows are irregular.
Â¢ Usually, sensors are deployed once in their lifetime, while nodes in adhoc networks move really in an adhoc manner.
Â¢ Sensor nodes mainly use broadcast, most adhoc networks are based on Peer-to-Peer (P2P).
Â¢ Sensor nodes are much more limited in their computation and communication capabilities than their adhoc network counterparts due to their low cost.
Â¢ Sensor nodes are prone to failures
3.3.2 MANET vs WSN
The commonalities and differences of WSN with Mobile Adhoc Networks (MANETs) are summarized below :
Â¢ COMMONALITIES WITH MANETs
Â¢ Self-organization, multi-hop
Â¢ Typically wireless, should be energy efficient
Â¢ DIFFERENCES TO MANETS
Applications: MANET more powerful, more general ? WSN more specific â€œ Devices: MANET more powerful, higher data rates, more resources ? WSN rather limited, embedded, interacting with environment â€œ Scale: MANET rather small (some dozen devices) ? WSN can be large (thousands) â€œ Basic paradigms: MANET individual node important, ID centric ? WSN network important, individual node may be dispensable, data centric â€œ Mobility patterns, Quality-of Service, Energy, Cost per node etc. 3.4 WSN Deployment 19 Fig. 3.1 shows a typical Wireless Sensor Network scenario. Page 20
A sensor network is a deployment of massive numbers of small, inexpensive, self- powered devices that can sense, compute and communicate with other devices for the purpose of gathering local information to make global decisions about a physical environment. The figure shows sensor nodes deployed in a geographical area. Data are collected to a sink which may be situated at base station and these data may be sent over internet to the end user for collection and analysis.
Sensor Networks Communication Architecture
The sensor nodes are usually scattered in a sensor field as shown in Fig. 3.2. Each of these scattered sensor nodes has the capabilities to collect data and route data back to the sink and end users. A sink is a long range radio node connecting WSNs to databases for communication. Data are routed back to the end user by a multi-hop infrastructureless architecture through the sink as shown in the figure. The sink may communicate with the task manager node via Internet or satellite.
Generally, the communication from sensor nodes to sinks is using multi-hop and from sinks to sensors is either broadcast or multicast.
3.6 Realization of a WSN
Fig. 3.3 shows the realization of a sensor network. The data collected by the sensor nodes (SN) and received by the gateways (GW). The gateways can be GPRS, WLAN, Ethernet or Blue tooth so as to send the data to a remote location.
SN GW SN SN SN SN SN SN SN SN SN SN GW GW GW Bluetooth E t h e r n e t SN G P R S W L A N Fig. 3.3 -
Clustering of Nodes in a WSN
The clustering of nodes in a wireless sensor network is depicted in Fig. 3.5. A set of
nodes forms a cluster which can have a cluster head. Clusters also can be combined together to
form a super cluster. Data can be received by the base station and sent it over internet.
The nodes in a cluster communicate to its cluster head. Cluster head, which is a node
with larger capacities, communicates to the base station. Only base station has got a link to
external databases, generally through internet.
Fig. 3.4 - Detailed View of a WSN Page 23
Sensor Network Protocol Stack
The protocol stack used by the sink and all sensor nodes is given in Fig. 3.6. This protocol stack combines power and routing awareness, integrates data with networking protocols, communicates power efficiently through the wireless medium, and promotes cooperative efforts of sensor nodes. The protocol stack consists of the application layer, transport layer, network layer, data link layer, physical layer, power management plane, mobility management plane and task management plane.
Depending on the sensing tasks, different types application software can be built and used on the application layer. The transport layer helps to maintain the flow of data if the sensor networks application requires it. The network layer takes care of routing the data supplied by the transport layer. Since the environment is noisy and sensor nodes can be mobile, The MAC protocol must be power aware and able to minimize the collision with the neighborsâ„¢ broadcast. The physical layer addresses the needs of a simple but robust modulation, transmission and receiving techniques. In addition the power, mobility and task management planes monitor the power, movement and task distribution among the sensor nodes. These planes help the sensor nodes coordinate the sensing task and lower the overall power consumption.
The power management plane manages how a sensor node uses its power. For example, a sensor node may turn off its receiver after receiving a message from one of its neighbours. This is to avoid getting duplicated messages. Also, when the power level of the sensor nodes low, sensor node broadcasts to its neighbors that it is low in power and cannot participate in routing messages. The remaining power is reserved for sensing. The mobility management plane detects and registers the movement of sensor nodes, so a route back to the user is always maintained, and the sensor nodes can keep track of who are their neighbor sensor nodes. By knowing who are the neighbor sensor nodes, the sensor nodes can balance their power and task usage. The task management plane balances and schedules the sensing tasks given to a specific region. Not all sensor nodes in that region are required to perform the sensing task at the same time. As a result, some sensor nodes perform the task more than the others depending on their power level. These management planes are needed, so that sensor nodes can work together in a power efficient way, route data in a mobile sensor network, and share resources between sensor nodes. Without them, each sensor node will just work individually. From the whole sensor network standpoint, it is more efficient if sensor nodes can collaborate with each other, so the lifetime of the sensor networks can be prolonged. 3.10 Sensor Network Physical Topology Wireless Sensor Network refers to a heterogeneous system combining tiny sensors and actuators with general purpose computing elements. Sensor networks may consist of hundreds or thousands of low-power, low-cost nodes, possibly mobile but more likely at fixed locations, deployed en masse to monitor and affect the environment. WSNs improve sensing accuracy by providing distributed processing of vast quantities of sensing information (e.g., seismic data, acoustic data, high-resolution images, etc.). When networked, sensors can aggregate such data to provide a rich, multidimensional view of the environment. In addition, networked sensors can focus their attention on critical events pointed out by other sensors in the network (e.g., an intruder entering a building). Finally, networked sensors can continue to function accurately in the face of failure of individual sensors; for example, if some sensors in a network lose a piece of crucial information, other sensors may come to the rescue by providing the missing data. Fig. 3.7 shows a simple sensor network. Sensor nodes gather data autonomously, and the network passes this data to one or more base stations, which forward the data to a sensor network server. Such servers will make available a wide range of data from different networks in the future. Moving from sensor nodes to the SNS, the systems generally increase in compute power, data storage and power availability. If a base station supports a large number of sensor nodes, they would typically be organized as an ad-hoc set of clusters with representative nodes communicating a groupâ„¢s data to the base.
Therefore a future in which collections of sensor nodes form ad hoc distributed processing networks that produce easily accessible and high-quality information about the physical environment is envisioned. Each sensor node operates autonomously with no central point of control in the network, and each node bases its decisions on its mission, the information it currently has, and its knowledge of its computing, communication and energy resources. Compared to todayâ„¢s isolated sensors, tomorrowâ„¢s networked sensors have the potential to perform their responsibilities with more accuracy, robustness and sophistication. 3.11 Sensor Network Challenges Extracting data gathered by sensor nodes in remote locations involve some unique challenges. These obstacles arise from the limited energy, computational power, and communication resources available to the sensors in the network.
Power Consumption (Battery): The wireless sensor node, being a micro electronic device, can only be equipped with a limited power source, in some application scenarios, replenishment of power sources might be impossible. Sensor node lifetime therefore shows a strong dependence on battery lifetime. Hence, power conservation and power management take on additional importance. The main task of a sensor node in a sensor field is to detect events, perform quick local data processing, and then transmit the data. Power consumption can hence be divided into three domains: sensing, communication and data processing.
Communication: The bandwidth of the wireless links connecting sensor nodes is often limited, on the order of a few hundred Kbps, further constraining inter-sensor communication. Also, a sensor node expends maximum energy in data communication. This involves both data transmission and reception.
Data Processing: Energy expenditure in data processing is much less compared to data communication. Local data processing is crucial in minimizing power consumption in a multihop sensor network. A sensor node must therefore have built-in computational abilities and be capable of interacting with its surroundings. Thus CMOS technology is used for microprocessor. Unfortunately, this has inbuilt limitations on energy efficiency. A CMOS transistor pair draws power every time it is switched. This switching power is proportional to the switching frequency, device capacitance and square of the voltage swing. Reducing the supply voltage is hence an effective means of lowering power consumption in the active state. Significant energy gains can be obtained by recognizing that peak performance is not always desired and therefore, the processorâ„¢s operating voltage and frequency can be dynamically adapted to instantaneous processing requirements.
Hardware Constraints: This is another criterion one must consider before WSN design. The current sensor motes have 4 â€œ 8 MHz CPU clock, 128 KB program memory, 4 KB RAM 916/433 base radio frequency and 512 KB non-volatile storage. Page 28 For instance, program memory limits your code size with 128 KB, which prevents you to load program, which has more size than that.
Environment: Environmental monitoring represents a class of sensor network applications with enormous potential benefits for scientific communities and society as a whole. Sensor nodes are densely deployed either very close or directly inside the phenomenon to be observed. Therefore, they usually work unattended in remote geographic areas. They may be working in the busy intersections in the interior of a large machinery at the bottom of an ocean on the surface of an ocean during a tornado in a biologically or chemically contaminated field attached to animals The following list gives us an idea about under which conditions sensor nodes are expected to work.
Transmission Media: In a multihop sensor network, communicating nodes are linked by a wireless medium. These links can be formed by radio, infrared or optical media. To enable global operation of these networks, the chosen transmission medium must be available worldwide.
Security: All sensor network levels must take security into account. Systems must blend into the environment and, when appropriate, carry warnings, alarms, and other information. Some networks can cope with the loss of one or more nodes due to failure or damage, and in remote areas, physical security may not be an issue. In addition, data may need protection against deliberate accidental alteration. However, security mechanisms should not hamper public access to information. Striking a balance between security and accessibility helps ensure that all parties can trust the systems.
Production Costs: Since the sensor network consists of a large number of sensor nodes, the cost of a single node is very important to justify the overall cost of the networks. If the cost of the network is more expensive than deploying traditional sensors, then the sensor network is not cost justified. As a result, the cost of each sensor node has to be kept low.
3.12 Networked Sensor Characteristics
Â¢ Small physical size and low power consumption: At any point in technological evolution, size and power constrain the processing, storage, and interconnect capability of the basic device. Obviously, reducing the size and power required for given capability are driving factors in the hardware design. At a system level, the key observation is that these capabilities are limited and scarce. This sets the background for the rest of the solution, which must be austere and efficient.
Concurrency-intensive operation: The primary mode of operation for these devices is to flow information from place to place with a modest amount of processing on the fly, rather than to accept a command, stop, think, and respond. For example, information may be simultaneously captured from sensors, manipulated, and streamed onto a network. Alternatively, data may be received from other nodes and forwarded in multi-hop routing or bridging situations. There is little internal storage capacity, so buffering large amounts of data between the inbound and the outbound flows is unattractive. Moreover, each of the flows generally involves a large number of low- level events interleaved with higher-level processing. Some of these events have real- time requirements, such as bounded jitter; some processing will extend over many such time-critical events.
Limited Physical Parallelism and Controller Hierarchy: The number of independent controllers, the capabilities of the controllers, and the sophistication of the processor-memory-switch level interconnect are much lower than in conventional systems. Typically, the sensor or actuator provides a primitive interface directly to a single-chip microcontroller. In contrast, conventional systems distribute the concurrent processing associated with the collection of devices over multiple levels of controllers interconnected by an elaborate bus structure. Although future architectural Page 30 developments may recreate a low duty-cycle analog controllers and interconnect, space and power constraints and limited physical configurability on-chip are likely to retain the need to support concurrency-intensive management of flows through the embedded microprocessor.
Diversity in Design and Usage: Networked sensor devices will tend to be application specific, rather than general purpose, and carry only the available hardware support actually needed for the application. As there is a wide range of potential applications, the variation in physical devices is likely to be large. On any particular device, it is important to easily assemble just the software components required to synthesize the application from the hardware components. Thus, these devices require an unusual degree of software modularity that must also be very efficient. A generic development environment is needed which allows specialized applications to be constructed from a spectrum of devices without heavyweight interfaces. Moreover, it should be natural to migrate components across the hardware/software boundary as technology evolves.
Robust Operation: These devices will be numerous, largely unattended, and expected to be operational a large fraction of the time. The application of traditional redundancy techniques is constrained by space and power limitations. Although redundancy across devices is more attractive than within devices, the communication cost for cross device redundancy is prohibitive. Thus, enhancing the reliability of individual devices is essential. This reinforces the need for efficient modularity: the components should be as independent as possible and connected with narrow interfaces. 3.13 Selection of Hardware and OS for WSN Applications
The major concerns in a wireless sensor network are energy efficiency, size and cost. To develop a networked embedded wireless system, first we have to identify a low-power, low cost and commercially available hardware platform. MICA2 platform, based on Atmelâ„¢s ATmega 128L microcontroller, developed by Berkeley University of California could be a selection for this. MICA2 is a small, power-efficient, flexible, and low cost integrated hardware module. The MICA2 runs TinyOS, a Tiny Microthreading Operating SystemPage 31 developed by Berkeley University of California, from its internal flash memory. TinyOS can be suited for such applications because it is a small, open-source, energy efficient software operating system designed specifically for large scale, self-configuring sensor networks. It supports an energy efficient wireless communication stack. Also TinyOS has control on various power down modes of the micro controller, and RF transceiver.
The hardware could be a MOTE-KIT400 for a typical WSN application. The motes are coming as a kit which provide all the hard ware and software required for faster development of sensor network applications. The kit includes :-
Â¢ 3 MICA2 Processor/Radio Boards
Â¢ 2 MTS300 Sensor Boards (Light, Temperature, Acoustic, and Sounder)
Â¢ 1 MIB510 Programming and Serial Interface Board
Â¢ Mote-View and Mote-Test Software
Â¢ Available in 916 MHz and 433 MHz options
The MOTE-KIT 400 is shown in Fig. 3.8.
3.13.2 Processor & Radio Board
The processor and radio details of MOTE-KIT 400 are listed below :-
Fig. 3.8 - MOTE-KIT 400 Page 32
Â¢ Program Flash Memory : 128Kbytes
Â¢ Current draw by processor : 8mA - Active mode
< 15Ã‚ÂµA - Sleep mode
Â¢ Center Freq. of the radio : 916/433 MHz
Â¢ Data rate of the radio transmission : 38.4K baud
Â¢ Outdoor range : 500 ft
Â¢ Current draw by radio :27 mA â€œ Transmit with
10 mA â€œ Receive
< 1 Ã‚ÂµA â€œ Sleep
Â¢ Size : 2.25 x 1.25 x 0.25
3.13.3 Operating System Requirements
As stated before, the devices will be of small physical size and are having low power consumption. That is to say that the devices have limited memory and power requirements. Most of the operations will be concurrency intensive. So the operating system should be able to service packets on-the-fly in real-time. The OS for WSN should be having limited number and capability of controllers due to the limited hardware parallelism and controller hierarchy. This reveals that such an OS will be having unsophisticated processor-memory switch-level interconnect. The OS should provide a higher degree of modularity for application specific sensors. This means that the OS should have diversity in design and usage. The OS should be reliable and assist applications in surviving individual device failures as the motes are prone to failures. This demands robustness for the operating system. TinyOS could be an ideal choice to meet the requirements of sensor network programming challenges.
TinyOS is a small, open-source, energy efficient; software operating system developed by UC Berkeley, which supports large scale, self-configuring sensor networks. The operating system is named TinyOS (Tiny Microthreading Operating System) because of its small size. TinyOS is specifically designed for network embedded systems. TinyOS has a programming model tailored for event-driven applications as well as a very small footprint. The core OS requires only 396 bytes of code and data memory, combined.
TinyOS is a micro threaded, event triggered operating system framework that is designed to retain the characteristics specified by the network sensors managing the hardware capabilities effectively, while supporting concurrency-intensive operation in a manner that achieves efficient modularity and robustness. TinyOS is not an operating system in the traditional sense. It is a programming framework for embedded systems and set of components that enable building an application specific operating system into each application. Before going into the details, it is time to look a little bit closer to two main ways of structuring concurrent systems. TinyOS has several important features: a component-based architecture, a simple event-based concurrency model, and split-phase operations.
4.2.1 Component-based Architecture
TinyOS provides a set of reusable system components. An application connects components using a wiring specification that is independent of component implementations; each application customizes the set of components it uses. Although most OS components are software modules, some are thin wrappers around hardware; the distinction is invisible to the developer. Decomposing different OS services into separate components allows unused services to be excluded from the application.
4.2.2 Tasks and Event-based Concurrency
There are two sources of concurrency in TinyOS: tasks and events. Tasks are a deferred computation mechanism. They run to completion and do not preempt each other. Components can post tasks; the post operation immediately returns, deferring the computation until the scheduler executes the task later. The post operation places the task on an internal task queue, which is processed in FIFO order. A maximum of 8 tasks can be queued at a time. When a task is executed, it runs to completion before the next task is run; therefore, a task should not spin or block for long periods of time. Tasks do not preempt each other, but a task can be preempted by a hardware event handler. Components can use tasks when timing requirements are not strict; this includes nearly all operations except low-level communication. To ensure low task execution latency, individual tasks must be short; lengthy operations should be spread across multiple tasks. The lifetime requirements of sensor networks prohibit heavy computation, keeping the system reactive. Events also run to completion, but may preempt the execution of a task or another event. Events signify either completion of a split-phase operation (discussed below) or an event from the environment (e.g. message reception or time passing). TinyOS execution is ultimately driven by events representing hardware interrupts.
4.2.3 Split-phase Operations
Because tasks execute non-preemptively, TinyOS has no blocking operations. All long-latency operations are split-phase: operation request and completion are separate functions. Commands are typically requests to execute an operation. If the operation is split- phase, the command returns immediately and completion will be signaled with an event; non- split-phase operations (e.g. toggle an LED) do not have completion events. A typical example of a split-phase operation is a packet send: a component may invoke the send command to initiate the transmission of a radio message, and the communication component signals the sendDone event when transmission has completed. Each component implements one half of the split-phase operation and calls the other; the wiring connects both commands and events across component boundaries.
Resource contention is typically handled through explicit rejection of concurrent requests. In the example above, if the communication component cannot handle multiple Page 35 concurrent send operations, it signals an error when a concurrent send is attempted. Alternately, the communication component could queue the request for future processing. The simple concurrency model of TinyOS allows high concurrency with low overhead, in contrast to a thread-based concurrency model in which thread stacks consume precious memory while blocking on a contended service. However, as in any concurrent system, concurrency and non-determinism can be the source of complex bugs, including deadlock. The TinyOS has got facilities for radio messaging, message hopping from mote to mote, low power modes, and sensor measurements and signal processing. Salient features of TinyOS are as follows:
Â¢ Software footprint
Â¢ Transmission Cost
Â¢ Inactive State
< 25 Ã‚ÂµA
Â¢ Peak load
Â¢ Typical CPU Usage
Â¢ Events Propagate through Stack
< 40 Ã‚Âµs
Concurrent Systems Approaches
4.3.1 Thread Driven Approach
In the thread-driven (thread-based) approach, threads and processes are primarily designed to support multiprogramming, and existing operating systems strive to virtualize hardware resources in a way that is transparent to applications. The system uses a main thread which hands off tasks to individual task-handling threads, which step through all the stages of processing that task. Threads are the standard form of expressing concurrency in most operating systems, and tools for programming in the sequential style of threads are relatively mature. However, there are several problems with thread programming. Synchronization primitives (such as locks, mutexes, or condition variables) are a common source of bugs, and lock contention can cause serious performance degradation as the number of threads competing for a lock increases. Additionally, the overhead of creating a handler thread for each task remains, although creating a pool of threads in advance can mitigate this cost. Finally, context switching between threads incurs a high overhead.
4.3.2 Event Driven Approach
In the event-driven (event-based) approach, the system uses a single thread and non- blocking interfaces to I/O subsystems or timer utilities to juggle between concurrent tasks. The processing of each task is implemented as a finite state machine, where transitions between states in the FSM are triggered by events. Event-driven programming has its own problems. Separate threads no longer handle the sequential flow of each task; instead, one thread processes all tasks in disjoint stages. This can make debugging difficult, as stack traces no longer represent the control flow for the processing of a particular task. Also, task state must be bundled into the task itself, rather than stored in local variables or on the stack in a threaded system. Event-packages are not standardized, and there are few debugging tools for event-driven programming. However, event-driven programming avoids many of the problems associated with synchronization, such as race conditions and deadlocks. Additionally, event- based systems can be faster than thread-based systems, since they avoid the overhead of thread creation and context switching.
A TinyOS application is simple a graph of components and a scheduler which is
compiled into one executable code. The TinyOS application is depicted pictorially in Fig. 4.1.
Application (User Components)
Main (includes Scheduler)
Application (User Components)
Main (includes Scheduler)
The idea behind a TinyOS application can be easily conceived with the help of the
following C code.
// component initialization
} // while
} // main
The running of an application can be visualized in this way : While some tasks are pending, the scheduler will schedule these tasks; otherwise simple puts the processor in sleep mode. This clearly matches the working principle of a mote as the motes will be normally in sleep mode and if an event occurs it has to wake up.
TinyOS Component Model
The component model of Tiny OS is shown in Fig. 4.2. A component has a frame (for
storage), tasks for computation and command and event interface. Each component declares
the commands it uses and the events it signals. The memory requirements of a component can
be known at compile time and this the overhead associated with dynamic allocation is
This figure shows a simple messaging component. Pictorially we can represent the component as a bundle of tasks, a block of states (component frame), a set of commands (upside down triangles), a set of handlers (triangles), solid down arcs for the command they use and the dashed upward arcs for the events they signal. All of these components are explicit in the component code.
TinyOS Scheduling & Communication
TinyOS uses a two-level scheduler, in which a small amount of processing associated with hardware events are performed immediately, while long running tasks may be interrupted. These tasks are the micro threads described in, where TinyOS is identified as a micro threaded operating system. Micro threads are also known as non-blocking threads or no preemptive threads. Scheduling of computation in TinyOS is split into two levels. The first level consists of events and commands. These short computations are executed immediately. The second level consists of tasks, which are long-running computations. When a task is posted, it is placed in a first-in, first-out (FIFO) queue. Tasks are executed when there are no events or commands to be run. There is a single stack in the system, which is assigned to the currently executing task. A running task may be preempted by events, in which case the interrupt hardware takes care of saving the state of a task. A task, however, may not preempt other tasks.
A non-blocking approach is taken throughout TinyOS. There are no locks and components never spin on a synchronization variable. The scheduler uses a lock-free queue data structure. Components perform a phase of an operation and terminate, allowing the completion event to resume their execution. Most components are written essentially as reentrant state machines. In current implementation, the TinyOS execution model is implemented on a single shared stack with a static frame per component.
The thread scheduler is currently a simple FIFO scheduler, utilizing a bounded size scheduling data structure. Depending on the requirements of the application, more sophisticated priority-based or deadline-based structures can be used. It is crucial that the scheduler is power aware: the prototype puts the processor to sleep when the thread queue is empty, but leaves the peripherals operating, so that any of them can wake up the system. This behavior enables us to provide efficient battery usage, which is the most important criterion that must be taken into account in WSN. Once the queue is empty, another thread can be scheduled only as a result of an event, thus there is no need for the scheduler to wake up until a hardware event triggers activity. More aggressive power management is left to the application.
Drawbacks of TinyOS
It is a special purpose (not general purpose) operating system.
It has resource constraints -- computation ability, memory and power
There is no dedicated I/O controller (this may cause loss of data).
It executes one program/process at one time (there is no multi-programming
It has very thin threads for running tasks (actually no thread in general)
There is no memory protection, which means it is easy to corrupt/crash the system
There is not much compile time error type checking.
It has heavy use of macros.
There is no support for common idioms: FSM-like programs, atomicity.
It has simplistic FIFO scheduling which means no real time guarantees.
4.8 TinyOS - Summary
The features of TinyOS are summarized below :-
TinyOS is a highly modular software environment tailored to the requirements of
Network Sensors, stressing efficiency, modularity, and concurrency
TinyOS is able to support new sensor devices as they evolve
Running an application on TinyOS can help reveal the impact of architectural changes in the underlying hardware, making it easier to design hardware that is optimized for a particular application.
It is not an Operating System in the traditional sense. It is a programming framework
for embedded systems rather than a full-function OS.
THE nesC LANGUAGE
nesC is a programming language for networked embedded systems that represent a new design space for application developers. An example of a networked embedded system is a sensor network, which consists of thousands of tiny, low power motes, each of which executes concurrent, reactive programs that must operate with severe memory and power constraints. nesCâ„¢s contribution is to support the special needs of this domain by exposing a programming model that incorporates event-driven execution, a flexible concurrency model, and component-oriented application design. Restrictions on the programming model allow the nesC compiler to perform whole-program analysis, including data-race detection (which improves reliability) and aggressive function inlining (which reduces resource consumption). nesC supports a programming model that integrates reactivity to the environment, concurrency, and communication. By performing whole-program optimizations and compile- time data race detection, nesC simplifies application development, reduces code size, and eliminates many sources of potential bugs.
nesC - Challenges
A key focus of nesC is holistic system design. Mote applications are deeply tied to hardware, and each mote runs a single application
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
project report helper|
Active In SP
Joined: Sep 2010
09-10-2010, 02:51 PM
semi 2.pdf (Size: 349.82 KB / Downloads: 70)
Sensor network application framework for autonomous
structural health monitoring of bridges
Edward Sazonova, Kerop Janoyan b, Ratan Jhac
a Dept. of Electrical and Computer Engineering
b Dept. of Civil and Environmental Engineering
c Dept. of Mechanical and Aeronautical Engineering
Clarkson University, 8 Clarkson Ave, Potsdam, NY, 13699
Life cycle monitoring of civil infrastructure such as bridges and buildings is critical to
the long-term operational cost and safety of aging structures. Nevertheless, there is no
commonly accepted and recognized way to perform automated monitoring of bridges.
One of the important issues is the cost of the data acquisition subsystem and its
installation and maintenance costs, which are tightly connected to the choice of
The presented application framework includes: first, Wireless Intelligent Sensor and
Actuator Network (WISAN) as an inexpensive way to perform data acquisition for the
tasks of structural health monitoring; second, a vibration-based SHM method for bridges;
and third, a fully autonomous SHM system for bridges, ambient-energy-powered and
minimally dependent of human involvement.
Design of the sensor network reflects the particularities of the application: proactive
rather than reactive nature of the data streams; fault-tolerant architecture ensuring
protection from extreme events; and real-time data acquisition capabilities. Other issues
include operating a massive array of heterogeneous sensors, achieving a low cost per
sensor, cost and sources of energy for the network nodes, energy-efficient distribution of
the computational load, security of communications and coexistence in the ISM radio
The modal SHM methods under consideration are the method of modal strain energy
with fuzzy uncertainty management, method of damage index and a method based on
Hilbert-Huang transform. Modal identification through ambient vibrations is performed
though auto-regressive moving average models.
The final step in the monitoring methods is the determination of bridge deterioration
rate and prediction of its remaining useful life based on measurements provided by the
sensor network and modal methods used. The deterioration curves are generated at both
the element and bridge levels and are compared to existing inspection-based methods.
Keywords: wireless sensor networks, structural health monitoring, ambient
vibrations, autonomous systems, modal strain energy, deterioration rate, life-cycle