System Architecture of - PowerPoint PPT Presentation

About This Presentation
Title:

System Architecture of

Description:

MANTIS hardware nymph's design was inspired by the Berkeley MICA an MICA2 Mote architecture. MANTIS Nymph is a single-board design, incorporating the micro ... – PowerPoint PPT presentation

Number of Views:245
Avg rating:3.0/5.0
Slides: 93
Provided by: damlat
Learn more at: http://www.cs.ucf.edu
Category:

less

Transcript and Presenter's Notes

Title: System Architecture of


1
System Architecture of Networked Sensor
Platforms and Sensor Networks Applications
2
Introduction
Wireless sensor networks (WSN) consists of group
of sensor nodes to perform distributed sensing
task using wireless medium. Characteristics-
low-cost, low-power, lightweight - densely
deployed - prone to failures - two ways of
deployment randomly, pre-determined or
engineered Objectives- Monitor
activities- Gather and fuse information -
Communicate with global data processing unit
3
Introduction
  • Recent sensor networks research involves almost
    all the layers and can be categorized into the
    following three aspects Akyildiz2002,
    Elson2002
  • Energy Efficiency
  • small devices, limited amount of energy,
    essential to prolong system lifetime
  • Scalability
  • deployment of thousands of sensor nodes,
    low-cost
  • Locality
  • smallest networks cannot depend on having global
    states

4
Why Sensor Platforms?
  • Traditional mechanisms of exploring the network
    (analysis and simulation) are not satisfied for
    exploring such a large-scale, dynamic and
    resource-constrained networks due to their
    difficulties to modeling every aspect of the
    system as a whole
  • For example, energy consumption model of the
    hardware platforms, including sensing,
    computation and communication, is not fully
    considered and overly-simplified assumptions have
    been made
  • Application-specific property of WSN makes the
    existing research mechanisms even harder to
    obtain meaningful results
  • Therefore, the demand to build a platform is
    increasing e.g., Berkeleys motes and MANTIS

5
Why Sensor Platforms?
  • Compared to analysis and simulation techniques,
    designing a system platform has the following
    advantages
  • Provides genuine executive environment various
    proposed algorithms can be exactly evaluated
    good way to examine existing design principles
    and discover new ones under different
    configurations
  • More attention can be focused on the
    application-layer
  • A real system platform can accelerate the pace of
    research and development

6
General WSN System Architecture
  • Constructing a platform for WSN falls into the
    area of embedded system development which usually
    consists of developing environment, hardware and
    software platforms.
  • Hardware Platform
  • Consists of the following four components
  • a) Processing Unit
  • Associates with small storage unit (tens of kilo
    bytes order) and
  • manages the procedures to collaborate with other
    nodes to carry out the
  • assigned sensing task
  • b) Transceiver Unit
  • Connects the node to the network via various
    possible transmission
  • medias such as infra, light, radio and so on

7
General WSN System Architecture
  • Hardware Platform
  • c) Power Unit
  • Supplies power to the system by small size
    batteries which makes the
  • energy a scarce resource
  • d) Sensing Units
  • Usually composed of two subunits sensors and
    analog-to-digital
  • Converters (ADCs). The analog signal produced by
    the sensors are
  • converted to digital signals by the ADC, and fed
    into the processing unit
  • e) Other Application Dependent Components
  • Location finding system is needed to determine
    the location of sensor
  • nodes with high accuracy mobilizer may be needed
    to move sensor
  • nodes when it is required to carry out the task

8
General WSN System Architecture
  • Hardware Platform

Figure 1 The components of a sensor node
Akyildiz2002
9
General WSN System Architecture
  • Software Platform
  • Consists of the following four components
  • a) Embedded Operating System (EOS)
  • Manages the hardware capability efficiently as
    well as supports
  • concurrency-intense operations. Apart from
    traditional OS tasks such as
  • processor, memory and I/O management, it must be
    real-time to rapidly
  • respond the hardware triggered events,
    multi-threading to handle
  • concurrent flows
  • b) Application Programming Interface (API)
  • A series of functions provided by OS and other
    system-level components
  • for assisting developers to build applications
    upon itself

10
General WSN System Architecture
  • Software Platform
  • c) Device Drivers
  • A series of routines that determine how the upper
    layer entities
  • communicate with the peripheral devices
  • d) Hardware Abstract Layer (HAL)
  • Intermediate layer between the hardware and the
    OS. Provides uniform
  • interfaces to the upper layer while its
    implementation is highly dependent
  • on the lower layer hardware. With the use of HAL,
    the OS and
  • applications easily transplant from one hardware
    platform to another

11
General WSN System Architecture
  • Software Platform

Figure 2 The software platform for WSN
12
General WSN System Architecture
  • System Development Environment
  • Provides various of tools for every stage of
    software development over
  • the specific hardware platform
  • a) Cross-Platform Development
  • Generally, an embedded system unlike PC and does
    not have the ability
  • of self-development. The final binary code run on
    that system, termed as
  • target system, will be generated on the PC,
    termed as host system, by
  • cross-platform compilers and linkers, and
    download the resulted image
  • via the communication port onto the target system

13
General WSN System Architecture
  • System Development Environment
  • Provides various of tools for every stage of
    software development over
  • the specific hardware platform
  • b) Debug Techniques
  • Due to the difficulties introduced by
    cross-platform development mode,
  • the debug techniques become critical for the
    efficiency of software
  • production. For this reason, many chips on the
    system provide the
  • on-chip debugger, such as JTAF, to reduce the
    development time.

14
Berkeley Motes Hill 2000
  • Motes are tiny, self-contained, battery powered
    computers with radio links, which enable them to
    communicate and exchange data with one another,
    and to self-organize into ad hoc networks
  • Motes form the building blocks of wireless sensor
    networks
  • TinyOS TinyOS, component-based runtime
    environment, is designed to provide support for
    these motes which require concurrency intensive
    operations while constrained by minimal hardware
    resources

Figure 3 Berkeley Mote
15
Berkeley Motes Hill 2000
  • Hardware Platform
  • Consists of
  • micro-controller with internal flash program
    memory
  • data SRAM
  • data EEPROM
  • a set of actuator and sensor devices, including
    LEDs
  • a low-power transceiver
  • an analog photo-sensor
  • a digital temperature sensor
  • a serial port
  • a small coprocessor unit

16
Berkeley Motes Hill 2000
  • Hardware Platform

Figure 4 The schematic for representative
network sensor platform
17
Berkeley Motes Hill 2000
  • Hardware Platform
  • The processing unit
  • MCU (ATMEL 90LS8535), an 8-bit architecture with
    16-bit addresses
  • provides 32 8-bit general registers and runs at
    4 MHz and 3.0 V
  • has 8 KB flash as the program memory and 512
    Bytes of SRAM as the data memory
  • MCU is designed such that the processor cannot
    write to instruction memory the prototype uses a
    coprocessor to perform this function
  • the processor integrates a set of timers and
    counters which can be configured to generate
    interrupts at regular time intervals
  • three sleep modes idle (shuts off the
    processor), power down (shuts off everything, but
    the watchdog and asynchronous interrupt logic
    necessary to wake up), power save (keep
    asynchronous timer on)

18
Berkeley Motes Hill 2000
  • Hardware Platform
  • The sensing units
  • contains two sub-components photo sensor and
    temperature sensor
  • photo sensor represents an analog input device
    with simple control lines which eliminate power
    drain through the photo resistor when not in use
  • temperature sensor (Analog Devices AD7418)
    represents a large class of digital sensors which
    have internal A/D converters and interface over a
    standard chip-to-chip protocol (the synchronous
    two-wire I2C protocol with software on the
    micro-controller synthesizing the I2C master over
    general I/O pins. There is no explicit arbiter
    and bus negotiations are carried out by the
    software on the micro-controller

19
Berkeley Motes Hill 2000
  • Hardware Platform
  • The transceiver unit
  • consist of an RF Monolithics 916.50 MHz
    transceiver (TR1000), antenna, and a collection
    of discrete components to configure the physical
    layer characteristics such as signal strength and
    sensitivity
  • operates in an ON-OFF key mode at speeds up to
    19.2 Kbps
  • control signals configure the radio to operate in
    either transmit, receive, or power-off mode
  • the radio contains no buffering, so each bit must
    be serviced by the controller on time
  • the transmitted value is not latched by the
    radio, so the jitter at the radio input is
    propagated into the transmission signal

20
Berkeley Motes Hill 2000
  • Hardware Platform
  • The transceiver unit is an Energizer CR2450
    lithium battery rated at
  • 575 mAh
  • The other auxiliary components include
  • The coprocessor
  • represents a synchronous bit-level device with
    byte-level support
  • MCU (AT09LS2343, with 2KB instruction memory, 128
    bytes of SRAM and EEPROM) that uses I/O pins
    connected to an SPI controller where SPI is a
    synchronous serial data link, providing high
    speed full-duplex connections (up to 1 Mbit)
    between peripherals
  • the sensor can be reprogrammed by transferring
    data from the network into the coprocessors 256
    KB EEPROM (24LC256)
  • can be used as a gateway to extra storage by the
    main processor

21
Berkeley Motes Hill 2000
  • Hardware Platform
  • The other auxiliary components include
  • The serial port
  • represents a synchronous bit-level device with
    byte-level controller support
  • uses I/O pins that are connected to an internal
    UART controller
  • in transmit mode, the UART takes a byte of data
    and shifts it out serially at a specified
    interval
  • in receive mode, it samples the input pin for a
    transition and shifts in bits at a specified
    interval from the edge
  • interrupts are triggered in the processor to
    signal completion of the events

22
Berkeley Motes Hill 2000, TinyOS
  • Hardware Platform
  • The other auxiliary components include
  • Three LEDs
  • represent outputs connected through general I/O
    ports they may be used to display digital values
    or status
  • Software Platform
  • based on Tiny Micro-Threading Operating System
    (TinyOS) which is designed for resource-constraine
    d MEMS sensors
  • TinyOS adopts an event model so that high levels
    of concurrency can be handled in a small amount
    of space
  • A stack-based threaded approach would require
    that stack space be reserved for each execution
    context

23
Berkeley Motes Hill 2000, TinyOS
  • Software Platform
  • A complete system configuration consists of a
    tiny scheduler and a graph of components
  • A component has four interrelated parts a set of
  • a set of command handlers
  • a set of event handlers
  • an encapsulated fixed-size frame
  • Bundle of simple tasks
  • tasks, commands and event handlers execute in the
    context of the frame and operate on its state
  • each component declares the commands it uses and
    the events it signals
  • these declarations are used to compose the
    modular components in a per-application
    configuration

24
Berkeley Motes Hill 2000, TinyOS
  • Software Platform
  • the composition process creates layers of
    components where higher-level components issue
    commands to lower-level components and
    lower-level components signal events to the
    higher-level components
  • Frames
  • fixed-size and statistically allocated which
    allows us to know memory requirements of a
    component at a compile time -- prevents overhead
    associated with dynamic allocation
  • Commands
  • non-blocking requests made to lower level
    components
  • typically, a command will deposit request
    parameters into its frame and conditionally post
    a task for later execution

25
Berkeley Motes Hill 2000, TinyOS
  • Software Platform
  • Commands
  • can invoke lower commands, but it must not wait
    for long
  • must provide feedback to its caller by returning
    status indicating whether it was successful or
    not
  • Event handlers
  • Invoked to deal with hardware events, either
    directly or indirectly
  • The lowest level components have handlers
    connected directly to hardware interrupts which
    may be external interrupts, timer events, or
    counter events
  • An event handler can deposit information into its
    frame, post tasks, signal higher level events or
    call lower level commands

26
Berkeley Motes Hill 2000, TinyOS
  • Software Platform
  • Event handlers
  • in order to avoid cycles in the command/event
    chain, commands cannot signal events
  • both signals and events are intended to perform a
    small, fixed amount of work, which occurs within
    the context of their components state
  • Tasks
  • perform the primary work
  • atomic entities with respect to other tasks, run
    to completion and can be preempted by events
  • can call lower level commands, signal higher
    level events, and schedule other tasks within a
    component

27
Berkeley Motes Hill 2000, TinyOS
  • Software Platform
  • Tasks
  • run-to-completion semantics make it possible to
    allocate a single stack that is assigned to the
    currently executing task which is essential in
    memory constrained systems
  • allows to simulate concurrency within each
    component, since tasks execute asynchronously
    with respect to the events
  • must never block or spin wait, otherwise, they
    will prevent progress in other components
  • Task scheduler
  • Utilizes a bounded size scheduling data structure
    to schedule various tasks base on FIFO,
    priority-based or deadline-based policy which is
    dependent on the requirements of the application

28
Berkeley Motes Hill 2000, TinyOS
Software Platform
Figure 5 The schematic for the architecture of
TinyOS
29
MANTIS Abrach 2003
  • MANTIS (MultimodAl system for NeTworks of In-situ
    wireless Sensors) provides a new multi-threaded
    embedded operating system integrated with a
    general-purpose single-board hardware platform to
    enable flexible and rapid prototyping of wireless
    sensor networks
  • the key design goals of MANTIS are
  • ease of use, i.e., a small learning curve that
    encourages novice programmers to rapidly
    prototype sensor applications
  • flexibility such that expert researchers can
    continue to adapt and extend the
    hardware/software system to suit the needs of
    advanced research

30
MANTIS Abrach 2003
  • MANTIS OS is called MOS
  • MOS selects its model as classical structure of
    layered multi-threaded operating systems which
    includes multi-threading, preemptive scheduling
    with time slicing, I/O synchronization via mutual
    exclusion, a standard network stack, and device
    drivers
  • MOS choose a standard programming language that
    the entire kernel and API are written in standard
    C. This design choice not only almost eliminates
    the learning curve, but also accrues many of the
    other benefits of a standard programming
    language, including cross-platform support and
    reuse of a vast legacy code base. C also eases
    development of cross-platform multimodal
    prototyping environments on X86 PCs

31
MANTIS Abrach 2003
  • Hardware Platform
  • MANTIS hardware nymphs design was inspired by
    the Berkeley MICA an MICA2 Mote architecture
  • MANTIS Nymph is a single-board design,
    incorporating the micro-controller, analog sensor
    ports, RF communication, EEPROM, and serial ports
    on one dual-layer 3.5 x 5.5 cm printed circuit
    board
  • the Nymph is centered around the AMTEL
    ATmega128(L) MCU, including interfaces for two
    UARTs, an SPI bus, an I2C bus, and eight
    analog-to-digital converter channels. It provides
    additional 64KB EEPROM external to MCU in
    addition to 4KB EEPROM included in MCU
  • the unit is powered either by batteries or an AC
    adapter, and a set of three on-board LEDs are
    included to aid in the debugging process. It is
    designed to hold a 24mm diameter lithium ion coin
    cell battery (CR2477), but any battery in the
    range of 1.8V to 3.6V can be connected

32
MANTIS Abrach 2003
  • Hardware Platform
  • in order to facilitate rapid prototyping in
    research environment, the Nymph has solderless
    plug connections for both analog and digital
    sensors, which eliminates the external sensor
    board for many applications
  • each connector provides lines for ground, power
    and sensor signal, allowing basic sensors such as
    photo sensors or complex devices such as infrared
    an ultra sounds receivers to be connected easily
  • the Chipcon CC1000 radio was chosen to handle
    wireless communication. It supports four carrier
    frequency bands (315, 433, 868, and 915 MHz) and
    allows for frequency hopping which is useful for
    multi-channel communication. It is one of the
    lowest power commercial radios and allows MOS to
    optimize the radio to further reduce the power
    consumption

33
MANTIS Abrach 2003
  • Hardware Platform
  • for additional modules, the Nymph includes JTAG
    interface which allows the user to easily
    download code to the hardware. This addition
    eliminates a need for separate programming board,
    simplifying the process of reprogramming the
    nodes while reducing the cost of overall system.
    As added benefit, the JTAG port allows the user
    to single-step through code on the MCU and also
    supports the remote shell
  • the Nymph uses one of the UARTs to supply a
    serial port (RS232) for connection to a PC while
    the second one is used as an interface to the
    optional GPS unit
  • MAX3221 RS232 serial chip is used and may be set
    in three different power saving modes
    power-down, receive only and shut down

34
MANTIS Abrach 2003
  • Hardware Platform

Figure 6 MANTIS Nymph
35
MANTIS Abrach 2003
  • Software Platform
  • MANTIS OS (MOS) adheres to classical layered
    multi-threaded design
  • top application and API layers show a simple C
    API which promotes the ease of use,
    cross-platform portability, and reuse of a large
    installed code base
  • in lower layers of MOS, it adapts the classical
    OS structures to achieve small memory footprint
  • System APIs
  • MANTIS provides comprehensive System APIs for I/O
    and system interaction
  • the choice of C language API simplifies
    cross-platform support and the development of a
    multimodal prototyping environment

36
MANTIS Abrach 2003
  • Software Platform
  • System APIs
  • since MANTIS System API is preserved across both
    physical sensor nodes as well as virtual sensor
    nodes running on X86 platforms, the same C code
    developed for MANTIS sensor Nymphs with AMTEL MCU
    can be compiled to run on X86 PCs with little or
    no alteration
  • Kernel and Scheduler
  • design of MOS kernel resembles classical
    UNIX-style schedulers
  • The services provided are subset of POSIX
    threads, most notably priority-based thread
    scheduling with round-robin semantics within a
    priority level
  • binary (mutex) and counting semaphores are also
    supported
  • the goal of the kernel design is to implement
    these familiar services in an efficient manner
    for resource-constrained environment of a sensor
    node

37
MANTIS Abrach 2003
  • Software Platform
  • Network Stack
  • focused on efficient use of limited memory,
    flexibility, and convenience
  • implemented as one or more user-level threads
  • different layers can be implemented in different
    threads, or all layers in the stack can be
    implemented in one thread
  • the tradeoff is between performance and
    flexibility
  • designed to minimize memory buffer allocation
    through layers
  • the data body for a packet is common through all
    layers within a thread
  • the headers for a packet is variably-sized and
    are pre-pended to the single data body
  • designed in a modular manner with standard APIs
    between each layers, thereby allowing developers
    easily modify or replace layer modules

38
MANTIS Abrach 2003
  • Software Platform
  • Device Drivers
  • Adopts the traditional logical/physical
    partitioning with respect to device driver design
    for the hardware
  • The application developer need not to interact
    with the hardware to accomplish a given task

39
MANTIS Abrach 2003
  • Software Platform

Figure 7 MANTIS OS Architecture
40
MANTIS Abrach 2003
  • System Development
  • application developers need to be able to
    prototype and test applications prior to
    distribution and physical deployment in the field
  • during deployment, in-situ sensor nodes need to
    be capable of being both dynamically reprogrammed
    and remotely debugged
  • in order to facilitates these issues, MANTIS
    identifies and implements three key advanced
    features for expert users of general-purpose
    sensor systems
  • multimodal prototyping environment
  • dynamic reprogramming
  • remote shell and commander server

41
MANTIS Abrach 2003
  • System Development
  • Multimodal Prototyping Environment
  • Provides a framework for prototyping diverse
    applications across heterogeneous platforms
  • A key requirement of sensor systems is the need
    to provide a prototyping environment to test
    sensor networking applications prior to
    deployment
  • Postponing testing of an application until after
    its deployment across a distributed sensor
    network can incur severe consequences
  • MANTIS prototyping environment extends beyond
    simulation to provide larger framework for
    development of network management and
    visualization applications as virtual nodes
    within a MANTIS network
  • MANTIS has property of enabling an application
    developer to test execution of the same C code on
    both virtual sensor nodes and later on in-situ
    physical sensor nodes

42
MANTIS Abrach 2003
  • System Development
  • Multimodal Prototyping Environment
  • Seamlessly integrates virtual environment with
    the real deployment network such that both
    virtual and physical nodes can co-exit and
    communicate with each other in the prototyping
    environment
  • Permits a virtual node to leverage other APIs
    outside of the MANTIS API, e.g., a virtual node
    with the MANTIS API could be realized as a UNIX
    X windows application that communicates with
    other rendering or database APIs to build
    visualization and network management applications

43
MANTIS Abrach 2003
  • System Development
  • Multimodal Prototyping Environment

Figure 8 Multimodal prototyping integrates both
virtual and physical sensor nodes across
heterogeneous X86 and AMTEL sensor platforms
44
MANTIS Abrach 2003
  • System Development
  • Dynamic Reprogramming
  • Sensor nodes should be remotely reconfigurable
    over a wireless multi-hop network after being
    deployed in the field. Since sensor nodes may be
    deployed in inaccessible areas and may scale to
    thousands of nodes, this simplifies management of
    the sensor network
  • MOS achieves dynamic reprogramming in several
    granularities re-flashing the entire OS
    reprogramming of a single thread and changing of
    variables within a thread
  • Another useful feature would be the ability to
    remotely debug a running thread. MOS provides a
    remote shell that enables a user to login and
    inspect the sensor nodes memory
  • MOS includes two programming modes (simpler and
    more advanced) in order to overcome the
    difficulty of reprogramming the network

45
MANTIS Abrach 2003
  • System Development
  • Dynamic Reprogramming
  • The simpler programming mode is similar to that
    used in many other systems and involves a direct
    communication with a specific MANTIS node
  • On a Nymph, this would be accomplished via a
    serial port the user simply connects the node to
    a PC and opens the MANTIS shell
  • Upon reset, MOS enters a boot loader that checks
    for communication from the shell. At this point,
    the node will accept a new code image, which is
    downloaded from the PC over the direct
    communication line
  • From the shell, the user has the ability to
    inspect and modify the nodes memory directly as
    well as spawn threads and retrieve debugging
    information including thread status, stack fill,
    and other statistics from OS
  • The boot loader transfers control to the MOS
    kernel on command from the shell, or at a startup
    if the shell is not present

46
MANTIS Abrach 2003
  • System Development
  • Dynamic Reprogramming
  • The more advanced programming mode is used when a
    node is already deployed, and does not require
    direct access to the node
  • The spectrum of dynamic reprogramming of in-situ
    sensor networks ranges from fine grained
    reprogramming to complete reprogramming
  • MOS has a provision for reprogramming any portion
    of the node up to and including the OS itself
    while the node is deployed in the field
  • This is accomplished through the MOS dynamic
    reprogramming interface

47
MANTIS Abrach 2003
  • System Development
  • Remote Shell and Commander Server
  • MOS includes the MANTIS Command Server (MCS)
    which is implemented as an application thread
  • From any device in the network equipped with a
    terminal, the user may invoke the command server
    client (also referred to as the shell) and log in
    to either a physical node (e.g., on a Nymph or
    Mica board) or a virtual node running as a
    process on a PC
  • MCS listens on a network port for commands and
    replies with the results, in a manner similar to
    RPC
  • The shell gains the ability to control a node
    remotely through MCS

48
MANTIS Abrach 2003
  • System Development
  • Remote Shell and Commander Server
  • The user may alter the nodes configuration
    settings, run or kill programs, display the
    thread table and other OS data, inspect and
    modify the nodes data memory, and call arbitrary
    user-defined functions
  • The shell is powerful debugging tool since it
    allows the user to examine and modify the state
    of any node, without requiring physical access to
    the node

49
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Introduction
  • Habitat and environmental monitoring represent
    essential class of sensor network applications by
    placing numerous networked micro-sensors in an
    environment where long-term data collection can
    be achieved
  • The sensor nodes perform filtering and triggering
    functions as well as application-specific or
    sensor-specific data compression algorithms thru
    the integration of local processing and storage
  • The ability to communicate allows nodes to
    cooperate in performing tasks such as statistical
    sampling, data aggregation, and system health and
    status monitoring
  • Increased power efficiency assists in resolving
    fundamental design tradeoffs, e.g., between
    sampling rates and battery lifetimes

50
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Introduction
  • The sensor nodes can be reprogrammed or retasked
    after deployment in the field by the networking
    and computing capabilities provided
  • Nodes can adapt their operation over time in
    response to changes in the environment
  • The application context helps to differentiate
    problems with simple and concrete solutions from
    open research areas
  • An effective sensor network architecture and
    general solutions should be developed for the
    domain
  • The impact of sensor networks for habitat and
    environmental monitoring is measured by their
    ability to enable new applications and produce
    new results

51
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Introduction
  • This paper develops a specific habitat monitoring
    application, but yet a representative of the
    domain
  • It presents a collection of requirements,
    constraints and guidelines that serve as a basis
    for general sensor network architecture
  • It describes the core components of the sensor
    network for this domain hardware and sensor
    platforms, the distinct networks involved, their
    interconnection, and the data management
    facilities
  • The design and implementation of the essential
    network services power management,
    communications, re-tasking, and node management
    can be evaluated in this context

52
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Habitat Monitoring
  • Researchers in the Life Sciences are concerned
    about the impacts of human presence in monitoring
    plants and animals in the field conditions
  • It is possible that chronic human disturbance may
    adversely effect results by changing behavioral
    patterns or distributions
  • Disturbance effects are of concern in small
    island situations where it may be physically
    impossible for researchers to avoid some impact
    on an entire population
  • Seabird colonies are extreme sensitive to human
    disturbance
  • Research in Maine Anderson 1995, suggests that
    a 15 minute visit to a cormorant colony can
    result in up to 20 mortality among eggs and
    chicks in a given breeding year. Repeated
    disturbance can lead to the end of the colony

53
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Habitat Monitoring
  • On Kent Island, Nova Scotia, research learned
    that Leachs Storm Petrels are likely to desert
    their nesting burrows in case of disturbance
    during the first two weeks of incubation
  • Sensor networks advances the monitoring methods
    over the traditional invasive ones
  • Sensors can be deployed prior to the breeding
    season or other sensitive period or while plants
    are dormant or the ground is frozen on small
    islets where it would be unsafe or unwise to
    repeatedly attempt field studies
  • Sensor network deployment may be more economical
    method for conducting long-term studies than
    traditional personnel-rich methods
  • A deploy em and leave em strategy of wireless
    sensor usage would decrease the logistical needs
    to initial placement and occasional servicing

54
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Great Duck Island
  • The College of Atlantic (COA) is field testing
    in-situ sensor networks for habitat monitoring
  • Great Duck Island (GDI) is a 237 acre island
    located 15 km south of Mount Desert Island, Maine
  • At GDI, three major questions in monitoring the
    Leachs Storm Petrel Anderson 1995
  • What is the usage pattern of nesting burrows over
    the 24-72 hour cycle when one or both members of
    a breeding pair may alternate incubation duties
    with feeding at sea?
  • What changes can be observed in the burrow and
    surface environmental parameters during the
    course of the approximately 7 month breeding
    season (April-October)?

55
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Great Duck Island
  • What are the differences in the
    micro-environments with and without large numbers
    of nesting petrels?
  • Presence/absence data is obtained through
    occupancy detection and temperature differentials
    between burrows with adult birds and burrows that
    contain eggs, chicks, or are empty
  • Petrels will most likely enter or leave during
    the daytime however, 5-10 minutes during late
    evening and early morning measurements are needed
    to capture the entry and exit timings
  • More general environmental differentials between
    burrow and surface conditions can be captured by
    records every 2-4 hours during the extended
    breeding season whereas, the differences between
    popular and unpopular sites benefit from
    hourly sampling

56
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Great Duck Island Requirements
  • Internet Access
  • The sensor networks at GDI must be accessible via
    the Internet since the ability to support remote
    interactions with in-situ networks is essential
  • Hierarchical Network
  • Habitats of interest are located up to several
    kilometers away. A second tier of wireless
    networking provides connectivity to multiple
    patches of sensor networks deployed at each of
    the areas.
  • Sensor Network Longevity
  • Sensor networks that runs for several month from
    non-rechargeable power sources would be desirable
    since studies at GDI can span multiple field
    seasons

57
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Great Duck Island Requirements
  • Operating off-the grid
  • Every level of the network must operate with
    bounded energy supplies
  • Renewable energy such as solar power may be
    available some locations, disconnected operation
    is a possibility
  • GDI has enough solar power that run the
    application 24x7 with small probabilities of
    service interruptions due to power loss
  • Management at-a-distance
  • Remoteness of the field sites requires the
    ability to monitor and manage sensor networks
    over the Internet. The goal is no on-site
    presence for maintenance and administration
    during the field season, except for installation
    and removal of nodes

58
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Great Duck Island Requirements
  • Inconspicuous operation
  • It should not disrupt the natural processes or
    behaviors under study
  • Removing human presence from the study areas
    would eliminate a source of error and variation
    in data collection and source of disturbance
  • System behavior
  • Sensor networks should present stable,
    predictable, and repeatable behavior at all times
    since unpredictable system is difficult to debug
    and maintain
  • Predictability is essential in developing trust
    in these new technologies for life scientists

59
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Great Duck Island Requirements
  • In-situ interactions
  • Local interactions are required during initial
    development, maintenance and on-site visits
  • PDAs can be useful in accomplishing these tasks
    they may directly query a sensor, adjust
    operational parameters and so on
  • Sensors and sampling
  • The ability to sense light, temperature,
    infrared, relative humidity, and barometric
    pressure are essential set of measurements
  • Additional measurements may include
    acceleration/vibration, weight, chemical vapors,
    gas concentrations, pH, and noise levels

60
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Great Duck Island Requirements
  • Data archiving
  • Sensor readings must be achieved for off-line
    data mining and analysis
  • The reliable offloading of sensor logs to
    databases in the wired, powered infrastructure is
    essential
  • It is desirable to interactively drill-down and
    explore sensors in near real-time complement
    log-based studies. In this mode of operation, the
    timely delivery of sensor data is the key
  • Nodal data summaries and periodic
    health-and-status monitoring also requires timely
    delivery of the data

61
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • System Architecture
  • A tiered architecture is developed
  • The lowest level consists of the sensor nodes
    that perform general purpose computing and
    networking as well as application-specific
    sensing
  • The sensor nodes may be deployed in dense patches
    and transmit their data through the sensor
    network to the sensor network gateway
  • Gateway is responsible for transmitting sensor
    data from the sensor patch through a local
    transit network to the remote base station that
    provides WAN connectivity and data logging
  • The base station connects to database replicas
    across the internet
  • At last, the data is displayed to researchers
    through a user interface

62
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • System Architecture

Figure 1 System architecture for habitat
monitoring
63
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • System Architecture
  • The autonomous sensor nodes are placed in the
    areas of interest where each sensor node collects
    environmental data about its immediate
    surroundings
  • Since these sensors are placed close to the area
    of interest, they can be built using small and
    inexpensive individual sensors high spatial
    resolution can be achieved through dense
    deployment of sensor nodes
  • This architecture offers higher robustness
    compared to traditional approaches which use a
    few high quality sensors with complex signal
    processing
  • The computational module is a programmable unit
    that provides computation, storage and
    bidirectional communication with other nodes

64
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • System Architecture
  • The computational module interfaces with the
    analog and digital sensors on the sensor module,
    performs basic signal processing and dispatches
    the data according to the needs of the
    application
  • Compared to traditional data logging systems,
    networked sensors offer two main advantages they
    can be re-tasked in the field and they can
    communicate with the rest of the system
  • In-situ re-tasking gives researchers the ability
    to refocus their observations based on the
    analysis of the initial results initially,
    absolute temperature readings are desired, after
    a while, only significant temperature changes
    exceeding a threshold may become more useful

65
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • System Architecture
  • Individual sensor nodes communicate and
    coordinate with one another
  • These nodes form a multi-hop network by
    forwarding each others messages and if needed,
    the network can perform in-network aggregation
    (e.g., relaying the average temperature across
    the region)
  • Eventually, data from each sensor needs to be
    propagated to the Internet
  • The propagated data may be raw, filtered or
    processed data
  • Since direct wide area connectivity cannot be
    brought to each sensor path due to several
    reasons (e.g., cost of equipment, power,
    disturbance created by the installation of the
    equipment in the environment), wide are
    connectivity is brought to a base station instead

66
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • System Architecture
  • The base station may communicate with the sensor
    patch using a wireless LAN where each sensor
    patch is equipped with a gateway that can
    communicate with the sensor network and provides
    connectivity to the transit network
  • The transit network may consist of a single hop
    link or series of networked wireless nodes and
    each transit network design has different
    characteristics with respect to expected
    robustness, bandwidth, energy efficiency, cost
    and manageability
  • To provide data to remote end-users, the base
    station includes WAN connectivity and persistent
    data storage for the collection of sensor patches

67
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • System Architecture
  • It is expected that WAN connection will be
    wireless
  • The architecture needs to address the
    disconnection possibilities
  • Each layer (sensor nodes, gateways, base
    stations) has some persistent storage to protect
    against data loss due to power outage as well as
    data management services
  • At the sensor level, these will be primitive,
    taking the form of data logging
  • The base station may provide relational database
    service while the data management at the gateways
    falls somewhere in between
  • When it comes to data collection, long-latency is
    preferable to data loss
  • Users interact with the sensor network in two ways

68
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • System Architecture
  • Remote users access the replica of the base
    station database
  • This approach assists on integration with data
    analysis and mining tools while masking the
    potential wide area disconnections with the base
    stations
  • On-site users may require direct interaction with
    the network and this can be accomplished with a
    small, PDA-sized device, referred to as gizmo
  • Gizmo allows the user to interactively control
    the network parameters by adjusting the sampling
    rates, power management parameters and other
    network parameters
  • The connectivity between any sensor node and
    gizmo may or may not rely on functioning on
    multi-hop sensor network routing

69
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Sensor Network Node
  • UC Berkeley motes are used as the sensor nodes
  • Mica uses a single channel, 916 MHz radio from RF
    Monolithics to provide bi-directional
    communication at 40 Kbps, an Atmel Atmega 103
    microcontroller running at 4 MHz and 512 KB
    nonvolatile storage
  • A pair of conventional AA batteries and a DC
    boost converter provide the power source
    however, other renewable energy sources can be
    used

70
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Sensor Board
  • The Mica Weather Board provides sensors that
    monitor changing environmental conditions with
    the same functionality as a traditional weather
    station
  • The Mica Weather Board includes temperature,
    photoresistor, barometric pressure, humidity, and
    passive infrared (thermopile) sensors

Table 1 Mica Weather Board
71
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Sensor Board

Figure 2 Mica Hardware Platform The Mica sensor
node (left) with the Mica Weather Board developed
for environmental monitoring applications
72
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Energy Budget
  • Typical habitat monitoring applications need to
    run for nine months
  • The application chooses how to allocate the
    energy budget between sleep modes, sensing, local
    calculations and communications
  • Since different nodes have different functions,
    they also have different power requirements, for
    instance, the nodes near the gateway may need to
    forward all messages from a patch while a node in
    a nest may only need to report its own readings
  • When a set of power limited nodes exhaust their
    power supplies, the network can become
    disconnected and inoperable
  • There is a need to budget the power with respect
    to the energy bottlenecks of the network

73
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Energy Budget
  • The baseline life time of the node is determined
    by the current draw in the sleep state
  • Minimizing power in sleep mode means turning off
    the sensors, the radio and putting the processor
    into a deep sleep mode

Table 2 Power required by various Mica operations
74
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Sensor Deployment
  • A wireless sensor network using Mica motes with
    Mica Weather Board has been deployed in July 2002
  • Environmental protective packaging has been
    designed which minimally obstruct sensing
    functionality

Figure 3 Acrylic enclosure used for deploying
the Mica mote
75
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Patch Gateways
  • Usage of different gateway nodes directly affects
    the underlying available transit network
  • Two designs implemented an 802.11b single hop
    with an embedded Linux system and a single hop
    mote-to-mote network
  • Initially, CerfCube Cerfcube which is a small
    StrongARM-based embedded system to act as a
    sensor patch gateway, is chosen
  • Each gateway is equipped with a CompactFlash
    802.11b adapter
  • Gateway use permanent storage of up to 1GB
  • The mote-to-mote solution consisted of a mote
    connected to the base station and a mote in the
    sensor patch

76
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Patch Gateways
  • The differences between the mote and CerfCube
    include different
  • communication frequency
  • power requirements
  • software components
  • The motes MAC layer does not require
    bi-directional link like 802.11b
  • In addition, the mote sends raw data with a small
    packet header (4 bytes) directly over the radio
    as opposed to overheads imposed by 802.11b and
    TCP/IP connections

77
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Base-station installation
  • For achieve remote access, collection of sensor
    patches is connected to the Internet through a
    wide-area link
  • On GDI, Internet connectivity is accomplished
    through a two-way satellite connection provided
    by Hughes and similar to DirecTV system
  • The satellite system is connected to a laptop
    which coordinates the sensor patches and provides
    a relational database service
  • Database Management System
  • The base station uses Postgres SQL database which
    stores time-stamped readings from the sensors,
    health status of the individual sensors, and
    metadata (e.g., sensor locations)

78
Wireless Sensor Networks for Habitat Monitoring
Mainwaring 2002
  • Implementation Strategies
  • Database Management System
  • The GDI database is replicated every fifteen
    minutes over the wide-area satellite link to
    Postgres database in Berkeley
  • User Interfaces
  • Many user interfaces can be implemented on top of
    the sensor database
  • GIS systems provide a widely used standard for
    analyzing geographical data and most statistics
    and data analysis packages implement interfaces
    to relational databases
  • Number of web interfaces can be implemented to
    provide the ubiquitous interfaces to the habitat
    data

79
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • Introduction
  • Focus is on issues related to dynamic sensor
    networks with mobile nodes and wireless
    communication between them
  • In this system, the sensor nodes collars carried
    by the animals under study wireless ad hoc
    networking techniques are used to swap and store
    data in a peer-to-peer manner and to pass it
    towards a mobile base station that sporadically
    traverses the area to upload data
  • Biology and biocomplexity research has been
    focused on gathering data and observations on a
    range of species to understand their interactions
    and influences on each other
  • For example, how human development into
    wilderness areas affects indigenous species
    there understand the migration patterns of wild
    animals and how they may be affected by changes
    in weather patterns or plant life, by
    introduction of non-native species, and by other
    influences

80
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • Introduction
  • Finding and learning these details require
    long-term position logs and other biometric data
    such as heart rate, body temperature, and
    frequency feeding
  • Current wildlife tracking studies rely on simple
    technology, for example, many studies rely on
    collaring a sample subset of animals with simple
    VHF transmitters
  • Researchers periodically drive through and/or fly
    over an area with a receiver antenna, and listen
    for pings from previously collared animals
  • Once animal is found, its behavior can be
    observed and its observed position can be logged
    however, there are limits to such studies
  • First, data collection is infrequent and can miss
    many interesting events

81
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • Introduction
  • Second, data collection is mostly limited to
    daylight hours, but animal behavior and movements
    in night hours can be different
  • Third, data collection is impossible or very
    limited for secluded species that avoid human
    contact
  • The most elegant trackers commercially available
    use GPS to track position and use satellite
    uploads to transfer data to a base station
  • These systems also suffer from several
    limitations
  • First, at most a log of 3000 position samples can
    be logged and no biometric data
  • Second, since satellite uploads are slow and uses
    high power consumption, they are done
    infrequently this limits how often position
    samples can be gathered without overflowing
    3000-entry log storage

82
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • Introduction
  • Third, downloads of data from the satellite to
    the researchers are both slow and expensive,
    therefore, constraining the amount of data
    collected
  • Finally, these systems operate on batteries
    without recharge when power is drained, the
    system become unusable unless it is retrieved,
    recharged and re-deployed
  • ZebraNet project is building tracking nodes that
    include a low-power miniature GPS system with
    user-programmable CPU, non-volatile storage for
    data logs, and radio transceivers for
    communicating either with other nodes or with a
    base station

83
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • Introduction
  • One of the key principles of ZebraNet is that the
    system should work in arbitrary wilderness
    locations no assumptions are made about the
    presence of of fixed antenna towers or cellular
    phone service
  • The system uses peer-to-peer data swaps to move
    the data around periodic researcher drives bys
    and/or fly-overs can collect logged data from
    several animals despite encountering relatively
    few within range
  • Even though ad hoc sensor networks have been
    heavily studied, not much has been published
    about the characteristics of mobile sensor
    networks with mobile base stations and very few
    studies focus on building real systems

84
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • Introduction
  • This paper has the following unique
    contributions
  • To the best knowledge of authors, this is the
    first study of mobile sensor networks protocols
    in which the base station is also mobile. It is
    presumed that researchers will upload data while
    driving or flying by the region
  • Zebra-tracking is a domain in which the node
    mobility models are unknown which makes it a
    research goal. Understanding how, when and why
    zebras undertake long-term migrations is the most
    essential biological question of this work.
  • ZebraNets data collection has communication
    patterns in which data can be cooperatively
    passed towards a base station
  • Energy tradeoffs are examined in detail using
    real system energy measurements for ZebraNet
    prototype hardware in operation

85
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • Introduction
  • Some of the interesting research questions to be
    explored are
  • How to make the communications protocol both
    effective and power-efficient?
  • To what extent can we rely on ad hoc,
    peer-to-peer transfers in a sparsely-connected
    spatially-huge sensor network?
  • How can we provide comprehensive tracking of a
    collection of animals, even if some of the
    animals are reclusive and rarely are close enough
    to humans to have their data logs updated
    directly?
  • This research work gives quantitative
    explorations of the design decisions behind some
    of these questions

86
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • ZebraNet Design Goals
  • The ZebraNet project is a direct and ongoing
    collaboration between researchers in experimental
    computer systems and in wildlife biology
  • The wildlife biologists have determined the
    trackers overall design goals
  • GPS position samples are taken every three
    minutes
  • Detailed activity logs taken for three minutes
    every hour
  • One year of operation without direct human
    intervention that is, not counting on
    tranquilizing and re-collaring an animal more
    than once per year
  • No fixed base stations, antennas, or cellular
    service
  • A high success rate for eventually delivering all
    logged data is essential while latency is not as
    critical
  • For a zebra collar, a weight limit of 3-5 lbs is
    recommended

87
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • ZebraNet Design Goals
  • Ultimately, this detailed information may include
    several position estimates, temperature
    information, weather data, environmental data,
    and body movements that will serve as signatures
    of behavior however, in this initial system, the
    focus is only on position data
  • Overall, the key goal is to deliver to
    researchers a very high fraction of the data
    collected over the months or years that the
    system is in operation
  • Therefore, ZebraNet must be power-efficient,
    designed with appropriate data log storage, and
    must be rugged to ensure reliability under tough
    environmental conditions

88
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • ZebraNet Problem Statement
  • The biologists design goals need to be translated
    into the engineering task at hand
  • Success rate at delivering position data to the
    researchers data homing rate should approach
    100
  • Weight limits on each node translate almost
    directly to computational energy limits since
    weight of the battery and solar panel takes bulk
    of the total weight of a ZebraNet node
    therefore, collar and protocol design decisions
    must manage the number and size of data
    transmissions required
  • System design choices must be made that limit the
    range of transmissions since the required
    transmitter energy increases dramatically with
    the distance transmitted

89
Energy-Efficient Computing for Wildlife Tracking
Design Tradeoffs and Early Experiences with
ZebraNet Juang 2002
  • ZebraNet Problem Statement
  • The amount of storage needed to hold position
    logs must be limited if many redundant copies
    are stored and swapped, the storage requirements
    can scale as O(n2)
  • Although the energy cost of storage is small
    compared to that of transmissions, it is still
    necessary to develop storage-efficient design
  • Due to limited transceiver, coverage and a base
    station only sporadically available, ZebraNet
    must forward data through other nodes in
    peer-to-peer manner and store redundant copies of
    position logs in other tracking nodes
  • Some of the key challenges in ZebraNet come from
    the spatial and temporal scale of the system

90
Energy-Efficient Computing for Wildl
Write a Comment
User Comments (0)
About PowerShow.com